仮想ブロードキャストリンクを利用した片方向通信路の透過的経路制御

仮想ブロードキャストリンクを利用した 片方向通信路の透過的経路制御藤枝　俊輔（慶應義塾大学） sirokuma@sfc.wide.ad.jp

概要 • 既存の経路制御技術は通信媒体の双方向性を前提としている • 片方向の通信路をインターネットで利用する場合に生じる経路制御の問題を解決 • 片方向通信路上に仮想のブロードキャストリンクを構築し、既存の経路制御プロトコルがそのまま動作する環境を提供

片方向通信路 • 衛星回線 • ＣＡＴＶ網片方向通信路 Uni-directional Link (UDL) 双方向回線を用いた通信路 Bi-directional Link(BDL)

片方向通信路の利用 • インターネットのトラフィック傾向 • サーバからクライアントへ • www • ftp • トラフィック全体にも偏りがある

片方向通信路の利用 • 衛星回線 • 広域性、同報性 • ＣＡＴＶ綱 • 既に設置された通信路の有効利用 Feeder Receiver UDL

ＵＤＬを含むネットワーク • 少数のFeederと多数のReceiverが接続するのが一般的 • Receiverは外部への送信にＢＤＬを利用する UDL Receiver Receiver Receiver Feeder BDL Internet

ＵＤＬを含むネットワークにおける経路制御の問題ＵＤＬを含むネットワークにおける経路制御の問題 • 動的な経路制御プロトコルが正しく動作しない • RIP • OSPF • ReceiverがＵＤＬ上の終点ＩＰアドレスに到達できない • ICMPエコー要求を利用して、FeederからReceiverへ到達性を確認できない

ＲＩＰを動作させた場合 • ルータＡが隣接ルータＢを経由した経路を利用するためには、事前にルータＢから経路情報を受け取る必要がある • ＵＤＬではFeederはReceiverからの経路情報を受け取れない Router B (Receiver) Router A (Feeder) 経路情報 UDL

ＯＳＰＦを動作させた場合 • ルータ間でコネクションを確立してから、その隣接ルータを経由した経路を使用する • コネクションの確立には、ルータ間で互いにＨＥＬＬＯメッセージを受け取る必要がある Router B (Receiver) Router A (Feeder) HELLO UDL HELLO

ＯＳＰＦを動作させた場合 • ルータ間でコネクションを確立してから、その隣接ルータを経由した経路を使用する • コネクションの確立には、ルータ間で互いにＨＥＬＬＯメッセージを受け取る必要がある Router B (Receiver) Router A (Feeder) HELLO UDL コネクションが確立されない

ReceiverからＵＤＬ上の終点ＩＰアドレスへの到達性ReceiverからＵＤＬ上の終点ＩＰアドレスへの到達性 • Receiverは外部への送信にBDLを利用 • 直接配送は間接配送よりも優先される • ＵＤＬ上の終点ＩＰアドレスにデータを送信する場合、BDLを利用できない。 Receiver Feeder/Receiver Internet Internet

ＵＤＬを含むネットワークにおける動的な経路制御の手法ＵＤＬを含むネットワークにおける動的な経路制御の手法 • 経路制御プロトコルの改変 • RIP,OSPF • UDLに接続するノードと経路情報を交換する全てのルータで変更されたプロトコルが動作する必要 • トンネルを用いた解決法 • ReceiverからFeederにトンネルを設置 • 最新の提案がＩＥＴＦで議論されている (draft-ietf-udlr-lltunnel-01.txt) • 実装が容易 • ReceiverとFeederだけに変更を加えればよい

全体図 UDLに送信するパケットをトンネリングブロードキャストエミュレーション UDL 脱カプセル化しデータリンクパケットを UDLに送信 Receiver Receiver Receiver Feeder BDL Internet ＤＴＣＰを用いて、トンネルを自動設定

仮想ブロードキャストリンク • ＵＤＬ上でブロードキャストリンクをエミュレーション • 現在の経路制御プロトコルがそのまま動作する環境を提供 • ReceiverからＵＤＬ上の終点ＩＰアドレスへの到達性を実現

Ｄｅｆａｕｌｔ　Ｆｅｅｄｅｒ • 既存の提案 • ReceiverからのBroadcast、Multicast、他のReceiverへのトンネル先 • 各Feederへの送信は個別にトンネルを使用 • 本設計 • Feederへの送信を含め、UDLへの送信全てをDefault Feederにトンネリング

既存の提案でのトンネリング UDL Receiver Receiver Feeder Feeder Default Feeder BDL Internet

本機構でのトンネリング UDL Receiver Receiver Feeder Feeder Default Feeder BDL Internet

ReceiverごとにDefault Feederを選択 Default FeederはＵＤＬに１つである必要はない。 Receiverはそれぞれ個別にDefault Feederを選択する UDL Receiver Receiver Feeder Default Feeder Default Feeder BDL Internet

想定するネットワーク環境 • Receiverには効率的にパケットを送信できるFeederがある • 同じ管理ドメイン内のFeederを利用 UDL Feeder Feeder Default Feeder Receiver BDL Internet Internet

性能の比較 • それぞれのFeederにトンネルを設定する場合、Feederがどのくらいの数までなら規模性を保てるのか • Receiverからのパケットを中継するFeederの負荷はどれくらいのものか詳細な性能の測定は今後の課題

データリンクトンネリング • データリンクアドレス • ＭＡＣアドレスを持つＵＤＬインタフェースが広まりつつある • データリンクヘッダ • FeederがReceiverからのパケットをＵＤＬに送信する場合 • Receiverであらかじめデータリンクパケットを　作成し、Feederでそれをそのまま送信する宛先　：宛先UDLインタフェースのＭＡＣアドレス送信元：ReceiverのUDLインタフェースのＭＡＣアドレス

Receiverのカプセル化 • ＵＤＬに送信するデータリンクパケット • トンネル先に向けカプセル化 • Destination = トンネル先ＩＰアドレス • Protocol = GRE DL_hdr IP_hdr Data • ＧＲＥヘッダを付加 • Generic Routing Encapsulation • 拡張性 GRE_hdr DL_hdr IP_hdr Data 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

ブロードキャストエミュレーション • 脱カプセル化したデータリンクパケットを　　元のＩＰパケットの宛先ごとに処理を行うＵＤＬインタフェースの input queueに追加 • Default Feeder自身 • ＵＤＬ上のほかのノード • ブロードキャストアドレス • マルチキャストアドレスＵＤＬインタフェースからそのまま送信パケットのコピーが 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 Feeder Feeder Default Feeder BDL Internet トンネルを設定

実験環境 • Ethernetを用いたLAN上でのシミュレーション • 経路制御プロトコルはRIP2とOSPFv2

検証結果 • 経路制御プロトコルにより、ＵＤＬを使用した経路を含む経路表が作成される • RIP2,OSPFv2の両方で、UDLを使用した経路を含む経路表が作成された • Receiverから他のＵＤＬ上の終点ＩＰアドレスへ到達性がある • Pingプログラムを用いて以下の到達性を確認 • FeederからReceiver • ReceiverからReceiver • Receiverからのブロードキャスト

まとめ • 本機構の導入により、ＵＤＬを含むネットワ　ークで既存の経路制御プロトコルが正しく動作することを確認した • これまで到達できなかったＵＤＬ上の終点　ＩＰアドレスに対し、Receiverからの到達性を確認した

今後の課題 • トンネルを通してパケットを送信することにどれほどのオーバーヘッドがあるか • オーバーヘッドが多い場合、経路制御パケット以外のトラフィックがトンネルに流れ込むのを抑制する必要がある • Receiverは、Default Feederをどのように選択すればよいのか • 最も効率よく利用できるDefault Feederをどのように見つけるか

仮想ブロードキャストリンクを利用した 片方向通信路の透過的経路制御