WO2006098024A1

WO2006098024A1 - Ipネットワークにおけるマルチキャストツリー監視方法およびシステム

Info

Publication number: WO2006098024A1
Application number: PCT/JP2005/004697
Authority: WO
Inventors: Tetsuya Nishi
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2005-03-16
Filing date: 2005-03-16
Publication date: 2006-09-21
Anticipated expiration: 2007-09-16
Also published as: US7693092B2; JP4381448B2; US20080175172A1; JPWO2006098024A1

Abstract

　本発明は、ネットワーク監視装置（４）からの指示に従って、例えば映像情報の発信元である送信端末（２Ｔ）から、通常のマルチキャストフレームとは区別される監視用のテストパケットを一定量連続して送信する。この連続したテストパケットを受信しこれらを通過させた各ルータ（３）にて生成される通過状態情報（例えばＭＩＢ情報）を上記ネットワーク監視装置（４）にて収集し、収集されたこれらの通過状態情報と、自ら保持するトポロジ情報とによって、テストパケットの各ルータ（３）のインタフェースにおける配信方向を判定し、この判定結果に基づいて、マルチキャストツリーを特定するようにする。

Description

IPネットワークにおけるマルチキャストツリー監視方法およびシステム技術分野

[0001] 本発明は、 IP (Internet Protocol)ネットワークにおけるマルチキャストツリー監視方法およびマルチキャストツリー監視システム、さらには、そのためのネットワーク監視装置、ルータおよび送信端末に関する。

背景技術

[0002] マルチキャスト IPアドレスを用いて、 1つの送信端末から多数のメンバー（受信端末 )に向けて例えば映像情報を配信すると!、つたストリーム系の IPマルチキャストネットワークが構築され、多数のユーザに利用されている。この場合、その映像情報はマルチキャストフレームとして、所定のルータを経由しながら IPネットワーク上を転送され、所定のメンバーに提供される力このとき当然、その所定のメンバーの全てに正確にその映像情報が行渡らなければならず、誤って上記所定のメンバー以外の宛先にその映像情報が届いてしまうようなことがあってはならない。すなわち、上記マルチキヤストフレームの伝送経路力設計どおりの伝送経路になっていなければならない。このように設計どおりの伝送経路になっていることを確認することは、例えば通信事業者にとって重要なことである。

[0003] 上述した伝送経路はマルチキャスト伝送の場合、 IPネットワーク上で一般にツリー状をなすことから、かかる伝送経路のノス形態を一般にマルチキャストツリーと呼んでいる。そして、上記マルチキャストフレームが実際に設計どおりの伝送経路に沿って転送されていることを確認するために、いわゆる「マルチキャストツリー監視」が、例えば上記映像情報の配信開始時やある!/、は障害発生時等に随時、例えば上記通信事業者によって行われる。本発明は、カゝかる「マルチキャストツリー監視」のための方法ならびにシステムについて言及するものである。

[0004] なお本発明に関連する公知技術としては下記の〔特許文献 1〕があり、この特許文献 1には、

「ネットワーク上にフィールド管理プロセス（FM)を置き、ホスト（1一 3)にフィールドクライアントプロセス（FC)を置き、各サブネットにサブネット管理プロセス (SM)を置き、ネットワーク上の複数端末間の通信手段としての情報バス生成要求をフィールド管理プロセス (FM)がフィールドクライアントプロセス（FC)を経由してユーザから受けると、フィールド管理プロセス (FM)がサブネット間の接続ポイントを決定し、それに応じたサブネット管理プロセス (SM)へマルチキャスト 'トンネリング設定の指示を出して設定することで、各端末がマルチキャストアドレスを指定してデータを送出し、グループ間通信をサポートする情報バスを動的に生成する」

ことにより、論理的なマルチキャスト網を動的に構築して計算機資源やネットワーク資源の効率的な利用を図ることが記載されている。

[0005] また当業者に周知の従来例として後述する図 28および図 29を参照しながら説明するマルチキャスト監視のための手法がある。しかしこの従来例の手法には後述する問題がある。

特許文献 1 :特開 2001— 156855号公報

発明の開示

発明が解決しょうとする課題

[0006] 図 28は、 IPマルチキャストネットワークにおける障害事例を示す図である。本図においては、一例として、送信端末 (カメラ)力もの映像情報を、マルチキャストツリーに沿って複数のルータを経由しながら複数（図では 2台）の受信端末に配信する様子を表している。

[0007] ここで例えば機器に対するパラメータの設定ミス等によって、設計とは異なる伝送経路（図中、点線の矢印で示すマルチキャストパス (ルート）参照）が形成されたものとする。そうすると、この誤ったルートにマルチキャスト 'トラヒックが転送され、例えば図中の HTTPサーバによるサービスが停止してしまう。すなわち図中の X印で示すように「サービスダウン」が発生する。このような障害が発生しないように事前に、マルチキヤストツリーの経路確認をしておく必要がある。またこのような障害が発生してしまったときは、迅速に障害箇所を特定して、その障害復旧をする必要がある。

[0008] 従来は、 (1)各ルータにテルネット (telnet)等でそれぞれログインし、そこカゝらマルチキャストに関するパラメータの設定情報を個別に収集していた。したがって、機器ごとに設定方法が異なり、全ての機器に対する設定情報を確認するための方法を知って V、なければならな、、と、う問題があった。

[0009] (2)また図 29に示すように、実際に運用しているツリーの疎通確認を行うためには個々の宛先の端末に向けて pingや tracerouteを実行しなければならなかった力これでは配信先が多いと処理に多大な時間がかかり、また、必ずしもュ-キャストの経路（図中、 SPTの経路）と、マルチキャストの経路（図中、 RPTの経路）とが同一経路とは限らないため、正しい経路の確認ができないという第 2の問題があった。なお、図中の記号の意味は、下記のとおりである。

[0010] RPT： Rendezvous Point Tree

¾PT: Shortest Patn Tree

DR: Designated Router

上記 (2)の問題点をさらに詳しく説明すると次のとおりである。

[0011] IPネットワークにおいて、 PIM—SM (Protocol Independent Multicast Sparse Mode) と呼ばれるマルチキャスト用の制御プロトコルを用いたマルチキャスト配信が広く用いられている。 PIM— SMでは、 RP (Rendezvous Point)に設定されたルータが全ての配信先にマルチキャストする場合と、 RPの負荷を軽減するためにヽくつかの宛先に対しては送信元に接続されて、る DR (Designated Router)で分配しュ-キャストルーチングに従ってパケットを配信する場合とがある。

[0012] このような PIM— SMでは、送信元から各宛先に対して RP経由（RPT: RP Tree)で配信されているのか、あるいは、送信元からのュ-キャストルーチング（SPT:

Shortest Path Tree)で配信されているの力、各ルータの設定情報等を詳細に調査しなければ分力ない。また、 RPTによる配信では、ュ-キャストルーチングと経路が異なるため、エンド ·ッ一'エンドで疎通確認を行おうとしても pingや traceroute等では疎通確認ができない。

[0013] したがって本発明は、上記問題点に鑑み、全ての機器に対する前述した設定情報を確認する方法を知ることを要することなぐまた、前述した ping等を実行することを要求することなぐ簡単な手法によって、マルチキャストツリーの確認と、疎通や品質の確認とが短時間に行える、マルチキャストツリーの監視のための方法ならびにシステムを提供することを目的とするものである。

課題を解決するための手段

