JP3953489B2 - 通信システムにおいてリソースをリザーブするための方法、ノード、システムおよびコンピュータ・プログラム - Google Patents

Description

本発明は、一般に、通信システムに関し、具体的には、前記通信システム内のリソースのリザーブに関する。

従来の通信システムまたはネットワークは、相互接続媒体によって結合された複数のノードから成る。通信は、「ソース・ノード（Source Node）」と呼ばれる１つのノードが、「宛先ノード（Destination Node）」と呼ばれる別のノードにデータを送信することによって実施される。特定のサービスの質（ＱｏＳ：Quality of Service）を維持するため、宛先ノードは、不適切な遅延を生じることなくデータを処理するための充分なリソースをリザーブしなければならない。実際、宛先ノードが充分なリソースをリザーブしなければならないだけでなく、宛先ノードに到達するまでにデータが通らなければならないあらゆる中間ノードも、これらの中間ノード内でデータの迅速な処理を確実にするための十分なリソースをリザーブしなければならない。例えば、ノードは、処理する前にデータをバッファするための十分なストレージ・スペースを有しなければならない。適切なバッファリングが行われなければ、ノードはデータを破棄しなければならない場合がある。この例では、ストレージがリソースである。しかしながら、一般に、リソースは、データを受信し処理するために必要なあらゆるものである可能性がある。結果として、リソースは、メモリ・スペース、プロセッサ・サイクル、リンク、帯域幅等を含み得る。

従来技術では、通信ネットワーク内でデータ・フローを管理するためのフロー制御の提案がいくつか行われている。リソース管理は、フロー制御方法の不可欠な部分である。従来技術のフロー制御の提案には、Ｂｒａｄｅｎ等による「Resource Reservation Protocol（ＲＳＶＰ）」（ＩＥＴＦ ＲＦＣ ２２０５、１９９７年９月）が含まれる。ＲＳＶＰは、受信器によって開始されるリソース・リザーブのセットアップを提供する。換言すると、宛先ノードは、ソース・ノードが送信するメッセージに基づいて、リソースをリザーブする。ＲＳＶＰプロトコルは、ホストが用いて、データ・フローのための帯域幅をネットワークに要求することができる。ＲＳＶＰは、通常、ルータによって用いられて、帯域幅の要求を、フローの経路または複数の経路に沿った全てのノードに配信する。また、ＲＳＶＰを発したノードは、ネットワークにおいて要求がインストールされたことを保証する確認を要求することができる。ＲＳＶＰの欠点の１つは、ＲＳＶＰプロトコルが、単純なフローについてのみリソースをリザーブすることである。換言すると、ＲＳＶＰは、１方向にのみリソースを要求する。このため、ＲＳＶＰは、同一のアプリケーション・プロセスが同時に送信者（ソース）および受信者（宛先）の双方として機能し得るとしても、送信者を、受信者から論理的に別個のものとして扱う。

「速度ベース」と呼ばれる別のフロー制御方式では、ソースから宛先にデータを配信することができる速度を、宛先からソースへのフィードバック信号によって制御する。宛先においてリソースが利用可能である場合、ソースは制限なしでデータを送信することができる。宛先のリソース供給が不十分であるか利用可能でない場合、送信速度は、完全にカットオフ・ポイントに制限される。かかる速度ベース技法の１つが、Ｌａｒｒｙ Ｒｏｂｅｒｔｓによる「Enhanced Proportional Rate Control Algorithm」と題するＡＴＭ文献＃９４−０７３５（１９９４年８月）に記載されている。

「信用ベース制御」と呼ばれる更に別のフロー制御方式では、宛先ノードは、「信用状」を発生してソース・ノードに転送し、ソース・ノードは、著しい信用を有する場合はデータを送信のみすることができる。信用は、データを処理することができる宛先ノードの能力を反映する。かかる信用ベース制御システムの１つが、Ｈｕｎｔ等による「Credit-Based Proposal for ATM Traffic Management」と題するＡＴＭ Ｆｏｒｕｍの文献＃９４−０６３２（１９９４年７月）に記載されている。
Braden等による「Resource Reservation Protocol (RSVP)」( IETF RFC 2205、1997年9月)という文献 LarryRobertsによる「EnhancedProportional Rate Control Algorithm」と題するATM文献 #94-0735 (1994年8月) Hunt等による「Credit-Based Proposal for ATM TrafficManagement」と題するATM Forumの文献 #94-0632 (1994年7月)

従来技術は、２つのノード間の関係、および、ソース・ノードによって用いるための宛先ノードによるリソースの割り当てについて考察しているが、これを、相互接続された複数のノード間でのリソースのリザーブにまで拡張する方法は提供していない。

本発明は、各請求項に記載された方法等である。

好ましくは、本発明のリソース・リザーブ・システムは、ネットワークにおける全てのノードに送信される「スロット・トークン（ＳＬＴ：Slotted Token）」と呼ばれる特別メッセージを発生するトークン発生ユニットを含む。ＳＬＴは、複数のサブ・フィールドを含み、各サブ・フィールドはネットワーク内のノードに関連付けられている。各サブ・フィールドは、ノードにおける各入力ポートごとの識別子（ＩＤ）と、ポートにおいて利用可能なリソースを示す値とを保持する。

好ましくは、各ノードには、リソース制御ユニット（ＲＣＵ：Resource Control Unit）が設けられている。これは、ノードにおいて入力ポートを監視し、ＳＬＴを介して、各入力ポートごとに利用可能なリソースを他のノードに伝達する。また、ＲＣＵは、前記ＲＣＵがデータを送りたい他のノードにおけるリソースをリザーブする。ＳＬＴは、ＳＬＴ送信専用の経路で、または、ノード間でデータを送信する相互接続経路で循環させることができる。最初のパス（pass）において、各ノードのＲＣＵは、入力ポートに利用可能なリソースを、その入力ポート用に確保されたＳＬＴ内のスペースに入力（書き込み）する。その入力ポートの全てについて情報を書き込んだ後、ＳＬＴは別のノードに転送され、この別のノードが同じことを行う。このプロセスは、ネットワーク内の全てのノードがＳＬＴに書き込みを行うまで継続する。ＳＬＴの第１または以降のパスで、各ＲＣＵは、特定の入力ポートにおいて必要なリソースをリザーブするため、この特定のポートに関連したスペースに記録された値からリソースを減算する。

従って、本発明は、複数のノード間での調整を行う。なぜなら、メッセージを用いて、全ノード間でのリソース可用性に関する情報を送信し、ノードは、メッセージ内のリソース可用性に関する情報を調節することによって、リソースをリザーブすることができるからである。

ここで、本発明の好適な実施形態について、以下の図面を参照しながら、一例としてのみ、詳細に説明する。

説明を簡略化するため、図面において、共通の要素は、同一の名称、番号、または他の記号によって識別する。

図１は、本発明の教示に従ったリソース・リザーブ通信システムのブロック図である。リソース・リザーブ通信システムは、通信サブシステムおよびリソース・リザーブ・サブシステムを含む。通信サブシステムは、Ｎｏｄｅ：０、Ｎｏｄｅ：１、・・・、Ｎｏｄｅ：（Ｎ−１）を含む。ノードは、相互接続媒体１２によって全て結合されている。通信サブシステムは、複数の異なる形態を取ることができる。例えば、通信サブシステムは、ルータ等のボックスとし、各ノードをルータ内のブレードとすることができる。かかる実施形態では、相互接続媒体１２は、ルータにおける背面であり、各ブレード間でデータを送信するためのバスまたは光チャネルを搭載することができる。同様に、通信サブシステムは、複数のボックスとし、各ボックスがノードを表し、ローカル・エリア・ネットワーク（ＬＡＮ）等の相互接続媒体１２またはインターネット等の他のタイプの通信ハイウエイによって相互接続することも可能である。換言すると、通信サブシステムは、ネットワーク内であるユニットから別のユニットにデータを送信しなければならないネットワークであれば、いかなるものとすることも可能である。

