(57)【特許請求の範囲】
【請求項１】
第１の端末装置及び第２の端末装置間のデータ転送に１以上のノード装置が介在するネットワークに対し、リソースを予約するネットワークリソース予約方法において、
上記第１の端末装置は、転送データの送信元及び送信先の識別情報、転送データのサービス種別、及び、必要なリソース量を含んでいる、リソース予約を要求する要求メッセージを送出し、
上記各ノード装置は、出力インターフェース毎に、しかも、サービス種別毎に、許容し得るリソース量を表す設定帯域と、現時点で割り当てている仮予約及び本予約のリソース量とを管理しており、要求メッセージを受信したときに、当該要求メッセージに含まれている送信先の識別情報に基づいて出力インターフェースを特定し、この特定した出力インターフェースと、受信した要求メッセージに含まれているサービス種別とに基づいて判定に用いる管理情報を定めて、リソースを予約できるか否かを判定し、予約できるときに、受信した要求メッセージに含まれているリソース量だけ仮予約のリソース量を増大させて、次の装置に要求メッセージを送信し（以下、要求メッセージの流れに従って、次の装置又は前の装置と呼ぶ）、リソースを予約できないときに、前の装置に、転送データの送信元及び送信先の識別情報、転送データのサービス種別、必要なリソース量、及び、予約否を含んでいる応答メッセージを送信し、
上記第２の端末装置は、要求メッセージを受信したときに、データ通信に応じられるか否かを判定し、データ通信に応じられるときに、前の装置に、転送データの送信元及び送信先の識別情報、転送データのサービス種別、必要なリソース量、及び、予約可を含んでいる応答メッセージを送信し、データ通信に応じられないときに、前の装置に、転送データの送信元及び送信先の識別情報、転送データのサービス種別、必要なリソース量、及び、予約否を含んでいる応答メッセージを送信し、
上記各ノード装置は、応答メッセージを受信したときに、当該応答メッセージに含まれている送信先の識別情報に基づいて出力インターフェースを特定し、この特定したインターフェースと、受信した応答メッセージに含まれているサービス種別とに基づいて更新対象の上記管理情報を定め、受信した応答メッセージが予約可のときに、定めた管理情報の本予約のリソース量を受信した応答メッセージに含まれているリソース量だけ増大させると共に前の装置に予約可の応答メッセージを送信し、受信した応答メッセージが予約否のときに、定めた管理情報の仮予約のリソース量を受信した応答メッセージに含まれているリソース量だけ減少させると共に前の装置に予約否の応答メッセージを送信し、
上記第１の端末装置は、受信した応答メッセージによりリソースを予約できたか否かを認識する
ことを特徴とするネットワークリソース予約方法。
【請求項２】
上記第１の端末装置は、転送データの送信元及び送信先の識別情報、転送データのサービス種別、及び、必要なリソース量を含んでいる、リソース予約の解除を要求する解除要求メッセージを送出し、
上記各ノード装置は、解除要求メッセージを受信したときに、当該解除要求メッセージに含まれている送信先の識別情報に基づいて出力インターフェースを特定し、この特定したインターフェースと、受信した解除要求メッセージに含まれているサービス種別とに基づいて更新対象の上記管理情報を定め、定めた管理情報の本予約のリソース量を受信した解除要求メッセージに含まれているリソース量だけ減少させると共に、定めた管理情報の仮予約のリソース量を受信した要求メッセージに含まれているリソース量だけ減少させて次の装置に解除要求メッセージを送信し、
上記第２の端末装置は、解除要求メッセージを受信したときに、データ通信状態を解除して前の装置に、転送データの送信元及び送信先の識別情報、転送データのサービス種別、必要なリソース量、及び、解除可を含んでいる解除応答メッセージを送信し、
上記各ノード装置は、解除応答メッセージを受信したときに、当該解除応答メッセージに含まれている送信先の識別情報に基づいて出力インターフェースを特定し、この特定したインターフェースと、受信した解除応答メッセージに含まれているサービス種別とに基づいて更新対象の上記管理情報を定め、受信した解除応答メッセージが解除可のときに、前の装置に解除可の解除応答メッセージを送信し、受信した解除応答メッセージが解除否のときに、定めた管理情報の仮予約のリソース量を受信した解除応答メッセージに含まれているリソース量だけ増加させると共に、定めた管理情報の本予約のリソース量を受信した解除応答メッセージに含まれているリソース量だけ増大させて前の装置に解除否の解除応答メッセージを送信し、
上記第１の端末装置は、受信した解除応答メッセージによりリソースを解除できたかを認識する
ことを特徴とする請求項１に記載のネットワークリソース予約方法。
【請求項３】
上記各ノード装置は、次の装置に予約の要求メッセージを送信してから、所定時間経過しても、対応する応答メッセージを受信できないときに、前の装置からの予約の要求メッセージの受信時に定めた管理情報の仮予約のリソース量を、受信した要求メッセージに含まれているリソース量だけ減少させると共に前の装置に予約否の応答メッセージを送信し、次の装置に解除要求メッセージを送信してから、所定時間経過しても、対応する解除応答メッセージを受信できないときに、前の装置からの解除要求メッセージの受信時に定めた管理情報の仮予約のリソース量を受信した要求メッセージに含まれているリソース量だけ増加させると共に、定めた管理情報の本予約のリソース量を受信した解除要求メッセージに含まれているリソース量だけ増大させて前の装置に解除否の解除応答メッセージを送信することを特徴とする請求項２に記載のネットワークリソース予約方法。
【請求項４】
第１の端末装置及び第２の端末装置間のデータ転送に介在するノード装置において、
出力インターフェース毎に、しかも、サービス種別毎に、許容し得るリソース量を表す設定帯域と、現時点で割り当てている仮予約及び本予約のリソース量とを管理しており、転送データの送信元及び送信先の識別情報、転送データのサービス種別、及び、必要なリソース量を含んでいる、リソース予約を要求する要求メッセージを受信したときに、当該要求メッセージに含まれている送信先の識別情報に基づいて出力インターフェースを特定し、この特定した出力インターフェースと、受信した要求メッセージに含まれているサービス種別とに基づいて判定に用いる管理情報を定めて、リソースを予約できるか否かを判定し、予約できるときに、受信した要求メッセージに含まれているリソース量だけ仮予約のリソース量を増大させる更新を行って、次の装置に要求メッセージを送信し（以下、要求メッセージの流れに従って、次の装置又は前の装置と呼ぶ）、リソースを予約できないときに、前の装置に、転送データの送信元及び送信先の識別情報、転送データのサービス種別、必要なリソース量、及び、予約否を含んでいる応答メッセージを送信する要求メッセージ処理手段と、
応答メッセージを受信したときに、当該応答メッセージに含まれている送信先の識別情報に基づいて出力インターフェースを特定し、この特定したインターフェースと、受信した応答メッセージに含まれているサービス種別とに基づいて更新対象の上記管理情報を定め、受信した応答メッセージが予約可のときに、定めた管理情報の本予約のリソース量を受信した応答メッセージに含まれているリソース量だけ増大させると共に前の装置に予約可の応答メッセージを送信し、受信した応答メッセージが予約否のときに、定めた管理情報の仮予約のリソース量を受信した応答メッセージに含まれているリソース量だけ減少させると共に前の装置に予約否の応答メッセージを送信する応答メッセージ処理手段と
を有することを特徴とするノード装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークリソース予約方法及びノード装置に関する。
【０００２】
【従来の技術】
従来より、ＩＰネットワーク上で、音声、画像などのデータストリームを転送する場合に、その通信サービスのアプリケーションがネットワークリソースを予約するための一定の方式を適用していた。このような予約方式として、ＲＳＶＰ（Resource Resevation Protcol）方式や、Diffserv（Differentiated Service）をサポートしたネットワークにおいてＣＯＰＳ（Common Open Policy Service）を用いたＳＬＡ（Service Level Agreement）を締結する方式の勧告化が進められている。
【０００３】
例えば、ＲＳＶＰ方式では、インターネット上で予約（占有）しているリソースを、その全てのルータがデータストリーム単位で管理している。またDiffservを用いる方法で、データストリームをネットワークに流すためにリソースを予約するのは、従来の専用線を用いた予約方法のイメージに近い。
【０００４】
【発明が解決しようとする課題】
しかしながら、上記従来例のネットワークリソースの予約方式によれば、以下のような課題があった。
【０００５】
ＲＳＶＰ方式では、ネットワークが大規模となり、そこを流れるデータストリームの数が莫大なものになったときに、各ルータでリソースを管理するための負荷が大きくなる。このため、一般にはＲＳＶＰ方式はあまり利用されていない。
【０００６】
またDiffservを用いる方法で、データストリームをネットワークに流すためにリソースを予約する方式は、上述したように、従来の専用線に近いイメージになるため、ネットワークリソースを有効に利用できないか、あるいは、あるアプリケーションが予約したリソースを通信中に確保し続けることができない場合も生じ得る。
【０００７】
そのため、ネットワーク要素でのリソース管理負荷が小さく、ネットワークリソースを有効に利用できる、予約リソースを通信中に確保し続けることが可能なネットワークリソース予約方法及びノード装置が求められている。
【０００８】
【課題を解決するための手段】
かかる課題を解決するため、第１の本発明は、第１の端末装置及び第２の端末装置間のデータ転送に１以上のノード装置が介在するネットワークに対し、リソースを予約するネットワークリソース予約方法において、（１）上記第１の端末装置は、転送データの送信元及び送信先の識別情報、転送データのサービス種別、及び、必要なリソース量を含んでいる、リソース予約を要求する要求メッセージを送出し、（２）上記各ノード装置は、出力インターフェース毎に、しかも、サービス種別毎に、許容し得るリソース量を表す設定帯域と、現時点で割り当てている仮予約及び本予約のリソース量とを管理しており、要求メッセージを受信したときに、当該要求メッセージに含まれている送信先の識別情報に基づいて出力インターフェースを特定し、この特定した出力インターフェースと、受信した要求メッセージに含まれているサービス種別とに基づいて判定に用いる管理情報を定めて、リソースを予約できるか否かを判定し、予約できるときに、受信した要求メッセージに含まれているリソース量だけ仮予約のリソース量を増大させて、次の装置に要求メッセージを送信し（以下、要求メッセージの流れに従って、次の装置又は前の装置と呼ぶ）、リソースを予約できないときに、前の装置に、転送データの送信元及び送信先の識別情報、転送データのサービス種別、必要なリソース量、及び、予約否を含んでいる応答メッセージを送信し、（３）上記第２の端末装置は、要求メッセージを受信したときに、データ通信に応じられるか否かを判定し、データ通信に応じられるときに、前の装置に、転送データの送信元及び送信先の識別情報、転送データのサービス種別、必要なリソース量、及び、予約可を含んでいる応答メッセージを送信し、データ通信に応じられないときに、前の装置に、転送データの送信元及び送信先の識別情報、転送データのサービス種別、必要なリソース量、及び、予約否を含んでいる応答メッセージを送信し、（４）上記各ノード装置は、応答メッセージを受信したときに、当該応答メッセージに含まれている送信先の識別情報に基づいて出力インターフェースを特定し、この特定したインターフェースと、受信した応答メッセージに含まれているサービス種別とに基づいて更新対象の上記管理情報を定め、受信した応答メッセージが予約可のときに、定めた管理情報の本予約のリソース量を受信した応答メッセージに含まれているリソース量だけ増大させると共に前の装置に予約可の応答メッセージを送信し、受信した応答メッセージが予約否のときに、定めた管理情報の仮予約のリソース量を受信した応答メッセージに含まれているリソース量だけ減少させると共に前の装置に予約否の応答メッセージを送信し、（５）上記第１の端末装置は、受信した応答メッセージによりリソースを予約できたか否かを認識することを特徴とする。
【０００９】
また、第２の本発明は、第１の端末装置及び第２の端末装置間のデータ転送に介在するノード装置において、（１）出力インターフェース毎に、しかも、サービス種別毎に、許容し得るリソース量を表す設定帯域と、現時点で割り当てている仮予約及び本予約のリソース量とを管理しており、転送データの送信元及び送信先の識別情報、転送データのサービス種別、及び、必要なリソース量を含んでいる、リソース予約を要求する要求メッセージを受信したときに、当該要求メッセージに含まれている送信先の識別情報に基づいて出力インターフェースを特定し、この特定した出力インターフェースと、受信した要求メッセージに含まれているサービス種別とに基づいて判定に用いる管理情報を定めて、リソースを予約できるか否かを判定し、予約できるときに、受信した要求メッセージに含まれているリソース量だけ仮予約のリソース量を増大させる更新を行って、次の装置に要求メッセージを送信し（以下、要求メッセージの流れに従って、次の装置又は前の装置と呼ぶ）、リソースを予約できないときに、前の装置に、転送データの送信元及び送信先の識別情報、転送データのサービス種別、必要なリソース量、及び、予約否を含んでいる応答メッセージを送信する要求メッセージ処理手段と、（２）応答メッセージを受信したときに、当該応答メッセージに含まれている送信先の識別情報に基づいて出力インターフェースを特定し、この特定したインターフェースと、受信した応答メッセージに含まれているサービス種別とに基づいて更新対象の上記管理情報を定め、受信した応答メッセージが予約可のときに、定めた管理情報の本予約のリソース量を受信した応答メッセージに含まれているリソース量だけ増大させると共に前の装置に予約可の応答メッセージを送信し、受信した応答メッセージが予約否のときに、定めた管理情報の仮予約のリソース量を受信した応答メッセージに含まれているリソース量だけ減少させると共に前の装置に予約否の応答メッセージを送信する応答メッセージ処理手段とを有することを特徴とする。
【００１０】
【発明の実施の形態】
（Ａ）第１の実施形態
以下、本発明によるネットワークリソース予約方法及びノード装置を、Diffserv機能をサポートするネットワークに適用した第１の実施形態を、図面を参照しながら詳述する。
【００１１】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態に係るネットワークシステム１００を構成する装置を示すブロック図である。
【００１２】
第１の実施形態のネットワークシステム１００は、ネットワークの終端要素である端末装置１１０と、端末装置１１０を収容しているノード装置（以下、エッジノード装置と呼ぶ）１２０と、エッジノード装置１２０間の通信に介在するノード装置（以下、コアノード装置と呼ぶ）１３０とを有している。なお、ネットワークの接続形態は、複数のノード装置１２０及び１３０をメッシュ状、リング状、バス状などのいずれで接続したものでも良い。また、同一ノード装置がある通信においてはエッジノード装置１２０となり、他の通信においてはコアノード装置１３０となることもあり得る。例えば、ノード装置１２０、１３０はルータなどが該当するものである。
【００１３】
端末装置１１０は、具体的な通信サービスを提供する各種のアプリケーション部１１１、それに必要なネットワークリソースを予約処理する予約管理部１１２、通信サービスで生じたデータをエッジノード装置１２０に転送する転送管理部１１９を有している。このユーザ端末装置１１０には、複数の通信サービスを任意に実装できるが、以下、一つの通信サービスを取り上げて説明する。
【００１４】
エッジノード装置１２０は、ネットワークリソースの予約管理部１２２、リソースの状態などを管理するリソース管理部１２３、リソース管理部１２３が管理に利用するリソース管理データテーブル１２４、端末装置１１０からの通信要求に対する受付管理を行う受付管理部１２５、受付管理部１２５が受付管理で利用する受付管理データテーブル１２６、及び、データ転送を管理する転送管理部１２９を有している。
【００１５】
コアノード装置１３０は、予約管理部１３２、リソース管理部１３３、リソース管理データテーブル１３４、及び、転送管理部１３９を有しており、エッジノード装置１２０の構成要素と同一名称が付与されている構成要素は、同様な機能を行うものである。
【００１６】
予約管理部１２２、１３２は、データの転送経路上で隣接すべき装置１１０、１２０、１３０の予約管理部１１２、１２２、１３２と、ＩＣＭＰ(Internet Control Message Protocol)、ＴＣＰ(Transmission Control Protocol)その他のプロトコルに従って所定のメッセージを授受し合い、協働して、ネットワークリソースの予約制御や開放制御を行うものである。
【００１７】
予約管理部１２２、１３２は、「ＳＴＡＲＴ」、「予約待ち」、「仮予約中」、「予約ＯＫ」、「予約ＮＧ」の予約状態を持ち、これら状態間の遷移は図２及び図３に示す通りである。
【００１８】
図２に示すように、「ＳＴＡＲＴ」状態からは「予約待ち」状態への遷移のみが可能であり、「予約待ち」状態からは自状態又は「仮予約中」状態への遷移のみが可能であり、「仮予約中」状態からは「予約ＯＫ」状態又は「予約ＮＧ」状態への遷移が可能であり、「予約ＮＧ」状態からは「予約待ち」状態への遷移のみが可能であり、「予約ＯＫ」状態からは「予約待ち」状態又は「予約ＮＧ」状態への遷移が可能である。
【００１９】
図３において、縦方向に記述した５個の状態は遷移前の状態を示し、横方向に記述した５個の状態は遷移後の状態を示し、その交点の欄には、その遷移条件を記述している。なお、図３における「ＭＳＧ」は、メッセージを表している。
【００２０】
状態遷移の具体的内容については、後述する動作説明で明らかにする。
【００２１】
リソース管理部１２３、１３３は、リソース管理データテーブル１２４、１３４を用いながら、リソースを管理するものである。リソース管理部１２３、１３３が管理するリソースは、例えば、自ノード（自ノードのデータ出力構成などを含んで良い）から、データ転送方向で隣接する装置１１０、１２０、１３０までのリソースである。
【００２２】
図４は、リソース管理データテーブル１２４、１３４の構成を示す説明図である。リソース管理データテーブル１２４、１３４は、当該ノード１２０、１３０が提供する通信サービスの種類「サービス種別（ＳＴ）」毎に設けられている。リソース管理データテーブル１２４、１３４は、サービス種別（ＳＴ）のそれぞれに対応させ、出力インターフェースを識別するための複数の「インターフェース−ＩＤ（ＯＬＩＤ）」、仮予約中のリソース量を表す「仮予約リソース量（ＰｉｎｇＷ）」、本予約（予約確定）後の「予約リソース量（ＰｅｄＷ）」、及び、ネットワーク管理者が該当インターフェースに割り当てたリソース量を表す「設定帯域（ＳＷ）」を有する。
【００２３】
エッジノード装置１２０にのみ設けられている受付管理部１２５は、受付管理データテーブル１２６を用いて、各端末装置１１０のトラフィックを管理するなどの受付管理を行うものである。なお、予約元（データ転送元）のエッジノード装置１２０の受付管理部１２５が有効に機能し、データ転送先側のエッジノード装置１２０の受付管理部１２５は、リソース予約面に関係する受付管理は実行しない。
【００２４】
図５は、受付管理データテーブル１２６の構成を示す説明図である。受付管理データテーブル１２６は、アプリケーションの利用者を識別するための複数の識別子「Ｕｓｅｒ−ＩＤ（ＵＩＤ）」のそれぞれに対応させ、アプリケーションが予約した「予約リソース量（ＰｅｄＷ）」、アプリケーションによる「予約サービス種別（ＳＴ）」を有する。
【００２５】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態のネットワークシステム１００でのリソース予約動作を説明する。
【００２６】
（Ａ−２−１）動作の基本的な技術思想
まず、第１の実施形態のネットワークシステム１００でのリソース予約動作の基本的な技術思想を図６を用いて説明する。なお、図６は、データ転送元（リソース予約元）の端末装置１１０Ａから、データ転送先の端末装置１１０Ｂへのデータ転送に、エッジノード装置１２０Ａ、コアノード装置１３０、エッジノード装置１２０Ｂがこの順で介在する（中継する）場合を示している。また、以下の説明では、データの転送元側を上流、データの転送先側を下流と表現する。
【００２７】
リソース予約元の端末装置１１０Ａは、収容されているエッジノード装置１２０Ａに必要リソース量（予約リソース量）やデータの転送先などの情報を通知してリソース予約を行う。
【００２８】
データ転送に介在すべき（中継処理を行う）各ノード装置１２０Ａ、１３０、１２０Ｂにおいては、上流の装置からのリソース予約の要求に対し、受け入れられるか否かを判別し、受け入れられる場合に、自ノードを仮予約状態にした後、下流の装置にリソース予約を行う。
【００２９】
このように各ノード装置１２０Ａ、１３０、１２０Ｂが、リソース予約が可能な状態であれば、リソース予約の要求が順次伝搬していき、データ転送先の端末装置１１０Ｂに到達する。
【００３０】
データ転送先の端末装置１１０Ｂは、リソース予約の要求を受信し、応じられる場合には、予約応答をエッジノード装置１２０Ｂに返信する。
【００３１】
各ノード装置１２０Ｂ、１３０、１２０Ａにおいては、下流の装置からのリソース予約を受け入れられる予約応答の返信を受けると、自ノードを本予約状態にした後、上流の装置にリソース予約を受け入れられる予約応答を返信する。
【００３２】
リソース予約元の端末装置１１０Ａは、リソース予約を受け入れられる予約応答の返信を受けると、そのことを認識し、データ転送を開始することになる。
【００３３】
各ノード装置１２０Ｂ、１３０、１２０Ａ又は端末装置１１０Ｂは、上流の装置からのリソース予約の要求に対し、受け入れられない場合には、自ノードを仮予約状態にすることなく、また、下流の装置にリソース予約を行うことなく、上流の装置に、受け入れられないことを返信する。
【００３４】
各ノード装置１２０Ｂ、１３０、１２０Ａにおいては、下流の装置からのリソース予約を受け入れられない旨の返信を受けると、自ノードを仮予約状態から予約待機状態に戻し、上流の装置にリソース予約を受け入れられない旨の返信を与える。
【００３５】
リソース予約元の端末装置１１０Ａは、リソース予約を受け入れられない旨の返信により、そのことを認識し、データ転送を待機することになる。
【００３６】
なお、コアノード装置１３０がない場合や、２個以上の場合であっても、さらには、端末装置１１Ａ及び１１０Ｂが同一のエッジノード装置１２０に収容されている場合であっても、上述した技術思想に従いながら、リソース予約処理が実行される。
【００３７】
以下、各装置１１０Ａ、１１０Ｂ、１２０Ａ、１２０Ｂ、１３０でのリソース予約処理を詳細に説明する。
【００３８】
なお、以下の説明においては、上流から下流へのメッセージを、「仮予約メッセージ」と呼び、下流から上流へのメッセージを、「予約応答メッセージ」と呼ぶこととする。
【００３９】
「仮予約」メッセージのデータ部には、ＩＰアドレス＋ポート番号等による「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、アプリケーションがネットワークに対して要求するネットワークの「サービス種別」、アプリケーションが要求するネットワークの「リソース量」を含む。
【００４０】
また、「予約応答」メッセージには、ＩＰアドレス＋ポート番号等による「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、アプリケーションがネットワークに対して要求したネットワークの「サービス種別」、アプリケーションが要求したネットワークの「リソース量」、「予約の可否状態」を含む。
【００４１】
（Ａ−２−２）リソース予約元の端末装置１１０Ａの動作
まず、リソース予約元の端末装置１１０Ａでの動作を図７を用いて説明する。なお、図７は、端末装置１１０（１１０Ａ、１１０Ｂ）としての動作を示したフローチャートであり、ステップＳＴ１１〜ＳＴ１６がリソース予約元の端末装置１１０Ａの処理を示し、ステップＳＴ１３、ＳＴ１４、ＳＴ１７〜ＳＴ１９が端末装置１１０Ａに対向する端末装置１１０Ｂの動作を示している。
【００４２】
端末装置１１０Ａでは、図７に示すとおり、アプリケーション部１１１で通信サービスが起動すると、そのユーザが任意のネットワークサービスとネットワークリソースを特定して必要なパラメータを指定する（ＳＴ１１）。このユーザ指定がなければアプリケーション部１１１が自動的に所要のパラメータを決定するようにしても、さらに所定の初期値から起動条件で設定させても良い。
【００４３】
予約管理部１１２では、これら設定パラメータが通知されると、ネットワークリソースの「仮予約」メッセージを編成してエッジノード装置１２０Ａの予約管理部１２２に送信する（ＳＴ１２）。そしてエッジノード装置１２０Ａを介して確保完了を通知する「予約応答」メッセージを受信できるまで待機する（ＳＴ１３）。ステップＳＴ１２の「仮予約」メッセージの送信によって、対向する端末装置１１０Ｂに至るネットワーク全体にわたり、そのリソースの確保（予約）を端末装置１１０Ａが求めたことになる。
【００４４】
後述するエッジノード装置１２０Ａ、コアノード装置１３０、エッジノード装置１２０Ｂ、対向する端末装置１１０Ｂのそれぞれで予約が完了すると、エッジノード装置１２０Ａを介して、ＯＫ（可）を表す「予約応答」メッセージが返信される。一方、エッジノード装置１２０Ａ、コアノード装置１３０、エッジノード装置１２０Ｂ、又は、対向する端末装置１１０Ｂがリソース予約を受け入れられないときは、その装置から上流に送出され始めたＮＧ（否）を表す「予約応答」メッセージが返信される。
【００４５】
受信したメッセージが「予約応答」メッセージであることを認識した端末装置１１０Ａは（ＳＴ１４参照）、このメッセージに含まれている予約の「可否状態」を判定し（ＳＴ１５）、“ＯＫ”であれば、そのパラメータに基づくリソース条件が転送管理部１２９に、また予約完了がアプリケーション部１１１にそれぞれ通知される。
【００４６】
アプリケーション部１１１では、仮予約を承認することで予約完了、すなわち本予約を宣言し、これを転送管理部１１９に通知してデータの送信を開始させる。転送管理部１１３では、例えばアプリケーション部１１１からのストリームデータを予約管理部１１２で指定したリソース条件に基づいてエッジノード装置１２０の転送管理部１２９に転送する（ＳＴ１６）。
【００４７】
また、受信した「予約応答」メッセージの可否状態が“ＮＧ”であれば、その旨をアプリケーション部１１１に通知して、いずれの場合も再びユーザがパラメータを指定するまで待機する（ＳＴ１３）。
【００４８】
（Ａ−２−３）エッジノード装置１２０Ａ、１２０Ｂの動作
エッジノード装置１２０Ａ、１２０Ｂにおいては、図８のフローチャートに示すとおり、予約管理部１２２は、「メッセージ（ＭＳＧ）受信待ち」（ＳＴ２１）において到来したメッセージの種類によって、リソース予約処理を変更する。
【００４９】
（Ａ−２−３−１）仮予約メッセージに対する動作
予約管理部１２２が、上流の端末装置１１０Ａ又はコアノード装置１３０から、リソースの「仮予約」メッセージを受信すると（ＳＴ２２）、自ノード装置１２０Ａ、１２０Ｂのリソース管理部１２４による管理状況から、予約が可能か否かを判別する（ＳＴ２３）。
【００５０】
そして、予約が可能な場合であれば自ノード装置１２０Ａ、１２０Ｂを「仮予約中」状態に移行させてリソース管理部１２３でリソース仮予約処理を実行させ、また、下流の装置１３０、１１０Ｂに「仮予約」メッセージを送信する（ＳＴ２４、ＳＴ２５）。一方、予約が不可能な場合であれば、「可否状態」として予約ＮＧを表す予約応答メッセージを形成して上流の装置１１０Ａ、１３０に送出する（ＳＴ２６）。
【００５１】
以下、ステップＳＴ２３〜ＳＴ２６の処理を、特に、ステップＳＴ２３の処理を詳細に説明する。
【００５２】
「仮予約」メッセージを受信すると、予約管理部１２２からリソース管理部１２３に対して「仮予約」メッセージ内容に指定された「サービス種別」、「リソース量」、「ストリーム送信先ＩＤ」を通知する。これを受けたリソース管理部１２３では、転送管理部１２９から「ストリーム送信先ＩＤ」への転送ルートにすべきインターフェース番号（インターフェースＩＤ）を取得する。
【００５３】
またリソース管理データテーブル１２４の設定内容に基づいて、そのサービス種別に対して指定されたリソース量が使用可能か否かを、下記の演算式＜１＞により判定する。
【００５４】
Ｐｉｎｇ［ｉ］＋Ｒ＜ＳＷ［ｉ］  …  ＜１＞
ｉはインタフェースを特定するパラメータであって１≦ｉ≦ｎ（ｎはインタフェースの個数）であり、Ｐｉｎｇ［ｉ］はｉ番目のインタフェースでの仮予約リソース量であり、Ｒは「仮予約」メッセージで指定されたリソース量であり、ＳＷ［ｉ］はノード装置の各リンクごとに予め割り当てられているリソース量（設定帯域）である。
【００５５】
この演算式＜１＞が満たされた場合には、下記の演算式＜２＞により新たな仮予約リソース量Ｐｉｎｇ［ｉ］を計算してリソース管理データテーブル１２４を更新する。これにより仮予約リソース量Ｐｉｎｇが更新される。
Ｐｉｎｇ［ｉ］＝Ｐｉｎｇ［ｉ］＋Ｒ  …  ＜２＞
【００５６】
Ｐｉｎｇ［ｉ］＝Ｐｉｎｇ［ｉ］＋Ｒ  …  ＜２＞
さらに、仮予約が可能である旨を予約管理部１２２に通知して「仮予約」メッセージを下流の装置１３０、１１０Ｂ（次ＨＯＰ）に送信する。
【００５７】
しかし、演算式＜１＞が満たされなければ、予約不能である旨を予約管理部１２２に通知して「可否状態」をＮＧとした「予約応答」メッセージを上流の装置１１０Ａ、１３０（前ＨＯＰ）に送信する。
【００５８】
（Ａ−２−３−２）予約応答メッセージに対する動作
予約管理部１２２が、下流の端末装置１１０Ｂ又はコアノード装置１３０からのリソースの「予約応答」メッセージを受信すると（ＳＴ２２）、「予約応答」メッセージに含まれている「可否状態」を判別する（ＳＴ３３）。そして、「可否状態」がＯＫであれば、リソース管理部１２３や受付管理部１２５と協働してリソース予約処理を行った後（ＳＴ３４；これにより次の予約待ち状態になる）、「可否状態」がＯＫの「予約応答」メッセージを上流の装置１１０Ａ、１３０（前のＨＯＰ）に送信する（ＳＴ３５）。一方、「可否状態」がＮＧの「予約応答」メッセージを受信したならば、リソース管理部１２３と協働してリソースの仮予約の取消処理を行った後（ＳＴ３６；これにより予約ＮＧ状態を介して予約待ち状態になる）、「可否状態」がＮＧの「予約応答」メッセージを上流の装置１１０Ａ、１３０（前のＨＯＰ）に送信する（ＳＴ３７）。
【００５９】
リソース予約処理（ＳＴ３４）やリソース仮予約取消処理（ＳＴ３６）を詳述する。予約管理部１２２はリソース管理部１２３に、「予約応答」メッセージに含まれている「可否状態」、「ストリーム送信先ＩＤ」、「サービス種別」、「リソース量」を通知する。その通知を受けたリソース管理部１２３が、「ストリーム送信先ＩＤ」に基づいて転送管理部１２９からそのストリームの転送ルートとすべきインターフェース番号（インターフェースＩＤ“ｉ”）を特定する。
【００６０】
リソース予約処理では、そのサービス種別に対して指定された予約リソース量を下記の演算式＜３＞により更新すると共に、予約が完了した旨を予約管理部１２２に通知する。
【００６１】
Ｐｅｄ［ｉ］＝Ｐｅｄ［ｉ］＋Ｒ  …  ＜３＞
Ｐｅｄ［ｉ］はｉ（１≦ｉ≦ｎ）番目のインターフェースでの予約リソース量であり、Ｒは「予約応答」メッセージで指定されているリソース量である。
【００６２】
なお、当該エッジノード装置が、予約元の端末装置１１０Ａを収容しているエッジノード装置１２０Ａであれば、「予約応答」メッセージの「ストリーム送信元ＩＤ」、「サービス種別」「リソース量」を受付管理部１２５に通知して、受付管理データテーブル１２６のＵｓｅｒ−ＩＤに「ストリーム送信元ＩＤ」を、予約リソース量に「リソース量」を、予約サービス種別へ「サービス種別」をそれぞれ登録する。
【００６３】
さらに、予約管理部１２２は、“ＯＫ”の「予約応答」メッセージを上流の装置１１０Ａ、１３０に送信する。なお、転送管理部１２９では、更新済の受付管理データテーブル１２６に基づいて、トラフィックを監視しながら、データ転送を行い、違反したデータの廃棄、マーキングなども適宜行う。
【００６４】
一方、リソース仮予約取消処理（ＳＴ３６）では、下記の演算式＜４＞により仮予約リソース量を元に戻す。
【００６５】
Ｐｉｎｇ［ｉ］＝Ｐｉｎｇ［ｉ］−Ｒ  …  ＜４＞
Ｒは、「予約応答」メッセージで指定されているリソース量である。
【００６６】
また、予約管理部１２２では、「可否状態」が“ＮＧ”の「予約応答」メッセージを上流の装置１１０Ａ、１３０に送信する。
【００６７】
（Ａ−２−４）コアノード装置１３０の動作
コアノード装置１３０は、受付管理部１２５の動作を除けば、エッジノード装置１２０Ａ、１２０Ｂと同様な動作を行う（図８参照）。
【００６８】
（Ａ−２−５）対向する端末装置１１０Ｂの動作
上述したように、図７のステップＳＴ１３、ＳＴ１４、ＳＴ１７〜ＳＴ１９は、予約元の端末装置１１０Ａに対向する端末装置１１０Ｂの動作を示している。
【００６９】
予約元の端末装置１１０Ａに対向する端末装置１１０Ｂにおいては、予約管理部１１２は、リソースの「仮予約」メッセージのみを受信でき（ＳＴ１３、ＳＴ１４）、エッジノード装置１２０Ｂから「仮予約」メッセージを受信すると、その「ストリーム送信先ＩＤ」に基づいてアプリケーション部１１１の状態を確認し（ＳＴ１７）、データを受信可能であれば「可否状態」が“ＯＫ”の「予約応答」メッセージを形成してエッジノード装置１２０Ｂに送信し（ＳＴ１８）、一方、データを受信可能でなければ「可否状態」が“ＮＧ”の「予約応答」メッセージを形成してエッジノード装置１２０Ｂに送信する（ＳＴ１９）。
【００７０】
（Ａ−２−６）タイムアウトによる仮予約の取消
また、フローチャートの図示は省略するが、エッジノード装置１２０Ａ、１２０Ｂやコアノード装置１３０などのノード装置は、下流に対して、「仮予約」メッセージを送出したときにから、所定時間の計時を行い、所定時間を経過しても下流側から、「予約応答」メッセージを受信しないときには、仮予約状態を取り消し、また、「可否状態」が“ＮＧ”の「予約応答」メッセージを形成して上流側に送信する。
【００７１】
また、リソース予約元の端末装置１１０Ａも、同様に、エッジノード装置１２０Ａに対して、「仮予約」メッセージを送出したときにから、所定時間の計時を行い、所定時間を経過しても、エッジノード装置１２０Ａから、「予約応答」メッセージを受信しないときには、リソースの予約を失敗したと捉える。
【００７２】
（Ａ−３）第１の実施形態の効果
第１の実施形態によれば、端末装置１１０Ａのアプリケーション部１１１が予約したリソースを、エッジノード装置１２０Ａでは、「Ｕｓｅｒ−ＩＤ」によりユーザデータのフロー単位で管理しているため、アプリケーション部１１１が予約した帯域を越えてリソースを使用しようとしているかを、エッジノード装置１２０Ａで監視、制御可能である。
【００７３】
また、ネットワークで管理すべきリソースの対象を、ユーザ端末装置１１０Ａ、１１０Ｂと、エッジノード装置１２０Ａ、１２０Ｂとの間ではフロー単位、エッジノード装置１２０Ａ、１２０Ｂとコアノード装置１３０との間、コアノード装置１３０同士の間では各リンク上を流れるサービス種別単位にしているため、各ノード装置１２０Ａ、１２０Ｂ、１３０、…で管理しなければならない状態数を大幅に軽減でき、その結果、リソース予約処理での負担を小さくすることができる。
【００７４】
さらに、各ノード装置１２０Ａ、１２０Ｂ、１３０、…では、リソースが予約可能か否かを判定する場合に、すでに「予約中」の帯域を考慮して算出しているために、決して予約のミスマッチを起すことがなくなる。これにより、あるアプリケーションが予約したリソースを通信中に確保し続けることができ、また、ネットワークリソースの効率的な利用を実現できる。
【００７５】
（Ｂ）第２の実施形態
以下、本発明によるネットワークリソース予約方法及びノード装置を、Diffserv機能をサポートするネットワークに適用した第２の実施形態を、図面を参照しながら詳述する。
【００７６】
第１の実施形態は、リソースの予約処理に係る実施形態であるが、第２の実施形態は、予約されたリソースの解除処理に係るものである。第２の実施形態によるリソースの解除処理は、第１の実施形態によってリソースが予約されたものに限定されないが、第１の実施形態によってリソースが予約されていることは好ましい。
【００７７】
（Ｂ−１）第２の実施形態の構成
第２の実施形態のネットワークシステムも、その構成は、上述した第１の実施形態に係る図１で表すことができる。すなわち、端末装置１１０と、端末装置１１０を収容してネットワーク上の予約リソースを解放するエッジノード装置１２０と、エッジノード装置１２０間に介在して予約リソースを解放する１以上のコアノード装置１３０とを有する。
【００７８】
この第２の実施形態の場合、隣り合う装置間では、第１の実施形態の「仮予約」、「予約応答」のメッセージに代えて、リソースの「解除要求」、「解除応答」のメッセージを転送する。
【００７９】
また、第２の実施形態の場合、各ノード装置１２０、１３０の予約管理部１２２、１３２は、「ＳＴＡＲＴ」、「解除待ち」、「解除中」、「解除ＯＫ」、「解除ＮＧ」の状態を持ち、これら状態間の遷移は図９及び図１０に示す通りである。リソースの予約とリソースの解除という違いはあるが、これらの状態遷移は、第１の実施形態と同様である。
【００８０】
（Ｂ−２）第２の実施形態の動作
次に、第２の実施形態のネットワークシステム１００でのリソース解除動作を説明する。
【００８１】
（Ｂ−２−１）動作の基本的な技術思想
第２の実施形態のネットワークシステム１００でのリソースの解除動作も、図１１に示すように、端末装置１１０Ａからの解除要求メッセージを、エッジノード装置１２０Ａ、コアノード装置１３０、エッジノード装置１２０Ｂの順に下流に向けて転送し、対向する端末装置１１０Ｂに到達し、端末装置１１０Ｂがリソースの解除処理を実行したときに、逆に、解除応答メッセージを、エッジノード装置１２０Ｂ、コアノード装置１３０、エッジノード装置１２０Ａの順に上流に向けて転送し、全てのネットワーク要素装置でリソースの解除を実行させるものである。
【００８２】
以下、各装置１１０Ａ、１１０Ｂ、１２０Ａ、１２０Ｂ、１３０でのリソース予約解除を詳細に説明する。
【００８３】
なお、「解除要求」メッセージのデータ部には、ＩＰアドレス＋ポート番号等による「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、アプリケーションがネットワークに対して予約した「サービス種別」、アプリケーションが予約した「リソース量」を含む。
【００８４】
また、「解除応答」メッセージには、ＩＰアドレス＋ポート番号等による「ストリーム送信元ＩＤ」、「ストリーム送信先ＩＤ」、アプリケーションがネットワークに対して予約した「サービス種別」、アプリケーションが予約した「リソース量」、「解除の可否状態」を含む。
【００８５】
（Ｂ−２−２）端末装置１１０Ａ、１１０Ｂの動作
まず、端末装置１１０Ａの動作を説明する。端末装置１１０Ａのユーザがアプリケーション部１１１を終了するとき、ユーザはアプリケーション部１１１が使用していたネットワークサービス及びネットワークリソースの解除を指示し、端末装置１１０Ａは解除のためのパラメータ設定を行う（ＳＴ４１）。なお、予約していたリソースに対するパラメータをユーザが選定しない場合には、端末装置１１０Ａが自律的に行う。そして、端末装置１１０Ａは、「解除要求」メッセージをエッジノード装置１２０Ａに送信する（ＳＴ４２）。
【００８６】
端末装置１１０Ａは、その後、その応答としてエッジノード装置１２０Ａから「解除応答」メッセージが与えられるのを待ち受け（ＳＴ４３）、「解除応答」メッセージを受信すると（ＳＴ４４）、「解除応答」メッセージに含まれている解除の「可否状態」を判定する（ＳＴ４６）。この「可否状態」が“ＯＫ”であれば、その旨をアプリケーション部に通知して正常終了し、“ＮＧ”ならばその旨をアプリケーション部に通知すると共に所定のＮＧ処理を行う（ＳＴ４７）。所定のＮＧ処理は、例えば、所定時間後に「解除要求」メッセージを再送させるための処理などである。
【００８７】
一方、対向する端末装置１１０Ｂは、「解除要求」メッセージの受信待ち状態にあり（ＳＴ４４）、「解除要求」メッセージを受信すると、その「ストリーム送信先ＩＤ」に対応した通信サービスをアプリケーション部で特定し、アプリケーション部は該当サービスの終了を行うと共に、「可否状態」を“ＯＫ”とした「解除応答」メッセージを形成してエッジノード装置１２０Ｂに送信する（ＳＴ４５）。
【００８８】
（Ｂ−２−３）各ノード装置の動作
各ノード装置１２０Ａ、１３０、１２０Ｂは、同様なリソースの解除動作を行う。なお、端末装置１１０Ａを収容しているエッジノード装置１２０Ａは、他のノード装置１２０Ｂ及び１３０と同様な処理に加え、受付管理部１２５での処理をも行う。
【００８９】
以下、各ノード装置１２０Ａ、１３０、１２０Ｂの動作を図１３のフローチャートを参照しながら、説明する。
【００９０】
各ノード装置１２０Ａ、１３０、１２０Ｂは、図１３に示すように、上流の装置１１０Ａ、１２０Ａ、１３０からの「解除要求」メッセージ、又は、下流の装置１３０、１２０Ｂ、１１０Ｂからの「解除応答」メッセージを待ち受けており（ＳＴ５１）、メッセージを受信すると、いずれの種類のメッセージであるかを判別する（ＳＴ５２）。
【００９１】
上流の装置１１０Ａ、１２０Ａ、１３０から「解除要求」メッセージを受信すると、隣接する下流の装置１３０、１２０Ｂ、１１０Ｂ側への予約リソースを解除する処理を実行する（ＳＴ５３）。
【００９２】
このリソース解除処理では、予約管理部は、「解除要求」メッセージに含まれている「サービス種別」、「リソース量」、「ストリーム送信先ＩＤ」をリソース管埋部に通知し、リソース管理部は、「ストリーム送信先ＩＤ」への転送ルートとすべきインターフェース番号（インターフェースＩＤ）“ｉ”を取得する。そして、リソース管理データテーブルの設定内容に基づいて、そのインターフェース番号“ｉ”に係る仮予約されているリソース量Ｐｉｎｇ［ｉ］及び予約されているリソース量Ｐｅｄ［ｉ］を、演算式＜１４＞、＜１５＞により変更してリソース解除が完了した旨を予約管理部に通知する。なお、Ｒは「解除要求」メッセージで指定されているリソース量である。
【００９３】
Ｐｉｎｇ［ｉ］＝Ｐｉｎｇ［ｉ］−Ｒ  …  ＜１４＞
Ｐｅｄ［ｉ］＝Ｐｅｄ［ｉ］−Ｒ      …  ＜１５＞
なお、エッジノード装置１２０Ａにおいては、リソース解除処理の一環として、「解除要求」メッセージの「ストリーム送信元ＩＤ」、「サービス種別」、「リソース量」に基づき、その受付管理部が受付管理データテーブルから該当する情報を削除することも行う。
【００９４】
その後、下流の装置１３０、１２０Ｂ、１１０Ｂに、「解除要求」メッセージを送信する（ＳＴ５４）。
【００９５】
一方、各ノード装置１２０Ａ、１３０、１２０Ｂは、下流の装置１３０、１２０Ｂ、１１０Ｂからの「解除応答」メッセージを受信すると、そのメッセージに含まれている「可否状態」を判定する（ＳＴ５５）。
【００９６】
この「可否状態」が“ＯＫ”であれば、「可否状態」が“ＯＫ”の「解除応答」メッセージを上流の装置１１０Ａ、１２０Ａ、１３０に送信する（ＳＴ５６）。これに対して、“ＮＧ”ならば所定のＮＧ処理をした後（ＳＴ５７）、「可否状態」が“ＮＧ”の「解除応答」メッセージを上流の装置１１０Ａ、１２０Ａ、１３０に送信する（ＳＴ５６）。
【００９７】
例えば、ＮＧ処理は、「解除要求」メッセージに応じて解除したリソースを復帰させる処理である。
【００９８】
図示は省略しているが、各ノード装置１２０Ａ、１３０、１２０Ｂは、下流の装置１３０、１２０Ｂ、１１０Ｂに「解除要求」メッセージを送信してから所定時間の計時を行っており、その所定時間内に「解除応答」メッセージを受信できないときに、自装置で所定のＮＧ処理をした後、「可否状態」が“ＮＧ”の「解除応答」メッセージを上流の装置１１０Ａ、１２０Ａ、１３０に送信する。
【００９９】
（Ｂ−３）第２の実施形態の効果
リソースの予約、リソースの予約解除という相違はあるが、第２の実施形態によっても、予約のミスマッチ防止を除けば、第１の実施形態と同様な効果を奏することができる。
【０１００】
すなわち、端末装置１１０Ａのアプリケーション部１１１が予約したリソースを、エッジノード装置１２０Ａでは、「Ｕｓｅｒ−ＩＤ」によりデータのフロー単位で管理しているため、アプリケーション部１１１が予約した帯域を越えてリソースを使用しようとしているかを、エッジノード装置１２０Ａで監視、制御可能である。また、ネットワークで管理すべきリソースの対象を、ユーザ端末装置１１０Ａ、１１０Ｂと、エッジノード装置１２０Ａ、１２０Ｂとの間ではフロー単位、エッジノード装置１２０Ａ、１２０Ｂとコアノード装置１３０との間、コアノード装置１３０同士の間では各リンク上を流れるサービス種別単位にしているため、各ノード装置１２０Ａ、１２０Ｂ、１３０、…で管理しなければならない状態数を大幅に軽減でき、その結果、リソース予約の解除処理での負担を小さくすることができる。
【０１０１】
（Ｃ）他の実施形態
上記各実施形態では、ユーザデータを一方向に送信する場合を一例としたが、双方向に送受信する場合であっても良く、また、マルチキャストの場合であっても良い。双方向の場合においては、例えば、予約可能かの判定時に逆方向での判定をも行うようにしても良く、対向する端末装置が「仮予約」メッセージを受信したときに、「予約完了」メッセージを送出するだけでなく、逆方向への「仮予約」メッセージを送出するようにしても良い。マルチキャストの場合であれば、例えば、各ノード装置において、「仮予約」メッセージを適宜分岐させ、また、「予約完了」メッセージを適宜統合することを要する。
【０１０２】
また、本発明が適用可能なネットワークも限定されるものではなく、インターネット網だけでなく、ローカルエリアネットワークなどでも良い。
【０１０３】
【発明の効果】
以上のように、本発明によれば、ネットワーク要素でのリソース管理負荷が小さく、ネットワークリソースを有効に利用できる、予約リソースを通信中に確保し続けることが可能なネットワークリソース予約方法及びノード装置を実現できる。
【図面の簡単な説明】
【図１】第１の実施形態のシステム構成を示すブロック図である。
【図２】第１の実施形態の各ノード装置の遷移状態の一例を示す説明図である。
【図３】第１の実施形態の各ノード装置の遷移条件の一例を示す説明図である。
【図４】第１の実施形態のリソース管理データテーブルの一例を示す説明図である。
【図５】第１の実施形態の受付管理データテーブルの一例を示す説明図である。
【図６】第１の実施形態でのリソース予約動作の概念の説明図である。
【図７】第１の実施形態の端末装置でのリソース予約動作を示すフローチャートである。
【図８】第１の実施形態のノード装置でのリソース予約動作を示すフローチャートである。
【図９】第２の実施形態の各ノード装置の遷移状態の一例を示す説明図である。
【図１０】第２の実施形態の各ノード装置の遷移条件の一例を示す説明図である。
【図１１】第２の実施形態での予約リソースの解除動作の概念の説明図である。
【図１２】第２の実施形態の端末装置での予約リソースの解除動作を示すフローチャートである。
【図１３】第２の実施形態のノード装置での予約リソースの解除動作を示すフローチャートである。
【符号の説明】
１００…ネットワークシステム、１１０、１１０Ａ、１１０Ｂ…端末装置、１１１…アプリケーション部、１１２、１２２、１３２…予約管理部、１１９、１２９、１３９…転送管理部、１２０、１２０Ａ、１２０Ｂ…エッジノード装置、１２３、１３３…リソース管理部、１２４、１３４…リソース管理データテーブル、１２５…受付管理部、１２６…受付管理データテーブル、１３０…コアノード装置。
【図１】
0004507400.tif 000002
【図２】
0004507400.tif 000003
【図３】
0004507400.tif 000004
【図４】
0004507400.tif 000005
【図５】
0004507400.tif 000006
【図６】
0004507400.tif 000007
【図７】
0004507400.tif 000008
【図８】
0004507400.tif 000009
【図９】
0004507400.tif 000010
【図１０】
0004507400.tif 000011
【図１１】
0004507400.tif 000012
【図１２】
0004507400.tif 000013
【図１３】
0004507400.tif 000014