Transcript UDL
仮想ブロードキャストリンクを利用した 片方向通信路の透過的経路制御 藤枝 俊輔（慶應義塾大学） [email protected] 概要 • 既存の経路制御技術は通信媒体の双方 向性を前提としている • 片方向の通信路をインターネットで利用す る場合に生じる経路制御の問題を解決 • 片方向通信路上に仮想のブロードキャスト リンクを構築し、既存の経路制御プロトコ ルがそのまま動作する環境を提供 片方向通信路 • 衛星回線 • ＣＡＴＶ網 片方向通信路 Uni-directional Link (UDL) 双方向回線を用いた通信路 Bi-directional Link(BDL) 片方向通信路の利用 • インターネットのトラフィック傾向 – サーバからクライアントへ • www • ftp – トラフィック全体にも偏りがある ﾙｰﾀ ﾙｰﾀ ﾙｰﾀ ﾙｰﾀ 片方向通信路の利用 • 衛星回線 – 広域性、同報性 • ＣＡＴＶ綱 – 既に設置された通信路の有効利用 Feeder Receiver ﾙｰﾀ ﾙｰﾀ UDL ﾙｰﾀ ﾙｰﾀ ＵＤＬを含むネットワーク • 少数のFeederと多数のReceiverが接続するの が一般的 • Receiverは外部への送信にＢＤＬを利用する UDL ﾙｰﾀ ﾙｰﾀ ﾙｰﾀ ﾙｰﾀ Receiver Receiver BDL Receiver Feeder Internet ＵＤＬを含むネットワークにおける 経路制御の問題 • 動的な経路制御プロトコルが正しく動作しない – RIP – OSPF • ReceiverがＵＤＬ上の終点ＩＰアドレスに到達で きない – ICMPエコー要求を利用して、FeederからReceiver へ到達性を確認できない ＲＩＰを動作させた場合 • ルータＡが隣接ルータＢを経由した経路を 利用するためには、事前にルータＢから経 路情報を受け取る必要がある • ＵＤＬではFeederはReceiverからの経路情 報を受け取れない Router B (Receiver) ﾙｰﾀ ﾙｰﾀ 経路情報 UDL Router A (Feeder) ﾙｰﾀ ﾙｰﾀ ＯＳＰＦを動作させた場合 • ルータ間でコネクションを確立してから、その 隣接ルータを経由した経路を使用する • コネクションの確立には、ルータ間で互いに ＨＥＬＬＯメッセージを受け取る必要がある Router B (Receiver) ﾙｰﾀ ﾙｰﾀ HELLO Router A (Feeder) UDL ﾙｰﾀ HELLO ﾙｰﾀ ＯＳＰＦを動作させた場合 • ルータ間でコネクションを確立してから、その 隣接ルータを経由した経路を使用する • コネクションの確立には、ルータ間で互いに ＨＥＬＬＯメッセージを受け取る必要がある Router B (Receiver) ﾙｰﾀ ﾙｰﾀ HELLO Router A (Feeder) UDL ﾙｰﾀ コネクションが 確立されない ﾙｰﾀ ReceiverからＵＤＬ上の 終点ＩＰアドレスへの到達性 • Receiverは外部への送信にBDLを利用 • 直接配送は間接配送よりも優先される • ＵＤＬ上の終点ＩＰアドレスにデータを送信 する場合、BDLを利用できない。 ﾙｰﾀ ﾙｰﾀ Receiver Feeder/Receiver Internet Internet ＵＤＬを含むネットワークにおける 動的な経路制御の手法 • 経路制御プロトコルの改変 – RIP,OSPF – UDLに接続するノードと経路情報を交換する全て のルータで変更されたプロトコルが動作する必要 • トンネルを用いた解決法 – ReceiverからFeederにトンネルを設置 – 最新の提案がＩＥＴＦで議論されている (draft-ietf-udlr-lltunnel-01.txt) – 実装が容易 – ReceiverとFeederだけに変更を加えればよい 全体図 UDLに送信する パケットを トンネリング ブロードキャストエミュレーション UDL 脱カプセル化し データリンク パケットを ﾙｰﾀ ﾙｰﾀ Receiver Receiver BDL ﾙｰﾀ Receiver UDLに送信 Internet ＤＴＣＰを用いて、 トンネルを自動設定 ﾙｰﾀ Feeder 仮想ブロードキャストリンク • ＵＤＬ上でブロードキャストリンクをエミュ レーション • 現在の経路制御プロトコルがそのまま動 作する環境を提供 • ReceiverからＵＤＬ上の終点ＩＰアドレスへ の到達性を実現 Ｄｅｆａｕｌｔ Ｆｅｅｄｅｒ • 既存の提案 – ReceiverからのBroadcast、Multicast、 他のReceiverへのトンネル先 – 各Feederへの送信は個別にトンネルを使用 • 本設計 – Feederへの送信を含め、UDLへの送信全てを Default Feederにトンネリング 既存の提案でのトンネリング UDL ﾙｰﾀ ﾙｰﾀ ﾙｰﾀ Receiver Receiver BDL Internet Feeder ﾙｰﾀ Feeder ﾙｰﾀ Default Feeder 本機構でのトンネリング UDL ﾙｰﾀ ﾙｰﾀ ﾙｰﾀ Receiver Receiver BDL Internet Feeder ﾙｰﾀ Feeder ﾙｰﾀ Default Feeder ReceiverごとにDefault Feederを選択 Default FeederはＵＤＬに１つである必要はない。 Receiverはそれぞれ個別にDefault Feederを選択する UDL ﾙｰﾀ ﾙｰﾀ ﾙｰﾀ Receiver Receiver BDL Internet Feeder ﾙｰﾀ Default Feeder ﾙｰﾀ Default Feeder 想定するネットワーク環境 • Receiverには効率的にパケットを送信でき るFeederがある – 同じ管理ドメイン内のFeederを利用 UDL ﾙｰﾀ Feeder ﾙｰﾀ ﾙｰﾀ ﾙｰﾀ Feeder Receiver Default Feeder BDL Internet Internet 性能の比較 • それぞれのFeederにトンネルを設定する場 合、Feederがどのくらいの数までなら規模 性を保てるのか • Receiverからのパケットを中継するFeeder の負荷はどれくらいのものか 詳細な性能の測定は今後の課題 データリンクトンネリング • データリンクアドレス – ＭＡＣアドレスを持つＵＤＬインタフェースが広 まりつつある • データリンクヘッダ – FeederがReceiverからのパケットをＵＤＬに送 信する場合 宛先 ：宛先UDLインタフェースのＭＡＣアドレス 送信元：ReceiverのUDLインタフェースのＭＡＣアドレス – Receiverであらかじめデータリンクパケットを 作成し、Feederでそれをそのまま送信する Receiverのカプセル化 • ＵＤＬに送信するデータリンクパケット DL_hdr IP_hdr Data • ＧＲＥヘッダを付加 – Generic Routing Encapsulation – 拡張性 GRE_hdr DL_hdr IP_hdr Data • トンネル先に向けカプセル化 – Destination = トンネル先ＩＰアドレス – Protocol = GRE IP_hdr GRE_hdr DL_hdr IP_hdr Data Feederの脱カプセル化 • プロトコルフィールドがGREのパケットを 脱カプセル化 IP_hdr GRE_hdr DL_hdr IP_hdr Data DL_hdr IP_hdr Data ブロードキャストエミュレーション • 脱カプセル化したデータリンクパケットを 元のＩＰパケットの宛先ごとに処理を行う Default Feeder自身 ＵＤＬインタフェースの ＵＤＬ上のほかのノード ＵＤＬインタフェース からそのまま送信 ブロードキャストアドレス ＵＤＬインタフェース からそのまま送信 マルチキャストアドレス ＵＤＬインタフェース からそのまま送信 input queueに追加 パケットのコピーが loopbackに渡される マルチキャストグループに入っている場合、 パケットのコピーをloopbackに渡す Feederの実装 • 脱カプセル化、ブロードキャストエミュレー ション – ip_input()内に実装 • トンネリング機構はプロトコルフィールドを参照 • 移植性 – 既存の提案ではデータリンク層に実装すべき とされていた • ＵＤＬへの送信ルーチンを変更 – データリンクヘッダを付加しない • データリンクヘッダを付加せずに送信するパケット には、mbufのM_UDLRフラグをＯＮにする トンネルの自動設定 • トンネルの設定には、Default FeederのＢＤＬ インタフェースのＩＰアドレスが必要 • DTCP（Dynamic Tunneling Control Protocol） がＩＥＴＦで提案されている。 – Feederは一定時間ごとにBDLインタフェースのIP アドレスをブロードキャスト（HELLOメッセージ） ＤＴＣＰの動作 BDLのIPをbroadcast UDL ﾙｰﾀ ﾙｰﾀ ﾙｰﾀ Receiver Receiver BDL Internet トンネルを設定 Feeder ﾙｰﾀ Feeder ﾙｰﾀ Default Feeder 実験環境 • Ethernetを用いたLAN上でのシミュレーション •経路制御プロトコルはRIP2とOSPFv2 検証結果 • 経路制御プロトコルにより、ＵＤＬを使用し た経路を含む経路表が作成される – RIP2,OSPFv2の両方で、UDLを使用した経路を 含む経路表が作成された • Receiverから他のＵＤＬ上の終点ＩＰアドレ スへ到達性がある – Pingプログラムを用いて以下の到達性を確認 • FeederからReceiver • ReceiverからReceiver • Receiverからのブロードキャスト まとめ • 本機構の導入により、ＵＤＬを含むネット ワ ークで既存の経路制御プロトコルが正 しく動作することを確認した • これまで到達できなかったＵＤＬ上の終点 ＩＰアドレスに対し、Receiverからの到達性 を確認した 今後の課題 • トンネルを通してパケットを送信することに どれほどのオーバーヘッドがあるか – オーバーヘッドが多い場合、経路制御パケット 以外のトラフィックがトンネルに流れ込むのを 抑制する必要がある • Receiverは、Default Feederをどのように選 択すればよいのか – 最も効率よく利用できるDefault Feederをどの ように見つけるか