[要約] 要約:RFC 7945は、情報中心ネットワーキング(ICN)の評価とセキュリティに関する考慮事項についてのガイドラインです。 目的:このRFCの目的は、ICNの利点と課題を評価し、セキュリティの観点からICNの実装と展開に関する指針を提供することです。

Internet Research Task Force (IRTF)                  K. Pentikousis, Ed.
Request for Comments: 7945                                    Travelping
Category: Informational                                        B. Ohlman
ISSN: 2070-1721                                                 Ericsson
                                                               E. Davies
                                                  Trinity College Dublin
                                                               S. Spirou
                                                        Intracom Telecom
                                                               G. Boggia
                                                     Politecnico di Bari
                                                          September 2016
        

Information-Centric Networking: Evaluation and Security Considerations

情報中心のネットワーキング:評価とセキュリティに関する考慮事項

Abstract

概要

This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.

このドキュメントでは、情報中心型ネットワーキング(ICN)の評価に関するいくつかの考慮事項を示し、ネットワークセキュリティに対するICNの影響に光を当てます。また、ICN領域の研究者が現在利用できる評価ツールを調査し、方法論と測定基準に関する提案を提供します。

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 <insert_name> 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は、Internet Research Task Force(IRTF)の<挿入_name>研究グループの合意を表します。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7945.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7945で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Evaluation Considerations  . . . . . . . . . . . . . . . . . .  4
     2.1.  Topology Selection . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Traffic Load . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Choosing Relevant Metrics  . . . . . . . . . . . . . . . . 10
       2.3.1.  Traffic Metrics  . . . . . . . . . . . . . . . . . . . 13
       2.3.2.  System Metrics . . . . . . . . . . . . . . . . . . . . 14
     2.4.  Resource Equivalence and Trade-Offs  . . . . . . . . . . . 16
   3.  ICN Security Aspects . . . . . . . . . . . . . . . . . . . . . 16
     3.1. Authentication  . . . . . . . . . . . . . . . . . . . . . . 17
     3.2. Authorization, Access Control, and Logging  . . . . . . . . 18
     3.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     3.4. Changes to the Network Security Threat Model  . . . . . . . 20
   4.  Evaluation Tools . . . . . . . . . . . . . . . . . . . . . . . 21
     4.1.  Open-Source Implementations  . . . . . . . . . . . . . . . 21
     4.2.  Simulators and Emulators . . . . . . . . . . . . . . . . . 22
       4.2.1.  ndnSIM . . . . . . . . . . . . . . . . . . . . . . . . 22
       4.2.2.  ccnSIM . . . . . . . . . . . . . . . . . . . . . . . . 23
       4.2.3.  Icarus Simulator . . . . . . . . . . . . . . . . . . . 23
     4.3.  Experimental Facilities  . . . . . . . . . . . . . . . . . 24
       4.3.1.  Open Network Lab (ONL) . . . . . . . . . . . . . . . . 24
       4.3.2.  POINT Testbed  . . . . . . . . . . . . . . . . . . . . 25
       4.3.3.  CUTEi: Container-Based ICN Testbed . . . . . . . . . . 25
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 26
   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . . 37
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
        
1. Introduction
1. はじめに

Information-Centric Networking (ICN) is a networking concept that arose from the desire to align the operation model of a network with the model of its typical use. For TCP/IP networks, this implies changing the mechanisms of data access and transport from a host-to-host model to a user-to-information model. The premise is that the effort invested in changing models will be offset, or even surpassed, by the potential of a "better" network. However, such a claim can be validated only if it is quantified.

情報中心型ネットワーキング(ICN)は、ネットワークの運用モデルをその典型的な使用のモデルに合わせたいという願望から生まれたネットワーキングの概念です。 TCP / IPネットワークの場合、これはデータアクセスおよびトランスポートのメカニズムをホストからホストへのモデルからユーザーから情報へのモデルに変更することを意味します。モデルの変更に費やされた労力は、「より良い」ネットワークの可能性によって相殺されるか、さらには超えることを前提としています。ただし、そのような主張は、それが定量化されている場合にのみ検証できます。

Different ICN approaches are evaluated in the peer-reviewed literature using a mixture of theoretical analysis, simulation and emulation techniques, and empirical (testbed) measurements. The specific methodology employed may depend on the experimentation goal, e.g., whether one wants to evaluate scalability, quantify resource utilization, or analyze economic incentives. In addition, though, we observe that ease and convenience of setting up and running experiments can sometimes be a factor in published evaluations. As discussed in [RFC7476], the development phase that ICN is going through and the plethora of approaches to tackle the hardest problems make this a very active and growing research area but, on the downside, it also makes it more difficult to compare different proposals on an equal footing.

理論的分析、シミュレーションとエミュレーション技術、および経験的(テストベッド)測定を組み合わせて、査読済みの文献でさまざまなICNアプローチが評価されています。採用される特定の方法論は、スケーラビリティの評価、リソース使用率の定量化、経済的インセンティブの分析など、実験の目的によって異なります。さらに、公開された評価では、実験の設定と実行の容易さと利便性が要因となる場合があることも認めています。 [RFC7476]で説明されているように、ICNが進行中の開発フェーズと最も困難な問題に取り組むための多くのアプローチにより、これは非常に活発で成長している研究分野になりますが、マイナス面では、さまざまな提案を比較することも困難になります平等に。

Performance evaluation using actual network deployments has the advantage of realistic workloads and reflects the environment where the service or protocol is to be deployed. In the case of ICN, however, it is not currently clear what qualifies as a "realistic workload". Trace-based analysis of ICN is in its infancy, and more work is needed towards defining characteristic workloads for ICN evaluation studies. Accordingly, the experimental process and the evaluation methodology per se are actively being researched for different ICN architectures. Numerous factors affect the experimental results, including the topology selected; the background traffic that an application is being subjected to; network conditions such as available link capacities, link delays, and loss-rate characteristics throughout the selected topology; failure and disruption patterns; node mobility; and the diversity of devices used.

実際のネットワーク展開を使用したパフォーマンス評価には、現実的なワークロードの利点があり、サービスまたはプロトコルが展開される環境を反映しています。ただし、ICNの場合、現時点では「現実的なワークロード」と見なされるものが明確ではありません。 ICNのトレースベースの分析はまだ始まったばかりであり、ICN評価研究の特徴的なワークロードを定義するためには、さらに多くの作業が必要です。したがって、実験プロセスと評価方法自体は、さまざまなICNアーキテクチャに対して積極的に研究されています。選択したトポロジーを含む多数の要因が実験結果に影響します。アプリケーションが受けるバックグラウンドトラフィック。選択したトポロジ全体で利用可能なリンク容量、リンク遅延、損失率特性などのネットワーク条件。障害と混乱のパターン;ノードの移動性;使用されるデバイスの多様性。

The goal of this document is to summarize evaluation guidelines and tools alongside suggested data sets and high-level approaches. We expect this to be of interest to the ICN community as a whole, as it can assist researchers and practitioners alike to compare and contrast different ICN designs, as well as with the state of the art in host-centric solutions, and identify the respective strengths and weaknesses. We note that, apart from the technical evaluation of the functionality of an ICN architecture, the future success of ICN will be largely driven by its deployability and economic viability. Therefore, ICN evaluations should assess incremental deployability in the existing network environment together with a view of how the technical functions will incentivize deployers to invest in the capabilities that allow the architecture to spread across the network.

このドキュメントの目的は、推奨されるデータセットと高レベルのアプローチと共に評価ガイドラインとツールをまとめることです。これは、ICNコミュニティ全体にとって興味深いものになると期待しています。これは、さまざまなICN設計をホストおよびセントリックソリューションの最先端技術と比較および対照し、それぞれを特定するために、研究者と実践者の両方を支援することができるためです。強みと弱み。 ICNアーキテクチャの機能の技術的評価とは別に、ICNの将来の成功は、その配備可能性と経済的実行可能性に大きく左右されることに注意してください。したがって、ICNの評価では、既存のネットワーク環境での段階的な展開可能性を評価するとともに、アーキテクチャがネットワーク全体に広がることを可能にする機能に投資する技術者の動機をどのように奨励するかについての見方を評価する必要があります。

This document has been produced by the IRTF Information-Centric Networking Research Group (ICNRG). The main objective of the ICNRG is to couple ongoing ICN research in the above areas with solutions that are relevant for evolving the Internet at large. The ICNRG produces documents that provide guidelines for experimental activities in the area of ICN so that different, alternative solutions can be compared consistently, and information sharing can be accomplished for experimental deployments. This document incorporates input from ICNRG participants and their corresponding text contributions; it has been reviewed by several ICNRG active participants (see the Acknowledgments), and represents the consensus of the research group. That said, note that this document does not constitute an IETF standard; see also [RFC5743].

このドキュメントは、IRTF情報中心のネットワーキング研究グループ(ICNRG)によって作成されました。 ICNRGの主な目的は、上記の分野で進行中のICN研究を、インターネット全体の進化に関連するソリューションと結びつけることです。 ICNRGは、ICNの分野での実験活動のガイドラインを提供するドキュメントを作成します。これにより、さまざまな代替ソリューションを一貫して比較できるようになり、実験展開で情報共有を実現できます。このドキュメントには、ICNRGの参加者からのインプットとそれに対応するテキストの寄稿が組み込まれています。これは、ICNRGのアクティブな参加者(謝辞を参照)によってレビューされ、研究グループのコンセンサスを表しています。ただし、このドキュメントはIETF標準を構成するものではないことに注意してください。 [RFC5743]も参照してください。

The remainder of this document is organized as follows. Section 2 presents various techniques and considerations for evaluating different ICN architectures. Section 3 discusses the impact of ICN on network security. Section 4 surveys the tools currently available to ICN researchers.

このドキュメントの残りの部分は、次のように構成されています。セクション2では、さまざまなICNアーキテクチャを評価するためのさまざまな手法と考慮事項について説明します。セクション3では、ネットワークセキュリティに対するICNの影響について説明します。セクション4では、ICNの研究者が現在利用できるツールについて概説します。

2. Evaluation Considerations
2. 評価に関する考慮事項

It is clear that the way we evaluate IP networks will not be directly applicable to evaluating ICN. In IP, the focus is on the performance and characteristics of end-to-end connections between a source and a destination. In ICN, the "source" responding to a request can be any ICN node in the network and may change from request to request. This makes it difficult to use concepts like delay and throughput in a traditional way. In addition, evaluating resource usage in ICN is a more complicated task, as memory used for caching affects delays and use of transmission resources; see the discussion on resource equivalents in Section 2.4.

IPネットワークの評価方法がICNの評価に直接適用されないことは明らかです。 IPでは、送信元と宛先の間のエンドツーエンド接続のパフォーマンスと特性に焦点が当てられています。 ICNでは、要求に応答する「ソース」はネットワーク内の任意のICNノードである可能性があり、要求ごとに変わる可能性があります。これにより、遅延やスループットなどの概念を従来の方法で使用することが困難になります。さらに、キャッシュに使用されるメモリが遅延と送信リソースの使用に影響を与えるため、ICNでのリソース使用状況の評価はより複雑なタスクです。セクション2.4の同等のリソースに関する説明を参照してください。

There are two major types of evaluations of ICN that we see a need to make. One type is to compare ICN to traditional networking, and the other type is to compare different ICN implementations and approaches against each other.

ICNの評価には、主に2つのタイプがあります。 1つはICNを従来のネットワーキングと比較するタイプで、もう1つは異なるICN実装とアプローチを相互に比較するタイプです。

In this section, we detail some of the functional components needed when evaluating different ICN implementations and approaches.

このセクションでは、さまざまなICN実装とアプローチを評価するときに必要な機能コンポーネントの一部について詳しく説明します。

2.1. Topology Selection
2.1. トポロジーの選択

There's a wealth of earlier work on topology selection for simulation and performance evaluation of host-centric networks. While the classic dumbbell topology is regarded as inappropriate for ICN, most ICN studies so far have been based on that earlier work for host-centric networks [RFC7476]. However, there is no single topology that can be used to easily evaluate all aspects of ICN. Therefore, one should choose from a range of topologies depending on the focus of the evaluation.

ホスト中心のネットワークのシミュレーションとパフォーマンス評価のためのトポロジー選択については、これまでに多くの作業が行われています。古典的なダンベルトポロジーはICNには不適切であると見なされていますが、これまでのほとんどのICN研究は、ホスト中心のネットワーク[RFC7476]の初期の研究に基づいています。ただし、ICNのすべての側面を簡単に評価するために使用できる単一のトポロジはありません。したがって、評価の焦点に応じて、さまざまなトポロジから選択する必要があります。

For scalability and resilience studies, there is a wide range of synthetic topologies, such as the Barabasi-Albert model [Barabasi99] and the Watts-Strogatz small-world topology [Watts98]. These allow experiments to be performed whilst controlling various key parameters (e.g., node degree). These synthetic topologies are appropriate in the general case, as there are no practical assurances that a future information-centric network will have the same topology as any of today's networks.

スケーラビリティと復元力の研究では、バラバシ-アルバートモデル[Barabasi99]やワッツストロガッツスモールワールドトポロジ[Watts98]など、さまざまな合成トポロジがあります。これらにより、さまざまな重要なパラメーター(ノードの次数など)を制御しながら実験を行うことができます。これらの合成トポロジは、将来の情報中心のネットワークが現在のネットワークと同じトポロジを持つことを実際に保証するものではないため、一般的なケースに適しています。

When studies look at cost (e.g., transit cost) or migration to ICN, realistic topologies should be used. These can be inferred from Internet traces, such as the CAIDA Macroscopic Internet Topology Data Kit (http://www.caida.org/data/active/internet-topology-data-kit) and Rocketfuel (http://www.cs.washington.edu/research/networking/rocketfuel). A problem is the large size of the topology (approximately 45K Autonomous Systems, close to 200K links), which may limit the scalability of the employed evaluation tool. Katsaros et al. [Katsaros15] address this problem by using scaled down topologies created following the methodology described in [Dimitropoulos09].

調査でコスト(トランジットコストなど)またはICNへの移行を検討する場合は、現実的なトポロジを使用する必要があります。これらは、CAIDA Macroscopic Internet Topology Data Kit(http://www.caida.org/data/active/internet-topology-data-kit)やRocketfuel(http://www.cs)などのインターネットトレースから推測できます。 .washington.edu / research / networking / rocketfuel)。問題はトポロジーのサイズが大きい(約45Kの自律システム、200Kのリンクに近い)ことであり、採用されている評価ツールのスケーラビリティを制限する可能性があります。 Katsaros et al。 [Katsaros15]は、[Dimitropoulos09]で説明されている方法論に従って作成された、縮小されたトポロジを使用してこの問題に対処します。

Studies that focus on node or content mobility can benefit from topologies and their dynamic aspects as used in the Delay-Tolerant Networking (DTN) community. As mentioned in [RFC7476], DTN traces are available to be used in such ICN evaluations.

ノードまたはコンテンツのモビリティに焦点を当てた研究は、遅延耐性ネットワーク(DTN)コミュニティで使用されているトポロジとその動的な側面の恩恵を受けることができます。 [RFC7476]で述べられているように、DTNトレースはそのようなICN評価で使用できます。

As with host-centric topologies, defining just a node graph will not be enough for most ICN studies. The experimenter should also clearly define and list the respective matrices that correspond to the network, storage, and computation capacities available at each node as well as the delay characteristics of each link [Montage]. Real values for such parameters can be taken from existing platforms such as iPlane (http://iplane.cs.washington.edu). Synthetic values could be produced with specific tools [Kaune09].

ホスト中心のトポロジと同様に、ノードグラフを定義するだけでは、ほとんどのICN研究には不十分です。また、実験者は、各ノードで利用可能なネットワーク、ストレージ、および計算能力に対応するそれぞれの行列と、各リンクの遅延特性[モンタージュ]を明確に定義してリストする必要があります。このようなパラメーターの実際の値は、iPlane(http://iplane.cs.washington.edu)などの既存のプラットフォームから取得できます。合成値は、特定のツール[Kaune09]で生成できます。

2.2. Traffic Load
2.2. トラフィック負荷

In this subsection, we provide a set of common guidelines, in the form of what we will refer to as a content catalog for different scenarios. This catalog, which is based on previously published work, can be used to evaluate different ICN proposals, for instance, on routing, congestion control, and performance, and can be considered as other kinds of ICN contributions emerge. As we are still lacking ICN-specific traffic workloads, we can currently only extrapolate from today's workloads. A significant challenge then relates to the identification of the applications contributing to the observed traffic (e.g., Web or peer-to-peer), as well as to the exact amount of traffic they contribute to the overall traffic mixture. Efforts in this direction can take heed of today's traffic mix comprising Web, peer-to-peer file sharing, and User-Generated Content (UGC) platforms (e.g., YouTube), as well as Video on Demand (VoD) services. Publicly available traces for these include those from web sites such as the MultiProbe Framework <http://multiprobe.ewi.tudelft.nl/multiprobe.html>, <http://an.kaist.ac.kr/traces/IMC2007.html> (see also [Cha07]), and the UMass Trace Repository <http://traces.cs.umass.edu/index.php/Network/Network>.

このサブセクションでは、さまざまなシナリオのコンテンツカタログとして参照する形式で、一連の一般的なガイドラインを提供します。このカタログは、以前に公開された作業に基づいており、ルーティング、輻輳制御、パフォーマンスなど、さまざまなICN提案を評価するために使用できます。また、他の種類のICNの貢献が出現したときに考慮することができます。 ICN固有のトラフィックワークロードがまだ不足しているため、現在推定できるのは今日のワークロードからのみです。次に、重要な課題は、観測されたトラフィック(Webまたはピアツーピアなど)に寄与しているアプリケーションの特定と、それらが全体的なトラフィックの混合に寄与しているトラフィックの正確な量に関係しています。この方向への取り組みは、Web、ピアツーピアファイル共有、ユーザー生成コンテンツ(UGC)プラットフォーム(YouTubeなど)、ビデオオンデマンド(VoD)サービスなど、今日のトラフィックミックスに注意する必要があります。これらの公開トレースは、MultiProbe Framework <http://multiprobe.ewi.tudelft.nl/multiprobe.html>、<http://an.kaist.ac.kr/traces/IMC2007などのWebサイトからのトレースを含みます。 html>([Cha07]も参照)、およびUMassトレースリポジトリ<http://traces.cs.umass.edu/index.php/Network/Network>。

Taking a more systematic approach, and with the purpose of modeling the traffic load, we can resort to measurement studies that investigate the composition of Internet traffic, such as [Labovitz10] and [Maier09]. In [Labovitz10], a large-scale measurement study was performed, with the purpose of studying the traffic crossing inter-domain links. The results indicate the dominance of Web traffic, amounting to 52% over all measured traffic. However, Deep Packet Inspection (DPI) techniques reveal that 25-40% of all HTTP traffic actually carries video traffic. Results from DPI techniques also reveal the difficulty in correctly identifying the application type in the case of P2P traffic: mapping observed port numbers to well-known applications shows P2P traffic constituting only 0.85% of overall traffic, while DPI raises this percentage to 18.32% [Labovitz10]. Relevant studies on a large ISP show that the percentage of P2P traffic ranges from 17% to 19% of overall traffic [Maier09]. Table 1 provides an overview of these figures. The "other" traffic type denotes traffic that cannot be classified in any of the first three application categories, and it consists of unclassified traffic and traffic heavily fragmented into several applications (e.g., 0.17% DNS traffic).

より体系的なアプローチを採用し、トラフィック負荷をモデル化する目的で、[Labovitz10]や[Maier09]などのインターネットトラフィックの構成を調査する測定調査に頼ることができます。 [Labovitz10]では、ドメイン間リンクを通過するトラフィックを調査する目的で、大規模な測定調査が行われました。この結果は、測定されたすべてのトラフィックの52%に相当するWebトラフィックの優位性を示しています。ただし、ディープパケットインスペクション(DPI)技術では、すべてのHTTPトラフィックの25〜40%が実際にビデオトラフィックを伝送していることがわかります。 DPI技術の結果は、P2Pトラフィックの場合にアプリケーションタイプを正しく識別することの難しさも明らかにしています。観測されたポート番号を既知のアプリケーションにマッピングすると、P2Pトラフィックが全体のトラフィックの0.85%のみを構成しているのに対し、DPIはこの割合を18.32%に上げています。 Labovitz10]。大規模なISPに関する関連研究では、P2Pトラフィックの割合がトラフィック全体の17%から19%に及ぶことが示されています[Maier09]。表1に、これらの図の概要を示します。 「その他」のトラフィックタイプは、最初の3つのアプリケーションカテゴリのいずれにも分類できないトラフィックを示し、未分類のトラフィックと、いくつかのアプリケーションに大きく断片化されたトラフィック(0.17%DNSトラフィックなど)で構成されます。

                   Traffic Type | Ratio
                   =====================
                   Web          | 31-39%
                   ---------------------
                   P2P          | 17-19%
                   ---------------------
                   Video        | 13-21%
                   ---------------------
                   Other        | 29-31%
                   =====================
        

Table 1: Traffic Type Ratios of Total Traffic [Labovitz10] [Maier09]

表1:総トラフィックのトラフィックタイプの比率[Labovitz10] [Maier09]

The content catalog for each type of traffic can be characterized by a specific set of parameters:

トラフィックのタイプごとのコンテンツカタログは、特定のパラメーターセットによって特徴付けることができます。

a) the cardinality of the estimated content catalog

a) 推定コンテンツカタログのカーディナリティ

b) the size of the exchanged contents (either chunks or entire named information objects)

b) 交換されるコンテンツのサイズ(チャンクまたは名前付き情報オブジェクト全体)

c) the popularity of objects (expressed in their request frequency)

c) オブジェクトの人気度(リクエスト頻度で表現)

In most application types, the popularity distribution follows some power law, indicating that a small number of information items trigger a large proportion of the entire set of requests. The exact shape of the power law popularity distribution directly impacts the performance of the underlying protocols. For instance, highly skewed popularity distributions (e.g., a Zipf-like distribution with a high slope value) favor the deployment of caching schemes, since caching a very small set of information items can dramatically increase the cache hit ratio.

ほとんどのアプリケーションタイプでは、人気度分布はいくつかのべき法則に従っており、少数の情報アイテムがリクエスト全体の大部分をトリガーすることを示しています。べき法則の人気分布の正確な形状は、基礎となるプロトコルのパフォーマンスに直接影響します。たとえば、非常に歪んだ人気分布(たとえば、勾配値が高いZipfのような分布)では、非常に小さい情報アイテムのセットをキャッシュするとキャッシュヒット率が大幅に向上するため、キャッシュスキームの展開が優先されます。

Several studies in the past few years have stated that Zipf's law is the discrete distribution that best represents the request frequency in a number of application scenarios, ranging from the Web to VoD services. The key aspect of this distribution is that the frequency of a content request is inversely proportional to the rank of the content itself, i.e., the smaller the rank, the higher the request frequency. If M denotes the content catalog cardinality and 1 <= i <= M denotes the rank of the i-th most popular content, we can express the probability of requesting the content with rank "i" as:

過去数年間のいくつかの調査では、Zipfの法則は、WebからVoDサービスに至るまでのさまざまなアプリケーションシナリオでの要求頻度を最もよく表す離散分布であると述べています。この分布の重要な点は、コンテンツ要求の頻度がコンテンツ自体のランクに反比例することです。つまり、ランクが小さいほど、要求頻度が高くなります。 Mがコンテンツカタログのカーディナリティを示し、1 <= i <= Mがi番目に人気のコンテンツのランクを示す場合、ランク "i"のコンテンツを要求する確率は次のように表すことができます。

   P(X=i) = (1 / i^(alpha)) / C, with C = SUM(1 / j^(alpha)), alpha > 0
   where the sum is obtained considering all values of j, 1 <= j <= M.
        

A recent analysis of HTTP traffic showed that content popularity is better reflected by a trimodal distribution model in which the head and tail of a Zipf distribution (with slope value 0.84) are replaced by two discrete Weibull distributions with shape parameter values 0.5 and 0.24, respectively [IMB2014].

HTTPトラフィックの最近の分析では、Zipf分布(勾配値0.84)の頭と尾がそれぞれ形状パラメーター値0.5および0.24の2つの離散ワイブル分布に置き換えられた三峰分布モデルによって、コンテンツの人気がよりよく反映されることが示されました[IMB2014]。

A variation of the Zipf distribution, termed the Mandelbrot-Zipf distribution was suggested [Saleh06] to better model environments where nodes can locally store previously requested content. For example, it was observed that peer-to-peer file-sharing applications typically exhibited a 'fetch-at-most-once' style of behavior. This is because peers tend to persistently store the files they download, a behavior that may also be prevalent in ICN.

Mandelbrot-Zipf分布と呼ばれるZipf分布のバリエーションは、ノードが以前に要求されたコンテンツをローカルに保存できる環境をより適切にモデル化するために提案されました[Saleh06]。たとえば、ピアツーピアのファイル共有アプリケーションは、通常、「1回限りのフェッチ」スタイルの動作を示します。これは、ピアがダウンロードしたファイルを永続的に保存する傾向があるためです。これは、ICNでもよく見られる動作です。

Popularity can also be characterized in terms of:

人気は次の点でも特徴付けられます。

a) The temporal dynamics of popularity, i.e., how requests are distributed in time. The popularity distribution expresses the number of requests submitted for each information item participating into a certain workload. However, they do not describe how these requests are distributed in time. This aspect is of primary importance when considering the performance of caching schemes since the ordering of the requests obviously affects the contents of a cache. For example, with a Least Frequently Used (LFU) cache replacement policy, if all requests for a certain item are submitted close in time, the item is unlikely to be evicted from the cache, even by a (globally) more popular item whose requests are more evenly distributed in time. The temporal ordering of requests gains even more importance when considering workloads consisting of various applications, all competing for the same cache space.

a) 人気の時間的ダイナミクス、つまりリクエストが時間内にどのように分散されるか。人気分布は、特定のワークロードに参加している各情報アイテムに対して送信されたリクエストの数を表します。ただし、これらの要求が時間内にどのように分散されるかについては説明していません。要求の順序は明らかにキャッシュの内容に影響を与えるため、この側面は、キャッシュスキーマのパフォーマンスを検討する場合に最も重要です。たとえば、Least Frequently Used(LFU)キャッシュ置換ポリシーでは、特定のアイテムに対するすべてのリクエストが時間内に送信された場合、そのリクエストが(グローバルに)より人気のあるアイテムであっても、キャッシュから削除される可能性は低くなります。より均等に分散されます。リクエストの時間的順序は、すべてが同じキャッシュスペースで競合するさまざまなアプリケーションで構成されるワークロードを検討するときに、さらに重要になります。

b) The spatial locality of popularity i.e., how requests are distributed throughout a network. The importance of spatial locality relates to the ability to avoid redundant traffic in the network. If requests are highly localized in some area of the entire network, then similar requests can be more efficiently served with mechanisms such as caching and/or multicast, i.e., the concentration of similar requests in a limited area of the network allows increasing the perceived cache hit ratios at caches in the area and/or the traffic savings from the use of multicast. Table 2 provides an overview of distributions that can be used to model each of the identified traffic types i.e., Web, Video (based on YouTube measurements), and P2P (based on BitTorrent measurements). These distributions are the outcome of a series of modeling efforts based on measurements of real traffic workloads ([Breslau99] [Mahanti00] [Busari02] [Arlitt97] [Barford98] [Barford99] [Hefeeda08] [Guo07] [Bellissimo04] [Cheng08]

b) 人気の空間的な局所性、つまり、リクエストがネットワーク全体にどのように分散されるか。空間的な局所性の重要性は、ネットワーク内の冗長なトラフィックを回避する機能に関連しています。リクエストがネットワーク全体の特定の領域に高度にローカライズされている場合、キャッシングやマルチキャストなどのメカニズムで同様のリクエストをより効率的に処理できます。つまり、ネットワークの限られたエリアに同様のリクエストを集中させることで、認識されるキャッシュを増やすことができます。エリア内のキャッシュでのヒット率やマルチキャストの使用によるトラフィックの節約。表2は、識別された各トラフィックタイプ(Web、ビデオ(YouTubeの測定に基づく)、およびP2P(BitTorrentの測定に基づく)など)をモデル化するために使用できる分布の概要を示しています。これらの分布は、実際のトラフィックワークロードの測定に基づく一連のモデリング作業の結果です([Breslau99] [Mahanti00] [Busari02] [Arlitt97] [Barford98] [Barford99] [Hefeeda08] [Guo07] [Bellissimo04] [Cheng08]

[Cheng13]). A tool for the creation of synthetic workloads following these models, and also allowing the generation of different traffic mixes, is described in [Katsaros12].

[Cheng13])。これらのモデルに従って合成ワークロードを作成し、さまざまなトラフィックミックスを生成するためのツールについては、[Katsaros12]で説明されています。

       |  Object Size   |  Temporal Locality   | Popularity Distribution
   =====================================================================
   Web | Concatenation  | Ordering via the     | Zipf: p(i)=K/i^a
       | of Lognormal   | Least Recently Used  | i: popularity rank
       | (body) and     | (LRU) stack model    | N: total items
       | Pareto (tail)  | [Busari02]           | K: 1/Sum(1/i^a)
       | [Barford98]    |                      | a: distribution slope
       | [Barford99]    | Exact timing via     | values 0.64-0.84
       |                | exponential          | [Breslau99] [Mahanti00]
       |                | distribution         |
       |                | [Arlitt97]           |
   ---------------------------------------------------------------------
   VoD | Duration/size: | No analytical models | Weibull: k=0.513,
       | Concatenated   |                      | lambda=6010
       | normal; most   | Random distribution  |
       | videos         | across total         | Gamma: k=0.372,
       | ~330 kbit/s    | duration             | theta=23910
       | [Cheng13]      |                      | [Cheng08]
   ---------------------------------------------------------------------
   P2P | Wide variation | Mean arrival rate of | Mandelbrot-Zipf
       | on torrent     | 0.9454 torrents/hour | [Hefeeda08]:
       | sizes          | Peers in a swarm     | p(i)=K/((i+q)/a)
       | [Hefeeda08].   | arrive as            | q: plateau factor,
       | No analytical  | l(t)= l0*e^(-t/tau)  | 5 to 100.
       | models exist:  | l0: initial arrival  | Flatter head than in
       | Sample a real  | rate (87.74 average) | Zipf-like distribution
       | BitTorrent     | tau: object          | (where q=0)
       | distribution   | popularity           |
       | [Bellissimo04] | (1.16 average)*      |
       | or use fixed   | [Guo07]              |
       | value          |                      |
   =====================================================================
        

* Random ordering of swarm births (first request). For each swarm, calculate a different tau. Based on average tau and object popularity. Exponential decay rule for subsequent requests.

* 群れの誕生のランダムな順序付け(最初の要求)。各群について、異なるタウを計算します。平均タウとオブジェクトの人気に基づいています。後続のリクエストの指数関数的減衰ルール。

Table 2: Overview of Traffic Type Models

表2:トラフィックタイプモデルの概要

Table 3 summarizes the content catalog. With this shared point of reference, the use of the same set of parameters (depending on the scenario of interest) among researchers will be eased, and different proposals could be compared on a common base.

表3は、コンテンツカタログをまとめたものです。この共通の参照ポイントにより、研究者間での(関心のあるシナリオに応じた)同じパラメーターセットの使用が容易になり、異なる提案を共通の基準で比較できます。

   Traffic | Catalog  |  Mean Object Size  |  Popularity Distribution
   Load    | Size     |  [Zhou11] [Fri12]  |  [Cha07] [Fri12] [Yu06]
           |[Goog08]  |  [Marciniak08]     |  [Breslau99] [Mahanti00]
           |[Zhang10a]|  [Bellissimo04]    |
           |[Cha07]   |  [Psaras11]        |
           |[Fri12]   |  [Carofiglio11]    |
           |          |                    |
           |          |                    |
           |          |                    |
   ===================================================================
   Web     |  10^12   | Chunk: 1-10 KB     | Zipf with
           |          |                    | 0.64 <= alpha <= 0.83
   -------------------------------------------------------------------
   File    | 5x10^6   | Chunk: 250-4096 KB | Zipf with
   sharing |          | Object: ~800 MB    | 0.75 <= alpha <= 0.82
   -------------------------------------------------------------------
   UGC     |  10^8    | Object: ~10 MB     | Zipf, alpha >= 2
   -------------------------------------------------------------------
   VoD     |  10^4    | Object: ~100 MB    | Zipf, 0.65 <= alpha <= 1
   (+HLS)  |          |    ~1 KB (*)       |
   (+DASH) |          |    ~5.6 KB (*)     |
   ===================================================================
        

UGC = User-Generated Content VoD = Video on Demand HLS = HTTP Live Streaming DASH = Dynamic Adaptive Streaming over HTTP

UGC =ユーザー生成コンテンツVoD =ビデオオンデマンドHLS = HTTPライブストリーミングDASH = HTTPを介した動的適応ストリーミング

(*) Using adaptive video streaming (e.g., HLS and DASH), with an optimal segment length (10 s for HLS and 2 s for DASH) and a bitrate of 4500 kbit/s [RFC7933] [Led12]

(*)アダプティブビデオストリーミング(HLSやDASHなど)を使用し、最適なセグメント長(HLSで10秒、DASHで2秒)とビットレート4500 kbit / s [RFC7933] [Led12]

Table 3: Content Catalog

表3:コンテンツカタログ

2.3. Choosing Relevant Metrics
2.3. 関連するメトリックの選択

Quantification of network performance requires a set of standard metrics. These metrics should be broad enough so they can be applied equally to host-centric and information-centric (or other) networks. This will allow reasoning about a certain ICN approach in relation to an earlier version of the same approach, to another ICN approach, or to the incumbent host-centric approach. It will therefore be less difficult to gauge optimization and research direction. On the other hand, the metrics should be targeted to network performance only and should avoid unnecessary expansion into the physical and application layers. Similarly, at this point, it is more important to capture as metrics only the main figures of merit and to leave more esoteric and less frequent cases for the future.

ネットワークパフォーマンスの定量化には、一連の標準メトリックが必要です。これらのメトリックは、ホスト中心のネットワークと情報中心の(または他の)ネットワークに等しく適用できるように、十分に広範でなければなりません。これにより、特定のICNアプローチを、同じアプローチの以前のバージョン、別のICNアプローチ、または現在のホスト中心のアプローチと比較して推論することができます。したがって、最適化と研究の方向性を評価することはそれほど難しくありません。一方、メトリックはネットワークパフォーマンスのみを対象とし、物理層とアプリケーション層への不要な拡張を回避する必要があります。同様に、この時点では、主要な性能指数のみをメトリックとしてキャプチャし、より難解で頻度の低いケースを将来に残すことがより重要です。

To arrive at a set of relevant metrics, it would be beneficial to look at the metrics used in existing ICN approaches, such as Content-Centric Networking (CCN) [Jacobson09] [VoCCN] [Zhang10b], NetInf [4WARD6.1] [4WARD6.3] [SAIL-B2] [SAIL-B3], PURSUIT [PRST4.5], COMET [CMT-D5.2] [CMT-D6.2], Connect [Muscariello11] [Perino11], and CONVERGENCE [Detti12] [Blefari-Melazzi12] [Salsano12]. The metrics used in these approaches fall into two categories: metrics for the approach as a whole, and metrics for individual components (name resolution, routing, and so on). Metrics for the entire approach are further subdivided into traffic and system metrics. It is important to note that the various approaches do not name or define metrics consistently. This is a major problem when trying to find metrics that allow comparison between approaches. For the purposes of exposition, we have tried to smooth over differences by classifying similarly defined metrics under the same name. Also, due to space constraints, we have chosen to report here only the most common metrics between approaches. For more details, the reader should consult the references for each approach.

