平成 12 年度
学士学位論文地域指向型ネットワークでのストリーム
配信
Stream Distribution on Regional Oriented Networks

1010399

杉山 道子

指導教員

菊池 豊

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

要 旨

地域指向型ネットワークでのストリーム配信
杉山 道子

地域間相互接続実験プロジェクトでは、研究ネットワーク RIBB (Regional Internet

BackBone) を JGN (Japan Gagabit Network) 上に構築し、次世代のサービスアーキテク
チャの実践的研究を行っている。また、我々は PIX (Pseudo Internet eXchange) モデルを提唱し、高知県における研究ネットワーク KPIX (Kochi PIX) で実験を進めている。
本研究の目的は、様々な機能やネットワーク構造およびポリシーを持った各地の地域ネッ
トワークを相互に接続することにより、単独では不可能な機能を提供することである。
今回は、RIBB と KPIX とを用いて動画配信サービスを実現することを目標とした。著者は、目標実現のために、富山国体中継とギガビットシンポジウム 2000 中継を行った。

6 日間、のべ約 60 時間に及ぶ、全国 8 都県への富山国体中継の結果は、パケットロスもほとんどなく十分な品質の動画を提供した。KPIX へのストリーム配信は、プロキシサーバ
を介さなかった場合は視聴可能、プロキシサーバを介した場合は視聴不能であった。
のべ約 8 時間に及ぶ全国 4 県へのギガビットシンポジウム 2000 中継結果は、20〜30 秒毎に 2 回程度の配信元が原因らしきノイズが観測されたものの、視聴者にとっては問題なく視聴出来る品質であった。KPIX へのストリーム配信は、視聴結果は不明であった。
これらの前例のない 2 つの中継実験の成功により、多くの異なる地域ネットワークの相互接続による動画像配信サービスが可能であることを実証した。

キーワード

ストリーミング, RIBB, KPIX, 富山国体, ギガビットシンポジウム 2000{i{

Abstract

Stream Distribution on Regional Oriented Networks
SUGIYAMA Michiko

RIBB was build a RIBB (Regional Internet BackBone) on JGN (Japan Gagabit Network), and wss researched service architecture next generation on it. Also We proposed
PIX (Pseudo Internet eXchange) model, and carry out investigations into PIX model
on KPIX (Kochi PIX).
The view for research is to provide a function impossible by itself by interconnecting
lot of Regional Networks has many functions, network structures and policys.
The goal for research is to achieve a service to distribution live-action I relay ToyamaKokutai and GigabitSymposium2000 for makeing it come true.
For six days solid, about 60 hours, The result of relay of ToyamaKokutai to 8 prefecture provided live-action of quality enough for audience, and there are pcketloss scantly.
The result of Distribution Stream to KPIX is It is possible to watch live-action in thecase of going through proxy server, It is no possible to watch live-action in the case of
nongoing through proxy server.
About 8 hours, The result of relay of GigabitSymposium2000 to 4 prefecture observe
some noise about 2 times per 20-30 seconds. but, The live-action was quality enoughfor audience. The result of Distribution Stream to KPIX unknown.
these success of unprecedented relay, I can substantiate that it is impossible to service to distribution live-action by interconnecting lot of Regional Networks has many
functions, network structures and policys.

{ ii {

key words

Streaming, RIBB, KPIX, ToyamaKokutai, GigabitSymposium2000{ iii {

目次
第1章

はじめに

1.1

用語集

第2章

2.1

1

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

3

地域指向型ネットワーク. . . . . . . . . . . . . . . . . . . . . .

3

2.1.1 研究内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5. . . . . . . . .

5

地域型高速アクセス回線の利用実験. . . . . . . . . . . . . . . . .

6分散型高速バックボーン技術の確立. . . . . . . . . . . . . . . . .

7

利用ネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . .

7. . . . . . . . . . . . . . . . .

7

KPIX 実験研究協議会 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.1 IX (Internet eXchange) . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.2

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

10

2.2.3 PIX モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

HAN (Harmonizing Area Network) . . . . . . . . . . . . . . . . .

11

2.2.4 KPIX(Kochi PIX) . . . . . . . . . . . . . . . . . . . . . . . . . .

15

KPIX における下位層の設計と構築 . . . . . . . . . . . . . . . . .

16

KPIX の特徴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.2.5 KPIX の経路制御 . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

PIX モデルの経路制御の問題点 . . . . . . . . . . . . . . . . . . . .

19

KPIX での実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

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

地域情報リソースの共有と分散情報環境の構築実験

2.1.2

研究開発用ギガビットネットワーク

2.2

第3章

1

地域 IX

21

ストリーミング技術{ iv {

目次

3.1

動画再生の方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.2

ストリーミングの流れ. . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.3

ユニキャストとマルチキャスト. . . . . . . . . . . . . . . . . . . . . . .

24

3.3.1

ユニキャスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.3.2

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

24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.4

バッファリング

3.5

圧縮技術. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.6

プロトコル

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

26

3.7

バリアブルビットレート . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.8

ストリーミングアプリケーション. . . . . . . . . . . . . . . . . . . . . .

27

3.8.1 Windows Media Technoloy . . . . . . . . . . . . . . . . . . . . .

27

Windows Media Encoder . . . . . . . . . . . . . . . . . . . . . .

28

Windows Media Service . . . . . . . . . . . . . . . . . . . . . . .

28

Windows Media Player . . . . . . . . . . . . . . . . . . . . . . .

28

3.8.2 Real System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

Real Producer . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

Real Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

Real Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

第4章

4.1

ストリーム配信によるマルチメディア放送実験

31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.1.1 JGN を利用したデジタルビデオによる高品質映像の配信実験 . . . .

31

4.1.2 映像ソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.1.3 トポロジー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

菊池研究室内の液晶テレビに表示 . . . . . . . . . . . . . . . . . . .

34

WMT を用いて KPIX へストリーム配信 . . . . . . . . . . . . . . .

34

富山国体映像中継{v{

目次

RealSystem を用いて KPIX へストリーム配信 . . . . . . . . . . .

34

ASX200 を用いて名古屋と岐阜へ再配信 . . . . . . . . . . . . . . .

35

4.1.4 ストリーム配信の設定とスペック . . . . . . . . . . . . . . . . . . .

35

4.1.5 KPIX への配信結果 . . . . . . . . . . . . . . . . . . . . . . . . . .

35

ギガビットシンポジウム 2000 中継. . . . . . . . . . . . . . . . . . . . .

37

4.2.1 映像ソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

4.2.2 トポロジー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

菊池研究室内の液晶テレビに表示 . . . . . . . . . . . . . . . . . . .

39

WMT を用いて KPIX へストリーム配信 . . . . . . . . . . . . . . .

40

DVTS を用いて富山と山梨に再配信 . . . . . . . . . . . . . . . . .

41

ストリーム配信の設定とスペック . . . . . . . . . . . . . . . . . . .

41

4.2.4 KPIX への配信結果 . . . . . . . . . . . . . . . . . . . . . . . . . .

41

まとめ

44

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

44

付録 A

KPIX の年表

46

付録 B

KPIX の活動履歴

50

Squid 動作モデルの設計 . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

B.1.1 設定変更にかかるコスト . . . . . . . . . . . . . . . . . . . . . . .

51. . . . . . . . . . . . . . . . . . . . .

51

参加組織のコンテンツを共有する Squid の設定 . . . . . . . . . . . . . . .

52

B.2.1 参加組織による HAN の構成 . . . . . . . . . . . . . . . . . . . . .

53

B.2.2 KPIX における典型的な WWW サーバ群の構成例 . . . . . . . . .

54

B.2.3 WWW サービスに対する要求 . . . . . . . . . . . . . . . . . . . .

55

B.2.4 サーバ群の連携パターン . . . . . . . . . . . . . . . . . . . . . . .

55

4.2

4.2.3

第5章

5.1

B.1

キャッシュサーバ連携モデル

B.2{ vi {

目次

B.2.5 リクエストに対するサーバ間の連携 . . . . . . . . . . . . . . . . .

57

B.2.6 各サーバの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

B.2.7 Squid によるサーバ群の実現 . . . . . . . . . . . . . . . . . . . . .

60

コンテンツを共有するサーバ間の連携 . . . . . . . . . . . . . . . . . . . .

62

B.3.1 リクエストに対するサーバ間の連携 . . . . . . . . . . . . . . . . .

63

コンテンツを共有する Squid の設定 . . . . . . . . . . . . . . . . . . . . .

66

B.4.1 各サーバの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

B.4.2 Squid によるサーバ群の実装 . . . . . . . . . . . . . . . . . . . . .

66

NTP による時刻同期 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

B.5.1 NTP とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

B.5.2 NTP の必要性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

B.5.3 NTP の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

B.5.4 NTP の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

B.6

MRTG による測定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

B.7

PIX モデルの諸問題とその解決手法 . . . . . . . . . . . . . . . . . . . . .

74

B.7.1 PIX モデル設計時の問題点 . . . . . . . . . . . . . . . . . . . . . .

75

B.7.2 問題点に対する解決法 . . . . . . . . . . . . . . . . . . . . . . . . .

75

B.7.3 KPIX での対応 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

B.3
B.4

B.5

B.8

富山国体映像中継

B.9

ギガビットシンポジウム 2000 中継. . . . . . . . . . . . . . . . . . . . .

76

B.10

pac ファイルの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

B.10.1 pac ファイルとは . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

B.10.2 pac ファイルの目的 . . . . . . . . . . . . . . . . . . . . . . . . . .

77

B.10.3 pac ファイルの記述 . . . . . . . . . . . . . . . . . . . . . . . . . .

77

B.10.4 pac ファイルの適用 . . . . . . . . . . . . . . . . . . . . . . . . . .

78

コストモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

B.11

{ vii {

目次

謝辞

81

参考文献

82

{ viii {図目次
2.1 JGN 通信回路構成図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92.2 HAN を構成する典型的な LAN の例 . . . . . . . . . . . . . . . . . . . . .

12

2.3 HAN を構成する最も小さい LAN の例 . . . . . . . . . . . . . . . . . . . .

13

2.4 HAN を構成するより大きな LAN の例 . . . . . . . . . . . . . . . . . . . .

14

2.5 4 つの LAN を持つ HAN の例 . . . . . . . . . . . . . . . . . . . . . . . .

15

2.6 インターネットから見た HAN . . . . . . . . . . . . . . . . . . . . . . . .

16

2.7 地域イントラネットとしての HAN . . . . . . . . . . . . . . . . . . . . . .

17

2.8 KPIX の無線リンク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.1 ストリーミング配信の基本構成 . . . . . . . . . . . . . . . . . . . . . . . .

23

3.2 ストリーミング配信の基本構成 . . . . . . . . . . . . . . . . . . . . . . . .

25

4.1 富山国体中継全体トポロジー . . . . . . . . . . . . . . . . . . . . . . . . .

32

4.2 富山国体中継トポロジー . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.3 富山国体中継全体トポロジー . . . . . . . . . . . . . . . . . . . . . . . . .

39

4.4 ギガビットシンポジウム 2000 トポロジー . . . . . . . . . . . . . . . . . .

40

B.1 KPIX のトポロジー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

B.2 参加組織による HAN の構成 . . . . . . . . . . . . . . . . . . . . . . . . .

54

B.3 KPIX における WWW サーバ群の構成 . . . . . . . . . . . . . . . . . . .

55

B.4 サーバ群の全連携パターン . . . . . . . . . . . . . . . . . . . . . . . . . .

56

B.5 制約を満たす連携パターン . . . . . . . . . . . . . . . . . . . . . . . . . .

56

B.6 KPIX におけるサーバ群の連携パターン . . . . . . . . . . . . . . . . . . .

57

B.7 PIX 上の公開コンテンツに対するリクエスト . . . . . . . . . . . . . . . . .

58

B.8 キャッシュされた公開コンテンツに対する同組織内からのリクエスト . . . .

58{ ix {

図目次

B.9 キャッシュされた公開コンテンツに対する他組織内からのリクエスト . . . .

59

B.10 非公開コンテンツに対するリクエスト . . . . . . . . . . . . . . . . . . . .

59

B.11 インターネット上の公開コンテンツに対するリクエスト . . . . . . . . . . .

60

B.12 インターネット上の公開コンテンツに対するリクエスト . . . . . . . . . . .

65

B.13 キャッシュされた公開コンテンツに対するリクエスト . . . . . . . . . . . .

66

B.14 日間キャッシュヒット . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

B.15 週間キャッシュヒット . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

B.16 PIX モデルの月額回線維持費用例 . . . . . . . . . . . . . . . . . . . . . . .

80

{x{

表目次
2.1 RIBB 参加組織 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2 KPIX 実験協議会参加組織 . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.3 無線 LAN ユニット能力一覧 . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.1 ストリーミングで使用するプロトコル . . . . . . . . . . . . . . . . . . . .

26

4.1 ストリームサーバの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.2 ストリームエンコーダの設定 . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.3 ストリームサーバの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.4 ストリームエンコーダの設定 . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.5 スペック比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.6 KPIX での富山国体中継視聴結果 . . . . . . . . . . . . . . . . . . . . . . .

38

4.7 ストリームサーバの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.8 ストリームエンコーダの設定 . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.9 KPIX でのギガビットシンポジウム 2000 中継視聴結果 . . . . . . . . . . .

43

B.1 KPIX トポロジーと設定量 . . . . . . . . . . . . . . . . . . . . . . . . . .

53

B.2 組織 X 内キャッシュサーバ A の動作 . . . . . . . . . . . . . . . . . . . . .

61

B.3 組織 X に対応する HAN 内キャッシュサーバ. . . . . . . . . . .

62

B.4 Squid A の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

B.5 PIX Squidの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

B.6 組織 X 内キャッシュサーバ A の動作 . . . . . . . . . . . . . . . . . . . . .

67

B.7 組織 X に対応する HAN 内キャッシュサーバ. . . . . . . . . . .

68

B.8 Squid A の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

B.9 PIX Squid{ xi {

の動作

の動作

表目次

B.10 MRTG 測定項目一覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

{ xii {

75

第1章

はじめに
地域間相互接続実験プロジェクトでは、研究ネットワーク RIBB (Regional Internet

BackBone) を JGN (Japan Gagabit Network) 上に構築し、次世代のサービスアーキテク
チャの実践的研究を行っている。また、我々は PIX (Pseudo Internet eXchange) モデルを提唱し、高知県における研究ネットワーク KPIX (Kochi PIX) で実験を進めている。
本研究の目的は、様々な機能やネットワーク構造およびポリシーを持った各地の地域ネッ
トワークを相互に接続することにより、単独では不可能な機能を提供することである。
今回は、RIBB と KPIX とを用いて動画配信サービスを実現することを目標とした。映像ソースとして富山国体中継とギガビットシンポジウム 2000 中継を採用した。
以下では、まず第 2 章で地域指向型ネットワークについて述べ、第 3 章でストリーミング
技術についての概念を説明する。そして、第 4 章では、富山国体中継とギガビットシンポジ
ウム 2000 中継について述べる。第 5 章ではまとめを行う。
著者はこれまでに、地域指向型ネットワークへのストリーム配信をテーマとし、
「地域間相
「KPIX
互接続実験プロジェクト」と「KPIX 実験研究協議会」に参加し研究を進めてきた。
実験研究協議会」における著者らの研究活動については付録にて紹介する。
以下ではでは本論文で使用する用語についてまとめた。

1.1

用語集

 MPLS (Multi Protocol Label Switch)

MPLS とは、MPLS ネットワーク内でパケットにラベルを付与し特定パケットを転送{1{

1.1 用語集することで、仮想パス上での転送が可能である。

 IEEE1394 (Institute of Electrical and Electronic Engineers 1394)
最大で 63 台の機器をデイジーチェーン接続またはツリー接続することができ、転送速
度は 100Mbps、200Mbps、400Mbps が規格化されている。機器を動作中に抜き差しすることができ、接続ケーブルによる電源の供給もできるようになっている。コンピュータと周辺機器を接続する規格として期待されており、家電を相互接続する家庭内 LANに利用する動きもある。すでに、デジタルビデオカメラの外部出力端子（DV 端子）に採用されている。Apple 社主導で開発が進んでいた時期のなごりで FireWire と呼ばれることもある。

 NTSC (National Television Standards Committee)

NTSC とは、地上波アナログカラーテレビ放送の方式を策定するアメリカの標準化委員会の名称。また、同委員会が 1953 年に策定した方式の名称。この方式は日本や北米、中南米で採用されている。水平方向の走査線数が 525 本で毎秒 30 フレームのインターレース方式で、水平走査周波数は 15.75MHz、垂直走査周波数は 60Hz である。

 DV

DV とは、ビデオテープレコーダ (VTR) の規格のひとつである。テープに映像をデジ
タルデータとして記録するため、編集や複製による劣化がない。データ形式には独自のものが使用されており、画面サイズは 720 × 480 ピクセル、フレームレートは 30fps、
圧縮率は 5 分の 1 である。

 DVTS (DV Transfer System)

DVTS とは、IEEE1394 上の DV と IP 上の DV の変換を行うシステムのことをいう。

{2{

第2章

地域指向型ネットワーク
地域指向型ネットワークとは、東京中心ではなく地域を中心としたネットワークのことをいう。
本研究では地域指向型ネットワークでのストリーム配信実験として、富山国体中継とギガ
ビットシンポジウム 2000 中継を行う。そのために、地域指向型ネットワークの説明が必要である。
この章では、地域指向型ネットワークを用いて実験・研究を行っている地域間相互接続実験プロジェクトと KPIX 実験研究協議会について説明する。

2.1

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

1999 年 5 月に林英輔教授麗澤大学をプロジェクトリーダとし開始された。正式名称を地域間相互接続実験プロジェクトとし、略称を RIBB (Regional Internet BackBone, RIBB)としている。以下 RIBB と呼ぶ。

RIBB では、プロジェクト参加組織（表 2.1）を中心として、現在のインターネットのアー
キテクチャに代わる次世代のサービスアーキテクチャの実践的研究を行っている [4]。具体的な目的は以下である。

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

2. 地域間において快適に地域型マルチメディア情報リソースを利用するため、xDSL やCATV を用いた地域型高速アクセス技術を確立する。

{3{

2.1 地域間相互接続実験プロジェクト
3. 地域間での情報流通を考慮した大規模分散型の超高速バックボーンアーキテクチャの設計・構築・運用を行うとともに、新技術を用いた経路制御技術の開発を目指す。

九州大学 情報基板センター
東北大学大型計算機センター
三重県立看護大学 看護学部
名古屋大学大型計算機センター
東京大学情報基板センター
会津大学先端技術研究センター
インターネット総合研究所
大阪大学 サイバーメディアセンタ
塩尻市 塩尻情報プラザ
九州芸術工科大学 芸術工学部 助手
総務省 通信総合研究所
日本インターネットエクスチェンジ
長野県情報技術試験場
仙台応用情報学研究振興財団 (TRIX)
徳島県ハイテクプラザ
九州工業大学 情報工学部 電子情報工学科
京都情報基板協議会
中国・四国インターネット協議会（広島大学）
ソフトピアジャパン
山梨県立女子短期大学（山梨次世代ネットワーク協議会）
麗澤大学
インテック・ウェブ・アンド・ゲノム・インフォマティクス
TAO 高知通信トラヒックリサーチセンター（高知工科大学内）

表 2.1 RIBB 参加組織

{4{

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

研究内容

RIBB における研究内容は、大きく 3 つに分かれる。地域情報リソースの共有と分散情報環境の構築実験、地域型高速アクセス回線の利用実験、散型高速バックボーン技術の確立の3 つである。以下でそれぞれの内容を説明する。

地域情報リソースの共有と分散情報環境の構築実験
国内の各地では、地域情報化施策や地域振興策などによって、デジタル画像やビデオライ
ブラリなどの高速・広帯域を必要とする様々な情報コンテンツや情報環境が提供されつつある。国内の地域情報流通、情報環境を考えた場合、これらの情報リソースを、地域内ばかり
でなく地域間においても有効に交換・共有することは非常に重要である。本プロジェクトでは、現在各地域で整備が進められている地域型マルチメディア情報コンテンツや、情報処理環境などの地域情報リソース、あるいは CATV や新聞社などが提供する地域型コンテンツなどを高速なバックボーンを用いて交換・共有し、次世代ネットワークにおける分散情報環
境の実現を目指す。以下に具体的な内容を示す。

 広域分散ファイルシステム
ひとつのデータを暗号化し、分散してディスクに保存する。分散されたデータ全てを揃えなくても数箇所の分散されたデータが集まれば復元できる。
例えば、6 箇所のディスクに分散してデータを保存する。そのうち 3 箇所にアクセスできれば、データは復元できる。2 箇所が侵入されてもデータは盗まれない。
このシステムから対障害性の向上や暗号化と組み合わせた安全なファイルシステムの確立が期待できる。

 分散サーバ技術

RingServer Project がある。このプロジェクトは、以下のようなシステム確立を目的としている。200GB クラスのコンテンツサーバを各地に分散し、同期技術を用いてすべてのサーバが常に同じコンテンツを保持している状態をつくる。ユーザからのリクエス{5{

2.1 地域間相互接続実験プロジェクト
トには、最適分散アクセス技術を用いて、最も近いサーバにアクセスを分散する。

地域型高速アクセス回線の利用実験
マルチメディア情報を利用するためには、ユーザは高速なアクセス回線を必要とする。既存のインターネットサービスでは低速なアクセスラインや通信回線の混雑などに影響され、広帯域を必要とする遠隔情報リソースを利用することはできない。本プロジェクトでは地域のインフラ技術のひとつとして xDSL や CATV などの高速ネットワークをギガビットネッ
トワークに接続し、上記の地域型マルチメディア情報リソースへの快適なアクセスを実現するための高速な地域型インフラの実験を行う。以下に具体的な内容を示す。

 2000 年とやま国体映像実験

2000 年とやま国体映像をソースとし、産官学の連携のもと、広帯域ネットワークを用いた映像伝送実験を行った。2000 年とやま国体映像実験については第 3 章で詳しく取り上げる。

 ギガビットシンポジウム 2000 映像実験
ギガビットシンポジウム 2000 映像をソースとし、広帯域ネットワークを用いた映像伝
送実験を行った。ギガビットシンポジウム 2000 映像実験については第 3 章で詳しく取り上げる。

 月食映像実験

2001 年 1 月 10 日の午前 3 時 30 分から午前 6 時 30 分にかけて日本各地で観測可能な月食をソースとし、広帯域ネットワークを用いた映像伝送実験を行った。
月食の映像はギガビットネットワークや衛星回線を利用し DV や MPEG2 で集結される。集結された映像は、分散ストリーム配信される。
分散ストリーム配信とは、ユーザにとって最適なサーバを選択し、ストリーム配信を行う配信方法である。RADIX を用いたリアルタイムの経路制御を利用し、Tenbin で

DNS を用いたアクセス分散を行うことで効率的、高品質なストリーム配信が可能で{6{

2.1 地域間相互接続実験プロジェクトある。

分散型高速バックボーン技術の確立
現在、国内のインターネットは東京一極集中型であり、国内のほとんどの通信は東京を経由して行われている。このため、上記の地域間での情報リソースの共有や地域間情報流通
は、現在の国内のインターネットトポロジでは実現不可能である。現在、国内の多くの地
域では地域情報ネットワークや相互接続点 (Internet eXchange, IX) などの構築が進められている。本プロジェクトでは、これらの間をギガビットネットワーク上で相互に接続することによって、高速・広帯域な地域間通信を実現する。特に地域間を接続するバックボーン
では、IETF (Internet Engineering Task Force) によって標準化が進められている MPLS
1 (Multi Protocol Label Switch) や IPv6 (Internet Protocol version 6) などの最新技術を用いることによって、次世代型の分散バックボーンアーキテクチャの設計・構築を進める。
以下に具体的な内容を示す。

 MPLS を用いた IXRIBB に MPLS を適用することで、仮想パス上で BGP4 によるトラヒック交換が可能になり、RIBB ネットワーク上での広域 IX が実現可能である。

2.1.2

利用ネットワーク

研究開発用ギガビットネットワーク
研究開発用ギガビットネットワーク (Japan Gagabit Network, JGN) 2 は、21 世紀における超高速ネットワークの現実に向け、超高速ネットワーク技術や高度アプリケーション技
術をはじめとする研究開発のための設備として、総務省（旧郵政省）の認可法人である通信・放送機構が整備を進めているネットワークで、平成 11 年度から平成 15 年度までの 5 年
1 第 1 章用語集参照
2 http://www.jgn.tao.go.jp/{7{

2.2 KPIX 実験研究協議会
間運営されることが予定されている。
この JGN は、全国 10 箇所の ATM (Asynchronous Transfer Mode) 交換設備及び 39 箇所の接続装置を超高速光ファイバで結んだネットワークと、全国 5 箇所の「共同利用型研究開発施設」及び「リサーチセンター」から構成される。ギガビットクラスのバックボーンが全国を縦断する研究用高速ネットワークである。
なお、JGN 通信回線及び共同利用型研究開発施設は、研究開発用として、大学、研究機
関、行政機関、地方自治体、企業等に無料で開放される。
現在では、127 のプロジェクトが利用している3 。また、高知県においては、TAO 高知通
信トラヒックリサーチセンターにその接続装置が設置され、ギガビットネットワークを利用した研究開発が行われている。

JGN の通信回路構成図を図 2.1 4 に示す。

2.2

KPIX 実験研究協議会

この節では KPIX 実験研究協議会について説明する。
はじめに IX について説明し、次に地域 IX を述べる。そして、我々が提唱している PIX
モデルについて説明し、最後に KPIX について説明する。

2.2.1

IX (Internet eXchange)

IX とは ISP (Internet Service Provider) を相互に接続する仕組みである。IX には、OSI
参照モデルの第 2 層であるデータリンク層で交換する仕組みと、第 3 層であるネットワーク
層で交換する方式がある。なお、機能する OSI 階層のいかんに関わらずトラフィックを交換する機構を IX と呼ぶ場合がある。これを広義の IX、第 2 層ないしは第 3 層による交換を指す場合を狭義の IX とし、以降は IX の狭義の IX を指すものとする。IX は大都市を中

3 2000 年 11 月現在
4 http://www.jgn.tao.go.jp/img/kousei2.gif{8{

2.2 KPIX 実験研究協議会

図 2.1

JGN 通信回路構成図

心とした交換を行う。このことは以下の観点から考えると問題である。

 対象障害通信経路上に障害が生じた際、別の地域での障害であっても、通信に影響を与える。

 レスポンス・スループット
大都市を中心の通信経路であることにより、地域内での通信のレスポンスやスルー
プットが他地域の通信の混雑状況に影響を受ける。

 人的資源や経済活動が地域に根付かない{9{

2.2 KPIX 実験研究協議会
トラフィックが大都市中心に交換されることにより、それを支える技術者や経済活
動も大都市に集中する状況が起こる。大手 IPS や IX に近い場所にデータセンターを置く事が妥当であり、トラフィックやコンテンツも集中する。

 通信経路に対する主体制・自治
大都市を中心とする IP 交換のトポロジーを持つと、経路制御の主体が大手 ISP や

IX になる。上で述べたような問題があることが分かっても、さらにそれが地域内のトラフィックであっても、問題は地域内では解決できない。

2.2.2

地域 IX

大都市中心の交換による問題を解決するために、大都市以外に IX を置く動きが活発である。これを地域 IX と呼ぶ。
地域 IX には、IX の持つ問題の一部を解決するものの、IX 技術が持つ問題点をそのまま継承する側面もある。以下では地域 IX の持つ問題点を指摘する。

 ネゴシエーションコスト

ISP などの経路制御を統括する組織との協調に多くの労力が必要となることがある。インターネットの経路制御は BGP4 を用いるルータ間で AS (Autonomous

System) 全てに関する経路情報が交換される。このため、以下のような欠点がある。
{ 経路制御が複雑になり管理に高い技術が要請される{ 制御の影響を管理単位の組織で閉じることができない

技術者のスキルが十分に高くないと経路制御の混乱を招きやすい上に、一旦混乱を起こした場合には影響がインターネット全体に広がる。このため、地域 IX を計画した場合には、安定な運用を維持したい ISP などの理解と協力を得る事は難しい。

 スケーラビリティー
地域 IX の最も大きな問題は、比較的大きな地域による地域 IX が成功すると仮定
しても、さらに小さな単位の組織が同様の展開をするための環境を必ずしも提供し{ 10 {

2.2 KPIX 実験研究協議会ない事にある。地域 IX 導入には高い技術者を必要とするので、地域 IX を導入するコミュニティが小さくなればなるほど導入は難しくなる。このため地域 IX を導入する事は、コミュニティに則したネットワーク技術を導入する観点からは、望ま
しいとはいえない。

 効率
密なコミュニティであるほど、ユーザが同一コンテンツを参照する機会は多くなる。このような状況では IP データグラムの交換をスムーズにするよりも、コンテ
ンツの繰り返し転送を減少させる方が効率が大きい。コミュニティ構造とネット
ワーク構造が近いほどアプリケーション層で共有できるコンテンツのトラフィックが増え重複転送を避ける事による効率改善を促進する事が可能になると推測できる。しかし、IX は OSI 第 3 層以下での交換しか行わないので、この状況を活かした交換の効率化には全く寄与する事ができない。

 人材
地域 IX では、経路制御に高い技術レベルが要求されるため、いかに管理者を確保するかという問題がつきまとう。

2.2.3

PIX モデルPIX (Pseudo IX) モデルとは、直観的にいえば地域に閉じたイントラネットを構成し、イ
ンターネットとイントラネットとのトラフィック交換は全てアプリケーション層で行うようなモデルである [12]。

HAN (Harmonizing Area Network)

PIX モデルの構成要素である HAN について説明する。PIX モデルにおいて経路制御の単位を HAN と呼ぶ。HAN は地域内での IP データグラムの到達可能域であり、1 つ以上の組織 (LAN) から成る。あるネットワークが PIX モデルを用いている場合には、そのネッ{ 11 {

2.2 KPIX 実験研究協議会
トワークは 1 つ以上の HAN により構成されている。PIX モデルにおける HAN は BGP4における AS の概念に相当する。HAN を構成する各 LAN はインターネットへの通信路とHAN の通信路との 2 つの通信路を持つ。各 LAN は以下の 3 つの部分から成る。
1. インターネットから IP データグラム到達可能
2. HAN 内で IP データグラム交換可能
3. それ以外
前 2 者の重複している部分を HAN ボーダと呼び、以下の条件を満足するものとする。

 少なくとも 1 つのホストが存在する
 グローバルアドレスが与えられている
 トランジット (HAN ボーダを越えるような IP データグラムのフォワード) は行わない

HAN を構成する典型的な LAN のトポロジーを図 2.2 に示す。

図 2.2

HAN を構成する典型的な LAN の例{ 12 {

2.2 KPIX 実験研究協議会
四角はホストを示し、円と長円は IP が直接到達可能な領域を示している。左側の長円はインターネットを、右側の長円は HAN を、円は LAN を示している。HAN ボーダにファ
イアウォールを設置し、LAN のその他のホストは HAN からもインターネットからも IP 不到達であり、IP のトランジットは行わない。

HAN の一部を構成するような最も簡潔な LAN の形態は、図 2.3 に示すような HAN ボー
ダにただ 1 台のホストが存在する場合である。

図 2.3 HAN を構成する最も小さい LAN の例

長円の重複する部分がホスト 1 台から構成される LAN である。より複雑な LAN の例は
図 2.4 に示す。
これらのトポロジーを持つ LAN が集まって HAN 全体を構成する。図 2.5 は 1 つの HANの例である。
図 2.5 の場合、LAN は、A、B、C、D の 4 つより構成される。この図でも円や曲線で囲まれた領域が IP の到達可能域を示している。各 LAN の HAN ボーダは、ISP1、ISP2、

ISP3、ISP4 を経由してインターネットと IP の交換を行う。

{ 13 {

2.2 KPIX 実験研究協議会

図 2.4 HAN を構成するより大きな LAN の例

インターネットと HAN 内のホストとは HAN ボーダを越えて IP を交換することは無い。
したがって、IP データグラムの到達可能性の視点で見ると、インターネット側からはいく
つかの LAN が ISP 経由で接続されているようにしか見えない (図 2.6)。
同様に HAN の内側からは、いくつかの LAN が HAN を経由して IP 接続されている地
域イントラネットのようにしか見えない (図 2.7)。

IP データグラムの到達保証が HAN の十分条件である。トポロジーを含むデータリンク
層以下の構成は、HAN を構成する地域の実情に応じて決定することになる。たとえば、中核となるルータを準備し、そこから各 HAN ボーダに方謝状に通信路を張っても構わないし、

HAN ボーダ全てを直線上に接続しても構わない。また、データリンク層を構成する技術がEthernet であっても専用線であってもスペクトラム拡散方式の無線であっても構わない。

{ 14 {

2.2 KPIX 実験研究協議会

図 2.5

2.2.4

4 つの LAN を持つ HAN の例

KPIX(Kochi PIX)

我々は産官学からなる KPIX 実験研究協議会を 1998 年 7 月 13 日に設立し、PIX モデルの実用化に向けた研究活動を行っている。また、この協議会は高知県での地域情報化プロ
ジェクトである KOCHI 2001 PLAN で定める協議会である。そして、事務局を高知県企画振興部情報企画課に置く。本協議会参加メンバーの組織（表 2.2）を中心として、PIX モデ
ルの実証実験を行っている。我々は、KPIX の構築・運営を通して、PIX モデルの構築・運用ノウハウの確立を目的としている。
産業

官庁

学術

高知システムズ高知県情報企画課

高知工科大学

シティネット

高知県工業技術センター

高知大学
高知高専

富士通高知システムズ
表 2.2 KPIX 実験協議会参加組織{ 15 {

2.2 KPIX 実験研究協議会

図 2.6 インターネットから見た HAN

KPIX における下位層の設計と構築

本節では、KPIX の下位層の設計と構築について述べる。ここで述べる内容は PIX モデルとは直接関係がない。これは、PIX モデルがネットワーク層以上についての概念であるためである。しかし、実際には PIX モデルは地域での応用を目指しているため、地域内でのデータリンクをどのように構築するかという問題は間接的に関係してくる。

KPIX では、HAN を構成するためのインフラに一部 KCAN (Kochi City-size Area
Network)[5] を使用している。一部とした理由として、KPIX は独自の専用線として無線
LAN ユニットを使用しているためである。KCAN は高知市・南国市をまたがる東西におよそ 20km、南北におよそ 10km を無線 LAN ユニットを使用し構築している。ネットワーク
としては、プライベート IP アドレスを中央基幹セグメント・東部セグメント・西部セグメ
ント・正蓮寺セグメント・土佐希望の家セグメントの 5 つのセグメントに分割し運用している。以下より、KPIX のインフラとして KCAN の無線ネットワークを含むものとする。

{ 16 {

2.2 KPIX 実験研究協議会

図 2.7

地域イントラネットとしての HAN

KPIX のネットワークを図 2.8 に示す。この図で四角は中継ポイントを、丸は接続ポイン
トを示している。
無線 LAN をデータリンクとして選択したのは、初期投資を除けばわずかなランニングコ
ストでの運用が可能であるためである。無線 LAN ユニットは、株式会社コーラス社製5 の「LAN Any-where B10」とアイコム株式会社製6 の「BR-200」を選択した。これらの簡単なスペックを図 2.3 に挙げる。KPIX を構成する HAN はこれらの無線 LAN ユニットを組
み合わせて構築されている。
これ らの無 線 LAN ユニッ トの通 信方式 には 2.4GHz 帯のスペ クト ラム拡 散方式 を使っている。また、これらの無線 LAN ユニットは直接拡散方式（DirectSequence Spread

Spectrum、以下 DSSS とする）を採用している。スペクトラム拡散方式の無線を選択したのは以下の利点があるためである。

5 http://www.callus.co.jp/
6 http://www.icom.co.jp/{ 17 {

2.2 KPIX 実験研究協議会

図 2.8 KPIX の無線リンク

 無線局免許、無線従事者免許が不要である
 秘話製、秘匿性に優れている
 天候の変化による影響を受けにくい 高速の伝送路としては、初期コスト及び運用コストが低廉である
 小型、軽量、小消費電力の割に長距離（数 km）の通信が可能である

KPIX の特徴

KPIX の特徴を述べる。

{ 18 {

2.2 KPIX 実験研究協議会

通信距離
通信速度

（カタログ値）

通信方式

B10

11Mbps

約 5km

スペクトラム拡散方式 (DSSS)

BR-200

2Mbps

約 2km

スペクトラム拡散方式 (DSSS)

表 2.3 無線 LAN ユニット能力一覧

KPIX はデータリンクとして無線 LAN を用いている。これにより、HAN を構成する回線の維持費が安価になっている。
現在、KPIX で交換するアプリケーションプロトコルは HTTP である。HTTP を交換するために、フリーのプロキシキャッシュサーバである Squid を使っている。また Squid の動作連携は、PIX モデルの基本動作連携である 12 通りとは異なる構成を取っている。これは、KPIX 参加組織のポリシーを満たす構成を取ったためである。

KPIX は将来、ストリーム型のデータをキャッシュし、地域にとって有益なコンテンツの増加を目指す。
以降、一般的な PIX モデルのことを「PIX モデル」、高知県で PIX モデルの実証実験として構築しているものを「KPIX」と呼ぶ。

2.2.5

KPIX の経路制御

KPIX では PIX モデルの経路制御設計とは異なった設計、実装を行っている。この章では KPIX の経路制御設計の PIX と異なる点を挙げ、KPIX における設計を示す。

PIX モデルの経路制御の問題点

PIX モデルの経路制御ポリシーでは、HAN ボーダと HAN とは IP reachable である。
すなわち、全ての組織内の HAN ボーダは、互いに IP reachable である。そのため、HAN
ボーダを互いに IP reachable にするために設定を行う必要がある。しかし、PIX で接続さ

{ 19 {

2.2 KPIX 実験研究協議会
れる各組織はそれぞれの組織内の経路制御に関するポリシーを持っている場合がある。その場合、ポリシーによっては HAN ボーダを互いに IP reachable にするための設定が行えない場合がある。このような場合は、ゲートウェイを設置する場所が IP reachable でなくな
り、PIX モデルが要求するトラフィック交換のモデルを実現できない可能性がある。

KPIX での実装

KPIX では以下の理由により、PIX モデルの経路制御ポリシーとは異なったポリシーを採用している。

 下位層として KCAN のリンクを利用している

KCAN は KPIX とは別のネットワーク組織であるため、KPIX の経路情報がKCAN に流れるのは好ましくない。
 KPIX で利用しているルータが OSPF を実装していない

KPIX 参加組織の多くは、組織内の経路制御を OSPF を用いて行っていたが、KPIX で採用したルータが OSPF に対応しておらず、経路情報の交換が不可能であった。

PIX 参加組織の数が少ない場合は、静的ルーティングを行うことで上記のような問題がある場合でも PIX の設計に基づいた経路制御設計が可能である。しかし、その場合は PIX 参
加組織の増減に伴なって経路情報の更新が必要となり、管理コストが増加するため PIX のメリットが減少する。

KPIX では PIX モデルにおける HAN ボーダを作らず、各組織内 LAN と HAN とは IPreachable ではない。そこで各組織内 LAN と HAN とを繋ぐルータの両側にキャッシュ
サーバを設置し、その二つのホストの間のみに対する静的経路を設定している。つまり、二台のゲートウェイをセットにして、組織内 LAN、HAN 両方から同様に見えるように設定
し、あたかも一台の HAN ボーダが存在するかのように見せている。

{ 20 {

第3章

ストリーミング技術
ストリーミングとは、インターネットなどのネットワークを通じて映像や音声などのマル
チメディアデータを視聴する際に、データを受信しながら同時に再生を行う方式のことをいう。
本研究では地域指向型ネットワークでのストリーム配信実験として、富山国体中継とギガビットシンポジウム 2000 中継を行う。そのために、ストリーミング技術の説明が必要である。
この章ではストリーミング技術について説明する [9] [8] [7] [10]。

3.1

動画再生の方法

現在、動画を符号化してから再生するまでの方法にダウンロード再生、疑似ストリーミン
グ、ストリーミングの 3 種類がある。
ダウンロード再生は、一度にデータをクライアント側に転送し、転送終了後に再生を開始する。このことから、再生開始までの時間はデータサイズと回線容量に依存する。また、転送時にクライアント側に複製することからデータサイズ分のディスクの空き容量を必要とする。サーバ・クライアント間の制御はない。
疑似ストリーミングは、一度にデータをクライアント側に転送し、転送終了を待たずに再生を開始する。このことから、再生開始までの時間はデータサイズと回線容量に依存しない。また、転送時にクライアント側に複製することからデータサイズ分のディスクの空き容量を必要とする。サーバ・クライアント間の帯域制御はない。クライアントではバッファリ{ 21 {

3.2 ストリーミングの流れ
ングが行われる。
ストリーミングは、連続的にデータを転送し、転送終了を待たずに再生を開始する。転送終了を待たずに再生を開始するので、再生開始までの時間はデータサイズと回線容量に依存しない。また、転送時にクライアント側に複製しないことから、データサイズ分のディスクの空き容量を必要としない。サーバ・クライアント間の帯域制御やバッファリング等の技術を応用し安定した伝送が可能である。

3.2

ストリーミングの流れ

ストリーミングの流れは、エンコーダ、ストリーミング配信サーバ、クライアントの 3 つ。
の構成から成る（図 3.1）
エンコーダは、ビデオキャプチャボードやサウンドボードを用いて、映像や音声をデジタル化した後、MPEG などの圧縮アルゴリズムを使ってデータ圧縮をする。圧縮されたデー
タはストリームデータとして保存されたり、パケット化し、配信サーバに転送されたりする。
配信サーバ（ストリーミングサーバ）は、エンコーダが生成したストリームデータをクライアントからの要求に応じて、クライアントにストリーム配信する。また、ネットワークの状況に合わせてストリームの帯域を動的に変更したり、マルチキャストやユニキャスト、

TCP (User Datagram Protocol) や UDP (Transmission Control Protocol) などから適切なプロトコルを選択するといった処理などを行う。配信方式としては、ライブ方式とオンデ
マンド方式がある。

 ライブ方式
ライブ方式は、エンコードしたデータを直接ストリームサーバに転送し、クライアントからの要求に応じてストリームサーバがクライアントへストリーム配信する。ストリー
ミングはライブ方式のみである。視聴時間に制限があり、配信時間内のみ視聴可能である。

 オンデマンド方式{ 22 {

3.2 ストリーミングの流れ
オンデマンド方式は、エンコードしたデータを直接ストリームサーバに転送せずに、HDD 等に蓄積する。クライアントからの要求に応じてストリームサーバがクライアン
トにストリーム配信する。ダウンロード再生と疑似ストリーミングはオンデマンド方式のみである。視聴時間に制限が無く、時間に因われずに視聴可能である。
クライアント (再生アプリケーション) は、受信したストリームデータをバファリングし、データをデコードして再生する。ライブ方式の場合は受動的な受信を行う。再生・停止のみ使用可能である。オンデマンド方式の場合は能動的な受信を行う。再生・停止に加え、早送り・巻き戻し・一時停止も使用可能である。

図 3.1

ストリーミング配信の基本構成{ 23 {

3.3 ユニキャストとマルチキャスト
3.3

ユニキャストとマルチキャスト

ストリーミングの下のレイヤの配信方法には、ユニキャストとマルチキャストがある（図

3.2）。
3.3.1

ユニキャストサーバの使用する帯域がクライアント数に依存する。この場合サーバの配信能力やネットワークの帯域などは、クライアントに比例した量が必要となる。

3.3.2

マルチキャストサーバの使用する帯域がクライアント数に依存しない。この場合ネットワーク上のルータ
でコンテンツをコピーするので、サーバの配信能力やネットワークの帯域などは、クライア
ント 1 台分で済む。

3.4

バッファリング

バッファリングは、ストリーミング再生をする際に、開始した時点ですぐにデータを再生
せずに、あらかじめ一定量のデータを蓄積してから再生を開始する方法である。
クライアントのアプリケーションはストリームデータを受信した際に、一定のバッファ領
域にデータを蓄積する。そして、再生時にバッファ領域から逐次データを取り出して再生を開始する。このことによりネットワークの混雑などで転送レートが一時的に低下してもバッファでこの遅れを吸収することが可能である。
再生直前にバッファへのデータの蓄積処理が発生する分、再生するまでに若干の遅延が発生する。特に高ビットレートのライブ映像を配信する場合では、クライアント側で数十秒のずれが生じることもあり、厳密にはリアルタイムではなくなる。

{ 24 {

3.5 圧縮技術

図 3.2

3.5

ストリーミング配信の基本構成

圧縮技術

動画のデータを無圧縮で伝送する場合、多くの帯域を必要とする。ストリーミングでは、データを圧縮することで帯域を有効に使用する。
圧縮方法には、可逆圧縮と不可逆圧縮がある。可逆圧縮は、不可逆圧縮より圧縮率が低い。
また、圧縮したデータを元通りに復元するので、圧縮前後でデータの品質は劣化しない。一方、不可逆圧縮は、可逆圧縮より圧縮率が高い。また、データを元通りに復元しないので、圧縮前後でデータの品質は劣化する。復元する際のデータの品質と圧縮率は反比例の関係であり、圧縮率を高くすれば品質は落ち、品質を高くすれば圧縮率は低くなる。ストリーミグ
では、後者の不可逆圧縮を採用している。
不可逆圧縮では、データの品質は劣化する。しかし、ストリーミングでは、映像と音声に、{ 25 {

3.6 プロトコル
それぞれに適した圧縮方式を用いることで、人間が視聴する際には支障はない品質になるよ
うに圧縮を行っている。

3.6

プロトコル

ストリーミングで使用するプロトコルを表 3.1 に示す。

5層
4層
3層

HTTP
RTP
TCP

UDP
IPunicast

UDP
IPmulticast

表 3.1 ストリーミングで使用するプロトコル

ストリーミングでは、クライアントがサーバにアクセスする際に、第 4 層の UDP とTCP、第 5 層の HTTP の 3 つのうちで適切なプロトコルが選択される。ストリーム配信では、TCP の信頼性より遅延の少なさを要求するため、UDP が多く利用される。

TCP では通信途中でエラーが検出されると、プロトコルレベルでデータの再送が行われる。このために、ストリーミングでは、データの遅延が発生して動画再生の流れに支障が出る可能性がある。UDP ではエラーを検出した場合に、パケットの再送は行わない。一時的にクオリティを落すことで、遅延なくデータ再生を続行するという処理が優先される。
ファイアウォールを経由した場合は、TCP や UDP による通信がうまくいかない場合がある。また、NAT を経由した場合は、UDP による通信がうまくいかない場合がある。このため、最初に UDP による接続を試みて、それがうまくいかない場合には、TCP や HTTP
による通信を試みるといった処理が通常行われる。

 RTP (Realtime Transport Protocol)

RTP は、ストリーム型データの伝送を目的としたプロトコルである。1996 年 1 月に「RFC1889」として標準化された。RTP は、TCP と同じトランスポート層のプロトコ{ 26 {

3.7 バリアブルビットレート
ルであり、再送制御はしない。また、RTP フレームのヘッダーには、マルチメディア・
データの符号化方式の識別に使うペイロード・タイプ識別子や、タイムスタンプ信号を埋め込める。そのため、画像や音声などをリアルタイムでやり取りする場合は、TCP でなく RTP の方が適している。同様のプロトコルに UDP がある。RTP にはデータ到達
時間の揺らぎ補正機能がある点が大きく違う。また、RTP は RTCP (real-time control

protocol) とセットで利用されることが多い。RTCP は、回線上の帯域幅の変化や伝送遅延などを上位アプリケーションに通知する機能を持つ。

3.7

バリアブルビットレート

バリアブルビットレート (Variable Bitrate) は、クライアントの受信状況に応じて、サーバがダイナミックに送信データのビットレートを変更する機能である。
サーバはネットワークの混雑等でクライアント側の受信状況が悪くなると、送信データの帯域を下げる。ネットワークの混雑等が解消されると、サーバは送信データの帯域を上げる。この機能を使用する場合はストリームコンテンツが複数のビットレートでエンコードされている必要がある。また、マルチキャストではこの機能は使用できない。

3.8

ストリーミングアプリケーション

この節では、代表的なストリーミングアプリケーションである Windows Media Technoloyと Real System について説明する。

3.8.1

Windows Media Technoloy

Windows Media Technoloy (WMT) は、Microsoft 社1 が開発・配布している、ストリー
ミングシステムである。

WMT とは、複数のソフトウェアの総称であり、コンテンツの作成から配信、再生までそ1 http://www.microsoft.com/{ 27 {

3.8 ストリーミングアプリケーション
れそれの機能を提供するさまざまなソフトウェアのことをいう。以下で WMT の基本的な

3 点のソフトウェアについて述べる。

Windows Media Encoder

Windows Media Encoder は、音声や動画のキャプチャからデータの圧縮までを行うための基本的なソフトウェアである。その他のコマンドラインツールやソフトウェアとあわせ、Windows Media Tools という名称で無償で配布されている。
エンコードの機能は、ActiveX コントロールとして提供されているので、Script や Visual

Basic など言語製品を用いてエンコーディングの自動化を行うことも可能である。
このエンコーダで作成されたデータはファイルの形で利用される。またライブのデータス
トリームとして数十人のユーザに配信することも可能である。

Windows Media Service

Windows2000 Server に標準的に付属しているストリームサーバである。Microsoft 社では Windows Media Service と呼んでいる。Windows Media Encoder でエンコードしたデータをクライアントへストリーム配信する。

UDP での配信やマルチキャストに対応し、このサーバを段階的に組み合わせることで多くのユーザに同コンテンツをストリーム配信することが可能である。
また、WindowsNT 向けには別途無償配布を行っている。

Windows Media Player

Windows Media Player は、音声や 動画 の再 生を 行 う。Internet Explorer ある いはOS2 に標準の機能として配布されており、無償の配布も行っている。Windows Media
2 Windows98 以降{ 28 {

3.8 ストリーミングアプリケーション
Player では CODEC (COder/DECoder) をインストールすることによって多くのメディア
コンテンツフォーマットに対応出来る。

3.8.2

Real System

Real System は、RealNetworks 社3 が開発・配布している、ストリーミングシステムである。

Real System とは、複数のソフトウェアの総称であり、コンテンツの作成から配信、再生までそれそれの機能を提供するさまざまなソフトウェアのことをいう。
また、Real System G2 では様々な機能が追加されている。以下で Real System の基本的な 3 点のソフトウェアについて述べる。

Real Producer

Real Producer は、音声や動画を圧縮しストリーミングに適したデジタルメディアクリッ
プに変換するエンコーディングツールである。
データをストリーム形式に変換し、RealServer へ転送を行ったり、ビデオファイルやサウンドファイルを独自のファイル (RealVideo、RealAudio) に変換したりする。
また、Real Producer には、有償のものに RealProducer Plus、無償のものに RealProducer

Basic がある。

Real Server

Real Server は、ストリームの同時配信、ライブ方式やオンデマンド方式に対応したストリームサーバである。Ral Producer でエンコードしたデータをクライアントへストリーム配信する。インターネットやイントラネットへのストリーム配信が可能である。

3 http://www.realnetworks.com/{ 29 {

3.8 ストリーミングアプリケーション
また、Real Server には、有償のものと無償のものがあり、ユーザ数等のライセンスにより、RealServer Basic、RealServer Plus、RealServer Professional、RealServer Intranet、

RealServer Plus for Academic、RealServer Professional for Academic などがある。最高
同時接続数は 2000 であり、すべてのサーバに、HTTP、RTSP、RTP、UDP、TCP/IP、

HTTP がサポートされている。

Real Player

Real Player は、音声や動画の再生を行う。
Real System G2 には、ビデオと共にテキストを表示する機能の SMIL (SynchronizedMultimedia Integration Language) など追加されている。
また、Real Player には、有償のものに RealPlayer Puls、無償のもに RealPlayer Basicがある。

{ 30 {

第4章

ストリーム配信によるマルチメディ
ア放送実験
この章では、本研究の目標実現のために行った、富山国体中継とギガビットシンポジウム

2000 中継について説明する。

4.1

富山国体映像中継

平成 12 年 10 月 14 日から 19 日に富山県にて 2000 年とやま国体秋季大会が開催された。
開催と同時に、RIBB では、富山国体における高度情報通信技術を利用したマルチメディア
配信実験を実施した。

4.1.1

JGN を利用したデジタルビデオによる高品質映像の配信実験

菊池研究室では JGN を利用したデジタルビデオによる高品質映像の配信実験に参加した。この配信実験は、JGN による超高速通信を利用し、デジタルビデオによる高品質映像
を富山県内外の接続拠点に配信し、大型スクリーンなどで上映し、超高速ネットワークを使った映像配信に関するノウハウを取得することを目標とする。

4.1.2

映像ソース

富山県にて開催される 2000 年とやま国体秋季大会の様子を CATV が撮影して、富山総合情報センターで 1 つにまとめた映像をソースとした。

{ 31 {

4.1 富山国体映像中継
4.1.3

トポロジー

富山国体中継の全体トポロジーを図 4.1 に示す。富山で撮影された映像は、JGN を用いて全国 8 都県（福島県、宮城県、山梨県、東京都、岐阜県、富山県、高知県、福岡県）へ配信される。配信先の全国 8 都県では、富山国体の模様を視聴することが可能である。また、インターネットによる配信も行ったため、インターネット経由の視聴が可能である。

図 4.1 富山国体中継全体トポロジー

図 4.2 に、本研究で携わった部分のトポロジーを示す。富山国体の映像は富山県の撮影地点から富山総合情報センターへ送られる。そして、JGN を経由して TAO 高知通信トラヒィックリサーチセンターに送られ、高知工科大学菊池研究室の ATM スイッチである

ASX200 まで送られる。また、富山総合情報センターから菊池研究室の ASX200 までの映像はすべて DV over ATM であり、1 本の PVC (Permanent Virtual Circuit) である。

{ 32 {

4.1 富山国体映像中継
ASX200 の設定を出力が 2 方向に出力されるように設定した。TAO 高知通信トラヒィッ
クリサーチセンターを経由して名古屋と岐阜へ再配信する流れと、菊池研究室の丹箱へ出力する流れの 2 方向である。さらに、菊池研究室の丹箱へ出力された映像を 3 方向に分ける。

1 本目は、菊池研究室内のビデオデッキを用いて液晶テレビに表示する。2 本目は、WMTを用いて KPIX へストリーム配信する。3 本目は、RealSystem を用いて KPIX へストリー
ム配信する。よって、ASX200 以降の映像の流れは全部で 4 方向となる。以下では、この 4方向を詳しく説明する。

図 4.2

富山国体中継トポロジー{ 33 {

4.1 富山国体映像中継
菊池研究室内の液晶テレビに表示
菊池研究室の ASX200 まで送られてきた映像を、DV over ATM で LinkUnit（図 4.2 中の丹箱。以下、丹箱と呼ぶ。
）へ転送する。丹箱へ転送された映像を、DV over IEEE13941 で
ビデオデッキへ転送する。ビデオデッキへ転送された映像を、NTSC に変換し液晶テレビに出力する。

WMT を用いて KPIX へストリーム配信

菊池研究室の ASX200 まで送られてきた映像を、DV over ATM で丹箱へ転送する。丹箱へ転送された映像を、DV over IEEE1394 で DVMC (DV Media Converter) へ転送する。

DVMC へ転送された映像を、NTSC2 (National Television Standards Committee) に変換し、ストリームエンコーダであり、ストリームサーバである phage に転送する。phage に転送された映像を、Windows Media Encoder でエンコードし、Windows Media Service
で KPIX へストリーム配信する。

phage からストリーム配信される映像は、高知工科大学のネットワーク（図 4.2 中のKUTPPA NET）と高知工科大学情報システム工学科のネットワーク（図 4.2 中の KUT
DISE Summit 群）を経由し、hachi まで転送される。hachi から violet に転送され、violet
は KPIX へ転送する。hachi と violet はプロキシサーバである。hachi は自組織キャッシュ
サーバであり、violet は自組織 KPIX 側キャッシュサーバである。

RealSystem を用いて KPIX へストリーム配信

WMT を用いて KPIX へストリーム配信と同様である。ただし、以下の部分が異なる。
ストリームエンコーダであり、ストリームサーバである heart に転送する。heart に転送された映像を、Real Producer でエンコードし、Real Server で KPIX へストリーム配信
1 第 1 章用語集参照
2 第 1 章用語集参照{ 34 {

4.1 富山国体映像中継する。

ASX200 を用いて名古屋と岐阜へ再配信

ASX200 まで転送された映像を、TAO 高知通信トラヒィックリサーチセンターを介し、JGN を経由して名古屋大学長谷川研究室と岐阜ソフトピアジャパンへ再配信する。また、
ASX200 から名古屋大学長谷川研究室と岐阜ソフトピアジャパンまでの映像はすべて DV
over ATM であり、1 本の PVC である。
4.1.4

ストリーム配信の設定とスペック

今回の KPIX へのストリーム配信にはストリームエンコーダとストリームサーバを 1 台のマシンで行った。表 4.1、表 4.2、表 4.3、表 4.4 に WMT (phage) と RealSystem (heart)の設定を示し、phage と heart のスペックは表 4.5 に示す。

WindowsMediaService (phage)
エイリアス

ToyamaKokutai

パスの種類

WindowsMedia エンコーダ

URL

http://210.163.147.134

ポート

8080

クライアント数

無制限

表 4.1

4.1.5

ストリームサーバの設定

KPIX への配信結果

14 日から 19 日の 6 日間、のべ約 60 時間に及ぶ全国 8 都県（福島県、宮城県、山梨県、東京都、岐阜県、富山県、高知県、福岡県）への中継は、パケットロスもほとんどなく十分な品質の動画を提供した。KPIX へのストリーム配信は、プロキシサーバを介さなかった場合{ 35 {

4.1 富山国体映像中継

WindowsMediaEncoder (phage)
最大ビットレート

512Kbps

オーディオ codec

Windows Media Audio V7

オーディオ形式

64kbps 44KHz stereo

ビデオ codec

Windows Media Video V7

ビデオサイズ352 × 288 (CIF)

フレームレート

30fps

キーフレームの間隔

4秒

画像の品質

0

表 4.2 ストリームエンコーダの設定

RealServer (heart)
URL

http://172.31.16.40:8080/ramgen/encoder/live.rm

ポート

8080

クライアント数25
表 4.3

ストリームサーバの設定は視聴可能、プロキシサーバを介した場合は視聴不能であった。
。KPIX 経由とは、KPIX 内の以下に KPIX での富山国体中継視聴結果を示す（表 4.6）

squid を経由した場合を指し、プロキシを介してストリーム配信サーバにアクセスする場合をいう。KCAN 経由とは、KPIX 内の squid を経由しない場合を指し、直接ストリーム配信
サーバにアクセスした場合をいう。インターネット経由とは、KPIX 経由でもなく、KCAN
経由でもなく、インターネットを経由してアクセスした場合を指す。KPIX 経由ではアクセス不能で、KCAN 経由とインターネット経由ではアクセス可能であった。

{ 36 {

4.2 ギガビットシンポジウム 2000 中継

RealProducer (heart)
56K Modem

Target Audience

Corporate LAN (150Kbps)

RealMedia Settings

Multi-rate SureStream

Audio Format

Voice Only

Video Quality

Smmothest Motion Video

表 4.4 ストリームエンコーダの設定

WMT (phage)

RealSystem (heart)

HHD

30G

20G

CPU

PenIII866MHz

PenIII600MHz

メモリ

512MB

640MB

ビデオキャプチャボード

Osprey-100

Osprey-1000

OS

Windows2000 Server

WindowsNT Server 4.0

ServerWindowsMediaService(Windows2000 Server に付属)

RealServer 7.0 Basic (free)

Encoder

WindowsMediaEncoder 7 (free)

RealProducer 8 Basic (free)

PlayerWindowsMediaPlayer 7 (free)

RealPlayer 8 Basic (free)

表 4.5 スペック比較

4.2

ギガビットシンポジウム 2000 中継

平成 12 年 11 月 8 日に北九州国際会議場をメイン会場とし、「ギガビットネットワーク・
シンポジウム 2000」が開催された。RIBB では、ギガビットネットワーク・シンポジウム

2000 の模様を JGN を用いて中継した。菊池研究室ではこのギガビットネットワーク・シン{ 37 {

4.2 ギガビットシンポジウム 2000 中継

経由

プロキシの有無視聴

KPIX 経由

有不能

KCAN 経由

無可能

インターネット経由

無可能

表 4.6 KPIX での富山国体中継視聴結果

ポジウム 2000 の映像を DVTS3 (DV Transfer System) を用いて DV over IEEE1394 から DV over IP に変換し、IP Multicast で RIBB 他組織へ再配信すると同時に、WMT を用いて KPIX へストリーム配信した。

4.2.1

映像ソース

北九州国際会議場で開催される、「ギガビットネットワーク・シンポジウム 2000」の様子(DV) をソースとする。
4.2.2

トポロジー

ギガビットシンポジウム 2000 中継の全体トポロジーを図 4.3 に示す。北九州国際会議場の映像は、JGN を用いて全国 4 県（愛知県、高知県、富山県、山梨県）へ配信される。配信
先の全国 4 県では、ギガビットシンポジウム 2000 の模様を視聴することが可能である。また、インターネットによる配信も行ったため、インターネット経由の視聴が可能である。
図 4.2 に、本研究で携わった部分のトポロジーを示す。北九州国際会議場の映像は、JGNを経由して名古屋大学大型計算機センターへ送られる。そして、JGN を経由して TAO 高知
通信トラヒックリサーチセンターに送られ、菊池研究室の ASX200 まで送られる。ASX200へ送られた映像は、丹箱へ送られる。また、名古屋大学大型計算機センターから菊池研究室の丹箱までの映像はすべて DV over ATM であり、1 本の PVC である。
3 第 1 章用語集参照{ 38 {

4.2 ギガビットシンポジウム 2000 中継

図 4.3 富山国体中継全体トポロジー

ASX200 から送られてきた映像を丹箱で、3 方向に分ける。1 本目は、菊池研究室内のビ
デオデッキを用いて液晶テレビに表示する。2 本目は、WMT を用いて KPIX へストリー
ム配信する。3 本目は、DVTS を用いて JGN を経由して富山と山梨に再配信する。以下では、この 3 方向を詳しく説明する。

菊池研究室内の液晶テレビに表示
富山国体中継の際と同様である。菊池研究室の ASX200 まで送られてきた映像を、DV

over ATM で丹箱へ転送する。丹箱へ転送された映像を、DV over IEEE1394 でビデオデッ
キへ転送する。ビデオデッキへ転送された映像を、NTSC に変換し液晶テレビに出力する。

{ 39 {

4.2 ギガビットシンポジウム 2000 中継

図 4.4

ギガビットシンポジウム 2000 トポロジー

WMT を用いて KPIX へストリーム配信

富山国体中継の際と同様である。菊池研究室の ASX200 まで送られてきた映像を、DV

over ATM で丹箱へ転送する。丹箱へ転送された映像を、DV over IEEE1394 で DVMC へ転送する。DVMC へ転送された映像を、NTSC に変換し、ストリームエンコーダであり、ストリームサーバである phage に転送する。phage に転送された映像を、Windows Media

Encoder でエンコードし、Windows Media Service で KPIX へストリーム配信する。
phage からストリーム配信される映像は、高知工科大学のネットワーク（図 4.4 中のKUTPPA NET）と高知工科大学情報システム工学科のネットワーク（図 4.4 中の KUT
DISE Summit 群）を経由し、hachi まで転送される。hachi から violet に転送され、violet
は KPIX へ転送する。hachi と violet はプロキシサーバである。hachi は自組織キャッシュ{ 40 {

4.2 ギガビットシンポジウム 2000 中継
サーバであり、violet は自組織 KPIX 側キャッシュサーバである。

DVTS を用いて富山と山梨に再配信

丹箱へ転送された映像を、DV over IEEE1394 で DVST（図 4.4 中の dvts）へ転送する。dvts で DV over IEEE1394 から DV over IP に変換する。dvts で DV over IP に変換した映像を IP multicast で、ATM ルータである silvia と mustard へ転送する。silvia とmustard では、DV over IP から DV over IP over ATM へ変換する。そして、DV over IP
over ATM 変換した映像を ASX200 へ再配信する。
ASX200 では、以下のように設定する。silvia からの入力は TAO 高知通信トラヒックリ
サーチセンターを介して JGN を経由し山梨の山梨県開放型研究開発センターへ配信する。

mustard からの入力は TAO 高知通信トラヒックリサーチセンターを介して JGN を経由して富山の富山総合情報センターへ配信する。また、ASX200 から山梨間と ASX200 から富山間の映像はすべて DV over IP over ATM であり、1 本の PVC である。

4.2.3

ストリーム配信の設定とスペック

今回の KPIX へのストリーム配信にはストリームエンコーダとストリームサーバを 1 台のマシンで行った。表 4.7、表 4.8 に WMT (phage) の設定を示す。また、phage のスペッ。
クは富山国体中継の際と同じである（表 4.5 を参照）

4.2.4

KPIX への配信結果のべ約 8 時間に及ぶ全国 4 県（愛知県、高知県、富山県、山梨県）への中継は、20〜30 秒
毎に 2 回程度の配信元が原因らしきノイズが観測されたものの、視聴者にとっては問題なく視聴出来る品質であった。KPIX へのストリーム配信は、報告が得られず視聴結果は不明で
あった。
。また、表
以下に KPIX でのギガビットシンポジウム 2000 中継視聴結果を示す（表 4.9）

{ 41 {

4.2 ギガビットシンポジウム 2000 中継

WindowsMediaService (phage)
エイリアス

gb-sympo

パスの種類

WindowsMedia エンコーダ

URL

http://210.163.147.134

ポート

8080

クライアント数

無制限

表 4.7

ストリームサーバの設定

WindowsMediaEncoder (phage)
最大ビットレート

512Kbps

オーディオ codec

Windows Media Audio V7

オーディオ形式

64kbps 44KHz stereo

ビデオ codec

Windows Media Video V7

ビデオサイズ352 × 288 (CIF)

フレームレート

30fps

キーフレームの間隔

4秒

画像の品質

0

表 4.8 ストリームエンコーダの設定の見方は富山国体の際と同様である。

{ 42 {

4.2 ギガビットシンポジウム 2000 中継

経由

プロキシの有無視聴

KPIX 経由

有不明

KCAN 経由

無不明

インターネット経由

無可能

表 4.9 KPIX でのギガビットシンポジウム 2000 中継視聴結果{ 43 {

第5章

まとめ
様々な機能やネットワーク構造およびポリシーを持った各地の地域ネットワークを相互に接続することにより、単独では不可能な機能を提供することを研究の目的とし、今回は、RIBB と KPIX とを用いて動画配信サービスを実現することを目標とした。
目標実現のために、富山国体中継とギガビットシンポジウム 2000 中継を行った。

6 日間、のべ約 60 時間に及ぶ、全国 8 都県（福島県、宮城県、山梨県、東京都、岐阜県、富山県、高知県、福岡県）への富山国体中継は、パケットロスもほとんどなく十分な品質の動画を提供した。KPIX へのストリーム配信は、プロキシサーバを介さなかった場合は視聴可能、プロキシサーバを介した場合は視聴不能であった。
のべ約 8 時間に及ぶ全国 4 県（愛知県、高知県、富山県、山梨県）へのギガビットシンポ
ジウム 2000 中継は、20〜30 秒毎に 2 回程度の配信元が原因らしきノイズが観測されたものの、視聴者にとっては問題なく視聴出来る品質であった。KPIX へのストリーム配信は、報告が得られず視聴結果は不明であった。
これらの前例のない 2 つの中継実験の成功により、多くの異なる地域ネットワークの相互接続による動画像配信サービスが可能であることを実証した。

5.1

今後の課題

多くの地域ネットワーク間の構成を自動化したいと考えてる。各地域ネットワークの機能や設備を入力し、行いたいサービスを入力すると構成の指示が自動で行われるものを検討している。

{ 44 {

5.1 今後の課題
サービスを提供している際の障害対策の研究も必要である。サービスを提供している際にネットワークが切れるなどの障害が生じた際には、自動で別の経路を選択するなどを検討している。
今回の富山国体中継とギガビットシンポジウム 2000 中継で、KPIX へのストリーム配信を行った。その結果、富山国体中継では、プロキシサーバを介した場合の KPIX へのスト
リーム配信は視聴不能であり、ギガビットシンポジウム 2000 中継では、プロキシサーバを介した場合の KPIX へのストリーム配信は報告が得られず視聴不明であった。今後、プロキシサーバを積極的に利用した KPIX へのストリーム配信の検討を行う予定である。

{ 45 {

付録 A

KPIX の年表
この付録では KPIX の歴史を時系列にそって示す。

 【1996 年未明】地域 IX の誕生

IX を地方に構築しようとする活動が活発におこなわれ始める。これは、地域内でのトラフィックが当該地域外の IX を経由することを、インターネットを基盤とした地域情報化を推進する場合の障害になると考えるようになってきたためである。

 【1997 年】PIX モデル誕生
応用層によるトラフィック交換モデルが日本ソフトウェア科学会において発表される [11]。

 【1997 年】DNS の構成

 【1998/07/13】第 1 回 KPIX 会議
県庁情報企画課（電気ビル内）において会議を行う。本会において KPIX 実験研究協議会が発足した。

 【1998/07/13】KPIX の誕生

PIX モデルの実証実験の場として KPIX が組織される。KPIX の構築・運営を通して、PIX モデルの構築・運用ノウハウの確立を目指す。

 【1999/08/02】第 2 回 KPIX 会議

KOCHI 2001 PLAN 会議室（森連会館 6 階）において会議を行う。本会では、KPIX の実験計画について討議された。

{ 46 {

 【1999/12/02】第 3 回 KPIX 会議
高知大 菊地研究室において会議を行う。本会では、KPIX のルーティングについて討議した。

 【1999/12/02】KPIX の経路制御
第 3 回 KPIX 会議において、以下の事項を確認した。
{ KPIX では HAN ボーダを置かない{ 組織内 LAN と HAN との両方にキャッシュサーバをおく{ ルーティングは静的に行う

 【2000/02/10】第 4 回 KPIX 会議
高知大 会議室において会議を行う。本会では、Squid のインストール法、設定例、そして PIX モデルにおけるキャッシュサーバの連携の提案をし討議した。

 【2000/02/10】Squid の動作の提案

PIX モデルにおけるキャッシュサーバの連携が 12 通りあることを示した。この連携は、設定変更にかかるコストについて考えられている。

 【2000/】旧 Squid の設定考案
参加組織のコンテンツを HAN 内で共有する Squid の設定を考案し、示した。また、KPIX において実装し、検証を開始した。

 【2000/04/17】KPIX 会議番外編
シティネット（大そね）において会議を行う。本会では、KPIX がデータリンクとして使用している IP ネットワークが IP reachable であってよいものかを討議した。

 【2000/06】NTP の設定

TS-820 を購入。NTP の設定を行う。
 【2000/07/25】第 5 回 KPIX 会議
高知高専 今井研において会議を行う。本会では、KPIX の無線リンクと Squid の設置状況と今後について討議した。

{ 47 {

 【2000/08/10】MRTG を用いたトラフィック測定

MRTG を用いて、Squid サーバを通過する HTTP コンテンツの監視を始める。
 【2000/09/29】DSM 富山
かねてから問題であった、KPIX のプライベートアドレス枯渇問題について解決案を示した。また、データリンクの相互運用についての解決案も同時に示した。

 【2000/10/14-19】富山国体中継
富山国体の中継画像を JGN{菊池研究室と経由して、Windows Media Technology
ストリーミングを KPIX へ配信した。

 【2000/11/08】ギガビットシンポジウム 2000 中継
北九州市で開催されたギガビットシンポジウム 2000 を JGN{菊池研究室と経由して、Windows Media Technology ストリーミングを KPIX へ配信した。

 【2000/11/20-22】ITRC 香川

PIX モデルにおいて効率的なサーバ間の連携の行えるサーバ群の構成を提案し、2000/12/1 に開催された DSM 和歌山にて発表をした。
 【2000/12/01】DSM 和歌山

PIX モデルにおいて効率的なサーバ間の連携の行えるサーバ群の構成を提案し、2000/12/1 に開催された DSM 和歌山にて発表をした。
 【2000/12/04】第 6 回 KPIX 会議
高知工科大 A260 高知工科大学において会議を行う。本会議では、無線リンクの状
況、研究発表、次年度の研究計画について討議した。

 【2000/12/04】pac 作成
プロキシ自動設定ファイル pac を作成する。

 【2000/12/04】Squid 動作決定
効率的なサーバ間の連携が行える Squid の動作を決定した。

 【2000/12/04】新 Squid の設定考案決定した動作に基づき Squid の設定ファイルを示した。

{ 48 {

 【2000/12/04】Squid 実装開始
新 Squid の設定ファイルを適用し、効率的な連携が行えるか検証を開始した。

 【2001/01/09】コストモデル

KPIX 協議会以外の組織が PIX モデルを構築する際の指針となるために、PIX モ
デルのランニングコストをモデル化し評価した。

 【2001/01/15】第 7 回 KPIX 会議
高知工科大 A260 高知工科大学において会議を行う。本会議では、次年度の KPIX
会議運営について討議した。

{ 49 {

付録 B

KPIX の活動履歴
本付録を KPIX 活動の一つの資料としてまとめる。そのため、本文と一部重複する部分
がある。

B.1

Squid 動作モデルの設計

我々は、PIX モデルにおける Squid の動作連携を提案した。これにより、PIX モデルでの Squid の連携は 12 通りあることがわかる [13]。このモデルでは、PIX モデルに新たに参加する組織が現れた場合の PIX 運営組織・新規 PIX 参加組織の設定変更にかかるコストに重点を置き、順位付けをおこなった（表 B.1）。この Squid 動作連携では、12 通り中どの
連携パターンを選択するとキャッシュのヒット率が高くなるかということは考えていない。
これは、キャッシュのヒット率が高くなるかということは、コンテンツをアクセスするト
ラフィックに依存しているため、このモデルでは一般的な解を得ることができないためである。
一般的な PIX モデル構成における Squid 動作連携をすべて示したことで、各組織のユー
ザ数やネットワーク運用体制の状態によって、最も設定変更にかかるコストが低い Squid の連携を明示することができた。
現在、運用を行っている KPIX では、各組織の運用面でのポリシーにより、基本的なSquid の動作連携は、表 B.1 中の『11』を選択している。この図より、KPIX は現在、設定変更にかかるコストに関しては良い連携を選んでいないことがわかる。

{ 50 {

B.1 Squid 動作モデルの設計
B.1.1

設定変更にかかるコスト

表 B.1 は PIX モデルでの Squid の連携 12 通りを表している。この表は、後のキャッシュ
サーバ連携モデルに挙げるモデルを図 B.1 を基に、実際にどのキャッシュサーバを通過させるかを表している。
図 B.1 のパラメータの説明を述べる。最も左の列に表示される数字は、キャッシュサーバ
連携の通し番号である。\Z → X" が示すものは、組織 Z のクライアントから組織 X へのコ
ンテンツ要求の意味である。\X → Z" は、組織 X のクライアントから組織 Z へのコンテンツ要求の意味である。

\新規"・\既存" は PIX モデルに新たに加わる組織・PIX モデルの運営をおこなっている
既存の組織が必要な設定量を表す。

\新規"・\既存" は 3 つのパラメータを持つ。このパラメータは左から、PIX 参加組織内
キャッシュサーバ、組織に対応する HAN 内キャッシュサーバ、クライアントに必要な設定量を表す。また、その設定量を表す記号として、\−○△▲×" がある。この記号はそれぞれ
左から、設定不要、少量の設定変更が必要、設定ファイルの変更を行うとして 2 行程度の変更が必要、設定ファイルの変更を行うとして 5 行程度の変更が必要、多くの設定変更が必要を表す。それぞれの記号にそれぞれ○に 1 点、△に 2 点、▲に 3 点、×に 4 点を付与する。

\合計" は各記号付与されている点の合計を書く。
\rank" は合計を基に各パターンを順位付けした結果である。
\hops" は要求をおこなうコンテンツサーバまでのホップ数を表す。

キャッシュサーバ連携モデル
ここでは、PIX モデルのキャッシュサーバ連携モデルを述べる。このモデルは、ネット
ワーク層の構造と運用面からの制約との条件から導出した。

1. コンテンツを持っている（アクセスされる）側のネットワーク構造は以下のサーバ類がIP reachable であると考える。

{ 51 {

B.2 参加組織のコンテンツを共有する Squid の設定（a）コンテンツを持つサーバ（b）組織内でキャッシュを行うサーバ

2. PIX バックボーンのネットワーク構造は以下のサーバ類が IP reachable であると考える。PIX バックボーンと各組織とでは IP 交換可能である。しかし、PIX バックボーン
は組織間の IP をトランジットしない。なお、ルータは専用であるものと想定している。
（a）コンテンツを持つ側に設置するキャッシュサーバ（b）コンテンツアクセスする側に設置するキャッシュサーバ

3. コンテンツをアクセスする側のネットワーク構造は以下のサーバ類が IP reachable であると考える。
（a）コンテンツにアクセスするクライアント（b）組織内でキャッシュを行うサーバ
このようなネットワークトポロジーモデル上でキャッシュサーバ連携モデルを考察した。

 コンテンツのあるサーバの組織のキャッシュサーバ 1b を用いるか否かの 2 通り。
 PIX バックボーンを通過する HTTP をどのキャッシュサーバ経由にするか。サーバ 2a
かサーバ 2b か、あるいはその両方かの 3 通り。なお、組織間で IP をトランジットしないので、どのキャッシュサーバも用いないという選択はあり得ない。

 コンテンツにアクセスするクライアント 3a からの HTTP を自組織内のキャッシュサー
バ 3b 経由にするか否かの 2 通り。
このように、どのキャッシュサーバを連携し通過させるかだけで、12 通りの選択肢が存在
する。

B.2

参加組織のコンテンツを共有する Squid の設定

KPIX 参加組織による HAN の構築にともない、「KPIX 参加組織の WWW コンテンツ
を KPIX を介して取得する」Squid の設定を考案し実装した。

{ 52 {

B.2 参加組織のコンテンツを共有する Squid の設定
Z →X

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

●

○

△

→1→1
○
△
○
6→1→1→1
●
○
△
6→3→1
●
○
○
△
6→3→1→1●○○○△
6 → 3 → 1 → A→ 1●○○△
6 → 3 → A→ 1●○○△
6 →C→ 1 → 1
●
○
○
○
△
6 →C→ 1 →A → 1●○○△
6 →C→ 3 → 1
●
○
○
○
△
6 →C→ 3 → 1 → 1
●
○
○
○
○
△
6 →C→ 3 → 1 →A → 1
●
○
○
○
△
6 →C→ 3 →A → 1
6

●

Z →X

X →Z

新規

既存

−−△

−−−

−−△

−−−

−−○

−−−

−△○

−−−

−△○

−−−

−△○

−−−

×−−

−−−

×−−

−−−

▲−−

−−−

▲△−

−−−

▲△−

−−−

▲△−

−−−

●

○

△

→3→3
○
○
△
1 → 3 →C→ 3
●
○
△
1→1→3
●
○
○
△
1→1→3→3●○○○△
1 → 1 → 3 →C→ 3●○○△
1 → 1 →C→ 3●○○△
1 →A→ 3 → 3
●
○
○
○
△
1 →A→ 3 →C→ 3●○○△
1 →A→ 1 → 3
●
○
○
○
△
1 →A→ 1 → 3 → 3
●
○
○
○
○
△
1 →A→ 1 → 3 →C→ 3
●
○
○
○
△
1 →A→ 1 →C→ 3
1

●

X →Z

合計

rank

hops

１２００

5

3

2

０３００

6

4

3

−−○

２０００

2

1

2

−△○

３２００

7

5

3

−△−

−△○

２３００

8

7

4

○−−

−△○

３２００

7

5

3

−○−

▲−−

１０１１

8

7

3

−△−

▲−−

０１１１

9

10

4

−−−

−−−

００１０

3

2

3

−○−

−△−

１０２１

11

12

4

−△−

−△−

０３１０

9

10

5

○−−

−△−

１２１０

8

7

4

１２３４

新規

既存

○△▲×

−○−

−−△

−△−

−−△

−−−
−○−

表 B.1 KPIX トポロジーと設定量

B.2.1

参加組織による HAN の構成

PIX では、以下の経路制御ポリシーを満たす HAN を構成する（図??）。
 HAN 内は IP Reachable である。

図 B.1 KPIX のトポロジー{ 53 {

B.2 参加組織のコンテンツを共有する Squid の設定
 HAN と Internet は IP Reachable でない。
 組織内のコンピュータと、組織に対応する HAN 内のサーバとは IP Reachable である。

Internet
the InternetY

Organization
Router

HAN
X(via the Internet)

Z
図 B.2 参加組織による HAN の構成

円は IP Reachable な領域を示す。HAN と各組織との重なりは互いに IP Reachable な

HAN ボーダである。HAN は Internet と IP Reachable でないため、各組織のインターネッ
ト経路を経由しないと IP の交換は行えない。

B.2.2

KPIX における典型的な WWW サーバ群の構成例

ここでは、以降の説明のために PIX モデルにおける WWW サーバ群の構成例を示す（図B.3）。各組織は以下で構成される。
 コンテンツを提供するサーバ (図中 I, II, III)
 組織内で運用するキャッシュサーバ (図中 A, B, C) HAN で各組織に対応するキャッシュサーバ (図中 , , ) インターネット経路{ 54 {

B.2 参加組織のコンテンツを共有する Squid の設定
 各組織のクライアント (図中 1, 2, 3, 4, 5)Internet
IV

Organization
Cache Sever

Y

B[10.30.136/24]

Contents Sever
4

II

Client3

Router(via the Internet)

HAN[172.31/16]
I

III
C
5

2

X

[192.168/16]

Z[172.21/16]

図 B.3 KPIX における WWW サーバ群の構成

B.2.3

WWW サービスに対する要求

ここでは PIX 参加組織からの WWW サービスに対する要求を述べる。

 HAN 内でできるだけ解決する。
 HAN 内で解決できない場合、自組織のインターネット経路により解決する。
 コンテンツの公開・非公開を、要求元の IP アドレスを用いて制御する。

B.2.4

サーバ群の連携パターン

ある組織のコンテンツを別の組織のクライアントが閲覧する場合、12 通りの連携パター。
ンが存在する（図 B.4）
このトポロジーをもとに KPIX の実装では、{ 55 {

B.2 参加組織のコンテンツを共有する Squid の設定

HAN

Organization
Cache Sever

A

B

X

Y

II

Contents Sever
Client

図 B.4 サーバ群の全連携パターン

 経路制御ポリシーにより、組織 X とサーバ 、組織 Y とサーバとは IP Reachable

でない。

 サーバ B を用いると要求元の IP アドレスによるアクセス制御ができない。
といった制約があり、これを満たすのは図 B.5 の連携パターンである。

HAN

Organization
Cache Sever

A

B

X

Y

II

Contents Sever
Client

図 B.5 制約を満たす連携パターン

更に、クライアント数はサーバ数よりも圧倒的に多く、クライアントの設定を変更するには大きなコストをともなう。また、参加組織において、既に運営されているキャッシュサー
バがある場合、キャッシュの設定を変更する方が作業コストが小さい。
以上のことより、KPIX においては図 B.6 の連携パターンを選択した。

{ 56 {

B.2 参加組織のコンテンツを共有する Squid の設定

HAN

Organization
Cache Sever

A

B

II

Y

X

Contents Sever
Client

図 B.6 KPIX におけるサーバ群の連携パターン

B.2.5

リクエストに対するサーバ間の連携

ここでは、あるリクエストに対してのサーバ間の連携について具体的な動作を示す。
初期状態としてコンテンツはどのサーバにもキャッシュされていないものとする。図中の矢印はリクエストの流れを、矢印に付した数字は流れの順序を表す。

 組織 X におけるサーバ I に公開コンテンツ i-1 があり、組織 Y 内にいるクライアント 3が閲覧しようとした場合（図 B.7）。
。サーバ B は i-1 がキャッシュクライアント 3 はサーバ B に i-1 をリクエストする（~1）
されていないのでサーバに i-1 をリクエストする（~2）。サーバ

を ~3, ~4 とリレーする。サーバ I はサーバ
シュし、サーバに返す（~6）。サーバ,

は、リクエストに i-1 を返す（~5）
。サーバ

は i-1 をキャッ, B はコンテンツを ~7, ~8 とリレーすると同時にキャッシュする。最後にクライアント 3 は i-1 を閲覧できる。

 その後、組織 Y 内にいるクライアント 4 が公開コンテンツ i-1 を閲覧しようとした場合。
（図 B.8）。サーバ B は i-1 をキャッシュクライアント 4 はサーバ B に i-1 をリクエストする（~1）
しているので、サーバにリクエストする事なくクライアント 4 コンテンツを受け取る。よってクライアント 4 は i-1 を閲覧できる。
（~2）

 その後、組織 Z 内にいるクライアント 5 が公開コンテンツ i-1 を閲覧しようとした場合。
（図 B.9）{ 57 {

B.2 参加組織のコンテンツを共有する Squid の設定

i-1

new

8

3

1

4

2

i-1

new

B

7
i-1

3
4

I

X i-1

Y

new

5 HAN
i-1

new

Z

5

図 B.7 PIX 上の公開コンテンツに対するリクエスト

i-1

3

i-1

new

2

B

4

1

Y

i-1

HAN
I

X

i-1

Z

i-1

図 B.8 キャッシュされた公開コンテンツに対する同組織内からのリクエスト

クライアント 5 はサーバ C に i-1 をリクエストする（~1）
。サーバ
を ~2, ~3 とリレーする。サーバ
トする事なくサーバ,

は、リクエストは i-1 をキャッシュしているので、サーバ I にリクエスに返す（~4）。サーバ, C はコンテンツを ~5, ~6 とリレーすると同時にキャッシュする。最後にクライアント 5 は i-1 を閲覧できる。

 組織 X におけるサーバ I に非公開コンテンツ i-2 があり、組織 Z 内にいるクライアント{ 58 {

B.2 参加組織のコンテンツを共有する Squid の設定

Y
i-1

HAN

i-1

i-1

4

I

X

i-1

5

new

C

2
1

3

i-1

5

new

6
i-1

new

Z

図 B.9 キャッシュされた公開コンテンツに対する他組織内からのリクエスト

5 が閲覧しようとした場合（図 B.10）。
クライアント 5 からの i-2 へのリクエストは、公開コンテンツに対するリクエストと同, I は、リクエストを ~1, ~2, ~3, ~4 とリレーする。サーバ I は、リク様にサーバ C、 ,エスト元が組織 X 内の IP アドレスを持たないサーバ。否定応答は、サーバ（~5）

であるため、否定応答を返す, , C が ~6, ~7, ~8 とリレーし、クライアント 5 は i-2 を閲覧

できない。

Y
HAN
5

i-2

I

4

6

7

3

2
1

X

5

C

8

Z

図 B.10 非公開コンテンツに対するリクエスト インターネット上にあるサーバ IV に公開コンテンツ i-3 があり、組織 X 内にいるクラ。
イアント 2 が閲覧しようとした場合（図 B.11）。サーバ A は、サーバ IV にリ
クライアント 2 はサーバ A に i-3 をリクエストする（~1）{ 59 {

B.2 参加組織のコンテンツを共有する Squid の設定
クエスト ~2 し、コンテンツを受け取る（~3）
。受け取ったコンテンツをサーバ A はキャッ
。最後にクライアント 2 は閲覧できる。
シュして、クライアント 2 に返す（~4）

Internet
IV

Y

i-3

HAN

2

3

Z

i-3

new

A

X

1

2

4
i-3

new

図 B.11 インターネット上の公開コンテンツに対するリクエスト

B.2.6

各サーバの動作

ここでは、図 B.6 の連携パターンにおいて、第 B.2.5 節の動作を行うための各サーバごとの動作を示す。表 B.2 と表 B.3 とは、それぞれサーバ A とサーバとの動作を示す。縦軸にリクエスト元を、横軸にコンテンツのある場所をとっている。Y と Z のサーバも同様で
ある。

B.2.7

Squid によるサーバ群の実現

表 B.2 と表 B.3 とに示すサーバの動作を Squid を例にして説明する。
サーバ A と、サーバをそれぞれ Squid A、Squidとし、squid.conf の設定例を表 B.4と表 B.5 に示す。
ここでは、組織 X に IP アドレス 192.168/16 を割り当て、Squid A を 192.168.8.10 とす{ 60 {

B.2 参加組織のコンテンツを共有する Squid の設定

表 B.2 組織 X 内キャッシュサーバ A の動作

コンテンツのある場所
リクエスト元組織 X 内X のクライアント

直接 1

サーバ 2

拒否 2

拒否 2

拒否 2

拒否 3

拒否 3

拒否 3

拒否 4

拒否 4

拒否 4

サーバ

,

3

インターネット 4

組織 Y、Z 内にリクエスト 1

インターネット直接 1

1 キャッシュされていればそれを用いてコンテンツを返す。
2の設定が正しければありえない。対設定ミス。

3,の設定が正しければありえない。対設定ミス。

4 組織 X のインターネット側ファイアウォールで止めるのが普通である。

る。同様に HAN に 172.31/16 を割り当て、Squidを 172.31.8.3 とする。

[Squid A の動作]1

 組織 X 内からのリクエストを許可し、それ以外からのリクエストは拒否する (13, 14)。
 KPIX 参加組織コンテンツへのリクエストについては、必ず squid に Parent でリクエストする (4, 5, 10)。

 上記以外へのリクエストは、直接リクエストする (11)。
[Squidの動作]2

 組織 X 内にあるサーバ I への HAN 内からのリクエストと、SquidA からのリクエストを許可し、それ以外からのリクエストは拒否する (16, 17, 18)。

1 動作の文末の数値は、表 B.4 の行番号に対応する。
2 動作の文末の数値は、表 B.5 の行番号に対応する。

{ 61 {

B.3 コンテンツを共有するサーバ間の連携

表 B.3 組織 X に対応する HAN 内キャッシュサーバの動作

コンテンツのある場所
リクエスト元組織 X 内組織 Y、Z 内

インターネット

X のクライアント 1

拒否 1

拒否 1

拒否 1

サーバ A

拒否 2

Y なら

にリクエスト 3

拒否 2

Z なら にリクエスト 3
,

直接 3

否定応答 3

拒否 4

インターネット 5

拒否 5

拒否 5

拒否 5

サーバ

1 クライアントの設定が正しければありえない。
2 A の設定が正しければありえない。対設定ミス。
3 キャッシュされていればそれを用いてコンテンツを返す。
4,の設定が正しければありえない。対設定ミス。

5 HAN がプライベートアドレスを用いるならありえない。グローバルアドレスであっても、A のインターネット側ファイアウォールで止めるのが普通である。

 組織 X 内にあるサーバ I へのリクエストは、直接リクエストする (13)。
 KPIX 参加組織のコンテンツへのリクエストは、それぞれ対応する HAN 内 Squid ,に Parent でリクエストする (4, 5, 6, 7)。

 上記以外のコンテンツへのリクエストは、許可しない (16, 17, 18)。

B.3

コンテンツを共有するサーバ間の連携

KPIX 内で交換されるすべてのコンテンツを交換・共有するサーバ間の連携パターンを考案した。
具体的には、B.2 の参加組織のコンテンツを共有するとともに、参加組織内でリクエスト{ 62 {

B.3 コンテンツを共有するサーバ間の連携

表 B.4 Squid A の設定

1

visible hostname A.X.or.jp

2

http port 3128

3

icp port 3130

4

cache peer5cache peer domain

6

acl all src 0.0.0.0/0

7

acl X SRC src 192.168.0.0/16

8

acl PIX DST dstdomain .Y.or.jp .Z.or.jp

9

acl X DST dstdomain .X.or.jp

10never direct allow PIX DST

11

always direct allow !PIX DST

12

icp access allow all13

http access allow X SRC

14

http access deny all.X.KPIX.net parent 3128 3130
.X.KPIX.net .Y.or.jp .Z.or.jp

される参加組織以外のコンテンツを HAN 内でキャッシュして共有する、サーバ間の連携パターンを決定した。

B.3.1

リクエストに対するサーバ間の連携

ここでは、参加組織以外のコンテンツへのリクエストとに対してのサーバ間の連携について具体的な動作を示す。
初期状態としてコンテンツはどのサーバにもキャッシュされていないものとする。図中の矢印はリクエストの流れを、矢印に付した数字は流れの順序を表す。

 インターネット上にあるサーバ IV に公開コンテンツ i-3 があり、組織 X 内にいるクラ{ 63 {

B.3 コンテンツを共有するサーバ間の連携

表 B.5 PIX Squidの設定

1

visible hostname.X.PIX.net

2

http port 3128

3

icp port 3130

4

cache peer5cache Peer domain

6cache peer

7cache peer domain

8

acl all src 0.0.0.0/0

9

acl PIX SRC src 172.31.0.0/16

10

acl X A src 192.168.8.10/32

11

acl X DST dstdomain .X.or.jp

12

acl PIX DST dstdomain .Y.or.jp .Z.or.jp

13

always direct allow X DST

14never direct allow all

15

icp access allow all16

http access allow PIX SRC X DST

17

http access allow X A PIX DST

18

http access deny all.Y.KPIX.net parent 3128 3130
.Y.KPIX.net .Y.or.jp.Z.KPIX.net parent 3128 3130
.Z.KPIX.net .Z.or.jp

イアント 2 が閲覧しようとした場合 (図 B.12)。
クライアント 2 はサーバ A に i-3 をリクエストする (~1)。サーバ A は、サーバ
クエスト ~2 を出す。サーバ

は他の HAN 内キャッシュサーバ,にリにキャッシュされているか問い合わせる (~3, 3~0 )。各キャッシュサーバにはキャッシュされていないので、
サーバに否定応答を返す (~4, 4~0 )。サーバは問い合わせたサーバすべてから否定応答をもらったら、サーバ A に i-3 のリクエスト ~5 を出す。サーバ A はサーバ IV にリク{ 64 {

B.3 コンテンツを共有するサーバ間の連携~ と返り、クライアント 2 は i-3 を閲覧できる。
エスト ~6 を出す。以降、i-3 は ~7, ~8, ~9, 10Internet
IV

Y

i-3

4'

6

7

i-3

new

5
i-3

HAN
Z

2

A

X

3

8
9

new

3'
4

1
10

2

i-3

new

図 B.12 インターネット上の公開コンテンツに対するリクエスト

B.13 では、リクエストをできるだけ HAN 内で解決するために、サーバ
A からのリクエストを HAN 内のサーバ ,は、サーバに問い合わせている。また、HAN 内で解決できない場合、自組織におけるインターネット経路で解決する。さらにこのとき、HAN 内でのキャッシュコンテンツを増やすため、サーバ A がサーバ にコンテンツをキャッシュさせている。

 その後、組織 Y 内にいるクライアント 4 が公開コンテンツ i-3 を閲覧しようとした場合(図 B.13)。
クライアント 4 はサーバ B に i-3 をリクエストする (~1)。サーバ B は、サーバ
エスト ~2 を出す。サーバ

は他の HAN 内キャッシュサーバ

いるか問い合わせる (~3, 3~0 )。サーバ
定応答を返す (4~0 )。サーバに返す (~4)。サーバ,にリクにキャッシュされては i-3 キャッシュしていないので、サーバに否は i-3 をキャッシュしているので、キャッシュをサーバ

は、受け取ったキャッシュコンテンツをキャッシュし、クライア

ント 4 に返す (~2)。よってクライアント 4 は i-3 を閲覧できる。

{ 65 {

B.4 コンテンツを共有する Squid の設定

i-3

new

6

i-3

new

4

Internet

1

B

2

5

i-3 IV

i-3

new

3
4 3'
i-3

A

Y

4'

i-3

X HAN Z

図 B.13 キャッシュされた公開コンテンツに対するリクエスト

B.4

コンテンツを共有する Squid の設定

第 B.3 節のサーバ間の連携パターンの決定により、参加組織コンテンツを共有し、なおかつ参加組織以外のコンテンツも共有する Squid の設定を行った。

B.4.1

各サーバの動作

ここでは、参加組織のコンテンツを共有する B.2.5 の動作を行い、なおかつ、B.3.1 の動作を行うための各サーバごとの動作を示す。表 B.6 と表 B.7 とは、それぞれサーバ A とサーバとの動作を示す。行にリクエスト元を、列にコンテンツのある場所をとっている。

Y と Z のサーバも同様である。
B.4.2

Squid によるサーバ群の実装

表 B.6 と表 B.7 とに示すサーバの動作を Squid を例にして説明する。
サーバ A と、サーバをそれぞれ Squid A、Squidとし、squid.conf の設定例を表 B.8と表 B.9 に示す。
ここでは、組織 X に IP アドレス 192.168/16 を割り当て、Squid A を 192.168.8.10 とす{ 66 {

B.4 コンテンツを共有する Squid の設定

表 B.6 組織 X 内キャッシュサーバ A の動作

コンテンツのある場所
リクエスト元組織 X 内X のクライアント

直接 1

サーバ

直接 1

拒否

直接 1

拒否 2

拒否 2

拒否 2

拒否 3

拒否 3

拒否 3

サーバ

,

2

インターネット 3

組織 Y、Z 内

インターネットにリクエスト 1にリクエスト 1

1 キャッシュされていればそれを用いてコンテンツを返す。
2 PIX のルーティングの設計で止める事も可能である。
3 組織 X のインターネット側ファイアウォールで止めるのが普通である。

る。同様に HAN に 172.31/16 を割り当て、Squidを 172.31.8.3 とする。

[Squid A の動作]3

 組織 X 内からと Squidからのリクエストを許可し、それ以外からのリクエストは拒否する (13, 14, 15)。

 組織 X 内のコンテンツサーバ I へのリクエストは、直接リクエストする (9)。
 上記以外へのリクエストについては、必ず Squidに Parent でリクエストする (4,11)。
 Squidからのリクエストは、直接リクエストする (10)。

[Squidの動作]4

 組織 X 内にあるサーバ I への HAN 内からのリクエストと、Squid A からのリクエス
3 動作の文末の数値は、表 B.8 の行番号に対応する。
4 動作の文末の数値は、表 B.9 の行番号に対応する。

{ 67 {

B.4 コンテンツを共有する Squid の設定

表 B.7 組織 X に対応する HAN 内キャッシュサーバの動作

コンテンツのある場所
リクエスト元組織 X 内組織 Y、Z 内

インターネット

X のクライアント 1

拒否 1

拒否 1

拒否 1

サーバ A

拒否 2

Y なら にリクエスト 3,

Z なら にリクエスト 3

無ければ A にリクエストにリクエスト 3,

直接

否定応答 3

否定応答 3

インターネット 4

拒否 4

拒否 4

拒否 4

サーバ

1 クライアントの設定が正しければありえない。
2 A の設定が正しければありえない。対設定ミス。
3 キャッシュされていればそれを用いてコンテンツを返す。
4 HAN がプライベートアドレスを用いるならありえない。グローバルアドレスであっても、A のインターネット側ファイアウォールで止めるのが普通である。
トを許可し、それ以外からのリクエストは拒否する (16, 17,18)。

 組織 X 内にあるサーバ I へのリクエストは、直接リクエストする (13)。
 上記以外のすべてのリクエストは他のキャッシュ・プロキシを使ってリクエストする(14)。
 KPIX 参加組織のコンテンツへのリクエストは、それぞれ対応する HAN 内 Squid ,に Parent でリクエストする (5, 7)。

 上記以外のコンテンツへのリクエストは、HAN 内 Squid ,に Sibling でリクエストする (4, 6)。

 Sibling でキャッシュの無かったリクエストについては、Squid A に Parent でリクエストする (8)。

{ 68 {

B.5 NTP による時刻同期

表 B.8 Squid A の設定

1

visible hostname A.X.or.jp

2

http port 3128

3

icp port 3130

4

cache peer5acl all src 0.0.0.0/0

6

acl X SRC src 192.168.0.0/16

7

acl PIX

8

acl X DST dstdomain .X.or.jp

9always direct allow X DST

10

always direct allow PIX

11never direct allow all

12

icp access allow all13

http access allow X SRC

14

http access allow PIX

15

http access deny all.X.KPIX.net parent 3128 3130

src 172.31.8.3/32

以上のことを、2000 年 11 月 21 日に香川県クアパーク津田にて行われた第 8 回 ITRC 総会・研究会、および、同年 12 月 1 日に和歌山県和歌山大学にて行われた 2000 年度第 4 回

DSM 研究会にて発表した。
また、同年 12 月 6 日に高知工科大で行われた「第 6 回 KPIX 会議」において、正式にKPIX のサーバの設定として採用が決定した。

B.5

NTP による時刻同期

この節では NTP の必要性とその設定について述べる。

{ 69 {

B.5 NTP による時刻同期

表 B.9 PIX Squid

B.5.1

の設定

1

visible hostname.X.PIX.net

2

http port 3128

3

icp port 3130

4

cache peer

5neighbor type domain

6cache peer

7neighbor type domain

8cache peer

9acl all src 0.0.0.0/0

10

acl PIX SRC src 172.31.0.0/16

11

acl X A src 192.168.8.10/32

12

acl X DST dstdomain .X.or.jp

13

always direct allow X DST

14never direct allow all

15

icp access allow all16

http access allow PIX SRC

17

http access allow X A

18

http access deny all.Y.KPIX.net sibling 3128 3130
.Y.KPIX.net parent .Y.or.jp.Z.KPIX.net sibling 3128 3130
.Z.KPIX.net parent .Z.or.jp.X.or.jp parent 3128 3130

NTP とはNTP (Network Time Protcol)[2] とはネットワーク上の複数のノードの時刻を同期させるプロトコルである。NTP は client-server 方式をとっており、client は server より時刻情報を受け取り、時刻同期を行う。また、client-server は階層構造をとることが可能であり、階層のどこに位置するかは stratum の値でわかる。階層の頂点に位置する server は{ 70 {

B.5 NTP による時刻同期
stratum1 である。また、同一 stratum のノード同士で互いに相手の時刻情報を用いて同期を行うことも可能である。

B.5.2

NTP の必要性

PIX ではキャッシュサーバを用いてトラフィックを交換する。そのためキャッシュサー
バのログを常に監視し、正常なサービスを継続的に提供する必要がある。また、トラフィッ
クの交換が正しく行われているか確認するためにも複数のキャッシュサーバのログを比較することが必要になる。

B.5.3

NTP の構成

KPIX では時刻情報を得るためにいくつかの組織に stratum1 の NTP server を設置した。
PC を stratum1 の NTP server として使用するために、古野電気株式会社の GPS Time
Receiver, TS-8205を用いた。また、NTP サーバの OS として FreeBSD6 を、サーバソフ
トとして ntp7 を用いた。TS-820 は GPS から時刻情報を取得して、その情報を 1PPS[3] として PC に送出する。この 1PPS を PC 側で取得することで極めて正確に PC の時刻あわせを行うことが可能であり、このようにして時刻を設定した PC を stratum1 の NTP server
として使用することができる。

B.5.4

NTP の設定

まず、FreeBSD が PPS 信号を受け取るように kernel を再構築する。kernel con g ファ
イルに

 options PPS SYNC

5 TS-820

http://www.furuno.co.jp/gps/prod6.htm

6 FreeBSD 友の会

http://www.jp.FreeBSD.org/

7 TimeServer http://www.eecis.udel.edu/ntp/{ 71 {

B.5 NTP による時刻同期の一行を書き加えて kernel の再構築を行う。

TS-820 には癖があってそのままでは ntp が使用できないため、ソースを展開し、NetBSD
での設定方法8 を参考にして refclock nmea.c を編集する。

gps_send(pp->io.fd,"$PMOTG,RMC,0000*1D\r\n", peer);という行が２ヶ所にあるので、はじめを

gps_send(pp->io.fd,"$PFEC,GPint,ZDA00,GGA00,GSV00,VTG00,RMC01\r\n",peer);に修正し、2 番目を消す。
その後ドキュメントに書かれている通りに con gure, make, make install を行う。

TS-820 をシリアルポートに接続し、/dev で以下のコマンドを実行する。
# ln -s cuaa0 gps1

/usr/local/etc/ntp.conf を以下のようにする。
server 127.127.20.1
fudge 127.127.20.1 time1 -1.0
driftfile /usr/local/etc/ntp.drift
以下のコマンドを実行して様子をみる。

/usr/local/bin/ntpd -c /usr/local/bin/ntp.conf
動作を確認して、上記コマンドが起動時に実行されるようにする。
動作しない場合は、TS-820 の 1PPS ランプが点滅していることを確認する。点滅していない場合は、アンテナの設置場所が悪いなどの理由により衛星から時刻情報を取得できていない状態である。アンテナを、全天が見渡せる場所に設置することで解決できる。全天が見渡せる場所が確保できない場合も、可能な限り広く空が見渡せる場所に設置する。
8 GPS/NetBSD/SS1

http://lips.is.kochi-u.ac.jp/NTP/{ 72 {

B.6 MRTG による測定
また、TS-820 が GPS の信号を受信していても NTP サーバがその信号を受信していない可能性がある。これを確認するために、# tip cuaa0c
を実行して、TS-820 から来る信号を監視する。時刻・位置情報が来ていればよい。
以上の確認をしたら、利用できるいくつかの NTP サーバと時刻を比較して正しい時刻になっているか確認する。正しい時刻を示していない場合は、以上の作業のいずれかに失敗している可能性がある。再度手順を確認して作業を行う。
以上の手順で stratum1 の NTP server を利用することができるようになる。

B.6

MRTG による測定

MRTG (Multi Router TraÆc Grapher) とは、Tobias Oetiker 氏が 1994 年、インター
ネット回線の負荷状況を WEB 上で監視するために作成されたフリーのソフトウェアである。MRTG は SNMP (Simple Netowrk Management Protocol) により値を受け取り、
ネットワーク等の状況をグラフ化する。SNMP を使用するため、SNMP が実装された機器であれば MRTG による監視が可能である。例えば、SNMP を実装した測定器の測定結果である外界の温度、湿度、風力、γ/β線などを定期的にグラフ化し WEB 上で監視することもできる。

MRTG は以前、WEB 上のグラフを GIF フォーマットで作成していた。しかし、近年のGIF ライセンス問題9 により PNG を使用するようになった。
この MRTG を用いて KPIX に接続しているある一つの Squid サーバのトラフィック状。この Squid サーバは、NTP client になるための設定
況等を測定した（図 B.14、図 B.15）
をおこなっているため、極めて正確な時刻を得ている。そのため、正しい時刻のトラフィッ
ク状況の監視が可能になっている。
また、KPIX のデータリンク層を構成している KCAN では、無線リンクの状況を ping コ
9 http://www.unisys.com/unisys/lzw/lzw-license.asp{ 73 {

B.7 PIX モデルの諸問題とその解決手法
マンドと MRTG を用いて監視しておいる。このため、無線リンクの切断などのトラブルに対する素早い対応を可能にしている。

図 B.14 日間キャッシュヒット

図 B.15 週間キャッシュヒット

これらのデータを含め、表 B.10 に表す値についても測定をおこなっている。

B.7

PIX モデルの諸問題とその解決手法

PIX モデルの実証実験の場である KPIX の設計の際の 2 つの問題とその解決法を述べる[6]。

{ 74 {

B.7 PIX モデルの諸問題とその解決手法

cacheServerRequests

cacheServerErrors

cacheServerInKb

cacheServerOutKb

cacheClientHttpRequests

cacheHttpHitscacheHttpErrors

cacheIcpPktsSent

cacheIcpPktsRecv

cacheIcpKbSent

cacheIcpKbRecv

cacheHttpInKb

cacheHttpOutKb

cacheCurrentSwapSize

cacheNumObjCountcacheCpuUsagecacheMemUsagecacheSysPageFault

表 B.10 MRTG 測定項目一覧

B.7.1

PIX モデル設計時の問題点

問題の一つは、プライベートアドレスの衝突、枯渇である。PIX モデルはプライベートア
ドレスを用いて各参加組織をつなぐ。そのため、全参加組織が使用していないプライベート
アドレスを見つけだすことが必要となる。全参加組織が使用していないプライベートアドレ
スがある場合、そのプライベートアドレスを使用すれば問題なく PIX モデルに移行できる。
しかし、プライベートアドレスは各組織毎、自由に使用しているため、参加組織が使用しているプライベートアドレスが重複する場合がでてくる。また、重複していない場合でも、空
きがいわゆる「虫食い」状態になっていて必要な大きさの空間を確保できない場合がある。
もう一つの問題は、既存のネットワークの上に別のアドレス空間をもつ PIX モデルを導入する際への手法である。これは、運営している IP ネットワークがあり、そのネットワー
クを PIX モデルで使用したとする。この時、IP ネットワークのポリシーが異なるなどの理由で管理上互いに独立のネットワークにしたい場合がある。

B.7.2

問題点に対する解決法

以上の問題解決の方法として、前者では NAT を使用する解決法を提案した。各 PIX 参
加組織が使用していないプライベート IP アドレスと PIX 用のプライベート IP アドレスをルータの NAT 機能を使用して「1 対 1」静的対応させることで、PIX 内からはある一つの{ 75 {

B.8 富山国体映像中継
プライベート IP アドレスを使用しているかのように見せることができる。
後者では IP トンネリングを用いた解決法を提案した。IPsec の技術使用することでパケットをカプセル化するため、既存のネットワークを意識せずに PIX ネットワークとして使用する事ができる。

B.7.3

KPIX での対応

これら 2 つの問題は、実際 KPIX でも問題となったことである。しかし、これら 2 つの実証実験を小規模な実験ネットワークを構築し検証した直後、KCAN では IP アドレスのリ
ナンバリングがおこない、NAT を使用することなく IP アドレスの衝突を回避した。

IP トンネリングについても、KCAN 管理・運用者より不満の声があがらなかったため、使用する機会がなくなった。
しかしこれら 2 つの問題は、一般的な PIX モデルに付いても十分当てはまる問題であると考え、我々はこれらの解決法を利用して問題を回避できると考える。

B.8

富山国体映像中継

本文 第 4 章 4.1 富山国体映像中継 を参照。

B.9

ギガビットシンポジウム 2000 中継

本文 第 4 章 4.2 ギガビットシンポジウム 2000 中継 を参照。

B.10

pac ファイルの作成

この節では pac ファイルの作成方法、およびブラウザへの設定方法などについて述べる。

{ 76 {

B.10 pac ファイルの作成
B.10.1

pac ファイルとはpac (Proby Auto Con guration) ファイル1011 とは、ブラウザのプロキシ設定を自動化する設定ファイルである。pac ファイルは JavaScript 風の文法によって記述されたテキス
トファイルである。現在 pac ファイルを使用できるのは Netscape Navigator と Microsoft

Internet Explorer である。
B.10.2

pac ファイルの目的

pac ファイルを使用してプロキシの自動設定を行うことによって多数あるクライアントの
ブラウザの設定の変更をそれぞれに対して行う必要がなくなり、もとの pac ファイルを変更するのみで全体の設定を変更することが可能となる。また、ブラウザの動作についても細かく規定することが可能であり、pac ファイルを使用してブラウザも PIX を動作に組み込む
ことでより柔軟なネットワーク設計を可能とする。

B.10.3pac ファイルの記述

pac ファイルは JavaScript に似た文法で記述される。ブラウザはユーザから URL へのリクエストを受け取ると、

function FindProxyForURL (url, host)fgという関数を呼び出す。引数として url はリクエストされた url 全体が、host には url に含まれる hostname が渡される。この関数は受け取った url, host をもとに、答えを返す。この関数が返すのは、以下の３つの値のどれかである。

 DIRECT: プロキシを使用せずに直接接続する
 PROXY: 使用するプロキシサーバとポート番号を返す
 SOCKS: 使用する SOCKS サーバとポート番号を返す
10 Netscape の資料 http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html
11 Internet Explorer 開発キット http://www.microsoft.com/japan/ie/ieak/{ 77 {

B.10 pac ファイルの作成
FindProxyForURL 関数の中では、一般的な JavaScript の関数の他にいくつかの定義済み関数を使用することができる。定義済み関数はいくつかのグループに分かれている。グループは以下の通りである。

 ホスト名による条件式
 IP アドレス、DNS に関する関数
 URL/hostname による条件式
 時間による条件式
 結合された配列
これらの関数を組み合わせることで柔軟なプロキシ設定を実現することが可能となる。

B.10.4pac ファイルの適用

pac ファイルはブラウザに読み込まれることで有効になる。そのため、何らかの方法でブラウザに読み込ませる必要がある。ただし、一度読み込ませれば pac ファイルが更新された
場合の再読み込みは自動化されているのが一般的であるため、pac ファイルの読み込みの設定は最初の一度行えばよい。

pac ファイルをブラウザに読み込ませるには以下のようにいくつかの方法がある。
 ブラウザに pac ファイルの URL を設定する
 WPAD[1] によって自動検出を行う{ DHCP を用いる
{ SLP を用いる
{ DNS を用いる

 A lookup を用いる
 SRV lookup を用いる
 TXT lookup を用いる

{ 78 {

B.11 コストモデル
WPAD による方法は現在では Microsoft Internet Explorer のみで使用することができる。
WPAD を使用するには、Internet Explorer のプロキシ設定の項目で
 設定を自動的に検出するにチェックを入れておくだけでよい。
これらの方法は上記のリストの順に優先順位が高い。すなわち、上から順に pac ファイルが検出され、見つかった時点でそれを適用する。現在の実装の状況から、一般的にはブラウザに設定する、あるいは DHCP を用いるか、DNS の A lookup を用いることが多い。

B.11

コストモデル

PIX モデルでの回線維持費を調査することにより、PIX におけるコストモデルを考察した。

PIX モデルに参加している組織は、インターネットへの専用線と PIX 内への接続回線を持つ。この時、総トラフィックが一定だと仮定し、総トラフィックを満たす場合の月額の回。
線維持費用を求めた（例：図 B.16）
このグラフを求めたことで、総トラフィックが大きい程、また地域内トラフィックの割合が大きい程月額の回線維持費用は PIX が有利なことがわかった。また無線ユニットによる接続では、トラフィック状況にほぼ無関係に PIX が有利である。

{ 79 {

B.11 コストモデル

Total traffic 1.5Mbps, Distance to connection point 89km
to Internet only
to Internet & leased line to PIX
to Internet & wireless unit to PIX

1.6e+06

1.4e+06

1.2e+06

[yen]

1e+06

800000600000400000200000

0
0

200

400

600

800

1000

[inner traffic(kbps)]

図 B.16 PIX モデルの月額回線維持費用例{ 80 {

1200

1400

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

KPIX 実験研究協議会メンバーである高知大学の菊地先生、高知高専の今井先生、高知シ
ステムズの松本さん、シティネットの澤本さん、富士通高知システムエンジニアリングの平田さん、高知県工業技術センター武市さんと今西さん、高知県情報企画課の蒲原さんと森さん、KPIX の構築・運営など大変お世話になりました。高知大の滝沢さんと山岡さんと田村さん、高専の杉本さん、研究に協力していただきありがとうごさいます。
島村和典教授をはじめとする、TAO 通信トラヒックリサーチセンターの皆様に感謝します。また、島村研究室の中平拓司さんには、ATM スイッチの資料をいただき、ありがとうございました。
同じテーマで研究を行い、協力してくれた、西内君、廣瀬君、正岡君に感謝します。同じ
菊池研究室の田渕さん、戸梶さん、長尾さん、角谷君、舟橋君に感謝します。
最後に、菊池 豊助教授に心から感謝します。
本実験研究は、通信・放送機構の平成 11 年度地域提案型研究開発制度（研究開発名「インターネットにおける地域指向型トラヒック交換モデル」）と、科学研究費補助金（課題番
号 11450153）との助成を受けています。

{ 81 {

参考文献[1] I. Cooper, P. Gauthier, J. Cohen, M. Dunsmuir, and C. Perkins. Web proxy autodiscovery protocol, November 2000. draft-cooper-webi-wpad-00.txt.
[2] David L. Mills. Network time protocol version 3, March 1992. RFC 1305.
[3] J. Mogul, D. Mills, J. Brittenson, J. Stone, and U. Windl. Pulse-per-second api for
unix-like operating systems, version 1.0, March 2000. RFC 2738.
[4] 中川郁夫, 林英輔, 樋地正浩, 八代一浩, 菊池豊, 西野大. ギガビットネットワークを用いた地域間相互接続の試み. 情報処理学会研究報告 99-DSM-15, pp. 7{12. 分散システ
ム運用技術研究会, 1999. ISSN 0919-6072.

[5] 今井一雅, 澤本一哲, 矢野漣, 菊地時夫, 菊池豊. 高速無線 LAN システムによる地域情報化ネットワークの構築と運用. 信学技報, pp. 39{44. 電子情報通信学会, January 2000.

[6] 西内一馬, 杉山道子, 廣瀬崇夫, 正岡元, 菊池豊. 高知地域指向疑似 IX の課題と解決
法. 情報処理学会研究報告, pp. 25{30. 分散システム運用技術研究会, October 2000.

ISSN0919-6072.
[7] 大澤光. インターネットストリーミング. 共立出版, 2000.
[8] 鍋島公章. キャッシュサーバの運用技術, dec 2000. Internet Week 2000, Tutorial.
[9] 櫻井智明, 山本文治. ストリーミング技術, dec 1999. Internet Week '99, Tutorial.
[10] 櫻井智明, 山本文治. ストリーミング技術, dec 2000. Internet Week 2000, Tutorial.
[11] 菊池豊, 菊地時夫. PIX: 応用層によるトラフィック交換モデル. インターネット
コンファレンス'97 論文集, pp. 159{162. 日本ソフトウェア科学会, December 1997.

ISSN1341-870X.
[12] 菊池豊, 菊地時夫. 応用層によるインターネットトラフィック交換モデル. コンピュー
タソフトウェア, Vol. 16, No. 4, pp. 46{58, July 1999.

[13] 菊池豊, 菊地時夫, 今井一雅, 松本浩明, 濱崎哲一, 武市統, 今西孝也, 澤本一哲, 杉山道{ 82 {

参考文献

子, 西内一馬, 廣瀬崇夫, 正岡元, 蒲原浩, 寺田浩詔. 高知応用層交換所の構築. 情報処理学会研究報告, pp. 49{54. DSM 研究会, May 2000. ISSN0919-6072.

{ 83 {