JP3977331B2 - Ｉｐ通信網における方法及び装置 - Google Patents

Description

本発明は、ＩＰ通信網における方法及び装置に関する。特に、ＩＰパケットの幾つかのストリームに関する所定の端点間サービス品質（ＱｏＳ；Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を入手するリソースの留保に関する。

インターネットは、ＩＥＴＦ（インターネット特別技術調査委員会）により標準化されたインターネットプロトコル（ＩＰ）に基づくものである。ＩＰプロトコルを有する幾つかの初期目標は、異種の物理的通信網を一つの大型の仮想通信網へ相互接続し、広範なアプリケーションをサポートする均一な基盤を提供することにある。これらの目標に到達する途方もない成功に向けた幾つかの技術的な理由は、下記の通りである。
＊ステートレスパケット伝送：ＩＰデータグラム伝送は、アプリケーションデータストリームに関してステートレスである。伝送は、宛先アドレス接頭語のテーブルにより実行される。
＊動的で規模拡張可能な経路選択：解放最短信号路優先（ＯＳＰＦ；Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ）や境界ゲートウェイプロトコル（ＢＧＰ；Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）等の分散させた動的なドメイン内及びドメイン間経路選択プロトコルにより設定される。これらの経路選択プロトコルは通信網の機能不全を自動的に検出し、新たなルートを立ち上げて機能不全を避ける。ドメイン間経路選択は、通信網アドレス接頭語の寄せ集めが故に宛先経路選択シンクツリーへ良好に規模拡張される。

ＩＰは、異なるトラヒック流が通信網リソースを等しく共有する箇所の通信網内で用いられるよう設計してある。これは、受信したＱｏＳが通信網内の現在の負荷に依存することを意味する。

現在、インターネットは、光ファイバから無線に及ぶリンク技術の点で、また実時間対話から非同期バルクデータ伝送に至るアプリケーションサービス要求の点で、またビジネスの重要な用途から無構成家庭娯楽に亙るユーザ要求の点で、より異質なものとなっている。この展開が、通信網内のサービス細分化の必要性を駆り立てている。ＱｏＳメカニズム上の要件は、前述のステートレスパケット伝送と規模拡張可能な寄せ集めの基本原理に従って展開させねばならない点にある。

以下、ＩＰ通信網内のＱｏＳの最新の技術水準について説明する。

統合サービス（ＩｎｔＳｅｒｖ；Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅ）／リソース保留プロトコル（ＲＳＶＰ；Ｒｅｓｏｕｒｃｅ ＲｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）
ＩｎｔＳｅｒｖアーキテクチャ及びＲＳＶＰは、個々のアプリケーションデータストリームについて端点間ＱｏＳ保証をもたらす送信アーキテクチャである。この解決策は、信号路に沿うルータ内のフロー状態の複雑なパケット分類ごとの価格を保証するきめ細かなサービスを提供する。ＲＳＶＰに関しては、集合器と分離器の間に寄せ集めトンネルを組み立てる提案が存在する。これはより規模拡張性があるが、それは依然として端部ルータ対間に寄せ集めトンネルが確立されたモデルである。これらの端部ルータは、標準的なＩｎｔＳｅｒｖ／ＲＳＶＰルータと少なくとも同じ複雑さを蒙ることになる。通信網ポリシー管理に関しては、ＲＳＶＰはポリシーサーバに依存する。

細分化サービス（ＤｉｆｆＳｅｒｖ；Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅ）
ＤｉｆｆＳｅｒｖアーキテクチャは、等級準拠伝送向けにルータのサポートを標準化するものである。コアルータ内のＤｉｆｆＳｅｒｖ伝送は、アプリケーションデータストリームについてステートレスである。ドメイン境界におけるトラヒック条件は、過負荷に対してドメインを保護するのに用いられる。ＤｉｆｆＳｅｒｖの課題は、広範なアプリケーションに対するＱｏＳ要求に応えることにある。様々なトラヒック分類に関するリソース（帯域）は準静的に支給し、期待されるサービス特性ならびに想定した用途統計に従った大きさとすることができる。しかしながら、支給を介してのみ予測可能なサービスレベルをもたらすため、リソースは過剰に支給しなければならない。このことは、同質のアプリケーション及びユーザ要求を有する同質の通信網において可能となろう。広く異なる特性をもったリンクを相互接続した箇所の実際の通信網（例えば、光ファイバアクセスや無線アクセス）と、全てのホップにて過剰支給する様々な要求をもったアプリケーション／ユーザは、大変な難題である。異種環境内で予測可能なサービスを提供するため、ＤｉｆｆＳｅｒｖはサービス品質と支給リソースの用途を制御するのに動的な通信網リソース管理（ＮＲＭ；Ｎｅｔｗｏｒｋ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ）に頼らねばならない。規模拡張要求に応えるため、リソース管理はリソース要求の寄せ集めをサポートしなければならない。

複数プロトコルラベル交換（ＭＰＬＳ；Ｍｕｌｔｉ−ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）
ＭＰＬＳは、従来のＩＰ通信網層経路選択とラベル交換伝送付き制御プロトコルを拡張する一方法である。ＭＰＬＳは、ＩＰ通信網に接続指向交換をもたらす。ラベルは、（伝送等価クラス（ＦＥＣ；Ｆｏｒｗａｒｄｉｎｇ Ｅｑｕｉｖａｌｅｎｃｅ Ｃｌａｓｓｅｓ）として公知の）特定のデータストリームデータに関連付けられる。ラベルとそれらのＦＥＣ拘束体は通信網すなわちＭＰＬＳドメインの端から端まで分配され、ラベル交換路を確立する。ドメインへ進入すると、パケットは１以上のラベル（ラベルスタック）を割り当てられる。ドメインを通過すると、パケットはラベルに基づいて伝送される。ＭＰＬＳは、特定のラベル交換路へリソースを割り当てることでＱｏＳを供給するのに用いることができる。ＭＰＬＳは、個々のラベル交換ドメイン内でのみ動作する。ドメイン間リソース留保は、現在サポートされていない。

