JP2000069031A - Ｒｓｖｐにおける代理フロー構築システムおよび方法 - Google Patents

Abstract

(57)【要約】 【課題】 ノードが閉塞している時間を利用して、一時
的に使用する代理フローを探索し、この代理フローを使
用してデータ転送を開始することにより、長時間ノード
の帯域が空かない場合のリソース予約の効率悪化を解消
する。 【解決手段】 データを送信する送信手段と、送信手段
から送信されたデータを受信する受信手段と、送信手段
と受信手段の間に設置され、相互接続された複数のノー
ドと、を有し、複数のノードは、送信手段から受信手段
に到達する複数のフローが構築可能であり、複数のフロ
ーのうち送信手段から受信手段に到達する最短のフロー
を通常のフローとして使用し、残りのフローを通常のフ
ローを構成するいずれかのノードに障害が発生したと
き、障害が発生したノードを迂回する代理のフローとし
て使用する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークを経
由したデータ転送時にネットワークを構成するノードに
障害が発生したとき、ＲＳＶＰ(Resource Reservation
Protocol)をサポートしているネットワークにおける
代理フローを経由してデータを転送する代理フローの構
築装置および方法に関する。

【０００２】

【従来の技術】ＣＰＵ、バッファ、帯域などの通信に関
するハードウェアやソフトウェア資源であるリソースの
利用帯域とネットワークが提供するサービス品質ＱＯＳ
(Quality Of Service)のサービス品質を提供するＲＳ
ＶＰをサポートしているベストエフォート型サービス
（受信側へのデータ転送は保証しないが、最大限の努力
は行うサービス）のネットワークにおいては、ノードか
らノードへのエンドツーエンドのデータパス上のリソー
ス確保、維持、およびコネクションレスＩＰ（Internet
Protocol）網でのＱＯＳを確保したサービスが可能と
されている。また、リソース不足によるリソース予約失
敗時のAdmission Controlエラーに対し、各ノードに常
駐している予約プログラムを抹消する“killer reserva
tion program”に対する対策も考えられており、リソー
ス予約の効率化も行われていた。

【０００３】ここで、ＲＳＶＰとは、インターネット上
でデータを送受信する際のリソースを確保し、ネットワ
ークが提供するＱＯＳサービス品質を保証するためのプ
ログラムである。中継システム内には、システムがＱＯ
Ｓサービスを確保できる十分な容量があるかどうか判断
するAdmission Controlと、ユーザがＱＯＳサービスの
確保が許可されているかどうかを判断するPolicy Cont
rolの２つの決定モジュールが存在する。Admission Co
ntrolエラーは、この中継システムにリソース確保要求
の問い合わせをしたときに、要求されたＱＯＳサービス
を確保できるだけの十分な容量がないために発生するエ
ラーのことである。

【０００４】従来の通信ネットワークのオペレーティン
グ方法としては、特開平９−２４７１９０号公報に記載
されている方法がある。これは、通信端末で用いられる
アプリケーションのタイプに応じてネットワークリソー
スを割り当てる方法とそのアーキテクチャを提供し、非
同期転送モード（ＡＴＭ：Asynchronous Transmission
Mode）ＲＳＶＰと一体となって、アプリケーションに
よってネットワークリソースの割り当てが可能な必要な
構成要素を有し、インターネットプロトコル／非同期転
送モードを介してリソース予約プロトコルを実行するア
ーキテクチャを提供するものである。

【０００５】

【発明が解決しようとする課題】上述した技術のうち、
あるフローに対しリソース予約の失敗時に、“killer r
eservation program”への対策が行われる方法の場合に
は、予約失敗時のエラーメッセージを受信したノードは
閉塞状態になってしまう。これにより、エラーを検出し
たノードの帯域が空かない限りリソースが確保できない
ため、長期にわたって閉塞状態が継続する可能性があ
り、リソース予約の効率を大きく悪化させる問題があっ
た。これは、ＲＳＶＰにおいてリソース予約を行うフロ
ーは、送信者から受信者に対して送信されるパスメッセ
ージにより、１つに決定され、複数存在しないからであ
る。

【０００６】また、上述した特開平９−２１４５０４号
公報に記載されている方法は、ＡＴＭ通信網を介したデ
ータパケットの配送時、受信側端末から送信される資源
予約メッセージによりＩＰレベルのサービス要求があっ
た場合、ＡＴＭ通信網上の仮想コネクションのリソース
予約は行っているが、リソース予約が失敗したときのこ
とはいっさい考慮されていない。従って、いったんリソ
ース予約が失敗すると、いくら仮想コネクションを利用
しているといっても、仮想コネクションを張り直さない
限り、確実にネットワークの閉塞状態に陥ってしまうと
いう問題点があった。

【０００７】本発明は上述したような従来の技術が有す
る問題点に鑑みてなされたものであって、ノードが閉塞
している時間を利用して、一時的に使用する代理フロー
を探索し、この代理フローを経由してデータ転送を開始
することにより、長時間ノードの帯域が空かない場合の
リソース予約の効率悪化を解消することを目的とする。

【０００８】

【課題を解決するための手段】上記の問題点を解決する
ため、データを送信する送信手段と、送信手段から送信
されたデータを受信する受信手段と、送信手段と受信手
段の間に設置され、相互接続された複数のノードと、を
有し、複数のノードは、送信手段から受信手段に到達す
る複数のフローが構築可能であり、複数のフローのうち
送信手段から受信手段に到達する最短のフローを通常の
フローとして使用し、残りのフローを通常のフローを構
成するいずれかのノードに障害が発生したとき、障害が
発生したノードを迂回する代理のフローとして使用する
ことを特徴とする。

【０００９】また、複数のノードのそれぞれは、複数の
ノードのいずれかに障害が発生したとき障害が発生した
ノードから隣接する下流側のノードに障害の発生を通知
する機能および複数のノードのいずれかのノードに障害
が発生したとき障害が発生したノードを迂回して送信手
段から受信手段に到達するフローを探索する機能を有す
ることを特徴とする。

【００１０】また受信手段は、送信手段と受信手段との
間に設置された複数のノードの予約したいリソースを有
するいずれかのノードにリソースを予約するためのメッ
セージを送信して、ノードのリソースを予約することを
特徴とする。

【００１１】また、送信手段は、通常のフローを構成す
るいずれかのノードに障害が発生したとき、障害が発生
したノードを迂回する代理のフローが複数存在する場
合、複数の代理のフローのうち、送信手段から受信手段
に到達する最短の代理のフローを選択することを特徴と
する。

【００１２】また、送信手段は、障害が発生したノード
のリソース予約が成功した場合、リソースを重複して予
約しないようにすべく、障害が発生した隣接する上流側
のノードにおいて、障害が発生したノードを経由して送
出されたリソースを予約するためのメッセージのフロー
識別子と障害が発生したノードを迂回するフローを経由
して送出されたリソースを予約するためのメッセージの
フロー識別子とを比較し、一致した場合は、障害が発生
したノードを迂回するフローを構成する各ノードに対し
リソースの予約を解除するためのメッセージを送出し
て、リソースの予約を解除することを特徴とする。

【００１３】また、送信手段は、障害が発生したノード
の障害が解消されると、障害が発生したノードを迂回す
るフローから障害が解消されたノードを経由するフロー
に切り替わることを特徴とする。

【００１４】また、複数のフローを構築可能な複数のノ
ードから構成される送信手段と受信手段を備えたリソー
ス予約システムで行われるリソース予約方法であって、
複数のフローのうちのいずれかのフローを構成するノー
ドが有するリソースを予約する第１のステップと、第１
のステップでリソースの予約が成功すると、送信手段か
ら受信手段にフローを経由してデータを転送する第２の
ステップと、第1のステップでノードのリソースの予約
が失敗すると、障害が発生した隣接する上流側のノード
が閉塞状態になる第３のステップと、第３のステップ
で、障害が発生した隣接する上流側のノードが閉塞状態
になったとき、障害が発生したノードを含むノードから
構成されるフローを迂回する代理のフローが存在する場
合、代理のフローを探索し代理のフローの確立が成功す
ると、代理のフローを経由して送信手段から受信手段に
データを転送する第４のステップと、第３のステップで
発生したノードの障害が解消されると、障害が発生した
フローを迂回するフローから障害が解消されたノードか
ら構成される本来のフローに移行し、本来のフローを経
由して送信手段から受信手段にデータを転送する第５の
ステップと、を含むことを特徴とする。

【００１５】上記のように構成される本発明において、
リソース予約が失敗した場合には、ネットワークが閉塞
状態になった期間を利用して、一時的に使用する代理フ
ローが検索され、検索された代理フローを使用してデー
タ転送が開始されるので、長時間閉塞状態が継続して帯
域が空かない場合のリソース予約の効率悪化を防止でき
る。

【００１６】

【発明の実施の形態】本発明の一実施例を図面を参照し
て説明する。

【００１７】本実施例は、ネットワークを経由したデー
タ転送時にネットワークを構成するノードに障害が発生
したとき、ＲＳＶＰをサポートしているネットワークに
おける代理フローを経由してデータを転送するものであ
る。ネットワークを経由してデータを転送するには、詳
述したように、ネットワークを構成する各ノードが有す
るリソース（ＣＰＵ、バッファ、帯域などの通信に関す
るハードウェアやソフトウェア）をあらかじめ予約して
おく必要がある。

【００１８】ところが、もし、リソース不足によりリソ
ースの予約が失敗すると、そのノードを経由するデータ
の転送ができなくなる。そこで、そのエラーが発生した
ノードを迂回してデータの転送を行おうというのが本実
施例の主旨である。

【００１９】図１は、本発明のシステム構成を示す図で
ある。図１に示すように、本実施例は、データを送信す
る送信手段１０と、送信手段１０から送信されたデータ
を受信する受信手段１１と、送信手段１０と受信手段１
１の間に設置され、相互接続された複数のノードＮ
［１］１２〜Ｎ［９］２０と、から構成される。

【００２０】なお、図１において、ネットワークを構成
しているノードＮ［１］１２〜Ｎ［９］２０は上述した
ＲＳＶＰをサポートしており、“killer reservation p
rogram”への対策も行われているとする。

【００２１】送信手段１０と受信手段１１間のノードＮ
［１］１２〜Ｎ［４］１５を接続する太い実線で示すル
ートがデータを転送する通常の通常のフロー３０、ノー
ドＮ［１］１２，Ｎ［５］１６，Ｎ［８］１７，Ｎ
［６］１８，Ｎ［７］１９，Ｎ［４］１５を接続する細
い実線で示すルートが通常のフロー３０が閉塞状態にな
ったとき通常のフロー３０に代わってデータを転送する
代理フロー３１。同様に、Ｎ［２］１３，Ｎ［６］１
８，Ｎ［７］１９，Ｎ［４］１５を接続する細い実線で
示すのが第２の代理フロー３２である。図中、送信手段
1０から受信手段１１間において、送信手段１０側に近
い方を上流側、受信手段１１側に近い方を下流側とす
る。

【００２２】なお、本実施例における複数のノードは、
複数のノードにいずれかのノードに障害が発生したと
き、障害が発生したノードから隣接する下流側のノード
に障害の発生を通知する機能と、複数のノードのいずれ
かのノードに障害が発生したとき障害が発生したノード
を迂回して送信手段から受信手段にデータを転送する機
能とを有している。

【００２３】図２は、実際の各ノード間の接続を示す図
である。一般に、ノードとは、通信ネットワークにおい
て、大型コンピュータ、交換機、端末、プリンタなどの
総称を指すものが、図においては、大型コンピュータ５
０，５５、端末５１，５２，５４、交換機５３が示され
ている。

【００２４】図３は、通常のフロー３０にリソース不足
によるAdmission Controlエラーが発生した場合を示す
図である。

【００２５】図３を参照しながら本実施例の動作を簡単
に説明する。

【００２６】図３の通常のフロー３０を構成している各
ノードＮ［１］１２〜Ｎ［４］１５に対し、送信手段１
０から受信手段１１に通常のフロー３０のパスを設定す
るメッセージPath Message４０を送出する。Path Mes
sage４０が上記のノードを経由して送信手段１０から受
信手段１１に無事到着すれば、Path Message４０が通
過した各ノードから構成されるルートがリソース予約フ
ローになるため、このフローに従って通常のフローを構
成する各ノードに対してリソース予約を行うメッセージ
ResvMessage４１を通常のデータ転送とは逆の受信手段
１１から送信手段１０に送出する。これで、何もエラー
が発生しなければ、通常のフローを構成する各ノードに
対するリソース予約を完了したことになるが、ここで、
例えば、図３に示すように、通常のフロー３０のノード
Ｎ［３］１４でリソース不足によるAdmission Control
エラーが発生した場合、エラーが発生したノードＮ
［３］１４は、上流側のノードＮ［４］１５にリソース
予約エラーメッセージResv Err Message４２を送出す
る。ノードＮ［３］１４からResv Err Message４２を
受信するとノードＮ［４］１５は閉塞状態になり、これ
と同時にエラーが発生したノードＮ［３］１４を迂回し
て送信手段１０まで到達できる代理ルートの探索を開始
する。

【００２７】ノードＮ［４］１５は、このとき、２つの
代理フロー３１，３２のいずれか１つを選択する。どの
代理ルートを選択するかその選択基準となるのは、各ノ
ード間の接続関係を示す経路情報に基づいており、エラ
ーが発生したノードの上流側のノードから複数のフォー
ワーディングルートを検索して、送信手段１０から目的
のノードまで最も近い最短フローを選択する。

【００２８】本実施例においては、図４に示すように、
２つの代理フロー３１，３２を真っ直ぐに延ばしてみる
と、フロー３２の方が短いことがわかる。従って、この
場合は、ノード（Ｎ［１］１２→Ｎ［２］１３→Ｎ
［６］１８→Ｎ［７］１９→Ｎ［４］１５）から構成さ
れる代理フロー３２が選択される。図３に戻り、ノード
Ｎ［４］１５から選択された代理フロー３２の各ノード
に対してリソースを予約するメッセージProxy Resv M
essage４３を送出して、代理フローの予約を行う。こう
して、代理フロー上３２の各ノードに対するリソース予
約を完成する。

【００２９】送信手段１０は、図５に示すように、代理
フロー３２を経由したProxy ResvMessage４３を受信し
た時点で、代理フロー３２の存在を認識し、代理フロー
３２を経由したデータ６０の転送を開始する。

【００３０】その後、図６に示すように、ノードＮ
［３］１４に発生したAdmission Controlエラーが解消
され、Ｎ［４］１５の閉塞状態が解除されると、送信手
段１０が受信手段１１からResv Message４１を受信し
た時点で代理フロー３１を経由したデータ６０の転送を
中止して代理フロー３１を解除し、通常のフロー３０に
切り替えて通常のフロー３０を経由したデータ転送を行
う。

【００３１】ここで、代理フローの確立や解除に用いら
れる各メッセージの機能と用途を簡単に説明しておく。
なお、各メッセージのフォーマットの説明は省略する。

【００３２】（１）Path Message 通常のフローのパス設定メッセージ。リソース予約を行
う通常のフローのパスを張るメッセージで、リソース予
約の開始の最初に送信手段1０から受信手段１１に送出
される。

【００３３】（２）Resv Message リソース予約メッセージ。送信手段1０から送出されたP
ath Message４０を受信し、このメッセージに対する応
答として受信手段１１から送信手段1０に返されるメッ
セージ。通常のフローを構成する各ノードのリソース予
約が可能になる。

