JP2007274485A

JP2007274485A - パス警報処理方法及び装置

Info

Publication number: JP2007274485A
Application number: JP2006099208A
Authority: JP
Inventors: Masa Tanaka; 雅田中
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2006-03-31
Filing date: 2006-03-31
Publication date: 2007-10-18
Also published as: US20070230359A1

Abstract

【課題】パス生成時における警報マスク指定を容易に解除することのできるパス警報処理方法及び装置を提供する。
【解決手段】パス設定時に使用するGMPLパスメッセージのAdmin_Statusオブジェクトに、警報マスク指定を行うと共に追加生成したSub-TLVオブジェクトの未使用ビットに警報マスク解除指定を行う。警報監視時に警報発生及びその回復を認識したとき、該警報マスク解除指定を確認して警報マスク解除を行う。上記の警報マスク解除指定は、パス設定後の一定タイマ時間経過後、警報マスク解除を示す所定のメッセージ、及び該所定のメッセージを所定回数受信したこと、の内の少なくともいずれか一つを指定することができる。
【選択図】図１

Description

本発明はパス警報処理方法及び装置に関し、特にGMPLS(Generalized Multi-Protocol Label Switching)を用いてネットワーク内に自動的にパス生成する際に発生するパス警報を処理する方法及び装置に関するものである。

パスを生成する場合、ネットワーク内のパス始点ノードから終点ノードまで全てのパスが生成されるまで、パス生成済ノードにてパス警報が発生する。この為、上位監視装置及び監視ネットワークに過負荷がかかると共に、新規パス生成に伴う警報か否かの判断等、人的コストもかかるという問題がある。

この問題を解決する為、勧告（RFC3473）により、従来ではパス生成時に人為的にパス生成区間に対して、警報マスク処理を施す等の事前作業を行っていた。

図9は、上記勧告（RFC3473）に基づき、GMPLSを用いてパス区間の始点ノード（Ingress：イングレス）N1〜終点ノード（Egress：イーグレス）N4間のパス生成（シグナリング）及び警報マスク処理の過程を例示したシーケンスを示す。

まず、ノードN1は、隣接する中間ノードN2に対してノードN1〜N4間の経路情報（Explicit_Route Object: ERO）やノードN1〜N2間で使用したいパス番号（TDM: Time Slot WDM:波長多重）を指定したパスメッセージPathMsg（図10(1)を参照。）を監視回線（図示せず）を利用して送信する。

ノードN2では、受信したパスメッセージPathMsgによって指定されたパス番号が有効(未使用)である場合には、該当するパス番号を予約状態とし、同様のパスメッセージPathMsgを次の中間ノードN3へ転送する。ノードN3もノードN2と同様の処理を行って終点ノードN4へパスメッセージPathMsgを転送する。

このように、転送されるパスメッセージPathMsg中には、同図(1)に示すように、“Admin_Status”オブジェクト（フィールド）が付与されており、上記勧告（RFC3473）では、この“Admin_Status”オブジェクトによってA-ビット指定（Admin Down指定）及びT-ビット指定（Test Mode）を行い、図9に示すように、パスメッセージPathMsg受信時に各ノードN1〜N4において警報マスク処理を実行することを規定している。

この後、ノードN4では、受信したパスメッセージPathMsgが有効である場合には、“OK”を示す応答であるリザーブメッセージResvMsg（同図(2)参照。）をやはり監視回線を経由して送信すると共に、自分自身に対してパス設定（クロスコネクト設定）を実施する。

ノードN4からのリザーブメッセージResvMsgを受信したノードN3では、ノードN2へリザーブメッセージResvMsgを送信すると共に自分自身に対して上記と同様にパス設定を実行する。ノードN2及びノードN1についても同様の処理が実行され、ノードN1〜ノードN4間のパス設定が完了する。なお、ノードN1ではリザーブメッセージResvMsgの送信は行わない。

なお、図10(1)に示すパスメッセージPathMsgの内容はおおむね次の通りである。

SESSION, SENDER_TEMPLATE：コネクションの識別情報を格納する領域（オブジェクト）で、5つの情報（イングレスアドレス、イーグレスアドレス、トンネルID、LSPID、拡張トンネルID）を組み合わせることでユニークに識別できるようにしている。

RSVP_HOP：利用するファイバーの識別情報として、パスメッセージPathMsgの送信側ノードのローカルIDが格納される。

TIME_VALUES：パスリフレッシュ間隔（リフレッシュタイマーの長さ）が格納される領域で、受信側はこの値を基にしてPTTDを決定する。一般には20〜30秒の値が格納される。

EXPLICIT_ROUTE：コネクションが経由されて行くべき経路情報が格納される領域。

LABEL_REQUEST：要求するラベルのタイプが格納される領域で、コネクションがどのようなものか（SDH/SONET,Ethernet（登録商標）, Lambda）を示す。

PROTECTION：コネクションが要求するプロテクションの種類などが格納される領域で、セグメントプロテクションにも関係する。

SESSION_ATTRIBUTE：コネクションの名前などが格納される領域で、中継ノードでコネクションをRTRVする際に名前を用いてコネクションを特定できるなどに使用できる。

ADMIN_STATUS：Admin_DownやDeletionなどの特殊な情報が格納される領域。

SENDER_TSPEC：コネクションが要求するレート情報（2.5G又は10Gなど）が入る領域で、SONETの場合はSTS1/STS3c/コンカチネーションの有無などを示す。

UPSTREAM_LABEL：予約したラベル情報（波長を識別する情報）を格納する領域。

また、同図(2)に示すリザーブメッセージResvMsgの内容はおおむね次の通りである。

RESV_CONFIRM：ResvConfMsgの送信を要求する場合にその情報を格納する領域。

FLOWSPEC：パスメッセージPathMsgのSENDER_TEMPLATEと同じコネクションの識別情報を格納する領域。

FILTERSPEC：パスメッセージPathMsgのSENDER_TSPECと同じに要求するレート情報を格納する領域。

LABEL：パスメッセージPathMsgのUPSTREAM_LABELと同じラベル情報を格納する領域。

上記のようなパス設定及び警報マスク処理を行うノードN1〜ノードN4の共通の構成例が図11に示されている。

各ノードは、概略的には、装置制御ユニット1と、通信制御ユニット2と、装置制御ユニット1に接続された監視装置3と、装置制御ユニット1に接続され光−電気信号変換及び交換動作を行うインタフェース・クロスコネクトユニット4と、通信制御ユニット2とインタフェース・クロスコネクトユニット4との間に接続されたSDH/SONETオーバーヘッド終端ユニット5とで構成されている。

この内、装置制御ユニット1は光主信号を処理し、通信制御ユニット2は監視回線を流れるパスメッセージPathMsg及びリザーブメッセージResvMsgを処理するものである。また、装置制御ユニット1は監視装置3に接続されたユーザインタフェース11と、このユーザインタフェース11と相互接続されたコマンド処理部12と、インタフェース・クロスコネクトユニット4に対して接続された装置制御部13及び警報制御部14と、パス設定の情報を記憶したデータベース15と、コマンド処理部12及び警報制御部14と相互接続されたCPU間通信制御部16とで構成されている。なお、装置制御部13及び警報制御部14の間並びにコマンド処理部12及び警報制御部14の間も相互接続されている。

また通信制御ユニット2は、装置制御ユニット1のCPU間通信制御部16と相互接続されたCPU間通信制御部21と、このCPU間通信制御部21に接続されたGMPLS制御部22と、このGMPLS制御部22に接続された通信制御部23と、この通信制御部23とオーバーヘッド終端ユニット5との間に接続されてデータ通信チャネル（DCC: Data Communication Channel）を制御するためのデータ通信チャネル制御部24とで構成されている。

このような構成の各ノードにおける図9に示したパス設定処理及び警報マスク処理の動作例を、始点ノードN1と、中間ノードN2又はN3と、終点ノードN4に分けて以下に説明する。

・始点ノードの動作例：図12
まず、ユーザにより、監視装置3から装置制御ユニット1のユーザインタフェース11に対してパス設定コマンドが投入される（ステップS1）。この場合、このパス設定コマンドには、図10(1)に示した“Admin_Status”オブジェクトに設定される警報マスク指定が含まれている。

このパス設定コマンドは、ユーザインタフェース11からコマンド処理部12に送られて一時的に保持されると共に、コマンド処理部12から警報制御部14に対して警報マスクの実行依頼を行う（ステップS2）。この警報マスク実行依頼を受けた警報制御部14は警報マスクを実行する（ステップS3）。

次に、コマンド処理部12は、CPU間通信制御部16及び通信制御ユニット2のCPU間通信制御部21を経由してGMPLS制御部22に対し、パスメッセージPathMsgの送信依頼を行う（ステップS4）。これを受けてGMPLS制御部22は、このパスメッセージPathMsgを、通信制御部23を介してデータ通信チャネル制御部24からオーバーヘッド終端ユニット5へ送り出し、さらにオーバーヘッド終端ユニット5からインタフェース・クロスコネクトユニット4を経て隣接するノードN2へ送り出す（ステップS5）。

