[要約] RFC 8763は、情報中心ネットワーキング（ICN）の展開に関する考慮事項をまとめたものであり、ICNの導入における課題やベストプラクティスを提供しています。このRFCの目的は、ICNの展開に関する情報を提供し、ネットワークエンジニアや研究者に役立つガイドラインを提供することです。
Internet Research Task Force (IRTF) A. Rahman
Request for Comments: 8763 InterDigital Communications, LLC
Category: Informational D. Trossen
ISSN: 2070-1721 Huawei
D. Kutscher
Emden University
R. Ravindran
Sterlite Technologies
April 2020
Deployment Considerations for Information-Centric Networking (ICN)
情報中心型ネットワーキング（ICN）の導入に関する考慮事項
Abstract
概要
Information-Centric Networking (ICN) is now reaching technological maturity after many years of fundamental research and experimentation. This document provides a number of deployment considerations in the interest of helping the ICN community move forward to the next step of live deployments. First, the major deployment configurations for ICN are described, including the key overlay and underlay approaches. Then, proposed deployment migration paths are outlined to address major practical issues, such as network and application migration. Next, selected ICN trial experiences are summarized. Finally, protocol areas that require further standardization are identified to facilitate future interoperable ICN deployments. This document is a product of the Information-Centric Networking Research Group (ICNRG).
情報中心のネットワーキング（ICN）は、長年にわたる基礎的な研究と実験の結果、技術の成熟に近づいています。このドキュメントでは、ICNコミュニティがライブ展開の次のステップに進むのを支援するために、展開に関するいくつかの考慮事項について説明します。最初に、キーオーバーレイおよびアンダーレイアプローチを含む、ICNの主要な配置構成について説明します。次に、ネットワークやアプリケーションの移行などの主要な実際的な問題に対処するために、提案された展開移行パスの概要を説明します。次に、選択したICNトライアルの経験をまとめます。最後に、将来の相互運用可能なICN展開を容易にするために、さらなる標準化が必要なプロトコル領域が特定されます。この文書は、情報中心型ネットワーキング研究グループ（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 https://www.rfc-editor.org/info/rfc8763.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8763で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Terminology
3. Abbreviations List
4. Deployment Configurations
4.1. Clean-Slate ICN
4.2. ICN-as-an-Overlay
4.3. ICN-as-an-Underlay
4.3.1. Edge Network
4.3.2. Core Network
4.4. ICN-as-a-Slice
4.5. Composite-ICN Approach
5. Deployment Migration Paths
5.1. Application and Service Migration
5.2. Content Delivery Network Migration
5.3. Edge Network Migration
5.4. Core Network Migration
6. Deployment Trial Experiences
6.1. ICN-as-an-Overlay
6.1.1. FP7 PURSUIT Efforts
6.1.2. FP7 SAIL Trial
6.1.3. NDN Testbed
6.1.4. ICN2020 Efforts
6.1.5. UMOBILE Efforts
6.2. ICN-as-an-Underlay
6.2.1. H2020 POINT and RIFE Efforts
6.2.2. H2020 FLAME Efforts
6.2.3. CableLabs Content Delivery System
6.2.4. NDN IoT Trials
6.2.5. NREN ICN Testbed
6.2.6. DOCTOR Testbed
6.3. Composite-ICN Approach
6.4. Summary of Deployment Trials
7. Deployment Issues Requiring Further Standardization
7.1. Protocols for Application and Service Migration
7.2. Protocols for Content Delivery Network Migration
7.3. Protocols for Edge and Core Network Migration
7.4. Summary of ICN Protocol Gaps and Potential Protocol Efforts
8. Conclusion
9. IANA Considerations
10. Security Considerations
11. Informative References
Acknowledgments
Authors' Addresses
The ICNRG charter identifies deployment guidelines as an important topic area for the ICN community. Specifically, the charter states that defining concrete migration paths for ICN deployments that avoid forklift upgrades and defining practical ICN interworking configurations with the existing Internet paradigm are key topic areas that require further investigation [ICNRGCharter]. Also, it is well understood that results and conclusions from any mid- to large-scale ICN experiments in the live Internet will also provide useful guidance for deployments.
ICNRG憲章は、配備ガイドラインをICNコミュニティの重要なトピック領域として特定しています。具体的には、チャーターは、フォークリフトアップグレードを回避するICN展開の具体的な移行パスを定義し、既存のインターネットパラダイムとの実用的なICNインターワーキング構成を定義することが、さらなる調査が必要な主要トピック領域であると述べています[ICNRGCharter]。また、ライブインターネットでの中規模から大規模のICN実験の結果と結論も、展開に役立つガイダンスを提供することはよく理解されています。
So far, outside of some preliminary investigations, such as [ICN-DEP-CON], there has not been much progress on this topic. This document attempts to fill some of these gaps by defining clear deployment configurations for ICN and associated migration pathways for these configurations. Also, selected deployment trial experiences of ICN technology are summarized. Recommendations are also made for potential future IETF standardization of key protocol functionality that will facilitate interoperable ICN deployments going forward.
これまでのところ、[ICN-DEP-CON]などの予備調査を除いて、このトピックについてはあまり進展がありません。このドキュメントでは、ICNの明確な展開構成と、これらの構成に関連する移行パスを定義することで、これらのギャップの一部を埋めようとしています。また、ICNテクノロジの選択された展開トライアルの経験もまとめられています。今後の相互運用可能なICN展開を容易にする主要なプロトコル機能の潜在的な将来のIETF標準化についても推奨が行われます。
The major configurations of possible ICN deployments are identified in this document as (1) Clean-slate ICN replacement of existing Internet infrastructure, (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, (4) ICN-as-a-Slice, and (5) Composite-ICN. Existing ICN trial systems primarily fall under the ICN-as-an-Overlay, ICN-as-an-Underlay, and Composite-ICN configurations. Each of these deployment configurations have their respective strengths and weaknesses. This document will aim to provide guidance for current and future members of the ICN community when they consider deployment of ICN technologies.
可能なICN展開の主要な構成は、このドキュメントでは、（1）既存のインターネットインフラストラクチャのクリーンスレートICNの置き換え、（2）ICN-as-an-Overlay、（3）ICN-as-an-Underlay、（4 ）ICN-as-a-Slice、および（5）Composite-ICN。既存のICNトライアルシステムは、主にICN-as-an-Overlay、ICN-as-an-Underlay、およびComposite-ICN構成に分類されます。これらの展開構成にはそれぞれ長所と短所があります。このドキュメントは、ICNコミュニティの現在および将来のメンバーがICNテクノロジの展開を検討する際のガイダンスを提供することを目的としています。
This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). It has been reviewed extensively by the Research Group (RG) members active in the specific areas of work covered by the document.
このドキュメントは、情報中心のネットワーキング研究グループ（ICNRG）のコンセンサスを表しています。それは、文書でカバーされている特定の作業領域で活動している研究グループ（RG）メンバーによって広範囲にレビューされています。
This document assumes readers are, in general, familiar with the terms and concepts that are defined in [RFC7927] and [ICN-TERM]. In addition, this document defines the following terminology:
このドキュメントは、読者が一般に、[RFC7927]と[ICN-TERM]で定義されている用語と概念に精通していることを前提としています。さらに、このドキュメントでは次の用語を定義しています。
Deployment: The final stage of the process of setting up an ICN network that is (1) ready for useful work (e.g., transmission of end-user video and text) in a live environment and (2) integrated and interoperable with the Internet. We consider the Internet in its widest sense where it encompasses various access networks (e.g., Wi-Fi or mobile radio network), service edge networks (e.g., for edge computing), transport networks, Content Distribution Networks (CDNs), core networks (e.g., mobile core network), and back-end processing networks (e.g., data centers). However, throughout this document, the discussion is typically limited to edge networks, core networks, and CDNs, for simplicity.
展開：（1）ライブ環境で有用な作業（たとえば、エンドユーザーのビデオやテキストの送信）の準備ができており、（2）インターネットと統合され相互運用可能なICNネットワークをセットアップするプロセスの最終段階。インターネットは、さまざまなアクセスネットワーク（Wi-Fiやモバイルラジオネットワークなど）、サービスエッジネットワーク（エッジコンピューティングなど）、トランスポートネットワーク、コンテンツ配信ネットワーク（CDN）、コアネットワーク（たとえば、モバイルコアネットワーク）、およびバックエンド処理ネットワーク（たとえば、データセンター）。ただし、このドキュメントでは、説明を簡単にするために、通常、エッジネットワーク、コアネットワーク、およびCDNに限定して説明します。
Information-Centric Networking (ICN): A data-centric network architecture where accessing data by name is the essential network primitive. See [ICN-TERM] for further information.
情報中心のネットワーキング（ICN）：名前を使用してデータにアクセスすることが不可欠なネットワークプリミティブであるデータ中心のネットワークアーキテクチャ。詳細については、[ICN-TERM]を参照してください。
Network Functions Virtualization (NFV): A networking approach where network functions (e.g., firewalls or load balancers) are modularized as software logic that can run on general purpose hardware and, thus, are specifically decoupled from the previous generation of proprietary and dedicated hardware. See [RFC8568] for further information.
ネットワーク機能仮想化（NFV）：ネットワーク機能（ファイアウォールやロードバランサーなど）が、汎用ハードウェアで実行できるソフトウェアロジックとしてモジュール化されているため、前世代の専用ハードウェアと専用ハードウェアから切り離されています。詳細については、[RFC8568]を参照してください。
Software-Defined Networking (SDN): A networking approach where the control and data planes for switches are separated, allowing for realizing capabilities, such as traffic isolation and programmable forwarding actions. See [RFC7426] for further information.
Software-Defined Networking（SDN）：スイッチのコントロールプレーンとデータプレーンが分離されているネットワークアプローチで、トラフィックの分離やプログラム可能な転送アクションなどの機能を実現できます。詳細については、[RFC7426]を参照してください。
API: Application Programming Interface
API：アプリケーションプログラミングインターフェイス
BIER: Bit Index Explicit Replication
BIER：ビットインデックスの明示的なレプリケーション
BoF: Birds of a Feather (session)
BoF：Birds of a Feather（セッション）
CCNx: Content-Centric Networking
CCNx：コンテンツ中心のネットワーキング
CDN: Content Distribution Network
CDN：コンテンツ配信ネットワーク
CoAP: Constrained Application Protocol
CoAP：制約付きアプリケーションプロトコル
DASH: Dynamic Adaptive Streaming over HTTP
DASH：HTTPを介した動的適応ストリーミング
Diffserv: Differentiated Services
Diffserv：差別化されたサービス
DoS: Denial of Service
DoS：サービス拒否
DTN: Delay-Tolerant Networking
DTN：遅延耐性ネットワーク
ETSI: European Telecommunications Standards Institute
ETSI：European Telecommunications Standards Institute
EU: European Union
EU：欧州連合
FP7: 7th Framework Programme for Research and Technological Development
FP7：研究および技術開発のための第7フレームワークプログラム
HLS: HTTP Live Streaming
HLS：HTTPライブストリーミング
HTTP: HyperText Transfer Protocol
HTTP：HyperText Transfer Protocol
HTTPS: HyperText Transfer Protocol Secure
HTTPS：HyperText Transfer Protocol Secure
H2020: Horizon 2020 (research program)
H2020：Horizon 2020（研究プログラム）
ICN: Information-Centric Networking
ICN：情報中心のネットワーキング
ICNRG: Information-Centric Networking Research Group
ICNRG：情報中心のネットワーキング研究グループ
IETF: Internet Engineering Task Force
IETF：Internet Engineering Task Force
IntServ: Integrated Services
IntServ：統合サービス
IoT: Internet of Things
IoT：モノのインターネット
IP: Internet Protocol
IP：インターネットプロトコル
IPv4: Internet Protocol Version 4
IPv4：インターネットプロトコルバージョン4
IPv6: Internet Protocol Version 6
IPv6：インターネットプロトコルバージョン6
IPTV: Internet Protocol Television
IPTV：インターネットプロトコルテレビ
IS-IS: Intermediate System to Intermediate System
IS-IS：中間システムから中間システム
ISP: Internet Service Provider
ISP：インターネットサービスプロバイダー
k: kilo (1000)
k：キロ（1000）
L2: Layer 2
いいえ：リアA.
LTE: Long Term Evolution (or 4th generation cellular system)
LTE：Long Term Evolution（または第4世代セルラーシステム）
MANO: Management and Orchestration
MANO：管理とオーケストレーション
MEC: Multi-access Edge Computing
MEC：マルチアクセスエッジコンピューティング
Mbps: Megabits per second
Mbps：メガビット/秒
M2M: Machine-to-Machine
M2M：Machine-to-Machine
NAP: Network Attachment Point
NAP：ネットワーク接続ポイント
NDN: Named Data Networking
NDN：名前付きデータネットワーク
NETCONF: Network Configuration Protocol
NETCONF：ネットワーク構成プロトコル
NetInf: Network of Information
Netinf：情報ネットワーク
NFD: Named Data Networking Forwarding Daemon
NFD：名前付きデータネットワーキング転送デーモン
NFV: Network Functions Virtualization
NFV：ネットワーク機能の仮想化
NICT: Japan's National Institute of Information and Communications Technology
NICT：国立情報通信技術研究所
NR: New Radio (access network for 5G)
NR：新しいラジオ（5Gのアクセスネットワーク）
OAM: Operations, Administration, and Maintenance
OAM：運用、管理、およびメンテナンス
ONAP: Open Network Automation Platform
ONAP：オープンネットワークオートメーションプラットフォーム
OSPF: Open Shortest Path First
OSPF：Open Shortest Path First
PoC: Proof of Concept (demo)
PoC：概念実証（デモ）
POINT: IP Over ICN - the better IP (project)
POINT：IP over ICN-優れたIP（プロジェクト）
qMp: Quick Mesh Project
qMp：クイックメッシュプロジェクト
QoS: Quality of Service
QoS：サービスの品質
RAM: Random Access Memory
RAM：ランダムアクセスメモリ
RAN: Radio Access Network
RAN：無線アクセスネットワーク
REST: Representational State Transfer (architecture)
REST：表現状態転送（アーキテクチャー）
RESTCONF: Representational State Transfer Configuration (protocol)
RESTCONF：表現状態転送構成（プロトコル）
RIFE: Architecture for an Internet For Everybody (project)
RIFE：万人のためのインターネットのアーキテクチャ（プロジェクト）
RIP: Routing Information Protocol
RIP：ルーティング情報プロトコル
ROM: Read-Only Memory
ROM：読み取り専用メモリ
RSVP: Resource Reservation Protocol
RSVP：リソース予約プロトコル
RTP: Real-time Transport Protocol
RTP：リアルタイム転送プロトコル
SDN: Software-Defined Networking
SDN：ソフトウェア定義ネットワーキング
SFC: Service Function Chaining
SFC：サービス機能連鎖
SLA: Service Level Agreement
SLA：サービスレベルアグリーメント
TCL: Transport Convergence Layer
TCL：トランスポートコンバージェンスレイヤー
TCP: Transmission Control Protocol
TCP：伝送制御プロトコル
UDP: User Datagram Protocol
UDP：ユーザーデータグラムプロトコル
UMOBILE: Universal Mobile-centric and Opportunistic Communications Architecture
UMOBILE：ユニバーサルモバイル中心の日和見通信アーキテクチャ
US: United States
米国：米国
USA: United States of America
アメリカ：アメリカ合衆国
VoD: Video on Demand
VoD：ビデオオンデマンド
VPN: Virtual Private Network
VPN：仮想プライベートネットワーク
WG: Working Group
WG：ワーキンググループ
YANG: Yet Another Next Generation (data modeling language)
YANG：まだ別の次世代（データモデリング言語）
5G: Fifth Generation (cellular network)
5G：第5世代（セルラーネットワーク）
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Networks
6LoWPAN：低電力ワイヤレスパーソナルエリアネットワーク上のIPv6
In this section, we present various deployment options for ICN. These are presented as "configurations" that allow for studying these options further. While this document will outline experiences with a number of these configurations (in Section 6), we will not provide an in-depth technical or commercial evaluation for any of them -- for this, we refer to existing literature in this space, such as [Tateson].
このセクションでは、ICNのさまざまな展開オプションについて説明します。これらは、これらのオプションをさらに検討できる「構成」として提示されます。このドキュメントでは、これらの構成（セクション6）での経験について概説しますが、それらの詳細な技術的または商業的評価は行いません。これについては、この分野の既存の文献を参照します。 [タテソン]。
ICN has often been described as a "clean-slate" approach with the goal to renew or replace the complete IP infrastructure of the Internet. As such, existing routing hardware and ancillary services, such as existing applications that are typically tied directly to the TCP/IP stack, are not taken for granted. For instance, a Clean-slate ICN deployment would see existing IP routers being replaced by ICN-specific forwarding and routing elements, such as NFD [NFD], CCNx routers [Jacobson], or Publish-Subscribe Internet Technology (PURSUIT) forwarding nodes [IEEE_Communications].
ICNは、インターネットの完全なIPインフラストラクチャを更新または交換することを目的とした「白紙の」アプローチとして説明されてきました。そのため、既存のルーティングハードウェアや、通常TCP / IPスタックに直接結び付けられている既存のアプリケーションなどの補助サービスは、当然のこととは見なされていません。たとえば、Clean-slate ICNの導入では、既存のIPルーターがICN固有の転送およびルーティング要素（NFD [NFD]、CCNxルーター[Jacobson]、Publish-Subscribe Internet Technology（PURSUIT）転送ノードなど）に置き換えられます。 IEEE_Communications]。
While such clean-slate replacement could be seen as exclusive for ICN deployments, some ICN approaches (e.g., [POINT]) also rely on the deployment of general infrastructure upgrades, in this case, SDN switches. Different proposals have been made for various ICN approaches to enable the operation over an SDN transport [Reed] [CONET] [C_FLOW].
このような白紙の状態での交換はICNの展開に限定されると見なすことができますが、一部のICNアプローチ（[POINT]など）は、一般的なインフラストラクチャのアップグレード（この場合はSDNスイッチ）の展開にも依存しています。 SDNトランスポート[Reed] [CONET] [C_FLOW]を介した操作を可能にするために、さまざまなICNアプローチに対してさまざまな提案が行われています。
Similar to other significant changes to the Internet routing fabric, particularly the transition from IPv4 to IPv6 or the introduction of IP multicast, this deployment configuration foresees the creation of an ICN overlay. Note that this overlay approach is sometimes, informally, also referred to as a tunneling approach. The overlay approach can be implemented directly (e.g., ICN-over-UDP), as described in [CCNx_UDP]. Alternatively, the overlay can be accomplished via ICN-in-L2-in-IP as in [IEEE_Communications], which describes a recursive layering process. Another approach used in the Network of Information (NetInf) is to define a convergence layer to map NetInf semantics to HTTP [NetInf]. Finally, [Overlay_ICN] describes an incremental approach to deploying an ICN architecture particularly well suited to SDN-based networks by also segregating ICN user- and control-plane traffic.
インターネットルーティングファブリックへの他の重要な変更、特にIPv4からIPv6への移行またはIPマルチキャストの導入と同様に、この展開構成はICNオーバーレイの作成を予測します。このオーバーレイアプローチは、非公式には、トンネリングアプローチとも呼ばれます。 [CCNx_UDP]で説明されているように、オーバーレイアプローチは直接実装できます（ICN-over-UDPなど）。別の方法として、[IEEE_Communications]のようにICN-in-L2-in-IPを介してオーバーレイを実現することもできます。これは、再帰的な階層化プロセスを説明しています。情報ネットワーク（NetInf）で使用される別のアプローチは、収束層を定義してNetInfセマンティクスをHTTP [NetInf]にマップすることです。最後に、[Overlay_ICN]は、ICNユーザートラフィックとコントロールプレーントラフィックも分離することにより、SDNベースのネットワークに特に適したICNアーキテクチャを展開するための段階的なアプローチについて説明しています。
However, regardless of the flavor, the overlay approach results in islands of ICN deployments over existing IP-based infrastructure. Furthermore, these ICN islands are typically connected to each other via ICN/IP tunnels. In certain scenarios, this requires interoperability between existing IP routing protocols (e.g., OSPF, RIP, or IS-IS) and ICN-based ones. ICN-as-an-Overlay can be deployed over the IP infrastructure in either edge or core networks. This overlay approach is thus very attractive for ICN experimentation and testing, as it allows rapid and easy deployment of ICN over existing IP networks.
ただし、フレーバーに関係なく、オーバーレイアプローチは、既存のIPベースのインフラストラクチャ上にICN展開のアイランドをもたらします。さらに、これらのICNアイランドは通常、ICN / IPトンネルを介して相互に接続されます。特定のシナリオでは、これには既存のIPルーティングプロトコル（OSPF、RIP、IS-ISなど）とICNベースのプロトコル間の相互運用性が必要です。 ICN-as-an-Overlayは、エッジネットワークまたはコアネットワークのIPインフラストラクチャ上に展開できます。したがって、このオーバーレイアプローチは、既存のIPネットワーク上でICNを迅速かつ簡単に展開できるため、ICNの実験とテストにとって非常に魅力的です。
Proposals, such as [POINT] and [White], outline the deployment option of using an ICN underlay that would integrate with existing (external) IP-based networks by deploying application-layer gateways at appropriate locations. The main reasons for such a configuration option is the introduction of ICN technology in given islands (e.g., inside a CDN or edge IoT network) to reap the benefits of native ICN, in terms of underlying multicast delivery, mobility support, fast indirection due to location independence, in-network computing, and possibly more. The underlay approach thus results in islands of native ICN deployments that are connected to the rest of the Internet through protocol conversion gateways or proxies. Routing domains are strictly separated. Outside of the ICN island, normal IP routing protocols apply. Within the ICN island, ICN-based routing schemes apply. The gateways transfer the semantic content of the messages (i.e., IP packet payload) between the two routing domains.
[POINT]や[White]などの提案は、適切な場所にアプリケーション層ゲートウェイを展開することにより、既存の（外部）IPベースのネットワークと統合するICNアンダーレイを使用する展開オプションの概要を示しています。そのような構成オプションの主な理由は、基になるマルチキャスト配信、モビリティサポート、高速インダイレクションに関するネイティブICNの利点を享受するために、特定のアイランド（たとえば、CDNまたはエッジIoTネットワーク内）にICNテクノロジーを導入することです。ロケーションの独立性、ネットワーク内コンピューティング、そしておそらくそれ以上。したがって、アンダーレイアプローチにより、プロトコル変換ゲートウェイまたはプロキシを介してインターネットの他の部分に接続されたネイティブICN展開のアイランドが生じます。ルーティングドメインは厳密に分離されています。 ICNアイランド以外では、通常のIPルーティングプロトコルが適用されます。 ICNアイランド内では、ICNベースのルーティングスキームが適用されます。ゲートウェイは、2つのルーティングドメイン間でメッセージの意味論的コンテンツ（つまり、IPパケットペイロード）を転送します。
Native ICN networks may be located at the edge of the network where the introduction of new network architectures and protocols is easier in so-called greenfield deployments. In this context, ICN is an attractive option for scenarios, such as IoT [ICN-IoT]. The integration with the current IP protocol suite takes place at an application gateway/proxy at the edge network boundary, e.g., translating incoming CoAP request/response transactions [RFC7252] into ICN message exchanges or vice versa.
ネイティブICNネットワークは、いわゆるグリーンフィールドの展開で新しいネットワークアーキテクチャとプロトコルの導入が容易になるネットワークのエッジに配置できます。このコンテキストでは、ICNはIoT [ICN-IoT]などのシナリオにとって魅力的なオプションです。現在のIPプロトコルスイートとの統合は、エッジネットワーク境界のアプリケーションゲートウェイ/プロキシで行われます。たとえば、着信CoAP要求/応答トランザクション[RFC7252]をICNメッセージ交換に、またはその逆に変換します。
The work in [VSER] positions ICN as an edge service gateway driven by a generalized ICN-based service orchestration system with its own compute and network virtualization controllers to manage an ICN infrastructure. The platform also offers service discovery capabilities to enable user applications to discover appropriate ICN service gateways. To exemplify a scenario in a use case, the [VSER] platform shows the realization of a multi-party audio/video conferencing service over such an edge cloud deployment of ICN routers realized over commodity hardware platforms. This platform has also been extended to offer seamless mobility as a service that [VSER-Mob] features.
[VSER]での作業により、ICNは、ICNインフラストラクチャを管理するための独自のコンピューティングおよびネットワーク仮想化コントローラーを備えた、汎用ICNベースのサービスオーケストレーションシステムによって駆動されるエッジサービスゲートウェイとして位置付けられます。このプラットフォームは、ユーザーアプリケーションが適切なICNサービスゲートウェイを検出できるようにするサービス検出機能も提供します。ユースケースのシナリオを例示するために、[VSER]プラットフォームは、汎用ハードウェアプラットフォーム上で実現されるICNルーターのこのようなエッジクラウド展開でのマルチパーティオーディオ/ビデオ会議サービスの実現を示しています。このプラットフォームは、[VSER-Mob]が特徴とするサービスとしてシームレスなモビリティを提供するように拡張されています。
In this suboption, a core network would utilize edge-based protocol mapping onto the native ICN underlay. For instance, [POINT] proposes to map HTTP transactions or some other IP-based transactions, such as CoAP, directly onto an ICN-based message exchange. This mapping is realized at the NAP, for example, in access points or customer premise equipment, which, in turn, provides a standard IP interface to existing user devices. Thus, the NAP provides the apparent perception of an IP-based core network toward any external peering network.
このサブオプションでは、コアネットワークは、ネイティブICNアンダーレイへのエッジベースのプロトコルマッピングを利用します。たとえば、[POINT]は、HTTPトランザクションまたは他のIPベースのトランザクション（CoAPなど）をICNベースのメッセージ交換に直接マッピングすることを提案しています。このマッピングは、NAPで、たとえば、アクセスポイントや顧客宅内機器で実現され、既存のユーザーデバイスへの標準IPインターフェイスを提供します。したがって、NAPは、IPベースのコアネットワークを外部のピアリングネットワークに向けた見かけの認識を提供します。
The work in [White] proposes a similar deployment configuration. There, the goal is to use ICN for content distribution within CDN server farms. Specifically, the protocol mapping is realized at the ingress of the server farm where the HTTP-based retrieval request is served, while the response is delivered through a suitable egress node translation.
[White]の作品は、同様のデプロイメント構成を提案しています。そこでの目標は、CDNサーバーファーム内のコンテンツ配信にICNを使用することです。具体的には、プロトコルマッピングは、HTTPベースの取得要求が処理されるサーバーファームの入口で実現され、応答は適切な出口ノード変換を通じて配信されます。
The objective of network slicing [NGMN-5G] is to multiplex a general pool of compute, storage, and bandwidth resources among multiple service networks with exclusive SLA requirements on transport and compute-level QoS and security. This is enabled through NFV and SDN technology functions that enable functional decomposition (hence, modularity, independent scalability of control, and/or the user-plane functions), agility, and service-driven programmability. Network slicing is often associated with 5G but is clearly not limited to such systems. However, from a 5G perspective, the definition of slicing includes access networks enabling dynamic slicing of the spectrum resources among various services, hence naturally extending itself to end points and cloud resources across multiple domains, to offer end-to-end guarantees. Once instantiated, these slices could include a mix of connectivity services (e.g., LTE-as-a-service), Over-the-Top (OTT) services (e.g., VoD), or other IoT services through composition of a group of virtual and/or physical network functions at the control-, user-, and service-plane levels. Such a framework can also be used to realize ICN slices with its own control and forwarding plane, over which one or more end-user services can be delivered [NGMN-Network-Slicing].
ネットワークスライシング[NGMN-5G]の目的は、トランスポートおよびコンピューティングレベルのQoSおよびセキュリティに関する排他的なSLA要件を備えた複数のサービスネットワーク間で、コンピューティング、ストレージ、および帯域幅リソースの一般的なプールを多重化することです。これは、機能分解（したがって、モジュール性、制御の独立したスケーラビリティ、ユーザープレーン機能、あるいはその両方）、俊敏性、およびサービス駆動型プログラミングを可能にするNFVおよびSDNテクノロジ機能によって実現されます。多くの場合、ネットワークスライスは5Gに関連していますが、このようなシステムに限定されないことは明らかです。ただし、5Gの観点から見ると、スライシングの定義には、さまざまなサービス間でスペクトルリソースを動的にスライシングできるようにするアクセスネットワークが含まれるため、エンドツーエンドの保証を提供するために、エンドポイントとクラウドリソースに複数のドメインに自然に拡張されます。インスタンス化されると、これらのスライスには、接続サービス（サービスとしてのLTEなど）、オーバーザトップ（OTT）サービス（たとえば、VoD）、または仮想グループの構成による他のIoTサービスの組み合わせが含まれる可能性があります。および/またはコントロール、ユーザー、およびサービスプレーンレベルでの物理ネットワーク機能。そのようなフレームワークを使用して、独自の制御プレーンと転送プレーンを備えたICNスライスを実現することもできます。これにより、1つ以上のエンドユーザーサービスを提供できます[NGMN-Network-Slicing]。
The 5G next generation architecture [fiveG-23501] provides the flexibility to deploy the ICN-as-a-Slice over either the edge (RAN) or mobile core network; otherwise, the ICN-as-a-Slice may be deployed end to end. Further discussions on extending the architecture presented in [fiveG-23501] and the corresponding procedures in [fiveG-23502] to support ICN has been provided in [ICN-5GC]. The document elaborates on two possible approaches to enable ICN: (1) as an edge service using the local data network (LDN) feature in 5G using User Plane Function (UPF) classification functions to fast handover to the ICN forwarder and (2) as a native deployment using the non-IP Protocol Data Unit (PDU) support that would allow new network layer PDU to be handed over to ICN UPFs collocated with the Generation NodeB (gNB) functions without invoking any IP functions. While the former deployment would still rely on 3GPP-based mobility functions, the later would allow mobility to be handled natively by ICN. However, both these deployment modes should benefit from other ICN features, such as in-network caching and computing. Associated with this ICN user-plane enablement, control-plane extensions are also proposed leveraging 5th Generation Core Network (5GC)'s interface to other application functions (AFs) to allow new network service-level programmability. Such a generalized network slicing framework should be able to offer service slices over both IP and ICN. Coupled with the view of ICN functions as being "service function chaining" [RFC7665], an ICN deployment within such a slice could also be realized within the emerging control plane that is targeted for adoption in future (e.g., 5G mobile) network deployments. Finally, it should be noted that ICN is not creating the network slice but instead that the slice is created to run a 5G-ICN instance [Ravindran].
5G次世代アーキテクチャ[fiveG-23501]は、エッジ（RAN）またはモバイルコアネットワークのいずれかにICN-as-a-Sliceを展開する柔軟性を提供します。それ以外の場合は、ICN-as-a-Sliceをエンドツーエンドで展開できます。 [fiveG-23501]で提示されたアーキテクチャの拡張と、[fiveG-23502]での対応する手順によるICNのサポートに関するさらなる議論は、[ICN-5GC]で提供されています。このドキュメントでは、ICNを有効にする2つの可能なアプローチについて詳しく説明します。（1）ICNフォワーダーへの高速ハンドオーバーにユーザープレーン機能（UPF）分類関数を使用する5Gのローカルデータネットワーク（LDN）機能を使用するエッジサービスとして、および（2）非IPプロトコルデータユニット（PDU）サポートを使用するネイティブ展開。これにより、新しいネットワークレイヤーPDUを、IP機能を呼び出さずにジェネレーションノードB（gNB）機能と同じ場所にあるICN UPFに引き渡すことができます。前者の配置は3GPPベースのモビリティ機能に依拠しますが、後者はモビリティがICNによってネイティブに処理されることを可能にします。ただし、これらの展開モードはどちらも、ネットワーク内キャッシュやコンピューティングなどの他のICN機能の恩恵を受けるはずです。このICNユーザープレーンの有効化に関連して、コントロールプレーン拡張は、第5世代コアネットワーク（5GC）のインターフェイスを他のアプリケーション機能（AF）に活用して、新しいネットワークサービスレベルのプログラマビリティを可能にすることも提案されています。このような一般化されたネットワークスライスフレームワークは、IPとICNの両方でサービススライスを提供できる必要があります。 ICN機能を「サービス機能チェーニング」[RFC7665]と見なすことと相まって、このようなスライス内のICN展開は、将来の（5Gモバイルなど）ネットワーク展開での採用を対象とする新しいコントロールプレーン内でも実現できます。最後に、ICNがネットワークスライスを作成するのではなく、5G-ICNインスタンス[Ravindran]を実行するためにスライスが作成されることに注意してください。
At the level of the specific technologies involved, such as ONAP [ONAP] (which can be used to orchestrate slices), the 5G-ICN slice requires compatibility, for instance, at the level of the forwarding/ data plane depending on if it is realized as an overlay or using programmable data planes. With SDN emerging for new network deployments, some ICN approaches will need to integrate as a data-plane forwarding function with SDN, as briefly discussed in Section 4.1. Further cross-domain ICN slices can also be realized using frameworks, such as [ONAP].
ONAP [ONAP]（スライスのオーケストレーションに使用できる）などの特定のテクノロジのレベルでは、5G-ICNスライスは、たとえば、転送/データプレーンのレベルで、オーバーレイとして、またはプログラム可能なデータプレーンを使用して実現されます。 4.1節で簡単に説明したように、新しいネットワーク導入のためにSDNが出現しているため、一部のICNアプローチはデータプレーン転送機能としてSDNと統合する必要があります。 [ONAP]などのフレームワークを使用して、クロスドメインICNスライスをさらに実現することもできます。
Some deployments do not clearly correspond to any of the previously defined basic configurations of (1) Clean-slate ICN, (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, and (4) ICN-as-a-Slice. Or, a deployment may contain a composite mixture of the properties of these basic configurations. For example, the Hybrid ICN [H-ICN_1] approach carries ICN names in existing IPv6 headers and does not have distinct gateways or tunnels connecting ICN islands or any other distinct feature identified in the previous basic configurations. So we categorize Hybrid ICN and other approaches that do not clearly correspond to one of the other basic configurations as a Composite-ICN approach.
一部の展開は、（1）Clean-slate ICN、（2）ICN-as-an-Overlay、（3）ICN-as-an-Underlay、および（4）ICNの以前に定義された基本構成のいずれにも明確に対応していません。 -スライスとして。または、デプロイメントには、これらの基本構成のプロパティの複合的な混合が含まれる場合があります。たとえば、ハイブリッドICN [H-ICN_1]アプローチでは、既存のIPv6ヘッダーにICN名が含まれ、ICNアイランドを接続する個別のゲートウェイやトンネル、または以前の基本構成で特定されたその他の個別の機能はありません。したがって、ハイブリッドICNと、他の基本構成の1つに明確に対応していない他のアプローチを、複合ICNアプローチとして分類します。
We now focus on the various migration paths that will have importance to the various stakeholders that are usually involved in the deployment of ICN networks. We can identify these stakeholders as:
ここでは、ICNネットワークの展開に通常関与するさまざまな利害関係者にとって重要となるさまざまな移行パスに焦点を当てます。これらの利害関係者は次のように特定できます。
* application providers
* アプリケーションプロバイダー
* ISPs and service providers, both as core and access network providers, as well as ICN network providers
* コアおよびアクセスネットワークプロバイダーとしてのISPとサービスプロバイダー、およびICNネットワークプロバイダー
* CDN providers (due to the strong relation of the ICN proposition to content delivery)
* CDNプロバイダー（ICNの提案とコンテンツ配信の強い関係による）
* end-device manufacturers and users
* エンドデバイスのメーカーとユーザー
Our focus is on technological aspects of such migration. Economic or regulatory aspects, such as those studied in [Tateson], [Techno_Economic], and [Internet_Pricing], are left out of our discussion.
私たちの焦点は、そのような移行の技術的側面にあります。 [Tateson]、[Techno_Economic]、および[Internet_Pricing]で研究されているような経済的または規制的側面は、ここでは取り上げません。
The Internet supports a multitude of applications and services using the many protocols defined over the packet-level IP service. HTTP provides one convergence point for these services with many web development frameworks based on the semantics provided by it. In recent years, even services such as video delivery have been migrating from the traditional RTP-over-UDP delivery to the various HTTP-level streaming solutions, such as DASH [DASH] and others. Nonetheless, many non-HTTP services exist, all of which need consideration when migrating from the IP-based Internet to an ICN-based one.
インターネットは、パケットレベルのIPサービスで定義された多くのプロトコルを使用して、多数のアプリケーションとサービスをサポートしています。 HTTPは、これらのサービスに1つの収束ポイントを提供し、HTTPが提供するセマンティクスに基づいた多くのWeb開発フレームワークを備えています。近年、ビデオ配信などのサービスでさえ、従来のRTP-over-UDP配信から、DASH [DASH]などのさまざまなHTTPレベルのストリーミングソリューションに移行しています。それにもかかわらず、多くの非HTTPサービスが存在し、IPベースのインターネットからICNベースのインターネットに移行する場合、それらすべてを考慮する必要があります。
The underlay deployment configuration option presented in Section 4.3 aims at providing some level of compatibility to the existing ecosystem through a proxy-based message flow mapping mechanism (e.g., mapping of existing HTTP/TCP/IP message flows to HTTP/ICN message flows). A related approach of mapping TCP/IP to TCP/ICN message flows is described in [Moiseenko]. Another approach described in [Marchal] uses HTTP/NDN gateways and focuses, in particular, on the right strategy to map HTTP to NDN to guarantee a high level of compatibility with HTTP while enabling an efficient caching of data in the ICN island. The choice of approach is a design decision based on how to configure the protocol stack. For example, the approach described in [Moiseenko] carries the TCP layer into the ICN underlay, while the [Marchal] approach terminates both HTTP and TCP at the edge of the ICN underlay and maps these functionalities onto existing ICN functionalities.
セクション4.3に示すアンダーレイデプロイメント構成オプションは、プロキシベースのメッセージフローマッピングメカニズム（既存のHTTP / TCP / IPメッセージフローからHTTP / ICNメッセージフローへのマッピングなど）を通じて既存のエコシステムにある程度の互換性を提供することを目的としています。 TCP / IPをTCP / ICNメッセージフローにマッピングする関連するアプローチは、[Moiseenko]で説明されています。 [Marchal]で説明されている別のアプローチは、HTTP / NDNゲートウェイを使用し、特に適切な戦略に焦点を当てて、HTTPをNDNにマップして、ICNアイランドでのデータの効率的なキャッシュを可能にすると同時に、HTTPとの高レベルの互換性を保証します。アプローチの選択は、プロトコルスタックの構成方法に基づく設計上の決定です。たとえば、[Moiseenko]で説明されているアプローチでは、TCPレイヤーがICNアンダーレイに組み込まれ、[Marchal]アプローチでは、ICNアンダーレイのエッジでHTTPとTCPの両方が終端され、これらの機能が既存のICN機能にマッピングされます。
Alternatively, ICN-as-an-Overlay (Section 4.2) and ICN-as-a-Slice (Section 4.4) allow for the introduction of the full capabilities of ICN through new application/service interfaces, as well as operations in the network. With that, these approaches of deployment are likely to aim at introducing new application/services capitalizing on those ICN capabilities, such as in-network multicast and/or caching.
または、ICN-as-an-Overlay（セクション4.2）およびICN-as-a-Slice（セクション4.4）を使用すると、ネットワークでの操作だけでなく、新しいアプリケーション/サービスインターフェイスを通じてICNの全機能を導入できます。これにより、これらの展開アプローチは、ネットワーク内マルチキャストやキャッシングなどのICN機能を利用した新しいアプリケーション/サービスの導入を目的とする可能性があります。
Finally, [ICN-LTE-4G] outlines a dual-stack end-user device approach that is applicable for all deployment configurations. Specifically, it introduces middleware layers (called the TCL) in the device that will dynamically adapt existing applications to either an underlying ICN protocol stack or standard IP protocol stack. This involves end device signaling with the network to determine which protocol stack instance and associated middleware adaptation layers to utilize for a given application transaction.
最後に、[ICN-LTE-4G]は、すべての展開構成に適用できるデュアルスタックエンドユーザーデバイスアプローチの概要を示しています。具体的には、既存のアプリケーションを基盤となるICNプロトコルスタックまたは標準IPプロトコルスタックのいずれかに動的に適合させるミドルウェアレイヤー（TCLと呼ばれる）をデバイスに導入します。これには、特定のアプリケーショントランザクションに使用するプロトコルスタックインスタンスと関連するミドルウェア適応層を決定するための、ネットワークとのエンドデバイスシグナリングが含まれます。
A significant number of services and applications are devoted to content delivery in some form, e.g., as video delivery, social media platforms, and many others. CDNs are deployed to assist these services through localizing the content requests and therefore reducing latency and possibly increasing utilization of available bandwidth, as well as reducing the load on origin servers. Similar to the previous subsection, the underlay deployment configuration presented in Section 4.3 aims at providing a migration path for existing CDNs. This is also highlighted in a BIER use-case document [BIER], specifically with potential benefits in terms of utilizing multicast in the delivery of content but also reducing load on origin and delegation servers. We return to this benefit in the trial experiences in Section 6.
相当数のサービスとアプリケーションが、ビデオ配信、ソーシャルメディアプラットフォームなど、何らかの形でコンテンツ配信に専念しています。 CDNは、コンテンツ要求をローカライズしてこれらのサービスを支援するために導入され、レイテンシを削減し、使用可能な帯域幅の使用率を増加させ、オリジンサーバーの負荷を軽減します。前のサブセクションと同様に、セクション4.3で紹介したアンダーレイデプロイメント構成は、既存のCDNの移行パスを提供することを目的としています。これは、BIERのユースケースドキュメント[BIER]でも強調表示されています。特に、コンテンツの配信にマルチキャストを利用するという点で潜在的な利点がありますが、配信元サーバーと委任サーバーの負荷も軽減されます。セクション6のトライアル体験で、このメリットに戻ります。
Edge networks often see the deployment of novel network-level technology, e.g., in the space of IoT. For many years, such IoT deployments have relied, and often still do, on proprietary protocols for reasons, such as increased efficiency, lack of standardization incentives, and others. Utilizing the underlay deployment configuration in Section 4.3.1, application gateways/proxies can integrate such edge deployments into IP-based services, e.g., utilizing CoAP-based [RFC7252] M2M platforms, such as oneM2M [oneM2M] or others.
エッジネットワークでは、IoTの分野など、斬新なネットワークレベルのテクノロジーの導入がよく見られます。長年にわたり、このようなIoTの展開は、効率の向上、標準化のインセンティブの欠如などの理由により、独自のプロトコルに依存しており、依然として依然としてそうであることがよくあります。セクション4.3.1のアンダーレイ展開構成を利用して、アプリケーションゲートウェイ/プロキシは、このようなエッジ展開をIPベースのサービスに統合できます。たとえば、oneM2M [oneM2M]などのCoAPベースの[RFC7252] M2Mプラットフォームを利用できます。
Another area of increased edge network innovation is that of mobile (access) networks, particularly in the context of the 5G mobile networks. Network softwarization (using technologies like service orchestration frameworks leveraging NFV and SDN concepts) are now common in access networks and other network segments. Therefore, the ICN-as-a-Slice deployment configuration in Section 4.4 provides a suitable migration path for the integration of non-IP-based edge networks into the overall system by virtue of realizing the relevant (ICN) protocols in an access network slice.
エッジネットワークのイノベーションが増加しているもう1つの分野は、モバイル（アクセス）ネットワークの分野であり、特に5Gモバイルネットワークに関連しています。 （NFVおよびSDNの概念を活用するサービスオーケストレーションフレームワークなどのテクノロジーを使用した）ネットワークソフトウォーライゼーションは、アクセスネットワークやその他のネットワークセグメントで一般的になりました。したがって、セクション4.4のICN-as-a-Slice展開構成は、アクセスネットワークスライスで関連する（ICN）プロトコルを実現することにより、非IPベースのエッジネットワークをシステム全体に統合するための適切な移行パスを提供します。 。
With the advent of SDN and NFV capabilities, so-called campus or site-specific deployments could see the introduction of ICN islands at the edge for scenarios such as gaming or deployments based on Augmented Reality (AR) / Virtual Reality (VR), e.g., smart cities or theme parks.
SDNおよびNFV機能の登場により、いわゆるキャンパスまたはサイト固有の展開では、拡張現実（AR）/仮想現実（VR）に基づくゲームや展開などのシナリオで、エッジにICNアイランドが導入される可能性があります。 、スマートシティ、テーマパーク。
Migrating core networks of the Internet or mobile networks requires not only significant infrastructure renewal but also the fulfillment of the key performance requirements, particularly in terms of throughput. For those parts of the core network that would migrate to an SDN-based optical transport, the ICN-as-a-Slice deployment configuration in Section 4.4 would allow the introduction of native ICN solutions within slices. This would allow for isolating the ICN traffic while addressing the specific ICN performance benefits (such as in-network multicast or caching) and constraints (such as the need for specific network elements within such isolated slices). For ICN solutions that natively work on top of SDN, the underlay deployment configuration in Section 4.3.2 provides an additional migration path, preserving the IP-based services and applications at the edge of the network while realizing the core network routing through an ICN solution (possibly itself realized in a slice of the SDN transport network).
インターネットまたはモバイルネットワークのコアネットワークを移行するには、インフラストラクチャを大幅に更新するだけでなく、特にスループットの観点から、主要なパフォーマンス要件を満たす必要があります。 SDNベースの光トランスポートに移行するコアネットワークの部分については、セクション4.4のICN-as-a-Sliceデプロイメント構成により、スライス内にネイティブICNソリューションを導入できます。これにより、特定のICNパフォーマンスの利点（ネットワーク内のマルチキャストやキャッシュなど）と制約（このような分離されたスライス内の特定のネットワーク要素の必要性など）に対処しながら、ICNトラフィックを分離できます。 SDNの上でネイティブに機能するICNソリューションの場合、セクション4.3.2のアンダーレイ展開構成は追加の移行パスを提供し、ICNソリューションを通じてコアネットワークルーティングを実現しながら、ネットワークのエッジでIPベースのサービスとアプリケーションを維持します（おそらく、それ自体がSDNトランスポートネットワークのスライスで実現されます）。
In this section, we will outline trial experiences, often conducted within collaborative project efforts. Our focus here is on the realization of the various deployment configurations identified in Section 4; therefore, we categorize the trial experiences according to these deployment configurations. While a large body of work exists at the simulation or emulation level, we specifically exclude these studies from our analysis to retain the focus on real-life experiences.
このセクションでは、多くの場合、共同プロジェクトの取り組みの中で行われる試験的な体験の概要を説明します。ここでの焦点は、セクション4で識別されたさまざまなデプロイメント構成の実現にあります。したがって、これらの展開構成に従って、試用エクスペリエンスを分類します。シミュレーションまたはエミュレーションレベルでは大量の作業が存在しますが、実際の経験に焦点を当て続けるために、これらの研究を分析から明確に除外しています。
Although the FP7 PURSUIT [IEEE_Communications] efforts were generally positioned as a Clean-slate ICN replacement of IP (Section 4.1), the project realized its experimental testbed as an L2 VPN-based overlay between several European, US, and Asian sites, following the overlay deployment configuration presented in Section 4.2. Software-based forwarders were utilized for the ICN message exchange, while native ICN applications (e.g., for video transmissions) were showcased. At the height of the project efforts, about 70+ nodes were active in the (overlay) network with presentations given at several conferences, as well as to the ICNRG.
FP7 PURSUIT [IEEE_Communications]の取り組みは、一般にIPの白紙のICNの置き換えとして位置付けられていましたが（セクション4.1）、プロジェクトは、実験的なテストベッドを、ヨーロッパ、米国、アジアのいくつかのサイト間のL2 VPNベースのオーバーレイとして実現しました。セクション4.2に示すオーバーレイのデプロイメント構成。ソフトウェアベースのフォワーダーがICNメッセージ交換に利用され、ネイティブのICNアプリケーション（ビデオ送信など）が紹介されました。プロジェクトの取り組みの最中、約70以上のノードが（オーバーレイ）ネットワークでアクティブで、複数の会議やICNRGでプレゼンテーションが行われました。
The Network of Information (NetInf) is the approach to ICN developed by the EU FP7 Scalable and Adaptive Internet Solutions (SAIL) project [SAIL]. NetInf provides both name-based forwarding with CCNx-like semantics and name resolution (for indirection and late binding). The NetInf architecture supports different deployment options through its convergence layer, such as using UDP, HTTP, and even DTN underlays. In its first prototypes and trials, NetInf was deployed mostly in an HTTP embedding and in a UDP overlay following the overlay deployment configuration in Section 4.2. [SAIL_Prototyping] describes several trials, including a stadium environment and a multi-site testbed, leveraging NetInf's routing hint approach for routing scalability [SAIL_Content_Delivery].
情報ネットワーク（NetInf）は、EU FP7スケーラブルおよび適応型インターネットソリューション（SAIL）プロジェクト[SAIL]によって開発されたICNへのアプローチです。 NetInfは、CCNxのようなセマンティクスを使用した名前ベースの転送と名前解決（間接指定と遅延バインディング用）の両方を提供します。 NetInfアーキテクチャは、UDP、HTTP、さらにはDTNアンダーレイの使用など、コンバージェンスレイヤーを通じてさまざまな展開オプションをサポートしています。最初のプロトタイプとトライアルでは、NetInfは、セクション4.2のオーバーレイ展開構成に従って、主にHTTP埋め込みとUDPオーバーレイに展開されました。 [SAIL_Prototyping]は、スタジアム環境やマルチサイトテストベッドなど、ルーティングのスケーラビリティ[SAIL_Content_Delivery]にNetInfのルーティングヒントアプローチを活用したいくつかのトライアルについて説明しています。
The Named Data Networking (NDN) is one of the research projects of the National Science Foundation (NSF) of the USA as part of the Future Internet Architecture (FIA) Program. The original NDN proposal was positioned as a Clean-slate ICN replacement of IP (Section 4.1). However, in several trials, NDN generally follows the overlay deployment configuration of Section 4.2 to connect institutions over the public Internet across several continents. The use cases covered in the trials include real-time videoconferencing, geolocating, and interfacing to consumer applications. Typical trials involve up to 100 NDN-enabled nodes [NDN-testbed] [Jangam].
Named Data Networking（NDN）は、Future Internet Architecture（FIA）Programの一環として、米国のNational Science Foundation（NSF）の研究プロジェクトの1つです。元のNDN提案は、IPのClean-slate ICNの置き換えとして位置付けられていました（セクション4.1）。ただし、いくつかの試験では、NDNは一般的にセクション4.2のオーバーレイ展開構成に従って、複数の大陸にまたがる公共のインターネットを介して機関を接続します。トライアルでカバーされるユースケースには、リアルタイムのビデオ会議、地理位置情報、および消費者アプリケーションへのインターフェースが含まれます。典型的な試験には、最大100のNDN対応ノード[NDN-testbed] [Jangam]が含まれます。
ICN2020 is an ICN-related project of the EU H2020 research program and NICT [ICN2020-overview]. ICN2020 has a specific focus to advance ICN towards real-world deployments through applications, such as video delivery, interactive videos, and social networks. The federated testbed spans the USA, Europe, and Japan. Both NDN and CCNx approaches are within the scope of the project.
ICN2020は、EU H2020研究プログラムとNICTのICN関連プロジェクトです[ICN2020の概要]。 ICN2020は、ビデオ配信、インタラクティブビデオ、ソーシャルネットワークなどのアプリケーションを通じて、ICNを実際の展開に向けて発展させることに特に重点を置いています。連合テストベッドは、米国、ヨーロッパ、および日本にまたがっています。 NDNとCCNxの両方のアプローチは、プロジェクトの範囲内です。
ICN2020 has released a set of interim public technical reports. The report [ICN2020-Experiments] contains a detailed description of the progress made in both local testbeds and federated testbeds. The plan for the federated testbed includes integrating the NDN testbed, the CUTEi testbed [RFC7945] [CUTEi], and the GEANT testbed [GEANT] to create an overlay deployment configuration of Section 4.2 over the public Internet. The total network contains 37 nodes. Since video was an important application, typical throughput was measured in certain scenarios and found to be in the order of 70 Mbps per node.
ICN2020は一連の暫定公開技術レポートをリリースしました。レポート[ICN2020-Experiments]には、ローカルテストベッドとフェデレーションテストベッドの両方で行われた進捗状況の詳細な説明が含まれています。フェデレーテッドテストベッドの計画には、NDNテストベッド、CUTEiテストベッド[RFC7945] [CUTEi]、およびGEANTテストベッド[GEANT]を統合して、パブリックインターネット上でセクション4.2のオーバーレイ展開構成を作成することが含まれます。ネットワーク全体には37ノードが含まれます。ビデオは重要なアプリケーションであるため、通常のスループットは特定のシナリオで測定され、ノードあたり70 Mbpsのオーダーであることがわかりました。
UMOBILE is another of the ICN research projects under the H2020 research program [UMOBILE-overview]. The UMOBILE architecture integrates the principles of DTN and ICN in a common framework to support edge computing and mobile opportunistic wireless environments (e.g., post-disaster scenarios and remote areas). The UMOBILE architecture [UMOBILE-2] was developed on top of the NDN framework by following the overlay deployment configuration of Section 4.2. UMOBILE aims to extend Internet functionally by combining ICN and DTN technologies.
UMOBILEは、H2020研究プログラム[UMOBILE-overview]に基づくICN研究プロジェクトの1つです。 UMOBILEアーキテクチャは、DTNとICNの原則を共通のフレームワークに統合して、エッジコンピューティングとモバイルの日和見的なワイヤレス環境（災害後のシナリオやリモートエリアなど）をサポートします。 UMOBILEアーキテクチャ[UMOBILE-2]は、セクション4.2のオーバーレイ展開構成に従って、NDNフレームワークの上に開発されました。 UMOBILEは、ICN技術とDTN技術を組み合わせることにより、インターネットを機能的に拡張することを目指しています。
One of the key aspects of UMOBILE was the extension of the NDN framework to locate network services (e.g., mobility management and intermittent connectivity support) and user services (e.g., pervasive content management) as close as possible to the end users to optimize bandwidth utilization and resource management. Another aspect was the evolution of the NDN framework to operate in challenging wireless networks, namely in emergency scenarios [UMOBILE-3] and environments with intermittent connectivity. To achieve this, the NDN framework was leveraged with a new messaging application called Oi! [UMOBILE-4] [UMOBILE-5], which supports intermittent wireless networking. UMOBILE also implements a new data-centric wireless routing protocol, DABBER [UMOBILE-6] [DABBER], which was designed based on data reachability metrics that take availability of adjacent wireless nodes and different data sources into consideration. The contextual awareness of the wireless network operation is obtained via a machine-learning agent running within the wireless nodes [UMOBILE-7].
UMOBILEの主要な側面の1つは、NDNフレームワークを拡張して、ネットワークサービス（たとえば、モビリティ管理や断続的な接続サポート）とユーザーサービス（たとえば、広範囲にわたるコンテンツ管理）をエンドユーザーのできるだけ近くに配置して、帯域幅の使用率を最適化することでした。とリソース管理。もう1つの側面は、困難なワイヤレスネットワーク、つまり緊急シナリオ[UMOBILE-3]および断続的な接続環境で動作するNDNフレームワークの進化でした。これを達成するために、NDNフレームワークはOi！と呼ばれる新しいメッセージングアプリケーションで活用されました。 [UMOBILE-4] [UMOBILE-5]は、断続的なワイヤレスネットワークをサポートします。 UMOBILEは、新しいデータ中心のワイヤレスルーティングプロトコルであるDABBER [UMOBILE-6] [DABBER]も実装します。DABBER[UMOBILE-6] [DABBER]は、隣接するワイヤレスノードと異なるデータソースの可用性を考慮したデータ到達可能性メトリックに基づいて設計されました。ワイヤレスネットワーク操作のコンテキスト認識は、ワイヤレスノード内で実行されている機械学習エージェントによって取得されます[UMOBILE-7]。
The consortium has completed several ICN deployment trials. In a post-disaster scenario trial [UMOBILE-8], a special DTN face was created to provide reachability to remote areas where there is no typical Internet connection. Another trial was the ICN deployment over the "Guifi.net" community network in the Barcelona region. This trial focused on the evaluation of an ICN edge computing platform, called PiCasso [UMOBILE-9]. In this trial, ten (10) Raspberry Pis were deployed across Barcelona to create an ICN overlay network on top of the existing IP routing protocol (e.g., qMp routing). This trial showed that ICN can play a key role in improving data delivery QoS and reducing the traffic in intermittent connectivity environments (e.g., wireless community network). A third trial in Italy was focused on displaying the capability of the UMOBILE architecture to reach disconnected areas and assist responsible authorities in emergencies, corresponding to an infrastructure scenario. The demonstration encompassed seven (7) end-user devices, one (1) access point, and one (1) gateway.
コンソーシアムはいくつかのICN展開トライアルを完了しました。災害後のシナリオのトライアル[UMOBILE-8]では、特別なDTN面が作成され、通常のインターネット接続がない遠隔地への到達可能性が提供されています。もう1つの試みは、バルセロナ地域での「Guifi.net」コミュニティネットワークを介したICNの展開でした。このトライアルは、PiCasso [UMOBILE-9]と呼ばれるICNエッジコンピューティングプラットフォームの評価に焦点を当てました。このトライアルでは、既存のIPルーティングプロトコル（qMpルーティングなど）の上にICNオーバーレイネットワークを作成するために、バルセロナ全体に10個のRaspberry Piが配備されました。この試験は、ICNがデータ配信のQoSを改善し、断続的な接続環境（ワイヤレスコミュニティネットワークなど）のトラフィックを削減する上で重要な役割を果たすことを示しました。イタリアでの3番目の試験は、インフラストラクチャシナリオに対応する、UMOBILEアーキテクチャが接続されていない領域に到達し、緊急時に責任ある当局を支援する能力を示すことに焦点が当てられました。デモには、7つのエンドユーザーデバイス、1つのアクセスポイント、および1つのゲートウェイが含まれていました。
POINT and RIFE are two more ICN-related research projects of the H2020 research program. The efforts in the H2020 POINT and RIFE projects follow the underlay deployment configuration in Section 4.3.2; edge-based NAPs provide the IP/HTTP-level protocol mapping onto ICN protocol exchanges, while the SDN underlay (or the VPN-based L2 underlay) is used as a transport network.
POINTとRIFEは、H2020研究プログラムのさらに2つのICN関連研究プロジェクトです。 H2020 POINTおよびRIFEプロジェクトでの取り組みは、セクション4.3.2のアンダーレイ展開構成に従います。エッジベースのNAPは、ICNプロトコル交換へのIP / HTTPレベルのプロトコルマッピングを提供し、SDNアンダーレイ（またはVPNベースのL2アンダーレイ）はトランスポートネットワークとして使用されます。
The multicast and service endpoint surrogate benefit in HTTP-based scenarios, such as for HTTP-level streaming video delivery, and have been demonstrated in the deployed POINT testbed with 80+ nodes being utilized. Demonstrations of this capability have been given to the ICNRG, and public demonstrations were also provided at events [MWC_Demo]. The trial has also been accepted by the ETSI MEC group as a public proof-of-concept demonstration.
マルチキャストおよびサービスエンドポイントは、HTTPベースのシナリオ（HTTPレベルのストリーミングビデオ配信など）での利点を代理し、80以上のノードが使用されている展開されたPOINTテストベッドで実証されています。この機能のデモがICNRGに提供され、イベント[MWC_Demo]で公開デモも提供されました。この裁判はまた、ETSI MECグループによって、概念実証の公開デモとして受け入れられました。
While the aforementioned demonstrations all use the overlay deployment, H2020 also has performed ICN underlay trials. One such trial involved commercial end users located in the PrimeTel network in Cyprus with the use case centered on IPTV and HLS video dissemination. Another trial was performed over the "Guifi.net" community network in the Barcelona region, where the solution was deployed in 40 households, providing general Internet connectivity to the residents. Standard IPTV Set-Top Boxes(STBs), as well as HLS video players, were utilized in accordance with the aim of this deployment configuration, namely to provide application and service migration.
前述のデモはすべてオーバーレイ展開を使用していますが、H2020はICNアンダーレイの試験も実施しています。そのような裁判の1つには、キプロスのPrimeTelネットワークに位置する商用エンドユーザーが関与し、ユースケースはIPTVおよびHLSビデオの普及に集中していました。バルセロナ地域の「Guifi.net」コミュニティネットワークを介して別のトライアルが行われ、40世帯にソリューションが展開され、住民に一般的なインターネット接続が提供されました。標準のIPTVセットトップボックス（STB）とHLSビデオプレーヤーは、この配置構成の目的に従って、つまりアプリケーションとサービスの移行を提供するために使用されました。
The H2020 Facility for Large-Scale Adaptive Media Experimentation (FLAME) efforts concentrate on providing an experimental ground for the aforementioned POINT/RIFE solution in initially two city-scale locations, namely in Bristol and Barcelona. This trial followed the underlay deployment configuration in Section 4.3.2, as per the POINT/ RIFE approach. Experiments were conducted with the city/university joint venture Bristol-is-Open (BIO) to ensure the readiness of the city-scale SDN transport network for such experiments. Another trial was for the ETSI MEC PoC. This trial showcased operational benefits provided by the ICN underlay for the scenario of a location-based game. These benefits aim at reduced network utilization through improved video delivery performance (multicast of all captured videos to the service surrogates deployed in the city at six locations), as well as reduced latency through the play out of the video originating from the local NAP, collocated with the Wi-Fi Access Point (AP) instead of a remote server, i.e., the playout latency was bounded by the maximum single-hop latency.
H2020大規模適応メディア実験施設（FLAME）の取り組みは、前述のPOINT / RIFEソリューションの実験的な基盤を、最初は2つの都市規模の場所、つまりブリストルとバルセロナに提供することに集中しています。この試行は、POINT / RIFEアプローチに従って、セクション4.3.2のアンダーレイ展開構成に従いました。市/大学の合弁会社ブリストル・イズ・オープン（BIO）で実験が行われ、そのような実験に対する都市規模のSDNトランスポート・ネットワークの準備が整っていることが確認されました。別の試験はETSI MEC PoCでした。この試験では、ロケーションベースのゲームのシナリオでICNアンダーレイによって提供される運用上のメリットを紹介しました。これらの利点は、ビデオ配信パフォーマンスの向上（キャプチャされたすべてのビデオを6か所の都市に配置されたサービスサロゲートにマルチキャストすること）によるネットワーク使用率の削減、およびローカルNAPから発信されたビデオの再生によるレイテンシの削減つまり、リモートサーバーの代わりにWi-Fiアクセスポイント（AP）を使用します。つまり、プレイアウトのレイテンシは、シングルホップの最大レイテンシによって制限されていました。
Twenty three (23) large-scale media service experiments are planned as part of the H2020 FLAME efforts in the area of Future Media Internet (FMI). The platform, which includes the ICN capabilities, integrated with NFV and SDN capabilities of the infrastructure. The ultimate goal of these platform efforts is the full integration of ICN into the overall media function platform for the provisioning of advanced (media-centric) Internet services.
Future Media Internet（FMI）の分野におけるH2020 FLAMEの取り組みの一環として、23の大規模メディアサービス実験が計画されています。インフラストラクチャのNFVおよびSDN機能と統合されたICN機能を含むプラットフォーム。これらのプラットフォームの取り組みの最終的な目標は、高度な（メディア中心の）インターネットサービスをプロビジョニングするために、メディア機能プラットフォーム全体にICNを完全に統合することです。
The CableLabs ICN work reported in [White] proposes an underlay deployment configuration based on Section 4.3.2. The use case is ICN for content distribution within complex CDN server farms to leverage ICN's superior in-network caching properties. This CDN based on "island of ICN" is then used to service standard HTTP/IP-based content retrieval requests coming from the general Internet. This approach acknowledges that whole scale replacement (see Section 4.1) of existing HTTP/IP end-user applications and related web infrastructure is a difficult proposition. [White] is clear that the architecture proposed has not yet been tested experimentally but that implementations are in process and expected in the 3-5 year time frame.
[White]で報告されたCableLabs ICNの作業では、4.3.2に基づいてアンダーレイ展開構成を提案しています。ユースケースは、ICNの優れたネットワーク内キャッシングプロパティを活用するための複雑なCDNサーバーファーム内でのコンテンツ配信のICNです。 「ICNの島」に基づくこのCDNは、一般的なインターネットからの標準のHTTP / IPベースのコンテンツ取得要求にサービスを提供するために使用されます。このアプローチは、既存のHTTP / IPエンドユーザーアプリケーションと関連するWebインフラストラクチャの全体的な置き換え（セクション4.1を参照）は難しい命題であることを認めています。 [ホワイト]は、提案されたアーキテクチャがまだ実験的にテストされていないことは明らかですが、実装は進行中であり、3〜5年の期間で予想されます。
[Baccelli] summarizes the trial of an NDN system adapted specifically for a wireless IoT scenario. The trial was run with 60 nodes distributed over several multistory buildings in a university campus environment. The NDN protocols were optimized to run directly over 6LoWPAN wireless link layers. The performance of the NDN-based IoT system was then compared to an equivalent system running standard IP-based IoT protocols. It was found that the NDN-based IoT system was superior in several respects, including in terms of energy consumption and for RAM and ROM footprints [Baccelli] [Anastasiades]. For example, the binary file size reductions for NDN protocol stack versus standard IP-based IoT protocol stack on given devices were up to 60% less for ROM size and up to 80% less for RAM size.
[Baccelli]は、ワイヤレスIoTシナリオに特化したNDNシステムの試行を要約しています。試用版は、大学のキャンパス環境にある複数の高層ビルに分散した60ノードで実行されました。 NDNプロトコルは、6LoWPANワイヤレスリンクレイヤーで直接実行するように最適化されました。次に、NDNベースのIoTシステムのパフォーマンスを、標準のIPベースのIoTプロトコルを実行する同等のシステムと比較しました。 NDNベースのIoTシステムは、エネルギー消費やRAMおよびROMのフットプリント[Baccelli] [Anastasiades]など、いくつかの点で優れていることがわかりました。たとえば、特定のデバイスでのNDNプロトコルスタックと標準のIPベースのIoTプロトコルスタックのバイナリファイルサイズの削減は、ROMサイズで最大60％、RAMサイズで最大80％減少しました。
The National Research and Education Network (NREN) ICN Testbed is a project sponsored by Cisco, Internet2, and the US Research and Education community. Participants include universities and US federal government entities that connect via a nationwide VPN-based L2 underlay. The testbed uses the CCNx approach and is based on the [CICN] open-source software. There are approximately 15 nodes spread across the USA that connect to the testbed. The project's current focus is to advance data-intensive science and network research by improving data movement, searchability, and accessibility.
National Research and Education Network（NREN）ICN Testbedは、Cisco、Internet2、およびUS Research and Educationコミュニティが主催するプロジェクトです。参加者には、全国的なVPNベースのL2アンダーレイを介して接続する大学や米国連邦政府機関が含まれます。テストベッドはCCNxアプローチを使用し、[CICN]オープンソースソフトウェアに基づいています。テストベッドに接続する米国全体に広がる約15のノードがあります。プロジェクトの現在の焦点は、データの移動、検索性、およびアクセシビリティを改善することにより、データ集約型の科学およびネットワークの研究を進めることです。
The DOCTOR project is a French research project meaning "Deployment and Securisation of new Functionalities in Virtualized Networking Environments". The project aims to run NDN over virtualized NFV infrastructure [Doctor] (based on Docker technology) and focuses on the NFV MANO aspects to build an operational NDN network focusing on important performance criteria, such as security, performance, and interoperability.
DOCTORプロジェクトはフランスの研究プロジェクトで、「仮想化ネットワーク環境における新機能の導入とセキュリティ化」を意味します。このプロジェクトは、仮想化されたNFVインフラストラクチャ[Doctor]（Dockerテクノロジーに基づく）でNDNを実行することを目的とし、NFV MANOの側面に焦点を当てて、セキュリティ、パフォーマンス、相互運用性などの重要なパフォーマンス基準に焦点を当てた運用NDNネットワークを構築します。
The data plane relies on an HTTP/NDN gateway [Marchal] that processes HTTP traffic and transports it in an optimized way over NDN to benefit from the properties of the NDN island (i.e., by mapping HTTP semantics to NDN semantics within the NDN island). The testbed carries real Web traffic of users and has been currently evaluated with the top 1000 most popular websites. The users only need to set the gateway as the web proxy. The control plane relies on a central manager that uses machine-learning-based detection methods [Mai-1] from the date gathered by distributed probes and applies orchestrated countermeasures against NDN attacks [Nguyen-1] [Nguyen-2] [Mai-2] or performance issues. A remediation can be, for example, the scale up of a bottleneck component or the deployment of a security function, like a firewall or a signature verification module. Test results thus far have indicated that key attacks can be detected accurately. For example, content poisoning attacks can be detected at up to over 95% accuracy (with less than 0.01% false positives) [Nguyen-3].
データプレーンは、HTTPトラフィックを処理し、最適化された方法でNDN経由で転送するHTTP / NDNゲートウェイ[Marchal]に依存して、NDNアイランドのプロパティのメリットを享受します（つまり、HTTPセマンティクスをNDNアイランド内のNDNセマンティクスにマッピングします）。 。テストベッドは、ユーザーの実際のWebトラフィックを伝送し、現在、最も人気のある上位1000のWebサイトで評価されています。ユーザーはゲートウェイをWebプロキシとして設定するだけです。コントロールプレーンは、分散型プローブによって収集された日付から機械学習ベースの検出方法[Mai-1]を使用し、NDN攻撃に対して調整された対策を適用する中央マネージャーに依存します[Nguyen-1] [Nguyen-2] [Mai-2 ]またはパフォーマンスの問題。修正は、たとえば、ボトルネックコンポーネントのスケールアップや、ファイアウォールや署名検証モジュールなどのセキュリティ機能の導入です。これまでのテスト結果では、主要な攻撃を正確に検出できることが示されています。たとえば、コンテンツポイズニング攻撃は、最大95％の精度で検出できます（0.01％未満の誤検知）[Nguyen-3]。
Hybrid ICN [H-ICN_1] [H-ICN_2] is an approach where the ICN names are mapped to IPv6 addresses and other ICN information is carried as payload inside the IP packet. This allows standard (ICN-unaware) IP routers to forward packets based on IPv6 info but enables ICN-aware routers to apply ICN semantics. The intent is to enable rapid hybrid deployments and seamless interconnection of IP and Hybrid ICN domains. Hybrid ICN uses [CICN] open-source software. Initial tests have been done with 150 clients consuming DASH videos, which showed good scalability properties at the server side using the Hybrid ICN transport [H-ICN_3] [H-ICN_2].
ハイブリッドICN [H-ICN_1] [H-ICN_2]は、ICN名がIPv6アドレスにマップされ、他のICN情報がIPパケット内のペイロードとして運ばれるアプローチです。これにより、標準（ICN非対応）IPルーターはIPv6情報に基づいてパケットを転送できますが、ICN対応ルーターはICNセマンティクスを適用できます。その目的は、IPとハイブリッドICNドメインの迅速なハイブリッド展開とシームレスな相互接続を可能にすることです。ハイブリッドICNは、[CICN]オープンソースソフトウェアを使用します。初期テストは、DASHビデオを消費する150のクライアントで行われ、ハイブリッドICNトランスポート[H-ICN_3] [H-ICN_2]を使用してサーバー側で優れたスケーラビリティプロパティを示しました。
In summary, there have been significant trials over the years with all the major ICN protocol flavors (e.g., CCNx, NDN, and POINT) using both the ICN-as-an-Overlay and ICN-as-an-Underlay deployment configurations. The major limitations of the trials include the fact that only a limited number of applications have been tested. However, the tested applications include both native ICN and existing IP-based applications (e.g., videoconferencing and IPTV). Another limitation of the trials is that all of them involve less than 1k users.
要約すると、ICN-as-an-OverlayおよびICN-as-an-Underlayデプロイメント構成の両方を使用して、主要なすべてのICNプロトコルフレーバー（CCNx、NDN、POINTなど）で長年にわたって重要な試験が行われてきました。試験の主な制限には、限られた数のアプリケーションのみがテストされているという事実が含まれます。ただし、テストされたアプリケーションには、ネイティブICNと既存のIPベースのアプリケーション（ビデオ会議やIPTVなど）の両方が含まれます。トライアルのもう1つの制限は、すべてのユーザーが1,000人未満のユーザーを対象とすることです。
Huawei and China Unicom have just started trials of the ICN-as-a-Slice configuration to demonstrate ICN features of security, mobility, and bandwidth efficiency over a wired infrastructure using videoconferencing as the application scenario [Chakraborti]; also, this prototype has been extended to demonstrate this over a 5G-NR access.
HuaweiとChina Unicomは、アプリケーションシナリオとしてビデオ会議を使用して有線インフラストラクチャ上のセキュリティ、モビリティ、および帯域幅効率のICN機能を実証するために、ICN-as-a-Slice構成の試験を開始しました[Chakraborti]。また、このプロトタイプは、5G-NRアクセスでこれを実証するために拡張されました。
The Clean-slate ICN approach has obviously never been in trials, as complete replacement of Internet infrastructure (e.g., existing applications, TCP/IP protocol stack, IP routers, etc.) is no longer considered a viable alternative.
クリーンスレートICNアプローチは、インターネットインフラストラクチャ（たとえば、既存のアプリケーション、TCP / IPプロトコルスタック、IPルーターなど）の完全な代替が実行可能な代替と見なされなくなったため、明らかに裁判にかけられたことはありません。
Finally, Hybrid ICN is a Composite-ICN approach that offers an interesting alternative, as it allows ICN semantics to be embedded in standard IPv6 packets so the packets can be routed through either IP routers or Hybrid ICN routers. Note that some other trials, such as the DOCTOR testbed (Section 6.2.6), could also be characterized as a Composite-ICN approach, because it contains both ICN gateways (as in ICN-as-an-Underlay) and virtualized infrastructure (as in ICN-as-a-Slice). However, for the DOCTOR testbed, we have chosen to characterize it as an ICN-as-an-Underlay configuration because that is a dominant characteristic.
最後に、ハイブリッドICNは、ICNセマンティクスを標準IPv6パケットに埋め込むことができるので、興味深い代替手段を提供する複合ICNアプローチであり、パケットはIPルーターまたはハイブリッドICNルーターのいずれかを通じてルーティングできます。 DOCTORテストベッド（セクション6.2.6）などの他のトライアルは、ICNゲートウェイ（ICN-as-an-Underlayなど）と仮想化インフラストラクチャ（ ICN-as-a-Sliceのように）。ただし、DOCTORテストベッドでは、ICN-as-an-Underlay構成として特徴づけることを選択しました。
"Information-Centric Networking (ICN) Research Challenges" [RFC7927] describes key ICN principles and technical research topics. As the title suggests, [RFC7927] is research oriented without a specific focus on deployment or standardization issues. This section addresses this open area by identifying key protocol functionality that may be relevant for further standardization effort in the IETF. The focus is specifically on identifying protocols that will facilitate future interoperable ICN deployments correlating to the scenarios identified in the deployment migration paths in Section 5. The identified list of potential protocol functionality is not exhaustive.
「情報中心型ネットワーキング（ICN）の研究課題」[RFC7927]は、主要なICN原則と技術研究トピックについて説明しています。タイトルが示すように、[RFC7927]は、導入や標準化の問題に特に焦点を当てずに研究指向です。このセクションでは、IETFでのさらなる標準化の取り組みに関連する可能性のある主要なプロトコル機能を特定することにより、このオープンエリアについて説明します。特に、セクション5の展開移行パスで識別されたシナリオに関連する将来の相互運用可能なICN展開を容易にするプロトコルの識別に重点が置かれています。識別された潜在的なプロトコル機能のリストは完全ではありません。
End-user applications and services need a standardized approach to trigger ICN transactions. For example, in Internet and web applications today, there are established socket APIs, communication paradigms (such as REST), common libraries, and best practices. We see a need to study application requirements in an ICN environment further and, at the same time, develop new APIs and best practices that can take advantage of ICN communication characteristics.
エンドユーザーのアプリケーションとサービスには、ICNトランザクションをトリガーするための標準化されたアプローチが必要です。たとえば、今日のインターネットおよびWebアプリケーションでは、確立されたソケットAPI、通信パラダイム（RESTなど）、共通ライブラリ、およびベストプラクティスがあります。 ICN環境でのアプリケーション要件をさらに調査し、同時に、ICN通信特性を利用できる新しいAPIとベストプラクティスを開発する必要があると考えています。
A key issue in CDNs is to quickly find a location of a copy of the object requested by an end user. In ICN, a Named Data Object (NDO) is typically defined by its name. [RFC6920] defines a mechanism that is suitable for static naming of ICN data objects. Other ways of encoding and representing ICN names have been described in [RFC8609] and [RFC8569]. Naming dynamically generated data requires different approaches(e.g., hash-digest-based names would normally not work), and there is a lack of established conventions and standards.
CDNの重要な問題は、エンドユーザーが要求したオブジェクトのコピーの場所をすばやく見つけることです。 ICNでは、名前付きデータオブジェクト（NDO）は通常、その名前で定義されます。 [RFC6920]は、ICNデータオブジェクトの静的な命名に適したメカニズムを定義しています。 ICN名をエンコードおよび表現する他の方法は、[RFC8609]および[RFC8569]で説明されています。動的に生成されたデータに名前を付けるには、さまざまなアプローチが必要であり（たとえば、ハッシュダイジェストベースの名前は通常機能しません）、確立された規則や標準がありません。
Another CDN issue for ICN is related to multicast distribution of content. Existing CDNs have started using multicast mechanisms for certain cases, such as for broadcasting streaming TV. However, as discussed in Section 6.2.1, certain ICN approaches provide substantial improvements over IP multicast, such as the implicit support for multicast retrieval of content in all ICN flavors.
ICNの別のCDN問題は、コンテンツのマルチキャスト配信に関連しています。既存のCDNは、ストリーミングTVのブロードキャストなど、特定のケースでマルチキャストメカニズムの使用を開始しています。ただし、セクション6.2.1で説明したように、特定のICNアプローチは、すべてのICNフレーバーのコンテンツのマルチキャスト取得を暗黙的にサポートするなど、IPマルチキャストを大幅に改善します。
Caching is an implicit feature in many ICN architectures that can improve performance and availability in several scenarios. The ICN in-network caching can augment managed CDN and improve its performance. The details of the interplay between ICN caching and managed CDN need further consideration.
キャッシングは、多くのICNアーキテクチャの暗黙的な機能であり、いくつかのシナリオでパフォーマンスと可用性を向上させることができます。 ICNネットワーク内キャッシングは、管理されたCDNを補強し、そのパフォーマンスを向上させることができます。 ICNキャッシングと管理されたCDN間の相互作用の詳細については、さらに検討する必要があります。
ICN provides the potential to redesign current edge and core network computing approaches. Leveraging ICN's inherent security and its ability to make name data and dynamic computation results available independent of location can enable a lightweight insertion of traffic into the network without relying on redirection of DNS requests. For this, proxies that translate from commonly used protocols in the general Internet to ICN message exchanges in the ICN domain could be used for the migration of application and services within deployments at the network edge but also in core networks. This is similar to existing approaches for IoT scenarios where a proxy translates CoAP request/responses to other message formats. For example, [RFC8075] specifies proxy mapping between CoAP and HTTP protocols. Also, [RFC8613] is an example of how to pass end-to-end encrypted content between HTTP and CoAP by an application-layer security mechanism. Further work is required to identify if an approach like [RFC8613], or some other approach, is suitable to preserve ICN message security through future protocol translation functions of gateways/proxies.
ICNは、現在のエッジおよびコアネットワークコンピューティングアプローチを再設計する可能性を提供します。 ICNの固有のセキュリティと、場所に関係なく名前データと動的計算結果を利用できる機能を利用すると、DNS要求のリダイレクトに依存することなく、トラフィックをネットワークに簡単に挿入できます。このため、一般的なインターネットで一般的に使用されているプロトコルからICNドメインでのICNメッセージ交換に変換するプロキシは、ネットワークエッジでの展開内のコアネットワークでのアプリケーションとサービスの移行に使用できます。これは、プロキシがCoAP要求/応答を他のメッセージ形式に変換するIoTシナリオの既存のアプローチに似ています。たとえば、[RFC8075]は、CoAPプロトコルとHTTPプロトコル間のプロキシマッピングを指定します。また、[RFC8613]は、アプリケーション層のセキュリティメカニズムによって、HTTPとCoAP間でエンドツーエンドの暗号化されたコンテンツを渡す方法の例です。 [RFC8613]のようなアプローチ、またはその他のアプローチが、ゲートウェイ/プロキシの将来のプロトコル変換機能を通じてICNメッセージのセキュリティを維持するのに適しているかどうかを特定するには、さらに作業が必要です。
Interaction and interoperability between existing IP routing protocols (e.g., OSPF, RIP, or IS-IS) and ICN routing approaches (e.g., NFD and CCNx routers) are expected, especially in the overlay approach. Another important topic is the integration of ICN into networks that support virtualized infrastructure in the form of NFV/ SDN and most likely utilize SFC as a key protocol. Further work is required to validate this idea and document best practices.
特にオーバーレイアプローチでは、既存のIPルーティングプロトコル（OSPF、RIP、IS-ISなど）とICNルーティングアプローチ（NFDおよびCCNxルーターなど）間の相互作用と相互運用性が期待されます。もう1つの重要なトピックは、NFV / SDNの形式で仮想インフラストラクチャをサポートし、SFCを主要なプロトコルとして利用する可能性が最も高いネットワークへのICNの統合です。このアイデアを検証し、ベストプラクティスを文書化するには、さらに作業が必要です。
There are several existing approaches to supporting QoS in IP networks, including Diffserv, IntServ, and RSVP. Some initial ideas for QoS support in ICN networks are outlined in [FLOW-CLASS], which proposes an approach based on flow classification to enable functions, such ICN rate control and cache control. Also, [ICN-QoS] proposes how to use Diffserv Differentiated Services Code Point (DSCP) codes to support QoS for ICN-based data path delivery. Further work is required to identify the best approaches for support of QoS in ICN networks.
Diffserv、IntServ、RSVPなど、IPネットワークでQoSをサポートするための既存のアプローチがいくつかあります。 ICNネットワークでのQoSサポートのいくつかの最初のアイデアは、[フロークラス]で概説されています。これは、フロー分類に基づいて、ICNレート制御やキャッシュ制御などの機能を有効にするアプローチを提案します。また、[ICN-QoS]は、Diffserv DiffServコードポイント（DSCP）コードを使用して、ICNベースのデータパス配信のQoSをサポートする方法を提案します。 ICNネットワークでQoSをサポートするための最良のアプローチを特定するには、さらに作業が必要です。
OAM is a crucial area that has not yet been fully addressed by the ICN research community but which is obviously critical for future deployments of ICN. Potential areas that need investigation include whether the YANG data modeling approach and associated NETCONF/ RESTCONF protocols need any specific updates for ICN support. Another open area is how to measure and benchmark performance of ICN networks comparable to the sophisticated techniques that exist for standard IP networks, virtualized networks, and data centers. It should be noted that some initial progress has been made in the area of ICN network path traceroute facility with approaches, such as CCNxinfo [CNNinfo] [Contrace].
OAMは、ICN研究コミュニティによってまだ完全に対処されていない重要な領域ですが、ICNの将来の展開にとって明らかに重要です。調査が必要になる可能性のある領域には、YANGデータモデリングアプローチおよび関連するNETCONF / RESTCONFプロトコルがICNサポートのための特定の更新を必要とするかどうかが含まれます。もう1つのオープンエリアは、標準のIPネットワーク、仮想化ネットワーク、およびデータセンターに存在する高度な手法に匹敵するICNネットワークのパフォーマンスを測定およびベンチマークする方法です。 ICNネットワークパスtraceroute機能の領域では、CCNxinfo [CNNinfo] [Contrace]などのアプローチにより、いくつかの初期の進歩があったことに注意してください。
Without claiming completeness, Table 1 maps the open ICN issues identified in this document to potential protocol efforts that could address some aspects of the gap.
完全性を主張することなく、表1は、このドキュメントで特定された未解決のICN問題を、ギャップのいくつかの側面に対処できる潜在的なプロトコルの取り組みにマッピングします。
+--------------+------------------------------------------+
| ICN Gap | Potential Protocol Effort |
+==============+==========================================+
| 1-Support of | HTTP/CoAP support of ICN semantics |
| REST APIs | |
+--------------+------------------------------------------+
| 2-Naming | Dynamic naming of ICN data objects |
+--------------+------------------------------------------+
| 3-Routing | Interactions between IP and ICN routing |
| | protocols |
+--------------+------------------------------------------+
| 4-Multicast | Multicast enhancements for ICN |
| distribution | |
+--------------+------------------------------------------+
| 5-In-network | ICN cache placement and sharing |
| caching | |
+--------------+------------------------------------------+
| 6-NFV/SDN | Integration of ICN with NFV/SDN and |
| support | including possible impacts to SFC |
+--------------+------------------------------------------+
| 7-ICN | Mapping of HTTP and other protocols onto |
| mapping | ICN message exchanges (and vice versa) |
| | while preserving ICN message security |
+--------------+------------------------------------------+
| 8-QoS | Support of ICN QoS via mechanisms, such |
| support | as Diffserv and flow classification |
+--------------+------------------------------------------+
| 9-OAM | YANG data models, NETCONF/RESTCONF |
| support | protocols, and network-performance |
| | measurements |
+--------------+------------------------------------------+
Table 1: Mapping of ICN Gaps to Potential Protocol Efforts
表1：ICNギャップと潜在的なプロトコルの取り組みのマッピング
This document provides high-level deployment considerations for current and future members of the ICN community. Specifically, the major configurations of possible ICN deployments are identified as (1) Clean-slate ICN replacement of existing Internet infrastructure, (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, (4) ICN-as-a-Slice, and (5) Composite-ICN. Existing ICN trial systems primarily fall under the ICN-as-an-Overlay, ICN-as-an-Underlay, and Composite-ICN configurations.
このドキュメントでは、ICNコミュニティの現在および将来のメンバーに対する高レベルの展開に関する考慮事項について説明します。具体的には、可能なICN展開の主要な構成は、（1）既存のインターネットインフラストラクチャのスレートスレートICN交換、（2）ICN-as-an-Overlay、（3）ICN-as-an-Underlay、（4）として識別されます。 ICN-as-a-slice、および（5）Composite-ICN。既存のICNトライアルシステムは、主にICN-as-an-Overlay、ICN-as-an-Underlay、およびComposite-ICN構成に分類されます。
In terms of deployment migration paths, ICN-as-an-Underlay offers a clear migration path for CDN, edge, or core networks to go to an ICN paradigm (e.g., for an IoT deployment) while leaving the critical mass of existing end-user applications untouched. ICN-as-an-Overlay is the easiest configuration to deploy rapidly, as it leaves the underlying IP infrastructure essentially untouched. However, its applicability for general deployment must be considered on a case-by-case basis. (That is, can it support all required user applications?). ICN-as-a-Slice is an attractive deployment option for upcoming 5G systems (i.e., for 5G radio and core networks) that will naturally support network slicing, but this still has to be validated through more trial experiences. Composite-ICN, by its nature, can combine some of the best characteristics of the other configurations, but its applicability for general deployment must again be considered on a case-by-case basis (i.e., can enough IP routers be upgraded to support Composite-ICN functionality to provide sufficient performance benefits?).
デプロイメント移行パスに関して、ICN-as-an-Underlayは、CDN、エッジ、またはコアネットワークがICNパラダイム（例えば、IoTデプロイメント）に移行するための明確な移行パスを提供し、既存のエンドの重要な質量を残します。ユーザーアプリケーションはそのままです。 ICN-as-an-Overlayは、基盤となるIPインフラストラクチャを基本的に変更しないため、迅速に展開するのに最も簡単な構成です。ただし、一般的な展開への適用性は、ケースバイケースで考慮する必要があります。 （つまり、必要なすべてのユーザーアプリケーションをサポートできますか？）。 ICN-as-a-Sliceは、ネットワークスライシングを自然にサポートする今後の5Gシステム（つまり、5G無線およびコアネットワーク）にとって魅力的な導入オプションですが、これはさらに多くのトライアルエクスペリエンスを通じて検証する必要があります。複合ICNは、その性質上、他の構成のいくつかの最良の特性を組み合わせることができますが、一般的な展開への適用性は、ケースバイケースで再度検討する必要があります（つまり、複合をサポートするために十分なIPルーターをアップグレードできます） -十分なパフォーマンス上の利点を提供するICN機能？）
There has been significant trial experience with all the major ICN protocol flavors (e.g., CCNx, NDN, and POINT). However, only a limited number of applications have been tested so far, and the maximum number of users in any given trial has been less than 1k users. It is recommended that future ICN deployments scale their users gradually and closely monitor network performance as they go above 1k users. A logical approach would be to increase the number of users in a slowly increasing linear manner and monitor network performance and stability, especially at every multiple of 1k users.
すべての主要なICNプロトコルフレーバー（CCNx、NDN、POINTなど）での重要なトライアル経験があります。ただし、これまでにテストされたアプリケーションの数は限られているため、特定のトライアルでの最大ユーザー数は1,000ユーザー未満でした。将来のICN展開では、ユーザー数を徐々に増やし、1,000人を超えるユーザーのネットワークパフォーマンスを注意深く監視することをお勧めします。論理的なアプローチは、ゆっくりと線形的にユーザー数を増やし、ネットワークのパフォーマンスと安定性を、特に1,000人のユーザーの倍数ごとに監視することです。
Finally, this document describes a set of technical features in ICN that warrant potential future IETF specification work. This will aid initial and incremental deployments to proceed in an interoperable manner. The fundamental details of the potential protocol specification effort, however, are best left for future study by the appropriate IETF WGs and/or BoFs. The ICNRG can aid this process in the near and mid-term by continuing to examine key system issues like QoS mechanisms, flexible naming schemes, and OAM support for ICN.
最後に、このドキュメントでは、潜在的な将来のIETF仕様の作業を保証するICNの一連の技術的機能について説明します。これは、相互運用可能な方法で進行する初期および増分の展開を支援します。ただし、プロトコル仕様の潜在的な取り組みの基本的な詳細は、適切なIETF WGおよび/またはBoFによる将来の調査に任せるのが最善です。 ICNRGは、QoSメカニズム、柔軟な命名方式、ICNのOAMサポートなどの主要なシステム問題を引き続き調査することにより、このプロセスを中期的に支援することができます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
ICN was purposefully designed from the start to have certain intrinsic security properties. The most well known of which are authentication of delivered content and (optional) encryption of the content. [RFC7945] has an extensive discussion of various aspects of ICN security, including many that are relevant to deployments. Specifically, [RFC7945] points out that ICN access control, privacy, security of in-network caches, and protection against various network attacks (e.g., DoS) have not yet been fully developed due to the lack of a sufficient mass of deployments. [RFC7945] also points out relevant advances occurring in the ICN research community that hold promise to address each of the identified security gaps. Lastly, [RFC7945] points out that as secure communications in the existing Internet (e.g., HTTPS) become the norm, major gaps in ICN security will inevitably slow down the adoption of ICN.
ICNは、最初から意図的に設計されており、特定の固有のセキュリティプロパティを備えています。最もよく知られているのは、配信されたコンテンツの認証と（オプションの）コンテンツの暗号化です。 [RFC7945]は、配備に関連する多くのことを含め、ICNセキュリティのさまざまな側面について広範囲にわたって議論しています。具体的には、[RFC7945]は、ICNアクセス制御、プライバシー、ネットワーク内キャッシュのセキュリティ、およびさまざまなネットワーク攻撃（DoSなど）に対する保護が、十分な大量のデプロイメントがないため、まだ完全には開発されていないことを指摘しています。 [RFC7945]は、特定されたセキュリティギャップのそれぞれに対処することを約束するICN研究コミュニティで発生している関連する進歩も指摘しています。最後に、[RFC7945]は、既存のインターネット（HTTPSなど）での安全な通信が一般的になるにつれて、ICNセキュリティの大きなギャップが必然的にICNの採用を遅くすると指摘しています。
In addition to the security findings of [RFC7945], this document has highlighted that all anticipated ICN deployment configurations will involve coexistence with existing Internet infrastructure and applications. Thus, even the basic authentication and encryption properties of ICN content will need to account for interworking with non-ICN content to preserve end-to-end security. For example, in the edge network underlay deployment configuration described in Section 4.3.1, the gateway/proxy that translates HTTP or CoAP request/responses into ICN message exchanges will need to support a security model to preserve end-to-end security. One alternative would be to consider an approach similar to [RFC8613], which is used to pass end-to-end encrypted content between HTTP and CoAP by an application-layer security mechanism. Further investigation is required to see if this approach is suitable to preserve ICN message security through future protocol translation functions (e.g., ICN to HTTP or CoAP to ICN) of gateways/proxies.
[RFC7945]のセキュリティ結果に加えて、このドキュメントでは、予想されるすべてのICN展開構成には、既存のインターネットインフラストラクチャおよびアプリケーションとの共存が含まれることが強調されています。したがって、ICNコンテンツの基本的な認証と暗号化のプロパティでさえ、エンドツーエンドのセキュリティを維持するために、ICN以外のコンテンツとの相互作用を考慮する必要があります。たとえば、セクション4.3.1で説明されているエッジネットワークアンダーレイの展開構成では、HTTPまたはCoAP要求/応答をICNメッセージ交換に変換するゲートウェイ/プロキシは、エンドツーエンドのセキュリティを維持するためにセキュリティモデルをサポートする必要があります。 1つの代替案は、[RFC8613]と同様のアプローチを検討することです。これは、アプリケーション層のセキュリティメカニズムによって、HTTPとCoAP間でエンドツーエンドの暗号化コンテンツを渡すために使用されます。このアプローチがゲートウェイ/プロキシの将来のプロトコル変換機能（ICNからHTTP、CoAPからICNなど）を通じてICNメッセージのセキュリティを維持するのに適しているかどうかを確認するには、さらに調査が必要です。
Finally, the DOCTOR project discussed in Section 6.2.6 is an example of an early deployment that is looking at specific attacks against ICN infrastructure, in this case, looking at Interest Flooding Attacks [Nguyen-2] and Content Poisoning Attacks [Nguyen-1] [Mai-2] [Nguyen-3] and evaluating potential countermeasures based on MANO-orchestrated actions on the virtualized infrastructure [Mai-1].
最後に、セクション6.2.6で説明されているDOCTORプロジェクトは、ICNインフラストラクチャに対する特定の攻撃、この場合はInterest Flooding Attacks [Nguyen-2]とContent Poisoning Attacks [Nguyen-1]に注目する初期展開の例です。 ] [Mai-2] [Nguyen-3]そして、仮想化インフラストラクチャ[MAi-1]でMANOが調整したアクションに基づいて潜在的な対策を評価します。
[Anastasiades] Anastasiades, C., "Information-centric communication in mobile and wireless networks", PhD Dissertation, DOI 10.7892/boris.83683, June 2016, <http://boris.unibe.ch/83683/1/16anastasiades_c.pdf>.
[アナスタシアデス]アナスタシアデス、C。、「モバイルおよびワイヤレスネットワークにおける情報中心の通信」、PhD論文、DOI 10.7892 / boris.83683、2016年6月、<http://boris.unibe.ch/83683/1/16anastasiades_c。 pdf>。
[Baccelli] Baccelli, E., et al., "Information Centric Networking in the IoT: Experiments with NDN in the Wild", ACM-ICN '14: Proceedings of the 1st ACM Conference on Information-Centric Networking, DOI 10.1145/2660129.2660144, September 2014, <http://conferences2.sigcomm.org/acm-icn/2014/papers/p77.pdf>.
[Baccelli] Baccelli、E。、他、「IoTにおける情報セントリックネットワーキング：野生におけるNDNの実験」、ACM-ICN '14：情報セントリックネットワーキングに関する第1回ACM会議の議事録、DOI 10.1145 / 2660129.2660144 、2014年9月、<http://conferences2.sigcomm.org/acm-icn/2014/papers/p77.pdf>。
[BIER] Trossen, D., Rahman, A., Wang, C., and T. Eckert, "Applicability of BIER Multicast Overlay for Adaptive Streaming Services", Work in Progress, Internet-Draft, draft-ietf-bier-multicast-http-response-03, 4 February 2020, <https://tools.ietf.org/html/draft-ietf-bier-multicast-http-response-03>.
[BIER] Trossen、D.、Rahman、A.、Wang、C。、およびT. Eckert、「適応ストリーミングサービスに対するBIERマルチキャストオーバーレイの適用性」、進行中の作業、インターネットドラフト、draft-ietf-bier-multicast -http-response-03、2020年2月4日、<https://tools.ietf.org/html/draft-ietf-bier-multicast-http-response-03>。
[CCNx_UDP] PARC, "CCNx Over UDP", <https://www.ietf.org/proceedings/ interim-2015-icnrg-04/slides/slides-interim-2015-icnrg-4-5.pdf>.
[CCNx_UDP] PARC、「CCNx Over UDP」、<https://www.ietf.org/proceedings/ interim-2015-icnrg-04 / slides / slides-interim-2015-icnrg-4-5.pdf>。
[Chakraborti] Chakraborti, A., et al., "Design and Evaluation of a Multi-source Multi-destination Real-time Application on Content Centric Network", 2018 1st IEEE International Conference on Hot Information-Centric Networking (HotICN), DOI 10.1109/HOTICN.2018.8605980, August 2018, <https://doi.org/10.1109/HOTICN.2018.8605980>.
[チャクラボルティ]チャクラボルティ、A。、他、「コンテンツセントリックネットワークでのマルチソースマルチデスティネーションリアルタイムアプリケーションの設計と評価」、2018第1回ホットインフォメーションセントリックネットワーキングに関するIEEE国際会議（HotICN）、DOI 10.1109 / HOTICN.2018.8605980、2018年8月、<https://doi.org/10.1109/HOTICN.2018.8605980>。
[CICN] fd.io, "Cicn", <https://wiki.fd.io/view/Cicn>.
[CICN] fd.io、「Cicn」、<https://wiki.fd.io/view/Cicn>。
[CNNinfo] Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering Content and Network Information in Content-Centric Networks", Work in Progress, Internet-Draft, draft-irtf-icnrg-ccninfo-04, 22 March 2020, <https://tools.ietf.org/html/draft-irtf-icnrg-ccninfo-04>.
[CNNinfo]浅枝浩子、大岡明夫、X。Shao、「CCNinfo：コンテンツ中心のネットワークにおけるコンテンツとネットワーク情報の発見」、進行中の作業、インターネットドラフト、draft-irtf-icnrg-ccninfo-04 、2020年3月22日、<https://tools.ietf.org/html/draft-irtf-icnrg-ccninfo-04>。
[CONET] Veltri, L., et al., "Supporting Information-Centric Functionality in Software Defined Networks", 2012 IEEE International Conference on Communications (ICC), DOI 10.1109/ICC.2012.6364916, November 2012, <http://netgroup.uniroma2.it/Stefano_Salsano/papers/ salsano-icc12-wshop-sdn.pdf>.
[CONET] Veltri、L.、et al。、 "Supporting Information-Centtric Functionality in Software Defined Networks"、2012 IEEE International Conference on Communications（ICC）、DOI 10.1109 / ICC.2012.6364916、November 2012、<http：// netgroup .uniroma2.it / Stefano_Salsano / papers / salsano-icc12-wshop-sdn.pdf>。
[Contrace] Asaeda, H., et al., "Contrace: a tool for measuring and tracing content-centric networks", IEEE Communications Magazine, Volume 53, Issue 3, DOI 10.1109/MCOM.2015.7060502, March 2015, <https://doi.org/10.1109/MCOM.2015.7060502>.
[Contrace] Asaeda、H。、他、「Contrace：コンテンツ中心のネットワークを測定および追跡するためのツール」、IEEE Communications Magazine、Volume 53、Issue 3、DOI 10.1109 / MCOM.2015.7060502、2015年3月、<https： //doi.org/10.1109/MCOM.2015.7060502>。
[CUTEi] Asaeda, H., Li, R., and N. Choi, "Container-Based Unified Testbed for Information Centric Networking", IEEE Network Volume 28, Issue:6, DOI 10.1109/MNET.2014.6963806, November 2014, <https://doi.org/10.1109/MNET.2014.6963806>.
[CUTEi] Asaeda、H.、Li、R。、およびN. Choi、「Container-Based Unified Testbed for Information Centric Networking」、IEEE Network Volume 28、Issue：6、DOI 10.1109 / MNET.2014.6963806、2014年11月、< https://doi.org/10.1109/MNET.2014.6963806>。
[C_FLOW] D. Chang, et al., "C_flow: An efficient content delivery framework with OpenFlow", The International Conference on Information Networking 2014 (ICOIN2014), pp. 270-275, DOI 10.1109/ICOIN.2014.6799480, February 2014, <https://ieeexplore.ieee.org/document/6799480>.
[C_FLOW] D. Chang、他、「C_flow：OpenFlowを使用した効率的なコンテンツ配信フレームワーク」、International Conference on Information Networking 2014（ICOIN2014）、pp。270-275、DOI 10.1109 / ICOIN.2014.6799480、February 2014、 <https://ieeexplore.ieee.org/document/6799480>。
[DABBER] Mendes, P., Sofia, R., Tsaoussidis, V., and C. Borrego, "Information-centric Routing for Opportunistic Wireless Networks", Work in Progress, Internet-Draft, draft-mendes-icnrg-dabber-04, 14 March 2020, <https://tools.ietf.org/html/draft-mendes-icnrg-dabber-04>.
[DABBER] Mendes、P.、Sofia、R.、Tsaoussidis、V。、およびC. Borrego、「日和見の無線ネットワークのための情報中心のルーティング」、進行中の作業、インターネットドラフト、draft-mendes-icnrg-dabber- 2020年3月14日、<https://tools.ietf.org/html/draft-mendes-icnrg-dabber-04>。
[DASH] DASH, "DASH Industry Forum", <http://dashif.org/>.
[DASH] DASH、「DASH Industry Forum」、<http://dashif.org/>。
[Doctor] DOCTOR, "Deployment and securisation of new functionalities in virtualized networking environments", <http://www.doctor-project.org/index.htm>.
[Doctor] DOCTOR、「仮想ネットワーク環境における新機能の導入とセキュリティ」、<http://www.doctor-project.org/index.htm>。
[fiveG-23501] 3GPP, "System Architecture for the 5G System", Release 15, 3GPP TS 23.501, December 2017.
[fiveG-23501] 3GPP、「5Gシステムのシステムアーキテクチャ」、リリース15、3GPP TS 23.501、2017年12月。
[fiveG-23502] 3GPP, "Procedures for the 5G System (5GS)", Release 15, 3GPP TS 23.502.
[fiveG-23502] 3GPP、「5Gシステム（5GS）の手順」、リリース15、3GPP TS 23.502。
[FLOW-CLASS] Moiseenko, I. and D. Oran, "Flow Classification in Information Centric Networking", Work in Progress, Internet-Draft, draft-moiseenko-icnrg-flowclass-05, 20 January 2020, <https://tools.ietf.org/html/draft-moiseenko-icnrg-flowclass-05>.
[FLOW-CLASS] Moiseenko、I。およびD. Oran、「情報セントリックネットワーキングにおけるフロー分類」、作業中、インターネットドラフト、draft-moiseenko-icnrg-flowclass-05、2020年1月20日、<https：// tools.ietf.org/html/draft-moiseenko-icnrg-flowclass-05>。
[GEANT] GEANT, "GEANT", <https://www.geant.org/>.
[GEANT] GEANT、「GEANT」、<https://www.geant.org/>。
[H-ICN_1] Cisco, "Cisco Announces Important Steps toward Adoption of Information-Centric Networking", February 2017, <http://blogs.cisco.com/sp/cisco-announces-important-steps-toward-adoption-of-information-centric-networking>.
[H-ICN_1]シスコ、「シスコは情報中心型ネットワーキングの採用に向けた重要なステップを発表」、2017年2月、<http://blogs.cisco.com/sp/cisco-announces-important-steps-toward-adoption-of -情報中心のネットワーキング>。
[H-ICN_2] Cisco, "Mobile Video Delivery with Hybrid ICN: IP-integrated ICN Solution for 5G", <https://www.cisco.com/c/dam/en/us/solutions/collateral/ service-provider/ultra-services-platform/mwc17-hicn-video-wp.pdf>.
[H-ICN_2]シスコ、「ハイブリッドICNを使用したモバイルビデオ配信：5G向けのIP統合ICNソリューション」、<https://www.cisco.com/c/dam/en/us/solutions/collateral/ service-provider /ultra-services-platform/mwc17-hicn-video-wp.pdf>。
[H-ICN_3] Muscariello, L., et al, "Hybrid Information-Centric Networking: ICN inside the Internet Protocol", ICNRG Interim Meeting, March 2018, <https://datatracker.ietf.org/meeting/interim-2018-icnrg-01/materials/slides-interim-2018-icnrg-01-sessa-hybrid-icn-hicn-luca-muscariello>.
[H-ICN_3] Muscariello、L.、et al、 "Hybrid Information-Centric Networking：ICN inside the Internet Protocol"、ICNRG Interim Meeting、March 2018、<https://datatracker.ietf.org/meeting/interim-2018 -icnrg-01 / materials / slides-interim-2018-icnrg-01-sessa-hybrid-icn-hicn-luca-muscariello>。
[ICN-5GC] Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G. White, "Enabling ICN in 3GPP's 5G NextGen Core Architecture", Work in Progress, Internet-Draft, draft-ravi-icnrg-5gc-icn-04, 31 May 2019, <https://tools.ietf.org/html/draft-ravi-icnrg-5gc-icn-04>.
[ICN-5GC] Ravindran、R.、Suthar、P.、Trossen、D.、Wang、C。、およびG. White、「3GPPの5G NextGenコアアーキテクチャでICNを有効にする」、作業中、インターネットドラフト、ドラフト-ravi-icnrg-5gc-icn-04、2019年5月31日、<https://tools.ietf.org/html/draft-ravi-icnrg-5gc-icn-04>。
[ICN-DEP-CON] Paik, E., Yun, W., Kwon, T., and H. Choi, "Deployment Considerations for Information-Centric Networking", Work in Progress, Internet-Draft, draft-paik-icn-deployment-considerations-00, 15 July 2013, <https://tools.ietf.org/html/draft-paik-icn-deployment-considerations-00>.
[ICN-DEP-CON] Paik、E.、Yun、W.、Kwon、T。、およびH. Choi、「情報中心のネットワーキングの導入に関する考慮事項」、進行中の作業、インターネットドラフト、draft-paik-icn -deployment-considerations-00、2013年7月15日、<https://tools.ietf.org/html/draft-paik-icn-deployment-considerations-00>。
[ICN-IoT] Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., Burke, J., Ahlgren, B., and A. Azgin, "Design Considerations for Applying ICN to IoT", Work in Progress, Internet-Draft, draft-irtf-icnrg-icniot-03, 2 May 2019, <https://tools.ietf.org/html/draft-irtf-icnrg-icniot-03>.
[ICN-IoT] Ravindran、R.、Zhang、Y.、Grieco、L.、Lindgren、A.、Burke、J.、Ahlgren、B。、およびA. Azgin、「IoTへのICNの適用に関する設計上の考慮事項」、 Work in Progress、Internet-Draft、draft-irtf-icnrg-icniot-03、2019年5月2日、<https://tools.ietf.org/html/draft-irtf-icnrg-icniot-03>。
[ICN-LTE-4G] Suthar, P., Stolic, M., Jangam, A., Ed., Trossen, D., and R. Ravindran, "Native Deployment of ICN in LTE, 4G Mobile Networks", Work in Progress, Internet-Draft, draft-irtf-icnrg-icn-lte-4g-05, 4 November 2019, <https://tools.ietf.org/html/draft-irtf-icnrg-icn-lte-4g-05>.
[ICN-LTE-4G] Suthar、P.、Stolic、M.、Jangam、A.、Ed。、Trossen、D。、およびR. Ravindran、「LTE、4GモバイルネットワークにおけるICNのネイティブ展開」、Work in Progress、Internet-Draft、draft-irtf-icnrg-icn-lte-4g-05、2019年11月4日、<https://tools.ietf.org/html/draft-irtf-icnrg-icn-lte-4g-05 >。
[ICN-QoS] Jangam, A., Suthar, P., and M. Stolic, "Supporting QoS aware Data Delivery in Information Centric Networks", Work in Progress, Internet-Draft, draft-anilj-icnrg-icn-qos-00, 14 July 2018, <https://tools.ietf.org/html/draft-anilj-icnrg-icn-qos-00>.
[ICN-QoS] Jangam、A.、Suthar、P。、およびM. Stolic、「情報セントリックネットワークでのQoS対応のデータ配信のサポート」、作業中、インターネットドラフト、draft-anilj-icnrg-icn-qos- 00、2018年7月14日、<https://tools.ietf.org/html/draft-anilj-icnrg-icn-qos-00>。
[ICN-TERM] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, "Information-Centric Networking (ICN): CCNx and NDN Terminology", Work in Progress, Internet-Draft, draft-irtf-icnrg-terminology-08, 17 January 2020, <https://tools.ietf.org/html/draft-irtf-icnrg-terminology-08>.
[ICN-TERM] Wissingh、B.、Wood、C.、Afanasyev、A.、Zhang、L.、Oran、D。、およびC. Tschudin、「情報中心のネットワーキング（ICN）：CCNxおよびNDN用語」、 Work in Progress、Internet-Draft、draft-irtf-icnrg-terminology-08、2020年1月17日、<https://tools.ietf.org/html/draft-irtf-icnrg-terminology-08>。
[ICN2020-Experiments] ICN2020, "D4.1: 1st Yearly WP4 Report & Demonstration", August 2017, <https://projects.gwdg.de/attachments/6840/D4.1-PU.pdf>.
[ICN2020-Experiments] ICN2020、「D4.1：1st Yearly WP4 Report＆Demonstration」、2017年8月、<https://projects.gwdg.de/attachments/6840/D4.1-PU.pdf>。
[ICN2020-overview] ICN2020, "ICN2020 Project Overview", <http://www.icn2020.org/>.
[ICN2020-overview] ICN2020、「ICN2020プロジェクトの概要」、<http://www.icn2020.org/>。
[ICNRGCharter] IRTF, "Information-Centric Networking Research Group Charter", <https://datatracker.ietf.org/doc/charter-irtf-icnrg/>.
[ICNRGCharter] IRTF、「情報中心のネットワーキング研究グループ憲章」、<https://datatracker.ietf.org/doc/charter-irtf-icnrg/>。
[IEEE_Communications] Trossen, D. and G. Parisis, "Designing and realizing an information-centric internet", IEEE Communications Magazine, Volume 50, Issue 7, DOI 10.1109/MCOM.2012.6231280, <https://doi.org/10.1109/MCOM.2012.6231280>.
[IEEE_Communications] Trossen、D。およびG. Parisis、「情報中心のインターネットの設計と実現」、IEEE Communications Magazine、Volume 50、Issue 7、DOI 10.1109 / MCOM.2012.6231280、<https://doi.org/10.1109 /MCOM.2012.6231280>。
[Internet_Pricing] Trossen, D. and G. Biczok, "Not paying the truck driver: differentiated pricing for the future internet", ReARCH '10: Proceedings of the Re-Architecting the Internet Workshop, ReArch '10: Proceedings of the Re-Architecting the Internet Workshop, DOI 10.1145/1921233.1921235, November 2010, <https://doi.org/10.1145/1921233.1921235>.
[Internet_Pricing] Trossen、D。、およびG. Biczok、「トラックの運転手にお金を払わない：将来のインターネットの差別化された価格設定」、ReARCH '10：Re-Architecting the Internet Workshop、ReArch '10：Proceedings of the Re- Architecting the Internet Workshop、DOI 10.1145 / 1921233.1921235、11月、<https://doi.org/10.1145/1921233.1921235>。
[Jacobson] Jacobson, V., et al., "Networking Named Content", CoNEXT '09: Proceedings of the 5th international conference on Emerging networking experiments and technologies, DOI 10.1145/1658939.1658941, December 2009, <https://doi.org/10.1145/1658939.1658941>.
[Jacobson] Jacobson、V.、et al。、 "Networking Named Content"、CoNEXT '09：Proceedings of the 5th International Conference on Emerging Networking Experiments and Technologies、DOI 10.1145 / 1658939.1658941、December 2009、<https：// doi。 org / 10.1145 / 1658939.1658941>。
[Jangam] Jangam, A., et al., "nlsrSIM: Porting and Simulation of Named-data Link State Routing Protocol into ndnSIM", DIVANet '17: Proceedings of the 6th ACM Symposium on Development and Analysis of Intelligent Vehicular Networks and Applications, DOI 10.1145/3132340.3132351, November 2017, <https://dl.acm.org/citation.cfm?id=3132351>.
[ジャンガム]ジャンガムA.他、「nlsrSIM：名前付きデータリンクステートルーティングプロトコルのndnSIMへの移植とシミュレーション」、DIVANet '17：インテリジェント車両ネットワークとアプリケーションの開発と分析に関する第6回ACMシンポジウムの議事録、DOI 10.1145 / 3132340.3132351、2017年11月、<https://dl.acm.org/citation.cfm?id=3132351>。
[Mai-1] Mai, H., et al., "Implementation of content poisoning attack detection and reaction in virtualized NDN networks", 2018 21st Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), DOI 10.1109/ICIN.2018.8401591, July 2018, <https://ieeexplore.ieee.org/document/8401591>.
[Mai-1] Mai、H.、et al。、 "Implementation of content poisoning attack detection and reaction in virtualized NDN network"、2018 21st Conference on Innovation in Clouds、Internet and Networks and Workshops（ICIN）、DOI 10.1109 / ICIN .2018.8401591、2018年7月、<https://ieeexplore.ieee.org/document/8401591>。
[Mai-2] Mai, H., et al., "Towards a Security Monitoring Plane for Named Data Networking: Application to Content Poisoning Attack", NOMS 2018 - 2018 IEEE/IFIP Network Operations Management Symposium, DOI 10.1109/NOMS.2018.8406246, July 2018, <https://doi.org/10.1109/NOMS.2018.8406246>.
[Mai-2] Mai、H.、et al。、 "Towards a Security Monitoring Plane for Named Data Networking：Application to Content Poisoning Attack"、NOMS 2018-2018 IEEE / IFIP Network Operations Management Symposium、DOI 10.1109 / NOMS.2018.8406246 、2018年7月、<https://doi.org/10.1109/NOMS.2018.8406246>。
[Marchal] Marchal, X., et al., "Leveraging NFV for the Deployment of NDN: Application to HTTP Traffic Transport", NOMS 2018 - 2018 IEEE/IFIP Network Operations and Management Symposium, DOI 10.1109/NOMS.2018.8406206, July 2018, <http://www.mallouli.com/recherche/publications/ noms2018-1.pdf>.
[Marchal] X、他、「NDVの展開のためのNFVの活用：HTTPトラフィックトランスポートへのアプリケーション」、NOMS 2018-2018 IEEE / IFIPネットワーク運用および管理シンポジウム、DOI 10.1109 / NOMS.2018.8406206、2018年7月、<http://www.mallouli.com/recherche/publications/noms2018-1.pdf>。
[Moiseenko] Moiseenko, I. and D. Oran, "TCP/ICN: Carrying TCP over Content Centric and Named Data Networks", ACM-ICN '16: Proceedings of the 3rd ACM Conference on Information-Centric Networking, DOI 10.1145/2984356.2984357, September 2016, <http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf>.
[Moiseenko] Moiseenko、I。およびD. Oran、「TCP / ICN：Carrying TCP over Content Centric and Named Data Networks」、ACM-ICN '16：Proceedings of the 3rd ACM Conference on Information-Centric Networking、DOI 10.1145 / 2984356.2984357 、2016年9月、<http://conferences2.sigcomm.org/acm-icn/2016/proceedings/p112-moiseenko.pdf>。
[MWC_Demo] InterDigital, "InterDigital Demo at Mobile World Congress (MWC)", 2016, <http://www.interdigital.com/ download/56d5c71bd616f892ba001861>.
[MWC_Demo] InterDigital、「InterDigital Demo at Mobile World Congress（MWC）」、2016年、<http://www.interdigital.com/download/56d5c71bd616f892ba001861>。
[NDN-testbed] NDN, "NDN Testbed", <https://named-data.net/ndn-testbed/>.
[NDN-testbed] NDN、「NDN Testbed」、<https://named-data.net/ndn-testbed/>。
[NetInf] Kutscher, D., Farrell, S., and E. Davies, "The NetInf Protocol", Work in Progress, Internet-Draft, draft-kutscher-icnrg-netinf-proto-01, 10 February 2013, <https://tools.ietf.org/html/draft-kutscher-icnrg-netinf-proto-01>.
[NetInf] Kutscher、D.、Farrell、S。、およびE. Davies、「The NetInf Protocol」、Work in Progress、Internet-Draft、draft-kutscher-icnrg-netinf-proto-01、2013年2月10日、<https ：//tools.ietf.org/html/draft-kutscher-icnrg-netinf-proto-01>。
[NFD] NDN, "NFD - Named Data Networking Forwarding Daemon", <https://named-data.net/doc/NFD/current/>.
[NFD] NDN、「NFD-Named Data Networking Forwarding Daemon」、<https://named-data.net/doc/NFD/current/>。
[NGMN-5G] NGMN Alliance, "5G White Paper", February 2015, <https://www.ngmn.org/wp-content/uploads/ NGMN_5G_White_Paper_V1_0.pdf>.
[NGMN-5G] NGMNアライアンス、「5Gホワイトペーパー」、2015年2月、<https://www.ngmn.org/wp-content/uploads/ NGMN_5G_White_Paper_V1_0.pdf>。
[NGMN-Network-Slicing] NGMN Alliance, "Description of Network Slicing Concept", NGMN 5G P1, Requirements & Architecture, Work Stream End-to-End Architecture, Version 1.0, January 2016, <https://www.ngmn.org/wp-content/ uploads/160113_NGMN_Network_Slicing_v1_0.pdf>.
[NGMN-ネットワークスライシング] NGMNアライアンス、「ネットワークスライシングコンセプトの説明」、NGMN 5G P1、要件とアーキテクチャ、ワークストリームエンドツーエンドアーキテクチャ、バージョン1.0、2016年1月、<https：//www.ngmn。 org / wp-content / uploads / 160113_NGMN_Network_Slicing_v1_0.pdf>。
[Nguyen-1] Nguyen, T., et al., "Content Poisoning in Named Data Networking: Comprehensive characterization of real deployment", 2017 IFIP/IEEE Symposium on Integrated Network and Service Management (IM), DOI 10.23919/INM.2017.7987266, July 2017, <https://doi.org/10.23919/INM.2017.7987266>.
[Nguyen-1] Nguyen、T.、et al。、 "Name Poisoning in Named Data Networking：Comprehensive Characterization of Real Deployment"、2017 IFIP / IEEE Symposium on Integrated Network and Service Management（IM）、DOI 10.23919 / INM.2017.7987266 、2017年7月、<https://doi.org/10.23919/INM.2017.7987266>。
[Nguyen-2] Nguyen, T., Cogranne, R., and G. Doyen, "An optimal statistical test for robust detection against interest flooding attacks in CCN", 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM), DOI 10.1109/INM.2015.7140299, July 2015, <https://doi.org/10.1109/INM.2015.7140299>.
[Nguyen-2] Nguyen、T.、Cogranne、R。、およびG. Doyen、「CCNにおけるインタレストフラッディング攻撃に対するロバストな検出のための最適な統計テスト」、2015年IFIP / IEEE統合ネットワーク管理に関する国際シンポジウム、 DOI 10.1109 / INM.2015.7140299、2015年7月、<https://doi.org/10.1109/INM.2015.7140299>。
[Nguyen-3] Nguyen, T., et al., "A Security Monitoring Plane for Named Data Networking Deployment", IEEE Communications Magazine, Volume: 56, Issue 11, DOI 10.1109/MCOM.2018.1701135, November 2018, <https://doi.org/10.1109/MCOM.2018.1701135>.
[Nguyen-3] Nguyen、T.、et al。、 "A Security Monitoring Plane for Named Data Networking Deployment"、IEEE Communications Magazine、Volume：56、Issue 11、DOI 10.1109 / MCOM.2018.1701135、November 2018、<https： //doi.org/10.1109/MCOM.2018.1701135>。
[ONAP] ONAP, "Open Network Automation Platform", <https://www.onap.org/>.
[ONAP] ONAP、「Open Network Automation Platform」、<https://www.onap.org/>。
[oneM2M] OneM2M, "oneM2M Service Layer Standards for M2M and IoT", 2017, <http://www.onem2m.org/>.
[oneM2M] OneM2M、「oneM2M Service Layer Standards for M2M and IoT」、2017、<http://www.onem2m.org/>。
[Overlay_ICN] Shailendra, S.,et al., "A novel overlay architecture for Information Centric Networking", 2015 21st National Conference on Communications, NCC 2015, DOI 10.1109/NCC.2015.7084921, April 2016, <https://www.researchgate.net/publication/282779666_A_nove l_overlay_architecture_for_Information_Centric_Networking> .
[Overlay_ICN] Shailendra、S.、et al。、 "Information Centric Networking for Information Centric Networking"、2015 21st National Conference on Communications、NCC 2015、DOI 10.1109 / NCC.2015.7084921、April 2016、<https：// www。 researchgate.net/publication/282779666_A_nove l_overlay_architecture_for_Information_Centric_Networking>。
[POINT] Trossen, D., et al., "IP over ICN - The better IP?", 2015 European Conference on Networks and Communications (EuCNC), DOI 10.1109/EuCNC.2015.7194109, June 2015, <https://doi.org/10.1109/EuCNC.2015.7194109>.
[POINT] Trossen、D。他、「IP over ICN-The better IP？」、2015 European Conference on Networks and Communications（EuCNC）、DOI 10.1109 / EuCNC.2015.7194109、2015年6月、<https：// doi .org / 10.1109 / EuCNC.2015.7194109>。
[Ravindran] Ravindran, R., et al., "5G-ICN : Delivering ICN Services over 5G using Network Slicing", IEEE Communications Magazine, Volume 55, Issue 5, DOI 10.1109/MCOM.2017.1600938, October 2016, <https://arxiv.org/abs/1610.01182>.
[Ravindran] Ravindran、R.、et al。、 "5G-ICN：Delivering 5G over 5G Network Slicing"、IEEE Communications Magazine、Volume 55、Issue 5、DOI 10.1109 / MCOM.2017.1600938、October 2016、<https： //arxiv.org/abs/1610.01182>。
[Reed] Reed, M., et al., "Stateless multicast switching in software defined networks", 2016 IEEE International Conference on Communications (ICC), DOI 10.1109/ICC.2016.7511036, May 2016, <https://doi.org/10.1109/ICC.2016.7511036>.
[リード]リード他、「ソフトウェア定義ネットワークにおけるステートレスマルチキャストスイッチング」、2016 IEEE International Conference on Communications（ICC）、DOI 10.1109 / ICC.2016.7511036、May 2016、<https://doi.org /10.1109/ICC.2016.7511036>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc6920>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-editor。 org / info / rfc7252>。
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7426] Haleplidis、E。、編、Pentikousis、K。、編、Denazis、S.、Hadi Salim、J.、Meyer、D.、O。Koufopavlou、「ソフトウェア定義ネットワーキング（SDN）：レイヤーand Architecture Terminology」、RFC 7426、DOI 10.17487 / RFC7426、2015年1月、<https://www.rfc-editor.org/info/rfc7426>。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、Ed。 C. Pignataro、編、「Service Function Chaining（SFC）Architecture」、RFC 7665、DOI 10.17487 / RFC7665、2015年10月、<https://www.rfc-editor.org/info/rfc7665>。
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.
[RFC7927] Kutscher、D.、Ed。、Eum、S.、Pentikousis、K.、Psaras、I.、Corujo、D.、Saucez、D.、Schmidt、T。、およびM. Waehlisch、「情報中心型Networking（ICN）Research Challenges」、RFC 7927、DOI 10.17487 / RFC7927、2016年7月、<https://www.rfc-editor.org/info/rfc7927>。
[RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016, <https://www.rfc-editor.org/info/rfc7945>.
[RFC7945] Pentikousis、K.、Ed。、Ohlman、B.、Davies、E.、Spirou、S。、およびG. Boggia、「情報中心のネットワーキング：評価とセキュリティに関する考慮事項」、RFC 7945、DOI 10.17487 / RFC7945 、2016年9月、<https://www.rfc-editor.org/info/rfc7945>。
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, DOI 10.17487/RFC8075, February 2017, <https://www.rfc-editor.org/info/rfc8075>.
[RFC8075] Castellani、A.、Loreto、S.、Rahman、A.、Fossati、T。、およびE. Dijk、「実装のマッピングのガイドライン：HTTPから制約付きアプリケーションプロトコル（CoAP）」、RFC 8075、DOI 10.17487 / RFC8075、2017年2月、<https://www.rfc-editor.org/info/rfc8075>。
[RFC8568] Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM., Aranda, P., and P. Lynch, "Network Virtualization Research Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019, <https://www.rfc-editor.org/info/rfc8568>.
[RFC8568]バーナードス、CJ。、ラーマン、A。、ズニーガ、JC。、コントレラス、LM。、アランダ、P。、およびP.リンチ、「Network Virtualization Research Challenges」、RFC 8568、DOI 10.17487 / RFC8568、2019年4月、<https://www.rfc-editor.org/info/rfc8568>。
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.
[RFC8569] Mosko、M.、Solis、I。、およびC. Wood、「Content-Centric Networking（CCNx）Semantics」、RFC 8569、DOI 10.17487 / RFC8569、2019年7月、<https：//www.rfc-editor .org / info / rfc8569>。
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.
[RFC8609] Mosko、M.、Solis、I。、およびC. Wood、「TLV形式のContent-Centric Networking（CCNx）メッセージ」、RFC 8609、DOI 10.17487 / RFC8609、2019年7月、<https：// www。 rfc-editor.org/info/rfc8609>。
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/info/rfc8613>.
[RFC8613] Selander、G.、Mattsson、J.、Palombini、F。、およびL. Seitz、「制約付きRESTful環境のオブジェクトセキュリティ（OSCORE）」、RFC 8613、DOI 10.17487 / RFC8613、2019年7月、<https：/ /www.rfc-editor.org/info/rfc8613>。
[SAIL] SAIL, "Scalable and Adaptive Internet Solutions (SAIL)", <http://www.sail-project.eu/>.
[SAIL] SAIL、「Scalable and Adaptive Internet Solutions（SAIL）」、<http://www.sail-project.eu/>。
[SAIL_Content_Delivery] FP7, "NetInf Content Delivery and Operations", Objective FP7-ICT-2009-5-257448/D-3.2, January 2013, <https://sail-project.eu/wp-content/uploads/2012/06/ SAIL_DB2_v1_0_final-Public.pdf>.
[SAIL_Content_Delivery] FP7、「NetInf Content Delivery and Operations」、目的FP7-ICT-2009-5-257448 / D-3.2、2013年1月、<https://sail-project.eu/wp-content/uploads/2012/ 06 / SAIL_DB2_v1_0_final-Public.pdf>。
[SAIL_Prototyping] FP7, "Prototyping and Evaluation", Objective FP7-ICT-2009-5-257448/D.B.4, March 2013, <http://www.sail-project.eu/wp-content/uploads/2013/05/ SAIL_DB4_v1.1_Final_Public.pdf>.
[SAIL_Prototyping] FP7、「プロトタイピングと評価」、目的FP7-ICT-2009-5-257448 / DB4、2013年3月、<http://www.sail-project.eu/wp-content/uploads/2013/05 / SAIL_DB4_v1.1_Final_Public.pdf>。
[Tateson] Tateson, J., et al., "Final Evaluation Report on Deployment Incentives and Business Models", PSIRP, Version 1.0, May 2010, <http://www.psirp.org/files/Deliverables/FP7-INFSO-ICT-216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf>.
[Tateson] Tateson、J。、他、「展開インセンティブとビジネスモデルに関する最終評価レポート」、PSIRP、バージョン1.0、2010年5月、<http://www.psirp.org/files/Deliverables/FP7-INFSO -ICT-216173-PSIRP-D4.6_FinalReportOnDeplIncBusinessModels.pdf>。
[Techno_Economic] Trossen, D. and A. Kostopoulos, "Techno-Economics Aspects of Information-Centric Networking", Volume 2, Journal for Information Policy , DOI 10.5325/jinfopoli.2.2012.0026, June 2012, <https://doi.org/10.5325/jinfopoli.2.2012.0026>.
[Techno_Economic] Trossen、D。およびA. Kostopoulos、「情報中心型ネットワーキングのテクノ経済的側面」、第2巻、情報政策ジャーナル、DOI 10.5325 / jinfopoli.2.2012.0026、2012年6月、<https：// doi .org / 10.5325 / jinfopoli.2.2012.0026>。
[UMOBILE-2] Sarros, C., et al., "Connecting the Edges: A Universal, Mobile-Centric, and Opportunistic Communications Architecture", IEEE Communications Magazine, Volume 56, Issue 2, DOI 10.1109/MCOM.2018.1700325, February 2018, <https://doi.org/10.1109/MCOM.2018.1700325>.
[UMOBILE-2] Sarros、C.、et al。、 "Connecting the Edges：A Universal、Mobile-Centtric、and Opportunistic Communications Architecture"、IEEE Communications Magazine、Volume 56、Issue 2、DOI 10.1109 / MCOM.2018.1700325、February 2018、<https://doi.org/10.1109/MCOM.2018.1700325>。
[UMOBILE-3] Tavares, M., Aponte, O., and P. Mendes, "Named-data Emergency Network Services", MobiSys '18: Proceedings of the 16th Annual International Conference on Mobile Systems, Applications, and Services, DOI 10.1145/3210240.3210809, June 2018, <https://doi.org/10.1145/3210240.3210809>.
[UMOBILE-3] Tavares、M.、Aponte、O。、およびP. Mendes、「Named-data Emergency Network Services」、MobiSys '18：Proceedings of the 16th Annual International Conference on Mobile Systems、Applications、and Services、DOI 10.1145 / 3210240.3210809、2018年6月、<https://doi.org/10.1145/3210240.3210809>。
[UMOBILE-4] Amaral, L., et al., "Oi! - Opportunistic Data Transmission Based on Wi-Fi Direct", 2016 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), DOI 10.1109/INFCOMW.2016.7562142, April 2016, <https://doi.org/10.1109/INFCOMW.2016.7562142>.
[UMOBILE-4] Amaral、L.、et al。、 "Oi！-Opportunistic Data Transmission Based on Wi-Fi Direct"、2016 IEEE Conference on Computer Communications Workshops（INFOCOM WKSHPS）、DOI 10.1109 / INFCOMW.2016.7562142、April 2016 、<https://doi.org/10.1109/INFCOMW.2016.7562142>。
[UMOBILE-5] Dynerowicz, S. and P. Mendes, "Demo: named-data networking in opportunistic network", ICN '17: Proceedings of the 4th ACM Conference on Information-Centric Networking, DOI 10.1145/3125719.3132107, September 2017, <https://doi.org/10.1145/3125719.3132107>.
[UMOBILE-5] Dynerowicz、S。およびP. Mendes、「Demo：named-data networking in opportunistic network」、ICN '17：Proceedings of the 4th ACM Conference on Information-Centric Networking、DOI 10.1145 / 3125719.3132107、September 2017、 <https://doi.org/10.1145/3125719.3132107>。
[UMOBILE-6] Mendes, P.,et al., "Information-centric routing for opportunistic wireless networks", ICN '18: Proceedings of the 5th ACM Conference on Information-Centric Networking, DOI 10.1145/3267955.3269011, September 2018, <https://doi.org/10.1145/3267955.3269011>.
[UMOBILE-6] Mendes、P.、et al。、「情報中心型ルーティング、日和見無線ネットワーク」、ICN '18：Proceedings of the 5th ACM Conference on Information-Centric Networking、DOI 10.1145 / 3267955.3269011、September 2018、< https://doi.org/10.1145/3267955.3269011>。
[UMOBILE-7] Sofia, R., "D4.5 Report on Data Collection and Inference Models", Deliverable, September 2017.
[UMOBILE-7]ソフィアR。、「D4.5データ収集と推論モデルに関するレポート」、成果物、2017年9月。
[UMOBILE-8] Sarros, C., et al., "ICN-based edge service deployment in challenged networks", ICN '17: Proceedings of the 4th ACM Conference on Information-Centric Networking, DOI 10.1145/3125719.3132096, September 2017, <https://doi.org/10.1145/3125719.3132096>.
[UMOBILE-8] Sarros、C.、et al。、 "ICN-based edge service deployment inチャレンジドネットワーク"、ICN '17：Proceedings of the 4th ACM Conference on Information-Centric Networking、DOI 10.1145 / 3125719.3132096、September 2017、 <https://doi.org/10.1145/3125719.3132096>。
[UMOBILE-9] Lertsinsrubtavee, A., et al., "Information-Centric Multi-Access Edge Computing Platform for Community Mesh Networks", COMPASS '18: Proceedings of the 1st ACM SIGCAS Conference on Computing and Sustainable Societies, DOI 10.1145/3209811.3209867, June 2018, <https://doi.org/10.1145/3209811.3209867>.
[UMOBILE-9] Lertsinsrubtavee、A。、他、「コミュニティメッシュネットワークのための情報中心型マルチアクセスエッジコンピューティングプラットフォーム」、COMPASS '18：コンピューティングと持続可能な社会に関する第1回ACM SIGCAS会議の議事録、DOI 10.1145 / 3209811.3209867、2018年6月、<https://doi.org/10.1145/3209811.3209867>。
[UMOBILE-overview] UMOBILE, "Universal, mobile-centric and opportunistic communications architecture", <http://www.umobile-project.eu/>.
[UMOBILE-overview] UMOBILE、「ユニバーサル、モバイル中心、日和見通信アーキテクチャ」、<http://www.umobile-project.eu/>。
[VSER] Ravindran, R., et al., "Towards software defined ICN based edge-cloud services", 2013 IEEE 2nd International Conference on Cloud Networking (CloudNet), DOI 10.1109/CloudNet.2013.6710583, <https://doi.org/10.1109/CloudNet.2013.6710583>.
[VSER] Ravindran、R.、et al。、 "Towards software defined ICN based edge-cloud services"、2013 IEEE 2nd International Conference on Cloud Networking（CloudNet）、DOI 10.1109 / CloudNet.2013.6710583、<https：// doi。 org / 10.1109 / CloudNet.2013.6710583>。
[VSER-Mob] Azgin, A., et al., "Seamless Producer Mobility as a Service in Information-centric Networks", ACM-ICN '16: Proceedings of the 3rd ACM Conference on Information-Centric Networking, DOI 10.1145/2984356.2988521, September 2016, <https://doi.org/10.1145/2984356.2988521>.
[VSER-Mob] Azgin、A。他、「情報中心のネットワークにおけるサービスとしてのシームレスなプロデューサーモビリティ」、ACM-ICN '16：情報中心のネットワーキングに関する第3回ACM会議の議事録、DOI 10.1145 / 2984356.2988521 、2016年9月、<https://doi.org/10.1145/2984356.2988521>。
[White] White, G. and G. Rutz, "Content Delivery with Content-Centric Networking", February 2016, <http://www.cablelabs.com/wp-content/uploads/2016/02/ Content-Delivery-with-Content-Centric-Networking-Feb-2016.pdf>.
[ホワイト]ホワイト、G.、G。ルッツ、「コンテンツ中心のネットワーキングによるコンテンツ配信」、2016年2月、<http://www.cablelabs.com/wp-content/uploads/2016/02/ Content-Delivery- with-Content-Centric-Networking-Feb-2016.pdf>。
Acknowledgments
謝辞
The authors want to thank Alex Afanasyev, Hitoshi Asaeda, Giovanna Carofiglio, Xavier de Foy, Guillaume Doyen, Hannu Flinck, Anil Jangam, Michael Kowal, Adisorn Lertsinsrubtavee, Paulo Mendes, Luca Muscariello, Thomas Schmidt, Jan Seedorf, Eve Schooler, Samar Shailendra, Milan Stolic, Prakash Suthar, Atsushi Mayutan, and Lixia Zhang for their very useful reviews and comments to the document.
著者はアレックスAfanasyev、浅田仁志、ジョバンナ・カロフィリオ、ザビエル・ド・フォイ、ギヨーム・ドイエン、ハンヌ・フリンク、アニル・ジャンガム、マイケル・コワール、アディソルン・ルッサンスルブターヴィー、パウロ・メンデス、ルカ・ムスカリエッロ、トーマス・シュミット、ヤン・セードルマー、イヴ・スクールラーに感謝します、Milan Stolic、Prakash Suthar、Atsushi Mayutan、Lixia Zhangが、このドキュメントに対する非常に有益なレビューとコメントを提供してくれました。
Special thanks to Dave Oran (ICNRG Co-chair) and Marie-Jose Montpetit for their extensive and thoughtful reviews of the document. Their reviews helped to immeasurably improve the document quality.
文書の広範囲にわたる思慮深いレビューを提供してくれたDave Oran（ICNRG共同議長）とMarie-Jose Montpetitに特に感謝します。彼らのレビューは、ドキュメントの品質を計り知れないほど改善するのに役立ちました。
Authors' Addresses
著者のアドレス
Akbar Rahman InterDigital Communications, LLC 1000 Sherbrooke Street West, 10th floor Montreal H3A 3G4 Canada
Akbar Rahman InterDigital Communications、LLC 1000 Sherbrooke Street West、10th floor Montreal H3A 3G4 Canada
Email: Akbar.Rahman@InterDigital.com
URI: http://www.InterDigital.com/
Dirk Trossen Huawei Technologies Duesseldorf GmbH Riesstrasse 25 80992 Munich Germany
Dirk Trossen Huawei Technologies Duesseldorf GmbH Riesstrasse 25 80992ミュンヘンドイツ
Email: dirk.trossen@huawei.com
URI: http://www.huawei.com/
Dirk Kutscher University of Applied Sciences Emden/Leer Constantiapl. 4 26723 Emden Germany
ダーククッチャー応用科学大学エムデン/レアーコンスタンシア4 26723エムデンドイツ
Email: ietf@dkutscher.net
URI: https://www.hs-emden-leer.de/en/
Ravi Ravindran Sterlite Technologies 5201 Greatamerica Pkwy Santa Clara, 95054 United States of America
Ravi Ravindran Sterlite Technologies 5201 Greatamerica Pkwy Santa Clara、95054アメリカ合衆国
Email: ravi.ravindran@gmail.com