第 8部
ネット ワーク管理303

第 1章はじめに
1.1

国内のインターネット の利用状況

国内のインターネットは、以下のネットワークプロジェクトによって運用されている個々のネットワークが相互接続することによって構築されている。
WIDE Internet:

WIDE プロジェクトが研究基盤として構築運用しているネットワーク

TISN: 東京大学理学部が中心となって構築され運用されているネットワークで、主に理学関連の研究組織がその参加組織である。
JAIN: 大学内ネットワークの相互接続を主な研究テーマとしている、科研費を基盤としたネットワーク
SINET:'92 年 4 月より運用を開始した学術情報センターが運用しているネットワーク

個々のネットワークの利用形態は、それぞれの運用ポリシや目的によって異なる。例えば、TISN などでは、高エネルギー物理学関連の大量の情報交換がされている可能性もあ
るし 、また、実際には、IP プロトコル以外のプロトコル、例えば DECnet プロトコルによる情報交換も行われている。また、WIDE Internet では、ルーティングプロトコルの実験のために BGP などのパケットが飛び交っているかもしれない。
このようにネットワークの利用形態は、個々のネットワークでは、ネットワークの目的の違いや運用ポリシーの違いなどによって大きく変化する。このため、国内のインターネットの全体的な利用状況を把握する方法として、個々のネットワーク内の利用状況を把握するだけでは不十分である。

WIDE プロジェクトでは、国内のインターネットの利用状況を把握するための１つの方法として、個々のネットワークの間で相互に交換される情報を分析することを行ってきた。
本節では、国内のインターネットの利用状況を把握するために行ってきた、ネットワー
ク間の相互トラフィックの解析結果について述べる。

305

306
1.2

1991 年度

WIDE 報告書

TIX(Tokyo Internet eXchange) のト ラフィック

WIDE プロジェクトでは、東京大学に敷設されているネットワーク相互接続用セグ メ
ントを監視し 、各ネットワークプロジェクトが運用しているネットワーク間のトラフィッ
クを 1991 年 6 月から測定してきた。
東京大学に敷設されているネットワーク相互接続用セグ メントの構成を図 1.1 に示す。

UTnet

R

R

256Kbps
10Mbps64Kbps x1(192Kbps)

R
R

WIDE

64Kbps x 2
48Kbps x1

R

JAIN

10Mbps128Kbps x1
64Kbps xN

R

TISN

図 1.1: ネットワーク相互接続用セグメントの構成

WIDE Internet、TISN、JAIN は、TIX によってそれぞれネットワーク間接続を行っている。もちろん、個々のネットワークの相互接続は、TIX 以外でも行われているが、トラフィック的には TIX による情報交換量が一番多い。また、今回のトラフィックの測定は、国内のインターネットの利用状況の概要把握であるので、他のネットワーク間接続
点によるトラフィック解析は行わなかった。
この相互接続用セグ メントにトラフィック監視用ワークステーションを設置し 、このワークステーションで、nnstat プログラムを実行し 、各プロトコル別のトラフィックを 1
時間単位でサンプリングした。
各々のネットワーク間の月別トラフィックを表 1.1, 1.2, 1.3に示す。また、月別の変化を示すためのグラスを図 1.2, 1.3, 1.4に示す。
これらの表とグラフから分かるように、国内インターネットのトラフィックは着実に増加している。WIDE-TISN 間では、約 1.6 倍、WIDE-JAIN 間のトラフィックでは、約 3.8倍にもなっている。特に JAIN は、この 1 年間で既設の回線速度が 9.6 Kbps から 64 Kbspに増強された組織が多く、また、新しく参加した組織も非常に多かった。JAIN と海外との通信は、現在 WIDE が転送していることもあり、WIDE と JAIN 間の通信量は飛躍的に増加したと考えられる。
アプリケーション別では、特に FTP の利用多く、ついで SNMP や Telnet の利用が多い。

第 8部

ネットワーク管理

307

Domain の情報量も結構多く、特に月別の変動では トラフィックが大きく変化している。これは 、ネームサーバの設定ミスなどによる事故や、ネットワークの状況変化 (特に、片方向のみの通信が不通などによる場合) などによるものであると考えられる。特に Domain は、UDP を用いているため、一旦異常な状態となると、短時間に大量のトラフィックを生むのも大きく影響していると考えられる。

表 1.1: WIDE-TISN 間の月別トラフィック (KByte)'91 Jun
Jul
Aug
Sep
Oct
Nov
Dec
'92 Jan
Feb
Mar
Apr
延び率

IP(All)2,542,478
4,240,318
4,062,328
3,301,529
2,853,132
4,760,936
3,456,340
3,791,860
3,587,969
4,691,225
4,713,951
1.61

FTP
1,312,325
1,481,137
1,250,338
1,769,781
1,802,573
2,074,873
2,186,951
2,506,932
2,464,764
2,913,225
2,845,160
1.36

SMTP
159,190
202,958
216,965
224,283
220,031
186,815
204,881
168,208
180,329
373,834
195,749
1.31

Telnet Domains
128,642 336,014
116,823 1,962,707
224,597 1,408,298
219,514 388,072
189,676 192,771
224,264 1,643,706
220,371 378,157
291,748 270,733
282,124 262,313
297,491 556,454
410,180 391,297
2.81
0.28

308

1991 年度

WIDE 報告書

5000

Traffic (M bytes)

4000

Other
Domains
FTP
ICMP
NNTP
SMTP
SNMP
Telnet

3000

2000

1000

0
Month (’91 Jun - ’92 Apr)

