JP3871538B2 - ネットワークリソース予約制御方法及びノード - Google Patents
ネットワークリソース予約制御方法及びノード Download PDFInfo
- Publication number
- JP3871538B2 JP3871538B2 JP2001307905A JP2001307905A JP3871538B2 JP 3871538 B2 JP3871538 B2 JP 3871538B2 JP 2001307905 A JP2001307905 A JP 2001307905A JP 2001307905 A JP2001307905 A JP 2001307905A JP 3871538 B2 JP3871538 B2 JP 3871538B2
- Authority
- JP
- Japan
- Prior art keywords
- reservation
- terminal
- resource
- node
- interface
- 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
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワークリソース予約制御方法及びノードに関する。
【０００２】
【従来の技術】
ＩＰネットワーク上で、画像や音声などのリアルタイムのデータストリームのトラフィックが今後増えることが予想される。このようなデータストリームのトラフィックは、従来型のトラフィックと異なり、ネットワークで帯域などを定常的に保証してやる必要がある。すなわち、アプリケーションが必要とする帯域などのネットワークリソースを予約したり解除したり維持したりするなど、制御することを要する。
【０００３】
従来より、ＩＰネットワーク上で、ネットワークのユーザ（アプリケーション）が、帯域などのネットワークリソースを予約するための従来技術として、ＲＳＶＰ（Resource Reservation Protocol）が標準化されている。例えば、ＲＳＶＰ方式では、インターネット上で予約（占有）しているリソースを、その全てのルータがデータストリーム単位で管理している。
【０００４】
また、従来の専用線を用いた予約方法のイメージに近いDiffserv（Differentiated Service）と、Policyサーバとを組み合わせて運用することにより、ユーザが必要な帯域をネットワークで確保する仕組みも標準化されている。
【０００５】
【発明が解決しようとする課題】
しかしながら、上述のようなネットワークリソースの予約方式によれば、以下のような課題があった。
【０００６】
ＲＳＶＰ方式では、ネットワークが大規模となり、そこを流れるデータストリームの数が莫大なものになったときに、各ルータでリソースを管理するための負荷が大きくなる。そのため、一般にはＲＳＶＰ方式は小規模ネットワーク程度しか利用されていない。
【０００７】
また、DiffservとPolicyサーバとを組み合わせた方式は、オンデマンドでユーザの要求を受け付けるような構成にはなっていない。
【０００８】
そのため、大、中規模ネットワークに対しても適用可能なネットワークリソース予約制御方法及びノードや、オンデマンドでユーザの要求を受け付けてネットワークリソースの予約を実行できるネットワークリソース予約制御方法及びノードが求められており、しかも、そのようなネットワークリソース予約制御方法及びノードは、ネットワークの故障にも対応できることが望まれている。
【０００９】
【課題を解決するための手段】
第１の本発明は、第１の端末及び第２の端末間のデータ転送に１以上のノードが介在するネットワークに対し、少なくともリソースを予約するネットワークリソース予約制御方法において、（１）上記第１の端末又は第２の端末を収容しているエッジノードは、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部と、リソース予約の受付用情報を記憶する予約管理データ記憶部とを備え、（２）上記第１の端末又は第２の端末を収容していないコアノードは、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部とを備え、（３）上記第１の端末から上記第２の端末へ、リソース予約を要求する予約要求メッセージ、リソース予約量を変更する変更要求メッセージ、又は、予約リソースを削除させる削除要求メッセージを送出し、上記第２の端末から上記第１の端末へ要求に対する応答メッセージを送出し、（４）各ネットワーク要素に対して、リソース予約、予約変更、削除を実行させると共に、上記各ノードが、各種要求メッセージ又は各種応答メッセージの受信により、上記各データ記憶部の内容を更新することを特徴とする。
【００１０】
第２の本発明は、第１の端末及び第２の端末間のデータ転送に１以上のノードが介在するネットワークにおける、上記第１の端末又は上記第２の端末を収容したノードにおいて、（１）転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部と、リソース予約の受付用情報を記憶する予約管理データ記憶部とを備え、（２）上記第１の端末から上記第２の端末への、リソース予約を要求する予約要求メッセージ、リソース予約量を変更する変更要求メッセージ、又は、予約リソースを削除させる削除要求メッセージを転送し、上記第２の端末から上記第１の端末への要求に対する応答メッセージを転送し、（３）リソース予約、予約変更、削除を実行すると共に、各種要求メッセージ又は各種応答メッセージの受信により、上記各データ記憶部の内容を更新することを特徴とする。
【００１１】
第３の本発明は、第１の端末及び第２の端末間のデータ転送に１以上のノードが介在するネットワークにおける、上記第１の端末又は上記第２の端末を収容したノードにおいて、（１）転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部とを備え、（２）上記第１の端末から上記第２の端末への、リソース予約を要求する予約要求メッセージ、リソース予約量を変更する変更要求メッセージ、又は、予約リソースを削除させる削除要求メッセージを転送し、上記第２の端末から上記第１の端末への要求に対する応答メッセージを転送し、（３）リソース予約、予約変更、削除を実行すると共に、各種要求メッセージ又は各種応答メッセージの受信により、上記各データ記憶部の内容を更新することを特徴とする。
【００１２】
第１〜第３の本発明において、各ノード（又は単）が、故障検出時に、故障検出に係るインタフェースを経路としている他のネットワーク要素に対し、故障通知メッセージを送出する故障管理部を有することが好ましい。
【００１３】
また、各ノードの故障管理部は、故障検出したインタフェース及び上記各データ記憶部の内容に基づき、上記故障通知メッセージを送出するネットワーク要素を認識することが好ましい。
【００１４】
さらに、各ノードの故障管理部は、他のネットワーク要素から、上記故障通知メッセージを受信したときに、受信した故障通知メッセージの内容、受信したインタフェース並びに上記各データ記憶部の内容に基づき、故障通知メッセージをさらに転送するネットワーク要素を認識して故障通知メッセージを転送することが好ましい。
【００１５】
さらにまた、各ノードは、隣接するネットワーク要素との間で、上記リソース管理データ記憶部の記憶内容に基づいて、作成した維持メッセージを授受し合い、維持メッセージの受信異常などに応じて、リンクなどの故障を検出することが好ましい。
【００１６】
また、各ノードは、上記故障通知メッセージの生成送出時や、故障通知メッセージの転送処理時に、上記各データ記憶部の故障に係る経路の情報をクリアすることが好ましい。
【００１７】
【発明の実施の形態】
（Ａ）第１の実施形態
以下、本発明によるネットワークリソース予約制御方法及びノードの第１の実施形態を図面を参照しながら詳述する。
【００１８】
この第１の実施形態は、インターネットのようなネットワーク上で、帯域などのネットワークリソースを、ユーザがオンデマンドで予約、変更、解除し得るようにしたものであり、また、いずれかのリソースの故障にも対応してネットワークリソースの予約制御を実行するようにしたものである。
【００１９】
（Ａ−１）第１の実施形態の構成
この第１の実施形態が対象としているネットワークＮは、通信事業者などが管理するものであり、図２に示すように、複数のノード２、３がリンク４を介してメッシュ、リンク状、バス状の任意の接続形態で接続されて構成されているものであり、適宜のノード２は端末（ユーザ端末）１を収容している。
【００２０】
各ノード２、３を接続するリンク４は、物理的なものであっても良く、下位レイヤのカプセル化機能などを用いた論理的なものであっても良い。また、この明細書において、通信に供する端末１を収容しているノード２をエッジノードと呼び、通信に供する端末１を収容していないノード３をコアノードと呼ぶことにする。なお、同一ノードがある通信においてはエッジノード２となり、他の通信においてはコアノード３となることもあり得る。例えば、ノード２、３はルータなどが該当するものである。
【００２１】
図１は、端末１、エッジノード２及びコアノード３の機能的構成を示すブロック図である。
【００２２】
端末１は、アプリケーション部１０１、予約管理部１０２、転送管理部１０３及び故障管理部１０４でを有する。アプリケーション部１０１は、具体的な通信サービスを提供するものであり（複数存在しても良い）、予約管理部１０２は、それに必要なネットワークリソースを予約処理するものであり、転送管理部１０３は、通信サービスで生じたデータをエッジノード２に転送するものであり、故障管理部１０４は、通信サービスでの故障管理を行うものである。
【００２３】
この端末１には、複数の通信サービスを任意に実装できるが、以下、一つの通信サービスを取り上げて説明する。
【００２４】
エッジノード２は、予約管理部２０１、転送管理部２０２、リソース管理部２０３、受付管理部２０４、受付管理データテーブル２０５、予約管理データテーブル２０６、予約ログデータテーブル２０７、リソース管理データテーブル２０８、故障管理部２０９及び仮予約リソース管理データテーブル２１０を有する。
【００２５】
予約管理部２０１は、ネットワークリソースの予約状況などを管理するものであり、転送管理部２０２は、データ転送を管理するものであり、リソース管理部２０３は、リソースの状態などを管理するものであり、受付管理部２０４は、端末１からの通信要求に対する受付管理を行うものであり、故障管理部２０９は、通信サービスでの故障管理を行うものである。
【００２６】
図３は、データのソース側端末１を収容するエッジノード２における各種テーブルの配置を示す説明図であり、図４は、データのディスティネーション側端末１を収容するエッジノード２における各種テーブルの配置を示す説明図である。
【００２７】
エッジノード２は、端末１とのインタフェースや、コアノード３や他のエッジノードとのインタフェースを有する。
【００２８】
ソース側端末１を収容するエッジノード２においては、端末１とのインタフェースは入力側のインタフェースとなり、コアノード３や他のエッジノードとのインタフェースは出力側のインタフェースとなる。このような場合のエッジノード２（ソース側端末１を収容するエッジノード２）においては、図３に示すように、端末１との各インタフェース（図３ではＩＦ＃Ｕ１及びＩＦ＃Ｕ２で示している）に関して、受付管理データテーブル２０５や予約管理データテーブル２０６や予約ログデータテーブル２０７（このテーブルは図３では省略）が機能し、コアノード３や他のエッジノードとの各インタフェース（図３ではＩＦ＃Ｔ１及びＩＦ＃Ｔ２で示している）に関して、リソース管理データテーブル２０８や仮予約リソース管理データテーブル２１０が機能する。
【００２９】
また、ディスティネーション側端末１を収容するエッジノード２においては、端末１とのインタフェースは出力側のインタフェースとなり、コアノード３や他のエッジノードとのインタフェースは入力側のインタフェースとなる。このような場合のエッジノード２（ディスティネーション側端末１を収容するエッジノード２）においては、図４に示すように、端末１との各インタフェース（図４ではＩＦ＃Ｕ１及びＩＦ＃Ｕ２で示している）に関して、予約管理データテーブル２０６やリソース管理データテーブル２０８や仮予約リソース管理データテーブル２１０が機能する。
【００３０】
受付管理データテーブル２０５は、受付管理部２０４が受付管理で利用するものであり、図５に示す構成を有する。受付管理データテーブル２０５は、ユーザが使用可能なネットワークサービスを管理するものであり、エッジノード２で分散管理されても、ネットワークを管理するサーバで集中的に管理されていても良い。後者のサーバでは、エッジノード２，２間のルートを管理しても良い。
【００３１】
受付管理データテーブル２０５は、図５に示すように、ユーザを識別するための識別子である「Ｕｓｅｒ−ＩＤ」２０５１と、このユーザがネットワークを管理する通信事業者と契約している「サービスタイプ」２０５２と、これに関する制限などを記述した「制限情報」２０５３などを含んでいる。
【００３２】
予約管理データテーブル２０６、予約ログデータテーブル２０７及び仮予約リソース管理データテーブル２１０は、予約管理部２０１が、ネットワークリソースの予約状況などを管理する際に利用するものである。上述したように、当該エッジノード２がソース側かディスティネーション側かにより、予約管理部２０１が、利用するテーブルは多少異なっている。
【００３３】
予約管理データテーブル２０６は、予約中のフローをユーザ毎に管理するためのものであり、図６に示す構成を有する。予約管理データテーブル２０６は、図６に示すように、ユーザを識別するための識別子である「Ｕｓｅｒ−ＩＤ」２０６１と、このユーザが予約している「サービスタイプ」２０６２と、ユーザが予約した「予約リソース量」２０６３と、予約フローの出先インタフェースの「インタフェース−ＩＤ」２０６４と、予約フローを識別するための識別子である「フロー−ＩＤ」２０６５とを含んでいる。
【００３４】
予約ログデータテーブル２０７は、予約管理データテーブル２０６の一部内容と、サービス提供時間や、イベント発生・終了時刻などの課金やネットワークの管理に必要なデータを格納するためのデータテーブルであり、図７に示す構成を有する。すなわち、予約ログデータテーブル２０７は、図７に示すように、ユーザを識別するための識別子である「Ｕｓｅｒ−ＩＤ」２０７１と、このユーザが予約している「サービスタイプ」２０７２と、ユーザが予約した「予約リソース量」２０７３と、ネットワークの管理に必要なデータ２０７４を含んでいる。
【００３５】
仮予約リソース管理データテーブル２１０は、図８に示すように、サービスタイプと出力インタフェース毎に存在し、「仮予約リソース量」２１０１と、保守者が割り当てる「設定リソース量」２１０２を含んでいる。
【００３６】
リソース管理データテーブル２０８は、リソース管理部２０３がリソースの管理に利用するものであり、図９に示す構成を有する。リソース管理データテーブル２０８は、サービスタイプと出力インタフェース毎に存在し、メッセージの入力インタフェースを識別するための「インタフェース−ＩＤ」２０８１、予約・変更・削除するフローの「ソース側エッジ−ＩＤ」２０８２、「ディスティネーション側エッジ−ＩＤ」２０８３、予約が完了した後のリソース量を表す「予約リソース量」２０８４を含んでいる。
【００３７】
コアノード３は、図１に示すように、予約管理部３０１、転送管理部３０２、リソース管理部３０３、リソース管理データテーブル３０４、故障管理部３０５及び仮予約リソース管理データテーブル３０６を有する。
【００３８】
図１０は、コアノード３における各種テーブルの配置を示す説明図である。
【００３９】
コアノード３は、他のコアノードや、エッジノードとのインタフェースを有する。これらインタフェースは、入力側のインタフェースとなることもあれば、出力側のインタフェースとなることがある。コアノード３においては、図１０に示すように、各フローに関して出力側のインタフェースと機能するインタフェース（図１０ではＩＦ＃Ｔ３及びＩＦ＃Ｔ４で示している）に関して、リソース管理データテーブル３０４や仮予約リソース管理データテーブル３０６が機能する。
【００４０】
コアノード３における各要素３０１、…、３０６は、エッジノード２の対応要素と同様なものである。なお、図１１及び図１２にはそれぞれ、コアノード３の仮予約リソース管理データテーブル３０６及びリソース管理データテーブル３０４の構成を示している。
【００４１】
コアノード３のリソース管理データテーブル３０４は、エッジノード２のものとほぼ同様であるが、「ソース側エッジ（ノード）−ＩＤ」３０４２及び「ディスティネーション側エッジ−ＩＤ」３０４３には、予約・変更・削除のシーケンス中で確定するエッジ−ＩＤが格納される点がエッジノード２のものと異なっている。
【００４２】
図３７は、コアノード３におけるインタフェースと、仮予約リソース管理データテーブル３０６及びリソース管理データテーブル３０４との位置関係例をフローとの関係で具体的に示す説明図である。また、図３７は、同一のサービスタイプのもののみを示しているとする。
【００４３】
図３７に示すコアノード３の例の場合、ソース側インタフェースとしてＩＦ（１）及びＩＦ（２）を有し、ディスティネーション側インタフェースとしてＩＦ（３）及びＩＦ（４）を有する。
【００４４】
仮予約リソース管理データテーブル３０６及びリソース管理データテーブル３０４はそれぞれ、ディスティネーション側インタフェース（出力インタフェース）ＩＦ（３）及びＩＦ（４）に関連して設けられている。なお、インタフェースＩＦ（３）及びＩＦ（４）がＯＵＴ及びＩＮの双方向対応ならば、インタフェースのＯＵＴ用に対応付けられて、仮予約リソース管理データテーブル３０６及びリソース管理データテーブル３０４が設けられる。
【００４５】
ディスティネーション側インタフェースＩＦ（３）を出力インタフェースとする経路は、エッジノードＥ１〜Ｅ２間（１０Ｍ）、エッジノードＥ１〜Ｅ３間（１０Ｍ）、及び、エッジノードＥ５〜Ｅ２間（１０Ｍ）であるので、インタフェースＩＦ（３）に係るリソース管理データテーブル３０４は、図３８（Ａ）に示すようになる。詳述は避けるが、インタフェースＩＦ（４）に係るリソース管理データテーブル３０４は、図３８（Ｂ）に示すようになる。
【００４６】
インタフェースＩＦ（３）に係る仮予約リソース管理データテーブル３０６の設定量が、図３８（Ｃ）に示すように、１００Ｍであれば、インタフェースＩＦ（３）を出力インタフェースとするリソース予約は１００Ｍまで可能である。今、リソース予約中のものがなければ、仮予約量（予約量）は３０Ｍであり、今後７０Ｍまでのリソース予約が可能である。
【００４７】
なお、図３８（Ｄ）には、インタフェースＩＦ（４）に係る仮予約リソース管理データテーブル３０６の構成を示している。
【００４８】
また、図３９における点線矢印は、インタフェースＩＦ（１）から受信したディスティネーション方向への後述する故障通知メッセージの転送経路を示しており、破線矢印は、インタフェースＩＦ（４）から受信したソース方向への後述する故障通知メッセージの転送経路を示している。
【００４９】
図３９は、予約元端末を収容しているエッジノード２におけるインタフェースと、各種データテーブルとの位置関係例を具体的に示す説明図である。図３９は、同一のサービスタイプのもののみを示しているとする。
【００５０】
図３９に示すエッジノード２の例の場合、ソース側インタフェースとしてＩＦ（１）及びＩＦ（２）を有し、ディスティネーション側インタフェースとしてＩＦ（３）及びＩＦ（４）を有する。
【００５１】
仮予約リソース管理データテーブル２１０及びリソース管理データテーブル２０８はそれぞれ、ディスティネーション側インタフェース（出力インタフェース）ＩＦ（３）及びＩＦ（４）に関連して設けられている。なお、インタフェースＩＦ（３）及びＩＦ（４）がＯＵＴ及びＩＮの双方向対応ならば、インタフェースのＯＵＴ用に対応付けられて、仮予約リソース管理データテーブル２１０及びリソース管理データテーブル２０８が設けられる。
【００５２】
予約管理データテーブル２０６は、ソース側インタフェース（入力インタフェース）ＩＦ（１）及びＩＦ（２）に関連して設けられている。なお、インタフェースＩＦ（１）及びＩＦ（２）がＯＵＴ及びＩＮの双方向対応ならば、インタフェースのＩＮ用に対応付けられて、予約管理データテーブル２０６が設けられる。
【００５３】
ディスティネーション側インタフェースＩＦ（３）を出力インタフェースとする、ユーザとディスティネーションエッジノードの組合せは、Ｕ１〜Ｅ１間（１０Ｍ）、Ｕ２〜Ｅ２間（１０Ｍ）、及び、Ｕ４〜Ｅ２間（１０Ｍ）であるので、インタフェースＩＦ（３）に係るリソース管理データテーブル２０８は、図４０（Ａ）に示すようになる。詳述は避けるが、インタフェースＩＦ（４）に係るリソース管理データテーブル２０８は、図４０（Ｂ）に示すようになる。
【００５４】
インタフェースＩＦ（３）に係る仮予約リソース管理データテーブル２１０の設定量が、図４０（Ｃ）に示すように、５０Ｍであれば、インタフェースＩＦ（３）を出力インタフェースとするリソース予約は５０Ｍまで可能である。今、リソース予約中のものがなければ、仮予約量（予約量）は３０Ｍであり、今後２０Ｍまでのリソース予約が可能である。なお、図４０（Ｄ）には、インタフェースＩＦ（４）に係る仮予約リソース管理データテーブル２１０の構成を示している。
【００５５】
ソース側インタフェースＩＦ（１）を入力インタフェースとするユーザ（予約元端末）は、Ｕ１〜Ｕ３であるので、インタフェースＩＦ（１）に係る予約管理データテーブル２０６は、図４０（Ｅ）に示すようになる。詳述は避けるが、インタフェースＩＦ（２）に係る予約管理データテーブル２０６は、図４０（Ｆ）に示すようになる。
【００５６】
なお、図３９における点線矢印は、インタフェースＩＦ（１）から受信したディスティネーション方向への後述する故障通知メッセージの転送経路を示しており、破線矢印は、インタフェースＩＦ（４）から受信したソース方向への後述する故障通知メッセージの転送経路を示している。
【００５７】
図４１は、対向端末を収容しているエッジノード２におけるインタフェースと、各種データテーブルとの位置関係例を示す説明図である。図４１は、同一のサービスタイプのもののみを示しているとする。
【００５８】
図４１に示すエッジノード２の例の場合、ソース側インタフェースとしてＩＦ（１）及びＩＦ（２）を有し、ディスティネーション側インタフェースとしてＩＦ（３）及びＩＦ（４）を有する。
【００５９】
仮予約リソース管理データテーブル２１０及びリソース管理データテーブル２０８はそれぞれ、ディスティネーション側インタフェース（出力インタフェース）ＩＦ（３）及びＩＦ（４）に関連して設けられている。なお、インタフェースＩＦ（３）及びＩＦ（４）がＯＵＴ及びＩＮの双方向対応ならば、インタフェースのＯＵＴ用に対応付けられて、仮予約リソース管理データテーブル２１０及びリソース管理データテーブル２０８が設けられる。
【００６０】
このディスティネーション側のエッジノード２の場合、予約管理データテーブル２０６は、ディスティネーション側インタフェースに対応付けて設けられている。
【００６１】
ディスティネーション側インタフェースＩＦ（３）を出力インタフェースとする、ソース側エッジノードとユーザとの組合せは、Ｅ１〜Ｕ１間（１０Ｍ）、Ｅ２〜Ｕ２間（１０Ｍ）、及び、Ｅ２〜Ｕ４間（１０Ｍ）であるので、インタフェースＩＦ（３）に係るリソース管理データテーブル２０８は、図４２（Ａ）に示すようになる。詳述は避けるが、インタフェースＩＦ（４）に係るリソース管理データテーブル２０８は、図４２（Ｂ）に示すようになる。
【００６２】
インタフェースＩＦ（３）に係る仮予約リソース管理データテーブル２１０の設定量が、図４２（Ｃ）に示すように、５０Ｍであれば、インタフェースＩＦ（３）を出力インタフェースとするリソース予約は５０Ｍまで可能である。今、リソース予約中のものがなければ、仮予約量（予約量）は３０Ｍであり、今後２０Ｍまでのリソース予約が可能である。なお、図４２（Ｄ）には、インタフェースＩＦ（４）に係る仮予約リソース管理データテーブル２１０の構成を示している。
【００６３】
このエッジノード２が収容する出力対象のユーザ（対向端末）は、Ｕ１〜Ｕ５であるので、予約管理データテーブル２０６は、図４２（Ｅ）に示すようになる。
【００６４】
なお、図３９における点線矢印は、インタフェースＩＦ（１）から受信したディスティネーション方向への後述する故障通知メッセージの転送経路を示しており、破線矢印は、インタフェースＩＦ（４）から受信したソース方向への後述する故障通知メッセージの転送経路を示している。
【００６５】
この第１の実施形態では、ネットワークリソースの予約・変更・削除を行うために、「予約要求」メッセージ、「予約応答」メッセージ、「変更要求」メッセージ、「変更応答」メッセージ、「削除要求」メッセージ、「削除応答」メッセージを使用する。これらメッセージは、ヘッダ部においてメッセージの種別が明らかにされる。
【００６６】
「予約要求」、「変更要求」、「削除要求」などの要求メッセージのデータ部構成はほぼ同様であり、図１３に示す構成を有する。すなわち、ストリーム送信元（端末）ＩＤ、ストリーム送信先（端末）ＩＤ、ソース側エッジ（ノード）ＩＤ、ディスティネーション側エッジ（ノード）ＩＤ、サービスタイプ、要求量及びフロー−ＩＤを含んでいる。また、「予約応答」、「変更応答」、「削除応答」などの応答メッセージのデータ部構成は同様であり、図１１に示す構成を有する。すなわち、ストリーム送信元（端末）ＩＤ、ストリーム送信先（端末）ＩＤ、ソース側エッジ（ノード）ＩＤ、ディスティネーション側エッジ（ノード）ＩＤ、サービスタイプ、要求量、フロー−ＩＤ及び要求に対する結果を含んでいる。
【００６７】
第１の実施形態のネットワークでは、その他に、「維持」メッセージ（ｋｅｅｐ ａｌｉｖｅメッセージ）や「故障通知」メッセージも授受される。
【００６８】
「維持」メッセージは、端末１、ノード２、３での予約状態を維持したり、ネットワークの故障を監視したりするためのものであり、図１５に示すように、データ部は、自ノードＩＤ、対向ノードＩＤ、サービスタイプ、要求量及び設定量を有する。「故障通知」メッセージは、各ノードが検出した故障を通知するものであり、図１６に示すように、データ部は、送信元ノードＩＤ、送信先ノードＩＤ、ソース側エッジ（ノード）ＩＤ、ディスティネーション側エッジ（ノード）ＩＤ、サービスタイプ、ユーザＩＤ及び要求量を有する。
【００６９】
（Ａ−２）第１の実施形態の動作
（Ａ−２−１）リソースの予約、変更、削除動作などの基本的な技術思想
第１の実施形態のリソースの予約、変更、削除動作の基本的な技術思想を、図１７のシーケンス図を用いて説明する。
【００７０】
なお、図１７は、データ転送元（リソース予約元）の端末１Ａから、データ転送先の端末１Ｂへのデータ転送に、エッジノード２Ａ、コアノード３、エッジノード２Ｂがこの順で介在する（中継する）場合を示している。また、以下の説明では、データの転送元側を上流、データの転送先側を下流と表現する。
【００７１】
第１の実施形態では、ネットワークリソースの予約・変更・削除を行うために、上述のように、「予約要求」メッセージ、「予約応答」メッセージ、「変更要求」メッセージ、「変更応答」メッセージ、「削除要求」メッセージ、「削除応答」メッセージなどを使用する。これらのメッセージの転送は、ＩＣＭＰやＴＣＰなどを用いてネットワーク上を伝播させる。そして、これらのメッセージが通るルートについては、一般的なルーティングテーブルに従っても良く、また、各ノードの予約管理部２０１、３０１が予約・変更時に予約状況に基づき決定するルートを選択しても良い。但し、後者の場合には、予約ルートとデータの転送ルートは同一でなければならない。
【００７２】
まず、図１７（Ａ）を参照しながら、リソースの予約動作の基本的な技術思想を説明する。
【００７３】
リソース予約元の端末１Ａは、収容されているエッジノード２Ａに必要リソース量（要求量）などの情報を含む予約要求メッセージを通知してリソース予約を行う。データ転送に介在すべき（中継処理を行う）各ノード２Ａ、３、２Ｂにおいては、上流の装置からの予約要求メッセージの受信時に、受け入れられるか否かを判別し、受け入れられる場合に、自ノードを仮予約状態にした後、下流の装置に予約要求メッセージを送出する。このように、各ノード２Ａ、３、２Ｂが、リソース予約が可能な状態であれば、予約要求メッセージが順次伝搬していき、データ転送先の端末１Ｂに到達する。
【００７４】
データ転送先の端末１Ｂは、予約要求メッセージを受信し、応じられる場合には、リソース予約を受け入れられるという結果を含む予約応答メッセージをエッジノード２Ｂに返信する。各ノード装置２Ｂ、３、２Ａにおいては、下流の装置からの受入れ可の予約応答メッセージの返信を受けると、自ノードを本予約状態にした後、上流の装置にその予約応答メッセージを送出する。リソース予約元の端末１Ａは、リソース予約を受け入れられる予約応答メッセージの返信を受けると、そのことを認識し、データ転送を開始することになる。
【００７５】
一方、各ノード２Ｂ、３、２Ａ又は端末装置１Ｂは、上流の装置からの予約要求メッセージに対し、受け入れられない場合には、自ノードを仮予約状態にすることなく、また、下流の装置に予約要求メッセージを送出することなく、上流の装置に、受け入れられない旨の予約応答メッセージを返信する。各ノード２Ｂ、３、２Ａにおいては、下流の装置からのリソース予約を受け入れられない旨の予約応答メッセージを受けると、自ノードを仮予約状態から予約待機状態に戻し、上流の装置にリソース予約を受け入れられない旨の予約応答メッセージを返信する。
【００７６】
リソース予約元の端末１Ａは、リソース予約を受け入れられない旨の予約応答メッセージの返信により、そのことを認識し、データ転送を待機することになる。
【００７７】
なお、コアノード３がない場合や、２個以上の場合であっても、さらには、端末１Ａ及び１Ｂが同一のエッジノード装置２に収容されている場合であっても、上述した技術思想に従いながら、リソース予約処理が実行される。
【００７８】
予約リソースの変更時の動作シーケンスは、リソース予約時の動作シーケンスと同様であるので、その技術思想の説明は省略する（図１７（Ｂ）参照）。
【００７９】
また、予約リソースの削除動作（予約リソースの解除動作）も、図１７（Ｃ）に示すように、端末１Ａからの削除要求メッセージが、エッジノード２Ａ、コアノード３、エッジノード２Ｂの順に下流に向けて転送され、最終的に対向する端末１Ｂに到達し、端末１Ｂがリソースの削除処理を実行したときに、逆に、削除応答メッセージが、エッジノード２Ｂ、コアノード３、エッジノード２Ａの順に上流に向けて転送され、通信に供する全てのネットワーク要素でリソースの削除（解除）が実行される。
【００８０】
予約されたリソースの予約状態は、図１８に示すように、端末を含めた隣接ノード間で、維持メッセージを授受することにより維持することができる。また、維持メッセージの授受により、ノード間の故障などを検出することもできる。
【００８１】
また、隣接するノード間を結ぶリンク（インタフェース）で故障が生じたときには、図１９に示すように、故障を認識したノード３Ａ、３Ｂが、故障通知メッセージを形成し、この故障通知メッセージを端末１Ａ、１Ｂまで伝搬することにより、通信に供していた全てのネットワーク要素で故障発生を認識し、故障リンク（インタフェース）に係る仮予約や本予約を解除することができる。
【００８２】
（Ａ−２−２）リソース予約動作の詳細
次に、各部でのリソース予約動作の詳細を説明する。ここで、端末１、エッジノード２及びコアノード３の接続関係が、上述した図１７（Ａ）であるとして説明する。
【００８３】
なお、端末１の予約管理部１０２、各ノード２、３の予約管理部２０１、３０１はそれぞれ、「ＳＴＡＲＴ」、「受信待ち」、「予約中」、「予約ＯＫ」、「予約ＮＧ」の予約管理状態を持ち、これら状態間の遷移は、図２０及び図２１に示す通りである。
【００８４】
図２０に示すように、「ＳＴＡＲＴ」状態からは「受信待ち」状態への遷移のみが可能であり、「受信待ち」状態からは自状態又は「予約中」状態への遷移のみが可能であり、「予約中」状態からは「予約ＯＫ」状態又は「予約ＮＧ」状態への遷移が可能であり、「予約ＮＧ」状態からは「受信待ち」状態への遷移のみが可能であり、「予約ＯＫ」状態からは「受信待ち」状態又は「予約ＮＧ」状態への遷移が可能である。
【００８５】
図２１において、縦方向に記述した５個の状態は遷移前の状態を示し、横方向に記述した５個の状態は遷移後の状態を示し、その交点の欄には、その遷移条件を記述している。［］で挟まれた文字列（例えば予約要求）は、メッセージを表している。
【００８６】
これらの状態遷移の具体的内容については、後述する各部の動作説明で明らかにする。
【００８７】
（Ａ−２−２−１）端末１のリソース予約動作
端末１（１Ａ、１Ｂ）でのリソース予約動作を図２０を用いて説明する。なお、図２０は、端末１としてのリソース予約動作を示したフローチャートであり、ステップＳＴ１０〜ＳＴ１６がリソース予約元の端末１Ａの処理を示し、ステップＳＴ１０、ＳＴ１３、ＳＴ１７〜ＳＴ１９が端末１Ａに対向する端末１Ｂの動作を示している。
【００８８】
端末１Ａの予約管理部１０２では、図２０に示す通り、イベント発生を待機しており（ＳＴ１０）、発生イベントがアプリケーション部１０１による通信サービスの起動であると、通信パラメータを選定する（ＳＴ１１）。
【００８９】
なお、要求側端末１Ａの利用者がアプリケーション部１０１を起動する。利用者は、必要があればアプリケーションに適したネットワークサービスや必要なネットワークリソースを指定する。指定がない場合にはアプリケーション部１０１が自律でこれらのパラメータを決定して予約管理部１０２に設定する。
【００９０】
予約管理部１０２は、通信パラメータが通知（設定）されると、ネットワークリソースの予約要求メッセージを編成してエッジノード２Ａの予約管理部２０１に送信し（ＳＴ１２）、イベント発生の待機状態に戻る。
【００９１】
なお、端末１Ａから送出された直後の予約要求メッセージのソース側エッジ−ＩＤ及びディスティネーション側エッジ−ＩＤ（図１３参照）は、空欄になっている。
【００９２】
ステップＳＴ１２の予約要求メッセージの送信によって、対向する端末１Ｂに至るネットワーク全体にわたり、そのリソースの確保（予約）を、端末１Ａが求めたことになる。
【００９３】
エッジノード２Ａ、コアノード３、エッジノード２Ｂ、対向する端末１Ｂのそれぞれで予約が完了すると、エッジノード２Ａを介して、ＯＫ（可）という要求結果を含む予約応答メッセージが返信される。一方、エッジノード２Ａ、コアノード３、エッジノード２Ｂ、対向する端末１Ｂがリソース予約を受け入れられないときは、その装置から上流に送出され始めたＮＧ（否）という要求結果を含む予約応答メッセージが返信される。
【００９４】
受信したメッセージが予約応答メッセージであることを認識した端末１Ａの予約管理部１０２は（ＳＴ１３参照）、このメッセージに含まれている要求結果、すなわち、予約の可否状態を判定し（ＳＴ１４）、ＯＫであれば、そのパラメータに基づくリソース条件が転送管理部１０３に、また予約完了がアプリケーション部１０１にそれぞれ通知される。
【００９５】
アプリケーション部１０１では、仮予約を承認することで予約完了、すなわち本予約を宣言し、これを転送管理部１０３に通知してデータの送信を開始させる。転送管理部１０３では、例えばアプリケーション部１０１からのストリームデータを予約管理部１０２で指定したリソース条件に基づいてエッジノード２Ａの転送管理部２０２に転送する（ＳＴ１５）。
【００９６】
また、受信した予約応答メッセージの可否状態がＮＧであれば、予約管理部１０２は、その旨をアプリケーション部１０１に通知して（ＳＴ１６）、イベント発生を待機する（ＳＴ１０）。
【００９７】
一方、予約元でない端末１Ｂの予約管理部１０２は、隣接するエッジノード２Ｂから予約要求メッセージを待ち受けており、予約要求メッセージを受信すると（ＳＴ１３参照）、予約要求メッセージ中の「ストリーム送信先ＩＤ」を元に、対応するアプリケーション部１０１を特定し、その状態が受信が可能な状態であるか否かを確認する（ＳＴ１７）。
【００９８】
そして、データの受信が可能な状態であれば、結果がＯＫの予約応答メッセージを作成し、エッジノード２Ｂヘ送信する（ＳＴ１８）。一方、データの受信が可能でなければ、結果がＮＧの予約応答メッセージを作成し、エッジノードヘ送信する（ＳＴ１９）。なお、予約応答メッセージ中の結果以外のデータ領域は、予約要求メッセージの内容をコピーする。
【００９９】
なお、予約元端末１Ａは、予約要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、予約応答メッセージが受信できないときには、ＮＧの予約応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）をエッジノード２Ａ側に送出して、仮予約又は本予約状態のノードなどの予約状態を取り消すようにさせる。
【０１００】
（Ａ−２−２−２）エッジノード２のリソース予約動作
エッジノード２（２Ａ、２Ｂ）でのリソース予約動作を図２３を用いて説明する。
【０１０１】
なお、図２３は、エッジノード２としてのリソース予約動作を示したフローチャートである。予約元の端末１Ａを収容しているエッジノード２Ａの動作も、対向する端末１Ｂを収容しているエッジノード２Ｂの動作も、図２３で表すことができるが、その動作内容には多少の違いがあり、以下では、エッジノード２Ａ、２Ｂの動作を区別して説明する。
【０１０２】
（Ａ−２−２−２−１）予約要求受信処理（予約元端末側エッジノード）
メッセージ受信待ち状態において（ＳＴ２０）、予約元端末１Ａからの予約要求メッセージを受信したエッジノード２Ａの予約管理部２０１は、受付管理部２０４やリソース管理部２０３と協働して、予約が可能か否かを判別する（ＳＴ２１、ＳＴ２２）。
【０１０３】
すなわち、受付管理部２０４へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知し、受付管理部２０４に、これら情報よりＵｓｅｒ−ＩＤを求めさせ、受付管理データテーブル２０５（図７参照）の格納内容（例えば制限情報）に基づき、受け付けて良いか否かを確認させる。また、受け付けＯＫの場合には、リソース管理部２０３は、例えば、図示しないルーティングテーブルなどによって予約要求メッセージの転送先インタフェース（出力側インタフェース）を特定し、その転送先インタフェースと、要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図８参照）を選定し、受信した予約要求メッセージの要求量で予約が可能かを、（１）式に従って判定する。
【０１０４】
仮予約量＋要求量≦設定量 …（１）
ここで、仮予約量は、そのインタフェース及びサービスタイプの組合せで既に仮予約されているリソース量であり、要求量は、予約要求メッセージで要求されているリソース量であり、設定量は、そのインタフェース及びサービスタイプの組合せについてネットワーク管理者により割り当てられているリソース量である。
【０１０５】
リソース管理部２０３は、（１）式が満たされ、予約可の場合には、仮予約リソース管理データテーブル２１０の仮予約量を（２）式に従って更新して（ＳＴ２３）、予約ＯＫを予約管理部２０１へ通知すると共に、（１）式が満たされず、予約不可の場合には、予約ＮＧを予約管理部２０１へ通知する。
【０１０６】
仮予約量＝仮予約量＋要求量 …（２）
予約管理部２０１は、予約ＯＫの場合には、今回の転送情報をセーブし、また、次ホップ（図１７（Ａ）の場合であればコアノード３）ヘ、受信した予約要求メッセージに、ソース側エッジ−ＩＤを付与して送信する（ＳＴ２４、ＳＴ２５）。
【０１０７】
これに対して、予約管理部２０１は、予約ＮＧの場合には、受信した予約要求メッセージに対応する予約応答メッセージを形成すると共に、その予約応答メッセージの結果のデータフィールドをＮＧとし、前ホップの端末１Ａへ送信する（ＳＴ２６）。
【０１０８】
（Ａ−２−２−２−２）予約要求受信処理（対向端末側エッジノード）
メッセージ受信待ち状態において（ＳＴ２０）、前ホップ（コアノード３や予約元端末収容エッジノード２Ａ）からの予約要求メッセージを受信したエッジノード２Ｂの予約管理部２０１は、リソース管理部２０３と協働して、予約が可能か否かを判別する（ＳＴ２１、ＳＴ２２）。
【０１０９】
すなわち、予約管理部２０１は、リソース管理部２０３へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知する。リソース管理部２０３は、例えば、これらの情報と図示しないルーティングテーブルとによって予約要求メッセージの転送先インタフェース（出力側インタフェース）を特定し、その予約要求メッセージの転送先インタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図８）を選定し、予約要求メッセージの要求量で予約が可能か否かを判定する。この判定式は、上述した（１）式と同一である。
【０１１０】
リソース管理部２０３は、（１）式が満たされ、予約可の場合には、仮予約リソース管理データテーブル２１０の仮予約量を上述した（２）式に従って更新して（ＳＴ２３）、予約ＯＫを予約管理部２０１へ通知すると共に、（１）式が満たされず、予約不可の場合には、予約ＮＧを予約管理部２０１へ通知する。
【０１１１】
予約管理部２０１は、予約ＯＫの場合には、今回の転送情報をセーブし、また、次ホップ（図１７（Ａ）の場合であれば端末１Ｂ）ヘ、受信した予約要求メッセージを送信する（ＳＴ２５）。この対向端末１Ｂを収容しているエッジノード２Ｂでは、予約要求メッセージに対するソース側エッジ−ＩＤの付与（ＳＴ２４）は省略される。
【０１１２】
これに対して、予約管理部２０１は、予約ＮＧの場合には、受信した予約要求メッセージに対応する予約応答メッセージを形成すると共に、その予約応答メッセージの結果のデータフィールドをＮＧとし、前ホップのコアノード３へ送信する（ＳＴ２６）。
【０１１３】
（Ａ−２−２−２−３）予約応答受信処理
予約応答メッセージの受信時動作は、予約元端末１Ａを収容しているエッジノード２Ａと、対向端末１Ｂを収容しているエッジノード２Ｂとの差が僅かであるのでまとめて説明する。
【０１１４】
メッセージ受信待ち状態において、下流側（端末１Ｂ又はコアノード３）から予約応答メッセージを受信すると（ＳＴ２０、ＳＴ２１）、予約管理部２０１は、予約応答メッセージの結果フィールドの内容に応じて、リソース管理部２０３にデータテーブルの更新処理を実行させる（ＳＴ２７、ＳＴ２８、ＳＴ３２）。
【０１１５】
予約応答メッセージの結果が予約ＯＫの場合には、リソース管理部２０３は、予約応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル２０８（図９参照）を選定し、このデータテーブル２０８中のインタフェース−ＩＤ２０８１、ソース側エッジ−ＩＤ２０８２、及び、ディスティネーション側エッジ−ＩＤ２０８３で特定すると共に、その行（レコード）の予約リソース量２０８４を（３）式に従って更新する（ＳＴ２８）。なお、特定できる行がない場合、リソース管理データテーブル２０８に行を追加する（ＳＴ２８）。
【０１１６】
予約量［ｉ］＝予約量［ｉ］＋要求量 …（３）
ここで、ｉは予約応答メッセージの転送先のインタフェース−ＩＤに対応する番号であり、予約量［ｉ］は、番号ｉに対応するインタフェースで予約されているリソース量であり、要求量は、予約応答メッセージ（従って予約要求メッセージ）で要求されているリソース量である。予約応答メッセージの転送先のインタフェース−ＩＤは、例えば、セーブした転送情報から求める。
【０１１７】
次に、予約管理部２０１は、予約管理データテーブル２０６（図６参照）へ、受信した予約応答メッセージに係る行を登録する（ＳＴ２８）。すなわち、Ｕｓｅｒ−ＩＤ２０６１、サービスタイプ２０６２、予約リソース量２０６３、インタフェース−ＩＤ２０６４を登録する。なお、Ｕｓｅｒ−ＩＤ２０６１は、予約応答メッセージのストリーム送信元ＩＤ、ストリーム送信先ＩＤ、サービスタイプ、フロー−ＩＤなどにより求める。予約リソース量２０６３には、予約応答メッセージの要求量が挿入される。
【０１１８】
その後、前ホップが端末１Ｂであった場合には（ＳＴ２９で肯定結果）、予約応答メッセージ中のディスティネーション側エッジ−ＩＤへ、自エッジノード２ＢのＩＤを設定した後（ＳＴ３０）に、前ホップが端末１Ｂ以外であった場合には直ちに、予約応答メッセージを次ホップ（コアノード３又は端末１Ａ）ヘ送信する（ＳＴ３１）。このような予約応答メッセージを送出するインタフェースは、上述のように、セーブした転送情報から定まったインタフェースである。
【０１１９】
このような予約後においては（データ通信が開始された以降においては）、転送管理部２０２が、予約管理データテーブル２０６に違反しているか否かを確認し、違反しているトラフィックに対して、データの廃棄、マーキングなど、所定の処理を行う。以上のようなトラフィック違反の確認処理は、予約元端末１Ａを収容しているエッジノード２Ａのみが行うようにしても良い。
【０１２０】
これに対して、受信した予約応答メッセージの結果が予約ＮＧの場合には、リソース管理部２０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図８参照）を選定し、（４）式に従ってその内容を更新する（ＳＴ３２）。この更新処理は、仮予約した予約要求を取り消す処理に該当する。
【０１２１】
仮予約量＝仮予約量−要求量 …（４）
仮予約量は、インタフェースで仮予約されているリソース量であり、要求量は、予約応答メッセージで（従って予約要求メッセージ）指定されているリソース量である。
【０１２２】
その後、予約管理部２０１は、予約ＮＧの予約応答メッセージを、セーブした転送情報から定まるインタフェースから、次ホップ（コアノード３又は端末１Ａ）ヘ送信する（ＳＴ３３）。
【０１２３】
なお、エッジノード２Ａ、２Ｂは、予約要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、予約応答メッセージが受信できないときには、ＮＧの予約応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）を下流側に送出して、仮予約又は本予約状態のノードなどの予約状態を取り消すようにさせる。
【０１２４】
（Ａ−２−２−３）コアノード３のリソース予約動作
コアノード３でのリソース予約動作を図２４を用いて説明する。
【０１２５】
なお、図２４は、コアノード３としてのリソース予約動作を示したフローチャートである。
【０１２６】
（Ａ−２−２−３−１）予約要求受信処理
メッセージ受信待ち状態において（ＳＴ４０）、前ホップ（予約元端末収容エッジノード２Ａや他のコアノード３）からの予約要求メッセージを受信したコアノード３の予約管理部３０１は、リソース管理部３０３と協働して、予約が可能か否かを判別する（ＳＴ４１、ＳＴ４２）。
【０１２７】
すなわち、予約管理部３０１は、リソース管理部３０３へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知する。リソース管理部３０３は、例えば、これらの情報と図示しないルーティングテーブルとによって予約要求メッセージの転送先インタフェース（出力側インタフェース）を特定し、予約要求メッセージの転送先インタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル３０６（図１１参照）を選定し、予約要求メッセージの要求量で予約が可能か否かを判定する。この判定式は、上述した（１）式と同一である。
【０１２８】
リソース管理部３０３は、（１）式が満たされ、予約可の場合には、仮予約リソース管理データテーブル３０６の仮予約量を上述した（２）式に従って更新して（ＳＴ４３）、予約ＯＫを予約管理部３０１へ通知すると共に、（１）式が満たされず、予約不可の場合には、予約ＮＧを予約管理部３０１へ通知する。
【０１２９】
予約管理部３０１は、予約ＯＫの場合には、転送情報をセーブすると共に、特定したインタフェースから、次ホップ（図１７（Ａ）の場合であればエッジノード２Ｂ）ヘ、受信した予約要求メッセージを送信する（ＳＴ４４）。
【０１３０】
これに対して、予約管理部３０１は、予約ＮＧの場合には、受信した予約要求メッセージに対応する予約応答メッセージを形成すると共に、その予約応答メッセージの結果のデータフィールドをＮＧとし、前ホップ（エッジノード２Ａや他のコアノード３）へ送信する（ＳＴ４５）。
【０１３１】
（Ａ−２−２−３−２）予約応答受信処理
メッセージ受信待ち状態において、下流側（エッジノード２Ｂや他のコアノード３）から予約応答メッセージを受信すると（ＳＴ４０、ＳＴ４１）、予約管理部３０１は、予約応答メッセージの結果フィールドの内容に応じて、リソース管理部３０３にデータテーブルの更新処理を実行させる（ＳＴ４６、ＳＴ４７、ＳＴ４９）。
【０１３２】
予約応答メッセージの結果が予約ＯＫの場合には、リソース管理部３０３は、予約応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル３０４（図１２参照）を選定し、このデータテーブル３０４中のインタフェース−ＩＤ３０４１（このＩＤはセーブした転送情報から特定される）、ソース側エッジ−ＩＤ３０４２、及び、ディスティネーション側エッジ−ＩＤ３０４３で特定できる行（レコード）の情報（予約リソース量３０４４）を上述した（３）式に従って更新する（ＳＴ４７）。なお、特定できる行がない場合、リソース管理データテーブル３０４に行を追加する（ＳＴ４７）。
【０１３３】
そして、予約管理部３０１は、セーブした転送情報から定まるインタフェースから、予約ＯＫの予約応答メッセージを次ホップ（エッジノード２Ａや他のコアノード３）ヘ送信する（ＳＴ４８）。
【０１３４】
これに対して、受信した予約応答メッセージの結果が予約ＮＧの場合には、リソース管理部３０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル３０６（図１１参照）を選定し、上述した（４）式に従ってその内容を更新する（ＳＴ４９）。この更新処理は、仮予約した予約要求を取り消す処理に該当する。そして、予約管理部３０１は、セーブした転送情報から定まるインタフェースから、予約ＮＧの予約応答メッセージを次ホップ（エッジノード２Ａや他のコアノード３）ヘ送信する（ＳＴ５０）。
【０１３５】
なお、コアノード３は、予約要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、予約応答メッセージが受信できないときには、ＮＧの予約応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）を下流側に送出して、仮予約又は本予約状態のノードなどの予約状態を取り消すようにさせる。
【０１３６】
（Ａ−２−２−４）リソース予約成功時の一連の流れ
以下、各要素１〜３を通したリソース予約成功時の一連の処理の流れの一例を簡単に説明する。
【０１３７】
端末１Ａは、予約要求メッセージをエッジノード２Ａへ送信する。
【０１３８】
これを受けたソース側エッジノード２Ａは、受付管理データテーブル２０５によって、ユーザの予約要求を受け付けて良いかを確認する。受付ＯＫならば、ルーティングテーブルから転送する出力側インタフェースを特定し、そのインタフェースに対応する仮予約リソース管理データテーブル２１０の記憶内容に従い、上述した（１）式で、その方向へ予約が可能かを確認する。予約ＯＫならば、予約要求メッセージをコアノード３へ転送する。このとき、ソース側エッジノード２Ａは、転送情報をセーブする。
【０１３９】
これを受けたコアノード３は、ルーティングテーブルから転送する出力側インタフェースを特定し、そのインタフェースに対応する仮予約リソース管理データテーブル３０６の記憶内容に従い、上述した（１）式で、その方向へ予約が可能かを確認する。予約ＯＫならば、予約要求メッセージをディスティネーション側エッジノード２Ｂへ転送する。このとき、コアノード３は、転送情報をセーブする。
【０１４０】
これを受けたディスティネーション側エッジノード２Ｂは、ルーティングテーブルから転送する出力側インタフェースを特定し、そのインタフェースに対応する仮予約リソース管理データテーブル２１０の記憶内容に従い、上述した（１）式で、その方向へ予約が可能かを確認する。予約ＯＫならば、予約要求メッセージを端末１Ｂへ転送する。このとき、ディスティネーション側エッジノード２Ｂは、転送情報をセーブする。
【０１４１】
端末１Ｂは、要求に応じられる場合には、予約応答メッセージをディスティネーション側エッジノード２Ｂに送信する。
【０１４２】
予約応答メッセージを受信したディスティネーション側エッジノード２Ｂは、受信インタフェースに対応するリソース管理データテーブル２０８に、ソース側エッジＩＤ、ディスティネーション側エッジＩＤ、予約リソース量を設定すると共に、予約管理データテーブル２０６に、ユーザＩＤ、サービスタイプ、予約リソース量及びフロー−ＩＤを設定し、また、フローの転送情報より転送先インタフェースを特定し、リソース管理データテーブル２０８及び予約管理データテーブル２０６のインタフェース−ＩＤにそのインタフェースを設定し、転送先インタフェースから予約応答メッセージをコアノード３へ転送する。
【０１４３】
予約応答メッセージを受信したコアノード３は、受信インタフェースに対応するリソース管理データテーブル３０４に、ソース側エッジＩＤ、ディスティネーション側エッジＩＤ、予約リソース量を設定し、また、フローの転送情報より転送先インタフェースを特定し、リソース管理データテーブル３０４のインタフェース−ＩＤにそのインタフェースを設定し、転送先インタフェースから予約応答メッセージをソース側エッジノード２Ａへ転送する。
【０１４４】
予約応答メッセージを受信したソース側エッジノード２Ａは、受信インタフェースに対応するリソース管理データテーブル２０８に、ソース側エッジＩＤ、ディスティネーション側エッジＩＤ、予約リソース量を設定し、また、フローの転送情報より転送先インタフェースを特定し、リソース管理データテーブル２０８のインタフェース−ＩＤにそのインタフェースを設定し、転送先インタフェースから予約応答メッセージを端末１Ａへ転送する。
【０１４５】
なお、上述したフローの転送情報は、フロー単位に管理しても良く（各要素の上述した動作説明はこの場合を想定している）、エッジノード間のパス毎に管理しても良い。
【０１４６】
フロー単位に管理する場合には、予約要求メッセージを受信するインタフェース毎に転送情報を管理し、その内容はフロー−ＩＤ及び転送先インタフェースのＩＤ（ディスティネーション側）である。予約応答メッセージの転送先は、予約応答メッセージ中のフロー−ＩＤを含む転送情報を管理するインタフェースである。
【０１４７】
エッジノード間のパス毎に管理する場合にも、予約要求メッセージを受信するインタフェース毎に転送情報を管理し、その内容はエッジノード間のパスＩＤ及び転送先インタフェースのＩＤ（ディスティネーション側）である。予約応答メッセージの転送先は、予約応答メッセージ中のエッジノード間のパスＩＤを含む転送情報を管理するインタフェースである。
【０１４８】
（Ａ−２−３）予約リソースの変更動作の詳細
次に、各部での予約リソースの変更動作の詳細を説明する。ここで、端末１、エッジノード２及びコアノード３の接続関係が、図１７（Ｂ）であるとして説明する。また、予約リソースの変更とは、予約したリソース量の変更を意味している。
【０１４９】
なお、端末１の予約管理部１０２、各ノード２、３の予約管理部２０１、３０１はそれぞれ、変更動作面から、「ＳＴＡＲＴ」、「受信待ち」、「変更中」、「変更ＯＫ」、「変更ＮＧ」の変更管理状態を持ち、これら状態間の遷移は、図２２及び図２３に示す通りである。
【０１５０】
図２２に示すように、「ＳＴＡＲＴ」状態からは「受信待ち」状態への遷移のみが可能であり、「受信待ち」状態からは自状態又は「変更中」状態への遷移のみが可能であり、「変更中」状態からは「変更ＯＫ」状態又は「変更ＮＧ」状態への遷移が可能であり、「変更ＮＧ」状態からは「受信待ち」状態への遷移のみが可能であり、「変更ＯＫ」状態からは「受信待ち」状態又は「変更ＮＧ」状態への遷移が可能である。
【０１５１】
図２３において、縦方向に記述した５個の状態は遷移前の状態を示し、横方向に記述した５個の状態は遷移後の状態を示し、その交点の欄には、その遷移条件を記述している。［］で挟まれた文字列（例えば変更要求）は、メッセージを表している。
【０１５２】
これらの状態遷移の具体的内容については、後述する各部の動作説明で明らかにする。
【０１５３】
（Ａ−２−３−１）端末１の予約リソース変更動作
端末１（１Ａ、１Ｂ）での予約リソース変更動作を図２７を用いて説明する。なお、図２７は、端末１としてのリソース変更動作を示したフローチャートであり、ステップＳＴ６０〜ＳＴ６６がリソース変更元の端末１Ａの処理を示し、ステップＳＴ６０、ＳＴ６３、ＳＴ６７〜ＳＴ６９が端末１Ａに対向する端末１Ｂの動作を示している。
【０１５４】
端末１Ａの予約管理部１０２では、図２７に示す通り、イベント発生を待機しており（ＳＴ６０）、発生イベントがアプリケーション部１０１による通信サービスの予約リソースの変更起動であると、通信パラメータを選定する（ＳＴ６１）。すなわち、要求側端末１Ａの利用者、又は、アプリケーション部１０１が自律で、予約中のリソースを変更する場合には、利用者又はアプリケーション部１０１が変更後のパラメータを決定し、予約管理部１０２へ通知する。
【０１５５】
予約管理部１０２は、変更に係る通信パラメータが通知されると、ネットワークリソースの変更要求メッセージを編成してエッジノード２Ａの予約管理部２０１に送信し（ＳＴ６２）、イベント発生の待機状態に戻る。
【０１５６】
ここで、変更要求メッセージの要求量には、今まで予約していた帯域と新しい帯域の差分帯域を挿入しても良く、また、今まで予約していた帯域と新しい帯域との双方を挿入しても良い。以下、差分帯域が挿入されているものとして説明する。
【０１５７】
ステップＳＴ６２の変更要求メッセージの送信によって、対向する端末１Ｂに至るネットワーク全体にわたり、その予約リソースの変更を、端末１Ａが求めたことになる。
【０１５８】
エッジノード２Ａ、コアノード３、エッジノード２Ｂ、対向する端末１Ｂのそれぞれで変更が完了すると、エッジノード２Ａを介して、変更ＯＫ（可）という要求結果を含む変更応答メッセージが返信される。一方、エッジノード２Ａ、コアノード３、エッジノード２Ｂ又は対向する端末１Ｂがリソース量変更を受け入れられないときは、その装置から上流に送出され始めた、ＮＧ（否）という要求結果を含む変更応答メッセージが返信される。
【０１５９】
受信したメッセージが変更応答メッセージであることを認識した端末１Ａの予約管理部１０２は（ＳＴ６３参照）、このメッセージに含まれている要求結果、すなわち、変更の可否状態を判定し（ＳＴ６４）、ＯＫであれば、変更した条件が転送管理部１０３に、また変更完了がアプリケーション部１０１にそれぞれ通知される。
【０１６０】
アプリケーション部１０１では、予約変更を転送管理部１０３に通知して変更後のデータの送信を開始させる。転送管理部１０３は、例えばアプリケーション部１０１からのストリームデータを予約管理部１０２で指定された変更後のリソース条件に基づいてエッジノード２Ａの転送管理部２０２に転送する（ＳＴ６５）。
【０１６１】
また、受信した変更応答メッセージの可否状態がＮＧであれば、予約管理部１０２は、その旨をアプリケーション部１０１に通知する（ＳＴ６６）。このとき、今までと同じリソース条件でデータ転送が実行される。
【０１６２】
一方、変更元でない端末１Ｂの予約管理部１０２は、隣接するエッジノード２Ｂからの変更要求メッセージを待ち受けており、変更要求メッセージを受信すると（ＳＴ６３参照）、変更要求メッセージ中の「ストリーム送信先ＩＤ」を元に、対応するアプリケーション部１０１を特定し、その状態が変更リソース量のデータの受信が可能な状態であるか否かを確認する（ＳＴ６７）。
【０１６３】
そして、データの受信が可能な状態であれば、結果がＯＫの変更応答メッセージを作成し、エッジノード２Ｂヘ送信する（ＳＴ６８）。一方、データの受信が可能でなければ、結果がＮＧの変更応答メッセージを作成し、エッジノード２Ｂヘ送信する（ＳＴ６９）。なお、変更応答メッセージ中の結果以外のデータ領域は、変更要求メッセージの内容をコピーする。
【０１６４】
なお、端末１Ａは、変更要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、変更応答メッセージが受信できないときには、ＮＧの変更応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）を下流側に送出して、変更を仮確定又は本確定したノードなどの変更を取り消すようにさせる。
【０１６５】
（Ａ−２−３−２）エッジノード２の予約リソース変更動作
エッジノード２（２Ａ、２Ｂ）での予約リソース変更動作を図２８を用いて説明する。
【０１６６】
なお、図２８は、エッジノード２としての予約リソース変更動作を示したフローチャートである。変更元の端末１Ａを収容しているエッジノード２Ａの動作も、対向する端末１Ｂを収容しているエッジノード２Ｂの動作も、図２８で表すことができるが、その動作内容には多少の違いがあり、以下では、エッジノード２Ａ、２Ｂの動作を区別して説明する。
【０１６７】
（Ａ−２−３−２−１）変更要求受信処理（変更元端末側エッジノード）
メッセージ受信待ち状態において（ＳＴ７０）、変更元端末１Ａからの変更要求メッセージを受信したエッジノード２Ａの予約管理部２０１は、受付管理部２０４やリソース管理部２０３と協働して、変更が可能か否かを判別する（ＳＴ７１、ＳＴ７２）。
【０１６８】
すなわち、受付管理部２０４へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知し、受付管理部２０４に、これら情報よりＵｓｅｒ−ＩＤを求めさせ、受付管理データテーブル２０５（図５参照）の格納内容（例えば制限情報）に基づき、リソース量の変更を受け付けて良いか否かを確認させる。また、受け付けＯＫの場合には、リソース管理部２０３は、変更要求メッセージの転送先インタフェースと、要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図６参照）を選定し、受信した変更要求メッセージの要求量（増減分）で変更が可能かを、（５）式に従って判定する。
【０１６９】
仮予約量＋要求量≦設定量 …（５）
ここで、仮予約量は、そのインタフェース及びサービスタイプの組合せで既に仮予約されているリソース量（既に予約されているリソース量を含む）であり、要求量は、変更要求メッセージで要求されている増減するリソース量であり、設定量は、そのインタフェース及びサービスタイプの組合せについてネットワーク管理者により割り当てられているリソース量である。
【０１７０】
リソース管理部２０３は、（５）式が満たされ、変更可の場合には、仮予約リソース管理データテーブル２１０の仮予約量を（６）式に従って更新して（ＳＴ７３）、変更ＯＫを予約管理部２０１へ通知すると共に、（５）式が満たされず、変更不可の場合には、変更ＮＧを予約管理部２０１へ通知する。
【０１７１】
仮予約量＝仮予約量＋要求量 …（６）
予約管理部２０１は、変更ＯＫの場合には、次ホップ（図１７（Ｂ）の場合であればコアノード３）ヘ、受信した変更要求メッセージに、ソース側エッジ−ＩＤを付与して送信する（ＳＴ７４、ＳＴ７５）。
【０１７２】
これに対して、予約管理部２０１は、変更ＮＧの場合には、受信した変更要求メッセージに対応する変更応答メッセージを形成すると共に、その変更応答メッセージの結果のデータフィールドをＮＧとし、前ホップの端末１Ａへ送信する（ＳＴ７６）。
【０１７３】
（Ａ−２−３−２−２）変更要求受信処理（対向端末側エッジノード）
メッセージ受信待ち状態において（Ｓ７０）、前ホップ（コアノード３や変更元端末収容エッジノード２Ａ）からの変更要求メッセージを受信したエッジノード２Ｂの予約管理部２０１は、リソース管理部２０３と協働して、変更が可能か否かを判別する（ＳＴ７１、ＳＴ７２）。
【０１７４】
すなわち、予約管理部２０１は、リソース管理部２０３へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知する。リソース管理部２０３は、これらの情報により、変更要求メッセージの転送先インタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図６）を選定し、変更要求メッセージの要求量で変更が可能か否かを判定する。この判定式は、上述した（５）式と同一である。
【０１７５】
リソース管理部２０３は、（５）式が満たされ、変更可の場合には、仮予約リソース管理データテーブル２１０の仮予約量を上述した（６）式に従って更新して（ＳＴ７３）、変更ＯＫを予約管理部２０１へ通知すると共に、（５）式が満たされず、変更不可の場合には、変更ＮＧを予約管理部２０１へ通知する。
【０１７６】
予約管理部２０１は、変更ＯＫの場合には、次ホップ（図１７（Ｂ）の場合であれば端末１Ｂ）ヘ、受信した変更要求メッセージを送信する（ＳＴ７５）。この対向端末１Ｂを収容しているエッジノード２Ｂでは、変更要求メッセージに対するソース側エッジ−ＩＤの付与（ＳＴ７４）は省略される。
【０１７７】
これに対して、予約管理部２０１は、変更ＮＧの場合には、受信した変更要求メッセージに対応する変更応答メッセージを形成すると共に、その変更応答メッセージの結果のデータフィールドをＮＧとし、前ホップのコアノード３へ送信する（ＳＴ７６）。
【０１７８】
（Ａ−２−３−２−３）変更応答受信処理
変更応答メッセージの受信時動作は、変更元端末１Ａを収容しているエッジノード２Ａと、対向端末１Ｂを収容しているエッジノード２Ｂとの差が僅かであるのでまとめて説明する。
【０１７９】
メッセージ受信待ち状態において、下流側（端末１Ｂ又はコアノード３）から変更応答メッセージを受信すると（ＳＴ７０、ＳＴ７１）、予約管理部２０１は、変更応答メッセージの結果フィールドの内容に応じて、リソース管理部２０３にデータテーブルの更新処理を実行させる（ＳＴ７７、ＳＴ７８、ＳＴ８２）。
【０１８０】
変更応答メッセージの結果が変更ＯＫの場合には、リソース管理部２０３は、変更応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル２０８（図９参照）を選定し、このデータテーブル２０８中のインタフェース−ＩＤ２０８１、ソース側エッジ−ＩＤ２０８２、及び又は、ディスティネーション側エッジ−ＩＤ２０８３で特定できる行（レコード）の情報（予約リソース量２０８４）を（７）式に従って更新する（ＳＴ７８）。
【０１８１】
予約量［ｉ］＝予約量［ｉ］＋要求量 …（７）
ここで、ｉは変更応答メッセージの転送先のインタフェース−ＩＤに対応する番号であり、予約量［ｉ］は、番号ｉに対応するインタフェースで予約されているリソース量であり、要求量は、変更応答メッセージ（従って変更要求メッセージ）で要求されているリソース量（増減分）である。
【０１８２】
次に、予約管理部２０１は、予約管理データテーブル２０６（図６参照）の、受信した変更応答メッセージに係る行の内容を更新する（ＳＴ７８）。すなわち、Ｕｓｅｒ−ＩＤ２０６１、サービスタイプ２０６２で特定された予約リソース量２０６３を、変更応答メッセージの要求量（増減分）分だけ更新させる。なお、この際にも、Ｕｓｅｒ−ＩＤ２０６１は、変更応答メッセージのストリーム送信元ＩＤ、ストリーム送信先ＩＤ、サービスタイプ、フロー−ＩＤなどにより求める。
【０１８３】
その後、前ホップが端末１Ｂであった場合には（ＳＴ７９で肯定結果）、変更応答メッセージ中のディスティネーション側エッジ−ＩＤへ、自エッジノード２ＢのＩＤを設定した後（ＳＴ８０）に、前ホップが端末１Ｂ以外であった場合には直ちに、変更応答メッセージを次ホップ（コアノード３又は端末１Ａ）ヘ送信する（ＳＴ８１）。
【０１８４】
このようなリソース量の変更後においては、転送管理部２０２が、予約管理データテーブル２０６に違反しているか否かを変更された予約リソース量に基づいて確認し、違反しているトラフィックに対して、データの廃棄、マーキングなど、所定の処理を行う。以上のようなトラフィック違反の確認処理は、変更元端末１Ａを収容しているエッジノード２Ａのみが行うようにしても良い。
【０１８５】
これに対して、受信した変更応答メッセージの結果が変更ＮＧの場合には、リソース管理部２０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図８参照）を選定し、（８）式に従ってその内容を更新する（ＳＴ８２）。この更新処理は、仮変更した内容を取り消す処理に該当する。
【０１８６】
仮予約量＝仮予約量−要求量 …（８）
仮予約量は、インタフェースで仮予約されているリソース量であり、要求量は、変更応答メッセージ（従って変更要求メッセージ）で指定されているリソース量の増減分である。
【０１８７】
その後、予約管理部２０１は、変更ＮＧの変更応答メッセージを次ホップ（コアノード３又は端末１Ａ）ヘ送信する（ＳＴ８３）。
【０１８８】
なお、エッジノード２は、変更要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、変更応答メッセージが受信できないときには、変更ＮＧの変更応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）を下流側に送出して、変更を仮確定又は本確定したノードなどの変更を取り消すようにさせる。
【０１８９】
（Ａ−２−３−３）コアノード３の予約リソース変更動作
コアノード３での予約リソースの変更動作を図２９を用いて説明する。なお、図２９は、コアノード３としての予約リソースの変更動作を示したフローチャートである。
【０１９０】
（Ａ−２−３−３−１）変更要求受信処理
メッセージ受信待ち状態において（ＳＴ９０）、前ホップ（変更元端末収容エッジノード２Ａやコアノード３）からの変更要求メッセージを受信したコアノード３の予約管理部３０１は、リソース管理部３０３と協働して、変更が可能か否かを判別する（ＳＴ９１、ＳＴ９２）。
【０１９１】
すなわち、予約管理部３０１は、リソース管理部３０３へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知する。リソース管理部３０３は、これらの情報により、変更要求メッセージの転送先インタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル３０６（図１１参照）を選定し、変更要求メッセージの要求量で変更が可能か否かを判定する。この判定式は、上述した（５）式と同一である。
【０１９２】
リソース管理部３０３は、（５）式が満たされ、変更可の場合には、仮予約リソース管理データテーブル３０６の仮予約量を上述した（６）式に従って更新して（ＳＴ９３）、変更ＯＫを予約管理部３０１へ通知すると共に、（５）式が満たされず、変更不可の場合には、変更ＮＧを予約管理部３０１へ通知する。
【０１９３】
予約管理部３０１は、変更ＯＫの場合には、次ホップ（図１７（Ｂ）の場合であればエッジノード２Ｂ）ヘ、受信した変更要求メッセージを送信する（ＳＴ９４）。
【０１９４】
これに対して、予約管理部３０１は、変更ＮＧの場合には、受信した変更要求メッセージに対応する変更応答メッセージを形成すると共に、その変更応答メッセージの結果のデータフィールドをＮＧとし、前ホップ（エッジノード２Ａや他のコアノード３）へ送信する（ＳＴ９５）。
【０１９５】
（Ａ−２−３−３−２）変更応答受信処理
コアノード３は、メッセージ受信待ち状態において、下流側（エッジノード２Ｂや他のコアノード３）から変更応答メッセージを受信すると（ＳＴ９０、ＳＴ９１）、その予約管理部３０１は、変更応答メッセージの結果フィールドの内容に応じて、リソース管理部３０３にデータテーブルの更新処理を実行させる（ＳＴ９６、ＳＴ９７、ＳＴ９９）。
【０１９６】
変更応答メッセージの結果が変更ＯＫの場合には、リソース管理部３０３は、変更応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル３０４（図１２参照）を選定し、このデータテーブル３０４中のインタフェース−ＩＤ３０４１、ソース側エッジ−ＩＤ３０４２、及び、ディスティネーション側エッジ−ＩＤ３０４３で特定できる行（レコード）の情報（予約リソース量３０４４）を上述した（７）式に従って更新する（ＳＴ９７）。そして、予約管理部３０１は、変更ＯＫの変更応答メッセージを次ホップ（エッジノード２Ａや他のコアノード３）ヘ送信する（ＳＴ９８）。
【０１９７】
これに対して、受信した変更応答メッセージの結果が変更ＮＧの場合には、リソース管理部３０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル３０６（図１１参照）を選定し、上述した（８）式に従ってその内容を更新する（ＳＴ９９）。この更新処理は、仮変更した変更要求を取り消す処理に該当する。そして、予約管理部３０１は、変更ＮＧの変更応答メッセージを次ホップ（エッジノード２Ａや他のコアノード３）ヘ送信する（ＳＴ１００）。
【０１９８】
なお、コアノード３は、変更要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、変更応答メッセージが受信できないときには、変更ＮＧの変更応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）を下流側に送出して、変更を仮確定又は本確定したノードなどの変更を取り消すようにさせる。
【０１９９】
（Ａ−２−４）予約リソースの削除動作の詳細
次に、各部での予約リソースの削除動作（解除動作）の詳細を説明する。ここで、端末１、エッジノード２及びコアノード３の接続関係が、図１７（Ｃ）であるとして説明する。また、予約リソースの削除とは、予約したリソース量の削除を意味している。
【０２００】
なお、端末１の予約管理部１０２、各ノード２、３の予約管理部２０１、３０１はそれぞれ、削除動作面から、「ＳＴＡＲＴ」、「受信待ち」、「削除中」、「削除ＯＫ」、「削除ＮＧ」の削除管理状態を持ち、これら状態間の遷移は、図３０及び図３１に示す通りである。
【０２０１】
図３０に示すように、「ＳＴＡＲＴ」状態からは「受信待ち」状態への遷移のみが可能であり、「受信待ち」状態からは自状態又は「削除中」状態への遷移のみが可能であり、「削除中」状態からは「削除ＯＫ」状態又は「削除ＮＧ」状態への遷移が可能であり、「削除ＮＧ」状態からは「受信待ち」状態への遷移のみが可能であり、「削除ＯＫ」状態からは「受信待ち」状態又は「削除ＮＧ」状態への遷移が可能である。
【０２０２】
図３１において、縦方向に記述した５個の状態は遷移前の状態を示し、横方向に記述した５個の状態は遷移後の状態を示し、その交点の欄には、その遷移条件を記述している。［］で挟まれた文字列（例えば削除要求）は、メッセージを表している。
【０２０３】
これらの状態遷移の具体的内容については、後述する各部の削除動作説明で明らかにする。
【０２０４】
（Ａ−２−４−１）端末１の予約リソース削除動作
端末１（１Ａ、１Ｂ）での予約リソース削除動作を図３２を用いて説明する。なお、図３２は、端末１としてのリソース削除動作を示したフローチャートであり、ステップＳＴ１１０〜ＳＴ１１６がリソース削除元の端末１Ａの処理を示し、ステップＳＴ１１０、ＳＴ１１３、ＳＴ１１７〜ＳＴ１１９が端末１Ａに対向する端末１Ｂの動作を示している。
【０２０５】
端末１Ａの利用者がアプリケーション部１０１を終了するとき、利用者は、アプリケーション部１０１が使用していたネットワークサービス、及び必要なネットワークリソースの削除を指示する。このとき、予約していたリソースに対応するパラメータの指定がなければ、アプリケーション部１０１は自律で使用していたネットワークサービスに対応するパラメータを決定し、転送管理部１０３に対して、データ転送停止指示を出す。それを受けた転送管理部１０３は、データの転送を停止する。これと並行して、アプリケーション部１０１は、これらのパラメータを、予約管理部１０２へ通知する。
【０２０６】
端末１Ａの予約管理部１０２では、図３２に示す通り、イベント発生を待機しており（ＳＴ１１０）、発生イベントがアプリケーション部１０１による通信サービスの予約リソースの削除起動であり、削除に係る通信パラメータが通知されると（ＳＴ１１１）、ネットワークリソースの削除要求メッセージを編成してエッジノード２Ａの予約管理部２０１に送信し（ＳＴ１１２）、イベント発生の待機状態に戻る。
【０２０７】
ステップＳＴ１１２の削除要求メッセージの送信によって、対向する端末１Ｂに至るネットワーク全体にわたり、その予約リソースの削除（解除）を、端末１Ａが求めたことになる。
【０２０８】
エッジノード２Ａ、コアノード３、エッジノード２Ｂ、対向する端末１Ｂのそれぞれで削除が完了すると、エッジノード２Ａを介して、削除ＯＫ（可）という要求結果を含む削除応答メッセージが返信される。一方、エッジノード２Ａ、コアノード３、エッジノード２Ｂ又は対向する端末１Ｂがリソース削除を受け入れられないときは、その装置から上流に送出され始めた、ＮＧ（否）という要求結果を含む削除応答メッセージが返信される。
【０２０９】
受信したメッセージが削除応答メッセージであることを認識した端末１Ａの予約管理部１０２は（ＳＴ１１３参照）、このメッセージに含まれている要求結果、すなわち、削除の可否状態を判定し（ＳＴ１１４）、削除ＯＫであれば、削除できた旨をアプリケーション部１０１に通知する。これに対して、受信した削除応答メッセージの可否状態が削除ＮＧであれば、予約管理部１０２は、ＮＧ処理を行い、その旨をアプリケーション部１０１に通知する（ＳＴ１１６）。
【０２１０】
一方、削除元でない端末１Ｂの予約管理部１０２は、隣接するエッジノード２Ｂからの削除要求メッセージを待ち受けており、削除要求メッセージを受信すると（ＳＴ１１３参照）、削除要求メッセージ中の「ストリーム送信先ＩＤ」又は「フロー−ＩＤ」を元に、対応するアプリケーション部１０１を特定し、ネットワークサービスの終了を表す通知を上げ、削除応答メッセージを作成し、エッジノード２Ｂヘ送信する（ＳＴ１１７、ＳＴ１１８）。なお、削除応答メッセージ中の結果以外のデータ領域は、削除要求メッセージの内容をコピーする。
【０２１１】
対応するアプリケーション部１０１を特定できないような場合には、予約管理部１０２は、結果がＮＧの削除応答メッセージを作成し、エッジノード２Ｂヘ送信する（ＳＴ１１９）。
【０２１２】
なお、端末１Ａは、削除要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、削除応答メッセージが受信できないときには、ＮＧの削除応答メッセージを受信したときとほぼ同様な処理を行う。
【０２１３】
（Ａ−２−４−２）エッジノード２の予約リソース削除動作
エッジノード２（２Ａ、２Ｂ）での予約リソースの削除動作を図３３を用いて説明する。
【０２１４】
なお、図３３は、エッジノード２としての予約リソース削除動作を示したフローチャートである。削除元の端末１Ａを収容しているエッジノード２Ａの動作も、対向する端末１Ｂを収容しているエッジノード２Ｂの動作も、図３３で表すことができるが、その動作内容には多少の違いがあり、以下では、エッジノード２Ａ、２Ｂの動作を区別して説明する。
【０２１５】
（Ａ−２−４−２−１）削除要求受信処理（削除元端末側エッジノード）
メッセージ受信待ち状態において（ＳＴ１２０）、削除元端末１Ａからの削除要求メッセージを受信したエッジノード２Ａの予約管理部２０１は、受付管理部２０４と協働して、削除要求を受付可能か否かを判別する（ＳＴ１２１、ＳＴ１２２）。
【０２１６】
すなわち、受付管理部２０４へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知し、受付管理部２０４に、これら情報よりＵｓｅｒ−ＩＤを求めさせ、受付管理データテーブル２０５（図５参照）の格納内容に基づき、リソース量の削除要求を受け付けて良いか否かを確認させる。例えば、該当するリソースの予約がなされていないような場合であれば、削除要求は否定される。
【０２１７】
削除要求が受け付けＯＫの場合には、予約管理部２０１は、次ホップ（図１７（Ｃ）の場合であればコアノード３）ヘ、受信した削除要求メッセージに、ソース側エッジ−ＩＤを付与して送信する（ＳＴ１２３、ＳＴ１２４）。これ以降、転送管理部２０２は、削除要求のあったフローのトラフィックを流さない。
【０２１８】
これに対して、予約管理部２０１は、削除要求が受け付けＮＧの場合には、受信した削除要求メッセージに対応する削除応答メッセージを形成すると共に、その削除応答メッセージの結果をＮＧとし、前ホップの端末１Ａへ送信する（ＳＴ１２５）。
【０２１９】
（Ａ−２−４−２−２）削除要求受信処理（対向端末側エッジノード）
メッセージ受信待ち状態において（ＳＴ１２０）、前ホップ（コアノード３や削除元端末収容エッジノード２Ａ）からの削除要求メッセージを受信したエッジノード２Ｂの予約管理部２０１は、次ホップ（図１７（Ｃ）の場合であれば端末１Ｂ）ヘ、受信した削除要求メッセージに送信する（ＳＴ１２１、ＳＴ１２４）。このときには、削除要求メッセージへのソース側エッジ−ＩＤの付与は実行されない。これ以降、転送管理部２０２は、削除要求のあったフローのトラフィックを流さない。
【０２２０】
（Ａ−２−４−２−３）削除応答受信処理
削除応答メッセージの受信時動作は、削除元端末１Ａを収容しているエッジノード２Ａと、対向端末１Ｂを収容しているエッジノード２Ｂとの差が僅かであるのでまとめて説明する。
【０２２１】
メッセージ受信待ち状態において、下流側（端末１Ｂ又はコアノード３）から削除応答メッセージを受信すると（ＳＴ１２０、ＳＴ１２１）、予約管理部２０１は、削除応答メッセージの結果の内容にかかわらず、リソース管理部２０３などにデータテーブルの更新処理を実行させる（ＳＴ１２６、ＳＴ１２７、ＳＴ１３１）。
【０２２２】
リソース管理部２０３は、削除応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル２０８（図９参照）を選定し、このデータテーブル２０８中のインタフェース−ＩＤ２０８１、ソース側エッジ−ＩＤ２０８２、及び又は、ディスティネーション側エッジ−ＩＤ２０８３で特定できる行（レコード）の情報（予約リソース量２０８４）を（９）式に従って更新する（ＳＴ１２７、ＳＴ１３１）。特定できる行が存在しない場合にはなにもしない。
【０２２３】
予約量［ｉ］＝予約量［ｉ］−要求量 …（９）
ここで、ｉは削除応答メッセージの転送先のインタフェース−ＩＤに対応する番号であり、予約量［ｉ］は、番号ｉに対応するインタフェースで予約されているリソース量であり、要求量は、削除応答メッセージ（従って削除要求メッセージ）で要求されているリソース量である。
【０２２４】
また、リソース管理部２０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図８参照）を選定し、（１０）式に従ってその内容を更新する（ＳＴ１２７、ＳＴ１３１）。
【０２２５】
仮予約量＝仮予約量−要求量 …（１０）
仮予約量は、インタフェースで仮予約されているリソース量であり、要求量は、削除応答メッセージ（従って削除要求メッセージ）で指定されているリソース量である。
【０２２６】
さらに、予約管理部２０１は、受信した削除応答メッセージより、Ｕｓｅｒ−ＩＤを求め、予約管理データテーブル２０６（図６参照）から、そのＵｓｅｒ−ＩＤに係る行の情報（サービスタイプ、予約リソース量、インタフェース−ＩＤ、フロー−ＩＤなど）を削除する（ＳＴ１２７、ＳＴ１３１）。
【０２２７】
その後、前ホップが端末１Ｂであった場合には、削除応答メッセージ中のディスティネーション側エッジ−ＩＤへ、自エッジノード２ＢのＩＤを設定した後（ＳＴ１２８、ＳＴ１２９）に、前ホップが端末１Ｂ以外であった場合には直ちに、受信した削除応答メッセージを次ホップ（コアノード３又は端末１Ａ）ヘ送信する（ＳＴ１３０、ＳＴ１３２）。
【０２２８】
なお、エッジノード２は、削除要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、削除応答メッセージが受信できないときには、削除ＮＧの削除応答メッセージを受信したときとほぼ同様な処理を行う。
【０２２９】
（Ａ−２−４−３）コアノード３の予約リソース削除動作
コアノード３での予約リソースの削除動作を図３４を用いて説明する。なお、図３４は、コアノード３としての予約リソースの削除動作を示したフローチャートである。
【０２３０】
（Ａ−２−４−３−１）削除要求受信処理
メッセージ受信待ち状態において（ＳＴ１４０）、前ホップ（削除元端末収容エッジノード２Ａや他のコアノード３）からの削除要求メッセージを受信したコアノード３の予約管理部３０１は、次ホップ（図１７（Ｃ）の場合であればエッジノード２Ｂ）ヘ、受信した削除要求メッセージを送信する（ＳＴ１４１、ＳＴ１４２）。
【０２３１】
（Ａ−２−４−３−２）削除応答受信処理
メッセージ受信待ち状態において、下流側（エッジノード２Ｂや他のコアノード３）から削除応答メッセージを受信すると（ＳＴ１４０、ＳＴ１４１）、予約管理部３０１は、削除応答メッセージの結果の内容にかかわらず、リソース管理部３０３にデータテーブルの更新処理を実行させる（ＳＴ１４３）。
【０２３２】
すなわち、リソース管理部３０３は、削除応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル３０４（図１２参照）を選定し、このデータテーブル３０４中のインタフェース−ＩＤ３０４１、ソース側エッジ−ＩＤ３０４２、及び、ディスティネーション側エッジ−ＩＤ３０４３で特定できる行（レコード）の情報（予約リソース量３０４４）を上述した（９）式に従って更新する。特定できる行が存在しない場合にはなにもしない。
【０２３３】
また、リソース管理部３０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル３０６（図１１参照）を選定し、上述した（１０）式に従ってその内容（仮予約リソース量）を更新する。
【０２３４】
その後、予約管理部３０１は、受信した削除応答メッセージをそのまま次ホップ（エッジノード２Ａや他のコアノード３）ヘ送信する（ＳＴ１４４〜ＳＴ１４６）。
【０２３５】
なお、コアノード３は、削除要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、削除応答メッセージが受信できないときには、削除ＮＧの削除応答メッセージを受信したときとほぼ同様な処理を行う。
【０２３６】
（Ａ−２−５）ネットワークの故障検出動作
次に、ネットワークの故障の検出動作について説明する。
【０２３７】
端末１、エッジノード２、コアノード３の各故障管理部１０４、２０９、３０５は、各インタフェースの対向装置に対して、図１５で示した維持メッセージを定期的に通知する。上述した図１８が、この維持メッセージの通知の様子である。この通知に係るインタフェースは、ＶＰＮのような論理的なリンクであっても良い。
【０２３８】
維持メッセージにおける要求量及び設定量には、エッジノード２やコアノード３であれば、仮予約リソース管理データテーブル２１０や３０６、及び、リソース管理データテーブル２０８や３０４の格納内容が利用される。端末１であれば、予約したリソースに関する要求量が挿入され、設定量は空欄である。
【０２３９】
各故障管理部１０４、２０９、３０５は、アクティブなインタフェース（データ通信に供しているインタフェース）の対向装置からの維持メッセージを常に監視する。前回の維持メッセージの受信時から一定期間を越えても、維持メッセージを受信しない場合には、インタフェースの先の対向装置か、その間の物理リンクの故障と判断する。ノードの場合は、図１６に示す故障通知メッセージを生成し、通知する動作を行う。
【０２４０】
故障通知メッセージの送信元ノードＩＤや送信先ノードＩＤ以外のデータには、リソース管理データテーブル２０８や３０４の格納内容が利用される。
【０２４１】
故障と判断する他の場合は、自装置のハードウェアからの通知による場合であり、故障箇所を認識する。ノードの場合は、故障通知メッセージを生成、通知する動作を行う。このハードウェアからの通知は、物理リンクそのものの故障や、下位レイヤの通信故障通知も含む。
【０２４２】
（Ａ−２−６）故障通知メッセージの生成、通知動作
次に、故障通知メッセージの作成動作と伝播動作について説明する。
【０２４３】
各故障管理部１０４、２０９、３０５は、故障を検出した場合には、自ノードあるいは自端末の予約管理部１０２、２０１、３０１に故障を検出したインタフェースＩＤを含む故障情報を通知する（このインタフェースＩＤは論理的に付与されたものでも良い）。これを受けたノード２、３の予約管理部２０１、３０１は、以下の故障通知メッセージの生成、通知動作を行う。なお、端末１の予約管理部１０２は、通知ルートが故障により存在しないので、故障通知メッセージの生成、通知動作を実行しない。
【０２４４】
以下の説明においては、ディスティネーション方向をＤ方向、ソース方向をＳ方向と記述する。
【０２４５】
いずれかの箇所で故障が生じた場合には、「仮予約」状態や、「本予約」状態のリソース予約を削除（解除）することなどもを行う。以下、これらの処理について詳述する。
【０２４６】
（Ａ−２−６−１）エッジノード２のＳ方向インタフェースの故障認識時動作
まず、対向端末１（１Ｂ）を収容しているエッジノード２（２Ｂ）が、Ｓ方向インタフェースの故障を検出した場合について説明する。すなわち、図３５のインタフェースＡ’で故障を検出した場合について説明する。
【０２４７】
故障管理部２０９が、Ｓ方向のインタフェースの故障を検出した場合には、予約管理部２０１は、故障したインタフェースに対応するインタフェースＩＤを行の要素にもつリソース管理データテーブル２０８（図９参照）を特定し、対応した行のインタフェースＩＤと、予約管理データテーブル２０６（図６参照）より、故障通知メッセージを通知する端末１（１Ｂ）を検索し、その端末１に繋がるインタフェースから故障通知メッセージを送信する。
【０２４８】
その後、予約管理データテーブル２０６から故障通知メッセージを送信した端末１のＵｓｅｒ−ＩＤの行を全て削除する。次に、特定したリソース管理データテーブル２０８をクリアする。最後に、故障したインタフェースに対応する、仮予約リソース管理データテーブル２１０（図８参照）の仮予約量をクリアする。端末１に対する故障通知メッセージの内容は、リソース管理データテーブル２０８に対応する内容をコピーする。
【０２４９】
次に、予約元端末１（１Ａ）を収容しているエッジノード２（２Ａ）がＳ方向の対向装置である予約元端末１Ａとのインタフェースの故障を検出した場合について説明する。すなわち、図３５のインタフェースＡで故障を検出した場合について説明する。
【０２５０】
全インタフェースに対応するリソース管理データテーブル２０８から、故障検出インタフェースＩＤを含む行を検索する。故障検出インタフェースＩＤを含むリソース管理データテーブル２０８が存在する場合、その行から故障通知メッセージを作成し、リソース管理データテーブル２０８に対応するインタフェースの対向のノードに対して故障通知メッセージを送信する。
【０２５１】
また、故障検出インタフェースに係る予約管理データテーブル２０６のデータの削除処理も行う。
【０２５２】
なお、以上のような処理に代え、以下のような処理を行っても良い。
【０２５３】
故障管理部２０９がＳ方向の端末１Ａとのインタフェースの故障を検出した場合には、予約管理部２０１は、故障したインタフェースに対応する予約管理データテーブル２０６（図６参照）を特定し、そこで管理されているフローの削除通知メッセージを作成し、予約管理データテーブル２０６に記述されているインタフェースから、ネットワーク側に送信する。例えば、端末１Ａの故障を検出した場合には、予約管理部２０１は、削除要求メッセージを送信し、その端末から削除要求メッセージを受信したのと同様のテーブル処理を行う。
【０２５４】
（Ａ−２−６−２）エッジノード２のＤ方向インタフェースの故障認識時動作
まず、予約元端末１（１Ａ）を収容しているエッジノード２（２Ａ）がＤ方向インタフェースの故障を検出した場合について説明する。すなわち、図３５のインタフェースＢで故障を検出した場合について説明する。
【０２５５】
故障管理部２０９がＤ方向インタフェースの故障を検出した場合、予約管理部２０１は、故障したインタフェースに対応するリソース管理データテーブル２０８（図８参照）を特定し、このリソース管理データテーブル２０８中のインタフェースＩＤと一致するインタフェースＩＤを含むＵｓｅｒ−ＩＤの行を予約管理データテーブル（図６参照）２０６より検索し、該当する端末１に故障通知メッセージを送信する。
【０２５６】
ここで、故障通知メッセージ中のサービスタイプは、インタフェースＩＤを検出したリソース管理データテーブルに対応するサービスタイプを入れる。送信元ノードＩＤに自ノードＩＤを、送信先ノードＩＤにそのインタフェースに対応する次ホップ（端末１）のノードＩＤを入れる。その他は、検索されたリソース管理データテーブル２０８のデータを設定する。
【０２５７】
送信元ノードＩＤと送信先ノードＩＤが必要なのは、本予約プロトコルを実装しない通信ノード（ルータ）が本予約プロトコルを実装する通信ノード間に存在するときに有効となる。このときは別途、本予約プロトコルを実装する隣接ノードを検出する仕組みが必要になる。
【０２５８】
その後、予約管理データテーブル２０６から故障通知メッセージを送信した端末１（１Ａ）のＵｓｅｒ−ＩＤの行を全て削除する。次に、特定したリソース管理データテーブル２０８をクリアする。最後に、故障したインタフェースに対応する、仮予約リソース管理データテーブル２１０（図６参照）をクリアする。
【０２５９】
次に、対向端末１（１Ｂ）を収容しているエッジノード２（２Ｂ）がＤ方向インタフェースの故障（従って端末１Ｂとのインタフェースの故障）を検出した場合について説明する。すなわち、図３５のインタフェースＢ’で故障を検出した場合について説明する。
【０２６０】
故障管理部２０９がＤ方向側端末１とのインタフェースの故障を検出した場合には、予約管理部２０１は、故障したインタフェ−スに対応する予約管理データテーブル２０６を特定し、そこで管理されているフローの削除通知メッセージ（例えば結果ＯＫの削除応答メッセージを適用）を作成し、ネットワーク側に送信する。
【０２６１】
故障したインタフェースに対応する予約管理データテーブル２０６、リソース管理データテーブル２０８及び仮予約リソース管理データテーブル２１０のクリア処理も行う。
【０２６２】
なお、対向端末１Ｂを収容したエッジノード２Ｂの対向端末１Ｂとのインタフェースでの故障検出時も、予約元端末１Ａを収容したエッジノード２Ａでの上述したＤ方向側のインタフェースの故障検出時と同様な上流に向かって故障通知メッセージの送出などの処理を行うようにしても良い。
【０２６３】
（Ａ−２−６−３）コアノード３のＳ方向インタフェースの故障認識時動作
次に、コアノード３におけるＳ方向インタフェースでの故障認識時の動作を説明する。すなわち、図３５のインタフェースＣで故障を検出した場合について説明する。
【０２６４】
故障管理部３０５が故障検出したインタフェースＩＤ（Ｓ方向インタフェースのＩＤとする）を予約管理部３０１へ通知する。
【０２６５】
これを受けた予約管理部３０１は、Ｄ方向への全てのリソース管理データテーブル３０４（図１２参照）より、このインタフェースＩＤを含むリソース管理データテーブル３０４を検索し、そのリソース管理データテーブル３０４内から予約情報（行）をクリアし、その予約リソース量を仮予約リソース管理テーブル３０６（図１１参照）より減らす。その後、クリア対象を含んだ全てのリソース管理データテーブル３０６が配置されているインタフェースから、その対向ノードへ故障通知メッセージを送信する。故障通知メッセージの内容には、リソース管理データテーブルの３０４のクリアした情報に対応する内容をコピーする。
【０２６６】
（Ａ−２−６−４）コアノード３のＤ方向インタフェースの故障認識時動作
次に、コアノード３におけるＤ方向インタフェースでの故障認識時の動作を説明する。すなわち、図３５のインタフェースＤで故障を検出した場合について説明する。
【０２６７】
故障管理部３０５が故障検出したインタフェースＩＤを予約管理部３０１へ通知し、これを受けた予約管理部３０１は、このインタフェースＩＤより関連するリソース管理データテーブル３０４（図１２参照）を特定する。そして、予約管理部３０１は、このリソース管理データテーブル３０４に登録されているインタフェースＩＤに対応する全対向ノードに対して、故障通知メッセージを送信する。
【０２６８】
ここで、故障通知メッセージ中のサービスタイプは、インタフェースＩＤを検出したリソース管理データテーブルに対応するサービスタイプを入れる。送信元ノードＩＤに自ノードＩＤを、送信先ノードＩＤにそのインタフェースに対応する次ホップ（エッジノード２Ａ）のノードＩＤを入れる。その他は、検索されたリソース管理データテーブル３０４のデータを設定する。
【０２６９】
送信元ノードＩＤと送信先ノードＩＤが必要なのは、本予約プロトコルを実装しない通信ノード（ルータ）が本予約プロトコルを実装する通信ノード間に存在するときに有効となる。このときは別途、本予約プロトコルを実装する隣接ノードを検出する仕組みが必要になる。
【０２７０】
その後、特定したリソース管理データテーブル３０４や仮予約リソース管理データテーブル３０６の内容をクリアする。
【０２７１】
（Ａ−２−６−５）対向端末１Ｂの故障の認識時動作
次に、図３５のＥに示すような対向端末１Ｂの故障の認識時の動作を説明する。
【０２７２】
Ｄ側エッジノード２Ｂで対向端末１Ｂに対する維持メッセージ（Ｋｅｅｐ Ａｌｉｖｅメッセージ；ユーザ、サービスタイプ毎に行う）がタイムアウトした場合、タイムアウト発生端末１Ｂを収容するインタフェースで管理する予約管理データテーブル２０６を特定し、タイムアウトしたユーザ、サービスタイプが予約した予約量とテーブル２０６内のインタフェースＩＤを読み出し、対応する行をクリアする。
【０２７３】
次に、タイムアウトを検出したインタフェースを管理するリソース管理データテーブル２０８で、読み出したインタフェースＩＤをキーとして検索した行の予約帯域から先ほど読み出した予約帯域を減算し、この行の情報に基づき、故障通知メッセージを作成し、タイムアウトしたユーザのユーザＩＤを故障通知メッセージに設定し、キーとしたインタフェースＩＤのインタフェースから故障通知メッセージを送信する。
【０２７４】
（Ａ−２−６−６）予約元端末１Ａの故障の認識時動作
次に、図３５のＦに示すような予約元端末１Ａの故障の認識時の動作を説明する。
【０２７５】
Ｓ側エッジノード２Ａで予約元端末１Ａに対する維持メッセージ（Ｋｅｅｐ Ａｌｉｖｅメッセージ；ユーザ、サービスタイプ毎に行う）がタイムアウトした場合、タイムアウト発生端末１Ａを収容するインタフェースで管理する予約管理データテーブル２０６を特定し、タイムアウトしたユーザ、サービスタイプが予約した予約量とテーブル２０６内のインタフェースＩＤを読み出し、対応する行をクリアする。
【０２７６】
次に、読み出したインタフェースＩＤと一致するインタフェースを管理するリソース管理データテーブル２０８で、タイムアウトを検出したインタフェースＩＤをキーとして検索した行の予約帯域から先ほど読み出した予約帯域を減算し、この行の情報に基づき、故障通知メッセージを作成し、タイムアウトしたユーザのユーザＩＤを故障通知メッセージに設定し、読み出したインタフェースＩＤのインタフェースから故障通知メッセージを送信する。
【０２７７】
（Ａ−２−６−７）エッジノード２のＤ方向からの故障通知メッセージの受信動作
次に、端末１を収容しているエッジノード２がＤ方向の対向装置（コアノード３や端末１Ｂ）から故障通知メッセージを受信した場合の動作について説明する。すなわち、図３６のインタフェースＡ、Ａ’で故障通知メッセージを受信した場合の動作について説明する。
【０２７８】
この場合、故障通知メッセージにユーザＩＤが含まれている場合と、含まれていない場合とで処理が異なり、場合を分けて説明する。
【０２７９】
故障通知メッセージにユーザＩＤが含まれていない場合は、伝送路故障に相当する。この場合、故障通知メッセージを受信したインタフェースで管理するリソース管理データテーブル２０８を、通知メッセージ中のソース側エッジＩＤとディスティネーション側エッジＩＤの組をキーとしてインタフェースＩＤ（第１のインタフェースＩＤ）を検索する。検索した第１のインタフェースで管理する予約管理データテーブル２０６を、故障通知メッセージを受信したインタフェースＩＤ（第２のインタフェースＩＤ）で検索する。第２のインタフェースＩＤに係る予約管理データテーブル２０６の行にあるユーザに対して故障通知メッセージを通知し、この行をクリアする。第１のインタフェースＩＤに係るリソース管理データテーブル２０８の検索した行をクリアする。
【０２８０】
これに対して、故障通知メッセージにユーザＩＤが含まれている場合は、端末１Ｂ（アプリケーション）の故障の場合に相当する。この場合、故障通知メッセージを受信したインタフェースで管理するリソース管理データテーブル２０８を、通知メッセージ中のソース側エッジＩＤとディスティネーション側エッジＩＤの組をキーとしインタフェースＩＤ（第１のインタフェースＩＤ）を検索する。検索したインタフェースで管理する予約管理データテーブル２０６を、ユーザＩＤ、サービスタイプ、故障通知を受信したインタフェースＩＤ（第２のインタフェースＩＤ）で検索し、予約量を読み出す。そのユーザに対して、故障通知メッセージを送信後、その行をクリアする。検索された第１のインタフェースＩＤに係るリソース管理データテーブル２０８の行の予約量を、読み出した予約量で減算する。
【０２８１】
以上のような故障通知メッセージの流れは、図３９や図４１における破線矢印での流れになっている。
【０２８２】
（Ａ−２−６−８）コアノード３のＳ方向からの故障通知メッセージの受信動作次に、コアノード３がＳ方向の対向装置（他のコアノード３やエッジノード２Ａ）から故障通知メッセージを受信した場合の動作について説明する。すなわち、図３６のインタフェースＢで故障通知メッセージを受信した場合の動作について説明する。
【０２８３】
予約管理部３０１は、故障通知メッセージをＳ方向から受信した場合には、その故障通知メッセージを受信したインタフェースのインタフェースＩＤと、故障通知メッセージにおけるディスティネーション側エッジＩＤ、ソース側エッジＩＤを含む、Ｄ方向側リソース管理データテーブル３０４（図１２参照）の全てを特定する。
【０２８４】
そして、対応する行を各リソース管理データテーブル３０４内から削除し、その削除した予約リソース量を仮予約リソース管理テーブル３０６（図１１参照）より減らす。その後、クリア対象を含む全リソース管理データテーブル３０６のインタフェースに対して、故障通知メッセージを送信する。故障通知メッセージの内容には、リソース管理データテーブルの３０４のクリアした情報に対応する内容をコピーする。
【０２８５】
以上のような故障通知メッセージの流れは、図３７における点線矢印での流れになっている。
【０２８６】
（Ａ−２−６−９）コアノード３のＤ方向からの故障通知メッセージの受信動作次に、コアノード３がＤ方向の対向装置（他のコアノード３やエッジノード２Ｂ）から故障通知メッセージを受信した場合の動作について説明する。すなわち、図３６のインタフェースＣで故障通知メッセージを受信した場合の動作について説明する。
【０２８７】
予約管理部３０１が、Ｄ方向の対向装置（他のコアノード３や対向端末収容エッジノード２Ｂ）からの故障通知メッセージを受信した場合には、それを受信したインタフェースに対応するインタフェースＩＤより、それに対応するリソース管理データテーブル３０４の全てを選定する。
【０２８８】
その後、故障通知メッセージ中のソース側エッジ−ＩＤ及びディスティネーション側エッジＩＤと、リソース管理データテーブル３０４中のソース側エッジＩＤ及びディスティネーション側エッジＩＤが一致する行を検索し、一致した行のインタフェースＩＤに対応する対向装置に向けて故障通知メッセージを送信する。このとき、故障通知メッセージ中の送信元ノードＩＤは自ノードのＩＤ、送信先ノードＩＤには対向装置のＩＤを設定する。
【０２８９】
その後、一致した行の予約量の総和を求め、対応するクラスの仮予約リソース管理データテーブル３０６の仮予約量から減算し、一致した行をデータテーブル３０４から削除する。
【０２９０】
以上のような故障通知メッセージの流れは、図３７における破線矢印での流れになっている。
【０２９１】
（Ａ−２−６−１０）エッジノード２のＳ方向からの故障通知メッセージの受信動作
次に、端末１を収容しているエッジノード２がＳ方向の対向装置（コアノード３や端末１Ａ）から故障通知メッセージを受信した場合の動作について説明する。すなわち、図３６のインタフェースＤ、Ｄ’で故障通知メッセージを受信した場合の動作について説明する。
【０２９２】
この場合、故障通知メッセージにユーザＩＤが含まれている場合と、含まれていない場合とで処理が異なり、場合を分けて説明する。
【０２９３】
故障通知メッセージにユーザＩＤが含まれていない場合は、伝送路の故障に該当する。この場合、故障通知メッセージを受信したインタフェースのＩＤ（第１のインタフェースＩＤ）をキーとして、全インタフェースで管理する予約管理データテーブル２０６を検索する。検索された行にあるユーザに対して、故障通知メッセージを通知し、同じ行のインタフェースＩＤをキーとして、故障通知メッセージを受信したインタフェースで管理するリソース管理データテーブル２０８を検索する。ここで検索された行の予約量から、第１のインタフェースＩＤをキーとした上述した検索時に読み出した予約量を減算する。第１のインタフェースＩＤをキーとした上述した検索での行をクリアする。
【０２９４】
これに対して、故障通知メッセージにユーザＩＤが含まれている場合は、端末１Ａ（アプリケーション）の故障に該当する。この場合、故障通知メッセージを受信したインタフェースＩＤ（第１のインタフェースＩＤ）と通知メッセージ中のユーザＩＤをキーとして、全インタフェースで管理する予約管理データテーブル２０８を検索する。ここで、検索された行にあるユーザに対して故障通知メッセージを通知し、同じ行のインタフェースＩＤをキーとして、故障通知メッセージを受信したインタフェースで管理するリソース管理データテーブル２０８を検索する。この検索時の行の予約量から、故障通知メッセージを受信したインタフェースをキーとした検索から読み出した予約量を減算する。故障通知メッセージを受信したインタフェースをキーとした検索での行をクリアする。
【０２９５】
以上のような故障通知メッセージの流れは、図３９及び図４１における点線矢印での流れになっている。
【０２９６】
（Ａ−３）第１の実施形態の効果
上述した第１の実施形態によれば、以下の効果を奏することができる。
【０２９７】
図５〜図９、図１１及び図１１で示したデータテーブルを持ち、図１７〜図１９で示した動作シーケンスに従って、リソース予約や、予約リソースの変更や、予約リソースの削除（解除）などの処理を行うことにより、ネットワークのユーザに対し、サービスタイプ毎のリソース予約などをオンデマンドで提供することができる。
【０２９８】
ネットワークの各ノードでは、予約状態を、サービスタイプ毎に維持するため、中規模や大規模のネットワークに対しても適用することができる。
【０２９９】
ネットワークのいずれかの箇所で故障が発生したときに、故障箇所で収容していたフローのリソースを、自動的に削除することができる。
【０３００】
リソース予約の動作シーケンスの中で、ソース側エッジノードのＩＤとディスティネーション側エッジノードのＩＤを取得し、各ノードのリソース管理テーブルで管理することができる。
【０３０１】
要求量や設定量などのリソース予約に係るデータを含む維持メッセージを、隣接する装置間で授受することにより、ノード間が論理的なリンクで接続されている場合の故障や下位レイヤの通信故障を検出できる。また、このようにして検出された故障や、自装置で検出された故障を、予約リソースを特定できる情報を含む故障通知メッセージを伝播することにより、故障発生から、各部装置が検出するまでにかかる時間を短くすることができる。
【０３０２】
維持メッセージの数は、各インタフェースの片方向でたかだか１つであるため、他のトラフィックに影響を与えない。また、維持メッセージの数は、各インタフェースの片方向でたかだか１つであるため、送信間隔を短くできる。こうすることにより、故障発生から検出までにかかる時間を短縮することができる。
【０３０３】
故障検出時の各ノードの予約リソース削除方法、故障通知メッセージの転送方法、故障通知メッセージの受信時の予約リソース削除方法、故障通知メッセージの受信時の故障通知メッセージの転送方法などを規定したことにより、各種データテーブルについて、故障に関連している予約リソースのみを削除することができる。
【０３０４】
（Ｂ）他の実施形態
上記実施形態の説明においても、種々変形実施形態に言及したが、さらに、以下に例示するような変形実施形態を挙げることができる。
【０３０５】
（Ｂ−１）リソース管理データテーブル２０８、３０４でのソース側エッジ−ＩＤやディスティネーション側エッジ−ＩＤは、予約要求メッセージや予約応答メッセージの際にのみ得て、変更要求メッセージ、削除要求メッセージ、変更応答メッセージ、削除応答メッセージの授受時には当初より挿入して、新たな取得を実行しないようにしても良い。
【０３０６】
（Ｂ−２） エッジノード間でパスを設定し、このパスのＩＤを、ソース側エッジ−ＩＤとディスティネーション側エッジ−ＩＤの組情報として管理するネットワークに対しても、上述したような本発明の技術思想を適用することができる。すなわち、このパスＩＤを元に、上述した予約、変更、削除、故障検出、故障通知などの処理を実行すれば良い。これにより、例えば、ＭＰＬＳなどのラベルスイッチを適用するネットワークに対して、本発明が適用可能である。
【０３０７】
（Ｂ−３）第１の実施形態においては、各要求のフローが端末（１Ａ）であったが、エッジノード２Ａの予約管理部２０１において、任意のタイミングで、予約、変更、削除の要求を行っても良い。
【０３０８】
例えば、リソース予約機能を持たない端末に対して、予め決められた帯域をネットワーク内で予約する場合に適用できる。また、ネットワーク内で閉じて専用線の帯域予約ができる。
【０３０９】
（Ｂ−４） 上述した「予約要求」、「削除要求」、「削除要求」、「予約応答」、「削除応答」、「削除応答」の各メッセージの内容に、「方向」のデータを追加するようにしても良い。
【０３１０】
第１の実施形態では、予約要求メッセージの流れる方向のフローに対して、リソース予約を行ったが、各メッセージ中に「方向」を含めることにより、第１の実施形態で予約したのとは逆方向のフローに対しても、ネットワークフローを予約することができる。これにより、各要求のトリガーをかける場所によらず、任意の方向のフローに対して、ネットワークリソースを予約することができる。
【０３１１】
【発明の効果】
以上のように、本発明によれば、大、中規模ネットワークに対しても適用可能なネットワークリソース予約制御方法及びノードや、オンデマンドでユーザの要求を受け付けてネットワークリソースの予約を実行できるネットワークリソース予約制御方法及びノードを適用でき、そのようなネットワークリソース予約制御方法及びノードは、ネットワークの故障にも対応できる。
【図面の簡単な説明】
【図１】第１の実施形態の各種ネットワーク要素の機能的構成を示すブロック図である。
【図２】第１の実施形態のネットワーク構成を示す概略ブロック図である。
【図３】第１の実施形態のソース側端末を収容するエッジノードにおける各種テーブルの配置を示す説明図である。
【図４】第１の実施形態のディスティネーション側端末を収容するエッジノードにおける各種テーブルの配置を示す説明図である。
【図５】第１の実施形態のエッジノードの受付管理データテーブルの構成を示す説明図である。
【図６】第１の実施形態のエッジノードの予約管理データテーブルの構成を示す説明図である。
【図７】第１の実施形態のエッジノードの予約ログデータテーブルの構成を示す説明図である。
【図８】第１の実施形態のエッジノードの仮予約リソース管理データテーブルの構成を示す説明図である。
【図９】第１の実施形態のエッジノードのリソース管理データテーブルの構成を示す説明図である。
【図１０】第１の実施形態のコアノードにおける各種テーブルの配置を示す説明図である。
【図１１】第１の実施形態のコアノードの仮予約リソース管理データテーブルの構成を示す説明図である。
【図１２】第１の実施形態のコアノードのリソース管理データテーブルの構成を示す説明図である。
【図１３】第１の実施形態の各種要求メッセージのデータ部構成を示す説明図である。
【図１４】第１の実施形態の各種応答メッセージのデータ部構成を示す説明図である。
【図１５】第１の実施形態の維持メッセージのデータ部構成を示す説明図である。
【図１６】第１の実施形態の故障通知メッセージのデータ部構成を示す説明図である。
【図１７】第１の実施形態のリソース予約、変更、削除（解除）動作のメッセージの転送の様子を示す説明図である。
【図１８】第１の実施形態の維持メッセージの授受の様子を示す説明図である。
【図１９】第１の実施形態の故障通知メッセージの授受の様子を示す説明図である。
【図２０】第１の実施形態の予約管理部のリソース予約時の状態遷移図である。
【図２１】第１の実施形態の予約管理部のリソース予約時の状態遷移条件を示す説明図である。
【図２２】第１の実施形態の端末のリソース予約動作を示すフローチャートである。
【図２３】第１の実施形態のエッジノードのリソース予約動作を示すフローチャートである。
【図２４】第１の実施形態のコアノードのリソース予約動作を示すフローチャートである。
【図２５】第１の実施形態の予約管理部の予約リソース変更時の状態遷移図である。
【図２６】第１の実施形態の予約管理部の予約リソース変更時の状態遷移条件を示す説明図である。
【図２７】第１の実施形態の端末の予約リソース変更動作を示すフローチャートである。
【図２８】第１の実施形態のエッジノードの予約リソース変更動作を示すフローチャートである。
【図２９】第１の実施形態のコアノードの予約リソース変更動作を示すフローチャートである。
【図３０】第１の実施形態の予約管理部の予約リソース削除時の状態遷移図である。
【図３１】第１の実施形態の予約管理部の予約リソース削除時の状態遷移条件を示す説明図である。
【図３２】第１の実施形態の端末の予約リソース削除動作を示すフローチャートである。
【図３３】第１の実施形態のエッジノードの予約リソース削除動作を示すフローチャートである。
【図３４】第１の実施形態のコアノードの予約リソース削除動作を示すフローチャートである。
【図３５】第１の実施形態の故障検出箇所別動作の説明に供する図である。
【図３６】第１の実施形態の故障通知メッセージの受信箇所別動作の説明に供する図である。
【図３７】第１の実施形態のコアノードにおけるインタフェースと、各種データテーブルとの位置関係例を示す説明図である。
【図３８】図３７の場合における各種データテーブルの内容を示す説明図である。
【図３９】第１の実施形態の予約元端末収容エッジノードにおけるインタフェースと、各種データテーブルとの位置関係例を示す説明図である。
【図４０】図３９の場合における各種データテーブルの内容を示す説明図である。
【図４１】第１の実施形態の対向端末収容エッジノードにおけるインタフェースと、各種データテーブルとの位置関係例を示す説明図である。
【図４２】図４１の場合における各種データテーブルの内容を示す説明図である。
【符号の説明】
１、１Ａ、１Ｂ…端末、
２、２Ａ、２Ｂ…エッジノード、
３、３Ａ…コアノード、
１０１…アプリケーション部、
１０２、２０１、３０１…予約管理部、
１０３、２０２、３０２…転送管理部、
１０４、２０９、３０５…故障管理部、
２０３、３０３…リソース管理部、
２０４…受付管理部、
２０５…受付管理データテーブル、
２０６…予約管理データテーブル、
２０７…予約ログデータテーブル、
２０８、３０４…リソース管理データテーブル、
２１０、３０６…仮予約リソース管理データテーブル。
【発明の属する技術分野】
本発明は、ネットワークリソース予約制御方法及びノードに関する。
【０００２】
【従来の技術】
ＩＰネットワーク上で、画像や音声などのリアルタイムのデータストリームのトラフィックが今後増えることが予想される。このようなデータストリームのトラフィックは、従来型のトラフィックと異なり、ネットワークで帯域などを定常的に保証してやる必要がある。すなわち、アプリケーションが必要とする帯域などのネットワークリソースを予約したり解除したり維持したりするなど、制御することを要する。
【０００３】
従来より、ＩＰネットワーク上で、ネットワークのユーザ（アプリケーション）が、帯域などのネットワークリソースを予約するための従来技術として、ＲＳＶＰ（Resource Reservation Protocol）が標準化されている。例えば、ＲＳＶＰ方式では、インターネット上で予約（占有）しているリソースを、その全てのルータがデータストリーム単位で管理している。
【０００４】
また、従来の専用線を用いた予約方法のイメージに近いDiffserv（Differentiated Service）と、Policyサーバとを組み合わせて運用することにより、ユーザが必要な帯域をネットワークで確保する仕組みも標準化されている。
【０００５】
【発明が解決しようとする課題】
しかしながら、上述のようなネットワークリソースの予約方式によれば、以下のような課題があった。
【０００６】
ＲＳＶＰ方式では、ネットワークが大規模となり、そこを流れるデータストリームの数が莫大なものになったときに、各ルータでリソースを管理するための負荷が大きくなる。そのため、一般にはＲＳＶＰ方式は小規模ネットワーク程度しか利用されていない。
【０００７】
また、DiffservとPolicyサーバとを組み合わせた方式は、オンデマンドでユーザの要求を受け付けるような構成にはなっていない。
【０００８】
そのため、大、中規模ネットワークに対しても適用可能なネットワークリソース予約制御方法及びノードや、オンデマンドでユーザの要求を受け付けてネットワークリソースの予約を実行できるネットワークリソース予約制御方法及びノードが求められており、しかも、そのようなネットワークリソース予約制御方法及びノードは、ネットワークの故障にも対応できることが望まれている。
【０００９】
【課題を解決するための手段】
第１の本発明は、第１の端末及び第２の端末間のデータ転送に１以上のノードが介在するネットワークに対し、少なくともリソースを予約するネットワークリソース予約制御方法において、（１）上記第１の端末又は第２の端末を収容しているエッジノードは、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部と、リソース予約の受付用情報を記憶する予約管理データ記憶部とを備え、（２）上記第１の端末又は第２の端末を収容していないコアノードは、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部とを備え、（３）上記第１の端末から上記第２の端末へ、リソース予約を要求する予約要求メッセージ、リソース予約量を変更する変更要求メッセージ、又は、予約リソースを削除させる削除要求メッセージを送出し、上記第２の端末から上記第１の端末へ要求に対する応答メッセージを送出し、（４）各ネットワーク要素に対して、リソース予約、予約変更、削除を実行させると共に、上記各ノードが、各種要求メッセージ又は各種応答メッセージの受信により、上記各データ記憶部の内容を更新することを特徴とする。
【００１０】
第２の本発明は、第１の端末及び第２の端末間のデータ転送に１以上のノードが介在するネットワークにおける、上記第１の端末又は上記第２の端末を収容したノードにおいて、（１）転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部と、リソース予約の受付用情報を記憶する予約管理データ記憶部とを備え、（２）上記第１の端末から上記第２の端末への、リソース予約を要求する予約要求メッセージ、リソース予約量を変更する変更要求メッセージ、又は、予約リソースを削除させる削除要求メッセージを転送し、上記第２の端末から上記第１の端末への要求に対する応答メッセージを転送し、（３）リソース予約、予約変更、削除を実行すると共に、各種要求メッセージ又は各種応答メッセージの受信により、上記各データ記憶部の内容を更新することを特徴とする。
【００１１】
第３の本発明は、第１の端末及び第２の端末間のデータ転送に１以上のノードが介在するネットワークにおける、上記第１の端末又は上記第２の端末を収容したノードにおいて、（１）転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部とを備え、（２）上記第１の端末から上記第２の端末への、リソース予約を要求する予約要求メッセージ、リソース予約量を変更する変更要求メッセージ、又は、予約リソースを削除させる削除要求メッセージを転送し、上記第２の端末から上記第１の端末への要求に対する応答メッセージを転送し、（３）リソース予約、予約変更、削除を実行すると共に、各種要求メッセージ又は各種応答メッセージの受信により、上記各データ記憶部の内容を更新することを特徴とする。
【００１２】
第１〜第３の本発明において、各ノード（又は単）が、故障検出時に、故障検出に係るインタフェースを経路としている他のネットワーク要素に対し、故障通知メッセージを送出する故障管理部を有することが好ましい。
【００１３】
また、各ノードの故障管理部は、故障検出したインタフェース及び上記各データ記憶部の内容に基づき、上記故障通知メッセージを送出するネットワーク要素を認識することが好ましい。
【００１４】
さらに、各ノードの故障管理部は、他のネットワーク要素から、上記故障通知メッセージを受信したときに、受信した故障通知メッセージの内容、受信したインタフェース並びに上記各データ記憶部の内容に基づき、故障通知メッセージをさらに転送するネットワーク要素を認識して故障通知メッセージを転送することが好ましい。
【００１５】
さらにまた、各ノードは、隣接するネットワーク要素との間で、上記リソース管理データ記憶部の記憶内容に基づいて、作成した維持メッセージを授受し合い、維持メッセージの受信異常などに応じて、リンクなどの故障を検出することが好ましい。
【００１６】
また、各ノードは、上記故障通知メッセージの生成送出時や、故障通知メッセージの転送処理時に、上記各データ記憶部の故障に係る経路の情報をクリアすることが好ましい。
【００１７】
【発明の実施の形態】
（Ａ）第１の実施形態
以下、本発明によるネットワークリソース予約制御方法及びノードの第１の実施形態を図面を参照しながら詳述する。
【００１８】
この第１の実施形態は、インターネットのようなネットワーク上で、帯域などのネットワークリソースを、ユーザがオンデマンドで予約、変更、解除し得るようにしたものであり、また、いずれかのリソースの故障にも対応してネットワークリソースの予約制御を実行するようにしたものである。
【００１９】
（Ａ−１）第１の実施形態の構成
この第１の実施形態が対象としているネットワークＮは、通信事業者などが管理するものであり、図２に示すように、複数のノード２、３がリンク４を介してメッシュ、リンク状、バス状の任意の接続形態で接続されて構成されているものであり、適宜のノード２は端末（ユーザ端末）１を収容している。
【００２０】
各ノード２、３を接続するリンク４は、物理的なものであっても良く、下位レイヤのカプセル化機能などを用いた論理的なものであっても良い。また、この明細書において、通信に供する端末１を収容しているノード２をエッジノードと呼び、通信に供する端末１を収容していないノード３をコアノードと呼ぶことにする。なお、同一ノードがある通信においてはエッジノード２となり、他の通信においてはコアノード３となることもあり得る。例えば、ノード２、３はルータなどが該当するものである。
【００２１】
図１は、端末１、エッジノード２及びコアノード３の機能的構成を示すブロック図である。
【００２２】
端末１は、アプリケーション部１０１、予約管理部１０２、転送管理部１０３及び故障管理部１０４でを有する。アプリケーション部１０１は、具体的な通信サービスを提供するものであり（複数存在しても良い）、予約管理部１０２は、それに必要なネットワークリソースを予約処理するものであり、転送管理部１０３は、通信サービスで生じたデータをエッジノード２に転送するものであり、故障管理部１０４は、通信サービスでの故障管理を行うものである。
【００２３】
この端末１には、複数の通信サービスを任意に実装できるが、以下、一つの通信サービスを取り上げて説明する。
【００２４】
エッジノード２は、予約管理部２０１、転送管理部２０２、リソース管理部２０３、受付管理部２０４、受付管理データテーブル２０５、予約管理データテーブル２０６、予約ログデータテーブル２０７、リソース管理データテーブル２０８、故障管理部２０９及び仮予約リソース管理データテーブル２１０を有する。
【００２５】
予約管理部２０１は、ネットワークリソースの予約状況などを管理するものであり、転送管理部２０２は、データ転送を管理するものであり、リソース管理部２０３は、リソースの状態などを管理するものであり、受付管理部２０４は、端末１からの通信要求に対する受付管理を行うものであり、故障管理部２０９は、通信サービスでの故障管理を行うものである。
【００２６】
図３は、データのソース側端末１を収容するエッジノード２における各種テーブルの配置を示す説明図であり、図４は、データのディスティネーション側端末１を収容するエッジノード２における各種テーブルの配置を示す説明図である。
【００２７】
エッジノード２は、端末１とのインタフェースや、コアノード３や他のエッジノードとのインタフェースを有する。
【００２８】
ソース側端末１を収容するエッジノード２においては、端末１とのインタフェースは入力側のインタフェースとなり、コアノード３や他のエッジノードとのインタフェースは出力側のインタフェースとなる。このような場合のエッジノード２（ソース側端末１を収容するエッジノード２）においては、図３に示すように、端末１との各インタフェース（図３ではＩＦ＃Ｕ１及びＩＦ＃Ｕ２で示している）に関して、受付管理データテーブル２０５や予約管理データテーブル２０６や予約ログデータテーブル２０７（このテーブルは図３では省略）が機能し、コアノード３や他のエッジノードとの各インタフェース（図３ではＩＦ＃Ｔ１及びＩＦ＃Ｔ２で示している）に関して、リソース管理データテーブル２０８や仮予約リソース管理データテーブル２１０が機能する。
【００２９】
また、ディスティネーション側端末１を収容するエッジノード２においては、端末１とのインタフェースは出力側のインタフェースとなり、コアノード３や他のエッジノードとのインタフェースは入力側のインタフェースとなる。このような場合のエッジノード２（ディスティネーション側端末１を収容するエッジノード２）においては、図４に示すように、端末１との各インタフェース（図４ではＩＦ＃Ｕ１及びＩＦ＃Ｕ２で示している）に関して、予約管理データテーブル２０６やリソース管理データテーブル２０８や仮予約リソース管理データテーブル２１０が機能する。
【００３０】
受付管理データテーブル２０５は、受付管理部２０４が受付管理で利用するものであり、図５に示す構成を有する。受付管理データテーブル２０５は、ユーザが使用可能なネットワークサービスを管理するものであり、エッジノード２で分散管理されても、ネットワークを管理するサーバで集中的に管理されていても良い。後者のサーバでは、エッジノード２，２間のルートを管理しても良い。
【００３１】
受付管理データテーブル２０５は、図５に示すように、ユーザを識別するための識別子である「Ｕｓｅｒ−ＩＤ」２０５１と、このユーザがネットワークを管理する通信事業者と契約している「サービスタイプ」２０５２と、これに関する制限などを記述した「制限情報」２０５３などを含んでいる。
【００３２】
予約管理データテーブル２０６、予約ログデータテーブル２０７及び仮予約リソース管理データテーブル２１０は、予約管理部２０１が、ネットワークリソースの予約状況などを管理する際に利用するものである。上述したように、当該エッジノード２がソース側かディスティネーション側かにより、予約管理部２０１が、利用するテーブルは多少異なっている。
【００３３】
予約管理データテーブル２０６は、予約中のフローをユーザ毎に管理するためのものであり、図６に示す構成を有する。予約管理データテーブル２０６は、図６に示すように、ユーザを識別するための識別子である「Ｕｓｅｒ−ＩＤ」２０６１と、このユーザが予約している「サービスタイプ」２０６２と、ユーザが予約した「予約リソース量」２０６３と、予約フローの出先インタフェースの「インタフェース−ＩＤ」２０６４と、予約フローを識別するための識別子である「フロー−ＩＤ」２０６５とを含んでいる。
【００３４】
予約ログデータテーブル２０７は、予約管理データテーブル２０６の一部内容と、サービス提供時間や、イベント発生・終了時刻などの課金やネットワークの管理に必要なデータを格納するためのデータテーブルであり、図７に示す構成を有する。すなわち、予約ログデータテーブル２０７は、図７に示すように、ユーザを識別するための識別子である「Ｕｓｅｒ−ＩＤ」２０７１と、このユーザが予約している「サービスタイプ」２０７２と、ユーザが予約した「予約リソース量」２０７３と、ネットワークの管理に必要なデータ２０７４を含んでいる。
【００３５】
仮予約リソース管理データテーブル２１０は、図８に示すように、サービスタイプと出力インタフェース毎に存在し、「仮予約リソース量」２１０１と、保守者が割り当てる「設定リソース量」２１０２を含んでいる。
【００３６】
リソース管理データテーブル２０８は、リソース管理部２０３がリソースの管理に利用するものであり、図９に示す構成を有する。リソース管理データテーブル２０８は、サービスタイプと出力インタフェース毎に存在し、メッセージの入力インタフェースを識別するための「インタフェース−ＩＤ」２０８１、予約・変更・削除するフローの「ソース側エッジ−ＩＤ」２０８２、「ディスティネーション側エッジ−ＩＤ」２０８３、予約が完了した後のリソース量を表す「予約リソース量」２０８４を含んでいる。
【００３７】
コアノード３は、図１に示すように、予約管理部３０１、転送管理部３０２、リソース管理部３０３、リソース管理データテーブル３０４、故障管理部３０５及び仮予約リソース管理データテーブル３０６を有する。
【００３８】
図１０は、コアノード３における各種テーブルの配置を示す説明図である。
【００３９】
コアノード３は、他のコアノードや、エッジノードとのインタフェースを有する。これらインタフェースは、入力側のインタフェースとなることもあれば、出力側のインタフェースとなることがある。コアノード３においては、図１０に示すように、各フローに関して出力側のインタフェースと機能するインタフェース（図１０ではＩＦ＃Ｔ３及びＩＦ＃Ｔ４で示している）に関して、リソース管理データテーブル３０４や仮予約リソース管理データテーブル３０６が機能する。
【００４０】
コアノード３における各要素３０１、…、３０６は、エッジノード２の対応要素と同様なものである。なお、図１１及び図１２にはそれぞれ、コアノード３の仮予約リソース管理データテーブル３０６及びリソース管理データテーブル３０４の構成を示している。
【００４１】
コアノード３のリソース管理データテーブル３０４は、エッジノード２のものとほぼ同様であるが、「ソース側エッジ（ノード）−ＩＤ」３０４２及び「ディスティネーション側エッジ−ＩＤ」３０４３には、予約・変更・削除のシーケンス中で確定するエッジ−ＩＤが格納される点がエッジノード２のものと異なっている。
【００４２】
図３７は、コアノード３におけるインタフェースと、仮予約リソース管理データテーブル３０６及びリソース管理データテーブル３０４との位置関係例をフローとの関係で具体的に示す説明図である。また、図３７は、同一のサービスタイプのもののみを示しているとする。
【００４３】
図３７に示すコアノード３の例の場合、ソース側インタフェースとしてＩＦ（１）及びＩＦ（２）を有し、ディスティネーション側インタフェースとしてＩＦ（３）及びＩＦ（４）を有する。
【００４４】
仮予約リソース管理データテーブル３０６及びリソース管理データテーブル３０４はそれぞれ、ディスティネーション側インタフェース（出力インタフェース）ＩＦ（３）及びＩＦ（４）に関連して設けられている。なお、インタフェースＩＦ（３）及びＩＦ（４）がＯＵＴ及びＩＮの双方向対応ならば、インタフェースのＯＵＴ用に対応付けられて、仮予約リソース管理データテーブル３０６及びリソース管理データテーブル３０４が設けられる。
【００４５】
ディスティネーション側インタフェースＩＦ（３）を出力インタフェースとする経路は、エッジノードＥ１〜Ｅ２間（１０Ｍ）、エッジノードＥ１〜Ｅ３間（１０Ｍ）、及び、エッジノードＥ５〜Ｅ２間（１０Ｍ）であるので、インタフェースＩＦ（３）に係るリソース管理データテーブル３０４は、図３８（Ａ）に示すようになる。詳述は避けるが、インタフェースＩＦ（４）に係るリソース管理データテーブル３０４は、図３８（Ｂ）に示すようになる。
【００４６】
インタフェースＩＦ（３）に係る仮予約リソース管理データテーブル３０６の設定量が、図３８（Ｃ）に示すように、１００Ｍであれば、インタフェースＩＦ（３）を出力インタフェースとするリソース予約は１００Ｍまで可能である。今、リソース予約中のものがなければ、仮予約量（予約量）は３０Ｍであり、今後７０Ｍまでのリソース予約が可能である。
【００４７】
なお、図３８（Ｄ）には、インタフェースＩＦ（４）に係る仮予約リソース管理データテーブル３０６の構成を示している。
【００４８】
また、図３９における点線矢印は、インタフェースＩＦ（１）から受信したディスティネーション方向への後述する故障通知メッセージの転送経路を示しており、破線矢印は、インタフェースＩＦ（４）から受信したソース方向への後述する故障通知メッセージの転送経路を示している。
【００４９】
図３９は、予約元端末を収容しているエッジノード２におけるインタフェースと、各種データテーブルとの位置関係例を具体的に示す説明図である。図３９は、同一のサービスタイプのもののみを示しているとする。
【００５０】
図３９に示すエッジノード２の例の場合、ソース側インタフェースとしてＩＦ（１）及びＩＦ（２）を有し、ディスティネーション側インタフェースとしてＩＦ（３）及びＩＦ（４）を有する。
【００５１】
仮予約リソース管理データテーブル２１０及びリソース管理データテーブル２０８はそれぞれ、ディスティネーション側インタフェース（出力インタフェース）ＩＦ（３）及びＩＦ（４）に関連して設けられている。なお、インタフェースＩＦ（３）及びＩＦ（４）がＯＵＴ及びＩＮの双方向対応ならば、インタフェースのＯＵＴ用に対応付けられて、仮予約リソース管理データテーブル２１０及びリソース管理データテーブル２０８が設けられる。
【００５２】
予約管理データテーブル２０６は、ソース側インタフェース（入力インタフェース）ＩＦ（１）及びＩＦ（２）に関連して設けられている。なお、インタフェースＩＦ（１）及びＩＦ（２）がＯＵＴ及びＩＮの双方向対応ならば、インタフェースのＩＮ用に対応付けられて、予約管理データテーブル２０６が設けられる。
【００５３】
ディスティネーション側インタフェースＩＦ（３）を出力インタフェースとする、ユーザとディスティネーションエッジノードの組合せは、Ｕ１〜Ｅ１間（１０Ｍ）、Ｕ２〜Ｅ２間（１０Ｍ）、及び、Ｕ４〜Ｅ２間（１０Ｍ）であるので、インタフェースＩＦ（３）に係るリソース管理データテーブル２０８は、図４０（Ａ）に示すようになる。詳述は避けるが、インタフェースＩＦ（４）に係るリソース管理データテーブル２０８は、図４０（Ｂ）に示すようになる。
【００５４】
インタフェースＩＦ（３）に係る仮予約リソース管理データテーブル２１０の設定量が、図４０（Ｃ）に示すように、５０Ｍであれば、インタフェースＩＦ（３）を出力インタフェースとするリソース予約は５０Ｍまで可能である。今、リソース予約中のものがなければ、仮予約量（予約量）は３０Ｍであり、今後２０Ｍまでのリソース予約が可能である。なお、図４０（Ｄ）には、インタフェースＩＦ（４）に係る仮予約リソース管理データテーブル２１０の構成を示している。
【００５５】
ソース側インタフェースＩＦ（１）を入力インタフェースとするユーザ（予約元端末）は、Ｕ１〜Ｕ３であるので、インタフェースＩＦ（１）に係る予約管理データテーブル２０６は、図４０（Ｅ）に示すようになる。詳述は避けるが、インタフェースＩＦ（２）に係る予約管理データテーブル２０６は、図４０（Ｆ）に示すようになる。
【００５６】
なお、図３９における点線矢印は、インタフェースＩＦ（１）から受信したディスティネーション方向への後述する故障通知メッセージの転送経路を示しており、破線矢印は、インタフェースＩＦ（４）から受信したソース方向への後述する故障通知メッセージの転送経路を示している。
【００５７】
図４１は、対向端末を収容しているエッジノード２におけるインタフェースと、各種データテーブルとの位置関係例を示す説明図である。図４１は、同一のサービスタイプのもののみを示しているとする。
【００５８】
図４１に示すエッジノード２の例の場合、ソース側インタフェースとしてＩＦ（１）及びＩＦ（２）を有し、ディスティネーション側インタフェースとしてＩＦ（３）及びＩＦ（４）を有する。
【００５９】
仮予約リソース管理データテーブル２１０及びリソース管理データテーブル２０８はそれぞれ、ディスティネーション側インタフェース（出力インタフェース）ＩＦ（３）及びＩＦ（４）に関連して設けられている。なお、インタフェースＩＦ（３）及びＩＦ（４）がＯＵＴ及びＩＮの双方向対応ならば、インタフェースのＯＵＴ用に対応付けられて、仮予約リソース管理データテーブル２１０及びリソース管理データテーブル２０８が設けられる。
【００６０】
このディスティネーション側のエッジノード２の場合、予約管理データテーブル２０６は、ディスティネーション側インタフェースに対応付けて設けられている。
【００６１】
ディスティネーション側インタフェースＩＦ（３）を出力インタフェースとする、ソース側エッジノードとユーザとの組合せは、Ｅ１〜Ｕ１間（１０Ｍ）、Ｅ２〜Ｕ２間（１０Ｍ）、及び、Ｅ２〜Ｕ４間（１０Ｍ）であるので、インタフェースＩＦ（３）に係るリソース管理データテーブル２０８は、図４２（Ａ）に示すようになる。詳述は避けるが、インタフェースＩＦ（４）に係るリソース管理データテーブル２０８は、図４２（Ｂ）に示すようになる。
【００６２】
インタフェースＩＦ（３）に係る仮予約リソース管理データテーブル２１０の設定量が、図４２（Ｃ）に示すように、５０Ｍであれば、インタフェースＩＦ（３）を出力インタフェースとするリソース予約は５０Ｍまで可能である。今、リソース予約中のものがなければ、仮予約量（予約量）は３０Ｍであり、今後２０Ｍまでのリソース予約が可能である。なお、図４２（Ｄ）には、インタフェースＩＦ（４）に係る仮予約リソース管理データテーブル２１０の構成を示している。
【００６３】
このエッジノード２が収容する出力対象のユーザ（対向端末）は、Ｕ１〜Ｕ５であるので、予約管理データテーブル２０６は、図４２（Ｅ）に示すようになる。
【００６４】
なお、図３９における点線矢印は、インタフェースＩＦ（１）から受信したディスティネーション方向への後述する故障通知メッセージの転送経路を示しており、破線矢印は、インタフェースＩＦ（４）から受信したソース方向への後述する故障通知メッセージの転送経路を示している。
【００６５】
この第１の実施形態では、ネットワークリソースの予約・変更・削除を行うために、「予約要求」メッセージ、「予約応答」メッセージ、「変更要求」メッセージ、「変更応答」メッセージ、「削除要求」メッセージ、「削除応答」メッセージを使用する。これらメッセージは、ヘッダ部においてメッセージの種別が明らかにされる。
【００６６】
「予約要求」、「変更要求」、「削除要求」などの要求メッセージのデータ部構成はほぼ同様であり、図１３に示す構成を有する。すなわち、ストリーム送信元（端末）ＩＤ、ストリーム送信先（端末）ＩＤ、ソース側エッジ（ノード）ＩＤ、ディスティネーション側エッジ（ノード）ＩＤ、サービスタイプ、要求量及びフロー−ＩＤを含んでいる。また、「予約応答」、「変更応答」、「削除応答」などの応答メッセージのデータ部構成は同様であり、図１１に示す構成を有する。すなわち、ストリーム送信元（端末）ＩＤ、ストリーム送信先（端末）ＩＤ、ソース側エッジ（ノード）ＩＤ、ディスティネーション側エッジ（ノード）ＩＤ、サービスタイプ、要求量、フロー−ＩＤ及び要求に対する結果を含んでいる。
【００６７】
第１の実施形態のネットワークでは、その他に、「維持」メッセージ（ｋｅｅｐ ａｌｉｖｅメッセージ）や「故障通知」メッセージも授受される。
【００６８】
「維持」メッセージは、端末１、ノード２、３での予約状態を維持したり、ネットワークの故障を監視したりするためのものであり、図１５に示すように、データ部は、自ノードＩＤ、対向ノードＩＤ、サービスタイプ、要求量及び設定量を有する。「故障通知」メッセージは、各ノードが検出した故障を通知するものであり、図１６に示すように、データ部は、送信元ノードＩＤ、送信先ノードＩＤ、ソース側エッジ（ノード）ＩＤ、ディスティネーション側エッジ（ノード）ＩＤ、サービスタイプ、ユーザＩＤ及び要求量を有する。
【００６９】
（Ａ−２）第１の実施形態の動作
（Ａ−２−１）リソースの予約、変更、削除動作などの基本的な技術思想
第１の実施形態のリソースの予約、変更、削除動作の基本的な技術思想を、図１７のシーケンス図を用いて説明する。
【００７０】
なお、図１７は、データ転送元（リソース予約元）の端末１Ａから、データ転送先の端末１Ｂへのデータ転送に、エッジノード２Ａ、コアノード３、エッジノード２Ｂがこの順で介在する（中継する）場合を示している。また、以下の説明では、データの転送元側を上流、データの転送先側を下流と表現する。
【００７１】
第１の実施形態では、ネットワークリソースの予約・変更・削除を行うために、上述のように、「予約要求」メッセージ、「予約応答」メッセージ、「変更要求」メッセージ、「変更応答」メッセージ、「削除要求」メッセージ、「削除応答」メッセージなどを使用する。これらのメッセージの転送は、ＩＣＭＰやＴＣＰなどを用いてネットワーク上を伝播させる。そして、これらのメッセージが通るルートについては、一般的なルーティングテーブルに従っても良く、また、各ノードの予約管理部２０１、３０１が予約・変更時に予約状況に基づき決定するルートを選択しても良い。但し、後者の場合には、予約ルートとデータの転送ルートは同一でなければならない。
【００７２】
まず、図１７（Ａ）を参照しながら、リソースの予約動作の基本的な技術思想を説明する。
【００７３】
リソース予約元の端末１Ａは、収容されているエッジノード２Ａに必要リソース量（要求量）などの情報を含む予約要求メッセージを通知してリソース予約を行う。データ転送に介在すべき（中継処理を行う）各ノード２Ａ、３、２Ｂにおいては、上流の装置からの予約要求メッセージの受信時に、受け入れられるか否かを判別し、受け入れられる場合に、自ノードを仮予約状態にした後、下流の装置に予約要求メッセージを送出する。このように、各ノード２Ａ、３、２Ｂが、リソース予約が可能な状態であれば、予約要求メッセージが順次伝搬していき、データ転送先の端末１Ｂに到達する。
【００７４】
データ転送先の端末１Ｂは、予約要求メッセージを受信し、応じられる場合には、リソース予約を受け入れられるという結果を含む予約応答メッセージをエッジノード２Ｂに返信する。各ノード装置２Ｂ、３、２Ａにおいては、下流の装置からの受入れ可の予約応答メッセージの返信を受けると、自ノードを本予約状態にした後、上流の装置にその予約応答メッセージを送出する。リソース予約元の端末１Ａは、リソース予約を受け入れられる予約応答メッセージの返信を受けると、そのことを認識し、データ転送を開始することになる。
【００７５】
一方、各ノード２Ｂ、３、２Ａ又は端末装置１Ｂは、上流の装置からの予約要求メッセージに対し、受け入れられない場合には、自ノードを仮予約状態にすることなく、また、下流の装置に予約要求メッセージを送出することなく、上流の装置に、受け入れられない旨の予約応答メッセージを返信する。各ノード２Ｂ、３、２Ａにおいては、下流の装置からのリソース予約を受け入れられない旨の予約応答メッセージを受けると、自ノードを仮予約状態から予約待機状態に戻し、上流の装置にリソース予約を受け入れられない旨の予約応答メッセージを返信する。
【００７６】
リソース予約元の端末１Ａは、リソース予約を受け入れられない旨の予約応答メッセージの返信により、そのことを認識し、データ転送を待機することになる。
【００７７】
なお、コアノード３がない場合や、２個以上の場合であっても、さらには、端末１Ａ及び１Ｂが同一のエッジノード装置２に収容されている場合であっても、上述した技術思想に従いながら、リソース予約処理が実行される。
【００７８】
予約リソースの変更時の動作シーケンスは、リソース予約時の動作シーケンスと同様であるので、その技術思想の説明は省略する（図１７（Ｂ）参照）。
【００７９】
また、予約リソースの削除動作（予約リソースの解除動作）も、図１７（Ｃ）に示すように、端末１Ａからの削除要求メッセージが、エッジノード２Ａ、コアノード３、エッジノード２Ｂの順に下流に向けて転送され、最終的に対向する端末１Ｂに到達し、端末１Ｂがリソースの削除処理を実行したときに、逆に、削除応答メッセージが、エッジノード２Ｂ、コアノード３、エッジノード２Ａの順に上流に向けて転送され、通信に供する全てのネットワーク要素でリソースの削除（解除）が実行される。
【００８０】
予約されたリソースの予約状態は、図１８に示すように、端末を含めた隣接ノード間で、維持メッセージを授受することにより維持することができる。また、維持メッセージの授受により、ノード間の故障などを検出することもできる。
【００８１】
また、隣接するノード間を結ぶリンク（インタフェース）で故障が生じたときには、図１９に示すように、故障を認識したノード３Ａ、３Ｂが、故障通知メッセージを形成し、この故障通知メッセージを端末１Ａ、１Ｂまで伝搬することにより、通信に供していた全てのネットワーク要素で故障発生を認識し、故障リンク（インタフェース）に係る仮予約や本予約を解除することができる。
【００８２】
（Ａ−２−２）リソース予約動作の詳細
次に、各部でのリソース予約動作の詳細を説明する。ここで、端末１、エッジノード２及びコアノード３の接続関係が、上述した図１７（Ａ）であるとして説明する。
【００８３】
なお、端末１の予約管理部１０２、各ノード２、３の予約管理部２０１、３０１はそれぞれ、「ＳＴＡＲＴ」、「受信待ち」、「予約中」、「予約ＯＫ」、「予約ＮＧ」の予約管理状態を持ち、これら状態間の遷移は、図２０及び図２１に示す通りである。
【００８４】
図２０に示すように、「ＳＴＡＲＴ」状態からは「受信待ち」状態への遷移のみが可能であり、「受信待ち」状態からは自状態又は「予約中」状態への遷移のみが可能であり、「予約中」状態からは「予約ＯＫ」状態又は「予約ＮＧ」状態への遷移が可能であり、「予約ＮＧ」状態からは「受信待ち」状態への遷移のみが可能であり、「予約ＯＫ」状態からは「受信待ち」状態又は「予約ＮＧ」状態への遷移が可能である。
【００８５】
図２１において、縦方向に記述した５個の状態は遷移前の状態を示し、横方向に記述した５個の状態は遷移後の状態を示し、その交点の欄には、その遷移条件を記述している。［］で挟まれた文字列（例えば予約要求）は、メッセージを表している。
【００８６】
これらの状態遷移の具体的内容については、後述する各部の動作説明で明らかにする。
【００８７】
（Ａ−２−２−１）端末１のリソース予約動作
端末１（１Ａ、１Ｂ）でのリソース予約動作を図２０を用いて説明する。なお、図２０は、端末１としてのリソース予約動作を示したフローチャートであり、ステップＳＴ１０〜ＳＴ１６がリソース予約元の端末１Ａの処理を示し、ステップＳＴ１０、ＳＴ１３、ＳＴ１７〜ＳＴ１９が端末１Ａに対向する端末１Ｂの動作を示している。
【００８８】
端末１Ａの予約管理部１０２では、図２０に示す通り、イベント発生を待機しており（ＳＴ１０）、発生イベントがアプリケーション部１０１による通信サービスの起動であると、通信パラメータを選定する（ＳＴ１１）。
【００８９】
なお、要求側端末１Ａの利用者がアプリケーション部１０１を起動する。利用者は、必要があればアプリケーションに適したネットワークサービスや必要なネットワークリソースを指定する。指定がない場合にはアプリケーション部１０１が自律でこれらのパラメータを決定して予約管理部１０２に設定する。
【００９０】
予約管理部１０２は、通信パラメータが通知（設定）されると、ネットワークリソースの予約要求メッセージを編成してエッジノード２Ａの予約管理部２０１に送信し（ＳＴ１２）、イベント発生の待機状態に戻る。
【００９１】
なお、端末１Ａから送出された直後の予約要求メッセージのソース側エッジ−ＩＤ及びディスティネーション側エッジ−ＩＤ（図１３参照）は、空欄になっている。
【００９２】
ステップＳＴ１２の予約要求メッセージの送信によって、対向する端末１Ｂに至るネットワーク全体にわたり、そのリソースの確保（予約）を、端末１Ａが求めたことになる。
【００９３】
エッジノード２Ａ、コアノード３、エッジノード２Ｂ、対向する端末１Ｂのそれぞれで予約が完了すると、エッジノード２Ａを介して、ＯＫ（可）という要求結果を含む予約応答メッセージが返信される。一方、エッジノード２Ａ、コアノード３、エッジノード２Ｂ、対向する端末１Ｂがリソース予約を受け入れられないときは、その装置から上流に送出され始めたＮＧ（否）という要求結果を含む予約応答メッセージが返信される。
【００９４】
受信したメッセージが予約応答メッセージであることを認識した端末１Ａの予約管理部１０２は（ＳＴ１３参照）、このメッセージに含まれている要求結果、すなわち、予約の可否状態を判定し（ＳＴ１４）、ＯＫであれば、そのパラメータに基づくリソース条件が転送管理部１０３に、また予約完了がアプリケーション部１０１にそれぞれ通知される。
【００９５】
アプリケーション部１０１では、仮予約を承認することで予約完了、すなわち本予約を宣言し、これを転送管理部１０３に通知してデータの送信を開始させる。転送管理部１０３では、例えばアプリケーション部１０１からのストリームデータを予約管理部１０２で指定したリソース条件に基づいてエッジノード２Ａの転送管理部２０２に転送する（ＳＴ１５）。
【００９６】
また、受信した予約応答メッセージの可否状態がＮＧであれば、予約管理部１０２は、その旨をアプリケーション部１０１に通知して（ＳＴ１６）、イベント発生を待機する（ＳＴ１０）。
【００９７】
一方、予約元でない端末１Ｂの予約管理部１０２は、隣接するエッジノード２Ｂから予約要求メッセージを待ち受けており、予約要求メッセージを受信すると（ＳＴ１３参照）、予約要求メッセージ中の「ストリーム送信先ＩＤ」を元に、対応するアプリケーション部１０１を特定し、その状態が受信が可能な状態であるか否かを確認する（ＳＴ１７）。
【００９８】
そして、データの受信が可能な状態であれば、結果がＯＫの予約応答メッセージを作成し、エッジノード２Ｂヘ送信する（ＳＴ１８）。一方、データの受信が可能でなければ、結果がＮＧの予約応答メッセージを作成し、エッジノードヘ送信する（ＳＴ１９）。なお、予約応答メッセージ中の結果以外のデータ領域は、予約要求メッセージの内容をコピーする。
【００９９】
なお、予約元端末１Ａは、予約要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、予約応答メッセージが受信できないときには、ＮＧの予約応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）をエッジノード２Ａ側に送出して、仮予約又は本予約状態のノードなどの予約状態を取り消すようにさせる。
【０１００】
（Ａ−２−２−２）エッジノード２のリソース予約動作
エッジノード２（２Ａ、２Ｂ）でのリソース予約動作を図２３を用いて説明する。
【０１０１】
なお、図２３は、エッジノード２としてのリソース予約動作を示したフローチャートである。予約元の端末１Ａを収容しているエッジノード２Ａの動作も、対向する端末１Ｂを収容しているエッジノード２Ｂの動作も、図２３で表すことができるが、その動作内容には多少の違いがあり、以下では、エッジノード２Ａ、２Ｂの動作を区別して説明する。
【０１０２】
（Ａ−２−２−２−１）予約要求受信処理（予約元端末側エッジノード）
メッセージ受信待ち状態において（ＳＴ２０）、予約元端末１Ａからの予約要求メッセージを受信したエッジノード２Ａの予約管理部２０１は、受付管理部２０４やリソース管理部２０３と協働して、予約が可能か否かを判別する（ＳＴ２１、ＳＴ２２）。
【０１０３】
すなわち、受付管理部２０４へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知し、受付管理部２０４に、これら情報よりＵｓｅｒ−ＩＤを求めさせ、受付管理データテーブル２０５（図７参照）の格納内容（例えば制限情報）に基づき、受け付けて良いか否かを確認させる。また、受け付けＯＫの場合には、リソース管理部２０３は、例えば、図示しないルーティングテーブルなどによって予約要求メッセージの転送先インタフェース（出力側インタフェース）を特定し、その転送先インタフェースと、要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図８参照）を選定し、受信した予約要求メッセージの要求量で予約が可能かを、（１）式に従って判定する。
【０１０４】
仮予約量＋要求量≦設定量 …（１）
ここで、仮予約量は、そのインタフェース及びサービスタイプの組合せで既に仮予約されているリソース量であり、要求量は、予約要求メッセージで要求されているリソース量であり、設定量は、そのインタフェース及びサービスタイプの組合せについてネットワーク管理者により割り当てられているリソース量である。
【０１０５】
リソース管理部２０３は、（１）式が満たされ、予約可の場合には、仮予約リソース管理データテーブル２１０の仮予約量を（２）式に従って更新して（ＳＴ２３）、予約ＯＫを予約管理部２０１へ通知すると共に、（１）式が満たされず、予約不可の場合には、予約ＮＧを予約管理部２０１へ通知する。
【０１０６】
仮予約量＝仮予約量＋要求量 …（２）
予約管理部２０１は、予約ＯＫの場合には、今回の転送情報をセーブし、また、次ホップ（図１７（Ａ）の場合であればコアノード３）ヘ、受信した予約要求メッセージに、ソース側エッジ−ＩＤを付与して送信する（ＳＴ２４、ＳＴ２５）。
【０１０７】
これに対して、予約管理部２０１は、予約ＮＧの場合には、受信した予約要求メッセージに対応する予約応答メッセージを形成すると共に、その予約応答メッセージの結果のデータフィールドをＮＧとし、前ホップの端末１Ａへ送信する（ＳＴ２６）。
【０１０８】
（Ａ−２−２−２−２）予約要求受信処理（対向端末側エッジノード）
メッセージ受信待ち状態において（ＳＴ２０）、前ホップ（コアノード３や予約元端末収容エッジノード２Ａ）からの予約要求メッセージを受信したエッジノード２Ｂの予約管理部２０１は、リソース管理部２０３と協働して、予約が可能か否かを判別する（ＳＴ２１、ＳＴ２２）。
【０１０９】
すなわち、予約管理部２０１は、リソース管理部２０３へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知する。リソース管理部２０３は、例えば、これらの情報と図示しないルーティングテーブルとによって予約要求メッセージの転送先インタフェース（出力側インタフェース）を特定し、その予約要求メッセージの転送先インタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図８）を選定し、予約要求メッセージの要求量で予約が可能か否かを判定する。この判定式は、上述した（１）式と同一である。
【０１１０】
リソース管理部２０３は、（１）式が満たされ、予約可の場合には、仮予約リソース管理データテーブル２１０の仮予約量を上述した（２）式に従って更新して（ＳＴ２３）、予約ＯＫを予約管理部２０１へ通知すると共に、（１）式が満たされず、予約不可の場合には、予約ＮＧを予約管理部２０１へ通知する。
【０１１１】
予約管理部２０１は、予約ＯＫの場合には、今回の転送情報をセーブし、また、次ホップ（図１７（Ａ）の場合であれば端末１Ｂ）ヘ、受信した予約要求メッセージを送信する（ＳＴ２５）。この対向端末１Ｂを収容しているエッジノード２Ｂでは、予約要求メッセージに対するソース側エッジ−ＩＤの付与（ＳＴ２４）は省略される。
【０１１２】
これに対して、予約管理部２０１は、予約ＮＧの場合には、受信した予約要求メッセージに対応する予約応答メッセージを形成すると共に、その予約応答メッセージの結果のデータフィールドをＮＧとし、前ホップのコアノード３へ送信する（ＳＴ２６）。
【０１１３】
（Ａ−２−２−２−３）予約応答受信処理
予約応答メッセージの受信時動作は、予約元端末１Ａを収容しているエッジノード２Ａと、対向端末１Ｂを収容しているエッジノード２Ｂとの差が僅かであるのでまとめて説明する。
【０１１４】
メッセージ受信待ち状態において、下流側（端末１Ｂ又はコアノード３）から予約応答メッセージを受信すると（ＳＴ２０、ＳＴ２１）、予約管理部２０１は、予約応答メッセージの結果フィールドの内容に応じて、リソース管理部２０３にデータテーブルの更新処理を実行させる（ＳＴ２７、ＳＴ２８、ＳＴ３２）。
【０１１５】
予約応答メッセージの結果が予約ＯＫの場合には、リソース管理部２０３は、予約応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル２０８（図９参照）を選定し、このデータテーブル２０８中のインタフェース−ＩＤ２０８１、ソース側エッジ−ＩＤ２０８２、及び、ディスティネーション側エッジ−ＩＤ２０８３で特定すると共に、その行（レコード）の予約リソース量２０８４を（３）式に従って更新する（ＳＴ２８）。なお、特定できる行がない場合、リソース管理データテーブル２０８に行を追加する（ＳＴ２８）。
【０１１６】
予約量［ｉ］＝予約量［ｉ］＋要求量 …（３）
ここで、ｉは予約応答メッセージの転送先のインタフェース−ＩＤに対応する番号であり、予約量［ｉ］は、番号ｉに対応するインタフェースで予約されているリソース量であり、要求量は、予約応答メッセージ（従って予約要求メッセージ）で要求されているリソース量である。予約応答メッセージの転送先のインタフェース−ＩＤは、例えば、セーブした転送情報から求める。
【０１１７】
次に、予約管理部２０１は、予約管理データテーブル２０６（図６参照）へ、受信した予約応答メッセージに係る行を登録する（ＳＴ２８）。すなわち、Ｕｓｅｒ−ＩＤ２０６１、サービスタイプ２０６２、予約リソース量２０６３、インタフェース−ＩＤ２０６４を登録する。なお、Ｕｓｅｒ−ＩＤ２０６１は、予約応答メッセージのストリーム送信元ＩＤ、ストリーム送信先ＩＤ、サービスタイプ、フロー−ＩＤなどにより求める。予約リソース量２０６３には、予約応答メッセージの要求量が挿入される。
【０１１８】
その後、前ホップが端末１Ｂであった場合には（ＳＴ２９で肯定結果）、予約応答メッセージ中のディスティネーション側エッジ−ＩＤへ、自エッジノード２ＢのＩＤを設定した後（ＳＴ３０）に、前ホップが端末１Ｂ以外であった場合には直ちに、予約応答メッセージを次ホップ（コアノード３又は端末１Ａ）ヘ送信する（ＳＴ３１）。このような予約応答メッセージを送出するインタフェースは、上述のように、セーブした転送情報から定まったインタフェースである。
【０１１９】
このような予約後においては（データ通信が開始された以降においては）、転送管理部２０２が、予約管理データテーブル２０６に違反しているか否かを確認し、違反しているトラフィックに対して、データの廃棄、マーキングなど、所定の処理を行う。以上のようなトラフィック違反の確認処理は、予約元端末１Ａを収容しているエッジノード２Ａのみが行うようにしても良い。
【０１２０】
これに対して、受信した予約応答メッセージの結果が予約ＮＧの場合には、リソース管理部２０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図８参照）を選定し、（４）式に従ってその内容を更新する（ＳＴ３２）。この更新処理は、仮予約した予約要求を取り消す処理に該当する。
【０１２１】
仮予約量＝仮予約量−要求量 …（４）
仮予約量は、インタフェースで仮予約されているリソース量であり、要求量は、予約応答メッセージで（従って予約要求メッセージ）指定されているリソース量である。
【０１２２】
その後、予約管理部２０１は、予約ＮＧの予約応答メッセージを、セーブした転送情報から定まるインタフェースから、次ホップ（コアノード３又は端末１Ａ）ヘ送信する（ＳＴ３３）。
【０１２３】
なお、エッジノード２Ａ、２Ｂは、予約要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、予約応答メッセージが受信できないときには、ＮＧの予約応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）を下流側に送出して、仮予約又は本予約状態のノードなどの予約状態を取り消すようにさせる。
【０１２４】
（Ａ−２−２−３）コアノード３のリソース予約動作
コアノード３でのリソース予約動作を図２４を用いて説明する。
【０１２５】
なお、図２４は、コアノード３としてのリソース予約動作を示したフローチャートである。
【０１２６】
（Ａ−２−２−３−１）予約要求受信処理
メッセージ受信待ち状態において（ＳＴ４０）、前ホップ（予約元端末収容エッジノード２Ａや他のコアノード３）からの予約要求メッセージを受信したコアノード３の予約管理部３０１は、リソース管理部３０３と協働して、予約が可能か否かを判別する（ＳＴ４１、ＳＴ４２）。
【０１２７】
すなわち、予約管理部３０１は、リソース管理部３０３へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知する。リソース管理部３０３は、例えば、これらの情報と図示しないルーティングテーブルとによって予約要求メッセージの転送先インタフェース（出力側インタフェース）を特定し、予約要求メッセージの転送先インタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル３０６（図１１参照）を選定し、予約要求メッセージの要求量で予約が可能か否かを判定する。この判定式は、上述した（１）式と同一である。
【０１２８】
リソース管理部３０３は、（１）式が満たされ、予約可の場合には、仮予約リソース管理データテーブル３０６の仮予約量を上述した（２）式に従って更新して（ＳＴ４３）、予約ＯＫを予約管理部３０１へ通知すると共に、（１）式が満たされず、予約不可の場合には、予約ＮＧを予約管理部３０１へ通知する。
【０１２９】
予約管理部３０１は、予約ＯＫの場合には、転送情報をセーブすると共に、特定したインタフェースから、次ホップ（図１７（Ａ）の場合であればエッジノード２Ｂ）ヘ、受信した予約要求メッセージを送信する（ＳＴ４４）。
【０１３０】
これに対して、予約管理部３０１は、予約ＮＧの場合には、受信した予約要求メッセージに対応する予約応答メッセージを形成すると共に、その予約応答メッセージの結果のデータフィールドをＮＧとし、前ホップ（エッジノード２Ａや他のコアノード３）へ送信する（ＳＴ４５）。
【０１３１】
（Ａ−２−２−３−２）予約応答受信処理
メッセージ受信待ち状態において、下流側（エッジノード２Ｂや他のコアノード３）から予約応答メッセージを受信すると（ＳＴ４０、ＳＴ４１）、予約管理部３０１は、予約応答メッセージの結果フィールドの内容に応じて、リソース管理部３０３にデータテーブルの更新処理を実行させる（ＳＴ４６、ＳＴ４７、ＳＴ４９）。
【０１３２】
予約応答メッセージの結果が予約ＯＫの場合には、リソース管理部３０３は、予約応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル３０４（図１２参照）を選定し、このデータテーブル３０４中のインタフェース−ＩＤ３０４１（このＩＤはセーブした転送情報から特定される）、ソース側エッジ−ＩＤ３０４２、及び、ディスティネーション側エッジ−ＩＤ３０４３で特定できる行（レコード）の情報（予約リソース量３０４４）を上述した（３）式に従って更新する（ＳＴ４７）。なお、特定できる行がない場合、リソース管理データテーブル３０４に行を追加する（ＳＴ４７）。
【０１３３】
そして、予約管理部３０１は、セーブした転送情報から定まるインタフェースから、予約ＯＫの予約応答メッセージを次ホップ（エッジノード２Ａや他のコアノード３）ヘ送信する（ＳＴ４８）。
【０１３４】
これに対して、受信した予約応答メッセージの結果が予約ＮＧの場合には、リソース管理部３０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル３０６（図１１参照）を選定し、上述した（４）式に従ってその内容を更新する（ＳＴ４９）。この更新処理は、仮予約した予約要求を取り消す処理に該当する。そして、予約管理部３０１は、セーブした転送情報から定まるインタフェースから、予約ＮＧの予約応答メッセージを次ホップ（エッジノード２Ａや他のコアノード３）ヘ送信する（ＳＴ５０）。
【０１３５】
なお、コアノード３は、予約要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、予約応答メッセージが受信できないときには、ＮＧの予約応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）を下流側に送出して、仮予約又は本予約状態のノードなどの予約状態を取り消すようにさせる。
【０１３６】
（Ａ−２−２−４）リソース予約成功時の一連の流れ
以下、各要素１〜３を通したリソース予約成功時の一連の処理の流れの一例を簡単に説明する。
【０１３７】
端末１Ａは、予約要求メッセージをエッジノード２Ａへ送信する。
【０１３８】
これを受けたソース側エッジノード２Ａは、受付管理データテーブル２０５によって、ユーザの予約要求を受け付けて良いかを確認する。受付ＯＫならば、ルーティングテーブルから転送する出力側インタフェースを特定し、そのインタフェースに対応する仮予約リソース管理データテーブル２１０の記憶内容に従い、上述した（１）式で、その方向へ予約が可能かを確認する。予約ＯＫならば、予約要求メッセージをコアノード３へ転送する。このとき、ソース側エッジノード２Ａは、転送情報をセーブする。
【０１３９】
これを受けたコアノード３は、ルーティングテーブルから転送する出力側インタフェースを特定し、そのインタフェースに対応する仮予約リソース管理データテーブル３０６の記憶内容に従い、上述した（１）式で、その方向へ予約が可能かを確認する。予約ＯＫならば、予約要求メッセージをディスティネーション側エッジノード２Ｂへ転送する。このとき、コアノード３は、転送情報をセーブする。
【０１４０】
これを受けたディスティネーション側エッジノード２Ｂは、ルーティングテーブルから転送する出力側インタフェースを特定し、そのインタフェースに対応する仮予約リソース管理データテーブル２１０の記憶内容に従い、上述した（１）式で、その方向へ予約が可能かを確認する。予約ＯＫならば、予約要求メッセージを端末１Ｂへ転送する。このとき、ディスティネーション側エッジノード２Ｂは、転送情報をセーブする。
【０１４１】
端末１Ｂは、要求に応じられる場合には、予約応答メッセージをディスティネーション側エッジノード２Ｂに送信する。
【０１４２】
予約応答メッセージを受信したディスティネーション側エッジノード２Ｂは、受信インタフェースに対応するリソース管理データテーブル２０８に、ソース側エッジＩＤ、ディスティネーション側エッジＩＤ、予約リソース量を設定すると共に、予約管理データテーブル２０６に、ユーザＩＤ、サービスタイプ、予約リソース量及びフロー−ＩＤを設定し、また、フローの転送情報より転送先インタフェースを特定し、リソース管理データテーブル２０８及び予約管理データテーブル２０６のインタフェース−ＩＤにそのインタフェースを設定し、転送先インタフェースから予約応答メッセージをコアノード３へ転送する。
【０１４３】
予約応答メッセージを受信したコアノード３は、受信インタフェースに対応するリソース管理データテーブル３０４に、ソース側エッジＩＤ、ディスティネーション側エッジＩＤ、予約リソース量を設定し、また、フローの転送情報より転送先インタフェースを特定し、リソース管理データテーブル３０４のインタフェース−ＩＤにそのインタフェースを設定し、転送先インタフェースから予約応答メッセージをソース側エッジノード２Ａへ転送する。
【０１４４】
予約応答メッセージを受信したソース側エッジノード２Ａは、受信インタフェースに対応するリソース管理データテーブル２０８に、ソース側エッジＩＤ、ディスティネーション側エッジＩＤ、予約リソース量を設定し、また、フローの転送情報より転送先インタフェースを特定し、リソース管理データテーブル２０８のインタフェース−ＩＤにそのインタフェースを設定し、転送先インタフェースから予約応答メッセージを端末１Ａへ転送する。
【０１４５】
なお、上述したフローの転送情報は、フロー単位に管理しても良く（各要素の上述した動作説明はこの場合を想定している）、エッジノード間のパス毎に管理しても良い。
【０１４６】
フロー単位に管理する場合には、予約要求メッセージを受信するインタフェース毎に転送情報を管理し、その内容はフロー−ＩＤ及び転送先インタフェースのＩＤ（ディスティネーション側）である。予約応答メッセージの転送先は、予約応答メッセージ中のフロー−ＩＤを含む転送情報を管理するインタフェースである。
【０１４７】
エッジノード間のパス毎に管理する場合にも、予約要求メッセージを受信するインタフェース毎に転送情報を管理し、その内容はエッジノード間のパスＩＤ及び転送先インタフェースのＩＤ（ディスティネーション側）である。予約応答メッセージの転送先は、予約応答メッセージ中のエッジノード間のパスＩＤを含む転送情報を管理するインタフェースである。
【０１４８】
（Ａ−２−３）予約リソースの変更動作の詳細
次に、各部での予約リソースの変更動作の詳細を説明する。ここで、端末１、エッジノード２及びコアノード３の接続関係が、図１７（Ｂ）であるとして説明する。また、予約リソースの変更とは、予約したリソース量の変更を意味している。
【０１４９】
なお、端末１の予約管理部１０２、各ノード２、３の予約管理部２０１、３０１はそれぞれ、変更動作面から、「ＳＴＡＲＴ」、「受信待ち」、「変更中」、「変更ＯＫ」、「変更ＮＧ」の変更管理状態を持ち、これら状態間の遷移は、図２２及び図２３に示す通りである。
【０１５０】
図２２に示すように、「ＳＴＡＲＴ」状態からは「受信待ち」状態への遷移のみが可能であり、「受信待ち」状態からは自状態又は「変更中」状態への遷移のみが可能であり、「変更中」状態からは「変更ＯＫ」状態又は「変更ＮＧ」状態への遷移が可能であり、「変更ＮＧ」状態からは「受信待ち」状態への遷移のみが可能であり、「変更ＯＫ」状態からは「受信待ち」状態又は「変更ＮＧ」状態への遷移が可能である。
【０１５１】
図２３において、縦方向に記述した５個の状態は遷移前の状態を示し、横方向に記述した５個の状態は遷移後の状態を示し、その交点の欄には、その遷移条件を記述している。［］で挟まれた文字列（例えば変更要求）は、メッセージを表している。
【０１５２】
これらの状態遷移の具体的内容については、後述する各部の動作説明で明らかにする。
【０１５３】
（Ａ−２−３−１）端末１の予約リソース変更動作
端末１（１Ａ、１Ｂ）での予約リソース変更動作を図２７を用いて説明する。なお、図２７は、端末１としてのリソース変更動作を示したフローチャートであり、ステップＳＴ６０〜ＳＴ６６がリソース変更元の端末１Ａの処理を示し、ステップＳＴ６０、ＳＴ６３、ＳＴ６７〜ＳＴ６９が端末１Ａに対向する端末１Ｂの動作を示している。
【０１５４】
端末１Ａの予約管理部１０２では、図２７に示す通り、イベント発生を待機しており（ＳＴ６０）、発生イベントがアプリケーション部１０１による通信サービスの予約リソースの変更起動であると、通信パラメータを選定する（ＳＴ６１）。すなわち、要求側端末１Ａの利用者、又は、アプリケーション部１０１が自律で、予約中のリソースを変更する場合には、利用者又はアプリケーション部１０１が変更後のパラメータを決定し、予約管理部１０２へ通知する。
【０１５５】
予約管理部１０２は、変更に係る通信パラメータが通知されると、ネットワークリソースの変更要求メッセージを編成してエッジノード２Ａの予約管理部２０１に送信し（ＳＴ６２）、イベント発生の待機状態に戻る。
【０１５６】
ここで、変更要求メッセージの要求量には、今まで予約していた帯域と新しい帯域の差分帯域を挿入しても良く、また、今まで予約していた帯域と新しい帯域との双方を挿入しても良い。以下、差分帯域が挿入されているものとして説明する。
【０１５７】
ステップＳＴ６２の変更要求メッセージの送信によって、対向する端末１Ｂに至るネットワーク全体にわたり、その予約リソースの変更を、端末１Ａが求めたことになる。
【０１５８】
エッジノード２Ａ、コアノード３、エッジノード２Ｂ、対向する端末１Ｂのそれぞれで変更が完了すると、エッジノード２Ａを介して、変更ＯＫ（可）という要求結果を含む変更応答メッセージが返信される。一方、エッジノード２Ａ、コアノード３、エッジノード２Ｂ又は対向する端末１Ｂがリソース量変更を受け入れられないときは、その装置から上流に送出され始めた、ＮＧ（否）という要求結果を含む変更応答メッセージが返信される。
【０１５９】
受信したメッセージが変更応答メッセージであることを認識した端末１Ａの予約管理部１０２は（ＳＴ６３参照）、このメッセージに含まれている要求結果、すなわち、変更の可否状態を判定し（ＳＴ６４）、ＯＫであれば、変更した条件が転送管理部１０３に、また変更完了がアプリケーション部１０１にそれぞれ通知される。
【０１６０】
アプリケーション部１０１では、予約変更を転送管理部１０３に通知して変更後のデータの送信を開始させる。転送管理部１０３は、例えばアプリケーション部１０１からのストリームデータを予約管理部１０２で指定された変更後のリソース条件に基づいてエッジノード２Ａの転送管理部２０２に転送する（ＳＴ６５）。
【０１６１】
また、受信した変更応答メッセージの可否状態がＮＧであれば、予約管理部１０２は、その旨をアプリケーション部１０１に通知する（ＳＴ６６）。このとき、今までと同じリソース条件でデータ転送が実行される。
【０１６２】
一方、変更元でない端末１Ｂの予約管理部１０２は、隣接するエッジノード２Ｂからの変更要求メッセージを待ち受けており、変更要求メッセージを受信すると（ＳＴ６３参照）、変更要求メッセージ中の「ストリーム送信先ＩＤ」を元に、対応するアプリケーション部１０１を特定し、その状態が変更リソース量のデータの受信が可能な状態であるか否かを確認する（ＳＴ６７）。
【０１６３】
そして、データの受信が可能な状態であれば、結果がＯＫの変更応答メッセージを作成し、エッジノード２Ｂヘ送信する（ＳＴ６８）。一方、データの受信が可能でなければ、結果がＮＧの変更応答メッセージを作成し、エッジノード２Ｂヘ送信する（ＳＴ６９）。なお、変更応答メッセージ中の結果以外のデータ領域は、変更要求メッセージの内容をコピーする。
【０１６４】
なお、端末１Ａは、変更要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、変更応答メッセージが受信できないときには、ＮＧの変更応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）を下流側に送出して、変更を仮確定又は本確定したノードなどの変更を取り消すようにさせる。
【０１６５】
（Ａ−２−３−２）エッジノード２の予約リソース変更動作
エッジノード２（２Ａ、２Ｂ）での予約リソース変更動作を図２８を用いて説明する。
【０１６６】
なお、図２８は、エッジノード２としての予約リソース変更動作を示したフローチャートである。変更元の端末１Ａを収容しているエッジノード２Ａの動作も、対向する端末１Ｂを収容しているエッジノード２Ｂの動作も、図２８で表すことができるが、その動作内容には多少の違いがあり、以下では、エッジノード２Ａ、２Ｂの動作を区別して説明する。
【０１６７】
（Ａ−２−３−２−１）変更要求受信処理（変更元端末側エッジノード）
メッセージ受信待ち状態において（ＳＴ７０）、変更元端末１Ａからの変更要求メッセージを受信したエッジノード２Ａの予約管理部２０１は、受付管理部２０４やリソース管理部２０３と協働して、変更が可能か否かを判別する（ＳＴ７１、ＳＴ７２）。
【０１６８】
すなわち、受付管理部２０４へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知し、受付管理部２０４に、これら情報よりＵｓｅｒ−ＩＤを求めさせ、受付管理データテーブル２０５（図５参照）の格納内容（例えば制限情報）に基づき、リソース量の変更を受け付けて良いか否かを確認させる。また、受け付けＯＫの場合には、リソース管理部２０３は、変更要求メッセージの転送先インタフェースと、要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図６参照）を選定し、受信した変更要求メッセージの要求量（増減分）で変更が可能かを、（５）式に従って判定する。
【０１６９】
仮予約量＋要求量≦設定量 …（５）
ここで、仮予約量は、そのインタフェース及びサービスタイプの組合せで既に仮予約されているリソース量（既に予約されているリソース量を含む）であり、要求量は、変更要求メッセージで要求されている増減するリソース量であり、設定量は、そのインタフェース及びサービスタイプの組合せについてネットワーク管理者により割り当てられているリソース量である。
【０１７０】
リソース管理部２０３は、（５）式が満たされ、変更可の場合には、仮予約リソース管理データテーブル２１０の仮予約量を（６）式に従って更新して（ＳＴ７３）、変更ＯＫを予約管理部２０１へ通知すると共に、（５）式が満たされず、変更不可の場合には、変更ＮＧを予約管理部２０１へ通知する。
【０１７１】
仮予約量＝仮予約量＋要求量 …（６）
予約管理部２０１は、変更ＯＫの場合には、次ホップ（図１７（Ｂ）の場合であればコアノード３）ヘ、受信した変更要求メッセージに、ソース側エッジ−ＩＤを付与して送信する（ＳＴ７４、ＳＴ７５）。
【０１７２】
これに対して、予約管理部２０１は、変更ＮＧの場合には、受信した変更要求メッセージに対応する変更応答メッセージを形成すると共に、その変更応答メッセージの結果のデータフィールドをＮＧとし、前ホップの端末１Ａへ送信する（ＳＴ７６）。
【０１７３】
（Ａ−２−３−２−２）変更要求受信処理（対向端末側エッジノード）
メッセージ受信待ち状態において（Ｓ７０）、前ホップ（コアノード３や変更元端末収容エッジノード２Ａ）からの変更要求メッセージを受信したエッジノード２Ｂの予約管理部２０１は、リソース管理部２０３と協働して、変更が可能か否かを判別する（ＳＴ７１、ＳＴ７２）。
【０１７４】
すなわち、予約管理部２０１は、リソース管理部２０３へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知する。リソース管理部２０３は、これらの情報により、変更要求メッセージの転送先インタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図６）を選定し、変更要求メッセージの要求量で変更が可能か否かを判定する。この判定式は、上述した（５）式と同一である。
【０１７５】
リソース管理部２０３は、（５）式が満たされ、変更可の場合には、仮予約リソース管理データテーブル２１０の仮予約量を上述した（６）式に従って更新して（ＳＴ７３）、変更ＯＫを予約管理部２０１へ通知すると共に、（５）式が満たされず、変更不可の場合には、変更ＮＧを予約管理部２０１へ通知する。
【０１７６】
予約管理部２０１は、変更ＯＫの場合には、次ホップ（図１７（Ｂ）の場合であれば端末１Ｂ）ヘ、受信した変更要求メッセージを送信する（ＳＴ７５）。この対向端末１Ｂを収容しているエッジノード２Ｂでは、変更要求メッセージに対するソース側エッジ−ＩＤの付与（ＳＴ７４）は省略される。
【０１７７】
これに対して、予約管理部２０１は、変更ＮＧの場合には、受信した変更要求メッセージに対応する変更応答メッセージを形成すると共に、その変更応答メッセージの結果のデータフィールドをＮＧとし、前ホップのコアノード３へ送信する（ＳＴ７６）。
【０１７８】
（Ａ−２−３−２−３）変更応答受信処理
変更応答メッセージの受信時動作は、変更元端末１Ａを収容しているエッジノード２Ａと、対向端末１Ｂを収容しているエッジノード２Ｂとの差が僅かであるのでまとめて説明する。
【０１７９】
メッセージ受信待ち状態において、下流側（端末１Ｂ又はコアノード３）から変更応答メッセージを受信すると（ＳＴ７０、ＳＴ７１）、予約管理部２０１は、変更応答メッセージの結果フィールドの内容に応じて、リソース管理部２０３にデータテーブルの更新処理を実行させる（ＳＴ７７、ＳＴ７８、ＳＴ８２）。
【０１８０】
変更応答メッセージの結果が変更ＯＫの場合には、リソース管理部２０３は、変更応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル２０８（図９参照）を選定し、このデータテーブル２０８中のインタフェース−ＩＤ２０８１、ソース側エッジ−ＩＤ２０８２、及び又は、ディスティネーション側エッジ−ＩＤ２０８３で特定できる行（レコード）の情報（予約リソース量２０８４）を（７）式に従って更新する（ＳＴ７８）。
【０１８１】
予約量［ｉ］＝予約量［ｉ］＋要求量 …（７）
ここで、ｉは変更応答メッセージの転送先のインタフェース−ＩＤに対応する番号であり、予約量［ｉ］は、番号ｉに対応するインタフェースで予約されているリソース量であり、要求量は、変更応答メッセージ（従って変更要求メッセージ）で要求されているリソース量（増減分）である。
【０１８２】
次に、予約管理部２０１は、予約管理データテーブル２０６（図６参照）の、受信した変更応答メッセージに係る行の内容を更新する（ＳＴ７８）。すなわち、Ｕｓｅｒ−ＩＤ２０６１、サービスタイプ２０６２で特定された予約リソース量２０６３を、変更応答メッセージの要求量（増減分）分だけ更新させる。なお、この際にも、Ｕｓｅｒ−ＩＤ２０６１は、変更応答メッセージのストリーム送信元ＩＤ、ストリーム送信先ＩＤ、サービスタイプ、フロー−ＩＤなどにより求める。
【０１８３】
その後、前ホップが端末１Ｂであった場合には（ＳＴ７９で肯定結果）、変更応答メッセージ中のディスティネーション側エッジ−ＩＤへ、自エッジノード２ＢのＩＤを設定した後（ＳＴ８０）に、前ホップが端末１Ｂ以外であった場合には直ちに、変更応答メッセージを次ホップ（コアノード３又は端末１Ａ）ヘ送信する（ＳＴ８１）。
【０１８４】
このようなリソース量の変更後においては、転送管理部２０２が、予約管理データテーブル２０６に違反しているか否かを変更された予約リソース量に基づいて確認し、違反しているトラフィックに対して、データの廃棄、マーキングなど、所定の処理を行う。以上のようなトラフィック違反の確認処理は、変更元端末１Ａを収容しているエッジノード２Ａのみが行うようにしても良い。
【０１８５】
これに対して、受信した変更応答メッセージの結果が変更ＮＧの場合には、リソース管理部２０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図８参照）を選定し、（８）式に従ってその内容を更新する（ＳＴ８２）。この更新処理は、仮変更した内容を取り消す処理に該当する。
【０１８６】
仮予約量＝仮予約量−要求量 …（８）
仮予約量は、インタフェースで仮予約されているリソース量であり、要求量は、変更応答メッセージ（従って変更要求メッセージ）で指定されているリソース量の増減分である。
【０１８７】
その後、予約管理部２０１は、変更ＮＧの変更応答メッセージを次ホップ（コアノード３又は端末１Ａ）ヘ送信する（ＳＴ８３）。
【０１８８】
なお、エッジノード２は、変更要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、変更応答メッセージが受信できないときには、変更ＮＧの変更応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）を下流側に送出して、変更を仮確定又は本確定したノードなどの変更を取り消すようにさせる。
【０１８９】
（Ａ−２−３−３）コアノード３の予約リソース変更動作
コアノード３での予約リソースの変更動作を図２９を用いて説明する。なお、図２９は、コアノード３としての予約リソースの変更動作を示したフローチャートである。
【０１９０】
（Ａ−２−３−３−１）変更要求受信処理
メッセージ受信待ち状態において（ＳＴ９０）、前ホップ（変更元端末収容エッジノード２Ａやコアノード３）からの変更要求メッセージを受信したコアノード３の予約管理部３０１は、リソース管理部３０３と協働して、変更が可能か否かを判別する（ＳＴ９１、ＳＴ９２）。
【０１９１】
すなわち、予約管理部３０１は、リソース管理部３０３へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知する。リソース管理部３０３は、これらの情報により、変更要求メッセージの転送先インタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル３０６（図１１参照）を選定し、変更要求メッセージの要求量で変更が可能か否かを判定する。この判定式は、上述した（５）式と同一である。
【０１９２】
リソース管理部３０３は、（５）式が満たされ、変更可の場合には、仮予約リソース管理データテーブル３０６の仮予約量を上述した（６）式に従って更新して（ＳＴ９３）、変更ＯＫを予約管理部３０１へ通知すると共に、（５）式が満たされず、変更不可の場合には、変更ＮＧを予約管理部３０１へ通知する。
【０１９３】
予約管理部３０１は、変更ＯＫの場合には、次ホップ（図１７（Ｂ）の場合であればエッジノード２Ｂ）ヘ、受信した変更要求メッセージを送信する（ＳＴ９４）。
【０１９４】
これに対して、予約管理部３０１は、変更ＮＧの場合には、受信した変更要求メッセージに対応する変更応答メッセージを形成すると共に、その変更応答メッセージの結果のデータフィールドをＮＧとし、前ホップ（エッジノード２Ａや他のコアノード３）へ送信する（ＳＴ９５）。
【０１９５】
（Ａ−２−３−３−２）変更応答受信処理
コアノード３は、メッセージ受信待ち状態において、下流側（エッジノード２Ｂや他のコアノード３）から変更応答メッセージを受信すると（ＳＴ９０、ＳＴ９１）、その予約管理部３０１は、変更応答メッセージの結果フィールドの内容に応じて、リソース管理部３０３にデータテーブルの更新処理を実行させる（ＳＴ９６、ＳＴ９７、ＳＴ９９）。
【０１９６】
変更応答メッセージの結果が変更ＯＫの場合には、リソース管理部３０３は、変更応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル３０４（図１２参照）を選定し、このデータテーブル３０４中のインタフェース−ＩＤ３０４１、ソース側エッジ−ＩＤ３０４２、及び、ディスティネーション側エッジ−ＩＤ３０４３で特定できる行（レコード）の情報（予約リソース量３０４４）を上述した（７）式に従って更新する（ＳＴ９７）。そして、予約管理部３０１は、変更ＯＫの変更応答メッセージを次ホップ（エッジノード２Ａや他のコアノード３）ヘ送信する（ＳＴ９８）。
【０１９７】
これに対して、受信した変更応答メッセージの結果が変更ＮＧの場合には、リソース管理部３０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル３０６（図１１参照）を選定し、上述した（８）式に従ってその内容を更新する（ＳＴ９９）。この更新処理は、仮変更した変更要求を取り消す処理に該当する。そして、予約管理部３０１は、変更ＮＧの変更応答メッセージを次ホップ（エッジノード２Ａや他のコアノード３）ヘ送信する（ＳＴ１００）。
【０１９８】
なお、コアノード３は、変更要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、変更応答メッセージが受信できないときには、変更ＮＧの変更応答メッセージを受信したときとほぼ同様な処理を行う。また、取消メッセージ（フォーマットの図示は省略）を下流側に送出して、変更を仮確定又は本確定したノードなどの変更を取り消すようにさせる。
【０１９９】
（Ａ−２−４）予約リソースの削除動作の詳細
次に、各部での予約リソースの削除動作（解除動作）の詳細を説明する。ここで、端末１、エッジノード２及びコアノード３の接続関係が、図１７（Ｃ）であるとして説明する。また、予約リソースの削除とは、予約したリソース量の削除を意味している。
【０２００】
なお、端末１の予約管理部１０２、各ノード２、３の予約管理部２０１、３０１はそれぞれ、削除動作面から、「ＳＴＡＲＴ」、「受信待ち」、「削除中」、「削除ＯＫ」、「削除ＮＧ」の削除管理状態を持ち、これら状態間の遷移は、図３０及び図３１に示す通りである。
【０２０１】
図３０に示すように、「ＳＴＡＲＴ」状態からは「受信待ち」状態への遷移のみが可能であり、「受信待ち」状態からは自状態又は「削除中」状態への遷移のみが可能であり、「削除中」状態からは「削除ＯＫ」状態又は「削除ＮＧ」状態への遷移が可能であり、「削除ＮＧ」状態からは「受信待ち」状態への遷移のみが可能であり、「削除ＯＫ」状態からは「受信待ち」状態又は「削除ＮＧ」状態への遷移が可能である。
【０２０２】
図３１において、縦方向に記述した５個の状態は遷移前の状態を示し、横方向に記述した５個の状態は遷移後の状態を示し、その交点の欄には、その遷移条件を記述している。［］で挟まれた文字列（例えば削除要求）は、メッセージを表している。
【０２０３】
これらの状態遷移の具体的内容については、後述する各部の削除動作説明で明らかにする。
【０２０４】
（Ａ−２−４−１）端末１の予約リソース削除動作
端末１（１Ａ、１Ｂ）での予約リソース削除動作を図３２を用いて説明する。なお、図３２は、端末１としてのリソース削除動作を示したフローチャートであり、ステップＳＴ１１０〜ＳＴ１１６がリソース削除元の端末１Ａの処理を示し、ステップＳＴ１１０、ＳＴ１１３、ＳＴ１１７〜ＳＴ１１９が端末１Ａに対向する端末１Ｂの動作を示している。
【０２０５】
端末１Ａの利用者がアプリケーション部１０１を終了するとき、利用者は、アプリケーション部１０１が使用していたネットワークサービス、及び必要なネットワークリソースの削除を指示する。このとき、予約していたリソースに対応するパラメータの指定がなければ、アプリケーション部１０１は自律で使用していたネットワークサービスに対応するパラメータを決定し、転送管理部１０３に対して、データ転送停止指示を出す。それを受けた転送管理部１０３は、データの転送を停止する。これと並行して、アプリケーション部１０１は、これらのパラメータを、予約管理部１０２へ通知する。
【０２０６】
端末１Ａの予約管理部１０２では、図３２に示す通り、イベント発生を待機しており（ＳＴ１１０）、発生イベントがアプリケーション部１０１による通信サービスの予約リソースの削除起動であり、削除に係る通信パラメータが通知されると（ＳＴ１１１）、ネットワークリソースの削除要求メッセージを編成してエッジノード２Ａの予約管理部２０１に送信し（ＳＴ１１２）、イベント発生の待機状態に戻る。
【０２０７】
ステップＳＴ１１２の削除要求メッセージの送信によって、対向する端末１Ｂに至るネットワーク全体にわたり、その予約リソースの削除（解除）を、端末１Ａが求めたことになる。
【０２０８】
エッジノード２Ａ、コアノード３、エッジノード２Ｂ、対向する端末１Ｂのそれぞれで削除が完了すると、エッジノード２Ａを介して、削除ＯＫ（可）という要求結果を含む削除応答メッセージが返信される。一方、エッジノード２Ａ、コアノード３、エッジノード２Ｂ又は対向する端末１Ｂがリソース削除を受け入れられないときは、その装置から上流に送出され始めた、ＮＧ（否）という要求結果を含む削除応答メッセージが返信される。
【０２０９】
受信したメッセージが削除応答メッセージであることを認識した端末１Ａの予約管理部１０２は（ＳＴ１１３参照）、このメッセージに含まれている要求結果、すなわち、削除の可否状態を判定し（ＳＴ１１４）、削除ＯＫであれば、削除できた旨をアプリケーション部１０１に通知する。これに対して、受信した削除応答メッセージの可否状態が削除ＮＧであれば、予約管理部１０２は、ＮＧ処理を行い、その旨をアプリケーション部１０１に通知する（ＳＴ１１６）。
【０２１０】
一方、削除元でない端末１Ｂの予約管理部１０２は、隣接するエッジノード２Ｂからの削除要求メッセージを待ち受けており、削除要求メッセージを受信すると（ＳＴ１１３参照）、削除要求メッセージ中の「ストリーム送信先ＩＤ」又は「フロー−ＩＤ」を元に、対応するアプリケーション部１０１を特定し、ネットワークサービスの終了を表す通知を上げ、削除応答メッセージを作成し、エッジノード２Ｂヘ送信する（ＳＴ１１７、ＳＴ１１８）。なお、削除応答メッセージ中の結果以外のデータ領域は、削除要求メッセージの内容をコピーする。
【０２１１】
対応するアプリケーション部１０１を特定できないような場合には、予約管理部１０２は、結果がＮＧの削除応答メッセージを作成し、エッジノード２Ｂヘ送信する（ＳＴ１１９）。
【０２１２】
なお、端末１Ａは、削除要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、削除応答メッセージが受信できないときには、ＮＧの削除応答メッセージを受信したときとほぼ同様な処理を行う。
【０２１３】
（Ａ−２−４−２）エッジノード２の予約リソース削除動作
エッジノード２（２Ａ、２Ｂ）での予約リソースの削除動作を図３３を用いて説明する。
【０２１４】
なお、図３３は、エッジノード２としての予約リソース削除動作を示したフローチャートである。削除元の端末１Ａを収容しているエッジノード２Ａの動作も、対向する端末１Ｂを収容しているエッジノード２Ｂの動作も、図３３で表すことができるが、その動作内容には多少の違いがあり、以下では、エッジノード２Ａ、２Ｂの動作を区別して説明する。
【０２１５】
（Ａ−２−４−２−１）削除要求受信処理（削除元端末側エッジノード）
メッセージ受信待ち状態において（ＳＴ１２０）、削除元端末１Ａからの削除要求メッセージを受信したエッジノード２Ａの予約管理部２０１は、受付管理部２０４と協働して、削除要求を受付可能か否かを判別する（ＳＴ１２１、ＳＴ１２２）。
【０２１６】
すなわち、受付管理部２０４へ「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、「サービスタイプ」、「要求量」、「フロー−ＩＤ」を通知し、受付管理部２０４に、これら情報よりＵｓｅｒ−ＩＤを求めさせ、受付管理データテーブル２０５（図５参照）の格納内容に基づき、リソース量の削除要求を受け付けて良いか否かを確認させる。例えば、該当するリソースの予約がなされていないような場合であれば、削除要求は否定される。
【０２１７】
削除要求が受け付けＯＫの場合には、予約管理部２０１は、次ホップ（図１７（Ｃ）の場合であればコアノード３）ヘ、受信した削除要求メッセージに、ソース側エッジ−ＩＤを付与して送信する（ＳＴ１２３、ＳＴ１２４）。これ以降、転送管理部２０２は、削除要求のあったフローのトラフィックを流さない。
【０２１８】
これに対して、予約管理部２０１は、削除要求が受け付けＮＧの場合には、受信した削除要求メッセージに対応する削除応答メッセージを形成すると共に、その削除応答メッセージの結果をＮＧとし、前ホップの端末１Ａへ送信する（ＳＴ１２５）。
【０２１９】
（Ａ−２−４−２−２）削除要求受信処理（対向端末側エッジノード）
メッセージ受信待ち状態において（ＳＴ１２０）、前ホップ（コアノード３や削除元端末収容エッジノード２Ａ）からの削除要求メッセージを受信したエッジノード２Ｂの予約管理部２０１は、次ホップ（図１７（Ｃ）の場合であれば端末１Ｂ）ヘ、受信した削除要求メッセージに送信する（ＳＴ１２１、ＳＴ１２４）。このときには、削除要求メッセージへのソース側エッジ−ＩＤの付与は実行されない。これ以降、転送管理部２０２は、削除要求のあったフローのトラフィックを流さない。
【０２２０】
（Ａ−２−４−２−３）削除応答受信処理
削除応答メッセージの受信時動作は、削除元端末１Ａを収容しているエッジノード２Ａと、対向端末１Ｂを収容しているエッジノード２Ｂとの差が僅かであるのでまとめて説明する。
【０２２１】
メッセージ受信待ち状態において、下流側（端末１Ｂ又はコアノード３）から削除応答メッセージを受信すると（ＳＴ１２０、ＳＴ１２１）、予約管理部２０１は、削除応答メッセージの結果の内容にかかわらず、リソース管理部２０３などにデータテーブルの更新処理を実行させる（ＳＴ１２６、ＳＴ１２７、ＳＴ１３１）。
【０２２２】
リソース管理部２０３は、削除応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル２０８（図９参照）を選定し、このデータテーブル２０８中のインタフェース−ＩＤ２０８１、ソース側エッジ−ＩＤ２０８２、及び又は、ディスティネーション側エッジ−ＩＤ２０８３で特定できる行（レコード）の情報（予約リソース量２０８４）を（９）式に従って更新する（ＳＴ１２７、ＳＴ１３１）。特定できる行が存在しない場合にはなにもしない。
【０２２３】
予約量［ｉ］＝予約量［ｉ］−要求量 …（９）
ここで、ｉは削除応答メッセージの転送先のインタフェース−ＩＤに対応する番号であり、予約量［ｉ］は、番号ｉに対応するインタフェースで予約されているリソース量であり、要求量は、削除応答メッセージ（従って削除要求メッセージ）で要求されているリソース量である。
【０２２４】
また、リソース管理部２０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル２１０（図８参照）を選定し、（１０）式に従ってその内容を更新する（ＳＴ１２７、ＳＴ１３１）。
【０２２５】
仮予約量＝仮予約量−要求量 …（１０）
仮予約量は、インタフェースで仮予約されているリソース量であり、要求量は、削除応答メッセージ（従って削除要求メッセージ）で指定されているリソース量である。
【０２２６】
さらに、予約管理部２０１は、受信した削除応答メッセージより、Ｕｓｅｒ−ＩＤを求め、予約管理データテーブル２０６（図６参照）から、そのＵｓｅｒ−ＩＤに係る行の情報（サービスタイプ、予約リソース量、インタフェース−ＩＤ、フロー−ＩＤなど）を削除する（ＳＴ１２７、ＳＴ１３１）。
【０２２７】
その後、前ホップが端末１Ｂであった場合には、削除応答メッセージ中のディスティネーション側エッジ−ＩＤへ、自エッジノード２ＢのＩＤを設定した後（ＳＴ１２８、ＳＴ１２９）に、前ホップが端末１Ｂ以外であった場合には直ちに、受信した削除応答メッセージを次ホップ（コアノード３又は端末１Ａ）ヘ送信する（ＳＴ１３０、ＳＴ１３２）。
【０２２８】
なお、エッジノード２は、削除要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、削除応答メッセージが受信できないときには、削除ＮＧの削除応答メッセージを受信したときとほぼ同様な処理を行う。
【０２２９】
（Ａ−２−４−３）コアノード３の予約リソース削除動作
コアノード３での予約リソースの削除動作を図３４を用いて説明する。なお、図３４は、コアノード３としての予約リソースの削除動作を示したフローチャートである。
【０２３０】
（Ａ−２−４−３−１）削除要求受信処理
メッセージ受信待ち状態において（ＳＴ１４０）、前ホップ（削除元端末収容エッジノード２Ａや他のコアノード３）からの削除要求メッセージを受信したコアノード３の予約管理部３０１は、次ホップ（図１７（Ｃ）の場合であればエッジノード２Ｂ）ヘ、受信した削除要求メッセージを送信する（ＳＴ１４１、ＳＴ１４２）。
【０２３１】
（Ａ−２−４−３−２）削除応答受信処理
メッセージ受信待ち状態において、下流側（エッジノード２Ｂや他のコアノード３）から削除応答メッセージを受信すると（ＳＴ１４０、ＳＴ１４１）、予約管理部３０１は、削除応答メッセージの結果の内容にかかわらず、リソース管理部３０３にデータテーブルの更新処理を実行させる（ＳＴ１４３）。
【０２３２】
すなわち、リソース管理部３０３は、削除応答メッセージを受信したインタフェースと要求されたサービスタイプとに対応する、リソース管理データテーブル３０４（図１２参照）を選定し、このデータテーブル３０４中のインタフェース−ＩＤ３０４１、ソース側エッジ−ＩＤ３０４２、及び、ディスティネーション側エッジ−ＩＤ３０４３で特定できる行（レコード）の情報（予約リソース量３０４４）を上述した（９）式に従って更新する。特定できる行が存在しない場合にはなにもしない。
【０２３３】
また、リソース管理部３０３は、受信したインタフェースと要求されたサービスタイプとに対応する仮予約リソース管理データテーブル３０６（図１１参照）を選定し、上述した（１０）式に従ってその内容（仮予約リソース量）を更新する。
【０２３４】
その後、予約管理部３０１は、受信した削除応答メッセージをそのまま次ホップ（エッジノード２Ａや他のコアノード３）ヘ送信する（ＳＴ１４４〜ＳＴ１４６）。
【０２３５】
なお、コアノード３は、削除要求メッセージの送信後、タイマを起動しており、所定時間を経過しても、削除応答メッセージが受信できないときには、削除ＮＧの削除応答メッセージを受信したときとほぼ同様な処理を行う。
【０２３６】
（Ａ−２−５）ネットワークの故障検出動作
次に、ネットワークの故障の検出動作について説明する。
【０２３７】
端末１、エッジノード２、コアノード３の各故障管理部１０４、２０９、３０５は、各インタフェースの対向装置に対して、図１５で示した維持メッセージを定期的に通知する。上述した図１８が、この維持メッセージの通知の様子である。この通知に係るインタフェースは、ＶＰＮのような論理的なリンクであっても良い。
【０２３８】
維持メッセージにおける要求量及び設定量には、エッジノード２やコアノード３であれば、仮予約リソース管理データテーブル２１０や３０６、及び、リソース管理データテーブル２０８や３０４の格納内容が利用される。端末１であれば、予約したリソースに関する要求量が挿入され、設定量は空欄である。
【０２３９】
各故障管理部１０４、２０９、３０５は、アクティブなインタフェース（データ通信に供しているインタフェース）の対向装置からの維持メッセージを常に監視する。前回の維持メッセージの受信時から一定期間を越えても、維持メッセージを受信しない場合には、インタフェースの先の対向装置か、その間の物理リンクの故障と判断する。ノードの場合は、図１６に示す故障通知メッセージを生成し、通知する動作を行う。
【０２４０】
故障通知メッセージの送信元ノードＩＤや送信先ノードＩＤ以外のデータには、リソース管理データテーブル２０８や３０４の格納内容が利用される。
【０２４１】
故障と判断する他の場合は、自装置のハードウェアからの通知による場合であり、故障箇所を認識する。ノードの場合は、故障通知メッセージを生成、通知する動作を行う。このハードウェアからの通知は、物理リンクそのものの故障や、下位レイヤの通信故障通知も含む。
【０２４２】
（Ａ−２−６）故障通知メッセージの生成、通知動作
次に、故障通知メッセージの作成動作と伝播動作について説明する。
【０２４３】
各故障管理部１０４、２０９、３０５は、故障を検出した場合には、自ノードあるいは自端末の予約管理部１０２、２０１、３０１に故障を検出したインタフェースＩＤを含む故障情報を通知する（このインタフェースＩＤは論理的に付与されたものでも良い）。これを受けたノード２、３の予約管理部２０１、３０１は、以下の故障通知メッセージの生成、通知動作を行う。なお、端末１の予約管理部１０２は、通知ルートが故障により存在しないので、故障通知メッセージの生成、通知動作を実行しない。
【０２４４】
以下の説明においては、ディスティネーション方向をＤ方向、ソース方向をＳ方向と記述する。
【０２４５】
いずれかの箇所で故障が生じた場合には、「仮予約」状態や、「本予約」状態のリソース予約を削除（解除）することなどもを行う。以下、これらの処理について詳述する。
【０２４６】
（Ａ−２−６−１）エッジノード２のＳ方向インタフェースの故障認識時動作
まず、対向端末１（１Ｂ）を収容しているエッジノード２（２Ｂ）が、Ｓ方向インタフェースの故障を検出した場合について説明する。すなわち、図３５のインタフェースＡ’で故障を検出した場合について説明する。
【０２４７】
故障管理部２０９が、Ｓ方向のインタフェースの故障を検出した場合には、予約管理部２０１は、故障したインタフェースに対応するインタフェースＩＤを行の要素にもつリソース管理データテーブル２０８（図９参照）を特定し、対応した行のインタフェースＩＤと、予約管理データテーブル２０６（図６参照）より、故障通知メッセージを通知する端末１（１Ｂ）を検索し、その端末１に繋がるインタフェースから故障通知メッセージを送信する。
【０２４８】
その後、予約管理データテーブル２０６から故障通知メッセージを送信した端末１のＵｓｅｒ−ＩＤの行を全て削除する。次に、特定したリソース管理データテーブル２０８をクリアする。最後に、故障したインタフェースに対応する、仮予約リソース管理データテーブル２１０（図８参照）の仮予約量をクリアする。端末１に対する故障通知メッセージの内容は、リソース管理データテーブル２０８に対応する内容をコピーする。
【０２４９】
次に、予約元端末１（１Ａ）を収容しているエッジノード２（２Ａ）がＳ方向の対向装置である予約元端末１Ａとのインタフェースの故障を検出した場合について説明する。すなわち、図３５のインタフェースＡで故障を検出した場合について説明する。
【０２５０】
全インタフェースに対応するリソース管理データテーブル２０８から、故障検出インタフェースＩＤを含む行を検索する。故障検出インタフェースＩＤを含むリソース管理データテーブル２０８が存在する場合、その行から故障通知メッセージを作成し、リソース管理データテーブル２０８に対応するインタフェースの対向のノードに対して故障通知メッセージを送信する。
【０２５１】
また、故障検出インタフェースに係る予約管理データテーブル２０６のデータの削除処理も行う。
【０２５２】
なお、以上のような処理に代え、以下のような処理を行っても良い。
【０２５３】
故障管理部２０９がＳ方向の端末１Ａとのインタフェースの故障を検出した場合には、予約管理部２０１は、故障したインタフェースに対応する予約管理データテーブル２０６（図６参照）を特定し、そこで管理されているフローの削除通知メッセージを作成し、予約管理データテーブル２０６に記述されているインタフェースから、ネットワーク側に送信する。例えば、端末１Ａの故障を検出した場合には、予約管理部２０１は、削除要求メッセージを送信し、その端末から削除要求メッセージを受信したのと同様のテーブル処理を行う。
【０２５４】
（Ａ−２−６−２）エッジノード２のＤ方向インタフェースの故障認識時動作
まず、予約元端末１（１Ａ）を収容しているエッジノード２（２Ａ）がＤ方向インタフェースの故障を検出した場合について説明する。すなわち、図３５のインタフェースＢで故障を検出した場合について説明する。
【０２５５】
故障管理部２０９がＤ方向インタフェースの故障を検出した場合、予約管理部２０１は、故障したインタフェースに対応するリソース管理データテーブル２０８（図８参照）を特定し、このリソース管理データテーブル２０８中のインタフェースＩＤと一致するインタフェースＩＤを含むＵｓｅｒ−ＩＤの行を予約管理データテーブル（図６参照）２０６より検索し、該当する端末１に故障通知メッセージを送信する。
【０２５６】
ここで、故障通知メッセージ中のサービスタイプは、インタフェースＩＤを検出したリソース管理データテーブルに対応するサービスタイプを入れる。送信元ノードＩＤに自ノードＩＤを、送信先ノードＩＤにそのインタフェースに対応する次ホップ（端末１）のノードＩＤを入れる。その他は、検索されたリソース管理データテーブル２０８のデータを設定する。
【０２５７】
送信元ノードＩＤと送信先ノードＩＤが必要なのは、本予約プロトコルを実装しない通信ノード（ルータ）が本予約プロトコルを実装する通信ノード間に存在するときに有効となる。このときは別途、本予約プロトコルを実装する隣接ノードを検出する仕組みが必要になる。
【０２５８】
その後、予約管理データテーブル２０６から故障通知メッセージを送信した端末１（１Ａ）のＵｓｅｒ−ＩＤの行を全て削除する。次に、特定したリソース管理データテーブル２０８をクリアする。最後に、故障したインタフェースに対応する、仮予約リソース管理データテーブル２１０（図６参照）をクリアする。
【０２５９】
次に、対向端末１（１Ｂ）を収容しているエッジノード２（２Ｂ）がＤ方向インタフェースの故障（従って端末１Ｂとのインタフェースの故障）を検出した場合について説明する。すなわち、図３５のインタフェースＢ’で故障を検出した場合について説明する。
【０２６０】
故障管理部２０９がＤ方向側端末１とのインタフェースの故障を検出した場合には、予約管理部２０１は、故障したインタフェ−スに対応する予約管理データテーブル２０６を特定し、そこで管理されているフローの削除通知メッセージ（例えば結果ＯＫの削除応答メッセージを適用）を作成し、ネットワーク側に送信する。
【０２６１】
故障したインタフェースに対応する予約管理データテーブル２０６、リソース管理データテーブル２０８及び仮予約リソース管理データテーブル２１０のクリア処理も行う。
【０２６２】
なお、対向端末１Ｂを収容したエッジノード２Ｂの対向端末１Ｂとのインタフェースでの故障検出時も、予約元端末１Ａを収容したエッジノード２Ａでの上述したＤ方向側のインタフェースの故障検出時と同様な上流に向かって故障通知メッセージの送出などの処理を行うようにしても良い。
【０２６３】
（Ａ−２−６−３）コアノード３のＳ方向インタフェースの故障認識時動作
次に、コアノード３におけるＳ方向インタフェースでの故障認識時の動作を説明する。すなわち、図３５のインタフェースＣで故障を検出した場合について説明する。
【０２６４】
故障管理部３０５が故障検出したインタフェースＩＤ（Ｓ方向インタフェースのＩＤとする）を予約管理部３０１へ通知する。
【０２６５】
これを受けた予約管理部３０１は、Ｄ方向への全てのリソース管理データテーブル３０４（図１２参照）より、このインタフェースＩＤを含むリソース管理データテーブル３０４を検索し、そのリソース管理データテーブル３０４内から予約情報（行）をクリアし、その予約リソース量を仮予約リソース管理テーブル３０６（図１１参照）より減らす。その後、クリア対象を含んだ全てのリソース管理データテーブル３０６が配置されているインタフェースから、その対向ノードへ故障通知メッセージを送信する。故障通知メッセージの内容には、リソース管理データテーブルの３０４のクリアした情報に対応する内容をコピーする。
【０２６６】
（Ａ−２−６−４）コアノード３のＤ方向インタフェースの故障認識時動作
次に、コアノード３におけるＤ方向インタフェースでの故障認識時の動作を説明する。すなわち、図３５のインタフェースＤで故障を検出した場合について説明する。
【０２６７】
故障管理部３０５が故障検出したインタフェースＩＤを予約管理部３０１へ通知し、これを受けた予約管理部３０１は、このインタフェースＩＤより関連するリソース管理データテーブル３０４（図１２参照）を特定する。そして、予約管理部３０１は、このリソース管理データテーブル３０４に登録されているインタフェースＩＤに対応する全対向ノードに対して、故障通知メッセージを送信する。
【０２６８】
ここで、故障通知メッセージ中のサービスタイプは、インタフェースＩＤを検出したリソース管理データテーブルに対応するサービスタイプを入れる。送信元ノードＩＤに自ノードＩＤを、送信先ノードＩＤにそのインタフェースに対応する次ホップ（エッジノード２Ａ）のノードＩＤを入れる。その他は、検索されたリソース管理データテーブル３０４のデータを設定する。
【０２６９】
送信元ノードＩＤと送信先ノードＩＤが必要なのは、本予約プロトコルを実装しない通信ノード（ルータ）が本予約プロトコルを実装する通信ノード間に存在するときに有効となる。このときは別途、本予約プロトコルを実装する隣接ノードを検出する仕組みが必要になる。
【０２７０】
その後、特定したリソース管理データテーブル３０４や仮予約リソース管理データテーブル３０６の内容をクリアする。
【０２７１】
（Ａ−２−６−５）対向端末１Ｂの故障の認識時動作
次に、図３５のＥに示すような対向端末１Ｂの故障の認識時の動作を説明する。
【０２７２】
Ｄ側エッジノード２Ｂで対向端末１Ｂに対する維持メッセージ（Ｋｅｅｐ Ａｌｉｖｅメッセージ；ユーザ、サービスタイプ毎に行う）がタイムアウトした場合、タイムアウト発生端末１Ｂを収容するインタフェースで管理する予約管理データテーブル２０６を特定し、タイムアウトしたユーザ、サービスタイプが予約した予約量とテーブル２０６内のインタフェースＩＤを読み出し、対応する行をクリアする。
【０２７３】
次に、タイムアウトを検出したインタフェースを管理するリソース管理データテーブル２０８で、読み出したインタフェースＩＤをキーとして検索した行の予約帯域から先ほど読み出した予約帯域を減算し、この行の情報に基づき、故障通知メッセージを作成し、タイムアウトしたユーザのユーザＩＤを故障通知メッセージに設定し、キーとしたインタフェースＩＤのインタフェースから故障通知メッセージを送信する。
【０２７４】
（Ａ−２−６−６）予約元端末１Ａの故障の認識時動作
次に、図３５のＦに示すような予約元端末１Ａの故障の認識時の動作を説明する。
【０２７５】
Ｓ側エッジノード２Ａで予約元端末１Ａに対する維持メッセージ（Ｋｅｅｐ Ａｌｉｖｅメッセージ；ユーザ、サービスタイプ毎に行う）がタイムアウトした場合、タイムアウト発生端末１Ａを収容するインタフェースで管理する予約管理データテーブル２０６を特定し、タイムアウトしたユーザ、サービスタイプが予約した予約量とテーブル２０６内のインタフェースＩＤを読み出し、対応する行をクリアする。
【０２７６】
次に、読み出したインタフェースＩＤと一致するインタフェースを管理するリソース管理データテーブル２０８で、タイムアウトを検出したインタフェースＩＤをキーとして検索した行の予約帯域から先ほど読み出した予約帯域を減算し、この行の情報に基づき、故障通知メッセージを作成し、タイムアウトしたユーザのユーザＩＤを故障通知メッセージに設定し、読み出したインタフェースＩＤのインタフェースから故障通知メッセージを送信する。
【０２７７】
（Ａ−２−６−７）エッジノード２のＤ方向からの故障通知メッセージの受信動作
次に、端末１を収容しているエッジノード２がＤ方向の対向装置（コアノード３や端末１Ｂ）から故障通知メッセージを受信した場合の動作について説明する。すなわち、図３６のインタフェースＡ、Ａ’で故障通知メッセージを受信した場合の動作について説明する。
【０２７８】
この場合、故障通知メッセージにユーザＩＤが含まれている場合と、含まれていない場合とで処理が異なり、場合を分けて説明する。
【０２７９】
故障通知メッセージにユーザＩＤが含まれていない場合は、伝送路故障に相当する。この場合、故障通知メッセージを受信したインタフェースで管理するリソース管理データテーブル２０８を、通知メッセージ中のソース側エッジＩＤとディスティネーション側エッジＩＤの組をキーとしてインタフェースＩＤ（第１のインタフェースＩＤ）を検索する。検索した第１のインタフェースで管理する予約管理データテーブル２０６を、故障通知メッセージを受信したインタフェースＩＤ（第２のインタフェースＩＤ）で検索する。第２のインタフェースＩＤに係る予約管理データテーブル２０６の行にあるユーザに対して故障通知メッセージを通知し、この行をクリアする。第１のインタフェースＩＤに係るリソース管理データテーブル２０８の検索した行をクリアする。
【０２８０】
これに対して、故障通知メッセージにユーザＩＤが含まれている場合は、端末１Ｂ（アプリケーション）の故障の場合に相当する。この場合、故障通知メッセージを受信したインタフェースで管理するリソース管理データテーブル２０８を、通知メッセージ中のソース側エッジＩＤとディスティネーション側エッジＩＤの組をキーとしインタフェースＩＤ（第１のインタフェースＩＤ）を検索する。検索したインタフェースで管理する予約管理データテーブル２０６を、ユーザＩＤ、サービスタイプ、故障通知を受信したインタフェースＩＤ（第２のインタフェースＩＤ）で検索し、予約量を読み出す。そのユーザに対して、故障通知メッセージを送信後、その行をクリアする。検索された第１のインタフェースＩＤに係るリソース管理データテーブル２０８の行の予約量を、読み出した予約量で減算する。
【０２８１】
以上のような故障通知メッセージの流れは、図３９や図４１における破線矢印での流れになっている。
【０２８２】
（Ａ−２−６−８）コアノード３のＳ方向からの故障通知メッセージの受信動作次に、コアノード３がＳ方向の対向装置（他のコアノード３やエッジノード２Ａ）から故障通知メッセージを受信した場合の動作について説明する。すなわち、図３６のインタフェースＢで故障通知メッセージを受信した場合の動作について説明する。
【０２８３】
予約管理部３０１は、故障通知メッセージをＳ方向から受信した場合には、その故障通知メッセージを受信したインタフェースのインタフェースＩＤと、故障通知メッセージにおけるディスティネーション側エッジＩＤ、ソース側エッジＩＤを含む、Ｄ方向側リソース管理データテーブル３０４（図１２参照）の全てを特定する。
【０２８４】
そして、対応する行を各リソース管理データテーブル３０４内から削除し、その削除した予約リソース量を仮予約リソース管理テーブル３０６（図１１参照）より減らす。その後、クリア対象を含む全リソース管理データテーブル３０６のインタフェースに対して、故障通知メッセージを送信する。故障通知メッセージの内容には、リソース管理データテーブルの３０４のクリアした情報に対応する内容をコピーする。
【０２８５】
以上のような故障通知メッセージの流れは、図３７における点線矢印での流れになっている。
【０２８６】
（Ａ−２−６−９）コアノード３のＤ方向からの故障通知メッセージの受信動作次に、コアノード３がＤ方向の対向装置（他のコアノード３やエッジノード２Ｂ）から故障通知メッセージを受信した場合の動作について説明する。すなわち、図３６のインタフェースＣで故障通知メッセージを受信した場合の動作について説明する。
【０２８７】
予約管理部３０１が、Ｄ方向の対向装置（他のコアノード３や対向端末収容エッジノード２Ｂ）からの故障通知メッセージを受信した場合には、それを受信したインタフェースに対応するインタフェースＩＤより、それに対応するリソース管理データテーブル３０４の全てを選定する。
【０２８８】
その後、故障通知メッセージ中のソース側エッジ−ＩＤ及びディスティネーション側エッジＩＤと、リソース管理データテーブル３０４中のソース側エッジＩＤ及びディスティネーション側エッジＩＤが一致する行を検索し、一致した行のインタフェースＩＤに対応する対向装置に向けて故障通知メッセージを送信する。このとき、故障通知メッセージ中の送信元ノードＩＤは自ノードのＩＤ、送信先ノードＩＤには対向装置のＩＤを設定する。
【０２８９】
その後、一致した行の予約量の総和を求め、対応するクラスの仮予約リソース管理データテーブル３０６の仮予約量から減算し、一致した行をデータテーブル３０４から削除する。
【０２９０】
以上のような故障通知メッセージの流れは、図３７における破線矢印での流れになっている。
【０２９１】
（Ａ−２−６−１０）エッジノード２のＳ方向からの故障通知メッセージの受信動作
次に、端末１を収容しているエッジノード２がＳ方向の対向装置（コアノード３や端末１Ａ）から故障通知メッセージを受信した場合の動作について説明する。すなわち、図３６のインタフェースＤ、Ｄ’で故障通知メッセージを受信した場合の動作について説明する。
【０２９２】
この場合、故障通知メッセージにユーザＩＤが含まれている場合と、含まれていない場合とで処理が異なり、場合を分けて説明する。
【０２９３】
故障通知メッセージにユーザＩＤが含まれていない場合は、伝送路の故障に該当する。この場合、故障通知メッセージを受信したインタフェースのＩＤ（第１のインタフェースＩＤ）をキーとして、全インタフェースで管理する予約管理データテーブル２０６を検索する。検索された行にあるユーザに対して、故障通知メッセージを通知し、同じ行のインタフェースＩＤをキーとして、故障通知メッセージを受信したインタフェースで管理するリソース管理データテーブル２０８を検索する。ここで検索された行の予約量から、第１のインタフェースＩＤをキーとした上述した検索時に読み出した予約量を減算する。第１のインタフェースＩＤをキーとした上述した検索での行をクリアする。
【０２９４】
これに対して、故障通知メッセージにユーザＩＤが含まれている場合は、端末１Ａ（アプリケーション）の故障に該当する。この場合、故障通知メッセージを受信したインタフェースＩＤ（第１のインタフェースＩＤ）と通知メッセージ中のユーザＩＤをキーとして、全インタフェースで管理する予約管理データテーブル２０８を検索する。ここで、検索された行にあるユーザに対して故障通知メッセージを通知し、同じ行のインタフェースＩＤをキーとして、故障通知メッセージを受信したインタフェースで管理するリソース管理データテーブル２０８を検索する。この検索時の行の予約量から、故障通知メッセージを受信したインタフェースをキーとした検索から読み出した予約量を減算する。故障通知メッセージを受信したインタフェースをキーとした検索での行をクリアする。
【０２９５】
以上のような故障通知メッセージの流れは、図３９及び図４１における点線矢印での流れになっている。
【０２９６】
（Ａ−３）第１の実施形態の効果
上述した第１の実施形態によれば、以下の効果を奏することができる。
【０２９７】
図５〜図９、図１１及び図１１で示したデータテーブルを持ち、図１７〜図１９で示した動作シーケンスに従って、リソース予約や、予約リソースの変更や、予約リソースの削除（解除）などの処理を行うことにより、ネットワークのユーザに対し、サービスタイプ毎のリソース予約などをオンデマンドで提供することができる。
【０２９８】
ネットワークの各ノードでは、予約状態を、サービスタイプ毎に維持するため、中規模や大規模のネットワークに対しても適用することができる。
【０２９９】
ネットワークのいずれかの箇所で故障が発生したときに、故障箇所で収容していたフローのリソースを、自動的に削除することができる。
【０３００】
リソース予約の動作シーケンスの中で、ソース側エッジノードのＩＤとディスティネーション側エッジノードのＩＤを取得し、各ノードのリソース管理テーブルで管理することができる。
【０３０１】
要求量や設定量などのリソース予約に係るデータを含む維持メッセージを、隣接する装置間で授受することにより、ノード間が論理的なリンクで接続されている場合の故障や下位レイヤの通信故障を検出できる。また、このようにして検出された故障や、自装置で検出された故障を、予約リソースを特定できる情報を含む故障通知メッセージを伝播することにより、故障発生から、各部装置が検出するまでにかかる時間を短くすることができる。
【０３０２】
維持メッセージの数は、各インタフェースの片方向でたかだか１つであるため、他のトラフィックに影響を与えない。また、維持メッセージの数は、各インタフェースの片方向でたかだか１つであるため、送信間隔を短くできる。こうすることにより、故障発生から検出までにかかる時間を短縮することができる。
【０３０３】
故障検出時の各ノードの予約リソース削除方法、故障通知メッセージの転送方法、故障通知メッセージの受信時の予約リソース削除方法、故障通知メッセージの受信時の故障通知メッセージの転送方法などを規定したことにより、各種データテーブルについて、故障に関連している予約リソースのみを削除することができる。
【０３０４】
（Ｂ）他の実施形態
上記実施形態の説明においても、種々変形実施形態に言及したが、さらに、以下に例示するような変形実施形態を挙げることができる。
【０３０５】
（Ｂ−１）リソース管理データテーブル２０８、３０４でのソース側エッジ−ＩＤやディスティネーション側エッジ−ＩＤは、予約要求メッセージや予約応答メッセージの際にのみ得て、変更要求メッセージ、削除要求メッセージ、変更応答メッセージ、削除応答メッセージの授受時には当初より挿入して、新たな取得を実行しないようにしても良い。
【０３０６】
（Ｂ−２） エッジノード間でパスを設定し、このパスのＩＤを、ソース側エッジ−ＩＤとディスティネーション側エッジ−ＩＤの組情報として管理するネットワークに対しても、上述したような本発明の技術思想を適用することができる。すなわち、このパスＩＤを元に、上述した予約、変更、削除、故障検出、故障通知などの処理を実行すれば良い。これにより、例えば、ＭＰＬＳなどのラベルスイッチを適用するネットワークに対して、本発明が適用可能である。
【０３０７】
（Ｂ−３）第１の実施形態においては、各要求のフローが端末（１Ａ）であったが、エッジノード２Ａの予約管理部２０１において、任意のタイミングで、予約、変更、削除の要求を行っても良い。
【０３０８】
例えば、リソース予約機能を持たない端末に対して、予め決められた帯域をネットワーク内で予約する場合に適用できる。また、ネットワーク内で閉じて専用線の帯域予約ができる。
【０３０９】
（Ｂ−４） 上述した「予約要求」、「削除要求」、「削除要求」、「予約応答」、「削除応答」、「削除応答」の各メッセージの内容に、「方向」のデータを追加するようにしても良い。
【０３１０】
第１の実施形態では、予約要求メッセージの流れる方向のフローに対して、リソース予約を行ったが、各メッセージ中に「方向」を含めることにより、第１の実施形態で予約したのとは逆方向のフローに対しても、ネットワークフローを予約することができる。これにより、各要求のトリガーをかける場所によらず、任意の方向のフローに対して、ネットワークリソースを予約することができる。
【０３１１】
【発明の効果】
以上のように、本発明によれば、大、中規模ネットワークに対しても適用可能なネットワークリソース予約制御方法及びノードや、オンデマンドでユーザの要求を受け付けてネットワークリソースの予約を実行できるネットワークリソース予約制御方法及びノードを適用でき、そのようなネットワークリソース予約制御方法及びノードは、ネットワークの故障にも対応できる。
【図面の簡単な説明】
【図１】第１の実施形態の各種ネットワーク要素の機能的構成を示すブロック図である。
【図２】第１の実施形態のネットワーク構成を示す概略ブロック図である。
【図３】第１の実施形態のソース側端末を収容するエッジノードにおける各種テーブルの配置を示す説明図である。
【図４】第１の実施形態のディスティネーション側端末を収容するエッジノードにおける各種テーブルの配置を示す説明図である。
【図５】第１の実施形態のエッジノードの受付管理データテーブルの構成を示す説明図である。
【図６】第１の実施形態のエッジノードの予約管理データテーブルの構成を示す説明図である。
【図７】第１の実施形態のエッジノードの予約ログデータテーブルの構成を示す説明図である。
【図８】第１の実施形態のエッジノードの仮予約リソース管理データテーブルの構成を示す説明図である。
【図９】第１の実施形態のエッジノードのリソース管理データテーブルの構成を示す説明図である。
【図１０】第１の実施形態のコアノードにおける各種テーブルの配置を示す説明図である。
【図１１】第１の実施形態のコアノードの仮予約リソース管理データテーブルの構成を示す説明図である。
【図１２】第１の実施形態のコアノードのリソース管理データテーブルの構成を示す説明図である。
【図１３】第１の実施形態の各種要求メッセージのデータ部構成を示す説明図である。
【図１４】第１の実施形態の各種応答メッセージのデータ部構成を示す説明図である。
【図１５】第１の実施形態の維持メッセージのデータ部構成を示す説明図である。
【図１６】第１の実施形態の故障通知メッセージのデータ部構成を示す説明図である。
【図１７】第１の実施形態のリソース予約、変更、削除（解除）動作のメッセージの転送の様子を示す説明図である。
【図１８】第１の実施形態の維持メッセージの授受の様子を示す説明図である。
【図１９】第１の実施形態の故障通知メッセージの授受の様子を示す説明図である。
【図２０】第１の実施形態の予約管理部のリソース予約時の状態遷移図である。
【図２１】第１の実施形態の予約管理部のリソース予約時の状態遷移条件を示す説明図である。
【図２２】第１の実施形態の端末のリソース予約動作を示すフローチャートである。
【図２３】第１の実施形態のエッジノードのリソース予約動作を示すフローチャートである。
【図２４】第１の実施形態のコアノードのリソース予約動作を示すフローチャートである。
【図２５】第１の実施形態の予約管理部の予約リソース変更時の状態遷移図である。
【図２６】第１の実施形態の予約管理部の予約リソース変更時の状態遷移条件を示す説明図である。
【図２７】第１の実施形態の端末の予約リソース変更動作を示すフローチャートである。
【図２８】第１の実施形態のエッジノードの予約リソース変更動作を示すフローチャートである。
【図２９】第１の実施形態のコアノードの予約リソース変更動作を示すフローチャートである。
【図３０】第１の実施形態の予約管理部の予約リソース削除時の状態遷移図である。
【図３１】第１の実施形態の予約管理部の予約リソース削除時の状態遷移条件を示す説明図である。
【図３２】第１の実施形態の端末の予約リソース削除動作を示すフローチャートである。
【図３３】第１の実施形態のエッジノードの予約リソース削除動作を示すフローチャートである。
【図３４】第１の実施形態のコアノードの予約リソース削除動作を示すフローチャートである。
【図３５】第１の実施形態の故障検出箇所別動作の説明に供する図である。
【図３６】第１の実施形態の故障通知メッセージの受信箇所別動作の説明に供する図である。
【図３７】第１の実施形態のコアノードにおけるインタフェースと、各種データテーブルとの位置関係例を示す説明図である。
【図３８】図３７の場合における各種データテーブルの内容を示す説明図である。
【図３９】第１の実施形態の予約元端末収容エッジノードにおけるインタフェースと、各種データテーブルとの位置関係例を示す説明図である。
【図４０】図３９の場合における各種データテーブルの内容を示す説明図である。
【図４１】第１の実施形態の対向端末収容エッジノードにおけるインタフェースと、各種データテーブルとの位置関係例を示す説明図である。
【図４２】図４１の場合における各種データテーブルの内容を示す説明図である。
【符号の説明】
１、１Ａ、１Ｂ…端末、
２、２Ａ、２Ｂ…エッジノード、
３、３Ａ…コアノード、
１０１…アプリケーション部、
１０２、２０１、３０１…予約管理部、
１０３、２０２、３０２…転送管理部、
１０４、２０９、３０５…故障管理部、
２０３、３０３…リソース管理部、
２０４…受付管理部、
２０５…受付管理データテーブル、
２０６…予約管理データテーブル、
２０７…予約ログデータテーブル、
２０８、３０４…リソース管理データテーブル、
２１０、３０６…仮予約リソース管理データテーブル。
Claims (13)
- 第１の端末及び第２の端末間のデータ転送に１以上のノードが介在するネットワークに対し、少なくともリソースを予約するネットワークリソース予約制御方法において、
上記第１の端末又は第２の端末を収容しているエッジノードは、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部と、リソース予約の受付用情報を記憶する予約管理データ記憶部とを備え、
上記第１の端末又は第２の端末を収容していないコアノードは、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部とを備え、
上記第１の端末から上記第２の端末へ、リソース予約を要求する予約要求メッセージ、リソース予約量を変更する変更要求メッセージ、又は、予約リソースを削除させる削除要求メッセージを送出し、上記第２の端末から上記第１の端末へ要求に対する応答メッセージを送出し、
各ネットワーク要素に対して、リソース予約、予約変更、削除を実行させると共に、上記各ノードが、各種要求メッセージ又は各種応答メッセージの受信により、上記各データ記憶部の内容を更新する
ことを特徴とするネットワークリソース予約制御方法。 - 上記第１の端末、上記各ノード、上記第２の端末は、故障検出時に、故障検出に係るインタフェースを経路としている他のネットワーク要素に対し、故障通知メッセージを送出する故障管理部を有することを特徴とする請求項１に記載のネットワークリソース予約制御方法。
- 上記各ノードの故障管理部は、故障検出したインタフェース及び上記各データ記憶部の内容に基づき、上記故障通知メッセージを送出するネットワーク要素を認識することを特徴とする請求項２に記載のネットワークリソース予約制御方法。
- 上記各ノードの故障管理部は、他のネットワーク要素から、上記故障通知メッセージを受信したときに、受信した故障通知メッセージの内容、受信したインタフェース並びに上記各データ記憶部の内容に基づき、故障通知メッセージをさらに転送するネットワーク要素を認識して故障通知メッセージを転送することを特徴とする請求項２又は３に記載のネットワークリソース予約制御方法。
- 上記第１の端末、上記各ノード、上記第２の端末は、隣接ネットワーク要素との間で、上記リソース管理データ記憶部の記憶内容に基づいて、作成した維持メッセージを授受し合い、維持メッセージの受信異常に応じて、リンクの故障を検出することを特徴とする請求項２〜４のいずれかに記載のネットワークリソース予約制御方法。
- 上記各ノードは、上記故障通知メッセージの生成送出時や、故障通知メッセージの転送処理時に、上記各データ記憶部の故障に係る経路の情報をクリアすることを特徴とする請求項２〜５のいずれかに記載のネットワークリソース予約制御方法。
- 第１の端末及び第２の端末間のデータ転送に１以上のノードが介在するネットワークにおける、上記第１の端末又は上記第２の端末を収容したノードにおいて、
転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部と、リソース予約の受付用情報を記憶する予約管理データ記憶部とを備え、
上記第１の端末から上記第２の端末への、リソース予約を要求する予約要求メッセージ、リソース予約量を変更する変更要求メッセージ、又は、予約リソースを削除させる削除要求メッセージを転送し、上記第２の端末から上記第１の端末への要求に対する応答メッセージを転送し、
リソース予約、予約変更、削除を実行すると共に、各種要求メッセージ又は各種応答メッセージの受信により、上記各データ記憶部の内容を更新する
ことを特徴とするノード。 - 第１の端末及び第２の端末間のデータ転送に１以上のノードが介在するネットワークにおける、上記第１の端末又は上記第２の端末を収容したノードにおいて、
転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、それに応じたリソース予約が可能な設定量とその時点までの予約総量とを対応付けて記憶する仮予約データ管理データ記憶部と、転送データのサービスタイプと当該ノードからの転送データの出力側インタフェースとの組合せ毎に、各フローについての入力側インタフェースと予約量とを少なくとも対応付けて記憶するリソース管理データ記憶部とを備え、
上記第１の端末から上記第２の端末への、リソース予約を要求する予約要求メッセージ、リソース予約量を変更する変更要求メッセージ、又は、予約リソースを削除させる削除要求メッセージを転送し、上記第２の端末から上記第１の端末への要求に対する応答メッセージを転送し、
リソース予約、予約変更、削除を実行すると共に、各種要求メッセージ又は各種応答メッセージの受信により、上記各データ記憶部の内容を更新する
ことを特徴とするノード。 - 故障検出時に、故障検出に係るインタフェースを経路としている他のネットワーク要素に対し、故障通知メッセージを送出する故障管理部を有することを特徴とする請求項７又は８に記載のノード。
- 上記故障管理部は、故障検出したインタフェース及び上記各データ記憶部の内容に基づき、上記故障通知メッセージを送出するネットワーク要素を認識することを特徴とする請求項９に記載のネットワークリソース予約制御方法。
- 上記故障管理部は、他のネットワーク要素から、上記故障通知メッセージを受信したときに、受信した故障通知メッセージの内容、受信したインタフェース並びに上記各データ記憶部の内容に基づき、故障通知メッセージをさらに転送するネットワーク要素を認識して故障通知メッセージを転送することを特徴とする請求項９又は１０に記載のノード。
- 隣接するネットワーク要素との間で、上記リソース管理データ記憶部の記憶内容に基づいて、作成した維持メッセージを授受し合い、維持メッセージの受信異常に応じて、リンクの故障を検出することを特徴とする請求項９〜１１のいずれかに記載のノード。
- 上記故障通知メッセージの生成送出時や、故障通知メッセージの転送処理時に、上記各データ記憶部の故障に係る経路の情報をクリアすることを特徴とする請求項９〜１２のいずれかに記載のノード。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001307905A JP3871538B2 (ja) | 2001-10-03 | 2001-10-03 | ネットワークリソース予約制御方法及びノード |
| US09/983,245 US20020059432A1 (en) | 2000-10-26 | 2001-10-23 | Integrated service network system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001307905A JP3871538B2 (ja) | 2001-10-03 | 2001-10-03 | ネットワークリソース予約制御方法及びノード |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003115871A JP2003115871A (ja) | 2003-04-18 |
| JP3871538B2 true JP3871538B2 (ja) | 2007-01-24 |
Family
ID=19127289
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001307905A Expired - Fee Related JP3871538B2 (ja) | 2000-10-26 | 2001-10-03 | ネットワークリソース予約制御方法及びノード |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3871538B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1277375C (zh) | 2003-07-31 | 2006-09-27 | 华为技术有限公司 | 一种光网络中永久连接和交换连接之间的转换方法 |
| US20060218353A1 (en) * | 2005-03-11 | 2006-09-28 | Interdigital Technology Corporation | Method and apparatus for implementing path-based traffic stream admission control in a wireless mesh network |
| JP2008060995A (ja) * | 2006-08-31 | 2008-03-13 | Nippon Telegr & Teleph Corp <Ntt> | Ｍｐｌｓネットワーク転送制御方法及びシステム |
-
2001
- 2001-10-03 JP JP2001307905A patent/JP3871538B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003115871A (ja) | 2003-04-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US4825206A (en) | Automatic feedback of network topology data | |
| US6801534B1 (en) | Management of path routing in packet communications networks | |
| Ramaswami et al. | Distributed network control for optical networks | |
| EP0575279B1 (en) | Distributed management communications network | |
| JP3701476B2 (ja) | データ通信方法 | |
| US5590118A (en) | Method for rerouting a data stream | |
| JP3159927B2 (ja) | 網動作方法、要求経路方法並びにルーティング及び承認制御する方法 | |
| JPH10173681A (ja) | 代替ルート決定方法およびネットワーク用ノード | |
| JP2505063B2 (ja) | 仮想チェインを確立し管理する方法およびシステム | |
| JPS61284144A (ja) | ネツトワ−クのトポロジ・デ−タベ−ス維持方法 | |
| US6781952B2 (en) | Establishment of designated S-PVC connection in PNNI operation ATM switching apparatus network | |
| WO1995009501A1 (fr) | Systeme de gestion d'element de reseau | |
| JP3871538B2 (ja) | ネットワークリソース予約制御方法及びノード | |
| JP3036524B2 (ja) | Ｖｐプロテクションシステム及び方法 | |
| JP4507400B2 (ja) | ネットワークリソース予約方法及びノード装置 | |
| JPH11308231A (ja) | 通信リソース予約方法 | |
| JP3049301B2 (ja) | コネクション型通信網での障害回復方式および輻輳回復方式 | |
| JPH11275095A (ja) | 非同期転送モード通信ネットワーク管理装置 | |
| JP3613325B2 (ja) | ルータ及び該ルータを用いたネットワーク及びネットワーク制御方法 | |
| EP1193908A1 (en) | Atm exchange and atm high reliability control method | |
| EP0699006A1 (en) | Method for rerouting a data stream | |
| JP2000031962A (ja) | Ｉｓｄｎバックアップチャネルの有効利用方式 | |
| JP2723027B2 (ja) | Ｔｃａｐの試験方法 | |
| JPH11252106A (ja) | コネクション経路変更装置とその変更方法及びノードとコネクション経路変更システム | |
| CN116248160A (zh) | 一种基于通信节点的网络快速通道构建方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040921 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060615 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060704 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060831 |
|
| 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: 20061017 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061017 |
|
| 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: 20101027 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111027 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111027 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121027 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121027 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131027 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |