第 10 部
ネット ワークト ラフィック統計情報の収集
と解析

317

第

1章

はじめに
WIDE NetStat WG は、広域分散環境におけるトラフィックデータの「収集」、「解析」、「保存」、「利用」等のために必要とされる技術に関する研究をおこなうことを目的に活動を行っている。また、トラフィックデータの収集・解析によって得られた情報をネット
ワーク管理において利用する技術に関する研究も合わせて行っている。
これまで当
では、
上のトラフィックの統計情報の収集・解析を通して、バックボーンの利用状況を、その上を流れるトラフィックの観点から明らかにし 、また、の国際回線を通した国際的な通信の広がりについての考察を行ってきた。
本報告では、 年度の活動をもとに、

WIDE

WG

WIDE Internet

WIDE

92

 トラフィックデータの収集手法の解説
 WIDE バックボーン上のトラフィック解析
 TIX 等における、他のネットワークプロジェクトとの間のトラフィック解析 国外のネットワークとのトラフィック解析
 IETF で現在提案されている、トラフィックデータの共用を行うための、共通データ
フォーマットについての解説
を行う。

319

2章
NNStat による統計情報の収集について
第

2.1

概要

NNStat[93] は、南カリフォルニア大学の Robert Braden らにより開発された、インター
ネット上のトラフィックの統計情報を収拾するためのツールである。NNStat を用いる事
によって、インターネット上に分散した幾つかのイーサネットセグ メントやポイント・
トゥー・ポイントリンクを通過する トラフィックのさまざまな統計情報を同時に収集する事が可能となる。また、どのような統計情報を収集するかは、インタラクティブに、もしくはコンフィギュレーションファイルにより柔軟に指定する事が可能である。
は概念的には、との２つの部分から構成される。

IP

NNStatHost)

SAA (Statistics Aquisition Agent) SCH (Statistics Collection

SAA(Statistics Aquisition Agent) ネットワーク上に複数個分散配置され、各々配置

IPされた場所における トラフィックを監視し 、コンフィギュレーションファイルによる指定にしたがって、統計情報の収集を行う。
というプログラムがこの役割を果たす。

statspy

SCH(Statistics Collection Host) 分散配置された複数の SAA を定期的にポーリング

SAA

し 、各
において収集された統計情報を一箇所に集め、ファイルに格納する。
というプログラムがこの役割を果たす。

collect

2.1 SAASAA SCH

SCH

NNStatSNMPmanagement agent management station

図
に、
および
を用いた
による統計情報の収集の基本概念を示す。
上記
と
の関係は
における
と
の関係と概念的には同じものである。

320

第 10 部

ネットワークト ラフィック統計情報の収集と解析

321

SAA
トラフィックデータ

Net 4
SAA

G

トラフィックデータNet 4 の統計データ

Net 3 の統計データ

Net 3
SCH

G

統計データ
G:ルータ

Net 2 の統計データ

SAA

G

Net 1 の統計データ

G

SAA
トラフィックデータ

トラフィックデータ

Net 2

Net 1

図

2.1: NNStat による統計情報収集の概念図

2.2 statspy が収集可能な統計情報
SAA

各は、イーサネットセグメントもしくはポイント・トゥー・ポイントのリンクを通過する全てのパケットを検査し 、あらかじめ指定された各種条件に従って、トラフィッ
クを分類し 、統計値を計算する。

2.2.1

論理的フィールドIP

TCP および UDP

ここでの条件の指定では、イーサネットフレームヘッダ、 ヘッダ、
ヘッダの以下のフィールドに対して、条件式を指定することができる。

322

1992 年度 WIDE 報告書

フィールド 名 フィールド 長 (バイト 数)

Ether.src
Ether.dst
Ether.type
IP.version
IP.length
IP.option
IP.TOS
IP.o set
IP.protocol
IP.srchost
IP.dsthostIP.srcnet
IP.dstnet
IP.srcsubn
IP.dstsubn
TCP.srcport
TCP.dstport
UDP.srcport
UDP.dstport
ICMP.type
ICMP.code
packetlength意味

6 イーサネットアドレス
6 イーサネットアドレス
2 イーサネットタイプ
1 IP バージョン
2 IP データグラムのサイズ
1 IP オプション
1 TOS を表すビット列
2 フラグ メントされている場合のオフセット値
1 IP のプロトコル
4 送り手の IP アドレス
4 送り先の IP アドレス
4 送り手のネットワークアドレス
4 送り先のネットワークアドレス
4 送り手のサブネットワークアドレス
4 送り先のサブネットワークアドレス
4 送り手の TCP ポート番号
4 送り先の TCP ポート番号
4 送り手の UDP ポート番号
4 送り先の UDP ポート番号
1 ICMP の type フィールド
1 ICMP の code フィールド可変

パケット全体のビット列
パケットの全長
ただし 、上記の表の各フィールドは、必ずしも実際の データグラムのヘッダ中に存在するものばかりではなく、例えばのように、実際のヘッダ中のフィールドの値を用いて計算可能な物もふくむ、論理的なものと考える。

4

IP.srcnet

2.2.2

IP

オブジェクトNNStat では、データ構造としていくつかのオブジェクトを用意しており、統計情報の収集は上記の表に示した、各 IP データグラムから得られる論理的なフィールド 値を、それらのオブジェクトに代入する事により行う。

 Recorders1 1 1統計値を格納するためのオブジェクト。
{ freq-all

IP.srchost

与えられた１つのフィールド値に対する頻度情報を格納する。例えば、をこのオブジェクトに与えることにより、各送り手の アドレス毎のパケット数を数えることができる。

IP

第 10 部

323

ネットワークト ラフィック統計情報の収集と解析{ freq-all-bytes

freq-all と類似しているが、パケット数を数えるだけではなく、パケット長の累積値も同時に格納することができる。

{ matrix-all

IP.srchost
IP アド

与えられた２つのフィールド値に対する頻度情報を格納する。例えば、とをこのオブジェクトに与える事により、送り手と送り先のレスの組毎のパケット数を数える事ができる。

IP.dsthost{ matrix-all-bytes

matrix-all と類似しているが、パケット数を数えるだけではなく、パケット長の累積値も同時に格納する事ができる。

{ その他 ([94] を参照)

 Filters1 1 1条件を表すオブジェクトで、条件式の一部として記述する事ができる{ eqf
与えられたフィールド 値を指定された値と比較する。

{ setfeqf は setf の特別な与えられたフィールド 値を指定された一連の値と比較する。
場合と考える事ができる。

{ その他 ([94] を参照)

2.2.3

コンフィギュレーション言語

上記の論理フィールド、オブジェクトと 、以下に示す構文を加えたコンフィギュレー
ション言語を用いて、に対して収集する統計情報を指定する。
コンフィギュレーション言語で使用するおもな構文には以下のものがある。

statspy attach 構文1 1 1オブジェクトの定義文全体
 enum 構文1 1 1フィールド 値に特定の文字列を対応づける
例

enum {*port* (20 "FTP data", 21 FTP, 23 Telnet, 25 SMTP,
37 Time, 42 Name, 43 Whois, 53 Domains,
69 TFTP, 79 Finger, 103 X.400, 104 "X.400-SND",
109 POP2, 111 sunrpc, 115 SFTP, 119 NetNews,
153 SGMP, 512 exec, 513 "rwho|rlogin", 514 shell,
515 printer, 520 RIP)}

324

1992 年度 WIDE 報告書*port*

この例では、にマッチする名前をもつフィールドの値に対して、上記のよ
うな値と文字列との対応を定義する。例えば 、の値 を、という文字列によって指定可能にする。これは以下に述べる 構文や構文でフィールド 値に対する条件を指定する時に便利である。

TCP.dstportif

23

Telnetselect restrict 構文1 1 1簡単なアクセスコントロールを行う。
例 restrict readwrite 192.41.197.0 0x00
この例では、この statspy プロセスに対して、192.41.197.0 のネットワーク上のホストからの読み書きのアクセスを許すことを指定する。

 subnet 構文1 1 1IP.srcsubn や IP.dstsubn フィールドによって識別可能なサブネット
ワークを指定する。
例

subnet 133.160.0.0 0x

Be0

133.160.0.0

この例では 、クラス
ネットワークであるはサブネットマスク
によってサブネットされている事を指定する。
構文で指定しないかぎりやによって参照されるネットワークアドレス
は、やによって参照されるネットワークアドレスと同一で
ある。

0x

e0

IP.srcsubn IP.dstsubn
IP.srcnet IP.dstnet

subnet record 構文1 1 1recorders オブジェクトに対する値の代入を行う
例1

record IP.srchost in SOURCE-IP freq-all ;は、SOURCE-IP という名前の freq-all オブジェクトを定義し 、各 IP.srchost 毎のパケット数を記録する。

record IP.srcnet,IP.dstnet in MATRIX-IP matrix-all-bytes ;は 、オブジェクトタイプ matrix-all-bytes のオブジェクト MATRIX-IP を定義
し 、各 IP.srcnet と IP.dstnet の組毎のパケット数を記録する。

例2

 if 構文1 1 1C 言語等と同様の通常の条件分岐構文
 select 構文1 1 1C 言語等の switch 構文と類似した制御構造を与える構文例

select TCP.dstport selectSport {case ("Telnet", "Whois", "Finger", "rwho|rlogin"):record IP.srchost, IP.dsthost in Telnet.hosts matrix-all;case ("FTP data", "FTP", "TFTP"):
record IP.srchost IP.dsthost in ftp.hosts matrix-all;case ("SMTP", "X.400", "X.400-SND", "NetNews"):

第 10 部

ネットワークト ラフィック統計情報の収集と解析

325

record IP.srchost IP.dsthost in mail.hosts matrix-all;default:
select TCP.srcport selectDport {case ("Telnet", "Whois", "Finger", "rwho|rlogin"):record IP.srchost, IP.dsthost in Telnet.hosts
matrix-all;case ("FTP data", "FTP", "TFTP"):
record IP.srchost IP.dsthost in ftp.hosts matrix-all;case ("SMTP", "X.400", "X.400-SND", "NetNews"):
record IP.srchost IP.dsthost in mail.hosts matrix-all;} #end of select TCP.srcport} # end of select TCP.dstport

TCP.dstport

TCP.srcport

上記の例では、およびによって、各パケットがどの
アプリケーションに属するかを決め、それに応じて対応する名前をもつタイプのオブジェクトである、、のそれぞれに、パケットの個数を記録する。

TCP
matrix-all

Telnet.hosts ftp.hosts mail.hosts

以下に、上記の構文を用いたコンフィギュレーションファイルの例を示す。

## Enum of TCP/UDP ports#
enum {*port* (20 "FTP data", 21 FTP, 23 Telnet, 25 SMTP,
37 Time, 42 Name, 43 Whois, 53 Domains,
69 TFTP, 79 Finger, 103 X.400, 104 "X.400-SND",
111 sunrpc, 115 SFTP, 119 NNTP, 161 SNMP,
162 "SNMP trap", 512 exec, 513 "rwho|rlogin",
514 shell, 515 printer, 520 RIP)
*IP.proto* (1 ICMP, 3 GGP, 6 TCP, 8 EGP, 12 PUP, 17 UDP,
20 HMP, 21 "XNS-IDP", 27 RDP, 63 HELLO, 77 ND),*ICMP*(0 "Echo Rep", 3 "Dest Unreach", 4 "Source Quench",
5 "Redirect", 8 "Echo Req", 11 "Time Exc",
12 "Param Prob", 13 "Time Stamp",
14 "Time Stamp Rep", 15 "Info Req", 16 "Info Rep",
17 "AddrMask Req", 18 "AddrMask Rep")326

1992 年度 WIDE 報告書}## restrict remote access to statspy#
restrict readwrite 192.41.197.5 0xffffffff #clapton
restrict readwrite 130.69.251.15 0xffffffff #clapton
restrict readwrite 127.0.0.1 0xffffffff #localhost
subnet 133.4.0.0 0xffffffe0#wide-bb

attach {## Record all IP packets.
#record IP.srcsubn,IP.dstsubn in IP matrix-all-bytes ;## Record ICMP packets.
#
if IP.protocol is IP.proto eqf("ICMP") {record ICMP.type,ICMP.code in ICMP.types matrix-all-bytes ;record IP.srcsubn,IP.dstsubn in ICMP matrix-all-bytes ;record packet in ICMP.dump bin-pkt(50) ;}## Record TCP packets.
#
select TCP.dstport selDport {case ("Telnet", "rwho|rlogin"):{record IP.srcsubn,IP.dstsubn in Telnet matrix-all-bytes;}
case ("FTP", "FTP data"):{record IP.srcsubn,IP.dstsubn in FTP matrix-all-bytes;}
case ("SMTP"):{
record IP.srcsubn,IP.dstsubn in SMTP matrix-all-bytes;}

第 10 部

ネットワークト ラフィック統計情報の収集と解析

case ("NNTP"):{
record IP.srchost,IP.dsthost in NNTP matrix-all-bytes;}
default:
select TCP.srcport selSport {case ("Telnet", "rwho|rlogin"):{record IP.srcsubn,IP.dstsubn in Telnet ;}case ("FTP", "FTP data"):{record IP.srcsubn,IP.dstsubn in FTP ;}case ("SMTP"):{
record IP.srcsubn,IP.dstsubn in SMTP ;}case ("NNTP"):{
record IP.srchost,IP.dsthost in NNTP ;}}}}この例では、以下のような統計情報が収集される。

327

328

1992 年度 WIDE 報告書

オブジェクト名IP

ICMP.types
ICMP
ICMP.dump
Telnet
FTP
SMTP
NNTP

統計情報

IP パケットの送り手ネットワークと送り先ネットワークの組毎のパケット数とバイト数
メッセージのとの組毎のパケット数とバイト数
メッセージの送り手と送り先ホストの組毎のパケット数とバ
イト数
全てのメッセージのダンプ、、の送り手ネットワークと送り先ネットワークの組毎のパケット数とバイト数、の送り手ネットワークと送り先ネットワークの組
毎のパケット数とバイト数に属するパケットの送り手ネットワークと送り先ネットワー
クの組毎のパケット数とバイト数に属するパケットの送り手ネットワークと送り先ネットワー
クの組毎のパケット数とバイト数

ICMP
ICMP

types code

ICMP
Telnet rwho rlogin
FTP FTP data
SMTP

NNTP

2.2.4 collect による statspy へのアクセス

statspy

前節で解説したように、統計をとりたい各ネットワーク上でプログラムを動かし、プログラムにより遠隔ホスト上で動作するプログラムからおのおので収集されている統計情報を１箇所に集めることができる。
によるアクセスの種類には、基本的に次の２種類がある。

collect

statspycollect

read 指定したオブジェクトの現在の値を読み出す。
readclear 指定したオブジェクトの現在の値を読みだし 、オブジェクトの保持するデー
タをクリアする。

collect による statspy へのアクセスの戦略としては、
 比較的短い周期で各 statspy に対して必要なオブジェクトに対する read アクセスを従って、行い、得られたデータをファイルに書き出す。

 上記よりも長い周期で各 statspy に対して必要なオブジェクトを指定した readclear
アクセスを行い、得られたデータをファイルに書き出す。
がとられている。
によって作られる統計情報のファイルは、が動作しているホスト毎に、さらに、オブジェクト毎に分割されて作られる。各々のファイルに書き出される内容は、そのオブジェクトの名前、オブジェクトが定義された時刻 統計をとり始めた時刻 、以前にされた時の時刻、現在の時刻、オブジェクトの内容等である。
以下には、により作成されるファイルの例を示す。

collect

readclearcollect

statspy()

第 10 部

ネットワークト ラフィック統計情報の収集と解析

329

Log created on Sun Oct 11 00:05:49 1992, for host jp-tap.wide.ad.jp.
Sample interval = 20 minutes; checkpoint interval = 60 minutes.
Clear interval = 60 minutes.
Object name = 'IP'.
OBJECT: IP Class= matrix-all-bytes [Created: 11:30:18 10-09-92]
ReadTime: 01:00:00 10-11-92, ClearTime: 00:00:00 10-11-92 (@-3600sec)
Total Count= 131762 (+0 orphans)
Total Bytes= 24589322B#bins = 812[133.164.0.0 : 133.160.0.0]= 67616 &9263392B (51.3%) @-0sec[130.209.0.0 : 133.50.0.0]= 8321 &2942916B( 6.3%) @-257sec[130.215.0.0 : 133.26.0.0]= 6009 &3286226B( 4.6%) @-596sec[138.95.0.0 : 130.34.0.0]= 5007 &201875B( 3.8%) @-3sec[134.95.0.0 : 133.9.0.0]= 4668 &256740B( 3.5%) @-4sec[128.252.0.0 : 130.34.0.0]= 3952 &2040828B ( 3.0%) @-576sec[192.42.239.0 : 130.34.0.0]= 3617 &146353B ( 2.7%) @-2229sec.
.
[途中省略].
.
[137.39.0.0 : 130.34.0.0]= 1 &67B ( <.1%) @-3212sec[138.253.0.0 : 133.4.1.0]= 1 &67B ( <.1%) @-3251sec

OBJECT: IP Class= matrix-all-bytes [Created: 11:30:18 10-09-92]
ReadTime: 02:00:00 10-11-92, ClearTime: 01:00:00 10-11-92 (@-3600sec)
Total Count= 193532 (+0 orphans)
Total Bytes= 24243313B#bins = 825[134.95.0.0 : 133.9.0.0]= 82161 &4518855B (42.5%) @-19sec[133.164.0.0 : 133.160.0.0]= 68548 &9391076B (35.4%) @-0sec[128.59.0.0 : 133.1.0.0]= 6649 &3435289B ( 3.4%) @-39sec[16.0.0.0 : 133.4.1.0]= 4438 &2252155B( 2.3%) @-2062sec.
.
[途中省略].

330

1992 年度 WIDE 報告書.

[130.127.0.0 : 133.4.4.0]= 1 &69B ( <.1%) @-3566sec[129.24.0.0 : 133.4.2.0]= 1 &61B ( <.1%) @-3576sec

OBJECT: IP Class= matrix-all-bytes [Created: 11:30:18 10-09-92]
ReadTime: 03:00:00 10-11-92, ClearTime: 02:00:00 10-11-92 (@-3600sec)
Total Count= 121194 (+0 orphans)
Total Bytes= 24399400B#bins = 823[133.164.0.0 : 133.160.0.0]= 74265 &10174305B (61.3%) @-0sec[18.0.0.0 : 131.113.0.0]= 5397 &2866870B( 4.5%) @-438sec[128.59.0.0 : 130.69.0.0]= 4686 &2554929B( 3.9%) @-62sec[141.210.0.0 : 130.158.0.0]= 4432 &2225222B( 3.7%) @-597sec.
.
[以下省略].
.

IP read clear
133.9.0.0
IP
82161
4518855
Telnet SMTP

1:00

この例では１時間毎にオブジェクトをしており、例えば時刻
から
の間に
から
への
パケットが
個あり、それらのパケッ
トによって運ばれたデータ量がバイトあったことが分かる。
これ以外にも同様に、オブジェクトやなどの統計情報のファイルも同時に作られるので、各々のファイルの内容を総合すれば 、各ネットワーク間で各アプリケー
ションによるトラフィックが１時間毎にどのくらいあったかを調べることができる。
これらのファイルに書き込まれた統計情報を、等のスクリプトを用いる事により集計し 、アプリケーション別のトラフィックの表を作ったり、グラフを描いたりすることができ、それにより、データを収集したネットワークにおけるトラフィックの傾向を把握する事ができ、構成管理やアカウント管理、場合によっては障害管理にも役立てる事
ができる。

2:00

133.95.0.0

perl[95]

2.3

利点と欠点

NNStat を用いた IP トラフィックの統計情報収集の手法に付い
NNStat を用いた手法における利点と欠点をまとめる。

以上簡単ではあるが、て概観した。以下に利点

 統計情報収集の作業を SAA と SCH とに分散する事により、遠隔地にある複数のホストで、SAA プログラムを動作させ、１箇所においた SCH プログラムか第 10 部

ネットワークト ラフィック統計情報の収集と解析

331

SAA

ら全ての
において収集されている統計情報を集める事ができるので、統計データの管理が容易に行える。

 イーサネット上の全てのトラフィックを観測できるので、SAA をイーサネット

セグメントに１つおいておけば 、そのセグメント上の全てのホストに関わるトラフィック、および 、そのセグメントを通過して行くトラフィックの全てを含む
統計情報を得られる。

 コンフィギュレーション言語により、収集したい統計情報を定義する事ができ、SAA によって収集する統計情報を変えたり、あとから新たに収集する統計情報を付け加えたりする事が柔軟に行える。

 イーサネット上に現れないトラフィックを観測する事ができない。例えば 、図2.2のような構成のネットワークの場合、ネットワーク１からネットワーク４に向かうトラフィックは、ネットワーク３を通過するので、図の SAA で観測可能

欠点

であるが、ネットワーク１からネットワーク２に向かうトラフィックは、ルーター１上で折り返してしまい、ネットワーク２には現れないので、図のでは観測不可能になる。このような場合、各ルーター上でも同様にプログラ
ムを動作させる必要があるが、ルーターが専用ルーターである場合には、それができない。特に、のようなバックボーンネットワークの場合、各におかれたルーターに複数の接続組織へのリンクが収容されている場合が多く、その様な場合には各組織毎の正確な統計情報が得られなくなる。

SAA

WIDE

SAA

NOC

 SNMP を併用しているような場合、NNStat とは別に運用する必要があり、得られたデータの集計や管理に手間がかかる。

2.4

まとめ

NNStat

本章では、を用いたトラフィックの統計収集手法に付いて簡単にまとめ、その利点および欠点に付いて議論した。
前節で述べたような利点を活かしたまま欠点を補って行くためには、専用ルーターにおいても、ここで概観したのような統計収集手法が実現されることが望まれる。その際、との融合に関しても考慮されるべきであり、のような枠組の中で、統計情報を柔軟に定義するための手法が用意され、標準と同様にからアクセスできるようになれば理想的である。
その際に検討しなければならない課題としては以下のものがあげられる。

SNMP

Station

NNStatenterprise MIBMIBManagement 全てのパケットのトランスポートヘッダまで調べる必要があるため、統計収集を行うことが、ルーターの通常の処理に対してどの程度のオーバーヘッドを与えるか。

 収集する統計情報を柔軟に定義するためには、どのように MIB を構成する必要があ
るか。

332

1992 年度 WIDE 報告書
ネットワーク１へ

ネットワーク２へ

Router1

SAA

ネットワーク３

Router2
ネットワーク４へ

図2.2: NNStat により観測できないトラフィック

 ある程度の量の統計データを保持するために、ルーターの通常の処理に必要なメモ
リ容量に較べて、どの程度余分なメモリ容量が必要となるか。

tcpdump[96]

なお、今回は述べなかったが、さらにのような、各パケットの内容を解析するためのツールも専用ルーター上に実現することが今後必要になることも考えられる。

3章
WIDE インターネット 上のト ラフィック解析
第WIDE NetStat WG では、WIDE インターネットの利用状況を把握し 、また将来の回線計画のための裏付けとなる情報を得るために、2 年前から 2で解説した nnstat を用いて WNOC-TYO と WNOC-SFC 間のトラフィックおよび国際回線のトラフィックデータの収集・解析をおこなっている。
また、
プロジェクトでは 、国内の他のネットワークとの相互接続を行なっている。現在、主な相互接続地点としては、、、の 箇所である。
では 、との相互接続を行ない、
では、ととの相互接続を行なっている。また、
では、との相互接続およびとの接続を行なっている。
ではのバックボーントラフィックと同様に、やにおけるネットワーク相互間のトラフィックの収集・解析も行っている。
本章では、インターネット上のトラフィックおよび各ネットワーク間のトラフィッ
クに関する統計情報を示す。

WIDE

TIX(Tokyo Internet eXchange) WNOC-TYO
WNOC-KYO 3
WNOC-KYO
TISN(Genome)
WNOC-TYOSINET JOINTIX
TRAIN, TISN, JAIN
UTnet
WIDE
NetStat WG WIDE
TIX WNOC-TYO
WIDE

3.1

ト ラフィックデータ収集環境

3.1

図 に、現在の東京地域におけるネットワーク相互接続の状況およびトラフィックデー
タ収集環境を示す。
図中の、、というホスト上で、を動作させ、それぞれ国際線、と間、のトラフィックデータを収集し 、というホストでを動作させ、各ホストで収集されたトラフィックデータを集め、ディスクに納めている。さらに収集されたデータは毎月 回に書き込み、保存している。
現在は、

jp-tap wnoc-tyo stat
WNOC-TYO WNOC-SFC
collect

TIX

statspy

1 CDROM

 ネットワークプロジェクト (WIDE、TISN、JAIN 等) 間
 WIDE バックボーン (現在は WNOC-TYO と WNOC-SFC 間のみ) 上 WIDE の国際回線上という分類で、全てのネットワークアドレス間の、

333

stat

334

1992 年度 WIDE 報告書

TISN

UTnet

JAIN

TRAIN

Stat

TIX

768Kbps

JOIN

SINET

WNOC-SPK
wnoc-tyo

WNOC-TYO
WNOC-SND

384Kbps
WNOC-FUK

WNOC-KYO

WNOC-HIJ
jp-tap

WNOC-OSAWNOC-SFC

WIDE

192Kbps

US Internet

図3.1: WIDE NetStat WG によるトラフィックデータ収集環境

第 10 部

335

ネットワークト ラフィック統計情報の収集と解析

 IP プロトコル別 (TCP、UDP、ICMP、IGMP 等) パケット数/バイト数
 ICMP メッセージタイプ別パケット数/バイト数
 TCP アプリケーション別 (FTP, Telnet 等) パケット数/バイト数
 UDP アプリケーション別 (DNS、NTP 等) パケット数/バイト数

1

に関する統計情報を、 時間毎にまとめて集計している。
上でのトラフィックは、各ネットワークプロジェクトのネットワークをに接続するために用いているルータのイーサネットアドレスを用いて、トラフィックを分類した。
以下の節では、
年 月から年 月までに収集されたデータに対する解析結果について述べる。

TIX

1992 6

TIX

1993 3

3.2 TIX における情報交換
3.2

1993 2(byte)

まず始めに、図は、
年 月の各ネットワーク間で交換された情報量
を、
各ネットワークのマトリックスと、と交換した情報量とでグラフ化したものである。
との情報交換は、元時点では、としてまとめた情報しかサンプルしていな
いため、各ネットワークとの情報交換した値となっていない。

SINET

TIX

TIX

336

1992 年度 WIDE 報告書

図3.2: TIX におけるネットワークプロジェクト間のトラフィック

第 10 部

337

ネットワークト ラフィック統計情報の収集と解析

3.2.1 92 年度のト ラフィック変動

nnstat以下に示す情報は、すべてを用いて収集したデータで、月別に一日あたり交換された情報量の変化をグラフ化している。括弧内の値は、各月で情報が収集出来た日数である。

図3.3: SINET と TIX の間のトラフィック

3.3 WONC-TYO { WNOC-SFC のト ラフィック
WIDE のバックボーン中最も利用されている WNOC-TYO と WNOC-SFC 間の昨年 1
年間のトラフィックを以下に示す。

3.4

国際線のト ラフィック

3.4.1 IP プロト コル別ト ラフィック

3.1

1992 6

1993 3

IP

表
は、
年 月から
年 月までの プロトコル別のトラフィック量をキロ
バイト単位で表したものである。
一番左側の欄の括弧の中の日数は、各月に 日のデータが完全に収集できた日数である1 。これを有効日数と呼ぶことにする。合計の欄が各月に国際線上を転送された
デー
2
タグラムの総データ量をあらわしている 。また、一日平均の欄は、月の総データ量をそ1

IP

collect を動作させたホストの状態によって、完全なデータが収1データを蓄積したディスクの容量や、集できないこと日があった。
2ただし 、このデータ量にはデータリンクレベルのフレームヘッダの分は含んでいない。

338

1992 年度 WIDE 報告書

図3.4: SINET と WNOC-TYO の間のトラフィック

第 10 部

ネットワークト ラフィック統計情報の収集と解析

図3.5: TISN と JAIN の間のトラフィック

339

340

1992 年度 WIDE 報告書

図3.6: TRAIN と JAIN の間のトラフィック

第 10 部

ネットワークト ラフィック統計情報の収集と解析

図

3.7: TRAIN と TISN の間のトラフィック

341

342

1992 年度 WIDE 報告書

図3.8: TRAIN と WIDE の間のトラフィック

第 10 部

ネットワークト ラフィック統計情報の収集と解析

図

3.9: WIDE と JAIN の間のトラフィック

343

344

1992 年度 WIDE 報告書

図3.10: WIDE と TISN の間のトラフィック

第 10 部

345

ネットワークト ラフィック統計情報の収集と解析

192Kbpsの月の有効日数で割った値である。一番右の欄は、のバンド 幅をもつ国際回線
上を有効日数の間に転送する事ができる最大のデータ量に対する月の総データ量の占める割合である。従って、この値は各月の ヵ月間の平均回線利用率を表している。
図
は、表
をもとに、
年 月から
年 月までの全 トラフィックのうち、各プロトコルのデータ量の占める割合を表したグラフである。どちらの方向に関してものデータ量が全体の約を占めている事が分かる。
図、図はそれぞれ国外から国内向け、国内から国外向けのプロトコル別の毎
月のトラフィック量を、各月の 日平均のデータ量の推移により表したものである。
グラフより、全体の傾向としてどちらも増加の傾向にあることが分かる。
年 月になると、国外から国内向けのトラフィックは、 ヵ月の平均で、国内から国外向
けのトラフィクはとなり、どちらも最高の利用率となっている。
年 月から
年 月にかけて、一日の平均トラフィック量は、国外から国外向けが倍、国内から国外向けが倍と増加している。グラフの示す傾向から今後更に増加していくことが予想される。また
年月と年 月はほかの月と比較してのトラフィックの占める割合が多くなっているが、これは各々の月の行われたのの実験によるものと考えられる。
以下の節では各、、の各プロトコルに関して解析を行った結果に付い
て述べる。

3.12

TCP
3.13

1993 3

3.1

1992 6

1

IP

86%

3.14

1

1

43.4%

2.6

1993 3

1992 11

1993 3

TCP UDP ICMP

52.6%

1993 3

1992 6
2.5

UDP
IETF Audiocast

346

1992 年度 WIDE 報告書

3.4.2 TCP アプリケーション別ト ラフィック

3.2

TCP

表
は、
アプリケーション別のトラフィック量を各月の一日平均のキロバイト数
で表したものである。

第 10 部

3.15

3.2

347

ネットワークト ラフィック統計情報の収集と解析

1992 6

1993 3

FTP TCP

70%

TCP

図
は、表
をもとに、
年 月から
年 月までの全
トラフィックのうち、主要なアプリケーションに関するデータ量の占める割合を表したグラフである。
どちらの方向に関してもがの全データ量の以上を占めている。
図と図は、それぞれ国外から国内向け、国内から国外向けの
アプリケー
ション別の毎月のトラフィック量を、各月の 日平均のデータ量の推移により表したものである。また、図と図は、
年 月の 日あたりのデータ量を とした、ア
プリケーション別のデータ量推移の傾向を表すグラフである。
全体の傾向として国外から国内向けののトラフィックは約 倍、国内から国外向
けののトラフィックは約 倍になっている。各アプリケーションに関しては、、、などのデータ転送型のアプリケーションのトラフィックはやのようなインタラクティブなアプリケーションに比べて増加の傾向が強い。また、どちらの方向のトラフィックに関しても、のカテゴ リーに入るプロトコルのトラフィッ
クが増えている。これはインターネット上で提供されるサービスの種類の広がりを示唆しているといえよう。

3.16

3.17

3.18

TCP
SMTP NNTP

3.19
4

1
1992 6

TCP

Other

TCP

1

1

3

FTP
Telnet login

348

1992 年度 WIDE 報告書

3.4.3 UDP アプリケーション別ト ラフィック

3.3

UDP

表
は、
アプリケーション別のトラフィック量を各月の一日平均のキロバイト数
で表したものである。

第 10 部

3.20

349

ネットワークト ラフィック統計情報の収集と解析

3.3

1992 6

1993 3

TCP

図
は、表
をもとに、
年 月から
年 月までの全
トラフィックのうち、主要なアプリケーションに関するデータ量の占める割合を表したグラフである。
主要なアプリケーションの内のトラフィックは、国外から国内向きでは、の全データ量の約、国内から国外向きでは約を占めている。
図と図は、それぞれ国外から国内向け、国内から国外向けの
アプリケー
ション別の毎月のトラフィック量を、各月の 日平均のデータ量の推移により表したものである。また、図と図は、
年 月の 日あたりのデータ量を とした、ア
プリケーション別のデータ量推移の傾向を表すグラフである。ただし 、アプリケーショ
ンによる変動が極端に異なっていたので、図
では
および
に対し
て、また図
では
に対して、それぞれ他のものとは異なる 軸 グラフの右端に表示されている でプロットしている。
全体の傾向として、国外から国内向けの
トラフィックが約 倍に増加しているのに対して、国内から国外向けの
トラフィックの増加率は 倍にも達していない。しかし 、図から分かるように、国外から国内向けの
トラフィックの増加傾向は、に分類されたアプリケーションのトラフィックの増加傾向に影響されている。とくにこの増加傾向は
年月および年 月に顕著に現れており、このトラフィッ
クの増加はそれぞれの時期に行われたのの実験によるものと考えられる。また、国内から国外向けのトラフィックの内、によるものが著しく増加しているが、これに呼応するように、国内から国外向けののトラフィックが増加していることが図よりわかる。

3.21

3.22

30%

3.23

3.24

Other

Domain

)

3.24

UDP

3.23

1992 11

3.22

50%

1
1992 6

Archie

UDP

UDP

1

1

3.23

Talk/Phone

UDP

5

UDP

1993 3IETF Audio Cast
Archie
FTP

2

Y (

Other

350

1992 年度 WIDE 報告書

3.4.4 ICMP の種類別ト ラフィック

3.4

ICMP

3.25

3.4

表
は、
メッセージのトラフィック量を各月の一日平均のパケット数で表したものである。
図
は、表
をもとに、
年 月から
年 月までに観測された全パケットのうち、主な種類のパケット数の全体に占める割合を表したグラフである。
国外から国内に向かう
のうち約
が
を示す
メッ
セージであった。これは国内で何らかのルーティングエラーが起こり、特定のアドレスに対するルーティング情報が、経路上のルーターのルーティングテーブルから消えてしまった場合ににひきずられて海外に流れて行き、のルーターでとなりそれに対してが送られることに起因している。また同様に、間違ったアドレスに対してパケットを送った時にも同様のことが起こる。
国内から国外に向かう
のうち約
が
を示す
メッセー
ジであった。また、約がを示すメッセージで、他の種類のメッセージの数と比較して多くなっている。とくに後者の発生する原因の一つとして、ルーティングループの存在が考えられるため、このメッセージが大量に発生しているような場合には注意が必要である。ただし 、コマンドによっても用いられているため、が発生したからといって、ルーティングループが起こっているとは一概には言えない。他のなどでえられる情報と併せて判断していく必
要がある。
図
と図
は、それぞれ国外から国内向け、国内から国外向けのの種類ごとの毎月のトラフィックを、 日平均のパケット数で表したものである。当り前のことではあるが、図のメッセージの数と、図のメッセージの数の変動 またその逆の場合 が呼応している。また、図および図の両方とも、
メッセージの数が 月にとくに多かったことが分かる。このことから、昨年 月には国内のルーティングが何らかの理由で不安定であったことが予想される。
また、図
の、 月の
メッセージの数もルーティングの不安定さを裏付けるかのように、大量に発生している。しかし 、 月、 月、 月にも同じ程度の数のメッセージが発生している。これらが全てルーティングループに起因しているとは考えにくい。この点に関してはさらに詳しい解析が必要であろう。
図から、 月以降に、国内から国外に向かう
メッセージが急激に増加していることがわかる。これは何らかの障害に起因していることが予想される。仮に、どのポートに対するメッセージなのかが分かればある程度その原因を究明することも可能であるが、現在のによるデータ収集方法では不可能である。
なぜなら、 で解説したように、
ではやのヘッダの情報をもとに統計データを記録しており、したがってのボディーとして返される、そのをひきおこした データグラムのヘッダの情報などを用いることができない。このような解析を行うためには、のようなツールを用いることが必要になるだろう。

1992 6

ICMP

1993 3ICMP

45% Network Unreachable

ICMP
IP

default route
FIX-West
Network Unreachable
ICMP
IP
ICMP
52% Port Unreachable
ICMP
19% Time Exceeded in Transit
ICMP
Time Exceeded

3.26

traceroute

SNMP

3.27

1
3.26 Echo Request()
Net Unreachable
6
6
3.27 6Time Exceeded
Time Exceeded
3.27

11

ICMP

3.27 Echo Reply
3.26
3.27

7

8

9

Port Unreachable

Unreachable

NNStatNNStat IP ICMP
ICMP

2

IP

tcpdumpICMP第 10 部

図ネットワークト ラフィック統計情報の収集と解析

3.11: WNOC-TYO と WNOC-SFC 間のトラフィック

351

352

1992 年度 WIDE 報告書

表

6月(23 日)
7月(31 日)
8月(31 日)
9月(29 日)
10 月(24 日)
11 月(30 日)
12 月(30 日)
1月(28 日)
2月(28 日)
3月(30 日)

3.1: プロトコル別トラフィック (単位：キロバイト )

ICMP

IGMP

TCP

UDP

合計

一日平均

IN
330,219
0 9,016,057 840,499 10,186,775 442,903
OUT 259,574
0 6,130,023 1,440,745 7,830,348 340,450IN300,219545 14,070,767 2,043,562 16,415,092 529,519
OUT 303,861
768 9,685,353 1,214,786 11,204,768 361,444
IN
124,714
0 14,943,681 2,200,149 17,268,545 557,050
OUT 171,125
0 10,952,087 1,092,845 12,216,058 394,066
IN
80,638
0 13,201,710 1,169,489 14,451,838 498,339
OUT 131,441
0 9,880,677 611,585 10,623,703 366,335
IN
64,643
0 13,286,104 1,324,699 14,675,447 611,477
OUT 188,894
0 10,178,627 1,788,799 12,156,325 506,514
IN
212,677 19,118 18,651,562 4,926,715 23,810,071 793,669
OUT 345,160 23,488 13,679,215 3,838,067 17,885,932 596,198
IN
185,176 29,220 20,368,457 3,015,233 23,598,087 786,603
OUT 438,892 34,429 12,996,192 1,246,867 14,716,381 490,546
IN
176,433 22,012 16,985,993 1,860,617 19,045,054 680,181
OUT 347,340 21,420 8,930,094 772,622 10,071,478 359,696
IN
281,358 7,051 24,787,572 2,246,190 27,322,172 975,792
OUT 569,901 9,696 16,093,806 1,519,153 18,192,562 649,734
IN
394,293 40,073 27,957,875 4,123,046 32,700,113 1,090,004
OUT 890,211 55,970 23,946,019 2,072,386 26,964,664 898,822
合計
IN 2,150,369 118,018 173,269,777 23,750,199 199,473,194 702,370(284 日) OUT 3,646,398 145,771 122,472,094 15,597,855 141,862,220 499,515

回線利用率

21.4%
16.4%
25.5%
17.4%
26.9%
19.0%
24.0%
17.7%
29.5%
24.4%
38.3%
28.8%
37.9%
23.7%
32.8%
17.4%
47.1%
31.3%
52.6%
43.4%
33.9%
24.1%

第 10 部

353

100%

86.33%

86.86%

ネットワークト ラフィック統計情報の収集と解析

Inbound
Outbound

80%

60%

IP

TCP

図

UDP

ICMP

IGMP

3.12: IP プロトコル別トラフィック量分布

Other

0.00%

0.09%

0.10%

0.06%

2.57%

1.08%

20%

11.00%

11.91%

40%

354

1992 年度 WIDE 報告書

1,100

Other
IGMP
ICMP
UDP
TCP

1,000
900

50 %

40 %

800

30 %

600
500

20 %

400

Line Utilization

MBytes

700

300
10 %

200
100

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Month

図

3.13: 国外から国内向けの、プロトコル別トラフィック量推移 (1 日平均)

1,100

Other
IGMP
ICMP
UDP
TCP

1,000
900

50 %

40 %

800

30 %

600
500

20 %

400
300

10 %

200
100

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Month

図

3.14: 国内から国外向けの、プロトコル別トラフィック推移 (1 日平均)

Line Utilization

MBytes700

第 10 部

表355

ネットワークト ラフィック統計情報の収集と解析

3.2: TCP アプリケーション別トラフィック (単位：キロバイト／日)IN
6 月 OUTIN
7 月 OUTIN
8 月 OUTIN
9 月 OUTIN
10 月 OUTIN
11 月 OUT
IN
12 月 OUTIN
1 月 OUTIN
2 月 OUTIN
3 月 OUT
IN
平均
OUT

FTP

303,392
193,648
346,111
221,895
360,439
261,992
353,977
270,943446,506
346,426
478,120
358,778
519,335
321,276
442,304
233,339648,657
401,272
674,162
569,538
459,711
320,010SMTP

35,78523,69844,07332,423
57,686
27,76243,07824,77946,98533,27260,43435,801
54,611
43,897
46,68330,22972,95175,043
83,40584,37755,133
41,542

NNTP

Telnet13,95919,493
17,206
17,702
20,26918,46525,165
12,392
20,715
13,141
36,915
16,892
44,257
18,724
77,383
13,72489,19429,252
94,38539,87744,50920,114

19,411
18,077
22,824
20,646
21,89827,841
13,11918,96815,69015,36817,184
18,357
15,36819,72013,376
14,854
20,671
21,83323,13828,16318,35920,606

Login

3,701
4,737
4,116
5,743
3,128
4,908
2,874
3,530
3,015
4,166
4,310
6,563
5,293
6,132
3,535
3,608
4,116
6,221
3,829
7,965
3,812
5,410

DomainFinger

4,009
759
4,240
552
3,744
481
3,586
506
807
1,045
769
963
884
1,336
775
1,100
2,234
1,775
2,429
2,760
2,358
1,132

Z39.50

285
271
492
489
323
253
383
331
1,077
501
556
488
722
572
511
354
669
688
595
841
556
483

291
29
185
15
193
20
459
35
144
19
678
69
417
48
173
18
595
68
419
97
360
42

80%

60%

TCP

FTP

図

SMTP

NNTP

TelnetLogin

DomainFinger

Z39.50

3.15: TCP アプリケーション別トラフィック量分布

Whois

5.06%

4.13%

0.02%

0.01%

0.06%

0.01%

0.11%

0.09%

0.39%

0.26%

1.25%

0.62%

4.78%

3.01%

7.30%

4.66%

9.63%

9.04%

40%

20%

79
52
61
28
36
16
47
15
187
38
93
34
138
75
152
54
114
143
116
142
100
60

その他

11,0905,760
14,58912,937
14,337
11,556
12,543
9,215
18,462
10,13322,65818,02937,924
21,426
21,75021,652
46,06838,48349,45164,44025,206
21,841

Inbound
Outbound

74.21%

75.35%

100%

Whois

Others356

1992 年度 WIDE 報告書

1,000

Other
Whois
Z39.50Finger
DomainLogin
Telnet
NNTP
SMTP
FTP

900
800
700

MBytes

600
500
400
300
200
100

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Month

図

3.16: 国外から国内向けの TCP アプリケーション別トラフィック量推移 (1 日平均)
1,000

Other
Whois
Z39.50Finger
DomainLogin
Telnet
NNTP
SMTP
FTP

900
800
700

MBytes

600
500
400
300
200
100

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Month

図

3.17: 国内から国外向けの TCP アプリケーション別トラフィック量推移 (1 日平均)

第 10 部

7

6

Traffic Trend

5

4

357

ネットワークト ラフィック統計情報の収集と解析

7

TCP
FTP
SMTP
NNTP
TelnetLogin
DomainFinger
Z39.50
Whois
Other

6

5

4

3

3

2

2

1

1

0

0
Jun, 92

Jul

Aug

Sep

Oct

Nov

Dec

Jan, 93

Feb

Mar

Month ( Jun, 1992 - Mar, 1993)

図3.18: 国外から国内向きの TCP アプリケーション毎のトラフィックの傾向
7

6

Traffic Trend

5

4

7

TCP
FTP
SMTP
NNTP
TelnetLogin
DomainFinger
Z39.50
Whois
Other

6

5

4

3

3

2

2

1

1

0

0
Jun, 92

Jul

Aug

Sep

Oct

Nov

Dec

Jan, 93

Feb

Mar

Month ( Jun, 1992 - Mar, 1993)

図3.19: 国内から国外向きの TCP アプリケーション毎のトラフィックの傾向358

1992 年度 WIDE 報告書

表3.3: UDP アプリケーション別トラフィック (単位：キロバイト／日)Domain NTP Archie Talk/Phone SNMP その他
26,013 1,026
1,291
294
556
7,364
53,272 1,563
29
3,157
266
4,354
30,286 1,269
1,467
192
353 32,354
29,873 1,594
40
215
26
7,438
26,585 1,418
1,067
162
261 41,480
21,893 1,590
26
131
112 11,501
9,091 1,232
1,208
278
210 28,308
13,447 1,518
24
234
25
5,842
26,734 1,154
1,590
621
186 24,912
32,362 1,285
350
411
14 40,111
19,059 1,486
821
588
166 142,103
20,097 1,210
610
513
1 105,505
28,945 1,516
1,132
1,820
79 67,015
24,860 1,213
1,336
301
6 13,846
19,840 1,465
1,556
155
329 43,107
17,522 1,214
984
495
310
7,069
26,207 1,605
1,148
5,926
310 45,024
26,791 1,239
4,621
761
385 20,459
34,226 1,363
1,444
949
238 99,215
38,397 1,243
5,006
891
534 23,010
24,728 1,364
1,264
1,097
263 54,911
27,247 1,367
1,329
656
166 24,158

IN
OUT
IN
7月
OUT
IN
8月
OUT
IN
9月
OUT
IN
10 月
OUT
IN
11 月
OUT
IN
12 月
OUT
IN
1月
OUT
IN
2月
OUT
IN
3月
OUT
IN
平均
OUT
6月

100%

65.66%

Inbound
Outbound

UDP

Domain図

NTP

Prospero

Talk/Phone

SNMP

0.30%

0.31%

1.19%

1.31%

2.42%

1.63%

20%

1.51%

40%

2.49%

29.57%

60%

43.99%

49.61%

80%

Other

3.20: UDP アプリケーション別トラフィック量分布第 10 部

180

359

ネットワークト ラフィック統計情報の収集と解析

Other
SNMP
Talk/Phone
ArchieNTP
Domain160

140

MBytes

120

100

80

60

40

20

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Month

図

3.21: 国外から国内向けの UDP アプリケーション別トラフィック量推移
180

Other
SNMP
Talk/Phone
ArchieNTP
Domain160

140

MBytes

120

100

80

60

40

20

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Month

図

3.22: 国内から国外向けの UDP アプリケーション別トラフィック量推移360

1992 年度 WIDE 報告書

6

21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0

UDP
DomainNTP
ArchieSNMP

5

Traffic Trend

4

3

2

1

0
Jun, 92

Jul

Aug

Sep

Oct

Nov

Dec

Jan, 93Feb

Talk/Phone
Other

Mar

Month ( Jun, 1992 - Mar, 1993)

図10

3.23: 国外から国内向きの UDP アプリケーション毎のトラフィックの傾向
180

UDP
DomainNTP
Talk/Phone
SNMP
Other

9
8

170
160
150
140
130

7

Traffic Trend

120
110

6

100
90

5

80
4

70
60

3

50
40

2

30
20

1

10
0

0
Jun, 92

Jul

Aug

Sep

Oct

Nov

Dec

Jan, 93

Feb

Mar

Month ( Jun, 1992 - Mar, 1993)

図3.24: 国内から国外向きの UDP アプリケーション毎のトラフィックの傾向

Archie第 10 部

表

3.4: ICMP の種類別トラフィック (単位：パケット数／日)

Echo
Reply
6月
7月
8月
9月
10 月
11 月
12 月
1月
2月
3月
平均

IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT

361

ネットワークト ラフィック統計情報の収集と解析

Net
Host
Port
Source Redirect EchoTime
ExUnreach Unreach Unreach Quench Host
Request ceeded

6,630 196,372 11,087 23,971
7,715 89,892
1,779
6,199
21,712 62,939
5,681 14,440
37,273
2,562
397
1,434
4,505 51,745
3,103
4,637
799
3,970
1,001
1,761
4,246 21,984
2,811
6,446
1,128
4,734
2,228
5,781
5,873 15,014
3,423
9,928
702
1,637 105,479
9,860
24,168 40,845
4,581 25,670
668
8,810 53,353 83,278
8,285 41,669 16,424 22,201
846
2,257
8,719 232,878
4,373 53,446 11,140 18,169
326
7,748 25,544 146,475
3,295 47,760 14,753 40,675
972 12,011
942 285,323
5,901 61,436 12,842 35,876
59,948 26,488
5,128 323,610
9,136 57,119
8,561 20,169
11,576 14,530 19,148 112,427

Other

in
Transit

1,744
33 10,059 3,700
247
0 8,762 82,942
3,241
33 36,315 3,663
746
1 27,440 76,949
1,292
72 1,173 4,144
199
86 16,135 68,684
931
290 1,966 4,822
82
1 6,419 56,575
1,441
340 3,008 4,900
214
4 7,608 13,341
3,900 1,364 5,102 6,909
100
2 38,432 4,106
1,737
70 6,113 7,668
105
1 7,197 11,432
2,124 11,774 2,769 10,742
76
2 6,930 31,809
3,573 20,879 22,285 18,036
172
1 27,846 20,487
2,916 29,032 48,024 16,358
202
392 37,653 40,296
2,318 6,510 14,089 8,163
217
52 18,991 40,572

15
58
2
77
5
45
125
199
187
27
18
89
5
353
289
20
44
35
37
40
70
97

362

1992 年度 WIDE 報告書

100%

Inbound
Outbound45.28%

51.66%

80%

60%

ICMP

Echo
Reply

Net
Host
Port
SourceUnreachUnreachUnreachQuench図Redirect
Host

Time ExceededEcho
in transit
Request3.25: ICMP 種類別メッセージ量分布

0.06%

0.04%

18.64%

6.47%

11.17%

8.73%

5.16%

0.02%

0.10%

1.84%

15.99%

8.80%

6.79%

6.68%

20%

5.32%

7.24%

40%

Others第 10 部

500000363

ネットワークト ラフィック統計情報の収集と解析

OthersTime Exceeded in transit
Echo Request
Redirect Host
Source Quench
Port Unreach
Host Unreach
Net Unreach
Echo Reply

450000400000350000

Packets

300000250000200000150000100000
50000
0
Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Month

図

3.26: 国外から国内向けの ICMP の種類別トラフィック量推移 (パケット数／日)
500000

OthersTime Exceeded in transit
Echo Request
Redirect Host
Source Quench
Port Unreach
Host Unreach
Net Unreach
Echo Reply

450000400000350000

Packets

300000250000200000150000100000
50000
0
Jun

Jul

Aug

Sep

Oct

Nov

Dec

Jan

Feb

Mar

Month

図

3.27: 国内から国外向けの ICMP の種類別トラフィック量推移 (パケット数／日)

4章
RFC1404:A Model for Common
Operational Statistics
第RFC1404[97]Internet

operational statistics

本章では、で提案されている、に於けるの為のモデルについてまとめる。このでは、尺度、測定方法、ポーリング期間、格納時のフォーマット、そして表示時のフォーマットについて推薦されているものが示され
ている。

4.1

RFC

序章

現在、多くのネットワークの管理において、ネットワークの利用や成長を表すネット
ワーク管理の尺度
を収集、格納することは珍しいことではない。その主な目的
は、組織内の短期間の問題の分離や長期間のネットワークの計画を容易にすることである。ネットワーク管理者の間での、共同な問題の分離やネットワークの計画といったよ
り大きな目的も存在する。
ネットワーク管理の尺度の収集や表示を行なうためのネットワーク管理ツールはいろ
いろあるが、測定や表示の方法が異なっているので、ネットワーク同士のデータを比較することが難しくなっている。それに加えて、どの尺度を常に集めるか、それらをどのように表すかについての共通の合意がない。
以下のような条件に一致したモデルが必要となる。

(metric)

1) 上記に述べた目的を満足させるための共通なネットワーク管理尺度の最小セット
2) これらの尺度を収集するためのツール
3) 共通な表示ツールによってこれらのデータを簡単に使用できるようにするための共通の保存フォーマット

4) 共通の表示方法のフォーマット
この Operational Statistics モデルの基では、データ収集ツールは与えられたフォーマットにしたがってデータを収集・保存し 、あらかじめ定義された方法でそのデータを表す
ための表示ツールによって後でデータを引き出す（図
を参照）
。

4.1

364

第 10 部

365

ネットワークト ラフィック統計情報の収集と解析
Network

New
Collection
Tool

Old
Collection
Tool

Post-Processor

CommonStatistics
Database

Pre-Processor

New
Presentation
Tool

Old
Presentation
Tool

Graphical Output(e.g., to paperor X-window)

図4.1: The Operational Statistics Model

operational statistics
)

(

oper-

このメモでは共通ののためのモデルの概観 ネットワークの収集や保存、表示法 を示す。
このモデルは尺度の最小セットや、これらの尺度がどのように収集・保存されるべきかを定義する。最終的には、間でネットワーク統計値を簡単に比較できるようにする
ための統計レポートの内容や構成について、その推薦されるものを示す。
このモデルの第一の目的は、複数の間でを最も効果的に分担する方法を定義することである。

ational statistics

NOC

NOC

4.2

operational statistics

モデル

モデルの定義は3 つに分けられる。

1. 収集される尺度の最小セットの定義
2. 収集された統計データを保存するためのフォーマットの定義
3. レポートを作成するための方法とフォーマットの定義
このモデルは、現在使用されている古い仕様のツールが、データをコンバートするフィル
タを提供することによって、新しい仕様に適合できることを示している（図
を参照）
。

4.1

366

1992 年度 WIDE 報告書

このモデルの一つの基本的な考えとして、統計データを一箇所に保存して、複数の他の場所で取り出したり表示したりできるようにすることがある。

4.2.1

尺度とポーリング期間

SNMP[79]

ここでは、標準のをベースとしたネットワーク管理ツールを用いることで簡単に収集することができる尺度の最小セットを定義する。したがってこれらの尺度は標準のの変数として利用できる。

Internet
MIB[98]Internet 標準の MIB が変更された場合、この尺度の最小セットの内容も考え直される。
収集することを強く望むような尺度の中で、SNMP を用いて Internet 標準の MIB から
現行では取り出す方法がない物もあるが、もしその様な尺度について良く検討されているなら、その様な尺度を収集するためのツールや方法が明白に定義されるべきである。

4.2.2

収集したデータを保存するためのフォーマット

余分な情報を最小にするような、データを保存するためのフォーマットを定義する。そのフォーマットは保存されている統計データのセットに関係する情報をすべて一つのヘッダーの構造に入れ、そしてそのヘッダー部に対応する統計データを収集した時間と場所についての情報を含める。

4.2.3

レポート

ある期間におけるオクテットとパケットの総量に関するレポートは 、ネットワークのトラフィックの流れの全体を見渡すために重要である。どんなトラフィックのタイプが多いか考えるために、アプリケーションとプロトコルを区別する必要がある。最終的には、資源の利用についてのレポートが推薦されるだろう。
レポートではその目的によって測定期間が異なってもよい。

4.2.4

セキュリティに関する問題点

データの共有には、法律的、倫理的、政治的な関連がある。見ているデータのことを心配する人がいる。なぜなら、そのデータがそのネットワークの一つを悪く見せるかも知れないからである。
このため、共有されるデータが、完全な状態で、正確に一致していて、信頼できる物であることを保証する必要がある。有用なものにするためには、同種のデータが関係する
すべてのサイトから収集されなければならず、そしてそれは同一の間隔で収集されなくてはならない。

第 10 部

4.3

尺度の分類

4.3.1

概観

367

ネットワークト ラフィック統計情報の収集と解析

この章では尺度の分類、および将来的なことまで含めて考えられた尺度に関するヒントについて述べる。

4.3.2

測定方法の区分を基準とした尺度の分類

ネットワークのトラフィックを評価するために用いられる尺度は、少なくとも要なカテゴ リーに分類される。

4 つの主

 利用に関する尺度
 性能に関する尺度
 可用性に関する尺度
 安定性に関する尺度
 利用に関する尺度
ネットワークを通して転送されたトラフィックの総量について異なる側面を述べる物。

{ 入出力されたパケットとオクテットの総量{ さまざまな尺度のピーク時の値{ プロトコル毎、アプリケーション毎の尺度

 性能に関する尺度
ネットワークの遅延や混雑の状態のようなサービスの質について述べる物。

{ 異なるプロトコルレイヤーに関する RTT metric{ バス (bus) ネットワーク上での衝突 (collision) の数{ ICMP Source Quench メッセージの数{ drop したパケットの数{ その他

 可用性に関する尺度
異なるプロトコルレイヤーの、長期間の可用性を表す尺度とみなすことができるもの。

{ 利用可能であった割合で表された、回線の可用性。
{ 経路に関する可用性3681992 年度 WIDE 報告書{ アプリケーションに関する可用性

 安定性に関する尺度
ネットワークのサービスのレベルを下げる様な、ネットワークの短期間の変動について述べる物。またこれらの尺度を用いることでトラフィックのパターンの変化についても知ることができる。

{ 急激な回線状態の変化に関する数{ 急激な経路の変更に関する数 (経路の apping としても知られている){ テーブル内のインターフェース毎の経路に関する数{ 次の hop count の安定性
{ 短い間隔での ICMP のふるまい

4.3.3

尺度の可用性を基準とした分類尺度を取り出すことを可能にするためには、対応する変数が、統計値が収集されている管理ド メインの一部となっているすべてのネットワークからアクセス可能でなくては
ならない。
標準の
で変数として定義されているので容易に取り出すことができる尺度もあるし 、あるベンダーのプライベートなのの一部として取り出すことができる尺度もある。また、ある尺度はの概念に含めることができな
いために取り出すことが不可能であると考えられる。あるいは、これらの尺度の実際の測定方法は広範囲に渡るポーリングを必要とするので取り出すことが不可能であると考えられる。
以降で示すような分類された尺度が、ネットワークの振舞いを評価する上で重要な尺度であると判断することができた。

Internet

MIB

enterprise MIB subtree
SNMP Internet 標準の MIB の中に既に含まれている、インターフェースに関する変数
Internet 標準の MIB に既に含まれている変数で、簡単に取り出せるもの{ ifInUcastPkts (入ってきた単一アドレス宛のパケット数){ ifOutUcastPkts (出て行った単一アドレス宛のパケット数){ ifInNUcastPkts (入ってきた、非単一アドレス宛 (ブロードキャスト等) のパケッ
ト数)
{ ifOutNUcastPkts (出て行った、非単一アドレス宛 (ブロードキャスト等) のパ
ケット数){ ifInOctets (入ってきたオクテット数){ ifOutOctets (出て行ったオクテット数)

第 10 部

ネットワークト ラフィック統計情報の収集と解析

369{ ifOperStatus (回線の状態)

 プライベートな Enterprise MIB の中に含まれている、インターフェースに関する
変数
プライベートなもの

enterprise MIB に入れられている変数で、時には取り出し可能な{ 入ってきた時点で捨てられてしまったパケットの数{ 送り出そうとした時点で捨てられてしまったパケットの数{ 入ってきた輻輳イベントの数{ 出て行った輻輳イベントの数{ 集計エラーの数{ インターフェースのリセットの数

 高頻度のポーリングを必要としている、インターフェースに関する変数
高い頻度でのポーリングを必要とする変数で、ネットワークに負荷を与えるために難しいもの{ インターフェースの待ち行列の長さ{ 統計情報を収集できなかった期間{ インターフェースが利用不可能であった時間{ 経路の変更の頻度{ そのインターフェースにおける次のホップ数

 どんな MIB の中にも含まれていない、インターフェースに関する変数
MIB の中に含まれていない変数で、MIB の中に含むことは可能であるが、SNMPを用いて取り出すことが不可能なもの{ リンクレイヤーに入ってきたパケット数{ リンクレイヤーから出て行ったパケット数{ リンクレイヤーに入ってきたオクテット数{ リンクレイヤーから出て行ったオクテット数{ パケットの到着時間間隔{ パケット長の分布

 ノード 毎の変数
これまでに分類されていないもの

370

1992 年度 WIDE 報告書{ プロトコル別の、入ってきたパケット数{ プロトコル別の、出て行ったパケット数{ プロトコル別の、入ってきたオクテット数{ プロトコル別の、出て行ったオクテット数{ 入ってきた時点で捨てられたパケット数{ 送り出そうとした時点で捨てられたパケット数{ パケット長分布{ システムの uptime{ ポーリングの間隔{ リブートした回数

 SNMP を用いて取り出すことができない尺度
SNMP を用いて取り出すことができない尺度{ 異なるプロトコルレイヤーでの遅延 (RTT){ アプリケーションレイヤーの可用性 (availability){ ピーク時の尺度の振舞い

4.3.4

推薦される尺度

このモデルが一般的な総意に至ることを容易にするために、尺度の最小セットを定義する必要がある。それは、必要不可欠な物、今日のネットワークの大部分で取り出すことが可能な物の両方である。一般的に取り出すことが可能であることを示すものとして、標準のの中にあるものが必須であると考えられる。

Internet

MIB

 選ばれた尺度
以下に続く尺度はたものである。

Internet 標準の MIB の中で合理的で望ましいものとして選ばれ各インターフェース毎に{ ifInOctets{ ifOutOctets{ ifInUcastPkts{ ifOutUcastPkts{ ifInNUcastPkts

第 10 部

371

ネットワークト ラフィック統計情報の収集と解析{ ifOutNUcastPkts{ ifInDiscards{ ifOutDiscards{ ifOperStatus
各ノード 毎に{ ipForwDatagrams{ ipInDiscards{ sysUpTime

Internet
MIB

MIB

RTT

上にあげたすべての尺度は標準のの中で利用できる。しかしの様に、多分どんなの中にも決して含まれていないような他の尺度でも、推薦できるものがある。このような尺度のためには、とは違ったデータ収集用のツールについてはっきりと定義する必要がある。

metric

4.4

SNMP

ポーリング頻度

ポーリングは、ネットワークの動向とキャパシティについての計画を行なうための基準として役に立つ統計量を集め保存するために行なう。すべての値について調査し蓄えることが推薦されるが必須ではない。

4.4.1

高頻度のポーリングを必要としている変数

1

ピーク時の振舞いを見つけ出すために推薦できることは、 分を最大とした期間でトラフィックデータの収集を行なうことである。この頻度で集められる尺度は、各インターフェース毎に、

 ifInOctets
 ifOutOctets
 ifInUcastPkts
 ifOutUcastPkts

60 秒

もしこの高いポーリングの頻度でデータの収集を行なうことが可能でないなら、の偶数倍の時間を用いることが推薦される。

372
4.4.2

1992 年度 WIDE 報告書
高頻度のポーリングを必要としていない変数

各インターフェース毎、

 ifInNUcastPkts
 ifOutNUcastPkts
 ifInDiscards
 ifOutDiscards
 ifOperStatus
そして、各ノード 毎、

 ipForwDatagrams (IP forwards)
 ipInDiscards (IP in discards)
 sysUpTime (system uptime)
これらの変数はより低いポーリングの頻度で集められても良い。特別なポーリングの頻度については言及しないが、 秒の偶数倍を選ぶことが勧められる。

60

4.5

生の統計データに対する前処理

4.5.1

データの最適化と圧縮()

冗長なデータの保存を避けるために、 保存する前に 生のデータに処理を加える必要がある。例えば 、リンクが落ちている時にデータを保存する必要はないし 、ある期間全くトラフィックのないリンクやノードからデータを集めて保存し続けることもない。
処理を行なうことの他の側面は、調査が行なわれている未加工のインターフェースからデータを取り出し 、それを役に立つデータに変換することである。

4.5.2

データの集計

ここでは集計をエントリーが記録され一つのポーリング期間が終ることを意味するものとする。新しく集められたエントリーは、いくつかの集計期間を終えて前もって記録されているエントリーの、その最初の物と最後の物を用いて作り出され、新しいエントリーが計算される。
集められたデータは与えられたファイルに前処理を施されて入れられる。
集計期間に関する提案:

第 10 部

ネットワークト ラフィック統計情報の収集と解析373

 24 時間の期間では、総計 15 分、
 1 ヶ月の期間では、総計 1 時間、
 1 年の期間では、総計 1 日
集計は、その前の集計期間のデータを基にした集計期間の値の、新しい平均値と最大値の計算結果である。それぞれの集計期間について、その最大値と平均値が計算されて保存されている。

4.6

統計データの保存

この章では統計データを保存するためのフォーマットについて述べる。最終的な目的
は、統計データの収集や保存、解析のためのツールを簡単にすることである。フォーマッ
トは、冗長な情報を最小にするという目的で定義されている。
フォーマットは、異なる つの部分からなり、ラベルセクション 、デバイスセクショ
ン 、データセクションとなる。ラベルセクションは続くデータセクションのデータの始
まりと終りの時間を示し 、データセクションは実際にデータが格納されたファイルと同じ物である。デバイスセクションは対応しているデータセクションに何が登録されているか特定する。
ラベルセクションとデバイスセクション、データセクションは一度以上現れても良い。
それぞれのセクションの形式は一つののペアによって範囲が決められる。
ラベルとデバイスセクションはともにデータファイルの中に直接格納されるか、ラベルセクションののエントリによって指定される別のファイルに格納される。
一つのデータセクションが一つのラベルセクションと一つのデバイスセクションに正確に対応していなくてはならない。

3

BEGIN-END

data- le4.6.1

格納時のフォーマット

stat-data ::=<label-section><FS><device-section><FS><data-section><FS>[<device-section><FS><data-section><FS>]
FS ::= "," | <LF> | <LF> # any text here <LF>
ファイルはラベルセクションから始まり、続いてデバイスセクション、データセクショ
ンと続く。もし何かの理由で記録されたデータの保存が中断された場合には、再びデー
タの保存が始められた時に新しいラベルが挿入される。記録されているデバイスが変えられた場合、新しいラベルと新しいデバイスを挿入することでこのことが表される。
実際のデータの物理的な保存はローカルに決められることで、いろいろ変えることができる。一つのインターフェース毎、あるいは同じデータファイルの中に記録された複374

1992 年度 WIDE 報告書

数のインターフェース毎に一つのデータファイルがあってもよい。ラベルセクションとデバイスセクションは、データファイルの中に入れても別ファイルに入れて保存しても良い。

 ラベルセクション
label-section ::="BEGIN_LABEL"<start_time><stop_time><data_file>"END_LABEL"

<FS>
<FS>
<FS>
<FS>

start-time ::= <time-string>
end-time::= <time-string>file-name::= <ascii-string>time-string ::= <year><month><day><hour><minute><second>year::= <digit><digit><digit><digit>
month::= 01 | ... | 12hour::= 00 | ... | 23
minute::= 00 | ... | 59
second::= 00 | ... | 59
digit::= 0 | ... | 9
ascii-string ::=MIB II で定義された <ascii-string> と同じ

時間は記録されているデータのセットに関連した始まりと終りの時間である。時間
は
形式。

UTC

 デバイスセクション
device-section ::= "BEGIN_DEVICE" <FS>
<device-field> <FS>
"END_DEVICE"
device-field::= <networkname><FS><routername><FS><linkname><FS><bw-value><FS><bw-sort><FS><proto-type><FS><proto-addr><FS><time-zone><FS><tag-table>[<tag-table>]第 10 部

ネットワークト ラフィック統計情報の収集と解析

375

networknameroutername
linkname
bw-valuebw-sortproto-type
proto-addr
timezonetag-table::= <ascii-string>::= <ド メイン名に完全に適合したもの>::= <ascii-string>::= <実際の bandwidth の値>::= "bps" | "Kbps" | "Mbps" | "Gbps" | "Tbps"::= "IP" | "DECNET" | "X.25" | "CLNS"::= <proto-type に依存したネットワークアドレス>::= <"+" | "-"><00 | ... | 12><00 | 30>::= <tag><FS><tag-class><FS><variable-field>[<FS><variable-field>]
tag-class::= "total" | "peak"variable-field ::= <variable-name> <FS> <initial-polling-period><FS><aggregation-period>tag::= <ascii-string>
variable-name ::= <ascii-string>
initial-polling-period ::= <digit>[<digit>]
aggregation-period::= <digit>[<digit>]

networkname は人間が読みやすい文字列の形式で、記録されたデータがどのネット
ワークに属しているかを表す。

routername はルータがどこに設置されているかというネットワークアーキテクチャ
にとって適切な、完全に適合した名前。

linkname は人間が読みやすい文字列の形式で、記録されたデータがどのリンクから集められたかを表す。

bandwidth は数値で、使用されている種類が続く。有効な種類は bps, Kbps, Mbps,
Tbps 。
prototype フィールドは記録されているインターフェースがどんなネットワークアー
キテクチャに繋がれているかを示す。有効なものは IP, DECNET, X.25, CLNP 。
network address は記録されているインターフェースの固有の数値形式のアドレスである。このアドレスの実際の形式は proto-type フィールドに示されたプロトコルに依存する。

time-zone は、データセクションの中で記録されたインターフェースの、ローカルな時間で表されているタイムスタンプに加えられるべき、時間差を示している。

tag-table はすべての集められた変数のリストである。変数名は Internet MIB の名
前に完全に適合するものである。テーブルは複数の tag を含んで良い。それぞれの

376

1992 年度 WIDE 報告書

tag は一回のポーリング及び集計期間にのみ関係づけられなくてはならない。もし 、変数が異なる期間に集められたなら、テーブルの中で一つの別のタグがそれぞれの期間毎に用いられなくてはならない。
変数は、記録されたデータの同じセット内で異なるポーリング期間で調査されたものを含んでも構わないので、それぞれの記録されたデータについてはっきりとポーリ
ング期間を関連づける必要がある。処理が終った後で、実際の期間はと比較して変化していても良く、これはのフィールドに記される。
とは、秒で示される。

periodaggregation period
initial polling period aggregation period

initial polling

集計はその前に調査されたデータの最大値を計算することでもあるので、集計の過程ではこれらの最大値を含めるためにを拡張する必要がある。収集された変数のフィールドは、前の期間からピーク時の値も含めることで拡張される。他の可能性はピーク時の値用に新しいを作ることである。未加工のデータと集められた物の総量、集められた物のピーク時の値が識別できるように、そのようなエントリーが一意に決まるような名前付けがインプリメントされる必要がある。

tag tabletag データセクション
data-section::= "BEGIN_DATA"<FS><data-field><LF>"END_DATA"

data-field::= <timestamp><FS><tag><FS><poll-delta><FS><delta-val>[<FS><delta-val>]

poll-delta ::= <digit> [<digit>]tag::= <ascii-string>delta-value ::= <digit> [<digit>]timestamp::= <year><month><day><hour><minute><second>year::= <digit><digit><digit><digit>
month::= 01 | ... | 12hour::= 00 | ... | 23
minute::= 00 | ... | 59
second::= 00 | ... | 59
digit::= 0 | ... | 9tag

データフィールドはフィールドに対応するデータが含まれている。それぞれのデータフィールドはタイムスタンプから始まり、集められたデータのの定義、その前のポーリングからの差を秒数で示している値が続く。変数の値は、カウンターtag

第 10 部

ネットワークト ラフィック統計情報の収集と解析

377

OperStatus
UTC

用には一つ前との差の値として格納され、の様なカウンターでないものには絶対値が格納される。タイムスタンプはで表され、デバイスセクションにあるフィールドは記録されているデバイス用にローカルな時間を計算するために使用される。

time-zone

4.6.2

保存に必要な容量の推定

ヘッダーセクションについてはこの例の中では含めていない。ポーリングが最大、推薦されるの変数のすべてについて用いられると仮定し 、また、それぞれの変数を文字で表した大きさが バイトであると仮定すると、以下のような計算が一年を基準とした統計データの収集と保存について行なえる。

12

ascii

8

データは以下の分類表にしたがって保存されると仮定する。

1 minute non-aggregated
15 minute aggregation period
1 hour aggregation period
1 day aggregation period
ここから次のようになるであろう

saved 1 day.
saved 1 week.
saved 1 month.
saved 1 year.

:

それぞれの集計期間毎の一つのエントリーの大きさ:

Aggregation periods
1 min

15 min1 hour1 day

Timestamp
Tag
Poll-Delta
Total values
Peak values
Field separators

14
5
2
96
0
14

14
5
3
96
96
28

14
5
4
96
192
42

14
5
5
96
288
56

Total entry size

131

242

353

464

60*24 = 1440 エントリありトータルサイズで 1440*131 = 187 Kbytes.
毎週 4*24*7 = 672 エントリが保存され、トータルサイズ 672*242 = 163 Kbytes.
毎月 24*30 = 720 エントリが保存され、トータルサイズ 720*353 = 254 Kbytes.
毎年 365 エントリが保存され、トータルサイズ 365*464 = 169 Kbytes.
全体の総数として、一年を通して 773 Kbytes 保存されると推定した。
毎日

378

1992 年度 WIDE 報告書

4.7

レポート のフォーマット

この章ではいくつかの レポートフォーマットを提案し 、これらレポートの中で使われている尺度を定義する。

4.7.1

レポート の形式と内容

ネットワークにおける長期間にわたる傾向、動向を示すには何カ月、何年もの間レポートを集める必要がある。ネットワークの振舞いにおいてやや長い期間の変化の動向を与える短期間の週間的なレポートがある。それはやや長い期間の技術的アプローチの入力として役立つ。結局、ネットワークの日々のオペレーションについての断片的なあらましを示す、日々のレポートが必要となる。
これらのレポートは次のような情報を必要とする。

 外部インターフェースの総トラフィックによりもたらされた負荷
 利用者によって分類された負荷
 プロトコル、アプリケーションによって分類された負荷
 回線やルータの資源利用
4.7.2 レポート の内容
 リンクあたりの負荷
尺度の区分

:

{ 外部インタフェース当たりの入力オクテット{ 同、出力オクテット{ 外部インタフェース当たりの入力パケット{ 同、出力パケット
目的は外部インターフェースで各々つながったネットワークのトラフィックの全体的な傾向を視覚化することにある。これは上記 つの尺度区分の各合計を棒グラフにして表すことが出来る。 時間、 日、 カ月、 年など時間的区分をいろいろ選
択して作れば良い。

11

 利用者あたりの負荷
尺度の区分:{ 利用者当たりの入力オクテット

1

4

1

第 10 部

379

ネットワークト ラフィック統計情報の収集と解析{ 同、出力オクテット{ 利用者当たりの入力パケット{ 同、出力パケット

F(n)ここでは利用者によって影響が出た負荷を（降順に）選別しておく。関数を考える。ここでは、上位 人の利用者により与えられた
トラフィックの合計のパーセンテージである。また関数は 番目にランクされた利用者によって与えられたトラフィックのパーセンテージである。

F(n)

n

(o erd)f(n) n

どんな動きをすれば 、それが利用者によって行なわれた事を意味するのかという定義は、統計が集められているサイトでローカルに行なわなければならない。
累積すればトラフィックが各ユーザー間においてどのように分割されたかを見渡すのに有益である。そうしておけば 、「何番目のユーザーにより発生したトラフィック
がどの位の割合になるか」などを素早く抽出することが可能となる。
棒グラフで各値の平均やピーク時の変化を表す方法は、ある期間内における平均値とその同じ期間内でのピークの値を計算すればよい。平均とピークの値は同じ棒の中に表す。

 資源の利用に関する報告
4.7.2.0.1

最大ピーク時の振舞いとして表された利用率 回線の利用状態はネット
ワーク負荷の情報を集めるのに用いられる。ポーリングの間隔は人間の活動の変化を十分に表せるよう注意するために、出来る限り小さくしなければならない。なぜならこれがネットワークの変化における負荷の動きの動向を表すからだ。一方、特に大きな影響を与えそうな過度の遅れに関しては間隔を小さくする必要はない。な
ぜなら過度の遅れは注目すべき影響を引き起こさないからだ。その理由は、人が一つの活動に従事し続けられる時間はだいたい 分が限度といえるからだ。そしてかなり長い遅れは彼らの作業効率に悪影響を与える。 分ごとの変化を記録するのは時間当たり二回すなわち分おきにサンプルが必要ということになる。 分間隔で集計することを勧めるのは、利用状態の変化を捉えるのにはそれで十分であるか
らだ。

30

15

30

10

ピーク時の様子を見る利用状態レポートにおいて可能なフォーマットは平均値とピーク値の合計を同じ図に表すようにする。例えばオーディオ機器と比べて見れば良い。
もしグラフがある時点での一日の合計値を示しているとすれば 、そのピークはそれらの日の中で一番混んでいる時を表している。また時間単位での合計値ならば 、そのピークは各時間における一番混んでいる
分間ということになる。

10

ある程度の時間単位でその平均や最大値を集計することで 回線の利用状態や一時的に負荷が非常に高くなることによるボトルネックになる部分の解析が可能になるだ
ろう。

380

1992 年度 WIDE 報告書
4.7.2.0.2

ピークの頻度分布により表された利用率 回線の利用状態を視覚化する
その他の方法には、 分間のサンプルを作り、サンプルと実際の負荷における頻度との比較を表すヒストグラムを作ることだ。

4.8

10

将来の発展についての考察

このメモは統計値収集作業の共通基盤を正式化するための初めての試みである。この作業の主要な指針の一つは、ベンダーとが各自のオペレーションツールでこのモデルを簡単に統合できるように、モデルを単純化しておくことにある。
また、このモデルの活用範囲や有用性をより大きく発展させたいくつかの案もある。

NOC

4.8.1

クライアント ／サーバーモデルを基にした統計情報交換システム/

この方法がより発達すれば 、 クライアント サーバシステムにおける、統計収集作業をするためのインタネットアクセスを供給するための定義が可能になる。そのような構造を心に描くと 、各はローカルに集めた様々な形の情報を提供するサーバをクライ
アントのためにインストールしなければならない。
質問的な語調を使えば 、クライアントは供給されたネットワークオブジェクトやインタ
フェース 尺度や時間の区切りを定義出来なければならないのかということになる。
をベースとしたプロトコルを使うとすれば 、サーバはリクエストデータを送らなければならないだろう。一度クライアントがこれらのデータを受けとると数多くのツー
ルを使うことで処理したり表示したりすることが出来るようになる。
統計収集サーバから
ツールのディレクトリに与えられたデータから、あらかじめ定義されたグラフを表示する、それらのタイプのグラフを補っている
ベースのツールに一つの可能性がある。他の捕捉方法としては、グラフをプリント出来るように、の出力が出来るようにすることもある。どのケースでも、以前の処理でローカルに収集されたデータを、保存できる可能性がなければならない。

NOC

TCP

,

X Window

X Window

Post Script

4.8.2 Internet 標準の MIB に含まれていない変数の追加について

Internet

MIB

尺度の分類に注目してみると、もし標準のの中で利用できれば確実に勧められる尺度がある。勧められる尺度のセットの一部を成す尺度を簡単にするため、統計収集作業を実行する範囲において必要と判断された変数を含んだ サブツリーをの中で明示する必要があるだろう。

MIB

4.8.3

詳細な資源利用に関する統計

尺度や表示方法に関する今までの紹介では興味ある分野のほんの一部でしかないが、それらはトラフィックの流れを細かい視点から見た統計値を表示するためのものである。そ第 10 部

ネットワークト ラフィック統計情報の収集と解析

381

れらの視点には アプリケーションやプロトコルを基にした割合の統計値も含まれる。今日それらの尺度はの標準ではない。
やのようなツールはこれらの情報を集めるのに使われている。

MIB

NSF

NNStat

第

5章

まとめ
92

WIDE

本報告では、 年度に行ったデータ収集および解析結果にもとづき、
インター
ネット上のトラフィックについての考察を行った。とくに今回は、国際線上を流れているの解析も行い、これらの解析から得られる情報をネットワーク管理にも利用可能である事を示した。最後に、今年度の活動の基盤の一つでもある、現在
により提案
されている
についての紹介を行った。
本年度は、昨年度までの研究結果を引き継いで、
バックボーン全域にデータ収集範囲を広げ、広域でのデータ収集系の運用を開始する。それにともない、収集したデー
タの効率の良い保存手法ならびに解析手法に関する研究に焦点をあてる。そして、今回紹介したのにもとづいて、これらの統計情報の効率の良い保存方法や解析結果の表現方法についての考察を進め、我々独自の案をに提案する等をとおして、データ保存と解析に関する国際的な協調のもとでの研究を進めていく予定である。また、現在行っている比較的長い期間でのデータ収集・解析に加えて、等に着目したリアルタイムのトラフィックデータ解析の、ネットワーク管理への応用について、による管理手法と比較しながら研究を進めていく。

ICMP

RFC

Operational Statistics Model

WIDEIETF Operational Statistics Model

ICMP

SNMP

382

IETF