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

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

藤枝　俊輔（慶應義塾大学）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

InternetBDL

ﾙｰﾀﾙｰﾀﾙｰﾀ

ﾙｰﾀ

ＵＤＬを含むネットワークにおける経路制御の問題

• 動的な経路制御プロトコルが正しく動作しない– RIP– OSPF

• Receiver がＵＤＬ上の終点ＩＰアドレスに到達できない– ICMP エコー要求を利用して、 Feeder から Recei

ver へ到達性を確認できない

ＲＩＰを動作させた場合• ルータＡが隣接ルータＢを経由した経

路を利用するためには、事前にルータＢから経路情報を受け取る必要がある

• ＵＤＬでは Feeder は Receiver からの経路情報を受け取れない

Router B(Receiver)

Router A(Feeder)

経路情報

UDLﾙｰﾀ ﾙｰﾀ ﾙｰﾀ ﾙｰﾀ

ＯＳＰＦを動作させた場合

• ルータ間でコネクションを確立してから、その隣接ルータを経由した経路を使用する

• コネクションの確立には、ルータ間で互いにＨＥＬＬＯメッセージを受け取る必要がある

Router B(Receiver)

Router A(Feeder)

UDL

HELLO

HELLO

ﾙｰﾀ ﾙｰﾀ

ﾙｰﾀ ﾙｰﾀ

ＯＳＰＦを動作させた場合

• ルータ間でコネクションを確立してから、その隣接ルータを経由した経路を使用する

• コネクションの確立には、ルータ間で互いにＨＥＬＬＯメッセージを受け取る必要がある

Router B(Receiver)

Router A(Feeder)

UDL

HELLO

ﾙｰﾀ ﾙｰﾀ

ﾙｰﾀ ﾙｰﾀ

コネクションが確立されない

Receiver からＵＤＬ上の終点ＩＰアドレスへの到達性• Receiver は外部への送信に BDL を利用• 直接配送は間接配送よりも優先される• ＵＤＬ上の終点ＩＰアドレスにデータ

を送信する場合、 BDL を利用できない。

Receiver

InternetInternet

ﾙｰﾀﾙｰﾀ

Feeder/Receiver

ＵＤＬを含むネットワークにおける動的な経路制御の手法

• 経路制御プロトコルの改変– RIP,OSPF

– UDL に接続するノードと経路情報を交換する全てのルータで変更されたプロトコルが動作する必要

• トンネルを用いた解決法– Receiver から Feeder にトンネルを設置– 最新の提案がＩＥＴＦで議論されている (draft-i

etf-udlr-lltunnel-01.txt)– 実装が容易– Receiver と Feeder だけに変更を加えればよい

ﾙｰﾀ

ﾙｰﾀ

UDL

Receiver Receiver Receiver Feeder

InternetBDL

UDL に送信するパケットをトンネリング

脱カプセル化しデータリンクパケットをUDL に送信

全体図ブロードキャストエミュレーション

ﾙｰﾀﾙｰﾀ

ＤＴＣＰを用いて、トンネルを自動設定

仮想ブロードキャストリンク

• 現在の経路制御プロトコルがそのまま動作する環境を提供

• Receiver からＵＤＬ上の終点ＩＰアドレスへの到達性を実現

• ＵＤＬ上でブロードキャストリンクをエミュレーション

Ｄｅｆａｕｌｔ　Ｆｅｅｄｅｒ

• 既存の提案– 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 はＵＤＬに１つである必要はない。Receiver はそれぞれ個別に Default Feeder を選択する

想定するネットワーク環境• Receiver には効率的にパケットを送信

できる Feeder がある– 同じ管理ドメイン内の Feeder を利用

UDL

Receiver

Internet

BDL

Feederﾙｰﾀ ﾙｰﾀﾙｰﾀ

DefaultFeeder

Feederﾙｰﾀ

Internet

性能の比較

• それぞれの Feeder にトンネルを設定する場合、 Feeder がどのくらいの数までなら規模性を保てるのか

• Receiver からのパケットを中継する Feeder の負荷はどれくらいのものか

詳細な性能の測定は今後の課題

データリンクトンネリング• データリンクアドレス

– ＭＡＣアドレスを持つＵＤＬインタフェースが広まりつつある

• データリンクヘッダ– Feeder が Receiver からのパケットをＵＤＬに送信す

る場合

– Receiver であらかじめデータリンクパケットを　作成し、 Feeder でそれをそのまま送信する

宛先　：宛先 UDLインタフェースのＭＡＣアドレス

送信元：Receiver の UDLインタフェースのＭＡＣアドレス

Receiver のカプセル化

• トンネル先に向けカプセル化– Destination = トンネル先ＩＰアドレス

– Protocol = GRE

IP_hdr DataDL_hdr• ＧＲＥヘッダを付加

– Generic Routing Encapsulation– 拡張性

• ＵＤＬに送信するデータリンクパケット

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

ブロードキャストエミュレーション

• 脱カプセル化したデータリンクパケットを　　元のＩＰパケットの宛先ごとに処理を行う

Default Feeder 自身

ＵＤＬ上のほかのノード

ブロードキャストアドレス

マルチキャストアドレス

ＵＤＬインタフェースのinput queue に追加

パケットのコピーがloopback に渡される

ＵＤＬインタフェースからそのまま送信

ＵＤＬインタフェースからそのまま送信

ＵＤＬインタフェースからそのまま送信

マルチキャストグループに入っている場合、パケットのコピーを loopback に渡す

Feeder の実装• 脱カプセル化、ブロードキャストエミュレーショ

ン– ip_input()内に実装

• トンネリング機構はプロトコルフィールドを参照• 移植性

– 既存の提案ではデータリンク層に実装すべきとされていた

• ＵＤＬへの送信ルーチンを変更– データリンクヘッダを付加しない

• データリンクヘッダを付加せずに送信するパケットには、 mbuf の M_UDLR フラグをＯＮにする

トンネルの自動設定

• トンネルの設定には、 Default Feeder のＢＤＬインタフェースのＩＰアドレスが必要

• DTCP （ Dynamic Tunneling Control Protocol ）がＩＥＴＦで提案されている。– Feeder は一定時間ごとに BDL インタフェー

スの IP アドレスをブロードキャスト（ HELLO メッセージ）

ＤＴＣＰの動作

UDL

Receiver DefaultFeeder

Internet

BDL

Receiver FeederFeederﾙｰﾀ ﾙｰﾀ ﾙｰﾀ

ﾙｰﾀﾙｰﾀ

BDLの IPを broadcast

トンネルを設定

実験環境

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

検証結果• 経路制御プロトコルにより、ＵＤＬを使用し

た経路を含む経路表が作成される– RIP2,OSPFv2 の両方で、 UDL を使用した経路を含む経

路表が作成された

• Receiver から他のＵＤＬ上の終点ＩＰアドレスへ到達性がある– Ping プログラムを用いて以下の到達性を確認

• Feeder から Receiver

• Receiver から Receiver• Receiver からのブロードキャスト

まとめ

• 本機構の導入により、ＵＤＬを含むネットワ　ークで既存の経路制御プロトコルが正しく動作することを確認した

• これまで到達できなかったＵＤＬ上の終点　ＩＰアドレスに対し、 Receiverからの到達性を確認した

今後の課題

• トンネルを通してパケットを送信することにどれほどのオーバーヘッドがあるか–オーバーヘッドが多い場合、経路制御パケッ

ト以外のトラフィックがトンネルに流れ込むのを抑制する必要がある

• Receiver は、 Default Feeder をどのように選択すればよいのか– 最も効率よく利用できる Default Feeder をどの

ように見つけるか