JP2005210514A - 予備経路予約方法及びノード制御装置 - Google Patents

Abstract

【課題】 現用パスのＳＲＬＧ毎に予備経路を割り当て、かつ、複数の予約経路でラベルを共有する予備経路予約を実現する。
【解決手段】 本発明は、予備パスを設定する際に、制御メッセージを現用パスが通過するノードから、該現用パスが通らない迂回経路上を通過して、予備パスの予約設定メッセージを転送し、予約設定メッセージの転送に伴って、予備パスの予約設定を行い、所望の次現用パス上のノードへ転送し、上記の処理を、逐次繰り返し、現用パスの始点から終点までの全区間に対して予備パスを設定することラベルスイッチングを利用する通信網において、制御メッセージを迂回経路上に転送し、順次予備パスを設定する。
【選択図】 図１

Description

本発明は、予備経路予約方法及びノード制御装置に係り、特に、ラベルスイッチングを利用する通信網において、現用パスの予備経路を故障復旧するために予約する際に、ＳＲＬＧ（Shared Risk Link Group）に対し、最短の経路で、あるいは必要最低限のリソースで予備パスを予約し、かつ、異なるＳＲＬＧに対する予備パス同士でリソースを共有し、さらに、その共有されたリソースの使用時まで、そのリソースに対してラベルの割当を保留することのできる予備経路予約方法及びノード制御装置に関する。

従来の通信網における故障復旧技術として、Fast ResouteとEnd-to-End Restorationがある。

最初に、Fast Rerouteについて説明する。

Fast Rerouteには、２つの方法がある。One-to-One Backup法と、Facility Backup法である。両者とも予備パスのラベルは故障に先立って割り当てられている。

One-to-One Backup法では、ある現用パスに対し、それぞれのリンク毎に予備パスが用意される。図８にその例を示す。Ｒ１，Ｒ２，Ｒ３〜Ｒ９は、それぞれネットワークノードを現し、各ノードのＩＤを、Ｒ１，Ｒ２，Ｒ３〜Ｒ９であるとする。例えば、Ｒ１とＲ２の間の実線のように、ノード同士をつなぐ実線はノード間のリンクを表す。これは、以下の他の図９，１０，４〜７においても同様であるとする。この場合、現用パスと予備パスは次のように作成される。図８には、現用パス１、予備パス１、予備パス２の矢印で記した。

現用パス１：Ｒ１→Ｒ２→Ｒ３→Ｒ４→Ｒ５
予備パス１：Ｒ１→Ｒ６→Ｒ７→Ｒ８→Ｒ３
予備パス２：Ｒ２→Ｒ７→Ｒ８→Ｒ４
予備パス３：Ｒ３→Ｒ８→Ｒ９→Ｒ５
予備パス４：Ｒ４→Ｒ９→Ｒ５
予備パス１は、現用パス１のＲ１→Ｒ２→Ｒ３区間を保護するものであり、予備パス２は現用パス１のＲ２→Ｒ３→Ｒ４区間を保護するものである。

現用パスのリンクの数だけ予備パスが用意される。この方法は、保護する現用パスが同一であれば、予備パスをマージすることで予備リソースを共有することができる。図８では、現用パス１を保護する予備パス同士ならば、リソースを共有することができる。

次に、Facility Backup法では、現用パスの特定ＳＲＬＧを迂回する予備パスが用意される。図９に例を示す。図９のＲ１〜Ｒ９は、ネットワークノードを表す。Ｒ２とＲ３間のリンク、及びリンクＲ３とＲ４間のリンクにＳＲＬＧ（Shared Risk Link Group）を割り当て、それぞれＳＲＬＧ１，ＳＲＬＧ２とした。この場合、現用パスと予備パスは次の通りである。ここでは、１つの予備パスを２本の現用で共有している。

・現用パス１：Ｒ１→Ｒ２→Ｒ３→Ｒ４→Ｒ５
・現用パス２：Ｒ８→Ｒ２→Ｒ３→Ｒ４→Ｒ９
・予備パス ：Ｒ２→Ｒ６→Ｒ７→Ｒ４
この方法は保護するＳＲＬＧが同じであれば、異なる現用パスの予備パス同士で予備リソースを共有することができる。図９における、現用パス１のＲ２→Ｒ３→Ｒ４の部分と、現用パス２のＲ２→Ｒ３→Ｒ４部分のように、異なる現用パスが経路の一部分を同じくするとき、その部分の予備パスを共有することができる。つまり、等しいＳＲＬＧを保護する予備パス同士でリソースを共有することができる（例えば、非特許文献１参照）。

また、End-to-End Restorationは、現用パスのIngressとEgressの間で予備パスを設定するものである。現用パスのある区間だけに予備パスを設定する機能はない（例えば、非特許文献２参照）。
draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, IETF Internet draft in WWW.ietf.org,2003 K.Shimano, A. Sahara, M.Koga, Y.TAkigawa, and K.Sato:"Demonstration of Fast Restoration for Distributed Control Plane on Photonic Network"ECOC2002, Copenhagen, Denmark, Sept.2002.

本発明の解決すべき課題は、ラベルスイッチングパスを利用し、現用パスのＳＲＬＧ毎に、予備経路を割り当てるネットワークにおいて、次の２つを実現することである。

・異なる現用パス、異なるＳＲＬＧが予備パスとその予備リソースを共有できる予備パスの予約を実現すること；
・故障発生時まで予備経路に対するラベル割当を保留し、ラベルの利用を効率的にする予備パス予約を実現すること。

従来の技術である「Fast Reroute」には、以下に述べるような問題点があり、このような課題が実現できる方法は考案されていない。

「Fast Reroute」では、予備経路に対するリソース予約とラベル配布を、それぞれＳＲＬＧに対する予備経路に対して行い、これは故障発生に前もって行われる。そのため、全ての予備パスの全てのリンクに対して前もってラベル割当とリソース予約を行う必要がある。「Fast Reroute」を用いた場合、「One-toOne Backup法」「Facility ,Backup法」のそれぞれの項で説明したように。予備経路が保護するＳＲＬＧまたは、現用パスが同じ場合には、ラベルを異なる予備パスで共有することができるが、保護するＳＲＬＧと現用パスが共に異なる場合には、ラベルを共有することができない。このような例を図１０に示す。Ｒ１〜Ｒ６はネットワークノードを表す。Ｒ１とＲ２の間、また、Ｒ５とＲ６の間のリンクに割り当てるＳＲＬＧをそれぞれＳＲＬＧ１、ＳＲＬＧ２とした。現用パスと予備パスの経路は次の通りである。

