WIDE Technical-Report in 2006

インターネット自動車のテスト
ベッドにおける複数 CoA 登録の導入と評価
wide-tr-icar-mcoa-testbed-01.pdf

WIDE Project : http://www.wide.ad.jp/

If you have any comments on this document, please contact to ad@wide.ad.jp

インターネット自動車のテストベッドにおける複数 CoA 登録の導入と評価
塚田 学 †, 三屋 光史朗 †, 湧川 隆次 †, 植原 啓介 †慶應義塾大学 政策・メディア研究科 †{tu-ka, mitsuya, ryuji } @sfc.wide.ad.jp,

1

はじめに

インターネット自動車プロジェクト [1](以下、 ICAR プロジェクト) は WIDE プロジェクト [2] 内において自動車をインターネットにつなげること、またその環境の上で考えられるアプリケーションに関する研究活動を 1996 年から行なってきた。
ICAR プロジェクトでは、ネットワーク層における移動体通信支援技術や、アプリケーション層におけるプローブ情報システムなどの研究活動が行なわれている。このように ICAR プロ
ジェクトにおいては、階層の異なる分野における協調が不可欠であるため、分野を越えた活動が必要である。これまでの活動で、ICAR アーキテクチャの基本的な部分は完成された。次に、各々の機能を個別に精査する必要性が出てきた。そのため、定常的に運用されるテストベッドを構築し、その上で評価を行っている。テストベッドは各分野の研究の連携を容易にするため、
図 1 のように、ネットワーク層やアプリケーション層などの層別にモジュール化されている [3]。

図 1: ICAR アーキテクチャ

一方、インターネット自動車は移動する計算機群であり、ICAR のアーキテクチャにおいて NEMO[4] が前提となっている[5] [6]。NEMO 機能を持つルータを Mobile Router (MR) といい、MR を車内に搭載することが想定されている。MR は Home
Agent (HA) と呼ばれるノードへ移動先のネットワーク上の位置を登録する。このネットワーク上の位置は、Care-of Address(CoA) と呼ばれる。この情報を元に MR と HA との間に双方向トンネルが確立される。MR は、無線 LAN や携帯電話の複数のネットワークインターフェイスを搭載して利用することが想定されている。しかし、NEMO 標準仕様では、複数の CoA を同時に HA に登録することができないため、同時に複数のネットワークインターフェイスを利用できない問題がある。このため、常にどちらか一つのネットワークインターフェイスを切替え利用することになる。上記の ICAR のテストベッドにおいても、MR は IEEE802.11b と PHS のネットワークインターフェ

kei@wide.ad.jp

イスを備えているが、その両方を同時に通信に利用することはできない。
この問題を解決するため、複数の CoA を同時に HA に登録する仕組みとして、複数 CoA 登録 [7] が提案されている。インターネット自動車の通信を複数のネットワークインターフェイスを用いて分散することができれば、通信の安定性の向上し、有効な帯域を増大する利点がある。しかし、複数 CoA 登録はHA への CoA の登録の手法であって、通信の分散の手法については対象外である。通信の分散の仕組みは、一般的に送受信アドレス、ポート番号、フローのタイプなどからユーザのポリシに応じて振り分ける方法が想定されていて、今後の議論が必要である。また、上記の手法は自動車内のネットワークの管理者はユーザのポリシを管理しなくてはならないため、ポリシ管理のオーバーヘッドが予想される。

本研究の目的と要件

2

複数 CoA 登録の実装は現在テスト段階であって、安定運用が可能であるか確かめられていない。本研究の目的は、インターネット自動車のテストベッドにおいて複数 CoA 登録を導入し、安定運用することである。また、複数 CoA 登録の運用上のメリットとデメリットを明らかにすることである。また、NEMO標準仕様と複数 CoA 登録とのネットワーク性能の比較し、評価する。
複数 CoA 登録の実装は現在テスト段階である一方、ICARテストベッドはアプリケーションなど、ネットワーク層以外においても運用が行われている。そのため、複数 CoA 登録の導入によって運用が停止してはならない。複数 CoA 登録の導入にあたって、その他の実験に支障のでないよう配慮する。
以下に本研究の目的と、複数 CoA 登録の導入の要件をまとめる。
目的• 複数 CoA 登録を安定運用できるか確かめること• 複数 CoA 登録の運用上のメリットとデメリットを明らかにすること• NEMO 標準仕様と複数 CoA 登録とのネットワーク性能の比較評価すること
要件• 複数 CoA 登録の導入によってその他の実験に支障のでな
いことCopyright Notice
Copyright (C) WIDE Project (2006). All Rights Reserved.

