2002 年度
学士学位論文輻輳適応型伝送による通信品質確保手法の提案
A inspection of communication resercation-of-quarity
using congestion adaptive transfer

1020305

豊島 修平

指導教員

菊池 豊

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

要 旨

輻輳適応型伝送による通信品質確保手法の提案
豊島 修平

通信の品質を確保する手法に QoS 制御型伝送がある。

QoS 制御型伝送は、ネットワーク資源を予約して品質を確保する手法であるため、伝送路となるネットワークをステートフルにする。ネットワークをステートフルにすると、ネッ
トワークの構造が複雑になってしまうというデメリットが生じる。
本研究では、ステートレスなネットワークにおいて通信品質を確保する伝送方式として、

QoS 適応型伝送を提案する。また、 QoS 適応型伝送をモデル化し、モデルに従った実証実験を行い品質が確保できる事を示す。
キーワード

QoS,QoS 制御型伝送,QoS 適応型伝送,IPv6–i–

Abstract
A inspection of communication resercation-of-quarity using
congestion adaptive transfer
TOYOSHIMA Shuhei

QoS controll type transfer is a technique of securing transfer quality.
It reserves the network resources,and network will be statefull.Demerit of statefull
network is to complicate network structure.
This research proposes to reserve transfer quality by stateless network named adaptive type transfer.And modelling QoS adaptive type transfer.Then show a transfer quality will be reserved.
key words

QoS,QoS controll type transfer,QoS adaptive type transfer,IPv6– ii –

目次
第1章

はじめに

1

第2章

基礎となる技術

3

QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1

QoS 制御型伝送モデル . . . . . . . . . . . . . . . . . . . . . . . .

4

トラフィック制御技術 . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.2

RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.3

Intserv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2.1

トラフィッククラスフィールド . . . . . . . . . . . . . . . . . . . .

7

マルチキャスト技術 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.3.1

IPv6 マルチキャスト . . . . . . . . . . . . . . . . . . . . . . . . .

10

マルチキャストアドレスの構造 . . . . . . . . . . . . . . . . . . . .

10

定義済みマルチキャストアドレス . . . . . . . . . . . . . . . . . . .

11. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

IPv6 でのマルチキャスト経路制御 . . . . . . . . . . . . . . . . . .

13

2.4

高信頼マルチキャスト . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.5

マルチキャストの利用シーンと信頼性の必要性 . . . . . . . . . . . . . . .

14

情報配布 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

データベースの同期 . . . . . . . . . . . . . . . . . . . . . . . . . .

15

放送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

即時データ配布 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.5.1

回線環境による考慮の必要性 . . . . . . . . . . . . . . . . . . . . .

16

2.5.2

高信頼マルチキャストに関するこれまでの動き . . . . . . . . . . . .

17

2.1

2.2

2.3

グループ管理– iii –

目次

2.5.3

提案されている高信頼マルチキャスト機構 . . . . . . . . . . . . . .

17

単純再送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17応答の集約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

受信者間における欠落の補完 . . . . . . . . . . . . . . . . . . . . .

18

前方誤り訂正 (FEC) を用いたパケットを回復 . . . . . . . . . . . .

19

高信頼マルチキャストの展望 . . . . . . . . . . . . . . . . . . . . .

19

地域間相互接続実験プロジェクト . . . . . . . . . . . . . . . . . . . . . .

20

地域間相互接続実験プロジェクトの目的 . . . . . . . . . . . . . . .

20

日蝕中継動画配信実験 . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.5.4
2.6

第3章

輻輳適応型伝送23

3.1

QoS 適応型伝送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.2

輻輳適応型伝送モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.2.1

モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

輻輳適応型伝送プロトコルの提案 . . . . . . . . . . . . . . . . . . . . . .

25

実験装置

26

4.1

目標 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.2

仕様 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.2.1

lossGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

内部仕様 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

sendCATP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

内部仕様 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

sendPPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

内部仕様 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.2.4

recvCATP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.2.5

logAnalyser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.3
第4章

4.2.2

4.2.3

– iv –

目次

4.2.6

第5章

5.1

5.2

第6章

6.1

内部仕様 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

ppmAnalyser . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

内部仕様 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

実証実験

34

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

34

5.1.1

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

34

5.1.2

実験方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

5.1.3

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

36

5.1.4

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

36

実験 2

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

40

5.2.1

構築環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5.2.2

実験方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.2.3

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

42

5.2.4

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

44

まとめ

46

今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

6.1.1

トラフィッククラスフィールドの利用 . . . . . . . . . . . . . . . . .

46

6.1.2

JPEG を利用した実験 . . . . . . . . . . . . . . . . . . . . . . . .

46

6.1.3

マルチキャストにおける 輻輳適応型伝送モデルの提案 . . . . . . . .

47

6.1.4

プレゼンテーション層も含めた送信機構の提案 . . . . . . . . . . . .

47

動作概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

OSI 参照モデルに基づく伝送機構モデル . . . . . . . . . . . . . . .

47

プレゼンテーション層も含めた受信機構の提案 . . . . . . . . . . . .

48

動作概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

OSI 参照モデルに基づく受信機構モデル . . . . . . . . . . . . . . .

49

6.1.5

–v–

目次

6.1.6

ルータ群におけるパケットフォワード機構の提案 . . . . . . . . . .

50

動作概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

パケットフォワーディング機構モデル . . . . . . . . . . . . . . . .

50

謝辞

52

参考文献

53

付録 A

映像配信実験

55

A.1

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

55

A.2

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

56

A.3

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

56

A.4

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

57

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

58

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

58

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

59

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

60

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

61

A.7

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

61

A.8

新湊曳山祭り中継. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

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

63

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

64

A.9

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

65

A.10

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

66

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

67

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

67

A.5

A.6

A.11

– vi –

図目次
2.1

Token Backet 動作モデル . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.2

IPv6 ヘッダ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83.1

輻輳適応型伝送モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.1

実験 1 想定環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.2

実験 2 想定環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.3

lossGen 内部構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.4

sendPPM 内部構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.5

画像の重み分け手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.6

ppmAnalyser 内部構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.1

実験 1 で用いるネットワーク . . . . . . . . . . . . . . . . . . . . . . . . .

35

5.2

パケットロス率 0 % のパケット到達状況 . . . . . . . . . . . . . . . . . . .

37

5.3

パケットロス率 20 % のパケット到達状況 . . . . . . . . . . . . . . . . . .

37

5.4

パケットロス率 40 % のパケット到達状況 . . . . . . . . . . . . . . . . . .

38

5.5

パケットロス率 60 % のパケット到達状況 . . . . . . . . . . . . . . . . . .

38

5.6

パケットロス率 80 % のパケット到達状況 . . . . . . . . . . . . . . . . . .

39

5.7

実験 2 で用いるネットワーク . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.8

破棄率 0 % における輻輳適応型伝送プロトコルを用いた場合 (左) と用いな
い場合 (右) の画像比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.9

43

破棄率 20 % における輻輳適応型伝送プロトコルを用いた場合 (左) と用いない場合 (右) の画像比較 . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.10 破棄率 40 % における輻輳適応型伝送プロトコルを用いた場合 (左) と用いない場合 (右) の画像比較 . . . . . . . . . . . . . . . . . . . . . . . . . . .

– vii –

43

図目次

5.11 破棄率 60 % における輻輳適応型伝送プロトコルを用いた場合 (左) と用いない場合 (右) の画像比較 . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5.12 破棄率 80 % における輻輳適応型伝送プロトコルを用いた場合 (左) と用いない場合 (右) の画像比較 . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

6.1

輻輳適応型伝送プロトコル送信機構 . . . . . . . . . . . . . . . . . . . . . .

48

6.2

輻輳適応型伝送プロトコル送信機構 . . . . . . . . . . . . . . . . . . . . . .

49

6.3

フォワーディング機構モデル . . . . . . . . . . . . . . . . . . . . . . . . .

51

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

59

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

60

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

61

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

63

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

68– viii –表目次
1.1

配信の際利用した技術 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

2.1

優先度フィールドの値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2

IPv6 マルチキャストアドレスの構造 . . . . . . . . . . . . . . . . . . . . .

10

5.1

実験 1 のマシン構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

5.2

パケット平均到達状況 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.3

パケット到達量と優先度の関係 . . . . . . . . . . . . . . . . . . . . . . . .

40

5.4

実験 2 のマシン構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42– ix –

第1章

はじめに
近年 xDSL や光通信、FWA、IMT-2000、CATV といった、いわゆるブロードバンド環
境がオフィスから家庭に至るまで浸透しつつある。ブロードバンド環境の浸透に伴い、より「広帯域」な環境を必要とするブロードバンドサービスが提供され始めた。しかし、現状のブロードバンドサービスはそれらの特徴を生かすような技術によって提供されていない場合が多く、その結果ネットワークリソースを無駄に消費してしまっている。
我々は 2000 年 10 月より 1 年以上に渡り映像配信実験を行って来た。その中で我々は表

