平成 13 年度
学士学位論文IPv6 マルチキャストにおける転送トポロジーの探索手法
A Discovery Method of Delivering Topology
in IPv6 Multicast

1020323

藤岡 里佳

指導教員

菊池 豊

2002 年 2 月 8 日
高知工科大学 情報システム工学科

要 旨IPv6 マルチキャストにおける転送トポロジーの探索手法
藤岡 里佳

マルチキャストネットワークの構築から運用において、より信頼性の高いサービスを提供するために考察・実験が行われている [1]。マルチキャストの実験が盛んに行われるようになると、実用の機会もより増加し、マルチキャストの管理にはより一層の考察が必要となってくる。
現状の IPv6 マルチキャスト [2] [3] におけるデバッグツールはマルチキャストの管理をするのに十分ではない。より多様なマルチキャスト管理ツールの使用を可能とするため、本研
究は IPv6 マルチキャストにおける転送トポロジーの探索手法の提案と実装とを行うことが目標である。
本論文では、ICMP echo メッセージ [4] と traceroute のアルゴリズム、MLD [5] のmtrace メッセージを用いてマルチキャスト経路情報を得る手法を提案する。
提案した手法を実装し、正しく機能することを確認した。
キーワード

マルチキャスト, デバッグツール, MLD, ICMP, PIM, RIBB–i–Abstract
A Discovery Method of Delivering Topology
in IPv6 Multicast
Rika FUJIOKA

In the employment from construction of a multicasting network,in order to offer
more reliable servise, consideration and the experiment are conducted [1]. If the experiment of multicasting [2] [3] comes to be conducted briskly, the opportunity of practicaluse will also be considered that much more consideration is needed for management of
increase and multicasting.
The debugging tool in the present IPv6 multicasting is not enough to manage
multicasting. In order to enalbe use of more variouse multicasting management tools,
it is a target that this research performs mounting of A Discovery Method of Delivering
Topology in IPv6 Multicast.
In this paper, the technique of acquiring multicast routeing infomation using the
ICMP echo message [4] and algorithm of traceroute and mtrace message of MLD [5]is proposed.
The proposed technique was mounted and it checked functioning correctly.
key words

Multicast, Debugging Tool, MLD, IGMP, PIM, RIBB

– ii –

目次
第1章

はじめに

1

RIBB におけるマルチキャスト配信実験 . . . . . . . . . . . . . . . . . . .

2

マルチキャスト

3

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1

ユニキャストとの違い . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.2

ブロードキャストとの違い . . . . . . . . . . . . . . . . . . . . . .

3

2.1.3

マルチキャストグループの概念 . . . . . . . . . . . . . . . . . . . .

5

2.2

構成要素 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.3

グループ管理プロトコル . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.3.1

MLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6Multicast Lister Report の制御技術 . . . . . . . . . . . . . . . . .

7

マルチキャスト経路プロトコル . . . . . . . . . . . . . . . . . . . . . . .

8

2.4.1

PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.4.2

Flooding と Reverse Path Forwarding . . . . . . . . . . . . . . .

10

2.4.3

送信元ツリー (Source Based Tree) . . . . . . . . . . . . . . . . . .

11

2.4.4

共有ツリー (Shard Tree) . . . . . . . . . . . . . . . . . . . . . . .

12

2.4.5

PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.4.6

PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

Hello メッセージング . . . . . . . . . . . . . . . . . . . . . . . . .

15

マルチキャストパケットの転送 . . . . . . . . . . . . . . . . . . . .

16共有ツリーへの参加 . . . . . . . . . . . . . . . . . . . . . . . . . .

17

指定されたルータ . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

RP 登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

1.1
第2章

2.1

2.4

– iii –

目次

第3章

Register-Stop メッセージ . . . . . . . . . . . . . . . . . . . . . . .

21

インターフェイスのプルーニング . . . . . . . . . . . . . . . . . . .

22

Assert メッセージング . . . . . . . . . . . . . . . . . . . . . . . .

23

Assert の獲得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

SBT スイッチング. . . . . . . . . . . . . . . . . . . . . . . . . .

25

RP の決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

マルチキャスト管理ツールとその問題

27

3.1

既存のツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.2

トラブル解決における現状と問題 . . . . . . . . . . . . . . . . . . . . . .

29

3.2.1

29

第4章

ネットワーク全体の転送トポロジー. . . . . . . . . . . . . . . . .

転送トポロジー探索ツール

31

4.1

要求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.2

転送トポロジーの探索手法の選択肢 . . . . . . . . . . . . . . . . . . . . .

32

4.2.1

ICMP ルータ要請・広告＋ IPv6 始点経路制御. . . . . . . . . . .

32

4.2.2

ICMP 近隣要請・広告＋ IPv6 始点経路制御 . . . . . . . . . . . . .

32

4.2.3

ホップリミット付きマルチキャストパケット . . . . . . . . . . . . .

33

4.2.4

ホップリミット付きマルチキャストパケット＋ IPv6 始点経路制御 .

33

4.2.5

ICMP echo メッセージ ＋ traceroute ＋ mtrace6 . . . . . . . . . .

34

4.3

提案手法の実現可能性についての評価 . . . . . . . . . . . . . . . . . . . .

34

4.4

転送トポロジー探索手法 . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.4.1

受信ホストの探索 . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.4.2

最終ホップルータの探索. . . . . . . . . . . . . . . . . . . . . . .

36

4.4.3

各受信ホストから送信ホストまでのマルチキャスト経路の取得 . . .

38

4.4.4

経路情報の集約と結果表示 . . . . . . . . . . . . . . . . . . . . . .

40

ツールの詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.5

– iv –

目次

4.5.1

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.5.2

ICMP echo による受信ホストの発見 . . . . . . . . . . . . . . . . .

42

4.5.3

発見した各受信ホストへの最終ホップルータの発見 . . . . . . . . .

42

4.5.4

メッセージ送出の時間間隔調整 . . . . . . . . . . . . . . . . . . . .

44

4.5.5

各受信ホストから送信ホストへのマルチキャスト経路の探索. . . .

44

4.5.6

各受信ホストから送信ホストへの経路を木構造に集約 . . . . . . . .

46

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

経路情報を木構造に集約する過程 . . . . . . . . . . . . . . . . . . .

46

木を出力用データに変換する過程 . . . . . . . . . . . . . . . . . . .

47

転送トポロジーを木構造で出力 . . . . . . . . . . . . . . . . . . . .

48

4.5.7
第5章

実験と結果

50

5.1

実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

5.2

実験 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

5.3

実験 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

5.4

実験 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

5.5

実験 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

評価と考察

56

6.1

評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

6.2

考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

6.2.1

ツールの実装. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

6.2.2

OS の実装とプロトコル . . . . . . . . . . . . . . . . . . . . . . . .

57

6.2.3

制限事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

実行ホスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

マルチキャスト経路情報の取得 . . . . . . . . . . . . . . . . . . . .

59

プロトコルの改良 . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

第6章

6.2.4

–v–

目次

第7章

62

まとめ

謝辞

63

参考文献

64

付録 A

関連技術用語65

RPM (Reverse-Path Multicasting) . . . . . . . . . . . . . . . . . . . . .

65

A.1.1 動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

A.1.2 接ぎ木 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

A.2

RPF チェック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

A.3

ICMP

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

A.3.1 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

A.3.2 ICMP メッセージタイプ . . . . . . . . . . . . . . . . . . . . . . .

69

映像配信実験まとめ

71

B.1

富山国体 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

B.2

Live!Eclipse(皆既月食中継) . . . . . . . . . . . . . . . . . . . . . . . . .

72

B.2.1 ネットワークトポロジー . . . . . . . . . . . . . . . . . . . . . . .

72

山梨かいじきらめき国体中継実験 . . . . . . . . . . . . . . . . . . . . . .

72

B.3.1 ネットワークトポロジー . . . . . . . . . . . . . . . . . . . . . . .

73

ギガビットネットワークフォーラム in 富山 . . . . . . . . . . . . . . . . .

73

B.4.1 ネットワークトポロジー . . . . . . . . . . . . . . . . . . . . . . .

74

Live!Eclipse(日食) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

B.5.1 ネットワークトポロジー . . . . . . . . . . . . . . . . . . . . . . .

75

DSM 中継 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

B.6.1 ネットワークトポロジー . . . . . . . . . . . . . . . . . . . . . . .

77

みちのく YOSAKOI まつり中継 . . . . . . . . . . . . . . . . . . . . . . .

77

A.1

付録 B

B.3

B.4

B.5

B.6

B.7

– vi –

目次

B.8

B.9

B.10

B.11

B.7.1 ネットワークトポロジー . . . . . . . . . . . . . . . . . . . . . . .

78. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

B.8.1 ネットワークトポロジー . . . . . . . . . . . . . . . . . . . . . . .

79

マシンスペック . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

みやぎ国体中継 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

B.9.1 ネットワークトポロジー . . . . . . . . . . . . . . . . . . . . . . .

82

国際会議 ISOM 中継 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

B.10.1 ネットワークトポロジー . . . . . . . . . . . . . . . . . . . . . . .

83

ギガビットネットワーク・シンポジウム in 沖縄 . . . . . . . . . . . . . .

83

新湊曳山祭り中継– vii –

図目次
2.1

ユニキャストとマルチキャストの違い. . . . . . . . . . . . . . . . . . . .

4

2.2

ブロードキャストとマルチキャストの違い . . . . . . . . . . . . . . . . . .

4

2.3

MLD query メッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.4

MLD report メッセージ. . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.5

送信元ツリーと共有ツリーの違い . . . . . . . . . . . . . . . . . . . . . . .

9

2.6

RPF の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.7

SBT の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.8

PIM-SM における RPT の例 . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.9

PIM-SM における Join . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.10 指定ルータの決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.11 Register メッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.12 Register-Stop メッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.13 プルーニング. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.14 Assert メッセージング . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.1

受信ホストの探索 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.2

traceroute アルゴリズム . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

4.3

mtrace メッセージの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

4.4

経路情報の並べ替え . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.5

経路情報の集約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.6

受信ホストの発見 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.7

最終ホップルータ発見 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

4.8

木構造の形成. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

4.9

木の追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48– viii –図目次

4.10 出力用データへの変換 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

5.1

実験ネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.2

実験 1 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

5.3

実験 2 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

5.4

実験 3 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

5.5

実験 4 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

A.1 RPM 枝刈り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

A.2 RPM 接ぎ木 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

A.3 RPF チェック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

A.4 ICMP メッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

B.1 ギガビットネットワークフォーラム in 富山中継ネットワーク図 . . . . . . .

75

B.2 Live!Eclipse(日食) ネットワーク図 . . . . . . . . . . . . . . . . . . . . . .

76

B.3 DSM 中継ネットワーク図 . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

B.4 新湊曳山祭り中継ネットワーク図 . . . . . . . . . . . . . . . . . . . . . . .

79

B.5 ISOM 中継ネットワーク図 . . . . . . . . . . . . . . . . . . . . . . . . . .

84– ix –

表目次
3.1

経路探索ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

5.1

実験環境マシンスペック . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

5.2

/usr/local/etc/pim6sd.conf の内容. . . . . . . . . . . . . . . . . . . . .

51

5.3

実験 1 内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

5.4

実験 2 内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

5.5

実験 3 内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

5.6

実験 4 内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

A.1 ICMP メッセージタイプ . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

–x–

第1章

はじめに
一台の送信サーバから複数台の受信クライアントへ同時に効率よく情報配信を行う技術としてマルチキャストがある。マルチキャストネットワークの構築から運用において、より信頼性の高いサービスを提供するために考察・実験が行われている [1]。地域間相互接続実験
プロジェクトである RIBB (Regional Internet BackBone) においても多くのマルチキャス
トに関する実験を行ってきた (第 1.1 節参照)。このように、マルチキャストの実験が盛んに行われるようになると、実用の機会もより増加し、マルチキャストの管理にはより一層の考察が必要となってくると考える。
本論文において、現状の IPv6 マルチキャストにおけるデバッグツールは十分ではないと考察し、マルチキャストの管理における現状把握が十分にできないことを指摘する。そして、IPv6 マルチキャストにおける複数経路を表示するツールが既存していないことを指摘
し、より多様なマルチキャスト管理ツールを使用を可能とするため、IPv6 マルチキャスト
における転送トポロジーの探索手法の提案と実装を目標とした。
第 2 章で、マルチキャストについて、本研究における探索手法の提案をする上で影響を及ぼす特徴を含めて説明する。第 3 章で、現在のマルチキャストの管理ツールにおける問題点を述べる。そして、第 4 章において本研究の目標を述べ、転送トポロジーの探索とこのトポ
ロジーを図示する手法とを述べる。第 5 章においてツールの実装とその実験結果について述べる。第 6 章で評価考察をし、最後にまとめを述べる。

–1–

1.1 RIBB におけるマルチキャスト配信実験

1.1

RIBB におけるマルチキャスト配信実験

RIBB (Regional Internet BackBone) という地域間相互接続実験プロジェクトがある。
JGN (JAPAN Gigabit Network) を用いて横のつながりを目指すプロジェクトである。目的としては、分散ストリーム配信技術がある。菊池研究室は RIBB のメンバーとして活動している。
菊池研究室では、これまで RIBB における多くのストリーム配信実験 (付録 B) に参加してきた。そのストリーム配信の中のいくつかでマルチキャストを用いた実験も行った。

IPv4 におけるマルチキャストからはじまり、IPv6 におけるマルチキャスト配信実験にも参加した。
この活動において、マルチキャストルータの構築、運用に参加した。マルチキャストルー
タの構築では苦労が絶えなかった。また、ストリーム配信や中継にはさまざまなトラブルが発生することを知った。特にマルチキャストにおけるストリーム配信では、マルチキャスト
ルータを正常に機能させるよう構築することに大変苦労した。

