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

Preview:

DESCRIPTION

仮想ブロードキャストリンクを利用した 片方向通信路の透過的経路制御. 藤枝 俊輔(慶應義塾大学) sirokuma@sfc.wide.ad.jp. 概要. 既存の経路制御技術は通信媒体の双方向性を前提としている 片方向の通信路をインターネットで利用する場合に生じる経路制御の問題を解決 片方向通信路上に仮想のブロードキャストリンクを構築し、既存の経路制御プロトコルがそのまま動作する環境を提供. 片方向通信路. 衛星回線 CATV網. 片方向通信路 Uni-directional Link (UDL). 双方向回線を用いた通信路 - PowerPoint PPT Presentation

Citation preview

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

藤枝 俊輔(慶應義塾大学)sirokuma@sfc.wide.ad.jp

概要

• 既存の経路制御技術は通信媒体の双方向性を前提としている

• 片方向の通信路をインターネットで利用する場合に生じる経路制御の問題を解決

• 片方向通信路上に仮想のブロードキャストリンクを構築し、既存の経路制御プロトコルがそのまま動作する環境を提供

片方向通信路

• 衛星回線• 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 をどの

ように見つけるか

Recommended