JP2004048662A

JP2004048662A - ネットワークのパス構成のためのビジネス方法および装置

Info

Publication number: JP2004048662A
Application number: JP2003069750A
Authority: JP
Inventors: Daisuke Matsubara; 松原　大典; Satoshi Yoshizawa; 吉澤　聡
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-07-11
Filing date: 2003-03-14
Publication date: 2004-02-12
Also published as: US20040008688A1

Abstract

【課題】広域エリアネットワークでパスを使った通信のときに、各ノードの負荷を低減させる。また、ネットワーク事業者に、新しい収入源を提供する
【解決手段】ネットワーク・プロバイダにより実行される方法で、サービス・プロバイダの各々と複数のパスＱｏＳレベルとの間のリンクを備えるデータベースを異なるＱｏＳレベルの使用に関連した料金スケジュールに基づいて管理する。そして、サービス・プロバイダからＱｏＳパスについての要求を受信し、受信したＱｏＳパスについての要求に応答して、サービス・プロバイダとユーザの間に要求されたＱｏＳパスのセットアップを試みる。成功した場合、サービス・プロバイダからユーザへ要求されたＱｏＳパスでコンテンツを転送し、ネットワーク・プロバイダは、ＱｏＳパスの使用についてサービス・プロバイダから支払いを受け取る。
【選択図】　　　　図７

Description