現用パス１：Ｒ１→Ｒ２
現用パス２：Ｒ３→Ｒ４
予備パス１：Ｒ１→Ｒ３→Ｒ４→Ｒ２
予備パス２：Ｒ５→Ｒ３→Ｒ４→Ｒ６
ここで、予備パス１は現用パス１のＳＲＬＧ１を保護する予備パスであり、予備パス２は現用パス２のＳＲＬＧ２を保護する予備パスである。また、両予備パスの経路は共に、Ｒ３→Ｒ４の区間を通過する。この場合、予備パス１と予備パス２では保護している現用パスが異なるので、One-to-One Backup法を適用した場合、Ｒ３→Ｒ４区間に対するラベルを予備パス１と予備パス２で共有することができない。また、予備パス１はＳＲＬＧ１を保護し、予備パス２はＳＲＬＧ２を保護し、２つの予備パスは同じＳＲＬＧ、つまり、同じ区間を保護するものではないので、Facility Backup法を用いてもＲ３→Ｒ４区間に対するラベルを予備パス１と予備パス２で共有することはできない。このような場合に、ラベルの共有が不可能である方法は、膨大なラベル数を用意できるパケット交換式のＭＰＬＳネットワークにおいては機能する。しかし、ＧＭＰＬＳ(Generalized Multicast Routiong Protocol)ネットワークの一つであるＷＤＭベースのネットワークやＴＤＭベースのネットワークにおいては、ＷＤＭでは光の波長、ＴＤＭではスロット番号（または位置）といったように、ラベルが物理的リソースに対応してラベル数が限られているため、ラベルを消費することはリソースを消費することに繋がる。よって、ラベルを効率的に共有し、ラベル使用量を低減できる方法が必要である。なお、ここでいうリソースとは、ＩＰパケットネットワークでは帯域であり、ＷＤＭ，ＴＤＭではネットワークでそれぞれ、光の波長、タイムスロットである。

一方、End-to-Endリストレーションでは、１本のパス全体に対して予備経路が用意されるパス上の一つのリンクの故障復旧のために、End-to-Endの予備経路を予約しなければならない。これは、故障に無関係な部分までの制御を必要とし、また、故障復旧の際の遅延の原因になる。パス上のリンクそれぞれに対して、必要最小限の予備経路を割り当てる予備経路予約方式が必要となる。

本発明は、上記の点に鑑みなされたもので、本発明の解決すべき課題は、ラベルスイッチングパスを利用し、現用パスのＳＲＬＧ毎に、予備経路を割り当てるネットワークにおいて、次の２つを実現することである。

・異なる現用パス、異なるＳＲＬＧが予備パスとその予備リソースを共有できる予備パスの予約を実現すること；
・故障発生時まで予備経路に対するラベル割当を保留し、ラベルの利用を効率的にする予備パス予約を実現すること；
を目的とする。

図１は、本発明の原理を説明するための図である。

本発明は、制御メッセージを用いて現用パス並びに該現用パスに対応する予備パスを予約設定し、故障箇所に応じて切替先予備パスの経路が選択される通信網における予備経路予約方法において、
ネットワークノード上のノード制御装置において、予備パスを設定する際に、
制御メッセージを現用パスが通過するノードから、該現用パスが通らない迂回経路上を通過して、予備パスの予約設定メッセージを転送し（ステップ１）、
予約設定メッセージの転送に伴って、予備パスの予約設定を行い（ステップ２）、所望の次現用パス上のノードへ転送し（ステップ３）、
上記の処理を、逐次繰り返し、現用パスの始点から終点までの全区間に対して予備パスを設定する。

また、本発明は、メッセージの転送の際に、メッセージにリスク情報を付加して転送する。

また、本発明は、リスク情報と、該リスク情報が示す現用パス上の一部が故障した場合に備えるための迂回用の予備パス情報を関連付けるデータベースを用いる。

また、本発明は、現用パスのリスク情報であるＳＲＬＧごとに予備パスを用意する。

図２は、本発明の原理構成図である。

本発明は、制御メッセージを用いて現用パス並びに該現用パスに対応する予備パスを予約設定し、故障箇所に応じて切替先予備パスの経路が選択される通信網上のノードに設けられるノード制御装置であって、
シグナリングによって作成されたパスのセッションＩＤ，経路、リソースを含む情報を格納するパス情報ＤＢ５０と、
使用可能なラベルと、所定のラベルの状態情報を格納するラベルＤＢ６０と、
ルーティングのフォワーディングテーブルやトポロジの情報を格納するルーティングＤＢ７０と、
シグナリングやラベル配布を行うプロトコルであるＲＳＶＰ−ＴＥの機能を実現するＲＳＶＰ−ＴＥ処理手段３０と、
ＲＳＶＰ−ＴＥ処理手段３０からのラベルの決定依頼に基づいて、ラベルＤＢを参照してＲＳＶＰ−ＴＥで配布するラベルを決定するラベル処理手段１０と、
ＯＳＰＦ，ＲＩＰを含むルーティングプロトコルを処理し、ルーティングＤＢ７０に格納するルーティングプロトコル処理手段４０と、
ＲＳＶＰ−ＴＥ処理手段３０からの要求により、パス情報ＤＢ１０を参照して、予備パス経路の計算を行い、該ＲＳＶＰ−ＴＥ処理手段３０に結果を返す経路計算手段２０と、を有し、
ＲＳＶＰ−ＴＥ処理手段３０は、
ネットワークノード上において、予備パスを設定する際に、
経路計算手段２０で計算された予備パス経路の計算結果に基づいて、予約設定メッセージを作成する手段と、
予約設定メッセージを、現用パスが通らない迂回経路を介して転送する手段と、
予約設定メッセージの転送に伴って、予備パスの予約設定を行う手段と、を有する。

また、本発明のＲＳＶＰ−ＴＥ処理手段３０は、予約設定メッセージの転送の際に、メッセージにリスク情報を付加して転送する手段を含む。

