第 9部
ネット ワーク管理295

第 1章
Prologue

1.1 The NetMan working group
The NetMan working group has been active in the area of network management. The
aim of this working group is to make signi cant and original contribution in the areas of
network management in particular and the Internet in general.

1.1.1 Activities during the year 1994-95
In the year 1994-95 we have mainly concentrated on development of tools and methodologies for automatically and mechanically synthesizing information from the Internet andmaking it available to network managers and intelligent applications for purposes of management, administration and operation. The result is a Network explorer which is currently
in its nal stages of research & development. The Network explorer provides the technicalmeans to draw a map of the global Internet. It also makes vital and updated network
con guration related information available literally at the users nger-tips. Continuing
our investigation into the causes and remedies of non-optimal operations in the Internet,
we have proposed some smart applications which use network con guration information.
Finally, as an important requirement for cooperative usage of the the Internet we havedeveloped an improved interface to the Network Planned outage database. It is based on
widely popular WWW-client and as such is expected to help overcome the initial reluctanceto use new procedures and technologies.

1.1.2 Planned activities for the year 1995-96
In the year 1995-96 we plan to work on the following

 Continue our research on a deployment strategy for X.500 in the Internet. This
involves populating the directory with information from the Internet with minimal
human intervention.
297

298

1994 年度 WIDE 報告書

 development of smart applications which use network information to operate eciently and optimally as far as network access and generated trac is concerned.

 polishing o the tools for cartography in the network. Following this we will attempt
to start a pilot to map the global Internet.

 Investigate the requirements of Information management and Information quality.
 Study the status and requirements for managing the bumper crop of information
servers that are sprouting all over the Internet.

1.2 Outline of the document
In chapter 2 preliminary results of our e orts to develop tools for automatically and mechanically synthesizing information from the Internet are presented. The AIMS Explorer
now scans the network using SNMP [72] for network con guration related information.
From the explored information the AIMS Explorer generates a network map complete
in all details. Apart from the visual map, which is an essential component for network
management and operations, the AIMS Explorer also generates a inventory of the network explored complete in postscript form ! The inventory consists of nodes, networks,interfaces, addresses, protocols, speeds, etc. This inventory is a valuable component for
network planning and administration.
Continuing our investigation into the causes and remedies of non-optimal operationsin the Internet, in chapter 3 we have presented an update on the results of our quest of
applications that are smart- that can make the distinction between far and near, expensive
and cheap in the network context. Though complete network con guration information in
the form of links and speeds and would suce to make some elementary judgement - very
rarely complete network con guration information is available. To take care of such cases
the possiblilty of using other information components to estimate the cost are examined.
The operation of the Internet is a cooperative e ort. No part is an island and there
is no centralized management or operation either. In such a scenario - it is important topublish and access information related to network operations. The present practice is touse mailing lists and newsgroups. Understandably, these systems have their restrictions. In
chapter 4 some of the requirements of such a system are examined and a prototype basedon one of the most popular network information retrieval systems has been proposed.

第 2章
構成情報の収集と解析

2.1 はじめにインターネットの広まりにつれて，管理や運用が複雑になってきている．そのため，ネッ
トワーク構成情報を有効に利用することが重要になっている．しかし，例えば，ネットワー
ク接続図ひとつをとってみても，その作成とメンテナンスの作業は，管理者にとって大きな負担となっており，常に新しいものに更新されているとは限らない．
本 WG では，可能な限り，汎用的なデータを標準的な枠組を用いて獲得して , それを解析して最新の構成を求めるという立場から，ネットワーク構成を把握している機器である
ルータに着目した．ルータも他のノードと同様に MIB (Management Information Base) を保持しており，それは標準的な管理プロトコル (例えば SNMP) によって取得できる．そして，その管理項目の中には，経路情報が含まれている．