関連する一連のメトリックに到達するには、コンテンツ中心のネットワーキング(CCN)[Jacobson09] [VoCCN] [Zhang10b]、NetInf [4WARD6.1] [ 4WARD6.3] [SAIL-B2] [SAIL-B3]、PURSUIT [PRST4.5]、COMET [CMT-D5.2] [CMT-D6.2]、Connect [Muscariello11​​] [Perino11]、およびCONVERGENCE [Detti12 ] [Blefari-Melazzi12] [Salsano12]。これらのアプローチで使用されるメトリックは2つのカテゴリに分類されます。アプローチ全体のメトリックと個々のコンポーネントのメトリック(名前解決、ルーティングなど)です。アプローチ全体のメトリックは、トラフィックとシステムメトリックにさらに細分されます。さまざまなアプローチが一貫して指標に名前を付けたり定義したりしないことに注意することが重要です。これは、アプローチ間の比較を可能にするメトリックを見つけようとする場合の主要な問題です。説明のため、同じように定義されたメトリックを同じ名前で分類することにより、差異を平滑化することを試みました。また、スペースの制約のため、ここでは、アプローチ間の最も一般的なメトリックのみを報告することにしました。詳細については、読者は各アプローチのリファレンスを参照する必要があります。

Traffic metrics in existing ICN approaches are summarized in Table 4. These are metrics for evaluating an approach mainly from the perspective of the end user, i.e., the consumer, provider, or owner of the content or service. Depending on the level where these metrics are measured, we have made the distinction into user, application, and network-level traffic metrics. So, for example, network-level metrics are mostly focused on packet characteristics, whereas user-level metrics can cover elements of human perception. The approaches do not make this distinction explicitly, but we can see from the table that CCN and NetInf have used metrics from all levels, PURSUIT and COMET have focused on lower-level metrics, and Connect and CONVERGENCE opted for higher-level metrics. Throughput and download time seem to be the most popular metrics altogether.

既存のICNアプローチのトラフィックメトリックを表4にまとめます。これらは、主にエンドユーザー、つまりコンテンツまたはサービスのコンシューマー、プロバイダー、または所有者の観点からアプローチを評価するためのメトリックです。これらのメトリックが測定されるレベルに応じて、ユーザー、アプリケーション、およびネットワークレベルのトラフィックメトリックを区別しました。したがって、たとえば、ネットワークレベルのメトリックは主にパケットの特性に焦点を当てていますが、ユーザーレベルのメトリックは人間の知覚の要素をカバーできます。アプローチではこれを明示的に区別していませんが、CCNとNetInfはすべてのレベルのメトリックを使用しており、PURSUITとCOMETは低レベルのメトリックに重点を置いており、ConnectとCONVERGENCEは高レベルのメトリックを選択していることが表からわかります。スループットとダウンロード時間は、全体で最も人気のあるメトリックのようです。

                   User   |    Application    |        Network
               ======================================================
                 Download | Goodput | Startup | Throughput |  Packet
                   time   |         | latency |            |  delay
   ==================================================================
   CCN         |    x     |    x    |         |      x     |    x
   ------------------------------------------------------------------
   NetInf      |    x     |         |    x    |      x     |    x
   ------------------------------------------------------------------
   PURSUIT     |          |         |    x    |      x     |    x
   ------------------------------------------------------------------
   COMET       |          |         |    x    |      x     |
   ------------------------------------------------------------------
   Connect     |    x     |         |         |            |
   ------------------------------------------------------------------
   CONVERGENCE |    x     |    x    |         |            |
   ==================================================================
        

Table 4: Traffic Metrics Used in ICN Evaluations

表4:ICN評価で使用されるトラフィックメトリック

While traffic metrics are more important for the end user, the owner or operator of the networking infrastructure is normally more interested in system metrics, which can reveal the efficiency of an approach. The most common system metrics used are: protocol overhead, total traffic, transit traffic, cost savings, router cost, and router energy consumption.

トラフィックメトリックはエンドユーザーにとってより重要ですが、ネットワークインフラストラクチャの所有者またはオペレーターは通常、システムメトリックにより関心があり、アプローチの効率を明らかにすることができます。使用される最も一般的なシステムメトリックは、プロトコルオーバーヘッド、総トラフィック、トランジットトラフィック、コスト削減、ルーターコスト、およびルーターエネルギー消費です。

Besides the traffic and systems metrics that aim to evaluate an approach as a whole, all surveyed approaches also evaluate the performance of individual components. Name resolution, request/data routing, and data caching are the most typical components, as summarized in Table 5. Forwarding Information Base (FIB) size and path length, i.e., the routing component metrics, are almost ubiquitous among approaches, perhaps due to the networking background of the involved researchers. That might be also the reason for the sometimes decreased focus on traffic and system metrics, in favor of component metrics. It can certainly be argued that traffic and system metrics are affected by component metrics; however, no approach has made the relationship clear. With this in mind and taking into account that traffic and system metrics are readily useful to end users and network operators, we will restrict ourselves to those in the following subsections.

アプローチ全体を評価することを目的とするトラフィックおよびシステムメトリックに加えて、調査されたすべてのアプローチは、個々のコンポーネントのパフォーマンスも評価します。表5にまとめられているように、名前解決、要求/データルーティング、およびデータキャッシングが最も一般的なコンポーネントです。関係する研究者のネットワーキングの背景。また、コンポーネントメトリックが優先され、トラフィックとシステムメトリックへのフォーカスが低下する場合もあります。トラフィックとシステムメトリックはコンポーネントメトリックの影響を受けることは確かです。ただし、どのようなアプローチも関係を明確にしていません。これを念頭に置き、トラフィックとシステムメトリックスがエンドユーザーとネットワークオペレーターにすぐに役立つことを考慮して、次のサブセクションに限定します。

                      Resolution      |    Routing    |    Cache
               ======================================================
                 Resolution | Request | FIB  |  Path  | Size |  Hit
                    time    |  rate   | size | length |      | ratio
   ==================================================================
   CCN         |     x      |         |  x   |   x    |   x  |   x
   ------------------------------------------------------------------
   NetInf      |     x      |    x    |      |   x    |      |   x
   ------------------------------------------------------------------
   PURSUIT     |            |         |  x   |   x    |      |
   ------------------------------------------------------------------
   COMET       |     x      |    x    |  x   |   x    |      |   x
   ------------------------------------------------------------------
   CONVERGENCE |            |    x    |  x   |        |   x  |
   ==================================================================
        

Table 5: Component Metrics in Existing ICN Approaches

表5:既存のICNアプローチのコンポーネントメトリック

Before proceeding, we should note that we would like our metrics to be applicable to host-centric networks as well. Standard metrics already exist for IP networks, and it would certainly be beneficial to take them into account. It is encouraging that many of the metrics used by existing ICN approaches can also be used on IP networks and that all of the approaches have tried on occasion to draw the parallels.

先に進む前に、ホスト中心のネットワークにもメトリックを適用できるようにしたいことに注意してください。 IPネットワークには標準的なメトリックがすでに存在しており、それらを考慮に入れることは確かに有益です。既存のICNアプローチで使用されているメトリックの多くがIPネットワークでも使用できること、およびすべてのアプローチが類似点を描くためにときどき試してきたことは心強いことです。

2.3.1. Traffic Metrics
2.3.1. トラフィックメトリック

The IETF has been working for more than a decade on devising metrics and methods for measuring the performance of IP networks. The work has been carried out largely within the IP Performance Metrics (IPPM) working group, guided by a relevant framework [RFC2330]. IPPM metrics include delay, delay variation, loss, reordering, and duplication. While the IPPM work is certainly based on packet-switched IP networks, it is conceivable that it can be modified and extended to cover ICN networks as well. However, more study is necessary to turn this claim into a certainty. Many experts have toiled for a long time on devising and refining the IPPM metrics and methods, so it would be an advantage to use them for measuring ICN performance. In addition, said metrics and methods work already for host-centric networks, so comparison with information-centric networks would entail only the ICN extension of the IPPM framework. Finally, an important benefit of measuring the transport performance of a network at its output, using Quality of Service (QoS) metrics such as IPPM, is that it can be done mostly without any dependence to applications.

IETFは、IPネットワークのパフォーマンスを測定するためのメトリックと方法の考案に10年以上取り組んできました。作業は、関連するフレームワーク[RFC2330]に導かれ、主にIPパフォーマンスメトリック(IPPM)ワーキンググループ内で行われました。 IPPMメトリックには、遅延、遅延変動、損失、並べ替え、および複製が含まれます。 IPPMの作業は確かにパケット交換IPネットワークに基づいていますが、ICNネットワークもカバーするように変更および拡張できると考えられます。ただし、この主張を確実にするためには、さらに調査が必要です。多くの専門家がIPPMメトリックとメソッドの考案と改良に長い間努力してきたので、ICNパフォーマンスの測定にそれらを使用することは利点です。さらに、前述のメトリックとメソッドはすでにホスト中心のネットワークで機能しているため、情報中心のネットワークとの比較には、IPPMフレームワークのICN拡張のみが伴います。最後に、IPPMなどのサービス品質(QoS)メトリックを使用して、ネットワークのトランスポートパフォーマンスを出力で測定することの重要な利点は、アプリケーションにほとんど依存せずに実行できることです。

Another option for measuring transport performance would be to use QoS metrics, not at the output of the network like with IPPM, but at the input to the application. For a live video-streaming application the relevant metrics would be startup latency, playout lag, and playout continuity. The benefit of this approach is that it abstracts away all details of the underlying transport network, so it can be readily applied to compare between networks of different concepts (host-centric, information-centric, or other). As implied earlier, the drawback of the approach is its dependence on the application, so it is likely that different types of applications will require different metrics. It might be possible to identify standard metrics for each type of application, but the situation is not as clear as with IPPM metrics, and further investigation is necessary.

トランスポートパフォーマンスを測定する別のオプションは、IPPMのようなネットワークの出力ではなく、アプリケーションへの入力でQoSメトリックを使用することです。ライブビデオストリーミングアプリケーションの場合、関連するメトリックは、起動遅延、再生ラグ、および再生継続性です。このアプローチの利点は、基盤となるトランスポートネットワークのすべての詳細を抽象化するため、さまざまな概念(ホスト中心、情報中心など)のネットワーク間の比較に簡単に適用できることです。前述のとおり、このアプローチの欠点はアプリケーションへの依存性です。そのため、異なるタイプのアプリケーションには異なるメトリックが必要になる可能性があります。アプリケーションのタイプごとに標準メトリックを識別することは可能かもしれませんが、状況はIPPMメトリックほど明確ではなく、さらに調査が必要です。

At a higher level of abstraction, we could measure the network's transport performance at the application output. This entails measuring the quality of the transported and reconstructed information as perceived by the user during consumption. In such an instance we would use Quality of Experience (QoE) metrics, which are by definition dependent on the application. For example, the standardized methods for obtaining a Mean Opinion Score (MOS) for VoIP (e.g., ITU-T Recommendation P.800) is quite different from those for IPTV (e.g., Perceptual Evaluation of Video Quality (PEVQ)). These methods are notoriously hard to implement, as they involve real users in a controlled environment. Such constraints can be relaxed or dropped by using methods that model human perception under certain environments, but these methods are typically intrusive. The most important drawback of measuring network performance at the output of the application is that only one part of each measurement is related to network performance. The rest is related to application performance, e.g., video coding, or even device capabilities, both of which are irrelevant to our purposes here and are generally hard to separate. We therefore see the use of QoE metrics in measuring ICN performance as a poor choice at this stage.

より高いレベルの抽象化では、アプリケーション出力でのネットワークのトランスポートパフォーマンスを測定できます。これには、ユーザーが消費中に認識した、転送および再構築された情報の品質の測定が伴います。そのような場合は、定義上アプリケーションに依存するQuality of Experience(QoE)メトリックを使用します。たとえば、VoIPの平均オピニオンスコア(MOS)(ITU-T勧告P.800など)を取得するための標準化された方法は、IPTV(ビデオ品質の知覚評価(PEVQ)など)とはかなり異なります。これらの方法は、制御された環境で実際のユーザーが関与するため、実装が難しいことで有名です。このような制約は、特定の環境下で人間の知覚をモデル化する方法を使用して緩和または削除できますが、これらの方法は通常、煩わしいものです。アプリケーションの出力でネットワークパフォーマンスを測定する際の最も重要な欠点は、各測定の一部のみがネットワークパフォーマンスに関連していることです。残りは、アプリケーションのパフォーマンスに関連しています。たとえば、ビデオコーディングやデバイスの機能であり、どちらもここでの目的には関係なく、一般に分離するのは困難です。したがって、ICNパフォーマンスの測定におけるQoEメトリックの使用は、この段階では不適切な選択であると考えています。

2.3.2. System Metrics
2.3.2. システム指標

Overall system metrics that need to be considered include reliability, scalability, energy efficiency, and delay/disconnection tolerance. In deployments where ICN is addressing specific scenarios, relevant system metrics could be derived from current experience. For example, in Internet of Things (IoT) scenarios, which are discussed in [RFC7476], it is reasonable to consider the current generation of sensor nodes, sources of information, and even measurement gateways (e.g., for smart metering at homes) or smartphones. In this case, ICN operation ought to be evaluated with respect not only to overall scalability and network efficiency, but also the impact on the nodes themselves. Karnouskos et al. [SensReqs] provide a comprehensive set of sensor and IoT-related requirements, for example, which include aspects such as resource utilization, service life-cycle management, and device management.

考慮する必要のある全体的なシステムメトリックには、信頼性、スケーラビリティ、エネルギー効率、および遅延/切断耐性が含まれます。 ICNが特定のシナリオに対応している展開では、関連するシステムメトリックを現在の経験から導き出すことができます。たとえば、[RFC7476]で説明されているモノのインターネット(IoT)シナリオでは、センサーノードの現在の世代、情報源、さらには測定ゲートウェイ(たとえば、家庭でのスマートメータリング)を検討するのが妥当です。スマートフォン。この場合、ICN操作は、全体的なスケーラビリティとネットワーク効率だけでなく、ノード自体への影響に関しても評価する必要があります。 Karnouskos et al。 [SensReqs]は、センサーとIoT関連の要件の包括的なセットを提供します。これには、リソースの利用、サービスのライフサイクル管理、デバイス管理などの側面が含まれます。

Additionally, various specific metrics are also critical in constrained environments, such as processing requirements, signaling overhead, and memory allocation for caching procedures, in addition to power consumption and battery lifetime. For gateways (which typically act as a point of service to a large number of nodes and have to satisfy the information requests from remote entities), we need to consider scalability-related metrics, such as frequency and processing of successfully satisfied information requests.

さらに、消費電力やバッテリーの寿命に加えて、処理要件、シグナリングオーバーヘッド、キャッシング手順のためのメモリ割り当てなど、さまざまな特定のメトリックも制約された環境で重要です。ゲートウェイ(通常、多数のノードへのサービスポイントとして機能し、リモートエンティティからの情報要求を満たす必要がある)の場合、成功した情報要求の頻度や処理など、スケーラビリティ関連のメトリックを考慮する必要があります。

Finally, given the in-network caching functionality of ICNs, efficiency and performance metrics of in-network caching have to be defined. Such metrics will need to guide researchers and operators regarding the performance of in-network caching algorithms. A first step on this direction has been made in [Psaras11]. The paper proposes a formula that approximates the proportion of time that a piece of content stays in a network cache. The model takes as input the rate of requests for a given piece of content (the Content of Interest (CoI)) and the rate of requests for all other contents that go through the given network element (router) and move the CoI down in the (LRU) cache. The formula takes also into account the size of the cache of this router.

最後に、ICNのネットワーク内キャッシング機能を考えると、ネットワーク内キャッシングの効率とパフォーマンスメトリックを定義する必要があります。このようなメトリックは、ネットワーク内キャッシングアルゴリズムのパフォーマンスに関して研究者やオペレーターを導く必要があります。この方向への最初のステップは、[Psaras11]で行われました。この論文では、コンテンツの一部がネットワークキャッシュに留まる時間の割合を概算する式を提案しています。モデルは、入力として、特定のコンテンツ(関心のあるコンテンツ(CoI))のリクエストのレートと、特定のネットワーク要素(ルーター)を通過して他のすべてのコンテンツのリクエストのレートを取得し、CoIを(LRU)キャッシュ。この式では、このルーターのキャッシュのサイズも考慮されます。

The output of the model essentially reflects the probability that the CoI will be found in a given cache. An initial study [Psaras11] is applied to the CCN / Named Data Networking (NDN) framework, where contents get cached at every node they traverse. The formula according to which the probability or proportion is calculated is given by:

モデルの出力は基本的に、CoIが特定のキャッシュで見つかる確率を反映しています。最初の調査[Psaras11]は、CCN / Named Data Networking(NDN)フレームワークに適用され、トラバースするすべてのノードでコンテンツがキャッシュされます。確率または比率が計算される式は、次のように与えられます。

   pi = [mu / (mu + lambda)]^N
        

where lambda is the request rate for the CoI, mu is the request rate for contents that move the CoI down the cache, and N is the size of the cache (in slots).

ここで、lambdaはCoIの要求レート、muはCoIをキャッシュに移動させるコンテンツの要求レート、Nはキャッシュのサイズ(スロット単位)です。

The formula can be used to assess the caching performance of the system and can also potentially be used to identify the gain of the system due to caching. This can then be used to compare against gains by other factors, e.g., addition of extra bandwidth in the network.

この式は、システムのキャッシングパフォーマンスを評価するために使用できます。また、キャッシングによるシステムのゲインを特定するためにも使用できます。次に、これを使用して、ネットワーク内の追加の帯域幅の追加など、他の要因によるゲインと比較できます。

2.4. Resource Equivalence and Trade-Offs
2.4. リソースの同等性とトレードオフ

As we have seen above, every ICN network is built from a set of resources, which include link capacities, and different types of memory structures and repositories used for storing named data objects and chunks temporarily (i.e., caching) or persistently, as well as name resolution and other lookup services. A range of engineering trade-offs arise from the complexity and processing requirements of forwarding decisions, management needs (e.g., manual configuration, explicit garbage collection), and routing needs (e.g., amount of state, manual configuration of routing tables, support for mobility).

上記で見たように、すべてのICNネットワークは、リンク容量を含む一連のリソース、および名前付きデータオブジェクトとチャンクを一時的(つまり、キャッシュ)または永続的に保存するために使用されるさまざまなタイプのメモリ構造とリポジトリから構築されます。名前解決およびその他の検索サービス。エンジニアリングのトレードオフの範囲は、転送の決定、管理のニーズ(例:手動構成、明示的なガベージコレクション)、ルーティングの必要性(例:状態の量、ルーティングテーブルの手動構成、モビリティのサポート)の複雑さと処理要件から生じます。 )。

In order to be able to compare different ICN approaches, it would be beneficial to be able to define equivalence in terms of different resources that today are considered incomparable. For example, would provisioning an additional 5 Mbit/s link capacity lead to better performance than adding 100 GB of in-network storage? Within this context, one would consider resource equivalence (and the associated trade-offs) -- for example, for cache hit ratios per GB of cache, forwarding decision times, CPU cycles per forwarding decision, and so on.

さまざまなICNアプローチを比較できるようにするには、今日では比較できないと見なされているさまざまなリソースの観点から同等性を定義できることが有益です。たとえば、追加の5 Mbit / sリンク容量をプロビジョニングすると、100 GBのネットワーク内ストレージを追加するよりもパフォーマンスが向上しますか?このコンテキスト内では、リソースの同等性(および関連するトレードオフ)を検討します。たとえば、キャッシュのGBあたりのキャッシュヒット率、転送決定時間、転送決定ごとのCPUサイクルなどです。

3. ICN Security Aspects
3. ICNのセキュリティアスペクト

The introduction of an information-centric networking architecture and the corresponding communication paradigm results in changes to many aspects of network security. These will affect all scenarios described in [RFC7476]. Additional evaluation will be required to ensure relevant security requirements are appropriately met by the implementation of the chosen architecture in the various scenarios.

情報中心のネットワーキングアーキテクチャと対応する通信パラダイムの導入により、ネットワークセキュリティの多くの側面が変化します。これらは、[RFC7476]で説明されているすべてのシナリオに影響します。さまざまなシナリオで選択したアーキテクチャを実装することにより、関連するセキュリティ要件が適切に満たされるようにするには、追加の評価が必要になります。

The ICN security aspects described in this document reflect the ICN security challenges outlined in [RFC7927].

このドキュメントで説明されているICNセキュリティの側面は、[RFC7927]で概説されているICNセキュリティの課題を反映しています。

The ICN architectures currently proposed have concentrated on authentication of delivered content to ensure its integrity. Even though the approaches are primarily applicable to freely accessible content that does not require access authorization, they will generally support delivery of encrypted content.

現在提案されているICNアーキテクチャは、配信されたコンテンツの認証に集中して、その整合性を確保しています。これらのアプローチは主に、アクセス許可を必要としない自由にアクセス可能なコンテンツに適用できますが、一般に暗号化されたコンテンツの配信をサポートします。

The introduction of widespread caching mechanisms may also provide additional attack surfaces. The caching architecture to be used also needs to be evaluated to ensure that it meets the requirements of the usage scenarios.

広範なキャッシングメカニズムの導入により、追加の攻撃面が提供される場合もあります。使用するキャッシングアーキテクチャも評価して、使用シナリオの要件を満たしていることを確認する必要があります。

In practice, the work on security in the various ICN research projects has been heavily concentrated on authentication of content. Work on authorization, access control, and privacy and security threats due to the expanded role of in-network caches has been quite limited. For example, a roadmap for improving the security model in NetInf can be found in [Renault09]. As secure communications on the Internet are becoming the norm, major gaps in ICN security aspects are bound to undermine the adoption of ICN. A comprehensive overview of ICN security is also provided in [Tourani16].

実際には、さまざまなICN研究プロジェクトのセキュリティに関する作業は、コンテンツの認証に大きく集中しています。ネットワーク内キャッシュの役割の拡大による、承認、アクセス制御、プライバシーとセキュリティの脅威への取り組みは、非常に制限されています。たとえば、NetInfのセキュリティモデルを改善するためのロードマップは、[Renault09]にあります。インターネット上での安全な通信が当たり前になっているため、ICNのセキュリティ面での大きなギャップは、ICNの採用を損なうことになります。 ICNセキュリティの包括的な概要は、[Tourani16]にも記載されています。

In the following subsections, we briefly consider the issues and provide pointers to the work that has been done on the security aspects of the architectures proposed.

次のサブセクションでは、問題を簡単に検討し、提案されたアーキテクチャのセキュリティ面で行われた作業へのポインタを提供します。

3.1. Authentication
3.1. 認証

For fully secure content distribution, content access requires that the receiver be able to reliably assess:

完全に安全なコンテンツ配信のために、コンテンツアクセスでは、受信者が以下を確実に評価できる必要があります。

validity: Is it a complete, uncorrupted copy of what was originally published?

妥当性:元々公開されていたものの完全で破損していないコピーですか?

provenance: Can the receiver identify the publisher? If so, can it and the source of any cached version of the document be adequately trusted?

起源:受信者は発行者を識別できますか?もしそうなら、それとドキュメントのキャッシュされたバージョンのソースは十分に信頼できますか?

relevance: Is the content an answer to the question that the receiver asked?

関連性:コンテンツは、受信者が尋ねた質問への回答ですか?

All ICN architectures considered in this document primarily target the validity requirement using strong cryptographic means to tie the content request name to the content. Provenance and relevance are directly targeted to varying extents: There is a tussle or trade-off between simplicity and efficiency of access and level of assurance of all these traits. For example, maintaining provenance information can become extremely costly, particularly when considering (historic) relationships between multiple objects. Architectural decisions have therefore been made in each case as to whether the assessment is carried out by the information-centric network or left to the application.

このドキュメントで検討されているすべてのICNアーキテクチャは、主にコンテンツ要求名をコンテンツに結び付ける強力な暗号化手段を使用して有効性要件を対象としています。出所と関連性は、さまざまな範囲で直接対象とされます。アクセスの単純さと効率とこれらすべての特性の保証のレベルとの間には、混乱またはトレードオフがあります。たとえば、特に複数のオブジェクト間の(履歴)関係を検討する場合は、来歴情報の維持に非常にコストがかかる可能性があります。したがって、評価は情報中心のネットワークによって実行されるのか、アプリケーションに任されるのかについて、アーキテクチャの決定がそれぞれの場合に行われました。

An additional consideration for authentication is whether a name should be irrevocably and immutably tied to a static piece of preexisting content or whether the name can be used to refer to dynamically or subsequently generated content. Schemes that only target immutable content can be less resource-hungry as they can use digest functions rather than public key cryptography for generating and checking signatures. However, this can increase the load on applications because they are required to manage many names, rather than use a single name for an item of evolving content that changes over time (e.g., a piece of data containing an age reference).

認証に関する追加の考慮事項は、名前を既存の静的コンテンツに変更不能かつ不変に関連付ける必要があるかどうか、または名前を使用して動的または後で生成されるコンテンツを参照できるかどうかです。不変コンテンツのみを対象とするスキームは、署名の生成とチェックに公開鍵暗号方式ではなくダイジェスト関数を使用できるため、リソースの消費量が少なくて済みます。ただし、これは、時間の経過とともに変化する進化するコンテンツのアイテム(たとえば、年齢の参照を含むデータの一部)に単一の名前を使用するのではなく、多くの名前を管理する必要があるため、アプリケーションの負荷を増大させる可能性があります。

Data-Oriented Network Architecture (DONA) [DONA] and CCN [Jacobson09] [Smetters09] integrate most of the data needed to verify provenance into all content retrievals but need to be able to retrieve additional information (typically a security certificate) in order to complete the provenance authentication. Whether the application has any control of this extra retrieval will depend on the implementation. CCN is explicitly designed to handle dynamic content allowing names to be pre-allocated and attached to subsequently generated content. DONA offers variants for dynamic and immutable content.

データ指向ネットワークアーキテクチャ(DONA)[DONA]およびCCN [Jacobson09] [Smetters09]は、来歴の確認に必要なほとんどのデータをすべてのコンテンツ取得に統合しますが、追加の情報(通常はセキュリティ証明書)を取得できる必要があります。来歴認証を完了します。アプリケーションがこの追加の検索を制御できるかどうかは、実装によって異なります。 CCNは、動的コンテンツを処理するように明示的に設計されており、名前を事前に割り当てて、後で生成されるコンテンツに添付できます。 DONAは、動的で不変のコンテンツのバリアントを提供します。

Publish-Subscribe Internet Technology (PURSUIT) [Tagger12] appears to allow implementers to choose the authentication mechanism so that it can, in theory, emulate the authentication strategy of any of the other architectures. It is not clear whether different choices would lead to lack of interoperability.

パブリッシュサブスクライブインターネットテクノロジー(PURSUIT)[Tagger12]を使用すると、実装者は認証メカニズムを選択できるため、理論的には他のアーキテクチャの認証戦略をエミュレートできます。異なる選択が相互運用性の欠如につながるかどうかは明らかではありません。

NetInf uses the Named Information (ni) URI scheme [RFC6920] to identify content. This allows NetInf to assure validity without any additional information but gives no assurance on provenance or relevance. A "search" request allows an application to identify relevant content, and applications may choose to structure content to allow provenance assurance, but this will typically require additional network access. NetInf validity authentication is consequently efficient in a network environment with intermittent connectivity as it does not force additional network accesses and allows the application to decide on provenance validation if required. For dynamic content, NetInf can use, e.g., signed manifests. For more details on NetInf security, see [Dannewitz10].

NetInfは名前付き情報(ni)URIスキーム[RFC6920]を使用してコンテンツを識別します。これにより、NetInfは追加情報なしで有効性を保証できますが、出所または関連性は保証されません。 「検索」リクエストにより、アプリケーションは関連するコンテンツを識別でき、アプリケーションはコンテンツを構造化して来歴を保証することを選択できますが、これには通常、追加のネットワークアクセスが必要です。 NetInfの有効性認証は、断続的な接続のあるネットワーク環境で効率的です。追加のネットワークアクセスを強制せず、必要に応じてアプリケーションが来歴の検証を決定できるためです。動的コンテンツの場合、NetInfは、たとえば署名付きマニフェストを使用できます。 NetInfセキュリティの詳細については、[Dannewitz10]を参照してください。

3.2. Authorization, Access Control, and Logging
3.2. 承認、アクセス制御、およびロギング

A potentially major concern for all ICN architectures considered here is that they do not provide any inbuilt support for an authorization framework or for logging. Once content has been published and cached in servers, routers, or endpoints not controlled by the publisher, the publisher has no way to enforce access control, determine which users have accessed the content, or revoke its publication. In fact, in some cases (where requests do not necessarily contain host/user identifier information), it is difficult for the publishers themselves to perform access control.

ここで検討されているすべてのICNアーキテクチャの潜在的な主な懸念は、承認フレームワークやロギングの組み込みサポートが提供されていないことです。コンテンツがパブリッシャーによって制御されていないサーバー、ルーター、またはエンドポイントにパブリッシュおよびキャッシュされると、パブリッシャーはアクセス制御を実施したり、コンテンツにアクセスしたユーザーを特定したり、パブリケーションを取り消すことができなくなります。実際、場合によっては(要求に必ずしもホスト/ユーザーID情報が含まれていない場合)、パブリッシャー自身がアクセス制御を実行することが困難です。

Access could be limited by encrypting the content, but the necessity of distributing keys out-of-band appears to negate the advantages of in-network caching. This also creates significant challenges when attempting to manage and restrict key access. An authorization delegation scheme has been proposed [Fotiou12]. This scheme allows semi-trusted entities (such as caches or CDN nodes) to delegate access control decisions to third-party access control providers that are trusted by the content publisher. The former entities have no access to subscriber-related information and should respect the decisions of the access control providers.

コンテンツを暗号化することでアクセスが制限される可能性がありますが、帯域外でキーを配布する必要があるため、ネットワーク内キャッシュの利点が失われるようです。これは、キーアクセスを管理および制限しようとするときにも大きな課題を引き起こします。承認委任スキームが提案されています[Fotiou12]。このスキームを使用すると、半信頼エンティティ(キャッシュやCDNノードなど)が、アクセス制御の決定を、コンテンツ発行元が信頼するサードパーティのアクセス制御プロバイダーに委任できます。前者は加入者関連情報にアクセスできず、アクセス制御プロバイダーの決定を尊重する必要があります。

A recent proposal for an extra layer in the protocol stack [LIRA] gives control of the name resolution infrastructure to the publisher. This enables access logging as well some degree of active cache management, e.g., purging of stale content.

プロトコルスタック[LIRA]の追加レイヤーに関する最近の提案では、名前解決インフラストラクチャをパブリッシャに制御できます。これにより、アクセスロギングとある程度のアクティブなキャッシュ管理(古いコンテンツのパージなど)が可能になります。

One possible technique that could allow for providing access control to heterogeneous groups and still allow for a single encrypted object representation that remains cacheable is Attribute-Based Encryption (ABE). A first proposal for this is presented in [Ion13]. To support heterogeneous groups and avoid having a single authority that has a master key multi-authority, ABE can be used [Lewko11].

異種グループへのアクセス制御を提供し、キャッシュ可能な単一の暗号化されたオブジェクト表現を可能にする1つの可能な手法は、属性ベースの暗号化(ABE)です。これに対する最初の提案は、[Ion13]に示されています。異種グループをサポートし、マスターキーの複数の権限を持つ単一の権限を持たないようにするために、ABEを使用できます[Lewko11]。

Evaluating the impact of the absence of these features will be essential for any scenario where an ICN architecture might be deployed. It may have a seriously negative impact on the applicability of ICN in commercial environments unless a solution can be found.

これらの機能が存在しない場合の影響を評価することは、ICNアーキテクチャが展開される可能性のあるすべてのシナリオに不可欠です。ソリューションが見つからない場合、商業環境でのICNの適用性に深刻な悪影響を与える可能性があります。

3.3. Privacy
3.3. プライバシー

Another area where the architectures have not been significantly analyzed is privacy. Caching implies a trade-off between network efficiency and privacy. The activity of users is significantly more exposed to the scrutiny of cache owners with whom they may not have any relationship. However, it should be noted that it is only the first-hop router/cache that can see who requests what, as requests are aggregated and only the previous-hop router is visible when a request is forwarded.

アーキテクチャが大幅に分析されていないもう1つの領域はプライバシーです。キャッシングは、ネットワーク効率とプライバシーの間のトレードオフを意味します。ユーザーの活動は、関係のない可能性のあるキャッシュ所有者の監視に著しくさらされます。ただし、リクエストが集約され、リクエストの転送時に前のホップのルーターのみが表示されるため、誰が何をリクエストしたかを確認できるのはファーストホップルーター/キャッシュのみであることに注意してください。

Although in many ICN architectures the source of a request is not explicitly identified, an attacker may be able to obtain considerable information if he or she can monitor transactions on the cache and obtain details of the objects accessed, the topological direction of requests, and information about the timing of transactions. The persistence of data in the cache can make life easier for an attacker by giving a longer timescale for analysis.

多くのICNアーキテクチャではリクエストのソースが明示的に識別されていませんが、攻撃者は、キャッシュ上のトランザクションを監視し、アクセスされたオブジェクトの詳細、リクエストのトポロジの方向、および情報を取得できれば、かなりの情報を入手できる可能性があります。取引のタイミングについて。キャッシュ内のデータの永続性は、分析に長いタイムスケールを与えることにより、攻撃者の生活を楽にします。

The impact of CCN on privacy has been investigated in [Lauinger10], and the analysis is applicable to all ICN architectures because it is mostly focused on the common caching aspect. The privacy risks of Named Data Networking are also highlighted in [Lauinger12]. Further work on privacy in ICNs can be found in [Chaabane13]. Finally, Fotiou et al. define an ICN privacy evaluation framework in [Fotiou14].

プライバシーに対するCCNの影響は[Lauinger10]で調査されており、分析は主に共通のキャッシュの側面に焦点を当てているため、すべてのICNアーキテクチャに適用できます。名前付きデータネットワーキングのプライバシーリスクも[Lauinger12]で強調表示されています。 ICNのプライバシーに関するさらなる研究は[Chaabane13]にあります。最後に、Fotiou et al。 [Fotiou14]でICNプライバシー評価フレームワークを定義します。

3.4. Changes to the Network Security Threat Model
3.4. ネットワークセキュリティ脅威モデルの変更

The architectural differences of the various ICN models versus TCP/IP have consequences for network security. There is limited consideration of the threat models and potential mitigation in the various documents describing the architectures. [Lauinger10] and [Chaabane13] also consider the changed threat model. Some of the key aspects are:

さまざまなICNモデルとTCP / IPのアーキテクチャの違いは、ネットワークセキュリティに影響を与えます。アーキテクチャを説明するさまざまなドキュメントでは、脅威モデルと潜在的な軽減策についての考慮が限られています。 [Lauinger10]と[Chaabane13]も、変更された脅威モデルを検討します。主な側面は次のとおりです。

o Caching implies a trade-off between network efficiency and user privacy as discussed in Section 3.3.

o セクション3.3で説明したように、キャッシングはネットワークの効率とユーザーのプライバシーの間のトレードオフを意味します。

o More-powerful routers upgraded to handle persistent caching increase the network's attack surface. This is particularly the case in systems that may need to perform cryptographic checks on content that is being cached. For example, not doing this could lead routers to disseminate invalid content.

o 永続的なキャッシュを処理するようにアップグレードされたより強力なルーターは、ネットワークの攻撃面を増やします。これは、キャッシュされているコンテンツに対して暗号化チェックを実行する必要があるシステムで特に当てはまります。たとえば、これを行わないと、ルーターが無効なコンテンツを配布する可能性があります。

o ICNs makes it difficult to identify the origin of a request (as mentioned in Section 3.3), slowing down the process of blocking requests and requiring alternative mechanisms to differentiate legitimate requests from inappropriate ones as access control lists (ACLs) will probably be of little value for ICN requests.

o ICNを使用すると、リクエストの発信元を特定することが難しくなり(セクション3.3で説明)、リクエストをブロックするプロセスが遅くなり、正当なリクエストと不適切なリクエストを区別するための代替メカニズムが必要になるため、アクセス制御リスト(ACL)はほとんど価値がありません。 ICNリクエストの場合。

o Denial-of-service (DoS) attacks may require more effort on ICN than on TCP/IP-based host-centric networks, but they are still feasible. One reason for this is that it is difficult for the attacker to force repeated requests for the same content onto a single node; ICNs naturally spread content so that after the initial few requests, subsequent requests will generally be satisfied by alternative sources, blunting the impact of a DoS attack. That said, there are many ways around this, e.g., generating random suffix identifiers that always result in cache misses.

o サービス拒否(DoS)攻撃では、ICNでTCP / IPベースのホスト中心のネットワークよりも多くの労力が必要になる可能性がありますが、それでも実行可能です。これの1つの理由は、攻撃者が同じコンテンツに対する繰り返し要求を単一のノードに強制することは困難であることです。 ICNはコンテンツを自然に拡散するため、最初の数回の要求の後、後続の要求は通常、代替ソースによって満たされ、DoS攻撃の影響を鈍くします。とはいえ、これには多くの方法があります。たとえば、常にキャッシュミスを引き起こすランダムなサフィックス識別子を生成します。

o Per-request state in routers can be abused for DoS attacks.

o ルーターの要求ごとの状態は、DoS攻撃のために悪用される可能性があります。

o Caches can be misused in the following ways:

o キャッシュは次のように誤用される可能性があります。

+ Attackers can use caches as storage to make their own content available.

+ 攻撃者は、キャッシュをストレージとして使用して、独自のコンテンツを利用可能にすることができます。

+ The efficiency of caches can be decreased by attackers with the goal of DoS attacks.

+ キャッシュの効率は、DoS攻撃を目的とする攻撃者によって低下する可能性があります。

+ Content can be extracted by any attacker connected to the cache, putting users' privacy at risk.

+ キャッシュに接続している攻撃者がコンテンツを抽出できるため、ユーザーのプライバシーが危険にさらされます。

Appropriate mitigation of these threats will need to be considered in each scenario.

これらの脅威の適切な緩和策は、各シナリオで検討する必要があります。

4. Evaluation Tools
4. 評価ツール

Since ICN is an emerging area, the community is in the process of developing effective evaluation environments, including releasing open-source implementations, simulators, emulators, and testbeds. To date, none of the available evaluation tools can be seen as the one and only community reference evaluation tool. Furthermore, no single environment supports all well-known ICN approaches, as we describe below, hindering the direct comparison of the results obtained for different ICN approaches. The subsections that follow review the currently publicly available ICN implementations, simulators, and experimental facilities.

ICNは新興地域であるため、コミュニティは、オープンソース実装、シミュレーター、エミュレーター、テストベッドのリリースなど、効果的な評価環境の開発を進めています。これまでのところ、利用可能な評価ツールはどれも、唯一のコミュニティ参照評価ツールとは言えません。さらに、以下で説明するように、単一の環境がすべての既知のICNアプローチをサポートしていないため、さまざまなICNアプローチで得られた結果を直接比較できません。以下のサブセクションでは、現在公開されているICNの実装、シミュレーター、および実験施設について説明します。

   An updated list of the available evaluation tools will be maintained
   at the ICNRG Wiki page: <https://trac.tools.ietf.org/group/irtf/trac/
   wiki/IcnEvaluationAndTestbeds>
        
4.1. Open-Source Implementations
4.1. オープンソース実装

