利用者主導型動的ノードグルーピング機構 に関する研究 慶應義塾大学政策・メディア研究科修士二年 サイバーインフォマティクス(CI) 青柳禎矩 主査 徳田英幸，副査 高汐一紀，戸辺義人 概要 ﻪ利用者主導型・導入容易な動的ノードグ ルーピング機構「シェパード」の提案 アウトライン ﻪ ﻪ ﻪ ﻪ 本研究の背景と目的 シェパードの提案および関連研究との比較 シェパードの設計と実装 今後とまとめ 本研究の背景と目的 ノードグループ ﻪIPを用いて通信できるプライベートなノードの増加 ﻪあらゆる組織でのLAN (Local Area Network)構築 → ﻩLANは固定的な「ノードグループ」 ：ノードグループ 通信相手による通信の分類 ﻪパブリックなサーバに対する通信 ﻪプライベートなノード同士の通信 google 番組表取得 動画鑑賞 ファイル共有 本研究の目的 「 ﻪ異なるLANに属する」プライベートなノード同士の通信に着目 ﻩ通常であればファイアウォール，NAT等を意識する必要がある ﻩ物理的なLANを意識しなくて良い＝透過的な通信を，利用者によって容 易に実現できないか？ ﻩユビキタスコンピューティングの発展により、ノード群の左右の繋がりがま すます重要になる 映像が見たい 映像が見たい 横断的なノードグループのメリット ノードグループ環境専用の アプリケーション使用 映像鑑賞 グループ専用の アプリケーション実装 新しいユビキタス アプリケーション 映像鑑賞 ﻪ下記を同時に実現できる ﻩ従来アプリケーションの再利用 ﻩ今後のアプリケーションの通信基盤 既存技術による解決策：VPN ﻪ横断的ノードグループ形成の単位がLAN ﻩノード単位の細かいアクセス制御ができない ﻩ通常，接続先LANの全ノードにアクセスできてしまう Virtual Leased Line (LAN と LAN) Virtual Private Dial-up Network (LAN とノード) 既存技術による解決策： 動的ノードグルーピング ﻪ横断的ノードグループ形成の単位がノード ﻩノード単位の細かいアクセス制御が可能 固定的 動的 シェパードの提案および関連研究と の比較 シェパードの提案 ﻪ機構名：シェパード ：動的ノードグルーピング機構 ﻩ下記を両立する動的ノードグルーピング機構 ﻯ既存ネットワーク構成，設定などを変更する必要がない → ﻳ利用者主導型 ﻯLAN内のノード一つにシェパードを導入するだけ → ﻳユーザが必要な導入回数が少ない 関連研究 ﻪノードからのトラフィックをどのように機構に 集約するか，に着目して分類 ﻩBridge Model ﻩRouting Model ﻩFlat Model 関連研究 (1) ﻪBridge Model トンネリング用の サーバが必要 ネットワーク構成の 変更が必要 ：動的ノードグルーピング機構 既存の実装 ・P2P-CUG (NEC) など 問題点 ・ネットワーク管理者主導型 ・ネットワークの知識が必要 関連研究 (2) ﻪRouting Model ルーティングテーブル の書き換え必要 ：動的ノードグルーピング機構 （既存の実装） ・SoftEther (ソフトイーサ) など トンネリング用の サーバが必要 問題点 ・ネットワーク管理者主導型 ・ネットワークの知識が必要 関連研究 (3) ﻪFlat Model ：動的ノードグルーピング機構 既存の実装 ノードのソフトウェア 改変が必要 ・i3 ・OCALA ・ELA など 問題点 全てのノードに インストールの必要 ・導入の手間が多い ・ノードによっては導入困難 シェパード ﻪシェパードのトラフィック集約手法 ﻩProxy ARP を利用する ﻩシェパード（羊飼い）のようにトラフィックを特定 ノードに呼び寄せることができる 送信先 送信元 ns ARP要求 ss nd ARP代理応答 sd 本来応答 すべきノード 比較 ﻪシェパードは導入前のコストが少ない Bridge Routing Flat Shepherd ネットワークの 物理的変更 必要 不要 不要 不要 ネットワークの 論理的変更 不要 必要 不要 不要 機構導入回数 少ない 少ない 多い 少ない 導入後の設定 必要 必要 必要 必要 シェパードの設計と実装 全体構成 ﻪLANのネットワーク環境 ﻩ一般的な 802.11 , IPv4による物理ネットワーク ﻩインターネットとの接続 ﻩシェパードをインストールした「シェパードノード」の存在 ﻯ各シェパードにはユニークなID ﻪシェパード管理サーバ ﻩシェパードの存在の把握 シェパード管理 サーバ シェパード シェパードノード ns ss シェパードノード nd sd シェパードの動作手順 (1) ﻪLAN内ノードの把握 ﻩノードのLANへの接続 ﻩシェパードノードがノードを認知 新しいノードを検出しました 追加しますか？ ノード名： はい ns 接続，DHCP要求等 ss いいえ シェパードの動作手順 (2) ﻪ外部LANのシェパードノードの発見 ﻩ各シェパードはユニークなIDを持つ ﻩシェパード管理サーバを通じて発見する シェパード管理 サーバ 発見 ns ss nd sd シェパードの動作手順 (3) ﻪ他ノードとの通信時に用いるIPアドレスの決定 ﻩシェパードは自分のMACアドレスを変更してDHCP要求を出す ﻩDHCP応答をプロミスキャスモードで受信する ﻩ応答に含まれているIPアドレスを用いる → ﻪnsからndは同一ネットワークのIPアドレスとして見える ﻩns通信時はssを参照する ns 10.0.0.1 DHCP要求 (10.0.0.3) ss nd 10.0.0.2 sd 192.168.0.1 192.168.0.2 DHCP応答受信 シェパードの動作手順 (4) ﻪトラフィックの誘導 ﻩノードが上記のIPアドレス宛にトラフィックを転送する ため，ARP要求する ﻩシェパードがそのARPに応答する (Proxy ARP) →nsがシェパードノードにトラフィックを送信するよう になる ARP要求 where 10.0.0.3 ns 10.0.0.1 (10.0.0.3) ss nd 10.0.0.2 sd 192.168.0.1 192.168.0.2 ARP応答 シェパードの動作手順 (5) ﻪ実際のトラフィック転送 ﻩ送信元ノードがトラフィックを送信→シェパードに到達 ﻩトラフィックをカプセリングして，他のシェパードに転送 ﻩ受信したそのインデューサはカプセリングをはずし，ト ラフィックを転送→送信先ノードがトラフィックを受信 IP Packet To:10.0.0.3 ns 10.0.0.1 ss 10.0.0.2 (10.0.0.3) nd sd 192.168.0.1 192.168.0.2 実装 ﻪシェパードノード ﻩ実装環境：Visual C++ .NET @ Windows XP ﻩ使用ライブラリ：WinPcap、Libjingle ﻪシェパード管理サーバ ﻩXMPPサーバを使用する ﻯXMPPはIMのオープンプロトコル ﻯ実装はいくつかオープンソースで公開されている ﻯサービス中のサーバも存在する (Google Talkなど) シェパードノードのモジュール図 User Interface ノード 追加要請 ノード 追加？ ノード 追加 Nodes managing module MAC アドレス Node managing module 宛先存在 確認 宛先 存在応答 宛先 要求 宛先 応答 内部メッセージ Inducing module DHCP 要求 ARP 要求 Capsulating module ARP 応答 トラフィック 受信 トラフィック 送信 トラフィック 今後とまとめ 進捗と今後の予定 ﻪ現在 ﻩネットワーク処理、GUIの実装途中 ﻪ11月 実装完了 ﻪ12月 評価完了 ﻪ並行して論文を執筆する 評価方針 ﻪ下記項目を関連研究と比較する ﻩ定性的評価 ﻯ導入容易性 ﻳネットワークの物理的変更 ﻳネットワークの論理的変更 ﻳ導入回数 ﻩ定量的評価 ﻯ動的ノードグルーピング完了までに要する時間 ﻯスループット ﻯ遅延 ﻯその他 まとめ ﻪ動的ノードグルーピングの必要性 「 ﻪシェパード」を提案 ﻩ利用者主導型（＝既存ネットワークへの変更不 要） ﻩ容易な導入（＝導入回数が少なくて良い） 参照文献 ﻪ ﻪ ﻪ ﻪ "異種セグメント端末による分散型仮想LAN構築機構の設計と実装" 青柳 禎矩, 滝沢 允, 斉藤 匡人, 間 博人, 徳田 英幸 情報処理学会全国大会 Vol.66 (3) 2004年3月 March. 2004 "ELA: 分散型VPNの設計と実装" 青柳 禎矩, 滝沢 允, 斉藤 匡人, 間 博人, 徳田 英幸 日本ソフトウェア学会インターネットテクノロジーワークショップ(WIT2004) "ELA: A Fully Distributed VPN System over Peer-to-Peer Network" Sadanori Aoyagi, Makoto Takizawa, Masato Saito, Hiroto Aida, Hideyuki Tokuda IEEE International Symposium on Applications and the Internet (SAINT 2005) 2005年1月 January. 2005 pp.89-92 "Shepherd: 利用者主導型動的ノードグルーピング機構" 青柳禎矩, 高橋ひとみ, 斉藤匡人, 間博人, 徳田英幸 日本ソフトウェア学会 SPA X Contribution ﻪLower load ﻩ監視すべきパケットが減る ﻪScalability ﻩサーバの性能が足りなくなってきたらサーバを 追加するだけでよい ﻪRedundancy ﻩサーバを複数設置して冗長性を持たせること が可能 Motivation ﻪ異なるネットワークに属するIPデバイス同士を容 易につなげたい ﻩユビキタスコンピューティングの発展によって，IPデバ イスおよびこのような需要は増えるはず Internet ﻪ４．２．２ ノードのグローバルな把握 ﻩ各PCはBuddy List を保持 ﻩ各IPデバイスごとにアクセス制限ができる ○○家のDVDレコーダからの接続 NAS： ○許可 ●禁止 プラズマ： ●許可 ○禁止 Related Works ﻪアプローチの種類 ﻩApplication Layer ﻩTransport Layer Related Work ﻪ拠点間接続VPN ﻩ端末は何もインストールしなくてもOK ﻩ端末とゲートウェイの間にIPsecサーバを設置 ﻯIPsecサーバは端末からの「全て」のトラフィックを監視 ﻯ特定宛先のパケットだけトンネリング処理 ﻩSoftEther, P2P-CUG なども基本的に同一 ゲートウェイ IPsecサーバ ﻪ問題点 ﻩ性能的な問題 ﻯ高負荷 ﻳ ﻳ 全てのトラフィックを監視す るので重い トンネリング通信以外の通 信も影響をうける ﻯボトルネック ﻳ ﻳ サーバが遅いと，全通信が 遅くなる 気軽にサーバを追加でき ない ﻬネットワーク構成を 変更する必要がある ﻯ冗長性の欠如 ﻳ 壊れたら全く通信できない ﻩ使用上の問題 ﻯ細かいアクセス制限が出 来ない ﻳDVDレコーダには通信 してよいが，NASはダメ とか ﻯ普通にDHCPでIPアドレス が割り当てられると，その デバイスにどのアドレス がついたか分かりにくい ﻪ２．３ ノードグルーピングのアプローチ ﻩApplication Layer ﻯpucc ﻩTransport Layer ﻯSOCKS ﻩNetwork Layer ﻯSoftEther, ﻩData Link Layer ﻯSoftEther, P2P-CUG,
© Copyright 2024 ExpyDoc
