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