IPv4 マルチキャストでの配信はいくつか実験を行っていく上で成功させることが可能となった。IPv6 マルチキャストでは失敗を繰り返しながら、ノウハウを蓄積していくことができた。また、これらの配信実験を経験する中で、IPv6 マルチキャストにおけるデバッグ
ツールの不足を感じ、本研究の発起に至った。

–2–

第2章

マルチキャスト
本章では、マルチキャストの概要を説明し、マルチキャストに関係するプロトコルについての解説を本論文に関連する特徴とともに述べる。

2.1

概要

マルチキャストは、ルータが送られてきたパケットを複製して受信ホストの方向へ送信することで、ネットワークへの負荷を軽減し、なお受信したいホストのみが受信できる技術で
ある。

2.1.1

ユニキャストとの違い

ユニキャストの場合、同じデータを受信する要求が複数あった場合、その要求の数だけデータを送り出す (図 2.1)。例えば、3 つのホストから要求あった場合、3 つの同じデータのパケットが送り出される。これに対してマルチキャストでは、単一のパケットで複数のノード (ルータやハブなど) に対して同一データを送信するため、データの送信量が少なく
てすむ。

2.1.2

ブロードキャストとの違い

ブロードキャストとマルチキャストにおける最も重要な違いは、マルチキャストパケット
はルータを越えて転送されるが、ブロードキャストパケットはルータを越えられないことで
ある。

–3–

2.1 概要

図 2.1

ユニキャストとマルチキャストの違い

また、ブロードキャストの場合、ネットワーク内の全ノードに対してデータを送信し、全ノードがパケットを受信し、処理する (図 2.2)。これに対してマルチキャストでは、マルチキャストグループに対してデータを送信し、受信したいホストのみがデータを受信することができる。
つまり、ブロードキャストでは、ネットワーク内での少数の末端ノードのみがそのトラフィックに興味があるのにもかかわらず、全ての末端ノードが各ブロードキャストパケットを受信しなければならない。そして、大部分の末端ノードがそのトラフィックに興味がなけ
れば、受信したパケットを破棄することになる。したがって、ホスト資源の浪費となり好ましくない。しかし、マルチキャストでは、受信したいホストのみがパケットを受信するた
め、このようなことは起こらない。

図 2.2

ブロードキャストとマルチキャストの違い–4–

2.2 構成要素

2.1.3

マルチキャストグループの概念

マルチキャストグループとは、あるマルチキャストアドレスへ送信されくるパケットを受信するホストの集まりのことである。
一つのマルチキャストグループには対応する一つのマルチキャストアドレスがある。マルチキャストパケットはそれぞれの、マルチキャストグループ宛てに送られる。そして、受信
ホストはこのマルチキャストグループに参加することでパケットを受信する。
マルチキャストグループ宛てにマルチキャストパケットを送信するということは、送信ホストがこのグループに対応するマルチキャストアドレスへ宛ててパケットを送信しているということである。
また、受信ホストが、マルチキャストグループへ参加するということは、マルチキャスト
アドレスへ宛てて参加のメッセージを送信するということである。すると、そのマルチキャ
ストアドレスへ送られているパケットが受信できるのである。

2.2

構成要素

ここでは、ホストとルータ間におけるプロトコルである、グループ管理プロトコルと、ルータ間におけるプロトコルである、マルチキャスト経路プロトコルについて述べる。

2.3

グループ管理プロトコル

グループ管理プロトコルは、ホストからルータに対してマルチキャストグループへの参加・脱退の通知や、ルータから各ホストへのマルチキャストグループの参加状況の問い合わせを行うプロトコルである。
このグループ管理プロトコルには、IPv4 に対応する IGMP (Internet Group Management

Protocol) と、IPv6 に対応する MLD (Multicast Listener Discovery) がある。ここでは、
本研究で用いる MLD について説明する。

–5–

2.3 グループ管理プロトコル

2.3.1

MLD

MLD の主な仕様を以下に示す (図 2.3)。
サブネットワークごとに一つのマルチキャストルータが定期的に全ホストグループに対して、Multicast Listener Query を送信する。Query メッセージは、メッセージを出したルータに直接接続しているサブネットワークに送信され、他のマルチキャストルータには転送されない。
末端ノードは Query メッセージを受け取ると、そのノードが属している各グループ宛てて Multicast Listener Report メッセージを返す。このメッセージは直接接続するマルチ
キャストルータを越えては転送されない。
以上により、Query を出したノードが直接接続しているネットワーク上で、どのホストグ
ループにメンバが存在しているかを決定する。

図 2.3 MLD query メッセージ–6–

2.3 グループ管理プロトコル

Multicast Lister Report の制御技術
各グループメンバからの Report メッセージがあふれるのを回避するために、Report メッ
セージを制御するための技術が用いられている。
図 2.4 のように、各末端ノードは、Query メッセージを受信すると、そのノードが属している各グループに関して Report 遅延タイマをスタートさせる。
それぞれの Report 遅延タイマは、Query メッセージに記される最大応答遅延 [Multicast

Listener Interval] の幅によって、異なったランダムな値にセットされる。タイマがすでに動いている時、Query メッセージを受信した場合、動いているタイマに残された値より要求された最大応答遅延 [Multicast Listener Interval] が小さい時にだけ新しく選んだランダムな値でタイマをリセットする。
マルチキャスト通信を行うインタフェースから、そのインタフェース上で同じグループのタイマが動いている間にノードが別のノードのレポートを受け取ると、そのタイマを止め、Report を送信しない。
ルータは、リンクからレポートを受け取った時、そのリンク上にリスナーを持つグループのリストを見る。もしレポートされたグループがこのリスト中に存在しなければ、そのタイ
マは最大応答遅延 [Multicast Listener Interval] の期間にセットされる。もし、このリスト中にすでに存在するグループに対してレポートを受信すると、そのグループに対するタイマ
は、最大応答遅延 [Multicast Listener Interval] の期間にリセットされる。
グループのタイマーが終了すると、リンク上にもはやそのグループに対してリスナーがいないと解釈され、そのグループはリストから消される。この消失はマルチキャスト経路プロ
トコルの要素とされる。
この技術によって、メンバになっている各末端ノードが Report を送る必要性を回避している。したがって、マルチキャストルータは、直接接続しているネットワーク上で、各ホストグループに対してメンバが存在しているか、いないのかという情報しか持っていない。ホストグループのメンバにどのホストが存在しているのかという情報は持っていない。

–7–

2.4 マルチキャスト経路プロトコル

図 2.4 MLD report メッセージ

2.4

マルチキャスト経路プロトコル

マルチキャスト経路プロトコルは、パケットを転送するルータにおいて、パケット複製するかどうかの決定や、パケットの転送先を決定するために使われる。
マルチキャスト経路プロトコルを、マルチキャストパケットの配送方式によって分類すると、図 2.5 のように、送信元ツリー (Source Based Tree) と共有ツリー (Shared Tree) に分けられる。もう一つの分類として、受信ホストの集積度によるものがある。これには、デンスモードとスパースモードがある。
マルチキャスト経路プロトコルには、IPv4 に対応するものとして距離ベクトル型マル
チキャスト経路プロトコル (DVMRP: Distance-Vector Multicast Routing Protocol) があり、IPv6 にも対応するものとして、Protocol-Independent Multicast (PIM) がある。ここでは、本研究で用いた PIM について説明する。

–8–

2.4 マルチキャスト経路プロトコル

図 2.5

2.4.1

送信元ツリーと共有ツリーの違い

PIM

PIM (Protocol-Independent Multicast) プロトコルは、実際は PIM-デンスモード (PIMDM: PIM-Dense Mode) [6] と PIM-スパースモード (PIM-SM: PIM-Sparse Mode) [7] の2 つのプロトコルで構成されている。PIM-SM における共有ツリー特有の制御メッセージを除けば、PIM-DM と PIM-SM は同一の制御メッセージを持つ。しかし、実際には 2 つのまったく独立したプロトコルである。
デンスモードは、受信ホストが密集して存在していることを仮定としている。このモード
では、通常状態で全てのホストに対してマルチキャストパケットを送信し、パケットを配送する必要のないサブネットワークのノード群ではパケットの送信停止をルータに通知する。
スパースモードは、受信ホストが散在的に存在していることを仮定としている。このモードでは、通常状態では、マルチキャストパケットを全てのホストに配送せず、パケットを受信する必要があるサブネットワークのノード群はルータに伝える。スパースモードは、ユー–9–

2.4 マルチキャスト経路プロトコル

ザがインターネット上に広範囲に分散していることを表す。

PIM は、特定のユニキャスト経路制御プロトコルに依存しないという機能に由来して付けられた名称である。PIM の実装では経路制御情報を提供し、トポロジの変化に適応する
ユニキャスト経路制御プロトコルの存在が必要なだけである。既存のユニキャスト経路プロ
トコルのどのような組み合わせでも、この目的には十分である。
はじめに、以下の項目を説明する。

• Flooding と Reverse Path Forwarding (RPF)• 送信元 ツリー
• 共有ツリー2.4.2

Flooding と Reverse Path Forwarding

Flooding とは、ルーティング情報の保存が必要ない、単純なルーティングスキームである。Flooding では、パケットは発信元以外のすべてのインターフェイスに転送される。

Reverse Path Forwarding (RPF) は、Flooding を最適化したものである。この方法では、ルーターが送信元 S に到達するためのインターフェイスがインターフェイス I だけである場合に限り、ルーターは S から I 経由でパケットを受信する。インターフェイスが正
しいかどうかは、ユニキャストルーティングテーブルで確認する。
この方法を使用すると、標準 Flooding に必要なオーバーヘッドを大幅に削減できる。
ルーターは 1 つの近隣ノードからしかパケットを受け付けないので、パケットの送信は 1
度だけである。つまり、ポイントツーポイントリンクの場合、各パケットは各リンクで各方向につき 1 度だけ転送される。RPF の例を図 2.6 に示す。
この例では、ルータはインターフェイス I0 経由で受信した送信元 1 からのマルチキャス
トパケットを破棄する。これは、ルーティングテーブルにこのインターフェイスが送信元 1
への最短パスとしてリストされていないためである。ルータがその送信元宛てのパケットを持っていれば、インターフェイス I1 を使用し、インターフェイス I1 を介して受信したパ– 10 –

2.4 マルチキャスト経路プロトコル

図 2.6 RPF の例

ケットは、ルーティング テーブルに送信元 1 への最短パスとしてリストされているので転送される。ルータのルーティング テーブルを使ってマルチキャスト パケットの最短パスを決定する点に注意しなければならない。

2.4.3

送信元ツリー (Source Based Tree)

送信元ツリーは、マルチキャストアドレスごとで、送信ホストごとに配送経路が存在する。つまり、同一マルチキャストアドレスでも送信ホストが異なると、別の配信経路が存在する。この配送方式では、マルチキャストと送信ホストの積の数だけの記憶領域を必要とす
るが、すべての受信者に対して最短経路を通るメリットがある。
送信元ツリーは、転送するパスが送信元への最短ユニキャストパスに基づいて決められることを意味する。
各マルチキャスト送信元よって対応するマルチキャストツリーがあり、直接送信元と全受信者を接続する。送信元と関連グループのツリーが構築されると、グループメンバへのトラ
フィックはすべてこのツリーを使って渡される。SBT には、送信インターフェイスのリス
トに (S,G) エントリがある。S は送信元アドレス、G はマルチキャストグループである。図2.7 に SBT の例を示す。
この例では、送信元 1 の SBT はルータ 1 とルータ 3 の組み合わせで別のパスがあった– 11 –

2.4 マルチキャスト経路プロトコル

図 2.7 SBT の例としても、ルータ 1 のインターフェイス I0 を通る。送信元 2 の SBT も同じように、たとえ別の (もっと長い) パスがあったとしてもインターフェイス I3 を通る (この例では、メト
リックはホップ数である)。

2.4.4

共有ツリー (Shard Tree)

共有ツリーは、あるマルチキャストアドレスに対して、一つの配送経路を持ち、マルチ
キャストパケットが必ず、コアルータから各受信ホストに転送される。この配送方式では、
送信元ツリーに比べてルータで保持する記憶領域が少なくてすむが、コアルータへの転送負荷が上がり、また余計な転送時間がかかるデメリットがある。

PIM-SM の共有ツリーでは、コアルータが RP(Rendezvous Point) と呼ばれ、 共有ツ– 12 –

2.4 マルチキャスト経路プロトコル

リー-が RP ツリー (RPT) と呼ばれる。送信ホストからすべてのトラフィックを受信し、そのトラフィックを受信ホストに転送する RP という中央ルータに依存するからである。
メンバは中央ノードに明示的に参加を送信するので、すべてのホストが受信するとは見なされない。その結果、送信ホストがいくつあっても、各マルチキャスト グループに作成されるツリーは 1 つだけである。グループを認識しているルーターだけがツリーに加わり、デー
タはそのデータを必要とする受信ホストにのみ送られる。

RPT には (*,G) エントリ (ワイルドカードエントリ) がある。G はマルチキャストグ
ループを意味する。RP には、まだ送信ホストが存在しない段階でも受信ホストの参加を受け付ける場所がある。
共有ツリーは 1 方向性である。つまり、データは RP から受信ホストへのみ送信される。

RP 以外のホストが共有ツリー上で送信する場合、データを参加ホストにマルチキャストする前に、まず RP にトンネリングする。

PIM-SM RPT の例を図 2.8 に示す。
この例では、ネットワーク構成が送信元ツリーの例と同じでも、トラフィックの転送経路が異なる。送信ホスト 1 からのマルチキャストトラフィックは、すべてルータ 1 からルータ

3 へのインターフェイス I1 つまり RP を通って送信される。送信ホスト 2 からは、ルータ
2 のインターフェイス I2 を通って RP へ送信される (送信ホストからこの RP へは最短経路である)。次に、RP はマルチキャストグループに明示的に参加した受信ホストにデータを配布する。その際、全受信ホストが同じツリーを使用する。1 つのネットワークに複数のRP が存在することもあるが、各マルチキャストグループの RP は 1 つだけである。
RP から受信ホストへの経路はすべて最短経路であるが、送信ホストから受信ホストへの最短経路は受信ホストから RP へのパスと同じではない。

2.4.5

PIM-DM

デンスモードの PIM は SBT を構築する。これは RPM アルゴリズム (付録 A.1 参照)に基づいている。したがって、PIM-DM はドメインの末端までパケットをブロードキャス– 13 –

2.4 マルチキャスト経路プロトコル

図 2.8 PIM-SM における RPT の例

トし、活動していない枝が枝刈りされるのを期待するデータ駆動型のプロトコルである。

PIM-DM が新しい (送信元, グループ) の組に対するパケットを入力インタフェース以外の全てのインタフェースに転送することである。

PIM-DM における枝刈りは明示的な枝刈りメッセージ (PIM-Prune メッセージ) によってだけ生じる。これは、ブロードキャストリンク (枝刈りメッセージを聞いているほかのルータが存在し、それ自身の動作している下流の受信ホストのためにこのグループへのト
ラフィックをさらに受信していたい場合、これらのルータは PIM-Join パケットをマルチキャストして配布木に接続されたままでいるよう保証しなければならない) 上のマルチキャストである。最後に、枝刈りが送られた後、下流に新しくグループのメンバが現れた場合、

PIM-DM は信頼性のある接ぎ木機構を使って以前送られた枝刈りメッセージを「消去」できる。

– 14 –

2.4 マルチキャスト経路プロトコル

PIM-DM は RPM を使っているので、受信したすべてのパケットに対しての RPF チェック (付録 A.2 参照) を実装している。

2.4.6

PIM-SM

PIM-SM(Protocol Independent Multicast-Sparse Mode) は共有ツリーと送信元ツリーの両方をサポートする。PIM-SM は、共有ツリーでは RP(Rendezvous Point) という名前の中央ルーターを共有ツリーのルートとして使用する。どちらかのツリーを使用することも、両方を同時に使用することも可能である。
以下の点について詳細を説明する。

PIM-SM プロトコルは、以下の部分から構成される。
• Hello メッセージング• マルチキャストパケットの転送• 共有ツリーへの参加• RP への登録• 共有ツリー (SBT) スイッチング• プルーニングインターフェイス• Assert メッセージング• RP の決定
これらの各項目について詳しく説明する。安定した、つまり RP がすでに選択されている状態のシステムを前提とし、その選択方法については、最後のセクションで説明する。

Hello メッセージング
PIM ルータは、定期的に、近隣 PIM ルータを発見するための Hello メッセージを送信する。Hello メッセージは ALL-PIM-ROUTERS グループ宛てのアドレスを使用するマル– 15 –

2.4 マルチキャスト経路プロトコル

チキャストである。Holdtime フィールドでは、情報が有効な期間を指定します。
ルータは、Hello メッセージを受信しても受信確認の送信は行わない。また、Hello メッ
セージを受信しても、そのインターフェイスは自動的にはマルチキャストトラフィックを転送するための送信インターフェイスには追加されない。

PIM-SM は明示的な参加モデルを使用する。このため下位の受信ホストは、トラフィッ
クがインターフェイスに転送される前にグループに参加する必要がある。

マルチキャストパケットの転送

PIM-SIM ルータは、マルチキャストグループに明示的に参加している受信ホストへのす
べてのインターフェイスにマルチキャストトラフィックを転送する (受信ホストがグループに参加するには、所属している各グループの MLD Multicast Listener Report メッセージを送る)。
ルータは、パケットが転送される前に RPF チェック (付録 A.2 参照) を行う。
正しいインターフェイスに到着したトラフィックは、すべての送信インターフェイス(”oif”) に送られ、以下のいずれかの条件があてはまる場合に、そこから下位受信者に送信される。

• 下位 PIM-SM ルータがこのルータへの参加を送信した。
• MLD プロトコルで明示的にグループに参加した直接接続されている受信ホストがいる。

• インターフェイスがグループに参加するように手動で設定されている。
各 (*, G)、(S, G) エントリに、それぞれの oif リストがある。

– 16 –

2.4 マルチキャスト経路プロトコル

共有ツリーへの参加
すでに説明したとおり、ホストがマルチキャストグループへの参加を希望する場合は、MLD メッセージをホストの上位ルータに送るため、ルータはそのグループからのトラ
フィックを受信できるようになる。これを行うには、ルータは RP に対して RPT への参加を希望することを通知する信号を送る必要がある。具体的には、PIM (*, G) Join メッセー
ジを RP 方向にある上位の PIM 近隣ノードに送る。

Join メッセージは ALL-PIM-ROUTERS グループ へ 1 ホップづつマルチキャストされる。これは、マルチアクセスネットワーク (イーサネットなど) では、すべての PIM 近隣
ノードが参加を認識するが、実際に参加を実行するのは、指定された上位の PIM 近隣ノードのみであることを意味する (参加と同じメッセージは後で説明するプルーニングにも使われる)。

PIM ルータは下位ルータから (*, G) Join を受信すると、マルチキャストルーティング
テーブルにグループ G の (*, G) 状態があるかどうかをチェックする。状態がすでに存在す
る場合、Join メッセージがすでに共有ツリーに到着し、メッセージを仲介したインターフェ
イスが oif リストに入力されたことを示す。状態が存在しない場合は、(*, G) エントリが作成され、インターフェイスが oif リストに入力され、再度 Join メッセージが RP 宛てに送信される。
最後のホップルータから RP への (*, G) 状態が 1 度作成されると、G のマルチキャスト
トラフィックがグループに参加したホストに到達する。このプロセスを図 2.9 に示す。
この例では、受信ホストは MLD Multicast Listener (Report) メッセージをルータ 2(グループ G 宛) に送り、マルチキャストグループ G への参加希望を示す。これがルータ 2 に接続されグループに参加した最初の受信ホストなので、ルータに (*, G) 状態はない。このためエントリが作成され、I4 が oif リストに追加され、Join メッセージが上位の近隣ノード、ルータ 1 に転送される。ルータ 1 にも (*, G) 状態がないため、同じプロセスを繰り返し、また Join メッセージを RP 宛てに転送する。

– 17 –

2.4 マルチキャスト経路プロトコル

図 2.9 PIM-SM における Join

RP が Join メッセージを受信するまで、または (*, G) 状態を持つ上位ルータがメッセージを受信するまで、このプロセスが続く。どちらの場合も、結果として RPT が作成され、RP から受信ホストへ届けられる。はじめに受信ホストが MLD メッセージを送信しないと、マルチキャストが開始されない点に注意する。

指定されたルータ
複数のルータがマルチアクセスネットワークに接続されている場合、そのうちの 1 つが選択されて、一定の時間、指定されたルータ (DR) としての役割を果たす必要がある。

DR は Join/Prune メッセージを RP 宛てに送ります。DR を選択するには、ネットワー
ク上の各 PIM ルータが受信した Hello メッセージを調べ、自分と近隣ノードとの IP アド
レスを比較する。最も高いアドレスを持つルータが DR になる。図 2.10 は、このプロセスを示す。
この例では、ルータ 1 より高い IP を持つルータ 2 が DR になる。指定した時間内に DR– 18 –

2.4 マルチキャスト経路プロトコルから Hello メッセージを受信しなかった場合は、再度 DR 選択が実行され、最上位の IP ア
ドレスを持つルータが DR になる。

図 2.10 指定ルータの決定

RP 登録
マルチキャストトラフィックの送信ホストは、必ずしもデータの送信先のグループに参加する必要はない。最初のホップのルータ (DR) は、送信ホストからのトラフィック受信を、その送信ホストの (S, G) 状態を持たなくても開始できる。これは、マルチキャストト
ラフィックがツリー上をどのように RP まで到達するかという情報はないことを意味する。
送信ホストの DR が最初のマルチキャストパケットを受信すると、それを Register メッ
セージにカプセル化し、そのグループの RP にユニキャストする。RP は各 Register メッ
セージを非カプセル化し、展開したデータパケットを RPT 上の下位メンバに転送する (RPは、必要に応じて送信ホストへの SBT を再度確立するため、(S, G) Join を DR に送り返すこともできる。通常、これはデータレートがしきい値に達したときに実行される)。
送信ホストから RP へのパスが確立すると、DR は、標準 IP マルチキャストパケット、および Register メッセージにカプセル化した形で、RP へトラフィックを送り始める。これは、RP が一時的にいくつかのパケットを 2 度受信することを意味する。RP が標準マル– 19 –

2.4 マルチキャスト経路プロトコル

チキャストパケットを検出すると、Register-Stop メッセージをルータ 1 に送る。これは、レジスタパケットの送信を中止する必要があることを意味する。

図 2.11 Register メッセージ

図 2.11 はレジスタプロセスのしくみを示している (ルータには既存の状態がないことを前提とする)。
この図は、送信元がマルチキャストデータの転送を開始したところを示す。送信ホストの DR であるルータ 1 は、(S, G) 状態を作成し、Register メッセージにカプセル化したパケットを RP にユニキャスする。RP はパケットを受信すると、Register メッセージからマルチキャストデータを抽出し、そのデータを必要とする受信ホストがいれば RPT に従って転送する。

SBT が確立されるまで、ルータ 1 は RP へのマルチキャストデータが入った Register
メッセージをユニキャストし続ける。ツリーが確立すると、ルータ 1 は標準 IP マルチキャ
ストパケットとして送信したものと同じマルチキャストトラフィックを SBT 上で転送し始– 20 –

2.4 マルチキャスト経路プロトコル

める。これは、RP が一時的に送信ホストのデータを Register メッセージとして SBT を介して受信することを意味する。

Register-Stop メッセージ
RP が、Register メッセージと非カプセル化した IP パケットとして送信ホストからのト
ラフィックの受信を開始すると、Register-Stop メッセージを DR に送信する。これで DRに SBT 上のトラフィックを標準 IP マルチキャスト パケットとして受信したことが通知される。DR はこのメッセージを受信すると、トラフィックを Register メッセージにカプセ
ル化するのを中止する。図 2.12 は、このプロセスを示す。

図 2.12 Register-Stop メッセージ

RP が Register-Stop メッセージを送信するもう 1 つのケースに、どの受信ホストもマルチキャストグループに所属していない場合がある。送信ホストはメンバのいないグループへも転送を開始できる。RP はこれらのパケットを破棄し、Register-Stop メッセージを送り、– 21 –

2.4 マルチキャスト経路プロトコル

DR に Register メッセージの送信を中止させる。

インターフェイスのプルーニング

RP が Prune メッセージを受信すると、Prune メッセージで示された送信ホストからのトラフィックの転送を中止する。プルーニングは、リーフルータ (受信ホストに直接接続されているルータ)、つまりここでは DR から発行される。マルチキャストグループの最後のメンバが MLD Multicast Listener Report を送信せず、 DR において遅延時間がタイムア
ウトと、DR の MLD 状態が削除され、インターフェイスがグループ G の (S, G) と (*, G)

oif リストの両方から取り除かれる。oif リストにある (*, G) 状態の すべてのインターフェ
イスが削除されると、つまりルータが G のメンバであるどのインターフェイスにも受信ホストを持たないと、Prune メッセージは上位の RP へ共有ツリーを通って送られる。
上位ルータの oif リストも空の場合、メッセージは RP への転送を続ける。ルータにまだ別のインターフェイス上の受信ホストの (*, G) 状態がある場合は、優先 Join メッセージをPIM 近隣ノードから受信しない限り、このインターフェイスも削除される (RPT の代わりに SBT が使用された場合も、ブランチのプルーニングと同じプロセスが適用される)。図2.4.6 はプルーニングプロセスの例を示したものである。
この例では、リーフルータであるルータ 2 において、グループの MLD Multicast Listener

Report メッセージの遅延時間がタイムアウトする。ほかにグループメンバがいないので、(*, G) とすべての (S, G) oif リストから I4 を削除する。これで、ルータの oif list は空になるので、I3 経由で、RP 宛て (*, G) Prune メッセージを RPT に送る。

Prune メッセージはルータ 1 が受信する。これにより、I3 インターフェイスがマルチ
キャストルーティングテーブルの (*, G) エントリの oif リストから削除される。排除が実行されるまでに待ち時間があることに注意する。マルチアクセスネットワークでは、優先

Join メッセージが近隣の PIM ノードから到着するかもしれないので、待つことが重要である。この場合、何も受信されなかったので、インターフェイスはプルーニングされる。

– 22 –

2.4 マルチキャスト経路プロトコル

図 2.13

プルーニング(*, G) oif リストが空になったので、(*, G) Prune は RP を通って RPT へ転送される。
このプロセスは、RP がメッセージを受信するか、プルーニングの結果 (*, G) oif リストが空ではないルータが見つかるまで続く。

Assert メッセージング
マルチアクセスネットワークでは、送信元または RP へのパスが並列して複数存在する
ため、グループメンバが複数のルータから重複パケットを受信することがある。この問題を回避するには、PIM-SM は Assert メッセージを使用して、指定した転送者を決定する。図2.14 は、このような状況を表している。
この例では、ルータ 1(RP) が、近隣ルータであるルータ 2 とルータ 3 にマルチキャスト
トラフィックを転送する。これらのルータは、LAN 上で交互にトラフィックを転送する。
ルータ 3 が最初に転送すると仮定する。ルータ 2 は、このグループが oif リストに入っているインターフェイスからマルチキャストパケットを受信する。次に、ルータ 2 はルータ 3 に– 23 –

