JP4219314B2

JP4219314B2 - 通信装置

Info

Publication number: JP4219314B2
Application number: JP2004282592A
Authority: JP
Inventors: 雄次金野
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2004-09-28
Filing date: 2004-09-28
Publication date: 2009-02-04
Anticipated expiration: 2024-09-28
Also published as: JP2006101026A; US7290173B2; US20060085694A1

Description

本発明は、通信装置に関し、特に、IPパケットを用いた通信システムにおける通信機能保守診断を行なう通信装置に関するものである。

従来より、IPパケットを用いた通信システムにおいて、各種通信デバイスの異常を検出してその保守を行なうための通信機能保守診断が行なわれており、以下に説明するように、(1)通信デバイスの異常発生時に通信機能の管理運用を司るCPUが割込み通知を受ける方式、及び(2)CPUが定期的に通信デバイスの異常を検出するためのポーリング処理を行なう方式が代表的な方式として知られている。

まず、前者の通信機能保守診断方式（1）について図7及び図8を参照して説明する。なお、図7に示したハードウェア100、ソフトウェア200、及び運用管理者又は上位CPU300の区分は、機能を大まかに区分して示したものであり、厳密な区分ではない。

この方式においては、ハードウェア100の機能として、表示部11及び割込み制御部12を備えた異常検出部10があり、ハードウェア100の機能とソフトウェア200の機能との境界に位置付けられる機能を有するCPU20がある。

異常検出部10における表示部11は一般的にレジスタで構成され、各ビットに診断対象のデバイス（図示せず）が対応付けられている。また、割込み制御部12は、必要に応じてCPU20に対する割込み信号を発するものである。

動作において、異常検出部10がハードウェア100に接続されたいずれかのデバイスから異常通知S1を受けると、表示部11において、該当するデバイスのビットが異常状態の値に変更され、割込み制御部12からCPU20に対し割込み通知S2が行われる。

割込み通知S2を受けたCPU20は、表示部11にアクセスして被疑箇所特定処理S3を行なうことにより、何れのデバイスが異常であるかを特定した後、運用管理者又は上位CPU 300に対し異常発生に関する通知S30を行うと共に、異常となっているデバイスに直接アクセスしてステータス情報取得処理S4を施すことにより、詳細のステータス情報を取得する。

なお、上記の異常発生に関する通知S30は、運用管理者に対する通知の場合、例えば、異常個所に対応したLEDの点灯等により行なうことが可能である。

図8は、このような通信機能保守診断方式(1)を採用したルータXの内部構成例を示したものである。図示の如く、ルータXは、回線インタフェース4から順に回線系バス5で接続されたデバイス1〜3と、各デバイス1〜3にPCIバス6で接続されたCPU20と、CPU 20にPCIバス6で接続された異常検出部10とで構成されている。すなわち、同図は図7に示した異常検出部10及びCPU 20と各デバイス1〜3との接続関係を示している。

また、デバイス3には連想メモリ6が接続されているが、これは、例えばIPアドレス情報をエントリとして有するものであり、通常のIPパケット処理において使用するものである。

動作において、例えば、デバイス2に障害が発生した場合、デバイス2から異常検出部10に対して異常通知S1が行われ、これを受けた異常検出部10では、表示部11の該当ビットによりデバイス2の異常を表示すると共に、割込み制御部12からCPU20に対し割込み通知S2を行う。

次に、割込み通知S2を受けたCPU20は、被疑箇所特定処理S3を行ない、デバイス2が異常であることが特定できるので、デバイス2にPCIバス6を介してアクセスすることによりステータス情報取得処理S4を行なう。

なお、図示していないが、各デバイス1〜3と異常検出部10とはそれぞれ制御線で接続されており、また、異常検出部10の割込み制御部12とCPU 20とも制御線で接続されているため、上記の異常通知S1及び割込み通知S2は、それぞれ制御線を介して瞬時に通知が行われる。

次に、通信機能保守診断方式（2）について図9を参照して説明する。なお、図9は、図7の異常検出部10及びCPU20の代わりにそれぞれ異常検出部30及びCPU 40を使用するものであり、異常検出部30は異常検出部10における表示部11と同様な表示部31を有しているが、割込み制御部12に相当する機能部を有していない。また、CPU40が表示部31に対して定期的にポーリングによる被疑箇所特定処理S5を定期的に行なうことが、図7と異なっている。

動作において、異常検出部30がいずれかのデバイスから異常通知S1を受けると、表示部31において、該当するデバイスのビットが異常状態の値に変更される。

上述の如く、CPU40が表示部31に対して定期的にポーリングによる被疑箇所特定処理S5を定期的に行なうため、この処理S5を行なった時点で表示部31に何れかのデバイスが異常であることが表示されていれば、CPU40は異常検出と共に被疑箇所の特定をすることが可能である。

これにより、被疑箇所が特定できたとき、CPU 4は運用管理者又は上位CPU 300に対し異常発生に関する通知S30を行うと共に、異常となっているデバイスに直接アクセスしてステータス情報取得処理S6を施すことにより、詳細のステータス情報を取得する。

上記の通信機能保守診断方式(1)及び（2）以外の通信機能保守診断方式としては、複数の通信装置が接続されたネットワークの保守・運用管理機能に関し、ループバック試験により信号線を常時監視することができ、また、遠隔から制御することができるものがある（例えば、特許文献１参照。）。

この方式では、汎用インタフェースに送信するパケットのプリアンブルに試験データ等の管理データを挿入し、また、汎用インタフェースから受信するパケット間のアイドル時間に挿入された、折り返された試験データ等の管理データを検出する第1の回路と、汎用インタフェースから受信するパケットのプリアンブルに挿入された管理データを検出し、また、汎用インタフェースのアイドル時間に管理データを挿入する第2の回路とを有している。また、第2の回路がプリアンブルに挿入された試験データを検出し、汎用インタフェースのアイドル時間に折り返すことに、ループバック試験を実行している。

また、保守インタフェース異常処理側の障害に起因する誤診断を回避しながら、信頼性の高い保守診断を実現する通信機能保守診断方式もある（例えば、特許文献２参照。）。

この方式では、保守インタフェースが、運用者による保守診断要求に対応する異常発生パターンを異常発生パターンライブラリ群から選択し、異常パターン発生部がこの異常発生パターンに対応する異常セルを生成し、診断点のノードへ送出する。また、診断点のノードでは、受信した異常セルを異常検出部で検出し、更に異常解析／通知部がその異常を障害データベースとの比較により解析し、擬似障害に対して異常検出側が正しく動作するか否かをチェックする。
特開2003-169093号公報特開平7-11104号公報

上記の通信機能保守診断方式(1)においては、異常通知S1を受けた異常検出部10の割込み制御部12が即座に割込み通知S2を行うため、或るデバイスに障害が生じてから、CPU20が割込み通知S2を受けるまでの時間は短い。しかしながら、この後、CPU 20が必要なステータス情報を取得するまでに行なう被疑箇所特定処理S3及びステータス情報取得処理S4は、共にPCIバス6を経由して行なわれるが、このPICバス6は33MHz程度の比較的低速なバスであるため、ステータス情報取得の対象となるデバイスの数が増えるほどCPU処理占有時間が長くなる。

これに対し、上記の通信機能保守診断方式（2）では、CPU 40はポーリングによる被疑箇所特定処理S5を行なうため、デバイスの異常を検出と被疑箇所の特定とを同時に行なうことが出来る。従って、必要なステータス情報を取得するにはステータス情報取得処理S6を行なうだけでよい。

しかしながら、ステータス情報取得処理S6もPCIバスを介して行なうものであるから、やはり、ステータス情報取得の対象となるデバイスの数が増えるほどCPU処理占有時間が長くなる。

また、定期的に行なうポーリングによりCPU処理が必要になると共に、異常通知S1のタイミングによっては、次回のポーリングが行われるまでCPU 40は異常を検知することができないという問題が有る。

従って本発明は、IPパケットを用いた通信を行なう通信装置において、通信機能保守診断に要するCPU処理占有時間を短縮し、以って通信機能保守診断処理を高速に行なうことを課題とする。