上記のどの方法も、ドメイン間リソース支給に追加のサポートが必要である。これは、サーバ準拠アーキテクチャによりもたらすことができる。ＲＳＶＰに関しては、ポリシーサーバのアーキテクチャが提案されている。ＤｉｆｆＳｅｒｖに関しては、ＱｏＳエージェントと帯域ブローカーが提案されている。ＭＰＬＳに関しては、ＭＰＬＳのセマンティクスを理解するＱｏＳエージェントを用いることもできる。

シェレン・オー（Ｓｃｈｅｌｅｎ， Ｏ）著、「インターネット内サービス品質エージェント」、博士論文、コンピュータ科学及び電気工学科、コンピュータ通信学部、ルーレオ（Ｌｕｌｅａ）工業大学、ルーレオ市（Ｌｕｌｅａ）、１９９８年には、通信網リソースマネージャ（ＮＲＭ；Ｎｅｔｗｏｒｋ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｒ）が紹介されている。ＮＲＭは、前記したメカニズム上で独立して或いはそれらと協働するかのいずれかでドメイン間リソース支給及び呼び出し承認制御をもたらすことができる。とりわけ、細分化伝送とＮＲＭの組み合わせが、前述したステートレス伝送及びドメイン間寄せ集めの基本線に沿って動作する。ＮＲＭは、信号路感応承認制御と、時間軸上でのリソースのスケジューリングと、即使用及び将来の使用に対するリソース要求の処理能力と、リソースマネージャエンティティ間のリソース送信（すなわち、ドメイン間通信）とアドレス接頭語により特定された宛先ドメイン向けのリソース要求の寄せ集めを有する。ＮＲＭは通信網の接続形態と特性を知っており、かくして接続形態に基づいて経路選択ドメイン内に存在するリソースの追尾を維持する。通信網内の各ドメインごとに、承認制御に責任を負うＮＲＭが存在する。ＮＲＭの例は、その固有のドメイン内での承認制御を実行し、他の宛先に関する隣接ＮＲＭをもったリソースを留保することができる。それ故、ＮＲＭは予測可能なＱｏＳを提供することができる。

漏斗概念（ｆｕｎｎｅｌ ｃｏｎｃｅｐｔ）は、シェレン（Ｓｃｈｅｌｅｎ）においても紹介されている。漏斗概念は、リソース要求の寄せ集めの規模拡張可能なモデルである。漏斗概念はＮＲＭを用いており、ＮＲＭは他のＮＲＭにリソースを請求する。異なる送信元から同一宛先への留保は、それらが信号路に沿って統合する箇所で寄せ集められ、かくして各ＮＲＭはそれらの隣接エージェントをもった宛先ドメインごとにせいぜい一つの留保を有する。宛先点が位置する箇所のドメインを担当するＮＲＭは、その点に関する受信留保要求を概括してそのドメイン内の任意の端点を網羅する。図１は、リソース要求が宛先ドメインへ向けて寄せ集める仕方を示すものである。図１は、４個のドメインＡ，Ｂ，Ｃ，Ｄからなる通信網１００である。各ドメインは、ＮＲＭａ，ｂ，ｃ，ｄを有する。Ｄｘ，Ｄｙ，Ｄｚは、無線アクセス通信網内の小通信網又は基地局コントローラとなろう。ＮＲＭａとＮＲＭｂは、ドメインＤ内のリソースを必要とする。すなわち、Ｄｙ向けのＮＲＭａとＤｘ向けのＮＲＭｂである。ＮＲＭが通信網接続形態を知っているお陰で、それらはパケットをドメインＣを介して伝送しなければならないことを知っている。本例では、ＮＲＭａは２０個のリソースユニット要求のＮＲＭｃへの伝送１０９を行ない、ＮＲＭｂは１０個のリソースユニット要求のＮＲＭｃへの伝送１１１を行なう。ＮＲＭｃはそれ自体のドメイン用にドメインＤ内に１０個のリソースユニットを必要としており、それ故にＮＲＭｄに対し４０個のリソースユニット要求を送信する。そこで、ＮＲＭｄはＮＲＭｃへ４０個のリソースユニットがドメインＤ内で留保されたという確認の伝送１１４を行ない、ＮＲＭｃはさらにＮＲＭａへ一つの確認の伝送１１０を行ない、一つの確認のＮＲＭｂへの伝送１１２を行なう。留保を用いるパケットはアプリケーション或いは端部ルータにより注目され、取り締まり点によって検査及び／又は論評を受ける。これは、許容されたＱｏＳ分類のみを伴なうパケットが留保された信号路を利用することを保証するためである。

漏斗概念では、宛先ドメインが良好に支給されるか或いは別のメカニズムを用いて宛先ドメイン内にＱｏＳを保証することが想定される。大規模通信網では、端点までの全ての道程に前述の漏斗概念を用いることは好ましくなく、何故ならそれは十分な規模拡張性をもたないだろうからである。その代わりに、漏斗は適当な大きさの宛先ドメイン（例えば、サブネット）に到達するのに用いられる。宛先ドメイン内では、信号路の最終部分についてリソースは一切留保されていない。それ故、漏斗概念はそれ自体、宛先ドメインが支給不足であるかどうかのＱｏＳを端点間すなわち送信元端点から宛先端点へ供給しない。しかしながら、良好に支給された宛先ドメインへ接続されていない宛先が存在する。この種のドメイン上の一例は無線アクセス通信網であり、ここでは最終ホップすなわち基地局と端末の間は隘路リンクとなる。ホストが移動端末であるとき、他の問題が生ずる。ＱｏＳメカニズムは、無線アクセス通信網内の基地局間のハンドオーバにてＱｏＳの素早い局所的再計算を可能にしなければならない。

目的に関する課題は、留保リソースに関する規模拡張可能な解決策を提供して異質のＩＰ通信網内に予測可能な端点間ＱｏＳを入手することにある。

この課題は請求項１の特徴を有するＩＰ通信網と請求項１６の特徴を有する通信網リソースマネージャ（ＮＲＭ）により解決される。この課題はまた、請求項２７の特徴を有する方法と請求項４２及び４４の特徴を有するコンピュータプログラム製品によっても解決される。

