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

Description

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

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

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

なお本発明に関連する公知技術としては下記の〔特許文献１〕があり、この特許文献１には、
「ネットワーク上にフィールド管理プロセス（ＦＭ）を置き、ホスト（１〜３）にフィールドクライアントプロセス（ＦＣ）を置き、各サブネットにサブネット管理プロセス（ＳＭ）を置き、ネットワーク上の複数端末間の通信手段としての情報バス生成要求をフィールド管理プロセス（ＦＭ）がフィールドクライアントプロセス（ＦＣ）を経由してユーザから受けると、フィールド管理プロセス（ＦＭ）がサブネット間の接続ポイントを決定し、それに応じたサブネット管理プロセス（ＳＭ）へマルチキャスト・トンネリング設定の指示を出して設定することで、各端末がマルチキャストアドレスを指定してデータを送出し、グループ間通信をサポートする情報バスを動的に生成する」
ことにより、論理的なマルチキャスト網を動的に構築して計算機資源やネットワーク資源の効率的な利用を図ることが記載されている。

また当業者に周知の従来例として後述する図２８および図２９を参照しながら説明するマルチキャスト監視のための手法がある。しかしこの従来例の手法には後述する問題がある。
特開２００１−１５６８５５号公報

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

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

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

（２）また図２９に示すように、実際に運用しているツリーの疎通確認を行うためには個々の宛先の端末に向けてｐｉｎｇやｔｒａｃｅｒｏｕｔｅを実行しなければならなかったが、これでは配信先が多いと処理に多大な時間がかかり、また、必ずしもユニキャストの経路（図中、ＳＰＴの経路）と、マルチキャストの経路（図中、ＲＰＴの経路）とが同一経路とは限らないため、正しい経路の確認ができないという第２の問題があった。なお、図中の記号の意味は、下記のとおりである。

ＲＰＴ：Rendezvous Point Tree
ＳＰＴ：Shortest Path Tree
ＤＲ：Designated Router
上記（２）の問題点をさらに詳しく説明すると次のとおりである。

ＩＰネットワークにおいて、ＰＩＭ−ＳＭ（Protocol Independent Multicast Sparse Mode）と呼ばれるマルチキャスト用の制御プロトコルを用いたマルチキャスト配信が広く用いられている。ＰＩＭ−ＳＭでは、ＲＰ（Rendezvous Point）に設定されたルータが全ての配信先にマルチキャストする場合と、ＲＰの負荷を軽減するためにいくつかの宛先に対しては送信元に接続されているＤＲ（Designated Router）で分配しユニキャストルーチングに従ってパケットを配信する場合とがある。

このようなＰＩＭ−ＳＭでは、送信元から各宛先に対してＲＰ経由（ＲＰＴ：RP Tree）で配信されているのか、あるいは、送信元からのユニキャストルーチング（ＳＰＴ：Shortest Path Tree）で配信されているのか、各ルータの設定情報等を詳細に調査しなければ分からない。また、ＲＰＴによる配信では、ユニキャストルーチングと経路が異なるため、エンド・ツー・エンドで疎通確認を行おうとしてもｐｉｎｇやｔｒａｃｅｒｏｕｔｅ等では疎通確認ができない。

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

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

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

図１は、本発明に係るマルチキャストツリー監視システム１０の基本構成を示す図である。 図２は、図１に示すマルチキャストツリー監視システム１０の監視動作を示すフローチャートである。 図３は、本発明に基づくマルチキャストツリー監視システムが適用されるＩＰネットワーク１の具体的イメージを示す図である。 図４は、本発明に基づくマルチキャストツリー監視システム１０の具体的構成例を示す図である。 図５は、本発明の経路判定動作を説明するために図３の一部を取り出して示す図（その１）である。 図６は、トポロジ管理テーブル３４の構成例を示す図である。 図７は、判定条件の項目を埋めた判定部３３による判定結果を示す図である。 図８は、経路状態の判定結果を例示する図である。 図９は、最終的な判定部３３による判定結果を例示する図である。 図１０は、本発明の経路判定動作を説明するために図３の一部を取り出して示す図（その２）である。 図１１は、図１０のもとでの、判定部３３による最終的な判定結果を示す図である。 図１２は、ＭＩＢのオブジェクトの第１例を表す図である。 図１３は、ＭＩＢのオブジェクトの第２例を表す図である。 図１４は、ＭＩＢのオブジェクトの第３例を表す図である。 図１５は、本発明の第１実施例を適用したＩＰネットワーク（図３）を表す図である。 図１６は、図１５において実行される第１実施例の動作を表すフローチャート（その１）である。 図１７は、図１５において実行される第１実施例の動作を表すフローチャート（その２）である。 図１８は、本発明の第２実施例を適用したＩＰネットワーク（図３）を表す図である。 図１９は、図１８において実行される第２実施例の動作を表すフローチャート（その１）である。 図２０は、図１８において実行される第２実施例の動作を表すフローチャート（その２）である。 図２１は、本発明の第３実施例（＃１）を適用したＩＰネットワーク（図３）を表す図である。 図２２は、図２１において実行される第３実施例（＃１）の動作を表すフローチャート（その１）である。 図２３は、図２１において実行される第３実施例（＃１）の動作を表すフローチャート（その２）である。 図２４は、本発明の第３実施例（＃２）を適用したＩＰネットワークを表す図である。 図２５は、図２４において実行される第３実施例（＃２）の動作を表すフローチャートである。 図２６は、第４実施例としての障害検知システムを適用したＩＰネットワークを表す図である。 図２７の（ａ）〜（ｄ）は、送信用フレームのヘッダフォーマットを示す図である。 図２８は、ＩＰマルチキャストネットワークにおける障害事例を表す図である。 図２９は、従来技術の問題点の１つを説明するための伝送経路例を表す図である。

