社団法人 電子情報通信学会THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報TECHNICAL REPORT OF IEICE.

Clean-slate 階層型アーキテクチャにおけるInformation Centric Networking の実現

近藤 賢郎† Heryanto† 嶋村 孔明†† 金子 晋丈†† 寺岡 文男††

†† 慶應義塾大学理工学部† 慶應義塾大学大学院理工学研究科E-mail: †latte@inl.ics.keio.ac.jp

あらまし 本稿では階層型アーキテクチャ上で実現される ICN である ZINK を提案する．ZINK ではアプリケーション層でコンテンツ名をコンテンツ保持ホストのノード ID のリストに解決する．このノード識別子のリストはID/Locator 分離を採用するネットワーク層においてノードロケ―タのリストへと解決される．ID/Locator 分離を採用するネットワーク層はモビリティサポートを効率的に実現する．コンテンツはマルチパスによる帯域集約機能や高機能な輻輳制御機能を備えたトランスポート層により転送される．その際，トランスポート層に備わる既存の輻輳制御機構を利用できる．結果的に ZINK では name-based routing でなく，経路集約可能な locator-based routingのみを用いれば足りる．本稿では ZINK のプロトタイプを IPv6 stack 上で実装しその基本性能を評価した．その結果，ZINK でのコンテンツ探索時間は実用的な範囲でありコンテンツ転送はマルチパスを利用することで効率的に行えることがわかった．

ZINK: An Information Centric Networking Mechanism Based on Layered

Network Architecture

Takao KONDO†, Heryanto†, Komei SHIMAMURA††, Kunitake KANEKO††, and Fumio

TERAOKA††

†† Faculty of Science and Technology, Keio Univ., Hiyoshi 3–14–1, Kohoku, Yokohama, 223–8522 Japan

† Grad. School of Sciense and Technology, Keio Univ., Hiyoshi 3–14–1, Kohoku, Yokohama, 223–8522 Japan

E-mail: †latte@inl.ics.keio.ac.jp

Abstract This paper proposes an ICN mechanism based on a layered network architecture called ZINK. In ZINK,

a content name is resolved to a list node IDs of content servers in the application layer and a node ID is mapped to

a node locator in the network layer, which results in scalable locator-based routing. An ID/Locator split approach

in the network layer can efficiently support server/client mobility. Multipath transfer in the transport layer enables

fast or fault tolerant content transfer. Existing well-tuned congestion control in the transport layer achieves fairness

not only among ICN flows but also among ICN flows and other flows. A proof-of concept prototype is implemented

on an IPv6 stack. Evaluation results show that the time for content finding is practical and efficient content transfer

is possible by using multipath transfer.

Key words Information Centric Networking，Data Centric Networking，New Generation Network

1. 背 景

Information Centric Networking (ICN) はネットワーキングモデルを host-centric なものから information-centric なものへと再構築するため提案された．その動機付けは，今日の

host-centricなインターネットにおけるコンテンツ取得時の可用性，真正性，再利用可能性の問題 [1]に由来する．これらの問題は，ネットワーキングモデルとコンテンツの取得という今日的なインターネットの利用法との間での齟齬があるため生じたものである．現在までに提案されている ICN アーキテクチャの提案

— 1 —

は 2 種類に分類することが出来る．一つ目は request-response

サービスモデルを採用する pull 型である．DONA [1]，NDN [2]

等が該当する．二つ目は publish-subscribe サービスモデルを採用する push 型である．PURSUIT [3] 等が該当する．ICN の代表的な提案の一つである NDN (Named-Data-

Networking) では，“narrow-waist” 層を含むアーキテクチャによりこれらの問題を解決する．NDN では content chunk 層をプロトコル・スタックに導入し narrow waist を形成する．その結果，content chunk 層はコンテンツ名によるネットワーキング (name-based routing) [4]，効率的なコンテンツ転送，輻輳制御，モビリティサポート，アクセス制御と言った様々な機能を一手に引き受けることとなる．本稿はこの narrow-waist 層の形成が ICN に必要な諸機能

を実現する上で適切なのかという疑問に基づいている [5]．つまり，ICN を実現するために必要な様々な機能を narrow waist

層で実現するのが適切か，階層的なアーキテクチャに配置して実現するのが適切かがここでの主眼である．本稿では，narrow

waist 層への機能の過剰な詰め込みはいくつかの問題点を生むことから，階層構造に従った機能の配置が適切だと結論づける．narrow waist 層への機能の過剰な詰め込みに起因する問題点としては，経路情報量の増大に伴うスケーラビリティの問題，narrow waist 層における輻輳制御の必要性 [6] [7]，高速/耐故障性コンテンツ転送に有用なマルチパス転送の実現困難，サーバモビリティにおけるスケーラビリティの問題，高機能のモビリティサポートに有用な高速ハンドオーバの実現困難等が挙げられる．以上の議論をもとに，本稿では階層型アーキテクチャ上に実

