第 11 部

ネット ワークマネージメント445

第 1章
序論

1.1

はじめに

計算機の進歩にともないコンピュータネットワークが脚光を浴びてきた。これはそもそも大型計算機ほどの処理能力はないが、システムを分散させて持ち、それぞれのシステムを各々がアクセスするという、ワークス
テーションの普及とともに生まれてきたものである。ワークステーション
は処理速度の速いマシンとして利用するに当たっては、ユーザの要求を満たす場合が多い。ワークステーションを単なる処理速度の速いパソコンとして用いるとすると、これはそのユーザにとっては、大変便利でかつ効率的なマシンとなる（ 但し 、価格の面を考えると個人購入は非常に難しい）。
しかし 、ワークステーションはパソコンではない。ワークステーションはシステムを分散させて持ち、それを共有して使うことをサポートしたマシを走らせて、他のマシンはンである。例えば 、あるマシン上でそのをアクセスする、といった具合である。従って、ワークス
テーションの利用を考えた時は、ネットワークを無視して考えることができなくなるのである。すなわち、ネットワークを介しての利用ができるという意味で、ワークステーションの価値があるとも言える。

JSERVERJSERVER

さて 、そのネットワークも、時代とともにどんどん広がっている。もともとは自分達で使うシステムを一つのネットワーク上に分散させて利用が中心であった。それが 、各々のするというをつないで、さらに大きなネットワークができるようになった。そうすると、さらに多くのシステムを利用できるという点からは、ワークス
テーションをより有効に活用しているということになるが 、逆に一つのシステムをより多くの人から使われているということにもなる。そのことが問題発生の原因となることもある。例えば 、各々が同じシステムをアクセ
スすればそのシステムを載せているマシンの負荷は、自ずと高まる。また、様々なシステムを皆がアクセスしにいけば今度は網自体の負荷も上がってが中心の世界では、ユーザの数もおおよそ予くる。これらの問題は

LAN

LAN(Local Area Network)

LAN

447

448

1989 年度 WIDE 報告書

測ができたり、網としても効率の良いイーサネット等を用いていたことで、をつなぎ合わあまり気になることはなかった。ところが、現在ではせて大きなネットワークを作り、そのネットワークを一つのポリシによって管理し 、そして、そのポリシを持ったネットワークをつなぎ合わせている状態である。そしてそのネットワークは、国家間をまたいでものアクセスが可能となるバックボーンを構築するまでに至っている。

LAN

このような広域のネットワークでは、網の種類も様々で、かつ経路に関しても一通りとは限らない。こうなると今までとは異なる新たな問題が生じる。例えば 、どこかの網が切れてしまったとか、途中のどこかのゲート
ウェイが落ちてしまって突然遅い経路を通ることになってしまったという問題がある（但し 、これらの問題は自分の組織内でよりも、自分の所属する組織を越えた相手と通信をする時、さらには他の組織を介してより遠くの組織と通信するような場合に特に問題となる）。また、組織の管理者にとって通信可能な他の組織の表玄関、すなわち外とつながっているゲート
ウェイの情報を認識していることは、自分の組織外で起きたことに対処す
る時に大変役に立つ。
さて、これらの問題を認識し 、さらにはより良い方法で対処することは、今後のネットワーク運営にとって貢献すると考えられる。実際の通信はある経路を通って行なわれ、またどこかで起きた問題も経路情報を通して知ることが多い。しかし 、現在の経路制御では、自分のマシンが、 どこかの経路が切れた 、 マシンが落ちて通信不可能になった 、ということを認識するまでには時間がかかる。そこで、本論文では、まず最初に自分からデスティネーションまでの経由したゲートウェイの情報を持つ。それから、そのデスティネーションが生きているかど うかの応答要求を出し続ける。そこで、もしその応答要求が返ってこなくなったらどこが切れて、あるいはどのゲートウェイが落ちて通信できなくなったのかを調べる。そのために途中の全てのゲートウェイに応答要求を出す。その結果どこの経路が切れたかを突き止める。そして、その故障箇所を知らせる。以上のことをする経路診断システムについて述べる。これにより、経路状態の遷移の早い認識を実現した。

" \

\

"

1.2

背景

1.2.1

研究対象としてのネットワーク

本研究で対象とするネットワークは広域分散環境ネットワークである。
自治システム をつな
広域分散環境ネットワークとは、ぎ合わせたネットワークのことをいう。
をつなぎ合わせ大きなネット

autonomous system(LAN)

第 11 部

ネット ワークマネージメント

449

ワークを作り、そのネットワークをあるポリシによって運営しているネットと呼ぶ。例えば慶応大学は一つのワークをと考えることができる。そのような内のネットを対象にするわけでもない。ここでは、ワークや、間を結んだネットワークを研究対象に考える。
内ネットワークの場合、管理者がそのネットワー
クの構成を理解していて、問題が起きた時にそれを調べて修復することができる。しかし 、広域分散環境の場合、実際どこで問題が起きているのかを検知することが困難であり、さらに物理的にも遠隔地で存在しているので修復も困難である。
従って、ネットワークを介した問題が重要になってくる。つまり、自分で直すことができなかったり、自分でログインできなかったり、そういう状況で問題が起きた時も、管理者はできる限りの環境をエンド ユーザに提供しなければならない。だからこそ、それぞれのネットワークの状況を知っておく必要がある。

systemautonomous system
LANautonomous
autonomous systemautonomous systemautonomous system

1.2.2

ネットワーク管理の前提

ネットワークを運用する管理者の義務は、エンドユーザにとってネット
ワークを全く意識せずにネットワークを利用できるような環境を提供することである。どこかで問題が起きたということなど 、エンド ユーザはまっ
たく気にしないでネットワークを利用できるということである。つまり、広域のネットワークを運用する場合に出てくる問題に速やかに対処して、問題を解決することとなる。広域ネットワークを運用する上で起こりうる問題には、

 どこかのゲートウェイが落ちた、
 どこかの網が切れた、などがある。これらの問題が生じても、ネットワークを円滑に利用できるような環境を提供しなければならない。ユーザがネットワークを意識せず
ネットワークを利用できるようにシステム的に支えることがこのような広域ネットワークの理想的な運用である。
更に、その条件の下でできる限りの環境を提供しなければならない。広
域ネットワークは状況毎に提供し得る環境が全く異なってくることもあり、もし提供できる環境が低性能なものだとしたらそのことをユーザに知らせなければならない。また、その状況下で最大の環境を提供しなければならない義務もある。つまり、異なった状況毎にそれに応じた機能が提供でき450

1989 年度 WIDE 報告書

なければならない。そうなってくると、ネットワーク管理者は自分の管理するネットワークだけなく、自分のネットワークとつながっているネット
ワーク、すなわち手の届かないネットワークの状態も常に注意して見ていなければならない。それは、直接つながっているネットワークだけでなく、ネットワークを介して到達可能なネットワークすべてである。
ユーザにその時の条件で実現できる最大の環境を提供することがネッ
トワーク管理の最終目標である。ネットワーク管理者はこのことを常に意識してネットワークを運営する必要がある。

1.3

本研究の目的

一口にコンピュータネットワークといっても、その中で持ち上がる問題は様々ある。そこで、今それらを以下のように大別してみる。

 アプリケーション等の、ネットワークを利用する上の技術的な問題、
 通信をささえるネットワーク管理の問題、
 ネットワークを作り上げている様々な網自体の問題、
本論文では、その数ある問題の中から、ネットワークが円滑に運営されかつ使用されるために、ネットワークの管理的側面から生じる問題を取り上げた。特に、経路情報に注目し 、動的に変化する経路を動的に監視するシ
ステムを提案する。
内だけを考え現在の経路は管理領域内、すなわちても、現在利用されている経路を調べることはできるが、どんな経路が利用可能なものとして潜在しているのかはわからない。もちろん、管理者は自内のネットワークの状態を把握し 、分の内のネットワークの安定を保たなければならない。しかし 、問題が生じた場合、それがどこで生じたのか、どのような問題が生じているのか
内では、そのネッを調べなければならないのである。
トワークについての状態を把握しているという理由からその原因を突き止めやすい。ところが 、それが広域なネットワークになるとその原因の究明が困難になる。そこで、その原因究明、及び 、ネットワークの状態保持のために経路診断システムが必要なのである。
ユーザの立場から見るとどのような経路を通ろうとも、正しく通信できれば良いかも知れない。しかし 、そのような通信サービスを提供するには、現在の経路、或は経路が変わってしまった原因を、そのサービスを提供する側が認識していなければならい。また、今後予想されるユーザ側か

autonomous systemautonomous systemsystemautonomous

autonomous system

第 11 部451

ネット ワークマネージメント

らの要求として、自分自身で指定した経路を用いて通信したいという要求が生じるかも知れない。その時も、その要求に従った経路制御が必要になると考えられる。
というプロトコルを中心に行なわれ更に、現在の経路制御はていることに注目する。このプロトコルを用いた経路制御を行なうと、実装上覆いきれないものがある。これは、経路制御の中でも経路が切れたとはその実装上、経いう情報について、スポットを当てた場合である。
路についての不利な情報はゆっくり伝播するという特性を持っている。しかし 、ネットワークが広域化し 、複雑化すると、ある経路は絶対切れてはによる情報の伝達をまって、困るといった要求も出てくる。この時、それから対処するのでは遅過ぎることになる。経路が切れたら直ちに突き止めて修復しなければならないかも知れないし 、バックアップ経路があればすぐつながなければならないかも知れない。未然に防げるものであればによる順次防がなければならない。従って、ここで必要となるものは的な情報ではなく、即時調べるような積極的な検索によって獲得される情報である。これによって、事態の悪化を防ぐことができるかも知れないし 、状態の早い立て直しにも役に立つかも知れない。
以上の理由から経路情報を認識すること、更には経路が変更された原因までを突き止められることが必要といえる。そこで、本論文では現存す
るプロトコルからどのような情報が得られるのか、それを利用した経路制
御の現状、及び積極的な検索による故障部分の発見を含んだ、経路診断システムの設計と評価について述べる。

