JP2004228968A

JP2004228968A - Streaming controller

Info

Publication number: JP2004228968A
Application number: JP2003014884A
Authority: JP
Inventors: Shuji Inoue; 修二井上; Jun Haneda; 潤羽根田; Hong Chen; ホングチェン; Peku Yau Tan; ペクヤウタン
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2003-01-23
Filing date: 2003-01-23
Publication date: 2004-08-12

Abstract

<P>PROBLEM TO BE SOLVED: To provide a streaming controller which efficiently controls a traffic over a subnet to reduce the traffic. <P>SOLUTION: A streaming controller concerns an engine handling IGMP messages related to IGMP protocols and is utilized in a process on the router side operated in conformity with IGMP protocols. The engine manages multicast traffic forwarding information database including information of receivers. More concretely, the engine records a receiver each time the receiver transmits an IGMP Membership_Report message being an IGMP message to the streaming controller. Since the engine can immediately finds whether another receiver desiring the same traffic exist or not by recorded information of receivers, the engine immediately stops forwarding in the case of the absence of other receivers desiring the traffic when receiving an IGMP Leave_Group message. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上のトラヒックを効率化して小さくすることのできるストリーミング制御装置に関する。
【０００２】
【従来の技術】
マルチキャスト技術は、ＩＰネットワーク上にある複数の受信機にオーディオビジュアルコンテンツをリアルタイムで配信するための重要な技術である。当該マルチキャスト技術は、従来のユニキャスト技術とは異なり、新しい受信機からコンテンツが要求されても新しい複製を作る必要がないため、貴重なネットワーク資源を節約することができる。この効果は、特に広帯域を必要とするコンテンツ、例えば単一ストリームで有効ネットワーク帯域幅の大部分を必要とするＭＰＥＧコンテンツ等の配信に有用であるため、このようなコンテンツをインターネットで配信する方法としてマルチキャスト技術が利用されている。
【０００３】
マルチキャスト技術を利用したコンテンツ配信源（以下「マルチキャスト配信源」という。）は、クラスＤのＩＰアドレス空間（２２４．０．０．０〜２３９．２５５．２５５．２５５）において、任意のユニキャストＩＰアドレスの代わりに当該グループアドレス中のＩＰアドレスを用いて所定のデータパケットを送信する。コンテンツの配信を要請する受信機が「ＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）Ｍｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」をマルチキャストルータ（以下、単に「ルータ」という。）に送信すると、当該ルータは宛先アドレスとしてグループアドレス付きパケットを受信機に送信する。また、コンテンツの配信を要請しないとき、受信機は「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」をルータに送信する。当該メッセージを受信したルータは、「ＩＧＭＰＧｒｏｕｐ＿Ｑｕｅｒｙメッセージ」を送出して、このグループのトラヒックに関係している受信機が同一サブネット中に存在するかを調べる。そして、当該ルータは、所定時間内に応答がなければグループのトラヒックをサブネットに転送するのを停止する。
【０００４】
ＩＧＭＰプロトコルはマルチキャスト技術の基礎である。現在のところ、当該ＩＧＭＰプロトコルに対して、受信機がルータにグループのみでなく受信を望むトラヒックのマルチキャスト配信源をも知らせることのできるマルチキャスト技術に主に的を絞った改善が行われている。このような改善が施されたＩＧＭＰプロトコルによって、マルチキャスト配信源からトラヒックを望む受信機のないサブネットに転送される不要なトラヒックを減らすことができる。これは、マルチキャスト技術の活用とグループアドレス空間の制限の観点から鑑みて、マルチキャスト技術の発展にとって重要である。
【０００５】
【発明が解決しようとする課題】
上述したように、ＩＧＭＰプロトコルによる「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」を利用したプロセスにはいくらかのディレイがある。すなわち、最終メンバー照会カウントに最終メンバー照会間隔を掛け合わせた時間後でなければ、マルチキャストルータはサブネットへのグループのトラヒックの転送を中止しない。このディレイは、受信機がサブネットに要請していない余分なトラヒックをもたらすこととなる。
【０００６】
このため、所定のグループを残し別のグループを接合するといった受信機による高速グループ走査が行われる際に、重大な問題を引起す可能性がある。すなわち、上記ディレイ中に、ルータは古いグループのトラヒックをサブネットになお転送し、同時に、ルータが新しいグループに対する「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」を受信した直後に新しいグループのトラヒックをサブネットに転送するため、このサブネット上のトラヒックは２倍になってしまうという問題があった。また、スイッチンググループ数が大きいと、余分のトラヒックはサブネットを渋滞させ、同じサブネット内の他のホストへのサービスを犠牲にしてしまうという問題があった。
【０００７】
これらの問題はＩＧＭＰプロトコルの「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」を利用したプロセスに起因するため、ＩＧＭＰプロトコルに基づく任意のマルチキャスト方式はその問題を受継ぐことになる。
【０００８】
本発明は、上記従来の問題に鑑みてなされたものであって、サブネット上のトラヒックを効率化して小さくすることのできるストリーミング制御装置を提供することを目的としている。
【０００９】
【課題を解決するための手段】
上記課題を解決するために、上記目的を達成するために、本発明に係るストリーミング制御装置は、受信機からの要求に応じてマルチキャストでコンテンツを配信するストリーミング制御装置であって、データ配信源から入力されたユニキャストトラヒックをマルチキャストトラヒックに変換するトラヒック変換手段と、前記コンテンツの転送状況および前記コンテンツの配信を要求した前記受信機を記憶したマルチキャストトラヒック転送情報データベースに記憶されている情報と、所定の規則とに基づいて、前記トラヒック変換手段によって変換されたマルチキャストトラヒックを配信するトラヒック配信手段と、を備えている。
【００１０】
したがって、マルチキャストトラヒック転送情報データベースに記録されている受信機の情報によって、同じトラヒックを要請する受信機が他に存在するかを直ちに知ることができるため、受信機が存在しない場合にはトラヒックの配信をすぐに停止できる。この結果、トラヒックを効率化して小さくすることができる。
【００１１】
また、本発明に係るストリーミング制御装置は、所定の間隔でＩＧＭＰメッセージを作成し送信するメッセージ送信手段と、前記メッセージ送信手段から送信された前記ＩＧＭＰメッセージと前記ＩＧＭＰメッセージの送信に対する応答に基づいて、マルチキャストトラヒック転送用の情報を更新する情報更新手段と、前記ＩＧＭＰメッセージを送信する間隔を構成する間隔設定手段と、を備えている。
【００１２】
また、本発明に係るストリーミング制御装置は、前記トラヒック変換手段は、前記データ配信源から入力されたユニキャストトラヒックのデータパケットを選択するデータパケット選択手段と、前記データパケット選択手段によって選択されたユニキャストトラヒックのデータパケットをマルチキャストトラヒックのデータパケットに変換するデータ変換手段と、を有する。
【００１３】
また、本発明に係るストリーミング制御装置は、前記マルチキャストポートで前記ＩＧＭＰメッセージを受信する際に、前記ＩＧＭＰメッセージがインターネットグループ用の「Ｍｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」であれば、そのメッセージに対応するマルチキャストグループ用のトラヒックの転送を可能にして、対応するマルチキャストグループ用のデータベースに受信機を登録し、前記ＩＧＭＰメッセージが「Ｌｅａｖｅ＿Ｇｒｏｕｐメッセージ」であれば、対応するマルチキャストグループ用のデータベースに登録されている受信機を除去し、その受信機がグループに連動しない場合に対応するマルチキャストグループ用のトラヒックの転送を無効にするようにして前記マルチキャストトラヒック転送情報データベースを更新するデータベース更新手段を備えている。
【００１４】
また、本発明に係るストリーミング制御装置は、前記トラヒック配信手段および前記データベース更新手段が、前記マルチキャストトラヒック転送情報データベースを共有する。
【００１５】
また、本発明に係るストリーミング制御装置は、マルチキャストトラヒックのデータパケットを出力する複数の出力リンクと、ユニキャストトラヒックのデータパケットを入力する複数の入力リンクと、を備えている。
【００１６】
また、本発明に係るストリーミング制御装置は、前記入力リンクが前記出力リンクの機能を備え、前記出力リンクが前記入力リンクの機能を備え、前記入力リンクを複数のデータ配信源に接続し、前記出力リンクを複数の受信機に接続している。
【００１７】
また、本発明に係るネットワークシステムは、本発明のストリーミング制御装置を備えたネットワークシステムであって、前記受信機が任意クラスタの任意のデータ配信源からデータストリームを受信可能であり、前記データ配信源に接続されたスイッチに前記ストリーミング制御装置が接続され、前記スイッチ経由で前記受信機に前記ストリーミング制御装置の各出力を接続することにより、前記データ配信源と前記受信機の複数のクラスタを支援するようネットワークが構成されている。
【００１８】
このように、ハードウェアによる制限によらずに任意の数のデータ配信源と受信機を有することのできるフレームワークが形成されるよう、複数のストリーミング制御装置が相互接続されたネットワーク構造を可能としている。
【００１９】
さらに、本発明に係るネットワークシステムは、前記ストリーミング制御装置は、高周波で前記データ配信源間を切り換えるために用いられる。
【００２０】
【発明の実施の形態】
本発明に係るストリーミング制御装置は、ＩＧＭＰプロトコルに係るＩＧＭＰメッセージを扱い、ＩＧＭＰプロトコルで動作するルータサイドでのプロセスで活用される。また、ストリーミング制御装置は、受信機の情報を含むマルチキャストトラヒック転送情報データベースを管理する。より具体的には、受信機がＩＧＭＰメッセージである「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」および「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」をストリーミング制御装置に送信するたびに、ストリーミング制御装置はそれぞれのメッセージを送信した受信機を記録又は記録の削除を行う。記録された受信機の情報によって、ストリーミング制御装置は同じトラヒックを要請する受信機が他に存在するかを直ちに知ることができるため、受信機が存在しない場合には転送をすぐに停止できるといった利点がある。
【００２１】
さらに、ストリーミング制御装置は、ユニキャストトラヒックをマルチキャストトラヒックに変換するエンジンを有する。これは、「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」による遅延の影響が最小となるように、マルチキャストトラヒックのスターティングポイントをより受信機側にするためのものである。また、ハードウェアによる制限によらずに任意の数のデータ配信源と受信機を有することのできるフレームワークが形成されるよう、複数のストリーミング制御装置が相互接続されたネットワーク構造を可能としている。
【００２２】
以下、本発明に係るストリーミング制御装置の実施の形態について、図面を参照して詳細に説明する。本実施形態のストリーミング制御装置は、例えばＩＰをベースとしたデジタルセキュリティシステムにおける高速グループスイッチングを支援する装置を提供する。
【００２３】
本実施形態のストリーミング制御装置はＩＰネットワーク上に配置される。当該ストリーミング制御装置が適切に機能するために、受信機はＩＧＭＰホストサイドのスタックを有する必要がある。すなわち、この受信機はマルチキャストトラヒックをストリーミング制御装置に要請したり、所定のマルチキャストグループをストリーミング制御装置に残すためにＩＧＭＰメッセージを利用する。
【００２４】
また、本実施形態のストリーミング制御装置は、ＲＦＣ２２３６に対応したＩＧＭＰメッセージを処理するエンジンを有するため、ネットワーク内の他のネットワークノードはスタックへの修正なくマルチキャスト信号化にＩＧＭＰを使用できる。本実施形態のストリーミング制御装置がネットワーク内に設けられると、データ配信源は、ユニキャストトラヒックを宛先アドレス（Ｕ２Ｍアドレス）を有する当該ストリーミング制御装置に送信し、ストリーミング制御装置がトラヒックを受信すると当該トラヒックをマルチキャストに変換する。
【００２５】
また、受信機が所定グループのトラヒックの受信を要請する場合、受信機はそのグループの「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐ＿ｒｅｐｏｒｔメッセージ」を本実施形態のストリーミング制御装置に送信する。ストリーミング制御装置がこのメッセージを受信すると、前記所定のグループのトラヒックを受信機が接続されたポートに転送し、同時に受信機の情報をマルチキャストトラヒック転送情報データベースに記録する。一方、受信機が所定グループのトラヒックの受信の停止を要請する場合、受信機はそのグループの「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」を本実施形態のストリーミング制御装置に送信する。ストリーミング制御装置がこのメッセージを受信するとマルチキャストトラヒック転送情報データベースを調べ、他の受信機が同じポート上で同じグループのトラヒックを要請していないなら、そのポートにグループのトラヒックを転送するのを停止する。
【００２６】
実際は、１つのストリーミング制御装置では、ハードウェアの限界のため所定数のデータ配信源しかサポートできない。このため、より多くのデータ配信源をサポートするために、いくつかのストリーミング制御装置がネットワークアーキテクチャにより運用可能となる。したがって、相互接続装置はデータ配信源と受信機の任意のクラスタをサポートできる。
【００２７】
本実施形態のストリーミング制御装置は、手動またはあるソフトウェアによって設定および制御される。このソフトウェアは本実施形態のストリーミング制御装置内または遠隔ホスト上で実行される。本実施形態のストリーミング制御装置がこのソフトウェアからのメッセージを受け取ることにより、当該ソフトウェアはリアルタイムに当該ストリーミング制御装置を制御することができる。
【００２８】
ストリーミング制御装置は自らを通るトラヒックに関する統計情報を記録して、当該情報は外部記憶装置に保存される。したがって、本実施形態のストリーミング制御装置または遠隔ホストで動作するソフトウェアは、特定の種類のメッセージによってリアルタイムにこの情報を検索することができる。
【００２９】
また、本実施形態のストリーミング制御装置内に設けられたエンジンは、設定ツールによって動作時に利用可能または利用不可能にすることが出来る。ストリーミング制御装置は、エンジンのいくつかが利用不可能となっている場合、一般のネットワークの役割を果たす。例えば、ユニキャスト／マルチキャスト変換エンジンが無効の場合、当該装置は高速グループスイッチングによってマルチキャストルータとして動作する。
【００３０】
以下、ＩＰベースのデジタルセキュリティシステムにおいて、オーディオビジュアルコンテンツを配信するストリーミング制御装置を使用した例について説明する。本実施形態のストリーミング制御装置は、ユニキャストからマルチキャストへの変換およびパケット転送を行う装置であり、ＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）プロトコルによる「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐ−Ｒｅｐｏｒｔメッセージ」、「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」および「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」を送出する。なお、以下の説明において、これらの用語は以下の意味として用いられる。
【００３１】
まず、「パケット」は、ネットワーク上で配信されるデータの構成単位である。また、「ストリーム」は、共通の属性を持つネットワークに転送されるパケットの集結である。また、「トラヒック」は、ネットワーク上を転送するストリームの集結である。また、「フロー」は、ストリームを配信するのに用いられるデータパスのことである。また、「ＱｏＳ」は、データストリームやトラヒックの「サービス品質」という用語である。また、「ＱｏＳプローブ」は、ネットワーク構成要素の１つでのフローのＱｏＳを測り、知らせる装置のことである。また、「ＮＥ」は、ネットワークルータやゲートウエイ、インテリジェントネットワークハブとして機能するように用いられるネットワーク構成要素のことである。また、「上位層」は、本実施形態のストリーミング制御装置から送信されたパケットを処理する装置の上部の任意のエンティティ（ｅｎｔｉｔｙ）のことである。
【００３２】
図１は、ユニキャストデータパケットトラヒックをマルチキャストデータパケットトラヒックに変換し、受信機からの要請に基づいて受信機に転送するストリーミング制御装置を示すブロック図である。同図に示す本実施形態のストリーミング制御装置は、４つの主要な構成要素、すなわち、Ｕ２Ｍ変換転送エンジン１０１と、照会および状態更新エンジン１０２と、サブＩＧＭＰ処理エンジン１０３と、転送および受信機登録テーブル１０４とを備えて構成されている。
【００３３】
なお、同図に示したストリーミング制御装置の構造は説明用に簡略化されており、実際の物理的アーキテクチャを反映しているとは限らない。また、実際には、当該装置はより複雑なアーキテクチャと特別のエンジンを有することができる。さらに、図１では主要なデータパスのみを示す。
【００３４】
図１に示すデータパスとは、照会および状態更新エンジン１０２からＵ２Ｍ変換転送エンジン１０１へのデータパスＡ、照会および状態更新エンジン１０２と転送および受信機登録テーブル１０４の間のデータパスＢ、Ｕ２Ｍ変換転送エンジン１０１と転送および受信機登録テーブル１０４の間のデータパスＣ、サブＩＧＭＰ処理エンジン１０３と転送および受信機登録テーブル１０４の間のデータパスＤ、およびＵ２Ｍ変換転送エンジン１０１とサブＩＧＭＰ処理エンジン１０３の間のデータパスＥ、サブＩＧＭＰ処理エンジン１０３から照会および状態更新エンジン１０２へのデータパスＦである。図１に示すように、データパスＡ，Ｆは一方向性であり、他のデータパスＢ，Ｃ，Ｄ，Ｅは双方向性である。データパスの方向はデータパス上での情報の流れの方向を示す。
【００３５】
実際には、より多くのデータパスが存在しており、特別の制御パスやシグナリングパスがある。図１に示すＵ２Ｍ変換転送エンジン１０１やサブＩＧＭＰ処理エンジン１０３は、例えばＦＰＧＡ等のハードウェア法により、あるいはソフトウェアモジュールとして実施される。これらのエンジンがハードウェア内で実施される場合に、データパスはこれらのエンジン間を物理的に接続する役割を果たす。これらのエンジンがソフトウェアモジュールとして実施されるなら、図１に示したデータパスはこれらのモジュール間のインターフェイスを示すことになる。
【００３６】
図１に示すように、データ配信源からのユニキャストトラヒックはユニキャストポートからＵ２Ｍ変換転送エンジン１０１に入力される。Ｕ２Ｍ変換転送エンジン１０１は所定の規則に基づいてトラヒックを処理し、得られたトラヒックを転送および受信機登録テーブル１０４に記憶した情報と所定の規則とに基づいて出力ポートに転送する。
【００３７】
図２は、Ｕ２Ｍ変換転送エンジン１０１の状態遷移図である。同図に示すように、Ｕ２Ｍ変換転送エンジン１０１は６つの状態、初期化を行う初期化状態２０１、各種条件に応じて他の状態に遷移するアイドル状態２０２、パケットのユニキャスト／マルチキャスト変換を行うＵ２Ｍ変換状態２０３、パケットの転送を行う転送状態２０４、ユニキャストパケットを転送するフォワードユニキャスト状態２０５およびパケットを上位層に転送して処理する上位層状態２０６のいずれかをとり得る。
【００３８】
Ｕ２Ｍ変換転送エンジン１０１は初期化状態２０１から始まる。図３は、初期化状態２０１のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。図３に示すように、Ｕ２Ｍ変換転送エンジン１０１はハードウェア構成を読み取る（Ｓ２１０１）。当該ステップＳ２１０１では、ポート、ユニキャストポートアドレスおよびマルチキャストポートアドレスの数の読み取りが可能であるが、より多くの属性を読み取ることができる。次に、Ｕ２Ｍ変換転送エンジン１０１はユーザ構成を読み取る（Ｓ２１０２）。当該ステップＳ２１０２は、ユニキャスト・マルチキャスト方式、Ｕ２Ｍ変換用のユニキャストアドレス、装置のＩＰアドレス、変換用のマルチキャストグループおよび同一カメラを同時に見るようにサポートした受信機数等の読み取りを含むが、これらに限定されない。
【００３９】
次に、Ｕ２Ｍ変換転送エンジン１０１は、上記ステップＳ２１０１，Ｓ２１０２で読み取った構成に対応して「ｆｏｒｗａｒｄ＿ｃｏｎｄｉｔｉｏｎ＿ｔｂｌテーブル」および「ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌテーブル」を作成し初期化する（Ｓ２１０３）。これらのテーブルは図１に示した転送および受信機登録テーブル１０４であり、ＲＯＭやメモリブロックとしてハードウェア内に記録されることが可能である。２つのテーブルの初期値は任意の値をとる。例えば、「ｆｏｒｗａｒｄ＿ｃｏｎｄｉｔｉｏｎ＿ｔｂｌテーブル」の値を−１に設定し、「ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌテーブル」の値を０に設定する。
【００４０】
初期化状態２０１の後はアイドル状態２０２となる。図４は、アイドル状態２０２のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。なお、以下に説明するステップは、Ｕ２Ｍ変換転送エンジン１０１がアイドル状態２０２から別の状態に遷移するときに実行される。また、当該遷移を誘発する事象はパケットの到来であると仮定する。また、その他の点では、アイドル状態２０２に戻るデフォルト遷移が発生する。
【００４１】
図４に示すように、Ｕ２Ｍ変換転送エンジン１０１は、前記事象を引き起こすパケットを得る（Ｓ２２０１）。次に、Ｕ２Ｍ変換転送エンジン１０１は、ステップＳ２２０１で得られたパケットがユニキャストポートからのものかを判断し（Ｓ２２０２）、ユニキャストポートからのものであればステップＳ２２０３に進み、そうでなければステップＳ２２０４に進む。ステップＳ２２０３では、ステップＳ２２０１で得られたパケットの宛先アドレスを得る。次に、この宛先アドレスを配列済みＵ２Ｍアドレスと比較して両アドレスが等しいかを判断し（Ｓ２２０５）、等しい場合はステップＳ２２１０に進み、等しくない場合はステップＳ２２０８に進む。ステップＳ２２１０では、「ｕｎｉｃａｓｔ＿ｐｋｔ＿ｄｅｓｔｉｎｅｄ＿ｕ２ｍ＿ａｄｄｒｅｓｓ条件」（変換するパケットの変換後のユニキャストアドレス）を設定し、Ｕ２Ｍ変換転送エンジン１０１はＵ２Ｍ変換状態２０３に遷移する。
【００４２】
一方、ステップＳ２２０８（宛先アドレスがＵ２Ｍアドレスに等しくない場合）では、ステップＳ２２０２で取得された宛先アドレスが装置自身のＩＰアドレスに等しいかを判断し、等しい場合はステップＳ２２０９に進み、等しくない場合はステップＳ２２１１に進む。ステップＳ２２０９では、「Ｏｔｈｅｒ＿ｐａｃｋｅｔ＿ｄｅｓｔｉｎｅｄ＿ｆｏｒ＿Ｕ２Ｍｂｏｘ条件」を設定し、上位層状態２０６に遷移する。一方、ステップＳ２２１１では、「Ｕｎｉｃａｓｔ＿ｎｏｔ＿ｆｏｒ＿Ｕ２Ｍ条件」を設定し、Ｕ２Ｍ変換転送エンジン１０１はフォワードユニキャスト状態２０５に遷移する。
【００４３】
ステップＳ２２０２による判断の結果、ステップＳ２２０１で得られたパケットがユニキャストポートからのものでない場合はステップＳ２２０４に進む。ステップＳ２２０４では、前記パケットがサブＩＧＭＰ処理エンジン１０３からのものかを判断し（Ｓ２２０４）、サブＩＧＭＰ処理エンジン１０３からのものであればステップＳ２２０６に進み、そうでなければステップＳ２２０７に進む。ステップＳ２２０６では、「Ｐｋｔ＿ｆｒｏｍ＿Ｓｕｂ−ＩＧＭＰ＿ｅｎｇｉｎｅ条件」を設定し、Ｕ２Ｍ変換転送エンジン１０１はフォワードユニキャスト状態２０５に遷移する。一方、ステップＳ２２０７では、「Ｑｕｅｒｙ＿ｐｋｔ＿ｆｒｏｍ＿Ｑｕｅｒｙ＿ｅｎｇｉｎｅ条件」を設定し、Ｕ２Ｍ変換転送エンジン１０１は転送状態２０４に遷移する。
【００４４】
上述したように、「ｕｎｉｃａｓｔ＿ｐｋｔ＿ｄｅｓｔｉｎｅｄ＿ｕ２ｍ＿ａｄｄｒｅｓｓ条件」がアイドル状態２０２からの遷移条件として設定されると、Ｕ２Ｍ変換転送エンジン１０１はＵ２Ｍ変換状態２０３に遷移する。図５は、Ｕ２Ｍ変換状態２０３のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。同図に示すように、Ｕ２Ｍ変換転送エンジン１０１は、まず、遷移を誘発するパケットの配信源アドレスを得る（Ｓ２３０１）。次に、ユニキャスト／マルチキャスト変換（Ｕ２Ｍ変換）を構成方式に基づくパケットに適用する。
【００４５】
変換方式はいくつか考えられ、当該Ｕ２Ｍ変換転送エンジン１０１は、現ワーキング方式として構成されるもののいずれか１つに従うことになる。例えば、Ｕ２Ｍ変換転送エンジン１０１は、全パケットの宛先アドレスフィールドを同じマルチキャストグループアドレスに変更することにより、全トラヒックを１つの構成済みマルチキャストグループに変換できる。また、Ｕ２Ｍ変換転送エンジン１０１は、トラヒックの配信源アドレスに基づくトラヒックを変換できる。１つの方法では、最初の宛先アドレスの低８ビットを貯え、かつ、宛先アドレスの高２４ビットをマルチキャストグループアドレスプレフィックスに設定することにより可能であるが、非常に多くの方式が考えられる。
【００４６】
次に、Ｕ２Ｍ変換転送エンジン１０１は、ステップＳ２３０２における変換後に、新しい宛先アドレスをパケット宛先アドレスフィールドに設定する（Ｓ２３０３）。そして、Ｕ２Ｍ変換転送エンジン１０１は、Ｕ２Ｍ変換状態２０３の処理を終えた後、転送状態２０４に遷移する。但し、この遷移は保護されない。
【００４７】
上述したように、「Ｑｕｅｒｙ＿ｐｋｔ＿ｆｒｏｍ＿Ｑｕｅｒｙ＿ｅｎｇｉｎｅ条件」がアイドル状態２０２からの遷移条件として設定されると、Ｕ２Ｍ変換転送エンジン１０１は転送状態２０４に遷移する。図６は、転送状態２０４のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。同図に示すように、Ｕ２Ｍ変換転送エンジン１０１は、まず、パケットの宛先アドレスから、「ｇｒｐ＿ｉｎｄｅｘ」、「テーブルの指数」を計算する（Ｓ２４０１）。なお、宛先アドレスから「ｇｒｐ＿ｉｎｄｅｘ」への写像方法は構成可能である。簡単な一事例は、指数として宛先アドレスの低８ビットを用いることであるが、非常に多くの写像方式が考えられ、上記説明は唯一の方法ではない。
【００４８】
「ｇｒｍ＿ｉｎｄｅｘ」を得た後に「ｆｏｒｗａｒｄ＿ｃｏｎｄｉｔｉｏｎ＿ｔｂｌ」テーブルを調べて、このグループのパケットに対する要請を持つポートがあるかを検討すると共に、宛先アドレスがａｌｌ＿ＤＲＰアドレス：２２４．０．０．１であるかを調べる（Ｓ２４０２）。このグループのトラヒックに対する要請を持つポートがあるか、宛先アドレスが「２２４．０．０．１」であれば、パケットは複製され、そのポートに転送される。これらのプロセスは、Ｕ２Ｍ変換転送エンジン１０１がハードウェア内で実施される場合に並列に行われる。このグループのトラヒックに対する要請を持つポートがない場合、このパケットは廃棄され、関連する配信源は開放される。転送状態２０４の後、Ｕ２Ｍ変換転送エンジン１０１はアイドル状態２０２に逆遷移する。
【００４９】
上述したように、「Ｐｋｔ＿ｆｒｏｍ＿Ｓｕｂ−ＩＧＭＰ＿ｅｎｇｉｎｅ条件」、「ｕｎｉｃａｓｔ＿ｎｏｔ＿ｆｏｒ＿Ｕ２Ｍ条件」または「ｂｒｏａｄｃａｓｔ＿ｐｋｔ条件」がアイドル状態２０２からの遷移条件として設定されるとすると、Ｕ２Ｍ変換転送エンジン１０１はフォワードユニキャスト状態２０５に遷移する。図７は、フォワードユニキャスト状態２０５のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。同図に示すように、Ｕ２Ｍ変換転送エンジン１０１は、まず、パケットを得て出力ポート指数を転送して計算する（Ｓ２５０１）。この出力ポート指数はボックスに設定した規則に基づいて計算される。なお、当該規則は構成可能であり、後述する。次に、Ｕ２Ｍ変換転送エンジン１０１は、ユニキャストパケットを出力ポートに転送する（Ｓ２５０２）。但し、前記規則がこのパケットを必要とするポートがないことを示すのであれば、このパケットはドロップされ、関連する配信源は開放される。
【００５０】
上述したように、「Ｏｔｈｅｒ＿ｐａｃｋｅｔ＿ｄｅｓｔｉｎｅｄ＿ｆｏｒ＿Ｕ２Ｍｂｏｘ条件」がアイドル状態２０２からの遷移条件として設定されると、Ｕ２Ｍ変換転送エンジン１０１は上位層状態２０６に遷移する。図８は、上位層状態２０６のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャートである。同図に示すように、Ｕ２Ｍ変換転送エンジン１０１は、パケットを上位層状態２０６に送信して処理する（Ｓ２６０１）。なお、上位層状態２０６はパケットのコンテンツを読み取り、それに従って動作する任意のハードウェアやソフトウェアモジュールである。
【００５１】
図９は、図１に示した照会および状態更新エンジン１０２の状態遷移図である。当該照会および状態更新エンジン１０２は、「ＩＧＭＰｇｅｎｅｒａｌ＿ｑｕｅｒｙメッセージ」を周期的に発生する機能および転送および受信機登録テーブル１０４を維持する機能を有する。
【００５２】
照会および状態更新エンジン１０２は初期化状態３０１から始まる。図１０は、初期化状態３０１の照会および状態更新エンジン１０２が行う動作について説明するフローチャートである。図１０に示すように、照会および状態更新エンジン１０２は、本実施形態のストリーミング制御装置に「Ｅｎａｂｌｅ＿Ｑｕｅｒｙ」を設定する（Ｓ３１０１）。同一ネットワーク内に複数の装置がある場合、唯一の装置は照会器（ｑｕｅｒｉｅｒ）であり、「ＩＧＭＰｇｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」を送信する。どの装置を照会器にするかについての決定は、後述するが、手動または所定の特定プロトコルによって行われる。
【００５３】
次に、照会および状態更新エンジン１０２は、照会（Ｑｕｅｒｙ）が有効かを判断し（Ｓ３１０２）、有効である（装置が照会器として構成されている）場合はステップＳ３１０３に進み、有効でない（照会器として構成されていない）場合は一連の処理を終了する。ステップＳ３１０３では、照会および状態更新エンジン１０２は、本実施形態のストリーミング制御装置から照会間隔の構成を得る（Ｓ３１０３）。なお、所定のデフォルト値は装置内に送信され、任意に手動または特定のプトロコルを通じて修正される。基本的に、間隔が短くなればなるほど、バースト性になり、より多くのＩＧＭＰメッセージは同一周期内にサブＩＧＭＰ処理エンジン１０３により処理される必要がある。一方、間隔が長くなればなるほど、「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」がリンク上で失われた場合に、本実施形態のストリーミング制御装置がマルチキャストトラヒックの転送を停止する前に長い時間を要する。
【００５４】
次に、照会および状態更新エンジン１０２は、「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」を形成する（Ｓ３１０４）。当該メッセージは上記照会間隔に合わせた最大応答時間を持つＲＦＣ２２３６に基づいて形成される必要がある。「ＩＧＭＰＧｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」は常に同じ状態のままであるので、この形成された「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」は後で再利用される。次に、照会および状態更新エンジン１０２は、照会タイマーを始動する（Ｓ３１０５）。照会タイマーの長さは上述のように照会間隔に設定される。そして、照会および状態更新エンジン１０２は、アイドル状態３０２に遷移する。但し、この遷移は保護されない。この遷移に伴う行動は、照会タイマー（Ｑｕｅｒｙ＿Ｔｉｍｅｒ）を設定することである。
【００５５】
照会および状態更新エンジン１０２は、本実施形態のストリーミング制御装置が照会器として構成されているときに「Ｑｕｅｒｙ＿ｔｉｍｅｒ＿ｅｘｐｉｒｅ条件」が設定されると、アイドル状態３０２から更新状況テーブル状態３０３に遷移する。但し、この場合以外は、サブＩＧＭＰ処理エンジン１０３が信号を送信する。図１１は、更新状況ステーブル状態３０３の照会および状態更新エンジン１０２が行う動作について説明するフローチャートを示す。図１１に示すように、ステップＳ３３０１では、各グループに対するマルチキャストポートのカウンタ値の各々が０（ゼロ）でなければＦｏｗａｒｄ＿ｓｔａｔｕｓ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］の値を減じ、０に達するとｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］をリセットする。当該ステップは全ポートと全グループに対して行われ、ハードウェアと並列に実行されるように実施される。
【００５６】
照会および状態更新エンジン１０２は、本実施形態のストリーミング制御装置が照会器として構成されているときに更新状況テーブル状態３０３から照会状態３０４に遷移する。但し、この場合以外は、アイドル状態３０２に遷移する。図１２は、照会状態３０４の照会および状態更新エンジン１０２の動作について説明するフローチャートを示す。図１２に示すように、ステップＳ３２０１では、データパス１を通じて「ＦｏｒｍｅｄＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」をＵ２Ｍ変換転送エンジン１０１に送信する。そして、照会および状態更新エンジン１０２は照会状態３０４からアイドル状態３０２に遷移する。この遷移時には、照会タイマー（Ｑｕｅｒｙ＿Ｔｉｍｅｒ）に予め与えられた値を設定する。
【００５７】
図１３は、図１に示したサブＩＧＭＰ処理エンジン１０３の状態遷移図である。当該サブＩＧＭＰ処理エンジン１０３は、マルチキャストポートで受信したＩＧＭＰメッセージを処理し、それに応じて転送および受信機登録テーブル１０４の更新を行う。サブＩＧＭＰ処理エンジン１０３は、ユニキャストポートで受信したユニキャストパケットを転送する。または、Ｕ２Ｍ変換転送エンジン１０１は、本実施形態のストリーミング制御装置に予め設定された規則に従った動作を行う。
【００５８】
サブＩＧＭＰ処理エンジン１０３は初期化エンジン４０１状態から始まる。図１４は、初期化エンジン４０１状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。図１４に示すように、サブＩＧＭＰ処理エンジン１０３は、本実施形態のストリーミング制御装置にハードウェア設定を行う（Ｓ４１０１）。当該設定は、ユニキャストポートのアドレス、マルチキャストポートのアドレスおよびマルチキャストポート数等を含む。
【００５９】
次に、サブＩＧＭＰ処理エンジン１０３は、本実施形態のストリーミング制御装置からソフトウェア設定を得る（Ｓ４１０２）。可能な設定項目は、装置のＩＰアドレス、ネットワークロバスト設定、当該装置が照会器であるかどうか、およびコントローラポートのアドレス等である。次に、サブＩＧＭＰ処理エンジン１０３は、上記ステップで得た設定により必要とされる場合に、ユニキャスト転送テーブルを初期化する（Ｓ４１０３）。
【００６０】
次に、サブＩＧＭＰ処理エンジン１０３は、初期化エンジン４０１からアイドル４０２状態に遷移する。本実施形態では、アイドル４０２状態からの遷移はパケットの到来により行われ、他の事象はアイドル４０２状態自身への遷移を行う「ｄｅｆａｕｌｔ」のカテゴリーに入るものと仮定する。なお、事象には多くの種類があり、当該仮定は説明の便宜性のためにのみ行われる。
【００６１】
図１５は、アイドル４０２状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。なお、以下に説明するプロセスは、サブＩＧＭＰ処理エンジン１０３がアイドル４０２状態から他の状態に遷移するときに実行される。図１５に示すように、サブＩＧＭＰ処理エンジン１０３は、イベントを誘発するパケットを得る（Ｓ４２０１）。次に、サブＩＧＭＰ処理エンジン１０３は、ステップＳ４２０１で取得されたパケットがＩＰパケットであるかを判断し（Ｓ４２０２）、ＩＰパケットである場合はステップＳ４２０３に進み、ＩＰパケットでない場合はステップＳ４２０７に進む。
【００６２】
ステップＳ４２０７（ＩＰパケットでない場合）では、「Ｏｔｈｅｒ＿ｐａｃｋｅｔ条件」を設定し、サブＩＧＭＰ処理エンジン１０３はドロップパケット４０６状態に遷移する。一方、ステップＳ４２０３（ＩＰパケットである場合）では、ステップＳ４２０１で取得されたパケットがＩＧＭＰパケットであるかをパケットのヘッダ情報を調べることにより判断し（Ｓ４２０３）、ＩＧＭＰパケットでない場合はステップＳ４２０４に進み、ＩＧＭＰである場合はステップＳ４２０５に進む。なお、ヘッダ情報において、ＩＧＭＰパケットはクラスＤのＩＰアドレスでタイプ２である。
【００６３】
ステップＳ４２０４（ＩＧＭＰパケットでない場合）では、当該パケットがユニキャストパケットであるかを判断し（Ｓ４２０４）、ユニキャストパケットであればステップＳ４２０６に進み、ユニキャストパケットでなければ上記説明したステップＳ４２０７に進んでドロップパケット４０６状態に遷移する。ステップＳ４２０６（ユニキャストパケットである場合）では、「ｕｎｉｃａｓｔ＿ｐｋｔ＿ｒｅｃｅｉｖｅｄ条件」を設定し（Ｓ４２０６）、サブＩＧＭＰ処理エンジン１０３はユニキャストフォワード４０５状態に遷移する。
【００６４】
ステップＳ４２０３でＩＧＭＰパケットであると判断された場合はステップＳ４２０５に進むが、当該ステップＳ４２０５では、当該パケットのＩＧＭＰタイプおよびグループフィールドを得る。次に、ステップＳ４２０８では、本実施形態のストリーミング制御装置における設定を基準としてグループアドレスを調べ、タイプフィールドが「ｍｅｍｂｅｒｓｈｉｐ＿ｒｅｐｏｒｔ」または「Ｌｅａｖｅ＿Ｇｒｏｕｐ」に等しいか、すなわち、ＩＧＭＰグループがマルチキャストグループプレフィックスと一致し、「ｍｅｍｂｅｒｓｈｉｐ＿ｒｅｐｏｒｔメッセージ」または「Ｌｅａｖｅ＿Ｇｒｏｕｐメッセージ」であるかを判断する（Ｓ４２０８）。当該ステップＳ４２０８において、等しければステップＳ４２０９に進み、等しくなければステップＳ４２１０に進む。
【００６５】
ステップ４２０９（等しい場合）では、「Ｒｅｃｅｉｖｅｄ＿ＩＧＭＰ＿ｍｅｍｂｅｒｓｈｉｐ＿ｒｅｐｏｒｔ＿ｐｋｔ条件」または「Ｒｅｃｅｉｖｅ＿ＩＧＭＰ＿Ｌｅａｖｅ＿ｇｒｏｕｐ＿ｐｋｔ条件」をタイプフィールドに基づいて設定し、サブＩＧＭＰ処理エンジン１０３は結合報告４０３状態またはリーブ報告４０４状態に遷移する。一方、ステップＳ４２１０（等しくない場合）では、メッセージが「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」であるか、本実施形態のストリーミング制御装置が非照会器であるかを判断する。当該ステップＳ４２１０において、上記２つの条件を満たせばステップＳ４２１１に進み、満たさなければステップＳ４２０７に進んで、サブＩＧＭＰ処理エンジン１０３はドロップパケット４０６状態に遷移する。ステップＳ４２１１では、「ｎｏｎ−Ｑｕｅｒｉｅｒ＆＆ＩＧＭＰ＿ｇｅｎｅｒａｌ＿ｑｕｅｒｙ条件」を設定し、サブＩＧＭＰ処理エンジン１０３はトリガ照会エンジン４０７状態に遷移する。
【００６６】
次に、サブＩＧＭＰ処理エンジン１０３は、「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」を受信するとアイドル４０２状態から結合報告４０３状態に遷移する。図１６は、結合報告４０３状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。図１６に示すように、サブＩＧＭＰ処理エンジン１０３は、パケットを受信するポート番号「ｐｏｒｔ＿Ｎｏ」を得る（Ｓ４３０１）。次に、パケット内のグループアドレスは、Ｕ２Ｍ変換転送エンジン１０１の転送状態で使用される同じハッシュ関数により、グループ指数「ｇｒｐ＿ｉｎｄｅｘ」に写像される（Ｓ４２０２）。次に、サブＩＧＭＰ処理エンジン１０３は、「Ｆｏｒｗａｒｄ＿ｓｔａｔｕｓ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］テーブル」の対応セルをマルチキャストトラヒックの転送（フォワード）を可能にする値に設定する（Ｓ４３０３）。
【００６７】
次に、サブＩＧＭＰ処理エンジン１０３は、ＩＧＭＰメッセージの配信源アドレスを得て、受信機登録テーブル「ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌ」の対応セルの対応ビットをセットする（Ｓ４３０４）。次に、当該セルのビットを「Ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］テーブル」に設定する（Ｓ４３０５）。なお、この操作はビットマップである必要はなく、任意形態で記録することも可能であり、受信機登録テーブルも多次元であり得る。以上のステップが行われるとメッセージパケットは破壊され、関連する配信源が開放される（Ｓ４３０６）。そして、サブＩＧＭＰ処理エンジン１０３は結合報告４０３状態からアイドル４０２状態に逆遷移する。
【００６８】
同じく、サブＩＧＭＰ処理エンジン１０３は、「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」を受信すると、アイドル４０２状態からリーブ報告４０４状態に遷移する。図１７は、リーブ報告４０４状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。ステップＳ４４０１，Ｓ４４０２，Ｓ４４０３は、図１６に示した結合報告４０３状態のサブＩＧＭＰ処理エンジン１０３が行うステップＳ４３０１，Ｓ４３０２，Ｓ４３０４と同様であり、ハッシング関数と写像法は両者にとって同じである。当該３つのステップの後に、サブＩＧＭＰ処理エンジン１０３は受信機登録テーブル「Ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］テーブル」の対応ビットを得る（Ｓ４４０４）。次に、対応ビットを設定するかを判断する（Ｓ４４０５）。これは、ソースがこのグループの「Ｍｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」を前に送信したかを調べる。配信源が当該グループを要請してない場合、サブＩＧＭＰ処理エンジン１０３は「ＩＧＭＰＬｅａｖｅ＿Ｇｒｏｕｐメッセージ」を処理しない。
【００６９】
ステップＳ４４０５において対応ビットを設定した場合、すなわち、配信源が「Ｍｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」を送信した場合、ステップＳ４４０６に進んで、対応ビットの設定を解除して未設定とする（Ｓ４４０６）。次に、サブＩＧＭＰ処理エンジン１０３は、それがこのポート上のグループを離れる最後の受信機であるかどうかを判断し（Ｓ４４０７）、最後の受信機であればステップＳ４４０８に進む。当該ステップＳ４４０８では、転送状況テーブル内の対応セルＦｏｒｗａｒｄ＿ｓｔａｔｕｓ＿ｔｂｌ［ｐｏｒｔ＿ｎｏ］［ｇｒｐ＿ｉｎｄｅｘ］にＵ２Ｍ変換転送エンジン１０１のグループのトラヒックに転送できる値を設定する。以上のステップが行われるとメッセージパケットは破壊され、関連する配信源が開放される（Ｓ４４０９）。そして、サブＩＧＭＰ処理エンジン１０３はリーブ報告４０４状態からアイドル４０２状態に逆遷移する。但し、この遷移は保護されない。
【００７０】
また、サブＩＧＭＰ処理エンジン１０３は、ユニキャストパケットを受信し、これを転送する場合に、アイドル４０２状態からユニキャストフォワード４０５状態に遷移する。図１８は、ユニキャストフォワード４０５状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。図１８に示すように、サブＩＧＭＰ処理エンジン１０３は、ユニキャストパケットを得る（Ｓ４５０１）。次に、転送規則と装置状況を調べて、当該パケットを転送すべきマルチキャストポートを決定する（Ｓ４５０２）。次に、当該パケットをユニキャストポートとステップＳ４５０２で決定したマルチキャストポートに転送する（Ｓ４５０３）。そして、サブＩＧＭＰ処理エンジン１０３は、ユニキャストフォワード４０５状態からアイドル４０２状態に遷移する。
【００７１】
また、サブＩＧＭＰ処理エンジン１０３は、アイドル４０２状態において「Ｏｔｈｅｒ＿ｐａｃｋｅｔ条件」が設定されると、アイドル４０２状態からドロップパケット４０６状態に遷移する。図１９は、ドロップパケット４０６状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。図１９に示すように、サブＩＧＭＰ処理エンジン１０３はパケットをドロップし、関連する配信源を開放する（Ｓ４６０１）。そして、サブＩＧＭＰ処理エンジン１０３はドロップパケット４０６状態からアイドル４０２状態に遷移する。
【００７２】
また、サブＩＧＭＰ処理エンジン１０３は、アイドル４０２状態において「ｎｏｎ＿Ｑｕｅｒｉｅｒ＆＆ＩＧＭＰ＿ｇｅｎｅｒａｌ＿ｑｕｅｒｙ条件」が設定されると、アイドル４０２状態からトリガ照会エンジン４０７状態に遷移する。図２０は、トリガ照会エンジン４０７状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャートである。図２０に示すように、サブＩＧＭＰ処理エンジン１０３は照会および状況更新エンジン１０２に信号を送信し、「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」の到来を示す（Ｓ４７０１）。なお、種々のポートにより受信される同一の「Ｇｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」の複製が複数あり得るので、ＩＰパケットの組合せ番号を用い、これが新しい照会メッセージかどうかを決定する。新しい照会メッセージのみが信号を誘発する。そして、サブＩＧＭＰ処理エンジン１０３は、トリガ照会エンジン４０７状態からアイドル４０２状態に遷移する。
【００７３】
転送および受信機登録テーブル１０４である「Ｆｏｒｗａｒｄ＿ｓｔａｔｕｓ＿ｔｂｌテーブル」および「Ｒｅｃｅｉｖｅｒ＿ｒｅｇｉｓｔｅｒ＿ｔｂｌテーブル」は、ハードウェアとソフトウェアによって実現される。ソフトウェアで実現される場合、前記テーブルは装置の設定により作成され、動的に修正される。図１に示すように、これらのテーブルは３つのエンジン全てからアクセス（Ｂ、Ｃ、Ｄ）可能であり、照会および状況更新エンジン１０２とサブＩＧＭＰ処理エンジン１０３のみがテーブルのコンテンツへと変化する。したがって、テーブルの同時アクセスを調整する制御が必要であり、当該制御は、ハードウェアで実行される場合はロック信号を利用し、ソフトウェアで実行される場合は例えば「ｍｕｔｅｘ」により行われる。
【００７４】
上述のように、本実施形態のストリーミング制御装置のアーキテクチャはユニキャストポートやマルチキャストポートの数に制限を設けるものでない。このため、本実施形態のストリーミング制御装置は同一エンジンを用いて複数のマルチキャストポートおよびユニキャストポートを伴って容易に実行される。ポート数はむしろ、上記アルゴリズムの代りにハードウェアの限界により決定される。このアーキテクチャはユニキャストポートをマルチキャストポートにでき、この逆も、Ｕ２Ｍ変換転送エンジン１０１とサブＩＧＭＰ処理エンジン１０３を単に組合せるだけで可能になる。
【００７５】
本実施形態のストリーミング制御装置が有するエンジンの機能性が有効や無効になることがある。このエンジンが有効である場合、当該装置は上記のように正常に動作する。一方、エンジンが無効になると、当該装置はトラヒックに対して存在しないこととなり、ブリッジやスイッチのように働く。なお、これらの有効および無効な動作とすることは容易である。例えば、装置のエンジンがハードウェアで実行される場合にはロック信号を使い、装置のエンジンがソフトウェアで実行される場合にはフラグを用いる方法も可能である。これらの動作は遠隔操作で実行できる。
【００７６】
図２１は、本実施形態のストリーミング制御装置を用いて監視システムにサービスを提供する事例のシナリオを示す説明図である。図２１に示すように、特許請求の範囲のスイッチに該当するレイヤー２スイッチにより本装置に接続するカメラ（データ源）の複数のクラスタがある。本装置は同じネットワーク内に存在する。このネットワーク構造は、ネットワークの任意数のカメラへの拡張を促す。ハードウェアの限界、例えばリンク容量のために、一台の装置は所定量までしかカメラ（データ源）を接続することができない。当該構造によれば、この課題を本実施形態のストリーミング制御装置を複数設けることで解決できる。本装置に接続された監視装置はカメラクラスタ内の任意カメラからトラヒックを監視することができる。この監視装置は、カメラの高速スイッチングを行うこともできる。なお、スイッチングの速度はサブＩＧＭＰ処理エンジン１０３の処理速度のみによって決定される。
【００７７】
図２１に示すように、１つ以上の本実施形態のストリーミング制御装置がネットワーク内にあると、レイヤー２スイッチと本装置がループを形成する。取扱いに注意しないと、パケットルーピングの電位問題を引き起すことになる。この問題を解決するために、いくつかの技術が必要とされるが解決策を与える。
【００７８】
上述したように、同じネットワーク内に本実施形態のストリーミング制御装置が複数ある場合、それらの内の１つを照会器とし、それが周期的に「ＩＧＭＰＧｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」を送出する。この照会器の選択は手動または所定プロトコルにより行われる。ネットワークアーキテクチャは対称性なので、複数の装置のうちの任意の１台はネットワークの性能に影響を及ぼさないで照会器として配置される。この選択も配置メッセージにより行われる。例えば、任意の装置は自らを初めに照会器であると認識し、「ＩＧＭＰ＿Ｑｕｅｒｙメッセージ」を送信し始める。１台の装置が他の装置から「Ｇｅｎｅｒａｌ＿Ｑｕｅｒｙメッセージ」を受信すると、当該装置は送信機のアドレスを調べる。送信機のアドレスがそれ自身のアドレスより小さい場合に非照会器となり、非照会器ルーチンを行う。また、ある既存の良く明示された配置メッセージが同じ目的に使用される。
【００７９】
本実施形態のストリーミング制御装置の動作を行う際、複数のマルチキャストポートが存在する場合は、ポートの１つが別々にパケットを転送する「ｃｏｎｔｒｏｌ＿ｐｏｒｔ」として構成される。「ｃｏｎｔｒｏｌ＿ｐｏｒｔ」の選択は配置時に手動または特定のプロトコルにより行われる。手動の場合、オペレータはモニタに接続されたどのレイヤー２スイッチも選ぶことができ、このスイッチに接続されたマルチキャストポートを装置の「ｃｏｎｔｒｏｌ＿ｐｏｒｔ」であるように配置できる。これは簡単なルーチンで、以下に説明するように容易に達成できる。照会器を識別した後、所定の配列に基づいて「ｃｏｎｔｒｏｌ＿ｐｏｒｔ」としてどんなマルチキャストポートでも選ぶことができる。照会器は制御ポートから送出された「ｃｏｎｔｒｏｌ＿ｐｏｒｔ＿ｍｓｇ」を送信する。非照会器の場合には、非照会器がこのメッセージを受信したポートを「ｃｏｎｔｒｏｌ＿ｐｏｒｔ」として配置する。
【００８０】
ネットワーク内のパケットルーピングを防ぐために用いる規則の例を以下に示す。
Ｕ２Ｍ変換転送エンジン１０１に対しては、（１）パケットがユニキャストポートからであれば、本実施形態のストリーミング制御装置が照会器の場合はマルチキャストポートへの転送、非照会器の場合は「ｃｏｎｔｏｒｏｌ＿ｐｏｒｔ」への転送を行い、（２）パケットがサブＩＧＭＰ処理エンジン１０３からであれば、照会器の場合は受信ポート以外の全ポートへの転送、非照会器の場合はパケットをドロップする。一方、サブＩＧＭＰ処理エンジン１０３に対しては、全マルチキャストパケット（非ＩＧＭＰメッセージ）をドロップする、ユニキャストポートにパケットを転送する、パケットをＵ２Ｍ変換転送エンジン１０１に転送する。
【００８１】
＜規則１＞複数の装置が同一ネットワーク内に存在する場合にパケットを転送する規則
これらの規則は、配置時に設定されるか、あるいは実行時にプロトコルにより遠隔設定されるものである。可能なプロトコルの事例は、ＴＣＰプロトコル上で受信する装置で１つのプロトコルを運用させることであり、以下に明示するように、それに送信された制御メッセージを受け入れる。
ｓｔｒｕｃｔＲｕｌｅ＿ｍｓｇ｛
ｉｎｔｅｎａｂｌｅ＿ｕ２ｍ；
ｉｎｔｅｎａｂｌｅ＿ｉｇｍｐ；
ｉｎｔｑｕｅｒｉｅｒ＿ｆｌａｇ；
ｉｎｔｃｏｎｔｒｏｌ＿ｐｏｒｔ＿ｉｎｄｅｘ；
ｉｎｔｕ２ｍ＿ｕｎｉｃａｓｔ＿ｑｕｅｒｉｅｒ＿ｐｔ；
ｉｎｔｕ２ｍ＿ｕｎｉｃａｓｔ＿ｎｏｎ−ｑｕｅｒｉｅｒ＿ｐｔ；
ｉｎｔｕ２ｍ＿ｉｇｍｐ＿ｑｕｅｒｉｅｒ＿ｐｔ；
ｉｎｔｕ２ｍ＿ｉｇｍｐ＿ｎｏｎ−ｑｕｅｒｉｅｒ＿ｐｔ；
ｉｎｔｉｇｍｐ＿ｍｕｌｔｉｃａｓｔ＿ｐｔ；
ｉｎｔｉｇｍｐ＿ｕｎｉｃａｓｔ＿ｐｔ：
ｉｎｔｉｇｍｐ＿ｏｔｈｅｒ＿ｐｔ；
｝；
【００８２】
＜データ構造１＞パケットを転送するための規則を伝えるメッセージ
データ構造内のフィールドを下記のように定義する。
・「ｅｎａｂｌｅ＿ｕ２ｍ」 − このフィールドは、装置のＵ２Ｍ変換および転送エンジン１０１が有効であるかを示す。事例値：１，イネーブル； −１，ディスエーブル
・「ｅｎａｂｌｅ＿ｉｇｍｐ」 − このフィールドは、装置のサブＩＧＭＰ処理エンジン１０３が有効であるかを示す。事例値：１，イネーブル； −１，ディスエーブル
・「ｑｕｅｒｉｅｒ＿ｆｌａｇ」 − このフィールドは、この装置が照会器として設定されるかどうかを示す。事例値：１，照会器に設定； −１，非照会器に設定
・「ｃｏｎｔｒｏｌ＿ｐｏｒｔ＿ｉｎｄｅｘ」 − このフィールドは、制御ポートとしてどのポートを設定すべきかを示す。
・「ｕ２ｍ＿ｕｎｉｃａｓｔ＿ｑｕｅｒｉｅｒ＿ｐｔ」 − このフィールドは、装置が照会器である場合にパケットがＵ２Ｍ変換転送エンジン１０１のユニキャストから到来したならばパケットを転送すべきポートに関するビットマップを伝える。
・「ｕ２ｍ＿ｕｎｉｃａｓｔ＿ｎｏｎ−ｑｕｅｒｉｅｒ＿ｐｔ」 − このフィールドは、装置が非照会器である場合にパケッドがＵ２Ｍ変換転送エンジン１０１のユニキャストポートから到来したならばパケットを転送すべきポートに関するビットマップを伝える。
・「ｕ２ｍ＿ｉｇｍｐ＿ｑｕｅｒｉｅｒ＿ｐｔ」 − このフィールドは、装置が照会器である場合にＵ２Ｍ変換転送エンジン１０１のサブＩＧＭＰ処理エンジン１０３からパケットが到来したならばパケットを転送すべきポートに関するビットマップを伝える。
・「ｕ２ｍ＿ｉｇｍｐ＿ｎｏｎ＿ｑｕｅｒｉｅｒ＿ｐｔ」 − このフィールドは、装置が非照会器である場合にＵ２Ｍ変換転送エンジン１０１のサブＩＧＭＰ処理エンジン１０３からパケットが到来したならばパケットを転送すべきポートに関するビットマップを伝える。
・「ｉｇｍｐ＿ｍｕｌｔｉｃａｓｔ＿ｐｔ」 − このフィールドは、マルチキャストパケットがサブＩＧＭＰ処理エンジン１０３上に到来したならばパケットを転送すべきポートに関するビットマップを伝える。なお、全て零とはパケットをドロップすべきことである。
・「ｉｇｍｐ＿ｕｎｉｃａｓｔ＿ｐｔ」 − このフィールドは、サブＩＧＭＰ処理エンジン１０３上で受信したユニキャストパケットを転送するかどうかの情報を伝える。事例値：１は転送を意味し、−１はパケットをドロップすることである。
・「ｉｇｍ＿ｏｔｈｅｒ＿ｐｋｔ」 − このフィールドは、他のパケット（ユニキャスト、ＩＧＭＰメッセージパケッド以外の）を転送するかどうかの情報を伝える。
【００８３】
上記の規則メッセージデータタイプは説明用の事例である。実際にはメッセージは種々の形態があり、多少のフィールドを持つことができ、信号化や承認化用の特別なメッセージタイプがある。
【００８４】
本実施形態のストリーミング制御装置は通過するトラヒックに関する実時間統計値を記録（ｌｏｇ）でき、それを局所あるいは遠隔に利用できるようにする。これは、ＴＣＰポート上で動作する装置に、要請がある場合に以下のようなログ情報報告メッセージを送信するプロセスを運用することにより行われる。
【００８５】
ｓｔｒｕｃｔｌｏｇ＿ｒｅｐｏｒｔ｛
ｉｎｔｔｉｍｅ；
ｉｎｔｄｅｖｉｃｅ＿ｉｄｅｎｔｉｔｙ；
ｉｎｔｐｏｒｔ＿ｎｕｍ；
ｉｎｔｇｒｐ＿ｎｕｍ；
ｓｔｒｕｃｔｇｒｐ＿ｌｏｇｇｒｐ＿ｒｅｐｏｒｔ［ｐｏｒｔ＿ｎｕｍ］［ｇｒｐ＿ｎｕｍ］；
｝；
ｓｔｒｕｃｔｇｒｐ＿ｌｏｇ｛
ｉｎｔｐｏｒｔ＿ｉｎｄｅｘ；
ｉｎｔｇｒｐ＿ｉｎｄｅｘ；
ｉｎｔｐｋｔ＿ｆｏｒｗａｒｄｅｄ；
ｉｎｔｇｉｇａ＿ｐｋｔ＿ｆｏｒｗａｒｄｅｄ；
ｉｎｔｐｋｔ＿ｄｒｏｐｐｅｄ；
ｉｎｔｇｉｇａ＿ｐｋｔ＿ｄｒｏｐｐｅｄ；
ｉｎｔｂｉｔｓ＿ｆｏｒｗａｒｄｅｄ；
ｉｎｔｇｉｇａ＿ｂｉｔｓ＿ｆｏｒｗａｒｄｅｄ；
ｉｎｔｂｉｔｓ＿ｄｒｏｐｐｅｄ；
ｉｎｔｇｉｇａ＿ｂｉｔｓ＿ｄｒｏｐｐｅｄ；
ｉｎｔａｖｇ＿ｂａｎｄｗｉｄｔｈ；
ｉｎｔｒｅｃｅｉｖｅｒ＿ｒｕｍ；
ｓｔｒｕｃｔｒｅｃｅｉｖｅｒ＿ｌｏｇｒｅｃｅｉｖｅｒ＿ｒｅｐｏｒｔ［ｒｅｃｅｉｖｅｒ＿ｒｕｍ］；
｝；
ｓｔｒｕｃｔｒｅｃｅｉｖｅｒ＿ｌｏｇ｛
ｉｎｔｒｅｃｅｉｖｅｒ＿ｉｄｅｎｔｉｙ；
ｉｎｔｊｏｉｎ＿ｔｉｍｅ；
ｉｎｔｌｅａｖｅ＿ｔｉｍｅ；
ｉｎｔａｖｇ＿ｂａｎｄｗｉｄｔｈ；
｝；
【００８６】
＜データ構造２＞ログレポートメッセージ用のデータ構造
データ構造のフィールドを下記の様に定義する。
・「ｔｉｍｅ」 − このフィールドは、このレポートを何時作成するかの時期について情報を伝える。その値の意味は実処理系依存である。
・「ｄｅｖｉｃｅ＿ｉｄｅｎｔｉｔｙ」 − このフィールドは、このレポートを注目する装置の実体についての情報を伝える。その値の意味は処理系依存である。
・「ｐｏｒｔ＿ｎｕｍ」 − このフィールドは、このレポートに含まれるポート数を示す。
・「ｇｒｐ＿ｎｕｍ」 − このフィールドは、このレポートに含まれるグループの数を示す。
・「ｇｒｐ＿ｒｅｐｏｒｔ」 − これは所定ポート上のあるグループに関する情報を含む可変サイズアレーである。それはｔｙｐｅｓｔｒｕｃｔｇｒｐ＿ｌｏｇである。
・「ｐｏｒｔ＿ｉｎｄｅｘ」 − これは、このグループログレポートに関するポート指標を示す。
・「ｇｒｐ＿ｉｎｄｅｘ」 − これは、このグループログレポートに関するグループ指標を示す。
・「ｐｋｔ＿ｆｏｒｗａｒｄ」，「ｇｉｇａ＿ｐｋｔ＿ｆｏｒｗａｒｄ」 − これらの２つのフィールドは、このポート上のこのグループのトラヒックに対して転送されたパケット数を示す。
・「ｐｋｔ＿ｄｒｏｐｐｅｄ」，「ｇｉｇａ＿ｐｋｔ＿ｄｒｏｐｐｅｄ」 − これらの二つのフィールドは、このポート上のこのグループのトラヒックに対してドロップされたパケット数を示す。
・「ｂｉｔｓ＿ｆｏｒｗａｒｄ」，「ｇｉｇａ＿ｂｉｔｓ＿ｆｏｒｗａｒｄ」 − これらの二つのフィールドは、このポート上のこのグループのトラヒックに対して転送状態になるビット数を示す。
・「ｂｉｔｓ＿ｄｒｏｐｐｅｄ」，「ｇｉｇａ＿ｂｉｔｓ＿ｄｒｏｐｐｅｄ」 − これらの二つのフィールドは、このポート上のこのグループのトラヒックに対してドロップ状態になるビット数を示す。
・「ａｖｇ＿ｂａｎｄｗｉｄｔｈ」 − このフィールドは、このポート上のこのグループのトラヒックの平均帯域幅である。
・「ｒｅｃｅｉｖｅｒ＿ｎｕｍ」 − このフィールドは、レポートに含まれる受信機記録の数を示す。
・「ｒｅｃｅｉｖｅｒ＿ｒｅｐｏｒｔ」 − これは、受信機記録情報のｒｅｃｅｉｖｅｒ＿ｎｕｍ数を含む可変サイズアレーである。それはデータタイプｓｔｒｕｃｔｒｅｃｅｉｖｅｒ＿ｌｏｇである。
・「ｒｅｃｅｉｖｅｒ＿ｉｄｅｎｔｉｔｙ」 − これは、この受信機記録情報に関する受信機の実体を示す。
・「ｊｏｉｎ＿ｔｉｍｅ」 − このフィールドは、受信機の接合グループ時間を示す。・「ｌｅａｖｅ＿ｔｉｍｅ」 − このフィールドは、受信機がグループを離れる時間を示す。
・「ａｖｇ＿ｂａｎｄｗｉｄｔｈ」 − このフィールドは、受信機の平均帯域幅を示す。
【００８７】
これらのメッセージタイプは説明用のみの事例であり、装置に用いる唯一のものとして考えるものではない。記録情報が他の処理形態においても実行される。上記の情報は３つのエンジン全てに集められ、後の検索用のデータベースとして装置、すなわち外部記憶装置に記憶される。
【００８８】
以上説明したように、本実施形態のストリーミング制御装置によれば、当該装置を通るトラヒックにサービス品質を提供できる。例えば、所定の受信機では、スループットパラメータを設定できるので、パケットを装置のポートに転送する場合にトラヒックを形成できる。また、本装置をネットワークに配置しても他のネットワークノードに特別な変更を必要としないため、配置の影響やコストを最小にできる。それゆえ、本装置を既存システムに容易に適用できる。
【００８９】
また、本装置は遠隔構成およびレポーティングが可能である、つまり、遠隔／集中制御器を用いて分散装置を管理できる。また、フレームワークを形成するようにいくつかの装置を相互接続することにより大規模ネットワークを支援することができる。また、本装置は、遠隔アクセスの局所用のトラヒックに関する実時間統計値情報を提供するため、遠隔／集中モニタの実現を促進する。さらに、ＱｏＳ情報を記録するフレームワークと特別のＱｏＳフレームワークを組み込む方法を提供する。
【００９０】
なお、ある特別ポートを前述のカメラや監視装置上に割当て、これらのデバイスが複数ある場合に所定デバイスに所定属性を割当て、所定の構成規則に基づいて出力ポートにトラヒック、特に所定パケットを転送することによって、ネットワーク内のルーピングを阻止しても良い。また、このリンクまたはネットワークサービスポートのデバイスとデバイス属性を自己構成することができる。
【００９１】
【発明の効果】
以上説明したように、本発明に係るストリーミング制御装置によれば、マルチキャストトラヒック転送情報データベースに記録されている受信機の情報によって、同じトラヒックを要請する受信機が他に存在するかを直ちに知ることができるため、受信機が存在しない場合にはトラヒックの配信をすぐに停止できる。この結果、トラヒックを効率化して小さくすることのできる。
【図面の簡単な説明】
【図１】ユニキャストデータパケットトラヒックをマルチキャストデータパケットトラヒックに変換し、受信機からの要請に基づいて受信機に転送するストリーミング制御装置を示すブロック図
【図２】Ｕ２Ｍ変換転送エンジン１０１の状態遷移図
【図３】初期化状態２０１のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図４】アイドル状態２０２のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図５】Ｕ２Ｍ変換状態２０３のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図６】転送状態２０４のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図７】フォワードユニキャスト状態２０５のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図８】上位層状態２０６のＵ２Ｍ変換転送エンジン１０１が行う動作について説明するフローチャート
【図９】示した照会および状態更新エンジン１０２の状態遷移図
【図１０】初期化状態３０１の照会および状態更新エンジン１０２が行う動作について説明するフローチャート
【図１１】更新状況ステーブル状態３０３の照会および状態更新エンジン１０２が行う動作について説明するフローチャート
【図１２】照会状態３０４の照会および状態更新エンジン１０２の動作について説明するフローチャート
【図１３】サブＩＧＭＰ処理エンジン１０３の状態遷移図
【図１４】初期化エンジン４０１状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図１５】アイドル４０２状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図１６】結合報告４０３状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図１７】リーブ報告４０４状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図１８】ユニキャストフォワード４０５状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図１９】ドロップパケット４０６状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図２０】トリガ照会エンジン４０７状態のサブＩＧＭＰ処理エンジン１０３が行う動作について説明するフローチャート
【図２１】本実施形態のストリーミング制御装置を用いて監視システムにサービスを提供する事例のシナリオを示す説明図
【符号の説明】
１０１Ｕ２Ｍ変換転送エンジン
１０２照会および状態更新エンジン
１０３サブＩＧＭＰ処理エンジン
１０４転送および受信機登録テーブル[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a streaming control device capable of efficiently reducing traffic on a network.
[0002]
[Prior art]
Multicast technology is an important technology for delivering audiovisual content to a plurality of receivers on an IP network in real time. Unlike the conventional unicast technique, the multicast technique does not need to make a new copy even when the content is requested from a new receiver, so that valuable network resources can be saved. This effect is particularly useful for delivering content that requires a wide bandwidth, such as MPEG content that requires most of the available network bandwidth in a single stream. Multicast technology is used.
[0003]
A content distribution source using the multicast technology (hereinafter, referred to as a “multicast distribution source”) is an arbitrary unicast IP in a class D IP address space (224.0.0.0 to 239.255.255.255). A predetermined data packet is transmitted using the IP address in the group address instead of the address. When a receiver requesting content distribution transmits an “IGMP (Internet Group Management Protocol) Membership_Report message” to a multicast router (hereinafter simply referred to as a “router”), the router transmits a packet with a group address as a destination address. Send to When not requesting the distribution of the content, the receiver transmits an “IGMP Leave_Group message” to the router. The router that has received the message sends an “IGMP Group_Query message” to check whether a receiver related to the traffic of this group exists in the same subnet. Then, if there is no response within a predetermined time, the router stops forwarding the group traffic to the subnet.
[0004]
The IGMP protocol is the basis of multicast technology. At present, improvements have been made to the IGMP protocol focused primarily on multicast technology that allows the receiver to inform routers of the multicast distribution source of the traffic they want to receive as well as the group. With such an improved IGMP protocol, unnecessary traffic transferred from a multicast distribution source to a subnet without receivers desiring traffic can be reduced. This is important for the development of the multicast technology in view of the utilization of the multicast technology and the limitation of the group address space.
[0005]
[Problems to be solved by the invention]
As described above, the process using the “IGMP Leave_Group message” according to the IGMP protocol has some delay. That is, the multicast router does not stop forwarding the group's traffic to the subnet until after the time obtained by multiplying the last member inquiry count by the last member inquiry interval. This delay results in extra traffic that the receiver is not soliciting from the subnet.
[0006]
This can cause serious problems when a fast group scan is performed by the receiver, such as leaving a predetermined group and joining another group. That is, during the delay, the router still forwards the old group traffic to the subnet, and at the same time, forwards the new group traffic to the subnet immediately after the router receives the "IGMP Membership_Report message" for the new group. There was a problem that the traffic above would be doubled. In addition, when the number of switching groups is large, there is a problem that extra traffic congests the subnet and sacrifices service to other hosts in the same subnet.
[0007]
Since these problems are caused by a process using the “IGMP Leave_Group message” of the IGMP protocol, any multicast method based on the IGMP protocol inherits the problem.
[0008]
The present invention has been made in view of the above-described conventional problems, and has as its object to provide a streaming control device capable of efficiently reducing traffic on a subnet.
[0009]
[Means for Solving the Problems]
In order to solve the above problems, in order to achieve the above object, a streaming control device according to the present invention is a streaming control device that distributes content by multicast in response to a request from a receiver, Traffic conversion means for converting the input unicast traffic into multicast traffic; and information stored in a multicast traffic transfer information database storing the transfer status of the content and the receiver requesting delivery of the content, and Traffic distribution means for distributing the multicast traffic converted by the traffic conversion means on the basis of the above rules.
[0010]
Therefore, the information of the receiver recorded in the multicast traffic transfer information database makes it possible to immediately know whether there is another receiver requesting the same traffic. Can be stopped immediately. As a result, traffic can be made more efficient and smaller.
[0011]
Further, the streaming control device according to the present invention, a message transmitting means for creating and transmitting an IGMP message at a predetermined interval, based on the response to the transmission of the IGMP message and the IGMP message transmitted from the message transmitting means, An information updating unit for updating information for multicast traffic transfer, and an interval setting unit for configuring an interval for transmitting the IGMP message are provided.
[0012]
Further, in the streaming control device according to the present invention, the traffic conversion means may include a data packet selection means for selecting a data packet of the unicast traffic input from the data distribution source, and a unicast traffic selected by the data packet selection means. Data conversion means for converting a data packet of the cast traffic into a data packet of the multicast traffic.
[0013]
Further, the streaming control device according to the present invention, when receiving the IGMP message on the multicast port, if the IGMP message is a “Membership_Report message” for the Internet group, the traffic for the multicast group corresponding to the message. And the receiver is registered in the database for the corresponding multicast group. If the IGMP message is a “Leave_Group message”, the receiver registered in the database for the corresponding multicast group is removed. Disabling the forwarding of traffic for the corresponding multicast group when the receiver is not linked to the group, so that the multicast traffic forwarding information database And a database updating means for updating.
[0014]
In the streaming control device according to the present invention, the traffic distribution unit and the database updating unit share the multicast traffic transfer information database.
[0015]
The streaming control device according to the present invention includes a plurality of output links for outputting multicast traffic data packets and a plurality of input links for inputting unicast traffic data packets.
[0016]
Also, in the streaming control device according to the present invention, the input link has the function of the output link, the output link has the function of the input link, and connects the input link to a plurality of data distribution sources. The link is connected to multiple receivers.
[0017]
Further, a network system according to the present invention is a network system including the streaming control device according to the present invention, wherein the receiver can receive a data stream from any data distribution source in any cluster, and the data distribution source The streaming control device is connected to a switch connected to, and each output of the streaming control device is connected to the receiver via the switch, thereby supporting the data distribution source and a plurality of clusters of the receiver. So that the network is configured.
[0018]
In this way, a network structure in which a plurality of streaming control devices are interconnected to form a framework capable of having any number of data distribution sources and receivers regardless of hardware limitations is provided. I have.
[0019]
Further, in the network system according to the present invention, the streaming control device is used for switching between the data distribution sources at a high frequency.
[0020]
BEST MODE FOR CARRYING OUT THE INVENTION
The streaming control device according to the present invention handles IGMP messages according to the IGMP protocol and is used in a process on the router side that operates according to the IGMP protocol. In addition, the streaming control device manages a multicast traffic transfer information database including information on the receiver. More specifically, each time the receiver transmits an IGMP message “IGMP Membership_Report message” and “IGMP Leave_Group message” to the streaming control device, the streaming control device records or records the receiver that transmitted each message. To delete. Since the streaming controller can immediately know whether there is another receiver requesting the same traffic from the recorded information of the receiver, the transmission can be stopped immediately when there is no receiver. There is.
[0021]
Further, the streaming control device has an engine that converts unicast traffic to multicast traffic. This is to make the starting point of the multicast traffic closer to the receiver so that the influence of the delay caused by the “IGMP Leave_Group message” is minimized. Also, a network structure in which a plurality of streaming control devices are interconnected is possible so that a framework capable of having an arbitrary number of data distribution sources and receivers is formed irrespective of hardware limitations.
[0022]
Hereinafter, embodiments of a streaming control device according to the present invention will be described in detail with reference to the drawings. The streaming control device of the present embodiment provides a device that supports high-speed group switching in, for example, a digital security system based on IP.
[0023]
The streaming control device according to the present embodiment is arranged on an IP network. For the streaming controller to function properly, the receiver needs to have an IGMP host-side stack. That is, the receiver uses the IGMP message to request multicast traffic to the streaming controller or leave a predetermined multicast group to the streaming controller.
[0024]
Further, since the streaming control device of the present embodiment has an engine for processing IGMP messages corresponding to RFC2236, other network nodes in the network can use IGMP for multicast signaling without modification to the stack. When the streaming control device of the present embodiment is provided in a network, the data distribution source transmits unicast traffic to the streaming control device having a destination address (U2M address), and when the streaming control device receives the traffic, the traffic is transmitted. To multicast.
[0025]
In addition, when the receiver requests reception of traffic of a predetermined group, the receiver transmits an “IGMP Membership_report message” of the group to the streaming control device of the present embodiment. When the streaming control device receives this message, it transfers the traffic of the predetermined group to the port to which the receiver is connected, and simultaneously records the information of the receiver in the multicast traffic transfer information database. On the other hand, when the receiver requests to stop receiving traffic of a predetermined group, the receiver transmits an “IGMP Leave_Group message” of the group to the streaming control device of the present embodiment. When the streaming controller receives this message, it checks the multicast traffic forwarding information database and stops forwarding group traffic to that port unless another receiver has requested the same group of traffic on the same port. .
[0026]
In fact, a single streaming controller can only support a certain number of data distribution sources due to hardware limitations. Thus, some streaming controllers can be operated with a network architecture to support more data distribution sources. Thus, the interconnect device can support any cluster of data distribution sources and receivers.
[0027]
The streaming control device of the present embodiment is set and controlled manually or by some software. This software is executed in the streaming control device of this embodiment or on a remote host. When the streaming control device of the present embodiment receives a message from this software, the software can control the streaming control device in real time.
[0028]
The streaming control device records statistical information on traffic passing through the streaming control device, and the information is stored in an external storage device. Therefore, the software running on the streaming control device or the remote host according to the present embodiment can search this information in real time by a specific type of message.
[0029]
In addition, the engine provided in the streaming control device of the present embodiment can be made available or unavailable during operation by the setting tool. The streaming controller plays the role of a general network when some of the engines are unavailable. For example, when the unicast / multicast conversion engine is disabled, the device operates as a multicast router by fast group switching.
[0030]
Hereinafter, an example in which a streaming control device that distributes audiovisual content is used in an IP-based digital security system will be described. The streaming control device of the present embodiment is a device that performs conversion from unicast to multicast and transfers packets, and uses an “IGMP Membership-Report message”, an “IGMP Leave_Group message”, and an “IGMP Leave_Group message” according to the IGMP (Internet Group Management Protocol) protocol. General_Query message ". In the following description, these terms are used as follows.
[0031]
First, a “packet” is a constituent unit of data distributed on a network. A “stream” is a collection of packets transferred to a network having a common attribute. "Traffic" is a collection of streams transmitted on a network. The “flow” is a data path used to distribute a stream. “QoS” is a term of “service quality” of a data stream or traffic. The “QoS probe” is a device that measures and notifies the QoS of a flow at one of the network components. “NE” refers to a network element used to function as a network router, gateway, or intelligent network hub. The “upper layer” refers to an arbitrary entity on the upper part of the device that processes the packet transmitted from the streaming control device of the present embodiment.
[0032]
FIG. 1 is a block diagram illustrating a streaming control apparatus that converts unicast data packet traffic into multicast data packet traffic and transfers the traffic to a receiver based on a request from the receiver. The streaming control apparatus according to the present embodiment shown in the figure has four main components: a U2M conversion and transfer engine 101, an inquiry and status update engine 102, a sub-IGMP processing engine 103, and a transfer and receiver registration table. 104.
[0033]
Note that the structure of the streaming control device shown in the figure is simplified for explanation, and does not always reflect the actual physical architecture. Also, in practice, the device may have a more complex architecture and special engines. Further, FIG. 1 shows only main data paths.
[0034]
The data path shown in FIG. 1 is a data path A from the inquiry and state update engine 102 to the U2M conversion transfer engine 101, a data path B between the inquiry and state update engine 102 and the transfer and receiver registration table 104, a U2M conversion Data path C between transfer engine 101 and transfer and receiver registration table 104, data path D between sub-IGMP processing engine 103 and transfer and receiver registration table 104, and U2M conversion transfer engine 101 and sub-IGMP processing engine 103 , A data path F from the sub IGMP processing engine 103 to the inquiry and status update engine 102. As shown in FIG. 1, data paths A and F are unidirectional, and the other data paths B, C, D and E are bidirectional. The direction of the data path indicates the direction of information flow on the data path.
[0035]
In practice, there are more data paths, special control paths and signaling paths. The U2M conversion transfer engine 101 and the sub IGMP processing engine 103 shown in FIG. 1 are implemented by a hardware method such as an FPGA or as a software module. When these engines are implemented in hardware, the data path serves to physically connect them. If these engines were implemented as software modules, the data paths shown in FIG. 1 would indicate the interface between these modules.
[0036]
As shown in FIG. 1, unicast traffic from a data distribution source is input to the U2M conversion transfer engine 101 from a unicast port. The U2M conversion and transfer engine 101 processes traffic based on a predetermined rule, and transfers the obtained traffic to an output port based on the information stored in the transfer and receiver registration table 104 and the predetermined rule.
[0037]
FIG. 2 is a state transition diagram of the U2M conversion transfer engine 101. As shown in the figure, the U2M conversion and transfer engine 101 performs six states, an initialization state 201 for performing initialization, an idle state 202 which transits to another state according to various conditions, and performs unicast / multicast conversion of a packet. It can take one of a U2M conversion state 203, a transfer state 204 for transferring a packet, a forward unicast state 205 for transferring a unicast packet, and an upper layer state 206 for transferring and processing a packet to an upper layer.
[0038]
The U2M conversion transfer engine 101 starts from an initialization state 201. FIG. 3 is a flowchart illustrating an operation performed by the U2M conversion transfer engine 101 in the initialization state 201. As shown in FIG. 3, the U2M conversion transfer engine 101 reads the hardware configuration (S2101). In step S2101, the number of ports, unicast port addresses, and multicast port addresses can be read, but more attributes can be read. Next, the U2M conversion transfer engine 101 reads the user configuration (S2102). Step S2102 includes reading of the unicast / multicast method, the unicast address for U2M conversion, the IP address of the device, the multicast group for conversion, and the number of receivers that support the same camera at the same time. It is not limited to.
[0039]
Next, the U2M conversion transfer engine 101 creates and initializes a “forward_condition_tbl table” and a “receiver_register_tbl table” corresponding to the configuration read in steps S2101 and S2102 (S2103). These tables are the transfer and receiver registration table 104 shown in FIG. 1, and can be recorded in hardware as a ROM or a memory block. The initial values of the two tables take arbitrary values. For example, the value of the “forward_condition_tbl table” is set to −1, and the value of the “receiver_register_tbl table” is set to 0.
[0040]
After the initialization state 201, an idle state 202 is set. FIG. 4 is a flowchart illustrating an operation performed by the U2M conversion transfer engine 101 in the idle state 202. The steps described below are executed when the U2M conversion transfer engine 101 transitions from the idle state 202 to another state. It is also assumed that the event that triggers the transition is the arrival of a packet. Otherwise, a default transition back to the idle state 202 occurs.
[0041]
As shown in FIG. 4, the U2M conversion transfer engine 101 obtains a packet that causes the event (S2201). Next, the U2M conversion transfer engine 101 determines whether the packet obtained in step S2201 is from a unicast port (S2202). If the packet is from a unicast port, the process proceeds to step S2203; Proceed to step S2204. In step S2203, the destination address of the packet obtained in step S2201 is obtained. Next, the destination address is compared with the arranged U2M address to determine whether the two addresses are equal (S2205). If they are equal, the process proceeds to step S2210, and if not, the process proceeds to step S2208. In step S2210, the “unicast_pkt_destined_u2m_address condition” (the converted unicast address of the packet to be converted) is set, and the U2M conversion transfer engine 101 transitions to the U2M conversion state 203.
[0042]
On the other hand, in step S2208 (when the destination address is not equal to the U2M address), it is determined whether or not the destination address acquired in step S2202 is equal to the IP address of the device itself. Proceed to step S2211. In step S2209, “Other_packet_destined_for_U2Mbox condition” is set, and the state transits to the upper layer state 206. On the other hand, in step S2211, “Unicast_not_for_U2M condition” is set, and the U2M conversion / transfer engine 101 transits to the forward unicast state 205.
[0043]
If the result of determination in step S2202 is that the packet obtained in step S2201 is not from a unicast port, the flow advances to step S2204. In step S2204, it is determined whether the packet is from the sub-IGMP processing engine 103 (S2204). If the packet is from the sub-IGMP processing engine 103, the process proceeds to step S2206; otherwise, the process proceeds to step S2207. In step S2206, “Pkt_from_Sub-IGMP_engine condition” is set, and the U2M conversion / transfer engine 101 transits to the forward unicast state 205. On the other hand, in step S2207, “Query_pkt_from_Query_engine condition” is set, and the U2M conversion transfer engine 101 transitions to the transfer state 204.
[0044]
As described above, when the “unicast_pkt_destined_u2m_address condition” is set as a transition condition from the idle state 202, the U2M conversion transfer engine 101 transitions to the U2M conversion state 203. FIG. 5 is a flowchart illustrating an operation performed by the U2M conversion transfer engine 101 in the U2M conversion state 203. As shown in the figure, the U2M conversion and transfer engine 101 first obtains a distribution source address of a packet that induces a transition (S2301). Next, unicast / multicast conversion (U2M conversion) is applied to packets based on the configuration scheme.
[0045]
Several conversion schemes are conceivable, and the U2M conversion transfer engine 101 follows one of those configured as the current working scheme. For example, the U2M translation and forwarding engine 101 can translate all traffic into one configured multicast group by changing the destination address field of all packets to the same multicast group address. Further, the U2M conversion transfer engine 101 can convert traffic based on the distribution source address of the traffic. One method is possible by storing the low 8 bits of the initial destination address and setting the high 24 bits of the destination address in the multicast group address prefix, but numerous schemes are possible.
[0046]
Next, after the conversion in step S2302, the U2M conversion transfer engine 101 sets a new destination address in the packet destination address field (S2303). Then, the U2M conversion transfer engine 101 transitions to the transfer state 204 after finishing the processing of the U2M conversion state 203. However, this transition is not protected.
[0047]
As described above, when the “Query_pkt_from_Query_engine condition” is set as a transition condition from the idle state 202, the U2M conversion transfer engine 101 transitions to the transfer state 204. FIG. 6 is a flowchart illustrating an operation performed by the U2M conversion transfer engine 101 in the transfer state 204. As shown in the drawing, the U2M conversion transfer engine 101 first calculates “grp_index” and “table index” from the destination address of the packet (S2401). Note that a mapping method from the destination address to “grp_index” is configurable. One simple case is to use the low 8 bits of the destination address as the exponent, but numerous mapping schemes are possible and the above is not the only one.
[0048]
After obtaining the "grm_index", the "forward_condition_tbl" table is checked to determine whether there is a port having a request for packets of this group, and whether the destination address is all_DRP address: 224.0.0.1. (S2402). If there is a port that has a request for traffic in this group, or if the destination address is "224.0.0.1", the packet is duplicated and forwarded to that port. These processes are performed in parallel when the U2M conversion transfer engine 101 is implemented in hardware. If no port has a request for this group's traffic, the packet is discarded and the associated source is released. After the transfer state 204, the U2M conversion transfer engine 101 transitions back to the idle state 202.
[0049]
As described above, if the “Pkt_from_Sub-IGMP_engine condition”, “unicast_not_for_U2M condition” or “broadcast_pkt condition” is set as a transition condition from the idle state 202, the U2M conversion transfer engine 101 transitions to the forward unicast state 205. . FIG. 7 is a flowchart illustrating an operation performed by the U2M conversion transfer engine 101 in the forward unicast state 205. As shown in the figure, first, the U2M conversion transfer engine 101 obtains a packet, transfers an output port index, and calculates (S2501). This output port index is calculated based on the rule set in the box. The rules are configurable and will be described later. Next, the U2M conversion transfer engine 101 transfers the unicast packet to the output port (S2502). However, if the rule indicates that no port needs the packet, the packet is dropped and the associated distribution source is released.
[0050]
As described above, when the “Other_packet_destined_for_U2Mbox condition” is set as a transition condition from the idle state 202, the U2M conversion transfer engine 101 transitions to the upper layer state 206. FIG. 8 is a flowchart illustrating an operation performed by the U2M conversion transfer engine 101 in the upper layer state 206. As shown in the figure, the U2M conversion transfer engine 101 transmits the packet to the upper layer state 206 for processing (S2601). The upper layer state 206 is any hardware or software module that reads the contents of the packet and operates according to the contents.
[0051]
FIG. 9 is a state transition diagram of the query and state update engine 102 shown in FIG. The query and status update engine 102 has a function of periodically generating an “IGMP general_query message” and a function of maintaining the transfer and receiver registration table 104.
[0052]
The query and state update engine 102 begins with an initialization state 301. FIG. 10 is a flowchart illustrating an inquiry about the initialization state 301 and an operation performed by the state update engine 102. As illustrated in FIG. 10, the inquiry and state update engine 102 sets “Enable_Query” in the streaming control device of the present embodiment (S3101). If there are multiple devices in the same network, the only device is the queryer, which sends an "IGMP general_Query message". The decision as to which device will be the interrogator, as described below, is made manually or by a predetermined specific protocol.
[0053]
Next, the query and status update engine 102 determines whether the query (Query) is valid (S3102). If the query is valid (the device is configured as a query device), the process proceeds to step S3103, and the query is not valid (query). If it is not configured as a device), a series of processing ends. In step S3103, the inquiry and status update engine 102 obtains the configuration of the inquiry interval from the streaming control device of the present embodiment (S3103). It should be noted that the predetermined default value is transmitted into the device and is optionally modified manually or through a specific protocol. Basically, the shorter the interval, the more bursty the more IGMP messages need to be processed by the sub-IGMP processing engine 103 within the same period. On the other hand, the longer the interval, the longer the time before the streaming control device of the present embodiment stops the transfer of the multicast traffic when the “IGMP Leave_Group message” is lost on the link.
[0054]
Next, the inquiry and status update engine 102 forms an "IGMP General_Query message" (S3104). The message needs to be formed based on RFC2236 with the maximum response time according to the inquiry interval. Since the “IGMP General_Query message” always remains in the same state, the formed “IGMP General_Query message” is reused later. Next, the inquiry and status update engine 102 starts an inquiry timer (S3105). The length of the inquiry timer is set to the inquiry interval as described above. Then, the inquiry and state update engine 102 transitions to the idle state 302. However, this transition is not protected. The action associated with this transition is to set an inquiry timer (Query_Timer).
[0055]
When the “Query_timer_expire condition” is set when the streaming control device of the present embodiment is configured as an inquiry device, the inquiry and state update engine 102 transitions from the idle state 302 to the update state table state 303. However, except in this case, the sub-IGMP processing engine 103 transmits a signal. FIG. 11 shows a flowchart describing the query of the update status stable status 303 and the operation performed by the status update engine 102. As shown in FIG. 11, in step S3301, the value of Forward_status_tbl [port_no] [grp_index] is reduced unless each of the counter values of the multicast port for each group is 0 (zero). When the counter value reaches 0, receiver_register_tbl [port_no] [ grp_index] is reset. This step is performed for all ports and all groups, and is performed so as to be executed in parallel with hardware.
[0056]
The inquiry and state update engine 102 transitions from the update state table state 303 to the inquiry state 304 when the streaming control device of the present embodiment is configured as an inquiry device. However, otherwise, the state transits to the idle state 302. FIG. 12 shows a flowchart describing the query of query status 304 and the operation of status update engine 102. As shown in FIG. 12, in step S3201, a “formed IGMP General_Query message” is transmitted to the U2M conversion transfer engine 101 via the data path 1. The query and state update engine 102 then transitions from the query state 304 to the idle state 302. At the time of this transition, a value given in advance is set to the inquiry timer (Query_Timer).
[0057]
FIG. 13 is a state transition diagram of the sub-IGMP processing engine 103 shown in FIG. The sub-IGMP processing engine 103 processes the IGMP message received at the multicast port, and performs transfer and updates the receiver registration table 104 accordingly. The sub IGMP processing engine 103 transfers the unicast packet received at the unicast port. Alternatively, the U2M conversion transfer engine 101 performs an operation according to a rule preset in the streaming control device of the present embodiment.
[0058]
The sub-IGMP processing engine 103 starts from the initialization engine 401 state. FIG. 14 is a flowchart illustrating an operation performed by the sub IGMP processing engine 103 in the state of the initialization engine 401. As illustrated in FIG. 14, the sub IGMP processing engine 103 performs hardware setting on the streaming control device of the present embodiment (S4101). The setting includes a unicast port address, a multicast port address, the number of multicast ports, and the like.
[0059]
Next, the sub IGMP processing engine 103 obtains software settings from the streaming control device of the present embodiment (S4102). Possible settings include the IP address of the device, network robust settings, whether the device is an interrogator, and the address of the controller port. Next, the sub-IGMP processing engine 103 initializes the unicast transfer table when required by the settings obtained in the above steps (S4103).
[0060]
Next, the sub IGMP processing engine 103 transitions from the initialization engine 401 to the idle 402 state. In the present embodiment, it is assumed that the transition from the idle state 402 is performed by the arrival of a packet, and that other events fall into the category of “default” which makes a transition to the idle state 402 itself. There are many types of events, and the assumption is made only for convenience of explanation.
[0061]
FIG. 15 is a flowchart illustrating an operation performed by the sub IGMP processing engine 103 in the idle 402 state. The process described below is executed when the sub IGMP processing engine 103 transitions from the idle state 402 to another state. As shown in FIG. 15, the sub-IGMP processing engine 103 obtains a packet that triggers an event (S4201). Next, the sub-IGMP processing engine 103 determines whether the packet acquired in step S4201 is an IP packet (S4202). If the packet is an IP packet, the process proceeds to step S4203; otherwise, the process proceeds to step S4207. .
[0062]
In step S4207 (when the packet is not an IP packet), “Other_packet condition” is set, and the sub IGMP processing engine 103 transitions to the state of the drop packet 406. On the other hand, in step S4203 (when the packet is an IP packet), it is determined whether the packet acquired in step S4201 is an IGMP packet by checking the header information of the packet (S4203). If the packet is not an IGMP packet, the process proceeds to step S4204. , IGMP, the process proceeds to step S4205. In the header information, the IGMP packet is a type D IP address of class D.
[0063]
In step S4204 (if it is not an IGMP packet), it is determined whether the packet is a unicast packet (S4204). If it is a unicast packet, the process proceeds to step S4206; if it is not a unicast packet, the process proceeds to step S4207 described above. The state transits to the drop packet 406 state. In step S4206 (when the packet is a unicast packet), “unicast_pkt_received condition” is set (S4206), and the sub IGMP processing engine 103 transits to the unicast forward 405 state.
[0064]
If it is determined in step S4203 that the packet is an IGMP packet, the process proceeds to step S4205. In step S4205, the IGMP type and group fields of the packet are obtained. Next, in step S4208, the group address is checked based on the settings in the streaming control device of the present embodiment, and the type field is equal to “membership_report” or “Leave_Group”, that is, the IGMP group matches the multicast group prefix, It is determined whether the message is a “membership_report message” or a “Leave_Group message” (S4208). In step S4208, if they are equal, the process proceeds to step S4209. If they are not equal, the process proceeds to step S4210.
[0065]
In step 4209 (if equal), “Received_IGMP_membership_report_pkt condition” or “Receive_IGMP_Leave_group_pkt condition” is set based on the type field, and the sub-IGMP processing engine 103 transitions to the combined report 403 state or the leave report 404 state. On the other hand, in step S4210 (if not equal), it is determined whether the message is an “IGMP General_Query message” or whether the streaming control device of the present embodiment is a non-inquirer. In step S4210, if the above two conditions are satisfied, the process proceeds to step S4211, and if not, the process proceeds to step S4207, and the sub IGMP processing engine 103 transitions to the state of the drop packet 406. In step S4211, “non-Query && IGMP_general_query condition” is set, and the sub-IGMP processing engine 103 transitions to the state of the trigger inquiry engine 407.
[0066]
Next, upon receiving the “IGMP Membership_Report message”, the sub IGMP processing engine 103 makes a transition from the idle 402 state to the combined report 403 state. FIG. 16 is a flowchart illustrating an operation performed by the sub IGMP processing engine 103 in the combined report 403 state. As shown in FIG. 16, the sub IGMP processing engine 103 obtains a port number “port_No” for receiving a packet (S4301). Next, the group address in the packet is mapped to a group index “grp_index” by the same hash function used in the transfer state of the U2M conversion transfer engine 101 (S4202). Next, the sub IGMP processing engine 103 sets the corresponding cell of the “Forward_status_tbl [port_no] [grp_index] table” to a value that enables the forwarding (forward) of the multicast traffic (S4303).
[0067]
Next, the sub IGMP processing engine 103 obtains the distribution source address of the IGMP message and sets the corresponding bit of the corresponding cell in the receiver registration table “receiver_register_tbl” (S4304). Next, the bit of the cell is set in the “Receiver_register_tbl [port_no] [grp_index] table” (S4305). This operation need not be a bitmap, but can be recorded in any form, and the receiver registration table can be multidimensional. When the above steps are performed, the message packet is destroyed, and the associated distribution source is released (S4306). Then, the sub IGMP processing engine 103 makes a reverse transition from the combined report 403 state to the idle 402 state.
[0068]
Similarly, upon receiving the “IGMP Leave_Group message”, the sub IGMP processing engine 103 transitions from the idle 402 state to the leave report 404 state. FIG. 17 is a flowchart illustrating an operation performed by the sub IGMP processing engine 103 in the leave report 404 state. Steps S4401, S4402, and S4403 are the same as steps S4301, S4302, and S4304 performed by the sub IGMP processing engine 103 in the combined report 403 state shown in FIG. 16, and the hashing function and the mapping method are the same for both. After these three steps, the sub-IGMP processing engine 103 obtains the corresponding bits of the receiver registration table “Receiver_register_tbl [port_no] [grp_index] table” (S4404). Next, it is determined whether to set the corresponding bit (S4405). It checks whether the source has previously sent a "Membership_Report message" for this group. If the distribution source has not requested the group, the sub IGMP processing engine 103 does not process the “IGMP Leave_Group message”.
[0069]
If the corresponding bit has been set in step S4405, that is, if the distribution source has transmitted the “Membership_Report message”, the process advances to step S4406 to cancel the setting of the corresponding bit and leave it unset (S4406). Next, the sub IGMP processing engine 103 determines whether or not it is the last receiver to leave the group on this port (S4407). If it is the last receiver, the process proceeds to step S4408. In step S4408, a value that can be transferred to the traffic of the group of the U2M conversion transfer engine 101 is set in the corresponding cell Forward_status_tbl [port_no] [grp_index] in the transfer status table. When the above steps are performed, the message packet is destroyed, and the associated distribution source is released (S4409). Then, the sub-IGMP processing engine 103 makes a reverse transition from the leave report 404 state to the idle 402 state. However, this transition is not protected.
[0070]
In addition, when the sub IGMP processing engine 103 receives a unicast packet and transfers it, it transitions from the idle 402 state to the unicast forward 405 state. FIG. 18 is a flowchart illustrating an operation performed by the sub IGMP processing engine 103 in the unicast forward 405 state. As shown in FIG. 18, the sub IGMP processing engine 103 obtains a unicast packet (S4501). Next, the transfer rule and the device status are checked to determine a multicast port to which the packet should be transferred (S4502). Next, the packet is transferred to the unicast port and the multicast port determined in step S4502 (S4503). Then, the sub IGMP processing engine 103 transitions from the unicast forward 405 state to the idle 402 state.
[0071]
Further, when the “Other_packet condition” is set in the idle 402 state, the sub IGMP processing engine 103 transitions from the idle 402 state to the drop packet 406 state. FIG. 19 is a flowchart illustrating an operation performed by the sub IGMP processing engine 103 in the state of the drop packet 406. As shown in FIG. 19, the sub-IGMP processing engine 103 drops the packet and releases the related distribution source (S4601). Then, the sub-IGMP processing engine 103 transitions from the state of the drop packet 406 to the state of the idle 402.
[0072]
Further, when the “non_Queryer && IGMP_general_query condition” is set in the idle 402 state, the sub IGMP processing engine 103 transitions from the idle 402 state to the trigger inquiry engine 407 state. FIG. 20 is a flowchart illustrating an operation performed by the sub IGMP processing engine 103 in the trigger inquiry engine 407 state. As shown in FIG. 20, the sub IGMP processing engine 103 transmits a signal to the inquiry and status update engine 102 to indicate the arrival of the “IGMP General_Query message” (S4701). Since there may be a plurality of copies of the same “General_Query message” received by various ports, the combination number of the IP packet is used to determine whether this is a new inquiry message. Only new inquiry messages trigger a signal. Then, the sub IGMP processing engine 103 transitions from the state of the trigger inquiry engine 407 to the state of idle 402.
[0073]
The “Forward_status_tbl table” and the “Receiver_register_tbl table” which are the transfer and receiver registration table 104 are realized by hardware and software. When implemented in software, the table is created by device settings and dynamically modified. As shown in FIG. 1, these tables are accessible (B, C, D) from all three engines, with only the query and status update engine 102 and the sub-IGMP processing engine 103 changing to table contents. Therefore, control for adjusting the simultaneous access to the table is required. The control is performed using a lock signal when executed by hardware, and is executed by, for example, “mutex” when executed by software.
[0074]
As described above, the architecture of the streaming control device of the present embodiment does not limit the number of unicast ports and multicast ports. For this reason, the streaming control device of the present embodiment is easily executed with a plurality of multicast ports and unicast ports using the same engine. The number of ports is rather determined by hardware limitations instead of the above algorithm. This architecture allows a unicast port to be a multicast port, and vice versa, by simply combining the U2M conversion and forwarding engine 101 and the sub-IGMP processing engine 103.
[0075]
The functionality of the engine of the streaming control device of the present embodiment may be enabled or disabled. If the engine is enabled, the device operates normally as described above. On the other hand, when the engine is disabled, the device is not present for traffic and acts like a bridge or switch. It is easy to make these valid and invalid operations. For example, a method using a lock signal when the engine of the apparatus is executed by hardware, and using a flag when the engine of the apparatus is executed by software is also possible. These operations can be performed by remote control.
[0076]
FIG. 21 is an explanatory diagram showing a scenario of a case where a service is provided to a monitoring system using the streaming control device of the present embodiment. As shown in FIG. 21, there are a plurality of clusters of cameras (data sources) connected to the apparatus by a layer 2 switch corresponding to the switches in the claims. This device exists in the same network. This network structure facilitates extension of the network to any number of cameras. Due to hardware limitations, such as link capacity, one device can only connect cameras (data sources) up to a certain amount. According to the structure, this problem can be solved by providing a plurality of streaming control devices of the present embodiment. The monitoring device connected to this device can monitor traffic from any camera in the camera cluster. This monitoring device can also perform high-speed switching of the camera. The switching speed is determined only by the processing speed of the sub IGMP processing engine 103.
[0077]
As shown in FIG. 21, when one or more streaming control devices of the present embodiment are in a network, a layer 2 switch and the present device form a loop. Careless handling can cause packet looping potential problems. To solve this problem, some techniques are needed but provide a solution.
[0078]
As described above, when there are a plurality of streaming control apparatuses of the present embodiment in the same network, one of them is used as an inquirer, which periodically sends out an “IGMP General_Query message”. The selection of this interrogator is performed manually or by a predetermined protocol. Because of the symmetry of the network architecture, any one of the devices is placed as an interrogator without affecting the performance of the network. This selection is also made by an arrangement message. For example, any device initially recognizes itself as an interrogator and starts sending “IGMP_Query messages”. When one device receives a "General_Query message" from another device, it checks the address of the transmitter. If the sender's address is less than its own address, it becomes a non-inquirer and performs a non-inquirer routine. Also, some existing well-defined placement messages are used for the same purpose.
[0079]
When performing the operation of the streaming control device of the present embodiment, if there are a plurality of multicast ports, one of the ports is configured as “control_port” that transfers packets separately. The selection of "control_port" is made manually at the time of deployment or by a specific protocol. In the manual case, the operator can select any layer 2 switch connected to the monitor and place the multicast port connected to this switch to be the "control_port" of the device. This is a simple routine that can be easily accomplished as described below. After identifying the interrogator, any multicast port can be selected as "control_port" based on a predetermined arrangement. The interrogator transmits "control_port_msg" sent from the control port. In the case of a non-inquirer, the port where the non-inquirer has received this message is arranged as “control_port”.
[0080]
The following is an example of a rule used to prevent packet looping in a network.
For the U2M conversion transfer engine 101, (1) if the packet is from a unicast port, transfer to the multicast port if the streaming control device of the present embodiment is an inquirer, and "control_port" if the streaming control device is a non-inquirer. (2) If the packet is from the sub-IGMP processing engine 103, the packet is forwarded to all ports except the receiving port in the case of the inquirer, and the packet is dropped in the case of the non-inquirer. On the other hand, for the sub IGMP processing engine 103, it drops all the multicast packets (non-IGMP messages), transfers the packets to the unicast port, and transfers the packets to the U2M conversion transfer engine 101.
[0081]
<Rule 1> Rules for transferring packets when a plurality of devices exist in the same network
These rules are either set at the time of deployment or remotely set by a protocol at run time. An example of a possible protocol is to run one protocol with a device receiving over the TCP protocol, accepting control messages sent to it, as specified below.
structure Rule_msg}
int enable_u2m;
int enable_igmp;
int querier_flag;
int control_port_index;
int u2m_unicast_querier_pt;
int u2m_unicast_non-querier_pt;
int u2m_igmp_query_pt;
int u2m_igmp_non-querier_pt;
int igmp_multicast_pt;
int igmp_unicast_pt:
int igmp_other_pt;
｝;
[0082]
<Data structure 1> Message that conveys rules for packet transfer
Define the fields in the data structure as follows:
"Enable_u2m"-This field indicates whether the U2M conversion and forwarding engine 101 of the device is enabled. Case values: 1, enable; -1, disable
"Enable_igmp"-This field indicates whether the sub-IGMP processing engine 103 of the device is enabled. Case values: 1, enable; -1, disable
"Querier_flag"-This field indicates whether this device is configured as an interrogator. Case value: 1, set to inquirer; -1, set to non-inquirer
"Control_port_index"-This field indicates which port to set as the control port.
"U2m_unicast_querier_pt"-This field conveys the bitmap for the port to which the packet should be forwarded if the packet came from the U2M translation and forwarding engine 101 unicast if the device is an interrogator.
"U2m_unicast_non-querier_pt"-This field conveys the bitmap for the port to forward the packet to if the packet comes from the unicast port of the U2M translation and forwarding engine 101 when the device is a non-inquirer.
"U2m_igmp_querier_pt"-This field conveys the bitmap for the port to which a packet should be forwarded if a packet arrives from the sub-IGMP processing engine 103 of the U2M conversion forwarding engine 101 when the device is an interrogator.
"U2m_igmp_non_querier_pt"-This field conveys the bitmap for the port to which the packet should be forwarded if a packet arrives from the sub-IGMP processing engine 103 of the U2M conversion forwarding engine 101 when the device is a non-inquirer.
"Igmp_multicast_pt"-This field conveys the bitmap for the port to which the multicast packet should be forwarded if it arrives on the sub-IGMP processing engine 103. Note that all zeros means that the packet should be dropped.
"Igmp_unicast_pt"-This field carries information on whether to forward unicast packets received on the sub-IGMP processing engine 103. Case values: 1 means transfer, -1 means drop packet.
• "igm_other_pkt"-This field carries information on whether to forward other packets (other than unicast, IGMP message packets).
[0083]
The above rule message data type is an illustrative example. In practice, messages come in a variety of forms, can have a few fields, and have special message types for signaling and acknowledgment.
[0084]
The streaming controller of this embodiment can log real-time statistics on traffic passing through it, making it available locally or remotely. This is performed by operating a process for transmitting a log information report message as follows to a device operating on a TCP port when requested.
[0085]
structure log_report ｛
int time;
int device_identity;
int port_num;
int grp_num;
structure grp_log grp_report [port_num] [grp_num];
｝;
structure grp_logｌｏ
int port_index;
int grp_index;
int pkt_forwarded;
int giga_pkt_forwarded;
int pkt_dropped;
int giga_pkt_dropped;
int bits_forwarded;
int giga_bits_forwarded;
int bits_dropped;
int giga_bits_dropped;
int avg_bandwidth;
int receiver_rum;
structreceiver_log receiver_report [receiver_rum];
｝;
structure receiver_logｌｏ
int receiver_identity;
int join_time;
int leave_time;
int avg_bandwidth;
｝;
[0086]
<Data structure 2> Data structure for log report message
The fields of the data structure are defined as follows.
"Time"-This field conveys information about when this report should be generated. The meaning of the value depends on the actual processing system.
"Device_identity"-This field conveys information about the identity of the device that is interested in this report. The meaning of the value depends on the processing system.
"Port_num"-This field indicates the number of ports included in this report.
"Grp_num"-This field indicates the number of groups included in this report.
"Grp_report"-This is a variable size array that contains information about a group on a given port. It is the type structure grp_log.
"Port_index"-This indicates the port index for this group log report.
"Grp_index"-This indicates the group index for this group log report.
"Pkt_forward", "giga_pkt_forward"-These two fields indicate the number of packets transferred for this group of traffic on this port.
"Pkt_dropped", "giga_pkt_dropped"-These two fields indicate the number of packets dropped for this group of traffic on this port.
"Bits_forward", "giga_bits_forward"-These two fields indicate the number of bits that will be in a forwarding state for this group of traffic on this port.
"Bits_dropped", "giga_bits_dropped"-These two fields indicate the number of bits that will be dropped for this group of traffic on this port.
"Avg_bandwidth"-This field is the average bandwidth of this group of traffic on this port.
• "receiver_num"-This field indicates the number of receiver records included in the report.
"Receiver_report"-this is a variable size array that contains the receiver_num number of receiver record information. It is of data type struct receiver_log.
"Receiver_identity"-This indicates the entity of the receiver regarding this receiver record information.
"Join_time"-This field indicates the receiver's splice group time. "Leave_time"-This field indicates the time the receiver leaves the group.
"Avg_bandwidth"-This field indicates the average bandwidth of the receiver.
[0087]
These message types are for illustrative purposes only and should not be considered as the only ones used for the device. The recording information is also executed in another processing mode. The above information is collected by all three engines and stored in a device, ie, an external storage device, as a database for later search.
[0088]
As described above, according to the streaming control device of the present embodiment, service quality can be provided to traffic passing through the device. For example, in a given receiver, throughput parameters can be set, so that when a packet is transferred to a port of the device, traffic can be formed. Further, even if this apparatus is arranged in a network, no special change is required for other network nodes, so that the influence and cost of the arrangement can be minimized. Therefore, the present apparatus can be easily applied to an existing system.
[0089]
The device is also remotely configurable and reporting, i.e., remote / centralized controllers can be used to manage distributed devices. Also, large networks can be supported by interconnecting several devices to form a framework. The apparatus also facilitates the realization of a remote / centralized monitor to provide real-time statistics on local traffic for remote access. Further, a framework for recording QoS information and a method for incorporating a special QoS framework are provided.
[0090]
In addition, a certain special port is allocated to the above-mentioned camera or surveillance device, and when there are a plurality of these devices, a predetermined attribute is allocated to a predetermined device, and traffic, particularly a predetermined packet, is transferred to an output port based on a predetermined configuration rule. This may prevent looping in the network. Also, the device and device attributes of this link or network service port can be self-configured.
[0091]
【The invention's effect】
As described above, according to the streaming control device of the present invention, it is possible to immediately know whether there is another receiver requesting the same traffic, based on the information of the receiver recorded in the multicast traffic transfer information database. Therefore, when there is no receiver, distribution of traffic can be stopped immediately. As a result, traffic can be made more efficient and smaller.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a streaming control device that converts unicast data packet traffic into multicast data packet traffic and transfers the traffic to a receiver based on a request from the receiver.
FIG. 2 is a state transition diagram of a U2M conversion transfer engine 101.
FIG. 3 is a flowchart illustrating an operation performed by a U2M conversion transfer engine 101 in an initialization state 201.
FIG. 4 is a flowchart illustrating an operation performed by the U2M conversion transfer engine 101 in an idle state 202.
FIG. 5 is a flowchart illustrating an operation performed by a U2M conversion transfer engine 101 in a U2M conversion state 203;
FIG. 6 is a flowchart illustrating an operation performed by the U2M conversion transfer engine 101 in a transfer state 204.
FIG. 7 is a flowchart illustrating an operation performed by the U2M conversion transfer engine 101 in the forward unicast state 205.
FIG. 8 is a flowchart illustrating an operation performed by the U2M conversion transfer engine 101 in the upper layer state 206.
FIG. 9 is a state transition diagram of the illustrated query and state update engine 102;
FIG. 10 is a flowchart for explaining an inquiry about an initialization state 301 and an operation performed by the state update engine 102;
FIG. 11 is a flowchart illustrating an inquiry about an update status stable state 303 and an operation performed by the state update engine 102;
FIG. 12 is a flowchart illustrating the operation of an inquiry of an inquiry state 304 and the operation of the state update engine 102;
FIG. 13 is a state transition diagram of the sub IGMP processing engine 103.
FIG. 14 is a flowchart illustrating an operation performed by the sub IGMP processing engine 103 in the state of the initialization engine 401.
FIG. 15 is a flowchart illustrating an operation performed by a sub IGMP processing engine 103 in an idle 402 state.
FIG. 16 is a flowchart illustrating an operation performed by the sub IGMP processing engine 103 in the combined report 403 state.
FIG. 17 is a flowchart illustrating an operation performed by a sub IGMP processing engine 103 in a leave report 404 state;
FIG. 18 is a flowchart illustrating an operation performed by the sub IGMP processing engine 103 in the unicast forward 405 state.
FIG. 19 is a flowchart illustrating an operation performed by the sub IGMP processing engine 103 in a state of a drop packet 406.
FIG. 20 is a flowchart illustrating an operation performed by a sub IGMP processing engine 103 in a state of a trigger inquiry engine 407;
FIG. 21 is an explanatory diagram showing a scenario of a case where a service is provided to a monitoring system using the streaming control device of the embodiment.
[Explanation of symbols]
101 U2M Conversion Transfer Engine
102 Query and Status Update Engine
103 Sub IGMP processing engine
104 transfer and receiver registration table

Claims

受信機からの要求に応じてマルチキャストでコンテンツを配信するストリーミング制御装置であって、
データ配信源から入力されたユニキャストトラヒックをマルチキャストトラヒックに変換するトラヒック変換手段と、
前記コンテンツの転送状況および前記コンテンツの配信を要求した前記受信機を記憶したマルチキャストトラヒック転送情報データベースに記憶されている情報と、所定の規則とに基づいて、前記トラヒック変換手段によって変換されたマルチキャストトラヒックを配信するトラヒック配信手段と、
を備えたことを特徴とするストリーミング制御装置。A streaming control device that distributes content by multicast in response to a request from a receiver,
Traffic conversion means for converting unicast traffic input from a data distribution source into multicast traffic,
The multicast traffic converted by the traffic converting means based on information stored in a multicast traffic transfer information database storing the transfer status of the content and the receiver requesting the delivery of the content, and a predetermined rule. Traffic distribution means for distributing
A streaming control device comprising:

所定の間隔でＩＧＭＰメッセージを作成し送信するメッセージ送信手段と、
前記メッセージ送信手段から送信された前記ＩＧＭＰメッセージと前記ＩＧＭＰメッセージの送信に対する応答に基づいて、マルチキャストトラヒック転送用の情報を更新する情報更新手段と、
前記ＩＧＭＰメッセージを送信する間隔を設定する間隔設定手段と、
を備えたことを特徴とする請求項１記載のストリーミング制御装置。Message sending means for creating and sending IGMP messages at predetermined intervals;
Information updating means for updating information for multicast traffic transfer based on the IGMP message transmitted from the message transmitting means and a response to the transmission of the IGMP message;
Interval setting means for setting an interval for transmitting the IGMP message,
The streaming control device according to claim 1, further comprising:

前記トラヒック変換手段は、
前記データ配信源から入力されたユニキャストトラヒックのデータパケットを選択するデータパケット選択手段と、
前記データパケット選択手段によって選択されたユニキャストトラヒックのデータパケットをマルチキャストトラヒックのデータパケットに変換するデータ変換手段と、
を有することを特徴とする請求項１記載のストリーミング制御装置。The traffic conversion means,
Data packet selection means for selecting a data packet of unicast traffic input from the data distribution source,
Data conversion means for converting the data packet of the unicast traffic selected by the data packet selection means to a data packet of the multicast traffic,
The streaming control device according to claim 1, further comprising:

前記マルチキャストポートで前記ＩＧＭＰメッセージを受信する際に、
前記ＩＧＭＰメッセージがインターネットグループ用の「Ｍｅｍｂｅｒｓｈｉｐ＿Ｒｅｐｏｒｔメッセージ」であれば、そのメッセージに対応するマルチキャストグループ用のトラヒックの転送を可能にして、対応するマルチキャストグループ用のデータベースに受信機を登録し、
前記ＩＧＭＰメッセージが「Ｌｅａｖｅ＿Ｇｒｏｕｐメッセージ」であれば、対応するマルチキャストグループ用のデータベースに登録されている受信機を除去し、その受信機がグループに連動しない場合に対応するマルチキャストグループ用のトラヒックの転送を無効にするようにして前記マルチキャストトラヒック転送情報データベースを更新するデータベース更新手段を備えたことを特徴とする請求項２記載のストリーミング制御装置。When receiving the IGMP message on the multicast port,
If the IGMP message is a “Membership_Report message” for an Internet group, the transfer of the traffic for the multicast group corresponding to the message is enabled, and the receiver is registered in the database for the corresponding multicast group.
If the IGMP message is a “Leave_Group message”, the receiver registered in the database for the corresponding multicast group is removed, and when the receiver is not linked to the group, the transfer of the traffic for the corresponding multicast group is performed. 3. The streaming control device according to claim 2, further comprising a database updating unit for updating the multicast traffic transfer information database so as to invalidate the multicast traffic transfer information database.