第２のＮＲＭが第１のＮＲＭへの宛先のドメイン属性ラベルを表明するステップ及び、
第１のＮＲＭと第２のＮＲＭが、表明されたドメイン属性ラベルに従って送信元端末と宛先端末の間の所定のＱｏＳを備えるＩＰパケットを伝送する適当な動作を個々に実行するステップ、
を含む本発明が提供するＩＰ通信網に実装する方法が、
異質のＩＰ通信網内の予測可能な端点間ＱｏＳを入手すべくリソースの留保を可能にする。

ＩＰ通信網であって、第２のＮＲＭが第１のＮＲＭに対し宛先ドメインのドメイン属性ラベルを表明する手段を備え、第１のＮＲＭと第２のＮＲＭが表明されたドメイン属性ラベルに従って送信元端末と宛先端末の間の所定のＱｏＳを用いてＩＰパケットを伝送し、異質なＩＰ通信網内で予測可能な端点間ＱｏＳを入手すべくリソースの留保を可能にするものである。

本発明の利点は、ＮＲＭ信号路ベクトルが要求された宛先ドメインと信号路沿いのＮＲＭ内でＮＲＭを特定するツールとして機能する点にある。

本発明の別の利点は、ＮＲＭ信号路ベクトルが端点へ向かう信号路沿いの妨害と機能不全を検出するツールをもたらす点にある。

さらに別の利点は、本発明が異なる特性をもった宛先ドメインどうしを識別するツールを提供することにある。

さらに別の利点は、本発明が支給不足宛先ドメインを備えた通信網内で漏斗モデルの規模拡張可能な属性を利用できる点にある。

図２は、本発明の第１実施形態になるＩＰ通信網２００を示す。通信網２００は、第１のドメインＥと第２のドメインＦを備える、ドメインはＩＰ通信網の論理部分であり、その分割は管理上の理由からなされる。ドメインは、経路選択ドメインを参照する本発明内にある。

ドメインＥは、ルータ２０１と通信網リソースマネージャ（ＮＲＭ）ｅとサーバ２１０と端末２０７を構成する小通信網２０８を備える。図２に記載した実施形態では、ドメインＥが送信元ドメインとなろう。或いは送信元ドメインは、宛先ドメインＦへ到達すべくドメインＥを介してパケットを伝送する第３のドメインでもよい。送信者の端末が位置するドメインを、送信元ドメインと呼ぶ。

宛先ドメインＦ及びは、サーバ２１１とルータ２０２とＮＲＭｆと小通信網２０３と小通信網２０３のうち一つの端点を備える。端点が配置されたドメインを、宛先ドメインと呼ぶ。

各小通信網２０３，２０８はさらに、少なくとも一つの端末２０４，２０７を備える。各端末２０４には、小通信網２０３，２０８により動的或いは静的ＩＰアドレスが割り当ててある。パケット送信対象と意図した端末２０４を、端点と呼ぶ。小通信網２０３，２０８は例示的にはＬＡＮであり、それは少なくとも一つのゲートウェイか、少なくとも一つのサーバ及び少なくとも一つの端末か、或いは少なくとも一つの無線通信網コントローラ（ＲＮＣ）と少なくとも一つの基地局（ＢＳ）と少なくとも一つの移動端末を備える無線通信網を含む。端末２０４，２０７は、好ましくは有線通信網内のＰＣかＩＰ電話か或いは移動電話か無線通信網内のラップトップとなろう。

ルータ２０１，２０２はそれぞれ、、異なる通信網２０３，２０８、例えば端末を含む異なるＬＡＮへ相互接続２０６，２１２，２０９を果たしている。ＮＲＭｅ，ＮＲＭｆは、例えばリソースを留保するコンピュータプログラムを含み、例えば個別サーバ２１０，２１１内か或いはさもなくば個別ルータ２０１，２０２内に実装することができる。サーバが実質的にはデータを記憶し計算するためのデバイスであるのに対し、ルータは主にＩＰパケットを経路選択するものである。

ＮＲＭは、「背景技術」以下に前記した特徴、例えば宛先ドメイン内でＮＲＭへ全て通ずる漏斗概念を用いることで承認制御とドメイン間通信２０５，２１０とリソース要求の寄せ集めを有する。ＮＲＭはさらに、適当な宛先アドレス接頭語を表明することで宛先アドレス接頭語に責任を負い、本発明のラベルに従ってドメイン属性ラベルを用いてこれらの宛先にラベルを付す。各ドメインをドメイン属性ラベルを用いて分類することで、リソースの利用可能性、例えば帯域等の異なる特性をもってドメインどうしを分離することが可能である。ドメイン内の端点に対するＱｏＳを入手すべく、ドメイン属性ラベルにはこのドメイン内でどの方法を使用するかに関する情報が含まれる。漏斗概念は宛先ドメイン内のＮＲＭへ全て通ずる規模拡張可能な仕方でもってリソースを留保するよう良好に機能するが、残るのはＮＲＭから宛先ドメイン内端点への道である。それ故、特に関心がもたれるのは属性、すなちわ宛先ドメインのドメイン属性ラベルである。リソース要求を受信し終えた宛先ドメインＦ内のＮＲＭｆは、（要求が許可されることが前提ではあるが）確認メッセージをＮＲＭｅと場合によっては要求内に含まれる他のユニットへ伝送する。確認メッセージは、相当量のリソースが留保され、それによって要求されたＱｏＳが宛先ＮＲＭＦに対し実現できることを通知する。ドメイン属性ラベルは確認メッセージへ付加されるか、或いは別個のメッセージにて送信することができる。ドメイン属性ラベルを読み取ることで、ＮＲＭと場合によっては要求内に含まれる他のユニットはそれらがリソースの留保を要求されたか否かを通知する。宛先ドメインが支給不足であるが故にリソースを留保しなければならない場合、ドメイン属性ラベルはリソース留保を如何に処理すべきか通知する。

ドメイン属性ラベル
ドメイン属性ラベルは、ドメイン属性ラベルフィールド内に規定してある。ラベルフィールドは例えば１６ビットで構成され、ＮＲＭ間で伝送されるデータの一部となろう。ラベルフィールドにより、多数のドメイン属性が規定される。ＮＲＭは伝送制御プロトコル（ＴＣＰ；Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）上でアプリケーションプロトコルと通信し、アプリケーションプロトコルがドメイン特性ラベルフィールドを規定している。この情報は通常の進路へ経路選択され、ドメイン属性ラベルの伝送用に事前留保されたリソースが存在し得る。４種類の属性ラベルの定義は、以下に与えられる。
＊「支給済み」のドメイン属性ラベルは、そのドメインがリソースを良好に支給されていて、ＱｏＳをドメイン内の端点へ供給するのにリソース留保が一切要求されないという情報をもたらすものである。これは、例えば良好に支給されたローカルエリアネットワーク（ＬＡＮ；Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）内に出現する。例えば端末２０７或いはＮＲＭｅ等の要求ユニットが動作を要求することは、一切ない。
＊「用命応答済み」のドメイン属性ラベルは、ドメインが例えば端点やプロキシや無線通信網コントローラ（ＲＮＣ；Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）により呼び出されたＮＲＭを介して局所的に立ち上がっているという情報をもたらす。端点が無線アクセス通信網内に位置する場合、すなわちリソースが局所ＩＰリソースマネージャと協働して無線通信網コントローラ（ＲＮＣ）により処理する場合、ＲＮＣはリソースについて局所ＮＲＭと協議する。ＲＮＣは端末（端点）を制御し、端点間ＱｏＳを要求するサービスを端末が要求した時にこれを知ることになる。
＊「要求済み」のドメイン属性ラベルは、ドメインが要求ユニット、例えば送信端末２０７やＮＲＭやプロキシにより呼び出してＱｏＳをＮＲＭから特定の端点へ拡張することのできるＮＲＭを介してＱｏＳを処理するという情報を提供するものである。ＮＲＭのアドレスは、ＮＲＭ信号路ベクトルを介して既知である。ＮＲＭ信号路ベクトルは、「ＮＲＭ信号路ベクトル」において以下にさらに説明する。
＊「送信済み」のドメイン属性ラベルは、ドメイン内のＱｏＳが送信により処理されたという情報をもたらす。送信エンティティはデータ内で「リソース留保プロトコル（ＲＳＶＰ）」メッセージを伝送していて、受信端末２０４をして宛先ドメイン内でＱｏＳを要求させ、受信エンティティは「ＲＳＶＰ ｒｅｓｖ」メッセージを伝送している。このことは、送信エンティティ（及び受信）を端末２０７としてトラヒックの信号路沿いに配置すべきことを意味している。しかしながら、ＮＲＭｅはこれらのＲＳＶＰメッセージを送ることが出来ず、しかもプロキシを介して宛先へメッセージを伝送すべきことをルータ２０１へ告げなければならない。

上記の４個のドメイン属性ラベルは、異なる特性をもった宛先ドメインどうしを識別できるようにすべく与えられる。ただし、他のドメイン属性ラベルを規定し、説明済みの方法に関連して用いることもできる。

ＮＲＭ信号路ベクトル
通信網リソースマネージャ（ＮＲＭ）信号路ベクトルは本発明に従って導入され、宛先への信号路に沿う通信網リソースマネージャの同定を可能にしている。所与の宛先向けの各漏斗ごとに、ＮＲＭ信号路ベクトルはリソースを許可し終えた一連のＮＲＭを告げる。ＮＲＭ信号路ベクトルは、要請された宛先ドメイン内でＮＲＭを特定する一つのツールである。妨害や機能不全もまたＮＲＭ信号路ベクトルにより検出することができ、例えば要求が妨害された場合、信号路ベクトルは妨害が発生したことを示し、或いはまたＮＲＭがアクセス不能となった場合、前記信号路ベクトルは問題の在る箇所を示す。ＮＲＭ信号路ベクトルは、要求されたラベルに対し用いられる。しかしながら、ＮＲＭ信号路はＮＲＭを識別すべく送信され支給され生成されたラベルに対し用いることができる。

本発明の第２の実施形態になるＩＰ通信網３００が、図３に開示してある。ＩＰ通信網３００は５個の経路選択ドメインＧ，Ｈ，Ｉ，Ｊ，Ｋを備え、ここでは一つのドメインＧが送信元ドメインであり、一つのドメインＩが宛先ドメインとなる。送信元ドメインＧはＮＲＭｇと端末３０１を構成する端点を備え、宛先ドメインＩはＮＲＭｉと宛先ユニット３１１と端点３０２を備える。さらに、中間ドメインＨはＮＲＭｈと端点３１２とデバイス３１３を備え、ドメインＪはＮＲＭｊを備え、ドメインＫはＮＲＭｋを備える。各ＮＲＭは、他のドメイン内の他のＮＲＭ及び端点と通信することができる。図３を参照するに、端末３０１はＩＰパケットへの送信を欲しており、端末３０２に対し所定のＱｏＳを要求している。本例の通信網の接続形態によれば、ＩＰパケットはドメインＨを通過してドメインＩへ到達することを要求している。要求されたＱｏＳを実現するため、本例の場合、１０個のユニットが端末３１０から宛先ドメインＩ内の端点（端末３０２）へ留保される。（要求されたＱｏＳを実現するには、必要量を超えるリソースが要求されもしよう。）リソース量は、遅延及び／又はジッタについて帯域及び／又は要件にて計測することができる。次のステップを、実行する。

端末３０１が先ずＮＲＭｇから１０個のユニットを要求し、続いて
ＮＲＭｇが、ＮＲＭｈから端点３０２へ１０個のユニットの要求３０３をする。
この第２の要求は他のドメインからの他の要求と共に寄せ集められ、例えばドメインＪが５個のユニットに関する要求３０７を、ドメインＨも通過させねばならずしかもその宛先をドメインＩ内或いは例えばドメインＫを越えて有する送信対象データを有するドメインＫ内に位置する端点へ送信する。各ＮＲＭは、宛先ドメインごとに１個だけ或いは数個の留保を備える。例えば、ＱｏＳは例えば遅延やビットレート等の点で異なる分類へ分割されよう。かくして、宛先ドメインごと及びＱｏＳ分類ごとに一つの留保ともし得る。その後、ＮＲＭｇは隣接ＮＲＭｈからのリソースの要求３０３をし、全てがＮＲＭｉへ通ずるリソースを留保する二つの異なる方法を用いることができる。「代案１」は、ＮＲＭｈがドメインＩに対し留保されたリソースを有するときに用いられ、「代案２」はＮＲＭｈがドメインＩに対し事前留保リソースを一切もたないときに用いられる。