1.1 に示す配信技術を利用してきた。しかし、それらの中で実時間性を保ち汎用ネットワー
クにおいて品質を確立できるような技術が必要である事に気が付いた。

MPEG2ts において採用していた FEC (FowardErrorCorrection) は、送信データに冗長符号を付ける事により、伝送途中に欠落してしまったパケットを受信側で回復するという技術である。FEC は実時間性を保ちながらある程度の品質を保証できる技術である。しかし、送信側が想定した以上にパケットロスが起きてしまうと全くパケット回復を行う事ができない。これでは、ネットワーク状況が大幅に変動してしまうようなネットワークでは利用が困

レイヤ
アプリケーション層
ネットワーク層
物理層

配信技術

WindowsMedia,RealMedia,DVTS,MPEG2ts
IPv4Unicast,IPv4Multicast,IPv6Unicast,IPv6Multicast
Wireless LAN,Ethernet,ATM,Satellite
表 1.1

配信の際利用した技術–1–

難である。しかし、汎用的なネットワークではネットワークの負荷状況が不定期かつ大変に変動してしまう為に FEC で完全に品質を保証する事は困難である。
一方、実時間性を保ちかつ通信品質を確保する手法に Intserv や Diffserv といった QoS
制御型伝送手法がある。しかし、QoS 制御型伝送を実現するとネットワークがステートフルになってしまうため、構造が複雑になってしまうという欠点がある。
以上の背景より、著者は伝送における実時間性を保持し、ステートレスなネットワーク
において欠落状態に適応した品質の情報を得られる伝送方式である輻輳適応型伝送を提案
する。

–2–

第2章

基礎となる技術
本章では、本研究を行う上で必要な QoS 理論、IPv6、マルチキャスト技術について解説
する。

2.1

QoS

従来のベストエフォート型のネットワークにおいて、ネットワーク上に流れる全てのパケットは公平であり、それらの到達に関しては何の保障もされていなかった。
また、事実上ネットワーク資源の利用は早い者勝ちであり、それゆえに各アプリケーショ
ンは最大限に帯域を確保しようと最大限の伝送を行っていた。それゆえ、一部の通信が多くの帯域を確保してしまうと、他の通信が十分な帯域を確保できなくなってしまうという事態も起こり得た。
ネットワークの品質を示す概念に QoS がある。QoS とは、Quality of Service の略で、利用者に対するサービス品質を表す。IETF Intserv ワーキンググループにおいては「定量的に表すことができる絶対的性能」と定めている [1]。

QoS の概念を持ち通信品質を確保する伝送方式を「QoS 制御型伝送」と言う。QoS 制御
型伝送は、次のようなアプリケーションに応用されると考えられている。

• ストリームデータ配信 (インターネット放送)• インターネット電話、インターネットテレビ電話• モバイルアプリケーションへの動画配信• 電子商取り引きにおける仮想ショッピングモールのウォークスルーや商品紹介–3–

2.1 QoS• ミッションクリティカル・システムにおける緊急通知、リアルタイム制御• 映像、音、CG を駆使した双方向ゲーム• ビデオやバックアップ用の大容量ファイルの転送

2.1.1

QoS 制御型伝送モデル

QoS 制御型伝送は、次に示す 2 層に分かれて処理を行う。
• アプリケーションレベル
OSI 参照モデルにおけるセッション層以上の上位層における処理で、例えば次のような
QoS 値を扱う。
– 動画フレーム数– 画像表示サイズ– 空間解像度– 色
アプリケーションレベルにおいて取り扱う QoS 値は以下で述べる通信レベルの QoS 制
御へフィードバックされる。

• 通信レベル
OSI 参照モデルにおけるトランスポート層以下の下位層における処理で、例えば次のよ
うな QoS 値を扱う。

– 遅延
– 誤り率
– ジッタ
– スループット
扱う QoS 値を定量的・客観的に測る事ができるという事から、これまでの技術開発では、通信レベルを対象としたものが主であった。

–4–

2.1 QoS

トラフィック制御技術
通信レベル QoS 制御では、トラフィック制御を行う。トラフィック制御を行うには、まず次に示す内容を決定しなければならない。

• ネットワーク容量• ピーク時間に基づく料金体系• サービス別の料金、アドミッション制御 (コネクションの制限)、ルーティング方式• エンド - エンドのフロー制御• キューイング方式 (パケットの優先順位)
次に、トラフィック制御技術要素を示す• adminition control
セッションごとに資源の予約をコントロールする方式• classifier
ルータの中で到着したパケットをグループに分類する方法• packet scheduler
グループ分類されたパケットの送出をスケジューリングする方法。キューイング方式やバッファ方式等• shaper
バーストを平滑化する技術

2.1.2

RSVP

RSVP は Resource reSerVation Protocol の略で、IETF RFC2205 [7]、RFC2208 [6]、RFC2209 [3] で定義されているネットワークリソースの予約プロトコルである。
RSVP は、マルチキャスト及びユニキャストの両方で使う事のできる資源予約プロトコル
で、RSVP 自体はネットワーク資源の制御を行わない。

–5–

2.1 QoSRSVP メッセージには、Flowspec という QoS 値が含まれている。Flowspec は、Token
Backet という仮想システムへのパラメータである。トークンとは、ネットワークへデータを送出する権利で、トークンバケットに一定量たまったバケットを消費する事によりパケットが送信される。Token Backet の動作モデルを図 2.1 に示す。また、資源の予約行為は受
token

token backet

consume token

queue

send packet

図 2.1 Token Backet 動作モデル

信端末において行う。予約は、経路変更やマルチキャストメンバ変更を動的に適応するソフ
トステートで行う。また、RSVP をサポートしていないネットワークを透過して動作する。

RSVP を利用するシステムでは、最低でもルータ群にトークンバケットを制御する機構を付加しなければならない。

2.1.3

Intserv

Intserv は Intergrated services の 略 で 、IETF RFC2201 [2]、RFC2211 [14]、RFC2212 [13]、RFC2215 [12] で 定 義 さ れ て い る ネット ワ ー ク リ ソ ー ス フ ロ ー 毎 の制御メカニズムである。また、リソースの予約プロトコルとして RSVP を利用する。

Intserv では、次のような目標を持っている。
• Guaranteed Service–6–2.2 IPv6

帯域と最大遅延を保障する• Controlled Load Services
遅延の目標値を持ち、流通を自ら制御する適応型アプリケーションで、ネットワークが混雑している場合であっても、利用率の低いベストエフォートネットワークと同等程度に動作する

Intserv におけるパケット制御を実現する為には、次のような機構が必要になる。
• パケット・バイ・パケットのフロー識別• 帯域確保の為のキューイング及びスケジューリング
• フロー毎に確保している帯域状況の保持• Flowspec をチェックするトークンバケット
このように、Intserv ではフロー数が増える程ネットワーク上で扱う状態制御情報が急速に増加してしまうため、スケーラビリティに欠ける。

2.2

IPv6

IPv6 (Internet Protocol Version 6) は、前のバージョンである IPv4 を基に改良・設計されたネットワーク層プロトコルである。IPv4 での反省点を考慮し、アドレス長の増加やヘッダ情報の見直しなど様々な改良が加えられている。IPv6 は、IETF の定める RFC によって定義されている。

2.2.1

トラフィッククラスフィールドIETF RFC2460 [5] は IPv6 ヘッダを定義している。IPv6 ヘッダの構造を図 2.2 に示す。
IPv6 ヘッダにおいてトラフィッククラスフィールドは、パケットの送信元ノードと転送
ルータとが IPv6 パケットの異なるクラスや優先度を区別するために使用する。現段階では実験段階のフィールドであるために、格納する具体的な値をプロトコルとして定義してい–7–

2.2 IPv6

version Traffic Class
field
field
(4bit) (8bit)

flow Label (20 bit)

payload length(16 bit)next header(8 bit)hop limit(8 bit)source address(128 bit)

destination address(128 bit)

図 2.2 IPv6 ヘッダ

ない。
トラフィッククラスフィールドには、次に示す一般用件が適用される。

• サービスインタフェース
ノード内の IPv6 サービスへのサービスインタフェースは、上位層プロトコルが起動するパケット中のトラフィックのビット値を、上位層プロトコルが供給する手段を提供しなければならない。そのディフォルト値は、全 8 ビットでなければならない。

• ノードによるフィールドの扱い
トラフィッククラスのビットの全てあるいは幾つかの特殊な使用 (実験あるいは最終的な標準) をサポートするノードは、特殊な使用が必要な時に自ら起動、転送、受信する
パケット中のそれらのビット値を変更する事が許される。ノードは特殊な使用をサポー–8–

