P2P技術を用いた端末識別子と位置情報の一貫性の改善に関する研究九州大学システム情報科学府情報知能工学専攻岡村研究室修士2年林健太朗 IPアーキテクチャの限界   現在のIPアーキテクチャは1970年代に開発され標準化された技術当時は考えられていなかった用途や状況により、様々な問題が (例)モビリティ、マルチホームモビリティの問題対向端末 1.0.0.0/24 1.0.0.1/24 TCP：通信相手は1.0.0.1 2.0.0.0/24 2.0.0.1/24 IPアドレスの二元性 ID ロケータ通信相手の端末を識別するためのアドレス（使用例）TCP ネットワーク上の位置を識別するためのアドレス (使用例)パケット配送（解決法）ロケータとIDで別のアドレスを使えば良い 2 ロケータ/ID分離ネットワーク  Future Internet   既存のネットワークに依存せず、一から新しくこれからのネットワークを考える研究分野ロケータ/ID分離ネットワークもFuture Internetのひとつモビリティの解決対向端末 ※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の端末が受信する 3 DNSによるロケータ/ID管理    IDに階層構造をもたせる DNSコンテンツサーバはIDの構造に対応したDNSコンテンツサーバ群を構築各サーバで対応するIDのロケータを管理 root サーバサーバ管理するID    C ID：A.B.C Loc：1.0.0.1 IDの右側が上位最上位はrootサーバ親サーバは子サーバのロケータのみ知っている管理している B A  該当のIDを管理するサーバへ問い合わせるためには、上位サーバからひとつづつ問い合わせる DNSコンテンツサーバ 4 DNSサーバの構成 DNS コンテンツサーバ DNS キャッシュサーバフルサービスリゾルバ再帰問い合わせスタブリゾルバ root サーバ非再帰問い合わせマスター（プライマリ）ゾーン転送スレーブ (セカンダリ) 5 キャッシュ    返答された情報はキャッシュする各レコードにはそれぞれTTLが設定されている TTL(Time To Live)  その情報をキャッシュしておく時間  一般的には1日～3日 DNS キャッシュサーバフルサービスリゾルバ DNS コンテンツサーバ root サーバ返答返答スタブリゾルバ 6 DNSによる管理の問題  移動端末のID管理  端末の移動によりロケータが頻繁に更新される可能性がある頻繁な更新  コンテンツサーバとキャッシュサーバの情報の不一致  キャッシュサーバの情報はTTL時間更新されない  TTL時間を短くすると一貫性は保つことができるが、コンテンツサーバ、特にrootサーバへの負荷が増大する 7 具体例 ID：A.B.Cの問い合わせクライアント ID：A.B.Cの問い合わせキャッシュサーバ ID：A.B.C Loc:1.0.0.1 ロケータの更新ネットワーク 1.0.0.1→2.0.0.1 1 コンテンツサーバ B ID：A.B.C Loc:1.0.0.1 1日間キャッシュ  Loc:1.0.0.1を TTL1日で返答ネットワーク 2 ID：A.B.C Loc:2.0.0.1 その瞬間端末が移動したとするこのキャッシュサーバを参照するDNSクライアントは1日間、ID ：A.B.Cの端末へアクセスできなくなる 8 研究の目的  DNSによるロケータ/ID情報の管理は問題    端末が移動する場合の頻繁なロケータの更新に対応できない上位のコンテンツサーバに負荷が集中そこで、P2Pネットワークによるロケータ/ID情報の管理を提案   頻繁な更新に対応負荷の分散本研究の目的：P2Pネットワークを用いたロケータ/ID分離ネットワークの実現 9 提案ネットワーク  ロケータ/ID管理サーバ(LIサーバ)    各ネットワークに設置サーバ同士でP2Pネットワークを構築しロケータ/ID情報を管理端末から見た場合    ロケータは接続先のLIサーバにより割り当てられる IDは端末ごとにユニークで、変化しない IDからロケータへの変換はLIサーバへ問い合わせるロケータ割り当て ID:A Loc：11 LIサーバ LIサーバネットワーク 1 ID問い合わせネットワーク 3 P2Pネットワーク LIサーバネットワーク 2 ID:E Loc:21 10 ロケータ/ID情報の管理    各サーバはそのアクセスネットワークへ接続している端末の IDとロケータを管理するその情報をP2Pネットワークへフラッディグするホップ数を制限することである一定の範囲に情報が広まる ID：Aに Loc：11割り当て ID：A Loc：11 ID：A Loc：11 ID:A Loc：11 ホップ数：１ホップ数：２ 11 問い合わせ    端末はそのアクセスネットワーク内に存在するサーバへ問い合わせを行うサーバがその情報を知っていればそれを返答知らなければ、P2Pネットワークへ問い合わせをフラッディング ID：BのLocは？ ID:Bは知らない ID:A Loc：11 ID：BのLocは？ ID：BのLocは？ 12 情報の一貫性 LIサーバ LIサーバ ID:A Loc：11 ネットワーク 1 P2P ネットワーク ID:A Loc：21 ネットワーク 2 ID問い合わせ LIサーバ  移動前のネットワークのサーバへも更新情報を通知し、そこからフラッディング   旧い情報を持つ範囲、つまり移動前のサーバからのフラッディング範囲の情報を更新する必要があるそれでも旧い情報を参照して、移動前のネットワークへパケットが送信された場合は、移動前のネットワークのサーバが 13 転送処理するシミュレーション  提案ネットワークにおける複数の方式の性能をシミュレーションする予定    評価項目     P2Pネットワークを用いた場合を複数方式 DNSを用いた場合問い合わせ時間更新時間確実性考察   P2PネットワークとDNSの違い改善方法 14 まとめ    DNSによるロケータ/ID情報の管理は問題 P2Pネットワークによるロケータ/ID情報管理の提案シミュレーションによりP2Pネットワークを用いる有効性、実現性を評価する 15