JP2001522199A - パケットネットワーク - Google Patents

パケットネットワーク

Info

Publication number
JP2001522199A
JP2001522199A JP2000519535A JP2000519535A JP2001522199A JP 2001522199 A JP2001522199 A JP 2001522199A JP 2000519535 A JP2000519535 A JP 2000519535A JP 2000519535 A JP2000519535 A JP 2000519535A JP 2001522199 A JP2001522199 A JP 2001522199A
Authority
JP
Japan
Prior art keywords
packet
parameters
reservation
node
route
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.)
Granted
Application number
JP2000519535A
Other languages
English (en)
Other versions
JP4399109B2 (ja
Inventor
ホジキンソン、テレンス・ジョフレイ
カーター、サイモン・フランシス
オニール、アラン・ウイリアム
ホワイト、ポール・パトリック
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Publication of JP2001522199A publication Critical patent/JP2001522199A/ja
Application granted granted Critical
Publication of JP4399109B2 publication Critical patent/JP4399109B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

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/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/26—Route discovery packet
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

(57)【要約】 インターネットにおいて資源を予約する方法を開示する。この方法は、大きい共有ツリーマルチキャスト環境に関係して使用すると、インターネット内のルータ（Ａ−Ｅ、Ｒ１−Ｒ６）内の経路状態が低減した改良されたプロセスを提供する。この方法は上流において受信者（Ｈ１−Ｈ７）から送信者（Ｈ１−Ｈ７）へ経路の特徴を送ること、およびその両者間にルータを含み、ルータは下流において異なる源からの経路の特徴を結合することを含む。次に結合された経路の特徴を表わすデータ、送信者のトラヒックの性質、および送信者によって要求される二端点間のサービス品質に基づいて予約を行なう。

Description

【発明の詳細な説明】
【０００１】 発明の属する技術分野 本発明はパケットネットワークにおいて資源を受取る方法に関する。本発明は
とくに、サービス品質保証を提供するインターネットを用意することに関係して
利用される。
【０００２】 従来の技術 インターネットにおいて資源を予約する方法はよく知られている。現在インタ
ーネットにおいて最もよく支援（サポート）されている方法は、資源予約プロト
コル（ＲＳＶＰ）(Resource Reservation Protocol)によって規定されている。
【０００３】 例えば電話による会話またはテレビ会議がインターネット上で実行されるとし
て要求されることは、インターネットが実時間通信を提供できることが望まれて
いる。これに関係して、提供できる２つのサービス品質は、次のドキュメント（
本明細書において参考文献として取り上げられる）によって特定されている： （１）S.Schenker, C.Partridge, R.Guerin. Specification of Guaranteed Qua
lity of Service, Request For Comments, September 1997, RFC 2212; （２）J.Wroclawski. Specification of the Controlled-Load Network Element
Service, Request For Comments, September 1997, RFC 2211。
【０００４】 本質的に、第１のドキュメントにおいて規定される保証サービスでは、ユーザ
のメッセージが受取り者に到達するのにかかる時間における上界を特定でき、制
御されるロードサービス（２）は、サービスが軽くロードされる(lightly loade
d)ときのみ、インターネットによって与えられるのと品質上類似したサービスを
提供する。ＲＳＶＰプロトコルにしたがってインターネットを動作すると、実時
間通信を行なうことができる。ＲＳＶＰプロトコルにしたがってインターネット
を動作するときの上述のサービス品質クラスへの通信の準備は次の文献に記載さ
れている（同様に本明細書において参考文献として取り上げる）： （３）P.White. RSVP and Integrated Services in the Internet:a tutorial,
IEEE Communications magazine, May 1997。
【０００５】 ＲＳＶＰプロトコルにしたがって動作するインターネットワークにおいて、送
信者がトラヒックレベルを高めたいとき、1以上の受信者へ最初に経路情報パケ ットを送り、移動した経路の特徴に関する情報および増加したトラヒックレベル
を特定する情報を与える。この経路情報パケットが各ノードを通って進み、これ
により送信者からの増加したトラヒックが1以上の受信者へ送られることになる 。経路特徴データは、パケットがノードを通った結果としてノードにインストー
ルされる。このプロセスが完了すると、1以上の受信者は増加したトラヒックの 規格および二端点間の経路の特徴（受取った経路情報パケットから得られる）に
基づいて要求された予約を計算し、要求された予約を特定するパケットを送信者
へ送り返す。十分なネットワーク資源が使用可能なとき、予約要求パケットを受
取る各ノードは適切な資源を予約し、パケットを送信者へ送り返す。
【０００６】 インターネットがＲＳＶＰにしたがって動作するとき、受信者は資源の予約を
要求する責務を負う。対照的に、インターネットストリームプロトコルバージョ
ン２（ＳＴ２）にしたがって動作するインターネットでは、送信者が資源の予約
を要求する責務を負う。
【０００７】 ＳＴ２にしたがって動作するネットワークは、ＲＳＶＰで可能であったよりも
迅速に資源を予約することができるが、一対多または多対一の通信において異な
るサービスレベルを提供することはできない。
【０００８】 発明が解決しようとする課題 本発明の態様にしたがって、複数のホストおよび1以上の相互接続ノードを含 むパケットネットワークにおいて資源を予約する方法であって： 複数の受信ホストを動作して、1以上の予約に影響を与えるパラメータを含む 逆方向にルート設定されたパケットを、ルートに沿って1以上の前記相互接続ノ ードを経由して1以上の送信ホストへ送る段階と； 前記１以上の中間ノードが、 異なる受信者から受取った逆にルート設定されたパケットの1以上のパラ メータを結合して、結合された予約に影響を与えるパラメータを生成して、 前記結合されたパラメータを記憶して、 前記結合されたパラメータを含む逆方向にルート設定されたパケットをさ
らに前記ルートに沿って1以上の送信ホストへ送るように動作する段階と； 前記送信ホストを動作して、資源予約パケットを前記ルートに沿って1以上 の受信者へ送り返す段階と； 前記１以上の中間ノードを動作して、前記予約パケットに応答して、該ノー
ドに記憶された予約に影響を与えるパラメータにしたがって資源を予約する段階
とを含む方法を提供する。
【０００９】 中間ノードは受信者によって送られた予約に影響を与えるデータを検査し、そ
れにしたがって資源を予約するので、本発明では資源の予約を受信者の要件に一
層よく合わせることができる。さらに本発明では、送信者が始めた資源予約プロ
トコルと関係するより迅速な資源予約を犠牲にせずにこれを達成する。
【００１０】 さらに、このやり方で経路の特徴（特性データ）を結合することによって、ネ
ットワーク内のノード間で送られる経路の特徴を表わすデータ量は、送信者が多
くの受信者にトラヒックを送るとき（すなわち送信者がマルチキャスティングす
るとき）に低減する。
【００１１】 いくつかの実施形態では、前記１以上の予約に影響を与えるパラメータは所望
のサービス品質クラスの指標を含み、前記１または複数の中間ノードは： 前記パラメータを更新して、下流の受信者によって要求される最高のサービ
ス品質クラスを表示し； 前記最高のサービス品質クラスと関係する資源予約プロセスにしたがって資
源を予約するように動作する。
【００１２】 このやり方では、１対多または多対多の通信において異なるサービス品質クラ
スを支援することができる。例えば、一部の受信者は上述の保証されたサービス
にしたがってサービス品質を要求でき、一方で他の受信者は上述の制御されたロ
ード規格のみにしたがってサービス品質を要求することができる。したがってよ
り融通の利くサービスを提供することができる。
【００１３】 ある種の実施形態では、予約パケットは１以上の送信者によって出力されるト
ラヒックの性質を示す情報を保持し、ノードは予約される資源を計算するときに
その情報を検討する。アプリケーションにおいて、送信者からのトラヒックが所
定の特徴をもつとき、これは本質的ではなくなる。
【００１４】 好ましい実施形態では、ホスト間のルート設定は共有のツリープロトコルにし
たがう。したがって複数の送信者がいる状況では、ノードに記憶される必要があ
る予約に影響を与えるデータ量を低減する。
【００１５】 これはとくに多数の送信者を含む通信に対して効果的である。多数の人を含む
テレビまたはオーディオ会議では、多数の送信者が存在していてもよい。マルチ
プレーヤゲームまたは分散形対話シミュレーションでは、はるかにより多数の送
信者が可能である。これらは潜在的には、メッセージを送受信する何千ものホス
トを含む。
【００１６】 本発明の第２の態様にしたがって、パケットネットワークであって： 受信された逆方向にルート設定されたパケットの１以上のパラメータを結合
して、結合された予約に影響を与えるパラメータを生成する手段と； 前記結合されたパラメータを記憶する手段と； さらに前記ルートに沿って前記結合されたパラメータを含む逆にルート設定
されたパケットを前記送信ホストへ送る手段と； 予約パケットに応答するノードに記憶された結合された予約に影響を与える
パラメータにしたがって資源を予約する手段とを含むパケットネットワークノー
ドを提供する。
【００１７】 ここで、本発明の特定の実施形態を例示的に添付の図面を参照して記載するこ
とにする。
【００１８】 発明の実施の形態 図１には7つの構成要素（Ｈ１ないしＨ７）が示されており、各構成要素はロ ーカルエリアネットワーク（Ｌ１ないしＬ６）に接続され、さらにローカルエリ
アネットワークはゲートウエイルータ（Ｒ１ないしＲ６）を含む。コンピュータ
Ｈ５、Ｈ６の２つは単一のローカルエリアネットワーク（ＬＡＮ）に接続され、
他の５つのコンピュータは各ＬＡＮに接続されている。ゲートウエイルータ（Ｒ
１ないしＲ７）はネットワークによって相互接続されており、該ネットワークは
、中間のルータ（ＡないしＥ）によって1以上の他のサブネットによって接続さ れた多数のサブネット（Ｓ１ないしＳ６）を含む。
【００１９】 第１のサブネットＳ１は3つのゲートウエイルータ（Ｒ１ないしＲ３）を第１ の中間のルータＡへ接続して、代わって第１の中間のルータは第２のサブネット
Ｓ２を介して第２の中間のルータＢへ接続されている。第３のサブネットＳ３は
第２の中間のルータを第３および第４の中間のルータＣ、Ｄへ接続する。第３の
中間のルータＣは第４のサブネットＳ４を介して第４のゲートウエイルータＲ４
へ接続される。第５のサブネットＳ５は第４の中間のルータＤを両方の第５の中
間ルータＥおよび第５のゲートウエイルータＲ５へ接続する。第５の中間のルー
タＥは第６のサブネットＳ６を介して第６のゲートウエイルータＲ６へ接続され
る。
【００２０】 コンピュータ（Ｈ１ないしＨ７）、ルータ（Ｒ１ないしＲ７、ＡないしＥ）、
およびサブネット（Ｓ１ないしＳ６）は、インターネットの一部を形成している
。インターネットは、ＬＡＮ（Ｌ１ないしＬ６）へ接続された多数の他のコンピ
ュータ（図示されていない）を含み、さらに他のサブネット、ルータ、およびＬ
ＡＮを含むこともある。インターネットはコンピュータ（Ｈ１ないしＨ７）がメ
ッセージを互いに送ることができるように動作する。インターネットは、例えば
一般的にインターネットとして知られているネットワークであってもよい。
【００２１】 インターネットはＴＣＰ／ＩＰネットワークアーキテクチャにしたがって動作
する。さらに図１に示された少なくともコンピュータおよびルータはマルチキャ
スティングを支援する。
【００２２】 ７つのコンピュータ（Ｈ１ないしＨ７）のそれぞれは、そのユーザがマルチプ
レーヤゲームに参加できるようにするプログラムによって制御される。ユーザが
ゲームに影響を与えるように動作するとき、このアクションを表わすメッセージ
は他のコンピュータのそれぞれへ送られる。当業者によって認識されるように、
このようなメッセージはマルチキャスティングプロトコルにしたがって、マルチ
キャストグループを形成する７つのコンピュータを使用してルート設定される。
以下の記述では、資源ベースのツリーマルチキャストルート設定プロトコルが使
用されるが、その代わりにコアベースのツリー（ＣＢＴ）プロトコルのような共
有ツリープロトコルを使用することができる。当業者は、共有ツリーマルチキャ
スティングプロトコルにしたがって動作するのに本発明を採用することにほとん
ど問題がない。
【００２３】 インターネットという用語にしたがって、後述ではコンピュータはホストと呼
ばれ、用語‘ノード’はホストおよびルータの両方を指すことを意図している。
コンピュータ上を走行しているプログラムはアプリケーションと呼ばれる。イン
ターネットにアクセスするのに必要な1以上のアプリケーションは所定のホスト によって実行できるので、各アプリケーションに‘ポート番号’を割り当てて、
ポート番号で分類された到来メッセージを対応するアプリケーションに送ること
ができる。
【００２４】 当業者には分かっているように、ＴＣＰ／ＩＰプロトコルスーツ(suite)はノ ードではなく、インターフェイスを参照するアドレスを使用する。したがってホ
ストＨ１はインターフェイスＩ１のＩＰアドレスによって識別され、ルータＲ１
は、該ルータＲ１をＬＡＮ Ｌ１に接続するインターフェイス用の１つのＩＰア ドレスと、該ルータＲ１を第１のサブネットＳ１に接続するインターフェイスＩ
3用の別のアドレスとをもつ。
【００２５】 メッセージは、送信ホストからマルチキャストグループ内の他のホストへ下流
を移動するといわれている。したがって、例えば第１のホストＨ１から他のホス
トへのメッセージの資源の予約については、第１のルータＲ１と第１のＬＡＮ Ｌ１との間のインターフェイスＩ１は上流のインターフェイスであることが知ら
れており、第１のルータＲ１と第１のサブネットＳ１との間のインターフェイス
Ｉ２は下流インターフェイスであることが知られている。
【００２６】 おおざっぱに言うと、本発明の第１の実施形態によると、７つのホスト（Ｈ１
ないしＨ７）にサービスしているインターネットの一部は、ＴＣＰ／ＩＰネット
ワークアーキテクチャにしたがって動作するが、加えて各ホストは他のホストと
通信するのに次の手続きにしたがってインターネットの資源を予約することがで
きる。ホストの予約に適した資源をもつことによって、他のホストへの通信経路
の特徴を制御することができる。例えば、通信遅延が最小にされるか、または所
定の範囲よりも低くすることができる。
【００２７】 この実施形態においては、各ホストは時折予約パケット（以下ではＲＥＳパケ
ット）を他の全てのホストへ送る。このパケットの目的の一部は各ノードに、資
源ベースのツリーにおいて直ぐ上流のノードの下流インターフェイスのアドレス
を与えることであり、メッセージはこの資源ベースのツリーにしたがって他の各
ホストへ向かう。このアドレスは先行するホップアドレスとして知られている。
当業者は、類似の機能がＲＳＶＰプロトコルのＰＡＴＨ（経路）メッセージによ
って実行されることを認識する。
【００２８】 受信ホストが少なくとも1つのＲＥＳパケットを受取ると、後方向制御（Backw ard Control）パケット（以下では、ＢＷＤＣパケットと記載される）を送信ホ ストへ送信を開始する。通常、受信ホストは所定のリフレッシュ期間において（
（以下で開示される）一定の環境を通って）１つのこのようなパケットを送る。
【００２９】 各ノードは、それが受取るＢＷＤＣパケットを読み取り、メモリ内のパケット
に含まれる経路の特徴を表わす最悪を記憶する。記憶された値を使用して、イン
ターフェイス経路の特徴ごとの最悪を表わすデータを更新する（このような記憶
されたデータは当業者に対する‘状態’エントリーとして知られている）。イン
ターフェイス状態エントリごとの類似の最悪は、ノードの他の各下流インターフ
ェイスに対して生成される。次に状態エントリは比較され、ノード経路の特徴ご
との最悪は状態エントリから得られ、上流へ送られるＢＷＤＣパケット内に含ま
れる。
【００３０】 上流へ送られるＢＷＤＣパケットの内容は、ノードから送られた先のＢＷＤＣ
パケットの内容とは異なる。さもなければＢＷＤＣパケットはリフレッシュ期間
が終わったときに送られる。
【００３１】 この手続きの結果、資源ベースのツリー内の各ノードはインターフェイス状態
エントリごとの最悪、すなわち該ノードから受信ホストの１以上へ導かれるツリ
ー上の経路から全ての経路の特徴を表わす最悪を記憶することになる。
【００３２】 次に受取られるＲＥＳパケットに基づいて、各ノードはインターフェイス状態
エントリごとの対応する最悪を使用して、ツリーの各下流リンク上で要求される
予約を計算する。
【００３３】 ノードにおけるインストールされた予約または状態エントリは、ＲＳＶＰにお
いて使用されるようないわゆる‘ソフト状態’を使用して実行される。したがっ
て状態エントリは当業者に知られている適切なリフレッシュがないときに削除さ
れることになる。
【００３４】 ここで予約プロセスを図２ないし５に関係してより詳しく記載する。
【００３５】 送信ホストから送られるＲＥＳパケットは、図２に開示された情報を含む。パ
ケットは同様のやり方でＩＰデータグラム内に、例えばＲＳＶＰ制御メッセージ
へエンカプシュレート（カプセル化）され、ＩＰヘッダ内の他のヘッダフィール
ド（図示されていない）によってこの予約プロトコルに関係するデータグラムと
して識別される。当業者は図２に示されていないＩＰヘッダ内の対のフィールド
をよく知っていると考えられる。
【００３６】 ＲＥＳパケット内の他のフィールドは次の情報を含む。 ・session（セッション）―これはＲＳＶＰプロトコルによって識別されるセッ ションと同一である―これはＲＥＳパケットが関係するフロー（すなわち、1以 上のメッセージ）用の送信先アドレス（マルチキャストグループに対するマルチ
キャストアドレス）、およびフローに関係する他のパラメータを含む。当業者は
これらのパラメータの性質が分かる。 ・Sender Template（送信者テンプレート）―これはＲＳＶＰプロトコルによっ て規定される対応するフィールドと同一である―すなわち、これは送信ホストを
識別するフィルタ規格である。これは送信ホストのＩＰアドレス、加えて選択的
に使用される送信ホストポートを含む。 ・Traffic specification(Tspec)（トラヒック規格）―これは後続のトークンバ
ケット表示を使用して送信ホストのトラヒック特徴を記述しているＲＳＶＰプロ
トコルによって規定される対応するフィールドと同一である。
【００３７】 ｐ＝フローのピークレート（バイト／秒） ｂ＝バケットの深さ（バイト） ｒ＝トークンバケットレート（バイト／秒） ｍ＝最小の規制されたユニット（バイト） Ｍ＝最大のデータグラムの大きさ（バイト） ・previous hop (Phop)（先のホップ）―これはＲＳＶＰプロトコルによって規 定された対応するフィールドと同一であり、すなわちこれは先行のホップアドレ
スを含むオブジェクトである。 ・timestamp（タイムスタンプ）フィールド―これは分散形ツリーを下って次の ノードへ到達する直前にローカルノードクロックの時刻でスタンプされる。 ・end-to-end delay（二端点間遅延）フィールド―これは、パケットが送信ホス
トによって送られるときから次のノードの上流インターフェイスに到達するとき
までの現在の遅延を与える。 ・CRTフィールド（２ビット）―これは送信ホストアプリケーションのシーリン グ予約タイプを識別する。１１は保証されるサービスを示し、１０は制御される
ロードを示し、００は最善を尽くすことを示す。０１は現在は特定されていない
が、最善を尽くすタイプと制御されるロードタイプとの間における新しいサービ
ス品質に対して使用することができる。 ・QoSvoid bit―これは１に設定されるときに、サービス品質保証を提供できな いことを示す。
【００３８】 送信ホストが保証されるサービスを要求するとき、データグラムはさらに次の
情報を含む保証されたサービスオブジェクトを含む。値CSumおよびDSumは上述の
保証されたサービス規格において規定される。 ・CSum―最後の上流がポイントを再生してからのＣ値の累積。 ・DSum―最後の上流がポイントを再生してからのＤ値の累積。 ・desired delay bound(所望の遅延範囲)フィールド―送信ホストアプリケーシ ョンによって要求される二端点間の遅延範囲を示す。 ・accumlated delay bound（累積された遅延範囲）フィールド―送信ホストと次
のノードの上流インターフェイスとの間のインストールされた遅延範囲を示す。 ・delayvoid bit(DV)―設定されると、このビットは所望の遅延範囲を保証でき ない受信ホストに対する指標となる。 ・lossvoid bit(LV)―設定されると、このビットは損失のないサービスを保証で
きない受信ホストに対する指標となる。
【００３９】 アプリケーションの制御のもとで実行する各ノードおよび受信ホストによって
送られるＢＷＤＣを図３に示した。ＲＥＳパケットのように、ＢＷＤＣパケット
はＩＰデータグラム内にエンカプシュレートされる。各場合において送信先のＩ
Ｐアドレスは先行のホップアドレスである。当業者は、この態様においてＢＷＤ
ＣパケットはＲＳＶＰプロトコルのＲＥＳＶパケットと同じである。
【００４０】 ＢＷＤＣパケット内に含まれる他の情報は次のものを含む： ・session（セッション）―これは対応するＲＥＳパケットに対して上述で規定 されるセッションフィールドと同一である。 ・downstream hop（下流ホップ）オブジェクト―これはＲＳＶＰの次のホップオ
ブジェクトと同一である。―すなわちこれは、その送られるパケットの直ぐ下流
のノードの上流インターフェイスのアドレスを与える。 ・timestamp（タイムスタンプ）フィールド―ノードの直ぐ上流へ送られる直前 にローカルノードクロックの時刻でスタンプされる。 ・timedeltaprevフィールド―これは、ノードの直ぐ上流へ送られる直前にtimed
eltaprevの記憶された値（この値は後で開示する）で満たされる。 ・CRTrフィールド（２ビット）―このフィールドは、受信ホストアプリケーショ
ンシーリング予約タイプを示す。このフィールドの値とそれらが表わす予約タイ
プとの間のマッピングは、ＲＥＳメッセージ内のＣＲＴフィールドと同じである
。 ・Worst Case Delay（最悪ケース遅延）フィールド―これは、ＢＷＤＣパケット
を送るノードの上流インターフェイスとそのノードの下流の各受信ホストとの間
で測定される最大データパケット伝搬遅延に等しい。 ・path MTU（経路ＭＴＵ）フィールド―これは、ＢＷＤＣパケットを送るノード
の上流インターフェイスとそのノードの下流の各受信ホストとの間の最小path M
TU値に等しい。 ・Worst Case Ctot（最悪ケースCtot）フィールド―これは保証されるサービス 規格に規定される通りである―すなわちこれは、ＢＷＤＣパケットを送るノード
の上流インターフェイスとそのノードの下流の各受信ホストとの間で経路に沿っ
て最大の累積されたCtot値に等しい。 ・Worst Case Dtot（最悪ケースDtot）―これは保証されるサービス規格におい て規定される通りである―すなわちこれはＢＷＤＣパケットを送るノードの上流
インターフェイスとそのノードの下流の各受信ホストとの間の経路に沿って最大
の累積されたDtot値に等しい。 ・path bandwidth（経路バンド幅）―これはＢＷＤＣパケットを送ったノードの
上流インターフェイスとそのノードの下流の各受信ホストとの間で経路に沿う最
大経路バンド幅に等しい。 ・sender address（送信者アドレス）―送信ホストのアドレスの組―アドレスは
（ホストＨ１ないしＨ７のグループのマルチキャストアドレスと組み合わせて）
、資源ベースのツリーがパケットに関係するノードを示す。
【００４１】 CtotおよびDtotは保証されるサービス規格において規定される通りである。送
信ホストが保証サービスを要求したとき、ＢＷＤＣパケットはさらに次のものを
含む： ・excess delay field(超過遅延フィールド)―インストールされた二端点間遅延
範囲が所望の二端点間遅延を現在超えた量。 ・bottleneck flag（ボトルネックフラグ）―後で開示するように、これは１に 設定されたとき、ＢＷＤＣメッセージが少なくともボトルネックルータに関する
限り移動したことを示す（すなわちＲＥＳメッセージの第１の経路上で累積され
た範囲が最初に所望の範囲を超えたときのルータ）。
【００４２】 最初に予約を設定するとき、各ホストはＲＥＳパケットを他のホストへ送る。
送信ホストから受信ホストへ経路によって構成される資源ベースのツリー上の各
ノードは次のタイミング動作を実行する。後で開示するように、各ノードは、Ｒ
ＥＳパケットを受取るたびにこれらの動作を実行する。
【００４３】 最初にtimestampフィールドは読み取られ、ノードのローカルクロックと比較 され、ＲＥＳパケットが最後のホップを横切るのにかかった時間を判断する。こ
の継続時間はパラメータtimedeltaprevとしてノードに記憶される。このtimesta
mpは次にノードのローカルクロックにしたがって設定され、ＲＥＳパケットは受
信ホストへ向けて資源ベースのツリーに沿って次のノードへ送られる。このプロ
セスは、（下流方向で移動するとき）関係する各ノードがそれらの直ぐ上流ホッ
プにおける伝搬遅延を表わすパラメータ（timedeltaprev）を記憶するまで反復 される。
【００４４】 ＲＥＳパケットが資源ベースのツリーのノードを通って伝搬されると、各受信
ホストはＢＷＤＣパケットを送信ホストへ送る。ホストによってパケット内に置
かれる初期値は、次のように判断される。path MTUおよびpath bandwidthは、送
信ホストが取付けられているＬＡＮの特徴に対応する。ホストは下流ノードフィ
ールド内にＩＰアドレスを挿入し、それが要求するサービス品質にしたがってCR
Trを設定する。最悪ケース(worst case)の経路の特徴は、ボトルネックフラグの
ように全てゼロに設定される。excess delayフィールドはこの段階で使用されな
い。timedeltaprevパラメータはtimedeltaprevフィールドに割り当てられる。
【００４５】 ＢＷＤＣパケットを受取ると、ノードは後述のタイミング動作、およびノード
経路の特徴ごとの最悪を判断する動作を実行する。
【００４６】 タイミング動作は、ノードが最初にパケット内のtimedeltaprevフィールドを 読取ることを含む。タイミング動作は（下流方向に移動するときに）ノードから
下流のホップにおける（ＲＥＳパケットによって経験される）伝搬遅延を記録す
ることが分かる。さらにＢＷＤＣパケットのタイムスタンプフィールドおよびロ
ーカルクロックを読み取ることによって、他の方向において同じホップ上の伝搬
遅延の値が得られる。下流ホップにおける遅延は何れの方向においても同じであ
ると仮定される。したがってこれらの２つの遅延の平均をとることによって、ノ
ードクロック間の不一致とは無関係に伝搬遅延値が得られる。下流ホップに対す
るこの平均遅延はパラメータ‘dnext’としてノードによって記憶される。
【００４７】 経路の特徴を監視する動作は次の通りである。
【００４８】 ＢＷＤＣパケットが到達すると、ノードは最初に現在のセッションおよび２つ
の経路を識別するパラメータによって識別される下流経路、すなわちパケットの
下流ノードフィールドに関係する経路状態エントリごとの最悪、並びにＢＷＤＣ
メッセージが到達した下流インターフェイスのアドレスの存在を検査する。
【００４９】 経路およびセッションに関係する経路状態エントリごとに予め記憶された最悪
が見付からないとき、経路状態エントリごとの新しい最悪が生成される。
【００５０】 経路状態エントリごとの最悪のフォーマットは図４に示した通りであり、sess
ion identifyingフィールド、sender addressフィールド、およびtwo path iden
tifyingフィールドを含み、さらに加えて次のフィールド： ・Worst Case Ctot（最悪ケースCtot） ・Worst Case Dtot（最悪ケースDtot） ・Worst Case Delay（最悪ケース遅延） ・ path bandwidth（経路バンド幅） ・ CRTr ・path MTU（経路MTU） ・dnext ・bottleneck flag（ボトルネックフラグ） 経路状態エントリごとの新しい最悪は、CRTr、経路バンド幅、pathMTU、Worst
Case Delay、Worst Case Ctot、およびWorst Case Dtotの値を割り当てること によって生成され、これらの値はＢＷＤＣパケット内において経路状態エントリ
ごとの最悪の対応するフィールドに含まれている。タイミング動作において計算
されるパラメータdnextはdnextフィールドに割り当てられる。bottleneck flag はゼロに初期設定され、次に記載するように使用される。
【００５１】 ノードは同じインターフェイス上に経路状態エントリごとに複数の最悪をもち
、同じセッションに関係するとき、ノードはそれらを結合して、インターフェイ
ス状態エントリごとに最悪を生成する。この状況は下流インターフェイスが共有
媒体のＬＡＮへ接続するときに生じることがある。
【００５２】 図５に示したように、インターフェイス状態エントリごとの最悪は経路状態エ
ントリごとの最悪と同じフィールドを含むが、経路状態エントリごとの最悪は下
流ノードフィールドがない。session、sender adressフィールド、および下流イ
ンターフェイスフィールドに割り当てられた値は経路状態エントリごとの最悪の
ものと同じである。他のフィールドの値は次のように計算される。 ・Worst Case Ctot = MAX{Worst Case Ctoti} ・Worst Case Dtot = MAX{Worst Case Dtoti} ・Worst Case Delay = MAX{Worst Case Delayi} ・path bandwidth = MAX{path bandwidthi} ・pathMTU = MIN{pathMTUi} ・CRTr = MAX{CRTi} ・dnext = MAX{dnexti} なお、下付き文字ｉは１ないし下流インターフェイスを共有するノード数の値
をとる。インターフェイス状態エントリごとの最悪で記憶された値Worst Case C
tot、Worst Case Dtot、Worst Case Delayは、下流インターフェイスに対する最
悪ケース(worst case)の経路特徴値である。これらの値はインターフェイスとは
異なる経路に関係することが可能である。経路状態エントリごとの何れかがそれ
を１に設定するときは、bottleneck flag(ボトルネックフラグ)は１に設定され る。
【００５３】 そのダウンストリームインターフェイスのそれぞれに対してインターフェイス
状態エントリごとの最悪を生成するとき、ノードは各状態期間に少なくとも１回
ノードデータごとに最悪を含むＢＷＤＣパケットを生成する。ノードデータごと
の最悪に含まれるパラメータは次のように計算される。 ・Worst Case Ctot = MAX{Worst Case Ctotn + Clocaln}、なおClocalnはＢＷＤ
Ｃパケットが到達した下流インターフェイスとノードの（session(セッション) によって判断される）上流インターフェイスとの間のCtotの値である； ・Worst Case Dtot = MAX{Worst Case Dtotn + Dlocaln}、なおDlocalnはＢＷＤ
Ｃパケットが到達した下流インターフェイスとノードの（sessin(セッション)に
よって判断される）上流インターフェイスとの間のCtotの値である； ・ Worst Case Delay = MAX{Worst Case Delayn} + dnextn ・ path bandwidth ＝ MIN(MAX{path bandwidthn}, path bandwidth upstre am) ・CRTr = MAX{CRTn} ・pathMTU = MIN(MIN{pathMTUn}, pathMTU upstream) なお、ｎは１からノードからの下流インターフェイス数への値をとるインデッ
クスであり、‘pathMTU upstream’および‘path bandwidth upstream’はそれ ぞれ最小のパケットの大きさおよび上流ホップのバンド幅を表わす。
【００５４】 CRTrが１１に設定されないとき、Ctot、Dtot、Worst Case Delayはゼロに設定
される。
【００５５】 上述の演算は、現在のセッションに関係する資源ベースのツリー内の各ノード
によって繰り返される。所定の送信ホストからのフローは、各ノードがノードか
ら受信ホストへ導かれる全ての経路の最悪のケースの特徴を記憶することが認識
されるであろう。
【００５６】 次に送信ホストは別のＲＥＳパケット（図２参照）要求、例えば保証されるサ
ービスを送る。したがってパケット内のＣＲＴフィールドは１１に設定され、所
望の遅延範囲は、パケットが送信ホストから全ての受信ホストへ到達するのにか
かる時間に代わること受信者が望む制限値に設定される。
【００５７】 トラヒック規格フィールドは送信ホストによって埋められ、二端点間遅延フィ
ールドは送信ホストにおいて記憶されるパラメータdnextの値に設定される。所 望の遅延範囲以外の保証されるサービスの各フィールドはゼロに初期化される。
【００５８】 資源ベースのツリーに沿う下流の第１のノードでは、照会遅延は現在のセッシ
ョンに含まれる１以上の下流ホップのそれぞれに対してフローに与えられること
になる。これは次の式にしたがって決定される： 式（１） Qdelay=所望の範囲(desired-bound)−累積された範囲(accumulated-bound)−最 悪ケース遅延(Worst Case Delay) Worst Case Delay値は、対応するフィールドと、現在のノードにおけるインタ
ーフェイス状態エントリごとの最悪のdnextパラメータとの和に等しい。第１の ノードにおいて、累積された範囲は通常ゼロかまたは非常に小さい値である。Qd
elay値は、受信ホストへの経路の残りにおいて許容できる合計の待ち行列遅延に
ついての推定値を表わす。
【００５９】 ＲＳＶＰプロトコルにしたがって動作する受信者によって実行されるプロセス
に類似したプロセスを使用して、各下流ホップ(downstream hop)において予約さ
れるバンド幅を計算して、所望の範囲において‘オンコース（予定進路を進行し
ている）’に留まる。インターフェイスパラメータごとの個々の最悪はこのイン
ターフェイスと異なる経路に関係していることあがるので、この計算によるとし
ばしば過大推定になってしまうことがある。当業者は、次の式を使用して推定値
を計算することを実現することになる： 式２ Qdelayend2end = ［(b-M)(p-R)/｛R(p-r) +（(M + Ctot)/R）｝］+ Dtot (ケースp > R > = r) 式３ Qdelayend2end =（(M + Ctot)/R）+ Dtot (ケースR > = p > = r) パラメータＭ、ｐ、ｂ、およびｒはＲＥＳメッセージの対応するフィールドか
ら得られる（これらの符号の意味はＲＥＳメッセージに対して既に開示した通り
である）。CtotおよびDtotの値は、現在の下流インターフェイスに関係するイン
ターフェイス状態エントリごとの最悪からの値と、ＣおよびＤのローカル値との
和である。Qdelayの値を得て、式２および３へ挿入するために、式１が使用され
る。式１を解いて、Ｒに対する値を得て、バンド幅Ｒが現在の下流インターフェ
イスから導き出されるホップ上で予約される。
【００６０】 保証されるサービス規格に記載される規則にしたがって、CsumおよびDsumの値
を他のパラメータと共に使用して、パケット損失を防ぐために予約に割り当てら
れなければならないバッファリング量を計算する。
【００６１】 予約要求がサービスされると、ＲＥＳパケット内のend-to-end delay（端端間
遅延）フィールドはそれを次に示すものに追加することによって増加する： ・次のホップに対する伝搬遅延、dnext；および、 ・ＲＥＳパケットが参照するフローのデータパケットにおける（関係する出力す
るインターフェイスに対する）現在のローカル照会遅延の推定値。
【００６２】 さらに次の更新がＲＥＳパケットに対して行なわれる： ・コピーされたパケットのaccumlated delay bound（累積遅延範囲）フィールド
は次に示すものによって増加される： １）次のホップに対する伝搬遅延、dnext；および、 ２）ＲＥＳパケットが参照するフローのメッセージにおける（関係する下流
インターフェイスに対する）インストールされたローカル待ち行列遅延範囲。こ
のローカル照会遅延範囲は、Ｒの予約された値を式２および式３へ、それぞれパ
ラメータCtotおよびDtotに対するローカル値ＣおよびＤと共に挿入することによ
って得られる。
【００６３】 ＲＥＳパケットに対して次の更新を行なう： ・Ｃのローカル値をCSumフィールドに加える；および、 ・Ｄのローカル値をDSumフィールドに加え、 これは送信ホストのトラヒックの再形成が下流インターフェイスにおいて実行さ
れないことを条件とし、この場合にCSumおよびDsumがゼロに設定される。
【００６４】 さらに次の何れかのとき、Qosvoidフィールドが１に設定される： ａ）保証されるサービス予約試行は、トラヒック規格のトークンバケットレ
ートと少なくとも同じ大きさのバンド幅を予約しないとき；または、 ｂ）制御されるロード予約試行が失敗するとき。
【００６５】 ノードが１に設定されるQosvoidの組をもつＲＥＳパケットを受取るとき、MIN
{CRTs，CRTr}が１０または１１のときは、このノードは制御されるロード予約を
保証する試行を行なう。
【００６６】 フィールドの更新が完了するとき、ＲＥＳパケットをルート設定ツリーにした
がって各次のホップに到達する前に、timestampフィールドは（上述のように） ローカルクロックに等しく設定される。
【００６７】 類似のプロセスが次の各ノードにおいて実行され、インストールされた待ち行
列によって累積された範囲が増加することによって式（１）から得られるQdelay
の値を生成することになり、これは受信ホストへの経路の残りに対して許容でき
る合計の待ち行列遅延の推定値を維持する。宣言されるトラヒック規格にしたが
うホストからのメッセージがあると仮定し、各ノードが計算されたバンド幅Ｒを
予約できるとすると、ノードにおける上述のプロセスは、送信ホストからのメッ
セージが受信ホストの全てに対する所望の遅延範囲内に伝えることができるよう
にするのに効果的である。
【００６８】 ノードが上述のように計算されたバンド幅を予約できないとき、（ノードにお
いて規制の実行を受け）可能な限り大きなバンド幅が予約される。しかしながら
予約されるバンド幅量は、ＲＥＳパケットのトークンバケットレートフィールド
(tocken bucket rate field)の値よりも小さいとき、保証されるサービスは提供
されず、これはdelayvoid、lossvoid、Qosvoidフラグを１に設定することによっ
て示される。
【００６９】 予約されたバンド幅がＲＥＳパケットのトークンバケットレートフィールドの
値よりも大きいとき、累積される範囲は所望の範囲と比較される。
【００７０】 所望の範囲がより大きくなると、予約プロセスは上述のように継続する。予約
されたバンド幅Ｒは上述のように過大に推定されることがあるので、これはしば
しば、所望の遅延範囲よりも小さい二端点間の経路において遅延を与える予約を
設定することになる。
【００７１】 しかしながら所望の範囲がより小さくなるとき、ノードは次のように動作する
： ・インターフェイス状態エントリごとの関連性と関係する予約のbottleneck fla
gを設定して、ボトルネックノードとしてそれ自身を分類する； ・ＲＥＳパケット内のdelayvoidフラグを１に設定し、それをツリーにしたがっ てノードへ送る。
【００７２】 ノードは、delayvoidフィールドを１に設定したＲＥＳパケットを受取ると、 可能な最大バンド幅（送信ホストのピークレートの倍数に制限される可能性が高
い）を予約し、それを送る。
【００７３】 （CRTs=CRTr=11において）delayvoidフィールドが１に設定され、delaylossフ
ィールドが０に設定されたＲＥＳパケットを受取るとき、受信ホストはaccumula
ted delay boundフィールドがdesired delay boundフィールドを超える量を計算
する。受信ホストは直ちに、excess delayフィールドが計算された超過遅延に設
定され、bottleneckフィールドがゼロに設定されたＢＷＤＣパケットを送る。こ
のようなＢＷＤＣパケットを受取る各ノードは、インターフェイス状態エントリ
ごとのノードの関係する最悪のbottleneck flagが１に設定されない限りパケッ トを無視する。ボトルネックノードはＢＷＤＣパケットを受取り、bottleneck f
lagフィールドを1に設定する。ノードは、ローカルバンド幅の予約を増加するこ
とによってＢＷＤＣメッセージ内に示されたexcess delayを削除または低減する
試行を行なう。この後でexcess delayが依然として存在するとき、excess delay
の修正値をもつＢＷＤＣパケットはホップへ、および同時に送信者へ送られ、Ｂ
ＷＤＣパケットが送信者に届くかまたはexcess delayが削除されるまで、各ノー
ドにおいて予約増加が試行される。
【００７４】 上述の実施形態では、データは各ノードにおいて結合され、結合されたデータ
を使用して、適切な資源予約を計算するとき、ノードの上流へ送られる。
【００７５】 別の実施形態では、資源予約は、結合が行なわれるノードにおいて結合された
データに基づいて計算することができる。
【００７６】 第２の実施形態は第１の実施形態に類似しているが、共有のツリープロトコル
を使用する。第２の実施形態において、sender addressフィールド（ＢＷＤＣパ
ケットでは、経路ごとに最悪およびインターフェイス状態エントリごとに最悪）
は要求されない。これは、ＲＥＳパケットが送られないインターフェイスが、se
ssionパラメータおよび到来インターフェイスに基づいてノードによって判断で きるからである。共有のツリーを使用するとき、インターフェイス状態エントリ
ごとの最悪が、マルチキャストグループに対する特定の送信者ではなくマルチキ
ャストグループに関係することになるとき、各ノードにおけるインターフェイス
状態エントリごとの最悪の数は、ノードから出力インターフェイス数と同じであ
る。
【００７７】 マルチ送信者環境において、第２の実施形態は、既知の予約プロトコルと比較
して要求されるインターフェイス状態エントリごとの最悪の量を低減することが
分かるであろう。
【００７８】 上述の実施形態において、Ｃターム（例えば、Ctot）、Ｄターム（例えば、Dt
ot）、およびリンク伝搬遅延の最悪ケースの組み合せは各用語ごとに独立して行
なわれた。したがって非常に保守的なローカルバンド幅予約となる。好ましい実
施形態では、Ｄ用語とリンク伝搬遅延とを含むレートの独立した遅延パラメータ
が使用される。これは、単なる各経路からの最大値Ｄではなく、遅延パラメータ
から独立した最悪ケースのレートの値としてＤの送られた値を取ることによって
達成できる。
【００７９】 上述の実施形態では、下流の受信者の1人によって要求される最高のサービス 品質をルータが見付けることができることが分かるであろう。同様の検討をータ
および他の予約に影響を与えるパラメータに応用する。ネットワーク内の中間ノ
ードにおけるこのようなパラメータの結合により、パケットネットワークにおけ
るマルチキャスト通信に対してより融通の利く資源予約を行なうことができる。
【図面の簡単な説明】
【図１】 インターネットを使用して相互に通信するコンピュータグループを示す模式図
。
【図２】 本発明の第１の実施形態において使用されたパケットを設定する予約内容を示
す模式図。
【図３】 第１の実施形態で使用されたノードパケットごとの上流にルート設定された最
悪の経路の特徴内容を示す模式図。
【図４】 第１の実施形態にしたがって動作するノード内に記憶される経路データごとに
最悪の経路の特徴を示す模式図。
【図５】 第１の実施形態にしたがって動作するノードに記憶されるインターフェイスデ
ータごとに最悪の経路の特徴を示す模式図。
───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ， ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，Ｄ Ｋ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ， ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，Ｌ Ｕ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ， ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，Ｕ Ｇ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者 カーター、サイモン・フランシス イギリス国、アイピー12・４ジェイエヌ、 サフォーク、ウッドブリッジ、モアフィー ルド・ロード ５ (72)発明者 オニール、アラン・ウイリアム イギリス国、アイピー４・２ジェイエー、 サフォーク、イプスウイッチ、セマトリ ー・ロード 36、ラチャエルス・コート ２ (72)発明者 ホワイト、ポール・パトリック イギリス国、エム27・０エイチビー、マン チェスター、スイントン、リングロウ・パ ーク・ロード 82 Ｆターム(参考） 5K030 HA08 HB17 HC01 KA05 LB05 LC09 5K034 CC06 EE11 FF10 NN31

Claims (7)

    【特許請求の範囲】
  1. 【請求項１】 複数のホストおよび1以上の相互接続ノードを含むパケット ネットワークにおいて資源を予約する方法であって： 複数の受信ホストを動作して、1以上の予約に影響を与えるパラメータを含む 逆方向にルート設定されたパケットを、ルートに沿って1以上の前記相互接続ノ ードを経由して1以上の送信ホストへ送る段階と； 前記１以上の中間ノードが、 異なる受信者から受取った逆にルート設定されたパケットの1以上のパラ メータを結合して、結合された予約に影響を与えるパラメータを生成して、 前記結合されたパラメータを記憶して、 前記結合されたパラメータを含む逆方向にルート設定されたパケットをさ
    らに前記ルートに沿って1以上の送信ホストへ送るように動作する段階と； 前記送信ホストを動作して、資源予約パケットを前記ルートに沿って1以上 の受信者へ送り返す段階と； 前記１以上の中間ノードを動作して、前記予約パケットに応答して、該ノー
    ドに記憶された予約に影響を与えるパラメータにしたがって資源を予約する段階
    とを含む方法。
  2. 【請求項２】 前記1以上の予約に影響を与えるパラメータが所望のサービ ス品質クラスの指標を含み； 前記1以上の中間ノードが： 前記パラメータを更新して、下流の受信者によって要求される最高のサービ
    ス品質クラスを表わし； 前記最高のサービス品質クラスと関係する資源予約プロセスにしたがって資
    源を予約するように動作する請求項1記載の方法。
  3. 【請求項３】 前記1以上の予約に影響を与えるパラメータが経路の特徴を 表わすパラメータを含む請求項1記載の方法。
  4. 【請求項４】 前記経路の特徴を表わすパラメータが1以上の遅延パラメー タを含む請求項３記載の方法。
  5. 【請求項５】 前記ホストが共有のツリールート設定アルゴリズムにしたが
    って通信する請求項１ないし４の何れか1項記載の方法。
  6. 【請求項６】 パケットネットワークであって： 受信された逆方向にルート設定されたパケットの１以上のパラメータを結合
    して、結合された予約に影響を与えるパラメータを生成する手段と； 前記結合されたパラメータを記憶する手段と； さらに前記ルートに沿って前記結合されたパラメータを含む逆にルート設定
    されたパケットを前記送信ホストへ送る手段と； 予約パケットに応答するノードに記憶された結合された予約に影響を与える
    パラメータにしたがって資源を予約する手段とを含むパケットネットワークノー
    ド。
  7. 【請求項７】 複数のホストおよび1以上の相互接続ノードを含むパケット ネットワークにおいて資源を予約する方法であって： 1以上の経路パラメータを含む経路の特徴を表わすデータパケットを、ルート に沿って1以上の前記相互接続ノードを経由して1以上の送信ホストへ送るように
    複数の受信ホストを動作する段階と； 前記1以上の中間ノードを、 受取った経路の特徴を表わすデータパケットの1以上のパラメータをプロ セスして、更新された経路の特徴を表わすパラメータを生成し、 前記更新されたパラメータを記憶し、 前記更新されたパラメータを含む経路の特徴を表わすデータパケットを前
    記ルートに沿って前記送信ホストへさらに送るように動作する段階と； 資源予約パケットを1以上の受信者へ前記ルートに沿って戻す段階と； 前記予約パケットに応答して、そのノードに記憶された経路の特徴を表わす
    データにしたがって資源を予約するように、前記送信ホストを動作する段階とを
    含む方法。
JP2000519535A 1997-11-03 1998-11-03 パケットネットワーク Expired - Fee Related JP4399109B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP97308790 1997-11-03
EP97308790.1 1997-11-03
PCT/GB1998/003274 WO1999023799A1 (en) 1997-11-03 1998-11-03 Packet network

Publications (2)

Publication Number Publication Date
JP2001522199A true JP2001522199A (ja) 2001-11-13
JP4399109B2 JP4399109B2 (ja) 2010-01-13

Family

ID=8229593

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000519535A Expired - Fee Related JP4399109B2 (ja) 1997-11-03 1998-11-03 パケットネットワーク

Country Status (6)

Country Link
US (1) US6163807A (ja)
EP (1) EP1031224B1 (ja)
JP (1) JP4399109B2 (ja)
AU (1) AU9754498A (ja)
DE (1) DE69829203T2 (ja)
WO (1) WO1999023799A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020510342A (ja) * 2017-03-10 2020-04-02 シーメンス アクチエンゲゼルシヤフトＳｉｅｍｅｎｓ Ａｋｔｉｅｎｇｅｓｅｌｌｓｃｈａｆｔ Ａｖｂストリームのモジュール式ルーティングの方法及び装置

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7260060B1 (en) * 1997-06-07 2007-08-21 Nortel Networks Limited Call admission control
US6798786B1 (en) * 1999-06-07 2004-09-28 Nortel Networks Limited Managing calls over a data network
US6519595B1 (en) * 1999-03-02 2003-02-11 Nms Communications, Inc. Admission control, queue management, and shaping/scheduling for flows
EP1079573B1 (en) * 1999-08-20 2013-02-27 Nortel Networks Limited Managing calls over a data network
US6975613B1 (en) 1999-12-06 2005-12-13 Telefonaktiebolaget L M Ericsson (Publ) System and method for scheduling communication sessions in an ad-hoc network
US6480505B1 (en) 1999-12-06 2002-11-12 Telefonaktiebolaget Lm Ericsson (Publ) Batched fair exhaustive polling scheduler
US6751200B1 (en) 1999-12-06 2004-06-15 Telefonaktiebolaget Lm Ericsson (Publ) Route discovery based piconet forming
US6704293B1 (en) 1999-12-06 2004-03-09 Telefonaktiebolaget Lm Ericsson (Publ) Broadcast as a triggering mechanism for route discovery in ad-hoc networks
US6535498B1 (en) 1999-12-06 2003-03-18 Telefonaktiebolaget Lm Ericsson (Publ) Route updating in ad-hoc networks
US7065578B2 (en) * 2000-03-20 2006-06-20 At&T Corp. Service selection in a shared access network using policy routing
US7606146B1 (en) * 2000-08-15 2009-10-20 Nortel Networks Limited Method and apparatus for implementing a policy-based management system on a network device
US7065042B1 (en) * 2000-08-15 2006-06-20 Nortel Networks Limited Aggregating filters
WO2002069108A2 (en) * 2001-02-26 2002-09-06 Eprivacy Group, Inc. System and method for controlling distribution of network communications
US7647411B1 (en) * 2001-02-26 2010-01-12 Symantec Corporation System and method for controlling distribution of network communications
US20030014532A1 (en) * 2001-07-16 2003-01-16 Shean-Guang Chang Method and apparatus for multicast support
KR100418562B1 (ko) * 2001-09-06 2004-02-14 주식회사 기지소프트 다중전송을 위한 중계경로 생성방법
US6925504B1 (en) * 2002-01-31 2005-08-02 Cisco Technology, Inc. Methods and apparatus for obtaining content from a content-originating device within a computerized network
DE10209048A1 (de) * 2002-03-01 2003-09-18 Siemens Ag Verfahren zur Signalisierung von Diensteanforderungen in heterogenen Netzen
US20030177125A1 (en) * 2002-03-18 2003-09-18 Dmitrii Loukianov Enhanced residential gateway and associated methods
JP2005534245A (ja) * 2002-07-25 2005-11-10 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ データを送るシステム及び方法
US7301951B2 (en) * 2002-07-31 2007-11-27 At&T Knowledge Ventures, L.P. Resource reservation protocol based guaranteed quality of service internet protocol connections over a switched network
US7272145B2 (en) * 2002-07-31 2007-09-18 At&T Knowledge Ventures, L.P. Resource reservation protocol based guaranteed quality of service internet protocol connections over a switched network through proxy signaling
US7065092B2 (en) * 2002-07-31 2006-06-20 Sbc Properties, L.P. Resource reservation protocol based guaranteed quality of service internet protocol (IP) connections over a switched network using newly assigned IP addresses
US7298750B2 (en) * 2002-07-31 2007-11-20 At&T Knowledge Ventures, L.P. Enhancement of resource reservation protocol enabling short-cut internet protocol connections over a switched network
US7467227B1 (en) * 2002-12-31 2008-12-16 At&T Corp. System using policy filter decision to map data traffic to virtual networks for forwarding the traffic in a regional access network
US7305479B1 (en) 2003-05-13 2007-12-04 Cisco Technology, Inc. Methods and apparatus for delivery of content requests within a content delivery network
US7373394B1 (en) 2003-06-30 2008-05-13 Cisco Technology, Inc. Method and apparatus for multicast cloud with integrated multicast and unicast channel routing in a content distribution network
GB0407144D0 (en) 2004-03-30 2004-05-05 British Telecomm Networks
US8055897B2 (en) * 2005-12-06 2011-11-08 Lippershy Celestial Llc Digital object title and transmission information
US20070136209A1 (en) * 2005-12-06 2007-06-14 Shabbir Khan Digital object title authentication
US8014389B2 (en) * 2005-12-06 2011-09-06 Lippershy Celestial Llc Bidding network
US9686183B2 (en) 2005-12-06 2017-06-20 Zarbaña Digital Fund Llc Digital object routing based on a service request
US8194701B2 (en) * 2005-12-06 2012-06-05 Lippershy Celestial Llc System and/or method for downstream bidding
US8762384B2 (en) * 2010-08-19 2014-06-24 Sap Aktiengesellschaft Method and system for search structured data from a natural language search request
US11438789B2 (en) * 2020-01-24 2022-09-06 Vmware, Inc. Computing and using different path quality metrics for different service classes
US12015536B2 (en) 2021-06-18 2024-06-18 VMware LLC Method and apparatus for deploying tenant deployable elements across public clouds based on harvested performance metrics of types of resource elements in the public clouds
US11943146B2 (en) 2021-10-01 2024-03-26 VMware LLC Traffic prioritization in SD-WAN
US11909815B2 (en) 2022-06-06 2024-02-20 VMware LLC Routing based on geolocation costs

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5831975A (en) * 1996-04-04 1998-11-03 Lucent Technologies Inc. System and method for hierarchical multicast routing in ATM networks
US5841777A (en) * 1996-08-30 1998-11-24 Hewlett-Packard Company System and method for accommodating ABR and CBR traffic on a shared communications channel
US6038212A (en) * 1996-12-13 2000-03-14 International Business Machines Corporation Method and system for optimizing the connection set up time in high speed communication networks for recovering from network failure

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020510342A (ja) * 2017-03-10 2020-04-02 シーメンス アクチエンゲゼルシヤフトＳｉｅｍｅｎｓ Ａｋｔｉｅｎｇｅｓｅｌｌｓｃｈａｆｔ Ａｖｂストリームのモジュール式ルーティングの方法及び装置
JP7046091B2 (ja) 2017-03-10 2022-04-01 シーメンス アクチエンゲゼルシヤフト Ａｖｂストリームのためのパスを予約する方法及び装置

Also Published As

Publication number Publication date
WO1999023799A1 (en) 1999-05-14
AU9754498A (en) 1999-05-24
EP1031224A1 (en) 2000-08-30
DE69829203D1 (de) 2005-04-07
EP1031224B1 (en) 2005-03-02
US6163807A (en) 2000-12-19
JP4399109B2 (ja) 2010-01-13
DE69829203T2 (de) 2006-02-16

Similar Documents

Publication Publication Date Title
JP4399109B2 (ja) パケットネットワーク
White RSVP and integrated services in the Internet: A tutorial
Partridge A proposed flow specification
Pan et al. YESSIR: A simple reservation mechanism for the Internet
Crowcroft Internetworking multimedia
US6519254B1 (en) RSVP-based tunnel protocol providing integrated services
US7974266B2 (en) Method and apparatus for classifying IP data
US8433521B2 (en) Avoiding unnecessary RSVP-based preemptions
US20070036163A1 (en) Resource sharing among multiple RSVP sessions
US7936696B2 (en) Efficient transmission of data to multiple network nodes
US20110299553A1 (en) Technique for Reducing Resources Allocated to an Existing Reservation in a Data Network
US8341288B2 (en) Mechanism for sharing resources among different senders and receivers
US7136382B1 (en) System and method for providing quality of service operations using IP addresses
Zhang et al. RFC2205: Resource ReSerVation Protocol (RSVP)--Version 1 Functional Specification
US6958974B1 (en) Method for providing a stable quality of data services within a packet-switching network
US7852762B2 (en) Shaping device and router device
Cisco Configuring RSVP
Cisco Configuring RSVP
Cisco Resource-Reservation Protocol (RSVP)
JP4340562B2 (ja) 通信の優先制御方法並びに通信の優先制御システム及び通信の優先制御装置
JP3686345B2 (ja) 通信品質保証方法
JP2002185516A (ja) パケット送信装置、パケット受信装置及びパケット通信方式
Partridge RFC1363: A Proposed Flow Specification
CN116668358A (zh) 一种基于优化蚂蚁算法的路由寻找方法及分布式会议系统
US20080159332A1 (en) Methods and devices for using variable length subpackets in data transmissions

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050802

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20070816

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070904

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20071204

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20071211

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080304

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20080930

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090204

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20090325

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090609

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090702

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: 20090929

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: 20091026

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121030

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: 20131030

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees