卒業制作 2004 年度 (平成 16 年度)

Mobile Network におけるインターネット接続性の動的共有に関する研究

指導教員
徳田 英幸
村井 純
楠本 博之
中村 修
南 政樹
慶應義塾大学 環境情報学部
塚田 学

t01613mt@sfc.keio.ac.jp
平成 17 年 1 月 31 日

概要
移動する計算機が増えるに従い、Mobile IPv6 や Network Mobility(NEMO) などの移動体通信技術の必要性が高まってきた。特に ITS の分野では、自動車に搭載されている機器を移動する計算機群と捉え、通信を行なう需要が高まっている。
移動体計算機群では、インターネット接続性を持つ計算機と持たない計算機が混在する。現状では、これらの計算機は、Mobile Router(MR) と呼ばれる一台のルータを経由してインター
ネットに接続される。そのため、移動計算機群の通信は一台の計算機の持つ接続性に依存したものとなる。
本研究では、例えば、PDA や携帯電話など移動ネットワーク内において接続性を持つ計算機を MR として動作させることで、移動計算機群の通信において複数の計算機が持つインター
ネット接続性を利用できるようにすることを目的とする。複数の MR を同時に利用可能にすることで冗長な通信を実現し、トラフィックを振り分けることで、有効な帯域を増大する。
これらを実現するため、複数 MR の接続性情報を動的な情報交換、協調して動作するモデルを提案した。その後、モデルに従いシステムの設計と実装を行ない、実験環境にて実装の評価を行なった。
本研究の結果、移動体計算機群において複数のインターネット接続を同時に利用できることを実証した。またユーザーのポリシに応じた接続経路の使い分け、および経路多重化による通信帯域を増加を実証した。本研究により、移動ネットワークに持ち込まれた複数のインターネッ
ト接続を有効に利用することが可能になった。

キーワード

1. IPv6 2. Network Mobility, 3. Multihoming, 4. Mobile IPv6, 5. インターネット自動車, 6.
インターネット
慶應義塾大学 環境情報学部
塚田 学

abstract
The needs toward mobile telecommunications technologies such as Mobile IPv6 and Network Mobility(NEMO) have increased as the number of mobile computers increases. Especially in Intelligent Transportation Systems(ITS) area, there is a strong demand toward
communication technology which allows group of equipment installed on automobiles.
In a group of moving computers, some computers connect the Internet and others do not.
These computers access the Internet via a computer which is called Mobile Router(MR).
Therefore, group of moving computers communicate by connectivity of a MR.
This study aims making multiple MRs available through the use of multiple computerswhich are operating as MRs in the mobile network. Utilization of multiple MRs increases theredundancy and available bandwidth of the communication.
To achieve this purpose, we propose a model that multiple MRs exchange own connectivity
information each other and share the information. The MRs collaborate each other to sharethe connectivity based on the information. After that we design and implement the modeland evaluate the system in test environment.
From this study, we were available multiple MR in Mobile Network. And we bear out thissystem are able to divide packet to different routes based on user policy. Beside we bear out
this system increase available bandwidth. Mobile Network can increase redundancy and get
benefit from multiple access technologies.

Keywords
1. IPv6, 2. Network Mobility, 3. Multihoming, 4. Mobile IPv6, 5. Internet CAR 6. The
Internet
Faculty of Environmental Information, Keio University
Manabu Tsukada

目次
第1章
1.1
1.2
1.3

序論
本研究の背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
本研究の目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
1
2
2

第 2 章 現状の移動計算機群環境と問題点
2.1 想定されるインターネット利用と目指すインターネット利用 . . . . . . . . . .
2.2 Network Mobility (NEMO) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 NEMO basic support . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 NEMO における Multihoming . . . . . . . . . . . . . . . . . . . . . . .
2.3 複数 MR モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 一般的な複数 MR モデル . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 本研究のターゲット . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 要求事項の整理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 本研究の前提に基づく要求 . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 Multihoming の問題点に基づく要求 . . . . . . . . . . . . . . . . . . . .
2.4.3 今後の移動体通信環境に基づくの要求 . . . . . . . . . . . . . . . . . .
2.4.4 要求事項のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3
3
4
5
6
8
8
9
11
11
11
12
13
13

第 3 章 関連研究
3.1 Mobile IPv6 の拡張技術 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Multiple Gateway in Mobile Network (MGMN) . . . . . . . . . . . . .
3.1.3 Default Router Selection . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4 Mobile IP SHAKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 NEMO の拡張技術 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 MR registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 複数 CoA 登録の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 関連研究のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14
14
14
15
17
17
18
19
20
22

第 4 章 要求事項を満たすモデルの提案
4.1 アプローチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 複数の binding を管理する機構の考察 . . . . . . . . . . . . . . . . . . .
4.1.2 エンドノードに追加の機能を必要としないモデルの考察 . . . . . . . . .
4.1.3 方針のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24
24
24
26
26

i

Mobile Network における接続性の動的共有モデル . . . . . . . . . . . . . . . .
4.2.1 複数 CoA 登録の拡張 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 バーチャルインターフェイス追加モデルの提案 . . . . . . . . . . . . . .
4.2.3 MR 間の動的な情報共有モデルの提案 . . . . . . . . . . . . . . . . . . .
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27
27
28
29
29

第 5 章 Multiple Mobile Router Management(MMRM) の設計
5.1 MMRM 設計概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 MMRM の用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 動作概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 本研究で定義したデータフォーマット . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Neighbor Egress interface List の定義 . . . . . . . . . . . . . . . . . . .
5.2.2 NEL Advertisement の定義 . . . . . . . . . . . . . . . . . . . . . . . .
5.3 MMRM の動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Neighbor Egress interface List の同期に関する流れ . . . . . . . . . . .
5.3.2 ポリシールーティングに関する流れ . . . . . . . . . . . . . . . . . . . .
5.3.3 冗長経路を用いた利用不可能な経路の検知 . . . . . . . . . . . . . . . .
5.3.4 冗長経路を利用した Binding Update . . . . . . . . . . . . . . . . . . .
5.3.5 送信元または送信先が MR の通信 . . . . . . . . . . . . . . . . . . . . .
5.3.6 複数経路を用いた負荷分散 . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31
31
31
32
34
34
34
35
35
36
37
38
39
40
40

第 6 章 Multiple Mobile Router Management の実装
6.1 実装環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 実装概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 MR 側の MMRMD 実装概要 . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 HA 側の MMRMD 実装概要 . . . . . . . . . . . . . . . . . . . . . . . .
6.3 MR 側の MMRMD の機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 Neigbor Egress interface List の同期 . . . . . . . . . . . . . . . . . . .
6.3.2 複数トンネルの管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.3 ポリシールーティング . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 HA 側の MMRMD の機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42
42
42
42
43
44
44
46
47
48

第 7 章 評価
7.1 評価環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1 評価環境の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.2 評価環境のネットワーク性能 . . . . . . . . . . . . . . . . . . . . . . .
7.2 定性的評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1 評価実験の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.2 定性評価のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 定量的評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 スループットの計測 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.2 オーバヘッドの計測 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50
50
50
51
52
52
56
56
57
58

4.2

4.3

ii

7.3.3 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59
59

第 8 章 結論
8.1 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61
61
61

付 録A
A.1 SHISA の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 ORF2004 でのデモンストレーション展示 . . . . . . . . . . . . . . . . . . . . .

66
66
68

7.4

iii

図目次
2.1
2.2
2.3
2.4
2.5
2.6

現状のインターネット自動車 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
現状の問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
実現するインターネット利用環境 . . . . . . . . . . . . . . . . . . . . . . . . .
Network Mobility の移動透過処理 . . . . . . . . . . . . . . . . . . . . . . . . .
Multihoming における問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . .
複数 MR モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4
4
4
6
8
9

3.1
3.2
3.3
3.4
3.5
3.6

Mobile IPv6 の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MGMN の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mobile IP SHAKE の移動端末管理 . . . . . . . . . . . . . . . . . . . . . . . .
Mobile IP SHAKE の通信経路 . . . . . . . . . . . . . . . . . . . . . . . . . . .
MR registration の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
複数 CoA 登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15
16
18
18
19
21

4.1
4.2

MR registration モデルと複数 CoA 登録モデルの比較 . . . . . . . . . . . . . .
バーチャルインターフェイス追加モデル . . . . . . . . . . . . . . . . . . . . .

25
28

5.1
5.2
5.3
5.4
5.5
5.6
5.7

NEL Advertizement による Egress インターフェイスの情報交換 . . . . . . . .
PMR による経路選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PMR によるポリシールーティング . . . . . . . . . . . . . . . . . . . . . . . .
冗長経路を用いた利用不可能な経路の検知 . . . . . . . . . . . . . . . . . . . .
冗長経路を利用した Binding Update . . . . . . . . . . . . . . . . . . . . . . .
送信元または送信先が MR の通信の例 . . . . . . . . . . . . . . . . . . . . . .
PMR のパケット振り分けによる負荷分散 . . . . . . . . . . . . . . . . . . . . .

32
33
36
38
39
40
41

6.1
6.2
6.3
6.4
6.5

MMRM の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NEL の同期 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
複数トンネルの制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ポリシールーティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HA 側の MMRMD の機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43
45
46
47
48

7.1
7.2
7.3
7.4
7.5

定性評価の実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
実験環境のスループットおよび RTT の計測 . . . . . . . . . . . . . . . . . . .
通信の分配ポリシ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tracerout6 による経路の表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
実験のトポロジ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50
51
53
53
54

iv

7.6 tracerout6 による経路の表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.7 実験のトポロジ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.8 スループットの計測 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.9 利用する接続性を変更する実験 . . . . . . . . . . . . . . . . . . . . . . . . . .
7.10 実験のトポロジ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.11 MMRM の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.12 オーバーヘッドの計測 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54
55
55
56
57
58
59

SHISA トレードマーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SHISA の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ORF でのデモンストレーション展示 2004/11/24 . . . . . . . . . . . . . . . .
デモンストレーション概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66
67
68
69

A.1
A.2
A.3
A.4

v

表目次
2.1

要求事項のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.1

関連研究の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.1
4.2
4.3

方針のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
要求事項と複数 CoA 登録の関連 . . . . . . . . . . . . . . . . . . . . . . . . . .
本研究のアプローチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27
28
30

5.1
5.2

Neighbor Egress interfaces List . . . . . . . . . . . . . . . . . . . . . . . . . .
NEL Advertisement のフォーマット . . . . . . . . . . . . . . . . . . . . . . .

34
35

7.1
7.2

定性的評価の各 PC の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
要求事項の充足 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52
56

vi

第 1 章 序論
本章では、本研究の背景および目的について述べる。また、本論文の構成について述べる。

1.1

本研究の背景無線でのインターネット接続が整備されるに従い、計算機は場所を選ばずにインターネットへ接続できるようになった。そのため、移動中においても計算機をインターネットに接続する
ことへの要求が高まっている。
しかし、移動する計算機をインターネットへ接続すると、既存のインターネットアーキテク
チャでは移動に起因して IP アドレスが変化してしまう。これにより計算機が移動するたびに継続中のセッションが遮断されたり、通信相手が特定できない問題が発生する。これらの問題を解決するため、Mobile IPv6[1] という移動体通信技術が提案された。
Mobile IPv6 は移動するホストごとに問題を解決する仕組みを必要とするため、ホスト全てに Mobile IPv6 の技術を組み込む必要が生じる。計算機を群として捉え移動をサポートするた
めに Mobile IPv6 を拡張した Network Mobility(NEMO)[2] が提案された。NEMO では 1 つの計算機が計算機群を代表して移動体通信機能を担当する。これにより、計算機群内のすべての計算機に移動体通信機能を組み込む必要が生じない。
現在、多数の計算機からなる集合が持ち運ばれる場面は頻繁に見受けられる。例えば、バッ
グの中に携帯電話や PC、PDA、携帯ゲーム機などを入れ持ち運ぶような場合や、バス、電車、飛行機などにおいて乗客のもつ計算機が集団で移動している場合に、NEMO による移動体通信機能は有効である。
また、ITS 分野 [3] で注目が集まっているインターネット自動車 [4] は移動する計算機群であり、インターネット自動車のアーキテクチャにおいては NEMO が前提となっている [5]。NEMO機能を持つルータを Mobile Router(MR) といい、MR を車内に搭載することが想定されている。
一方、無線によるインターネット接続は安定性に欠ける。そのため、例えば、自動車内から
インターネットを利用して自宅の家族とテレビ電話するような場合、通信が途切れたりする。
あるインターネット接続性が利用できなくなった際、別のインターネット接続性を用いて通信を継続できれば、通信の安定性は向上する。また、無線によるインターネット接続は帯域も十分でない。そのため、自動車におけるテレビ電話は低画質となる。複数のインターネット接続性を同時に利用可能であれば、より高画質でのテレビ電話を用いたコミュニケーションが可能となる。
通信をより安定させ、帯域を増大するため、MR に複数のインターフェイスを搭載する研究などが進められている。しかし、無線によるインターネット接続の安定性や帯域の問題を完全に解決するには至っていない。
NEMO 基本サポートはその仕様上、車内の計算機は一台の MR 経由してインターネットに接続される。そのため、車内にインターネット接続性を持つ計算機が複数搭載されている場合

1

においても、安定性の向上や帯域の増大は達成できない。移動ネットワークに複数の MR を設置し、状況に応じて接続性を使い分けることができれば、安定性の向上と帯域の増大を達成できる。しかし、現状の NEMO においてはそのような仕組みは存在しない。

1.2

本研究の目的今後のインターネット自動車は、インターネット接続性を持つ計算機と持たない計算機の混在した計算機群となる。
本研究は、移動計算機群において計算機の接続性が存在する時、すべての計算機がその接続性を利用できるようにする。また、移動計算機群において複数の接続性がある時、トラフィッ
クを分散することができるようにする。
本研究では複数の計算機の持つ接続性を有効に利用するため、複数 MR が協調して動作するモデルを提案する。そして、本研究はそのモデルを実現するために生じる技術的な問題を整理し、解決方法を示す。また、解決方法に基づいたシステムの設計・実装を行ない、その有用性を示すため、評価を行なう。
本システムによって、移動計算機は安定した、広帯域の通信を行なうことが可能となる。

1.3

本論文の構成第 2章では、本研究で想定する環境を述べ、本研究分野における本研究の位置づけの説明を行なう。その後、問題点をまとめ要求事項を整理する。第 3章では、関連研究について説明を行なう。またそれぞれの技術と本研究の要求事項との関係を考察する。第 4章では、要求事項を満たすための方針を決定する。そのため、要求事項を満たすための機能ごとに考察を行なう。
方針から、要求を満たすモデルを Multiple Mobile Router Management (MMRM) として提案する。第 5章では、提案したモデルに従い MMRM の設計を行なう。第 6章では、本研究で実装した MMRM デーモンを説明する。第 7章では、定性的評価と定量的評価について述べる。第8章において、本研究のまとめと今後の課題について述べる。

2

第 2 章 現状の移動計算機群環境と問題点
本章ではまず、本研究おいて想定する移動計算機群環境について述べる。次に、NEMO の基本的な技術の仕様である NEMO 基本サポートの概要を述べ、拡張の仕様である Multihomingについて述べる。その後、複数 MR の問題点を整理する。最後にこれらの問題点を解決するため、本研究の要求事項を整理する。

2.1

想定されるインターネット利用と目指すインターネット利用

インターネット自動車プロジェクトや、InternetITS プロジェクトにおいては、IPv6 を用いて自動車と社会との接続を目指している。
無線技術の普及により、持ち運び可能な計算機もインターネットへ参加することが可能となる。これらの計算機には移動体通信技術が組み込まれる。携帯電話や PDA などのホストには
Mobile IPv6 が組み込まれ、自動車や電車、飛行機などの計算機ネットワークには NEMO のプロトコルスタックが組み込まれる。これらの技術により、移動体は異なるネットワークを移動しても着信可能性と移動透過性を保証される。これにより、ユーザは移動中も途切れることなく通信を行なうことが可能となる。
インターネット自動車では、自動車内部の計算機がインターネットに接続され、自動車の持つ情報を互いに交換する。運転者達が各自動車の情報を共有することで、より安全で快適な交通が実現する。そのために、自動車に搭載される GPS センサやスピードセンサ、ブレーキセンサなどがのセンサ類をインターネットに接続する必要がある。また、搭乗者によって PDA、
携帯電話、PC などが持ち込まれる。現状のインターネット自動車においては、図 2.1に示した
ように、車内の計算機は MR の持つ無線 LAN や PHS などの複数メディアを利用してインター
ネットへ接続する。
しかし、現状のインターネット自動車には、図 2.2に示すように車内のすべての計算機は MRを経由した通信を行なうため、一台の MR の持つ接続性に依存した通信となる問題がある。例
えば、図 2.2において、車内のすべての計算機は (2) に示す接続性のみ利用可能である。一方、携帯電話や PDA など搭乗者が持ち込む計算機は、図 2.2の (1) に示すように個別に接続性を持つ。しかし、これらの図 2.2の (1) に示す接続性は直接接続性を持つ計算機のみが利用可能であり、また着信可能性や移動透過性が保証されない。
そこで図 2.3に、本研究で目指すインターネット利用環境を示す。車内に持ち込まれた PDA
や携帯電話などの計算機を MR として動作させ、車内に複数 MR を設置することで、一台のMR の接続性に依存しない通信を実現する。例えば図 2.3において、車載ルータと携帯電話、
PDA を MR として動作させ、これらの計算機の持つ接続性を車内のすべての計算機が利用可能にする。これにより、通信の安定性を向上し、計算機の通信が利用可能な帯域を増大する。

3

Internet

Internet
IEEE802.11b

(2)

(1)

PHS

leave
Mobile Router

Mobile Router

Mobile Network

join

sensors
PDA

MobilephonesMobilephones

PCs

PDA

PC

sensors

Mobile Network

Mobile Network

図 2.1: 現状のインターネット自動車

図 2.2: 現状の問題点

Internet
leave

IEEE802.11g

IEEE802.11b

join
Mobile Router

Mobile Router
Mobile Router

sensors

PC

Mobile Network

図 2.3: 実現するインターネット利用環境

2.2

Network Mobility (NEMO)

NEMO は移動計算機群の通信に不可欠で、本研究の目指すインターネット利用環境に深く関わる。そのため、本節では NEMO の標準化状況や基本的動作などを紹介する。
NEMO は次世代インターネット環境における移動体通信技術として標準化に向けて IETF[6]において NEMO Working Group(NEMO WG)[7] で議論されている。NEMO の利用は広範囲にわたることが想定され、早期の仕様の決定が望まれている。そのため NEMO WG では標準化の議論を簡略化し、早期に仕様の決定を行なうため、NEMO の仕様を NEMO 基本サポートと NEMO 拡張サポートに区別した。その上で、NEMO 基本サポートを先に標準化することを目指している。

4

2.2.1NEMO basic support

現在、NEMO 基本サポートの仕様は決定されつつある。本節では NEMO 基本サポートについて解説を行なう。以下に用語の説明を記し、図 2.4 に Network Mobility を用いた移動透過処理の流れを示す。
以下に NEMO の用語を示す。

• Mobile Network (NEMO)
NEMO によって移動透過性・着信可能性をもつネットワーク。
• Mobile Router(MR)Mobile Network を提供しているルータ。
• Home Agent(HA)
Mobile Network のインターネット上の位置を把握している計算機。
• Mobile Network Node(MNN)
Mobile Network 内のノード。
• Correspondent Node(CN)通信相手の計算機。
• Home Link
HA が接続したリンク。
• Foreign Link
MR の移動先のリンク。
• Egress インターフェイス
MR の持つインターネットへ接続されたインターフェイス。
• Ingress インターフェイス
MR の持つ Mobile Network 側のインターフェイス。
• Mobile Network Prefix (MNP)
Mobile Network に広告されているネットワークプレフィクス。
• Home Address
MR を識別するための不変の IP アドレス。
• Care of Address(CoA)
移動先のネットワークで与えられる IP アドレス。
• BindingHome Address と CoA の対応付け。MR の CoA は移動によって変化するが、HA は Home
Address と CoA を対応付けることで転送先を識別する。HA は対応付けのデータを Binding
Cache (BC) によって管理する。MR は BC を更新するため HA に CoA を通知する。このメッセージを Binding Update といい、HA は MR へ登録が正常に終了したことを伝える。このメッセージを Binding Acknowledgement と呼ぶ。また、MR は Binding Updateを行なう計算機を Binding Update List (BUL) によって管理する。
5

Correspondent Node

CN
Home Agent

Foreign link

HA
Internet

Home linkARAR
2.update
Mobile Router

MR
MNN

MR

MNN
1.moveMobile Network Node

図 2.4: Network Mobility の移動透過処理
図 2.4に NEMO の概要を示す。Mobile Router(MR) は常に不変のネットワークである Mobile
Network を Mobile Network Node(MNN) に提供している。MR は異なるリンクへ移動すると移動先のネットワークで取得した Care of Address(CoA) を Home Agent(HA) に通知する。これにより、HA は MR の下にある Mobile Network のネットワーク上の位置を把握する。その後、その Mobile Network 宛のパケットを MR に転送することによって Mobile Network はネットワーク上の移動を実現している。HA はパケット転送を行なう際、パケットに IP ヘッダを加える IP-in-IP カプセル化という処理を行なう。この処理のことをトンネルを生成するという。
トンネルの処理は MR から HA に転送される際にも行なわれる。この HA と MR でのヘッダを脱着する処理は Bi-directional トンネルリングと呼ばれる。

2.2.2

NEMO における Multihoming

本研究で目指す複数 MR の協調は、NEMO 拡張サポートに含まれる。また、そのなかでも特に Multihoming と呼ばれる分野に含まれる。そのため、本節では NEMO における Multihomingの活動を紹介する。
IETF において Multihoming は NEMO 拡張サポートとして議論されている。Multihomingが目指す利点は draft-ernst-generic-goals-and-benefits-00[8] に述べられている。Multihomingの利点を要約すると以下の通りである。

• 常時接続性の向上• 通信の安定性の向上• 通信の負荷分散• 複数経路通信 (Bi-casting)6• 経路選択の可能化• 通信の帯域の増大
また、draft-ietf-nemo-multihoming-issues-01[9] において、NEMO における Multihoming の分析が行なわれている。文献 [9] では、Multihoming を MR、HA、MNP が単一であるか複数であるかによって分類し、8 通りの Multihoming の形態を定義している。文献 [9] では、例えば MR が 1 つ、HA が 1 つ、MNP が 1 つのモデルである NEMO 基本サポートは、(M R, HA, M N P ) = (1, 1, 1)のように表すことができる。また、MR が複数、HA が複数、MNP が 1 つのモデルは(M R, HA, M N P ) = (n, n, 1)というように表すことが可能となる。また、文献 [9] では Multihoming において想定される問題を図 2.5の 13 通りに分類している。文献 [9] は、8 通りの Multihoming を定義し、13 通りの問題を分類することで、Multihoming の議論を行なう上で基本となっている。

7

¶

1. 残存トンネル利用 (Path Survival)
利用可能な MR-HA トンネルが 1 つ以上ある時、そのトンネルを利用できること。

³

2. トンネル選択 (Path Availability)
MR-HA トンネルが複数ある時、トンネルを選択できること。
3. 送信元アドレスフィルタリング (Ingress Filtering)
送信元アドレスフィルタリングによって、フィルタされないこと。
4. 通信不能の検知 (Failure Detection)
通信不能となった MR-HA トンネルを検知できること。
5. メディア状態取得 (Media Detection)
メディアの状態を取得できること。
6. HA 同期化 ( HA Synchronization)
複数 HA が同一の決定によって動作できること。
7. MR 同期化 (MR Synchronization)
複数 MR の同一の決定によって動作できること。
8. プレフィクス委託 (Prefix Delegation)
プレフィクス委託に問題が起こらないこと。
9. 複数 Binding 登録 (Multiple Binding/Registrations)
複数の Binding を登録できること。
10. 送信元アドレス選択 (Source Address Selection)
通信の送信元アドレスを選択する機構を考慮すること。
11. 既存ルーティングへの影響 (Imapct on the Routing Infrastructure)
既存のルーティングアーキテクチャへの影響を考慮すること。
12. Nested Mobile Networks
Nested Mobile Network の問題を考慮すること。
µ

13. Mobile Network 分割 (Split Mobile Networks)
Mobile Network が分裂した場合の処理を考慮すること。

2.3

図 2.5: Multihoming における問題点

複数 MR モデル

本節では、複数 MR モデルについて説明を行なう。

2.3.1

一般的な複数 MR モデル

第 2.2.2節の Multihoming の定義を用いると、図 2.6の 4 通りの複数 MR がある。

A.
B.

(n, 1, 1) : 複数 MR、単一 HA、単一 MNP(n, n, 1) : 複数 MR、複数 HA、単一 MNP
8

´

C.
D.

(n, 1, n) : 複数 MR、単一 HA、複数 MNP(n, n, n) : 複数 MR、複数 HA、複数 MNP

HAHAInternet

Internet

MR

MR

MR

MNP1

HA

MNP1

(MR, HA, MNP) = (n, 1, 1)

MR

MNP2

MR

MNP1

MNN

(MR, HA, MNP) = (n, 1, n)

HAInternet

MR

MNP1

MNN

MNN

HA

Internet

MR

MNP1

HA

(MR, HA, MNP) = (n, n, 1)

MR

MNP1

MNP2

MNN

(MR, HA, MNP) = (n, n, n)

図 2.6: 複数 MR モデル

複数 MR は Multihoming において最も複雑なモデルである「複数 MR、複数 HA、複数 MNP」を含むので、複数 MR では、図 2.5に示した全ての問題点を考慮する必要がある。

2.3.2

本研究のターゲット

本研究の目的は複数 MR を利用可能とすることである。本研究では複数 HA や複数 MNP の問題を除き、複数 MR の問題のみに着目するため、ターゲットを (n, 1, 1) モデルに絞る。本研究の想定するシナリオは、自動車への搭乗者が持ち込んだ計算機の接続性を利用可能とすることであり、搭乗者の持ち込む計算機は自動車外においては、HA と MNP を持たないことを想定する。
これによって、図 2.5に示した Multihoming の問題のうち、3. 送信元アドレスフィルタリン
グ、6.HA 同期化、8. プレフィクス委託、10. 送信元アドレス選択、11. 既存ルーティングへの影響、12.Nested Mobile Network などを考慮する必要がなくなる。これらの問題は、主に複数
HA または複数 MNP に対する問題である。
3. 送信元アドレスフィルタリングの問題は、MNN が複数のアドレスが取得する際に、起こる問題である。そのため、主に複数 MNP に対する問題であるため、本研究の対象からは除く。
6.HA 同期化は複数 HA に対する問題であるため、本研究の対象から除外する。
8. プレフィクス委譲の問題は、主に複数 MNP に対する問題である。単一の MNP のプレフィ
クス委譲は NEMO 基本サポートと同様に行なうことができるため、本研究の問題とならない。
10. 送信元アドレス選択は MNN が複数のアドレスを取得する際に起こる問題である。そのため、主に複数 MNP の問題点であるため、本研究の問題点とはならない。
11. 既存ルーティングへの影響は本研究で扱う (n, 1, 1) モデルには、大きな問題とならない。

9

HA が複数の MR へのトンネルを持つが、これらのルーティングを HA のみで管理することができるため、ルーティングへの影響は限定的である。
12. Nested Mobile Network の問題は本研究では扱わない。Ingress インターフェイス同士が接続することを前提とする。
この他、5. メディア状態取得についても扱わない。5 は、OSI 参照モデルのデータリンク層における問題である。通信相手との物理的な通信路を確保し、通信路を流れるデータのエラー検出などを行なう。本研究は、データリンク層でのエラー検知を基に動作するシステムとする。
本研究では、Multihoming の問題点の中でも複数 MR の問題点のみを扱う。問題点は以下の6 つである。
1. 残存トンネル利用
Mobile Network と固定のインターネットの間に 1 つ以上の MR-HA 間トンネルがある場
合、MNN はそれを利用できる。また、通信中の MR-HA 間トンネルが通信不能となった
場合、MNN は代替のトンネルを利用できるべきである。利用するトンネルを変更する
際、ネットワーク層より上位の層に透過的である必要がある。
2. トンネルの選択利用
複数のトンネルが存在する時、利用するトンネルは選択できる必要がある。トンネルを切替え可能であるか、または同時利用可能であるべきである。これらはパラメータによって選択利用できる必要がある。また、Mobile Network から送信される通信と、固定のイ
ンターネットから送信される通信の両方を考慮する必要がある。そのため、MR 側と HA側の処理を考慮する必要がある。
3. 通信不能の検知
無線での通信においては通信不能の検知が必要である。HA 側では無線の通信不能を検知できないため、MR が通信不能の通知を行なう必要がある。MR は利用可能なインターフェイスから通知できる必要がある。
4. MR 同期化
複数 MR において、各 MR が同じ決定にしたがって動作する必要がある。同期化のモデ
ルにはプライマリ-セカンダリモデルと、ピア-to-ピアモデルが想定される。
5. 複数 Binding 登録
複数トンネルを扱う場合、単一 MNP に対して複数の CoA を登録する必要がある。Mobile
IPv6 において類似の問題を扱った解決方法として、第 3.2.2節に示した複数 Binding 登録を可能とした複数 CoA 登録がある。
6. Mobile Network 分割
複数 MR の Ingress インターフェイス側のリンクが分離し、同一 MNP の Mobile Networkが 2 つになる問題がある。この問題は通信不能を引き起こすため回避する必要がある。
HA においてリンクの分割を検知することはできないため、MR が通知する処理が必要と
なる。

10

2.4

要求事項の整理

本節では要求事項を整理する。前提となる要求、Multihoming の問題点からの要求、今度の移動体通信環境に基づく要求に分けて説明し、整理する。

2.4.1

本研究の前提に基づく要求

本研究では、移動体計算機群の通信環境を改善する。想定される移動体通信環境の代表例としてインターネット自動車が挙げられる。インターネット自動車において移動体通信をサポートしない接続性は利用価値が低い。移動透過性を持たないため、自動車の移動に起因して通信が遮断してしまう問題がある。また、着信可能性を持たないため自動車間の自由なコミュニケー
ションが実現できない問題がある。よって移動体通信サポートはインターネット自動車に必要不可欠である。
Mobile IPv6 や NEMO といった移動体通信技術は、移動に関する問題を解決する。Mobile
IPv6 は 3章で述べる。Mobile IPv6 はホストの移動体通信を実現し、NEMO はネットワークの移動体通信をサポートする。しかし、Mobile IPv6 による移動体通信の実現にはエンドノードに移動体通信機能が必要となるため、自動車に持ち込まれる全ての計算機に移動体通信サポー
トを行なう必要が生じてしまう。
車内に持ち込まれる計算機は、例えば普段は机の上で利用する PC であったりする。そのため、一時的に自動車のインターネット環境を利用するためだけに移動体通信をサポートすることはコストが高い。また、車内には計算機資源を豊富に持たないセンサノードなどが含まれる。
これらの計算機に移動体通信機能を新たに追加することは避ける必要がある。以上に示したよ
うに、エンドノードへ移動体通信機能を追加しない必要がある。一方、NEMO では MR が移動体通信機能を持つことによって、エンドノードに移動体通信機能を必要としない。したがって、移動計算機群においては NEMO を利用することが合理的である。
また、NEMO は IETF などで、多くの研究者が長年の議論と努力の積み重ねを行ない、標準化されつつある技術である。そのため、ネットワークの移動透過性を実現する技術としては、普及に最も近い立場にある。本研究の成果は、近い将来に普及することを目指すため、本研究
は NEMO の拡張によって目的を達成することとする。
さらに、NEMO を採用する理由としてインターネット自動車プロジェクトが車内ネットワー
クの移動透過性を実現するため、NEMO を想定している点が挙げられる。本研究の成果は、イ
ンターネット自動車の普及を促進し、インターネット自動車を快適な通信環境にするために利用する。そのため、本研究は、NEMO を拡張することで目的を達成される必要がある。
以上の理由によって本研究では移動体通信を実現するため NEMO を利用する。以下に本研究の前提となる要求事項をまとめる。

• エンドノードに対する追加機能なしに移動体通信をサポートするため、NEMO を利用す
ること

2.4.2

Multihoming の問題点に基づく要求

以下に、第 2.3.2節に述べた Multihoming の問題点に基づいた要求事項をまとめる。

• 複数接続性を利用し、経路変更は上位の層に透過的であること (残存トンネル利用)
11• 利用する接続性を選択できること (トンネルの選択利用)• 他の計算機の接続性を用いて Binding を通知できること (通信不能の検知)• 各 MR が同じ決定にしたがって動作すること (MR 同期化)
• 複数の Binding を登録できること (複数 Binding 登録)• Mobile Network の分割の処理を考慮すること (Mobile Network 分割)

2.4.3

今後の移動体通信環境に基づくの要求

今後の移動計算機群には計算機資源を豊富に持つ計算機と持たない計算機、インターネット
接続性を持つ計算機と持たない計算機が混在する。また、計算機の一部は頻繁に群への参加・離脱を行なう。したがって、有効に通信を振り分けるためにはそれらの計算機の動きを検知・管理する必要が生じる。
複数の接続性を選択利用する機構を想定する際、エンドノードが利用する接続性を選択する
方法が考えられる。
しかし、この方法では、例えば一時的にインターネット自動車の環境を利用する計算機に対しても新たな機能を追加する必要が生じてしまう。インターネット自動車に持ち込まれる全ての計算機に新たな機能を追加することは、インストールコストが高い。また、インターネット
自動車のネットワーク環境を利用するために新たな機能を必要とするという解決方法では、インターネット自動車の普及を阻害する要因となる。
また、インターネット自動車には計算機資源に乏しいセンサーノードが多く含まれる。そのため、エンドノードへ新たな機能を追加ことなく他の要求事項を満たす必要がある。
以下に、今後の移動体通信環境に基づくの要求事項を示す。

• 計算機の持つ接続性の管理を動的に行なうこと• エンドノードに複数接続性の共有機能を必要としないこと

12

2.4.4

要求事項のまとめ

本研究における要求事項を表 2.1に整理した。本研究では 6 つの Multihoming の問題点を解決し、これらの要求事項を満たす複数 MR モデルを提案する。
表 2.1: 要求事項のまとめ
要求の由来

要求事項

番号

前提となる要求

エンドノードに対する追加機能なしに移動体通信をサポートする
ため、NEMO を利用すること

R1

Multihoming の問題点に基づく要求(文献 [9] に述べられている問題)

残存トンネルを利用し、経路変更は上位の層に透過的であること利用するトンネルを選択できること
他の計算機の接続性を用いて Binding を通知できること
各 MR が同じ決定にしたがって動作すること
複数の Binding を登録できること
Mobile Network の分割の処理を考慮すること

今後の移動体通信環境に基づく要求計算機の持つ接続性の管理を動的に行なうこと
エンドノードに複数接続性の共有機能を必要としないこと

2.5

R2
R3
R4
R5
R6
R7
R8
R9

まとめ

本章では、現状の移動体通信環境と目指す移動体通信環境について説明した。まず移動通信環境について説明した。その後、NEMO 基本サポートと Multihoming について説明し、Multihomingにおける一般的な問題を挙げた。本研究のターゲットとなるモデルを絞り、問題点をまとめた。
また、要求事項を整理した。

13

