(57)【特許請求の範囲】
【請求項１】
複数のドメインにまたがるネットワーク経路でのQoS保証方法であって、
前記複数のドメインのそれぞれに備えられるドメイン間を連携するQoSサーバのうち、QoS保証用資源要求元となるドメインに備えられるQoSサーバにより、
QoS保証用資源要求メッセージを生成し、
前記生成されたQoS保証用資源要求メッセージを経路上の次のドメインを管理するQoSサーバに送り、
前記QoS保証用資源要求メッセージに対し、前記経路上の全てのドメインでQoS保証用資源要求に対する結果が、資源確保が可能であるとき、得られたQoS保証のための、次ドメインから宛先ネットワークアドレスが属するドメインまでの経路上の資源を管理し、
さらに、前記QoS保証用資源要求元となるドメインに備えられるQoSサーバにより、
カスタマから前記複数のドメインにまたがる、自ドメインが始点となる方向である上り方向のQoS保証要求を受けた場合に、
前記QoS保証用資源要求の宛先アドレスから特定される外部ドメインの資源と、自ドメインの資源が割り当て可能か否かを、前記管理する資源情報から判断し、割り当て可能であれば、前記カスタマの要求に対して資源確保が可能であることの通知を返す
ことを特徴とするQoS保証方法。
【請求項２】
請求項１において、
前記複数のドメインにまたがる経路上の中間にあるQoSサーバにより、
前記複数ドメインにまたがる経路でのQoS保証用資源要求を受け、
前記要求に含まれる宛先ネットワーク情報から次ドメインにまたがる要求であるか否かを判定し、
次ドメインにまたがる要求であると判定されるとき、次ドメインのQoSサーバを特定し、
さらに自ドメインの次ドメインに接続するゲートウェイアドレスを特定し、
前記要求メッセージにゲートウェイアドレスを付加して前記次ドメインのQoSサーバに
対してメッセージを転送する
ことを特徴とするQoS保証方法。
【請求項３】
請求項２において、
前記複数のドメインにまたがる経路上の中間にあるQoSサーバにより、
さらに自ドメインで要求を満たすQoS保証用資源が割り当てられることを確認し
前記転送したメッセージに対する応答が資源確保が可能であるとき、前段のドメインにある前記QoS保証用資源要求の送信元QoSサーバに対して資源確保が可能であることの通知を返す
ことを特徴とするQoS保証方法。
【請求項４】
請求項１乃至３のいずれかにおいて、
前記複数のドメインにまたがる経路上の終端のドメインにあるQoSサーバにより、
前記QoS保証用資源要求を受け、宛先ネットワークが自ドメインに属することから自ド
メインが終点であることを確定し、
さらに自ドメインで要求を満たすQoS保証用資源が割り当てられることを確認した場合、QoS保証用資源要求を転送してきた前段のドメインのQoSサーバに対して資源確保が可能であることの通知を返す、
ことを特徴とするQoS保証方法。
【請求項５】
複数のドメインにまたがるネットワーク経路に配置されるドメイン間連携QoSサーバで
あって、
送信元となるドメインに付属するドメイン間連携QoSサーバとして、
QoS保証用資源要求メッセージを生成し、前記生成されたQoS保証用資源要求メッセージを経路上の次のドメインを管理するQoSサーバに送るドメイン間連携機能部と、
前記QoS保証用資源要求メッセージに対し、前記経路上の全てのドメインでQoS保証用資源要求に対する結果が資源確保が可能であるとき、得られたQoS保証のための、次ドメインから宛先ネットワークアドレスが属するドメインまでの経路上の資源を管理する資源管理機能部を有し、
カスタマから前記複数のドメインにまたがる、自ドメインが始点となる方向である上り方向のQoS保証要求を受けた場合に、
前記QoS保証用資源要求の宛先アドレスから特定される外部ドメインの資源と、自ドメインの資源が割り当て可能か否かを、前記管理する資源情報から判断し、割り当て可能であれば、前記カスタマの要求に対して資源確保が可能であることの通知を返す、
ことを特徴とするドメイン間連携QoSサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，マルチドメインネットワークにおけるＱoＳ保証方法及び，これに適用するQoSサーバに関し，QoS保証可能なネットワークシステムにおいて複数の管理ドメインで構成される場合に，エンドツーエンドでの通信品質保証を動的に効率よく行うためのＱoＳ保証方法及び，これに適用するQoSサーバに関する。
【背景技術】
【０００２】
品質保証通信を実現するためには，帯域をデータフローごとにエンドツーエンドで確保する必要がある。大規模ネットワークになると，通信経路は複数のドメインを通過することが一般的であり，この場合データフローが通る経路上の全ての管理ドメインにおいて帯域確保を行う必要がある。
【０００３】
かかる必要に対して，従来技術としては，以下のものが挙げられる。
【０００４】
第１の方法は，図１に示すRFC2205，第１版機能説明におけるRSVP（Resource reSerVation Protocol）によって，経路上のネットワーク資源を予約する方法である。
【０００５】
図１において，ドメインＡ,Ｂ上に経路が張られ,送信元（sender）１００からパス（path）メッセージで順次にトラヒック特性や経路情報を送り，送信先（receiver）１０１から予約（RESV）メッセージを送信元（sender）に送る。経路途中にあるルータＲで必要な設定を行うことで，データパスの予約が行われる。
【０００６】
この方法では，途中のルータがRSVP対応していなくても動作するが，経路上のQoS保証予約が確実に行われるためには全てのルータＲがRSVP対応している必要がある。さらに，フローごとの情報をルータＲが保持しなければならず，ネットワーク規模（スケーラビリティ）に制限が生じるという問題がある。
【０００７】
また，特許文献１に記載された第２の従来技術「マルチドメインに対応した品質保証型通信サービス提供方式およびサービス提供方法ならびにサービス仲介装置」が知られている。図２にこの技術の説明図が示される。
【０００８】
ドメインＡ，Ｂ対応にネットワークサービス管理装置２Ａ，２Ｂがあり，これを管理するさらに上位のマルチドメインサービスブローカ１が備えられる。
【０００９】
送信元ネットワーク１００のカスタマ１００ａから要求がある（ステップＳ１）と，対応するドメインＡのネットワークサービス管理装置２Ａはマルチドメインサービスブローカ１に経路やネゴシエーションするべき他のネットワークサービス管理装置の情報を問い合わせる（ステップＳ２）。
【００１０】
マルチドメインサービスブローカ１から通知（ステップＳ３）された他ドメインＢのネットワークサービス管理装置２Ｂとネゴシエーションを行い（ステップＳ４），各ドメインで設定を行う（ステップＳ５）。設定後，カスタマ１００ａに設定の旨応答して（ステップＳ６），経路上のQoS保証をマルチドメインで実現する。
【００１１】
かかる図２に示す方法では，カスタマ１００ａに対するネットワークサービス管理装置２Ａに対する要求（Ｓ１）からカスタマ１００ａへの応答（Ｓ６）までに処理時間がかかるという課題がある。
【００１２】
また，第３の従来技術として，紙ベースの契約（SLA契約，Service Level Agreement）による方法がある。この方法は，各ドメイン管理者（ネットワークプロバイダ）同士であらかじめQoS保証して転送するための契約を結んでおき，契約を実行するための設定を各々行っておく。
【００１３】
すなわち，第３の従来技術を示す図３により説明すると，ネットワークドメインＡの管理者は，ネットワークドメインＢの管理者とお互いに，例えば３０Ｍbpsのトラフィックを遅延が少なくパケットロスがおきないように転送するという契約を結んでおく（ＳＳ１）。
【００１４】
そして，それぞれドメインＡ，Ｂにおいて，に契約を履行できるように契約内容の登録としてネットワーク機器の設定を行う（ＳＳ２）。
【００１５】
カスタマ１００ａからネットワーク（ａ）１００を通して，例えばネットワークｂ−ｃ間で１Ｍｂｐｓの使用要求があると（ＳＳ３），QoSサーバ１０などが契約した帯域内で使用できるかどうかを既に設定許可されている帯域を確認して更新する（ＳＳ４）。そして，使用できる場合（図３に示す例では，２７Ｍbpsの余裕があるので，使用許可の応答を返し（ＳＳ５），マルチドメインにまたがるQoS保証通信を実現する。
【００１６】
しかし，かかる方法では，使わないときも常に帯域を確保しており帯域に無駄がでる。カスタマ１００ａからの要求が多く，帯域が不足しても，直ちに契約や設定の変更できず呼損させてしまう。
【００１７】
また，一時的な要求の増加にあわせて契約変更を行うと，再度，契約を元に戻す作業も必要となり煩雑であるというような課題が存在する。
【００１８】
さらに，第４の従来方法として，特許文献２に記載の技術がある。この従来技術では，各ネットワークドメインのポリシーサーバ同士でＳＬＡ合意要求および合意，契約情報の管理を行う。３つ以上のドメインのサーバが関わる契約については複数の契約が関連するため，中間に位置するドメインの契約情報を管理しているサーバで複数の契約の関連付けを行い，変更が生じたときには関連する契約すべての変更ができる。
【００１９】
すなわち，図４により説明すると，各ドメインＡ，Ｂ，Ｃのポリシーサーバ２０Ａ，２０Ｂ，２０Ｃ同士で契約をオンラインで締結する仕組み（処理工程Ｐ１の手順）を持つ。ポリシーサーバ２０Ａとポリシーサーバ２０Ｂ間でＡ−Ｂ間契約を成立させ，ポリシーサーバ２０Ｂとポリシーサーバ２０Ｃ間でＢ−Ｃ間契約を成立させ留（処理工程Ｐ２）。
【００２０】
ついで，契約に基づき，それぞれのドメインにおいて必要な機器設定を行う（処理工程Ｐ３）。
【００２１】
なお，変更が生じた場合には関連する契約についても変更を行うことができ，３つ以上のドメインに関連する契約の動的な変更も可能である（処理工程Ｐ４）。
【００２２】
かかる第４の技術においては，要求元ドメインＡがドメインＣまでの経路上の資源を要求する場合，ドメインＡとドメインＢとの契約， ドメインＢとドメインＣとの契約の２つの契約が生成され，中間ドメインＢが契約情報の関連付けを行う。すなわち他ドメインの要求によって発生した情報を保持する必要がある。したがって，中間ドメインＢで保持する関連付け情報は膨大になるという課題を有している。
【特許文献１】特許第3617406号公報
【特許文献２】特開2002-74207号公報
【発明の開示】
【発明が解決しようとする課題】
【００２３】
上記図１に示した第１の従来技術であるRSVPによる方式の場合，トラフィックが通過する全てのルータＲがRSVP対応であることが前提として必要であり実現性に乏しく，またルータＲがフローごとの情報を保持・管理しなければならないため，大規模ネットワークでの適用にはスケーラビリティに欠けるということが知られている。
【００２４】
また，第２の従来技術である，図２に示した特許文献1に示される方式では，カスタマの要求に対応して仲介装置からネゴシエーション相手の情報を得て他のドメインとネゴシエーションを行うという方法であり，カスタマへの応答までの処理時間がかかるという問題点がある。
【００２５】
また，第３の従来技術である，図３に示した，あらかじめ紙ベースでSLA（Service Level Agreement）契約を取り交わしておく方法については，使用状況が想定トラヒック量と大きく異なってしまった場合に資源の利用効率が悪くなってしまい，使用状況にあわせて契約を変更する場合でも契約変更やそれに伴う諸設定に時間を要するという問題がある。
【００２６】
さらに，第４の従来技術である，図４に示した特許文献２に記載のポリシーサーバを用いる方法では，基本的にSLA合意および契約は隣接する２つのドメイン間同士で行われる。すなわち，n個（3つ以上）のネットワークドメインを通過する経路でのQoS保証に対してn-1個の契約が関連するため，全ての契約を関連付けする必要があり，中間に位置するドメインのサーバで多くの関連付けのための情報を保持しなければならない。
【００２７】
かかる第１から第４の従来技術に鑑みて，本発明の目的は，大規模なマルチドメインネットワークにおいてカスタマからの要求にすばやく応答でき，使用状況にあった資源利用をしつつエンドツーエンドでの品質保証通信を可能とし，更にそのために管理する情報も少なく抑える，マルチドメインネットワークにおけるＱoＳ保証方法及び，これに適用するQoSサーバを提供することにある。
【課題を解決するための手段】
【００２８】
上記の目的を達成する本発明の第１の側面は，複数のドメインにまたがるネットワーク経路でのQoS保証方法であって，前記複数のドメインのそれぞれに備えられるドメイン間を連携するQoSサーバのうち，QoS保証用資源要求元となるドメインに備えられるQoSサーバにより，QoS保証用資源要求メッセージを生成し，前記生成されたQoS保証用資源要求メッセージを経路上の次のドメインを管理するQoSサーバに送り，
前記QoS保証用資源要求メッセージに対し，前記経路上の全てのドメインでQoS保証用資源要求に対する結果が，資源確保が可能であるとき，得られたQoS保証のための，次ドメインから宛先ネットワークアドレスが属するドメインまでの経路上の資源を管理することを特徴とする。
【００２９】
また，上記の目的を達成する本発明の第２の側面は，複数のドメインにまたがるネットワーク経路に配置されるドメイン間連携QoSサーバであって，送信元なるドメインに付属するドメイン間連携QoSサーバとして，QoS保証用資源要求メッセージを生成し，前記生成されたQoS保証用資源要求メッセージを経路上の次のドメインを管理するQoSサーバに送るドメイン間連携機能部と，前記QoS保証用資源要求メッセージに対し，前記経路上の全てのドメインでQoS保証用資源要求に対する結果が資源確保が可能であるとき，得られたQoS保証のための，次ドメインから宛先ネットワークアドレスが属するドメインまでの経路上の資源を管理する資源管理機能部を有することを特徴とする。
【００３０】
かかる本発明の特徴により，宛先ネットワークアドレスごとに，他のドメインのQoS保証用資源を獲得する手段を持ち，要求元のドメインのQoSサーバがあらかじめ（カスタマからの要求受付とは別のタイミングで）他のドメインの資源を宛先ネットワークアドレスごとに獲得・管理しておくことで，２つ以上の複数ドメインにまたがるカスタマからのQoS要求を受けた場合に，通過する他のドメイン全てのQoSサーバとネゴシエーションを行うことなく受付可否判定ができ，すぐに応答することが可能となる。
【００３１】
前記第１及び第２の側面において，前記複数のドメインにまたがる経路上の中間にあるQoSサーバにより，他ドメインのQoSサーバからカスタマからの資源要求メッセージを転送された場合に，前記資源要求メッセージの要求元アドレスから特定される外部ドメインの資源と，自ドメインの資源が割当可能かどうかを，管理資源情報から判断し，割当可能であれば要求元のQoSサーバに対して資源確保が可能であることの通知を返す様に構成してもよい。
【００３２】
前記第１及び第２の側面において，前記QoS保証用資源要求元となるドメインに備えられるQoSサーバにより，カスタマから前記複数ドメインにまたがる，自ドメインが始点となる方向である上り方向のQoS保証要求を受けた場合に，前記QoS保証用資源要求の宛先アドレスから特定される外部ドメインの資源と，自ドメインの資源が割当可能かどうかを，管理資源情報から判断し，割当可能であれば前記カスタマの要求に対して資源確保が可能であることの通知を返す様に構成してもよい。
【００３３】
また，前記第１及び第２の側面において，前記QoS保証用資源要求元となるドメインに備えられるQoSサーバにより，カスタマから複数ドメインにまたがる自ドメインが終点となる方向である下り方向のQoS保証要求を受けた場合に，前記QoS保証用資源要求の宛先アドレスから特定される終点ドメインのQoSサーバに対し，要求メッセージを転送し，前記要求メッセージに対する応答が資源確保が可能であれば，前記カスタマに資源確保が可能であることの通知を返す様に構成してもよい。
【００３４】
前記第１及び第２の側面において，前記QoS保証用資源要求元となるドメインに備えられるQoSサーバにより，カスタマから複数ドメインにまたがる双方向のQoS保証要求を受けた場合に，前記双方向のQoS保証要求の宛先アドレスから特定される終点ドメインのQoSサーバに対し，前記双方向のQoS保証要求メッセージを転送し，前記双方向のQoS保証要求メッセージに対する応答が,資源確保可能であり，かつ前記双方向のQoS保証要求の宛先アドレスから特定される外部ドメインの資源と，自ドメインの資源が割当可能かどうかを，管理資源情報から判断し，割当可能であれば，前記カスタマの要求に対して資源確保が可能であることの通知を返すように構成してもよい。 
【００３５】
かかる構成により，要求元ドメインで要求元が始点となる資源を全て管理することで，要求元ドメインから宛先ネットワークの属するドメインまで３つ以上のドメインが連なっていた場合に，中間に位置するドメインのQoSサーバが第４の従来技術のように複数の契約情報を関連付ける情報を持つ必要がない。すなわち中間に位置するドメインのQoSサーバは自ドメインの該当する資源を確保する機能と，メッセージの転送が必要かどうかを判定し転送を行う機能を持ち，さらに自ドメインの資源が確保できた場合で，メッセージを転送した場合はその応答も資源確保が可能であることの通知であれば前のドメインのQoSサーバに資源確保が可能である応答を返す機能を持てばよい。
【００３６】
さらに，上記第１及び第２の側面において，前記QoS保証用資源要求元となるドメインに備えられるQoSサーバにより，管理している宛先ネットワークまでの他ドメイン資源の未使用資源量が閾値よりも多い状態が一定時間以上続いた場合に，QoS保証用資源を一定量解放する解放要求メッセージを生成し，前記宛先ネットワークから特定される次ドメインのQoSサーバに解放要求メッセージを転送し，前記QoSサーバに解放要求メッセージの応答結果が資源解放可能であれば管理している他ドメイン資源の更新を行うように構成してもよい。
【００３７】
また，上記第１及び第２の側面において，前記管理している宛先ネットワークまでの他ドメイン資源の未使用資源量が閾値よりも少ない状態が一定時間以上続いた場合には，QoS保証用資源を一定量要求するメッセージを生成し，宛先ネットワークから特定される次ドメインのQoSサーバに前記生成したメッセージを転送し，前記メッセージに対する応答結果が資源確保可能であれば管理している他ドメイン資源の更新を行う様に構成してもよい。
【００３８】
かかる構成により，要求元ドメインで管理している他のドメインのQoS保証用資源が，カスタマの要求が多くて不足したりカスタマの要求が少なくて余っている場合に，QoS保証用資源を追加で獲得あるいは解放する手段を持つことで，状況に応じた資源確保を行うことができ，資源利用効率を向上させ呼損率を低減させることができる。
【発明を実施するための最良の形態】
【００３９】
以下に図面に従い，本発明の実施の形態例を説明する。なお，実施の形態例は本発明の理解のためのものであり，本発明の技術的範囲がこれらに限定されるものではない。
［実施例１］
図５に実施例１のネットワーク構成を示す。ネットワークは，ドメインＡ，Ｂ，Ｃが繋がって構成されていると想定する。
（３つのドメインに跨る資源の，要求元での獲得方法）
ドメインＡ，Ｂ，Ｃにはそれぞれドメイン間連携QoSサーバ３Ａ，３Ｂ，３Ｃが存在する。
【００４０】
図６は，ドメイン間連携QoSサーバ３Ａ，３Ｂ，３Ｃの機能ブロックであり，構成は共通であり，カスタマ要求受付機能部３０，資源管理機能部３１，自ドメイン経路管理機能部３２，ドメイン間連携機能部３３から構成される。
【００４１】
自ドメインの資源３４については、区間ごとに自ドメイン経路管理機能３２で経路と帯域を決定し、自ドメインQoS資源管理機能部３１ａで管理する。図５に示す例では，ドメインＡのエッジルータＥＲ1からゲートウエイＧＷ1までの経路は，中央ルータCR1を経由して，ＥＲ1-CR1-ＧＷ1であり，これに帯域保証として１０Ｍbpsを割り当てることとする。かかる経路の決定や資源割当量の決定方法については、従来の最適資源割当アルゴリズムなどが適用できる。
【００４２】
したがって，自ドメインQoS資源管理機能部３１ａにより，ＥＲ1-ＧＷ1で10Mbpsの帯域保証用資源を管理する。このとき，自ドメインQoS資源管理機能部３１ａにより，図７Ａに示す管理テーブルが自ドメイン資源３４に作成される。
【００４３】
区間ＥＲ１とＧＷ１の上り，下り方向に，QoSクラスが帯域保証クラスであって，使用可能帯域として１０Ｍbpsが確保される。このとき使用前であるので，空き帯域は使用可能帯域と同じである。
【００４４】
他のドメインＢ，Ｃにおいても，同様に，それぞれ自ドメイン内区間の帯域保証用資源を確保しているものとする。たとえば，ドメインＢはゲートウエイＧＷ2とゲートウエイＧＷ3の間，ゲートウエイＧＷ2とエッジルータＥＲ3の間，エッジルータＥＲ3とゲートウエイＧＷ3の間にそれぞれ５０Ｍbps分の資源を確保し，管理する。
【００４５】
ドメインＣはゲートウエイＧＷ4とエッジルータＥＲ2の間に５０Mbps分を確保し，管理する。
【００４６】
ここで，ドメインＡでは，送信元(SOURCE(1))１００から送信先（DESTINATION (1)）１０１までの通信に対して帯域保証サービスを行うために１０Ｍbps分の資源を確保したいと判断する。判断のトリガとしては，例えばオペレータがあらかじめ帯域保証サービスを提供する区間と帯域を決定し，ドメイン間連携QoSサーバ３Ａに設定しておく方法などが考えられる。
【００４７】
ドメインＡが送信先１０１までの資源，即ち，ドメインＡのゲートウエイＧＷ1からドメインＢを通り，ドメインＣに至る経路でのQoS保証のための資源を１０Ｍbps分確保するために，ドメイン間連携QoSサーバ３Ａのドメイン間連携機能部３３でQoS保証用資源要求メッセージを生成する。
【００４８】
図８は，かかるドメイン間連携QoSサーバ３ＡにおけるQoS保証のための資源要求メッセージ生成処理のフロー図である。また，図９は，ドメインＡ，Ｂ，Ｃ間のシーケンスフローである。
【００４９】
まず，ドメイン間連携QoSサーバ３Ａの資源管理機能部３１でマルチドメイン区間での保証要求を決定し、ドメイン間連携機能部３３に要求を送る（図８：ステップＳ１０，図９：処理工程Ｐ１）。
【００５０】
この要求にはゲートウエイＧＷ1から送信先１０１までの区間に対する要求であること，帯域保証クラスで１０Ｍbps分確保したいことを情報として含める。
【００５１】
ドメイン間連携QoSサーバ３Ａは，メッセージを送付する先の情報として，送信先１０１までに至るために次のドメインがドメインＢであることと，ドメイン間連携QoSサーバ３Ｂのアドレスをあらかじめ管理している。このとき送信先１０１がドメインＣに属することを知っている必要はない。
【００５２】
したがって，ドメイン間連携QoSサーバ３Ａは，保証区間で、自ドメインの次にあたるドメインが，ドメインＢであり，対応するドメイン間連携QoSサーバ３Ｂのアドレスを特定する（図８：ステップＳ１１，図９：処理工程Ｐ２）。
【００５３】
この際，メッセージ生成に必要な情報はあらかじめドメイン間連携QoSサーバ３Ａで保持している。例えば，図１０に示すように，宛先ネットワーク情報I，自ドメイン情報II，経由するゲートウエイIII及び，自ドメイン間連携QoSサーバアドレスIVを有している。
【００５４】
図１１Ａは，上記メッセージ生成に必要な情報に基づき生成されるQoS保証用資源要求メッセージのフォーマットの例を示す図である。QoS要求メッセージの区別を示すＩＤを含むQoS要求メッセージヘッダと，QoS要求メッセージの区別に対応するQoS要求の内容が書き込まれる。
【００５５】
図１１Ｂは，図１１Ａのフォーマットに従って生成されたドメイン間連携QoSサーバ３Ａにより生成された資源要求メッセージの内容である。
【００５６】
ドメイン間連携QoSサーバ３Ａのドメイン間連携機能部３３により，隣接するドメインＢのドメイン間連携QoSサーバ３Ｂに資源要求メッセージが送られる（図８：ステップＳ１２，図９：処理工程Ｐ３）。
【００５７】
したがって，ドメインＢのドメイン間連携QoSサーバ３Ｂのドメイン間連携機能部３３でドメイン間連携QoSサーバ３Ａからの図１１Ｂに示した資源要求メッセージを受ける。
【００５８】
ドメイン間連携QoSサーバ３Ｂでは，ゲートウエイＧＷ1と接続しているのはゲートウエイＧＷ2であること，送信先１０１に至るために次のドメインがドメインＣであって，ゲートウエイＧＷ３が接続していることの事実から，ゲートウエイＧＷ2からゲートウエイＧＷ3に至る資源があるかどうかを，資源管理機能部３１に確認し（処理工程Ｐ４），対応の資源があればその割当を行う（処理工程Ｐ５）。
【００５９】
図１２は，ドメインＢのドメイン間連携QoSサーバ３Ｂで保持している帯域情報であり，自ドメイン資源３４として更新される。すなわち，ドメインＡからの要求で１０Ｍbpsの容量を割り当てるため，ドメインＢのゲートウエイＧＷ2からゲートウエイＧＷ3への帯域保証クラスの空き帯域が５０Ｍbpsから４０Ｍbpsに更新される。
【００６０】
ドメインＢの資源管理機能部３１は，このように資源割り当てを行い，ドメイン間連携機能部３３に資源確保が可能であること（以下，ＯＫと表記する）を通知する（処理工程Ｐ６）。
【００６１】
次いで，ドメインＢのドメイン間連携QoSサーバ３Ｂは，送信先１０１に接続するために，次のドメインＣのドメイン間連携QoSサーバ３Ｃを決定し（処理工程Ｐ７），これに対して，資源確保要求メッセージを転送する（処理工程Ｐ８）。
【００６２】
このとき，ゲートウエイＧＷ３から送信先１０１までの区間に対する要求であることを示すように転送するメッセージ内容を書き換える。
【００６３】
図１１Ｃは，ドメイン間連携QoSサーバ３Ｂが転送するメッセージの内容であり，ドメイン間連携QoSサーバ３Ａから送られるメッセージ（図１１Ｂ）に対して，ゲートウエイが書き換えられている（ＧＷ1→ＧＷ3）。
【００６４】
図１３Ａ，図１３Ｂは，ドメイン間QoSサーバ３Ｂにおいて，QoS保証のための資源要求メッセージを受信したときの上記処理（処理工程Ｐ３〜Ｐ７）における詳細動作フローを示す図である。
【００６５】
図１３Ａにおいて，ドメイン間連携QoSサーバ３ＡからQoS保証用資源要求メッセージを受信する（ステップＳ２０）と，ドメイン間連携機能部３０は，自ドメインの区間を特定する（ステップＳ２１）。すなわち，ゲートウエイＧＷ2とゲートウエイＧＷ3の区間を特定する。
【００６６】
ついで，特定した区間の資源確保処理を行う（ステップＳ２２）。特定した区間の資源確保が不能であれば，要求に対してＮＧの応答を返信する（ステップＳ２９Ｂ）。
【００６７】
一方，ステップＳ２４で資源確保が可能と判断されれば，資源管理機能部３１により区間と確保した帯域の情報を自ドメイン資源３４で管理する（ステップＳ２５）。
【００６８】
ついで，宛先ネットワークは他のドメインに属するか否かを判断し（ステップＳ２６），他のドメインに属しない場合（ステップＳ２６，ＮＯ）は，要求ＯＫの応答をドメイン間連携QoSサーバ３Ａに送信する（ステップＳ２９Ａ）。
【００６９】
ステップＳ２６で宛先ネットワークは他のドメインに属すると判断される場合（ステップＳ２６，ＹＥＳ）は，メッセージ転送処理が行われる（ステップＳ２７）。このメッセージ転送処理の内容は，図１３Ｂに示す処理フローに従い行われる。
【００７０】
図１３Ｂにおいて，保証区間で、自ドメインの次にあたるドメイン、及びそこでのドメイン間連携QoSサーバ，本実施例では，ドメイン間連携QoSサーバＣのアドレスを特定する（ステップＳ２７１）。
【００７１】
ついで，ドメイン間連携機能部３３で、図１１Ｃに示したメッセージ転送フォーマットにおける要求メッセージのゲートウェイアドレスを書き換え（本実施例では，ゲートウエイアドレスＧＷ3に書換え）て，特定したドメイン間連携QoSサーバ３Ｃに送信する（ステップＳ２７２）。
【００７２】
図１３Ａのフローに戻り，ドメイン間連携QoSサーバ３Ｃからの転送メッセージに対するＯＫの応答を受信した場合（ステップＳ２８，ＹＥＳ）は，要求元であるドメイン間連携QoSサーバ３ＡにＯＫの応答を送信する（ステップＳ２９Ａ）。
【００７３】
図９に戻り，ドメインＣのドメイン間連携QoSサーバ３Ｃのドメイン間連携機能部３３は，送信先１０１が自ドメインに属するため，メッセージ転送は行わないでよいと判断する（処理工程Ｐ９）。また，ゲートウエイＧＷ3と接続しているゲートウエイＧＷ4から，送信先１０１が接続しているエッジルータＥＲ2に至る自ドメインの資源があるかどうかを，資源管理機能部３１に確認し（処理工程Ｐ１０），割当を行う（処理工程Ｐ１１）。
【００７４】
割当通知を受けると（処理工程Ｐ１２），ドメイン間連携QoSサーバ３Ｃのドメイン間連携機能部３３によりドメイン間連携QoSサーバ３ＢにＯＫの応答を返す（処理工程Ｐ１３）。
【００７５】
ドメイン間連携QoSサーバ３Ｂは，自ドメインでの資源割当がＯＫで，ドメイン間連携QoSサーバ３Ｃからの応答もＯＫであることを確認し（処理工程Ｐ１４），ドメイン間連携QoSサーバ３ＡにＯＫの応答を返す（処理工程Ｐ１５、図１３ＡステップＳ２９Ａ）。
【００７６】
ドメイン間連携QoSサーバ３Ｂから，ドメイン間連携QoSサーバ３Ａのドメイン間連携機能部３３で，要求受付がＯＫであるとのメッセージを受信すると（図８：ステップＳ１３，Ｙｅｓ，図９：処理工程Ｐ１６），資源管理機能部３１の他ドメインQoS資源管理機能部３１ｂにより，獲得したゲートウエイＧＷ1から送信先１０１までの資源１０Ｍbpsを他ドメイン資源３５として管理する（図８：ステップＳ１５，図９：処理工程Ｐ１７）。このときの他ドメイン資源３５の管理テーブルの状態は，図７Ｂに示すごとくである。
【００７７】
以上により，ドメインＡにおいて，送信先１０１までの資源が１０Ｍbps分確保される。この状態で，ドメインＡのカスタマ１００ａから，送信先１０１に属する端末への１Ｍbpsの帯域保証通信要求があった場合，以下のように動作する。
【００７８】
図１４は，ドメインＡのカスタマ１００ａから，送信先１０１に属する端末への１Ｍbpsの帯域保証通信要求に対する処理シーケンスである。
【００７９】
カスタマ1００ａからの帯域保証要求が，ドメイン間連携QoSサーバ３Ａのカスタマ要求受付機能部３０で受け付けられる（処理工程Ｐ２０）。
【００８０】
カスタマ要求受付機能部３０は，要求方向，区間を確認し，自ドメインが送信元（Source）である上り方向であることを確認する（処理工程Ｐ２１）。そして，資源管理機能部３１に対し，要求区間の帯域を確認する（処理工程Ｐ２２）。
【００８１】
資源管理機能部３１では図１５Ａ，図１５Ｂに示したように自ドメイン資源３４と送信先１０１間での区間の帯域情報である他ドメイン資源３５を管理している
これらの自，他ドメイン資源３４，３５からカスタマ１００ａの端末アドレスから接続するエッジルータがＥＲ1であること，更にドメイン間連携QoSサーバ３Ａでも保持している図１０に示した隣接ドメイン情報から，送信先１０１へはゲートウエイＧＷ1を経由することがわかる。
【００８２】
これにより，資源管理機能部３１は，自ドメインのエッジルータＥＲ1からゲートウエイＧＷ1までの区間で帯域保証クラス１Mbpsの帯域を割当てが可能かを確認する。
【００８３】
さらに，他ドメインのＧＷ1から送信先１０１間の区間で帯域保証クラス１Mbpsの割当てが可能かを確認する（処理工程Ｐ２３）。割当て可能であるので，該当する自，他ドメイン資源３４，３５の割当てを行う。このとき，資源情報に割当て帯域，割当先の情報を付加し，空き帯域を更新する。今回は１Mbpsの要求があったので，空き帯域を９Mbpsに減らす。この状態が，自，他ドメイン資源３４，３５に更新，反映される。
【００８４】
図１５Ａは，自ドメイン資源３４の更新登録されたカスタマ１００ａに対しての帯域割当て後の帯域情報である。同様に，図１５Ｂは，他ドメイン資源３４の更新登録されたカスタマ１００ａに対しての帯域割当て後の帯域情報である。
【００８５】
ついで，保証要求受付OKを，カスタマ要求受付機能部３０からカスタマ１００ａに返答する（処理工程Ｐ２４，Ｐ２５）。
【００８６】
以上のようにして，宛先ネットワーク毎に品質保証要求に対して割り当てられる資源を準備しておくことで，カスタマ１００ａからの要求があった場合に既に確保した資源を割り当て，すばやく要求に対応できる。
［実施例２］
次に第２の実施例として２つのドメインに跨る資源の割当帯域の増減について説明する。
【００８７】
実施例２として図１６に示すようなネットワークを想定する。
【００８８】
ドメインＡは自ドメインの資源として，ネットワーク１００Ａに繋がるルータＲ1からＲ3までの区間とネットワーク１００Ｂに繋がるルータＲ2からＲ3までの区間にそれぞれ８Ｍbpsの帯域保証用資源を確保している。また，ルータＲ3からネットワーク１００Ｃ，１００Ｄに至る区間に，１０Ｍbpsの帯域を獲得している。
【００８９】
事前にドメインＡは、ドメイン間連携QoSサーバ３Ａにより，ドメインＢのドメイン間連携QoSサーバ３ＢにQoS保証用資源の要求を行い（Ｓ２０）、ネットワーク１００Ｃ、１００ＤとのQoS保証通信用にルータＲ4からルータＲ5の帯域を確保しておく（ステップＳ２１）。
【００９０】
ドメイン間連携QoSサーバ３Ｂからの設定応答を受け（ステップＳ２２），ドメイン間連携QoSサーバ３Ａは，自，他ドメイン資源３４，３５を更新する（ステップＳ２３）。
【００９１】
このような事前処理が行われた状態で，図１７に示すように，ネットワーク１００Ａに接続しているドメインＡのカスタマ１００ａから，ネットワーク１００Ｃに対して１Ｍbpsの帯域保証通信を要求（ステップＳ３０）がなされると想定する。
【００９２】
ドメイン間連携QoSサーバ３Ａは，ルータＲ2からルータＲ3の区間の資源から１Ｍbpsを割当て，ルータＲ3からネットワーク１００Ｃ，１００Ｄに至る区間の資源から１Ｍbpsを割り当てる（ステップＳ３１）。したがって，残り区間はそれぞれ７Ｍbps，９Ｍbpsになる。
【００９３】
ついで，割当てができたので，カスタマにQoS保証通信可能であることをカスタマ１００ａに通知する。
【００９４】
ここで，カスタマの要求が増加してきて，ネットワーク１００Ａからネットワーク１００Ｄへの要求５Ｍbps分，およびネットワーク１００Ｂからネットワーク１００Ｃへの要求が４Ｍbps分受け付けられた状態を想定する。
【００９５】
図１８に示すようにルータＲ3からネットワーク１００Ｃ，１００Ｄへの資源の残り帯域は１Ｍbpsになっている。
【００９６】
したがって，ドメイン間連携QoSサーバ３Ａの資源管理機能部３１で，残り帯域を所定の閾値と比較してネットワーク１００Ｃ，１００Ｄへの帯域保証用資源１０Ｍbps分の追加要求を決定する。要求メッセージを生成してドメイン間連携QoSサーバ３Ｂへ送る（ステップＳ４０）。図１６で示した手順と同様に，ドメインＢでの帯域がドメインＡ用に確保され（ステップＳ４１），ドメイン間連携QoSサーバ３Ａはドメイン間連携QoSサーバBからＯＫの応答を得る（ステップＳ４２）。
【００９７】
ドメイン間連携QoSサーバ３Ａでは資源管理機能部３１の他ドメイン資源３５の情報を更新する，すなわちルータＲ3からネットワーク１００Ｃ，１００Ｄに至る区間の資源の残り帯域が１１Ｍbpsであるとする（図１８）。
【００９８】
以上に示したように，要求状況に応じて柔軟に資源の追加を行うことができ，資源の有効利用を図る効果が得られる。
［実施例３］
次に，カスタマ１００ａからの下り方向フローの帯域保証要求について，実施例３として説明する。
【００９９】
図１９にカスタマから下り方向のフローの帯域保証要求を受けたケースについてシーケンスを示す。実施例１で示したように，本発明では上り方向（送信元が自ドメインになる方向）で，マルチドメイン環境での保証用資源を確保するものである。このため，下り方向の要求が来た場合には保証要求を出すカスタマ（ドメインＡと契約しているカスタマ）の通信相手が属するドメインが送信元(Source)となるフローを保証する必要がある。
【０１００】
すなわち，通信相手がドメインＣに属する場合，帯域の割当てはドメイン間連携QoSサーバＣが行う。したがって，以下のような処理を行うことによって下り方向の保証に対応することができる。
【０１０１】
まず，カスタマ１００ｂは自分が属しているドメインで，保証サービスを受けるため，ドメイン間連携QoSサーハ゛３Ａのカスタマ要求受付機能部３０に帯域保証要求を出す（処理工程Ｐ３０）。カスタマ要求受付機能３０では，要求方向を確認し（処理工程Ｐ３０ａ），下り方向であるため，ドメイン間連携機能部３３に要求を転送する（処理工程Ｐ３１）。
【０１０２】
ドメイン間連携機能部３３は，要求された保証区間から次のドメインのQoSサーバを決定し（処理工程Ｐ３１ａ），ドメイン間連携QoSサーバ３Ｂに要求を転送する（処理工程Ｐ３２）。
【０１０３】
ドメイン間連携QoSサーバ３Ｂのドメイン間連携機能部部３３は，要求された保証区間から，自ドメインが終点ではないため，さらに次のドメインのQoSサーバを決定し（処理工程Ｐ３２ａ），ドメイン間連携QoSサーバ３Ｃに要求を転送する（処理工程Ｐ３３）。
【０１０４】
ドメイン間連携QoSサーバ３Ｃのドメイン間連携機能部３３は，要求された保証区間から，自ドメインが終点であることを確認し（処理工程Ｐ３３ａ），カスタマ要求受付機能部３０に要求を渡す（処理工程Ｐ３４）。
【０１０５】
カスタマ要求受付機能部３０は，要求の内容に従い，資源管理機能部３１に帯域確認を行う（処理工程Ｐ３５）。資源管理機能部３１は，要求を満足するために該当する自ドメイン資源３４，他ドメイン資源３５を割当てる（処理工程Ｐ３５ａ）。割当てができればＯＫをカスタマ要求受付機能部３０に返す（処理工程Ｐ３６）。
【０１０６】
カスタマ要求受付機能部３０から保証要求受付ＯＫをドメイン間連携機能部３３に送り（処理工程Ｐ３７），従って，保証要求受付ＯＫの応答を，ドメイン間連携QoSサーバ３Ｃから３Ｂ，３Ａへと順次返していく。
【０１０７】
最終的に，カスタマ１００ｂに要求受付ＯＫが返される。
【０１０８】
以上の手順により，下り方向の保証も，送信元（Source）となる端末やサーバの属するドメインのQoSサーバに要求を転送し，転送先ドメインで帯域割当てを行うことで実現することができる。
【０１０９】
なお，双方向通信の場合は，上りと下りの処理を両方行うことで実現できる。図２０は，双方向通信の場合の資源割り当て処理を説明するシーケンスフローである。図１９と異なる点は，ドメインＡのQoSサーバ３Ａのカスタマ要求受付機能部３０で，カスタマ１００ｃからの帯域保証要求を受け付けると，要求方向が双方向であることを確認する（処理工程Ｐ３０ｂ）。下り方向については，図１９に示したシーケンス処理に従う。同時に上り方向について，自ドメインＡの資源管理機能部３１に帯域確認を行う（処理工程ＰＰ３８）。
【０１１０】
資源管理機能部３１では，該当する自・他ドメインの上り方向の資源割り当てを行い（処理工程Ｐ３８ａ），帯域割当てＯＫの通知をカスタマ要求受付機能部３０に返す（処理工程Ｐ３９）。
【０１１１】
したがって，カスタマ要求受付機能部３０は，この自ドメインの資源管理機能部３１からの帯域割当てＯＫの通知と，ドメイン間連携QoSサーバ３Ｃから３Ｂ，３Ａへと順次返された，下り方向の帯域割当てＯＫの通知を確認し（処理工程Ｐ３９ａ），カスタマ１００ｃに帯域保証要求に対するＯＫを返信する。
【０１１２】
ここで，ドメイン間連携QoSサーバにおける動的なQoS保証のためには，資源の利用状況に対応して，追加の資源確保の要求，あるいは，不使用となった資源の解放処理が必要である。
【０１１３】
図２１は，かかる資源の追加及び解放決定判断を行う処理の例を示すフロー図である。
【０１１４】
図２１において，オペレータが資源を確保する区間情報，対象QoSクラス，最小確保帯域を資源管理機能部３１に登録しておく（ステップＳ３０）。
【０１１５】
ついで，適時に定時各区間，各QoSクラスの空き帯域を確認する（ステップＳ３１）。このとき，空き帯域が一定時間閾値より小であるか，大であるかを判定する（ステップＳ３２）。空き帯域が一定時間閾値の範囲内である時，次の適時まで，状態を維持する（ステップＳ３３）。
【０１１６】
一定時間閾値より小であれば，空き帯域が一定時間閾値より小となった区間・QoSクラスに関して、ドメイン間連系機能部３３へ資源追加を要求する（ステップＳ３４）。一方，空き帯域が一定時間閾値より大であれば，閾値より大となった区間・QoSクラスに関して、ドメイン間連系機能部３３へ資源解放を要求する（ステップＳ３５）。
【０１１７】
図２２は，図２１の判断フローにより資源解放の要求が判定された場合の資源解放メッセージ生成処理フローである。
【０１１８】
まず，ドメイン間連携QoSサーバ３Ａの資源管理機能部３１でマルチドメイン区間での保証用帯域解放を図２１に示した判断フローにより決定し，ドメイン間連携機能部３３へ解放を要求する（ステップＳ４０）。
【０１１９】
ドメイン間連携機能部３３では，解放要求を受けると，保証区間である，自ドメインの次に当たるドメイン（本実施例では，ドメインＢ），及びそこでのドメイン間連携QoSサーバ３Ｂのアドレスを特定する（ステップＳ４１）。
【０１２０】
これに基づき，ドメイン間連携機能部３３で、要求メッセージを生成、特定したドメイン間QoSサーバ３Ｂに送信する（ステップＳ４２）。
【０１２１】
このとき生成される解放要求メッセージフォーマットの例が図２３Ａに示される。保証帯域要求メッセージフォーマット（図１１Ｂ）と同様であるが，メッセージタイプが解放であり，方向が規定されていない。
【０１２２】
このドメイン間連携QoSサーバ３Ａからの解放要求を受けると，ドメイン間連携QoSサーバ３Ｂにおいて，図２４Ａ，図２４Ｂに示す処理を行う。すなわち，図２４Ａにおいて，ドメイン間連携QoSサーバ３Ｂは，ドメイン間連携QoSサーバ３ＡからQoS保証用資源解放要求メッセージ受信する（ステップＳ５０）と，実施例ドメインの区間即ち，ゲートウエイＧＷ2とＧＷ3の区間を特定する（ステップＳ５１）。そして，この特定された区間の資源の解放処理を行う（ステップＳ５１）。
【０１２３】
このとき，資源の解放が可能でなければ，要求された資源解放要求に対しＮＧの応答を返す（ステップＳＳ５７Ｂ）。
【０１２４】
一方，資源の解放が可能であれば（ステップＳ５２，ＹＥＳ），資源管理機能部３１により，解放した区間と帯域の情報を更新，管理する（ステップＳ５３）。
【０１２５】
ついで，解放要求メッセージの宛先ネットワークが他ドメインに属するかを判断し，自ドメイン即ち，ドメインＢ宛であれば，要求に対しＯＫの旨を送信する（ステップＳ５７Ａ）。
【０１２６】
一方，他ドメインに属すれば（ステップＳ５４，ＹＥＳ），メッセージを転送メッセージに置き換えて該当の他ドメイン，本実施例ではドメインＣ宛に転送する。図２４Ｂは，このときの，ドメイン間連携QoSサーバ３Ｂのメッセージ転送処理の詳細である。
【０１２７】
すなわち，保証区間で、自ドメインの次にあたるドメイン、及びそこでのドメイン間連携QoSサーバ３Ｃのアドレスを特定する（ステップＳ５５１）。ついで，ドメイン間連携機能部３３で、図２３Ｂに示すように，解放要求転送メッセージフォーマットにおいて，解放要求メッセージのゲートウェイアドレスを書き換え（ＧＷ1からＧＷ3への変更），特定したドメイン間連携QoSサーバ３Ｃに転送する（ステップＳ５５２）。
【０１２８】
図２４Ａのフローに戻り，ドメイン間連携QoSサーバ３Ｂは，ドメイン間連携QoSサーバ３Ｃからの転送メッセージに対する応答がＯＫであるか否かを判断する（ステップＳ５６）。
【０１２９】
解放要求に対しＯＫの応答であれば（ステップＳ５６，ＹＥＳ），要求に対してＯＫの応答をドメイン間連携QoSサーバ３Ａに送信する（ステップＳ５７Ａ）。さらに，解放要求に対しＮＧ応答であれば（ステップＳ５６，ＮＯ），ドメイン間連携QoSサーバ３Ａに要求ＮＧ応答を送信する（ステップＳ５７Ｂ）。
【０１３０】
（付記１）
複数のドメインにまたがるネットワーク経路でのQoS保証方法であって，
前記複数のドメインのそれぞれに備えられるドメイン間を連携するQoSサーバのうち，QoS保証用資源要求元となるドメインに備えられるQoSサーバにより，
QoS保証用資源要求メッセージを生成し，
前記生成されたQoS保証用資源要求メッセージを経路上の次のドメインを管理するQoSサーバに送り，
前記QoS保証用資源要求メッセージに対し，前記経路上の全てのドメインでQoS保証用資源要求に対する結果が，資源確保が可能であるとき，得られたQoS保証のための，次ドメインから宛先ネットワークアドレスが属するドメインまでの経路上の資源を管理する
ことを特徴とするQoS保証方法。
【０１３１】
（付記２）
付記１において，
前記複数のドメインにまたがる経路上の中間にあるQoSサーバにより，
前記複数ドメインにまたがる経路でのQoS保証用資源要求を受け，
前記要求に含まれる宛先ネットワーク情報から次ドメインにまたがる要求であるか否かを判定し，
次ドメインにまたがる要求であると判定されるとき，次ドメインのQoSサーバを特定し，
さらに自ドメインの次ドメインに接続するゲートウェイアドレスを特定し，
前記要求メッセージにゲートウェイアドレスを付加して前記次ドメインのQoSサーバに対してメッセージを転送する
ことを特徴とするQoS保証方法。
【０１３２】
（付記３）
付記２において，
前記複数のドメインにまたがる経路上の中間にあるQoSサーバにより，
さらに自ドメインで要求を満たすQoS保証用資源が割り当てられることを確認し
前記転送したメッセージに対する応答が資源確保可能であるとき，前段のドメインにある前記QoS保証用資源要求の送信元QoSサーバに対して資源確保が可能であることの通知を返す
ことを特徴とするQoS保証方法。
【０１３３】
（付記４）
付記１乃至３のいずれかにおいて，
前記複数のドメインにまたがる経路上の終端のドメインにあるQoSサーバにより，
前記QoS保証用資源要求を受け，宛先ネットワークが自ドメインに属することから自ドメインが終点であることを確定し，
さらに自ドメインで要求を満たすQoS保証用資源が割り当てられることを確認した場合，QoS保証用資源要求を転送してきた前段のドメインのQoSサーバに対して資源確保が可能であることの通知を返す，
ことを特徴とするQoS保証方法。
【０１３４】
（付記５）
付記１において，
前記複数のドメインにまたがる経路上の中間にあるQoSサーバにより，
前記複数ドメインにまたがる経路でのQoS保証用資源要求を受け，
前記QoS保証用資源要求に含まれる宛先ネットワークと前段のドメインのゲートウェイアドレスから，自ドメイン内の区間を特定し，特定した区間の資源が要求に対して割り当て可能であれば，前記要求元ドメインに対して必要な量の前記区間の資源を割り当てる，
ことを特徴とするQoS保証方法。
【０１３５】
（付記６）
付記１において，
前記QoS保証用資源要求元となるドメインに備えられるQoSサーバにより，
カスタマから前記複数ドメインにまたがる，自ドメインが始点となる方向である上り方向のQoS保証要求を受けた場合に，前記QoS保証用資源要求の宛先アドレスから特定される外部ドメインの資源と，自ドメインの資源が割当可能かどうかを，管理資源情報から判断し，割当可能であれば前記カスタマの要求に対して資源確保が可能であることの通知を返す，
ことを特徴とするQoS保証方法。
【０１３６】
（付記７）
付記１において，
前記QoS保証用資源要求元となるドメインに備えられるQoSサーバにより，
カスタマから複数ドメインにまたがる自ドメインが終点となる方向である下り方向のQoS保証要求を受けた場合に，前記QoS保証用資源要求の宛先アドレスから特定される終点ドメインのQoSサーバに対し，要求メッセージを転送し，
前記要求メッセージに対する応答が資源確保が可能であれば，前記カスタマに資源確保が可能であることの通知を返す，
ことを特徴とするQoS保証方法。
【０１３７】
（付記８）
請求項２において，
前記複数のドメインにまたがる経路上の中間にあるQoSサーバにより， 
他ドメインのQoSサーバからカスタマからの資源要求メッセージを転送された場合に，前記資源要求メッセージの要求元アドレスから特定される外部ドメインの資源と，自ドメインの資源が割当可能かどうかを，管理資源情報から判断し，
割当可能であれば要求元のQoSサーバに対して資源確保が可能であることの通知を返す，
ことを特徴とするQoS保証方法。
【０１３８】
（付記９）
付記１において，
前記QoS保証用資源要求元となるドメインに備えられるQoSサーバにより，
カスタマから複数ドメインにまたがる双方向のQoS保証要求を受けた場合に，前記双方向のQoS保証要求の宛先アドレスから特定される終点ドメインのQoSサーバに対し，前記双方向のQoS保証要求メッセージを転送し，
前記双方向のQoS保証要求メッセージに対する応答が資源確保が可能であり，かつ前記双方向のQoS保証要求の宛先アドレスから特定される外部ドメインの資源と，自ドメインの資源が割当可能かどうかを，管理資源情報から判断し，
割当可能であれば，前記カスタマの要求に対して資源確保が可能であることの通知を返す，
ことを特徴とするQoS保証方法。
【０１３９】
（付記１０）
付記１において，
前記QoS保証用資源要求元となるドメインに備えられるQoSサーバにより，
管理している宛先ネットワークまでの他ドメイン資源が閾値よりも多い状態が一定時間以上続いた場合に，QoS保証用資源を一定量解放する解放要求メッセージを生成し，
前記宛先ネットワークから特定される次ドメインのQoSサーバに解放要求メッセージを転送し，
前記QoSサーバに解放要求メッセージの応答結果が資源確保が可能であれば管理している他ドメイン資源の更新を行う，
ことを特徴とするQoS保証方法。
【０１４０】
（付記１１）
付記１において，
前記管理している宛先ネットワークまでの他ドメイン資源が閾値よりも少ない状態が一定時間以上続いた場合には，QoS保証用資源を一定量要求するメッセージを生成し，
宛先ネットワークから特定される次ドメインのQoSサーバに前記生成したメッセージを転送し，
前記メッセージに対する応答結果が資源確保が可能であれば管理している他ドメイン資源の更新を行う，
ことを特徴とするQoS保証方法。
【０１４１】
（付記１２）
複数のドメインにまたがるネットワーク経路に配置されるドメイン間連携QoSサーバであって，
送信元なるドメインに付属するドメイン間連携QoSサーバとして，
QoS保証用資源要求メッセージを生成し，前記生成されたQoS保証用資源要求メッセージを経路上の次のドメインを管理するQoSサーバに送るドメイン間連携機能部と，
前記QoS保証用資源要求メッセージに対し，前記経路上の全てのドメインでQoS保証用資源要求に対する結果が資源確保が可能であるとき，得られたQoS保証のための，次ドメインから宛先ネットワークアドレスが属するドメインまでの経路上の資源を管理する資源管理機能部を有する，
ことを特徴とするドメイン間連携QoSサーバ。
【０１４２】
（付記１３）
複数のドメインにまたがるネットワーク経路に配置されるドメイン間連携QoSサーバであって，
前記複数のドメインにまたがる経路上の中間にあるQoSサーバとして，
送信元なるドメインに付属するドメイン間連携QoSサーバからのQoS保証用資源要求を受けるドメイン間連携機能部を有し，
前記ドメイン間連携機能部は，前記QoS保証用資源要求に含まれる宛先ネットワーク情報から次ドメインにまたがる要求であるか否かを判定し，
次ドメインにまたがる要求であると判定されるとき，次ドメインのQoSサーバを特定し，
さらに自ドメインの次ドメインに接続するゲートウェイアドレスを特定し，
前記要求メッセージにゲートウェイアドレスを付加して前記次ドメインのQoSサーバに対してメッセージを転送する
ことを特徴とするドメイン間連携QoSサーバ。
【０１４３】
（付記１４）
付記１３において，
前記複数のドメインにまたがる経路上の中間にあるQoSサーバとして，
さらに自ドメインで要求を満たすQoS保証用資源が割り当てられることを確認し
前記転送したメッセージに対する応答が資源確保が可能であるとき，前段のドメインにある前記QoS保証用資源要求の送信元QoSサーバに対して資源確保が可能であることの通知を返す
ことを特徴とするドメイン間連携QoSサーバ。
【０１４４】
（付記１５）
複数のドメインにまたがるネットワーク経路に配置されるドメイン間連携QoSサーバであって，
前記複数のドメインにまたがる経路上の終端のドメインにあるQoSサーバとして，
送信元なるドメインに付属するドメイン間連携QoSサーバからのQoS保証用資源要求を受け，宛先ネットワークが自ドメインに属することから自ドメインが終点であることを確定し，
さらに自ドメインで要求を満たすQoS保証用資源が割り当てられることを確認した場合，前記QoS保証用資源要求を転送してきた前段のドメインのQoSサーバに対して資源確保が可能であることの通知を返す，
ことを特徴とするドメイン間連携QoSサーバ。
【０１４５】
（付記１６）
付記１４において，
さらに，前記複数ドメインにまたがる経路でのQoS保証用資源要求を受け，
前記QoS保証用資源要求に含まれる宛先ネットワークと前段のドメインのゲートウェイアドレスから，自ドメイン内の区間を特定し，特定した区間の資源が要求に対して割り当て可能であれば，前記要求元ドメインに対して必要な量の前記区間の資源を割り当てる，
ことを特徴とするドメイン間連携QoSサーバ。
【０１４６】
（付記１７）
付記１２において，
カスタマから前記複数ドメインにまたがる，自ドメインが始点となる方向である上り方向のQoS保証要求を受けた場合に，前記QoS保証用資源要求の宛先アドレスから特定される外部ドメインの資源と，自ドメインの資源が割当可能かどうかを，管理資源情報から判断し，割当可能であれば前記カスタマの要求に対して資源確保が可能であることの通知を返す，
ことを特徴とするドメイン間連携QoSサーバ。
【０１４７】
（付記１８）
付記１２において，
カスタマから複数ドメインにまたがる自ドメインが終点となる方向である下り方向のQoS保証要求を受けた場合に，前記QoS保証用資源要求の宛先アドレスから特定される終点ドメインのQoSサーバに対し，要求メッセージを転送し，
前記要求メッセージに対する応答が資源確保が可能であれば，前記カスタマに資源確保が可能であることの通知を返す，
ことを特徴とするドメイン間連携QoSサーバ。
【０１４８】
（付記１９）
付記１３において，
他ドメインのQoSサーバからカスタマからの資源要求メッセージを転送された場合に，前記資源要求メッセージの要求元アドレスから特定される外部ドメインの資源と，自ドメインの資源が割当可能かどうかを，管理資源情報から判断し，
割当可能であれば要求元のQoSサーバに対して資源確保が可能であることの通知を返す，
ことを特徴とするQoS保証方法。
【０１４９】
（付記２０）
付記１２において，
カスタマから複数ドメインにまたがる双方向のQoS保証要求を受けた場合に，前記双方向のQoS保証要求の宛先アドレスから特定される終点ドメインのQoSサーバに対し，前記双方向のQoS保証要求メッセージを転送し，
前記双方向のQoS保証要求メッセージに対する応答が資源確保が可能であり，かつ前記双方向のQoS保証要求の宛先アドレスから特定される外部ドメインの資源と，自ドメインの資源が割当可能かどうかを，管理資源情報から判断し，
割当可能であれば，前記カスタマの要求に対して資源確保が可能であることの通知を返す，
ことを特徴とするドメイン間連携QoSサーバ。
【０１５０】
（付記２１）
付記１２において，
管理している宛先ネットワークまでの他ドメイン資源が閾値よりも多い状態が一定時間以上続いた場合に，QoS保証用資源を一定量解放する解放要求メッセージを生成し，
前記宛先ネットワークから特定される次ドメインのQoSサーバに解放要求メッセージを転送し，
前記QoSサーバに解放要求メッセージの応答結果が資源確保が可能であれば管理している他ドメイン資源の更新を行う，
ことを特徴とするドメイン間連携QoSサーバ。
【０１５１】
（付記２２）
付記１２において，
前記管理している宛先ネットワークまでの他ドメイン資源が閾値よりも少ない状態が一定時間以上続いた場合には，QoS保証用資源を一定量要求するメッセージを生成し，
宛先ネットワークから特定される次ドメインのQoSサーバに前記生成したメッセージを転送し，
前記メッセージに対する応答結果が資源確保が可能であれば管理している他ドメイン資源の更新を行う，
ことを特徴とするドメイン間連携QoSサーバ。
【産業上の利用可能性】
【０１５２】
実施例について，説明したように，本発明により大規模なマルチドメインネットワークにおいて，カスタマからの要求にすばやく応答でき，使用状況にあった資源利用をしつつエンドツーエンドでの品質保証通信を可能とする。よって，ネットワークの効率的な運用を可能とし，産業上寄与するところ大である。
【図面の簡単な説明】
【０１５３】
【図１】第１の従来技術を説明する図である。
【図２】第２の従来技術を説明する図である。
【図３】第３の従来技術を説明する図である。
【図４】第４の従来技術を説明する図である。
【図５】本発明の実施例１のネットワーク構成を示す図である。
【図６】ドメイン間連携QoSサーバ３Ａ，３Ｂ，３Ｃの機能ブロックである。
【図７Ａ】自ドメイン資源３４の管理テーブルの状態を示す図である。
【図７Ｂ】他ドメイン資源３５の管理テーブルの状態を示す図である。
【図８】ドメイン間連携QoSサーバ３ＡにおけるQoS補償のための資源要求メッセージ生成処理のフロー図である。
【図９】ドメインＡ，Ｂ，Ｃ間のシーケンスフローである。
【図１０】ドメイン間連携QoSサーバ３Ａで保持しているメッセージ生成に必要な情報を説明する図である。
【図１１Ａ】QoS保証用資源要求メッセージのフォーマットの例を示す図である。
【図１１Ｂ】図１１Ａのフォーマットに従って生成されたドメイン間連携QoSサーバ３Ａにより生成された資源要求メッセージの内容を示す図である。
【図１１Ｃ】ドメイン間連携QoSサーバ３Ｂが転送するメッセージの内容を示す図である。
【図１２】ドメインＢのドメイン間連携QoSサーバ３Ｂで保持している帯域情報を湿す図である。
【図１３Ａ】ドメイン間QoSサーバ３Ｂにおいて，QoS保証のための資源要求メッセージを受信したときの上記処理（処理工程Ｐ３〜Ｐ７）における詳細動作フローを示す図である。
【図１３Ｂ】図１３Ａのフローにおけるメッセージ転送処理の内容は，図１３Ｂに示す処理フローを示す図である。
【図１４】ドメインＡのカスタマ１００ａから，送信先１０１に属する端末への１Ｍbpsの帯域保証通信要求に対する処理シーケンスである。
【図１５Ａ】自ドメイン資源３４の内容を示す図である。
【図１５Ｂ】送信先１０１間での区間の帯域情報である他ドメイン資源３５の内容を示す図である。
【図１６】実施例２ネットワークを示す図である。
【図１７】帯域保証通信を要求に対して事前に処理された図１６のネットワークにおける状態を示す図である。
【図１８】図１６のネットワークにおいて，ルータＲ3からネットワーク１００Ｃ，１００Ｄへの資源の残り帯域は１Ｍbpsになっている状態を示す図である。
【図１９】カスタマから下り方向のフローの帯域保証要求を受けたケースについてシーケンスを示す図である。
【図２０】双方向通信の場合の資源割り当て処理を説明するシーケンスフローを示す図である。
【図２１】資源の追加及び解放決定判断を行う処理の例を示すフロー図である。
【図２２】図２１の判断フローにより資源解放の要求が判定された場合の資源解放メッセージ生成処理フローである。
【図２３Ａ】解放要求メッセージフォーマットの例を示す図である。
【図２３Ｂ】解放要求転送メッセージフォーマットにおいて，解放要求メッセージのゲートウェイアドレスを書き換えた状態を示す図である。
【図２４Ａ】解放要求を受けるときのドメイン間連携QoSサーバ３Ｂにおける処理のフローを示す図である。
【図２４Ｂ】図２４Ａの処理における転送処理（ステップＳ４５５）の詳細を説明する図である。
【符号の説明】
【０１５４】
１００ａ  カスタマ
３Ａ，３Ｂ，３Ｃ  ドメイン間連携QoSサーバ
ＥＲ1, ＥＲ2,ＥＲ3 エッジルータ
ＧＷ1,ＧＷ2, ＧＷ3 ゲートウエイ
１００  送信元
１０１  送信先
３０  カスタマ要求受付機能部
３１  資源管理機能部
３１ａ  自ドメインQoS資源管理機能部
３１ｂ  他ドメインQoS資源管理機能部
３２  自ドメイン経路管理機能部
３３  ドメイン間連携機能部
３４  自ドメイン資源
３５  他ドメイン資源
【図１】
0004571080.tif 000002
【図２】
0004571080.tif 000003
【図３】
0004571080.tif 000004
【図４】
0004571080.tif 000005
【図５】
0004571080.tif 000006
【図６】
0004571080.tif 000007
【図７Ａ】
0004571080.tif 000008
【図７Ｂ】
0004571080.tif 000009
【図８】
0004571080.tif 000010
【図９】
0004571080.tif 000011
【図１０】
0004571080.tif 000012
【図１１Ａ】
0004571080.tif 000013
【図１１Ｂ】
0004571080.tif 000014
【図１１Ｃ】
0004571080.tif 000015
【図１２】
0004571080.tif 000016
【図１３Ａ】
0004571080.tif 000017
【図１３Ｂ】
0004571080.tif 000018
【図１４】
0004571080.tif 000019
【図１５Ａ】
0004571080.tif 000020
【図１５Ｂ】
0004571080.tif 000021
【図１６】
0004571080.tif 000022
【図１７】
0004571080.tif 000023
【図１８】
0004571080.tif 000024
【図１９】
0004571080.tif 000025
【図２０】
0004571080.tif 000026
【図２１】
0004571080.tif 000027
【図２２】
0004571080.tif 000028
【図２３Ａ】
0004571080.tif 000029
【図２３Ｂ】
0004571080.tif 000030
【図２４Ａ】
0004571080.tif 000031
【図２４Ｂ】
0004571080.tif 000032