JP3967954B2 - 光クロスコネクト網の障害回復方法 - Google Patents
光クロスコネクト網の障害回復方法 Download PDFInfo
- Publication number
- JP3967954B2 JP3967954B2 JP2002125711A JP2002125711A JP3967954B2 JP 3967954 B2 JP3967954 B2 JP 3967954B2 JP 2002125711 A JP2002125711 A JP 2002125711A JP 2002125711 A JP2002125711 A JP 2002125711A JP 3967954 B2 JP3967954 B2 JP 3967954B2
- Authority
- JP
- Japan
- Prior art keywords
- path
- optical
- oxc
- gmpls
- failure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Optical Communication System (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、光クロスコネクト網の障害回復方法に係り、ＧＭＰＬＳにより光クロスコネクトのスイッチングをおこなう光クロスコネクト網で、光スイッチ部のみで高速に障害回復のおこなうことのできる光クロスコネクト網の障害回復方法に関する。
【０００２】
【従来の技術】
近年、インターネットの急速な普及などにより、大容量のバックボーンの通信手段として、光通信技術に関心が集まっている。このような光通信のプロトコルを規定する技術として、ＧＭＰＬＳ（Generalized Multi Protocol Label Switching）がある。ＧＭＰＬＳは、従来のＭＰＬＳのラベルをＷＤＭ（Wavelength Division Multiplexing：波長分割多重）の波長に適用したもので、ルータと光クロスコネクトの連携により波長単位の経路制御が可能になり、光クロスコネクトにＧＭＰＬＳを実装したスイッチングルータを使うと、光信号のままでスイッチングできると同時に、経路選択の決定は、ＩＰ技術で実現できるようになる。
【０００３】
ところで、フォトニックネットワークのリカバリー（プロテクション／リストレーション）としては、ＩＥＴＦ（Internet Engineering Task Force）で議論されているＧＭＰＬＳ主体のリカバリー方式と、ＩＴＵ−Ｔ（International Telecommunication Union-Telecommunication Sector）で議論されている物理層主体のリカバリー方式の２つがある。
【０００４】
ＧＭＰＬＳを使って光パスの制御をおこなう場合、ネットワークの階層構成としては、主信号が流れるデータプレーン（物理層）と、ＧＭＰＬＳの制御信号が流れるコントロールプレーン（制御層）は分離された２階層になる。この階層にしたがって、ＧＭＰＬＳ制御部は、物理層に属する光スイッチ部から障害通知してもらい、光スイッチ部に対しパス切替えを要求することで、光パスのリカバリーを実現することとなる。このリカバリーの種類としては、ＩＥＴＦドラフト（Generalized MPLS Recovery Mechanisms :draft-lang-ccamp-recovery-oo.txt）記載のように、１：１スパンプロテクション、Ｍ：Ｎパスプロテクション、パスリストレーション等、多様なリカバリー方式が検討されている。
【０００５】
物理層主体のリカバリーについては、ＩＴＵ−ＴのＡＳＴＮ（Automatic Switching Transport Network）のＧ．８７１（Framework for optical transport network recommendations）にて議論されはじめたところである。
【０００６】
【発明が解決しようとする課題】
上記のＧＭＰＬＳ主体のリカバリー方式では、ＧＭＰＬＳ自体にリンク障害検知のメカニズムを持たないため、障害が発生してからバックアップパスに切替えるまでに時間がかかってしまうという問題点があった。
【０００７】
また、上記の物理層主体のリカバリーは、現時点、ポイントｔｏポイント、あるいは、リング形態でのみ実現可能であり、メッシュ形態での切替え技術は確立されていない。例えば、ＳＤＨ（Synchronous Digital Hierarchy）伝送の ＡＰＳ（Automatic Protection Switch）バイトを用いたポイントｔｏポイント、リング形態での高速切替えは既存技術であるが、メッシュ形態において、障害時に迂回ルートへ切替える等のリカバリー技術は確立されていない。
【０００８】
本発明は、上記問題点を解決するためになされもので、その目的は、ＧＭＰＬＳにより光パスの制御をおこなう光クロスコネクト網で、光スイッチ部のみで高速に障害回復をおこなえるようにするとともに、光スイッチ部のみで障害回復がおこなえないときには、ＧＭＰＬＳ制御部の制御により障害の回復をおこなうようにして、多様な光クロスコネクト網の接続形態に対応できる光クロスコネクト網の障害回復方法を提供することにある。
【０００９】
【課題を解決するための手段】
上記問題点を解決するために、本発明では、ＧＭＰＬＳにより光パスの制御をおこない、光クロスコネクトにＧＭＰＬＳ制御部と光スイッチ部とを有する光クロスコネクト網の障害回復方法において、光パスの通信に障害が起こった際に、光スイッチ部によりバックアップパスを確保することが可能なときには、光スイッチ部は、障害情報、切替え情報をＧＭＰＬＳ制御部に通知し、ＧＭＰＬＳ制御部は、前記光スイッチ部からの障害情報、切替え情報を基にして、ラベル情報、パス管理情報を更新し、障害が起こった光パスの通信を、前記バックアップパスによりすることによって障害回復をおこなうようにする。
【００１０】
また、光スイッチ部によりバックアップパスを確保することが不可能なときには、光スイッチ部は、障害情報をＧＭＰＬＳ制御部に通知し、ＧＭＰＬＳ制御部は、光スイッチ部からの障害情報を基にして、ラベル情報、パス管理情報を更新し、バックアップパスを確保して、障害が起こった光パスの通信を、前記バックアップパスによりすることによって障害回復をおこなうようにする。
【００１１】
【発明の実施の形態】
以下、本発明に係る各実施形態を、図１ないし図２１を用いて説明する。
【００１２】
〔実施形態１〕
以下、本発明に係る第一の実施形態を、図１ないし図１９を用いて説明する。（I）光クロスコネクト網のシステム構成
先ず、図１ないし図４を用いて本発明の光クロスコネクト網のシステム構成について説明する。
図１は、本発明の光クロスコネクト網のネットワーク構成図である。
図２は、本発明の光クロスコネクト網の詳細な構成図である。
図３は、光スイッチ部での通信を説明するための図である。
図４は、光クロスコネクト監視・制御ソフトウェア構成を説明するための図である。
【００１３】
本発明の光クロスコネクト網は、図１に示されように光クロスコネクト１１，１２，…（以下、「ＯＸＣ」と略記する）間は、ＷＤＭ（Wavelength Division Multiplexing）回線３１，３２，…にてメッシュ状に接続されており、各ＯＸＣ１１，１２，…には、ルータ回線７１，７２，…によりルータ２１〜３０が接続されている。光パス管理サーバ４は、ユーザからの要求に基づいてＯＸＣ１１，１２，…に対して光パスの設定要求をおこなう。そして、この光パス管理サーバ４からのトリガによって、ルータ間に光パスが設定される。
【００１４】
ＯＸＣの構成を詳細に示すと図２のようになる。すなわち、ＯＸＣ１４は、ＧＭＰＬＳコントローラ５１と、光スイッチ部６１からなり、ネットワーク階層としては、ＧＭＰＬＳコントローラが属しＧＭＰＬＳの制御信号が流れる制御プレーンと、光スイッチ部が属し主信号が流れるデータプレーンの２階層で構成される。ＧＭＰＬＳコントローラ５１は、隣接するＯＸＣのＧＭＰＬＳコントローラ５２と接続それており、各ＧＭＰＬＳコントローラ間と、光パス管理サーバ４と各ＯＸＣのＧＭＰＬＳコントローラ間については、ＩＰレベルで相互接続されているものとする。
【００１５】
ＧＭＰＬＳコントローラ５１，５２は、光パス管理サーバ４から光パス生成要求を受けると、ＧＭＰＬＳのシグナリングプロトコルを使って、光パスの使用波長、経路を決定する。そして、その情報をもとに光スイッチの設定をおこない、ルータ２５，２８間の光パスを確立する。ＧＭＰＬＳシグナリングプロトコルとしては、ＴＥ−ＲＳＶＰ（Traffic Engineering-Resource Reservation Protocol）、ＣＲ−ＬＤＰ（Constraint Routing-Label Distribution Protocol）が存在するが、本実施形態では、ＧＭＰＬＳシグナリングプロトコルとしてＣＲ−ＬＤＰを用いて説明することにする。
【００１６】
光スイッチ部での通信の概念を示すと、図３に示されるようになる。
【００１７】
光スイッチ部は、波長単位での経路切替え機能を持っている。光スイッチ部には、複数のＷＤＭ回線とルータ回線が接続される。ＷＤＭ回線には、ＷＤＭ回線毎に方路番号と、使用可能な波長をチャネル番号として割り当て、ルータ回線には、一つ方路番号と、接続ルータ毎に個別のチャネル番号を割り当てる。チャネルは入力用と出力用とに分かれている。そして、光スイッチ部は、ＧＭＰＬＳコントローラ５１，５２から指定された入力の方路、チャネル番号と、出力の方路、チャネル番号間でのスイッチング制御をおこなう。
【００１８】
上記の光スイッチ部での通信は、ＧＭＰＬＳコントローラが制御することによりおこなわれる。
【００１９】
ＧＭＰＬＳコントローラ５１には、図４に示されるようにＧＭＰＬＳ制御プログラム４１、ルーティングプロトコル４２と、フォワーディングＤＢ４３が実装されている。
【００２０】
ＧＭＰＬＳ制御プログラム４１は、ＧＭＰＬＳプロトコル処理、光スイッチ制御等の処理をおこなうプログラムである。ルーティングプロトコル４２は、制御プレーンを使って、ＯＸＣ網のトポロジーを自動的に収集し、その結果をフォワーディングＤＢ４３に格納するためのプロトコルである。なお、ルーティングプロトコル４２については、ＩＥＴＦで議論されているＯＳＰＦ（Open Shortest Path First）オプティカル拡張の技術を用いて、実現することができる。一方、光スイッチ部６１には、光スイッチの制御ならびに、光パスの監視・制御をおこなうＯＸＣ監視・制御プログラム４４が実装されている。
【００２１】
ＧＭＰＬＳコントローラ５１と、光スイッチ部６１はイーサネット４６（イーサネットは、登録商標）で接続されており、ＧＭＰＬＳ制御プログラム４１とＯＸＣ監視・制御プログラム４４間でメッセージ通信をおこなう。このメッセージ通信によって、光スイッチの制御や、光スイッチ部からＧＭＰＬＳコントローラへの光パス障害通知／切替え通知がおこなわれる。
（II）ＧＭＰＬＳコントローラに関連するデータ構造
次に、図５ないし図９を用いてＧＭＰＬＳコントローラに関連するデータ構造について説明する。これは、ＧＭＰＬＳ制御プログラム４１で使用するテーブル、および、データベース（ＤＢ）である。
図５は、接続ルータ管理テーブルの構造を示す模式図である。
図６は、方路管理テーブルの構造を示す模式図である。
図７は、ラベル状態管理テーブルの構造を示す模式図である。
図８は、光パス管理テーブルの構造を示す模式図である。
図９は、フォワーディングＤＢ構造を示す模式図である。
【００２２】
接続ルータ管理テーブルは、自らのＯＸＣに接続されているルータを管理するためのテーブルであり、図５に示されるように自らのＯＸＣに接続されたルータのチャネル番号（フィールド５０１）と、ＩＰアドレス（フィールド５０２）がセットされる。
【００２３】
方路管理テーブルは、自らのＯＸＣが有する方路を管理するためのテーブルであり、図６に示されるようにＷＤＭ回線に割り当てられた方路番号（フィールド６０１）と、その方路先に接続された隣接ＧＭＰＬＳコントローラのＩＰアドレス（フィールド６０２）がセットされる。ＧＭＰＬＳの場合、一般に制御信号と主信号は別回線となるため、制御信号（例えば、後述するＬａｂｅｌ Ｒｅｑｕｅｓｔメッセージなど）の送信回線と、生成する光パスの回線（方路）は一致しないが、本実施形態では、方路番号と隣接ＧＭＰＬＳコントローラのＩＰアドレスは１対１に対応するものとし、制御信号の送信元アドレスから、生成する光パスの方路も特定できるものとする。
【００２４】
ラベル状態管理テーブルは、 ＷＤＭ回線のラベルの状態を管理するためのテーブルであり、ＷＤＭ回線毎に存在して、図７に示されるように使用可能な入力チャネル番号（フィールド７１）と、チャネルの状態（フィールド７２）がセットされる。使用するラベルは受信側が決定するものであり、本実施例では、ＷＤＭ回線の入力チャネル（実態は波長）がラベルに相当する。
【００２５】
光パス管理テーブルは、ＧＭＰＬＳコントローラが設定した光パスを管理するためのテーブルであり、光パスＩＤ（フィールド８１）、入力の方路番号とチャネル番号（フィールド８２，８３）、出力の方路番号とチャネル番号（フィールド８４，８５）、および、パスの送信先ルータのアドレス（フィールド８６）と、パス識別コードフラグ（フィールド８７）がセットされる。
【００２６】
パス識別コードは、そのパスに対してこのＯＸＣがどのタイプのＯＸＣにあたるかを識別するために、Ｉｎｇｒｅｓｓ／Ｃｏｒｅ／Ｅｇｒｅｓｓ ＯＸＣの三種類のＯＸＣのタイプを識別するためのコードが入る。なお、三種類のＯＸＣのタイプについては、後に詳細に説明する。
【００２７】
ここで、上記テーブルにセットされる方路番号やチャネル番号等については、手動、あるいは、自動コンフィギュレーションによってセットされ、光スイッチ部６１とＧＭＰＬＳコントローラ５１間、および、隣接するＧＭＰＬＳコントローラ間５１，５２にて、各値のネゴシエーションが取れているものとする。
【００２８】
フォワーディングＤＢ４３は、光パスの経路（方路）を決定するためのルーティングプロトコルに用いられるものであり、宛先である送信先ルータのＩＰアドレス（フィールド９１）に対して、次ホップＧＭＰＬＳコントローラのＩＰアドレス（フィールド９２）がルーティングプロトコルによってセットされる。
（III）ＯＸＣでの光パスの生成
次に、図１０ないし図１２を用いてＯＸＣで光パスを生成するときの処理について説明する。
【００２９】
ＧＭＰＬＳのＣＲ−ＬＤＰでは、一度のリクエストで、ＯＸＣ間の両方向の光パスを生成するプロトコルと、片方向の光パスを生成するときのプロトコルが用意されているが、以下では、片方向の光パスを生成するシーケンスについてのみ説明する
先ず、ユーザは、図１に示したような光クロスコネクト網のネットワーク構成をふまえて、光パスの入り口にあたる送信元ルータと出口にあたる送信先ルータを指定して、光パスの生成の要求をおこなう。送信元ルータと、送信先ルータには、それぞれ、ＩＰアドレスとして、ＳＡ（Source Address）とＤＡ（Destination Address）が割り当てられている。
【００３０】
そして、光パス管理サーバ４は、ユーザから要求された送信元ルータと送信先ルータ間に光パスを生成するための処理を開始する。先ず、光パス管理サーバ４は、ユーザから光パス生成要求を受付けると、送信元ルータが接続されたＯＸＣのＧＭＰＬＳコントローラに対して光パスの生成要求をおこなう。
【００３１】
ところで、ＧＭＰＬＳでは、網を構成するＯＸＣに三種類のタイプを設けて、それに応じてプロトコルを規定している。
【００３２】
Ｉｎｇｒｅｓｓ ＯＸＣは、光パスの入り口にあたるＯＸＣであり、反対に、Ｅｇｒｅｓｓ ＯＸＣは、光パスの出口にあたるＯＸＣであり、その中間のＯＸＣは、Ｃｏｒｅ ＯＸＣと呼ばれる。
【００３３】
以下の光パス生成処理は、Ｉｎｇｒｅｓｓ ＯＸＣと、Ｅｇｒｅｓｓ ＯＸＣと、Ｃｏｒｅ ＯＸＣとで処理が異なるので、それぞれ分けて説明する。また、ここで説明する光パス生成処理はＧＭＰＬＳの標準シーケンスである。
【００３４】
以下で説明するように、光パスの入り口であるＩｎｇｒｅｓｓ、中間のＣｏｒｅ、出口であるＥｇｒｅｓｓのＯＸＣに順次メッセージがやり取りされて、パス管理サーバ４が要求したＳＡからＤＡへの片方向の光パスが生成されることになる。
（Ａ）Ｉｎｇｒｅｓｓ ＯＸＣでの光パス生成処理
先ず、図１０を用いてＩｎｇｒｅｓｓ ＯＸＣで光パスを生成するときの処理について説明する。
図１０は、ＯＸＣで光パスを生成するときのＩｎｇｒｅｓｓ ＯＸＣの処理を示すフローチャートである。
【００３５】
Ｉｎｇｒｅｓｓ ＯＸＣは、送信元ルータが接続されているＯＸＣであり、光パス管理サーバ４から光パス生成の要求を受けるＯＸＣであった。
【００３６】
Ｉｎｇｒｅｓｓ ＯＸＣのＧＭＰＬＳ制御プログラム４１は、光パス管理サーバ４から光パス生成要求を受付けると、初めに光パスＩＤを生成する（ステップ１０１）。これはＯＸＣ網の光パスを一意に識別するための識別子であり、光パスの管理に用いられる。ここでは、図８に示されるようにＩｎｇｒｅｓｓ ＯＸＣのＧＭＰＬＳコントローラのＩＰアドレスに、ＧＭＰＬＳコントローラがローカルに管理する一貫番号を付加した値とする。
【００３７】
次に、送られてきたＤＡをキーにして、フォワーディングＤＢ３をサーチし、Ｌａｂｅｌ Ｒｅｑｕｅｓｔメッセージ（以下、単に「Ｌａｂｅｌ Ｒｅｑｕｅｓｔ」という）を送信するＧＭＰＬＳコントローラのＩＰアドレスを取得する（ステップ１０２）。
【００３８】
Ｌａｂｅｌ Ｒｅｑｕｅｓｔとは、あるＯＸＣが他のＯＸＣに対して、送信のためのラベル割当てを要求するメッセージである。Ｌａｂｅｌ Ｒｅｑｕｅｓｔを送信されたＯＸＣは、それに応えてＬａｂｅｌ Ｍａｐｐｉｎｇメッセージ（以下、単に「Ｌａｂｅｌ Ｍａｐｐｉｎｇ」という）により、割当てたラベル（チャネル番号であり、光パスの波長）を通知する。
【００３９】
先ず、取得したＧＭＰＬＳコントローラのＩＰアドレスをキーにして方路管理テーブルをサーチし、光パスの送信方路番号を取得する（ステップ１０３）。
【００４０】
次に、Ｌａｂｅｌ Ｒｅｑｕｅｓｔのパラメータとして、光パスＩＤと、ＤＡをセットして、ステップ１０２で求めた送信先のＩＰアドレスを持つＧＭＰＬＳコントローラに送信し（ステップ１０４）、Ｌａｂｅｌ Ｍａｐｐｉｎｇの受信待ちとなる（ステップ１０５）。
【００４１】
このＯＸＣに送信されてくるＬａｂｅｌ Ｍａｐｐｉｎｇには、Ｌａｂｅｌ Ｍａｐｐｉｎｇ送信元のＧＭＰＬＳコントラーラが指定した入力チャネル（Ｌａｂｅｌ Ｍａｐｐｉｎｇ 受信側からみると、出力チャネルになる）がセットされている。
【００４２】
したがって、このＯＸＣのＧＭＰＬＳコントローラがＬａｂｅｌ Ｍａｐｐｉｎｇを受信すると、上記のパラメータを基にして、入力の方路とチャネル番号、出力の方路とチャネル番号を指定して光スイッチ部に対して、スイッチの設定要求をおこなう（ステップ１０６）。
【００４３】
すなわち、入力側に、光パス生成要求時に指定されたＳＡに対する方路番号とチャネル番号を、出力側にＬａｂｅｌ Ｒｅｑｕｅｓｔを送信した方路番号と、受信したＬａｂｅｌ Ｍａｐｐｉｎｇにセットされていたチャネル番号を指定する。
【００４４】
そして、光スイッチの設定後、設定した光パスの情報を、図８に示した光パス管理テーブルにセットする（ステップ１０７）。すなわち、この処理では、ステップ１０１で生成した光パスＩＤ、ＧＭＰＬＳコントローラが光スイッチ部に指定した入出力の方路番号とチャネル番号、送信先ルータの宛先アドレス（ＤＡ）と、パス識別コードに「Ｉｎｇｒｅｓｓ」を表すコードをフィールド８１〜８７にそれぞれセットする。最後に、光パスＩＤを光パス管理サーバ４に通知して処理を終了する。
（Ｂ）Ｃｏｒｅ ＯＸＣでの光パス生成処理
次に、図１１を用いてＣｏｒｅ ＯＸＣで光パスを生成するときの処理について説明する。
図１１は、ＯＸＣで光パスを生成するときのＣｏｒｅ ＯＸＣの処理を示すフローチャートである。
【００４５】
Ｃｏｒｅ ＯＸＣは、Ｉｎｇｒｅｓｓ ＯＸＣとＥｇｒｅｓｓ ＯＸＣ間の経路の中間に位置するＯＸＣであった。
【００４６】
したがって、パスの上流にある（Ｉｎｇｒｅｓｓ ＯＸＣまたはＣｏｒｅ ＯＸＣである）ＯＸＣからＬａｂｅｌ Ｒｅｑｕｅｓｔを受信することになる。
【００４７】
Ｃｏｒｅ ＯＸＣのＧＭＰＬＳ制御プログラム４１は、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを受信すると（ステップ１１１）、Ｉｎｇｒｅｓｓ ＯＸＣでの処理（ステップ１０２〜１０３）と同様に、セットされたＤＡをキーにしてフォワーディングＤＢをサーチし、Ｌａｂｅｌ Ｒｅｑｕｅｓｔ送信先のＧＭＰＬＳコントローラのＩＰアドレスと、送信先ＧＭＰＬＳコントローラのＩＰアドレスから方路管理テーブルをサーチし送信方路番号を取得する（ステップ１１２，１１３）。そして、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを送信し（ステップ１１４）、ＬａｂｅｌＭａｐｐｉｎｇの受信待ちとなる（ステップ１１５）。
【００４８】
パスの下流にあたるＯＸＣ（Ｃｏｒｅ ＯＸＣまたはＥｇｒｅｓｓ ＯＸＣである）Ｌａｂｅｌ Ｍａｐｐｉｎｇを受信すると、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを受信した方路のラベル状態管理テーブルを参照し、入力チャネルを確保する（ステップ１１６）。Ｌａｂｅｌ Ｒｅｑｕｅｓｔ受信方路番号は、図６に示した方路管理テーブルからＬａｂｅｌ Ｒｅｑｕｅｓｔ送信元アドレスと一致する方路をサーチすることで確認できる。
【００４９】
チャネルの状態は、「空き」、「使用中」、「異常」、「予約中」の四種類あるが、ＧＭＰＬＳコントローラは、ここで空き状態のチャネルを確保し、確保した入力チャネルに該当する図７に示したラベル状態管理テーブルのチャネル状態７２を、「空き」から「使用中」に変更する。そして、入力チャネル確保後、光スイッチ部に対し、光パス生成要求をおこなう（ステップ１１７）。入力の方路、チャネル番号には、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを受信した方路番号と、ステップ１１６で確保した入力チャネルの番号を指定し、出力の方路、チャネル番号には、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを送信した方路番号と、受信したＬａｂｅｌＭａｐｐｉｎｇにセットされたチャネル番号を指定する。
【００５０】
光パス管理テーブルを更新（ステップ１１８）した後、確保した入力チャネル番号をＬａｂｅｌ Ｍａｐｐｉｎｇにセットして、Ｌａｂｅｌ Ｒｅｑｕｅｓｔ送信元のパスの上流のＯＸＣのＧＭＰＬＳコントローラに送信する。
【００５１】
光パス管理テーブル更新処理（ステップ１１８）は、Ｉｎｇｒｅｓｓ ＯＸＣでの処理（ステップ１０７）と同様であり、異なるのは、パス識別コードのセットが「ｃｏｒｅ」を表すコードになることだけである。
（Ｃ）Ｅｇｒｅｓｓ ＯＸＣでの光パス生成処理
次に、図１２を用いてＥｇｒｅｓｓ ＯＸＣで光パスを生成するときの処理について説明する。
図１２は、ＯＸＣで光パスを生成するときのＥｇｒｅｓｓ ＯＸＣの処理を示すフローチャートである。
【００５２】
Ｅｇｒｅｓｓ ＯＸＣは、光パスの出口にあたるＯＸＣであり、宛先の送信先ルータに接続されているＯＸＣであった。
【００５３】
Ｅｇｒｅｓｓ ＯＸＣのＧＭＰＬＳ制御プログラム４１は、パスの上流のＯＸＣ（Ｉｎｇｒｅｓｓ ＯＸＣまたはＣｏｒｅ ＯＸＣである）からＬａｂｅｌ Ｒｅｑｕｅｓｔを受信すると（ステップ１２１）、セットされたＤＡをキーにしてフォワーディングＤＢをサーチする。ただし、ＤＡのＩＰアドレスを持つルータは自ＯＸＣに接続されていることが分かるので、自らがＥｇｒｅｓｓ ＯＸＣであると判定して、Ｌａｂｅｌ Ｒｅｑｕｅｓｔの送信はおこなわれない（ステップ１２２）。
【００５４】
自らがＥｇｒｅｓｓ ＯＸＣの判定した後、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを受信した方路のラベル状態管理テーブルを参照し、空き状態の入力チャネルを確保する。確保したチャネルの状態は、「空き」から「使用中」に更新して、ラベル状態管理テーブルのチャネル状態７２の値をセットする（ステップ１２３）。そして、ＧＭＰＬＳコントローラは、光スイッチ部に対し、光パス設定要求をおこなう（ステップ１２４）。
【００５５】
このとき、入力の方路、チャネル番号にＬａｂｅｌ Ｒｅｑｕｅｓｔを受信した方路番号と、ステップ１２３で確保した受信チャネル番号を指定し、出力の方路、チャネル番号にＤＡの方路番号とチャネル番号を指定する。
【００５６】
次に、光パス管理テーブルを更新し（ステップ１２５）、確保した入力チャネル番号をＬａｂｅｌ Ｍａｐｐｉｎｇメッセージにセットして、Ｌａｂｅｌ Ｒｅｑｕｅｓｔ送信元であるパスの上流のＯＸＣのＧＭＰＬＳコントローラに送信する（ステップ１２６）。
【００５７】
光パス管理テーブル更新処理は、ＩｎｇｒｅｓｓとＣｏｒｅ ＯＸＣでの処理（ステップ１０７，１１８）と同様であり、異なるのは、パス識別コードのセットが「Ｅｇｒｅｓｓ」を表すコードになることだけである。
（III）光パスの障害回復処理
次に、図１３および図１９を用いて本発明の光クロスコネクト網の光パスに障害が起こったときの障害回復処理について説明する。
【００５８】
以下、光クロスコネクト網の光パスに障害が起こったときの障害回復処理について、光スイッチ部主体でバックアップパスへの切替えをおこなう場合と、ＧＭＰＬＳコントローラ主体でバックアップパスへの切替えをおこなう場合について項をわけて説明する。
（Ａ）光スイッチ部主体でバックアップパスへの切替えをおこなう場合
先ず、図１３ないし図１６を用いて光スイッチ部主体でバックアップパスへの切替えをおこなう場合について説明する。
図１３は、光スイッチ部主体でバックアップパスへの切替えをおこなう例の説明図である。
図１４は、イベントフォーマットの模式図である。
図１５は、バックアップパス通知フォーマットの模式図である。
図１６は、本発明の第一の実施形態に係るＧＭＰＬＳコントローラがイベントを受信したときの障害回復の処理を示すフローチャートである。
【００５９】
この場合は、光パスに障害が起こり通信ができなくなったときで、光スイッチ部のみでバックアップパスへの切替えがおこなえる場合であり、例えば、通信をおこなっている光パスのファイバーは使えるが、該当するチャネルに障害がおこったときで、他のチャネルは使用できる場合である。
【００６０】
このときには、光スイッチ部のＯＸＣ監視・制御プログラム４４の動作により、光スイッチ部のみで、障害が発生したＯＸＣ間での障害回復をおこなうことになる。なお、この実現方法については、例えば、ＳＤＨ伝送のＡＰＳバイト等を用いて実現するものとする。
【００６１】
本実施形態では、障害が発生したＯＸＣ間で、元の光パスと異なった空きチャネルが使用可能な場合であって、光スイッチ部のＯＸＣ監視・制御プログラム４４の動作のみで、他の空きチャネルへの切替えがおこなえるものとする。
【００６２】
例えば、図１３に示すような網の構成において、ＯＸＣ２とＯＸＣ３間のチャネル番号１に障害が発生したとき、空き状態であるチャネル番号３への切替えがおこなえるものとする。
【００６３】
このとき、光スイッチ部のＯＸＣ監視・制御プログラム４４は、障害時、ならびに、障害回復時、入・出力のチャネル単位でイベント情報をＧＭＰＬＳ制御プログラム４１に通知する。
【００６４】
このときのイベントフォーマットは、図１４に示すようにイベントコード（フィールド１４１）、入出力コード（フィールド１４２）、イベント発生方路番号とイベント発生チャネル番号（フィールド１４３，１４４）、切替えコード（フィールド１４５）、および、切替方路番号、チャネル番号（フィールド１４６，１４７）をセットするエリアで構成される。
【００６５】
イベントコードは、イベントが障害発生か障害回復かを識別するコードである。入出力コードは、イベントが入力チャネルか出力チャネルかを識別するコードである。切替えコードは、切替えがおこなわれたか否かを識別するためのコードであり、「切替え実施」、「切替え不可」、「切替え不要」の三つの状態を持つ。ここで、「切替え実施」、「切替え不可」は、光スイッチ部がバックアップパスへの切替えをおこなったか、できなかったかを表す。また、「切替え不要」は、パスが設定されておらず、未使用中のチャネルであって、切替えをおこなう必要がない場所に対する障害を表す。
【００６６】
図１３に示されるようにＩｎｇｒｅｓｓ ＯＸＣのＯＸＣ１、Ｃｏｒｅ ＯＸＣのＯＸＣ２、Ｅｇｒｅｓｓ ＯＸＣのＯＸＣ３が接続されているときに、ＯＸＣ２のチャネル番号１とＯＸＣ３のチャネル番号１の間の経路で障害が起こったものとする。ここで、プライマリーパスと呼んでいるのは、バックアップパスに対する概念であり、障害がおこる前に最初に使用されていた元の光パスである。
【００６７】
この例では、ＯＸＣ２とＯＸＣ３の間でＯＸＣ２のチャネル番号３とＯＸＣ３のチャネル番号３のバックアップパスに切替えている。バックアップパスのための切替えの方路と、チャネル番号を確保するには、二通りのやり方が考えられる。
【００６８】
一つは、光スイッチ部のＯＸＣ監視・制御プログラム４４が自ら探して確保する方法であり、また、今一つは、ＧＭＰＬＳコントローラが光スイッチ部に対して、図１５に示されたようなバックアップ通知フォーマットにより通知された切替え方路番号（フィールド１３６）と、切替えチャネル番号（フィールド１３７）の内容を保持しておいて、障害が起こったときにこの情報を利用してバックアップパスに切替える方法である。
【００６９】
切替えが終わると、ＯＸＣ２，３の各光スイッチ部はこれらの情報を、図１４に示すフォーマットで、各ＧＭＰＬＳコントローラにイベントとして通知する。
【００７０】
ＧＭＰＬＳコントローラ５１内のＧＭＰＬＳ制御プログラム４１は、イベントを受信すると図１５のフローチャートに示された処理を実行する。
【００７１】
先ず、イベントを受信すると（ステップ１５０）、イベントの入出力コードと、発生方路番号からＷＤＭ回線の入力チャネルに対するイベントか否かチェックする（ステップ１５１）。
【００７２】
障害が起こった回線がＷＤＭ回線か否かのチェックは、イベント発生方路が方路管理テーブルに登録されているか否かによって判断できる。そして、ＷＤＭ回線の入力チャネルの場合には、イベントコードに応じて下記のようにラベル状態管理テーブルの更新処理（ステップ１５２）をおこなう。
【００７３】
イベントコードが「障害」の場合、障害が発生した方路番号とチャネル番号をキーにして、ラベル状態管理テーブルを参照し、障害が発生した入力チャネルの状態を「使用中」から「異常」に更新する。そして、切替えコードが、「切替え実施」状態の場合は、さらに切替えた入力チャネルの状態を「空き」から「使用中」に更新する。また、イベントコードが「障害回復」の場合、回復した方路番号とチャネル番号をキーにして、ラベル状態管理テーブルを参照し、回復したチャネルの状態を「異常」から「空き」に更新する。
【００７４】
次に、イベントコードをチェックし（ステップ１５３）、「障害回復」の場合は処理を終了する。
【００７５】
イベントコードが、「障害」のときには、切替えコードを判定する（ステップ１５４）。
【００７６】
切替えコードが、「切替え不要」であればそのまま処理を終了し、「切替え実施」であれば、光パス管理テーブルの更新処理をおこなう（ステップ１５５）。ここでの更新処理は、入出力コード１４２、イベント発生した方路番号１４３、イベント発生したチャネル番号１４４、切替え方路番号１４６、切替えチャネル番号１４７を参照して、新しいバックアップパスの方路番号、チャネル番号を設定する。
【００７７】
以上の処理によって、光スイッチ部による切替えが可能な障害の場合、障害がおこってもバックアップパスへの高速の切替えがおこなえるとともに、ＧＭＰＬＳコントローラで保持するラベル状態管理テーブルも光スイッチ部の状態とあわせて更新でき、かつ、切替えられた光パスの情報も更新できる。同様に障害回復時や、切替え不要な障害の場合についても、ラベル状態管理テーブルを光スイッチ部の状態とあわせて更新できる。
（Ｂ）ＧＭＰＬＳコントローラ部主体でバックアップパスへの切替えをおこなう場合
次に、先の図１６と、図１７ないし図１９を用いて光スイッチ部主体でバックアップパスへの切替えをおこなう場合について説明する。
図１７は、ＧＭＰＬＳコントローラ主体でバックアップパスへの切替えをおこなう例の説明図である。
図１８は、Ｌａｂｅｌ ＷｉｔｈＤｒａｗメッセージを受信したＯＸＣのＧＭＰＬＳコントローラの処理を示すフローチャートである。
図１９は、Ｌａｂｅｌ Ｒｅｌｅａｓｅメッセージを受信したＯＸＣのＧＭＰＬＳコントローラの処理を示すフローチャートである。
【００７８】
この場合は、光パスに障害が起こり通信ができなくなったときで、光スイッチ部のみでバックアップパスへの切替えがおこなえなくなった場合であり、例えば、通信をおこなっている光パスのファイバーが切断された状態になり、該当する経路では通信ができなくなって目的の通信をおこなうために迂回する経路が必要になったときである。
【００７９】
ここでは、例えば、図１７に示されるようにＯＸＣ２とＯＸＣ３との間のＷＤＭ回線が全て障害になったとする。
【００８０】
障害がおこったときには、ＯＸＣ２の光スイッチ部は、出力のチャネル番号１が障害であること、ＯＸＣ３の光スイッチ部は、入力のチャネル番号１が障害であることを、また、切替えの状態が「切替え不可」であることを、自らのＧＭＰＬＳコントローラに通知する。
【００８１】
ＧＭＰＬＳコントローラ５１内のＧＭＰＬＳ制御プログラム４１は、イベントを受信すると（ステップ１５０）、イベントの入出力コードと、発生方路番号からＷＤＭ回線の入力チャネルに対するイベントか否かチェックする（ステップ１５１）。
【００８２】
この場合に、ＯＸＣ３の障害の方が、ＷＤＭ回線の入力チャネルの障害になるので（ステップ１５１）、既に説明したように、ＯＸＣ３のＧＭＰＬＳコントローラは、ラベル状態管理テーブルの入力チャネル番号７１のチャネル状態７２を「障害中」に書換える（ステップ１５２）。
【００８３】
次に、イベントコードをチェックし（ステップ１５３）、イベントコードが、「障害」のときには、切替えコードを判定する（ステップ１５４）。
【００８４】
そして、切替えコードが「切替え不可」なので、障害が発生した光パスをいったん、削除する。
【００８５】
そのために、入出力コード、障害のあった方路番号、チャネル番号をキーして光パス管理テーブルから対象の光パスを検索し、光パスＩＤと、入・出力の方路番号を取得し、該当するエントリーを削除する（ステップ１５６）。そして、障害が発生した光パスの削除要求をおこなう（ステップ１５７）。
【００８６】
光クロスコネクト網で光パスを削除すために、障害が発生したチャネルが入力の場合には、ＧＭＰＬＳコントローラは、Ｌａｂｅｌ Ｒｅｌｅａｓｅメッセージ（以下、「Ｌａｂｅｌ Ｒｅｌｅａｓｅ」と呼ぶ）をＥｇｒｅｓｓ側ＯＸＣのＧＭＰＬＳコントローラに送信する。反して、障害が発生したチャネルが出力の場合には、ＧＭＰＬＳコントローラは、Ｉｎｇｒｅｓｓ側ＯＸＣのＧＭＰＬＳコントローラにＬａｂｅｌ Ｗｉｔｈｄｒａｗメッセージ（以下、「Ｌａｂｅｌ Ｗｉｔｈｄｒａｗ」と呼ぶ）を送信する。
【００８７】
ここで、Ｌａｂｅｌ Ｒｅｌｅａｓｅ、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗは、ＧＭＰＬＳの標準シーケンスとして規定されているものであり、Ｌａｂｅｌ Ｒｅｌｅａｓｅは、Ｉｎｇｒｅｓｓ側からＥｇｒｅｓｓ側に送信されるＧＭＰＬＳのメッセージであり、正常時にも用いられるパス削除要求である。Ｌａｂｅｌ Ｗｉｔｈｄｒａｗは、Ｅｇｒｅｓｓ側からＩｎｇｒｅｓｓ側に向けて送信される異常時のパス削除要求である。Ｌａｂｅｌ ＲｅｌｅａｓｅとＬａｂｅｌ Ｗｉｔｈｄｒａｗの送信先ＧＭＰＬＳコントローラのＩＰアドレスについては、障害のあった光パスの入・出力方路番号から方路管理テーブルを参照することで取得できる。なお、Ｉｎｇｒｅｓｓ、および、Ｅｇｒｅｓｓ ＯＸＣについては、光パスの端点であり、Ｌａｂｅｌ Ｒｅｌｅａｓｅ、および、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗの送信はおこなわない。
【００８８】
図１７に示した本実施形態の例では、ＯＸＣ２のＧＭＰＬＳコントローラは、ＯＸＣ１に対してＬａｂｅｌ Ｗｉｔｈｄｒａｗを送信し、ＯＸＣ３のＧＭＰＬＳコントローラは、Ｅｇｒｅｓｓ ＯＸＣであり、Ｌａｂｅｌ Ｒｅｌｅａｓｅの送信はおこなわない。
【００８９】
Ｌａｂｅｌ Ｒｅｌｅａｓｅと、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗには、削除する光パスＩＤをセットし、この値によって削除する光パスが特定される。Ｌａｂｅｌ Ｒｅｌｅａｓｅ、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗの処理の詳細は、後に説明する。
【００９０】
そして、Ｉｎｇｒｅｓｓ ＯＸＣの場合には（ステップ１５８）、削除した光パスと同一のＳＡ，ＤＡに対して再度、光パスの生成処理をおこなう（ステップ１５９）。このとき、フォワーディングＤＢは既に、ルーティングプロトコルによって障害時の状態が反映され、ＤＡへの光パスの経路（方路）は障害箇所を迂回するように更新されているものとする。Ｉｎｇｒｅｓｓ ＯＸＣからのＬａｂｅｌ Ｒｅｑｕｅｓｔは、障害を迂回するＯＸＣに順次送信され、ＥｇｒｅｓｓＯＸＣまで到達される。すなわち、本実施形態の考え方は、障害時のバックアップパスをルーティングプロトコルによって作成させるものであると言える。
【００９１】
図１７に示した本実施形態の場合には、Ｌａｂｅｌ Ｒｅｑｕｅｓｔは、ＯＸＣ１からＯＸＣ４に、ＯＸＣ４からＯＸＣ５に、ＯＸＣ５からＯＸＣ３にそれぞれ送信される。
【００９２】
Ｉｎｇｒｅｓｓ、Ｃｏｒｅ、Ｅｇｒｅｓｓ ＯＸＣでは、それぞれ、図１０により説明したＩｎｇｒｅｓｓ ＯＸＣでの光パス生成要求受付け処理、図１１により説明したＣｏｒｅ ＯＸＣでのＬａｂｅｌ Ｒｅｑｕｅｓｔ受信処理、図１２により説明したＥｇｒｅｓｓ ＯＸＣでのＬａｂｅｌ Ｒｅｑｕｅｓｔ受信処理をおこなうことで、障害のバックアップパスとして、ＳＡからＤＡへの光パスが生成される。
【００９３】
なお、Ｉｎｇｒｅｓｓ ＯＸＣにおける光パスＩＤ生成処理（ステップ１０１）については、障害で削除された光パスＩＤとは、異なる光パスＩＤを割り当てることとする。これは、障害による光パス削除処理と、光パスの再生成処理が競合するのを防ぐためである。
【００９４】
次に、図１８を用いてＬａｂｅｌ Ｗｉｔｈｄｒａｗを受信したときのＧＭＰＬＳのＧＭＰＬＳ制御プログラム４１の処理について説明する。
【００９５】
先ず、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗを受信すると（ステップ１７１）、セットされたパスＩＤをキーにして光パス管理テーブルを参照し、設定していたスイッチの開放処理を光スイッチ部に要求する（ステップ１７２）。そして、開放したＷＤＭ回線の入力チャネルについて、ラベル状態管理テーブルのチャネル状態を「使用中」から「空き」の状態に更新する（ステップ１７３）。また、削除要求のあった光パスのエントリーを光パス管理テーブルから削除する（ステップ１７４）。
【００９６】
そして、そのＯＸＣのタイプを判定し（ステップ１７５）、Ｉｎｇｒｅｓｓ ＯＸＣの場合には、処理を終了し、Ｉｎｇｒｅｓｓ ＯＸＣでない場合は、Ｉｎｇｒｅｓｓ側ＯＸＣのＧＭＰＬＳコントローラに対して、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗを送信する（ステップ１７６）。
【００９７】
次に、図１９を用いてＬａｂｅｌ Ｒｅｌｅａｓｅを受信したときのＧＭＰＬＳのＧＭＰＬＳ制御プログラム４１の処理について説明する。
【００９８】
先ず、Ｌａｂｅｌ Ｒｅｌｅａｓｅを受信すると（ステップ１８１）、セットされたパスＩＤをキーにして光パス管理テーブルを参照し、設定していたスイッチの開放処理を光スイッチ部に要求する（ステップ１８２）。そして、ＷＤＭ回線の入力チャネルについて、ラベル状態管理テーブルのチャネル状態を「使用中」から「空き」の状態に更新する（ステップ１８３）。また、削除要求のあった光パスのエントリーを光パス管理テーブルから削除する（ステップ１８４）。
【００９９】
そして、そのＯＸＣのタイプを判定し（ステップ１８５）、Ｅｇｒｅｓｓ ＯＸＣの場合には、処理を終了し、Ｅｇｒｅｓｓ ＯＸＣでない場合は、Ｅｇｒｅｓｓ側ＯＸＣの次のＧＭＰＬＳコントローラに対して、Ｌａｂｅｌ Ｒｅｌｅａｓｅを送信する（ステップ１８６）。
これらの処理によって、光スイッチ部による切替えが不可能な障害の場合、いったん、障害によって切断された光パスの削除処理がおこなわれ、使用していたＷＤＭ回線の入力チャネル（ラベル）の開放処理がおこなわれる。そして、Ｉｎｇｒｅｓｓ ＯＸＣにおいて、再度、光パスの生成処理が実行されることでリカバリーがおこなわれる。
【０１００】
以上の光パス生成処理、障害時のリカバリー処理、光パス削除処理によって、ユーザに対して信頼性の高い光パスを効率よく提供することができる。
【０１０１】
〔実施形態２〕
以下、本発明に係る第二の実施形態を、図２０および図２１を用いて説明する。
図２０は、光パス管理テーブルの追加フィールドの模式図である。
図２１は、本発明の第二の実施形態に係るＧＭＰＬＳコントローラがイベントを受信したときの障害回復の処理を示すフローチャートである。
【０１０２】
第一の実施形態では、光スイッチ部でのリカバリーがおこなえない場合には、障害が起きた光パスをＬａｂｅｌ Ｒｅｌｅａｓｅと、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗにより削除して、新たにＯＸＣ間でＬａｂｅｌ Ｒｅｑｕｅｓｔによりバックアップパスを張りなおすものであった。
【０１０３】
本実施形態は、ＧＭＰＬＳコントローラが予め確保しておいたバックアップパスを、光スイッチ部に通知することにより、バックアップパスを生成して障害回復をおこなおうとするものである。
【０１０４】
光パス管理サーバ４は、ユーザからパス生成要求を受付けると、現用のプライマリーパスの生成要求をおこなうことは第一の実施形態と同様であるが、それに加えてバックアップパスの生成要求をＯＸＣ１１〜１５に対しておこなう。
【０１０５】
また、第一の実施形態、光パスの径路はルーティングプロトコル４２が作成するフォワーディングＤＢ４３に従って生成していたが、第一の実施形態では、光パス管理サーバ４がパス径路を指定することにする。これは、ＧＭＰＬＳシグナリングプロトコル（ＣＲ−ＬＤＰ，ＴＥ−ＲＳＶＰ）はパス径路を指定できるので、その機能を用いて実現することができる。
【０１０６】
以下、プライマリーパスとバックアップパスの生成について項を分けて説明する。
（I）プライマリーパスの生成処理
先ず、プライマリーパスの生成処理から説明する。
【０１０７】
Ｉｎｇｒｅｓｓ、Ｃｏｒｅ、Ｅｇｒｅｓｓ ＯＸＣにおけるプライマリーパスの生成処理は、第一の実施形態の光パス生成処理（図１０、図１１、図１２）と基本的には同一シーケンスであり、以下に第一の実施形態と異なる処理についてのみ説明することにする。
【０１０８】
光パス管理サーバ４は、送信先のルータに接続されているＩｎｇｒｅｓｓ ＯＸＣに対して、ＳＡとＤＡ、プライマリーパスの径路、パススイッチＯＸＣとパスマージＯＸＣを指定する。パス径路については、Ｉｎｇｒｅｓｓ ＯＸＣから、Ｅｇｒｅｓｓ ＯＸＣに至るまでに通過するＧＭＰＬＳコントローラのＩＰアドレスを順番に指定する。このパス経路の指定、および、パススイッチＯＸＣ、パスマージＯＸＣで、ＯＸＣの識別子として使用しているのは、ＯＸＣ内のＧＭＰＬＳコントローラのＩＰアドレスである。
【０１０９】
またここで、パススイッチＯＸＣとは、プライマリーパスとバックアップパスが分岐するＯＸＣのことであると定義し、パスマージＯＸＣとは、プライマリーパスとバックアップパスが合流するＯＸＣのことであると定義する。
【０１１０】
図１７に示したプライマリーパスとバックアップパスとＯＸＣの関係を例にとれば、パススイッチＯＸＣはＯＸＣ１であり、パスマージＯＸＣはＯＸＣ３となる。
【０１１１】
光パス管理サーバ４が指定した径路は、Ｉｎｇｒｅｓｓ ＯＸＣによって、Ｌａｂｅｌ Ｒｅｑｕｅｓｔに付加され送信される。そしてＣｏｒｅ ＯＸＣでは、この径路情報をＬａｂｅｌ Ｒｅｑｕｅｓｔに付加し送信していく。
【０１１２】
第一の実施形態では、Ｉｎｇｒｅｓｓ 、Ｃｏｒｅ ＯＸＣの光パス生成処理（図１０、図１１）において、Ｌａｂｅｌ Ｒｅｑｕｅｓｔ送信先を決定する際、フォワーディングＤＢをサーチしていたが（ステップ１０２，１１２）、第二の実施形態では、光パス管理サーバ４が指定した径路、または、Ｌａｂｅｌ Ｒｅｑｕｅｓｔにセットされた径路情報から決定するように変更する。また、光パス管理サーバ４が指定したパススイッチＯＸＣ、パスマージＯＸＣの情報についても、Ｌａｂｅｌ Ｒｅｑｕｅｓｔに付加され、プライマリーパス径路上の全ＯＸＣに通知される。
【０１１３】
プライマリパスの生成時に、光パス管理テーブルにパラメタをセットしなければならないが、本実施形態のＧＭＰＬＳコントローラが用いる光パス管理テーブルは、第一の実施形態の図８に示した光パス管理テーブルに対して、図２０に示されたフィールド２０１〜２０４が追加されるたものである。。
【０１１４】
パススイッチＯＸＣ（フィールド２０１）と、パスマージＯＸＣ（フィールド２０２）については、上記のようにＬａｂｅｌ Ｒｅｑｕｅｓｔに付加されて通知されるものであり、Ｉｎｇｒｅｓｓ、Ｃｏｒｅ、Ｅｇｒｅｓｓ ＯＸＣにおいて、プライマリパス生成時のそれぞれの光パス管理テーブル更新処理（ステップ１０７，１１８，１２５）でセットされる。
【０１１５】
切替え方路番号と切替えチャネル番号（フィールド２０３，２０４）は、バックアップパスとして切替える方路番号とチャネル番号であり、後述するバックアップパスの生成処理にてセットされる。なおこれが有効になるのは、分岐するＯＸＣであるパススイッチＯＸＣと、パスマージＯＸＣのみであり、プライマリパスとバックアップパスが分岐しない他のＯＸＣではこのパラメタは意識することはない。
【０１１６】
以上の処理によって、光パス管理サーバ４が指定した径路でＳＡ，ＤＡ間にプライマリーパスが生成される。また、パス管理テーブルのエントリーにパススイッチＯＸＣと、パスマージＯＸＣの情報がそれぞれセットされる。
（II）バックアップパスの生成処理
次にバックアップパスの生成処理について説明する。
【０１１７】
パス管理サーバ４は、プライマリ生成要求の後に、パススイッチＯＸＣに対して、バックアップパスの径路、対応するプライマリーパスのパスＩＤを指定し、バックアップパスの生成要求をおこなう。
【０１１８】
ここで、バックアップパスの径路情報、プライマリーパスのパスＩＤは、Ｌａｂｅｌ Ｒｅｑｕｅｓｔに付加され送信される。
【０１１９】
バックアップパスのＩｎｇｒｅｓｓ、Ｃｏｒｅ、Ｅｇｒｅｓｓ ＯＸＣは、プライマリーパスの生成処理と同様に処理をおこなう。ここで、バックアップパスのＩｎｇｒｅｓｓ ＯＸＣとは、パススイッチＯＸＣのことであり、Ｅｇｒｅｓｓ ＯＸＣとは、パスマージＯＸＣのことである。パススイッチＯＸＣとパスマージＯＸＣでは、パス管理テーブルから対応するプライマリーパスのエントリーをサーチし、バックアップパスへの切替え情報として切替え方路番号と切替えチャネル番号をフィールド２０３，２０４にセットする。このとき、パススイッチＯＸＣではバックアップパスの出力の方路番号とチャネル番号をセットし、パスマージＯＸＣではバックアップパスの入力の方路番号とチャネル番号をセットする。
【０１２０】
このパックアップパスの生成処理の段階では、障害がおこっていないので、パススイッチＯＸＣと、パスマージＯＸＣのＧＭＰＬＳコントローラは、実際に光スイッチ部へのパス生成要求はおこなわない。光スイッチ部へのパス生成要求がおこなわれるのは、次の項の障害が発生したときである。
【０１２１】
なお、パスマージＯＸＣの入力チャネル（ラベル）確保処理については、実際にパス設定はおこなわないので、ラベル状態管理テーブルのチャネル状態は「予約中」とする。
【０１２２】
以上の処理によって、光パス管理サーバ４が指定したパススイッチＯＸＣとパスマージＯＸＣ間の指定径路でバックアップパスが生成される。そして、パススイッチＯＸＣとパスマージＯＸＣにおいて、バックアップパスへの切替え情報がパス管理テーブルにセットされる。
【０１２３】
バックアップパスのリソース（ラベル）については、「使用中」、または、「予約中」となっており、別ユーザからの光パス生成要求によってＧＭＰＬＳコントローラが使用することはない。また、光スイッチ部も、「予約中」の入力チャネルの情報を把握していないが、入力チャネルと対向側の出力チャネルについては、既にパス設定がおこなわれており、光スイッチ部が自立的に予約中のチャネルを使用することはない。
（III）障害が発生したときの処理
次に、障害が発生したときのＧＭＰＬＳコントローラの処理について説明する。
【０１２４】
これは、プライマリーパスに障害が発生し、ＧＭＰＬＳコントローラにて、バックアップパスへ切替えるまでの処理である。
【０１２５】
光スイッチ部単独での切替え可能な障害の場合については、第一の実施形態と同様であり、本実施形態で問題となるのはＧＭＰＬＳコントローラ部主体でバックアップパスへの切替えをおこなう場合である。
【０１２６】
障害発生時、第一の実施形態と同様に、イベント情報がＧＭＰＬＳコントローラに通知される。
【０１２７】
そして、ＧＭＰＬＳコントローラ内のＧＭＰＬＳ制御プログラム４１はイベントを受信すると、図２２のフローチャートに示される処理を実行する。
【０１２８】
切替えコードが「切替え不可」のイベント処理以外（ステップ２１０〜２１５）については、図１６に示した第一の実施形態１の処理（ステップ１５０〜１５５）と同一であるので、切替えコードが「切替え不可」の場合のみ説明することにする。
【０１２９】
切替えコードが「切替え不可」の場合には（ステップ２１４）、障害が発生したＯＸＣがパススイッチＯＸＣあるいは、パスマージＯＸＣかをチェックする（ステップ２１６）。これは、光パス管理テーブルから障害発生パスに対応するパススイッチＯＸＣ、パスマージＯＸＣを参照し、自ＧＭＰＬＳコントローラのＩＰアドレスと一致するか否かをチェックすることで判断できる。
【０１３０】
障害が発生したＯＸＣがパススイッチＯＸＣ、あるいは、パスマージＯＸＣの場合には、光パス管理テーブルの切替え情報を参照し、光スイッチ部に対し切替え要求をおこなう（ステップ２１７）。
【０１３１】
パススイッチＯＸＣでも、パスマージＯＸＣでもない場合には、ｎｏｔｉｆｉｃａｔｉｏｎメッセージ（以下、単に「ｎｏｔｉｆｉｃａｔｉｏｎ」と呼ぶ）を隣接するＧＭＰＬＳコントローラに送信する（ステップ２１８）。
【０１３２】
ｎｏｔｉｆｉｃａｔｉｏｎは、ＣＲ−ＬＤＰに規定されているイベント通知用のメッセージである。ｎｏｔｉｆｉｃａｔｉｏｎに障害が発生した光パスＩＤを付加することで、障害発生パスをパススイッチＯＸＣ、パスマージＯＸＣに通知する。ｎｏｔｉｆｉｃａｔｉｏｎ送信先は、障害発生方路がＩｎｇｒｅｓｓ側かＥｇｒｅｓｓ側かによって異なる。Ｉｎｇｒｅｓｓ側ならば、Ｅｇｒｅｓｓ側の方向に位置する隣接するＧＭＰＬＳコントローラに送信し、Ｅｇｒｅｓｓ側であれば、Ｉｎｇｒｅｓｓ側の方向に位置するＧＭＰＬＳコントローラに送信する。
【０１３３】
ｎｏｔｉｆｉｃａｔｉｏｎを受信したＧＭＰＬＳコントローラ内のＧＭＰＬＳ制御プログラム４１は、図２１に示した処理（ステップ２１６〜２１８）と同様の処理をおこなう。自ＯＸＣがパススイッチＯＸＣか、もしくは、パスマージＯＸＣかをチェックする。そして、バックアップパスへの切替え、または、ｎｏｔｉｆｉｃａｔｉｏｎの送信処理をおこなう。
【０１３４】
ｎｏｔｉｆｉｃａｔｉｏｎの送信先は、Ｉｎｇｒｅｓｓ側から受信した場合は、Ｅｇｒｅｓｓ側の方向に位置する隣接ＧＭＰＬＳコントローラに、Ｅｇｒｅｓｓ側から受信した場合は、Ｉｎｇｒｅｓｓ側の方向に位置する隣接ＧＭＰＬＳコントローラに送信することは同様である。
【０１３５】
このようにして、ｎｏｔｉｆｉｃａｔｉｏｎは、障害発生したＯＸＣから、ＩｎｇｒｅｓｓとＥｇｒｅｓｓ側ＯＸＣに向けｈｏｐ−ｂｙ−ｈｏｐで伝搬されていき、パススイッチＯＸＣ、パスマージＯＸＣに伝わる。そして、障害が起こった光パスがバックアップパスに切替えられて、リカバリーがおこなわれる。
【０１３６】
【発明の効果】
本発明によれば、ＧＭＰＬＳにより光パスの制御をおこなう光クロスコネクト網で、光スイッチ部のみで高速に障害回復をおこなえるようにするとともに、光スイッチ部のみで障害回復がおこなえないときには、ＧＭＰＬＳ制御部の制御により障害の回復をおこなうようにして、多様な光クロスコネクト網の接続形態に対応できる光クロスコネクト網の障害回復方法を提供することができる。
【図面の簡単な説明】
【図１】本発明の光クロスコネクト網のネットワーク構成図である。
【図２】本発明の光クロスコネクト網の詳細な構成図である。
【図３】光スイッチ部での通信を説明するための図である。
【図４】光クロスコネクト監視・制御ソフトウェア構成を説明するための図である。
【図５】接続ルータ管理テーブルの構造を示す模式図である。
【図６】方路管理テーブルの構造を示す模式図である。
【図７】ラベル状態管理テーブルの構造を示す模式図である。
【図８】光パス管理テーブルの構造を示す模式図である。
【図９】フォワーディングＤＢ構造を示す模式図である。
【図１０】ＯＸＣで光パスを生成するときのＩｎｇｒｅｓｓ ＯＸＣの処理を示すフローチャートである。
【図１１】ＯＸＣで光パスを生成するときのＣｏｒｅ ＯＸＣの処理を示すフローチャートである。
【図１２】ＯＸＣで光パスを生成するときのＥｇｒｅｓｓ ＯＸＣの処理を示すフローチャートである。
【図１３】光スイッチ部主体でバックアップパスへの切替えをおこなう例の説明図である。
【図１４】イベントフォーマットの模式図である。
【図１５】バックアップパス通知フォーマットの模式図である。
【図１６】本発明の第一の実施形態に係るＧＭＰＬＳコントローラがイベントを受信したときの障害回復の処理を示すフローチャートである。
【図１７】ＧＭＰＬＳコントローラ主体でバックアップパスへの切替えをおこなう例の説明図である。
【図１８】Ｌａｂｅｌ ＷｉｔｈＤｒａｗメッセージを受信したＯＸＣのＧＭＰＬＳコントローラの処理を示すフローチャートである。
【図１９】Ｌａｂｅｌ Ｒｅｌｅａｓｅメッセージを受信したＯＸＣのＧＭＰＬＳコントローラの処理を示すフローチャートである。
【図２０】光パス管理テーブルの追加フィールドの模式図である。
【図２１】本発明の第二の実施形態に係るＧＭＰＬＳコントローラがイベントを受信したときの障害回復の処理を示すフローチャートである。
【符号の説明】
１１〜１５…光クロスコネクト、２１〜３０…ルータ、３１〜３７…ＷＤＭ回線、４…光パス管理サーバ、７１〜７３…ルータ回線。５１，５２…ＧＭＰＬＳコントローラ、６１，６２…光スイッチ部４１…ＧＭＰＬＳ制御プログラム、４２…ルーティングプロトコル、４３…フォワーディングＤＢ、４４…ＯＸＣ監視・制御プログラム。
【発明の属する技術分野】
本発明は、光クロスコネクト網の障害回復方法に係り、ＧＭＰＬＳにより光クロスコネクトのスイッチングをおこなう光クロスコネクト網で、光スイッチ部のみで高速に障害回復のおこなうことのできる光クロスコネクト網の障害回復方法に関する。
【０００２】
【従来の技術】
近年、インターネットの急速な普及などにより、大容量のバックボーンの通信手段として、光通信技術に関心が集まっている。このような光通信のプロトコルを規定する技術として、ＧＭＰＬＳ（Generalized Multi Protocol Label Switching）がある。ＧＭＰＬＳは、従来のＭＰＬＳのラベルをＷＤＭ（Wavelength Division Multiplexing：波長分割多重）の波長に適用したもので、ルータと光クロスコネクトの連携により波長単位の経路制御が可能になり、光クロスコネクトにＧＭＰＬＳを実装したスイッチングルータを使うと、光信号のままでスイッチングできると同時に、経路選択の決定は、ＩＰ技術で実現できるようになる。
【０００３】
ところで、フォトニックネットワークのリカバリー（プロテクション／リストレーション）としては、ＩＥＴＦ（Internet Engineering Task Force）で議論されているＧＭＰＬＳ主体のリカバリー方式と、ＩＴＵ−Ｔ（International Telecommunication Union-Telecommunication Sector）で議論されている物理層主体のリカバリー方式の２つがある。
【０００４】
ＧＭＰＬＳを使って光パスの制御をおこなう場合、ネットワークの階層構成としては、主信号が流れるデータプレーン（物理層）と、ＧＭＰＬＳの制御信号が流れるコントロールプレーン（制御層）は分離された２階層になる。この階層にしたがって、ＧＭＰＬＳ制御部は、物理層に属する光スイッチ部から障害通知してもらい、光スイッチ部に対しパス切替えを要求することで、光パスのリカバリーを実現することとなる。このリカバリーの種類としては、ＩＥＴＦドラフト（Generalized MPLS Recovery Mechanisms :draft-lang-ccamp-recovery-oo.txt）記載のように、１：１スパンプロテクション、Ｍ：Ｎパスプロテクション、パスリストレーション等、多様なリカバリー方式が検討されている。
【０００５】
物理層主体のリカバリーについては、ＩＴＵ−ＴのＡＳＴＮ（Automatic Switching Transport Network）のＧ．８７１（Framework for optical transport network recommendations）にて議論されはじめたところである。
【０００６】
【発明が解決しようとする課題】
上記のＧＭＰＬＳ主体のリカバリー方式では、ＧＭＰＬＳ自体にリンク障害検知のメカニズムを持たないため、障害が発生してからバックアップパスに切替えるまでに時間がかかってしまうという問題点があった。
【０００７】
また、上記の物理層主体のリカバリーは、現時点、ポイントｔｏポイント、あるいは、リング形態でのみ実現可能であり、メッシュ形態での切替え技術は確立されていない。例えば、ＳＤＨ（Synchronous Digital Hierarchy）伝送の ＡＰＳ（Automatic Protection Switch）バイトを用いたポイントｔｏポイント、リング形態での高速切替えは既存技術であるが、メッシュ形態において、障害時に迂回ルートへ切替える等のリカバリー技術は確立されていない。
【０００８】
本発明は、上記問題点を解決するためになされもので、その目的は、ＧＭＰＬＳにより光パスの制御をおこなう光クロスコネクト網で、光スイッチ部のみで高速に障害回復をおこなえるようにするとともに、光スイッチ部のみで障害回復がおこなえないときには、ＧＭＰＬＳ制御部の制御により障害の回復をおこなうようにして、多様な光クロスコネクト網の接続形態に対応できる光クロスコネクト網の障害回復方法を提供することにある。
【０００９】
【課題を解決するための手段】
上記問題点を解決するために、本発明では、ＧＭＰＬＳにより光パスの制御をおこない、光クロスコネクトにＧＭＰＬＳ制御部と光スイッチ部とを有する光クロスコネクト網の障害回復方法において、光パスの通信に障害が起こった際に、光スイッチ部によりバックアップパスを確保することが可能なときには、光スイッチ部は、障害情報、切替え情報をＧＭＰＬＳ制御部に通知し、ＧＭＰＬＳ制御部は、前記光スイッチ部からの障害情報、切替え情報を基にして、ラベル情報、パス管理情報を更新し、障害が起こった光パスの通信を、前記バックアップパスによりすることによって障害回復をおこなうようにする。
【００１０】
また、光スイッチ部によりバックアップパスを確保することが不可能なときには、光スイッチ部は、障害情報をＧＭＰＬＳ制御部に通知し、ＧＭＰＬＳ制御部は、光スイッチ部からの障害情報を基にして、ラベル情報、パス管理情報を更新し、バックアップパスを確保して、障害が起こった光パスの通信を、前記バックアップパスによりすることによって障害回復をおこなうようにする。
【００１１】
【発明の実施の形態】
以下、本発明に係る各実施形態を、図１ないし図２１を用いて説明する。
【００１２】
〔実施形態１〕
以下、本発明に係る第一の実施形態を、図１ないし図１９を用いて説明する。（I）光クロスコネクト網のシステム構成
先ず、図１ないし図４を用いて本発明の光クロスコネクト網のシステム構成について説明する。
図１は、本発明の光クロスコネクト網のネットワーク構成図である。
図２は、本発明の光クロスコネクト網の詳細な構成図である。
図３は、光スイッチ部での通信を説明するための図である。
図４は、光クロスコネクト監視・制御ソフトウェア構成を説明するための図である。
【００１３】
本発明の光クロスコネクト網は、図１に示されように光クロスコネクト１１，１２，…（以下、「ＯＸＣ」と略記する）間は、ＷＤＭ（Wavelength Division Multiplexing）回線３１，３２，…にてメッシュ状に接続されており、各ＯＸＣ１１，１２，…には、ルータ回線７１，７２，…によりルータ２１〜３０が接続されている。光パス管理サーバ４は、ユーザからの要求に基づいてＯＸＣ１１，１２，…に対して光パスの設定要求をおこなう。そして、この光パス管理サーバ４からのトリガによって、ルータ間に光パスが設定される。
【００１４】
ＯＸＣの構成を詳細に示すと図２のようになる。すなわち、ＯＸＣ１４は、ＧＭＰＬＳコントローラ５１と、光スイッチ部６１からなり、ネットワーク階層としては、ＧＭＰＬＳコントローラが属しＧＭＰＬＳの制御信号が流れる制御プレーンと、光スイッチ部が属し主信号が流れるデータプレーンの２階層で構成される。ＧＭＰＬＳコントローラ５１は、隣接するＯＸＣのＧＭＰＬＳコントローラ５２と接続それており、各ＧＭＰＬＳコントローラ間と、光パス管理サーバ４と各ＯＸＣのＧＭＰＬＳコントローラ間については、ＩＰレベルで相互接続されているものとする。
【００１５】
ＧＭＰＬＳコントローラ５１，５２は、光パス管理サーバ４から光パス生成要求を受けると、ＧＭＰＬＳのシグナリングプロトコルを使って、光パスの使用波長、経路を決定する。そして、その情報をもとに光スイッチの設定をおこない、ルータ２５，２８間の光パスを確立する。ＧＭＰＬＳシグナリングプロトコルとしては、ＴＥ−ＲＳＶＰ（Traffic Engineering-Resource Reservation Protocol）、ＣＲ−ＬＤＰ（Constraint Routing-Label Distribution Protocol）が存在するが、本実施形態では、ＧＭＰＬＳシグナリングプロトコルとしてＣＲ−ＬＤＰを用いて説明することにする。
【００１６】
光スイッチ部での通信の概念を示すと、図３に示されるようになる。
【００１７】
光スイッチ部は、波長単位での経路切替え機能を持っている。光スイッチ部には、複数のＷＤＭ回線とルータ回線が接続される。ＷＤＭ回線には、ＷＤＭ回線毎に方路番号と、使用可能な波長をチャネル番号として割り当て、ルータ回線には、一つ方路番号と、接続ルータ毎に個別のチャネル番号を割り当てる。チャネルは入力用と出力用とに分かれている。そして、光スイッチ部は、ＧＭＰＬＳコントローラ５１，５２から指定された入力の方路、チャネル番号と、出力の方路、チャネル番号間でのスイッチング制御をおこなう。
【００１８】
上記の光スイッチ部での通信は、ＧＭＰＬＳコントローラが制御することによりおこなわれる。
【００１９】
ＧＭＰＬＳコントローラ５１には、図４に示されるようにＧＭＰＬＳ制御プログラム４１、ルーティングプロトコル４２と、フォワーディングＤＢ４３が実装されている。
【００２０】
ＧＭＰＬＳ制御プログラム４１は、ＧＭＰＬＳプロトコル処理、光スイッチ制御等の処理をおこなうプログラムである。ルーティングプロトコル４２は、制御プレーンを使って、ＯＸＣ網のトポロジーを自動的に収集し、その結果をフォワーディングＤＢ４３に格納するためのプロトコルである。なお、ルーティングプロトコル４２については、ＩＥＴＦで議論されているＯＳＰＦ（Open Shortest Path First）オプティカル拡張の技術を用いて、実現することができる。一方、光スイッチ部６１には、光スイッチの制御ならびに、光パスの監視・制御をおこなうＯＸＣ監視・制御プログラム４４が実装されている。
【００２１】
ＧＭＰＬＳコントローラ５１と、光スイッチ部６１はイーサネット４６（イーサネットは、登録商標）で接続されており、ＧＭＰＬＳ制御プログラム４１とＯＸＣ監視・制御プログラム４４間でメッセージ通信をおこなう。このメッセージ通信によって、光スイッチの制御や、光スイッチ部からＧＭＰＬＳコントローラへの光パス障害通知／切替え通知がおこなわれる。
（II）ＧＭＰＬＳコントローラに関連するデータ構造
次に、図５ないし図９を用いてＧＭＰＬＳコントローラに関連するデータ構造について説明する。これは、ＧＭＰＬＳ制御プログラム４１で使用するテーブル、および、データベース（ＤＢ）である。
図５は、接続ルータ管理テーブルの構造を示す模式図である。
図６は、方路管理テーブルの構造を示す模式図である。
図７は、ラベル状態管理テーブルの構造を示す模式図である。
図８は、光パス管理テーブルの構造を示す模式図である。
図９は、フォワーディングＤＢ構造を示す模式図である。
【００２２】
接続ルータ管理テーブルは、自らのＯＸＣに接続されているルータを管理するためのテーブルであり、図５に示されるように自らのＯＸＣに接続されたルータのチャネル番号（フィールド５０１）と、ＩＰアドレス（フィールド５０２）がセットされる。
【００２３】
方路管理テーブルは、自らのＯＸＣが有する方路を管理するためのテーブルであり、図６に示されるようにＷＤＭ回線に割り当てられた方路番号（フィールド６０１）と、その方路先に接続された隣接ＧＭＰＬＳコントローラのＩＰアドレス（フィールド６０２）がセットされる。ＧＭＰＬＳの場合、一般に制御信号と主信号は別回線となるため、制御信号（例えば、後述するＬａｂｅｌ Ｒｅｑｕｅｓｔメッセージなど）の送信回線と、生成する光パスの回線（方路）は一致しないが、本実施形態では、方路番号と隣接ＧＭＰＬＳコントローラのＩＰアドレスは１対１に対応するものとし、制御信号の送信元アドレスから、生成する光パスの方路も特定できるものとする。
【００２４】
ラベル状態管理テーブルは、 ＷＤＭ回線のラベルの状態を管理するためのテーブルであり、ＷＤＭ回線毎に存在して、図７に示されるように使用可能な入力チャネル番号（フィールド７１）と、チャネルの状態（フィールド７２）がセットされる。使用するラベルは受信側が決定するものであり、本実施例では、ＷＤＭ回線の入力チャネル（実態は波長）がラベルに相当する。
【００２５】
光パス管理テーブルは、ＧＭＰＬＳコントローラが設定した光パスを管理するためのテーブルであり、光パスＩＤ（フィールド８１）、入力の方路番号とチャネル番号（フィールド８２，８３）、出力の方路番号とチャネル番号（フィールド８４，８５）、および、パスの送信先ルータのアドレス（フィールド８６）と、パス識別コードフラグ（フィールド８７）がセットされる。
【００２６】
パス識別コードは、そのパスに対してこのＯＸＣがどのタイプのＯＸＣにあたるかを識別するために、Ｉｎｇｒｅｓｓ／Ｃｏｒｅ／Ｅｇｒｅｓｓ ＯＸＣの三種類のＯＸＣのタイプを識別するためのコードが入る。なお、三種類のＯＸＣのタイプについては、後に詳細に説明する。
【００２７】
ここで、上記テーブルにセットされる方路番号やチャネル番号等については、手動、あるいは、自動コンフィギュレーションによってセットされ、光スイッチ部６１とＧＭＰＬＳコントローラ５１間、および、隣接するＧＭＰＬＳコントローラ間５１，５２にて、各値のネゴシエーションが取れているものとする。
【００２８】
フォワーディングＤＢ４３は、光パスの経路（方路）を決定するためのルーティングプロトコルに用いられるものであり、宛先である送信先ルータのＩＰアドレス（フィールド９１）に対して、次ホップＧＭＰＬＳコントローラのＩＰアドレス（フィールド９２）がルーティングプロトコルによってセットされる。
（III）ＯＸＣでの光パスの生成
次に、図１０ないし図１２を用いてＯＸＣで光パスを生成するときの処理について説明する。
【００２９】
ＧＭＰＬＳのＣＲ−ＬＤＰでは、一度のリクエストで、ＯＸＣ間の両方向の光パスを生成するプロトコルと、片方向の光パスを生成するときのプロトコルが用意されているが、以下では、片方向の光パスを生成するシーケンスについてのみ説明する
先ず、ユーザは、図１に示したような光クロスコネクト網のネットワーク構成をふまえて、光パスの入り口にあたる送信元ルータと出口にあたる送信先ルータを指定して、光パスの生成の要求をおこなう。送信元ルータと、送信先ルータには、それぞれ、ＩＰアドレスとして、ＳＡ（Source Address）とＤＡ（Destination Address）が割り当てられている。
【００３０】
そして、光パス管理サーバ４は、ユーザから要求された送信元ルータと送信先ルータ間に光パスを生成するための処理を開始する。先ず、光パス管理サーバ４は、ユーザから光パス生成要求を受付けると、送信元ルータが接続されたＯＸＣのＧＭＰＬＳコントローラに対して光パスの生成要求をおこなう。
【００３１】
ところで、ＧＭＰＬＳでは、網を構成するＯＸＣに三種類のタイプを設けて、それに応じてプロトコルを規定している。
【００３２】
Ｉｎｇｒｅｓｓ ＯＸＣは、光パスの入り口にあたるＯＸＣであり、反対に、Ｅｇｒｅｓｓ ＯＸＣは、光パスの出口にあたるＯＸＣであり、その中間のＯＸＣは、Ｃｏｒｅ ＯＸＣと呼ばれる。
【００３３】
以下の光パス生成処理は、Ｉｎｇｒｅｓｓ ＯＸＣと、Ｅｇｒｅｓｓ ＯＸＣと、Ｃｏｒｅ ＯＸＣとで処理が異なるので、それぞれ分けて説明する。また、ここで説明する光パス生成処理はＧＭＰＬＳの標準シーケンスである。
【００３４】
以下で説明するように、光パスの入り口であるＩｎｇｒｅｓｓ、中間のＣｏｒｅ、出口であるＥｇｒｅｓｓのＯＸＣに順次メッセージがやり取りされて、パス管理サーバ４が要求したＳＡからＤＡへの片方向の光パスが生成されることになる。
（Ａ）Ｉｎｇｒｅｓｓ ＯＸＣでの光パス生成処理
先ず、図１０を用いてＩｎｇｒｅｓｓ ＯＸＣで光パスを生成するときの処理について説明する。
図１０は、ＯＸＣで光パスを生成するときのＩｎｇｒｅｓｓ ＯＸＣの処理を示すフローチャートである。
【００３５】
Ｉｎｇｒｅｓｓ ＯＸＣは、送信元ルータが接続されているＯＸＣであり、光パス管理サーバ４から光パス生成の要求を受けるＯＸＣであった。
【００３６】
Ｉｎｇｒｅｓｓ ＯＸＣのＧＭＰＬＳ制御プログラム４１は、光パス管理サーバ４から光パス生成要求を受付けると、初めに光パスＩＤを生成する（ステップ１０１）。これはＯＸＣ網の光パスを一意に識別するための識別子であり、光パスの管理に用いられる。ここでは、図８に示されるようにＩｎｇｒｅｓｓ ＯＸＣのＧＭＰＬＳコントローラのＩＰアドレスに、ＧＭＰＬＳコントローラがローカルに管理する一貫番号を付加した値とする。
【００３７】
次に、送られてきたＤＡをキーにして、フォワーディングＤＢ３をサーチし、Ｌａｂｅｌ Ｒｅｑｕｅｓｔメッセージ（以下、単に「Ｌａｂｅｌ Ｒｅｑｕｅｓｔ」という）を送信するＧＭＰＬＳコントローラのＩＰアドレスを取得する（ステップ１０２）。
【００３８】
Ｌａｂｅｌ Ｒｅｑｕｅｓｔとは、あるＯＸＣが他のＯＸＣに対して、送信のためのラベル割当てを要求するメッセージである。Ｌａｂｅｌ Ｒｅｑｕｅｓｔを送信されたＯＸＣは、それに応えてＬａｂｅｌ Ｍａｐｐｉｎｇメッセージ（以下、単に「Ｌａｂｅｌ Ｍａｐｐｉｎｇ」という）により、割当てたラベル（チャネル番号であり、光パスの波長）を通知する。
【００３９】
先ず、取得したＧＭＰＬＳコントローラのＩＰアドレスをキーにして方路管理テーブルをサーチし、光パスの送信方路番号を取得する（ステップ１０３）。
【００４０】
次に、Ｌａｂｅｌ Ｒｅｑｕｅｓｔのパラメータとして、光パスＩＤと、ＤＡをセットして、ステップ１０２で求めた送信先のＩＰアドレスを持つＧＭＰＬＳコントローラに送信し（ステップ１０４）、Ｌａｂｅｌ Ｍａｐｐｉｎｇの受信待ちとなる（ステップ１０５）。
【００４１】
このＯＸＣに送信されてくるＬａｂｅｌ Ｍａｐｐｉｎｇには、Ｌａｂｅｌ Ｍａｐｐｉｎｇ送信元のＧＭＰＬＳコントラーラが指定した入力チャネル（Ｌａｂｅｌ Ｍａｐｐｉｎｇ 受信側からみると、出力チャネルになる）がセットされている。
【００４２】
したがって、このＯＸＣのＧＭＰＬＳコントローラがＬａｂｅｌ Ｍａｐｐｉｎｇを受信すると、上記のパラメータを基にして、入力の方路とチャネル番号、出力の方路とチャネル番号を指定して光スイッチ部に対して、スイッチの設定要求をおこなう（ステップ１０６）。
【００４３】
すなわち、入力側に、光パス生成要求時に指定されたＳＡに対する方路番号とチャネル番号を、出力側にＬａｂｅｌ Ｒｅｑｕｅｓｔを送信した方路番号と、受信したＬａｂｅｌ Ｍａｐｐｉｎｇにセットされていたチャネル番号を指定する。
【００４４】
そして、光スイッチの設定後、設定した光パスの情報を、図８に示した光パス管理テーブルにセットする（ステップ１０７）。すなわち、この処理では、ステップ１０１で生成した光パスＩＤ、ＧＭＰＬＳコントローラが光スイッチ部に指定した入出力の方路番号とチャネル番号、送信先ルータの宛先アドレス（ＤＡ）と、パス識別コードに「Ｉｎｇｒｅｓｓ」を表すコードをフィールド８１〜８７にそれぞれセットする。最後に、光パスＩＤを光パス管理サーバ４に通知して処理を終了する。
（Ｂ）Ｃｏｒｅ ＯＸＣでの光パス生成処理
次に、図１１を用いてＣｏｒｅ ＯＸＣで光パスを生成するときの処理について説明する。
図１１は、ＯＸＣで光パスを生成するときのＣｏｒｅ ＯＸＣの処理を示すフローチャートである。
【００４５】
Ｃｏｒｅ ＯＸＣは、Ｉｎｇｒｅｓｓ ＯＸＣとＥｇｒｅｓｓ ＯＸＣ間の経路の中間に位置するＯＸＣであった。
【００４６】
したがって、パスの上流にある（Ｉｎｇｒｅｓｓ ＯＸＣまたはＣｏｒｅ ＯＸＣである）ＯＸＣからＬａｂｅｌ Ｒｅｑｕｅｓｔを受信することになる。
【００４７】
Ｃｏｒｅ ＯＸＣのＧＭＰＬＳ制御プログラム４１は、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを受信すると（ステップ１１１）、Ｉｎｇｒｅｓｓ ＯＸＣでの処理（ステップ１０２〜１０３）と同様に、セットされたＤＡをキーにしてフォワーディングＤＢをサーチし、Ｌａｂｅｌ Ｒｅｑｕｅｓｔ送信先のＧＭＰＬＳコントローラのＩＰアドレスと、送信先ＧＭＰＬＳコントローラのＩＰアドレスから方路管理テーブルをサーチし送信方路番号を取得する（ステップ１１２，１１３）。そして、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを送信し（ステップ１１４）、ＬａｂｅｌＭａｐｐｉｎｇの受信待ちとなる（ステップ１１５）。
【００４８】
パスの下流にあたるＯＸＣ（Ｃｏｒｅ ＯＸＣまたはＥｇｒｅｓｓ ＯＸＣである）Ｌａｂｅｌ Ｍａｐｐｉｎｇを受信すると、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを受信した方路のラベル状態管理テーブルを参照し、入力チャネルを確保する（ステップ１１６）。Ｌａｂｅｌ Ｒｅｑｕｅｓｔ受信方路番号は、図６に示した方路管理テーブルからＬａｂｅｌ Ｒｅｑｕｅｓｔ送信元アドレスと一致する方路をサーチすることで確認できる。
【００４９】
チャネルの状態は、「空き」、「使用中」、「異常」、「予約中」の四種類あるが、ＧＭＰＬＳコントローラは、ここで空き状態のチャネルを確保し、確保した入力チャネルに該当する図７に示したラベル状態管理テーブルのチャネル状態７２を、「空き」から「使用中」に変更する。そして、入力チャネル確保後、光スイッチ部に対し、光パス生成要求をおこなう（ステップ１１７）。入力の方路、チャネル番号には、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを受信した方路番号と、ステップ１１６で確保した入力チャネルの番号を指定し、出力の方路、チャネル番号には、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを送信した方路番号と、受信したＬａｂｅｌＭａｐｐｉｎｇにセットされたチャネル番号を指定する。
【００５０】
光パス管理テーブルを更新（ステップ１１８）した後、確保した入力チャネル番号をＬａｂｅｌ Ｍａｐｐｉｎｇにセットして、Ｌａｂｅｌ Ｒｅｑｕｅｓｔ送信元のパスの上流のＯＸＣのＧＭＰＬＳコントローラに送信する。
【００５１】
光パス管理テーブル更新処理（ステップ１１８）は、Ｉｎｇｒｅｓｓ ＯＸＣでの処理（ステップ１０７）と同様であり、異なるのは、パス識別コードのセットが「ｃｏｒｅ」を表すコードになることだけである。
（Ｃ）Ｅｇｒｅｓｓ ＯＸＣでの光パス生成処理
次に、図１２を用いてＥｇｒｅｓｓ ＯＸＣで光パスを生成するときの処理について説明する。
図１２は、ＯＸＣで光パスを生成するときのＥｇｒｅｓｓ ＯＸＣの処理を示すフローチャートである。
【００５２】
Ｅｇｒｅｓｓ ＯＸＣは、光パスの出口にあたるＯＸＣであり、宛先の送信先ルータに接続されているＯＸＣであった。
【００５３】
Ｅｇｒｅｓｓ ＯＸＣのＧＭＰＬＳ制御プログラム４１は、パスの上流のＯＸＣ（Ｉｎｇｒｅｓｓ ＯＸＣまたはＣｏｒｅ ＯＸＣである）からＬａｂｅｌ Ｒｅｑｕｅｓｔを受信すると（ステップ１２１）、セットされたＤＡをキーにしてフォワーディングＤＢをサーチする。ただし、ＤＡのＩＰアドレスを持つルータは自ＯＸＣに接続されていることが分かるので、自らがＥｇｒｅｓｓ ＯＸＣであると判定して、Ｌａｂｅｌ Ｒｅｑｕｅｓｔの送信はおこなわれない（ステップ１２２）。
【００５４】
自らがＥｇｒｅｓｓ ＯＸＣの判定した後、Ｌａｂｅｌ Ｒｅｑｕｅｓｔを受信した方路のラベル状態管理テーブルを参照し、空き状態の入力チャネルを確保する。確保したチャネルの状態は、「空き」から「使用中」に更新して、ラベル状態管理テーブルのチャネル状態７２の値をセットする（ステップ１２３）。そして、ＧＭＰＬＳコントローラは、光スイッチ部に対し、光パス設定要求をおこなう（ステップ１２４）。
【００５５】
このとき、入力の方路、チャネル番号にＬａｂｅｌ Ｒｅｑｕｅｓｔを受信した方路番号と、ステップ１２３で確保した受信チャネル番号を指定し、出力の方路、チャネル番号にＤＡの方路番号とチャネル番号を指定する。
【００５６】
次に、光パス管理テーブルを更新し（ステップ１２５）、確保した入力チャネル番号をＬａｂｅｌ Ｍａｐｐｉｎｇメッセージにセットして、Ｌａｂｅｌ Ｒｅｑｕｅｓｔ送信元であるパスの上流のＯＸＣのＧＭＰＬＳコントローラに送信する（ステップ１２６）。
【００５７】
光パス管理テーブル更新処理は、ＩｎｇｒｅｓｓとＣｏｒｅ ＯＸＣでの処理（ステップ１０７，１１８）と同様であり、異なるのは、パス識別コードのセットが「Ｅｇｒｅｓｓ」を表すコードになることだけである。
（III）光パスの障害回復処理
次に、図１３および図１９を用いて本発明の光クロスコネクト網の光パスに障害が起こったときの障害回復処理について説明する。
【００５８】
以下、光クロスコネクト網の光パスに障害が起こったときの障害回復処理について、光スイッチ部主体でバックアップパスへの切替えをおこなう場合と、ＧＭＰＬＳコントローラ主体でバックアップパスへの切替えをおこなう場合について項をわけて説明する。
（Ａ）光スイッチ部主体でバックアップパスへの切替えをおこなう場合
先ず、図１３ないし図１６を用いて光スイッチ部主体でバックアップパスへの切替えをおこなう場合について説明する。
図１３は、光スイッチ部主体でバックアップパスへの切替えをおこなう例の説明図である。
図１４は、イベントフォーマットの模式図である。
図１５は、バックアップパス通知フォーマットの模式図である。
図１６は、本発明の第一の実施形態に係るＧＭＰＬＳコントローラがイベントを受信したときの障害回復の処理を示すフローチャートである。
【００５９】
この場合は、光パスに障害が起こり通信ができなくなったときで、光スイッチ部のみでバックアップパスへの切替えがおこなえる場合であり、例えば、通信をおこなっている光パスのファイバーは使えるが、該当するチャネルに障害がおこったときで、他のチャネルは使用できる場合である。
【００６０】
このときには、光スイッチ部のＯＸＣ監視・制御プログラム４４の動作により、光スイッチ部のみで、障害が発生したＯＸＣ間での障害回復をおこなうことになる。なお、この実現方法については、例えば、ＳＤＨ伝送のＡＰＳバイト等を用いて実現するものとする。
【００６１】
本実施形態では、障害が発生したＯＸＣ間で、元の光パスと異なった空きチャネルが使用可能な場合であって、光スイッチ部のＯＸＣ監視・制御プログラム４４の動作のみで、他の空きチャネルへの切替えがおこなえるものとする。
【００６２】
例えば、図１３に示すような網の構成において、ＯＸＣ２とＯＸＣ３間のチャネル番号１に障害が発生したとき、空き状態であるチャネル番号３への切替えがおこなえるものとする。
【００６３】
このとき、光スイッチ部のＯＸＣ監視・制御プログラム４４は、障害時、ならびに、障害回復時、入・出力のチャネル単位でイベント情報をＧＭＰＬＳ制御プログラム４１に通知する。
【００６４】
このときのイベントフォーマットは、図１４に示すようにイベントコード（フィールド１４１）、入出力コード（フィールド１４２）、イベント発生方路番号とイベント発生チャネル番号（フィールド１４３，１４４）、切替えコード（フィールド１４５）、および、切替方路番号、チャネル番号（フィールド１４６，１４７）をセットするエリアで構成される。
【００６５】
イベントコードは、イベントが障害発生か障害回復かを識別するコードである。入出力コードは、イベントが入力チャネルか出力チャネルかを識別するコードである。切替えコードは、切替えがおこなわれたか否かを識別するためのコードであり、「切替え実施」、「切替え不可」、「切替え不要」の三つの状態を持つ。ここで、「切替え実施」、「切替え不可」は、光スイッチ部がバックアップパスへの切替えをおこなったか、できなかったかを表す。また、「切替え不要」は、パスが設定されておらず、未使用中のチャネルであって、切替えをおこなう必要がない場所に対する障害を表す。
【００６６】
図１３に示されるようにＩｎｇｒｅｓｓ ＯＸＣのＯＸＣ１、Ｃｏｒｅ ＯＸＣのＯＸＣ２、Ｅｇｒｅｓｓ ＯＸＣのＯＸＣ３が接続されているときに、ＯＸＣ２のチャネル番号１とＯＸＣ３のチャネル番号１の間の経路で障害が起こったものとする。ここで、プライマリーパスと呼んでいるのは、バックアップパスに対する概念であり、障害がおこる前に最初に使用されていた元の光パスである。
【００６７】
この例では、ＯＸＣ２とＯＸＣ３の間でＯＸＣ２のチャネル番号３とＯＸＣ３のチャネル番号３のバックアップパスに切替えている。バックアップパスのための切替えの方路と、チャネル番号を確保するには、二通りのやり方が考えられる。
【００６８】
一つは、光スイッチ部のＯＸＣ監視・制御プログラム４４が自ら探して確保する方法であり、また、今一つは、ＧＭＰＬＳコントローラが光スイッチ部に対して、図１５に示されたようなバックアップ通知フォーマットにより通知された切替え方路番号（フィールド１３６）と、切替えチャネル番号（フィールド１３７）の内容を保持しておいて、障害が起こったときにこの情報を利用してバックアップパスに切替える方法である。
【００６９】
切替えが終わると、ＯＸＣ２，３の各光スイッチ部はこれらの情報を、図１４に示すフォーマットで、各ＧＭＰＬＳコントローラにイベントとして通知する。
【００７０】
ＧＭＰＬＳコントローラ５１内のＧＭＰＬＳ制御プログラム４１は、イベントを受信すると図１５のフローチャートに示された処理を実行する。
【００７１】
先ず、イベントを受信すると（ステップ１５０）、イベントの入出力コードと、発生方路番号からＷＤＭ回線の入力チャネルに対するイベントか否かチェックする（ステップ１５１）。
【００７２】
障害が起こった回線がＷＤＭ回線か否かのチェックは、イベント発生方路が方路管理テーブルに登録されているか否かによって判断できる。そして、ＷＤＭ回線の入力チャネルの場合には、イベントコードに応じて下記のようにラベル状態管理テーブルの更新処理（ステップ１５２）をおこなう。
【００７３】
イベントコードが「障害」の場合、障害が発生した方路番号とチャネル番号をキーにして、ラベル状態管理テーブルを参照し、障害が発生した入力チャネルの状態を「使用中」から「異常」に更新する。そして、切替えコードが、「切替え実施」状態の場合は、さらに切替えた入力チャネルの状態を「空き」から「使用中」に更新する。また、イベントコードが「障害回復」の場合、回復した方路番号とチャネル番号をキーにして、ラベル状態管理テーブルを参照し、回復したチャネルの状態を「異常」から「空き」に更新する。
【００７４】
次に、イベントコードをチェックし（ステップ１５３）、「障害回復」の場合は処理を終了する。
【００７５】
イベントコードが、「障害」のときには、切替えコードを判定する（ステップ１５４）。
【００７６】
切替えコードが、「切替え不要」であればそのまま処理を終了し、「切替え実施」であれば、光パス管理テーブルの更新処理をおこなう（ステップ１５５）。ここでの更新処理は、入出力コード１４２、イベント発生した方路番号１４３、イベント発生したチャネル番号１４４、切替え方路番号１４６、切替えチャネル番号１４７を参照して、新しいバックアップパスの方路番号、チャネル番号を設定する。
【００７７】
以上の処理によって、光スイッチ部による切替えが可能な障害の場合、障害がおこってもバックアップパスへの高速の切替えがおこなえるとともに、ＧＭＰＬＳコントローラで保持するラベル状態管理テーブルも光スイッチ部の状態とあわせて更新でき、かつ、切替えられた光パスの情報も更新できる。同様に障害回復時や、切替え不要な障害の場合についても、ラベル状態管理テーブルを光スイッチ部の状態とあわせて更新できる。
（Ｂ）ＧＭＰＬＳコントローラ部主体でバックアップパスへの切替えをおこなう場合
次に、先の図１６と、図１７ないし図１９を用いて光スイッチ部主体でバックアップパスへの切替えをおこなう場合について説明する。
図１７は、ＧＭＰＬＳコントローラ主体でバックアップパスへの切替えをおこなう例の説明図である。
図１８は、Ｌａｂｅｌ ＷｉｔｈＤｒａｗメッセージを受信したＯＸＣのＧＭＰＬＳコントローラの処理を示すフローチャートである。
図１９は、Ｌａｂｅｌ Ｒｅｌｅａｓｅメッセージを受信したＯＸＣのＧＭＰＬＳコントローラの処理を示すフローチャートである。
【００７８】
この場合は、光パスに障害が起こり通信ができなくなったときで、光スイッチ部のみでバックアップパスへの切替えがおこなえなくなった場合であり、例えば、通信をおこなっている光パスのファイバーが切断された状態になり、該当する経路では通信ができなくなって目的の通信をおこなうために迂回する経路が必要になったときである。
【００７９】
ここでは、例えば、図１７に示されるようにＯＸＣ２とＯＸＣ３との間のＷＤＭ回線が全て障害になったとする。
【００８０】
障害がおこったときには、ＯＸＣ２の光スイッチ部は、出力のチャネル番号１が障害であること、ＯＸＣ３の光スイッチ部は、入力のチャネル番号１が障害であることを、また、切替えの状態が「切替え不可」であることを、自らのＧＭＰＬＳコントローラに通知する。
【００８１】
ＧＭＰＬＳコントローラ５１内のＧＭＰＬＳ制御プログラム４１は、イベントを受信すると（ステップ１５０）、イベントの入出力コードと、発生方路番号からＷＤＭ回線の入力チャネルに対するイベントか否かチェックする（ステップ１５１）。
【００８２】
この場合に、ＯＸＣ３の障害の方が、ＷＤＭ回線の入力チャネルの障害になるので（ステップ１５１）、既に説明したように、ＯＸＣ３のＧＭＰＬＳコントローラは、ラベル状態管理テーブルの入力チャネル番号７１のチャネル状態７２を「障害中」に書換える（ステップ１５２）。
【００８３】
次に、イベントコードをチェックし（ステップ１５３）、イベントコードが、「障害」のときには、切替えコードを判定する（ステップ１５４）。
【００８４】
そして、切替えコードが「切替え不可」なので、障害が発生した光パスをいったん、削除する。
【００８５】
そのために、入出力コード、障害のあった方路番号、チャネル番号をキーして光パス管理テーブルから対象の光パスを検索し、光パスＩＤと、入・出力の方路番号を取得し、該当するエントリーを削除する（ステップ１５６）。そして、障害が発生した光パスの削除要求をおこなう（ステップ１５７）。
【００８６】
光クロスコネクト網で光パスを削除すために、障害が発生したチャネルが入力の場合には、ＧＭＰＬＳコントローラは、Ｌａｂｅｌ Ｒｅｌｅａｓｅメッセージ（以下、「Ｌａｂｅｌ Ｒｅｌｅａｓｅ」と呼ぶ）をＥｇｒｅｓｓ側ＯＸＣのＧＭＰＬＳコントローラに送信する。反して、障害が発生したチャネルが出力の場合には、ＧＭＰＬＳコントローラは、Ｉｎｇｒｅｓｓ側ＯＸＣのＧＭＰＬＳコントローラにＬａｂｅｌ Ｗｉｔｈｄｒａｗメッセージ（以下、「Ｌａｂｅｌ Ｗｉｔｈｄｒａｗ」と呼ぶ）を送信する。
【００８７】
ここで、Ｌａｂｅｌ Ｒｅｌｅａｓｅ、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗは、ＧＭＰＬＳの標準シーケンスとして規定されているものであり、Ｌａｂｅｌ Ｒｅｌｅａｓｅは、Ｉｎｇｒｅｓｓ側からＥｇｒｅｓｓ側に送信されるＧＭＰＬＳのメッセージであり、正常時にも用いられるパス削除要求である。Ｌａｂｅｌ Ｗｉｔｈｄｒａｗは、Ｅｇｒｅｓｓ側からＩｎｇｒｅｓｓ側に向けて送信される異常時のパス削除要求である。Ｌａｂｅｌ ＲｅｌｅａｓｅとＬａｂｅｌ Ｗｉｔｈｄｒａｗの送信先ＧＭＰＬＳコントローラのＩＰアドレスについては、障害のあった光パスの入・出力方路番号から方路管理テーブルを参照することで取得できる。なお、Ｉｎｇｒｅｓｓ、および、Ｅｇｒｅｓｓ ＯＸＣについては、光パスの端点であり、Ｌａｂｅｌ Ｒｅｌｅａｓｅ、および、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗの送信はおこなわない。
【００８８】
図１７に示した本実施形態の例では、ＯＸＣ２のＧＭＰＬＳコントローラは、ＯＸＣ１に対してＬａｂｅｌ Ｗｉｔｈｄｒａｗを送信し、ＯＸＣ３のＧＭＰＬＳコントローラは、Ｅｇｒｅｓｓ ＯＸＣであり、Ｌａｂｅｌ Ｒｅｌｅａｓｅの送信はおこなわない。
【００８９】
Ｌａｂｅｌ Ｒｅｌｅａｓｅと、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗには、削除する光パスＩＤをセットし、この値によって削除する光パスが特定される。Ｌａｂｅｌ Ｒｅｌｅａｓｅ、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗの処理の詳細は、後に説明する。
【００９０】
そして、Ｉｎｇｒｅｓｓ ＯＸＣの場合には（ステップ１５８）、削除した光パスと同一のＳＡ，ＤＡに対して再度、光パスの生成処理をおこなう（ステップ１５９）。このとき、フォワーディングＤＢは既に、ルーティングプロトコルによって障害時の状態が反映され、ＤＡへの光パスの経路（方路）は障害箇所を迂回するように更新されているものとする。Ｉｎｇｒｅｓｓ ＯＸＣからのＬａｂｅｌ Ｒｅｑｕｅｓｔは、障害を迂回するＯＸＣに順次送信され、ＥｇｒｅｓｓＯＸＣまで到達される。すなわち、本実施形態の考え方は、障害時のバックアップパスをルーティングプロトコルによって作成させるものであると言える。
【００９１】
図１７に示した本実施形態の場合には、Ｌａｂｅｌ Ｒｅｑｕｅｓｔは、ＯＸＣ１からＯＸＣ４に、ＯＸＣ４からＯＸＣ５に、ＯＸＣ５からＯＸＣ３にそれぞれ送信される。
【００９２】
Ｉｎｇｒｅｓｓ、Ｃｏｒｅ、Ｅｇｒｅｓｓ ＯＸＣでは、それぞれ、図１０により説明したＩｎｇｒｅｓｓ ＯＸＣでの光パス生成要求受付け処理、図１１により説明したＣｏｒｅ ＯＸＣでのＬａｂｅｌ Ｒｅｑｕｅｓｔ受信処理、図１２により説明したＥｇｒｅｓｓ ＯＸＣでのＬａｂｅｌ Ｒｅｑｕｅｓｔ受信処理をおこなうことで、障害のバックアップパスとして、ＳＡからＤＡへの光パスが生成される。
【００９３】
なお、Ｉｎｇｒｅｓｓ ＯＸＣにおける光パスＩＤ生成処理（ステップ１０１）については、障害で削除された光パスＩＤとは、異なる光パスＩＤを割り当てることとする。これは、障害による光パス削除処理と、光パスの再生成処理が競合するのを防ぐためである。
【００９４】
次に、図１８を用いてＬａｂｅｌ Ｗｉｔｈｄｒａｗを受信したときのＧＭＰＬＳのＧＭＰＬＳ制御プログラム４１の処理について説明する。
【００９５】
先ず、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗを受信すると（ステップ１７１）、セットされたパスＩＤをキーにして光パス管理テーブルを参照し、設定していたスイッチの開放処理を光スイッチ部に要求する（ステップ１７２）。そして、開放したＷＤＭ回線の入力チャネルについて、ラベル状態管理テーブルのチャネル状態を「使用中」から「空き」の状態に更新する（ステップ１７３）。また、削除要求のあった光パスのエントリーを光パス管理テーブルから削除する（ステップ１７４）。
【００９６】
そして、そのＯＸＣのタイプを判定し（ステップ１７５）、Ｉｎｇｒｅｓｓ ＯＸＣの場合には、処理を終了し、Ｉｎｇｒｅｓｓ ＯＸＣでない場合は、Ｉｎｇｒｅｓｓ側ＯＸＣのＧＭＰＬＳコントローラに対して、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗを送信する（ステップ１７６）。
【００９７】
次に、図１９を用いてＬａｂｅｌ Ｒｅｌｅａｓｅを受信したときのＧＭＰＬＳのＧＭＰＬＳ制御プログラム４１の処理について説明する。
【００９８】
先ず、Ｌａｂｅｌ Ｒｅｌｅａｓｅを受信すると（ステップ１８１）、セットされたパスＩＤをキーにして光パス管理テーブルを参照し、設定していたスイッチの開放処理を光スイッチ部に要求する（ステップ１８２）。そして、ＷＤＭ回線の入力チャネルについて、ラベル状態管理テーブルのチャネル状態を「使用中」から「空き」の状態に更新する（ステップ１８３）。また、削除要求のあった光パスのエントリーを光パス管理テーブルから削除する（ステップ１８４）。
【００９９】
そして、そのＯＸＣのタイプを判定し（ステップ１８５）、Ｅｇｒｅｓｓ ＯＸＣの場合には、処理を終了し、Ｅｇｒｅｓｓ ＯＸＣでない場合は、Ｅｇｒｅｓｓ側ＯＸＣの次のＧＭＰＬＳコントローラに対して、Ｌａｂｅｌ Ｒｅｌｅａｓｅを送信する（ステップ１８６）。
これらの処理によって、光スイッチ部による切替えが不可能な障害の場合、いったん、障害によって切断された光パスの削除処理がおこなわれ、使用していたＷＤＭ回線の入力チャネル（ラベル）の開放処理がおこなわれる。そして、Ｉｎｇｒｅｓｓ ＯＸＣにおいて、再度、光パスの生成処理が実行されることでリカバリーがおこなわれる。
【０１００】
以上の光パス生成処理、障害時のリカバリー処理、光パス削除処理によって、ユーザに対して信頼性の高い光パスを効率よく提供することができる。
【０１０１】
〔実施形態２〕
以下、本発明に係る第二の実施形態を、図２０および図２１を用いて説明する。
図２０は、光パス管理テーブルの追加フィールドの模式図である。
図２１は、本発明の第二の実施形態に係るＧＭＰＬＳコントローラがイベントを受信したときの障害回復の処理を示すフローチャートである。
【０１０２】
第一の実施形態では、光スイッチ部でのリカバリーがおこなえない場合には、障害が起きた光パスをＬａｂｅｌ Ｒｅｌｅａｓｅと、Ｌａｂｅｌ Ｗｉｔｈｄｒａｗにより削除して、新たにＯＸＣ間でＬａｂｅｌ Ｒｅｑｕｅｓｔによりバックアップパスを張りなおすものであった。
【０１０３】
本実施形態は、ＧＭＰＬＳコントローラが予め確保しておいたバックアップパスを、光スイッチ部に通知することにより、バックアップパスを生成して障害回復をおこなおうとするものである。
【０１０４】
光パス管理サーバ４は、ユーザからパス生成要求を受付けると、現用のプライマリーパスの生成要求をおこなうことは第一の実施形態と同様であるが、それに加えてバックアップパスの生成要求をＯＸＣ１１〜１５に対しておこなう。
【０１０５】
また、第一の実施形態、光パスの径路はルーティングプロトコル４２が作成するフォワーディングＤＢ４３に従って生成していたが、第一の実施形態では、光パス管理サーバ４がパス径路を指定することにする。これは、ＧＭＰＬＳシグナリングプロトコル（ＣＲ−ＬＤＰ，ＴＥ−ＲＳＶＰ）はパス径路を指定できるので、その機能を用いて実現することができる。
【０１０６】
以下、プライマリーパスとバックアップパスの生成について項を分けて説明する。
（I）プライマリーパスの生成処理
先ず、プライマリーパスの生成処理から説明する。
【０１０７】
Ｉｎｇｒｅｓｓ、Ｃｏｒｅ、Ｅｇｒｅｓｓ ＯＸＣにおけるプライマリーパスの生成処理は、第一の実施形態の光パス生成処理（図１０、図１１、図１２）と基本的には同一シーケンスであり、以下に第一の実施形態と異なる処理についてのみ説明することにする。
【０１０８】
光パス管理サーバ４は、送信先のルータに接続されているＩｎｇｒｅｓｓ ＯＸＣに対して、ＳＡとＤＡ、プライマリーパスの径路、パススイッチＯＸＣとパスマージＯＸＣを指定する。パス径路については、Ｉｎｇｒｅｓｓ ＯＸＣから、Ｅｇｒｅｓｓ ＯＸＣに至るまでに通過するＧＭＰＬＳコントローラのＩＰアドレスを順番に指定する。このパス経路の指定、および、パススイッチＯＸＣ、パスマージＯＸＣで、ＯＸＣの識別子として使用しているのは、ＯＸＣ内のＧＭＰＬＳコントローラのＩＰアドレスである。
【０１０９】
またここで、パススイッチＯＸＣとは、プライマリーパスとバックアップパスが分岐するＯＸＣのことであると定義し、パスマージＯＸＣとは、プライマリーパスとバックアップパスが合流するＯＸＣのことであると定義する。
【０１１０】
図１７に示したプライマリーパスとバックアップパスとＯＸＣの関係を例にとれば、パススイッチＯＸＣはＯＸＣ１であり、パスマージＯＸＣはＯＸＣ３となる。
【０１１１】
光パス管理サーバ４が指定した径路は、Ｉｎｇｒｅｓｓ ＯＸＣによって、Ｌａｂｅｌ Ｒｅｑｕｅｓｔに付加され送信される。そしてＣｏｒｅ ＯＸＣでは、この径路情報をＬａｂｅｌ Ｒｅｑｕｅｓｔに付加し送信していく。
【０１１２】
第一の実施形態では、Ｉｎｇｒｅｓｓ 、Ｃｏｒｅ ＯＸＣの光パス生成処理（図１０、図１１）において、Ｌａｂｅｌ Ｒｅｑｕｅｓｔ送信先を決定する際、フォワーディングＤＢをサーチしていたが（ステップ１０２，１１２）、第二の実施形態では、光パス管理サーバ４が指定した径路、または、Ｌａｂｅｌ Ｒｅｑｕｅｓｔにセットされた径路情報から決定するように変更する。また、光パス管理サーバ４が指定したパススイッチＯＸＣ、パスマージＯＸＣの情報についても、Ｌａｂｅｌ Ｒｅｑｕｅｓｔに付加され、プライマリーパス径路上の全ＯＸＣに通知される。
【０１１３】
プライマリパスの生成時に、光パス管理テーブルにパラメタをセットしなければならないが、本実施形態のＧＭＰＬＳコントローラが用いる光パス管理テーブルは、第一の実施形態の図８に示した光パス管理テーブルに対して、図２０に示されたフィールド２０１〜２０４が追加されるたものである。。
【０１１４】
パススイッチＯＸＣ（フィールド２０１）と、パスマージＯＸＣ（フィールド２０２）については、上記のようにＬａｂｅｌ Ｒｅｑｕｅｓｔに付加されて通知されるものであり、Ｉｎｇｒｅｓｓ、Ｃｏｒｅ、Ｅｇｒｅｓｓ ＯＸＣにおいて、プライマリパス生成時のそれぞれの光パス管理テーブル更新処理（ステップ１０７，１１８，１２５）でセットされる。
【０１１５】
切替え方路番号と切替えチャネル番号（フィールド２０３，２０４）は、バックアップパスとして切替える方路番号とチャネル番号であり、後述するバックアップパスの生成処理にてセットされる。なおこれが有効になるのは、分岐するＯＸＣであるパススイッチＯＸＣと、パスマージＯＸＣのみであり、プライマリパスとバックアップパスが分岐しない他のＯＸＣではこのパラメタは意識することはない。
【０１１６】
以上の処理によって、光パス管理サーバ４が指定した径路でＳＡ，ＤＡ間にプライマリーパスが生成される。また、パス管理テーブルのエントリーにパススイッチＯＸＣと、パスマージＯＸＣの情報がそれぞれセットされる。
（II）バックアップパスの生成処理
次にバックアップパスの生成処理について説明する。
【０１１７】
パス管理サーバ４は、プライマリ生成要求の後に、パススイッチＯＸＣに対して、バックアップパスの径路、対応するプライマリーパスのパスＩＤを指定し、バックアップパスの生成要求をおこなう。
【０１１８】
ここで、バックアップパスの径路情報、プライマリーパスのパスＩＤは、Ｌａｂｅｌ Ｒｅｑｕｅｓｔに付加され送信される。
【０１１９】
バックアップパスのＩｎｇｒｅｓｓ、Ｃｏｒｅ、Ｅｇｒｅｓｓ ＯＸＣは、プライマリーパスの生成処理と同様に処理をおこなう。ここで、バックアップパスのＩｎｇｒｅｓｓ ＯＸＣとは、パススイッチＯＸＣのことであり、Ｅｇｒｅｓｓ ＯＸＣとは、パスマージＯＸＣのことである。パススイッチＯＸＣとパスマージＯＸＣでは、パス管理テーブルから対応するプライマリーパスのエントリーをサーチし、バックアップパスへの切替え情報として切替え方路番号と切替えチャネル番号をフィールド２０３，２０４にセットする。このとき、パススイッチＯＸＣではバックアップパスの出力の方路番号とチャネル番号をセットし、パスマージＯＸＣではバックアップパスの入力の方路番号とチャネル番号をセットする。
【０１２０】
このパックアップパスの生成処理の段階では、障害がおこっていないので、パススイッチＯＸＣと、パスマージＯＸＣのＧＭＰＬＳコントローラは、実際に光スイッチ部へのパス生成要求はおこなわない。光スイッチ部へのパス生成要求がおこなわれるのは、次の項の障害が発生したときである。
【０１２１】
なお、パスマージＯＸＣの入力チャネル（ラベル）確保処理については、実際にパス設定はおこなわないので、ラベル状態管理テーブルのチャネル状態は「予約中」とする。
【０１２２】
以上の処理によって、光パス管理サーバ４が指定したパススイッチＯＸＣとパスマージＯＸＣ間の指定径路でバックアップパスが生成される。そして、パススイッチＯＸＣとパスマージＯＸＣにおいて、バックアップパスへの切替え情報がパス管理テーブルにセットされる。
【０１２３】
バックアップパスのリソース（ラベル）については、「使用中」、または、「予約中」となっており、別ユーザからの光パス生成要求によってＧＭＰＬＳコントローラが使用することはない。また、光スイッチ部も、「予約中」の入力チャネルの情報を把握していないが、入力チャネルと対向側の出力チャネルについては、既にパス設定がおこなわれており、光スイッチ部が自立的に予約中のチャネルを使用することはない。
（III）障害が発生したときの処理
次に、障害が発生したときのＧＭＰＬＳコントローラの処理について説明する。
【０１２４】
これは、プライマリーパスに障害が発生し、ＧＭＰＬＳコントローラにて、バックアップパスへ切替えるまでの処理である。
【０１２５】
光スイッチ部単独での切替え可能な障害の場合については、第一の実施形態と同様であり、本実施形態で問題となるのはＧＭＰＬＳコントローラ部主体でバックアップパスへの切替えをおこなう場合である。
【０１２６】
障害発生時、第一の実施形態と同様に、イベント情報がＧＭＰＬＳコントローラに通知される。
【０１２７】
そして、ＧＭＰＬＳコントローラ内のＧＭＰＬＳ制御プログラム４１はイベントを受信すると、図２２のフローチャートに示される処理を実行する。
【０１２８】
切替えコードが「切替え不可」のイベント処理以外（ステップ２１０〜２１５）については、図１６に示した第一の実施形態１の処理（ステップ１５０〜１５５）と同一であるので、切替えコードが「切替え不可」の場合のみ説明することにする。
【０１２９】
切替えコードが「切替え不可」の場合には（ステップ２１４）、障害が発生したＯＸＣがパススイッチＯＸＣあるいは、パスマージＯＸＣかをチェックする（ステップ２１６）。これは、光パス管理テーブルから障害発生パスに対応するパススイッチＯＸＣ、パスマージＯＸＣを参照し、自ＧＭＰＬＳコントローラのＩＰアドレスと一致するか否かをチェックすることで判断できる。
【０１３０】
障害が発生したＯＸＣがパススイッチＯＸＣ、あるいは、パスマージＯＸＣの場合には、光パス管理テーブルの切替え情報を参照し、光スイッチ部に対し切替え要求をおこなう（ステップ２１７）。
【０１３１】
パススイッチＯＸＣでも、パスマージＯＸＣでもない場合には、ｎｏｔｉｆｉｃａｔｉｏｎメッセージ（以下、単に「ｎｏｔｉｆｉｃａｔｉｏｎ」と呼ぶ）を隣接するＧＭＰＬＳコントローラに送信する（ステップ２１８）。
【０１３２】
ｎｏｔｉｆｉｃａｔｉｏｎは、ＣＲ−ＬＤＰに規定されているイベント通知用のメッセージである。ｎｏｔｉｆｉｃａｔｉｏｎに障害が発生した光パスＩＤを付加することで、障害発生パスをパススイッチＯＸＣ、パスマージＯＸＣに通知する。ｎｏｔｉｆｉｃａｔｉｏｎ送信先は、障害発生方路がＩｎｇｒｅｓｓ側かＥｇｒｅｓｓ側かによって異なる。Ｉｎｇｒｅｓｓ側ならば、Ｅｇｒｅｓｓ側の方向に位置する隣接するＧＭＰＬＳコントローラに送信し、Ｅｇｒｅｓｓ側であれば、Ｉｎｇｒｅｓｓ側の方向に位置するＧＭＰＬＳコントローラに送信する。
【０１３３】
ｎｏｔｉｆｉｃａｔｉｏｎを受信したＧＭＰＬＳコントローラ内のＧＭＰＬＳ制御プログラム４１は、図２１に示した処理（ステップ２１６〜２１８）と同様の処理をおこなう。自ＯＸＣがパススイッチＯＸＣか、もしくは、パスマージＯＸＣかをチェックする。そして、バックアップパスへの切替え、または、ｎｏｔｉｆｉｃａｔｉｏｎの送信処理をおこなう。
【０１３４】
ｎｏｔｉｆｉｃａｔｉｏｎの送信先は、Ｉｎｇｒｅｓｓ側から受信した場合は、Ｅｇｒｅｓｓ側の方向に位置する隣接ＧＭＰＬＳコントローラに、Ｅｇｒｅｓｓ側から受信した場合は、Ｉｎｇｒｅｓｓ側の方向に位置する隣接ＧＭＰＬＳコントローラに送信することは同様である。
【０１３５】
このようにして、ｎｏｔｉｆｉｃａｔｉｏｎは、障害発生したＯＸＣから、ＩｎｇｒｅｓｓとＥｇｒｅｓｓ側ＯＸＣに向けｈｏｐ−ｂｙ−ｈｏｐで伝搬されていき、パススイッチＯＸＣ、パスマージＯＸＣに伝わる。そして、障害が起こった光パスがバックアップパスに切替えられて、リカバリーがおこなわれる。
【０１３６】
【発明の効果】
本発明によれば、ＧＭＰＬＳにより光パスの制御をおこなう光クロスコネクト網で、光スイッチ部のみで高速に障害回復をおこなえるようにするとともに、光スイッチ部のみで障害回復がおこなえないときには、ＧＭＰＬＳ制御部の制御により障害の回復をおこなうようにして、多様な光クロスコネクト網の接続形態に対応できる光クロスコネクト網の障害回復方法を提供することができる。
【図面の簡単な説明】
【図１】本発明の光クロスコネクト網のネットワーク構成図である。
【図２】本発明の光クロスコネクト網の詳細な構成図である。
【図３】光スイッチ部での通信を説明するための図である。
【図４】光クロスコネクト監視・制御ソフトウェア構成を説明するための図である。
【図５】接続ルータ管理テーブルの構造を示す模式図である。
【図６】方路管理テーブルの構造を示す模式図である。
【図７】ラベル状態管理テーブルの構造を示す模式図である。
【図８】光パス管理テーブルの構造を示す模式図である。
【図９】フォワーディングＤＢ構造を示す模式図である。
【図１０】ＯＸＣで光パスを生成するときのＩｎｇｒｅｓｓ ＯＸＣの処理を示すフローチャートである。
【図１１】ＯＸＣで光パスを生成するときのＣｏｒｅ ＯＸＣの処理を示すフローチャートである。
【図１２】ＯＸＣで光パスを生成するときのＥｇｒｅｓｓ ＯＸＣの処理を示すフローチャートである。
【図１３】光スイッチ部主体でバックアップパスへの切替えをおこなう例の説明図である。
【図１４】イベントフォーマットの模式図である。
【図１５】バックアップパス通知フォーマットの模式図である。
【図１６】本発明の第一の実施形態に係るＧＭＰＬＳコントローラがイベントを受信したときの障害回復の処理を示すフローチャートである。
【図１７】ＧＭＰＬＳコントローラ主体でバックアップパスへの切替えをおこなう例の説明図である。
【図１８】Ｌａｂｅｌ ＷｉｔｈＤｒａｗメッセージを受信したＯＸＣのＧＭＰＬＳコントローラの処理を示すフローチャートである。
【図１９】Ｌａｂｅｌ Ｒｅｌｅａｓｅメッセージを受信したＯＸＣのＧＭＰＬＳコントローラの処理を示すフローチャートである。
【図２０】光パス管理テーブルの追加フィールドの模式図である。
【図２１】本発明の第二の実施形態に係るＧＭＰＬＳコントローラがイベントを受信したときの障害回復の処理を示すフローチャートである。
【符号の説明】
１１〜１５…光クロスコネクト、２１〜３０…ルータ、３１〜３７…ＷＤＭ回線、４…光パス管理サーバ、７１〜７３…ルータ回線。５１，５２…ＧＭＰＬＳコントローラ、６１，６２…光スイッチ部４１…ＧＭＰＬＳ制御プログラム、４２…ルーティングプロトコル、４３…フォワーディングＤＢ、４４…ＯＸＣ監視・制御プログラム。
Claims (5)
- ＧＭＰＬＳ（Generalized Multi Protocol Label Switching）により光パスの制御をおこない、光クロスコネクトにＧＭＰＬＳ制御部と光スイッチ部とを有する光クロスコネクト網の障害回復方法において、
光パスの通信に障害が起こった際に、
前記光スイッチ部によりバックアップパスを確保することが可能なときには、
前記光スイッチ部は、障害情報、切替え情報をＧＭＰＬＳ制御部に通知し、
前記ＧＭＰＬＳ制御部は、前記光スイッチ部からの障害情報、切替え情報を基にして、ラベル情報、パス管理情報を更新し、
障害が起こった光パスの通信を、前記バックアップパスによりすることによって障害回復をおこなうことを特徴とする光クロスコネクト網の障害回復方法。 - 前記ＧＭＰＬＳ制御部は、バックアップパスを確保するために前記光スイッチ部に予めラベル情報、パス管理情報を通知することを特徴とする請求項１記載の光クロスコネクト網の障害回復方法。
- 前記光スイッチ部は、障害が回復した際に、障害回復情報を前記ＧＭＰＬＳ制御部に通知し、
前記ＧＭＰＬＳ制御部は、前記ラベル情報を、空き、使用中、異常、予約中の四つの状態で管理して、かつ、前記光スイッチ部からの前記障害情報、前記切替え情報、前記障害回復情報を基に前記ラベル情報を更新することを特徴とする請求項１および請求項２記載のいずれかの光クロスコネクト網の障害回復方法。 - 前記光スイッチ部によりバックアップパスを確保することが不可能なときには、
前記光スイッチ部は、障害情報をＧＭＰＬＳ制御部に通知し、
前記ＧＭＰＬＳ制御部は、前記光スイッチ部からの障害情報を基にして、ラベル情報、パス管理情報を更新し、バックアップパスを確保して、
障害が起こった光パスの通信を、前記バックアップパスによりすることによって障害回復をおこなうことを特徴とする請求項１の光クロスコネクト網の障害回復方法。 - 前記光スイッチ部によりバックアップパスを確保することが不可能なときには、
前記ＧＭＰＬＳ制御部は、障害のあった光パスを削除して、パス生成元である光クロスコネクトにおいて、削除した光パスの再生成をおこなうことを特徴とする請求項４記載の光クロスコネクト網の網の障害回復方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002125711A JP3967954B2 (ja) | 2002-04-26 | 2002-04-26 | 光クロスコネクト網の障害回復方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002125711A JP3967954B2 (ja) | 2002-04-26 | 2002-04-26 | 光クロスコネクト網の障害回復方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003318983A JP2003318983A (ja) | 2003-11-07 |
| JP3967954B2 true JP3967954B2 (ja) | 2007-08-29 |
Family
ID=29540351
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002125711A Expired - Fee Related JP3967954B2 (ja) | 2002-04-26 | 2002-04-26 | 光クロスコネクト網の障害回復方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3967954B2 (ja) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1801802B (zh) * | 2004-12-31 | 2010-06-02 | 华为技术有限公司 | 通用多协议标签交换路径上节点重启恢复的方法 |
| JP2006319758A (ja) * | 2005-05-13 | 2006-11-24 | Mitsubishi Electric Corp | 通信装置、通信システムおよび通信プログラム |
| CN101069394B (zh) | 2005-12-05 | 2015-01-28 | 日本电信电话株式会社 | 故障补救方法和数据包通信装置 |
| JP4678778B2 (ja) * | 2006-02-28 | 2011-04-27 | Ｋｄｄｉ株式会社 | マルチレイヤネットワーク運用管理システムおよびコンピュータプログラム |
| JP4580372B2 (ja) * | 2006-08-10 | 2010-11-10 | 株式会社日立製作所 | ネットワークシステム |
| JP2008211330A (ja) * | 2007-02-23 | 2008-09-11 | Hitachi Communication Technologies Ltd | ノード制御装置およびノードシステム |
| JP4661892B2 (ja) | 2008-03-25 | 2011-03-30 | 日本電気株式会社 | 通信ネットワークシステム、通信装置、経路設計装置及び障害回復方法 |
| JP4935737B2 (ja) * | 2008-03-27 | 2012-05-23 | Ｋｄｄｉ株式会社 | 光バースト交換ネットワーク間を波長パスにより中継したシステムでの障害検出方法および障害復旧方法 |
| JP5071200B2 (ja) | 2008-03-28 | 2012-11-14 | 富士通株式会社 | 信号伝送装置 |
| JP5793955B2 (ja) * | 2011-05-20 | 2015-10-14 | 日本電気株式会社 | ノード |
| EP2922248B1 (en) * | 2012-11-16 | 2019-06-26 | Nec Corporation | Communication system, control device, method for controlling same, and program |
-
2002
- 2002-04-26 JP JP2002125711A patent/JP3967954B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003318983A (ja) | 2003-11-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2358230C (en) | Optimized fault notification in an overlay mesh network via network knowledge correlation | |
| US7881183B2 (en) | Recovery from control plane failures in the LDP signalling protocol | |
| EP2658149B1 (en) | Method and device for restoring network | |
| US7525907B2 (en) | Method, device and software for establishing protection paths on demand and revertive protection switching in a communications network | |
| EP2071772B1 (en) | Communication node apparatus, communication system, and path resource assigning method | |
| JP4661892B2 (ja) | 通信ネットワークシステム、通信装置、経路設計装置及び障害回復方法 | |
| Sengupta et al. | From network design to dynamic provisioning and restoration in optical cross-connect mesh networks: An architectural and algorithmic overview | |
| US20030117950A1 (en) | Link redial for mesh protection | |
| US20040109687A1 (en) | Fast rerouting method through generalized multi-protocol label switching | |
| US20030095500A1 (en) | Methods for distributed shared mesh restoration for optical networks | |
| JP5163479B2 (ja) | パス切替え方法 | |
| WO2004075494A1 (ja) | 通信ネットワークにおけるパスの故障救済を行うための装置及び方法 | |
| CN101095058A (zh) | 在使用标签交换协议的环形拓扑网络中保护多播业务的有效保护机制 | |
| US20080049610A1 (en) | Routing failure recovery mechanism for network systems | |
| EP1755240B1 (en) | Method for performing association in automatic switching optical network | |
| WO2008040253A1 (fr) | Procédé pour traiter les informations de ressources dans une liaison d'ingénierie de trafic | |
| WO2007085173A1 (fr) | Procédé de traitement d'une ressource de réseau et unité de réseau d'un réseau optique intelligent associé | |
| JP2002247038A (ja) | ネットワークにおけるリング形成方法及び障害回復方法並びにリング形成時のノードアドレス付与方法 | |
| JP2013503516A (ja) | 伝送ネットワークにおけるサービス復元速度向上方法及びパス計算エレメント | |
| JP3967954B2 (ja) | 光クロスコネクト網の障害回復方法 | |
| JP2007500955A (ja) | 伝送ネットワークにおける固定接続及び相手先選択接続間の移行のための方法 | |
| CN100531092C (zh) | 智能光网络的业务重路由触发方法 | |
| JP6160211B2 (ja) | 伝送装置 | |
| US20030097471A1 (en) | Routing in transmission networks | |
| WO2008040254A1 (fr) | Procédé de traitement destiné aux informations de liaison d'ingénierie de trafic |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050411 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070116 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070220 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070412 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20070412 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070508 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070601 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100608 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100608 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100608 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100608 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110608 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110608 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120608 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120608 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130608 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |