仮想ブロードキャストリンクを利用した 片方向通信路の透過的経路制御 藤枝 俊輔（慶應義塾大学） 藤枝　俊輔（慶應義塾大学） 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は外部への送信にBDLを利用 直接配送は間接配送よりも優先される ＵＤＬ上の終点ＩＰアドレスにデータを送信する場合、BDLを利用できない。 Receiver Feeder/Receiver Internet Internet

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

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

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

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

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

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

ReceiverごとにDefault Feederを選択 UDL Receiver Receiver Feeder Default Feeder Default Feeder BDL Internet

想定するネットワーク環境 Receiverには効率的にパケットを送信できるFeederがある UDL BDL Default Feeder Receiver BDL Internet Internet

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

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

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メッセージ）

ＤＴＣＰの動作 UDL BDL BDLのIPをbroadcast 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をどのように見つけるか