図１および５を参照すると、通信サブシステムの各ノードは、１つ以上の入力ポートおよび１つ以上の出力ポートを有する。具体的には、Ｎｏｄｅ：０は、ＩｎＰ：０と標示された入力ポートを有し、ＯＰ：０およびＯＰ：１と標示された出力ポートを有する。同様に、Ｎｏｄｅ：１およびＮｏｄｅ：（Ｎ−１）は、図に示すように標示された適切な入力ポートおよび出力ポートを有する。一般的な原理として、リソース・リザーブ通信システム１０におけるデータ・フローの方向は、矢印によって示す。Ｎｏｄｅ：０およびＮｏｄｅ：（Ｎ−１）間等のノード間のデータ送信は、相互接続媒体１２に沿って転送される。各入力ポートおよび出力ポートには、図において３辺記号として示すバッファが設けられている。３辺記号の水平線は、バッファに配置されるデータのスタックまたはキューを表す。また、他のタイプの記号を用いてバッファを表すことも可能である。

更に図１および５を参照すると、リソース・リザーブ・サブシステムは、ノードの各々に埋め込まれたリソース制御ユニットと、通信媒体１４（図１）および相互接続媒体１２（図５）によって相互接続されるトークン発生ユニットとを含む。通信媒体１４は、トークン発生ユニットによって発生された「スロット・トークン」（後に説明する）と呼ばれるメッセージを送信するいずれかの送信媒体とすることができる。図１において、スロット・トークンは、通信媒体１４等の専用伝送経路上で送信されるが、図５では、スロット・トークンは、データも送信する相互接続媒体１２上で送信されることに留意するべきである。リソース制御ユニット（ＲＣＵ）によって実行される機能は、ＲＣＵが埋め込まれたノードの入力ポートの監視を含み、他のノードに、その入力ポートに利用可能なリソースを伝達する。また、ＲＣＵは、処理のためデータを送信する必要がある他のノードにおけるリソースをリザーブする役目も担う。ＲＣＵは、特定のノードについてスロット・トークン（ＳＬＴ）内に保持される値から所望の量を減算することによって、別のノードにおけるリソースをリザーブする。トークン発生ユニット（ＴＧＵ）は、「スロット・トークン」と呼ばれる特別メッセージを発生し、これは、次いで、システムにおける全てのリソース制御ユニットに送信される。トークン発生ユニットは、図１および５では別個のユニットとして図示しているが、ＴＧＵの機能は、ノードＲＣＵに一体化し、これによって別個のＴＧＵの必要を無くすことも可能である。

ここで図１、２、および５を参照すると、スロット・トークン１６は、複数のサブ・フィールドを含み、その各々が、システム内のノードに関連した情報を保持する。ここで図２に移ると、Ｎｏｄｅ：０ Ｉｎｆｏと標示された第１のサブ・フィールドは、Ｎｏｄｅ：０に関する情報を保持する。同様に、Ｎｏｄｅ：１ Ｉｎｆｏと標示されたサブ・フィールドは、Ｎｏｄｅ：１に関する情報を搬送する等である。サブ・フィールド内の情報は、そのノードに関する入力ポートの識別子（i．ｄ．）およびその入力ポートで利用可能なリソースを表す指示を含む。図２を詳しく見ると、Ｎｏｄｅ：０のための第１のサブ・フィールドは、そのポートの識別子を保持するＩｎＰ：０と標示されたパーティションを有し、ＡｖＲｅｓＩｎＰ₀と標示されたパーティションは、その入力ポートで利用可能なリソースを搬送する。同様に、Ｎｏｄｅ₁では、ＩｎＰ：１、ＩｎＰ：２、ＩｎＰ：３と標示された３つの入力ポートがある。入力ポートＩＤに隣接したスペースに、入力ポートの各々について利用可能なリソースが記録されている。このスロット・トークン・メッセージを循環させながら、リソース制御ユニットは、そのポートに割り当てられたスペースに、ポート番号および関連リソースを入力することができる。同様に、リソース制御ユニットは、利用可能なリソースを調整して、要求元ノードからのデータを処理するためにノードが別のノードにリザーブさせたいリソースを示すことによって、他のポートにおけるリソースをリザーブすることができる。Ｎｏｄｅ：（Ｎ−１）のパーティション形成は、他のノードと同様であり、更に詳しくは述べない。