また、本発明のパス情報ＤＢ５０は、リスク情報と、該リスク情報が示す現用パス上の一部が故障した場合に備える迂回用の予備パス情報を関連付ける情報を有する。

また、本発明のＲＳＶＰ−ＴＥ処理手段３０は、現用パスのリスク情報であるＳＲＬＧ毎に予備パスを用意する。

上記により、本発明は、現用パスのＳＲＬＧごとに予備経路を割り当て、かつ、複数の予備経路でラベルを共有する予備経路予約を実現することができる。

以下、図面と共に本発明の実施の形態を説明する。

現用パスのリンク毎に予備経路を割り当て、かつ、複数の予備経路でラベル、及びリソースを共有する予備経路予約を実現する方法を以下に示す。

以下に示す機能が、ＲＳＶＰ−ＴＥ対応のルータ等のネットワークノードに実装される。

ネットワークノードに実装されたノード制御装置の構成を図３に示す。

同図に示すノード制御装置１００は、ラベル処理部１０、経路計算処理部２０、ＲＳＶＰ−ＴＥプロトコル処理部３０、ルーティングプロトコル処理部４０、パス情報ＤＢ５０、ラベルＤＢ６０，ルーティングＤＢ７０、及びスイッチング機能部８０から構成され、他のノード２００と接続されている。

ＲＳＶＰ−ＴＥプロトコル処理部３０は、シグナリングやラベル配布を行うプログラムコルであるＲＳＶＰ−ＴＥの機能を実現する部分である。ここで、ＲＳＶＰ−ＴＥの機能については、IETF RFC3209やIETF RFC3473を参照されたい。

ラベル処理部１０は、ＲＳＶＰ−ＴＥで配布するラベルの決定とラベルの状態管理を行う。

経路計算処理部は、ＲＳＶＰ−ＴＥにおけるシグナリングの経路を決定する。

ルーティングプロトコル処理部４０は、ＲＩＰ(Routing Information Protocol)、ＯＳＰＦ(Open Shortest Path First)などのルーティングプロトコルを処理する部分である。

スイッチング機能部８０は、トラフィックのクロスコネクションを行うハードウェアとその管理機能部である。

パス情報ＤＢ５０は、シグナリングによって作成されたパスのセッションＩＤ、経路、リソースなどの情報を格納するデータベースである。

ラベルＤＢ６０は、使用可能なラベルと、本実施の形態で規定するラベルの状態情報を格納するデータベースである。

ルーティングＤＢ７０は、ルーティングのフォワーディングテーブルや、トポロジーの情報を格納するデータベースである。

以下に、同図に示すノード制御装置の動作を説明する。

ＲＳＶＰ−ＴＥプロトコル処理部３０は、ラベル処理部１０に配布するラベルの決定依頼を行い、ラベル処理部１０は、ＲＳＶＰ−ＴＥプロトコル処理部３０からの要求を受けてラベルの決定を行い、その決定結果をＲＳＶＰ−ＴＥプロトコル処理部４０に伝達する。

ラベル処理部１０は、配布ラベルを決定する過程で、ラベルＤＢ６０の情報を参照する。さらに、ラベル処理部１０は、トラフィックの切り換えをスイッチング機能部８０に要求することができ、要求を受けたスイッチング機能部８０はクロスコネクションを行う。

スイッチング機能部８０は、データリンク９０により、他ノード２００と接続されている。

また、ＲＳＶＰ−ＴＥプロトコル処理部３０は、シグナリングの経路決定を経路決定処理部２０に要求することができ、その要求を受けた経路計算処理部２０は、経路計算結果をＲＳＶＰ−ＴＥプロトコル処理部３０に返す。

経路決定処理部２０は、経路決定の過程でルーティングＤＢ７０を参照する。また、このルーティングＤＢ７０の情報は、ルーティングプロトコル処理部４０によって作成される。

さらに、ＲＳＶＰ−ＴＥプロトコル処理部３０とルーティングプロトコル処理部４０は、他のノード２００と通信する。

ＲＳＶＰ−ＴＥプロトコル処理部３０は、メッセージなどの情報のやり取りを他ノード２００と行い、ルーティングプロトコル処理部４０は、ルート情報等のルーティングプロトコルに必要な情報のやり取りを他のノード２００と行う。

なお、同図における他ノード２００も、上記で説明したノード制御装置１００と同様の機能を有するものとする。

本実施の形態では、リソース予約とラベル配布にシグナリングプロトコルを利用し、シグナリングプロトコルによりパスの設定を行う。シグナリングプロトコルとしては、例えば、独自に拡張を加えたＲＳＶＰ−ＴＥ（例えば、IETF RFC3209やIETF RFC3473）のシグナリングを利用することが考えられる。パスの設定と運用するには、パス上のネットワークノードのリソース予約と、ノードがトラフィックを転送するためのラベルの割り当てをシグナリングにより行う必要がある。現用パスについては、リソース予約とラベル配布を同時に行う。予備パスについては、故障に先立ちリソースの予約のみを行い、故障発生後に、ラベルとリソースの割り当てを行う。また、現用パスシグナリング後に予備パスをシグナリングするものとする。本発明において、このようなシグナリングの機能はＲＳＶＰ−ＴＥプロトコル処理部３０において実現する。

ここで、リソースの共有方法について説明する。

本実施の形態では、予備パスにリソース、及びラベルを割り当てる際に、複数の予備パスでリソースとラベルの共有を行う。このようなラベル共有管理は、ＲＳＶＰ−ＴＥプロトコル処理部３０及びラベル処理部１０で実現され、ラベルの情報はラベルＤＢ６０に保存される。ラベル共有のためにラベルの状態に次の３つの区別を設ける。

・どの現用パスにも関連付けられていない状態（unused）；
・決められた条件を満たす現用パスン関連付けられ、複数の現用パスと関連付けることが可能な状態(reserved)；
・一意に指定した一つの現用パスだけに関連付けられている状態(assigned)；
ここでは、説明のため、この３つの状態をそれぞれ、“unused”、“reserved”、“assigned”
と呼ぶことにする。