2.4 マルチキャスト経路プロトコル

図 2.14 Assert メッセージング

パケットを転送する。これはルータ 3 も、発信インターフェイス上のデータを受信することを意味する。発信インターフェイス上に入ってくるパケットを受信すると、LAN 上のほかの PIM-SM 近隣ノードもグループにトラフィックを送信していることがルータに警告される。これは、グループメンバが重複メッセージを受信することを意味する。
この問題を回避するために、ルータは、トラフィックを転送するための単一のルータを選択するための Assert メッセージを発信する。下位のルータは、Assert メッセージをリッス
ンし、どのルータが選択され、後続の Join メッセージをどこに送ればいいかを確認する。
ここでは、ルータ 4 が最初 Join メッセージをルータ 2 に送り、ルータ 5 が最初 Join メッ
セージをルータ 3 に送るものとする。アサートの後、すべての Join メッセージが指定転送者になったルータ 2 またはルータ 3 に送られる。

– 24 –

2.4 マルチキャスト経路プロトコル

Assert の獲得
すべてのルータが同じユニキャストプロトコルを実行している場合、最良のメトリックのルータが Assert を獲得する。たとえば、すべてのルータが RIP を使用している場合、最もホップ数の小さいルータが選択される。メトリックが同じ場合は、IP アドレスが最も大きいルータが選択される。
ルータが異なるユニキャストプロトコルを実行している場合はメトリックの比較ができない。たとえば、RIP はメトリックとしてホップ数を使用しているが、OSPF メトリックはイ
ンターフェイスの速度を使用する。この場合、メトリック優先順位の値により、トラフィッ
クを転送するルータとインターフェイスを排除するルータを決定する。
メトリックの優先順位は、ネットワークで実行しているユニキャストプロトコルごとに設定できる。ルータがあるグループの Assert メッセージを受け取ると、パケットにあるメト
リックの優先順位の値とルータ自体の持つ値が比較される。2 つの値が同じ場合、メトリッ
クを比較すればトラフィックの転送に使用するルータを決定できる。メトリックの優先順位が異なる場合は、最もメトリックの優先順位の低いものが選択される。

SBT スイッチング
最後のホップのルータに対して、グループのしきい値を超えたらルータを RPT から SBTへ切り替えるように、トラフィックのしきい値 (キロビット単位) を設定できる。このしきい値に達すると、DR は (S, G) Join をパケットの送信ホスト宛てに送信する。これで、送信ホスト S からルータまでの SBT が確立する。SBT への切り替えとは、マルチキャスト
トラフィックの配信に最短パスが使用されることを意味する。

– 25 –

2.4 マルチキャスト経路プロトコル

RP の決定RP の決定は、ブートストラップルータ (BSR) を使用して Bootstrap メッセージを作成する方法を用いる。これらのメッセージを使って必要ならば BSR を選択し、RP 情報を発する。メッセージは、各リンクの ALL-PIM-ROUTERS グループへマルチキャストされる。

1 つまたは複数のルータを BSR の候補として指定できる。どのルータを BSR にすべきか判断しにくい場合は、候補がアドバタイズをドメインに大量に送信する (RPF を使用す
ると、一斉送信のコストを抑えられる)。最も優先順位の高いルーターが選択される。すべての優先順位が同じ場合は、IP アドレスが最も高い候補が BSR になる。

RP 候補として設定されたルータは、この情報を BSR にユニキャストする (ほとんどの
場合、BSR の候補として設定されたルータは RP としても設定される)。RP 候補のアドバ
タイズには、アドバタイズルータと、サービス対象となるマルチキャストグループのアドレ
スが入っている。

BSR が定期的に作成する Bootstrap メッセージには、RP の候補セット (RP-Set)、および対応するグループアドレスが入っている。Bootstrap メッセージは、1 ホップごとに配信され、ドメイン全体に行き渡る。
ルータは、BSR が作成した Bootstrap メッセージを受信し、保管します。DR が、直接接続されているホストの (または、そのホストからのデータパケットの) MLD からエントリを持たないグループに対するメンバシップ指定を取得すると、DR はハッシュ関数を使用して、そのグループアドレスを、そのグループにサービスを提供できる RP 候補の 1 つにマッピングする。次に、DR は Join/Prune メッセージをその RP 宛てに送る (または Register
メッセージをユニキャストする)。

– 26 –

第3章

マルチキャスト管理ツールとその問題
第 2 章では、マルチキャストの仕組みを述べた。
第 2 章からも分かるように、マルチキャストはユニキャストに比べルーティングが複雑であり、ユニキャストにおけるトラブルより、多様なトラブルが起こると考えられる。従って、マルチキャストルーティングにおいて把握できる状況は十分なものではないと言える。
特に IPv6 におけるマルチキャストのデバッグツールは不足していると言える。
本章では、マルチキャスト管理用の既存のデバッグツールを紹介する。そして、マルチ
キャストネットワークの管理における問題を指摘する。

3.1

既存のツール

マルチキャストの管理に用いることのできる既存のデバッグツールを紹介する。

• IPv4 におけるツール– IGMP∗ mtrace
受信ホストから送信ホストへの到達性が把握できる。受信ホストから送信ホス
トへの経路上のホップのアドレス、パケット数、ルーティングのエラー状況の情報が得られる。

– DVMRP– 27 –

3.1 既存のツール∗ mrinfo
指定ルータの経路設定情報が把握できる。指定したマルチキャストルータに隣接する個々のルータの IP アドレスが表示される。指定したルータの IP アド
レスに続き、隣接するルータの IP アドレスと名前、メトリック (接続コスト)、
スレッシュホールド (マルチキャストパケット生存時間) が表示される。マルチキャストルータのバージョンが新しければ、接続タイプ (tunnel, srcrt) およ
び接続状態 (disabled, down) も表示される。

∗ map-mbone
指定したマルチキャストルータから到達可能なすべてのマルチキャストルータを把握できる。

– PIM∗ pimstat
IPv4 対応の PIM におけるデーモンの状態や統計情報を把握できる。
• IPv6 におけるツール– MLD∗ mtrace6
受信ホストから送信ホストへの到達性が把握できる。受信ホストから送信ホス
トへの経路上のホップのアドレス、ルーティングのエラー状況の情報が得られる。

– PIM6∗ pim6stat
IPv6 対応の PIM におけるデーモンの状態や統計情報を把握できる。マルチ
キャストインタフェースの状態、隣接 PIM ルータの情報、MLD Querier のリスト、マルチキャストルーティングテーブルの情報が表示される。

– 28 –

3.2 トラブル解決における現状と問題

3.2

トラブル解決における現状と問題

マルチキャストにおけるデバッグツールは、第 3.1 節において紹介したものしかなく非常に少ない。また、把握できる状態も限られている。

3.2.1

ネットワーク全体の転送トポロジー

以上のツールのうち、経路を把握するツールを表 3.1 にまとめた。この表から分かるように、単独経路を表示するツールは IPv4 にも IPv6 にも既存している。ところが、複数経路を把握するツールに関しては、IPv4 には既存しているが、IPv6 には既存していない。すな
わち、IPv6 マルチキャストにおいて、ネットワーク全体におけるマルチキャストパケットの転送トポロジーを探索し表示するツールは存在していない。
表示内容
単独経路

複数経路

IPv4

mtracemap-bone

IPv6

mtrace6

既存なし

表 3.1

経路探索ツール

IPv4 マルチキャストにおいて複数経路を表示しているツールがあって、IPv6 マルチキャ
ストにない理由には、用いられるプロトコルの違いがある。IPv4 のツールでは、グループ
管理プロトコルである IGMP の ASK NEIGHBORS IGMP メッセージを利用することができる。このメッセージを送信することで、隣接するマルチキャストルータのデータ取得をし、マルチキャストルータがそれ以上見付からないという状態になるまで繰り返すことでマルチキャストネットワークの全体図を得ている。一方、IPv6 マルチキャストにいては、グループ管理プロトコルである MLD にも、マルチキャスト経路プロトコルである PIM にも、
上述のメッセージと同様な機能を果たすメッセージタイプは存在しない。
これが、IPv6 マルチキャストにおける複数経路の取得を困難にしており、ツールが存在– 29 –

3.2 トラブル解決における現状と問題しない理由であると考える。

– 30 –

第4章

転送トポロジー探索ツール
マルチキャストパケットの転送トポロジーを把握することができれば、マルチキャストにおけるさまざまな問題において、マルチキャストルーティングのトラブルと他のトラブルとを区別することができるようになると考える。これにより、マルチキャストの管理を容易にすることを希望できる。
そこで、本研究では、IPv6 マルチキャストにおける転送トポロジーの探索手法を提案する。また、この手法を「mtopology6」として実装する。
本章では、マルチキャストにおける転送トポロジーを探索・図示するツールのプロセスを述べる。まず本研究で考案した転送トポロジーの探索手法案を紹介する。そして本研究で採用した手法を説明する。その後、このツールの詳細なアルゴリズムを説明する。

4.1

要求

提案したい手法における要求の詳細は以下となる。

• 1 つのホスト上に実装するのみで、実行可能
この要求を満たすと、実行するホスト以外のホストへのツールの実装の手間と、負荷を省くことができる。しかし、要求を満たさければ、探索を実行した際にもしこのツールを実装していないホストがマルチキャストネットワークの途中にあれば、正しい結果が得ることができない。

• 既存のプロトコルを用いて探索可能
この要求を満たすと、実行ホスト以外のホストへツールを実装させて処理を行ってもら– 31 –

4.2 転送トポロジーの探索手法の選択肢

う必要性を低くできる。

• 転送トポロジーを Tree 構造に図示
この要求を満たすと、経路情報をアドレスを羅列する表示より、より分かりやすいツー
ルとなる。

4.2

転送トポロジーの探索手法の選択肢

本研究で考案した転送トポロジーを探索する手法を述べる。

4.2.1

ICMP ルータ要請・広告＋ IPv6 始点経路制御

ICMP のルータ要請・ルータ広告メッセージと、IPv6 拡張ヘッダの始点経路制御を用いた手法を考案した。これは以下の 2 つの行程を繰り返すことで、受信ホスト方向へマルチ
キャストパケットが到達可能な経路を探索する手法である。

• ICMP のルータ要請をマルチキャストアドレス宛に直接接続しているリンク上に送信し、これに対して送られてくるルータ広告メッセージによって、マルチキャストルータを発見する。

• 次に、発見したマルチキャストルータを IPv6 拡張ヘッダの始点経路制御の途中経路ホストとして追加したルータ要請メッセージを、マルチキャストアドレス宛に送信する。

4.2.2

ICMP 近隣要請・広告＋ IPv6 始点経路制御

ICMP の近隣要請・近隣広告メッセージと IPv6 拡張ヘッダの始点経路制御を用いた手法を第 4.2.1 節の案とともに考案した。これは、上記で述べた案と類似した手法で、上記のICMP ルータ要請・ルータ広告メッセージの代わりに、ICMP 近隣要請・近隣広告を用いる手法である。
つまり、以下の工程を繰り返すことによって、受信ホスト方向へマルチキャストパケット
が到達可能な経路を探索する手法である。

– 32 –

4.2 転送トポロジーの探索手法の選択肢• マルチキャストアドレスに向けて ICMP 近隣要請メッセージを直接接続しているリン
ク上に送信し、これに対して送られてくる近隣広告メッセージを受信することによって、マルチキャストパケットを受信または、転送しているホストを発見する。

• 次に、発見したホストを IPv6 拡張ヘッダの始点経路制御の途中経路ホストとして追加
した近隣要請メッセージを、マルチキャストアドレス宛に送信する。

4.2.3

ホップリミット付きマルチキャストパケット

次に、ホップリミット付きマルチキャストパケットを用いた手法を考案した。
これは、パケットをマルチキャストグループ宛にホップりミットを 1 ホップずつ増加させながら、受信ホストから ICMP ポート到達不可メッセージを受信するまで送信する。
そして、ICMP ポート到達不可メッセージを受信するまでに得る、ICMP の時間超過メッ
セージを収集することで、マルチキャストの転送経路における途中経路の情報を得る手法である。
この手法には 1 つの問題がある。一回のパケット送信に対して、1 度にさまざまなサブ
ネットから複数の返答が来る。したがって、これらの返答を経路情報として各経路に振り分ける際に、厳密にどの経路の先にそのホストがあるのか判断できないからである。
この問題を改善する手法を次に述べる。

4.2.4

ホップリミット付きマルチキャストパケット＋ IPv6 始点経路制御

ホップリミット付きマルチキャストパケットに加え IPv6 拡張ヘッダの始点経路制御を用いた手法である。
この手法は、第 4.2.3 節で述べた手法に IPv6 拡張ヘッダの始点経路制御を用いる。まず、ホップリミット付きマルチキャストパケットの送信で得られたアドレスを最初の中継ホストとして指定する。そして、この始点経路制御されたパケットをホップリミット付きマルチ
キャストパケットで送信する。これによって、指定したホストのすぐ下流のサブネット上だ– 33 –

4.3 提案手法の実現可能性についての評価

けの ICMP エラーメッセージを収集することが可能となり、マルチキャスト経路での次の中継ホスト情報を得る。これをホップリミットを増加させながら繰り返すことによって送信ホストから各受信ホストまでのマルチキャスト経路を得る。

4.2.5

ICMP echo メッセージ ＋ traceroute ＋ mtrace6

本研究で採用したこの手法は、ICMP echo メッセージと、traceroute のアルゴリズム、

mtrace6 のアルゴリズムを用いたものである。この手法については、第 4.4 節で詳しく述
べる。