前記トラヒック配信手段および前記データベース更新手段が、前記マルチキャストトラヒック転送情報データベースを共有することを特徴とする請求項４記載のストリーミング制御装置。5. The streaming control device according to claim 4, wherein the traffic distribution unit and the database updating unit share the multicast traffic transfer information database.

マルチキャストトラヒックのデータパケットを出力する複数の出力リンクと、
ユニキャストトラヒックのデータパケットを入力する複数の入力リンクと、
を備えたことを特徴とする請求項１ないし５のいずれかに記載のストリーミング制御装置。A plurality of output links for outputting multicast traffic data packets,
Multiple input links for inputting unicast traffic data packets,
The streaming control device according to any one of claims 1 to 5, further comprising:

前記入力リンクが前記出力リンクの機能を備え、
前記出力リンクが前記入力リンクの機能を備え、
前記入力リンクを複数のデータ配信源に接続し、前記出力リンクを複数の受信機に接続したことを特徴とする請求項６記載のストリーミング制御装置。The input link has the function of the output link,
The output link has the function of the input link,
7. The streaming control device according to claim 6, wherein the input link is connected to a plurality of data distribution sources, and the output link is connected to a plurality of receivers.

請求項１ないし７のいずれかに記載のストリーミング制御装置を備えたネットワークシステムであって、
前記受信機が任意クラスタの任意のデータ配信源からデータストリームを受信可能であり、
前記データ配信源に接続されたスイッチに前記ストリーミング制御装置が接続され、
前記スイッチ経由で前記受信機に前記ストリーミング制御装置の各出力を接続することにより、前記データ配信源と前記受信機の複数のクラスタを支援するようネットワークが構成されたことを特徴とするネットワークシステム。A network system comprising the streaming control device according to any one of claims 1 to 7,
The receiver can receive a data stream from any data distribution source in any cluster;
The streaming control device is connected to a switch connected to the data distribution source,
A network system comprising: a network configured to support the data distribution source and a plurality of clusters of the receiver by connecting each output of the streaming control device to the receiver via the switch.

前記ストリーミング制御装置は、高周波で前記データ配信源間を切り換えるために用いられることを特徴とする請求項８記載のネットワークシステム。9. The network system according to claim 8, wherein the streaming control device is used to switch between the data distribution sources at a high frequency.