代案１：大半の操作では、リソースは第１のＮＲＭにおける宛先ドメインまで完全に許可されるが、それはＮＲＭが割り当て上の目標に従ってリソースの留保ならび時間軸上の要求、例えば一日の内の時間と１週間の内の日にちに関する要求についての発見的教授法を実行できるからである。要求は、かくして宛先ドメイン内のＮＲＭｉへ全て通ずるリソースに関する第１のＮＲＭｈにより直接許可されよう。
確認メッセージは、例えばＮＲＭｈからＮＲＭｇ及びＮＲＭｈからＮＲＭｊへの各リソース協議３０８の後に、隣接ＮＲＭによる送信３０４に処される。
ＮＲＭｈとＮＲＭｉは、ベクトルを更新すべく、それらの固有の個体情報、例えばそれらのＩＰアドレスをＮＲＭ信号路ベクトルへ付加する。
ＮＲＭ信号路ベクトルは、確認メッセージに含まれる。
ＮＲＭｈは、ドメインＩからＮＲＭｇへドメイン属性ラベルを表明する。ドメインＩに対するリソースの事前留保が実行されたときに、ＮＲＭｈはドメインＩのドメイン属性ラベルを受け取る。
端末３０１には、ＮＲＭｇから表明されたドメイン属性ラベルとリソースがドメインＩへ留保されたという確認とが与えられる。

代案２：場合によっては、一切留保が実行されないときに、要求３０３が隣接ＮＲＭ間の要求連鎖を生み出し、リソースを立ち上げよう。そこで、確認は発信元へ向けて伝搬して戻る。確認とは、リソースが確認メッセージに示す如く宛先ドメインへ利用可能となったことを意味するものである。
ＮＲＭｈは、ＮＲＭｉから５＋１０個のユニットの要求３０５をする。
ＮＲＭｉは要求を受け取り、目的地がそのドメイン内に位置することを通知する。
確認メッセージはＮＲＭｉからＮＲＭｈへの送信３０６に処され、そこでＮＲＭｉは１５個のユニットがｈへ留保されたことに応答する。
ＮＲＭｉはＮＲＭ信号路ベクトル内に付加され、ベクトルは確認メッセージ３０６にて送信される。
ＮＲＭｉは、ＮＲＭｈへドメインＩのドメイン属性ラベルを表明する。
確認メッセージはＮＲＭｈからＮＲＭｇへの送信３０４に処され、そこでＮＲＭｈは１０個のユニットがｇへ留保されたことに応答する。
ＮＲＭｈは、ここではＮＲＭｉとＮＲＭｈの固体情報を含むその固有の固体情報をＮＲＭ信号路ベクトルへ付加する。このベクトルは、確認メッセージ３０４に含まれる。
ＮＲＭｈは、ドメイン属性ラベルをＮＲＭｇへ表明する。
端末３０１には、ＮＲＭｇから表明されたドメイン属性ラベルとリソースがドメインＩへ留保されたという確認とが与えられる。

代案１と代案２の実行時には、適切な動作が表明済みドメイン属性ラベルに従って実行される。

ドメイン特性ラベルを支給した場合、
宛先ドメイン内では、リソースが留保されることは一切ない。
ＩＰパケットは、従来の経路選択プロトコルに従って非留保信号路上の端点３０２へ経路を選択される。

ドメイン属性ラベルが用命に応じた場合、
宛先ドメインＩが、ＮＲＭｉを介してＱｏＳセットアップを局所的に処理する。
宛先ユニット３１１は、例えば端点やプロキシや好ましくは無線通信網内の無線通信網コントローラ（ＲＮＣ）であるが、これが宛先ドメイン内のＮＲＭｉを呼び出す。（ＲＮＣは、端末の無線リソースを制御する。）
宛先ユニット３１１は、要求されたリソースについて宛先ＮＲＭと協議する。各宛先ユニット３１１は、その最も局所的なＮＲＭを認識しなければならない。それは、各宛先ユニット３１１を構成することで行なうことができる。

ドメイン特性ラベルが要求された場合、
そこからＩＰパケットが発生する要求ユニット、例えば端点３０１やプロキシやＮＲＭｇがＮＲＭｉを呼び出す。ＱｏＳは、そこでＮＲＭｉを介して処理され、ＱｏＳをさらに特定の端点３０２へ拡張させる。ＮＲＭｉのアドレスは、ＮＲＭ信号路ベクトルを介して要求ユニットにより知れる。

ドメイン属性ラベルが送信された場合、
送信者３０１は「ＲＳＶＰ信号路」メッセージを伝送し、受信者３０２をして端点３０２へＱｏＳを要求させる。
受信者はそこで、「ＲＳＶＰ ｒｅｓｖ」メッセージを伝送して宛先ドメインＩ内にリソースを留保する。

図４は、汎用モードにおける本発明による方法のフローチャートを示す。本方法は、ＩＰ通信網内で実行され、送信元ドメイン内に位置する送信元端末から宛先ドメイン内に存在する宛先端末へＩＰパケットを伝送することを意図したものであり、ここでは送信元ドメインと宛先ドメインはそれぞれＮＲＭを有する。本方法は、次のステップを含む。
ステップ４０１：前記発信元ドメインＥ内に位置する第１のＮＲＭｅが、前記宛先ドメインＦ内に位置する第２のＮＲＭｆからリソースを要求する。
ステップ４０２：ＮＲＭｆが、ベクトルを更新すべくそのＩＤをＮＲＭ信号路ベクトルへ付加する。
ステップ４０３：ＮＲＭｆが、宛先ドメインＦのドメイン属性ラベルを第１のＮＲＭｅへ表明する。
ステップ４０４：ＮＲＭｅ及びＮＲＭｆが、所定の端点間ＱｏＳを用いてＩＰパケットを伝送する適切な動作を実行する。