現用パスでトラフィック転送のために利用されているラベルは、その現用パスそれぞれに一つずつ割り当てられているので、“assigned”である。ＲＳＶＰ−ＴＥプロトコル処理部３０による予備パスシグナリングで予約されたラベルは、実施のトラフィック転送に使われているわけではないので、複数の予備パスで共有することができる。この場合のラベルは複数の予備パスに関連付けられているので、その状態は“reserved”である。言い換えれば、“reserved”状態のラベルに複数のパスが関連付けられていれば、そのラベルが複数のパスで共有されているということができる。また、予備パスに実際にトラフィックを転送する必要が発生すると、トラフィック転送のためにラベルが一意に選択され、予備パスのラベルの状態は、“assigned”となる。“assigned”の状態は、スイッチング機能部８０にクロスコネクトを用いたシステムでは、スイッチング機能部８０におけるクロスコネクトが完了した状態である。シグナリングに関わらなかったラベルの状態は“unused”である。このような３つの状態管理がラベル処理部１０により行われる。

予備パスシグナリングの際、ＲＳＶＰ−ＴＥプロトコル処理部３０で、その予備パスに必要な“reserved”状態のラベル数の計算を行い、ラベル処理部で必要数の“reserved”状態ラベルの確保を行う。ここで、“reserved”状態ラベルを共有し、できるだけラベルの確保数を少なくすることで、効率的なラベルの利用が図られる。ラベルが物理的リソースと対応する場合は、リソース量に関してもこれと同様に共有が行われる。このような共有管理は、ＲＳＶＰ−ＴＥプロトコル処理部３０とラベル処理部１０の連携により行われる。

次に、現用のシグナリングと予備のシグナリングの区別について説明する。

本発明では、ＲＳＶＰ−ＴＥプロトコル処理部３０により、現用のシグナリングと予備のシグナリングの区別が行われる。説明のためにそれぞれを、“PRIMARY”と“SECONDARY”と呼ぶこととする。

この区別は、ＲＳＶＰ−ＴＥプロトコルにおいて、新しいメッセージがオブジェクトもしくはサブオブジェクトを設け、それの存在の是非で判断することもできる。Pathメッセージを受け取るノードのうち、IngressノードとEgressノード以外の中間ノードでは、ＲＳＶＰ−ＴＥプロトコル処理部３０は、PathメッセージがPRIMARYであれば、現用のシグナリングであると判断し、SECONDARYである場合は、予備パスのシグナリングであると判断する。これは、例えば、ＩＥＴＦドラフトの１つ「draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt, IETF Internet draft in WWW.ietf.org,2003」で規定されているProtection Objectのセカンダリー・ビットを用いて判断することができる。

次に、現用パスシグナリングパスについて説明する。

現用パスシグナリングの際に、ＲＳＶＰ−ＴＥプロトコル処理部３０は、現用パスのＳＲＬＧと通過ノードのＩＤをPathメッセージに記録する。このとき、ＳＲＬＧとノードＩＤは、Pathメッセージが通過した順番が保存されるようにリストとしてPathメッセージに記録される。このようにすることで、egressノードでは、Pathメッセージが通過したリンクのＳＲＬＧ番号と通過したノードのノードＩＤをPathメッセージから知ることができる。このPathメッセージで集められる情報は、図４のネットワークでは、それぞれ現用パスについて、表１のようなものになる。

これらの情報は、ＲＳＶＰ−ＴＥプロトコル処理部３０により、パス情報ＤＢ５０に保存される。図４において、Ｒ１〜Ｒ１２は、ネットワークノードを表す。Ｒ１とＲ２間、Ｒ１とＲ２間、Ｒ２とＲ３間、Ｒ３とＲ４間、Ｒ５とＲ６間、Ｒ６とＲ７間、Ｒ７とＲ８間、Ｒ１１とＲ６間、Ｒ７とＲ１２間のリンクに割り当てるＳＲＬＧをそれぞれＳＲＬＧ−１、ＳＲＬＧ−２，ＳＲＬＧ−３，ＳＲＬＧ−４，ＳＲＬＧ−５，ＳＲＬＧ−６，ＳＲＬＧ−７，ＳＲＬＧ−８とした。また、次のような現用パスと予備パスを定義した。

現用パス１：Ｒ１→Ｒ２→Ｒ３→Ｒ４
現用パス２：Ｒ５→Ｒ６→Ｒ７→Ｒ８
現用パス３：Ｒ１２→Ｒ６→Ｒ７→Ｒ１２
予備パス１：Ｒ１→Ｒ９→Ｒ１０→Ｒ３
予備パス２：Ｒ６→Ｒ９→Ｒ１０→Ｒ７
予備パス３：Ｒ６→Ｒ９→Ｒ１０→Ｒ７
また、現用パスのリンクにはＳＲＬＧ番号を割り当てた。現用パスのＳＲＬＧ番号は、現用パス１、２，３、それぞれについて、現用パス２については、Ingress側からＳＲＬＧ−４，ＳＲＬＧ−５，ＳＲＬＧ−６、現用パス３については、Ingress側からＳＲＬＧ−７，ＳＲＬＧ−５，ＳＲＬＧ−８である。現用パス２と現用パス３は、ＳＲＬＧ−５が割り当てられたリンクを共有している。ここで、予備パス１は、現用パス１のＳＲＬＧ１，ＳＲＬＧ２を保護し、予備パス３は現用パス３のＳＲＬＧ５を保護するものである。

Pathメッセージを送信する際、ラベル処理部１０において、自ノードで利用可能な出力ラベルが決定され、ＲＳＶＰ−ＴＥプロトコル処理部３０に通知される。ＲＳＶＰ−ＴＥプロトコル処理部３０は、自ノードで利用可能な出力ラベルを、Pathメッセージに含め、下流隣接ノードに通知する。このPathメッセージは、下流ノードのＲＳＶＰ−ＴＥプロトコル処理部で受け取られる。Pathメッセージに含まれていたラベル情報は、受け取ったノードのＲＳＶＰ−ＴＥプロトコル処理部により、自分自身の利用可能な出力ラベルに置き換えられ、さらに、下流のノードへと中継される。これを実現する方法として、この利用可能ラベル情報を、ＲＳＶＰ−ＴＥのLabel_Setオブジェクトに記して、それをPathメッセージに含めて送信する方法がある。

