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をどの
ように見つけるか

Download Report