【０００１】
【発明の属する技術分野】
本発明はサービス品質の要求に適合するネットワーク内のプリセットパスに関する。
【０００２】
【従来の技術】
広域ネットワーク（ＷＡＮ，　Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ　）、とくにインターネットは通信量の増加によるストレージと計算量の過負荷に悩まされており、この問題は憂慮すべき事態になってきている。
【０００３】
資源予約プロトコル（ＲＳＶＰ，　Ｒｅｓｏｕｒｃｅ　ＲｅＳｅｒＶａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ　）は、ネットワーク資源の予約メッセージと確認メッセージが接続される度にデータの通るノード全部で必要とされ、接続が確立される際に長い遅延を作り出すことが多い。ＲＳＶＰおよびマルチプロトコル・ラベルスイッチング（ＭＰＬＳ，　ＭｕｌｔｉＰｒｏｔｏｃｏｌ　Ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ　）ネットワークでは、ネットワークの規模が大きくなるにつれて、接続数とあるノードが処理しなければならない予約のトランザクション数が増大し、これに相応する大きな計算量が各ノードに求められ、またネットワークは必要とする接続やトランザクションを処理できなくなることもある。
【０００４】
最近、インターネット・プロトコル（ＩＰ，　Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）基盤上で動作するアプリケーションが進化し、データの高バンド幅かつリアルタイム転送が必要とされるようになってきた。これらの要求が強いアプリケーションを、例えば、Ｅ−メールのダウンロード、Ｗｅｂページトランザクションのような従来のアプリケーションと区別ものとして、例えば、サービス品質（ＱｏＳ，　Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ　）属性たとえばバンド幅、遅延、及びジッタなどを保証する仮想パス（以下単に「パス」と言う）が使用されうる。データ送信元は、データフローを割り当てるパスを指定してからそのパスにデータを送出して保証されたＱｏＳを得るようにする。
【０００５】
例えば、特許文献１などに記載されているように、従来技術のひとつの方法ではプリセットパスを設定する。プリセットパスは、広域ネットワーク（ＷＡＮ）、例えばインターネットの最初のホップノードと最後のホップノードの間に設定され、最初のホップノードへ直接接続する端末からはじまり最後のホップノードへ直接又は間接に接続する端末で終わるあらゆるパスで使用できる。最初のホップノードと最後のホップノードへ直接接続する多数の端末が、それら自身のパスを設定した場合にはプリセットパスを共有できる。
【０００６】
本明細書で用いているように、ネットワークのエッジ・ノード、サブネットワークのエッジ・ノード、ワークグループのエッジ・ノード、およびゲートウェイは広域ネットワークの最初のホップノードと最後のホップノードの例であり、これらは最初のホップノードと最後のホップノードの間のパスに沿って存在するトランジット（中間）ノードとは対照的である。
【０００７】
ルーティング情報は、非特許文献１によれば、ＷＡＮの最初のホップノードと最後のホップノードの間で交換される。最初のホップノードは宛先端末のＩＰアドレスをプリセットパスへリンクするパステーブルを必要とする。発信元の端末は宛先ＩＰアドレスと一緒に最初のホップノードへパケットを送出する。最初のホップノードは宛先ＩＰアドレスを使用してパステーブルからパスを抽出し、その後選択されたプリセットパスに沿ってパケットを転送する。
【０００８】
特許文献２では、多数のサービス品質（ＱｏＳ）パラメータを指定する接続要求に応答して宛先への第一のパスを選択している。第一のパスに沿った第一の信号の伝送が失敗した場合には、第二のパスがデータベースにしたがって選択される。プリセットパスはＱｏＳについて最新に保持される。
【０００９】
特許文献３では、端末のログオン時に利用可能なプリセットパスを説明している。発信元ネットワーク要素はパスの開始点であり、次のネットワーク要素に向かってパストレース値を送信し、このパストレース値はパストレース値を送信する要素の識別値を有する。受信側要素はパストレース値の識別子を自分自身の識別子に変更してから、変更したパストレース値を次の要素へ再送信すると言う具合にエンドポイントまで続く。それぞれの要素は相互接続情報を保持し相互接続情報を用いてパスを構築するネットワーク管理システムへ送信する。
【００１０】
特許文献４は、同じＩＰネットワーク・アドレスを割り当てられた複数のルータ・インタフェースがＩＰワークグループを作成しホストの再設定を必要とすることなくワークグループ内のどこにでもホストを再配置できるようにしている。単一のアドレスを幾つかの物理ネットワークで使用する。
【００１１】
特許文献５は、ネットワーク内の送信元ノードと宛先ノードの間で最小限しか重複しない複数のパスを決定するためのシステムを開示している。第一のパスと第二のパスが重複している場合、システムは、少なくとも一方のパスを変更してパスの重複を最小限にとどめるようにし、一つのパスでの障害が別のパスの障害を誘発する可能性を減少させるようにしている。
【００１２】
上記従来技術から理解されるように、ＱｏＳパスのセットアップの改良の必要性がある。
【００１３】
一方、ＩＰ（インターネット・プロトコル）の最近の発達で、電気通信事業者は、ＩＰネットワーク基盤について基幹網とアクセス網の双方で多額の投資を行なってきた。しかし、ほとんどの人にとって、とくに消費者は、ＩＰネットワークは非常に低コスト又はときに無料で提供されている。電気通信事業者はＩＰネットワークからの増収に問題を抱えることになった。
【００１４】
従来、ユーザは毎月一定金額を電気通信事業者に支払うが、ネットワーク資源をどの位使用したかとは無関係である（図８の矢印（０）、ユーザからネットワーク・プロバイダ）。また、サービス・プロバイダはネットワーク・プロバイダにネットワーク使用量として毎月一定額を支払う（図８の矢印（０）、サービス・プロバイダからネットワーク・プロバイダ）。場合によっては、インターネット・ショッピングなど、ユーザがサービス・プロバイダにショッピング・サービス又はユーザの購入した商品の支払いを行なうが、これは回線事業者、すなわち、ネットワーク・プロバイダの収入にはならない。電気通信事業者は一定収入を提供するビット伝送サービスを有している。
【００１５】
【特許文献１】
米国特許６，１０８，３０４号
【非特許文献１】
ＩＥＴＦ，　Ｍｕｌｔｉ−ｐｒｏｔｏｃｏｌ　ｌａｂｅｌ　Ｓｗｉｔｃｈｉｎｇ　Ａｒｃｈｉｔｅｃｔｕｒｅ，　ＲＦＣ３０３１，　Ｊａｎｕａｒｙ　２００１
【特許文献２】
米国特許５，９３３，４２５号
【特許文献３】
米国特許６，０９４，６８２号
【特許文献４】
米国特許５，７５１，９７１号
【特許文献５】
米国特許６，２５６，２９５Ｂ１号
【特許文献６】
米国特許６，２５３，２４１号
【００１６】
【発明が解決しようとする課題】
ここに記載したニーズ、また、その他のニーズは、本発明により対処される。
【００１７】
従来技術の分析の結果、本発明の発明者は、ＱｏＳパスの要求を処理する際にネットワーク上での計算負荷とストレージ要求を減少する必要性があることを発見した。
【００１８】
したがって、本発明において問題とその原因として従来技術のシステムの分析を行なったことにより、ＱｏＳパスの要求をより効率的に処理する必要性があることが見出された。
【００１９】
本発明以前においては、ＱｏＳパスの何らかの要求が受信されるのに先立ってパスのセットアップ手順の全部を完了することがＱｏＳを実現する究極的な方法であると考えられてきた。
【００２０】
本発明にあたり、プリセットパスのアプローチでは最初のホップノードがネットワーク内の全ての端末についてのプリセットパスを含むパステーブルを格納し管理する必要があり、これには非常に大きなテーブルの管理が必要になると言う問題があることが分った。テーブルの管理はＱｏＳパスの要求が増大するにしたがって非常に大規模になることが予想される。本発明における分析によると、宛先端末の最後のホップノードが変化した場合、その宛先端末に対するプリセットパスのテーブルを管理している全ての最初のホップノードが当該プリセットパスをこれに合わせて変更する必要があり、これがノードにおける負荷増大の原因の一つであることが示される。宛先端末の最後のホップノードが変化する度に全ての最初のホップノードのパステーブルを更新しなければならないので、端末の位置が頻繁に変化すると問題はさらに悪化する。本発明において問題を分析し、主な原因を決定してこの原因を排除し、さらに宛先端末に関係するＱｏＳの要求が存在した後でのみプリセットパスに対して最後のホップノードと宛先端末を関連付けることにより、このような確認された問題を解決するものである。
【００２１】
サブネットＩＰアドレスを用いて端末を集約することができるが、問題はこれでは解決しない。端末サブネットが小さなグループに分割されサブネットの個数が多くなると、テーブルは巨大になる。
【００２２】
本発明は指定された宛先デバイスへのＱｏＳパスの特定の要求で開始されるＱｏＳパス選択のプロセスに応答して、当該宛先デバイス（サブネットのエッジノード、ＬＡＮ、ＷＡＮなど、または端末）からノードパスへの１つまたはそれ以上のプリセットノードへリンクすることにより問題を解決する。
【００２３】
【課題を解決するための手段】
実施形態ではプリセットパスを使用するが、最初のホップノードは各々の宛先デバイスについてのパステーブルを格納しない。その代わり、最初のホップノードは各々の最後のホップノードに対するプリセットパスを表わすパステーブルを格納する。ＱｏＳパス要求の送信元デバイス、例えばサブネットのエッジノードや端末などは、希望するデータフローのフロー情報とパスを拡張すべき宛先端末とを表わす最初のホップノードへの要求信号を送信する。これに応答して、最初のホップノードは次のような特徴にしたがって指定されたパスにフローを割り当てる：
１）最初のホップノードでは各最後のホップノードを各々のパスにリンクするテーブル（ノードパステーブル）を格納する。
【００２４】
２）送信元及び宛先デバイスが最初のホップノード／最後のホップノードのＩＤを取得する。
【００２５】
３）ＱｏＳパス要求に応答して、宛先デバイスが最初のホップノードへ最後のホップノードＩＤを送信する。
【００２６】
４）宛先デバイス又は最初のホップノードで、特定の要求が最後のホップノードＩＤに関連付けられる。
【００２７】
５）最初のホップノードは最後のホップノードＩＤをつかってノードパステーブルからプリセットパスを抽出し要求状態を送信元デバイスに通知する。
【００２８】
本発明による上記の解決方法は後続のＱｏＳ要求を満たす従来技術のプリセットパスの利点の全部を提供することができ、しかも、ＱｏＳパスの急激に増大する使用を処理する際に生ずるネットワーク内の計算資源及びストレージ資源への従来技術で非常に大きかった要求に関連する従来技術での問題点を解消する。
【００２９】
さらに、本発明はＩＰネットワークのＱｏＳ（サービス品質）資源制御で課金することにより収入を発生させる方法をＩＰネットワーク・サービスの電気通信事業者に提供するものである。サービスはユーザに提供される。本発明により、さらに付加価値の高いサービスを提供することで収入を得る機会を増やすことができる。
【００３０】
ＱｏＳ制御パスサービスは、本明細書で以降「オンデマンド・パスサービス」（ＯＤＰ）と呼び、電気通信事業者向けに開発中である。本発明はＯＤＰサービスで収入を発生する方法を実現する。
【００３１】
特許文献６では、コンピュータ・ネットワーク内でユーザへ情報を送信するために低コストのバンド幅が選択される。サービス・プロバイダはネットワークを使用してユーザへ「マーケティング情報」を供給する。ユーザまたはユーザのプロフィールからの賛助の可能性によって、サービス・プロバイダはマーケティング情報をどのように送信するか決定する、すなわち、どのような種類のＱｏＳを使用するか決定する。サービス・プロバイダは、ネットワーク・プロバイダに対してＱｏＳ伝送料を支払う。サービス・プロバイダは、実際にビジネスを行なう確率が高い顧客（ユーザ）へマーケティングデータを送信するにはＱｏＳが高くさらに高額な方法を選択するようになる。この特許では、ユーザは提供された高いＱｏＳについてネットワーク・プロバイダに支払いは行なわず、前述した月額固定料金を支払うだけである。サービス・プロバイダからネットワーク・プロバイダへ使用ごとの金の流れが、この特許では存在するが、それによってユーザが開始した高品質のフローを可能にしているわけではない。
【００３２】
ユーザ数はサービス・プロバイダの数を大幅に越えるので、本発明に見られるようなユーザが開始したフローは、ネットワーク・プロバイダの収入を拡大する特許文献６の方法より高い可能性を有している。
【００３３】
インターネットへアクセスする技術改良が進歩したため、インターネットではビデオが次の「ｋｉｌｌｅｒ・アプリケーション」になると広く流布されている。こうした理由その他により、インターネットからユーザへのデータの品質供給の必要性が存在する。
【００３４】
また、閲覧時に希望する品質を提供する従来技術による方法の一つは、何らかの種類の伝送を用いてビデオをダウンロードしてユーザの端末へ格納しておき、続けてユーザにより再生するが、これには著作権や遅延の問題が存在する。
【００３５】
【発明の実施の形態】
インタラクティブ・ビデオ通信や高画質ビデオ配信などの用途でＱｏＳを提供するのために、ネットワーク、例えば、図１のＷＡＮでの要求が多くなる。マルチプロトコル・ラベルスイッチング（ＭＰＬＳ）は、ＱｏＳを実現するようにネットワーク経由の専用パスを設定する。パケットスイッチング・ネットワークでは各パケットが宛先識別子を持っており、本明細書ではこれを宛先マシンＩＤと呼ぶことにする。ネットワークが大規模になるとＭＰＬＳパスも個数が増加する。
【００３６】
本発明の実施形態は、図２に示したように、オンデマンド・サービス品質（ＱｏＳ）保証サービスの一部として、ネットワーク・プリセットアップ・フェーズを使用する。ネットワーク・プリセットアップ・フェーズは、例えば、発明の背景で説明した従来技術に開示されているように従来技術によるものである。上記出願の基本的なパス設定技術は、特に本出願の図５及び図６に関連して以下で説明する。
【００３７】
ネットワークは、ノード（ゲートウェイ、端末、エッジノード、中間ノード、スイッチなど）がリンク（幹線、回線など）で結合されるインライン通信で、素材管理システム（ＭＭＳ、Ｍａｔｅｒｉａｌ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ）、ネットワーク管理システム（ＮＭＳ，　Ｎｅｔｗｏｒｋ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ）や幹線管理システム（ＴＭＳ，　Ｔｒｕｎｋ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ）を含むものである。ＴＭＳとＭＭＳは、ネットワーク内の「資源」を予約するように機能し、これによって、ネットワークのリンクが特定のデータ処理能力（例えば１００Ｍｂｐｓ）を持っていると識別される。次に、各リンクのデータ処理能力がノードに対して全体として又は部分として割り当てられ、それらのノードは、ノードのデータ処理能力に基づいてデータ通信及びネットワークへの参加を管理する。
【００３８】
ＴＭＳは図示していないが、図１のノードＡ１、Ａ、Ｂ、Ｃ、Ｄに含まれシステムバスによってメモリへ結合されたプロセッサを含む。メモリは各種テーブルを保持し、これにはＴＭＳ準備テーブル、ＴＭＳ幹線テーブル、ＴＭＳ幹線状態テーブル、ＴＭＳパステーブルが含まれる。テーブルは本発明を理解するのに必要な場合にのみ本明細書で詳細に開示しており、それ以外の従来のテーブルは、不必要に詳細になることにより本発明が不明瞭にならないようにするために、説明しないこととする。
【００３９】
エッジ又はゲートウェイ・ノードＡ１及びＡは、ネットワーク・プリセットアップ・フェーズを実装するために使用され、ノードのインテリジェンスを提供し従来のノード・プロセッサにより実行される制御プログラムをストレージに含む。そして、このプログラムは、ノードパステーブル、ノード幹線テーブル、ノードインタフェース状態テーブル、ノード幹線状態テーブルを含む多数のテーブルでＮＭＳから受信した情報を管理する。ノードインタフェーステーブルは、ノードに関連するアクセスネットワークなどのネットワーク・リンクへ接続するノードの別のインタフェースを識別する。
【００４０】
ネットワーク上の発信元マシンから宛先マシンへ送出されたメッセージ（パケット）には、ノードがネットワーク資源とネットワークを通るパスを割り当てるのに使用するヘッダ情報が提供される。
【００４１】
ネットワーク・プリセットアップ・フェーズ（期間）の間、所定の経路（パス）とあらかじめ設定されたリンク資源（例えば、バンド幅、クラスなど）がテーブル内でＮＭＳにより割り当てられる。従来と同様に、パスのエッジ及び内部ノードはキューイングとバッファリングを含み、これによりある種のＱｏＳクラスで転送レートの設定ができるようになる。ＮＭＳは、エッジノード（最初のホップノードと最後のホップノード）へ、また中継ノード（中間ノード）へ制御情報を送出してキュー制御を設定し、これによりリンクの資源を設定する。同様に、ＮＭＳから図２の最初のホップノード及び最後のホップノードへ送出された制御情報は、代表的にはノードが保持するルーティング情報を変更してこれにより特定のパスを割り当てる。
【００４２】
ＴＭＳルーティングテーブルは、ＮＭＳが初期化の間に準備しＴＭＳへ提供されるが、他のノードへ割り当てられたパスに関係する情報を含む。ＴＭＳルーティングテーブルの一例として、各パスについて、カラムには最初のホップノード、最後のホップノード、パスを形成するネットワークリンクがリストアップされる。ＴＭＳは各ノードに関係するＴＭＳパステーブルの部分をそのノードへ送信する。
【００４３】
ＮＭＳは、最初のホップノード、最後のホップノード、中間ノードを制御してこれらの出力のデータ通信特性を設定し実効的に通信クラスとして（この例ではもクラスＡ）パス又はリンクバンド幅を設定する。従来のディファレンシャル・サービス（ＤｉｆｆＳｅｒｖ）アーキテクチャを用いて、または他のＱｏＳ実装を用いて、出力キューとこれに関係するキュー制御回路は、ノードにパケットを分類、マークづけ、監査、体系化、順位付けさせるように設定する。これによりＮＭＳは、各方向に固有のリンクへ特定のバンド幅を割り当てる。このようなリンクは「暫定リンク」と呼ばれる。暫定テーブルはリンクが接続する二つのノードにより各暫定リンクを識別する。テーブル内で、各リンクには、例えば、バンド幅などの通信特性が割り当てられる。
【００４４】
ＴＭＳによる資源の分散により各ノードにはプリセットパスが提供され、その各々は特定のバンド幅が用意されたネットワークリンクを含む。ノードパステーブルは各ノードが保持して暫定リンクの各々のバンド幅を含む。特定の方向でバンド幅を配分するには、ネットワーク・プリセットアップの間にＮＭＳとＴＭＳにより設定されたパスによって変化するが、各ノードの準備に３又は４方向の数個のリンクにバンド幅を分割することが必要になる。
【００４５】
資源をネットワークリンクに割り当てて、これらの資源をノードに配分した後、ＴＭＳは各ノードについてＴＭＳパス状態テーブルを作成して保持し、これには以下のカラムが含まれる。すなわち、当該ノードで管理される各パス、各パスの暫定リンク識別、各パスのバンド幅、各パスが使用されているか否か、そのパスで利用できる未使用バンド幅の量である。
【００４６】
ノードパス状態テーブルは、ノードの各々が保持しており基本的にＴＭＳパス状態テーブルと同じ情報を含むが、各々のノードだけについてである点で異なる。また、ＴＭＳにより資源を割り当てた際に暫定リンクになるネットワークリンクが識別される。
【００４７】
ノード幹線状態テーブルは、各ノードで処理される通信が変化するので連続的に変化する。ノードを通る通信が開始して停止すると、そのパスでテーブル内に格納されている「利用可能」と「使用中」の資源の量が、使用しているパスに合わせて変化する。さらに、パス状態情報はＴＭＳへ定期的に送出されてＴＭＳパス状態テーブルを変更し、様々なノードパスの状態も反映することができる。しかし、ＴＭＳパス状態テーブルの情報は、状態情報がＴＭＳへどの位速く又どの位の頻度で送信されるかに依存した量だけ、ノードパス状態テーブルのそれを遅延させる。例えば、ノードは自分自身のノード幹線状態テーブルを変更した直後にパス状態情報を送信することがあり、又はもっと少ない頻度で例えば所定の時間間隔の後などで状態情報を送信することもあり、又は他のキーイング・イベントによって情報を送信することもある。
【００４８】
各ノードは、ゲートウェイとして１つ以上のネットワークと接続することがあり、または、一つのネットワークに対して複数の接続を張ることもあり、その結果接続の各々についてインタフェースを有する。各ノードでノードフローパステーブルが作成されて保持され、各インタフェースの資源を識別する、すなわちバンド幅、使用中のバンド幅の量、未だ利用可能な未使用バンド幅の量である。この情報は、各ノードでノードパス状態テーブルにあるパスが保持される情報と同様である。
【００４９】
各ノードの割り当てられたバンド幅は、送信元マシンが要求しＱｏＳデータ転送を許可された場合に使用され、これによって図５に示したように転送が行なわれる長さのデータ通信パスを作成する。図５は図面のパスセットアップフェーズを実行する代表的な方法のフローチャートである。
【００５０】
図５、ステップ１５２：図２のパスセットアップフェーズの第一の通信として最初のホップノードへ接続されたデバイス又はネットワーク上の実体（すなわち、送信元マシン、これは図１と図２の送信元端末である）からＱｏＳパスの要求を最初のホップノードＡ１が受信する。要求は、パスの特性、例えば、バンド幅、クラスその他（フロー情報）についてのもので、宛先端末ＩＤと最後のホップノードＩＤを含む。
【００５１】
図５、ステップ１５６：最初のホップノードはノードフローパステーブルを検索して、ネットワークに接続して要求を承認するインタフェースで利用可能な資源があるかを判定する。資源がない場合、手順はステップ１５６からステップ１８４へ分岐し、ノードは要求元（送信元マシン）へ「拒絶」を返して手順を終了する。しかし、充分なインタフェース資源が利用できる場合には、手順はステップ１６０へ進む。
【００５２】
図５、ステップ１６０：最初のホップノードは要求を承諾するとの想定の元でインタフェース資源を予約し、ノードはフローパステーブルを検索して要求の宛先ＩＰアドレスに対応する宛先マシンへのプリセットパス又はパス群を検出する。プリセットパスが見つかれば、手順はステップ１６２へ進む。
【００５３】
図５、ステップ１６２：ノードはパスが要求の資源と一致する必要のある資源を有しているか判定する。多数のパスが利用できる場合、最初のホップノードは、全部のパスの資源を調べる。要求された資源を備えたパスが見つからない場合、手順はステップ１６４へ進む。要求された資源を備えたパスが見つかった場合、手順はステップ１７０へ進む。
【００５４】
図５、ステップ１６４：最初のホップノードはパス再設定手順（図６を参照してさらに完全には以下で説明する）を実行すべきか否か判定する。結果がイエスなら手順はステップ１８０に進みノーの結果なら手順はステップ１８４へ進み、ここで最初のホップノードは要求元へ「拒絶」を返して手順を終了する。パス再設定の決定は、初期化中又は資源状態に基づいて制限される（例えば、単位時間あたりで何らかの個数の要求だけを行なうように設定される）。
【００５５】
図５、ステップ１８０：パス再設定は、希望のパスの暫定リンクの１つまたはそれ以上にバンド幅を一時的に再割り当てする。
【００５６】
図５、ステップ１８２：ステップ１８０のパス再設定によって不十分な資源が復元される場合、手順はステップ１８４に進み、最初のホップノードは要求元（送信元端末）へ「拒絶」を返して手順を終了する。パス再設定処理が充分な資源を得られる場合、手順は後述のステップ１７０に進む。
【００５７】
図５、ステップ１７０：最初のホップノードが要求を許可して資源とパスを予約した後、最初のホップノードは最後のホップノードへ制御信号を送信し要求を最後のホップノードへ通知する。
【００５８】
図５、ステップ１７２：最後のホップノードは、これに関連する端末ポートテーブルを調べて通信を処理する資源を決定する。
【００５９】
図５、ステップ１７４：資源が充分でない場合、手順はステップ１８６へ進む。資源が充分な場合手順はステップ１７６へ進む。
【００６０】
図５、ステップ１８６：最後のホップノードは、送信元の第１のノードに拒絶を返し手順は前述のステップ１８４へ戻る。
【００６１】
図５、ステップ１７６：最後のホップノードは、必要な設定をセットアップして要求で指定された最初のホップノードからの信号で記載された（フローポートテーブルを作成する）ＱｏＳパスに準じたパケットをマークし転送し、さらに最初のホップノードへＡＣＫ（肯定応答）を返す。
【００６２】
図５、ステップ１７８：最初のホップノードは、要求で指定されたＱｏＳ条件にしたがって、パケットをマークし転送するための設定をセットアップして送信元端末にＡＣＫを返す。手順はこの後ステップ１９０で終了する。
【００６３】
その後、送信元端末は、図２のデータ転送フェーズにしたがって、パケットを送信し、通信を開始する。送信元端末が通信を終了するとき、「解放」メッセージを送出し（図２に図示していない）、これに影響を受けるノードは、適宜テーブルを変更する。
【００６４】
図５に図示した処理のステップ１８０でパス再設定の主要ステップが図６に示してある。要約すると、図６のパス再設定処理は要求に応じてＱｏＳパスを探している最初のホップノードのパスに少なくとも一時的に再割り当てすることが可能な余剰資源を特定するように機能する。すなわち、最初のホップノードによって管理されたプリセットパスのいずれにおいても充分な資源を持ったパスが見つからない場合、１つまたはそれ以上のパスの利用可能な資源を再割り当てすることでパスを見つけ出す試みがパス再設定により行なわれる。
【００６５】
図６、ステップ２０２：最初のホップノードはＴＭＳへ要求を送信し、これにはさらに多くの資源（例えばバンド幅）を必要とするリンクの識別と必要とされるバンド幅の量が含まれる。
【００６６】
図６、ステップ２０４：ＴＭＳはＴＭＳパス状態テーブルを検索して要求で識別されたパスと共通の暫定リンクを共有する別のリンク（他のノードが管理する）を探す。あるパスについて多数の共有リンクが存在する場合、パス再設定処理ではリンクの全てが候補となり、要求に対して不十分な資源を持っているパスは要求によりＴＭＳへ通知される。したがって、パス状態テーブルを用いてＴＭＳは、再設定要求で識別されたパスと同じように、同じ不十分な資源のリンクを共有するパスを特定しようとする。１つ以上のパスが見つかった場合、ＴＭＳはそのパスの利用可能な資源と要求の必要性に基づいてパスを選択する。
【００６７】
図６、ステップ２０６：パス資源有効性の肯定的決定（イエス）では手順がステップ２１０に進み、それ以外ではステップ２０８に進む。
【００６８】
図６、ステップ２０８：見つかったパスをいずれにしても使用すべきかを決定する。しない場合には、手順はステップ２１６に進む。前述したように、ＴＭＳパス状態テーブルの状態情報はノードによって維持されている状態情報を遅延させる。遅延量はノードがＴＭＳの状態更新情報を送信する頻度によって変化する。すなわち、ステップ２０８の決定はＴＭＳで利用可能な状態が不正確であり、特定のパスが必要とされる資源を本当に持っていると言う仮定で行なわれる。したがって、ステップ２１０の要求は、いずれにしても行なわれる。
【００６９】
図６、ステップ２１６：ＴＭＳは最初のホップノードへ「拒絶」メッセージを返して手順を終了する。
【００７０】
図６、ステップ２１０：ＴＭＳはパスの識別と必要とされるかあるいは希望するバンド幅の量で別のパスを管理するノードへ要求を送信する。
【００７１】
図６、ステップ２１２：別の幹線上の資源についての要求を受信したノードは、これに付属するテーブルを検索して、要求された別の幹線の状態を調べる。その別の経路には要求の条件に適合するには不十分な資源しか存在しないとノードが判定した場合、ノードがＴＭＳへ「拒絶」を送信した後で手順をステップ２１４へ進め、それ以外の場合手順はステップ２１８へ進む。
【００７２】
図６、ステップ２１４：ＴＭＳは再試行するかどうかを決定する。再試行する場合、手順はステップ２０４へ戻る。決定は少なくとも部分的にパスを共有するのが二つ又はそれ以上のノードであると言う事実に基づいている。一方のノードが管理するパスに充分な資源がない場合でも他方にはある場合がある。したがってステップ２１４はステップ２０４へ戻って必要とされる資源について別のパスを発見しようと試みる。
【００７３】
これ以外に、ステップ２１４でＴＭＳが使用する決定処理は、充分な資源のある別のパスを特定しようとする試行のプリセット回数又は他の何らかの要因に基づくことができる。
【００７４】
図６、ステップ２１８：別のパスを管理するノードが「承認」をＴＭＳへ送信し付属するテーブルを調節する（別の幹線で「バンド幅」と「利用可能」のカラムの両方で示された資源の量を減少させる。
【００７５】
図６、ステップ２２０：ＴＭＳはパス状態テーブルを変更して資源の再割り当てを反映させる。ＴＭＳは要求が認められた再設定要求を行なったノードに通知して、パス状態テーブルを変更させ再設定を適宜反映させる（すなわち資源の再割り当て）。
【００７６】
図６、ステップ２２２：追加の資源を探している最初のホップノードもテーブルを変更して、問題の幹線について追加の資源を反映する。
【００７７】
ＱｏＳパスの構築を使用する従来のネットワーク構成及びパケットスイッチング用アーキテクチャは代表的には「パス」と言う用語すなわちエンド間接続でネットワーク経由の資源を管理していた。上記の制御ではネットワーク内の資源を「リンク」単位で管理する。送信側ノードがパスを作成する場合、パスを作成できるかどうかはこれが管理しているリンク資源（幹線資源）情報に基づいて決定し追加の情報を他の実体に尋ねる必要はない。
【００７８】
ＮＭＳとＴＭＳは一つの要素に結合することができる。ゲートウェイ要素とこれに対応するエッジノードは単一の最初のホップノードとして統合することができ、これが前述したようなシグナリング、資源管理、承認制御などのゲートウェイ機能を有することになる。
【００７９】
図５と図６に関連して説明したように、ネットワーク経由の図２のパスセットアップフェーズはデータ転送のＱｏＳに特定の要求で開始する。最初のホップノードは要求のＱｏＳ要求に適合するのに資源が充分か否かをチェックする。資源が充分でない場合、追加の資源を他のノード割り当てから借り受けることができ、これは管理システムへの「再設定」要求により図２の従来のネットワーク・プリセットアップ・フェーズで行なった。充分な資源を再割り当てできた場合、送信元ノードは要求を許可でき、資源がない場合要求は拒否される。ネットワーク内で接続単位でネットワーク資源を予約し制御する必要性が排除される。
【００８０】
図１において、簡略化した広域ネットワーク（ＷＡＮ）例えばインターネットが図示してあるが、これは最初のホップノードＡ１と複数の最後のホップノードＡ、Ｂ、Ｃ、Ｄに対してだけである。中間ノード（図示していない）はネットワークの端に図示されたノード間の多数のパスに沿ってネットワーク内に存在する。送信元デバイス（図面の実施形態では送信元端末）は最初のホップノードに接続されるが、実際には例えば複数の送信元マシン、端末、サブネットのエッジノードが最初のホップノードＡ１のポートに接続される。各々の最後のホップノードは複数の宛先マシン（図面の実施形態では宛先端末）へ接続され、宛先マシンは、例えば、サブネットの端末やエッジノードであっても良い。
【００８１】
図１において、各最初のホップノードはコンピュータ・システムを使用するが、これの詳細は周知であり従来のものであることから図示していない。コンピュータ・システムはコンピュータで読み取り可能なコードのストレージを含み、これはフローパステーブル、ノードパステーブル、端末ポートテーブル、フローポートテーブルを本発明による実施形態として含めるように一部分模式的な形で図示してある。
【００８２】
図１は本発明の実施形態であるため図１には図示していないが、発明の背景で参照した従来技術はＩＰルーティングテーブルを備え、ＱｏＳの要求が行なわれる前にネットワークプリセットで作成される。従来技術のＩＰルーティングテーブルは一方のカラムにＩＰアドレス、例えば最初の３列で宛先端末Ｔ１，Ｔ２，Ｔ３のアドレス、また別のカラムでは、最初の３列でプリセットパスの識別例えばＰ１，Ｐ２，Ｐ３を含む。前述したように、このような従来技術のテーブルは巨大であり急激に大きくなるが、これはネットワークの個々のノードへ接続される全部の端末のためである。本発明ではプリセットパスへ接続される端末の識別を必要とせず、最後のホップノードの識別だけしか必要としない。
【００８３】
プリセットパスの従来技術は、ＱｏＳ要求の時点でのパスの従来のセットアップに対する改善である。本発明は、従来なら予想されない方法でプリセットパスの従来技術を改善するものであり、プリセットパスの宛先マシンリンクへの最後のホップの識別をその宛先マシンに関係するＱｏＳパスの特定の要求時にセットアップすることによる。ネットワーク上での計算負荷及びストレージ要求を減少する点で本発明の利点は大きい。以下の説明は実施形態のこの部分の実装として、より詳細に記述するものである。
【００８４】
図１において、各々の宛先デバイスはコンピュータ・システムを使用し（これの詳細は周知であり従来のものであることから図示していない）、コンピュータ・システムはコンピュータで読み取り可能なコードのストレージを含み、これは例えばフローポートテーブルなど実施形態のテーブルを含めるように一部分模式的な形で図示してある。当該テーブルは宛先マシンをこれに対応するネットワークノードＡ、Ｂ、Ｃ、又はＤの接続ポートに関連付ける。
【００８５】
図２に図示してあるように、本実施形態の処理には第１のフェーズがあり、これはネットワーク・プリセットアップ・フェーズである。最初のホップノードＡ１と１つまたは複数の最後のホップノード例えば図１の最後のホップノードＡ、Ｂ、Ｃ、Ｄがこれらの間でネットワークＷＡＮの介在ノードを含めた静的パス上で情報を交換し（介在ノードは、図２に図示してあり図１のネットワークでも含まれる）、プリセットパスを従来の方法で構築し、本発明によるセットアップでは宛先端末を含める必要がない点で異なっている。プリセットパスの構築時には、最初のホップノードは図１に図示したフローパステーブルとノードパステーブルを生成又は作成する。これらのテーブルは本発明でユニークなものだが、プリセットパスを構築するのに使用される方法は、例えば発明の背景で言及した従来技術に説明されているように、従来技術で周知のものであって、前記非特許文献１の中の広域ネットワークにおけるＭＰＬＳメソッドを含め、当該目的で本明細書に開示が含まれる。これによって多数のパスが最初のホップノードと最後のホップノードの間でセットアップされ、別の中間ノードを経由する別のパスが選択される。各プリセットパスは単方向又は双方向である。
【００８６】
図２の処理で次のフェーズは従来の端末ログオンに関係し、ここで宛先及び送信元マシン例えば端末が各々のノードＡ１、Ａ、Ｂ、Ｃ、Ｄに接続する。その結果宛先及び送信元デバイスは各々のノードＩＤを各々取得する。ノードの各々は、端末ポートテーブルを作成、更新、又は何らかの維持を行ない（ここでは最後のホップノードテーブルだけが本発明に関係する）、テーブルは各々のログオンしたデバイスと、結合されているエグレス／イングレス・ポートを関連付け又はリンクする。本発明で注目すべきこととしては、各々の宛先端末ＩＤが宛先端末の接続された最後のホップノードのエグレス・ポートにリンクされることである。このフェーズは、ネットワークへの端末ログオン時又は端末がロケーションを変更し別のノードへ接続したときに完了する。このフェーズで本発明でことなっているのは、本実施形態で、端末がログオンした又はノードの関係を変更したネットワークについて他のノードや制御に通知する必要がないことである。
【００８７】
図２に示した第３のフェーズはアプリケーションレベルの接続セットアップで、これはＱｏＳパスのオンデマンド要求に関連して本発明で完全に独自のものである。例えば、送信元と宛先マシンに常駐するアプリケーションは、ビデオ会議用である。従来の方法では送信元と宛先マシンが従来のＩＰルーティングを使用して、例えばＨ．３２３及びＳＩＰ標準を使用してアプリケーションレベルの接続を確立する。送信元デバイスは宛先デバイスが直接接続されるべきノードを識別するように要求する。これに応答して、宛先デバイスは最後のホップノード経由で送信元端末へ、従来のＩＰルーティングを使用して、すなわちプリセットパスなしで、最後のホップノードのＩＤと宛先端末ＩＤを含むメッセージを送信する。宛先端末ＩＤと最後のホップノードＩＤを送信元端末へ通知するあらゆる手段が使用でき、上記の方法は通信を確立する手段の単なる代表例にすぎない。
【００８８】
図２に図示した次のフェーズは、パスセットアップに関連するもので、これは図５及び図６に関連して詳細に前述した。送信元端末はＱｏＳパスの要求を、オンデマンドＱｏＳパスサービスの一部として、最初のホップノードへ送信する。要求には最後のホップノードのＩＤと希望する宛先デバイスの識別ＩＤ、例えば、各々ＡとＴ１が含まれる。このステップは、図１に図示していない。要求にはフロー特性例えば送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号などのフロー特性を指定するフロー情報も含まれる。
【００８９】
ノードパステーブルと最後のホップノードのＩＤを用いて最初のホップノードは要求を最適に満たし最後のホップノードへ接続するパスを決定する。最初のホップノードは、ノードパステーブル、選択パスから抽出した情報を使用して、プリセットパスへ各々のフローをリンクする図１のフローパステーブルを作成又は更新する。要求は最初のホップノードＡ１によって送信され、これは本実施形態において送信元デバイスがインターネットＷＡＮ上で宛先デバイスへ接続されるノードである。宛先端末のＩＤ、最後のホップノードのＩＤ、要求されたＱｏＳパスのフロー情報は送信元デバイスによって最初のホップノードへ送信される。従来のＩＰルーティング又は選択されたＱｏＳパスをこの通信に使用できる。
【００９０】
最後のホップノードは、これに応答して図１に図示したフローポートテーブルを作成し、このフローポートテーブルは、各フローＦ１、Ｆ２などを関連するエグレス・ポートＥ１、Ｅ２などへ関連付ける又はリンクする。
【００９１】
この後、最後のホップノードは処理において、これまでにその部分が更新を完了したことを表わす最初のホップノードへの肯定応答（ＡＣＫ）を送信する。ＡＣＫ受信時に、最初のホップノードは同様のＡＣＫを送信元デバイスへ送信する。
【００９２】
図２に図示した次のフェーズはデータ転送である。送信元デバイスは最初のホップノードへデータ送信、パケットフローを開始する。受信時に、最初のホップノードはパスセットアップフェーズで選択されたＱｏＳパスへ指定されたフローを割り当てる。これによって最初のホップノードと中間ノードは指定されたプリセットパスを要求されたＱｏＳに使用する最後のホップノードへパケットを転送する。最後のホップノードはフローをエグレス・ポートへリンクし、データ、パケットフローを指定された宛先デバイスへ送信するフローポートテーブルを参照する。
【００９３】
したがって、送信元端末（マシン又はデバイス）から宛先端末（マシン又はデバイス）へＷＡＮ経由でデータの転送を管理するため、最初のホップノードは、端末がログオンされるとデータベースの端末ポートテーブル（すなわち、フローポートテーブル）を更新して、最初のホップノードへ結合されたマシンについての状態情報を提供し、しかる後ログオンした各端末へこれのノードＩＤを渡す。
【００９４】
次に、最初のホップノードは、ＷＡＮ経由でサービス品質（ＱｏＳ）を保証したプリセットパスを確立し、ＷＡＮ経由のプリセットパス、パスのＱｏＳが依存するネットワーク資源、各ＱｏＳパスのＷＡＮ最後のホップノードの識別子の間の関連性を提供するためにデータベースのノードパステーブルを更新する。なお、このときに、パスの各宛先端末の識別を必要としない。
【００９５】
そして、最初のホップノードは、指定された送信元端末から指定された宛先端末へのオンデマンドＱｏＳ保証パスのアプリケーションレベル要求を受信して、要求において指定された宛先端末に対応付けられた最後のホップノードの識別についての問い合わせと応答をＷＡＮ上で送信することにより、従来のＩＰルーティングを使用するアプリケーションレベル接続を確立して、送信元端末と宛先端末で動作しているアプリケーションを支援する。（この支援は、要求で指定された宛先端末に対応付けられた最後のホップノードの識別に関して問い合わせる宛先端末へアプリケーションレベルの信号の送信する。また、応答が送信されるべき送信元端末から発信されたときに信号を識別する）。
【００９６】
次に、最初のホップノードは、要求で指定された宛先端末へ結合された最後のホップノードを識別しまた最後のホップノードと宛先端末のうちの一方から発信されたものとして信号を識別する（後者の場合が実施形態である）。
【００９７】
次に、最初のホップノードは、宛先マシンへ結合された最後のホップノードの識別を送信元端末から受信する。
【００９８】
次に、最初のホップノードは、データベースのフローパステーブルを作成し最後のホップノードへ情報を送信してこれのデータベースのフローポートテーブルを作成し、完了時に送信元端末へ完了を肯定応答する。
【００９９】
次に、最初のホップノードは、フローパステーブルの作成の一部として、ノードパスデータベースが検索されＱｏＳパスが宛先マシンに対応付けられた最後のホップノードの要求及び識別子の両方に基づいて抽出される。
【０１００】
その後、次に、最初のホップノードは、要求にしたがって宛先端末へ送信元端末のためのパケットを転送する。
【０１０１】
「最後のホップノード」Ａ、Ｂ、Ｃ、Ｄは、全て通信で最初のホップノードとして機能し、「最初のホップノード」Ａ１は最後のホップノードとして機能する。すなわち、ＱｏＳのオンデマンド要求をどの端末が行なうかに依存しており、それらのノードは、逆の役割のプログラムとテーブルを有することを意味する。
【０１０２】
本発明の更なる実施形態として、最初のホップノード端末が、上記の例の宛先端末と送信元端末によって実行されるアプリケーションレベルの作業の幾つかを肩代りすることもできる。本発明は、例えば、ネットワークがＩＰルータを含むネットワーク・サービスで使用可能である。本発明は、他のネットワーク、例えば、プリセットパスを有することがあるＡＴＭ（非同期転送モード）ネットワークで使用可能である。
【０１０３】
図７は、ネットワーク・プロバイダ代表的には電気通信事業者、サービス・プロバイダ又はコンテンツ・プロバイダ、およびユーザ例えば消費者（個人）又はビジネス事業者の三者間での通信を使用する本発明の実施形態のパス要求と支払いの関係の実施形態の模式図である。
【０１０４】
本実施形態で、３者間の支払いは従来の月極め料金（０）を含み、これは図７に示してあるように、サービス・プロバイダによって又ユーザによってネットワーク・プロバイダへ支払われる。
【０１０５】
図７の左手下隅に示してあるように、ユーザの端末はサービス・プロバイダによって提供されるサービス又はコンテンツの表示を有している。ビデオの例に含まれているのは、ゴールド、シルバー、ブロンズ、無料品質の配信選択、ＱｏＳパス、タイトル１とタイトル２のコンテンツ題名の二つの例で各々低いコストと低い品質である。普通の制御ボタン例えば右手上隅に示してある二つが設けてあり、これと一緒にサービス・プロバイダのホームページ・アドレスが特定の例として示してある。この表示はサービス・プロバイダからユーザへ、ユーザがサービス・プロバイダに最初に接触したときに送信される。このウェブページはアップデートによるオンタイム又はコンタクト毎に提供される（後者は実施形態の一部をなす。ユーザは希望するコンテンツと、コンテンツ供給で希望するサービス品質を、例えばポイント・アンド・クリックの方法又は何らかの他の選択方法により選択する。例では、タイトル２のビデオを受信するのに追加コスト１５ドルでゴールド・サービスを選択しており、この選択がＷＡＮ上でサービス・プロバイダへサービス要求（１）として送信される。
【０１０６】
図７の通信（１）、ユーザからサービス・プロバイダへのサービス要求に応答して、サービス・プロバイダはネットワーク・プロバイダへパス要求（２）を送信する。ネットワーク・プロバイダのＡＰＩ（アプリケーション・プログラム・インタフェース，　Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）は、図１から図６に関連して説明したようにサービス・プロバイダとユーザの間でエンド間のＱｏＳパス（３）を設定し、設定が完了したら、サービス・プロバイダへ肯定応答（４）を送信する。このように設定されたＱｏＳパス（３）はデータ転送の品質が保証された通信パスを提供し、これには最小バンド幅と最大遅延を含む。
【０１０７】
次に、ユーザは受け取るサービス（例えばビデオ・コンテンツ）について、サービス・プロバイダに支払い、トランザクション（６）を行なう。ビデオ・コンテンツの供給はＱｏＳパス（３）の上で行なわれ、ユーザは高品質表示である程度の満足が得られる。サービス・プロバイダはパスの使用についての支払い、トランザクション（７）を行ない、この支払いはトランザクション（６）のユーザの支払いの一部から得られる。
【０１０８】
サービス・プロバイダからのビデオ供給の例で実施形態を説明するが、本発明は多種多様な用途やサービス例えばショッピングやオーディオにも応用することができるものである。サービス・プロバイダはユーザの端末へビデオ・コンテンツの配信の何らかの品質保証を付けてビデオデータを供給し、このサービスに対して金額を課金する。
【０１０９】
図１０は本発明によるデータ供給のフローチャートで、とくにビデオサービスを供給する実施形態に関するものである。
【０１１０】
図１０、ステップ２００：ユーザはサービス・プロバイダとのコンタクトを確立する、例えば、ＩＰ又はＵＲＬアドレスを使用してサービス・プロバイダのホームページにアクセスするなどにより、またサービス・プロバイダはウェブページ（ウェブ・ポータル）をユーザの端末ディスプレイへダウンロードさせる。
【０１１１】
図１０、ステップ２０５：サービス・プロバイダはユーザへウェブページを返し、この一例が図７の左手下隅に図示してあり、ここではコンテンツの選択とＱｏＳレベルの選択が表示される。本発明の簡略化したバージョンでは、例えば、ユーザが一つのサービス・レベル（ＱｏＳレベル）についてのみサービス・プロバイダと契約した、又は本発明のもっとも簡略なバージョンとしてユーザへの図７及び図８の表示がユーザに対して何ら品質選択を持っていない、などとすることができる。このようにすれば、ユーザは、一つのコンテンツに対して一つのサービスだけが見えることになり、品質の表示はないか、又は他の品質グレードに代替するものがなく、ネットワーク上の問題全部がユーザには透過的になるであろう。
【０１１２】
図１０、ステップ２１０：サービス・プロバイダのウェブページを閲覧する間に、ユーザは見たいと思うビデオデータ（図７の「タイトル１」）を選択して希望するビデオ供給の種類（図７の「ゴールド（１５ドル）」）を選択する。図７は、コンテンツ選択ウェブページのステップ２０５によるユーザ端末表示例を示す。図７の例では、その時点で利用可能なＱｏＳセッティングの全部が選択できるように表示されており、また、図８では利用できない選択肢は×印が付けられている。選択は何らかの方法によって、例えばポイント・アンド・クリックの方法によるカーソルで、又は音声コマンドによって、ライトペン、タッチパッド、その他によって行なうことができる。特定の例として、ユーザが表示されたボタンをクリックすると、図７の「サービス要求」（１）がサービス・プロバイダへ行く。図１０、ステップ２０５に関連して上記で開示した簡略化されたバージョンでは、ユーザからサービス・プロバイダへの通信は文字どおりのＱｏＳの選択を含まないが、ＱｏＳは通信の一部としてユーザ識別により本質的に識別されることになる。
【０１１３】
図１０、ステップ２１５：ビデオ・コンテンツとサービス要求で要求された品質に応答して、サービス・プロバイダは適当なパス属性を付けて、例えばバンド幅、遅延、持続時間、ソースアドレス、宛先アドレスなど、ネットワーク・プロバイダへの「パス要求」を送信する。実施形態の一例として、図７に図示してあるように、要求（２）に関して、ネットワーク・プロバイダは、サービス・プロバイダからの「パス要求」（パスセットアップ要求とも呼ばれることがある）を受信するＡＰＩ（アプリケーション・プログラム・インタフェース）を使用する。二つの例として、ＡＰＩの引き数には、各種のＱｏＳ（サービス品質）パラメータ、ソースアドレス＆宛先アドレス、持続時間、また指定されるパスの所定のクラス、宛先アドレス、及び持続時間が挙げられる。以下はＡＰＩ例１はこの操作を実行するために使用される代表的なＡＰＩを示す。
【０１１４】
【数１】

【数２】

図１０、ステップ２２０：ネットワーク・プロバイダは図７に図示してあるように又サービス・プロバイダによって要求された通りパス（３）をセットアップしようと試みる。一例として、ＡＰＩはパスの値段についてのパラメータを持っている。サービス・プロバイダは価格を提供し、ネットワーク・プロバイダはネットワーク資源の可用性を調べまた資源を要求された価格で割り当てできるか否かを調べる。別の方法としては、ネットワーク・プロバイダにパスについての価格を提供してもらってからサービス・プロバイダに見積り価格でのパスセットアップを「実行」するように依頼する。
【０１１５】
ところで、ベストエフォート型通信でＩＰネットワーク内に通信品質の保証されたパスを作成して、通信する技術が知られている。この技術では、拠点間に、例えば、ＶＰＮ（仮想プライベート・ネットワーク，　Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）を構築する。しかしながら、このようなビジネス／企業ユーザに使用が制限されている通信とは異なり、本発明の方法では、消費者を含めた広い範囲のユーザによって使用できるものである。ネットワーク資源利用効率を改善するために、本発明の方法では、オンデマンド方式でパスを割り当て、また、スケーラブルであるから大規模ＩＰネットワークでも使用することができる。
【０１１６】
図１０、ステップ２２５：パスセットアップが成功したら、ステップ２３０を実行する。それ以外の場合には手順はステップ２３５へ進む。
【０１１７】
図１０、ステップ２３０：パスセットアップが成功したら、ネットワーク・プロバイダはサービス・プロバイダへＡＣＫを返す。
【０１１８】
図１０、ステップ２３５：ネットワーク・プロバイダはサービス・プロバイダへＮＡＣＫを返す。
【０１１９】
図１０、ステップ２４０：パスセットアップが完了しなかった場合、サービス・プロバイダはユーザへのサービスを最初に拒否する。サービス・プロバイダは次にユーザディスプレイ用のデータを提供するプリセットの代替案のひとつへ進むか又は同様のもののユーザーデモグラフィーに基づいてどの代替案を使用するかの決定を行なう。
【０１２０】
図１０、ステップ２４５：サービス・プロバイダのウェブ・ポータルはユーザがすでに選択したＱｏＳか、それより高いＱｏＳを選択しないようにして図８に図示してあるようにユーザが選択することのできる代替案を表示する。
【０１２１】
図１０、ステップ２５０：ステップ２１０の方法と同様の選択方法を用いることにより、ユーザは別の「パス要求」を、例えば同一のビデオについてただしもっと低い品質で供給されるように、送信する。この高品質サービスの防止は、元々のユーザと同一のアクセスノード又はゲートウェイを共有する他のユーザに対しても行なうことができる。ステップ２１５，２２０，２２５，２３５，２４０，２４５を回る処理ループは、パスセットアップに成功するまで、又はタイムアウト（図示していない）が発生するまで行なわれる。
【０１２２】
ステップ２３５でＮＡＣＫを返す代わりとして、ネットワーク・プロバイダはその時点で提供することのできるパスに関する情報を返すことができ、このパスは低品質なのが一般的である。次に、ステップ２４０で、サービス・プロバイダはユーザに対して、低い品質のサービスしか提供できないことを通知し、低品質かつ低価格のサービスを希望するか否かをユーザに問い合わせる。以下のＡＰＩ例２はこの動作を実行するＡＰＩを実装する代表的な擬似コードを示したものである：
【０１２３】
【数３】