パスメッセージを受信した現用パスのEgressノードのＲＳＶＰ−ＴＥプロトコル処理部３０は、ReserveメッセージをIngressノードに向かって送信する。このとき、EgressノードのＲＳＶＰ−ＴＥプロトコル処理部３０は、Pathメッセージに保存されている通過ノードとＳＲＬＧ番号の情報をReserveメッセージに含める。また、先に受け取ったPathメッセージに含まれていた上流ノードの利用可能出力ラベルをラベル処理部１０に渡す。ラベル処理部１０は、ノードの入力ラベルを選択し、結果をＲＳＶＰ−ＴＥプロトコル処理部３０に返し、ＲＳＶＰ−ＴＥプロトコル処理部３０は、Reserveメッセージに含める。

この入力ラベル選択は、Reserveメッセージを中継する全てのノードで行われ、順序が保存されるように、Reserveメッセージに記録されていく。選択されたラベルは、ラベル処理部１０により、“assigned”状態とされ、ＲＳＶＰ−ＴＥプロトコル処理部３０により、現用パスに関連づけられる。また、ラベルの状態が変化したことが、ラベル処理部１０により、ラベルＤＢ６０に記録される。

Reserveメッセージを中継するノードは、そのメッセージから作成を試みているパスを構成するノードと、パスを構成するリンクのＳＲＬＧ番号、自分の使用すべき出力ラベルの情報を得ることができ、その情報はそれぞれ、そのノードのパス情報ＤＢ５０とラベルＤＢ６０に保存される。

ReserveメッセージがIngressノードに届くと、現用パスのシグナリングは終了する。

現用パスのシグナリング手順の例を図５に示す。同図において、Ｒ１〜Ｒ６はネットワークノードである。Ｒ１は、Ingressノードであり、Ｒ２はEgressノードである。Ｒ１とＲ２間、Ｒ２とＲ３間、Ｒ３とＲ４間に割り当てられるＳＲＬＧをそれぞれＳＲＬＧ１，ＳＲＬＧ２，ＳＲＬＧ３とした。Reserveメッセージで、Ｒ１とＲ２間、Ｒ２とＲ３間、Ｒ３とＲ４間に割り当てられるラベルをそれぞれ、λ_３、λ_２、λ_１とした。図５において、括弧内の数字の１〜６は、Pathメッセージ、及びReserveメッセージが各リンクを通過する順番を表している。また、矢印は、そのノード間でメッセージが送信される方向を表す。IngressノードＲ１、EgressノードＲ４の間でＲ１→Ｒ２→Ｒ３→Ｒ４という予備パスを作成する。

Pathメッセージは、Ｒ１のＲＳＶＰ−ＴＥプロトコル処理部３０によりＲ４に向かって送信され、通過した中間ノードのＩＤ，及びＳＲＬＧ番号が記録される（図５における括弧内の数字１〜３）。Pathメッセージを受け取ったEgressノードＲ４のＲＳＶＰ−ＴＥプロトコル処理部３０は、IngressノードＲ１に、Reserveメッセージを送信する。Reserveメッセージには、Pathメッセージ送信過程において記録されたＳＲＬＧとノードＩＤの情報がＲＳＶＰ−ＴＥプロトコル処理部３０によってコピーされる。ここでは、それぞれのリンクに割り当てられるλ_１、λ_２、λ_３というラベルがラベル処理部１０により決定され、順にReserveメッセージに記録されていく（図５の括弧内の数字４〜６）。図５の括弧内の数値１〜３のときに、Pathメッセージに保存されているＳＲＬＧ番号とノードＩＤのリスト、図５の括弧内の数値４〜６にReserveメッセージに保存されているＳＲＬＧ番号とノードＩＤのリスト、及びラベル情報のリストは次のようになる。ＳＲＬＧ番号とノードＩＤのリストとラベル情報のリストはパス情報ＤＢ５０に保存される。

なお、以下の括弧内の数字と図５の括弧内の数字は対応するものとする。

・ＳＲＬＧ番号・ノードＩＤリスト
（１）Ｒ１
（２）Ｒ１→ＳＲＬＧ１→Ｒ２
（３）Ｒ１→ＳＲＬＧ１→Ｒ２→ＳＲＬＧ２→Ｒ３
（４）Ｒ１→ＳＲＬＧ１→Ｒ２→ＳＲＬＧ２→Ｒ３→ＳＲＬＧ３→Ｒ４
（５）Ｒ１→ＳＲＬＧ１→Ｒ２→ＳＲＬＧ２→Ｒ３→ＳＲＬＧ３→Ｒ４
（６）Ｒ１→ＳＲＬＧ１→Ｒ２→ＳＲＬＧ２→Ｒ３→ＳＲＬＧ３→Ｒ４
・ラベルリスト
（４）λ_１
（５）λ_１→λ_２
（６）λ_１→λ_２→λ_３
次に、予備パス経路の計算について説明する。

予備パスシグナリングの手続は現用パスのReserveメッセージを受け取った後にＲＳＶＰ−ＴＥプロトコル処理部３０により行われるが、予備経路をシグナリングするノードは、シグナリングを開始する前に予備パスの経路を計算する必要がある。ここでは、現用パスのノードＩＤリストの情報を用いて、経路計算処理部２０により予備経路が計算される。計算された予備経路は、ＲＳＶＰ−ＴＥプロトコル処理部３０に渡され、予備パスのPathメッセージのＥＲＯ（Explicit root object）に設定される。また、ＲＳＶＰ−ＴＥプロトコル処理部３０は、この予備パスの経路から、予備パスの終端点を知ることができる。

次に、予備パスシグナリングについて説明する。

本発明では、Egress以外のパス上のノードが、それぞれ下流にあるＳＲＬＧに対して予備パスを作成するため、現用パスの中間ノード毎に予備パスが作成される。中間ノードを通る現用パスは、１本とは限らないので、現用パスを構成するEgress以外のノードは、自分が保持する現用パスの数分だけ予備パスのシグナリングを行う。よって、ＲＳＶＰ−ＴＥプロトコル処理部３０は、シグナリングを開始するノードＩＤとそのノードが保護する現用パスのＩＤを用いて、予備パスセッションを一意に識別することができる。つまり、予備パスのPathメッセージに、送信元のノードＩＤと、その予備経路で保護する現用パスのＩＤを含めることで、ＲＳＶＰ−ＴＥプロトコル処理部３０は、全ての予備パスセッションのPathメッセージを区別することができる。この対応関係の一例を表２に示す。