複数 CoA 登録の導入

3

ICAR テストベッドは、KAME プロジェクト [8] で開発したSHISA 実装 [9] を用いて構築されている。本章では、まず現在運用中の NEMO 標準仕様の HA と今回導入する複数 CoA 登録の HA の併設について述べる。その後、SHISA の概要について述べ、特に SHISA の複数 CoA 登録の実装について述べる。
その後、複数 CoA 登録を ICAR テストベッドへ導入するために必要な HA と MR の変更について述べる。

3.1

複数 CoA 対応の HA の設置

現在、NEMO 標準仕様で運用中のインターネット自動車に影響をあたえないため、現状の NEMO 標準仕様の HA は変更せず、新たに複数 CoA 登録の HA を設置する。同一のリンクが複数の HA の Home link になっている場合、動的 HA アドレス発見の仕組みに影響がでる可能性がある。HA が互いに影響しないように、図 2 に示すように、Home Link を分離して設置した。
HA-MCoA home link

HA-MCoA

HA-basic

Home agenet forMultiple CoA registration

Home agenet for
NEMO basic support

HA-basic home linktau41gw

IPv6 over IPv4
tunnel server

HA

図 2: HA の設置

複数 CoA 登録の実装概要

SHISA の基本的な実装概要は、付録 A に記述した。本節では本研究で行う変更を説明するため、複数 CoA 登録のパケットの流れを説明する。パケットの流れを図 3 に示した。図中のnemo0、nemo1、nemo2 はそれぞれ仮想トンネルインターフェイスである。HA と MR の間に確立されているトンネルは、HAアドレスと CoA を両端とし、Home Address と CoA の対ごとに確立される。
通信相手 (CN) から移動ネットワークノード (MNN) への通信はまず、インターネットの配送の仕組みによって HA へと配送される。HA では移動ネットワーク宛てのパケットを受け取る。HA 内部では Routing table が参照され、移動ネットワーク宛てのパケットを nemo0 のトンネルインターフェイスへと出力される。nemo0 から出力されたパケットは、ユーザのポリシに基づいて設定された IP Filter [10] のルールを評価して、希望の NEMO トンネルへと出力される。IP Filter のルールは送受信のアドレス、送受信のポート番号、フローのタイプなどによって区別される。
例えば、図 3 のように CN から MNN に (a) 送信先ポート22 番の通信と (b) UDP の通信が行われているとする。どちらnemo0IP Filter

routing
table

(a)

CN(b)

nemo1

nemo2

nemo1

nemo2

MRMNN
routingtable

(a)
(b)

送信先ポート 22番
UDP

図 3: CN から MNN へのパケットの流れ

図は省略するが、MNN から CN への通信も同様に、MR 内部では Routing table が参照され、移動ネットワークからのパケットを nemo0 のトンネルインターフェイスへと出力される。
nemo0 から出力されたパケットは、ユーザのポリシに基づいて設定された MR の IP Filter のルールを評価して、nemo1、nemo2などの希望の NEMO トンネルへと出力される。

導入に必要な HA の変更

3.3

Internet

3.2の通信も HA の Routing table を参照し、nemo0 へと出力されるが、IP Filter のルールに基づいてそれぞれ、nemo1、nemo2と別々のトンネルインターフェイスへと出力される。図 3 の例
では、(a) の通信は nemo1 を、(b) の通信は nemo2 を利用して移動ネットワークへと到達する。

インターネット自動車において、HA と MR の間に確立された複数のトンネルは、MR に備えられた無線ネットワークインターフェイスの電波状況などによって利用できなくなる。そのため、利用できるトンネルを把握し、利用できるトンネルに変更が会った場合は、変更に応じて IP Filter のルールを変更する必要がある。
HA 側では、Binding Cache (BC) の状態に応じて、IP Filterのルールを変更するため、IP Filter daemon (IPFD) を実装した。IPFD は図 4 の (a) に示すように HAD からのメッセージをモビリティソケットを通じて受信する。IPFD メッセージに含まれる Binding unique Identiﬁcation 番号 (BID) によって利用できるトンネルインターフェイスを把握する。その後、利用できるトンネルに応じた IPF のルールを適用する。

IPFD
IPF socket(b)setup
IPF rule

NEMONETD(a)HAD BC

Mobility Socket

user land

RAW socket for MH

Routing socket

setup tunnel
setup routeBC

図 4: HA の変更

Copyright Notice
Copyright (C) WIDE Project (2006). All Rights Reserved.

HA
kernelNIC
Binding Acknowlagement
etc....

導入に必要な MR の変更

3.4

MR 側でも同様に、利用できるトンネルを把握し、利用できるトンネルに変更が会った場合は、変更に応じて IP Filter のルールを変更する必要がある。
MR 側では、Binding Update List (BUL) の状態に応じて、IP Filter のルールを変更するため、IP Filter daemon (IPFD)を実装した。IPFD は図 5 の (a) に示すように MRD からのメッセージをモビリティソケットを通じて受信する。IPFD はメッセージに含まれる BID によって利用できるトンネルインターフェイスを把握する。その後、利用できるトンネルに応じた IPF のルールを適用する。
Binding Update
etc...

MR

setup tunnel
setup routesetup
IPF rule

NIC

BULuser land
Routing socket

MDD

(a)

IPF socket

MRD BUL

IPFD

Mobility Socket

NEMONETD

参考文献[1] イ ン タ ー ネット 自 動 車 プ ロ ジェク ト, January 2006.
http://www.sfc.wide.ad.jp/InternetCAR/.

[3] 遠山祥広 , 塚田学 , 植原啓介 , 砂原秀樹 , 村井純. イン
ターネット自動車のテストベッドの構築と評価, November
2004. 情報処理学会研究報告 第 6 回ユビキタスコンピュー
ティングシステム pp.37–pp.43.

ユーザの通信振り分けポリシ交換

今回実装した IPFD はユーザのポリシを IP Filter のルールとして定義したものを利用可能なトンネルの状態に応じて適応するプログラムである。ユーザのポリシはあらかじめ設定してあることを想定している。
インターネットから自動車内への通信は HA のポリシによって振り分けられ、自動車内からインターネットへの通信は MRのポリシによって振り分けられる。現状では、HA 側のポリシとMR 側のポリシを同期する仕組みは無く、互いに独立に設定される。そのため、HA と MR のどちらかのポリシを変更すればHA と MR のポリシに不整合が起こり、自動車内からインターネットへの通信と、インターネットから自動車内への通信で違う経路を経由する可能性がある。自動車内のネットワークを管理する者がポリシを設定するとき、HA 側と MR 側のポリシに不整合があれば、適切に管理者の意思を反映できない。よって、
HA 側と MR 側のポリシを同期させる仕組みが必要である。
ICAR プロジェクトでは、HA と MR のポリシの交換することで、HA 側と MR 側のポリシを同期させる仕組みを検討している。この仕組みは IPFD を拡張することで実現する。

5ICAR テストベッドは WIDE プロジェクト ICAR ワーキン
ググループの方々との共同作業で構築したものである。和泉順子氏、佐藤雅明氏の両 ICAR ワーキンググループ・チェアをはじめとする ICAR ワーキンググループメンバーの皆様に感謝の意を表します。特に過去 3 回行われた ICAR 合宿に参加された皆様に感謝いたします。また、島慶一氏、百瀬剛氏をはじめ SHISA開発メンバの皆様に感謝致します。

[2] WIDE project, January 2006. http://www.wide.ad.jp/.

図 5: MR の変更

4

謝辞

(b)

RAW socket for MH

kernel

用上のメリットとデメリットを明らかにすることである。ICARワーキンググループでは、複数 CoA 登録を用いたテストベッドを構築した。複数 CoA 登録の安定運用、性能評価については今後の課題として行っていく。

[4] Vijay Devarapalli, Ryuji Wakikawa, Alexandru Petrescu, and Pascal Thubert. Network Mobility (NEMO)
Basic Support Protocol, January 2005. IETF RFC3963.
[5] Thierry Ernst, Koshiro Mitsuya, and Keisuke Uehara. Network Mobility from the InternetCAR Perspective. JOIN: Journal on Interconnection Networks, 4(3),September 2003.
[6] K. Mitsuya, K. Uehara, and J. Murai. The in-vehicle
router system to support network mobility, October
2003. LNCS Vol. 2662, page. 633-642.
[7] Wakikawa Ryuji, Uehara Keisuke, Ernst Thierry, andNagami Kenichi. Multiple Care-of Addresses Registration, January 20 2005. IETF work in progress.
[8] KAMEプ ロ ジェク ト,
http://www.kame.net/.