2.2 IPv6

トしていないトラフィッククラスについては、いかなるビットも無視して変更せずに残すべきである。

• 値の変更
上位層プロトコルは、受信したパケットのトラフィッククラスのビットの値がパケットの送信元が送信した値と同じであると想定してはならない。
最初に IPv6 ヘッダを定義した RFC1883 [4] では、トラフィッククラスフィールドと同様の意味を持つ優先度ヘッダフィールドがあった。優先度ヘッダフィールドを指定する事により相対的にパケットの優先度を設定することができ、途中で破棄されるパケットを指定することができる。4 ビットの値幅のうち、0 から 7 までは輻輳されたトラフィックの為に、8 から 15 までは実時間通信あるいは輻輳制御されていないトラフィックの為に予約されている。
優先度フィールドの各値の説明を 2.1 に示す。
表 2.1

優先度フィールドの値

優先度フィールドの値

予約されている内容

0

特徴なしトラフィック

1「穴埋め」トラフィック (例：ネットニュース)2

不在データ転送 (例：電子メール)

3

(予約)

4

バルク転送 (例：FTP、NFS)

5

(予約)

6

対話トラフィック (例：telnet、X)

7

インターネット制御トラフィック (例：RTP、SNMP)

8 〜 15

実時間通信トラフィックまたは輻輳制御されていないトラフィック

優先度フィールドは、RFC2460 に obsolute された際にトラフィッククラスフィールドに–9–

2.3 マルチキャスト技術

表 2.2 IPv6 マルチキャストアドレスの構造

8bit

4bit

4bit

112bit

マルチキャスト・プレフィックス (11111111)

フラグ

スコープ

グループ番号

置き換えられた。

2.3

マルチキャスト技術

マルチキャストは、複数の送信ノードに対して同一のコンテンツを伝送する際に利用する技術である。従来のユニキャスト通信では、送信ノードは受信ノードの数だけコンテンツを送信しなければならず、ネットワーク資源を無駄に消費していた。
それに対しマルチキャスト通信ではただ一つのコンテンツを送信し、経路途中にあるルータにおいて受信ノードの数だけ複製する。これにより、伝送途中のネットワーク資源を必要以上に消費せずに複数の受信ノードにコンテンツを伝送できる。

2.3.1

IPv6 マルチキャスト

マルチキャストアドレスの構造
マルチキャストアドレスの構造を、表 2.2 に示す。各項目の意味は以下である。

• マルチキャスト・プレフィックス
マルチキャストアドレスは、上位 8 ビットが全て 1 であると決まっている。

• フラグ
フラグ

0

0

0

T

– 10 –

2.3 マルチキャスト技術– 上位 3 ビット：予約– 4 ビット目：アドレスが一時的 (Transient) であるかどうか示すフラグ

IANA から割り当てられたアドレスを利用する場合は、4 ビット目を 0 にするが、アドレスを一時的に利用する場合は以下の手順で一時的にアドレスを利用する。

1.「セッション一覧データベース」に問い合わせてアドレスを無造作に選び出す
2. 衝突検出アルゴリズムによりアドレスの一意性を確かめる
3. セッションが終了すると、アドレスは開放される• スコープ
マルチキャストグループの範囲設定に用いる。以下のスコープ値が定義されている。

値

スコープ

値

スコープ

0

予約

8

組織ローカル・スコープ

1

ノードローカル・スコープ

9(未割り当て)2

リンクローカル・スコープ

A(未割り当て)3(未割り当て)B(未割り当て)4(未割り当て)C(未割り当て)5

サイトスコープ・ローカル

C(未割り当て)6(未割り当て)E

グローバル・スコープ

7(未割り当て)F

予約

定義済みマルチキャストアドレス

IANA によって、いくつかのグループ番号はあらかじめ割り当てられている。それにより、アプリケーション等であらかじめ固定的にマルチキャストアドレスを組み込む事ができる。

– 11 –

2.3 マルチキャスト技術

Group No

割り当て

0

予約

1

すべての IPv6 ノード

2

すべての IPv6 ルータ

43

すべての NTP サーバ

1:0

すべての DHC サーバと中継エージェント

グループ管理IPv6 マルチキャストでは、グループ管理を標準でサポートしている。グループ管理に関する手続きは、ICMP のメッセージで行う。グループ管理に関する ICMP メッセージは以下のようなものがある。
タイプ

メッセージの種類

130

グループ・メンバーの問い合わせ131

グループ・メンバーの通知

132

グループ・メンバーからの脱退

ICMP メッセージの書式は以下の通りである。
01234567

89012345

タイプ

コード67890123

最大応答遅延45678901

チェックサム未使用

マルチキャストアドレス• グループ・メンバの登録グループに参加したいホストは、その参加したいグループアドレスへタイプ 131 (グ– 12 –

2.3 マルチキャスト技術

ループメンバの問い合わせ) の ICMP メッセージを送り続ける。

• グループ・メンバからの脱退
グループから脱退したいホストは、そのグループ全体に対してタイプ 132 (グループメ
ンバからの脱退) の ICMP メッセージを送る。

• グループ・メンバの問い合わせ
ルータが特定のグループにメンバーがいるか知りたい場合、以下の手順で問い合わせを行う。

1. ルータがグループに対してタイプ 130 (グループメンバの問い合わせ) の ICMP
メッセージを送る

2. グループメンバのホストは、タイプ 131 (グループメンバの通知) メッセージで応答する。応答メッセージを送る際、最大応答遅延の値をランダムに選出し、その値だけ待ってからメッセージを送る。

3. ルータは、帰って来た ICMP メッセージよりグループメンバを確認する。送出を待っているメンバがタイプ 131 のメッセージを受信したら、最大応答遅延の値を 0にして、送信をやめる。

IPv6 でのマルチキャスト経路制御
IPv4 の時と同様に、マルチキャスト経路制御にはホスト〜ルータ間で用いられるプロト
コルとルータ〜ルータ間で用いられるプロトコルがある。

• ホスト〜ルータ間で用いられるプロトコル
マルチキャスト受信者探索プロトコル (MLD: Multicast Listener Discovery) プロトコル– 13 –

2.4 高信頼マルチキャスト(MLD の仕様は、IGMPv2 を踏襲している)• ルータ間のプロトコル PIM (Protocol Independent Multicast)
PIM のメッセージフォーマットは、当初より IPv6 を含めた複数ネットワークプロトコ
ルへの対応を考えて設計されているので、修正を加えなくても IPv6 環境で利用できる。

2.4

高信頼マルチキャスト

高信頼マルチキャストとは、パケット損失に対応する事ができないマルチキャストにおいて信頼性を確保する性質を持つマルチキャストである。
従来の IP マルチキャストでは、パケットの損失に対応することができない。その為、IPの信頼性を確保する技術がマルチキャストには必要であると言われている。それが高信頼マルチキャストである。

TCP の場合、Ack 応答によるパケット欠落の検出、受信時の重複削除と整列機能によってデータ転送の信頼性を確保していた。
通信が１対１の場合は、Ack 応答は信頼性を得るのに有効な手段であった。しかし、通信が１対他であるマルチキャスト通信の場合は Ack の応答数が増え、送信側のシステムやその接続されるネットワークで Ack が集中する問題（Ack Implosion: 応答爆発）が発生してしまう。これでは、スケーラビリティを阻害してしまう為にそのまま利用する訳にはいかない。その為に TCP とは別の信頼性を確保する手段、が必要である。

2.5

マルチキャストの利用シーンと信頼性の必要性

本節ではマルチキャストの利用シーンを挙げ、各状況について必要となる信頼性を考える。

– 14 –

2.5 マルチキャストの利用シーンと信頼性の必要性

情報配布• 利用シーン
多数の拠点に対して、その拠点で処理に用いるデータやソフトウェア等を一斉配布する場合。例えば、CAD データの変更分を全国の工場へ配布する場合や、アプリケーショ
ンソフトウェアのバージョンアップ配布等。

• 特徴
データに即時性は求められない。

データベースの同期• 利用シーン
転送は情報配布と同じく多数の拠点に対して行う。具体的には業務データのデータベー
ス同期や Web のキャッシュサーバ等• 特徴
データの種類によってデータが即時に正しく変更される事が要求される。

放送• 利用シーン
上記２つは転送のみであったが、放送は転送と再生が同時に行われるストリーム転送である。IP ネットワーク上でラジオや TV 放送、会議の中継や多地点会議等。

• 特徴
転送と再生の両方を行うので、転送のための即時性及び再生のために遅延変動の極小化が求められる。

– 15 –

2.5 マルチキャストの利用シーンと信頼性の必要性

即時データ配布• 利用シーン
データの配布であり、放送のように即時性の要求されるもの。例えばディーリングシス
テム等が挙げられる。

