修士論文 帯域を削減するための下流受信者数に応じた ユニキャスト通信

NAIST-IS-MT0051035
修士論文
帯域を削減するための下流受信者数に応じた
ユニキャスト 通信とマルチキャスト 通信の切り替え
機構の提案と評価
河野 智彦
2002 年 2 月 8 日
奈良先端科学技術大学院大学
情報科学研究科 情報システム学専攻
本論文は奈良先端科学技術大学院大学情報科学研究科に
修士 (工学) 授与の要件として提出した修士論文である。
河野 智彦
審査委員：
山口 英 教授
砂原 秀樹 教授
門林 雄基 助教授
帯域を削減するための下流受信者数に応じた
ユニキャスト 通信とマルチキャスト 通信の切り替え
機構の提案と評価3
河野 智彦
内容梗概
マルチキャストはストリーミング配送の問題を解決できる技術である．しかし，
現在のマルチキャストは，インターネット規模では動作していない．これは，イ
ンタード メインマルチキャストプロトコルが十分に開発されていないためである．
インタード メインマルチキャストプロトコルの実現は，解決していない問題があ
るため多くの時間が必要であると考えられる．そこで，本論分ではマルチキャス
トネットワークをド メインをまたいで，接続することが可能なトンネル技術に注
目をした．トンネル技術には，mrouted と Automatic Tunneling Protocol がある．
しかしながら，これらの方式では実際のインターネットで利用するには問題点が
ある．そこで本論分ではこれらの問題を解決することのできるトンネル技術とし
て MCDP の提案を行った．また，MCDP の実装と実験による評価を行い，その
動作の検証を行った．
キーワード
インターネット , ユニキャスト , マルチキャスト , マルチキャストプロトコル，ト
ンネル技術，切り替え機構
3 奈良先端科学技術大学院大学 情報科学研究科 情報システム学専攻 修士論文,
MT0051035, 2002
年
2
月
8
日.
i
NAIST-IS-
A switching mechanism from unicast to
multicast to reduce bandwidth consumption
based on the number of users3
Tomohiko Kohno
Abstract
Multicast is thought as the method to use network bandwidth more eectively
than unicast for realtime streaming applications. But, multicast is not widely
used in the real internet. That is because current interdomain multicast routing
protocol is not adopted widely, for the problems to be solved. We forcused tunneling mechanism that can transport the multicast stream using unicast connections
over non-multicast network. But, there are some problems in current tunneling
mechanism. I proposed MCDP (Multicast Capability Discovery Protocol) that
can solve these problems. In this thesis, I explain the detail of the proposed
mechanism and implementation on NetBSD. Then, I evaluate the usefulness of
our mechanism through experiment.
Keywords:
Internet, Unicast, Multicast, Switch mechanism, Number of users
3 Master's
Thesis, Department of Information Systems,
Graduate School of Information
Science, Nara Institute of Science and Technology, NAIST-IS-MT0051035,
ii
February 8, 2002.
目次
1. はじめに
2
2. マルチキャスト 通信技術
4
2.1 イントラド メインマルチキャスト : : : : : : : : : : : : : : : : : :
4
2.1.1 PIM-SM (Protocol Independence Multicast Protocol - Sparce
Mode) : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6
7
2.1.2 イントラド メインマルチキャストの現状 : : : : : : : : : :
2.2 インタード メインマルチキャスト : : : : : : : : : : : : : : : : : :
7
2.2.1 MSDP(Multicast Source Discovery Protocol : : : : : : : :
7
2.2.2 インタード メインマルチキャストの問題 : : : : : : : : : :
8
8
2.3 トンネル技術 : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
2.3.1 mrouted のトンネル技術 : : : : : : : : : : : : : : : : : : :
9
2.3.2 Automatic Tunnering Protocol(AMT) : : : : : : : : : : : : 10
2.4 研究の目的 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11
3. MCDP(Multicast Capability Discovery Protocol)
3.1
3.2
3.3
3.4
3.5
3.6
MCDP の概要
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
対象とするアプリケーション
構成
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
MCDP Sender :
MCDP Router :
受信者
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
4. 実装
13
13
13
14
17
19
21
22
4.1 MCDP Sender の実装 : : : : : : : : : : :
4.1.1 MCDP Sender のメインルーチン
4.1.2 受信者と配送方法の管理 : : : : :
4.1.3 MCDP Redirect の入力 : : : : : :
4.1.4 送信処理 : : : : : : : : : : : : : :
iii
: : : : : : : : : : : : : :
: : : : : : : : : : : : : :
: : : : : : : : : : : : : :
: : : : : : : : : : : : : :
: : : : : : : : : : : : : :
22
22
24
26
26
4.1.5 ユーザインターフェイス : : : :
4.2 MCDP Router の実装 : : : : : : : : :
4.2.1 通信の計測 : : : : : : : : : : :
4.2.2 管理する状態 : : : : : : : : : :
4.2.3 MCDP Option 毎に行なう処理
4.2.4 一秒毎に行なう情報の更新操作
4.2.5 受信者数の把握 : : : : : : : : :
4.2.6 MCDP Redirect の送信 : : : : :
4.3 受信者の実装 : : : : : : : : : : : : : :
4.3.1 切り替え動作に対する検証検証
4.3.2 受信者アプリケーションの改変
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
44
5. 実験と考察
5.1 実験ネットワーク
5.2 実験結果 : : : : :
5.3 考察 : : : : : : :
28
32
32
33
33
36
36
36
39
39
42
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
44
47
50
6. まとめと今後の課題
51
謝辞
53
参考文献
54
iv
図目次
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
mrouted のトンネル技術 : : : : :
AMT のトンネル技術 : : : : : : :
MCDP Sender と MCDP Router :
動作概要
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
マルチキャストで配送が可能なコンテンツのユニキャスト配送
マルチキャストで配送可能なパケットに対するラベル付け
ルータでのラベルに注目した通信の計測
受信者情報と配送方法の管理
: : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : :
配送方法を管理する構造体
受信者の追加
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : :
MCDP Redirect : : : : : : : : :
MCDP Redirect パケットの入力
配送方法の変更
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
MCDP IP Option ヘッダのフォーマット
送信処理
: : : :
: : : : : : : : : : : : : : : : : : : :
MCDP Router の設置 : : : : : :
MCDP Sender のメインルーチン
受信者管理用の構造体
: :
: : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
MCDP Router のメインルーチン
（ S, G) 情報 : : : : : : : : : : : :
(S, G, Seq) 情報 : : : : : : : : : :
MCDP Option の入力処理 : : : :
一秒毎に行なう処理
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
(S, G)，(S, G, Seq) 情報の TTL を減算
マルチキャスト使用の決定
: : : : : : : : : : : : : : : : : : : : : :
有効期限が切れた情報を削除
受信者数の把握
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
MCDP Redirect の送信
: : : : : : : : : : : : : : : : : : : : : : : :
v
9
11
14
15
15
16
17
18
19
23
24
24
27
28
29
30
30
31
33
34
34
35
36
37
37
38
39
40
29
30
31
32
33
34
ユニキャストパケットの読み込み設定
マルチキャストパケットの受信設定
実験ネットワーク
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : :
カーネルパラメータの設定
: : : : : : : : : : : : : : : : : : : : : :
ユニキャストだけでの配送
: : : : : : : : : : : : : : : : : : : : : :
MCDP を用いた配送
: : : : : : : : : : : : : : : : : : : : : : : : :
41
41
45
47
48
49
表目次
1
2
3
マルチキャストルーティングプロトコル
各 OS での動作結果
: : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
受信者側ホストの設定
: : : : : : : : : : : : : : : : : : : : : : : :
1
6
42
46
1. はじめに
インターネットの普及に伴い，通信に利用される接続環境も発展が続いている．
接続環境の発展は，CATV，ADSL，FTTH といった接続サービスの大容量化と
低価格化を実現し ，現在ではユーザの家庭においても，数メガビット /秒といっ
た広帯域の接続環境を利用できるようになってきた．このような変化はブロード
バンド 化と呼ばれている．
ブロードバンド 化により受信者は，より容量の大きい動画や音声なども手軽に
扱えるようになった．動画や音声等の配送には，ストリーミング配送という技術が
用いられている．ストリーミング配送を用いることで従来まで必要であったデー
タのダウンロードに必要な手間と時間は必要とならない．このため，ユーザは手
軽に大容量のコンテンツを扱うことができる．このような背景によりストリーミ
ング配送は一般的となってきた．
しかし，ストリーミング配送においてコンテンツの送信者は，受信するユーザ
の増加に従い必要となる帯域と処理が増加するという問題が発生する．この問題
はインターネットでストリーミング配送に用いているプロトコルが 1 対 1 の通信
を行なうユニキャストを用いているためである．ユニキャストでは，複数の受信
者に同一の内容のデータを送信する場合でも受信者の数だけデータを複製して受
信者毎にデータを送らなければならない．また，より多くのユーザにストリーミ
ング配送を行なうためには送信者は帯域を受信者数に比例して増やす必要がある．
このため，送信者が帯域を増やすことができない場合にはストリーミングの品質
を下げたり，同時にサービスできるユーザ数に制限をすることになる．ユニキャ
ストの問題を解決する技術としてマルチキャストがある．マルチキャストを用い
ると，一つのデータ送信するだけで複数の受信者に配送できる．このため，マル
チキャストを用いるとユニキャストで問題となっていたような帯域と処理負荷の
問題はおこらない．
マルチキャストの研究は，Deering による最初の提案 [1] から 10 年以上が経っ
た現在も行なわれている．この間に IETF などを始めとした多くの研究機関で
は，マルチキャストを実現するためのマルチキャストプロトコルの提案が続けら
れてきた．マルチキャストプロトコルには複数の方式がある．現在インターネッ
2
トで最も一般的に用いられている方式は，PIM-SM と呼ばれるプロトコルである．
PIM-SM は主要なベンダーのルータでも実装が行なわれており，比較的容易に設
定することが可能となっている．しかし，PIM-SM はインターネット規模で動作
することは困難である．マルチキャストをインターネット規模で動作させるには，
ド メイン内で動作する PIM-SM と併せて，ド メイン間で動作させるインタード
メインのマルチキャストプロトコルを設定する必要がある．インタード メインマ
ルチキャストプロトコルにも，いくつかの方式が提案されているものの，解決さ
れていない問題がある．このためインターネット規模でのマルチキャストは現在
のところ実現されていない．インタード メインのマルチキャストプロトコルを動
作させずに，インターネット規模のマルチキャストを行う方法としてトンネル技
術を用いる方法がある．しかしながら，既存のプロトコルには実際に使用する上
で欠点がある．そこで，本研究では既存のプロトコルの欠点と解決するトンネル
技術の提案を行なう．この提案により，ド メイン間のマルチキャストプロトコル
を必要とせずに異なるド メインへの配送にマルチキャストを利用できる．送信者
は受信者までの経路に，マルチキャストの接続性が無い場合においても，受信者
のド メインがマルチキャストに対応している限り，そのド メインへの配送をマル
チキャストで行なうことが可能となる．
以下，本論文では次のように構成されている．第 2 章では本研究の対象である
マルチキャスト技術について述べる．第 3 章では，本論分で提案する手法を述べ
る．第 4 章では提案方式の実装を詳説し，第 5 章では実装を評価する．第 6 章で
は本提案方式に対する考察と今後の課題を述べ，第 7 章で結論を述べる．
3
2. マルチキャスト 通信技術
マルチキャストは，効率良く複数の受信者にデータを配送するための技術であ
る．インターネットで一般に用いられているユニキャストを使って複数の受信者
にパケットを送信する場合は，送信者は内容が同じパケットを受信者の数だけ複
製してから送信しなければならない．また，経路上のルータは内容が同じである
重複したパケットを一つずつ転送しなくてはならない．一方，マルチキャストを
用いた場合には，ネットワークと送信者はユニキャストの場合のような無駄な処
理と帯域が必要とならない．
マルチキャストプロトコルは，大きく分けてド メイン内のマルチキャストと実
現するイントラド メインマルチキャストと，ド メイン間のマルチキャストと行な
うイントラド メインマルチキャストの 2 つに分けられる．2.1節ではイントラド メ
インマルチキャストプロトコルの説明を行なう．2.2節ではインタード メインマル
チキャストプロトコルの説明を行う．
2.1
イント ラド メインマルチキャスト
イントラド メインマルチキャストは，受信者グループの管理と，配送木の構築
という２つの処理に分けることができる．以降ではそれぞれについて説明をする．
受信者グループの管理
受信者グループは，マルチキャストでデータでデータが配送される複数の受信
者の組である．受信者グループはグループアドレスによって識別される．グルー
プアドレスは，IPv4 のクラス D の範囲 224.0.0.0∼239.255.255.255 が用いられる．
送信者は，グループアドレスを宛先とするパケットを送信することで，受信者グ
ループにデータを送信することができる．
一方，受信者は受信を希望するマルチキャストアドレスを近隣のルータに連絡
する．そのアドレス宛のパケットを自分のネットワークに転送するようにマルチ
キャストルータに通知する必要がある．
マルチキャストの設定がされたルータ（以下，マルチキャストルータ）は，マルチ
キャストパケットを受信者に配送するために受信者がいるネットワークにどのマル
4
チキャストアドレス宛のパケットを転送すればよいのか知っておく必要がある．こ
の目的のために使用がされるのが Internet Group Management Protocol(IGMP)[2][3][4]
である．IGMP は , 同一ネットワーク上のマルチキャストルータと受信者との間
で受信者グループの管理を行なうための制御メッセージを定めている．IGMP で
は，以下の 2 つの制御メッセージを用いて，マルチキャストルータと受信者の間
で情報の交換を行なう．
IGMP query メッセージ
あるマルチキャストグループに参加している受信者がネットワーク上に存
在するかど うかを問い合わせるためのメッセージ
IGMP report メッセージ
あるマルチキャストグループの受信を希望する受信者がマルチキャストルー
タに対して送信するメッセージ
これらの制御メッセージを定期的に交換することによって, マルチキャストルー
タはローカルネットワークにグループアドレス宛のパケットを配送すればよいか
を把握することができる．
マルチキャスト 配送木の構築
マルチキャストルータは，マルチキャストパケットを複数の受信者まで配送する
ための経路を決定する．この経路は，ループが発生しない木構造にしなければな
らない．仮にループが発生した場合には，大容量のトラフィックがネットワークを
占有するなどの問題が発生し，ネットワークに深刻な被害を与える可能性がある
からである．木構造に配送経路を構築するためには，
「 Shortest Path Tree(SPT) 」
や「 Shared Distribution Tree 」などのアルゴ リズムが用いられる．
マルチキャストでの配送に用いられる経路のことを特にマルチキャスト配送木
と呼び，その構築に用いるプロトコルをマルチキャストルーティングプロトコル
と呼ぶ．マルチキャスト配送木は，ネットワーク内のどの受信者がどのマルチキャ
ストグループに参加しているのかという情報に基づいて構築される．代表的なマ
ルチキャストルーティングプロトコルとしては DVMRP[5]，MOSPF，CBT[6]，
5
表 1 マルチキャストルーティングプロトコル
Protocol
Type
受信者密度 Algorithm
DVMRP Source-based
MOSPF Source-based
CBT
Core-based
PIM-DM Source-based
PIM-SM Core-based
密
疎
疎
密
疎
RPM
Dijkstra
SPT
SPT
SPT
PIM-DM[7]，PIM-SM[8] がある．これらのプロトコルは，表 1に示すようにマル
チキャスト配送木の構築のアルゴ リズムや，対象とする受信者の密度による動作
の違いや，配送木の構築の方法の違いにより分類できる．
2.1.1 PIM-SM (Protocol Independence Multicast Protocol - Sparce
Mode)
PIM-SM は，ド メイン内で動作するマルチキャストプロトコルとして現在最も
一般的に用いられている．
PIM-SM は，Shortest Path Tree を用いて配送木を構築する．PIM-SM では，配
送木の頂点に RP(Rendezvous Point) と呼ばれる特別のルータを用いる．PIM-SM
は一つのグループアドレス毎に一つの RP を決定する．複数のグループアドレス
が，同一の RP を指定することも可能である．
RP はマルチキャスト配送木の頂点となるマルチキャストルータである．PIMSM では，マルチキャストルータは送信者が配送したマルチキャストパケットを，
グループアドレスから決定される RP 宛に配送する．RP では，IGMP により把
握したグループ情報をもとに全ての受信者までのマルチキャストルータに配送木
を構築しておく．送信されたマルチキャストパケットは，経由するマルチキャス
トルータが RP まで転送し，RP から受信者のいるネットワークまで転送される．
PIM-SM では，グループアドレスと RP の関係を全てのルータで一意に設定す
る必要がある．この設定が正しく行なわれていないと，PIM-SM は正常に動作し
6
ない．
2.1.2 イント ラド メインマルチキャスト の現状
現在では，IGMP や PIM-SM が一般的なベンダーのルータに実装されている．
このため，ネットワーク管理者はこれらをルータで有効にすることで，マルチキャ
ストを容易に動作させられる．ISP の事例として Sprint や UUNet などの ISP が
1999 年の時点でマルチキャストをサポートしている．また，日本では IIJ などが
サポートを行っている．
2.2
インタード メインマルチキャスト
2.1.2節で述べたように，ド メイン内でマルチキャストを動作させることは比較
的容易になってきた．しかし，ド メイン内のマルチキャストルーティングプロト
コルだけでは，インターネット規模のマルチキャストは実現できない．例えば，
PIM-SM の場合においては，すべてのルータがグループに対する RP の対応表を
正しく管理するためのプロトコル等が問題である．このために，マルチキャスト
ネットワークを接続するインタード メインのマルチキャストルーティングプロト
コルが提案されている．インタード メインマルチキャストルーティングプロトコ
ルによって，マルチキャストをサポートするネットワークを接続することでイン
ターネット規模のマルチキャストを実現できる．
2.2.1 MSDP(Multicast Source Discovery Protocol
現在のインターネットで最も一般的に利用されているインタード メインプロト
コルは MSDP(Multicast Source Discovery Protocol) である．MSDP は，PIM-SM
と併せて利用する．MSDP は PIM-SM が動作するマルチキャストネットワーク
内の RP 間を TCP のコネクションを用いてメッシュ上に接続する．TCP のコネ
クションではグループアドレスと RP の対応や，送信者の情報などが交換される．
MSDP を用いることで，PIM-SM をサポートするネットワークは相互に接続して
マルチキャストができるようになる．
7
MSDP は複数の RP 間で TCP のコネクションをメッシュ上に張る必要があり，
このコネクション上には，全ての RP からの情報が溢れることになる．このため
MSDP は，スケラビリィティーの問題がある [9]
2.2.2 インタード メインマルチキャスト の問題
ISP でのマルチキャストの利用が実用段階になってきたのに対して，インター
ネット規模でのマルチキャストはまだ実用段階になっていない．これは，インター
ド メインマルチキャストルーティングプロトコルはまだ開発段階であり，多くの
解決しなければならない問題が残っているためである．インタード メインのマル
チキャストプロトコルの問題点は，Christian Huitema の著書「 Internet Routing 」
[10] において 4 つの点が指摘されている．
アドレス割り当て
ド メイン分割
アクセス制御
セキュリティー
これらの問題の解決としては，例えばアドレス問題の解決として PIM-SSM[11]
という方式の提案などによって解決されようとしている．また，アクセス制御な
どについても上位層での暗号化処理などによって解決が図られようとしている．
しかしながら，インターネット規模で動作するマルチキャストルーティングプロ
トコルの開発にはまだ多くの時間が必要と考えられる．
2.3
トンネル技術
2.2節で述べたように，インタード メインのマルチキャストプロトコルが，イン
ターネット規模で動作するには，まだ多くの時間が必要であると考えられる．し
かしながら，インタード メインマルチキャストプロトコルを動作させることなく
インターネット規模のマルチキャストを行なう方法としてトンネル技術をもちい
る方法がある．トンネル技術を用いることで，インタード メインマルチキャスト
8
ルーティングプロトコルが動作していないマルチキャストネットワーク間を接続
することができ，マルチキャストを行うことができる．この節ではマルチキャス
トと併せて利用するトンネリング技術を説明する．
2.3.1 mrouted のトンネル技術
概要
mrouted[12] は，マルチキャストルーティングプロトコルを実装しているプロ
グラムの名称である．mrouted はトンネル技術がサポートしている．mrouted の
トンネル技術は，二つのマルチキャストルータがユニキャストルータを経由して
接続されている場合に，マルチキャストパケットをカプセル化しデータを送受信
することにより 2 つのマルチキャストネットワークを接続する．マルチキャスト
ルータはマルチキャストトンネルの終点アドレスに送信すべきマルチキャストパ
ケットを受信すると，もう一方のマルチキャストルータを終点アドレスとするカ
プセル化を施し，ユニキャストパケットとして送信する．このパケットを受信し
たマルチキャストルータはカプセル化されたパケットからマルチキャストパケッ
トを取り出しマルチキャスト中継する．トンネルの両端となる二つのマルチキャ
ストルータを接続しているネットワークはあたかも一つのマルチキャストネット
ワークとして動作することができる (図 1 ）．
3
C
o
m
3
図 1 mrouted のトンネル技術
9
C
m
o
問題点
mrouted のトンネル技術は，通信を行なう前にネットワークの管理者によって
設定行なう必要がある．このため任意の送信者および受信者が通信を行いたい相
手との間にマルチキャストの接続性を確保するには，トンネルを多数のド メイン
の間で設定しなければならない．mrouted のトンネル技術は，管理上のコストが
多くなることが問題といえる．
2.3.2 Automatic Tunnering Protocol(AMT)
概要
Automatic Tunnering Protocol(AMT)[13] はマルチキャストネットワークに接
続していないホストが，ユニキャストの接続性を利用してマルチキャストネット
ワークに接続しマルチキャストパケットを受信できるようにするトンネル技術で
ある．
ホストは自分の属するネットワークでマルチキャストルーティングプロトコル
が動作していない場合，マルチキャストパケットの送受信ができない．AMT は
このような状況でホストが，マルチキャストをサポートするネットワークに設置
された AMT をサポートするルータとの相互動作によりトンネルの設定を行う．
ホストは，AMT に対応した multikit と呼ばれるアプリケーションを利用する
ことで AMT を利用できる．マルチキャストアプリケーションは，起動を multikit
経由で行なうことで仮想的にマルチキャストネットワークに接続されたように動
作できる．
問題点
AMT は，ホストが通信を行う前に動的に設定を行うことで，mrouted で問題
となる管理上のコストは大きくならない．AMT を利用した場合，個々のホスト
はマルチキャストネットワークに接続することができる．しかし，あるコンテン
ツの送信者とコンテンツの受信者がマルチキャストのネットワークにそれぞれト
ンネル技術を用いて接続した場合には，マルチキャストネットワーク上の接続性
10
3
3
C
o
C
o
m
m
図 2 AMT のトンネル技術
は保証されない．また，データの送信者から見て受信者がマルチキャストパケッ
トを受信できる状態にあるかど うかの判定ができない．これらの点が AMT の問
題となる．このため，AMT を用いてマルチキャストネットワークに接続を行う
送信者は，受信者までのマルチキャスト経路がある保証がないため，到着性がよ
り高いユニキャストの利用を続けることになる．
2.4
研究の目的
前節では，既存のトンネル技術の問題点を指摘した．本論分では，既存のトン
ネル技術が持つ問題を克服するために次のような特徴をもったもつトンネル技術
の提案を行う．
動的な接続
AMT が実現するようなホストが動的にマルチキャストネットワークに接続
する
受信者にデータが届くことの保証
送信者が，受信者との間にマルチキャストネットワークの接続性があるこ
とを確認できる機構
ユニキャストからマルチキャストへの配送の切り替え
11
受信者のネットワークがマルチキャストをサポートしていない場合にユニ
キャストで配送を行い，マルチキャストで配送ができる場合にマルチキャ
ストで配送を行う機構．
以上の提案によって，インタード メインのマルチキャストプロトコルが動作し
ていない場合においても，インターネット規模でのマルチキャストがより効果的
に行うことができると考えられる．また，送信者はマルチキャストの効果を受信
者のネットワークの対応に合わせて得ることができる．
以降の章では，この目的を実現するための提案方式の説明を行う．
12
3. MCDP(Multicast Capability Discovery Protocol)
3.1
MCDP
の概要
MCDP は，送信者とマルチキャストネットワークを接続する技術である MCDP
は，インタード メインマルチキャストが動作していないド メイン間においてマル
チキャストを行うことができる．MCDP は，2.4で目的とした特徴を実現するこ
とを目的とする．
MCDP はユニキャストパケットに特別なラベルを付加して配送を行ない，そ
のラベルによって配送経路上のマルチキャストネットワークを探す．また，この
ラベルを検出したマルチキャストルータは，自分のネットワークがマルチキャス
トをサポートしている場合に，送信者に直接メッセージを送信し，送信者が行な
う以降の通信をマルチキャストに切り替えさせられる．この後，送信者とマルチ
キャストネットワークはトンネル技術により接続する．送信者はトンネル技術に
より接続されたネットワーク内の受信者に対して，それ以降の通信をマルチキャ
ストできる．
3.2
対象とするアプリケーション
MCDP は，動画や音声のストリーミング配送において利用することを想定し
ている．MCDP の上位層から見たその特性はユニキャストではなく，マルチキャ
ストとなる．つまり，MCDP は初期状態では受信者の数だけユニキャストを使用
してデータ配送を行なうものの，受信者毎の通信の品質管理は行なえない．これ
は，MCDP で行なっている通信がマルチキャストに切り替わる可能性があるため
である．信頼性のある通信を行なう場合には，リライアブルマルチキャスト [14]
等の技術を併せて用いる必要がある．
13
3.3
構成
MCDP は，送信者と受信者，そしてマルチキャストネットワークに設置された
ルータの動作により構成される．この関係は図 3に示すようになる．本論分の以
降の説明では，提案方式に従って動作する送信者を MCDP Sender，提案方式に
従って動作するマルチキャストネットワークに設置されたルータを MCDP Router
と呼ぶ．提案方式の動作概要は図 4に示す４つの動作で単純化できる．本節では
図 4に示す動作を簡単に説明する．
図 3 MCDP Sender と MCDP Router
1. ユニキャストを用いたリアルタイムストリーミング配信
14
図 4 動作概要
C
Server
3
C
2
C
1
B
3
Router
B
2
B
A
1
Client1
A
2
Client2
A
3
Client3
1
Router
Internet
図 5 マルチキャストで配送が可能なコンテンツのユニキャスト配送
15
送信者が , マルチキャストでの配送が可能なデータをユニキャストで配信を
行なっている図 5に示すような状態を提案方式の対象とする．図 5は，3 人
の受信者に対して送信者が A，B，C，という順序で同じ内容をもつパケッ
トを送信している場面である．提案方式は，送信者は配送を行なうユニキャ
ストパケットに，図 6に示すように新しく定義する IP Option を利用し通信
にラベルを付けを行なう．
IP Option
IP Header
(G,Seq N)
Payload
図 6 マルチキャストで配送可能なパケットに対するラベル付け
2. ラベルに注目した通信の計測
ネットワーク管理者は，任意のルータにおいて送信者が付加したラベルを
計測できる．この様子を図 7に示す．この計測により，自分のネットワーク
に流れてくるパケットが内容が重複しているパケットであることがわかる．
また，このパケットを送信している送信者が配送しているコンテンツがマ
ルチキャストで配送できるものであることも分かる．
3. マルチキャストネットワークから送信者への応答
ネットワークはラベルを計測することによって，特定の送信者が配送を行
なっている受信者の数を把握することが出来る．マルチキャストネットワー
クはこの受信者数の情報をもとにして，マルチキャストを使用するかど う
か判定することができる．マルチキャストを利用した方が効果的であると
判断した場合に，配送が可能な受信者の情報と併せて送信者にマルチキャ
ストネットワークの情報を知らせる．この動作により，2.4節で目的とした
2 点目の実現が可能となる．
4. ユニキャスト通信からマルチキャスト通信への配送方法の切り替え
16
G,Seq1
G,Seq2
G,Seq2
G,Seq1
Router
Up Stream
Down Stream
図 7 ルータでのラベルに注目した通信の計測
送信者は，ネットワークから応答を受けて任意の受信者に対する配送を，指
定された MCDP router への配送で置き換えることができる．MCDP Sender
は，応答のあった MCDP Router に対してトンネル技術を用いてパケット
の送信を行い，これまでユニキャストで配送していた複数人の受信者への
配送を，ネットワークで有効になっているマルチキャスト方式によって行
なうことができる．
以降の節では，提案方式の動作の説明を MCDP Sender，MCDP Router，およ
び受信者について行う．
3.4
MCDP Sender
MCDP Sender は，提案方式に従って動作するリアルタイムストリーミングの
送信者である．MCDP Sender はユニキャストでのコンテンツ配信において，本
論文が提案するラベル付けを行い，その通信内容がマルチキャストで配送可能で
あることをネットワークに広告する．さらに，特定受信者に対するユニキャスト
配送を，MCDP Router からの応答によりマルチキャスト配送に切り替え，配送
17
図 8 受信者情報と配送方法の管理
に必要な帯域の削減と送信負荷の低減を図ることができる．
MCDP Sender の主な機能を以降で説明する．
受信者及び配送方法の管理
MCDP Sender は，コンテンツの配送相手となる受信者の情報と，受信者への
データ送信に使用する配送方法の情報を管理する．この情報は図 8に示すように
保持される．図の受信者リストには，受信者の IP アドレスが格納される．一方，
配送方法リストにはその受信者へデータを配送する際の，パケットの宛先アドレ
スとして使用される IP アドレスが格納されている．
MCDP Sender は，MCDP Router からのメッセージを受けることで，管理して
いる配送方法を変更する．以降では MCDP Router から送信されるこのメッセー
ジを MCDP Redirect と呼ぶ．この MCDP Redirect には次に示す情報が含まれ
ている．
配送方法を変更する受信者
新しい配送先のアドレス
MCDP Redirect メッセージを受信した MCDP Sender は，指定された受信者
に対する配送方法を，新しい配送先アドレスによって置き換える．この置き換え
によって，複数の受信者に対する配送を，単一の配送方法に集約することが可能
となる．
18
配送処理
MCDP Sender は，配送するコンテンツを，MTU 値に分割し，各データを配
送方式が管理する宛先毎にそれぞれ複製し MCDP Option を付加したパケットを
生成した上で送信する．
3.5
MCDP Router
マルチキャストに対応するネットワークは，インターネットとの接続点におい
て，MCDP Router を設置できる．MCDP Router はマルチキャストネットワーク
に中継される重複したパケットを MCDP Option に注目することで検出できる．
また，MCDP Sender に対して，ネットワークに設定されてあるマルチキャスト
プロトコルを使用させるように MCDP Redirect を送信することができる．
MCDP Router の主な動作を以降で説明する．
MCDP Router の設置
Internet
Network
Module
Router
Listener
Listener
Listener
Listener
Listener
Router
Listener
MulticastNetwork
図 9 MCDP Router の設置
19
MCDP Router は，図 9に示すように，マルチキャストが有効になっているネッ
トワークの境界にあるルータに設置する．設置するルータが，ソフトウェアルー
タの場合には MCDP Router を同一ルータ上で動作させる．また，設置するルー
タがハード ウェアルータの場合にはポートミラーリング機能によって，ルータを
通過するパケットを監視できるようにすることで MCDP Router を動作させる．
MCDP Router は，設置されたネットワークの下流において動作しているマル
チキャストプロトコルとそのプロトコルで配送できる受信者の範囲，また下流ネッ
トワークに位置する受信者の数などを把握しているものとする．
MCDP Router を多段に設置することは，現在の仕様では考慮していない．現
在の仕様では，他のネットワークとマルチキャスト上の接続がないネットワーク
に設置することを考えている．
MCDP Option の計測
もっとも単純な MCDP Router の動作は，MCDP Option を観測した直後に
MCDP Sender に MCDP Redirect を送信することである．さらに，MCDP Router
は MCDP Option に注目することで通信が対象とする受信者の数や，通信の帯域
量等の情報を得ることもできる．以降の説明では，この動作を主に取り上げ説明
をおこなう．
MCDP Router は，MCDP Option が付加されたパケットを送信者のアドレス
S と，MCDP GroupAddress に設定された識別子 G によって独立した通信として
識別できる．MCDP Router は，この S と G の組（以下では (S,G) と略する) で
識別される通信毎に，累積帯域量や通信の持続時間，通信が占有する帯域量の把
握が可能となる．さらに，MCDP Router は，MCDP Option に付加されたシー
ケンス番号 Seq に注目し，同一の Seq の出現数を数えることで，計測を行なって
いるルータの下流の位置する受信者の数についても把握することができる．
この計測により，MCDP Router は一定人数以上の受信者への配送が確認され
た場合においてのみ，MCDP Sender に MCDP Redirect を送信することもでき
る．このことは，1 人に対するマルチキャスト配送など ，マルチキャストを用い
ることが明らかに適さないストリーミングをマルチキャストにさせないといった
利用ができる．MCDP Redirect を送信する条件は，ネットワークの管理者によっ
20
て任意に設定できる．
MCDP Redirect の送信
MCDP Router は，マルチキャストで配送を行なうと決定した通信に対して，
MCDP Sender がユニキャストを使用して配送を行なった場合，この配送先の受信
者の IP アドレスと，MCDP Router の IP アドレスを MCDP Reidrecct で MCDP
Sender に送信する．
パケット の中継処理
マルチキャストで配送を決めた通信を送信者に伝えると，MCDP Router は
MCDP Option が付加された自分宛のパケットを MCDP Sender から受信する．
MCDP Router は MCDP Option に含まれた Group Address にパケットの宛先を
書き換えて内部ネットワークに中継をおこない，受信者にマルチキャストパケッ
トを送信する．
3.6
受信者
受信者は，配送方法がグループマルチキャストに変更した場合に，送信者から
参加するマルチキャストグループアドレスを指定される．受信者は，配送方式が
グループマルチキャストに切り替わった後でも，データの受信を続けるために，
指定されたグループアドレスに参加する必要がある．受信者に必要な処理につい
ては， 4.3.2節で詳しく説明を行う．
21
4. 実装
本章では，提案方式の実装について説明を行なう．まず始めに，MCDP Sender
と MCDP Router の実装について述べる．次に，受信者に対して行なった検証実
験と，受信者プログラムの構成についても述べる．
4.1
MCDP Sender
の実装
本節では，MCDP Sender の実装の説明をおこなう．説明は次に示す３つの機
能毎に行なう．
受信者と配送方法の管理
受信者の IP アドレスの管理
管理している受信者の追加や削除といった機能
MCDP Redirect による配送方法の変更
受信者にデータを送信する方法の管理
ネットワークから配送方法変更に対する処理
パケット配送処理
ストリーミングデータを生成するホストからデータを受け取り，管理して
いる受信者に向けて，データの複製と転送を行なう処理．
4.1.1 MCDP Sender のメインルーチン
MCDP Sender のメインルーチンの部分を図 10に示す．
本論文の実装では，ソケットからの入力処理に select() 関数を利用している．
図 10では，select() 関数を隠蔽するライブラリを用いて，UDP のストリーミング
データの入力，ユーザインターフェイスからの入力，MCDP Redirect の入力を
処理している．MCDP Redirect の入力には BPF を用いた．
22
void _loop(void)
{
/* select() 関数の処理を隠蔽するライブラリを使用 */
selecter
= selecter_new();
/* 処理対象となる入力と，入力に対して実行する関数の指定 */
/* スプリットする UDP ストリーミングの入力 */
selecter_add_w_name(selecter, (void *)mod_usock,
_read_and_sendpacket,
"UDP splitter");
/* ユーザインターフェイスの入力 */
selecter_add_w_name(selecter, (void *)mod_ui,
_mod_ui_input,
"User Interface");
/* MCDP Redirect の入力 */
selecter_add_w_name(selecter, (void *)mod_psock,
_promisc_input,
"MCDP redirect input");
promisc_socket_set_read_and_operate(mod_psock, _redirect_packet);
/* select() 関数を使用するループ */
selecter_loop(selecter);
}
図 10 MCDP Sender のメインルーチン
23
4.1.2 受信者と配送方法の管理
受信者の管理を行なうために，実装では図 11に示す構造体を定義した．
typedef struct _Listener {
struct _Listener *prev;
struct _Listener *next;
int ip;
Way *way;
int last_seq;
int listen_port;
int write_packet;
int write_byte;
} Listener;
/*
/*
/*
/*
/*
前の受信者へのポインタ */
後ろの受信者へのポインタ */
受信者の IP アドレス */
配送方法が格納された構造体へのポインタ */
最後に送信したシーケンス番号 */
/* 受信者のポート番号 (未使用) */
/* 累積書き込みパケット数 */
/* 累積書き込みバイト数 */
図 11 受信者管理用の構造体
構造体のそれぞれの値の説明を次に示す．
各受信者の情報は，リンクリストをもちいて管理されている．
配送方法を管理するために，実装では次のような構造体を定義した．
typedef
int
int
int
} Way;
struct _Way{
method; /* 配送方法の種類 */
dest; /* 配送先の IP アドレス */
ref; /* この配送方法の参照数 */
図 12 配送方法を管理する構造体
構造体のメンバ変数はそれぞれ次のような意味を持つ．
method
配送方法の種類を示す．とりうる値は次の３通りである．
24
{ ユニキャスト配送
{ マルチキャスト配送
{ トンネルによるマルチキャスト配送
dest
実際のパケットを送る配送先の IP アドレスを示す．
配送方法の種類がユニキャスト配送の場合，配送先の IP アドレスは受信者
の IP アドレスと一致する．
配送方式の種類がマルチキャスト配送の場合には，MCDP グループアドレ
スに格納するマルチキャストアドレスとなる．
配送方法の種類がトンネルによるマルチキャスト配送の場合には，マルチキャ
ストネットワークで動作している提案手法が実装を行なう MCDP Router
が動作しているホストの IP アドレスとなる．
ref
この配送方式を参照している受信者の数を表す．つまり，この値が２以上
の場合になっている場合，マルチキャストが行なわれていることになる．
一方，この値が０になった場合，この配送方法が管理している値はどの受
信者に対する配送にも利用されないので削除される．
新しい受信者の追加処理を行なう関数を図 13に示す．関数の入力の入力は次に
示す３つの変数である．
SS Stack *sst
一つのコンテンツごとに管理される情報を含む構造体．受信者情報は，SS Stack
内でリンクリストによって保持されている．また，高速な受信者情報の参
照のためにハッシュテーブルを用いても受信者は管理されている．
ip
受信者の IP アドレス
25
port
受信者のポート番号を指定する．受信者毎に UDP ポート番号を使い分ける
処理は現在のところ行なっていないため，特に意味はない．
将来的には XCAST 方式などで利用される可能性がある．
4.1.3 MCDP Redirect の入力
MCDP Sender は，MCDP Redirect を受信することで受信者に対する配送方法
を変更する．
実装では，MCDP Redirect パケットを，図 14に示すような IP Option として
定義した．MCDP Redirect パケットは UDP パケットであるが，データには何も
含まれていない．
この応答パケットは，データを配送している受信者がマルチキャストネットワー
クに位置している場合に MCDP Sender に送られる．このパケットを受けること
で，MCDP Sender は指定された受信者への配送を，指定された IP アドレスへの
配送によって代替することができる．
このパケットを受信することで，MCDP Sender は，管理している受信者情報
とそれが参照している配送方法の関係を更新する．
応答パケットの情報から，新しい配送方法情報の追加，もしくは既に存在して
いる配送方法の参照カウントの増加を行い，指定された受信者の配送方法が変更
される．一方，その受信者が以前参照していた配送方法の参照カウントが１減算
され，その結果どの受信者からも参照されなくなった (参照カウントが 0 になっ
た ) 配送方法は削除される．
4.1.4 送信処理
今回は，MCDP Sender は，ストリーミングデータの生成プログラム（ 移行で
はストリーミングサーバ）と別のホスト上で動作可能となるように実装した．
MCDP Sender は，ストリーミングサーバから受信したパケットを，管理して
いる配送方法情報を利用してパケットの送信を行なう．送信するパケットは，ス
26
int ss_rctl_add_receiver(SS_Stack *sst, int ip, int port)
{
Listener *new;
Way *w;
struct timeval tv;
/* 重複した受信者の登録防止 */
if (hash(&sst->ip_hash, ip)){
fprintf(stderr, "add_receiver(): Client IP already exist
ip2str2(ip));
return -1;
}
%s\n",
/* 受信者管理用のメモリ確保 */
new = (Listener *)malloc(sizeof(Listener));
if (new == NULL) {
fprintf(stderr, "add_receiver: can't alloc memory\n");
exit(-1);
}
memset(new, 0, sizeof(Listener));
/* 受信者のアドレスの設定 */
new->ip = ip;
/* ユニキャストで配送 */
w = _get_way(sst, MCDP_UNICAST, ip);
new->way = w;
/* 配送方法の参照カウントを１加算 */
_inc_way_ref(new->way);
/* 受信者管理用のリンクリストに追加 */
ADD_LINK_LIST(sst->last_listener, new);
/* 受信者管理用のハッシュテーブルに追加 */
add_hash(&sst->ip_hash, (char *)new);
/* 送受信者数の加算 */
sst->listener_num++;
return 1;
}
図 13 受信者の追加
27
IP Option
ID
IP Option
Length
unused
Listener IP
Distination IP
図 14 MCDP Redirect
トリーミングサーバから受信したパケットの複製を行い IP Header の送り元アド
レスを MCDP Sender の IP アドレスに変更し，宛先アドレスを管理されている
配送方法ごとの IP アドレスを使用する．
また，ここで配送するパケットには図 17に示す MCDP オプションを，IP Option
に挿入する．MCDP オプションは，大きさが 8byte の IP オプションである．ま
た，IP Option ID として現在利用されていない 153 を一時的に使用している．
MCDP オプション内のグループアドレスには，この配送がグループマルチキャ
ストに切り替わった場合にはパケットの宛先に使用されるグループマルチキャス
トアドレスが格納される．また，MCDP シーケンス番号にはストリーミングサー
バからパケットを受信する度に増加する値を格納する．ストリーミングサーバか
ら受け取ったパケットに対して，同じ MCDP シーケンス番号をもったパケット
が，管理されている配送方法の数だけ複製されることになる．
配送処理を図 4.1.4に示す．
4.1.5 ユーザインターフェイス
新しい受信者の追加や削除などの受信者の管理には，異なる上位層プロトコル
と組み合わせて使用することを，本実装では想定している．上位層プロトコルに
は，Web インターフェイスを用いたものや，SIP(Session Initiation Protocol)[15]
などが考えられる．
Web を利用する場合には，受信者が最初に送信者の用意した Web ページにア
28
/* リダ イレクトパケットの入力 */
static int _redirect_packet(char *ptr, int len)
{
struct ip *iph = (struct ip *)ptr;
Mredirect *mr;
u_int32_t router_ip;
u_int32_t client_ip;
if( iph->ip_hl != (sizeof(struct ip) + sizeof(Mredirect)) >> 2) {
return(0);
}
mr = (Mredirect *)(iph + 1);
/* MCDP Option であることの確認 (IP Option ID が 153 であることの確認) */
if (mr->ipopt_id != IP_MOPT_VALUE
|| mr->ipopt_len != sizeof(Mredirect))
{
return(0);
}
router_ip = ntohl(mr->redirect_ip);
client_ip = ntohl(mr->client_ip);
/* リダ イレクト先のルータ */
/* 配送方法を変更する受信者 */
/* 指定された受信者への配送を，
トンネルを利用してルータまでの配送に切り替え */
ss_rctl_change_trans_way(mod_sst, client_ip, MCDP_TUNNEL, router_ip);
return(1);
}
図 15 MCDP Redirect パケットの入力
29
/* 配送方法の変更 */
int ss_rctl_change_trans_way(SS_Stack *sst, int ip, int m, int d)
{
Listener *li;
Way *w;
/* 指定の受信者情報の検索 */
li = (Listener *)hash(&sst->ip_hash, ip);
if(li == NULL) {
fprintf(stderr, "Listener (%s) is not exist\n", ip2str2(ip));
return -1;
}
/* 受信者が参照している配送方法の参照カウントの減算．
参照カウントが０になった場合は削除 */
_remove_way(sst, li->way);
/* 既存の配送方法を検索 (無ければ新規作成) */
w = _get_way(sst, m, d);
/* 配送方法の参照カウントの加算 */
_inc_way_ref(w);
/* 受信者情報に格納 */
li->way = w;
return 0;
}
図 16 配送方法の変更
IP Option
ID
IP Option
Length
Sequence Number
Group Address
図 17 MCDP IP Option ヘッダのフォーマット
30
int ss_rctl_sendpacket(SS_Stack *sst, char *buf, int buf_len, int option)
{
IPinfo ip;
Moption mopt;
LinkList *_way
Listener *li =
int send_len =
int send_num =
= NULL;
NULL;
0;
0;
/* 全ての配送方法に対して */
for(_way = sst->top_way->next; _way; _way = _way->next) {
/* IP Header の設定 */
ip.sip
= sst->src_ip;
ip.dip
= ((Way *)(_way->ptr))->dest;
ip.sport = sst->src_port;
ip.dport = sst->dest_port;
/* MCDP Option の設定 */
mopt.ipopt_id = IP_MOPT_VALUE;
mopt.ipopt_len = sizeof(Moption);
mopt.group
=
sst->multi_ip;
mopt.sequence
= 0x0000FFFF & sst->seq;
/* RawSocket を使用したパケット送信 */
send_len = ss_tctl_sendpacket(&ip, &mopt, buf, buf_len, option);
/* 統計情報の加算 */
ADD_STAT(sst->stat_write_len, send_len);
send_num++;
}
/* 受信者のシーケンス番号の更新 */
for(li = sst->top_listener->next; li != NULL; li = li->next) {
li->last_seq = sst->seq;
li->write_packet++;
li->write_byte+=send_len;
}
/* シーケンス番号の加算 */
sst->seq++;
return send_num;
}
図 18 送信処理
31
クセスを行い．送信者が配送するコンテンツの情報を得る．コンテンツを受信す
るための情報には，送信者が送信する UDP のポート番号，マルチキャストでの
配送の場合にはマルチキャストアドレスなどが必要となる．
今回の実装では，Web や SIP のインターフェイスは用意していない．代わりに，
受信者の管理のためのコマンド ライン用のユーザインターフェイスを用意した．
このインターフェイスは，次の２つのコマンドにより受信者の追加と，削除を
行なう．
add ip address
delete ip address
また，次のコマンドにより受信者の一覧とその配送先を確認することができる．
list
受信者情報の一覧表示
cast
配送方法の一覧表示
4.2
MCDP Router
の実装
本節では，MCDP Router の実装について説明する．
MCDP Router の主な機能は，計測による通信の状態把握と，マルチキャスト
プロトコルの使用選択，さらに内部ネットワークでの配送をマルチキャストに切
り替えた後の MCDP Sender 間のパケットの転送と，受信者に対する配送処理で
ある．
先ず始めに，MCDP Router のメインルーチン部分を図 19に示す．
4.2.1 通信の計測
ルータ上で MCDP Router は，ルータを流れるパケットの MCDP オプションに
注目することで，特定の送信者が配送を行っている受信者の数や，帯域使用量を把
32
void _loop(void)
{
selecter = selecter_new();
/* IP Option を計測する関数 */
selecter_add(selecter, (void *)mod_psock, _promisc_input);
/* １秒毎に呼ばれる情報更新関数 */
selecter_set_timeout(selecter, _periodic_update, 0, TIMEOUT_CHECK_SPAN);
/* Start Time */
time_start = time_last_update = time_now();
/* Main loop */
selecter_loop(selecter);
}
図 19 MCDP Router のメインルーチン
握することができる．これらの情報の把握には，送信者の IP アドレスと，MCDP
オプションのグループアドレスおよび，シーケンス番号に注目することで実現で
きる．以降では，ストリーミング通信の把握を行なうために，MCDP Router が
扱う情報の説明と，MCDP Router が個々のパケット毎に行なう処理の説明する．
4.2.2 管理する状態
MCDP Router は，送信者の通信ごとに図 20に示す構造体を管理する．
また，MCDP Option のシーケンス番号毎に図 21に示す情報を保持する．
4.2.3 MCDP Option 毎に行なう処理
続いて，MCDP Option の入力に対して行なう処理を図 22示す．入力された
MCDP Option によって（ S, G ）情報の更新と，(S, G, Seq) 情報の更新が行わ
れる．
33
typedef struct _SG_STATE {
struct _SG_STATE *next;
struct _SG_STATE *prev;
int source;
int group;
/* リンクリスト操作用 */
/* 送信者の IP アドレス */
/* 送信者内の通信識別子
*/
int num; /* 転送パケット数 (per 秒) */
*/
int total_num;
/* 累積転送パケット数
int byte;
int total_byte;
/* 転送バイト数 (per 秒) */
/* 累積転送バイト数
*/
int ttl;
/* この構造体情報の有効時間 */
int listener_num;
int do_multicast;
/* 受信者の数 */
/* 使用するマルチキャスト
SEQ_State seq;
/* (S,G,Seq) 情報へのポインタ */
SS_Stack *sst;
/* SIM の動作で使用した受信者
リストへのポインタ */
*/
} SG_State;
図 20 （ S, G) 情報
typedef struct _SEQ_State {
struct _SEQ_State *next;
int sequence;
int start;
int last;
/* シーケンス番号 */
/* シーケンス番号を最初に計測した時間 */
/* シーケンス番号を最後に観測した時間 */
int num; /* 累積パケット数 (受信者数) */
int byte; /* 累積バイト数 */
int ttl;
/* 構造体情報の有効期限 */
} SEQ_State;
図 21 (S, G, Seq) 情報
34
void mm_sg_input(int s, int g, int seq, int cip, int dest_port,
int len, int sec, int usec)
{
int res;
SG_State *found_sg;
SEQ_State *sg_seq;
/* (S, G) 情報の更新 */
found_sg = _sg_search(s, g);
if (found_sg == NULL)
found_sg = _sg_new(s, g);
found_sg->ttl = SG_INITIAL_TTL;
found_sg->num++;
found_sg->byte += len;
/* (S, G, Seq) 情報の更新 */
sg_seq = _seq_search(found_sg, seq);
if (sg_seq == NULL) {
fprintf(stderr, "_seq_search(): Can't find\n");
}
sg_seq->ttl = SEQ_INITIAL_TTL; /* Reflesh */
sg_seq->num ++;
sg_seq->byte += len;
sg_seq->last = sec;
/* マルチキャストを行なう場合の処理 */
if (found_sg->do_multicast >0) {
/* MCDP リダ イレクトを送信済みかど うか確認 */
if (ss_rctl_find_receiver(found_sg->sst, cip) == NULL) {
res = ss_rctl_add_receiver(found_sg->sst, cip, dest_port);
if (found_sg->do_multicast > 1) {
ss_rctl_change_trans_way(found_sg->sst,
cip, MCDP_MULTICAST, g);
}
/* MCDP リダ イレクトパケットの送信 */
mm_redirect(s, cip);
} else {
/* MCDP リダ イレクトパケットの再送 */
mm_redirect(s, cip);
}
}
}
図 22 MCDP Option の入力処理
35
4.2.4 一秒毎に行なう情報の更新操作
続いて，一秒毎に行なう管理情報の更新処理を図 23，24，25，26に示す．図 24
は保持されている情報の TTL 値を１減らす処理を行う．図 25は保持されている
情報を用いて，マルチキャストを使用するべき通信であるかの判定を行う．図 26
は保持されている情報が古くなった場合の削除の処理を行う．
void mm_sg_reflesh(int tm, FILE *log)
{
/* (S, G), (S, G, Seq) 情報の更新 */
_update_sg_state();
/* (S, G) 情報毎にマルチキャストの使用について調査 */
_check_sg_multicast();
/* 有効期限が切れた情報を削除 */
_clean_all_sg_state();
}
図 23 一秒毎に行なう処理
4.2.5 受信者数の把握
受信者数の把握には，保持されている (S,G,Seq) 番号が，一定期間参照されず
削除される際に格納されていた，Seq 番号が利用される．
4.2.6 MCDP Redirect の送信
MCDP Router は，(S,G) の受信者の数が一定の数を超え，マルチキャストの
使用を決定した直後から，(S, G) 情報をもつユニキャストパケットの入力に対し
て，MCDP Sender に MCDP Redirect を送信する．この処理を図 28に示す．こ
の関数は，図 22に示す関数から参照されている．
受信者の IP アドレス
36
static void _update_sg_state()
{
SG_State *t;
SEQ_State *sq;
for (t = sg_top->next; t; t = t->next) {
DEC_TTL(t->ttl);
for (sq = t->seq.next; sq; sq = sq->next) {
DEC_TTL(sq->ttl);
}
t->total_num += t->num;
t->total_byte += t->byte;
}
}
図 24 (S, G)，(S, G, Seq) 情報の TTL を減算
static void _check_sg_multicast(void)
{
SG_State *t;
struct timeval tv;
gettimeofday(&tv, NULL);
/* 全ての (S, G) 情報について */
for (t = sg_top->next; t; t = t->next) {
/* マルチキャストを使用していない場合 */
if (!t->do_multicast) {
/* 受信者の比較 */
if (t->listener_num > DO_MULTICAST_MEMBER) {
t->do_multicast = MULTICAST;
}
}
}
}
図 25 マルチキャスト使用の決定
37
static void _clean_all_sg_state(void)
{
SG_State *t;
SEQ_State *sq;
for (t = sg_top->next; t; t = t->next) {
//sg_top->byte = 0;
//sg_top->num = 0;
t->num = 0;
t->byte = 0;
if (t->ttl == 0) {
/* ALL Clean */
/* Clear (S,G)State, Don't break Link
_clean_sg_wo_ll(t);
*/
/* and, Clear ALL (S,G,Seq)State, not break Link */
for (sq = t->seq.next; sq; sq = sq->next) {
_clean_seq_wo_ll(sq);
}
} else {
/* Inttl SG-SEQ Clean */
for(sq = t->seq.next; sq; sq = sq->next)
{
/* Sequence Table expired */
if (sq->ttl == 0 ) {
int seq_backup = sq->sequence;
/* Update Current Listener Number */
if (t->do_multicast > 0) {
_update_current_listener(t, t->listener_num);
} else {
_update_current_listener(t, sq->num);
}
_clean_seq_wo_ll(sq);
sq->sequence = seq_backup;
}
}
}
}
}
図 26 有効期限が切れた情報を削除
38
void _update_current_listener(SG_State *t, int new_num)
{
if (t->listener_num <= new_num) {
/* (S, G) 情報の受信者数の更新 */
t->listener_num = new_num;
} else {
/* 受信者数の減少には若干バイアスを設ける (パケットド ロップ対策) */
t->listener_num = (int)(((float)(t->listener_num
* 9 + new_num)) / 10);
}
}
図 27 受信者数の把握
切り替え後の通信における配送を，マルチキャストを利用して配送可能な
受信者の IP アドレス
切り替え後の配送を代行するルータのアドレス
切り替え後の通信において，指定した受信者への配送のために MCDP Sender
がパケットを送信する宛先．
4.3
受信者の実装
4.3.1 切り替え動作に対する検証検証
受信者は，ユニキャストパケットで転送されてきたデータが，途中からマルチ
キャストパケットで転送されることになっても，通信を切断されることなくデー
タを受信し続けられないといけない．本節では，この要求に対して行った，受信
者の動作検証の説明する．
受信者は，図 29に示す UDP ソケットインターフェイスを用いた一般的なプロ
グラムによって，ユニキャストパケットの受信ができる．
39
void mm_redirect(int sender_ip, int client_ip)
{
struct ip *ip;
Mredirect *mr;
struct udphdr *dummy_udp;
int len = sizeof(struct ip) + sizeof(Mredirect) + sizeof(struct udphdr);
int res;
struct sockaddr_in send_sa;
/* IP Header の設定
ip = (struct ip *)
ip->ip_v
ip->ip_hl
ip->ip_tos
ip->ip_len
ip->ip_len
ip->ip_id
ip->ip_off
ip->ip_ttl
ip->ip_p
ip->ip_dst.s_addr
ip->ip_src.s_addr
*/
redirect_pkt_buf;
= IPVERSION;
= (sizeof(struct ip) + sizeof(Mredirect)) >> 2;
= 0;
= htons(len);
= len;
= 0;
= 0;
= mredirect_ttl;
= IPPROTO_UDP;
= htonl(sender_ip);
= 0;ip->ip_sum
= 0;
/* MCDP Redirect の設定 */
mr = (Mredirect *)(ip + 1);
mr->ipopt_id
= IP_MOPT_VALUE;
mr->ipopt_len = sizeof(Mredirect);
mr->flag
= MCDP_REDIRECT_ADD;
mr->redirect_ip = htonl(my_ip);
mr->client_ip = htonl(client_ip);
/* ADD */
/* ダミーの UDP Header の設定 */
dummy_udp = (struct udphdr *)(mr + 1);
dummy_udp->uh_sport = htons(20000); /* Dummy Port */
dummy_udp->uh_dport = htons(20000); /* Dummy Port */
dummy_udp->uh_ulen = htons(sizeof(struct udphdr));
dummy_udp->uh_sum = htons(0);
memset((char *) &send_sa, 0, sizeof(struct sockaddr_in));
send_sa.sin_family = AF_INET;
send_sa.sin_addr.s_addr = inet_addr(ip2str2(sender_ip));
/* パケットの送信 */
res = sendto(sock_out, redirect_pkt_buf, len, 0,
(struct sockaddr *) &send_sa, sizeof(send_sa));
}
図 28 MCDP Redirect の送信
40
int socket;
struct sockadd_in client;
socket = socket(AF_INET, SOCK_DGRAM, 0);
memset((char *) &client,
client.sin_family
=
client.sin_addr.s_addr =
client.sin_port
=
0, sizeof(client));
AF_INET;
htonl(INADDR_ANY);
htons(bind_port);
res = bind(socket, (struct sockaddr *) &client, sizeof client);
/* ユニキャストで配送されたデータの読み込み処理 */
図 29 ユニキャストパケットの読み込み設定
図 29の操作によって生成されたソケットから読めるデータは，ユニキャストだ
けである．このソケットでは配送が途中からマルチキャストに切り替わった場合，
それ以降のデータを受信できない．
マルチキャストによって配送されたデータを受け取るには，上記の操作に加え
てソケットに対して図 30に示す処理をすればよい．このでは，multi ip という変
数にマルチキャストアドレスが格納されている．
/* multi_ip <= "224.0.0.104" */
struct ip_mreq mreq;
memset((char *) &mreq, 0, sizeof(mreq));
mreq.imr_multiaddr.s_addr = htonl(multi_ip);
mreq.imr_interface.s_addr = htonl(INADDR_ANY);
setsockopt(socket, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));
/* socket 変数を用いた，マルチキャストで配送されたデータの読み込み処理 */
図 30 マルチキャストパケットの受信設定
41
図 30により，指定したマルチキャストグループを宛先としたマルチキャストパ
ケットの受信が可能となる．
ここで，一般的な動作として認知されていないものの，図 29と図 30の処理を
行った後の状態では，マルチキャストとユニキャストの両方のパケットの受信が
単一のソケットで読み込むことができる．図 29と図 30の処理には特別な権限は
必要ない．一般ユーザの権限で行うことができる．このことより，このことから
受信者プログラムは従来のプログラミングスタイルを大きく変更することなく，
既存の API を用いることだけで MCDP に対応できることがわかる．
マルチキャストとユニキャストのパケットが単一のソケットで読み込みできる
ことは NetBSD1.52 で確認した．本論分では，同様の検証をいくつかの OS にお
いても行なった．この結果を表 2に示す．表における○は，ユニキャストパケッ
トが運ぶデータとマルチキャストパケットが運ぶデータが同一ソケットで入力で
きたことを示す．
表 2の結果より，主要な OS において受信者はデータの配送方法が通信中にユ
ニキャストからマルチキャストに切り替わっても，マルチキャストアドレスに参
加さえしていれば MCDP に対応できる．また，この対応には OS に備わる既存
の API を利用するだけでよい．
表 2 各 OS での動作結果
OS
可否
NetBSD1.52
○
FreeBSD4.4
○
RedHatLinux (kernel2.4) ○
Windows2000
○
4.3.2 受信者アプリケーションの改変
受信者プログラムは，配送方法がグループマルチキャストに切り替わる前に，
MCDP Sender からグループマルチキャストアドレスを指定された上で，このグ
42
ループアドレスに参加しておく必要がある．このことを実現するためには２つの
方法がある．以降ではそれぞれについて説明する．
アプリケーションの改変
一つ目は，は送信者が受信者に SIP(Session Initiation Protocol)[15] 等を用い
てグループアドレスに関する情報を送信者が受信者アプリケーションに通知する
方法である．SIP は，電話会議や音声通信などの制御のために IETF の Working
Group で規格化がなされているプロトコルである．SIP を用いることで，スト
リーミング配送を行いながらグループアドレスに関する情報を送信者は，受信者
に通知できる．受信者アプリケーションは，LIBSIP[16] などのライブラリを用い
ること，少ないコストで SIP に対応することができると考えられる．
Proxy の使用
もう一つの方法として，Proxy を用いた別の方式がある．Proxy は，受信者プ
ログラムの代わりにマルチキャストパケットを受信し，ユニキャストパケットに
変換し，受信者プログラムに転送するプログラムである．Proxy を用いれば，受
信者のプログラムに改変を行なわずに MCDP に対応することが出来る．Proxy
の問題としては，受信者に受信用のプログラム以外のプログラムを起動させるコ
ストがあることである．これら２つの方法は，受信者プログラムを提案方式に対
応させために大きなコストにならないと考えられる．
本論分で行った実装では，上記のような対応をせず．起動時に受信者アプリケー
ションにマルチキャストグループアドレスを設定するという方法を用いた．
43
5. 実験と考察
本章では，実験用ネットワークを用いて提案方式の動作の検証を行なう．実験
は，MCDP を適用することによるネットワーク帯域の変化を計測して行った．
5.1
実験ネット ワーク
ネット ワーク
実験は，図 31に示すネットワークを構築して行った．
実験ネットワークは 4 つのネットワークと２つのルータで構成される．10.0/12
と 10.16/12 のネットワークを接続するルータは FreeBSD で動作する PC ルータ
である．このルータでは MCDP Router の実装が動作する．10.0/12 と 10.48/12
のネットワークを結ぶルータは Cisco 2600 である．
実験ネットワークにおいて，受信者ホストが属する MCDP Router 以下の部分が
提案方式の対象とするマルチキャストネットワークである．Cisco2600 では PIM-
DM が設定されており，マルチキャストルーティングを行なう．また，MCDP
Router には，10 以上の受信者へのユニキャスト配送を確認した場合に MCDP
Redirect を送信するように設定している．
受信者
受信者の存在しない IP アドレスへのパケットの送信は，中継を行うルータで
受信者ホストの ARP の解決が出来ないためにド ロップする．そこで多人数の受
信者が存在するネットワークを実現するために，受信者側のホスト 10.2.0.0 で，
IP Alias 機能を利用し 100 個の IP アドレスを追加した．この設定により，受信者
ホストは次の表 3に示すような IP アドレス構成となる．それぞれのホストでは，
付加した IP アドレスの数だけプロセスを起動させ，送信者の送信するパケット
の受信を行う．これらの設定により，MCDP Router 以下のネットワークの 102
人まで受信者に正常にパケットを転送できる．
なお，受信者と送信者との間での通信開始についての制御コネクションは行っ
ていない．このため，実験では送信者は受信者からのコンテンツに対する要求が
44
45
図 31 実験ネットワーク
表 3 受信者側ホストの設定
受信者ホスト
Client1
Client2
Client3
IP アドレスの範囲 IP アドレスの数
10.1.0.0
1
10.2.0.0 - 10.2.0.99
100
10.3.0.0
1
あることを事前に知っているものとする．また，送信者がデータ受信に使用する
UDP のポート番号についても，受信者が知っているものとする．
さらに，マルチキャストへの切り替えが起こる直前に送信者が受信者に知らせ
るマルチキャストグループアドレスについても，受信者には事前に知らされてい
るものとし，そのグループアドレスへの加入を通信前の段階において既に行なっ
ているものとする．
送信者の設定
実験に用いるストリーミングデータは，MCDP Sender と異なるホストで生成
する．これは，配送処理で負荷が掛かると思われる MCDP Sender 上では，実験
で使用するストリーミングデータの帯域を正確に生成することが困難であること
が，実験を行なう過程で明らかになったためである．MCDP Sender は，ホスト
10.32.0.2 にて生成されたデータを受信し，全ての受信者に対する配送を行なう．
ホスト 10.32.0.2 は，ペイロードが 1000 バイトの UDP パケットを，実験で使
用する帯域量となるように，送信間隔を調整して MCDP Sender に送信する．例
えば，1Mbps のストリーミングデータを生成する場合には 8msec の送信間隔で
パケットを送信する．
また，切り替え機構の動作を確認するために，受信者数を通信開始から一秒間
隔で増加させた．つまり，計測時間 t (sec) に応じて受信者数
= t の関係で受
信者数を増加させる．受信者の増加は，受信者ホスト A の IP アドレス 10.1.0.0
から順に，ホスト B の IP アドレス 10.2.0.1, 10.2.0.2, ... ,10.2.0.99 と追加してい
き，102 人目となる受信者ホスト C の IP アドレス 10.3.0.0 が受信を開始するま
46
L
で続ける．
その他の条件
ホストの時刻は，複数ホストにおけるデータ測定を行なうにあたり，NTP(Network
Time Protocol) を使用して同期を取った．このために，まず MCDP Sender が動
作するホストは外部の NTP サーバと同期を取らせ，残りのホストをこのホスト
と同期を取らせた．
なお，計測における時刻情報の取得には，gettimeofday() システムコールを利
用した．この際，マイクロ秒単位までの値を参照可能であるが，計測においては
ミリ秒までの値を利用した．これは，計算機上で得られるミリ秒以下の数値は，
ソフトウェアアーキテクチャ構造のために精度が期待できないからである．また，
計測は，ルータ R のインターネット側インターフェイス fxp0 とド メイン内ネッ
トワーク側 xl0 におけるストリーミング通信の帯域を対象として行なった．また，
計測には tcpdump と解析用の awk スクリプトを用いた．
ホストには十分なネットワークパフォーマンスが出るように，図 32の設定を
カーネルの初期設定ファイル (GENERIC) に追加した．
maxusers
512
options MAXFILES=32768
options NMBCLUSTERS=65536
options NPROC=20000
図 32 カーネルパラメータの設定
5.2
実験結果
本節では，実験の結果を示す．
図 33は，ユニキャストだけで配送を行なった結果を示す．
図 34は，MCDP を用いた場合の結果を示す．
47
100
Internet(fxp0)
Intranet(xl0)
Traffic (Mbps)
80
60
40
20
0
0
20000
40000
60000
Time (ms)
80000
図 33 ユニキャストだけでの配送
48
100000
120000
100
Internet(fxp0)
Intranet(xl0)
Traffic (Mbps)
80
60
40
20
0
0
20000
40000
60000
Time (ms)
80000
図 34 MCDP を用いた配送
49
100000
120000
5.3
考察
図 33では，ユニキャストだけを用いて 102 人の受信者への配送を行なう場合
の評価を行なった．この場合，一つ目の結果は，50000msec 程度の時刻で，50 人
程度にデータを送信を行ない始める場合において，帯域が上流側と下流側の両方
で落ち込み，通信が不安定になる現象が起きた．この時点での帯域の測定値は約
50Mbps/sec 程度であった．この計測結果より，ユニキャスト配送が帯域および，
処理負荷の増加に対して配送可能な人数の上限が実験環境において 50 人程度ま
でサービスを行なえることが分かった．
最後に，図 34では，マルチキャストへ通信を切り替えた場合の評価を行なった．
マルチキャストで受信者にデータを送信する場合，切り替えの直後から，上流側
と下流側両方の帯域量が，受信者一人分だけの帯域しか消費していないことが分
かる．このことから，実装を行った MCDP が期待ど うりに動作していることが
分かる．
50
6. まとめと今後の課題
マルチキャストはストリーミング配送の問題を解決できる技術である．しかし，
現在のマルチキャストは，インターネット規模では動作していない．これは，イ
ンタード メインマルチキャストプロトコルが十分に開発されていないためである．
インタード メインマルチキャストプロトコルの実現は，解決していない問題があ
るため多くの時間が必要であると考えられる．そこで，本論分ではマルチキャス
トネットワークをド メインをまたいで接続することが可能なトンネル技術に注目
をした．トンネル技術には，mrouted と Automatic Tunneling Protocol がある．
しかしながら，これらの方式では実際のインターネットで利用するには問題点が
ある．そこで本論分ではこれらの問題を解決することのできるトンネル技術とし
て MCDP の提案を行った．MCDP は次の点を目的としたトンネル技術である．
動的な接続
受信者にデータが届くことの保証
ユニキャストからマルチキャストへの配送の切り替え
さらに，MCDP の実装と実験による評価を行い，その動作の検証を行った．
MCDP を用いることで，送信者は受信者の属するネットワークに動的にトン
ネル技術を用いて接続することができる．また，その接続は MCDP Redirect に
よって受信者へのマルチキャストネットワークの接続性があることが確認できる．
さらに，送信者は受信者のネットワークがマルチキャストをサポートしていない
場合にはユニキャストで配送を行い．MCDP Redirect を受信することで，マル
チキャストで配送ができることが分かった時点で，マルチキャストの配送に切り
替えることができる．
また，ネットワークは送信者に対して少ない人数への配送にはユニキャストの
通信のままで配送を行なわせ，大人数の受信者に対するストリーミング配信の場
合にはマルチキャストを用いた配送を行なわせる，といった受信者数に応じた配
送方式の切り替えが可能となる．このことは，ネットワークで有効にされている
51
マルチキャストプロトコルを，その特性に応じた通信に合わせて利用できるとい
う面で有効である．
更に，マルチキャストプロトコルに対応していないネットワークも含めたすべ
てのネットワークは，本研究で提案したパケットに付けられれたラベルを観測す
ることで，自分のネットワークに適したマルチキャストプロトコルの導入を検討
するが可能となる．このことも，今後のマルチキャストの普及に対して効果が高
いと考えられる．
今後の課題
提案方式は，送信者，受信者，ルータの動作を改変する方式であった．しかし
ならが，MCDP のラベル付けは，さらに良いマルチキャスト方式を実現するため
に有効であると考えられる．今後はこのような点について関して考察を行いたい．
52
謝辞
本研究を行うにあたり，終始温かい御指導と貴重なご意見を頂きました山口英
教授，砂原秀樹教授，門林雄基助教授に深く感謝の意を表します．
本研究を進めるにあたり数々の御教示と御討論を頂き，温かい目で見守り御指
導頂きました大江 将史氏，Vasaka Visoottiviseth 氏に心より感謝いたします. ま
た数々の励ましと御指導を頂いた計算機言語学講座の奥田 剛助手, 飯田 勝吉助
手にも深く感謝いたします.
日頃より研究活動全般にわたりご協力いただいた計算機言語学講座の皆様に感
謝いたします．
53
参考文献
[1] S. Deering and D. Cheriton. Multicast routing in datagram internetworks
and extended LANs, May 1990.
[2] S. E. Deering. Internet Group Management Protocol - IGMP. RFC1112,
Aug 1989.
[3] W. Fenner. Internet Group Management Protocol, version 2. RFC2236, Nov
1997.
[4] B. Cain, S. Derring, and A. Thyagarajan. Internet Group Management
Protocol, version 3. draft-ietf-idmr-igmp-v3-*.txt, Feb 1999.
[5] T. Pusateri. Distance Vector Multicast Routing Protocol. draft-ietf-idmrdvmrp-v3-10, August 2000.
[6] A. Ballardie. Core Based Trees (CBT) Multicast Routing Architecture.
RFC2201, September 1997.
[7] Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed
Helmy, David Meyer, and Liming Wei. Protocol Independent Multicast Version 2 Dense Mode Specication . draft-ietf-pim-v2-dm-03.txt, June 1999.
[8] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deeringand, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. Protocol Independent
Multicast-Sparse Mode (PIM-SM). RFC2362 , June 1998.
[9] Radia
Perlman
著
加 藤 朗
監訳. Interconnections:bridges,routers,switches,and internetworking protocols,2nd edition.
[10] Christian Huitema 著 前村昌紀 監修. インターネット・ルーティング .
54
[11] Supratik Bhattacharyya, Christophe Diot, Sprint ATL, and Leonard Giuliano. An Overview of Source-Specic Multicast(SSM) Deployment. draftietf-ssm-overview-02.txt, December 2001.
[12] mrouted. http://www.univ-valenciennes.fr/CRU/MBone/mrouted.html.
[13] Ross Finlayson, Radia Perlman, and Doron Rajwan. Accelerating the Deployment of Multicast Using Automatic Tunneling . draft-nlayson-mbonedautotunneling-00.txt, February 2001.
[14] A. Mankin, A. Romanow, S. Bradner, and V. Paxson. IETF Criteria for
Evaluating Reliable Multicast Transport and Application Protocols. RFC
2357, June 1998.
[15] M. Handley and ACIRI. Sip: Session initiation protocol. RFC2543, March
1999.
[16] SIP
Library
with
C++
http://www.cs.columbia.edu/ kns10/software/siplib/.
55
interface.