図１は本発明に係るマルチキャストツリー監視システムの基本構成を示す図である。本監視システムは参照番号１０で示されており、その代表的な構成要素（後述）は参照番号１１〜１４で示す。本発明に係るこのマルチキャストツリー監視システム１０は、その前提としてＩＰネットワーク１内に形成される。

このＩＰネットワーク１は、図示するとおり、端末２と、ルータ３と、ネットワーク監視装置４とを含んでなり、該ネットワーク監視装置４によってマルチキャストフレームの伝送経路を探索する。もう少し詳しく言えばこのＩＰネットワーク１は、マルチキャストフレームを配信する送信端末（ＴＸ）２Ｔと、そのマルチキャストフレームを受信する複数の受信端末（ＲＸ）２Ｒと、その送信端末２Ｔから複数の受信端末２Ｒへ向けて形成されるツリー状のマルチキャストフレーム伝送経路上に複数配置されるルータ３と、を含んで構成される。

このＩＰネットワーク１内に形成されるマルチキャストツリー監視システム１０は、上述したように、代表的に、指示機能部１１と、送信機能部１２と、状態情報生成機能部１３と、判定機能部１４と、から構成される。これら機能部１１〜１４の主たる機能は次のとおりである。

指示機能部１１は、ネットワーク監視装置４に設けられ、通常配信されるマルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを送信端末２Ｔに対し指示する機能を備え、
送信機能部１２は、送信端末２Ｔに設けられ、上記の指示に従ってテストパケットをルータ３に向けて送信する機能を備え、
状態情報生成機能部１３は、送信されたテストパケットを受信しこれを通過させた各ルータ３に設けられ、その通過させたテストパケットの通過状態情報を生成する機能を備え、
判定機能部１４は、ネットワーク監視装置４にさらに設けられ、各ルータ３から収集した通過状態情報に基づいてテストパケットのＩＰネットワーク１上での配信方向を判定し、この判定結果によりツリー状のマルチキャストフレーム伝送経路を特定する機能を備える。

図２は上述した図１のマルチキャストツリー監視システム１０において実行されるマルチキャストツリー監視方法を表すフローチャートである。すなわち、マルチキャストフレームの伝送経路をネットワーク監視装置４によって探索するための本発明によるマルチキャストツリー監視方法は、本図に示すステップＳ１１〜Ｓ１４によって実行される。

ステップＳ１１：ネットワーク監視装置４から送信端末２Ｔに対し、通常配信されるマルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを指示し、
ステップＳ１２：送信端末２Ｔにおいて、上記の指示に従ってテストパケットをルータ３に向けて送信し、
ステップＳ１３：送信されたテストパケットを受信しこれを通過させたルータ３の各々において、そのテストパケットの通過状態情報を生成し、
ステップＳ１４：ネットワーク監視装置４において、各ルータ３から収集した上記の通過状態情報に基づいて、テストパケットのＩＰネットワーク１上での配信方向を判定し、この判定結果により上記ツリー状の伝送経路を特定する。

さらに具体的には、上記第１のステップＳ１１において、監視用のテストパケットは、
（ｉ）マルチキャストフレームとしては通常採用されることがないデータ長を有するパケット、
（ii）未使用の、発信用ＩＰアドレスあるいは宛先マルチキャストＩＰアドレスを有するパケット、
（iii）パケットの有効時間ＴＴＬ（Time To Live）が１から、予め指定したＮまで設定されたパケット、
のいずれかから選択され、そして予め定めた一定量のテストパケットが連続的に送信されるようにする。

さらに上記第３のステップＳ１３において、上記の通過状態情報は好ましくは、ネットワーク管理用データベースＭＩＢ（Management Information Base）情報として生成される。

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

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

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

本図の構成はＩＰネットワーク１を具体的に表しており、前述したマルチキャストツリー監視システム（図１の参照番号１１〜１４）については記載を省略している。これは、本発明によるマルチキャストツリーの伝送経路のイメージをより一層分かりやすくするためである。すなわち本図を参照すると、送信端末２Ｔ（本図の例ではカメラ）からのマルチキャストフレーム（映像情報）が、ＩＰネットワーク１上の所定のルータ３を経由して、所定の受信端末２Ｒ（本図の例ではパソコン）に転送される様子が示されており、ここにその転送ルートがマルチキャストツリーをなす伝送経路５となる。

まずネットワーク監視装置４について見ると、この中には前述した図１の指示機能部１１と判定機能部１４とが含まれる。なおこのネットワーク監視装置４、例えばマルチキャストツリー監視サーバは、通常はＩＰネットワーク１内に元々設けられているものであって、この既存のサーバ内に上記機能部１１および１４を本発明によって新たに追加することになる。このネットワーク監視装置４は、この他にトポロジ管理テーブルや状態情報（ＭＩＢ）収集部等も含まれる。

一方図３の送信端末（カメラとして示す）２Ｔはいわばマルチキャスト・ストリーム配信装置であって、ネットワーク監視装置４からのテストパケット送信指示があったとき、該配信装置（２Ｔ）は、
（ｉ）マルチキャストフレームとしては通常採用されることがないデータ長を有するパケット、
（ii）未使用の、発信用ＩＰアドレスあるいは宛先マルチキャストＩＰアドレスを有するパケット、
（iii）パケットの有効時間ＴＴＬ（Time To Live）が１から、予め指定したＮまで設定されたパケット、
のいずれかからなるテストパケットを伝送経路５上に流す。つまり通常マルチキャストフレームとして存在することが殆どないフレームをテストパケットとして一定量、連続的に流す。

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

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

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

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

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

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

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

また判定機能部１４は、隣接ルータとの接続関係を保持するトポロジ管理テーブル３４をも有し、上述した配信方向の判定のために参照する。

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

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

このテストパケット送信部４２にて生成しかつ送信されるテストパケットＰｔは、前述したパケット（ｉ）、（ii）および（iii）のいずれかから選択されると共に、予め定めた一定量のテストパケットＰｔが連続的に送信される。

次にルータ３について見ると、前述の図１においてはこのルータ３を、送信端末２Ｔより送信されたテストパケットＰｔを受信しこれを通過させた際のそのテストパケットの通過状態情報を、ネットワーク監視装置４による前述の探索に供するために生成する状態情報生成機能部１３として示したが、図４においては、この状態情報生成機能部１３は、ネットワーク管理用データベース（ＭＩＢ）５１と、このネットワーク管理用データベース（ＭＩＢ）５１により生成された通過状態情報を、直接または送信端末２Ｔを介して、ネットワーク監視装置４に送信する状態情報送信部５２とから構成している。なお、スイッチ部５３はルータ３に既存の本来のルーティングという役割を果たすものである。

なお後に図２６を参照して説明するとおり、本発明によるマルチキャストツリー監視方法によれば、ＩＰネットワーク１内の障害検知といった機能も簡単に実現することができる。このために、図４に示す判定機能部１４は、前述した判定部３３による判定結果により特定されたツリー状のマルチキャストフレーム伝送経路５が、マルチキャストフレームを受信すべき全ての受信端末２Ｒには到達していないと判断したとき障害検知情報ＡＬＭを発生する障害判定部３６をさらに備えることができる。

図４に示すマルチキャストツリー監視システム１０の実際の構成例によると、ネットワーク監視装置４は「マルチキャストツリー監視サーバ」であり、その中の状態情報収集部３１は「ＳＮＭＰ送受信部」（ＳＮＭＰ：Simple Network Management Protocol）であり、また状態情報格納部３２は「ＭＩＢ情報格納部」である。さらに図４に示す送信端末２Ｔは「マルチキャストフレーム配信装置」であり、さらにまた図４に示すルータ３内のネットワーク管理データベース（ＤＢ）は「ＭＩＢ」であり、その中の状態情報送信部は「ＳＮＭＰ送受信部」である。かかる実際の構成例においては、本発明のマルチキャストツリー監視システム１０は、マルチキャストツリー監視サーバ（４）、マルチキャストフレーム配信装置（２Ｔ）、およびルータ３からなる。

このマルチキャストツリー監視サーバ（４）において、
マルチキャストパス判定部３３は、マルチキャストフレーム配信装置（２Ｔ）に対してツリー監視用のテストパケット配信を指示したり、
ルータ３からＭＩＢ情報を取得するためＳＮＭＰ送受信部（３１）にＭＩＢ（例えば、ＲＭＯＮ（Remote Network Monitoring）ＭＩＢ）収集を指示したり、
ＭＩＢ情報格納部（３２）から収集したＭＩＢ情報を収集したり、
トポロジ管理テーブル３４から各ルータ３の接続関係を把握したり、
ツリー表示部３５に配信装置（２Ｔ）から受信端末２Ｒまでのツリーの構築結果を通知するようにしている。

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

またツリー監視実行指示部２１は、マルチキャストフレーム配信装置（２Ｔ）に対して配信テストパケットのアドレス、テストパケットのパケットサイズ、ＴＴＬ、およびポート番号を配信装置（２Ｔ）に通知し、配信装置（２Ｔ）からの実行終了結果をマルチキャストパス判定部３３に通知するようにしている。これにより、ツリーを識別するために必要なＭＩＢ情報やＩＣＭＰ（Internet Control Message Protocol）でのtime exceededパケットを抽出することができる。

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

ＭＩＢ情報格納部（３２）は、ルータ３から収集したＭＩＢ情報を格納するようにしている。これにより、マルチキャストパス判定部３３が必要なＭＩＢ情報を解析できる。

ＳＮＭＰ送受信部３１はマルチキャストパス判定部３３からの指示により、各ルータ３からＭＩＢ情報を収集するためのＳＮＭＰコマンドを実行するようにしている。これによりＭＩＢ情報格納部（３２）に格納する情報を収集できる。

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

マルチキャストストリーム配信装置（２Ｔ）において、
ツリー監視要求受付部４１は、マルチキャストツリー監視サーバ（４）のツリー監視実行指示部２１からの指示およびパラメータを受け付け、テストパケット送信部４２に送信の実行を指示したり、
送信終了、およびＩＣＭＰでのtime exceededパケットの受信結果を、マルチキャストツリー監視サーバ（４）に返送するようにしている。

テストパケット送信部４２は、指定されたアドレス、ＴＴＬ、ポート番号、パケットサイズで、テストパケットを送信するようにしている。これにより、マルチキャストツリー監視サーバ（４）で必要なＭＩＢ情報等を収集できる。

ルータ３において、
スイッチ部５３は、マルチキャストフレーム配信装置（２Ｔ）からのテストパケットをルーティングするようにしている。これによりテストパケットを他のルータ、あるいは受信端末２Ｒにルーティングすることができる。

ＳＮＭＰ送受信部（５２）は、マルチキャストツリー監視サーバ（４）からのＳＮＭＰ Ｒｅｑｕｅｓｔに対し、ＭＩＢ情報をもって応答するようにしている。これにより、マルチキャストツリー監視サーバで必要なＭＩＢ情報を収集できる。

ＭＩＢ（５１）はテストパケットの受信に基づき受信パケット数等を累積するようにしている。これにより、マルチキャストツリー監視サーバ（４）で必要なＭＩＢ情報を収集することができる。

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

次に図３に示すＩＰネットワーク１内の任意の一部に注目して、マルチキャストツリー伝送経路５の判定手法を、図５〜図１１を参照して具体的に説明する。

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

図６はトポロジ管理テーブル３４の構成例を示す図である。ただし、ルータ３のうちの“Router１”についての管理テーブルを示し、他の“Router２”、“Router３”…についてはそれぞれ個別に管理テーブルが用意される。

図５を参照すると、ルータ（Router１）３のポートＰ１、Ｐ２およびＰ３は、それぞれ隣接ルータRouter２のポートＰ２に接続し、Router３のポートＰ１に接続し、Router５のポートＰ１に接続しているから、Router１についてのトポロジ管理テーブル３４の内容は図６に示すごとくなる。

次に、図６のテーブル３４における判定条件を決定する。そこで、上述のとおり、まず送信端末２ＴよりテストパケットＰｔを短時間のうちに大量に送信する（図４の４２）。このテストパケットの送信に起因して各ルータ３にて発生するＭＩＢ情報を蓄積する（図４の５１）。さらにそのＭＩＢ情報を収集した上で分析し、各ルータ３の各ポートＰにおけるテストパケットの配信方向を判定する。これを図７に示す。

図７は判定条件の項目を埋めた判定部３３による判定結果を示す。テストパケットの流入量が多いか少ないか、については、ある閾値を設定してそれより多いか少ないかで判断する。その閾値（ＴＨ）は、送信端末２Ｔより送信されるテストパケットの量（例えば１００パケットとする）とほぼ同じ値とする（ＴＨ＝１００）。あるいは、伝送途中での若干のパケットロスを考慮して、１００より小さい値とする（例：９０＜ＴＨ＜１００）。かくしてその閾値ＴＨを用いて、判定条件の項目の黒丸と白丸が定まる。そしてこれら黒丸と白丸とにより既述した通過状態情報（テストパケットの経路状態情報）が判定される。これを図８に示す。

図８は経路状態の判定結果を例示する図である。本図の右矢印、左矢印および両矢印は、Router１のポートＰ１、Ｐ２およびＰ３におけるテストパケットの配信方向すなわち経路状態（各ルータでの通過状態）を示す。結局、図９に示すテーブル３４が完成する。

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

図１０も、図５と同様、本発明の経路判定動作を説明するために図３の一部を取り出して示す図であるが、図５と異なるのは黒丸と白丸の記載がないことである。これは、図１０において用いるテストパケットが、第３形態（iii）すなわちＴＴＬを利用する形態のテストパケットを採用しているからであり、図５における第１形態（ｉ）すなわち短いデータ長を用いる形態のテストパケットあるいは第２形態（ii）すなわち通常あり得ない発信元アドレス及び／又は宛先アドレスを用いる形態のテストパケットとは異なる。

図１０において、ＴＴＬ＝３に設定してテストパケット送信部４２（図４）より送信されたテストパケットは、Routerを１つ通過する毎にそのＴＴＬ値が１ずつ減算され例えばRouter５に到ってＴＴＬ＝０になるとtime exceededパケットが、このRouter５から直接（または送信端末２Ｔを介して間接に）、状態情報収集部３１（図４）に収集される。同様に、
ＴＴＬ＝４に設定されたテストパケットはRouter１に到ってＴＴＬ＝０となってそのtime exceededパケットが状態情報収集部３１に収集され、
ＴＴＬ＝５に設定されたテストパケットはRouter２およびRouter５に到ってそれぞれＴＴＬ＝０となってそのtime exceededパケットが状態情報収集部３１に収集され、
ＴＴＬ＝６に設定されたテストパケットはRouter６に到ってＴＴＬ＝０となってそのtime exceededパケットが状態情報収集部３１に収集される。

図１１は上述したＴＴＬをパラメータとするテストパケットを利用した場合の、最終的な判定部３３による判定結果を示す図である。図５と同一のネットワークを前提とするから、この判定結果は、当然、図９の判定結果と同じになる。

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

図１２はＭＩＢのオブジェクトの第１例を示す図であって、前述したテストパケットの第１形態（ｉ）を示し、
図１３はＭＩＢのオブジェクトの第２例を示す図であって、前述したテストパケットの第２形態（ii）を示し、
図１４はＭＩＢのオブジェクトの第３例を示す図であって、前述したテストパケットの第３形態（iii）を示す。

すなわち図１２は、マルチキャストフレームとしては通常採用されることがないデータ長を有する第１形態（ｉ）のテストパケットをＰｔとして示し、データ長が６４byte以下のものをテストパケットとしている。図１３は、未使用の、発信用ＩＰアドレスあるいは宛先マルチキャストＩＰアドレスを有する第２形態（ii）のテストパケットの特徴を表している。また図１４は、パケットの有効時間ＴＴＬ（Time To Live）が１から、予め指定したＮまで設定された第３形態（iii）のテストパケットの特徴を表している。

上記の図１２、図１３および図１４についてもう少し具体的に説明すると、これらの図１２〜図１４は、マルチキャストツリーの認識に必要となるＭＩＢ情報を示す。テストパケットの流入量で監視する場合は、通常流れることがない６４byte以下のフレームを例えばetherStatsUndersizePkts（図１２）を用いて送信し、その流入量を計測することでマルチキャストツリーを認識できる。

あるいは、特定の送信ＩＰアドレスなどを用い、その送信ＩＰアドレスと宛先ＩＰマルチキャストアドレスを用いたテストパケットを送信し、そのテストパケット数を計測するnlMatrixSDOctets（図１３）を用いることでもマルチキャストツリーの認識が可能である。この場合は、そのテストパケットが流入するポートを識別するために、addressMapSource（ポート番号）、およびaddressMapNetworkAddress（上記addressMapSourceへ入力される送信ＩＰアドレスの一覧）の収集も必要となる。

あるいは、ＴＴＬを１からＮまで設定した各テストパケットを送信し、ＴＴＬが０になったルータであることを示すＩＣＭＰ time exceededパケットを送信する際にその送信パケット数を計測するicmpOutTimeExcdsを用いて、マルチキャストツリーを認識することが可能である。この場合も、addressMapSource、およびaddressMapNetworkAddressの収集が必要である。

次に上述した第１形態（ｉ）、第２形態（ii）および第３形態（iii）の各テストパケットをそれぞれ用いた第１、第２および第３実施例を説明する。なお、これらの第１、第２および第３実施例は、上述の図４〜図１４で説明した構成を、図３のＩＰネットワーク１上でそれぞれ具現化したものである。

図１５は本発明の第１実施例を適用したＩＰネットワーク（図３）を表す図であり、
図１６は図１５において実行される第１実施例の動作を表すフローチャート（その１）であり、
図１７は同フローチャート（その２）である。

まず図１５を参照すると、本第１実施例のもとでの動作は、下記１．〜６．のようになる。なお送信端末（マルチキャストフレーム配信装置）としては、映像情報をＭＰＥＧ等にフォーマット化するエンコーダ（２Ｅ）として示す。

１．各ルータ３からテストパケット送信前のＭＩＢ（etherStatsUndersizePkts）を収集し、
２．エンコーダ（２Ｅ）にテストパケットの送信を指示し、
３．ＲＴＰ（Realtime Transfer Protocol）ヘッダのみのテストパケットを一定量送信し、
４．再度、ルータ３からＭＩＢ（etherStatsUndersizesPkts）情報を収集し、
５．流入量の多いインタフェース（ポート）、および流入方向を判定して、
６．マルチキャストツリーを表示部３５に表示する。

さらに詳細な処理の流れを図１６および図１７を参照して説明する。

ステップＳ２１：監視サーバ（４）は、これからＩＰネットワーク１に流そうとするテストパケット（本第１実施例では、図１２の最上段のetherStatsUndersizePkts）のカウント値を、各ルータ３のＭＩＢ（図４の５１）から受信する。ＭＩＢ（５１）におけるetherStatsUndersizePktsの監視テストの直前における初期カウント値を入手するためである。すなわち、テストパケットの流入量がこの初期カウント値より大幅にカウントアップしたとき、テストパケットが当該ルータを通過したものと判定する。

ステップＳ２２：監視サーバ（４）はエンコーダ（２Ｅ）に対し、短時間に大量に流すべきテストパケットの個数を指定してその送信を指示する。

ステップＳ２３：上記の送信指示を受信したエンコーダ（２Ｅ）は、ＲＴＰヘッダのみからなるパケットを、テストパケットとして、テストパケット送信部（図４の４２）から送信開始する。

ステップＳ２４：エンコーダ（２Ｅ）は、そのテストパケットの送信を終了したら、その終了を監視サーバ（４）に通知する。

ステップＳ２５：上記のテストパケットの送信終了によって、該テストパケットが通過したルータにおいては、そのテストパケットすなわちetherStatsUndersizePktsについてのＭＩＢ情報すなわちカウント値が大幅に増大しているはずである。そこで監視サーバ（４）は、各ルータ３のＭＩＢ（５１）から再度、etherStatsUndersizePktsのカウント値の情報を受信する。

ステップＳ２６：監視サーバ（４）はそのカウント値すなわちテストパケットの流入量が前述した閾値ＴＨを超えたか否かを、判定部（図４の３３）により判断する。

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

ステップＳ３０：かくして各ルータ３におけるテストパケットの通過状態が判明し、これを表示部（図４の３５）に表示する。

以上をまとめると、第１実施例に係るマルチキャストツリー監視システム１０は、
ネットワーク中にほとんど流れることがない６４byte以下のパケットを監視用テストパケットとして送信する記載のマルチキャストフレーム配信装置（２Ｔ）と、
該６４byte以下のパケットの流入量を示すＭＩＢ情報（etherStatsUndersizePkts）を収集するマルチキャストツリー監視サーバ（４）と、
テストパケットの流入量に基づきＭＩＢ情報を生成するルータ３と、を用い、
該監視サーバ（４）が配信装置（２Ｔ）に指示した送信サイズを有するパケットが入力されるルータ３のインタフェース（ポート）を該ＭＩＢ情報から判定し、トポロジ管理テーブル３４に示す接続関係と該ＭＩＢ情報とから求めたパケットの流入方向をもとに、接続されたインタフェースにおけるフレームの配信方向を判定するように構成している。

図１８は本発明の第２実施例を適用したＩＰネットワーク（図３）を表す図であり、
図１９は図１８において実行される第２実施例の動作を表すフローチャート（その１）であり、
図２０は同フローチャート（その２）である。

まず図１８を参照すると、本第２実施例のもとでの動作は、下記１．〜８．のようになる。

１．エンコーダ（２Ｅ）のサブネットにおける未使用アドレスを調査し、
２．各ルータ３からテストパケット送信前のＭＩＢ（nlMatrixSDOctets）を収集し、
３．エンコーダ（２Ｅ）に対してテストパケットの送信用アドレスを指定してその送信を指示し、
４．その指定されたアドレスでテストパケットを一定量送信し、
５．ルータ３からＭＩＢ情報（addressMapSource, addressMapNetworkAddress）を収集してテスト用アドレスの入力ポートを特定し、
６．再度、nlMatrixSDOctetsを収集し、
７．流入量の多いインタフェース、およびその流入方向を判定して、
８．マルチキャストツリーを表示部３５に表示する。

さらに詳細な処理の流れを図１９および図２０を参照して説明する。なお図１９および図２０に示すフローチャートの各ステップのうち、前述した図１６および図１７でのステップと実質的に同一のステップについては、図１６および図１７における対応するステップと同一のステップ番号、すなわちＳ２２、Ｓ２４、Ｓ２６〜Ｓ３０を付して示す。

したがって本第２実施例の特徴をなすステップは、Ｓ３１、Ｓ３２およびＳ３３である。

ステップＳ３１：監視サーバ（４）は、これからＩＰネットワーク１に流そうとするテストパケット（本第２実施例では図１３に示されるパケット）のカウント値を、各ルータ３のＭＩＢ（図４の５１）から受信する。図１３のパケットの、監視テストの直前における、ＭＩＢ（５１）内の初期カウント値を入手するためである。すなわち、テスト直前におけるテストパケットの流入量がその初期カウント値より大幅にカウントアップしたとき、テストパケットが当該ルータを通過したものと判定する。

ステップＳ３２：第２実施例におけるテストパケット専用のＩＰアドレス（図１３の上段参照）を有するパケットを、各ルータ３に向けて送信する。

ステップＳ３３：図１３で規定されるパケットについてのＭＩＢ情報を、各ルータ３から受信する。以降のステップは、第１実施例の場合（Ｓ２６〜Ｓ３０）と同じである。

以上をまとめると、第２実施例に係るマルチキャストツリー監視システム１０は、
特定の発信用ＩＰアドレス、あるいは特定の宛先マルチキャストＩＰアドレスで監視用テストパケットを送信するマルチキャストフレーム配信装置（２Ｔ）と、
該テストパケットの入力インタフェース（ポート）を特定するＭＩＢ情報（addressMapSourceおよびaddressMapNetworkAddress）と、該テストパケットの流入量を計測するＭＩＢ情報（nlMatrixSDOctets）とを収集するマルチキャストツリー監視サーバ（４）と、
テストパケットの流入量に基づきＭＩＢ情報を生成するルータ３と、を用い、
該監視サーバ（４）が配信装置（２Ｔ）に対して指示した送信アドレスと送信量とを有するパケットが観測されたルータ３をnlMatrixSDOctetsにより判定し、かつaddressMapSourceおよびaddressMapNetworkAddressの収集結果により、トポロジ管理テーブル３４に示される接続リンクにおけるマルチキャストツリーの配信方向を判定するように構成している。

図２１は本発明の第３実施例（＃１）を適用したＩＰネットワーク（図３）を表す図であり、
図２２は図２１において実行される第３実施例（＃１）の動作を表すフローチャート（その１）であり、
図２３は同フローチャート（その２）である。

まず図２１を参照すると、本第３実施例（＃１）のもとでの動作は、下記１．〜８．のようになる。

１．エンコーダ（２Ｅ）のサブネットにおける未使用アドレスを調査し、
２．各ルータ３からテストパケット送信前のＭＩＢ（icmpTimeExcds）を収集し、
３．エンコーダ（２Ｅ）に対しテストパケットの送信用アドレスを指定してその送信を指示し、
４．その指定されたアドレスおよびＴＴＬ１〜Ｎにてテストパケットを一定量送信し、
５．ルータ３からＭＩＢ情報（addressMapSource, addressMapNetworkAddress）を収集し、テスト用アドレスの入力ポートを特定し、
６．再度、ＩＣＭＰ time excds.パケットを収集し、
７．流入量の多いインタフェース、およびその流入方向を判定して、
８．マルチキャストツリーを表示部３５に表示する。

さらに詳細な処理の流れを図２２および図２３を参照して説明する。なお図２２および図２３に示すフローチャートの各ステップのうち、前述した図１６および図１７でのステップと実質的に同一のステップについては、図１６および図１７における対応するステップと同一のステップ番号、すなわちＳ２２、Ｓ２４、Ｓ２６〜Ｓ３０を付して示す。

したがって本第３実施例（＃１）の特徴をなすステップは、Ｓ４１、Ｓ４２およびＳ４３である。

ステップＳ４１：監視サーバ（４）は、これからＩＰネットワーク１に流そうとするテストパケット（本第３実施例（＃１）では図１４に示されるパケットのカウント値）を、各ルータ３のＭＩＢ（図４の５１）から受信する。図１４のパケットの、監視テストの直前における、ＭＩＢ（５１）内の初期カウント値を入手するためである。すなわち、テスト直前におけるテストパケットの流入量がその初期カウント値より大幅にカウントアップしたとき、テストパケットが当該ルータを通過したものと判定する。

ステップＳ４２：ＴＴＬ１からＴＴＬＮまで指定した各パケットを、指定した数だけ、各ルータ３に向けて送信する。

ステップＳ４３：図１４で規定されるパケットについてのＭＩＢ情報を、各ルータ３から直接、監視サーバ（４）にて受信する。以降のステップは、第１実施例の場合（Ｓ２６〜Ｓ３０）と同じである。

以上をまとめると、第３実施例（＃１）に係るマルチキャストツリー監視システム１０は、
特定の発信用ＩＰアドレス、あるいは特定の宛先マルチキャストＩＰアドレスおよびＴＴＬ＝１〜Ｎ（Ｎ：任意）を有するテストパケットを、指定された送信量ずつ配信するマルチキャストフレーム配信装置（２Ｔ）と、
該テストパケットの入力インタフェース（ポート）を特定するＭＩＢ情報（addressMapSourceおよびaddressMapNetworkAddress）と、該テストパケットのＴＴＬが０になり該パケットを廃棄したことを示すＭＩＢ情報（icmpOutTimeExcds）とを収集するマルチキャストツリー監視サーバ（４）と、
該icmpOutTimeExcdsパケットの送信に基づきＭＩＢ情報を生成するルータ３と、を用い、
該監視サーバ（４）が配信装置（２Ｔ）に対して指示したパケット数だけicmpOutTimeExcdsパケットを送信したルータ３を抽出し、かつaddressMapSourceおよびaddressMapNetworkAddressの収集結果に基づいて、トポロジ管理テーブル３４の接続リンクにおけるマルチキャストツリーの配信方向を判定するように構成する。

図２４は本発明の第３実施例（＃２）を適用したＩＰネットワークを表す図であり、
図２５は図２４において実行される第３実施例（＃２）の動作を表すフローチャートである。

図２４を参照すると、本第３実施例（＃２）のもとでの動作は、下記１．〜５．のようになる。

１．エンコーダ（２Ｅ）に対しテストパケットの送信用ポート番号を指定して、その送信を指示し、
２．その送信指示に従い、送信ポート番号Ｘ＋１〜Ｘ＋Ｎの各ポート番号に相当するＴＴＬ１〜Ｎを付与したテストパケットを一定量エンコーダ（２Ｅ）より送信し、
３．ＴＴＬ１〜Ｎの各パケットに応答したＩＣＭＰ time exceededパケットを返送したルータを監視サーバ（４）に通知し、
４．ポート番号と送信ルータのアドレスとをもとに、配信装置（２Ｔ）から該送信ルータ（time exceededパケットを返送したルータ）までのホップ数を判定し、配信インタフェース（ポート）および配信方向を判定して、
５．ツリーを表示部３５に表示する。

さらに詳細な処理の流れを図２５を参照して説明する。本図のフローチャート中、ステップＳ２２とＳ３０は前述のとおりであり、ステップＳ５１〜５４が本第３実施例（＃２）の特徴をなす。

ステップＳ５１：図２４において説明した上記の２．の工程に相当する
ステップＳ５２およびＳ５３：図２４において説明した上記の３．および４．の工程に相当し、ステップＳ５２では、各ルータ３よりエンコーダ（２Ｅ）が受信したtime exceededパケットを、各該time exceededパケットに記述された上記の送信ポート番号をもとに、ＴＴＬ１〜Ｎの順に並べたルータリストをエンコーダ（２Ｅ）が作成し、これを監視サーバ（４）に転送する。

さらにステップＳ５３では、エンコーダ（２Ｅ）より受信した上記のＴＴＬ１〜Ｎの順に並べたルータリストを、監視サーバ（４）内の判定部３３（図４）にて分析して、テストパケットの転送経路（通過状態情報）を判定する。

ステップ５４：上記のテストパケットの転送経路をもとに、マルチキャストの方向をトポロジ管理テーブル３４に設定する。

以上をまとめると、第３実施例（＃２）に係るマルチキャストツリー監視システム１０は、
ＴＴＬ＝１〜Ｎ（Ｎ：任意）と、ＴＴＬの値に対応する送信ポート番号または宛先ポート番号（Ｘ＋１〜Ｘ＋Ｎ、Ｘ：任意、Ｎ：ＴＴＬの値）により特定されたテストパケットを、指定された送信量ずつ配信し、各ルータ３から返送されたＩＣＭＰ time exceededパケットを、送信結果として、監視サーバ（４）に返送するマルチキャストフレーム配信装置（２Ｔ）と、
返送された該ＩＣＭＰ time exceededパケットを配信装置（２Ｔ）より収集するマルチキャストツリー監視サーバ（４）と、
該ＩＣＭＰ time exceededパケットの情報を監視サーバ（４）に送信するルータ３と、を用い、
該マルチキャストフレーム配信装置（２Ｔ）から返送されたＩＣＭＰ time exceededパケットを解析し、該ＩＣＭＰ time exceededパケットを送信したルータ３のＩＰアドレス、および、送信ポート番号あるいは宛先ポート番号から、該マルチキャストフレーム配信装置（２Ｔ）から当該ルータ３までのホップ数を判定し、トポロジ管理テーブル３４に示す隣接ルータ関係と該ホップ数とから、マルチキャストフレームの配信方向を判定するように構成する。

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

図２６は第４実施例としての障害検知システムを適用したＩＰネットワーク１を表す図である。本図において、例えば光ファイバの断線あるいはルータ３の故障が原因で本図中のＦ（fault）点にて障害が発生したものとすると、本発明のマルチキャストツリー監視を利用すれば、かかる障害箇所（Ｆ）を簡単に特定することができる。

このために、本図の例では前述した第３実施例を利用する。すなわち、送信端末２Ｔより、ＴＴＬを１からＮまで設定した各テストパケットをネットワーク上に流すと、各ルータ３からtime exceededパケットが送信端末２Ｔに返送され、監視サーバ（４）においては該当のカウンタのカウント値が増加する。

ところが、障害箇所（Ｆ点）より下流側にあるルータ（３ａ、３ｂおよび３ｃ）には上記のテストパケットが到達し得ない。このため、図２６中の点線Ａａ、ＡｂおよびＡｃのようにＩＣＭＰ time exceededパケットの戻りがなく、監視サーバ（４）から見てこれらのルータ３ａ、３ｂおよび３ｃに該当する各カウンタのカウント値は一定値に止まったままとなる。この結果監視サーバ（４）は、これらのサーバから最も送信端末２Ｔに近いサーバ（３ａ）の近傍において障害が発生したものと推定し、障害判定部３６より障害検知情報ＡＬＭを発出する。

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

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

図２７（ａ）〜（ｄ）は送信用フレームのヘッダフォーマットを示す図であり、本図の（ａ）にはEtherフレームの全体を示し、その中のＩＰヘッダとＵＤＰヘッダとＲＴＰヘッダとをそれぞれ本図の（ｂ）、（ｃ）および（ｄ）に詳細に示す。前述した第１形態（ｉ）のテストパケットは、ここで示したＲＴＰヘッダ（ｄ）までの５６byteのフレームを生成することで実現できる。またその他の形態（ii）および（iii）のテストパケットについては、各レイヤのヘッダ情報において、ＩＰヘッダ内のＴＴＬ（ｂ）やＵＤＰヘッダ内のポート番号（ｃ）等を所望の値に設定することで実現できる。

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

Claims (8)

1. マルチキャストフレームを配信する送信端末と、該マルチキャストフレームを受信する複数の受信端末と、該送信端末から該複数の受信端末へ向けて形成されるツリー状のマルチキャストフレーム伝送経路上に複数配置されるルータと、を含んで構成されるＩＰネットワークにおいて、前記マルチキャストフレームの伝送経路をネットワーク監視装置によって探索するためのマルチキャストツリー監視方法であって、
   前記ネットワーク監視装置から前記送信端末に対し、通常配信される前記マルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを指示する第１のステップと、
   前記送信端末において、前記指示に従って前記テストパケットを前記ルータに向けて送信する第２のステップと、
   送信された前記テストパケットを受信しこれを通過させた前記ルータの各々において、該テストパケットの通過状態情報を生成する第３のステップと、
   前記ネットワーク監視装置において、各前記ルータから収集した前記通過状態情報に基づいて前記テストパケットの前記ＩＰネットワーク上での配信方向を判定し、この判定結果により前記ツリー状の伝送経路を特定する第４のステップと、を有し、
   前記第１のステップにおける前記監視用のテストパケットは、（ｉ）前記マルチキャストフレームとしては通常採用されることがないデータ長を有するパケット、（ii）未使用の、発信用ＩＰアドレスあるいは宛先マルチキャストＩＰアドレスを有するパケット、（iii）パケットの有効時間ＴＴＬ（Time To Live）が１から、予め指定したＮまで設定されたパケット、のいずれかから選択されると共に、予め定めた一定量の該テストパケットが連続的に送信されることを特徴とするマルチキャストツリー監視方法。
2. 前記第３のステップにおける前記通過状態情報は、ネットワーク管理用データベースＭＩＢ（Management Information Base）情報として生成されることを特徴とする請求項１に記載のマルチキャストツリー監視方法。
3. 前記第４のステップにおける前記の判定は、前記ネットワーク監視装置内にあって隣接ルータとの接続関係を保持するトポロジ管理テーブルを参照して行われることを特徴とする請求項１に記載のマルチキャストツリー監視方法。
4. マルチキャストフレームを配信する送信端末と、該マルチキャストフレームを受信する複数の受信端末と、該送信端末から該複数の受信端末へ向けて形成されるツリー状のマルチキャストフレーム伝送経路上に複数配置されるルータと、を含んで構成されるＩＰネットワークにおいて、前記マルチキャストフレームの伝送経路をネットワーク監視装置によって探索するためのマルチキャストツリー監視システムであって、
   前記ネットワーク監視装置に設けられ、通常配信される前記マルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを前記送信端末に対し指示する指示機能部と、
   前記送信端末に設けられ、前記指示に従って前記テストパケットを前記ルータに向けて送信する送信機能部と、
   送信された前記テストパケットを受信しこれを通過させた各前記ルータに設けられ、その通過させたテストパケットの通過状態情報を生成する状態情報生成機能部と、
   前記ネットワーク監視装置にさらに設けられ、各前記ルータから収集した前記通過状態情報に基づいて前記テストパケットの前記ＩＰネットワーク上での配信方向を判定し、この判定結果により前記ツリー状のマルチキャストフレーム伝送経路を特定する判定機能部と、
   を含んで構成されると共に、前記監視用のテストパケットは、（ｉ）前記マルチキャストフレームとしては通常採用されることがないデータ長を有するパケット、（ii）未使用の、発信用ＩＰアドレスあるいは宛先マルチキャストＩＰアドレスを有するパケット、（iii）パケットの有効時間ＴＴＬ（Time To Live）が１から、予め指定したＮまで設定されたパケット、のいずれかから選択されると共に、予め定めた一定量の該テストパケットが連続的に送信されることを特徴とするマルチキャストツリー監視システム。
5. マルチキャストフレームを配信する送信端末と、該マルチキャストフレームを受信する複数の受信端末と、該送信端末から該複数の受信粉末へ向けて形成されるツリー状のマルチキャストフレーム伝送経路上に複数配置されるルータと、を含んで構成されるＩＰネットワークにおいて、前記マルチキャストフレームの伝送経路をネットワーク監視装置によって探索するためのマルチキャストツリー監視システムを形成する該ネットワーク監視装置であって、
   通常配信される前記マルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを、前記送信端末に対し指示する指示機能部と、
   送信された前記テストパケットを受信しこれを通過させた各前記ルータにて生成された該テストパケットの通過状態情報に基づいて、該テストパケットの前記ＩＰネットワーク上での配信方向を判定し、この判定結果により前記ツリー状のマルチキャストフレーム伝送経路を特定する判定機能部と、を備え、
   前記判定機能部は、各前記ルータからそれぞれの前記通過状態情報を収集する状態情報収集部と、収集された該通過状態情報を格納する状態情報格納部と、格納された該通過状態情報をもとに前記配信方向を判定するマルチキャストパス判定部と、を有すると共に、該判定機能部は、前記状態情報格納部に格納された前記テストパケットの送信直前の前記通過状態情報と、そのテストパケットの送信後の該通過状態情報との差分が大であるときに前記の判定を行うことを特徴とするネットワーク監視装置。
6. 前記判定機能部は、前記配信方向の判定のために参照する、隣接ルータとの接続関係を保持するトポロジ管理テーブルを有することを特徴とする請求項５に記載のネットワーク監視装置。
7. 前記判定機能部は、前記判定結果により特定された前記ツリー状のマルチキャストフレーム伝送経路の構成を表示するツリー表示部を有することを特徴とする請求項５に記載のネットワーク監視装置。
8. マルチキャストフレームを配信する送信端末と、該マルチキャストフレームを受信する複数の受信端末と、該送信端末から該複数の受信端末へ向けて形成されるツリー状のマルチキャストフレーム伝送経路上に複数配置されるルータと、を含んで構成されるＩＰネットワークにおいて、前記マルチキャストフレームの伝送経路をネットワーク監視装置によって探索するためのマルチキャストツリー監視システムを形成する該送信端末であって、
   通常配信される前記マルチキャストフレームとは区別される監視用のテストパケットを送信すべきことを示す前記ネットワーク監視装置からの指示を受けて、前記テストパケットを前記ルータに向けて送信する送信機能部を備え、
   前記送信機能部は、前記監視用のテストパケットを送信すべきことを示す前記ネットワーク監視装置からの指示を受け付けるツリー監視要求受付部と、その指示を受け付けて前記テストパケットを生成し送信するテストパケット送信部と、を有すると共に、前記テストパケット送信部にて生成しかつ送信される前記テストパケットは、（ｉ）前記マルチキャストフレームとしては通常採用されることがないデータ長を有するパケット、（ii）未使用の、発信用ＩＰアドレスあるいは宛先マルチキャストＩＰアドレスを有するパケット、（iii）パケットの有効時間ＴＴＬ（Time To Live）が１から、予め指定したＮまで設定されたパケット、のいずれかから選択されると共に、予め定めた一定量の該テストパケットが連続的に送信されることを特徴とする送信端末。

Images