• 特徴
コンテンツ到達に即時性が求められる。

これらの事から、利用シーンによって要求される “転送信頼性”、“即時性”、“配布の規模” の度合いが異なることが分かる。
しかし、上述した３つの性能を全て満足する伝送を実現するのは大変困難である。例えば、ストリーム配信（放送）において転送信頼性を向上させようとすると、転送信頼性を向上させる為の手続き（例えば Ack 応答）に時間がかかってしまい即時性の向上が困難になってしまう。また、転送信頼性を向上させる手続きの量が減ったとしても、配布規模が大きくなれば、これもまた総処理量を増やしてしまう。

2.5.1

回線環境による考慮の必要性

新たなマルチキャスト機構を考えるには、利用するリンク媒体についても考えなければならない。最近手近なサービスとなってきた技術の中で、衛星、無線、CATV 等のリンク媒体
は多数の受信者に効率良くマルチキャスト転送をすることができる。これらを用いたマルチ
キャストは、規模が数千から数万に及ぶ大きなものでも実現できる反面、光ファイバ等に比べてノイズによるパケット紛失の発生頻度が大きい。また、衛星回線は下り回線しかないので、応答を返す場合は別途上り回線が必要になってくる。
このように、リンク媒体によっても考えなければならない問題が変わってくる。例えば、衛星を用いればクライアントまでの経路が複雑にならなくて済むが、頻繁に起こるパケット– 16 –

2.5 マルチキャストの利用シーンと信頼性の必要性

紛失に対応しがたく、ATM を用いればパケット紛失は減るがクライアントまでの経路が複雑になってしまう。

2.5.2

高信頼マルチキャストに関するこれまでの動き

これまでに、アプリケーションから転送の高信頼化機構を独立させて TCP のように共通のトランスポート層機構を策定しようという動きがあった。しかし、ここまでに述べたよ
うに応用場面や要求が多様であるため、単独で全てを満たすトランスポート層機構はできな
いということが IRTF で合意されている。そこで、現在までにいくつかの既存の提案をモ
ジュール化してビルディングブロック要素に書き直す作業が行われている。∗1

2.5.3

提案されている高信頼マルチキャスト機構

前節で述べたように、マルチキャストは応用場面や要求によって利用する手法を選ばなければならない。本節では動作別に高信頼マルチキャストを章かいする。

単純再送
再送により損失したパケットを回復する方法。ARQ (Automatic Repeat Request) という。

ARQ には、結果に関わらず一定回数再送を行う方式や、TCP のように受信者より要求されたパケットを再送する方式が提案されている。
一定回数再送を繰り返す方式は、小規模でネットワークの性能があらかじめ分かっている

LAN などで利用するのには都合が良い。
一方、TCP のように受信者から要求を受けようとすると、前述したような「応答の爆発」が起こってしまい、せいぜい数十端末が限度となってしまう。しかし、未着に対する応答だ∗1 (RFC2048、draft-ietf-rmt-bb-track-01.txt、draft-artf-bb-fec-02.txt、draft-ietf-rmt-bb-lcc-00.txt、draft-ietf-rmt-bb-tree-config-02.txt)– 17 –

2.5 マルチキャストの利用シーンと信頼性の必要性

けを返す Nack (否定応答) 方式や、複数パケットに関する未着情報だけをまとめて応答する

Selective Nack (選択的否定応答) 方式、応答が同時に到着しないように応答送出時刻を分散させるバックオフタイマによる応答遅延等の工夫を加えることにより、数千端末規模の配布を実現することができる。
このように再送を利用した拡張は、アプリケーションに実装するだけで実現できるので、すでにいくつかのアプリケーションが作成されている。しかし、それらは UDP を介して IP
マルチキャストを利用するもので、単純再送をマルチキャスト向けトランスポート層技術として分離しているのではない。

応答の集約
応答の集約は、受信者から送信サーバへの応答をマルチキャストを通じて行う方式である。パケット未達時にマルチキャスト配布木の葉から枝に向けて応答を送る。これにより、応答を順次集約していく事ができるので、応答内容の重複を防ぎ送信サーバへの応答個数を減らすことができる。このように応答を逆に集約することを Ack Migration または Mergeという。
この技術を利用したプロトコルに、Cisco 社と Tibco 社によって開発された PGM(Pragmatic General Multicast) がある。PGM は、ルータでの集約機能を提供する。また、
Nack を受けたルータが下流に対して受信を告げるので、Nack 転送の信頼性を確保する役目も果たす。

受信者間における欠落の補完
受信者間での欠落を補完する技術には、Purdu 大学及び AT&T ベル研究所から提案された RMTP (Reliable Multicast Transport Protocol) や、Sally Floyd ら個人グループによって提案された SRM (Scalable Reliable Multicast) 等がある。

RMTP は近隣の受信者をグループ化し、そのグループごとに代表者を立てる。代表者は、– 18 –

2.5 マルチキャストの利用シーンと信頼性の必要性

グループ内の受信者及び下流の代表者から Ack 応答を受け、解決できなければ上流の代表者に問い合わせる。この方法は、グループの管理や代表者の選定方法に問題が残るものの、送信サーバへの応答集中は起こらないというメリットがある。

SRM では、RMTP のように明確なグループを作成しない代わりに、データの欠落が発生した受信者は、全受信者に対して再送要求を出す。これにより、なるべく近隣の受信者間でデータ欠落を補完することが期待できる。この場合、結果的にゆるいグループが構成されている。これにより、グループ管理を行う必要が無くなる。しかし、再送要求が重複する可能性も出てくる。

前方誤り訂正 (FEC) を用いたパケットを回復
前方誤り訂正 (FEC: Foward Error Correction) とは、誤り訂正符号を用いてデータの欠落を回復する手法のことである。この手法では、送信時に、元のデータより冗長符号を計算
し別パケットとして送信する。そうすれば、もし途中でパケットが欠落してしまっても受信側で冗長符号から元データを回復することができる。
誤り訂正符号はいろいろと提案されている。しかし、その中でも回線ビット誤りや磁気記録媒体のビット誤りの訂正によく用いられる Reed-Solomon 符号を用いる例が多い。

FEC によるパケット回復は、冗長度を変化させることで欠落パケットの許容量が変わってくる。効率の良い転送を行うためには、欠落パケット数程度の冗長度を与えることが最良である。しかし、ネットワークの状況やユーザ数によって欠落パケットの数は変わってくるので、常に最適な冗長度を与える事は極めて難しい。

2.5.4

高信頼マルチキャストの展望

同一データの大量配布は、伝送路の進歩に従い一般化されてゆく。データの大量配布を実現させるためには、信頼性が高く、なおかつ効率の良いデータ転送が必要になってくる。
データの大量配布の手法の一つとして、マルチキャストはすでに利用され、多くの環境で利– 19 –

2.6 地域間相互接続実験プロジェクト用されている。マルチキャストを標準的なデータの配布手法として確立するには、転送信頼性を向上させる技術を確立する必要がある。
高信頼マルチキャストを実現させるには、アプリケーション共通のトランスポート層機能として高信頼化機構を独立させなければならない。現在、IETF RMT ワーキンググループ
では、以下のような要素ブロックが提案されている。

• 既存の要素技術では必ずしもアプリケーションの要求に十分に答えていないと考えられる。さらなる個別の要素技術の開発とそれらのビルディングブロックとしての標準化が必要である• 要素の組み合わせ技術がほとんど考えられていないので、技術的に組み合わせの可能性と有効性を確認することとその標準への反映が必要である• 要素を選択して使う場合、選択の基準が明らかでないので、それを明らかにすることが
必要である

2.6

地域間相互接続実験プロジェクト

2000 年 10 月より、地域間相互接続実験プロジェクトに参加してきた。ここでは、地域間相互接続実験プロジェクトについて説明をする。

地域間相互接続実験プロジェクトの目的
地域間相互実験実験 (RIBB: Regional Internet BackBone) には、3 つの大きな活動目的がある。

• 情報リソースを地域間で有効に交換・共有
国内各地で整備が進められているマルチメディア情報コンテンツや 高速情報処理環境
等の「情報リソース」を地域間で有効に交換・共有する• 地域型高速アクセス技術の確立– 20 –

2.6 地域間相互接続実験プロジェクト

地域間において快適に地域型マルチメディア情報リソースを利用するために xDSL やCATV を用いた地域型高速アクセス技術を確立する• 地域型の超高速大規模分散バックボーンアーキテクチャの設計・構築・運用
地域間での情報流通を考慮した大規模分散型の超高速バックボーンアーキテクチャの設計・構築・運用を行うとともに、 新技術を用いた経路制御技術の開発を目指する