また、複数ある予備パスのシグナリングは、ＲＳＶＰ−ＴＥプロトコル処理部３０において、以下のタイミングと手順で行われる。この説明を図６に示す。図６において、Ｒ_１，Ｒ_２〜Ｒ_Ｎは、ネットワークノードであり、合計Ｎ個存在するものとした現用パスは、IngressノードをＲ_１、EgressノードをＲ_Ｎとし、その経路は、Ｒ_１→Ｒ_２→…→Ｒ_Ｎ−１→Ｒ_Ｎであるものとする。また、予備パスは、全てのＳＲＬＧを保護できるようにあり、計Ｍ本存在するものとした。予備パスは点線で表した。まず、IngressノードＲ_１がReserveメッセージを受け取ったことをトリガし、ノードＲ_１のＲＳＶＰ−ＴＥプロトコル処理部３０が経路計算処理部２０に自分の下流側のＳＲＬＧに対する予備経路計算の要求を出し、その要求を受け取った経路計算処理部２０で予備経路が計算される。Pathメッセージが、Ｒ_１から予備経路の終端ノードに向けて送信され、その予備経路に従って、シグナリングが行われる。計算された予備経路の終端がＲ_２であるとすると、Ｒ_１からＲ_２に向かって、Pathメッセージが送信される。次に、Ｒ_１のＲＳＶＰ−ＴＥプロトコル処理部３０からのPathメッセージを受け取ったＲ_２のＲＳＶＰ−ＴＥプロトコル処理部３０は、それをトリガにReserveメッセージをＲ_１に送信すると共に、予備パス２のシグナリングを開始する。このように、予備経路の終端ノードとなったノードが、同様に自分の下流側のＳＲＬＧに対する予備経路をシグナリングすることで、シグナリングが連鎖的に行われる。この連鎖がIngressノードから開始され、順に繰り返され、Engressノードまで到達し、最終的に全ての区画に対する予備経路が作成されることになる。

予備経路のPathメッセージには、その予備経路で保護するリンクのＳＲＬＧ番号が含まれる。このＳＲＬＧの番号の情報は、現用パスのPathメッセージからのリストと、迂回経路計算で求めた予備パスの終端ノードＩＤを元に決定することができる。自ノードと迂回経路の終端ノードは共に、現用パス上にあるので、自ノードと迂回経路の終端ノードの間のＳＲＬＧを現用パスのPathメッセージからのリストから調べればよい。この情報は、この予備パスのパス情報としてパス情報ＤＢ５０に保存される。

更に、予備パスのPathメッセージには、現用パスのバックアップとして機能するのに必要なリソース量が記録され、これは現用パスの予約帯域と等しく設定される。予備パスのセッションを保持するノードのＲＳＶＰ−ＴＥプロトコル処理部３０は、現用パスを保護するのに必要とされるリソース量をパス情報としてパス情報ＤＢ５０に保存する。また、リソース量からその予備パスに必要なラベル数を計算し、それをそのパスの情報としてパス情報ＤＢ５０に保存する。

説明のため、予備パスセッションを保持するノードでこれらの情報を管理するテーブルの一例を表３に示す。

これは、図４のＲ９のパス情報ＤＢ５０が保持するもので、Ｒ９とＲ１０間のリンクのリソース情報に該当するする。表３では、このノードが保持する予備パスのセッションＩＤをキーにして、それに関連するＳＲＬＧ番号、また、現用パスを保護するのに必要なラベル数とリソース量が記録されている。ここでのラベル数とリソース量は、ラベル処理部１０が予備パスに、“reserved”の状態として関連付けることが可能なラベル数とリソース量である。さらに、これらの情報の他に、ラベル処理部１０により“unused”状態のラベルから選択された自ノードで利用可能な出力ラベルの情報がPathメッセージを用いて、下流隣接ノードに運ばれる。これは、現用のパスメッセージと同様である。

予備パスシグナリングのPathメッセージを受け取った予備パスの終端点ノードは、送信元ノードにReserveメッセージを送信する。この予備パスのReserveメッセージには予備パスPathメッセージと同様に、関係する現用パスの保護に必要なリソース量が記録されている。Reserveメッセージを受け取った中間ノードのＲＳＶＰ−ＴＥプロトコル処理部３０は、その予備パスと“reserve”状態のラベルの関連付けを行い、その情報をパス情報ＤＢ５０に保存する。同時に、メッセージに記述されているリソース量を利用して自ノードで必要なリソース量、ラベル数を求め、“reserved”状態のラベル数を増やすかどうかの判断を行う。その結果、ラベル数が足りない場合は、Pathメッセージより得た上流ノードの利用可能出力ラベルをラベル処理部１０に通知し、ラベル処理部１０にラベルの決定要求を行う。

ラベル処理部１０は、上流ノードの利用可能出力ラベルの中から、必要数のラベルを選択し、“reserved”状態にし、ラベルＤＢ６０に記録する。“reserved”となったラベルは、ＲＳＶＰ−ＴＥプロトコル処理部３０に通知され、予備パスとの関連付けが行われる。“reserved”状態となったラベル数は、その予備パスの必要ラベル数としてパス情報ＤＢ５０に保存される。

次に、必要リソース量の計算法について説明する。

予備パスセッションを維持するノードにおいて、ＲＳＶＰ−ＴＥプロトコル処理部３０は、複数の予備パスセッションを維持する場合がある。この場合、複数の予備パスセッションでリソースを共有する。このとき、このノードが最低限確保しなければならないリソース量の計算法を以下に示す。このような処理は、ＲＳＶＰ−ＴＥプロトコル処理部３０がパス情報ＤＢ５０を利用しながら行われる。

はじめに、予備パスのシグナリング毎に、その予備パスで保護する現用パスに必要なリソース量が集められる。従って、この情報は、予備パスＩＤをキーにして整理することができる。ここでのキーの数はそのノードが保持する予備パスセッションの数、つまり、そのノードが携わったシグナリングの数である。この例を表３で前述した。これは、図４のＲ９の保持するもので、Ｒ９とＲ１０間のリンクのリソース情報に該当する。ここで、前述のように、予備経路のPathメッセージにはその予備経路で保護するＳＲＬＧ番号が含まれているので、Ｒ９は、それぞれの予備パスセッションが保護するＳＲＬＧを知ることができる。これにより、予備パス毎の必要リソースを知ることができる。