上記の課題を解決するため、本発明に係る通信装置は、縦続接続した一連の診断対象デバイスを順に経由する都度診断用フレームに記録される各診断対象デバイスの一連の最新ステータス情報を終端する診断用フレーム終端部と、該一連の診断対象デバイスの正常時における各ステータス情報を該診断対象デバイスの接続順に並べた一連の正常ステータス情報を予め１つのエントリとして格納すると共に、終端された該一連の最新ステータス情報が該エントリと一致しなければ異常通知を発生する連想メモリと、終端された該一連の最新ステータス情報を格納するステータス情報格納部と、該異常通知を受けたとき、該ステータス情報格納部から該一連の最新ステータス情報を取得し出力するCPUと、を備えたことを特徴としている。

本発明の原理を図1を参照して説明する。なお、同図に示したハードウェア100、ソフトウェア200、及び運用管理者又は上位CPU300の区分は、機能を大まかに区分して示したものであり、厳密な区分ではない。

同図においてハードウェア100の機能を有するのは、診断用フレーム終端部110並びにこれに接続された連想メモリ120及びステータス情報格納部130である。また、同図においてハードウェア100の機能とソフトウェア200の機能との境界に位置付けられる機能を有するのはCPU140であり、図示の如く連想メモリ120及びステータス情報格納部130に共通接続されている。

連想メモリ120は、縦続接続した一連の診断対象デバイスの正常時における各ステータス情報を該診断対象デバイスの接続順に並べた一連の正常ステータス情報を予め１つのエントリとして格納している。

また、診断用フレームFnには、同図に示す状態では既に、各診断対象デバイスの一連の最新ステータス情報が全ての該診断対象デバイスを順に経由する都度記録されている。

診断用フレーム終端部110は、診断用フレームFnに記録された一連の最新ステータス情報を終端し、連想メモリ120及びステータス情報格納部130に与える。連想メモリ120は、終端された該一連の最新ステータス情報が該エントリと一致しなければ異常通知S10を発生する。同時に、ステータス情報格納部130は、終端された該一連の最新ステータス情報を格納する。

また、CPU 140は、連想メモリ120からの異常通知S10を受けたとき、ステータス情報格納部130から該一連の最新ステータス情報を取得する（同図のステータス情報取得処理S20）。

この後、CPU 140は、取得した一連の最新ステータス情報を出力することにより、従来と同様な、運用管理者又は上位CPU 300に対する通知S30を行うことが出来る。

これにより、異常検知後、図7に示したような被疑箇所特定処理S3及び異常となっている診断対象デバイス毎に直接アクセスすることによるステータス情報取得処理S4を行う場合と比較して、被疑箇所特定処理S3そのものを必要としない。また、異常となっている診断対象デバイスが複数存在する場合においても、1回のステータス情報取得処理S20により、全ての診断対象デバイスの最新ステータス情報を一括して取得できることから、CPU処理占有時間を削減することが出来る。

また、図9に示したようなポーリングによる被疑箇所特定処理S5を行なうことにより異常検知をする場合と比較して、定期的なポーリング処理を必要とせず、また、異常となっている診断対象デバイスが複数存在する場合においても、1回のステータス情報取得処理S20により、全ての診断対象デバイスの最新ステータス情報を一括して取得できることから、CPU処理占有時間を削減することが出来る。

上記の各診断対象デバイスは、該診断用フレーム受信時におけるそれぞれの最新のステータス情報を該診断用フレームに記録する手段を有していればよい。

また、上記の通信装置は、該連想メモリと該CPUとが制御線で接続され、該CPUと該ステータス情報格納部とがPCIバスで接続されていればよい。

これにより、連想メモリ120からCPU140への異常通知S10は制御線を介して行われ、CPU 140からステータス情報格納部130に対するステータス情報取得処理20はPCIバスを介して行なわれる。

また、上記の通信装置は、該縦続接続した一連の診断対象デバイスの一端に位置する該診断対象デバイスを該連想メモリに直結し、該診断用フレームの宛先アドレスを該連想メモリに直結した該診断対象デバイスのアドレスとして、該診断用フレームを、他端に位置する該診断対象デバイスから入力すればよい。

すなわち、該縦続接続した一連の診断対象デバイスの一端に位置する該診断対象デバイスを該連想メモリに直結し、他端に位置する該診断対象デバイスから該診断用フレームを入力する。このとき、該診断用フレームの宛先アドレスを該連想メモリに直結した該診断対象デバイスのアドレスとすることで、該診断用フレームは、該縦続接続した一連の診断対象デバイスの全てを順に経由することになる。

また、上記の通信装置は、該縦続接続した一連の診断対象デバイスの一端に接続され、該診断用フレームを生成して送信する診断用フレーム生成部を備えてもよい。

すなわち、該診断用フレームは、縦続接続した一連の診断対象デバイスの一端に接続された診断用フレーム生成部によって生成され、通信装置宛に送信される。

これにより、例えば複数の通信装置に通信回線を介して接続された１つの診断用フレーム生成部から、各通信装置宛の診断用フレームを生成して送信することにより接続された全ての通信装置の保守診断処理を一元管理することが可能になる。

また、上記の通信装置は、該診断用フレームに対応して該連想メモリが異常通知を行ったか否かの情報を診断結果フレームとして該診断用フレーム生成部に送信する手段をさらに備えてもよい。

すなわち、診断用フレーム生成部宛に送信される診断結果フレームは、受信した診断用フレームに対応して連想メモリが異常通知を行ったか否かの情報を含むものである。

従って、診断用フレーム生成部は、診断結果フレームを受信することにより、該診断用フレームの宛先である通信装置において異常があったか否かを把握することが可能になる。

また、上記の診断用フレーム生成部は、該診断用フレームを定期的又は所望の指定時に生成して送信すればよい。

本発明の通信装置によれば、CPUが従来のような被疑箇所特定処理や定期的なポーリング処理を行なう必要が無く、また、異常となっている診断対象デバイスが複数存在する場合においても、1回のステータス情報取得処理により、全ての診断対象デバイスの最新ステータス情報を一括して取得できることから、通信機能保守診断処理に要するCPU処理占有時間を短縮することが可能になり、以って通信機能保守診断処理を高速に行なうことが可能になる。

また、従来は診断対象デバイス毎に異常通知用の制御線を設ける必要があったが、本発明の通信装置によれば、異常通知用の制御線はCPUと連想メモリ間だけでよいため、通信装置を構成するプリント板における制御線の配線領域を削減できるという効果も得られる。

図2は、本発明の通信装置の実施例(1)として、ルータAの構成を示したものである。図示の如く、ルータAは、回線インタフェース4から順に回線系バス5で接続されたデバイス1〜3と、各デバイス1〜3にPCIバス6で接続されたCPU140とで構成されている。

デバイス3は、診断用フレーム終端部110を有しており、この診断用フレーム終端部110には図示の如くデバイス3外部の連想メモリ120及びステータス情報格納部130が接続されている。この内、連想メモリ120は、従来どおり通常のIPパケット処理においても使用するものであるが、ルータAにおいては、異常検出のためのエントリとして、予め全てのデバイス1〜3の正常時における各ステータス情報から成る一連の正常ステータス情報を格納しておくものである。

この一連のステータス情報は、通常、例えば全ビットが“0”であるようなエントリであるが、デバイスによっては正常時のステータス情報が必ずしも全ビット“0”とは限らない。

なお、図示していないが、連想メモリ120とCPU 140とは制御線で接続されているものであり、ステータス情報格納部130とCPU 140とはPCIバスで接続されているものである。但し、ステータス情報格納部130は、デバイス3の内部に含まれていてもよく、この場合もデバイス3とCPU140とがPCIバス6で接続されていることから、テータス情報格納部130とCPU 140とはPCIバスで接続されることになる。

動作において、回線インタフェース4を介してルータAが受信する診断用フレームF0は、各デバイス1〜3を経由する都度、それぞれのステータス情報D1〜D3が図示の診断用フレームF1〜F3に示す如く付加されて行く。なお、診断用フレームF1〜F3は全て診断用フレームF0の状態を示したものである。すなわち、診断用フレームF1は、診断用フレームF0にデバイス1のステータス情報D1が付加された状態であり、診断用フレームF2は、診断用フレームF0にデバイス2のステータス情報D2がさらに付加された状態であり、診断用フレームF3は、診断用フレームF0にデバイス3のステータス情報D3がさらに付加された状態である。

デバイス3において、診断用フレームF0にステータス情報D3がさらに付加された後の診断用フレームF3には、ステータス情報D1〜D3から成る一連の最新ステータス情報Dnが記録されている。従って、診断用フレーム終端部110は、診断用フレームF3に記録された一連の最新ステータス情報Dnを終端し、連想メモリ120及びステータス情報格納部130に与える。こうして、一連の最新ステータス情報Dnはステータス情報格納部130に格納されると共に、連想メモリ120において一致するエントリがあるか否かについて検索される。

デバイス1〜3に何ら異常が無ければ、一連の最新ステータス情報Dnは、上記の一連の正常ステータス情報のエントリと一致（ヒット）する筈である。

従って、一致するエントリが連想メモリ120に存在しなければ、デバイス1〜3の少なくともいずれか１つにおいて障害が発生していることになるため、連想メモリ120はCPU 140に対する異常通知S10を発生する。CPU140は異常通知S10を受けると、ステータス情報格納部130に対してステータス情報取得処理S20を行なう。

なお、ルータAにおいては、図示の如く連想メモリ120に直結しているのはデバイス3であり、このデバイス3が最後にステータス情報D3を診断用フレームF0に付加するものである。従って、診断用フレームF0の宛先アドレスにはデバイス3のアドレスが設定されているものとする。この場合のアドレスはMACアドレスを使用すればよい。

ここで、デバイス2に障害が発生した場合を想定する。この場合、デバイス2のステータス情報D2は異常を示す値となっている。従って、一連の最新ステータス情報に一致するエントリが連想メモリ120に存在せず、両者は不一致となり、連想メモリ120は異常通知S10を発生する。これを受けたCPU140は、ステータス情報取得処理S20により、ステータス情報格納部130からデバイス1〜3の最新のステータス情報D1〜D3を一括して取得する。この中には、デバイス2の最新のステータス情報D2が含まれていることから、CPU140は、従来のようにPCIバス6を介してデバイス2にアクセスする必要が無くなる。

なお、従来のようにPCIバス6を介してデバイス2にアクセスし、ステータス情報D2を取得する場合、ステータス情報が4バイト(32ビット)であればCPU処理占有時間は約690nsecである。従って、例えば、同時に複数のデバイスが異常となった場合には、それぞれのデバイスに対するステータス情報取得処理が必要であるため、単純計算で690nsecに異常となったデバイスの数を掛けた値のCPU処理占有時間（図示の例で全デバイス1〜3が異常であるときは、690nsec×3＝2,070nsec）を要することになる。

これに対し、図2のルータAにおいて、デバイス3と連想メモリとが156.25MHzのデータバス（72ビット）で接続され、デバイス2とデバイス3とが312.5MHzの回線系バス5（16ビット）で接続された条件の下、デバイス1を省いた状態でシミュレーションを行うと、64バイトの診断フレーム（4バイト〜16バイトのステータス情報を含む）を連続送信する場合には、一連の最新ステータス情報は51nsec毎に得られる。すなわち、ステータス情報格納部130は51nsec毎に更新される。

ルータAの場合、CPU140が行うステータス情報取得処理S20はPCIバス6を介して行なう処理であるため、1回のステータス情報取得処理S20そのものは上記のデバイス2にアクセスする場合の約690nsecと同程度の時間を要するが、複数のデバイスの最新のステータス情報を一括して取得することが可能であることから、ステータス情報を取得すべきデバイス数が多くなる程、従来技術と比較してCPU処理占有時間を短縮することが可能となる。

また、図7及び図9に示した従来の通信機能保守診断方式（1）及び(2)の場合、それぞれ、異常検出部10及び異常検出部20に対する異常通知S1は各デバイスが発生するものであるから、各デバイスと異常検出部10及び異常検出部20とは制御線で接続する必要があるが、図2に示した本実施例(1)の場合、連想メモリ120とCPU140との間のみ異常通知S10用の制御線を接続すればよい。

このように制御線の本数が少ないことは、通信装置を構成するプリント板における制御線のの配線領域を削減できるというメリットがあり、複数のプリント板を重ねて構成する装置の場合には特に有効である。

次に、同図のデバイス3に診断用フレームF0が到達した後の、診断用フレームの処理フローを図3を用いて説明する。なお、同図において、特に明記していない処理ステップは、デバイス3により実行される処理ステップである。

デバイス3は、まず、フレームを受信すると（ステップS100）、受信したフレームの宛先MACアドレスが自デバイスのMACアドレスであるか否かを判断する（同S101）。

次に、デバイス3は、ステップS101において、受信したフレームの宛先MACアドレスが自デバイスのMACアドレスでなければフレームを廃棄し（同S110）、自デバイスのMACアドレスであればさらにフレームがIPv4フレーム又はIPv6フレームであるか否かを判断する（同S102）。