現される ICN である ZINK を提案する．ZINK では，アプリケーション層においてコンテンツ名をコンテンツ保持ホスト(content server) のノード ID (node ID) のリストへと解決される．この node ID リストは，ID/Locator 分離を採用するネットワーク層においてノードロケータ (node locator) のリストへと解決される．コンテンツはマルチパス転送をサポートしたトランスポート層によって転送される．結果的に ZINK では name-based routing を用いる必要がなく，経路集約可能なlocator-based routing のみを用いれば足りる．また，ZINK は6 階層新世代ネットワークアーキテクチャである ZNA においても実現される．この場合，ZNA が提供するいくつかのサービスの利用が可能である．すなわち，マルチパス転送による効率的なコンテンツ転送 [8]，ID/Locator 分離 [9] [10] に基づくモビリティサポート，ネットワーク層とデータリンク層間のクロスレイヤ協調 [11] に基づく高速ハンドオーバである．本稿では ZINK のプロトタイプを IPv6 スタック上に実装しその基本性能を評価した．

2. 関 連 研 究

本節では，これまでに提案されている代表的な三つの ICN

アーキテクチャ (DONA，NDN，PURSUIT) をコンテンツを取得するシナリオにおいて以下の比較軸において分析する．すなわち，スケーラビリティ，高速/耐故障性のあるコンテンツ

転送，モビリティサポート，アクセス制御である．2. 1 コンテンツの探索コンテンツの探索メカニズムは name-based routing と名前

解決がある．DONA，NDN は name-based routing を用いるのに対して，PURSUIT は rendezvous と呼ばれる DHT ベースの名前解決を用いる．name-based routing では経路情報の集約ができずに経路情報数はコンテンツ数に比例して増加していくので，DONA と NDN にはスケーラビリティの問題がある．PURSUIT は rendezvous のためにコンテンツ名に flat な名前空間を用いるのでコンテンツ名の集約が困難となる．このため PURSUIT にはスケーラビリティの問題がある．スケーラビリティに関する詳細な議論は 7. 3 節 にて行う．2. 2 コンテンツの転送NDN ではコンテンツを含む Data packet は Interest packet

が転送されたパスを逆順に転送されて client に返送される．PURSUITでは rendezvousの後に Bloom filterによる source-

based routing によってコンテンツが client に返送される．何れの手法でもマルチパスを用いた帯域集約パスや耐故障性を備えたパスの利用は困難である．DONA でのコンテンツ転送は，IP のように host-to-host 通信によるものと NDN のようにコンテンツ要求メッセージが辿ったパスの逆順を辿るものとの何れかを選択できる．2. 3 モビリティ・サポートname-based routing を用いる DONA や NDN での client

mobility は client の移動完了後にコンテンツ要求メッセージを送信することでサポートできる．しかし，移動前に送信したコンテンツ要求メッセージに対応するコンテンツの返信は移動前の場所に送信される．移動前の場所に送られたコンテンツは clinet が受信出来ずに損失する．NDN や DONA におけるserver mobility は移動後に経路情報を再広告することでサポートされる．経路情報の再広告はスケーラビリティの問題を生む．PURSUIT における client mobility は，移動前にコンテン

ツを unsubscribe して移動後に再度 subscription を再度送信することでサポートされる．これは PURSUIT が採用するpublish/subscribe model に則ったものである．しかし，name-

based routing の場合と同様に，移動前に subscribe したコンテンツは移動完了後も移動前の場所に送信される．移動前の場所に送られたコンテンツは client が受信できずに損失する．PURSUIT での server mobility は，rendezvous を構成するDHT ノードの更新を必要とする．client mobility のサポート時のコンテンツの損失を防ぐため

には，高速ハンドオーバ機構が必要となる．高速ハンドオーバ機構は client のデータリンク層における linkdown を検知してネットワーク層に通知する．移動前のネットワークに agent を設置して NDN における高度な client mobility の実現を試みる提案として [12] がある．しかし，このような agent の配置は named-chunk layer のさらなる複雑化を招く．2. 4 アクセス制御3 つ既存研究の何れにおいてもアクセス制御はコンテンツの

暗号化のみをもって提供される．しかし，アクセス権限のない

— 2 —

ISP-1

ContentOwner

in ietf.org

ContentServer

ContentOwner

in isp-1.com

Client

storeietf.org:RFC/rfc2460.txt

ContentServer

storeisp-1.com:latte/paper.pdf

Req. for“iftf.org:RFC/rfc2460.txt”

ContentServer

Reply with“ietf.org:RFC/rfc2460.txt”from the nearestIETF

Logical View Phisical View

CacheHolder

図 1 想定する環境

client が暗号化されていたとしてもコンテンツを取得できるのは適切でない．権限のない client が暗号化されたコンテンツを取得した場合，その暗号化は時間をかけて総当たり式に解読されるリスクを孕むからである．また，解読できない場合でも，どのサーバに当該コンテンツが保存されているかや当該コンテンツが存在するかといった情報が権限のない client にも知れ渡るのは不適切である．文献 [13] は PURSUIT にコンテンツ単位のアクセス制御機

能を導入する．PURSUIT はコンテンツの探索に rendezvous

による名前解決を用いるので，文献 [13] は rendezvous にアクセス制御機構を導入することで client を認証認可する．しかし，文献 [13] では single domain のみの認証認可を提供しているが，インターネットでは multi domain に渡る認証認可 [14]

が必要とされる．

3. 階層型アーキテクチャによる ICN

3. 1 想定する環境本稿が想定する環境は Web のような今日のインターネット

環境と同様に，インターネットに参加する全ての主体がコンテンツを公開しうると想定する．Google や Akamai といった“hyper giants” と呼ばれるコンテンツ・プロバイダだけでなく，個人もインターネット上でコンテンツを公開する．個人は ISP

からインターネットへの接続性を購入したり，コンテンツ・プロバイダが提供するサービスを購入したりしてコンテンツをインターネットで公開する．図 1 に本稿が想定する環境を示す．論理的な視点にたつ場

合，個々のコンテンツはコンテンツ所有者 (content owner)

が所有する．content owner はそれぞれ何らかの組織に属すると考える．図 1 では二人の content owner がそれぞれコンテンツを所有している．IETF に所属する content owner

は ietf.org:rfc2460.txt という名前のコンテンツを所有する．ISP-1 からインターネット接続性を購入する content owner

は isp-1.com:latte/paper.pdf という名前のコンテンツを所有する．但し，この content owner は ISP-1 の中で latte というID を持つと想定する．物理的な視点にたつ場合，個々のコンテンツは content owner により content server に配置される．content server とはコンテンツを保持する物理的なサーバのことである．cache holder は in-network cache を生成するノードである．cache holder はコンテンツのキャッシュを保持する．content server と cache holder を併せて content holder と呼

ぶ．図 1 の IETF に所属している content owner は，2 台のcontent server に ietf.org:rfc2460.txt を配置している．cache

holder は isp-1.com:latte/paper.pdf のキャッシュを保持している．3. 2 コンテンツのネーミングコンテンツ名は大きく hierarchical and human-readable

name と flat and self-certifying name の二つに大別される．hierarchical and human-readable name は現在のインターネットで使われている URL のような構文をとり (e.g.,

ietf.org:rfc2460.txt)，可読な複数のパートが階層的に組み合わさった構成をとる．flat and self-certifying name は，典型的には principal と label の二つの要素から構成される．principal

は content ownerの公開鍵の暗号化ハッシュからなり，label はコンテンツデータのハッシュ値等の principal 毎の local name

である．両者のネーミング手法は共に利点と欠点を持ち合わせる．

human-readable and hierarchical name は階層を構成する個々のパートが可読なため，ヒトがコンテンツ名を容易に識別できる．例えば ietf.org という名前からは IETF という名の組織を容易に連想できる．またコンテンツ名を階層構造に従って集約することが出来るため，コンテンツ数が増加した場合でも名前空間はスケーラブルである．しかし，階層的な構造をもった名前は consistency の問題を孕む．特に content owner の所属組織が変わった場合にはコンテンツ名が変化する蓋然性は高い．また human-readable な名前で self-certifying [15] [16] を行おうとしたときには，PKI のような追加の機能が必要となる．flat and self-certifying name は名前自体に公開鍵のハッシュ

値が含まれるため，self-certifying によるコンテンツの真正性を検証できる．しかし，ハッシュ値を元にした名前はヒトが記憶するのが困難なので，コンテンツ名と content owner とを紐づける仕組み (e.g., PKI) が必要となる [17]．また flat なコンテンツ名の構造は，コンテンツ数が増えるにつれて名前空間中でスケーラビリティの問題を生む．スケーラビリティの問題を緩和するため，DHT / Multi-level DHT (MDHT) を用いた名前空間の管理が提案された [18] [19]．これらの提案ではコンテンツ名の管理を DHT を構成するノード群に分散させ，個々のノードが保持する情報量を低減する．本稿では human-readable and hierarchical name がコンテ

ンツのネーミングに適すると考える．これはコンテンツ名の名前空間をスケーラブルにすると同時に，content ownerにコンテンツに関する情報の manageability を十分に付与するためである．flat and self-certifying name を用いるとき，名前空間におけるスケーラビリティを確保するために DHT/MDHT ベースの名前管理が必要となる．このときコンテンツに関する情報はDHT を構成するノード群に分散される．しかし，通常 content

owner は DHT を構成する全てのノードを管理していないので，結果的に content owner のコンテンツへの manageability

は阻害される．human-readable and hierarchical name を用いる場合の欠

点は次のように解決する．コンテンツの真正性保証は NDN と

— 3 —

同様の手法で self-certifying によって実現する．コンテンツ名中の上位階層の組織は authority となって下位階層の組織が保有する公開鍵を署名して，下位階層の組織が保有するコンテンツの真正性を保証する．また，コンテンツ名の consistency の問題はコンテンツ名のエイリアスによって解決する．content

owner の所属組織が変わってコンテンツ名が変化した場合には，変化前のコンテンツ名から変化後のコンテンツ名へのエイリアスを記述する．こうすることで所属組織の変化に関わらずコンテンツ名の consistency は保たれる．3. 3 階層型アーキテクチャにおける ICN の実現図 2 と図 3 には，ICN の各機能を narrow-wast layer を持っ

たアーキテクチャと階層型アーキテクチャに配置した場合の配置法を示す．1. 節で示した通り，narrow-waist を持ったアーキテクチャに ICN の機能を配置した場合にはスケーラビリティの問題，narrow-waist layer の複雑化，効率的なコンテンツ転送の実現困難，高度なモビリティ・サポートの実現困難といった問題が生じる．これらの問題を解決するため，本論文では図3 で示すような階層型のアーキテクチャで ICN を実現することを提案する．階層型アーキテクチャにおいて ICN の各機能は以下の様に

実現する: コンテンツ名はアプリケーション層の名前解決機構によって content server の node ID (content server ID) のリストに変換される．content server とは content owner が自身のコンテンツを static に配置したサーバのことであり cache

holder は含まない．content server ID は ID/Locator 分離を採用したネットワーク層において content server の locator に変換される．コンテンツ転送は高機能な輻輳制御機能を備えたトランスポート層プロトコルによって行う．結果的にコンテンツ名による name-based routing を用いる必要はなく，経路集約可能でスケーラブルな locator ベースの routing を行えば足りる．モビリティ・サポートは ID/Locator 分離をサポートするネットワーク層の機能により実現する．

Content chunkLayer

Security

IP UDP

Apps.

Broadcast

Forwarding Strategy...

Contenttransfer

Mobilitysupport

Name-basedrouting

Congestioncontrol

図 2 Narrow-waist アーキテクチャにおける ICN

App.Layer

TransportLayer

Apps.Name resolution

ICN controlmultipath transfercongestion control

ID-Loc mappingLoc-based routing

NetworkLayer

content name- scalable/authentic content name to node ID mapping

- in-network caching- bandwidth aggregation- fault tolerance- fairness- mobility support- multihoming support- scalable routing

Name ResolutionFunctions Features

Node IDs ofcontent servers

Node IDs ofcontent servers

図 3 階層型アーキテクチャにおける ICN

ContentServer

(Host ID: HID2)

ContentServer

(Host ID: HID1)ContentOwner

CMA

content owner’s domain

StoreContent

RegisterContentHolder ID

ietf.org:RFC/rfc2460.txt HID1HID2

Name Host ID

．．． ．．．

Mapping tabel after the registration 12

図 4 Content mapping system

org.

.

ContentServer

Client

CMA

CMA AAA

1’RetrieveCH IDs List

3 TransferPath Estab.

4 RetrieveContent

2RetrieveAttr. Info.

ietf.org.

The nearestfrom Client

1’’

2’4’

CMA

ContentServerQuery

CMA1

図 5 コンテンツ取得手順

4. ZINK の設計

4. 1 コンテンツの管理ZINK 上の全てのコンテンツは content owner’s domain と

label からなるコンテンツ名 (e.g., ietf.org:rfc2460.txt) を保有する．content owner’s domain (e.g., ietf.org) は content

owner が所属する組織の名前を示す．従って，content owner’s

domain は content server とは無関係である．content owner’s

domainは ZINK上のコンテンツの管理単位となる．label (e.g.,rfc2460.txt) は content owner’s domain 内でのコンテンツのlocal 名である．CMSはコンテンツ名とコンテンツを保持する content server

ID リストのマッピング情報を管理する．CMS は今日のインターネットの DNS と同様に，各 content owner’s domain に階層的に配置された Content Mapping Agent (CMA) によって構成される．図 4 に示すように，content owner は ZINK

上で公開するコンテンツを content servers に配置する．その後 content owner はコンテンツ名 (e.g., ietf.org:rfc2460.txt)

と content servers ID リストのマッピングを，自身が属するcontent owner’s domain の CMA に登録する．CMA に登録されたコンテンツは ZINK 上でグローバルに公開される．コンテンツを取得しようとする client は，CMS に問い合わ

せて content serever ID リスト (e.g., {HID1, HID2}) を取得する．client は当該マッピング情報 (e.g., ietf.org:rfc2460.txt

-> {HID1, HID2} を持った CMA を DNS のような iterative

なクエリによって発見する．4. 2 コンテンツ取得手順図 5 に ZINK におけるコンテンツの取得手順を示す．client

が ietf.org:rfc2460.txt という名前のコンテンツを取得しようと試みている場合を想定する．まず Client は cms query メッセージと cms reply メッセー

— 4 —

ジを用いて ietf.org ドメインの CMA を探索する．この過程は今日のインターネットの DNS と同様に，ルートドメインのCMA から順に itarative に探索する (図 5-1).

ietf.org ドメインの CMA を発見後，ietf.org:rfc2460.txt のContent Server ID リスト取得のために client は cms query

メッセージを送信する．CMA からは Content Server ID リストを含む cms reply メッセージの返信を受ける (図 5-1’)．コンテンツがアクセス制御のもとにある場合は，CMA は AAA

(Authentication, Authorization, and Accounting) サーバに問い合わせて client のアクセス権を確認する (図 5-1”)．client は CMA から取得した Content Server ID リストを元

に最適な Content Server を選び出して info request メッセージを送信する．Content Server からはコンテンツの属性情報(e.g., ファイル形式，ファイルサイズ等) を含む info reply メッセージの返信を受ける (図 5-2)．コンテンツがアクセス制御のもとにある場合は，Content Server は AAA サーバに問い合わせて client のアクセス権を確認する (図 5-2’)．clientは Content Serverから取得したコンテンツの属性情報

をもとに受信バッファ等を作成した後に，Content Server にコンテンツ転送パスの確立を要求するため init request メッセージを送信する．Content Server はコンテンツの転送パスの確立を終えてから client に init reply メッセージを送信する (図5-3).

clientはコンテンツの取得のために content request メッセージを Content Server に送信する．Content Server はコンテンツのデータを含んだ content reply メッセージを client に返信する (Fig.5-4)．コンテンツがアクセス制御のもとにある場合は，Content Server は AAA サーバに問い合わせて client のアクセス権を確認する (図 5-4”)．4. 3 ZINK でのキャッシングZINKでは Content Mapping System Cache (CMS Cashe)，

Content Server Cache (CS Cache)，Content Cache の 3 種類のキャッシュを扱う．CMS Cache は domain の名前とそのCMA の Host ID との対応を保持する．CS Cache はコンテンツ名と その Content Server ID リストとの対応を保持する．Content Server ID は content owner が自身のコンテンツをstatic に配置したサーバの ID であり，cache holder の node

ID は含まれない．Content Cache はコンテンツ名とそのコンテンツのデータを保持する．cms query メッセージが CMS Cache にヒットした場合 (図

6)，CMS Cache により CMA の Host ID が得られる．このため，後に続く ietf.org ドメインの CMA を itarative に探索する過程を省略できる．cms query メッセージが CS Cacheにヒットした場合 (図 7)，

client が取得を試みるコンテンツの Content Server ID リストが得られる．このため，後に続く ietf.org ドメインの CMA をitarative に探索する過程の全てを省略出来る．info request メッセージが Content Cache にヒットした場

合 (図 9)，client は取得を試みていたコンテンツをこのキャッシュから得ることができる. このため，当初の info request メッ

org.

.

ContentServer

Client

CMA

CMA

1’

34

2

ietf.org.

CMA

ContentServer

1

CMSCache

図 6 cms query メッセージのCMS cache へのヒット

org.

.

ContentServer

Client

CMA

CMA

34

2

ietf.org.

CMA

ContentServer

1

CSCache

図 7 cms query メッセージのCS cache へのヒット

org.

.

ContentServer

Client

CMA

CMA

1’

34

ietf.org.

CMA

ContentServer

1

ContentCache

2

図 8 info request メッセージのContent cache へのヒット

org.

.

ContentServer

Client

CMA

CMA

ietf.org.

CMA

ContentServer

1

ContentCache

図 9 cms query メッセージのContent cache へのヒット

L6

L5

L4

L3

L1, L2

Applications

sophisticated transfer paths(bundled/spatially-spliced path etc)

end-to-end transfer(TCP, UDP)

networking by host ID(ID/locator split)

図 10 Z Network Architecture

セージの宛先ノードから当該キャッシュノードまでのコンテンツ転送過程を省略できる．cms query メッセージが直接 Content Cache にヒットした

場合 (図 9)，client は取得を試みていたコンテンツをこのキャッシュから得ることが出来る．このため，CMA の探索過程やcontent server からのコンテンツの転送過程を省略できる．

5. ZINK on ZNA

5. 1 ZNA 概要ZNA は clean-slate アプローチに基づく 6 階層新世代ネット

ワークアーキテクチャである (図 10)．ZNA にはいくつかの特長がある．まず ZNA はアプリケーション層に高機能な通信パスを提供するためにセッション層 (L5 ) [8] を導入する．トランスポート層 (L4 ) が提供するソケット間の通信路 (L4-path) ではアプリケーションにプリミティブな通信機能しか提供できない．L5 ではこれらの帯域集約や耐故障性保証といった機能を適切にモデル化した高機能なパス (L5-path) を提供する．L5-path の具体例としては bundled path，spatially-spliced

— 5 —

ApplicationLayer (L6)

SessionLayer (L5)

TransportLayer (L4)

NetworkLayer (L3)

Link and Phy.Layer (L1-2)

Apps.

budled path

Name Resolution SystemAAA Infrastructure

ZNP

spatially-spliced path

TCP UDP

Ethernet WiFi

ZINK control in-network cache

...

...

Functions Features

inter/intra-node cross-layer cooperation

- authentication and authorization of clients- scalable/authentic content name to node ID mapping

- bandwidth aggregation- fault tolerance- ZINK overlay network

- ID/Loc split- mobility/multihoming support- locator based routing

- end-to-end transfer (w/ or wo/ reliability and congestion control)

図 11 ZINK architecture on ZNA

path がある．bundled path とは，複数の L4-path を束ねたL5-path である．束ねた L4-path を同時に使用することにより帯域を集約した L5-path を提供できる．複数の L4-path のうち 1 つを通信に使用し他を予備とすることで，L4-path に障害が発生した場合でも即座に予備の L4-path を使うといった耐障害性を持った L5-path を提供できる．spatially-spliced

path とは，空間的に複数の L4-path を中間ノードの L5 でつなぎ合わせて構成した L5-path である．L4-path をつなぎ合わせるノードを L5-relay (splicer) と呼ぶ．L5-relay はパケットを中継する際，設置されたポリシに従ってパケットの中継の可否を判断したり，必要に応じてヘッダの内容を書き換える．spatially-spliced path は大きな遅延を含む L5-path を splicer

で分割し，遅延の小さな複数の L4-path とすることができる(TCP acceleration [20])．splicer による柔軟なポリシの適用は効率的なコンテンツ転送をサポートする．また，ZNAのネットワーク層 (L3 )はノード ID上副層と for-

warding 下副層に分離される [9] [10]．このためノード ID (ID)

とノードロケータ (Locator) は分離される．この ID/Locator

分離のアプローチはモビリティ・サポートやマルチホーミングを容易とする．ハンドオーバのような動的なネットワーク状態変化に適応するために，ZNA ではノード間クロスレイヤ協調機能 [11] が採用されている．5. 2 ZINK Architecture on ZNA

ZINK の各機能を ZNA 上に配置して図 11 を得る．アプリケーション層 (L6 ) では client/server アプリケーション用のAPIs，名前解決システム (CMS)，AAA 基盤 [14] といった機能が提供される．AAA 基盤では ZINK 上の client を認証認可する．ZINKネットワークはセッション層 (L5 )が提供する spatially-

spliced path 上に構築されるオーバレイ・ネットワークである．インターネットを構成する全ノードが ZINK をサポートする必要はない．ZINK をサポートするノードは L5 にてコントロール・メッセージを交換する一方，それ以外のノードはそれらのメッセージをネットワーク層 (L3 ) で forwarding する．ZINK は L5 が提供する複数の L5-path をコンテンツ転送に

利用可能である．bundled path はマルチパスを利用することで，帯域集約による高速転送や耐故障性を備えたパスでの転送

zinkd ・Signaling control messages・Content transferpath establishment・Self-Certifying

CMS・Name resolution・Mapping info. management

Cache Manager・Cache creation・Cache matching

User App.・Browser Emulator・Video streamer

Overlay Library (overlay network establishment)

L5

TCP, mpTCP, UDP, lin6, IPv6L4/L3

図 12 実装モジュール

表 1 ノード内処理時間cms query info request init request

Processing Time 613 µs 1,068 µs 2,371 µs

を実現する．spatially-spliced path は大容量長距離ファイル転送での TCP acceleration を実現する．さらに L5 には ZINK での in-network cache の生成・管理

機能がある．これはネットワークを流れるパケットに含まれるZINK のセマンティクスを L5 は解釈できるからである．トランスポート層 (L4 ) が提供する二種類のデータ転送機能をZINK では使用できる．輻輳制御，フロー制御，伝送の信頼性を伴ったデータ転送提供するを TCP と，ベストエフォートなデータ転送を提供する UDP である．L3 では ID/Locator 分離が採用されており，モビリティやマルチホーミングをサポートする．ノード間クロスレイヤ協調機構はデータリンク層のリンク状態の変化をすばやく L3 に通知することで，高速ハンドオーバを実現する．

6. ZINK のプロトタイプ実装

本稿では IPv6 スタック上のユーザアプリケーションとしてZINK のプロトタイプを実装した．図 12 に ZINK を構成するモジュールを示す．ZINK はアプリケーション層にオーバレイ・ネットワークとして構成される．オーバレイを構成するためにのライブラリは ZINK daemon (zinkd) から呼び出される．zinkd は制御メッセージのシグナリング，コンテンツ転送パスの確立，self-certifying [15], [16] を行う．CMS は名前解決サービスを提供しコンテンツ名と content server ID とのマッピングを管理するデーモンである．IPv6 スタック上に ZINK のプロトタイプを作成するに当

たり，ZNA 中のいくつかの機能を以下のように代用して実現した．ZNA L5 が提供するマルチパス転送による帯域集約はMultipathTCP (mpTCP) [21] により代用した．mpTCP はTCP オプションを指定することで TCP ストリームを複数経路で転送することを可能とするプロトコルである．ネットワーク層における ID/Locator 分離機構としては LIN6 [22] を用いた．LIN6 は IPv6 と互換性のある ID/Locator 分離プロトコルである．

7. 評価と考察

7. 1 コンテンツ探索時間本節では，作成したプロトタイプにおける cms query，

— 6 —

0  

5  

10  

15  

20  

103 104 105 106

Nod

al  Procedu

re  Tim

e  [m

s]  

Num  of  Entries  [log10]

cms_query  

info_request  

図 13 ノード内処理時間とデータベースのエントリ数

info request，init request の各コントロール・メッセージのノード内処理時間を示す．その後，コンテンツ探索時間を推論する．プロトタイプは KVM hypervisor 上で動作する仮想マシン環境において動作させた．Hypervisor マシンには Intel

Core i7-3770S processor，8GB RAMが搭載されている．IntelCore i7-3770S processor には論理的には 8 個の CPU が搭載されていると見なせる．Hypervisor 上で 2 台の仮想マシンを立ち上げ，それらに合計 4 CPU と 4GB RAM を割り当てて評価を行った．表 1には典型的なシナリオを想定した描くコントロール・メッ

セージのノード内処理時間を示す．cms query と info request

メッセージのノード内処理時間については，CMA内のマッピング情報と Content Server 内のコンテンツ数がそれぞれ 10,000

エントリとしたときの値である．CMA と Content Server それぞれのエントリ数を 10,000 としたのは以下の統計資料に依る．今日の Web において，1 組織辺りが保有するコンテンツ数の平均は 9,132 個 [23]，1 ホスト当たりが保有するコンテンツ数の平均値は 2,684 個 [23] である．通常，インターネットにおける end-to-end 通信の Round Trip Time (RTT) は数十msec のオーダであることから，表 1 に記したノード内処理時間は RTT に比して十分小さな値であると言える．図 13 はデータベースのエントリ数と cms query と

info request の両メッセージのノード内処理時間の関係を示す．ZINK はコンテンツのネーミングに階層的な名前空間を用いるので，tier-1 domian (e.g., gTLDs adn ccTLDs) の CMA

には膨大なエントリが蓄積されると推察できる．例えば我が国のccTLD である .jp domain の DNS 権威サーバには 1.3× 106

個 [24] の ゾーン が登録されている．この値を図 13 に当てはめると，tier-1 domain にある CMA のノード内処理時間は約 20 msec となることがわかる．info request メッセージについては，Content Server に登録されているコンテンツ数が1.0 × 105 個であったとしても，ノード内処理時間 10msec に満たないことが図 13 からわかる．このコンテンツ数は現在のWeb での 1 サーバ辺りのコンテンツ数の約 40 倍の値である．以上の結果から，ネットワーク中にキャッシュがない場合に

コンテンツの探索時間 T は (1) 式のように定式化できる．但し RTT は client と CMA/Content Server との間の RTT，n

はコンテンツ名に含まれるの domain の階層数とする．(root

domain を 0 階層目の domain とする) (1) 式では tier-1 do-

main における cms query メッセージの処理時間を RTT +20

msec，tier-1 以外の domain での cms query メッセージの処理時間を RTT + 0.613 msec，info request メッセージの処理時間を RTT + 1.068 msec と想定している．

T = (RTT + 20) + n(RTT + 0.613) + (RTT + 1.068) (msec)(1)

cms query メッセージが CMS cache にヒットした場合，(1)

式は 2RTT + 0.613 + 1.068 msec に短縮される．cms query

メッセージが CS cache ないし Content cache にヒットした場合，(1) 式は (RTT + 1.068) msec に短縮される．今日のインターネットにおける DNS の場合と同様に cms query メッセージが CMS cache にヒットする確率は高いので，T はおよそ 2RTT となる．一方，NDNでのコンテンツ探索時間 Tndn は (2)式のように

定式化できる．但し proc は個々の NDN ノードでのノード内処理時間，h を client から Content Server までの hop count

とする．

Tndn = RTT/2 + proc× h (2)

proc は RTT と比して十分に小さな値と想定すれば，Tndn はRTT/2 と近似できる．従って両者のコンテンツ探索時間を比較すると，ZINK の場合は NDN の場合より約 2n 倍長くかかると推定できる．7. 2 コンテンツ転送時間今日のインターネットでは例えば LTE 回線と Wi-Fi のよう

に，一台のデバイスが複数のインターフェイスを持つことが一般的となった．ZINK はコンテンツ転送にマルチパス転送が利用できる．対して，NDN は Interest packet が転送されたパスと逆順に Data packet を forward する必要があるため，コンテンツ転送にマルチパス転送を利用できない．Client と Content Server 間に 2 本の disjoint なパスがあ

る環境で，(i) path-1 を 1 本だけを使ってコンテンツ転送するとき (single path transfer) と (ii) mpTCP により path-1 とpath-2 の 2 本を使ってコンテンツ転送するとき (multipath

transfer) のスループットを比較した．両方のパス共に RTT は10 ms に設定した．スループットの計測は client にて行った．表 2 はボトルネックリンクの帯域を 100 Mbps としたとき

の single path transfer のスループットを示す．対して，表 3

は path-1 のボトルネックリンクの帯域を 100 Mbps で固定して path-2 のボトルネックリンクの帯域を変化させたときの multipath transfer のスループットを示す．二つの表を比較すると path-1 対 path-2 の帯域の比率に関係なく multipath

transfer のスループットは改善することがわかる．コンテンツ転送におけるマルチパス転送の効果は明らかである．7. 3 スケーラビリティZINK は経路集約な locator-based の経路制御を行うため，

必要な経路情報量は今日のインターネットと同程度といえる．今日の IPv4 インターネットにおける BGP fullroute は 507,100

経路 (2014 年 9 月に AS2500 から計測) ある．これは 1× 109

個のアドレスを含む IPv4 のアドレス空間から経路集約して

— 7 —

表 2 Single path transfer

でのスループットpath-1 Throughput

100 Mbps 86.76 Mbps

表 3 Multipath transfer

でのスループットpath-1, path-2 Throughput

100, 100 Mbps 165.02 Mbps

100, 50 Mbps 129.57 Mbps

100, 10 Mbps 95.26 Mbps

いった結果である．対して，name-based routing ではインターネットにあるコ

ンテンツの数だけの経路情報を扱う必要がある．今日の Web

において Google 検索エンジンが保有する Index には 1× 1012

個 [25] のユニークな URL のが含まれると言われる．ICN における経路情報量は 1× 1012 以上のオーダを持つと考えられる．DONA や PURSUIT の名前空間は flat な構造をとるので，経路情報の集約は不可能である．従って，DONA の Resolution

Handler や PURSUIT の rendezvous を構成する DHT ノード群は 1×1012 以上の経路数を扱うこととなる．NDN の場合，コンテンツ名の階層構造に従って経路を集約することが可能である．しかし，NDN での経路情報の集約効率コンテンツの分散の仕方に依存したものである．[26] は NDN のコア・ルータは 2.5× 1010 経路の情報を保持する必要があると述べる．これは現在のインターネットの IPv4 fullroute を遙かに超えるオーダであり，NDN がインターネット規模でスケールしないことを示す．

8. 結 論

本稿では narrow-waist layer で実現される ICN の既存提案が抱える問題点を指摘し，それらを解決するために階層がｋたアーキテクチャに基づく ICN である ZINK を提案する．ZINK

は name-based routing に起因するスケーラビリティの問題，コンテンツ転送時の narrow-waist layer での輻輳制御の必要性，マルチパスを用いた効率的なコンテンツ転送の実現困難，高速ハンドオーバの実現困難といった問題を解決する．本稿では ZINK のプロトタイプを IPv6 スタック上で実装し

て基本性能を評価した．その結果，ZINK でのコンテンツ探索時間は実用的な範囲でありコンテンツ転送はマルチパスを利用することで効率的に行えることがわかった．

文 献[1] T. Koponen, M. Chawla, B. G. Chun, A. Ermolinskiy, K. H.

Kim, S. Shenker, and I. Stoica. A Data-oriented (and be-

yond) Network Architecture. In Proc. of SIGCOMM 2007,

pp. 181–192, 2007.

[2] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass,

N. H. Briggs, and R. L. Braynard. Networking Named Con-

tent. In Proc. of CoNEXT ’09, pp. 1–12, 2009.

[3] N. Fotiou, P. Nikander, D. Trossen, and G.C. Polyzos. De-

veloping Information Networking Further: From PSIRP to

PURSUIT. In Broadband Commu., Networks, and Systems,

Vol. 66, pp. 1–13. Springer, 2012.

[4] D.R. Cheriton and M. Gritter. TRIAD: A New Next-

Generation Internet Architecture, 2000. http://citeseerx.

ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5878.

[5] 寺岡文男. A Consideration on Information Centric Network-

ing. 電子情報通信学会 ICN時限研究会キックオフワークショップ

, 2015. http://www.ieice.org/~icn/wp-content/uploads/

2015/04/ICN_kickoff_3.pdf.

[6] T. Fu, Y. Li, T. Lin, H. Tan, H. Tang, and S. Ci. An Ef-

fective Congestion Control Scheme in Content-Centric Net-

working. In Proc. of PDCAT ’12, pp. 245–248, 2012.

[7] N. Rozhnova and S. Fdida. An Effective hop-by-hop Inter-

est Shaping Mechanism for CCN Communications. In Proc.

of INFOCOM WKSHPS ’12, pp. 322–327, 2012.

[8] M. Ide, K. Kaneko, and F. Teraoka. Validation of Session

Layer Protocols and API in ZNA. In Proc. of AINTECH

’12, pp. 77–84, 2012.

[9] S. Kanemaru and F. Teraoka. ZNP: A Network Layer Pro-

tocol Based on ID/locator Split Considering Practical Op-

eration. In Proc. of ICC ’11, pp. 1–6, 2011.

[10] S. Kanemaru, K. Yonemura, and F. Teraoka. ZNP: A New

Generation Network Layer Protocol Based on ID/Locator

Split Considering Practical Operation. IEICE Trans. on

Commu., Vol. E96-B, No. 3, pp. 764–777, 2013.

[11] K. Yonemura, K. Kaneko, and F. Teraoka. CLINEX: An

Inter-node Cross-Layer Cooperation Architecture to Adapt

to Dynamically Changing Network Situation. In Proc. of

COMPSAC ’13, pp. 33–42, 2013.

[12] Y. Rao, H. Zhou, D. Gao, H. Luo, and Y. Liu. Proac-

tive Caching for Enhancing User-Side Mobility Support in

Named Data Networking. In Proc. of 2013 7th Int’l Conf.

on IMIS, pp. 37–42, 2013.

[13] N. Fotiou, G.F. Marias, and G.C. Polyzos. Access Control

Enforcement Delegation for Information-centric Networking

Architectures. In Proc. of SIGCOMM Workshop on ICN

’12, pp. 85–90, 2012.

[14] S. Ben Ayed and F. Teraoka. Collaborative Access Con-

trol for Multi-Domain Cloud Computing. IEICE Trans. on

Info. and Sys., Vol. E95-D, No. 10, pp. 2401–2414, 2012.

[15] D. Mazieres, M. Kaminsky, M.F. Kaashoek, and E. Witchel.

Separating Key Management from File System Security. In

Proc. of SOSP ’99, pp. 124–139, 1999.

[16] R. Moskowitz and P. Nikander. Host Identity Protocol Ar-

chitecture. RFC 4423, IETF, 2006.

[17] A. Ghodsi, T. Koponen, J. Rajahalme, P. Sarolahti, and

S. Shenker. Naming in Content-oriented Architectures. In

Proc. of SIGCOMM Workshop on ICN ’11, pp. 1–6, 2011.

[18] D-6.1 First NetInf Architecture Description. http://www.

4ward-project.eu/index.php?s=file_download&id=39.

[19] H. Liu, X. De Foy, and D. Zhang. A Multi-level DHT Rout-

ing Framework with Aggregation. In Proc. of SIGCOMM

Workshop on ICN ’12, pp. 43 – 48, 2012.

[20] S. Ladiwala, R. Ramaswamy, and T. Wolf. Transparent

TCP acceleration. Computer Communications, Vol. 32,

No. 4, pp. 691–702, 2009.

[21] S. Barr, C. Paasch, and O. Bonaventure. MultiPath TCP:

From Theory to Practice. In Proc. of the IFIP Networking,

2011.

[22] M. Ishiyama, M. Kunishi, K. Uehara, H. Esaki, and

F. Teraoka. LINA: A New Approach to Mobility Support

in Wide Area Networks. IEICE Trans. on Commu., Vol.

E84-B, No. 8, pp. 2076–2086, 2001.

[23] WWW Content Statistical Survey Report (in Japanese).

http://www.soumu.go.jp/iicp/chousakenkyu/data/research/

survey/telecom/2006/2006-2-01.pdf.

[24] Statistics / Japan Registry Services Co., Ltd. http://jprs.

co.jp/en/stat/.

[25] M.F. Bari, S. Chowdhury, R. Ahmed, R. Boutaba, and

B. Mathieu. A Survey of Naming and Routing in

Information-centric Networks. IEEE Communications

Magazine, Vol. 50, No. 12, pp. 44–53, 2012.

[26] D. Perino and M. Varvello. A Reality Check for Content

Centric Networking. In Proc. of SIGCOMM Workshop on

ICN ’11, pp. 44–49, 2011.

— 8 —