【００３４】（３）Proxy Resv Message 代理フロー確立メッセージ。通常のフローを構成するノ
ードのリソース予約時にAdmission Controlエラーが発
生したとき、代理フローを確立するための通常のフロー
にエラーが発生したノードの下流側のノードから代理フ
ローを構成する各ノードに送出される。Proxy Resv M
essage４３は、代理フローに対するリソース予約の開始
指定、エラーが発生したノードのＩＰアドレスの内容を
含むProxy Resv Message４３を複数のインタフェース
に送出するノードが存在する場合に、候補としてあげら
れた複数の代理フローを識別するためのＩＰアドレスの
保持エリア（以降、代理識別子と呼ぶ）を持つ点が異な
るだけでその他はResv Message４１と同じである。

【００３５】（４）Teardown Message 通常のフロー予約取り消しメッセージ。Resv Message
４１により予約された通常のフローの予約を取り消すた
め通常のフローを構成する各ノードに対して送出され
る。

【００３６】（５）Proxy Teardown Message 代理フロー予約取り消しメッセージ。Proxy Resv Mes
sage４３により代理フローのリソースを重複して予約す
るのを防止するため送信手段1０から代理フローに送出
される。Teardown Message４４と同じ内容であるが、
代理識別子エリアの内容が含まれ、代理フローの解除を
示すProxyEndBitが用意されている点が異なる。

【００３７】（６）Resv Err Message Admission Controlエラー発生通知メッセージ。リソー
ス不足による通常のフローのノードにAdmission Contr
olエラーが発生したノードから上流側のノードに送出さ
れる。

【００３８】（７）Non-Search Message 代理フロー探索禁止メッセージ。ノードが閉塞状態にな
って、ResErrMessageを受信しても代理ノードの探索を
行わないことをエラーが発生したノードの上流側のノー
ドに送出される。

【００３９】こられのメッセージうち、特に、Proxy R
esv Message４３にはＩＰアドレス（サブフロー識別子
（図示せず）として使用）が設定され、代理フローの予
約に使用される。 また、Proxy Teardown Message４
６にはProxyEndBitが用意され、代理フローのリソース
の予約解除に使用される。

【００４０】図７は、本実施例の状態の移行を示す状態
遷移図である。

【００４１】本実施例の代理フロー探索装置は、状態の
変化に応じて以下のように状態が移行する。まず、リソ
ース予約を開始し（状態７０）、リソース予約が成功す
ると、通常のフローを経由して目的のノードにデータを
転送する（状態７２）。リソース予約が失敗すると、ノ
ードが閉塞状態になる（状態７１）。状態７１で、ノー
ドの閉塞状態が解除されれば、代理フローの探索に移行
せずに再びリソース予約ができる状態７０になる。ノー
ドが閉塞状態になったとき、代理フローが存在する場合
は、ノード間の接続関係等を含むノードの経路情報を基
に代理フローの探索を開始する。探索の結果、代理フロ
ーの確立が成功すると（状態７３）、代理フローを経由
して目的のノードにデータを転送する。こうして、リソ
ースの予約が成功すると、代理フローを解除し通常のフ
ローにルートを切り替えて、通常のフローを経由したデ
ータの転送を開始する。

【００４２】また、本実施例の動作は、以下の３つのフ
ェーズから成る。各フェーズのデータやメッセージの流
れを示す各フロー制御の説明を以下に示す。

【００４３】図８は、通常のフローを経由したリソース
予約時のフロー制御を示す図である。図８において、ノ
ードＮ［１］１２〜Ｎ［７］１９が送信手段１０から受
信手段１１の間に配置されているが、このうちノードＮ
［１］１２〜Ｎ［４］１５が通常のフロー、ノードＮ
［５］１６〜Ｎ［８］１９が代理フローを構成するノー
ドである。また、各ノードから下に延びている線が太い
実線で示されているときは、それらのノードがその時点
でメッセージやデータの送受信に関与していることを示
し、細い点線で示されているときは関与していないこと
を示す。

【００４４】（１）通常のフローを経由したリソース予
約 それでは、図８のフロー制御の流れに従って順に説明し
ていく。送信手段１０から受信手段１１に通常のフロー
の各ノードＮ［１］１２〜Ｎ［４］１５を経由してPath
Message４０が送出される。 Path Message４０が受
信手段１１に無事に到着すると、Path Message４０が
通過したノードＮ［１］１２〜Ｎ［４］１５から構成さ
れる通常のフロー３０がリソース予約を行うフローにな
り、このフローに従って受信手段１１から信手段１０に
Resv Message４１を送出し、通常のフロー３０を構成
する各ノードに対しリソース予約を開始する。

【００４５】しかし、図８のように、例えば、ノードＮ
［３］１４でリソース不足によるAdmission Controlエ
ラーが発生した場合、エラーが発生したノードＮ［３］
１４からノードＮ［４］１５にエラーの発生を通知する
Resv Err Message４２が送出される。そして、ノード
Ｎ［３］１４はこのメッセージを受信して閉塞状態にな
ると同時に、ノードＮ［３］１４からノードＮ［２］１
３，Ｎ［１］１２，送信手段１０に閉塞状態になっても
これらのノードから構成される代理フローの探索を禁止
するNon-Search Message４３を送出する。こうして、N
on-Search Message４３を受信したノードＮ［１］１
２，Ｎ［２］１３、送信手段１０は代理フローの探索を
行わない。このように、ノードＮ［１］１２，Ｎ［２］
１３に代理フローの探索を禁止するNon-Search Messag
e４３を送出するのは、ノードＮ［１］１２とＮ［２］
１３がノードＮ［３］１４に対し受信手段１１に至るフ
ォーワードルートでなく、送信手段１０に至るバックワ
ードルートであるからである。