図３は、トークン発生ユニットの動作を示すフローチャートである。ブロック１８は、フローチャートへの入口である。ブロック１８において、プログラムはプロセスに入り、ブロック２０へ進み、初期化を行う必要があるか否かをチェックする。初期化を実行する場合、プロセスはブロック２２に入り、図２に示したフォーマットのスロット・トークン（ＳＬＴ）を発生する。次いで、プロセスはブロック２４へ進み、サブ・フィールドの各々における入力ポートのＩＤを初期値にセットする。次いで、プログラムはブロック２６へ進み、入力ポートの利用可能リソースを書き込むためにリザーブされたスペースをゼロに初期化する。次いで、プロセスは２８に入り、ＳＬＴを転送し、プログラムはループをブロック２０に戻る。ブロック２０において、初期化プロセスがうまく完了した場合、プログラムはブロック３０へ進み、ＳＬＴが到着したかをテストする。ＳＬＴが到着していれば、プログラムはブロック２８に下りる。ＳＬＴが到着していなければ、プロセスは、ブロック３０を出て、Ｎｏ経路に沿ってブロック２０に入る。

この動作において、トークン発生ユニット（ＴＧＵ）はスロット・トークンを発生し、これは、システムが作動している限り常に循環している。この円環が信頼性の高い転送機構を提供するので、スロット・トークンは消失したり破損したりしないと想定される。前述のように、スロット・トークンの各スロットは、単一の入力ポートに関連付けられており、その入力ポートに利用可能なリソースを示す。従って、ＩｎＰ：ｉについて、リソースは、スロット・トークンにおいてＡｖＲｅｓＩｎＰ：ｉと示される。最初にＴＧＵがＳＬＴを発生する時、ＴＧＵは、全てのＩｎＰ：ｉのＡｖＲｅｓＩｎＰ：ｉをゼロにセットする。更に、入力ポートについて利用可能なリソースの量は、ゼロ以上の段階的な値または設計者によって選択された他のいずれかの数量的表現によって表すことができると想定される。ノードのリソース制御ユニットがスロット・トークンを受信すると、リソース制御ユニットは、それが有する全てのＩｎＰ：ｉのＡｖＲｅｓＩｎＰ：ｉを更新する。例えば、Ｎｏｄｅ：１（図１）が、ＩｎＰ：１について１５０（リソースの単位）、ＩｎＰ：２について１００、ＩｎＰ：３について２００を割り当てていると仮定する。ノード１のＲＣＵが最初にＳＬＴを受信すると、これはＡｖＲｅｓＩｎＰ：１を１５０に、ＡｖＲｅｓＩｎＰ：２を１００に、ＡｖＲｅｓＩｎＰ：３を２００にセットする。

ノードのＲＣＵがＳＬＴを受信すると、ＲＣＵは、それを用いて、処理のためデータを送信する必要がある他のノードにおいてリソースをリザーブする。例えば、Ｎｏｄｅ：０（図１）が、この時点でまたは今後、ＩｎＰ：（Ｋ−２）またはＮｏｄｅ：（Ｎ−１）にデータを送信する必要があると仮定する。このため、Ｎｏｄｅ：０のＲＣＵがＳＬＴを受信すると、ＡｖＲｅｓＩｎＰ：２から必要な量を差し引くことによって、ＩｎＰ：（Ｋ−２）におけるリソースをリザーブする。例えば、Ｎｏｄｅ₀のＲＣＵがＩｎＰ：（Ｋ−２）に１０ユニットをリザーブしたい場合、ＡｖＲｅｓＩｎＰ：（Ｋ−２）から１０を引いた後に、ＳＬＴを転送する。リソースのリザーブの量は、スロット・トークン・メッセージにおいて利用可能と示されるものに限定されることに留意すべきである。

図４は、リソース制御ユニットの動作のフローチャートを示す。リソース制御ユニットは、状態マシーン、プログラム・プロセッサ組み合わせ論理、または同様のデバイスとして実施することができる。図４のフローチャートを用いて、本明細書において前述したようにリソース制御ユニットを発生することができる。

図４は、リソース制御ユニット（ＲＣＵ）の動作を示すフローチャートを示す。このフローチャートは、当業者によって、リソース制御ユニットを設計するために用いることができる。ブロック２８において、プログラムはプロセスに入り、ブロック３０へ進み、スロット・トークン（ＳＬＴ）が到着したか否かをチェックする。ＳＬＴが到着していない場合、プロセスは、Ｎｏ経路に沿って出てブロック５２に入り、プロセスは、入力ポート（ＩｎＰ）において受信されたいずれかのデータが処理されたか否かをチェックする。答えがＮｏである場合、プロセスはループを戻ってブロック３０に入る。応答がＹｅｓである場合、プログラムはブロック５０に入り、ポートで受信したフレームを処理した結果として解放されたリソースを、その特定のポートに利用可能なリソースに追加する。次いで、プロセスは、ループを戻って５０から３０に移る。

更に図４を参照すると、ブロック３０において答えがＹｅｓである場合、プログラムはブロック３２に入り、ＳＬＴが最初に到着したか否かをチェックする。ブロック３２からの応答がＮｏである場合、プロセスはブロック３６に下りる。ブロック３６において、最後にＳＬＴを受信してからの入力ポートＩｎＰ：ｉに関連した解放リソースの合計量（ＲｅＲｅｓＩｎＰ：ｉ）が、入力ポートＩｎＰ：ｉの利用可能リソース量に追加される。

ブロック３６から、プログラムはブロック３８に入る。ブロック３８において、最後にＳＬＴを受信してからの入力ポートＩｎＰ：ｉに関連した解放リソースの合計量（ＲｅＲｅｓＩｎＰ：ｉ）を、ゼロにリセットする。

ブロック３２では、ＲＣＵにおいてＳＬＴを最初に受信している場合、プログラムはブロック３４に入り、ＲＣＵはその入力ポートの各々で利用可能なリソースの値を挿入し、ブロック３８に下りる。

更に図４を参照すると、ブロック３８から、プログラムはブロック４０に下りて、ＲＣＵは、リザーブしたリソースが取り消しを必要とするか否かをチェックする。応答がＹｅｓである場合、プログラムはブロック４０を出てＹｅｓ経路に沿ってブロック４２に進み、全ての取り消されるポートのリザーブについて、その量を、その特定のポートに利用可能なリソースに追加する。ブロック４２から、プログラムはブロック４４に下りる。ブロック４０では、ＲＣＵがリザーブしたリソースを取り消すことを望まない場合、プログラムはブロク４４に下りる。ブロック４４において、ＲＣＵは、リソースをリザーブする必要があるか否かを決定する。答えがＹｅｓである場合、プログラムはブロック４６に下りて、リソース制御ユニットは、全ての入力ポートから、特定の入力ポートにおいて利用可能なリソースから必要な量を減算し、ブロック４８に入る。ブロック４８において、ＳＬＴを転送し、プログラムはループをブロック３０に戻り、上述のプロセスを繰り返す。

従って、ノードは、ここに記載した明示的なリソース・リザーブを実行しない限り、他のノードのリソースを用いることができない。ノードは、リザーブしたものよりも多く別のノードのリソースを用いてはならない。ノードがそのリザーブを「使い果たした」場合、もっとリソースを必要とするならば、新たなリザーブをする必要がある。後にＳＬＴを受信すると（すなわち初回の後）、ＲＣＵは、以下の方式に従って、それが有する全てのＩｎＰ：ｉについてＳＬＴのＡｖＲｅｓＩｎＰ：ｉ値を更新する。すなわち、ＲｅｓＩｎＰ：ｉを、最後にＳＬＴが受信されてからのＩｎＰ：ｉに関連する解放リソース合計量にする。全てのＩｎＰ：ｉについて、ＲＣＵは、ＳＬＴのＡｖＲｅｓＩｎＰ：ｉにＲｅｓＩｎＰ：ｉを追加してから、ＳＬＴを転送する。

例えば、Ｎｏｄｅ：１が、ＩｎＰ：（Ｋ−２）で受信されたデータの処理の結果として、５単位のリソースを解放した場合、ＲｅｓＩｎＰ：（Ｋ−２）に５を追加し、これは、次にＮｏｄｅ：（Ｎ−１）のＲＣＵがＳＬＴを受信する時にＡｖＲｅｓＩｎＰ：（Ｋ−２）に追加される。

ノードは、他のノードにおいてリザーブしたリソースについて、そのリザーブを取り消すことができる。ノードのＲＣＵがＳＬＴを受信すると、ＲＣＵは、それを用いて、必要としない場合がある他のノードのいずれかのリザーブしたリソースを取り消す。例えば、Ｎｏｄｅ₀（図１）がＩｎＰ：（Ｋ−２）において１０単位をリザーブし、４単位を取り消したいと仮定する。Ｎｏｄｅ：０のＲＣＵがＳＬＴを受信すると、ＡｖＲｅｓＩｎＰ：（Ｋ−２）の値に４を加える。

分散型の「通知ベース（Advertisement-based）」方式が提供される。受信者は、リソースを通知し、送信者は、分散方式で必要なものを取る。

本発明は、１つのリザーブ・メッセージによって、
・１送信者１受信者、
・１送信者多受信者、
・多送信者１受信者、
・多送信者多受信者、
のための動的リソース・リザーブをサポートする。受信者は、リソースのリザーブが行われた場合、送信者が誰であるかを知る必要はない。帯域内または帯域外で機能することができる。

本発明の教示に従った分散型の帯域外リソース・リザーブ・システムのブロック図である。 本発明の教示にしたがったスロット・トークン（ＳＬＴ）フォーマットの図表現である。 トークン発生ユニット（ＴＧＵ）における論理のためのフローチャートを示す。 リソース制御ユニット（ＲＣＵ）における論理のためのフローチャートである。 本発明の教示に従った分散型の帯域内リソース・リザーブ・ユニットのブロック図である。

Claims (6)

1. 複数のノードが相互接続された通信システムにおいてリソースをリザーブするための方法であって、 （ａ）ノードにおいて、各ノードを接続する経路を巡回するメッセージを受信するステップであって、前記メッセージは、相互接続された複数のノードのそれぞれに関連づけられ、各ノードにおける少なくとも１つのポートの識別子、および、前記少なくとも１つのポートにおいて利用可能なリソースに関連した情報を保持するための関連スペースを保持するための少なくとも１つのサブ・フィールドを有する、ステップと、 （ｂ）リソース制御ユニットによって前記メッセージを調べるステップと、 （ｃ）前記サブ・フィールドが、前記ノードにおける入力ポートのＩＤ（識別子）と合致する識別子を保持する場合、前記関連スペースに、前記少なくとも１つのポートにおいて利用可能なリソースを書き込み、前記識別子が、前記ノードがデータを送信しようとするポートのポートＩＤと合致する場合、前記スペースに記録されたリソース情報から必要なリソース量を減算して求められた値を当該スペースに書き込むことにより、当該ポートにおけるリソースをリザーブするステップと、前記メッセージを転送するステップとを備える、方法。
2. 前記ノードがリソースをリザーブしたポートへのデータの送信を終了したことに応じ、前記スペースに記録されたリソース情報に、リザーブしていたリソース量を追加するステップを更に備える、請求項１に記載の方法。
3. 前記ノードがリソースのリザーブを取り消すことを望む場合、前記スペースに記録されたリソース情報に、リザーブを取り消すリソース量を追加するステップを更に備える、請求項１に記載の方法。
4. 請求項１〜３のいずれかの方法を実行する通信ネットワークにおいて用いられるノード。
5. システムであって、 複数のノードであって、請求項４に記載のノードを含むノードと、 前記複数のノードを動作的に接続する相互接続媒体と、を備える、システム。
6. コンピュータ読み取り可能ストレージ媒体上にストアされたコンピュータ・プログラム・コードを備えるコンピュータ・プログラムであって、データ処理システム上で実行されると、前記データ処理システムに、請求項１〜３のいずれかの方法を実行するよう命令するコンピュータ・プログラム。

Images