[要約] 要約：RFC 7927は、情報中心ネットワーキング（ICN）の研究課題についてのガイドラインです。ICNの特徴、課題、および将来の研究方向について詳しく説明しています。目的：このRFCの目的は、ICNの研究者や開発者に対して、ICNの課題や可能性についての理解を深め、将来の研究に役立つガイドラインを提供することです。
Internet Research Task Force (IRTF) D. Kutscher, Ed.
Request for Comments: 7927 NEC
Category: Informational S. Eum
ISSN: 2070-1721 Osaka University
K. Pentikousis
Travelping
I. Psaras
UCL
D. Corujo
Universidade de Aveiro
D. Saucez
INRIA
T. Schmidt
HAW Hamburg
M. Waehlisch
FU Berlin
July 2016
Information-Centric Networking (ICN) Research Challenges
情報中心型ネットワーキング（ICN）の研究課題
Abstract
概要
This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.
このメモは、情報中心のネットワーキング（ICN）の研究課題について説明します。これは、一意の名前の付いたデータをインターネットのコア原則として導入することにより、インターネットインフラストラクチャを進化させて情報配信を直接サポートするアプローチです。データは場所、アプリケーション、ストレージ、および輸送手段から独立し、セキュリティ、ユーザーモビリティ、マルチキャスト、ネットワーク内キャッシュなど、多くの望ましい機能を有効化または強化します。これらの利点を実現するためのメカニズムは、IRTFやその他の場所で進行中の研究の主題です。このドキュメントでは、ネーミング、セキュリティ、ルーティング、システムスケーラビリティ、モビリティ管理、ワイヤレスネットワーキング、トランスポートサービス、ネットワーク内キャッシング、ネットワーク管理など、ICNにおける現在の研究課題について説明します。
This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).
このドキュメントは、IRTF Information-Centric Networking Research Group（ICNRG）の製品です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、Internet Research Task Force（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 http://www.rfc-editor.org/info/rfc7927.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7927で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................4
2. Problems with Host-Centric Communications .......................4
3. ICN Terminology and Concepts ....................................6
3.1. Terminology ................................................6
3.2. Concepts ...................................................6
4. ICN Research Challenges .........................................8
4.1. Naming, Data Integrity, and Data Origin Authentication .....8
4.2. Security ..................................................10
4.2.1. Data Integrity and Origin Authentication ...........10
4.2.2. Binding NDOs to Real-World Identities ..............11
4.2.3. Access Control and Authorization ...................12
4.2.4. Encryption .........................................13
4.2.5. Traffic Aggregation and Filtering ..................13
4.2.6. State Overloading ..................................13
4.2.7. Delivering Data Objects from Replicas ..............14
4.2.8. Cryptographic Robustness ...........................14
4.2.9. Routing and Forwarding Information Bases ...........15
4.3. Routing and Resolution System Scalability .................15
4.3.1. Route-By-Name Routing ..............................15
4.3.2. Lookup-By-Name Routing .............................16
4.3.3. Hybrid Routing .....................................17
4.4. Mobility Management .......................................18
4.5. Wireless Networking .......................................20
4.6. Rate and Congestion Control ...............................22
4.7. In-Network Caching ........................................24
4.7.1. Cache Placement ....................................24
4.7.2. Content Placement: Content-to-Cache Distribution ...25
4.7.3. Request-to-Cache Routing ...........................26
4.7.4. Staleness Detection of Cached NDOs .................26
4.7.5. Cache Sharing by Multiple Applications .............27
4.8. Network Management ........................................27
4.9. ICN Applications ..........................................29
4.9.1. Web Applications ...................................30
4.9.2. Video Streaming and Download .......................30
4.9.3. Internet of Things .................................31
5. Security Considerations ........................................32
6. Informative References .........................................32
Acknowledgments ...................................................37
Authors' Addresses ................................................37
Information-Centric Networking (ICN) is an approach to evolve the Internet infrastructure to directly support accessing Named Data Objects (NDOs) as a first-order network service. Data objects become independent of location, application, storage, and means of transportation, allowing for inexpensive and ubiquitous in-network caching and replication. The expected benefits are improved efficiency and security, better scalability with respect to information/bandwidth demand, and better robustness in challenging communication scenarios.
情報中心型ネットワーキング（ICN）は、インターネットインフラストラクチャを進化させて、一次ネットワークサービスとしての名前付きデータオブジェクト（NDO）へのアクセスを直接サポートするアプローチです。データオブジェクトは、場所、アプリケーション、ストレージ、および輸送手段から独立しているため、安価でユビキタスなネットワーク内のキャッシングとレプリケーションが可能です。期待される利点は、効率とセキュリティの向上、情報/帯域幅の要求に関するスケーラビリティの向上、および困難な通信シナリオにおける堅牢性の向上です。
ICN concepts can be deployed by retooling the protocol stack: name-based data access can be implemented on top of the existing IP infrastructure, e.g., by allowing for named data structures, ubiquitous caching, and corresponding transport services, or it can be seen as a packet-level internetworking technology that would cause fundamental changes to Internet routing and forwarding. In summary, ICN can evolve the Internet architecture towards a network model based on named data with different properties and different services.
ICNの概念は、プロトコルスタックを再構築することで導入できます。名前ベースのデータアクセスは、既存のIPインフラストラクチャの上に実装できます。たとえば、名前付きデータ構造、ユビキタスキャッシング、対応するトランスポートサービスを許可したり、次のように表示したりできます。インターネットのルーティングと転送に根本的な変化をもたらすパケットレベルのインターネットワーキング技術。要約すると、ICNは、さまざまなプロパティとさまざまなサービスを持つ名前付きデータに基づいて、インターネットアーキテクチャをネットワークモデルに進化させることができます。
This document presents the ICN research challenges that need to be addressed in order to achieve these goals. These research challenges are seen from a technical perspective, although business relationships between Internet players will also influence developments in this area. We leave business challenges for a separate document, however. The objective of this memo is to document the technical challenges and corresponding current approaches and to expose requirements that should be addressed by future research work.
このドキュメントでは、これらの目標を達成するために対処する必要があるICN研究の課題を示します。これらの研究課題は技術的な観点から見られますが、インターネットプレイヤー間のビジネス関係もこの分野の発展に影響を与えます。ただし、ビジネス上の課題は別のドキュメントに任せます。このメモの目的は、技術的な課題と対応する現在のアプローチを文書化し、将来の研究作業で対処する必要がある要件を明らかにすることです。
This document has been reviewed, commented on, and discussed extensively for nearly two years by the vast majority of ICNRG members, which certainly exceeds 100 individuals. It is the consensus of ICNRG that the research challenges described in this document should be published in the IRTF stream of the RFC series. This document does not constitute a standard.
この文書は、ほぼ100名を超えるICNRGメンバーの大多数によって、2年近くにわたってレビュー、コメント、および広範囲にわたって議論されてきました。この文書で説明されている研究課題がRFCシリーズのIRTFストリームで公開されるべきであるというのがICNRGの合意です。この文書は標準を構成するものではありません。
The best current practice to manage the above-mentioned growth in terms of data volume and number of devices is to increase infrastructure investment, employ application-layer overlays that cache content such as Content Distribution Networks (CDNs) and Peer-to-Peer (P2P) applications, provide location-independent access to data, and optimize its delivery. In principle, such platforms provide a service model of accessing named data objects (NDOs) (e.g., replicated web resources in data centers) instead of a host-to-host packet delivery service model.
データ量とデバイス数の観点から上記の成長を管理するための現在のベストプラクティスは、インフラストラクチャへの投資を増やすことです。コンテンツ配布ネットワーク（CDN）やピアツーピア（P2P）などのコンテンツをキャッシュするアプリケーションレイヤーオーバーレイを採用します。 ）アプリケーション、データへの場所に依存しないアクセスを提供し、その配信を最適化します。原則として、このようなプラットフォームは、ホスト間パケット配信サービスモデルではなく、名前付きデータオブジェクト（NDO）（たとえば、データセンターで複製されたWebリソース）にアクセスするサービスモデルを提供します。
However, since this functionality resides in overlays only, the full potential of content distribution platforms cannot be leveraged as the network is not aware of data requests and data transmissions. This has the following impact:
ただし、この機能はオーバーレイにのみ存在するため、ネットワークはデータ要求とデータ送信を認識していないため、コンテンツ配信プラットフォームの可能性を完全に活用することはできません。これには次の影響があります。
o Data traffic typically follows sub-optimal paths as it is effectively routed, depending on the overlay topology instead of the Internet-layer topology.
o データトラフィックは、インターネット層トポロジではなくオーバーレイトポロジに応じて、効果的にルーティングされるため、通常は次善のパスをたどります。
o Network capabilities, such as multicast and broadcast, are largely underutilized or not employed at all. As a result, request and delivery for the same object have to be made multiple times.
o マルチキャストやブロードキャストなどのネットワーク機能は、ほとんど活用されていないか、まったく採用されていません。その結果、同じオブジェクトに対する要求と配信は複数回行われる必要があります。
o Overlays typically require significant infrastructure support, e.g., authentication portals, content storage, and applications servers, making it often impossible to establish local, direct communication.
o オーバーレイは通常、認証ポータル、コンテンツストレージ、アプリケーションサーバーなどの重要なインフラストラクチャサポートを必要とするため、ローカルの直接通信を確立することがしばしば不可能になります。
o The forwarding layer cannot cooperate with transport-layer functions, so sometimes useful functionality such as local retransmission and local rate control have to be implemented with TCP proxies or other intermediaries.
o 転送層はトランスポート層機能と連携できないため、ローカル再送信やローカルレート制御などの有用な機能を、TCPプロキシまたは他の中間機能で実装する必要がある場合があります。
o Provenance validation uses host authentication today. As such, even if there are locally cached copies available, it is normally not easily possible to validate their authenticity.
o 来歴の検証では、現在ホスト認証を使用しています。そのため、ローカルにキャッシュされたコピーが利用できる場合でも、通常、その信頼性を検証することは簡単にはできません。
o Many applications follow their own approach to caching, replication, transport, and authenticity validation (if at all), although they all share similar models for accessing named data objects in the network.
o 多くのアプリケーションは、ネットワーク内の名前付きデータオブジェクトにアクセスするための同様のモデルを共有していますが、キャッシング、レプリケーション、トランスポート、および真正性検証（ある場合）に対する独自のアプローチに従います。
Host-centric communication systems restrict applications to data transfer between end-hosts only. Naming data directly provides a powerful "hook" for applications to exploit and natively support multi-party communication, e.g., multi-source/multi-destination communication and a ubiquitous information ecosystem that is not restricted to end-host addresses.
ホスト中心の通信システムは、アプリケーションをエンドホスト間のデータ転送のみに制限します。データに名前を付けることで、アプリケーションが強力な「フック」を提供し、マルチソース通信、マルチ宛先通信などのマルチパーティ通信や、エンドホストアドレスに限定されないユビキタス情報エコシステムなどを活用してネイティブにサポートします。
Information-Centric Networking (ICN): A concept for communicating in a network that provides accessing named data objects as a first order service. See Section 3.2 for details.
情報中心型ネットワーキング（ICN）：名前付きデータオブジェクトへのアクセスを一次サービスとして提供するネットワークで通信するための概念。詳細については、セクション3.2を参照してください。
Named Data Object (NDO): Addressable data unit in an information-centric network that can represent a collection of bytes or a piece of information. In ICN, each data object has a name bound to it, and there are typically mechanisms to secure (and validate) this binding. Different ICN approaches have different concepts for how to map NDOs to individual units of transport, e.g., chunks and segments. Sometimes smaller units may be represented by NDOs themselves. Within the context of this document, an NDO is any named data object that can be requested from the network, and we do not consider sub-units below the NDO level. In this document, we often use the terms "NDO" and "data object" interchangeably.
名前付きデータオブジェクト（NDO）：バイトのコレクションまたは情報の一部を表すことができる情報中心のネットワーク内のアドレス可能なデータ単位。 ICNでは、各データオブジェクトにバインドされた名前があり、通常、このバインディングを保護（および検証）するメカニズムがあります。 ICNのアプローチが異なれば、NDOをチャンクやセグメントなどの個々のトランスポートユニットにマッピングする方法も異なります。時には、より小さな単位がNDO自体によって表される場合があります。このドキュメントのコンテキスト内では、NDOはネットワークから要求できる任意の名前付きデータオブジェクトであり、NDOレベルより下のサブユニットは考慮しません。このドキュメントでは、「NDO」と「データオブジェクト」という用語を同じ意味で使用することがよくあります。
Requestor: Entity in an ICN network that is sending a request for a named data object to the network.
リクエスタ：名前付きデータオブジェクトのリクエストをネットワークに送信しているICNネットワークのエンティティ。
Publisher: Entity in an ICN network that publishes an NDO to the network, so that corresponding requests can reach the publisher. The publisher does not need to be identical to the actual creator, for example, a publisher could provide the service of hosting NDOs on behalf of the actual creators/owners.
パブリッシャー：NDOをネットワークにパブリッシュするICNネットワークのエンティティ。対応するリクエストがパブリッシャーに到達できるようにします。パブリッシャーは実際の作成者と同一である必要はありません。たとえば、パブリッシャーは実際の作成者/所有者に代わってNDOをホストするサービスを提供できます。
Fundamentally, ICN provides access to named data as a first-order network service, i.e., the network is able to serve requests to named data natively. That means network nodes can receive requests for named data and act as necessary, for example, by forwarding the request to a suitable next hop. Consequently, the network processes requests for named data objects (and corresponding responses) natively. Every network node on a path is enabled to perform forwarding decisions, cache objects, etc. This enables the network to forward such requests on optimal paths, employing the best transmission technologies at every node, e.g., broadcast/multicast transmission in wireless networks to avoid duplicate transmission of both requests and responses.
基本的に、ICNは名前付きデータへのアクセスを一次ネットワークサービスとして提供します。つまり、ネットワークは名前付きデータへのリクエストをネイティブで処理できます。これは、ネットワークノードが名前付きデータの要求を受信し、要求を適切なネクストホップに転送するなどして、必要に応じて機能できることを意味しています。その結果、ネットワークは名前付きデータオブジェクト（および対応する応答）の要求をネイティブに処理します。パス上のすべてのネットワークノードは、転送の決定、オブジェクトのキャッシュなどを実行できます。これにより、ネットワークは、そのような要求を最適なパスで転送し、すべてのノードで最高の伝送技術を使用できます。要求と応答の両方の複製送信。
In ICN, there is a set of common concepts and node requirements beyond this basic service model. Naming data objects is a key concept. In general, ICN names represent neither network nodes nor interfaces -- they represent NDOs independently of their location.
ICNには、この基本的なサービスモデル以外にも、一連の共通の概念とノード要件があります。データオブジェクトの命名は重要な概念です。一般に、ICN名はネットワークノードでもインターフェースでもありません。それらは場所に関係なくNDOを表します。
Names do play a key role in forwarding decisions and are used for matching requests to responses: in order to provide better support for accessing copies of NDOs regardless of their location, it is important to be able to validate that a response actually delivers the bits that correspond to an original request for named data.
名前は決定を転送する上で重要な役割を果たし、要求と応答の照合に使用されます。場所に関係なくNDOのコピーにアクセスするためのより良いサポートを提供するには、応答が実際にビットを提供することを検証できることが重要です名前付きデータの元のリクエストに対応します。
Name-content binding validation is a fundamental security service in ICN, and this is often achieved by establishing a verifiable binding between the object name and the actual object or an identity that has created the object. ICN can support other security services, such as provenance validation and encryption, depending on the details of naming schemes, object models, and assumptions on infrastructure support. Security services such as name-content binding validation are available to any node, i.e., not just the actual requestors. This is an important feature for enabling ingress gateways to check object authenticity to prevent denial-of-service attacks.
名前とコンテンツのバインディング検証はICNの基本的なセキュリティサービスであり、オブジェクト名と実際のオブジェクト、またはオブジェクトを作成したIDとの間に検証可能なバインディングを確立することで実現できます。 ICNは、命名スキーム、オブジェクトモデル、インフラストラクチャサポートの前提の詳細に応じて、来歴の検証や暗号化などの他のセキュリティサービスをサポートできます。名前とコンテンツのバインディング検証などのセキュリティサービスは、実際のリクエスタだけでなく、どのノードでも利用できます。これは、イングレスゲートウェイがオブジェクトの信頼性をチェックしてサービス拒否攻撃を防ぐための重要な機能です。
Based on these fundamental properties, it is possible to leverage network storage ubiquitously: every ICN node can cache data objects and respond to requests for such objects -- it is not required to validate the authenticity of the node itself since name-content bindings can be validated. Ubiquitous in-network storage can be used for different purposes: it can enable sharing, i.e., the same object copy can be delivered to multiple users/nodes as in today's proxy caches and CDNs. It can also be used to make communication more robust (and perform better) by enabling the network to answer requests from local caches (instead of from origin servers). In case of disruption (message not delivered), a node can resend the request, and it could be answered by an on-path cache, i.e., on the other side of the disrupted link. The network itself would be able to send local retransmissions, which enables shorter round-trip times and the offloading of origin servers and other parts of the network.
これらの基本的な特性に基づいて、ネットワークストレージをユビキタスに活用できます。すべてのICNノードはデータオブジェクトをキャッシュし、そのようなオブジェクトのリクエストに応答できます。名前とコンテンツのバインディングはノード自体の信頼性を検証する必要はありません検証済み。ユビキタスネットワーク内ストレージはさまざまな目的に使用できます。つまり、共有を可能にすることができます。つまり、現在のプロキシキャッシュやCDNと同じように、同じオブジェクトのコピーを複数のユーザー/ノードに配信できます。また、ネットワークが（オリジンサーバーからではなく）ローカルキャッシュからのリクエストに応答できるようにすることで、通信をより堅牢にする（そしてパフォーマンスを向上させる）ためにも使用できます。中断（メッセージが配信されない）の場合、ノードは要求を再送信でき、パス上のキャッシュ、つまり、中断されたリンクの反対側で応答できます。ネットワーク自体がローカルの再送信を送信できるため、往復時間が短縮され、配信元サーバーやネットワークの他の部分の負荷が軽減されます。
ICN potentially retrieves segments of NDOs from multiple data sources, so only a requestor can determine the completion of a retrieval process, i.e., the retrieval of NDOs or individual segments is typically controlled by a requestor. For this reason, ICN transport protocols are typically based on a receiver-driven mechanism: requestors can control message sending rates by regulating the request sending rate (assuming that every response message has to be triggered by a request message). Retransmission would be achieved by resending requests, e.g., after a timeout. Because objects can be replicated, object transmission and transport sessions would not necessarily have end-to-end semantics: requests can be answered by caches, and a node can select one or multiple next-hop destinations for a particular request depending on configuration, observed performance, or other criteria.
ICNは複数のデータソースからNDOのセグメントを取得する可能性があるため、リクエスタのみが取得プロセスの完了を判断できます。つまり、NDOまたは個々のセグメントの取得は通常、リクエスタによって制御されます。このため、ICNトランスポートプロトコルは通常、受信者主導のメカニズムに基づいています。リクエスターは、リクエスト送信レートを調整することでメッセージ送信レートを制御できます（すべての応答メッセージがリクエストメッセージによってトリガーされる必要があると想定）。再送信は、たとえばタイムアウト後にリクエストを再送信することで実現されます。オブジェクトは複製できるため、オブジェクトの送信セッションとトランスポートセッションは必ずしもエンドツーエンドのセマンティクスを持つ必要はありません。要求はキャッシュによって応答され、ノードは特定の要求に対して、構成に応じて1つまたは複数のネクストホップ宛先を選択できます。パフォーマンス、または他の基準。
This receiver-driven communication model potentially enables new interconnection and business models: a request for named data can be linked to an interest of a requestor (or requesting network) in data from another peer, which could suggest modeling peering agreements and charging accordingly.
このレシーバー主導の通信モデルにより、新しい相互接続とビジネスモデルが可能になる可能性があります。名前付きデータのリクエストは、別のピアからのデータのリクエスター（またはリクエストネットワーク）の関心にリンクできるため、ピアリング契約のモデリングとそれに応じた課金を提案できます。
Naming data objects is as important for ICN as naming hosts is for today's Internet. Fundamentally, ICN requires unique names for individual NDOs, since names are used for identifying objects independently of their location or container. In addition, since NDOs can be cached anywhere, the origin cannot be trusted anymore, hence the importance of establishing a verifiable binding between the object and its name (name-data binding validation) so that a requestor can be sure that the received bits do correspond to the NDO originally requested (data integrity). Data origin authentication is a different security service that can be related to naming, i.e., verifying that an NDO has indeed been published by a publisher (that could be identified by a name prefix).
ホストの命名が今日のインターネットの場合と同様に、データオブジェクトの命名もICNにとって重要です。名前はオブジェクトの場所やコンテナとは無関係にオブジェクトを識別するために使用されるため、基本的に、ICNでは個々のNDOに一意の名前が必要です。さらに、NDOはどこにでもキャッシュできるため、オリジンを信頼できなくなり、オブジェクトとその名前の間に検証可能なバインディングを確立すること（名前とデータのバインディング検証）が重要になります。最初に要求されたNDOに対応します（データ整合性）。データ発信元認証は、名前付けに関連する別のセキュリティサービスです。つまり、NDOが本当にパブリッシャーによって発行されていることを確認します（名前のプレフィックスで識別できます）。
The above functions are fundamentally required for the information-centric network to work reliably; otherwise, neither network elements nor requestors can trust object authenticity. Lack of this trust enables several attacks, including DoS attacks, by injecting spoofed content into the network. There are different ways to use names and cryptography to achieve the desired functions [ICNNAMING] [ICNSURVEY], and there are different ways to manage namespaces correspondingly.
上記の機能は、情報中心のネットワークが確実に機能するために基本的に必要です。そうでない場合、ネットワーク要素もリクエスタもオブジェクトの信頼性を信頼できません。この信頼の欠如により、なりすましコンテンツをネットワークに挿入することにより、DoS攻撃を含むいくつかの攻撃が可能になります。名前と暗号化を使用して目的の機能を実現する方法はいくつかあります[ICNNAMING] [ICNSURVEY]。それに応じて名前空間を管理する方法もいくつかあります。
Two types of naming schemes have been proposed in the ICN literature: hierarchical and flat namespaces. For example, a hierarchical scheme may have a structure similar to current URIs, where the hierarchy is rooted in a publisher prefix. Such hierarchy enables aggregation of routing information, improving scalability of the routing system. In some cases, names are human readable, which makes it possible for users to manually type in names, reuse, and, to some extent, map the name to the user intent.
ICNの文献では、階層型とフラットの名前空間という2つのタイプの命名方式が提案されています。たとえば、階層スキームは、現在のURIに似た構造を持ち、階層はパブリッシャープレフィックスに基づいています。このような階層により、ルーティング情報の集約が可能になり、ルーティングシステムのスケーラビリティが向上します。場合によっては、名前は人間が判読できるため、ユーザーが手動で名前を入力し、再利用し、ある程度、ユーザーの意図に名前をマッピングすることができます。
The second general class of naming schemes enables verifying the object's name-data integrity without requiring a Public Key Infrastructure (PKI) or other third party to first establish trust in the key. This is achieved, e.g., by binding the hash of the NDO content to the object's name. For instance, this can be done by directly embedding the hash of the content in the name. Another option is an indirect binding, which embeds the public key of the publisher in the name and signs the hash of the content with the corresponding private key. The resulting names are typically non-hierarchical, or flat, although the publisher field could be employed to create a structure that could facilitate route aggregation.
命名方式の2番目の一般的なクラスでは、公開鍵基盤（PKI）または他のサードパーティが最初に鍵の信頼を確立する必要なく、オブジェクトの名前とデータの整合性を検証できます。これは、たとえば、NDOコンテンツのハッシュをオブジェクトの名前にバインドすることによって実現されます。たとえば、コンテンツのハッシュを名前に直接埋め込むことでこれを行うことができます。別のオプションは、名前に発行者の公開鍵を埋め込み、対応する秘密鍵でコンテンツのハッシュに署名する間接バインディングです。結果の名前は、通常、非階層的またはフラットですが、パブリッシャーフィールドを使用して、ルート集約を容易にする構造を作成できます。
There are several design trade-offs for ICN naming that affect routing and security. Hash-based names are not human readable nor hierarchical. They can, however, provide some structure for aggregation, for instance, a name part corresponding to a publisher. In hash-based names with indirect binding, the key of the publisher is bound to the name of NDO, so when a user receives, e.g., the triplet, namely (data, key, signature), the receiving entity can verify that the NDO has been generated by the possessor of the private/public key pair and that the NDO has not been changed in transit (data integrity). This can be done by cryptographically hashing the received key and the name of the NDO, and comparing it with the received hashed key. Then, the key can be used to verify the signature.
ICNの命名には、ルーティングとセキュリティに影響を与える設計上のトレードオフがいくつかあります。ハッシュベースの名前は人間が読めるものでも階層的でもありません。ただし、パブリッシャーに対応する名前部分など、集計の構造を提供できます。間接バインディングを使用するハッシュベースの名前では、パブリッシャーのキーはNDOの名前にバインドされているため、ユーザーが、たとえば、トリプレット、つまり（データ、キー、署名）を受信すると、受信エンティティはNDOを確認できます。秘密鍵と公開鍵のペアの所有者によって生成され、NDOが転送中に変更されていない（データの整合性）。これは、受信したキーとNDOの名前を暗号化してハッシュし、受信したハッシュしたキーと比較することで実行できます。次に、キーを使用して署名を検証できます。
Data origin authentication can be achieved by validating signatures based on public key cryptography about an NDO's name and content. In order to ascertain data integrity and origin authenticity with such an approach, a PKI-like system is required that would allow linking the corresponding public key to a trust chain.
データの起点認証は、NDOの名前と内容に関する公開鍵暗号に基づいて署名を検証することで実現できます。このようなアプローチでデータの整合性と発信元の信頼性を確認するには、対応する公開鍵を信頼チェーンにリンクできるようにするPKIのようなシステムが必要です。
Research challenges specific to naming include:
命名に固有の研究課題は次のとおりです。
o Naming static data objects can be performed by using content hashes as part of object names, so that publishers can calculate the hash over existing data objects and requestors, and any ICN node can validate the name-content binding by recalculating the hash and comparing it to the name (component). [RFC6920] specifies a concrete naming format for this.
o 静的データオブジェクトの命名は、オブジェクト名の一部としてコンテンツハッシュを使用して実行できるため、パブリッシャーは既存のデータオブジェクトとリクエスターに対するハッシュを計算でき、ICNノードは、ハッシュを再計算してそれと比較することにより、名前とコンテンツのバインディングを検証できます。名前（コンポーネント）。 [RFC6920]は、このための具体的な命名形式を指定しています。
o Naming dynamic objects refers to use cases where the name has to be generated before the object is created. For example, this could be the case for live streaming, when a publisher wants to make the stream available by registering stream chunk names in the network. One approach to this can be hash-based names with indirect binding as described above.
o 動的オブジェクトの命名とは、オブジェクトを作成する前に名前を生成する必要があるユースケースを指します。たとえば、パブリッシャーがネットワークにストリームチャンク名を登録することでストリームを使用可能にしたい場合、これはライブストリーミングの場合です。これに対する1つのアプローチは、上記のように間接バインディングを使用したハッシュベースの名前にすることができます。
o Requestor privacy protection can be a challenge in ICN as a direct consequence of the accessing-named-data-objects paradigm: if the network can "see" requests and responses, it can also log request history for network segments or individual users, which can be undesirable, especially since names are typically expected to be long-lived. That is, even if the name itself does not reveal much information, the assumption is that the name can be used to retrieve the corresponding data objects in the future.
oリクエスターのプライバシー保護は、名前付きデータオブジェクトへのアクセスパラダイムの直接的な結果として、ICNでの課題となる可能性があります。特に名前は通常、存続期間が長いと予想されるため、これは望ましくありません。つまり、名前自体では多くの情報が明らかにならない場合でも、名前は将来対応するデータオブジェクトを取得するために使用できると想定されます。
o Updating and versioning NDOs can be challenging because it can contradict fundamental ICN assumptions: if an NDO can be replicated and stored in in-network storage for later retrieval, names have to be long-lived and the name-content binding must not change; updating an object (i.e., changing the content without generating a new name) is not possible. Versioning is one possible solution but requires a naming scheme that supports it (and a way for requestors to learn about newer and older versions).
o ICNの基本的な前提に反する可能性があるため、NDOの更新とバージョン管理は困難な場合があります。NDOを複製してネットワークストレージに格納し、後で取得できるようにする場合は、名前を長期間有効にする必要があり、名前とコンテンツのバインディングを変更してはなりません。オブジェクトを更新する（つまり、新しい名前を生成せずにコンテンツを変更する）ことはできません。バージョン管理は1つの可能なソリューションですが、それをサポートする命名方式（およびリクエスタが新しいバージョンと古いバージョンについて学習する方法）が必要です。
o Managing accessibility can also be a challenge. In ICN, the general assumption is to enable ubiquitous access to NDOs, but there can be relevant use cases where access to objects should be restricted, for example, to a specific user group. There are different approaches for this, such as object encryption (requiring key distribution and related mechanisms) or the concept of scopes, e.g., based on names that can only be used/resolved under some constraints.
o アクセシビリティの管理も難しい場合があります。 ICNでは、一般的な想定はNDOへのユビキタスアクセスを有効にすることですが、オブジェクトへのアクセスを特定のユーザーグループなどに制限する必要がある関連するユースケースがある場合があります。これには、オブジェクトの暗号化（鍵の配布と関連するメカニズムが必要）や、スコープの概念など、いくつかの制約の下でのみ使用/解決できる名前に基づくなど、さまざまなアプローチがあります。
Security is an active research field in ICN. This section provides an overview of important security features and corresponding challenges that are related to shifting to information-centric communications. Some challenges are well understood, and there are (sometimes multiple different) approaches to address them, whereas other challenges are active research and engineering topics.
セキュリティはICNの活発な研究分野です。このセクションでは、重要なセキュリティ機能の概要と、情報中心の通信への移行に関連する対応する課題について説明します。いくつかの課題はよく理解されており、それらに対処するための（場合によっては複数の異なる）アプローチがありますが、他の課題は活発な研究とエンジニアリングのトピックです。
As mentioned in Section 4.1, data integrity verification is an important ICN feature, since NDOs are retrieved not only from an original copy holder but also from any caching point. Hence, the communication channel endpoints to retrieve NDOs are not trustable anymore, and solutions widely used today such as Transport Layer Security (TLS) [RFC5246] cannot be used as a general solution. Since data objects can be maliciously modified, ICN should provide receivers with a security mechanism to verify the integrity of the data object, and there are different ways to achieve this.
セクション4.1で述べたように、NDOは元のコピーホルダーからだけでなく、任意のキャッシュポイントからも取得されるため、データ整合性検証は重要なICN機能です。したがって、NDOを取得するための通信チャネルエンドポイントは信頼できなくなり、トランスポート層セキュリティ（TLS）[RFC5246]などの今日広く使用されているソリューションは、一般的なソリューションとして使用できません。データオブジェクトは悪意を持って変更される可能性があるため、ICNはデータオブジェクトの整合性を検証するためのセキュリティメカニズムを受信者に提供する必要があり、これを実現するにはさまざまな方法があります。
An efficient approach for static NDOs is providing a name-content-binding by hashing an NDO and using the hash as a part of the object's name. [RFC6920] provides a mechanism and a format for representing a digest algorithm and the actual digest in a name (amongst other information).
静的NDOの効率的なアプローチは、NDOをハッシュし、そのハッシュをオブジェクトの名前の一部として使用することで、名前とコンテンツのバインディングを提供することです。 [RFC6920]は、ダイジェストアルゴリズムと実際のダイジェストを名前で（他の情報とともに）表すメカニズムとフォーマットを提供します。
For dynamic objects where it is desirable to refer to an NDO by name before the object has been created, public key cryptography is often applied, i.e., every NDO would be authenticated by means of a signature performed by the data object publisher so that any data object consumer can verify the validity of the data object based on the signature. However, in order to verify the signature of an object, the consumer must know the public key of the entity that signed the object.
オブジェクトが作成される前に名前でNDOを参照することが望ましい動的オブジェクトの場合、公開鍵暗号がしばしば適用されます。つまり、すべてのNDOは、データオブジェクトパブリッシャーによって実行される署名によって認証され、オブジェクトコンシューマは、署名に基づいてデータオブジェクトの有効性を確認できます。ただし、オブジェクトの署名を検証するには、コンシューマはオブジェクトに署名したエンティティの公開鍵を知っている必要があります。
Data origin authentication, i.e., verifying that an NDO has indeed been published by a publisher, requires a secure binding of an NDO name to a publisher identity -- this is also typically implemented using public key cryptography, i.e., by requiring a receiver to verify digital signatures that are part of received messages.
データ発信元認証、つまりNDOが実際にパブリッシャーによって発行されたことを確認するには、NDO名をパブリッシャーIDに安全にバインドする必要があります。これも、通常、公開鍵暗号を使用して、つまり受信者に確認を要求することによって実装されます。受信したメッセージの一部であるデジタル署名。
One research challenge is then to support a mechanism to distribute the publisher's public keys to the consumers of data objects. There are two main approaches to achieve this: one is based on an external third-party authority such as hierarchical Public Key Infrastructure (PKI) (see [RFC5280] for a description of hierarchical PKI), and the other is to adapt a hash-based scheme with indirect binding. The former, as the name implies, depends on an external third party authority to distribute the public key of the publisher for the consumers. In a hash-based scheme with indirect binding, the public key (or a hash of it) would be used as part of the name -- which is sufficient to validate the data integrity.
研究の課題の1つは、発行者の公開鍵をデータオブジェクトの消費者に配布するメカニズムをサポートすることです。これを達成するには、主に2つの方法があります。1つは階層的な公開鍵基盤（PKI）（階層的なPKIの説明については[RFC5280]を参照）などの外部の第三者機関に基づいており、もう1つはハッシュを適用することです。間接バインディングを使用したベースのスキーム。前者は、その名前が示すように、パブリッシャーの公開鍵をコンシューマーに配布するための外部の第三者機関に依存しています。間接バインディングを使用するハッシュベースのスキームでは、公開鍵（またはそのハッシュ）が名前の一部として使用されます。これは、データの整合性を検証するのに十分です。
In cases where information about the origin of a data object is not available by other means, the object itself would have to incorporate the necessary information to determine the object publisher, for example, with a certificate, that can be validated through the PKI. Once the certificate is authenticated, its public key can be used to authenticate the signed data object itself.
データオブジェクトの出所に関する情報が他の方法で利用できない場合、オブジェクト自体に必要な情報を組み込む必要があります。たとえば、証明書を使用して、PKIを通じて検証できるオブジェクト発行元を決定する必要があります。証明書が認証されると、その公開鍵を使用して、署名されたデータオブジェクト自体を認証できます。
In addition to validating NDO authenticity, it is still important to bind real-world identities, e.g., a publisher identity, to objects, so that a requestor can verify that a received object was actually published by a certain source.
NDOの信頼性を検証することに加えて、リクエスタが受信したオブジェクトが実際に特定のソースによって公開されたことを確認できるように、実際のID（パブリッシャーIDなど）をオブジェクトにバインドすることは依然として重要です。
With hash-based names, real-world identity bindings are not intrinsically established: the name provides the hash of the NDO or of the public key that was used to sign the NDO. There needs to be another binding to a real-world identity if that feature is requested.
ハッシュベースの名前では、実際のIDバインディングは本質的に確立されていません。名前は、NDOまたはNDOの署名に使用された公開鍵のハッシュを提供します。その機能が要求された場合、実世界のアイデンティティへの別のバインディングが必要です。
If the object name directly provides the publisher name and if that name is protected by a certificate that links to a PKI-like trust chain, the object name itself can provide an intrinsic binding to a real-world identity.
オブジェクト名がパブリッシャー名を直接提供し、その名前がPKIのような信頼チェーンにリンクする証明書によって保護されている場合、オブジェクト名自体が実際のIDへの組み込みバインディングを提供できます。
Binding between NDOs and real-world identities is essential, but there is no universal way to achieve it as it is all intrinsic to a particular ICN approach.
NDOと実際のIDの間のバインドは不可欠ですが、それはすべて特定のICNアプローチに固有のものであるため、それを実現する普遍的な方法はありません。
Access control and authorization is a challenge in ICN, because of the lack of user-to-server authentication in the fundamental communication model based on named data.
名前付きデータに基づく基本的な通信モデルにはユーザーからサーバーへの認証がないため、アクセス制御と承認はICNの課題です。
All ICN entities are capable of delivering NDOs on demand due to their in-network caching function. In such an environment, traditional access control schemes based on Access Control List (ACL) are ill-suited since widely distributed ICN entities have to maintain an identical control policy over NDOs for each consumer, which is prohibited due to computational overhead and privacy issues. There are two complementary approaches to address the issues:
すべてのICNエンティティは、ネットワーク内キャッシング機能により、オンデマンドでNDOを配信できます。このような環境では、広く分散しているICNエンティティが各消費者のNDOに対して同一の制御ポリシーを維持する必要があるため、アクセス制御リスト（ACL）に基づく従来のアクセス制御スキームは不適切です。これは、計算オーバーヘッドとプライバシーの問題のために禁止されています。この問題に対処するには、2つの補完的なアプローチがあります。
1. Separated approach: access control service from a third party that is independent from ICN entities. Due to the clear separation, ICN entities are free from computational overhead to determine the accessibility of NDOs by consumers; also, consumers can secure their privacy through the independent authorization entity [ACCESS-CTL-DEL]. Relevant challenges to this approach include reducing the authorization delay (when communicating to the access control provider) and currency and consistency of access control information (when access control lists are distributed).
1. 分離されたアプローチ：ICNエンティティから独立しているサードパーティからのアクセス制御サービス。明確に分離されているため、ICNエンティティは、消費者によるNDOのアクセス可能性を判断するための計算オーバーヘッドがありません。また、消費者は独立した認証エンティティ[ACCESS-CTL-DEL]を通じてプライバシーを保護できます。このアプローチに関連する課題には、認証の遅延（アクセス制御プロバイダーと通信する場合）とアクセス制御情報の最新性と一貫性（アクセス制御リストが配布される場合）の削減があります。
2. Integrated approach: access control service from ICN entities. This mechanism is often based on content encryption and key distribution [ENCRYPTION-AC]. As mentioned previously, this approach suffers from prohibitive overhead for ICN entities due to the process of key verification. While key distribution is challenging per se, this approach is beneficial in a way that NDOs can be retrieved without the help of an external access control provider. Challenges to this approach include: 1. applying an access control mechanism for dynamic NDOs in in-network caches in a timely manner;
2.統合アプローチ：ICNエンティティからのアクセス制御サービス。このメカニズムは、多くの場合、コンテンツの暗号化とキーの配布に基づいています[ENCRYPTION-AC]。前述のように、このアプローチは、鍵の検証プロセスのために、ICNエンティティの法外なオーバーヘッドの影響を受けます。キーの配布自体は困難ですが、このアプローチは、外部のアクセス制御プロバイダーの助けを借りずにNDOを取得できるという点で有益です。このアプローチの課題は次のとおりです。1.ネットワーク内キャッシュの動的NDOにアクセス制御メカニズムを適時に適用する。
2. providing consumers with the different levels of accessibility to individual NDOs in a scalable manner; and
2. 個々のNDOへのさまざまなレベルのアクセシビリティをスケーラブルな方法で消費者に提供します。そして
3. managing key revocation and similar PKI management functions.
3. キーの取り消しと同様のPKI管理機能を管理します。
In ICN, NDOs can be encrypted to implement access control (only consumers in possession of corresponding decryption keys can access the content) or privacy (same approach). Distributing and managing the corresponding keys as well as providing usable interfaces to applications and human users are challenges and the subject of ongoing work.
ICNでは、NDOを暗号化して、アクセス制御（対応する復号化キーを所有するコンシューマーのみがコンテンツにアクセスできます）またはプライバシー（同じアプローチ）を実装できます。対応するキーの配布と管理、およびアプリケーションと人間のユーザーへの使用可能なインターフェースの提供は、課題であり、進行中の作業の主題です。
In principle, the challenges are similar to those of broadcast/media distribution, and similar approaches (combing symmetric with public key cryptography) are being investigated [NDN-CTL-SHARING].
原則として、課題はブロードキャスト/メディア配信の課題と同様であり、同様のアプローチ（公開鍵暗号と対称的に組み合わせる）が調査されています[NDN-CTL-SHARING]。
One request message to retrieve a data object can actually aggregate requests coming from several consumers. This aggregation of requests reduces the overall traffic but makes per-requestor filtering harder. The challenge in this case is to provide a mechanism that allows request aggregation and per-requestor filtering. A possible solution is to indicate the set of requestors in the aggregated request such that the response can indicate the subset of requestors allowed to access the data object. However, this solution requires collaboration from other nodes in the network and is not suitable for caching. Another possible solution is to encrypt data objects and ensure that only authorized consumers can decrypt them. This solution does not preclude caching and does not require collaboration from the network. However, it implies a mechanism to generate group keys (e.g., different private keys can be used to decrypt the same encrypted data object) [CHAUM].
データオブジェクトを取得する1つの要求メッセージは、実際には複数のコンシューマからの要求を集約できます。この要求の集約により、全体的なトラフィックは減少しますが、要求者ごとのフィルタリングが難しくなります。この場合の課題は、要求の集約と要求者ごとのフィルタリングを可能にするメカニズムを提供することです。可能な解決策は、集約された要求内のリクエスタのセットを示して、応答がデータオブジェクトへのアクセスを許可されたリクエスタのサブセットを示すことができるようにすることです。ただし、このソリューションはネットワーク内の他のノードからのコラボレーションを必要とし、キャッシングには適していません。別の可能な解決策は、データオブジェクトを暗号化し、許可されたコンシューマだけがそれらを解読できるようにすることです。このソリューションはキャッシングを排除せず、ネットワークからのコラボレーションを必要としません。ただし、これはグループキーを生成するメカニズムを意味します（たとえば、異なる暗号化キーを使用して、同じ暗号化されたデータオブジェクトを復号化できます）[CHAUM]。
ICN solutions that implement state on intermediate routers for request routing or forwarding (e.g., Content-Centric Networking (CCN) [CCN]) are subject to denial-of-service attacks from overloading or superseding the internal state of a router (e.g., "interest flooding" [BACKSCATTER]). Additionally, stateful forwarding can enable attack vectors such as resource exhaustion or complexity attacks to the routing infrastructure. The challenge is then to provision routers and construct internal state in a way that alleviates sensibility to such attacks. The problem becomes even harder if the protocol does not provide information about the origin of messages. Without origin, it is a particular challenge to distinguish between regular (intense) use and misuse of the infrastructure.
要求のルーティングまたは転送のために中間ルーターに状態を実装するICNソリューション（例：Content-Centric Networking（CCN）[CCN]）は、ルーターの内部状態（例えば、 "）の過負荷または優先によるサービス拒否攻撃の影響を受けます。インタレストフラッディング」[バックスキャッター]）。さらに、ステートフル転送により、リソース不足やルーティングインフラストラクチャへの複雑な攻撃などの攻撃ベクトルが可能になります。次に、このような攻撃に対する感度を緩和する方法でルーターをプロビジョニングし、内部状態を構築することが課題になります。プロトコルがメッセージの発信元に関する情報を提供しない場合、問題はさらに困難になります。起源がなければ、インフラストラクチャの通常の（激しい）使用と誤用を区別することは特に困難です。
A common capability of ICN solutions is data replication and in-network storage. Delivering replicated data objects from caches decouples content consumption from data sources, which leads to a loss of control on (1) content access and (2) content dissemination. In a widely distributed, decentralized environment like the Internet, this raises several challenges.
ICNソリューションの一般的な機能は、データ複製とネットワーク内ストレージです。複製されたデータオブジェクトをキャッシュから配信すると、コンテンツの消費がデータソースから切り離され、（1）コンテンツへのアクセスと（2）コンテンツの配布の制御が失われます。インターネットのような広く分散した分散環境では、これはいくつかの課題を引き起こします。
One group of challenges is related to content management. Without access control, a content provider loses the means to count and survey content consumption, to limit access scopes, to control or know about the number of copies of its data in the network, or to withdraw earlier publications reliably. Any non-cooperative or desynchronized data cache may hinder an effective content management policy.
課題の1つのグループは、コンテンツ管理に関連しています。アクセス制御がないと、コンテンツプロバイダーは、コンテンツ消費をカウントして調査する、アクセススコープを制限する、ネットワーク内のデータのコピー数を制御または把握する、または以前のパブリケーションを確実に取り消す手段を失います。非協調的または非同期のデータキャッシュは、効果的なコンテンツ管理ポリシーを妨げる可能性があります。
Another group of challenges arises from potential traffic amplifications in the decoupled environment. ICN solutions that attempt to retrieve content from several replicas in parallel, or decorrelated network routing states, but also distributed attackers may simultaneously initiate the transmission of content from multiple replicas towards the same destination (e.g., "initiated overloads" or "blockades" [BACKSCATTER]). Methods for mitigating such threats need rigorous forwarding checks that require alignment with caching procedures (e.g., on-path or off-path).
別の課題グループは、分離された環境での潜在的なトラフィック増幅から生じます。複数のレプリカからコンテンツを並行して取得しようとするICNソリューション、または非相関のネットワークルーティング状態だけでなく、分散攻撃者も、複数のレプリカから同じ宛先に向けてコンテンツの送信を同時に開始する可能性があります（「開始された過負荷」または「遮断」など）[BACKSCATTER ]）。このような脅威を軽減する方法には、キャッシング手順（例：オンパスまたはオフパス）との整合を必要とする厳密な転送チェックが必要です。
Content producers sign their content to ensure the integrity of data and to allow for data object authentication. This is a fundamental requirement in ICN due to distributed caching. Publishers, who massively sign content, which is long-lived, offer time and data to an attacker for comprising cryptographic credentials. Signing a large amount of data eases common attacks that try to breach the key of the publisher. Based on this observation, the following research challenges emerge: o To which extent does the content publication model conflict with the cryptographic limitations?
コンテンツプロデューサーはコンテンツに署名して、データの整合性を確保し、データオブジェクト認証を可能にします。これは、分散キャッシュによるICNの基本的な要件です。長期間有効なコンテンツに大量に署名する発行元は、暗号化された資格情報を構成するための時間とデータを攻撃者に提供します。大量のデータに署名することで、発行者の鍵を破ろうとする一般的な攻撃を緩和します。この観察に基づいて、次の研究課題が浮上します。oコンテンツ公開モデルは、暗号化の制限とどの程度競合しますか？
o How can we achieve transparent re-signing without introducing additional cryptographic weaknesses or key management overhead?
o 暗号化の弱点や鍵管理のオーバーヘッドを追加せずに、透過的な再署名を実現するにはどうすればよいですか？
In general, ICN implementations should be designed considering the guidelines provided by [RFC7696], especially regarding cryptographic algorithm agility, for example, [RFC6920] specifies a naming scheme for hash-based names that was designed to support algorithm agility.
一般に、ICN実装は、特に暗号化アルゴリズムの俊敏性に関して、[RFC7696]によって提供されるガイドラインを考慮して設計する必要があります。たとえば、[RFC6920]は、アルゴリズムの俊敏性をサポートするように設計されたハッシュベースの名前の命名スキームを指定します。
In information-centric networks, one attack vector is to increase the size of routing and forwarding information bases at ICN nodes, i.e., attacking routing scalability in networks that rely on routing by name. This is an intrinsic ICN security issue: possible mitigation approaches include combining routing information authenticity validation with filtering (e.g., maximum de-aggregation level whenever applicable, blacklists, etc.,).
情報中心のネットワークでは、1つの攻撃ベクトルは、ICNノードでのルーティングおよび転送情報ベースのサイズを増やすことです。つまり、名前によるルーティングに依存するネットワークでルーティングのスケーラビリティを攻撃します。これは固有のICNセキュリティ問題です。可能な軽減策には、ルーティング情報の真正性検証とフィルタリング（たとえば、適用可能な場合は常に最大の非集約レベル、ブラックリストなど）を組み合わせることが含まれます。
ICN routing is a process that finds an NDO based on its name initially provided by a requestor. ICN routing may comprise three steps: (1) name resolution, (2) discovery, and (3) delivery. The name resolution step translates the name of the requested NDO into its locator. The discovery step routes the request to the data object based on its name or locator. The last step (delivery) routes the data object back to the requestor. Depending on how these steps are combined, ICN routing schemes can be categorized as Route-By-Name Routing (RBNR), Lookup-By-Name Routing (LBNR), and Hybrid Routing (HR) as discussed in the following subsections.
ICNルーティングは、リクエスタによって最初に提供された名前に基づいてNDOを見つけるプロセスです。 ICNルーティングは、（1）名前解決、（2）発見、（3）配信の3つのステップで構成されます。名前解決ステップは、要求されたNDOの名前をロケーターに変換します。検出ステップでは、名前またはロケーターに基づいて要求をデータオブジェクトにルーティングします。最後のステップ（配信）では、データオブジェクトをリクエスタにルーティングします。これらの手順の組み合わせ方に応じて、ICNルーティングスキームは、次のサブセクションで説明するように、名前によるルーティング（RBNR）、名前によるルーティング（LBNR）、およびハイブリッドルーティング（HR）として分類できます。
RBNR omits the first name resolution step as the name of the NDO is directly used to route the request to the data object. Therefore, routing information for each data object has to be maintained in the routing table. Since the number of data objects is very large (estimated as 10^11 back in 2007 [DONA], but this may be significantly larger than that, e.g., 10^15 to 10^22), the size of routing tables becomes a concern, as it can be proportional to the number of data objects unless an aggregation mechanism is introduced. On the other hand, RBNR reduces overall latency and simplifies the routing process due to the omission of the resolution process. For the delivery step, RBNR needs another identifier (ID) of either host or location to forward the requested data object back to the requestor. Otherwise, an additional routing mechanism has to be introduced, such as breadcrumbs routing [BREADCRUMBS], in which each request leaves behind a trail of breadcrumbs along its forwarding path, and then the response is forwarded back to the requestor consuming the trail.
NDOの名前は要求をデータオブジェクトにルーティングするために直接使用されるため、RBNRは最初の名前解決手順を省略します。したがって、各データオブジェクトのルーティング情報は、ルーティングテーブルで維持する必要があります。データオブジェクトの数が非常に多いため（2007年には[DONA]で10 ^ 11と推定されていますが、これよりもかなり大きくなる可能性があります（例：10 ^ 15から10 ^ 22））、ルーティングテーブルのサイズが問題になります集計メカニズムが導入されていない限り、データオブジェクトの数に比例する可能性があるため。一方、RBNRは、全体的なレイテンシを削減し、解決プロセスの省略によりルーティングプロセスを簡素化します。配信ステップでは、RBNRは、要求されたデータオブジェクトをリクエスタに転送するために、ホストまたは場所の別の識別子（ID）を必要とします。それ以外の場合は、ブレッドクラムルーティング[BREADCRUMBS]などの追加のルーティングメカニズムを導入する必要があります。この場合、各要求は転送パスに沿ってブレッドクラムの痕跡を残し、応答はその痕跡を消費するリクエスタに転送されます。
Challenges specific to RBNR include:
RBNRに固有の課題は次のとおりです。
o How can we aggregate the names of data objects to reduce the number of routing entries?
o ルーティングエントリの数を減らすために、データオブジェクトの名前をどのように集約できますか？
o How does a user learn the name that is designed for aggregation by the provider? For example, although we name our contribution as "ICN research challenges", the IRTF (provider) may want to change the name to "/IETF/IRTF/ICN/Research challenges" for aggregation. In this case, how does a user learn the name "/IETF/IRTF/ICN/ Research challenges" to retrieve the contribution initially named "ICN research challenges" without any resolution process?
o ユーザーは、プロバイダーによる集計用に設計された名前をどのようにして学習しますか？たとえば、寄付を「ICNリサーチチャレンジ」と名付けましたが、IRTF（プロバイダー）は、名前を「/ IETF / IRTF / ICN /リサーチチャレンジ」に変更して集計する場合があります。この場合、ユーザーはどのようにして「/ IETF / IRTF / ICN /リサーチチャレンジ」という名前を学習し、解決プロセスなしで最初に「ICNリサーチチャレンジ」と名付けられた寄稿を取得しますか？
o Without introducing the name aggregation scheme, can we still achieve scalable routing by taking advantage of topological structure and distributed copies? For example, would employing compact routing [COMPACT], random walk [RANDOM], or greedy routing [GREEDY] work at the Internet scale?
o 名前集約方式を導入しなくても、トポロジー構造と分散コピーを利用してスケーラブルなルーティングを実現できますか？たとえば、コンパクトルーティング[COMPACT]、ランダムウォーク[ランダム]、または貪欲ルーティング[GREEDY]を採用すると、インターネット規模で機能しますか？
o How can we incorporate copies of a data object in in-network caches in this routing scheme?
o このルーティング方式のネットワーク内キャッシュにデータオブジェクトのコピーを組み込むにはどうすればよいですか？
o Breadcrumbs routing implies a symmetric path for ICN request and response delivery. Some network configurations and link types prohibit symmetric path forwarding, so it would be challenging to interconnect such networks to an infrastructure based on breadcrumbs routing. For example, certain forwarding strategies in Delay-Tolerant Networking (DTN) [RFC4838] are employing opportunistic forwarding where responses cannot be assumed to travel the same path as requests.
o ブレッドクラムルーティングは、ICN要求および応答配信の対称パスを意味します。一部のネットワーク構成とリンクタイプは対称パス転送を禁止しているため、このようなネットワークをブレッドクラムルーティングに基づくインフラストラクチャに相互接続することは困難です。たとえば、Delay-Tolerant Networking（DTN）[RFC4838]の特定の転送戦略は、応答が要求と同じパスを移動すると想定できない日和見転送を採用しています。
LBNR uses the first name resolution step to translate the name of the requesting data object into its locator. Then, the second discovery step is carried out based on the locator. Since IP addresses could be used as locators, the discovery step can depend on the current IP infrastructure. The delivery step can be implemented similarly to IP routing. The locator of the requestor is included in the request message, and then the requested data object is delivered to the requestor based on the locator. An instantiation of LBNR is [MDHT].
LBNRは、最初の名前解決ステップを使用して、要求しているデータオブジェクトの名前をロケーターに変換します。次に、ロケーターに基づいて2番目のディスカバリー・ステップが実行されます。 IPアドレスはロケーターとして使用できるため、検出手順は現在のIPインフラストラクチャに依存する可能性があります。配信ステップは、IPルーティングと同様に実装できます。リクエスタのロケータはリクエストメッセージに含まれ、リクエストされたデータオブジェクトはロケータに基づいてリクエスタに配信されます。 LBNRのインスタンス化は[MDHT]です。
Challenges specific to LBNR include:
LBNRに固有の課題は次のとおりです。
o How can we build a scalable resolution system that provides:
o 以下を提供するスケーラブルな解決システムをどのように構築できますか？
* Fast lookup: Mapping the name of a data object to its locators (copies as well).
* 高速検索：データオブジェクトの名前をロケーター（コピーも）にマッピングします。
* Fast update: The location of a data object is expected to change frequently. Also, multiple data objects may change their locations at the same time, e.g., data objects in a laptop.
* 高速更新：データオブジェクトの場所は頻繁に変更されることが予想されます。また、ラップトップ内のデータオブジェクトなど、複数のデータオブジェクトが同時に場所を変更する場合もあります。
o How can we incorporate copies of a data object in in-network caches in this routing scheme?
o このルーティング方式のネットワーク内キャッシュにデータオブジェクトのコピーを組み込むにはどうすればよいですか？
HR combines RBNR and LBNR to benefit from their advantages. Within a single administrative domain, e.g., an ISP, where scalability issues can be addressed with network planning, RBNR can be adopted to reduce overall latency by omitting the resolution process. On the other hand, LBNR can be used to route between domains that have their own prefix (locator).
HRは、RBNRとLBNRを組み合わせて、それらの利点を活用します。ネットワーク計画でスケーラビリティの問題に対処できるISPなどの単一の管理ドメイン内では、RBNRを採用することで、解決プロセスを省略して全体のレイテンシを削減できます。一方、LBNRは、独自のプレフィックス（ロケーター）を持つドメイン間のルーティングに使用できます。
For instance, a request message initially includes the name of the NDO for the operation of RBNR and is forwarded to a cached copy of the NDO or the original server. When the request message fails to find a routing entry in the router, a name resolution step kicks in to translate the name into its locator before forwarding the request message based on the retrieved locator.
たとえば、要求メッセージには最初にRBNRの操作用のNDOの名前が含まれ、NDOのキャッシュされたコピーまたは元のサーバーに転送されます。要求メッセージがルーターでルーティングエントリを見つけられなかった場合、名前解決手順が開始され、検索されたロケーターに基づいて要求メッセージを転送する前に、名前がロケーターに変換されます。
Challenges specific to HR are:
人事に固有の課題は次のとおりです。
o How can we design a scalable mapping system that, given the name of the NDO, should return a destination domain locator so that a user request can be encapsulated and forwarded to the domain?
o NDOの名前を指定すると、ユーザー要求をカプセル化してドメインに転送できるように、宛先ドメインロケーターを返すスケーラブルなマッピングシステムをどのように設計できますか？
o How can the mapping information be secured to prevent a malicious router from hijacking the request message by chaining its locator?
o 悪意のあるルーターがロケーターをチェーンしてリクエストメッセージをハイジャックするのを防ぐために、マッピング情報をどのように保護できますか？
o How can the bind between the name and the content of the NDO be maintained for the verification of its origin and integrity when the name changes due to the retrieved locator?
o 検索されたロケーターが原因で名前が変更された場合、その起源と整合性を検証するために、名前とNDOのコンテンツ間のバインドをどのように維持できますか？
Mobility management has been an active field in host-centric communications for more than two decades. In IETF in particular, starting with [RFC2002], a multitude of enhancements to IP have been standardized aiming to "allow transparent routing of IP datagrams to mobile nodes in the Internet" [RFC5944]. In a nutshell, mobility management for IP networks is locator-oriented and relies on the concept of a mobility anchor as a foundation for providing always-on connectivity to mobile nodes (see [MMIN]). Other standards organizations, such as 3GPP, have followed similar anchor-based approaches. Traffic to and from the mobile node must flow through the mobility anchor, typically using a set of tunnels, enabling the mobile node to remain reachable while changing its point of attachment to the network.
モビリティ管理は、20年以上にわたってホスト中心の通信におけるアクティブな分野です。特にIETFでは、[RFC2002]以降、「インターネットのモバイルノードへのIPデータグラムの透過的なルーティングを許可する」[RFC5944]を目的として、IPに対する多数の拡張機能が標準化されています。簡単に言うと、IPネットワークのモビリティ管理はロケーター指向であり、モバイルノードへの常時接続を提供するための基盤としてのモビリティアンカーの概念に依存しています（[MMIN]を参照）。 3GPPなどの他の標準化団体は、同様のアンカーベースのアプローチに従っています。モバイルノードとの間のトラフィックは、通常は一連のトンネルを使用してモビリティアンカーを通過する必要があります。これにより、モバイルノードは、ネットワークへの接続ポイントを変更している間も到達可能な状態を維持できます。
Needless to say, an IP network that supports node mobility is more complex than one that does not, as specialized network entities must be introduced in the network architecture. This is reflected in the control plane as well, which carries mobility-related signaling messages, establishes and tears down tunnels, and so on. While mobile connectivity was an afterthought in IP, in ICN, this is considered a primary deployment environment. Most, if not all, ICN proposals consider mobility from the very beginning, although at varying levels of architectural and protocol detail. That said, no solution has so far come forward with a definite answer on how to handle mobility in ICN using native primitives. In fact, we observe that mobility appears to be addressed on an ICN proposal-specific basis. That is, there is no single paradigm solution, akin to tunneling through a mobility anchor in host-centric networking, that can be applied across different ICN proposals. For instance, although widely deployed mobile network architectures typically come with their own network entities and associated protocols, they follow the same line of design with respect to managing mobility. This design thinking, which calls for incorporating mobility anchors, permeates in the ICN literature too.
言うまでもなく、ノードモビリティをサポートするIPネットワークは、サポートしないネットワークよりも複雑です。これは、特殊なネットワークエンティティをネットワークアーキテクチャに導入する必要があるためです。これは、モビリティ関連のシグナリングメッセージを伝送したり、トンネルを確立および切断したりするなど、コントロールプレーンにも反映されます。モバイル接続はIPで後付けでしたが、ICNでは、これは主要な展開環境と見なされます。すべてではないにしても、ほとんどのICN提案では、アーキテクチャとプロトコルの詳細レベルはさまざまですが、最初からモビリティを考慮しています。とはいえ、これまでのところ、ネイティブプリミティブを使用してICNでモビリティを処理する方法について明確な答えを出した解決策はありません。実際、モビリティはICN提案固有の基準で対処されているように見えます。つまり、ホスト中心のネットワーキングでのモビリティアンカーを介したトンネリングのような、異なるICN提案全体に適用できる単一のパラダイムソリューションはありません。たとえば、広く展開されているモバイルネットワークアーキテクチャには通常、独自のネットワークエンティティと関連するプロトコルが付属していますが、モビリティの管理に関しては同じ設計ラインに従います。モビリティアンカーの組み込みを必要とするこのデザイン思考は、ICNの文献にも浸透しています。
However, employing mobility anchors and tunneling is probably not the best way forward in ICN research for mobile networking. Fundamentally, this approach is anything but information-centric and location-independent. In addition, as argued in [SEEN], current mobility management schemes anchor information retrieval not only at a specific network gateway (e.g., home agent in Mobile IP) but also at a specific correspondent node due to the end-to-end nature of host-centric communication. However, once a change in the point of attachment occurs, information retrieval from the original "correspondent node" may no longer be optimal. This was shown in [MANI], for example, where a simple mechanism that triggers the
ただし、モバイルネットワーキングのICN研究では、モビリティアンカーとトンネリングを採用することはおそらく最善の方法ではありません。基本的に、このアプローチは情報中心で場所に依存しないものです。さらに、[SEEN]で議論されているように、現在のモビリティ管理スキームは、特定のネットワークゲートウェイ（モバイルIPのホームエージェントなど）だけでなく、エンドツーエンドの性質により特定のコレスポンデントノードでも情報検索をアンカーします。ホスト中心のコミュニケーション。ただし、アタッチポイントの変更が発生すると、元の「コレスポンデントノード」からの情報検索は最適ではなくなる可能性があります。これは[MANI]で示されていました。たとえば、
discovery of new retrieval providers for the same data object, following a change in the point of attachment, clearly outperforms a tunnel-based approach like Mobile IP in terms of object download times. The challenge here is how to capitalize on location information while facilitating the use of ICN primitives, which natively support multicast and anycast.
アタッチメントポイントの変更後の同じデータオブジェクトの新しい取得プロバイダーの発見は、オブジェクトのダウンロード時間に関して、モバイルIPのようなトンネルベースのアプローチよりも明らかに優れています。ここでの課題は、マルチキャストとエニーキャストをネイティブにサポートするICNプリミティブの使用を促進しながら、位置情報を活用する方法です。
ICN naming and name resolution, as well as the security features that come along, should natively support mobility. For example, CCN [CCN] does not have the restriction of spanning tree routing, so it is able to take advantage of multiple interfaces or adapt to the changes produced by rapid mobility (i.e., there is no need to bind a layer 3 address with a layer 2 address). In fact, client mobility can be simplified by allowing requests for new content to normally flow from different interfaces or through newly connected points of attachment to the network. However, when the node moving is the (only) content source, it appears that more complex network support might be necessary, including forwarding updates and cache rebuilding. A case in point is a conversation network service, such as a voice or video call between two parties. The requirements in this case are more stringent when support for seamless mobility is required, especially when compared to content dissemination that is amenable to buffering. Another parameter that needs to be paid attention to is the impact of using different wireless access interfaces based on different technologies, where the performance and link conditions can vary widely depending of numerous factors.
ICNの命名と名前解決、およびそれに伴うセキュリティ機能は、モビリティをネイティブでサポートする必要があります。たとえば、CCN [CCN]にはスパニングツリールーティングの制限がないため、複数のインターフェイスを利用したり、高速モビリティによって生成された変更に適応したりできます（つまり、レイヤー3アドレスをバインドする必要はありません）レイヤ2アドレス）。実際、クライアントのモビリティは、通常、新しいコンテンツのリクエストが異なるインターフェイスから、またはネットワークに新しく接続された接続ポイントを介して流れるようにすることで簡略化できます。ただし、移動するノードが（唯一の）コンテンツソースである場合、更新の転送やキャッシュの再構築など、より複雑なネットワークサポートが必要になる可能性があります。代表的な例は、2者間の音声通話やビデオ通話などの会話ネットワークサービスです。この場合の要件は、シームレスなモビリティのサポートが必要な場合、特にバッファリングが可能なコンテンツの配布と比較すると、より厳格です。注意が必要なもう1つのパラメータは、さまざまなテクノロジに基づくさまざまなワイヤレスアクセスインターフェイスを使用した場合の影響です。この場合、パフォーマンスとリンクの状態は、さまざまな要因によって大きく異なります。
In host-centric networking, mobility management mechanisms ensure optimal handovers and (ideally) seamless transition from one point of attachment to another. In ICN, however, the traditional meaning of "point of attachment" no longer applies as communication is not restrained by location-based access to data objects. Therefore, a "seamless transition" in ICN ensures that content reception continues without any perceptible change from the point of view of the ICN application receiving that content. Moreover, this transition needs to be executed in parallel with ICN content identification and delivery mechanisms, enabling scenarios such as preparation of the content delivery process at the target connectivity point prior to the handover (to reduce link switch disturbances). Finally, these mobility aspects can also be tightly coupled with network management aspects, in respect to policy enforcement, link control, and other parameters necessary for establishing the node's link to the network.
ホスト中心のネットワーキングでは、モビリティ管理メカニズムにより、最適なハンドオーバーと、（理想的には）ある接続点から別の接続点へのシームレスな移行が保証されます。ただし、ICNでは、データオブジェクトへの場所ベースのアクセスによって通信が制限されないため、「アタッチメントポイント」の従来の意味は適用されなくなりました。したがって、ICNの「シームレスな移行」により、ICNアプリケーションがそのコンテンツを受信するという観点からは、目に見える変化なしにコンテンツの受信が続行されます。さらに、この移行はICNコンテンツの識別および配信メカニズムと並行して実行する必要があるため、（リンクスイッチの妨害を減らすために）ハンドオーバー前のターゲット接続ポイントでのコンテンツ配信プロセスの準備などのシナリオが可能になります。最後に、これらのモビリティの側面は、ポリシーの施行、リンク制御、およびネットワークへのノードのリンクを確立するために必要なその他のパラメータに関して、ネットワーク管理の側面と密接に結合することもできます。
In summary, the following research challenges for ICN mobility management can be derived:
要約すると、ICNモビリティ管理に関する次の研究課題を導き出すことができます。
o How can mobility management take full advantage of native ICN primitives?
o モビリティ管理はどのようにしてネイティブICNプリミティブを最大限に活用できますか？
o How do we avoid the need for mobility anchors in a network that by design supports multicast, anycast, and location-independent information retrieval?
o 設計上、マルチキャスト、エニーキャスト、および場所に依存しない情報検索をサポートするネットワークで、モビリティアンカーの必要性をどのように回避しますか？
o How can content retrieval mechanisms interface with specific link operations, such as identifying which links are available for certain content?
o コンテンツ取得メカニズムは、特定のコンテンツで使用可能なリンクの識別など、特定のリンク操作とどのように連携できますか？
o How can mobility be offered as a service that is only activated when the specific user/content/conditions require it?
o 特定のユーザー/コンテンツ/条件で必要な場合にのみアクティブ化されるサービスとしてモビリティを提供するにはどうすればよいですか？
o How can mobility management be coordinated between the node and the network for optimization and policing procedures?
o 最適化とポリシングの手順のために、ノードとネットワーク間でモビリティ管理をどのように調整できますか？
o How do we ensure that managing mobility does not introduce scalability issues in ICN?
o モビリティの管理によってICNにスケーラビリティの問題が発生しないようにするにはどうすればよいですか？
o How will the name resolution process be affected by rapid topological changes when the content source itself is mobile?
o コンテンツソース自体がモバイルである場合、名前解決プロセスはトポロジーの急激な変化によってどのように影響を受けますか？
Today, all layer 2 (L2) wireless network radio access technologies are developed with a clear assumption in mind: the waist of the protocol stack is IP, and it will be so for the foreseeable future. By fixing the protocol stack waist, engineers can answer a large set of questions, including how to handle conversational traffic (e.g., voice calls) vs. web traffic, how to support multicast, and so on, in a rather straightforward manner. Broadcast, on the other hand, which is inherent in wireless communication, is not fully taken advantage of. On the contrary, researchers are often more concerned about introducing mechanisms that ensure that "broadcast storms" do not take down a network. The question of how can broadcast better serve ICN needs has yet to be thoroughly investigated.
今日、すべてのレイヤー2（L2）無線ネットワーク無線アクセス技術は、明確な仮定を考慮して開発されています。プロトコルスタックのウエストはIPであり、近い将来にはそうなるでしょう。プロトコルスタックのウエストを修正することで、エンジニアは会話型トラフィック（音声通話など）とWebトラフィックの処理方法、マルチキャストのサポート方法など、さまざまな質問にかなり簡単に答えることができます。一方、無線通信に固有のブロードキャストは、十分に活用されていません。それどころか、「ブロードキャストストーム」がネットワークを停止させないようにするメカニズムを導入することについて、研究者はより懸念することがよくあります。どのようにしてICNのニーズにより適切に放送を配信できるかという問題は、徹底的に調査されていません。
Wireless networking is often intertwined with mobility, but this is not always the case. In fact, empirical measurements often indicate that many users tend to connect (and remain connected) to a single Wi-Fi access point for considerable amounts of time. A case in point, which is frequently cited in different variations in the ICN literature, is access to a document repository during a meeting. For instance, in a typical IETF working group meeting, a scribe takes notes, which are uploaded to a centralized repository (see Figure 1). Subsequently, each meeting participant obtains a copy of the document on their own devices for local use, annotation, and sharing with colleagues that are not present at the meeting. Note that in this example, there is no node mobility and that it is not important whether the document with the notes is uploaded in one go at the end of the session or in a streaming-like fashion as is typical today with online (cloud-based) document processing.
ワイヤレスネットワーキングはしばしばモビリティと絡み合っていますが、常にそうであるとは限りません。実際、多くのユーザーがかなりの時間、単一のWi-Fiアクセスポイントに接続する（そして接続したままにする）傾向があることを経験的測定はしばしば示しています。 ICN文献のさまざまなバリエーションで頻繁に引用される代表的な例は、会議中のドキュメントリポジトリへのアクセスです。たとえば、典型的なIETFワーキンググループミーティングでは、筆記者がメモを取り、中央リポジトリにアップロードされます（図1を参照）。その後、会議の各参加者は、ローカルでの使用、注釈、および会議に参加していない同僚との共有のために、自分のデバイスでドキュメントのコピーを取得します。この例では、ノードの移動性はなく、ノートのあるドキュメントがセッションの最後に一度にアップロードされるのか、今日オンライン（クラウド-ベース）ドキュメント処理。
+---------------------+
| Document Repository |
+---------------------+
||
(Internet)
||
+--------------+
| Access Point |
+--------------+
/ | \
/ | \
/ | \
Scribe Participant 1 ... Participant N
Figure 1: Document Sharing During a Meeting
図1：会議中のドキュメント共有
In this scenario, we observe that the same data object bits (corresponding to the meeting notes) need to traverse the wireless medium at least N+1 times, where N is the number of meeting participants obtaining a copy of the notes. In effect, a broadcast medium is shoehorned into N+1 virtual unicast channels. One could argue that wireless local connectivity is inexpensive, but this is not the critical factor in this example. The actual information exchange wastes N times the available network capacity, no matter what the spectral efficiency (or the economics) underlying the wireless technology is. This waste is a direct result of extending the remote access paradigm from wired to wireless communication, irrespective of the special characteristics of the latter.
このシナリオでは、同じデータオブジェクトビット（会議メモに対応）がワイヤレスメディアを少なくともN + 1回トラバースする必要があることがわかります。Nは、メモのコピーを取得する会議参加者の数です。実際には、ブロードキャストメディアはN + 1の仮想ユニキャストチャネルにシューホーンされます。ワイヤレスローカル接続は安価であると主張することもできますが、これはこの例では重要な要素ではありません。実際の情報交換は、ワイヤレス技術の基礎となるスペクトル効率（または経済性）に関係なく、利用可能なネットワーク容量のN倍を浪費します。この無駄は、リモートアクセスのパラダイムを有線から無線に拡張したことによる直接的な結果であり、後者の特別な特性に関係ありません。
It goes without saying that an ICN approach that does not take into consideration the wireless nature of an interface will waste the same amount of resources as a host-centric paradigm. In-network caching at the wireless access point could reduce the amount of data carried over the backhaul link, but, if there is no change in the use of the wireless medium, the NDO will still be carried over the wireless ether N+1 times. Intelligent caching strategies, replica placement cooperation, and so on simply cannot alleviate this. On the other hand, promiscuous interface operation and opportunistic caching would maximize wireless network capacity utilization in this example.
言うまでもなく、インターフェイスのワイヤレスの性質を考慮しないICNアプローチは、ホスト中心のパラダイムと同じ量のリソースを浪費します。ワイヤレスアクセスポイントでのネットワーク内キャッシュにより、バックホールリンクを介して伝送されるデータの量を減らすことができますが、ワイヤレスメディアの使用に変更がない場合、NDOはワイヤレスエーテルを介してN + 1回伝送されます。 。インテリジェントキャッシング戦略、レプリカ配置の連携などでは、これを軽減することはできません。一方、この例では、無差別なインターフェイス操作と便宜的キャッシングにより、ワイヤレスネットワークのキャパシティ使用率が最大になります。
Arguably, if one designs a future wireless access technology with an information-centric "layer 3" in mind, many of the design choices that are obvious in an all-IP architecture may no longer be valid.
おそらく、情報中心の「レイヤー3」を念頭に置いて将来のワイヤレスアクセステクノロジーを設計すると、オールIPアーキテクチャーで明らかな設計の選択肢の多くが無効になる可能性があります。
Although this is clearly outside the scope of this document, a few research challenges that the wider community may be interested in include:
これは明らかにこのドキュメントの範囲外ですが、より広いコミュニティが関心を持つ可能性があるいくつかの研究課題は次のとおりです。
o Can we use wireless resources more frugally with the information-centric paradigm than what is possible today in all-IP wireless networks?
o 情報中心のパラダイムを使用して、すべてのIPワイヤレスネットワークで現在可能なものよりも効率的にワイヤレスリソースを使用できますか？
o In the context of wireless access, how can we leverage the broadcast nature of the medium in an information-centric network?
o ワイヤレスアクセスのコンテキストでは、情報中心のネットワークでメディアのブロードキャストの性質をどのように活用できますか？
o Would a wireless-oriented ICN protocol stack deliver significant performance gains? How different would it be from a wired-oriented ICN protocol stack?
o ワイヤレス指向のICNプロトコルスタックは、パフォーマンスを大幅に向上させますか？有線指向のICNプロトコルスタックとはどのように異なりますか？
o Is it possible that by changing the network paradigm to ICN we can, in practice, increase the spectral efficiency (bits/s/Hz) of a wireless network beyond what would be possible with today's host-centric approaches? What would be the impact of doing so with respect to energy consumption?
o ネットワークパラダイムをICNに変更することで、実際に、ワイヤレスネットワークのスペクトル効率（ビット/秒/ Hz）を、今日のホスト中心のアプローチで可能なものを超えて増やすことができるでしょうか。エネルギー消費に関してそうすることの影響は何でしょうか？
o Can promiscuous wireless interface operation coupled with opportunistic caching increase ICN performance, and if so, by how much?
o 無差別ワイヤレスインターフェイスの操作と便宜的キャッシングを組み合わせることで、ICNパフォーマンスを向上させることができますか。
o How can a conversational service be supported at least as efficiently as today's state-of-the-art wireless networks deliver?
o 現在の最先端のワイヤレスネットワークが提供するのと同じくらい効率的に会話型サービスをどのようにサポートできますか？
o What are the benefits of combining ICN with network coding in wireless networks?
o ワイヤレスネットワークでICNとネットワークコーディングを組み合わせる利点は何ですか？
o How can Multiple-Input Multiple-Output (MIMO) and Coordinated Multipoint Transmission (CoMP) be natively combined with ICN primitives in future cellular networks?
o 多入力多出力（MIMO）と協調マルチポイント伝送（CoMP）を、将来のセルラーネットワークでICNプリミティブとネイティブに組み合わせるにはどうすればよいですか？
ICN's receiver-driven communication model as described above creates new opportunities for transport protocol design, as it does not rely solely on end-to-end communication from a sender to a requestor. A requested data object can be accessible in multiple different network locations. A node can thus decide how to utilize multiple sources, e.g., by sending parallel requests for the same NDO or by switching sources (or next hops) in a suitable schedule for a series of requests.
上記のICNの受信側駆動型通信モデルは、送信側から要求側へのエンドツーエンド通信だけに依存しないため、トランスポートプロトコル設計の新しい機会を生み出します。要求されたデータオブジェクトは、複数の異なるネットワークロケーションでアクセスできます。したがって、ノードは、たとえば、同じNDOに対する並列要求を送信することによって、または一連の要求に適したスケジュールでソース（またはネクストホップ）を切り替えることによって、複数のソースを利用する方法を決定できます。
In this model, the requestor would control the data rate by regulating its request sending rate and next by performing source/ next-hop selections. Specific challenges depend on the specific ICN approach, but general challenges for receiver-driven transport protocols (or mechanisms, since dedicated protocols might not be required) include flow and congestion control, fairness, network utilization, stability (of data rates under stable conditions), etc. [HRICP] and [CONTUG] describe request rate control protocols and corresponding design challenges.
このモデルでは、リクエスタは要求の送信レートを調整することでデータレートを制御し、次にソース/ネクストホップの選択を実行してデータレートを制御します。特定の課題は特定のICNアプローチに依存しますが、レシーバー主導のトランスポートプロトコル（または専用プロトコルが不要な場合があるためメカニズム）の一般的な課題には、フローおよび輻輳制御、公平性、ネットワーク使用率、安定性（安定した条件下でのデータレート）が含まれますなど。[HRICP]と[CONTUG]では、要求レート制御プロトコルと対応する設計の課題について説明しています。
As mentioned above, the ICN communication paradigm does not depend strictly on end-to-end flows, as contents might be received from in-network caches. The traditional concept of a flow is then somewhat not valid as sub-flows, or flowlets, might be formed on the fly, when fractions of an NDO are transmitted from in-network caches. For a transport-layer protocol, this is challenging, as any measurement related to this flow as traditionally done by transport protocols such as TCP, can often prove misleading. For example, false Round-Trip Time (RTT) measurements will lead to largely variable average and smoothed RTT values, which in turn will trigger false timeout expirations.
上記のように、コンテンツはネットワーク内のキャッシュから受信される可能性があるため、ICN通信パラダイムはエンドツーエンドのフローに厳密には依存していません。 NDOの一部がネットワーク内のキャッシュから送信されると、サブフローまたはフローレットがオンザフライで形成される可能性があるため、フローの従来の概念は幾分有効ではありません。トランスポート層プロトコルの場合、これは困難です。これは、TCPなどのトランスポートプロトコルによって従来行われていたこのフローに関連する測定は、誤解を招くことが多いためです。たとえば、誤ったラウンドトリップ時間（RTT）の測定は、主に変動する平均値と平滑化されたRTT値につながり、次に誤ったタイムアウトの期限切れをトリガーします。
Furthermore, out-of-order delivery is expected to be common in a scenario where parts of a data object are retrieved from in-network caches rather than from the origin server. Several techniques for dealing with out-of-order delivery have been proposed in the past for TCP, some of which could potentially be modified and reused in the context of ICN. Further research is needed in this direction though to choose the right technique and adjust it according to the requirements of the ICN architecture and transport protocol in use.
さらに、データオブジェクトの一部が元のサーバーからではなくネットワーク内のキャッシュから取得されるシナリオでは、順序どおりの配信が一般的であると予想されます。順序不同の配信を処理するためのいくつかの手法がTCPに対して過去に提案されており、そのうちのいくつかはICNのコンテキストで変更および再利用される可能性があります。 ICNアーキテクチャと使用中のトランスポートプロトコルの要件に従って適切な手法を選択し、調整するために、この方向でさらに調査が必要です。
ICN offers routers the possibility to aggregate requests and can use several paths, meaning that there is no such thing as a (dedicated) end-to-end communication path, e.g., a router that receives two requests for the same content at the same time only sends one request to its neighbor. The aggregation of requests has a general impact on transport protocol design and offers new options for employing per-node forwarding strategies and for rethinking in-network resource sharing [RESOURCE-POOL].
ICNはルーターに要求を集約する可能性を提供し、複数のパスを使用できます。つまり、（専用の）エンドツーエンド通信パスなどはありません。たとえば、同じコンテンツに対する2つの要求を同時に受信するルーター1つの要求のみをそのネイバーに送信します。リクエストの集約は、トランスポートプロトコルの設計に一般的な影響を与え、ノードごとの転送戦略を採用したり、ネットワーク内リソース共有を再考したりするための新しいオプションを提供します[RESOURCE-POOL]。
Achieving fairness for requestors can be one challenge as it is not possible to identify the number of requestors behind one particular request. A second problem related to request aggregation is the management of request retransmissions. Generally, it is assumed that a router will not transmit a request if it transmitted an identical request recently, and because there is no information about the requestor, the router cannot distinguish the initial request from a client from a retransmission from the same client. In such a situation, routers can adapt their timers to use the best of the communication paths.
1つの特定のリクエストの背後にあるリクエスタの数を特定することができないため、リクエスタの公平性を達成することは1つの課題となります。リクエストの集約に関連する2番目の問題は、リクエストの再送信の管理です。一般に、最近同一のリクエストを送信した場合、ルータはリクエストを送信しないと想定されます。また、リクエスタに関する情報がないため、ルータはクライアントからの最初のリクエストと同じクライアントからの再送信を区別できません。このような状況では、ルーターはタイマーを調整して、最適な通信パスを使用できます。
Explicitly named data objects allow for caching at virtually any network element, including routers, proxy caches, and end-user devices. Therefore, in-network caching can improve network performance by fetching content from nodes that are geographically placed closer to the end user. Several issues that need further investigation have been identified with respect to in-network caching. In this section, we list important challenges that relate to the properties of the new ubiquitous caching system.
明示的に名前が付けられたデータオブジェクトを使用すると、ルーター、プロキシキャッシュ、エンドユーザーデバイスなど、実質的にすべてのネットワーク要素でのキャッシュが可能になります。したがって、ネットワーク内キャッシュは、地理的にエンドユーザーの近くに配置されているノードからコンテンツをフェッチすることにより、ネットワークパフォーマンスを向上させることができます。ネットワーク内キャッシングに関して、さらに調査が必要ないくつかの問題が確認されています。このセクションでは、新しいユビキタスキャッシングシステムの特性に関連する重要な課題を示します。
The declining cost of fast memory gives the opportunity to deploy caches in network routers and to take advantage of cached NDOs. We identify two approaches to in-network caching, namely, on-path and off-path caching. Both approaches have to consider the issue of cache location. Off-path caching is similar to traditional proxy-caching or CDN server placement. Retrieval of contents from off-path caches requires redirection of requests and, therefore, is closely related to the Request-to-Cache Routing problem discussed below. Off-path caches have to be placed in strategic points within a network in order to reduce the redirection delays and the number of detour hops to retrieve cached contents. Previous research on proxy-caching and CDN deployment is helpful in this case.
高速メモリのコストの低下により、ネットワークルーターにキャッシュを展開し、キャッシュされたNDOを利用する機会が与えられます。ネットワーク内キャッシュへの2つのアプローチ、つまり、オンパスキャッシングとオフパスキャッシングを特定します。どちらのアプローチでも、キャッシュの場所の問題を考慮する必要があります。オフパスキャッシングは、従来のプロキシキャッシングまたはCDNサーバー配置に似ています。オフパスキャッシュからコンテンツを取得するには、要求をリダイレクトする必要があるため、以下で説明する要求からキャッシュへのルーティングの問題と密接に関連しています。キャッシュされたコンテンツを取得するためのリダイレクト遅延と迂回ホップの数を減らすために、オフパスキャッシュをネットワーク内の戦略的なポイントに配置する必要があります。この場合、プロキシキャッシングとCDN展開に関する以前の調査が役立ちます。
On the other hand, on-path caching requires less network intervention and fits more neatly in ICN. However, on-path caching requires line-speed operation, which places more constraints on the design and operation of in-network caching elements. Furthermore, the gain of such a system of on-path in-network caches relies on opportunistic cache hits and has therefore been considered of limited benefit, given the huge amount of contents hosted in the Internet. For this reason, network operators might initially consider only a limited number of network elements to be upgraded to in-network caching elements. The decision on which nodes should be equipped with caches is an open issue and might be based, among others, on topological criteria or traffic characteristics. These challenges relate to both the Content Placement problem and the Request-to-Cache Routing problem discussed below.
一方、パス上のキャッシングは、ネットワークの介入が少なくて済み、ICNにうまく適合します。ただし、オンパスキャッシングには回線速度の動作が必要です。これにより、ネットワーク内キャッシング要素の設計と動作により多くの制約が課されます。さらに、このようなパス上のネットワーク内キャッシュのシステムの利点は、日和見的なキャッシュヒットに依存しているため、インターネットでホストされている膨大な量のコンテンツを考えると、メリットは限られていると考えられています。このため、ネットワークオペレーターは、限られた数のネットワーク要素のみをネットワーク内キャッシュ要素にアップグレードすることを最初に検討する場合があります。キャッシュを装備する必要があるノードの決定は未解決の問題であり、特にトポロジ基準またはトラフィック特性に基づく場合があります。これらの課題は、コンテンツの配置の問題と、以下で説明するリクエストからキャッシュへのルーティングの問題の両方に関連しています。
In most cases, however, the driver for the implementation, deployment, and operation of in-network caches will be its cost. Operating caches at line speed inevitably requires faster memory, which increases the implementation cost. Based on the capital to be invested, ISPs will need to make strategic decisions on the cache placement, which can be driven by several factors, such as avoidance of inter-domain/expensive links, centrality of nodes, size of domain and the corresponding spatial locality of users, and traffic patterns in a specific part of the network (e.g., university vs. business vs. fashion district of a city).
ただし、ほとんどの場合、ネットワーク内キャッシュの実装、展開、および運用の推進力がそのコストになります。ライン速度でキャッシュを操作するには、必然的に高速のメモリが必要になり、実装コストが増加します。投資する資本に基づいて、ISPはキャッシュ配置に関する戦略的決定を行う必要があります。これは、ドメイン間/高価なリンクの回避、ノードの中心性、ドメインのサイズ、および対応する空間のようないくつかの要因によって推進できます。ユーザーの地域性、およびネットワークの特定の部分のトラフィックパターン（大学の都市、ビジネス、都市のファッション地区など）。
Given a number of on-path or off-path in-network caching elements, content-to-cache distribution will affect both the dynamics of the system, in terms of request redirections (mainly in case of off-path caches) and the gain of the system in terms of cache hits. A straightforward approach to content placement is on-path placement of contents as they travel from source to destination. This approach reduces the computation and communication overhead of placing content within the network but, on the other hand, might reduce the chances of hitting cached contents. This relates to the Request-to-Cache Routing problem discussed next.
オンパスまたはオフパスのネットワーク内キャッシング要素が多数ある場合、コンテンツからキャッシュへの配信は、要求のリダイレクト（主にオフパスキャッシュの場合）とシステムのゲインの両方に関して、システムのダイナミクスに影響します。キャッシュヒットの観点からシステムの。コンテンツの配置への直接的なアプローチは、コンテンツがソースから宛先に移動する際のコンテンツのパス上の配置です。このアプローチは、ネットワーク内にコンテンツを配置する計算と通信のオーバーヘッドを削減しますが、一方で、キャッシュされたコンテンツにヒットする可能性を削減する可能性があります。これは、次に説明するリクエストからキャッシュへのルーティングの問題に関連しています。
Furthermore, the number of replicas held in the system brings up resource management issues in terms of cache allocation. For example, continuously replicating data objects in all network elements results in redundant copies of the same objects. The issue of redundant replication has been investigated in the past for hierarchical web caches. However, in hierarchical web-caching, overlay systems coordination between the data and the control plane can guarantee increased performance in terms of cache hits. Line-speed, on-path, in-network caching poses different requirements; therefore, new techniques need to be investigated. In this direction, reducing the redundancy of cached copies is a study item. However, the issue of coordinated content placement in on-path caches remains open.
さらに、システムに保持されているレプリカの数により、キャッシュの割り当てに関するリソース管理の問題が発生します。たとえば、すべてのネットワーク要素でデータオブジェクトを継続的に複製すると、同じオブジェクトのコピーが冗長になります。冗長な複製の問題は、階層型Webキャッシュについて過去に調査されています。ただし、階層型Webキャッシングでは、データとコントロールプレーン間のオーバーレイシステムの調整により、キャッシュヒットに関してパフォーマンスの向上を保証できます。回線速度、パス上、ネットワーク内キャッシングにはさまざまな要件があります。したがって、新しい技術を調査する必要があります。この方向では、キャッシュされたコピーの冗長性を削減することが検討項目です。ただし、パス上のキャッシュ内のコンテンツの配置の調整に関する問題は未解決のままです。
The Content-to-Cache Allocation problem relates also to the characteristics of the content to be cached. Popular content might need to be placed where it is going to be requested next. Furthermore, issues of "expected content popularity" or temporal locality need to be taken into account in designing in-network caching algorithms in order for some contents to be given priority (e.g., popular content vs. one-timers). The criteria as to which contents should be given priority in in-network content caches relates also to the business relationships between content providers and network operators. Business model issues will drive some of these decisions on content-to-cache distribution, but such issues are outside the scope of this note and are not discussed here further.
コンテンツとキャッシュの割り当ての問題は、キャッシュされるコンテンツの特性にも関係しています。人気のあるコンテンツは、次にリクエストされる場所に配置する必要がある場合があります。さらに、一部のコンテンツを優先するために、ネットワーク内キャッシュアルゴリズムを設計する際には、「期待されるコンテンツの人気」または一時的な局所性の問題を考慮する必要があります（人気のあるコンテンツとワンタイムのコンテンツなど）。ネットワーク内のコンテンツキャッシュでどのコンテンツを優先するかに関する基準は、コンテンツプロバイダーとネットワークオペレーター間のビジネス関係にも関係します。ビジネスモデルの問題は、コンテンツからキャッシュへの配布に関するこれらの決定の一部を推進しますが、そのような問題はこの注記の範囲外であり、ここではこれ以上説明しません。
In order to take advantage of cached contents, requests have to be forwarded to the nodes that cache the corresponding contents. This challenge relates to name-based routing, discussed earlier. Requests should ideally follow the path to the cached NDO. However, instructions as to which content is cached where cannot be broadcast throughout the network. Therefore, the knowledge of an NDO location at the time of the request either might not exist or might not be accurate (i.e., contents might have been removed by the time a request is redirected to a specific node).
キャッシュされたコンテンツを利用するには、対応するコンテンツをキャッシュするノードにリクエストを転送する必要があります。この課題は、前述の名前ベースのルーティングに関連しています。リクエストは、キャッシュされたNDOへのパスに従うのが理想的です。ただし、キャッシュされるコンテンツに関する指示は、ネットワーク全体にブロードキャストできません。したがって、要求時のNDOの場所の情報は存在しないか、正確でない可能性があります（つまり、要求が特定のノードにリダイレクトされるまでにコンテンツが削除された可能性があります）。
Coordination between the data and the control planes to update information of cached contents has been considered, but in this case, scalability issues arise. We therefore have two options. We either have to rely on opportunistic caching, where requests are forwarded to a server and in case the NDO is found on the path, then the content is fetched from this node instead of the origin server, or we employ cache-aware routing techniques. Cache-aware routing can involve either both the control and the data plane or only one of them. Furthermore, cache-aware routing can be done in a domain-wide scale or can involve more than one individual Autonomous System (AS). In the latter case, business relationships between ASes might need to be exploited in order to build a scalable model.
キャッシュされたコンテンツの情報を更新するためのデータとコントロールプレーン間の調整が検討されていますが、この場合、スケーラビリティの問題が発生します。したがって、2つのオプションがあります。リクエストがサーバーに転送され、パス上でNDOが見つかった場合、コンテンツがオリジンサーバーではなくこのノードからフェッチされる、日和見キャッシングに依存する必要があるか、キャッシュ対応ルーティング技術を採用します。キャッシュ対応ルーティングには、コントロールプレーンとデータプレーンの両方を含めることも、1つだけを含めることもできます。さらに、キャッシュ対応ルーティングは、ドメイン全体の規模で行うことも、複数の独立した自律システム（AS）を含めることもできます。後者の場合、スケーラブルなモデルを構築するために、AS間のビジネス関係を活用する必要がある場合があります。
Due to the largely distributed copies of NDOs in in-network caches, ICN should be able to provide a staleness verification algorithm that provides synchronization of NDOs located at their providers and in-network caching points. Two types of approaches can be considered for this problem, namely direct and indirect approaches.
ネットワーク内キャッシュにNDOのコピーが広く分散しているため、ICNは、プロバイダーとネットワーク内キャッシュポイントにあるNDOの同期を提供する古さ検証アルゴリズムを提供できるはずです。この問題には、2つのタイプのアプローチ、つまり直接アプローチと間接アプローチが考えられます。
In the direct approach, each cache looks up certain information in the NDO's name, e.g., the timestamp, that directly indicates its staleness. This approach is applicable to some NDOs that come from machine-to-machine and Internet of Things scenarios, whose base operation relies on obtaining the latest version of that NDO (i.e., a soil sensor in a farm providing different continuous parameters that are sent to a display or greenhouse regulation system) [FRESHNESS].
直接的なアプローチでは、各キャッシュはNDOの名前から特定の情報（タイムスタンプなど）を検索し、その古さを直接示します。このアプローチは、マシンツーマシンとモノのインターネットのシナリオに由来する一部のNDOに適用できます。その基本操作は、そのNDOの最新バージョンの取得に依存しています（つまり、ファーム内の土壌センサーに送信されるさまざまな連続パラメーターを提供します）ディスプレイまたは温室調整システム）[FRESHNESS]。
In the indirect approach, each cache consults the publisher of the cached NDO about its staleness before serving it. This approach assumes that the NDO includes the publisher information, which can be used to reach the publisher. It is suitable for the NDO whose expiration time is difficult to be set in advance, e.g., a web page that contains the main text (which stays the same ever after) and the interactive sections such as comments or ads (which are updated irregularly).
間接的なアプローチでは、各キャッシュは、サービスを提供する前に、キャッシュされたNDOのパブリッシャーにその古さについて問い合わせます。このアプローチでは、NDOに発行元情報が含まれ、発行元に到達するために使用できると想定しています。有効期限を事前に設定することが難しいNDOに適しています。たとえば、メインテキスト（これまでと同じです）やコメントや広告などのインタラクティブなセクション（不定期に更新されます）を含むWebページ。
It is often argued that ignoring stale NDOs in caches and simply providing new names for updated NDOs might be sufficient rather than using a staleness verification algorithm to manage them. However, notifying the new names of updated NDOs to users is not a trivial task. Unless the update is informed to all users at the same time, some users would use the old name although they intended to retrieve the updated NDO.
キャッシュ内の古いNDOを無視して、更新されたNDOに新しい名前を提供するだけで、古い検証アルゴリズムを使用してそれらを管理するのではなく、十分であるとしばしば主張されます。ただし、更新されたNDOの新しい名前をユーザーに通知することは簡単な作業ではありません。更新がすべてのユーザーに同時に通知されない限り、一部のユーザーは更新されたNDOを取得するつもりでしたが、古い名前を使用します。
One research challenge is how to design consistency and coherence models for caching NDOs along with their revision handling and updating protocols in a scalable manner.
研究課題の1つは、NDOをキャッシュするための整合性と一貫性のあるモデルを、リビジョンの処理とプロトコルのスケーラブルな方法でどのように設計するかです。
When ICN is deployed as a general, application-independent network and cache infrastructure, multiple consumers and producers (representing different applications) would communicate over the same infrastructure. With universal naming schemes or sufficiently unique hash-based identifiers, different application could also share identical NDOs in a transparent way.
ICNがアプリケーションに依存しない一般的なネットワークおよびキャッシュインフラストラクチャとして展開される場合、複数のコンシューマとプロデューサ（異なるアプリケーションを表す）は同じインフラストラクチャを介して通信します。ユニバーサルネーミングスキーマまたは十分に一意のハッシュベースの識別子を使用すると、異なるアプリケーションが同一のNDOを透過的に共有することもできます。
Depending on the naming, data integrity, and data origin authentication approaches, there may be technical and business challenges to share caches across different applications, for example, content protection, avoiding cache poisoning, ensuring performance isolation, etc. As ICN research matures, these challenges should be addressed more specifically in a dedicated document.
ネーミング、データ整合性、およびデータ発信元認証のアプローチによっては、コンテンツ保護、キャッシュ汚染の回避、パフォーマンスの分離の確保など、さまざまなアプリケーション間でキャッシュを共有するための技術的およびビジネス上の課題が存在する可能性があります。ICNの研究が成熟するにつれて、これらは課題は、専用のドキュメントでより具体的に対処する必要があります。
Managing networks has been a core craft in the IP-based host-centric paradigm ever since the technology was introduced in production networks. However, at the onset of IP, management was considered primarily as an add-on. Essential tools that are used daily by networkers, such as ping and traceroute, did not become widely available until more than a decade or so after IP was first introduced. Management protocols, such as SNMP, also became available much later than the original introduction of IP, and many still consider them insufficient despite the years of experience we have running host-centric networks. Today, when new networks are deployed, network management is considered a key aspect for any operator, a major challenge that is directly reflected in higher operational cost if not done well. If we want ICN to be deployed in infrastructure networks, development of management tools and mechanisms must go hand in hand with the rest of the architecture design.
ネットワークの管理は、本番ネットワークにテクノロジーが導入されて以来、IPベースのホスト中心のパラダイムにおけるコアクラフトでした。ただし、IPの開始時には、管理は主にアドオンと見なされていました。 pingやtracerouteなど、ネットワーカーが日常的に使用する重要なツールは、IPが最初に導入されてから10年以上経つまでは広く普及していませんでした。 SNMPなどの管理プロトコルも、最初のIPの導入よりもはるかに遅れて利用可能になりました。ホスト中心のネットワークを実行してきた長年の経験にもかかわらず、多くの人がまだ不十分だと考えています。今日、新しいネットワークが導入されると、ネットワーク管理はすべてのオペレーターにとって重要な側面と見なされます。主要な課題は、うまくいかなければ運用コストの増加に直接反映されます。 ICNをインフラストラクチャネットワークに展開する場合、管理ツールとメカニズムの開発は、残りのアーキテクチャ設計と連携する必要があります。
Although defining an FCAPS (Fault, Configuration, Accounting, Performance, and Security) [ISOIEC-7498-4] management model for ICN is clearly outside the scope of this document, there is a need for creating basic tools early on while ICN is still in the design and experimentation phases that can evolve over time and help network operations centers (NOCs) to define policies, validate that they are indeed used in practice, be notified early on about failures, and determine and resolve configuration problems. Authentication, Authorization, and Accounting (AAA) as well as performance management, from a NOC perspective, will also need to be considered. Given the expectations for a large number of nodes and unprecedented traffic volumes, automating tasks or even better employing self-management mechanisms are preferred. The main challenge here is that all tools we have at our disposal today are node-centric, are end-to-end oriented, or assume a packet-stream communication environment. Rethinking reachability and operational availability, for example, can yield significant insights into how information-centric networks will be managed in the future.
FCAPS（障害、構成、アカウンティング、パフォーマンス、およびセキュリティ）[ISOIEC-7498-4]の定義は、ICNの管理モデルは明らかにこのドキュメントの範囲外ですが、ICNがまだある間に、初期のツールを作成する必要があります。時間の経過とともに発展し、ネットワークオペレーションセンター（NOC）がポリシーを定義し、実際に実際に使用されていることを検証し、障害について早期に通知され、構成の問題を特定して解決するのに役立つ設計および実験フェーズNOCの観点からの認証、承認、アカウンティング（AAA）とパフォーマンス管理も考慮する必要があります。多数のノードと前例のないトラフィック量が予想されるため、タスクを自動化するか、自己管理メカニズムをより適切に使用することが推奨されます。ここでの主な課題は、今日自由に使用できるすべてのツールがノード中心であるか、エンドツーエンド指向であるか、またはパケットストリーム通信環境を想定していることです。たとえば、到達可能性と運用の可用性を再考すると、情報中心のネットワークが将来どのように管理されるかについて重要な洞察が得られます。
With respect to network management, we see three different aspects. First, any operator needs to manage all resources available in the network, which can range from node connectivity to network bandwidth availability to in-network storage to multi-access support. In ICN, users will also bring into the network significant resources in terms of network coverage extension, storage, and processing capabilities. Delay Tolerant Networking (DTN) characteristics should also be considered to the degree that this is possible (e.g., content dissemination through data mules). Second, given that nodes and links are not at the center of an information-centric network, network management should capitalize on native ICN mechanisms. For example, in-network storage and name resolution can be used for monitoring, while native publish/subscribe functionality can be used for triggering notifications. Finally, management is also at the core of network-controlling capabilities by allowing operating actions to be mediated and decided, triggering and activating networking procedures in an optimized way. For example, monitoring aspects can be conjugated with different management actions in a coordinated way, allowing network operations to flow in a concerted manner.
ネットワーク管理に関しては、3つの異なる側面があります。まず、どのオペレーターも、ネットワークで利用可能なすべてのリソースを管理する必要があります。これには、ノード接続からネットワーク帯域幅の可用性、ネットワーク内ストレージ、マルチアクセスサポートまでさまざまです。 ICNでは、ユーザーは、ネットワークカバレッジの拡張、ストレージ、および処理機能の観点から、ネットワークに重要なリソースを持ち込みます。遅延耐性ネットワーク（DTN）の特性も、これが可能である程度に考慮する必要があります（データラバを介したコンテンツの配信など）。次に、ノードとリンクが情報中心のネットワークの中心にない場合、ネットワーク管理はネイティブのICNメカニズムを活用する必要があります。たとえば、監視にはネットワーク内ストレージと名前解決を使用できますが、通知のトリガーにはネイティブのパブリッシュ/サブスクライブ機能を使用できます。最後に、管理はまた、最適化された方法でネットワーク手順をトリガーおよびアクティブ化する操作アクションを仲介および決定できるようにすることにより、ネットワーク制御機能の中核にもなります。たとえば、監視の側面をさまざまな管理アクションと連携させて連携させることで、ネットワーク操作を協調して流すことができます。
However, the considerations on leveraging intrinsic ICN mechanisms and capabilities to support management operations go beyond a simple mapping exercise. In fact, it not only raises a series of challenges on its own, but also opens up new possibilities for both ICN and
ただし、管理操作をサポートするための固有のICNメカニズムと機能の活用に関する考慮事項は、単純なマッピングの練習を超えています。実際、それ自体が一連の課題を引き起こすだけでなく、ICNとICN
"network management" as a concept. For instance, naming mechanisms are central to ICN-intrinsic operations, which are used to identify and reach content under different aspects (e.g., hierarchically structured vs. "flattish" names). In this way, ICN is decoupled from host-centric aspects on which traditional network management schemes rely. As such, questions are raised that can directly be translated into challenges for network management capability, such as, for example, how to address a node or a network segment in an ICN naming paradigm, how to identify which node is connected "where", how to be aware of the node capabilities (i.e., high or low-powered machine-to-machine (M2M) node), and if there is a host-centric protocol running where the management process can also leverage.
概念としての「ネットワーク管理」。たとえば、名前付けメカニズムは、さまざまな側面（たとえば、階層的に構造化された名前と「フラットな」名前）でコンテンツを識別して到達するために使用されるICN固有の操作の中心です。このようにして、ICNは、従来のネットワーク管理スキームが依存するホスト中心の側面から切り離されています。そのため、たとえば、ICNネーミングパラダイムでノードまたはネットワークセグメントをアドレス指定する方法、「どこで」接続されているノードを識別する方法など、ネットワーク管理機能の課題に直接変換できる質問が提示されます。ノードの機能（つまり、高電力または低電力のマシンツーマシン（M2M）ノード）を認識する方法と、管理プロセスも活用できるホスト中心のプロトコルが実行されているかどうか。
But, on the other hand, these same inherent ICN characteristics also allow us to look into network management through a new perspective. By centering its operations around NDOs, one can conceive new management operations addressing, for example, per-content management or access control, as well as analyzing performance per NDO instead of per link or node. Moreover, such considerations can also be used to manage operational aspects of ICN mechanisms themselves. For example, [NDN-MGMT] reutilizes inherent content-centric capabilities of CCN to manage optimal link connectivity for nodes, in concert with a network optimization process. Conversely, how these content-centric aspects can otherwise influence and impact management in other areas (e.g., security and resilience) is also important, as exemplified in [CCN-ACCESS], where access control mechanisms are integrated into a prototype of the [PURSUIT] architecture.
ただし、一方で、これらの同じ固有のICN特性により、新しい視点からネットワーク管理を調査することもできます。オペレーションをNDOに集中させることで、コンテンツごとの管理やアクセス制御などの新しい管理オペレーションを考えたり、リンクやノードごとではなくNDOごとのパフォーマンスを分析したりできます。さらに、そのような考慮事項は、ICNメカニズム自体の運用面を管理するためにも使用できます。たとえば、[NDN-MGMT]は、CCNの固有のコンテンツ中心の機能を再利用して、ネットワーク最適化プロセスと連携して、ノードの最適なリンク接続を管理します。逆に、[CCN-ACCESS]に例示されているように、これらのコンテンツ中心の側面が他の領域（たとえば、セキュリティと回復力）の管理に影響を与え、影響を与える方法も重要です。アクセス制御メカニズムは[PURSUIT ] 建築。
The set of core research challenges for ICN management includes:
ICN管理の主要な研究課題は次のとおりです。
o Management and control of NDO reception at the requestor
o リクエスタでのNDO受信の管理と制御
o Coordination of management information exchange and control between ICN nodes and ICN network control points
o ICNノードとICNネットワークコントロールポイント間の管理情報交換と制御の調整
o Identification of management and controlling actions and items through information naming
o 情報の命名による管理とアクションおよびアイテムの制御の識別
o Relationship between NDOs and host entities identification, i.e., how to identify a particular link, interface, or flow that needs to be managed
o NDOとホストエンティティの識別の関係、つまり、管理する必要がある特定のリンク、インターフェース、またはフローを識別する方法
ICN can be applied to different application domains and is expected to provide benefits for application developers by providing a more suitable interface for application developers (in addition to the other ICN benefits described above). [RFC7476] provides an overview of relevant application domains at large. This section discusses opportunities and challenges for selected application types.
ICNはさまざまなアプリケーションドメインに適用でき、（上記の他のICNの利点に加えて）アプリケーション開発者により適切なインターフェイスを提供することにより、アプリケーション開発者に利点を提供することが期待されます。 [RFC7476]は、関連するアプリケーションドメイン全体の概要を提供します。このセクションでは、選択したアプリケーションタイプの機会と課題について説明します。
Intuitively, the ICN request/response communication style seems to be directly mappable to web communication over HTTP. NDO names could be the equivalent of URIs in today's web, proprietary and transparent caching could be obsoleted by ICN in-network caching, and developers could directly use an ICN request/response API to build applications.
直感的には、ICN要求/応答通信スタイルは、HTTPを介したWeb通信に直接マッピングできるようです。 NDO名は今日のWebのURIに相当する可能性があり、独自の透過的なキャッシングはICNネットワーク内キャッシングによって廃止され、開発者はICN要求/応答APIを直接使用してアプリケーションを構築できます。
Research efforts such as [ICN2014-WEB-NDN] have analyzed real-world web applications and ways to implement them in ICN. The most significant insight is that REST-style (Representational State Transfer) web communication relies heavily on transmitting user/ application context information in HTTP GET requests, which would have to be mapped to corresponding ICN messages. The challenge in ICN would be how to exactly achieve that mapping. This could be done to some degree by extending name formats or by extending message structure to include cookies and similar context information. The design decisions would need to consider overhead in routers (for example, if larger GET/Interest messages would have to be stored in corresponding tables on routers).
[ICN2014-WEB-NDN]などの研究努力により、実際のWebアプリケーションと、それらをICNに実装する方法が分析されました。最も重要な洞察は、RESTスタイル（Representational State Transfer）のWeb通信は、対応するICNメッセージにマップする必要があるHTTP GETリクエストでユーザー/アプリケーションコンテキスト情報を送信することに大きく依存していることです。 ICNでの課題は、そのマッピングを正確に達成する方法です。これは、名前形式を拡張するか、メッセージ構造を拡張してCookieと同様のコンテキスト情報を含めることにより、ある程度行うことができます。設計の決定では、ルーターのオーバーヘッドを考慮する必要があります（たとえば、より大きなGET / Interestメッセージをルーターの対応するテーブルに格納する必要がある場合）。
Other challenges include the ability to return different results based on requestor-specific processing in the presence of immutable objects (and name-object bindings) in ICN and the ability for efficient bidirectional communication, which would require some mechanism to name and reach requestor applications.
その他の課題には、ICN内の不変オブジェクト（および名前オブジェクトバインディング）の存在下でリクエスター固有の処理に基づいて異なる結果を返す機能や、リクエスターアプリケーションに名前を付けて到達するためのメカニズムが必要な効率的な双方向通信の機能が含まれます。
One of ICN's prime application areas is video streaming and download where accessing named data, object-level security, and in-network storage can fulfill requirements for both video streaming and download. The applicability and benefits of ICN to video has been demonstrated by several prototype developments [ICN2014-AHLGREN-VIDEO-DEMO].
ICNの主要なアプリケーション領域の1つは、ビデオストリーミングとダウンロードです。名前付きデータ、オブジェクトレベルのセキュリティ、およびネットワーク内ストレージにアクセスすると、ビデオストリーミングとダウンロードの両方の要件を満たすことができます。 ICNのビデオへの適用性と利点は、いくつかのプロトタイプ開発[ICN2014-AHLGREN-VIDEO-DEMO]によって実証されています。
[VIDEO-STREAMING] discusses the opportunities and challenges of implementing today's video services such as DASH-based (Dynamic Adaptive Streaming over HTTP) streaming and download over ICN, considering performance requirements, relationship to peer-to-peer live streaming, IPTV, and Digital Rights Management (DRM).
[VIDEO-STREAMING]は、パフォーマンス要件、ピアツーピアライブストリーミング、IPTV、デジタル著作権管理（DRM）。
In addition to just porting today's video application from a host-centric paradigm to ICN, there are also promising opportunities to leverage the ICN network services for redesigning and thus significantly enhancing video access and distribution [ICNRG-2015-01-WESTPHAL]. For example, ICN store and forward could be leveraged for rate adaptation to achieve maximum throughput and optimal Quality of Experience (QoE) in scenarios with varying link properties, if capacity information is fed back to rate selection algorithms at senders. Other optimizations such as more aggressive prefetching could be performed in the network by leveraging visibility of chunk NDO names and NDO metadata in the network. Moreover, multi-source rate adaptation in combination with network coding could enable better QoE, for example, in multi-interface/ access scenarios where multiple paths from client to upstream caches exist [RFC7476].
今日のビデオアプリケーションをホスト中心のパラダイムからICNに移植するだけでなく、ICNネットワークサービスを活用してビデオのアクセスと配信を再設計し、大幅に強化する有望な機会もあります[ICNRG-2015-01-WESTPHAL]。たとえば、容量情報が送信者のレート選択アルゴリズムにフィードバックされる場合、リンクプロパティが変化するシナリオで最大スループットと最適なエクスペリエンス品質（QoE）を実現するために、ICNストアアンドフォワードをレート適応に活用できます。ネットワーク内のチャンクNDO名とNDOメタデータの可視性を活用することにより、より積極的なプリフェッチなどの他の最適化をネットワークで実行できます。さらに、ネットワークコーディングと組み合わせたマルチソースレートアダプテーションは、たとえば、クライアントからアップストリームキャッシュへの複数のパスが存在するマルチインターフェイス/アクセスシナリオ[RFC7476]で、より良いQoEを可能にします。
The essence of ICN lies in the name-based routing that enables users to retrieve NDOs by the names regardless of their locations. By definition, ICN is well suited for IoT applications, where users consume data generated from IoTs without maintaining secure connections to them. The basic request/response style APIs of ICN enable developers to build IoT applications in a simple and fast manner.
ICNの本質は、ユーザーが場所に関係なく名前でNDOを取得できる名前ベースのルーティングにあります。定義上、ICNは、ユーザーがIoTへの安全な接続を維持せずにIoTから生成されたデータを使用するIoTアプリケーションに適しています。 ICNの基本的なリクエスト/レスポンススタイルのAPIにより、開発者はIoTアプリケーションをシンプルかつ高速な方法で構築できます。
Ongoing efforts such as [ICN-FOR-IOT], [ICN-ARCH], and [ICN2014-NDNWILD] have addressed the requirements and challenges of ICN for IoT. For instance, many IoT applications depend on a PUSH model where data transmission is initiated by the publisher, so they can support various real-time applications (emergency alarm, etc.). However, ICN does not support the PUSH model in a native manner due to its inherent receiver-driven data transmission mechanism. The challenge would be how to efficiently support the PUSH model in ICN, so it provides publish/subscribe-style APIs for IoT application developers. This could be done by introducing other types of identifiers such as a device identifier or by extending the current request/response communication style, which may result in heavy overhead in ICN routers.
[ICN-FOR-IOT]、[ICN-ARCH]、[ICN2014-NDNWILD]などの継続的な取り組みにより、ICN for IoTの要件と課題に対処しています。たとえば、多くのIoTアプリケーションは、データ送信がパブリッシャーによって開始されるPUSHモデルに依存しているため、さまざまなリアルタイムアプリケーション（緊急アラームなど）をサポートできます。ただし、ICNは固有のレシーバー駆動のデータ送信メカニズムのため、PUSHモデルをネイティブな方法でサポートしていません。問題は、ICNでPUSHモデルを効率的にサポートする方法であり、IoTアプリケーション開発者にパブリッシュ/サブスクライブスタイルのAPIを提供します。これは、デバイス識別子などの他のタイプの識別子を導入することによって、または現在の要求/応答通信スタイルを拡張することによって行うことができ、ICNルーターで大きなオーバーヘッドが発生する可能性があります。
Moreover, key characteristics of the ICN underlying operation also impact important aspects of IoT, such as the caching in content storage of network forwarding entities. This allows the simplification of ICN-based IoT application development. Since the network is able to act on named content, generic names provide a way to address content independently of the underlying device (and access) technology, and bandwidth consumption is optimized due to the availability of cached content. However, these aspects raise challenges themselves concerning the freshness of the information received from the cache in contrast to the last value generated by a sensor, as well as pushing content to specific nodes (e.g., for controlling them), which requires individual addressing for identification. In addition, due to the heterogeneous nature of IoT nodes, their processing capabilities might not be able to handle the necessary content signing verification procedures.
さらに、基になるICNオペレーションの主要な特性は、ネットワーク転送エンティティのコンテンツストレージでのキャッシングなど、IoTの重要な側面にも影響を与えます。これにより、ICNベースのIoTアプリケーション開発を簡素化できます。ネットワークは名前付きコンテンツを操作できるため、総称名は、基盤となるデバイス（およびアクセス）テクノロジーとは無関係にコンテンツに対処する方法を提供し、キャッシュされたコンテンツの可用性により帯域幅の消費が最適化されます。ただし、これらの側面は、センサーによって生成された最後の値とは対照的に、キャッシュから受信した情報の鮮度、および特定のノードにコンテンツをプッシュする（たとえば、それらを制御する）ために、識別のために個別のアドレス指定を必要とする課題を提起します。 。さらに、IoTノードの異種性により、その処理機能は必要なコンテンツ署名検証手順を処理できない場合があります。
This document does not impact the security of the Internet. Security questions related to ICN are discussed in Section 4.2.
このドキュメントは、インターネットのセキュリティには影響しません。 ICNに関連するセキュリティの質問については、セクション4.2で説明します。
[ACCESS-CTL-DEL] Fotiou, N., Marias, G., and G. Polyzos, "Access control enforcement delegation for information-centric networking architectures", Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12) Helsinki, Finland, DOI 10.1145/2342488.2342507, 2012.
[ACCESS-CTL-DEL] Fotiou、N.、Marias、G。、およびG. Polyzos、「情報中心のネットワークアーキテクチャのためのアクセス制御実施委任」、情報中心のネットワークに関するICNワークショップの第2版の議事録（ ICN '12）ヘルシンキ、フィンランド、DOI 10.1145 / 2342488.2342507、2012。
[BACKSCATTER] Waehlisch, M., Schmidt, TC., and M. Vahlenkamp, "Backscatter from the Data Plane - Threats to Stability and Security in Information-Centric Network Infrastructure", Computer Networks Vol 57, No. 16, pp. 3192-3206, DOI 10.1016/j.comnet.2013.07.009, November 2013.
[バックスキャッター] Waehlisch、M.、Schmidt、TC、およびM. Vahlenkamp、「データプレーンからの後方散乱-情報中心のネットワークインフラストラクチャにおける安定性とセキュリティへの脅威」、コンピュータネットワークVol。57、No。16、pp。3192 -3206、DOI 10.1016 / j.comnet.2013.07.009、2013年11月。
[BREADCRUMBS] Rosensweig, E. and J. Kurose, "Breadcrumbs: Efficient, Best-Effort Content Location in Cache Networks", In Proceedings of the IEEE INFOCOM 2009, DOI 10.1109/INFCOM.2009.5062201, April 2009.
[BREADCRUMBS] Rosensweig、E.、J。Kurose、「Breadcrumbs：Efficient、Best-Effort Content Location in Cache Networks」、Proceedings of the IEEE INFOCOM 2009、DOI 10.1109 / INFCOM.2009.5062201、2009年4月。
[CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", CoNEXT 2009, DOI 10.1145/1658939.1658941, December 2009.
[CCN] Jacobson、V.、Smetters、D.、Thornton、J.、Plass、M.、Briggs、N。、およびR. Braynard、「Networking Named Content」、CoNEXT 2009、DOI 10.1145 / 1658939.1658941、2009年12月。
[CCN-ACCESS] Fotiou, N., Marias, G., and G. Polyzos, "Access control enforcement delegation for information-centric networking architectures", In Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12), ACM, New York, NY, USA, 85-90, DOI 10.1145/2342488.2342507, 2012.
[CCN-ACCESS] Fotiou、N.、Marias、G。、およびG. Polyzos、「情報中心のネットワークアーキテクチャのためのアクセス制御実施委任」、情報中心のネットワークに関するICNワークショップの第2版の議事録（ICN '12）、ACM、ニューヨーク、ニューヨーク、アメリカ、85-90、DOI 10.1145 / 2342488.2342507、2012。
[CHAUM] Chaum, D. and E. van Heijst, "Group signatures", In Proceedings of EUROCRYPT, DOI 10.1007/3-540-46416-6_22, 1991.
[CHAUM] Chaum、D。およびE. van Heijst、「グループの署名」、EUROCRYPTの議事録、DOI 10.1007 / 3-540-46416-6_22、1991。
[COMPACT] Cowen, L., "Compact routing with minimum stretch", In Journal of Algorithms, vol. 38, pp. 170-183, DOI 10.1006/jagm.2000.1134, 2001.
[COMPACT]コーウェンL.、「ストレッチが最小のコンパクトルーティング」、アルゴリズムのジャーナル、vol。 38、pp。170-183、DOI 10.1006 / jagm.2000.1134、2001。
[CONTUG] Arianfar, S., Nikander, P., Eggert, L., Ott, J., and W. Wong, "ConTug: A Receiver-Driven Transport Protocol for Content-Centric Networks", Technical Report Aalto University Comnet, 2011.
[CONTUG] Arianfar、S.、Nikander、P.、Eggert、L.、Ott、J。、およびW. Wong、「ConTug：受信者主導のコンテンツ中心のネットワークのためのトランスポートプロトコル」、テクニカルレポートAalto University Comnet、 2011。
[DONA] Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gon Chun, B., and S. Shenker, "A Data-Oriented (and Beyond) Network Architecture", In Proceedings of SIGCOMM 2007, DOI 10.1145/1282427.1282402, August 2007.
[ドナ]コポネン、T。、エルモリンスキー、A。、チャウラ、M。、キム、K。、ゴンチュン、B.、S。シェンカーSIGCOMM 2007、DOI 10.1145 / 1282427.1282402、2007年8月。
[ENCRYPTION-AC] Kurihara, J., Uzun, E., and C. Wood, "An Encryption-Based Access Control Framework for Content-Centric Networking", IFIP Networking 2015, Toulouse, France, DOI 10.1109/IFIPNetworking.2015.7145300, September 2015.
[ENCRYPTION-AC] Kurihara、J.、Uzun、E。、およびC. Wood、「コンテンツ中心のネットワーキングのための暗号化ベースのアクセス制御フレームワーク」、IFIPネットワーキング2015、トゥールーズ、フランス、DOI 10.1109 / IFIPNetworking.2015.7145300、 2015年9月。
[FRESHNESS] Quevedo, J., Corujo, D., and R. Aguiar, "Consumer Driven Information Freshness Approach for Content Centric Networking", IEEE INFOCOM Workshop on Name-Oriented Mobility Toronto, Canada, DOI 10.1109/INFCOMW.2014.6849279, May 2014.
[フレッシュネス]ケベド、J。、コルホ、D。、およびR.アギアール、「コンテンツ中心のネットワーキングのための消費者主導の情報フレッシュネスアプローチ」、名前付きモビリティに関するIEEE INFOCOMワークショップ、カナダ、トロント、DOI 10.1109 / INFCOMW.2014.6849279、5月2014。
[GREEDY] Papadopoulos, F., Krioukov, D., Boguna, M., and A. Vahdat, "Greedy forwarding in dynamic scale-free networks embedded in hyperbolic metric spaces", In Proceedings of the IEEE INFOCOM, San Diego, USA, DOI 10.1109/INFCOM.2010.5462131, 2010.
[GREEDY] Papadopoulos、F.、Krioukov、D.、Boguna、M。、およびA. Vahdat、「双曲線メトリック空間に埋め込まれた動的なスケールフリーネットワークでのグリーディな転送」、IEEE INFOCOMの議事録、サンディエゴ、米国、DOI 10.1109 / INFCOM.2010.5462131、2010。
[HRICP] Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop-by-hop and receiver-driven interest control protocol for content-centric networks", In Proceedings of ACM SIGCOMM ICN 2012, DOI 10.1145/2342488.2342497, 2012.
[HRICP] Carofiglio、G.、Gallo、M。、およびL. Muscariello、「コンテンツ中心のネットワークのためのホップバイホップおよび受信者主導のジョイント制御プロトコル」、ACM SIGCOMM ICN 2012、DOI 10.1145 / 2342488.2342497、2012。
[ICN-ARCH] Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E., Burke, J., Ravindran, R., Ed., and G. Wang, "ICN based Architecture for IoT - Requirements and Challenges", Work in Progress, draft-zhang-iot-icn-challenges-02, August 2015.
[ICN-ARCH] Zhang、Y.、Raychadhuri、D.、Grieco、L.、Baccelli、E.、Burke、J.、Ravindran、R.、Ed。、およびG. Wang、「ICNベースのIoT向けアーキテクチャ-要件と課題」、進行中の作業、draft-zhang-iot-icn-challenges-02、2015年8月。
[ICN-FOR-IOT] Lindgren, A., Ben Abdesslem, F., Ahlgren, B., Schelen, O., and A. Malik, "Applicability and Tradeoffs of Information-Centric Networking for Efficient IoT", Work in Progress, draft-lindgren-icnrg-efficientiot-03, July 2015.
[ICN-FOR-IOT] Lindgren、A.、Ben Abdesslem、F.、Ahlgren、B.、Schelen、O。、およびA. Malik、「効率的なIoTのための情報中心のネットワーキングの適用性とトレードオフ」、進行中の作業、draft-lindgren-icnrg-efficientiot-03、2015年7月。
[ICN2014-AHLGREN-VIDEO-DEMO] Ahlgren, B., Jonasson, A., and B. Ohlman, "Demo Overview: HTTP Live Streaming over NetInf Transport", ACM SIGCOMM Information-Centric Networking Conference Paris, France, DOI 10.1145/2660129.2660136, September 2014.
[ICN2014-AHLGREN-VIDEO-DEMO] Ahlgren、B.、Jonasson、A。、およびB. Ohlman、「Demo Overview：HTTP Live Streaming over NetInf Transport」、ACM SIGCOMM Information-Centric Networking Conference Paris、フランス、パリ、DOI 10.1145 / 2660129.2660136、2014年9月。
[ICN2014-NDNWILD] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. Waehlisch, "Information Centric Networking in the IoT: Experiments with NDN in the Wild", ACM SIGCOMM Information-Centric Networking Conference Paris, France, DOI 10.1145/2660129.2660144, September 2014.
[ICN2014-NDNWILD] Baccelli、E.、Mehlis、C.、Hahm、O.、Schmidt、T。、およびM. Waehlisch、「IoTにおける情報セントリックネットワーキング：野生のNDNによる実験」、ACM SIGCOMM情報- Centric Networking Conference Paris、France、DOI 10.1145 / 2660129.2660144、2014年9月。
[ICN2014-WEB-NDN] Moiseenko, I., Stapp, M., and D. Oran, "Communication Patterns for Web Interaction in Named Data Networking", ACM SIGCOMM Information-Centric Networking Conference Paris, France, DOI 10.1145/2660129.2660152, September 2014.
[ICN2014-WEB-NDN] Moiseenko、I.、Stapp、M。、およびD. Oran、「名前付きデータネットワーキングにおけるWeb相互作用の通信パターン」、ACM SIGCOMM Information-Centric Networking Conference Paris、France、DOI 10.1145 / 2660129.2660152、 2014年9月。
[ICNNAMING] Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and S. Shenker, "Naming in Content-Oriented Architectures", In Proceedings ACM SIGCOMM Workshop on Information-Centric Networking (ICN), DOI 10.1145/2018584.2018586, 2011.
[ICNNAMING] Ghodsi、A.、Koponen、T.、Rajahalme、J.、Sarolahti、P。、およびS. Shenker、「コンテンツ指向アーキテクチャの命名」、Proceedings ACM SIGCOMM Workshop on Information-Centric Networking（ICN） 、DOI 10.1145 / 2018584.2018586、2011。
[ICNRG-2015-01-WESTPHAL] Westphal, C., "Video over ICN", IRTF ICNRG Meeting Cambridge, Massachusetts, USA, January 2015, <http://www.ietf.org/proceedings/interim/2015/01/13/icnrg/ slides/slides-interim-2015-icnrg-1-0.pptx>.
[ICNRG-2015-01-WESTPHAL] Westphal、C。、「Video over ICN」、IRTF ICNRGミーティング、ケンブリッジ、米国、マサチューセッツ、2015年1月、<http://www.ietf.org/proceedings/interim/2015/01 /13/icnrg/slides/slides-interim-2015-icnrg-1-0.pptx>。
[ICNSURVEY] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., and B. Ohlman, "A Survey of Information-Centric Networking", In Communications Magazine, IEEE, vol. 50, no. 7, pp. 26-36, DOI 10.1109/MCOM.2012.6231276, 2012.
[ICNSURVEY] Ahlgren、B.、Dannewitz、C.、Imbrenda、C.、Kutscher、D。、およびB. Ohlman、「A-Survey of Information-Centric Networking」、In Communications Magazine、IEEE、vol。 50、いいえ。 7、pp。26-36、DOI 10.1109 / MCOM.2012.6231276、2012。
[ISOIEC-7498-4] ISO, "Information Processing Systems -- Open Systems Interconnection -- Basic Reference Model -- Part 4: Management Framework", November 1989, <http://standards.iso.org/ittf/PubliclyAvailableStandards/ s014258_ISO_IEC_7498-4_1989(E).zip>.
[ISOIEC-7498-4] ISO、「情報処理システム-オープンシステム相互接続-基本参照モデル-パート4：管理フレームワーク」、1989年11月、<http://standards.iso.org/ittf/PubliclyAvailableStandards/ s014258_ISO_IEC_7498-4_1989（E）.zip>。
[MANI] Pentikousis, K. and T. Rautio, "A multiaccess Network of Information", WoWMoM 2010 IEEE, DOI 10.1109/WOWMOM.2010.5534922, June 2010.
[MANI] Pentikousis、K。およびT. Rautio、「情報のマルチアクセスネットワーク」、WoWMoM 2010 IEEE、DOI 10.1109 / WOWMOM.2010.5534922、2010年6月。
[MDHT] D'Ambrosio, M., Dannewitz, C., Karl, H., and V. Vercellone, "MDHT: A hierarchical name resolution service for information-centric networks", ACM SIGCOMM workshop on Information-centric networking Toronto, Canada, DOI 10.1145/2018584.2018587, August 2011.
[MDHT] D'Ambrosio、M.、Dannewitz、C.、Karl、H。、およびV. Vercellone、「MDHT：情報中心のネットワークのための階層的な名前解決サービス」、情報中心のネットワーキングトロントに関するACM SIGCOMMワークショップ、カナダ、DOI 10.1145 / 2018584.2018587、2011年8月。
[MMIN] Pentikousis, K. and P. Bertin, "Mobility management in infrastructure networks", Internet Computing, IEEE vol. 17, no. 5, pp. 74-79, DOI 10.1109/MIC.2013.98, October 2013.
[MMIN] Pentikousis、K。およびP. Bertin、「インフラストラクチャネットワークのモビリティ管理」、インターネットコンピューティング、IEEE vol。 17、いいえ。 5、pp。74-79、DOI 10.1109 / MIC.2013.98、2013年10月。
[NDN-CTL-SHARING] Yu, Y., "Controlled Sharing of Sensitive Content", IRTF ICNRG Meeting San Francisco, USA, October 2015, <https://www.ietf.org/proceedings/interim/2015/10/03/ icnrg/slides/slides-interim-2015-icnrg-4-8.pdf>.
[NDN-CTL-SHARING] Yu、Y。、「機密コンテンツの管理された共有」、IRTF ICNRGミーティング、米国サンフランシスコ、2015年10月、<https://www.ietf.org/proceedings/interim/2015/10/ 03 / icnrg / slides / slides-interim-2015-icnrg-4-8.pdf>。
[NDN-MGMT] Corujo, D., Aguiar, R., Vidal, I., and J. Garcia-Reinoso, "A named data networking flexible framework for management communications", Communications Magazine, IEEE vol. 50, no. 12, pp. 36-43, DOI 10.1109/MCOM.2012.6384449, December 2012.
[NDN-MGMT] Corujo、D.、Aguiar、R.、Vidal、I。、およびJ. Garcia-Reinoso、「管理通信用の名前付きデータネットワーキングフレキシブルフレームワーク」、Communications Magazine、IEEE vol。 50、いいえ。 12、36-43ページ、DOI 10.1109 / MCOM.2012.6384449、2012年12月。
[PURSUIT] Fotiou et al., N., "Developing Information Networking Further: From PSIRP to PURSUIT", In Proceedings of Proc. BROADNETS. ICST, DOI 10.1007/978-3-642-30376-0_1, 2010.
[PURSUIT] Fotiou et al。、N.、「情報ネットワークのさらなる発展：PSIRPからPURSUITへ」、Procedings of Proc。ブロードネット。 ICST、DOI 10.1007 / 978-3-642-30376-0_1、2010。
[RANDOM] Gkantsidis, C., Mihail, M., and A. Saberi, "Random walks in peer-to-peer networks: algorithms and evaluation", In Perform. Eval., vol. 63, pp. 241-263, DOI 10.1016/j.peva.2005.01.002, 2006.
[ランダム] Gkantsidis、C.、Mihail、M。、およびA. Saberi、「ピアツーピアネットワークでのランダムウォーク：アルゴリズムと評価」、In Perform。評価、vol。 63、pp。241-263、DOI 10.1016 / j.peva.2005.01.002、2006。
[RESOURCE-POOL] Psaras, I., Saino, L., and G. Pavlou, "Revisiting Resource Pooling: The case of In-Network Resource Sharing", ACM HotNets Los Angeles, USA, DOI 10.1145/2670518.2673875, October 2014.
[RESOURCE-POOL] Psaras、I.、Saino、L。、およびG. Pavlou、「Revisiting Resource Pooling：The Case of In-Network Resource Sharing」、ACM HotNets Los Angeles、USA、DOI 10.1145 / 2670518.2673875、2014年10月。
[RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, DOI 10.17487/RFC2002, October 1996, <http://www.rfc-editor.org/info/rfc2002>.
[RFC2002]パーキンス、C。、編、「IPモビリティサポート」、RFC 2002、DOI 10.17487 / RFC2002、1996年10月、<http://www.rfc-editor.org/info/rfc2002>。
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, <http://www.rfc-editor.org/info/rfc4838>.
[RFC4838] Cerf、V.、Burleigh、S.、Hooke、A.、Torgerson、L.、Durst、R.、Scott、K.、Fall、K。、およびH. Weiss、「Delay-Tolerant Networking Architecture」 、RFC 4838、DOI 10.17487 / RFC4838、2007年4月、<http://www.rfc-editor.org/info/rfc4838>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, <http://www.rfc-editor.org/info/rfc5944>.
[RFC5944]パーキンス、C。、編、「IPv4のIPモビリティサポート、改訂」、RFC 5944、DOI 10.17487 / RFC5944、2010年11月、<http://www.rfc-editor.org/info/rfc5944>。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <http://www.rfc-editor.org/info/rfc6920>.
[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A。、およびP. Hallam-Baker、「Naming Things with Hashes」、RFC 6920、DOI 10.17487 / RFC6920、 2013年4月、<http://www.rfc-editor.org/info/rfc6920>。
[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, <http://www.rfc-editor.org/info/rfc7476>.
[RFC7476] Pentikousis、K.、Ed。、Ohlman、B.、Corujo、D.、Boggia、G.、Tyson、G.、Davies、E.、Molinaro、A.、and S. Eum、 "Information-Centricネットワーキング：ベースラインシナリオ」、RFC 7476、DOI 10.17487 / RFC7476、2015年3月、<http://www.rfc-editor.org/info/rfc7476>。
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <http://www.rfc-editor.org/info/rfc7696>.
[RFC7696] Housley、R。、「暗号化アルゴリズムの敏捷性と実装必須アルゴリズムの選択に関するガイドライン」、BCP 201、RFC 7696、DOI 10.17487 / RFC7696、2015年11月、<http://www.rfc-editor.org / info / rfc7696>。
[SEEN] Pentikousis, K., "In search of energy-efficient mobile networking", Communications Magazine, IEEE vol. 48 no. 1, pp. 95-103, DOI 10.1109/MCOM.2010.5394036, January 2010.
[SEEN] Pentikousis、K。、「エネルギー効率の高いモバイルネットワーキングを求めて」、Communications Magazine、IEEE vol。 48いいえ。 1、pp。95-103、DOI 10.1109 / MCOM.2010.5394036、2010年1月。
[VIDEO-STREAMING] Westphal, C., Ed., Lederer, S., Posch, D., Timmerer, C., Azgin, A., Liu, S., Mueller, C., Detti, A., Corujo, D., Wang, J., Montpetit, M., Murray, N., Azgin, A., and S. Liu, "Adaptive Video Streaming over ICN", Work in Progress, draft-irtf-icnrg-videostreaming-08, April 2016.
[VIDEO-STREAMING] Westphal、C.、Ed。、Lederer、S.、Posch、D.、Timmerer、C.、Azgin、A.、Liu、S.、Mueller、C.、Detti、A.、Corujo、 D.、Wang、J.、Montpetit、M.、Murray、N.、Azgin、A。、およびS. Liu、「ICNを介した適応型ビデオストリーミング」、Work in Progress、draft-irtf-icnrg-videostreaming-08、 2016年4月。
Acknowledgments
謝辞
The authors would like to thank Georgios Karagiannis for providing suggestions on QoS research challenges, Dimitri Papadimitriou for feedback on the routing section, and Joerg Ott and Stephen Farrell for reviewing the whole document.
著者は、QoS研究課題に関する提案を提供してくれたGeorgios Karagiannis、ルーティングセクションに関するフィードバックを提供してくれたDimitri Papadimitriou、ドキュメント全体をレビューしてくれたJoerg OttとStephen Farrellに感謝します。
Authors' Addresses
著者のアドレス
Dirk Kutscher (editor) NEC Kurfuersten-Anlage 36 Heidelberg Germany
Dirk Kutscher（編集者）NEC Kurfuersten-Anlage 36ハイデルベルクドイツ
Email: kutscher@neclab.eu
Suyong Eum Osaka University, School of Information Science and Technology 1-5 Yamadaoka, Suita Osaka 565-0871 Japan
すよんｇ えうｍ おさか うにゔぇｒしｔｙ、 Ｓちょおｌ おｆ いんふぉｒまちおん Ｓしえんせ あんｄ てｃｈのぉｇｙ １ー５ やまだおか、 すいた おさか ５６５ー０８７１ じゃぱん
Phone: +81-6-6879-4571
Email: suyong@ist.osaka-u.ac.jp
Kostas Pentikousis Travelping Koernerstr. 7-10 Berlin 10785 Germany
Costas Pentikousis Traveling Koernersstr。 7-10ベルリン10785ドイツ
Email: k.pentikousis@travelping.com Ioannis Psaras University College London, Dept. of E.E. Eng. Torrington Place London WC1E 7JE United Kingdom
メール：k.pentikousis@travelping.com Ioannis Psaras University College London、Dept. of E.E. Eng。トリントンプレイスロンドンWC1E 7JEイギリス
Email: i.psaras@ucl.ac.uk
Daniel Corujo Universidade de Aveiro Instituto de Telecomunicacoes, Campus Universitario de Santiago Aveiro P-3810-193 Portugal
ダニエル・コルホアヴェイロ大学通信研究所、サンティアゴアヴェイロ大学キャンパスP-3810-193ポルトガル
Email: dcorujo@av.it.pt
Damien Saucez INRIA 2004 route des Lucioles - BP 93 Sophia Antipolis 06902 Cedex France
ダミアンサウセINRIA 2004ルートデルシオレス-BP 93ソフィアアンティポリス06902セデックスフランス
Email: damien.saucez@inria.fr
Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg 20099 Germany
トーマスC.シュミットHAWハンブルグベルリントール7ハンブルク20099ドイツ
Email: t.schmidt@haw-hamburg.de
Matthias Waehlisch FU Berlin Takustr. 9 Berlin 14195 Germany
まってぃあｓ わえｈぃｓｃｈ ふ べｒぃん たくｓｔｒ。 ９ べｒぃん １４１９５ げｒまｎｙ
Email: waehlisch@ieee.org