この場合、GMPLSプロトコルにおけるシーケンスは、主信号を送るデータ回線中のオーバーヘッドの一部を用いて行われる高速通信であるDCC通信（IP over DCC）又はLAN経由で行われ、通常のIPプロトコルのパケットによって行われる。すなわち、IPパケットのペイロード部分にGMPLS用データが乗り、各ノード間でGMPLSデータのやり取りが行われるが、パス設定用の監視データに関しては、主信号のオーバーヘッド（DCC）を用いた監視回線によって実行される。すなわち、DCC/LAN共に通常ネットワークを構成する各ノードの監視用回線として用いられる。

このようにしてノードN1から送信されたパスメッセージPathMsgに応答して、上述のように終点ノードN4からリザーブメッセージResvMsgが、パスメッセージPathMsgと同様に、DCC/LAN経由で送られて来るので、ノードN1は、隣接するノードN2からこのリザーブメッセージResvMsgを受信する（ステップS6）。そして、このリザーブメッセージResvMsgをインタフェース・クロスコネクトユニット4、オーバーヘッド終端ユニット5、データ通信チャネル制御部24、及び通信制御部23を経由して受信したGMPLS制御部22は、CPU間通信制御部21及び16を介してコマンド処理部12へパス設定制御依頼を行う（ステップS7）。

これを受けてコマンド処理部12は、装置制御部13に対してパス設定制御依頼を行う（ステップS8）。これを受けて装置制御部13は、データベース15の情報に基づき、インタフェース・クロスコネクトユニット4に対してパス設定を実行すると共に警報制御部14に対して警報監視開始依頼を行う（ステップS9）。

なお、この時点では、始点ノードN1〜終点ノードN4間においてパス設定はまだ実質的に完了していない（ステップT1）。

次に、警報制御部14は、インタフェース・クロスコネクトユニット4にパス警報監視を開始させる（ステップS10）。これは、光レベルが正常であるか、主信号中のペイロードデータが無いか（UNEQ）、あるいはAIS信号が挿入されているか（AIS）によって判断する（ステップS11）。

このステップS11での判断の結果、インタフェース・クロスコネクトユニット4から警報制御部14に対して状態通知（警報通知）がなされる（ステップS12）。これを受けて警報制御部14では、警報（UNEQ/AIS/etc）の発生を認識する（ステップS13）。しかしながら、警報制御部14は、警報が発生しても、現在、ステップS3で実行された警報マスク処理中であることから、警報装置3への警報通知を行わない（ステップS14）。

なお、この時点では、始点ノードN1〜終点ノードN4間の全ノードにおいてパス設定が完了していることになる（ステップT2）。

この後、インタフェース・クロスコネクトユニット4から警報制御部14に対して状態変化（警報の回復）が通知される（ステップS15）と、警報制御部14では警報状態が回復したと認識する（ステップS16）。但し、警報制御部14は、やはり現在は警報マスク実行中であることから、監視装置3への警報回復通知を行わない（ステップS17）。

この結果、警報マスク状態が継続することとなる（ステップT3）。

・中間ノードの動作例：図13
この中間ノードの動作例は、図12に示した始点ノードの動作例に対して、ステップS21〜S24が加えられていると共に、ステップS1,S2, S4が除かれている点が異なっている。

すなわち、例えば中間ノードとしてのノードN2を例に取ると、まず監視回線（LAN又はDCC）を通じてパスメッセージPathMsgを受信する（ステップS21）。このパスメッセージPathMsgは、インタフェース・クロスコネクトユニット4、オーバーヘッド終端ユニット5、データ通信チャネル制御部24、及び通信制御部23を経由してGMPLS制御部22で受信される。この受信したパスメッセージPathMsgにおいては、“Admin_Status”オブジェクト中で警報マスクが指定されている。

これを受けてGMPLS制御部22は、CPU間通信制御部21及び16を経由して装置制御ユニット1における警報制御部14に対して警報マスクの実行を依頼する（ステップS22）。

これにより、警報制御部14において警報マスクが実行され（ステップS3）、且つ警報マスクの完了をGMPLS制御部22へ通知する（ステップS23）。

この後、図12の動作例と同様に、ステップS5〜S9が実行されてパスメッセージPathMsgの送信及びリザーブメッセージResvMsgの受信が行われ、警報制御部14がインタフェース・クロスコネクトユニット4に対して警報監視を開始することになる。