January

2006.

[9] SHISA, January 2006. http://www.mobileip.jp/.
[10] IP
Filter,January
http://coombs.anu.edu.au/ avalon/.

まとめ

本レポートではインターネット自動車テストベッドにおいてネットワーク部分を NEMO 標準仕様から複数 CoA 登録へと置き換える手法について論じた。本研究の目的は複数 CoA 登録を導入し、安定運用することである。また、複数 CoA 登録の運Copyright Notice
Copyright (C) WIDE Project (2006). All Rights Reserved.

2006.

付録 A: SHISA の実装概要

HA

SHISA はカーネルにおける実装を最小限に押え、NEMO 機能を以下の 4 つのデーモンに分割した。Mobile Router Daemon(MRD)、Movement Detection Daemon (MDD)、NEMO network Daemon (NEMONETD)、Home Agent Daemon (HAD)である。そのなかで NEMONETD のみが、MR と HA の両方で動作する。SHISA は各デーモンが相互に作用することで NEMO機能を果たしている。デーモン間のメッセージングは新たに定義したモビリティソケットを用いて行なわれる。モビリティソケッ
トは、ノード情報や Binding の変更情報、移動の検知、Returning Home、経路最適化の情報などを交換するためのインターフェイスである。以下に 4 種類の各デーモンの説明を行なう。
• Mobile Router Daemon (MRD)
MR のみで動作するデーモン。おもに Binding の管理を行なう。BUL のタイムアウトのチェックを行ない、定期的にBinding Update を送信する。Binding の追加・更新・削除の情報はモビリティソケットを通じてカーネルへと通知される。

Routing socket

HAD BCRAW socket for MH

user land
kernelMobility Socket

setup tunnel
setup routeBCNIC

Binding Acknowlagement
etc....

InternetMR

setup tunnel
setup route

Binding Update
etc...

NIC

BUL

RAW socket for MH

Routing socket

Mobility Socket

MDD• Movement Detection Daemon (MDD)
MR のみで動作するデーモン。ルーティングソケットを監視し移動を検知する。移動情報はモビリティソケットを通じて MRD へと通知される。MDD は、移動を検知するために監視するインターフェイスを指定して実行される。
• NEMO network Daemon (NEMONETD)
MR、HA の両方で動作するデーモン。モビリティソケッ
トを監視することで、Binding の追加・更新・削除を検知する。モビリティソケットからの情報により、トンネルの生成・削除を行ない、ルーティングテーブルの経路を変更する。

NEMONETDNEMONETD

kerneluser land

MRD BUL

図 6: SHISA の実装概要

BC はライフタイムの期限が切れると HAD によって削除され、BUL はライフタイムが切れると MRD によって削除される。また、MDD は通信不能になったインターフェイスを検知するとモビリティソケットを用いて MRD へと通知を行ない、MRD は BUL を削除する。

• Home Agent Daemon (HAD)
HA のみで動作するデーモン。BC を管理する。また、Binding Update によって BC を追加・更新・削除を行ない、Binding Acknowledgement を送信する。BC の変更情報
はモビリティソケットを通じて、カーネルへと通知される。
以下に SHISA の動作概要を図 6 を用いて説明する。
まず、移動と Binding 登録における流れを説明する。MR 側
では、CoA を取得するとルーティングソケットを監視しているMDD が、移動を検知する。移動の情報や CoA や BID などの情報はモビリティソケットを通じて MRD へと通知される。MRDは取得した CoA を HA へ登録するため、Binding Update を行なう。
Binding Update を受け取った HAD は、Binding Cache の更新のメッセージや CoA、HoA などをモビリティソケットを通じてカーネルへと通知する。この時、NEMONETD はモビリティソケットのメッセージを検知し、CoA へのトンネルを生成し、トンネルの経路を加える。HAD は Binding 登録が正常に終了したことを MR へ通知するため、Binding Acknowlegdementを行なう。
Binding Acknowlegdement を受け取った MRD ではカーネ
ルの BUL を更新するため、更新のメッセージなどをカーネルへと通知する。この時、NEMONETD はモビリティソケットのメッセージを検知し、HA address へのトンネルを生成し、トンネルの経路を加える。

Copyright Notice
Copyright (C) WIDE Project (2006). All Rights Reserved.