(57)【要約】【課題】少なくとも１つのルータに対するネットワークリソース状態を検索し、使用可能なネットワークリソース状態によって新規なマルチキャスティングサービスの提供可否を決定するマルチキャスティング制御システム及びその方法を提供する。【解決手段】マルチキャスティングサービスのＱｏＳ保証方法に関し、マルチキャスティングソースまたは受信端末が新規登録されたり、ルータまたは受信端末が既存のマルチキャスティンググループから脱退する場合などにおいて、ネットワークのトポロジー及びリソース状態を検索し、検索したネットワークリソース状態によって新規なマルチキャスティングサービスの提供可否を決定するマルチキャスティング制御システム及びその方法を提供することによって、マルチキャスティング基盤の高品質マルチメディアサービスをユーザに提供することができる。【選択図】図３
2007181205.tif 000002
【特許請求の範囲】
【請求項１】
マルチキャスティングサービスが提供される少なくとも１つの受信端末と、
マルチキャスティングソースから前記受信端末に転送されるマルチキャスティングサービスパケットを中継する少なくとも１つのルータと、
前記ルータのネットワークリソース状態を収集して使用可能なネットワークリソースを把握し、新規なマルチキャスティングソースから前記ルータへのマルチキャスティングパケットの受信可否または前記ルータから新規な受信端末へのマルチキャスティングパケットの送信可否を決定するマルチキャスティング制御システムと、
を含むことを特徴とするマルチキャスティングサービスネットワーク。
【請求項２】
前記マルチキャスティングサービスネットワークは、
ＤＶＲＭＰ、ＭＯＳＰＦ、ＣＢＴ、ＰＩＭ−ＤＭ、ＰＩＭ−ＳＭのうち少なくとも１つを用いてマルチキャスティングパケットを転送することを特徴とする請求項１に記載のマルチキャスティングサービスネットワーク。
【請求項３】
前記ネットワークリソースは、
帯域幅（Ｂａｎｄｗｉｄｔｈ）、遅延時間（Ｄｅｌａｙ  Ｔｉｍｅ）、遅延分散（Ｄｅｌａｙ  Ｖａｒｉａｎｃｅ）に関する情報のうち少なくとも１つを含むことを特徴とする請求項１に記載のマルチキャスティングサービスネットワーク。
【請求項４】
前記マルチキャスティング制御システムは、
新規なマルチキャスティングパケットの送受信に必要なリソースと使用可能なネットワークリソースとを比較し、使用可能なネットワークリソースが足りないルータが前記新規なマルチメディアパケットをドロップするように制御することを特徴とする請求項１に記載のマルチキャスティングサービスネットワーク。
【請求項５】
前記マルチキャスティング制御システムは、
マルチキャスティングサービスを少なくとも１つのクラスに区分し、各クラス毎に最大利用可能なネットワークリソース量である最大ネットワークリソースを割り当てることを特徴とする請求項１に記載のマルチキャスティングサービスネットワーク。
【請求項６】
前記マルチキャスティング制御システムは、
新規なマルチキャスティングパケットの送受信のための使用可能なリソースが足りない場合には、使用可能なネットワークリソースが存在するクラスに割り当てられた最大ネットワークリソースを減少させ、新規なマルチキャスティングパケットが属するクラスに割り当てられた最大ネットワークリソースを増加させることを特徴とする請求項５に記載のマルチキャスティングサービスネットワーク。
【請求項７】
前記マルチキャスティング制御システムは、
マルチキャスティングパケットの転送状態がプルーン状態である入出力インタフェースを含むルータがマルチキャスティングパケットをドロップするように制御することを特徴とする請求項１に記載のマルチキャスティングサービスネットワーク。
【請求項８】
前記マルチキャスティング制御システムは、
マルチキャスティングサービスのための受信端末の登録または脱退、ルータの入出力インタフェースのマルチキャスティングパケットの転送状態変更、所定のアップデート時間の経過または満了のうち少なくとも１つのイベントが発生する場合には、ネットワークリソース状態をアップデートすることを特徴とする請求項１に記載のマルチキャスティングサービスネットワーク。
【請求項９】
少なくとも１つのルータと通信を行うためのルータ連結モジュールと、
前記ルータ連結モジュールを用いて前記ルータに対するネットワークリソースを収集し、使用可能なネットワークリソースを把握するリソース管理モジュールと、
前記リソース管理モジュールから使用可能なネットワークリソースを伝達され、新規なマルチキャスティングソースから前記ルータへのマルチキャスティングパケットの受信可否または前記ルータから新規な受信端末へのマルチキャスティングパケットの送信可否を決定する呼処理モジュールと、
を含むことを特徴とするマルチキャスティング制御システム。
【請求項１０】
ネットワークリソース状態によるネットワーク運用ポリシーを管理するポリシー管理モジュールと、
前記ポリシー管理モジュールから伝達されたポリシーを前記ルータが解析できる命令語に変換して伝達するポリシー適用モジュールと、
をさらに含むことを特徴とする請求項９に記載のマルチキャスティング制御システム。
【請求項１１】
前記ネットワークリソースは、
ルータ間の帯域幅、遅延時間、及び遅延分散に関する情報のうち少なくとも１つを含むことを特徴とする請求項９に記載のマルチキャスティング制御システム。
【請求項１２】
前記リソース管理モジュールは、
ルータのＩＤ、インタフェースＩＤ、総帯域幅、マルチキャスティングクラス、前記各クラス毎に使われる帯域幅、使われる総帯域幅、及び使用可能な帯域幅に関する情報のうち少なくとも１つを格納するリソース管理テーブルを含むことを特徴とする請求項９に記載のマルチキャスティング制御システム。
【請求項１３】
少なくとも１つのルータからネットワークリソース情報を収集し、各ルータ毎に使用可能なネットワークリソースを把握する段階と、
新規なマルチキャスティング受信端末または新規なマルチキャスティングソースが任意のルータにマルチキャスティングサービスを要請する段階と、
前記使用可能なネットワークリソースを用いて、前記ルータが新規なマルチキャスティングソースからマルチキャスティングパケットを受信するか、または、新規な受信端末にマルチキャスティングパケットを送信するかを決定する段階と、
を含むことを特徴とするマルチキャスティングサービス制御方法。
【請求項１４】
前記マルチキャスティングパケットの送受信は、
ＤＶＲＭＰ、ＭＯＳＰＦ、ＣＢＴ、ＰＩＭ−ＤＭ、ＰＩＭ−ＳＭのうち少なくとも１つを利用することによって行われることを特徴とする請求項１３に記載のマルチキャスティングサービス制御方法。
【請求項１５】
前記ネットワークリソースを収集する段階は、
互いに異なるルータ間の帯域幅、遅延時間、及び遅延分散に関する情報のうち少なくとも１つを収集することを特徴とする請求項１３に記載のマルチキャスティングサービス制御方法。
【請求項１６】
ルータのＩＤ、インタフェースＩＤ、総帯域幅、マルチキャスティングクラス、前記各クラス毎に使われる帯域幅、使われる総帯域幅、及び使用可能な帯域幅に関する情報のうち少なくとも１つを格納する段階を、さらに含むことを特徴とする請求項１３に記載のマルチキャスティングサービス制御方法。
【請求項１７】
新規なマルチキャスティングパケットの送受信に必要なリソースと使用可能なネットワークリソースとを比較し、使用可能なネットワークリソースが足りないルータが前記新規なマルチメディアパケットをドロップするように制御する段階を、さらに含むことを特徴とする請求項１３に記載のマルチキャスティングサービス制御方法。
【請求項１８】
マルチキャスティングサービスを少なくとも１つのクラスに区分し、各クラス毎に最大ネットワークリソースを割り当てる段階を、さらに含むことを特徴とする請求項１３に記載のマルチキャスティングサービス制御方法。
【請求項１９】
新規なマルチキャスティングパケットの送受信のための使用可能なリソースが足りない場合には、使用可能なネットワークリソースが存在するクラスに割り当てられた最大ネットワークリソースを減少させ、新規なマルチキャスティングパケットが属するクラスに割り当てられた最大ネットワークリソースを増加させる段階を、さらに含むことを特徴とする請求項１８に記載のマルチキャスティングサービス制御方法。
【請求項２０】
マルチキャスティングパケットの転送状態がプルーン状態である入出力インタフェースを含むルータがマルチキャスティングパケットをドロップするように制御する段階を、さらに含むことを特徴とする請求項１３に記載のマルチキャスティングサービス制御方法。
【請求項２１】
マルチキャスティングサービスのための受信端末の登録または脱退、ルータの入出力インタフェースのマルチキャスティングパケットの転送状態変更、所定のアップデート時間の経過または満了のうち少なくとも１つのイベントが発生する場合に、少なくとも１つのルータに対するネットワークリソース状態をアップデートするように制御する段階を、さらに含むことを特徴とする請求項１３に記載のマルチキャスティングサービス制御方法。
【請求項２２】
ＰＩＭ−ＳＭ（Ｐｒｏｔｏｃｏｌ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｍｕｌｔｉｃａｓｔ−Ｓｐａｒｓｅ  Ｍｏｄｅ）を用いたマルチキャスティング制御方法であって、
新規なマルチキャスティングソースが任意のルータにマルチキャスティングサービスを要請する段階と、
前記ルータとランデブーポイント間におけるリンクの使用可能な帯域幅情報を収集する段階と、
前記リンクの使用可能な帯域幅が新規なマルチキャスティングサービスの利用に必要な帯域幅より足りない場合には、前記ルータは、前記新規なマルチキャスティングソースからマルチキャスティングパケットを受信しない段階と、
を含むことを特徴とするマルチキャスティング制御方法。
【請求項２３】
ＰＩＭ−ＳＭを用いたマルチキャスティング制御方法であって、
ルータ入出力インタフェースと受信端末間におけるリンクの使用可能な帯域幅情報を収集する段階と、
前記リンクの使用可能な帯域幅が新規なマルチキャスティングサービスの利用に必要な帯域幅より足りない場合には、前記ルータは、マルチキャスティングソースから受信したマルチキャスティングパケットをドロップする段階と、
を含むことを特徴とするマルチキャスティング制御方法。
【請求項２４】
ＰＩＭ−ＳＭを用いたマルチキャスティング制御方法であって、
新規な受信端末がプルーン状態であるルータを介してランデブーポイントにマルチキャスティングサービスを要請する段階と、
前記ランデブーポイントと前記ルータ間におけるリンクの使用可能な帯域幅情報を収集する段階と、
前記リンクの使用可能な帯域幅が新規なマルチキャスティングサービスの提供に必要な帯域幅より大きい場合には、前記ランデブーポイント及び前記ルータを介して前記受信端末にマルチキャスティングパケットを転送する段階と、
を含むことを特徴とするマルチキャスティング制御方法。
【請求項２５】
ＰＩＭ−ＳＭを用いたマルチキャスティング制御方法であって、
ランデブーポイントに連結された少なくとも１つの受信端末がマルチキャスティングサービスグループから脱退する段階と、
前記ランデブーポイントに連結された受信端末が全てマルチキャスティングサービスグループから脱退する場合には、前記マルチキャスティングサービスグループにマルチキャスティングパケットを提供するソースに直接連結されたルータが前記マルチキャスティングパケットをドロップするように制御する段階と、
を含むことを特徴とするマルチキャスティング制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチキャスティングサービスのＱｏＳを保証するためのマルチキャスティング制御システム及びその方法に関する。
【背景技術】
【０００２】
従来、ネットワークは、有線／無線ネットワーク、音声／データネットワーク、放送／通信ネットワークに区分され、各々のネットワークは、互いに異なる方式でユーザにサービスを提供してきた。しかしながら、現在は、ＮＧＮ（Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｎｅｔｗｏｒｋ）の概念として有線／無線の統合、音声／データ統合、放送／通信統合ネットワークについての研究や開発が活発に進行している。ＮＧＮは、ＩＰ基盤の高品質且つ大容量のパケットネットワークで構成されるものと予想される。また、ＮＧＮが始まる時点には、従来のサービスも進化してデジタル映像サービス、高画質ＶｏＤ、大容量ネットワークゲームなどの高品質マルチメディアサービスがユーザに提供されるだろう。
【０００３】
前述した高品質マルチメディアサービスには、インタラクティブＴＶ（Ｉｎｔｅｒａｃｔｉｖｅ  ＴＶ）、オンデマンドＴＶ（Ｏｎ  Ｄｅｍａｎｄ  ＴＶ）、ビデオコンファレンス（Ｖｉｄｅｏ  Ｃｏｎｆｅｒｅｎｃｅ）、デジタルＴＶ（Ｄｉｇｉｔａｌ  ＴＶ）、高画質ストリーミングビデオ（Ｓｔｒｅａｍｉｎｇ  Ｖｉｄｅｏ）などの映像サービスなどが挙げられ、ＩＰを基盤にしてユーザに提供されるだろう。
【０００４】
前述したマルチメディアサービスをＩＰネットワーク上でユーザに提供するためには、ＩＰユニキャストルーティングプロトコル（ＩＰ  Ｕｎｉｃａｓｔ  Ｒｏｕｔｉｎｇ  Ｐｒｏｔｏｃｏｌ）とＩＰマルチキャスティングプロトコル（ＩＰ  Ｍｕｌｔｉｃａｓｔｉｎｇ  Ｐｒｏｔｏｃｏｌ）が必要である。ＩＰマルチキャスティングプロトコルの例として、ＤＶＭＲＰ、ＭＯＳＰＦ、ＣＢＴ、ＰＩＭ−ＤＭ、ＰＩＭ−ＳＭなどが開発された。
【０００５】
これらのうち、ＰＩＭ−ＳＭ（Ｐｒｏｔｏｃｏｌ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｍｕｌｔｉｃａｓｔ−Ｓｐａｒｓｅ  Ｍｏｄｅ）が拡張性や連動性を考慮して、最も優れた性能を示すものと報告されており、現在商用化されている大部分の３階層スイッチ（Ｌａｙｅｒ  ３  Ｓｗｉｔｃｈ）は、ＰＩＭ−ＳＭをサポートしている。
【０００６】
まず、ＰＩＭ−ＳＭで利用する（Ｓ、Ｇ）ステートの表現について説明する。このような形式の符号は、マルチキャスティンググループを区別するための符号に該当し、ソース（Ｓ：Ｓｏｕｒｃｅ）及びマルチキャスティンググループアドレス（Ｇ：Ｍｕｌｔｉｃａｓｔｉｎｇ  Ｇｒｏｕｐ  Ａｄｄｒｅｓｓ）を用いてセッショントラフィックを識別するものである。
【０００７】
例えば、（＊、Ｇ）において、＊は、グループＧに送る全てのソースを表現するワイルドカードであり、Ｇは、マルチキャスティンググループを意味するものである。したがって、どのルータに（＊、Ｇ）ステートを照会するということは、全てのソースにおいてＧというグループに属するマルチキャスティングパケットを受信するか否かを照会するという意味である。
【０００８】
図１は、従来のＰＩＭ−ＳＭを用いたマルチキャスティングネットワークの動作方法を示すブロック図である。
【０００９】
図１に示されたように、ＩＰネットワークは、ソース（Ｓ１）１１、ルータ（Ｒｏｕｔｅｒ１〜  Ｒｏｕｔｅｒ４）１２Ａ、１２Ｂ、１２Ｃ、１２Ｄ、ランデブーポイント（ＲＰ）１３、及び受信端末（Ｒ１、Ｒ２）１４Ａ、１４Ｂなどから構成される。
【００１０】
第１、第２の受信端末１４Ａ、１４Ｂは、マルチキャスティンググループＧに加入してマルチキャスティングサービスが提供される。このために、第１、第２の受信端末１４Ａ、１４Ｂは、まず、ＩＧＭＰ加入メッセージ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ  Ｊｏｉｎ  Ｍｅｓｓａｇｅ）を各々第３のルータ、第４のルータ１２Ｃ、１２Ｄに転送し、マルチキャスティンググループＧに加入する（ステップＳ１０１）。
【００１１】
第３、第４のルータ１２Ｃ、１２Ｄは、ＰＩＭ加入メッセージ（ＰＩＭ  Ｊｏｉｎ  Ｍｅｓｓａｇｅ）を通じてランデブーポイント１３のマルチキャスティンググループＧに加入する（ステップＳ１０２）。このようにランデブーポイント１３に対して登録が行われた場合には、ランデブーポイント１３から第３、第４のルータ１２Ｃ、１２ＤまでのマルチキャスティンググループＧに対する共有ツリー（Ｓｈａｒｅｄ  Ｔｒｅｅ）が形成される。
【００１２】
前述したようなマルチキャスティングサービスを提供するソース１１は、第１のルータ１２Ａにマルチキャスティングパケットを転送する。これを受信した第１のルータ１２Ａは、ランデブーポイント１３に登録メッセージを転送し（ステップＳ１０３）、ランデブーポイント１３は、登録メッセージを用いてマルチキャスティンググループＧに対するソースツリー（Ｓｏｕｒｃｅ  Ｔｒｅｅ）を形成し始める。
【００１３】
ランデブーポイント１３は、第２のルータ１２ＢにＰＩＭ加入メッセージを転送し（ステップＳ１０４）、マルチキャスティンググループへの加入を要請し、第２のルータ１２Ｂは、第１のルータ１２ＡにＰＩＭ加入メッセージをさらに転送し（ステップＳ１０５）、第１のルータ１２ＡのマルチキャスティングＧグループに対するソースツリーを完成するようになる。
【００１４】
前述したように、第１のルータ１２Ａからランデブーポイント１３までソースツリーが形成される場合には、ランデブーポイント１３は、第１のルータ１２Ａに登録中止メッセージ（Ｒｅｇｉｓｔｅｒｉｎｇ  Ｓｔｏｐ  Ｍｅｓｓａｇｅ）を転送し、登録過程を終了する（ステップＳ１０６）。このような登録過程後、ＰＩＭ−ＳＭを用いてソース１１から第１、第２の受信端末１４Ａ、１４Ｂまでマルチキャスティングパケットが転送される（ステップＳ１０７）。
【００１５】
前述したように、従来のＰＩＭ−ＳＭマルチキャスティングプロトコルでは、ネットワークリソース状態に関係なく、新規なソースを収容しているので、既存のサービスのＱｏＳを保証できないという問題点を有する。そして、ランデブーポイントとサービス終端ルータである第３、第４のルータとの間に共有ツリーが生成される場合、ネットワークリソース状態に関係なく、マルチキャスティングデータが送受信されるので、サービスのＱｏＳ品質が劣化するという問題点がある。また、当該マルチキャスティンググループに対する受信端末が全く存在しなくても、登録過程が行われ、パケットが送受信されるので、各ルータのネットワークリソースの浪費をもたらすという問題点が発生する。
【００１６】
また、特許文献１には、ヘッドエンドと加入者がマルチキャスティンググループを介して放送ストリームを送受信する一般的方法についての技術が記載されており、ＰＩＭ−ＳＭなどのプロトコルを用いてマルチキャスティング制御を行うことが可能な技術も記載されている。
【特許文献１】韓国特許出願１０−２００４−０００９６３０
【発明の開示】
【発明が解決しようとする課題】
【００１７】
本発明は、前述のような従来技術に係る問題点を解決するためになされたもので、その目的は、少なくとも１つのルータに対するネットワークリソース状態を検索し、使用可能なネットワークリソース状態によって新規なマルチキャスティングサービスの提供可否を決定するマルチキャスティング制御システム及びその方法を提供することにある。
【課題を解決するための手段】
【００１８】
上記目的を達成するために、本発明の一態様に係るマルチキャスティングサービスネットワークは、マルチキャスティングサービスが提供される少なくとも１つの受信端末と、マルチキャスティングソースから受信端末に転送されるマルチキャスティングサービスパケットを中継する少なくとも１つのルータと、ルータのネットワークリソース状態を収集して使用可能なネットワークリソースを把握し、新規なマルチキャスティングソースからルータへのマルチキャスティングパケットの受信可否またはルータから新規な受信端末へのマルチキャスティングパケットの送信可否を決定するマルチキャスティング制御システムと、を含むことができる。
【００１９】
この場合、マルチキャスティングサービスネットワークは、ＤＶＲＭＰ、ＭＯＳＰＦ、ＣＢＴ、ＰＩＭ−ＤＭ、ＰＩＭ−ＳＭのうち少なくとも１つを用いてマルチキャスティングパケットを転送する。また、ネットワークリソースは、帯域幅（Ｂａｎｄｗｉｄｔｈ）、遅延時間（Ｄｅｌａｙ  Ｔｉｍｅ）、遅延分散（Ｄｅｌａｙ  Ｖａｒｉａｎｃｅ）に関する情報のうち少なくとも１つを含む。
【００２０】
マルチキャスティング制御システムは、新規なマルチキャスティングパケットの送受信に必要なリソースと使用可能なネットワークリソースとを比較し、使用可能なネットワークリソースが足りないルータが新規なマルチメディアパケットをドロップするように制御することができる。
【００２１】
また、マルチキャスティング制御システムは、マルチキャスティングサービスを少なくとも１つのクラスに区分し、各クラス毎に最大利用可能なネットワークリソース量である最大ネットワークリソースを割り当てるポリシーを含むことができ、このようなポリシーに従って新規なマルチキャスティングパケットの送受信のための使用可能なリソースが足りない場合、使用可能なネットワークリソースが存在するクラスに割り当てられた最大ネットワークリソースを減少させ、新規なマルチキャスティングパケットが属するクラスに割り当てられた最大ネットワークリソースを増加させる制御を行うことができる。
【００２２】
より好ましくは、マルチキャスティング制御システムは、マルチキャスティングパケットの転送状態がプルーン状態である入出力インタフェースを含むルータがマルチキャスティングパケットをドロップするように制御することができる。
【００２３】
ポリシーに従う時、マルチキャスティングサービスのための受信端末の登録または脱退、ルータの入出力インタフェースのマルチキャスティングパケットの転送状態変更、所定のアップデート時間の経過または満了のうち少なくとも１つのイベントが発生する場合、ネットワークリソース状態をアップデートすることができる。
【００２４】
本発明の他の態様に係るマルチキャスティング制御システムは、少なくとも１つのルータと通信を行うためのルータ連結モジュールと、ルータ連結モジュールを用いてルータに対するネットワークリソースを収集し、使用可能なネットワークリソースを把握するリソース管理モジュールと、リソース管理モジュールから使用可能なネットワークリソースを伝達され、新規なマルチキャスティングソースからルータへのマルチキャスティングパケットの受信可否またはルータから新規な受信端末へのマルチキャスティングパケットの送信可否を決定する呼処理モジュールと、を含むことができる。
【００２５】
この場合、マルチキャスティング制御システムは、ネットワークリソース状態によるネットワーク運用ポリシーを管理するポリシー管理モジュールと、ポリシーをルータが解析できる命令語に変換して伝達するポリシー適用モジュールと、をさらに含むことができる。
【００２６】
また、リソース管理モジュールは、ルータのＩＤ、インタフェースＩＤ、総帯域幅、マルチキャスティングクラス、各クラス毎に使われる帯域幅、使われる総帯域幅、使用可能な帯域幅に関する情報のうち少なくとも１つを格納するリソース管理テーブルを含むことができる。
【００２７】
また、本発明のさらに他の態様に係るマルチキャスティングサービス制御方法は、少なくとも１つのルータからネットワークリソース情報を収集し、各ルータ毎に使用可能なネットワークリソースを把握する段階と、新規なマルチキャスティング受信端末または新規なマルチキャスティングソースが任意のルータにマルチキャスティングサービスを要請する段階と、ルータが使用可能なネットワークリソースを用いて新規なマルチキャスティングソースからルータへのマルチキャスティングパケットの受信可否、またはルータから新規な受信端末へのマルチキャスティングパケットの送信可否を決定する段階と、を含むことができる。
【００２８】
この場合、マルチキャスティングパケットの送受信は、ＤＶＲＭＰ、ＭＯＳＰＦ、ＣＢＴ、ＰＩＭ−ＤＭ、ＰＩＭ−ＳＭのうち少なくとも１つを利用することによって行われ、ネットワークリソースを収集する段階は、互いに異なるルータ間の帯域幅、遅延時間、遅延分散に関する情報のうち少なくとも１つを収集することを意味する。また、マルチキャスティングサービス制御方法は、ルータのＩＤ、インタフェースＩＤ、総帯域幅、マルチキャスティングクラス、各クラス毎に使われる帯域幅、使われる総帯域幅、使用可能な帯域幅に関する情報のうち少なくとも１つを格納する段階をさらに含むことができる。
【００２９】
本発明に係るマルチキャスティングサービス制御方法は、新規なマルチキャスティングパケットの送受信に必要なリソースと使用可能なネットワークリソースとを比較し、使用可能なネットワークリソースが足りないルータが新規なマルチメディアパケットをドロップするように制御する段階と、マルチキャスティングサービスを少なくとも１つのクラスに区分し、各クラス毎に最大利用可能なネットワークリソース量であるネットワークリソースを割り当てる段階と、新規なマルチキャスティングパケットの送受信のための使用可能なリソースが足りない場合、使用可能なネットワークリソースが存在するクラスに割り当てられた最大ネットワークリソースを減少させ、新規なマルチキャスティングパケットが属するクラスに割り当てられた最大ネットワークリソースを増加させる段階と、マルチキャスティングパケットの転送状態がプルーン状態である入出力インタフェースを含むルータがマルチキャスティングパケットをドロップするように制御する段階と、マルチキャスティングサービスのための受信端末の登録または脱退、ルータの入出力インタフェースのマルチキャスティングパケットの転送状態変更、所定のアップデート時間の経過または満了のうち少なくとも１つのイベントが発生する場合、少なくとも１つのルータに対するネットワークリソース状態をアップデートするように制御する段階などをさらに含むことができる。
【００３０】
また、本発明のさらに他の態様に係るＰＩＭ−ＳＭ（Ｐｒｏｔｏｃｏｌ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｍｕｌｔｉｃａｓｔ−Ｓｐａｒｓｅ  Ｍｏｄｅ）を用いたマルチキャスティング制御方法は、新規なマルチキャスティングソースが任意のルータにマルチキャスティングサービスを要請する段階と、ルータとランデブーポイント間におけるリンクの使用可能な帯域幅情報を収集する段階と、リンクの使用可能な帯域幅が新規なマルチキャスティングサービスの利用に必要な帯域幅より足りない場合、ルータは、新規なマルチキャスティングソースからマルチキャスティングパケットを受信しない段階と、を含むことができる。
【００３１】
また、本発明のさらに他の態様に係るＰＩＭ−ＳＭを用いたマルチキャスティング制御方法は、ルータ入出力インタフェースと受信端末間におけるリンクの使用可能な帯域幅情報を収集する段階と、リンクの使用可能な帯域幅が新規なマルチキャスティングサービスの利用に必要な帯域幅より足りない場合、ルータは、マルチキャスティングソースから受信したマルチキャスティングパケットをドロップする段階と、を含むことができる。
【００３２】
この場合、ＰＩＭ−ＳＭを用いたマルチキャスティング制御方法は、新規な受信端末がプルーン状態であるルータを介してランデブーポイントにマルチキャスティングサービスを要請する段階と、ランデブーポイントとルータ間におけるリンクの使用可能な帯域幅情報を収集する段階と、リンクの使用可能な帯域幅が新規なマルチキャスティングサービスの提供に必要な帯域幅より大きい場合、ランデブーポイント及びルータを介して受信端末にマルチキャスティングパケットを転送する段階と、を含むことができる。
【００３３】
本発明のさらに他の態様に係るマルチキャスティング制御方法は、ランデブーポイントに連結された少なくとも１つの受信端末がマルチキャスティングサービスグループから脱退する段階と、ランデブーポイントに連結された受信端末が全てマルチキャスティングサービスグループから脱退する場合、マルチキャスティングサービスグループにマルチキャスティングパケットを提供するソースに直接連結されたルータがマルチキャスティングパケットをドロップするように制御する段階と、を含むことができる。
【発明の効果】
【００３４】
本発明のマルチキャスティング制御システム及びその制御方法によれば、マルチキャスティングソースまたは受信端末が新規登録されたり、ルータまたは受信端末が既存のマルチキャスティンググループから脱退する場合などにおいて、ネットワークのトポロジー及びリソース状態を検索し、検索したネットワークリソース状態によって新規なマルチキャスティングサービスの提供可否を決定するので、マルチキャスティング基盤の高品質マルチメディアサービスをユーザに提供することができる。
【発明を実施するための最良の形態】
【００３５】
以下、添付の図面を参照して、本発明の実施形態のマルチキャスティングサービス制御システム及びその方法について詳細に説明する。
【００３６】
図２は、本発明の一実施形態のマルチキャスティング制御システムを含むマルチキャスティングネットワークを示すブロック図である。
【００３７】
図２に示されたように、インターネットサービスを提供するためのＩＰネットワークは、受信端末（Ｒ１〜Ｒ３）５１〜５３、ルータ（Ｒｏｕｔｅｒ１〜Ｒｏｕｔｅｒ５）４１〜４５、ランデブーポイント（ＲＰ）６０、ソース（Ｓ１）３０及びマルチキャスティング制御システム２０などから構成される。
【００３８】
受信端末（Ｒ１〜Ｒ３）５１〜５３は、マルチキャスティングサービスをユーザに提供するための構成要素である。受信端末（Ｒ１〜Ｒ３）５１〜５３は、ルータ（Ｒｏｕｔｅｒ１〜Ｒｏｕｔｅｒ５）４１〜４５からマルチキャスティングパケットが伝送され、マルチキャスティングパケットに従うサービスをユーザに提供する。一方、マルチキャスティングソース（Ｓ１）３０は、マルチキャスティングサービスのためのパケットを出力する構成要素である。
【００３９】
ルータ（Ｒｏｕｔｅｒ１〜Ｒｏｕｔｅｒ５）４１〜４５及びランデブーポイント（ＲＰ）６０は、マルチキャスティングソース（Ｓ１）３０から受信端末（Ｒ１〜Ｒ３）５１〜５３までマルチキャスティングパケットを中継する構成要素である。また、ルータ（Ｒｏｕｔｅｒ１〜Ｒｏｕｔｅｒ５）４１〜４５またはランデブーポイント（ＲＰ）６０は、各々入出力インタフェースｉｆ１〜ｉｆ１４を含む。
【００４０】
ルータ（Ｒｏｕｔｅｒ１〜Ｒｏｕｔｅｒ５）４１〜４５は、入出力インタフェースｉｆ１〜ｉｆ１４を介して他のルータ（Ｒｏｕｔｅｒ１〜Ｒｏｕｔｅｒ５）４１〜４５または受信端末（Ｒ１〜Ｒ３）５１〜５３にマルチキャスティングパケットをルーティングする。
【００４１】
また、パケットをマルチキャスティングするために、ルータ（Ｒｏｕｔｅｒ１〜Ｒｏｕｔｅｒ５）４１〜４５及びランデブーポイント（ＲＰ）６０は、少なくとも１つのマルチキャスティングプロトコルを利用しなければならない。このようなマルチキャスティングプロトコルには、前述したように、ＤＶＭＲＰ、ＭＯＳＰＦ、ＣＢＴ、ＰＩＭ−ＤＭ、ＰＩＭ−ＳＭなどが挙げられる。
【００４２】
運用者インタフェース７０は、運用者から命令を入力され、マルチキャスティング制御システム２０を制御する一方で、マルチキャスティング制御システム２０が各種ネットワーク構成要素の制御状況をディスプレーする機能を有する。
【００４３】
マルチキャスティング制御システム２０（ＭＳＱＣ：Ｍｕｌｔｉｃａｓｉｎｇ  Ｓｅｒｖｉｃｅ  Ｑｏｓ  Ｃｏｎｔｒｏｌｌｅｒ）は、マルチキャスティングサービスのＱｏＳを制御するためのシステムであって、本発明の核心的技術思想に該当する。
【００４４】
図２に示されたように、マルチキャスティング制御システム２０は、マルチキャスティングサービスを提供するルータ（Ｒｏｕｔｅｒ１〜Ｒｏｕｔｅｒ５）４１〜４５及びランデブーポイント（ＲＰ）６０に連結されていて、ルータ間におけるリンク、ルータとランデブーポイント間におけるリンクのネットワークリソース状態、ルータの入出力インタフェースの状態などを収集、管理する。また、収集したネットワークリソース状態によって設定されるポリシーを転送することによって、各ルータ（Ｒｏｕｔｅｒ１〜  Ｒｏｕｔｅｒ５）４１〜４５及びランデブーポイント（ＲＰ）６０を制御する。
【００４５】
図３は、本発明の一実施形態のマルチキャスティング制御システムの内部構造を示すブロック図である。
【００４６】
図３に示されたように、マルチキャスティング制御システム２０は、ポリシー管理モジュール（ＰＭ：Ｐｏｌｉｃｙ  Ｍａｎａｇｅｒ  Ｍｏｄｕｌｅ）２１、ポリシー適用モジュール（ＰＤＭ：Ｐｏｌｉｃｙ  Ｄｅｐｌｏｙ  Ｍｏｄｕｌｅ）２２、リソース管理モジュール（ＴＲＭ：Ｔｏｐｏｌｏｇｙ／Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅ  Ｍｏｄｕｌｅ）２３、呼処理モジュール（ＣＭ：Ｃａｌｌ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｍａｎａｇｅ  Ｍｏｄｕｌｅ）２４、ルータ連結モジュール（ＲＣＭ：Ｒｏｕｔｅｒ  Ｃｏｎｎｅｃｔｉｏｎ  Ｍｏｄｕｌｅ）２５、及び、運用者インターフェース（ＧＵＩ）２６などから構成される。
【００４７】
ポリシー管理モジュール（ＰＭ）２１は、ＩＰネットワークリソースを制御／管理するポリシー機能を行い、ポリシー適用モジュール２２は、ポリシー管理モジュール（ＰＭ）２１からポリシーを伝達され、ルータのようなネットワーク構成要素が解析できる命令語に変換して出力する機能を行う。リソース管理モジュール（ＴＲＭ）２３は、マルチキャスティングネットワークに含まれた構成要素のトポロジー（Ｔｏｐｏｌｏｇｙ）変化、リソース（Ｒｅｓｏｕｒｃｅ）変化などをチェックし、呼処理モジュール（ＣＭ）２４は、ネットワーク上の他の構成要素と呼設定などの制御を行うと共に、各マルチキャスティングサービスの収容可否を判断する。
【００４８】
ルータ連結モジュール（ＲＣＭ）２５は、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）、ＣＬＩ（Ｃｏｍｍａｎｄ  Ｌｉｎｅ  Ｉｎｔｅｒｆａｃｅ）、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）などを用いてルータ（Ｒｏｕｔｅｒ１〜  Ｒｏｕｔｅｒ５）４１〜４５に命令を下したり、情報を収集する機能を行う。
【００４９】
まず、マルチキャスティング制御システム２０は、ルータ連結モジュール（ＲＣＭ）２５を介して制御や管理対象となるＩＰネットワークのトポロジー及びリソースを収集する。収集したネットワークのトポロジー及びリソースは、リソース管理モジュール（ＴＲＭ）２３に含まれたリソーステーブル（Ｒｅｓｏｕｒｃｅ  Ｔａｂｌｅ）を用いて管理される。このようなリソーステーブルは、表１のように生成される。
【００５０】
【表１】
2007181205.tif 000003
【００５１】
表１に示されたように、リソーステーブルは、リンクＩＤ（Ｌｉｎｋ  ＩＤ）、ルータＩＤ（Ｒｏｕｔｅｒ  ＩＤ）、インタフェースＩＤ（Ｉｎｔｅｒｆａｃｅ  ＩＤ）、リンク物理的帯域幅（Ｌｉｎｋ  Ｂａｎｄｗｉｄｔｈ／Ｐｈｙｓｉｃａｌ）、使用帯域幅（Ｌｉｎｋ  Ｂａｎｄｗｉｄｔｈ／Ｕｓｅｄ）、マルチキャスティングクラス（Ｃｌａｓｓ  ＩＤ）、割り当てられた帯域幅（Ｃｌａｓｓ  ＢＷ／Ａｌｌｏｃａｔｅｄ）、使用可能な帯域幅情報（Ｃｌａｓｓ  ＢＷ／Ｕｎｕｓｅｄ）などを含む。
【００５２】
リンクＩＤは、マルチキャスティングネットワークの隣接する２つのルータ間の連結を意味する識別子である。１つのリンクＩＤに２つのルータのＩＤ及びインタフェースＩＤ情報が格納された場合は、リンクの両方の終端点に２つのルータが連結されたケースである。また、１つのルータのＩＤ及びインタフェースＩＤ情報が格納された場合は、リンクの一方の終端点がソース又は受信端末に連結されたケースに該当する。
【００５３】
リンク物理的帯域幅は、各リンクが物理的に最大サポート可能な帯域幅を意味し、使用帯域幅は、最大サポート可能な帯域幅のうち実際に使用している帯域幅を意味する。また、リソーステーブルは、マルチキャスティングサービスを優先順位などの基準によって各クラス毎に区分し（Ｃｌａｓｓ  ０、１、３）、各クラス毎に割り当てられた帯域幅及び使用可能な可能な帯域情報を含む。
【００５４】
表１のリソーステーブルは、帯域幅情報を含んでいるが、帯域幅情報だけでなく、遅延時間情報、遅延分散情報などのようなネットワークリソース情報を含むことができる。
【００５５】
リソース管理モジュール（ＴＲＭ）２３は、収集、格納しているデータをポリシー管理モジュール（ＰＭ）２１に伝達する。これを用いてポリシー管理モジュール（ＰＭ）２１は、運用者によって設定されたポリシーによってネットワーク構成要素を制御するためにポリシー適用モジュール（ＰＤＭ）２２にポリシーを伝達する。
【００５６】
ポリシー適用モジュール（ＰＤＭ）２２は、ポリシー管理モジュール（ＰＭ）２１から受信したポリシーを、ルータのようなネットワーク構成要素が解析できる命令に変換し、ルータ連結モジュール（ＲＣＭ）２５を介してネットワーク構成要素に伝達する。また、呼処理モジュール（ＣＭ）２４は、新規なマルチキャスティングサービスが要請される場合には、リソース管理モジュール２３に連動してマルチキャスティングサービスの収容可否を判断できる。
【００５７】
以下、マルチキャスティング制御システム２０がルータ間におけるリンクの帯域幅を用いてマルチキャスティングネットワークを制御する方法を例に取って説明する。
【００５８】
すなわち、第１のリンクの帯域幅が１００であり、マルチキャスティングサービスクラス（Ｍｕｌｔｉｃａｓｔｉｎｇ  Ｓｅｒｖｉｃｅ  Ｃｌａｓｓ）が４種類である場合、運用者は、各サービスクラス毎に３０％、２０％、１５％、１０％の帯域幅を最大利用可能帯域幅に各々割り当てることができる。もちろん、このような帯域幅の割当は、運用者のポリシーによって変わり、リンクの余裕リソースを考慮するために、各クラス毎に最大利用可能帯域幅の合計が必ず１００％である必要もない。
【００５９】
このような運用者のポリシーは、運用者インタフェース７０を介してマルチキャスティング制御システム２０のポリシー管理モジュール（ＰＭ）２１に入力される。ポリシー管理モジュール（ＰＭ）２１から各クラス毎の帯域幅割当ポリシーを伝達されたポリシー適用モジュール（ＰＤＭ）２２は、ルータ連結モジュール（ＲＣＭ）２５を介して各ルータ（Ｒｏｕｔｅｒ１〜Ｒｏｕｔｅｒ５）４１〜４５に帯域幅割当命令を伝達する。
【００６０】
また、ルータ（Ｒｏｕｔｅｒ１〜Ｒｏｕｔｅｒ５）４１〜４５は、各ルータ（Ｒｏｕｔｅｒ１〜Ｒｏｕｔｅｒ５）４１〜４５の入出力インタフェースｉｆ１〜ｉｆ１４を制御し、各クラス毎に帯域幅を割り当てる。すなわち、クラス０は、３０、クラス１は、２０、クラス２は、１５、クラス３は、１０の最大帯域幅を割り当てられる。帯域幅の割当が完了した後、リソース管理モジュール２３は、ポリシー管理モジュール（ＰＭ）２１から帯域幅割当情報を受信したり、ルータ連結モジュール（ＲＣＭ）２５を介して各リンクの帯域幅割当情報を収集するようになる。
【００６１】
呼処理モジュール（ＣＭ）２４は、新規なマルチキャスティングサービスが要請される場合、新規なマルチキャスティングサービスに必要な帯域幅より使用可能な帯域幅が多い場合にだけ、新規サービスを受け入れる。このような新規なサービス要請及び収容に関する判断結果は、運用者インタフェース７０に報告される。
【００６２】
例えば、２０の必要帯域幅を有するクラス０の第１のマルチキャスティングサービスが要請された場合には、使用可能な帯域幅が３０であるから、呼処理モジュール（ＣＭ）２４は、第１のマルチキャスティングサービスを受け入れる。この場合、２５の必要帯域幅を有するクラス０の第２のマルチキャスティングサービスがさらに要請された場合には、現在使用可能な帯域幅が１０であるから、呼処理モジュール（ＣＭ）２４は、第２のマルチキャスティングサービスを受け入れないようになる。
【００６３】
図４Ａは、ソースからランデブーポイントまでリソースが存在しない場合のマルチキャスティングネットワークを示すブロック図であり、図４Ｂは、図４Ａの場合に適用されるマルチキャスティング制御方法を示すフローチャートである。
【００６４】
ソース（Ｓ１）３０は、第１のルータ（Ｒｏｕｔｅｒ１）４１にマルチキャスティングパケットを転送する（ステップＳ４０１。なお、図中においてはステップをＳと略す。）。これを受信した第１のルータ（Ｒｏｕｔｅｒ１）４１は、Ｓ、Ｇステート（Ｓｔａｔｅ）を生成し（ステップＳ４０２）、マルチキャスティング制御システム２０内のルータ連結モジュール（ＲＣＭ）２５を経て呼処理モジュール（ＣＭ）２４に呼設定要請メッセージ（ＣＡＣ  Ｒｅｑｕｅｓｔ  Ｍｅｓｓａｇｅ）を転送する（ステップＳ４０３）。
【００６５】
呼設定要請メッセージは、ソース（Ｓ１）３０のＩＰアドレス、マルチキャスティンググループアドレス、ランデブーポイント（ＲＰ）６０のＩＰアドレス、帯域幅、サービスクラスなどの情報を含む。呼設定要請メッセージを転送するためには、第１のルータ（Ｒｏｕｔｅｒ１）４１がマルチキャスティングデータの帯域幅またはデータレート（Ｄａｔａ  Ｒａｔｅ）を把握していなければならないが、これは、ソース（Ｓ１）３０から受信したＩＰパケット内のＴＯＳ／ＤＳＣＰ（Ｔｙｐｅ  ｏｆ  Ｓｅｒｖｉｃｅ／Ｄｉｆｆｓｅｒｖ  Ｃｏｄｅ  Ｐｏｉｎｔ）フィールドなどを用いて把握することができる。もちろん、ソース（Ｓ１）３０と第１のルータ（Ｒｏｕｔｅｒ１）４１との間の別途のメッセージ交換を用いて把握することもできる。
【００６６】
呼設定要請メッセージを受信した呼処理モジュール（ＣＭ）２４は、第１のルータ（Ｒｏｕｔｅｒ１）４１からランデブーポイント（ＲＰ）６０までのリンク上に使用可能な帯域幅が存在するか否かを確認する。このために、呼処理モジュール（ＣＭ）２４は、リソース管理モジュール（ＴＲＭ）２３に第１のルータ（Ｒｏｕｔｅｒ１）４１からランデブーポイント（ＲＰ）６０までのリンク及び使用可能なリソースを照会（Ｑｕｅｒｙ）要請する（ステップＳ４０４）。リソース管理モジュール（ＴＲＭ）２３は、第１のルータ（Ｒｏｕｔｅｒ１）４１からランデブーポイント（ＲＰ）６０までの経路及びリソースを探索し、所定の帯域幅を要求するサービスの収容可否をチェックする（ステップＳ４０５）。
【００６７】
このようなサービスの収容可否は、各リンク毎の使用可能な帯域幅（Ｕｎｕｓｅｄ  Ｂａｎｄｗｉｄｔｈ）値を参照して把握することができる。図４の例は、第１のルータ（Ｒｏｕｔｅｒ１）４１と第２のルータ（Ｒｏｕｔｅｒ２）４２間におけるリンクのリソースが足りない場合であるから、リソース管理モジュール（ＴＲＭ）２３は、サービス収容が不可能であるという応答を呼処理モジュール（ＣＭ）２４に転送する（ステップＳ４０６）。
【００６８】
これを受信した呼処理モジュール（ＣＭ）２４は、第１のルータ（Ｒｏｕｔｅｒ１）４１及びマルチキャスティング制御システム２０内のポリシー管理モジュール（ＰＭ）２１に第１のルータ（Ｒｏｕｔｅｒ１）４１とランデブーポイント（ＲＰ）６０間のリソース不足を通知する（ステップＳ４０７）。このようなリソース不足通知は、第１のルータ（Ｒｏｕｔｅｒ１）４１とランデブーポイント（ＲＰ）６０間におけるリソースが足りない特定のリンクに関する情報などを含むことができる。
【００６９】
リソース不足通知を受信したポリシー管理モジュール（ＰＭ）２１は、運用者インタフェース（ＧＵＩ）２６を介して運用者にリソース不足を通知する（ステップＳ４０８）。これを受信した運用者は、ポリシーを変更して上記問題を解決することができる。このようなポリシーは、各クラス毎の最大利用可能帯域幅の増減の調整、他のマルチキャスティングサービスの中断、その他のデータパケットの転送中断などのポリシーなどが可能である。
【００７０】
もちろん、このようなポリシーは、予めポリシー管理モジュール（ＰＭ）２１に格納され、必要に応じて、運用者の操作を経ることなく、適用されることもできる。ポリシー管理モジュール（ＰＭ）２１は、ネットワークを制御するためのポリシーをポリシー適用モジュール（ＰＤＭ）２２に転送する（ステップＳ４０９）。
【００７１】
本実施形態において、運用者は、第１のルータ（Ｒｏｕｔｅｒ１）４１がパケットをドロップするポリシー（Ｐａｃｋｅｔ  Ｄｒｏｐ  Ｐｏｌｉｓｈ）を設定しており、このようなポリシーは、第１のルータ（Ｒｏｕｔｅｒ１）４１に伝達される（ステップＳ４１０）。最後に、第１のルータ（Ｒｏｕｔｅｒ１）４１は、ステップＳ４０３〜Ｓ４１０の過程を繰り返すことによって、サービス収容可否を、一定の回数または期間に亘ってチェックする。
【００７２】
図５Ａは、共有ツリー上にリソースがあるリンクとリソースがないリンクが存在する場合のマルチキャスティングネットワークを示すブロック図であり、図５Ｂは、図５Ａの場合に適用されるマルチキャスティング制御方法を示すフローチャートである。
【００７３】
図５の制御方法は、ランデブーポイント（ＲＰ）６０に共有ツリー（＊．Ｇ）が登録されていて、ランデブーポイント（ＲＰ）６０のインタフェースのうちｉｆ８は、リソース不足状態からリソース存在状態に変更される場合に適用される。
【００７４】
リソース管理モジュール（ＴＲＭ）２３は、呼処理モジュール（ＣＭ）２４の要請によって第１のルータ（Ｒｏｕｔｅｒ１）４１とランデブーポイント（ＲＰ）６０との間の使用可能なリソースを検索した結果、要請されたマルチキャスティングサービスに対する使用可能なリソースが存在するので、呼処理モジュール（ＣＭ）２４にサービス収容が可能であるという応答を転送する（ステップＳ５０１）。
【００７５】
第１のルータ（Ｒｏｕｔｅｒ１）４１とランデブーポイント（ＲＰ）６０間のサービス収容が可能であるという通知を受けた呼処理モジュール（ＣＭ）２４は、ランデブーポイント（ＲＰ）６０にマルチキャスティンググループＧのステートを照会要請する（ステップＳ５０２）。このようなステート照会は、ランデブーポイント（ＲＰ）６０がマルチキャスティンググループＧのためのパケットを出力するか否かをチェックすることができる。
【００７６】
この際、マルチキャスティングステート照会要請時に、マルチキャスティンググループのアドレス情報をも転送することによって、状態照会を要請したマルチキャスティンググループを判別することができる。このような照会要請に対してランデブーポイント（ＲＰ）６０は、入出力インタフェースのうちフォワード状態であるインタフェースの情報を含む応答を呼処理モジュール（ＣＭ）２４に転送する（ステップＳ５０３）。
【００７７】
応答メッセージに含まれる情報には、マルチキャスティンググループアドレス、フォワード状態であるインタフェース目録などが存在する。図５を参照すれば、ランデブーポイント（ＲＰ）６０のインタフェースｉｆ５、ｉｆ６、ｉｆ８、ｉｆ１０のうちｉｆ６とｉｆ８だけがフォワード状態に該当するので、応答メッセージは、ｉｆ６、ｉｆ８を含むようになる。
【００７８】
呼処理モジュール（ＣＭ）２４は、リソース管理モジュール（ＴＲＭ）２３にフォワード状態であるｉｆ６、ｉｆ８のリソース状態を照会要請する（ステップＳ５０４）。これにより、リソース管理モジュール（ＴＲＭ）２３は、ｉｆ６及びｉｆ８のリソース状態及び次のホップルータを検索する（ステップＳ５０５）。
【００７９】
リソース管理モジュール（ＴＲＭ）２３は、検索結果を呼処理モジュール（ＣＭ）２４に転送する（ステップＳ５０６）。図５Ａに示されたように、ｉｆ６には、使用可能なリソースがあり、且つｉｆ８には、使用可能なリソースがないという応答が、呼処理モジュール（ＣＭ）２４に通知される。
【００８０】
その後、呼処理モジュール（ＣＭ）２４は、使用可能なリソースが存在するｉｆ６の次のホップルータである第３のルータ（Ｒｏｕｔｅｒ３）４３にマルチキャスティング状態照会を要請する（ステップＳ５０７）。これに対して、第３のルータ（Ｒｏｕｔｅｒ３）４３は、同様にフォワード状態のインタフェース目録を呼処理モジュール（ＣＭ）２４に転送する（ステップＳ５０８）。
【００８１】
図５Ａで、第３のルータ（Ｒｏｕｔｅｒ３）４３は、フォワード状態であるｉｆ１２を呼処理モジュール（ＣＭ）２４に通知する。これに対して、呼処理モジュール（ＣＭ）２４は、再びｉｆ１２に対するリソース照会を要請し（ステップＳ５０９）、リソース管理モジュール（ＴＲＭ）２３は、ｉｆ１２及び次のホップルータを検索し、その結果を呼処理モジュール（ＣＭ）２４に通知する（ステップＳ５１０、ステップＳ５１１）。このような作業は、次のホップルータが受信端末に直接連結されたルータとなるまで続く。
【００８２】
一方、呼処理モジュール（ＣＭ）２４は、使用可能なリソースが存在しないｉｆ８に対してポリシー管理モジュール（ＰＭ）２１に使用可能なリソース不足を通知する（ステップＳ５１２）。これを受信したポリシー管理モジュール（ＰＭ）２１は、運用者インタフェース（ＧＵＩ）２６を介して運用者に通知し（ステップＳ５１３）、運用者から入力されたポリシーをポリシー適用モジュール（ＰＤＭ）２２に転送する（ステップＳ５１４）。
【００８３】
ポリシー適用モジュール（ＰＤＭ）２２は、運用者のポリシーに従うマルチキャスティングドロップ命令をランデブーポイント（ＲＰ）６０に転送する（ステップＳ５１５）。呼処理モジュール（ＣＭ）２４は、第１のルータ（Ｒｏｕｔｅｒ１）４１に登録修正メッセージを転送し、今まで修正されたネットワークトポロジーに基づいてマルチキャスティングサービス環境を再設定する（ステップＳ５１６）。
【００８４】
以上で説明した呼収容判断過程を終了したマルチキャスティング制御システム２０は、一般的なＰＩＭ−ＳＭと同じ方法を用いてマルチキャスティングデータを転送できる。
【００８５】
すなわち、その後、呼処理モジュール（ＣＭ）２４は、変更されたポリシーを反映するために、リソース管理モジュール（ＴＲＭ）２３にリソース情報アップデート命令を伝達し（ステップＳ５１７）、リソース管理モジュール（ＴＲＭ）２３は、リソース情報をアップデートする（ステップＳ５１８）。
【００８６】
ランデブーポイント（ＲＰ）６０のｉｆ８には、受信端末が連結されているにもかかわらず、サービスが進行されていない状態である。呼処理モジュール（ＣＭ）２４は、リソース管理モジュール（ＴＲＭ）２３にｉｆ８に関するリソース照会を持続的に行う（ステップＳ５１９）。運用者のポリシー実行結果、使用可能なリソースが発生する場合には、前述した過程と同様に、ルータインタフェースの使用可能なリソースが充分であるか否かをチェックする（ステップＳ５２０〜Ｓ５２６）。
【００８７】
呼処理モジュール（ＣＭ）２４は、ポリシー管理モジュール（ＰＭ）２１にツリーに対してサービス収容が可能であるという通知をし（ステップＳ５２７）、これにより、ポリシー管理モジュール（ＰＭ）２１は、ポリシー適用モジュール（ＰＤＭ）２２にパケットドロップ解除命令を伝達する（ステップＳ５２８）。ポリシー適用モジュール（ＰＤＭ）２２は、ランデブーポイント（ＲＰ）６０にｉｆ８の該当マルチキャスティンググループに対するパケットドロップ解除命令を伝達する（ステップＳ５２９）。
【００８８】
パケットドロップ解除命令を行った後、呼処理モジュール（ＣＭ）２４は、リソース管理モジュール（ＴＲＭ）２３にリソースアップデート命令を伝達し（ステップＳ５３０）、リソース管理モジュール（ＴＲＭ）２３は、リンクのリソース状態をアップデートする（ステップＳ５３１）。
【００８９】
前述した制御方法は、ランデブーポイント（ＲＰ）６０を基準にして適用されたものであるが、共有ツリー上の全てのルータを基準にして適用されることもできる。
【００９０】
図６Ａは、ランデブーポイント（ＲＰ）６０の入出力インタフェースがプルーン状態（Ｐｒｕｎｅ）からフォワード状態（Ｆｏｒｗａｒｄ）に変換される場合のマルチキャスティングネットワークを示すブロック図であり、図６Ｂは、図６Ａの場合に適用されるマルチキャスティング制御方法を示すフローチャートである。
【００９１】
入出力インタフェースのプルーン状態とは、入出力インタフェースを介してパケットをルーティングする受信端末または他のルータが存在しない場合を意味する。反対に、入出力インタフェースのフォワード状態は、プルーン状態と相反する概念であって、入出力インタフェースを介してパケットを受信する端末または他のルータが存在する状態を意味する。
【００９２】
ＰＩＭ−ＳＭを利用する場合には、プルーン状態は、Ｐｒｕｎｅ／Ｓｐａｒｓｅで表現し、フォワード状態は、Ｆｏｒｗａｒｄ／Ｓｐａｒｓｅで表現する。万一、ＰＩＭ−ＤＭを利用する場合には、プルーン状態は、Ｐｒｕｎｅ／Ｄｅｎｓｅで表現することができ、フォワード状態は、Ｆｏｒｗａｒｄ／Ｄｅｎｓｅで表現することができる。
【００９３】
第５のルータ４５に新規に第３の受信端末（Ｒ３）５３が連結される場合には、第３の受信端末（Ｒ３）５３は、マルチキャスティンググループＧに加入するために、第５のルータ４５にＩＧＭＰ加入メッセージを転送する（ステップＳ６０１）。
【００９４】
これにより、第５のルータ４５は、マルチキャスティンググループＧに対する（＊、Ｇ）ステートを生成し（ステップＳ６０２）、第５のルータ４５は、共有ツリー加入のためにランデブーポイント（ＲＰ）６０にＰＩＭ加入メッセージを転送する（ステップＳ６０３）。この際、ランデブーポイント（ＲＰ）６０は、プルーン状態であったｉｆ１０をフォワード状態に変換する（ステップＳ６０４）。
【００９５】
ランデブーポイント（ＲＰ）６０は、マルチキャスティング制御システム２０の呼処理モジュール（ＣＭ）２４にｉｆ１０の状態変換メッセージを転送する（ステップＳ６０５）。この場合には、状態変換メッセージは、マルチキャスティンググループアドレス、フォワード状態に変換されたインタフェース目録などの情報を含むことができる。
【００９６】
これを受信した呼処理モジュール（ＣＭ）２４は、リソース管理モジュール（ＴＲＭ）２３にｉｆ１０に対するリソースを照会するように要請し（ステップＳ６０６）、リソース管理モジュール（ＴＲＭ）２３は、前述した方法によってｉｆ１０のリソース状態及び次のホップルータを検索し（ステップＳ６０７）、実施形態でリソース管理モジュール（ＴＲＭ）２３は、呼処理モジュール（ＣＭ）２４にリソースが存在するという応答を転送する（ステップＳ６０８）。
【００９７】
呼処理モジュール（ＣＭ）２４は、ｉｆ１０の次のホップルータである第５のルータ４５に（＊、Ｇ）ステートを照会し（ステップＳ６０９）、第５のルータ４５は、フォワード状態であるｉｆ１４情報を呼処理モジュール（ＣＭ）２４に転送することによって応答する（ステップＳ６１０）。
【００９８】
上記応答に対して呼処理モジュール（ＣＭ）２４は、さらにリソース管理モジュール（ＴＲＭ）２３にｉｆ１４に対してリソースを照会要請し（ステップＳ６１１）、リソース管理モジュール（ＴＲＭ）２３は、ｉｆ１４に対するリソース情報及び次のホップルータを検索し（ステップＳ６１２）、呼処理モジュール（ＣＭ）２４に通知する（ステップＳ６１３）。
【００９９】
図５で説明した通り、このようなリソース検索過程は、受信端末５３に直接連結される第５のルータ４５まで行われる。図６の例で、第５のルータ４５は、第３の受信端末（Ｒ３）５３に直接連結されたルータであるから、これ以上のリソース探索過程は存在しない。
【０１００】
その後、呼処理モジュール（ＣＭ）２４が、ポリシー管理モジュール（ＰＭ）２１によってポリシーを設定し、ポリシー管理モジュール（ＰＭ）２１がポリシー適用モジュール（ＰＤＭ）２２によって設定されたパケットフォワード命令を伝達するようにし（ステップＳ６１４）、ポリシー適用モジュール（ＰＤＭ）２２は、ランデブーポイント（ＲＰ）６０にパケットをｉｆ１０にフォワードする命令を転送する（ステップＳ６１５）。
【０１０１】
そして、呼処理モジュール（ＣＭ）２４は、リソース管理モジュール（ＴＲＭ）２３がネットワークのリソース状態をアップデートする命令を伝達し（ステップＳ６１６）、これにより、リソース管理モジュール（ＴＲＭ）２３は、リソースアップデートを行う（ステップＳ６１７）。
【０１０２】
もちろん、以上で説明した手続は、ランデブーポイント（ＲＰ）６０だけでなく、共有ツリー上に存在する全てのルータに同様に適用されることができる。
【０１０３】
図７Ａは、ランデブーポイント（ＲＰ）６０の入出力インタフェースがフォワード状態からプルーン状態に変換される場合のマルチキャスティングネットワークを示すブロック図であり、図７Ｂは、図７Ａの場合に適用される本発明のさらに他の実施形態のマルチキャスティング制御方法を示すフローチャートである。
【０１０４】
マルチキャスティンググループからの脱退を望む第１の受信端末（Ｒ１）５１は、第３のルータ（Ｒｏｕｔｅｒ３）４３にＩＧＭＰ脱退メッセージ（ＩＧＭＰ  Ｌｅａｖｅ  Ｍｅｓｓａｇｅ）を転送する（ステップＳ７０１）。
【０１０５】
ＩＧＭＰ脱退メッセージを受信した第３のルータ（Ｒｏｕｔｅｒ３）４３は、ｉｆ１２インタフェースを介してマルチキャスティングパケットを転送する必要がないので、ｉｆ１２のパケット転送状態をプルーン状態に変換し（ステップＳ７０２）、ランデブーポイント（ＲＰ）６０にＰＩＭプルーンメッセージ（ＰＩＭ  Ｐｒｕｎｅ  Ｍｅｓｓａｇｅ）を転送する（ステップＳ７０３）。
【０１０６】
ＰＩＭプルーンメッセージを受信したランデブーポイント（ＲＰ）６０は、第３のルータ（Ｒｏｕｔｅｒ３）４３と同様の理由で、（＊、Ｇ）ステート上のｉｆ６をプルーン状態に変換する（ステップＳ７０４）。その後、マルチキャスティング制御システム２０の呼処理モジュール（ＣＭ）２４にｉｆ６のプルーン状態変換メッセージを転送する（ステップＳ７０５）。
【０１０７】
これを受信した呼処理モジュール（ＣＭ）２４は、リソース管理モジュール（ＴＲＭ）２３にリソース情報アップデート命令を伝達し（ステップＳ７０６）、これにより、リソース管理モジュール（ＴＲＭ）２３は、ネットワークの各リンク毎のリソース情報を調べてアップデートする（ステップＳ７０７）。この場合、リソース管理モジュール（ＴＲＭ）２３は、プルーン状態であるランデブーポイント（ＲＰ）６０のｉｆ６、第３のルータ（Ｒｏｕｔｅｒ３）４３のｉｆ１２に対してもリソースアップデートを行う。
【０１０８】
第２の受信端末（Ｒ２）５２と第３の受信端末（Ｒ３）５３の脱退過程は、前述した第１の受信端末（Ｒ１）５１の脱退過程と同様に行われる（ステップＳ７０８〜Ｓ７２１）。
【０１０９】
第１の受信端末（Ｒ１）５１、第２の受信端末（Ｒ２）５２、第３の受信端末（Ｒ３）５３がいずれもマルチキャスティンググループＧから脱退することによって、ランデブーポイント（ＲＰ）６０自体がプルーン状態に変更される。すなわち、ランデブーポイント（ＲＰ）６０は、プルーン状態のインタフェースだけを含む。
【０１１０】
万一、第１のルータ（Ｒｏｕｔｅｒ１）４１からランデブーポイント（ＲＰ）６０までマルチキャスティングデータを転送する場合、このようなデータは、目的地が存在しないデータに該当するのでネットワークのリソースが浪費される。以下、このような問題点を解決するためのマルチキャスティング制御方法について説明する。
【０１１１】
ランデブーポイント（ＲＰ）６０は、呼処理モジュール（ＣＭ）２４を介して（ステップＳ７２２）ポリシー管理モジュール（ＰＭ）２１に（＊、Ｇ）ステートの全てのインタフェースがプルーン状態に変換されたことを通知する（ステップＳ７２３）。その後、ポリシー管理モジュール（ＰＭ）２１は、この状況に対するポリシーをポリシー適用モジュール（ＰＤＭ）２２に伝達し（ステップＳ７２４）、ポリシー適用モジュール（ＰＤＭ）２２は、第１のルータ（Ｒｏｕｔｅｒ１）４１にポリシーを伝達する（ステップＳ７２５）。
【０１１２】
図７では、ランデブーポイント（ＲＰ）６０の全てのインタフェースがプルーン状態に変更された場合、マルチキャスティングソース（Ｓ１）３０に直接連結された第１のルータ（Ｒｏｕｔｅｒ１）４１がマルチキャスティンググループＧに属するパケットをドロップするようにするポリシーが適用される。これは、第１のルータ（Ｒｏｕｔｅｒ１）４１からマルチキャスティングソース（Ｓ１）３０までパケットを転送しないことによって、受信端末が存在しない場合にも、パケットが転送され、リソースが浪費されることを防止するためである。
【０１１３】
ポリシー命令の伝達後、呼処理モジュール（ＣＭ）２４は、リソース管理モジュール（ＴＲＭ）２３が第１のルータ（Ｒｏｕｔｅｒ１）４１、ランデブーポイント（ＲＰ）６０間のリソースをアップデートするように制御する（ステップＳ７２６）。このような制御によって、リソース管理モジュール（ＴＲＭ）２３は、リソースアップデート機能を行う（ステップＳ７２７）。
【０１１４】
以上で説明したマルチキャスティング制御方法は、ランデブーポイント（ＲＰ）６０のインタフェースがプルーン状態に変換される場合だけでなく、共有ツリー上に存在するルータのインタフェースがプルーン状態に変換される場合にも適用が可能である。また、図７では、受信端末のマルチキャスティンググループ脱退動作をＩＧＭＰ  ｖ２を基盤にして説明したが、この動作は、ＩＧＭＰ  ｖ１でも同様に適用が可能である。
【０１１５】
図８Ａは、ランデブーポイント（ＲＰ）６０上に当該マルチキャスティンググループに対する共有ツリーが生成されない場合のマルチキャスティングネットワークを示すブロック図であり、図８Ｂは、図８Ａの場合に適用されるマルチキャスティング制御方法を示すフローチャートである。
【０１１６】
リソース管理モジュール（ＴＲＭ）２３は、呼処理モジュール（ＣＭ）２４が要請した第１のルータ（Ｒｏｕｔｅｒ１）４１とランデブーポイント（ＲＰ）６０間のリソース照会要請に対して、該当リンクの使用可能なリソースを検索する。該検索結果、第１のルータ（Ｒｏｕｔｅｒ１）４１とランデブーポイント（ＲＰ）６０間に要請されたマルチキャスティングサービスに対する使用可能なリソースが存在する場合には、リソース管理モジュール（ＴＲＭ）２３は、新規なマルチキャスティングサービスの収容が可能であるという応答を呼処理モジュール（ＣＭ）２４に転送する（ステップＳ８０１）。
【０１１７】
応答メッセージを受信した呼処理モジュール（ＣＭ）２４は、ランデブーポイント（ＲＰ）６０に（＊、Ｇ）ステート照会要請メッセージを転送する（ステップＳ８０２）。これを受信したランデブーポイント（ＲＰ）６０には、マルチキャスティンググループＧに属するサービス受信端末が存在しないので、（＊、Ｇ）ステートが存在しないという応答を通知し（ステップＳ８０３）、このような応答は、呼処理モジュール（ＣＭ）２４を介してポリシー管理モジュール（ＰＭ）２１に伝達される（ステップＳ８０４）。
【０１１８】
ポリシー管理モジュール（ＰＭ）２１は、ポリシー適用モジュール（ＰＤＭ）２２に既設定されたポリシーを転送するようになり（ステップＳ８０５）、これは、第１のルータ（Ｒｏｕｔｅｒ１）４１に伝達される（ステップＳ８０６）。このような状況で適用可能なポリシーとして、第１のルータ（Ｒｏｕｔｅｒ１）４１のマルチキャスティンググループパケットドロップポリシーなどが挙げられる。
【０１１９】
図９Ａは、ランデブーポイント（ＲＰ）６０上にマルチ・キャスティンググループに対して共有ツリーが生成された場合のマルチキャスティングネットワークを示すブロック図であり、図９Ｂは、図９Ａの場合に適用される本実施形態のマルチキャスティング制御方法を示すフローチャートである。
【０１２０】
マルチキャスティンググループＧに加入したい第１の受信端末（Ｒ１）５１は、第３のルータ（Ｒｏｕｔｅｒ３）４３にＩＧＭＰ加入メッセージを転送する（ステップＳ９０１）。メッセージを受信した第３のルータ（Ｒｏｕｔｅｒ３）４３は、（＊、Ｇ）ステートを生成し（ステップＳ９０２）、共有ツリーの加入のためにランデブーポイント（ＲＰ）６０にＰＩＭ加入メッセージを転送する（ステップＳ９０３）。
【０１２１】
ランデブーポイント（ＲＰ）６０も、以前にはマルチキャスティンググループＧのためのサービスを提供しなかったので、新しく（＊、Ｇ）ステートを生成する（ステップＳ９０４）。その後、ランデブーポイント（ＲＰ）６０は、ステート生成通知メッセージをマルチキャスティング制御システム２０の呼処理モジュール（ＣＭ）２４に転送する（ステップＳ９０５）。
【０１２２】
なお、ステップＳ９０６〜Ｓ９１８の手続は、前述したので、その説明を省略する。このように新規なマルチキャスティングサービスの収容が完了した後、ポリシー管理モジュール（ＰＭ）２１は、ポリシー適用モジュール（ＰＤＭ）２２を介して（ステップＳ９１９）パケットドロップ解除命令と登録実行命令を第１のルータ（Ｒｏｕｔｅｒ１）４１に伝達する（ステップＳ９２０、Ｓ９２１）。リソース管理モジュール（ＴＲＭ）２３は、呼処理モジュール（ＣＭ）２４の制御によって（ステップＳ９２２）ネットワークのリソースをアップデートする過程を行う（ステップＳ９２３）。
【０１２３】
以上、本発明の好ましい実施形態を説明したが、本発明は、上述した特許請求の範囲と発明の詳細な説明及び添付された図面に限定されるものではなく、本発明の技術的思想を逸脱しない範囲内で、様々な置換、変形及び変更が可能である。
【０１２４】
例えば、本発明では、主にＰＩＭ−ＳＭプロトコルを用いたマルチキャスティング制御システムまたはマルチキャスティング制御方法について説明したが、当業者なら本発明で説明した技法を、マルチキャスティングのためのＤＶＲＭＰ、ＭＯＳＰＦ、ＣＢＴ、ＰＩＭ−ＤＭ、ＰＩＭ−ＳＭなどのプロトコルに容易に適用可能であろう。
【図面の簡単な説明】
【０１２５】
【図１】従来のＰＩＭ−ＳＭを用いたマルチキャスティングネットワークの動作方法を示すブロック図。
【図２】本発明の一実施形態のマルチキャスティング制御システムを含むマルチキャスティングネットワークを示すブロック図。
【図３】本発明の一実施形態のマルチキャスティング制御システムの内部構造を示すブロック図。
【図４Ａ】ソースからランデブーポイントまでリソースが存在しない場合のマルチキャスティングネットワークを示すブロック図。
【図４Ｂ】図４Ａの場合に適用される本発明の他の実施形態のマルチキャスティング制御方法を示すフローチャート。
【図５Ａ】共有ツリー上にリソースがあるリンクとリソースがないリンクが存在する場合のマルチキャスティングネットワークを示すブロック図。
【図５Ｂ】図５Ａの場合に適用される本発明のさらに他の実施形態のマルチキャスティング制御方法を示すフローチャート。
【図６Ａ】ランデブーポイントの入出力インタフェースがプルーン状態（Ｐｒｕｎｅ）からフォワード状態（Ｆｏｒｗａｒｄ）に変換される場合のマルチキャスティングネットワークを示すブロック図。
【図６Ｂ】図６Ａの場合に適用される本発明のさらに他の実施形態のマルチキャスティング制御方法を示すフローチャート。
【図７Ａ】ランデブーポイントの入出力インタフェースがフォワード状態からプルーン状態に変換される場合のマルチキャスティングネットワークを示すブロック図。
【図７Ｂ】図７Ａの場合に適用される本発明のさらに他の実施形態のマルチキャスティング制御方法を示すフローチャート。
【図８Ａ】ランデブーポイント上に該当マルチキャスティンググループに対する共有ツリーが生成されない場合のマルチキャスティングネットワークを示すブロック図。
【図８Ｂ】図８ａの場合に適用される本発明のさらに他の実施形態のマルチキャスティング制御方法を示すフローチャート。
【図９Ａ】ランデブーポイント上にマルチキャスティンググループに対して共有ツリーが生成された場合のマルチキャスティングネットワークを示すブロック図。
【図９Ｂ】図９Ａの場合に適用される本発明のさらに他の実施形態のマルチキャスティング制御方法を示すフローチャート。
【符号の説明】
【０１２６】
２０  マルチキャスティング制御システム
３０  ソース
４１、４２、４３、４４、４５  ルータ
５１、５２、５３  受信端末
６０  ランデブーポイント
【図１】
2007181205.tif 000004
【図２】
2007181205.tif 000005
【図３】
2007181205.tif 000006
【図４Ａ】
2007181205.tif 000007
【図４Ｂ】
2007181205.tif 000008
【図５Ａ】
2007181205.tif 000009
【図５Ｂ】
2007181205.tif 000010
【図６Ａ】
2007181205.tif 000011
【図６Ｂ】
2007181205.tif 000012
【図７Ａ】
2007181205.tif 000013
【図７Ｂ】
2007181205.tif 000014
【図８Ａ】
2007181205.tif 000015
【図８Ｂ】
2007181205.tif 000016
【図９Ａ】
2007181205.tif 000017
【図９Ｂ】
2007181205.tif 000018