【００４６】なお、ここでいう閉塞状態とは、一定時間
経過後のリトライ失敗も含めた状態のことをいう。

【００４７】（２）代理フローの確立 図９，図１０は、代理フローの確立を示すフロー制御を
示す図である。

【００４８】続いて、通常のフロー３０にAdmission co
ntrolエラーが発生したとき、代理フローを探索し、こ
のうち最短の代理フロー３２を選択する場合を例にとり
説明する。Admission Controlエラーが発生したノード
Ｎ［３］１４の上流側のノードＮ［４］１５から代理フ
ロー３２を構成するＮ［７］１９，ノードＮ［７］１９
からＮ［６］１８，およびノードＮ［６］１８からＮ
［８］１７にProxy Resv Message４４を送出して、代
理フローの探索を開始する。

【００４９】ノードＮ［４］１５からProxy Resv Mes
sage４４を受信した代理フローのノードＮ［７］１９
は、２つの代理フロー３１，３２が存在することを探索
した時点で、ノードＮ［３］１４がAdmission Control
エラー発生ノードであることをProxy Resv Message４
４から認識して、ノードＮ［６］１８にのみProxy Res
v Message４４を送出する。Proxy Resv Message４４
を受信したノードＮ［６］１８は、ノードＮ［２］１３
とＮ［８］１３が共にAdmission Controlエラーが発生
したノードではないので、Proxy Resv Message４４を
この２つのノードに送出する。この際、Proxy Resv M
essage４４の代理識別子エリアに送信先の宛先となるノ
ードＮ［２］１３およびＮ［８］１７のＩＰアドレス
（サブフロー識別子として使用）を格納して送出する。
ノードＮ［８］１７の上流側のノードＮ［１］１２，Ｎ
［２］１３，Ｎ［５］１６，Ｎ［８］１７も同様に送信
先のＩＰアドレスを格納してノードＮ［１］１２から送
信手段１０，ノードＮ［２］１３からＮ［３］１４，Ｎ
［５］１６からＮ［１］１４，ノードＮ［８］１７から
Ｎ［５］１６にそれぞれProxy Resv Message４４を送
出するので、送信手段１０には、１つまたは複数のProx
y Resv Message４４が到着することになる。

【００５０】その結果、ノードＮ［１］１２では、通常
のフロー３０および代理フロー３２を経由したProxy R
esv Message４４を２方向から受信することになるが両
方のフロー識別子が同じであれば、ネットワークの過負
荷を防ぐためリソースを重複して予約しないようにす
る。送信手段１０は、最初に受信したProxy Resv Mes
sage４４を送信手段１０→Ｎ［１］１２→Ｎ［２］１３
→Ｎ［６］１８→Ｎ［７］１９→Ｎ［４］１５→受信手
段１１を経由する代理フロー３２からのものと認識し、
後から受信したすべてのProxy Resv Message４４に対
し、代理フローの予約取り消しを行うためProxy Teard
own Message４６、代理フローのノードＮ［５］１６と
Ｎ［８］１７に送出する。そして、以上により確立され
る代理フロー３２を経由し、最終ホップを使用してデー
タ転送を開始する。

【００５１】データ通信分野において、ホップとは、通
常送信先から送信元へのルータ間のデータの転送をい
う。すなわち、ここでは、ルータ間の最後のデータ転送
を意味する。

【００５２】（３）代理フローの解除および通常のフロ
ーへの切り替え 図１１は、代理フローの解除と通常のフローへの切り替
えを示すフロー制御を示す図である。

【００５３】ノードＮ［３］１４のAdmission Control
エラーが解消されリソース予約が成功すると、ノードＮ
［１］１２，Ｎ［２］１３は、通常のフロー３０および
代理フローを経由した２方向からResv Message４１を
受信する。そこで、受信した両方のResv Message４１
のフロー識別子とProxy Resv Message４３のフロー識
別子とを比較して、一致した場合は、リソースを重複し
て予約しないように代理フローのリソース予約を解除す
る。送信手段1０はResvMesage４１を受信すると、代理
フローに対し、Proxy Teardown Message４６にProxyE
ndBitを立てて送出する。これにより、代理フローを構
成している各ノードＮ［１］１２，Ｎ［２］１３，Ｎ
［６］１８，Ｎ［７］１９，Ｎ［４］１５のリソース予
約が解除される。しかし、ノードＮ［１］１２，Ｎ
［２］１３，Ｎ［４］１５については、Resv Message
４１によってリソースが予約されているため予約状態を
変えない。ノードＮ［４］１５は、ProxyEndBitが立っ
ているProxyTeardowmMessage４６を受信してから、本来
の通常のフロー３０を経由したデータ転送を開始する。

【００５４】以上により、代理フローから通常のフロー
への切り替え処理が終了する。

