(57)【要約】データ流れシステムであって、ソース１００は入口エレメント１０２に予約パケットを伝送する。入口エレメント１０２は入力メッセージ通信を監視しデータ流れ情報を収集する。サービス差別化の品質は、異なるデータ流れのデータパケットをマーキングすることによって実現される。入口エレメント１０２は予約パケットを登録しコアルータ１０６に要求を転送する。コアルータ１０６は要求されるサービスレベルおよび利用可能な資源を評価する。この評価に基づいて、コアルータ１０６は受け取ったメッセージを拒絶するか、受け入れるか、または改変して、サービスの要求されるレベルの価格を表示し、予約パケットを転送する。このプロセスは、予約パケットが宛先１１０に到着するまで繰り返され、宛先１１０はソース１００に対して、予約パケットの結果を表すフィードバックメッセージを送る。予約を行った後、ソース１００は周期的なコントロールメッセージを伝送して資源の利用可能性、および流れの経路に関する情報を収集する。
2004508739.tif 000002
【特許請求の範囲】
【請求項１】
ユーザーからユーザーへのデータパケットのサービス送達の価格設定ベース品質のための装置であって、ユーザーはそれぞれ財政的制限、少なくとも１つのサービスプロファイル、アプリケーションニーズをもっており、ユーザー対ユーザーの動的資源予約を行い、そしてデータ送達に関連するデータマーキングを含ませるためのヘッダを持つデータパケットの形式でデータの伝送を行い、ここでデータパケットは該装置を介してユーザーからユーザーへと送達されるものであり、該装置は、
データ伝送帯域幅およびプロセッサ容量を含む動的に割り当てられたネットワーク資源を持つコンピュータネットワークを備え、該コンピュータネットワークは、
複数のノードシステムであって、該複数のノードシステムとともにソースノードシステムおよび動的ノードシステムを持っており、
複数のノードシステムと接続されている複数のエッジエレメントであって、それぞれのノードシステムが少なくとも１つのエッジエレメントに接続するようにされており、および
複数の相互接続されたコアルータであって、該複数の相互接続続されたコアルータは複数のエッジエレメントに接続されて、それぞれのエレメントが少なくとも１つのコアルータに接続されるようにされ、そして複数のノードシステムのそれぞれのノードシステムは経路によってネットワークを介して複数のノードシステムのそれぞれの他のノードシステムに通信可能に接続されている、を備えるネットワーククラウド、を備えており、
該ネットワーク資源はモニタされ、複数の予測可能で動的に割り当て可能なサービスレベルの品質を提供するように構成されており、それぞれのサービスレベルの品質はネットワーク資源の特定の組み合わせを保証しサービスの価格を含んでおり、それぞれのサービスレベルの品質のサービス価格はネットワークを介したデータ伝送の許可を最適化してネットワーク内の渋滞を避けるように設定されており、
これによりネットワークのユーザーは、ネットワークにおいてネットワーククラウドを介して伝送を行うことで、ノードシステムを使って他のノードシステムを使用している他のユーザーにデータを伝送し、ユーザーが彼らのニーズおよび価格支払い能力に応じてサービスレベルの品質を動的に選択することを可能とする装置。
【請求項２】
前記サービスレベルの品質は、
ａ．可変価格および固定品質のサービス、
ｂ．固定価格および固定品質のサービス
ｃ．固定価格および可変品質のサービス、および
ｄ．ハイブリッドサービス
から選択されることを特徴とする、請求項１に記載のデータパケットのサービス送達の価格設定ベース品質のための装置。
【請求項３】
前記サービスレベルの品質はユーザーによって決定されることを特徴とする、請求項２に記載のデータパケットのサービス送達の価格設定ベース品質のための装置。
【請求項４】
もしユーザーがそのユーザーの財源を超えて資源を利用しようとする場合、伝送は少なくとも以下のプロトコルの内の１つによって処理される、
ｉ．伝送を無視する、
ｉｉ．より低いサービスレベルに送る、および
ｉｉｉ．最善の努力を尽くした通信として送る、
を特徴とする、請求項１に記載のデータパケットのサービス送達の価格設定ベース品質のための装置。
【請求項５】
前記ネットワーククラウドを除くすべてのエレメントは無線ノードとして動作するように構成されていることを特徴とする、請求項１に記載のデータパケットのサービス送達の価格設定ベース品質のための装置。
【請求項６】
インターネットは前記コアルータを提供するものであり、前記ユーザーはインターネットによってインターフェースされる端末であることを特徴とする、請求項１に記載のデータパケットのサービス送達の価格設定ベース品質のための装置。
【請求項７】
前記ネットワークはイントラネットであり、財政的制限は少なくとも以下の
ユーザーノードを動作させる人物のアイデンティティー、および
ユーザーノードの識別、
の内の１つに基づいて割り当てられることを特徴とする、請求項１に記載のデータパケットのサービス送達の価格設定ベース品質のための装置。
【請求項８】
前記ネットワークはインターネットでありサービスの価格は通貨建てであることを特徴とする、請求項１に記載のデータパケットのサービス送達の価格設定ベース品質のための装置。
【請求項９】
前記サービスレベルの品質は、ネットワーク資源の特有の組み合わせを保証して、前記ネットワークが以下の
ｉ．電話、
ｉｉ．映像会議、
の内の少なくとも１つをサポートするようにすることを特徴とする、請求項１に記載のデータパケットのサービス送達の価格設定ベース品質のための装置。
【請求項１０】
サービスレベルの少なくとも１つの品質のサービス価格は、以下の
ｉ．予想されるネットワーク負荷
ｉｉ．ネットワーク負荷の安定性
ｉｉｉ．ネットワーク負荷の予測可能性
の内の少なくとも１つに基づいて調整されることを特徴とする、請求項１に記載のデータパケットのサービス送達の価格設定ベース品質のための装置。
【請求項１１】
購入価格は、ネットワークの過度な使用を防止して渋滞を最小限にしつつネットワークからの全体的な利益を最大限にするレベルに設定されることを特徴とする、請求項１に記載のデータパケットのサービス送達の価格設定ベース品質のための装置。
【請求項１２】
資源費用はすべてのユーザーノードに分配されることを特徴とする、請求項１に記載のデータパケットのサービス送達の価格設定ベース品質のための装置。
【請求項１３】
ユーザーからユーザーへのデータパケットのサービス送達の価格設定ベース品質のための方法であって、ユーザーはそれぞれ財政的制限、少なくとも１つのサービスプロファイル、アプリケーションニーズをもっており、ユーザー対ユーザー動的資源予約を行い、そしてデータ送達に関連するデータマーキングを含ませるためのヘッダを持つデータパケットの形式でデータの伝送を行い、ここでデータパケットは該方法を介してユーザーからユーザーへと送達されるものであり、該方法は、
データ伝送帯域幅およびプロセッサ容量を含む動的に割り当てられたネットワーク資源を持つコンピュータネットワークを提供する工程備え、該提供されたコンピュータネットワークは、
複数のノードシステムであって、該複数のノードシステムとともにソースノードシステムおよび動的ノードシステムを持っており、
複数のノードシステムと接続されている複数のエッジエレメントであって、それぞれのノードシステムが少なくとも１つのエッジエレメントに接続するようにされており、および
複数の相互接続されたコアルータであって、該複数の相互接続されたコアルータは複数のエッジエレメントに接続されて、それぞれのエレメントが少なくとも１つのコアルータに接続されるようにされ、そして複数ののノードシステムのそれぞれのノードシステムは経路によってネットワーククラウドを介して複数のノードシステムのそれぞれの他のノードシステムに通信可能に接続されている、を備える
ネットワーククラウド、を備えており、
該ネットワーク資源はモニタされ、複数の予測可能で動的に割り当て可能なサービスレベルの品質を提供するように構成されており、それぞれのサービスレベルの品質はネットワーク資源の特定の組み合わせを保証しサービスの価格を含んでおり、それぞれのサービスレベルの品質のサービス価格はネットワークを介したデータ伝送の許可を最適化してネットワーク内の渋滞を避けるように設定されており、
これによりネットワークのユーザーは、ネットワークにおいてネットワーククラウドを介して伝送を行うことで、ノードシステムを使って他のノードシステムを使用している他のユーザーにデータを伝送し、ユーザーが彼らのニーズおよび価格支払い能力に応じてサービスレベルの品質を動的に選択することを可能とする装置。
【請求項１４】
前記サービスレベルの品質は、
ａ．可変価格および固定品質のサービス、
ｂ．固定価格および固定品質のサービス
ｃ．固定価格および可変品質のサービス、および
ｄ．ハイブリッドサービス
から選択されることを特徴とする、請求項１３に記載のデータパケットのサービス送達の価格設定ベース品質のための方法。
【請求項１５】
前記サービスレベルの品質はユーザーによって決定されることを特徴とする、請求項１４に記載のデータパケットのサービス送達の価格設定ベース品質のための方法。
【請求項１６】
もしユーザーがそのユーザーの財源を超えて資源を利用しようとする場合、伝送は少なくとも以下のプロトコルの内の１つによって処理される、
ｉ．伝送を無視する、
ｉｉ．より低いサービスレベルに送る、および
ｉｉｉ．最善の努力を尽くした通信として送る、
を特徴とする、請求項１３に記載のデータパケットのサービス送達の価格設定ベース品質のための方法。
【請求項１７】
前記ネットワーククラウドを除くすべてのエレメントは無線ノードとして動作するように構成されていることを特徴とする、請求項１３に記載のデータパケットのサービス送達の価格設定ベース品質のための方法。
【請求項１８】
インターネットは前記コアルータを提供するものであり、前記ユーザーはインターネットによってインターフェースされる端末であることを特徴とする、請求項１３に記載のデータパケットのサービス送達の価格設定ベース品質のための方法。
【請求項１９】
前記ネットワークはイントラネットであり、財政的制限は少なくとも以下の
ユーザーノードを動作させる人物のアイデンティティー、および
ユーザーノードの識別、
の内の１つに基づいて割り当てられることを特徴とする、請求項１３に記載のデータパケットのサービス送達の価格設定ベース品質のための方法。
【請求項２０】
前記ネットワークはインターネットでありサービスの価格は通貨建てであることを特徴とする、請求項１３に記載のデータパケットのサービス送達の価格設定ベース品質のための方法。
【請求項２１】
前記サービスレベルの品質は、ネットワーク資源の特有の組み合わせを保証して、前記ネットワークが以下の
ｉ．電話、
ｉｉ．映像会議、
の内の少なくとも１つをサポートするようにすることを特徴とする、請求項１３に記載のデータパケットのサービス送達の価格設定ベース品質のための方法。
【請求項２２】
サービスレベルの少なくとも１つの品質のサービス価格は、以下の
ｉ．予想されるネットワーク負荷
ｉｉ．ネットワーク負荷の安定性
ｉｉｉ．ネットワーク負荷の予測可能性
の内の少なくとも１つに基づいて調整されることを特徴とする、請求項１３に記載のデータパケットのサービス送達の価格設定ベース品質のための方法。
【請求項２３】
購入価格は、ネットワークの過度な使用を防止して渋滞を最小限にしつつネットワークからの全体的な利益を最大限にするレベルに設定されることを特徴とする、請求項１３に記載のデータパケットのサービス送達の価格設定ベース品質のための方法。
【請求項２４】
資源費用はすべてのユーザーノードに分配されることを特徴とする、請求項１３に記載のデータパケットのサービス送達の価格設定ベース品質のための方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本願は、２０００年２月４日に米国特許庁に出願された「インターネットにおける価格設定ベースのサービス品質（ＰＱｏＳ）コントロールのためのアーキテクチャ」という名称の仮出願第６０／１８０，４５０号の恩恵を主張するものである。
【０００２】
本発明はインターネットアーキテクチャに関し、より詳細には、ネットワークにおける価格設定ベースサービス品質コントロールのためのシステムに関する。
【０００３】
【従来の技術及び発明が解決しようとする課題】
ネットワークシステムにおけるサービス品質（ＱｏＳ）保証の分野における現行の研究により、本質的に２つの主なプロトコルがもたらされた。統合サービス（ＩｎｔＳｅｒｖ）モデルは、ネットワークにおけるそれぞれのエンドシステムまたは宛先ノードが特定のＱｏＳおよびその他の特定のパラメータを要求することのできる柔軟なアーキテクチャを提供するものである。エンドシステムはいくつかの信号プロトコルを使って要求を送る。これによりネットワーク資源を確保する結果となった。確保した資源を確実に流れるようにするために、資源を宛先ノードに接続している経路上のそれぞれの横断コアルータは、流れおよびその要求される資源についての流れごとの状況情報を維持する必要がある。例えばノード不良によりデータ流れの状況が矛盾することを避けるために、信号プロトコルはしばしば周期的に再生を必要とするソフト状況情報を利用する。
【０００４】
流れごとの状況を維持し周期的にこれらのデータを再生することが必要なために、多数の流れを取り扱う際に信号プロトコルにスケーリング上の問題が生じる結果となった。差別化サービス（ＤｉｆｆＳｅｒｖ）モデルは、ネットワークプロバイダとユーザーとの間におけるサービスレベル協定（ＳＬＡｓ）を利用してこの問題を回避するよう設計された。これらのサービスレベル協定は、ユーザーの集中的な通信に対してプロバイダから得ることのできるサービス品質レベルを記載している。確立されたサービスレベル協定に準拠して送られる通信は特定のサービス品質レベルに所属するものとしてマーキングされる。コアルータにおいては、データパケットはそのマーキングされたサービス品質レベルに基づいてそれぞれ異なった方法で処理される。同じマーキングを持つパケットはすべて同様に扱われるため、コアルータは支持されるサービス品質レベルに対して割り当てられた資源を記載した情報を維持するだけでよい。サービスレベル協定は通信集中に利用されるため、流れごとの情報は必要ではない。さらに、差別化サービスモデルがあるため、エッジエレメントだけが入ってくる通信を監視し許可コントロールの決定を行うことを必要とする。コアルータは、ネットワークプロバイダとそのユーザーとの間のサービスレベル協定を履行するのに十分な大きさとされることが望まれる。このようなやり方により統合サービスモデルのスケーラビリティ問題は回避されるものの、このやりかたはかなり融通がきかない。サービスレベル協定は主に静的な方法で確立されるかまたはまれにしか変更されず、通常、だいだい数日または数週間ごとに変更されるものである。従って、差別化サービスモデルでは、ユーザーは自身の通信要求に従って予約された資源を増減することが認められない。サービスレベル協定の静的性質に加えて、流れの集中についてサービス品質レベルを特定することは、いくつかの流れの積極性（ａｇｇｒｅｓｓｉｖｅｎｅｓｓ）、往復遅延および取った経路の違いにより同じ集中に存在した流れの間で資源の分配が不公平になる結果となり得る。特定の安定してサービス品質レベルを確実なものとするためにネットワークプロバイダはそのネットワークを、ユーザーがとるどのような経路においてもサービスレベル協定に従っていつでも協定に沿ったサービス品質レベルをユーザーに提供するような大きさとする必要がある。ユーザーの通信がネットワークで取る正確な経路は前もってはわからないため、主な欠点は、ネットワークがすべてのあり得るケースを網羅するために非常に過度の規定が必要であるということである。このことはマルチキャストの場合により顕著である、なぜならユーザーの通信がプロバイダネットワーク内で異なる経路をとり得るためすべての経路において同時に十分な資源が利用可能でなければならないからである。
【０００５】
従って、統合サービスモデルの柔軟性と差別化サービスモデルの簡素性を兼ね備えたシステムを提供することが望まれている。このタイプのシステムはユーザーが流れごとの予約をできるようにすると同時にネットワークコアルータを比較的簡素な状態のままとすることを可能にするものである。
【０００６】
【課題を解決するための手段】
ユーザーからユーザーへのデータパケットのサービス送達の価格設定ベース品質のための装置および方法であって、ユーザーはそれぞれ財政的制限、少なくとも１つのサービスプロファイル、アプリケーションニーズをもっており、ユーザー対ユーザー動的資源予約を行う。さらにユーザーは送達に関連するデータマーキングを含ませるためのヘッダを持つデータパケットの形式でデータの伝送を行う。データパケットはネットワークを構成しているノードであるユーザーからユーザーへと送達される。１つの実施態様においては、ネットワークは動的に割り当てられたネットワーク資源を持つコンピュータネットワークである。これらの資源はデータ伝送帯域幅およびプロセッサ容量を含んでいる。さらにコンピュータネットワークは複数のノードシステムを含んでいる。このノードシステムは、信号を発生するソースノードシステムおよび信号の宛先である宛先ノードシステムを含んでいる。信号は一部、構成ネットワーククラウドを介して移動する。このネットワーククラウドは、複数のノードシステムに接続された複数のエッジエレメントを含んでおり、それぞれのノードシステムが少なくとも１つのエッジエレメントに接続するようにされている。さらに、それぞれのエッジエレメントは複数の相互接続されているコアルータを含んでおり、ここで、複数の相互接続されているコアルータは複数のエッジエレメントに接続されて、それぞれのエッジエレメントが少なくとも１つのコアルータに接続され、かつ複数のノードシステムのそれぞれのノードシステムが経路によってネットワーククラウドを介して複数のノードシステムのノードシステムと互いにに通信可能に接続されている。さらに、
ネットワーク資源はモニタされ、複数の予測可能で動的に可変のサービスレベルの品質を提供するように構成されており、それぞれのサービスレベルの品質はネットワーク資源の特定の組み合わせを保証しサービスの価格を含んでいる。それぞれのサービスレベルの品質のサービス価格はネットワークを介したデータ伝送の許可を最適化してネットワーク内の渋滞を避けるように設定されている。システム全体により、ネットワークのユーザーはネットワークにおいてノードシステムを使って他のノードシステムを使用している他のユーザーにデータを伝送することが可能となる。伝送はネットワーククラウドを介して行われ、ユーザーが彼らのニーズおよび価格支払い能力に応じてサービスレベルの品質を動的に選択できるようにする。
【０００７】
他の実施態様においては、価格設定ベースのサービス品質のための方法および装置は、ユーザーの財源を超えて資源を利用しようとするユーザーに対し、伝送を無視するか、より低いサービスレベルに送るか、最善の努力を尽くした通信として送るかのいずれかによって応答する。
【０００８】
他の実施態様においては、価格設定ベースのサービス品質のための方法および装置は、無線通信を使ってノードがネットワーククラウドと通信するようにネットワークが構成されている。例えば、ユーザーは無線ノードを使ってエッジエレメントに連絡してよく、そしてエッジエレメントは非無線技術を利用してネットワーククラウドと通信してよい。
【０００９】
【発明の実施の形態】
本発明はネットワークシステムに関するものであり、より詳細には、ネットワークにおけるサービスコントロールの価格設定ベースサービス品質コントロールのためのシステムである。以下の説明は、参照図面と共に、当業者が本発明を実施し利用できるようにしまた本発明を特定のアプリケーションに取り入れることができるようにするために提示されるものである。さまざまな改変ならびに異なるアプリケーションにおけるさまざまな利用も当業者にとっては即座に明白であり、本願において定義される一般的な原則は実施態様の広い範囲に適応し得る。従って、本発明は提示される態様のみに限定されるものではなく、本願に開示される原則および新規な特徴に一致する最も広い範囲に含まれるものとする。さらに、特にそれ以外の明白な記載がない限り、本願に含まれる図面は線的に描写され何ら特定の尺度を持つものではない点に留意すべきである、なぜならこれらは本発明の概念の定性的な描写として提供されるものであるからである。
序説
本発明にはいくつかの側面がある。これらをここで簡単に紹介する。第１は価格設定ベースのサービス品質（ＰＱｏＳ）の基本的なアーキテクチャおよび設計である。本質的に、ＰＱｏＳの１つの基本的な目的は、ネットワークユーザーに対して、彼らの財政的限度および彼らのアプリケーションの必要性に見合った動的帯域幅予約を行うための手段を提供することである。プロトコルのアーキテクチャは、ソースおよび宛先が割り当てられた帯域幅クラスにおいてそのデータ送信を維持することを必要とする。割り当てられたバンド幅を超過して送られるパケットはより低いサービスクラスに追放されるかまたは無視される。スケーラビリティもまた議論され、特にどのようにしてコアルータが短期間に流れごとの状況情報を維持することだけを必要とし、これにより増加したスケーラビリティをあらかじめ考慮しておくのかに関して議論される。
【００１０】
ＰＱｏＳプロトコルは複数のメッセージを含んでいる。これらについては基本的アーキテクチャおよび設計目的のセクションでより詳細に議論する。このセクションは、信号送信およびデータ流れ予約維持の問題に焦点を当てる。ここではＰＱｏＳコントロールメッセージは、要求、承認、およびルータメッセージという３つの総称タイプに分類できる。そしてそれぞれのタイプはさらに別のタイプに細分され、これらのタイプはこれらがエンドシステムおよびルータにおいて処理される方法を決定している。
【００１１】
ＰＱｏＳは照会位相を含む複数の位相を持っている。ここで、ソースは照会（ＱＵＥＲＹ）パケットを発行することによって予約手順を開始する。照会（ＱＵＥＲＹ）パケットによってソースはそれが要求しているＱｏＳレベル、予約すべき資源の量、およびいくつかの価格設定情報を示す。次の位相は予約位相である。ここでソースは、ネットワークからの特定の量の資源を要求する。更新位相は、資源の利用可能性および価格に関する事項についての情報をエンドシステムに常に知らせ続ける。更新を最新な状態に維持するために、エンドユーザーは周期的に再生（ＲＥＦＲＥＳＨ）メッセージを送る。削除位相は最終位相であり、データ流れに割り当てられた資源を解放するために使われる。削除位相はセッションが終わる前に削除（ＤＥＬＥＴＥ）メッセージを発行するべきものである。
【００１２】
ＰＱｏＳに関する実施問題を次に議論する。データとコントロール通信とを区別するために、ユニキャスト伝送の場合には異なるポート番号を利用することが適切である。マルチキャストの場合については、データ流れのための予約が確立されるまでは宛先がマルチキャストされたデータ流れを受け取ることが許されないようにするべきである。
【００１３】
ＰＱｏＳシステムは複数の価格設定ベースのサービスを含んでおり、これらのサービスは一般的に特有のネットワークに配置されて、ネットワークが不足するにつれて帯域幅の価格を増加させるものである。これにより、込み合っている期間中はより高額なまたはより重要なデータだけがネットワークに入ることを確実なものとする。
【００１４】
本発明の１つの実施態様は、価格設定ベースＱｏＳアーキテクチャ（ＰＱｏＳ）に依存したサービス品質（ＱｏＳ）モデルを提供するものであり、柔軟で実施が簡単である。簡単な通信の筋書きの概観を図１に示す。この図はエンドノード対エンドノード予約の例を表すものである。この説明のために、ノードはデータの送受信を簡素化するように構成されたネットワーク内のいかなるエレメントも事実上意味するものとして理解される。この筋書きにおいて、ソースノード１００は、ネットワークにおける資源の利用可能性および流れが取る経路についての情報を収集するための周期的な制御メッセージを伝送するコントロールメッセージを、差別化サービスＰＱｏＳクラウド１０４の入口エッジエレメント１０２に送る。そしてコントロールメッセージは、それを宛先ノード１１０に送る出口エッジエレメント１０８に到着するまでＰＱｏＳクラウド１０４内のコアルータ１０６に沿って送られる。サービスクラウド１０４の価格設定ベース品質は、コアルータがＰＱｏＳプロトコルをサポートしているネットワーク内の部分を表す。より詳細には、アーキテクチャはソースノード１００が予約パケットを入口エッジエレメント１０２に伝送する場合におけるデータ流れの確立を計算に入れている。入口エッジエレメント１０２はそれぞれ入ってくる通信を監視してデータ流れ情報を収集する。入口エッジエレメント１０２は多数のデータ流れを扱うことを望まれているわけではなくまた扱うこともない。サービス差別化の品質は、異なるデータ流れのデータパケットを、これらの流れに割り当てられた資源の量に従って異なった方法でマーキングすることによって実現される。入口エッジエレメント１０２は予約を登録し、要求をコアルータ１０６のうちの最初のものに送る。コアルータ１０６は、パケットマーキングおよび利用可能な資源によって表示されるように要求されるサービスレベルを評価する。この評価に基づいて、コアルータ１０６は受け取った要求を拒否するか、受け入れるか、または改変し、要求されるサービスのレベルの価格を表示し、宛先への経路に沿って予約を次のホップに送る。ここでこのプロセスは、予約パケットが宛先ノード１１０に到着するまで繰り返される。そして宛先ノード１１０は、予約の試みの結果を表すフィードバックメッセージをソース１００に送る。あらかじめ定義されたしばらくの期間中にフィードバックメッセージがない場合には、ソース１００は予約要求を再開する。予約が良好に確立された後、ソース１００は周期的コントロールメッセージを伝送して、ネットワークにおける資源の利用可能性および流れがとる経路についての情報を収集する。これにより、ソースノード、またはソース１００は、ネットワークロード状況における変更を検出でき、もし必要であれば、この情報に基づいてその資源消費を調整することができるようになる。このような調節は、通常、ネットワークロードの増加またはいくつかの他のネットワーク資源の縮小の結果、ネットワーク資源の価格が値上がりした場合に必要である。さらに、起源ノード、またはソースノード１００および宛先ノード１１０は経路の変更を検出して、変更された経路についての新しい予約シークエンスを開始することができる。
【００１５】
この基本的なアーキテクチャにより、コアネットワークを妨げない状態に保ちながらユーザーはデータ流れ予約を行うことが可能となる。通信の管理およびデータ流れ情報の収集に関する問題はエッジエレメントにおいて取り扱われる。サービス差別化の品質は、異なるデータ流れのデータパケットを、これらのデータ流れに割り当てられた資源の量に従って異なった方法でマーキングすることによって実現される。本発明の重要な側面は、ＱｏＳ予約セットアップ中、ＱｏＳ予約ティアーダウンオペレーション中、およびコアルータ間の予約セットアップのホップごとの承認およびティアーダウンオペレーション中は、一時的なデータ流れ状況の情報だけがネットワークのコアルータに保存されることである。エンドシステムは、予約されたサービスの品質、参加しているエンドシステム、および予約セッションがとる経路を表す情報を収集する。この情報を周期的に更新することによって、エンドノードは経路の変更または経路ノードの不良を検出することができる。
【００１６】
本発明は、ネットワークユーザーのニーズを計算に入れるのみならず、予測可能な価格をネットワークプロバイダが提供することができ、さらに混雑ベースの価格設定アプローチを利用してその資源が完全に売り切れてしまわないようにすることができるがこれにはネットワークプロバイダが新しいサービスに対する要求を拒絶することが必要である、サービスの一例を提示するものである。
基本的なアーキテクチャおよび設計目的
本発明の主要な目的は、彼らの財政的限度および彼らのアプリケーションの必要性に見合った動的帯域幅予約を行うための手段を提供することである。これらの予約はネットワーク内のコアルータにおいて状況情報を維持することを必要とせずに、エンド対エンドベーシスで行われる。ネットワークプロバイダにとって価格設定ベースのサービス品質は、許可コントロールおよび混雑の回避を同時に価格体系に組み込みつつサービス差別化の品質を可能としながらする簡素なネットワークアーキテクチャを提供するものである。ネットワーク資源はこれらが必要とされる場合動的に割り当てられて、ネットワークプロバイダがネットワークの寸法を過剰に大きくすることなくネットワーク資源をより効率的に割り当てることができ、また予測可能なサービスレベルの品質を提供することができるようにする。
プロトコルアーキテクチャ
本発明は差別化サービスモデルに類似したいくつかの技術を利用している。エッジエレメントは詳細な流れ当たりの状況情報を維持しており、この情報は消費されたネットワーク資源、サービスレベルの品質、および流れのアイデンティティーを含んでいる。許可コントロール、および通信監視および通信整形は主にエッジエレメントにおいて実現される。特有のソースの流れのために予約されたネットワーク資源に従って送られるデータパケットは、特定のサービスクラスに所属するものとしてマーキングされ、ソースのサービスプロファイルに送られてこれに従う。予約されたネットワーク資源を超過して送られるパケットはソースのサービスプロファイル（これは予約セットアップ中に確立されたものである）を侵害し、ドロップされるかより低いサービスクラスによってマーキングされるか、または最善の努力をした通信として送られる。データパケットはそれぞれマークを持っている。このマークは、単一のパケットの重要性に関する知識をもっているソースノードか、またはソースノードによって発生されたデータ通信の渋滞速度についての知識をもっているエッジエレメントによって作ることができる。いずれの場合においても、エッジエレメントは監視および／または整形メカニズムを実施して、それらの予約されたネットワーク資源にデータ流れが確実に一致するようにする必要がある。さらに、本発明は予約パケットの確立および維持の問題に関連しており、コアルータにおけるサービス差別化の実際の実現にはあまり関連していない。従って、要求される資源の合計を単に「帯域幅」と言及しても、どのようにしてユーザーが彼らのサービス品質要求を記載するべきかを適切に述べるものではない。所望されるサービスの細分性およびコアルータにおいて実施されたスケジューリング体系により、価格設定ベースのサービス品質はさまざまなやり方で実施されてサービスレベルの品質について異なる宛先を利用し得る。このような宛先は、平均帯域幅、最大帯域幅、バースト長さを含むか、または宛先は単に流れのタイプを列挙するに過ぎないこともあり得る。いずれの場合においても、サービス品質についてのすべての記載はコアルータにおいて帯域幅要求、およびバッファ要求に変換される必要がある。一般に、バッファ費用は帯域幅費用に比べると小さいものである。その結果、帯域幅は一般的に、本発明によって利用される資源の大部分を含んでいる。
【００１７】
起源ノードおよび宛先ノードに位置するエンドユーザーが彼らの要求を動的に送信し、彼らの実際のニーズに従って調整された専用の資源を持つことができるようにするために、価格設定ベースのサービス品質はエンド対エンドシグナリング体系とホップバイホップシグナリング体系との両方によってサービスモデルを拡張するように構成されている。
【００１８】
コントロールメッセージがネットワークからドロップした場合、エンドシステムおよびコアルータは廃棄される前にどのコアルータまで予約パケットが処理されたかを決定する必要がある。このような状況においては、ホップバイホップシグナリングがしばしば有利に利用される。前回の予約パケットの損失に対応して単純に予約パケットを再発行することで、最初の要求がすでに良好に処理されているノードにおいて二重予約が生じる可能性がある。二重予約の事例を回避するために、エンド対エンドおよびホップバイホップシグナリングが組み合わせて利用される。エンド対エンドシグナリングが通信経路全体に渡って行われ、ホップバイホップシグナリングが、横断経路全体に対するのとは対照的にノードからノードに発生する場合、エンド対エンドシグナリングおよびホップ対ホップシグナリングは、それぞれのコアルータにそのアドレスを予約パケットに保持されているアドレスリストの後ろに追加させることによって行われる。ＰＱｏＳシステムにおいては、それぞれの予約メッセージはアドレスリストを持っており、これに対して、メッセージパケットが通過するそれぞれのコアルータがそのアドレスを後ろに追加する。予約パケットを受け取った後、コアルータは流れのアイデンティティーを表す状況情報を維持する。要求された資源およびアドレスリストは要求メッセージパケットに保持される。さらにタイマーが保持されており、これはいつ要求データが廃れたかをあらわすものである。Ｔｒｏｕｔｅｒとして表示される期間において、コアルータはそれらの上流側隣接コアルータ（信号のもっとも最新のソース）に対し、受け取ったすべての予約パケットを知らせる。下流（もっとも最新の宛先ノード）コアルータが予約パケットＱｍを受け取ったという確認を受け取ると、コアルータは自身が維持しているリストからこの要求についてのエントリを削除する。コアルータＲｉから受け取った要求（Ｑｉ）に関するタイマーがコアルータＲｌ＋１において期限切れとなった場合、Ｒｌ＋１はＲｉに対するその周期的メッセージの中にアドレスリストおよびＱｉのＱｏＳ情報をともなったネガティブな承認を含んでいる。そしてネガティブな承認は、要求Ｑｉの逆アドレスリストの中に表されたコアルータに沿って送られる。従って、Ｑｉのソースは予約が良好に行われたノードを表すメッセージを最終的に受け取ることになるはずである。そしてソースは予約パケットを再送して前回の要求からのアドレスのリストをその中に含ませることができる。このリストの中に自身のアドレスを見出すコアルータはこの要求のための予約を行ったり要求のために状況情報を維持したりする必要はない。
【００１９】
ＰＱｏＳコアルータにおけるホップバイホップ承認プロセスを図２に提示する。ここで（Ｔｒａｃｋ）２００は、第１のコアルータ（Ｒｉ）および第２のコアルータ（Ｒｉ＋ｌ）間における予約パケットおよび削除要求の転送と、この要求に対する承認受け取りとの間で経過し得る最長時間である。すべての（Ｔｒａｃｋ）２００は決定ステップ２０２に提出され、ここでコアルータ２０４またはエッジルータ２０６に所属するものとして分類される。「エッジルータ」という用語は、入口エッジエレメントおよび出口エッジエレメントを含むものとして理解するべき点に留意すること。もしコアルータ２０４に所属すると分類された場合、（Ｔｒａｃｋ）２００はコア取り扱いステップ２０８に送られるが、ここでＲＡＣＫは受信されて失敗した要求のリストおよびタイミング情報のリストと共に送られる。もしエッジルータ２０６に所属すると分類された場合、（Ｔｒａｃｋ）２００はエッジ取り扱いエレメント２１０に送られるが、ここでＲＡＣＫはタイミング情報とともに隣接するコアルータに送られる。コアルータ２０４として分類されるかエッジルータ２０６として分類されるかにかかわりなく、ＲＡＣＫは少なくとも１つの隣接ステップ２１２によって受信される。このステップにおいてＲＡＣＫは評価されコアルータに所属するかまたはエッジルータに所属するかが決定される。エッジルータについては、失敗した要求照会ステップ２１４に照会が送られ、もし失敗がなければ送信はドロップされ、さもなければソースには失敗した要求２１６が知らされる。もしＲＡＣＫがコアルータに所属する場合は、照会は失敗した要求ステップ２１８および承認要求ステップ２２０に送られる。もしいずれかのステップからネガティブな答えがあった場合、このステップについての照会はドロップされる。もし失敗した要求ステップ２１８が肯定的な出力を発生する場合、要求は失敗した要求２２２のローカルリストに含まれる。もし承認要求ステップ２２０が肯定的な出力を発生する場合、要求２２４のローカル状況情報が削除される。もしＴＲが期限切れとなった場合、照会が再びコアまたはエッジ判断ステップ２２６に行く。もしエッジエレメントからのものであると判断された場合はソース２２８に連絡し、もしコアルータであると判断された場合は失敗した要求２３０のローカルリストに要求を含ませる。
【００２０】
予約が良好に行われたことは、宛先ノード、この場合には宛先ノードによるポジティブな承認によって表される。監視および整形機能を開始するために、この承認はエッジエレメントによって傍受される必要がある。予約された資源の量およびレベルは、特定のサービスレベル品質を持つデータ転送速度に変換される。予約をともなう流れに所属する通信は、サービスレベルの要求される品質と、ノードが要求されるレベルに準拠していること、すなわち、ノードがそのサービスレベルを超過するデータを送らないことによって準拠していることとに基づいてマーキングされる。
スケーラビリティ
一般に、統合サービスを提供するように構成されたコアルータはそれぞれのデータ流れについての状況情報を維持する必要がある。これは、流れを一定のサービスレベル品質に分類し、特定のサービスレベル品質によって流れをスケジューリングすることを目的としている。サービスの品質はさまざまなエレメントに関連している。しかしながら、確実な帯域幅、および高度な時間直線性を持つサービスがＱｏＳを設定する際の重要なエレメントとしてしばしば含まれる。時間直線性は、電話および映像会議、および流動メディアをリアルタイムに送達することが必要とされるその他のアプリケーションにとって重要である。さらに、データ流れおよびその流れ専用の資源を表す情報が維持されねばならない。例えば電話および映像会議などにサービスレベルの品質の数を制限し、パケットヘッダ内のマークを利用してパケットが所属するレベルを表示することにより（ここでは映像または音声）、パケット分類の複雑さを軽減することができる。この状態においては、コアルータはマーキングを読取ってパケットをサービスレベルの適切な品質に割り当てることだけを必要とする。価格設定ベースのサービス品質コアルータは短期間の間、特に予約を確立している最中およびそれに続く更新調整期間中、データ流れ状況情報を維持することだけを必要とする。
【００２１】
価格設定ベースのサービス品質は、中間コアルータにおける宛先ノード応答のマージングをサポートしない。これは、それぞれの予約パケットまたは更新が宛先ノードによる承認をトリガすることを意味する。いくつかの状態においてこれは望ましくない。何回コントロールメッセージが送られるか、そしてマルチキャストグループおよびマルチキャストグループの分布により、いくつかのオプションを適用してコントロール通信を削減することができる。オプションのうちの１つは抑制である。少数のノードに添付された多数の宛先ノードをともなうマルチキャストツリーの場合については、承認は同じ内容を保持する。いくつかの同じ承認を伝送することを避けるために、それぞれの宛先ノードは無作為に選択したある期間の後にその承認パケットの伝送をスケジュールする。もしこの期間中に承認が同じ内容をともなう他のあて先ノードを形成することが観察された場合は、宛先ノードは自身の承認を伝送することを差し控える。あるいは、ユニキャスト伝送を利用することができる。ここで、広い領域に分配されたほんの少しの宛先ノードをともなうマルチキャストグループの場合については、承認を分配するためにマルチキャストを使用しても不必要なオーバーヘッドを発生させるだけである。より効率的な解決策は、承認がソースノードに対して直接宛先ノードを形成することをユニキャストすることである。価格設定ベースのサービス品質によって使用されるエンド対エンドコントロールメッセージに加えて、コアルータはホップバイホップメッセージを互いの間で交換する。しなしながら、それぞれのコアルータはその近接するコアルータに対して周期的にメッセージを伝送するだけなので、オーバーヘッドは小さくデータ流れの数と意味のある相関関係は持たない。
プロトコルメッセージ
価格設定ベースのサービス品質プロトコルメッセージには、要求メッセージ、承認メッセージ、およびコアルータメッセージという３つの総称タイプがある。そしてそれぞれのタイプはさらに別のタイプに細分され得、これらのタイプはこれらがエンドシステムおよびコアルータにおいて処理される方法を決定している。それぞれのタイプを以下に述べる。
１．要求メッセージ
すべての要求メッセージは同じ概略構造を持っているが、いくつかのフィールドはいくつかの特定のサブタイプに関連するに過ぎない。要求メッセージは好ましくは以下のフィールドを含む。
１．タイプ（Ｔ）：電話などの、メッセージのタイプ
２．流れｉｄ（Ｉｄ）：流れのアイデンティティーを表す数字。このフィールドは予約セッションを開始する前にアプリケーションによって決定される。Ｉｄはアプリケーションが使っている可能性がある他の予約セッションと区別するために固有の値に設定されることを必要とする。そして予約セッションに使用されるすべてのコントロールメッセージは同じアイデンティティーを使用する。
３．ＱｏＳレベル（Ｑ１）：要求されるサービスレベル
４．帯域幅（Ｂｒｅｑ）：予約される特定のＱｏＳ（Ｑ１）レベルにおける資源の記載。このフィールドは、要求されるサービスおよびアプリケーション要件に基づいて開始される。このフィールドの実際のフォーマットおよび内容はＰＱｏＳの実施に左右される。
５．価格（Ｐ）：予約される資源の価格。このフィールドは、要求されるサービスおよびアプリケーション要件に基づいて開始される。このフィールドの実際のフォーマットおよび内容はＰＱｏＳの実施に左右される。
６．価格区分（Ｐｆｒａｃ）：予約された帯域幅の価格がソースと宛先ノードとの間で分割されるべき場合に、ソースは宛先ノードが支払う必要のある支払い分担をこのフィールドに表示することができる。ソースが予約された資源すべてに対する支払いを行う場合はこのフィールドは０に初期化される。
７．遅延（Ｔｄｅｌａｙ）：予約または削除要求の転送とそれに対するネガティブな承認の受信との間の最大時間を収集するかまたは表示するためのフィールド。
８．タイムスタンプ（Ｔｓｅｎｄ）：パケットが送られた時間を表示するためにソースによって設定されるタイムスタンプ。特定の実施態様と同様に要求メッセージのタイプにより、必要に応じてコントロールメッセージに別のフィールドがあってもよい。
照会メッセージ（ＱＵＥＲＹ）
実際の予約パケットを伝送する前に、ソースはネットワークで利用可能な資源およびこれらの資源に割り当てられた価格、ならびに予約ステップに必要とされる遅延情報を照会することを必要とする。このメッセージのタイプはＱＵＥＲＹに設定される。
予約パケット（ＲＥＳＶ）
予約パケットであるＲＥＳＶによって、ソース、ここではソースノードは実際の予約パケットを発行する。このメッセージのタイプはＲＥＳＶに設定される。総称要求メッセージのフィールドに加えて、予約パケットＲＥＳＶは以下のフィールドを含んでいる。
１．ルーティングリスト長さ（Ｎｒｏｕｔｅｒ）：ルーティングリストのコアルータアドレスの数を表す。このフィールドはソースにおいて０に初期化されそれぞれの逆コアルータについて１つだけ増加される。
２．ルーティングリスト（Ｌｒｏｕｔｅｒ）：このリストは、すでにトラバースされたコアルータのアドレスを表す。Ｌｒｏｕｔｅｒはソースにおいて空に設定され、してそれぞれのトラバースされたコアルータはそのアドレスを伝送されたパケットの後ろに追加する。
３．繰り返しルーティングリスト長さ（Ｎｒｏｕｔｅｒ＝ｏｌｄ）：失われた予約パケットに応答してこの予約パケットＲＥＳＶが送られた場合、このフィールドは前回失われた予約パケットの最中に良好にトラバースされたコアルータの数を表す。さもなければＮｒｏｕｔｅｒ＿ｏｌｄは０に設定される。
４．繰り返しルーティングリスト（Ｌｒｏｕｔｅｒ＿ｏｌｄ）：前回の予約パケットが失われたという表示に応答してこの予約パケットＲＥＳＶが送られた場合、このリストは前回失われた予約パケットによってトラバースされたコアルータのアドレスを表す。さもなければＬｒｏｕｔｅｒ＿ｏｌｄは空に設定される。
５．削除メッセージ（ＤＥＬＥＴＥ）：削除（ＤＥＬＥＴＥ）メッセージによってソースノードは、ネットワークコアルータがそれらについて予約されている帯域幅の数を削減するかまたは排除するべきであることを表す。削除（ＤＥＬＥＴＥ）メッセージは、予約パケットＲＥＳＶと同じ構造を持っているが、ＤＥＬＥＴＥに設定されているタイプをともなっている。さらにこの場合、帯域幅フィールドはコアルータにおいて削減され予約されていない帯域幅の量と解釈される。ここで、繰り返しコアルータリスト（Ｌｒｏｕｔｅｒ＿ｏｌｄ）および数（Ｎｒｏｕｔｅｒ＿ｏｌｄ）は、削除要求を発行しているデータ流れのためのルーティング情報を表す。
６．予約チェックメッセージ（ＲＣＨＥＣＫ）：後で述べるように、ソースノードは予約パケットが宛先ノードに到着したかどうかをチェックする必要がある。このために、ソースはＲＣＨＥＣＫに設定されたタイプフィールドを持つ要求メッセージを発行し、予約情報はオリジナル予約パケットを形成する。この場合、繰り返しコアルータリストおよび数は、ＲＣＨＥＣＫ要求を発行している流れのためのルーティング情報を表す。
７．再生（ＲＥＦＲＥＳＨ）パケットメッセージ
利用可能な資源およびそれらの価格に関する事項についてエンドシステムを更新された状態に維持するため、ソースはＲＥＦＲＥＳＨに設定されたタイプフィールドを持つ要求メッセージを周期的に発行する必要がある。要求メッセージの基本的フィールドに加えて、ＲＥＦＲＥＳＨパケットは以下のフィールドを含んでいる。
ａ．ルーティングリスト長さ（Ｎｒｏｕｔｅｒ）メッセージ：ルーティングリストのコアルータアドレス数を表す。このフィールドはソースにおいて０に初期化されそれぞれのトラバースされたコアルータによって１つだけ増加される。
ｂ．ルーティングリスト（Ｌｒｏｕｔｅｒ）：このリストはすでにトラバースされているコアルータのアドレスを表す。Ｌｒｏｕｔｅｒはソースにおいて空に設定され、そしてそれぞれのトラバースされたコアルータはそのアドレスをリストの最後に添付する。
ｃ．予約されている資源（Ｂｒｅｓｖ）：このフィールドは流れＩｄについて現在予約されている資源の量を表しており、ソースによって設定される。
２．承認メッセージ（ＡＣＫ）
受信した要求に応答して、宛先ノードはソースノードにそれらの要求の結果を知らせるために承認メッセージを発行する。一般に、承認メッセージは基本的要求メッセージと同じ構造である。承認メッセージに開示されるサービス品質および価格設定情報は一般に、これらが承認している対サービス要求（ｒｅｑｕｅｓｔ−ｆｏｒ−ｓｅｒｖｉｃｅ）メッセージから得られる。さらに、宛先ノードは価格区分のエントリを変更して宛先ノードがいくら支払う意志があるかを表示したり、予約されている資源エントリを削減してデータ取り扱いに関する自身の能力を反映させてよい。従って、宛先ノードはどのように費用を分割するか、そしてどれくらいの帯域幅を契約に入れるかについてソースと交渉し得る。一般的な価格設定ベースのサービス品質メッセージに含まれるフィールドに加えて、ＡＣＫメッセージは以下の別のフィールドを持っている。
ａ．経路変更フラグ（Ｆｐｃ）：このフラグを「オン」に設定するということは、流れが取った経路において宛先ノードが変更を検出したことを意味する。
ｂ．ルーティングリスト長さ（Ｎｒｏｕｔｅｒ）：ルーティングリストのコアルータアドレス数を表す。
ｃ．ルーティングリスト（Ｌｒｏｕｔｅｒ）：このリストは、要求メッセージによってトラバースされたコアルータのアドレスを表す。
【００２２】
それぞれのＡＣＫメッセージをもつ完全なルーティングリストを送らないようにするためには、以下の場合において宛先ノードはルーティングリストおよび数（ＬｒｏｕｔｅおよびＮｒｏｕｔｅｒ）に記入することだけを必要とする、すなわち
ｉ．コントロールパケットが取った経路における変更を検出したとき、
ｉｉ．マルチキャストセッションに加わった後、または
ｉｉｉ．予約パケットを受け取った後。
３．ルータメッセージ
価格設定ベースのサービス品質によって、本発明はエンド対エンドシグナリングとホップバイホップルータシグナリングとを組み合わせている。そういうものであるため、ルータ対ルータメッセージとルータ対ソースメッセージとを区別することができる。
ルータ承認（ＲＡＣＫ）メッセージ
予約または削除オペレーションが重複しないようにするために、ソースはどのルータがドロップされる前に予約または削除メッセージをトラバースしたかを常に把握する必要がある。このために、ルータはタイムアウト後に期限切れとなるいくつかの状況情報を維持している。Ｔｒｏｕｔｅｒの期間中は、それぞれのルータ（ｎ）はそれに近接するすべてのルータ（ｍ）に対して以下の構造と共にＲＡＣＫメッセージを送る。
１．タイムスタンプ（Ｔｓｔａｍｐｎ）：このパケットがルータｎによって送られた時間。
２．バッファ遅延（ＴＢｎ）：ルータｍからのＲＡＣＫメッセージがルータｎにおいてこうむる可能性のある最大バッファリング遅延。
３．受信されたタイムスタンプ（Ｔｍ）：ルータｍから受信された最後のＲＡＣＫメッセージのタイムスタンプ。
４．承認遅延（Ｔｄｅｌａｙｍ）：ルータｍからの最後のＲＡＣＫメッセージを受け取ってからこのＲＡＣＫメッセージを送る間に経過した時間。
５．受信した要求の数（Ｎｒｅｑ）：最後のＲＡＣＫメッセージを送って以来、ルータｍからルータｎに到着した予約または削除要求の数。
６．要求リスト：最後のＲＡＣＫメッセージを送って以来、ルータｍからルータｎに到着した予約または削除要求のアイデンティティー。それぞれの要求はソースのアドレスおよび宛先ノードおよび流れの識別を介して識別される。
７．失敗した要求の数（Ｎｆａｉｌ）：最後のＲＡＣＫメッセージを送って以来、ルータｍからルータｎに到着し期限切れとなった要求の数。
８．失敗した要求のリスト：局地的に期限切れとなるか、または宛先ノードに向かって上流にある他のルータによって期限切れとされたと報告された要求の状況情報を含んでいるリスト。失敗した要求を記載している状況情報は、要求がタイムアウトとされたルータにおいて保存されているすべての状況情報、すなわちＱｏＳ、価格設定、およびルーティング情報を表す流れのための要求メッセージの内容を含んでいる。
ネガティブ承認メッセージ（ＮＡＣＫ）
失敗した要求を表すエントリをともなうＲＡＣＫメッセージをエッジエレメントが受け取った場合、エッジエレメントはこの要求のソースに対して失敗を知らせる必要がある。これは失敗した要求を発行したソースに対して、要求のアイデンティティー、この要求を処理するために最後のルータによって観察された価格設定および帯域幅情報、および最後のルータの方向に進むルーティングリストを表しているＮＡＣＫメッセージを送ることによって行われる。
照会位相
ネットワークを介して予約を行うために、エンドシステムはネットワークと相互作用しなければならない。基本的なアプローチでは、上で述べたように、ソースがコントロールメッセージをエッジエレメントに伝送し、ここからこれらのメッセージをネットワーククラウドに転送し、そしてこれらのメッセージを他のエッジエレメントに転送して最終的に宛先ノードに転送する。エッジエレメントは、すべてのコントロールメッセージを受け取って処理することを必要とするのに対して、コアルータは予約または削除メッセージに応答することだけを必要とする。ＰＱｏＳルータにおけるコントロールメッセージ処理を図３に示す。ここで、ＰＱｏＳコントロールメッセージ３００は決定ステップ３０２に提出される。決定ステップ３０２は制御メッセージ３００を再生／予約チェックメッセージ（ＲＥＦＲＥＳＨ／ＲＣＨＥＣＫ）３０４か予約パケット／削除（ＲＥＳＶ／ＤＥＬＥＴＥ）メッセージ３０６かのいずれかであるとして分類する。ノードは予約パケット／削除工程３０７を照会して自身のアドレスが繰り返しルーティングリスト（Ｌｒｏｕｔｅ＿ｏｌｄ）に含まれているかどうかを確認する。もし含まれていなければ、メッセージはノー（ＮＯ）ステップ３０８に送られ、ここでＰＱｏＳは資源割り当て３０８ａを更新し、システム状況情報３０８ｂを保存し、ルータｍ（Ｔｍ）３０８ｃから受け取った最後のＲＡＣＫメッセージにタイムスタンプをし、自身のアドレスをルーティングリスト（Ｌｒｏｕｔｅｒ）３０８ｄに加える。ルーティングリスト（Ｌｒｏｕｔｅｒ）３０８ｄは要求メッセージによってトラバースされた、ソースノードから宛先ノードへのルータのアドレスを表している。次に、メッセージは次のコアルータ、エッジエレメント、またはノードに転送される。万一ノード自身のアドレスが繰り返しルーティングリスト（Ｌｒｏｕｔｅｒ＿ｏｌｄ）に含まれている場合は、ノードは自身のアドレス（Ｌｒｏｕｔｅｒ）３１０を付け加える。もし最初の決定ステップ３０２がコントロールメッセージを再生／予約チェックメッセージ３０４であるとして分類する場合は、コントロールメッセージは再生／予約チェックステップ３１２に送られ、ここでノードは自身のアドレス（Ｌｒｏｕｔｅｒ）３１２ａを付け加え、割り当て３１２ｂの合計を更新し、メッセージを次のルータ、エレメント、またはノードに転送する。
【００２３】
前述のエンドノード対エンドノード予約の例を図４に図示する。ここで、ソースノード４００は、ソースノード４００からネットワーク入口エッジエレメント４０４へと移動する照会パケット４０２を発行することによって予約手順を開始する。そして照会パケット４０２は複数のルータ４０６を介して出口エッジエレメント４０８へと移動し、最終的には宛先ノード４１０へと移動する。照会パケット４０２によって、ソースノード４００はそれが要求しているＱｏＳレベル、予約する資源の量、および価格設定情報を表す。さらに、照会パケットはデータパケットの価格区分フィールドにおいて、宛先ノードが引き受けるべき資源の分担を特定する。それぞれのトラバースされたコアルータ４０６は照会パケット４０２に表示された予約パケットをコントロールし、要求されるサービスおよびその付加状況により帯域幅および価格エントリを変更し得る。さらに、それぞれのコアルータ４０６は、この要求についての承認パケットを、この要求を送ってきたコアルータ４０６に送るのにかかると思われる最大時間値（Ｔｒａｃｋ）を付け加える。価格設定ベースのサービス品質とともに使用されるさまざまなタイマーの値を決定する詳細については次の段落で述べることにする。照会パケット４０２は宛先ノード４１０において受け取られると、照会メッセージ４０２は帯域幅および価格設定フィールドを含んでおりこれらはネットワークにおける現在の資源の利用可能性を表すものである。資源要求値はソースノード４００が実際の予約パケットを発行する前に変わるかもしれないものの、これら資源要求値は一般に、ネットワークにおける資源の利用可能性および価格を良好に表示するものとして役立つ。
【００２４】
照会パケット４０２を受け取った後、宛先ノード４１０は承認プロトコルによりいくらかの期間（Ｔ）の後に承認メッセージ（ＡＣＫ）４１２をスケジュールする。この承認メッセージ（ＡＣＫ）４１２は宛先ノード４１０から送られ、出口エッジエレメント４０８、コアルータ４０６、および入口エッジエレメント４０４を介してソースノード４００へを送り返される。
【００２５】
予約位相中は、ソースノード４００はネットワークから特定の量の資源を要求する。新しい予約間の区別または予約の更新はない。ソースノード４００は資源の所望の増加を表示する新しい予約パケットを発行することにより、割り当てられた資源の量をいつでも増加させることができる。そしてこれはコアルータ４０６において新しい予約として処理される。しかしながら、これに従ってエッジ入口エレメント４０４および出口エレメント４０８は自身の状況情報を更新することを必要とする。予約パケット４１４、再生パケット４１６、および承認４１８はすべて同様に取り扱われる。
予約位相
２つのルータ承認（ＲＡＣＫ）メッセージ間の時間を表すＴをともなう良好な予約の一例を図５に示す。ソースノード５００は、自身の照会要求に対する承認メッセージを受け取った後、予約するよう要求されたＱｏＳ資源および価格設定情報を表す予約パケット（ＲＥＳＶ）５０２を発行することによって実際の予約手順を開始する。照会位相中に決定された価格設定および帯域幅値は、ネットワークにおける実際の資源利用可能性および価格についてのガイドラインとされるべきものである。さらに、ソース５００は（Ｔｓ）秒後に期限切れとなるようにタイマーをスケジュールする。予約パケット（ＲＥＳＶ）５０２がまず最初に入口エレメント５０４に送られ、それが流れを許可するのに十分な資源を持っているかどうかをチェックする。もしそれが流れを受け入れる場合は、入口エレメント５０４は識別、ＱｏＳ特徴、および価格設定情報の形式でこの要求についての状況情報を維持する。ここで識別は、この予約パケット５０２に所属し、宛先ノード５０８のアドレス、発信ノード５００のアドレス、およびパケットデータ流れ識別（Ｉｄ）を使用するパケットの入口エレメント５０４の識別を参照する。ＱｏＳ特徴は、予約パケット５０２において把握されているようにＱｏＳレベルおよび帯域幅要件を含んでいる。価格設定情報は、コスト対ソースノード５００に関する情報を維持するためにエッジエレメント５０４のニーズを含んでいる。
【００２６】
サービス差別化は、異なるＱｏＳレベルに所属するものとしてパケットをマーキングすることによって行われる。これは、ソースノード５００かまたは入口エッジエレメント５０４においてパケットをマーキングすることによって行うことができる。いずれの場合においても入口エッジエレメント５０４は、入ってくる流れがそれらの予約された資源に確実に一致するようにする責任がある。これは、予約された資源を超えて送られるパケットの優先度をドロップするかまたは低くする監視または整形メカニズムの使用を必然的にともなう。
【００２７】
承認メッセージを傍受し、ネットワークに置ける資源の利用可能性および価格についての情報を把握することによって、エッジエレメントはキラー予約の問題を避けることができる。キラー予約は、ネットワークの一部において与えられる大量の資源をユーザーが要求する場合に発生する。その結果、ネットワークのこの部分において新しい予約が拒絶される。予約はネットワークのいくつかの他の部分において拒絶されるが、これは、この要求に対して予約された資源が浪費され、その結果その他の要求が、場合によっては不必要に拒絶されたことを意味する。照会の結果とは一致しない要求を拒絶することによって、キラー予約の影響をかなり低くすることができる。さらに、入口エッジエレメント５０４はタイマーを、ＴＲＥ後に期限切れとなるようにスケジュールしてそのアドレスをアドレスリスト（Ｌｒｏｕｔｅｒ）に含ませる。入口エッジエレメント５０４はカウンタＮｒｏｕｔｅｒを１だけ増分させ、メッセージを経路上の次のルータに向けて宛先ノードまで転送する。
【００２８】
コアルータ５１０は、予約パケットを記載する状況情報を一時的に維持する。予約パケットであるＲＥＳＶ５０２を受け取った後コアルータ５１０は、予約パケットＲＥＳＶ５０２に保持されている、識別、ＱｏＳ、価格情報、およびルーティング情報のコピーを保持する。しかしながらこの情報は、最長期間ＴＲｉ秒の間だけしか維持されない。もしルータがこの期間中に、次のルータがこの要求を受け取ることを承認するＲＡＣＫメッセージ５１２を宛先ノードに向かう経路に沿って受け取らない場合は、ルータはこの要求は失われたと判断する。そしてこの要求は、要求のルータリストに表されているように、もともと要求を送ってきたコアルータ５１０にあらかじめあてられている次のＲＡＣＫメッセージ５１２の失敗した要求リストに付け加えられる。ＴＲが期限切れとなる前に、次のルータがこの要求を受け取ったことを表すＲＡＣＫメッセージ５１２が受け取られると、状況情報が削除される。情報を削除する前に、ルータ５１０はこの要求の受け取りを承認したかどうか確認する必要がある。
【００２９】
宛先ノード５０８に到着する前に、コントロールメッセージはＰＱｏＳネットワークを他のネットワークかまたは最終宛先ノード５０８に接続している他のエッジエレメント５０６を通過し得る。入口エッジエレメント５０４は、流れのアイデンティティー、ＱｏＳおよび価格設定情報ならびに受け取られたＲＥＳＶパケット５０２メッセージに記載されているようにルーティング情報を記載している状況情報を維持する必要がある。
【００３０】
宛先ノード５０８では、宛先ノードはＡＣＫメッセージ５１４を発行することによって予約パケットであるＲＥＳＶ５０２の受け取りを承認する。ＡＣＫメッセージ５１４は通常、ＲＥＳＶパケット５０２の内容を含んでいる。しかしながら、宛先ノード５０８は予約された資源のエントリまたは支払いをする意志のある価格区分（または通信費用の区分）を変更することによって自身の好みおよび能力を表現し得る。この場合、経路変更フラグ（Ｆｐｃ）が開始される。
【００３１】
入口エッジエレメント５０４および出口エッジエレメント５０６はＡＣＫメッセージ５１４を使用して、要求についての自身の状況情報を更新する。ソースは、予約されている実際の資源、資源の価格、および宛先ノードが支払いを受け入れる意志のある価格の区分を記載しているＡＣＫメッセージ５１４の内容をコントロールする。もし１つ以上の報告された値がソースによって受け入れ不可能な場合は、ソースはＡＣＫメッセージ５１４に報告されている資源の量を表すＤＥＬＥＴＥメッセージを送ることにより、予約されている資源を削除する必要がある。
【００３２】
万一承認パケット（ＡＣＫ）５１４または予約パケット（ＲＥＳＶ）５０２のいずれかがドロップされる場合、ソース５００は、予約の重複を避けるためにそれがすでに予約を行ったコアルータ５１０のセットを決定する必要がある。
【００３３】
予約が重複することを避けるために利用される方法を図６に詳細に示す。渋滞エラーおよびリンクエラーは、いずれかのコアルータ（Ｒｎ）において予約パケット６００をドロップさせる可能性がある。それぞれのルータ（ｉ）は、最終宛先ノード６０２に向かってさらに上流のルータにおいて予約パケット６００が失われたと推測する前に、ＴＲｉ期間中、要求についての状況情報を維持する。予約パケット６００は（ＲＥＳＶ（流れｉｄ、Ｌｒｏｕｔｅｒ、Ｌｒｏｕｔｅｒ＿ｏｌｄ））の形式で記述されており、ＲＡＣＫパケット６０４は（ＲＡＣＫ（流れｉｄ、Ｌｒｏｕｔｅｒ））の形式で記述されている。予約パケット６００はソースノード６０６において発生し、入口エッジエレメント６０８および第１のルータ（Ｒ１）６１０を良好に通過するがその後のルータ（Ｒ２）６１２においてドロップされる。それぞれのトラバースされたルータは自身のアドレスをルーティングリスト（Ｌｒｏｕｔｅｒ）に付け加え、（ＴＲｉ）の期間中この予約パケット６００についての状況情報を維持する。ルータは受け取られて失敗した要求を表すＲＡＣＫパケットをＴ秒ごとに伝送する。万一要求がまったく受け取られなかった場合、またはすべての要求が良好に行われた場合、例えばエッジエレメント２（Ｅ２）６１４のＲＡＣＫパケット６０４などのＲＡＣＫパケット６０４のリストは空である。要求が良好に受け取られた場合は、例えばＲ１６１０およびＲ２６１２のＲＡＣＫパケット６０４などのＲＡＣＫパケット６０４は、流れのアイデンティティーを要求リストフィールドに表す。アイデンティティー１の流れの要求についてのＲ２６１２（ＴＲ２）のタイマーが時間２Ｔ６１６の前に期限切れとなると仮定する。従って、Ｒ２６１２はそのＲＡＣＫパケット６０４の中に、Ｒ２６１２において見られるように失敗した要求のアイデンティティーおよびその要求のルーティングリストの内容を含んでいる。Ｒ１６１０は時間３Ｔ６１８においてこの情報をエッジエレメントに転送し、エッジエレメントは、失われた予約パケットのアイデンティティーと予約パケットによって良好にトラバースされたルータのアドレスとを表しているソースに対し、ＮＡＣＫメッセージを直接送る。
【００３４】
失敗した要求に応答して、ソースノード６０６は、ＱｏＳおよび損失に応答してＮＡＣＫメッセージが出口エッジエレメント６０８から受け取った価格設定採用形式とともに新しい予約パケットを発行する。新しい要求においてＬｒｏｕｔｅｒおよびＮｒｏｕｔｅｒが空の場合は、Ｌｒｏｕｔｅｒ＿ｏｌｄおよびＮｒｏｕｔｅｒ＿ｏｌｄはルーティングリストの値およびＮＡＣＫメッセージに表されている長さを持っている。それぞれのコアルータにおいて、コアルータは予約パケットＲＥＳＶに添付されているＬｒｏｕｔｅｒ＿ｏｌｄリストに自身のアドレスが含まれていたかどうかをチェックする。もしコアルータが、自身のアドレスがＬｒｏｕｔｅｒ＿ｏｌｄに含まれていることを見出した場合、これらコアルータはこの予約についての予約をすでに行っており、最終宛先に向かう経路上の次のルータに予約を転送する必要があるのみであると仮定する。リストに自身のアドレスを見出さなかったルータは損失がなかった場合の新しいメッセージについて行われるのと同じ手順に従う必要がある。最初の予約要求の伝送とその要求の再伝送との間で流れの経路が変わったという状態では、もはやトラバースされないルータにおいて予約される資源は失われる。このような状態は、アドミッションコントロール手順についての予約資源の量を決定する際に対応される必要がある。
【００３５】
もしタイムアウト期間Ｔｓ後、ソースノード６０６が自身が伝送した予約パケットに対する回答の受け取りがない場合、ソースノード６０６は空に設定されたＬｒｏｕｔｅｒを持つ予約パケットチェック要求（ＲＣＨＥＣＫ）を発行する。それぞれのトラバースされたコアルータは自身のアドレスをアドレスリスト（Ｌｒｏｕｔｅｒ）の最後に添付し、パケットを最終宛先ノード６０２に向けて転送する。
オリジナルの要求が最終宛先ノード６０２に到着した場合は、最終宛先ノード６０２は要求についてのエントリおよびそれについてのルーティング情報を維持する。このような状態において、最終宛先ノード６０２は受け取ったＲＣＨＥＣＫ（Ｌｒｏｕｔｅｒ）メッセージのルート情報と、オリジナルの予約パケットＲＥＳＶから自身が収集した情報とを比較する。もしこれらのリストが同じである場合、最終宛先ノード６０２はＲＣＨＥＣＫメッセージに含まれるルーティングリストとともにＡＣＫメッセージを発行するか、さもなければ、「オン」状態に設定された経路変更フラグを持つＡＣＫメッセージ、および古いルーティングリストを発行する必要がある。このような場合には、ソース６０６はＡＣＫメッセージに表されたルーティングリストに設定されたＬｒｏｕｔｅｒ＿ｏｌｄをもつ予約パケットを発行する。Ｌｒｏｕｔｅｒ＿ｏｌｄリストに含まれないトラバースされたコアルータだけがセッションのための新しい予約を行う必要がある。もはやトラバースされないルータにおける最初のＲＥＳＶ要求によって予約された資源は、これらのルータにおいて割り当てられた資源に対する評価者が割り当てられた資源の実際の値に収束するまで浪費される。最終宛先ノード６０２が予約パケットであるＲＥＳＶを受け取らないの場合は、まず最初に、最終宛先ノード６０２はセットオフされた経路変更フラグを持つＡＣＫメッセージ、および空のルーティングリストを送る。これはソース６０６に対して新しい予約パケットを発行必要があることを知らせるものである。
更新位相
エンドシステムに常に予約の利用可能性および価格を知らせ続け、行われた予約の量を評価するためにルータにおいてハードステートプロトコルを使うことを避けるために、エンドノードは周期的にＲＥＦＲＥＳＨパケットを送る必要がある。それぞれのトラバースされたコアルータは自身のアドレスをルーティングリストに含ませ、価格設定および資源利用可能性情報を更新し、メッセージを経路上の次のコアルータに向けて最終宛先ノード６０２に転送する。最終宛先ノード６０２は受け取ったＲＥＦＲＥＳＨパケットのルーティングリストと、予約オペレーション中に決定されたそのローカルコピーとを比較する。もしこれらのリストが同じである場合は、宛先ノードは空のルーティングリストとともにＡＣＫメッセージを発行するか、さもなければセットオンされた経路変更フラグ（Ｆｐｃ）を持つＡＣＫメッセージ、および新しいルーティングリストを発行する必要がある。それは新しいルーティングリストを含み、ソースが新しい経路を正しく受け取ったことを表す新しい経路のための予約パケットを受け取るまで、すべてのＡＣＫメッセージにおいてＦｐｃを設定する。
【００３６】
セットオンされた経路変更フラグを持つＡＣＫメッセージを受け取った後、ソースはその古いリストとＡＣＫメッセージにおいて受け取られた新しいリストとに共通だったアドレスを含むＬｒｏｕｔｅｒ＿ｏｌｄとともに予約パケットを発行する。これにより、宛先ノードへの新しい経路上の新しいルータだけが他の予約を行う必要がある。ＡＣＫメッセージが繰り返しでありソースがすでに新しく変更された経路のための予約位相を開始している場合は、ＡＣＫメッセージは無視される。
削除位相
データ流れに割り当てられた資源を解除するために、ソースはセッションを終える前にＤＥＬＥＴＥメッセージをしなければならない。この流れが実際に予約を行ったコアルータにおいてのみ資源が削除されることを確実にするため、ソースはＬｒｏｕｔｅｒ＿ｏｌｄにある流れのルーティングリストを含む。自身のアドレスをＬｒｏｕｔｅｒ＿ｏｌｄリストに見出したそれぞれのトラバースされたルータは削除メッセージに表された量だけ割り当てられた資源の値を低減し、予約パケットを次のルータに対し宛先ノードに向けて転送する。ＤＥＬＥＴＥメッセージは予約パケットであるＲＥＳＶに類似のコアルータにおいて処理される。すなわち、これらはＲＡＣＫメッセージによって承認される。ＤＥＬＥＴＥメッセージが失われている場合は、ソースはどのポイントまで削除オペレーションが良好だったかを表すＮＡＣＫメッセージを受け取る。この場合、ソースは他のＤＥＬＥＴＥメッセージを再送する必要がある。
【００３７】
予約パケットの場合については、Ｌｒｏｕｔｅｒ＿ｏｌｄは予約がすでに行われたルータのリストを表す。削除の場合については、Ｌｒｏｕｔｅｒ＿ｏｌｄは削除オペレーションがまだ進行していないルータを表す。従って、Ｌｒｏｕｔｅｒ＿ｏｌｄはここでは流れによってトラバースされる経路に含まれていてＮＡＣＫメッセージには含まれていないルータのリストを表す。
【００３８】
削除オペレーションとともにソースベースルーティングを使用することは、経路の変更による資源の浪費を低減する際に非常に大きな価値がある。すなわち、経路における変更の後、ソースはすべての新しくトラバースされた経路において新しい予約を行う必要があり、もはやトラバースされない古い経路の部分において予約される資源は浪費される。ソースベースルーティングを使用することによって、ソースは古い経路に設定されているルーティングリスト（Ｌｒｏｕｔｅｒ）およびもはやトラバースされないルータのアドレスを含むＬｒｏｕｔｅｒ＿ｏｌｄと共に削除パケットを送ることができる。そしてそれぞれのルータは、自身の現在のルーティングテーブルには基づかずにＬｒｏｕｔｅｒのルーティング情報を使用してＤＥＬＥＴＥパケットを転送する。自身のアドレスをＬｒｏｕｔｅｒ＿ｏｌｄに見出したそれぞれのルータはＤＥＬＥＴＥ要求によって表された資源の量を削除する必要がある。
【００３９】
ここまでは本発明をユニキャスト、すなわち、１つのソースおよび１つの目的とする宛先ノードがある場合に関連するとして説明してきた。本発明はマルチキャスト機能にも応用できる。このような状態においては、宛先ノードはソースのずっと後にセッションに加わることができる。マルチキャストの場合には、新しい宛先ノードはＲＥＦＲＥＳＨパケットを待ち、そして「オン」に設定された経路変更フラグを持つＡＣＫメッセージ、およびＲＥＦＲＥＳＨパケットに表されたルーティング情報を送る必要がある。新しい宛先ノードからＡＣＫメッセージを受け取った後、ソースは宛先ノードに対して予約パケットであるＲＥＳＶを発行する必要がある。重複予約を避けるために、ソースは二次元リストを維持しており、リストの一方の軸はマルチキャストパケットによってトラバースされたすべてのルータのアドレスをもっており他方の軸はすべての宛先ノードを列挙している。このリストのそれぞれのエントリは、宛先ノードＸがコアルータＹをトラバースしている最中かどうかを表している。新しい宛先ノードがセッションに加わる場合は、ソースはＡＣＫメッセージに表示されているように宛先ノードに向かってルーティングリストをチェックし、どのルータがそのリストにとって新しいかを判断する。そして予約はこれらの新しいルータについてのみ必要とされる。すなわちソースは、この宛先ノードに向かう経路上にありすでに他の宛先ノードへの経路上に含まれているすべてのルータを列挙しているＬｒｏｕｔｅｒ＿ｏｌｄリストと共に予約パケットであるＲＥＳＶを発行する。期間にわたってある宛先ノードからソースがＡＣＫメッセージを得ない場合は、この宛先ノードはセッションを去っていると判断されてソースはこの宛先ノードのために予約されている資源を削除するように構成される。もしソースルーティングがサポートされる場合、ＤＥＬＥＴＥメッセージが、失敗した宛先ノードによってのみトラバースされるルータのリストを表すＬｒｏｕｔｅｒ＿ｏｌｄリストおよび宛先ノードに向かうルーティングリストを表すＬｒｏｕｔｅｒとともに宛先ノードに向かって送られる。そしてＬｒｏｕｔｅｒ＿ｏｌｄリストに含まれるルータはＤＥＬＥＴＥメッセージに表示されているようにソースを削除しなければならない。
【００４０】
マルチキャストまたはユニキャストステートのいずれにおいても、ＰＱｏＳシステムは大量のデータを保存するのにコアルータを必要としない。むしろ、コアルータはすべての流れについてすでに予約されている資源の合計についての情報を維持することだけを必要とする。予約されている資源の正確な合計はＲＥＳＶおよびＤＥＬＥＴＥメッセージの情報を使用して維持することができるが、明白な削除メッセージに頼ることは不一致の問題を引き起こす可能性がある。ＤＥＬＥＴＥメッセージの損失、ノードの失敗、経路の変更、またはＤＥＬＥＴＥメッセージを発生しない不完全なＰＱｏＳ実行によりいくつか問題が発生する可能性がある。従って、ＰＱｏＳは予約されている資源の量を評価するためにＲＥＦＲＥＳＨパケットを利用する。流れＦＩ７００ａの場合を表している図７、および予約されている資源の量を決定する筋書きを考慮する。ソースは自身の流れついて予約されている資源の量（Ｂｒｅｓｖｉ）を表すＲＥＦＲＥＳＨパケットをＴ０秒ごとに伝送する。従って、間隔（ｔ，ｔ＋Ｔ０］７０２ａにおけるすべての流れのＢｒｅｓｖｉのすべての値の合計は、この期間中の予約された資源（Ｒｒｅｓｖ）全量を表すこととなる。
ここで、
【００４１】
【数１】
2004508739.tif 000003
しかしながら、パケットが直面する可能性のあるバッファリング遅延におけるジッタにより、ルータは間隔（ｔ，ｔ＋Ｔ０）７０２ａにおけるすべての流れからはＲＥＦＲＥＳＨパケットを受け取らない可能性がある。この流れの第１のＲＥＦＲＥＳＨパケットは間隔（ｔ，ｔ＋Ｔ０）７０２ａのオブザベーション間隔７０４のすぐ外で受け取られる。第２の例においては、流れＦＩ７００ｂはちょうどＴ０秒後に送られ、（Ｔ０＋Ｔｊｌ：Ｔｊｌ・Ｔ＜Ｔｊ）秒後に受け取られるため、間隔（ｔ＋Ｔ０，ｔ＋２Ｔ０）７０２ｂに当てはまる。この状態に対処するためには、ルータは遅れて到着するＲＥＦＲＥＳＨパケットを同様に考慮して取る必要がある。最大限の遅延ジッタを（Ｔｊ）７０６に設定するには、ルータは（ｔ，ｔ＋Ｔｊ＋Ｔｊ）間隔中にＲｒｅｓｖを決定する必要がある。このようにして決定されたＲｒｅｓｖは、実際には間隔（ｔ，ｔ＋Ｔ０）においてすでに予約された資源の上限である。ＲＥＦＲＥＳＨパケットはＴ０期間において送られるため、ルータは同様にＴ０ごとに新しいオブザベーション期間を開始する必要がある。しかしながら、送れて到着することを計算に入れるためにオブザベーション期間は（Ｔ０＋Ｔｊ）７０８の長さである必要があるため、Ｒｒｅｓｖは同じ流れからの重複ＲＥＦＲＥＳＨパケットを含む可能性がある。図面が示すように、（ｔ＋Ｔ０，ｔ＋２Ｔ０）間隔中は、流れＦｌ７００ａのＲＥＦＲＥＳＨパケットは二度カウントされる。このことはルータを過小利用する結果となる可能性があるものの、予約されている資源に上限を与えて、これらのニーズにこたえる確実に適切な資源がない限りは新しい流れを許可しないようにするものである。このようなアプローチを利用することにより、ルータの平均利用レベル（Ｕ）は以下のように概算することができる。
【００４２】
【数２】
2004508739.tif 000004
遅延ジッタの問題に加えて、ＲＥＦＲＥＳＨパケットがドロップする可能性があるため、これらの流れによって消費される帯域幅のシェアはＲｒｅｓｖを決定される場合には計算には入れられない。損失の影響を低くするためには、ルータはｎ個のオブザベーション間隔のウィンドウ中における最大観測Ｒｒｅｓｖをとる必要がある。さらに、コアルータは自身の利用可能な資源（Ｒ）のすべてを割り当ててはいけないが、（Ｒｒｅｓｖ＞Ｒ×σ：σ＜１）の場合については新しい流れを拒絶する。ここに述べる方法により、コアルータはＴ０秒期間ごとに（Ｔ０＋Ｔｊ）７０８の長さのオブザベーション間隔を開始する。ルータはｎ個のオブザベーション間隔（Ｒｒｅｓｖｏｌｄ）の最後のウィンドウにおいて観察された値を記載している変数、および現在のオブザベーションウィンドウ（Ｒｒｅｓｖ ｃｕｒｒｅｎｔ）のオブザベーション間隔のいずれかにおいて測定された予約されている資源の最大カウントを記載している変数を維持している。新しい予約または削除要求を受け取った後、ルータは要求される量によってＲｒｅｓｖ ｏｌｄおよびＲｒｅｓｖ ｃｕｒｒｅｎｔを増やすか減らす必要がある。
【００４３】
そしてＢ資源を要求している流れは以下の場合についてのみ許可される。
【００４４】
最大（Ｒｒｅｓｖｏｌｄ，Ｒｒｅｓｖｃｕｒｒｅｎｔ）＋Ｂ＜Ｒ×σ
ソースおよびコアルータはパケットの損失を決定するためにタイムアウトを使用する。すなわち、ソースは予約パケットかそれに対する承認が失われたと結論づける前にＴｓ秒待つ。エッジエレメントおよびコアルータは、もしＴＲｉ秒あとに次の上流のルータによって予約パケットが承認されなかった場合、予約パケットは失われたと判断する。さまざまなタイマーにおいて値を設定する場合は、ソースの（Ｔｓ）タイマーがいずれのルータのタイマー（ＴＲｉ）にも先立って、またはソース向かってネガティブな承認（ＮＡＣＫ）が送られている最中に、期限切れとなっていないことを確認することが重要である。
【００４５】
次のルータ（Ｒｉ＋１）に対して予約または削除要求を転送し、それに対する商人を受け取る間にコアルータ（Ｒｉ）において経過し得る最大時間（Ｔｒａｃｋ）はＤｉ，Ｄｉ＋１，Ｄｒｔｔｉ，ｉ＋１、およびＴｒｏｕｔｅｒの合計であり、ここでＤｉはＲｉおよびＲｉ＋１を接続しているリンクの入力インターフェースにおけるバッファリング遅延であり、Ｄｉ＋１はＲｉ＋１およびＲｉを接続しているリンクの入力インターフェースにおけるバッファリング遅延であり、Ｄｒｔｔｉ，ｉ＋１はＲｉおよびＲｉ＋１間の往復移動伝播遅延であり、Ｔｒｏｕｔｅｒは２つのＲＡＣＫメッセージを送る間の時間である。ルータＲｉにおけるバッファリング遅延の値はＲｉに知られると推測でき、ＲＡＣＫメッセージ同士で交換される。往復移動伝播を決定するために、ルータは自身のＲＡＣＫメッセージの中に、いつこのパケットが送られたかを表すタイムスタンプ（Ｔｓｔａｍｐ）を含んでいる。例えば、ルータＲｉはｔｌにおいてＲＡＣＫメッセージをルータＲｉ＋１に送る。そしてルータＲｉ＋１はＲｉに対する自身のＲＡＣＫメッセージの中に、タイムスタンプ（ｔｌ）、ならびにＲｉからＲＡＣＫメッセージを受け取ってから自身の（Ｔｗａｉｔｉ）を送る間に経過した時間を含んでいる。Ｒｉ＋１からＲＡＣＫメッセージが到着した時間（ｔ２）、送付タイムスタンプ（ｔｌ）およびＴｗａｉｔｉを組み合わせることで、ルータＲｉは以下のようにしてＲｉ＋１への往復移動伝播遅延Ｄｒｔｔｉ，ｉ＋１を決定することができる。
【００４６】
Ｄｒｔｔｉ，ｉ＋１＝ｔ２−ｔ１−Ｔｗａｉｔｉ
Ｄｒｔｔｉ，ｉ＋１の計算はルータＲｉおよびルータＲｉ＋１の両方で起こり得るバッファリング遅延を含んでいるため、ルータは実際の伝播遅延としてＤｒｔｔｉ，ｉ＋１の最小値をとらなければならない。エッジエレメント、ソース、および宛先ノードの間の伝播遅延を正確に見積もりできない場合は、エッジエレメントにおいてはこれらのＴｒａｃｋを設定するためには実際の伝播遅延ではなく大きな省略値を使用しなければならない。それぞれのルータは要求メッセージの中のＴｄｅｌａｙフィールドに対して自身のＴｒａｃｋの値を付け加える。これにより、宛先ノードに到着したとき伝播遅延であるＴｄｅｌａｙは、ソースにおいて予約パケットを送ってから返答としてネガティブな承認を受け取る間の最大時間を表すことになる。要求メッセージの最大エンド対エンド往復遅延は以下の構成要素からなる、すなわち、Ｄｕｐｓｔｒｅａｍ、Ｄｄｏｗｎｓｔｒｅａｍ、Ｔｆｅｅｄｂａｃｋ、およびＴｒｔｔである。ここで上流遅延であるＤｕｐｓｔｒｅａｍはソースから宛先ノードへの途中のルータにおけるバッファリング遅延であり、Ｄｄｏｗｎｓｔｒｅａｍは宛先ノードからソースへの途中のルータにおけるバッファリング遅延であり、フィードバック遅延であるＴｆｅｅｄｂａｃｋは、宛先ノードにおいて要求を受け取りスケジュールされた承認をそれに答えて送る間に経過し得る時間であり、Ｔｒｔｔはソースと宛先ノードとの間のエンド対エンド往復移動伝播遅延である。ここで、Ｔｆｅｅｄｂａｃｋはプロトコルの広域変数に設定するか、またはＡＣＫメッセージの別のフィールドとして保持できる。Ｔｄｅｌａｙはバッファリング遅延の組み合わせ（ＤｕｐｓｔｒｅａｍおよびＤｄｏｗｎｓｔｒｅａｍ）ならびに伝播遅延（Ｔｒｔｔ）についての控えめな見積もりである。実際には、Ｔｄｅｌａｙは両方向に同じルートを取るパケットの遅延を見積もるものであり、これは必ずしも承認パケットの場合ではない。ソースタイマーであるＴｓが、ポジティブなものにしろネガティブなものにしろ承認を受け取る前に期限切れとならないことを確実にするために、ソースはＴｓを以下に設定する。
【００４７】
Ｔｓ＝ｍａｘ（Ｔｄｅｌａｙ，ｍａｘ（Ｔｒｅｃｖ−Ｔｓｅｎｄ））＋Ｔｆｅｅｄｂａｃｋ
ここで、Ｔｓｅｎｄはある要求メッセージ（Ｍ）のタイムスタンプであり、Ｔｒｅｃｖは要求Ｍに対する承認が受け取られた時間である。従って、ｍａｘ（Ｔｒｅｃｖ−Ｔｓｅｎｄ）という表現は、ソースと宛先ノードとの間で測定される最大往復移動遅延を表す。さらに、ソースは予約パケットの中の遅延時間Ｔｄｅｌａｙを照会位相中に決定されたＴｄｅｌａｙに設定する。ソース−エッジエレメントセットはそのタイマーＴＲＥを以下のように設定する
ＴＲＥ＝Ｔｄｅｌａｙ−ＤＲＥ−Ｄｒｔｔ
ここで、ＤＲＥはソースとエッジエレメントとを接続しているリンクに到着するパケットについての最大バッファリング遅延であり、Ｄｒｔｔはソースとエッジエレメントとの間の往復移動伝播遅延またはその見積もりである。次のルータに予約パケットを転送する前に、エッジエレメントは要求においてＴｄｅｌａｙをＴＲＥに設定する。
【００４８】
コアルータルータにおいては、それぞれのルータｉはそのタイムアウトＴＲｉを以下のように設定する。
【００４９】
ＴＲｉ＝Ｔｄｅｌａｙ−Ｔｒａｃｋｉ
そして予約パケットの遅延時間ＴｄｅｌａｙをＴｒａｃｋｉによって同様に短縮する。
【００５０】
ＰＱｏＳソースの挙動を図８に表す。ここで、入力事象ステップ８００は決定エレメント８１０に提出される。決定エレメント８１０は入力事象を照会して、それがタイムアウト８１２、ネガティブな承認メッセージＮＡＣＫ８１４、または承認メッセージであるＡＣＫ８１６を含んでいるかどうかどうかを確認し、それに応じて事象を転送するように構成されている。もし事象がＡＣＫ８１６を含んでいる場合、事象は決定エレメント８１８に送られ、報告されているルーティングリストが望まれているものと異なるかどうか照会される。もしルーティングリストが望まれているものと食い違わない場合、スケジュールは次のルーティンＲＥＦＲＥＳＨに提出され、入力事象ステップ８００に進むことによってループが繰り返される。もしルーティングリストが望まれているものとは食い違う場合は、エレメント８２２に進む。エレメント８２２は予約パケットであるＲＥＳＶを送るように構成されている。そして、入力事象工程８００に進む。もし事象がＮＡＣＫ８１４を含んでいる場合、Ｌｒｏｕｔｅｒ＿ｏｌｄを持つ予約パケットであるＲＥＳＶはＮＡＣＫに表されている履歴に設定され、入力事象ステップ８００に進むことによってループが繰り返される。入力事象ステップ８００がタイムアウト８１２を含んでいる場合は、ＲＣＨＥＣＫメッセージを送って入力事象ステップ８００に進む。
実施問題
コアルータに要求メッセージの内容をより厳密に審査するよう警告するために、ＩＰルータ警告オプションとともにＰＱｏＳメッセージがＩＰパケットに保持されている。データとコントロール通信とを区別するには、ユニキャストの場合には異なるポート番号を使うだけで十分である。マルチキャストの場合には、宛先ノードはマルチキャストされたデータ流れを、それについての予約が行われる前に受け取ることは認められない。しかしながら、宛先ノードは承認を送る前にＲＥＦＲＥＳＨパケットを待つ必要があるため、マルチキャストされたコントロールデータはそれがコントロールしているデータ通信から完全に隔離されねばならない。このような隔離により、コントロールおよびデータ通信についてネットワークが異なるマルチキャストツリーを確立する状態において問題が生じてしまう場合がある。両方のマルチキャストセッションは同じソースおよび宛先ノードを持っているため、このような状態が生じる見込みはほとんどない。最長時間を決定する際に、ネガティブな承認が宛先ノードに到着する可能性があり、ＰＱｏＳは損失のない内部ルータ通信を取り得る。このような状態を実現するために、ＲＡＣＫメッセージはネットワークにおいてもっとも高い優先度で伝導される必要がある。起こり得る損失に対処するために、コアルータは受け取った流れのアイデンティティーをＲＡＣＫメッセージにおいてｎ回再送してよい。この場合、ＲＡＣＫへの時間であるＴｒａｃｋの計算は以下のように改変される必要がある。
【００５１】
Ｔｒａｃｋ＝Ｄｉ＋Ｄｉ＋１＋Ｔｒｔｔｉ，ｊ＝ｉ＋ｎ×Ｔｒｏｕｔｅｒ
ここで、Ｔｒａｃｋ、すなわちルータ承認は予約または削除要求を転送する間に経過し得る最大時間であり、ＤｉはＲｉとＲｉ＋１とを接続しているリンクの入力インターフェースにおけるバッファリング遅延であり、Ｄｒｔｔｉ，ｉ＋１はＲｉとＲｉ＋１との間の往復移動伝播遅延であり、Ｔｒｏｕｔｅｒは２つのＲＡＣＫメッセージを送る間の時間であり、ここでＴｒｔｔｉ，ｉ＝１は、ソースノードと宛先ノードとの間のエンド対エンド往復移動伝播遅延である。
価格設定ベースのサービス
特定のＱｏＳレベルを要求することは、本質的には適切な帯域幅割り当てに対する要求であり、このような割り当てにより要求されたＱｏＳレベルをサポートするのに十分な帯域幅が提供されるものである。帯域幅の売り主として、ネットワークプロバイダはできるだけ多くの帯域幅を売りたいと考えるであろうが新しい入力要求を拒絶する必要が生じるほど多くではないであろう。従って、利用可能な帯域幅がすべて数個の宛先ノードに割り当てられるような場合を避けるために、ネットワークプロバイダは帯域幅の価格を引き上げて、用立て可能な供給が既存の需要に一致するようにする。このように一致させることで、もっとも渋滞する期間中はより高い価格またはより重要なデータだけがネットワークに入ることが確実となる。必ずしも金銭的価値を参照するわけではないものの、金銭的価値は価格設定の要素として利用し得る点に留意するべきである。例えば、ドメイン内ネットワークにおいては、被雇用者の立場が価格設定の基本として利用される。この種の渋滞価格設定は２つの意味合いの内の１つを持っている。もしネットワークプロバイダが渋滞状態に従ってネットワークの資源の価格を調整し続ける場合、価格は予測できない。なぜなら価格はプロバイダが提供できる帯域幅の量およびネットワーク内のユーザーの数に左右され、これらは両方とも動的数字であるからである。このことは活動および通信費用を前もって企画したいと考えるユーザーにとっては企画を混乱させるものである。もし確立している流れの価格をネットワークプロバイダが一定に保つと決めたとしても、ある接続の価格はそれでもネットワーク内のユーザー数および負荷状態によって変動するであろう。しかしながら接続を確立した後は、通信費用は固定され予測可能となる。しかしながらこのことは、同時に到着するものの順次処理される２つの予約パケットが異なる価格を持つという意味では不公平をもたらす。この明らかな二分状態は、予測可能な固定価格および渋滞価格設定を組み合わせることによって解決される。このような解決策は、図９に表される関数に類似の形状を持つ価格機能を利用することを提案している。この関数は、ネットワークプロバイダが帯域幅またはその他の資源を豊富な場合には固定相場価格９００で売れるようにする。しかしながら、ネットワーク資源が不足してくると、帯域幅の価格は上昇する９０４。ネットワーク資源の豊富さはネットワーク利用９０２と緊密な相互関係があり、ネットワーク利用のレベルがより高くなるにつれて、新しい通信にとって利用できる資源は少なくなる。価格設定関数の正確な形状は、プロバイダによって招かれる実際の費用、希望される利用レベル、およびユーザー数に左右される。固定で予測可能な価格９０６を要求するユーザーを満足させるために、ネットワークプロバイダは柔軟性、および他の種類の価格設定ベースのサービスを喜んで採用するという他のネットワークユーザーの意志を考慮し得る。費用もまた、夜間または週末などの予測されるネットワーク負荷に基づいて割り当てることができる。さらに、ネットワーク負荷の安定性を使用して、将来ネットワークがどのように負荷されるかについてよりよく理解することができる。ネットワーク資源についての価格を設定する際に、内部または外部要因に基づいたネットワーク予測可能性もまた利用し得る。これは高度に自動化されたネットワークにおいて特に有用である。
固定価格および固定品質サービス（ＦＰＦＱ）
固定価格および固定品質サービス（ＦＰＦＱ）は、固定で予測可能な価格を要求しており、ネットワーク付加状態に従って自身のＱｏＳ要件を適合させる意志がないかまたは適合させることができないユーザー向けに設計されている。収益性を確実にするために、たとえ利用可能なネットワーク資源のほとんどが割り当てられていても、ネットワークプロバイダは必ずサービスを固定相場より高く値段付けするであろう。従って、ＦＰＦＱユーザーはたとえ大量の資源があっても固定価格およびＱｏＳに対する割増金を支払う。この場合、ＦＰＦＱユーザーはＱＵＥＲＹパケットにおいて、必要とするネットワーク資源の量を表示する。トラバースされたコアルータは新しい流れに対処するのに十分な資源を持っていると仮定して、必要とされた資源の価格を表示する。もし十分な資源が得られない場合は、ＱＵＥＲＹメッセージの資源フィールドはルータにおいて利用可能な資源の量を反映させるように調整される。そしてソースは低減されたレベルのサービスを受け入れるかセッションを取りやめるかを決定しなければならない。ネットワークが要求される資源をサポートできるか、またはソースが照会の結果に従って自身の予約を調整する意志がある場合は、ソースは所望のＱｏＳレベルを表す予約パケットであるＲＥＳＶを発行する。このＦＰＦＱサービスに対する予約を受け取った後、ルータはＲＥＦＲＥＳＨパケットにおける帯域幅要件であるＢｒｅｑ、および価格であるＰフィールドする必要はない。なぜならこれらはデータ流れの継続時間中は固定だからである。
固定価格および可変品質サービス（ＦＰＶＱ）
ユーザーは自身の財政的能力を知っているため、あらかじめ設定された価格でもっともよいと思われるサービスを提供するサービスを選択するであろう。従ってＦＰＶＱユーザーは、セッション開始後、特定の量の資源を受け取る。ネットワークの渋滞および資源価格の変更により、ＦＰＶＱサービスのユーザーに提供される資源の量は変更する。伝送されたデータが失われることを避けるために、ユーザーは伝送挙動を調整して変更されたネットワーク負荷コンディションに調和する必要がある。伝送挙動は帯域幅の使用を含む。照会位相の最中は、ユーザーは価格設定フィールドＰにおいてユーザーが支払う意志のある価格を特定する。トラバースされたルータは、自身の現在の負荷および価格状態に従って帯域幅フィールドであるＢｒｅｑを調整する。従って、ソースにおいて受け取られたＡＣＫメッセージは、ユーザーが特定の価格で得ることのできる資源の量を表している。もし利用可能な資源が適切であれば、ソースはＲＥＳＶ要求を開始する。ＲＥＦＲＥＳＨパケットにおいて、ルータは負荷および価格の変更に従って帯域幅フィールドＢｒｅｑを調整する。そしてエッジエレメントは自身の監視または整形パラメータを調整して、資源割り当ての動的変更をネットワークに反映する必要がある。
可変価格および固定品質サービス（ＶＰＦＱ）
いくつかの状態において、ユーザーは資源消費に容易に合わせることができない。これは例えば、電話データ流れをともなう場合である。このような状態では、ユーザーは、資源消費が比較的柔軟でないにもかかわらず、やはり固定相場および固定ＱｏＳサービスについて査定されるよりも低い価格の恩恵を受けることになる。これらのユーザーは可変価格および固定品質サービスの候補者である。ＶＰＦＱプロバイダは一種のリスク刺激策を提供する。ユーザーはＱＵＥＲＹメッセージにおいて必要とする資源の量を特定する。中間ルータは価格設定フィールドを調整して、要求された資源の価格を表示する。もし、おそらくソースの財政的資源が制限されているか、または単に十分な帯域幅がないために要求された資源が割り当てられない場合は、ＱＵＥＲＹメッセージの資源フィールドはルータにおいて利用可能な資源の量に設定される。そしてソースは低減されたＱｏＳレベルを受け入れるかセッションを放棄するかを決定しなければならない。周期的なＲＥＦＲＥＳＨパケットにおいて、ルータはソースに現在の価格を知らせる。もし価格がユーザーの支払い能力を超える場合は、ネットワークアーキテクチャは通信を終了するか、またはＱｏＳを低減する。さらに、エッジエレメントはユーザーのために自身のアカウンティング情報を調整して価格の動的変動をネットワークに反映させる。
ハイブリッドサービス
上述のサービス例においては、考慮されたモデルは固定データ流れ予約、データ流れの継続時間中固定されている価格をもっているか、またはＲＥＦＲＥＳＨパケットの細分性をともなった変動予約または価格を持っていた。他のモデルをさらに拡張して帯域幅リースの場合に対処することもできる。すなわち、ソースは接続の寿命よりも短い期間中において、固定価格およびＱｏＳレベルを要求する。このようなサービスは複数の方法によって実現することができる。より簡素な方法の１つはそれぞれの位相、またはデータ流れにおける期間中に予約パケットを再発行することである。例えば、ソースは固定価格およびＱｏＳを要求する場合、ソースのニーズを表す予約パケットを送る。データ流れパラメータが変更する期間中は、ソースはその古い資源を削除して新しいパラメータにより新しい予約を開始することができる。他の選択肢は、ネットワークが固定価格およびＱｏＳを提供することを希望する期間の長さをソースが予約パケットに表示することである。この期間の終了後、ソースはネットワークと価格およびＱｏＳレベルを再交渉する必要がある。このようなアプローチを利用することで、エッジエレメントは交渉された期間中、特定のＱｏＳレベルに所属するとして流れをマーキングする。もし、この期間後に、新しい価格およびＱｏＳレベルを交渉しない場合は、エッジエレメントはこのソースから到着するすべてのパケットをドロップするかまたは最善を尽くしたパケットとしてそのデータを送るか、さもなければより低いレベルのサービスとする。ハイブリッドの場合におけるサービスの価格は、より長い交渉されたデータ流れ期間の場合において上昇した価格に適合するサービスの価格よりも高くなる可能性がある。
価格予測可能性およびルーティング
それぞれのトラバースされたコアルータは、特定のサービスについてユーザーが支払う必要のある最終的な価格に寄与するため、最終的な価格はトラバースされたコアルータの数によって変更となる可能性がある。しかしながら、流れの経路に沿ったコアルータの数はともすると流れの寿命中変動し得る。そしてこのような経路の変更は、たとえＦＰＦＱサービスにおいてさえも、単一のデータ流れの最中に使用される類似の接続の価格に違いが生じる結果となる可能性がある。一対のエンドシステムについて２つのエンドシステム間でルートを固定する必要なしに固定の価格を得るために（例えばソースノードおよび宛先ノード）、一方が相対的価格を使用してよい。すなわち、コアルータにおける資源の実際の価格を予約パケットの価格フィールドに付け加える代わりに、コアルータは単に、固定価格と比較して要求される資源がどれくらい高いかを常時するだけでよい。従って、もしコアルータが価格設定関数において固定価格領域にあった場合は、ゼロが価格フィールドに付け加えられる。さもなければ、価格設定関数によって表される価格は基本価格で割り算されこの値が付け加えられる。従って、もし要求が渋滞していないネットワークを通過する場合、流れがどのルートを取るかにかかわらずユーザーには基本価格を請求される。渋滞しているネットワークを通過する場合は、渋滞しているコアルータだけが価格の上昇に寄与する。
【００５２】
マルチキャスト通信の筋書きでは、宛先ノードをソースに接続している経路は容量が変動する可能性がある。このような不均質性に対処するために、ソースはさまざまな戦略を利用し得る。まず第１に、ソースは均質な予約を試みる。この場合、ソースは単一のＱｏＳレベルを使用してすべての宛先ノードに向かう経路を予測してこのＱｏＳレベルをサポートする。ここでは、固定ＱｏＳレベルだけを使用することができる（すなわち、ＦＰＦＱまたはＶＰＦＱサービス）。そして宛先ノードは、宛先ノードによって受け取られたＲＥＦＲＥＳＨパケットがソースからのルートが必要なＱｏＳレベルをサポートするのに十分な資源を持っていることを示す場合にのみセッションに加わることができる。より柔軟な筋書きにおいては、ソースはもっとも劣悪な経路によってサポートされているＱｏＳレベルの使用を選択する可能性がある。この場合、新しい宛先ノードがセッションに加わることを希望しており、新しい宛先ノードに向かうＲＥＦＲＥＳＨパケットが、ソースと新しい宛先ノードとを接続している経路が現在のレベルよりもかなり劣悪であることを示している場合、ソースは新しい低減されたＱｏＳレベルに適合する必要があり、ソース−エッジエレメントはその整形または監視パラメータを新しいＱｏＳレベルに従って変更する必要がある。もし均質な予約が適切でないかまたは選択されない場合、ソースは層状伝送を選択する可能性がある。層状データ伝送は、ソースがそのデータをｎ個の異なる層に分割することを可能とする。ソースから宛先ノードへの経路上における資源利用可能性に基づいて、宛先ノードはｎ個の層まで参加できる。そして層の数および異なる層に割り当てられる資源の数は、宛先ノードおよびネットワークの均質性に基づいて調整することができる。
【００５３】
ユニキャストの場合については、予約された資源および送られたデータの量の金額は、コントロールパケットの単純なコントロール情報を利用してソースノードまたは宛先ノードのいずれかに請求するか、または両方のノードで分割することができる。マルチキャストセッションの場合については、通信の費用をソースに請求する点はユニキャストの場合と同じである。しかしながら、宛先ノードが支払いをするようサポートされている場合、問題はより困難である。宛先ノードは映像会議または電話を含む状況においては支払う見込みがある。マルチキャストグループに加わる場合、宛先ノードが直接責任を負うのは宛先ノードをマルチキャストツリーに接続しているリンクをトラバースするデータに対してのみである。すべての宛先ノードはマルチキャストツリーのリンクを共用している可能性がある。ソースにおいて維持されているルーティングテーブルは、どの宛先ノードがどのコアルータを共用しているかを表している。これは宛先ノードの間で費用を分配するための良好な根拠となり得る。
【図面の簡単な説明】
【図１】エンド対エンドネットワーク予約の一例の図である。
【図２】ＰＱｏＳルータにおけるホップバイホップ承認プロセスを表すフローチャートである。
【図３】ＰＱｏＳルータにおけるコントロールメッセージ処理を表すフローチャートである。
【図４】ネットワーク簡素化エンド対エンド予約の概略図である。
【図５】ネットワーク上で良好に行われた資源予約の概略図である。
【図６】ネットワーク上で失敗した資源予約の概略図である。
【図７】予約する資源の量を決定する筋書きの概略図である。
【図８】ＰＱｏＳ送り手の挙動を表すフローチャートである。
【図９】価格設定モデルであり、価格をネットワーク利用のレベルに関連づけたものである。
【図２】
2004508739.tif 000005
【図３】
2004508739.tif 000006
【図４】
2004508739.tif 000007
【図５】
2004508739.tif 000008
【図６】
2004508739.tif 000009
【図８】
2004508739.tif 000010
【図９】
2004508739.tif 000011
【国際公開パンフレット】
2004508739.tif 000012
2004508739.tif 000013
2004508739.tif 000014
2004508739.tif 000015
2004508739.tif 000016
2004508739.tif 000017
2004508739.tif 000018
2004508739.tif 000019
2004508739.tif 000020
2004508739.tif 000021
2004508739.tif 000022
2004508739.tif 000023
2004508739.tif 000024
2004508739.tif 000025
2004508739.tif 000026
2004508739.tif 000027
2004508739.tif 000028
2004508739.tif 000029
2004508739.tif 000030
2004508739.tif 000031
2004508739.tif 000032
2004508739.tif 000033
2004508739.tif 000034
2004508739.tif 000035
2004508739.tif 000036
2004508739.tif 000037
2004508739.tif 000038
2004508739.tif 000039
2004508739.tif 000040
2004508739.tif 000041
2004508739.tif 000042
2004508739.tif 000043
2004508739.tif 000044
2004508739.tif 000045
2004508739.tif 000046
2004508739.tif 000047
2004508739.tif 000048
2004508739.tif 000049
2004508739.tif 000050
2004508739.tif 000051
2004508739.tif 000052
2004508739.tif 000053
2004508739.tif 000054
2004508739.tif 000055
2004508739.tif 000056
2004508739.tif 000057
2004508739.tif 000058
2004508739.tif 000059
2004508739.tif 000060
2004508739.tif 000061
2004508739.tif 000062
2004508739.tif 000063
2004508739.tif 000064
【国際公開パンフレット（コレクトバージョン）】
2004508739.tif 000065
【国際調査報告】
2004508739.tif 000066
2004508739.tif 000067
2004508739.tif 000068