第 3 章 関連研究
本章では、本研究に関連する研究についての説明を行なう。関連する技術としては、移動体通信技術に関連する技術と、インターネット接続性共有によって通信の安定性を向上する研究を紹介する。まず、Mobile IPv6 について説明した後、Mobile IPv6 の拡張技術を紹介する。
NEMO は、本研究の目的とする計算機群の移動透過性を実現している点で本研究にとくに重要な技術であり、IETF での活動についても紹介する。その後、関連研究についての考察とまとめを行なう。

3.1

Mobile IPv6 の拡張技術

本研究に関連する技術として、Mobile IPv6 を拡張した技術を 3 つ挙げる。本節では、これらの技術のベースとなる Mobile IPv6 を説明した後、Mobile IPv6 を拡張した技術について述
べる。

3.1.1

Mobile IPv6

Mobile IPv6 は最も古くから開発されている移動体通信技術であるため、これを拡張した研究は数多い。そのなかに、本研究に関連する研究もあることから、関連研究として Mobile IPv6を紹介する。
Mobile IPv6 は第 2.2.1節に示した NEMO の基礎となるプロトコルである。Mobile IPv6の IETF における標準化活動は、10 年にも及ぶ議論の結果 2004 年 6 月に終了した。現在はRFC3775[1] となっている。Mobile IPv6 はホストの移動体通信をサポートするプロトコルである。以下に概要を示す。
Mobile IPv6 の用語は第 2.2.1節に示した NEMO と共通のものが多い。よって、第 2.2.1節で説明を行なった用語については省略する。以下に用語を示す。
• Mobile Node (MN)
移動体ノード。ネットワーク間を移動するノード。
図 3.1に Mobile IPv6 の概要を示した。Mobile IPv6 では HA が MN の CoA と Home Addressの対応づけを行なっている。MN はネットワークを移動し新たな CoA を取得すると HA へと
CoA を通知する (Binding Update)。HA は MN の Home Address 最新の CoA へ転送すること
で、MN は常に一意の IP アドレスで認識される。これによって、MN は移動透過性と着信可能性を持つ。通信の経路は図 3.1中の (a) のように HA を経由する。この他、HA を経由しない通信を行なうための手法も標準化されているが、本研究と直接関係しないので省略する。

14

BC
CN

Foreign link

Binding Update

Internet

HA
Home link

AR

AR

(a)

BUL

move

MN

図 3.1: Mobile IPv6 の概要

3.1.2

Multiple Gateway in Mobile Network (MGMN)

MGMN[10] は、移動体計算機群のインターネット接続性を共有し、エンドノードに着信可能性と移動透過性を達成しているため、本研究と関連する。
MGMN では、移動する計算機群においてインターネット接続性を動的に共有する機構の設計と実装を行なっている。本節では、この論文で設計実装された MGMN について解説を行なう。まず、用語を解説した後、概要を説明する。
以下に用語の説明を行なう。
• Internal Network
計算機の通信が可能な内部ネットワーク。
• Internal Node
内部ネットワーク内のすべてのノード。
• Gateway
Internal Node がインターネットへの接続性を他の Internal node へと提供している状態を示す。Gateway はインターネットと内部ネットワークの両方に接続している。
• 外部インターフェイス
Gateway がもつインターフェイスのうちインターネットへ接続しているインターフェイス。
• Gateway 情報
Gateway のもつ外部インターフェイスに関する情報、および Gateway として機能するための情報。Internal Node はこの情報を元に利用する Gateway を選択する。
図 3.2に概要を示す。Gateway はルータ広告にオプションを付加することで自身の持つ外部
インターフェイスの情報を Ineternal Network へと送信する。送信される情報は、ネットワー
クプレフィクス、メディアタイプ、帯域情報リンク状態などである。Internal Node はこれらの

15

Internet
IEEE802.11b

PHSgateway2

gateway1
Router Advertisement option
prefix 2001:1:0:1::/64
Type IEEE802.11b
Bandwidth 11Mbps
linkstatus associated
etc ......

Router Advertisement option

Internal Network
2001:1:0:1:EUI64
2001:2:0:2:EUI64

2001:1:0:1:EUI64
2001:2:0:2:EUI64

Gateway list
Policy list

prefix 2001:2:0:2::/64
Type PHS
Bandwidth 128Kbps
linkstatus associated
etc ......

Gateway list
Internal NodeInternal Node

Policy list

図 3.2: MGMN の概要

Gateway 情報を Gateway List へと格納する。また、Internal Node は Gateway 情報によってGateway を選択するためのポリシをあらかじめ設定し、保持している。
Internal Node は、送信元アドレスを選択することでどのインターネット接続性を利用するかを決定することが可能である。この機構では、移動透過性や着信可能性を保証することはできない。よって、Internal Node は Mobile IPv6 によって移動を透過することを想定している。

要求事項の充足の有無

MGMN では、複数の計算機の持つインターネット接続性を動的に共有できる。これによって、内部ネットワークの計算機は複数の接続性を利用でき、通信の安定性は向上する。また、
エンドノードが Mobile IPv6 の機能を備えることによって移動に関する問題を解決できる。
しかし、MGMN は車内のネットワーク内のすべての計算機に移動体通信機能を追加することを想定しているため、エンドノードに移動体通信機能を追加しない要求を満たさない。また、
エンドノードが Gateway 情報とポリシによって通信を振り分けることを想定している。そのため、エンドノードに複数接続性の共有機能を必要としない要求を満たさない。

16

3.1.3

Default Router Selection

Default Router Selection[11] は、複数のゲートウェイを利用するために開発されている。
Default Router Selection では、エンドノードが複数のゲートウェイを持つモデルが複数 MRに類似しているため紹介する。
Default Router Selection において、複数の接続性を選択する機構が提案されている。計算機がデフォルトゲートウェイとしているルータを複数保持している場合、どちらのルータをファー
ストホップにするかを決定する必要がある。Default Router Selection では、デフォルトルートの選択を IPv6 のおける近隣探索プロトコル (Neighbor Discovery Protocol, NDP)[12] を拡張して実現している。NDP においてルータ広告メッセージに、Default Router Preference フィー
ルドを設け、ルータの優先度を通知する。またオプションとして、Router Information Optionを定義し、ルータの経路情報を広告する。計算機は、複数のルータ広告を受信したとき、ルータの優先度と経路情報を元に利用するゲートウェイを決定することができる。

要求事項の充足の有無

Default Router Selection では複数の接続性を選択する機構について提案されている。そのため複数の接続性を有効に利用することでエンドノードの行なう通信の安定性を高めることが可能となる。
しかし、複数の接続性を切替えるには、エンドノードがルータの情報を受信し選択する必要がある。そのため、エンドノードに複数接続性を共有する機能を必要としない要求を満たさない。
また、移動体通信については議論されていないため、インターネット自動車に Default Router
Selection を導入するだけでは、移動に関する問題は解決されない。エンドノードが Mobile IPv6機能を持つことで移動に関する問題は解決される。しかし、その場合においてもエンドノードに移動体通信機能を必要としないという要求を満たさない。

3.1.4

Mobile IP SHAKE

Mobile IP SHAKE[13] は移動体計算機群のインターネット接続性を共有することを目的としている。Mobile IP SHAKE においてエンドノードは、Mobile IPv6 の拡張として着信可能性と移動透過性を達成している。移動計算機群にたいしてこれらの要求を満たす点が本研究に関連するため、紹介する。
Mobile IP SHAKE は複数端末の回線を同時に利用することで広帯域な通信を可能とする。
また、複数回線を利用するため HA にトラフィックを分配する機能を持たせた。
図 3.3に Mobile IP SHAKE の移動端末管理の概要を示す。MN1 は近隣端末においてクラスタを構築するため、SHAKE Cluster Control Manager(SCCM) [14] を利用する。SCCM では、移動端末が自身の情報 (NetIF 情報、CPU、バッテリ残量など) を広告する。MN1 クラスタへの協力を依頼するためクラスタ要求を送信する (a)。協力を承諾した MN2 はクラスタ応答を行なう(b)。MN1 は自身の HA へ MN2 の CoA を通知する。この時の Binding Update は Mobile IPv6のメッセージフォーマットにしたがう。また、ビットフラグによって Mobile IP SHAKE の仕組
みによって登録されたことを識別できるようにしておく (c)。HA は Binding Acknowlegementを返答する (d)。
また、図 3.4に Mobile IP SHAKE の通信について示す。HA が CN から届けられた MN1 宛
17

Binding Cache
HoACoA
MN1 HoA MN1 CoA
MN1 HoA MN2 CoA

Frag
SHAKE

src: CN
dst: MN1 HoA
CNForeign linkAR(d)Internet

Home link
Foreign link

AR

Foreign linksrc: HA
dst: MN1 CoA
src: CN
dst: MN1 HoA

AR

(c)

(a)
MN1

SHAKE

HA

HA

Internet

Frag

BC

BC
CN

Binding Cache
HoACoA
MN1 HoA MN1 CoA
MN1 HoA MN2 CoAHome link
Foreign link

AR

AR

MN1

AR

src: HA
dst: MN2 CoA
src: CN
dst: MN1 HoA

MN2cluster(b)

MN2

src: CN
dst: MN1 HoAcluster

図 3.3: Mobile IP SHAKE の移動端末管理

図 3.4: Mobile IP SHAKE の通信経路のパケットを転送する際には、MN1 および MN2 にパケットをカプセル化して分配する。MN2は届けられたパケットのカプセルかを解除し、クラスタ内のリンクを通じて MN1 にパケットを転送する。

要求事項の充足の有無

Mobile IP SHAKE では、移動体通信をサポートしながら計算機の持つ接続性をすべて利用することが可能なる。また、計算機群は動的に構成されるため、計算機の参加・離脱を動的に管理できる。計算機同士のコミュニケーションによって計算機資源に基づいたトラフィックの分配を行なうことが可能となる。また、通信経路の変更はネットワーク層より上位の層に対して透過的である。
しかし、エンドノードに移動体通信機能を必要としない要求を満たさない。そのためすべての計算機に対して移動体通信機能を組み込む必要が生じる。また、エンドノードに複数接続性の共有機能を必要としない要求を満たさない。そのため、すべての計算機がトラフィックの分散に関する機能を必要とする。

3.2

NEMO の拡張技術

本研究の目的を達成する上で Network Mobility は必要不可欠な技術である。そのため、IETFで提案されている本研究に関係したシステムについての解説を行なう。

18

3.2.1

MR registration

MR registration[15] では、移動体計算機群にたいしてインターネット接続性の共有、移動体
通信のサポートなどを目指している点で本研究に関連する。
MR registration において、複数の MR を 1 つの HA に登録し、移動ネットワークを冗長化したり、負荷分散するシステムが提案されている。このシステムで新たに定義された用語を解説し、動作概要を説明する。
以下に用語の説明を行なう。
• Neighbor MR
同じ Mobile Network 内に存在し、直接のインターネット接続性を持っている MR。draftietf-nemo-terminology-00[16] で定義される root-MR。
• Neighbor HA
Neighbor MR の相手となる HA。
• MR 情報
Neighbor MR および Neighbor HA に通知される情報。HoA、CoA、Mobile Network
Prefix のこと。
Neighbor MR list for HA
HoA1

CoA1 NEMO-prefix

HoA2

CoA2 NEMO-prefix

HoA3

CoA3 NEMO-prefix

HA
NEMO tunnel

Binding Update.....

Internetneighbor MR registration

HoA2
CoA2
NEMO-prefix

CoA2

CoA1

Neighbor MR list for MR1
HoA2

CoA2 HA adress NEMO-prefix

HoA3

CoA3 HA adress NEMO-prefix

MR1
HoA1

MR2
HoA2

CoA3

MR3
HoA3

NEMO-prefix

図 3.5: MR registration の概要
図 3.5を動作概要を示した。各 MR は、Ingress interface から送信する RA に MR 情報を加えて情報交換をしている。交換された情報は各 MR のもつ Neighbor MR list へと格納される。ある MR が Mobile Network へ参加した時、Mobile IPv6 の Return Routability 機能を利用して参加した MR を認証する。次に MR は neighbor MR registration sub-option を Binding Updateに挿入し、HA に参加した MR の情報を登録する。HA は naighbor MR registration sub-optionの内容から、Neighbor MR list へと格納する。

19

MNN から通信相手への通信は MNN のデフォルトゲートウェイとなる MR から Neighbor HAへと転送され通信相手へと配送される。通信相手から MNN への通信は HA が Mobile Network
を鍵に Neighbor MR list を参照し、合致した CoA の中から任意の CoA を選び転送すること
で、MNN へと配送される。

要求事項の充足の有無

MR registration では、Mobile Network に複数の MR を登録することによって接続性を共有することができる。そのため、Mobile Network の安定性を増すことができる。Mobile Network
内の計算機の行なう通信は着信可能性と移動透過性持っているため、移動に関する問題は解決されている。また、これらはエンドノードに移動体通信機能を追加することなく実現されている。
しかし、MR registration では複数 MR の接続性を HoA によって識別するため、複数の接続性を持つ MR はにおいても 1 つの接続性だけしか登録できない。そのためすべての接続性を共有するという要求を満たさない。また、複数の接続性を切替えたり、同時利用するための機構について議論されていない。そのため複数接続性を切替えるためにはエンドノードは複数のMR のうちからデフォルトゲートウェイを選択するを必要が生じる。これによってエンドノードに新たな機能を追加しないという要求を満たさない。

3.2.2

複数 CoA 登録の概要

Multiple Care of Address registration (複数 CoA 登録)[17] では、Mobile IPv6 および NEMO
で単一の HoA に対して複数の Binding を登録する手法について議論している。これは、本研究の要求事項に含まれるものであるため、関連研究として紹介する。
本節では、まず複数 CoA 登録で新たに定義された用語について解説し、動作概要について述べる。以下に用語の解説を行なう。
• Binding Unique Identification number (BID)
BID は複数の Binding 登録を区別するための識別子である。Mobile Node は重複しない
方法で BID を生成する。値には、負の数ではない整数を用いる。BID は管理者のポリシにしたがって、任意の時間で変更可能である。
• Primary Care of Address (Primary CoA)
Primary CoA とは Home Address に関連づけられた、プライマリの CoA である。Mobile
Node は常にプライマリの CoA を選択していなければならない。もし Primary CoA が無効になった場合には、プライマリの CoA を選び直さなければならない。
• Binding Unique Identifier sub-option
BID を記述するためのサブオプション。
複数の CoA を取得した Mobile Node は Primary CoA を選択し、Primary CoA を取得しているインターフェイスをプライマリのインターフェイスとする。その後、Binding Uniqe Identifier
sub-option を付帯した Binding Update を行う。この時、’Frag M’ をセットする。Binding Updateには重複しない BID を添付する。HA は Binding Update を受け付けると BC を追加するとともに BID も登録する。この登録の後、同様に Mobile Node はプライマリでない CoA の登録を行う。図 3.6に各 CoA と BID の関係を示した。

20

Binding Cache
HoA
CoA
2001::1111 2001:2::EUI64
2001::1111 2001:3::EUI64
2001::1111 2001:4::EUI64

Frag
R/M
R/M
R/M

BID lifetime
1111 102222 103333 10NEMO prefix table
HoA
MNP
2001::1111 2001:1:0:1::

length64

BC

CN

HA 2001:1::2

Internet

Foreign link
2001:2::/64

Foreign link
2001:3::/64

Foreign link
2001:4::/64

AR

AR
AR

CoA 2001:2::EUI64
BID 1111

Binding Update List
HA address CoA
2001:1::2
2001:2::EUI64
2001:1::2
2001:3::EUI64
2001:1::2
2001:4::EUI64

Home link
2001:1::/64

AR

CoA 2001:3::EUI64
BID 2222

BUL

CoA 2001:4::EUI64
BID 3333
HoA 2001::1111
MNP 2001:1:0:1::/64

MR

BID lifetime
1111 102222 103333 10
MNN

MNN

図 3.6: 複数 CoA 登録

BID は Home Address で BC を検索するのと同様に、BC を検索する鍵として用いられる。
HA は Home Address と BID の両方を鍵として用い、BC の検索を行なう。検索の結果、Home
Address と BID が合致した Binding をルーティングに用いる。どの BID をどの通信に用いるかは、ユーザのポリシとフィルタ情報によって事前に決めておく。
複数 CoA のうちの 1 つが変更になった場合、MN は BID を含む Binding Update を行なう。
Binding Update を受け取ったノードは、BID に合致した Binding を更新する。
Mobile Node が 1 つの CoA だけを登録することにした時、’Frag M’ を含まない Primary CoAの Binding Update を行なう。それによって、Binding Update を受け取ったノードは、Primary
CoA を登録し、Primary CoA の Binding Cache 以外を削除する。
また、Mobile IPv6 および Network Mobility の標準仕様において、ある CoA で通信不能になった際、通信不能になった CoA を HA に通知することはできない。複数 CoA 登録においては通信不能でない CoA を通じて HA に通信不能となった CoA を通知することができる。この処理は、Binding Update に Alternate CoA サブオプションを添付することで行なう。同様に、
Binding Update に Alternate CoA サブオプションを追加することによって、一回の Binding
Update で複数の CoA を登録することができる。これにより、広帯域／低遅延／低コストなイ

21

ンターフェイスを用いて、狭帯域／高遅延／高コストなインターフェイスの CoA を通知することができる。

要求事項の充足の有無
複数 CoA 登録では MR の持つ複数の CoA を BID によって識別し登録する。これによって、複数の接続性を利用することができる。複数の接続性を利用することによって Mobile Networkの安定性を増すことができる。Mobile Network 内の計算機の行なう通信は着信可能性と移動透過性持っているため、移動に関する問題は解決されている。また、これらはエンドノードに移動体通信機能を追加することなく実現されている。
しかし、複数 CoA 登録では単一の MR の持つ複数の接続性を利用することができるが、他の計算機の持つ接続性を利用することはできない。よって、すべてのインターネット接続性を利用可能にするという要求を満たさない。また、同様に複数の接続性を用いて Binding を通知する手法を議論しているが、他の計算機の接続性を利用して登録を通知することはできない。
そのため、他の計算機の接続性を用いて Binding を通知できるという要求を満たさない。

3.3

関連研究のまとめ

Mobile IPv6 や NEMO など移動体通信に関する技術は移動に関する問題を解決していた。しかし、複数の計算機の持つ接続性を利用可能にすることはできなかった。NEMO を拡張した技術である MR registration では、移動体通信を実現しながら計算機の持つ接続性を共有できた。しかし、すべての接続性を共有することはできなかった。また、利用する接続性を選択するためエンドノードに追加の機能が必要であった。同じく NEMO を拡張した技術である複数
CoA 登録では移動体通信を実現しながら、複数の接続性を利用可能であった。しかし、利用可能となる複数接続性はいずれも単一の計算機が持っていなければならなかった。そのため、他の計算機の持つ接続性を利用することができない問題が残されていた。
MGMN と Default Router Selection の複数接続性を利用する研究においてはネットワークの安定性を増大したり、接続性の選択利用が可能となった。しかし、いずれも移動体通信機能と複数接続性の利用機能をエンドノードの拡張として行なっていた。そのため、いずれもエンド
ノードに新たな機能を追加しない要求を満たさなかった。
表 3.1に要求事項とこれらの技術との関係を整理した。表 3.1に示すとおり、第 2.4.4節でまとめた要求事項をすべて満たすシステムはなかった。前章までで紹介した関連研究を導入することによって、本研究で目指すインターネット自動車のインターネット利用環境を構築できない
ことがわかった。
特に、表 3.1の F に示したエンドノードに複数接続性の共有機能を必要としない要求を満たす技術はなかった。そのため、本研究で新たな仕組みを構築する必要があると考える。また、Dに示した他の計算機の接続性を用いて Binding を通知できる要求を満たす技術も存在しない。
同様に本研究で新たな仕組みを構築する必要がある。
本章では、移動体通信技術と複数接続性の利用に関する研究に分類して関連研究をまとめた。
また、Network Mobility については現在 IETF において議論されてる技術についても紹介した。
その後、要求事項とこれら技術との関係を考察した。関連する技術では本研究の目的が達成できないことがわかった。次章以降では目的を達成するためのアプローチについて述べ、要求事

22

項をすべて満たすシステムを提案する。
表 3.1: 関連研究の比較
分類

Mobile IPv6の拡張技術

NEMO の
拡張技術

A.
B.

C.
D.
E.

技術名

A

Mobile IPv6MGMN
Default Router Selection+Mobile IPv6
Mobile IP SHAKE
Network Mobility
MR registration
複数 CoA 登録

B

C

D

E

×
×

×
○

×
×

—1
○

—2
×

×

○

×

○

×

×

○

×

○

×

×
×
×

—1

—2
×
—2

○
○
○

×
△3
×

○
—1

エンドノードに対する追加機能なしに移動体通信をサポートすること (R1)
(NEMO を利用すること)複数計算機のインターネット接続性を動的に利用可能にすること
複数接続性を利用し、経路変更は上位の層に透過的であること (R2)
利用する接続性を選択できること (R3)
複数の Binding を登録できること (R4)
各 MR が同じ決定にしたがって動作すること (R5)
計算機の持つ接続性の管理を動的に行なうこと (R8)
他の計算機の接続性を用いて Binding を通知できること (R6)
Mobile Network の分割の処理を考慮すること (R7)
エンドノードに複数接続性の共有機能を必要としないこと (R9)1

Mobile Network 分割が起こらないため、対象外
複数計算機の接続性を共有できないため、対象外
3すべてのインターネット接続性を利用できない
2

23

第 4 章 要求事項を満たすモデルの提案
本章では、第 2.4.4節で示した要求事項をすべて満たすモデルを提案する。そのためにまず、目的を達成するための方針を決定する。方針を決定するため、複数インターネット接続性の共有機能についての考察を行なう。また、エンドノードに追加の機能を必要としないモデルについての考察を行なう。まとめとして方針に基づいたモデルを提案する。

4.1

アプローチ

本節では第 2.4.4節で示した要求事項をすべて満たすシステムを提案するためのアプローチを考察する。本研究では、エンドノードに対する追加機能なしに移動体通信をサポートするため、NEMO を利用する (R1)。その他の要求事項を満たすための機能として複数 Binding の登録のモデル (R6) とノードに追加機能を必要としないモデル (R9) の考察を検討する必要がある。
本研究の要求事項はすべて満たすべきであるが、考察を行なってもアプローチを決定するために影響を与えない要求事項については考察を省略する。以下に示した要求事項はその他の通信技術に非依存であるため、方針の策定に影響を及ぼさない。

• 残存トンネルを利用し、経路変更は上位の層に透過的であること (R2)
• 利用するトンネルを選択できること (R3)
• 他の計算機の接続性を用いて Binding を通知できること (R4)
• 各 MR が同じ決定にしたがって動作すること (R5)
• Mobile Network の分割の処理を考慮すること (R7)
• 計算機の持つ接続性の管理を動的に行なうこと (R8)
複数インターネット接続性を用いてエンドノードの通信の安定性を増大させる手法は関連研究に見られた。しかし、複数 Binding を管理する機構が不十分なため全ての接続性を共有できない問題があった。また、エンドノードに追加の機能を必要とするモデルが提案されていたが、これらのモデルは本研究の要求を満たさなかった。本節では、複数 Binding の管理の機構とエンドノードに追加の機能を必要としないモデルについて考察を行なう。

4.1.1

複数の binding を管理する機構の考察

MR registration では、複数 Binding の管理を MR の HoA ごとに行なっていたため、複数のBinding をもつ MR には対応できなかった。そのため MR の持つ複数の接続性のうちの 1 つだ24

けを登録することとなった。本研究の目的である、全てのインターネット接続性の共有を行な
うため、Binding の登録は接続性ごとに行なう必要がある。
一方、複数 CoA 登録においては NEMO の MR-HA 間トンネルを BID によって識別できる
ため、インターネット接続性ごとの登録が可能であった。しかし、複数 CoA 登録は単一の MRに対する MR-HA 間トンネルを区別して登録できるが、複数の MR の MR-HA 間トンネルを管理することはできなかった。
Binding Cache
HoA
CoA
Frag
R
2001::1111 2001:2::EUI64
2001::2222 2001:3::EUI64
R
R
2001::3333 2001:4::EUI64
NEMO prefix table
HoA
MNP
length
2001::1111 2001:1:0:1::
64
2001::2222 2001:1:0:1::
64
2001::3333 2001:1:0:1::
64(a)Binding Cache
HoA
CoA
2001::1111 2001:2::EUI64
2001::1111 2001:3::EUI64
2001::1111 2001:4::EUI64

Frag
R/M
R/M
R/M

NEMO prefix table
HoA
MNP
2001::1111 2001:1:0:1::

length
64

BC

BC

HA

HA

Internet

CoA
2001:1::EUI64

CoA
2001:2::EUI64

HoA 2001::1111
MNP 2001:1:0:1::/64

Internet

CoA
2001:3::EUI64

HoA 2001::2222
MNP 2001:1:0:1::/64

BID
1111
2222
3333

CoA
2001:4::EUI64

HoA 2001::3333
MNP 2001:1:0:1::/64

CoA
2001:1::EUI64
BID 1111

CoA
2001:2::EUI64
BID 2222

CoA
2001:3::EUI64
BID 3333

HoA 2001::1111
MNP 2001:1:0:1::/64

(c)

(b)

MNN

MNN

MR registration

Multiple CoA registration

図 4.1: MR registration モデルと複数 CoA 登録モデルの比較

図 4.1に MR registration と複数 CoA 登録のモデルの比較について示した。MR registrationのように HoA によって Binding を識別し登録する方法では、複数インターフェイスの MR に対応できない。図 4.1中では HoA が”2001::1111” である MR は CoA が “2001:2::EUI64” として登録されているため”2001:1::EUI64” の CoA は HA に登録されていない。そのため、図 4.1中の (a) のように利用できないインターネット接続性が存在する。
一方、複数 CoA 登録は BID という Binding を一意に識別するための識別子を定義すること

25

によって、インターフェイスごとの Binding を登録することが可能となった。
本研究の目的である複数ノードのもつ接続性を共有するため、単一の MNP に対して複数のCoA を HA に登録する仕組みが必要である。複数 CoA 登録の仕組みは、これを満たしている。
したがって、本研究において新しく複数 CoA 登録の仕組みを定義することは技術の重複に当たり望ましくない。よって、本研究において複数 CoA 登録の仕組みを利用し、拡張することで本研究の目的を達成する。
また、複数 CoA 登録は、残存トンネルを利用し、経路変更は上位の層に透過的であること(R2) と利用するトンネルを選択できること (R3) も同時に満たす。

4.1.2

エンドノードに追加の機能を必要としないモデルの考察

MGMN、Mobile IP SHAKE、MR registration など、複数の計算機のインターネット接続性を有効に利用するためのモデルは関連研究に見られた。しかし、第 3.3節に示したとおりエンドノードに追加の機能を必要としないモデルは存在しない。MR registration や MGMN や
Default Router Selection など Mobile Network に複数のゲートウェイがあるモデルでは、エンドノードがデフォルトゲートウェイを選ぶ必要が生じた。一方、Mobile Network にただ 1 つだけ存在するゲートウェイが接続性を持っているモデルでは、エンドノードに接続性選択の必要は生じない。このモデルに該当する複数 CoA 登録では、エンドノードに追加の機能を必要としない。ただし、複数 CoA 登録では、複数の計算機の接続性を有効に利用できない問題があった。
図 4.1に、MR registration などのように Mobile Network に複数のゲートウェイがあるモデ
ルと、複数 CoA 登録のようなただ 1 つのゲートウェイに複数の接続性が存在するモデルを比較した。図 4.1中の (b) に示したとおり、MR registration に代表される複数ゲートウェイモデ
ルでは、エンドノードが直接経路を選択する必要が生じてしまう。一方、図 4.1の (c) に示したとおり、複数 CoA 登録のモデルでは、エンドノードは接続性を選択する必要は生じない。複数の接続性を選択する機能は MR が担当する。エンドノードは通常のネットワークと同様に、そのネットワークのデフォルトルータへとパケットを送出することで通信を行なうことが可能である。
本研究においては、エンドノードに追加の機能を必要としない要求を満たすため、Mobile
Network のデフォルトルータをただ 1 つとするモデルを採用する。

4.1.3

方針のまとめ本研究において要求事項を満たすためと複数インターネット接続性の共有機能とエンドノードに追加の機能を必要としないモデルが必要であった。複数インターネット接続性の共有機能
としては、複数 Binding を扱う仕組みが必要となった。本節では本研究のアプローチとして、
複数 CoA 登録の仕組みを利用することが適切であると結論した。また、エンドノードに追加の機能を必要としないモデルとして、移動ネットワークにただ 1 つのデフォルトゲートウェイ
を設定することとした。
表 4.1に方針を整理した。

26

表 4.1: 方針のまとめ
要求事項

アプローチ

エンドノードに対する追加機能なしに移動体通信をサポートするため、NEMO を利用すること (R1)
複数の Binding を登録できること (R6)
残存トンネルを利用し、経路変更は上位の層に透過的であること (R2)
利用するトンネルを選択できること (R3)NEMO の仕組みの利用

複数 CoA 登録の仕組みの利用

エンドノードに接続性選択機能を必要としないこと (R9)

Mobile Network に 1 つのデフォルトルータの設置

他の計算機の接続性を用いて Binding を通知できること (R4)
各 MR が同じ決定にしたがって動作すること (R5)
Mobile Network の分割の処理を考慮すること (R7)
計算機の持つ接続性の管理を動的に行なうこと (R8)

これらの要求は他の移動体通信技術に非依存であるためアプローチ決定に影響しない

4.2

Mobile Network における接続性の動的共有モデル

前節では、第 2.4.4節で述べた要求事項を満たすシステムを構築するため、本研究の方針を決定した。方針を基に本節では、Mobile Network における接続性の動的共有モデルを提案する。
まず、参考になるモデル分析し、拡張の検討を行なう。

4.2.1

複数 CoA 登録の拡張

前節で述べた方針は、複数 CoA 登録モデルと類似している。複数 CoA 登録は方針と同様に、移動体通信機能を満たすために NEMO を用いる。また、本研究の方針として同一 MNP に対する複数の Binding 登録には複数 CoA 登録の仕組みを利用する。複数 CoA 登録は方針と同様に、Mobile Network に 1 つのデフォルトルータを設置するモデルである。本研究の要求事項を満たすため、複数 CoA 登録のモデルは適している。
一方、関連研究のまとめで表 3.1に示したとおり、複数 CoA 登録は複数計算機のインターネッ
ト接続性を利用可能にするという要求を満たしていない。また、他の計算機の接続性を用いてBinding を通知できる要求を満たしていない。そこで、エンドノードに複数接続性の共有機能を必要としない要求などを満たしつつ、これらの要求を満たす必要が有る。要求事項と複数 CoAの関連を表 4.2に整理した。
また、複数接続性を HA に登録するモデルは、複数 CoA 登録の概念に含まれるべきである。
つまり、単一の計算機の複数接続性であっても、複数の計算機の複数接続性であっても、HAへの登録は同一の仕組みで登録できることが望ましい。よって、本研究の目的は複数 CoA 登録の拡張によって達成されることが望ましい。
本節では、複数 CoA 登録がすでに満たしている要求へ悪影響することなく、満たしていない
要求を満たす。そのため、エンドノードに追加機能を必要としない接続性共有機構と動的な接続性共有モデルについて考察する。

27

表 4.2: 要求事項と複数 CoA 登録の関連要求の充足状況

要求事項

エンドノードに対する追加機能なしに移動体通信をサポートするため、NEMO を利用すること (R1)
複数の Binding を登録できること (R6)
残存トンネルを利用し、経路変更は上位の層に透過的であること (R2)
利用するトンネルを選択できること (R3)
エンドノードに接続性選択機能を必要としないこと (R9)
他の計算機の接続性を用いて Binding を通知できること (R4)
各 MR が同じ決定にしたがって動作すること (R5)
Mobile Network の分割の処理を考慮すること (R7)
計算機の持つ接続性の管理を動的に行なうこと (R8)4.2.2

NEMO の仕組みの利用

複数 CoA 登録の仕組みによって充足追加の機能の構築が必要

バーチャルインターフェイス追加モデルの提案

本研究は方針として、エンドノードに追加機能を必要としないため、Mobile Network に 1 つのデフォルトゲートウェイを設置することとした。デフォルトゲートウェイを 1 つ設置し、複数の MR を利用するため、図 4.2に示すモデルを採用する。

HA
for Multiple CoA
Registration

join

Binding Cache
HoA
CoA
MR2 HoA MR1 CoA
MR2 HoA MR2 CoA
MR2 HoA MR2 CoA

BID
BID1
BID2
BID3

Frag
R/M
R/M
R/M

Internet
BID2

BID3

BID1

join

Real
interface

MR1

Virtualinterface

MR2

VirtualinterfaceMR3

default route
MNN

Mobile Netowrk

図 4.2: バーチャルインターフェイス追加モデル

Mobile Network に持ち込まれた計算機は、MR として動作し、プライマリとなる MR のバー
28

チャルインターフェイスとして加わる。これによって Mobile Network にデフォルトゲートウェ
イを 1 つ設置し、複数接続性を利用できる。まず、それらの計算機の CoA を MR の HA へと登録する。HA は複数 CoA 登録の仕組みによって MR-HA トンネルを識別する。HA から Mobile
Network へのトラフィックの分散は BID よるトンネルの識別によって可能となる。MR から、
HA へのトラフィックは MR がリアルインターフェイスから送信するか、バーチャルインター
フェイスから送信するかによって実現できる。
このモデルによって、複数 CoA 登録の満たしている要求事項に影響することなく、複数の計算機の接続性を共有することが可能となる。また、プライマリの MR が複数の MR の持つインターネット接続性を管理できる。

4.2.3

MR 間の動的な情報共有モデルの提案

NEMO 基本サポートでは、Mobile Network に複数の MR が接続されることはないため、複数の MR は互いに他の MR が接続されていることを検知できない。これは、複数 MR 間の情報交換が欠如しているためである。
そのため、要求事項のうち各 MR が同じ決定にしたがって動作する要求 (R5) を満たすことができない。また、互いに他の MR の接続状況を検知することがないため、計算機の持つ接続性の管理を動的に行なう要求 (R8) は満たすことができない。その他、互いに他の MR の情報を知ることができないため、他の計算機の接続性を用いて Binding を通知する要求を満たすことができない。また、Mobile Network への複数の MR の接続状況を確認する仕組みがないた
め、Mobile Network の分割を回避する要求 (R7) を満たすことができない。
本研究では MR 間の動的な情報共有を行なうことで、これらの要求事項を満たす。各 MR は移動ネットワーク側のインターフェイスを用いて情報共有を行なう。各 MR の Binding の追加・更新・削除などの情報を動的に交換する仕組みが必要となる。また、ある MR の Binding
Update を他の MR が代行するためのメッセージなどを交換する。また、MR 間が常に情報交換を行なうことで Mobile Network の分割を検知することが可能となる。

4.3

まとめ

本章では、要求事項を満たすためのアプローチについて論じた。結果、複数 CoA 登録を拡張しすることが適切と結論した。また、複数 CoA 登録が満たしていない要求についてまとめた。
本研究では、4.3に示すように、複数 CoA 登録にバーチャルインターフェイス追加モデルとMR 間の動的な情報共有モデルを導入し、拡張することで、目的を達成する。

29

表 4.3: 本研究のアプローチ
要求事項

要求の充足状況

エンドノードに対する追加機能なしに移動体通信をサポートするため、NEMO を利用すること (R1)
残存トンネルを利用し、経路変更は上位の層に透過的であること (R2)
複数の Binding を登録できること (R6)
利用するトンネルを選択できること (R3)
エンドノードに接続性選択機能を必要としないこと (R9)
各 MR が同じ決定にしたがって動作すること (R5)
計算機の持つ接続性の管理を動的に行なうこと (R8)
他の計算機の接続性を用いて Binding を通知できること (R4)
Mobile Network の分割の処理を考慮すること (R7)30

NEMO の仕組み
複数 CoA 登録の仕組み+
バーチャルインターフェイス
追加モデル

MR 間の動的な情報共有モデル

第 5 章 Multiple Mobile Router
Management(MMRM) の設計
本研究では、4章で提案したモデルを元に Multiple Mobile Router Management(MMRM) を提案する。本システムは Multiple Care of Address registration[17] を拡張して行なう。MMRMの設計概要について述べる。次に動作概要で、まず本研究で新たに定義した Neighbor Egressinterface List(NEL) について説明する。その後、MMRM の動作をを機能ごとにまとめ、その動作を説明する。

5.1

MMRM 設計概要

本研究において新たに拡張を行なう必要のない機能として、HA の BC を扱う機能があげられる。複数 CoA 登録において定義されている BC のデータストラクチャは、同一 Home Addressを鍵として、複数の CoA を登録する機能をもっている。3章で述べたとおり、それらの Binding
を BID によって管理することができる。MMRM は複数 CoA 登録によって拡張された HA の機能に変更を加えることなく、本研究の目的を達成できる。
本研究において新たに拡張を行なう機能として、複数 MR の Binding の情報を交換する機能があげられる。複数 CoA 登録では、単一の MN が複数の CoA を取得することが前提となっているため、MN 内部ですべての MN-HA 間トンネルを扱うことができた。しかし、本研究において CoA を取得するノードが複数存在する。そのため、複数 MN 間で MN-HA 間トンネルの情報を交換する仕組みが必要となる。
MMRM では複数の MN が互いの MN-HA 間トンネルの情報を交換できる仕組みを提案する。
本研究において、上記の機能を追加することで MN の機能を拡張し、HA の機能を拡張しないこととする。これによって HA は複数 CoA 登録を行なう際、MN が単一のノードあっても、また複数のノードであっても同一の仕組みによって扱うことができる。

5.1.1

MMRM の用語

本節では、本研究で新たに定義した用語について説明を行なう。

• Primary Mobile Router (PMR)
所属する Mobile Network を提供する責任をもつ MR。ある Mobile Network に必ず 1 台
存在しなければならない。この Mobile Network のルーティングポリシを有する。また、
MNN のデフォルトゲートウェイとなる MR。MNN からのパケットのファーストホップとなり、ポリシによって HA までの経路を決定する。
• non-Primary Mobile Router (non-PMR)
31

所属する Mobile Network の PMR から転送されたパケットを HA まで転送する MR。自身はポリシを持たず、常に PMR の決定した経路に従いパケットを転送する。

• Neighbor Egress interface List (NEL)
Mobile Network と HA を結ぶ MR-HA トンネルの情報を格納するデータストラクチャ。
PMR は必ず NEL を持たなければならない。non-PMR は NEL を持つべきである。PMR
は NEL によって現在存在する MR-HA トンネルを取得することで、ユーザのポリシを反映することができる。
• NEL Advertisement
PMR および non-PMR は、自身の持つインターフェイスからの MR-HA 間トンネルの情報を Ingress インターフェイスを通じて Mobile Network へと提供する。MR は BUL が追加・変更・削除された時に NEL Advertisement を送信する。

5.1.2

動作概要

PMR および non-PMR は同一 Mobile Network 内の MR の持つ Egress インターフェイスの情報を保持するため NEL を持つ。各 MR は NEL の情報を交換するため、NEL Advertisement を行
なう。NEL Advertisement は、MR-HA トンネルの情報を Ingress インターフェイスから、オールノードマルチキャストアドレスへ送信することで行なう。NEL および NEL Advertisement
は、本研究で新しく定義したため、第 5.2.1節および第 5.2.2節においてフォーマットなど詳細の説明を行なう。

HA(4) Binding Update

Binding Update
Binding Acknowlegement

Binding Acknowlegement

Internet(6) (3) update

NEL

NEL

NEL

PMR

(5) update

non-PMR

non-PMR

BUL

non-PMR(1) move(8) create tunnel(2)(7) NEL Advertisement

NEL Advertisement

MNN
Mobile Network

図 5.1: NEL Advertizement による Egress インターフェイスの情報交換

図 5.1を用いて Egress インターフェイスの情報交換の概要について説明を行なう。Mobile32

Network 内に入ってきた non-PMR(1) は、定期的に送信されている NEL Advertisement メッ
セージを受け取る (2)。MR はこのメッセージを受け取ると、メッセージに含まれる情報を NEL へと格納し (3)、自身もその Mobile Network の MR として動作する。その後、Mobile Network を提供している HA へと Binding Update を行なう (4)。この際、non-PMR は PMR と同じ Home
Address を使用し、また複数 CoA 登録の仕様のとおり重複しない Binding Uniqe Identifer(BID)
を生成し、Binding Update を行なう。CoA 登録が正常に終了した MR は、Binding Update
List(BUL) を生成し (5)、それを基に NEL を更新する (6)。その後、NEL の更新を他の MR へと伝えるため、Mobile Network に対して NEL Advertisement を行なう (7)。
NEL Advertisement を受け取った PMR は、その情報を NEL へと格納し、自身の属する
Mobile Network に新たに MR-HA トンネルが確立されたことを検知する。PMR は、その nonPMR の Ingress インターフェイスへと MR-MR 間トンネルを確立する (8)。

CNHANEMO tunnel

BID1

BID2

BID3

BID4

Internet
NEL

NEL

PMR

NEL

non-PMR

non-PMR

MNN
Mobile Network

図 5.2: PMR による経路選択

図 5.2を用いて MMRM のルーティングについて説明を行なう。PMR はルータ広告を送信するなどし、MNN はデフォルト経路を PMR へと設定する。PMR のみが、どの通信にどの
MR-HA トンネルを利用するかを記述したポリシをもつ。MR-HA トンネルは BID によって識別される。図 5.2に示すように、MNN の通信はまず、PMR へと送信される。PMR は MNN
からのパケットがどのトンネルから送信されるべきか、ポリシを参照する。 この時、PMR は自身の持つトンネルから出ていくべき通信であれば、通常の Network Mobility のとおり HAへと送信する。また、パケットが non-PMR の持つ MR-HA トンネルを使用するべきであった
場合、non-PMR へトンネルを通じて転送する。PMR からのパケットを受け取った non-PMR
は、そのパケットを HA へと転送する。図 5.2では、PMR がポリシによって、non-PMR の持
つ Egress インターフェイスを経由する経路を選んだ場合を示した。HA は CN から MNN への通信を複数 CoA 登録と同じ仕組みによって振り分ける。

33

5.2

本研究で定義したデータフォーマット

本節では、本研究で新たに定義したデータストラクチャである Neighbor Egress interface List
(NEL) のフォーマットと、NEL を交換するための仕組みである NEL advertizement のフォー
マットについて説明を行なう。

5.2.1

Neighbor Egress interface List の定義

本研究では、同一の Mobile Network に属する PMR および non-PMR が MR-HA トンネルの情報を保持し合うため、NEL を定義した。PMR では NEL を参照することで、どのような
MR-HA トンネルが存在するかを得る。そこで、存在する MR-HA トンネルの情報を得ること
で、ポリシに従いルーティングすることができる。
NEL のフォーマットは次のとおりである。

要素

表 5.1: Neighbor Egress interfaces List
形式

BID
MR タイプHome Address
CoA
Ingress インターフェイスのグローバルアドレス
ライフタイム

5.2.2

整数

PMR・non-PMR
IPv6 address
IPv6 address
IPv6 address秒

NEL Advertisement の定義

本研究では、PMR と non-PMR が NEL の情報を交換するために NEL Advertisement を行
なうこととする。NEL Advertisement は自身のもつトンネルの情報のみを ingress インターフェ
イス側に送信することとする。送信先をオールノードマルチキャストにし、宛先ポート番号を11233 に設定した UDP パケットを送信する。UDP パケットに含まれれる情報は次のとおりである。

34

表 5.2: NEL Advertisement のフォーマット
形式

要素
動作

BID
MR タイプHome Address
CoA
Ingress インターフェイスのグローバルアドレス
ライフタイム

5.3

NEL ADD・NEL REMOVE・ADD REQEST・REMOVE REQEST整数
PMR ・ non-PMR
IPv6 address
IPv6 address
IPv6 address秒

MMRM の動作

本節では、MMRM の動作を機能別に説明を行なう。

5.3.1

Neighbor Egress interface List の同期に関する流れ

本システムでは NEL Advertisement を行なうことで、互いの MR-HA トンネルの情報を交換する。ここでは、MR の追加・離脱と NEL の更新・削除についての流れの説明を行なう。

新規の MR の参加

PMR は常に Mobile Network に NEL Advertisement を行なう。PMR の NEL Advertisementを検知した non-PMR は、その Mobile Network の MR として動作するため、PMR からの NEL
Advertisement に含まれる Home Address を設定して、Mobile Network の HA に対して Binding
Update を行なう。MR-HA トンネルを生成し、BUL を追加した non-PMR は Mobile Network
へ自身の持つ MR-HA トンネルを含む NEL Advertisement を行なう。
同一 Mobile Network に所属する PMR および non-PMR は NEL に登録されていない BID を含む NEL Advertisement を検知すると、NEL Advertisement に含まれる情報を NEL へと格納する。また、PMR は新規の non-PMR の ingress インターフェイスに対してトンネルを生成する。
non-PMR は、PMR からの NEL Advertisement を受け取ると、PMR への MR-MR トンネ
ルを生成する。以上の処理で新規の MR の参加は完了する。

計算機集合内の Mobile Rotuer の離脱

NEL Advertisement には、NEL が有効である時間を定義したライフタイムの情報が含まれている。PMR および non-PMR は、指定されたライフタイムが経過した NEL を削除する。HA との Binding を持ち BUL を追加した MR は、Mobile Network へと NEL Advertisement を流さなければならない。そのため、Mobile Network に NEL Advertisement を流さない non-PMR
は Mobile Network を離脱したこととする。
35

また、Mobile Network の分割による問題を解決するため、non-PMR が PMR の NEL Advertizement を受け取れなくなった際は、HA への Binding Update を止め、その HA においての MR としての機能を停止する。

NEL の更新・削除に関する処理
各 MR は Mobile Network に所属する MR-HA 間トンネルの情報を NEL に格納し保持している。各 MR は BUL が追加・更新・削除された時に NEL Advertisement を行なう。BUL の追加・更新は Binding Update および Binding Acknowledgement が正常に処理された時に行なわれる。BUL の削除は、あるインターフェイスの CoA が通信不能となった時、または、Binding
Update が正常に処理されず BUL がタイムアウトした時に行なわれる。

5.3.2

ポリシールーティングに関する流れ

PMR は上記の NEL の同期によって、常に Mobile Network に所属する MR-HA 間トンネルを把握している。PMR はルータ広告を送信するなどして、MNN のデフォルトルータとなるよ
うにしておく。MNN が送信するパケットは、常に PMR をファーストホップとする。

CN

HA
Policy for PMR
filtertunneldefault

BID1

Port number : 22

BID2

flow type : UDP

BID3

src : AddressB

BID4

BID1

BID2

BID3

BID4

(a)

(b)

(c)

(d)

PMR

non-PMR1

non-PMR2

non-PMR3Port 22
UDP

MNN1

MNN2
Mobile Network

図 5.3: PMR によるポリシールーティング

PMR はポリシに基づいて通信を振り分ける。図 5.3 に例をあげる。PMR は、フローのタイ
36

プ、ポート番号、送信先アドレス、送信元アドレスなどによって、通信の経路を変える。PMRのポリシは事前に、ポート 22 番のパケットを BID2 のトンネル、フローのタイプが UDP のパケットを BID3 のトンネル、送信元アドレスが AddressB のパケットを BID4 のトンネル、以上に当てはまらないパケットを BID1 へと振り分けるように設定されている。
図 5.3の (a) の通信のように、MNN1 の送信するパケットはデフォルトルートとして PMRに送信される。この場合、PMR のポリシに合致しないので、デフォルトの経路として BID1であるトンネルををとおり HA へ転送される。経路は「MNN1 - PMR - HA - 通信相手」となる。図 5.3の (b) に示すとおり、MNN1 の送信する UDP パケットは、PMR のポリシによりMR-MR 間トンネルを通って non-PMR1 へと転送される。non-PMR1 は、MR-MR 間トンネ
ルを通じて PMR から転送されたパケットを HA へと転送する。この場合の経路は「MNN1 PMR - non-PMR1 - HA - 通信相手」となる。同様に図 5.3の (c) に示す通信経路は「MNN2 PMR - non-PMR2 - HA - 通信相手」となり、(d) の経路は「MNN - PMR - non-PMR3 - HA
- 通信相手」となる。
すべての通信は PMR をファーストホップとし、必ず 2 ホップ以内で Mobile Network 外へと転送される。またすべての通信は MR および HA を経由し、移動体通信サポートを受ける。
通信相手から MNN への通信は、HA の保持するポリシによって振り分けられる。振り分ける
ためのポリシの保持、ルーティングなどは複数 CoA 登録の仕組みからの変更はない。従って、通信経路は「通信相手 - HA - PMR - MNN」または、「通信相手 - HA - non-PMR - MNN」
となる。

5.3.3

冗長経路を用いた利用不可能な経路の検知

本システムでは、MR-HA 間トンネルが 1 つである NEMO 基本サポートでは不可能であっ
た HA における利用不可能な経路の検知を行なうことができる。
NEMO 基本サポートにおいて MR のインターフェイスが通信不能になった際、HA は BC のライフタイムがタイムアウトすることでしかそれを検知できない。複数の MR-HA 間トンネルを利用する本システムでは、利用不能となったインターフェイスをその他のインターフェイス
を用いて、HA に通知することができる。
あるトンネルが利用不能となった時、まず MR は対応する NEL を削除する。その後、NEL を削除したことを NEL Advertisement の REMOVE REQEST を用いて、Mobile Network に所
属する MR へと通知する。各 MR は NEL Advertisement の情報から利用不能となった MR-HA
トンネルに対応する NEL を削除する。NEL の検索には BID を用いる。その後、1 台の MR が
HA へと利用不能となったインターフェイス宛の MR-HA 間トンネルの BID を通知する。この通知には、ライフタイムを 0 とした Binding Update を用いる。
図 5.4に、この仕組みの例を示す。まず、図 5.4中の (1) に示した BID4 で識別される MR-HA 間
トンネルのインターフェイスが通信不能となった。BID4 のトンネルを保持していた MR は NELを削除し、REMOVE REQEST を含む NEL Advertisement を行なう。NEL Advertisement には、BID4 と Home Address が含まれる。NEL Advertisement を受け取った各 MR はそれぞれ
BID4 に対応する NEL を削除する。その後、1 台の MR が HA へと利用不能となったインターフェイス宛の MR-HA 間トンネルの BID を通知する。通知を行なう MR は、事前に設定しておく必要がある。例えば、一番数字の小さい BID をもつインターフェイスを用いて通知した
り、常に PMR が通知を行う、というようなポリシを事前に決めておく。本例では、PMR の37

HA(3) Binding Update
.....

BID1

BID2

(1) invalid
BID4

BID3

alternate CoA sub-option

CoA4
BID sub-option

NEL

BID4
Lifetime : 0

PMR NEL

non-PMR

NEL
CoA4
non-PMR(2) NEL Advertisement
REMOVE_REQEST
BID4
non-PMR

Mobile Network

non-PMR’s address

CoA4
etc ...

図 5.4: 冗長経路を用いた利用不可能な経路の検知保持する BID1 のインターフェイスを用いた通知を行なう。通知は BID sub-option を追加した Binding Update をライフタイムを 0 で送ることによって HA に BC を削除させることで行
なう。

5.3.4

冗長経路を利用した Binding Update

本システムでは、高遅延・狭帯域・金銭的に高コストのインターフェイスなど、頻繁に Binding
Update することが望ましくないインターフェイスで取得した CoA をそのインターフェイス以
外から HA に通知できる。
まず、Binding Update を他のインターフェイスで代行する MR は、BU を行なうために必な情
報を NEL Advertisement を用いて、他の MR へと通知する。必要な情報には、Home Address、CoA、BID である。NEL Advertisement の action フィールドには ADD REQUEST を挿入する。このメッセージを受け取ったノードのうち 1 台が Binding Update を行なう。その他のノードはこのメッセージを無視する。通知を行なう MR は、事前に設定しておく必要がある。例えば、一番数字の小さい BID をもつインターフェイスを用いて通知したり、常に PMR が通知を行う、というようなポリシを事前に決めておく。Binding Update および Binding Acknowledgement
を正常に処理したその MR は NEL Advertisement を用いて、Binding が正常に処理されたことをその他の MR へと伝える。
図 5.5に例を示す。図 5.5中の (1) に示すとおり、BID3 と BID4 をもつ non-PMR は BID4の Binding Update を代行させるため、Action フィールドに ADD REQEST を挿入した NELAdvertisement を行なう。NEL Advertisement の内容は、BID4、CoA4 と Home Address などである。(2)ADD REQEST を含む NEL Advertisement を受信した PMR は BID4 の Binding
Update を代行して行なう。事前に PMR が Binding Update を代行することを決めておく。
Binding Update を代行しない MR はこのメッセージを無視する。Binding Update は Alternate

38

HA

(2) Binding Update
.....
BID1

alternate CoA sub-option

BID2

BID3

BID4

CoA4
BID sub-option

BID4
CoA1
(3) NEL Advertisement
NEL_ADD

