Download
1 / 15
150 likes | 235 Views
京都大学大学院情報学研究科 藤川 賢治 松本 存史 小塚 真敬 岡部 寿男. TCPマルチホームオプションの実装とSOCKSサーバへの応用. 背景. マルチホーミングの需要 通信経路に冗長性を持たせ、高信頼・耐障害性のある インターネット接続を実現する 従来のルータ主導のマルチホーミング方式の限界 経路表の増大(Punching Hole) 小規模サイトのサポート(AS番号が必要) IETF Multi6ワーキンググループ IPv6時代の新しいマルチホーミング方式の検討
E N D
京都大学大学院情報学研究科 藤川 賢治 松本 存史 小塚 真敬 岡部 寿男 TCPマルチホームオプションの実装とSOCKSサーバへの応用
背景 マルチホーミングの需要 通信経路に冗長性を持たせ、高信頼・耐障害性のある インターネット接続を実現する 従来のルータ主導のマルチホーミング方式の限界 経路表の増大(Punching Hole) 小規模サイトのサポート(AS番号が必要) IETF Multi6ワーキンググループ IPv6時代の新しいマルチホーミング方式の検討 太田氏らによるEnd-to-End原理に基づく新しいマルチホーム方式「End-to-End Multihoming」の提案 End-to-End Multihomingの実用化に取り組む End-to-End Multihomingの実用化に取り組む
End-to-End Multihoming 3ffe:1:1::/64 2002:11:22::/64 43.245.1.2 IPv6 IPv6 IPv4 • エンドノードが複数のアドレスを持つ • IPv4・IPv6混在環境, 有線・無線混在環境 など • 適切な上流回線にパケットを送信する必要性 (Ingress Filtering)
End-to-End Multihoming drop! drop! drop! DATA DATA DATA DATA DATA エンドシステムに必要な機能 • アドレス情報交換 • 複数アドレス対応 • ネットワーク障害検出 • 経路切り替え 接続開始時・途中に経路を切り替えて障害回復 エンドホストのみの協調動作によって行うマルチホーミング手法 3ffe:1:1::/64 2002:11:22::/64 43.245.1.2/24
関連研究-E2E-MH- トランスポート層手法 新プロトコル:SCTP(R. Stewart), DCCP(Kohler E. ) 多機能・先進的 TCP/UDPと非互換 アプリケーションの書き換え TCP拡張方式: Troel's TCP,TCP Migrate TCPとの互換性 セキュリティ,拡張性に 制約がある 中間レイヤ手法(L3.5) L3とL4の間に複数アドレス対応のための層を設ける Multi6 Wgで提案 MAST/SHIM/ODT L3,L4には一切変更無し L4の機能を別レイヤで再度実装するなど無駄が多い Application Application ID1 IP1 Transport ID1 Transport L3.5 IP1 IP2 IP1 IP2 Network Network IP2 IP2 IP1 IP1
本研究の概要 • End-to-End Multihomingのための3種類の エンドシステムを設計・実装 3)拡張型 トランスポート層手法 1)アプリケーション層手法 2)トランスポート層手法 Application Application Application IP1 IP1 IP2 IP1 Transport Transport Transport MH Framework IP1 IP2 IP1 IP2 IP2 IP1 Network Network Network IP2 IP2 IP1 IP1 IP2 IP1 提案手法の妥当性確認のための実験 関連研究、提案手法の比較・考察
提案手法-設計ポリシー- パス1 送信元アドレス1 ゲートウェイ1 送信元アドレス2 パス2 ゲートウェイ2 パス3 送信元アドレス3 • 設計ポリシー • Multipathを用いたパス定義(Ingress Filter回避) • Fate-sharing(End-to-End)原理の遵守 • 「あるアプリケーション/トランスポートの死活(fate)が他のアプリケーション/トランスポートの死活(fate)に影響しない」 • 障害検出 • 実際のデータ(と同じ形式の)パケットによって障害検出 • 他のコネクションの死活を利用しない 宛先アドレス
提案手法1-アプリケーション層モデル- • 「LIN6 Aggressive API」 • モバイルプロトコルLIN6をマルチホーム対応に • アプリケーションにアドレスを制御するためのAPIを提供 • アドレス情報交換: L3(LIN6プロトコル) • 障害検出・経路切替 L7(アプリケーション) • 複数経路を柔軟に 利用可能 • アプリケーションの修正 が必要
提案手法2-トランスポート層モデル- SYN+MH-Permit SYN,ACK+MH-Permit ACK DATA+アドレス情報 ACK+アドレス情報確認 DATA X DATA 再送 X DATA X DATA 経路切り替え ACK • TCP-MH :TCPのE2E-MH対応 • アドレス情報交換のためのTCPオプションを定義 • DATAパケットに制御情報を多重化 addr1 addr3 addr2 addr3 Internet addr1 addr2
提案手法2-トランスポート層モデル(cont.)- • TCP-MH:その他の特徴 • 内部的にTCPを束ねる形で複数アドレス対応を実現 • 既存のTCP拡張手法の問題点を解決 • Troel'sTCPはIPv6に特化 • TCP Migrateは複数アドレスを扱えない • 既存のTCPと通信互換性を保つ • 高速で完全な障害検出 • アプリケーションに修正の必要無し • TCP以外の プロトコルに関しては E2E-MHをサポートしない • アドレス情報が各コネクション単位 に管理される Application (socket) TCP-MH TCP TCP TCP IF1 IF2
提案手法3-拡張トランスポート層モデル- • TLC-FM(Transport Layer Common Framework for Multihoming) • 全トランスポートプロトコルに対して、共通のE2E-MHフレームワークを提供 • 経路切り替え・アドレス情報交換などの共通機能を提供 • 障害検出は各トランスポートプロトコル及びアプリケーションにて行う • アドレス/ゲートウェイ/ パス情報の共有、 品質の評価・学習を行う • UDPアプリなどの障害検出 はアプリの助けが望ましい
実験環境 -障害検出・経路切り替え- • TCP-MH実装を用いて経路切り替え手法を検証 • 直結した2ホスト間でTCP接続 • ケーブルを抜き差しし、ネットワーク障害を模倣
4度目の再送パケットが別経路で再送 10～20秒程度で障害から回復、誤検出無し 実験結果 -障害検出・経路切り替え- 経路1 bytes 経路2 seconds 障害発生 回復 発生 回復
関連研究・提案手法の比較 一長一短があるが、制御チャネルの実装方法の 工夫次第でTLC-FMが汎用的 TLC-FM (Layer4') TCP-MH (Layer4) LIN6API (Layer7) Layer3.5 SCTP △ 障害検出 ◎ ◎ ◎ ◎ 制御チャネル トランスポート層以上で検出 × E2E-MH 対応範囲 ○ △ △ ◎ TCP ホスト単位 全トランスポート SCTP アプリ単位 × △ 普及の容易さ △ △ ○ 制御チャネルが独立 制御チャネルが独立 LIN6プロトコル × 処理コスト (オーバヘッド) △ ○ ○ ○ 処理が重複 ○ ○ ○ △ セキュリティ ◎ TCP拡張性の制限
まとめ • End-to-End Multihomingの実用化に向けて • 新しいエンドシステムの必要性 • 求められる機能 • 3種類のエンドシステムの設計と実装 • システム設計ポリシー • それぞれの特徴、長所・短所について • 実験を行い、本設計の妥当さを検証 • 関連研究と提案手法を比較評価