図 1.2: WIDE { TISN 間のトラフィック

表 1.2: WIDE-JAIN 間の月別トラフィック (KByte)'91 Jun
Jul
Aug
Sep
Oct
Nov
Dec
'92 Jan
Feb
Mar
Apr
延び率

IP(All)FTP SMTP Telnet Domains
540,535 115,733 236,843 48,228 65,567
1,114,918 500,513 335,689 86,924 53,778
526,870 111,713 91,163 34,973 169,675
1,303,860 496,329 346,186 151,090 185,990
1,080,271 574,371 238,997 101,605 98,132
1,208,028 662,384 233,128 89,109 95,344
901,904 438,393 154,384 51,188 117,208
1,573,492 573,279 326,370 97,779 303,873
2,236,192 1,132,060 337,170 149,673 108,678
2,007,899 725,010 323,279 146,507 135,322
2,098,100 974,207 402,994 102,915 266,878
3.73
4.81
1.60
1.98
2.56

第 8部

309

ネットワーク管理

5000

Traffic (M bytes)

4000

Other
Domains
FTP
ICMP
NNTP
SMTP
SNMP
Telnet

3000

2000

1000

0
Month (’91 Jun - ’92 Apr)

図 1.3: WIDE { JAIN 間のトラフィック

表 1.3: TISN-JAIN 間の月別トラフィック (KByte)'91 Jun
Jul
Aug
Sep
Oct
Nov
Dec
'92 Jan
Feb
Mar
Apr
延び率

IP(All)FTP
581,024 224,246
839,071 487,233
858,051 495,153
1,382,344 698,206
1,595,315 871,919
1,174,059 667,514
1,367,601 587,109
1,400,363 688,673
1,277,986 690,198
1,631,300 981,139
1,815,152 1,124,068
2.19
2.63

SMTP
14,54765,046
21,26539,58968,561
36,156
38,711
41,33547,57668,802
46,953
1.61

Telnet Domains
36,509 79,828
56,155 130,687
65,707 182,705
102,142 223,176
143,559 114,698
94,546 235,110
111,869 342,916
143,140 287,857
145,716 152,741
139,018 171,232
106,651 128,595
2.47
1.39

310

1991 年度

WIDE 報告書

5000

Traffic (M bytes)

4000

Other
Domains
FTP
ICMP
NNTP
SMTP
SNMP
Telnet

3000

2000

1000

0
Month (’91 Jun - ’92 Apr)

図 1.4: TISN { JAIN 間のトラフィック

第 8部

1.3

311

ネットワーク管理

WIDE Internet 内のト ラフィック変化

WIDE Internet Backbone の一部である東京 WNOC-TYO と藤沢 WNOC-SFC 間のト
ラフィックを TIX における方法と同様な方法で解析した結果を表 1.4および図 1.5に示す。
WIDE Internet でも、やはり FTP の利用が全体的なトラフィックの約半分を占めているが、ネットワーク相互のトラフィックに比べ、SMTP や NNTP のトラフィック量の占める割合が多くきている。
トラフィック全体の延び率は、この 1 年間で約 2 倍となっている。特徴的な延び率としては、NNTP の延び率が 0.96 と減少傾向となっている。これは 、この 1 年間で NNTPの無駄なトラフィックを無くすために、NNTP の転送ルートの整備を行い、この作業が実際に無駄なトラフィックの軽減につながったことが実証された。

表 1.4: TYO-SFC 間の月別トラフィック (KByte)'91 Jul
Aug
Sep
Oct
Nov
Dec
'92 Jan
Feb
Mar
Apr
延び率

1.4

IP(All)
FTP
SMTP
12,430,567 4,047,112 2,022,677
11,344,093 3,480,102 1,547,636
13,892,836 5,294,130 2,295,448
15,649,191 6,513,230 2,393,632
23,959,390 6,544,481 2,345,672
14,481,251 6,128,593 1,997,405
19,089,774 8,703,864 2,695,241
19,997,879 8,235,701 2,674,243
23,374,788 10,287,483 3,076,802
23,317,416 11,760,961 3,146,812
1.98
3.25
1.71

NNTP
1,986,258
1,685,200
1,746,925
2,161,649
2,278,958
1,732,619
1,890,842
1,945,997
1,936,481
1,675,369
0.96

Telnet Domains
734,701 2,358,779
762,387 1,758,437
909,152 1,927,544
1,198,182 1,690,774
1,071,300 8,845,131
881,740 2,119,617
1,299,752 1,641,755
1,244,516 1,756,911
1,289,983 2,694,001
1,173,855 2,278,772
1.64
0.96

まとめ

WIDE プロジェクトでは、国内のインターネットの利用状況等を把握するため、本節で述べたような情報収集を重要な拠点で行っている。このような情報収集は、ネットワー
クの利用状況を把握するだけではなく、定常的なトラフィックに対して異常と考えられる
トラフィックを検出するような技術の開発の基盤となる重要な研究である。
しかし 、本節で解析した情報だけでも、圧縮した形式で保存したとしても約 1G Byte の情報量になり、また、収集した情報を解析するために、圧縮されたファイルを解凍し 、解析する処理を行うためには、非常に多くの時間が必要である。例えば 、今回の解析でも、必要な情報を圧縮されたファイルから抜き出すだけで、1 日以上の時間が必要であった。

312

1991 年度

WIDE 報告書

25000

Traffic (M bytes)

20000

Other
Domains
FTP
ICMP
NNTP
RIP
SMTP
SNMP
Telnet

15000

10000

5000

0
Month (’91 Jul - ’92 Apr)

図 1.5: TYO { SFC 間のトラフィック

第 8部

ネットワーク管理

今後、このような情報の保存に対する研究も重要な項目である。

313

第 2章
国際ト ラフィックに関する調査
2.1

はじめに

インターネットによって提供される、電子メール、電子掲示板、遠隔ログイン、ファイ
ル転送などのサービスは、研究者が情報を交換したり、資源を共有したりするために必要不可欠なものになりつつある。
しかし 、海外から国内、および、国内から海外に向かうこのようなサービスのトラフィッ
クは、WIDE と PACCOM との間の国際リンクに集中している。
一般的にこのような国際リンクは長距離の国際専用線によりまかなわれており、比較的バンド 幅が小さい割にコストはかかるものである。このような限られた資源を効率よく利用していくことは、上に挙げたようなサービスを維持し 、品質を改善して行くために必要不可欠である。
本章の目的は、

 PACCOM-WIDE 間の国際リンクの現在の利用状況の評価
 これらのサービスを利用した、国際コミュニケーションの到達範囲および交換される情報量の測定である。
ここで用いた方法は、主要なアプリケーションプロトコルにより交換されるパケットのヘッダ情報を収集し 、それらを解析するというものである。ほとんどのユーザーサービ
スを提供するアプリケーションプロトコルは TCP をトランスポート層のプロトコルとして用いているので、ここでのデータ収集、解析は TCP のトラフィックのみに注目する。
ここで強調したい点は、このような解析は国際トラフィックの性質を知る上での最初のステップだということである。ここで示す解析結果は、国際間で交換される情報の流れを最適化するための基本的なデータをあたえるものであり、有効なネットワークのプランニングを行うためには、さらにこのような調査を繰り返し 、また、国内のトラフィック
をも含めて、より広い範囲で行うことが必要である。
最初の２つの節で、ネットワークの構成と、データ収集・解析の手法について述べ、後の節でこれらの解析結果について述べる。

314

第 8部

2.2

ネットワーク管理

315

日本からのインターネット への接続

本節では WIDE インターネットと NSFNET との接続形態について述べる。

U.S.A
Korea

TPC-3
HAW-4

Japan
Hawaii

Australia

New Zealand

図 2.1: PACCOM のトポロジー

WIDE インターネットと NSFNET バックボーンとの接続は PACCOM(Paci c Computer
Communication Infrastructure) を経由して行なわれている。図- 2.1は PACCOM のトポ
ロジーの概略である。

日本国内においては、学術研究ネットワークは、TISN 、JAIN 、WIDE の３つの独立したネットワークから構成されている。TISN は 14 のインターネットリーチャブルなサイ
ト 1を持ち、128 Kbps の国際専用線でハワイ大学と接続されている。JAIN と WIDE は、それぞれ 22 、34 のインターネットリーチャブルなサイトを持ち、WIDE が持つ 192 Kbpsの国際専用線でハワイ大学と接続されている。TISN と WIDE が持つこれらの国際専用
線は、物理的には、同じ TPC-3(Trans Paci c Cable) という海底ケーブルを用いている。
一方、日本からのこれら２つの線と韓国からの線は、ハワイ大学内のイーサネットを経由して、512 Kbps2の専用線を経由して NASA-Ames にある、FIX-West(Federal Internet
eXchange-West) に接続されている。オーストラリアやニュージーランド も NASA-Ames
12

これらのサイト数は、１月２５日現在の数字である。
現在は T1 にアップグレードされている。

316

1991 年度

WIDE 報告書

で、PACCOM ネットワークに接続されている。日本とこれらの国々との間のすべてのトラフィックはハワイ大学との間の回線を通っている。
本節で報告するデータ解析は、WIDE インターネットとハワイ大学の間の 192 Kbps の回線上のトラフィックのみに対して行なった。しかし 、日米間のトラフィックの約 60%はこの回線を経由しているので、この回線上のトラフィックが日本の国際トラフィックを代表していると考えられる。

2.3

データ収集・解析環境

日本と他の国々との間のすべてのトラフィックは、WIDE 藤沢ネットワークオペレー
ションセンター (WNOC-SFC) 内にあるイーサネット上を経由する。データの収集は、このイーサネットセグメント上に設置された SparcStation1+上で行なった。図-2.2 、図-2.3
はこのデータ収集環境を図示している。CPU に対する負荷等を考慮して、収集したデータの解析はリアルタイムには行なわず、後ほど別のマシン上で行なった。
観測されたほとんどのトラフィックは FTP 、SMTP 、 Telnet 、 DNS 等の TCP/ IP プ
ロトコル群に属するパケット [?] によるものである。データの収集には tcpdump[?] を用い、各プロトコルヘッダに含まれる情報のみを集めた。
回線速度が比較的低速であったので、tcpdump の処理のオーバーヘッドにより拾いきれなかったパケットは、全体の約 0.2%であった。データの収集期間は１９９２年１月１９日（ 日）から１月２５日（土）の１週間である。この期間に観測されたデータのうちTCP プロトコルを用いたものが約２ギガバイトで、実際に収集したプロトコルヘッダ情報は compress により圧縮した状態で約 280 メガバイトであった。これらのヘッダ情報を、
perl 言語 [?] を用いて解析した。
TCP を用いたアプリケーションプロトコルのトラフィックについて調べるために、TCPの" データ" に注目した。すなわち、これ以後の議論では、TCP 以外のトラフィックは除外
し 、バイト数には IP や TCP のヘッダは含めず、また、パケット数には、acknowledgment
パケットのようなデータサイズが 0 であるようなパケットは含めない。
今回 TCP のコネクションを追跡するために以下のヘッダ情報を用いた [?] 、

 ソースおよびデスティネーションイーサネットアドレス
 ソースおよびデスティネーション IP アドレスおよび TCP ポート
 TCP フラグ （ 例： SYN, FIN, 等） シーケンス番号 ( Sequence number ) アクノレッヂ番号 ( Acknowledgement number )これらの情報により、

1. 日本から外に出てゆく、また、日本に入ってくる、バイト数、パケット数の計測

第 8部

ネットワーク管理

317

2. 各 TCP コネクションの追跡
3. TCP コネクションのコネクション要求の方向の検知
4. コネクション要求の方向に対して順方向、逆方向に送られるバイト数、パケット数の計測

5. 各アプリケーションプロトコルで交換された情報量の計測を行なった。
さらに、DNS や whois データベースを用いて各コネクションの両端の IP アドレスを
ド メイン名に変換し 、それらが属する国を調べた。
以下の節では、これらの解析結果について論ずる。

318

1991 年度

WIDE 報告書

WNOC-SNDWNOC-TYO
WNOC-SFC

U.S. Internet

WNOC-KYO
WNOC-OSAWNOC-FUK

図 2.2: WIDE インターネットの構成

PACCOM
192 Kbps

jp-entry

Proteon 4100+
192 Kbps

WNOC-TYO

64 Kbps

WNOC-KYO

64 Kbps

WNOC-SNDSun SS1+
jp-tapjp-gateSun4/260shendo

Sun3/480

Sun4/490

WNOC-SFC

図 2.3: データ収集環境

第 8部

ネットワーク管理

2.4

国内向き・海外向き TCP ト ラフィック

2.4.1

国際回線の利用状況
日付
1 月 19 日
1 月 20 日
1 月 21 日
1 月 22 日
1 月 23 日
1 月 24 日
1 月 25 日

合計319

バイト 数 （Ｋｂｙｔｅｓ）
海外から国内 国内から海外
合計

166,711229,702
190,187
427,900
308,425
305,437
139,933
1,768,296

48,403 215,114
61,679 291,381
85,995 276,182
129,265 557,165
88,587 397,011
108,736 414,174
73,978 213,911
596,643 2,364,938

表 2.1: データ転送量

日付
1 月 19 日
1 月 20 日
1 月 21 日
1 月 22 日
1 月 23 日
1 月 24 日
1 月 25 日

合計

平均回線利用率 （Ｋｂｐｓ）
海外から国内 国内から海外
合計

17.06( 8.9%)
23.80(12.4%)
23.66( 12.3%)
43.15(22.5%)
34.87(18.2%)
31.38(16.3%)
14.64( 7.6%)
26.91(14.0%)

5.21( 2.7%) 22.27( 5.8%)
6.85( 3.6%) 30.65( 8.0%)
11.34( 5.9%) 35.00( 9.1%)
13.97( 7.3%) 57.11(14.9%)
10.82( 5.6%) 45.70( 11.9%)
11.78( 6.1%) 43.17(11.2%)
8.08( 4.2%) 22.72( 5.9%)9.67( 5.0%) 36.58( 9.5%)

表 2.2: 回線利用率
表-2.1は１月１９日から２５日までの日々のＴＣＰデータのトラフィック量、また、表2.2は日々の平均データ転送速度である。また、図-2.4は１時間毎の日本から海外、海外から日本のそれぞれの方向に流れたデータ量のグラフである。
データ収集を行なった７日間（１６８時間3 ）で約２ギガバイトのＴＣＰデータがこの回線上でやりとりされた。
3

２１日の１８：２０から２２：０８まで、および 、２３日の１８：０５から２０：１５までの間ゲー
トウェイマシンのダウンがあったので、正確なデータ収集期間は１６２時間と２分である。

320

1991 年度

Inbound Traffic
Outbound Traffic

60000

WIDE 報告書

Average Inbound Traffic
Average Outbound Traffic

Bytes per hour ( Kbytes )

50000

40000

30000

20000

10000

0

0:00

12:00

0:00

Jan 19( Sun )

12:00

Jan 20( Mon )

0:00

12:00

Jan 21( Tue )

0:00

12:00

0:00

Jan 22( Wed )
Time ( Hour )

12:00

0:00

Jan 23( Thu )

12:00

Jan 24( Fri )

0:00

12:00 ( JST )Jan 25( Sat )

図 2.4: 国内向き・海外向きトラフィックのデータ転送速度 (バイト／時)

ＴＣＰのパケットはそれぞれ最低でも２０バイトのＩＰヘッダと２０バイトのＴＣＰ
ヘッダを持つ。この期間中約７７０万のデータパケットが観測され、ヘッダを除いた平均パケット長は３１３バイトであった。パケット数にヘッダの分の４０を掛け、これをＴＣＰデータのバイト数に加えて以下のような計算をすると、ＴＣＰトラフィックの１時間あたりの平均転送速度は約３６．６ Ｋｂｐｓとなる。

(総データ量 + 総パケット数 2 ４０ ) 2 ８ (bits=byte)
総観測時間

=

973240(2; 364; 938 + 7 7291024)28= 36:58Kbps
583; 320;;

国際回線の容量はそれぞれの方向に１９２Ｋｂｐｓなので、７日間でＴＣＰのトラフィッ
クは平均約９．５％を占めたことになる。これは平均では比較的低い利用率といえるかも知れない。しかし 、図-2.4は、回線利用がピークを向かえる時間帯においては、かなり高い利用率になっていることを示している。７日間でもっとも高かった時間帯4で、国内
4

国内に向かうトラフィックは１月２２日の１４時台が、海外に向かうトラフィックは１月２４日の８時台がピークであった。

第 8部

321

ネットワーク管理に向かう１時間あたりの平均転送速度は約１３３Ｋｂｐｓであり、海外に向かう平均転送速度は約３７Ｋｂｐｓであった。

このことから、ここに示した値がＴＣＰ以外のトラフィックや、データサイズが 0 であるようなＴＣＰトラフィックを除外したものであることも考慮すると、もっとも利用率の高い時間帯では、回線はかなり混雑していることが分かる。さらに、例えば１５分間隔のようにより短い範囲での平均を求めれば、より高いトラフィックのピークが見られるだ
ろう。

2.4.2

サービス要求の方向

Inbound Connection
Outbound Connection
Number of Connection Requests per Hour

900

800

700

600

500

400

300

200

100

0

0:00

12:00

Jan 19( Sun )

0:00

12:00

Jan 20( Mon )

0:00

12:00

Jan 21( Tue )

0:00

12:00

Jan 22( Wed )

0:00

12:00

Jan 23( Thu )

0:00

12:00

Jan 24( Fri )

0:00

12:00 ( JST )Jan 25( Sat )

図 2.5: 国内から海外、海外から国内に対するコネクション要求の数
図-2.5は、海外から国内、国内から海外の各方向に送られたコネクション要求の１時間毎の個数のグラフである。このグラフから次のような特徴があることが分かる。すなわ
ち、国内から海外に向かうコネクション要求は、正午から深夜の間に多く発生し 、一方
深夜から午前中にかけては非常に少ない数しか発生していない。このパターンは日本の研究者たちの典型的な労働時間帯を反映していると思われる。

しかし図-2.5のグラフは、サービスの要求という観点から考えると正確とはいえない。
通常は、TCP のアプリケーションが提供するサービスのクライアント側が、TCP のコネ
クション要求をサーバーに対して送る。しかし 、例えば FTP-Data の場合は特殊で、コネクション要求はサーバー側からクライアント側へと送られる。すなわち、FTP-Dataのコネクション要求が送られる方向と、サービスを要求する方向とが逆になっている。

322

1991 年度

WIDE 報告書

このことを考慮して、FTP-Data のコネクション要求の方向を逆向きにして、図-2.5のグラフを書き直したものが、図- 2.6である。

第 8部

323

ネットワーク管理

Inbound Service
Outbound Service

Number of Service Requests per Hour

900

800

700

600

500

400

300

200

100

0

0:00

12:00

0:00

Jan 19( Sun )

12:00

Jan 20( Mon )

0:00

12:00

0:00

Jan 21( Tue )

12:00

0:00

Jan 22( Wed )

12:00

0:00

Jan 23( Thu )

12:00

0:00

Jan 24( Fri )

12:00 ( JST )Jan 25( Sat )

図 2.6: 国内から海外、海外から国内に対するサービス要求の数
図-2.6のグラフの、国内から海外に向かうサービス要求数の曲線は、図-2.5の国内から海外に向かうコネクション要求数の曲線よりも、深夜から午前中にかけて少なく、昼過ぎから深夜にかけて多くなるというパターンをより顕著に示している。さらに、海外から国内に向かうサービス要求数の曲線は、これとは逆の、比較的午後は少なく午前は多い、というパターンを示している。日本とアメリカの時差がこのような回線の時差利用をもたらしているといえる。
国内向き、海外向きのパケット長はどちらも比較的小さい値（１００バイト以下）と、
512 バイト周辺の２つのピークを持つ分布になっている (図- 2.7 、図-2.8)。512 バイトという値は、TCP データの最大値として良く用いられている値である。

方向
海外から国内国内から海外合計

平均および百分位数
平均

5%

25%

50%

75%

95%

365.185
220.439313.287

1
1
1

33
3
13

512
50
512

512
512
512

512
512
512

表 2.3: 国内向き・海外向きパケットサイズ分布 ( 単位：バイト )表-2.3は、国内向きトラフィックの平均パケット長が海外向きのトラフィックの平均パ
ケット長よりも大きいことを示している。百分位数を比較すると、国内向きパケットの324

1991 年度

WIDE 報告書

内、FTP-Data のような、巨大データ転送プロトコルに属するパケットの割合が、海外向きのその種のパケットの割合よりも多いことが分かる。

Number of packets in that size ( Log )1000000

100000

10000

1000

100

10

1
1

100

512

1460

Packet Size ( Bytes )図 2.7: 国内向きパケット長分布

1000000

Number of packets in that size ( Log )100000

10000

1000

100

10

1
1

100

512

1460

Packet Size ( Bytes )図 2.8: 海外向きパケット長分布

第 8部

2.4.3

ネットワーク管理325

プロト コル別統計値

コネクション要求の方向を調べるために、SYN パケットをとりそこねたコネクション
に関しては、これ以降の議論には含めない。これらの除外したコネクションにより交換されたデータの量は、表-2.1に示された合計値の２％であった。
プロト コルFTP-Data
SMTP
NNTP
TelnetDomainFTP
Finger

その他
合計

海外から国内国内から海外1,345,224 77.16% 402,474 70.84%
121,164 6.95% 65,880 11.60%
142,038 8.15% 44,252 7.79%
42,694 2.45% 30,026 5.28%
15,063 0.86%
347 0.06%
5,270 0.30% 4,381 0.77%
978 0.06% 1,192 0.21%
71,049 4.08% 19,619 3.45%
1,743,480 100.00% 568,171 100.00%

表 2.4: プロトコル別、国内向き・海外向き転送データ量（キロバイト ）と合計に対する割合
表-2.4は、表-2.3に関して行なった解析が正しかったことを示している。FTP-Data のような巨大データ転送プロトコルによって転送されたデータ量の割合は、国内向きのト
ラフィックの方が国外向きのトラフィックよりも大きい。FTP-Data プロトコルによるデータ転送は国内向きが全体の７７％、国外向きが全体の７１％である。
表-2.5は、各アプリケーションプロトコルの、海外から国内向き、国内から海外向きのそれぞれの方向に要求されたコネクションの数と、それぞれの要求の方向に対して順方向に送られたデータ量と逆方向に送られたデータ量である。コネクション要求の方向とデー
タが流れる方向との間の関係は、アプリケーションプロトコルによって異なっている。
Telnet や FTP のような対話型のアプリケーションや、Domain や Finger のような情報照会型のアプリケーションでは、コネクション要求の方向に対して逆方向により多くのデータが流れる。それに対して、FTP-Data や SMTP のようなデータ転送型アプ
リケーションでは、コネクション要求の方向に対して順方向により多くのデータが流れる。NNTP に関しては、データが送られる方向は、コネクション要求の方向には依存せず、ニュースの転送経路の設定に依存しているようだ。

326

1991 年度

プロト コルWIDE 報告書

コネクション数

FTP-Data

海外から国内国内から海外SMTP

海外から国内国内から海外NNTP

海外から国内国内から海外Telnet

海外から国内国内から海外Domain

海外から国内国内から海外FTP

海外から国内国内から海外Finger

海外から国内国内から海外その他

海外から国内国内から海外合計

海外から国内国内から海外転送データ量 (キロバイト )順方向
逆方向

22,593 1,251,408
15,181
398,256
21,260115,505
16,88857,814
6,270
46,587
8,969
39,067
1,736
1,000
1,492
802
550
15
2,798
86
2,598
896
3,333
1,251
4,013
24
1,469
9
649
5,717
1,065
6,400
59,669 1,421,153
51,195
503,686

4,218
93,816
8,066
5,658
5,184
95,451
29,224
41,694261
15,048
3,130
4,374
1,183
954
13,21965,33164,485322,327

表 2.5: プロトコル別、国内向き・海外向きコネクション

プロト コルFTP-Data
Domain
NNTP
SMTP
FingerTelnet
FTP

その他
合計

平均

百分位数
5%

25%

50%

75%

95%

529.403 512 512
425.633 23 512
324.769 8 43
220.427 6 33
128.772 2
2
53.915 1
130.293 6 16
121.698 1
2
313.287 1 13

512
512
512
60
9
2
25
14
512

512
512
512
512
210
9
30
121
512

536
512
512
512
512
512
73
512
512

表 2.6: プロトコル別パケット長分布（ バイト ）

第 8部

327

ネットワーク管理表-2.6は、各アプリケーションプロトコルのパケット長の分布である。Telnet や FTPのような対話型のアプリケーションのパケット長は比較的小さな値の周りに分布しており、FTP-Data のような巨大データ転送型のアプリケーションのパケット長は、512 バ
イトの周りに多く分布している。

Number of packets in that size ( Log )図 2.9: Telnet のパケット長分布

1000

100

10

1
0

100

200

300

400

500

Packet Size ( Bytes )図 2.10: Finger のパケット長分布

600

700

328

1991 年度

WIDE 報告書

Number of packets in that size ( Log )

10000

1000

100

10

1
0

100

200

300

400

500

Packet Size ( Bytes )図 2.11: Domain のパケット長分布

Number of packets in that size ( Log )

10000

1000

100

10

1
0

50

100

150

200

250

300

350

400

450

500

550

Packet Size ( Bytes )図 2.12: FTP のパケット長分布

Number of packets in that size ( Log )1000000

100000

10000

1000

100

10

1
1

100

512

1460

Packet Size ( Bytes )図 2.13: FTP-Data のパケット長分布

第 8部

329

ネットワーク管理

Number of packets in that size ( Log )100000

10000

1000

100

10

1
0

100

200

300

400

500

600

700

800

900

1000

1100

1200

1300

1400

1500

Packet Size ( Bytes )図 2.14: SMTP のパケット長分布

Number of packets in that size ( Log )100000

10000

1000

100

10

1
0

100

200

300

400

Packet Size ( Bytes )図 2.15: NNTP のパケット長分布

500

330
2.5

1991 年度

WIDE 報告書

日本と他の国々との間の情報交換

アプリケーションプロトコルを介して、情報がどの国との間で交換されているのかを詳しく調べるために、DNS を利用して、すべてのＴＣＰコネクションの両端のホストのIP アドレスからをド メイン名に変換した。そして、得られたド メイン名の一番右側の部
分をそのド メインが属する国名として用いた。残念ながら DNS だけではすべての IP ア
ドレスをド メイン名に変換することができなかったので、whois データベースを併用して、少なくともその IP アドレスが属している国名だけでも調べようと試みた。それでも
まだ、どの国に属しているのか不明な IP アドレスがあったが、それらの IP アドレスが関係しているコネクションについては、以下の議論からは除外した。幸いここで除外されたコネクション数は、2.4章で用いたコネクション数の 0.6%であり、それらのコネクショ
ンにより交換されたデータ量は、2.4章で用いたデータ量の 0.9%であった。
本節に示す解析結果は、日本の研究者たちと他の国々の研究者たちとの間で交換される情報の量、種類について着目したものである。一般的に、日本と他の国々との間、特にアメリカとの間の情報の流れには、かなりの不均衡があると考えられている。すなわち、情報の流れは日本の外から一方的に流れ込んでおり、日本から海外に対しては、ほとん
ど情報が流れていないと思われがちである。しかし 、ここに示す解析結果により、かなりの量の情報が日本から海外にも同様に流れているということが分かる。
表-2.7は、日本と他の国々との間で交換されたすべてのＴＣＰデータの量である。各行の一番右の欄は、相手の国を表すトップド メインの名前で、合計バイト数の多い順に並べられている。ほとんどのデータはアメリカ（ edu, com 等のド メイン ）との間で交換されているが、それでも、少なくとも全体の１３％はそれ以外の国との間で交換されている。
これは、日本の研究者たちのコミュニケーションの範囲が 、対アメリカのみに留まらず、環太平洋地域やヨーロッパ等の多くの国々にまで広がっていることを示している。

ネットワーク管理

331

バイト 数
海外から国内 国内から海外

コネクション数
海外から国内 国内から海外

第 8部

ド メイン

edu
com
org
gov
net
de
fr
au
ca
uk
mil
se
dk
il
ch
nl
at
it
nz
no
br
hk
es
sg
us
kr
mx
gr
ie
hu
pl
za
is
be
pt
tw

国名
アメリカ
アメリカ
アメリカ
アメリカ
アメリカ
ド イツ
フランス
オースト ラリア
カナダ
イギリス
アメリカ
スウェーデン
デンマーク
イスラエル
フィンランドスイス
オランダオースト リアイタリア
ニュージーランド
ノルウェイ
ブラジル
香港
スペイン
シンガポール
アメリカ
韓国
メキシコ
ギリシャ
アイルランド
ハンガリー
ポーランド
南アフリカ
アイスランド
ベルギー
ポルトガル
台湾
合計

1,081,824,425
253,380,216
140,661,183
77,792,355
77,181,168
42,092,581
21,256,861
16,374,621
17,216,893
6,657,069
17,874,860
19,763,793
1,976,102
44,1004,328,088
2,268,435
1,624,967
359,268
243,684
104,019
326,597
161,578
11,973529,61272,464
246,963
277,716
22,405
12,981
15,200
10,204
117,404
17,744
14,90912,5491,371
2,878
1,784,879,236

269,582,416
75,163,919
12,156,135
24,711,322
14,219,613
17,499,247
21,649,227
21,465,957
19,904,945
18,977,853
6,368,826
3,350,355
14,151,067
12,827,143
2,828,460
3,573,455
2,690,110
3,326,400
3,122,141
2,302,672
1,866,997
1,629,413
1,602,993
744,111
1,125,344
940,123
835,935
828,502567,699
328,880
166,954
58,83058,78235,756
21,3448,694
196
560,691,816

表 2.7: 全 TCP データの流れ

28,242
14,146
1,435
1,789
3,060
1,313
364
933
3,631
950
850
371
257
46
524
202
317
338
123
53
117
71
14
60
59
40
110
14
32
5
0
27
8
3
11
0
0
59,51522,144
12,069
277
2,433
2,980
1,349
694
1,089
1,226
1,633
308
482
241
125
479
602
429
330
406
60
170
90
98
114
42
97
361
10
102
78
29
42
4
9
22
4
5
50,633

332

2.5.1

1991 年度

WIDE 報告書

主要なアプリケーションプロト コル

国際的なコミュニケーションの手段として、もっともよく使われているプロトコルは、
SMTP と NNTP である。また、一方では、FTP プロトコルが、データの交換や、パブリックド メインソフトウェアの流通の為によく使われている。以下の節では、これらの主要なアプリケーションプロトコルについて順に考察する。
SMTP のト ラフィック

表-2.8は、海外から国内、国内から海外のそれぞれの方向の SMTP のトラフィックの流れである。ＴＣＰのアプリケーションの中で、SMTP による通信が、もっとも多くの国との間で行われている。このプロトコルによるコネクションの数は、全ＴＣＰコネク
ションの３４％であり、もっともよく用いられる国際コミュニケーションの手段が 、電子メールであるということを裏づけている。いくつかの国に関しては、日本から送られるデータの量と、その国から送られて来るデータの量がほぼ等しい量になっている。
一方、日本へ送られてくるデータの量が、日本から送り出されるデータの量の２倍前後になっている国もある。SMTP のような、個人対個人のコミュニケーションに用いられるプロトコルのデータに関して、このような不均衡の存在は奇妙に思えるかも知れない。
このことを説明する一つの理由として、海外で管理されているメーリングリストに、日本から参加している研究者が多数いるということが挙げられる。このような場合、そのメーリングリストの、海外にいるすべての参加者からのメールが、日本国内に送られてくる。また、日本にいる参加者がそのメーリングリストにメールを１通出すと、メーリ
ングリストの管理ホストから、日本にいる参加者の数だけ同じ メールが複製されて、国内に返ってくるような設定になっていることが多い。このようなことから、日本から流れ出すデータ量よりも、日本に流れ込んでくるデータ量の方が多くなることが考えられる。もう一つの理由としては、RFC をメールでオーダーしたり、データベースにメールを使ってアクセスしたりするようなシステムの存在が挙げられる。そのようなシステム
では、リクエスト メールはほんの数行程度であるのに対して、返事として送られてくる
メールは、比較的大きなものになりがちである。これらのことから考えると、電子メー
ルによるコミュニケーションは、必ずしも個人対個人のコミュニケーション手段とは限
らない。

第 8部

ド メイン

edu
com
gov
net
uk
ca
au
org
nl
de
se
mil
fr
at
dk
kr
ch
us
no
it
ie
br
il
hu
es
nz
sg
za
is
hk
mx
be
pl
pt
tw
合計

バイト 数
海外から国内 国内から海外

58,073,056
32,841,366
10,654,102
3,772,570
1,958,345
2,819,436
2,797,095
2,237,973
1,196,560
1,478,962
1,323,454
1,464,593
790,418
358,308
316,232
378,208
206,621296,570
245,476
207,112
124,671
14,20095,564
39,660
10,204
44,485
68,14968,55817,744
9,896
7,053
20,476
11,613
12,212
1,371
250
123,962,563

333

ネットワーク管理

26,496,811
21,019,158
1,990,317
3,292,139
2,590,771
1,622,761
1,224,208
468,004
1,456,917
1,155,673
896,382
629,316
687,994
408,936426,281
253,572
397,324
293,712
189,559
166,551
248,329
256,546
103,155
142,141
166,954
101,518
72,27962,13358,78235,65821,936
7,820
14,998
7,577
8,694
49
66,974,955

コネクション数.
海外から国内 国内から海外

10,287
5,167
649
531
327
746
327
748
197
273
166
578
205
135
283
118
71
84
34
54
50
2
43
19
0
22
38
32
8
3
3
9
7
9
0
0
21,225

表 2.8: SMTP のトラフィック

6,878
4,862
351
895
637
432
336
96
166
275
78
129
185
174
105
40
126
428
72
53
95
63
38
41
29
37
33
26
4
8
16
3
7
2
4
1
16,725

334

1991 年度

WIDE 報告書

NNTP のト ラフィック

表-2.9はもう一つの人対人のコミュニケーション手段である電子掲示板システムのデー
タ転送に用いられている NNTP プロトコルのトラフィック量である。この電子掲示板シ
ステムとしては、USENET ニュースシステムが広く用いられている。
前述の SMTP は異なり、NNTP のコネクションは任意のホスト間で張られるものではない。むしろ、サーバー間でニュースを転送するために設定された経路に依存している。表-2.9に挙げられているド メインはわずか６つではあるが、ニュースの転送はいわゆる バケツリレー方式 で行われているので、日本で投稿されたニュースも、ここに挙げられたド メインのサーバーを経由して、世界中のサーバーへと転送されていく。さらに、日本独自のニュースグループである"fj"も、最近は海外でも転送を希望するサーバーも多数あり、日本語で書かれたニュースが海外へと流れていっている。

ド メイン
edu
com
net
uk
au
mil

合計

バイト 数
海外から日本 日本から海外

95,281,960
48,792,354
252,884
68,499883,833
144,844
145,424,374

20,872,134
11,863,547
7,269,830
3,031,062
7,809
709
43,045,091

コネクション数
海外から日本 日本から海外

12
6,221
0
14
0
0
6,247

3,252
4,418
1,125
160
9
5
8,969

表 2.9: NNTP のトラフィック

FTP のト ラフィック

いわゆる FTP のセッションは 、実際には FTP-Control5と FTP-Data の二つのプロトコルを介して行われる。FTP-Control プロトコルは、データ転送を制御するためにユーザーからサーバーに送られるコマンド の転送と、それらのコマンド の実行状況を示す応答メッセージの転送を行う。一方、"dir"や、"get"のような制御コマンドを実行
した結果出力されるデータも含む、すべてのデータの転送は FTP-Data プロトコルを介して送られる。表-2.10は FTP-Control のコネクションによるトラフィック量を、また、
表-2.11は FTP-Data のコネクションによるトラフィック量である。
これらの表から、FTP-Data のトラフィック量全体の約 22%が日本から海外に送られていることがわかる。日本から送られる FTP-Data のトラフィック量が日本へと送られてくる量よりも多いような国もある。
表-2.10と表-2.11を比較してみると、FTP-Control 日本から海外へのコネクション数と海外から日本へのコネクション数の比が、FTP-Data の海外から日本へのコネクショ
5

FTP-Contrl のことを単に FTP 呼ぶことが多い。

第 8部

ド メイン

edu
com
net
de
gov
uk
ca
au
org
fr
se
mil
it
nl
ch
dk
at
no
kr
gr
il
hk
br
us
nz
es
sg
be
mx
pl
ie
tw
合計

バイト 数
海外から国内 国内から海外

3,279,348
417,750434,258
217,727
207,119
68,891
89,611
88,852
141,291
53,88499,351
51,41559,376
19,32727,394
19,16520,904
15,43012,849
9,711
8,664
4,433
4,798
7,706
1,347
2,993
2,225
1,117
936
1,006
2,192
905
236
5,372,211

335

ネットワーク管理

コネクション数
海外から国内 国内から海外

2,294,206
415,581
161,387
225,562
129,486
183,130
153,080
131,604
49,597
104,615
34,48367,861
37,27663,552
53,847
46,162
43,90543,86741,93828,89425,18825,22917,147
9,358
6,882
5,086
5,104
3,637
3,287
2,541
1,296
2,487
68
4,417,343

表 2.10: FTP トラフィック

1,092
382
17
152
43
159
91
98
11
76
12
39
25
47
42
41
43
23
37
20
20
25
9
6
4
8
8
4
4
2
2
1
0
2,543

2,181
267
271
99
89
14
56
43
84
28
51
36
38
6
20
4
10
1
4
1
2
0
0
10
0
1
1
0
0
1
7
0
2
3,327

336

1991 年度

ド メイン

edu
com
org
gov
net
de
fr
au
ca
mil
uk
dk
il
se
ch
at
it
nz
no
hk
br
nl
sg
mx
us
gr
es
kr
ie
pl
be
合計

WIDE 報告書

バイト 数
海外から国内 国内から海外

844,769,610
158,639,413
136,345,557
53,595,550
71,355,544
33,830,493
20,701,781
11,416,664
13,197,590
16,049,449
2,325,839
1,011,020
09,227,302
2,516,179
1,906,889
0
8,810
448
98,142
038,198288,011
0
316
0
4,224
129,643
2,615
0
7,844
0
1,377,467,131

193,374,712
33,370,384
5,354,684
21,280,459
3,409,280
14,974,922
20,899,762
19,197,477
16,803,173
5,693,688
11,549,226
12,549,906
12,658,232
1,969,278
2,055,505
1,754,727
2,825,456
2,799,327
2,212,790
1,658,061
1,563,644
1,516,540
1,113,722
861,311
817,853
743,206
541,581296,647
394,364
69,6774,414
3,059
394,317,067

コネクション数
海外から国内 国内から海外

14,677
1,651
555
984
2,182
848
128
326
252
241
106
31
0
154
296
40
1
4
4
25
0
22
35
0
2
0
9
4
7
0
8
0
22,592

表 2.11: FTP-DATA トラフィック量

7,588
1,534
37
450
108
803
474
481
643
88
659
180
84
234
62
165
213
281
19
110
82
37
220
16
3
25
100
14
134
15
3
15
14,877

第 8部

337

ネットワーク管理

ン数と日本から海外へのコネクション数の比とおおよそ等しい値になっている。
多くの FTP サーバーでは、"anonymous" FTP をサポートしている点に注目してほしい。この "anonymous" FTP のセッションでは 、まず FTP-Control のコネクションがサーバーに対して張られ、ついで、いくつかの FTP-Data コネクションを介して比較的大量のデータが送られる。
ある種の情報やソフトウェアの配送という点から考えると、それらをもつサーバーがいかに広く知られているかということが重要になる。表-2.12は国内と海外の FTP サー
バーを、FTP-Control コネクションを受け付けた数の順にならべ、その上位５つずつをまとめたものである。国内の上位５つのサーバーは合計で 1,290 の FTP-Control コ
ネクションを海外の 893 個のホストから受け付け、それらのホストに対して 237,548,327
バイトのデータを FTP-Data コネクションにより転送した。これら 893 のホストは、実に 31 の異なる最上位ド メインに属していた。また、海外の上位５つのサーバーは、国内からの 208 個の異なるホストから合計 573 の FTP-Control コネクションを受け付け、
377,447,509 バイトのデータを FTP-Data コネクションにより転送した。

FTP サーバー

国内
海外

サービスの
要求数

クライアントホスト の数

転送された
データ量（バイト 数）

1,290
573

893
208

237,548,327
377,447,509

表 2.12: 国内、海外の上位５ FTP サーバー
この表には上位５つずつしか挙げていないが 、実際には 、海外から、国内の 151ヶ所のサーバーにサービス要求（ FTP-Control コネクション ）があり、国内からは海外の627ヶ所のサーバーにサービス要求があった。表-2.11から考えると国内の上位５つのサーバーで、海外に対するデータ転送全体の 60%を行っており、海外の上位５つのさーばで、日本へのデータ転送の 27%を行っていることがわかる。これらのサーバーにより転送されたデータ量は、71%の 27%なので全体の 19%である。したがって、仮にこれらの海外の上位５つのサーバーのコピーが国内に用意されていたならば 、海外から国内へのトラ
フィック量を、実際の 81%まで減らすことができるだろう。同様に考えると、国内から海外へのトラフィック量も 46%減少させることが可能である。もちろん、実際にはこれほど単純ではなく、情報やソフトウェアの分配経路を最適に設定するような手法を考案しなければならないだろう。
[?] によると、FTP によるファイルの転送は、かなりの割合で重複している。すなわち、特定のファイルが何度も FTP により転送されることが多いということである。仮に、われわれの国際専用線を利用する、FTP によるファイル転送にもこれが当てはまるとすると、上に挙げたように、単純に、よく利用される FTP サーバーのコピーをそのままつく
るのではなく、頻繁にアクセスされるようなファイルを選んで国内の FTP サーバー上に配置することにより、比較的低速で、しかしコストのかかる国際専用線をより効率的に338

1991 年度

WIDE 報告書

利用することができるであろう。実際このようなことは国内の主要な FTP サーバーでは行われていることであるが、それでも、国内で入手可能なデータやファイルを海外までとりにいく場合が多いことが予想される。最近国内でも開始された archie のようなサービスが今後広まるにつれて、このような状況がど う改善されて行くかは興味深いところである。
国内でのソフトウェアの再分配の試みとして 、昨年秋に X11R5 がリリースされた際に、上述のような方法を採用した。すなわち、事前に MIT と打ち合わせて、あらかじめ
X11R5 のリリースキットを国内のいくつかのサーバーに用意し 、さらにその旨を事前に国内で広報した上で、世界中で同時に公開を行った。
公開後１週間、国際専用線上の FTP-Data のトラフィックを監視した結果、海外のサーバーからの X11R5 の転送は、わずか１ホストが行ったのみであった。それに対して、国内のいくつかのサーバーの FTP の記録から 、同じ 期間に 36 の国内のホストがX11R5 の転送を行っていたことがわかった。ただし 、国際専用線上のトラフィックに関しては、FTP-Data により転送されたファイル名を監視していたわけではなく、かわりに各 FTP-Data コネクションにより転送されるデータ量のみの監視を行った。この手法はファイル名を監視するよりも大ざっぱなやり方ではあるが、X11R5 を公開している特定のサーバーからの、いくつもの 524,288 バイトのデータ転送はほぼまちがいなく X11R5の転送と断定できる。
もし前もってこのような準備をしていなければ 、国内のサーバーから転送を行った 36のホストのいくつかは、海外のサーバーに対して FTP の要求を行ったであろう。
ここで注意しなければならないのは、X11R5 を FTP するのは、ほとんどの場合が各組織の管理者であると考えられる点である。一般のユーザーに比べて管理者は国内のサーバーからも X11R5 が公開されるというような情報に注意を傾けているので、このような試みは成功する可能性が高い。しかし 、一般ユーザーが興味を持つようなデータやソフ
トウェアを効率よく分配するためには、自分がどのサーバーから FTP をするのかを気にすることなく、最適なサーバーを選択できるような機構が必要であろう。
ソフトウェアの分配に関しては、FTP 以外のプロトコルも用いられていることも考慮
しなければならない。例えば、USENET ニュースの comp.sources.unix のようなニュース
グループに記事として投稿されたソースコードは同時にどこかの"anonymous" FTP サー
バー上にも置かれることが多い。したがって、同じソフトウェアが、異なるプロトコルのデータとして、重複して国際専用線上を転送されてことになる。理想的には、特定のソフトウェアに関するデータ転送は１度だけ国際専用線上で行われ、その後国内で分配される際には、必要に応じていくつかのプロトコルデータに変換されるべきである。

第 8部

2.6

ネットワーク管理

339

まとめと今後の課題

本章では、日本と他の国々との間の TCP 上のサービストラフィックの特徴について調査した。ここで示した調査結果は、われわれが国際トラフィックの特徴に対して抱いていた予測のうちあるものを裏付け、またあるものを修正するために役立った。しかし 、ここで示した解析は国際トラフィックの特徴を知るために必要な解析のほんの一部にすぎない。今後はより統計的な手法を用いて、トラフィックをさまざまな側面からとらえ解析
していくことが必要である。そうすることによりはじめて、細かなトラフィックの特徴をとらえることができ、それに基づいた今後のネットワークの設計が可能となる。
今後の課題としては、

 長期的なデータ収集
 統計的な手法を用いた解析手法の考察
 他国の統計データとの比較が挙げられる。

第 3章
NSFNET バックボーンにおけるト ラフィック情報の統計収集について
3.1

はじめに

現在、NSFNET 1 バックボーンは T1 と T32の 2 種類の回線を用いたバックボーンから構成されており、1988 年 7 月より Merit Inc. によって運営、管理されている。このNSFNET バックボーンのトラフィックに関する統計データがネットワーク管理の一環として Merit Inc. により収集されており、統計データの一部は毎月集計され、一般にも公開されている。

一方、現在、WIDE バックボーンのトラフィックの統計情報を定常的に収集、解析していくための準備が進められており、一部の バックボーンリンク (1参照) や、国際リンク(2参照) のトラフィックデータの収集、解析を試験的に行なっている。
WIDE Statistics Working Group では今後の定常的なバックボーントラフィックの統計
情報収集とその公開を行っていく指針としていくために、NSFNET のバックボーンでの統計情報収集と公開されている統計情報の内容についての調査を行なった。本章では、まず NSFNET バックボーンで収集されているデータの種類と収集方法について述べ、次に、現在定期的に公開されている NSFNET のトラフィックの統計情報の内容について述る。最後に WIDE Statistics Working Group の今後の方針について述べる3 。

3.2

NSFNET のト ラフィック調査について

NSFNET は 14 の NSS(Nodal Switching Subsystem) を持つ T1 リンクを用いたネット
ワークと、16 の NSS を持つ T3 によるネットワークの 2 種類のバックボーンネットワー
クから構成されている。現在、Meritl Inc. によりそれぞれのトラフィックの統計情報の収集が行われている。

NSF:National Science Foundation
T1 と T3 は、それぞれ 1.544Mbps と 45Mbps の容量の回線である
ここでは NSF によって 毎月公開されている統計資料と、NSFNET のトラフィック情報収集の状況について、SDSC(San Diego Supercomputer Center) のメンバーが我々に対して個人的にコメントした内容に基づいて述べる。それは NSF や Merit から正式に出されたコメントではない。
1
2
3

340

第 8部

ネットワーク管理341

NSFNET では、大きく分けて次の 3 種類の、トラフィックに関する統計値が収集されている。

1. バックボーンノード 間の遅延
2. バックボーンノードのインターフェースにおける処理量
3. パケットの種類
以下それぞれについて順に述べる。

3.2.1

ノード 間の遅延

ノード 間の遅延は、NSFNET バックボーンの各ノード 間の round-trip times (RTT) を、
ICMP Echo (ping) を用いて測定されている。具体的には、バックボーンの各 NSS の外部インターフェース間で 15 分ごとに測定する。測定されたデータは、各ノード 上に一時的に置かれ、一日ごとにまとめられ NOC のデータ収集所に転送される。
この 15 分ごとのサンプル値から、その月の平均のノード 間遅延を計算し 、その値の半分の値が片道の遅延とされる。これより 14 14 のノード 間の遅延のマトリックスがで
きる。

2

3.2.2

インターフェースの処理量

バックボーンノード の各インターフェースでの処理量の統計データが SNMP[?] を用いて収集されている。具体的なデータの内容としては、

 インターフェースが受けとった、または送ったパケット数
 インターフェースが受けとった、または送ったバイト数
 インターフェースが受けとったエラーパケット数
これらの値は、各インターフェースの、パケット数、バイト数、エラーパケット数を累積する SNMP のカウンターの値を 15 分ごとに測定することによって得られる。また、これらの得られたデータから "1 日にバックボーンに流入したパケット数" などを計算している。この値はバックボーンの 1 日の負荷として捉えることができる。さらに、1 時間ごとのバックボーンの負荷や 利用度を求め、一日のうちでバックボーンの混雑している、または空いている時間帯を得ることも可能である。
NSFNET の NSS では 、比較的完全な SNMP の MIB[?] により、曖昧さの少ない値を得ることができる。しかし 、それ以外にも様々なネットワークの性能に関係する情報が必要である。MIB から得られる処理したパケット数やバイト数のようなインターフェースに関するカウンターの値を、それ以外の情報とともにネットワーク管理システムに入342

1991 年度

WIDE 報告書

力することにより、ネットワークの性能監視、ボトルネックの発見、そして最終的には、
ネットワークの最適化を行なうことができると考えられる。
また、パケット交換のネットワークでは、瞬間的にパケットが増加する性質がある。しかし 、この測定では 15 分ごとに値を測定しているため、このような突発的なトラフィッ
クを観測することはできず、ネットワークトラフィックのおおまかな特徴となっている。

3.2.3 NNStat によるパケット の分類
NSFNET のゲートウェイである各 NSS は、PSP(Packet Switching Processors) と呼ばれる専用回線を収容するノード を IEEE 802.5 トークンリングによって相互接続した構成となっている。また、このトークンリングのバスを通るパケットのヘッダを調べる専用のプロセッサを持っている。これにより、インターネット統計収集用パッケージである NNStat を、このプロセッサ上で動作させて、NSS 全体のパフォーマンスを落とさずに NSS を通る全てのパケットの統計情報を得ることができる。例としては、IP レイヤの上位レイヤにあたるトランスポートプロトコルレイヤの種類によってパケットを分類し 、それぞれの頻度の分布を求めることができる。現在は、パケット数を以下のように分類して統計を出すことができる。

 ネットワークのソース：デスティネーション のマトリックス
 パケット長のヒストグラム
 IP でのプロトコル別の頻度分布
 TCP/UDP のポートごと (つまりアプリケーションごと) の分布
 NSS を通過するパケットの数
 1 秒で到着するパケットの数のヒストグラム
これらの情報の処理の流れとしては 、まず、上に挙げたような NNStat から得られる
トラフィックの統計データを、1ヶ月ごとの、\ソースネットワーク：デスティネーション
ネットワーク" のマトリックスの形で分類し 、アプリケーションごとのパケット数の分布を出す。また、ソースネットワーク、デスティネーションネットワークのマトリックスの形のデータから、1 時間ごとの NSS 対 NSS のトラフィックのマトリックスも作成される。
このマトリックスやバックボーンのルーティング情報やパケット長の分布などのデータなどは、NSFNET のネットワークトポロジを改善するためのソフトウェアや、その他の性能分析ツールの入力データとして用いられる。これらの数値は NSF への月例報告には含まれないが、時折公開されており、ネットワークの設計や最適化にも用いられている。
ここでパケット数だけでなくバイト数での測定を行っているのは、アプリケーション
によって 1 パケットのバイト数に違いがあるためである。つまり、平均のパケットサイズは 125 バイトから 175 バイトになるが、実際のパケットサイズの分布としては 41 バイ

第 8部

ネットワーク管理343

ト (Telnet の典型的なパケットサイズ) と 576 バイト (フラグメントされたパケットのサイズ) の 2 つのピークがある。
また、これらの統計情報を、特別な目的のために用いることも可能である。例えば 、

 スーパーコンピュータへのネットワークアクセスとネットワークの利用度の相関関係
 DNS のトラフィックの監視のような項目が挙げられる。

3.3

公開されている NSFNET の統計情報

これまでに述べたようにして収集された情報をもとにして、毎月、NSFNET の統計情報のレポートが作成され一般に公開されている。これまでに述べたように、統計収集のためのツールとしては、ping 、SNMP 、NNStat が用いられている。
統計情報のファイル名は、"tN-YYMM.TYPE" で表され、それは以下のような内容の
データのファイルであることを示している。
tN ネットワーク名(t1 または t3)

YYMM 年と月
TYPE そのファイルの統計情報のタイプ。以下の7 つのタイプがある。

1. delay
NSFNET バックボーンの各ノード 間での片道の遅延の分布の四分位数(1991 年 6 月より前については、最少と最大と平均値となっている)
2. pnss
NSFNET バックボーンの各 NSS へ入ってくる一日ごとのパケット数
3. bnss
NSFNET バックボーンの各 NSS へ入ってくる一日ごとのバイト数
4. pnets
NSFNET バックボーンを通って一ヶ月間に各ネットワークへ出入りするパケッ
ト数と、それぞれの全体に対する割合

5. bnets
NSFNET バックボーンを通って一ヶ月間に各ネットワークへ出入りするバイト数と、それぞれの全体に対する割合

6. country
NSFNET バックボーンを一ヶ月に通るトラフィックの国ごとのパケット数とバ
イト数

344

1991 年度

WIDE 報告書

7. ports
NSFNET バックボーンを一ヶ月に通るトラフィックのサーヴィスごとのパケッ
ト数とバイト数
ただし T3 ネットワークは、pnss 、bnss の統計情報のみとなっている。
例えば 、"t1-9202.pnss" は、1992 年 2 月の NSFNET の T1 バックボーンの各 NSS に入ってきた一日ごとのトラフィックをパケット数で測定した統計情報である。
各タイプごとの統計情報について、次に詳しく述べる。

3.3.1 delay
T1 によって構成されるネットワークには 14 のノードがあり、それら各々のノード 相互の RTT を ICMP Echo を用いて 15 分ごとに測定している。それらの値からその月の平均のノード 間遅延を計算し 、その半分の値をノード 間の片道の遅延 (単位はミリ秒：1/1000sec) とする。この遅延の値の四分位数のそれぞれを、NSS の測定元ノードと測定先ノー
ド の番号による 14 2 14 のマトリックスで表している。
例として、ある月の遅延の四分位値のうち、中央値のマトリックスのデータを示す。

NSFNET T1 Delay Matrix Report for March 1992
2nd Quartile Results
From/To 5 6 7 8 9 10 11 12 13 14 15 16
5
68 57 24 33 18 41 21 64 51 62 42
668
60 69 57 75 27 52 18 22 46 83
757 61
76 67 65 37 41 50 62 19 31
8
26 72 76
17 41 47 44 84 74 53 67
935 59 67 17 23 35 53 71 75 78 90 35
10
18 75 69 40 21
51 37 78 68 46 58
11
41 28 36 45 34 51
70 40 44 48 60
12
21 51 41 42 52 37 70
48 35 52 25
13
66 20 49 86 72 81 41 50
20 35 7214
51 22 61 72 73 66 44 35 1846 54
1567 46 18 51 76 46 48 52 34 4641
16
42 83 29 66 87 59 59 24 71 53 41
17
41 77 50 26 35 20 65 58 65 78 34 72
18
22 44 54 44 51 38 22 41 57 62 66 62

17
34
76
49
25
52
18
63
51
69
76
33
70
54

18
23
45
55
46
37
22
41
59
62
66
62
59

3.3.2 pnss
NSF バックボーンの各 NSS に入ってくる一日ごとのパケット数。表の行は各バックボーンの名前、列は日付となっている。例として、ある月の pnss のデータのうち、数日間の第 8部

ネットワーク管理

345

一部のノードについてのデータを示す。

Day Argonne
139608923409623391235::
Total 12710280

T3 ネットワークについて
1992 年 3 月
Ann Arbor Pittsburgh
Ithaca SaltLake
BostonTotals7295770 23159392 13447394 164728 25274446 143632451
9915600 22230673 15025353 166018 32276964 179380068
11792739 18830275 30603420 181101 34864760 193332673
:
:
:
:
:
:
513261990 623284522 527880792 5540142 950054040 5181572520

3.3.3 bnss
NSFNET バックボーンの各 NSS へ入ってくる一日ごとのバイト数。前に示した pnssの表と同じ形になるが、パケット数のかわりにバイト数で測定されたものである。

3.3.4 pnets
NSFNET バックボーンを通って各ネットワークへ出入りするパケット数の一ヶ月の合計と、それぞれのネットワークへのトラフィックが全体に対して占める割合。
例として、ある月の一部のデータを次に示す。

NSFNET T1 Backbone Trac Distribution by Internet Network Number
1992 年 3 月
合計パケット数 : 8,924,601,550
合計バイト数 : 1,641,789,183,650
ネットワーク数 : 4,081
Pakets In
Pacets Out percentages
AS IP Number Network Name To Backbone From Backbone In Out
93 128.252
WASHINGTON-U 454,616,050
285,914,100 5.09 3.20
73 128.95
WASHINGTON
180,063,650
174,600,600 2.02 1.96
267 129.79
INDIANA-NET
176,642,950
147,513,700 1.98 1.65
280 128.83
UTAUSTIN
165,339,000
121,767,600 1.85 1.36
1206 128.2
CMU-NET
129,292,850
125,317,350 1.45 1.40
97 128.112
PRINCETON
127,563,550
87,025,150 1.43 0.98
702 137.39
UUNET-WAN
126,827,950
99,063,300 1.42 1.11
97 128.6
RUTGERS
123,854,650
90,427,050 1.39 1.01
200 36
SU-NET-TEMP
120,476,200
82,081,500 1.35 0.92
194 128.117
UCAR
112,069,550
88,852,850 1.26 1.00
38 128.174
UIUC-CAMPUS-B 111,980,100
92,672,600 1.25 1.04
200 128.32
UCB-ETHER
104,303,350
95,460,900 1.17 1.07

346

3.3.5

1991 年度

WIDE 報告書

bnets

NSFNET バックボーンを通って各ネットワークへ出入りする一ヶ月のトラフィックを
バイト数で測定した値と、それぞれのネットワークへのトラフィックが全体に対して占める割合。前に示した pnet の表と同じ形になるが、パケット数のかわりにバイト数で測定されたものである。

第 8部

ネットワーク管理

347

3.3.6 country
NSFNET バックボーンを通るトラフィックの国ごとのパケット数とバイト数。例としてある月のデータのうち、上位の数ヶ国分について次に示す。

Nets
2302
191
115
112
43
19
199
179
17
99
28
6

NSFNET T1 Backbone Trac Distribution by Country
1992 年 3 月
合計パケット数 : 8,924,601,550
合計バイト数 : 1,641,789,183,650
ネットワーク数 : 4,081
国: 40
Pakets In
Pacets Out
percentages
Country
To Backbone From Backbone In Out
United States
7,616,219,250 7,215,056,700 85.34 80.84
Canada418,331,150
409,150,850 4.69 4.58
Australia
167,352,000
119,721,800 1.88 1.34
United Kingdom 148,937,800
144,996,700 1.67 1.62
Sweden109,535,200
169,940,600 1.23 1.90
Finland66,603,600
79,164,650 0.75 0.89
Germany
51,130,100
107,819,300 0.57 1.21
France49,232,500
91,608,600 0.55 1.03
Norway49,229,350
70,160,450 0.55 0.79
Japan
40,073,450
26,898,200 0.45 0.30
Taiwan31,896,400
33,473,850 0.36 0.38
Denmark
30,470,700
28,843,750 0.34 0.32

3.3.7 ports
NSFNET バックボーンを通過するトラフィックのサーヴィスごとのパケット数とバイト数。現在、データがあまりにも多いため、サンプリングして解析する方法を取っており、完全に正しいデータであるとは言えないが、サンプリングによる影響は本当に僅かである。表はパケットの多いサーヴィス順になっている。
例として、ある月のデータのうち上位のいくつかのサーヴィスのデータを示す。

NSFNET T1 Backbone Trac Distribution by Service
合計パケット数: 8,924,601,550
合計バイト数: 1,641,789,183,650

348

1991 年度

Service Name
ftp-data(other ports)
telnetnntp
smtp
nameserver
ftp(other protocols)
vmnet
irc
who/loginntp(unknown)
X0
syslog/cmd

WIDE 報告書

Port Packets Count % Pkts
20 2,345,582,650 26.282| 1,819,683,100 20.390
23 1,109,624,000 12.433
119930,703,700 10.429
25779,172,450 8.731
53
616,370,700 6.906
21
210,861,050 2.363|
187,167,800 2.097
175
179,897,400 2.016
6667
124,715,150 1.397
513
80,673,900 0.904
123
66,563,250 0.746
1023
64,405,950 0.722
6000
47,513,250 0.532
514
39,135,050 0.439

Byte Count
828,850,604,950
171,983,064,750
78,901,539,450
178,094,436,150
118,713,376,000
62,653,762,550
15,199,203,900
15,913,880,450
65,039,534,550
10,249,531,050
3,478,657,300
5,078,830,450
9,733,875,200
7,010,593,600
16,412,937,450% Byts50.48510.4754.806
10.848
7.231
3.816
0.926
0.969
3.962
0.624
0.212
0.309
0.593
0.427
1.000

3.3.8 WIDE インターネット におけるト ラフィック調査について
WIDE インターネットにおいても、これまでに述べたようなバックボーンのトラフィッ
ク調査と定期的なレポート作成が必要である。
具体的には、WIDE インターネットで必要とされるトラフィック統計データは、以下の3 つに分けられる。

 WIDE バックボーンノード 間のトラフィック
 WIDE と日本国内の他のネットワーク間とのトラフィック
 国際リンクとのトラフィック
まず、1 番目のバックボーンノード 間のトラフィックについては、本章で述べた NSF で行われている方法を参考として、同様の測定を行っていく予定である。 これは、バック
ボーンの性能管理、構成管理などに必要とされる。
2 番目の日本国内の他のネットワークとの間のトラフィックについては、現在 1 章で述べたような方法で測定を始めている。
3 番目の項目については、前章で述べたように tcpdump を用いて収集が始められている。また、特に国際リンクのトラフィックデータの収集では、収集するデータの形式について他国との協調が求められてきており、現在そのための話し合いが進められている。
また、統計データの量は非常に大きくなるため、収集するデータの内容とその保存方法については、検討が必要である。収集されたデータの解析から得られる国際リンクのト
ラフィックの状況によっては、国際リンクの構成を再検討することも可能である。

第 8部

ネットワーク管理349

これらのデータを定期的にレポートとしてまとめ、一般に公開していく予定である。さらに、特別な目的のためにもっと詳しい情報が必要とされる場合には、すぐにそれに対応できるような統計情報収集のための環境も実現していく予定である。

第 4章
WIDE Network Management Workshop'92 報告4.1

はじめにWIDE Network Management Workshop '92 は WIDE プロジェクトが初めて主催した
ワークショップである．このワークショップは，

 ネットワーク・マネージメントとは何か?
 実際のネットワーク・マネージメントはどのように行われているのか?
 ネットワーク・マネージメント・システムは何を対象としてどのようなマネージメ
ントができるのか?

ということを興味の主眼として開催された．
WIDE Network Management Workshop '92

日時: 1992 年 3 月 27 日
場所: 大阪大学基礎工学部Σホール
主催: WIDE Project
共催: 日本 UNIX ユーザ会 (JUS), 情報処理学会
プログラム:

司会: 山口英中村修

Session 1: モデル

SNMP と CMOT

司会: 大野浩之
菊地宏臣

Session 2: 開発(製品紹介)

350

大阪大学
東京大学
東京工業大学
日本サン・マイクロシステムズ (株)

第 8部

351

ネットワーク管理(製品紹介)

長沼義一(製品紹介)

長福真一(製品紹介)

泉谷建司(製品紹介)
OSI 管理に基づく LAN 管理システムの開発
SNMP の今後

古郡正美
吉江信夫
秋山欣也

横河ヒューレット
パッカード (株)横河ディジタルコンピュータ (株)日本ディジタル
イクイップ メント (株)ソニー (株)
住友電気工業 (株)日本電気 (株)Session 3: 運用技術

司会: 三膳孝通

東京工業大学

松下電器のコンピュータネットワークの概要
企業におけるネットワークの導入と運用管理

加藤朗
山口英
今津英世
徳川義崇

慶應義塾大学
大阪大学
松下電器産業 (株)(株) ディアィティ

Session 4: 将来のネットワーク管理

司会: 中村修

東京大学

中村眞
工藤丈一
加藤朗
佐野晋
山口英

シャープ (株)(株) アスキー慶應義塾大学
日本電気 (株)大阪大学

WIDE におけるネットワーク管理−なぜ SNMP は使えないか−
Campus Networking と管理

パネルディスカッション
パネリスト

当日は大手私鉄のストライキのため，時間を 30 分繰り下げてワークショップが開始された．参加者は 100 名弱でほぼ予定通りの人数となった．
セッションの間の休憩時間には共催の JUS から菓子パンとミネラル・ウォータの差入れがあり，休憩時間にも菓子パンをはさんで盛んな意見交換が行われていた．

4.2

各セッションの内容

Session 1:モデル
ネットワーク管理のモデルとして，OSI のネットワーク管理モデルがあり，実際にはすでに広く利用され始めている SNMP および MIB，OSI のネットワーク管理を IP の世界に導入した CMOT がある．そして，Internet におけるネットワーク管理の実際の Topic
として，広域に広がったネットワーク管理，課金や認証，その中でどのような管理を行うかが重要になる．

352

1991 年度

WIDE 報告書

Session 2:開発
本ワークショップの特徴の 1 つがこのセッションである．現在市販されているネットワー
ク管理システムの紹介と今後の方向についての発表が行われた．いずれの製品も SNMPを用いて管理を行うものとなっている．ネットワーク管理システムを特色づけるものとしては，ネットワーク構成の記述，システムのカスタマイズ，さらにアプリケーションとのインタフェースである．製品となっている管理システムはそれぞれに趣向を凝らしたものであり，さらに外見にも気配りがなされている．
製品紹介
Sun NetManager

Sun NetManger はネットワーク管理のためのプラットフォームがコンセプトであり，
インタフェースを公開することでネットワーク管理を行うユーザが必要な機能を利用してシステムを構築する．

HP OverView

HP OverView の最大の特徴はネットワーク構成を自動的に作成する Auto Discoveryの機能である．この機能はノードを順に発見して行く機能である．
YDC LMaT

LMaT は管理者として初心者用として，Easy Setup, Easy Use のシステムを目指したものである．
DECmcc ディレクタ/DECmccMSU

分散処理指向の管理システムであり，OSI を指向したシステムである．SNMP も OSI
管理の一部として位置づけたものである．

第 8部

ネットワーク管理

353

SONY NewsOS

SONY NEWS には OS に標準的に SNMP を扱う管理ツールが用意されている．あくまでも管理に用いるツールである．

OSI 管理に基づく LAN 管理システムの開発

OSI 管理モデルに基づいており，OSI ネットワークの管理を行うシステムである．

SNMP の今後

MIB の現状と今後の拡張の方向についての紹介．今後の拡張方向としては，多様な機種ヘの対応，マルチプロトコル化，セキュリティの強化，さらに障害管理の強化としてTrap の充実がある．SNMP の特徴は何でも管理できるということである．

この発表に対しては会場からの質問として SNMP で何もかもやることに関して，また現実的に全てが可能かど うかという疑問が出されていた．これにはネットワーク管理には何が必要かを考える必要があるとのコメントが出された．

Sessiong 3: 運用技術
WIDE におけるネットワーク管理

WIDE Internet の管理の実態についての報告．WIDE Internet は 専任管理者がおらず，ユーザが管理者を兼ねている．Internet の運用上はトラブルよりも停電などの事態が多い．またほとんど正常に見えてていても部分的に異常が発生しているときもある．またネットワークが複雑になるにつれて問題の原因を知ることも困難である．このようなネットワークを管理するためには管理者に近い Intelligence を持ち，何が正常であるかを判断し，異常時に警告を出すようなシステムが必要である．このような面で明示的な構造を持たず，また polling をする必要がある SNMP は管理には使えない．
campus networking と管理

大阪大学を例としたキャンパスネットワークの管理についての報告．阪大のネットワー
クは，まだ発展途上であり，今後新たなネットワークが接続されてくる．キャンパス・ネッ
トワークにおける最大の困難は優秀な人材が次々に移動することであり，このような環境で実験から運用への移行をしなければならないという問題がある．
松下電器のコンピュータネット ワークの概要

松下電器のネットワーク管理の体制はデータリンク以下の層は mail/news を使っていない EDP 部門が管理している．ユーザはメイルが 4,000 名, ニュース 3,000 名である．会
社的には運用業務の評価は行われており，課長クラス以下では便利になったという意識がを持っている．
企業におけるネット ワークの導入と運用管理
ディアイティにおけるネットワークの発展と構築．問題となるのはやはり管理者が足りないことであり，台数が少ない間は 1 人でも管理できるが，台数が増えるにつれて作業が増えすぎる．それでも管理は 1 人に集中する．ある程度の規模を越えると，管理に必
要なコミニュケーションの手段としての mail/news が必須になる．

354

1991 年度

WIDE 報告書

Sessiong 4: 将来のネットワーク管理
このセッションではそれまでのと議論を踏まえた上で，発表将来のネットワーク管理というテーマで，いくつかのトピックについて議論を行った．

ネット ワーク管理システム
各社のネットワーク管理システムのコンセプトや，対象とするユーザについの補足．
Sun NetManager

Sun NetManager は使う人がそれぞれの立場で各自の管理システムを構築するためのプラットホームである．管理システムとして要求されている市場が未知であるのに完成したシステムを提供するのは困難である．この点プラットホームではアプリ
ケーションは 1 種類ではないため，各々の目的，規模またレベルに合わせることができる．すべてに合わせたプロダクトを出す予定はない．
質問: 1000 台ぐらいのキャンパスネットワークで管理できるか?

回答: システム全体は無理であり，階層構造をとって範囲を定めて管理を行うことなら可能である．
HP OpenView

HP OpenView はキャンパスネットワークレベルを対象として，MAX 2000 ノード程度まで管理できる．管理項目は監視，障害の発見と回復，および解析である．

YDC LMaT

対象とする規模はこれまでの実績は最大で 44 セグメント 500 ノード 程度である．対第 8部

ネットワーク管理355

象とするユーザはネットワークに関しては比較的初心者であり，明日からでも使えるシステムを目指している．
DEC MSU

ネットワーク管理業務のサービスための専用システムで，技術的にしっかりした冷
静な管理者を対象としており，いわばプロフェッショナルユースを目指している．
会場からのコメント : 実際に管理システムの使用経験から言うと使うのは楽しいが実際に管理するのは苦しい．

 業務の報告やレポートの作成には利用できる可能性がある．
パネリストのコメント : プロが管理するのに利用するために軽くて端末で利用できるものが必要である．
 グラフィカルユーザインタフェースは格好がよいが本当に必要かどうかはわからない．
 自分のツールとすることは難しく使いものになりにくい．
 presentation には使える．
 スタッフに技術移転をするためには見てくれが大切．
 市販のネットワーク管理システムは，プロの管理者には使いにくいが，必要とされる場合もある．

 プロ向けに本当に使えるシステムは必要である．
 ネットワークは場所により大きく異なるので汎用システムは有り得ず，本当当に使えるものは受注ソフトになってしまう．

 一つのやり方として管理者の知識を記述する枠組みを用意して，その上で知識を与えてゆくという方法がある．
SNMP の可能性

 インタフェースの情報だけでは無理であり，パケットそのものを見たい．
 SNMP でどこまで管理するかを考えて新たな MIB を作ればよい．
 MIB でなにもかもやるのは疑問．
 破綻するまでやってみるのも一つの方法．

356

1991 年度

WIDE 報告書

ネット ワーク管理のあり方

 現在は今はエンジニアがすべてをやっているが，今後はエンジニアではない運用管理スタッフが必要で，そのためにはツールの色分けも必要になる．

 これは企業としては通る話であるが，大学では不可能かもしれない．大学もプロのサポートやサービスを買えるようにするか，あるいは大学として人材を確保し続けなければならないのか．大学では本当は研究をしたい．

 キャンパスネットワークの環境は何でも知っていないとだめであるため，お金を払っても環境を買えないし，発注できない．

 大学に身も心も捧げた会社を作り，保守費を払ってサービスを買いたい人たちは買う．しかし，作ることが楽しい人たちは WIDE とか JAIN で楽しみながらやる．

 US では berkeley, merit のような会社組織が管理を行っているが，日本でも第 3 セ
クターでの管理組織が可能ではないか．

 しかし，これには研究費の半分を払う覚悟が必要であり，また体制として学生を雇うことを考えねばならないが，それが可能なのか．
参加者の比率約 90 名の参加者の中の割合．
実際のネットワーク管理者
ネットワーク管理の研究者
ツールの開発者
ネットワーク管理が商売

80%
20 名
7名
6名

ネット ワーク管理ツールに最低限必要な機能

 自分のプログラムに組み込み，トラブルがあったときになるべく早く解決するための助けとなるシステム．

 トラブルのときに診断し，障害の切りわけをするシステム．
 予算のとれるシステム．
 バックグランドでやりながら，重要障害が発生したとにだけそのレポートを画面の一部に表示する．

 ネットワークの管理は生きたものであるから設計に役立つツール．
 主治医としてのネットワーク管理者を総合的に管理するシステム．
 ユーザのアクティビティを監視して，どこで何をやったかを記録する．
 管理者の協調作業を支援するシステム．

第 8部

4.3

ネットワーク管理

357

おわりに

今回のワークショップは研究の面からも，実務の面からも非常に意義のある会合であった．ネットワーク管理に関する研究会はこれまでにも開催されているが，今回のワークショップがこれまでのものと大きく異なるのは，非常に現実的で実証的な側面に重きを置いた点である．Internet に接続されている様々なネットワークがどのように管理されているか，管理のために必要な道具立ては何かなどの実際の経験に基づいた問題，ネット
ワーク管理システムと言う名前を持つ製品の内容と実用性，ネットワーク管理の今後とSNMP の方向性などの問題を，参加者がそれぞれの背景を持って意見を交換する場として有効に作用した．
このワークショップは様々な視点を共通の土俵で議論するための先駆けであり，主催者の目的を達成した．この成功を受けて，今後も Netman Workshop は引続き開催される予定である．

358

1991 年度

WIDE 報告書