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