さらに、デバイス3は、ステップS102において、IPv4フレーム又はIPv6フレームであれば、通常のフレーム処理（同S111）を行なった後、フレームの中継を行なう（同S112）。IPv4フレーム又はIPv6フレームでなければ、受信したフレームは診断用フレームであるので、デバイス3は自デバイスのステータス情報を取得する（同S103）。

次に、デバイス3内の診断用フレーム終端部110が、診断用フレームに記録された一連の最新ステータス情報を終端し、ステータス情報格納部130に格納すると共に連想メモリ120に入力する（同S104）。

次に、連想メモリ120は、ステップS104において診断用フレーム終端部110から入力された一連の最新ステータス情報を用いてエントリの検索を行なう（同S105）。

さらに、連想メモリ120は、ステップS105における検索結果がミスヒット（一連の最新ステータス情報と予め連想メモリ120に格納された一連の正常ステータス情報のエントリとが一致しないこと。）であるか否かを判定し（同S106）、ミスヒットでなければ、全てのデバイスのステータス情報が正常時のステータス情報と一致することを意味するため、異常は無いと診断する。

ステップS106においてミスヒットである場合は、少なくともいずれかのデバイスのステータス情報が異常値であることを意味するため、連想メモリ120がCPU140に異常通知S10を行う（同S107）。

ステップS107において、連想メモリ120から異常通知S10を受けたCPU140は、ステータス情報格納部130から一連の最新ステータス情報を取得する（同S108）。なお、ステップS108の処理は図2におけるステータス情報取得処理S20に相当している。

同図においては、デバイス3による診断結果フレーム送信のステップS109が示されている。この処理は図2においては示していないが、デバイス3が行なう処理として追加することができる。すなわち、デバイス3は、ステップS106においてミスヒットである場合には、「異常なし」を示す“診断結果OK”の診断結果フレームを送信し、ステップS108を実行した後であれば、異常が検出されているため「異常あり」を示す“診断結果NG”の診断結果フレームを送信する。なお、診断結果フレームの宛先は後述する診断用フレーム生成部である。

ここで、診断用フレームのフレームフォーマットについて図4を用いて説明する。同図(1)及び(2)はそれぞれ通常のIPv4フレームFv4及び診断用フレームF0のフレームフォーマットを示したものである。

IPv4フレームFv4は、同図(1)に示す如く、送信元MACアドレス、宛先MACアドレス、タグ、タイプ、IPヘッダ、送信元IPアドレス、宛先IPアドレス、及びデータで構成されている。

診断用フレームF0は、同図(2)に示す如く、同図(1)のIPv4フレームFv4と同様の構成を有しているが、IPヘッダにおけるバージョンの値が異なる。バージョンの値とは、同図(1)及び(2)において、それぞれ、矢印で示す位置の“4”及び“0”であり、この値がIPのバーションを示している。例えば“4”であればIPv4フレームであり、“6”であればIPv6フレームであることを意味する。診断用フレームF0は、いずれのIPバージョンにも該当しないよう、この値が“0”となっている。

従って、上述の図3に示した診断用フレームの処理フローのステップS103においては、このバージョンの値を確認することにより、受信したフレームがIPv4フレーム又はIPv6フレームであるか否かが分かる。

また、診断用フレームF0は、データ領域に各デバイス1〜3のステータス情報が格納される。図示の例では、それぞれ32ビットからなるデバイス1〜3のステータス情報の領域が確保され、残りの領域にはパディングが施されている。

次に、本発明の通信装置の実施例(2)として、上記の実施例(1)におけるルータA及びルータAと同様の構成を有するルータBが通信回線により接続されており、さらに、ルータAには通信回線により診断用フレーム生成部Cfが接続されている場合について説明する。

この場合、図示の如く、従来は各ルータA及びBがそれぞれ必要としていた診断用コンソールCa及びCbが不要となる。

診断用フレーム生成部Cfは、診断用コンソールCa及びCbに代わるものであり、一台でルータA及びBの双方の診断を行なうものである。

動作において、診断用フレーム生成部Cfは、定期的又は所望の指定時に、ルータA及びルータBに宛てた診断用フレームF0を生成し、通信回線を介して送信する。但し、この場合、診断用フレーム生成部Cfは、ルータA及びルータB内でそれぞれ連想メモリに直結しているデバイスを予め把握しているものとし、このデバイスのアドレスを診断用フレームの宛先アドレスとして設定する。

診断用フレームF0を受信したルータA及びルータBは、それぞれ、宛先アドレスで指定されたデバイスが、図3に示した上記の実施例(1)におけるものと同様な診断用フレームの処理を行い、同図のステップS109において診断結果フレームFrを送信する。

図5に示す如く、ルータA及びBから送信された診断結果フレームFrは、通信回線を介して診断用フレーム生成部Cfに戻される。このため、診断用フレーム生成部Cfでは、各ルータA及びBの診断結果を一元的に把握することが出来る。

実施例(2)の応用例として、診断用フレーム生成部Cfは、定期的又は所望の指定時に、ルータA宛てに診断フレームF0を送信し、ルータAは自装置内のデバイスについて図3に示した上記の実施例(1)におけるものと同様な診断用フレームの処理を行った後、診断フレームF0をルータBに転送することも可能である。

この場合、ルータBにおける連想メモリは例えば図6に示す構成とすることが出来る。すなわち、診断用フレームF0がルータA及びルータBのステータス情報を格納できることから、ルータAの各デバイスの正常値（正常時におけるステータス情報の値）を示すアドレス“0x0000”のエントリとして、4ビットからなるエントリ種別“0x1”及びそれぞれ32ビットのデバイス1〜3のステータス情報が格納されている。

また、ルータBの各デバイスの正常値を示すアドレス“0x0001”のエントリとして、エントリ種別“0x2”及びそれぞれ32ビットのデバイス1〜3のステータス情報が格納されている。なお、上記のエントリ種別は、複数のルータが存在する場合に各ルータを識別するためのコードである。

同図の例では、連想メモリのコンテンツは1ルータ当り最大144ビットのステータス情報を格納することが出来る。すなわち、最大144ビットのステータス情報の検索が可能である。

例えば図5のルータBがこのような連想メモリを有していれば、ルータBにおいては、ルータA及びルータBの双方の診断結果を得ることも可能である。

なお、各ルータA及びBがそれぞれ独自に自装置内の診断処理を行なう場合は、同図のアドレス“0x0000”及び“0x0001”のエントリのみをそれぞれの連想メモリに格納しておけば良い。

デバイス1は、例えば、OSI参照モデルの第1層(PHY層)に位置するものを処理する機能を有するLSIである。OSI参照モデルはPHY層について、ネットワークの物理的な接続・伝送方式を定めている。英語表記の頭を取って「PHY」と略称されることもある。具体的には、ケーブルの材質やコネクタ形状、及びデータと電気信号の相互変換方式(電圧などの規定)等がこの層に属する。物理層ではデータの内容については一切関知しない。
デバイス2は、例えば、OSI7層モデルのデータリンク層の二つの副層のうち下位に位置するもの(MAC層)を処理する機能を有するLSIである。OSI参照モデルはMAC層について、フレーム(データの送受信単位)の送受信方法やフレームの形式、誤り検出方法などを規定する。
デバイス3は、例えば、LSC(Load Sharing Controllerの略)IPフレームの負荷分散機能を有し、FPGA(Filed Programable Logic)で設計される。LSCは到着したパケットのヘッダ情報をもとに振り分け先を決定し、Src/Dst MACアドレスの書き換えを行い振り分け先にパケットを送信する。振り分けの対象となるIPフレームのヘッダ情報をCAM(連想メモリ)に格納しておき、CAM検索の結果ヒットしたフレームに対しMACアドレスの書き換えを行いパケットの送信を行う。

（付記１）
縦続接続した一連の診断対象デバイスを順に経由する都度診断用フレームに記録される各診断対象デバイスの一連の最新ステータス情報を終端する診断用フレーム終端部と、
該一連の診断対象デバイスの正常時における各ステータス情報を該診断対象デバイスの接続順に並べた一連の正常ステータス情報を予め１つのエントリとして格納すると共に、終端された該一連の最新ステータス情報が該エントリと一致しなければ異常通知を発生する連想メモリと、
終端された該一連の最新ステータス情報を格納するステータス情報格納部と、
該異常通知を受けたとき、該ステータス情報格納部から該一連の最新ステータス情報を取得し出力するCPUと、
を備えたことを特徴とする通信装置。
（付記２）付記１において、
各診断対象デバイスは、該診断用フレーム受信時におけるそれぞれの最新のステータス情報を該診断用フレームに記録する手段を有することを特徴とする通信装置。
（付記３）付記１において、
該連想メモリと該CPUとが制御線で接続され、該CPUと該ステータス情報格納部とがPCIバスで接続されていることを特徴とする通信装置。
（付記４）付記１において、
該縦続接続した一連の診断対象デバイスの一端に位置する該診断対象デバイスを該連想メモリに直結し、該診断用フレームの宛先アドレスを該連想メモリに直結した該診断対象デバイスのアドレスとして、該診断用フレームを、他端に位置する該診断対象デバイスから入力することを特徴とする通信装置。
（付記５）付記１において、
該縦続接続した一連の診断対象デバイスの一端に接続され、該診断用フレームを生成して送信する診断用フレーム生成部を備えたことを特徴とする通信装置。
（付記６）付記５において、
該診断用フレームに対応して該連想メモリが異常通知を行ったか否かの情報を診断結果フレームとして該診断用フレーム生成部に送信する手段をさらに備えたことを特徴とする通信装置。
（付記７）付記５において、
該診断用フレーム生成部は、該診断用フレームを定期的又は所望の指定時に生成して送信することを特徴とする通信装置。

本発明に係る通信装置の原理構成例を示したブロック図である。本発明に係る通信装置の実施例（１）を示したブロック図である。実施例（１）における診断用フレームの処理フローを示したフローチャート図である。本発明における診断用フレームのフレームフォーマットを説明するための図である。本発明に係る通信装置の実施例（２）を示したブロック図である。実施例（２）における連想メモリの構成例を示した図である。従来の通信機能保守診断方式（１）を示したブロック図である。従来の通信機能保守診断方式（１）を用いたルータの内部構成例を示したブロック図である。従来の通信機能保守診断方式（２）を示したブロック図である。

符号の説明

1〜3 デバイス
4 回線インタフェース
5 回線系バス
6 PCIバス
10, 30 異常検出部
11, 31 表示部
12 割込み制御部
20, 40, 130 CPU
100 ハードウェア
110 連想メモリ
120 ステータス情報格納部
200 ソフトウェア
300 管理者又は上位CPU
A, B, X ルータ
Ca, Cb 診断用コンソール
Cf 診断用フレーム生成部
F0〜F3, Fn 診断用フレーム
Fr 診断結果フレーム
Fv4 通常のIPv4フレーム
図中、同一符号は同一又は相当部分を示す。

Claims

縦続接続した一連の診断対象デバイスを順に経由する都度診断用フレームに記録される各診断対象デバイスの一連の最新ステータス情報を終端する診断用フレーム終端部と、
該一連の診断対象デバイスの正常時における各ステータス情報を該診断対象デバイスの接続順に並べた一連の正常ステータス情報を予め１つのエントリとして格納すると共に、終端された該一連の最新ステータス情報が該エントリと一致しなければ異常通知を発生する連想メモリと、
終端された該一連の最新ステータス情報を格納するステータス情報格納部と、
該異常通知を受けたとき、該ステータス情報格納部から該一連の最新ステータス情報を取得し出力するCPUと、
を備えたことを特徴とする通信装置。
請求項１において、
各診断対象デバイスは、該診断用フレーム受信時におけるそれぞれの最新のステータス情報を該診断用フレームに記録する手段を有することを特徴とする通信装置。
請求項１において、
該連想メモリと該CPUとが制御線で接続され、該CPUと該ステータス情報格納部とがPCIバスで接続されていることを特徴とする通信装置。
請求項１において、
該縦続接続した一連の診断対象デバイスの一端に位置する該診断対象デバイスを該連想メモリに直結し、該診断用フレームの宛先アドレスを該連想メモリに直結した該診断対象デバイスのアドレスとして、該診断用フレームを、他端に位置する該診断対象デバイスから入力することを特徴とする通信装置。
請求項１において、
該縦続接続した一連の診断対象デバイスの一端に接続され、該診断用フレームを生成して送信する診断用フレーム生成部を備えたことを特徴とする通信装置。