(57)【要約】【課題】  ＱｏＳが保証されたマルチキャストツリーを効率的に生成することができる方法を提供する。【解決手段】  受信端Ｒ１からのリクエストに応えて、送信端Ｓ１から受信端Ｒ１までのダウンストリームパスに沿ってノードを経由してリザーブメッセージを転送する。ダウンストリームパスに沿った各ノード（Ａ〜Ｄ）は、ａ）リザーブメッセージを受信したらダウンストリームパスにおける当該ノードから次のダウンストリームノードまでのリンクに対してＱｏＳリソースを確保（リザーブ）し、かつマルチキャストリソースを設定するステップと、ｂ）リザーブメッセージを次のダウンストリームノードへ転送するステップとを実行し、ｃ）ダウンストリームパスに沿った各ノードにおいてＱｏＳリソースが確保され、かつマルチキャストリソースが設定されるまで、ステップａ）とステップｂ）を繰り返す。【選択図】  図２
2008228303.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにおけるマルチキャストセッションに対してＱｏＳ（サービス品質）リソースを確保してマルチキャストネットワークのリソースを設定する方法であって、
送信端から発するセッションをあるＱｏＳ要件によって受信しようとする受信端からのリクエストに応答して、前記送信端から前記受信端までのダウンストリームのパスに沿って当該ネットワークのノードを経由してリザーブメッセージを転送するステップを含み、前記ダウンストリームのパスに沿った各ノードが、
ａ）前記リザーブメッセージを受信したらそれに応えて、前記ダウンストリームのパスにおける当該ノードから次のダウンストリームノードまでのリンクに対して、ＱｏＳリソースを確保してマルチキャストリソースを設定するステップと、
ｂ）前記リザーブメッセージを前記次のダウンストリームノードへ転送するステップと
を実行し、
ｃ）前記送信端から前記受信端までの前記ダウンストリームパスに沿った各ノードにおいて、前記ＱｏＳリソースが確保されて前記マルチキャストリソースが設定されるまで、前記ステップａ）と前記ステップｂ）を繰り返す方法。
【請求項２】
要求されたセッションに対して、ＱｏＳリソースが既に確保されており、マルチキャストリソースが既に設定されている場合には、ＱｏＳリソースの確保とマルチキャストリソースの設定とを実行することなく次のダウンストリームノードへ前記リザーブメッセージを転送するステップを更に含む、請求項１に記載の方法。
【請求項３】
前記マルチキャストリソースの設定は、該設定が実行されるべき前記ノードから次のダウンストリームノードへのリンクに対してマルチキャストグループのＩＰアドレスを設定するステップを含む、請求項１または２に記載の方法。
【請求項４】
前記マルチキャストリソースの設定は、マルチキャストチャネルをマルチキャストセッションとなるべきセッションに割り当てるステップを含み、前記マルチキャストチャネルはそのチャネルの送信端のアドレスとマルチキャストグループのＩＰアドレスとを含む、請求項１〜３のいずれか１項に記載の方法。
【請求項５】
ある特定のセッションに対する前記リザーブメッセージを受信するノードにおいてＱｏＳリソースの確保とマルチキャストリソースの設定とが既に実行されている場合には、現在要求されているセッションに対する次のダウンストリームノードがＱｏＳリソースの確保とマルチキャストリソースの設定とが既に行われているノードと同じであるかどうかをチェックし、同じでなければ、要求されているセッションの次のダウンストリームノードへのリンクに対してＱｏＳリソースの確保とマルチキャストリソースの設定とを実行することによりマルチキャストツリーにおける新たな分岐を構築するステップを更に含む、請求項１〜４のいずれか１項に記載の方法。
【請求項６】
マルチキャストセッションは、そのセッションの送信端、そのセッションのＱｏＳ要件およびそのマルチキャストグループＩＰアドレスを含むセッションオブジェクトによって特定されるものである、請求項１〜５のいずれか１項に記載の方法。
【請求項７】
前記マルチキャストリソースの設定は、
当該ノードからみて１つ前のアップストリームノードのＩＰアドレスを格納するステップと、
１つ前のアップストリームノードのＩＰアドレスを使用して、ＱｏＳリソースが確保され、マルチキャストリソースが設定されたパスをアップストリームの向きにたどっていって、そのパスに沿ってマルチキャストリソースの設定を完了するステップと
を含む、請求項１〜６のいずれか１項に記載の方法。
【請求項８】
前記ＱｏＳリソースの割当はクラスベースの確保スキームによって実行され、この際、フローがリソースを要求するサービスクラスに対して最初に最小バンド幅が割り当てられるようになっており、更に、このクラスにおいてフローが要求するリソース必要量のその後の進展に応じて、割当のバンド幅がフローによって要求される量と等しくなるように増減される、請求項１〜７のいずれか１項に記載の方法。
【請求項９】
前記リザーブメッセージはリソースの変更またはリリースを要求し、斯かる変更またはリリースのリクエストはそのリクエストが受信されたネットワークエージェントから受信端がネットワークにアクセスするネットワークエージェントに向かうダウンストリーム方向に同じ方法によって処理される、請求項１〜８のいずれか１項に記載の方法。
【請求項１０】
前記リザーブメッセージはリフレッシュフラグがセットされたリフレッシュメッセージであり、このリフレッシュメッセージがアクセスエージェントに向けて定期的にダウンストリームの向きに送信される、請求項１〜９のいずれか１項に記載の方法。
【請求項１１】
前記リザーブメッセージは、各ネットワークエージェントが前記リクエストおよび前記リザーブメッセージをインターセプトして処理することができるように、ルータ警告オプションがセットされた状態により送信される、請求項１〜１０のいずれか１項に記載の方法。
【請求項１２】
前記リザーブメッセージがネットワークエージェントに沿って転送され、これらのネットワークエージェントはドメインの境界に位置するエッジエージェントとドメインの中心部に位置するコアエージェントとから成り、ドメイン間の接続が前記エッジエージェントを通じてのみ確立することが可能であり、
前記コアエージェントによって格納されるステート情報は、
別のネットワークエージェントに繋がる各出力インタフェース毎に、ＱｏＳステートとして、ＱｏＳクラス、リクエスタである入口エージェントのＩＰアドレス、および指定バンド幅を格納するほかに、
別のネットワークエージェントに繋がる各出力インタフェース毎に、マルチキャストステートとして、送信端ＩＰアドレスおよびグループＩＰアドレスを格納し、
前記エッジエージェントは、これらに加えて更に、各セッションおよび各フロー識別子毎に、ＱｏＳクラス、送信端ＩＰアドレス、マルチキャストグループＩＰアドレス、所要バンド幅、出口ＩＰアドレス、アクセスエージェントのＩＰアドレスおよびＱｏＳパスを格納する、請求項１〜１１のいずれか１項に記載の方法。
【請求項１３】
ネットワークにおけるマルチキャストセッションに対してＱｏＳ（サービス品質）リソースを確保してマルチキャストネットワークリソースを設定する装置であって、
受信端が送信端から発するセッションをあるＱｏＳ要件によって受信しようとする受信端からのリクエストを受信すると、それに応えて前記送信端から前記受信端までのダウンストリームパスに沿って当該ネットワークのノードを経由してリザーブメッセージを転送するモジュールを具備し、前記ダウンストリームパスに沿った各ノードは、
ａ）前記リザーブメッセージを受信したらそれに応えて、前記ダウンストリームパスにおける当該ノードから次のダウンストリームノードまでのリンクに対してＱｏＳリソースを確保してマルチキャストリソースを設定するステップと、
ｂ）前記リザーブメッセージを前記次のダウンストリームノードへ転送するステップと
を実行し、
ｃ）前記送信端から前記受信端までの前記ダウンストリームパスに沿った各ノードにおいて、前記ＱｏＳリソースが確保されて前記マルチキャストリソースが設定されるまで、前記ステップａ）と前記ステップｂ）を繰り返す、装置。
【請求項１４】
請求項２〜１２のいずれか１項に記載された方法を実行するモジュールを更に具備する請求項１３に記載の装置。
【請求項１５】
コンピュータ上において実行されたときにこのコンピュータが請求項１〜１２のいずれか１項に記載された方法を実行することを可能にするプログラムコードから成るコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおけるマルチキャストセッションに対して、ＱｏＳリソースを確保（リザーブ）し、マルチキャストネットワークリソースを設定する方法および装置に関する。
【背景技術】
【０００２】
異種ネットワークにわたるユーザのグループへのＱｏＳ（quality of service）センシティブなマルチキャストセッションの実現は、送信端（senderまたはsource）から受信端（receivers）へのパスに設定（install）されたネットワーククラスのＱｏＳ特性を考慮したマルチキャストツリー（multicast trees）の制御を必要とすることから、骨の折れる仕事である。さらに、ネットワーク能力が異なるマルチキャスト環境とマルチキャストトランスポート技術が異なるドメインにおいてＱｏＳ保証が必要とされる。また異種性サポートに加えて、データパスは、ＱｏＳリソースの割当とルートが非対称なネットワークにおけるマルチキャスト制御を可能にする、送信端送信端から受信端へのルートにおけるマルチキャストセッションのための約束されたＱｏＳ要件を最低限満足しなければならない。
【０００３】
確保（リザーブ）されたリソースによってセッションコンテンツをユーザのグループ（groups）へ配布するためにＱｏＳアプローチとマルチキャストアプローチとを共存させることは、集中型または分散型ＱｏＳアウェアなマルチキャストルーティングアプローチがＱｏＳ制約条件（例えば利用可能なバンド幅および／またはサービスクラス）を考慮して送信端と受信端との間の最良のパスを計算する状況に対して取り組まれてきた。しかしながら、これらのアプローチではセッションコンテンツは、ＱｏＳリソースの確保（QoS resource reservation）を遂行することなく、選択されたパスに構築されたマルチキャストツリーに沿って転送される。さらに、既存のソリューションは２パスシグナリング（信号伝達）スキーム（two-pass signalling scheme）を通じてＱｏＳリソースを確保（リザーブ）し、マルチキャストステートを導入するが、これはＱｏＳリソースを制御するための１つのリソース確保スキームと、既に確保（リザーブ）されたパスにおけるマルチキャストツリーの構築を制御するための別のソリューションの使用を必要とする。シングルパスシグナリングスキームと比較すると、セッションセットアップ遅延は追加のシグナリングオーバヘッドによって増大する可能性があり、リソース確保とマルチキャストツリーの構築に異なるソリューションを使用することはシステムの複雑さのほかにステートオーバヘッド（state overhead）を増大させる可能性がある。さらに、ＱｏＳおよびマルチキャストリソースを設定するための異なるシグナリング方向（例えばダウンストリームとアップストリーム）は、ルーティングの非対称性（ユニキャストルーティングによって異なるパスが割り当てられることがある）に影響される可能性がある。図１Ａに示すように、送信端送信端から受信端へのパス上に、クラスベースのネットワークにおけるＱｏＳリソースが割り当てられている。図１はこの様子を入口ノード（この入口ノードには別のアップストリームネットワークについての図示されていない出口ノードまたは図示されていない送信端が接続されている場合がある）から出口ノード（この出口ノードには図示されていない受信端または図示されていないダウンストリームネットワークが接続されている場合がある）へのパスに対して示している。ＱｏＳを確保（リザーブ）するためのシグナリングは入口ノード（ingress node）を発し、出口ノード（egress node）に到達するまでダウンストリームの向きにコアノード（core nodes）を経由して進む。ＱｏＳリソースを確保（リザーブ）することが到来するＱｏＳシグナリングメッセージによって要求されると、各ステーション毎に、実際に確保（リザーブ）が行われ、その結果がアップストリーム方向に返信される。この手続きは入口ノードを発して出口ノードに向かうパス（何らかのユニキャストルーティングプロトコルによって決定される）に沿って実行される。
【０００４】
他方、図１Ｂに示すように、マルチキャストのリソース（multicast resources）は、受信端から送信端に向かってパス上に割り当てられる。言い換えると、マルチキャストのリソースの設定（コンフィギュレーション）は出口ノードから開始し、入口ノードに向かってアップストリームの向きに進む。このとき、各ノードにおいてマルチキャストリソースは、例えばセッションのマルチキャストグループのＩＰアドレスとこのセッションの送信端を各ノードにおいて定める（setting）ことによって設定される。マルチキャストのリソースの設定が行われるパスも、何らかのユニキャストルーティングプロトコルに基づいて決定される。
【０００５】
送信端と受信端との間においてユニキャストルート（unicast routes）が異なる２方向（図１Ａにおけるような送信端から受信端への方向と、図１Ｂにおけるような受信端から送信端への方向）において決定されるような場合には、２つのルートは一致せず異なっている蓋然性が大きい。これは、ＱｏＳの確保がマルチキャストツリーに対して行われるべき場合には、ＱｏＳが確保（リザーブ）されたルートとマルチキャストのルートとが異なる可能性があることを意味する。言い換えると、マルチキャストツリーは確保済みのパス（reserved-path）内に設定されない場合があり、結果的に非ＱｏＳアウェアなマルチキャストツリーがもたらされる。この様子を図１Ｃに示す。この図は、送信端から受信端へのパスは逆方向とは異なる場合があるため、ルートが非対称であるために、ＱｏＳアウェアなマルチキャストツリーの構築をあきらめざるを得ない場合があることを示している。
【０００６】
いくつかの研究団体によって最近提案されたソリューションのほとんどは、リソースの確保にシングルパスのシグナリングスキーム（single-path signalling schemes）を利用するものであり、単純化するためにマルチキャストサポートなしに考え出された。例えば、ＱｏＳ−ＮＳＩＳシグナリングレイヤプロトコル（ＱｏＳ−ＮＳＩＳ：QoS-NSIS Signalling Layer Protocol）（例えば非特許文献１参照）はシグナリングの交換を目標としており、そこではメッセージはＮＳＩＳ（Next Steps in Signalling）フレームワーク（例えば非特許文献２参照）をサポートするネットワークにおける到来ユニキャストフローが要求するＱｏＳリソースについての情報を伝える。
【０００７】
いくつものアプローチがＱｏＳ保証付きでマルチキャストセッションを提供するためにＱｏＳおよびマルチキャストを共存使用する問題に取り組んできた。従前の集中型または分散型ＱｏＳマルチキャストルーティングアプローチ（例えば非特許文献３参照）は、最良のパスを計算し、選択されたパス上にそのパス上のリソースを確保（reserve）することなくマルチキャストツリーを生成するといった形で働くが、このためバンド幅が動的に変更されるネットワークには不向きである。
【０００８】
マルチキャストとリソース確保をサポートする既存のアプローチ（例えば非特許文献４または非特許文献５参照）は、２パスシグナリングスキーム（two-pass signalling scheme）に基づいて、別個にＱｏＳアウェアなマルチキャストツリーを生成する働きをする異なるソリューションを実現する。マルチキャストプロトコル（multicast protocol）は送信端と宛先との間の最良のルートを計算し（例えばネットワークリソースの利用可能性と伝搬遅延特性とに基づいて最短経路を見つける）、条件に合ったパスにマルチキャストツリーを生成するのに対して、リソース確保プロトコル（resource reservation protocol）は、ネットワークをプローブメッセージによってフラディング（flooding）することによって確保済みのパス（reserved-path）を見つけ、それをマルチキャストツリーと合併する。これらのアプローチは、リソースをフラディング（flooding）、探索（probing）および確保（reserving）するための多数のシグナリングメッセージのために、シグナリングのオーバヘッドとセッションセットアップの遅延とが増大するという欠点を有する。さらに、これらのソリューションは、ＱｏＳおよびマルチキャストリソースを提供するための異なるプロトコル／機構を必要とするために、ネットワークがより複雑なものとなる。
【０００９】
ＯＳＭＡＲ（Overlay for Source-specific Multicast in Asymmetric Routing）の提案は非対称ルーティングの環境におけるＱｏＳとマルチキャストの問題を解決することを目指している（例えば非特許文献６参照）。この提案において、各ルータのＭＲＩＢ（Multicast Routing Information Base）は、要求されたマルチキャストソースそれぞれのネットワークに達する次ホップ（next hop）のアドレスによって更新される。さらに、既に選択されたパスにマルチキャストツリーを生成するために、受信端近くのアクセスルータにおいてＰＩＭ−ＳＳＭがトリガーされる。しかしながら、このソリューションはＰＩＭ−ＳＭおよびＰＩＭ−ＳＳＭマルチキャストモデルの環境を目指しているだけで、到来するセッションのためのリソースは確保（リザーブ）せず、ＱｏＳおよびマルチキャストを制御するのに別々のスキームの使用を求める。
【非特許文献１】A. McDonald, "NSLP for Quality-of-Service signalling", The Internet Engineering Task Force - IETF, Internet Draft Jun 2006
【非特許文献２】S. v. d. Bosch, "Next Steps in Signalling (NSIS): Framework", The Internet Engineering Task Force - IETF, RFC4080, Jun 2005
【非特許文献３】Z. Li and P. Mohapatra, "QMBF: A QoS-aware Multicast Routing Protocol", Computer Communication, 2003
【非特許文献４】技術仕様書ＲＦＣ２２０５
【非特許文献５】J. Cui, L. Lao, M. Faloutsos, and M. Gerla, "AQoSM: scalable QoS multicast provisioning in DiffSery networks". Computer Networks 50, January 2006
【非特許文献６】P. Mendes, "OSMAR: Overlay for Source-specific Multicast in Asymmetric Routing Environments," Technical Report, DoCoMo Euro-Labs, 2004
【発明の開示】
【００１０】
本発明は、上記課題を解決するため、ネットワークにおけるマルチキャストセッションに対してＱｏＳ（サービス品質）リソースを確保（リザーブ）してマルチキャストネットワークのリソースを設定するための方法を提供する。本方法は、
送信端（ソース）から発するセッションをあるＱｏＳ要件によって受信しようとする受信端（レシーバ）からのリクエストに応答して、前記送信端から前記受信端までのダウンストリームのパスに沿って当該ネットワークのノードを経由してリザーブメッセージを転送するステップを含み、前記ダウンストリームのパスに沿った各ノードが、
ａ）前記リザーブメッセージを受信したらそれに応えて、前記ダウンストリームのパスにおける当該ノードから次のダウンストリームノードまでのリンクに対して、ＱｏＳリソースを確保してマルチキャストリソースを設定するステップと、
ｂ）前記リザーブメッセージを前記次のダウンストリームノードへ転送するステップと
を実行し、
ｃ）前記送信端から前記受信端までの前記ダウンストリームパスに沿った各ノードにおいて、前記ＱｏＳリソースが確保されて前記マルチキャストリソースが設定されるまで、前記ステップａ）と前記ステップｂ）を繰り返す、ように構成される。
【００１１】
同じ方向の同じパスに沿ってＱｏＳリソース（QoS resources）を確保（リザーブ）し、マルチキャストリソース（multicast resources）を設定することにより、マルチキャストセッションと保証されたＱｏＳとの間の異なるパスが避けられる。このように、ＱｏＳが保証されたマルチキャストツリーの効率的な生成が可能となる。
【００１２】
本方法は、１つの態様として、要求されたセッションに対して、ＱｏＳリソースが既に確保されており、マルチキャストリソースが既に設定されている場合には、ＱｏＳリソースの確保とマルチキャストリソースの設定とを実行することなく次のダウンストリームノードへ前記リザーブメッセージを転送するステップを更に含む。
【００１３】
これによりリソースとシグナリング（信号伝達）の不要な浪費が避けられる。
【００１４】
本方法の１つの態様として、前記マルチキャストリソースの設定は、該設定が実行されるべき前記ノードから次のダウンストリームノードへのリンクに対してマルチキャストグループＩＰアドレスを設定することを含む。
【００１５】
送信端（ソース）から受信端（レシーバ）に向かうパスに沿ってマルチキャストグループＩＰアドレスを設定（セッティング）することは、マルチキャストリソースを設定し、マルチキャストツリーを生成する有効な方法である。
【００１６】
本方法の１つの態様として、前記マルチキャストリソースの設定は、マルチキャストチャネルをマルチキャストセッションとなるべきセッションに割り当てるステップを含み、前記マルチキャストチャネルはそのチャネルの送信端のアドレスとマルチキャストグループのＩＰアドレスであるアドレスとを含む。
【００１７】
本方法は、１つの態様として、ある特定のセッションに対する前記リザーブメッセージを受信するノードにおいてＱｏＳリソースの確保とマルチキャストリソースの設定とが既に実行されていた場合には、現在要求されているセッションに対する次のダウンストリームノードがＱｏＳリソースの確保とマルチキャストリソースの設定とが既に行われているノードと同じであるかどうかをチェックし、同じでなければ、要求されているセッションの次のダウンストリームノードへのリンクに対してＱｏＳリソースの確保とマルチキャストリソースの設定とを実行することによりマルチキャストツリーにおける新たな分岐を構築するステップを更に含む。
【００１８】
こうして、マルチキャストツリーはＱｏＳリソースの確保が統合された方法によって生成することが可能である。
【００１９】
本方法の１つの態様として、マルチキャストセッションは、そのセッションの送信端、そのセッションのＱｏＳ要件およびそのマルチキャストグループＩＰアドレスを含むセッションオブジェクト（session object）によって特定される。
【００２０】
こうして、セッションとその対応するＱｏＳリソースおよびその対応するマルチキャストリソースは識別することが可能であり、同じセッションに対してマルチキャストルートまたはツリーが既に存在しているかどうかを認識することができる。
【００２１】
本方法の１つの態様として、前記マルチキャストリソースの設定は、
当該ノードからみて１つ前のアップストリームノードのＩＰアドレスを格納するステップと、
１つ前のアップストリームノードのＩＰアドレスを使用して、ＱｏＳリソースが確保（リザーブ）され、マルチキャストリソースが設定されたパスをアップストリームの向きに辿っていって、そのパスに沿ってマルチキャストリソースの設定を完了するステップとを含む。
【００２２】
こうして、マルチキャストツリーの管理（メンテナンス）は、ＰＩＭ−ＳＳＭといった外部機構に“外部委託（アウトソーシング）”することが可能である。本方法は従って既存のマルチキャストツリー管理アプローチと両立可能である。
【００２３】
本方法の１つの態様として、前記ＱｏＳリソースの割当はクラスベースの確保スキームによって実行され、この際、フローがリソースを要求するサービスクラスに対して最初に最小バンド幅が割り当てられるようになっており、更に、このクラスにおいてフローが要求するリソース必要量のその後の進展に応じて、割当のバンド幅が、フローが要求する量と等しくなるように増減される。
【００２４】
これによりリソースの効率的な割当が可能となる。
【００２５】
本方法の１つの態様として、前記リザーブメッセージはリソースの変更またはリリースを要求し、斯かる変更またはリリースのリクエストはそのリクエストが受信されたネットワークエージェントから受信端がネットワークにアクセスするネットワークエージェントに向かってダウンストリームの向きに同じ方法によって処理される。
【００２６】
本方法の１つの態様として、前記リザーブメッセージはリフレッシュフラグがセットされたリフレッシュメッセージであり、このリフレッシュメッセージはアクセスエージェントに向かって定期的にダウンストリームの向きに送信される。
【００２７】
これは、例えば、ノードが移動または故障する場合があること、あるいはセッション若しくはフローに対するＱｏＳ要件が変わる場合があることを考慮している。
【００２８】
本方法の１つの態様として、前記リザーブメッセージは、各ネットワークエージェントが前記リクエストおよび前記リザーブメッセージをインターセプトして処理することができるように、ルータ警告オプションがセットされた状態で送信される。
【００２９】
これにより、パス内の各ノードはメッセージを検査し、処理することが可能となる。
【００３０】
本方法の１つの態様として、前記リザーブメッセージはネットワークエージェントに沿って転送され、これらのネットワークエージェントはドメインの境界に位置するエッジエージェントとドメインの中心部に位置するコアエージェントとから成り、ドメイン間の接続は前記エッジエージェントを通じてのみ確立することが可能であり、前記コアエージェントによって格納されるステート情報は、
別のネットワークエージェントに繋がる各出力インタフェース毎に、ＱｏＳステートとして、ＱｏＳクラス、リクエスタである入口エージェントのＩＰアドレス、および指定バンド幅を格納するほかに、
別のネットワークエージェントに繋がる各出力インタフェース毎に、マルチキャストステートとして、送信端ＩＰアドレスおよびグループＩＰアドレスを格納し、前記エッジエージェントは、これらに加えて更に、
各セッションおよび各フロー識別子毎に、ＱｏＳクラス、送信端ＩＰアドレス、マルチキャストグループＩＰアドレス、所要バンド幅、出口ＩＰアドレス、アクセスエージェントのＩＰアドレスおよびＱｏＳパスを格納する。
【００３１】
本発明は、上記課題を解決するため、ネットワークにおけるマルチキャストセッションに対してＱｏＳ（サービス品質）リソースを確保（リザーブ）し、かつマルチキャストネットワークリソースを設定（コンフィグ）するための装置も提供する。本装置は、
受信端（レシーバ）が送信端（ソース）から発するセッションをあるＱｏＳ要件によって受信しようとする受信端からのリクエストを受信すると、それに応えて、前記送信端から前記受信端までのダウンストリームパスに沿って当該ネットワークのノードを経由してリザーブメッセージを転送するモジュールを具備し、前記ダウンストリームパスに沿った各ノードは、
ａ）前記リザーブメッセージを受信したらそれに応えて、前記ダウンストリームパスにおける当該ノードから次のダウンストリームノードまでのリンクに対してＱｏＳリソースを確保してマルチキャストリソースを設定するステップと、
ｂ）前記リザーブメッセージを前記次のダウンストリームノードへ転送するステップとを実行し、
ｃ）前記送信端から前記受信端までの前記ダウンストリームパスに沿った各ノードにおいて、前記ＱｏＳリソースが確保されて前記マルチキャストリソースが設定されるまで、前記ステップａ）と前記ステップｂ）を繰り返すように構成される。
【００３２】
本装置は上記いずれかの態様の方法を実行するためのモジュールを更に具備する。
【００３３】
上記の形態に加え、本発明は、上記課題を解決するため、コンピュータ上において実行されたときにこのコンピュータが上記いずれかの態様の方法を実行することを可能にするプログラムコードから成るコンピュータプログラムも提供する。
【発明を実施するための最良の形態】
【００３４】
以下、本発明の実施の最良の形態を添付図面を参照して詳細に説明する。その前にまず本願において用いられる用語について説明しておく。
【００３５】
・アクセスルータ（access router）：受信端が属するアクセスネットワーク（access network）にリンクしたルータをいう。
・入口エッジデバイス（ingress edge device）：所与のフローにとってネットワークへの入口となるネットワークの境界（エッジ）デバイスが入口エッジデバイスである。
・出口エッジデバイス（egress edge device）：所与のフローにとってネットワークからの出口となるネットワークの境界（エッジ）デバイスが出口エッジデバイスである。
・ダウンストリーム（downstream）：入口ノードから出口ノードまたはアクセスノードへの方向をさす。
・アップストリーム（upstream）：出口ノードから入口ノードへの方向のことである。
・ユニキャストルーティング情報ベース（Unicast Routing Information Base）（略してユニキャストＲＩＢ）：ユニキャストトポロジーテーブル（unicast topology table）である。
・マルチキャストルーティング情報ベース（Multicast Routing Information Base）（略してマルチキャストＲＩＢまたはＭＲＩＢ）：一般的にユニキャストＲＩＢから得られるマルチキャストトポロジーテーブル（multicast topology table）。ＰＩＭプロトコルはＭＲＩＢを使用してJoin/Pruneメッセージをどこに送信するかを決定する。
・確保済みのパス（Reserved Path）：Reserveメッセージがリソースを制御したパスのこと。
【００３６】
以下、本発明の実施形態を説明する。
【００３７】
実施の一形態として、シングルパスＱｏＳリソース確保とマルチキャストツリー制御のためのソリューションが提供される。このソリューションはクラスベースのＱｏＳアウェアなドメインにおいてマルチキャストセッションにおいてコンテンツが効率的に流通することを可能にするものであり、マルチキャストリソースはＱｏＳリソースを確保（リザーブ）する働きをするときに設定される。マルチキャストリソースの設定（コンフィギュレーション）はマルチキャストツリーの生成と関係し、ＱｏＳリソースはデータパスに沿った各ノードの上において選択されたサービスクラスに対するある量のバンド幅を確保することと関係がある。この機構は好ましくはオープンインタフェースをサポートすべきであり、それにより異なるプロトコルおよび機構との容易な相互作用と直接的な展開が同時に可能になる。
【００３８】
本発明の実施の一形態を図２を参照して説明する。この例では、送信端（source）Ｓ１はあるセッションを送信する準備が整っていることを広報する。この広報（advertisement）は受信端Ｒ１に到達し、受信端Ｒ１はそのセッションへの参加を決める。実際のマルチキャスト伝送とは無関係な方法によって送信端に到達することができるJoinリクエスト（参加リクエスト）を通じて、送信端Ｓ１にそのセッションを受信する意思があることを通知する。Joinリクエストは受信端Ｒ１が満足させたいＱｏＳ要件も示す。
【００３９】
その後、実施の一形態によるリソース確保メカニズムが開始される。送信端Ｓ１はReserveメッセージをノードＡに送信することによって確保（リザーブ）の手続きを開始する。ReserveメッセージはＱｏＳ要件の指示とセッションの定義を含む。次にノードＡにおいてＱｏＳ要件に基づいてＱｏＳリソース確保（QoS resource reservation）が実行され、更にマルチキャストリソース設定（multicast resource configuration）が実行される。
【００４０】
続いて、手続きはReserveメッセージをノードＢへダウンストリームの向きに転送（フォワード）することによって継続される。ノードＢにおいてもＱｏＳ確保（QoS reservation）が実行され、マルチキャスト設定が実行される。完了後、ReserveメッセージはノードＣに転送され、ノードＣもＱｏＳ確保とマルチキャスト設定を実行する。続いて、Reserveメッセージは受信端Ｒ１に向かってノードＤにダウンストリームの向きに転送され、ノードＤもＱｏＳ確保とマルチキャスト設定を実行する。
【００４１】
このように、ＱｏＳ確保はマルチキャスト設定（multicast configuration）と同じパスに沿って同じ方向（送信端から受信端への方向）に実行される。従来技術とは対照的にこれはＱｏＳ確保がそれに沿って実行されるルートとマルチキャスト設定がそれに沿って実行されるルートが異なっていないことを保証し、その結果、マルチキャストパスに沿ったＱｏＳ確保が保証される。
【００４２】
実施の一形態によれば、ノードにおけるマルチキャストの設定はそのノードにおいてマルチキャストグループＩＰアドレスを設定することから成る。実施の一形態において、斯かるマルチキャスト設定はマルチキャストセッション（multicast session）が設定されるべき出力インタフェース（outgoing interface）に対して、言い換えると当該ノードから次のダウンストリームノードへのリンクに対して実行される。グループＩＰアドレスは利用可能なマルチキャストグループアドレスのプール（pool）から選ぶことができる。送信端ＩＰアドレス（図２において送信端Ｓ１のアドレス）、セッション識別子（特定のセッションを識別する）、およびそれが設定された出力インタフェースと一緒に、それはある特定のダウンストリーム方向（次のダウンストリームノードへの方向）のノードにおけるＳＳＭ（source specific multicast）セッションを定義する。
【００４３】
このように、ある特定ノードにおけるマルチキャストセッションは、ＱｏＳ確保とともに設定することが可能である。図２に示されたＱｏＳ確保とマルチキャスト設定がそれに沿って実行されるパス（ノードＡ−Ｂ−Ｃ−Ｄ）は任意のユニキャストルーティングプロトコルによって決定することができる。
【００４４】
マルチキャスト設定とＱｏＳ確保がある特定ノードにおいて起こると、設定されたマルチキャストセッションに他のノードが参加することが許される。例えば受信端Ｒ２が同じセッションに参加する意思がある場合にはそれは対応するリクエストを送信端Ｓ１に送信する。そこからReserveリクエスト（図２には点線により示されている）がノードＡに転送（フォワード）され、そこで、要求されたマルチキャストセッションがこのノードＡに既に存在すること、言い換えると、マルチキャスト設定およびＱｏＳ確保が何らかのユニキャストプロトコルに基づいて決定された次のダウンストリームノード（ノードＢ）へのリンクに対して既に実行されていることが決定される。従って、それ以上何もアクションを起こす必要はなく、Reserveリクエストメッセージは（点線が示すように）次のダウンストリームノードＢに転送（フォワード）されるだけでよい。ここでＱｏＳ保証付きの要求されたセッションは、しかしながら、いま要求されたセッションに対して何らかのユニキャストルーティングプロトコルによって決定された次のダウンストリームノードＦに対してではなく、ノードＢからＣへのリンクに対して存在することが決定される。このため、ＱｏＳ確保はノードＢからＦへのリンクに対してまだ実行される必要があり、更にマルチキャスト設定が実行される必要がある。これは例えば、ノードＡからＢへのリンクとノードＢからＣへのリンクに対して既に設定されているマルチキャストグループＩＰアドレスをノードＢからＦへのリンクに対しても設定することによって実行することができる。これはノードＡからＤに既に存在したＱｏＳ保証されたマルチキャストセッションに対してノードＢからＦに延びる新たな分岐を設けることに相当する。続いてこの手続によってＱｏＳ確保とマルチキャスト設定とがノードＦから受信端Ｒ２へのリンクに対して実行され、そのようにして送信端から受信端へのダウンストリームパスに沿ったＱｏＳ確保とマルチキャストリソース設定が完了する。
【００４５】
実施の一形態による全体の手続きの流れを図３に概略的に示す。Reserveリクエストを最初にフォワードした（ステップ３２０）後、ＱｏＳリソース確保とマルチキャストリソース設定とが既に行われているかどうかをチェックする（ステップ３３０）。行われている場合、Reserveメッセージは次のノードへ転送される（ステップ３２０）。行われていない場合、ステップ３４０において、ＱｏＳリソース確保とマルチキャストリソース設定が実行される。ステップ３５０において、ＱｏＳリソース確保とマルチキャストリソース設定が全体のパスに対して既に行われているかどうかがチェックされる。行われていない場合、手続きの流れはステップ３２０に戻る。行われていれば、手続きは終了する。
【００４６】
次に更なる実施形態について説明する。実施の一形態によれば、バンド幅が動的に変更され、ルーティングが非対称な異種環境にわたってＱｏＳリソース確保とマルチキャストツリー制御を遂行するためのシングルパスリソース確保＆マルチキャストツリー制御（Single-pass Resource Reservation and Multicast Tree Control）（略してReCast）と呼ばれるフレキシブルなソリューションが提供される。以下、この機構（メカニズム）を“ReCast”機構と呼び、それはＱｏＳおよびマルチキャストリソースをシングルパスシグナリングスキームを通じて同時に制御することが可能である。後述する更なる実施形態によれば、ReCast機構はマルチキャストツリーを生成するためのＱｏＳパスを指示することによって外部のマルチキャストプロトコルと相互作用するように構成することができる。
【００４７】
以下の説明から明らかとなるように、ReCast機構は“ReCast”エージェントと呼ばれる、それらの機能性によりReCast機構を実現するネットワークエージェントに実装される。ネットワークエージェントはネットワークのノードに実装することができる。
【００４８】
ReCastシングルパススキームのおかげで非対称ルートのネットワークにおけるＱｏＳ保証付きのセッションコンテンツの配布が可能であり、効率的な形状のマルチキャストツリーの構築が可能となる。さらに、バンド幅のキャパシティの挙動が動的なネットワークにおいてＱｏＳリソースとマルチキャストツリーを制御するために統一したソリューションが使用されるために、シグナリングオーバヘッド（信号オーバヘッド）、セッションセットアップ時間および環境の複雑さが低減される。実施の一形態によれば、提案するソリューションは以下のことに基づいている。
・マルチキャストセッションの送信端は、セッションオブジェクト（session object）と呼ばれる、各マルチキャストフローのＱｏＳ要件、優先順位およびレートを定義する。
・各受信端は任意のオフラインまたはオンライン手段によって送信端からマルチキャストセッションオブジェクト（multicast session object）を取得する。
・各受信端はセッションセットアップ時間にその受信端と繋がったネットワーク内のエージェントにセッションオブジェクトを送信する。
・ネットワークエージェントにおけるプロトコルまたは機構はセッションオブジェクトを使用して（送信端から受信端への）セッションパスに沿った各ドメインにおけるマルチキャストセッションの各フロー毎にネットワークリソースの割当とマルチキャストツリーの生成を要求する。ユニキャストのドメイン間リンクにおけるＱｏＳ保証とセッション接続性が外部のプロトコルまたは機構によって実現される。エンドツーエンドのマルチキャストサポート付き環境において、ReCastはingress-to-accessルータからＱｏＳアウェアなマルチキャストツリーを制御する働きをする。
・実施の一形態によるルータはＩＰルーティング警告オプション（IP Routing Alert Option）［ＲＦＣ２１１３］に対応する。これによりそれらは受信したパケットを検査し、その中に含まれるReCast関連メッセージを認識することができる。
【００４９】
ReCast機能はReCastエッジエージェント（ReCast-E：ReCast Edge agent）とReCastコアエージェント（ReCast-C：ReCast Core agent）呼ばれるネットワークエージェントによってサポートされる。ReCast-Eエージェントはステートフル（stateful）であり、フロー毎のＱｏＳリソースおよびマルチキャストステートの制御を可能にする。ReCast-Eエージェントは内部インタフェースと外部インタフェースを実装し、シグナリングを開始する。内部インタフェースは例えば他のReCastエージェントと相互作用するために利用され、外部インタフェースは例えば外部プロトコルまたは機構と通信するために利用される。他方、ReCast-Cエージェントはreduced state（per-class）であり、要求されたＱｏＳおよびマルチキャストリソースを設定するようにシグナルを送られたときに反応するための内部インタフェースをサポートするだけである。
【００５０】
ReCast機能は集中型または分散型方式によりサポートすることが可能である。図４Ａに一般的なシナリオにおけるReCastエージェント達の配置の一例を示す。ドメインＡにおいては、ReCastエージェントは分散方式で動作しており、ReCast-Eエージェントはネットワークエージェントと一緒にエッジ（境界）エージェントに置かれ、ReCast-Cエージェントはコアノード（core nodes）内にある。ドメインＢにおいては、ReCastエージェントは分散配置されるが、しかしながら、マルチキャスト制御は（例えばＰＩＭ−ＳＭによって使用される）ランデブーポイント／マルチキャストコントローラ機構（Rendezvous Point/Multicast Controller mechanism）によって実行される。この方式では、ReCast-Eエージェントはランデブーポイントと相互作用してローカルなマルチキャストモデルについての情報を取得するほかに、ドメインにおける各フロー毎に使用されるマルチキャストチャネルの割当を要求する。ドメインＣではＱｏＳおよびマルチキャストリソースは集中制御される。この方式では、リソースコントローラとReCast-Eエージェントは同じノード内に配置される。
【００５１】
図４Ｂの上の部分は、送信端Ｓ１と送信端Ｓ２からマルチキャストセッション（セッション１およびセッション２）が複数の受信端へ配布される様子を示している。セッション１はエッジエージェントＡを介してコアエージェントＤに配布され、コアエージェントＤからそれはエッジエージェントＦとエッジエージェントＧへ分岐する。セッション１はエッジエージェントＨを通じてドメイン２に入り、コアエージェントＪを通過してそれはエッジエージェントＭとコアエージェントＫに分岐する。コアエージェントＫからそれはエッジエージェントＮに転送される。他方、セッション１はエッジエージェントＯを通じてドメイン３に入り、エッジエージェントＯからそれはコアエージェントＱに転送され、そこでエッジエージェントＳおよびＴに分岐する。
【００５２】
セッション２はエッジエージェントＢからドメイン１に入り、コアエージェントＥに転送され、そこでそれはエージェントＧとＤに分岐し、エージェントＤはそれをエージェントＦに転送する。次にそれはエッジエージェントＩを通じてドメイン２に入り、エージェントＬに転送され、そこでそれはエージェントＫとＮに分岐する。エージェントＫはそれをエッジエージェントＭに送る。
【００５３】
セッション２はエッジエージェントＯを通じてドメイン３に入り、エージェントＲへ転送され、そこでそれはエッジエージェントＳとＴに分岐する。
【００５４】
各セッションはグローバル識別子（図示されていない）を有し、それに対してセッションのフローはローカル識別子（チャネルとも呼ばれる）を有する。
【００５５】
図４Ｂの下の部分にエッジエージェントとコアエージェントにおいてそれぞれ管理されるステート（state）を示す。既に言及したように、両タイプのエージェントともステートフル（つまり、ステートを管理（maintain）する）であるが、コアエージェントに関しては若干削減されている。
【００５６】
実施の一形態によれば、エッジエージェント（ReCast-E）はマルチキャストステートとＱｏＳリソースに関するセッションおよびフロー毎ステート（session and per-flow state）を管理（maintain）する。セッションは（グローバルな）セッション識別子（セッションＩＤ（session ID））によって識別され、図４Ｂに示すように（識別子“フローＩＤ（FLOW ID）”を有する）１つの対応するフローに対して、セッションの各フロー毎にステート（state）情報が管理される。これはＱｏＳ要件（例えばＱｏＳクラス）に関係するステートとマルチキャスト設定（multicast configuration）（例えばマルチキャストＩＰアドレス（multicast IP address）および送信端ＩＰアドレス（source IP address））に関係するステートとを含む。実施の一形態によれば、このステート情報は図４Ｂに示すような次のような情報を含む。この情報は、例えばＤＳＣＰフィールド（ＱｏＳクラスの表示、いわゆる“ＴｏＳフィールドにサービスクラスを示す差別化されたサービスコードポイント”）、送信端ＩＰ（source IP）、（マルチキャストグループの）グループＩＰ（Group IP）、所要バンド幅（BW required）、出口エージェント（セッションはこのエージェントを経由してドメインを去る）のＩＰ（Egress IP）、およびＱｏＳパス（QoS Path）を含む。このように、エッジエージェントについてはそのＱｏＳステート（QoS state）およびそのマルチキャストステート（multicast state）に関するセッションに対するステートが管理される。図４Ｂが示すようにこの情報はエッジエージェントのみに格納されるが、コアエージェントとエッジエージェントの両方は次のようなステート情報を格納する。
【００５７】
ＱｏＳリザベーションステート（QoS reservation state）に関しては、各出力インタフェース毎に（例えばエージェントが分岐ノードであり、２以上のノードへの出力側の接続が存在する場合には、複数の出力インタフェースが存在し得る）、各ＱｏＳクラスのステート表示（ここではＤＳＣＰ１、ＤＳＣＰ２、およびＤＳＣＰ  Ｎ）が管理され、これらのクラスのそれぞれに対して入口リクエスタＩＰ（ingress requester IP）と所要バンド幅（requested bandwidth）が格納される。
【００５８】
マルチキャストステート（multicast state）に関しては、各出力インタフェース毎に、送信端ＩＰアドレス（source IP）とマルチキャストグループのグループＩＰアドレス（Group IP）が格納される。
【００５９】
異種環境にわたるＱｏＳリソース確保とマルチキャストツリー制御をサポートするため、ReCastは以下のインタフェース（図５参照）をサポートする。
・インタフェース
・・アプリケーションインタフェース（Application Interface）：リソースのリクエストをイネーブルにすることによってReCast機構またはReCastノードを外部の機構またはプロトコルにさらし、その成果をフィードバックするために使用される。例えば、それはReCastに（例えば外部のセッションシグナリングプロトコルまたはＱｏＳマッピングメカニズムと相互作用する）ドメインにおけるフローに対してネットワークリソースを設定することを要求するために使用することができる。加えて、ReCastは進行中のセッションフローのリソースを別のサービスクラスに再割り当てし、またはセッションが終了したら若しくはユーザが別のドメインに移動したことに起因してフローに関連するネットワークリソースをリリースするための指示（indication）を受信することができる。
・・マルチキャスト制御インタフェース（Multicast Control Interface）：ドメイン内の各フロー毎に割り当てられたマルチキャストチャネルについての情報を取得するために使用される。フローが終了すると、ReCastはマルチキャストコントローラ機構をトリガーして、割り当てられたチャネル（すなわちマルチキャストグループＩＰアドレス）をリリースすることができる。実施の一形態においてマルチキャストチャネルは２元タプル＜送信端ＩＰアドレス，グループＩＰアドレス＞である。グループＩＰアドレスは（ＳＳＭにおいて）送信端によって生成される。本発明の実施形態においては、任意のマルチキャストチャネルの送信端は入口デバイス内に置かれ、それは後にマルチキャストにより送信されるフローを生成するデバイスとは異なることに注意する。つまり、図４Ｂにおいてフローの送信端デバイスはＳ１およびＳ２であるが、しかしながら、マルチキャスト伝送の送信端はデバイスＡおよびＢであり、これらのデバイスはマルチキャストチャネルをフローに割り当てることによってマルチキャスト伝送を開始する。マルチキャスト制御インタフェースは（通信インタフェースによって取得された）割当の出力インタフェースに対してマルチキャスト分類子／リプリケータを設定することによってマルチキャストネットワークルータにおけるマルチキャストステートを直接的に生成、変更またはリリースするために使用することもできる。ＭＲＩＢにおけるエントリの追加は、マルチキャストツリーを生成／管理するためにマルチキャストプロトコルをトリガーすることと同様、このインタフェースを通じて遂行される。さらに、ReCastはこのインタフェースを使用して制御情報を問い合わせ、例えばマルチキャストツリーがインストールされているかどうかをチェックし、あるいはＭＲＩＢからパスを検索する。
・・ネットワークリソース制御インタフェース（Network Resource Control Interface）：現在利用可能なネットワークサービスクラスと利用可能なバンド幅についての情報を取得するために使用される。ＱｏＳはリソースを確保し、またはトラフィックを調整することによって、例えばスケジューラ（schedulers）とポリサ（policers）をそれぞれ適正に設定することによって制御することが可能である。リソースの再設定（reconfiguration）もReCastによって、例えばマーカ（marker）を再設定して進行中のフローを別のサービスクラスにリマップ（remap）するようにすることによってあるいは既に遂行された確保（reservation）によってサポートされる。セントラルリソースコントローラとのクラスタにおいて、ReCastはこのインタフェースを使用してその遂行のためにセントラルコントローラ（例えばバンド幅ブロッカ（bandwidth broker））をトリガーする。さらに、ReCastはネットワークプロビジョニングのためにＳＬＳコントローラと相互作用する、あるいは例えばリソース情報をクエリーすることができる。
・・通信インタフェース（Communication Interface）：ReCastエージェントの動作（operations）の支援として制御情報を伝えるメッセージを交換するために使用される。さらに、ReCastはこのインタフェースを使用してシステムの頑強性の支援としてルーティングプロトコルと相互作用する。例えば、ReCastはＯＳＰＦと相互作用して、下位レベルのプロトコルによるサポート表示を通じて、後者が、ネットワークインタフェースがダウンするときを検出すると、再ルーティング（re-routings）を検出する（例えば非特許文献［J. Moy, "OSPF Version 2", The Internet Engineering Task Force -IETF, RFC2328, Apr 1998］参照）。加えて、それはユニキャストルーティング情報ベース（ユニキャストＲＩＢ）から出力インタフェースを検索する。
【００６０】
図５にReCastエージェントのタイプ別のインタフェースを示す。ReCastエージェント間の交換メッセージは、制御情報を運ぶものであり、通信インタフェースを通じて実現される。
【００６１】
実施の一形態によるこれらのReCastメッセージは以下のものから成る。
・Reserve（確保）：このメッセージはReCastエージェントに、要求された確保／設定機能を指示し、動作の支援としてＱｏＳ量およびマルチキャストステートを伝える。ReCastエージェントはリソースの確保（reservation）、変更（modification）、リリース（releasing）および更新（refreshing）をサポートするが、これらの動作は全て、同じような（例えばフラグが機能性を示すことによって）しかし若干変更されたReserveメッセージによってトリガーされる。
・Response（応答）：要求された動作の状況（例えば受理または却下）について通知するために使用される。さらに、それは例えばノードが所要のＱｏＳを充たさないときなど、不具合が検出されたらすぐにノードにフィードバックするために使用される。こうして、既にインストールされたリソースを認識するために逆のパスに信号伝達される。更新動作の結果、Responseメッセージは対応するReserveメッセージのボトルネックエージェントにおけるネットワーク能力についての情報を運ぶ。加えて、ノードがルーティングプロトコルによってインタフェースがダウンしていることを通知されると、Responseメッセージは、ルーティングを示すコードと共に、ローカルに格納された全ての入口ノードへ送信される。
【００６２】
実施の一形態におけるReCastはＱｏＳおよびマルチキャストリソースを制御するための次のような２つのオペレーション方法を有する（他の実施形態では２つの方法の一方のみを実施することができる）。
・ＭＦＣ（Multicast Full Control）：ＭＦＣ方法はＱｏＳおよびマルチキャストリソースを同時に割り当てる（または設定する）ほかに、ステートストレージの管理を制御し、ＱｏＳ／マルチキャストの頑強性（robustness）も実現することを目標とする。ReCastはクラス単位（per-class basis）で所要量のバンド幅を確保（リザーブ）することによってＱｏＳ（例えばセッションフローのビットレートまたは既定レート）を割り当てる。マルチキャストリソースはＱｏＳ確保の遂行と同時にマルチキャストツリーを生成し、（ユーザが移動したり、セッションが終了したり、あるいは再ルーティングのせいで）セッションリソースを変更／リリースすることが必要になるまで、対応するステートを管理することによって制御される。再ルーティング事象が検出されるとすぐにReCastは新しいパスにＱｏＳおよびマルチキャストリソースを設定する。
・ＭＲＣ（Multicast Reduce Control）：ＭＲＣ方法も、マルチキャストツリーを管理すること（外部のマルチキャストコントローラ機構（例えばＰＩＭ−ＳＳＭ）によって遂行される）がないということを除いては、ＱｏＳおよびマルチキャストリソースを同時に割り当てることに取り組む。このため、例えば１つ前のノードのＩＰアドレスをＭＲＩＢに登録することによって、ReCastはリソース確保を遂行し、マルチキャストステートをインストールする。このようにして、マルチキャストコントローラがＱｏＳリソースがそれに沿って確保（リザーブ）されたパスを特定することを可能にする情報が管理され、それによりこれらのノードにマルチキャストツリーをインストールすることが可能となる。その目的のため、ドメインの出口／アクセスルータ（egress/access router）において、ReCastが各ノードにおいてＭＲＩＢに加えたパスにマルチキャストツリーを生成するためにマルチキャストコントローラがトリガーされる。マルチキャストコントローラは確保（リザーブ）されたパス（確保済みのパス）をカバーし、例えばこれらのノードにおいてマルチキャストグループＩＰアドレスを設定することによって、マルチキャストステートをインストールすることから、それはマルチキャストツリーの管理の支援としてそのデータベース内のマルチキャスト情報を供給する。それ故、ReCastは転送ノード（forwarding nodes）においてマルチキャスト情報を格納せず、助言（consults）とチェックを遂行するためにマルチキャストコントローラ機構が保存する情報に依存する。
【００６３】
従って次のよう言うことができる。ＭＲＣの場合、マルチキャストリソース設定はＱｏＳ確保が行われる各ノードのＭＲＩＢに１つ前のノードのＩＰアドレスを格納することから成り、その後、マルチキャスト設定はマルチキャストツリーの完成のためにこうして確立されたルートを逆に辿ることによって、つまりこれらのノードの各ノードに対してマルチキャストグループＩＰアドレスを設定することによって完了する。これは例えばＰＩＭ−ＳＳＭコントローラによって実行することができる。
【００６４】
実施の一形態によれば、上記方法の各方法の利用についての決定は静的および／または動的な設定（コンフィギュレーション）によって選択することができる。静的設定（static configuration）はサービスプロバイダによってそのビジネスモデルに基づいてまたはその近隣（neighbours）との同意に基づいて設定することができる。一方、動的設定（dynamic configuration）は要求に応じて外部のプロトコル／機構あるいは別のReCastエージェントによって実行することができる。これらの場合、セッションまたはフローのある特定のセットに対してどの方法が使用されなければならないかを通知するための指示（indication）はインタフェースによってあるいはメッセージによって送られる。
【００６５】
本機構はいくつかの利点を有する。以下、その一部を挙げる。
・ＱｏＳおよびマルチキャストオペレーションに対して異なるオペレーション方法を提供することによって、システムのフレキシビリティを増大させることができる；
・ネットワークオペレータは動的なバンド幅の変更と非対称なルーティングが伴う複数の環境にわたるＱｏＳおよびマルチキャストオペレーションの統一されたソリューションを使用することによってその運営コストを削減することができる；
・マルチキャストプロトコル（ＰＩＭ−ＳＳＭなど）が存在する場合にマルチキャストツリーの形成を制御することができ、またはマルチキャストプロトコルが存在しない場合にマルチキャストツリーを完全制御することができる；
・セッションセットアップ時間を削減できる；
・シグナリングオーバヘッドを削減できる；
・ＱｏＳ確保とマルチキャスト設定の異なるパスを避けることができる。
【００６６】
次に本発明の実施形態をより詳しく説明する。
【００６７】
実施の一形態によれば、ReCastはクラス単位（per-class basis）でＱｏＳリソースを確保（リザーブ）し、それと同時にシグナリング（信号伝達）のための通信インタフェースのサポートを通じて送信端から受信端へのセッションパスにマルチキャストツリーを生成することを目標とする。ReCastはフレキシブルなマルチキャスト制御を実現する。そこではネットワーク管理者は、ユーザは同じ方法でデータを受信するので、直接的な性能の示唆なしにReCastがＱｏＳおよびマルチキャストを制御する働きをする方法を設定する。
【００６８】
ReCast-Eエージェントはドメイン内の現在のセッションおよびフローについてのステート（state）を管理する必要がある。それ故、ReCast-Eはセッション毎フロー毎のステート（per-session and per-flow state）を保持する。このステートは、ReCastがセッションの各フロー毎にリソース、サービスクラス、ビットレート、送信端アドレス、グループアドレスおよび出口エージェントのアドレスを設定したパスのリストを含むことができる。一方、ReCast-Cエージェントは、利用可能なサービスクラスおよび各出力インタフェース毎のマルチキャストグループアドレスのリストのみを格納する。これに関しては、図４Ｂの下の部分を再度参照すると、ReCastエージェントによって格納されているステート情報がわかる。ReCastエージェントはソフトステート（soft-state）アプローチを使用してセッション毎フロー毎のステート（per-session and per-flow state）を管理することができる。これは例えばステートが定期的に更新（refresh）され、それにより例えばノードの移動に起因して起こるかもしれない任意の変更が考慮されることを意味する。
【００６９】
ドメイン内におけるマルチキャストコントローラスキームとの通信のおかげで基礎となるマルチキャストモデルに関係なくReCastを利用することができる。従って、各到来フロー毎に（セッションオブジェクトに基づいて）、ReCastはマルチキャストコントローラと（そのインタフェースを使用することによって）相互作用してマルチキャストチャネル識別子の割当を要求する。マルチキャストチャネル識別子はReCastによってセッションセットアップ時にマルチキャストツリーの生成を制御するために使用される。例えば、マルチキャストチャネル識別子はＳＳＭマルチキャストコントローラ（ＳＳＭチャネル＜送信端、グループ＞）によって、あるいはＭＡＤＣＡＰ（Multicast Address Dynamic Client Allocation Protocol）（ＲＦＣ２７３０参照）によって割り当てることができる。フローが終了すると、ReCastはマルチキャストコントローラ機構をトリガーして、割り当てられたチャネルをリリースする。
【００７０】
ReCastによって提供される機能について図６および図７を参照して説明する。
・リソースの確保（Resource Reservation）：ＱｏＳおよびマルチキャストネットワークリソースをダウンストリームの向きに設定する動作（オペレーション）である。ＱｏＳリソース設定はサービスクラスに関連する所要量のバンド幅の確保に取り組む。マルチキャスト設定は（ＭＦＣ方法では）マルチキャストツリーを直接的に生成する、あるいは（ＭＲＣ方法では）ＭＲＩＢをセッションパスで適時更新することを意味する。入口ルータにおいてアプリケーションインタフェースを介して外部のアプリケーション／機構によってトリガーされると、ReCast-Eエージェントは図６に示すようにステートａに進んで、マルチキャスト制御インタフェース（Multicast Control Interface）を介して必要とされるマルチキャストチャネルを割り当てる（ステートａ）。マルチキャストチャネルはセッションおよびその送信端に対してマルチキャストグループＩＰアドレスを設定（setting）することによって割り当てることができる。従ってそれはマルチキャストセッションのマルチキャストグループＩＰアドレスおよび送信端から成るタプル（tuple）を構成することがある。このタプルはセッションに割り当てられ、それによりマルチキャストチャネルを割り当てる。成功したマルチキャストチャネルの割当の後、ReCast-Eはステートｂに進んで、指示されたセッションが割り当てられた出力インタフェース（outgoing interface）にまだインストールされていない場合に、ローカルな出力インタフェースが到来するフローを受け入れるのに十分なリソースを有しているかどうかをチェックすることによって、アドミッション制御（admission control）を実行する。フローを承認すると、ReCast-Eはステートｃに進んで、ローカルなネットワークリソースを設定し、要求されたステートを更新し、そしてReserveメッセージをアクセスルータに向かって送信する。そのメッセージはルーティング警告オプションセット（routing alert option set）を有しているので、ユニキャストルーティングテーブルによって提供されたデータパスに沿った全てのノードがそのメッセージを処理する。Reserveメッセージを受信すると同時に、ReCast-Cエージェントはアドミッション制御を実行するためにステートａ（図７参照）に入る。リクエストがローカルに受入可能な場合、ReCast-Cはステートｂに入ってローカルなネットワークリソースを設定し、Reserveメッセージをダウンストリームの向きに転送する。エージェントがフローを拒否するとき（ステートｃ）、不具合を通知するコード（ＮＯＫ）を含むResponseメッセージが逆方向のパスに送り返され、リソースは各到達ノードによってリリースされる（例えば図７のステートｅ）。出口およびアクセスルータにおいてReCast-Cエージェントの同じ確保動作（reservation operations）がReCast-Eエージェントによって遂行される。確保を遂行した後、アクセスルータにおけるReCast-EエージェントはResponse（ＯＫ）メッセージを作成して入口ルータに送信する。入口ルータはパスステート（path state）を更新し、リクエスタアプリケーションをトリガーしてリクエストを確認する（図６のステートｆ）とともに割り当てられたマルチキャストチャネルについて通知する。
・リソースの変更（Resource Modification）：例えばセッションの品質レベルに再適応する必要があるときなどに、現在のセッションの確保をダウンストリームの向きに変更する動作（オペレーション）である。この動作は、セッションが存在するときに動作を避けない制御テストを除いては、リソースの確保（Resource Reservation）で説明したものと同様である。
・リソースの明示的なリリース（Explicit Resource Releasing）：出口／アクセスノードから分岐ノードまでのパスに沿ったノードにおいて指示された量のリソースをアップストリームの向きにリリースする動作（オペレーション）である。出口／アクセスルータでトリガーされると、ReCast-Eエージェントは最初に、指示されたセッションが２つ以上の出力インタフェースにおいて設定されているかどうかをチェックする。設定されていれば、指示された受信端に導く出力インタフェースのリソースのみがリリースされ、セッションが残りのパスで働き続けられるように次のノードはリソースをリリースすることはできないことを示すフラグがセットされたReserveメッセージが作成され、入口ルータ（ingress router）に送信される。ＭＲＩＢによって示されたパスに沿った全てのノードは最初にそのメッセージがリリースをイネーブルとするかどうかをチェックする。イネーブルであれば、リソースはリリースされ、そのメッセージはアップストリームの向きに転送される。イネーブルでなければ、メッセージは転送されるだけである。Reserveメッセージ（フラグがセットされていなければ通常のReserveメッセージとして機能するが、フラグがセットされているので実際にリリースメッセージとして働く）が受信されるとすぐに、入口ルータはResponse（ＯＫ）メッセージを作成して、リリースメッセージの発信源であるエージェントリクエスタ（agent requester）にそれを送信し、続いてそれはリクエスタアプリケーションを確認コードでトリガーする。
・リソースのリフレッシュ（Resource Refreshing）：保持されなければならないステートの量を指示することによってステートストレージ（state storage）をダウンストリームの向きに制御する動作（オペレーション）である。入口ルータにおけるReCast-Eエージェントにおいてリフレッシュ時間が経過したら、それはリフレッシュフラグがオンに設定され、同じ確保済みパスとサービスクラスを共有するフローに対するステートが集約されたReserveメッセージを作成し、それをアクセスルータに向かってダウンストリームの向きに送信する。ＭＦＣ方法で動作するとき、適合するフローに関連するマルチキャストツリーもそれらのメンテナンス制御のためにシグナリングメッセージに入れられる。インターセプトされたシグナリングで運ばれた情報に基づいて、データパス内の各ReCastエージェントは最初にユニキャストテーブルから次のホップ（next hop）のＩＰアドレスを検索し、それをメッセージに示されたパスと比較する。異なるとき、メッセージはReserveメッセージとして処理され、動作が終了したら同じメッセージがダウンストリームの向きに転送される。等しいとき、ReCastエージェントは指示されたサービスクラスに対して確保（リザーブ）された現在のバンド幅とメッセージから得られた量との間の違いを記憶し、そのメッセージをダウンストリームの向きに転送する。リフレッシュを遂行した後、アクセスルータにおけるReCast-EエージェントはResponse（ＯＫ）メッセージを作成し、それを入口ルータに送信する。各サービスクラス毎に、クリーンアップ時間が経過したらReCastエージェントは現在の確保をリフレッシュされなかった量だけ減らす。
【００７１】
図８に、２つのドメインと１つのマルチキャストセッション（１つのフローおよび２人の受信端）とから成る２つの一般的なシナリオにおける、ＱｏＳおよびマルチキャストリソースの制御（control）を示す。ドメインＡでは、ReCastはＭＦＣ方法（ＱｏＳおよびマルチキャストリソースのフル制御）で動作するように構成されており、ドメインＢではReCastはＭＲＣ方法（マルチキャストツリーの管理はなし）で動作するように構成されている。外部のアプリケーションが送信端から受信端へのパス内にあるドメインの入口エージェントにおけるReCastをトリガーしてセッションのためのリソースを要求することを想定する。さらに、マルチキャストチャネル割当は本例ではＳＳＭマルチキャストコントローラによって実行される。説明を簡単にするため、サービスクラスに割り当てられたリソースは両方のドメインにおいてオーバロードされないと仮定する。
【００７２】
図８に受信端Ｒ１がマルチキャストセッションＳ１（このセッションは１つのフローＦ１によって構成され、送信端Ｎ１から供給される）に加入したいと思っている一例を示す。それ故、ネットワークエージェントＥ３に繋がったＲ１上のアプリケーションプロトコルはセッションオブジェクト（session object）を作成し、シグナリングメッセージを使用してＳ１への方向にある最も近い分岐点を探す。入口ノードｌ１（受信端までこれより近い分岐点は存在しない）における分岐点に到達するとすぐに、アプリケーションプロトコルはReCastをトリガーしてマルチキャストセッションＳ１のためのＱｏＳおよびマルチキャストリソースを設定する。最初に、ReCastはマルチキャストコントロールインタフェース（Multicast Control Interface）を介してＳＳＭマルチキャストコントローラ機構をトリガーしてドメインＡにおいてマルチキャストセッションＳ１によって使用されるローカルなマルチキャストチャネルを割り当てる（本例ではマルチキャストチャネルはマルチキャストタプル＜ｌ１，Ｇ１＞によって識別される）。ここでｌ１は新しく確立されたマルチキャストセッションの送信端（入口ノードｌ１）のＩＰアドレスであり、Ｇ１は新しいセッションが確立される場合に利用可能なマルチキャストグループＩＰアドレスのプールから自由に選択できるマルチキャストグループＩＰアドレスである。その後、ReCastは通信インタフェース（Communication Interface）を通じて処理するためのｌ１からＣ１への出力インタフェース（ｏｉｆ）を割り当て、それは所要のリソース（セッションオブジェクトから得られる）が、割り当てられたｏｉｆに現在設定されているかどうかを最初にチェックする。
【００７３】
割り当てられたｏｉｆ（出力インタフェース）にＳ１が存在しない場合、ReCastは所要バンド幅を確保（リザーブ）し、マルチキャストツリーを（マルチキャストコントロールインタフェース（Multicast Control Interface）を介して）生成し、フロー毎のデータベースを、チャネル識別子を含む、セッションオブジェクトから得られた情報で更新する。最後に、ReCastは、サービスクラス、所要バンド幅およびマルチキャストチャネル識別子についての情報をもつReserveメッセージを作成し、それをルーティング警告オプション（routing alert option）をオンにした上でＥ３に向かって送信する（入口から出口までの全てのエージェントはこのメッセージをインターセプトする）。信号伝達されるとすぐに、Ｃ１はＱｏＳおよびマルチキャストリソースを設定し、ローカルデータベースを適宜更新してから、シグナリングメッセージをＥ３に向けて送信する。同じ動作がＥ１とｌ４で適宜遂行される。
【００７４】
ｌ４によって受信されたReserveメッセージはマルチキャストチャネル（＜ｌ１，Ｇ１＞）を伝えるので、新たなマルチキャストチャネル割当は要求されない。このため、ReCastは確保（reservation）を遂行し、マルチキャストツリーを生成する。ReCastはＭＲＣ方法で動作するように構成されているので、Ｅ１のＩＰアドレスはＭＲＩＢに加えられる。その後、それはフロー毎のデータベースを更新し、Ｅ３に向かってReserveメッセージを送信する。ダウンストリームパスに沿った各エージェントはReserveメッセージがＥ３に到達するまでネットワークリソース設定とデータベース更新を遂行する。ReserveメッセージがＥ３に到達すると、そこでＰＩＭ−ＳＳＭがトリガーされ、Responseメッセージがｌ１に返信される。
【００７５】
以下、個々のノードによって実行される動作を図８Ａを参照して詳しく説明する。
【００７６】
動作１（ノードｌ１）
・外部アプリケーション／機構はリソースをReCastに要求する；
・ｌ１はマルチキャストアドレスのＳＳＭプールからマルチキャストチャネルを割り当てる；
・ｌ１はＲＩＢから出力インタフェースを検索する；
・ｌ１はアドミッション制御を実行する：
・・ｌ１は指示されたセッション（Ｓ１）が出力インタフェースに存在しないかどうかをチェックする。
・・Ｓ１は存在しないので、ｌ１は出力インタフェースがフローを受け入れるのに十分なリソースを有しているかどうかをチェックする。
・アドミッション制御が成功裏に遂行された後：
・・ｌ１は関連するサービスクラスに対して所要量のバンド幅を確保（リザーブ）するようにパケットスケジューラを設定する；
・・ｌ１は指示されたマルチキャストグループに属するパケットを複製するように出力インタフェースを設定することによってマルチキャストツリーを生成する；
・・ｌ１はセッションステートを格納する；
・・ｌ１はReserveメッセージを作成してＥ３に向かってそれを送信する。
【００７７】
動作２（ノードＣ１）
・Ｃ１はReserveメッセージを受信する；
・Ｃ１はＲＩＢから出力インタフェースを検索する；
・Ｃ１はアドミッション制御を処理する。成功裏に遂行された後：
・・Ｃ１はＱｏＳリソースを確保（リザーブ）する；
・・Ｃ１はマルチキャストツリーを生成する；
・Ｃ１はReserveメッセージを転送する。
【００７８】
動作３（ノードＥ１）
・Ｅ１は動作２と同じ動作を実行する。
【００７９】
動作４（ノードｌ４）
・ｌ４はReserveメッセージを受信する；
・ｌ４はマルチキャストグループを割り当てない。それはReserveメッセージに含まれているからである；
・ｌ４は出力インタフェースを検索する；
・ｌ４はアドミッションを実行し、成功裏に遂行された後：
・・ＱｏＳリソースを設定する；
・・マルチキャストツリーは生成しない。ReCastはＭＲＣ方法で動作するように構成されているからである；
・・Ｅ１のＩＰアドレスをＭＲＩＢに加える；
・・Ｓ１に関連したステートを格納する；
・・Reserveメッセージを転送する。
【００８０】
動作５（ノードＣ５）
・動作４と同じ動作を実行し、ｌ４のＩＰアドレスをＭＲＩＢに加える。
【００８１】
動作６（ノードＥ３）
・Reserveメッセージを受信する；
・出力インタフェースを検索する；
・アドミッション制御を処理する。成功裏に遂行された後：
・・Ｃ５のＩＰアドレスをＭＲＩＢに加える；
・・Response（ＯＫ）メッセージを作成し、ｌ１に向かってそれを送信する。
【００８２】
動作７（ノードｌ１）
・Reserve（ＯＫ）メッセージを受信する；
・Ｓ１エントリにおけるパスステートを更新する；
・要求された動作の成功を通知するためにリクエスタのアプリケーション／機構をトリガーする。
【００８３】
シングルパスＱｏＳおよびマルチキャストリソース設定は次のようにして遂行することができる。
【００８４】
次に、ノードによって実行される個別の動作を図８Ｂを参照して詳しく説明する。図８Ｂに、受信端Ｒ２がアクセスルータＥ４においてＳ１に加入したいと思っている場合の一例を示す。本例で使用されるセッションアプリケーションはＳ１が活動化された最も近い入口ノードを検出するためのセッション制御機構で強化されていると想定する。これにより、ReCastはｌ４でトリガーされ、ｌ４においてローカル情報に基づいて、ｌ４からＣ５のｏｉｆにＳ１が存在することを検出することによって冗長な確保がスキップされる。Reserveメッセージを受信するとすぐにＣ５におけるReCastは、Ｃ６が次のホップ（next hop）であることと、Ｓ１がＣ５からＣ６のｏｉｆでアクティブでないことを両方検出する。ReCastはＭＲＣ方法で動作しているので、それはＣ５からＣ６のｏｉｆとＣ６からＥ４のｏｉｆにおいてバンド幅を確保（リザーブ）し、ｌ４のＩＰアドレスをＣ５におけるＭＲＩＢに加え、Ｃ５のＩＰアドレスをＣ６のＭＲＩＢに加える。対応する動作が完了した後、ReCastはＥ４においてＰＩＭ−ＳＳＭをトリガーし、Response（ＯＫ）メッセージをｌ４に送信する。続いてｌ４はそのステートを更新し、リクエスタアプリケーションに成功を確認する。
【００８５】
図８Ｂに示されたノードによって実行される個別の動作について詳しく説明する。
【００８６】
動作１（ノードｌ４）
・外部のアプリケーション／機構はリソースをReCastに要求する；
・マルチキャストチャネルは割り当てない。それはトリガーによって運ばれるからである；
・出力インタフェースをＲＩＢから検索する；
・アドミッション制御を処理する：
・・Ｓ１が出力インタフェースにおいてローカルに活動化されていることを検出し、従ってリソースを設定しない。
・Reserveメッセージを作成し、Ｅ４に向かってそれを送信する。
【００８７】
動作２（ノードＣ５）
・Reserveメッセージを受信する；
・出力インタフェースをＲＩＢから検索する；
・アドミッション制御を処理する：
・・Ｓ１がＣ６への出力インタフェースにおいて活動化されていないことを検出する；
・・このため、バンド幅の利用可能性をチェックする。
・アドミッション制御が成功裏に遂行された後：
・・ＱｏＳリソースを設定する；
・・ｌ４のＩＰアドレスをＭＲＩＢに加える；
・・ReserveメッセージをＥ４に転送する。
【００８８】
動作３（ノードＣ６）
・動作２と同じ動作を遂行する；
・さらに、Ｃ５のＩＰアドレスをＭＲＩＢに加える；
・Reserveメッセージを転送する。
【００８９】
動作４（ノードＥ４）
・Reserveメッセージを受信する；
・出力インタフェースを検索する；
・アドミッション制御を処理する。成功裏に遂行された後：
・・Ｃ６のＩＰアドレスをＭＲＩＢに加える；
・・Response（ＯＫ）メッセージを作成し、ｌ４に向かってそれを送信する。
【００９０】
動作５（ノードｌ４）
・Response（ＯＫ）メッセージを受信する；
・Ｓ１エントリにパスステート（path state）を追加する；
・要求された動作の成功を通知するためにリクエスタのアプリケーション／機構をトリガーする。
【００９１】
このようにして、リクエストメッセージが転送されなければならないパスは短縮することができ、処理オーバヘッドは削減することができる。
【００９２】
次に実施の一形態によるリフレッシュ手続きについて説明する。入口ノードｌ１でリフレッシュ時間が経過すると、ReCastはフローＦ１の現在要求されるリソースをチェックおよび更新し、リフレッシュフラグ（refresh flag）がオンにセットされたReserveメッセージ（Ｒｅｓｅｖｅ（Ｒ）））を作成し、それをＥ３に向かって送信する。データパスに沿った各エージェントはそのReserveメッセージから得られるリソースをリフレッシュし、それをダウンストリームの向きに送信する。Ｓ１がｌ１でアクティブになっている限り、データパスに沿ったリソースは定期的なＲｅｓｅｖｅ（Ｒ）メッセージが送られるごとに適宜メンテナンスされる。ｌ１におけるReCast-Eはリフレッシュ時間にはフローをローカルに特定せず、Ｒｅｓｅｖｅ（Ｒ）メッセージは一切送信されない（この場合にはＳ１はもはや利用可能でないことがあるので）。そこで、データパスに沿った各ReCastエージェントはクリーンナップ時間に達したらＳ１に関連するリソースをリリースする。
【００９３】
次に実施の一形態によるリソースをリリースする手続きについて説明する。Ｒ１がＳ１から離脱するとき、ReCastはＥ３において明示的なリリースでトリガーされる。Ｓ１に関連するリソースをリリースした後、ReCastは解体フラグ（tear down flag）がオンにセットされたReserveメッセージを作成し、それをｌ１に向かってアップストリームの向きに送信する。逆のパスに沿った全てのノードは分岐ノード（図８ｂにおけるＣ５）に信号伝達するまでリソースをリリースする。Reserveメッセージから得られるリソースをリリースした後、Ｃ５（分岐ノード）は全ての次のノードはリソースをリリースすることなくメッセージをアップストリームの向きに転送しなければならないことを指示するフラグをセットする。ｌ１はそのメッセージを受信すると、ReCast-EはＦ１のステートとＥ３へのパスを削除し、成功したことを通知するResponse（ＯＫ）メッセージをＥ３に送信する。
【００９４】
次に実施の一形態によるＱｏＳ確保の仕組みについて説明する。本実施形態ではＱｏＳ確保はクラスベース（class-based）であり、これはある特定のフローにある特定の固定されたバンド幅を割り当てるというよりも、そのＱｏＳ要件に基づくフローがある特定のクラスに割り当てられることを意味する。リソースが要求された各クラス毎に（言い換えると対応するフローが存在する各クラス毎に）、最小バンド幅が割り当てられる。この様子を図９に概略的に示す。図中、クラスＡ、クラスＢおよびクラスＣが存在する。これらのクラスの各々にはフローがノードに到来し、これらのクラスの１つに対してリソースを要求する時点で最小バンド幅が割り当てられる。特定の最小バンド幅はクラスに応じて予め定められている場合がある。
【００９５】
クラスに最初に割り当てられた最小バンド幅が十分でない（例えば、同じクラスにおけるリソースを要求する追加のフローが到来したため）ことが検出されたら、すぐにリソース割当機構は当該クラスに割り当てられるバンド幅を増大させることができる。クラスのリソースの増加量（またはリソースがより少なくて済む場合には減少量）はフローが要求するリソースに等しい。この増量は例えば図９に概略的に追加のバンド幅ＡＢによって示されている。この追加のバンド幅はクラスＡに最初に割り当てられた最小バンド幅ＭＢに加えて後からこのクラスＡに加えられたものである。
【００９６】
これはリソース割当が“フロー毎（per-flow）”というより“クラス毎（per-class）”に実行されることを意味する。ある特定のクラスに割り当てられた実際のバンド幅はこのクラスに入るフローが要求する所要量のバンド幅に依存する。あるクラスに実際に割り当てられるバンド幅は従ってある特定のクラスにおけるフローおよびそれらのリソース所要量に応じて動的に変化することがある。固定されたバンド幅を特定のフローに割り当てるのではなく、“クラス毎フロー毎の（per-class-per-flow）”確保スキームは、リソースを不必要に浪費することなく、割当リソースのフレキシブルな適応を可能にする。各クラスごとに、割当リソースは（ある特定のクラスがフローを全く持たない場合、バンド幅は全く割り当てられていない）最小限から出発し、クラスにおける個別のリソース所要量の進展に応じて、このクラスに割り当てられる対応するリソースは増減される。実施の一形態によれば斯かるクラスベースの確保スキームは各出力インタフェース毎に、言い換えると次のダウンストリームノードへの各出力リンク（outgoing link）毎に適用され、それによりリンクおよびネットワーク全体の全リソースの効率的な割当が可能である。
【００９７】
上記の実施形態は、ハードウェア、ソフトウェア、あるいはハードウェアとソフトウェアの組み合わせによって実施することができることは当業者であれば理解できよう。本発明の実施形態に関連して説明されたモジュールおよび機能は、全体的または部分的に、本発明の実施形態に関連して説明された方法の通りに動作するように適切にプログラムされたマイクロプロセッサまたはコンピュータによって実現することができる。本発明の実施形態を実現する装置は例えば、本発明の実施形態で説明された機構を実行することが可能なように適切にプログラムされたネットワークにおけるノードその他の構成要素を含むことができる。例えば、ネットワークノードは本発明の実施形態に関連して説明されたノードとして機能するようにプログラムすることができ、それにより本発明の実施形態が実際に構成される。上述したReCastノードとして機能するようにプログラムされたノードはかくして本発明の実施形態を実現することができる。
【００９８】
本発明の実施の一形態として、データキャリアに格納された、あるいは他の方法で記録媒体もしくは伝送リンクといった何らかの物理的手段によって具現化されたコンピュータプログラムであって、コンピュータ上で実行されたときにこのコンピュータが上記実施形態に従って動作することを可能にするコンピュータプログラムが提供される。
【００９９】
本発明の実施形態は、例えばネットワークのノード若しくはネットワークの他のエンティティであって上記機構に従って動作するようにプログラムされたものによって実現することができる。
【図面の簡単な説明】
【０１００】
【図１Ａ−１Ｃ】従来技術によるＱｏＳ＆マルチキャストリソース確保スキームを概説するための図である。
【図２】本発明の実施の一形態によるＱｏＳ＆マルチキャストリソース確保スキームを概説するための図である。
【図３】本発明の実施の一形態による方法のフロー図である。
【図４Ａ】本発明を適用することができる一般的な環境を示す図である。
【図４Ｂ】本発明の実施の一形態による環境を示す図である。
【図５】本発明の実施の一形態によるノードのインタフェースを示す図である。
【図６】本発明の実施の一形態によるノードの動作を説明するための図である。
【図７】本発明の実施の一形態によるノードの動作を説明するための図である。
【図８】（ａ）および（ｂ）はそれぞれ本発明の実施形態の動作を説明するための図である。
【図９】本発明の実施の一形態によるＱｏＳリソース割当の仕組みを特にバンド幅に関して説明するための図である。
【符号の説明】
【０１０１】
Ａ〜Ｔ  ネットワークノード
ｌ１〜ｌ５  入口ノード
Ｃ１〜Ｃ６  コアノード
Ｅ１〜Ｅ４  出口ノード
Ｆ１  フロー
Ｎ１  フローの送信端（ソース）
Ｒ１〜Ｒ２  受信端（レシーバ）
【図１Ａ−１Ｃ】
2008228303.tif 000003
【図２】
2008228303.tif 000004
【図３】
2008228303.tif 000005
【図４Ａ】
2008228303.tif 000006
【図４Ｂ】
2008228303.tif 000007
【図５】
2008228303.tif 000008
【図６】
2008228303.tif 000009
【図７】
2008228303.tif 000010
【図８】
2008228303.tif 000011
【図９】
2008228303.tif 000012
【外国語明細書】
2008228303.tif 000013
2008228303.tif 000014
2008228303.tif 000015
2008228303.tif 000016
2008228303.tif 000017
2008228303.tif 000018
2008228303.tif 000019
2008228303.tif 000020
2008228303.tif 000021
2008228303.tif 000022
2008228303.tif 000023
2008228303.tif 000024
2008228303.tif 000025
2008228303.tif 000026
2008228303.tif 000027
2008228303.tif 000028
2008228303.tif 000029
2008228303.tif 000030
2008228303.tif 000031
2008228303.tif 000032
2008228303.tif 000033
2008228303.tif 000034
2008228303.tif 000035
2008228303.tif 000036
2008228303.tif 000037
2008228303.tif 000038
2008228303.tif 000039
2008228303.tif 000040
2008228303.tif 000041
2008228303.tif 000042
2008228303.tif 000043
2008228303.tif 000044
2008228303.tif 000045
2008228303.tif 000046
2008228303.tif 000047
2008228303.tif 000048
2008228303.tif 000049
2008228303.tif 000050
2008228303.tif 000051
2008228303.tif 000052
2008228303.tif 000053
2008228303.tif 000054
2008228303.tif 000055
2008228303.tif 000056