4.3

提案手法の実現可能性についての評価

第 2 章でのマルチキャストの説明の中で述べた特徴も参考に、このツールを作成するために障害となる問題点を挙げる。

• マルチキャストルータは直接接続したリンク上に受信ホストが存在するのか、存在しな
いのかという情報しか持っていない。

• 逆経路転送を行っており、送信側から受信側へのマルチキャストパケットの流れをたどることはできない。したがって、送信側からクライアントへの到達性を送信側で知ることは現在のプロトコルでは難しい。

• 送信ホストと各受信ホストの間のマルチキャストにおける転送経路を探索するプロトコ
ルは、マルチキャストに関するプロトコルを用いらなければ把握できない。

• MLD において用いることのできるメッセージタイプは MLD mtrace query, response
メッセージのみである。

• PIM において用いることのできるメッセージタイプは Hello メッセージだが、Hello
メッセージに対しての応答は発生されない。

• マルチキャスアドレスに対して ICMP エラーメッセージは発生されない。

– 34 –

4.4 転送トポロジー探索手法

以下において、第 4.2.1 節の案から第 4.2.4 節の案の実現可能性について評価する。
まず、第 4.2.1 節の案と第 4.2.2 節の案の 2 つの案は機能しない。
その理由は、まずマルチキャストに対して ICMP パケットを送信すると、マルチキャス
トでのルーティングによって受信ホストまでパケットが転送され、途中のルータでは受け取られないからである。従って、マルチキャストグループ宛の ICMP ルータ要請メッセージと近隣要請メッセージは使用できないとした。
もう一つの理由として、IPv6 拡張ヘッダの始点経路制御において、指定する途中経路のアドレスにも、最終的な宛先アドレスにも、マルチキャストアドレスは使用できないからである。
よって、この 2 つの案は、IPv6 拡張ヘッダの始点経路制御を用いることができたとしても、転送トポロジーを探索することは不可能な案である。
次の、第 4.2.3 節の案も機能しない。
この案にはまず、第 4.2.3 節で述べた問題点がある。そしてもう一つに、マルチキャス
トパケットに対して、ICMP によるエラーメッセージは発生されないためである。従って、

ICMP の時間超過メッセージや、ICMP ポート到達不可メッセージは送られてこないため使用できない。
最後の第 4.2.4 節の案は、実現できない。
これは、マルチキャストパケットに対して、ICMP によるエラーメッセージは発生されな
いためである。従って、ICMP の時間超過メッセージや、ICMP ポート到達不可メッセー
ジは送られてこないため実現できない。しかし、ICMP エラーメッセージがマルチキャストに返信されれば、実現可能である。

4.4

転送トポロジー探索手法

本節では、本研究で用いた手法について述べる。
第 4.1 節で述べた仕様を満たすための前提条件として、転送トポロジーを実行するホスト– 35 –

4.4 転送トポロジー探索手法

は送信ホストとする。また、その送信ホストは、検索する転送トポロジーのマルチキャスト
アドレスに対しての経路が設定されているとする。おおまかな流れは次のようになる。

• 受信ホストの探索• 各受信ホストへの最終ホップルータの探索• 各受信ホストから送信ホストへのマルチキャスト経路の探索• 各経路情報の集約・結果表示
以下では各ステップについて詳細を述べる。

4.4.1

受信ホストの探索

まず、指定されたマルチキャストグループの受信ホストを探索する手法を説明する。

ICMP echo request メッセージ (付録 A.3 参照) をマルチキャストグループ宛てに送信す
ると、request メッセージは PIM によってルータからルータへと転送され、受信ホストへと届けられる (図 4.1)。これを受信したホストは echo reply をユニキャストで echo requestを送信したホストへと送出する。これによって、受信ホストの IP アドレスを取得すること
ができる。

4.4.2

最終ホップルータの探索

第 4.4.1 節で発見した各受信ホストから送信ホストへのマルチキャスト経路を取得するた
めに、MLD mtrace メッセージを利用する。しかし、MLD mtrace メッセージは受信ホス
トではなく最終ホップルータで処理される。そのため、送信ホストから受信ホストへのマ
ルチキャスト経路での最終ホップルータを指定して、そこへユニキャストによって mtrace

query メッセージを送出する必要がある。
ここでは、送信ホストから受信ホストへのマルチキャスト経路での最終ホップルータを見つけるために traceroute のアルゴリズムを援用する。すなわち、この探索では ICMP と– 36 –

4.4 転送トポロジー探索手法

図 4.1

受信ホストの探索

ホップリミット∗1 を使用する。ホップリミットはその IP データグラムの生存時間を表している。ルータを通過するごとに、1 ずつ数値が減少していき、0 になると破棄される。この
とき破棄したルータは、発信者に対して ICMP の Time Exceeded for a Datagram (時間超過) メッセージを送信する。
まず、使用していないと思われるポート番号を選んで UDP メッセージを第 4.4.1 節で発見した各受信ホスト宛に送信する。受信ホストにこの UDP メッセージが到着した場
合には、受信ホストはそのデータを処理することができないので、ICMP の Destination-

Unreachable (宛先到達不可能) タイプの中の「ポート到達不可」を表すメッセージを返送する。これによって受信ホストまでデータが到着したことを知ることが出来る。
上記の仕組みを利用して、図 4.2 のように、ホップリミットを 1 から始め、ICMP のポート到達不可またはホップリミットが最大になるまで増やしつづけ、受信ホストまでの経路情報を得ていく。
このように、traceroute アルゴリズムを用いて取得したユニキャストにおける送信ホスト∗1 IPv4 における TTL (生存時間) に相当する。

– 37 –

4.4 転送トポロジー探索手法

図 4.2 traceroute アルゴリズム

から受信ホストへの経路における、受信ホストへの 1 つ前のホストを最終ホップルータと判
断する。

4.4.3

各受信ホストから送信ホストまでのマルチキャスト経路の取得

第 4.4.2 節でも述べたように、各受信ホストから送信ホストへのマルチキャスト経路は、
既存のプロトコル、MLD にある mtrace メッセージによって取得する。MLD mtrace メッ
セージは、MLD プロトコルの拡張機能によってアクセスされる、マルチキャストルータに実装された追跡機能を用いるメッセージタイプである。mtrace メッセージには、問合せに用いられる mtrae query メッセージと、問合せに対する返答に用いられる mtrace response
メッセージの 2 タイプがある。

mtrace メッセージによる問合せ・返答における動作の概要を図 4.3 を用いて解説する。
トレースは、受信者から送信元へ逆方向に実行される。トレースの問合せパケットは最終
ホップルータにユニキャストで送信する。問合せパケットを受信した最終ホップのマルチ– 38 –

4.4 転送トポロジー探索手法

キャストルータではトレースの応答パケットを生成し、それにそのホップでのレポートを詰め込む。そして、この応答パケットをユニキャストを使って、指定された送信元から送られてくるパケットにおける、そのルータの前段のホップであると思われるルータへ転送する。
経路上の各ルータはそのパケットにレポートを追加して転送する。トレースの応答パケット
が最初のホップルータ（送信元のネットワークに直結されているルータ）に到達すると、そのルータはトレースの問合せに指定されている応答の送り先アドレスへ最終的な形の応答を送る。
以上の仕組みを用いて、第 4.4.2 節で得た各最終ホップルータ宛に mtrace query メッセー
ジを送信し、respons メッセージを受信することで、マルチキャストグループのすべての受信者から送信ホストへのマルチキャスト経路情報を取得する。

図 4.3 mtrace メッセージの動作– 39 –

4.5 ツールの詳細

4.4.4

経路情報の集約と結果表示

第 4.4.3 節までの手順で得た、マルチキャストグループにおける送信ホストから各受信ホ
ストへのマルチキャスト経路の情報を集約し、木構造に表示する。
最初に、第 4.4.3 節までの手順で得た各マルチキャスト経路は、受信ホストから送信ホス
トへの順になっているので、これを逆の順に並べ替える (図 4.4)。次に最初の経路について幹を生成する。そして他の経路情報について生成した木と比較し、新しい子や兄弟を追加していく。(図 4.5)。これによって得られた木を結果として出力する。

図 4.4

経路情報の並べ替え

次にこの手法を実装し、結果を図示するツールの詳細な流れを説明する。

4.5

ツールの詳細

本節では、本手法を実装したツールの詳細なプロセスについて述べる。

4.5.1

概要

ツールの大まかな流れは次のようになる。

1. ICMP echo メッセージによる各受信ホストの発見– 40 –

4.5 ツールの詳細

図 4.5

経路情報の集約

2. 発見した受信ホストに対する最終ホップルータの発見
3. プログラムを 4 分停止
4. 各受信ホストから送信ホストへのマルチキャスト経路の探索
5. 各受信ホストから送信ホストへの経路を木構造に収束
6. 転送トポロジーとして木を出力
上記のそれぞれの詳細について解説する。

– 41 –

4.5 ツールの詳細

4.5.2

ICMP echo による受信ホストの発見

第 4.4.1 節で述べたように受信ホストは、ICMP echo メッセージを用いて発見する。まず ICMP echo request メッセージをマルチキャストグループ宛に送信する。そして、echo

reply メッセージを返信してきたホストをマルチキャストの受信ホストとして、受信ホスト
リストに加える。
詳細なプログラムの流れを、以下に示す (図 4.6)。

1. ICMPv6 プロトコル対応の RAW ソケットを作成 [8]。オプションとして ICMPv6
echo reply メッセージのみを受け取るようにフィルターを付ける。
2. ICMP echo request メッセージタイプのパケットを作成。メッセージの ID フィールドに他のアプリケーションによる返信と区別するため、独自の ID を付けておく。

3. パケットを送信し、一定時間の間、返信を待つ。
4. echo reply メッセージタイプで、かつ ID が一致する返信パケットを受信すると、このパケットの送信ホストをマルチキャストパケットの受信ホストとして、受信ホストリス
トに加える。

5. タイムアウトするまで、4 を繰り返す。

4.5.3

発見した各受信ホストへの最終ホップルータの発見

第 4.4.2 節で解説したように、最終ホップルータの発見には、traceroute のアルゴリズムを援用する。従って、この機能の大まかな流れは、以下となる。
まず UDP のデータグラムパケットに使用されていないようなポート番号を指定し、第4.5.2 節で発見した各受信ホストに対し、ホップリミットを 1 ホップから 1 づつ増加させな
がら、送信する。この送信に対して、ICMP time exceeded メッセージを受信すると、このメッセージを送信したホストを、そのマルチキャスト受信ホストへの経路情報の末尾に加える。また、ICMP dstination unreach メッセージを受信すると、同様にこのメッセージを送– 42 –

4.5 ツールの詳細

ICMPv6

  RAW    %$    !  " # =&(' ID)+ ,request !

ICMPv6 echo request
(ID

i=0

3

)*

 .- ,/01echo reply

No

Yes

ID

2 341

No

Yes

- ,65 789:78
,0  <+ ,5 7=?>($@A7
host[i]=;
i=i+1

図 4.6

受信ホストの発見信したホストを、そのマルチキャスト受信ホストへの経路情報の末尾に加え、UDP パケッ
トの送信を終了する。そして、得られた各受信ホストへの経路の最後から 2 番目のホストを最終ホップルータとして、最終ホップルータのリストに加える。
以上を受信ホストリストにあるそれぞれのホストに実行する。
詳細なプログラムの流れを、以下に示す (図 4.7)。受信ホストリストの全てのホストに対して以下を実行する。

– 43 –

4.5 ツールの詳細

1. 受信用の ICMPv6 プロトコル対応の RAW ソケットと、送信用のデータグラムのソケットを作成。

2. ホップ数 h を 1 から、1 づつ増加し、128 ホップまで以下を繰り返す。
（a）送信用のソケットにホップ数 h としてホップリミットのオプションを付ける。
（b）UDP パケットを送信。
（c）返信パケットを受信したら、経路情報の末尾に、そのパケットの送信ホストを加える。
（d）返信パケットが、destination unreach メッセージであれば、この受信ホストに対するパケット送信を終了し、リストの次の受信ホストについて実行する。

3. 受信ホストリストにあるそれぞれのホストの経路情報における、最後から 2 番目のホストを最終ホップルータとして、最終ホップルータリストに補完する。

4.5.4

メッセージ送出の時間間隔調整本研究における数十回の実地試験により、次の過程で行う MLD mtrace メッセージの送受信が、他パケットの送受信後に実行される場合、その他パケットの送受信の後、一定時間間隔を空けて行わなければ、MLD mtrace メッセージ受信に失敗するという結果を得た。
そして、実際に 20 回ほど作成した本手法のツールを用いて試したところ、4 分間は間隔を空けると MLD mtrace メッセージの受信に失敗する可能性は低いという結果を得た。
したがって、この過程は、次に行う MLD mtrace メッセージの送受信を、この過程以前
での動作、ICMP echo メッセージの送受信と、UDP パケットの送信と ICMP メッセージの受信の 2 つの送受信から、一定時間間隔 (4 分間) を、空けるための過程である。

4.5.5

各受信ホストから送信ホストへのマルチキャスト経路の探索

第 4.4.3 節で述べたように、マルチキャスト経路の探索は、MLD プロトコルの mtrace
メッセージを用いて行う。ツールにおけるこの機能のおおまかな流れを次に示す。

– 44 –

4.5 ツールの詳細

ICMPv6
"!#%$ & ')( RAW
h=0,h<128,h+1

  * +, h -".)/* +10%234"5678(:9<;"=
UDP >?
> @AB 

route[x][i]=>3 ?*C EDGFH C
i=i+1

I

J "KL

dst unreach

Yes

No

図 4.7

MN

最終ホップルータ発見

1. ICMPv6 プロトコル対応の RAW ソケットを作成
オプションとして、MLD mtrace response メッセージのみを受け取るようにフィル
ターを設定する。

2. MLD mtrace query パケットの作成
MLD ヘッダと MLD query フィールドの設定を行う。
3. MLD mtrace query パケットを最終ホップルータへ送信し、返答を受信。
4. mroute[x] に返答 (MLD mtrace resp メッセージ) に入っている経路情報を補完。

– 45 –

4.5 ツールの詳細

4.5.6

各受信ホストから送信ホストへの経路を木構造に集約

概要
この過程は、第 4.4.4 節で述べた方法を用いて、上記までに取得した情報を木構造で出力するための準備にあたる。おおまかな流れを、以下に示す。

1. 経路情報を逆順 (送信側ホストから受信側ホスト順) に並べ替え
木構造は送信ホストの次のルータを根とするため、経路情報を現在までの受信側ホストから送信側ホストの順の逆にする必要がある。

2. 経路情報のアドレスを番号に変換、(番号, アドレス) のリストを補完
IPv6 アドレスは文字列表記では長さが可変であるので、出力ディスプレイに表現する
木構造を作成しにくい。また、最長のものになると、表示できる木の深さの限界が大変浅くなるため、番号に変換して出力する。従って、アドレスと番号の対応表も別に出力する。

3. 経路情報を木構造に集約
4. 木構造を出力用のデータに変換
経路情報を木構造に集約する過程と、出力用データに変換する過程を以下で説明する。

経路情報を木構造に集約する過程
これまでに得られた経路情報 (mroute) の構造は次のようになっている。

mroute[受信ホスト数][送信側〜受信側のルータ数]=アドレスに対応する番号
木構造を形成するデータは図 4.8 のようになる。

経路情報を木構造に集約するアルゴリズムの大まかな流れを以下に示す。

1. 最初の受信ホストに対する経路情報 (mroute[0]) の木を生成する。

– 46 –

4.5 ツールの詳細 A) )host( A  ) )
host(

leaf(

leaf(

  )next(
 ) A  )leaf( )host(childlen(  )next(
 )childlen(  )next(
 )childlen(

図 4.8

木構造の形成2. mroute[1] の経路情報から順に最後の経路情報まで、以下を繰り返す。これまでに生成した木と比較し、新しい子や兄弟を加える。
最初の木の作り方は以下のようになる。
最初の経路情報 mroute[0] の最初のアドレス (mroute[0][0]) から、最後のアドレスまでを順に読み、その都度、その新しいアドレスの leaf を作り、直前に生成した leaf の childlen(子へのポインタ) を、その新しい leaf に向ける。
新しい経路情報を既存の木と比較し、木に加える方法は図 4.9 のようになる。

mroute[x] は host[x] に対するマルチキャストにおける経路情報とする。l は leaf 構造体へのポインタで、初期値は、生成された木の根となる leaf 構造体を指している。

木を出力用データに変換する過程
これまでに生成された木のデータを出力のために、木の親と子の間を - や | で繋げたデータに変換する過程について説明する。この過程の流れは、図 4.10 のようになる。

print[i] は i 行目に出力するデータ内容である。

– 47 –

4.5 ツールの詳細

1

mroute[x][i]
=NULL

No

Yes

returnl->host=mroute[x][i]Nol->next=NULL

Yesl->childlen
=NULL

No
Yes

Yes





l=l->childlen
i=i+1

l->next=mroute[x][i]1l=l->next

i=i+1

mroute[x][i]
=NULL

1

No

Yes

returnl=l->next

l->childlen=mroute[x][i]1l=l->childlen

1

図 4.9

4.5.7

木の追加

転送トポロジーを木構造で出力

第 4.5.6 節で得られた配列 print を print[0] から順に出力し、その都度改行することで、転送トポロジーの木構造での表示を行う。

– 48 –

4.5 ツールの詳細

1No

l->next=NULL
Yes

print[i]=print[i]+l->host

print[i]=print[i]+l->hostl->childlen=NULL

fukasa[x-1]=0YesNol->childlen=NULL

l2=l->childlen
fukasa[x-1]=x

print[i]=print[i]+"\0"

Yes

print[i]=print[i]+"---"

print[i]=print[i]+"\0"i=i+1

l=l->childlen
x=x+1

No

x=x+1
print[i]=print[i]+"---"

2
1

i=i+1
1
returnprint[i]=print[i]+"
|-"

2

2
l=l->next

print[i]=print[i]+"|-"t=0,t<x-1,t+1
1
l=l->next
x=x-1

Nofukasa[t]

0

Yes

1

print[i]=print[i]+"| "print[i]=print[i]+""2図 4.10 出力用データへの変換– 49 –

第5章

実験と結果
第 4 章で述べた方法によって作成したツールが、手法、アルゴリズム、設計、実装通りに動作し、予想通りの結果が得られるのか、また出力結果の精度をテストし、このツールの評
価・考察を行うために実験を行う。まず実験環境を示し、実験内容、結果について示す。

5.1

実験環境

まず、実験環境について述べる。
本実験に図 5.1 のようなネットワークを構築した。全ホストには FreeBSD4.4 をインストールしている。実験環境のマシンスペックは表 5.1 となっている。
マシン名

CPU

クロック周波数

メモリ

OS

dvts

PentiumIII

800Mhz

780MB

FreeBSD 4.4-RELEASE

MR1PentiumIII

450Mhz64MB

FreeBSD 4.4-RELEASE

MR2PentiumIII

450Mhz64MB

FreeBSD 4.4-RELEASE

MR3PentiumIII

450Mhz64MB

FreeBSD 4.4-RELEASE

MR4PentiumIII

450Mhz64MB

FreeBSD 4.4-RELEASE

client1

PentiumIII

800Mhz1GB

FreeBSD 4.4-RELEASE

client2

PentiumIII

500Mhz192MB

FreeBSD 4.4-RELEASE

client3

PentiumIII

450Mhz64MB

FreeBSD 4.4-RELEASE

表 5.1

実験環境マシンスペック– 50 –

5.1 実験環境

図 5.1

実験ネットワーク

cand_bootstrap_router;cand_rp;
表 5.2 /usr/local/etc/pim6sd.conf の内容

次に、各実験においてホストに割り当てられる役割に共通する設定事項を述べる。

• マルチキャストパケット送信ホスト
default 経路を設定#sysctl -w net.inet6.ip6.defmcasthlim=64• PIM-SM ルータ
FreeBSD4.4 における pim6sd-20010602a.tar.gz をインストール#sysctl -w net.inet6.ip6.defmcasthlim=64• RP
pim6sd.conf(/usr/local/etc/pim6sd.conf)(表 5.2 参照)) において、DR,RP となるように設定

– 51 –

5.2 実験 1

ホスト名

役割

dvts

マルチキャストパケット送信ホスト

MR1

PIM-SM ルータ,RP

MR2

PIM-SM ルータ

MR3

PIM-SM ルータ

MR4

PIM-SM ルータ

client1

受信ホスト

client2

受信ホスト

client3

受信ホスト
表 5.3

実験 1 内容• 受信ホストdefault 経路を設定

5.2

実験 1

実験 1 では、以下の表 5.3 に示すように、送信ホストを dvts、RP を mr1、受信ホストを

client1,client2,client3 として、送信ホストにてツールの実行を試み、そのときの出力結果を調べた。
実験 1 の結果として、図 5.2 の出力が得られた。

5.3

実験 2

この実験 2 では、以下の表 5.4 に示すように、送信ホストを dvts、RP を mr1、受信ホス
トを client1,client2 として、送信ホストにてツールの実行を試み、そのときの出力結果を調べた。
実験 2 の結果として、図 5.3 の出力が得られた。

– 52 –

5.3 実験 2

Multicast Delivering Topology----------------------------01---02
|-03
|-04
Address measurement table [No.]Address-------------------------------------[01] d1::1[02] 3c::3[03] 4c::4[04] 2c::2
図 5.2

実験 1 結果

ホスト名

役割

dvts

マルチキャストパケット送信ホスト

MR1

PIM-SM ルータ,RP

MR2

PIM-SM ルータ

MR3

PIM-SM ルータ

MR4

PIM-SM ルータ

client1

受信ホスト

client2

受信ホスト

client3なし
表 5.4

実験 2 内容

Multicast Delivering Topology----------------------------01---02|-03
Address measurement table [No.]Address-------------------------------------[01] d1::1[02] 4c::4[03] 2c::2
図 5.3

実験 2 結果– 53 –

5.4 実験 3

ホスト名

役割

dvts

マルチキャストパケット送信ホスト

MR1

PIM-SM ルータ

MR2

PIM-SM ルータ

MR3

PIM-SM ルータ,RP

MR4

PIM-SM ルータ

client1

受信ホスト

client2

受信ホスト

client3

受信ホスト
表 5.5

実験 3 内容

Multicast Delivering Topology----------------------------01---02---03|-04
Address measurement table [No.]Address-------------------------------------[01] 3c::3[02] d1::1[03] 4c::4[04] 2c::2
図 5.4

5.4

実験 3 結果

実験 3

この実験 3 では、以下の表 5.5 に示すように、送信ホストを dvts、RP を mr3、受信ホス
トを client1,client2,client3 として、送信ホストにてツールの実行を試み、そのときの出力結果を調べた。。
実験 3 の結果として、図 5.4 の出力が得られた。

– 54 –

5.5 実験 4

ホスト名

役割

dvts

マルチキャストパケット送信ホスト

MR1

PIM-SM ルータ

MR2

PIM-SM ルータ

MR3

PIM-SM ルータ,RP

MR4

PIM-SM ルータ

client1

受信ホスト

client2なし

client3

受信ホスト
表 5.6

実験 4 内容

Multicast Delivering Topology----------------------------01---02---03
Address measurement table [No.]Address-------------------------------------[01] 3c::3[02] d1::1[03] 4c::4
図 5.5

5.5

実験 4 結果

実験 4

この実験 4 では、以下の表 5.5 に示すように、送信ホストを dvts、RP を mr3、受信ホス
トを client1,client3 として、送信ホストにてツールの実行を試み、そのときの出力結果を調べた。
実験 4 の結果として、図 5.5 の出力が得られた。

– 55 –

第6章

評価と考察
第 4 章における手法を実装したツールについて、第 5 章での実験結果を基にこのツールの有効性や精度などついて評価・考察する。

6.1

評価

実験においては予想通りの結果を得ることができた。これにより、本研究における提案手法・アルゴリズム・設計・実装の全てにおいて成功したと言える。
また、PIM-SM は、初期では共有ツリーを用いたルーティングを行い、トラフィックなどが多くなった時点で送信元ツリーも同時に用いたルーティングを行うプロトコルである。しかし、今回は共有ツリーのみを用いたルーティングを行っている環境でのみの実験しか行えなかった。したがって、両ツリーを用いたルーティングを行っている時点での実験も必要であると考える。
今回の実験は、マルチキャスト経路プロトコルに PIM-SM を用いている。しかし、PIM-

DM におけるマルチキャストルーティングを用いたネットワークで実験することができなかった。この環境についての実験も必要であると考える。

– 56 –

6.2 考察

6.2

考察

6.2.1

ツールの実装IPv6 における転送トポロジーを探索する手法を提案し、マルチキャストの管理に有効なツールの実装ができた。制限はあるものの、この手法であっても、マルチキャストにおけるトラブルにおいて新たな現状が把握できる。
次のような例を考える。このツールを実行することで、マルチキャストパケットが転送される範囲を得る。そこでマルチキャストパケットを送信したとする。すると同じサブネット
上に受信に成功したホストと成功しなかったホストが現れたとする。
ここで、ツールの結果でパケットは転送されてサブネット上に流れていることが判明していると、転送失敗以外に受信失敗の原因があると判断できる。
したがって、本ツールで得られる転送トポロジーの Tree は、マルチキャストパケットが転送される範囲が把握でき、マルチキャスト経路プロトコルにおける転送失敗と他の原因を区別することができる。
また、既存のプロトコルのみを用いることによって、一台のホストに実装するのみで、探索を実行可能にできたことは、ツールとして大変実用的であり、有用性が高いと言える。

6.2.2

OS の実装とプロトコル

今回、第 5 章の結果から分かるように、結果が RP から下流の転送トポロジーのみしか表示されていない。
これは、送信ホストからマルチキャストパケットを送信している状態で実験を行っていな
いからである。つまり、受信ホストがマルチキャストグループへ参加しているのみでマルチ
キャストパケットは受信していない状態で実験を行っている。
これは、第 4.5.4 節で解説したように、mtrace メッセージを送受信する前のある一定の期間に、パケットの送受信を行うと mtrace メッセージの送受信が成功しないからである。
つまり、マルチキャストパケットを送信しているという状態でツールを実行しても、– 57 –

6.2 考察

mtrace メッセージが送受信できず、マルチキャスト経路が得られない。
よって、送信ホストからマルチキャストパケットを送信しない状態で実験を行っている。
上記の状態で、RP から下位の転送トポロジーしか得られない理由は、第 2.4.6 節の RPの登録から分かる。
つまり、マルチキャストパケットが送信されないと、送信ホストの先にある DR にマル
チキャストパケットが到達しないため、Register メッセージが発生しない。このため、このメッセージによる、RP から上流のこの DR への経路上において、マルチキャストグルー
プへの Join がされない。したがって、この DR から RP へのマルチキャスト経路が確立しない。
よって、RP から下流のマルチキャスト経路しか確立せず、この RP から下流の経路しか得られない。
この mtrace メッセージの送受信が他のパケットの送受信に影響されて成功しない点について、今回用いている OS である FreeBSD4.4 の実装が、プロトコル通りに動作しているのかという検証が必要であると考える。

6.2.3

制限事項

実行ホスト
制限の一つである、送信ホストのみにおける実行については、どのホストにおいても実行できる手法にすることができれば、本ツールの利用範囲が広がることになったと考ることもができたと考える。また、送信ホストにおいてマルチキャストネットワークへのパケットの到達性が全体図として把握できる本ツールは、送信者にとっては有効であると考える。

ICMP echo request を送出するホストにおいてマルチキャストグループにおける経路が設定されていないとパケットを送出することはできない。したがって、本手法を実行するホストは検索するグループにおける経路が設定されていることを前提とする。
送信ホストでは、この前提事項を満たしていなければパケットを送出することもできない– 58 –

6.2 考察ため、送信ホストが実行ホストである前提事項は当り前であるが、次のようなことが考えられる。
本研究の手法の全貌から理解できるが、指定されたマルチキャストグループに対しての経路が設定されていれば、マルチキャスト経路上のどのルータでも実行でき、そのルータから
下位 (自ホストから受信ホスト) の転送トポロジーは把握できる手法となる。

マルチキャスト経路情報の取得

MLD の mtrace query メッセージをマルチキャストにおける最終ホップルータでなく、ユニキャストにおける最終ホップルータに向けて送信することが、1 つの問題点である。
もし、ユニキャストにおける最終ホップルータとマルチキャストにおける最終ホップルータが同一でない場合、MLD の mtrace query メッセージに応答がない。したがって、受信ホストへマルチキャストパケットが到達していたとしても、その最終ホップルータに対するマルチキャスト経路は 1 ホップ分も取得できなくなることが問題となる。
また、MLD の mtrace query メッセージを使用することについても、問題がある。これには、mtrace query メッセージに対してに返ってくる経路情報が、送信ホストから受信ホストへの経路における最終ホップルータから、上流に向かって各ホストでの情報を追加して返信されてくる response メッセージを受信することで得ることに原因がある。
例えば、マルチキャストパケットが、最終ホップルータまで達せず、途中のルータまでしか転送されていないとする。そしてかつ、この途中のルータより下流のルータまでへは、受信側から Join がされているとする。すると、その下流のルータの経路情報のみの中途半端な経路を得ることとなる。
つまり、本研究における手法を実装したこのツールには、ユニキャストにおける最終ホッ
プルータとマルチキャストにおける最終ホップルータが同じである場合のみ、その最終ホッ
プルータから送信側へのマルチキャスト経路情報が得ることができる。
したがって、本ツールの動作を厳密に記述すると最終ホップルータから送信側へ Join し– 59 –

6.2 考察ているルータまでの木構造を、上記の制限の上で正確に出力するツールとなる。

6.2.4

プロトコルの改良

本研究では、既存のプロトコルを用いて、1 つのホストにツールを実装することによって、転送トポロジーの情報を得るということを仕様としていた。しかし、現在のプロトコルにおいて、下流のマルチキャストルーティングやルータに関する情報を問い合わせて、応答を得るというものは MLD の mtrace query メッセージのみである。したがって、ユニキャスト
におけるプロトコルの使用は避けられなかったと考える。
また、MLD の mtrace メッセージにおいても、マルチキャストが逆経路転送であるため、受信ホストから送信ホストへのマルチキャスト経路を得るためのメッセージとなっている。
したがって、現段階では送信ホストからネットワーク全体への正確なマルチキャストパケッ
トの到達性に関しては把握できる手法を提案することは不可能であったと考える。
しかし、マルチキャスト経路プロトコルにおいて、通常の機能として不要なものである
が、MLD の mtrace メッセージのようなトラブルシューティングのためのプロトコルとして、送信ホストの次ホップルータからホスト情報を加えて下流に転送し、最終ホップルータ
からユニキャストで応答を得るプロトコルがあれば、正確な転送トポロジーが把握できる。
また、マルチキャストに対して ICMP が応答するようにし、かつ IPv6 拡張ヘッダの始点
経路制御においてもマルチキャストアドレスを使用できるようにプロトコルを変更することでも、正確な転送トポロジーの把握が実現できる。
この案が採用されると、第 4.2.4 節に示したホップリミット付きマルチキャストパケットと IPv6 拡張ヘッダの始点経路制御を用いた探索手法案を採用することができる。
しかし、これには、多量の ICMP メッセージが送信ホストへ送られることとなり、送信ホストへの負荷を挙げることとなるというデメリットがある。特に発信元アドレスを偽造す
ると、他のホストに対する DoS アタックが可能になることが問題となる。
もう一つに、MLD mtrace メッセージを受信ホストで有効にするという案がある。この場合、ツールを実行しないホストに対して、そのホストにあまり利益のない処理を追加する– 60 –

6.2 考察必要がある。
しかし、これらのプロトコル改良を行うと、本研究で提案した手法におけるユニキャスト
における最終ホップルータとマルチキャストにおける最終ホップルータが同じ場合のみとい
う制限がなくなり、より正確でシンプルな手法が提案できると考える。

– 61 –

第7章

まとめ
マルチキャストの管理において、現状を把握するツールが十分にないという問題点を指摘した。そして、IPv6 マルチキャストにおいて複数経路を表示するツールが存在しないことを挙げた。そこで、本研究では IPv6 マルチキャストにおける転送トポロジーの探索手法の提案を行い、UNIX 上のツールとして実装した。
手法は、ICMP の echo メッセージを用いて受信ホストを見つけ、ユニキャストにおけるtraceroute のアルゴリズムを用いて受信ホストへの最終ホップルータを得る。その最終ホップルータに向けて、MLD の mtrace query メッセージを送出することによって、送信ホス
トから受信ホストへの各マルチキャスト経路を得る。そして、得られた各受信ホストへのマ
ルチキャスト経路を集約し、Tree 構造で表示するものである。
この手法では、ユニキャストにおける最終ホップルータとマルチキャストにおける最終ホップルータが同じである場合のみ正確に機能することと、このツールが送信ホストのみで実行が可能であるという制限が生じた。
今後の課題として、このツールのマルチキャスト経路プロトコル PIM-DM における実験と、PIM-SM の共有ツリーと送信元ツリーが混在する状況における実験を行う必要がある。
また、MLD mtrace メッセージの動作については、FreeBSD4.4 の実装がプロトコル通りに動作しているのか検証する必要がある。
最後に、マルチキャストのデバッグツールに有効となるプロトコルの改良の提案を行いたい。

– 62 –

謝辞
インテックウェブアンドゲノムインフォマティックスの中川いくおさん、小杉さん、木村さん、金山さん、楠田さん、富山県総合情報センターの糸岡さん、東北大学の曽根先生、山梨県立女子短期大学の八代先生、山梨大学の深澤さん、広島大学の相原先生、東北日立の樋地さん、名古屋大学の長谷川先生、ニスカ株式会社の笹本さん、ソフトピアジャパンの石田さん、山田さん、映像配信実験の際は大変お世話になりました。ありがとうございます。その他、地域間相互接続実験プロジェクトのメンバーの方々にも感謝します。

KPIX 実験研究協議会のメンバーである高知大学の菊地先生、高知高専の今井先生、高知システムズの松本さん、シティネットの澤本さん、富士通高知システムエンジニアリングの平田さん、高知県工業技術センターの武市さん、今西さん、高知県情報企画課の蒲原さん、
高知電子計算センターの森さん、山梨国体映像配信実験の際はお世話になりました。
島村和典教授をはじめとする、TAO 通信トラヒックリサーチセンターの皆様に感謝します。
本研究に多大な助言をくださった、同じ菊池研究室の修士の、廣瀬さん、西内さん、正岡さん、田渕さん、舟橋さんに感謝します。同じ菊池研究室で本研究の協力と、各中継実験において助言をくれた、豊島君に感謝します。同じ菊池研究室の小川さん、澤田さん、澤野君、前田さんに感謝します。
最後に、菊池 豊助教授に心から感謝します。

– 63 –

参考文献[1] 内山長承. 情報処理 高信頼マルチキャスト, 第 42 巻. aug 2001.
[2] Thomas A. Maufer. IP マルチキャスト入門. Nov 2000.
[3] Dave Kosiur. マスタリング TCP/IP IP マルチキャスト編. Nov 1999.
[4] S. Deering A. Conta. Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification, Dec 1998.
[5] B. Haberman S. Deering, W. Fenner, et al. Multicast Listener Discovery (MLD) for
IPv6, Oct 1999.
[6] William Siadak Andrew Adams, Jonathan Nicholas. Protocol Independent Multicast- Dense Mode (PIM-DM) Protocol Specification(revised), Nov 2001. draft-ietf-pimdm-new-v2-00.tex.
[7] A. Helmy D. Thaler S. Deering M. Handley V. Jacobson C. Liu P. Sharma L. Wei
D. Estrin, D. Frinacci, et al. Protocol Independent Multicast-Sparse Mode (PIMSM):Protocol Secification, Jun 1999. RFC2362.
[8] W. Richard Stevens. UNIX ネットワークプログラミング第 2 版 Vol.1 ネットワーク
API:ソケットと XTI. Jul 2000.

– 64 –

付録 A

関連技術用語A.1

RPM (Reverse-Path Multicasting)

RPM は配布木を次のようなものだけから構成する。
• グループのメンバが存在するサブネットワーク• これらのグループのメンバが存在する各サブネットワークへ始点から到達する最短経路
上のルータとサブネットワーク

RPM によって始点からの「最短経路木」は「枝刈り」され、データグラムは終点グループの動作しているメンバに至る枝に沿ってだけ転送される。

A.1.1

動作

マルチキャストルータが (送信ホスト, グループ) の組に対応するパケットを受信した場
合、最初のパケットは、インターネット内のすべてのルータに沿って転送される。ネット
ワーク端にあるルータ (末端のサブネットワークにしか接続していない) は、末端ルータ(リーフルータ) と呼ばれる。各リーフルータが少なくとも最初のマルチキャストパケットを送信することを保証している。リーフルータは、グループのメンバが 1 つ以上そのサブネッ
トワークに存在すればパケットを転送する。
図 A.1 のように、リーフルータのサブネットワークにこのグループのメンバがいなければ、リーフルータは上流のルータにそれを通知する。この情報は上流のルータにこの特定の始点から特定のグループへのパケットをリーフルータに転送しないよう知らせる。ある始点– 65 –

A.1 RPM (Reverse-Path Multicasting)からグループへのトラフィックを簡単に表す方法として、(送信ホスト, グループ) の組を用いる。この処理は枝刈りと呼ばれる。RPM の枝刈りメッセージは始点に向けて 1 ホップ戻
るほうに送られる。枝刈りメッセージを受け取った上流ルータはしばらくの間、この枝刈り情報をメモリに保存しなければならない。
枝刈りの情報は、ある一定の生存時間だけ保持される。各枝刈りメッセージの保存時間が切れると、ルータはメモリからそれを消去する。この始点がこのグループに対して送信を続けていれば、この (送信ホスト, グループ) の組に対する次のパケットはすべての下流ルータに対してブロードキャストされる。これによって、失効状態 (すでに動作していないグループに対する枝刈り情報) になっていた領域が、マルチキャストルータによって再利用される。

図 A.1 RPM 枝刈り– 66 –

A.2 RPF チェック

A.1.2

接ぎ木

あるグループに関して受信者がある枝の先にはいないことを示す枝刈りメッセージが上流に送られ、後でこのグループのメンバが現れるた場合の動作を説明する。
グループの新しいメンバに直接隣接するルータは、このグループに関する枝刈りメッセー
ジを過去に送ったことを記憶しており、この始点に関する 1 ホップ前のルータがどれであるかを知っている。ルータは接ぎ木 (graft) メッセージを上流、つまり 1 ホップ始点に近いほうに送り、自分自身の枝刈り情報を削除する。
この処理は、この (送信ホスト, グループ) の組の配布木の動作している枝に達するまで続けられる。この以前は動作していなかった枝が、(送信ホスト, グループ) の組の配布木に加えられ、データがグループの新しいメンバに向けてながされる。図 A.2 はこの RPM の接ぎ木のようすを示している。各接ぎ木メッセージは信頼性をもって送られ、下流のルータは(特定の送信ホストに向けての) 手前のホップがそれを受信したことを確実にできる。

A.2

RPF チェック

ルータが実行する RPF チェックのタイプは、ツリーが RPT か SBT かによって異なる。RPT の場合の RPF チェックは、RP の IP アドレスを使用する。SBT の場合の RPF
チェックは、送信元のアドレスを使用する。両方のケースを図 A.3 に示す。
送信ホスト 1 からのマルチキャストトラフィックは RPT を使用する。つまり、送信ホス
ト 1 は、マルチキャストグループではなく RP にトラフィックを送る (ルータがこれを明示するには、(S, G) エントリの代わりに (*, G) エントリを使用する)。
このトラフィックを送信する前に、ルータ 1 はユニキャストルーティングテーブルをチェックし、RP からのパケットが正しいインターフェイスに到着しているかどうかを確認する。この場合は正しいインターフェイス I1 に到着しているので、パケットは転送される。
送信ホスト 2 からのマルチキャストトラフィックは、SBT を使用する (ルータがこれを明示するには、送信元に (S, G) エントリを使用する)。この場合、ルータは送信元の IP ア

– 67 –

A.3 ICMP

図 A.2 RPM 接ぎ木

ドレスを使って RPF チェックを実行し、ユニキャストルーティングテーブルで送信元からのトラフィックが正しいインターフェイスに到着していることを確認する。例では、正しい
インターフェイスに到着しているので、トラフィックは転送される。

A.3

ICMP

ICMP の概要について解説し、本論文で用いた ICMP echo メッセージを取上げて説明
する。

A.3.1

概要

ICMP (Internet Control Message Protocol) は、ネットワーク層に含まれるプロトコル
で、エラーなどの状況報告を行うためのメッセージを提供するものである。IP データの転– 68 –

A.3 ICMP

図 A.3 RPF チェック

送の際にエラーが発生したときには、そのデータの送信元に対して ICMP メッセージが送信される。ICMP は IP データグラムと同じ方法で転送されるため、ICMP メッセージの到達の保証はない。また、ICMP はエラーの報告を行うだけであり、その対応はアプリケー
ションに任されることになる。ICMP のメッセージは、図 A.4 のように IP データグラムによってカプセル化されている。

図 A.4 ICMP メッセージ

ICMP メッセージはタイプとコードによりメッセージの意味が定義されている。オプショ
ンの部分はタイプとコードにより内容が変わる。

A.3.2

ICMP メッセージタイプ

IPv6 における ICMP メッセージタイプは表 A.1 のようになっている。

– 69 –

A.3 ICMP

タイプ

メッセージ

1

Destination Unreachable（終点到達不可）

2

Packet Too Big（パケット過大）

3Time Exceded for a Datagram（時間超過）

4

Parameter Problem（パラメータ不良）

5

Redirect（リダイレクト）

128

Echo Request（エコー要求）

129

Echo Reply（エコー応答）

130Group Membership Query（グループメンバシップ問合せ）

131Group Membership Query（グループメンバシップ報告）

132Group Membership Reduction（グループメンバシップ縮小）

133

Router Solicitation（ルータ要請）

134

Router Advertisement（ルータ広告）

135

Neighbor Solicitation Message（近隣要請）

136

Neighbor Advertisement（近隣広告）

137

Redirect（リダイレクト）
表 A.1 ICMP メッセージタイプ– 70 –

付録 B

映像配信実験まとめ

B.1

富山国体

• 参考 URL
2000 年とやま国体 http://www.pref.toyama.jp/sections/1901/kookutai/• 日程
2000 年 10 月 14 日 〜 12 月 19 日
• 配信元
インテック ウェブ アンド ゲノム• 番組内容富山県にて行われた富山国体の中継映像。

• 配信データ形式– DV over ATM
富山→ TRIX、高知、山梨、福岡、熊本、CRL、名古屋、岐阜、会津– RealMedia,WMT
富山 IX 内にて配信– 71 –

B.2 Live!Eclipse(皆既月食中継)

B.2

Live!Eclipse(皆既月食中継)• 参考 URL
ライブ！エクリプス実行委員会

http://www.live-eclipse.org• 日程
2001 年 1 月 10 日
• 配信元
INTEC Web and Genome Informatics Corporation• 番組内容ライブ！エクリプス実行委員会によって NTT 大手町に集められた各地からの月食映像を編集した映像。映像は、札幌、関東、京都府精華町、岡山県美星、佐賀、沖縄で撮影された。

• 配信データ形式
Realvideo,QuickTime,WindowsMedia (RADIX+Tenbin)(NTT 大手町→各地)
Windows Media over 衛星 (→高知)

B.2.1

ネットワークトポロジー

B.3

山梨かいじきらめき国体中継実験• 参考 URL
http://www.yamanashi-ken.ac.jp/kaz/kokutai-y/• 日程
2002 年 2 月 27 日 〜 2 月 31 日
• 配信元
Y-NIX

– 72 –

B.4 ギガビットネットワークフォーラム in 富山• 番組内容山梨県にて行われた「かいじきらめき国体」の競技中継映像。放送した競技は、「フィギュアスケート成年 SP 」、「フィギュアスケート成年フリー」、フィギュアスケート少年フリー」、「ショートトラック 1000m リレー予選」、「ショートトラック 1000m リレー
決勝」• 配信データ形式

B.3.1

ネットワークトポロジー

B.4

ギガビットネットワークフォーラム in 富山• 参考 URL
報道発表 URL

http://www.gigafo.toyama-ix.net
実験用 URL

http://www.toyama-ix.net/event/gigafo2001/
IP 実験用 URL
http://www.toyama.ix.net/event/gigafo2001/index-ip.html• 日程2001 年 5 月 28 日
• 配信元
INTEC Web and Genome Informatics Corporation ?
• 番組内容富山国際会議場で行われたギガビットネットワークフォーラム 2001 の映像。プロ
グラムとして、「ユビキタス＆ブロードバンドネットワークのビジネスインパクト」、– 73 –

B.5 Live!Eclipse(日食)「CAN(コニュニティ エリア ネットワーク) とコアラ」、「高度情報通信ネットワーク社
会の形成に向けて」、「地域における IT の取組と今後の課題」。

• 配信データ形式
DV over ATM (LinkUnit) (富山→石川、福井、福岡、三重、名古屋、岐阜、大阪、高知)
DV over IPv4 Multicast over ATM (DVTS)(高知→山梨、富山)
Realvideo,Windows Media over IPv4 Multicast over ATM (富山→高知、山梨、岐阜、富山地域 IX)

Realvideo(500K,1Mbps)+WindowsMedia(1.5Mbps)

B.4.1

ネットワークトポロジー

図 B.1 参照。

B.5

Live!Eclipse(日食)• 参考 URL
Live!Eclipse 2001
http://www.live-eclipse.org/jpn/• 日程2001 年 6 月 21 日
• 配信元
広島大学

• 番組内容ライブ！エクリプス実行委員によってライブ！エクリプスエンコーディングセンターに集められたアフリカの日食中継を編集した映像。映像はジンバブエ、ザンビア、マダガ
スカルで撮影したもので、番組内容も本格的なものであった。

– 74 –

B.5 Live!Eclipse(日食)

図 B.1

ギガビットネットワークフォーラム in 富山中継ネットワーク図• 配信データ形式– RealVideo, QuickTime, WMT(RADIX + Tenbin)
エンコーディングセンター→各地– MPEG2Ts over IPv4multicast 広島→福岡、佐賀、高知、京都、岐阜、山梨、富山、東京、TRIX

B.5.1

ネットワークトポロジー

図 B.2 参照。

– 75 –

B.6 DSM 中継

図 B.2 Live!Eclipse(日食) ネットワーク図

B.6

DSM 中継• 参考 URL
http://www.live-eclipse.org• 日程
2001 年 7 月 27 日
• 配信元
高知工科大学菊池研究室• 番組内容高知工科大学にて行われた情報処理学会「分散システム／インターネット運用技術」研
究会第二回定例会の生中継映像。

• 配信データ形式
Windows Media over IPv4 (Internet,kpix へ)DV over IPv4 over ATM(高知→富山 (RIBB))– 76 –

B.7 みちのく YOSAKOI まつり中継

B.6.1

ネットワークトポロジー

図 B.3 参照。

図 B.3 DSM 中継ネットワーク図

B.7

みちのく YOSAKOI まつり中継• 参考 URL
地域マルチメディアネットワーク研究会 (中継映像の Download)

http://corent-co.jp/CATV
みちのく YOSAKOI 祭り

http://michinoku-yosakoi.net/– 77 –

B.8 新湊曳山祭り中継• 日程
2001 年 9 月 22 日
• 配信元
TRIX
• 番組内容みちのく YOSAKOI 祭りの中継映像。

• 配信データ形式– DV over ATM(LinkUnit)
TRIX →高知、名古屋、富山– WMT(1.5Mbps)
TRIX →富山

B.7.1

ネットワークトポロジー

B.8

新湊曳山祭り中継• 参考 URL
技術情報 URL

http://www.toyama-ix.net/event/hikiyama
中継 URLhttp://www.toyama-ix.net/live/hikiyama• 日程2001 年 10 月 1 日
• 配信元
富山

• 番組内容– 78 –

B.8 新湊曳山祭り中継

新湊ケーブルネットワークにおいて放送された新湊曳山祭りの映像。

• 配信データ形式
DV over ATM (LinkUnit) (富山→ TRIX、福岡、岐阜)
DV over IPv6 over ATM (富山→高知、山梨)
WindowsMedia( 100,300Kpbs) (富山地域 IX へ)
DV over IPv6 Multicast over ATM (富山→高知、山梨) →失敗

B.8.1

ネットワークトポロジー

図 B.4 参照。

図 B.4

新湊曳山祭り中継ネットワーク図– 79 –

B.8 新湊曳山祭り中継

マシンスペック• ATM-R– 富山 (高知向けの構成)
PRODUCT

Dell Optiplex GX110

CPUPentium III 930 MHz, Memory: 512 MBOS

FreeBSD 4.3-RELEASE + ALTQ-3.0(altq-3.0-sys-altq-freebsd-4.3.patch)

ATM-NIC

Efficient Networks ENI-155p (en0)

Eth-NIC

3Com 3c905C-TX Fast Etherlink Xl (xl0)

– 高知
CPU

Pentium

800 MHz,Memory:768 MBOS

FreeBSD 4.3-RElEASE + ALTQ-3.0(altq-3.0-sys-altq-freebsd-4.3.patch)

ATM-NIC

Efficient Networks ENI-155p (en0)

Eth-NICIntel Pro 10/100B/100+ Ethernet

– 山梨
CPU

Pentium III 600MHz, Memory: 256 MBOS

FreeBSD 4.3-RELEASE + ALTQ-3.0(altq-3.0-sys-altq-freebsd-4.3.patch)

ATM-NIC

Efficient Networks ENI-155p (en0)

Eth-NIC• DVTS マシン

Intel Eter Express Pro (fxp0)– 富山 1(高知向けの構成)
PRODUCT

Dell Optiplex GX110

CPUPentium III 930 MHz, Memory: 512 MBOS

FreeBSD 4.3-RELEASE + firewire-freebsd-4.3-20010910

ieee1394

Digital Origin MotoDV (lynx0: Texas Instrument PCILynx)

Eth-NIC

3Com 3c905C-TX Fast Etherlink Xl (xl0)

software
DVTS-0.3.6– 富山 2(山梨向けの構成)– 80 –

B.9 みやぎ国体中継

PRODUCT

Dell Optiplex GX110

CPUPentium III 930 MHz, Memory: 512 MBOS

FreeBSD 4.3-RELEASE + firewire-freebsd-4.3-20010910 + ALTQ-3.0(altq-3

ieee1394

Digital Origin MotoDV (lynx0: Texas Instrument PCILynx)

ATM-NIC

Efficient Networks ENI-155p (en0)

Eth-NIC

3Com 3c905C-TX Fast Etherlink Xl (xl0)

software

DVTS-0.3.6

– 高知
CPU

Pentium

800MHz:Memory 768 MBOS

FreeBSD 4.3-RELEASE + firewire-freebsd-4.3-20010910

ieee1394

Digital Origin MotoDV (lynx0: Texas Instrument PCILynx)

Eth-NICIntel Pro10/100B/100+ Ethernet

software

DVTS-0.3.6

– 山梨

B.9

CPU

Pentium III 1GHz, Memory: 256 MBOS

FreeBSD 4.3-RELEASE + firewire-freebsd-4.3-20010910

ieee1394

Digital Origin MotoDV (lynx0: Texas Instrument PCILynx)

Eth-NICIntel Eter Express Pro (fxp0)

software

DVTS-0.3.6

みやぎ国体中継• 参考 URL
みやぎ国体映像配信実験関係者のためのメモのページ

http://web.tia.ad.jp/kokutai2001/「新世紀・みやぎ国体」
宮城県秋期国体映像配信実験 http://kokutai.toyama-ix.net/miyagi01/「第 1 回障害者スポーツ大会」映像配信実験

http://kokutai.toyama-ix.net– 81 –

B.10 国際会議 ISOM 中継• 日程
新世紀・みやぎ国体

2001 年 10 月 13 日 〜 10 月 18 日
障害者スポーツ大会

2001 年 10 月 27 日 〜 10 月 30 日

• 配信元
TRIX
• 番組内容宮城県にて行われた「新世紀・みやぎ国体」および「障害者スポーツ大会」の中継映像。
「新世紀・みやぎ国体」においては開会式、サッカー、バドミントン、柔道、閉会式の映像が。「障害者スポーツ大会」においては開会式、陸上競技、フライングディスク、車
椅子バスケット、閉会式の映像が流された。

• 配信データ形式– DV over ATM(LinkUnit)
TRIX →高知、富山– WMT(500Kbps, 1Mbps)
TRIX →高知、山梨、富山

B.9.1

ネットワークトポロジー

B.10

国際会議 ISOM 中継• 参考 URL
国際会議 ISOM 2001 富山サテライト– 82 –

B.11 ギガビットネットワーク・シンポジウム in 沖縄

http://www.toyama-tic.co.jp/isom/
実験 URLhttp://www.toyama-ix.net/event/isom• 日程
2001 年 11 月 11 日〜 12 日
• 配信元
富山

• 番組内容富山で行われた国際会議 ISOM 2001 富山サテライトの映像。

• 配信データ形式
DV over IPv6 Multicast over ATM (富山→高知、山梨、TRIX)
DV over IPv6 Multicast (JGN6 上で富山→ TRIX(大手町機器の不調で失敗)
富山県内の CATV 局番組としても放送 (会場からの映像は、LinkUnit の映像を利用)

B.10.1

ネットワークトポロジー

図 B.5 参照。

B.11

ギガビットネットワーク・シンポジウム in 沖縄• 参考 URL
ギガビットシンポジウム沖縄

http://www.jgn.tao.go.jp/sympo2001/• 日程
2001 年 11 月 19 日 〜 11 月 20 日
• 配信元
どこか

– 83 –

B.11 ギガビットネットワーク・シンポジウム in 沖縄

図 B.5 ISOM 中継ネットワーク図• 番組内容沖縄で行われたギガビットネットワーク・シンポジウムの中継映像。

• 配信データ形式– DV over ATM(LinkUnit)– DV over IPv6(DVTS)– 84 –