[0014] 本発明は、ネットワーク監視装置 (4)からの指示によって、例えば映像情報の発信元である送信端末（2T)から、通常のマルチキャストフレームとは区別される監視用のテストパケットを一定量連続して送信する。この連続したテストパケットを受信しこれらを通過させた各ルータ（3)にて生成された通過状態情報 (例えば MIB情報)を上記ネットワーク監視装置 (4)にて収集し、収集されたこれらの通過状態情報と、自ら保持するトポロジ情報とによって、テストパケットの各ルータ（3)における配信方向を判定し、この判定結果に基づいて、マルチキャストツリーを探索しこれを特定するようにする。

[0015] これにより、従来は何時間も力かっていたマルチキャストツリーの監視力数分のうちに完了できるようになる。

図面の簡単な説明

[0016] [図 1]図 1は、本発明に係るマルチキャストツリー監視システム 10の基本構成を示す図である。

[図 2]図 2は、図 1に示すマルチキャストツリー監視システム 10の監視動作を示すフロ一チャートである。

[図 3]図 3は、本発明に基づくマルチキャストツリー監視システムが適用される IPネットワーク 1の具体的イメージを示す図である。

[図 4]図 4は、本発明に基づくマルチキャストツリー監視システム 10の具体的構成例を示す図である。

[図 5]図 5は、本発明の経路判定動作を説明するために図 3の一部を取り出して示す図（その 1)である。

[図 6]図 6は、トポロジ管理テーブル 34の構成例を示す図である。

[図 7]図 7は、判定条件の項目を埋めた判定部 33による判定結果を示す図である。

[図 8]図 8は、経路状態の判定結果を例示する図である。

[図 9]図 9は、最終的な判定部 33による判定結果を例示する図である。

[図 10]図 10は、本発明の経路判定動作を説明するために図 3の一部を取り出して示す図（その 2)である。

[図 11]図 11は、図 10のもとでの、判定部 33による最終的な判定結果を示す図である

[図 12]図 12は、 MIBのオブジェクトの第 1例を表す図である。

[図 13]図 13は、 MIBのオブジェクトの第 2例を表す図である。

[図 14]図 14は、 MIBのオブジェクトの第 3例を表す図である。

[図 15]図 15は、本発明の第 1実施例を適用した IPネットワーク（図 3)を表す図である

[図 16]図 16は、図 15において実行される第 1実施例の動作を表すフローチャート (その 1)である。

[図 17]図 17は、図 15にお、て実行される第 1実施例の動作を表すフローチャート (その 2)である。

[図 18]図 18は、本発明の第 2実施例を適用した IPネットワーク（図 3)を表す図である

[図 19]図 19は、図 18にお、て実行される第 2実施例の動作を表すフローチャート (その 1)である。

[図 20]図 20は、図 18において実行される第 2実施例の動作を表すフローチャート (その 2)である。

[図 21]図 21は、本発明の第 3実施例（ # 1)を適用した IPネットワーク（図 3)を表す図である。

[図 22]図 22は、図 21にお、て実行される第 3実施例（ # 1)の動作を表すフローチヤート（その 1)である。

[図 23]図 23は、図 21にお、て実行される第 3実施例（ # 1)の動作を表すフローチヤート（その 2)である。

[図 24]図 24は、本発明の第 3実施例（ # 2)を適用した IPネットワークを表す図である

[図 25]図 25は、図 24において実行される第 3実施例（ # 2)の動作を表すフロートである。 [図 26]図 26は、第 4実施例としての障害検知システムを適用した IPネットワークを表す図である。

[図 27]図 27の（a)— (d)は、送信用フレームのヘッダフォーマットを示す図である。

[図 28]図 28は、 IPマルチキャストネットワークにおける障害事例を表す図である。

[図 29]図 29は、従来技術の問題点の 1つを説明するための伝送経路例を表す図である。

発明を実施するための最良の形態

[0017] 図 1は本発明に係るマルチキャストツリー監視システムの基本構成を示す図である。本監視システムは参照番号 10で示されており、その代表的な構成要素 (後述）は参照番号 11一 14で示す。本発明に係るこのマルチキャストツリー監視システム 10は、その前提として IPネットワーク 1内に形成される。

[0018] この IPネットワーク 1は、図示するとおり、端末 2と、ルータ 3と、ネットワーク監視装置 4とを含んでなり、該ネットワーク監視装置 4によってマルチキャストフレームの伝送経路を探索する。もう少し詳しく言えばこの IPネットワーク 1は、マルチキャストフレームを配信する送信端末 (TX) 2Tと、そのマルチキャストフレームを受信する複数の受信端末 (RX) 2Rと、その送信端末 2Tから複数の受信端末 2Rへ向けて形成されるツリー状のマルチキャストフレーム伝送経路上に複数配置されるルータ 3と、を含んで構成される。

[0019] この IPネットワーク 1内に形成されるマルチキャストツリー監視システム 10は、上述したように、代表的に、指示機能部 11と、送信機能部 12と、状態情報生成機能部 13と、判定機能部 14と、力も構成される。これら機能部 11一 14の主たる機能は次のとおりである。

[0020] 指示機能部 11は、ネットワーク監視装置 4に設けられ、通常配信されるマルチキヤストフレームとは区別される監視用のテストパケットを送信すべきことを送信端末 2Tに対し指示する機能を備え、

送信機能部 12は、送信端末 2Tに設けられ、上記の指示に従ってテストパケットをルータ 3に向けて送信する機能を備え、

状態情報生成機能部 13は、送信されたテストパケットを受信しこれを通過させた各ルータ 3に設けられ、その通過させたテストパケットの通過状態情報を生成する機能を備え、

判定機能部 14は、ネットワーク監視装置 4にさらに設けられ、各ルータ 3から収集した通過状態情報に基づいてテストパケットの IPネットワーク 1上での配信方向を判定し、この判定結果によりツリー状のマルチキャストフレーム伝送経路を特定する機能を備える。

[0021] 図 2は上述した図 1のマルチキャストツリー監視システム 10において実行されるマルチキャストツリー監視方法を表すフローチャートである。すなわち、マルチキャストフレームの伝送経路をネットワーク監視装置 4によって探索するための本発明によるマルチキャストツリー監視方法は、本図に示すステップ S 11一 S 14によって実行される。

[0022] ステップ S11 :ネットワーク監視装置 4から送信端末 2Tに対し、通常配信されるマルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを指示し、ステップ S 12：送信端末 2Tにお、て、上記の指示に従ってテストパケットをルータ 3 に向けて送信し、

ステップ S13 :送信されたテストパケットを受信しこれを通過させたルータ 3の各々にお!、て、そのテストパケットの通過状態情報を生成し、

ステップ S14 :ネットワーク監視装置 4において、各ルータ 3から収集した上記の通過状態情報に基づいて、テストパケットの IPネットワーク 1上での配信方向を判定し、この判定結果により上記ツリー状の伝送経路を特定する。

[0023] さらに具体的には、上記第 1のステップ S11において、監視用のテストパケットは、

(i)マルチキャストフレームとしては通常採用されることがないデータ長を有するパケッ卜、

(ii)未使用の、発信用 IPアドレスあるいは宛先マルチキャスト IPアドレスを有するパケット、

(iii)パケットの有効時間 TTL (Time To Live)力^から、予め指定した Nまで設定されたパケット、

のいずれかから選択され、そして予め定めた一定量のテストパケットが連続的に送信されるようにする。 [0024] さらに上記第 3のステップ SI 3において、上記の通過状態情報は好ましくは、ネットワーク管理用データベース MIB (Management Information Base)情報として生成される。

[0025] さらにまた上記第 4のステップ S14において、上記の判定は、ネットワーク監視装置 4内にあって隣接ルータとの接続関係を保持するトポロジ管理テーブルを参照して行われるようにする。

[0026] 図 1および図 2を参照して、本発明に係るシステムおよび方法の基本的概念を示したので、次にもう少し具体的な実施形態を参照しながら説明する。

[0027] 図 3は本発明に基づくマルチキャストツリー監視システムが適用される IPネットヮーク 1の具体的イメージを示す図である。なお、全図を通じて同様の構成要素には、同一の参照番号または記号を付して示す。

[0028] 本図の構成は IPネットワーク 1を具体的に表しており、前述したマルチキャストツリー監視システム（図 1の参照番号 11一 14)については記載を省略している。これは、本発明によるマルチキャストツリーの伝送経路のイメージをより一層分力りやすくするためである。すなわち本図を参照すると、送信端末 2T (本図の例ではカメラ)力のマルチキャストフレーム（映像情報）力 IPネットワーク 1上の所定のルータ 3を経由して、所定の受信端末 2R (本図の例ではパソコン）に転送される様子が示されており、ここにその転送ルートがマルチキャストツリーをなす伝送経路 5となる。

[0029] まずネットワーク監視装置 4について見ると、この中には前述した図 1の指示機能部 11と判定機能部 14とが含まれる。なおこのネットワーク監視装置 4、例えばマルチキヤストッリ一監視サーバは、通常は IPネットワーク 1内に元々設けられて、るものであつて、この既存のサーバ内に上記機能部 11および 14を本発明によって新たに追カロすることになる。このネットワーク監視装置 4は、この他にトポロジ管理テーブルや状態情報 (MIB)収集部等も含まれる。

[0030] 一方図 3の送信端末 (カメラとして示す） 2Tはいわばマルチキャスト 'ストリーム配信装置であって、ネットワーク監視装置 4からのテストパケット送信指示があつたとき、該配信装置 (2T)は、

の!、ずれかからなるテストパケットを伝送経路 5上に流す。つまり通常マルチキャストフレームとして存在することが殆どな、フレームをテストパケットとして一定量、連続的に流す。

[0031] このようなテストパケットを一定量、連続的にネットワーク上に流すことが本発明の特徴をなし、各ルータ 3のインタフェース（ポート） 6におけるそのテストパケットの流入量を調べることにより、送信端末 2Tから受信端末 2Rまでのテストパケットの伝送経路を探索することができ、よってマルチキャストツリーが特定されることになる。

[0032] つまり上記のテストパケットの各インタフェース 6における流入量を測定して、図 3中、黒丸を付したインタフェース 6でのテストパケットの「流入量は少なく」、白丸を付したインタフェース 6でのそのテストパケットの「流入量が多!、」ことが、ネットワーク監視装置 4において明らかになったとすると、この場合のマルチキャストツリーをなす伝送経路は本図の矢印 5で示すようになることが判明する。

[0033] このように、大量のテストパケットを短時間だけネットワーク上に流して、上記流入量を調べるだけで、マルチキャストツリーの監視 (探索）が完了してしまうから、その監視に要する所要時間は高々数分である。これは従来における所要時間である数時間に比べるとおおよそ 1Z60の時間短縮となる。

[0034] ここで、上述したマルチキャストツリー監視システム 10を構成する構成要素をもう少し具体的に示す。

[0035] 図 4は本発明に基づくマルチキャストツリー監視システム 10の具体的構成例を示す図である。

[0036] まずネットワーク監視装置 4について見てみると、前述の図 1ではこの装置 4を、通常配信されるマルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを、送信端末 2Tに対し指示する指示機能部 11、および送信されたそのテストパケットを受信しこれを通過させた各ルータ 3にて生成されたそのテストパケットの通過状態情報に基づいて、そのテストパケットの IPネットワーク 1上での配信方向を判定し、この判定結果によりツリー状のマルチキャストフレーム伝送経路を特定する判定機能部 14として示したが、図 4においては、その指示機能部 11を、ツリー監視実行指示部 21から構成している。またその判定機能部 14についてはこれを、各ルータ 3からそれぞれの通過状態情報を収集する状態情報収集部 31と、収集されたその通過状態情報を格納する状態情報格納部 32と、格納されたその通過状態情報をもとに前述した配信方向を判定するマルチキャストパス判定部 33と、カゝら構成している。

[0037] この判定機能部 14特にマルチキャストパス判定部 33は、状態情報格納部 32に格納されたそのテストパケットの送信直前の通過状態情報と、そのテストパケットの送信後の通過状態情報との差分が大であるときに、前述した判定を行うようにする。差分が大であるということは、当該テストパケットが当該ルータ 3を通過したことを意味する力である。

[0038] また判定機能部 14は、隣接ルータとの接続関係を保持するトポロジ管理テーブル

34をも有し、上述した配信方向の判定のために参照する。

[0039] さらにまた判定機能部 14は、上記の判定結果により特定されたツリー状のマルチキヤストフレーム伝送経路 5の構成をオペレータに表示するためのツリー表示部 35を有するのが望ましい。

[0040] 次に送信端末 2Tついて見ると、前述の図 1においてはこの端末 2Tを、通常配信されるマルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを示すネットワーク監視装置 4からの指示を受けて、そのテストパケットをルータ 3に向けて送信する送信機能部 12として示したが、図 4においては、その送信機能部 12を、監視用のテストパケットを送信すべきことを示すネットワーク監視装置 4からの指示を受け付けるツリー監視要求受付部 41と、その指示を受け付けてテストパケット Ptを生成し送信するテストパケット送信部 42とから構成している。

[0041] このテストパケット送信部 42にて生成しかつ送信されるテストパケット Ptは、前述したパケット (i)、（ii)および (m)のいずれかから選択されると共に、予め定めた一定量のテストパケット Ptが連続的に送信される。 [0042] 次にルータ 3について見ると、前述の図 1においてはこのルータ 3を、送信端末 2T より送信されたテストパケット Ptを受信しこれを通過させた際のそのテストパケットの通過状態情報を、ネットワーク監視装置 4による前述の探索に供するために生成する状態情報生成機能部 13として示したが、図 4においては、この状態情報生成機能部 13 は、ネットワーク管理用データベース（MIB) 51と、このネットワーク管理用データべース (MIB) 51により生成された通過状態情報を、直接または送信端末 2Tを介して、ネットワーク監視装置 4に送信する状態情報送信部 52とから構成している。なお、スイッチ部 53はルータ 3に既存の本来のルーティングという役割を果たすものである。

[0043] なお後に図 26を参照して説明するとおり、本発明によるマルチキャストツリー監視方法によれば、 IPネットワーク 1内の障害検知といった機能も簡単に実現することができる。このために、図 4に示す判定機能部 14は、前述した判定部 33による判定結果により特定されたツリー状のマルチキャストフレーム伝送経路 5が、マルチキャストフレームを受信すべき全ての受信端末 2Rには到達して、な、と判断したとき障害検知情報 ALMを発生する障害判定部 36をさらに備えることができる。

[0044] 図 4に示すマルチキャストツリー監視システム 10の実際の構成例によると、ネットヮーク監視装置 4は「マルチキャストツリー監視サーノであり、その中の状態情報収集部 31は「SNMP送受信部」（SNMP : Simple Network Management Protocol)であり、また状態情報格納部 32は「MIB情報格納部」である。さらに図 4に示す送信端末 2T は「マルチキャストフレーム配信装置」であり、さらにまた図 4に示すルータ 3内のネットワーク管理データベース（DB)は「MIB」であり、その中の状態情報送信部は「SNM P送受信部」である。力かる実際の構成例においては、本発明のマルチキャストツリー監視システム 10は、マルチキャストツリー監視サーバ（4)、マルチキャストフレーム配信装置（2T)、およびルータ 3からなる。

[0045] このマルチキャストツリー監視サーバ（4)にお!/、て、

マルチキャストパス判定部 33は、マルチキャストフレーム配信装置（2T)に対してッリー監視用のテストパケット配信を指示したり、

ルータ 3から MIB情報を取得するため SNMP送受信部（31)に MIB (例えば、 RM ON (Remote Network Monitoring) MIB)収集を指示したり、 MIB情報格納部（32)から収集した MIB情報を収集したり、

トポロジ管理テーブル 34から各ルータ 3の接続関係を把握したり、

ツリー表示部 35に配信装置（2T)力受信端末 2Rまでのツリーの構築結果を通知するようにしている。

[0046] これらの構成部分により、マルチキャストのテストパケットが流れるインタフェースおよび流れる方向を認識することができる。

[0047] またツリー監視実行指示部 21は、マルチキャストフレーム配信装置（2T)に対して配信テストパケットのアドレス、テストパケットのパケットサイズ、 TTL、およびポート番号を配信装置 (2T)に通知し、配信装置 (2T)力ゝらの実行終了結果をマルチキャストパス判定部 33に通知するようにしている。これにより、ツリーを識別するために必要な

MIB情報や ICMP (Internet Control Message Protocol)での time exceededパケットを抽出することができる。

[0048] トポロジ管理テーブル 34は、各ルータ 3の隣接ルータとの物理的な接続情報を格納するようにして、る。これによりマルチキャストのテストパケットがどのインタフェースを利用して、るかが認識できる。

[0049] MIB情報格納部（32)は、ルータ 3から収集した MIB情報を格納するようにして、る

。これにより、マルチキャストパス判定部 33が必要な MIB情報を解析できる。

[0050] SNMP送受信部 31はマルチキャストパス判定部 33からの指示により、各ルータ 3 力も MIB情報を収集するための SNMPコマンドを実行するようにして、る。これにより

MIB情報格納部（32)に格納する情報を収集できる。

[0051] さらにツリー表示部 35は、マルチキャストパス判定部 33で把握したツリーの構成をオペレータに表示できるようにしている。これにより、ツリーの可視化が図れ、便利である。

[0052] マルチキャストストリーム配信装置（2T)にお!/、て、

ツリー監視要求受付部 41は、マルチキャストツリー監視サーバ (4)のツリー監視実行指示部 21からの指示およびパラメータを受け付け、テストパケット送信部 42に送信の実行を指示したり、

送信終了、および ICMPでの time exceededパケットの受信結果を、マノレチキャストツリー監視サーバ (4)に返送するようにして、る。

[0053] テストパケット送信部 42は、指定されたアドレス、 TTL、ポート番号、パケットサイズで、テストパケットを送信するようにしている。これにより、マルチキャストツリー監視サーバ (4)で必要な MIB情報等を収集できる。

[0054] ルータ 3において、

スィッチ部 53は、マルチキャストフレーム配信装置（2T)力のテストパケットをルーティングするようにしている。これによりテストパケットを他のルータ、あるいは受信端末 2Rにルーティングすることができる。

[0055] SNMP送受信部（52)は、マルチキャストツリー監視サーバ（4)からの SNMP Re questに対し、 MIB情報をもって応答するようにしている。これにより、マルチキャストツリー監視サーバで必要な MIB情報を収集できる。

[0056] MIB (51)はテストパケットの受信に基づき受信パケット数等を累積するようにしている。これにより、マルチキャストツリー監視サーノ (4)で必要な MIB情報を収集することがでさる。

[0057] ここで図 3を再び参照すると、図 4で示したマルチキャストツリー監視サーバ（4)、マルチキャストストリーム配信装置（2T)、およびルータ 3を用いたマルチキャストツリー監視システム 10において、各インタフェース毎の MIB情報をサーバ（4)が収集し、特定のテストパケットの流入量が多、インタフェースを検索して、テストパケットの流入方向を把握することにより、マルチキャストテストパケットのフローを認識することができる。あるいは、各ルータ 3がマルチキャストフレーム配信装置（2T)に向かって送信する、 ICMP time exceededパケットを解析し、マルチキャストストリーム配信装置（2T)からのホップ数を把握することも可能である。

[0058] 次に図 3に示す IPネットワーク 1内の任意の一部に注目して、マルチキャストツリー伝送経路 5の判定手法を、図 5—図 11を参照して具体的に説明する。

[0059] 図 5は経路判定動作を説明するために図 3の一部を取り出して示す図である。本図において、参照番号 3は図 3に示すとおりルータを表しているが、図 5ではさらに Router 1, Router2"'のように各ルータを区別して示す。また図 5においては上述した、各ルータのインタフェースをポート Pl、 P2および P3のように区別して示す。なお、各ポート (P)に近接して示す黒丸と白丸は、図 3の場合と同様、テストパケットの各ィンタフェース（ポート）への流入量の大小を表し、白丸を付したポートには大量のテストパケットが流入している例を示している。そしてこのような、テストパケットの流入量の大小に応じてマルチキャストパケットの配信方向を特定することになる。この配信方向の特定に際しては、前述のトポロジ管理テーブル（図 4の 34)が有効になる。

[0060] 図 6はトポロジ管理テーブル 34の構成例を示す図である。ただし、ルータ 3のうちの "Router 1"につ、ての管理テーブルを示し、他の" Router2，，、 "Router3，，- · ·につ!/、てはそれぞれ個別に管理テーブルが用意される。

[0061] 図 5を参照すると、ルータ（Routerl) 3のポート Pl、 P2および P3は、それぞれ隣接ルータ Router2のポート P2に接続し、 Router3のポート P1に接続し、 Router5のポート P1に接続して、る力ら、 Routerlにつ!/、てのトポロジ管理テーブル 34の内容は図 6 に示すごとくなる。

[0062] 次に、図 6のテーブル 34における判定条件を決定する。そこで、上述のとおり、まず送信端末 2Tよりテストパケット Ptを短時間のうちに大量に送信する（図 4の 42)。このテストパケットの送信に起因して各ルータ 3にて発生する MIB情報を蓄積する（図 4の 51)。さらにその MIB情報を収集した上で分析し、各ルータ 3の各ポート Pにおけるテストパケットの配信方向を判定する。これを図 7に示す。

[0063] 図 7は判定条件の項目を埋めた判定部 33による判定結果を示す。テストパケットの流入量が多いか少ないか、については、ある閾値を設定してそれより多いか少ないかで判断する。その閾値 (TH)は、送信端末 2Tより送信されるテストパケットの量 (例えば 100パケットとする）とほぼ同じ値とする（TH= 100)。あるいは、伝送途中での若干のパケットロスを考慮して、 100より小さい値とする（例： 90く THく 100)。力べしてその閾値 THを用いて、判定条件の項目の黒丸と白丸が定まる。そしてこれら黒丸と白丸とにより既述した通過状態情報 (テストパケットの経路状態情報)が判定される。これを図 8に示す。