次に、Ｒ９は、予備パス毎の必要リソースから、ＳＲＬＧ毎の必要リソースを求める。まず、それぞれのＳＲＬＧに何本の現用が通っているかをチェックする。一つのＳＲＬＧに、複数のＩＤの異なる現用が通っている場合、そのＳＲＬＧを保護するために必要なリソースは、それらの現用の使用リソースの和となる。保護する現用パスのＩＤが同じ複数の予備パスが通っている場合、値の大きいリソース要求量を用いる（通常両者は等しい）。これを計算するために、ＳＲＬＧ番号をキーとして、データを整理したのが、表４である。

上記のようなリソース計算を行い、ＳＲＬＧ番号毎に必要リソースを求めることができる。

最後に自ノードがどれだけのリソース量を用いればよいかが計算される。リソースを、共有しない場合には、ＳＲＬＧ番号についてのリソース量の和がこのノードで確保が必要なリソース量である。リソースを共有する場合、ＳＲＬＧ番号についてのリソース量の内、最大のものがこのノードで確保が必要なリソース量となる。表４の例では、ＳＲＬＧ１，ＳＲＬＧ２，ＳＲＬＧ５に必要なリソース量は、それぞれ、ｘ、ｘ、ｙ＋ｚであるので、ｘとｙ＋ｚの内の値の大きいリソース量が、このノードで必要なリソース量となる。ラベルについても、同様なやり方で共有ができ、この場合必要なラベル数はａ＋ｂとなる。このようにして、予備パスＩＤの異なる４つの予備パスでリソースとラベルが共有できている。この場合に、図４のネットワークで確保されるリソース量を図７に示す。図７は、図４と対応している。図７において、Ｒ１〜Ｒ１２はネットワークノードである。現用パスと予備パス、及びＳＲＬＧ番号は、図４と同様であるとする。実際の長方形に囲まれたアルファベットｘ，ｙ，ｚは現用パスに必要なリソース量を表す。点線に囲まれたアルファベットｘ，ｙ，ｚ及びそれらの式は、予備パスに必要なリソース量を表す。Ｒ９とＲ１０の間に記載されているＭＡＺ（ｘ，ｙ＋ｚ）は、ｘとｙ＋ｚの内、値の大きい方の分だけリソースが割り当てられていることを意味する。

次に、故障時の切り替えについて説明する。

あるＳＲＬＧで故障が発生すると、その事実がそのＳＲＬＧの上流ノードに伝えられる。自分に隣接する下流ＳＲＬＧで故障が発生したことを通達されたノードにおけるＲＳＶＰ−ＴＥプロトコル処理部３０は、そのＳＲＬＧを保護している予備パスの経路に対してＲＳＶＰ−ＴＥのシグナリング手続きを行う。このとき、シグナリングをトリガにして、その経路上でトラフィック転送を行うためのラベルが、各ノードのラベル処理部１０が管理する“reserved”状態のラベルから一つずつ選ばれ、“assigned”状態となる。ラベル処理部１０は、このラベル状態遷移処理と同時にスイッチング機能部８０に切替要求を出す。これを受けて、スイッチング機能部８０は、トラフィックを予備パスに切り替える。

予備パスへの切り替えが終了した後、予備パスの始点と終端点の間で、元の現用パスであった部分のリソースとラベルはラベル処理部１０により開放され、“unused”状態とされる。

次に、故障切替シグナリングの区別について説明する。

予備パス上のノードは予備パスを作成するためのシグナリングとトラフィックを転送させるためのシグナリングを区別する必要がある。この実現方法は、例えば次の２つが考えられる。

一つは、メッセージを受け取ることで、遷移するノードの状態遷移で区別する方法であり、もう一つはメッセージ中のある値の違いで区別する方法である。

メッセージで区別する場合、ＲＳＶＰ−ＴＥプロトコル処理部３０がPathメッセージ中のオブジェクトの特定ビットで区別することが考えられる。このようなオブジェクトの候補の一つとして、例えば、“draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt, IETF Internet draft in WWW.ietf.org,2003”に記載されているProtectionオブジェクトのＰビットを用いて実現することが考えられる。

また、ＲＳＶＰ−ＴＥプロトコル処理部３０は、トラフィックを切り替えられる予備パスが、複数の現用パスを保護している場合、送られてくる切替シグナリングメッセージが、どの現用を保護するものかを識別する必要がある。これは、予備パスＩＤによって識別することができる。予備パスＩＤは送信ノードＩＤと現用パスＩＤで決まるので、言い換えると、Pathメッセージ、Reserveメッセージに含まれている保護する現用パスＩＤと送信ノードＩＤより区別することができる。

最後に、故障切替後のリフレッシュメッセージについて説明する。

ＲＳＶＰ−ＴＥは、ソフトステートプロトコルであるため、ＲＳＶＰ−ＴＥプロトコル処理部３０は、パスのセッションを維持するために、パス上でリフレッシュメッセージをやり取りする必要がある。故障切替え前のリフレッシュメッセージは、ＲＳＶＰにおける方法（例えば、IETF RFC2205）と同様に行い、故障切替によって経路が変更された後の現用パスのリフレッシュメッセージのやり取りは次のように行う。

ＲＳＶＰにおける手順では、始めに現用パスが作成された時に用いられたのと同一なPathメッセージがリフレッシュメッセージとしてIngressからEngressまで送信され、その応答として、始めに現用パスが作成された時に用いられたのと同一なReserveメッセージがEngressからIngressまでリフレッシュメッセージとして送信される。一方、本発明では、故障を検出する故障端のノードにおいて、ＲＳＶＰ−ＴＥプロトコル処理部３０は、Pathメッセージをリフレッシュメッセージとして受け取った際に、Pathメッセージの送信すべき経路が記述されているPathメッセージのExplicit Routeオブジェクトを、迂回経路を通過するように書き替えを行い、もう一つの故障端ノードに向けて、運用状態になった迂回経路に送信する。受け取った下流側の故障端ノードにおいて、ＲＳＶＰ−ＴＥプロトコル処理部３０は、パス上の下流ノードにそれを中継し、最終的には現用パスのEgressまで送信される。