本方法は、本方法のステップを実行するソフトウェアコード手段を含むコンピュータプログラム製品により実装される。コンピュータプログラム製品は、サーバ或いはルータ内の処理手段上で実行される。コンピュータプログラムは、直接に或いはフロッピーディスクやＣＤやインターネット等のコンピュータが使用可能な媒体からロードされる。

本発明は、上記の好適な実施形態に限定されるものではない。様々な代替例や改変例や均等物を用いることができる。それ故、上記の実施形態は添付特許請求の範囲により規定される本発明範囲を限定するものとして捉えてはならない。

リソース要求を漏斗概念を用いて宛先ドメインへ向け寄せ集める従来技術の一例を示す図である。 本発明になる二つのドメインを備える通信網を示す図である。 本発明になるドメインリ間ソース留保の一例を開示する図である。 本発明になるリソース留保のシーケンス線図を表わす図である。

符号の説明

Ａ，Ｂ，Ｃ，Ｄ ドメイン
Ｄｘ，Ｄｙ，Ｄｚ 基地局コントローラ
１００ 通信網
１０９，１１１，１１２，１１４ 伝送
Ｅ 送信元ドメイン
Ｆ 宛先ドメイン
Ｇ 送信元ドメイン
Ｈ 中間ドメイン
２００ ＩＰ通信網
２０１，２０２ ルータ
２０３，２０８ 小通信網
２０４ 宛先端末
２０７ 送信元端末
２０５ ドメイン間通信
２０６，２１２，２０９ 相互接続
２１０ ドメイン間通信（メッセージ）
２１１ サーバ
３００ ＩＰ通信網
３０１ 端末
３０２，３１２ 端点
３０３，３０５，３０７ 要求
３０４ 送信
３０６ 送信（リソース要求）
３０８ リソース協議
３１０ 端末
３１１ 宛先ユニット
３１２ 終端端末
３１３ デバイス

Claims (45)

1. 送信元ドメイン（Ｅ）と宛先ドメイン（Ｆ）を含む複数のドメインを備えるＩＰ通信網（２００）で、該送信元ドメイン（Ｅ）が送信元端末（２０７）と第１の通信網リソースマネージャ（ＮＲＭ）（ｅ）を備え、前記宛先ドメイン（Ｆ）が宛先端末（２０４）と第２のＮＲＭ（ｆ）を備え、
   前記送信元ドメイン（Ｅ）内の前記送信元端末（２０７）が、前記宛先端末（２０４）に対し所定のＱｏＳを要求するＩＰパケットを送信する手段を備え、
   前記送信元ドメイン（Ｅ）内の第１のＮＲＭ（ｅ）が、前記ＩＰパケットの伝送に十分でかつ前記ＱｏＳを実現することのできる送信元を第２のＮＲＭ（ｆ）から要求する手段を備えるＩＰ通信網（２００）であって、
   前記第２のＮＲＭ（ｆ）が、
   前記宛先ドメイン（Ｆ）のドメイン属性ラベルを前記第１のＮＲＭ（ｅ）へ表明する手段を備え、
   前記第１のＮＲＭ（ｅ）と前記第２のＮＲＭ（Ｉ）がそれぞれ、前記表明されたドメイン属性ラベルに従い前記送信元端末（２０７）と前記宛先端末（２０４）の間の前記ＱｏＳを用いて前記ＩＰパケットを伝送する適切な動作を実行する、
   ことを特徴とするＩＰ通信網（２００）。
2. 前記送信元ドメイン（Ｇ）からの前記ＩＰパケットは一つの中間ドメイン（Ｈ）を介して前記宛先ドメイン（Ｉ）へ伝送し、
   前記中間ドメイン（Ｈ）は隣接するドメイン（Ｇ，Ｉ）内のＮＲＭ（ｇ，ｉ）を用いてドメイン間通信するよう設けた少なくとも一つのＮＲＭ（ｈ）を備える、
   ことを特徴とする請求項１記載のＩＰ通信網（３００）。
3. ＮＲＭ信号路ベクトルを用いて前記宛先ドメイン（Ｆ）内で前記ＮＲＭ（ｆ）を特定する手段を備える、
   ことを特徴とする請求項１又は２記載のＩＰ通信網（２００）。
4. ＮＲＭ信号路ベクトルを用い、前記送信元端末（２０７）から前記端末（２０４）への信号路に沿う前記ＮＲＭ（ｅ，ｆ）を特定する手段を備える、
   ことを特徴とする請求項１乃至３のいずれか１項に記載のＩＰ通信網（２００）。
5. ＮＲＭ信号路ベクトルを用い、前記送信元端末（２０７）から前記終端端末（２０４）までの信号路沿いに妨害及び機能不全の少なくとも１つを検出する手段を備える、
   ことを特徴とする請求項１乃至４のいずれか１項に記載のＩＰ通信網（２００）。
6. 前記第２のＮＲＭ（ｆ）は、その固有の個体情報をＮＲＭ信号路ベクトルへ付加する手段を備える、
   ことを特徴とする請求項１乃至５のいずれか１項に記載のＩＰ通信網（２００）。
7. 前記第２のＮＲＭ（ｆ）は、前記隣接するＮＲＭ（ｅ）へメッセージ（２１０）を送信する手段で、該メッセージ（２１０）が前記ＮＲＭ信号路ベクトルを含む前記手段を備える、
   ことを特徴とする請求項３乃至６のいずれか１項に記載のＩＰ通信網（２００）。
8. ＮＲＭ（ｈ）は、他のドメイン（Ｊ）からの他の要求を前記送信元要求（３０３）に寄せ集める手段を備える、
   ことを特徴とする請求項１乃至７のいずれか１項に記載のＩＰ通信網（３００）。
9. 前記表明された属性ラベルが「支給済み」である場合、適切な動作を実行する前記手段が非留保リソース上でＩＰパケットを伝送する手段を備える、
   ことを特徴とする請求項１乃至８のいずれか１項に記載のＩＰ通信網（２００）。
10. 前記表明された属性ラベルが「用命応答済み」である場合、適切な動作を実行する前記手段が前記宛先ドメイン内でＮＲＭ（ｆ）を呼び出し前記終端端末へのＱｏＳを保証する手段をさらに備える宛先ドメイン内デバイスを備える、
    ことを特徴とする請求項１乃至８のいずれか１項に記載のＩＰ通信網（２００）。
