ZNPにおける実運用を考慮したID/Locatorマッピング機能の提案

ZNP における実運用を考慮した ID/Locator マッピング機能の提案
A Proposal of Mapping System for ZNP Considering Practical Operation
米村和真 †
金丸翔 †
寺岡文男 ‡
† 慶應義塾大学大学院理工学研究科
‡ 慶應義塾大学理工学部
E-mail: † {yonex, satsuma}@tera.ics.keio.ac.jp
‡ [email protected]
Abstract: モビリティやマルチホーム，ルーティングスケーラビリティ，セキュリティをサポートするため，ID/Locator
Split アプローチに基づいたアーキテクチャがこれまでに多数提案されてきた．しかし，そのうちのどれも将来のイ
ンターネットにおける実運用のための要求を満足できていない．そこで提案されたのが ZNP (Z Network Protocol)
である．本論文では，ZNP 上で動作する ID/Locator マッピングシステムの詳細設計について述べる．実運用を考
慮するにあたって重要な点は，異種ネットワーク層プロトコルのサポート，マッピングシステムのスケーラビリ
ティ，マッピング情報の管理が独立していること，Locator 情報が管理ドメインから流出しないことである．これ
らの要求は，ZNP における “Internetworking with a Common ID Space” と呼ばれる特徴および，本論文の提案する
マッピングシステムによって満足されると考える．また，マッピングシステムを操作するプロトコルとして ZCMP
(Z Control Message Protocol) を設計し，一部機能を実装した．そして，実装した機能については簡単な動作確認を
行った．現在，ZNP/ZCMP は引き続き実装中である．
keyword: New Generation Network, Network Layer, ID/Locator Split
1 はじめに
本論文は，ZNP におけるマッピングシステムの詳細設
計について述べる．マッピングシステムは Name を ID
インターネットの誕生から 40 年近くが経過してい
にマッピングする NMS (Name Mapping System) と，ID
る．その間，設計当初には想定されていなかった様々な
を Locator にマッピングする IMS (ID Mapping System)
要求に対応するため，インターネットには様々な機能
からなる．NMS では NMA (Name Mapping Agent) が
拡張が繰り返し行われてきた．しかし，それによって
木を構成し，IMS では IMA (ID Mapping Agent) が木
インターネットは従来の階層化構造を壊され複雑なも
を構成する．また，マッピングシステムを制御するプ
のとなり，現在はインターネットの設計を一から見直
ロトコルとして ZCMP (Z Control Message Protocol) を
す “Clean Slate” による再設計の気運が世界中で高まっ
設計し，一部の機能を実装した．
ている．
本提案の特徴は，実運用を考慮して以下の 4 つの要
現在のインターネットでは，ネットワーク層 (L3) プ
求条件を満たすようにマッピングシステムを設計した
ロトコルとして主に IP (Internet Protocol) が使用され
ことである．(1) 異種 L3 プロトコルをサポートするこ
ており，IP アドレスがノード識別子 (ID) と位置指示子
と，(2) ID/Locator マッピングシステムがスケーラブル
(Locator) の役割を兼ねている．IP アドレスの持つこの
二面性がモビリティやマルチホームの実現を困難にし
ている．また，多様なノードが接続するようになると
予想される将来のインターネットでは，IP 以外の L3
プロトコルを取り入れる必要性が高まることも考えら
れる．
以上のような背景を踏まえ，我々は将来のインター
ネットにおける 6 階層アーキテクチャZNA (Z Network
Architecture) を提案している [1]．その中で，L3 プロ
トコルとしては，ID/Locator 分離に基づく ZNP (Z Network Protocol) を提案している [2]．
であること，(3) マッピング情報の管理が独立している
こと，(4) Locator 情報がドメインを越えて管理されな
いこと．この 4 つの要求条件を挙げる理由は以下のと
おりである．将来のインターネットでは，ZNP のよう
な L3 プロトコルや IPv4, IPv6, その他の L3 プロトコ
ルが混在すると考えられるため，(1) は満足されるべき
である．(2) は，ID/Locator split に基づくプロトコルは
マッピングシステムを持たねばならず，その上大量の
ノードをサポートするためにはマッピングシステムに
スケーラビリティが求められることを示している．(3)
は，ノードのマッピング情報はノードが所属するドメ
1
イン (ホームドメイン) 内で管理されなければならない
ことを意味している．特に，一時的にノードが外部ド
メインに接続したときのマッピング情報の認証に関し
4
5
て，もしホームドメインではなく外部ドメインがマッ
3
ピング情報を管理するなら，マッピング情報の認証が
6
難しくなってしまう．(4) は，管理ドメイン内のトポロ
2
ジ情報が外部に漏えいすることを防ぐため，あるドメ
1
インで管理されている Locator 情報は，外部ドメイン
のマッピングシステムに登録されてはならないことを
意味する．
図 1: Node Identity Architecture の概要
FOO.COM
2 関連研究
Realm A
X.FOO.COM
ID/Locator Split の概念に基づくアーキテクチャにつ
いての関連研究を挙げる．
Y.FOO.COM
Realm B
Realm C
RZBS
2.1
Node Identity Architecture
RZBS
RZBS
Routing
Network
Node Identity Architecture[3, 4] は，ノードが各自で
生成する公開鍵をそのノードの Node Identifier (NID)
として，エンド間でノードを認識する．Node Identity
Architecture では，各ローカルドメイン (LD) ごとに異な
るネットワーク層プロトコルを使用できるのが特徴であ
る．各 LD 内の通信は，それぞれの LD で使用されるネ
ットワーク層プロトコルで動作する．異なる LD 間の通
信では，NID の固定長のハッシュ値である Node Identity
Forwarding Tag (NIFT) と，Routing Hint を用いてルー
ティングを実現する．通常，この Routing Hint には，
各ノードが接続している LD において，直接グローバ
ルインターネットに接続する Core Node Identity Router
(CNR) の NIFT が使用される．各ノードは，NIFT を上
位の Node Identity Router (NR) へと登録する．すると
各 NR は CNR へ到達するまで自動的に上位の NR へ
と登録情報を伝え，LD 内で NIFT によるルーティング
が可能となる．
Node Identity Architecture では，各 LD で用いられ
る NID を，異なる LD 間の通信では NIFT に置き換え
て通信をするため，各 LD 内ごとに異なるルーティン
グやアドレッシングが可能であり，グローバルなネッ
トワークで単一なアドレス空間を必要としない．従っ
て，さまざまなネットワークが接続可能であり，現在
の IPv4 ネットワークなども 1 つの LD として捉えるこ
とも可能である．
zone
<HUI>
BOB.X.FOO.COM
zone
<HUI>
ALICE.Y.FOO.COM
論理的リンク
シグナリングリンク
物理的リンク
図 2: MILSA の概要
しかし，各 LD で接続するノードの NIFT を上位の
NR が保持し，上位の NR になるほどその情報量が増
える．また，CNR が LD 間通信のすべてのパケットの
Routing Hint から Locator への問い合わせをしなけれ
ばならない．このため，各 LD に接続するノード数に
制約がありスケーラビリティに問題がある．
2.2
MILSA
MILSA (A Mobility and Multihoming Supporting
Identifier Locator Split Architecture for Naming in the
Next Generation Internet)[5] のネットワーク構成を図
2 に示す．
MILSA では，ドメインの論理的関係を Realm，物
理的関係を Zone として，Realm-Zone Bridging Server
(RZBS) がこれらの関連付けを管理する．データ転送は
2
Unified Control Network
Zone 内で行われ，制御メッセージのやり取りは RZBS
間で行われる．すなわち，シグナリングとデータの分
離が実現されており，柔軟な設計が可能である．また，
Zone と Realm はともに階層構造をとり，それらを管理
する RZBS も階層構造となる．これらの階層構造によ
り，スケーラビリティが確保されている．また，MILSA
では，ID として Hierarchical URI-like Identifier (HUI)
を使用し，Locator として IP アドレスを使用する．
MILSA は，モビリティとマルチホームをサポート
する．モビリティについては，ノードは移動先で IDLocator マッピングを RZBS に登録するだけでよく，マ
Domain Name Registry (DNR)
ID Registry (IDR)
Global Transit Network
HNR
gateway
host
ルチホームについても同様に追加の ID-Locator マッピ
Edge Network
gateway
HNR
host
Edge Network
ングを最寄りの RZBS に登録するだけである．
しかし，MILSA では Locator として IP アドレスを
図 3: HIMALIS のネットワーク構成
使用することしか想定していないため，異種 L3 プロ
トコルの混在には対応できない．また，ヘッダ構造が
ロトコルを使用可能である点も，将来のインターネッ
複雑であったり，HUI が可変長である点がシステムに
トへの要件を満たしている．
とって扱いにくいと考えられる．
しかし，ノードが Edge Network をまたいで移動し
た際のシグナリングで，Home Network の Gateway が
2.3
HIMALIS
持つマッピング情報を Foreign Network の Gateway に
渡す必要がある．このようにマッピング情報がドメイ
HIMALIS (Heterogeneity Inclusion and Mobility
Adaptation through Locator ID Separation in New Generation Network)[6] のネットワーク構成を図 3 に示す．
HIMALIS のネットワークは，Global Transit Network,
Edge Network, Unified Logical Control Network の 3 つ
で構成される．Global Transit Network はプロバイダバッ
クボーンネットワークの集合であり，Edge Network は
動的ホストが構成するネットワークである．各ドメイ
ンごとに 1 つの Host Name Registry (HNR) が置かれ，
自身が管理する Edge Network 内のホスト名，ID, Locator のマッピングなどの動的情報を管理する．Unified
Logical Control Network は 2 つのレジストリから構成
され，Domain Name Registry (DNR) はドメイン名とそ
のドメインを管理する HNR 情報のマッピングを管理
し，ID Registry (IDR) は全てのホストの ID と Locator
のマッピングを管理する．
HIMALIS では，Unified Logical Control Network を
構成する IDR, DNR, HNR によってマッピング情報が分
散管理されるためスケーラビリティは優れていると考
えられる．また同様にして，マッピング情報の独立管
理も達成されている．ゲートウェイにおけるプロトコ
ル変換機能によって Edge Network ごとに異なる L3 プ
ンを越えて管理されることは好ましくない．
ZNP におけるマッピングシステム
の提案
3
本章では，関連研究を踏まえて提案された ZNP と，
本研究の提案方式であるマッピングシステムについて
述べる．
3.1
3.1.1
ZNP の特徴
ネットワーク構成
関連研究では，ネットワークが多段の階層構造をと
ることやランダムな構造をとることが考えられていた．
しかし，現状のネットワークの運用や将来のインター
ネットでの実運用を考えると，ネットワーク構成が最
終的には次のような特徴を持つであろうと想定できる．
• 共通の Locator (GU-Loc: Global Universal Locator)
を使用する Global Universal Network (GU-Net) が
新世代ネットワークのバックボーンとなる．
3
2 bytes
Global Universal Network
(backbone network)
router
Global Universal
Networks
(edge networks)
10 bytes
Node Identifier
- Regional Internet Registry number
- National Internet Registry number
- etc.
locator conversion gateway protocol conversion gateway
Private Universal
Local Networks
Networks
(edge networks)
(edge networks)
Universal Locator Space
4 bytes
Registry Organization
16 bytes
Identifier
Identifier
図 5: ZNP で用いられる ID のフォーマット
Local Locator Space
図 4: ZNP のネットワーク構成
• ID を指定すれば，相手が接続するネットワーク
に関わらず，相手を一意に指定できるようにする．
そのため ID は globally unique である必要がある．
• GU-Loc を使用するエッジネットワークが GU-Net
に接続する．これは現在のインターネットにおい
• 将来も現在と同じように公的な registry が地域ご
とに存在すると考えられる．
て NAT を介さずにバックボーンに接続している
組織に相当する．
• 各組織で独立して ID の割り当てができるように，
ID には階層構造を持たせるべきである．
• Global Universal Network と同じ L3 プロトコル
を使用するが，Locator (PU-Loc: Private Universal Locator) のスコープはネットワーク内に限ら
れる Private Universal Network (PU-Net) がバック
ボーンに接続する．GU-Net と PU-Net は Locator
conversion router によって接続される．これは現
在のインターネットにおいて NAT を介してバッ
クボーンに接続している組織に相当する．
• さらに後述するように，ID の値からそれを管理す
る IMA を見つける必要もある．そのためにも階
層構造は必要となる．
また，以下の想定に基づいて各領域サイズを割り当
てた．
• registry の識別のためには 2 バイトあれば十分で
あろう．
• 異種 L3 プロトコルを使用する Local Network (LNet) がバックボーンに接続する．GU-Net と L-Net
は Protocol conversion gateway によって接続され
る．IPv4, IPv6 や機器特有の L3 プロトコルは今
後も局地的には残ると考えられる．
• 各 registry が管轄する地域に存在する組織の識別
には 4 バイトあれば充分であろう．
• 各組織に属するノードの識別には 10 バイトあれ
ば十分であろう．
ZNP のネットワーク構成はこれらの特徴を考慮したも
のであり，その様子は図 4 のようになる．
それぞれのフィールドについて，Node Identifier は例
えば大学などの組織から個別のノードに割り当てら
3.1.2
Internetworking with a common ID space
れ，Organization Identifier は JPNIC や APNIC などの
registry から割り当てられ，Registry Identifier は，現在
のインターネットにおける ICANN のような権威から
割り当てられることを想定している．
ZNP では read ID (rID) と pseudo ID (pID) という 2
種類の ID を導入している．rID をパケットヘッダに含
めると，どのノード同士が通信しているかや，ノード
の移動軌跡が盗聴者に分かってしまう．そこで，通信
セッションごとや移動ごとに変化する pID を導入し，
rID の代わりに pID をヘッダに含めることで，匿名性
ZNP では，ノード名として現在のインターネットに
おける FQDN (Fully Qualified Domain Name) を，ノー
ド ID として 128 bits の ID 空間を導入している．特
別な仕組みを導入することなく，IP では実現が困難で
あったモビリティやマルチホームなどのサポートを達
成できる．また，ID の表記法は IPv6 address の表記法
に準拠する．
ID のフォーマットを図 5 に示す．ID がこのような
構造をとる理由は以下のとおりである．
4
を高める．pID の使用方法に関する詳細は今後の研究
(""+&./0!
課題とする．
ZNP では Locator は 128bit とし，ネットワークトポ
ロジーにしたがって集約可能になるように階層的に割
り当てられることを想定している，階層的な Locator
割り当て法としては，HANA[7] などが考えられる．表
記法は IPv6 address の表記法に準拠する．
3.2
3/0!
2&2&2!
1'2! ./0!
3/0!
;<,+21'=>?5.,+@!
./0!
3/0!
2&2&2!
2&2&2!
マッピングシステムの提案
08.39!
:8.39!
'<,+21'2=8?5.,+@!
./0!
45./0!
2&2&2!
ZNP では，Name，ID，Locator のマッピングが必要
6!"7$!&&
3/0! -'$#,&
453/0! !"#$!%&
'()*$+,&
2&2&2!
-'$#,!
になる．これらのマッピング管理を実現するにあた
り，Name Mapping Agent (NMA) と ID Mapping Agent
図 6: ZNP におけるマッピングエージェントの階層構造
(IMA) という 2 種類のマッピングエージェントを導入
した．また，Gateway 上で動作し，マッピング情報の
キャッシュを管理する mapping cache を導入した．
からず，ノードが ID to Locator mapping を IMA に登
録する際にどのようにして認証するかが問題になる，
このような観点から，NMS や IMS は木構造をとる．
3.2.1
スケーラブルなマッピングシステム
あるドメインの NMA や IMA が管理するマッピン
グ情報に変更が加えられた場合，それによって他のド
NMA では Name と rID のマッピングを管理し，IMA
では rID と Locator のマッピングを管理する．静的な
マッピングは NMA が管理し，動的なマッピングは IMA
が管理することで，マッピングの性質に応じた管理手
法やマッピングエージェントの配置法を選択でき，管
理しやすくしている．さらに，マッピングエージェン
トを図 6 のように階層構造化することによって，それ
ぞれが管理するドメイン内の情報のみを保持すれば良
いことになり，スケーラビリティを確保できる．
NMA は現在の DNS (Domain Name System) のよう
に Root NMA を根とする木構造をとる．IMA は ID
フォーマットの階層構造に従って同じように木構造を
とる．そして各 NMA は下位の NMA の Locator を保
持し，また各 NMA は同一ドメインを管理する IMA の
Locator も保持する．
メインのマッピングエージェントには変更が加わるべ
きではない．ZNP では，各ドメインごとに NMA, IMA
を配置し，マッピング管理の独立性を達成している．
また，図 6 のように PU-Net, L-Net 内にそれぞれ Local
NMA (L-NMA) を配置し，ドメイン内のマッピング情
報の更新は，そのドメイン内の NMA, IMA の持つ情
報が更新されることで完結する．
3.2.3
Locator 情報のドメイン内管理
インターネットに異種 L3 プロトコルが混在するよ
うになった場合，ドメイン内のトポロジ情報，すなわ
ち Locator 情報がドメイン外に流出することは好まし
くない．互いに異なる L3 プロトコルを使用するよう
なドメインでは，それぞれの使用する Locator を互い
に理解することができない．また，セキュリティ上の
3.2.2
マッピング管理の独立性
観点からも，ドメイン内の Locator 情報はドメイン内
でのみ使用され，ドメイン外に知られることのないほ
ある組織に属するノードのマッピング情報はその組
うがよい．
織に存在する NMA や IMA で管理されるべきである．
ZNP では，GU-Net, PU-Net, L-Net の境界に設置し
スケーラビリティの観点では，たとえば IMA の構造
た Gateway 上の mapping cache が IMA との制御メッ
は木構造ではなく DHT を利用するという方法も考え
セージのやりとりを通して適切な Locator 変換を行う
られる．しかし DHT を利用するとあるノードの ID to
ことで，ドメインをまたいで同じ Locator 情報が使用
Locator mapping をどの組織の IMA が管理するかが分
5
znp01
ラベル
rID
レコードタイプ
101:100:1::4
リソースデータ
②
IMA
(unet.jp)
Node_B.unet.jp
⑦
リソースデータ
Node_W.sub.unet.jp
rID
ホスト名
rID
pID
ホスト名
pID
NMA
ドメイン名
NMA の rID
IMA
ID
IMA の rID
LOC
ID
Locator
PTR
ID
ホスト名
unet.jp
ID - 101:100::
LOC - 2001:db8::/48
④
⑤
⑥
IMA
NMA
(sub.unet.jp) (sub.unet.jp)
表 1: レコードタイプの一覧
ラベル
③
Node_A.unet.jp
図 7: リソースレコードの一般形
レコードタイプ
①
NMA
(unet.jp)
sub.unet.jp
ID - 101:100:1::
LOC - 2001:db8:1::/64
⑨
⑧ Node_Y.sub.unet.jp
Node_X.sub.unet.jp
図 8: ネットワークの例
ここで，図 8 のようなネットワークを簡単な例に
あげて，具体的なゾーンファイルの内容を示す．まず
されることはなく，Locator 情報がドメイン外に流出す
unet.jp ドメインがあり，その下に Node A, Node B と，
sub ドメインが存在する．unet.jp は ID として 101:100::
を持ち，Locator は 2001:db8::/48 とする．sub.unet.jp
ドメイン内には Node W, Node X, Node Y が存在す
る．sub.unet.jp は ID として 101:100:1::を持ち，Locator は 2001:db8:1::/64 とする．NMA-unet.jp は Node A,
ることはない．
3.3
ゾーンファイルの設計
NMA, IMA が保持するマッピング情報を初期化する
Node B の rID と，IMA-unet.jp の rID および Locator
と，下位ドメインを管理する NMA-sub.unet.jp の rID
および Locator を保持する．この場合の NMA-unet.jp の
ゾーンファイルを図 9 に示す．IMA-unet.jp は Node A,
Node B の Locator と，下位ドメインを管理する IMAsub.unet.jp の rID および Locator を保持する．この場合
の IMA-unet.jp のゾーンファイルを図 10 に示す．さら
に，sub.unet.jp 内の NMA-sub.unet.jp, IMA-sub.unet.jp
のゾーンファイルをそれぞれ図 11, 12 に示す．
実際にゾーンファイルを参照する例として，unet.jp 内
にある Node A が sub.unet.jp 内にある Node X とデー
タ通信を開始するときのマッピング解決手順を説明す
る．(1) Node A は，Name “Node X.sub.unet.jp” を所属
ドメインの NMA-unet.jp に問い合わせる．(2) NMAunet.jp は，図 9 にある NMA レコードから sub ドメ
インを管理する NMA-sub.unet.jp の rID “101:100:1::5”
を，LOC レコードからその rID に対応する Locator “2001:db8:1::5” を見つける．(3) NMA-unet.jp は，
クエリ “Node X.sub.unet.jp” を NMA-sub.unet.jp にフ
方法として，現在の DNS サーバで広く利用されている
BIND (Berkeley Internet Name Domain) にならい，ゾー
ンファイルを設計した．ゾーンファイルは図 7 に示すよ
うに，一行ごとにマッピング情報をリソースレコード
として記述する．リソースレコードはラベル，レコー
ドタイプ，リソースデータの 3 つの要素で構成される．
レコードタイプによって，ラベルとリソースデータに
記述する内容を指定する．その対応関係を表 1 に示す．
レコードの種類は，rID, pID, NMA, IMA, LOC, PTR
の 6 種類である．rID, pID レコードでは，ノード名に対
応する ID を記述する．ひとつのノードに複数の ID が
割り当てられても構わない．NMA レコードでは，ドメ
イン名に対して，そのドメインを管理する下位の NMA
の rID を記述する．IMA レコードでは，ID に対応す
る下位の IMA の rID を記述する．LOC レコードでは，
ノードの ID, NMA の ID, IMA の ID に対応する Locator
を記述する．ひとつの ID に対して複数の Locator が割
り当てられても構わない．PTR レコードは逆引き用の
レコードで，ID に対して名前を記述する．
6
# ホスト名とホストの rID のマッピング
Node_A
rID
101:100::3
Node_B
rID
101:100::4
# ホストの rID と IMA のマッピング
101:100::
IMA
101:100::2
101:100::2
LOC
2001:db8::2
# ドメイン名と下位 NMA のマッピング
sub.unet.jp. NMA
101:100:1::5
101:100:1::5 LOC
2001:db8:1::5
# ホストの rID と Locator のマッピング
101:100:1::7 LOC
2001:db8:1::7
101:100:1::8 LOC
2001:db8:1::8
101:100:1::9 LOC
2001:db8:1::9
図 12: IMA-sub.unet.jp のゾーンファイル
ォワードする．(4) NMA-sub.unet.jp は，図 11 にあ
る rID レコードから Node X の rID “101:100:1::8”
を，IMA レコードからその rID に対応する IMA-
sub.unet.jp の rID “101:100:1::6” を，LOC レコードか
図 9: NMA-unet.jp のゾーンファイル
ら IMA-sub.unet.jp の Locator “2001:db8:1:6” を見つけ
る．(5) NMA-sub.unet.jp は，IMA-sub.unet.jp の情報を
NMA-unet.jp に返送する．(6) NMA-unet.jp は，IMAsub.unet.jp の情報を Node A に返送する．(7) Node A
は，rID “101:100:1::8” を IMA-sub.unet.jp に問い合わせ
る．(8) IMA-sub.unet.jp は，図 12 にある LOC レコード
# ホストの rID と Locator のマッピング
から Node X の Locator “2001:db8:1::9” を見つける．(9)
101:100::3
LOC
2001:db8::3
IMA-sub.unet.jp は，Node X の Locator を Node A に返
101:100::4
LOC
2001:db8::4
送する (10) Node A は，Node X の rID “101:100:1::8”
# ドメインのプレフィクスと下位 IMA のマッピン
と LOC “2001:db8:1:::9” を取得したので，Node X と
グ
データ通信を開始することができる．
101:100:1:: IMA
101:100:1::6
101:100:1::6 LOC
2001:db8:1::6
ZNP におけるマッピングシステム
の動作
4
図 10: IMA-unet.jp のゾーンファイル
本章では，マッピングシステムの動作の様子とシグ
ナリングメッセージについて説明する．
# ホスト名とホストの rID のマッピング
Node_W
rID
101:100:1::7
Node_X
rID
101:100:1::8
Node_Y
rID
101:100:1::9
# ホストの rID と IMA のマッピング
101:100:1::
IMA
101:100:1::6
101:100:1::6 LOC
2001:db8:1::6
4.1
動作例
本節では，2 つのエンドノードがどちらも GU-Net
内にある場合と，GU-Net 内と PU-Net 内に別れている
場合のシグナリングプロセスについて説明する．
4.1.1
GU-Net 内での通信
この例では，GU-Net
図 11: NMA-sub.unet.jp のゾーンファイル
内にあるノード
X
(Node X.unet1.jp) が同じく GU-Net 内にある
ノード Y (Node Y.unet2.jp) と通信を開始する場合
7
を考える．その概要を図 13 に示す．動作は次のよう
;&'$
(LK%;F+$
になる．(0) 前もって両ノードはそれぞれの rID と
Locator のマッピングを自身の属するドメインの IMA
に登録しておく．(1) ノード X が，ノード Y の名前
(Node Y.unet2.jp) を格納した Request メッセージ
%&'$ %&'$
;&'$
('K%;F+$ !""#$%&'$ ()*+$ (,-.#70)*+$
//! /<!
9!
;&'$
(,-.#70)*+$
を NMA-unet1.jp に送信する．(2)-(4) NMA-unet1.jp
7!
/7!
MN$/4! <!
が，ノード Y の情報を持っていない場合は，Root
4!
%&'$
(,-.#/0)*+$
;&'$
(,-.#/0)*+$
O!
<!
5!
/! 8!
:!
NMA から NMA の階層を辿り，ノード Y の rID を
NMA-unet2.jp から得る．(5) NMA-unet1.jp が，ノー
ド Y の rID を ID Reply メッセージに格納してノード
X に送信する．この ID Reply メッセージはノード Y
の rID と IMA-unet2.jp の Locator を持つ．(6) ノード
X が，ノード Y の rID を ID Request メッセージに格
納して IMA-unet2.jp に送信し，ノード Y の Locator
を得る．(7) ノード X が，データパケットをノード
Y に送信する．(8) データパケットを受信すると，
ノード Y は ZNP ヘッダから得たノード X の rID を
Locator Request メッセージに格納して IMA-unet2.jp
に送信する．これによって ZNP ヘッダにあるソース
ID が信頼に値するものかどうか確認できる．(9)-(12)
IMA-unet2.jp が，ノード X の情報を持っていない場合
は，Root NMA から IMA の階層を辿り，ノード X の
Locator を IMA-unet1.jp から得る．(13) IMA-unet2.jp
が，ノード X の Locator を Locator Reply メッセージ
に格納してノード Y に送信する．(14) ノード Y が，
データパケットをノード X に送信する．
以上が GU-Net 内でのシグナリングプロセスの概要
になるが，その間 IMA や NMA, 両ノードはマッピン
グ情報をキャッシュに保存するため，これ以降のデー
タパケットの送信についてはシグナリングプロセスを
省略することが出来る．また，このシグナリングの後，
さらにエンドノード間で pID を決定するための通信プ
ロセスを踏み，データパケットの送受信に関して pID
を使用することで，盗聴に対して匿名性を確保できる．
%"1.260,-.#70)*$
/5!
%"1.230,-.#/0)*$
;=$!.>,.?#@!.*AB$
C"D$!.>,.?#@!.*AB$
=E#E$F"GG,-HDEI"-$
C"D$!.J$!.>,.?#@!.*AB!
図 13: GU-Net 内での ID/Locator 解決
X がノード Y の rID を得る．(2) ノード X が，ノー
ド Y の rID を Locator Request メッセージに格納し
て IMA-pnet.jp に送信し，gw の GU-Loc を得る．(3)
ノード X が，データパケットを gw に送信する．(4)
gw がデータパケットを受信したときにノード Y の
rID と Locator のマッピングのキャッシュがない場合，
gw 上で動作する maping cache がノード Y の rID を
Locator Request メッセージに格納して L-IMA-pnet.jp
に送信し，ノード Y の PU-Loc を得る．(5) gw が図
14 に示すように ZNP ヘッダの Locator フィールドを
書き換え，ノード Y にパケットを送信する．(6) デー
タパケットを受信すると，ノード Y は ZNP ヘッダか
ら得たノード X の rID を Locator Request メッセージ
に格納して L-IMA-pnet.jp に送信する．L-IMA-pnet.jp
は，ノード X が自身の管理するドメインにないため
gw の PU-Loc を Locator Reply メッセージに格納し
て送信する．(7) ノード Y が，データパケットを gw
に送信する．(8) gw がデータパケットを受信したと
きにノード X のマッピングのキャッシュがない場合，
mapping cache がノード X の rID を Locator Request
メッセージに格納して IMA-unet.jp に送信し，ノード
X の GU-Loc を得る．(9) gw が ZNP ヘッダの Locator
フィールドを書き換え，ノード X にパケットを送信
する．
4.1.2
GU-Net – PU-Net 間での通信
この例では，GU-Net
以上が GU-Net – PU-Net 間でのシグナリングプロセ
スの概要である．このように，gw で Locator の書き換
内にあるノード
X
(Node X.unet.jp) が PU-Net 内にあるノード Y
(Node Y.pnet.jp) と通信を開始する場合を考える．
これは現在のインターネットにおける NAT を介した
通信にあたる．その概要を図 14 に示す．動作は次の
ようになる．(1) 4.1.1 節の手順と同様にして，ノード
えを行うことによって，PU-Net 内にあるノード Y の
Locator (PU-Loc Node Y) は他ドメインに流出するこ
とがない．
8
IJK=!()$%,'()*+,-L!
IMK=!()$%&'()*+,-L!
>"#$
%&'()*+,-$
<=>"#$
%,'()*+,-$
0
ZNP Header
>"#$
%,'()*+,-$
7
Message
Type
11
Flag
ZCMP Header
X!
Y!
D!
G!
!./(0?*,'()*+,$
2.34).5$
3.'6(578.'$
94)(:4;$
H!
図 15: ZCMP メッセージヘッダ
@!
B!
ZNP Header
N!J$O(4/(5$%,5.3*H-!
P53$<.3$Q$JK=<.309:!
P53$<.3$Q$MK=<.30!./(01!
R7)$<.3$Q$JK=<.30!./(0?!
R7)$<.3$Q$MK=<.309:!
P53$>R$$$$Q$>R0!./(01!
P53$>R$$$$Q$>R0!./(01!
R7)$>R$$$Q$$>R0!./(0?!
R7)$>R$$$Q$$>R0!./(0?!
ZCMP Header
0
15
Query Type
ID Request
31
Length
Query Data (target’s Name)
図 16: ID Request メッセージ
図 14: GU-Net – PU-Net 間での ID/Locator 解決
4.2
31
Number of
Answers
!./(01*&'()*+,$
>R$S(T&(7)US(,2;$
<.3$S(T&(7)US(,2;$
R4)4$V.EE&'834W.'$
N!J$O(4/(5$%,5.3*D-!
!"#$
%&'()*+,-$
A!
23
Number of
Queries
Sequence Number
E4,,8'90343F($
C!
15
Code
表す．Number of Queries/Answers フィールドは，ヘッ
ZCMP メッセージ
ダの後に付加される Query/Answer フィールドの個数
Z Control Message Protocol (ZCMP) は，マッピング
システムを制御するためのプロトコルである．ZCMP
が定義するメッセージは，ID Request/Reply メッセー
ジ，Locator Request/Reply メッセージ，Locator Registration Request/Reply メッセージ，Communication Request/Reply メッセージの 8 種類である．ID Request メッ
セージは，ノード名に対応する rID を要求するメッセー
ジであり，ID Reply メッセージはそれに対する応答で
ある．これらは NMA とエンドノードの間や NMA 同士
でやり取りされる．Locator Request メッセージは，rID
もしくは pID に対応する Locator を要求するメッセー
ジであり，Locator Reply メッセージはそれに対する応
答である．これらは Root NMA, IMA, mapping cache
とエンドノードの間でやり取りされる．Locator Registration Request メッセージは，rID もしくは pID に
対応する Locator の登録を要求するメッセージであり，
Locator Registration Reply はそれに対する応答である．
これらは IMA とエンドノードの間でやり取りされる．
Communication Request/Reply メッセージは pID の決定
に用いられるメッセージであり，これらはエンドノー
ド間でやり取りされる．
ZCMP メッセージのヘッダを 64 bits の固定長で図 15
のように定義した．Message Type フィールドは，ZCMP
メッセージの種類を表す．Flag フィールドは，mapping cache の動作の制御に使用される．Code フィー
を表す．Sequence Number フィールドは，通信を行う
エンドノードの識別に用いられる．
ZCMP メッセージヘッダの Message Type フィー
ルドには，表 2 で示す値を格納し，ZCMP メッセー
ジの種類を指定する．これによってヘッダの後に続
く Query/Answer フィールドの構成が決まる．ID Request/Reply Message のメッセージフォーマットを図 16,
17 に示す．このように，Query/Answer フィールドは
さらに Type, Length, Data の 3 つのフィールドから構
成される．Type では表 3 で示す値を指定し，Length
では次の Data のバイト数を指定，Data には問い合わ
せる ID やノード名の文字列，もしくはそれに対する
回答である ID や Locator を格納する．図 17 のように
ID Reply メッセージなどは Answer フィールドを複数
持つ場合がある．例えば，4.1.1 節の手順 (5) などの場
合，問い合わせノード名に対応する ID に加えて次に
Locator Request メッセージを送信するべき IMA の ID
0
ZNP Header
31
Query (Name)
Answer (target’s rID)
0
15
Answer Type
31
Length
ZCMP Header
ID Reply
Answer (IMA’s rID)
Answer Data
Answer (IMA’s Loc)
Life Time
図 17: ID Reply メッセージ
ルドは Reply メッセージで使用され，エラーの内容を
9
0@A+9:%
B3A+9:C%
表 2: ZCMP ヘッダにおける Message Type の値
Value
Message Type
0x01
ZCMP ID REQUEST
0x02
ZCMP ID REPLY
0x03
ZCMP LOC REQUEST
0x04
ZCMP LOC REPLY
0x05
ZCMP LOC REG REQUEST
0x06
ZCMP LOC REG REPLY
0x07
ZCMP COM REQUEST
0x08
ZCMP COM REPLY
0x10
ZCMP ECHO REQUEST
0x11
ZCMP ECHO REPLY
DE@A+9:F!
"#''(!=28#8>9!
!"#$%
("#$!
=#:9G#H!
'&!'$%
?&!'$!
&!'$!
')(!*$!
)(!*$!
)(!*$!
=#:9G#H%.%"#''(!=28#8>9!
+,-%.%/,-!
012345-3%678*9:!
012/+;<%678*9:!
図 18: 実装モジュール
linkd, znpd は ZNP の実装であり，全ての ZNP ノー
ドに必要なモジュールである．linkd はリンク層の機
能をユーザ空間でエミュレートする役割を担う．znpd
表 3: 各 Query/Answer フィールドにおける Query
は ZNP を取り扱うモジュールで，ルーティングとフォ
Type/Answer Type の値
ワーディングの機能を持つ．gw 上では 2 種類の znpd
Value
Type
0x01
ZCMP TYPE NAME
0x02
ZCMP TYPE RID
0x03
ZCMP TYPE NMA
0x04
ZCMP TYPE IMA
0x05
ZCMP TYPE LOC
0x06
ZCMP TYPE PTR
が動作し，PF LOCAL ソケットを使用して通信を行い，
ZNP ヘッダの Locator 書き換え等をサポートする．こ
れらのモジュールは将来的にカーネル内に実装される
予定である．
nmad, imad, mapping cache は本研究での実装であ
る．nmad/imad は NMA や IMA 上でユーザ空間におい
て ZCMP を取り扱うデーモンである．nmad は NMA の
機能を提供し，imad は IMA の機能を提供する．mapping cache は gw 上で ZCMP を取り扱い，マッピング情
報をキャッシュする役割を担う．これらは PF LOCAL
ソケットを使用して znpd とパケットをやり取りする．
と Locator の情報も返送する必要がある．
5 実装
5.2
本章では，ZNP と ZCMP の実装の概要と現状を述
nmad, imad では，マッピング情報の各エントリを
リスト構造で管理している．NMA においてノード名
と rID のマッピングを保持するリストの例を図 19 に，
IMA においてノード ID と Locator のマッピングを保
持するリストの例を図 20 に示す．ID Request メッセー
ジや Locator Request メッセージを受信すると，ZCMP
メッセージから Query Data を抽出し，これらのリスト
のポインタを辿ってマッピングを検索する．また，ひと
つのノード名に対して複数の ID がマッピングされるこ
とや，ひとつの ID に対して複数の Locator がマッピン
グされることが可能であるため，各エントリがさらに
べる．実装は現在継続中である．
5.1
マッピング情報の保持
実装モジュール
本研究では，ZNP 上で動作するマッピングエージェ
ント NMA (nmad)，IMA (imad) と gw 上で動作する
マッピングキャッシュ (mapping cache) の実装をユーザ
空間上で行っている．実装モジュールの関係を図 18 に
示す．また，将来的にはカーネル上に実装する予定で
ある．
10
name_id_list_head
name_id_list
name_id_list
Node_X
Node_Y
name_id_list
Node_W
id_list_head
id_list_head
id_list_head
id_list
id_list
id_list
101:100:1::4
101:100:1::5
101:100:1::6
Private Universal Network
L-NMA/L-IMA
(pnet.jp)
id_list
NMA/IMA
(unet2.jp)
101:100:1::7
11
1001:db8:11::/64
192.168.11.0/24
図 19: Name-rID リスト
id_loc_list
id_loc_list_head
id_loc_list
6
14
9
2001:db8:10::/64
192.168.20.0/24
1001:db8:10::/64
192.168.10.0/24
gw
8
NMA/IMA
(unet.jp)
16
15
2001:db8:11::/64
192.168.21.0/24
10
5
2001:db8:1::/64
192.168.1.0/24
4
2001:db8::/64
192.168.0.0/24
13
id_loc_list
101:100:1::4
101:100:1::5
101:100:1::6
loc_list_head
loc_list_head
loc_list_head
loc_list
loc_list
loc_list
2001:db8:1::4
2001:db8:1::5
2001:db8::6
loc_list
loc_list
2001:db8::5
2001:db8:1::6
gw
Local Network 17
1
3
2
12
7
192.168.30.0/24
2001:30::/64
Root NMA
NMA/IMA NMA/IMA NMA (jp)
IMA
18
(pnet.jp) IMA (JPNIC) (APNIC)
192.168.31.0/24 (lnet.jp)
2001:31::/64
Global Universal Network
19
20
L-NMA/L-IMA
(pnet.jp)
図 20: ID-Locator リスト
図 21: ネットワーク構成
リストヘッダを持つような二重のリスト構造になって
いる．今後，検索アルゴリズムの改善を考える際には，
これらのリストのソートが重要であると考えられる．
5.3
実験環境
評価にむけて，VMware ESXi 上で仮想マシン 20 台
に CentOS 5.5 をインストールし，図 21 に示す仮想ネッ
registry
トワークを構築した．図 21 中の黒字は実験で使用し
0
た IP アドレスを表し，赤字は ZNP における Locator
を表す．
各ドメインを管理する NMA, IMA は一部を除き同
一ノード内に置いた．NMA は Root NMA を根として，
jp ドメインの NMA，その下に unet.jp, unet2.jp, pnet.jp,
lnet.jp の各ドメインの NMA という階層をとる．IMA
は Root NMA を根として，APNIC の IMA, JPNIC の
IMA, その下に unet.jp, unet2.jp, pnet.jp, lnet.jp の各ド
メインの IMA という階層をとる．
本提案の実装で使用する ID の割り当て例を図 22 に
示す．ZNP で使用する ID はこのように階層構造をと
る．そのため，longest match 方式を用いることで，あ
る ID についてその ID を管理している IMA の情報を
知ることができる．
ROOT
APNIC
AfriNIC
ARIN
…
JPNIC
NIDA
SGNIC
…
unet.jp
pnet.jp
lnet.jp
unet2.jp
1
0xFF 0x00
0x01 0x00
0x02 0x00
0x03 0x00
0x04 0x00
0x01 0x01
0x01 0x02
0x01 0x03
0x01 0x04
0x01 0x01
0x01 0x01
0x01 0x01
0x01 0x01
value
organization
2
3
4
5
6
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0x01 0x00 0x00 0x01
0x01 0x00 0x00 0x02
0x01 0x00 0x00 0x03
0x01 0x00 0x00 0x04
図 22: ZNP での ID の割り当て例
11
v6形式表示
…
FF00::
100::
200::
300::
400::
101::
102::
103::
104::
101:100:1::
101:100:2::
101:100:3::
101:100:4::
# ディレクトリを指定
# ディレクトリを指定
options {
options {
directory "/etc/zna";
directory "/etc/zna";
};
};
# ROOT NMA の情報を読み込ませる
# ROOT NMA の情報を読み込ませる
zone "." {
zone "." {
file "nma.root";
file "nma.root";
};
};
# ID 正引き用ゾーンファイルのファイル名を指定
# Locator 正引き用のゾーンファイル名を指定
zone "pnet.jp." {
zone "unet.jp." {
file "nma.pnet.jp.zone";
file "ima.pnet.jp.zone";
};
};
# ID 逆引き用ゾーンファイルのファイル名を指定
zone "2.0.0.0.0.0.1.0.1.0.1.0.zna" {
図 24: IMA のコンフィグファイルの例 (unet.jp)
file "nma.pnet.jp.rev";
};
znp04
rID
101:100:1::4
znp05
rID
101:100:1::5
図 23: NMA のコンフィグファイルの例 (unet.jp)
znp06
rID
101:100:1::6
5.4
ゾーンファイル
101:100:1::
IMA
101:100:1::6
今回の実装では，NMA, IMA に初期のマッピング情
101:100:1::6
報を与える方法として，コンフィグファイルとゾーン
ファイルを記述し読み込ませる方式を採用した．
コンフィグファイルでは，NMA, IMA が起動時に
LOC
2001:db8:1::6
図 25: ID 正引き用のゾーンファイルの例 (unet.jp)
読み込むゾーンファイルのファイル名等を指定する．
NMA, IMA でのコンフィグファイルの書式の例を図
23, 24 に示す．コンフィグファイル内，optoins の項目
では，ゾーンファイルが置かれたディレクトリを指定
する．zone の項目では，ドメイン名を指定した後，そ
のドメイン内のマッピング情報が書かれたゾーンファ
イルのファイル名を指定する．
ZCMP メッセージの各 Query/Answer フィールドで
指定される Query/Answer Type の値を表 3 に示したが，
これはゾーンファイルに記述されたレコードに対応し
ている．
今回の実装で用意した図 21 のネットワークにおい
て，GU-Net で動作する NMA-unet.jp と IMA-unet.jp の
ゾーンファイルの例を図 25, 26, 27 に示す．
4
5
6
PTR
PTR
PTR
znp04.unet.jp.
znp05.unet.jp.
znp06.unet.jp.
図 26: ID 逆引き用のゾーンファイルの例 (unet.jp)
101:100:1::4
101:100:1::5
101:100:1::6
LOC
LOC
LOC
LOC
2001:db8:1::4
2001:db8::4
2001:db8:1::5
2001:db8:1::6
図 27: Locator 正引き用のゾーンファイルの例 (unet.jp)
12
5.5
動作確認・時間計測
中に示した．NMA-unet.jp がターゲットのキャッシュを
持っていることで省略された所要時間は，Root NMA,
本論文では，図 21 において GU-Net 上のドメインで
NMA-jp, NMA-unet2.jp における処理時間と，階層問
い合わせの通信にかかる時間 3 ∗ RT T の和と考えてよ
い．今回の実験から，マッピングエージェントがキャッ
シュを持つことによるシグナリングプロセスの省略は
有効であることがわかった．さらに，キャッシュの導
入は Name の階層構造が深くなるほど有効に働く．大
規模なネットワークではより大きな効果が期待できる．
ただし，キャッシュの TTL の管理などについては慎重
になる必要があり，設計や実装の今後の課題である．
マッピングエージェントによるマッピング情報の検
ある unet.jp 内のホスト znp05 が，同じく GU-Net 上の
ドメインである unet2.jp 内のホスト znp15 へデータ通
信を開始するためのシグナリングが正しく完了するこ
とを確認し，その所要時間を計測した．NMA-unet.jp
が znp15.unet2.jp の Name-ID マッピングのキャッシュ
を持っていない場合，シグナリング順序は具体的に次
のとおりである．ここで，znp15.unet2.jp をターゲット
と呼ぶ．(1) znp05 が NMA-unet.jp にターゲットの ID
を問い合わせる．(2) NMA-unet.jp が Root NMA にター
ゲットの ID を問い合わせる．(3) Root NMA は NMA-
jp の ID/Locator を返す．(4) NMA-unet.jp が NMA-jp
にターゲットの ID を問い合わせる．(5) NMA-jp は
NMA-unet2.jp の ID/Locator を返す．(6) NMA-unet.jp
が NMA-unet2.jp にターゲットの ID を問い合わせる．
(7) NMA-unet2.jp はターゲットの ID と IMA-unet2.jp
の ID/Locator を返す．(8) NMA-unet.jp はターゲット
の ID と IMA-unet2.jp の ID/Locator を znp05 に返す．
(9) znp05 が IMA-unet2.jp にターゲットの Locator を
問い合わせる．(10) IMA-unet2.jp はターゲットの Locator を返す．以上の様子について，5.1 節で述べたモ
ジュールごとに時間計測ポイントを示したものを図
28 に示す．udp send は，その中で z gethostbyname(),
z gethostbyid() を呼び出し Name-ID 解決と ID-Locator
解決を行うアプリケーションである．
一方，NMA-unet.jp がターゲットについての NameID マッピングのキャッシュを持っていた場合，Root
NMA からの階層的問い合わせは省略され，シグナリ
ング手順は次のようになる．(1) znp05 が NMA-unet.jp
にターゲットの ID を問い合わせる．(2) NMA-unet.jp
はキャッシュからターゲットの ID と IMA-unet2.jp の
ID/Locator を返す．(3) znp05 が IMA-unet2.jp にター
ゲットの Locator を問い合わせる．(4) IMA-unet2.jp は
ターゲットの Locator を返す．以上の様子を図 29 に
示す．
NMA-unet.jp がターゲットのマッピング情報のキャッ
シュを持たない場合の各ノード内での処理時間 (例: A1–
A2, B1–B4, C1–C4 など) と，各マッピングエージェン
ト内での nmad, imad の処理時間 (例: B2–B3, F2–F3 な
ど) を図 28 中に示した．同様にして，NMA-unet.jp が
キャッシュを持たない場合についての計測結果を図 29
13
索にかかる時間は，保持するレコード数やキャッシュ
の容量，検索アルゴリズム，CPU の性能などに左右さ
れる．本研究では，Name, ID の構造を階層化するこ
とで個々のマッピングエージェントの保持するレコー
ド数の増大を抑制し，スケーラビリティを確保してい
る．レコードの検索アルゴリズムについては，5.2 節
で述べた単純なリスト構造での管理ではなく，保持す
るデータのソートや，データベースの利用などによる
改良の余地はあるだろう．
また，本論文では，ZNP やマッピングシステムがユー
ザ空間への実装であることや，仮想化ネットワーク環
境における実験であることから，安定した測定結果を
得られていないことは確かである．カーネル空間への
実装を通して，より安定したパフォーマンスを得るこ
とができるようになると考えている．
6 まとめ
ZNP とは，将来のインターネットにおけるモビリ
ティやマルチホーミングなどの要求を満足するため，
ID/Locator Split アプローチに基づいて提案されたネッ
トワーク層プロトコルである．本論文では，ZNP にお
いて，マッピングシステムのスケーラビリティ，ドメ
インごとの独立したマッピング管理，ドメイン外への
Locator 流出がないことなど，実運用を考慮したマッピ
ング機能を提案した．マッピングシステムとして NMA,
IMA を階層化して導入し，それらを制御する ZCMP を
設計・実装した．さらに，仮想環境で構築したネット
ワークを利用して，階層的な名前解決が正常に動作す
ることを確認し，それに係る時間を計測した．今後は
znp05 (Host)
udp_send znpd linkd
znp06 (NMA-unet.jp)
linkd znpd nmad
A1
918.3 μsec
B1
A2
B2
1,690.0 μsec
B4
B5
1,450.5 μsec
ID Resolution
znp01 (Root NMA)
C1 linkd znpd nmad
C2
37.8 μsec
1,590.3 μsec
C3
C4
B6
znp03 (NMA-jp)
40.7 μsec
B7
D1 linkd znpd nmad
B3
41.8 μsec
B8
944.4 μsec
B10
10.4 μsec
D4 znp16 (NMA-unet2.jp)
E1 linkd znpd nmad
E2
47.6 μsec
1,072.0 μsec
E3
E4
B14
10.8 μsec
B15
B11
B12
B13
1,215.4 μsec
A3
B16
988.3 μsec
A4
znp16 (IMA-unet2.jp)
linkd znpd imad
A5
Locator
Resolution
819.1 μsec
A6
F1
F2
1,344.8 μsec
24.0 μsec
F3
A7
42.5 μsec
D3
B9
1,543.6 μsec
D2
F4
1139.4 μsec
A8
図 28: モジュールごとの時間測定ポイント (キャッシュなしの場合)
14
znp05 (Host)
udp_send znpd linkd
znp06 (NMA-unet.jp)
linkd znpd nmad
G1
ID
Resolution
762.2 μsec
H1
G2
H2
5,083.7 μsec
G3
H3
47.2 μsec
H4
1,099.0 μsec
G4
znp16 (IMA-unet2.jp)
linkd znpd imad
G5
Locator
Resolution
951.9 μsec
G6
I1
I2
2,583.3 μsec
32.8 μsec
I3
I4
G7
1,069.9 μsec
G8
図 29: モジュールごとの時間測定ポイント (キャッシュありの場合)
ZNP/ZCMP の実装を進め，これらの基本機能を確認
し，新世代ネットワークでの実運用に耐えうるもので
あることを確認する予定である．
[4] S Schütz, Henrik Abrahamsson, Bengt Ahlgren, and
Marcus Brunner. Design and Implementation of the
Node Identity Internetworking Architecture. Computer Networks: The International Journal of Computer and Telecommunications Networking, Vol. 54,
No. 7, pp. 1142–1154, May. 2010.
参考文献
[1] F. Teraoka. Redesigning Layered Network Architecture for New Generation Networks. In Proceedings
of 2nd IEEE Workshop on the Network of the Future,
pp. 1–6, Dec. 2009.
[5] Jianli Pan, Subharthi Paul, Raj Jain, and Mic Bowman. MILSA: A Mobility and Multihoming Supporting Identifier Locator Split Architecture for Naming
in the Next Generation Internet. In GLOBECOM, pp.
2264–2269. IEEE, 2008.
[2] Sho Kanemaru and Fumio Teraoka. ZNP: A Network
Layer Protocol Based on ID/Locator Split Considering Practical Operation. In Proceedings of International Conference on Communications (ICC 2011).
IEEE, 2011.
[6] KAFLE Ved P. and INOUE Masugi. HIMALIS:
Heterogeneity Inclusion and Mobility Adaptation
through Locator ID Separation in New Generation
Network. IEICE Transactions on Communications,
Vol. 93, No. 3, pp. 478–489, 2010.
[3] B. Ahlgren, J. Arkko, L. Eggert, and J. Rajahalme. A
Node Identity Internetworking Architecture. In INFOCOM 2006. 25th IEEE International Conference
on Computer Communications. Proceedings, pp. 1–
6, 2006 Apr.
[7] 藤川賢治, 太田昌孝. 階層的なロケータ自動番号割
当プロトコル hana と dns との連携. 電子情報通信
学会技術研究報告. IA, インターネットアーキテク
チャ, Vol. 110, No. 260, pp. 29–34, 2010-10-21.
15

Download Report