[0064] 図 8は経路状態の判定結果を例示する図である。本図の右矢印、左矢印および両矢印は、 Routerlのポート Pl、 P2および P3におけるテストパケットの配信方向すなわち経路状態 (各ルータでの通過状態）を示す。結局、図 9に示すテーブル 34が完成する。

[0065] 図 9は最終的な判定部 33による判定結果を例示する図であり、これによりマルチキヤストフレームの伝送経路が特定され、マルチキャストツリーの探索が完了する。

[0066] 図 10も、図 5と同様、本発明の経路判定動作を説明するために図 3の一部を取り出して示す図であるが、図 5と異なるのは黒丸と白丸の記載がないことである。これは、図 10にお、て用いるテストパケットが、第 3形態 (iii)すなわち TTLを利用する形態のテストパケットを採用しているからであり、図 5における第 1形態 (i)すなわち短いデータ長を用いる形態のテストパケットある、は第 2形態 (ii)すなわち通常あり得な!/、発信元アドレス及び Z又は宛先アドレスを用いる形態のテストパケットとは異なる。

[0067] 図 10において、 TTL = 3に設定してテストパケット送信部 42 (図 4)より送信されたテストパケットは、 Routerを 1つ通過する毎にその TTL値が 1ずつ減算され例えば Router5に到って TTL = 0になると time exceededパケット力この Router5から直接（または送信端末 2Tを介して間接に)、状態情報収集部 31 (図 4)〖こ収集される。同様に、

TTL = 4に設定されたテストパケットは Routerlに到って TTL = 0となってその time exceededパケットが状態情報収集部 31に収集され、

TTL = 5に設定されたテストパケットは Router2および Router5に到ってそれぞれ T TL = 0となってその time exceededパケットが状態情報収集部 31に収集され、

TTL = 6に設定されたテストパケットは Router6に到って TTL = 0となってその time exceededパケットが状態情報収集部 31に収集される。

[0068] 図 11は上述した TTLをパラメータとするテストパケットを利用した場合の、最終的な判定部 33による判定結果を示す図である。図 5と同一のネットワークを前提とするから、この判定結果は、当然、図 9の判定結果と同じになる。

[0069] 以上述べたようなマルチキャストツリーの探索を可能にする要因の 1つは、既述のとおり、通常配信されるマルチキャストフレームとは区別される監視用のテストパケットを使用することにある。このような特殊なテストパケットは、図 4のネットワーク管理用データベース 51 (好適例としては前述の MIB)において特殊なオブジェクトとなり、各ルータ 3におけるテストパケットの検出をきわめて容易にする。力かる MIBのオブジェクトについて詳細例を示す。

[0070] 図 12は MIBのオブジェクトの第 1例を示す図であって、前述したテストパケットの第 1形態 (i)を示し、

図 13は MIBのオブジェクトの第 2例を示す図であって、前述したテストパケットの第 2形態 (ii)を示し、

図 14は MIBのオブジェクトの第 3例を示す図であって、前述したテストパケットの第 3形態 (iii)を示す。

[0071] すなわち図 12は、マルチキャストフレームとしては通常採用されることがないデータ長を有する第 1形態 (i)のテストパケットを Ptとして示し、データ長が 64byte以下のものをテストパケットとしている。図 13は、未使用の、発信用 IPアドレスあるいは宛先マルチキャスト IPアドレスを有する第 2形態 (ii)のテストパケットの特徴を表して、る。また図 14は、パケットの有効時間 TTL (Time To Live)が 1から、予め指定した Nまで設定された第 3形態 (iii)のテストパケットの特徴を表して、る。

[0072] 上記の図 12、図 13および図 14についてもう少し具体的に説明すると、これらの図 1 2—図 14は、マルチキャストツリーの認識に必要となる MIB情報を示す。テストバケツトの流入量で監視する場合は、通常流れることがな、64byte以下のフレームを例えば etherStatsUndersizePkts (図 12)を用いて送信し、その流入量を計測することでマルチキャストツリーを認識できる。

[0073] あるいは、特定の送信 IPアドレスなどを用い、その送信 IPアドレスと宛先 IPマルチキャストアドレスを用いたテストパケットを送信し、そのテストパケット数を計測する nlMatrixSDOctets (図 13)を用いることでもマルチキャストツリーの認識が可能である。この場合は、そのテストパケットが流入するポートを識別するために、

addressMapbource (ポ ~~ト番号)、および adaressMapNetworkAddress、上己 addressMapSourceへ入力される送信 IPアドレスの一覧）の収集も必要となる。

[0074] あるいは、 TTLを 1から Nまで設定した各テストパケットを送信し、 TTLが 0になったルータであることを示す ICMP time exceededパケットを送信する際にその送信パケット数を計測する icmpOutTimeExcdsを用いて、マルチキャストツリーを認識することが可會である。この場合も、 addressMapSource,および addressMapNetworkAddressの収集が必要である。

[0075] 次に上述した第 1形態 (i)、第 2形態 (ii)および第 3形態 (iii)の各テストパケットをそれぞれ用いた第 1、第 2および第 3実施例を説明する。なお、これらの第 1、第 2および第 3実施例は、上述の図 4一図 14で説明した構成を、図 3の IPネットワーク 1上でそれぞれ具現ィ匕したものである。

[0076] 図 15は本発明の第 1実施例を適用した IPネットワーク（図 3)を表す図であり、図 16は図 15において実行される第 1実施例の動作を表すフローチャート (その 1) であり、

図 17は同フローチャート（その 2)である。

[0077] まず図 15を参照すると、本第 1実施例のもとでの動作は、下記 1.一 6.のようになる

。なお送信端末 (マルチキャストフレーム配信装置）としては、映像情報を MPEG等にフォーマット化するエンコーダ（2E)として示す。

[0078] 1.各ルータ 3からテストパケット送信前の MIB (etherStatsUndersizePkts)を収集し

2.エンコーダ（2E)にテストパケットの送信を指示し、

3. RTP (Realtime Transfer Protocol)ヘッダのみのテストパケットを一定量送信し、

4.再度、ルータ 3から MIB (etherStatsUndersizesPkts)情報を収集し、

5.流入量の多いインタフェース（ポート）、および流入方向を判定して、

6.マルチキャストツリーを表示部 35に表示する。

[0079] さらに詳細な処理の流れを図 16および図 17を参照して説明する。

[0080] ステップ S21 :監視サーバ（4)は、これから IPネットワーク 1に流そうとするテストパケット（本第 1実施例では、図 12の最上段の etherStatsUndersizePkts)のカウント値を、各ルータ 3の MIB (図 4の 51)力受信する。 MIB (51)における

etherStatsUndersizePktsの監視テストの直前における初期カウント値を入手するためである。すなわち、テストパケットの流入量カこの初期カウント値より大幅にカウントァップしたとき、テストパケットが当該ルータを通過したものと判定する。

[0081] ステップ S22 :監視サーバ (4)はエンコーダ（2E)に対し、短時間に大量に流すべきテストパケットの個数を指定してその送信を指示する。 [0082] ステップ S23：上記の送信指示を受信したエンコーダ（2E)は、 RTPヘッダのみからなるパケットを、テストパケットとして、テストパケット送信部（図 4の 42)から送信開始する。

[0083] ステップ S24 :エンコーダ（2E)は、そのテストパケットの送信を終了したら、その終了を監視サーバ (4)に通知する。

[0084] ステップ S25：上記のテストパケットの送信終了によって、該テストパケットが通過したルータにおいては、そのテストパケットすなわち etherStatsUndersizePktsについての MIB情報すなわちカウント値が大幅に増大しているはずである。そこで監視サーノ（4)は、各ルータ 3の MIB (51)から再度、 etherStatsUndersizePktsのカウント値の情報を受信する。

[0085] ステップ S26：監視サーバ（4)はそのカウント値すなわちテストパケットの流入量が前述した閾値 THを超えた力否かを、判定部（図 4の 33)により判断する。

[0086] ステップ S27 :上記の閾値 THを超えていれば、「マルチキャストの入力あり」と判断し、トポロジ管理テーブル 34にこれを設定し、

ステップ S28：上記の閾値 THを超えなければ、「マルチキャストの入力なし」と判断し、トポロジ管理テーブル 34にこれを設定する。なお上述した「マルチキャストの入力あり」および「マルチキャストの入力なし」は、図 9においてそれぞれ白丸および黒丸として表したものに相当する。

[0087] ステップ S30 :かくして各ルータ 3におけるテストパケットの通過状態が判明し、これを表示部（図 4の 35)に表示する。

[0088] 以上をまとめると、第 1実施例に係るマルチキャストツリー監視システム 10は、

ネットワーク中にほとんど流れることがない 64byte以下のパケットを監視用テストパケットとして送信する記載のマルチキャストフレーム配信装置（2T)と、

該 64byte以下のパケットの流入量を示す MIB情報（etherStatsUndersizePkts)を収集するマルチキャストツリー監視サーバ (4)と、

テストパケットの流入量に基づき MIB情報を生成するルータ 3と、を用い、該監視サーバ (4)が配信装置 (2T)に指示した送信サイズを有するパケットが入力されるルータ 3のインタフェース（ポート）を該 MIB情報から判定し、トポロジ管理テーブル 34に示す接続関係と該 MIB情報とから求めたパケットの流入方向をもとに、接続されたインタフェースにおけるフレームの配信方向を判定するように構成している。

[0089] 図 18は本発明の第 2実施例を適用した IPネットワーク（図 3)を表す図であり、図 19は図 18において実行される第 2実施例の動作を表すフローチャート (その 1) であり、

図 20は同フローチャート（その 2)である。

[0090] まず図 18を参照すると、本第 2実施例のもとでの動作は、下記 1.一 8.のようになる

[0091] 1.エンコーダ（2E)のサブネットにおける未使用アドレスを調査し、

2.各ルータ 3からテストパケット送信前の MIB (nlMatrixSDOctets)を収集し、

3.エンコーダ（2E)に対してテストパケットの送信用アドレスを指定してその送信を指示し、

4.その指定されたアドレスでテストパケットを一定量送信し、

5.ノレータ 3力ら MIB情報 (addressMapSource, addressMapNetworkAddress)を収集してテスト用アドレスの入力ポートを特定し、

6.再度、 nlMatrixSDOctetsを収集し、

7.流入量の多いインタフェース、およびその流入方向を判定して、

8.マルチキャストツリーを表示部 35に表示する。

[0092] さらに詳細な処理の流れを図 19および図 20を参照して説明する。なお図 19および図 20に示すフローチャートの各ステップのうち、前述した図 16および図 17でのステツプと実質的に同一のステップについては、図 16および図 17における対応するステツプと同一のステップ番号、すなわち S22、 S24、 S26— S30を付して示す。

[0093] したがって本第 2実施例の特徴をなすステップは、 S31、 S32および S33である。

[0094] ステップ S31 :監視サーバ（4)は、これから IPネットワーク 1に流そうとするテストパケット（本第 2実施例では図 13に示されるパケット）のカウント値を、各ルータ 3の MIB ( 図 4の 51)力も受信する。図 13のパケットの、監視テストの直前における、 MIB (51) 内の初期カウント値を入手するためである。すなわち、テスト直前におけるテストパケットの流入量がその初期カウント値より大幅にカウントアップしたとき、テストパケットが当該ルータを通過したものと判定する。

[0095] ステップ S32 :第 2実施例におけるテストパケット専用の IPアドレス（図 13の上段参照）を有するパケットを、各ルータ 3に向けて送信する。

[0096] ステップ S33 :図 13で規定されるパケットについての MIB情報を、各ルータ 3から受信する。以降のステップは、第 1実施例の場合 (S26— S30)と同じである。

[0097] 以上をまとめると、第 2実施例に係るマルチキャストツリー監視システム 10は、

特定の発信用 IPアドレス、ある、は特定の宛先マルチキャスト IPアドレスで監視用テストパケットを送信するマルチキャストフレーム配信装置（2T)と、

該テストパケットの入力インタフェース (ポート）を特定する MIB情報（

addressMapSourceおよび addressMapNetworkAddressリと、該テストノヽケットの流入量を計測する MIB情報（nlMatrixSDOctets)とを収集するマルチキャストツリー監視サーバ (4)と、

テストパケットの流入量に基づき MIB情報を生成するルータ 3と、を用い、該監視サーバ (4)が配信装置 (2T)に対して指示した送信アドレスと送信量とを有するパケットが観測されたルータ 3を nlMatrixSDOctetsにより判定し、かつ

addressMapSourceおよび addressMapNetworkAddressの収集結果により、トポロジ管理テーブル 34に示される接続リンクにおけるマルチキャストツリーの配信方向を判定するように構成している。

[0098] 図 21は本発明の第 3実施例（ # 1)を適用した IPネットワーク（図 3)を表す図であり図 22は図 21にお、て実行される第 3実施例（ # 1)の動作を表すフローチャート (その 1)であり、

図 23は同フローチャート（その 2)である。

[0099] まず図 21を参照すると、本第 3実施例（# 1)のもとでの動作は、下記 1.一 8.のようになる。

[0100] 1.エンコーダ（2E)のサブネットにおける未使用アドレスを調査し、

2.各ルータ 3からテストパケット送信前の MIB (icmpTimeExcds)を収集し、

3.エンコーダ（2E)に対しテストパケットの送信用アドレスを指定してその送信を指示し、

4.その指定されたアドレスおよび TTL1一 Nにてテストパケットを一定量送信し、

5. ノレータ 3力ら MIB情報 (addressMapSource, addressMapNetworkAddress)を収集し、テスト用アドレスの入力ポートを特定し、

6.再度、 ICMP time excc^パケットを収集し、

8.マルチキャストツリーを表示部 35に表示する。

[0101] さらに詳細な処理の流れを図 22および図 23を参照して説明する。なお図 22および図 23に示すフローチャートの各ステップのうち、前述した図 16および図 17でのステツプと実質的に同一のステップについては、図 16および図 17における対応するステツプと同一のステップ番号、すなわち S22、 S24、 S26— S30を付して示す。

[0102] したがって本第 3実施例（ # 1)の特徴をなすステップは、 S41、 S42および S43である。

[0103] ステップ S41 :監視サーバ（4)は、これから IPネットワーク 1に流そうとするテストパケット (本第 3実施例（# 1)では図 14に示されるパケットのカウント値)を、各ルータ 3の MIB (図 4の 51)力も受信する。図 14のパケットの、監視テストの直前における、 MIB (51)内の初期カウント値を入手するためである。すなわち、テスト直前におけるテストパケットの流入量がその初期カウント値より大幅にカウントアップしたとき、テストバケツトが当該ルータを通過したものと判定する。

[0104] ステップ S42 :TTL1から TTLNまで指定した各パケットを、指定した数だけ、各ルータ 3に向けて送信する。

[0105] ステップ S43 :図 14で規定されるパケットについての MIB情報を、各ルータ 3から直接、監視サーバ (4)にて受信する。以降のステップは、第 1実施例の場合 (S26— S3 0)と同じである。

[0106] 以上をまとめると、第 3実施例（ # 1)に係るマルチキャストツリー監視システム 10は、特定の発信用 IPアドレス、ある、は特定の宛先マルチキャスト IPアドレスおよび TT L= 1一 N (N：任意）を有するテストパケットを、指定された送信量ずつ配信するマルチキャストフレーム配信装置（2T)と、該テストパケットの入力インタフェース (ポート）を特定する MIB情報（ addressMapSourceおよび addressMapNetworkAddress)と、該テストノケットの TTL力 S 0になり該パケットを廃棄したことを示す MIB情報 (icmpOutTimeExcds)とを収集するマルチキャストツリー監視サーバ（4)と、

該 icmpOutTimeExcdsパケットの送信に基づき MIB情報を生成するルータ 3と、を用い、

該監視サーバ (4)が配信装置 (2T)に対して指示したパケット数だけ

icmpOutTimeExcdsパケットを送信したノレータ 3を抽出し、力つ addressMapSourceおよび addressMapNetworkAddressの収集結果に基づ、て、トポロジ管理テーブル 34の接続リンクにおけるマルチキャストツリーの配信方向を判定するように構成する。

[0107] 図 24は本発明の第 3実施例（ # 2)を適用した IPネットワークを表す図であり、図 25は図 24にお、て実行される第 3実施例（ # 2)の動作を表すフローチャートである。

[0108] 図 24を参照すると、本第 3実施例（# 2)のもとでの動作は、下記 1.一 5.のようになる。

[0109] 1.エンコーダ（2E)に対しテストパケットの送信用ポート番号を指定して、その送信を指示し、

2.その送信指示に従い、送信ポート番号 X+ 1— X+Nの各ポート番号に相当する TTL1一 Nを付与したテストパケットを一定量エンコーダ（2E)より送信し、

3. TTL1一 Nの各パケットに応答した ICMP time exceededパケットを返送したルータを監視サーバ (4)に通知し、

4.ポート番号と送信ルータのアドレスとをもとに、配信装置（2T)から該送信ルータ (time exceededパケットを返送したルータ）までのホップ数を判定し、配信インタフエース (ポート）および配信方向を判定して、

5.ツリーを表示部 35に表示する。

[0110] さらに詳細な処理の流れを図 25を参照して説明する。本図のフローチャート中、ステツプ S22と S30は前述のとおりであり、ステップ S51— 54が本第 3実施例（ # 2)の特徴をなす。 [0111] ステップ S51 :図 24において説明した上記の 2.の工程に相当するステップ S52および S53 :図 24において説明した上記の 3.および 4.の工程に相当し、ステップ S52では、各ルータ 3よりエンコーダ（2E)が受信した time exceededパケットを、各該 time exceededパケットに記述された上記の送信ポート番号をもとに、 T TL1一 Nの順に並べたルータリストをエンコーダ（2E)が作成し、これを監視サーバ（ 4)に転送する。

[0112] さらにステップ S53では、エンコーダ（2E)より受信した上記の TTL1一 Nの順に並ベたルータリストを、監視サーバ (4)内の判定部 33 (図 4)にて分析して、テストパケットの転送経路 (通過状態情報)を判定する。

[0113] ステップ 54 :上記のテストパケットの転送経路をもとに、マルチキャストの方向をトポロジ管理テーブル 34に設定する。

[0114] 以上をまとめると、第 3実施例（ # 2)に係るマルチキャストツリー監視システム 10は、

TTL= 1一 N (N :任意）と、 TTLの値に対応する送信ポート番号または宛先ポート番号 (X+ 1— X+N、 X：任意、 N :TTLの値）により特定されたテストパケットを、指定された送信量ずつ配信し、各ルータ 3から返送された ICMP time exceededパケットを、送信結果として、監視サーバ (4)に返送するマルチキャストフレーム配信装置（2 T)と、

返送された該 ICMP time exceededパケットを配信装置（2T)より収集するマルチキャストツリー監視サーバ (4)と、

該 ICMP time exceededパケットの情報を監視サーバ（4)に送信するルータ 3と、を用い、

該マルチキャストフレーム配信装置（2T)から返送された ICMP time exceededパケットを解析し、該 ICMP time exceededパケットを送信したルータ 3の IPアドレス、および、送信ポート番号あるいは宛先ポート番号から、該マルチキャストフレーム配信装置（2T)力当該ルータ 3までのホップ数を判定し、トポロジ管理テーブル 34に示す隣接ルータ関係と該ホップ数とから、マルチキャストフレームの配信方向を判定するように構成する。

[0115] さらに本発明の第 4実施例としては、 IPネットワーク 1における障害検知システムを提供する。すなわち本発明のマルチキャストツリー監視システム 10は、障害検知システムとしても機能することができる。このことについては、図 4の障害検知判定部 36として既に説明した力ここではその障害検知システムの全体について示す。

[0116] 図 26は第 4実施例としての障害検知システムを適用した IPネットワーク 1を表す図である。本図において、例えば光ファイバの断線あるいはルータ 3の故障が原因で本図中の F (fault)点にて障害が発生したものとすると、本発明のマルチキャストツリー監視を利用すれば、力かる障害箇所 (F)を簡単に特定することができる。

[0117] このために、本図の例では前述した第 3実施例を利用する。すなわち、送信端末 2 丁より、 TTLを 1から Nまで設定した各テストパケットをネットワーク上に流すと、各ルータ 3から time exceededパケットが送信端末 2Tに返送され、監視サーバ（4)においては該当のカウンタのカウント値が増加する。

[0118] ところが、障害箇所 (F点）より下流側にあるルータ（3a、 3bおよび 3c)には上記のテストパケットが到達し得ない。このため、図 26中の点線 Aa、 Abおよび Acのように IC MP time exceededパケットの戻りがなぐ監視サーバ（4)から見てこれらのルータ 3a 、 3bおよび 3cに該当する各カウンタのカウント値は一定値に止まったままとなる。この結果監視サーバ (4)は、これらのサーバから最も送信端末 2Tに近、サーバ（3a)の近傍において障害が発生したものと推定し、障害判定部 36より障害検知情報 ALM を発出する。

[0119] 以上の説明では、 ICMP time exceededパケットの欠落を検知することにより障害を見つけるようにして、るが、これに限らず MIB情報の欠落を監視することによつても同様に障害を見つけることができる。

[0120] このように本発明を実施するには特定のテストパケットの存在が重要である。このため、前述した説明では、 RTPヘッダ、 TTL、送信元ポート番号等が用いられている。そこでテストパケットとなる送信用フレームの実例を図に示しておく。

[0121] 図 27 (a)—（d)は送信用フレームのヘッダフォーマットを示す図であり、本図の（a) には Etherフレームの全体を示し、その中の IPヘッダと UDPヘッダと RTPヘッダとをそれぞれ本図の (b)、（c)および (d)に詳細に示す。前述した第 1形態 (i)のテストパケットは、ここで示した RTPヘッダ（d)までの 56byteのフレームを生成することで実現できる。またその他の形態（ii)および (m)のテストパケットについては、各レイヤのへッダ情報にお、て、 IPヘッダ内の TTL (b)や UDPヘッダ内のポート番号（c)等を所望の値に設定することで実現できる。

以上説明したように本発明によれば、簡易な手法でマルチキャストツリーの認識と疎通確認とを実現でき、従来何時間も力かって調査して、たマルチキャストツリーの監視を、数分程度で完了することができる。

Claims

請求の範囲

[1] マルチキャストフレームを配信する送信端末と、該マルチキャストフレームを受信する複数の受信端末と、該送信端末から該複数の受信端末へ向けて形成されるツリー状のマルチキャストフレーム伝送経路上に複数配置されるルータと、を含んで構成される IPネットワークにおいて、前記マルチキャストフレームの伝送経路をネットワーク監視装置によって探索するためのマルチキャストツリー監視方法であって、

前記ネットワーク監視装置から前記送信端末に対し、通常配信される前記マルチキヤストフレームとは区別される監視用のテストパケットを送信すべきことを指示する第 1 のステップと、