11. 前記デバイスは無線通信網コントローラ（ＲＮＣ）であり、前記終端端末（２０４）は移動端末である、
    ことを特徴とする請求項１０記載のＩＰ通信網（２００）。
12. 前記表明された属性ラベルが「要求済み」である場合、適切な動作を実行する前記手段が他のＮＲＭを呼び出す手段をさらに含む要求デバイスを含み、他のＮＲＭが局所ＮＲＭから特定の目的地ターミナル（２０４）へリソース留保を拡張する手段を含む、
    ことを特徴とする請求項１乃至８のいずれか１項に記載のＩＰ通信網（２００）。
13. 前記要求デバイスは前記元々の要求デバイス（２０７）或いはＮＲＭ（ｅ）である、
    ことを特徴とする請求項１２記載のＩＰ通信網（２００）。
14. 前記ＩＰ通信網（２００）はＮＲＭ信号路ベクトルを用いて前記他のＮＲＭのアドレスを特定する手段を備える、
    ことを特徴とする請求項１２又は１３記載のＩＰ通信網（２００）。
15. 前記表明された属性ラベルが「送信済み」である場合、適切な動作を実行する前記手段が、「リソース留保プロトコル（ＲＳＶＰ；Ｒｅｓｏｕｒｃｅ ＲｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）信号路」メッセージを前記宛先端末（２０４）へ伝送する手段をさらに備える前記送信元端末（２０７）と、宛先ドメイン（Ｆ）内にリソースを留保すべく「ＲＳＶＰ ｒｅｓｖ」メッセージを伝送する手段をさらに備える前記宛先端末２０４を備える、
    ことを特徴とする請求項１乃至８のいずれか１項に記載のＩＰ通信網（２００）。
16. 請求項１乃至１５のいずれか１項に記載のＩＰ通信網（３００）内のドメイン（Ｈ）内通信網リソースマネージャ（ＮＲＭ）ユニット（ｈ）で、第２のドメイン（Ｉ）内に位置する第２のＮＲＭ（ｉ）からリソース要求３０６を受信する手段を備えるＮＲＭユニット（ｈ）であって、
    ドメイン（Ｈ）のドメイン属性ラベルを前記第２のＮＲＭ（ｉ）へ表明する手段と、
    前記表明されたドメイン属性ラベルに従い第１の端点（３１２）と第２の端点（３０２）間の端点間ＱｏＳを提供する適切な動作を実行する手段を備える、
    ことを特徴とするＮＲＭユニット（ｈ）。
17. ＮＲＭ信号路ベクトルを用いて前記第３のドメイン（Ｇ）内の第３のＮＲＭ（ｇ）を特定する手段をさらに備える、
    ことを特徴とする請求項１６記載のＮＲＭユニット（ｈ）。
18. ＮＲＭ信号路ベクトルを用いて第１の端点（３１２）と第３の端点（３０２）の間の信号路沿いの妨害及び機能不全の少なくとも１つを検出する手段をさらに備える、
    ことを特徴とする請求項１６又は１７記載のＮＲＭユニット（ｈ）。
19. その固有の個体情報をＮＲＭ信号路ベクトルへ付加する手段をさらに備える、
    ことを特徴とする請求項１６乃至１８のいずれか１項に記載のＮＲＭユニット（ｈ）。
20. 前記第２のＮＲＭ（ｍ）へメッセージ（３０５）を送信する手段で、該メッセージ（３０５）が前記ＮＲＭ信号路ベクトルからなる前記手段をさらに備える、
    ことを特徴とする請求項１６乃至１９のいずれか１項に記載のＮＲＭユニット（ｈ）。
21. 前記リソース要求（３０６）に他のドメイン（Ｊ）からの他の要求を寄せ集める手段をさらに備える、
    ことを特徴とする請求項１６乃至２０のいずれか１項に記載のＮＲＭユニット（ｈ）。
22. 前記表明された属性ラベルが「用命応答済み」である場合、適切な動作を実行する前記手段は、前記ドメイン（Ｈ）内のデバイス（３１３）からの呼び出しを受信する手段を備え、該呼び出しが前記終端端末（３１２）に対しＱｏＳを保証する前記ＮＲＭ（ｈ）への要求をさらに含む、
    ことを特徴とする請求項１６乃至２１のいずれか１項に記載のＮＲＭユニット。
23. 前記デバイス（３１３）は無線通信網コントローラ（ＲＮＣ）であり、前記終端端末（３１２）は移動端末である、
    ことを特徴とする請求項２２記載のＮＲＭユニット（ｈ）。
24. 前記表明された属性ラベルが「要求済み」である場合、適切な動作を実行する前記手段が要求デバイスからの呼び出しを受信し前記ＮＲＭユニット（ｈ）からのリソース留保を特定の端点（３１２）へ拡張する手段を備える、
    ことを特徴とする請求項１６乃至２１のいずれか１項に記載のＮＲＭユニット（ｈ）。
25. 前記要求デバイスは、ドメイン（Ｉ）又はＮＲＭ（ｉ）内の端点（３０２）である、
    ことを特徴とする請求項２４記載のＮＲＭユニット（ｈ）。
26. そのアドレスが前記ＮＲＭ信号路ベクトルにより特定されるようにする手段をさらに備える、
    ことを特徴とする請求項２４又は２５記載のＮＲＭユニット（ｈ）。
27. 請求項１乃至２６のいずれか１項に記載のＩＰ通信網（２００）内でリソースを留保し、送信元ドメイン（Ｅ）内の送信元端末（２０７）と宛先ドメイン（Ｆ）内の宛先端末（２０４）の間の所定のＱｏＳを入手する方法であって、
    前記送信元ドメイン（Ｅ）内に配置され、前記宛先ドメイン（Ｆ）内に位置する第２のＮＲＭ（ｆ）から前記ＱｏＳを実現するのに必要なリソースを要求する第１の通信網リソースマネージャ（ＮＲＭ）（ｅ）で、前記リソースがさらなるステップを含む前記方法により特徴付けられたＩＰパケット伝送を意図したものであり、該さらなるステップが、
    前記第２のＮＲＭ（ｆ）が前記第１のＮＲＭ（ｅ）への宛先のドメイン属性ラベルを表明するステップと、
    前記第１のＮＲＭ（ｅ）と前記第２のＮＲＭ（ｆ）がそれぞれ、前記表明されたドメイン属性ラベルに従って前記送信元端末（２０７）と前記宛先（２０４）端末の間の前記ＱｏＳを用いて前記ＩＰパケットを伝送する適切な動作を実行するステップを含む、
    ことを特徴とする入手方法。
