P2P技術を用いた端末識別子と 位置情報の一貫性の改善に関する研究 九州大学 システム情報科学府 情報知能工学専攻 岡村研究室 修士2年 林 健太朗 目次 研究背景 P2Pネットワークを用いた管理方式の提案 提案方式の構成 提案方式の規模適応性 シミュレーション ロケータ/ID分離ネットワーク DNSによるロケータ/ID管理方式 DNSによる方式の規模適応性の問題 設定・シナリオ 結果 考察 まとめと今後の課題 2 IPアーキテクチャの限界 IPアーキテクチャは1970年代に開発され標準化された技術 当時は考えられていなかった用途や状況により、様々な問題 が出てきている (例)移動透過性の問題 対向端末 TCP：通信相手 は1.0.0.1 1.0.0.0/24 2.0.0.0/24 1.0.0.1/24 2.0.0.1/24 3 Future Internet IPアーキテクチャ上で問題を解決する場合、IPアーキテクチャ の制限を受ける また、様々な問題を解決するために開発されたプロトコル間で 冗長や競合が発生しているという問題もある Future Internet 既存のネットワークに依存せず，一から新しくこれからのネッ トワークを考える研究分野 根本から全体を見直すことで、現在のプロトコル間の冗長や 競合といった問題を一掃する 4 ロケータ/ID分離ネットワーク Future Internetでは、位置情報(ロケータ)と端末識別子(ID)を 分離した新しいネットワークの研究が行われている これをロケータ/ID分離ネットワークと呼ぶ 移動透過性、マルチホーム、経路表サイズの増加の解決 本研究における定義 ネットワーク上の端点(位置)を一意に特定する識別子 ロケータ ID ネットワーク上の端末を一意に特定する識別子 5 ロケータ/ID分離ネットワーク パケット送信時、通信相手の宛先IDを指定 宛先IDを現在のロケータに変換し配送 既存の研究では、ロケータ/ID変換システムとしてDNS方式が 提案されている ＊参考文献[1][2] 移動透過性の解決 対向端末 ※IDもIPアドレス TCP：通信相手は ID:A.B.C 1.0.0.0/24 2.0.0.0/24 送信の流れ ID宛てのパケットを作成 宛先IDを現在のロケータに変換 ロケータを基に配送 ID：A.B.C Loc:1.0.0.1 ID:A.B.C Loc：2.0.0.1 宛先IDの端末が受信する 6 DNSによるロケータ/ID管理方式 DNSサーバ IDとロケータの対応を管理するサーバ IDを元にした木構造を構築 問い合わせIDに応じて、適切な子のサーバのロケータもしくは該当ロケータを 返答 DNSキャッシュサーバ クライアントから問い合わせを受け、DNSサーバへの問い合わせを行うことでロ ケータを解決し返答 一度問い合わせたIDのネームサーバのロケータをキャッシュ 問い合わせたIDのロケータ自体はキャッシュしない ネームサーバのみ キャッシュ root サーバ 返答 C 問い合わせ DNS クライアント DNS キャッシュサーバ ID：A.B.C Loc：100 ロケータ登録 B DNSサーバ 7 規模適応性の問題 頻繁にアクセスを受ける移動端末のロケータ/ID管理 負荷分散のためにスレーブサーバ増設 頻繁なロケータ更新が頻繁なゾーン転送につながり負荷が集中 Bネームサーバ ID：A.B.C 100[回/s]アクセス クライアント マスターサーバ 頻繁な ロケータ更新 頻繁なゾーン転送 キャッシュ サーバ スレーブサーバ 100[回/s]問い合わせ 100[回/s]問い合わせ 8 P2Pネットワークによる管理の提案 DNSによるロケータ/ID管理は規模適応性の問題がある P2Pネットワークによるロケータ/ID情報の管理を提案 端末のロケータ情報をキャッシュしないため、ネームサーバへアクセス が集中 負荷分散のためにスレーブサーバを増設しても、頻繁なロケータ更新 によるゾーン転送処理の増大 優れた規模適応性を持つ 頻繁にアクセスを受ける移動端末がある場合にも、問題が起きない 研究目的：ロケータ/ID管理について、DNS方式の規模適応 性の問題をP2Pネットワークを用いた提案方式によって解決 する 9 提案方式の構成 割り当てサーバ 各サブネットワークに設置 そのネットワークに接続する端末に対してロケータを割り当て LI(ロケータ/ID)ノード WAN LIノード同士で P2Pネットワークを構築 端末からのロケータ/ID情報登録 を受け付け管理する 端末からのロケータ 問い合わせを受け返答 割り当てサーバ P2Pネットワーク LIノード ロケータ 割り当て LAN ロケータ/ID 情報登録 端末 割り当てサーバ 割り当てサーバ LAN LAN 10 ロケータの問い合わせ ①LIノードが端末からの問い合わせを受ける ②問い合わせIDのロケータを知らなければ、P2Pネットワークに 対して問い合わせをフラッディング フラッディング：送信元ノード以外の隣接する全ノードに対してコピーを 送信する操作 ③問い合わせ情報はそれぞれ、経由したLIノードのロケータを順 番通り記憶 ロケータ登録 G H D LIノード C K F A 問い合わせ ID：K1のLoc？ B J E ID：K1 Loc：100 問い合わせ の目的地 経由ノードＡ，Ｂ，Ｅ,Jの ロケ－タを順に記憶 11 ロケータの返答 ①受信した問い合わせ情報の経由LIノードを参照 ②最後に経由したノードへ返答情報を送信 ③返答情報とそれを送信した隣接ノードをキャッシュ TTLは返答情報送信元ノードが指定 送信先ノードでも転送とキャッシュを同様に行う LIノード キャッシュを 持つLIノード G D C K F A 返答情報 ID：K1 Loc：100 H キャッシュ ＩＤ：K1 – Loc：100 転送先のロケータ：E B E キャッシュ ＩＤ：K1 – Loc：100 転送先のロケータ：J ID：K1 Loc：100 J 経由ノードＡ，Ｂ，Ｅ,Jの ロケ－タを順に記憶 12 ロケータの更新 ①LIノードが端末からのロケータ更新を受ける ②登録情報およびキャッシュを更新 ③キャッシュを参考に返答情報の転送先へ更新情報を送信 送信先ノードでもキャッシュの更新と転送を同様に行う ただしキャッシュのTTLは更新しない LIノード キャッシュを 持つLIノード G D C H キャッシュ ＩＤ：K1 – Loc：200 Loc：100 転送先のロケータ：E キャッシュ ＩＤ：K1 – Loc：200 Loc：100 転送先のロケータ：J K F A B E J ロケータ更新 Loc：100→200 13 規模適応性について 頻繁な問い合わせについて ノード数と更新負荷の関係 キャッシュが存在しない時は、更新元サーバへアクセスが集中 時間が経ち、キャッシュが広がると、アクセスは分散 分散度合いはノード数に依存 各ノードの更新処理は隣接ノードへの転送処理のみ キャッシュは、問い合わせをした端末に向けて作成 アクセスのないノードに向けて無駄な更新をしない 以上の事から、提案方式はノード数を増加させることが容易 であると予想される このことをシミュレーションによって示す 14 シミュレーション設定 共通設定 DNS方式の設定 日本地図上で１辺10[km]の正方形をひとつの ネットワークエリアとする 毎秒100回のアクセスを受ける端末が 100[km/h]のスピードで日本を縦断 1時間に10回、つまり6分間隔で ロケータ更新を行う計算 100[km/h] 100[アクセス/s] 東京にマスターサーバをひとつ その他の都道府県にスレーブサーバをひとつずつ、計46個設置 マスター・スレーブ間の帯域は100[Mbps] 遅延は20[ms] 提案方式の設定 各都道府県にLIノードを計47個設置 各ノードは平均4つのリンクをランダムなノードに対して持つ リンク間の帯域は100[Mbps] 遅延は20[ms] 15 シナリオ 全ノードの内、問い合わせを受けているノードの割合を「ノ ード稼働率」と呼ぶことにする 0～30分の間は西日本からのみアク セスがあるとする ノード稼働率＝ 23 / 47 ≒ 0.5 30～60分の間はどこからもアクセス がないとする ノード稼働率 ０．５ ノード稼働率＝ 0 / 47 ＝ 0 この1時間中の、ロケータ更新によ るシステムの負荷を調べる ノード稼働率 ０ アクセスなし 16 結果：各ノードの総転送回数 転送回数[回] 470 460 450 440 100 省略 転送回数[回] 100 430 80 420 60 0 3 6 9 121518212427303336394245 積分値：460[回] 60 40 40 20 20 0 マスター サーバ 80 0 3 6 9 121518212427303336394245 ノード番号 積分値：145[回] 0 0 4 8 12 16 20 24 28 32 36 40 44 DNS方式 ノード番号 提案方式 それぞれのノードが1時間の間に行った、 更新情報の転送回数の合計 17 結果：転送回数の時間推移 転送回数[回] 500 450 400 350 300 250 200 150 100 50 0 DNS方式 提案方式 6 12 18 ノード稼働率 ０．５ 24 30 36 42 48 54 60 時間[m] ノード稼働率 ０ 1時間の間のシステム全体の更新情報転送回数の推移 18 考察 シミュレーション結果 ノード数を増加させることが容易 提案方式は、ノード稼働率によって更新情報転送数が変わる 転送処理の負荷は分散される 更新情報転送数がノード数に直接依存しない ノード数の増加によって特定のノードに負荷が集中することがない 以上のことから提案方式は、DNS方式よりも規模適 応性について優れていると言える 19 考察 提案手法の問題点 問い合わせのフラッディング 更新完了までに時間がかかる(今回は80.33[ms])ため、古 い情報が参照される恐れ 解決策 問い合わせに分散ハッシュテーブル(DHT)を用いる 移動前のネットワークへ送信されたパケットを、そのネット ワークの割り当てサーバが代理で受信し、宛先端末の新 しいロケータへ転送する 20 まとめと今後の課題 まとめ DNSによるロケータ/ID管理方式の規模適応性の問題を示した P2Pネットワークを用いたロケータ/ID管理方式を提案 シミュレーションによって、提案方式が優れた規模適応性を持つことを 示した 今後の課題 ノード数を増加させた場合のシミュレーション DHTを用いた問い合わせ方式の考案 古い情報が参照された場合の対応システムの考案 21 参考文献 文献[1] aLorand Jakab, Albert Cabellos-Aparicio, Florin Coras, Damien Saucez, and Olivier Bonaventure, "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System, “IEEE journal on selected areas in communications, Volume 28, Issue 8, pages 1332-1343, October 2010. 文献[2] P. Nikander, J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extension," RFC 5205, April 2008. 22 ご清聴ありがとうございました 23
© Copyright 2024 ExpyDoc