CoA4

PMR

non-PMR

non-PMR(1) NEL Advertisement
ADD_REQUEST
BID4
non-PMR’s address

BID4
non-PMR’s address

Mobile Network

Home Address
etc ...

Home Address
CoA4
etc ...

図 5.5: 冗長経路を利用した Binding Update

CoA sub-option に CoA4 を格納し、BID sub-option に BID4 を格納したものを送信する。
(3)Binding Update と Binding Acknowlegement を正常に処理した PMR は、Binding を更新できたことを他のノードに伝える。BID4 と CoA4 を含む、NEL ADD の NEL Advertisementを行なう。これによってすべての MR は、BID4 の Binding が更新されたことを知り、NEL へと追加する。また、BID4 の MR-HA 間トンネルを保持する MR は、トンネルを保持し続ける。

5.3.5

送信元または送信先が MR の通信

本システムでは、Binding Update に用いる Home Address として PMR と non-PMR で同一のものを使う。そのため、本研究では Home Address はノードを一意に識別する識別子でなく、同じ Mobile Network に所属する MR を表す識別子となる。そのため、PMR および non-PMR
を送信元または送信先にする通信には Home Address を用いず、Ingress インターフェイスのアドレスを用いる。本システムでは、Mobile IPv6 によるルーティングは行なわず、Network
Mobility のみによるルーティングを行なう。
また、図 5.6に示すとおり、送信先・送信元に MR の Ingress インターフェイスを用いることによって、PMR および non-PMR も冗長経路を選択できるなど MMRM の持つ利点を享受できる。Ingress インターフェイスのアドレスは Mobile Network 内部のアドレスであるからで
ある。

39

CN

HA
Internet
MR1

MR2

MR3

Ingress IF
Mobile Network

図 5.6: 送信元または送信先が MR の通信の例

5.3.6

複数経路を用いた負荷分散

MMRM では、図 5.7に示すとおり、Mobile network 内からの通信は全て PMR を経由する
ことがわかる。そのため、PMR がパケットを送る経路を定期的に変更することで、MR-HA 間
トンネルにかかる負荷を分散することが可能である。
図 5.7の例では、4 つの MR-HA 間トンネルが同等の帯域・遅延だったとすると 1 つのトンネ
ルに 4 分の 1 のトラフィックを分配すれば、各トンネルにかかる負荷は 4 分の 1 となる。また、通信相手から MNN へのトラフィックは HA が各 HA-MR 間トンネルに分配することで、負荷分散が可能である。

5.4

まとめ

MMRM は、MR 間のメッセージングを NEL Advertisement という、各自の Binding を広告するという仕組みによって構築した。また、複数 MR の Binding の状態を保持するため NEL というデータストラクチャを定義した。NEL Advertisement と NEL によって MR の参加・離脱に関する処理を実現した。また、alternate CoA sub-option や BID sub-option を用いた、Binding
Update を代行する処理も NEL Advertizement を利用することで実現した。
また、MMRM は BID による Binding 管理や、BID sub-option など、複数 CoA 登録の仕様を変更することなく設計した。これによって、より汎用的で上位の概念である複数 CoA 登録の仕様によって、Binding を扱うことができる。とくに HA の機能は全く変更を加えることなく設計されてる。そのため、HA では Mobile Network に所属する MR の数に関わらず、汎用

40

CN

HA
Internet
PMR

non-PMR

non-PMR

MNN
Mobile Network

図 5.7: PMR のパケット振り分けによる負荷分散

的に複数 CoA 登録を受け付けることが可能となっている。

41

第 6 章 Multiple Mobile Router
Management の実装
本章では本論文で実装した MMRM について説明を行なう。最初に動作の概要を説明する。その後、機能ごとの実装を説明する。

6.1

実装環境

MMRM は NetBSD1.6.2-RELEASE[18] 上で動作する SHISA[19] を拡張することで実装した。SHISA は 2004 年 11 月 15 日のスナップを用いた。本実装は、SHISA のデーモン群に新たに 1 つのデーモンを追加する形で行なった。なお、SHISA の紹介は付録 A.1に記した。

6.2

実装概要

MMRM は、本研究において SHISA に Multiple Mobile Router Management Daemon(MMRMD)として追加した。MR 側の MMRMD は、同一 Mobile Network に所属する他の MR と情報交換をし、ポリシのとおりに IPF と経路を書き換える。HA 側の MMRMD は BC の状態に応じて IPF のポリシを書き換える。本章では、まず MR、HA の両方の MMRMD 実装概要について説明を行なう。その後、各機能ごとの詳細な解説を行なう。なお、MR、HA のコードは同一のものであり、起動時のモード選択によって MR、HA の切替えを行なう。

6.2.1

MR 側の MMRMD 実装概要

起動時に MR モードを選択された MMRMD は、まず 2 つのソケットを開く。1 つは BUL の状態を監視するためのモビリティソケットであり、もう 1 つは Ingress インターフェイスからMR 間の情報交換を行なうための RAW ソケットである。モビリティソケットでは SHISA の提供する PF MOBILITY を用い、RAW ソケットは UDP の 11233 番ポートを利用する。次に、Ingress インターフェイスと指定されたインターフェイスのグローバルアドレスを取得し、自身の MR の識別子とする。mip0 インターフェイスについたアドレスを HoA とする。ここで、初期化が完了する。
図 6.1に MR 側と HA 側の MMRMD の動作概要を示した。MR 側の MMRMD は初期化終了後、MMRMD はモビリティソケットと Ingress インターフェイスを監視しており、受信メッ
セージに対する対応を行なう。モビリティソケットからは、BUL の追加・変更・削除のメッセー
ジが来る (図 6.1の (a))。MMRMD は BUL の追加・変更のメッセージに含まれる HoA、CoA、BID を取得し、NEL へと格納する。BUL の削除の場合は対応する NEL をリストから削除する。いずれの場合も、Ingress インターフェイスに向けて、NEL Advertisement を行なう (図426.1の (b))。
また、NEL ADD の NEL Advertisement を受け取った MMRMD は対応する NEL を追加または更新する (図 6.1の (c))。NEL REMOVE の NEL Advertisement を受け取った MMRMDは対応する NEL を削除する。NEL 追加・更新時にはライフタイムに指定されたタイマーを設定しておき、定期的な更新のない NEL を削除する。
また、MMRMD は NEL のステートが変わる毎に IPF のポリシをユーザのポリシによって書き換える (図 6.1の (d))。

6.2.2

HA 側の MMRMD 実装概要

起動時に HA モードを選択された MMRMD はモビリティソケットを開く。MMRMD はモビリティソケットを監視して、BC の追加・変更・削除を NEL へと格納する (図 6.1の (e))。NELに変更のあった時、NEL を参照し IPF のポリシをユーザのポリシによって書き換える (図 6.1の (f))。

HA

NEMONETD

Routing socket

Mobility Socket

setup tunnel
setup route

BC

NEL

HAD

MMRMD

(e)

(f)

RAW socket for MH

IPF Socket

NIC

setup policyBCBinding Acknowlagement
etc....

Binding Update
etc...

MR1

Egress IF

BUL

Mobility Socket(a)

MDD NEMONETDNEL Advertisement

Ingress IF

RAW socket for MH

Routing socket

kernelMobile Network

Internetsetup tunnel
setup routeuser land(b)

setup policy(c)

IPF Socket

RAW socket for UDP(d)Ingress IF

kernelRAW socket for UDP

user land

MRD

MMRMD

MMRMD

BUL

NEL

NEL

図 6.1: MMRM の概要

43

MR2

6.3

MR 側の MMRMD の機能

本節では、MR 側の MMRMD の機能である NEL の同期、複数経路の制御、ポリシールー
ティングについて説明する。

6.3.1

Neigbor Egress interface List の同期

図 6.2に NEL の同期に関する処理を行なう機能の実装概要を示す。各実線は、処理の流れを示す。各点線はデータベースへの操作を表す。図は 2 つの MR の MMRMD を示している。各
MMRMD は同一のものであるが、MR1 ではモビリティソケットのメッセージ受信から UDP
メッセージ送信までのみを示した。MR2 では UDP メッセージ受信からの処理のみを示した。
図 6.2中の機能を次に挙げる。

• NEL データベース
Neigbor Egress interface List。同一 Mobile Network に所属する MR の持つ Egress イン
ターフェイスの情報を格納したデータベース。HoA、CoA、BID、Ingress インターフェ
イスアドレスなどの対応づけを持つ。詳しくは、表 5.1で述べた。
• NMRL データベース
Neighbor Mobile Router List。現在の近隣の MR を格納するデータベース。Ingress イン
ターフェイスのアドレスによってエントリを識別できる。また、各エントリはタイマによる管理されており、定期更新のないエントリは削除される。
• mipsock input in mmrm 処理部
モビリティソケットを監視し、ソケットから受信するメッセージによって次の処理を決定する。MR 側の MMRMD においては、MIPM BUL ADD、MIPM BUL CHANGE、
MIPM BUL REMOVE のメッセージを受信し、処理する。
• nel add 機能
MR の BUL の追加・変更によって、NEL の追加・変更を行なう。NEL を BID によって検索し、BID が一致するエントリがある場合はそのエントリを更新する。また、一致す
るエントリがない場合は、新規のエントリを追加する。
• nel delete by bid 機能
MR の BUL が削除されると、対応する NEL の削除を行なう。NEL を BID によって検索し、BID が一致するエントリを削除する。
• nmrl add 機能
NMRL にエントリを追加・更新する。NMRL はタイマで削除される。そのため、有効な
近隣の MR のエントリはライフタイム以内に更新される。
• send nel 機能
自身の MR の NEL の追加・削除を知らせるため、NEL advertizement を行なう機能。メッセージは、UDP のポート 11233 を利用して NEL ADD と NEL REMOVE を送信する。

44

• mmrmsock input 処理部
UDP ソケットを監視し、ソケットから受信するメッセージによって次の処理を決定する。
NEL ADD と NEL REMOVE を受信し、処理する。
• nmrl refresh timer 機能
NMRL の定期の更新がなされているか管理する。そのため、NMRL 追加時のタイムから
ライフタイムが経過していないか監視する。
• nmrl delete 機能
期限の切れた NMRL を削除する機能。期限の切れた NMRL を MR の Ingress インターフェイスのアドレスで検索し、削除する。
• nel delete by addr 機能
NMRL が削除された時、対応する NEL も削除する機能。NEL を削除された MR のもつ
Ingress インターフェイスで検索し、一致する NEL エントリのすべてを削除する。

NMRL

MR1
MMRMD

(c)

add

timer
nmrl_refresh_timer

nmrl_add
nmrl_delete

NEL_REMOVE

send_neladd

NEL(i) delete

NEL_ADD
delete

(a)

(d)

(b)

nel_delete_by_bid(e)

nel_delete_by_addr(j)deletenel_add

NEL_REMOVE

nmrl_add

add

NEL

add

(f)

(g)
nel_addmmrmsock_input

NEL_ADDMR2
MMRMD

MIPM_BUL_ADD
MIPM_BUL_CHANGE

Mobility Socket

(h)

add

nel_delete_by_bid

mipsock_input_in_mmrm
MIPM_BUL_REMOVENMRLUDP Socket

NEL_REMOVE

NEL_ADDUDP Socket
UDP (port 11233)

図 6.2: NEL の同期

MR 側の MMRMD では、モビリティソケットから BUL 削除のメッセージを受信すると対応する NEL を削除する (図 6.2の (a))。モビリティソケットから BUL 追加・更新のメッセージを受信すると NEL データベースを更新し (図 6.2の (b))、NMRL データベースを更新する (図 6.2の(c))。その後、UDP ソケットによって、近隣の MR へと NEL ADD の NEL advertizement を行なう。このとき、NEL データベースを削除した場合は、NEL REMOVE メッセージを送信
し (図 6.2の (d))、NEL データベースを追加更新した場合は NEL ADD メッセージを送信する(図 6.2の (e))。
UDP ソケットから、NEL REMOVE のメッセージを受信すると、NEL を BID によって検索し、一致する NEL を削除する (図 6.2の (f))。MMRMD は UDP ソケットから NEL ADD のメッセージを受信すると、NEL 情報を NEL データベースへと格納する。このとき、NEL を

45