28. 前記送信元ドメイン（Ｇ）からのＩＰパケットは第３のドメイン（Ｈ）を介して前記宛先ドメイン（Ｉ）へ伝送され、
    前記第３のドメイン（Ｈ）は隣接ドメイン（Ｇ，Ｉ）内のＮＲＭ（ｇ，ｉ）とドメイン間通信するよう設けた少なくとも一つのＮＲＭ（ｈ）を備える、
    ことを特徴とする請求項２７記載の入手方法。
29. ＮＲＭ信号路ベクトルを用い、前記宛先ドメイン（Ｆ）内の前記ＮＲＭ（ｆ）を特定するステップをさらに含む、
    ことを特徴する請求項２７又は２８記載の入手方法。
30. ＮＲＭ信号路ベクトルを用い、前記送信元端末（２０７）から前記終端端末（２０４）への信号路に沿う前記ＮＲＭ（ｅ，ｆ）を特定するステップをさらに含む、
    ことを特徴とする請求項２７乃至２９のいずれか１項に記載の入手方法。
31. ＮＲＭ信号路ベクトルを用い、前記送信元端末（２０７）から前記終端端末（２０４）への信号路に沿う妨害及び機能不全の少なくとも１つを検出するステップをさらに含む、
    ことを特徴とする請求項２７乃至３０のいずれか１項に記載の入手方法。
32. ＮＲＭ（ｆ）の個体情報をＮＲＭ信号路ベクトルへ付加するステップをさらに含む、
    ことを特徴とする請求項２７乃至３１のいずれか１項に記載の入手方法。
33. 隣接ＮＲＭ（ｅ）へメッセージ（２１０）を送信するステップと、
    前記メッセージ（２１０）内に前記ＮＲＭ信号路を包含させるステップをさらに含む、
    ことを特徴とする請求項３２記載の入手方法。
34. 前記ＩＰ通信網（３００）内の別のドメイン（Ｊ）からの他の要求を前記送信元要求（３０３）に寄せ集めるステップをさらに含む、
    ことを特徴とする請求項２７乃至３３のいずれか１項に記載の入手方法。
35. 前記表明された属性ラベルが「支給済み」である場合、前記適切な動作が、
    非留保リソース上でＩＰパケットを伝送するステップを含む、
    ことを特徴とする請求項２７乃至３４のいずれか１項に記載の入手方法。
36. 前記表明された属性ラベルが「用命応答済み」である場合、前記適切な動作が、
    前記宛先ドメイン（Ｆ）内のＮＲＭ（ｆ）を呼び出し、前記終端端末（２０４）に対しＱｏＳを保証するステップを含む、
    ことを特徴とする請求項２７乃至３４のいずれか１項に記載の入手方法。
37. 無線通信網コントローラ（ＲＮＣ）が前記宛先ドメイン（Ｆ）内の前記ＮＲＭ（ｆ）を呼び出して前記終端端末へのＱｏＳを保証し、前記終端端末（２０４）は移動端末である、
    ことを特徴する請求項３６記載の入手方法。
38. 前記表明された属性ラベルが「要求済み」である場合、前記適切な動作が、
    リソース留保を前記他のＮＲＭから特定の宛先端末（２０４）へ拡張する他のＮＲＭを呼び出すステップを含む、
    ことを特徴とする請求項２７乃至３４のいずれか１項に記載の入手方法。
39. 前記元々の要求デバイスすなわちＮＲＭ（ｅ）が前記他のＮＲＭを呼び出す、
    ことを特徴とする請求項３８記載の入手方法。
40. 前記他のＮＲＭのアドレスを特定するＮＲＭ信号路ベクトルを用いるステップをさらに含む、
    ことを特徴とする請求項３８又は３９記載の入手方法。
41. 前記表明された属性ラベルが「送信済み」である場合、前記適切な動作が、
    送信元端末（２０７）が「リソース留保プロトコル（ＲＳＶＰ）信号路」メッセージを前記宛先ドメイン（Ｆ）内の前記宛先端末（２０４）へ伝送するステップと、
    前記宛先端末（２０４）が前記宛先ドメイン（Ｆ）内にリソースを留保すべく「ＲＳＶＰ ｒｅｓｖ」メッセージを伝送するステップを含む、
    ことを特徴とする請求項２７乃至３４のいずれか１項に記載の入手方法。
42. 請求項２７乃至４１のいずれか１項に記載のステップを実行するソフトウェアコード手段を備える、
    ことを特徴とするＩＰ通信網内のサーバ及びルータの少なくとも１つ内の処理手段へ直接搭載可能なコンピュータプログラム製品。
43. 前記処理手段が無線通信網コントローラかプロキシか端末内に位置する、
    ことを特徴とする請求項４２記載のＩＰ通信網内のサーバ及びルータの少なくとも１つ内の処理手段へ直接搭載可能なコンピュータプログラム製品。
44. コンピュータ使用可能な媒体に記憶させたコンピュータプログラム製品であって、
    ＩＰ通信網内の処理手段に請求項２７乃至４１のいずれか１項に記載のステップの実行を制御させる読み取り可能なプログラムを備える、
    ことを特徴とするコンピュータプログラム製品。
45. ＩＰ通信網内のサーバ及びルータの少なくとも１つ内の処理手段を動作させる読み取り可能なプログラムを備える請求項４４記載のコンピュータ使用可能な媒体上に記憶させたコンピュータプログラム製品であって、
    前記処理手段もまた無線通信網コントローラ又はプロキシ或いは端末内に配置してある、
    ことを特徴とするコンピュータプログラム製品。

Images