2.2 構成情報
構成管理などで必要とされる情報は，以下のようなものである．

 ネットワーク要素をグラフ化 (頂点はノード，辺は接続を示す) するための接続情報．
 ノード やそれらの接続の属性 (速度，料金，プロトコル，OS，サービスなど )．
 ネットワーク要素の名前やアドレス．
 ネットワーク管理者や技術担当者の詳細．
 運用のポリシー．etc.

2.3 出力結果
前記の項目に対応する MIB を取得し，接続関係などを解析し，地図形式と表形式で表現するツールを開発した．その出力結果 (ポストスクリプト版) を以下に示す．紙面の都合上，

299

1994 年度 WIDE 報告書

300

構成情報解析ツール
MIB
SNMP
情報取得

network info

地図形式

DB

summary

ＮＥＴＷＯＲＫ
概要

表形式

図 2.1: 構成情報収集システム
いずれも一部のみを示している．(なお，これは，1995 年 4 月現在のものであり，表 2.1 に示すように，ド メインが wide.ad.jp である 31 のホストとそれらが持つ 210 個のインター
フェース情報をまとめたものである．従って，この時点で，SNMP により情報が取得できない1ホストについては，描かれていない．)
図 2.2は，ド メイン名 wide.ad.jp に関連するネットワーク構成を階層的に表したときの一番上位の図である．ここでは，ゲートウェイ間がポイント−ポイントで接続されるまでの部分をひとかたまりとし，楕円で表現している．組織の地理的情報を持っていないので，配置は機械的におこなっている．
図 2.3は，図 2.2中の jp-gate ネットワークの詳細 (階層的に下のレベル ) 図である．矩形はホスト，ホストに付属の四角はインターフェース，太線は LAN を示す．
表形式の方は，jp-gate.wide.ad.jp と wnoc-tyo.wide.ad.jp の 2 ホストについて，以下の項目を記述している．(MIB-II[73] より) システム概要．
 location．
 管理者．
 プロトコル対応．(これは，MIB が取得できるかによって判断している．)
 I/F 情報 (IP アドレス，名称，タイプ，接続先の IP アドレス/ホスト名/名称)

1 本 WG で把握している SNMP コミュニテイ名による判断

第 9部

ネット ワーク管理*--------------------------** SNMP queries sent to: (31 + + 15)**
HostsProcessed: 46**
Recd replies from: 31**
Incomplete from:**No replies from: 15**--------------------------** Elements found**Hosts : 31**
Interfaces : 210**
Networks : 92**--------------------------*Gateway
Comments*================================ =================
wnoc-tyo
SNMPOK
wnoc-kyoto-iij
SNMPOK
wnoc-nara-cisco
SNMPOK
wnoc-fujisawa-proteon2
SNMPOK
wnoc-tyo-ss2
SNMPOK
jp-gateSNMPOK
wnoc-sfc-ipc
SNMPOK
wnoc-snd
SNMPOK
wnoc-tyo-news
SNMPNORES
wnoc-tokyo-cisco2
SNMPNORES
wnoc-tokyo-cisco3
SNMPNORES
wnoc-tokyo-wellfleet
SNMPNORES
wnoc-tokyo-cisco5
SNMPOK
wnoc-tokyo-cisco6
SNMPOK
wnoc-snd-ss2
SNMPOK
wnoc-tokyo-cisco7
SNMPOK
wnoc-hac
SNMPOK
wnoc-tokyo-cnx
SNMPNORES
wnoc-tokyo-otemachi
SNMPOK
wnoc-spk
SNMPOK
wnoc-fujisawa-netblazer
SNMPNORES
wnoc-tokyo-cisco
SNMPOK
wnoc-kyoto-cisco25
SNMPNORES
wnoc-kyoto-cisco26
SNMPNORES
wnoc-tokyo-igs
SNMPOK
wnoc-tokyo-sinet
SNMPOK
wnoc-kyoto-cisco2
SNMPOK
wnoc-fujisawa-yamaha1
SNMPNORES
wnoc-fujisawa-cisco2
SNMPOK
wnoc-tokyo-netblazer
SNMPNORES
wnoc-spk-cisco
SNMPOK
wnoc-fujisawa-cisco4
SNMPOK
wnoc-kyoto-cnx
SNMPNORES
wnoc-fujisawa-cisco5
SNMPOK
wnoc-fujisawa-cisco6
SNMPOK
wnoc-tyo-satgw
SNMPNORES
wnoc-fujisawa-dnx
SNMPNORES
wnoc-nara-cisco2
SNMPOK
wnoc-nara-ss2
SNMPOK
wnoc-kyoto-cisco
SNMPNORES
wnoc-tokyo-nss
SNMPNORES
wnoc-fujisawa-cisco
SNMPOK
wnoc-kyo-ss2
SNMPOK
wnoc-hij-cisco
SNMPOKwide-sfc-gw
SNMPNORES
wnoc-kyo-ss5
SNMPOK

表 2.1: SNMP による情報収集ホスト一覧

301

1994 年度 WIDE 報告書

302

AIMS EXPLORERMay 8 18:26:41 1995

nakasu.wide

osaka.iij.n

Rtr.192.41.

NTT-osk-cis

Rtr.192.218

rins.st.ryu

wnoc-kyo-ss wnoc-hij-ci

wnoc-nara-cjoingate.jovega-s0.cis

Rtr.192.51.

cisco.san.hgw.shiga-pc

tambaent.gw

hc-entry.hi

cit-gate.cs

mjugwy.meij

wnoc-spk.wi

Rtr.202.48.

choshi.kaba

Rtr.192.31.

Rtr.192.218

kioi.cc.sop

titanet-gat

cynthia.cc.

melcogw.isl

rena.dit.cowide.nspixp

wnoc-tyo.wi

ieice.ieice

unisysgw.un

ut-wide.nc.

kanagw.kanahitwide.hit

hosei-gw.ad

nogu.gw.toh

hskgw.hitac

wnoc-snd.wi jp-gate.wid nscwide.noc

r99-s0.jais

cst_s8_gw.nlkbreth.forsoumgw.soum wnoc-tokyo-

kdd-im-ciscwnoc-ham.wi jvc-k3.jvc-

ricohwgw.ri

wnoc-hac.wi

widegw.icot

ipsj.or.jp

astecgw.ast

Rtr.202.13.

fwide.fujit

ascwide.asc

us-entry.wi

wnoc-tokyo-

tsbgw.isl.r

canon-prote Rtr.198.120

otsuka-gate

otemachi.ii

図 2.2: MIB-II より得られた WIDE ネットワーク構成図

ascwide.ascii

tsbgw.isl.rdc

hskgw.hitachi

wnoc-tyo.wide

fwide.fujitsu

AIMS EXPLORER
us-entry.wide
May 8 11:43:10 1995

nscwide.noc.n

wnoc-snd.wide
jp-gatewnoc-kyo-ss2.

cisco-sfc

wnoc-fujisa

wide-sfc-gw

wnoc-fujisa

NET.192.47.16
Rtr.192.47.

wnoc-fujisa

wnoc-fujisa

jp-entry

wnoc-fujisa

wnoc-fujisa

wnoc-fujisawa

wnoc-sfc-ipc

wnoc-fujisa

wnoc-fujisa

wnoc-fujisa

canon-proteon

melcogw.isl.m

NET.133.4.39.0
wnoc-ham.wide

Rtr.133.4.3

ricohwgw.rico

jvc-k3.jvc-vi

図 2.3: MIB-II より得られた jp-gate ネットワーク構成図

第 9部

303

ネット ワーク管理

jp-gatejp-gate.wide.ad.jp
4BSD/ISODE SNMP
Fujisawa NOC, WIDE Project
Akira Kato <kato@wide.ad.jp>

RIP2 OSPF BGP
○
○
Ver.4
133.4.11.1
le0133.4.1.1
le1133.4.2.1
ptp0

ether

133.4.11.0

wide-fujisawa-

ether

133.4.1.0

wide-jp-net

PTP

133.4.2.2
ptp0

wnoc-tyo

133.4.7.1
ptp1

PTP

133.4.7.2
ptp0

wnoc-kyo-ss2

133.4.4.1
ptp2

PTP

133.4.4.2
ptp0

wnoc-snd--ptp4PTP

202.249.12.2

hskgw.hitachi---ptp5PTP

202.249.10.123

tsbgw.isl.rdc.

--ptp6PTP

133.152.1.1

ascwide.ascii--ptp7PTP

133.160.28.1

fwide.fujitsu--ptp8PTP

133.179.213.31

nscwide.noc.ns

1994 年度 WIDE 報告書

304

wnoc-tyownoc-tyo.wide.ad.jp
4BSD/ISODE SNMPTokyo NOC, WIDE Project
Osamu Nakamura <osamu@cc.u-tokyo.ac.jp>

RIP2 OSPF BGP
○
○
Ver.4
133.4.3.2
le0133.4.2.2
ptp0

ether

133.4.3.0

wide-tokyo-net

PTP

133.4.2.1
ptp0

jp-gate--ptp5PTP

133.156.1.1

rena.dit--ptp6PTP

133.123.1.1

lkbreth.foretu

133.4.24.1
ptp7

PTP

133.4.24.2
ptp0

wnoc-spk

第 3章
最適運用

3.1 はじめにインターネットの世界は，近年急速に発展している．それに伴い，広い範囲に分散したサーバーとクライアントを扱うアプリケーションもよく利用されるようになり，ネットワー
ク利用において劇的な変化をもたらした．従来のニュース／利用者が制限された ftp(ファイル転送) などのアプリケーションは，ネットワーク層プロトコルや管理者によって予め計画された経路を使う．それに反して，gopher/ WWW/ archie/ anonymous ftp(誰でも制限なく利用可能な ftp) などは，管理者が予想していた範囲を越えてアクセスをおこなう．しかも，利用者は最適ではないサーバーをアクセスするかもしれないという問題がある．な
ぜなら，平均的なネットワーク利用者は，どのサーバーにアクセスしたらよいかの知識を持たないからである．
例えば，ある特定のファイルを探している利用者を考えてみる．archie のようなサーバー
が，該当ファイルを持つ ftp サーバーのリストを返す．このとき利用者は，archie がリス
トアップした最初のサーバーを選ぶことが多い．その結果，コスト的に最適ではないサーバーからのファイル転送がおこなわれることになるかもしれない．結局，ネットワークの成長とそのアプリケーションの普及が，ネットワークの性能とアプリケーションの利便性を損ねることになる．
そこで，2章で得られるネットワーク構成情報を利用することを前提に，妥当と思われる
ネットワーク運用のコストモデルを考察する．

3.2 ファイル転送の現状
一般的なファイル転送の手順は，以下のようになる．

1. 何らかの手段でファイル名を知る．
2. archie などの格納位置通知ツールを起動する．
3. 通知されたサーバーの中から利用者が選択する．
305

306

1994 年度 WIDE 報告書
ＦＴＰサーバー
ＡＲＣＨＩＥ
サーバー

ls-lR

ls-lR

ls-lR
．
．
．
ls-lR

図 3.1: archie システム

図 3.2: xarchie の起動例

4. ftp などのファイル転送ツールを起動する．
ここで，archie システムとは，ftp サービスを提供する各サーバーのファイルリストを収集し (図 3.1)，ファイル名で提供ホストを検索できるようにしているものである．図 3.2に，その起動例を示す．
しかしながら，前記 2の段階では，コストによるソーティングなどの処理は一切おこなわれず (図 3.2の例では，アルファベット順で通知されている)，どのサーバーからファイル転送をおこなうかは，利用者が無作為に決めているのが現状である．
求めているファイルが広く分布している場合は，利用者が近くにあることを知っているサーバーに存在する可能性が高く，それを選択すればいいであろう．しかし，近年，コンピュータ化が進み，あらゆる種類の情報が電子化されるようになっている．このような状
況では，ひとつのサーバーが全ての情報を保持することはないであろう．よって，利用者がよく知っているサーバーが archie のリストに掲載されるとは限らなくなり，適当ではな
いサーバーへのアクセスを発生させることになる．

