情報指向ネットワーキングの研究動向
†Research Trends of Information-Centric Networking
朴 容 震 Yong-Jin PARK
あらまし
Future Internet
のアーキテクチャとして，情報指向ネットワーキングが注目されている．これは，従来の
IP
プロトコルによるホスト中心のアクセスと異なり，コンテンツの名前 を使って直接，情報にアクセスするものである．本稿では情報指向ネットワーキング登場 の背景，その概要および特徴について解説する．さらに，学会活動，標準化動向および研 究課題について概説する．†本稿は平成25年２月27日の第９回早稲田大学−NTT技術交流会での講演に一部加筆・修正を加えたものである．
1 はじめ
Future Internet
のアーキテクチャとして情報指向ネッ ト ワ ー キ ン グ（ICN: Information-Centric Networking
） が最近注目を浴びている．現在のインターネットは，IP
プロトコルを中心としており，ホストすなわち場所 に依存している．これに対しICN
では，コンテンツの 名前を使って，直接，情報にアクセスする．ICN
は，このようなアーキテクチャの総称であり，いくつかの 提案がなされている．具体的なものとして，データ指 向（
Data-Oriented
）・名前付きデータ（Named Data
）・コンテンツ指向（
Content-Centric
）ネットワーキング などがある．なお，本稿では，コンテンツ，データ，情報の用語は．交換可能である．
以後では，
Future Internet
研究とICN
の背景，ICN
の特徴，具体例，学会活動および標準化動向を概説す る．おわりに研究課題について述べる．2 Future Internet 研究
インターネットは，世界の22億人以上が利用してお り，非常に成功した技術である．現在のインターネッ トは，1960年および1970年代に作られた基本技術に依 存している．しかし，インターネットを使う環境がそ の当時と現在では，大きく変化した．たとえば，研究 用ネットワークから商用ネットワーク，小規模利用者 から大規模，信頼できる利用者から多くの悪用する者 の出現，固定ホストから移動端末，遠隔ログインおよ びファイル転送応用からウェブ・ビデオ・ソーシャル ネットワーク応用へと変わった．これらの変化に対応 するために，インターネットプロトコルの改善をする 必要があり，図１のように多くの機能が追加および新 たな階層が導入された．
インターネットの重大な問題点としては，次のこ
とがあげられる．１）セキュリティ（
Security
）：ウイ ルス，DDoS
攻撃，スパムメールに脆弱，２）移動性（
mobility
）：端末が固定から移動に主流が変わって移動性支援が重要，３）拡張性（
scalability
）：利用者数，端 末数，トラフィックにおける規模の急増，４）管理性（
manageability
）：ネットワーク運営・監視・制御機能 の不足．また，インターネットが社会インフラとして 重要性が増しているなか，近未来に解決すべき問題と しては，災害，老齢化社会，エネルギー問題，食糧危 機，医療，経済格差，犯罪防止などがある．このような状況を考慮して，2005年頃に，新しいイ ンターネット技術をゼロから作り直そう（
clean slate
設 計）というFuture Internet
研究が始まった．2005年米 国では米科学財団（NSF
），2007年ヨーロッパのFP
7（7
th Framework Programme
）が研究支援を始め，2007 年日本は新世代ネットワーク（NWNG: New Generation Networks
），2006年韓国でのFIF
（Future Internet Forum
） が設立した．しばらくの間，注目されるアーキテクチャ の出現がなかったが，2010年頃からICN
の研究が注目 されるようになった．ᯏ⢻䈱䈘䉌䈭䉎ㅊട Protocol Layer䈱䈘䉌䈭䉎ᝌ
図１：インターネットへの新しい機能の追加/継ぎ当て［1］
米国
NSF
はFIND
（Future Internet Design
）プロジェク トの後続として，2010年FIA
（Future Internet Architecture
） プロジェクトを始めた．FIA
では以下の５個の研究を支援 している：１）
Named Data Networking
（ICN
プロジェクト），２）NEBURA
（クラウドコンピューテイング指向アーキテクチャ），３）
MobilityFirst
（無線移動端末指向アーキ テクチャ），４）eXpressive Internet Architecture
（XIA
： コンテンツ・ホスト・サービスの３タイプおよび発展 性を考慮），５）ChoiceNet
（プロトコルの各層で選択 が可能なアーキテクチャ）．これらの共通点は，セキュ リティ強化であるが，情報指向の概念も取り入れてい る．3 ICN出現の背景
1980−1990年代のインターネットの主要トラフィッ クは遠隔ログインやファイル転送などの遠隔資源共有 であった．その後，主要トラフィックはウエブあるい は映像の情報共有・アクセスにシフトしている．前者 のトラフィックを扱うための通信モデルは，
host-to- host
型であり，ロケーション指向ネットワーク層であ るIP
プロトコルが適している．後者に適したモデル は，information-to-user
型である．現在のインターネッ ト上でこれを実現するために，CDN
（Content Delivery Network
），P
2P
（Peer-to-Peer
）が考案された．しかし，これらは，応用層オーバレイであり，本質的な解決策 ではない．
また，図２からは，米国でのトラフィックの推移が 分かる．主要なトラフィックは，1990年代にはファイ ル転送と
P
2P
，2010年代 はビデオと変化を示している．これからもビデオの比 率がより増加する傾向にあるので，ネットワーク機能 としていかにビデオコンテンツを効率的に配送するか が大きな課題となる．以上をネットワークアーキテク チャレベルで解決しようとICN
が提案された．4 ICNの特徴
図３は，概念的にインターネットと
ICN
を比較し ている．現在のインターネットは，URL
をIP
アドレ スに変換し，それを基にコンテンツプロバイダーにア クセスするが，ICN
ではコンテンツ名で直接，ネット ワーク内のコンテンツにアクセスできる．具体的な
ICN
の特徴をみると，１）名前付きコンテ ンツの利用により，ロケーションから独立で，より直 接的にコンテンツへのアクセスが可能であり，経路制 御も名前ベースで行われる．２）セキュリティ機能が コンテンツレベルに組み込まれているので，従来のIP
のように通信路をセキュアにする方法より利点が 多い．３）インネットワーク（in-network
）キャシン グ機能によりネットワーク内でコンテンツの複製を貯 蔵する．これに関して図４では，ユーザ１がコンテン ツを要求すると，要求パケットがルータＡのコンテン ツプロバイダーに到着し，コンテンツがユーザ１に転 送される．コンテンツはその途中でルータＡ，Ｂ，Ｄ にキャシュされる．次にユーザ２が同じコンテンツを 要求すると，要求パケットがルータＢに送られ，ルー タB
はキャシュしているコンテンツを送り返す．その 時，ルートＥにもキャシュされる．このような方法を
on-path
キャシュと呼んでおり，特定のルータだけにキャシュする
off-path
キャシュと呼ばれる方法もあ図２：米国インターネットトラフィックの比率［2］
Name ( /YouTube/Video/A) User
Name ( /YouYY Tube
ICN
IP Address㩷(74.125.235.69)
Internet IP
DNS
Provider
㽵Contents
Provider
Cache Pr
Cachhe
図３：現在のインターネットとICNの比較
A
D
C B
G
E F
User1 User2 User3 User4
㽲
㽲
㽲
㽳
㽳
㽳 㽴 㽴 㽵
㽵
B
D E
A
Content provider図４：in-network （on-path） キャシングのメカニズム㩷
る．４）キャシングにより，複数のルータがコンテン ツの複製を持つので，アクセスの低遅延および高信頼 が可能になる．５）このキャシュを利用することによ り，移動性サポート（特に，利用者移動性）も容易と なる．６）また，
ICN
は，本質的にマルチキャストを 可能にしている．現在のインターネットの成功の原因のひとつに砂時 計（スリムなウエスト）アーキテクチャがある．これ がインターネットのデザインをエレガントにかつ強力 にしている．この中心はシンプルかつユニバーサルな ネットワーク層（
IP
）があり，それがグローバルな相 互連結に必要な機能性を具現している．ICN
ではコン テンツを中心とした砂時計アーキテクチャを作ること が重要な目標である（図５参照）．5 ICN研究プロジェクト
ICN
の研究プロジェクトは2000年代の後半に始まっ た． 米 国 で は，2007年 にUCB
に よ りDONA
（Data- Oriented Network Architecture
［3］が発表され，続いて） ゼロックスのCCN
（Content-Centric Networking
［4］，） 2010年にはNSF
がNDN
（Named Data Networking
）プ ロジェクトを支援している．DONA
は，その後のICN
の研究に影響を与えたが，継続されていない．CCN
とNDN
は，同じ研究者が参加しているので，同一の ものと見なされる．ヨーロッパでは，FP
７が次のよ うな，いくつかのICN
プロジェクトを支援している．PURSUIT
［5］（この直前のプロジェクトはPSIRP
），NetInf
［6］（この後続プロジェクトはSAIL
），COMET
［7］，その他がある（図６参照）．代表的なプロジェク トを整理したものが表１である．表の最後の行はプロ
トタイプソフトウエアであり，自由にダウンロードす ることができる．
6 基本オペレイション
ここでは，代表的な
CCN
，PURSUIT
，NetInf
の基 本オペレイションについて述べる［8］．６．１ CCN
（1）CCNの基本オペレイション
CCN
は２種類のパケットのみを使う．コンテン ツ要求パケットであるインタレストパケット（IntP:
Interest Packet
）と要求されたコンテンツを送り返す応 答パケットのデータパケット（DatP: Data Packet
）で ある．そのフォーマットを図７に示す．図８のように，利用者１は，要求するコンテンツ名を含む
IntP
を発 信する（図８①）．これを受信したCCN
ルータ１はIP 䉮䊮䊁䊮䉿
䉟䊮䉺䊷䊈䉾䊃 䌉䌃䌎
㩷
図５：砂時計アーキテクチャ
図７：CCNの２種類のパケット［4］
USA EU
NDN
PURSUIT COAST NetInf
COMET ALTCANTE
ENVISION
CCN Router 2 CCN Router 1 2
CCN
Contents Contents
1
Content Provider
User 1 User 2
㽲 㽳
㽴 㽵
㽶 caching 㽷
㽸caching
㽹
㽺 㽻
Interest packet Data packet
図６：米国とヨーロッパのICNプロジェクト 図８：CCNの基本オペレイション 表１：代表的なICNプロジェクト
DONA CCN/NDN PURSUIT NetInf Starting time 2007 CCN （2009）/
NDN （2010） PSIRP （2008）/
PURSUIT （2010） NetInf （2008）/ SAIL （2010）
Principal
Organization UCB Xerox/ UCLA EU EU
Sponsor Xerox/
NSF FIA FP7 FP7
Project budget
（duration） NSF $7.9M
（3yrs） €5.2M （2.5yrs） €12.4M（2.5yrs）
Prototype CCNx/
ndnSIM Blackhawk/
Blackadder GIN
名前による経路選択を行い，次の
CCN
ルータ２に送 る（図８②）．CCN
ルータ２では同様の処理を行い，コンテンツプロバイダーに送る（図８③）．コンテン ツプロバイダーは指定のコンテンツを
DatP
に入れて 送出する（図８④）．これを受けたCCN
ルータ２は そのコンテンツをキャシュし，送り返すためのテーブ ル（PIT
；後述）を参照して，次段に送出する（図８⑤⑥）．
CCN
ルータ１では同様の操作をして（図８⑦⑧），最終的に利用者１に
DatP
が到着する．利用者２ が同じコンテンツを要求した場合は，CCN
ルータ１ にキャシュされたものが利用者２に送り返される（図 ８⑨⑩）．図９は，
CCN
ルータの内部構造を示しており，３ 個のテーブルによって構成されている．CS
（Content
Store
）はキャシュされているコンテンツを管理し，PIT
（Pending Interest Table
）は，このルータを経由し たIntP
の送信元のフェイス番号（CCN
ではインター フェイスのことをフェイスと呼ぶ）を記憶する．FIB
（
Forwarding Information Base
）は，名前ベースのルー ティングテーブルである．図10にCCN
ルータの内 部処理過程を示す．ルータにIntP
が到着すると，そ のコンテンツ名とCS
エントリを比較し一致すれば，DatP
を作り，到着したIntP
のフェイスに送り返す．一致しなければ，
IntP
をPIT
エントリと比較し，一致 すれば，すでに同じIntP
がこのルータから送られて いるので，PIT
の要求フェイスにIntP
が到着したフェ イス番号を加える．一致しなければ，FIB
エントリと のlongest prefix matching
を行う．一致すれば，PIT
にIntP
を登録し，FIB
の指定するフェイスにIntP
を送出 する．DatP
がこのCCN
ルータに到着したときは，ま ずPIT
を参照して，指定するフェイスにこのDatP
を 送出し，同時にCS
に登録する．以上に見られるよう にCCN
のオペレイションは比較的シンプルである．（2）ネーミングシステム
CCN
のネーミングシステムは，図11のような階層 構造であり，human-readable
になっている．現在はこ の例のようなウエブベースのネーミングが提案されて いる．現在のウエブの個数は6.
3×10８個［9］であり，現在使用中の
IP
アドレス数（10９のオーダ）と比較す ると扱いうる数であると言われている．しかし，応用 によっては，異なったネーミングが要求される．現在 のすべてのコンテンツの数は1012〜1015のオーダ［10］だと言われているので，これを対象とするには，更な る研究が必要である．
（3）セキュリティ
CCN
のセキュリティは，コンテンツベースになっ ており，データパケットに組み込まれていることが 特徴である．図７のようにデータパケットではシグ ネチュア（デジタル署名）欄があるので，IP
ネット ワークのように通信毎にセキュアな通信路を作らなく てもよい．そのため，キャッシュされたコンテンツを 利用する場合にも優れている．コンテンツプロバイ ダー側では一方向キャシュ関数を使い，コンテンツ名 とデータのハッシュ値を計算し，それらを加えたもの CCN Router (Forwarding Engine)
㩷
• 㓏ጀ᭴ㅧ
• Human-readable
/parc.com/videos/widgetA.mpg/_v2/_s0
図９：CCN ルータの内部構造
図11：CCNのネーミングシステム
Content
Store PIT FIB
Interest
Data Y
N N
Interest packet cached data Arrived data
Y Adding the arriving face
Sending to the related faces
Y
Adding the entry (name:face)
N
Discard
o
㩷
Hash Values(Name) Hash Values(Data)
Hash Values(HVN & HVD) Private Key Signature(N & C)
HVN + HVD es(H
Encrypt
図10：CCN ルータ内部処理過程 図12：コンテンツプロバイダーでのシグネチュア値の計算
にさらにハッシュ値を計算し，それをプロバイダー
（
publisher
）のプライベートキーで暗号化したものが，シグネチュア値となる．データパケットを受信した利 用者は，その
Signed Info
欄の情報を利用し，プロバイ ダーの公開キーを入手し，図13のようにシグネチュア 値を復号する．その値と受信したコンテンツ名とデー タから得られたハッシュ値を比較し，一致すればデー タの完全性（integrity
）と認証（authentication
）が検 証される．６．２ PURSUIT
PURSUIT
は，CCN
と 違 い，Publish-Subscribe
型 のICN
となっている．そのオペレイションは図14のよ うになる．最初に，パブリッシャ（コンテンツプロバ イダー）は自分の持っているコンテンツをランデブー システム（RS: Rendezvous System
）に登録する（図14①）．サブスクライバ（利用者）は，コンテンツ要求 パケットを
RS
に送る（図14②）．RS
でこの要求が登 録されたコンテンツ名と一致する（図14③）と，RS
はパブリッシャにサブスクライバまでの経路情報（FI:
Forwarding Identifier
）を送る（図14④）．パブリッシャ は，これを利用してコンテンツをサブスクライバに送 る（図14⑤）．途中のルータはこのFI
の情報を利用し，次段に転送する（図14⑥⑦）．また，
PURSUIT
のネー ミングシステムは，階層構造でなく，フラット構造を 採用している．その名前部分は，パブリッシャの公開 キーのハッシュ値とコンテンツラベルを含んでおり，それにより完全性の検証が可能であるとしている．こ の性質は自己証明ネーム（
self-certifying name
）と呼 ばれ，CCN
のような公開キー基盤（PKI: Public-key Infrastructure
）を使わないので，第３パーティの必要 性がないとされている［8］．６．３ NetInf
NetInf
は名前ベースとロケーションベースのハイブリッドな組み合わせのアーキテクチャになっており，
どちらも各ノードで自由に使える．図15に示すよう に，
NRS
（Name resolution service
）が利用する時は，利用者（
consumer
）はNRS
に名前解決要求パケット を送り，それに対するロケーション情報を受信し（図 15①②），それを用いてパブリッシャからデータを得 る（図15③④）．あるいは，利用者は名前ベースルー ティングにより，コンテンツ名を持つ要求パケットを 送出することができる．これがパブリッシャに到着 し，データが要求された利用者に転送される（図15⑤〜⑧）．この戻りの経路は，中継ルータで状態を維持 するか，要求パケットに中継ルータのラベルをスタッ クすることで分かる［6］．また，
NetInf
もPURSUIT
同様，ネーミングにフラット構造を採用している．６．４ ICNの展開
なお，これらの
ICN
の特徴をまとめたものが表２ である．ICN
は，基本的にオーバレイネットワークで あるので，表２の最後の行（トランスポート）にある ように，この表の三つのICN
ともに，IP
層をトラン スポート層として具現できる．ICN
がFuture Internet
アーキテクチャとして使われることを仮定したとき，この性質を考慮すると図16のような
ICN
の展開が考 えられる．初期には，現行のIP
基盤上で使われるICN
部分が多く，ピュアICN
の部分は少ない．IP
部 分は次第に少なくなり，やがてピュアICN
だけにな るだろう．互換性がないために，IPv
4 からIPv
6 の 移行に15年も掛かったことを考えると，ICN
はclean
slate
設計ではあるが，そのオーバレイ性質は大きな利点になっている．
Hash Values(HVN & HVD) Public
Key es(H
Signature(N & C) Unencrypt
Hash Values(Name) Hash Values(Data) Hash Values(HVN & HVD)
HVN + HVD es(H
=?
Key Locator cc
right content
• falsified?
• spooning?
• Wrong Key?
…
API NetInf Roung Cache API API
Applicaon Applicaon
API NetInf Roung Cache
NetInf Roung Cache
API NetInf Roung Cache API
APIApplicaon NRS
Transport n
n he
g Roung
g e
Roung Cache
Transport
g R g R
tInf on
ggg on Publisher
Router
Consumer
Publisher
㽲 㽳
㽴 㽵
㽶
㽹 㽷
㽸 GET GET
DATA DATA
Name resoluon service
図１３：利用者側でのシグネチュア値の検証
図15：NetInfの基本オペレーション［7］
API PURSUIT Roung Cache II Applicaon Transport
API PURSUIT
Roung Cache API APIApplicaon
AP P R AP APApp ort
Rendezvous Rendezvous
PURSUIT Roung R s
Publisher
PURSUIT
Router PURSUIT
Router
Subscriber
SUIT on
ach
g PURSUIT
Roung
ache g
㽲 㽳 㽴
㽵
㽷 㽶 㽸
Scope
Resolve/match
㽸 㽸 㽸 㽸 㽸 㽸
FI Data
㽶 㽶
図14：PURSUITの基本オペレーション［7］
7 学会活動と標準化
IEEE
のコミュニケーションマガジンでは，2012年７ 月号と12月号にICN
小特集を掲載している．ICN
関連 のワークショップが，ACM SIGCOMM
では2011年か ら，IEEE INFOCOM
では2012年から毎年開催されて いる．これらのコンファレンスは，高水準のものとして 定評があるが，これらのコンファレンスと並行してICN
ワークショップが行われている．IRTF
では，2012年４ 月にICNRG
（Information-Centric Networking Research Group
）が活動を始めた．また，ITU
ではSG
13（Future networks including cloud computing
，mobile and NGN
）Q
21でICN
の標準化の検討が2012年に始まった．ここ では，ICN
をData Aware Networking
と呼んでいる．また，アジアの
Future Internet
研究の推進団体であるAsiaFI
（
Asia Future Internet Forum
）では，2010年から若い研究 者のために毎年サマースクールを開いている．2012年か らはNDN
実践ワークショップなどを開催している．8 おわり
ICN
はFuture Internet
アーキテクチャとして注目さ れているが，まだ，研究を要する課題が多くある．そ れらは，ネーミングとセキュリティ，ルーテイングと 名前解決システムの拡張性，移動性とネットワーク管 理，無線ネットワーキングとトランスポートサービ ス，インネットワークキャシングである［11］．また，ICN
のキャパシティおよび限界も研究範囲である．現 在のICN
研究は，コンテンツアクセスに焦点を当て ているが，M
2M
の応用にICN
がどのように 対応できるかも，興味深い．参考文献
［1］ NICT, New Generation Network Architecture AKARI Conceptual Design （ver1.1）, 2007-2008.
［２］ The Web Is Dead. Long Live the Internet | Wired Magazine | Wired. com, http: //www. wired. com/magazine/2010/08/ff_
webrip/all/1.
［３］ Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gonChun, B., and S. Shenker, A Data-Oriented （and Beyond） Network Architecture , In Proceedings of SIGCOMM 2007, Aug 2007.
［4］ V. Jacobson, D. Smetters, J. Thornton, M. Plass, N. Briggs, R. Braynard, Networking Named Content , in Proc. ACM CoNext, Rome, Italy, Dec 2009.
［５］ Fotiou et al., N., Developing Information Networking Further: From PSIRP to PURSUIT , In Proceedings of Proc. BROADNETS, ICST, 2010.
［6］ Christian Dannewitz, Dirk Kutscher et al.. Network of Information （NetInf） – An information-centric networking architecture Computer Communications, 36（2013）, pp721-735.
［7］ A. Bęben, J. Mongay Batalla, D. Florez, W. K. Chai, S. Spirou, N. Wang and M. Georgiades, The Content Mediator Architecture for Content-Aware Networks , Special Issue of Journal Telecommunication Review and Telecommunication News, pp. 1192-1203, No. 8-9, September 2012.
［8］ B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, B.
Ohlman, A survey of information-centric networking IEEE Communication Magazine Vol. 50, Issue 7, Page（s）26-36, July 2012.
［９］ December 2012 Web Server Survey | Netcraft, http: //news.
netcraft. com/archives/2012/12/04/december-2012-web- server-survey. html.
［10］ https: //www.acreo.se/sites/default/files/pub/acreo.se/
EXPERTISE/broadband/icn_for_content_distribution_-_
vendor_perspective_-_sail_meeting. pdf.
［11］ D. Kutscher, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, ICN Research Challenges , IETF draft draft- kutscher- icnrg-challenges-00, Internet Engineering Task Force, February 2013. Work in progress.
表２：各ICN の特徴［7］
CCN PURSUIT NetInf
Namespace hierarchical flat flat Name-data
integrity Signature, PKI Signature, no PKI Signature, no PKI Human-
readable Name Yes No No
Routing
Aggregation Publisher Scope Publisher Routing of
Data Request Name-based NRS (Rendezvous System)
Hybrid of NRS and Name-based Routing of
Data Reverse request path using route state
Source Routing using Bloom filter
Reverse request path using stack, or direct IP connection Caching On-path Off-path On-path/Off-path Transport Many including IP PURSUIT/IP Many including IP
PKI: Public-key Infrastructure NRS: Name Resolution Service
ICN
IP
ICN
IP
• 䌉䌃䌎㩷can be implemented as overlay network
• Migraon from IPv4 to IPv6 took about 15 years because of lack of compability.
㩷 図16：ICNの展開予想