RIP [19]

RIP

RIP

RIP

1.4

本論文の構成2

本論文の構成は、第 章で現状のコンピュータネットワークと、ネット
ワークマネージメントについて述べる。現在のネットワークの状態や、現在用いられている経路制御のためのプロトコル、更には現存するマネージ
メントシステム、そして、それらの基に生じる問題点について述べる。第章では、問題点に対するアプローチを述べる。第 章で、システムの設計について説明する。第 章でそのシステムの実装、及び評価を行ない、第 章で本研究の結論と、今後の課題について述べる。

3

6

5

4

第 2章
コンピュータネットワークとネットワークマ
ネージメントワークステーションの発展にともないコンピュータネットワークが盛んに論じられるようになってきた。コンピュータの世界にネットワークという新しい技術が導入され、そのことによって、エンドユーザ側、管理者側、等から様々な要求がなされるようになった。その要求に答えながらネット
ワークを運営していかなければならない。
ネットワークを運営するという問題を考えていく上で、ネットワークマ
ネージメントという概念が生まれた。これは、広域ネットワークを円滑に運営するために人間の手によって行使している部分のバックアップを、少しでもコンピュータにサポートさせようとするものである。今後、更にネットワークが複雑化され、広域化されると、ユーザにとってはネットワークの利用の範囲が広がりとても便利になる。しかし 、それだけネットワーク
ユーザが多様化することに備えるため、管理者はより細かくネットワーク
を管理し 、運営していかなければならなくなる。

\

この章では、まず現在の広域分散ネットワークについて、 今はどのような構図でできているか 、 管理の単位は何か 、 管理のあり方はど うかについて述べる。次に、ネットワークを管理するためのシステムとして、
現在どのようなものがあるのかについて述べる。

" \

2.1

" \

"

現状のネット ワーク

LAN

現状のネットワークはイーサネットを用いた中心のネットワーク
から、それらが複数つながった複雑なネットワークになっている。この複雑なネットワークは、一つのポリシに基づいて管理されている。このように、複雑につなぎ合わされたネットワークが、ある一つのポリシによって自治システム と呼ぶ。更
管理されている組織を、に、現在のネットワークをそのようなど うしを結び

autonomous system ()
autonomous system452

第 11 部453

ネット ワークマネージメント

付けて、より広域なネットワークが築き上げられている。現在広域なネッ
トワークは、日本各地から、更には、国家間を結んだネットワークにまで至っている。
2.1.1

WIDE 広域分散環境()
autonomous system

現在の広域分散環境は図 Figure 2.1 のようになっている。現在の広域環境ネットワークの管理は、それぞれのの管理者が広域ネットワークのよりよい利用環境を提供できるように、協力しながら思考錯誤で行なっている。その第一歩として、まずは確かなバックボーン作りをしている。なぜなら、日本における広域ネットワーク環境というものは後から作られたものだからである。
が中心になって、コンピュータネットワー
アメリカではクの要求、あるいは利用を予想してネットワークが構築された。従って、その発展のしかたは、まずバックボーンとなるべきネットワークがあって、そのネットワークを中心に広域ネットワークを構築した形になっている。ところが 、日本の場合はそれぞれのネットワークが存在して、その上に、それらをつなぎ合わせる広域のネットワークを構築するという形になっている。このことによって、逆に現在のネットワークのような複雑な形になったともいえる。
また、実際につながっている組織間を接続する網の能力に違いがある。
と更に、モデムを利用したダ イアルアップによるアクセスや、
いった新しい媒体の加入を考えると、今後更に複雑なネットワーク様相を呈していくと予想される。
この広域ネットワークを運営していく上で、様々な要求、問題が生じる。例えば 、ARPAnet [1]ISDN [91]

 遅延、
 輻輳、
 バンド 幅、 優先権、 到達可能性、
 信頼性、などがある。これらの問題は、やはりネットワークの広域化によってクローを中心としたネットワークでは、意ズアップされている。なぜなら、

LAN

454

1989 年度 WIDE 報告書

US Internet
512 kbps

#

ハワイ大学

"
22

22
% ##
KABA
SONY
リコー
%

%





!
!
!
!
%
6 

! %
!!!!
% 
? 

 !!!!!



京都WNOC

,22
2  , 

東京WNOC

!

慶応大学




 

青山学院大学
000000 



東京大学




 6


 



SRA
KDD 研究所
電総研

 
X





y XXX
6
XX
?  




Xz






 


大阪大学



6
?
6
?

京都大学




6
?
6
?


九州大学




名古屋大学




 

東京工業大学

6
?
6
#?



理研




KEK

 

? 学情ネットワーク
6
? 

- : 9.6 kbps

 

2.1: WIDE 広域分散環境: 64 kbps: others



6
? 




NACSISRD 東北大学



"
!

: autonomous system図第 11 部

455

ネット ワークマネージメント

識する必要のない問題も含まれているからである。広域ネットワークをより便利かつ、有益なものにするには、これらの問題を解決しなければなら
ない。

2.1.2

autonomous system(自治システム)

autonomous system とは、イーサネットによって結ばれたネットワー
クがいくつもつなぎ合わされてできた複雑なネットワークが、ある一つのポリシによって管理されている組織のことである。ここで、もう少し具体とは、経路制御の目的のために、単的に定義すると、
一の管理権限により制御されるネットワークとゲートウェイの集合のことをいう。従って、例えば 、日本国内を考えてみれば 、各大学 慶応、東大、東工大、等 とか、一つの会社 あるいは、その会社の中の研究所 等が、そと考えられる。その間を様々のなポリシを反映させながら 、つなぎ合わせることによって現在の広域分散環境が築き上げられている。

autonomous system)autonomous system(()
autonomous systemautonomous systemという概念が必要かというと、それはでは、なぜ
各々ポリシの違った組織をつなぎ 、その出来上がったネットワークを円滑に運営していくことを考えた時に必要となる。つまり、各々のはあるポリシによって管理されていて 、ネットワークを運営する側は、その間のネットワークの状態を保持できれば良い、ということになる。すなわち、ネットワークを階層的に管理できるのである Figure 2.2 。この、ネットワークの階層的な管理を考えた時、の概念が必要になる。

systemautonomous

autonomous system()
autonomous systemautonomous systemの点から見ると、
さて、現在の広域ネットワークをの内のネットワークと、外のネットワークとに分けて広域分散環境というものは 外 の考えられる。すると上述のネットワークである。内側は、単一の管理権限によって経路制御が行なわれているのに対し 、外側は、それぞれの管理権限の集合によって経路制御がなされることになる。外側が様々な媒体によってつながっていて、その媒体によっても性能が異なる。

autonomous system

WIDE

autonomous system

[29]

\ "

というのは一つのポリシによって管理
このように、外のネットワー
されているのである。このポリシが、クと通信を行なう時の、自分のネットワークを表わす大事な要因ともなるのである。

autonomous system456

1989 年度 WIDE 報告書

A
A

A
AA

CC
C

44 4
4
4

CC

US Internet






!!
!
!
!! 

@ aaaa
@@ 
aaa

AS 
AS H
AS
AS
H
 
 

0 @
1
0
@@
0
0
@@
0
0
@
LAN

LAN

管理ポリシ

AS: autonomous system
図LAN2.2: ネットワーク管理

第 11 部
2.1.3

ネット ワークマネージメント

457

管理ポリシ

autonomous system

広域分散環境に着目した場合、そのの管理ポリシがネットワークに大きな影響を与える。ここでは 、管理ポリシとは何か、それがネットワークにどのように反映されているかを述べる。
管理ポリシは具体的に、

 autonomous system 内の情報で外に知らせるものに制限をつける、
 autonomous system 内の管理はその外とは独立に行なう、
 送り出すパケットに優先権をつける、
 入ってくるパケットに制限をつける、

autonomous systemの等の自分の入ってくる、或は出ていく情報にその考え方を盛り込んだものである。また、このような政治的な要求だけでな
く、性能的な要求もある。例えば 、

 速い通信が可能なら通信したい、
 混んでなければ通信したい、といったマシンや網自体に依存した要求である。これらも、体外的な要求のポリシの一つと考えることもでと考えれば 、そのきる。
このポリシは経路決定のシステムに反映されている。例えば 、外に向かってアナウンスするとか、入ってくる情報に制限をつける、というのはというシステムによって反映されている。また、性能的な要求をサポートするシステムはまだないが、結局それらが直接影響するものは経路決定である。つまり、ポリシを行使しながらネットワークを運営していき、かつネットワークを効率的に保持するために、経路決定に依存した要求を満たしていかなければならない。
以上のように、ポリシと経路が密接に関連している。

autonomous system

gated [18]2.2

ネット ワークマネージメント

autonomous system

現在の広域ネットワークをのつながりと見ると、内ではその組織のポリシに基づいた管理がなされる
各必要がある。しかし 、現状は、管理者が自分の 手 で作業をしなければならない。その管理をマシンに依存したシステムとして実現したものがネッ

autonomous system

\ "

458

1989 年度 WIDE 報告書

トワークマネージメントシステムである。ネットワークが広域化していく
ことにより、自治システムのポリシに従った管理が必要となる。また、広域化することにより、エンド ユーザ、或は、管理者からも様々な要求が出るようになった。例えば 、

 ネットワークの安定性、
 通信の高速性、反応性、
 各 autonomous system の機密保護、
 到達可能性、
 ネットワークの負荷 (網の負荷、マシンの負荷) 、などである。これらの、ポリシや、要求を一つ一つ管理者の手によって応えていたのではもう対応し切れなくなってきている。そこで、ネットワー
ク管理のためのシステムが必要なのである。
しかし 、マネージメントシステムの開発はまだまだ発展途上で、十分な供給にまでは至っていない。既存のシステムはまだ広く利用されておらず、利用も複雑である。基本的には今ある情報を管理して、要求に応じてその情報を伝播するというアルゴ リズムである。ネットワークの状態を自分から積極的に調べに行くわけではない。その意味では、まだ問題が残っている。しかし 、マネージメントシステムに目を向け、管理に必要な情報をデータベースとして保持し 、要求に答えるというだけでも、緊急時以外でのネットワーク管理には非常に役に立つ。本論文では 、 できるだけ緊急 ということにも目を向け、経路情報に限ってはいるが、その要求に答えるシステムを構築する。

\

"

2.2.1

現存するマネージメントシステム

SNMP [25]SGMP [26]ここでは、を中心に、更にその前任者であるをあげる。どちらも、基本的には同じアルゴリズムで作られている。あるゲー
トウェイ、あるいはホスト上にデーモンをおいて自分のデータベースを持
つ、そして、権利のあるゲートウェイあるいはホストがその情報を得る。
それによって、知りたい情報を伝播しようというアルゴ リズムである。

(1) SNMP(Simple Network Management Protocol)

SNMP アーキテクチャモデルはネットワークマネージメントステイショ
ンとネットワークエレメントの集まりからなっている (Figure 2.3)。一つ

第 11 部459

ネット ワークマネージメントのエレ メントに対し 、複数のステイションがエレ メントの中の情報をアクセスしにいっている。

エレ メントステイション
アプリケーションエイジェント

8
8H88
HHH

4
44 44
(2) 44
4
J
JJ

(1)
(3)

HHH
8
8H
8
8

データ
ベース

(1) 要求(2) 検索(3) 応答図2.3: SNMP アーキテクチャ

 ネットワークマネージメントステイション 1 1 1 エレ メントを監視した
り制御したりするマネージメントアプリケーションを実行する。

 ネットワークエレ メント 1 1 1 ホスト、ゲートウェイ、ターミナルサー
バ、等その他同種類のもので、マネージメントステイションからの要求によってマネージメント機能を実行するよう、その責任を負わされたエイジェントを持ったデバイスのこと。

 エイジェント 1 1 1 実際に SNMP を実装する snmpd が動いていて、自分のデータベースを獲得、保持して、ステイションの要求に応じてそのデータベースを伝播する。

SNMP はこのマネージメントステイションとエイジェントの間のマネージメントインフォメーションを伝達するために用いられているプロトコルであ460

1989 年度 WIDE 報告書る。マネージメントインフォメーションの伝達はプロトコルメッセージの交換によって行なわれる。エイジェントは 、によって定義された変数を持っており、この変数はマネージメ
ント情報をオブジェクトの形で持っているものである。この変数がステイ
アプリケーションによって表現される。尚、このションに伝達され変数はフリーアクセスではなく、コミュニティ名というものによって、そのアクセスを制限している。

MIB(Management InformationBase) [30]SNMP MIB(Management Information Base)

ASN.1

[57]

管理に必要な情報を言語に従って定義づけしたものである。そのオブジェクトのリストを定義したもの。組織的な関心事や管理的なポリシに大いに関係していて 、管理されているオブジェクトを特定している。例えば 、経路情報のための変数としては、
や、という変数のグループがある。また、それぞれの変数は、単一の変数の場合や、複数の変数のエントリを持った変数の場合もある。

Table

Interface

IP Routing Table

 SMI(Structures and Identi cation of Management Information)

SMI [36]MIBとは、で定義されたデータを構造化して持っているものである。つまり、データを階層化された、変数木を構成している。このことによって、変数の意味付けがされ、ある変数がどこの部分に管理されているかが分かる。また、ある変数をアクセスしたいときは、
この変数木の構造に基づいてなされなければならない。しかし 、この管理された変数木が非常に多種多様であることから、変数をアクセスする際の複雑さが生じている。

(2) SGMP(Simple Gateway Monitering Protocol)

SNMP

基本的な考え方はと同じである。情報を変数として持っておき、その変数をアクセスすることによって情報が伝播できるものである。もと
もと、急場の要求を満たすために作られたもので、将来的にもっと汎用的なものが現れることは予想されていた。

CCITT X.409

[11]

の
言語
に基づいてなされている。欠変数の管理は
点はプロトコル実装上の複雑性が増すこと。利点は、プロトコルに従った
データの表現がマシンに対して独立しているので、広域のネットワークに対応しやすいこと。

第 11 部

ネット ワークマネージメント

461

SNMP と同様ゲートウェイにかかる負担を最小限にしようという目標を持って実装されてはいるが、共にその負荷はまだまだ大きく、これからこれらのマネージメントシステムはかなり発展していくことが予想される。

第 3章
経路制御

マネージメントシステムを経路制御だけに注目して扱う。そこで、経路制御の現状を把握するために、この章で、1. 現存する経路制御プロトコル、
2. 経路制御の問題点、
3. 問題点に対するアプローチ、の順に述べる。まず、現存するプロトコルを列挙する。そのプロトコルには利点もあり、欠点もある。例えば 、誤情報を避けるために悪い情報はその情報の真偽性を確認しながら伝播するということと、悪くなる可能性があるなら真偽に関わらずすぐに知りたいという概念は相反する。しかし 、
これは一つのプロトコルによる実現はできないのである。この原因はプロ
トコルの性能が悪いからではない。ローカルネットワークのために作られたプロトコルを、広域ネットワークにも用いているために生じた問題とも考えられる。このような矛盾を解決するためのアプローチを最後に述べて
いる。

3.1

現存する経路制御プロト コル

ここで 、実際にシステムを設計する上での足掛かりとなる、現在の経路制御に関係したプロトコルを紹介する。実際に経路に関する情報を提供したり更新したりするプロトコル あるいは、プログラム自身 として以下のようなものがある。

()(1) RIP(Routing Information Protocol)

RIP とは、routed [80] と呼ばれるプログラムで実装されている。もともとカリフォルニア大学バークレイ校でローカルネットワーク上のマシン

462

第 11 部

ネット ワークマネージメント463

間で矛盾のないルーティングと到達可能性の情報を提供するために設計された。
これは、各デスティネーションをゲートウェイのホップカウントで計っはルーティング情た距離にしたがった経路情報を伝達する。普通報のパケットを待っている状態になっている。ネットワーク間のルータになっているマシンは、定期的に自分のルーティングテーブルのコピーを直によって受け接接続しているホストあるいはネットワークに送る。
取ったパケットがルーティングテーブルの更新に利用されるのは次の場合である。

routedrouted

1. ホップカウントが 15 以下で (16 以上は無限大と定義されている)、そのデスティネーションのエントリがルーティングテーブルの中に存在しなかった場合。

2. 送られてきたメッセージが直接接続しているゲートウェイ (ルータ) からのものである場合。

3. ルーティングテーブルのエントリが 90 秒間更新されておらず、更にその経路の方が現在の経路より少なくともコスト的に効率的な場合
つまり、ホップカウントが同じか小さい場合 。

()

4. デスティネーションに対する経路がホップカウントをメトリックスとして、今の経路より短い場合。

routedは自分のマシンのルーティングテーブルを書き換え、更新されると、直接接続しているホストあるいはネットワークにパケットを送る。
はルーティングテーブルを変更する前に、その情報の安定さを確かめるために秒程度待つ。また、はルーティングテーブルのエントリが分間更新されてないと、そのエントリのメトリックスを無限大を表すにセットし 、そのエントリを抹消する。抹消は、そのエントリの無効がイ
ンタネットに伝播するのを保証するためにさらに秒遅らせて行なう。

330

routedrouted1660

このように直接ルーティングテーブルを書き換えられるので、現在の経路制御に関して、最も影響を与えている。

(2) HELLO Protocol

RIP での経路制御方法は、最小のホップカウントを基に経路を計算するという方法である。ホップカウントではネットワークの応答の生の測定や最適形を作り出せない。従って、ネットワークの負荷に応じて経路を変464

1989 年度 WIDE 報告書化させることができない。結果として、経路制御を相対的に静的なものにしている。
は 、デスティネーションに対するメト
そこで 、リックスとして、ホップカウントの代わりに遅延を基に距離を計る基準を用いたプロトコルである。
は以下の基本的な二つの機能を提供する。

HELLO Protocol [37]HELLO Protocol
1. 経路のトポロジの中でクロックを同期させ、各マシンがデスティネー
ションへの最短遅延経路を計算する、

2. RIP と同様に、新しい経路を計算するすることにより、経路情報を更
新できる、

HELLO

メッセージの交換に関係する
最短遅延経路を計算するためには、マシンは近接するマシンでのクロックの最良と思われるデータを管理すると同様ことが必要である。また、経路情報の更新に関しては、用のルーティングテーブル、つまり遅延時間によって定められたルーティングテーブルを伝播し合うことによって行なわれる。しかし 、そと同じ様に、経路更新に関しては、良い更新は即座になさ
こにはまたれ、良くない更新は冗長的に行なわれるという問題は残っている。
は現在、ほとんどサポートされていない。
しかし、このRIP

Protocol

HELLO

RIP

HELLO Protocol(3) EGP(Exterier Gateway Protocol)

autonomous system につながっているゲートウェイど うしが自分の autonomous system の到達可能性情報を知らせるために使われるのがEGP [38] である。
EGP は以下の三つの特徴を持っている。
1. 二つのゲートウェイが到達可能性の情報を通信するべきであることを合意するための neighbor acquisition 機構を保持している。
2. 合意したゲートウェイに対し 、継続的に応答しているかど うかを試験他のする。

3. ルーティング更新メッセージを渡すことにより、ネットワークの到達可能性情報を定期的に交換する。

neighbor acquisition

機構によって合意を得ると、ゲートウェイは他
こののゲートウェイにルーティング情報の交換を要求することができる。
しかし 、このプロトコルもほとんどサポートされていない。

第 11 部

ネット ワークマネージメント

465(4) GGP(Gateway-to-Gateway Protocol)
コアゲートウェイシステムという、全てのデスティネーションに対して信頼性のある矛盾のない経路を提供するよう設計されたシステムがある。
このコアゲートウェイシステム内でルーティング情報を交換するためのプ
である。
ロトコルが

GGP [58]

GGP によってゲートウェイが交換するルーティング情報は、(N,D) という組から構成されている。N はネットワークで、D はそのネットワークに到達するためのコストを与える距離 (distance) である。距離を比べることによって、ネットワークに対する最短経路を計算する。また、経路の更新が行なわれると、そのコストはシステム内の全てに伝播される。距離は
通常ゲートウェイホップ、即ちホップカウントを用いる。
このプロトコルも、ほとんどサポートされてない。

(5) gatedautonomous system

コーネル大学で書かれた、外のゲートウェイへの経路情報をど のように知らせるかを制限した規則の集合を持ったとと、を組み合わせたものである。

RIP

HELLO EGP
gated は RIP や HELLO のメッセージを受け付け、ローカルマシンのルーティングテーブルを routed のように変更する。autonomous system 内からの経路を EGP を使って外のゲートウェイに知らせる。これより、gatedの重要性は、内側のルーティング情報と外側へのルーティング情報を自動的に結び付けることが可能であることである。

HELLO も、EGP もサポートされていないので、現在は外側に
routed を用いている。

実際は
対しても、

3.2

経路制御の問題点

autonomous systemautonomous system

経路制御上の問題点は内、外に分けて考えるべきである。しかし 、実際はプロトコルとしては、内も外も同じプロトコルを用いているのが現状である。逆に、このことが問題の内で用いているもの
原因になっている可能性もある。
をその外でも使うことによって矛盾する要求が生じることがある。そこで、プロトコル実装上の問題と、プロトコルによって覆いきれない問題についてを原因とともに述べてみる。

autonomous system466

1989 年度 WIDE 報告書

3.2.1

プロト コル実装上の問題点

ここでは、経路制御で用いられているプロトコルの実装上の問題点を内の経路情報交換にはを用いる。その述べる。
際に生じる問題として、

autonomous system

RIP

1. autonomous system 内に存在する全てのトポロジを扱えるわけではない、

2. もしある一つのゲートウェイが落ちたとする (あるいは、網が切れているかも知れない) と、それに代わる置換経路があればそれを使って通信が行なわれる。その際、置換経路の伝播が完了してない時の経路がループを起こすかも知れない、

3. もし経路が更新される時、更新の情報が全てのゲートウェイに伝播されるまでの間は元の経路が保存されており、その間の経路は矛盾を招くおそれがある、

4. RIP 自身のパケットによってネットワークの負荷を上げ、ネットワー
クを非効率的なものにする恐れがある、

5. RIP を用いる上で有効なホップカウントは 15 までなので、それ以上のホップカウントが必要なネットワークとは情報交換ができない、(などがある。現在の経路制御では今使っている経路だけ 次にどのゲートウェイに対して送るか を知っていて、存在する全ての経路を認識しているわけではない。もちろん、いつもそのことを知っている必要があるわけではないが、今の経路が切れて置換経路が必要な時に分かっていた方が対応が早いことがある。この意味で、管理者がトポロジを理解していることが必要な場合もある。
置換経路の伝播は誤情報の伝播を避けるために 、冗長的に伝わっていく。その間にも通信が行なわれる可能性があり、経路が更新されていればその経路に従ってデータは送られる。しかし 、どこか途中がまだ更新されていない時、このデータがデスティネーションまで到達する保証がなくなる。
は秒毎に自分のルーティングテーブルの情報を伝達する。従っのパケットが流れているといえる。このこて、常にネットワーク上にとが網自身、或はホストの負荷を増すことにもなる。しかし 、これはに限ったことではなく、このようにある期間毎にパケットを送るプロトコ
ルの一般的な問題ともいえる。以上のように、プロトコルとして特性を持っているが、その特性が逆に広域ネットワークの利用を考えた時に問題の原因になることもある。

)

RIP 30RIP

RIP

第 11 部467

ネット ワークマネージメント

15

ホップカウントの最大が という実装の仕方は、もともとローカルネッ
トワークを対象にして考えられたプロトコルであることから理解できる。
そのプロトコルをそのままインターネットに利用していることから、この問題は生じてきている。
本論文では、これらの問題点をプロトコルの実装を変更することによる解決を目的にしているのではない。プロトコルの情報を取り入れ、更に機能を付加することにより問題点を解決することを目的としている。
3.2.2

プロト コルでサポート されていない問題点

autonomous system の外の広域ネットワークに注目すると、外側は複数の管理権限が共存しているので、それらを侵してはならない。また自分自身も外向きのポリシを持って経路制御をしていかなければならない。

autonomous systemの制御情報を知っている
ゲートウェイが、各々のと、通信における性能が分かったり、経路の動的な変化が分かったり、という広域ネットワークを安定的に保持するために有用なことが多い。実際
広域ネットワークでは、経路の動的な変化は頻繁に起こり得る。
そのような広域分散環境をネットワーク管理者の立場から、更に経路に焦点を絞って考えた時の問題点を述べる。ここで問題になるのは、どこかの故障によって今ある経路が使用不可能になり、置換経路によってカバーしようとした時、どのような環境が提供できるかということである。なぜなら、ネットワーク管理の大前提は、エンド ユーザがネットワークを意識せずネットワークを利用できる環境を提供することだからである。従って、問題は動的に変わる可能性のある経路の情報を、いかに動的に監視するかということである。
動的な監視によって管理者が知りたいことは、やはり経路が切れたという情報である。もちろん、伝播される情報にはメトリックスとしてのホップカウントが減り、到達が可能であるという情報もある。このような喜ばしい情報を知ることもトポロジをとらえる意味で大切である。しかし 、経路がより良くなってエンドユーザに環境が提供できなくなることはないが、経路が切れると環境を提供できなることは大いにありうる。従って、ここで知りたい情報は特に経路が切れるという情報になる。

RIP

による
更に、この切れたことの伝播についてもう少し堀下げる。
伝播は冗長的に伝播される。従って、その経路が切れたかど うかはしばらく立ってからわかることになる。しかし 、場合によっては、絶対に切れてには困るとか、切れたらすぐ 知りたい、という要求がある。これは、よって実現することはできない。そこで、本論文でこのできるだけ早く切れた情報を検知するシステムを提案する。

RIP

468

1989 年度 WIDE 報告書

この問題を解決するには、ある経路が使用できなくなったという情報を受け取り、環境が変わってしまった場合に、

 エンド ユーザ、に提供可能な環境を必要に応じて知らせる、
 その置換経路の容量がど うなのか、その経路と容量の情報を持つ、
 実際にどこで故障が起きたのかを調べる、といったの機能が必要になる。
これらの機能を備えて、動的に変わる経路に対し動的に対応し 、更にユーザにできる限りの環境を提供しなければならない。このようなプロト
コルによってサポートされていない問題点についてのアプローチを次に述
べる。

3.3

問題点に対するアプローチ

そこで 、具体的なアプローチを考える。上述した三つの問題点をそれぞれ解決することがこの問題解決のアプローチと考える。その中でも本論文では特に、三番目の故障の検知に着目する。前の二つの問題については
今後の課題にする。特に二番目については、その情報をどのように保持し伝播するかというまさしくマネージメントプロトコルを必要とすると考えらる。
具体的に以下のようなアプローチを考える。それは、

1. ユーザインタフェース、
2. カレント経路検索システム、
3. 故障部分検索システム、
4. 重要リンク決定システム、
5. 経路診断システム、
このように分類される。ここで、経路診断システムが、ユーザインタフェー
ス、カレント経路検索システム、故障部分検索システム、重要リンク決定
システムをサポートする。インタフェース部分は、システムが把握した情報をユーザにより視覚的に提供する。重要リンク決定システムによってデスティネーションを定める。そして、そのデスティネーション 自分間の経路をカレント経路検索システムによって把握する。その経路情報をデータ{

第 11 部

ネット ワークマネージメント469

ベースにして故障部分検索システムで故障を検知しさらには場所の究明をによる冗長的な情報の伝播を補うためする。つまり、このシステムはに、自分から積極的に応答要求を出すことで経路の生の状態を把握しようというものである。
このような経路診断システムを設計することによって、問題を解決させる。次節で、その具体的な設計について述べる。

RIP

第 4章
経路診断システムの設計

この章では、経路診断システムとは何か、何を目的としたシステムか、をまず述べる。そこで、目的を達成するためにどのような設計が必要かを述べる。更に、その設計ではこのシステムはどんなものから構成されるかを述べる。その構成要素がそれぞれどのような役割をしていて、どんな設計で、何をするのかを述べる。

4.1

経路診断システム

個々のシステムの具体的な設計をする前に、経路診断システムがど う
いうものかについてを述べる。
エンドユーザにとってはネットワークのことを気にせず、ネットワークを利用できることがもっとも望ましい。それを提供する側の管理者にとっては、ユーザが気にせず利用できるような環境を築くことが目標である。
そこでは、動的な経路制御を動的に把握することが最終目標である。このシステムの実現のためにはいくつかのステップを踏む必要がある。この経路診断システムは経路情報を利用して経路を動的に管理するために、以下のような経緯を踏まえる。
第一は全てのトポロジの理解である。しかし 、全てのトポロジの理解を
インターネットで実現することは非常に困難である。なぜなら、そのトポ
ロジは複雑、雑多だからである。しかし 、これが動的に把握できるということは経路制御する上で、とても大切なことである。なぜなら、経路を動的にとらえていればネットワークの故障に気がつきやすかったり、その箇所が調べやすかったりするからである。更に、ある所からある所までで到達可能な経路の情報をとらえられることも大切である。そこで、このトポ
ロジの理解は、全ての経路を把握することは困難なので、現在の経路を検索することによって補う。さらには世の中に存在する全てのデスティネー
ションに対して現在の経路を把握するというのは、莫大なデータベースを持つことになり有用でないし 、また広域ネットワークを利用する上でもそ470

第 11 部

ネット ワークマネージメント

471のデータベースのうちの一握りが有用なデータになるであろうと予想されるので、デスティネーションを自分で特定して、そのデスティネーション
に対しての経路を把握する。
次は、どこかの場所が落ちたり網が切れたりしたとき、その場所と原因を究明することである。原因の究明に関しては、ここでは触れない。将来的に、切れた経路の原因を自動的に究明でき、更にそれを自動的に修復できるようなシステムは非常に重宝するであろう。ここでは、経路が切れた場所を発見、するシステムを構築する。
この時、そのネットワークの状態を判断するメトリックスとして、

 それぞれの網にかかっている負荷、
 ゲートウェイにかかっている負荷、
 その網を使ったときのラウンドトリップタイム、
 通信パケットの応答率、などがわかると、その判断の目安になる。その中でも、本システムではパケットの応答率を経路が切れたことの判断基準にした。ネットワークの網にかかる負荷、というのは確かに経路
自身の負荷や、ゲートウェイのにかかる負荷を耐えず調べるが切れる直接の原因となる。マシンのということは可能かもしれないが、いくつものゲートウェイを介していたりすることを踏まえると実際的ではない。ましてや、網自身にかかる負荷を監視するということは実現しにくい。そこで、その直接の原因によって影響が及ぼされる二次的な結果としての、ラウンドトリップタイムや、パケットの応答率 あるいは、到着率 を用いる方が、そのデータの収集を考えた時に実際的である。また、ラウンドトリップタイムと応答率というのは独立したものではなく相関しているものなのでど ちらをパラメータにしても同じであるので、最終的な判断としてパケットの応答率を選んだ。ここで、最終的なと言ったのは実装に関してはラウンドトリップタイムを基に応答率を導いているからである。
このように経路診断システムではまず、デスティネーションを決め、そのデスティネーションまでの経路調べ、そのデスティネーションに対して定期的に応答要求をすることで経路状態を捉えている。さらに、その応答率によって経路の異変を察知した時は、経路のデータベースから中間ゲー
トウェイに対して応答要求をして、どこの経路が切れたかを調べている。

CPU

(

CPU

)

ここまでが分かることで 、一つの経路を動的に捉えたことにする。これが、システムの目的と概要である。残された問題は、このシステムを構472

1989 年度 WIDE 報告書

築する際に限って問題になるのではなく、ネットワークを利用したシステムを構築する際に必ず問題になる、 そのシステムによるネットワークへの影響である 。特に、動的に何かをする時は気をつけなければならない。このことをあまり気にしない短絡的な実現方法は、もし静的な情報を捉えることができているのなら、耐えずその情報を得ることができるような要求パケットを送り続けるという方法である。しかし 、経路情報のように耐えず変わる可能性があり、また安定しているとほとんど 代わらないといった情報を得るために、耐えず要求パケットを送り続けることはネットワークの負荷を非常に増大させる可能性があることを予想しなければならない。
このことを考慮すると、ネットワーク上のアーキテクチャとしては次の二つが考えられる。

\"

1. 自分のマシンにあるシステムを載せ、他のマシンには負荷をかけずに実現する (Figure 4.1) 。
2. お互いのマシン毎に自分の情報を保持し 、それらを規則にしたがって交換することにより実現する (Figure 4.2) 。
前者は、自分が望む要求に対する行動を全て自分で行なう。従って、他のマシンには負荷をかけることはなく、他のマシンの持っている情報を自分が得るだけである。この方法では、他のマシンに負荷をかけないことが利点である。しかし 、もし必要な情報が非常に多く、その情報を保持するだけでマシンの負荷になり、それを処理するのにまたマシン大きな負荷がかかってしまう場合はこの方法による実装は効率的でない。
逆に、後者はお互いで このような情報をこのように管理しておこうという合意をする。その合意の基に、自分の保持している情報を交換し合う。この方法は前者の欠点である、非常に多いデータ量という問題を解決する。その意味で、広域分散環境のネットワークを管理するには一般的である。しかし 、互いにデータを交換し合う規則を構築しなければならない。
これは、ネットワークのアーキテクチャに大いに関わることで簡単なことではない。
そこで 、本論文では前者を用いた実現を考えてみた。このような方法
で経路を動的に管理することを実現する。
以上のように、経路診断システム Figure 4.3 は、

\

"

(

1. ユーザインタフェース、
2. カレント経路検索システム、
3. 故障部分検索システム、)

第 11 部

ネット ワークマネージメント473

広域分散環境ネットワーク

E
EE
AS EE
'



AS  $'$&%

22 222 22&%
22 2 2222 22
'
$
AS
2 22
2
!
!
22 2
!
!!
!
!
!
AS
2 22 !$!!!!!!!1 & %'! システム ! 7- : 情報の収集
/


&

: 経路

D.B.

%
図

4.1: アーキテクチャ1

474

1989 年度 WIDE 報告書

広域分散環境ネットワーク
AS
'

AS
'

$

$

システム

システム

7

7

/ &/ 


D.B.

1A
A1

AS A1
'

%

&

$

'

D.B.

1A
A1

システム

7

8
H8
H

H88H

D.B.

%

H8H8 : プロトコル
: 経路

図

AS

$

システム

/ 
&%

4.2: アーキテクチャ2

H
8
8H

7

/ 

&

D.B.

%

第 11 部

ネット ワークマネージメント475

4. 重要リンク決定システム、の四つのシステムを統合的にサポートして、経路を診断し 、経路状況の情報を提供する。

4.2

ユーザインタフェース

経路診断システムのユーザインタフェースとは、システムからの情報をユーザに見せるための部分である。本システムの中のメインとなる部分を占めるシステムではないが、システムの診断結果を直接表す部分という意味から、本システムの成果を映し出しているといえる。ここでは、デー
タベースを基に診断した結果をディスプレ イ上にアピールしているので、デスティネーションまでの経路と、もし異変があった時どこで起きたかということが分かる。従って、その結果から今までのホップカウントだけによる経路制御に、ラウンドトリップタイムを基にした応答率による経路状
態が分かる。このことで、経路の動的な変化に対応している。具体的には、
まずデスティネーションまでの経路が決定したらそれを表示する。そして、
何か状態変化を知らせる信号を受け取るたびにその情報を表示する。これを繰り返している。しかし 、前にも述べたが将来的にはもっと様々なメト
リックスを反映させて経路状態を診断するのが望ましい。そうすれば 、動的な経路変化をより正確に監視できるようになる。
また、広域ネットワークを考える時、経路情報に加えて次のような情報が得られることも有用となるかも知れない。

1. autonomous system の外とつながっているゲートウェイの情報。
2. ある autonomous system の管理者の名前。
autonomous system 外とつながっているゲートウェイが落ちるとそのネットワーク、あるいはそのゲートウェイを介して通信するネットワークの管への到達が不可能になる。それにともない、その理者名や、もし管理者がログインしてたら、そのマシン名の情報が出ると
外とつながっているゲートウェイ
便利である。また、を送ることを待たが落ちそうになったら、落ちるのをまって落ちたらずに、もし可能なら、先に置換経路に切替えてしまう機能を持っていると役立つ場合もある。
本論文では、このユーザインタフェースに焦点を当てるのではなく、そのためのデータベースの保持、データベースを作るためのシステムの実現を第一目標にしている。そして、その情報を利用したユーザインタフェー
スを構築する。

autonomous systemautonomous system

RIP

476

1989 年度 WIDE 報告書

経路診断システム

88

ユーザインタフェース

88

経路検索
システム

@@00 経路情報
デスティネーション 88
ゲートウェイ88
ゲートウェイ88
ゲートウェイ88
ゲートウェイ88-

パケットの流れ

図

00@@
故障部分
検索
システム



A

重要リンク
決定
システム

00@@

00@@

@@00
- 

-

4.3: 経路診断システム

i

 Z



-

第 11 部

4.3

477

ネット ワークマネージメント

カレント 経路検索システム

カレント経路検索システムでは、文字通りデスティネーションまでどのような経路をたど っているかその経路を検索する。その際検索される経路は、現在のホップカウントを用いて定められている、ルーティングテー
ブルに従った経路である。さらに、その調べた情報をいつでも引き出せる
ようにデータベースとして保持する。
カレント経路システムの実現は、以下のものから成り立っている。

1. 保持する情報となるデータベース。
2. その情報を得るためのシステム。
カレント経路検索システムの設計をこの二つから述べる。
4.3.1

データベース

データベースはシステムというよりは、システムによって生じた結果であるが、実際に参照したり、更新したりという意味からは逆に一番大切ともいえる。このデータベースの中の中心は介している中間ゲートウェイ
であるが、付帯情報としてラウンドトリップタイムも有している。
4.3.2

データベースを得るためのシステム

データベースを得るとは、デスティネーションまでの経路を検索し道順を築き上げることである。その経路の決定の仕方は現在の経路制御においては一意である。そこでまず経路決定のアルゴ リズムを説明する。そしてその後、そのアルゴ リズムに則ったデータベースの得方について述べる。

(1) 経路決定のアルゴリズム
経路の決定のアルゴリズムは現在は一つしか存在せず、いかなる実現方
法を用いても結果は一つである。その決定方法とは、メトリックスとしてホップカウントを用い、デスティネーションに対しホップカウントの少ないゲートウェイへ向かう経路をとるというものである。従って、各マシンのルーティングテーブルにはデスティネーションネットワークやデスティ
ネーションへ送るための次のゲートウェイの情報が記述してある。そのデ秒毎に各スティネーションへのゲートウェイは一意である。この情報はをブロードキャストすることにより、今の経路がホッゲートウェイがプカウントをメトリックスとしたときに最短であるかど うかが決められる。
よって、経路はデスティネーションが与えられた時そのデスティネーショ

RIP

30

478

1989 年度 WIDE 報告書

ンネットワークに対するゲートウェイが決まり、その経路をとる。そして、そのゲートウェイがまた自分のルーティングテーブルに従って経路をとる。
このように、デスティネーションまでの経路が決定されるのである。言い換えると、経路を決定する際自分は次のゲートウェイまでの責任しか持たず、それ以降はそのゲートウェイに任せている。
さてそのデータベースの得方、すなわちデスティネーションまでの経路の検索の仕方であるが、大きく分けて二種類ある。

 情報伝播プロトコルを用いてルーティングテーブルからのデータを集積する、という各マシンに依存した方法。

 自分から送るパケットの IP [56] データグラムの time-to-live フィー
ルドを利用する、という自分のマシンにのみ依存した方法。
前者の方法を取り入れるものとして、二通り考えてみた。

1. SNMP を用いたもの。
2. RIP query を用いたもの。
(1) SNMP を用いた方法

SNMPといっても様々のものが広まっているが、一番機能
現在一口にやの整っているものとしては製品化しているものがある。また、で作られたものもある。
を用いるためには各自治システムがその製品を製品化している
購入しなければならないということになり、ここでは考慮にいれない。でやで作られたを用いたとすると、これはコマンド
は、によってデスティネーションのルーティングテーブルが取ってくることができる。従って、必要な時にこのコマンドを使うようなシステムにすれば 、そのホストのルーティングテーブルを取り出すことができる。しかし 、こがそれぞれの自治システムのゲートウェイ上で動いている保証のはない。

MIT CMU

SNMP

MIT CMU

SNMP

SNMP

(2) RIP query を用いた方法

RIPというプロトコルを利用して他のホストのこちらは逆に、今ある
ルーティングテーブルを取り出そう、というものである。ここでは、という機能をあるゲートウェイに出すことによって、そのゲートウェ

query

RIP

第 11 部

ネット ワークマネージメント

479

RIP

イが送っているの情報を聞き出すことができる。このことによってそのホストのルーティングテーブルを取り出すことができる。

SNMP

はマネージメントシステムとして開発さ以上の通りであるが 、れたものであるがまだまだ発展途中であり、また、各で取り入れられているかという問題もある。
を用いた場合ルー
ティングテーブルの冗長的な更新の問題点は解決されない。いずれにしても、プロトコルによって情報を伝播し 、その情報を基に経路を構築するということでパフォーマンスがかかる。
次に後者による方法である。

autonomous system
RIP query(3) IP データグラムを用いた方法

IPtime-to-liveIPtime-to-live
0time-to-live

データグラムのフィールド の特性を使うもこの方法はフィールドとは文字通り生存時間を表している。すのである。
なわち、 データグラムを受け取ったゲートウェイはそのパケットが自分フィールドの値を 引いて次に送る。その時宛でなければそのその値が であるとそれ以上送ることはせず、 になって目的のデスティ
ネーションに届きませんでしたよ という返事を送り主に返すのである。
この特性を利用して最終デスティネーションまでの経路を構築する。

1
\0

"

SNMP はまだあまり一般に広まっていないし 、また、RIP query を用いる場合も経路を構築するまでに探索コストがかかる。そこで、本論文でデータグラム FIgure 4.4 を用いた方法を採用した。
は三番目の

IP

4.4

(

)

故障部分検索システム

故障部分の発見についても次の二通りが考えられる。

1. RIP に応じた検索による発見。
2. 積極的な検索による発見。
能動的、受動的の違いはあるが 、いずれにしてもこのシステムでは自分の持っている経路情報を基にどこで故障がおきているのかを発見するも
のである。
4.4.1

RIP に応じた検索

RIP に応じた検索をする場合は、カレント経路を検索する時にも RIPに基づいたデータベースを持っていなければならない。具体的には、自分480

1989 年度 WIDE 報告書

カレント経路診断システム
自分

データ

QQ 
Q

0@@
00 @

経路情報データベース
デスティネーション
ゲートウェイゲートウェイゲートウェイ@@ 00@0
IP データグラム

ネットワーク
図4.4: カレント経路診断システム

第 11 部

481

ネット ワークマネージメント

RIP

30

の持っている経路情報とによって 秒毎に伝わってくる情報を見比べによる伝播で切れたことが分かるのは、ルーティングテーブルがる。
更新されないことによってルーティングテーブルの中からそのエントリが消えることによって認識できる。その後、各中間ゲートウェイにを出してどこから情報が途切れていいるのかを発見する。
からの情報を待っていて、それが伝わったらデータベー
この場合、スを基に切れた場所の究明をする。従って、情報を待つことにより切れたことの認識に時間がかかることが予想され 、総じて故障箇所の発見にも時間がかかる。

RIP

RIP query

RIP

4.4.2

積極的な検索RIPRIPに応じた検索が 、による情報の伝播から切れた場所の発見をするという受動的な検索であるのに対し 、この積極的な検索では、自分からデスティネーションに対し 、定期的に応答要求のパケットを送ることによって経路の状態を確認するという能動的な検索をする。
具体的には、デスティネーションに対して定期的に応答要求パケットを送る。そこで、その応答率がなくなったことで切れたことを判断する。その後、自分のデータベースの中の中間ゲートウェイに応答要求を出す。これによってどこが切れたかが分かる。

RIPに応じた検索では、切れた場所が発見できるという機このように、能が加わるだけで、切れた場所、あるいは切れそうな場所の早期発見にはによる情報の伝播よりも早ならない。これに対し 、積極的な検索ではく発見できる可能性がある。従って、本研究では故障部分の発見に、に応じた検索ではなく、積極的な検索による方法を用いる Figure 4.5 。

RIP

(

4.5

RIP
)

重要リンク決定システム

WIDE

このシステムで、ターゲットとするデスティネーションを定める。
広域分散環境ネットワークの中で、どのリンクが重要なのかを定めることは非常に困難なことである。そこで、本論文ではその重要さをエンドユー
ザの主観的な立場から見た定め方と、実験から定める方法とを用いた。
4.5.1

主観的な定義これは 、そのエンド ユーザの主観によって重要なリンクを決めるものである。この主観にもここでは次の二通りがあると考える。

1. 経験による主観。

482

1989 年度 WIDE 報告書

故障部分検索システム

データベース8
8HH88
HH

ターゲットホスト名

1
応答要求

A

A
11 A

A
返答

1
AA 1
1
ターゲットホスト

図4.5: 故障部分診断システム

2. ポリシによる主観。
経験による主観とは、文字通り、今までの経験からここのリンクは多用しているのでど うしても切れては困る、というものである。これに対し 、
ポリシによる主観とは、たとえあまり使われなくともポリシ上ど うしても切れては困る、というものである。
いずれにしても、ここでの定義では自分で経路を診断したいデスティ
ネーションを定めることになる。
4.5.2

実験的な定義IP

これはあるホストに対し 、そのホストに出入りする データグラムの統計を定期的に取ることにより、そのホストにとってどのリンクの使用頻度が高いかを調べる。具体的には 、 データグラムのソースフィールドと、デスティネーションフィールド の統計を取ることで、どのホストとの通信が多いかが分かる。その結果から、使用頻度の高い経路をそのホストにとって重要な経路とするものである。そこで、その重要度を以下のように定義する。

IP

第 11 部

483

ネット ワークマネージメント

A 指定: 1 時間毎に 10 分間データグラムを取り出入りする IP データ
グラムのうちの 50%以上を占めるリンク。
B 指定: それ以外のリンク。
A

B

ここで、 指定のリンクは自動的にそのリンクを監視する。 指定のリンクについては何もしない。その理由は、多くのホストに向けて経路診断をすることはネットワーク中に多くの応答パケットを投げることになるので、そのことによって逆にネットワークの網の負荷を上げてしまい効率が悪くなりかねないからである。
これらのように、この重要リンク決定システムでは、経路診断を実際にどのデスティネーションに対して行なうか、それを決定するためのもの
である。

第 5章
実装と評価

ここでは、経路診断システムの実装についてと、実装に当たり、本シスによる実装との比較、システムが与えるネットワークへの負荷
テムとについて述べる。

RIP

5.1

実装

前節の設計に従って具体的にどのように実装したかを述べる。このシステムの中心部の流れは次ページに示す。
5.1.1

ユーザインタフェース

ここでは 、デスティネーションの状態を画面上に表わすことで経路の診断結果としている。前述のアルゴ リズムの中の信号部分の時、デスティ
ネーション、あるいは中間ゲートウェイの状態を表示する。
具体的には、

 危険信号 1 1 1 ホスト名の点滅、ブザー、
 通信不能信号 1 1 1 ホスト名の反転、経路への印づけ、ブザー、
 通常時 1 1 1 ホスト名、経路、とすることによって状態の遷移を表わしている。
このようなディスプレ イ制御のシステムを、付加機能を持った便利なものになるよう構築すると管理者だけではなく、エンド ユーザにとっても意義のあるアプリケーションになる。これは、今後の課題にする。

484

第 11 部

ネット ワークマネージメント

485

main(){/* デスティネーションまでの経路を探索 *//* 探索の結果をデータベースとして保持 */カレント経路検索;for (;;) {/* デスティネーションと通信可能の時 */if (デスティネーションが生きている場合) {/* デスティネーションに対し応答要求を開始 */応答要求 (デスティネーション );if (パケット喪失率 != 100%) {if (パケット喪失率 >= 90%) {危険信号;}
else {for (データベースのエントリがなくな
るまで) {
応答要求 (ゲートウェイ);
if (パケット喪失率 == 100%) {ゲートウェイへの通信不
能信号;

}
}
デスティネーションへの通信不能信号;}}}
else {/* デスティネーションと通信が不能の時 */応答要求 (デスティネーション );/* 再び通信可能になる */if (パケット喪失率 < 90%) {通信復活信号;
カレント経路検索;}
else {
死んだまま;
}

}
}

486

1989 年度 WIDE 報告書

}
5.1.2

カレント 経路検索システム

IP

time-to-liveIP

カレント経路検索にはデータグラムのフィールド の特の実装は、送られたデータグラムが自分宛な性を利用した。現在のら取り込み、そうでなければルーティングテーブルに従って次のゲートウェ
フィールド の値を 減らイにそのデータを転送する。その際フィールドが になったらしてから転送する。そこで、もしそのパケットを捨て、そのことを送り主に伝える これは、のという機能によって行なわれる 。従って、フィールドが である データグラ
ムを受け取ると転送する時に を引くと になってしまうのでそこでそのデータグラムを捨て、そのことを送り主に対して伝える。その時の、データグラムの送り主は元のデータグラムを捨てたホストになる。
フィールド を から一つずつ増やしてデ以上のことより、
スティネーション宛にデータグラムを送るとその返ってくるデータグ
ラムによって途中のゲートウェイが分かるのである。

IPtime-to-livetime-to-live

1

0
ICMP(Intenet(
Control Message Protocol) [55] TIME EXCEEDED)
time-to-live
1
1
0
IP
time-to-live
IP

5.1.3

IP

ICMP

1

故障部分検索システム

ICMP ECHO REQUESTECHO REQUESTECHO REQUESTECHO REPLY

故障部分検索には応答要求を利用した。これはの機能を利用している。この機能は、パケットを受け取るとエコバックしなければならないというものである。
パケットを受け取るとエコバックのためにパケットを送り返す。これによって経路及び 、ホストの生存が確認できる。
パケット個を 秒毎に送り、そ
ここでは、このパケットの個数をカウント
れに対してエコバックされた
し 、その割合によってホスト、及び経路の状態を認識している。具体的には、パケットの喪失率を以下のように定義する。

ECHO REQUEST10ECHO REPLY

lostpacketslate =1

sendingpackets 0 receivingpackets
2 100
sendingpackets

この値をもとに次のように経路の状態を定義づける。

1. パケット喪失率 100% 1 1 1 どこかの経路が切れている。
2. パケット喪失率 90%以上 1 1 1 効率が悪い。
3. パケット喪失率 90%未満 1 1 1 正常。

第 11 部487

ネット ワークマネージメント

このパケット喪失率によってデスティネーションへの経路が切れていると診断されると、経路情報のデータベースからホストを一つずつ取り出してそれらに対して同様に応答要求を出す。その結果、どこの経路が切れていたのかを発見する。

5.1.4

重要リンク決定システム

重要リンクの決め方のうち、経験的に決める方は自分の主観でターゲッ
トとなるデスティネーションを定めるので、この場では割愛する。さて、データグラムの統計のとり方であるが、ここではを利用して、イーサネット上にながれている データグラムを全て拾い上げる。そのデータグラムのソース、デスティネーションの統計を調べてどのホストとの通信が多いかを定め、そのホスト経路を診断するためのターゲットデスティネーションにする。

IP
NIT(Network Interface
IPTap) [67]

しかし 、この経路診断システムで自動的にデスティネーションを決定
して自動的に診断を始めるという実装はしていない。 データグラムの統計をとってその結果からターゲットデスティネーションを決める。そして、
そのデスティネーションに対して経路の診断をするようにした。

IP

5.2

評価

RIP

ここで 、
の実装と、本システムの実装を比較することにより、本によって切れたリンクを検知するには、システムの評価をする。
による情報の伝播が冗長的であるために時間がかかる。これは、が悪のアルゴ リズムとして、良い情報
いことを表しているわけではない。
つまり、少ないホップカウントで到達できるという情報 はいちはやく伝播される。すなわち、すぐルーティングテーブルが更新される。しかし 、悪い情報 ホップカウントが増えたという情報 は、その情報の信用性を確かめるために冗長的に伝播するのである。すなわち、悪い情報がルーティ
ングテーブルの新たなエントリになることはない。従って、何かの間違い
で悪い情報が生まれても、冗長的に伝播している間に正しい情報が伝わると、悪い情報は捨てられるのである。

RIP

RIP

RIP

(

(

RIP

)

)

RIP

による経路制御では補えない問題を本システムでこのことから、を用いた実装の結果と、本システムの実装の補佐してみた。そこで、結果との比較を行ない、評価とする。

RIP

488

1989 年度 WIDE 報告書

5.2.1

RIP の実装の結果

RIP を用いて経路制御を行なった場合の、切れたリンクの検知と対応の仕方は、

1. RIP のメトリックス (すなわち、ホップカウント) が徐々に増える、
2. メトリックスが 16 以上になった時、切れたことを認識する、
3. 置換経路が存在する時、より有用な置換経路を選択する、
4. 存在しない時は、人間が修復するかもしくは、新しいリンクを作る、
このように行なわれる。

koch{ccut(東大) 間の経路を考えてみる (Figure 5.1)。
ここで、ccut が落ちて koch{ccut 間のリンクが切れたとすると、ルー
ティングテーブルに default というエントリがないと仮定すれば 、RIP による経路状況の伝播、変遷は以下のようになる (Table 5.1) 。数字は、経
そこで、例えば、路制御のためのメトリックスであるホップカウントを指している。

(sec)
180s
420s
660s
ccut loopback
Down
Down
Down
relay ccut
1 ccut16
消滅|
jp-gate relay
2 relay
2 relay16
消滅koch jp-gate 3 jp-gate 3 jp-gate 3 jp-gate 16
マシン

時間

表

5.1: ccut 宛のルーティングテーブルの変遷

ccut
relay ccut

RIP

がダウンしたためを伝播しなくなる。従って、直接接
これは
続している
は
宛の情報が伝わらず、秒後にメトリックスが無限大にセットされ 、更に秒後にルーティングテーブルの中からのエントリが抹消される。これによって、
が伝播する
の情報に
宛の情報がなくなる。同様にして、更に秒後にがの秒後にエントリが抹メトリックスを無限大にセットする。そしてその消される。以下同様ににものダウンが秒後に伝わる。そこは到達不可能になったことを知るのである。
で、

60

relay
180

ccut

koch

koch ccut

180

ccut

しかし実際にはルーティングテーブルはている Table 5.2 。

(

)

60
660

ccut

RIP
jp-gate ccutdefault というエントリを持っ第 11 部489

ネット ワークマネージメント

東京大学

ccut.cc.u-tokyo.ac.jp













relay.cc.u-tokyo.ac.jp

慶応大学

,,
,
,
,,
,
,
,,

88
888888

jp-gate.wide.ad.jp

111
1
11
1111
11
1111
11

koch.slab.math.keio.ac.jp

図5.1: koch-ccut 間経路

490

1989 年度 WIDE 報告書

Routing tables
Destination
Gateway
Flags Refcnt Use
Interfaceradish.nakanish kossvax.slab.ma UGH 23859
ie0
keio-math-slab- koch.slab.math. U
261941748 ie0
defaultjp-gate.wide.ad UG 12118593 ie0
loopback
localhostU
40293941 lo0
5.2: koch のルーティングテーブルの一部

表

ccut
koch

defaults

jp-gate宛のパケットはであるに送られてしこのように、は何秒間たっても自分のルーティングテーブルにないデまう。するととして次スティネーションへのパケットはデスティネーションをのゲートウェイを選ぶ。従って、はがダウンしたということを認識することはなくなるのである。これは実際に通信はできないのに、経路制御は自分のルーティングテーブルに従って行なうことを表わしている。
によって覆いきれない部分なのである。
このことが、

defaultkoch ccut

RIP

5.2.2

経路診断システムの評価

RIP に対し 、経路診断システムの場合の切れたリンクの検知の仕方は、
1. 重要なリンク (デスティネーション) を考え、そのリンク (デスティネー
ション ) に対したえず応答要求パケット (ICMP ECHO REQUEST)を送り、その応答 (ICMP ECHO REPLY) を調べる、
2. そのラウンドトリップタイムが著しく遅れ最後に一パケットも返ってこなくなったことでそのリンクが切れたと仮定し 、認識する、

3. その後、途中の全てのノードに対し監視パケットを送り、実際にどこのリンクが切れて、その目的デスティネーションに到達できないかを
確認する、
となる。
間の経路を考えてみる。ここで、が落そこで、同様にちてその間のリンクが切れると以下のようになる Table 5.3 。
秒で間の経路が切れたことが確認できる。
これより、約という値は初期設定によって変わる値である。この結果はあるター
このゲットに対して 秒毎に個応答要求を出した時の値である。この応答要

koch{ccut

30

30

1

ccut{relay

10

(

)

ccut

マシン

第 11 部

ネット ワークマネージメント

491

(sec)

10s

30s

時間

20s

ccut 喪失率 100%
Down
Down
Down
relay
|
|
|
喪失率 0%
jp-gate||
喪失率 0%|
koch|
喪失率 0%||
表 5.3: 経路診断システムによる変遷
230

求を 秒毎に送ったり、また 個送り続けたりという設定をすることも可能である。もしあるホストに対して応答要求を個送ったとすると、その情報の信頼性は高まる。つまり、 個の応答要求に対しての応答率より、個の応答要求に対する応答率の方が精度は良くなるという意味である。
しかし 、どこかのマシンが落ちて通信不能になった時、そのそれぞれのホ個ずつの応答要求をすると、それだけ故障箇所の決定まストに対してでに時間がかかることになる。また、間隔をあけることはネットワークへの負荷を与えないという点から有意義ではあるが、信頼性のあるデータを提供するためには間隔は疎でも長いあいだ送らなければならないので、早個
い発見は実現できないというジレンマもある。これらから、 秒毎に送ることを選んだ。
また、今後の課題としては 、例えば重要リンク決定システムに応じて要求パケットの送る個数、送る間隔、データのサイズを決めるような実現をするものが考えられる。
更には、より凝ったユーザインタフェースを作ることによりネットワー
クのトポロジと状態の理解を実現できる。例えば 、ある程度のネットワー
クの状態図を表わし 、その中のどれかを対象に選んでやるとその間のネッ
トワークの状態を検索しに行くようにする。
いずれにしても、今後の発展はまだまだ考えられるが 、とりあえず第一目標である故障箇所の早期発見は達成されたといえる。

10

30

30

30

1

5.2.3

10

実装によるネットワークへの負荷

設計のところでも述べているように、ネットワークを利用するアーキ
テクチャをこのシステムのように、一つのマシンが情報を一人で集めに行くという方法をとると、多数のパケットをネットワークに送り込まないとその実現はなかなか困難になる。そこで、その網の負荷をなるべく少なくするためにこのシステムでは、送るデータグラムをなるべく小さく必要最小限 例えばヘッダ部分だけ を送るように実装している。

(

)

492

1989 年度 WIDE 報告書

1
CPU

64

具体的に、 回の応答要求で バイトを送る場合を考える。これによっの負荷と、ネットワークの網自体にかかる負荷を考える。
てうける、(1) CPU の負荷

CPU

xload

のロードアベレージをで見ることによってその様
これは、子を調べてみた。この章の最後に、システムを動かした時とそうでない時の結果を示す。

CPUkitasun(に与える負荷はそれほどないといえる 尚、この
これより、直接
結果は任意にマシンのロード アベレージをとりそのときにシステ
ムも動かしてみたものである 。

)(2) ネット ワークの負荷

jp-gate{relay 間の経路を考えてみる。ここはバンド幅が 64kbps(bitper second) の専用回線を用いている。この間にながれている IP データグ
ラムの統計をしらべてみる。ここで、このデータを 10 分程度収集してみると 660byte/s 程度のデータグラムが流れている。従ってこれは約 6600bpsのデータが流れていると考えられる。一方、このシステムが送っている IP
データグラムは 1 秒間に 64 バイトであるから約 640bps である。以上より、
もともと最大の 10%程度の使用量の所へ、さらにこの 10 分の 1 のデータ
例えばを流してもそれほどの影響はないといえる。

10

100

分間の統計は前後するが、そもそも最大容量のもちろん、この分の であるのでそれほどの負荷を与えていないと判断できる。また、回の専用回線ばかりではい。例えば 、イーサネットは線に関してもであり、の回線、等様々である。結局、ネットワークに与える負荷とはその時使っている容量に対してまだどれだけの容量が余っていてそこにどれだけの容量を送るかという相対的な割合が重要になる。

1

10mbps64kbps
9.6kbps

このように考えてもえる。

64 バイトが与える影響はそれほど大きくないとい以上よりネットワークに与える負荷それほどないといえる。しかし、ネッ
トワークを介したアーキテクチャでも述べた通り、一つのマシンが全ての情報を得に行くといった実現の方法を取ると、そのマシンにかかる負荷が個のデスティネー
大きくなる可能性はある。このシステムでも、これを倍にションに対して行なえばそのネットワークに与える負荷は単純になる。また様々なマシンでこのように実現したシステムを動かせばネット
ワークの負荷にもなりかねない。従って、このシステムが残す課題もある。

10

10

第 11 部

ネット ワークマネージメント

493

しかし 、第一目標を達成していることと、当座はそれほどネットワークに負荷は与えないという実験結果からこのシステムは成功と評価できる。

494

1989 年度 WIDE 報告書

第 6章
結論

6.1

結果

目的でも述べた通り、このシステムの目標は動的に変化する経路状態
を動的に把握することであった。そのために、実際には切れていなくても切れそうと判断して対処をしている。その理由は、ネットワークが広域になってくると、 ど うしても切れては困るリンク といった要求が出てくる。このような要求に応じるためにも、危険な状態はいちはやく発見して適切な対処をしてネットワークの安定性を保持しなければならないからで
あった。

\

"

そこで、本システムではその切れそうであるか否かの判断のために、応返ってこなければもちろん切れた
答要求パケットの喪失率を用いた。
以上返ってこない場合にはそれを危険と判断してと判断し 、さらにはいる。このような実現により、危険箇所の早期発見をしている。そこには、
そのパケットの喪失率の信頼性という問題もある。例えば 、パケットは多
く送ればそれだけその間の経路の応答性は正確に伝わる。しかし 、多く送ることによって時間をかけてしまうと早期発見というテーマに対してジレ回というのを一つのンマが起こる。そこで、本システムでは 秒毎を秒サイクルにしている。もし一つもパケットを喪失していなけらば約後に応答要求が終る。もし一つでも喪失していると個送った後、今までのパケットの返ってきた時間 つまり、ラウンドトリップタイム の最大値の 倍だけ待って終了する。また、一つも返ってこなかったら秒間だけ個のパケットの応答要求に結論を導ていまって終了する。このように個では信頼性がないのでは 、という意見に対しては、各マシンはる。
そもそも落ちるために作られているのではなく、たまたま落ちてしまうのである。あるいは、経路にしても切れるためにあるのではなく、たまたま回をサイクルに切れてしまうのである。だとすれば 、この応答要求は無限に行なうよう実装されている、従って、そこにひっかかった時が落ちたことを表し 、その時までには何サイクルもの応答要求を行なっているか

100%

90%

1

\10

10

10

10

(

2

10

)
10

"

10

495

496

1989 年度 WIDE 報告書

10

1

回でもそれに 回も応答がなけれも知れない。そう考えれば 、たとえば異常といえる。そこで、異常を検知した後は各デスティネーションに対回ずつの応答要求をしてパケット喪失率がであった所を切れた
し箇所と判断している。

10

100%

さらに、このシステムではその切れたデスティネーションに対し応答要で求を出し続けている。もちろん、落ちている間のパケット喪失率はある。そこで、もしマシンが復活することによって経路が復旧したり、置換経路を取ったことによって経路が復旧するとこの応答要求に対してデスティ
ネーションは返事を出す。これによってこのシステムでは復旧したこともすぐに分かることになる。続けて、もし復旧したらすぐにカレント経路の検索を始める。そうすると新しくできた経路が分かる。このことから、もし新しい経路が元の経路と同じであれば 、経路が切れたことの原因がそのマシンが落ちた等の理由であるかも知れない。逆に経路が変わっていれば 、経路が何かの原因で落ち、すぐに置換経路によってつながったとわかる。

100%

このように、切れた後もデスティネーションに対して応答要求をする
ことによってその切れたことの原因についての検査にもなり、また、ユー
ザにとっても復旧がすぐに伝わり便利である。このことによって、本システムの目的であった刻々と変わる可能性のある経路を、動的に監視することの実現がなされたといえる。もちろん、この経路決定の基になっているのは現在の経路制御プロトコルであるので、経路決定に用いられているのはホップカウントだけである。今後は他のメトリックス 例えば 、ラウン
ドト リップタイムなど を基にした経路制御も考えられ 、本システムがそれらに対する汎用性もあるといえる。

)(

また、ユーザインタフェースで少しでもユーザの目に移るような実現をすることでその後の早い対処に役立ている。さらに、ユーザインタフェー
スを便利にすることで、システムの応用性が出てくる。このユーザインタ
フェースをより充実させて一つのシステムのより有用な実現をしたい。
また、重要リンク決定システムの導入がなされていない。これは、やたらに診断システムを動かさないためである。これをしっかり導入するためにはその経路の重要さの定義づけが必要になってくる。つまり、流れているデータグラムの統計から、その統計をどのように判断するかである。こ
こでは最も簡単な、宛先として流れている量の多いソースとデスティネー
ションを重要であると定義している。その宛先が重要であることは正しいと思うが、さらに細かい定義付けをして、それに応じて診断を始めるというのが望ましい。そのためにも、さらにデータ分析システムを導入した診断ができると有用である。しかし 、このシステムで第一目標は達成されている。

第 11 部497

ネット ワークマネージメント

以上の意味において、このシステムは故障部分の早期発見、及び経路情報の動的な監視に対し有用である。今後の課題もあり、システムをさらに発展させることにより、より正確な情報の捉え方が可能になる。いずれにしても、ひとつの目標を達成した点がこのシステムの成果である。

6.2

今後の発展

6.2.1

問題点

このシステムの最大の問題点は、自分のホストからの検索しかできな
いことである。従ってネットワーク管理の立場からの全てのトポロジの把握という目標を達成するまでには至ってない。そこで、自分が直接制御することのできない経路の情報を把握するという新たな目標が生じてくる。
6.2.2

課題

RIP

このシステムでは、によって覆いきれない部分を支援した。しかし 、ネットワーク管理を考えた場合、さらなる要求が存在する。このシス
テムでは、自分のホストが中心で自分のホストにかかわる経路に関する情報だけを調べることができる。従って、自分が直接関係してない経路の情報を調べられない場合がある。例えば 、次のような経路のトポロジの場合を考える Figure 6.1 。

(

A{B
B{C
A

)

A{C

B{C

間、
間の経路情報は分かるが、間を経由してここでは、いないかぎり、間の経路情報は分からない。しかし 、ネットワークを考えた場合ホスト にとっても、間の情報を知っていた方がいいときもある。このような時、お互いに持っている情報を交換するようなプロト
コルが必要になってくる。

B{C

このように、今後は情報交換プロトコルを利用するにしろ、任意の経路の状態が把握できるということが課題となる。
6.2.3

応用

このような経路情報管理システムの利用は様々考えられる。例えば 、置換経路への早い移行ができる。つまり、今までのアルゴ リズムでは切れてから 、もし置換経路があればそれに変更するというものだった。そこで、切れる前に先につないでしまって、現在の経路が切れても通信は途切れなの接いようにすることができる。あるいは、新しい通信媒体である
続の目安になることもある。

ISDN

498

ホスト B

1989 年度 WIDE 報告書

LLLL
LLLL

ホスト C

JJJJ
JJJJ
JJ
JJJJ
JJJJ
J JJ
JJ
J

図

6.1: 例






 



ホスト A第 11 部

ネット ワークマネージメント

499

さらには、経路情報に他のメトリックスを導入するとより正確なネット
ワークの状態を把握できる。例えば 、ネットワーク利用の要求として次のようなものがある。

 そんな経路が存在するんだったら必ずそこから送って、
 このパケットは速い所から送って、
 このパケットは安い回線で送って、などである。
このような、新しい要求に答えることで 、ネットワークの安定した管理、そしてネットワークの効率のよい利用が実現する。
以上のように、本論文で述べた経路診断システムはこれからのネット
ワークマネージメントの一歩としては、その役割を果たせた。新しい課題
を一つずつ克服していくことにより理想的なネットワーク運営を実現して
いきたい。

500

1989 年度 WIDE 報告書