Flexcast による段階的導入に優れたマルチキャストシステムの設計と

by user

on 28 марта 2017

Category: Documents

>> Downloads: 2

views

Report

Comments

Description

Download Flexcast による段階的導入に優れたマルチキャストシステムの設計と

Transcript

Flexcast による段階的導入に優れたマルチキャストシステムの設計と

Title
Flexcastによる段階的導入に優れたマルチキャストシステ
ムの設計と実装 : システム開発論文特集
Author(s)
井上, 武; 谷, 誠一郎; 高橋, 宏和; 湊, 真一; 宮崎, 敏明; 豊島,
鑑
Citation
電子情報通信学会論文誌. D-I, 情報・システム, I-情報処理
, J88(2): 272-291
Issue Date
2005-02-01
DOI
Doc URL
http://hdl.handle.net/2115/47395
Right
copyright©2005 IEICE
Type
article
Additional
Information
File
Information
40_ieice_2005.pdf
Instructions for use
Hokkaido University Collection of Scholarly and Academic Papers : HUSCAP
論
システム開発論文特集
文
Flexcastによる段階的導入に優れたマルチキャストシステムの
設計と実装
武明
敏
上崎
井宮
谷誠一郎竹
豊島
高橋宏和↑
湊
盲
-t*
鑑
↑
Design and Implementationo
ft
h
eI
n
c
r
e
m
e
n
t
a
l
l
y Deployable M
u
l
t
i
c
a
s
t System
BasedonF
l
e
x
c
a
s
t
e
i
i
c
h
i
r
oTANI↑¥HirokazuTAKAHASHlt S
h
i
n
-i
c
h
iMINATO
T
a
k
e
r
uINOUEta) S
T
o
s
h
i
a
k
iMIYAZAKI
う
↑ a
ndKanTOYOSHIMAt
う
う
いう
あらまし IPm
u
l
t
i
c
a
s
tは，これまで 1
0年以上にわたって研究開発が進められてきたが，インターネット全
域に広く展開されるには至っていない.この原因のーっとして， IPm
u
l
t
i
c
a
s
tを使ったマルチキャストシステム
は，初期投資が大きいという点が考えられる. F
l
e
x
c
a
s
tは IPm
u
l
t
i
c
a
s
tと同様にルータで分岐を行う方式であ
るが，マルチキャスト機能をネットワーク層からより上位の層へと移したため，部分的な導入でサービスを開始
できるという特徴をもっ.我々はこのような F
l
e
x
c
a
s
tの特徴を使って，少ない設備投資でサービスを開始でき，
需要に合わせて拡張可能なマルチキャストシステムを開発した. F
l
e
x
c
a
s
tルータの開発にあたっては， www
検者システムや GRIDcomputingで大きな成果を挙げている PCクラスタを花、用し，初期投資の抑制と高い拡
張性を実現するとともに，ネットワーク装置に求められる高い可用性も実現した.グループ管理システムの開発
では， IPm
u
l
t
i
c
a
s
tとの互換性を維持し，既存アプリケーションの利用を可能とすることで，開発コストを抑制
した.更に， IPm
u
l
t
i
c
a
s
tにおいて長年の懸案となっていたグループアドレス管理に関するスケーラピリティ問
題を，管理権限を局所化することにより解決した.最後に，市販 PCに実装して評価実験を行い，本提案システ
ムが G
bitjsレベルの転送能力を有しており，また，高い 1
可用性を備えることを明らかにした.
キーワード
l
e
x
c
a
s
t
マルチキャスト，マルチキャストルータ，グループ管理，段階的展開， F
のインターネットはユニキャストによる配{言カ古一般的
1.まえがき
であり，受信者数に比例してトラヒックが増大すると
インターネットが広く普及し，現在では誰もが気軽
いう課題を抱えている.この課題を解決するために，
に W W W (WorldWideWeb) や電子メールを楽し
10年以上にわたってマルチキャスト配信技術の研究が
めるようになった.これまでは，文字や静止画のよう
進められてきた.一般にマルチキャストでは，送信者
な小容量コンテンツを中心に利用されてきたインター
を根，受信者を葉とする木状の配信経路を構築する.
ADSLや FTTHによりアクセスラ
送信されたパケットは，節に位置するルータによって
インの広帯域化がj
1!むにつれ， J
I
央{象のような広帯 j
或コ
複製され，各受信者まで届けられる.マルチキャスト
ンテンツに対ーする需要が増加している. しかし，現在
を導入することによって，
ネットであるカ，
T日4
(
'
1
>
1
1
言f
包f
d株式会社
Nτ'T 未来ねっと研究所，i
+
l
l
~l~( t~l
きることが分かつている
r
b
"
NTT Network In!lo
v
a
t
i
o
l
l Laboratoriesヲ N Tぐr Corporatioll，
1
1 Hilmri-llo-oka，
Yokosuka-shi，
2
:
3
9~-0847 .
Japan
i
i 1本;副行 1
5
4
1
5株式会 i
'
J NTT コミュニケーション平1
'
'
f
:
U
s
健研究所，
Jl)~ 本 Tli
N'rrr Connnunication Science Laboratories，N
'
T
"
I
' Corporation，
~i "
'1Mori日 08atoWakamiya，
A.
t
sugi-shi，
243~0198 .
Japan
不
J
J
l
:
f
c
，北海道大学大学院情報科学研究科
a
) 芯l
n
a
i
l
:t
a
，
kern.inoue
⑬1
1l.
i
e
i
c
e
.
o
r
g
2
7
2
電子情報通信学会論文誌
トラヒックを大 11I日に ì~lji成で、
[
1
1
，
][
3
2
]
.
このように大きな利点をもっマルチキャストである
が，その長い歴史にもかかわらず， l
¥
!
IBone[
1
7
]のよ
うな仮想実験志向や企業内，学内に閉じて利用されるに
とどまっている.これにはいくつかの原悶が考えられ
るが [
1
6
]，我々は以下の問題点に注目した. IETF標
準として採用され，最も広く知られているマルチキャ
D-I Vo.
lJ
88-D-I N
o
.2 pp.272-291
@ (社)電子情報通信学会 2005
論文 /
F
l
e
x
c
a
s
tによる段階的導入に優れたマルチキャストシステムの設計と実装
スト方式に IPml
出i
c
a
s
t[
1
3
]がある.しかし，マル
deployment) のサポート，配信経路 (
d
e
l
i
v
e
r
yp
a
t
h
)，
チキャスト機能をネットワーク層で実現しているため，
受信者数 (numbero
fr
e
c
e
i
p
i
e
n
t
s
) に焦点を当てる.
経路ヒの全ルータが対応するまでマルチキャストサー
IPm1l1
t
i
c
a
s
t[
1
3
]は
， IETF標準として採用されて
ビスを開始できない.また，実際のサービスでは，広
いるマルチキャスト方式である.その特徴は，クラ
帯域コンテンツを中心に利用されると予想されるため，
イアント管理と経路制御に異なるプロトコルを用い
Gbit/sレベルの高い転送能力が求められ
る点，マルチキャスト機能をネットワーク層で実現
j
レータには
る.ところが，サービス開始前に高性能マルチキャ
している点にある. PIM-SM (
p
r
o
t
o
c
o
lindependent
ストルータを展開，運用することは，経済的リスクが
t
i
c
a
s
t
s
p
a
r
s
emode)[
1
4
]に代表される経路制御プ
m1l1
大きく，現実的ではない.この問題を解決するために，
ロトコルは，送信者を根，受信者を葉とする最短経
少ない設備投資でサービスを開始し，需要の拡大に合
路木 (jJ1)を構築し，配信を行う.クライアント管理プ
わせて段階的に拡張可能であるマルチキャストシステ
I
n
t
e
r
n
e
tg
r
o
l
l
pmanagement
ロトコルには) IGMP (
ムの登場が望まれている.
8
]あるいは MLD (m1l1
t
i
c
a
s
tl
i
s
t
e
n
e
rd
i
s
p
r
o
t
o
c
o
l
)[
我々は，上記の課題を解決する新たなマルチキャス
ト方式， F
l
e
x
c
a
s
tの提案を行ってきた
[
2
6
，
][
3
1
][
3
4
]
.
ぅ
3
6
]を用いる. IGMP/MLDについては， 2.2
c
o
v
e
r
y
)[
で説明する.一方，マルチキャスト機能をネットワー
F
l
e
x
c
a
s
tは，より上位の層でマルチキャスト機能を実
t
i
c
a
s
tではグループア
ク層で実現するために， IPm1l1
現しており，ルータ悶の通信はユニキャストによって
ドレスという特殊な IPアドレスを用いている.ルー
行われる.このため，ネットワーク全体への展開を待
タは，ユニキャストとは異なるメカニズムによってグ
たずして，サービスを開始することができる.本論文
ループアドレスあてのパケットを転送する.しかし，
は
， F
l
e
x
c
a
s
tを用いたマルチキャストシステムの開発
このメカニズムを実装しないルータが配信経路上に存
について論じる.我々は，少ない設備投資でサービス
在すると，そこでパケットは廃棄されてしまう.結局，
開始可能であること，需要に合わせて拡張可能である
IPm
u
l
t
i
c
a
s
tは，対応ルータがネットワーク全体に展
こと，をマルチキャストシステムに対する課題ととら
開されないうちは満足に動作しないという課題を抱え
え，開発を行った.また，ネットワークシステムに必
ることとなった(仰
須とされる可用性も課題に含め，検討を進めた.開発
IPm1l1
t
i
c
a
s
tの対極に位置する方式が， End-system
システムは， F
l
e
x
c
a
s
tルータとグループ管理システム
1
][
1
0
]である. End-systeulm
l
l
l
t
i
c
a
s
tは
，
m
u
l
t
i
c
a
s
t[
l
e
x
c
c
凶ルータの開発にあたっては，
に大別される. F
マルチキャスト機能を上記層に実装する.そして，各
Google™ [
3
9
]に代表される
www検索システムや
受信者を節とする配信経路を構築し，ユニキャストで
GRIDcomputing[
4
0
]で大きな成果を挙げているク
節簡を通信する.このため，ルータへの機能追加は不
PCクラスタによっ
要であり，受信者にソフトウェアを配布することで迅
ラスタシステムを応、用し，小規模
ぅ
てルータシステムを構成した.グループ管理システム
速にサービスを開始することカ fできる.しかし，ノ f
Pm
u
l
t
i
c
a
s
tとの互換性やスケーラピリ
の開発では， I
ケットの複製を受信者が行うため，配信経路は大きく
ティに盟意した.
Pm
u
l
t
i
c
a
s
tほどの大きなトラ
迂回することとなり， I
.で F
l
e
x
c
a
s
tを始めとしたマルチキャスト
以下， 2
方式を振り返る. 3
. で開発システムへの要求条件を
ヒック削減効果は期待できない.また，品質やセキュ
リティを他の受信者に負うという課題も残される.
.， 5
.で F
l
e
x
c
a
s
t)レータとグループ管理シ
確認し， 4
Xcast[
3
]は，パケットヘッダに受信者アドレスを列
ステムの構成方法を提案する.評価結果を 6
. で述べ
挙し配信経路上のルータが必要に応じてパケットを
る. 7
. では関連技術について触れ， 8
. で本論文をま
とめる.
(
注1
) :本論文では，各受信者から送信者への l
i
Y
:r
;
f
l
経路によって機成さ
2
. マルチキャスト方式
れる木を指す.
(
1
12) :過渡的な対処法として，対応ルータ l
i
J
lにトンネルを設定し，非
対応、ルータを越えて配信を行うことができるが，運用コストの !
1
[
H加とい
2.1 マルチキャスト方式比較
う課題がある [
2
J
. 途別コストを削減するために，受信者から迷焔の IP
multicεstルータへと自動的にトンネルを構築する方式も提案されてい
本章では，現在までに提案されているマルチキャス
ト方式を 4種類に分類し，それぞれの得失を明らかに
i
n
c
r
e
m
e
n
t
a
l
する.比較にあたっては，段階的展開 (
2
0
，
][
3
5
J
. しかし，このようにして機当5
されるトンネルは，マルチ
る[
キャスト特有の木状経路ではなく，ユニキャストのように放射状となる.
このため. IP multicast の利点であるトラヒック削減効果が ~~Åi れてし
まうという欠点がある.
273
電子情報通信学会論文誌 2
0
0
5
/
2Vo
l
.J
88-D-IN
o
.2
表 1 マルチキャスト方式比較
T
a
b
l
e1 C
o
m
p
a
r
i
s
o
no
fsomem
u
l
t
i
c
a
s
tm
e
t
h
o
d
s
.
M
u
l
t
i
c
a
s
tmethod
I
n
c
r
e
m
e
n
t
a
ld
e
p
l
o
y
m
e
n
t
I
Pm
u
l
t
i
c
a
s
t
N
o
ts
u
p
p
o
r
t
e
d
E
n
d
s
y
s
t
e
mm
u
l
t
i
c
a
s
t
S
u
p
p
o
r
t
e
d
X
c
a
s
t
S
u
p
p
o
r
t
e
d
S
u
p
p
o
r
t
e
d
F
l
e
x
c
a
s
t
D
e
l
i
v
e
r
yp
a
t
h
子
学 o
fr
e
c
e
i
p
i
e
n
t
s
S
h
o
r
t
e
s
tp
a
t
h
U
n
l
i
m
i
t
e
d
Redundantp
a
t
h
U
n
l
i
m
i
t
e
d
S
h
o
r
t
e
s
tp
a
t
h R
e
s
t
r
i
c
t
e
db
yp
a
c
k
e
tl
e
n
g
t
h
S
h
o
r
t
e
s
tp
a
t
h
U
n
l
i
m
i
t
e
d
複製しながら配信を行う方式である.ユニキャストア
プアドレス G のペア (
8 G)によって区別される.以
ドレスをあて先とするため，配信経路上に非対応ルー
下，このベアを 88Mチャネル，あるいは単にチャネ
タが存在してもパケットが廃棄されることはない.し
l
e
x
c
a
s
tルータを次
ルと呼ぶ.また，説明の便宜上， F
かし，受信者数に比例してパケットヘッダが大きくな
のように区別する.サーバと同一セグメントに接続さ
るため，配信数に限界が生じる.また，パケットを転
れたルータを Rootルータ，クライアントと向ーセグ
送するたびに，列挙されたすべてのアドレスに対して
メントに接続されたルータを Leafルータ，その他の
経路探索を行うため，ルータの転送負荷が非常に高く
ルータを Branchingルータとする.
ヲ
なる.複数パケットにわたって Xcastを行うことで，
F
l
e
x
c
a
s
tでは， IPml
此i
c
a
s
tと同様に， IGMP/MLD
5
]も提案されてい
配信数の限界を解消する改良方式 [
によってクライアントを管理する.このため， IPmul-
るが，長すぎる受信者リストは，より大きなオーバ
t
i
c
a
s
t用に開発されたクライアントをそのまま別用する
ヘッドをもたらす.
ことができる. IGMP/班 LDにはいくつかのパージョ
F
l
e
x
c
a
s
t[
2
6
]，[
3
1
]，[
3
4
]は，上記 3方式それぞれの
e
r
s
i
o
n
ンがあるが，チャネルの特定が可能な IGMPv
特徴を併せもつマルチキャスト方式である.ここで
3，MLDv
e
r
s
i
o
n2 (以下， IGMPv3/MLDv2) を用
l
e
x
c
a
s
tは
，
は特徴を述べ，詳細は次節で説明する. F
いる.
Endsystemm
u
l
t
i
c
a
s
tや Xcastと同様に，マルチキャ
続いて， F
l
e
x
c
a
s
tの動作概要を説明する.クライア
スト機能をより上位の層に実装し，ユニキャストアド
ントは，受信を希望するチャネルを記載した IGMP
l
e
x
c
a
s
tを実装
レスにより通信を行う.このため， F
u
l
t
i
c
a
s
tl
i
s
t
e
n
e
r
membershipr
e
p
o
r
tあるいは MLDm
しないルータが混在したネットワークであっても，マ
r
e
p
o
r
tを送出する. Leafルータは Reportを受信す
ルチキャスト配信を行うことができる. F
l
e
x
c
a
s
tの
oinと呼ばれるパケットを作成し，定期的に
ると， J
配信木は，クライアントからサーバに至るユニキャス
送信する. Joinパケットには受信希望チャネルを記載
ト経路を束ねた最短経路木になるため， End-system
し，サーバのユニキャスト IPアドレスをあて先に設
司
m
u
l
t
i
c
a
s
tのように経路が冗長になることはない.経
oinパケットは通常のユニキャスト IPルー
定する. J
l
e
x
c
a
s
tルータで分!肢が行われ，その割合が増
路上の F
テインク、、に従ってサーバへと転送される.この転送経
えるほどトラヒック削減効果は大きくなる.すべての
路上に Branchingルータが設置されていると，その
u
l
t
i
c
a
s
tと伺等のトラヒッ
ルータが対応すると， IPm
Branchingルータは J
o
i
nパケットの送信元アドレス
)
ク削減効果が得られる(ii'3
l
e
x
c
a
s
t転送表 (
F
l
e
x
c
a
s
tforwardingt
a
b
l
e
) と呼
をF
以上の議論により，我々は F
l
e
x
c
a
s
tを選択した.表 1
に各方式の特徴を簡単にまとめる.
2
.2 Flexcast
本節では， F
l
e
x
c
a
s
tについて説明を行う. F
l
e
x
c
a
s
t
の役割は経路制御とデータ配信である.信頼性やセ
キュリテイについては，他の方式と組み合わせること
で実現する.詳細は 7
. で述べる.
F
l
e
x
c
a
s
tでは，送信者(サーバ)を根とする木状の
経路を構築し，配信を行う.以下，この木状の配信経
s
o
u
r
c
es
p
e
c
i
f
i
c
路を配信木とIl乎ぶ.配信木は， 88M (
m
u
l
t
i
c
a
s
t
)[
2
5
] と同様に，サーバアドレス Sとグルー
2
7
4
ばれる表に登録する.転送表には，チャネルごとに要
求元アドレスが記録される.そして， Leafルータと
oinパケットを作成し，サーバへと定期的に
同様に J
送信する. Rootルータも， Branchingルータと同様
oinパケットが Root
に転送表を管理する.最終的に J
ルータまで到達すると，配信木が完成する.
(
注3
) :F
l
e
x
c
a
s
tと同様のね{放をもっ方式に， REUNITE(
R
B
c
u
r
s
i
v
e
U
N
i
c
a
s
tT
r
e
E
)[33]や HBH(
H
o
pByHopl
l
l
u
l
t
i
c
a
s
t
)[12]がある.
EUNITEは特殊なアルゴリスムにより配も材班長を俗芸 Eする
しかし， R
ため，受信者離脱時の経路 J
併{
I
J成処 J
l
!
:
l
が配信木全体に波及するという課
題がある [
1
2
]
. また， HBHはプロトコルが非常に級車f
rであり，配信さ
4
]
.
れない受信者が現れる可能↑生が指摘されている [
論文 /
F
l
e
x
c
a
s
tによる段階的導入に優れたマルチキャストシステムの設計と実装
.
.
.
.
- F
l
e
x
c
a
s
tj
o
i
n
噌圃
F
l
e
x
c
a
s
ts
t
r
e
a
m
4 I Pm
u
l
t
i
c
a
s
ts
t
r
e
a
m
R
:戸 r
w
a
r
d
i
n
g
匹目
5
B1:
f
o
r
w
a
r
d
i
l
l
g
B1:五
orwarding
t
a
b
l
e
E開
E門
E雪
B2
B2:f
o
n
v
a
r
d
i
l
l
g
B2¥戸川 a
r
d
i
n
g
(
a
)
Ll
t
a
b
!
e
I S.G ILl
.L21
Cl I
・
i
(
b
)
(
c
)
(
d
)
図 1 F
l
e
x
c
a
s
t動イ乍例
Ane
x
a
m
p
l
eofF
l
e
x
c
a
s
t
F
i
g
.1
Rootルータは，サーバから IPm
u
l
t
i
c
a
s
tノfケット
Branchingルータ Blの転送表には B2が
， Rootルー
を受信し， Streamと呼ばれるパケットにカプセル化
タ R の転送表には Blが登録される(図 l
(
a
)
)
. Rは
，
する.そして，転送表に登録されている要求元へとユ
Sが送出している IPm
u
l
t
i
c
a
s
tパケットを Streamパ
ニキャストで送信する. B
ranchingルータは，受信し
ケットにカプセル化し， Blへと送信する. Streamパ
た Streamパケットを，転送表の各要求元へと転送す
ケッドは B2を経由して Llに届けられ，カプセル化
る.最終的に Streamパケットが L
eafルータまで到
を解かれた IPm
u
l
t
i
c
a
s
tパケットが Clへと到着する
eafルータによってカプセル化されていた
着すると， L
(
図 1(
b
)
).
IPm
u
l
t
i
c
a
s
tパケットが取り出され，クライアントへ
と送出される.
クライアントが受信を停止するときは，次のような
続いて，クライアント C2， C3が R
eportを送信す
る.この R
eportを受信した Leafルータ L2，L3は
，
Ll と向車禁に J
o
i
nノfケットを送信し，それぞれ B2，
動作が行われる.まず，クライアントが IGMP/MLD
Blの転送表に登録される(図 l
(
c
)
)
. Rは
， Sが送
l
e
a
v
eを送出する. Leafルータは，他に同一チャネ
出している IPm
u
l
t
i
c
a
s
tパケットを Streamパケット
ルを受信しているクライアントが存在しないことを
にカプセル化し， Blへと送信する. Streamパケット
確認すると，サーバあてに Pruneパケットを送信す
は Bl，B2で複製され， Ll，L2，L3まで届けられる.
る. Pruneパケットには，停止チャネルが記載される.
Ll，L2，L3はカプセル化を解き， Cl，C2，C3へと
Pruneパケットが Branchingルータによって受信され
IPm
u
l
t
i
c
a
s
tパケットを送信する(図 l
(
d
)
)
.
ると， B
ranchingルータは送信元を転送表から削除す
ここで， B2が F
l
e
x
c
a
s
tに対応していない場合を考
る.そして，そのチャネルの要求元がいなくなったら，
える. Ll，L2カ'
J
差{言した J
o
i
nは
， B2ではなく Bl
Pruneパケットをサーバへと送信する. Rootルータ
によって受信される.そして， Blの転送表に Ll，L2
もB
ranchingルータと同様に， Pruneパケットの送信
が登録される. Streamパケットは， Blで三つに複
元を転送表から削除する.要求元がいなくなったチャ
製され， Ll~L3 にあてて送られる.この後， B2を
ネルは，配信を停止する.
F
l
e
x
c
a
s
t対応ルータに置き換えると， Llと L2への分
図 1は
， 3台のクライアント Cl，C2，C3カえチャ
岐が B2で行われることになる.つまり，最初からす
ネル (
S，G) を JII~ に要求する操子を表している.配信木
べてのルータを F
l
e
x
c
a
s
t対応にしておく必要はなく，
の右側には，各ルータが管理する F
l
e
x
c
a
s
t転送表を記
後から順次 F
l
e
x
c
a
s
t対応ルータを増やしていくこと
す.この図を用いて，具体的な動作例を説明する. L
eaf
が可能であり，これによって配信効率を向上させるこ
ルータ Llは，クライアント Clが送出した R
eportを
l
e
x
c
a
s
tルータの割合が増えるほどトラ
とができる. F
受信すると，サーバ Sあてに J
o
i
nパケットを送信する.
ヒツク部減効果は大きくなり，全ルータが対応すると
Llから Sへの経路上に設置された Branchingルータ
IPm
u
l
t
i
c
a
s
tと同じ配信木を構築することができる.
B2は
， J
o
i
nパケットの送信元である Llを転送表に登
ところで，本節では IGMPv3/MLDv2の利用を
録し， Sあてに J
o
i
nパケットを送信する.同 4
最にして，
前提として， F
l
e
x
c
a
s
tの説明を行った . しかし，
2
7
5
電子情報通信学会論文誌 2
0
0
5
/
2Vo
l
.J
8
8
D
IN
o
.2
現在は IGMPv3jMLDv2への移行過渡期であり，
l
e
x
c
a
s
tでは TCPやむDPと
2.2で見たように， F
IGMPv1，
2jMLDv1を実装したクライアントもまだ
いった下位層を規定していない.そこで，まず，下位
2jMLDvlはグループアドレ
多く存在する. IGMPvl，
層についての議論から開始する.1.でも述べたよう
スのみを指定するプロトコルであり， SSMチャネルを
に，我々は主なコンテンツとして映橡を検討している.
2jMLDvlクライ
特定することができない. IGMPvl，
映像は一般に容量が大きいが，ファイル配信のように
アントに対して配信を行うためには，グループアドレ
完全な信頼性は要求されないことが多い.このことか
スにサーバアドレスを追加し，チャネルを耳文得するメ
ら，信頼性は低いがオーパヘッドの小さい UDP とに
カニズムが必要とされる.また， IGMPv1ぅ2jMLDvl
プロトコルを実装する. I
P上に新たなトランスポー
を用いる場合には，グループアドレスをネットワーク
ト層を定義することも可能で、あるが，ファイアウオー
全体で一意に保たなければならないが，スケーラピリ
ルやネットワーク監視技術との親和性が低くなるため
ティのあるグループアドレス管理方式は提案されてい
採用しない.
J
o
i
n，Pruneパケットのあて先ポート番号は，あら
ない [
1
6
]
.
3
. マルチキャストシステムへの要求条件
本節では，マルチキャストシステムが実現すべき課
ルータは，通過する UDPパケットのあて先ポート番号
o
i
n，Pruneパケットをえり分ける. F
l
e
x
を検査し， J
c
a
s
t転送表に J
o
i
nパケットの送信元を登録する際に
題を確認する.
@
l
e
x
c
a
s
tルータで統ーしておく. F
l
e
x
c
a
s
t
かじめ全 F
は
， IPアドレスに加えて， J
o
i
nパケットの送信元ポー
設備投資の抑制
既存資産を有効に利用した開発を行い，設備投資を
l
e
x
c
a
s
tルータの開発では，既に運用
抑える.例えば， F
されているルータやスイッチを取り込んでシステム設
ト番号を記録しておく.このポート番号は， S
tream
パケットのあて先ポート番号となる.なお，各パケッ
トの送信元ポート番号は任意とする.
計を行うことが望ましい.また，これまでに開発された
UDPヘッダの次に，パージョンやチャネルといった
IG間 Pvl2jMLDv1クライアントを利用するために，
l
e
x
c
a
s
tヘッダを定義する. F
l
e
x
フィールドをもっ F
グループ管理システムによって IGMPv1ぅ2jMLDv1
c
a
s
tヘッダは， IPv4のとき 1
6ノfイト， IPv6では 40
への後方互換性を実現する.
バイトとなる.具体的なヘッダフォーマットは省略す
高いスケーラピリテイ
る. Streamパケットでは， F
l
e
x
c
a
s
tヘッダに続いて
ぅ
@
マルチキャストシステムは，多くのユーザに対して
IPm
l
l
l
t
i
c
a
s
tパケットをカプセル化する.カプセル化
サービスを提供することを期待されているため，高い
によるオーバヘッドは， IPv4の場合で 4
4バイトと
スケーラピリテイが要求される.そのため， F
l
e
x
c
a
s
t
なる(注 4)
ルータはトラヒックの伸びに合わせて転送能力を段階
的に拡張することができ， G
b
i
t
j
sレベルの高い転送能
MPEG-2TransportStreamで標準的に用いられる
1356バイトであるとすると，カプセル化によるオー
力を達成できることが望ましい.また，グループ管理
3
.
2
%のオーバヘッドとなる.
バヘッドは約 :
システムは，グループアドレス管理にまつわるスケー
ラピリティ問題を解決することが期待される.
@
高い可用性
カプセル化される I
Pm
l
l
l
t
i
c
a
s
tパケットカf
う
4.2 クラスタシステム
持支的に，マルチキャストのように基本的なネット
ワーク 1~ 能は，ルータあるいはスイッチと U'f ，まれる
可用性を高めるためには，システム全体が多重化さ
ネットワーク専用装置に実装される.複数ベンダの装
れ，単一故障点が存在しないことを要求される.シス
置によって構成されているネットワークに新しい機能
テムは自動的に障害を検知し
を追加する場合は，ベンダごとに開発を行い，
予備システムへと切り
l
t
l日:運
換わる.切換時間は， RIP[
2
8
]，OSPF[
2
9
]といった
J
ザJ
]
免トラヒッ
用性の検証作業が必要となる.また，広;
経路制御プロトコルと同校度の数
1
1を伴うマルチキャスト機能
クのリアルタイム複製処王1
数ト秒を目指す.
4
. Flexcastルータの言宣言十
4.1 プ口トコ jレ設計
は，通常のネットワーク装置で F
日いられる CPUでは
処理能力が不足し，専用のハードウェアが必要となる
場合もある.結果的に，マルチキャストルータの開発
本節では， 2.2で紹介したアルゴリズムをプロトコ
ルとして定義する.
2
7
6
(
Y
I
>
t
):20 (IPヘソダ)ト 8 (UDPヘソダ )+16 (Flcxcas(，ヘ、ソダ )='J4.
論文 /
F
l
e
x
c
a
s
tによる段階的導入に優れたマルチキャストシステムの設計と実装
は高くつくことが多い.
睡
き
つ
ー‘方，オフィスや家庭 l
u
jけコンピュータである PC
は，低価格で処理能力の高い
事
CPOを備えている.比較
PC
的負荷の高い機能であっても，ソフトウェア実装で処
1
3
9
]
理することができる.更に，近年では， Google™ [
に代表される
www検索システムや GRIDcomput-
4
0
]において， PCで構成したクラスタシステム
i
n
g[
M
o
t
h
c
r
r
o
u
t
e
r
を用いて高い処理能力と可用性を実現することに成功
している.クラスタシステムとは，
1
&妻女のコンピュー
タを組み合わせて一つの機能を実現するシステム形態
(B
i
a
n
c
h
i
n
g
勢;ぬ
のことであり，安価なコンピュータを用いて高い処理
能力と可用性を得ることができる.
B
r
a
n
c
h
i
n
gr
o
u
t
e
rs
y
s
t
c
m
我々は，運用中のルータあるいはスイッチに小規模
凶 2B
r
a
n
c
h
i
n
gルータシステム打者成例
F
i
g
.
2 An巴x
a
m
p
l
eo
fb
r
a
n
c
h
i
n
gr
o
u
t
e
rs
y
s
t
e
m
.
l
e
x
c
a
s
t
な PCクラスタを接続し，システムとして F
ルータ機能を実現するアプローチを選択する.既存設
備を有効利用し，また開発コストや装置コストを抑え
ることで，初期投資を抑える.更に，クラスタシステ
BranchingPCが担当しているチャネルが記録され
采用することにより，高いスケーラピリティと可
ムを t
e
e
p
a
l
i
v
eパケットを受信しなかった
る. 一定時間 K
l
e
x
c
a
s
t以外のパケッ
用性を期待することができる. F
BranchingPCは，障害が発生したとみなされ，担当
トは既存のルータあるいはスイッチで処理されるため，
PC表から削除される. BalancerPC閉では， VRRP
従来どおりの信頼性が確保される.
(
V
i
r
t
u
a
lRouterRedundancyProtocol
)[
2
4
]等によ
以下，ルータあるいはスイッチと
PCクラスタを
り，冗長化が行われる.
l
e
x
c
a
s
tルータシステムと呼ぶ.次節より，
まとめてふ F
母ルータは，通過する UDPパケットのあて先ポー
F
l
e
x
c
a
s
tルータシステムの構成方法を具体的に説明す
o
i
n，Pruneパケットを Balancer
ト番号を検査し， J
る
(
注 51
PCへと転送する(注 61
4.3 Branching)レータシステム
4.3.1 概要
4.3.2 負荷分散メカニズム
1支に，
クラスタシステムでは，クラスタ入口に
本節では B
ranchingルータシステムの構成方法を提
負荷分散装置を設置し，クラスタを構成する各コン
案する.関 2 に構成例を示す.図に示すように，既に
ピュータにパケットを振り分ける. トラヒック量に比
稼語力中のルータあるいはスイッチに
PCクラスタを f
i
E
べてデータ処理負荷が大きい場合には，このメカニズ
続する. j
:
)
、
降
， PCクラスタが接続されるルータある
ムは効果的に動作する. しかし，マルチキャストのよ
motherr
o
u
t
e
r
) と呼ぶ.
いはスイッチを，母ルータ (
うにトラヒック量が大きくなると，負荷分散装置が過
PCクラスタは，負荷分散 Ooadb
a
l
a
n
c
e
r
) 機能をも
負荷になるおそれがある.この課題を解決するために，
， B
ranchingルータ手足能をもっ PCによって
っ PCと
6
]という負荷分散方式を参考にする.
サーバ直接応答 [
alancerPC，後者を Branching
構成される.前者を B
詳細は省略するが，サーバI
直接応答では，データパ
PCとu
乎ぶ.
l
e
x
c
a
s
tルー
ケットを負荷分散装置から迂囲させる. F
BranchingPCは
， 2
.2で述べた処理を行う.唯一異
a
l
a
n
c
e
rPCに対し，定期的に K
e
e
p
a
l
i
v
e
なる点は， B
パケットを送信することである.
B
a
l
a
n
c
e
rPCの役割は， J
o
i
n，Pruneノfケットを
BranchingPCにJ
辰りう子けることである. B
alancer
， K
e
e
p
a
l
i
v
eパケットによって稼動中の BranchPCは
i
s
t
) に記録する.
i
n
gPCを知り，担当 PC表 (PCl
ranchingPC 一覧と，各
担当 PC表には，稼動中 B
alancer
タシステムにおいても， Streamパケットが B
PCを通過しないよう留意して設計を行う.
l
e
x
c
a
s
tルータシステムの負荷分散メカ
本項では， F
u
主5
) :;
な
お
， IPm
u
l
t
i
c
a
s
tは，ネットワーク 1
日でマルチキャスト機能
を実現するため，パケ y トのあて先を明示的に変吏することが凶嫌であ
り，クラスタシステムによるアプローチは迎さない.
(
注6
) :近年では，多くのルータやスイァチが，このようなボート香号
による転送機能をもっ. 6.2.1 で述べるように，我今はいくつかの代表
的なルータとスイァチで実!~設を行い，
I
!
U
J
f
Fを確認している.
277
電子情報通信学会論文誌 2
0
0
5
/
2Vo
l
.J
88-D-INo.2
!
t
oS
1，S2
︻
Bl
V2(
ba
c
;
t
u
p
)
E
V2(
b
a
c
R
;
u
p
)
t
oS1，S2
G一一一
一
?
一一一
L-S
一一
C一
i﹂
l一
寸i寸一
P
一
一
Aっ
と一
J 2
vl一一一
V2(
b
a
c
J
<
;
u
p
)
V
1
:PCl
i
s
t
IBlI
IB2I
1
j
t
aS
1，S2
81・f
o
r
w
a
r
d
i
n
g
Bl
Bl
I
S1
.
G
l
.
.
l
.Ll I
(
a
)
10S
1，S2
(
む
)
(
c
)
10S
1，S2
t
oS1，S2
吋り
e
V2(
b
a
c
R
;
u
p
)
ロV2(bacl<;up)
Bl
口 Bl
8
2
:f
o
r
w
a
r
d
i
n
g
れリ
(
e
)
口
(
(
d
)
、
品
川
、
口
¥V
V
l
:P
C
l
i
s
l
Vl(~aster)
図3B
r
a
n
c
h
i
n
gルータシステム動作例
F
i
g
.
3 Ane
x
a
m
p
l
eo
fl
o
a
db
a
l
a
n
c
i
n
gi
nb
r
a
n
c
h
i
n
gr
o
u
t
e
rs
y
s
t
e
m
.
ニズムを説明する. B
a
l
a
n
c
e
rPCは，母ルータから
PCを担当 PC表に追加し，次に担当を選択するとき
J
o
i
nパケットを受信すると，要求チャネルを担当して
から候補として扱う. B
ranchingPCを追加する際に，
ranchingPCを担当 PC表から検索する.担当
いる B
j
レータシステムとしての機能を停止する必要はない.
が未割当である場合，何らかのアルゴリズムによって，
図 3に
， B
ranchingルータシステムの動作例を示
(
8
1，G
1
)に
そのチャネルの担当 B
ranchingPCを選択する.選択
す.図では， L
eafルータ L1がチャネル
アルゴリズムには，ラウンドロビンのような単純な方
対し， J
o
i
nパケットを送信している. 2台の B
a
l
a
n
c
e
r
法から，クライアントの要求傾向に基づき負荷を先読
， VRRPによって冗長化されている.
PCV1，V2は
みするような高度な方法まで，在意のアルゴリズムを
VRRPについては 4.3.4で説明する.ここでは， V1，
用いることができる.最終的に， B
a
l
a
n
c
e
rPCは J
o
i
n
V2のうち， V1のみが動作していると考えればよい.
パケットを担当 B
ranchingPCへと転送する.このよ
Vlの担当 PC表には， BranchingPCB1，B2が登
うにして，各 B
ranchingPCへと負荷を分散する.
録されている.母ルータ M は
， L1が送信した J
o
i
nパ
J
o
i
nパケットを受信した BranchingPCは
， J
o
i
nパ
ケットを V1へと転送する(図 3
(
a
)
)
.J
o
i
nパケット
ケットの送信元を転送表に登録する.そして， B
ranch-
を受信した V1は，担当 PC表を検索し， (
8
1，G
1
)が
i
n
g PCは，自分を送信元とする J
o
i
nパケットを
登録されていないことを知る.すると，担当として B1
生成し，サーバへと送信する.すると，上流からの
を選択し， J
o
i
nパケットを転送する. B1は
， L1を転
8treamパケットは， BalancerPCをキ壬由することな
送表に登録し(引に Bl を送信元とする J
o
i
nパケット
，
く B
ranchingPCへと直接送られてくる.このよう
b
)
)
. 8treamパケッ
をサーバ 81へと送信する(図 3(
にして， 8treamパケットを B
a
l
a
n
c
e
rPCから迂回さ
トが B1に届くと， B1は転送表に笠録されている L1
へと転送する(図 3
(
c
)
)
.
せる.
ル」タシステムとしての転送能力を向上するには，
続いて， L
eafルータ L2が，チャネル (
8
2，G2)へ
ranchingPCを追加するだけでよい.追加さ
単純に B
o
i
nパケットを送信する(図 3
(
d
)
)
. V1は，新た
とJ
~/した Branching
PCは
， B
a
l
a
n
c
e
rPCに K
e
e
p
a
l
i
v
eノf
ケットを送イ言する. B
a
l
a
n
c
e
rPCは，この Branching
(
i
t7) :4.1で説明したように，実際には Ll の 1P アドレスと送信元
ポート番号がを録されるが，ここでは ìi~_今に Ll とだけ記す.
2
7
8
論文/
F
l
e
x
c
a
s
tによる段階的導入に優れたマルチキャストシステムの設計と実装
t
o51，52
t
o5
1，52
e
r
)
Vl何回 t
V1
:PCl
i
s
t
V
1
:P
C
l
i
s
t
にナロ7τ~
.G
]
)
.(
S
2
.
G
2
l1
￨B21 (
S1
Inフ I
(S2，
G勾i
L
V2(bad;up)
二一一一一J
B2:forwarding
0
0
~
~
隠I
4B
r
a
n
c
h
i
n
gPC障害時の動作例
F
i
g
.
4 Ane
x
a
m
p
l
eo
ff
a
i
l
o
v
e
rwhen b
r
a
n
c
h
i
n
gPCi
sg
e
t
t
i
n
gd
o
w
n
.
乱
な担当として B2を選択し， J
o
i
nパケットを転送す
いため，停止時間を次の範囲に収めることができる.
o
i
n
る. B2は L2を転送表に登録し，サーバ 82へと J
パケットを送信する(図 3(
e
)
)
. 8treamパケットは
Tkeep-
1
keep <D <Tke叩
(
2
)
B2に到着し， L2へと転送されていく(関 3(
f
)
).こ
図 4 を用いて BranchingPCに障害が発生した際
a
l
a
n
c
e
rPCV1によって，負荷は 2台の
のように， B
の動作を説明する. Branching PC B1 に障害が発
BranchingPCB1，B2に分散される.
e
e
p
a
l
i
v
eパケットが途絶え，しばらく
生すると， K
4
.3
.3 BranchingPC障害
して B
alancerPCV1の担当 PC表から削除される
本項では， BranchingPCに障害が発生したとき
(
a
)
)
. その後，チャネル (
8
1，G1)への J
o
i
nパ
(
図 4
の動作メカニズムを説明するUc
E8)
障害に見舞われた
b
)
)，担当 PC表から
ケットを受信した V1は(図 4(
BranchingPCの担当チャネルを，障害発生チャネル
(
8
1，G1
)を検索し，未登録であることを知る.新担当
と呼ぶことにする. BranchingPCに障害が発生する
尺し， J
o
i
nパケットを
として BranchingPCB2を選4
e
e
p
a
l
i
v
eパケットが途絶え， BalancerPCの担
と
， K
転送する. B2は，転送表に (
8
1ぅ G1)と L1を登録し，
当 PC表から削除される.その後，障害発生チャネル
o
i
nパケットを送信する(国 4(
c
)
)
.
サーバへと J
への J
o
i
nパケットを BalancerPCが受信すると，担
4
.3
.4 B
alancerPC障害
当 PC表の中から担当を選択し度す.そして，新担当
alancerPCに障害が発生した場合を考
本項では， B
によって，配信が再開される.
a
l
a
n
c
e
rPCの冗長化プロトコルには VRRP
える. B
このように， BranchingPCに障害が発生しても，
を用いるとする. VRRPでは，複数の装置を一つの
ルータシステム全体としては Branchingルータの機
グループに所属させる.通常は，そのうち 1台がグ
能を継続することができる.障害発生チャネルの配信
ループを代表する仮想 IPアドレスを用いて通信を
e
e
p
a
l
i
v
eがタイムアウトし，次の J
o
i
n
停止時間は， K
行う.通信を行っている装置をマスター，待機中の装
パケットを受信するまでとなる.停止時間を D とす
置をパックアップと呼ぶ.マスター装置は定期的に
ると，次の不等式で表すことができる.
Tkeep - 1ke叩
<D
<Tkeep十
ん oin
Adv
e
r
t
i
s
e
m
e
n
tパケットを送信する.マスター装置に
(
1
)
ここで，1ke叩，
Tkeep はそれぞれ K
e
e
p
a
l
i
v
eパケット
送信関隔とタイムアウト時間，1jo聞は J
o
i
nパケット
送信間隔である.また，heep <Tke叩である.
なお，B
a
l
a
n
c
e
rPCにも BranchingPCと同様の
転送表を管理させることで，停止時間を短縮すること
a
l
a
n
c
e
rPCは
， K
e
e
p
a
l
i
v
eカfタイムアウ
もできる. B
トすると同時に新担当を選択し，転送表を新担当に送
信する.新担当は，すぐにサーバへと J
o
i
nパケット送
信し，配信を再開する.次の J
o
i
nパケットを待たな
障害が発生し， A
dvertisementパケットが途絶えると，
同一グループに属するパックアップ装置の一つが仮想
IPアドレスを引き継ぎ，マスターに切り換わる.母
ルータや BranchingPCは，仮想 IPアドレスに対し
て通信を行うため，切換後も ARPキャッシュの更新
を行うだけで通信を継続することができる.
K
e
e
p
a
l
i
v
eパケットが途絶えるような隊害を想定
o
s
. ネットワークケーブルに隊:去が
r
a
n
c
h
i
n
gルータプロ
発生した場合である.その他の障害例えば， B
(
注8
):.本論文では，
し，議論を行う.例えば， PCや
セスのみが停止するような際答については，既存のプロセス民主祝ツール
3
8
J と組み合わせることで解決することができる.
等[
279
電子情報通信学会論文誌 2
0
0
5
/
2Vol
.J
8
8
D
IN
o
.2
V
2
:P
C
l
i
s
t
IBl I
t
oS
l
.S2
V2・P
C
l
i
s
t
V
2
:P
C
l
i
s
t
IBl I(
SI
.
Gll I
t
oSl，S2
IB2 I
t
oSJ，S2
IB2I
一
B
1
:f
O/
warding
里E
l
J
1
1
a;
f
j
一-一
一今必一一
pb一一
一
- q，h一一
m
-oa--
2
一一
一G
B
2
:f
o
r
w
a
r
d
i
n
g
(
a
)
(
c
)
(
b
)
国 5 BalancerPC障害時の動作例
Fig.5 Anexampleoff
a
i
l
o
v
e
rwhenabalanc
巴rPCi
sg日ttingdown.
B
a
l
a
n
c
e
rPCに障害が発生すると， BranchingPC
は一時的に J
o
i
nパケットを受信できない状態になる.
o
i
nパケットがタイムアウトするまでに B
a
l
しかし， J
(
図 5
(
c
)
)
. この間， 2台の BranchingPCB1，B2は
，
中断することなく配信を行うことができる.
a
n
c
e
rPCが切り換わり，次の J
o
i
nパケットが到着す
4.3.5 BalancerjBra
恥 h
i
時 PC
ここまで， B
a
l
a
n
c
e
r
、PCと B
ranchingPCを異なる
o
i
nパケッ
れば，配信が中断することはない.最後の J
PCとして説明したが，同 -PCに両方の機能を実装し
o
i
nパケットを受
トを受信してから，障害回復後に J
でも構わない.また，そのようにすることによって，装
信するまでの時間は，次の時間の総和となる.障害発
置数を削減することができる.本項では，両機能をもっ
生前最後の J
o
i
nパケットを受信してから障害が発生
PCによって構成された Branchingルータシステムに
ついて説明する(iElO) 以降， B
a
l
a
n
c
e
rPCと Branch-
e
e
p
a
l
i
v
eを送信
するまでの時間， VRRP切換時間， K
o
i
nパケットが届くまでの時
するまでの時間，次の J
o
i
nパ
間.よって，次の不等式が満たされるときには J
， B
a
l
a
n
c
e
rjBranching
i
n
gPCの両機能をもっ PCを
PCと表記することにする.
ケットカfタイムアウトすることはなく，ルータシステ
負荷分散メカニズ、ムは，機能を分担した場合と同じ
である. VRRPによりマスターとなっている PCは
，
ムとしては無瞬断で切換を行うことができる.
(
3
)
:
;T
TVTTP 十 h e叩 +2I
join :
join
各 PCから K
e
e
p
a
l
i
v
eを受信し，担当 PC表に記録す
e
e
p
a
l
i
v
eを受信し，
る.このとき，悶 -PCからも K
ここで，T
VRRP切換時間(注 g)，T
o
i
n
join は J
VTTP は
o
i
nパケット
担当 PC表に記録する.母ルータから J
タイムアウト時間である. K
e
e
p
a
l
i
v
eと同様に，Ijoin <
を受信すると，担当 PCを選択し，転送する.
l
続いて，障害発生時の動作を説明する . おa
Tjoin である.
る場合がある.このとき，要求元で、パケット重複が発
a
n
c
e
rjBranching PC に障害が発生すると，まず，
VRRPによってマスター PCが切り換わる . 続い
生する. B
a
l
a
n
c
e
rPC間で担当 PC表を同期しておく
て
， K
e
e
p
a
l
i
v
eによって担当 PC表への登録が行われ，
ことで，この重複を避けることができる.
J
o
i
nの振分けが開始される.このため，障害発生チャ
なお，切換の前後で担当 B
ranchingPCが変更され
図 5に B
a
l
a
n
c
e
rPCV1が障害に見舞われた例を
示す.障害発生後しばらくすると， VRRPによって
B
a
l
a
n
c
e
rPCV2がマスターに切り換わる(図 5
(
a
)
)
.
ネルの配信停止時間は，次の不等式で表される.
TV
p
T7"
<D <T
VTTP
+heep十 Ijoin
(
4
)
すると，母ルータ M は V2へと J
o
i
nパケットを転
なお，非障害発生チャネルへの配信は，式(~))が満た
S
lぅ Gl)への
送するようになる. V2は，チャネル (
されている眠り中断しない.
J
O
i
l
lパケットを受信し，新担当を選択する.ここでは，
BranchingPCB1を選択したとする.すると， J
o
i
n
パケットを B1へと転送する(国 5(
b
)
).同様にして，
S
2 G2)への J
o
i
nパケ
チャネル (
う
y
トを受信すると，
o
i
nパケットを転送する
新担当として B2を選択し， J
2
8
0
(
注9
):I
i
i
:
主
管dこは， VRRP切;奥I
時t
I
¥
J
は A
dvertisenwnti
イ
きη
r
m
l雨と p
r
i
o
r
i
t
yによって決定される [
2
4
J
. しかし，通常，切換 H~irl\Jの似は約 l 秒、
と小さいため，ここでは単純に TV1'1'TJ とJ
4す.
U
t
l
o
):通常， Join 処 J~tfft 1
苛は S
trea
.m 綾製処政に比べて圧倒的に小
さいと二予想されるため. Bra
.n
chingP Cに Balancer機能を追加して
t
r
e
a
r
n品質への彩響は非常に小さいと J
号えられる.
も
， S
論文 /
Flexcastによる段階的導入に優れたマルチキャストシステムの設計と実装
{oS1，S2
t
oS
1，S2
t
oS
1，S2
円v
a
r
d
i
n
g
B1:fo
t
a
b
l
e
￨岳1.011 L
1
B1(
m
a
s
t
c
r
)L 一一一一一一」
B
2
:P
C
l
i
s
t
耳l
B2(b
叫 up)L
上一一」
B2(mas
，
e
t
e
r
]
I
"
"
B
"
'
2
-l
1
_ _
'
国一
B
2
:P
C
l
i
s
t
B
2
:f
o
n
v
a
r
d
i
n
g
t
a
b
l
e
1S2.021L2
ω2，02)I
B
2
.
'f
0
1
w
a
r
d
i
n
g
)
80
(
(
a
)
堅E
(
c
)
l
i
I6 B
a
l
a
n
c
e
r
/
B
r
a
n
c
h
i
n
gPC障害時の動作例
F
i
g6 Ane
x
a
m
p
l
eo
ff
a
i
l
o
v
e
rwhenab
a
l
a
n
c
e
r
/
b
r
a
n
c
h
i
n
gPCi
sg
e
t
t
i
n
gd
o
w
n
.
，
G
ancerjBranchingPCB1がマスターとなり，担当 PC
QU
a
)は，障害が発生する前の様子である . B
a
l
図 6(
s
r
e
v
-
、till--siLIfts-19J
図 6の例を用いて，障害発生時の動作を説明する.
Rootr
o
u
t
e
rsystem
表を管理している. B1がチャネル (
8
1，G1)を担当し，
BalancerjBranchingPCB2がチャネル (
8
2 G2)を
う
担当している.ここで， B1に障害が発生したとする.
すると， VRRPによって B2カfマスターになる. B2
r
o
u
t
e
r
は B2自身に K
eepaliveパケットを送イ言し，十旦当 PC
表に登録する(図 6(
b
)
).続いて，母ルータ M から
(
8
1 G1)ーへの J
o
i
nパケットを受信すると，唯一の候
ぅ
8
2
補である B2を担当として選択する.同様にして， (
う
G2)への J
o
i
nパケットも処理される(国 6
(
c
)
)
.こ
図 7R
o
o
tルータシステム構成例
F
i
g
.
7 Ane
x
a
m
p
l
eo
fr
o
o
tr
o
u
t
e
rs
y
s
t
e
m
.
8
1 G1)は，担
のように，障害発生チャネルである (
う
当が変更された後に，配信が再開される.また，非障
8
2、G
2)では，中断なく配信が続け
害発生チャネル (
られる.
のように， RootPCと同一セグメントにサーバを設
4
.3
.6 Branchingルータ構成のまとめ
alancerPCは J
o
i
nを RootPCに振り分
置する. B
このように，クラスタシステムによって，スケーラ
o
i
nパケットを受信した RootPCは，サーバ
ける. J
ピリティと可用性に優れた Branchingルータシステム
u
l
t
i
c
a
s
tパケットを streamパケット
が送出する IPm
を実現することができる.更に，母ルータを冗長化す
にカプセル化し，下流へと転送する.その他の動作メ
ることで，このルータシステムは単一故障点をもたな
カニズムは， Branchingルータシステムとほぼ同じで
くなる.
ある.
母ルータへの要求条件は， PCクラスタの接続とそ
間 8に L
eafルータシステムの構成例を示す. Leaf
o
i
n，Pruneパケットの転送設定
れに伴う経路通知， J
ルータシステムの冗長化は， IGMPjMLDによって
である.なお， BranchingPCは母ルータ以外の装置
行われる.冗長化の基本原理は VRRPとほぼ同じで
に接続することができる.例えば，母ルータの転送能
あるため，ここでは省略する.負荷分散は， IGMP
力が低いときには，隣接する高性能スイッチに接続し
snooping[
9
]のようなデータリンク層のメカニズムに
でもよい.
よって行う
IGMPsnoopingでは， IGMPReportの
4.4 Rootルータシステム， Leafルータシステム
傍聴機能をもっスイッチを用いることで， IPm
u
l
t
i
c
a
s
t
Rootルータシステムの構成は， Branchingルータ
パケットの伝搬範囲を制限することができる.
システムとほぼ閉じである.図 7に構成例を示す.図
なお，遠隔会議のように双方向でマルチキャスト
2
8
1
電子情報通信学会論文誌 2
0
0
5
/
2Vol
.J
8
8
心1No.2
S
一
﹁トム寸﹂刀
Gア一り
n
一色一一 n
⋮⋮一
M
一v
n
r
〆S
、
町
EE'i
Ll
Cl(
I
GMPv2)
(
b
)
(
a
)
図 8 Leafルータシステム構成例
Fig.8 Anexampleo
fl
e
a
froutersystem.
5
iuv
C2
d
L2
'sl
q
'
M
B
C3
d'PJPLhC
Leafr
o
u
t
e
rsystem，
d
z
川
口
，
， --j
J
，
、d
，a
，
Bl
FLJXG
・
‘
，
，
〆
，
p
R
S
毘 9 グループ管理システム動作例
Fig.9 Anexampleofgroupmanagement.
m
u
l
t
i
c
a
s
tパケットが Leafルータに届くと， Leafルー
を行うときには， Rootルータと L
eafルータを同一
タは送信元アドレスからサーバアドレスを取得する.
eaf
母ルータに接続する.このとき， Rootルータと L
eafルータはサー
トラヒックがしきい値を超えると， L
j
レータの機能を向。
PCに実装しでもよい.
5
. グループ管理システムの設計
5
.
1 IGMP/MLD後方互換性
2.2で述べたように， F
l
e
x
c
a
s
tでは，クライアン
o
i
nパケットを送イ言し，サーバを担とする
バあてに J
配信木へと切り換える.このように， P1M-8Mはメカ
ニズムが複雑で、あり，また r
endezvousp
o
i
n
tにトラ
ヒツクが集中するという課題もある
[
2
]
.
一方， URLr
endezvousd
i
r
e
c
t
o
r
yは
，
wwwサー
ト管理プロトコルに 1GMPv3/MLDv2を用いること
バを設置し，そこにチャネルを品元管理する方式であ
を前提としている.これは，クライアントが送出する
る.クライアントは， Reportを送信する前に
Reportによって 88Mチャネルを特定するためである.
サーバに HTTPリクエストを送信する.このリクエス
しかし，現在はまだ 1GMPv1ヲ2jMLDv1を実装した
トには，グループアドレスが含まれる . W W Wサーバ
クライアントが多く存在する. 1GMPv1ぅ2jMLDv1は
は，グループアドレスに対応するサーバアドレスを検
グループアドレスのみを特定するプロトコルであり，
索し，そのサーバアドレスを含む URLへの再リクエ
F
l
e
x
c
a
s
tが用いている 88Mチャネルを特定するため
ストを促す.そして，クライアントは指示された URL
には，サーバアドレスを追加するメカニズムが必要と
へアクセスを試みる.ここで
なる.本節では，グループアドレスをチャネルへと変
セスを傍聴し， URLに含まれるサーバアドレスを記憶
換する方式について議論を行う.
する.その後，クライアントが Reportを送信すると，
www
Leafルータはこのアク
1Pm
u
l
t
i
c
a
s
tでは，この課題を解決するために二つ
Leafルータは記憶したサーバへと J
o
i
nパケットを送
endezvousp
o
i
n
t
の解決策を提案している.一つは， r
endezvousd
i
r
e
c
t
o
r
yは
， r
endezvous
信する. URLr
と呼ばれる仮想サーバを用いる方法である.この方法
p
o
i
n
t方式に比べシンプルであるが，クライアントに
1
8
] として標準化されている.もう」つ
は P1M-8M[
URLrendezvousd
i
r
e
c
t
o
r
yの実装を要求する.
endezvousd
i
r
e
c
t
o
r
y[
3
7
] と呼ばれる方法
は
， URLr
である.
P1M-8Mは次のように動作する. Leafルータは Re-
本節では，それぞれの方式の課題を解決するシンプル
なグループ管理方式を提案する.提案方式では， URL
rendezvousd
i
r
e
c
t
o
r
yと同 j
長に，チャネルを
www
wwwサーバをグルー
o
i
n
tあてに J
o
i
nパ
p
o
r
tを受信すると， rendezvousp
サーバに '
J
C管理する.この
ケットを送信する.そして， r
ende1';vousp
o
i
n
tを根と
g
r
o
u
pmanagements
e
r
v
e
r
) と1
1
乎ぶ.
プ管理サーバ (
する配信木を構築する.一方， Rootルータは，サー
Lea
.
fルータは， 1GMPv1ス
jMLDv1Reportを受信す
u
l
t
i
c
a
s
tパケットを，ユニキャ
バから送出された IPm
ると，グループ管理サーバにグループアドレスを送信
ストパケットにカプセル化し， r
ende1';vousp
o
i
n
tへと
し，片)忘するチャネルを問い合わせる.
i
2S:信ーする.このようにして，サーノてとクライアントは
~9 に示す例を用いて提案方式の動作を説明する.
Hには，チャネル (
8G
)が登録
rendezvousp
o
i
n
tで出会い， rendezvousp
o
i
n
tを根
グループ管]里サーバ
とする目白言木によって配信が開始される.その後， 1P
されている. Le
a
.
fルータ L1には， H のアドレスが設
2
8
2
う
論文 /
Flexcastによる段階的導入に優れたマルチキャストシステムの設計と
定されている.そして， Llはクライアント Clから
を用いることが要求される. IGMPvl，
2/MLDvlか
Reportを受信すると，グループアドレス G に対応す
らの過j
度期においては，グループアドレスのー意性保
るサーバアドレスを H に問い合わせる . Hは Llに S
証は，避けて通れない問題である.
を返す. Llは Sあてに J
oinパケットを送出する.こ
ループ管理方式と F
l
e
x
c
a
s
tを組み合わせることで，グ
:，通常の Flexcastと同様に動作する.
こから先 U
ループアドレスの一意性に関する条件を緩和すること
グループ管理サーバに登録されているチャネルには
m
T節で提案したグ
ができる.本節では，この理由を説明する.
有効期限が設定されており，期限を過ぎたグループア
理解を容易にするために，次のようなシナリオを想
ドレスは再利用可能である.また，グループ管理サー
定して説明を行う.マルチキャストネットワークを提
バから取得したチャネルにも有効期限が設定されてい
供するあるネットワーク事業者と，その顧客を考える.
るため，期限中の再問合せは不要である.提案方式に
顧客は，例えば，契約者に放送サービスを提供する二
は
， rendezvousp
o
i
n
tのようなトラヒック集中点はな
次プロパイダや，社内向けに遠隔会議や遠隔教育を行
く，クライアントは IGMP/MLDのみを実装すれば
う企業である.ネットワーク事業者は Branchingルー
よい.なお，グループ管理サーバの冗長化については，
タを運用し，顧客は Rootルータ， Leafルータを運用
一般の
wwwサーノ T可用性向上方式を利用すること
ができる
[
6
]
.
する.
ここで，マルチキャストネットワークを PIM-SMに
最後に，表 2 に 3方式をまとめる.比較項目は，追
lexcastを用いる場合とを比
よって運用する場合と， F
a
d
d
i
t
i
o
n
a
lnode)，トラヒック集中 (
t
r
a
伍C
加装置 (
l
e
x
c
a
s
tを用いる場合は，各顧客がグループ
較する. F
c
o
n
c
e
n
t
r
a
t
i
o
n
)，クライアントへの追加要求 (
r
e
q
u
i
r
e
-
管理サーバを設置する.なお，顧客間でユニキャスト
mentsf
o
rc
l
i
e
n
t
s
) とした.
アドレスの重援はないとする.
5.2 グループアドレス管玉里に関するスケーラビリ
PIMS Mによってマルチキャストネットワークを運
同
用する場合，顧客開でグループアドレスが重複しない
アイ
ー
ー
骨
支
に
， IPm
u
l
t
i
c
a
s
tでは，グループアドレスをネッ
ように調整する必要がある.同一グループアドレスを
トワーク全体で一意に保つ必要がある. SSMチャネル
使うと，異なる顧客のネットワークにパケットが混入
を用いることでこの課題を解決することが可能で、ある
する可能性がある.これは， PIM-SMではグループア
が，クライアント管理プロトコルに IGMPv3/MLDv2
ドレスのみで配信木を特定することがあるためである.
表 2 IGMP/MLD後方互換方式比較
T
a
b
l
e2 Comparisono
ft
r
a
n
s
l
a
t
i
o
nm
e
t
h
o
d
s
.
A
d
d
i
t
i
o
n
a
ln
o
d
e
T岡田 cc
o
n
c
e
n
t
r
a
t
i
o
n R
e
q
u
i
r
e
m
e
n
t
sf
o
rc
l
i
e
n
t
s
T旨a
n
s
l
a
t
i
o
nmethod
R
e
n
d
z
v
o
u
sp
o
i
n
t
No
Y
e
s
R
e
n
d
e
z
v
o
u
sp
o
i
n
t
W W Ws
e
r
v
e
r
URLr
e
n
d
e
z
v
o
u
sd
i
r
e
c
t
o
r
y
No
URLr
e
n
d
e
z
v
o
u
sd
i
r
e
c
t
o
r
y
Groupmanagements
e
r
v
e
r
No
No
Ourp
r
o
p
o
s
a
l
Rx戸r
w
a
r
d
i
n
g
CUS10merX
げ y，
Gs
I
HvLJ
，
，
_
Gs
?
Dy
V
、
、、
、、
、、
ーム
(
S
y
.GS)""
Sy
Sx
Ry
RX
v
Cy
I
Sx，
Gs I
ト一一一一一一寸
'
'J
J
v
GS7y
，
，
t
匡
弘
R
y
.
・f
o
r
w
a
r
d
i
n
g
堅型
，
81:fonノαr
d
i
n
g
n
J
B2
ヲ
ー
E型
，'
/ '(
S
xG〓
82:fonvarding
".
f
t
f
αb
l
e
土Xl
CX1
CX1
堅E
図 10 グループアドレス管理の独立性
F
i
g
.10 I
n
d
e
p
e
n
d
e
n
c
eo
fg
r
o
u
pm
a
n
a
g
e
m
e
n
t
.
2
8
3
電子情報通信学会論文誌 2
005/2Vol
.J88-D-IN
o
.2
一方， F
l
e
x
c
a
s
tによってマルチキャストネットワー
クを運用している場合，グループアドレスは顧客内で
表3F
l
e
x
c
a
s
tルータ機能及び負荷分散機能開発環境
T
a
b
l
e3 D
e
v
e
l
o
p
m
e
n
te
n
v
i
r
o
n
m
e
n
to
fF
l
e
x
c
a
s
t
r
o
u
t
e
r
sa
n
dl
o
a
db
a
l
a
n
c
i
n
gs
o
f
t
w
a
r
e
s
一意であればよい.これは， F
l
e
x
c
a
s
tルータは常に
L
a
n
g
u
a
g
e
C
o
m
p
i
l
e
r
O
p
e
r
a
t
i
n
gs
y
s
t
e
m
L
i
n
u
xk
e
r
n
e
l
チャネルによって配信木を特定するためである.
例えば，函 10のように，顧客 X，Y が F
l
e
x
c
a
s
tに
C十十
g
c
c3
.
2
.
2
RedHatL
i
n
u
x9
2.
4.
2
0
よるマルチキャストサービスを受けているネットワー
クを考える.ネットワーク事業者は Branchingルー
表 4 グループ管理サーパ開発環境
タ B1，B2を提供している.顧客 X は
， Rootルータ
T
a
b
l
e4 D巴v
e
l
o
p
m
e
n
te
n
v
i
r
o
n
m
e
n
to
fg
r
o
u
p
l
n
a
n
a
g
e
l
n
e
n
ts
e
r
v
e
r
.
Rx，Leafルータ LXl' LX2，サーバ Sx，クライアン
L
a
n
g
u
a
g
e
Ja
v
a
™ Servletserver
D
a
t
a
b
a
s
es
e
r
v
e
r
O
p
e
r
a
t
i
n
gs
y
s
t
e
m
L
i
n
u
xk
e
r
n
e
l
ト CXl，CX2，グループ管理サーバ Hxを運用してい
る.同様に，顧客 Y は
， Rootルータ Ry，Leafルー
タ Ly，サーバ Sy，クライアント Cy，グループ管理
サーパ Hy を運用している.ここで，顧客 X，Y が共
Ja
v
a
™1
.4
.
1
t
o
m
c
a
t4
.1
.1
8
p
o
s
t
g
r巴SQL7
.
3
.
1
RedHatL
i
n
u
x9
4.
2
0
2.
通するグループアドレス Gs を利用しているとする.
CXl と Cyはグループアドレス Gs に立すして Report
を送信する.このとき，それぞれのグループ管理サー
Groupmanagement
s
e
r
v
e
r
s
e
r
v
e
r
Dummyroot
バは， GSに対応するチャネルとして， (Sx，GS)
，(Sy，
Gs)を返す. B1，B2は別々のチャネルとして認識し，
顧客開でパケットが混入することはない.
l
e
x
c
a
s
t
このように，提案するグループ管理方式と F
を組み合わせることにより，グループアドレス管理を
顧客ごとに独立して行うことができる.ネットワーク
全体で一意性を管理する場合に比べ，管理が容易にな
り，スケーラピリテイの向上が期待できる.
6
. 実装と評価
4
. で、述べた設計方針に従って， F
l
e
x
c
a
s
tルータを
実装し， Branchingルータシステムの転送能力と障害
発生時の切換時間を測定した.また， 5
. で提案した
Dm
闘 1
1 B
r
a
n
c
h
i
n
gルータシステム評価笑験ネットワーク
F
i
g
.1
1 E
x
p
e
r
i
m
e
n
t
a
ln
e
t
w
o
r
k
sf
o
rb
r
a
n
c
h
i
n
gr
o
u
t
e
r
s
y
s
t
e
me
v
a
l
u
a
t
i
o
n
.
グループ管理システムによって，後方互換性が確保さ
れていること，顧客間で共通するグループアドレスを
利用できることを確認した.
た.本論文では， IPv4で行った実験について述べる.
6
.2 BranchingルータシステムI
'
'
i
書
民
平
{
面
6
.1 Flexcastルータの実装
6.2.1 実験ネットワーク
Flexcastルータ機能と負荷分散機能を， Linux上で
園 1
1に
， Branchingルータシステム評価実験を
動作するユーザ空間ソフトウェアとして実装した.実
行ったネットワークトポロジーを示す.サーバ，ク
装言語は C十十である.負荷分散アルゴリズムはラウ
ライアントには， Kubotek 相[~ MPEG-2Transport
ンドロビンとした.なお， Rootルータと Leafルータ
いた. Bra
恥 h
ingルータシステムへの
Stream[
4
5
]を月3
は，同一ソフトウェアとして実装した.ソフトウェア
負荷を増やすために， 1:疑似的な Rootルータ (dummy
開発環境を表 3に示す.
e
a
f
) を作成
r
o
o
t
) と擬似的な Leafルータ (dummyl
. で提案したグルーフ。管理サーバを， Java™
また， 5
した.
S
e
r
v
l
e
t技術 [
4
2
]を用いて実装した.データベースに
擬似 Rootは
， Rootルータと同様に転送表を管恕
は
， postgreSQL[
4
8
]を用いた.開発環境を表 4 に
する.また，指定されたピットレートで IPm
u
l
t
i
c
a
s
t
示す.
パケットを生成し， Streamパケットにカプセル化し
すべてのソフトウェアは， IPv4/6両方の実装を行つ
2
8
4
て送出することができる.生成する IPm
u
l
t
i
c
a
s
tパ
論文/Flexcastによる段階的導入に優れたマルチキャストシステムの設計と実装
ケットは 1，
456バイトとした.生成ピットレートにつ
6.2.2 転送能力評価
いては後述する.擬制、 Rootは 1台で複数のチャネル
送受信ビットレートやチャネル数を変化させて実験
を送信することができ，多くのサーバが存在する状況
を行い， Branchingルータシステムの転送能力を評価
を再現することができる.
した.また， Bala配 erjBranchingP Cの数を変化さ
擬似、 Leafは，指定されたチャネルに対し， Joinパ
せ，ルータシステムの拡張性についても評価を行った.
0秒間隔で Streamパケッ
ケットを送信する.また， 1
MPEG-2サーバと擬似 Rootの送信ピットレート
トの受信ピットレートを記録する.実験では， 1台の
000kbitjsとした.それ
は
， 6ヲ184kbitjsあるいは 20，
P Cに複数の擬似 Leafを起動し，多くのクライアント
ぞれ， SD，H D規格の MPEG-2Transport Stream
が存在する状況を模擬した.
を想定している.なお， MPEG-2サーバ，クライア
図 11 に示すように，母ルータと 2 台の P C で
184kbitjsのときのみ
ントは，送信ピットレートが 6，
Branching ルータシステムを構成した . 2 台の P C
， 1台あるいは 2
用いた. BalancerjBranchingP Cは
には，どちらにも BalancerP C と BranchingP Cの
台とした.チャネル数は， 2あるいは 16である.チャ
4
4
]
両機能をインストールした. KeepalivedforLinux[
ネルごとの要求数が等しくなるように擬似 Leafを設
の VRRP機能によってお alancerjBranchingP Cの
定した.擬似、 Leaf数は結果グラフ中に示す.
冗長化を行った.母ルータには CiscoCatalyst 6500
次の手)
1買で、実験を行った.まず， Branchingルータ
を用いた(た 11) 指定されたポート番号に一致する UDP
システムと RootjLeafルータ， MPEG-2サーバ，擬
パケットを BalancerjBranchingP Cへと転送するよ
旬
、 Rootを起動する.その後， MPEG-2クライアント
， P C と母ルータの諸元
うに設定した.表 5，表 6に
を起動し，続いて擬似 Leafを起動する.すべての擬似
を示す.
Leafが受信を開始後，誌を似、 Leafでの受信ピットレー
図 11 のように， RootjLeafルータはクラスタ化を
行わなかった. MPEG-2サーバ，クライアントを除
トと BalancerjBranchingP Cの CPU使用率を観測
した.観測時間は 120秒間とした.
結果を図 12~ 図 15 に示す.図 12 は，送信ピット
き，すべて 1000Base-Tのインタフェースを備える.
t
疑似
MPEG-2サーバ，クライアントは 100Base-TXであ
レートを 6ぅ184kbitjs としたときに，
Leafで測
る.実験パラメータを表 7にまとめる.
定した受信ピットレート平均値である.横軸は，擬
似 Leafと MPEG-2 クライアントが要求するピット
レートの総和である.以降，総要求ピットレートと
表 5 Ba1加 c
e
r/BranchingPC諸元
Tab1e5 S
p
e
c
i
f
i
c
a
t
i
o
no
fba1ancer/branchingPC.
#o
f
l
e
a
v
e
s(
l
e
a
fr
o
u
t
e
randdummyl
e
a
v
e
s
)
1
0
0
2
0
0
3
0
0
4
0
0
面
噌
i
00
4
ho
10s
30s
1s
4s
4s
官。“
J
o
i
ni
n
t
e
r
v
a
1Ijoin
J
o
i
ntimeoutTjoin
Keepalivei
n
t
e
r
v
a
1Ikeep
巴p
a
l
i
v
etimeoutTkeep
Ke
:
匂 rrp
VRRPf
a
i
l
o
v
e
rtimeT
﹄ 5
3 吋2
ugE︿
表 7 実験パラメータ
Tab1e7 Parametersi
nt
h巴 e
x
p
e
r
i
m
e
n
t
s
.
日u i b i - - n v
内u n u n v A U A U
AUAUAVAU
AUAUAUAU
Backplane
32Gbit/ssharedbus
NetworkI
n
t
e
r
f
a
c
e 1000Base-Tx48
OperatingSys
七em IOS ™ 1
2
.
2
auaUA
表 6 母ルータ諸元
p
e
c
i
f
i
c
a
t
i
o
no
fmotherr
o
u
t
er
.
Table6 S
り，総要求ピットレートが 800Mbitjs以下の領域で
{田仏門戸当﹄岡田二時
I
n
t
e
1X巴on™ 3
.
0
6GHzx1
512M BDDRPC-21000ECCReg.x2
Memory
Motherboard SupermicroX5DPE-G2
Chipset
I
n
t
e
1E7501c
h
i
p
s
e
t
PCIbus
PCI-X64b
i
t
/
1
0
0MHz
I
n
t
e
1PRO/1000MTS
e
r
v
e
rAdapter
NIC
CPU
呼ぶ.上側の横軸に，対応する分岐数を示す.図よ
苫\一可~
1PC，
2c
h
a
n
n
e
1
s →
←
1PC，1
6c
h
a
n
n
e
l
s←
2PCs，
2c
h
a
n
n
e
l
s →D2PCs，
1
6c
h
a
n
n
e
l
s寸&ー
5
0
0
1
0
0
0
1
5
0
0
2
0
0
0
T
o
t
a
lr
e
q
u
e
s
tr
a
t
e[
M
b
p
s
l
2
5
0
0
図 1
2 Branchingルータシステム転送能力評価(送信ピッ
トレート 6，
184k
b
i
t
/
s
)
F
i
g
.1
2 Eva1uating forwarding a
b
i
l
i
t
yo
fbranching
r
o
u
t
e
rsystem(datar
a
t
e
: 6，
1
8
4
k
b
i
t
/
s
)
.
(
j
.
主 11) :C
i
s
c
oC
a
t
a
l
y
s
t6
5
0
0以外にも， C
i
s
c
o7
2
0
0，FoundaryB
i
r
a
n
c
h
i
n
gルータシステムを構成で
g
I
r
o
n4
0
0
0を用いて実験を行い， B
きることを確認している.
285
電子情報通信学会論文誌 2005/2Vol
.J88-D-INo.2
AU
AUAUnUAvnv
1i
08642
[邑 AUSHA芯申出吋由ロロ仏。
#o
f
l
e
a
v
e
s(
l
e
a
f
r
o
u
t
e
randdummyl
e
a
v
e
s
)
100
200
300
4
0
1
0
一
一
一
一
一
一
一
円
「
1PC，
2c
h
a
n
n
β
l
s →
←
1PC，
1
6c
h
a
n
n
e
l
s ート
2PCs，
2c
h
a
n
n
e
l
s 寸Qト
2PCs，1
6c
h
a
n
n
e
l
s寸ト
求にこたえられていることが分かる.図中の矢印は，
BalancerjBranchingP Cを 2台，チャネル数を 16 と
したときに， MPEG-2 クライアントカ勺まとんど乱れ
なく映像を再生できた領域である.なお，チャネル数
の変化に対しては，有意な差は見られなかった.
国 13 は，送信ピットレートが 6，
184kbitjsのとき
に
， BalancerjBranching P C-C:測定した C P U使用
品
。
。
(
J
)
1000
1500
2000
T
o
t
a
lr
e
q
u
e
s
tr
a
t
e[
l
¥
在b
p
s
]
2500
図 13 Balancer/BranchingPCCPU使用率(送信ピッ
トレート 6，
184k
b
i
t
/
s
)
F
i
g
.13 CPUusag
巴乱tb
alancer/branchingPC (data
184k
b
i
t
/
s
)
.
r
a
t
e
: 6，
率である. 2台の BalancerjBranchingP C を用いた
ときには， VRRPによってマスタとなっている P Cを
測定した.横軸は国 12 と同じである.総要求ピット
レートが増加するにつれて C P U使用率は上昇するが，
約 30~40% で飽和している.このときの総要求ピット
レートは，図 12 において要求にこたえられなくなっ
#o
f
l
e
a
v
e
s(
l
e
a
fr
o
u
t
e
randdummyl
e
a
v
e
s
)
50
~25000~
A
クは Ethernetや P C内部パス等， C P U以外に存在し
国 ¥ トザ又一
当
官2
0000
たピットレートと一致している.つまり，ボトルネッ
1
0
0
… 婦
(
J
)
，
.
.
.
315000
，
.
.
.
ていたと考えられる.なお，チャネル数の増加に伴っ
て
， C P U使用率が増加しているが，これは，入力ト
ラヒツクが増加するためであると考えられる.
吋
』
h
a
n
n
e
l
s →
←
1PC，2c
1PC，
1
6c
h
a
n
n
e
l
s ート
2c
h
a
n
n
e
l
s 斗〉
5000 2PCs，
2PCs，
1
6c
h
a
n
n
e
l
s~企ー
ω10000
。
〉
U
~
U
:
>
〈
500
000kbitjsのとき
国 14は，送信ピットレートが 20，
の擬似 Leaf受信ピットレートである.送信ピットレー
1000
1
5
0
0
2000
s
]
T
o
t
a
lr
e
q
u
e
s
tr
a
t
e[Mbp
2500
トを 6ぅ184kbitjs としたときと，同様の傾向を示して
いる.
図 14 Branchingルータシステム転j
芸能力評価(送信ビッ
トレート 20，
000k
b
i
t
/
s
)
b
i
l
i
t
yo
f branching
Fig.14 Evaluating forwarding a
000kbit/s).
r
o
u
t
e
rsystem(datar
a
t
e
: 20，
図 15 は，同じ送信ピットレートにおける BalancerjBranching P C の C P U使用率である . 送信
ピットレートが 6，
184kbitjsのときと比べて C P U使
用率がやや高くなっているのは，入力トラヒックが増
AUAUA
日リハ
5o
加したためと考えられる.
100
1PC，
2c
h
a
n
n
e
l
s
1PC，
1
6c
h
a
n
n
e
l
s
2PCs，
2c
h
a
n
n
e
l
s
→
←
以上の結果より， P C クラスタによって構成した
ート
Branchingルータシステムは， Gbitjs レベルの高い
-0ー
〆ノ~I 2PCs，16channels-A-
り
転送能力を実現できることが分かった.更に，需要に
合わせて P Cを追加し，ルータシステムとしての転送
AUAUA
能力を向上可能で、あることも明らかになった.
6.2.3 障害切換性能評価
り
ED 認申切出山山口口門同0.@﹀︿
0
8642
1i
口
{求].ぷ U
#o
f
l
e
a
v
e
s(
l
巴a
f
r
o
u
t
e
randdummyl
e
a
v
e
s
)
U
500
1000
1500
2000
T
o
t
a
lr
e
q
u
e
s
tr
a
t
e[
M
b
p
s
]
2500
図 1
5 Balancer/BranchingPCCPU使用率(送信ビツ
トレート 20ぅ000k
b
i
t
/
s
)
Fig.15 CPUusagea
tbalancer/branchingPC(data
O
O
k
b
i
t
/
s
)
.
r
a
t
e
: 20O
ヲ
本項では， Branchingルータシステムの障害切換性
能について述べる.前項と同様，図 1
1 に示すネット
ワークを用い，実験を行った.
1前項と同じ手 JII~ で各装置を起動する.障害切換を行
うため， BalancerjBranchingP C を 2 台とも起動し
ておく.その後，マスター P Cのネットワークケーブル
は，受信ピットレートが送信ピットレートに等しいこ
を抜き， BalancerjBranchingP Cの開害を模擬した.
とが分かる.このことは， Branchingルータシステム
そして， t
疑似 Leafで配信中断時間を観測し，障害切
が，全要求にこたえられていることを意味している.
換性能を評価する.送信ピットレートを 6，
184kbitjs，
また， BalancerjBranchingP C を 1台としたときに
チャネル数を 16，総要求ピットレートを約 294Mbitjs
比べ， 2台にしたときは約 2 倍
， 1500Mbitjsの要
とした.擬似 Leaf数は 48であり，そのうち半数が障
う
286
論文 /Flexcastによる段階的導入に優れたマルチキャストシステムの設計‘と実装
30
AVAVAV
21
・u
u
ASS- 口注OQ
ilO
1
0
20
J
o
i
ni
n
t巴r
v
a
l[
s
e
c
.
]
3
0
決
￨j1
6 自
己
信
仁j
1
t
析時間
Fig.16 Downt
i
m
e
.
害発生チャネルを受信する.
Join送信間隔
l]oin
を 5，1
0，20秒と変化させ，そ
れぞれ 2 間ずつ測定を行った. Joinタイムアウト時間
Tjoin は，Join 送信間隔ん o~n の 3 倍とした.その他
のパラメータは表 7 と同じである.
CustomerX
CustomerY
国 17 グループ管理システム評価実験ネットワーク
F
i
g
.17 Experimentalnetworksf
o
rgroup
managernents
y
s
t
e
r
ne
v
a
l
u
a
t
i
o
n
.
図 1
6 に結果を示す.横軸は Join送信間隔ん 01-n，
縦軸は障害発生チャネルの配信中断時間である.グラ
フ中の点は中断時間の平均値を表し，誤差棒は最大値
と最小値を表す.淡い太線は，式 (
4
)から予想、される
中断時間である.グラフより，おおむね予想時間内に
#server
group
c
h
i
l
d
.1 1
92.168.204.253:1025
1
9
2
.
1
6
8
.
2
0
0
.
1 2
3
9
.
1
9
2
.1
.1 1
9
2
.
1
6
8
.
2
0
3
.
2
5
3
:1027
192.168.205.10 2
3
9
.
1
9
2
.1
図 18 Branchingルータ転送表
F
i
g
.1
8 Forwardingt
a
b
l
eonthebranchingrouter
.
配信が再開されていることが分かる.予想時間をわず
かに超えているのは， A R Pキャッシュ更新処理や Join
管理システムの評価が目的であるため， Flexcastルー
パケット送受信処理，伝送遅延等の影響と考えられる.
タのクラスタイヒは行二わなヵ、った.
3
)が満たされていたため，非障
なお，本実験では式 (
6.3.2 評価結果
害発生チャネルが中断することはなかった.
前項で述べたシナリオに従い，グループ管理システ
以上の結果から， Branchingルータシステムは高い
可用性をもつことが示された.
ムの評価実験を行った.それぞれのグループ管理サー
バに，共通のグループアドレスをもっチャネルを登録
6.3 グループ管理システム評価
しておく.そして，両顧客のクライアントが，それぞ
6.3.1 実E
東ネットワーク
れ要求した映像を再生できることを確認する.
7に，グループ管理システムの評価実験を行った
図1
ul実験の結果，それぞれのクライアントでは， IPm
ネットワークトポロジーを示す.この実験ネットワー
ticastパケットが混ざり合うこともなく，要求した映像
クは，次のようなシナリオを想定して構築されている.
を再生することができた.このとき， Branching)レー
あるネットワーク事業者が， Flexcastを用いてマルチ
タの転送表を見てみると，共通のグループアドレスを
キャストネットワークサーピスを提供している. 2組
もっチャネルが別のエントリとして扱われていること
の顧客 X，Y はネットワーク事業者と契約し，マルチ
が分かる(臨 1
8
).なお，図中の child とは，要求元
キャストネットワークを用いて映像配信を行う.顧客
のことである.
は IGMPv2 クライアントを用いるため，グループ管
このように，提案するグループ管理方式と Flexcast
理サーバを設置し，グループアドレスを SSMチャネ
を組み合わせることにより，顧客間で共通するグルー
ルへと変換する.ここで，顧客 X，Y は，偶然にも共
プアドレスを用いることカすできる.グループアドレス
通するグループアドレスを用いることとなったとする.
管理にまつわるスケーラピリティ問題を大きく緩和で
顧客 X は，サーバ，クライアントとして 6.2で用
きることが明らかになった.
いた MPEG-2Transport Streamを用いた.顧客 Y
6
.4 Flexcast システムを用いたフィールド実験
は WindowsMedia[
4
9
]を利用した.なお，グループ
本論文では，実験室内に構築した比較的小規模な
287
電子情報通信学会論文誌 2
0
0
5
/
2Vol
.J
8
8
D
IN
o
.2
ネットワークでの実験結果を報告した.本節では，我々
合化はサーバとクライアントで行われる.このため，
がこれまで、に行ったニつのフィールド実験について簡
暗号化によるデータ保護は任意のマルチキャスト方式
単に説明する.
と組み合わせることができる.
l
e
x
c
a
s
tを用いた日米間遠隔会議実験であ
一つは， F
一方， IGAP (
I
n
t
e
r
n
e
t Group membership Au-
凶e
r
n
e
t
2[
4
1
]と GEMNetという
る.この実験では， 1
t
h
e
n
t
i
c
a
t
i
o
n P
r
o
t
o
c
o
l
) ，MLDA (
M
u
l
t
i
c
a
s
t L
i
s
こつの広域実験ネットワークを用い，地球規模の広域
t
e
n
e
r D
i
s
c
o
v
e
r
y A
u
t
h
e
n
t
i
c
a
t
i
o
n p
r
o
t
o
c
ol)は，
ネットワークでの配信が可能であることを確認した.
IGMPjMLDReportに認証情報を追加し， Leafルー
もう一つの実験では，研究開発用広帯域ネットワー
タで認証，課金を行う方式である [
2
2
]，[
2
3
]
. 我々は
ク JGN (
JapanG
i
g
a
b
i
tNetwork)[
4
3
]を用い，日本
Leafルータに IGAPを実装し，アクセス制御実験を
各地へのハイビジョン映像配信実験を行った.この実
l
e
x
c
a
s
tと連携可能であること
行った.実験の結果， F
験は， MPLSルータを用いた動的負荷分散方式 [
3
0
]の
を確認している.
実験と同時に行った.品費市Ij御方式と組み合わせるこ
とにより，ハイビジョンのような広帯域ストリームで
あっても広域配信可能であることを実証した.
l
e
x
c
a
s
tルータのクラスタ化
これらの実験では， F
司
8
. むすび
本論文では， F
l
e
x
c
a
s
tを用いたマルチキャストシス
テムの開発について議論を行った.
は行わず， 6.3 の実験のように 1台ずつの PCで
まず，マルチキャストサービスの現状を分析し，初
Flexcωtルータを構成した.なお，実験の詳細は文
期投資が大きいという課題に着目した.そして，その
献[
2
6
]，[
4
6
]う [
4
7
]を参照されたい.
原因の一つに IPm
u
l
t
i
c
a
s
tのアーキテクチャがあると
7
. 関連技術
考えた. I
Pm
u
l
t
i
c
a
s
tは，マルチキャスト機能をネッ
2.2で述べたように， F
l
e
x
c
a
s
tは信頼性やセキュ
チャは，対応ルータをネットワーク全体に展開するこ
リテイに関する機能をもたない.本章では，我々が開
とを要求する.そこで，マルチキャスト機能を上位層
発したシステムと連携可能で、あると考えられる信頼性
で実現している F
l
e
x
c
a
s
tを採用し，マルチキャストシ
マルチキャスト方式やアクセス制御方式を簡単に紹介
l
e
x
c
a
s
tは，対応ルー
ステムを開発することとした. F
する.
タを段階的に展開することが可能なマルチキャスト方
トワーク層で実現している.しかし，このアーキテク
7.1 信頼性マルチキャスト
式である.更に， End-systemm
u
l
t
i
c
a
s
tのようにト
D
i
g
i
t
a
lf
o
u
n
t
a
i
nアプローチ [
7
]は，誤り訂正符号に
ラヒック削減効果を犠牲にすることはなく， X
castの
よって信頼性を確保する方式である.ルータへの機能
追加は不要で、あり，任意のマルチキャスト方式と組み合
ように受信者数を制限することもない.
F
l
e
x
c
a
s
tルータの開発にあたっては， W W W検索
わせて利用することができる.我々は d
i
g
i
t
a
lf
o
u
n
t
a
i
n
システムや GRIDcomputingで大きな成果を挙げて
アプローチを実装したソニー社製 Magnacasts
e
r
v
e
r
いるクラスタシステムに注目した.運用中のルータあ
を用いて， F
l
e
x
c
a
s
tとの連携実験を行った.その結果，
るいはスイッチに小規模な PCクラスタを接続し，シ
d
i
g
i
t
a
lf
o
u
n
t
a
i
nアプローチによって， F
l
e
x
c
a
s
tに信
ステムとして F
l
e
x
c
a
s
tルータ機能を設計した.既存
頼性がもたらされることを確認している.また， 6.4
設備を有効利用し，開発コストや装置コストを抑える
で紹介したように，ルータによって実現される品質制
ことで，初期投資を抑えることが可能となった.また，
御方式と連携することも可能である.
クラスタシステムにより，高いスケーラピリティと可
TCP トラヒックと共存するためには，ふくそう制
用性を実現した.
御方式との連携も重要で、ある. WEBRC (Waveand
F
l
e
x
c
a
s
tは，クライアント管理プロトコルに
EquationBasedRateC
o
n
t
r
o
l
)は
， e
n
d
t
o
e
n
dでふ
IGMPv3jMLDv2を採用している.このため， IP
くそう制御を行う方式である [
2
7
]
. 連携実験は行って
m
u
l
t
i
c
a
s
t用に開発されたクライアントを利用し，
いないが， F
l
e
x
c
a
s
tとの相性は良いと考えている.
開発コストを抑制することができる.しかし，
7.2 セキュリティ
現在は IGMPv3jMLDv2への移行過渡期であり，
マルチキャストにおいては，暗号化によりデータ保
IGMPv12jMLDv1を実装したクライアントもまだ
護を行う方式 [
2
1
]が…骨支的である.通常，暗号化と複
多く存在する.本論文では，これまでに開発された
2
8
8
ぅ
論文 /Flexcastによる段階的導入に優れたマルチキャストシステムの設計と実装
IGMPvl2jMLDvl クライアントを利用するために，
j式を
グループアドレスから SSMチャネルへの変換 )
ぅ
提案した.更に，提案方式により，グループアドレス
管理を顧客ごとに独立して行うことができることを示
した. I
Pmulticastのよう 1
こネットワーク全体で一意
性を管理する場合によヒベ，管理が容易になり，スケー
v
e
r
slOn 札" IETF Request f
o
rCommellts:
3
3
7
6，Oc(;
2002.
[
9
] M.J. Chris初日前 n，K. Kimball and F
. Solensky，
う
"
C
o
n
s
i
c
l
e
r
a
t
iOl凶
f
o
r lGl
V
IP
孔
n
c
l M LD snooping
switchesヲ
'
， IETF I
n
t
e
r
n
e
t Draft work i
l
l progr
朗
う
Sぅ
M品
.
y2004.
“A c出 ef
o
rend
[
1
0
] Y
.
H
.
.Chu，S.G.Rao，andH.Zhang，
nr
n
u
1
t
i
c
a
s
t，
"Proc.SIGMETIUCS00，pp.1-12，
s
y
s
t巴r
ヲ
ラピリテイの向上が期待できる.
.
1une2000.
Flexcastルータを実装し，転送能力と障害切換性能
の評価実験を行った.その結果， Gbitjs レベルの転送
能力を実現可能であること，高い可用性を備えること
を明らかにした.更に，提案したグループ管理システ
A
. Sirbu，
“ Prici月 rnu1ticast
[
1
1
] .
1.
C
.
-1
. Chu品時乱ndM .
.pproach，
" Telecolll
communication: A cost-based a
l
1
1u
nication Systernsぅ
vol
.17，n
o
.
:
3，p
p
.
2
8
1
2
9
7，.
1uly
2001.
[
1
2
] L
.狂.lVI.K. Costa，S
. Fdi
<
九
， a
n
c
l O.C.M.B. Duarteヲ
ムを実装し，後方互換性が峰保されていること，顧客
“
日 opbyhopr
n
u
l
t
i
c
a
s
troutingprotocol，
"Proc.SIG-
間で共通するグループアドレスを利用できることを確
[M
'Ol，pp.249-259，Aug.2001
C O乱i
い
[
1司
3
] S
. De伐
er
出
:
i
I
珂， "Mul
比
t
i
c陥 trou
而時 i
凶n i
n
t
e
ω
rnetw飢or
比
.
'
ω
王
k
s
日乱M
認した.
令
extendecl LANs，
" Proc. SIGCOMM'88，pp.55-64，
本システムによって，マルチキャストサービス開始
時の経済的リスクを抑えることが可能となり，普及を
“Anarchitectnref
o
rwide-areal11u
l
t
i
c
a
s
t
[
1
4
] S
.Deering，
routing，
" Proc. S1GCOMM'94， pp.126-135， Aug.
促進できると期待している.
謝辞
Aug. 1
9
8
8
.
Flexcast研究開発プロジェクトを推進して頂
色論文執筆の機会を与えて Fさった林一博グループ
リーダ(現 NTTアドバンステクノロジ ) に深く感謝
1
9
9
4
.
[
1
5
] S
.
E
.Deering，
W.C.Fenner，a
n
c
lB.Haberman，"Mul-
"IETFRet
i
c
a
s
tl
i
s
t
e
l
l
e
rc
l
i
s
c
o
v
e
r
y(MLD) f
o
rIPv6，
questf
o
rCornrnents2710 Oct.1999.
ラ
[
1
6
] C. Diot，B.N. L白vineぅ B.Ly1esぅ H. K出 s
e
r
n，a
n
c
l D.
致します.
Balensiefen，
“Deploymentissuesf
o
rth巴 1Pmulticast
ム
ι
献
"1EEENetw.，vol
.14，
pp.78s
e
r
v
i
c
ea
n
c
la
r
c
h
i
t
e
c
t
u
r
e，
[
1
] E. Aharoni and R. Cohen，
“ Restricted dynamic
s
t
e
i
n
e
rt
r
e
e
sf
o
rs
c
a
l
a
b
1
e mu1ticast i
n datagram
" Proc. 1NFOCOM'97ヲ vo1
.2，pp.876-883，
networks，
Apri11
9
9
7
.
“The巴v01utionofmu1ticast: From
[
2
] K.C. A1meroth，
the MBone to interdomain multicast t
o 1nternet2
う
'
， IEEE N巴tw.，vol
.14，n
o.1，pp.10-20，
dep10yment
Jan.
jFeb.2000.
[
3
] R.Boivie，
N.Fe1dman，
Y.lmaiぅ W.Livens，D.Ooms，
and O. Paridaens，唱x
p
l
i
c
i
tmu1ticast (Xcast) basic
"1ETF1nternetDraft，workinprogress，
s
p
e
c
i
f
i
c
a
t
i
o
n，
June2004.
“ SEM:A newsmallgroup
[
4
] A.BoudaniandB.Cousinヲ
" Proc. 1CT2003，vo1
.1ヲ
mu1ticast routing protoc01，
88，Jan.2000.
[
1
7
] H. Eriksson，
“MBONE: The ml
山 i
c
a
s
t backbone，
"
Comrnun.ACM，vo1
.37，
no.8，pp.54-60，Aug. 1
9
9
4
.
[
1
8
] D. Estrinぅ D. Farinacci，A. Helmy
ぅ D
. Thalerヲ S
Deering M. Hanclley， V. Jacobsonヲ C.-G. Liu，
ラ
P
. Sharma， a
n
c
l L
. Wし
巴
“
Protocol i
n
c
l
e
p
e
n
c
l
e
n
t
r
n
u
l
t
i
c
a
s
t
s
p
a
r
s
er
n
o
c
l
e(PIM-SM):Protocols
p
e
c
i五c
a
.
ω
t
i
o
n，
"1ETFRequestforComrn日nts2362，.
June1998
[
1
9
] W.C.Fenner，"1ntern
巴 tg
roupmanagementprotocol，
version2，
"1ETFRequestforComments2236，Nov.
1
9
9
7
.
[
2
0
] R. Finlayson，
“TheUDPmulticasttun問 lingprotoc
0
1，
"IETFInternetDraft，Nov.2003.
[
2
1
] T.Harcljonoa
.
n
c
lB
.Weis，吋 hem叫 t
i
c
a
s
tgro叩 s
e
c
l
ト
rityarchitecture，
"IETFRequestforComments3740
う
pp.
450-455 Feb.2003.
ラ
[
5
] A. Boudani， A. Guitton， and B. Cousin，
“ GXc
a
s
t
: Genera1ized e
x
p
l
i
c
i
t mu1ticast routing protoc
0
1，
" 1ETFInternet Draft workinprogress，March
う
2004.
[
6
] T.Bourkeヲ ServerLoadBa1ancing，O'Reilly& Asso2001
.
c
i
a
t
e
s，
[
7
] J.W.Byers，
M.Luby
，M.Mitzenmact巴r，andA.Rege，
“
Ad
i
g
i
t
a
1fountainapproach七or
巴l
i
a
b
1巴 d
i
s
t
r
i
b
u
t
i
o
n
o
fbulkdata，
"Proc. SIGCOMM'98，pp.56-67 Aug.
ヲ
1
9
9
8
.
. Deeri時ヲ B.Fenner，1
. Kouve1as，andA
[
8
] B.Cain，S
I
n
t
e
r
n
e
tgroupmanagementprotoc01，
Thyagarajan，"
March2004.
D.Anclou，
H.He，
W.Tawbi，
a
n
c
lT.Niki，
[
2
2
] T.Hayashi，
1
n
t
e
r
n
e
tgroupmembershipauthenticationprotocol
“
(IGAP)，
"IETF1
凶 e
rnetDraftヲ A碍・ 2003
A.Tanabe，H.Satou，a
n
c
lT.Niki，
[
2
3
] T.H&yashi，H.He，
Multicastl
i
s
t
e
n
e1' c
l
i
s
c
o
v
e
r
yauthenticationp1'otocol
“
(MLDA)，
" IETF Internet Draft，wo1'k i
n prog1'e
s
s，
May2004.
[
2
4
] R
. Hinclen，“Vi1'tual router 1'eclunclancy p1'otocol
(VRRP)，
"1ETFRequestforComments3768，Ap1'i
l
2004.
. Cheriton，"IP ml
山 i
c
a
s
t
[
2
5
] H.W. Holbrook a
n
c
l D.R
2
8
9
電子情報通信学会論文誌 2005/2Vol
.J88-D-INo.2
c
h
a
n
n
e
l
s
: Express support f
o
rl
a
r
g
巴s
c
a
l
es
i
n
g
l
e
-
h
t
tp
:jjww
V
J
.
.kubotek.comj
enginfojEhome.html
sourceappl
ications，
"Proc.SIGCOMM'99，pp.65-78，
[
4
6
J NTT News Rel
ease，
“ NTTstreamssuper high d
e
f
-
S
e
p
t
.1
9
9
9
.
i
n
i
t
i
o
n movies i
n the g
l
o
b
a
ls
c
a
l
e high-speed n
e
t
-
. Tani，K. Ishimaru，S
. Minato，and T
[
2
6
J T. Inoue，S
d
e
a
r
e
amul
t
i
c
a
s
t
i
n
gbasedonf
iexcast
Miyazaki，刈"Ii
"Proc. APSITT'03，
Towardtheubiquitousnetwork，
pp.301-306，
Nov.2003
:l
，S
. Skar叫
[
2
7
J M. Luby，V.K Goya
work，
" http://www.
n
t
t
.c
o
.jp/news/news02e/021
1/
021113.html，Nov.2002.
[
4
7
J NTT News Release，
“ Thes
u
c
c
e
s
s
f
u
l demonstrati
o
n
o
f simultaneous wide-area mul
t
i
p
o
i
n
tt
r
乱 n
smission
and G.B. Horn，
o
fH D streams f
o
r the broadband ubiquitous era，
"
"Waveandequationbasedr
a
tec
o
n
t
r
o
lusingm
u
l
t
i
-
h
t
t
p
://www.ntt.co叩 jn巴wsjnews03ej0305j
"Proc.SIGCOMM'02，pp.191c
a
s
troundt
r
i
ptime，
030530.html，May2003
204，
Aug.2002.
[
2
8
J G.S. Malkin，
“ RIP version 2，
" IETF Request f
o
r
Comments2453，
Nov. 1998
“ OSPFversion2，
" IETFRequ巴s
tf
o
rCom[
2
9
J J
. Moy，
t
t
p
:
jjwww.postgresql
.orgj
[
4
8
J PostgreSQL，h
[
4
9
J WindowsMed民
h
t
t
p
:jjwindowsmedia.microsoft.comj
(平成 16年 5月 1
8 日受付，9月 13 日再受付)
April1998
ments2328，
[
3
0
J T. Ogura，J
. Suzuki，A. Chugo，M. Katoh，and T.
“S
t
a
b
i
l
i
t
y eval
uation o
fa dynamic t
r
a
f
f
i
c
Aoyama，
engineeringmethodi
nal
a
r
g
e
s
c
a
l
enetwork，
"IEICE
.E86-B，no.2，pp.518-525，Feb.
Trans. Commu
n
.，voI
2003.
井上
武
(正員)
[
3
1
J S
. Ohta，S
. Ta爪乱ndT. Miyazaki，
“ Multicastasa
1998京大・工・物理工卒 .2000同大大
t
r
a
f
f
i
cvariancesmoothe
rf
o
rIP streamings
e
r
v
i
c
e，
"
学院工学研究科修士課程了.同年 NT T入
社.以来，移動通信，マルチキャスト通信
Proc.Networks'02，
pp.105-110，June2002.
“
Scal
i
n
g o
f multicast t
r
e
e
s
: Comments on the
の研究に従事 .現在，未来ねっと研究所社
員. 2002本会情報ネットワーク研究会研
" Proc. SIGCOMM'99，
chuang-sirbu s
c
a
l
i
n
g l
aw，
究賞受賞 .
. Sh巴nker，and H. Tangmunarunkit，
[
3
2
J G. P
h
i
l
l
i
p
s，S
pp.
41-51，Aug. 1
9
9
9
.
[
3
3
J I
. Stoica，T.S.E. Ng，and H. Zhang，
“ REUNITE: A
r
e
c
u
r
s
i
v
eunica
s
t approach t
o multicast，
" Proc.IN.3，pp.1644-1653，M乱 r
ch2000.
FOCOM'OO，vol
[
3
4
J S
. Tani，T. Miyazaki，乱吋 N. Takahash
i， “
Adapt based on IP unicast and dyt
i
v
e stream multic乱s
tmechanism: Ana
c
t
i
v
e
namiccommercialattachm巴n
networkimpl巴mentation，
"Proc.IWAN2001，pp.116S
e
p
t
.2001
.
133，
[
3
5
J D. Thaler，M. Tal
war，A. Aggarwal，L
.V
i
c
i
sano，
andD.Ooms，
“ IPv4automati
cmulticastwithoutex-
奇誠一郎
(正員)
1993京大・工・情報工学卒. 1995東大・
迎・情報科学専攻了. 1995 日本電信電話株
式会社入社.現在，同社コミュニケーショ
ン科学基礎研究所研究主任.通信プロトコ
ル，離散アルゴリズム，量子計算・通信の研
究に従事. 2000年度情報・システムソサイ
エテイ論文賞(先見論文)受賞.情報処理学会， ACM，IEEE
各会員.
p
l
i
c
i
ttunnel
s(AMT)，
"IETFInternetDraft，workin
Feb.2004
progress，
. Fdida，S
. Deeri時，B
.
[
3
6
J R. Vida，L.H.M.K. Costa，S
高橋宏和
(正員)
Fenner，I
. Kouvelas，and B. Haberman，“Multicast
2000長岡技科大・工・電気電子システム
"IETF
l
istenerdiscoveryv
e
r
si
o
n2(MLDv2)f
o
rIPv6，
工卒. 2002同大大学院-工学研究科修士課
Requestf
o
rComments3810，June2004.
程了 .同年 NTT入社.以来，マルチキャ
[
3
7
J Ciscosystems，
I
n
c
.，
h
t
t
p
:
jjwww.cisco.comj
スト通信の研究に従事.現在，未来ねっと
t
t
p
:
jjcr.yp.tojdaemontool
s.html
[
38J daemontools，h
棚究所社員.
[
3
9
J Google，h
t
t
p
:
jjwww.google.comj
t
t
p
:
jjwww.ggf
.orgj
[
4
0
J Gl
obalGridForum，h
[
4
1
J Internet2，http・jjwww.in
もe
rnet2.
eduj
，
[
4
2
J JavaS
e
r
v
l
e
tTechnology
http・jjjava.
sun.comjproductsjser
v
l
e
t
j
[
4
3
J JapanGi
gabi
tNetwork，
ht
t
p
:
jjwww.j
g
n
.
n
ic
t
.
g
o
.
j
p
j
e
n
gl
ishjindex_E.html
[
4
4
J Keepalivedf
o
rLinux，
h
t
t
p
:
jjkeepaliv
巴d
.
s
ourc
e
f
o
r
g
e
.n巴t
j
[
4
5
J KubotekCorp.，
290
論文 / Fl
excastによる段階的導入に優れたマルチキャストシステムの設計と実装
湊
真一
(正員)
1988京大・工・情報卒， 1990同大大学
院修士課程了. 1995同博士後期課程(社会
人選抜)修了.博士(工学). 1990NTT入
社.以来，吠規模論理データの表現と処理
アルゴリズムの研究開発に従事 .1997米国
スタンフォード大客員研究員. 1999NTT
未来ねっと研究所主任研究員 .2004 より北大情報科学研究科
naryDeci
s
i
o
nDiagramsandAppl
ic
a
ti
ons
助教授.著書:
“ Bi
，1995)
. 2000情報処理i
l
学会山下記
f
o
rVLSICAD" (Kl
uwer
念
品
i
Jl
究賞受賞. I
EEE，情報処理学会各会員.2000 ~ 2003 情報
処理学会論文誌編集委員.
宮崎敏明
(正員)
1981電通大・
電気通信・
応用電子卒. 1983
同大大学院修士謀程了 .同年日本電信電話
公社(現 NTT) 入社.現在，同社未来ねっ
と研究所グループリーダ. LSI
CAD，通信
用
FPGA及び応用装置，アクティブネ
y
トワーク，ユピキタスネットワークの研究
開発に従事.新潟大大学院客員教授.東京農工大非常勤講師.
工博(東工大). IEEE，情報処理学会各会員 .
豊島
鑑
(正員)
1982福井大・工・電子卒. 1984同大大
I
程了.同年日本電信
学院工学研究科修士号t
電話公社(現 NTT) 入社.以来， ATM伝
送・交換システム， IPoverATMシステ
ム
， Networkベース DDoS防御システム，
Uni
c
a
s
tベース多地点配信システム等の研
究開発に従事.現在， NTT未来ねっと研究所主任研究員. 1988
本会篠原記念学術奨励賞受賞. IEEE会員 .
2
9
1