そして、GMPLS制御部22は、隣接するノードN1に対してリザーブメッセージResvMsgを送信し（ステップS24）、警報監視を開始することになる（ステップS10）。

この後、ステップS10からS17までは図12に示した始点ノードの動作例と同様である。

したがって、ステップS17において監視装置3への警報回復通が抑止されるため、警報マスク状態が継続されることとなる（ステップT3）。

・終点ノードの動作例：図14
この終点ノードの動作例は、図13に示した中間ノードの動作例において、ステップS5及びS6が省かれている点が異なっている。

すなわち、隣接するノードに対してパスメッセージPathMsgを送信したり、隣接するノードからリザーブメッセージResvMsgを受信したりするステップが省かれているだけであり、その他のステップは中間ノードと同様である。したがって、ステップS17においてやはり監視装置3への警報回復通知は抑止され、以て警報マスク状態が継続されることとなる（ステップT3）。

一方、ノード装置間に伝送路を設定し該伝送路を介して情報の送受信を行う複数の情報転送ノードと、各情報転送ノードによって実現されるネットワークの状況を監視した結果に応じて各情報転送ノードに伝送路の再設定指示を送るサービス品質制御ノードとを設け、監視結果に応じて複数の情報転送ノード装置に伝送路の再設定指示を行うことにより、動的かつ柔軟に構成する伝送路を用いて、サービス品質を満足できる制御を行うことができるシステムがある（例えば、特許文献1参照。）。
特開2004-247943号公報

上記のように、GMPLSを用いてパス生成時のメッセージ(PathMsg)中に含まれるオブジェクト(Admin_Status Object)を用いて警報マスクすることが勧告(RFC3473)に規定されているが、警報マスク状態が継続してしまい、解除のみ人為的に各ノードに対して実施しなければならないという課題があった。

従って本発明は、パス生成時における警報マスク指定を容易かつ迅速に解除することのできるパス警報処理方法及び装置を提供することを目的とする。

上記の目的を達成するため本発明に係るパス警報処理方法（又は装置）においては、パス設定時に、警報マスク指定と共に警報マスク解除指定を行う第1ステップ（又は手段）と、警報監視時に、発生した警報の回復を認識したとき、該警報マスク解除指定に基づいて該警報マスクの解除を行う第2ステップ（又は手段）と、を備えたことを特徴としている。

すなわち、本発明においては、従来と同様にパス設定時に警報マスク指定を行うが、これと同時に警報マスク解除指定も行っておく。そして、警報監視を行っている際に、警報の発生を認識し且つその回復を認識した場合、該警報マスク解除指定を確認する。この結果、警報マスク解除指定がなされていることが分かった時には、これをトリガとして警報マスク解除を行う。

この場合のパス設定は、GMPLSによるパス設定を用いることができる。

なお、始点ノード等においては、警報マスク指定及び警報マスク解除指定をパス設定コマンドの投入時に行えばよく、中間又は終点ノード等では、警報マスク指定及び警報マスク解除指定を、パス設定時に受信するパスメッセージの所定領域に格納されているか否かを確認すればよい。

また、上記の所定領域は、例えば図1に示すように、パスメッセージPathMsgにおけるAdmin_Status領域（オブジェクト）であり、該警報マスク解除指定に対しては、該Admin_Status領域におけるSub-TLV領域の未使用ビットを割り当てることができる。

そして、上記の警報マスク解除指定としては、該Sub-TLV領域の未使用ビットを用いて、該パス設定後の一定時間経過後（タイマ方式）、警報マスク解除を示す所定のメッセージ（メッセージ方式）、及び該所定のメッセージの所定回数の受信（メッセージ受信回数方式）、の内の少なくともいずれか一つを指定することができる。

以上のように本発明によれば、警報マスクに対する解除トリガを予め設定しておくことにより、警報回復時に警報マスク解除が自動的に実施され、迅速且つ正確な警報マスクの解除が実現される。

以下、本発明に係るパス警報処理方法及び装置が実現されているノードを、従来例と同様に、始点ノードと中間ノードと終点ノードに分けて図面を参照して説明する。なお、この動作実施例においても、図9に示したシステム構成を例にとって説明するが、各ノードの構成例は、図11に示した従来から用いられているノードの構成例と同様である。

◎始点ノードの動作実施例：図2〜図6
本発明の始点ノードN1の動作例は、図12に示した従来例の始点ノードの動作例に対して、ステップS3の代わりにステップS31のサブルーチンが用いられ、更にステップS17の後にステップS32〜S34が用いられている点が異なっている。

すなわち、ステップS31においては、警報制御部14が警報マスク処理を実行する際、Sub-TLV生成処理も併せて実行する。そして、パスメッセージPathMsgの送信手順へ進む。

・Sub-TLV生成処理：図3
ここで、図3によりSub-TLV生成処理フローを説明する。

まず、警報制御部14が警報マスク処理を実行するとき（ステップS100）、図1に示したパスメッセージPathMsgにおける“Admin_Status”オブジェクトの中のSub-TLV領域（オブジェクト）に対して設定されるべきIビット指定が行われているか否かを判定する（ステップS101）。

なお、このIビット指定は、上記のステップS1において、“Admin_Status”オブジェクトを使った警報マスク指定を行うときに監視装置3からユーザにより設定されるもので、この設定は、例えばコマンド処理部12に一時格納されており、これを参照してステップS101を実行する。

ステップS101の判定の結果、Iビット指定が行われていることが分かった場合には、“Admin_Status”のIビットフラグをONにセットし、Sub-TLVのタイマ値格納領域を設定して指定タイマ値を格納する（ステップS102）。

ここで、パスメッセージPathMsgにおける“Admin_Status”オブジェクト、及びこれに追加されたSub-TLV（オブジェクト）について説明する。

まず、図4(1)は、図1に示した“Admin_Status”オブジェクトの従来から用いられているフォーマットを示しており、これはRFC3471（RFC3473）によって規定されているそのものである。この内のヘッダー部分HDは本発明も同様にして使用されるが、ペイロード部分PLは、“Reflect”ビットR（1ビット）と、“Reserved”ビット（28ビット）と、“Testing”ビットT（1ビット）と、“Administratively down”ビットA（1ビット）と、“Deletion in progress”ビットD（1ビット）とを含んでいる。この内、“Reserved”ビットは未使用ビットとして上記のRFC3471（RFC3473）においては定義されていないユーザオプション領域である。

そこで、本発明では、同図(2)に示すように“Reserved”ビットの内の一部分を下記の通り利用する。なお、“R”,“T”,“A”,“D”ビットは従来と同様に使用される。

(1)“Inhibit Alarm”ビットI（1ビット）：このビットが指定(セット)されるときには、リザーブメッセージResvMsg受信後、後述するSub-TLVで指定された時間経過を条件に警報マスクを解除する。

(2)“Message”ビットM（1ビット）：このビットが指定されるときには、Sub-TLVで指定された所定のメッセージを受信したことを条件に警報マスクを解除する。

(3)“Over retry time”ビットO（1ビット）：このビット指定時には、Sub-TLVで指定された所定のメッセージを、やはりSub-TLVで指定された回数だけ受信したことを条件に警報マスクを解除する。

(4)“Select”ビットS（1ビット）：このビットが指定されるときには、上記の“I”,“M”,“O”ビット中の内の少なくともいずれか1つが設定されていることを条件に警報マスクを解除する。

ここで、上記の各追加ビット(1)〜(4)に対応するSub-TLV構造について、図5を参照して以下に説明する。

(1)タイマによる自動解除：Iビット
図4(2)に示した新“Admin_Status”オブジェクトにおいてIビットが指定された場合には、指定タイマ時間を定義したSub-TLV（オブジェクト）を“Admin_Status”オブジェクトに追加して生成し、これに基づき、リザーブメッセージResvMsg受信後又はパス設定後から指定タイマ時間経過した後、警報マスク解除動作を行う。

この場合に追加するSub-TLV構造は、図5(1)に示すフォーマットを有しており、そのヘッダ部分HDにおいて、新たにClass-numとして“250”を定義する。また、ペイロード部分PLにおいては、“Timer Value”領域で解除タイマ時間を指定する。指定範囲は、“0〜0xFFFFFFFF(msec)”で、0は無限大(解除無し)を示す。

(2)指定メッセージによる解除：Mビット
“Admin_Status”オブジェクトにおいてMビットフラグが設定された場合には、メッセージ種別を定義したSub-TLVを生成し、リザーブメッセージResvMsg受信後又はパス設定後に指定メッセージを受信したことを条件に、警報マスク解除を行う。

この場合に追加するlang=EN-US>Sub-TLV構造は、同図(2)に示すフォーマットを有しており、そのヘッダ部分HDにおいて、新たにClass-numとして“251”を定義する。また、ペイロード部分PLにおいては、“Message Type”でメッセージ種別（ResvConf/Path Msg/RSVP Hello/etc：RFC3471にて定義）を指定し、“Version”には“Source ID”の種別(IPv4 or IPv6)の識別情報を指定し、“Source ID”には、送信元IP Address を指定する。

