JP4213972B2 - ネットワークのパス構成のための方法および装置 - Google Patents
ネットワークのパス構成のための方法および装置 Download PDFInfo
- Publication number
- JP4213972B2 JP4213972B2 JP2003069735A JP2003069735A JP4213972B2 JP 4213972 B2 JP4213972 B2 JP 4213972B2 JP 2003069735 A JP2003069735 A JP 2003069735A JP 2003069735 A JP2003069735 A JP 2003069735A JP 4213972 B2 JP4213972 B2 JP 4213972B2
- Authority
- JP
- Japan
- Prior art keywords
- path
- hop node
- node
- qos
- destination
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/822—Collecting or measuring resource availability data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/803—Application aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
Description
【０００１】
【発明の属する技術分野】
本発明はサービス品質の要求に適合するネットワーク内のプリセットパスに関する。
【０００２】
【従来の技術】
広域ネットワーク（ＷＡＮ, Wide Area Network）、とくにインターネットは通信量の増加によるストレージと計算量の過負荷に悩まされており、この問題は憂慮すべき事態になってきている。
【０００３】
資源予約プロトコル（ＲＳＶＰ, Resource ReSerVation Protocol）は、ネットワーク資源の予約メッセージと確認メッセージが接続される度にデータの通るノード全部で必要とされ、接続が確立される際に長い遅延を作り出すことが多い。ＲＳＶＰおよびマルチプロトコル・ラベルスイッチング（ＭＰＬＳ, MultiProtocol Label Switching）ネットワークでは、ネットワークの規模が大きくなるにつれて、接続数とあるノードが処理しなければならない予約のトランザクション数が増大し、これに相応する大きな計算量が各ノードに求められ、またネットワークは必要とする接続やトランザクションを処理できなくなることもある。
【０００４】
最近、インターネット・プロトコル（ＩＰ, Internet Protocol）基盤上で動作するアプリケーションが進化し、データの高バンド幅かつリアルタイム転送が必要とされるようになってきた。これらの要求が強いアプリケーションを、例えば、Ｅ−メールのダウンロード、Ｗｅｂページトランザクションのような従来のアプリケーションと区別ものとして、例えば、サービス品質（ＱｏＳ, Quality of Service ）属性例えばバンド幅、遅延、及びジッタなどを保証する仮想パス（以下単に「パス」と言う）が使用されうる。データ送信元は、データフローを割り当てるパスを指定してからそのパスにデータを送出して保証されたＱｏＳを得るようにする。
【０００５】
例えば、特許文献１などに記載されているように、従来技術のひとつの方法ではプリセットパスを設定する。プリセットパスは、広域ネットワーク（ＷＡＮ）、例えばインターネットの最初のホップノードと最後のホップノードの間に設定され、最初のホップノードへ直接接続する端末からはじまり最後のホップノードへ直接又は間接に接続する端末で終わるあらゆるパスで使用できる。最初のホップノードと最後のホップノードへ直接接続する多数の端末が、それら自身のパスを設定した場合にはプリセットパスを共有できる。
【０００６】
本明細書で用いているように、ネットワークのエッジ・ノード、サブネットワークのエッジ・ノード、ワークグループのエッジ・ノード、およびゲートウェイは広域ネットワークの最初のホップノードと最後のホップノードの例であり、これらは最初のホップノードと最後のホップノードの間のパスに沿って存在するトランジット（中間）ノードとは対照的である。
【０００７】
ルーティング情報は、非特許文献１によれば、ＷＡＮの最初のホップノードと最後のホップノードの間で交換される。最初のホップノードは宛先端末のＩＰアドレスをプリセットパスへリンクするパステーブルを必要とする。発信元の端末は宛先ＩＰアドレスと一緒に最初のホップノードへパケットを送出する。最初のホップノードは宛先ＩＰアドレスを使用してパステーブルからパスを抽出し、その後選択されたプリセットパスに沿ってパケットを転送する。
【０００８】
特許文献２では、多数のサービス品質（ＱｏＳ）パラメータを指定する接続要求に応答して宛先への第一のパスを選択している。第一のパスに沿った第一の信号の伝送が失敗した場合には、第二のパスがデータベースにしたがって選択される。プリセットパスはＱｏＳについて最新に保持される。
【０００９】
特許文献３では、端末のログオン時に利用可能なプリセットパスを説明している。発信元ネットワーク要素はパスの開始点であり、次のネットワーク要素に向かってパストレース値を送信し、このパストレース値はパストレース値を送信する要素の識別値を有する。受信側要素はパストレース値の識別子を自分自身の識別子に変更してから、変更したパストレース値を次の要素へ再送信すると言う具合にエンドポイントまで続く。それぞれの要素は相互接続情報を保持し相互接続情報を用いてパスを構築するネットワーク管理システムへ送信する。
【００１０】
特許文献４は、同じＩＰネットワーク・アドレスを割り当てられた複数のルータ・インタフェースがＩＰワークグループを作成しホストの再設定を必要とすることなくワークグループ内のどこにでもホストを再配置できるようにしている。単一のアドレスを幾つかの物理ネットワークで使用する。
【００１１】
特許文献５は、ネットワーク内の送信元ノードと宛先ノードの間で最小限しか重複しない複数のパスを決定するためのシステムを開示している。第一のパスと第二のパスが重複している場合、システムは、少なくとも一方のパスを変更してパスの重複を最小限にとどめるようにし、一つのパスでの障害が別のパスの障害を誘発する可能性を減少させるようにしている。
【００１２】
上記従来技術から理解されるように、ＱｏＳパスのセットアップの改良の必要性がある。
【００１３】
【特許文献１】
米国特許６，１０８，３０４号
【非特許文献１】
IETF, Multi-protocol label Switching Architecture, RFC3031, January 2001
【特許文献２】
米国特許５，９３３，４２５号
【特許文献３】
米国特許６，０９４，６８２号
【特許文献４】
米国特許５，７５１，９７１号
【特許文献５】
米国特許６，２５６，２９５Ｂ１号
【００１４】
【発明が解決しようとする課題】
ここに記載したニーズ、また、その他のニーズは、本発明により対処される。
【００１５】
従来技術の分析の結果、本発明の発明者は、ＱｏＳパスの要求を処理する際にネットワーク上での計算負荷とストレージ要求を減少する必要性があることを発見した。
【００１６】
したがって、本発明において問題とその原因として従来技術のシステムの分析を行なったことにより、ＱｏＳパスの要求をより効率的に処理する必要性があることが見出された。
【００１７】
本発明以前においては、ＱｏＳパスの何らかの要求が受信されるのに先立ってパスのセットアップ手順の全部を完了することがＱｏＳを実現する究極的な方法であると考えられてきた。
【００１８】
本発明にあたり、プリセットパスのアプローチでは最初のホップノードがネットワーク内の全ての端末についてのプリセットパスを含むパステーブルを格納し管理する必要があり、これには非常に大きなテーブルの管理が必要になると言う問題があることが分った。テーブルの管理はＱｏＳパスの要求が増大するにしたがって非常に大規模になることが予想される。本発明における分析によると、宛先端末の最後のホップノードが変化した場合、その宛先端末に対するプリセットパスのテーブルを管理している全ての最初のホップノードが当該プリセットパスをこれに合わせて変更する必要があり、これがノードにおける負荷増大の原因の一つであることが示される。宛先端末の最後のホップノードが変化する度に全ての最初のホップノードのパステーブルを更新しなければならないので、端末の位置が頻繁に変化すると問題はさらに悪化する。本発明において問題を分析し、主な原因を決定してこの原因を排除し、さらに宛先端末に関係するＱｏＳの要求が存在した後でのみプリセットパスに対して最後のホップノードと宛先端末を関連付けることにより、このような確認された問題を解決するものである。
【００１９】
サブネットＩＰアドレスを用いて端末を集約することができるが、問題はこれでは解決しない。端末サブネットが小さなグループに分割されサブネットの個数が多くなると、テーブルは巨大になる。
【００２０】
本発明では、指定された宛先デバイスへのＱｏＳパスの特定の要求で開始されるＱｏＳパス選択のプロセスに応答して、当該宛先デバイス（サブネットのエッジノード、ＬＡＮ、ＷＡＮなど、または端末）からノードパスへの１つまたはそれ以上のプリセットノードへリンクすることにより問題を解決する。
【００２１】
【課題を解決するための手段】
実施形態ではプリセットパスを使用するが、最初のホップノードは各々の宛先デバイスについてのパステーブルを格納しない。その代わり、最初のホップノードは各々の最後のホップノードに対するプリセットパスを表わすパステーブルを格納する。ＱｏＳパス要求の送信元デバイス、例えば、サブネットのエッジノードや端末などは、希望するデータフローのフロー情報とパスを拡張すべき宛先端末とを表わす最初のホップノードへの要求信号を送信する。これに応答して、最初のホップノードは次のような特徴にしたがって指定されたパスにフローを割り当てる：
１）最初のホップノードでは各最後のホップノードを各々のパスにリンクするテーブル（ノードパステーブル）を格納する。
【００２２】
２）送信元及び宛先デバイスが最初のホップノード／最後のホップノードのＩＤを取得する。
【００２３】
３）ＱｏＳパス要求に応答して、宛先デバイスが最初のホップノードへ最後のホップノードＩＤを送信する。
【００２４】
４）宛先デバイス又は最初のホップノードで、特定の要求が最後のホップノードＩＤに関連付けられる。
【００２５】
５）最初のホップノードは最後のホップノードＩＤを使ってノードパステーブルからプリセットパスを抽出し要求状態を送信元デバイスに通知する。
【００２６】
本発明による上記の解決方法は後続のＱｏＳ要求を満たす従来技術のプリセットパスの利点の全部を提供することができ、しかも、ＱｏＳパスの急激に増大する使用を処理する際に生ずるネットワーク内の計算資源及びストレージ資源への従来技術で非常に大きかった要求に関連する従来技術での問題点を解消する。
【００２７】
【発明の実施の形態】
インタラクティブ・ビデオ通信や高画質ビデオ配信などの用途でＱｏＳを提供するのために、ネットワーク、例えば、図１のＷＡＮでの要求が多くなる。マルチプロトコル・ラベルスイッチング（ＭＰＬＳ）は、ＱｏＳを実現するようにネットワーク経由の専用パスを設定する。パケットスイッチング・ネットワークでは各パケットが宛先識別子を持っており、本明細書ではこれを宛先マシンＩＤと呼ぶことにする。ネットワークが大規模になるとＭＰＬＳパスも個数が増加する。
【００２８】
本発明の実施形態は、図２に示したように、オンデマンド・サービス品質（ＱｏＳ）保証サービスの一部として、ネットワーク・プリセットアップ・フェーズを使用する。ネットワーク・プリセットアップ・フェーズは、例えば、発明の背景で説明した従来技術に開示されているように従来技術によるものである。上記出願の基本的なパス設定技術は、特に本出願の図５及び図６に関連して以下で説明する。
【００２９】
ネットワークは、ノード（ゲートウェイ、端末、エッジノード、中間ノード、スイッチなど）がリンク（幹線、回線など）で結合されるインライン通信で、素材管理システム（ＭＭＳ、Material Management System）、ネットワーク管理システム（ＮＭＳ, Network Management System）や幹線管理システム（ＴＭＳ, Trunk Management System）を含むものである。ＴＭＳとＭＭＳは、ネットワーク内の「資源」を予約するように機能し、これによって、ネットワークのリンクが特定のデータ処理能力（例えば１００Ｍｂｐｓ）を持っていると識別される。次に、各リンクのデータ処理能力がノードに対して全体として又は部分として割り当てられ、それらのノードは、ノードのデータ処理能力に基づいてデータ通信及びネットワークへの参加を管理する。
【００３０】
ＴＭＳは図示していないが、図１のノードＡ１、Ａ、Ｂ、Ｃ、Ｄに含まれシステムバスによってメモリへ結合されたプロセッサを含む。メモリは各種テーブルを保持し、これにはＴＭＳ準備テーブル、ＴＭＳ幹線テーブル、ＴＭＳ幹線状態テーブル、ＴＭＳパステーブルが含まれる。テーブルは本発明を理解するのに必要な場合にのみ本明細書で詳細に開示しており、それ以外の従来のテーブルは、不必要に詳細になることにより本発明が不明瞭にならないようにするために、説明しないこととする。
【００３１】
エッジ又はゲートウェイ・ノードＡ１及びＡは、ネットワーク・プリセットアップ・フェーズを実装するために使用され、ノードのインテリジェンスを提供し従来のノード・プロセッサにより実行される制御プログラムをストレージに含む。そして、このプログラムは、ノードパステーブル、ノード幹線テーブル、ノードインタフェース状態テーブル、ノード幹線状態テーブルを含む多数のテーブルでＮＭＳから受信した情報を管理する。ノードインタフェーステーブルは、ノードに関連するアクセスネットワークなどのネットワーク・リンクへ接続するノードの別のインタフェースを識別する。
【００３２】
ネットワーク上の発信元マシンから宛先マシンへ送出されたメッセージ（パケット）には、ノードがネットワーク資源とネットワークを通るパスを割り当てるのに使用するヘッダ情報が提供される。
【００３３】
ネットワーク・プリセットアップ・フェーズ（期間）の間、所定の経路（パス）とあらかじめ設定されたリンク資源（例えば、バンド幅、クラスなど）がテーブル内でＮＭＳにより割り当てられる。従来と同様に、パスのエッジ及び内部ノードはキューイングとバッファリングを含み、これによりある種のＱｏＳクラスで転送レートの設定ができるようになる。ＮＭＳは、エッジノード（最初のホップノードと最後のホップノード）へ、また中継ノード（中間ノード）へ制御情報を送出してキュー制御を設定し、これによりリンクの資源を設定する。同様に、ＮＭＳから図２の最初のホップノード及び最後のホップノードへ送出された制御情報は、代表的にはノードが保持するルーティング情報を変更してこれにより特定のパスを割り当てる。
【００３４】
ＴＭＳルーティングテーブルは、ＮＭＳが初期化の間に準備しＴＭＳへ提供されるが、他のノードへ割り当てられたパスに関係する情報を含む。ＴＭＳルーティングテーブルの一例として、各パスについて、カラムには最初のホップノード、最後のホップノード、パスを形成するネットワークリンクがリストアップされる。ＴＭＳは各ノードに関係するＴＭＳパステーブルの部分をそのノードへ送信する。
【００３５】
ＮＭＳは、最初のホップノード、最後のホップノード、中間ノードを制御してこれらの出力のデータ通信特性を設定し実効的に通信クラスとして（この例ではもクラスＡ）パス又はリンクバンド幅を設定する。従来のディファレンシャル・サービス（ＤｉｆｆＳｅｒｖ）アーキテクチャを用いて、または他のＱｏＳ実装を用いて、出力キューとこれに関係するキュー制御回路は、ノードにパケットを分類、マークづけ、監査、体系化、順位付けさせるように設定する。これによりＮＭＳは、各方向に固有のリンクへ特定のバンド幅を割り当てる。このようなリンクは「暫定リンク」と呼ばれる。暫定テーブルはリンクが接続する二つのノードにより各暫定リンクを識別する。テーブル内で、各リンクには、例えば、バンド幅などの通信特性が割り当てられる。
【００３６】
ＴＭＳによる資源の分散により、各ノードにはプリセットパスが提供され、その各々は特定のバンド幅が用意されたネットワークリンクを含む。ノードパステーブルは各ノードが保持して暫定リンクの各々のバンド幅を含む。特定の方向でバンド幅を配分するには、ネットワーク・プリセットアップの間にＮＭＳとＴＭＳにより設定されたパスによって変化するが、各ノードの準備に３、３未満、４又は４方向以上の数個のリンクにバンド幅を分割することが必要になる。
【００３７】
資源をネットワークリンクに割り当てて、これらの資源をノードに配分した後、ＴＭＳは各ノードについてＴＭＳパス状態テーブルを作成して保持し、これには以下のカラムが含まれる。すなわち、当該ノードで管理される各パス、各パスの暫定リンク識別、各パスのバンド幅、各パスが使用されているか否か、そのパスで利用できる未使用バンド幅の量である。
【００３８】
ノードパス状態テーブルは、ノードの各々が保持しており基本的にＴＭＳパス状態テーブルと同じ情報を含むが、各々のノードだけについてである点で異なる。また、ＴＭＳにより資源を割り当てた際に暫定リンクになるネットワークリンクが識別される。
【００３９】
ノード幹線状態テーブルは、各ノードで処理される通信が変化するので連続的に変化する。ノードを通る通信が開始して停止すると、そのパスでテーブル内に格納されている「利用可能」と「使用中」の資源の量が、使用しているパスに合わせて変化する。さらに、パス状態情報はＴＭＳへ定期的に送出されてＴＭＳパス状態テーブルを変更し、様々なノードパスの状態も反映することができる。しかし、ＴＭＳパス状態テーブルの情報は、状態情報がＴＭＳへどの位速く又どの位の頻度で送信されるかに依存した量だけ、ノードパス状態テーブルのそれを遅延させる。例えば、ノードは自分自身のノード幹線状態テーブルを変更した直後にパス状態情報を送信することがあり、又はもっと少ない頻度で例えば所定の時間間隔の後などで状態情報を送信することもあり、又は他のキーイング・イベントによって情報を送信することもある。
【００４０】
各ノードは、ゲートウェイとして１つ以上のネットワークと接続することがあり、または、一つのネットワークに対して複数の接続を張ることもあり、その結果接続の各々についてインタフェースを有する。各ノードでノードフローパステーブルが作成されて保持され、各インタフェースの資源を識別する、すなわちバンド幅、使用中のバンド幅の量、未だ利用可能な未使用バンド幅の量である。この情報は、各ノードでノードパス状態テーブルにあるパスが保持される情報と同様である。
【００４１】
各ノードの割り当てられたバンド幅は、送信元マシンが要求しＱｏＳデータ転送を許可された場合に使用され、これによって図５に示したように転送が行なわれる長さのデータ通信パスを作成する。図５は図面のパスセットアップフェーズを実行する代表的な方法のフローチャートである。
【００４２】
図５、ステップ１５２：図２のパスセットアップフェーズの第一の通信として最初のホップノードへ接続されたデバイス又はネットワーク上の実体（すなわち、送信元マシン、これは図１と図２の送信元端末である）からＱｏＳパスの要求を最初のホップノードＡ１が受信する。要求は、パスの特性、例えば、バンド幅、クラスその他（フロー情報）についてのもので、宛先端末ＩＤと最後のホップノードＩＤを含む。
【００４３】
図５、ステップ１５６：最初のホップノードはノードフローパステーブルを検索して、ネットワークに接続して要求を承認するインタフェースで利用可能な資源があるかを判定する。資源がない場合、手順はステップ１５６からステップ１８４へ分岐し、ノードは要求元（送信元マシン）へ「拒絶」を返して手順を終了する。しかし、充分なインタフェース資源が利用できる場合には、手順はステップ１６０へ進む。
【００４４】
図５、ステップ１６０：最初のホップノードは要求を承諾するとの想定の元でインタフェース資源を予約し、ノードはフローパステーブルを検索して要求の宛先ＩＰアドレスに対応する宛先マシンへのプリセットパス又はパス群を検出する。プリセットパスが見つかれば、手順はステップ１６２へ進む。
【００４５】
図５、ステップ１６２：ノードはパスが要求の資源と一致する必要のある資源を有しているか判定する。多数のパスが利用できる場合、最初のホップノードは、全部のパスの資源を調べる。要求された資源を備えたパスが見つからない場合、手順はステップ１６４へ進む。要求された資源を備えたパスが見つかった場合、手順はステップ１７０へ進む。
【００４６】
図５、ステップ１６４：最初のホップノードはパス再設定手順（図６を参照してさらに完全には以下で説明する）を実行すべきか否か判定する。結果がイエスなら手順はステップ１８０に進みノーの結果なら手順はステップ１８４へ進み、ここで最初のホップノードは要求元へ「拒絶」を返して手順を終了する。パス再設定の決定は、初期化中又は資源状態に基づいて制限される（例えば、単位時間あたりで何らかの個数の要求だけを行なうように設定される）。
【００４７】
図５、ステップ１８０：パス再設定は、希望のパスの暫定リンクの１つまたはそれ以上にバンド幅を一時的に再割り当てする。
【００４８】
図５、ステップ１８２：ステップ１８０のパス再設定によって不十分な資源が復元される場合、手順はステップ１８４に進み、最初のホップノードは要求元（送信元端末）へ「拒絶」を返して手順を終了する。パス再設定処理が充分な資源を得られる場合、手順は後述のステップ１７０に進む。
【００４９】
図５、ステップ１７０：最初のホップノードが要求を許可して資源とパスを予約した後、最初のホップノードは最後のホップノードへ制御信号を送信し要求を最後のホップノードへ通知する。
【００５０】
図５、ステップ１７２：最後のホップノードは、これに関連する端末ポートテーブルを調べて通信を処理する資源を決定する。
【００５１】
図５、ステップ１７４：資源が充分でない場合、手順はステップ１８６へ進む。資源が充分な場合手順はステップ１７６へ進む。
【００５２】
図５、ステップ１８６：最後のホップノードは、送信元の第１のノードに拒絶を返し手順は前述のステップ１８４へ戻る。
【００５３】
図５、ステップ１７６：最後のホップノードは、必要な設定をセットアップして要求で指定された最初のホップノードからの信号で記載された（フローポートテーブルを作成する）ＱｏＳパスに準じたパケットをマークし転送し、さらに最初のホップノードへＡＣＫ（肯定応答）を返す。
【００５４】
図５、ステップ１７８：最初のホップノードは、要求で指定されたＱｏＳ条件にしたがって、パケットをマークし転送するための設定をセットアップして送信元端末にＡＣＫを返す。手順はこの後ステップ１９０で終了する。
【００５５】
その後、送信元端末は、図２のデータ転送フェーズにしたがって、パケットを送信し、通信を開始する。送信元端末が通信を終了するとき、「解放」メッセージを送出し（図２に図示していない）、これに影響を受けるノードは、適宜テーブルを変更する。
【００５６】
図５に図示した処理のステップ１８０でパス再設定の主要ステップが図６に示してある。要約すると、図６のパス再設定処理は要求に応じてＱｏＳパスを探している最初のホップノードのパスに少なくとも一時的に再割り当てすることが可能な余剰資源を特定するように機能する。すなわち、最初のホップノードによって管理されたプリセットパスのいずれにおいても充分な資源を持ったパスが見つからない場合、１つまたはそれ以上のパスの利用可能な資源を再割り当てすることでパスを見つけ出す試みがパス再設定により行なわれる。
【００５７】
図６、ステップ２０２：最初のホップノードはＴＭＳへ要求を送信し、これにはさらに多くの資源（例えばバンド幅）を必要とするリンクの識別と必要とされるバンド幅の量が含まれる。
【００５８】
図６、ステップ２０４：ＴＭＳはＴＭＳパス状態テーブルを検索して要求で識別されたパスと共通の暫定リンクを共有する別のリンク（他のノードが管理する）を探す。あるパスについて多数の共有リンクが存在する場合、パス再設定処理ではリンクの全てが候補となり、要求に対して不十分な資源を持っているパスは要求によりＴＭＳへ通知される。したがって、パス状態テーブルを用いてＴＭＳは、再設定要求で識別されたパスと同じように、同じ不十分な資源のリンクを共有するパスを特定しようとする。１つ以上のパスが見つかった場合、ＴＭＳはそのパスの利用可能な資源と要求の必要性に基づいてパスを選択する。
【００５９】
図６、ステップ２０６：パス資源有効性の肯定的決定（イエス）では手順がステップ２１０に進み、それ以外ではステップ２０８に進む。
【００６０】
図６、ステップ２０８：見つかったパスをいずれにしても使用すべきかを決定する。しない場合には、手順はステップ２１６に進む。前述したように、ＴＭＳパス状態テーブルの状態情報はノードによって維持されている状態情報を遅延させる。遅延量はノードがＴＭＳの状態更新情報を送信する頻度によって変化する。すなわち、ステップ２０８の決定はＴＭＳで利用可能な状態が不正確であり、特定のパスが必要とされる資源を本当に持っていると言う仮定で行なわれる。したがって、ステップ２１０の要求は、いずれにしても行なわれる。
【００６１】
図６、ステップ２１６：ＴＭＳは最初のホップノードへ「拒絶」メッセージを返して手順を終了する。
【００６２】
図６、ステップ２１０：ＴＭＳはパスの識別と必要とされるかあるいは希望するバンド幅の量で別のパスを管理するノードへ要求を送信する。
【００６３】
図６、ステップ２１２：別の幹線上の資源についての要求を受信したノードは、これに付属するテーブルを検索して、要求された別の幹線の状態を調べる。その別の経路には要求の条件に適合するには不十分な資源しか存在しないとノードが判定した場合、ノードがＴＭＳへ「拒絶」を送信した後で手順をステップ２１４へ進め、それ以外の場合手順はステップ２１８へ進む。
【００６４】
図６、ステップ２１４：ＴＭＳは再試行するかどうかを決定する。再試行する場合、手順はステップ２０４へ戻る。決定は少なくとも部分的にパスを共有するのが二つ又はそれ以上のノードであると言う事実に基づいている。一方のノードが管理するパスに充分な資源がない場合でも他方にはある場合がある。したがってステップ２１４はステップ２０４へ戻って必要とされる資源について別のパスを発見しようと試みる。
【００６５】
これ以外に、ステップ２１４でＴＭＳが使用する決定処理は、充分な資源のある別のパスを特定しようとする試行のプリセット回数又は他の何らかの要因に基づくことができる。
【００６６】
図６、ステップ２１８：別のパスを管理するノードが「承認」をＴＭＳへ送信し付属するテーブルを調節する（別の幹線で「バンド幅」と「利用可能」のカラムの両方で示された資源の量を減少させる。
【００６７】
図６、ステップ２２０：ＴＭＳはパス状態テーブルを変更して資源の再割り当てを反映させる。ＴＭＳは要求が認められた再設定要求を行なったノードに通知して、パス状態テーブルを変更させ再設定を適宜反映させる（すなわち資源の再割り当て）。
【００６８】
図６、ステップ２２２：追加の資源を探している最初のホップノードもテーブルを変更して、問題の幹線について追加の資源を反映する。
【００６９】
ＱｏＳパスの構築を使用する従来のネットワーク構成及びパケットスイッチング用アーキテクチャは代表的には「パス」と言う用語すなわちエンド間接続でネットワーク経由の資源を管理していた。上記の制御ではネットワーク内の資源を「リンク」単位で管理する。送信側ノードがパスを作成する場合、パスを作成できるかどうかはこれが管理しているリンク資源（幹線資源）情報に基づいて決定し追加の情報を他の実体に尋ねる必要はない。
【００７０】
ＮＭＳとＴＭＳは一つの要素に結合することができる。ゲートウェイ要素とこれに対応するエッジノードは単一の最初のホップノードとして統合することができ、これが前述したようなシグナリング、資源管理、承認制御などのゲートウェイ機能を有することになる。
【００７１】
図５と図６に関連して説明したように、ネットワーク経由の図２のパスセットアップフェーズはデータ転送のＱｏＳに特定の要求で開始する。最初のホップノードは要求のＱｏＳ要求に適合するのに資源が充分か否かをチェックする。資源が充分でない場合、追加の資源を他のノード割り当てから借り受けることができ、これは管理システムへの「再設定」要求により図２の従来のネットワーク・プリセットアップ・フェーズで行なった。充分な資源を再割り当てできた場合、送信元ノードは要求を許可でき、資源がない場合要求は拒否される。ネットワーク内で接続単位でネットワーク資源を予約し制御する必要性が排除される。
【００７２】
図１において、簡略化した広域ネットワーク（ＷＡＮ）例えばインターネットが図示してあるが、これは最初のホップノードＡ１と複数の最後のホップノードＡ、Ｂ、Ｃ、Ｄに対してだけである。中間ノード（図示していない）はネットワークの端に図示されたノード間の多数のパスに沿ってネットワーク内に存在する。送信元デバイス（図面の実施形態では送信元端末）は最初のホップノードに接続されるが、実際には例えば複数の送信元マシン、端末、サブネットのエッジノードが最初のホップノードＡ１のポートに接続される。各々の最後のホップノードは複数の宛先マシン（図面の実施形態では宛先端末）へ接続され、宛先マシンは、例えば、サブネットの端末やエッジノードであっても良い。
【００７３】
図１において、各最初のホップノードはコンピュータ・システムを使用するが、これの詳細は周知であり従来のものであることから図示していない。コンピュータ・システムはコンピュータで読み取り可能なコードのストレージを含み、これはフローパステーブル、ノードパステーブル、端末ポートテーブル、フローポートテーブルを本発明による実施形態として含めるように一部分模式的な形で図示してある。
【００７４】
図１は本発明の実施形態であるため図１には図示していないが、発明の背景で参照した従来技術はＩＰルーティングテーブルを備え、ＱｏＳの要求が行なわれる前にネットワークプリセットで作成される。従来技術のＩＰルーティングテーブルは一方のカラムにＩＰアドレス、例えば最初の３列で宛先端末Ｔ１，Ｔ２，Ｔ３のアドレス、また別のカラムでは、最初の３列でプリセットパスの識別例えばＰ１，Ｐ２，Ｐ３を含む。前述したように、このような従来技術のテーブルは巨大であり急激に大きくなるが、これはネットワークの個々のノードへ接続される全部の端末のためである。本発明ではプリセットパスへ接続される端末の識別を必要とせず、最後のホップノードの識別だけしか必要としない。
【００７５】
プリセットパスの従来技術は、ＱｏＳ要求の時点でのパスの従来のセットアップに対する改善である。本発明は、従来なら予想されない方法でプリセットパスの従来技術を改善するものであり、プリセットパスの宛先マシンリンクへの最後のホップの識別をその宛先マシンに関係するＱｏＳパスの特定の要求時にセットアップすることによる。ネットワーク上での計算負荷及びストレージ要求を減少する点で本発明の利点は大きい。以下の説明は実施形態のこの部分の実装として、より詳細に記述するものである。
【００７６】
図１において、各々の宛先デバイスはコンピュータ・システムを使用し（これの詳細は周知であり従来のものであることから図示していない）、コンピュータ・システムはコンピュータで読み取り可能なコードのストレージを含み、これは例えばフローポートテーブルなど実施形態のテーブルを含めるように一部分模式的な形で図示してある。当該テーブルは宛先マシンをこれに対応するネットワークノードＡ、Ｂ、Ｃ、又はＤの接続ポートに関連付ける。
【００７７】
図２に図示してあるように、本実施形態の処理には第１のフェーズがあり、これはネットワーク・プリセットアップ・フェーズである。最初のホップノードＡ１と１つまたは複数の最後のホップノード例えば図１の最後のホップノードＡ、Ｂ、Ｃ、Ｄがこれらの間でネットワークＷＡＮの介在ノードを含めた静的パス上で情報を交換し（介在ノードは、図２に図示してあり図１のネットワークでも含まれる）、プリセットパスを従来の方法で構築し、本発明によるセットアップでは宛先端末を含める必要がない点で異なっている。プリセットパスの構築時には、最初のホップノードは図１に図示したフローパステーブルとノードパステーブルを生成又は作成する。これらのテーブルは本発明でユニークなものだが、プリセットパスを構築するのに使用される方法は、例えば発明の背景で言及した従来技術に説明されているように、従来技術で周知のものであって、前記非特許文献１の中の広域ネットワークにおけるＭＰＬＳメソッドを含め、当該目的で本明細書に開示が含まれる。これによって多数のパスが最初のホップノードと最後のホップノードの間でセットアップされ、別の中間ノードを経由する別のパスが選択される。各プリセットパスは単方向又は双方向である。
【００７８】
図２の処理で次のフェーズは従来の端末ログオンに関係し、ここで宛先及び送信元マシン例えば端末が各々のノードＡ１、Ａ、Ｂ、Ｃ、Ｄに接続する。その結果宛先及び送信元デバイスは各々のノードＩＤを各々取得する。ノードの各々は、端末ポートテーブルを作成、更新、又は何らかの維持を行ない（ここでは最後のホップノードテーブルだけが本発明に関係する）、テーブルは各々のログオンしたデバイスと、結合されているエグレス／イングレス・ポートを関連付け又はリンクする。本発明で注目すべきこととしては、各々の宛先端末ＩＤが宛先端末の接続された最後のホップノードのエグレス・ポートにリンクされることである。このフェーズは、ネットワークへの端末ログオン時又は端末がロケーションを変更し別のノードへ接続したときに完了する。このフェーズで本発明でことなっているのは、本実施形態で、端末がログオンした又はノードの関係を変更したネットワークについて他のノードや制御に通知する必要がないことである。
【００７９】
図２に示した第３のフェーズはアプリケーションレベルの接続セットアップで、これはＱｏＳパスのオンデマンド要求に関連して本発明で完全に独自のものである。例えば、送信元と宛先マシンに常駐するアプリケーションは、ビデオ会議用である。従来の方法では送信元と宛先マシンが従来のＩＰルーティングを使用して、例えばＨ．３２３及びＳＩＰ標準を使用してアプリケーションレベルの接続を確立する。送信元デバイスは宛先デバイスが直接接続されるべきノードを識別するように要求する。これに応答して、宛先デバイスは最後のホップノード経由で送信元端末へ、従来のＩＰルーティングを使用して、すなわちプリセットパスなしで、最後のホップノードのＩＤと宛先端末ＩＤを含むメッセージを送信する。宛先端末ＩＤと最後のホップノードＩＤを送信元端末へ通知するあらゆる手段が使用でき、上記の方法は通信を確立する手段の単なる代表例にすぎない。
【００８０】
図２に図示した次のフェーズは、パスセットアップに関連するもので、これは図５及び図６に関連して詳細に前述した。送信元端末はＱｏＳパスの要求を、オンデマンドＱｏＳパスサービスの一部として、最初のホップノードへ送信する。要求には最後のホップノードのＩＤと希望する宛先デバイスの識別ＩＤ、例えば、各々ＡとＴ１が含まれる。このステップは、図１に図示していない。要求にはフロー特性例えば送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号などのフロー特性を指定するフロー情報も含まれる。
【００８１】
ノードパステーブルと最後のホップノードのＩＤを用いて最初のホップノードは要求を最適に満たし最後のホップノードへ接続するパスを決定する。最初のホップノードは、ノードパステーブル、選択パスから抽出した情報を使用して、プリセットパスへ各々のフローをリンクする図１のフローパステーブルを作成又は更新する。要求は最初のホップノードＡ１によって送信され、これは本実施形態において送信元デバイスがインターネットＷＡＮ上で宛先デバイスへ接続されるノードである。宛先端末のＩＤ、最後のホップノードのＩＤ、要求されたＱｏＳパスのフロー情報は送信元デバイスによって最初のホップノードへ送信される。従来のＩＰルーティング又は選択されたＱｏＳパスをこの通信に使用できる。
【００８２】
最後のホップノードは、これに応答して図１に図示したフローポートテーブルを作成し、このフローポートテーブルは、各フローＦ１、Ｆ２などを関連するエグレス・ポートＥ１、Ｅ２などへ関連付ける又はリンクする。
【００８３】
この後、最後のホップノードは処理において、これまでにその部分が更新を完了したことを表わす最初のホップノードへの肯定応答（ＡＣＫ）を送信する。ＡＣＫ受信時に、最初のホップノードは同様のＡＣＫを送信元デバイスへ送信する。
【００８４】
図２に図示した次のフェーズはデータ転送である。送信元デバイスは最初のホップノードへデータ送信、パケットフローを開始する。受信時に、最初のホップノードはパスセットアップフェーズで選択されたＱｏＳパスへ指定されたフローを割り当てる。これによって最初のホップノードと中間ノードは指定されたプリセットパスを要求されたＱｏＳに使用する最後のホップノードへパケットを転送する。最後のホップノードはフローをエグレス・ポートへリンクし、データ、パケットフローを指定された宛先デバイスへ送信するフローポートテーブルを参照する。
【００８５】
したがって、送信元端末（マシン又はデバイス）から宛先端末（マシン又はデバイス）へＷＡＮ経由でデータの転送を管理するため、最初のホップノードは、端末がログオンされるとデータベースの端末ポートテーブル（すなわち、フローポートテーブル）を更新して、最初のホップノードへ結合されたマシンについての状態情報を提供し、しかる後ログオンした各端末へこれのノードＩＤを渡す。
【００８６】
次に、最初のホップノードは、ＷＡＮ経由でサービス品質（ＱｏＳ）を保証したプリセットパスを確立し、ＷＡＮ経由のプリセットパス、パスのＱｏＳが依存するネットワーク資源、各ＱｏＳパスのＷＡＮ最後のホップノードの識別子の間の関連性を提供するためにデータベースのノードパステーブルを更新する。なお、このときに、パスの各宛先端末の識別を必要としない。
【００８７】
そして、最初のホップノードは、指定された送信元端末から指定された宛先端末へのオンデマンドＱｏＳ保証パスのアプリケーションレベル要求を受信して、要求において指定された宛先端末に対応付けられた最後のホップノードの識別についての問い合わせと応答をＷＡＮ上で送信することにより、従来のＩＰルーティングを使用するアプリケーションレベル接続を確立して、送信元端末と宛先端末で動作しているアプリケーションを支援する。（この支援は、要求で指定された宛先端末に対応付けられた最後のホップノードの識別に関して問い合わせる宛先端末へアプリケーションレベルの信号の送信する。また、応答が送信されるべき送信元端末から発信されたときに信号を識別する）。
【００８８】
次に、最初のホップノードは、要求で指定された宛先端末へ結合された最後のホップノードを識別しまた最後のホップノードと宛先端末のうちの一方から発信されたものとして信号を識別する（後者の場合が実施形態である）。
【００８９】
次に、最初のホップノードは、宛先マシンへ結合された最後のホップノードの識別を送信元端末から受信する。
【００９０】
次に、最初のホップノードは、データベースのフローパステーブルを作成し最後のホップノードへ情報を送信してこれのデータベースのフローポートテーブルを作成し、完了時に送信元端末へ完了を肯定応答する。
【００９１】
次に、最初のホップノードは、フローパステーブルの作成の一部として、ノードパスデータベースが検索されＱｏＳパスが宛先マシンに対応付けられた最後のホップノードの要求及び識別子の両方に基づいて抽出される。
【００９２】
その後、次に、最初のホップノードは、要求にしたがって宛先端末へ送信元端末のためのパケットを転送する。
【００９３】
「最後のホップノード」Ａ、Ｂ、Ｃ、Ｄは、全て通信で最初のホップノードとして機能し、「最初のホップノード」Ａ１は最後のホップノードとして機能する。すなわち、ＱｏＳのオンデマンド要求をどの端末が行なうかに依存しており、それらのノードは、逆の役割のプログラムとテーブルを有することを意味する。
【００９４】
本発明の更なる実施形態として、最初のホップノード端末が、上記の例の宛先端末と送信元端末によって実行されるアプリケーションレベルの作業の幾つかを肩代りすることもできる。本発明は、例えば、ネットワークがＩＰルータを含むネットワーク・サービスで使用可能である。本発明は、他のネットワーク、例えば、プリセットパスを有することがあるＡＴＭ（非同期転送モード）ネットワークで使用可能である。
【００９５】
本発明は多数の実施形態及び実装との関連で説明したが、これらにより本発明が限定されるものではなく添付の請求項の範囲に納まる各種の明白な変更及び等価な構成を包含する。
【００９６】
本発明の態様、特徴、利点は、本発明を実現する上で発明者が意図した最良の態様である特定の実施形態及び実装を、変更及び変化を含めて簡略に図示することで、以上の詳細な説明から容易に明らかになった。本発明はその他の及び別の実施形態も可能であり幾つかの詳細は本明細書の教示にしたがえば各種の明白な態様で、全てが本発明の趣旨と範囲から逸脱することなく変更が可能である。したがって図面及び説明は本質的に図示を目的としたものであって制限ではないと考えるべきである。
【００９７】
【発明の効果】
本発明によれば、最初のホップノードは宛先端末へプリセットパスをリンクする情報を格納また管理する必要がない。実施形態において最初のホップノードは、最初のホップノードへプリセットパスをリンクする情報を管理し、要求が行なわれ予備的なプリセットパスが選択されるまで宛先端末へのリンクを要求しない。端末数は最後のホップノードの個数の逓倍数であるから、これは要求されるテーブルサイズを大幅に減少させ、その上、最初のホップノードでのストレージ要求とデータベース管理処理負荷を大幅に減少させる。ここで、最初のホップノードは、理論的に例えばネットワークのエッジノードの全部とＷＡＮのゲートウェイ・ノードの全部である。
【００９８】
また、宛先端末がロケーションを変更して別の最初のホップノードへ接続する場合には、最初のホップノードのパステーブルは再設定される必要がない。これは端末のロケーションが頻繁に変化する場合、また、ポータブル又は移動体端末の使用が増加して、最後のホップノードは、将来的にさらに頻繁に変化する場合に、最初のホップノードの計算負荷を大幅に減少させる。
【図面の簡単な説明】
【図１】ネットワークとくにＷＡＮと、当該ネットワークに接続される端末の略図で、本発明の実施形態によりオンデマンドで割り当てられるＱｏＳパスのテーブルの例は最初のホップノードと最後のホップノードに格納される。
【図２】図１のＷＡＮのノードすなわち図１の送信元端末と図１の宛先端末で送受信される信号のチャートで、上から下へ向かって本発明の実施形態を実装する際の信号の代表的順序を示す。
【図３】最初のホップノードテーブルの例で、エッジノードで記憶媒体に存在し図１の最初のホップノードとして動作するエッジノードで使用され、本発明の実施形態を実装するための代表的データを示す。
【図４】図４は、端末ポートテーブルの例で、エッジノードで記憶媒体に存在し図１の最後のホップノードとして動作するエッジノードで使用され、本発明の実施形態を実装するための代表的データを示す。
【図５】図２に開示した本発明のネットワーク・プリセットアップ・フェーズで動作し、ネットワーク内の最初のホップノード又は後続のホップノードで行なわれてネットワーク内でＱｏＳパスをセットアップするためのステップを示すフロー図である。
【図６】ＱｏＳパス要求に対応する容量を備えたネットワーク経由のパスを取得しようとする際のパス再設定に関して、図５のステップ１８０をさらに詳細に示すフロー図である。
【発明の属する技術分野】
本発明はサービス品質の要求に適合するネットワーク内のプリセットパスに関する。
【０００２】
【従来の技術】
広域ネットワーク（ＷＡＮ, Wide Area Network）、とくにインターネットは通信量の増加によるストレージと計算量の過負荷に悩まされており、この問題は憂慮すべき事態になってきている。
【０００３】
資源予約プロトコル（ＲＳＶＰ, Resource ReSerVation Protocol）は、ネットワーク資源の予約メッセージと確認メッセージが接続される度にデータの通るノード全部で必要とされ、接続が確立される際に長い遅延を作り出すことが多い。ＲＳＶＰおよびマルチプロトコル・ラベルスイッチング（ＭＰＬＳ, MultiProtocol Label Switching）ネットワークでは、ネットワークの規模が大きくなるにつれて、接続数とあるノードが処理しなければならない予約のトランザクション数が増大し、これに相応する大きな計算量が各ノードに求められ、またネットワークは必要とする接続やトランザクションを処理できなくなることもある。
【０００４】
最近、インターネット・プロトコル（ＩＰ, Internet Protocol）基盤上で動作するアプリケーションが進化し、データの高バンド幅かつリアルタイム転送が必要とされるようになってきた。これらの要求が強いアプリケーションを、例えば、Ｅ−メールのダウンロード、Ｗｅｂページトランザクションのような従来のアプリケーションと区別ものとして、例えば、サービス品質（ＱｏＳ, Quality of Service ）属性例えばバンド幅、遅延、及びジッタなどを保証する仮想パス（以下単に「パス」と言う）が使用されうる。データ送信元は、データフローを割り当てるパスを指定してからそのパスにデータを送出して保証されたＱｏＳを得るようにする。
【０００５】
例えば、特許文献１などに記載されているように、従来技術のひとつの方法ではプリセットパスを設定する。プリセットパスは、広域ネットワーク（ＷＡＮ）、例えばインターネットの最初のホップノードと最後のホップノードの間に設定され、最初のホップノードへ直接接続する端末からはじまり最後のホップノードへ直接又は間接に接続する端末で終わるあらゆるパスで使用できる。最初のホップノードと最後のホップノードへ直接接続する多数の端末が、それら自身のパスを設定した場合にはプリセットパスを共有できる。
【０００６】
本明細書で用いているように、ネットワークのエッジ・ノード、サブネットワークのエッジ・ノード、ワークグループのエッジ・ノード、およびゲートウェイは広域ネットワークの最初のホップノードと最後のホップノードの例であり、これらは最初のホップノードと最後のホップノードの間のパスに沿って存在するトランジット（中間）ノードとは対照的である。
【０００７】
ルーティング情報は、非特許文献１によれば、ＷＡＮの最初のホップノードと最後のホップノードの間で交換される。最初のホップノードは宛先端末のＩＰアドレスをプリセットパスへリンクするパステーブルを必要とする。発信元の端末は宛先ＩＰアドレスと一緒に最初のホップノードへパケットを送出する。最初のホップノードは宛先ＩＰアドレスを使用してパステーブルからパスを抽出し、その後選択されたプリセットパスに沿ってパケットを転送する。
【０００８】
特許文献２では、多数のサービス品質（ＱｏＳ）パラメータを指定する接続要求に応答して宛先への第一のパスを選択している。第一のパスに沿った第一の信号の伝送が失敗した場合には、第二のパスがデータベースにしたがって選択される。プリセットパスはＱｏＳについて最新に保持される。
【０００９】
特許文献３では、端末のログオン時に利用可能なプリセットパスを説明している。発信元ネットワーク要素はパスの開始点であり、次のネットワーク要素に向かってパストレース値を送信し、このパストレース値はパストレース値を送信する要素の識別値を有する。受信側要素はパストレース値の識別子を自分自身の識別子に変更してから、変更したパストレース値を次の要素へ再送信すると言う具合にエンドポイントまで続く。それぞれの要素は相互接続情報を保持し相互接続情報を用いてパスを構築するネットワーク管理システムへ送信する。
【００１０】
特許文献４は、同じＩＰネットワーク・アドレスを割り当てられた複数のルータ・インタフェースがＩＰワークグループを作成しホストの再設定を必要とすることなくワークグループ内のどこにでもホストを再配置できるようにしている。単一のアドレスを幾つかの物理ネットワークで使用する。
【００１１】
特許文献５は、ネットワーク内の送信元ノードと宛先ノードの間で最小限しか重複しない複数のパスを決定するためのシステムを開示している。第一のパスと第二のパスが重複している場合、システムは、少なくとも一方のパスを変更してパスの重複を最小限にとどめるようにし、一つのパスでの障害が別のパスの障害を誘発する可能性を減少させるようにしている。
【００１２】
上記従来技術から理解されるように、ＱｏＳパスのセットアップの改良の必要性がある。
【００１３】
【特許文献１】
米国特許６，１０８，３０４号
【非特許文献１】
IETF, Multi-protocol label Switching Architecture, RFC3031, January 2001
【特許文献２】
米国特許５，９３３，４２５号
【特許文献３】
米国特許６，０９４，６８２号
【特許文献４】
米国特許５，７５１，９７１号
【特許文献５】
米国特許６，２５６，２９５Ｂ１号
【００１４】
【発明が解決しようとする課題】
ここに記載したニーズ、また、その他のニーズは、本発明により対処される。
【００１５】
従来技術の分析の結果、本発明の発明者は、ＱｏＳパスの要求を処理する際にネットワーク上での計算負荷とストレージ要求を減少する必要性があることを発見した。
【００１６】
したがって、本発明において問題とその原因として従来技術のシステムの分析を行なったことにより、ＱｏＳパスの要求をより効率的に処理する必要性があることが見出された。
【００１７】
本発明以前においては、ＱｏＳパスの何らかの要求が受信されるのに先立ってパスのセットアップ手順の全部を完了することがＱｏＳを実現する究極的な方法であると考えられてきた。
【００１８】
本発明にあたり、プリセットパスのアプローチでは最初のホップノードがネットワーク内の全ての端末についてのプリセットパスを含むパステーブルを格納し管理する必要があり、これには非常に大きなテーブルの管理が必要になると言う問題があることが分った。テーブルの管理はＱｏＳパスの要求が増大するにしたがって非常に大規模になることが予想される。本発明における分析によると、宛先端末の最後のホップノードが変化した場合、その宛先端末に対するプリセットパスのテーブルを管理している全ての最初のホップノードが当該プリセットパスをこれに合わせて変更する必要があり、これがノードにおける負荷増大の原因の一つであることが示される。宛先端末の最後のホップノードが変化する度に全ての最初のホップノードのパステーブルを更新しなければならないので、端末の位置が頻繁に変化すると問題はさらに悪化する。本発明において問題を分析し、主な原因を決定してこの原因を排除し、さらに宛先端末に関係するＱｏＳの要求が存在した後でのみプリセットパスに対して最後のホップノードと宛先端末を関連付けることにより、このような確認された問題を解決するものである。
【００１９】
サブネットＩＰアドレスを用いて端末を集約することができるが、問題はこれでは解決しない。端末サブネットが小さなグループに分割されサブネットの個数が多くなると、テーブルは巨大になる。
【００２０】
本発明では、指定された宛先デバイスへのＱｏＳパスの特定の要求で開始されるＱｏＳパス選択のプロセスに応答して、当該宛先デバイス（サブネットのエッジノード、ＬＡＮ、ＷＡＮなど、または端末）からノードパスへの１つまたはそれ以上のプリセットノードへリンクすることにより問題を解決する。
【００２１】
【課題を解決するための手段】
実施形態ではプリセットパスを使用するが、最初のホップノードは各々の宛先デバイスについてのパステーブルを格納しない。その代わり、最初のホップノードは各々の最後のホップノードに対するプリセットパスを表わすパステーブルを格納する。ＱｏＳパス要求の送信元デバイス、例えば、サブネットのエッジノードや端末などは、希望するデータフローのフロー情報とパスを拡張すべき宛先端末とを表わす最初のホップノードへの要求信号を送信する。これに応答して、最初のホップノードは次のような特徴にしたがって指定されたパスにフローを割り当てる：
１）最初のホップノードでは各最後のホップノードを各々のパスにリンクするテーブル（ノードパステーブル）を格納する。
【００２２】
２）送信元及び宛先デバイスが最初のホップノード／最後のホップノードのＩＤを取得する。
【００２３】
３）ＱｏＳパス要求に応答して、宛先デバイスが最初のホップノードへ最後のホップノードＩＤを送信する。
【００２４】
４）宛先デバイス又は最初のホップノードで、特定の要求が最後のホップノードＩＤに関連付けられる。
【００２５】
５）最初のホップノードは最後のホップノードＩＤを使ってノードパステーブルからプリセットパスを抽出し要求状態を送信元デバイスに通知する。
【００２６】
本発明による上記の解決方法は後続のＱｏＳ要求を満たす従来技術のプリセットパスの利点の全部を提供することができ、しかも、ＱｏＳパスの急激に増大する使用を処理する際に生ずるネットワーク内の計算資源及びストレージ資源への従来技術で非常に大きかった要求に関連する従来技術での問題点を解消する。
【００２７】
【発明の実施の形態】
インタラクティブ・ビデオ通信や高画質ビデオ配信などの用途でＱｏＳを提供するのために、ネットワーク、例えば、図１のＷＡＮでの要求が多くなる。マルチプロトコル・ラベルスイッチング（ＭＰＬＳ）は、ＱｏＳを実現するようにネットワーク経由の専用パスを設定する。パケットスイッチング・ネットワークでは各パケットが宛先識別子を持っており、本明細書ではこれを宛先マシンＩＤと呼ぶことにする。ネットワークが大規模になるとＭＰＬＳパスも個数が増加する。
【００２８】
本発明の実施形態は、図２に示したように、オンデマンド・サービス品質（ＱｏＳ）保証サービスの一部として、ネットワーク・プリセットアップ・フェーズを使用する。ネットワーク・プリセットアップ・フェーズは、例えば、発明の背景で説明した従来技術に開示されているように従来技術によるものである。上記出願の基本的なパス設定技術は、特に本出願の図５及び図６に関連して以下で説明する。
【００２９】
ネットワークは、ノード（ゲートウェイ、端末、エッジノード、中間ノード、スイッチなど）がリンク（幹線、回線など）で結合されるインライン通信で、素材管理システム（ＭＭＳ、Material Management System）、ネットワーク管理システム（ＮＭＳ, Network Management System）や幹線管理システム（ＴＭＳ, Trunk Management System）を含むものである。ＴＭＳとＭＭＳは、ネットワーク内の「資源」を予約するように機能し、これによって、ネットワークのリンクが特定のデータ処理能力（例えば１００Ｍｂｐｓ）を持っていると識別される。次に、各リンクのデータ処理能力がノードに対して全体として又は部分として割り当てられ、それらのノードは、ノードのデータ処理能力に基づいてデータ通信及びネットワークへの参加を管理する。
【００３０】
ＴＭＳは図示していないが、図１のノードＡ１、Ａ、Ｂ、Ｃ、Ｄに含まれシステムバスによってメモリへ結合されたプロセッサを含む。メモリは各種テーブルを保持し、これにはＴＭＳ準備テーブル、ＴＭＳ幹線テーブル、ＴＭＳ幹線状態テーブル、ＴＭＳパステーブルが含まれる。テーブルは本発明を理解するのに必要な場合にのみ本明細書で詳細に開示しており、それ以外の従来のテーブルは、不必要に詳細になることにより本発明が不明瞭にならないようにするために、説明しないこととする。
【００３１】
エッジ又はゲートウェイ・ノードＡ１及びＡは、ネットワーク・プリセットアップ・フェーズを実装するために使用され、ノードのインテリジェンスを提供し従来のノード・プロセッサにより実行される制御プログラムをストレージに含む。そして、このプログラムは、ノードパステーブル、ノード幹線テーブル、ノードインタフェース状態テーブル、ノード幹線状態テーブルを含む多数のテーブルでＮＭＳから受信した情報を管理する。ノードインタフェーステーブルは、ノードに関連するアクセスネットワークなどのネットワーク・リンクへ接続するノードの別のインタフェースを識別する。
【００３２】
ネットワーク上の発信元マシンから宛先マシンへ送出されたメッセージ（パケット）には、ノードがネットワーク資源とネットワークを通るパスを割り当てるのに使用するヘッダ情報が提供される。
【００３３】
ネットワーク・プリセットアップ・フェーズ（期間）の間、所定の経路（パス）とあらかじめ設定されたリンク資源（例えば、バンド幅、クラスなど）がテーブル内でＮＭＳにより割り当てられる。従来と同様に、パスのエッジ及び内部ノードはキューイングとバッファリングを含み、これによりある種のＱｏＳクラスで転送レートの設定ができるようになる。ＮＭＳは、エッジノード（最初のホップノードと最後のホップノード）へ、また中継ノード（中間ノード）へ制御情報を送出してキュー制御を設定し、これによりリンクの資源を設定する。同様に、ＮＭＳから図２の最初のホップノード及び最後のホップノードへ送出された制御情報は、代表的にはノードが保持するルーティング情報を変更してこれにより特定のパスを割り当てる。
【００３４】
ＴＭＳルーティングテーブルは、ＮＭＳが初期化の間に準備しＴＭＳへ提供されるが、他のノードへ割り当てられたパスに関係する情報を含む。ＴＭＳルーティングテーブルの一例として、各パスについて、カラムには最初のホップノード、最後のホップノード、パスを形成するネットワークリンクがリストアップされる。ＴＭＳは各ノードに関係するＴＭＳパステーブルの部分をそのノードへ送信する。
【００３５】
ＮＭＳは、最初のホップノード、最後のホップノード、中間ノードを制御してこれらの出力のデータ通信特性を設定し実効的に通信クラスとして（この例ではもクラスＡ）パス又はリンクバンド幅を設定する。従来のディファレンシャル・サービス（ＤｉｆｆＳｅｒｖ）アーキテクチャを用いて、または他のＱｏＳ実装を用いて、出力キューとこれに関係するキュー制御回路は、ノードにパケットを分類、マークづけ、監査、体系化、順位付けさせるように設定する。これによりＮＭＳは、各方向に固有のリンクへ特定のバンド幅を割り当てる。このようなリンクは「暫定リンク」と呼ばれる。暫定テーブルはリンクが接続する二つのノードにより各暫定リンクを識別する。テーブル内で、各リンクには、例えば、バンド幅などの通信特性が割り当てられる。
【００３６】
ＴＭＳによる資源の分散により、各ノードにはプリセットパスが提供され、その各々は特定のバンド幅が用意されたネットワークリンクを含む。ノードパステーブルは各ノードが保持して暫定リンクの各々のバンド幅を含む。特定の方向でバンド幅を配分するには、ネットワーク・プリセットアップの間にＮＭＳとＴＭＳにより設定されたパスによって変化するが、各ノードの準備に３、３未満、４又は４方向以上の数個のリンクにバンド幅を分割することが必要になる。
【００３７】
資源をネットワークリンクに割り当てて、これらの資源をノードに配分した後、ＴＭＳは各ノードについてＴＭＳパス状態テーブルを作成して保持し、これには以下のカラムが含まれる。すなわち、当該ノードで管理される各パス、各パスの暫定リンク識別、各パスのバンド幅、各パスが使用されているか否か、そのパスで利用できる未使用バンド幅の量である。
【００３８】
ノードパス状態テーブルは、ノードの各々が保持しており基本的にＴＭＳパス状態テーブルと同じ情報を含むが、各々のノードだけについてである点で異なる。また、ＴＭＳにより資源を割り当てた際に暫定リンクになるネットワークリンクが識別される。
【００３９】
ノード幹線状態テーブルは、各ノードで処理される通信が変化するので連続的に変化する。ノードを通る通信が開始して停止すると、そのパスでテーブル内に格納されている「利用可能」と「使用中」の資源の量が、使用しているパスに合わせて変化する。さらに、パス状態情報はＴＭＳへ定期的に送出されてＴＭＳパス状態テーブルを変更し、様々なノードパスの状態も反映することができる。しかし、ＴＭＳパス状態テーブルの情報は、状態情報がＴＭＳへどの位速く又どの位の頻度で送信されるかに依存した量だけ、ノードパス状態テーブルのそれを遅延させる。例えば、ノードは自分自身のノード幹線状態テーブルを変更した直後にパス状態情報を送信することがあり、又はもっと少ない頻度で例えば所定の時間間隔の後などで状態情報を送信することもあり、又は他のキーイング・イベントによって情報を送信することもある。
【００４０】
各ノードは、ゲートウェイとして１つ以上のネットワークと接続することがあり、または、一つのネットワークに対して複数の接続を張ることもあり、その結果接続の各々についてインタフェースを有する。各ノードでノードフローパステーブルが作成されて保持され、各インタフェースの資源を識別する、すなわちバンド幅、使用中のバンド幅の量、未だ利用可能な未使用バンド幅の量である。この情報は、各ノードでノードパス状態テーブルにあるパスが保持される情報と同様である。
【００４１】
各ノードの割り当てられたバンド幅は、送信元マシンが要求しＱｏＳデータ転送を許可された場合に使用され、これによって図５に示したように転送が行なわれる長さのデータ通信パスを作成する。図５は図面のパスセットアップフェーズを実行する代表的な方法のフローチャートである。
【００４２】
図５、ステップ１５２：図２のパスセットアップフェーズの第一の通信として最初のホップノードへ接続されたデバイス又はネットワーク上の実体（すなわち、送信元マシン、これは図１と図２の送信元端末である）からＱｏＳパスの要求を最初のホップノードＡ１が受信する。要求は、パスの特性、例えば、バンド幅、クラスその他（フロー情報）についてのもので、宛先端末ＩＤと最後のホップノードＩＤを含む。
【００４３】
図５、ステップ１５６：最初のホップノードはノードフローパステーブルを検索して、ネットワークに接続して要求を承認するインタフェースで利用可能な資源があるかを判定する。資源がない場合、手順はステップ１５６からステップ１８４へ分岐し、ノードは要求元（送信元マシン）へ「拒絶」を返して手順を終了する。しかし、充分なインタフェース資源が利用できる場合には、手順はステップ１６０へ進む。
【００４４】
図５、ステップ１６０：最初のホップノードは要求を承諾するとの想定の元でインタフェース資源を予約し、ノードはフローパステーブルを検索して要求の宛先ＩＰアドレスに対応する宛先マシンへのプリセットパス又はパス群を検出する。プリセットパスが見つかれば、手順はステップ１６２へ進む。
【００４５】
図５、ステップ１６２：ノードはパスが要求の資源と一致する必要のある資源を有しているか判定する。多数のパスが利用できる場合、最初のホップノードは、全部のパスの資源を調べる。要求された資源を備えたパスが見つからない場合、手順はステップ１６４へ進む。要求された資源を備えたパスが見つかった場合、手順はステップ１７０へ進む。
【００４６】
図５、ステップ１６４：最初のホップノードはパス再設定手順（図６を参照してさらに完全には以下で説明する）を実行すべきか否か判定する。結果がイエスなら手順はステップ１８０に進みノーの結果なら手順はステップ１８４へ進み、ここで最初のホップノードは要求元へ「拒絶」を返して手順を終了する。パス再設定の決定は、初期化中又は資源状態に基づいて制限される（例えば、単位時間あたりで何らかの個数の要求だけを行なうように設定される）。
【００４７】
図５、ステップ１８０：パス再設定は、希望のパスの暫定リンクの１つまたはそれ以上にバンド幅を一時的に再割り当てする。
【００４８】
図５、ステップ１８２：ステップ１８０のパス再設定によって不十分な資源が復元される場合、手順はステップ１８４に進み、最初のホップノードは要求元（送信元端末）へ「拒絶」を返して手順を終了する。パス再設定処理が充分な資源を得られる場合、手順は後述のステップ１７０に進む。
【００４９】
図５、ステップ１７０：最初のホップノードが要求を許可して資源とパスを予約した後、最初のホップノードは最後のホップノードへ制御信号を送信し要求を最後のホップノードへ通知する。
【００５０】
図５、ステップ１７２：最後のホップノードは、これに関連する端末ポートテーブルを調べて通信を処理する資源を決定する。
【００５１】
図５、ステップ１７４：資源が充分でない場合、手順はステップ１８６へ進む。資源が充分な場合手順はステップ１７６へ進む。
【００５２】
図５、ステップ１８６：最後のホップノードは、送信元の第１のノードに拒絶を返し手順は前述のステップ１８４へ戻る。
【００５３】
図５、ステップ１７６：最後のホップノードは、必要な設定をセットアップして要求で指定された最初のホップノードからの信号で記載された（フローポートテーブルを作成する）ＱｏＳパスに準じたパケットをマークし転送し、さらに最初のホップノードへＡＣＫ（肯定応答）を返す。
【００５４】
図５、ステップ１７８：最初のホップノードは、要求で指定されたＱｏＳ条件にしたがって、パケットをマークし転送するための設定をセットアップして送信元端末にＡＣＫを返す。手順はこの後ステップ１９０で終了する。
【００５５】
その後、送信元端末は、図２のデータ転送フェーズにしたがって、パケットを送信し、通信を開始する。送信元端末が通信を終了するとき、「解放」メッセージを送出し（図２に図示していない）、これに影響を受けるノードは、適宜テーブルを変更する。
【００５６】
図５に図示した処理のステップ１８０でパス再設定の主要ステップが図６に示してある。要約すると、図６のパス再設定処理は要求に応じてＱｏＳパスを探している最初のホップノードのパスに少なくとも一時的に再割り当てすることが可能な余剰資源を特定するように機能する。すなわち、最初のホップノードによって管理されたプリセットパスのいずれにおいても充分な資源を持ったパスが見つからない場合、１つまたはそれ以上のパスの利用可能な資源を再割り当てすることでパスを見つけ出す試みがパス再設定により行なわれる。
【００５７】
図６、ステップ２０２：最初のホップノードはＴＭＳへ要求を送信し、これにはさらに多くの資源（例えばバンド幅）を必要とするリンクの識別と必要とされるバンド幅の量が含まれる。
【００５８】
図６、ステップ２０４：ＴＭＳはＴＭＳパス状態テーブルを検索して要求で識別されたパスと共通の暫定リンクを共有する別のリンク（他のノードが管理する）を探す。あるパスについて多数の共有リンクが存在する場合、パス再設定処理ではリンクの全てが候補となり、要求に対して不十分な資源を持っているパスは要求によりＴＭＳへ通知される。したがって、パス状態テーブルを用いてＴＭＳは、再設定要求で識別されたパスと同じように、同じ不十分な資源のリンクを共有するパスを特定しようとする。１つ以上のパスが見つかった場合、ＴＭＳはそのパスの利用可能な資源と要求の必要性に基づいてパスを選択する。
【００５９】
図６、ステップ２０６：パス資源有効性の肯定的決定（イエス）では手順がステップ２１０に進み、それ以外ではステップ２０８に進む。
【００６０】
図６、ステップ２０８：見つかったパスをいずれにしても使用すべきかを決定する。しない場合には、手順はステップ２１６に進む。前述したように、ＴＭＳパス状態テーブルの状態情報はノードによって維持されている状態情報を遅延させる。遅延量はノードがＴＭＳの状態更新情報を送信する頻度によって変化する。すなわち、ステップ２０８の決定はＴＭＳで利用可能な状態が不正確であり、特定のパスが必要とされる資源を本当に持っていると言う仮定で行なわれる。したがって、ステップ２１０の要求は、いずれにしても行なわれる。
【００６１】
図６、ステップ２１６：ＴＭＳは最初のホップノードへ「拒絶」メッセージを返して手順を終了する。
【００６２】
図６、ステップ２１０：ＴＭＳはパスの識別と必要とされるかあるいは希望するバンド幅の量で別のパスを管理するノードへ要求を送信する。
【００６３】
図６、ステップ２１２：別の幹線上の資源についての要求を受信したノードは、これに付属するテーブルを検索して、要求された別の幹線の状態を調べる。その別の経路には要求の条件に適合するには不十分な資源しか存在しないとノードが判定した場合、ノードがＴＭＳへ「拒絶」を送信した後で手順をステップ２１４へ進め、それ以外の場合手順はステップ２１８へ進む。
【００６４】
図６、ステップ２１４：ＴＭＳは再試行するかどうかを決定する。再試行する場合、手順はステップ２０４へ戻る。決定は少なくとも部分的にパスを共有するのが二つ又はそれ以上のノードであると言う事実に基づいている。一方のノードが管理するパスに充分な資源がない場合でも他方にはある場合がある。したがってステップ２１４はステップ２０４へ戻って必要とされる資源について別のパスを発見しようと試みる。
【００６５】
これ以外に、ステップ２１４でＴＭＳが使用する決定処理は、充分な資源のある別のパスを特定しようとする試行のプリセット回数又は他の何らかの要因に基づくことができる。
【００６６】
図６、ステップ２１８：別のパスを管理するノードが「承認」をＴＭＳへ送信し付属するテーブルを調節する（別の幹線で「バンド幅」と「利用可能」のカラムの両方で示された資源の量を減少させる。
【００６７】
図６、ステップ２２０：ＴＭＳはパス状態テーブルを変更して資源の再割り当てを反映させる。ＴＭＳは要求が認められた再設定要求を行なったノードに通知して、パス状態テーブルを変更させ再設定を適宜反映させる（すなわち資源の再割り当て）。
【００６８】
図６、ステップ２２２：追加の資源を探している最初のホップノードもテーブルを変更して、問題の幹線について追加の資源を反映する。
【００６９】
ＱｏＳパスの構築を使用する従来のネットワーク構成及びパケットスイッチング用アーキテクチャは代表的には「パス」と言う用語すなわちエンド間接続でネットワーク経由の資源を管理していた。上記の制御ではネットワーク内の資源を「リンク」単位で管理する。送信側ノードがパスを作成する場合、パスを作成できるかどうかはこれが管理しているリンク資源（幹線資源）情報に基づいて決定し追加の情報を他の実体に尋ねる必要はない。
【００７０】
ＮＭＳとＴＭＳは一つの要素に結合することができる。ゲートウェイ要素とこれに対応するエッジノードは単一の最初のホップノードとして統合することができ、これが前述したようなシグナリング、資源管理、承認制御などのゲートウェイ機能を有することになる。
【００７１】
図５と図６に関連して説明したように、ネットワーク経由の図２のパスセットアップフェーズはデータ転送のＱｏＳに特定の要求で開始する。最初のホップノードは要求のＱｏＳ要求に適合するのに資源が充分か否かをチェックする。資源が充分でない場合、追加の資源を他のノード割り当てから借り受けることができ、これは管理システムへの「再設定」要求により図２の従来のネットワーク・プリセットアップ・フェーズで行なった。充分な資源を再割り当てできた場合、送信元ノードは要求を許可でき、資源がない場合要求は拒否される。ネットワーク内で接続単位でネットワーク資源を予約し制御する必要性が排除される。
【００７２】
図１において、簡略化した広域ネットワーク（ＷＡＮ）例えばインターネットが図示してあるが、これは最初のホップノードＡ１と複数の最後のホップノードＡ、Ｂ、Ｃ、Ｄに対してだけである。中間ノード（図示していない）はネットワークの端に図示されたノード間の多数のパスに沿ってネットワーク内に存在する。送信元デバイス（図面の実施形態では送信元端末）は最初のホップノードに接続されるが、実際には例えば複数の送信元マシン、端末、サブネットのエッジノードが最初のホップノードＡ１のポートに接続される。各々の最後のホップノードは複数の宛先マシン（図面の実施形態では宛先端末）へ接続され、宛先マシンは、例えば、サブネットの端末やエッジノードであっても良い。
【００７３】
図１において、各最初のホップノードはコンピュータ・システムを使用するが、これの詳細は周知であり従来のものであることから図示していない。コンピュータ・システムはコンピュータで読み取り可能なコードのストレージを含み、これはフローパステーブル、ノードパステーブル、端末ポートテーブル、フローポートテーブルを本発明による実施形態として含めるように一部分模式的な形で図示してある。
【００７４】
図１は本発明の実施形態であるため図１には図示していないが、発明の背景で参照した従来技術はＩＰルーティングテーブルを備え、ＱｏＳの要求が行なわれる前にネットワークプリセットで作成される。従来技術のＩＰルーティングテーブルは一方のカラムにＩＰアドレス、例えば最初の３列で宛先端末Ｔ１，Ｔ２，Ｔ３のアドレス、また別のカラムでは、最初の３列でプリセットパスの識別例えばＰ１，Ｐ２，Ｐ３を含む。前述したように、このような従来技術のテーブルは巨大であり急激に大きくなるが、これはネットワークの個々のノードへ接続される全部の端末のためである。本発明ではプリセットパスへ接続される端末の識別を必要とせず、最後のホップノードの識別だけしか必要としない。
【００７５】
プリセットパスの従来技術は、ＱｏＳ要求の時点でのパスの従来のセットアップに対する改善である。本発明は、従来なら予想されない方法でプリセットパスの従来技術を改善するものであり、プリセットパスの宛先マシンリンクへの最後のホップの識別をその宛先マシンに関係するＱｏＳパスの特定の要求時にセットアップすることによる。ネットワーク上での計算負荷及びストレージ要求を減少する点で本発明の利点は大きい。以下の説明は実施形態のこの部分の実装として、より詳細に記述するものである。
【００７６】
図１において、各々の宛先デバイスはコンピュータ・システムを使用し（これの詳細は周知であり従来のものであることから図示していない）、コンピュータ・システムはコンピュータで読み取り可能なコードのストレージを含み、これは例えばフローポートテーブルなど実施形態のテーブルを含めるように一部分模式的な形で図示してある。当該テーブルは宛先マシンをこれに対応するネットワークノードＡ、Ｂ、Ｃ、又はＤの接続ポートに関連付ける。
【００７７】
図２に図示してあるように、本実施形態の処理には第１のフェーズがあり、これはネットワーク・プリセットアップ・フェーズである。最初のホップノードＡ１と１つまたは複数の最後のホップノード例えば図１の最後のホップノードＡ、Ｂ、Ｃ、Ｄがこれらの間でネットワークＷＡＮの介在ノードを含めた静的パス上で情報を交換し（介在ノードは、図２に図示してあり図１のネットワークでも含まれる）、プリセットパスを従来の方法で構築し、本発明によるセットアップでは宛先端末を含める必要がない点で異なっている。プリセットパスの構築時には、最初のホップノードは図１に図示したフローパステーブルとノードパステーブルを生成又は作成する。これらのテーブルは本発明でユニークなものだが、プリセットパスを構築するのに使用される方法は、例えば発明の背景で言及した従来技術に説明されているように、従来技術で周知のものであって、前記非特許文献１の中の広域ネットワークにおけるＭＰＬＳメソッドを含め、当該目的で本明細書に開示が含まれる。これによって多数のパスが最初のホップノードと最後のホップノードの間でセットアップされ、別の中間ノードを経由する別のパスが選択される。各プリセットパスは単方向又は双方向である。
【００７８】
図２の処理で次のフェーズは従来の端末ログオンに関係し、ここで宛先及び送信元マシン例えば端末が各々のノードＡ１、Ａ、Ｂ、Ｃ、Ｄに接続する。その結果宛先及び送信元デバイスは各々のノードＩＤを各々取得する。ノードの各々は、端末ポートテーブルを作成、更新、又は何らかの維持を行ない（ここでは最後のホップノードテーブルだけが本発明に関係する）、テーブルは各々のログオンしたデバイスと、結合されているエグレス／イングレス・ポートを関連付け又はリンクする。本発明で注目すべきこととしては、各々の宛先端末ＩＤが宛先端末の接続された最後のホップノードのエグレス・ポートにリンクされることである。このフェーズは、ネットワークへの端末ログオン時又は端末がロケーションを変更し別のノードへ接続したときに完了する。このフェーズで本発明でことなっているのは、本実施形態で、端末がログオンした又はノードの関係を変更したネットワークについて他のノードや制御に通知する必要がないことである。
【００７９】
図２に示した第３のフェーズはアプリケーションレベルの接続セットアップで、これはＱｏＳパスのオンデマンド要求に関連して本発明で完全に独自のものである。例えば、送信元と宛先マシンに常駐するアプリケーションは、ビデオ会議用である。従来の方法では送信元と宛先マシンが従来のＩＰルーティングを使用して、例えばＨ．３２３及びＳＩＰ標準を使用してアプリケーションレベルの接続を確立する。送信元デバイスは宛先デバイスが直接接続されるべきノードを識別するように要求する。これに応答して、宛先デバイスは最後のホップノード経由で送信元端末へ、従来のＩＰルーティングを使用して、すなわちプリセットパスなしで、最後のホップノードのＩＤと宛先端末ＩＤを含むメッセージを送信する。宛先端末ＩＤと最後のホップノードＩＤを送信元端末へ通知するあらゆる手段が使用でき、上記の方法は通信を確立する手段の単なる代表例にすぎない。
【００８０】
図２に図示した次のフェーズは、パスセットアップに関連するもので、これは図５及び図６に関連して詳細に前述した。送信元端末はＱｏＳパスの要求を、オンデマンドＱｏＳパスサービスの一部として、最初のホップノードへ送信する。要求には最後のホップノードのＩＤと希望する宛先デバイスの識別ＩＤ、例えば、各々ＡとＴ１が含まれる。このステップは、図１に図示していない。要求にはフロー特性例えば送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号などのフロー特性を指定するフロー情報も含まれる。
【００８１】
ノードパステーブルと最後のホップノードのＩＤを用いて最初のホップノードは要求を最適に満たし最後のホップノードへ接続するパスを決定する。最初のホップノードは、ノードパステーブル、選択パスから抽出した情報を使用して、プリセットパスへ各々のフローをリンクする図１のフローパステーブルを作成又は更新する。要求は最初のホップノードＡ１によって送信され、これは本実施形態において送信元デバイスがインターネットＷＡＮ上で宛先デバイスへ接続されるノードである。宛先端末のＩＤ、最後のホップノードのＩＤ、要求されたＱｏＳパスのフロー情報は送信元デバイスによって最初のホップノードへ送信される。従来のＩＰルーティング又は選択されたＱｏＳパスをこの通信に使用できる。
【００８２】
最後のホップノードは、これに応答して図１に図示したフローポートテーブルを作成し、このフローポートテーブルは、各フローＦ１、Ｆ２などを関連するエグレス・ポートＥ１、Ｅ２などへ関連付ける又はリンクする。
【００８３】
この後、最後のホップノードは処理において、これまでにその部分が更新を完了したことを表わす最初のホップノードへの肯定応答（ＡＣＫ）を送信する。ＡＣＫ受信時に、最初のホップノードは同様のＡＣＫを送信元デバイスへ送信する。
【００８４】
図２に図示した次のフェーズはデータ転送である。送信元デバイスは最初のホップノードへデータ送信、パケットフローを開始する。受信時に、最初のホップノードはパスセットアップフェーズで選択されたＱｏＳパスへ指定されたフローを割り当てる。これによって最初のホップノードと中間ノードは指定されたプリセットパスを要求されたＱｏＳに使用する最後のホップノードへパケットを転送する。最後のホップノードはフローをエグレス・ポートへリンクし、データ、パケットフローを指定された宛先デバイスへ送信するフローポートテーブルを参照する。
【００８５】
したがって、送信元端末（マシン又はデバイス）から宛先端末（マシン又はデバイス）へＷＡＮ経由でデータの転送を管理するため、最初のホップノードは、端末がログオンされるとデータベースの端末ポートテーブル（すなわち、フローポートテーブル）を更新して、最初のホップノードへ結合されたマシンについての状態情報を提供し、しかる後ログオンした各端末へこれのノードＩＤを渡す。
【００８６】
次に、最初のホップノードは、ＷＡＮ経由でサービス品質（ＱｏＳ）を保証したプリセットパスを確立し、ＷＡＮ経由のプリセットパス、パスのＱｏＳが依存するネットワーク資源、各ＱｏＳパスのＷＡＮ最後のホップノードの識別子の間の関連性を提供するためにデータベースのノードパステーブルを更新する。なお、このときに、パスの各宛先端末の識別を必要としない。
【００８７】
そして、最初のホップノードは、指定された送信元端末から指定された宛先端末へのオンデマンドＱｏＳ保証パスのアプリケーションレベル要求を受信して、要求において指定された宛先端末に対応付けられた最後のホップノードの識別についての問い合わせと応答をＷＡＮ上で送信することにより、従来のＩＰルーティングを使用するアプリケーションレベル接続を確立して、送信元端末と宛先端末で動作しているアプリケーションを支援する。（この支援は、要求で指定された宛先端末に対応付けられた最後のホップノードの識別に関して問い合わせる宛先端末へアプリケーションレベルの信号の送信する。また、応答が送信されるべき送信元端末から発信されたときに信号を識別する）。
【００８８】
次に、最初のホップノードは、要求で指定された宛先端末へ結合された最後のホップノードを識別しまた最後のホップノードと宛先端末のうちの一方から発信されたものとして信号を識別する（後者の場合が実施形態である）。
【００８９】
次に、最初のホップノードは、宛先マシンへ結合された最後のホップノードの識別を送信元端末から受信する。
【００９０】
次に、最初のホップノードは、データベースのフローパステーブルを作成し最後のホップノードへ情報を送信してこれのデータベースのフローポートテーブルを作成し、完了時に送信元端末へ完了を肯定応答する。
【００９１】
次に、最初のホップノードは、フローパステーブルの作成の一部として、ノードパスデータベースが検索されＱｏＳパスが宛先マシンに対応付けられた最後のホップノードの要求及び識別子の両方に基づいて抽出される。
【００９２】
その後、次に、最初のホップノードは、要求にしたがって宛先端末へ送信元端末のためのパケットを転送する。
【００９３】
「最後のホップノード」Ａ、Ｂ、Ｃ、Ｄは、全て通信で最初のホップノードとして機能し、「最初のホップノード」Ａ１は最後のホップノードとして機能する。すなわち、ＱｏＳのオンデマンド要求をどの端末が行なうかに依存しており、それらのノードは、逆の役割のプログラムとテーブルを有することを意味する。
【００９４】
本発明の更なる実施形態として、最初のホップノード端末が、上記の例の宛先端末と送信元端末によって実行されるアプリケーションレベルの作業の幾つかを肩代りすることもできる。本発明は、例えば、ネットワークがＩＰルータを含むネットワーク・サービスで使用可能である。本発明は、他のネットワーク、例えば、プリセットパスを有することがあるＡＴＭ（非同期転送モード）ネットワークで使用可能である。
【００９５】
本発明は多数の実施形態及び実装との関連で説明したが、これらにより本発明が限定されるものではなく添付の請求項の範囲に納まる各種の明白な変更及び等価な構成を包含する。
【００９６】
本発明の態様、特徴、利点は、本発明を実現する上で発明者が意図した最良の態様である特定の実施形態及び実装を、変更及び変化を含めて簡略に図示することで、以上の詳細な説明から容易に明らかになった。本発明はその他の及び別の実施形態も可能であり幾つかの詳細は本明細書の教示にしたがえば各種の明白な態様で、全てが本発明の趣旨と範囲から逸脱することなく変更が可能である。したがって図面及び説明は本質的に図示を目的としたものであって制限ではないと考えるべきである。
【００９７】
【発明の効果】
本発明によれば、最初のホップノードは宛先端末へプリセットパスをリンクする情報を格納また管理する必要がない。実施形態において最初のホップノードは、最初のホップノードへプリセットパスをリンクする情報を管理し、要求が行なわれ予備的なプリセットパスが選択されるまで宛先端末へのリンクを要求しない。端末数は最後のホップノードの個数の逓倍数であるから、これは要求されるテーブルサイズを大幅に減少させ、その上、最初のホップノードでのストレージ要求とデータベース管理処理負荷を大幅に減少させる。ここで、最初のホップノードは、理論的に例えばネットワークのエッジノードの全部とＷＡＮのゲートウェイ・ノードの全部である。
【００９８】
また、宛先端末がロケーションを変更して別の最初のホップノードへ接続する場合には、最初のホップノードのパステーブルは再設定される必要がない。これは端末のロケーションが頻繁に変化する場合、また、ポータブル又は移動体端末の使用が増加して、最後のホップノードは、将来的にさらに頻繁に変化する場合に、最初のホップノードの計算負荷を大幅に減少させる。
【図面の簡単な説明】
【図１】ネットワークとくにＷＡＮと、当該ネットワークに接続される端末の略図で、本発明の実施形態によりオンデマンドで割り当てられるＱｏＳパスのテーブルの例は最初のホップノードと最後のホップノードに格納される。
【図２】図１のＷＡＮのノードすなわち図１の送信元端末と図１の宛先端末で送受信される信号のチャートで、上から下へ向かって本発明の実施形態を実装する際の信号の代表的順序を示す。
【図３】最初のホップノードテーブルの例で、エッジノードで記憶媒体に存在し図１の最初のホップノードとして動作するエッジノードで使用され、本発明の実施形態を実装するための代表的データを示す。
【図４】図４は、端末ポートテーブルの例で、エッジノードで記憶媒体に存在し図１の最後のホップノードとして動作するエッジノードで使用され、本発明の実施形態を実装するための代表的データを示す。
【図５】図２に開示した本発明のネットワーク・プリセットアップ・フェーズで動作し、ネットワーク内の最初のホップノード又は後続のホップノードで行なわれてネットワーク内でＱｏＳパスをセットアップするためのステップを示すフロー図である。
【図６】ＱｏＳパス要求に対応する容量を備えたネットワーク経由のパスを取得しようとする際のパス再設定に関して、図５のステップ１８０をさらに詳細に示すフロー図である。
Claims (8)
- 広域ネットワーク（ＷＡＮ）のホップノードによって実行され、前記ＷＡＮ経由で送信元マシンから宛先マシンへのサービス品質（ＱｏＳ）保証プリセットパスのデータ送信を管理するための方法であって、各ステップが前記ＱｏＳ保証プリセットパスの最初のホップノードで実行される方法であり、
前記方法は、
前記ＷＡＮを経由するＱｏＳ保証プリセットパスと各ＱｏＳ保証プリセットパスの最後のホップノードの識別子とのリンクを提供するノードパスデータベースを記憶するステップと、
その後に、前記宛先マシンに対応付けられた前記最後のホップノードの識別子を含むメッセージを受信するステップと、
その後に、前記宛先マシンへリンクされたＱｏＳ保証プリセットパスについて前記ノードパスデータベースを検索し、前記宛先マシンに対応付けられた前記最後のホップノードの前記識別子に基づいてＱｏＳ保証プリセットパスを選択し抽出するステップと、
その後に、前記ＱｏＳ保証プリセットパス特定の状況に関して前記送信元マシンへ通知するステップと
を含むことを特徴とする方法。 - 前記受信するステップは、前記送信元マシンから発信されるものとして識別されるアプリケーションレベルの信号として前記メッセージを受信することを特徴とする請求項１に記載の方法。
- さらに、前記受信するステップの前に、前記要求の宛先マシンに対応付けられた前記最後のホップノードを識別し、前記最後のホップノードと前記宛先マシンの一方から送信されるものとして前記信号を識別するアプリケーションレベル信号を前記送信元マシンへ送信するステップ
を含むことを特徴とする請求項２に記載の方法。 - さらに、前記送信の前に、前記要求の宛先マシンに対応付けられた前記最後のホップノードの識別に関して問い合わせ、前記送信元マシンから発信されるものとして前記信号を識別するアプリケーションレベル信号を前記宛先マシンへ送信するステップ
を含むことを特徴とする請求項３に記載の方法。 - さらに、前記選択された保証プリセットパス上で、前記送信元マシンから前記宛先マシンへデータを転送するステップ
を含むことを特徴とする請求項１に記載の方法。 - 前記ノードパスデータベースを管理するステップは、各々のＱｏＳ保証プリセットパスについて前記パスのＱｏＳが依存するネットワーク資源についての情報を提供する
ことを特徴とする請求項１に記載の方法。 - 前記受信するステップの前に、前記宛先マシンに対応付けられた前記最後のホップノードの識別子を要求する問い合わせを、前記ＷＡＮ上で前記宛先マシンへあてて送信するステップ
をさらに含むことを特徴とする請求項１に記載の方法。 - 広域ネットワーク（ＷＡＮ）の最初のホップノードに対応付けられた送信元マシンによってマシン上で実行され、前記ＷＡＮ経由で前記送信元マシンから宛先マシンへオンデマンド・サービス品質（ＱｏＳ）保証プリセットパスのデータ送信によって最適化されたアプリケーションを実行する方法であって、
前記方法は、
アプリケーションレベルで、前記宛先マシンに対応付けられた最後のホップノードの識別子を前記宛先マシンに要求して受信するステップと、
ＱｏＳ保証プリセットパスの要求と、前記宛先マシンの識別子と、前記宛先マシンに対応付けられた前記最後のホップノードの識別子とを含む前記最初のホップノードへのメッセージを送信するステップと、
その後に、要求されたＱｏＳ保証プリセットパスの確立の肯定応答を受信するステップと、
前記肯定応答に応答して、前記ＱｏＳ保証プリセットパスへのリンクとともに前記最初のホップノードへ前記データを送信するステップ
を含むことを特徴とする方法。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/192,971 US7215640B2 (en) | 2002-07-11 | 2002-07-11 | Method and apparatus for path configuration in networks |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004048661A JP2004048661A (ja) | 2004-02-12 |
| JP2004048661A5 JP2004048661A5 (ja) | 2006-03-23 |
| JP4213972B2 true JP4213972B2 (ja) | 2009-01-28 |
Family
ID=30114440
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003069735A Expired - Fee Related JP4213972B2 (ja) | 2002-07-11 | 2003-03-14 | ネットワークのパス構成のための方法および装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7215640B2 (ja) |
| JP (1) | JP4213972B2 (ja) |
Families Citing this family (43)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2290731A1 (en) * | 1999-11-26 | 2001-05-26 | D. Jed Harrison | Apparatus and method for trapping bead based reagents within microfluidic analysis system |
| US6432290B1 (en) | 1999-11-26 | 2002-08-13 | The Governors Of The University Of Alberta | Apparatus and method for trapping bead based reagents within microfluidic analysis systems |
| US20030108664A1 (en) * | 2001-10-05 | 2003-06-12 | Kodas Toivo T. | Methods and compositions for the formation of recessed electrical features on a substrate |
| CA2474644A1 (fr) | 2002-02-21 | 2003-09-25 | Alcatel | Procede pour determiner une route spectrale pour une connexion donne dans un reseau de telecommunication optique, et noeud pour la mise en oeuvre de ce procede |
| CN1639234A (zh) * | 2002-02-28 | 2005-07-13 | 陶氏环球技术公司 | 适用于食品包装的膜 |
| US20030217923A1 (en) * | 2002-05-24 | 2003-11-27 | Harrison D. Jed | Apparatus and method for trapping bead based reagents within microfluidic analysis systems |
| US20030233456A1 (en) * | 2002-06-14 | 2003-12-18 | Nortel Networks Limited | Communication between call controllers by amending call processing messages |
| US20040008688A1 (en) * | 2002-07-11 | 2004-01-15 | Hitachi, Ltd. | Business method and apparatus for path configuration in networks |
| WO2004061085A2 (en) * | 2002-12-30 | 2004-07-22 | The Regents Of The University Of California | Methods and apparatus for pathogen detection and analysis |
| CN1283079C (zh) * | 2003-02-20 | 2006-11-01 | 华为技术有限公司 | Ip网络业务质量保证方法及系统 |
| US7876757B2 (en) * | 2003-11-06 | 2011-01-25 | International Business Machines Corporation | Router-assisted fast processing of packet termination in host |
| CN100454887C (zh) * | 2003-11-24 | 2009-01-21 | 中兴通讯股份有限公司 | 在MPLS网络中实现QoS保证的方法、装置和系统 |
| FR2864394B1 (fr) * | 2003-12-19 | 2006-03-03 | Cit Alcatel | Procede d'etablissement d'une connexion logique entre un noeud de depart et un noeud d'arrivee non adjacents d'un reseau de telecommunications |
| US20050198362A1 (en) * | 2003-12-31 | 2005-09-08 | Navada Muraleedhara H. | Exception packet forwarding |
| US7406091B2 (en) * | 2004-01-12 | 2008-07-29 | Hewlett-Packard Development Company, L.P. | Distribution of communications between paths |
| US9160571B2 (en) * | 2004-03-11 | 2015-10-13 | Hewlett-Packard Development Company, L.P. | Requesting a service from a multicast network |
| US20050213557A1 (en) * | 2004-03-26 | 2005-09-29 | Cherng-Daw Hwang | Multimedia communication and collaboration system and protocols |
| JP4334424B2 (ja) * | 2004-07-09 | 2009-09-30 | 富士通株式会社 | ネットワークのリソース，サービス発見方法及び中継ノード装置 |
| EP1794581A2 (en) * | 2004-09-15 | 2007-06-13 | Microchip Biotechnologies, Inc. | Microfluidic devices |
| DE102004063461B4 (de) * | 2004-12-23 | 2008-06-26 | Nec Europe Ltd. | Verfahren zum Suchen von Diensten, Ressourcen und/oder Funktionalitäten in einem Netzwerk |
| US7974202B2 (en) | 2005-05-06 | 2011-07-05 | Corrigent Systems, Ltd. | Tunnel provisioning with link aggregation |
| JP4585944B2 (ja) * | 2005-08-31 | 2010-11-24 | 株式会社日立製作所 | パケット通信装置 |
| US20070101018A1 (en) * | 2005-11-01 | 2007-05-03 | Meral Shirazipour | Inter-domain QoS reservation establishment and modification |
| CN100420237C (zh) * | 2005-11-18 | 2008-09-17 | 华为技术有限公司 | 在路由器上对实时业务进行控制的方法 |
| FI119166B (fi) * | 2005-11-30 | 2008-08-15 | Tellabs Oy | Menetelmä ja laitteisto palvelunlaatuluokasta riippuvan reitityspäätöksen muodostamiseksi |
| US7463580B2 (en) * | 2005-12-15 | 2008-12-09 | Corrigent Systems, Ltd. | Resource sharing among network tunnels |
| US7870263B2 (en) * | 2005-12-27 | 2011-01-11 | At&T Intellectual Property I, L.P. | Carrier interoperability for critical services |
| US8072879B2 (en) | 2006-02-03 | 2011-12-06 | Cisco Technology, Inc. | Technique for determining whether to reestablish fast rerouted primary tunnels based on backup tunnel path quality feedback |
| US8741230B2 (en) * | 2006-03-24 | 2014-06-03 | Theranos, Inc. | Systems and methods of sample processing and fluid control in a fluidic system |
| US7545740B2 (en) * | 2006-04-07 | 2009-06-09 | Corrigent Systems Ltd. | Two-way link aggregation |
| US7626930B2 (en) * | 2006-11-13 | 2009-12-01 | Corrigent Systems Ltd. | Hash-based multi-homing |
| US7697525B2 (en) * | 2006-12-21 | 2010-04-13 | Corrigent Systems Ltd. | Forwarding multicast traffic over link aggregation ports |
| WO2008115626A2 (en) * | 2007-02-05 | 2008-09-25 | Microchip Biotechnologies, Inc. | Microfluidic and nanofluidic devices, systems, and applications |
| KR20100112140A (ko) | 2008-01-22 | 2010-10-18 | 톰슨 라이센싱 | 패킷 스위칭 네트워크에 대한 자원들이 예약을 돕는 방법, 연관된 관리 디바이스, 및 보조 디바이스 |
| WO2009108260A2 (en) * | 2008-01-22 | 2009-09-03 | Microchip Biotechnologies, Inc. | Universal sample preparation system and use in an integrated analysis system |
| US8549124B2 (en) * | 2009-05-27 | 2013-10-01 | International Business Machines Corporation | Network management discovery tool |
| WO2012024658A2 (en) | 2010-08-20 | 2012-02-23 | IntegenX, Inc. | Integrated analysis system |
| US8805382B2 (en) * | 2012-07-23 | 2014-08-12 | At&T Intellectual Property I, L.P. | System and method for quality of service in a wireless network environment |
| JP2014103514A (ja) * | 2012-11-19 | 2014-06-05 | Toshiba Corp | 通信装置、通信システムおよびプログラム |
| US9172604B1 (en) | 2013-02-25 | 2015-10-27 | Google Inc. | Target mapping and implementation of abstract device model |
| US9166912B2 (en) | 2013-02-25 | 2015-10-20 | Google Inc. | Translating network forwarding plane models into target implementation using sub models and hints |
| CN104243302B (zh) * | 2013-06-20 | 2018-03-16 | 华为技术有限公司 | 业务路由报文处理方法、装置及网络系统 |
| JP2016079529A (ja) * | 2014-10-17 | 2016-05-16 | 花王株式会社 | 不織布 |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5115495A (en) * | 1988-10-18 | 1992-05-19 | The Mitre Corporation | Communications network system using full-juncture and partial-juncture station status information for alternate-path distance-vector routing |
| US5233604A (en) * | 1992-04-28 | 1993-08-03 | International Business Machines Corporation | Methods and apparatus for optimum path selection in packet transmission networks |
| US5435003A (en) * | 1993-10-07 | 1995-07-18 | British Telecommunications Public Limited Company | Restoration in communications networks |
| JP3599364B2 (ja) * | 1993-12-15 | 2004-12-08 | 富士通株式会社 | ネットワーク装置 |
| US5613069A (en) * | 1994-12-16 | 1997-03-18 | Tony Walker | Non-blocking packet switching network with dynamic routing codes having incoming packets diverted and temporarily stored in processor inputs when network ouput is not available |
| US5563878A (en) * | 1995-01-05 | 1996-10-08 | International Business Machines Corporation | Transaction message routing in digital communication networks |
| US5751971A (en) * | 1995-07-12 | 1998-05-12 | Cabletron Systems, Inc. | Internet protocol (IP) work group routing |
| US5721820A (en) * | 1995-09-11 | 1998-02-24 | International Business Machines Corporation | System for adaptively routing data in switching network wherein source node generates routing message identifying one or more routes form switch selects |
| JP2723097B2 (ja) * | 1995-12-04 | 1998-03-09 | 日本電気株式会社 | Ｑｏｓルーティング装置 |
| US6400681B1 (en) * | 1996-06-20 | 2002-06-04 | Cisco Technology, Inc. | Method and system for minimizing the connection set up time in high speed packet switching networks |
| US6275492B1 (en) * | 1996-12-03 | 2001-08-14 | Nortel Networks Limited | Method and apparatus for routing data using router identification information |
| US6130892A (en) * | 1997-03-12 | 2000-10-10 | Nomadix, Inc. | Nomadic translator or router |
| US6266706B1 (en) * | 1997-09-15 | 2001-07-24 | Effnet Group Ab | Fast routing lookup system using complete prefix tree, bit vector, and pointers in a routing table for determining where to route IP datagrams |
| US6256295B1 (en) * | 1997-09-25 | 2001-07-03 | Nortel Networks Limited | Method and apparatus for determining multiple minimally-overlapping paths between nodes in a network |
| JP3782229B2 (ja) * | 1998-03-13 | 2006-06-07 | 富士通株式会社 | パス情報構築方法 |
| US6141783A (en) * | 1998-04-10 | 2000-10-31 | International Business Machines Corporation | Error propagation limiting encoder/decoder for multilevel decision feedback equalization |
| US6141738A (en) | 1998-07-08 | 2000-10-31 | Nortel Networks Corporation | Address translation method and system having a forwarding table data structure |
| US6594265B1 (en) * | 1998-11-10 | 2003-07-15 | International Business Machines Corporation | Method and system in an asynchronous transfer mode (ATM) network for providing an available bit rate interface to a continuous bit rate virtual path connection with adjustable bandwidth |
| US7320034B2 (en) * | 2000-03-20 | 2008-01-15 | International Business Machines Corporation | System and method for reserving a virtual connection in an IP network |
-
2002
- 2002-07-11 US US10/192,971 patent/US7215640B2/en not_active Expired - Fee Related
-
2003
- 2003-03-14 JP JP2003069735A patent/JP4213972B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7215640B2 (en) | 2007-05-08 |
| US20040008687A1 (en) | 2004-01-15 |
| JP2004048661A (ja) | 2004-02-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4213972B2 (ja) | ネットワークのパス構成のための方法および装置 | |
| US7477657B1 (en) | Aggregating end-to-end QoS signaled packet flows through label switched paths | |
| US9413546B2 (en) | QOS provisioning in a network having dynamic link states | |
| AU2003264320B2 (en) | The system and method for realizing the resource distribution in the communication network | |
| EP1921813B1 (en) | Method and apparatus for providing guaranteed quality/class of service within and across networks using existing reservation protocols and frame formats | |
| US6594268B1 (en) | Adaptive routing system and method for QOS packet networks | |
| JP4476292B2 (ja) | リアルタイムサービスデータ伝送路の選択方法 | |
| US7327681B2 (en) | Admission control method in internet differentiated service network | |
| US20040008688A1 (en) | Business method and apparatus for path configuration in networks | |
| US20020103924A1 (en) | Method for allocating network aggregation bandwidth and a network system using the same | |
| CN100454887C (zh) | 在MPLS网络中实现QoS保证的方法、装置和系统 | |
| JPH09270793A (ja) | 通信制御方法 | |
| US7457239B2 (en) | Method and apparatus for providing a quality of service path through networks | |
| EP4184937A1 (en) | Method, apparatus, and system for communication in data centre | |
| JP2000312226A (ja) | 通信品質を保証する方法 | |
| US20150100694A1 (en) | Use of iterative learning for resolving scalability issues of bandwidth broker | |
| US7787469B2 (en) | System and method for provisioning a quality of service within a switch fabric | |
| US7296087B1 (en) | Dynamic allocation of shared network resources between connection-oriented and connectionless traffic | |
| JP2001156779A (ja) | 通信システム間のサービスの品質をマッピングするシステムと方法 | |
| JP4014889B2 (ja) | ネットワーク管理装置 | |
| KR100411249B1 (ko) | 다중프로토콜 레이블스위칭 망에서 경계 게이트웨이프로토콜 테이블 정보를 이용한 레이블 할당방법 | |
| KR20010019613A (ko) | 라우터에서 데이터 전송 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060202 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060202 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20060202 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080130 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080617 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080808 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20081007 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081031 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111107 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111107 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121107 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121107 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131107 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |