ICNの発展のために考えたいこと

村⽥正幸⼤阪⼤学⼤学院情報科学研究科murata@ist.osaka-u.ac.jp www.anarg.jp

April 20th, 2016電⼦情報通信学会ICN技術時限研究専⾨委員会第4回 ICN技術研究会

内容

1. ICNのターゲット再考 エンドユーザ︖

2. クラウドを超えるサービス︖ Googleに勝つには︖

3. ICN for XXX︖情報流通基盤として

2M. Murata

ICNのメリット

サーバロケーションに依存しない「サーバ位置を感じさせない」は、ネットワークのそもそもの⽬標

ではなかったか︖ ネットワーク内キャッシュ／処理 ICN以外でもできるユースケース → というと必ずトランスコーディング

セキュリティコンテンツ保護︖ サイバー攻撃耐性︖

マルチキャスト需要はほんとうにあるか︖→ 2020年オリパラ︖

モビリティサポート IPでもできる移動体の⼤前提

M. Murata 3

→ICNの技術的課題の抽出になっている＝研究者の習性

ICN設計要件の例（研究者が説明するとこうなる）

設計プリンシプル• Support multiple and new business

models• Simplicity• “Keep It Simple, Stupid” by David S.

Isenberg→ “Make everything as simple as possible, but not simpler,” by Albert Einstein

• Sustainability, Scalability and Robustness

• Loose coupling• As things get larger they often exhibit

increased interdependence between components

SRC: EC Future Content Networks Group, “Why do we need a Content-Centric Internet? Proposals towards Content-Centric Internet Architectures,” White paper.

設計要件1. Name resolution and findability2. Content-centric routing3. Flexible content business models4. Trustworthiness of content and media

services5. Choice of source and presentation6. Decentralized self-organization

メリット• Content could be stored/cached closer to

the end users• Routers could identify/analyze what

content is flowing through them• Network could dynamically identify what

is the best path to the user• Content could be interactively adapted• Content could be selected and adapted to

the context• Content could be active instead of static

4M. Murata

ネットワーク研究開発の今後

NW⾃⾝がサービスを提供するサービスイネーブラ“ネットワーク=⼟管”からの脱却「オブジェクト指向」ネットワーキング

NW⾃⾝がクラウド機能を提供するNWノードはナノデータセンター化

NW＝トランスポート＋制御＋管理＋サービスサービスイネーブラを組み合わせて⾼度なサービスを実現

7M. Murata

ICNにおける「ユーザ視点」︖

M. Murata 6

ネットワーク内処理

ネットワーク内キャッシュ

ネットワーク内トラヒック低減レスポンスタイムの向上

これがICNの本質か︖ 確かにネットワークトラヒックの⼤部分を

動画が占めているが…

SDN/NFVの例

SDN is about customizing network paths

NFV is about introducing more flexibility in data plane services

Network Operators

Enables network optimization, traffic engineering

Reduces costs

Simplifies the deployment of data plane middleboxes

Enables the fast introduction of new data-plane services

Reduces costs and may increase revenues

End Users X Enables relocating data plane services in the network

Reduces costs, increase flexibility

7

Risso, F., Manzalini, A., & Nemirovsky, M. (2013). Some controversial opinions on Software-Defined data plane services. SDN4FNS 2013 - 2013 Workshop on Software Defined Networks for Future Networks and Services, (November)

M. Murata

利⽤者（エンドユーザ）を対象に考えるとこうなる

NETWORK FOR PEOPLE, NOT FOR GOOGLE実態は

コンテンツホルダーは寡占状態

6

「利⽤者は雲の中がどうなっているか気にせずサービスを利⽤できる」

エンドユーザ︓ データの所有から利⽤へ アプリ（サービス）も所有

から利⽤へ

クラウドとは

コンテンツ中⼼のネットワークへ 事業者も「所有から利⽤」へ スモールスタートの実現 ステークホルダーの再構築 ネットワーク中⽴性の確保 省エネ(︖)ターゲットは⼀般利⽤者ではなさそう

ネットワークは単なる⼟管

M. Murata

ICNの本質︖ 新しい情報流通のしかけ IPの良さを継承しながら、既存IPの問題（ネットワーク内処理、セ

キュリティ、マルチキャスト、モビリティ等）を統合的に解決

M. Murata 9

V. Jacobson, et. al, “Networking Named Content,”ACM CoNext 2009

Etsi nfv

ETSI GS NFV-INF 001 V1.1.1 (2015-01), Network Functions Virtualisation (NFV), Infrastructure Overview

オールマイティ︖マジックワード︖

1. KISSの原則2. Hourglass Model

Everything over IP/IP over Everything3. イノベーションの源泉

複合処理（複合サービス）

クラウドを超えるサービス︖

参考︓ETSI Mobile Edge Computing Use Case 1: Active Device Location Tracking Use Case 2: Augmented Reality Content Delivery Use Case 3: Video Analytics Use Case 4: RAN-aware Content Optimization Use Case 5: Distributed Content and DNS Caching Use Case 6: Application-aware Performance Optimization 10

処理（サービス）

コンテンツ提供

モビリティ＋リアルタイム通信モビリティ＋リアルタイム処理

M. Murata

ICN

クラウド

ネットワークの価値

ネットワーク価値Metcalfʼs law: O(N2)

N ユーザ数Odlyzko et al.,: O(N logN)

サービスやコンテンツ・情報へのアクセシビリティO(logS x logM) (?)

S サービス数、M コンテンツ数

11

Odlyzko, A., & Tilly, B. (2005). A refutation of Metcalfeʼs Law and a better estimate for the value of networks and network interconnections. IEEE Spectrum, July 2006, pp. 26-31.

Van Hove, L. (2014). Metcalfeʼs law: not so wrong after all. NETNOMICS: Economic Research and Electronic Networking, 15(1), 1–8.

拡張クラウド

M. Murata

ICN

ICN FOR SDI

SDI for ICNDeploymentのための基盤

ICN for SDIFCSC: Function Centric Service Chaining

Decouple location from the identity (name) of the function

Can make better use of flexibility offered by NFV

12

Arumaithurai, M., Chen, J., Monticelli, E., Fu, X., & Ramakrishnan, K. K. (2014). Exploiting ICN for flexible management of software-defined networks. In Proceedings of the 1st international conference on Information-centric networking - INC ʼ14 (pp. 107–116).

M. Murata

ICN FOR IOT

実時間ストリームデータ

13

Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T. C., & Wählisch, M. (2014). Information Centric Networking in the IoT: Experiments with NDN in the Wild. Proceedings of the 1st International Conference on Information-Centric Networking, (September), 77–86.

Why ICN for IOT︖ Simplified, natural API

Example: Get “/paris/cordeliers/amphi_farabeuf/temperature”

Increased robustness by caching Lossy wireless links in the IoT Ease data fusion by hop-wise

replication Reduced network layer Inherent auto-configuration IoT devices w/o user interface

M. Murata

ICN FOR DTN

14

Tyson, G., Bigham, J., & Bodanese, E. (2013). Towards an Information-Centric Delay-Tolerant Network. IEEE Infocom Nomen Workshop.

ICN (NDN architecture) DTN (Bundle Protocol)

Disruption Tolerance

Interest packets without FIB entries are dropped. Data packets without PIT entries are also dropped. Either case would occur during disruption

Bundles will be stored and forwarded during disruption,assuming sufficient storage capacity.

API Asynchronous get Socket-like with chronological TTL setting

In-network storage Ubiquitous router caching Temporary store-and-forward buffer

Addressing/Naming Hierarchical addresses for content URI addresses for nodes

Security Model Signing content by producers Signing bundles by senders

Reliable Delivery Receiver driven (re-request) Bundle custody transfer and replication

Fragmentation Managed by sources Managed by network (and optionally source)

COMPARISON OF ICNs AND DTNs(USING NDN [1] AND BUNDLE PROTOCOL [8] ARCHITECTURES)

M. Murata

ICN FOR CONNECTED VEHICLES Application

Vehicular applications are information-oriented in nature. Generated data are relevant to a given location (e.g., points-of-interest notification), and/or to a given time interval (e.g., traffic jam warnings expire in a few hours; parking lots availability lasts a few seconds).

Finally, generated data are intended for groups of recipients (e.g., ads of parking lots to approaching vehicles).

Mobility IP-based host-centric protocols, such as Mobile IP, are known to add complexity and

perform unsatisfactorily in VANETs With ICN, the use of named data simplifies mobility support. The anycasting and in-

network caching properties of ICN allow vehicles to retrieve content from the most convenient (typically, the nearest to the consumer) producer/storage point.

Security Due to ephemeral nature of vehicular communications, trustworthiness should be

based on data instead of the reputation of providing entities.

M. Murata 15

ICN FOR 5G

M. Murata 16

Flat Application-centric Network Architecture No Gateways or Tunnels In-build Mobility In-build Security, Storage and Computing Technology Neutral (any RAN) Application-centric Control Plugin Radio, Licensed/Unlicensed

Paul Polakos, “Laying a New Foundation for 5G,” The MIT Wireless Center 5G Days, May 2015.

INFORMATION-CENTRIC IOT OVER 5G

Naming Application Centric (Hierarchical/Secure/Hybrid )

Scalability Name-Location Split, Localizes Communication where required

Resource Constraints Application aware communication

Context-aware communications Adaptation at Network Level (at all levels)

Seamless mobility handling Flexible Name Resolution (Late Binding)

Data Storage Enables Edge Computing/Multicasting

Security and privacy Very Flexible (User/Device/Service/Content Level)

Communication reliability Adaptable to Best Effort to DTN

Ad hoc and infrastructure mode De-coupling of Application from Transport Layer

M. Murata 17Yanyong Zhang, et al. “ICN based Architecture for IoT,” ICNRG/IETF 88, 2013

ICN FOR OTHER XXXʼS

ICN for Smart XXXNaming

ICN for Information ResilienceInformation caching

ICN for Distributed ComputingIn-network processing

M. Murata 18

ICNのメリット

新しいサービスを実現する情報流通基盤1.資源に対するネーミングサービス2.新しいIoTデータ（ストリーム、情報）を

扱える3.プログラミングの容易性4.利⽤者、サービスに紐付いたモビリティサ

ポート

M. Murata 19

ICN＝ネットワークアーキテクチャ︖ 通信事業者を念頭におくと「産業界への出⼝がないとダメ」「いくらになるのか︖」

仮想化が成功した理由 SDN (Software-Defined Network)／OpenFlow、NFV (Network

Functions Virtualization) HWのコモディティ化、SW制御によるHWの多様な技術発展の吸収、

CAPEX/OPEXの削減（早期展開も含めて） 通信事業者は管理系を含めたプログラマビリティは欲しいが、それを⼿放す（API

を開放する）理由は︖ サービスに対する対価を得る⽣命線

対話すべきは通信事業者ではなく、サービス事業者 どうしても通信事業者と対話したければ

キャッシュによるQoE向上 トラヒック削減 → CAPEX 5G/SDN/NFVのユースケースの展開 → 仮想化とネーミングは⼀体のはず

ただし、強敵は多い︓エッジコンピューティング等M. Murata 20

ICNの研究課題

1. ソースモビリティ2. “コンテンツ”ではなく“サービス”、“情報”のin-

networkキャッシング3. 動的なサービス 実際に必要とされているのは、静的コンテンツへのアクセ

スではなく、サービスの動的な構成／提供4. これらを扱うネーミング 階層化 vs. フラット with 属性

5. クラウドサービスとの融合 ICNですべてを解決できるわけではない クラウドにアクセスするエージェント機能

M. Murata 21

ICN時限研専の⽬的

⼤量で多様な端末の収容、ネットワークの⼤規模化・多様化・複雑化・モバイル化・仮想化、通信の省エネルギー化、安全性・信頼性の確保など、従来の情報ネットワーク分野における学術的基盤では取り扱うことが困難な問題を克服し、また、情報ネットワークの今後の益々の発展を⽀えるために、体系化された情報指向ネットワーク技術を確⽴していくことは急務と⾔えます。そのためには、既存のいわゆる情報通信⼯学だけでなく、その周辺分野、さらにはオペーレーションも含めた技術展開の議論など、多様な視座からのアプローチが求められます。加えて、同分野の国際競争⼒の強化には、欧⽶に並ぶICN拠点形成によるわが国の地位確⽴が必須であります。

本時限研究専⾨委員会では、これまで独⽴して研究開発が推進されてきた情報指向ネットワークを主体的、体系的に捉え、充実した議論の場を提供し、今後の情報通信分野における情報指向ネットワーク技術の⼀層の研究促進を⽬指します。

22M. Murata

次の⼀⼿

「体系的に捉える」とは︖アーキテクチャモデル概念設計そろそろ実装モデル実⽤化のための⼯程

タスクフォース（あるいは合宿）による集中議論︖1. ユースケース2. ユーザメリット（そもそもICNにおけるユーザ︖）3. 国内／国際連携4. 実⽤化への⼯程

M. Murata 23