The Named Data Networking (NDN) project has open-sourced a software reference implementation of the architecture and protocol called NDN (http://named-data.net). NDN is available for deployment on various operating systems and includes C and Java libraries that can be used to build applications.

Named Data Networking(NDN)プロジェクトは、NDN(http://named-data.net)と呼ばれるアーキテクチャとプロトコルのソフトウェアリファレンス実装をオープンソース化しています。 NDNはさまざまなオペレーティングシステムでの展開に使用でき、アプリケーションの構築に使用できるCおよびJavaライブラリが含まれています。

CCN-lite (http://www.ccn-lite.net) is a lightweight implementation of the CCN protocol that supports most of the key features of CCNx and is interoperable with CCNx. CCN-lite implements the core CCN logic in about 1000 lines of code, so it is ideal for classroom work and course projects as well as for quickly experimenting with CCN extensions. For example, Baccelli et al. use CCN-lite on top of the RIOT operating system to conduct experiments over an IoT testbed [Baccelli14].

CCN-lite(http://www.ccn-lite.net)は、CCNxの主要機能のほとんどをサポートし、CCNxと相互運用可能なCCNプロトコルの軽量な実装です。 CCN-liteは、コアCCNロジックを約1000行のコードで実装するため、教室での作業やコースプロジェクト、およびCCN拡張機能をすばやく試すのに最適です。たとえば、Baccelli et al。 RIOTオペレーティングシステム上でCCN-liteを使用して、IoTテストベッドを介して実験を行います[Baccelli14]。

PARC is offering CCN source code under various licensing schemes, please see <http://www.ccnx.org> for details.

PARCは、さまざまなライセンススキームの下でCCNソースコードを提供しています。詳細については、<http://www.ccnx.org>を参照してください。

The PURSUIT project (http://www.fp7-pursuit.eu) has open-sourced its Blackhawk publish-subscribe (Pub/Sub) implementation for Linux and Android; more details are available at <https://github.com/fp7-pursuit/blackadder>. Blackadder uses the Click modular router for ease of development. The code distribution features a set of tools, test applications, and scripts. The POINT project (http://www.point-h2020.eu) is currently maintaining Blackadder.

PURSUITプロジェクト(http://www.fp7-pursuit.eu)は、LinuxおよびAndroid向けのBlackhawk publish-subscribe(Pub / Sub)実装をオープンソース化しています。詳細については、<https://github.com/fp7-pursuit/blackadder>を参照してください。 Blackadderは、Clickモジュラールーターを使用して開発を容易にしています。コード配布には、一連のツール、テストアプリケーション、およびスクリプトが含まれます。 POINTプロジェクト(http://www.point-h2020.eu)は現在Blackadderを維持しています。

The 4WARD and SAIL projects have open-sourced software that implements different aspects of NetInf, e.g., the NetInf URI format and HTTP and UDP convergence layer, using different programming languages. The Java implementation provides a local caching proxy and client. Further, an OpenNetInf prototype is available as well as a hybrid host-centric and information-centric network architecture called the Global Information Network (GIN), a browser plug-in and video-streaming software. See <http://www.netinf.org/open-source> for more details.

4WARDおよびSAILプロジェクトには、異なるプログラミング言語を使用して、NetInfのさまざまな側面(NetInf URI形式、HTTPおよびUDPコンバージェンスレイヤーなど)を実装するオープンソースソフトウェアがあります。 Java実装は、ローカルキャッシングプロキシとクライアントを提供します。さらに、OpenNetInfプロトタイプだけでなく、グローバル情報ネットワーク(GIN)と呼ばれる、ホスト中心と情報中心のハイブリッドネットワークアーキテクチャ、ブラウザープラグイン、およびビデオストリーミングソフトウェアも利用できます。詳細については、<http://www.netinf.org/open-source>を参照してください。

4.2. Simulators and Emulators
4.2. シミュレーターとエミュレーター

Simulators and emulators should be able to capture faithfully all features and operations of the respective ICN architecture(s) and any limitations should be openly documented. It is essential that these tools and environments come with adequate logging facilities so that one can use them for in-depth analysis as well as debugging. Additional requirements include the ability to support medium- to large-scale experiments, the ability to quickly and correctly set various configurations and parameters, as well as to support the playback of traffic traces captured on a real testbed or network. Obviously, this does not even begin to touch upon the need for strong validation of any evaluated implementations.

シミュレーターとエミュレーターは、それぞれのICNアーキテクチャーのすべての機能と操作を忠実にキャプチャできる必要があり、制限は公開して文書化する必要があります。これらのツールと環境には、詳細な分析とデバッグに使用できるように、適切なロギング機能が備わっていることが不可欠です。その他の要件には、中規模から大規模の実験をサポートする機能、さまざまな構成とパラメータを迅速かつ正確に設定する機能、実際のテストベッドまたはネットワークでキャプチャされたトラフィックトレースの再生をサポートする機能が含まれます。明らかに、これは評価された実装の強力な検証の必要性に触れさえしません。

4.2.1. ndnSIM
4.2.1. ndnSIM

The Named Data Networking (NDN) project (http://named-data.net) has developed ndnSIM [ndnSIM] [ndnSIM2]; this is a module that can be plugged into the ns-3 simulator (https://www.nsnam.org) and supports the core features of NDN. One can use ndnSIM to experiment with various NDN applications and services as well as components developed for NDN such as routing protocols and caching and forwarding strategies, among others. The code for ns-3 and ndnSIM is openly available to the community and can be used as the basis for implementing ICN protocols or applications. For more details, see <http://ndnsim.net/2.0/>.

Named Data Networking(NDN)プロジェクト(http://named-data.net)がndnSIM [ndnSIM] [ndnSIM2]を開発しました。これは、ns-3シミュレーター(https://www.nsnam.org)にプラグインできるモジュールであり、NDNのコア機能をサポートします。 ndnSIMを使用して、ルーティングプロトコル、キャッシング、転送戦略など、NDN用に開発されたコンポーネントだけでなく、さまざまなNDNアプリケーションやサービスを試すことができます。 ns-3およびndnSIMのコードはコミュニティーに公開されており、ICNプロトコルまたはアプリケーションを実装するための基礎として使用できます。詳細については、<http://ndnsim.net/2.0/>を参照してください。

4.2.2. ccnSIM
4.2.2. ccns

ccnSim [ccnSim] is a CCN-specific simulator that was specially designed to handle forwarding of a large number of CCN-chunks (http://www.infres.enst.fr/~drossi/index.php?n=Software.ccnSim). ccnSim is written in C++ for the OMNeT++ simulation framework (https://omnetpp.org). Other CCN-specific simulators include the CCN Packet-Level Simulator [CCNPL] and CCN-Joker [Cianci12]. CCN-Joker emulates in user space all basic aspects of a CCN node (e.g., handling of Interest and Data packets, cache sizing, replacement policies), including both flow and congestion control. The code is open source and is suitable for both emulation-based analyses and real experiments. Finally, Cabral et al. [MiniCCNx] use container-based emulation and resource isolation techniques to develop a prototyping and emulation tool.

ccnSim [ccnSim]は、多数のCCNチャンク(http://www.infres.enst.fr/~drossi/index.php?n=Software.ccnSim)の転送を処理するように特別に設計されたCCN固有のシミュレーターです。 )。 ccnSimは、OMNeT ++シミュレーションフレームワーク(https://omnetpp.org)用にC ++で記述されています。その他のCCN固有のシミュレータには、CCNパケットレベルシミュレータ[CCNPL]とCCN-Joker [Cianci12]があります。 CCN-Jokerは、フローと輻輳制御の両方を含む、CCNノードのすべての基本的な側面(インタレストパケットとデータパケットの処理、キャッシュサイジング、置換ポリシーなど)をユーザー空間でエミュレートします。コードはオープンソースであり、エミュレーションベースの分析と実際の実験の両方に適しています。最後に、Cabralら。 [MiniCCNx]コンテナベースのエミュレーションおよびリソース分離技術を使用して、プロトタイピングおよびエミュレーションツールを開発します。

4.2.3. Icarus Simulator
4.2.3. イカロスシミュレーター

The Icarus simulator [ICARUS] focuses on caching in ICN and is agnostic with respect to any particular ICN implementation. The simulator is implemented in Python, uses the Fast Network Simulator Setup tool [Saino13], and is available at <http://icarus-sim.github.io>. Icarus has several caching strategies implemented, including among others ProbCache [Psaras12], node-centrality-based caching [Chai12], and hash-route-based caching [HASHROUT].

Icarusシミュレーター[ICARUS]はICNでのキャッシングに焦点を当てており、特定のICN実装に関しては不可知論です。シミュレータはPythonで実装され、Fast Network Simulator Setupツール[Saino13]を使用し、<http://icarus-sim.github.io>から入手できます。 Icarusには、ProbCache [Psaras12]、ノード中心型ベースのキャッシュ[Chai12]、ハッシュルートベースのキャッシュ[HASHROUT]など、いくつかのキャッシュ戦略が実装されています。

ProbCache [Psaras12] is taking a resource management view on caching decisions and approximates the available cache capacity along the path from source to destination. Based on this approximation and in order to reduce caching redundancy across the path, it caches content probabilistically. According to [Chai12], the node with the highest "betweenness centrality" along the path from source to destination is responsible for caching incoming content. Finally, [HASHROUT] calculates the hash function of a content's name and assigns contents to caches of a domain according to that. The hash space is split according to the number of caches of the network. Then, upon subsequent requests, and based again on the hash of the name included in the request, edge routers redirect requests to the cache assigned with the corresponding hash space. [HASHROUT] is an off-path caching strategy; in contrast to [Psaras12] and [Chai12], it requires minimum coordination and redirection overhead. In its latest update, Icarus also includes implementation of the "Satisfied Interest Table" (SIT) [Sourlas15]. The SIT points in the direction where content has been sent recently. Among other benefits, this enables information resilience in case of network fragmentation (i.e., content can still be found in neighbor caches or in users' devices) and inherently supports user-assisted caching (i.e., P2P-like content distribution).

ProbCache [Psaras12]は、キャッシングの決定についてリソース管理の視点を取り入れ、ソースから宛先へのパスに沿って利用可能なキャッシュ容量を概算しています。この概算に基づいて、パス全体のキャッシュの冗長性を減らすために、コンテンツを確率的にキャッシュします。 [Chai12]によると、送信元から宛先へのパスに沿って「中間の中心性」が最も高いノードは、着信コンテンツのキャッシュを担当します。最後に、[HASHROUT]はコンテンツの名前のハッシュ関数を計算し、それに従ってドメインのキャッシュにコンテンツを割り当てます。ハッシュ空間は、ネットワークのキャッシュ数に応じて分割されます。次に、後続のリクエストに応じて、リクエストに含まれる名前のハッシュに基づいて、エッジルーターは対応するハッシュスペースが割り当てられたキャッシュにリクエストをリダイレクトします。 [HASHROUT]はオフパスキャッシング戦略です。 [Psaras12]と[Chai12]とは対照的に、最小限の調整とリダイレクトのオーバーヘッドが必要です。 Icarusの最新の更新では、「充足利息表」(SIT)[Sourlas15]の実装も含まれています。 SITは、コンテンツが最近送信された方向を指しています。他の利点の中でも特に、これにより、ネットワークの断片化(つまり、コンテンツが近隣のキャッシュまたはユーザーのデバイスに存在する場合)の場合に情報の回復力が可能になり、本質的にユーザー支援のキャッシュ(つまり、P2Pのようなコンテンツ配信)がサポートされます。

Tortelli et al. [ICNSIMS] provide a comparison of ndnSIM, ccnSim, and Icarus.

Tortelli et al。 [ICNSIMS]は、ndnSIM、ccnSim、およびIcarusの比較を提供します。

4.3. Experimental Facilities
4.3. 実験施設

An important consideration in the evaluation of any kind of future Internet mechanism lies in the characteristics of that evaluation itself. Central to the assessment of the features provided by a novel mechanism is the consideration of how it improves over already existing technologies, and by "how much". With the disruptive nature of clean-slate approaches generating new and different technological requirements, it is complex to provide meaningful results for a network-layer framework, in comparison with what is deployed in the current Internet. Thus, despite the availability of ICN implementations and simulators, the need for large-scale environments supporting experimental evaluation of novel research is of prime importance to the advancement of ICN deployment.

将来のあらゆる種類のインターネットメカニズムの評価における重要な考慮事項は、その評価自体の特性にあります。新規メカニズムによって提供される機能の評価の中心は、既存のテクノロジーをどのように改善するか、および「どれだけ」改善するかの検討です。クリーンスレートアプローチの破壊的な性質により、新しく異なる技術要件が生成されるため、現在のインターネットで展開されているものと比較して、ネットワーク層フレームワークに意味のある結果を提供することは複雑です。したがって、ICN実装とシミュレーターの可用性にもかかわらず、新規研究の実験的評価をサポートする大規模環境の必要性は、ICN展開の進歩にとって最も重要です。

Different experimental facilities have different characteristics and capabilities, e.g., having low cost of use, reproducible configuration, easy-to-use tools, and available background traffic, and being sharable.

実験施設が異なれば、特徴や機能も異なります。たとえば、使用コストが低く、設定が再現可能で、使いやすいツール、利用可能なバックグラウンドトラフィックがあり、共有可能です。

4.3.1. Open Network Lab (ONL)
4.3.1. オープンネットワークラボ(オンライン)

An example of an experimental facility that supports CCN is the Open Network Lab [ONL] that currently comprises 18 extensible gigabit routers and over a 100 computers representing clients and is freely available to the public for running CCN experiments. Nodes in ONL are preloaded with CCNx software. ONL provides a graphical user interface for easy configuration and testbed setup as per the experiment requirements, and also serves as a control mechanism, allowing access to various control variables and traffic counters.

CCNをサポートする実験施設の例は、現在18の拡張可能なギガビットルーターとクライアントを表す100台を超えるコンピューターで構成され、CCN実験を実行するために自由に公開されているOpen Network Lab [ONL]です。 ONLのノードには、CCNxソフトウェアがプリロードされています。 ONLは、実験要件に従って簡単な構成とテストベッドのセットアップを行うためのグラフィカルユーザーインターフェイスを提供し、制御メカニズムとしても機能し、さまざまな制御変数とトラフィックカウンターへのアクセスを可能にします。

Further, it is also possible to run and evaluate CCN over popular testbeds [PLANETLAB] [EMULAB] [DETERLAB] [OFELIA] by directly running, for example, the CCNx open-source code [Salsano13] [Carofiglio13] [Awiphan13] [Bernardini14]. Also, the Network Experimentation Programming Interface (NEPI) [NEPI] is a tool developed for controlling and managing large-scale network experiments. NEPI can be used to control and manage large-scale CCNx experiments, e.g., on PlanetLab [Quereilhac14].

さらに、CCNxオープンソースコード[Salsano13] [Carofiglio13] [Awiphan13] [Bernardini14 ]。また、ネットワーク実験プログラミングインターフェイス(NEPI)[NEPI]は、大規模ネットワーク実験を制御および管理するために開発されたツールです。 NEPIは、PlanetLab [Quereilhac14]などの大規模なCCNx実験の制御と管理に使用できます。

4.3.2. POINT Testbed
4.3.2. POINTテストベッド

The POINT project is maintaining a testbed with 40 machines across Europe, North America (Massachusetts Institute of Technology (MIT)), and Japan (National Institute of Information and Communications Technology (NICT)) interconnected in a topology containing one Topology Manager and one rendezvous node that handle all publish/subscribe and topology formation requests [Parisis13]. All machines run Blackadder (see Section 4.1). New nodes can join, and experiments can be run on request.

POINTプロジェクトは、1つのトポロジーマネージャーと1つのランデブーを含むトポロジーで相互接続された、ヨーロッパ、北米(マサチューセッツ工科大学(MIT))、および日本(National Institute of Information and Communications Technology(NICT))の40台のマシンでテストベッドを維持しています。すべてのパブリッシュ/サブスクライブおよびトポロジ形成要求を処理するノード[Parisis13]。すべてのマシンでBlackadderが実行されます(セクション4.1を参照)。新しいノードを結合でき、リクエストに応じて実験を実行できます。

4.3.3. CUTEi: Container-Based ICN Testbed
4.3.3. CUTEi:コンテナーベースのICNテストベッド

NICT has also developed a testbed used for ICN experiments [Asaeda14] comprising multiple servers located in Asia and other locations. Each testbed server (or virtual machine) utilizes a Linux kernel-based container (LXC) for node virtualization. This testbed enables users to run applications and protocols for ICN in two experimentation modes using two different container designs:

NICTはまた、アジアやその他の場所にある複数のサーバーで構成されるICN実験[Asaeda14]に使用されるテストベッドを開発しました。各テストベッドサーバー(または仮想マシン)は、ノードの仮想化にLinuxカーネルベースのコンテナー(LXC)を利用します。このテストベッドにより、ユーザーは2つの異なるコンテナー設計を使用して、2つの実験モードでICNのアプリケーションとプロトコルを実行できます。

1. application-level experimentation using a "common container" and

1. 「共通のコンテナ」を使用したアプリケーションレベルの実験

2. network-level experimentation using a "user container."

2. 「ユーザーコンテナ」を使用したネットワークレベルの実験。

A common container is shared by all testbed users, and a user container is assigned to one testbed user. A common container has a global IP address to connect with other containers or external networks, whereas each user container uses a private IP address and a user space providing a closed networking environment. A user can login to his/her user containers using SSH with his/her certificate, or access them from PCs connected to the Internet using SSH tunneling.

共通のコンテナーはすべてのテストベッドユーザーによって共有され、ユーザーコンテナーは1つのテストベッドユーザーに割り当てられます。共通のコンテナーには、他のコンテナーまたは外部ネットワークに接続するためのグローバルIPアドレスがありますが、各ユーザーコンテナーはプライベートIPアドレスとユーザースペースを使用して、閉じたネットワーク環境を提供します。ユーザーは、SSHを使用して自分の証明書でユーザーコンテナーにログインするか、SSHトンネリングを使用してインターネットに接続されたPCからコンテナーにアクセスできます。

This testbed also implements an "on-filesystem cache" to allocate caching data on a UNIX filesystem. The on-filesystem cache system accommodates two kinds of caches: "individual cache" and "shared cache." Individual cache is accessible for one dedicated router for the individual user, while shared cache is accessible for a set of routers in the same group to avoid duplicated caching in the neighborhood for cooperative caching.

このテストベッドは、「ファイルシステムキャッシュ」も実装して、UNIXファイルシステムにキャッシュデータを割り当てます。ファイルシステム上のキャッシュシステムは、「個別キャッシュ」と「共有キャッシュ」の2種類のキャッシュに対応しています。個々のキャッシュは、個々のユーザーの1つの専用ルーターからアクセスできますが、共有キャッシュは、同じグループ内のルーターのセットからアクセスして、協調キャッシュのために近隣で重複するキャッシュを回避できます。

5. Security Considerations
5. セキュリティに関する考慮事項

This document does not impact the security of the Internet, but Section 3 outlines security and privacy concerns that might affect a deployment of a future ICN approach.

このドキュメントはインターネットのセキュリティには影響しませんが、セクション3では、将来のICNアプローチの展開に影響を与える可能性のあるセキュリティとプライバシーの問題について概説します。

6. Informative References
6. 参考引用

[4WARD6.1] Ohlman, B., et al., "First NetInf Architecture Description", 4WARD Project Deliverable D-6.1, April 2009.

[4WARD6.1] Ohlman、B.他、「First NetInf Architecture Description」、4WARD Project Deliverable D-6.1、2009年4月。

[4WARD6.3] Ahlgren, B., et al., "NetInf Evaluation", 4WARD Project Deliverable D-6.3, June 2010.

[4WARD6.3] Ahlgren、B.他、「NetInf Evaluation」、4WARD Project Deliverable D-6.3、2010年6月。

[Arlitt97] Arlitt, M. and C. Williamson, "Internet web servers: workload characterization and performance implications", IEEE/ACM Transactions on Networking, vol. 5, pp. 631-645, DOI 10.1109/90.649565, 1997.

[Arlitt97] Arlitt、M。およびC. Williamson、「インターネットWebサーバー:ワークロードの特性とパフォーマンスへの影響」、IEEE / ACM Transactions on Networking、vol。 5、pp。631-645、DOI 10.1109 / 90.649565、1997。

[Asaeda14] Asaeda, H., Li, R., and N. Choi, "Container-Based Unified Testbed for Information-Centric Networking", IEEE Network, vol. 28, no. 6, pp. 60-66, DOI 10.1109/MNET.2014.6963806, 2014.

[Asaeda14] Asaeda、H.、Li、R.、and N. Choi、 "Container-Based Unified Testbed for Information-Centtric Networking"、IEEE Network、vol。 28、いいえ。 6、pp。60-66、DOI 10.1109 / MNET.2014.6963806、2014。

[Awiphan13] Awiphan, S., et al., "Video streaming over content centric networking: Experimental studies on PlanetLab", Proc. Computing, Communications and IT Applications Conference (ComComAp), IEEE, DOI 10.1109/ComComAp.2013.6533602, 2013.

[Awiphan13] Awiphan、S.、et al。、「コンテンツ中心のネットワーキングを介したビデオストリーミング:PlanetLabの実験的研究」、Proc。コンピューティング、通信、ITアプリケーション会議(ComComAp)、IEEE、DOI 10.1109 / ComComAp.2013.6533602、2013。

[Baccelli14] Baccelli, E., et al., "Information Centric Networking in the IoT: Experiments with NDN in the Wild", Proceedings of the 1st international conference on Information-centric networking (ICN '14), ACM, DOI 10.1145/2660129.2660144, 2014.

[Baccelli14] Baccelli、E。、他、「IoTにおける情報セントリックネットワーキング:野生のNDNを使用した実験」、情報中心のネットワーキングに関する第1回国際会議の議事録(ICN '14)、ACM、DOI 10.1145 / 2660129.2660144、2014。

[Barabasi99] Barabasi, A. and R. Albert, "Emergence of Scaling in Random Networks", Science, vol. 286, no. 5439, pp. 509-512, DOI 10.1126/science.286.5439.509, 1999.

[Barabasi99] Barabasi、A.およびR. Albert、「ランダムネットワークにおけるスケーリングの出現」、Science、vol。 286、いいえ。 5439、509-512ページ、DOI 10.1126 / science.286.5439.509、1999年。

[Barford98] Barford, P. and M. Crovella, "Generating representative web workloads for network and server performance evaluation", in ACM SIGMETRICS '98 / PERFORMANCE '98, pp. 151-160, DOI 10.1145/277851.277897, 1998.

[Barford98] Barford、P。およびM. Crovella、「ネットワークおよびサーバーのパフォーマンス評価のための代表的なWebワークロードの生成」、ACM SIGMETRICS '98 / PERFORMANCE '98、pp。151-160、DOI 10.1145 / 277851.277897、1998。

[Barford99] Barford, P., Bestavros, A., Bradley, A., and M. Crovella, "Changes in web client access patterns: Characteristics and caching implications", World Wide Web, vol. 2, pp. 15-28, DOI 10.1023/A:1019236319752, 1999.

[Barford99] Barford、P.、Bestavros、A.、Bradley、A。、およびM. Crovella、「Webクライアントアクセスパターンの変更:特性とキャッシングの影響」、World Wide Web、vol。 2、pp。15-28、DOI 10.1023 / A:1019236319752、1999。

[Bellissimo04] Bellissimo, A., Levine, B., and P. Shenoy, "Exploring the Use of BitTorrent as the Basis for a Large Trace Repository", University of Massachusetts Amherst, Tech. Rep. 04-41, 2004.

[Bellissimo04] Bellissimo、A.、Levine、B。、およびP. Shenoy、「大規模なトレースリポジトリの基礎としてのBitTorrentの使用の探索」、マサチューセッツ大学アマースト、Tech。議員、2004年4月41日。

[Bernardini14] Bernardini, C., et al., "Socially-aware caching strategy for content centric networking", Proc. IFIP Networking Conference, DOI 10.1109/IFIPNetworking.2014.6857093, 2014.

[Bernardini14] Bernardini、C.、et al。、「コンテンツ中心のネットワーキングのための社会的に認識されたキャッシング戦略」、Proc。 IFIPネットワーキング会議、DOI 10.1109 / IFIPNetworking.2014.6857093、2014。

[Blefari-Melazzi12] Blefari Melazzi, N., et al., "Scalability Measurements in an Information-Centric Network", Springer Lecture Notes in Computer Science (LNCS), vol. 7586, DOI 10.1007/978-3-642-41296-7_6, 2012.

[Blefari-Melazzi12] Blefari Melazzi、N.他、「情報中心のネットワークにおけるスケーラビリティ測定」、コンピュータサイエンスにおけるスプリンガー講義ノート(LNCS)、vol。 7586、DOI 10.1007 / 978-3-642-41296-7_6、2012。

[Breslau99] Breslau, L., Cao, P., Fan, L., Phillips, G., and S. Shenker, "Web caching and zipf-like distributions: evidence and implications", Proc. of INFOCOM '99, New York (NY), USA, DOI 10.1109/INFCOM.1999.749260, March 1999.

[Breslau99]ブレスラウ、L。、曹操、P。、ファン、L。、フィリップス、G。、およびS.シェンカー、「Webキャッシングとzipfのような分布:証拠と含意」、Proc。 INFOCOM '99、ニューヨーク(NY)、米国、DOI 10.1109 / INFCOM.1999.749260、1999年3月。

[Busari02] Busari, M. and C. Williamson, "ProWGen: a synthetic workload generation tool for simulation evaluation of web proxy caches", Computer Networks, vol. 38, no. 6, pp. 779-794, DOI 10.1016/S1389-1286(01)00285-7, 2002.

[Busari02] Busari、M。およびC. Williamson、「ProWGen:Webプロキシキャッシュのシミュレーション評価のための合成ワークロード生成ツール」、Computer Networks、vol。 38、いいえ。 6、pp。779-794、DOI 10.1016 / S1389-1286(01)00285-7、2002。

[Carofiglio11] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino, "Modeling Data Transfer in Content-Centric Networking", Proceedings of the 23rd International Teletraffic Congress (ITC '11), San Francisco, USA, September 2011.

[Carofiglio11] Carofiglio、G.、Gallo、M.、Muscariello、L。、およびD. Perino、「コンテンツ中心のネットワーキングにおけるデータ転送のモデリング」、第23回国際電気通信会議(ITC '11)、サンフランシスコ、米国、2011年9月。

[Carofiglio13] Carofiglio, G., et al., "Optimal multipath congestion control and request forwarding in Information-Centric Networks", Proc. 2013 21st IEEE International Conference on Network Protocols (ICNP), DOI 10.1109/ICNP.2013.6733576, 2013.

[Carofiglio13] Carofiglio、G.、et al。、 "Optimum multipath congestion control and request forwarding in in-Centric Networks"、Proc。 2013第21回ネットワークプロトコルに関するIEEE国際会議(ICNP)、DOI 10.1109 / ICNP.2013.6733576、2013。

[CCNPL] Institut de Recherche Technologique (IRT) SystemX, "CCNPL-SIM", <http://systemx.enst.fr/ccnpl-sim>.

[CCNPL] Institute for Technological Research(IRT)SystemX、「CCNPL-SIM」、<http://systemx.enst.fr/ccnpl-sim>。

[ccnSim] Rossini, G. and D. Rossi, "Large scale simulation of CCN networks", Proc. AlgoTel 2012, La Grande Motte, France, May 2012.

[ccnSim]ロッシーニ、G。およびD.ロッシ、「CCNネットワークの大規模シミュレーション」、Proc。 AlgoTel 2012、La Grande Motte、フランス、2012年5月。

[Cha07] Cha, M., Kwak, H., Rodriguez, P., Ahn, Y.-Y., and S. Moon, "I tube, you tube, everybody tubes: analyzing the world's largest user generated content video system", Proceedings of the 7th ACM SIGCOMM conference on Internet measurement (IMC '07), San Diego (CA), USA, DOI 10.1145/1298306.1298309, October 2007.

[Cha07] Cha、M.、Kwak、H.、Rodriguez、P.、Ahn、Y.-Y。、およびS. Moon、「I Tube、You Tube、Everybody Tubes:世界最大のユーザー生成コンテンツビデオシステムの分析"、インターネット測定に関する第7回ACM SIGCOMM会議の議事録(IMC '07)、サンディエゴ(CA)、米国、DOI 10.1145 / 1298306.1298309、2007年10月。

[Chaabane13] Chaabane, A., De Cristofaro, E., Kaafar, M., and E. Uzun, "Privacy in Content-Oriented Networking: Threats and Countermeasures", ACM SIGCOMM Computer Communication Review, Vol. 43, Issue 3, DOI 10.1145/2500098.2500102, July 2013.

[Chaabane13] Chaabane、A.、De Cristofaro、E.、Kaafar、M。、およびE. Uzun、「コンテンツ指向ネットワーキングにおけるプライバシー:脅威と対策」、ACM SIGCOMM Computer Communication Review、Vol。 43、発行3、DOI 10.1145 / 2500098.2500102、2013年7月。

[Cheng08] Cheng, X., Dale, C., and J. Liu, "Statistics and social network of YouTube videos", 16th International Workshop on Quality of Service (IWQoS 2008), IEEE, pp. 229-238, DOI 10.1109/IWQOS.2008.32, 2008.

[Cheng08] Cheng、X.、Dale、C.、J。Liu、「YouTubeビデオの統計とソーシャルネットワーク」、サービス品質に関する第16回国際ワークショップ(IWQoS 2008)、IEEE、ページ229-238、DOI 10.1109 /IWQOS.2008.32、2008。

[Cheng13] Cheng, X., Liu, J., and C. Dale, "Understanding the Characteristics of Internet Short Video Sharing: YouTube as a Case Study", IEEE Transactions on Multimedia, vol. 15, issue 5, DOI 10.1109/TMM.2013.2265531, 2013.

[Cheng13] Cheng、X.、Liu、J。、およびC. Dale、「インターネットショートビデオ共有の特性を理解する:ケーススタディとしてのYouTube」、IEEE Transactions on Multimedia、vol。 15、問題5、DOI 10.1109 / TMM.2013.2265531、2013。

[Chai12] Chai, W., He, D., Psaras, I., and G. Pavlou, "Cache 'Less for More' in Information-centric Networks", Proceedings of the 11th international IFIP TC 6 conference on Networking (IFIP '12), DOI 10.1007/978-3-642-30045-5_3, 2012.

[Chai12] Chai、W.、He、D.、Psaras、I.、and G. Pavlou、 "Cache 'Less for More' in Information-centric Networks"、Proceedings of the 11th international IFIP TC 6 Conference on Networking(IFIP '12)、DOI 10.1007 / 978-3-642-30045-5_3、2012。

[Cianci12] Cianci, I. et al. "CCN - Java Opensource Kit EmulatoR for Wireless Ad Hoc Networks", Proc. of the 7th International Conference on Future Internet Technologies (CFI '12), Seoul, Korea, DOI 10.1145/2377310.2377313, September 2012.

[Cianci12] Cianci、I。ら。 「CCN-ワイヤレスアドホックネットワーク用JavaオープンソースキットEmulatoR」、Proc。第7回未来のインターネット技術に関する国際会議(CFI '12)、韓国ソウル、DOI 10.1145 / 2377310.2377313、2012年9月。

[CMT-D5.2] Beben, A., et al., "Scalability of COMET System", COMET Project Deliverable D5.2, February 2013.

[CMT-D5.2] Beben、A.他、「COMETシステムのスケーラビリティ」、COMETプロジェクト成果物D5.2、2013年2月。

[CMT-D6.2] Georgiades, M., et al., "Prototype Experimentation and Demonstration", COMET Project Deliverable D6.2, February 2013.

[CMT-D6.2] Georgiades、M.、et al。、「Prototype Experimentation and Demonstration」、COMET Project Deliverable D6.2、2013年2月。

[Dannewitz10] Dannewitz, C., Golic, J., Ohlman, B., B. Ahlgren, "Secure Naming for A Network of Information", IEEE Conference on Computer Communications Workshops (INFOCOM), San Diego, CA, DOI 10.1109/INFCOMW.2010.5466661, March 2010.

[Dannewitz10] Dannewitz、C.、Golic、J.、Ohlman、B.、B. Ahlgren、 "Secure Naming for A Network of Information"、IEEE Con​​ference on Computer Communications Workshops(INFOCOM)、San Diego、CA、DOI 10.1109 / INFCOMW.2010.5466661、2010年3月。

[DETERLAB] Benzel, T., "The Science of Cyber-Security Experimentation: The DETER Project", Proceedings of the 27th Annual Computer Security Applications Conference (ACSAC '11), DOI 10.1145/2076732.2076752, December 2011.

[DETERLAB]ベンゼルT.、「サイバーセキュリティ実験の科学:DETERプロジェクト」、第27回コンピュータセキュリティアプリケーション会議の議事録(ACSAC '11)、DOI 10.1145 / 2076732.2076752、2011年12月。

[Dimitropoulos09] Dimitropoulos, X., et al., "Graph annotations in modeling complex network topologies", ACM Transactions on Modeling and Computer Simulation (TOMACS), vol. 19, no. 4, DOI 10.1145/1596519.1596522, November 2009.

[Dimitropoulos09] Dimitropoulos、X.、et al。、 "複雑なネットワークトポロジのモデリングにおける注釈の注釈"、ACM Transactions on Modeling and Computer Simulation(TOMACS)、vol。 19、いいえ。 4、DOI 10.1145 / 1596519.1596522、2009年11月。

[DONA] Koponen, T., et al., "A Data-Oriented (and Beyond) Network Architecture", Proceedings of the 2007 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM '07), ACM, DOI 10.1145/1282380.1282402, 2007.

[DONA] Koponen、T.、et al。、 "A Data-Oriented(and Beyond)Network Architecture"、Proceedings of the 2007 Conference on Applications、technology、architectures and protocol for computer communication(SIGCOMM '07)、ACM、 DOI 10.1145 / 1282380.1282402、2007。

[EMULAB] Eide, E., et al., "An Experimentation Workbench for Replayable Networking Research", Proceedings of the 4th USENIX conference on Networked systems design & implementation (NSDI '07), 2007.

[EMULAB] Eide、E。、他、「再生可能なネットワーク研究のための実験ワークベンチ」、ネットワークシステムの設計と実装に関する第4回USENIX会議の議事録(NSDI '07)、2007年。

[Fotiou12] Fotiou, N., et al., "Access control enforcement delegation for information-centric networking architectures", Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12), ACM, DOI 10.1145/2342488.2342507, 2012.

[Fotiou12] Fotiou、N.他、「情報中心のネットワークアーキテクチャのためのアクセス制御実施委任」、情報中心のネットワークに関するICNワークショップの第2版の議事録(ICN '12)、ACM、DOI 10.1145 / 2342488.2342507、2012。

[Fotiou14] Fotiou, N., et al., "A framework for privacy analysis of ICN architectures", Proc. Second Annual Privacy Forum (APF), Springer, DOI 10.1007/978-3-319-06749-0_8, 2014.

[Fotiou14] Fotiou、N.他、「ICNアーキテクチャのプライバシー分析のフレームワーク」、Proc。第2年次プライバシーフォーラム(APF)、Springer、DOI 10.1007 / 978-3-319-06749-0_8、2014。

[Fri12] Fricker, C., Robert, P., Roberts, J. and N. Sbihi, "Impact of traffic mix on caching performance in a content-centric network", 2012 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), Orlando, USA, DOI 10.1109/INFCOMW.2012.6193511, March 2012.

[Fri12] Fricker、C.、Robert、P.、Roberts、J。、およびN. Sbihi、「コンテンツ中心のネットワークにおけるキャッシングパフォーマンスへのトラフィックミックスの影響」、2012年コンピュータ通信ワークショップに関するIEEE会議(INFOCOM WKSHPS)、米国、オーランド、DOI 10.1109 / INFCOMW.2012.6193511、2012年3月。

[Goog08] Google, "Official Google Blog: We knew the web was big...", July 2008, <http://googleblog.blogspot.it/ 2008/07/we-knew-web-was-big.html>.

[Goog08] Google、「公式のGoogleブログ:ウェブが大きいことはわかっていました...」、2008年7月、<http://googleblog.blogspot.it/ 2008/07 / we-knew-web-was-big.html >。

[Guo07] Guo, L., Chen, S., Xiao, Z., Tan, E., Ding, X., and X. Zhang, "A performance study of BitTorrent-like peer-to-peer systems", IEEE Journal on Selected Areas in Communication, vol. 25, no. 1, pp. 155-169, DOI 10.1109/JSAC.2007.070116, 2007.

[Guo07] Guo、L.、Chen、S.、Xiao、Z.、Tan、E.、Ding、X。、およびX. Zhang、「BitTorrentのようなピアツーピアシステムのパフォーマンス研究」、IEEE Journal in Selected Areas in Communication、vol。 25、いいえ。 1、pp。155-169、DOI 10.1109 / JSAC.2007.070116、2007。

[HASHROUT] Saino, L., Psaras, I., and G. Pavlou, "Hash-routing Schemes for Information-Centric Networking", Proceedings of the 3rd ACM SIGCOMM workshop on Information-centric networking (ICN '13), DOI 10.1145/2491224.2491232, 2013.

[ハッシュルート]サイノL.、プサラスI.、およびG.パヴロウ、「情報中心型ネットワーキングのハッシュルーティングスキーム」、情報中心型ネットワーキングに関する第3回ACM SIGCOMMワークショップの議事録(ICN '13)、DOI 10.1145 /2491224.2491232、2013。

[Hefeeda08] Hefeeda, M. and O. Saleh, "Traffic Modeling and Proportional Partial Caching for Peer-to-Peer Systems", IEEE/ACM Transactions on Networking, vol. 16, no. 6, pp. 1447-1460, DOI 10.1109/TNET.2008.918081, 2008.

[Hefeeda08] Hefeeda、M。およびO. Saleh、「ピアツーピアシステムのトラフィックモデリングと比例部分キャッシング」、IEEE / ACM Transactions on Networking、vol。 16、いいえ。 6、pp。1447-1460、DOI 10.1109 / TNET.2008.918081、2008。

[ICARUS] Saino, L., Psaras, I., and G. Pavlou, "Icarus: a Caching Simulator for Information Centric Networking (ICN)", Proceedings of the 7th International ICST Conference on Simulation Tools and Techniques (SimuTools '14), DOI 10.4108/icst.simutools.2014.254630, 2014.

[イカルス]サイノL.、プサラスI、およびG.パヴロウ、「イカルス:情報セントリックネットワーキング(ICN)のキャッシングシミュレータ」、第7回国際ICST会議のシミュレーションツールとテクニックに関する会議録(SimuTools '14) 、DOI 10.4108 / icst.simutools.2014.254630、2014。

[Detti12] Detti, A., et al., "Supporting the Web with an Information Centric Network that Routes by Name", Elsevier Computer Networks, vol. 56, no. 17, DOI 10.1016/j.comnet.2012.08.006, November 2012.

[Detti12] Detti、A。、他、「名前でルーティングする情報中心ネットワークでWebをサポートする」、Elsevier Computer Networks、vol。 56、いいえ。 17、DOI 10.1016 / j.comnet.2012.08.006、2012年11月。

[ICNSIMS] Tortelli, M., et al., "CCN Simulators: Analysis and Cross-Comparison", Proceedings of the 1st international conference on Information-centric networking (ICN '14), ACM, DOI 10.1145/2660129.2660133, 2014.

[ICNSIMS] Tortelli、M.、et al。、 "CCN Simulators:Analysis and Cross-Comparison"、Proceedings of the 1st International Conference on Information-centric Networking(ICN '14)、ACM、DOI 10.1145 / 2660129.2660133、2014。

[IMB2014] Imbrenda, C., Muscariello, L., and D. Rossi, "Analyzing Cacheable Traffic in ISP Access Networks for Micro CDN Applications via Content-Centric Networking", Proceedings of the 1st international conference on Information-centric networking (ICN '14), DOI 10.1145/2660129.2660146, 2014.

[IMB2014] Imbrenda、C.、Muscariello、L。、およびD. Rossi、「コンテンツ中心のネットワーキングによるマイクロCDNアプリケーションのためのISPアクセスネットワークのキャッシュ可能なトラフィックの分析」、情報中心のネットワーキング(ICN)に関する第1回国際会議の議事録'14)、DOI 10.1145 / 2660129.2660146、2014。

[Ion13] Ion, M., Zhang, J., and E. Schooler, "Toward content-centric privacy in ICN: attribute-based encryption and routing", Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM (SIGCOMM '13), ACM, DOI 10.1145/2486001.2491717, 2013.

[Ion13] Ion、M.、Zhang、J。、およびE. Schooler、「ICNのコンテンツ中心のプライバシーに向けて:属性ベースの暗号化とルーティング」、SIGCOMMに関するACM SIGCOMM 2013会議の議事録(SIGCOMM '13)、 ACM、DOI 10.1145 / 2486001.2491717、2013。

[Jacobson09] Jacobson, V., et al., "Networking Named Content", Proceedings of the 5th international conference on Emerging networking experiments and technologies (CoNEXT '09), DOI 10.1145/1658939.1658941, 2009.

[Jacobson09] Jacobson、V.、et al。、 "Networking Named Content"、Proceedings of the 5th International Conference on Emerging networking Experiments and Technologies(CoNEXT '09)、DOI 10.1145 / 1658939.1658941、2009。

[Katsaros12] Katsaros, K., Xylomenos, G., and G. Polyzos, "GlobeTraff: a traffic workload generator for the performance evaluation of future Internet architectures", 2012 5th International Conference on New Technologies, Mobility and Security (NTMS), DOI 10.1109/NTMS.2012.6208742, 2012.

[Katsaros12] Katsaros、K.、Xylomenos、G。、およびG. Polyzos、「GlobeTraff:将来のインターネットアーキテクチャのパフォーマンス評価のためのトラフィックワークロードジェネレータ」、2012年第5回新技術、モビリティ、セキュリティに関する国際会議(NTMS)、 DOI 10.1109 / NTMS.2012.6208742、2012。

[Katsaros15] Katsaros, K., et al., "On the Inter-domain Scalability of Route-by-Name Information-Centric Network Architectures", Proc. IFIP Networking Conference, DOI 10.1109/IFIPNetworking.2015.7145308, 2015.

[Katsaros15] Katsaros、K.、et al。、 "Route-by-Name Information-Centric Network Architectures"、Proc。 IFIPネットワーキング会議、DOI 10.1109 / IFIPNetworking.2015.7145308、2015。

[Kaune09] Kaune, S. et al., "Modelling the Internet Delay Space Based on Geographical Locations", 17th Euromicro International Conference on Parallel, Distributed and Network-based Processing, Weimar, Germany, DOI 10.1109/PDP.2009.44, 2009.

[Kaune09] Kaune、S. et al。、 "Modeling the Internet Delay Space Based on Geographical Locations"、17th Euromicro International Conference on Parallel、Distributed and Network-based Processing、Weimar、Germany、DOI 10.1109 / PDP.2009.44、2009。

[Labovitz10] Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, J., and F. Jahanian, "Internet inter-domain traffic", In Proceedings of the ACM SIGCOMM 2010 conference (SIGCOMM DOI 10.1145/1851182.1851194, 2010.

[Labovitz10] Labovitz、C.、Iekel-Johnson、S.、McPherson、D.、Oberheide、J。、およびF. Jahanian、「インターネットドメイン間トラフィック」、ACM SIGCOMM 2010会議の議事録(SIGCOMM DOI 10.1145) /1851182.1851194、2010。

[Lauinger10] Lauinger, T., "Security and Scalability of Content-Centric Networking", Masters Thesis, Technische Universitaet Darmstadt and Eurecom, September 2010.

[Lauinger10] Lauinger、T。、「コンテンツ中心のネットワーキングのセキュリティとスケーラビリティ」、修士論文、Technische Universitaet Darmstadt and Eurecom、2010年9月。

[Lauinger12] Lauinger, Y., et al, "Privacy Risks in Named Data Networking: What is the Cost of Performance?", ACM SIGCOMM Computer Communication Review, Vol. 42, Issue 5, DOI 10.1145/2378956.2378966, 2012.

[Lauinger12] Lauinger、Y。、他、「名前付きデータネットワーキングにおけるプライバシーリスク:パフォーマンスのコストとは」、ACM SIGCOMM Computer Communication Review、Vol。 42、Issue 5、DOI 10.1145 / 2378956.2378966、2012。

[Led12] Lederer, S., Muller, C., and C. Timmerer, "Dynamic adaptive streaming over HTTP dataset", Proceedings of the ACM Multimedia Systems Conference (MMSys '12), pp. 89-94, DOI 10.1145/2155555.2155570, 2012.

[Led12] Lederer、S.、Muller、C。、およびC. Timmerer、「HTTPデータセットを介した動的適応ストリーミング」、ACMマルチメディアシステム会議の議事録(MMSys '12)、89-94ページ、DOI 10.1145 / 2155555.2155570 、2012。

[Lewko11] Lewko, A. and B. Waters, "Decentralizing attribute-based encryption", Proc. of EUROCRYPT 2011, Lecture Notes in Computer Science (LNCS), vol. 6632, pp. 568-588, DOI 10.1007/978-3-642-20465-4_31, 2011.

[Lewko11] Lewko、A。およびB. Waters、「属性ベースの暗号化の分散化」、Proc。 EUROCRYPT 2011、Lecture Notes in Computer Science(LNCS)、vol。 6632、pp.568-588、DOI 10.1007 / 978-3-642-20465-4_31、2011。

[LIRA] Psaras, I., Katsaros, K., Saino, L., and G. Pavlou, "Lira: A location independent routing layer based on source-provided ephemeral names", Electronic and Electrical Eng. Dept., UCL, London, UK, Tech. Rep. 2014, <http://www.ee.ucl.ac.uk/comit-project/publications.html>.

[リラ] Psaras、I.、Katsaros、K.、Saino、L。、およびG. Pavlou、「リラ:ソースから提供されたエフェメラル名に基づく場所に依存しないルーティングレイヤー」、Electronic and Electrical Eng。部署、UCL、ロンドン、英国、技術。 2014年6月、<http://www.ee.ucl.ac.uk/comit-project/publications.html>。

[Mahanti00] Mahanti, A., Williamson, C., and D. Eager., "Traffic analysis of a web proxy caching hierarchy", IEEE Network, Vol. 14, No. 3, pp. 16-23, DOI 10.1109/65.844496, May/June 2000.

[Mahanti00] Mahanti、A.、Williamson、C。、およびD. Eager。、「Webプロキシキャッシング階層のトラフィック分析」、IEEEネットワーク、Vol。 14、No. 3、pp。16-23、DOI 10.1109 / 65.844496、May / June 2000。

[Maier09] Maier, G., Feldmann, A., Paxson, V., and M. Allman, "On dominant characteristics of residential broadband internet traffic", In Proceedings of the 9th ACM SIGCOMM conference on Internet measurement conference (IMC '09), New York, NY, USA, 90-102. DOI 10.1145/1644893.1644904, 2009.

[Maier09] Maier、G.、Feldmann、A.、Paxson、V。、およびM. Allman、「住宅用ブロードバンドインターネットトラフィックの支配的な特性について」、インターネット測定会議に関する第9回ACM SIGCOMM会議の議事録(IMC '09 )、ニューヨーク、ニューヨーク、アメリカ、90-102。 DOI 10.1145 / 1644893.1644904、2009。

[Marciniak08] Marciniak, P., Liogkas, N., Legout, A., and E. Kohler, "Small is not always beautiful", In Proc. of IPTPS, International Workshop of Peer-to-Peer Systems, Tampa Bay, Florida (FL), USA, February 2008.

[Marciniak08] Marciniak、P.、Liogkas、N.、Legout、A。、およびE. Kohler、「小さいことは必ずしも美しいとは限らない」、Proc。 IPTPS、国際ピアツーピアシステムのワークショップ、タンパベイ、フロリダ(FL)、米国、2008年2月。

[MiniCCNx] Cabral, C., et al., "High fidelity content-centric experiments with Mini-CCNx", 2014 IEEE Symposium on Computers and Communications (ISCC), DOI 10.1109/ISCC.2014.6912537, 2014.

[MiniCCNx] Cabral、C。他、「Mini-CCNxを使用した高忠実度コンテンツ中心の実験」、2014年コンピュータと通信に関するIEEEシンポジウム(ISCC)、DOI 10.1109 / ISCC.2014.6912537、2014年。

[Montage] Hussain, A. and J. Chen, "Montage Topology Manager: Tools for Constructing and Sharing Representative Internet Topologies", DETER Technical Report, ISI-TR-684, August 2012.

[モンタージュ]フセインA.とJ.チェン、「モンタージュトポロジマネージャー:代表的なインターネットトポロジを構築および共有するためのツール」、DETERテクニカルレポート、ISI-TR-684、2012年8月。

[Muscariello11] Muscariello, L., Carofiglio, G., and M. Gallo, "Bandwidth and storage sharing performance in information centric networking", Proceedings of the ACM SIGCOMM workshop on Information-centric networking (ICN '11), DOI 10.1145/2018584.2018593, 2011.

[Muscariello11​​] Muscariello、L.、Carofiglio、G。、およびM. Gallo、「情報中心のネットワーキングにおける帯域幅とストレージ共有パフォーマンス」、情報中心のネットワーキングに関するACM SIGCOMMワークショップの議事録(ICN '11)、DOI 10.1145 / 2018584.2018593、2011。

[ndnSIM] Afanasyev, A., et al., "ndnSIM: NDN simulator for NS-3", NDN Technical Report NDN-0005, Revision 2, October 2012.

[ndnSIM] Afanasyev、A。など、「ndnSIM:NDN Simulator for NS-3」、NDN Technical Report NDN-0005、Revision 2、2012年10月。

[ndnSIM2] Mastorakis, S., et al., "ndnSIM 2.0: A new version of the NDN simulator for NS-3", NDN Technical Report NDN-0028, Revision 1, January 2015.

[ndnSIM2] Mastorakis、S.、et al。、 "ndnSIM 2.0:a new version of the NDN simulator for NS-3"、NDN Technical Report NDN-0028、Revision 1、January 2015。

[NEPI] Quereilhac, A., et al., "NEPI: An integration framework for Network Experimentation", 2011 19th International Conference on Software, Telecommunications and Computer Networks (SoftCOM), IEEE, 2011.

[NEPI] Quereilhac、A。、他、「NEPI:ネットワーク実験のための統合フレームワーク」、2011年第19回ソフトウェア、通信、およびコンピュータネットワークに関する国際会議(SoftCOM)、IEEE、2011年。

[OFELIA] Sune, M., et al., "Design and implementation of the OFELIA FP7 facility: The European OpenFlow testbed", Computer Networks, vol. 61, pp. 132-150, DOI 10.1016/j.bjp.2013.10.015, March 2014.

[OFELIA] Sune、M.、et al。、「OFELIA FP7設備の設計と実装:European OpenFlowテストベッド」、Computer Networks、vol。 61、pp。132-150、DOI 10.1016 / j.bjp.2013.10.015、2014年3月。

[ONL] DeHart, J., et al., "The open network laboratory: a resource for networking research and education", ACM SIGCOMM Computer Communication Review (CCR), vol. 35, no. 5, pp. 75-78, DOI 10.1145/1096536.1096547, 2005.

[ONL] DeHart、J。、他、「オープンネットワークラボ:ネットワーキングの研究と教育のためのリソース」、ACM SIGCOMM Computer Communication Review(CCR)、vol。 35、いいえ。 5、pp。75-78、DOI 10.1145 / 1096536.1096547、2005。

[Parisis13] Parisis, G., Trossen, D., and H. Asaeda, "A Node Design and a Framework for Development and Experimentation for an Information-Centric Network", IEICE Transactions on Communications, vol. E96-B, no. 7, pp. 1650-1660, July 2013.

[Parisis13] Parisis、G.、Trossen、D.、H. Asaeda、 "A Node Design and a Framework for Development and Experimenting for a Information-Centric Network"、電子情報通信学会論文誌、vol。 E96-B、いいえ。 7、pp。1650-1660、2013年7月。

[Perino11] Perino, D. and M. Varvello, "A Reality Check for Content Centric Networking", Proceedings of the ACM SIGCOMM workshop on Information-centric networking (ICN '11), DOI 10.1145/2018584.2018596, 2011.

[Perino11] Perino、D.、M。Varvello、「A Reality Check for Content Centric Networking」、Proceedings of the ACM SIGCOMM Workshop on Information-centric networking(ICN '11)、DOI 10.1145 / 2018584.2018596、2011。

[PLANETLAB] Chun, B., et al., "Planetlab: an overlay testbed for broad-coverage services", ACM SIGCOMM Computer Communication Review (CCR), vol. 33, no. 3, pp. 3-12, DOI 10.1145/956993.956995, 2003.

[PLANETLAB] Chun、B.、et al。、 "Planetlab:a overlay testbed for broad-coverage services"、ACM SIGCOMM Computer Communication Review(CCR)、vol。 33、いいえ。 3、pp。3-12、DOI 10.1145 / 956993.956995、2003。

[PRST4.5] Riihijarvi, J., et al., "Final Architecture Validation and Performance Evaluation Report", PURSUIT Project Deliverable D4.5, January 2013.

[PRST4.5] Riihijarvi、J。他、「最終アーキテクチャの検証とパフォーマンス評価レポート」、PURSUITプロジェクト成果物D4.5、2013年1月。

[Psaras11] Psaras, I., Clegg, R., Landa, R., Chai, W., Pavlou, G., "Modelling and Evaluation of CCN-Caching Trees", Proceedings of the 10th international IFIP TC 6 conference on Networking, Valencia, Spain, May 2011.

[Psaras11] Psaras、I.、Clegg、R.、Landa、R.、Chai、W.、Pavlou、G。、「CCNキャッシングツリーのモデリングと評価」、ネットワーキングに関する第10回国際IFIP TC 6会議の議事録、スペイン、バレンシア、2011年5月。

[Psaras12] Psaras, I., Chai, W., and G. Pavlou, "Probabilistic In-Network Caching for Information-Centric Networks", Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12), DOI 10.1145/2342488.2342501, 2012.

[Psaras12] Psaras、I.、Chai、W。、およびG. Pavlou、「情報中心型ネットワークのための確率的ネットワーク内キャッシング」、情報中心型ネットワークに関するICNワークショップの第2版の議事録(ICN '12) 、DOI 10.1145 / 2342488.2342501、2012。

[Quereilhac14] Quereilhac, A., et al., "Demonstrating a unified ICN development and evaluation framework", Proceedings of the 1st international conference on Information-centric networking (ICN '14), ACM, DOI 10.1145/2660129.2660132, 2014.

[Quereilhac14] Quereilhac、A。、他、「統一されたICN開発および評価フレームワークのデモ」、第1回国際情報中心ネットワークに関する国際会議の議事録(ICN '14)、ACM、DOI 10.1145 / 2660129.2660132、2014。

[Renault09] Renault, E., Ahmad, A., and M. Abid, "Toward a Security Model for the Future Network of Information", Proceedings of the 4th International Conference on Ubiquitous Information Technologies & Applications (ICUT '09), IEEE, DOI 10.1109/ICUT.2009.5405676, 2009.

[Renault09] Renault、E.、Ahmad、A。、およびM. Abid、「将来の情報ネットワークのセキュリティモデルに向けて」、第4回ユビキタス情報技術およびアプリケーションに関する国際会議(ICUT '09)、IEEE 、DOI 10.1109 / ICUT.2009.5405676、2009。

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <http://www.rfc-editor.org/info/rfc2330>.

[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、RFC 2330、DOI 10.17487 / RFC2330、1998年5月、<http://www.rfc -editor.org/info/rfc2330>。

[RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, December 2009, <http://www.rfc-editor.org/info/rfc5743>.

[RFC5743] Falk、A。、「Definition of an Internet Research Task Force(IRTF)Document Stream」、RFC 5743、DOI 10.17487 / RFC5743、2009年12月、<http://www.rfc-editor.org/info/rfc5743 >。

[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <http://www.rfc-editor.org/info/rfc6920>.

[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A。、およびP. Hallam-Baker、「Naming Things with Hashes」、RFC 6920、DOI 10.17487 / RFC6920、 2013年4月、<http://www.rfc-editor.org/info/rfc6920>。

[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, <http://www.rfc-editor.org/info/rfc7476>.

[RFC7476] Pentikousis、K.、Ed。、Ohlman、B.、Corujo、D.、Boggia、G.、Tyson、G.、Davies、E.、Molinaro、A.、and S. Eum、 "Information-Centricネットワーキング:ベースラインシナリオ」、RFC 7476、DOI 10.17487 / RFC7476、2015年3月、<http://www.rfc-editor.org/info/rfc7476>。

[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, <http://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月、<http://www.rfc-editor.org/info/rfc7927>。

[RFC7933] Westphal, C., Ed., Lederer, S., Posch, D., Timmerer, C., Azgin, A., Liu, W., Mueller, C., Detti, A., Corujo, D., Wang, J., Montpetit, M., and N. Murray, "Adaptive Video Streaming over Information-Centric Networking (ICN)", RFC 7933, DOI 10.17487/RFC7933, August 2016, <http://www.rfc-editor.org/info/rfc7933>.

[RFC7933] Westphal、C。、編、Lederer、S.、Posch、D.、Timmerer、C.、Azgin、A.、Liu、W.、Mueller、C.、Detti、A.、Corjojo、D。 、Wang、J.、Montpetit、M。、およびN. Murray、「情報中心型ネットワーキング(ICN)を介した適応型ビデオストリーミング」、RFC 7933、DOI 10.17487 / RFC7933、2016年8月、<http://www.rfc- editor.org/info/rfc7933>。

[SAIL-B2] SAIL, "NetInf Content Delivery and Operations", SAIL Project Deliverable D-B.2, May 2012.

[SAIL-B2] SAIL、「NetInf Content Delivery and Operations」、SAIL Project Deliverable D-B.2、2012年5月。

[SAIL-B3] Kutscher, D., Ed., et al., "Final NetInf Architecture", SAIL Project Deliverable D-B.3, January 2013, <http://www.sail-project.eu/deliverables/>.

[SAIL-B3] Kutscher、D。、編、他、「Final NetInf Architecture」、SAIL Project Deliverable D-B.3、2013年1月、<http://www.sail-project.eu/deliverables/>。

[Saino13] Saino, L., Cocora, C., and G. Pavlou, "A Toolchain for Simplifying Network Simulation Setup", Proceedings of the 6th International ICST Conference on Simulation Tools and Techniques (SimuTools '13), 2013.

[Saino13] Saino、L.、Cocora、C.、and G. Pavlou、 "A Toolchain Simplifying Network Simulation Setup"、Proceedings of the 6th International ICST Conference on Simulation Tools and Techniques(SimuTools '13)、2013。

[Saleh06] Saleh, O., and M. Hefeeda, "Modeling and caching of peer-to-peer traffic", Proceedings of the 2006 IEEE International Conference on Network Protocols (ICNP), DOI 10.1109/ICNP.2006.320218, 2006.

[Saleh06] Saleh、O。、およびM. Hefeeda、「ピアツーピアトラフィックのモデリングとキャッシング」、2006年ネットワークプロトコルに関するIEEE国際会議(ICNP)の議事録、DOI 10.1109 / ICNP.2006.320218、2006。

[Salsano12] Salsano, S., et al., "Transport-Layer Issues in Information Centric Networks", Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12), ACM, DOI 10.1145/2342488.2342493, 2012.

[Salsano12] Salsano、S.、et al。、 "Transport-Layer Issues in Information Centric Networks"、Proceedings of the second edition of the ICN Workshop on Information-centric networking(ICN '12)、ACM、DOI 10.1145 / 2342488.2342493、 2012。

[Salsano13] Salsano, S., et al., "Information Centric Networking over SDN and OpenFlow: Architectural Aspects and Experiments on the OFELIA Testbed", Computer Networks, vol. 57, no. 16, pp. 3207-3221, DOI 10.1016/j.comnet.2013.07.031, November 2013.

[Salsano13] Salsano、S。、他、「SDNおよびOpenFlowを介した情報セントリックネットワーキング:OFELIAテストベッドのアーキテクチャの側面と実験」、Computer Networks、vol。 57、いいえ。 16、pp。3207-3221、DOI 10.1016 / j.comnet.2013.07.031、2013年11月。

[SensReqs] Karnouskos, S., et al., "Requirement considerations for ubiquitous integration of cooperating objects", 2011 4th IFIP International Conference on New Technologies, Mobility and Security (NTMS), DOI 10.1109/NTMS.2011.5720605, 2011.

[SensReqs] Karnouskos、S。、他、「協調オブジェクトのユビキタス統合の要件に関する考慮事項」、2011年第4回IFIP国際会議、新技術、モビリティおよびセキュリティ(NTMS)、DOI 10.1109 / NTMS.2011.5720605、2011。

[Smetters09] Smetters, D., and V. Jacobson, "Securing network content", Technical Report TR-2009-01, PARC, 2009.

[Smetters09] Smetters、D。、およびV. Jacobson、「ネットワークコンテンツの保護」、テクニカルレポートTR-2009-01、PARC、2009。

[Sourlas15] Sourlas, V., Tassiulas, L., Psaras, I., and G. Pavlou, "Information Resilience through User-Assisted Caching in Disruptive Content-Centric Networks", 14th IFIP Networking Conference, Toulouse, France, DOI 10.1109/IFIPNetworking.2015.7145301, May 2015.

[Sourlas15] Sourlas、V.、Tassiulas、L.、Psaras、I。、およびG. Pavlou、「Disruptive Content-Centric Networksにおけるユーザー支援キャッシングによる情報復元力」、第14回IFIPネットワーキング会議、ツールーズ、フランス、DOI 10.1109 /IFIPNetworking.2015.7145301、2015年5月。

[Tagger12] Tagger, B., et al., "Update on the Architecture and Report on Security Analysis", Deliverable 2.4, PURSUIT EU FP7 project, April 2012.

[Tagger12] Tagger、B.他、「アーキテクチャの更新とセキュリティ分析に関するレポート」、成果物2.4、PURSUIT EU FP7プロジェクト、2012年4月。

[Tourani16] Tourani, R., Mick, T., Misra, S., and G. Panwar, "Security, Privacy, and Access Control in Information-Centric Networking: A Survey", arXiv:1603.03409, March 2016.

[Tourani16] Tourani、R.、Mick、T.、Misra、S。、およびG. Panwar、「情報中心のネットワーキングにおけるセキュリティ、プライバシー、およびアクセス制御:調査」、arXiv:1603.03409、2016年3月。

[VoCCN] Jacobson, V., et al., "VoCCN: Voice-over Content-Centric Networks", Proceedings of the 2009 workshop on Re-architecting the internet (ReArch '09), DOI 10.1145/1658978.1658980, 2009.

[VoCCN] Jacobson、V.、et al。、 "VoCCN:Voice-over Content-Centric Networks"、Proceedings of the 2009 Workshop on the Re-architecting the internet(ReArch '09)、DOI 10.1145 / 1658978.1658980、2009。

[Watts98] Watts, D. J. and S. H. Strogatz, "Collective dynamics of 'small-world' networks", Nature, vol. 393, no. 6684, pp. 440-442, DOI 10.1038/30918, April 1998.

[Watts98] Watts、D。J.およびS. H. Strogatz、「「小世界」ネットワークの集団ダイナミクス」、Nature、vol。 393、いいえ。 6684、pp.440-442、DOI 10.1038 / 30918、1998年4月。

[Yu06] Yu, H., Zheng, D., Zhao, B., and W. Zheng, "Understanding user behavior in large-scale video-on-demand systems", ACM SIGOPS Operating Systems Review - Proceedings of the 2006 EuroSys conference, Vol. 40, Issue 4, pp. 333-344, DOI 10.1145/1218063.1217968, April 2006.

[Yu06] Yu、H.、Zheng、D.、Zhao、B。、およびW. Zheng、「大規模なビデオオンデマンドシステムでのユーザーの動作を理解する」、ACM SIGOPSオペレーティングシステムレビュー-2006年のEuroSysの議事録会議、Vol。 40、第4号、333-344ページ、DOI 10.1145 / 1218063.1217968、2006年4月。

[Zhang10a] Zhang, C., Dhungel, P., Wu, D., and K. Ross, "Unraveling the BitTorrent Ecosystem", IEEE Transactions on Parallel and Distributed Systems, vol. 22, issue 7, pp. 1164-1177, DOI 10.1109/TPDS.2010.123, 2010.

[Zhang10a] Zhang、C.、Dhungel、P.、Wu、D。、およびK. Ross、「BitTorrentエコシステムの解明」、IEEE Transactions on Parallel and Distributed Systems、vol。 22、第7号、1164-1177ページ、DOI 10.1109 / TPDS.2010.123、2010年。

[Zhang10b] Zhang, L., et al., "Named Data Networking (NDN) Project", NDN Technical Report NDN-0001, October 2010, <http://named-data.net/publications/techreports/>.

[Zhang10b] Zhang、L.他、「Named Data Networking(NDN)Project」、NDN Technical Report NDN-0001、2010年10月、<http://named-data.net/publications/techreports/>。

[Zhou11] Zhou, J., Li, Y., Adhikari, K., and Z.-L. Zhang, "Counting YouTube videos via random prefix sampling", Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference (IMC '11), Berlin, Germany, DOI 10.1145/2068816.2068851, November 2011.

[Zhou11] Zhou、J.、Li、Y.、Adhikari、K.、Z.-L。 Zhang、「ランダムプレフィックスサンプリングによるYouTube動画のカウント」、インターネット測定会議に関する2011 ACM SIGCOMM会議の議事録(IMC '11)、ベルリン、ドイツ、DOI 10.1145 / 2068816.2068851、2011年11月。

Acknowledgments

謝辞

Konstantinos Katsaros contributed the updated text of Section 2.2 along with an extensive set of references.

Konstantinos Katsarosは、セクション2.2の更新されたテキストと広範なリファレンスセットを寄稿しました。

Priya Mahadevan, Daniel Corujo, and Gareth Tyson contributed to a draft version of this document.

Priya Mahadevan、Daniel Corujo、およびGareth Tysonが、このドキュメントのドラフトバージョンに貢献しました。

This document has benefited from reviews, pointers to the growing ICN literature, suggestions, comments, and proposed text provided by the following members of the IRTF Information-Centric Networking Research Group (ICNRG), listed in alphabetical order: Marica Amadeo, Hitoshi Asaeda, E. Baccelli, Claudia Campolo, Christian Esteve Rothenberg, Suyong Eum, Nikos Fotiou, Dorothy Gellert, Luigi Alfredo Grieco, Myeong-Wuk Jang, Ren Jing, Will Liu, Antonella Molinaro, Luca Muscariello, Ioannis Psaras, Dario Rossi, Stefano Salsano, Damien Saucez, Dirk Trossen, Jianping Wang, Yuanzhe Xuan, and Xinwen Zhang.

このドキュメントは、レビュー、増加するICN文献へのポインタ、提案、コメント、およびIRTF情報中心のネットワーキング研究グループ(ICNRG)の次のメンバーから提供されたテキストからアルファベット順にリストされています。 E.バチェッリ、クラウディアカンポロ、クリスチャンエステベローゼンバーグ、スヨンエウム、ニコスフォティウ、ドロシーゲラート、ルイージアルフレドグリーコ、ミョンウクチャン、レンジン、ウィルリュー、アントネラモリナロ、ルカムスカリエッロ、イオアニスプサラス、ダリオロッシーノ、ステファノサルファDamien Saucez、Dirk Trossen、Jianping Wang、Yuanzhe Xuan、Xinwen Zhang。

The IRSG review was provided by Aaron Falk.

IRSGレビューはAaron Falkによって提供されました。

Authors' Addresses

著者のアドレス

Kostas Pentikousis (editor) Travelping Koernerstr. 7-10 10785 Berlin Germany

Costas Pentikousis(editor)Traveling Coernerstr。 7-10 10785ベルリンドイツ

   Email: k.pentikousis@travelping.com
        

Borje Ohlman Ericsson Research S-16480 Stockholm Sweden

Borje Ohlman Ericsson Research S-16480ストックホルムスウェーデン

   Email: Borje.Ohlman@ericsson.com
        

Elwyn Davies Trinity College Dublin/Folly Consulting Ltd Dublin, 2 Ireland

Elwyn Davies Trinity College Dublin / Folly Consulting Ltdダブリン、2アイルランド

   Email: davieseb@scss.tcd.ie
        

Spiros Spirou Intracom Telecom 19.7 km Markopoulou Avenue 19002 Peania, Athens Greece

Spyros Spyros Intracom Telecom 19.7 km Markopoulou Avenue 19002 Peania、Athens Greeke

   Email: spis@intracom-telecom.com
        

Gennaro Boggia Dept. of Electrical and Information Engineering Politecnico di Bari Via Orabona 4 70125 Bari Italy

ジェンナロボジア部の電気および情報工学の技術Politecnico di Bari Via Orabona 4 70125バーリイタリア

   Email: g.boggia@poliba.it