地域間相互接続実験における動画配信実験
地域間相互接続実験では、活動目的の検証実験として、動画配信実験を行っている。この実験では、次のような環境を用いている。

• 基幹トラヒックの伝送に JGN を利用する
基幹トラヒックの伝送に通信・放送機構の提供する超高速光ファイババックボーンである JGN (Japan Gigabit Network) を利用する事により、地域間を高速に接続する• 地域間で情報を共有する各地域で提供されるデジタル画像やビデオライブラリ等の情報リソースを地域間で共有する• 地域型高速バックボーンを JGN に繋ぐ
各地域で整備されつつある CATV や xDSL、無線ネットワーク等の高速バックボーン
を JGN に接続し、通信におけるボトルネックが少ない環境を構築して快適な情報リソースへのアクセス環境を構築する

日蝕中継動画配信実験
付録 A.11 に示すように我々は、2001 年 11 月の ISOM 中継実験までに、12 回の映像配
信実験を行ってきた。その中でも、高信頼マルチキャスト技術である FEC を利用した日食
動画配信実験について述べる。

– 21 –

2.6 地域間相互接続実験プロジェクト• イベント内容
ライブ!エクリプスが皆既日食映像をライブ中継しており、その映像を RIBB を通じて全国へ生中継するというものであった。

• ネットワーク構成
ライブエクリプスから配信されたザンビア、ジンバブエ、マダガスカルの映像を、東京から JGN 経由で広島大学へ送信し、FEC Multicast で東京大学、富山大学、九州大学
へと送信した。そうして、さらに九州大学の Multicast Router を一度通り、佐賀、京都、高知工科大学へ。さらに高知工科大学の Multicast Router を通り、ソフトピアジャ
パン、山梨、東北へ順次全国へと送信した。
この映像実験において、FEC マルチキャストを利用した動画を受信する事ができた。

FEC により、ノイズのように微細なパケットロスは補償され感じる事がなかった。しかし、復元閾値を越えるパケットロスが発生した際はブロックノイズが出てしまった。

– 22 –

第3章

輻輳適応型伝送
QoS 制御型伝送は送信、受信ノードによってネットワーク資源を制御するモデルなので、ネットワークがステートフルになる。ネットワークがステートフルになってしまうと、ス
テートを交換するためネットワークの構造が複雑になってしまい、ネットワークの拡大に伴い次のようなコストが発生してしまう。

• ネットワーク上に流れるステート制御情報の処理オーダが増加してしまうために起こる
ネットワークノードへの負荷コスト• ステート情報を管理するためのコスト
本章では、ステートレスなネットワークにおいて品質を確保する伝送方式として、QoS 適応型伝送を提案する。また、 QoS 適応型伝送の動作モデルとして 輻輳適応型伝送を提案し、
輻輳適応型伝送における伝送機構である 輻輳適応型伝送プロトコルの提案を行う。

3.1

QoS 適応型伝送

本節では、通信品質確保手法の新たな伝送方式 QoS 適応型伝送を説明する。
ネットワーク資源をステートフルにする事により、通信品質を制御する QoS 制御型伝送に対して、 QoS 適応型伝送はネットワーク資源がステートレスでありながら通信品質を確保する。

QoS 適応型伝送では、ネットワークにステートを持たせず、ネットワークの構造に複雑な処理を要求をしない。すなわち、ネットワークに通信品質の保証を求めない。本手法では伝– 23 –

3.2 輻輳適応型伝送モデル

send node

receive noderouter group

図 3.1

輻輳適応型伝送モデル

送情報を階層化し、ネットワーク上で欠落する順序を制御する事により通信品質を確保する。これにより、ネットワークの負荷状況に適応した通信品質を得る事ができる。

QoS 適応型伝送は以下のような点において有用であると考えられる• ステートレスなネットワークにおいて適用するので、スケーラビリティが高い• 送信・受信機構への実装のみで実現できるため、導入コストが少ない• ベストエフォートの延長上の概念でありながら、ネットワーク資源の占領問題を回避する事が可能である

3.2

輻輳適応型伝送モデル

本節では、QoS 適応型伝送の動作モデルの一つである輻輳適応型伝送を説明する。輻輳
適応型伝送では、伝送をネットワークに適応させるために送信情報の重み分けを行い、重みに応じた優先度をパケットへ付加する。

3.2.1

モデル

輻輳適応型伝送のモデルを、図 3.1 に示す。各ノードの役割を次に示す。

• 送信ノード– 24 –

3.3 輻輳適応型伝送プロトコルの提案

コンテンツを送信するノード。ルールに従い伝送コンテンツの重み分けを行い、重みに応じた優先度を付加して送信する。

• ルータ群
パケットをフォワードするルータの集まり。各々のルータにおいて付加状況によって優先度の低いパケットより破棄する。

• パケットを受信するノード。受信パケットよりルールに従いコンテンツを再構築する。

このように、本手法では構成ノードがそれぞれの役割を果たす事により QoS 適応型伝送の定義に沿った品質を得る事ができる。

3.3

輻輳適応型伝送プロトコルの提案

本節では、 輻輳適応型伝送を実現するために規定する輻輳適応型伝送プロトコルの説明をする。
輻輳適応型伝送プロトコルはコンテンツの重み分け規則及びパケット構成方法を規定しており、送信・受信ノードのプレゼンテーション層に実装する機構である。本研究では、輻輳
適応型伝送プロトコルにおけるコンテンツの重み分け規則及びパケット構成方法の定義は行わない。

– 25 –

第4章

実験装置
輻輳適応型伝送モデルの実験環境を構築本研究では、輻輳適応型伝送モデルを想定した実験を行うために PC を準備し IPv6 ネットワークを構築した。また、輻輳適応型伝送モデル
における送信ノード、受信ノード、ルータ群の動作をシュミレーションするために UNIX 上で動作するソフトウェアを作成した。本章では、本研究の実験を行うために作成したソフト
ウェアについて解説する。

4.1

目標

本研究では、2 種類の実装実験を行うためにプログラムを作成した。それらのプログラムの実装により、次のような環境を構成する事を目標とした。

• 実装実験 1
実装実験 1 では、次のような環境において調査を行う。

– ID 付きのデータをコンテンツとして 輻輳適応型伝送プロトコルモデルに沿った伝送を行う– 輻輳適応型伝送モデルと比較するために、ID 付きのデータをコンテンツとして
UDP による伝送も行う– 輻輳適応型伝送モデルにおけるルータ群において輻輳状況を発生する– 受信したパケットを解析し、パケットの到達状況をグラフに記す想定する実験装置の構成を図 4.1 に示す。

• 実装実験 2– 26 –

4.2 仕様graphlog
sender node

receiver node

ID data

ID data

ID data

ID data

ID data

ID data
happen congestion

router group

図 4.1

実験 1 想定環境

実装実験 1 では、次のような環境において調査を行う。

– PPM 形式の画像ファイルをコンテンツとして輻輳適応型伝送プロトコルモデルに沿った伝送を行う– 輻輳適応型伝送モデルと比較するために、PPM 形式の画像ファイルをコンテンツ
として UDP により伝送を行う– 輻輳適応型伝送モデルにおけるルータ群において輻輳状況が発生する– 受信したパケットを解析し、画像を再構成する想定する実験装置の構成を図 4.2 に示す。

4.2

仕様

前節で想定した環境を構築するために、次のような仕様に基づくプログラムを作成した。

– 27 –

4.2 仕様picturepicturereconstruction

PPM

PPM
log
sender node

receiver node

ID data

ID data

ID data

ID data

ID data

ID data
happen congestion

router group

図 4.2

4.2.1

実験 2 想定環境

lossGen輻輳適応型伝送プロトコルモデルにおけるルータ群の動作をシミュレートするプログラ
ム。複数のキューを有し、指定の確率により輻輳状況を発生させる。

内部仕様
本プログラムは、パケット受信部、キュー、パケット送信部により構成する。各部位の構成を図 4.3 に示す。また、各部位の機構を次に示す。

• パケット受信部
ネットワークよりパケットを受信し、パケットに付加された優先度を判別して優先度に応じたキューへパケットを格納する。

• キュー– 28 –

4.2 仕様priority 0priority 1receive unit

priority 2

send unit

priority 9priority queue

図 4.3 lossGen 内部構成

パケットを格納するバッファで、優先度別に 10 本用意する。それぞれのキューは独立しており、キューが一杯の場合は先頭のパケットより破棄する。

• パケット送信部
優先度の高いキューよりパケットを捜査し、初めに見つかったパケットを送信する。
また、輻輳状態を生成するために、キューからパケットを取得する直前に 0 から 100 までの乱数 R を生成し、輻輳状況発生率 P と比べてR>Pである場合のみ送信処理を行うようにする。

4.2.2

sendCATP

パケットに優先度及び ID を付加して指定したホストへ送信するプログラム。