(3)指定メッセージの指定回数受信による解除：Oビット
“Admin_Status”オブジェクトにおいてOビットフラグが設定された場合には、メッセージ種別及び回数を定義したSub-TLVを生成し、リザーブメッセージResvMsg受信後又はパス設定後に指定メッセージを指定回数受信したことを条件に、警報マスク解除を行う。

この場合に追加するSub-TLV構造は、同図(3)に示すフォーマットを有しており、そのヘッダ部分HDにおいて、新たにClass-numとして“251”を定義する。また、ペイロード部分PLにおいては、上記(2)の指定メッセージによる解除に用いられる“Message Type”と“Version”と“Source ID”に加えて、“Retry Value”領域を設けて受信回数を指定する。

(4)複数条件による解除：Sビット
“Admin_Status”オブジェクトにおいてSビットフラグが設定された場合には、上記(1)〜(3)の解除条件の内のいずれか少なくとも1つを満たした時に警報マスクを解除する。

図3に戻って、Iビット指定があるときには、図5(1)に示したタイマ値格納領域“Timer Value”を生成してタイマ値を格納し（ステップS102）、ノードN1内の例えばコマンド処理部12等の内部メモリ領域にIビットフラグをONに設定し、タイマ値を格納することによってバックアップを行っておく（ステップS103）。

次に、Mビット指定があるか否かを判定する（ステップS104）。この結果、Mビット指定が指定されているときには、“Admin_Status”のMビットフラグをONにセットし、図5(2)に示すようにSub-TLVとしてメッセージID格納領域“Message Type”,“Version”,及び“Source ID”を生成し、ここにメッセージID（Msg ID）を格納する（ステップS105）。そして、ノード内のメモリ領域にMビットフラグ及びメッセージIDをバックアップしておく（ステップS106）。

次に、Oビット指定が有るか否かを判定する（ステップS107）。この結果、Oビット指定が有る場合には、“Admin_Status”のOビットフラグをONにセットし、図5(3)に示すようにSub-TLVとしてメッセージID及びリトライ回数を格納する領域“MessageType”,“Version”,及び“Source ID”並びに“Retry Value”を生成し、メッセージIDとリトライ回数を格納する（ステップS108）。そして、内部メモリ領域においてOビットフラグ及びメッセージID並びにリトライ回数をバックアップする（ステップS109）。

更に次にSビット指定があるか否かを判定する（ステップS110）。このSビット指定がある場合には、上記のIビット、Mビット、又はOビットの警報マスク解除方法の内の少なくともいずれか一つを満たした時に警報マスクを解除するものである。このため、Sビットフラグを内部メモリ領域にバックアップする（ステップS111）。

このようにして“Admin_Status”オブジェクト及び追加Sub-TLVオブジェクトを生成し（ステップS112）、上記のように設定したI/M/O/SビットのフラグがONになっているか否かを判定し（ステップS113）、一つでもONになっていれば、“Admin_Status”オブジェクトにSub-TLVオブジェクトを追加する（ステップS114）。そして、警報マスク完了を警報制御部14からGMPLS制御部22へ通知する（ステップS115）。

このようにして、図2のステップS31においてSub-TLV生成処理が実行され、ステップS4〜ステップS17が従来の始点ノードと同様に実行される。

この結果、ステップS17においては、警報マスク実行中であるので、監視装置3への警報回復通知は抑止されているが、次にステップS32に進み、I/M/Oビットの指定があるか否かを判定する。この結果、いずれのビット指定も無い場合にはパス生成の処理が完了するが（ステップS33）、いずれかのビット指定がある場合には警報マスク解除処理を実行する（ステップS34）。

・警報マスク解除処理：図6
図6にはこの警報マスク解除フローが示されている。

まず、この警報マスク解除フローはGMPLSパケットを受信するか又は一定の周期（1秒タイマ）毎にタイムアップして実行される（ステップS200）。

まず警報マスク中であるか否かがチェックされる（ステップS201）。この結果、ステップS17で既に警報マスクが実行中であるので、周期処理タイムアップ処理に移行すべきか否かを判定する（ステップS202）。これは、この警報マスク解除フローが例えば1秒タイマによる周期処理が行われるためである。

この後、Iビット指定フラグがONになっているか否かを、図3のステップS101でバックアップ内部メモリ領域を参照して判定する（ステップS203）。この結果、Iビット指定フラグがOFFである場合にはステップS207に進むが、ONに設定されている場合には、図3のステップS103で内部メモリ領域にバックアップされているタイマ値を“1”だけ減算する（ステップS204）。この結果、タイマ値“0”、すなわちタイムアップしたか否かを判定し（ステップS205）、タイマ値“0”であるときのみIビット指定フラグをOFFにする（ステップS206）。

次に、Mビット指定フラグがONであるか否かを、バックアップメモリから判定する（ステップS207）。この結果、Mビット指定フラグがONに設定されている場合には、受信パケットに設定されているメッセージIDとステップS106でバックアップされているメッセージIDとが一致するか否かを判定する（ステップS208）。この結果、両者が一致している場合のみ、Mビット指定フラグをOFFにする（ステップS209）。

更に次にOビット指定フラグがONになっているか否かを、バックアップメモリから判定し（ステップS210）、Oビット指定フラグがONになっているときには、受信パケットに設定されているメッセージがステップS109でバックアップされているメッセージIDと一致するか否かを判定する（ステップS211）。そして、両者のメッセージIDが一致した場合、そのバックアップされた指定回数が“1”であるか否かを判定する（ステップS212）。

この結果、バックアップされた指定回数が“1”でない場合にはステップS111でバックアップした指定回数を“1”だけ減算して（ステップS213）、ステップS215に進むが、そうでない場合にはOビット指定フラグをOFFにする（ステップS214）。

そして最後にSビット指定フラグがONに設定されているか否かを判定する（ステップS215）。

この結果、Sビット指定フラグがONに設定されていないときには、I/M/Oビット指定フラグのいずれかにONからOFFに変化した形跡があるか否かを判定する（ステップS216）。この結果、ONからOFFへの変化があったことが分かった場合には、I/M/Oビット指定フラグの全てをOFFにする（ステップS217）。

一方、Sビット指定フラグがONの場合には、I/M/Oビット指定フラグが全てがOFFであるか否かを判定し（ステップS218）、全てがOFFの場合にはステップS217と同様に警報マスクを解除する（ステップS219）。すなわち、Sビット指定フラグがONの場合には、I/M/Oビット指定フラグのいずれか1つがONであれば警報マスク解除を行うことになる。

この後、通常処理に移行する（ステップS220）。ステップS216及びS218において、“NO”であった場合も同様にステップS220に進んで通常処理に移る。

◎中間ノードの動作実施例：図7, 図3〜図6
この動作実施例は、図13に示した従来例の動作例においてステップS3をステップS31に置き換え、ステップS17の後にステップS32〜S34を設けた点が異なっている。

すなわち、本発明の中間ノードにおいても、図2に示した始点ノードの動作例と同様にステップS31により警報マスク処理とSub-TLV生成処理を実行し、そしてステップS17において警報回復通知を抑止した後、I/M/Oビットの指定があるか否かによって図6に示した警報マスク解除処理を実行するものである。

なお、この中間ノードにおいても、上述した図3〜図6の実施例を用いればよい。

◎終点ノードの動作実施例：図8, 図3〜図6
この終点ノードの動作実施例は、図14に示した従来例と比較すると、ステップS3がステップS31に置き換えられ、ステップS17などにステップS32〜ステップS34を追加した点が異なっている。

すなわち、この終点ノードの場合も上記の中間ノードと同様に警報マスク処理の実行と共にSub-TLV生成処理を行っておき、警報回復通知が抑制された後でもI/M/Oビットの始点がある場合には図6に基づく警報マスク解除処理を実行するものである。

なお、この終点ノードにおいても、上述した図3〜図6の実施例を用いればよい。

なお、本発明は、上記実施例によって限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。

（付記１）
パス設定時に、警報マスク指定と共に警報マスク解除指定を行う第1ステップと、
警報監視時に、発生した警報の回復を認識したとき、該警報マスク解除指定に基づいて該警報マスクの解除を行う第2ステップと、
を備えたことを特徴とするパス警報処理方法。
（付記２）付記１において、
該パス設定が、GMPLSによるパス設定であることを特徴としたパス警報処理方法。
（付記３）付記１において、
該警報マスク指定及び警報マスク解除指定が、パス設定コマンド投入時に行われることを特徴としたパス警報処理方法。
（付記４）付記１において、
該警報マスク指定及び警報マスク解除指定が、パス設定時に受信するパスメッセージの所定領域に格納されていることを特徴としたパス警報処理方法。
（付記５）付記４において、
該所定領域が、該パスメッセージにおけるAdmin_Status領域であり、該警報マスク解除指定に対しては、該Admin_Status領域におけるSub-TLV領域の未使用ビットが割り当てられることを特徴としたパス警報処理方法。
（付記６）付記５において、
該警報マスク解除指定が、該未使用ビットを用いて、該パス設定後に経過した一定時間、該警報マスク解除を示す所定のメッセージ、及び該所定のメッセージの所定繰り返し回数の内の少なくともいずれか一つを条件としたことを特徴としたパス警報処理方法。
（付記７）
パス設定時に、警報マスク指定と共に警報マスク解除指定を行う第1手段と、
警報監視時に、発生した警報の回復を認識したとき、該警報マスク解除指定に基づいて該警報マスクの解除を行う第2手段と、
を備えたことを特徴とするパス警報処理装置。
（付記８）付記７において、
該パス設定が、GMPLSによるパス設定であることを特徴としたパス警報処理装置。
（付記９）付記７において、
該警報マスク指定及び警報マスク解除指定が、パス設定コマンド投入時に行われることを特徴としたパス警報処理装置。
（付記１０）付記７において、
該警報マスク指定及び警報マスク解除指定が、パス設定時に受信するパスメッセージの所定領域に格納されていることを特徴としたパス警報処理装置。
（付記１１）付記１０において、
該所定領域が、該パスメッセージにおけるAdmin_Status領域であり、該警報マスク解除指定に対しては、該Admin_Status領域におけるSub-TLV領域の未使用ビットが割り当てられることを特徴としたパス警報処理装置。
（付記１２）付記１１において、
該警報マスク解除指定が、該未使用ビットを用いて、該パス設定後に経過した一定時間、該警報マスク解除を示す所定のメッセージ、及び該所定のメッセージの所定繰り返し回数の内の少なくともいずれか一つを条件としたことを特徴としたパス警報処理装置。

本発明に係るパス警報処理方法及び装置の実施例で用いられるGMPLSのパスメッセージの一例を示したフォーマット図である。本発明に係るパス警報処理方法及び装置を実現するノードが始点において動作するときの実施例を示したフローチャート図である。本発明に用いられる各ノードにおいて共通に用いられるSub-TLV生成処理を示したフローチャート図である。従来から知られているGMPLSのパスメッセージ中のAdmin_Statusオブジェクトの旧フォーマットと新フォーマットを示した図である。本発明によって追加されたSub-TLVオブジェクトの構造を示したフォーマット図である。本発明によって各ノードに共通に用いられる警報マスク解除処理を示したフローチャート図である。本発明における中間ノードの動作実施例を示したフローチャート図である。本発明における終点ノードの動作実施例を示したフローチャート図である GMPLSによる双方向パスの生成シーケンスを示した図である。従来から知られているGMPLSで用いられるパスメッセージ及びリザーブメッセージのフォーマット図である。本発明及び従来例に共通の各ノードの構成例を示したブロック図である。従来例における始点ノードの動作例を示したフローチャート図である。従来例の中間ノードの動作例を示したフローチャート図である。従来例の終点ノードの動作例を示したフローチャート図である。

符号の説明

1 装置制御ユニット
2 通信制御ユニット
3 監視装置
4 インタフェース・クロスコネクトユニット
5 SDH/SONETオーバーヘッド終端ユニット
11 ユーザインタフェース
12 コマンド処理部
13 装置制御部
14 警報制御部
15 データベース
16, 21 CPU間通信制御部
22 GMPLS制御部
23 通信制御部
24 データ通信チャネル制御部
図中、同一符号は同一又は相当部分を示す。

Claims

パス設定時に、警報マスク指定と共に警報マスク解除指定を行う第1ステップと、
警報監視時に、発生した警報の回復を認識したとき、該警報マスク解除指定に基づいて該警報マスクの解除を行う第2ステップと、
を備えたことを特徴とするパス警報処理方法。
請求項１において、
該パス設定が、GMPLSによるパス設定であることを特徴としたパス警報処理方法。
請求項１において、
該警報マスク指定及び警報マスク解除指定が、パス設定コマンド投入時に行われることを特徴としたパス警報処理方法。
パス設定時に、警報マスク指定と共に警報マスク解除指定を行う第1手段と、
警報監視時に、発生した警報の回復を認識したとき、該警報マスク解除指定に基づいて該警報マスクの解除を行う第2手段と、
を備えたことを特徴とするパス警報処理装置。
請求項４において、
該パス設定が、GMPLSによるパス設定であることを特徴としたパス警報処理装置。