図１０、ステップ２５５：ユーザはビデオについて、すなわちコンテンツ（サービス）についてサービス・プロバイダに支払いを行なう（図７の矢印（６）：ユーザからサービス・プロバイダ）。すなわち、ユーザは提供されたサービス／商品に対してサービス・プロバイダに支払いを行なう。このステップは多数の方法で実行できるが、好適な実装はビデオストリームの配信（図７の矢印（５））が開始する直前に支払いを行なうことであるが、他の可能性も想定される、例えばアカウントを一時的に課金して、最終的な課金はステップ２７５の後又はその一部としてまで遅延する。支払いはクレジットカード又はデビットカードによる又はアカウント課金による。ユーザはサービス（ビデオ・コンテンツ）について支払っていて、ネットワーク使用に対してではないと信じ込んでいる。言い換えれば、パスについての支払いはユーザから隠蔽されている。
【０１２４】
図１０、ステップ２６０：サービス・プロバイダはユーザへ、ユーザによって選択されたＱｏＳパスを使用することにより、ビデオストリームを配信する。
【０１２５】
図１０、ステップ２６５：ビデオの配信は、パス障害イベント（ＰＦ，　Ｐａｔｈ　Ｆａｉｌｕｒｅ　ｅｖｅｎｔ）である配信の失敗の発生について、又はビデオ終了イベント（ＥｏＶ，　Ｅｎｄ　ｏｆ　Ｖｉｄｅｏ　ｅｖｅｎｔ）の発生について、ユーザの端末にあるクライアント・ソフトウェアによってモニタされる。少なくとも配信障害イベントは、サービス・プロバイダに報告される。
【０１２６】
図１０、ステップ２７０：サービス・プロバイダとネットワーク・プロバイダは、配信障害の発生源を特定しサービス・プロバイダはどこの問題が障害イベントを発生させたか、例えばサービス・プロバイダのサーバ計算機が過負荷になっている、又はネットワーク・プロバイダのパス資源が障害を起しているなどを特定する。
【０１２７】
図１０、ステップ２７５：「返金」メカニズムはシステムの一部であるから、ビデオ伝送の障害が発生した場合、ユーザは支払いを取り返し、クレジットを受け取るか又は課金を取り消してもらい、障害がネットワーク・プロバイダにより発生したと判明した場合サービス・プロバイダは支払いを取り返し、クレジットを受け取るか又は課金を取り消してもらう。
【０１２８】
図１０、ステップ２８０：サービス・プロバイダはパスに対してネットワーク・プロバイダに支払いを行なう。このステップは多くの方法で実行できるが好適な実装は（図７の矢印（７））で、時間間隔（例えば１月）について使用情報を蓄積し、支払いを定期的に行なうようにする。ネットワーク・プロバイダが実際には多数のネットワーク・プロバイダで構成されている例、例えば図９では、ネットワーク・プロバイダへの支払いは使用したネットワーク・プロバイダの間で配分される。この支払いはサービス・プロバイダに最も近いネットワーク・プロバイダによって行なわれサービス・プロバイダからの支払いを受け取り他のネットワーク・プロバイダへこれを再配分する（図９のフロー＃１）か、又は一対一で支払いを中継するネットワーク・プロバイダによる（図９のフロー＃２）か、又はサービス・プロバイダにより個別にネットワーク・プロバイダの各々に支払う（図９のフロー＃３）。
【０１２９】
本発明は多数の実施形態及び実装との関連で説明したが、これらにより本発明が限定されるものではなく添付の請求項の範囲に納まる各種の明白な変更及び等価な構成を包含する。
【０１３０】
本発明の態様、特徴、利点は、本発明を実現する上で発明者が意図した最良の態様である特定の実施形態及び実装を、変更及び変化を含めて簡略に図示することで、以上の詳細な説明から容易に明らかになった。本発明はその他の及び別の実施形態も可能であり幾つかの詳細は本明細書の教示にしたがえば各種の明白な態様で、全てが本発明の趣旨と範囲から逸脱することなく変更が可能である。したがって図面及び説明は本質的に図示を目的としたものであって制限ではないと考えるべきである。
【０１３１】
【発明の効果】
本発明によれば、最初のホップノードは宛先端末へプリセットパスをリンクする情報を格納また管理する必要がない。実施形態において最初のホップノードは、最初のホップノードへプリセットパスをリンクする情報を管理し、要求が行なわれ予備的なプリセットパスが選択されるまで宛先端末へのリンクを要求しない。端末数は最後のホップノードの個数の逓倍数であるから、これは要求されるテーブルサイズを大幅に減少させ、その上、最初のホップノードでのストレージ要求とデータベース管理処理負荷を大幅に減少させる。ここで、最初のホップノードは、理論的に例えばネットワークのエッジノードの全部とＷＡＮのゲートウェイ・ノードの全部である。
【０１３２】
また、宛先端末がロケーションを変更して別の最初のホップノードへ接続する場合には、最初のホップノードのパステーブルは再設定される必要がない。これは端末のロケーションが頻繁に変化する場合、また、ポータブル又は移動体端末の使用が増加して、最後のホップノードは、将来的にさらに頻繁に変化する場合に、最初のホップノードの計算負荷を大幅に減少させる。
【０１３３】
また、本発明によれば、回線事業者のＩＰネットワーク・ビジネスの新しい形態に適用可能で新しい収入源を提供することができる。
【図面の簡単な説明】
【図１】ネットワークとくにＷＡＮと、当該ネットワークに接続される端末の略図で、本発明の実施形態によりオンデマンドで割り当てられるＱｏＳパスのテーブルの例は最初のホップノードと最後のホップノードに格納される。
【図２】図１のＷＡＮのノードすなわち図１の送信元端末と図１の宛先端末で送受信される信号のチャートで、上から下へ向かって本発明の実施形態を実装する際の信号の代表的順序を示す。
【図３】最初のホップノードテーブルの例で、エッジノードで記憶媒体に存在し図１の最初のホップノードとして動作するエッジノードで使用され、本発明の実施形態を実装するための代表的データを示す。
【図４】端末ポートテーブルの例で、エッジノードで記憶媒体に存在し図１の最後のホップノードとして動作するエッジノードで使用され、本発明の実施形態を実装するための代表的データを示す。
【図５】図２に開示した本発明のネットワーク・プリセットアップ・フェーズで動作し、ネットワーク内の最初のホップノード又は後続のホップノードで行なわれてネットワーク内でＱｏＳパスをセットアップするためのステップを示すフロー図である。
【図６】ＱｏＳパス要求に対応する容量を備えたネットワーク経由のパスを取得しようとする際のパス再設定に関して、図５のステップ１８０をさらに詳細に示すフロー図である。
【図７】ネットワーク・プロバイダとサービス・プロバイダとユーザの間での通信を使用する本発明の実施形態のパス要求と支払いの関係の実施形態の模式図で、図１０のステップ２０５のウェブページを示す。
【図８】図７と同様の模式図だが、図１０のステップ２４５のウェブページを示す。
【図９】図１０のステップ２７５による３種類の支払方法を示す模式図である。
【図１０】本発明によるデータ供給のフローチャートで、とくにビデオサービスを供給する実施形態に関連する。

Claims

ユーザと、サービス・プロバイダと、ネットワーク・プロバイダの間でデータ通信ネットワークにより通信しつつ実行される方法であって、
前記方法は前記ネットワーク・プロバイダによりマシン上で実行され、
異なるサービス・プロバイダの各々と前記ネットワークを通る複数の異なるパスＱｏＳレベルとの間のリンクを備えるデータベースを、前記異なるＱｏＳレベルの使用に関連した料金スケジュールに基づいてコンテンツ配信のために管理するステップと、
前記サービス・プロバイダからＱｏＳパスについての要求を受信するステップと、
前記受信したＱｏＳパスについての要求に応答して、前記サービス・プロバイダと前記ユーザの間に前記要求されたＱｏＳパスをセットアップしようと試みるステップと、
前記セットアップが成功した場合、前記サービス・プロバイダから前記ユーザへ前記要求されたＱｏＳパスでコンテンツ・ストリームを転送するステップと、
前記セットアップが成功した場合、前記ＱｏＳパスの使用について前記サービス・プロバイダから支払いを受け取るステップと
を含むことを特徴とする方法。
前記管理するステップと受信するステップとは、ＱｏＳパス使用の持続とＱｏＳパス使用のレベルに前記料金スケジュールを関連付けることを含むことを特徴とする請求項１に記載の方法。
さらに、前記セットアップを試みるステップの一部として、前記サービス・プロバイダにより使用するために割り当てられるのに前記要求されたＱｏＳパスが利用可能か否かに関してネットワーク資源の可用性を調べ、前記ＱｏＳパスをセットアップしようと試み、前記パスセットアップが成功したか否かを前記要求元に通知するステップ
を含むことを特徴とする請求項１に記載の方法。
さらに、前記ＱｏＳパス上でのコンテンツ配信の障害についての責任に関して前記サービス・プロバイダへ情報を提供するステップと、
前記ネットワーク・プロバイダが配信障害イベントについての責任を負っている場合には、前記サービス・プロバイダへの補償を提供するステップと、
を含むことを特徴とする請求項３に記載の方法。
さらに、前記セットアップを試みるステップの一部として、前記サービス・プロバイダにより使用するために割り当てられるのに前記要求されたＱｏＳパスが利用可能か否かに関してネットワーク資源の可用性を調べ、現在利用可能なパスについて前記サービス・プロバイダへ情報を提供し、前記ＱｏＳパスの一つに対して前記サービス・プロバイダに実行するように要求するステップ
を含むことを特徴とする請求項１に記載の方法。
さらに、前記ＱｏＳパス上でのコンテンツ供給の障害についての責任に関して前記サービス・プロバイダへ情報を提供するステップと、
前記ネットワーク・プロバイダが配信障害イベントについての責任を負っている場合には、前記サービス・プロバイダへの補償を提供するステップと
を含むことを特徴とする請求項５に記載の方法。
さらに、前記ＱｏＳパス上のコンテンツ供給の障害についての責任に関して前記サービス・プロバイダへ情報を提供するステップ
を含むことを特徴とする請求項１に記載の方法。
さらに、前記ネットワーク・プロバイダが配信障害イベントについての責任を負っている場合には、前記サービス・プロバイダへの補償を提供するステップ
をさらに含むことを特徴とする請求項７に記載の方法。
さらに、前記管理するステップはＱｏＳパス使用の持続とＱｏＳパス使用のレベルに前記料金スケジュールを関連付けること
を含むことを特徴とする請求項８に記載の方法。
ユーザと、サービス・プロバイダと、ネットワーク・プロバイダの間でデータ通信ネットワークにより通信しつつ実行される方法であって、
前記方法は前記サービス・プロバイダによりマシン上で実行され、
前記ネットワーク・プロバイダと契約して、異なるＱｏＳレベルの使用に関連した料金スケジュールでコンテンツ配信の異なる複数のＱｏＳレベルを提供するステップと、
前記ユーザからの要求に関連したコンテンツ選択を受信するステップと、
前記コンテンツ選択関連の要求と前記ＱｏＳレベルの一つとを相関させるステップと、
前記受信したコンテンツ選択に関連した要求に応答して、前記ＱｏＳレベルと相関した保証を伴って、前記ネットワーク・プロバイダに対して、エンドツウエンドの原則により前記サービス・プロバイダと前記ユーザの間のＱｏＳパスをセットアップするように要求するステップと、
前記セットアップが成功したときに、前記セットアップパスの識別子付きで前記ユーザに前記コンテンツを送信するステップと
を含むことを特徴とする方法。
前記契約するステップは、ＱｏＳパス使用持続時間とＱｏＳパス使用レベルに前記料金スケジュールの料金を関連付けることを含む
ことを特徴とする請求項１０に記載の方法。
さらに、前記要求するステップは、パス品質属性、ソースアドレス、宛先アドレス、持続時間とともに前記ネットワーク・プロバイダへパスセットアップ要求を送信するステップ
を含むことを特徴とする請求項１０に記載の方法。
さらに、前記受信するステップの前にユーザ接触に応答して、ＱｏＳの複数のレベルの間からＱｏＳのレベルの選択について前記ユーザへの指示をダウンロードするステップ
を含むことを特徴とする請求項１０に記載の方法。
さらに、パスセットアップ失敗に応答して、もっと低い品質又は直前の品質の再試行の一方で前記同じコンテンツの選択要求を前記ユーザに促すステップ
を含むことを特徴とする請求項１０に記載の方法。
さらに、前記ユーザのクライアント・ソフトウェアから配信イベントの障害の発生の通知を受信するステップと、
前記通知を受信するステップに応答して配信イベントの前記障害についての責任を特定して前記特定した責任にしたがって支払い責任を調節するステップと
を含むことを特徴とする請求項１０に記載の方法。
さらに、パスセットアップ失敗に応答して、別のＱｏＳを前記ユーザに提供し又前記すでに選択したＱｏＳともっと高いＱｏＳの選択を前記ユーザにさせないようにするステップ
を含むことを特徴とする請求項１０に記載の方法。
さらに、前記要求するステップの後でこれに関連して前記ネットワーク・プロバイダから現在利用可能なパスの情報を受信するステップ
を含むことを特徴とする請求項１０に記載の方法。
ユーザと、サービス・プロバイダと、ネットワーク・プロバイダの間でデータ通信ネットワークにより通信しつつ、マシン上で実行される方法であって、
前記ネットワーク経由の複数の異なるＱｏＳレベルのパスに関連して前記プロバイダの少なくとも一つによる使用とデータをリンクするデータベースを管理するステップと、
前記パスのＱｏＳレベルの一つに関連した要求を受信するステップと、
前記要求に応答して前記要求がパスセットアップに成功する結果となる場合には、パス使用に基づいて前記ネットワーク・プロバイダへの支払いを管理するための手段と
を含むことを特徴とする方法。
さらに、ＱｏＳパス使用持続時間に前記支払いを関連付けるための手段
を含むことを特徴とする請求項１８に記載の方法。
さらに、ＱｏＳパス使用レベルに前記支払いを関連付けるための手段
をさらに含むことを特徴とする請求項１８に記載の方法。
さらに、ＱｏＳパス使用持続時間とＱｏＳパス使用レベルに前記支払いを関連付けるための手段
を含むことを特徴とする請求項１８に記載の方法。
さらに、パスセットアップ失敗に応答して前記支払いを変化させるための手段を含むことを特徴とする請求項２１に記載の方法。
さらに、配信イベントの障害の発生に応答して配信イベントの前記障害についての責任を特定し、また前記特定した責任にしたがって支払いを調節するステップ
を含むことを特徴とする請求項２１に記載の方法。
さらに、配信イベントの障害の発生に応答して別のＱｏＳを前記ユーザに提供し、又前記すでに選択したＱｏＳともっと高いＱｏＳの選択を前記ユーザにさせないようにする手段
を含むことを特徴とする請求項１８に記載の方法。
パスセットアップ失敗に応答して前記支払いを変化させるための手段
を含むことを特徴とする請求項１８に記載の方法。
配信イベントの障害の発生に応答して配信イベントの前記障害についての責任を特定し、また前記特定した責任にしたがって支払い責任を調節する手段
を含むことを特徴とする請求項１８に記載の方法。
請求項１８に記載の方法を物理的に実装するために実行可能なコンピュータで読み取り可能なコードを有するコンピュータで読み取り可能なストレージと、
前記ストレージに動作的に接続されて前記コードを取出し前記コードを実行する能力を備えるコンピュータと、
前記ネットワークへの接続用の入力及び出力ポートと
を含むことを特徴とするネットワーク・ノード。
請求項２１に記載の方法を物理的に実装するために実行可能なコンピュータで読み取り可能なコードを有するコンピュータで読み取り可能なストレージと、
前記ストレージに動作的に接続されて前記コードを取出し前記コードを実行する能力を備えるコンピュータと、
前記ネットワークへの接続用の入力及び出力ポートと
を含むことを特徴とするネットワーク・ノード。
請求項２３に記載の方法を物理的に実装するために実行可能なコンピュータで読み取り可能なコードを有するコンピュータで読み取り可能なストレージと、
前記ストレージに動作的に接続されて前記コードを取出し前記コードを実行する能力を備えるコンピュータと、
前記ネットワークへの接続用の入力及び出力ポートと
を含むことを特徴とするネットワーク・ノード。
請求項２４に記載の方法を物理的に実装するために実行可能なコンピュータで読み取り可能なコードを有するコンピュータで読み取り可能なストレージと、
前記ストレージに動作的に接続されて前記コードを取出し前記コードを実行する能力を備えるコンピュータと、
前記ネットワークへの接続用の入力及び出力ポートと
を含むことを特徴とするネットワーク・ノード。