前記送信端末において、前記指示に従って前記テストパケットを前記ルータに向けて送信する第 2のステップと、

送信された前記テストパケットを受信しこれを通過させた前記ルータの各々にお!/ヽて、該テストパケットの通過状態情報を生成する第 3のステップと、

前記ネットワーク監視装置にお!ヽて、各前記ルータから収集した前記通過状態情報に基づいて前記テストパケットの前記 IPネットワーク上での配信方向を判定し、この判定結果により前記ツリー状の伝送経路を特定する第 4のステップと、

を有することを特徴とする IPネットワークにおけるマルチキャストツリー監視方法。

[2] 前記第 1のステップにおける前記監視用のテストパケットは、（i)前記マルチキャストフレームとしては通常採用されることがないデータ長を有するパケット、（ii)未使用の

、発信用 ipアドレスあるいは宛先マルチキャスト ipアドレスを有するパケット、（ )パケットの有効時間 TTL (Time To Live)が 1から、予め指定した Nまで設定されたパケット、のいずれかから選択されると共に、予め定めた一定量の該テストパケットが連続的に送信されることを特徴とする請求項 1に記載のマルチキャストツリー監視方法。

[3] 前記第 3のステップにおける前記通過状態情報は、ネットワーク管理用データべ一ス MIB (Management Information Base)情報として生成されることを特徴とする請求項 1に記載のマルチキャストツリー監視方法。

[4] 前記第 4のステップにおける前記の判定は、前記ネットワーク監視装置内にあって隣接ルータとの接続関係を保持するトポロジ管理テーブルを参照して行われることを特徴とする請求項 1に記載のマルチキャストツリー監視方法。

[5] マルチキャストフレームを配信する送信端末と、該マルチキャストフレームを受信する複数の受信端末と、該送信端末から該複数の受信端末へ向けて形成されるツリー状のマルチキャストフレーム伝送経路上に複数配置されるルータと、を含んで構成される IPネットワークにおいて、前記マルチキャストフレームの伝送経路をネットワーク監視装置によって探索するためのマルチキャストツリー監視システムであって、前記ネットワーク監視装置に設けられ、通常配信される前記マルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを前記送信端末に対し指示する指示機能部と、

前記送信端末に設けられ、前記指示に従って前記テストパケットを前記ルータに向けて送信する送信機能部と、

送信された前記テストパケットを受信しこれを通過させた各前記ルータに設けられ、その通過させたテストパケットの通過状態情報を生成する状態情報生成機能部と、前記ネットワーク監視装置にさらに設けられ、各前記ルータから収集した前記通過状態情報に基づいて前記テストパケットの前記 IPネットワーク上での配信方向を判定し、この判定結果により前記ツリー状のマルチキャストフレーム伝送経路を特定する判定機能部と、

を含んで構成されることを特徴とするマルチキャストツリー監視システム。

[6] マルチキャストフレームを配信する送信端末と、該マルチキャストフレームを受信する複数の受信端末と、該送信端末から該複数の受信粉末へ向けて形成されるツリー状のマルチキャストフレーム伝送経路上に複数配置されるルータと、を含んで構成される IPネットワークにおいて、前記マルチキャストフレームの伝送経路をネットワーク監視装置によって探索するためのマルチキャストツリー監視システムを形成する該ネットワーク監視装置であって、

通常配信される前記マルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを、前記送信端末に対し指示する指示機能部と、

送信された前記テストパケットを受信しこれを通過させた各前記ルータにて生成された該テストパケットの通過状態情報に基づ、て、該テストパケットの前記 IPネットヮーク上での配信方向を判定し、この判定結果により前記ツリー状のマルチキャストフレーム伝送経路を特定する判定機能部と、

を備えることを特徴とするネットワーク監視装置。

[7] 前記判定機能部は、各前記ルータからそれぞれの前記通過状態情報を収集する状態情報収集部と、収集された該通過状態情報を格納する状態情報格納部と、格納された該通過状態情報をもとに前記配信方向を判定するマルチキャストパス判定部と、を有することを特徴とする請求項 6に記載のネットワーク監視装置。

[8] 前記判定機能部は、前記状態情報格納部に格納された前記テストパケットの送信直前の前記通過状態情報と、そのテストパケットの送信後の該通過状態情報との差分が大であるときに前記の判定を行うことを特徴とする請求項 7に記載のネットワーク監視装置。

[9] 前記判定機能部は、前記配信方向の判定のために参照する、隣接ルータとの接続関係を保持するトポロジ管理テーブルを有することを特徴とする請求項 6に記載のネットワーク監視装置。

[10] 前記判定機能部は、前記判定結果により特定された前記ツリー状のマルチキャストフレーム伝送経路の構成を表示するツリー表示部を有することを特徴とする請求項 6 に記載のネットワーク監視装置。

[11] マルチキャストフレームを配信する送信端末と、該マルチキャストフレームを受信する複数の受信端末と、該送信端末から該複数の受信端末へ向けて形成されるツリー状のマルチキャストフレーム伝送経路上に複数配置されるルータと、を含んで構成される IPネットワークにおいて、前記マルチキャストフレームの伝送経路をネットワーク監視装置によって探索するためのマルチキャストツリー監視システムを形成する該送信端末であって、

通常配信される前記マルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを示す前記ネットワーク監視装置力もの指示を受けて、前記テストパケットを前記ルータに向けて送信する送信機能部を備えることを特徴とする送信端末。

[12] 前記送信機能部は、前記監視用のテストパケットを送信すべきことを示す前記ネットワーク監視装置力の指示を受け付けるツリー監視要求受付部と、その指示を受け付けて前記テストパケットを生成し送信するテストパケット送信部と、を有することを特徴とする請求項 11に記載の送信端末。

[13] 前記テストパケット送信部にて生成しかつ送信される前記テストパケットは、（i)前記マルチキャストフレームとしては通常採用されることがないデータ長を有するパケット、 (ii)未使用の、発信用 IPアドレスあるいは宛先マルチキャスト IPアドレスを有するパケット、（iii)パケットの有効時間 TTL (Time To Live)力^から、予め指定した Nまで設定されたパケット、のいずれかから選択されると共に、予め定めた一定量の該テストパケットが連続的に送信されることを特徴とする請求項 12に記載の送信端末。

[14] マルチキャストフレームを配信する送信端末と、該マルチキャストフレームを受信する複数の受信端末と、該送信端末から該複数の受信端末へ向けて形成されるツリー状のマルチキャストフレーム伝送経路上に複数配置されるルータと、を含んで構成される IPネットワークにおいて、前記マルチキャストフレームの伝送経路をネットワーク監視装置によって探索するためのマルチキャストツリー監視システムを形成する該ルータであって、

前記送信端末より送信された前記テストパケットを受信しこれを通過させた際の該テストパケットの通過状態情報を、前記ネットワーク監視装置による前記の探索に供するために生成する状態情報生成機能部を備えてなることを特徴とするルータ。

[15] 前記状態情報生成機能部は、ネットワーク管理用データベース (MIB)と、該ネットワーク管理用データベース (MIB)により生成された前記通過状態情報を、直接または前記送信端末を介して、前記ネットワーク監視装置に送信する状態情報送信部と、を有することを特徴とする請求項 14に記載のルータ。

[16] 前記判定機能部は、前記判定結果により特定された前記ツリー状のマルチキャストフレーム伝送経路力前記マルチキャストフレームを受信すべき全ての前記受信端末には到達していないと判断したとき障害検知情報を発生する障害判定部をさらに有することを特徴とする請求項 6に記載のネットワーク監視装置。