3.3 実際の経路

第 9部

ネット ワーク管理307

前節の問題を回避するためには，どれがネットワーク運用的に最適かを判断することが必要になる．そのためには，ネットワーク構成を詳細に把握していなければならない．しかし，実際のふたつのホスト間の経路は，それぞれのホストとネットワーク組織との接続
やそのネットワーク組織内の運用形態によって決定されるもので，簡単にはわからない．
例えば．仙台のある利用者の求めるファイルが，東京大学と北海道大学に保持されていることが，archie が出力した情報のド メイン名からわかったとする．利用者は，直観的に，それぞれの地理的距離にそれほど差はなく，アクセス者が少なそうであるという理由から，北海道大学へアクセスするかもしれない．しかし，それぞれのある時点での実際の経路は，
これは，traceroute というツールを利用して得られた AIC ( 仙台) のゲートウェイから北海道大学／東京大学の ftp サーバーまでのそれぞれの経路である．地理的感覚とは異なる
接続関係になっているが，一般の利用者は，このことを認識していないであろう．
そこで，2章で得られる情報を利用することを考える．
traceroute tonameserv.sys.hokudai.ac.jp
1 wnoc-snd-ss2.wide.ad.jp
2 wnoc-snd.wide.ad.jp
3 jp-gate.wide.ad.jp
4 wnoc-fujisawa-cisco5.wide.ad.jp
5 wnoc-tokyo-cisco5.wide.ad.jp
6 wnoc-tyo.wide.ad.jp
7 wnoc-spk.wide.ad.jp
8 cynthia.cc.hokudai.ac.jp
9 nameserv.sys.hokudai.ac.jp
10

ftp.u-tokyo.ac.jp
wnoc-snd-ss2.wide.ad.jp
wnoc-snd.wide.ad.jp
jp-gate.wide.ad.jp
wnoc-fujisawa-cisco5.wide.ad.jp
wnoc-tokyo-cisco5.wide.ad.jp
wnoc-tokyo-cisco2.wide.ad.jp
ut-wide.nc.u-tokyo.ac.jp
hongogw.nc.u-tokyo.ac.jp
130.69.127.101
ftp.u-tokyo.ac.jp

図 3.3: AIC(仙台) から北海道大学／東京大学までの経路

3.4 コスト 評価モデル
本稿では，ネットワークの効率的運用の尺度であるコストをネットワークに対する負荷という観点から，パケットが存在する時間を基準として考察する．これを求めるには，全てのネットワークの接続やその速度などがわかればよいのであるが，現実には制限がある．
例えば，SNMPv により情報を得るには，コミュニティ名という一種のパスワードが必要になるが，これはネットワークの管理や運営に関わることであり，誰か (何らかのツール)
が，全てのネットワーク組織のコミュニティ名を知っていることを前提にすることは事実上不可能である．

1994 年度 WIDE 報告書

308

AIMS EXPLORER
Apr 13 14:32:10 1995

BUCT-NET-3717 KREN-GATEWAY-2563

TOPIC-2503

CAREN-NET-2896
TRAIN-2502

NCA5-2504

TISN-2501

CSI-2506

JOIN-2498

KARRN-2508

IIJ-2497

INFOWEB-2510
WIDE-2500
CORE-2511

MESH-2518

IMNET-2513
CICC-2522
SINET-2907

JPNIC-2515
TokyoNet-2521

GDBnetJP-2517

HEPNET-J-2505

図 3.4: BGP-MIB より得られた AS 構成図

そこで，詳細な接続や速度情報を取得できない部分を別に考慮し，次の評価式を定義する．

cost = costin + costout(3:1)