– 29 –

4.2 仕様picture loader

PPM

ppm

balancerbalanced ppm

packet senderprioritied packet

図 4.4 sendPPM 内部構造

内部仕様
本プログラムでは、0 から 999999 までの ID を付けたパケットを送出する。パケットに付ける優先度 pri は、ID の値に対して

pri = ID mod 10という規則によって決定する。

4.2.3

sendPPM

ファイルから PPM 形式の画像を読み込み、画像情報の重み分けを行い、優先度を付加して送信する。

内部仕様
本プログラムは画像読み込み部、重み分け部、パケット送信部により構成する。各部位の構成を図 4.4 に示す。また、各部位の機構を次に示す。

• 画像読み込み部– 30 –

4.2 仕様

PPM 形式のファイルを読み込む。
• 重み分け部
図 4.5 に示すような手法で画像情報を重み分けする。

ppm Pix

B
color

G
R

gradation

1
0
0
1
1
0
1
0
0

0
0
1
0
1
1
0
1
0

0
0
1
0
1
0
1
1
1

0
1
0
1
0
0
1
0
0

0
1
0
1
0
1
1
0
0

0
1
1
1
0
1
1
0
0

1
1
1
0
0
0
1
0
0

1
0
0
0
1
0
0
1
0

densitypriority

LSB

high

MSB

low

group

図 4.5

画像の重み分け手法

1. 各ピクセルを RGB 成分に分割する
2. 8 ピクセル分の要素を 1 グループとする
3. 階調度をビット表記し、上位ビットのグループほど高い優先度とする• パケット送信部
重み分けした画像情報の重要度に対応した優先度をパケットデータ部の先頭に付加して
送信する。

4.2.4

recvCATP

パケット受信プログラム。受信をしたパケットのパケットデータ部を標準出力に出力する。このプログラムは受け取ったパケットを出力するだけである。出力結果より、後述する– 31 –

4.2 仕様

logAnalyser や ppmAnalyser を利用してパケットの解析及びデータの再構成を行う。

4.2.5

logAnalyser

recvCATP により作成されたパケット受信ログを解析し、パケットの到達状況を示す。

内部仕様
本プログラムは、ログ読み込み部、ログ解析部、到達状況表示部により構成した。各コン
ポーネントの機能を次に示す。

• ログ読み込み部
ログファイルより、到達パケット情報を読み込む。

• ログ解析部
到達パケット情報に含まれる ID 及び優先度を解析し、優先度別に 10000 毎のパケット
到達率を調べる。

• 到達状況表示部
解析結果を表計算ソフトでグラフ化するために、タブ区切りで結果を表示する。

4.2.6

ppmAnalyser

recvCATP により作成されたパケット受信ログを解析し、PPM 形式の画像情報を再生
する。

内部仕様
本プログラムは、ログ読み込み部、ログ解析部、PPM 画像生成部により構成する。各部
位の構成と動作の流れを図 4.6 に示す。また、各コンポーネントの機能を以下に示す。

• ログ読み込み部– 32 –

4.2 仕様

log reader

log
read

log data

log analyser

ppm restructure data

ppm remaker
write

PPM

図 4.6 ppmAnalyser 内部構造

ログファイルより、到達パケット情報を読み込む。

• ログ解析部
到達パケット情報に含まれる sendPPM より送信された画像情報を読み込み、再生画像情報を構築する。

• PPM 画像生成部
未到達のパケットは 0 で補正し、再生画像情報より PPM 画像を生成する。

– 33 –

第5章

実証実験
輻輳適応型伝送モデルに従い環境を構築し、コンテンツの伝送を行った。本章ではその優位性を評価した実験内容を解説する。また、実験結果より考察を行う。

5.1

実験 1

本実験では、輻輳適応型伝送モデルにおけるルータ群において輻輳状況が発生した場合、
輻輳適応型伝送プロトコルを用いて伝送を行うとパケットの到達状況はどのようなものになるか調べる。

5.1.1

実験ネットワーク輻輳適応型伝送モデルに沿って図 5.1 に示すネットワークを構築した。
各ノードの解説を次に示す。

• senderPC輻輳適応型伝送モデルにおける、送信ノードの役割を果たす。プログラム sendCATP を利用して 輻輳適応型伝送プロトコルを用いてパケットを送信する。パケットを 1000000
個送り、送信順に対応した ID を付加した。

• paclet loss generate PC
輻輳適応型伝送モデルにおけるルータ群の役割を果たす。プログラム lossGen を利用し、指定の輻輳状態を発生させる。

• receivePC– 34 –

5.1 実験 1

senderPC

sendCATPMR1::1
12::/64::2
packet loss genarate PC

lossGenMR2::2
23::/64::3
receiverPC

recvCATP, logAnalyser

MR3

図 5.1

実験 1 で用いるネットワーク

輻輳適応型伝送モデルにおける受信ノードの役割を果たす。プログラム recvCATP を用いてパケットを受信する。また受信したパケットを、プログラム logAnalyser で解析する。
また、各ノードのマシン構成を表 5.1 に示す。
ノード

senderPC

packet loss generate PC

receivePC

マシン名

MR1

MR2

MR3

IP addr / prefixlen

12::1 / 64

12::2 / 64

23::3 / 64

23::2 / 64
CPU

PentiumIII

PentiumIII

PentiumIII

クロック周波数450MHz450MHz450MHz

メモリ

64MB

64MB

64MB

OS

FreeBSD 4.4

FreeBSD 4.4

FreeBSD 4.4

表 5.1

実験 1 のマシン構成– 35 –

5.1 実験 1

5.1.2

実験方法

以下の手順で実験を行った。

1. packet loss create PC において、パケットロスの発生率を指定して lossGen を起動する。

2. recverPC において、recvCATP を起動し、受信待機をする。
3. senderPC において sendCATP を起動し、伝送を開始する。
4. senderPC において sendCATP がパケットを送出を終了するのを確認する。
5. receiverPC において logAnalyser を利用してログを解析してタブ区切りの表計算ファ
イルを作成する。

6. 表計算ソフトウェアでタブ区切りのファイルを読み込みグラフを作成する。

5.1.3

実験結果

実験の結果、パケットロス率が各 0%、20%、40%、60%、80%の場合において図 5.2、図5.3、図 5.4、図 5.6 に示すようなグラフを得た。グラフにおける x 軸はパケット ID を、y
軸はパケットの到達率を、z 軸は各優先度を示している。
また、グラフより得る事のできたパケット平均到達状況を表 5.2 にまとめる。

5.1.4

考察

図 5.2、図 5.3、図 5.4、図 5.5、図 5.6 より、パケットロス率が増えるのに従い、優先度の低いパケットから破棄されている事が分かる。
また表 5.2 より、全て到達する優先度とパケット平均総到達量の関係を調査し表 5.3 に示した。表 5.3 より、パケットの到達状況を次のように示すことができると分かった。
輻輳適応型伝送モデルにおいて送信ノードより AllSendP 個のパケットを送信したとする。優先度 p のパケットは PriPacket(p) 個送信されており、途中で順序入れ換えが行われ– 36 –

5.1 実験 1

図 5.2

パケットロス率 0 % のパケット到達状況

図 5.3

パケットロス率 20 % のパケット到達状況– 37 –

5.1 実験 1

図 5.4

パケットロス率 40 % のパケット到達状況

図 5.5

パケットロス率 60 % のパケット到達状況– 38 –

5.1 実験 1

図 5.6

パケットロス率 80 % のパケット到達状況

パケットロス率

0%

20 %

40 %

60 %

80 %

優先度 0 パケットの平均到達率 ( % )

100

100

100

100

100

優先度 1 パケットの平均到達率 ( % )

100

100

100

100

89.2

優先度 2 パケットの平均到達率 ( % )

100

100

100

100

0

優先度 3 パケットの平均到達率 ( % )

100

100

100

88.8

0

優先度 4 パケットの平均到達率 ( % )

100

100

100

0

0

優先度 5 パケットの平均到達率 ( % )

100

100

90.4

0

0

優先度 6 パケットの平均到達率 ( % )

100

100

0

0

0

優先度 7 パケットの平均到達率 ( % )

100

90.4

0

0

0

優先度 8 パケットの平均到達率 ( % )

100

0

0

0

0

優先度 9 パケットの平均到達率 ( % )

90.0

0

0

0

0

10000 パケット中の平均総到達量

9898

7903

5984

3887

1892

表 5.2

パケット平均到達状況– 39 –

5.2 実験 2

パケット破棄率 ( % )

0

20

40

60

80

10000 パケット中の平均総到達量

9898

7903

5964

3887

1892

全て到達する優先度

0〜8

0〜7

0〜4

0〜2

0

表 5.3

パケット到達量と優先度の関係ず、受信ノードにおいて ReceiveP 個のパケットを受信したとすると、
pri
X