【００５５】代理フローを解除する際、フロー識別子だ
けでなく代理識別子エリア（図示せず）も参照して、該
当フローに対しProxy Teardown Message４６を送出す
る。通常、最終ホップを使用して本メッセージを送出す
ることにより、Proxy ResvMessage４３の送出を開始し
たノードＮ［４］１５まで本メッセージが到達すること
になるが、複数のインタフェースに対し、 Proxy Resv
Message４３を送出したノードＮ［６］１８（代理識
別子エリアに格納されたＩＰアドレスと送信元アドレス
が一致するノード）は、 Proxy Resv Message４３に
よる代理フローに対するすべてのProxy Teardown Mes
sage４６が戻ってこない場合には、Proxy Resv Messa
ge４３の送出を停止する。なお、リソースを解放する際
は、Proxy Teardown Message４６を受信するノード
は、フロー識別子および代理識別子エリアを参照して、
該当する代理フローのみ解除する。つまり、ノード内に
代理フローに対するリソース予約が存在する限り、リソ
ース予約を解除しないでResv Message４１で設定され
た帯域と同じ帯域を予約し続ける。

【００５６】なお、代理フローを構築する前に、Resv
Message４１による通常のフローが確立されていた場合
には、通常のフロー３０を構成している各ノードは、Pr
oxyResv Message４３を受信した時点で、代理フローの
識別子を既に確立されている通常のフロー３０のフロー
識別子と比較して、一致した場合には、Proxy Resv M
essage４３に対して、すぐにProxy Teardown Message
４６を送出して、代理フローのリソース解除を行う。

【００５７】図１２〜１４は、本実施例の動作を示すフ
ローチャートである。

【００５８】次に、本発明の一実施例を図１２〜１５を
参照して詳細に説明する。

【００５９】まず、送信手段1０から通常のフロー（Ｎ
［１］１２，Ｎ［２］１３，Ｎ［３］１４，Ｎ［４］１
５）３０を通過して受信手段１１にPath Message４０
を送出する（ステップＳ１００）。受信手段１１がPath
Message４０を受信したかどうか判断し、Path Messa
ge４０を受信していない場合は、ステップＳ１００に戻
ってPath Message４０の送出を続ける（ステップＳ１
０１）、ステップＳ１０１で、受信手段１１がPath Me
ssage４０を受信した場合は、受信手段１１から送信手
段１０にResv Message４１を送出する（ステップＳ１
０２）。そして、通常のフロー３０を構成する各ノード
のリソースの予約が成功したかどうか判断し（ステップ
Ｓ１０３）、リソースの予約が成功した場合は、送信手
段１０から受信手段１１にデータを転送して、終了する
（ステップＳ１０４）。

【００６０】以上が図８に示した通常のフロー３０を経
由したリソース予約処理である。

【００６１】ステップＳ１０３で、リソースの予約が失
敗した場合は、リトライするかどうか判断し、リトライ
する場合は、ステップＳ１０２に戻って、Resv Messag
e４１を再送する（ステップＳ１０５）。リトライしな
い場合は、リソース予約失敗の原因が、例えば、ノード
Ｎ［３］１４でリソース不足によるAdmission Control
エラーが発生したかどうか判断し（ステップＳ１０
６）、ノードＮ［３］１４でエラーが発生した場合は、
エラーが発生したノードＮ［３］１４を迂回して送信手
段１０に到達する代理フローが存在するかどうか判断す
る（ステップＳ１０７）。代理フローが存在しない場合
は、もう一度通常のフロー３０を構成する各ノードの予
約を試みるためリトライするかどうか判断し、リトライ
する場合には、ステップＳ１００に戻って、Path Mess
age４０を再送し、リトライしない場合は、終了する
（ステップＳ１０８）。代理フローが存在する場合は、
ノードＮ［３］１４の上流側のノードＮ［４］１５に通
常のフロー３０の予約失敗を通知するメッセージResv
Err Message４２を送出する（ステップＳ１０９）。そ
して、ノードＮ［３］１４からノードＮ［１］１２，Ｎ
［２］１３，送信手段１０にバックワードルートの探索
の禁止を通知するメッセージNon-Search Message４３
を送出する（ステップＳ１１０）。続いて、ノードＮ
［４］１５から代理フローのノードＮ［７］１９，ノー
ドＮ［７］１８からＮ［６］１９，ノードＮ［６］１９
からＮ［２］１３とＮ［８］１７，ノードＮ［５］１６
からＮ［１］１２，ノードＮ［２］１３からＮ［１］１
２，ノードＮ［１］１２から送信手段１０にProxy Res
v Message４４を送出する（ステップＳ１１１）。代理
フローを構築する前に、Resv Message４１による本来
のフロー３０を確立していた場合、本来のフロー３０を
構築している各ノードは、ProzyResvMessage４４２を受
信した時点で、代理フローの識別子を、既に完成してい
る本来のフローのフロー識別子と比較して、一致した場
合は、Proxy Resv Message４４に対して即時にProxy
Teardown Message４６を送出して、代理フローのリ
ソース解除を行う。