Pathメッセージを受け取ったEgressノードにおけるＲＳＶＰ−ＴＥプロトコル処理部３０は、ReserveメッセージをPathメッセージが送られてきた経路と同じ経路に返送する。このReserveメッセージには、Pathメッセージが送信されてきた経路と同じ経路に返送する。このReserveメッセージには、Pathメッセージの通った経路情報が、Record Routeオブジェクトとして保存されている。Reserveメッセージを中継するノードのＲＳＶＰ−ＴＥプロトコル処理部３０は、この情報を参照し、各ノードが持つパス情報ＤＢ５０にある現用パス経路情報を新しい情報へ更新する。

なお、上記の実施の形態では、ネットワーク上のノード内のノード制御装置の動作として説明しているが、個々のノード制御装置の動作をプログラムとして構築し、ノード制御装置として利用されるコンピュータにインストールし、ＣＰＵ等の制御手段により実行する、または、ネットワークを介して流通させることも可能である。

また、構築されたプログラムを、ノード制御装置として利用されるコンピュータに接続されるハードディスク装置や、フレキシブルディスク、ＣＤ−ＲＯＭ等の可搬記憶媒体に格納し、実行時にコンピュータにインストールすることも可能である。

なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

本発明は、ラベルスイッチングを利用し、現用パスのＳＲＬＧ毎に予備経路を割り当てるネットワークに適用可能である。

本発明の原理を説明するための図である。 本発明の原理構成図である。 本発明の一実施の形態におけるノード制御装置の構成図である。 本発明の一実施の形態におけるネットワーク例である。 本発明の一実施の形態における現用パスシグナリングの一例である。 本発明の一実施の形態における予備パスシグナリングの順序を示す図である。 本発明の一実施の形態における予約されるリソース量を示す図である。 One-to-One Backup法を説明するための図である。 Facility Backup法を説明するための図である。 互いに異なった現用パス、異なったＳＲＬＧを保護する予備パスを説明するための図である。

符号の説明

１０ ラベル処理部
２０ 経路計算処理部
３０ ＲＳＶＰ−ＴＥプロトコル処理部
４０ ルーティングプロトコル処理部
５０ パス情報ＤＢ
６０ ラベルＤＢ
７０ ルーティングＤＢ
８０ スイッチング機能部
９０ データリンク
１００ ノード、ノード制御装置
２００ ノード

Claims (8)

1. 制御メッセージを用いて現用パス並びに該現用パスに対応する予備パスを予約設定し、故障箇所に応じて切替先予備パスの経路が選択される通信網における予備経路予約方法において、
   ネットワークノード上のノード制御装置において、前記予備パスを設定する際に、
   前記制御メッセージを前記現用パスが通過するノードから、該現用パスが通らない迂回経路上を通過して、前記予備パスの予約設定メッセージを転送し、
   前記予約設定メッセージの転送に伴って、予備パスの予約設定を行い、所望の次現用パス上のノードへ転送し、
   上記の処理を、逐次繰り返し、前記現用パスの始点から終点までの全区間に対して予備パスを設定することを特徴とする予備経路予約方法。
2. 前記メッセージの転送の際に、
   前記メッセージにリスク情報を付加して転送する請求項１記載の予備経路予約方法。
3. 前記リスク情報と、該リスク情報が示す現用パス上の一部が故障した場合に備えるための迂回用の予備パス情報を関連付けるデータベースを用いる請求項２記載の予備経路予約方法。
4. 前記現用パスのリスク情報であるＳＲＬＧ(Shared Risk Link Group)毎に予備パスを用意する請求項１記載の予備経路予約方法。
5. 制御メッセージを用いて現用パス並びに該現用パスに対応する予備パスを予約設定し、故障箇所に応じて切替先予備パスの経路が選択される通信網上のノードに設けられるノード制御装置であって、
   シグナリングによって作成されたパスのセッションＩＤ，経路、リソースを含む情報を格納するパス情報ＤＢと、
   使用可能なラベルと、所定のラベルの状態情報を格納するラベルＤＢと、
   ルーティングのフォワーディングテーブルやトポロジの情報を格納するルーティングＤＢと、
   シグナリングやラベル配布を行うプロトコルであるＲＳＶＰ−ＴＥの機能を実現するＲＳＶＰ−ＴＥ処理手段と、
   前記ＲＳＶＰ−ＴＥ処理手段からのラベルの決定依頼に基づいて、ラベルＤＢを参照して前記ＲＳＶＰ−ＴＥで配布するラベルを決定するラベル処理手段と、
   ＯＳＰＦ，ＲＩＰを含むルーティングプロトコルを処理し、ルーティングＤＢに格納するルーティングプロトコル処理手段と、
   前記ＲＳＶＰ−ＴＥ処理手段からの要求により、前記パス情報ＤＢを参照して、予備パス経路の計算を行い、該ＲＳＶＰ−ＴＥ処理手段に結果を返す経路計算手段と、を有し、
   前記ＲＳＶＰ−ＴＥ処理手段は、
   ネットワークノード上において、前記予備パスを設定する際に、
   前記経路計算手段で計算された前記予備パス経路の計算結果に基づいて、予約設定メッセージを作成する手段と、
   前記予約設定メッセージを、現用パスが通らない迂回経路を介して転送する手段と、
   前記予約設定メッセージの転送に伴って、予備パスの予約設定を行う手段と、を有することを特徴とするノード制御装置。
6. 前記ＲＳＶＰ−ＴＥ処理手段は、
   前記予約設定メッセージの転送の際に、前記メッセージにリスク情報を付加して転送する手段を含む請求項５記載のノード制御装置。
7. 前記パス情報ＤＢは、
   前記リスク情報と、該リスク情報が示す現用パス上の一部が故障した場合に備える迂回用の予備パス情報を関連付ける情報を有する請求項５記載のノード制御装置。
8. 前記ＲＳＶＰ−ＴＥ処理手段は、
   前記現用パスのリスク情報であるＳＲＬＧ毎に予備パスを用意する請求項５記載のノード制御装置。
   

Images