BID によって検索し、一致する NEL がある場合は更新を行なう (図 6.2の (g))。その後、NMRLを追加または更新する。NMRL の追加の際は、タイマによって期限切れの NMRL を削除できるようにする。NMRL の更新の際は、タイマの期限を更新する ((図 6.2の (h))。
MR 間をつなぐリンクが断絶し、UDP のメッセージが届かなくなると、NMRL のタイマが期限切れとなる。期限の切れた NMRL エントリは削除される (図 6.2の (i)) 。またその後、期限の切れた MR のもつ Egress インターフェイスを登録した NEL エントリはすべて削除する ((図6.2の (j))。

6.3.2

複数トンネルの管理

図 6.3に複数トンネルの管理の実装概要を示す。各実線は処理の流れを示す。各点線はデータベースへの操作を表す。図は、MR で実行される MMRMD と NEMONETD である。MMRMDのトンネル管理は SHISA デーモン群の 1 つである NEMONETD を参考にした。図では比較のため、NEMONETD も描画した。MMRMD は UDP メッセージの受信から、トンネルの生成・削除までの流れを示した。

HA

MR

MR

NEMO tunnel

NEMO tunnel

NEMO tunnel

NEMO tunnel

BID1

BID2

BID3

BID4

Egress Interface

Ingress Interface

Egress Interface

setup

delete

(a)

setup

(b)

nemo_tun_set
nemo_tun_set

nemo_tun_del

nemo_tun_dellookupmmrmsock_input
lookup
NEMO IF

deleteNEMO IFmain

NEMONETD

NEL_ADD

NEL_REMOVEUDP Socket

MMRMD
MR

図 6.3: 複数トンネルの制御

図 6.3中の機能を次に挙げる。

• NEMO IF データベース
NEMO トンネルのインターフェイス名と BID の対応づけを保持するデータベース。初期
化時に設定ファイルを読み込むことで作成される。
• mmrmsock input 処理部
UDP ソケットを監視し、ソケットから受信するメッセージによって次の処理を決定する。
NEL ADD と NEL REMOVE を受信し、処理する。
46

• nemo tun set 機能指定されたトンネル先とトンネル元、インターフェイス名に応じた NEMO トンネルを生成する。
• nemo tun del 機能指定されたインターフェイス名のトンネルを削除する。
MR の MMRMD は UDP ソケットから受信したメッセージによってトンネルを生成・削除する。
UDP ソケットから NEL ADD を受信した際、NEMO IF データベースを検索し、BID に対応づけられたインターフェイス名を取得する。その後、Ingress インターフェイスから近隣のMR の Ingress インターフェイスへとトンネルを生成する (図 6.3の (a))。
UDP ソケットから NEL REMOVE を受信した際、NEMO IF データベースを検索し、BIDに対応づけられたインターフェイス名を取得する。その後、取得したインターフェイス名のトンネルを削除する (図 6.3の (b))。
図 6.3に示すとおり、MMRMD の仕組みは MR-HA 間トンネルを管理する NEMONET と共通のものとした。そのため、MR-HA 間トンネルと MR-MR 間トンネルは同一の仕組みで扱うことができる。MR-HA 間トンネルと MR-MR 間トンネルの抽象化が可能となった。

6.3.3

ポリシールーティング

図 6.4にポリシールーティングの仕組みついて示した。各実線は処理の流れを示す。各点線
はデータベースへの操作を表す。図は、MR 上のデータの流れを示し、MMRMD の動作を示
した。

HA

MR

MR

NEMO tunnel

nemo0

BID1

BID2

BID3

BID4

nemo1

nemo2

nemo3

nemo4

lookup

ipf policy

MMRMDchangeIP Filter

ip_output

lookuprouting tableMRchange_ipf_policydata

NEL nel change
図 6.4: ポリシールーティング47

図 7.3中の機能を次に挙げる。

• change ipf policy 機能
NEL のエントリが追加・更新・変更されたときに IPF ポリシを変更する。
MR は常にデフォルトルートを”nemo0” インターフェイスへと設定しておく。MR の転送するパケットはすべて nemo0 のトンネルに送信される。nemo0 から送出されるパケットは、IP
Filter によって転送先が決定される。IP Filter は IPF ポリシによって決定されている。
MMRMD は NEL の追加・更新・削除に応じて IPF のポリシを変更する。どのように変更するかは事前に設定しておく必要がある。
MMRM 実装では、図 6.4の MR-HA 間トンネルと MR-MR 間トンネルに示すように、両者を抽象化した。IP Filter という統一の仕組みでポリシールーティングが可能となるため、ポリシの記述が容易である。また、MMRM 実装は IP Filter の機構を用いたことで、より詳細なポリシの記述を、より簡易なユーザインターフェイスによって提供できた。

6.4

HA 側の MMRMD の機能

本節では、HA 側の MMRMD を示す。各実線は処理の流れを示す。各点線はデータベース
への操作を表す。図は、HA 上のデータの流れを示し、HA 側の MMRMD の動作を示した。

BID1

nemo1

BID2

BID3

nemo2

nemo3

NEMO tunnel

changeIP Filter

lookup

ipf policy

add

NEL
nemo0

ip_outputchange_ipf_policy

deletenel_delete_by_bid

lookupnel_add

mipsock_input_in_mmrm

routing table

MIPM_BC_CHANGE

data

MIPM_BC_ADD
MIPM_BC_CHANGE

MMRMD

HA

Mobility Socket

図 6.5: HA 側の MMRMD の機能

図 6.5中の機能は MR 側の MMRM と同一コードを利用したため、省略する。
HA 側の MMRMD はモビリティソケットを監視する。モビリティソケットからは MIPM BC ADD、
MIPM BC CHANGE、MIPM BC REMOVE のメッセージを受信し、処理する。BC の追加・
更新のメッセージを受信すると、BC 情報を NEL へと格納する。BC の削除のメッセージを受48

信すると、NEL を BID によって検索し一致する NEL を削除する。NEL の追加・更新・削除の処理を行なった後、IPF ポリシを書き換える。
HA のデフォルトルートは常に nemo0 へと設定される。よって、HA から Mobile Network
へとの転送するパケットはまず、nemo0 へと送られる。nemo0 から送出されるパケットは、IP
Filter によって、HA-MR 間トンネルへと送出される。HA 側の MMRMD は NEL の状態によって動的に IPF ポリシを書き換えることでポリシールーティングを実現する。

49

第 7 章 評価
本章では、本研究で実装した MMRM の評価を行う。定性評価では、要求事項を満たす動作が可能か確認を行なう。定量評価では、スループットや RTT などを測定し、本システムが動作した際の性能を確認する。

7.1

評価環境

本研究では、本システムの定性的評価および定量的評価を行なうため、評価環境を構築した。
本節では、評価環境の構成とネットワーク性能について述べる。

7.1.1

評価環境の構成

評価実験は想定しない通信が測定に影響しないように、図 7.1 に示すようなローカルな IPv6
ネットワークを構築して行なった。
2001::/64
2001::1

2001::2

router1

router2

2001:1::1

2001:1::2

HArouter3

2001:2::1

2001:1::/64

2001::4

2001::3
2001:3::1

2001:2::/64

2001:2::EUI64

2001:3::/64

2001:3::EUI64

MR1

router4(HoA 2001::1111)

2001:1:0:1::1

2001:3::EUI64

MR2(HoA 2001::1111)

2001:4::1
2001:4::/64
2001:4::3

CN

2001:1:0:1::2
2001:1:0:1::/64

2001:1:0:1::EUI64

MNN1

Bandwidth:
1200Kbits/sec

図 7.1: 定性評価の実験環境

図 7.1の線は Ethernet ケーブルで構成されており、点線で示されている Ethernet ケーブルは帯域を 1200 Kbits/sec に制限した。これは複数ルータを用いてスループットの測定を行なった際、HA や CN がボトルネックとならないようにするためである。帯域制限には NEC 社製
CX2510 広域 Ether 対応レイヤ 2 スイッチ [20] を用いた。また、各 router は 5 秒ごとにルータ
広告を行なっている。

50

7.1.2

評価環境のネットワーク性能

本システムの性能を測定を行なうため、評価の前提となる評価環境の性能を測定する必要がある。そこで、本節では、本システムを動作させない状態での評価環境の性能を確認する。
NEMO を動作させない状態での測定と NEMO を動作させた状態の性能を測定した。また、
実験環境のスループットと遅延を調べた。いずれも 1200 Kbits/sec の帯域制限された経路を経由するように実験した。計測は以下のように行なった。
NEMO 無効時のスループットの測定は iperf を用いた。CN を iperf のサーバとして” iperf-s -V” を実行した。また、MR1 および MR2 を iperf のクライアントとして”iperf -c 2004:4::4-i 2 -t 100 -f k” を実行した。100 秒間のスループットの平均を図 7.2の表に示した。遅延の実
験は、MR1 または MR2 から CN へと ping6 プログラムを実行した。1 秒おき 100 回の 56Byteのパケットを送信した際の平均の RTT を計測した。
NEMO 有効時のスループットの測定は、同様に MNN から CN まで、iperf を用いて行なった。100 秒間のスループットの平均を図 7.2の表に示した。遅延の測定は NEMO 有効時と同様に MNN と CN 間で行なった。
結果を図 7.2の右の表にまとめる。
NEMO を無効にして計測した (A)、(B)、(C) と NEMO を有効にして計測した (D)、(E)、(F)
で計測の値に違いが出た。NEMO を無効とした計測では、パケット転送は 3 ホップであるのに対し、NEMO を有効とした際の計測では、7 回のパケット転送が行なわれる。更に、NEMOを有効にした際の計測には、MR と HA においてパケットのカプセル化、脱カプセル化が行なわれるためオーバーヘッドがかかる。そのため、スループットは 301 Kbits/sec 減少した。また、RTT は 1.319m ミリ秒増加した。
ホップ数が 3 から 7 になったことでスループットは約 20%減少し、RTT は約 2 倍になった。
これは、測定結果としては想定されるとおりであるため、本実験環境は評価環境として妥当である。

disable NEMO

enable NEMO

HA

CN

HA

CN

router1

router4

router1

router4

router2(A)
MR1

router3

(B)

(C)
MR2

router2

router3

(E)

(D)

(F)

MR1

MR2

Bandwidth

Delay (RTT)(A)

1239 Kbits/sec

1.124 ms(B)

1229 Kbits/sec

1.334 ms(C)

1234 Kbits/sec

1.096 ms(D)

1071 Kbits/sec

2.381 ms(E)

723 Kbits/sec

2.762 ms

(F)

1004 Kbits/sec

2.369 ms

MMN

図 7.2: 実験環境のスループットおよび RTT の計測

51

また、各 PC の性能を表 7.1に整理した。MR1 および MR2 の Ingress インターフェイスは10BASE-T、その他のリンクは 100BASE-T である。複数 MR の性能が同じであるので、本システムの測定への影響は、無視できるとした。
表 7.1: 定性的評価の各 PC の構成
CPU
メモリ

HA
MR1
MR2
CN
MNN1
Router7.2

PentiumIII 1.0GHz
PentiumIII 1.0GHz
PentiumIII 1.0GHz
Pentium M 1.0GHz
PentiumIII 868.25MHz
AMD Enhanced Am486X4

256M
640M
640M
256M
256M
64M

OS
NetBSD 1.6.2-RELEASENetBSD 1.6.2-RELEASENetBSD 1.6.2-RELEASE
FreeBSD 4.10-RELEASENetBSD 1.6.2-RELEASE
FreeBSD 4.9-RELEASE

定性的評価

本節では、本システムの設計の正当性を検証するために、MR 側と HA 側の MMRMD および SHISA デーモン群を動作させ、評価を行う。
本研究で設計したシステムが、要求事項を満たすか検証する。

7.2.1

評価実験の概要

本研究では、定性的評価として、第 2.4.4に挙げた要求事項を満たしているかの確認を行なう。
要求事項の「他の計算機の接続性を用いて Binding を通知できること」および「Mobile Networkの分割の処理を考慮すること」を満たす機能は実装していない。そのため、評価を行なわない。
定性的評価として、以下の機能を確認する実験を行なう。

1. ポート番号による通信の振り分けが可能
2. すべての接続性が利用可能
3. 利用する接続性を動的な変更が可能
4. 利用する接続性の変更がアプリケーションに影響しない

ポート番号による通信の振り分けが可能
本実験ではポート番号によって通信を振り分け可能であることを示す。
実験には図 7.1に示した実験環境を用いた。本実験では、ポート番号での振分けを示すため、
MNN から CN へポート 1500 番とポート 2500 番 traceroute6 プログラムを実行し、経路が変わることを示す。
MR1 の通信振分けのための IPF ポリシを図 7.3に示すように設定した。MR1 はポート番号
1500 番の通信を MR2 へと転送する。また、ポート番号 2500 番の通信を HA へ転送する。

52

以上の環境で MNN から traceroute6 プログラムを用いて CN までの経路を確認した。ポー
ト番号 1500 番を指定した traceroute6 は図 7.4の (a) にある出力を得た。MNN から CN への経
路には MR1 および MR2 を経由していることがわかる。次に、ポート番号 2500 番を指定した
traceroute6 は図 7.4の (b) にある出力を得た。MNN から CN への経路には MR1 のみを経由していることがわかる。
以上に示したとおり、本システムはポート番号によって通信の経路を変更することが可能であることが確認できた。
¶

CN(a) UDP ポート 1500 番
MNN# traceroute6 -p 1500 2001:4::4
traceroute6 to 2001:4::4 (2001:4::4) from 2001:1:0:1:280:45ff:fe45:d1ab,
30 hops max, 12 byte packets
1 2001:1::1111 0.623 ms 0.495 ms 0.487 ms(MR1)
2 2001:1::1111 1.012 ms 0.954 ms 0.951 ms(MR2)
3 2001:1::a00:1fff:feb1:3865 2.096 ms 1.820 ms 1.827 ms(HA)
4 2001:1::1 2.260 ms 2.274 ms 2.212 ms(router)
5 2001::4 2.861 ms 2.749 ms 2.756 ms(router)
6 2001:4::4 2.834 ms 2.834 ms 2.826 ms
(CN)

HA

IPFpolicy
port = 2500

MR1

MR2
IPF policy
port = 1500

MNN
図 7.3: 通信の分配ポリシ(b) UDP ポート 2500 番
MNN# traceroute6 -p 2500 2001:4::4
traceroute6 to 2001:4::4 (2001:4::4) from 2001:1:0:1:280:45ff:fe45:d1ab,
30 hops max, 12 byte packets
1 2001:1::1111 0.546 ms 0.493 ms 0.488 ms(MR1)
2 2001:1::a00:1fff:feb1:3865 1.816 ms 1.357 ms 1.289 ms(HA)
3 2001:1::1 1.765 ms 1.722 ms 1.782 ms(router)
4 2001::4 2.368 ms 2.265 ms 2.291 ms(router)
5 2001:4::4 2.401 ms 2.315 ms 2.343 ms(CN)µ図 7.4: tracerout6 による経路の表示

すべての接続性が利用可能
本実験では、複数 MR の持つすべて接続性が利用可能であることを示す。
実験は、図 7.1に示した実験環境を用いた。本実験では、複数の MR の持つ接続性のうち 1 つだけを接続した状態で、MNN が CN にアクセスできることを確認する。この際、MNN が CNにアクセスできれば、1 つ残した接続性は利用できることが示せる。この実験を複数 MR の持
つすべての接続性に対して行なうことで、すべての接続性が利用可能であると示す。
図 7.5に実験のトポロジを示した。図 7.5の (A) 以外の Ethernet ケーブルを抜いて、(A) のみで通信を行なえるようにした。MNN から CN へ traceroute6 プログラムを実行し、図 7.6の出力を得た。
次に、図 7.5の (B) 以外の Ethernet ケーブルを抜いて、(B) のみで通信を行なえるようにした。MNN から CN へ traceroute6 プログラムを実行し、図 7.6の出力を得た。
最後に、図 7.5の (C) 以外の Ethernet ケーブルを抜いて、(C) のみで通信を行なえるようにした。MNN から CN へ traceroute6 プログラムを実行し、図 7.6の出力を得た。
以上に示したとおり、本システムでは通信可能なすべての接続性を利用することが可能であることが確認できた。

53

³

´

¶

(A) のみ、Ethernet ケーブルを接続
MNN# traceroute6 2001:4::4
traceroute6 to 2001:4::4 (2001:4::4) from 2001:1:0:1:20d:5eff:fe48:2b9d,
64 hops max, 12 byte packets
1 2001:1::1111 1.062 ms 0.527 ms 0.501 ms(MR1)
2 2001:1::a00:1fff:feb1:3865 1.657 ms 1.436 ms 1.383 ms(HA)
3 2001:1::1 1.769 ms 1.856 ms 1.752 ms(router)
4 2001::4 2.445 ms 2.347 ms 2.332 ms(router)
5 2001:4::4 2.345 ms 2.428 ms 2.273 ms
(CN)

CN
HA

(A)

(B)

MR1

(C)

MR2

MNN
図 7.5: 実験のトポロジ³(B) のみ、Ethernet ケーブルを接続
MNN# traceroute6 2001:4::4
traceroute6 to 2001:4::4 (2001:4::4) from 2001:1:0:1:20d:5eff:fe48:2b9d,
64 hops max, 12 byte packets
1 2001:1::1111 1.02 ms 0.498 ms 0.49 ms(MR1)
2 2001:1::a00:1fff:feb1:3865 2.12 ms 2.002 ms 1.832 ms(HA)
3 2001:1::1 2.483 ms 2.461 ms 2.255 ms(router)
4 2001::4 2.968 ms 2.896 ms 2.789 ms(router)
5 2001:4::4 2.86 ms 2.847 ms 2.82 ms(CN)(C) のみ、Ethernet ケーブルを接続
MNN# traceroute6 2001:4::4
traceroute6 to 2001:4::4 (2001:4::4) from 2001:1:0:1:20d:5eff:fe48:2b9d,
64 hops max, 12 byte packets
1 2001:1::1111 0.556 ms 0.621 ms 0.494 ms(MR1)
2 2001:1::1111 1.444 ms 1.021 ms 0.962 ms(MR2)
3 2001:1::a00:1fff:feb1:3865 2.163 ms 2.179 ms 2.119 ms(HA)
4 2001:1::1 2.594 ms 2.598 ms 2.545 ms(router)
5 2001::4 3.129 ms 3.129 ms 3.108 ms(router)
6 2001:4::4 3.147 ms 3.173 ms 3.101 ms(CN)µ図 7.6: tracerout6 による経路の表示利用する接続性を動的な変更が可能
本実験では、利用する接続性を動的に変更できることを示す。
実験は、図 7.1に示した実験環境を用いた。本実験では、利用できる接続性が 1 つの時から、3 つに増えるまでの MNN のトラフィックを観測する。この時、MNN は MR の接続性のスルー
プット限界までトラフィックをかける。利用できる接続性が増えれば、トラフィック量も増える。トラフィック量が増えることで利用する接続性を動的に変更できることを示す。
本実験では、CN を iperf のサーバとして” iperf -s -V” を実行した。また、MNN を iperf のクライアントとして”iperf -c 2004:4::4 -i 3 -t 600 -f k” を実行した。MNN ではポート番号を5001 番、5002 番、5003 番に指定した iperf を実行した。
0 秒から 300 秒では、(B) と (C) の Ethernet ケーブルを抜いて、測定を行なった。そのため、
MNN の実行する合計 3 つ実行した iperf はすべて、図 7.7の (A) を経由する。300 秒から 600
秒では、(B) と (C) の Ethernet ケーブルを接続した。また、図 7.7に示したように、ポート番
号によって通信を振り分けるポリシを設定した。
図 7.8に iperf の出力を処理し、グラフにまとめた。グラフでは、測定開始から 300 秒を境にスループットが向上している様子がわかる。これは、(B) と (C) の Ethernet ケーブルが接続された直後に通信の振分けが開始されたことを示している。
以上に示したとおり、本システムでは利用する接続性を動的に変更することが可能であることがが確認できた。

54´

bandwidth (kbits / sec)

CN
HA
(A)

(B)

(C)

port 5001

port 5002

port 5003

4000
port 5001
port 5002
port 5003

3500

3000

2500

2000

1500

MR1

MR2

1000

500

MNN

0

0

100

200

300

400

500

time (sec)

図 7.7: 実験のトポロジ
図 7.8: スループットの計測利用する接続性の変更がアプリケーションに影響しないこと
本実験では、通信中に利用する接続性を変更してもアプリケーションに影響しないことを示す。
実験は、図 7.1に示した実験環境を用いた。本実験では、MNN と CN が通信中にに MR が移動ネットワークに参加・離脱する実験を行なった。MR が参加・離脱することで利用する接続性が変更される。通信を行なうアプリケーションは、ビデオストリーミング、WEB カメラ、車の情報をサーバに送信するプログラムを用いた。
図 7.9に実験のトポロジを示した。まず、始めに MNN が MR2 の接続性を利用して通信している際に、図 7.9の (A) ケーブルを抜いた。その後、経路が図 7.9のように変更される。この時、アプリケーションのセッションが継続された。
また、MNN が MR2 の接続性を利用して通信している際に、図 7.9の (B) ケーブルを抜いた。
その後、経路が図 7.9のように変更される。この時、アプリケーションのセッションが継続された。
この実験は 11 月 23,24 日の SFC Open Reserch Forum 2004(ORF2004) において実施した。
MR の参加・離脱により、利用するトンネルが変更されても、ビデオストリーミングやその他のアプリケーションによる通信が途切れなかった。詳細は A.2に記した。
よって、接続性の管理を動的に行なうことが可能であった。また、利用するトンネルの変更
は上位の層に透過的であることがわかった。

55

600

CN

CN

HA

HA
(B)

MR1

MR1

MR2

MR2

(A)

MNN

MNN

図 7.9: 利用する接続性を変更する実験

7.2.2

定性評価のまとめ

本節では、本システムが以下の機能をもつことを示した。

1. ポート番号による通信の振り分けが可能
2. すべての接続性が利用可能
3. 利用する接続性を動的な変更が可能
4. 利用する接続性の変更がアプリケーションに影響しないこと
これによって、表 7.2の要求事項が満たされたことを確認できた。
表 7.2: 要求事項の充足
要求事項

実験

残存トンネルを利用し、経路変更は上位の層に透過的であること利用するトンネルを選択できること
各 MR が同じ決定にしたがって動作すること
複数の Binding を登録できること
計算機の持つ接続性の管理を動的に行なうこと
エンドノードに複数接続性の共有機能を必要としないこと

7.3

4
1
1, 2, 3, 4
1, 2, 3, 4
3
1, 2, 3, 4

定量的評価

本節では、本システムの性能測定を行なう。本システムを動作する前と動作したときのスルー
プットを計測し、どれだけスループットの変化を測定する。また、本システムにかかるオーバー56

ヘッドを計測する。本システムを NEMO 基本サポートと比べる。RTT とスループットを計測し、本システムが行なうパケット転送によるオーバーヘッドを測定する。

7.3.1

スループットの計測

本実験では、本システムを動作させると NEMO 基本サポートと比較して、スループットが向上することを示す。また、どれぐらいのスループット向上が見られるか確認する。
実験は、図 7.1に示した実験環境を用いた。本実験では、複数の MR の持つ接続性が 1 つの場合と 3 つの場合のスループットを計測して比較する。
本実験では、CN を iperf のサーバとして” iperf -s -V” を実行した。また、MNN を iperf のクライアントとして”iperf -c 2004:4::4 -i 3 -t 600 -f k” を実行した。MNN ではポート番号を5001 番、5002 番、5003 番に指定した iperf を同時に 3 つ実行した。

(A)

CN

CN

HA

HA

(B)

(C)

port 5001
port 5002
port 5003

MR1

MR2

(A)

(B)

(C)

port 5001

port 5002

port 5003

MR1

MNN

MR2

MNN

0 sec - 300 sec

300 sec - 600 sec

図 7.10: 実験のトポロジ

0 秒から 300 秒では、(B) と (C) の Ethernet ケーブルを抜いて、測定を行なった。そのため、
MNN の実行した合計 3 つ実行した iperf はすべて、図 7.10の (A) を経由する。300 秒から 600
秒では、(B) と (C) の Ethernet ケーブルを接続した。また、図 7.10に示したように、ポート番
号によって通信を振り分けるポリシを設定した。
図 7.11に 3 つの経路のスループットを合計したもののグラフを示す。0 秒から 300 秒までは、
スループットは平均 1086 Kbits/sec であった。300 秒から 600 秒まででは、3 つの経路が利用可能となり平均のスループットは 2586Kbits/sec に向上した。これによって、本システムは利用可能な帯域を増大することが確認できた。

57

bandwidth (kbits / sec)

4000
port 5001
port 5002
port 5003

3500

3000

2500

2000

1500

1000

500

0

0

100

200

300

400

500

time (sec)600

図 7.11: MMRM の概要

7.3.2

オーバヘッドの計測

本システムでは、複数 MR を利用する際に MR 間でパケットの転送が行なわれる。本節では、MR 間パケット転送にかかるオーバーヘッドを計測する。実験は NEMO 基本サポートと本システムを比較することで、オーバーヘッドの程度を明らかにする。RTT とスループットに影響するオーバーヘッドを計測する。
RTT とスループットの両方の実験で、図 7.1に示した実験環境を用いた。RTT の実験は、MNN から CN へと ping6 プログラムを実行した。1 秒おき 100 回の 56Byte のパケットを送信した際の平均の RTT を計測した。また、スループットの実験では、CN を iperf のサーバとして” iperf -s -V” を実行した。また、MNN を iperf のクライアントとして”iperf -c 2004:4::4 -i
3 -t 600 -f k” を実行した。
RTT とスループットの結果を図 7.12にまとめた。RTT は、本システムを動作した場合、動作しない場合に比べて、0.479 ミリ秒増えた。本システムでは、ルータが 1 ホップ増えるため、RTT が増えるが、複数 MR を利用できるメリットと比較して無視できる程度である。同様にス
ループットは 80Kbits/sec 減少したが、複数 MR を利用できるメリットと比較しオーバーヘッ
ドは無視できる程度であった。

58

Basic NEMO suppot

MMRM support

CN

CN

HA

HA

MR1

MR2

MR1

MNN

MR2

MNN

RTT: 2.381 ms
Bandwidth : 1071 Kbit/sec

RTT: 2.860 ms
Bandwidth : 991 Kbit/sec

図 7.12: オーバーヘッドの計測

7.3.3

考察

本システムを動作させる事によって、MNN の利用可能な帯域は 1086 Kbits/sec から 2586
Kbits/sec へと向上した。これによって本システムが帯域を向上させる事を示した。
しかし、MMRM を動作させない場合は MNN は 1 つの経路のみを利用するのに対して、実験では MMRM を動作する事で、3 つの経路を利用可能となる。3 つの経路は、すべて同じ帯域が利用可能であるため、MMRM を動作させた時の理想的な値は、1086 x 3 = 3258 Kbits/secとなる。しかし、MMRM を動作した場合の実測値は、2586Kbits/sec であり、理想値との間に672Kbits/sec の乖離が見られる。
実験において本システムのオーバーヘッドが 80Kbits/sec であったことを考慮し、仮に 1 つの経路につき 80Kbits/sec のオーバーヘッドがかかると推定した場合、MMRM には 80 x 3 =240 Kbits/sec のオーバーヘッドがかかると推定される。しかし、実験によるオーバーヘッド
は、672Kbits/sec のオーバーヘッドを計測したため、MMRM には定量評価において想定した以外のオーバーヘッドがかかっていることが示された。
今後の研究で、本システムにかかるオーバーヘッドを解明し、改善する。

7.4

まとめ

定性評価で、本システムは本研究で実装した MMRM では未実装の機能を除いたすべての要求事項を満たしたことを確認した。
定量評価では、本システムによって向上するスループットを測定し、有効性を示した。また、

59

本システムにかかるオーバーヘッドが、RTT とスループットにおいて無視できる程度であることを示した。
しかし、本研究で想定しないオーバーヘッドが観測されたため、今後、解明と改善を行なう予定である。

60

第 8 章 結論
本章では、まとめと今後の課題を挙げ、本論文の結論とする。

8.1

まとめ

本研究によって、移動計算機群において接続性を持つ計算機が存在する時、すべての計算機がその接続性を利用できるようになった。また、接続性を持つ計算機が複数存在する時、トラフィックを複数経路へ分散することが可能となった。これによって、車内の計算機の通信の安定性を改善でき、帯域を増大することができた。また、これらの機構は既存の IPv6 ノードにたいして新たな機能の追加や変更を必要とすることなく構築できた。そのため、本研究で構築したシステムは計算機群に持ち込まれる計算機すべてにこれらの利点を提供できる。
複数 MR の利用は、接続性の共有は複数 CoA 登録における MR を拡張することで実現した。
これによって、HA は MR が単一であるか、複数であるかに関わらず同一の仕組みによって複数 CoA を登録することが可能となった。
本システムを用いれば、携帯電話や PDA などの既存のインターネット接続性を利用して、自動車をインターネットへ接続できる。既存のインターネット接続性を自動車に供与することで、インターネット自動車の普及が期待できる。

8.2

今後の課題

今後の課題として、実用性、セキュリティの対応、負荷分散、標準化への議論などが挙げられる。
本システムの実用性として、本システムを自動車に設置し、運用を行なう。インターネット
自動車プロジェクトの実証実験において本研究を用いることで、システムの改良を行なう。 具
体的には、実際のフィールドで実験を行なうことで無線メディアの特性を考慮したシステムの構築を行なう必要が生じる。また、ポリシを記述するインターフェイスを充実することで、利便性を向上させる。
本研究のセキュリティ対策として、MR 間の認証、non-PMR と HA 間の認証を検討する。
NEMO においては、Bi-directional トンネルは IPsec で守られることで、セキュリティを確保する。本システムにおいて、MR-MR 間トンネル、MR-HA 間トンネルを IPsec で守る機構を検討する必要がある。とくに悪意のあるユーザのが NEL 情報を登録することは、通信不能を引き起こすため検討する必要がある。
本システムにおいて、複数トンネルを用いてトラフィック分散を行なうことができる。帯域や遅延など特性の違うメディアを利用して複数トンネルを同時利用する場合、パケットの到着
順序が一様にならない。そのため、TCP など上位の層を考慮したトラフィック分配の仕組みが必要となる。今後は、トラフィック分配の仕組みなどを検討する。

61

本システムを普及するに当たって、複数のプラットフォーム上の実装が相互に接続する必要が生じる。これらを実現するためには、技術の標準化が必要不可欠である。そのため、本シス
テムの標準化を目指す。まず、NEMO WG においてインターネットドラフトを執筆し、本システムに対する議論を行なう。また、標準化の議論でプロトコルを精査する過程で、さらに本システムの改善が期待できる。

62

謝辞
本論文の作成にあたり，御指導いただきました慶應義塾大学環境情報学部教授 村井純博士、並びに同学部教授 徳田英幸博士、同学部助教授 楠本博之博士、同学部助教授 中村修博士、同学部専任講師 南政樹氏に感謝致します。
卒業論文の全般を通してお世話になりました、慶應義塾大学大大学院 政策・メディア研究科
講師 植原啓介博士、同大学院 政策・メディア研究科助手 湧川隆次博士、同大学院 政策・メディア研究科 訪問研究員 Thierry Ernst 博士、政策・メディア研究科研究員 渡辺恭人博士、同大学院 政策・メディア研究科助手 佐藤雅明氏に深く感謝致します。
多くの御指導と御助言をいただきました、慶應義塾大学大大学院 政策・メディア研究科 博士過程 三屋光史朗氏、同大学院 修士過程 渡里雅史氏、同大学院修士過程 小柴晋氏、同大学院修士過程 岡田耕司氏に感謝致します。
Multihoming の予備実験を共に行ない、議論した Korea Telecom 社 EunKyoung Paik 博士、
慶應義塾大学 村井研究室研究員 Romain Kuntz 氏に感謝致します。ORF2004 でのデモンスト
レーションの準備や説明員をしてくれるなど、いつも助けていただいた慶應義塾大学 環境情報学部 中村友一氏、評価実験において夜通し助けていただいた同学部 苧坂 浩輔氏に感謝致します。
非常にシンプルかつ拡張性に富む SHISA の実装のおかげで、本研究のアイデアを容易に実装できました。株式会社 インターネットイニシアティブ 島慶一氏、日本電気 株式会社 百瀬剛氏をはじめ SHISA 開発メンバの皆様に感謝致します。
また、いつも同じ部屋で卒業論文を書いていて、互いの論文を参考にし不備を指摘しあった
同期の友人 遠山祥広氏に深く感謝致します。
そして、本論文の作成にあたって御協力していただいた慶應義塾大学 徳田・村井・楠本・中村・南合同研究室の皆様に感謝致します。とくに、週 1 回のミーティングにおいて本論文を書くに当たっての相談を聞いていただき、適切なアドバイスを与えて下さった NACM 研究グルー
プの皆様に感謝致します。

63

参考文献
[1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6, June 2004.
[2] Vijay Devarapalli, Ryuji Wakikawa, Alexandru Petrescu, and Pascal Thubert. Network
Mobility (NEMO) Basic Support Protocol, June 2004. IETF work in progress.
[3] インターネット ITS 評議会 (InternetITS), January 2005. http://www.internetits.org/.
[4] イ ン タ ー ネット 自 動 車 プ ロ ジェク ト,
http://www.sfc.wide.ad.jp/InternetCAR/.

January2005.

[5] 遠山祥広 , 塚田学 , 植原啓介 , 砂原秀樹 , 村井純. インターネット自動車のテストベッドの構築と評価, November 2004. 情報処理学会研究報告 第 6 回ユビキタスコンピューティ
ングシステム pp.37–pp.43.
[6] The Internet Engineering Task Force, January 2005. http://www.ietf.org/.
[7] NEMO
Network
Mobility
Working
http://www.ietf.org/html.charters/nemo-charter.html.

Group,

January

2005.

[8] T. Ernst, N. Montavont, R. Wakikawa, E. Paik, C. Ngand K. Kuladinithi, and T. Noel.
Goals and Benefits of Multihoming, July 2004. IETF work in progress.
[9] C. Ng, E. Paik, and T. Ernst. Analysis of Multihoming in Network Mobility Support,
October 25 2004. IETF work in progress.
[10] 日野哲志, 湧川隆次, 植原啓介, and 村井純. 複数の移動計算機による協調通信機構の設計と実装, 2001.
[11] R.Draves and D.Thaler. Default Router Preferences and More-Specific Routes, October
11 2004. IETF work in progress.
[12] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6),
December 1998.
[13] 伊藤陽介, 小山健二, 太田賢, and 石原進. Mobile IP を用いた通信回線共有方式の実装,
July 2003. マルチメディア，分散，協調とモバイル（DICOMO2003）シンポジウム論文集, 情報処理学会シンポジウムシリーズ, Vol.2003, No.9, pp.97-100 (2003-6).
[14] 小西洋佑, 石原進, 水野忠則. 通信回線共有方式のためのクラスタ資源管理に関する検討, 2002. 情報処理学会研究報告モバイルコンピューティングとワイヤレス通信研究会,
2002-MBL-23, Vol.2002, No.115, pp1968-1976(2002).
64[15] Cho Seongho, Na Jongkeun, Kim Chongkwon, Lee Sungjin, Kang Hyunjung, and Koo
Changhoi. Neighbor MR Authentication and Registration Mechanism in Multihomed
Mobile Networks, April 2004. IETF work in progress.
[16] T.Ernst and H.Lach. Network Mobility Support Terminology, May 2003. IETF work inprogress.
[17] Wakikawa Ryuji. Multiple Care-of Addresses Registration, 19 Jun 2004. IETF work inprogress.
[18] The NetBSD Project, January 2005. http://www.netbsd.org/.
[19] SHISA (WIDEMIP), January 2005. http://www.mobileip.jp/.
[20] NEC 社製 CX2510 広域 Ether 対応レイヤ 2 スイッチ, January 2005. http://www.necglobalnet.com/products/cx2510mc.html.
[21] WIDE プロジェクト, January 2005. http://www.wide.ad.jp/.
[22] SFC-MIP, January 2005. http://www.wakikawa.net/Research/contents/mip6.html.
[23] KAME プロジェクト, January 2005. http://www.kame.net/.
[24] SFC OPEN RESEARCH FORUM 2004, January 2005. http://orf.sfc.keio.ac.jp/.

65

付 録A

A.1

SHISA の概要

SHISA は WIDE プロジェクト [21] で開発されていた SFC-MIP[22] と KAME-MIP[23] において Mobile IPv6 および Network Mobility の実装を統合したものである。二つの実装により培われた技術を統合し、より合理的な設計を目標に開発されている。SFC-MIP や KAME-MIP
では、Mobile IPv6 および NEMO の機能がカーネルによって実装されていたが、SHISA では各役割をもつデーモン間の協調によって動作するように実装されている。現在、Mobile IPv6、
NEMO basic support、複数 CoA 登録が動作する。本章では、NEMO basic support と複数CoA 登録についての実装を解説する。

図 A.1: SHISA トレードマーク

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、経路最適化の情報などを交換するためのインターフェイスである。それらの情報とそれらに付随する HoA、CoA など付随する情報をを通知することが可能である。
以下に 4 種類の各デーモンの説明を行なう。
• Mobile Router Daemon (MRD)
MR のみで動作するデーモン。おもに Binding の管理を行なう。BUL のタイムアウトのチェックを行ない、定期的に Binding Update を送信する。Binding の追加・更新・削除の情報はモビリティソケットを通じてカーネルへと通知される。
• Movement Detection Daemon (MDD)
MR のみで動作するデーモン。ルーティングソケットを監視し移動を検知する。移動情報66

はモビリティソケットを通じて MRD へと通知される。MDD は、移動を検知するために監視するインターフェイスを指定して実行される。

• NEMO network Daemon (NEMONETD)
MR、HA の両方で動作するデーモン。モビリティソケットを監視することで、Bindingの追加・更新・削除を検知する。モビリティソケットからの情報により、トンネルの生成・削除を行ない、ルーティングテーブルの経路を変更する。
• Home Agent Daemon (HAD)
HA のみで動作するデーモン。BC を管理する。また、Binding Update によって BC を追加・更新・削除を行ない、Binding Acknowledgement を送信する。BC の変更情報はモビリティソケットを通じて、カーネルへと通知される。

HA

NEMONETD

Routing socket

HAD BCRAW socket for MH

user land
kernelMobility Socket

setup tunnel
setup route

BC

NIC

Binding Acknowlagement
etc....

InternetMR

setup tunnel
setup route

Binding Update
etc...

NIC

BUL

RAW socket for MH

Routing socket

MDD

Mobility Socket

NEMONETD
図 A.2: SHISA の概要

以下に SHISA の動作概要を図 A.2を用いて説明する。

67

kerneluser land

MRD BUL

まず、移動と 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 へのトンネルを生成し、トンネルの経路を加える。
BC はライフタイムの期限が切れると HAD によって削除され、BUL はライフタイムが切れると MRD によって削除される。また、MDD は通信不能になったインターフェイスを検知す
るとモビリティソケットを用いて MRD へと通知を行ない、MRD は BUL を削除する。

A.2

ORF2004 でのデモンストレーション展示

2004 年 11 月 23 日、24 日、SFC OPEN RESEARCH FORUM 2004(ORF2004)[24] の村井研究室スペースにおいて本研究のデモンストレーション展示を行なった。多くの来場者に本研究の成果をアピールすることができた。また、来場者には多くのアドバイスをいただき、今後の研究の指針とすることができた。その他、2 日間にわたって、本システムを動作し続けたことで多くのバグを発見することができた。

HA

IPv6 camera

IPv6 sensor

center server
PDA

MR
MR

IPv6 sensor

図 A.3: ORF でのデモンストレーション展示 2004/11/24

68図 A.4にデモンストレーションの概要を示す。
Demo A では車内で PDA が動画サーバからストリーミングを受けている。PDA は直接無線でのインターネット接続性をもたないが、車内のネットワークにつなぐことでインターネットへ接続する。移動によって MR1 の無線が利用不能となっても、MR2 の無線によってインター
ネットへ接続することが可能となる。
Demo B では、車内に搭載された IPv6 カメラを自宅の PC からアクセス可能となる。搭乗者は家族とコミュニケーションを行なうことが可能である。本システムの着信可能性と移動透過性によって、いつでもどこでも自動車のカメラにアクセスできる。
Demo C では、センターサーバで車内に搭載された温度センサと加速度センサの値を収集できる。自動車は接触事故を起こすと急激な加速度を検知する。この情報をセンターサーバで検知することで事故後の素早い対応を行なうことが可能となる。
利用可能な接続性を管理し、トラフィックを分散するデモンストレーションを行なった。これらのデモンストレーションによって、本研究のシステムの成果をアピールできた。
Demo Chome
center server

Movie streaming
serverPC

Demo B

Internet

In-Vehicle network
MR2

MR1

ZaurusDemo A

IPv6 camera

IPv6 acceleration
sensor

IPv6 temperature
sensor

図 A.4: デモンストレーション概要

69