ここで，costinは，詳細な接続情報を取得可能な範囲内のコスト，costoutは，その範囲外のコストである．
第 1 項は，ネットワーク・ライン上に存在する時間とゲートウェイなどの接続点での処理時間の和である．転送ファイルの大きさがメガバイトのオーダーであるとき，現在のネットワーク組織間の接続速度 (〜Mbps) と接続点での処理時間を考慮すると，後者は前者に比べて非常に小さいと考えられるので，結局以下のようになる．(文献 [74] より)

costin 'n K
X
i=1 vi(3:2)

ここで，n は始点から終点までの接続点の数，viは第 i 番めの接続の速度，K は定数である．
MIB-II からゲートウェイ間を接続するインターフェース速度 ( ifSpeed) が得られるので，上式は計算可能である．
なお，この項目は各ゲートウェイで SNMP を処理するプログラムの実装や運用上の問題
から，実際には有効な値がセットされていないことがある．この場合は，インターフェー
ス・タイプ ( ifType) から推測される速度を概略値として用いることが考えられる．また，
OSPF-MIB[75] の Metric (100Mbps を基準にした値) を用いてもよい．(2章では，MIB-II

第 9部

309

ネット ワーク管理

のみからの解析結果を示したが，OSPF-MIB /BGP-MIB[76] を解析して，それぞれ構成地
図を出力できるようになっている．)
第 2 項については，例えば，目的のサーバーが複数の AS (Autonomous System) を越えて経路される場合は，BGP の情報を利用する．BGP-MIB により，ネットワーク番号と AS の関係を求めることができる．例として，図 3.4に，WIDE のゲートウェイ (wnocsnd.wide.ad.jp) から得られた AS 構成を示す．経路制御方法 (海外へは，デフォルト ) の関係から日本の構成 (中国と韓国の一部を含む) が得られている．
これにより，目的のサーバーまでの AS 経路がわかる．例えば，京都大学の archie サー
バーは，ネットワーク番号が 130.54.0.0，AS が 2504 (NCA5) であり，高エネルギー物理学研究所 (名古屋大学内) のある ftp サーバーは，ネットワーク番号が 202. 13.193.0，ASが 2505 (HEPNET-J) である．よって WIDE (AS が 2500) を経由する場合，後者への方が AS をひとつ (SINET) 多く通過することになる．実際，WIDE バックボーンを利用する
AIC(仙台) におけるファイル転送時間や ping による RTT ( Round Trip Time) は，後者の方が平均的に大きく1 ，各 AS の構成規模にそれほど差がないときは，通過 AS 数を評価基準とするのは妥当であると思われる．

接続速度
接続速度未設定
詳細構成不明構成情報取得可能範囲

K/ v iK/ v j利用者

ftp
serverAS

図 3.5: コスト評価モデル

以上の考察をまとめたモデルを図 3.5に示す．点線で囲まれた部分は，詳細な構成情報を取得できる範囲を示す．なお，利用者が直接に構成情報を取得できる立場になくても，ネッ
トワーク運用組織 (プロバイダ ) から情報を提供されるという状況を考えると，本モデルは一般的なものと言える．
1 経路の安定性や packet loss，利用状況によって変動がある．

310

3.5 まとめ1994 年度 WIDE 報告書

ネットワーク運用に関してコストを考慮する必要性を述べ，構成情報を用いて経路を評価する方法を示した．
今後の検討課題を以下に挙げる．

 本手法の定量的な評価．
 詳細情報を取得不可能な部分の他の評価方法．
 料金などの新たなコスト情報の収集と評価方法．
 archie の出力を本手法のコスト順にソーティングするツールの開発．

第 4章
ユーザフレンド リィなネット ワーク停止予定情報
データベースシステム

4.1 はじめにあるネットワークに対しアクセスが不可能となった場合，それが障害によるものなのか，
またはあらかじめ予定された停止によるものなのかを切り分けることは，インターネット
での障害解析で重要である．
そこでネットワーク停止予定情報を把握しておくために，我々は停止予定情報をデータベー
ス化し一元管理を行い，常時検索ができるシステムのプロトタイプ [77] を試作し実験を行なって来た (前システム)．
そして今回より広範囲な利用を目指して，WWW クライアントソフト (Mosaic) の利用，入力データの削減を施した，新しいネットワーク停止予定情報データベースシステムについて検討を行なった．
本章ではこの新ネットワーク停止予定情報データベースシステムに関する報告を行なう．