PriPacket(i ) ≤ ReceiveP

(5.1)

i=0

を満たす優先度 pri までのパケットは全て到達しているといえる。また、ルータにおけるパケット破棄率 LossPer が分かれば、送信ホストでは
pri
X

PriPacket(i ) ≤ AllSendP × LossPer

(5.2)

i=0

を満たす優先度 pri までのパケットは全て到達しているといえる。
受信ノードにおいて、受信するデータのデータタイプと優先度付加規則が分かっていれば、式 5.1 より受信パケット数を知るだけで復元できるデータの度合が分かる。
また、1 対 1 の伝送の場合、送信ノードにおいてルータ上の定量的なパケット破棄量を知る事ができれば、ネットワークの負荷状況によって式 5.2 より送信パケット量を増減調整する事ができる。

5.2

実験 2

本実験では、輻輳適応型伝送モデルに従いコンテンツを伝送した場合、輻輳適応型伝送プ
ロトコルを利用する場合と利用しない場合を比較し、違いを調べる。

5.2.1

構築環境

輻輳適応型伝送モデルに沿って図 5.2.1 に示す環境を構築した。
各ノードの解説を次に示す。

– 40 –

5.2 実験 2

senderPC

sendPPMMR1::1
12::/64::2
packet loss genarate PC

lossGenMR2::2
23::/64::3
receiverPC

recvCATP, ppmAnalyser

MR3

図 5.7

実験 2 で用いるネットワーク• senderPC輻輳適応型伝送モデルにおける送信ノードの役割を果たす。プログラム sendPPM を利用し、 PPM 形式の画像をコンテンツとして輻輳適応型伝送プロトコルを用いてパケットを送信する。また、比較実験においては輻輳適応型伝送プロトコルを利用せずにUDP で送信する。
• packet loss generate PC
輻輳適応型伝送モデルにおけるルータ群の役割を果たす。プログラム lossGen を利用し、指定の確率で輻輳状況を発生させパケットを破棄する。

• receivePC
輻輳適応型伝送モデルにおける受信ノードの役割を果たす。プログラム recvCATP を用いてパケットを受信する。また、受信したパケットをプログラム ppmAnalyser で解析し、PPM 形式の画像を再生する。
また、各ノードのマシン構成を表 5.4 に示す。

– 41 –

5.2 実験 2

ノード

senderPC

packet loss generate PC

receivePC

マシン名

MR1

MR2

MR3

IP addr / prefixlen

12::1 / 64

12::2 / 64

23::3 / 64

23::2 / 64
CPU

PentiumIII

PentiumIII

PentiumIII

クロック周波数450MHz450MHz450MHz

メモリ

64MB

64MB

64MB

OS

FreeBSD 4.4

FreeBSD 4.4

FreeBSD 4.4

表 5.4

5.2.2

実験 2 のマシン構成

実験方法

次の手順で実験を行った。

1. packet loss generate PC において、パケットロスの発生率を指定して lossGen を起動する。

2. receivePC において、recvCATP を起動し、受信待機をする。
3. senderPC において、 sendPPM を起動し、伝送を開始する。
4. senderPC において、 secdPPM がパケットの送出を終了するのを確認する。
5. receiverPC において、 ppmAnalyser を利用してログを解析して PPM 画像を再生
する。

5.2.3

実験結果

実験の結果、パケットロス率が各 0%、20%、40%、60%、80%の場合において図 5.8、図5.9、図 5.10、図 5.12 に示すようなグラフを得た。

– 42 –

5.2 実験 2

図 5.8

破棄率 0 % における輻輳適応型伝送プロトコルを用いた場合 (左) と用いない場合 (右) の画像比較

図 5.9

破棄率 20 % における輻輳適応型伝送プロトコルを用いた場合 (左) と用いな

い場合 (右) の画像比較

図 5.10 破棄率 40 % における輻輳適応型伝送プロトコルを用いた場合 (左) と用いな
い場合 (右) の画像比較– 43 –

5.2 実験 2

5.2.4

考察

図 5.8 、図 5.9、図 5.10 、図 5.11 、図 5.12 より、パケットロス率が増加するのに伴い、
輻輳適応型伝送プロトコルを利用して伝送している場合は色解像度が低下していったのに対して、輻輳適応型伝送プロトコルを利用しない場合はノイズにより視認が困難になっている事が分かる。
この結果より、輻輳適応型伝送モデルを利用して重み分けを行ったコンテンツを伝送すれば、輻輳適応型伝送を利用しない場合に比べて高い品質を得る事ができると分かった。

– 44 –

5.2 実験 2

図 5.11 破棄率 60 % における輻輳適応型伝送プロトコルを用いた場合 (左) と用いな
い場合 (右) の画像比較

図 5.12 破棄率 80 % における輻輳適応型伝送プロトコルを用いた場合 (左) と用いな
い場合 (右) の画像比較– 45 –

第6章

まとめ
本研究では、QoS 適応型伝送を提案し、QoS 適応型伝送のモデルである輻輳適応型伝送モデルを提案した。また、輻輳適応型伝送モデルにおける伝送機構である輻輳適応型伝送プ
ロトコルの提案を行った。
また、実証実験を行い、輻輳適応型伝送モデルは輻輳状況に適応した品質を提供できるという事を示した。以下では今後の課題を述べる。

6.1

今後の課題

6.1.1

トラフィッククラスフィールドの利用

本研究では、FreeBSD 4.4 にて実装されている IPv6 環境において RFC 2553 [8] を参考にトラフィッククラスフィールドの値を操作しようとしたものの操作できなかった。今後は原因を追求し利用をしたいと考えている。

6.1.2

JPEG を利用した実験

DCT 変換により正確に重み分けのされている JPEG を用いて輻輳適応型伝送モデル上で伝送を行う事により、重み分け理論を適用した輻輳適応型伝送モデルの優位性を示す事ができると考えている。

– 46 –

6.1 今後の課題

6.1.3

マルチキャストにおける 輻輳適応型伝送モデルの提案

本研究ではユニキャストにおけるモデルのみの提案であった。しかし、輻輳適応型伝送モデルは再送を想定としていないので、マルチキャストにおいても機能する。また、ネット
ワークの構造がシンプルであるため伝送の実時間性も高い。以上の事から輻輳適応型伝送モ
デルをマルチキャストに適用して伝送を行おうと考えている。

6.1.4

プレゼンテーション層も含めた送信機構の提案

輻輳適応型伝送モデルにおける送信ノードへの実装は、コンテンツの送信データタイプを決定するプレゼンテーション層であると考えている。ここでは、現段階において考案している送信ノードにおける伝送機構を紹介する。

動作概要
送信ノードは、プロトコルで定められた規則によって伝送するコンテンツを重み分けして、重要度に応じた優先度を IPv6 ヘッダのトラフィッククラスフィールドに格納してネッ
トワークへ送信する。

OSI 参照モデルに基づく伝送機構モデル
図 6.2 に示すように、OSI 参照モデルにおけるプレゼンテーション層に 輻輳適応型伝送プ
ロトコル送信機構を加える事により実現する。輻輳適応型伝送送信機構の動作を次に示す。

1. アプリケーション (Application) よりコンテンツ (contents) を受け取る。
2. 変換機構 (convert module) により、コンテンツフォーマットに対応した重み分けを行う。変換機構の動作を次に示す。
（a）コンテンツを受け取る（b）規則に従って重み分けを行う– 47 –

6.1 今後の課題

application layer

Application
contents

rules
presentation layer

convert module
layered contents
reconstruction mechanizm
priority contents stream

session layer

図 6.1

session輻輳適応型伝送プロトコル送信機構（c）重み分けしたコンテンツ (layered contents) を返す

3. 重み分けしたコンテンツを再構成機構 (reconstruction mechanizm) により送信順に並べ変える。再構成機構の動作を次に示す。

• 重み分けされたコンテンツを受け取る• 規則に従ってバッファリング、再構築を行う• 再構築したコンテンツに優先度を付加して返す
4. 優先度が付加されたコンテンツ (priority contents stream) をセッション層に渡す。

6.1.5

プレゼンテーション層も含めた受信機構の提案

輻輳適応型伝送モデルにおける受信ノードへの実装はコンテンツの受信データタイプによって再構成を行うため、プレゼンテーション層であると考えている。ここでは、元段階において思案している受信ノードにおける受信機構を紹介する。

– 48 –

6.1 今後の課題

動作概要
受信ノードは、受信したパケットをプロトコルに定められた規則に従い再構成してアプリ
ケーションへ送る。

OSI 参照モデルに基づく受信機構モデル
図 6.2 に示すように、OSI 参照モデルにおけるプレゼンテーション層に輻輳適応型伝送プ
ロトコル受信機構を加える事により実現する。CATP 受信機構の動作を次に示す。
Application