【００６２】以上のようにノードＮ［１］１２，送信手
段１０には、１つまたは複数のResvMessage４４が到達
することになるので、送信手段１０で複数のProxy Res
vMessage４４を受信したかどうか判断する（ステップＳ
１１２）。送信手段１０が複数のProxy Resv Message
４４を受信した場合は、２方向からProxy ResvMessage
４４のフロー識別子と代理識別子とを比較して、代理フ
ローかどうかチェックする（ステップＳ１１３）。２方
向から受信したフロー識別子と代理識別子が同じであれ
ば、送信手段１０は最初に受信したProxy Resv Messa
ge４４を代理フロー２２からのものと認識し、リソース
を重複して予約しないように、代理フロー３２以外の代
理フロー３１の各ノードＮ［５］１６，Ｎ［８］１７に
送信手段１０からProxy Teardown Message４６を最終
ホップを使用して送出する（ステップＳ１１４）。この
ように該当するフローのみ解除する。つまり、ノード内
に代理フローに対するリソース予約が存在する限り、Re
sv Message４１で設定されるべき帯域と同じ帯域を予
約し続ける。そして、ノードＮ［６］１８で、Proxy T
eardown Message４６を受信したかどうか判断する（ス
テップＳ１１５）。通常、最終ホップを使用して本メッ
セージを送出することにより、Proxy Resv Message４
４の送出を開始したノードＮ［４］１５まで本メッセー
ジが到達するが、代理識別子エリアに格納されたＩＰア
ドレスと送信元アドレスが一致するノードＮ［８］１８
は、Proxy Resv Message４４に対するProxyResvTeard
ownMessage４６が戻ってこない場合は、Proxy Resv M
essage４４の送出を停止する。ノードＮ［６］１８でPr
oxy Teardown Message４６を受信した場合は、Proxy
Resv Message４４の送出を停止する（ステップＳ１
１６）。代理フローが確立されたかどうか判断し（ステ
ップＳ１１７）、代理フローが確立されていない場合
は、上述したステップＳ１１１に戻る。代理フローが確
立された場合は、送信手段１０から受信手段１１に代理
フローを経由してデータを転送する（ステップＳ１１
８）。

【００６３】以上が図９，図１０に示した代理フローの
確立処理である。

【００６４】ノードＮ［３］１４のAdmission Control
エラーが解消され、ノードＮ［３］１４のリソース予約
が成功したかどうか判断し、失敗した場合は、ステップ
Ｓ１１８に戻り（ステップＳ１１９）、成功した場合
は、ノードＮ［２］１３，ノードＮ［１］１２，送信手
段１０が受信手段１１からResv Message４１を受信す
る（ステップＳ１２０）。この際、代理フロー３２を経
由したリソースが既に予約されていた場合は、ノードＮ
｛１｝１２とＮ［２］１３は受信したResv Message４
１のフロー識別子とProxy Resv Message４４のフロー
識別子とを比較して、一致した場合は、リソースを重複
して予約しないようにするため、ノードＮ［１］１２と
Ｎ［２］１３で、Proxy Resv Message４４のフロー識
別子とResvMessage４１のフロー識別子とを比較する
（ステップＳ１２１）。一致した場合は、代理フローを
構成する各ノードＮ［１］１２，Ｎ［２］１３，Ｎ
［４］１５，Ｎ［６］１８，Ｎ［７］１９にProxyEndBi
tを立ててProxy Teardown Message４６を送出し、リ
ソースの二重予約を防止する（ステップＳ１２２）。た
だし、Ｎ［１］１２，Ｎ［２］１３，Ｎ［４］１５につ
いては、Resv Message４１によりリソース予約がなさ
れているため予約状態を変えない。ProxyTeardownResvM
essage４６のフロー識別子とResv Message４１のフロ
ー識別子が一致しない場合は、ノードＮ［４］１５がPr
oxy Teardown Message４６を受信したかどうか判断す
る（ステップＳ１２３）。ノードＮ［４］１５がProxy
Teardown Message４６を受信した場合は、代理フロ
ー３２から通常のフロー３０に切り替えて、送信手段１
０から受信手段１１に通常のフロー３０を経由してデー
タを転送する（ステップＳ１２４）。

【００６５】以上が図１１に示した代理フローの解除お
よび通常のフローへの切り替え処理である。

【００６６】以上のように、リソース不足が発生した場
合に、本来の通常のフローとは別に代理フローを構築
し、代理フローを経由したデータの転送を行ってリソー
ス予約の効率化を可能にする。

【００６７】

【発明の効果】以上のように、本発明によれば、リソー
ス不足からリソース予約に失敗した場合は、予約失敗の
メッセージを受信したノードはエラーを検出したノード
のリソース予約が成功するまで閉塞状態で待ち続けるこ
とになるが、この期間を利用して、本来のフローとは別
に一時的に使用する代理フローを検索して、代理フロー
が存在する場合は、パスメッセージにより指定されたフ
ローのリソース予約が完成するまでの間、代理フローを
経由してデータを送出して、リソース予約における効率
化が可能となる。

【図面の簡単な説明】

【図１】本発明のシステム構成を示す図である。

【図２】ネットワークを構成する各ノードの接続とノー
ドの構成要素を示す図である。

【図３】代理フローの探索を示す図である。

【図４】最短フローパスを示す図である。

【図５】代理フローを経由したデータの転送を示す図で
ある。

【図６】代理フローから通常のフローに切り替えた後の
データ転送を示す図である。

【図７】本実施例の状態遷移図を示す図である。

【図８】通常のフローを経由したリソース予約のフロー
制御を示す図である。

【図９】代理フロー確立のフロー制御を示す図である。

【図１０】代理フロー確立のフロー制御を示す図であ
る。

【図１１】代理フロー解除および通常のフローへの切り
替えのフロー制御を示す図である。

【図１２】本実施例の動作を示すフロ−チャートであ
る。

【図１３】本実施例の動作を示すフローチャートであ
る。

【図１４】本実施例の動作を示すフローチャートであ
る。

【符号の説明】

１０ 送信手段 １１ 受信手段 １２，１３，１５，１６，，１７，１８，１９，２０，
５０，５１，５２，５３，５４，５５ ノード ４０ Path Message ４１ Resv Message ４２ Resv Err Message ４３ Non-Search Message ４４ Proxy Resv Message ４５ Teardown Message ４６ Proxy Teardown Message ６０ リソース予約状態 ６１ ノード閉塞状態 ６２ リソース予約成功状態 ６３ 代理フロー確立状態

Claims (7)

【特許請求の範囲】
1. 【請求項１】 データを送信する送信手段と、 前記送信手段から送信されたデータを受信する受信手段
   と、 前記送信手段と前記受信手段の間に設置され、相互接続
   された複数のノードと、を有し、 前記複数のノードのそれぞれは、前記送信手段から受信
   手段に到達する複数のフローを構築可能であり、該複数
   のフローのうち前記送信手段から受信手段に到達する最
   短のフローを通常のフローとして使用し、残りのフロー
   を該通常のフローを構成するいずれかのノードに障害が
   発生したとき、該障害が発生したノードを迂回する代理
   のフローとして使用することを特徴とする代理フロー構
   築システム。
2. 【請求項２】 請求項１記載の代理フロー構築システム
   において、 前記複数のノードのそれぞれは、該複数のノードのいず
   れかに障害が発生したとき該障害が発生したノードから
   隣接する下流側のノードに障害の発生を通知する機能お
   よび前記複数のノードのいずれかのノードに障害が発生
   したとき障害が発生したノードを迂回して前記送信手段
   から受信手段に到達するフローを探索する機能を有する
   ことを特徴とする代理ノ−ド構築装置。
3. 【請求項３】 請求項１または２項記載の代理フロー構
   築システムにおいて、 前記受信手段は、前記送信手段と受信手段との間に設置
   された複数のノードの予約したいリソースを有するいず
   れかのノードにリソースを予約するためのメッセージを
   送信して、該ノードのリソースを予約することを特徴と
   する代理フロー構築システム。
4. 【請求項４】 請求項１ないし３項のいずれか１項に記
   載のリソース予約システムにおいて、 前記送信手段は、前記通常のフローを構成するいずれか
   のノードに障害が発生したとき、該障害が発生したノー
   ドを迂回する代理のフローが複数存在する場合、該複数
   の代理のフローのうち、前記送信手段から受信手段に到
   達する最短の代理のフローを選択することを特徴とする
   代理フロー構築システム。
5. 【請求項５】 請求項１ないし４項のいずれか１項に記
   載のリソース予約システムにおいて、 前記送信手段は、前記障害が発生したノードのリソース
   予約が成功した場合、リソースを重複して予約しないよ
   うにすべく、前記障害が発生した隣接する上流側のノー
   ドにおいて、前記障害が発生したノードを経由して送出
   されたリソースを予約するためのメッセージのフロー識
   別子と前記障害が発生したノードを迂回するフローを経
   由して送出されたリソースを予約するためのメッセージ
   のフロー識別子とを比較し、これらが一致した場合に
   は、前記障害が発生したノードを迂回するフローを構成
   する各ノードに対しリソースの予約を解除するためのメ
   ッセージを送出して、リソースの予約を解除することを
   特徴とするリソース予約システム。
6. 【請求項６】 請求項１ないし５項のいずれか１項に記
   載のリソース予約システムにおいて、 前記送信手段は、前記障害が発生したノードの障害が解
   消されると、前記障害が発生したノードを迂回するフロ
   ーから前記障害が解消されたノードを経由するフローに
   切り替えることを特徴とするリソース予約システム。
7. 【請求項７】 複数のフローを構築可能な複数のノード
   から構成される送信手段と受信手段を備えたリソース予
   約システムで行われるリソース予約方法であって、 前記複数のフローのうちのいずれかのフローを構成する
   ノードが有するリソースを予約する第１のステップと、 前記第１のステップでリソースの予約が成功すると、前
   記送信手段から受信手段に前記フローを経由してデータ
   を転送する第２のステップと、 前記第1のステップで前記ノードのリソースの予約が失
   敗すると、該障害が発生した隣接する上流側のノードが
   閉塞状態になる第３のステップと、 前記第３のステップで、障害が発生した隣接する上流側
   のノードが閉塞状態になったとき、障害が発生したノー
   ドを含むノードから構成されるフローを迂回する代理の
   フローが存在する場合、該代理のフローを探索し該代理
   のフローの確立が成功すると、該代理のフローを経由し
   て前記送信手段から受信手段にデータを転送する第４の
   ステップと、 前記第３のステップで発生したノードの障害が解消され
   ると、前記障害が発生したフローを迂回するフローから
   障害が解消されたノードから構成される本来のフローに
   移行し、該本来のフローを経由して前記送信手段から受
   信手段にデータを転送する第５のステップと、を含むこ
   とを特徴とする代理フロー構築方法。