4.2 前システムと問題点
現在のネットワーク停止予定情報の通知はニュースグループ "jp.inet.trouble" にて行なっている．しかしネットワークの大規模化に伴い件数が増加傾向にあり，停止予定時期も数週間後から数時間後のものまであり，必要とする停止予定情報を得るのは困難になって来ている．
そこでこの停止予定情報をデータベース化し一元管理を行い，常時必要な情報が検索できるシステムが望まれていた．
このような問題を対処するため我々はネットワーク停止予定情報データベースシステム(前システム) を試作し実験を行なって来た．
以下はその方針である．

1. 各ネットワーク管理者自身があるデータベースに対し停止予定情報の登録，更新，削除処理が行なえること．

311

1994 年度 WIDE 報告書

312

2. ネットワーク停止により影響を受ける可能性のあるすべてのユーザから検索が可能な
こと．

3. 上記 1,2 の各処理がデータベースサーバ側の人手を介さないこと．
4. 移植性が高いこと．
またアクセス方法として以下の方法が考えられた．

1. データベースサーバのホストにログインして直接操作する方法．
2. サーバ・クライアント方式で直接遠隔操作する方法．
3. 電子メールを利用して間接的に遠隔操作する方法．
この内，影響を受ける可能性のあるすべてのユーザからアクセスできることに重点を置き，
電子メールを利用する方法を採用した．
しかし実験するにあたり，以下の問題が出てきた．

1. 通知管理者が停止予定情報を SGML[78][79] 文書型で記述し電子メールにて送信しなければならず，不便さが感じられた．

2. 入力データ項目数が多く，わずらわしさが感じられた．
今回この問題を解決するために，前システムのユーザインタフェースを見直すこととし検討した．

4.3 方針と実現方法
前システムの問題を解決し操作しやすい便利なシステムを実現するために，以下の方針
で検討を行なった．

1. 管理者が SGML のようなある定まったフォーマット形式によりデータ入力を行なうのではなく，単なるデータだけの入力とする．

2. 管理者から入力してもらうデータ項目を最小限とする．
これらの方針を考慮し，次の方法により実現した．

1. 現在のネットワークにおいて一般に広く知られかつ多く利用されおり，またネット
ワークを介しハイパーテキスト機能を持っている WWW クライアントがあり，これを利用する．そして HTML 文書に FORM タグで入力フィールド などを作成することで登録等を WWW のクライアントソフトからデータ入力やマウス操作で行なわれるようにする．

2. 一部の入力データにネットワーク上で提供されている情報 (whois プロトコルで得られる情報) を利用する．

第 9部

ネット ワーク管理

4.4 システム概要
4.4.1

313

データ構成

図 4.1にデータ項目を示す．
なお入力文字は特に制限は無いが，必須項目記入や" 停止開始時間"，" 停止終了時間" 項目に関する時分 (0 23 時，0 59 分) のチェックを行なう．

a) 登録番号（例： 1234）b) パスワード（例： 5678）c) 停止開始時間（例： May 10 13:00 1995）d) 停止終了時間（例： May 10 15:00 1995）e) 停止システム名（例： aic.co.jp）f) 停止システムIP（例： 150.80.0.0）g) 停止影響システム名（例： tohoku.ac.jp）h) 運用責任者（例： 木村 行男）

i) 所属組織（例：（株）高度通信システム研究所）j) 電話番号（例： 022-279-3310）k) FAX番号（例： 022-279-3640）l) 報告者Mail（例： miura@aic.co.jp）

図 4.1: データ構成

4.4.2

機能構成

図 4.2に初期画面を示す．機能として登録，更新，削除，検索がある．

 登録

図 4.3に登録画面を示す．

管理者はネットワーク停止予定情報を登録する．入力するデータ項目は " 停止開始
時間", " 停止終了時間"," 停止システム名", " 停止影響システム名"," 報告者 Mail" であり，" 停止影響システム名" 項目以外が必須項目である．この内 " 停止システム名"をキーとし，whois プロトコルを利用して『ド メイン情報』を得る．この『ド メイン情報』から以下の情報を収集する．
ア) 使用 IP アドレスイ) 運用責任者ウ) 組織名---> f) 停止システム IP---> h) 運用責任者---> i) 所属組織

314

1994 年度 WIDE 報告書

図 4.2: 初期画面

図 4.3: 登録画面

第 9部

ネット ワーク管理

315

次にこの " 運用責任者" をキーとして，再び whois プロトコルを利用し『個人情報』
を得る．これより以下の情報を収集する．
エ) 電話番号オ) FAX 番号---> j) 電話番号---> k) FAX 番号

なお" 停止システム名" が whois プロトコルで得られる情報から得られない時は，管理者が直接停止予定情報を入力することになる．
これら管理者が入力した情報と whois プロトコルで得られた情報から収集した情報とが登録され，データベース化される．
登録完了後図 4.4の様な登録内容と" 登録番号"，" パスワード " が電子メールにより通知される．この" 登録番号"，" パスワード " は停止予定情報ごとに発行され，その停止予定情報の更新や削除時に必要となるので管理しておかなければならない．

ネットワーク停止予定入力要求 は正常に実行されました．
Mail により登録内容及び，登録番号とパスワード番号を示します．
これらの番号は予定の修正や消去を行なう場合に必要となりますので，保存して下さい．
御協力ありがとうございました．

＜停止開始時間 ＞： May 10 13:00 1995
＜停止終了時間 ＞： May 10 15:00 1995
＜停止システム名 ＞： aic.co.jp＜停止システムIP ＞ ： 150.80.0.0＜停止影響システム名 ＞： tohoku.ac.jp＜ 運用責任者 ＞： 木村 行男＜ 所属組織 ＞：（株）高度通信システム研究所＜ 電話番号 ＞： 022-279-3310＜ FAX番号 ＞： 022-279-3640＜ 報告者Mail ＞： miura@aic.co.jp＜ 登録番号 ＞ ： 5674
＜ パスワード ＞： 1411

本システムに関するお問い合わせはまでお願いします．

outagedb-admin@aic.co.jp

図 4.4: 登録完了通知例

 更新

入力項目は" 登録番号"," パスワード " の他に更新する項目である．更新は " 登録番号"，" パスワード " がキーとなり情報をサーチし，該当ファイルの指定項目を更新する．なおこの時にも更新完了後に更新内容と新たに発行される" 登録番号"，" パスワード " が電子メールにより通知される．

1994 年度 WIDE 報告書

316

 削除

削除での入力項目は " 登録番号"," パスワード " だけであり，これらがキーとなり情報をサーチし，該当情報を削除する．

 検索前システムと同様に，検索は日時項目以外の指定項目に対し正規表現のパターンマッ
チを行い，英文字は小文字・大文字に関係なく検索可能である．また複数の項目を指定し検索を行なう場合は "and" で検索を行なう．日時に関しては指定時間範囲内に停止予定時間の一部があれば一致したこととする．
図 4.5は検索した結果例である．

図 4.5: 検索結果例画面

4.5 おわりに本システムでは whois プロトコルで得られる情報と WWW クライアントソフトの利用に
より前システムのユーザインターフェース部の検討を行なった．これにより管理者のデー
タ入力項目の削減，処理作業の軽減を計った．
特に WWW クライアントソフトを利用したことでネットワーク停止予定情報システムのデータ入力操作が向上され，使いやすい，見やすいものとなった．
今後の課題として以下に示す．

第 9部

ネット ワーク管理

1. 備考項目の設定．
2. 古い停止予定情報の処置．
3. 付加サービス機能の充実．
以上の課題を検討し，本システムの公開を目指すつもりである．

317

318

1994 年度 WIDE 報告書