(57)【要約】【課題】  マルチベンダ環境で、自装置と対向装置間の同一プロトコルによる相互動作をすることなく、自装置のみでネットワーク障害を高精度に検出する。【解決手段】  障害監視制御パケット送信部１１は、障害監視制御パケットを生成し、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置２０に対して、障害監視制御パケットを送信する。送信パケットカウンタ１２は、障害監視制御パケットの送信パケット数をカウントする。受信パケットカウンタ１３は、対向装置２０から送信される制御パケットを受信して、受信パケット数をカウントする。障害検出部１４は、送信パケット数と受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識し、外部へ通知する。【選択図】  図１
2006229477.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上の障害検出を行う障害検出装置において、
障害監視制御パケットを生成し、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置に対して、前記障害監視制御パケットを送信する障害監視制御パケット送信部と、
前記障害監視制御パケットの送信パケット数をカウントする送信パケットカウンタと、
前記対向装置から送信される制御パケットを受信して、受信パケット数をカウントする受信パケットカウンタと、
前記送信パケット数と前記受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識し、外部へ通知する障害検出部と、
を有することを特徴とする障害検出装置。
【請求項２】
前記障害監視制御パケット送信部は、装置内の上位レイヤの処理部に配置し、前記送信パケットカウンタは、装置内の前記対向装置と自装置が接続する物理レイヤまたはリンクレイヤの処理部に配置することで、前記障害検出部は、前記送信パケット数の監視を行って、前記上位レイヤと前記物理レイヤの処理部間の経路に発生する障害検出を保証することを特徴とする請求項１記載の障害検出装置。
【請求項３】
前記受信パケットカウンタは、装置内の上位レイヤの処理部に配置することで、前記障害検出部は、前記受信パケット数の監視を行って、前記対向装置から前記上位レイヤの処理部までの経路に発生する障害検出を保証することを特徴とする請求項１記載の障害検出装置。
【請求項４】
前記障害監視制御パケット送信部は、ユーザトラフィックが流れていないときであっても、誤った障害検出がされないように、ユーザトラフィックとは独立な前記障害監視制御パケットを常時一定間隔で送信することを特徴とする請求項１記載の障害検出装置。
【請求項５】
自装置と前記対向装置とが、複数リンクを仮想的な１つのリンクとみなすリンク・アグリゲーションで接続している場合には、前記障害監視制御パケット送信部は、前記複数リンクの各リンクから前記障害監視制御パケットを送信し、前記送信パケットカウンタは、前記複数リンクのリンク毎に送信パケット数をカウントし、前記受信パケットカウンタは、前記複数リンクの各リンクから前記対向装置から送信された制御パケットを受信して、リンク毎に受信パケット数をカウントし、前記障害検出部は、リンク毎に障害検出を行うことを特徴とする請求項１記載の障害検出装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、障害検出装置に関し、特にネットワーク上の障害検出を行う障害検出装置に関する。
【背景技術】
【０００２】
近年、通信事業者が提供する、ＬＡＮ（Local Area Network）を利用してのキャリアサービスとして、広域イーサネット（イーサネットは登録商標）があり、現在広がりを見せている。広域イーサネットは、イーサネットのＬＡＮ環境を、レイヤ２スイッチを使ってネットワークを接続し、複数のＬＡＮ環境を１つに統合するサービスである。
【０００３】
広域イーサネットは、高価なルータ（レイヤ３スイッチ）を用いずに、安価なスイッチングハブ（レイヤ２スイッチ）を使うので、ネットワークの構築や運用管理に関わるコストが削減でき、例えば、企業の構内ＬＡＮをつなげて、都市全体のエリアにまで拡張することが可能である。
【０００４】
また、このようなキャリアネットワークにおいて、ネットワーク障害が発生し、復旧が遅れると、被害も重篤なものになるため、装置内の各種パッケージの二重化、装置自身の二重化、リンクの二重化、エンド−エンド間のパスの二重化等の様々なレベルでの冗長構成が採用されており、障害検出時には冗長系側にすみやかに切り替えを行うことで耐障害性の向上を図っている。
【０００５】
ただし、冗長構成をいくら設けていても、装置自身が障害をすばやく的確に検出できなければ意味がなく、サイレント障害（冗長側への自動的な切り替えが行われず、またオペレータへのアラーム通知もなく、異常動作が生じていることが認識しにくい障害）が発生すると、障害期間が長時間続き、またイーサネット網においては、ループ（loop）が生じて、フレーム輻輳が発生してしまうおそれがある。
【０００６】
図１１、図１２はループによるネットワーク障害を説明するための図である。ネットワーク５０は、ノード５１〜５４で構成され、ノード５１〜ノード５４はリング状に互いに接続し、ノード５１とノード５４が接続している（図中、細実線が物理的な回線）。
【０００７】
ここで、イーサネット網を構築する場合には、ループ状の経路が生じないように、ツリー（tree）構造の経路となるように構築する。なぜなら、もし、ネットワーク上にループ状の経路が存在すると、フレームのブロードキャスト時に、ブロードキャスト・ストーム（broadcast storm）と呼ばれるフレーム輻輳が発生するからである。
【０００８】
すなわち、あるノードからブロードキャスト・フレームを送出したとき、ブロードキャスト・フレームは、各ノードにおいて、受信ポート以外のすべてのポートからフラッディング（flooding）されるので、ネットワーク内にループがあると、ブロードキャスト・フレームは、ループ内を無限に流れることになり、同じ経路を延々とブロードキャスト・フレームが巡ってしまう。
【０００９】
すると、帯域が瞬時にブロードキャスト・フレームで埋まってしまい、通常の通信ができなくなってしまう。例えば、図１１のように、ネットワーク５０にはループＲがあるので、ブロードキャスト・フレームがノード５１→ノード５２→ノード５３→ノード５４→ノード５１→・・・とうように、ループＲ上を無限に流れて輻輳が発生してしまう。
【００１０】
したがって、イーサネット網を構築する場合には、レイヤ２ネットワークでのループを論理的に遮断する必要がある。例えば、図１２のように、回線Ｌ１、Ｌ２を論理的に遮断すれば、すべてのループがなくなって、ツリーＴの構造が形成される（図中、太実線）。
【００１１】
このようなツリー（スパニングツリー（Spanning Tree）と呼ばれる）を形成するためには、例えば、ＳＴＰ（Spanning Tree Protocol）の制御により、各ノード間でＢＰＤＵ（Bridge Protocol Data Unit）と呼ばれる制御情報をやりとりし、トラヒック経路をダイナミックに変更する運用を行う（スタティックに運用する場合には、各ノードに対してあらかじめツリー経路となるように設定しておく）。これにより、物理的にループを形成しているネットワークであっても、フレームがループの中を巡り続ける事態を防ぐことができる。
【００１２】
ところが、図１２のようなスパニングツリーが形成されていても、ネットワーク５０にサイレント障害が発生して障害検出機能が効果的に働かないと、そのために各ノードでの経路認識が食い違ってきて、ツリー構造が崩れ、ループが生じてしまうおそれがある。したがって、サイレント障害の対策には、冗長構成を設けることの他にさらに、いかに高精度に障害を検出できるかということが重要な事項となる。
【００１３】
従来のイーサネットの障害検出として、ＬＡＮ内の装置でループバックテストを実行する技術が提案されている（例えば、特許文献１）。
【特許文献１】特開２００３−３０４２６４号公報（段落番号〔００２０〕〜〔００２７〕，第１図）
【発明の開示】
【発明が解決しようとする課題】
【００１４】
上記のような、サイレント障害が発生すると、運用系から冗長系への切替え契機は、顧客からの苦情によるしかなく、サービスの長時間の断となるため、各ベンダでは独自のプロトコルによって、ネットワーク障害を検出する取り組みがなされている。
【００１５】
図１３はネットワーク障害検出の流れを示す図である。ベンダ独自プロトコルによる一般的なネットワーク障害を検出する一動作例を示している。ノードＡ、ＢがリンクＬ３、Ｌ４で接続している。
【００１６】
〔Ｓ２１〕ノードＡは、リンクＬ３を通じて、フレームＦａをノードＢへ送信する。フレームＦａには、自ノード識別欄と他ノード識別欄があり、ノードＡでは、フレームＦａの自ノード識別欄に、自分がノードＡである旨の“Ａ”を挿入し、他ノード識別欄には、リンクＬ４から受信したフレームＦｂの自ノード識別欄に記されている“Ｂ”を折り返す形で挿入して送信する。
【００１７】
〔Ｓ２２〕ノードＢは、リンクＬ４を通じて、フレームＦｂをノードＡへ送信する。フレームＦｂは、自ノード識別欄と他ノード識別欄があり、ノードＢでは、フレームＦｂの自ノード識別欄に、自分がノードＢである旨の“Ｂ”を挿入し、他ノード識別欄には、リンクＬ３から受信したフレームＦａの自ノード識別欄に記されている“Ａ”を折り返す形で挿入して送信する。
【００１８】
〔Ｓ２３〕ノードＡは、フレームＦｂを受信すると、フレームＦｂの自ノード識別欄に記されている“Ｂ”という情報をメモリに記憶させる（すなわち、相手ノードがＢであることを記憶する）。なお、メモリのエージング時間（メモリをクリアする更新時間）を１分とし、フレームＦｂの送信間隔は２０秒とする。
【００１９】
〔Ｓ２４〕ノードＢは、フレームＦａを受信すると、フレームＦａの自ノード識別欄に記されている“Ａ”という情報をメモリに記憶させる（すなわち、相手ノードがＡであることを記憶する）。なお、メモリのエージング時間を１分とし、フレームＦａの送信間隔は２０秒とする。
【００２０】
〔Ｓ２５〕ノードＡは、フレームＦｂが３回来ないとメモリをクリアすることになり、このとき他ノード識別欄に“０”を挿入したフレームＦａ−１を生成してノードＢへ送信する。また、ノードＡは、フレームＦｂが３回来ないことで、リンクＬ４（または対向のノードＢ）に障害が発生していることを検出する。
【００２１】
〔Ｓ２６〕ノードＢは、フレームＦａ−１を受信すると、他ノード識別欄に“０”が挿入されていることを認識する。すなわち、自分のノード識別名（Ｂ）がノードＡに伝わっておらず、自分が送信しているフレームＦｂがノードＡに正常受信されていないことを認識し、リンクＬ４（または対向のノードＡ）に障害が発生していることを検出する。
【００２２】
このように、「対向装置から制御フレームを一定期間受信しないこと」及び「対向装置から受信する制御フレーム中の折り返し情報が、自装置が送信した情報と異なること」によって、送受信ノード間で障害検出を行うことができる。
【００２３】
しかし、このような現状のベンダ独自プロトコルによるネットワーク障害検出では、上記の例のような、対向装置側の監視内容を意識した上での制御を行うことを前提としているため、ネットワーク内の自社装置間で接続されたリンクしか対応できないといった問題があった。
【００２４】
このため、マルチベンダ化が進んでいる現在のキャリアネットワークに対して、利便性が乏しいといった問題があり、さらにネットワーク検出障害のプロトコルの標準化も進展していないのが現状である。
【００２５】
このため、マルチベンダ環境において、自装置と対向装置間で同一プロトコルによる相互動作をすることなく、対向装置側が障害の監視を何ら意識せずに、ネットワーク障害を検出できれば、非常に耐障害性の向上という意味での効果が期待され、このような技術の実現が強く要望されている。
【００２６】
本発明はこのような点に鑑みてなされたものであり、対向装置間で同一プロトコルによる相互動作をすることなく、自装置のみでネットワーク障害を高精度に検出する障害検出装置を提供することを目的とする。
【課題を解決するための手段】
【００２７】
本発明では上記課題を解決するために、図１に示すような、ネットワーク上の障害検出を行う障害検出装置１０において、障害監視制御パケットを生成し、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置２０に対して、障害監視制御パケットを送信する障害監視制御パケット送信部１１と、障害監視制御パケットの送信パケット数をカウントする送信パケットカウンタ１２と、対向装置２０から送信される制御パケットを受信して、受信パケット数をカウントする受信パケットカウンタ１３と、送信パケット数と受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識し、外部へ通知する障害検出部１４と、を有することを特徴とする障害検出装置１０が提供される。
【００２８】
ここで、障害監視制御パケット送信部１１は、障害監視制御パケットを生成し、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置２０に対して、障害監視制御パケットを送信する。送信パケットカウンタ１２は、障害監視制御パケットの送信パケット数をカウントする。受信パケットカウンタ１３は、対向装置２０から送信される制御パケットを受信して、受信パケット数をカウントする。障害検出部１４は、送信パケット数と受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識し、外部へ通知する。
【発明の効果】
【００２９】
本発明の障害検出装置は、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置に対して、障害監視制御パケットを送信して障害監視制御パケットの送信パケット数をカウントし、対向装置から送信される制御パケットを受信して、受信パケット数をカウントし、送信パケット数と受信パケット数に対して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識する構成とした。これにより、マルチベンダ環境において、自装置と対向装置間で同一プロトコルによる相互動作をすることなく、自装置のみでネットワーク障害を高精度に検出することが可能になる。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の実施の形態を図面を参照して説明する。図１は障害検出装置の原理図である。障害検出装置１０は、障害監視制御パケット送信部１１、送信パケットカウンタ１２、受信パケットカウンタ１３、障害検出部１４から構成され、ネットワーク上の障害検出を行う装置である。障害検出装置１０の機能は、例えば、広域イーサネット内のレイヤ２スイッチなどに適用可能である。
【００３１】
障害監視制御パケット送信部１１は、障害監視制御パケットを生成し、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置２０に対して（すなわち、自社製品とは異なる他社の製品に対して）、障害監視制御パケットを送信する。送信パケットカウンタ１２は、障害監視制御パケットの送信パケット数をカウントする。
【００３２】
受信パケットカウンタ１３は、対向装置２０から送信される制御パケットを受信して、受信パケット数をカウントする。障害検出部１４は、送信パケット数と受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識し、外部へ通知する。
【００３３】
次に障害監視制御パケット送信部１１、送信パケットカウンタ１２及び受信パケットカウンタ１３の障害検出装置１０内の配置位置について説明する。図２は障害検出装置１０のブロック構成を示す図である。障害検出装置１０は、スイッチング処理部１０１、出力パケット処理部（Egress Process）１０２ａ、入力パケット処理部（Ingress Process）１０２ｂ、ＭＡＣ（Media Access Control）処理部１０３ａ、１０３ｂ、リンクインタフェース部１０４ａ、１０４ｂ、ＣＰＵ１０５から構成される。
【００３４】
出力パケット処理部１０２ａは、スイッチング処理部１０１でスイッチングされたパケットの入力処理を行い、ＭＡＣ処理部１０３ａは、ＭＡＣレイヤの終端処理を行う。リンクインタフェース部１０４ａは、物理レイヤでの送信インタフェース処理を行って、パケットを対向装置２０へリンクＬを介して送信する。
【００３５】
また、リンクインタフェース部１０４ｂは、リンクＬを介して送信された対向装置２０からのパケットに、物理レイヤでの受信インタフェース処理を行い、ＭＡＣ処理部１０３ａは、ＭＡＣレイヤの終端処理を行う。入力パケット処理部１０２ｂは、パケットの出力処理を行ってスイッチング処理部１０１へ送信する。ＣＰＵ１０５は、各構成ブロックの全体制御を行う。
【００３６】
ここで、障害監視制御パケット送信部１１の機能は、出力パケット処理部１０２ａに配置し、送信パケットカウンタ１２は、リンクインタフェース部１０４ａに配置する。そして、出力パケット処理部１０２ａから障害監視制御パケットを一定間隔で流して、リンクインタフェース部１０４ａでその障害監視制御パケットをカウントする。
【００３７】
障害検出部１４の機能を有するＣＰＵ１０５は、送信パケットカウンタ１２でカウントされる送信パケット数を監視して、一定時間内にパケット数に変化がなければ障害発生とみなす（障害監視制御パケット送信部１１から一定間隔で障害監視制御パケットが送信されるので、一定時間カウントアップされていなければ障害が発生していることになる）。
【００３８】
この場合、出力パケット処理部１０２ａ→ＭＡＣ処理部１０３ａ→リンクインタフェース部１０４ａの経路が、障害検出の保証範囲となる（ただし、この送信側の障害検出では、対向装置２０に確実にパケットが送信されていることは確認できないが、リンクＬが確立した状態で、少なくてもリンクインタフェース部１０４ａまでが正常であれば、トラフィックが対向装置２０に届かない確率は非常に低いので、障害検出のカバー範囲は広くなる）。
【００３９】
一方、受信パケットカウンタ１３は、入力パケット処理部１０２ｂに配置し、入力パケット処理部１０２ｂにおいて、対向装置２０から送信されたパケットをカウントする。
障害検出部１４の機能を有するＣＰＵ１０５は、受信パケットカウンタ１３でカウントされる受信パケット数を監視して、一定時間内にパケット数に変化がなければ障害発生とみなす（対向装置２０から一定間隔で制御パケットが送信されるので、一定時間カウントアップされていなければ障害が発生していることになる）。この場合、対向装置２０→リンクインタフェース部１０４ｂ→ＭＡＣ処理部１０３ｂ→入力パケット処理部１０２ｂの経路が、障害検出の保証範囲となる。
【００４０】
このように、障害監視制御パケットを送信して障害検出を行う場合は、障害監視制御パケット送信部１１を装置の上位レイヤ処理側（装置の内側）に配置し、送信パケットカウンタ１２を物理レイヤ処理（装置の外側）に配置する。また、対向装置２０から送信される制御パケットによる障害検出を行う場合は、受信パケットカウンタ１３を装置の上位レイヤ処理側に配置する。このような配置にすることで、上記のように障害検出の保証範囲を最も広くとることが可能になる。
【００４１】
次に１本のリンクにおける障害検出動作について説明する。図３は装置間が１本のリンクで接続された際の障害検出動作を示すシーケンス図である。障害検出装置１０の機能を有する装置を自社装置１０ａ、対向装置２０を他社装置２０ａとし、互いに１本のリンクＬで接続している。
【００４２】
〔Ｓ１〕自社装置１０ａ内の障害監視制御パケット送信部１１は、障害監視用の独自のパケットである障害監視制御パケットを一定間隔で他社装置２０ａへ送信する。なお、この障害監視制御パケットは、他社装置２０ａで受信されたときに廃棄されるものであり、ペイロードには何の制御内容をも含まないパケットである。
【００４３】
〔Ｓ２〕自社装置１０ａ内の送信パケットカウンタ１２は、障害監視制御パケットをカウントする。
〔Ｓ３〕自社装置１０ａ内の障害検出部１４は、カウントされる送信パケット数を監視する。カウント値に変化がなければ（カウントアップされてなければ）ステップＳ４へいき、変化があれば監視を続ける。
【００４４】
〔Ｓ４〕障害検出部１４は、自社装置１０ａに障害が発生しているものとみなし外部へアラーム通知する。
〔Ｓ５〕他社装置２０ａは、制御パケットを送信する。この制御パケットは、他社装置２０ａから送信される何らかの制御パケットであり（カウント動作のみに用いるためどのような制御パケットでもよい）、一定間隔で送信されるものである。
【００４５】
〔Ｓ６〕自社装置１０ａ内の受信パケットカウンタ１３は、制御パケットを受信してカウントする。
〔Ｓ７〕自社装置１０ａ内の障害検出部１４は、カウントされる受信パケット数を監視する。カウント値に変化がなければステップＳ８へいき、変化があれば監視を続ける。
【００４６】
〔Ｓ８〕障害検出部１４は、他社装置２０ａから自社装置１０ａ間の経路に障害が発生しているものとみなし外部へアラーム通知する。
ここで、ステップＳ１、Ｓ５において、障害監視制御パケットと制御パケットは、常時一定間隔でリンクＬ上に送出されるユーザトラフィックとは独立したパケットとする。
【００４７】
なぜなら、もしユーザトラフィックに関連するパケットを使用して、パケット数のカウント値による障害検出を行うと、夜間などではユーザトラフィックが減少しカウント値の変化が起こらず、通信状態が正常であっても障害が発生していると誤って検出するおそれがあるからである。
【００４８】
このため、自社装置１０ａからはユーザトラフィックとは無関係な独自の障害監視制御パケットを送信し、また他社装置２０ａから送信されるユーザトラフィックとは無関係な何らかの制御パケットを受信することで、ユーザトラフィックが流れていないときであっても、誤検出のない障害検出を可能にしている。
【００４９】
また、ステップＳ４、Ｓ８ではアラーム通知を行ってオペレータに保守動作を促しているが、その後の障害検出装置１０の動作として、該当ポートを無効化する処理が行われる（対向装置２０はリンク断を検出することになる）。無効化されたポートの復旧は、手動または定期的に自動復旧が行われる。さらに、障害検出をリンク冗長／装置冗長への切り替え契機として、冗長系へ切り替えることも可能である。
【００５０】
以上説明したように、障害検出装置１０では、自装置側で統計情報として送信パケット数及び受信パケット数を計測して、これらの統計情報を収集し、障害検出を行う構成とした。このような構成により、対向装置２０側の監視内容を意識せずに障害検出を行うことができる。すなわち、マルチベンダ環境において、自装置と対向装置間で同一プロトコルによる相互動作をすることなく、対向装置２０側が障害の監視を何ら意識せずに、また冗長ポートを追加するなどといった作業も不要であり、効率よくネットワーク障害を検出できる。このため、従来のように、自社装置間でのみ接続されたリンクしか障害検出ができないといった不便さがなくなり、他ベンダ装置に接続しても、高精度にネットワーク障害が検出できるので、マルチベンダ環境において対耐障害性の向上を図ることが可能になる。
【００５１】
次に自社装置１０ａと他社装置２０ａがリンク・アグリゲーション（Link Aggregation（以降ＬＡと呼ぶ））で接続している際の障害検出動作について説明する。なお、ＬＡは、複数リンクを仮想的な１つのリンクとみなす接続方式であり、IEEE.802.3adで規定されている。
【００５２】
図４は装置間がＬＡで接続された際の障害検出動作を示すシーケンス図である。自社装置１０ａと他社装置２０ａが３本のリンクＬ１〜Ｌ３で接続し、このリンクＬ１〜Ｌ３を仮想的な１本のリンクとして使用するものとする。
【００５３】
〔Ｓ１１〕自社装置１０ａ内の障害監視制御パケット送信部１１は、障害監視用の独自のパケットである障害監視制御パケットをリンクＬ１〜Ｌ３を介して、一定間隔で他社装置２０ａへ送信する。
【００５４】
〔Ｓ１２〕自社装置１０ａ内の送信パケットカウンタ１２は、リンクＬ１〜Ｌ３毎に流れる障害監視制御パケットをカウントする。
〔Ｓ１３〕自社装置１０ａ内の障害検出部１４は、リンクＬ１〜Ｌ３毎にカウントされる送信パケット数を監視する。カウント値に変化がなければステップＳ１４へいき、変化があれば監視を続ける。
【００５５】
〔Ｓ１４〕障害検出部１４は、自社装置１０ａに障害が発生しているものとみなし外部へアラーム通知する。
〔Ｓ１５〕他社装置２０ａは、リンクＬ１〜Ｌ３を介して、制御パケットを送信する。
【００５６】
〔Ｓ１６〕自社装置１０ａ内の受信パケットカウンタ１３は、リンクＬ１〜Ｌ３毎に制御パケットを受信してカウントする。
〔Ｓ１７〕自社装置１０ａ内の障害検出部１４は、リンクＬ１〜Ｌ３毎にカウントされる受信パケット数を監視する。カウント値に変化がなければステップＳ１８へいき、変化があれば監視を続ける。
【００５７】
〔Ｓ１８〕障害検出部１４は、他社装置２０ａから自社装置１０ａ間の経路に障害が発生しているものとみなし外部へアラーム通知する。
次に障害検出装置１０を具体的に実現した際の構成及び動作について説明する。図５は障害検出装置１０の機能を有する通信装置の構成を示す図である。通信装置３０は、装置管理部３１、ＣＬ（command line）／ＮＭＳ（network management system）インタフェース部３２、ＬＣＣ（Link Connectivity Check）プロトコル処理部３４、フィルタリングデータベース処理部３５、回線／スイッチ制御部３６、スイッチング処理部３７、回線インタフェース処理部３８−１〜３８−ｎから構成される。
【００５８】
なお、障害監視制御パケット送信部１１、送信パケットカウンタ１２及び受信パケットカウンタ１３の機能は、回線インタフェース処理部３８−１〜３８−ｎに含まれ、障害検出部１４の機能は、ＬＣＣプロトコル処理部３４に含まれる。
【００５９】
装置管理部３１は、装置全体の管理を行う。具体的にはプロビジョニング情報管理部３３と連携し、装置のプロビジョニング情報にもとづき、スイッチング処理部３７、回線インタフェース処理部３８−１〜３８−ｎ、ＬＣＣプロトコル処理部３４に動作条件を指示する。
【００６０】
また、スイッチング処理部３７／回線インタフェース処理部３８−１〜３８−ｎ／ＬＣＣプロトコル処理部３４から、動作状態／障害発生／障害復旧等に関する情報を入手し、必要なアクションを取る。障害検出制御を行う装置管理部３１に対する機能拡張例を以下の（Ａ１）〜（Ａ４）に示す。
【００６１】
（Ａ１）プロビジョニング情報管理部３３との連携によりポート毎にadminstatusパラメータの設定情報を読み出し、これにもとづき、ＬＣＣプロトコル処理部３４に動作条件の指示を行う。
【００６２】
（Ａ２）ＬＣＣプロトコル処理部３４からの通知により、障害検出をオペレータへ通知する。
（Ａ３）ＬＣＣプロトコル処理部３４からの通知により、障害検出を知り、必要によりフィルタリングデータベース処理部３５に対して、フィルタリングデータベースのフラッシュを指示する。
【００６３】
（Ａ４）ＬＣＣプロトコル処理部３４からの通知により、障害検出を知り、必要により回線／スイッチ制御部３６を経由し、回線インタフェース処理部３８−１〜３８−ｎに対して、Disableステートへの遷移を指示する。
【００６４】
ＣＬ／ＮＭＳインタフェース部３２は、CL（コマンドライン）／NMS（ネットワーク管理システム）とのインタフェースを司り、ここでは、プロビジョニング情報管理部３３と連携し、管理情報の設定及び表示を行う。
【００６５】
プロビジョニング情報管理部３３は、ＣＬ／ＮＭＳインタフェース部３２からの指示に従い、プロビジョニング情報を設定／表示すると共に、該当プロビジョニング情報を各機能ブロックに対して参照可能とする。
【００６６】
ＬＣＣプロトコル処理部３４は、ＬＣＣの動作主体であり、装置管理部３１から指示された動作条件に従い、障害を検出した場合は、その旨を装置管理部３１に通知する。障害検出制御を行うＬＣＣプロトコル処理部３４に対する機能拡張例を以下の（Ｂ１）〜（Ｂ５）に示す。
【００６７】
（Ｂ１）装置管理部３１からの指示により、ポート毎に障害監視機能／制御パケット送信機能の有効化／無効化を行い、ポート状態ステートマシン＃１〜＃ｎに動作指示を出すとともに、必要に応じて、回線インタフェース処理部３８−１〜３８−ｎに障害監視の開始／停止を指示する。
【００６８】
（Ｂ２）制御パケット送信機能が有効の場合、必要に応じて、回線インタフェース処理部３８−１〜３８−ｎに障害監視用制御パケットを装置管理部３１から指示された間隔で送信する事を指示する。
【００６９】
（Ｂ３）障害監視機能が有効の場合、回線インタフェース処理部３８−１〜３８−ｎからの障害検出通知／復旧通知を受信し、ポート状態ステートマシン＃１〜＃ｎに該当イベントの発生を通知する。
【００７０】
（Ｂ４）ポート状態ステートマシン＃１〜＃ｎの動作により、障害を認識し、該当ポートが障害である旨を、装置管理部３１に通知する。
（Ｂ５）装置管理部３１からの指示により、回線／スイッチ制御部３６を経由し、回線インタフェース処理部３８−１〜３８−ｎに対して、Disableステートへの遷移を指示する。
【００７１】
フィルタリングデータベース処理部３５は、プロビジョニング情報管理部３３、装置管理部３１、回線インタフェース処理部３８−１〜３８−ｎと連携し、ＭＡＣフィルタリングデータベースの原本を管理し、各回線インタフェース処理部に対して、必要なＭＡＣフィルタリングデータベースを提供するとともに、スイッチング制御部３７に対して、必要なスイッチングを指示する。
【００７２】
回線／スイッチ制御部３６は、装置管理部３１からの指示に従い、スイッチング処理部３７／回線インタフェース処理部３８−１〜３８−ｎに対して、動作条件を通知するとともに、スイッチング処理部３７／回線インタフェース処理部３８−１〜３８−ｎからの動作状態／障害発生／障害復旧等に関する情報を装置管理部３１に通知する。
【００７３】
スイッチング処理部３７は、回線／スイッチ制御部３６からの指示に従い、各回線インタフェース処理部及び自装置内の必要な機能ブロックとのスイッチングを行う。
回線インタフェース処理部３８−１〜３８−ｎは、回線／スイッチ制御部３６からの指示に従い、ＭＡＣフィルタリングデータベースを参照することによるパケットの送受信を行う。障害検出制御を行う回線インタフェース処理部３８−１〜３８−ｎに対する機能拡張例を以下の（Ｃ１）、（Ｃ２）に示す。
【００７４】
（Ｃ１）ＬＣＣプロトコル処理部３４からの指示により、障害監視ステートマシン＃１〜＃ｎに対して、障害監視の開始／停止を指示する。
（Ｃ２）障害監視ステートマシン＃１〜＃ｎは、統計情報（カウント値）の受信パケット数と送信パケット数の変化を周期的に監視し、障害検出／復旧検出をＬＣＣプロトコル処理部３４に通知する。
【００７５】
次に通信装置３０における障害検出の動作設定について説明する。
（１）障害検出用監視統計情報
（１ａ）受信パケット数：ＭＡＣチップの受信ユニキャストパケット数と受信非ユニキャストパケット数との和の変化を監視する。ただし、ＣＬＩによりクリアされないカウンタを監視する。
【００７６】
（１ｂ）送信パケット数：ＭＡＣチップの送信ユニキャストパケット数と送信非ユニキャストパケット数との和の変化を監視する。ただし、ＣＬＩによりクリアされないカウンタを監視する。
【００７７】
（２）単一物理ポートに対して、以下の動作指定を行う。
（２ａ）特定のMAC DA（マルチキャストアドレス／対向装置のユニキャストアドレス）、Ethertypeを付与した制御パケットを特定の送信間隔で送信する事を指定する。
【００７８】
（２ｂ）障害検出時の動作モードを指定する。
（TRAP通知のみ（障害検出時にアラーム通知をして保守動作を促すこと）／TRAP通知＋shutsown（障害検出時にアラーム通知をして保守動作を促し、該当ポートを無効化すること）／TRAP通知＋shutsown＋自動復旧（障害検出時にアラーム通知をして保守動作を促し、該当ポートを無効化し、定期的に自動復旧を試みること）。
【００７９】
（２ｃ）障害検出保護回数を指定する。
障害検出タイマ値×障害検出保護回数→この期間障害が継続した場合障害とする。障害検出タイマは８秒固定とする（受信パケット数または／送信パケット数がこのタイマの期間変化しなかった場合障害とする）。
【００８０】
（３）障害監視制御パケットの送信開始契機は以下とする。
「該当ポートがＬＣＣ機能を指定されている状態」かつ「該当ポートの物理ポートがUP状態」へ遷移時で該当ポートがパケットの送受信が可能となった時。
【００８１】
（４）送信パケット数／受信パケット数の変化の監視開始契機は以下とする（物理ポートのLINK UP／DOWNを考慮する）。
（４ａ）「該当ポートがＬＣＣ機能を指定されている状態」かつ「該当ポートがリンクアップ中」へ遷移時。
【００８２】
（４ｂ）「監視正常状態」で該当ポートのリンクダウンを検出後、リンクアップを検出時。
（４ｃ）TRAP通知モードで障害検出後、自動復旧した場合。
【００８３】
（４ｄ）TRAP通知モードで障害検出後、復旧待ち状態で、該当ポートのリンクダウンを検出後、リンクアップを検出時。
（４ｅ）TRAP通知＋shutdownモードで、障害検出によるshutdownを実施後、オペレータからの復旧指示によりリンクアップを試み、リンクアップした時。
【００８４】
なお、上記リンクアップ検出時は常に、該当ポートがパケットの送受信が可能となったことが条件として加わる。
（５）送信パケット数／受信パケット数の変化の監視停止契機は以下とする（物理ポートのLINK UP／DOWNを考慮する）。
【００８５】
（５ａ）該当ポートがＬＣＣ機能の指定を解除された時。
（５ｂ）該当ポートがリンクダウンした時。
（５ｃ）該当ポートがTRAP通知＋shutdown及びTRAP通知＋shutsown＋自動復旧モードで運用中に、障害検出によるshutdownを実施した場合。
【００８６】
（６）shutdownと通常のshutdownの識別と復旧方法
（６ａ）新たに本機能で認識するポート状態（LccOperStatus）を設け、ifOperStatusがdown状態で、LccOperStatusがfailureの時に、本機能によりshutdownを実施したものと判断する。
【００８７】
（６ｂ）上記状態からの復旧は、noshutdownコマンドにより行う。
（６ｃ）障害の検出そのものは、システムとしての警報の扱いの対象外とする。つまり、本機能による障害の検出そのものでは、TRAP通知のみとする。
【００８８】
（７）障害監視方式を以下に示す。
（７ａ）（４）に示す条件を障害監視のトリガとする。
（７ｂ）（２）で規定した障害検出タイマを周期として、（１）で規定した「受信パケット数」と「送信パケット数」の変化を監視する。
【００８９】
（７ｃ）前の周期で収集した「受信パケット数」／「送信パケット数」と現周期で収集した「受信パケット数」／「送信パケット数」を比較し、どちらかが一致した場合、障害と判断し、この障害検出が指定された保護回数連続した時、一致したカウンタ名及びポートIDを付加情報として障害検出を通知する。
【００９０】
（７ｄ）障害検出中は、上記と同様の方式で復旧を監視する。復旧の判定は前の周期で収集した「受信パケット数」／「送信パケット数」と現周期で収集した「受信パケット数」／「送信パケット数」を比較し、双方が不一致の場合とし、ポートIDを付加情報として障害検出を通知する。
【００９１】
（７ｅ）（５）で規定した条件をトリガとして、障害監視を停止する。
次に障害監視制御パケットのフォーマットについて説明する。図６は障害監視制御パケットのフォーマットを示す図である。図中の数値はbyteを表す。各フィールドの説明を以下に示す。
【００９２】
MAC DA[６]は、宛先MACアドレスであり、コマンドにて指定されたアドレスを設定する。デフォルトで01-00-0E-00-00-01。MAC SA[６]は、送出元MACアドレスであり、自装置のMACアドレスを設定する。
【００９３】
L／T[２]は、障害監視制御パケットのEther-Typeであり、 コマンドにて指定された値を設定する。Sub Type[１]は、0x20固定とする（0x20が障害監視制御パケットであることを示す識別番号となる）。
【００９４】
Flags[１]は、０固定とする。Code[２]は、＜02-00＞とし、ＬＣＣ機能の制御パケットを示す。TTL（Time to Live）[１]はリザーブとする（２５５固定）。TTL base[１]は、リザーブ（２５５固定）とする。
【００９５】
Sequence number[２]は、０固定とする。Slot-ID[１]は、パケットを送信するポートのスロット識別子である。Port-ID[１]は、パケットを送信するポートのポート識別子である。Padding[３６]は、ALL“０”を設定する。
【００９６】
次に通信装置３０のポート状態ステートマシン及び障害監視ステートマシンについて説明する。図７、図８はポート状態ステートマシン＃１〜＃ｎの状態遷移を示す図である。変数の定義を以下に示す。
【００９７】
LccAdminStatus：ＬＣＣ機能の該当ポートへの設定状態。disable,enableの状態を持つ。
ifOperStatus：該当ポートのオペレーショナルリンク状態。up,down,dormant（新規追加）の３つの状態を持つ。dormant状態へは、本機能によりshutdownされた場合に遷移し、他状態への遷移は通常のshutdownコマンドが投入された場合のみ遷移する。
【００９８】
LccOperStatus：本機能における該当ポートの状態であり、監視機能無効、監視正常、障害中、監視休止中の状態を持つ。監視機能無効（disable）は、本機能が指定されていない状態または指定されたがリンクがアップしていない状態である。監視正常（normal）は、本機能による監視状態にあり、正常な状態である。障害中（failure）は、本機能による障害を検出した状態で、動作モードにより、該当ポートのifOperStatusはdormant状態の場合とup状態の場合がある。監視休止中（unknown）は、本機能による監視正常時にリンクダウンを検出（ifOperStatusがdown）し、監視を休止している状態である。
【００９９】
LccMonStartInd：障害監視ステートマシンへの動作指示。動作指示内容として、trueは、この値に変化したことにより、障害監視ステートマシンは監視を開始する。falseは、この値に変化したことにより、障害監視ステートマシンは監視を停止する。
【０１００】
LccMode： 本機能による障害検出時の動作モードを意味する（コマンドにより指定）。動作モードには、shutdown（障害検出時、shutdownするモード）とnoShutdown（障害検出時、shutdownしないモード）がある。
【０１０１】
次にポート状態ステートマシン＃１〜＃ｎの関数の定義を示す。
noticeNormalTrap（）： 障害監視を開始した事を示すTRAPを送信する。付加情報として、検出portidを付与する。
【０１０２】
noticeFailTrap（）：本機能による障害を検出した事を示すTRAPを送信する。付加情報として、検出portid,障害種別（Rx／Tx／RxTx）を付与する。
LccShutdown（）：ＬＣＣ機能によるshutdownを実行する。
【０１０３】
図９、図１０は障害監視ステートマシン＃１〜＃ｎの状態遷移を示す図である。変数の定義を以下に示す。
prevRxCount：直前の周期で収集した受信パケットカウンタの内容を示す。
【０１０４】
prevTxCount：直前の周期で収集した送信パケットカウンタの内容を示す。
currRxCount：現周期で収集した受信パケットカウンタの内容を示す。
currTxCount：現周期で収集した送信パケットカウンタの内容を示す。
【０１０５】
rxCount：getStatistics関数で収集した受信パケットカウンタの内容を示す。
txCount：getStatistics関数で収集した送信パケットカウンタの内容を示す。
rxFail：受信パケットカウンタの監視が正常か否かを示す変数（障害監視で使用）。
【０１０６】
txFail：送信パケットカウンタの監視が正常か否かを示す変数（障害監視で使用）。
rxFail2：受信パケットカウンタの監視が正常か否かを示す変数（復旧監視で使用）。
txFail2：送信パケットカウンタの監視が正常か否かを示す変数（復旧監視で使用）。
【０１０７】
timerExp：タイマステートマシンにより、登録されたタイマが満了時、trueに設定される変数。
monTimer：タイマステートマシンに登録されるタイマ変数。タイマステートマシンは、本変数が０以外の時に１秒周期で１減算し、０になるとtimerExpをtrueに設定する。
【０１０８】
adminMonTimer：監視タイマとして設定された変数（R2.3では８固定）。
rxCompRslt：compStatistics関数の実行結果が格納される変数（受信パケットカウンタ）。
【０１０９】
txCompRslt：compStatistics関数の実行結果が格納される変数（送信パケットカウンタ）。
detectGuardTimes：保護回数連続障害検出判定用変数。
【０１１０】
adminGuardTimes：CLIにより指定された保護回数。
次に障害監視ステートマシン＃１〜＃ｎにおける関数の定義を示す。
getStatistics（）：統計情報の受信パケットカウンタと送信パケットカウンタを参照し、その結果を、それぞれrxCount,txCountに格納する。
【０１１１】
compStatistics（）：prevRxCountとcurrRxCount／prevTxCountとcurrTxCountを比較し、その結果をそれぞれ、rxCompRslt／txCompRsltに格納する（一致したらtrueを一致しなかったらfalseを設定する）。
【０１１２】
failNotics（）：LccOperStatusにfailureを設定する事によりポート状態ステートマシンに障害検出を通知する（rxFail／txFailは付加情報としてポート状態ステートマシンにより参照される）。
【０１１３】
recovNotics（）：LccOperStatusにnormalを設定する事によりポート状態ステートマシンに障害復旧の検出を通知する。
制御パラメータ（送信）は、宛先MACアドレス、Ether Type、制御パケット送信間隔（固定：３秒）からなる。制御パラメータ（監視）は、監視タイマ（固定：８秒とし、この時間送受信パケット数のどちらかが変化しない場合、障害と判定する）。動作モード、保護回数からなる。
【０１１４】
保守者への通知（TRAP）は、障害を検出したことを通知する。このとき、付加情報として、障害検出ポートや障害種別（Rx／Tx／RxTx）を通知する。また、TRAPにより、障害が復旧したことを通知し、このとき付加情報として、復旧検出ポートを通知する。
【０１１５】
保守者への通知（CLI）は、Link Connectivity Check（ＬＣＣ）機能に関する設定状態をコマンドにより、参照可能とする。または監視ポートの状態をコマンドにより、参照可能とする（ポート状態：正常（normal）、障害中（failure）、未知（unknown）、監視無効（disable）。
【０１１６】
フィルタリング条件は、受信制御パケットは障害監視用統計情報収集後、廃棄することする。
以上説明したように、障害検出装置１０は、マルチベンダ環境のキャリアネットワークにおけるリンクのサイレント障害の検出に有効であり、ネットワークの耐障害性の向上を図ることが可能になる。特に、障害検出装置１０は、独自機能でありながら、他社装置に何ら変更を必要としないためキャリアにとって、マルチベンダ環境における導入を容易にする。
【０１１７】
（付記１）  ネットワーク上の障害検出を行う障害検出装置において、
障害監視制御パケットを生成し、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置に対して、前記障害監視制御パケットを送信する障害監視制御パケット送信部と、
前記障害監視制御パケットの送信パケット数をカウントする送信パケットカウンタと、
前記対向装置から送信される制御パケットを受信して、受信パケット数をカウントする受信パケットカウンタと、
前記送信パケット数と前記受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識し、外部へ通知する障害検出部と、
を有することを特徴とする障害検出装置。
【０１１８】
（付記２）  前記障害監視制御パケット送信部は、装置内の上位レイヤの処理部に配置し、前記送信パケットカウンタは、装置内の前記対向装置と自装置が接続する物理レイヤまたはリンクレイヤの処理部に配置することで、前記障害検出部は、前記送信パケット数の監視を行って、前記上位レイヤと前記物理レイヤの処理部間の経路に発生する障害検出を保証することを特徴とする付記１記載の障害検出装置。
【０１１９】
（付記３）  前記受信パケットカウンタは、装置内の上位レイヤの処理部に配置することで、前記障害検出部は、前記受信パケット数の監視を行って、前記対向装置から前記上位レイヤの処理部までの経路に発生する障害検出を保証することを特徴とする付記１記載の障害検出装置。
【０１２０】
（付記４）  前記障害監視制御パケット送信部は、ユーザトラフィックが流れていないときであっても、誤った障害検出がされないように、ユーザトラフィックとは独立な前記障害監視制御パケットを常時一定間隔で送信することを特徴とする付記１記載の障害検出装置。
【０１２１】
（付記５）  前記障害監視制御パケット送信部は、前記対向装置で受信されたときに廃棄され、ペイロードに制御内容を含まない前記障害監視制御パケットを生成し送信することを特徴とする付記４記載の障害検出装置。
【０１２２】
（付記６）  自装置と前記対向装置とが、複数リンクを仮想的な１つのリンクとみなすリンク・アグリゲーションで接続している場合には、前記障害監視制御パケット送信部は、前記複数リンクの各リンクから前記障害監視制御パケットを送信し、前記送信パケットカウンタは、前記複数リンクのリンク毎に送信パケット数をカウントし、前記受信パケットカウンタは、前記複数リンクの各リンクから前記対向装置から送信された制御パケットを受信して、リンク毎に受信パケット数をカウントし、前記障害検出部は、リンク毎に障害検出を行うことを特徴とする付記１記載の障害検出装置。
【０１２３】
（付記７）  ネットワーク上の障害検出を行う障害検出方法において、
障害監視制御パケットを生成して、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置に対して、前記障害監視制御パケットを送信し、
前記障害監視制御パケットの送信パケット数を、送信パケットカウンタでカウントし、
前記対向装置から送信される制御パケットを、受信パケットカウンタで受信して、受信パケット数をカウントし、
前記送信パケット数と前記受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識して外部へ通知することで、前記対向装置の側で障害の監視を認識することなく、自装置側のみで障害検出を行うことを特徴とする障害検出方法。
【０１２４】
（付記８）  装置内の上位レイヤの処理部で障害監視制御パケットの生成、送信を行い、前記送信パケットカウンタは、装置内の前記対向装置と自装置が接続する物理レイヤまたはリンクレイヤの処理部に配置することで、前記送信パケット数の監視により、前記上位レイヤと前記物理レイヤの処理部間の経路に発生する障害検出を保証することを特徴とする付記７記載の障害検出方法。
【０１２５】
（付記９）  前記受信パケットカウンタは、装置内の上位レイヤの処理部に配置することで、前記受信パケット数の監視により、前記対向装置から前記上位レイヤの処理部までの経路に発生する障害検出を保証することを特徴とする付記７記載の障害検出方法。
【０１２６】
（付記１０）  ユーザトラフィックが流れていないときであっても、誤った障害検出がされないように、ユーザトラフィックとは独立な前記障害監視制御パケットを常時一定間隔で送信することを特徴とする付記７記載の障害検出方法。
【０１２７】
（付記１１）  前記対向装置で受信されたときに廃棄され、ペイロードに制御内容を含まない前記障害監視制御パケットを生成し送信することを特徴とする付記１０記載の障害検出方法。
【０１２８】
（付記１２）  自装置と前記対向装置とが、複数リンクを仮想的な１つのリンクとみなすリンク・アグリゲーションで接続している場合には、前記複数リンクの各リンクから前記障害監視制御パケットを送信し、前記送信パケットカウンタは、前記複数リンクのリンク毎に送信パケット数をカウントし、前記受信パケットカウンタは、前記複数リンクの各リンクから前記対向装置から送信された制御パケットを受信して、リンク毎に受信パケット数をカウントすることで、リンク毎に障害検出を行うことを特徴とする付記７記載の障害検出方法。
【図面の簡単な説明】
【０１２９】
【図１】障害検出装置の原理図である。
【図２】障害検出装置のブロック構成を示す図である。
【図３】装置間が１本のリンクで接続された際の障害検出動作を示すシーケンス図である。
【図４】装置間がＬＡで接続された際の障害検出動作を示すシーケンス図である。
【図５】障害検出装置の機能を有する通信装置の構成を示す図である。
【図６】障害監視制御パケットのフォーマットを示す図である。
【図７】ポート状態ステートマシンの状態遷移を示す図である。
【図８】ポート状態ステートマシンの状態遷移を示す図である。
【図９】障害監視ステートマシンの状態遷移を示す図である。
【図１０】障害監視ステートマシンの状態遷移を示す図である。
【図１１】ループによるネットワーク障害を説明するための図である。
【図１２】ループによるネットワーク障害を説明するための図である。
【図１３】ネットワーク障害検出の流れを示す図である。
【符号の説明】
【０１３０】
１０  障害検出装置
１１  障害監視制御パケット送信部
１２  送信パケットカウンタ
１３  受信パケットカウンタ
１４  障害検出部
２０  対向装置
【図１】
2006229477.tif 000003
【図２】
2006229477.tif 000004
【図３】
2006229477.tif 000005
【図４】
2006229477.tif 000006
【図５】
2006229477.tif 000007
【図６】
2006229477.tif 000008
【図７】
2006229477.tif 000009
【図８】
2006229477.tif 000010
【図９】
2006229477.tif 000011
【図１０】
2006229477.tif 000012
【図１１】
2006229477.tif 000013
【図１２】
2006229477.tif 000014
【図１３】
2006229477.tif 000015