application layer

contents

rules
reconstruct mechanizm

priority contents stream
session layer

図 6.2

session輻輳適応型伝送プロトコル送信機構

1. セッション層より、優先度が付加されているパケット (priority contents stream) を受け取る。

2. 再構成機構 (construction organization) により、コンテンツを再構成する。再構成機
構の動作を次に示す。
（a）優先度が付加されたコンテンツを受け取る（b）規則に従って、再構成を行う（c）コンテンツ (contents) を返す– 49 –

6.1 今後の課題

3. アプリケーションにコンテンツを渡す
受信機構においては、これらの他にも受信していないパケットの判別方法や補償方法も考えなければならない。

6.1.6

ルータ群におけるパケットフォワード機構の提案

ここでは、現段階において考案しているルータにおけるルーティング機構を紹介する。

動作概要
各ルータにおいて、ネットワークの負荷状況によってトラフィッククラスフィールドに格納されている優先度の低いパケットより破棄する。

パケットフォワーディング機構モデル
送信ノードにおいて付加された優先度は、IPv6 ヘッダのトラフィッククラスフィールドに格納されている。図 6.3 に示すようにルータはネットワーク層でパケットフォワーディン
グを行う。
ルータの動作を次に示す。

1. 隣接ノードより、コンテンツを受信する。
2. ネットワーク層においてフォワーディングを行う。その際実装に求められる動作を次に示す。

• フォワーディングの際に IPv6 ヘッダのトラフィッククラスを参照する• パケットを破棄する際は、優先度に従って優先度の低いパケットから破棄する
3. ルーティングのアルゴリズムが示す隣接ノードへパケットを送信する。

– 50 –

6.1 今後の課題

router

network layer

packet fowarding module

data link layer

physical layer

図 6.3

フォワーディング機構モデル– 51 –

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

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

– 52 –

参考文献[1] Integrated services (intserv) charter. http://www. ietf.org/html.charters/intservcharter.html.
[2] A Ballardie. RFC2201 Core Based Trees (CBT) Multicast Routing Architecture.
Consultant, September 1997.
[3] R Braden and L Zhang. RFC2209 Resource ReSerVation Protocol (RSVP) – Version 1 Message Processing Rules. IETF, September 1997.
[4] S Deering and R Hinden. RFC1883 Internet Protocol and Version 6 (IPv6) specification. IETF, December 1995.
[5] S Deering and R Hinden. RFC2460 Internet Protocol,Version 6 (IPv6) specification.
IETF, December 1998.
[6] A Mankin ED, F Baker, B Braden, S Bradner, M O’Dell, A Romanow, A Weinrib, and L Zhang. RFC2208 Resource ReSerVation Protocol (RSVP) Version 1
Applicability Statement Some Guidelines on Deployment. IETF, September 1997.
[7] R Braden ED, L Zhang, S Herzog, and S Jamin. RFC2205 Resource ReSerVation
Protocol (RSVP) – Version 1 Functional Specification. IETF, September 1997.
[8] R Gilligan, S Thomson, J Bound, and W Stevens. RFC2553 Basic Socket Interface
Extensions for IPv6. IETF, March 1999.
[9] B W Kernighan and D M Richie. プログラミング言語 C. 共立出版, 第 2 版, 6 1989.
[10] Brian W Kernighan and Rob Pike. The Practice of Programming. Addison-Wesley,
1999.
[11] Thomas A Maufer. IP マルチキャスト入門. bit. 共立出版, 12 2000.
[12] S Shenker. RFC2215 General Characterization Parameters for Integrated Service
Network Elements. J Wrocklawski, September 1997.

– 53 –

参考文献[13] S Shenker, C Partridge, and R Guerin. RFC2212 Specification of Guranteed Qualityof Service. IETF, September 1997.
[14] J Wroclawski. RFC2211 Specification of the Controlled-Load Network Element
Service. IETF, September 1997.
[15] クリスチャン・ウイテマ. IPv6 次世代インターネット・プロトコル. 株式会社プレン
ティスホール出版, 1997.

[16] 阪田史郎. インターネットと QoS 制御. NetCom ライブラリ. 裳華房, 6 2001.
[17] 河野清尊. login:UNIX C システムプログラミング言語. オーム社, 1992.
[18] 山内長承. 高信頼マルチキャスト. 情報処理, pp. 754–759. 情報処理学会, 2001.
[19] 篠田陽一（編）. UNIX ネットワークプログラミング
トと XTI. ピアソン・エデュケーション, 第 2 版, 1999.

– 54 –

vol.1 ネットワーク API:ソケッ付録 A

映像配信実験

A.1

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

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

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

A.2

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

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

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

A.3

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

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

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

A.4

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

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

http://www.toyama-ix.net/event/gigafo2001/
IP 実験用 URL
http://www.toyama.ix.net/event/gigafo2001/index-ip.html• 日程2001 年 5 月 28 日
• 配信元
INTEC Web and Genome Informatics Corporation ?
• 番組内容富山国際会議場で行われたギガビットネットワークフォーラム 2001 の映像。プログラム
として、「ユビキタス＆ブロードバンドネットワークのビジネスインパクト」、「CAN(コ
ニュニティ エリア ネットワーク) とコアラ」、「高度情報通信ネットワーク社会の形成に向けて」、「地域における IT の取組と今後の課題」。

– 57 –

A.5 Live!Eclipse(日食)• 配信データ形式
DV over ATM (LinkUnit) (富山→石川、福井、福岡、三重、名古屋、岐阜、大阪、高知)

DV over IPv4 Multicast over ATM (DVTS)(高知→山梨、富山)
Realvideo,Windows Media over IPv4 Multicast over ATM (富山→高知、山梨、岐阜、富山地域 IX)

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

A.4.1

ネットワークトポロジー

図 A.1 参照。

A.5

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

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

• 配信データ形式– 58 –

A.5 Live!Eclipse(日食)

図 A.1

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

A.5.1

ネットワークトポロジー

図 A.2 参照。

– 59 –

A.6 DSM 中継

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

A.6

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

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

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

A.6.1

ネットワークトポロジー

図 A.3 参照。

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

A.7

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

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

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

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

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

A.8

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

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

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

– 62 –

A.8 新湊曳山祭り中継• 配信データ形式
DV over ATM (LinkUnit) (富山→ TRIX、福岡、岐阜)
DV over IPv6 over ATM (富山→高知、山梨)
WindowsMedia( 100,300Kpbs) (富山地域 IX へ)
DV over IPv6 Multicast over ATM (富山→高知、山梨) →失敗

A.8.1

ネットワークトポロジー

図 A.4 参照。

図 A.4

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

A.8 新湊曳山祭り中継

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

Dell Optiplex GX110

CPUPentium III 930 MHz, Memory: 512 MBOS

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

ATM-NIC

Efficient Networks ENI-155p (en0)

Eth-NIC

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

– 高知
CPU

Pentium

800 MHz,Memory:768 MBOS

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

ATM-NIC

Efficient Networks ENI-155p (en0)

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

– 山梨
CPU

Pentium III 600MHz, Memory: 256 MBOS

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

ATM-NIC

Efficient Networks ENI-155p (en0)

Eth-NIC• DVTS マシン

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

Dell Optiplex GX110

CPUPentium III 930 MHz, Memory: 512 MBOS

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

ieee1394

Digital Origin MotoDV (lynx0: Texas Instrument PCILynx)

Eth-NIC

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

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

A.9 みやぎ国体中継

PRODUCT

Dell Optiplex GX110

CPUPentium III 930 MHz, Memory: 512 MBOS

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

ieee1394

Digital Origin MotoDV (lynx0: Texas Instrument PCILynx)

ATM-NIC

Efficient Networks ENI-155p (en0)

Eth-NIC

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

software

DVTS-0.3.6

– 高知
CPU

Pentium

800MHz:Memory 768 MBOS

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

ieee1394

Digital Origin MotoDV (lynx0: Texas Instrument PCILynx)

Eth-NICIntel Pro10/100B/100+ Ethernet

software

DVTS-0.3.6

– 山梨

A.9

CPU

Pentium III 1GHz, Memory: 256 MBOS

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

ieee1394

Digital Origin MotoDV (lynx0: Texas Instrument PCILynx)

Eth-NICIntel Eter Express Pro (fxp0)

software

DVTS-0.3.6

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

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

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

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

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

2001 年 10 月 27 日 〜 10 月 30 日

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

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

A.10

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

http://www.toyama-tic.co.jp/isom/– 66 –

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

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

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

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

A.10.1

ネットワークトポロジー

図 A.5 参照。

A.11

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

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

• 番組内容– 67 –

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

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

沖縄で行われたギガビットネットワーク・シンポジウムの中継映像。

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