JP3774351B2 - パケット変換装置およびパケット変換方法 - Google Patents
パケット変換装置およびパケット変換方法 Download PDFInfo
- Publication number
- JP3774351B2 JP3774351B2 JP2000039076A JP2000039076A JP3774351B2 JP 3774351 B2 JP3774351 B2 JP 3774351B2 JP 2000039076 A JP2000039076 A JP 2000039076A JP 2000039076 A JP2000039076 A JP 2000039076A JP 3774351 B2 JP3774351 B2 JP 3774351B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- client
- multicast data
- server
- data transfer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はネットワークを用いた通信方式に係り、更に詳しくは送信側からメッセージを同時に複数の受信側に中継する同報通信、すなわちマルチキャスト通信において、ネットワークがマルチキャスト通信をサポートしていない場合に、マルチキャストデータ転送パケットをネットワーク内では１対１の通信に用いられるユニキャストデータパケットに変換して通信を行うための、パケット変換装置、およびパケット変換方法に関する。
【０００２】
【従来の技術】
最近例えばインターネット上でもライブの中継や、会議型のマルチキャスト通信サービスへの時期が高まっている。このようなマルチキャスト通信方式の第１の従来技術を図１９を用いて説明する。この第１の従来技術では、例えばＩＰ（インターネットプロトコル）パケットをインターネットに入力させる際に、インターネット上でマルチキャストデータパケットとして多くのクライアントに転送するために、パケットの先頭にＩＰヘッダを付加する方法がとられていた。
【０００３】
例えばライブの中継のような場合には、それを配信するサーバ５０から常にネットワークに対してマルチキャストデータパケットが送信され、そのライブの中継を要求する複数のクライアントは、それぞれサーバ５０から常に送り出されているマルチキャストデータパケットの中継をネットワーク側に要求し、マルチキャストデータパケットの中継が行われることになる。このような場合、サーバ５０から送り出されているマルチキャストデータパケットは、ゲートウェイ５１を介してインターネット内でのパケット転送を制御するルータ５２に入力される。この時サーバ５０から送り出されるパケットにはＩＰヘッダＡと、ＵＤＰ（ユーザデータグラムプロトコル）ヘッダＢとが格納されているが、ゲートウェイ５１からルータ５２に入力される時点で、パケットの先頭に更に複数のクライアントにそのパケットを配信するためのＩＰヘッダＸが付加されて、ネットワーク内に入力される。
【０００４】
図２０はマルチキャスト通信方式の第２従来技術の説明図である。この技術は次の文献に述べられている。
特開平１０−２４２９６２：インターネット上のマルチキャストゲートウェイ通信方法およびシステム
図２０においてはネットワークはすでにマルチキャスト通信に対応しているものとし、マルチキャスト通信をサポートしていないのは、マルチキャストデータの受信を要求するクライアント側の端末であるとする。そこでサーバ５５から送り出され、ＩＰマルチキャスト対応ネットワーク５６上で転送された、例えばＩＰマルチキャストデータパケットは、クライアント側のゲートウェイ５７によって必要な数だけのコピーが行われ、一般に複数台のクライアント５８側の端末にＩＰユニキャストデータパケットとして中継される。
【０００５】
【発明が解決しようとする課題】
図１９で説明した第１の従来技術としてのＩＰヘッダ付加方式では、ネットワーク上で転送されるパケットにはＩＰヘッダを付加しなければならないために、例えばローカルエリアネットワーク（ＬＡＮ）としてのイーサネットに属するサーバ５０から、マルチキャストデータとしてイーサネットの最大パケット長に相当するデータを送ろうとしても、ゲートウェイ５７においてその一部を削除しなければならず、イーサネットの最大パケット長に対応するデータを送ることができないという問題点があった。またネットワーク上でトラブルが発生した場合に、パケットの形式が通常のものと異なるため、トラブルの解析が困難であるという問題点もあった。
【０００６】
図２０で説明した第２の従来技術では、マルチキャスト通信をサポートしていない部分は受信側の端末に限定されている。しかながら実際にはマルチキャスト通信をサポートするためのソフトウェアはすでに市場に流通しており、端末がサポートすることは容易である。問題になるのはルータなど、ネットワークが未対応の場合である。インターネットは基本的にはマルチキャスト通信をサポートしているとはいえるが、マルチキャスト通信用のＩＰアドレスの数は限定されており、例えば企業の本社と工場とのそれぞれのＬＡＮをインターネットで結ぶ仮想公衆網（ＶＰＮ）において、マルチキャストデータ通信を大規模に実行するような状況には対応できないという問題点があった。
【０００７】
本発明の課題は、上述の問題点に鑑み、インターネット上ではマルチキャストデータパケットをユニキャストデータパケットとして転送するために、ネットワークの入口／出口でパケットヘッダの変換を行うパケット変換装置、およびパケット変換方法を提供することである。
【０００８】
【課題を解決するための手段】
図１は本発明の原理構成ブロック図である。同図はネットワークの入口／出口に備えられ、パケットの変換を行うパケット変換装置の原理構成ブロック図である。
【０００９】
図１においてパケット変換装置１の内部に備えられるヘッダ変換手段２はマルチキャストデータ転送パケット、例えばＩＰマルチキャストデータパケットのヘッダを書き換えて、ユニキャストデータ転送パケット、例えばＩＰユニキャストデータパケットとして前記ネットワークに入力させる動作と、および／またはネットワークから受け取ったユニキャストデータ転送パケットのヘッダを書き換えてマルチキャストデータ転送パケットとして、例えばクライアントに出力するものである。
【００１０】
本発明の実施の形態においては、前記のネットワークはワイドエリアネットワーク、例えばインターネットであり、パケット変換装置はそのワイドエリアネットワークとローカルエリアネットワークとを接続するゲートウェイ装置に備えられ、ヘッダ変換手段２がパケットのＩＰヘッダ内のパケット宛先ＩＰアドレスと、送信元ＩＰアドレスとの書き換えを行うこともできる。
【００１１】
また発明の実施形態においては、ヘッダ変換装置はサーバ側ゲートウェイ装置とクライアント側ゲートウェイ装置とに、それぞれ備えられることもできる。こサーバ側ゲートウェイ装置はローカルエリアネットワークに属し、マルチキャストデータ転送パケットを配信するサーバが接続されたものであり、クライアント側ゲートウェイ装置は異なるローカルエリアネットワークに属し、マルチキャストデータ転送パケットの要求元としてのクライアントに接続されたものである。
【００１２】
この場合、クライアント側ゲートウェイ装置に備えられるパケット変換装置は、クライアントからのマルチキャストデータ受信要求を受けた時、その受信要求に対応する識別子を生成する手段を備えることもできる。
【００１３】
またクライアント側ゲートウェイ装置に備えられるパケット変換装置は、この識別子をマルチキャストデータそのもののＩＰアドレスに対応させて、記憶する手段を更に備え、サーバ側ゲートウェイ装置に備えられるパケット変換装置は、クライアント側から通知されたその識別子を、マルチキャストデータそのもののＩＰアドレスに対応させて記憶する手段を更に備えることもできる。
【００１４】
更に本発明の実施の形態においては、パケット変換装置はネットワーク内でのパケットの転送制御を実行するルータに備えられることもできる。
本発明のパケット変換方法は、ネットワークの入口／出口においてパケットの変換を行う方法であり、マルチキャストデータ転送パケットのヘッダを書き換えて、ユニキャストデータ転送パケットとしてネットワークに入力させ、ネットワークから受け取ったユニキャストデータ転送パケットのヘッダを書き換えて、マルチキャストデータ転送パケットとして出力するものである。
【００１５】
この場合、ネットワークはワイドエリアネットワークであり、パケットの変換はワイドエリアネットワークとローカルエリアネットワークとを接続するゲートウェイ装置によって実行されることもできる。
【００１６】
本発明のパケット変換装置において使用される記憶媒体は、ネットワークの入口／出口に備えられるパケット変換装置によって使用されるものであ、マルチキャストデータ転送パケットのヘッダを書き換えて、ユニキャストデータ転送パケットとしてネットワークに入力させるステップ、またはネットワークから受け取ったユニキャストデータ転送パケットのヘッダを書き換えて、マルチキャストデータ転送パケットとして出力するステップのいずれかをコンピュータに実行させるためのプログラムを格納したコンピュータ読み取り可能な可搬型記憶媒体である。
【００１７】
以上のように本発明によれば、マルチキャストデータ転送パケットを、ヘッダ変換を行うことによって、ネットワーク内ではユニキャストデータ転送パケットとして転送することにより、マルチキャスト通信に未対応のネットワークにおいてもマルチキャストデータの転送が可能となる。
【００１８】
例えばインターネットを介して２つのローカルエリアネットワークが接続された仮想公衆網において、片方のローカルエリアネットワークに属するサーバから配信されているマルチキャストデータを、インターネットを介してもう一つのローカルエリアネットワークに属し、そのマルチキャストデータを要求したクライアントに対して確実に転送することが可能となる。
【００１９】
【発明の実施の形態】
以下本発明の実施の形態について図面を用いて詳細に説明する。図２は本発明のヘッダ変換方式が用いられるマルチキャストデータ通信システムの全体構成ブロック図である。同図において、サーバ１０からクライアント１４に対して、一般にクライアント１４からの要求によってマルチキャストデータが送信されるものとする。中間のネットワーク１２は例えばインターネットであり、マルチキャスト通信に未対応のネットワーク、または少なくともサーバ１０、あるいはクライアント１４から見てブラックボックスであり、ＩＰマルチキャスト通信に対応しているか否かが不明であり、マルチキャスト通信に未対応のネットワークとして考えた方が適切と考えられるネットワークである。
【００２０】
図２においてサーバ１０からのマルチキャストデータは、例えばパケットの形式で、サーバ側ゲートウェイ１１を介してＩＰマルチキャスト未対応ネットワーク１２に与えられ、そのネットワーク内でのルーティングによって、クライアント１４が接続されたクライアント側ゲートウェイ１３を介して、クライアント１４に転送される。
【００２１】
図３は図２におけるデータの流れの説明図である。図３においてサーバ１０から送出されたＩＰマルチキャストデータＭは、サーバ側のゲートウェイ１１に入力され、ここでＩＰデータが変換されることにより、ＩＰユニキャストデータＵとしてＩＰマルチキャスト未対応のＩＰネットワーク１２に入力される。
【００２２】
ＩＰネットワーク１２の内部には、複数のルータ１５ａ〜１５ｅがあり、入力されたＩＰユニキャストデータＵ、これらのルータのうち例えば１５ａ，１５ｂを介して、データ受信側のクライアント１４側のゲートウェイ１３に接続されているルータ１５ｃに転送される。
【００２３】
ルータ１５ｃからゲートウェイ１３に出力されるＩＰユニキャストデータＵは、クライアント側のゲートウェイ１３によってＩＰヘッダの変換が行われ、ＩＰマルチキャストデータＭとしてクライアント１４に与えられる。
【００２４】
図４はゲートウェイによるヘッダの書き換えの説明図である。同図においては、サーバ１０側のゲートウェイ１１によって行われるヘッダの変換について説明する。
【００２５】
サーバ１０は１つのローカルエリアネットワーク（ＬＡＮ）、例えばイーサネットに属するものとし、イーサネットのパケットをゲートウェイ１１に送るものとする。イーサネットにおける最大パケット長は、最後に付加されるＣＲＣデータを含めて１５１８バイトであり、マルチキャストデータとしての実データの前にヘッダが付加されており、そのヘッダ部には先頭にＭＡＣ（メディアアクセスコントロール）、次にインターネットプロトコル（ＩＰ）ヘッダＡ、その後にユーザデータグラムプロトコル（ＵＤＰ）ヘッダＢが格納されているものとする。なおＣＲＣ，ＭＡＣは図示されていない。
【００２６】
このマルチキャストデータパケットＭはゲートウェイ１１に入力され、ゲートウェイ１１によってＩＰヘッダとＵＤＰヘッダの書き換えが行われ、ＩＰヘッダは例えばＡからＣに、ＵＤＰヘッダはＢからＤに書き換えられる。そしてこの結果のパケットは、ＩＰユニキャストデータパケットとしてＩＰネットワーク内のルータ１５ａに入力される。
【００２７】
ここでゲートウェイ１１によるパケットの変換においては、一般にＩＰヘッダとＵＤＰヘッダの書き換えが行われるだけであり、実データのデータ長も、またパケット全体のパケット長、およびそのフォーマットには何ら変更が行われない。このため、イーサネットにおけるパケットの最大長に対応する最大データ長のデータを、そのままＩＰマルチキャストデータパケットとしてクライアント側に送ることができ、また例えばＩＰネットワーク上でトラブルが発生しても、パケット内のヘッダやデータなどの格納領域のフォーマットはそのままであり、トラブルの内容を容易に解析することができる。
【００２８】
図５はサーバからクライアントまでのマルチキャストデータ転送時におけるヘッダの変換、特にＩＰヘッダの変換の説明図である。同図においてＩＰアドレスはサーバ１０に対して１００、クライアント１４に対して２００、サーバ側の ゲートウェイ１１に対して３００、クライアント側のゲートウェイ１３に対して４００であり、ＩＰマルチキャストデータそのものに対するＩＰアドレスは０００であるとする。
【００２９】
サーバ１０から送り出されたマルチキャストデータパケットのＩＰヘッダには、宛先ＩＰアドレスとしてマルチキャストデータそのもののアドレス０００が、また送信元ＩＰアドレスとしてはサーバ１０のアドレスである１００が格納されて、ゲートウェイ１１に与えられる。なおここでは簡単のため、図４で説明したＵＤＰヘッダなどは省略されている。
【００３０】
ゲートウェイ１１ではＩＰヘッダの書き換えが行われる。すなわちマルチキャストデータパケットをユニキャストデータパケットに変換するために、ＩＰネットワーク上でそのパケットがユニキャストデータパケット、すなわち送信元と宛先とがそれぞれ単一であるような形式へのヘッダの変換が行われる。ここではゲートウェイ１１からゲートウェイ１３にデータパケットが転送されるように、宛歴ＩＰアドレスとして例えばゲートウェイ１３のアドレスである４００が、また送信元ＩＰアドレスとしてゲートウェイ１１のアドレス３００が格納されて、ＩＰネットワーク上のルータ１５ａに与えられる。
【００３１】
ＩＰネットワーク１２上では、図３で説明したように、クライアント側のゲートウェイ１３が接続されたルータ１５ｃから、ゲートウェイ１３に対してマルチキャストデータを格納するデータパケットがユニキャストデータパケットとして入力される。
【００３２】
このパケットはゲートウェイ１３によって再びＩＰヘッダの変換が行われ、クライアント１４に対してマルチキャストデータパケットとして送られる。すなわち宛先ＩＰアドレスはマルチキャストデータそのもののアドレスとしての０００に、送信元ＩＰアドレスはこのマルチキャストデータを配信しているサーバ１０のＩＰアドレス１００に変換されて、クライアント１４に与えられる。
【００３３】
図６はクライアントによるマルチキャストデータの要求から、実際にそのデータがクライアントに与えられるまでの、ネットワークシステム内の動作の概要説明図である。同図においてクライアント１４がマルチキャストデータを要求するフェーズをフェーズ１とし、実際にそのマルチキャストデータパケットが中継されてクライアント１４に与えられるフェーズをフェーズ５として、フェーズ１からフェーズ５までの間のシステム内の動作の概要について説明する。
【００３４】
まずフェーズ１において、クライアント１４からクライアント側ゲートウェイ１３に対して、マルチキャストデータの中継を要求するデータ要求パケットが送られる。ここでクライアント側ゲートウェイ１３は、自装置内に保持されている管理テーブル１７を参照し、後述するように要求されたマルチキャストデータに対応する識別子などが登録されているか否かを判定し、登録されていない場合には必要なデータの登録を行い、フェーズ２においてサーバ側ゲートウェイ１１に対してマルチキャストデータの送信を要求するパケットを送る。このパケットには、管理テーブル１７に格納されているマルチキャストデータに対応する識別子を含むマルチキャストデータ送信要求が実データとして格納されている。
【００３５】
サーバ側ゲートウェイ１１は、フェーズ３においてクライアント側ゲートウェイ１３との間で必要な情報交換を行う。この情報交換は、クライアント側ゲートウェイ１３が実際にマルチキャストデータを含むユニキャストデータパケットを受け取った時点で、このパケットを実際にマルチキャストデータ配信元としてのサーバ１０から送り出されたＩＰマルチキャストデータパケットに復元するために必要な情報を交換するものである。この情報交換にあたって、両方のゲートウェイ１１，１３は、必要なデータをそれぞれ管理テーブル１８，１７に登録する。情報交換終了後に、クライアント側ゲートウェイ１３はサーバ側ゲートウェイ１１に対して、マルチキャストデータが実データとして格納されたＩＰユニキャストデータパケットの送信を要求するために受信準備完了を通知する。
【００３６】
前述のようにサーバ１０からサーバ側ゲートウェイ１１に対しては、常にＩＰマルチキャストデータパケットが送り出されているため、サーバ側ゲートウェイ１１はフェーズ４において前述のようにＩＰヘッダ、およびＵＤＰヘッダの書き換えを行って、マルチキャストデータを含むパケットをＩＰユニキャストデータパケットとして、クライアント側ゲートウェイ１３に対して中継するトンネリング処理を実行する。
【００３７】
クライアント側ゲートウェイ１３は管理テーブル１７の内容を参照し、サーバ側ゲートウェイ１１から受信したＩＰユニキャストデータパケットのＩＰヘッダ、ＵＤＰヘッダの書き換えを行い、ＩＰマルチキャストデータパケットとしてクライアント１４に中継するトンネリングを行って、処理を終了する。
【００３８】
続いてクライアント側ゲートウェイとサーバ側ゲートウェイによって行われる処理、およびネットワークシステムにおける動作シーケンスについて説明する。図７はクライアント側ゲートウェイによって行われる処理のフローチャートである。同図において処理が開始されると、まずステップＳ１で受信したパケットが図６のフェーズ１でクライアント１４から送られたマルチキャストデータの要求パケットか否かが判定され、そのパケットである場合にはステップＳ２で要求されたマルチキャストデータそのもののアドレスが管理テーブル１７にすでに登録されているか否かが判定される。登録されていない場合には、ステップＳ３以降の処理に移行する。
【００３９】
ステップＳ３では、要求されたＩＰマルチキャストデータそのもののアドレスに対応するサーバ側ゲートウェイのＩＰアドレス、図５では３００が求められ、ステップＳ４で管理テーブル１７に登録されていないユニークな識別子が、そのマルチキャストデータのアドレスに対応して生成され、ステップＳ５で管理テーブル１７にマルチキャストデータアドレス、サーバ側ゲートウェイアドレス、および識別子が登録される。
【００４０】
その後ステップＳ６で、フェーズ２における処理として、クライアント側ゲートウェイ１３からサーバ側ゲートウェイ１１に対してマルチキャストデータの送信要求が送られる。ステップＳ７で、サーバ側ゲートウェイからの応答が受信されたか否かが判定され、まだ受信されていない場合にはステップＳ６以降の処理が繰り返される。なおステップＳ６で、サーバ側ゲートウェイ１１に送られる送信要求パケットの実データ内部には、要求されるマルチキャストデータのアドレスが０００であることと、それに対応する識別子の値が含まれる。
【００４１】
サーバからの応答が受信されたと判定されると、ステップＳ８でフェーズ３における情報交換の内容としての、管理テーブル１７への情報登録が行われる。ここで追加登録される情報は、要求されたマルチキャストデータを発信しているサーバ、図５ではサーバ１０のＩＰアドレス、および前述のＵＤＰヘッダの一部であるサーバ側１０のポート番号としての送信元ポート（ソケット）番号、およびマルチキャストデータの宛先のため基本的には特定する必要のない宛先ポート（ソケット）番号である。
【００４２】
管理テーブル１７への情報の追加登録が終了すると、ステップＳ９でサーバ側ゲートウェイ１１に対して、フェーズ３の最終段階としてマルチキャストデータの受信準備完了通知が送られ、その後ステップＳ１０でサーバ側ゲートウェイ１１からフェーズ４におけるデータ中継が行われたか、すなわちマルチキャストデータを受信したか否かが判定される。マルチキャストデータを受信していない場合には、サーバ側ゲートウェイ１１との間での処理に何らかのエラーが発生したものと考えれらるため、ステップＳ６以降の処理に戻り、例えば管理テーブルへの追加情報登録のやりなおしなどが実行される。
【００４３】
ステップＳ１０で、サーバ側ゲートウェイ１１からマルチキャストデータの中継が行われ、データを受信したと判定されると、ステップＳ１１でそのマルチキャストデータの中継が続けられているか否かが判定され、続けられている場合には処理を終了する。またステップＳ２でクライアント１４からフェーズ１で送られたマルチキャストデータ要求に対応するマルチキャストデータのアドレスが管理テーブル１７にすでに登録されていると判定された時には、ステップＳ３〜ステップＳ１０の処理はすでに実行されていることになるため、ステップＳ１１でマルチキャストデータの中継が行われているか否かが判定され、行われている場合には処理を終了する。行われていない場合にはマルチキャストデータの中継を待つために、ステップＳ２以降の処理が繰り返される。更にステップＳ１でクライアント１４から受信したパケットがマルチキャストデータの要求パケットでない場合には、本発明で実行すべき処理に対応しないことになるため、ステップＳ１２で受信したパケットが廃棄される。
【００４４】
図８はサーバ側ゲートウェイによって行われる処理のフローチャートである。同図において処理が開始されると、まずステップＳ２１で受信したパケットが前述のようにサーバ側から常時送られているＩＰマルチキャストデータパケットか否かが判定される。マルチキャストデータパケットである場合には、ステップＳ２２でそのマルチキャストデータのアドレスが図６の管理テーブル１８にすでに登録されているか否かが判定さ、登録されている場合にはそのまま処理を終了し、登録されていない場合には受信したパケットからＩＰマルチキャストデータのアドレス、ＩＰマルチキャストデータ送信サーバのＩＰアドレス、図５では１００、および宛先ポート（ソケット）番号、および送信元ポート（ソケット）番号が登録されて処理を終了する。
【００４５】
ステップＳ２１で受信したパケットがＩＰマルチキャストデータパケットでないと判定された場合には、ステップＳ２４で受信したパケットがクライアント側ゲートウェイからのマルチキャストデータの要求パケットか否かが判定され、そうでない場合には本発明の処理とは無関係であるため、そのまま処理を終了する。
【００４６】
マルチキャストデータ要求パケットである場合には、ステップＳ２５で要求されたＩＰマルチキャストデータのアドレスが管理テーブル１８にすでに登録されているか否かが判定され、登録されていない場合には本来サーバ側から常に送られているべきＩＰマルチキャストデータパケットが受信されていないことになるため、マルチキャストデータパケットの中継を行うことはできないことになり、そのまま処理を終了する。
【００４７】
ステップＳ２５でＩＰマルチキャストデータアドレスが管理テーブルにすでに登録されている場合には、ステップＳ２６でクライアント側ゲートウェイから要求されたＩＰマルチキャストデータのアドレスに対応して、データ要求パケットに含まれている送信元ＩＰアドレス、すなわちクライアント側ゲートウェイ１３のＩＰアドレス、図５では４００と、クライアント側ゲートウェイによって生成された識別子の値が管理テーブル１８に追加登録され、ステップＳ２９でクライアント側ゲートウェイ１３に対して、クライアント側ゲートウェイにおいてユニキャストデータパケットからマルチキャストデータパケットを復元するために必要な復元情報、例えば前述の宛先ポート（ソケット）番号、送信元ポート（ソケット）番号などがクライアント側ゲートウェイに送信され、ステップＳ２８でクライアント側ゲートウェイ１３から送られる準備完了通知を受信したか否かが判定され、まだ受信していない場合にはステップＳ２７以降の処理が繰り返される。
【００４８】
ステップＳ２８でクライアント側ゲートウェイからの準備完了通知を受信したと判定されると、フェーズ３の情報交換は終了し、ステップＳ２９で該当するマルチキャストデータパケットのＩＰヘッダ、ＵＤＰヘッダの変換を行い、ユニキャストデータパケットとして、クライアント側ゲートウェイにフェーズ４の処理として、パケットの中継を行う。
【００４９】
次に図７、図８のフローチャートを用いてクライアント側ゲートウェイとサーバ側ゲートウェイとによって実行される動作のシーケンスについて、図９〜図１２のシーケンスチャート、この動作において用いられるデータを示す図１３〜図１５、およびサーバ側ゲートウェイとクライアント側ゲートウェイに備えられる管理テーブルのフォーマットと格納データの例を示す図１６、図１７を用いて説明する。
【００５０】
クライアント、すなわちユーザによって要求されたマルチキャストデータは、最終的にクライアント側ゲートウェイ１３から前述のフェーズ５においてクライアント１４に中継されるが、この時クライアントは基本的には受信するパケットの宛先ＩＰアドレスが自ら要求したマルチキャストデータのそのもののアドレスに一致しているか否かだけをチェックしているため、フェーズ４からフェーズ５に移る時に、クライアント側ゲートウェイがサーバ側ゲートウェイから中継されてきたＩＰユニキャストデータパケットを、ＩＰマルチキャストデータパケットに復元する際に、データの送信元ＩＰアドレスをどのように設定しても、基本的には問題がないと考えられる。
【００５１】
このため本発明の実施形態としては、クライアント側ゲートウェイがクライアントに対して送り出すＩＰマルチキャストデータパケットのＩＰヘッダに格納されるデータの送信元ＩＰアドレスを設定する方法として、第１にＩＰマルチキャストデータ送信サーバのＩＰアドレスを用いる方法、第２にクライアント側ゲートウェイのＩＰアドレスを用いる方法、第３にマルチキャストデータそのもののＩＰアドレスを用いる方法の３つのいずれかを用いるものとし、それぞれの方法を以下［１］，［２］、および［３］として説明する。
【００５２】
図９はサーバ側ゲートウェイとクライアント側ゲートウェイとによって実行される動作シーケンスの前半部分を示すシーケンスチャートであり、前述の３つの方法すなわち［１］，［２］、および［３］に共通のシーケンスである。この図９においては前出のフェーズ１とフェーズ２との動作が行われる。
【００５３】
なお、図９においてサーバ側ゲートウェイ１１には、図６におけるサーバ１０に相当する第１のサーバ１０に加えて、一般的には異なるマルチキャストデータを配信している第２のサーバ３０も接続されているものとするが、ここでクライアント１４に最終的に中継されるマルチキャストデータパケットは第１のサーバ１０によって配信されているものとする。
【００５４】
図９において(1) で、第１のサーバ１０からマルチキャストデータの送信が開始される。ここでＩＰマルチキャストデータパケットには、そのＩＰヘッダに宛先ＩＰアドレスとしてマルチキャストデータそのもののアドレスとしての０００、送信元サーバのＩＰアドレスとしての１００が格納され、またＵＤＰヘッダの中に宛先ポート（ソケット）番号として１０１、送信元ポート（ソケット）番号として１０２が格納されているものとする。
【００５５】
第２のサーバ３０からは(2) で、異なるマルチキャストデータの送信が開始される。このデータパケットには、(1) におけると同様に宛先ＩＰアドレスとしてマルチキャストデータそのもののアドレスを示す０１０、送信元ＩＰアドレスとしてのサーバのアドレス１１０、宛先ポート（ソケット）番号として１１１、送信元ポート（ソケット）番号として１１２が格納されている。これらのＩＰアドレスおよびポート番号などは、図１３のＩＰヘッダ内、ＵＤＰヘッダ内、およびデータ部のデータの上２行の(1) と(2) に示されている。(1) 、すなわち第１のサーバ１０から送られるマルチキャストデータパケットには、クライアント側から要求されることになるマルチキャスト実データが含まれている。
【００５６】
これらのマルチキャストデータパケットを受け取ったサーバ側ゲートウェイ１１は(3) で管理テーブル１８への情報登録を行う。ここで登録される内容は、図１６のサーバ側ゲートウェイにおける管理テーブル内のマルチキャストアドレス、サーバＩＰアドレス、宛先ポート（ソケット）番号、および送信元ポート（ソケット）番号であり、これらのデータはそれぞれのマルチキャストアドレスに対応して、生成タイミング(3) でサーバ側ゲートウェイの管理テーブル１８に格納される。
【００５７】
クライアント１４は(4) で、ＩＰマルチキャストデータの送信開始を要求するデータ要求パケットをクライアント側ゲートウェイ１３に対して送る。この送信開始要求においては、図１３の(4) に示すようにＩＰヘッダ内の宛先ＩＰアドレスはマルチキャストデータのアドレスとしての、０００、送信元ＩＰアドレスはクライアント１４のＩＰアドレスとしての２００に設定され、データ部にはマルチキャストデータの要求命令であることが示される。このパケットにおけるＵＰＰヘッダ内の宛先ポート番号、送信元ポート番号については特定する必要がなく、例えば空白とされる。
【００５８】
クライアント側ゲートウェイ１３は(5) で、要求されたマルチキャストデータアドレスに対応するサーバ側ゲートウェイ１１のＩＰアドレスが３００であることを割り出し、(6) で要求されたマルチキャストデータのアドレスに対するユニークな識別子して４０１を生成し、(7) で図１６のクライアント側ゲートウェイ内の管理テーブルに示すように、マルチキャストデータアドレス、サーバ側ゲートウェイＩＰアドレス、および識別子の内容を登録する。
【００５９】
クライアント側ゲートウェイ１３は、テーブルへのデータ登録が終了すると、(8) で該当するサーバ側ゲートウェイ１１に対してＩＰマルチキャストデータパケットの送信を要求するパケットを送る。この要求パケットには、図１３の(8) で示されるように、ＩＰヘッダ内の宛先ＩＰアドレスとしてサーバ側ゲートウェイ１１のアドレス３００、送信元ＩＰアドレスとしてクライアント側ゲートウェイ１３のＩＰアドレス４００が設定され、ＵＤＰヘッダ内の送信元ポート（ソケット）番号としてはクライアント側ゲートウェイ１３のポートの番号としての４０１が設定される。宛先ポート（ソケット）番号はマルチキャストデータパケットの中継要求が入力されるポート番号として、例えば固定されているものであり、３０１であるとする。またこの要求パケットのデータ部には、要求されているＩＰマルチキャストデータのアドレスが０００であることが示される。
【００６０】
図９においてフェーズ１、およびフェーズ２の動作は終了し、前述の第１の方法としての［１］では、後半のフェーズ３〜フェーズ５の動作は図１０の動作シーケンスチャートによって示される。
【００６１】
図１０において、まずフェーズ３の処理として、サーバ側ゲートウェイ１１によって(9) で図１６に示されるように要求されたＩＰマルチキャストデータのアドレス０００に対応して、クライアント側からのデータ送信要求に含まれる送信元ＩＰアドレス、すなわち４００と、クライアント側ゲートウェイ１3 によって生成された識別子４０１がサーバ側ゲートウェイの管理テーブル１８に格納される。
【００６２】
その後サーバ側ゲートウェイ１１は、(10)でクライアント側ゲートウェイ１３に対して復元に必要な情報を送信する。この復元情報送信用パケットのＩＰヘッダ内のアドレス、およびＵＤＰヘッダ内のポート番号は、(8) でクライアント側ゲートウェイ１３から送られたマルチキャストデータ中継要求パケット内のアドレスを宛先と送信元で逆にしたものである。データ部には、復元に必要な情報としてのＩＰマルチキャストサーバのＩＰアドレスとしての１００、宛先ポート（ソケット）番号としての１０１、送信元ポート（ソケット）番号としての１０２が格納されている。
【００６３】
クライアント側ゲートウェイ１３は、受け取った復元情報の管理テーブル１７への登録を(11)で行う。ここでの登録内容は、図１６のクライアント側ゲートウェイの管理テーブルの生成タイミング(11)で示されるように、サーバＩＰアドレス１００、宛先と送信元のポート番号としての１０１および１０２である。
【００６４】
クライアント側ゲートウェイ１３は、管理テーブルへの復元情報の登録が終了すると、(12)でサーバ側ゲートウェイ１１に対して受信準備完了を通知するパケットを送る。このパケットのＩＰアドレス内の宛先、および送信元アドレス、ＵＤＰヘッダ内の宛先、および送信元ポート番号は(8) におけるデータ中継要求パケットにおけると同じであり、パケットのデータ部には受信準備完了通知が格納されている。これでフェーズ３の動作は終了する。
【００６５】
サーバ側ゲートウェイ１１は、クライアント側ゲートウェイ１３からの受信準備完了通知を受け取ると、マルチキャストデータの中継を開始する。第１のサーバ１０からのＩＰマルチキャストデータパケットの送信は、(1) で説明したのと同様に常にサーバ側ゲートウェイ１１に対して続けられているため、サーバ側ゲートウェイ１１は(13)で、第１のサーバ１０から受信したマルチキャストデータパケットのＩＰヘッダとＵＤＰヘッダの変換を行う。
【００６６】
そしてサーバ側ゲートウェイ１１は、(14)でＩＰデータヘッダとＵＤＰヘッダが変換されたデータパケットを、ネットワーク内でユニキャストデータパケットとして、クライアント側ゲートウェイ１３に中継する。ここで中継されるデータパケットのＩＰヘッダ、ＵＤＰヘッダに含まれるＩＰアドレスや、ポート（ソケット）番号などのデータは、図１３の(14)に示されるように、(10)における復元情報送信時のパケットヘッダの内容と同じである。
【００６７】
クライアント側ゲートウェイ１３はサーバ側から中継されたデータパケットを受け取ると、(15)で管理テーブル１７の内容を参照してＩＰヘッダとＵＤＰヘッダの変換を行って、マルチキャストデータパケットを復元し、(16)で復元されたマルチキャストデータパケットを中継、すなわち同報して、クライアント１４に与える。この復元されたマルチキャストデータパケットのＩＰヘッダ内の宛先ＩＰアドレスは、マルチキャストデータのアドレスとしての０００、送信元ＩＰアドレスはサーバ１０のアドレスとしての１００、宛先ポート（ソケット）番号はあまり意味はないが、ここでは１０１、送信元ポート（ソケット）番号は第１のサーバ１０のポート番号としての１０２である。
【００６８】
図１１は前述の第２の方法、すなわち［２］における動作シーケンスの後半を示し、図１４は［２］におけるパケットのＩＰヘッダ、ＵＤＰヘッダ、およびデータ部に格納されるデータの説明図であり、図１７は［２］における管理テーブルのフォーマットと格納されるデータの例である。
【００６９】
［２］においても、動作シーケンスの前半は図９におけると全く同じである。従って図１４において(1) 〜(8) に対応するデータは図１３におけると同じであり、また図１７でサーバ側ゲートウェイとクライアント側ゲートウェイとのそれぞれに備えられる管理テーブルの内容も、生成タイミング(3) と(7) に対しては同じである。
【００７０】
図１１の後半の動作シーケンスは図１０におけると同じ部分も多いので、図１０と異なる部分についてのみ説明する。［２］においては前述のように、最終的にクライアント側ゲートウェイ１３からクライアント１４に対してＩＰマルチキャストデータパケットが中継される時、送信元ＩＰアドレスとしてクライアント側ゲートウェイ１２のＩＰアドレス４００がＩＰヘッダに格納される点が［１］と異なっている。そこでクライアント側ゲートウェイ１３において、サーバ側ゲートウェイ１１から中継されてきたＩＰユニキャストデータパケットをマルチキャストデータパケットに変換する際の復元データとして、このマルチキャストデータの配信元である第１のサーバ１０のＩＰアドレス１００は不必要となる。
【００７１】
このため(10)でサーバ側ゲートウェイ１１からクライアント側ゲートウェイ１３に送られる復元情報は、図１０の(10)と異なってサーバのＩＰアドレス１００を含む必要がなくなる。このことは図１４において(10)におけるデータ部に、図１３の(10)と異なって、サーバのＩＰアドレス＝１００が含まれていないことに示されている。
【００７２】
従って図１１の(11)で、クライアント側ゲートウェイ１３の管理テーブル１７に格納される復元情報には第１のサーバ１０のＩＰアドレス１００は含まれず、このことから図１７のクライアント側ゲートウェイの管理テーブルには、図１６と異なって、サーバＩＰアドレスの格納領域は存在せず、生成タイミング(11)では宛先ポート（ソケット）番号、および送信元ポート（ソケット）番号のみが格納されることが示されている。
【００７３】
そして図１１では、(16)でクライアント側ゲートウェイ１３からクライアント１４に対して中継されるＩＰマルチキャストデータパケットのＩＰヘッダに含まれる送信元ＩＰアドレスが図１０の(16)における１００、すなわち第１のサーバ１０のＩＰアドレスではなく、４００、すなわちクライアント側ゲートウェイ１３のＩＰアドレスである点が異なっており、このことは図１４の(16)における送信元ＩＰアドレスが４００であり、図１３の(16)における送信元ＩＰアドレスが１００であるのと異なる点に示されている。
【００７４】
図１２は前述の［３］における後半の動作シーケンスチャートであり、図１５は［３］においてＩＰヘッダ、ＵＤＰヘッダ、およびデータ部に格納されるデータを示す。［３］においても、動作シーケンスの前半は図９と同じであり、従って図１５においても(1) 〜(8) に対応するデータは、図１３および図１４と同じである。なお［３］におけるサーバ側ゲートウェイとクライアント側ゲートウェイに備えられる管理テーブルのフォーマットとその格納データは図１６と全く同じであるため、その説明を省略する。
【００７５】
図１２において、(15)までの動作は［１］に対する図１０におけると同じであり、従って図１５における(14)までのデータは、図１３におけると同じである。［１］におけると異なる動作は、(16)におけるクライアント側ゲートウェイ１３からクライアント１４に対して最終的にマルチキャストデータパケットを中継する時の動作である。［３］においては、この時ＩＰヘッダ内の送信元ＩＰアドレスとしてクライアント１４が要求したマルチキャストデータそのもののアドレス０００が使われる。これが図１０において、送信元ＩＰアドレスとして第１のサーバ１０のＩＰアドレス１００が使われる点と異なる点である。この相違に対応して、図１５でも(16)における送信元ＩＰアドレスは０００となっている。
【００７６】
最後に本発明におけるプログラムのコンピュータへのローディングについて図１８を用いて説明する。本発明におけるヘッダの変換は、例えばサーバが所属するローカルエリアネットワークとインターネットとを接続するゲートウェイ装置、およびインターネットとクライアントの属するＬＡＮとを接続するゲートウェイ装置によって実行されるが、これらのゲートウェイ装置はコンピュータをその基本要素として構成することが可能である。
【００７７】
そこで本発明の請求項１０、図７、図８などのプログラムは、コンピュータ４１のメモリ４５に格納され、本体４４によってそのプログラムが実行されることによって、ヘッダ変換が行われる。
【００７８】
このプログラムは、例えば可搬型記憶媒体４２に記録され、その記憶媒体４２をコンピュータ４１にロードすることによって、またはプログラム提供者側からネットワーク回線４３を介して転送され、コンピュータ４１にロードされることによって実行されることもできる。
【００７９】
コンピュータ４１のメモリ４５としては、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、またはハードディスクなどを使用することができ、また可搬型記憶媒体４２としてはメモリカード、フロッピーディスク、ＣＤ−ＲＯＭ、光ディスク、光磁気ディスクなど、任意のコンピュータ読み取り可能な記憶媒体を使用することができる。
【００８０】
以上の説明においては、主として１つのサーバから１つのクライアントに対して、ＩＰマルチキャストデータパケットをインターネットを介して配信する場合を対象として本発明の内容を説明したが、本発明の対象はこれに限定されるものでないことは当然である。例えばインターネットの両側に１つの企業の工場や営業所などに対応する２つのＬＡＮが存在し、営業所と工場の間で例えばテレビ会議を行う場合に相互にマルチキャストデータを送受信するような形式も当然可能である。この場合、本発明のヘッダ変換装置はゲートウェイ装置に備えられるだけとは限定されず、例えばＩＰネットワークのルータに備えられることも当然可能である。
【００８１】
【発明の効果】
以上詳細に説明したように、本発明によればマルチキャストデータパケットをヘッダ変換によってユニキャストデータパケットに変換し、マルチキャストデータ通信をサポートしていないネットワーク、あるいはマルチキャストデータ通信をサポートしているかいないかが不明のネットワークに対して入力させ、ネットワークの出口で再びマルチキャストデータパケットに変換することによって、例えば仮想公衆網（ＶＰＮ）を構成する２つのローカルエリアネットワークの間でマルチキャストデータ通信を実行することが可能になり、マルチキャストデータ通信の普及に寄与するところが大きい。
【図面の簡単な説明】
【図１】本発明の原理構成ブロック図である。
【図２】本発明のヘッダ変換方式が用いられるマルチキャストデータ通信システムの全体構成を示すブロック図である。
【図３】図２のマルチキャストデータ通信システムにおけるデータの流れを説明する図である。
【図４】ゲートウェイによるヘッダの書き換えを説明する図である。
【図５】マルチキャストデータ転送時におけるＩＰヘッダの変換を説明する図である。
【図６】ネットワークシステム内の動作の概要を説明する図である。
【図７】クライアント側ゲートウェイによる処理のフローチャートである。
【図８】サーバ側ゲートウェイによる処理のフローチャートである。
【図９】第１、第２、第３の方法において２つのゲートウェイによって実行される動作の前半部分を示すシーケンスチャートである。
【図１０】第１の方法における動作の後半部分を示すシーケンスチャートである。
【図１１】第２の方法における動作の後半部分を示すシーケンスチャートである。
【図１２】第３の方法における動作の後半部分を示すシーケンスチャートである。
【図１３】第１の方法において用いられるデータの例を示す図である。
【図１４】第２の方法において用いられるデータの例を示す図である。
【図１５】第３の方法において用いられるデータの例を示す図である。
【図１６】第１の方法における２つのゲートウェイの管理テーブルの例を示す図である。
【図１７】第２の方法における２つのゲートウェイの管理テーブルの例を示す図である。
【図１８】本発明におけるプログラムのコンピュータへのローディングを説明する図である。
【図１９】マルチキャストデータ通信の従来技術の第１の例を示す図である。
【図２０】マルチキャストデータ通信の従来技術の第２の例を示す図である。
【符号の説明】
１ パケット変換装置
２ ヘッダ変換手段
１０ サーバ
１１ サーバ側ゲートウェイ
１２ ＩＰネットワーク
１３ クライアント側ゲートウェイ
１４ クライアント
１５ａ〜１５ｅ ルータ
１７，１８ 管理テーブル
【発明の属する技術分野】
本発明はネットワークを用いた通信方式に係り、更に詳しくは送信側からメッセージを同時に複数の受信側に中継する同報通信、すなわちマルチキャスト通信において、ネットワークがマルチキャスト通信をサポートしていない場合に、マルチキャストデータ転送パケットをネットワーク内では１対１の通信に用いられるユニキャストデータパケットに変換して通信を行うための、パケット変換装置、およびパケット変換方法に関する。
【０００２】
【従来の技術】
最近例えばインターネット上でもライブの中継や、会議型のマルチキャスト通信サービスへの時期が高まっている。このようなマルチキャスト通信方式の第１の従来技術を図１９を用いて説明する。この第１の従来技術では、例えばＩＰ（インターネットプロトコル）パケットをインターネットに入力させる際に、インターネット上でマルチキャストデータパケットとして多くのクライアントに転送するために、パケットの先頭にＩＰヘッダを付加する方法がとられていた。
【０００３】
例えばライブの中継のような場合には、それを配信するサーバ５０から常にネットワークに対してマルチキャストデータパケットが送信され、そのライブの中継を要求する複数のクライアントは、それぞれサーバ５０から常に送り出されているマルチキャストデータパケットの中継をネットワーク側に要求し、マルチキャストデータパケットの中継が行われることになる。このような場合、サーバ５０から送り出されているマルチキャストデータパケットは、ゲートウェイ５１を介してインターネット内でのパケット転送を制御するルータ５２に入力される。この時サーバ５０から送り出されるパケットにはＩＰヘッダＡと、ＵＤＰ（ユーザデータグラムプロトコル）ヘッダＢとが格納されているが、ゲートウェイ５１からルータ５２に入力される時点で、パケットの先頭に更に複数のクライアントにそのパケットを配信するためのＩＰヘッダＸが付加されて、ネットワーク内に入力される。
【０００４】
図２０はマルチキャスト通信方式の第２従来技術の説明図である。この技術は次の文献に述べられている。
特開平１０−２４２９６２：インターネット上のマルチキャストゲートウェイ通信方法およびシステム
図２０においてはネットワークはすでにマルチキャスト通信に対応しているものとし、マルチキャスト通信をサポートしていないのは、マルチキャストデータの受信を要求するクライアント側の端末であるとする。そこでサーバ５５から送り出され、ＩＰマルチキャスト対応ネットワーク５６上で転送された、例えばＩＰマルチキャストデータパケットは、クライアント側のゲートウェイ５７によって必要な数だけのコピーが行われ、一般に複数台のクライアント５８側の端末にＩＰユニキャストデータパケットとして中継される。
【０００５】
【発明が解決しようとする課題】
図１９で説明した第１の従来技術としてのＩＰヘッダ付加方式では、ネットワーク上で転送されるパケットにはＩＰヘッダを付加しなければならないために、例えばローカルエリアネットワーク（ＬＡＮ）としてのイーサネットに属するサーバ５０から、マルチキャストデータとしてイーサネットの最大パケット長に相当するデータを送ろうとしても、ゲートウェイ５７においてその一部を削除しなければならず、イーサネットの最大パケット長に対応するデータを送ることができないという問題点があった。またネットワーク上でトラブルが発生した場合に、パケットの形式が通常のものと異なるため、トラブルの解析が困難であるという問題点もあった。
【０００６】
図２０で説明した第２の従来技術では、マルチキャスト通信をサポートしていない部分は受信側の端末に限定されている。しかながら実際にはマルチキャスト通信をサポートするためのソフトウェアはすでに市場に流通しており、端末がサポートすることは容易である。問題になるのはルータなど、ネットワークが未対応の場合である。インターネットは基本的にはマルチキャスト通信をサポートしているとはいえるが、マルチキャスト通信用のＩＰアドレスの数は限定されており、例えば企業の本社と工場とのそれぞれのＬＡＮをインターネットで結ぶ仮想公衆網（ＶＰＮ）において、マルチキャストデータ通信を大規模に実行するような状況には対応できないという問題点があった。
【０００７】
本発明の課題は、上述の問題点に鑑み、インターネット上ではマルチキャストデータパケットをユニキャストデータパケットとして転送するために、ネットワークの入口／出口でパケットヘッダの変換を行うパケット変換装置、およびパケット変換方法を提供することである。
【０００８】
【課題を解決するための手段】
図１は本発明の原理構成ブロック図である。同図はネットワークの入口／出口に備えられ、パケットの変換を行うパケット変換装置の原理構成ブロック図である。
【０００９】
図１においてパケット変換装置１の内部に備えられるヘッダ変換手段２はマルチキャストデータ転送パケット、例えばＩＰマルチキャストデータパケットのヘッダを書き換えて、ユニキャストデータ転送パケット、例えばＩＰユニキャストデータパケットとして前記ネットワークに入力させる動作と、および／またはネットワークから受け取ったユニキャストデータ転送パケットのヘッダを書き換えてマルチキャストデータ転送パケットとして、例えばクライアントに出力するものである。
【００１０】
本発明の実施の形態においては、前記のネットワークはワイドエリアネットワーク、例えばインターネットであり、パケット変換装置はそのワイドエリアネットワークとローカルエリアネットワークとを接続するゲートウェイ装置に備えられ、ヘッダ変換手段２がパケットのＩＰヘッダ内のパケット宛先ＩＰアドレスと、送信元ＩＰアドレスとの書き換えを行うこともできる。
【００１１】
また発明の実施形態においては、ヘッダ変換装置はサーバ側ゲートウェイ装置とクライアント側ゲートウェイ装置とに、それぞれ備えられることもできる。こサーバ側ゲートウェイ装置はローカルエリアネットワークに属し、マルチキャストデータ転送パケットを配信するサーバが接続されたものであり、クライアント側ゲートウェイ装置は異なるローカルエリアネットワークに属し、マルチキャストデータ転送パケットの要求元としてのクライアントに接続されたものである。
【００１２】
この場合、クライアント側ゲートウェイ装置に備えられるパケット変換装置は、クライアントからのマルチキャストデータ受信要求を受けた時、その受信要求に対応する識別子を生成する手段を備えることもできる。
【００１３】
またクライアント側ゲートウェイ装置に備えられるパケット変換装置は、この識別子をマルチキャストデータそのもののＩＰアドレスに対応させて、記憶する手段を更に備え、サーバ側ゲートウェイ装置に備えられるパケット変換装置は、クライアント側から通知されたその識別子を、マルチキャストデータそのもののＩＰアドレスに対応させて記憶する手段を更に備えることもできる。
【００１４】
更に本発明の実施の形態においては、パケット変換装置はネットワーク内でのパケットの転送制御を実行するルータに備えられることもできる。
本発明のパケット変換方法は、ネットワークの入口／出口においてパケットの変換を行う方法であり、マルチキャストデータ転送パケットのヘッダを書き換えて、ユニキャストデータ転送パケットとしてネットワークに入力させ、ネットワークから受け取ったユニキャストデータ転送パケットのヘッダを書き換えて、マルチキャストデータ転送パケットとして出力するものである。
【００１５】
この場合、ネットワークはワイドエリアネットワークであり、パケットの変換はワイドエリアネットワークとローカルエリアネットワークとを接続するゲートウェイ装置によって実行されることもできる。
【００１６】
本発明のパケット変換装置において使用される記憶媒体は、ネットワークの入口／出口に備えられるパケット変換装置によって使用されるものであ、マルチキャストデータ転送パケットのヘッダを書き換えて、ユニキャストデータ転送パケットとしてネットワークに入力させるステップ、またはネットワークから受け取ったユニキャストデータ転送パケットのヘッダを書き換えて、マルチキャストデータ転送パケットとして出力するステップのいずれかをコンピュータに実行させるためのプログラムを格納したコンピュータ読み取り可能な可搬型記憶媒体である。
【００１７】
以上のように本発明によれば、マルチキャストデータ転送パケットを、ヘッダ変換を行うことによって、ネットワーク内ではユニキャストデータ転送パケットとして転送することにより、マルチキャスト通信に未対応のネットワークにおいてもマルチキャストデータの転送が可能となる。
【００１８】
例えばインターネットを介して２つのローカルエリアネットワークが接続された仮想公衆網において、片方のローカルエリアネットワークに属するサーバから配信されているマルチキャストデータを、インターネットを介してもう一つのローカルエリアネットワークに属し、そのマルチキャストデータを要求したクライアントに対して確実に転送することが可能となる。
【００１９】
【発明の実施の形態】
以下本発明の実施の形態について図面を用いて詳細に説明する。図２は本発明のヘッダ変換方式が用いられるマルチキャストデータ通信システムの全体構成ブロック図である。同図において、サーバ１０からクライアント１４に対して、一般にクライアント１４からの要求によってマルチキャストデータが送信されるものとする。中間のネットワーク１２は例えばインターネットであり、マルチキャスト通信に未対応のネットワーク、または少なくともサーバ１０、あるいはクライアント１４から見てブラックボックスであり、ＩＰマルチキャスト通信に対応しているか否かが不明であり、マルチキャスト通信に未対応のネットワークとして考えた方が適切と考えられるネットワークである。
【００２０】
図２においてサーバ１０からのマルチキャストデータは、例えばパケットの形式で、サーバ側ゲートウェイ１１を介してＩＰマルチキャスト未対応ネットワーク１２に与えられ、そのネットワーク内でのルーティングによって、クライアント１４が接続されたクライアント側ゲートウェイ１３を介して、クライアント１４に転送される。
【００２１】
図３は図２におけるデータの流れの説明図である。図３においてサーバ１０から送出されたＩＰマルチキャストデータＭは、サーバ側のゲートウェイ１１に入力され、ここでＩＰデータが変換されることにより、ＩＰユニキャストデータＵとしてＩＰマルチキャスト未対応のＩＰネットワーク１２に入力される。
【００２２】
ＩＰネットワーク１２の内部には、複数のルータ１５ａ〜１５ｅがあり、入力されたＩＰユニキャストデータＵ、これらのルータのうち例えば１５ａ，１５ｂを介して、データ受信側のクライアント１４側のゲートウェイ１３に接続されているルータ１５ｃに転送される。
【００２３】
ルータ１５ｃからゲートウェイ１３に出力されるＩＰユニキャストデータＵは、クライアント側のゲートウェイ１３によってＩＰヘッダの変換が行われ、ＩＰマルチキャストデータＭとしてクライアント１４に与えられる。
【００２４】
図４はゲートウェイによるヘッダの書き換えの説明図である。同図においては、サーバ１０側のゲートウェイ１１によって行われるヘッダの変換について説明する。
【００２５】
サーバ１０は１つのローカルエリアネットワーク（ＬＡＮ）、例えばイーサネットに属するものとし、イーサネットのパケットをゲートウェイ１１に送るものとする。イーサネットにおける最大パケット長は、最後に付加されるＣＲＣデータを含めて１５１８バイトであり、マルチキャストデータとしての実データの前にヘッダが付加されており、そのヘッダ部には先頭にＭＡＣ（メディアアクセスコントロール）、次にインターネットプロトコル（ＩＰ）ヘッダＡ、その後にユーザデータグラムプロトコル（ＵＤＰ）ヘッダＢが格納されているものとする。なおＣＲＣ，ＭＡＣは図示されていない。
【００２６】
このマルチキャストデータパケットＭはゲートウェイ１１に入力され、ゲートウェイ１１によってＩＰヘッダとＵＤＰヘッダの書き換えが行われ、ＩＰヘッダは例えばＡからＣに、ＵＤＰヘッダはＢからＤに書き換えられる。そしてこの結果のパケットは、ＩＰユニキャストデータパケットとしてＩＰネットワーク内のルータ１５ａに入力される。
【００２７】
ここでゲートウェイ１１によるパケットの変換においては、一般にＩＰヘッダとＵＤＰヘッダの書き換えが行われるだけであり、実データのデータ長も、またパケット全体のパケット長、およびそのフォーマットには何ら変更が行われない。このため、イーサネットにおけるパケットの最大長に対応する最大データ長のデータを、そのままＩＰマルチキャストデータパケットとしてクライアント側に送ることができ、また例えばＩＰネットワーク上でトラブルが発生しても、パケット内のヘッダやデータなどの格納領域のフォーマットはそのままであり、トラブルの内容を容易に解析することができる。
【００２８】
図５はサーバからクライアントまでのマルチキャストデータ転送時におけるヘッダの変換、特にＩＰヘッダの変換の説明図である。同図においてＩＰアドレスはサーバ１０に対して１００、クライアント１４に対して２００、サーバ側の ゲートウェイ１１に対して３００、クライアント側のゲートウェイ１３に対して４００であり、ＩＰマルチキャストデータそのものに対するＩＰアドレスは０００であるとする。
【００２９】
サーバ１０から送り出されたマルチキャストデータパケットのＩＰヘッダには、宛先ＩＰアドレスとしてマルチキャストデータそのもののアドレス０００が、また送信元ＩＰアドレスとしてはサーバ１０のアドレスである１００が格納されて、ゲートウェイ１１に与えられる。なおここでは簡単のため、図４で説明したＵＤＰヘッダなどは省略されている。
【００３０】
ゲートウェイ１１ではＩＰヘッダの書き換えが行われる。すなわちマルチキャストデータパケットをユニキャストデータパケットに変換するために、ＩＰネットワーク上でそのパケットがユニキャストデータパケット、すなわち送信元と宛先とがそれぞれ単一であるような形式へのヘッダの変換が行われる。ここではゲートウェイ１１からゲートウェイ１３にデータパケットが転送されるように、宛歴ＩＰアドレスとして例えばゲートウェイ１３のアドレスである４００が、また送信元ＩＰアドレスとしてゲートウェイ１１のアドレス３００が格納されて、ＩＰネットワーク上のルータ１５ａに与えられる。
【００３１】
ＩＰネットワーク１２上では、図３で説明したように、クライアント側のゲートウェイ１３が接続されたルータ１５ｃから、ゲートウェイ１３に対してマルチキャストデータを格納するデータパケットがユニキャストデータパケットとして入力される。
【００３２】
このパケットはゲートウェイ１３によって再びＩＰヘッダの変換が行われ、クライアント１４に対してマルチキャストデータパケットとして送られる。すなわち宛先ＩＰアドレスはマルチキャストデータそのもののアドレスとしての０００に、送信元ＩＰアドレスはこのマルチキャストデータを配信しているサーバ１０のＩＰアドレス１００に変換されて、クライアント１４に与えられる。
【００３３】
図６はクライアントによるマルチキャストデータの要求から、実際にそのデータがクライアントに与えられるまでの、ネットワークシステム内の動作の概要説明図である。同図においてクライアント１４がマルチキャストデータを要求するフェーズをフェーズ１とし、実際にそのマルチキャストデータパケットが中継されてクライアント１４に与えられるフェーズをフェーズ５として、フェーズ１からフェーズ５までの間のシステム内の動作の概要について説明する。
【００３４】
まずフェーズ１において、クライアント１４からクライアント側ゲートウェイ１３に対して、マルチキャストデータの中継を要求するデータ要求パケットが送られる。ここでクライアント側ゲートウェイ１３は、自装置内に保持されている管理テーブル１７を参照し、後述するように要求されたマルチキャストデータに対応する識別子などが登録されているか否かを判定し、登録されていない場合には必要なデータの登録を行い、フェーズ２においてサーバ側ゲートウェイ１１に対してマルチキャストデータの送信を要求するパケットを送る。このパケットには、管理テーブル１７に格納されているマルチキャストデータに対応する識別子を含むマルチキャストデータ送信要求が実データとして格納されている。
【００３５】
サーバ側ゲートウェイ１１は、フェーズ３においてクライアント側ゲートウェイ１３との間で必要な情報交換を行う。この情報交換は、クライアント側ゲートウェイ１３が実際にマルチキャストデータを含むユニキャストデータパケットを受け取った時点で、このパケットを実際にマルチキャストデータ配信元としてのサーバ１０から送り出されたＩＰマルチキャストデータパケットに復元するために必要な情報を交換するものである。この情報交換にあたって、両方のゲートウェイ１１，１３は、必要なデータをそれぞれ管理テーブル１８，１７に登録する。情報交換終了後に、クライアント側ゲートウェイ１３はサーバ側ゲートウェイ１１に対して、マルチキャストデータが実データとして格納されたＩＰユニキャストデータパケットの送信を要求するために受信準備完了を通知する。
【００３６】
前述のようにサーバ１０からサーバ側ゲートウェイ１１に対しては、常にＩＰマルチキャストデータパケットが送り出されているため、サーバ側ゲートウェイ１１はフェーズ４において前述のようにＩＰヘッダ、およびＵＤＰヘッダの書き換えを行って、マルチキャストデータを含むパケットをＩＰユニキャストデータパケットとして、クライアント側ゲートウェイ１３に対して中継するトンネリング処理を実行する。
【００３７】
クライアント側ゲートウェイ１３は管理テーブル１７の内容を参照し、サーバ側ゲートウェイ１１から受信したＩＰユニキャストデータパケットのＩＰヘッダ、ＵＤＰヘッダの書き換えを行い、ＩＰマルチキャストデータパケットとしてクライアント１４に中継するトンネリングを行って、処理を終了する。
【００３８】
続いてクライアント側ゲートウェイとサーバ側ゲートウェイによって行われる処理、およびネットワークシステムにおける動作シーケンスについて説明する。図７はクライアント側ゲートウェイによって行われる処理のフローチャートである。同図において処理が開始されると、まずステップＳ１で受信したパケットが図６のフェーズ１でクライアント１４から送られたマルチキャストデータの要求パケットか否かが判定され、そのパケットである場合にはステップＳ２で要求されたマルチキャストデータそのもののアドレスが管理テーブル１７にすでに登録されているか否かが判定される。登録されていない場合には、ステップＳ３以降の処理に移行する。
【００３９】
ステップＳ３では、要求されたＩＰマルチキャストデータそのもののアドレスに対応するサーバ側ゲートウェイのＩＰアドレス、図５では３００が求められ、ステップＳ４で管理テーブル１７に登録されていないユニークな識別子が、そのマルチキャストデータのアドレスに対応して生成され、ステップＳ５で管理テーブル１７にマルチキャストデータアドレス、サーバ側ゲートウェイアドレス、および識別子が登録される。
【００４０】
その後ステップＳ６で、フェーズ２における処理として、クライアント側ゲートウェイ１３からサーバ側ゲートウェイ１１に対してマルチキャストデータの送信要求が送られる。ステップＳ７で、サーバ側ゲートウェイからの応答が受信されたか否かが判定され、まだ受信されていない場合にはステップＳ６以降の処理が繰り返される。なおステップＳ６で、サーバ側ゲートウェイ１１に送られる送信要求パケットの実データ内部には、要求されるマルチキャストデータのアドレスが０００であることと、それに対応する識別子の値が含まれる。
【００４１】
サーバからの応答が受信されたと判定されると、ステップＳ８でフェーズ３における情報交換の内容としての、管理テーブル１７への情報登録が行われる。ここで追加登録される情報は、要求されたマルチキャストデータを発信しているサーバ、図５ではサーバ１０のＩＰアドレス、および前述のＵＤＰヘッダの一部であるサーバ側１０のポート番号としての送信元ポート（ソケット）番号、およびマルチキャストデータの宛先のため基本的には特定する必要のない宛先ポート（ソケット）番号である。
【００４２】
管理テーブル１７への情報の追加登録が終了すると、ステップＳ９でサーバ側ゲートウェイ１１に対して、フェーズ３の最終段階としてマルチキャストデータの受信準備完了通知が送られ、その後ステップＳ１０でサーバ側ゲートウェイ１１からフェーズ４におけるデータ中継が行われたか、すなわちマルチキャストデータを受信したか否かが判定される。マルチキャストデータを受信していない場合には、サーバ側ゲートウェイ１１との間での処理に何らかのエラーが発生したものと考えれらるため、ステップＳ６以降の処理に戻り、例えば管理テーブルへの追加情報登録のやりなおしなどが実行される。
【００４３】
ステップＳ１０で、サーバ側ゲートウェイ１１からマルチキャストデータの中継が行われ、データを受信したと判定されると、ステップＳ１１でそのマルチキャストデータの中継が続けられているか否かが判定され、続けられている場合には処理を終了する。またステップＳ２でクライアント１４からフェーズ１で送られたマルチキャストデータ要求に対応するマルチキャストデータのアドレスが管理テーブル１７にすでに登録されていると判定された時には、ステップＳ３〜ステップＳ１０の処理はすでに実行されていることになるため、ステップＳ１１でマルチキャストデータの中継が行われているか否かが判定され、行われている場合には処理を終了する。行われていない場合にはマルチキャストデータの中継を待つために、ステップＳ２以降の処理が繰り返される。更にステップＳ１でクライアント１４から受信したパケットがマルチキャストデータの要求パケットでない場合には、本発明で実行すべき処理に対応しないことになるため、ステップＳ１２で受信したパケットが廃棄される。
【００４４】
図８はサーバ側ゲートウェイによって行われる処理のフローチャートである。同図において処理が開始されると、まずステップＳ２１で受信したパケットが前述のようにサーバ側から常時送られているＩＰマルチキャストデータパケットか否かが判定される。マルチキャストデータパケットである場合には、ステップＳ２２でそのマルチキャストデータのアドレスが図６の管理テーブル１８にすでに登録されているか否かが判定さ、登録されている場合にはそのまま処理を終了し、登録されていない場合には受信したパケットからＩＰマルチキャストデータのアドレス、ＩＰマルチキャストデータ送信サーバのＩＰアドレス、図５では１００、および宛先ポート（ソケット）番号、および送信元ポート（ソケット）番号が登録されて処理を終了する。
【００４５】
ステップＳ２１で受信したパケットがＩＰマルチキャストデータパケットでないと判定された場合には、ステップＳ２４で受信したパケットがクライアント側ゲートウェイからのマルチキャストデータの要求パケットか否かが判定され、そうでない場合には本発明の処理とは無関係であるため、そのまま処理を終了する。
【００４６】
マルチキャストデータ要求パケットである場合には、ステップＳ２５で要求されたＩＰマルチキャストデータのアドレスが管理テーブル１８にすでに登録されているか否かが判定され、登録されていない場合には本来サーバ側から常に送られているべきＩＰマルチキャストデータパケットが受信されていないことになるため、マルチキャストデータパケットの中継を行うことはできないことになり、そのまま処理を終了する。
【００４７】
ステップＳ２５でＩＰマルチキャストデータアドレスが管理テーブルにすでに登録されている場合には、ステップＳ２６でクライアント側ゲートウェイから要求されたＩＰマルチキャストデータのアドレスに対応して、データ要求パケットに含まれている送信元ＩＰアドレス、すなわちクライアント側ゲートウェイ１３のＩＰアドレス、図５では４００と、クライアント側ゲートウェイによって生成された識別子の値が管理テーブル１８に追加登録され、ステップＳ２９でクライアント側ゲートウェイ１３に対して、クライアント側ゲートウェイにおいてユニキャストデータパケットからマルチキャストデータパケットを復元するために必要な復元情報、例えば前述の宛先ポート（ソケット）番号、送信元ポート（ソケット）番号などがクライアント側ゲートウェイに送信され、ステップＳ２８でクライアント側ゲートウェイ１３から送られる準備完了通知を受信したか否かが判定され、まだ受信していない場合にはステップＳ２７以降の処理が繰り返される。
【００４８】
ステップＳ２８でクライアント側ゲートウェイからの準備完了通知を受信したと判定されると、フェーズ３の情報交換は終了し、ステップＳ２９で該当するマルチキャストデータパケットのＩＰヘッダ、ＵＤＰヘッダの変換を行い、ユニキャストデータパケットとして、クライアント側ゲートウェイにフェーズ４の処理として、パケットの中継を行う。
【００４９】
次に図７、図８のフローチャートを用いてクライアント側ゲートウェイとサーバ側ゲートウェイとによって実行される動作のシーケンスについて、図９〜図１２のシーケンスチャート、この動作において用いられるデータを示す図１３〜図１５、およびサーバ側ゲートウェイとクライアント側ゲートウェイに備えられる管理テーブルのフォーマットと格納データの例を示す図１６、図１７を用いて説明する。
【００５０】
クライアント、すなわちユーザによって要求されたマルチキャストデータは、最終的にクライアント側ゲートウェイ１３から前述のフェーズ５においてクライアント１４に中継されるが、この時クライアントは基本的には受信するパケットの宛先ＩＰアドレスが自ら要求したマルチキャストデータのそのもののアドレスに一致しているか否かだけをチェックしているため、フェーズ４からフェーズ５に移る時に、クライアント側ゲートウェイがサーバ側ゲートウェイから中継されてきたＩＰユニキャストデータパケットを、ＩＰマルチキャストデータパケットに復元する際に、データの送信元ＩＰアドレスをどのように設定しても、基本的には問題がないと考えられる。
【００５１】
このため本発明の実施形態としては、クライアント側ゲートウェイがクライアントに対して送り出すＩＰマルチキャストデータパケットのＩＰヘッダに格納されるデータの送信元ＩＰアドレスを設定する方法として、第１にＩＰマルチキャストデータ送信サーバのＩＰアドレスを用いる方法、第２にクライアント側ゲートウェイのＩＰアドレスを用いる方法、第３にマルチキャストデータそのもののＩＰアドレスを用いる方法の３つのいずれかを用いるものとし、それぞれの方法を以下［１］，［２］、および［３］として説明する。
【００５２】
図９はサーバ側ゲートウェイとクライアント側ゲートウェイとによって実行される動作シーケンスの前半部分を示すシーケンスチャートであり、前述の３つの方法すなわち［１］，［２］、および［３］に共通のシーケンスである。この図９においては前出のフェーズ１とフェーズ２との動作が行われる。
【００５３】
なお、図９においてサーバ側ゲートウェイ１１には、図６におけるサーバ１０に相当する第１のサーバ１０に加えて、一般的には異なるマルチキャストデータを配信している第２のサーバ３０も接続されているものとするが、ここでクライアント１４に最終的に中継されるマルチキャストデータパケットは第１のサーバ１０によって配信されているものとする。
【００５４】
図９において(1) で、第１のサーバ１０からマルチキャストデータの送信が開始される。ここでＩＰマルチキャストデータパケットには、そのＩＰヘッダに宛先ＩＰアドレスとしてマルチキャストデータそのもののアドレスとしての０００、送信元サーバのＩＰアドレスとしての１００が格納され、またＵＤＰヘッダの中に宛先ポート（ソケット）番号として１０１、送信元ポート（ソケット）番号として１０２が格納されているものとする。
【００５５】
第２のサーバ３０からは(2) で、異なるマルチキャストデータの送信が開始される。このデータパケットには、(1) におけると同様に宛先ＩＰアドレスとしてマルチキャストデータそのもののアドレスを示す０１０、送信元ＩＰアドレスとしてのサーバのアドレス１１０、宛先ポート（ソケット）番号として１１１、送信元ポート（ソケット）番号として１１２が格納されている。これらのＩＰアドレスおよびポート番号などは、図１３のＩＰヘッダ内、ＵＤＰヘッダ内、およびデータ部のデータの上２行の(1) と(2) に示されている。(1) 、すなわち第１のサーバ１０から送られるマルチキャストデータパケットには、クライアント側から要求されることになるマルチキャスト実データが含まれている。
【００５６】
これらのマルチキャストデータパケットを受け取ったサーバ側ゲートウェイ１１は(3) で管理テーブル１８への情報登録を行う。ここで登録される内容は、図１６のサーバ側ゲートウェイにおける管理テーブル内のマルチキャストアドレス、サーバＩＰアドレス、宛先ポート（ソケット）番号、および送信元ポート（ソケット）番号であり、これらのデータはそれぞれのマルチキャストアドレスに対応して、生成タイミング(3) でサーバ側ゲートウェイの管理テーブル１８に格納される。
【００５７】
クライアント１４は(4) で、ＩＰマルチキャストデータの送信開始を要求するデータ要求パケットをクライアント側ゲートウェイ１３に対して送る。この送信開始要求においては、図１３の(4) に示すようにＩＰヘッダ内の宛先ＩＰアドレスはマルチキャストデータのアドレスとしての、０００、送信元ＩＰアドレスはクライアント１４のＩＰアドレスとしての２００に設定され、データ部にはマルチキャストデータの要求命令であることが示される。このパケットにおけるＵＰＰヘッダ内の宛先ポート番号、送信元ポート番号については特定する必要がなく、例えば空白とされる。
【００５８】
クライアント側ゲートウェイ１３は(5) で、要求されたマルチキャストデータアドレスに対応するサーバ側ゲートウェイ１１のＩＰアドレスが３００であることを割り出し、(6) で要求されたマルチキャストデータのアドレスに対するユニークな識別子して４０１を生成し、(7) で図１６のクライアント側ゲートウェイ内の管理テーブルに示すように、マルチキャストデータアドレス、サーバ側ゲートウェイＩＰアドレス、および識別子の内容を登録する。
【００５９】
クライアント側ゲートウェイ１３は、テーブルへのデータ登録が終了すると、(8) で該当するサーバ側ゲートウェイ１１に対してＩＰマルチキャストデータパケットの送信を要求するパケットを送る。この要求パケットには、図１３の(8) で示されるように、ＩＰヘッダ内の宛先ＩＰアドレスとしてサーバ側ゲートウェイ１１のアドレス３００、送信元ＩＰアドレスとしてクライアント側ゲートウェイ１３のＩＰアドレス４００が設定され、ＵＤＰヘッダ内の送信元ポート（ソケット）番号としてはクライアント側ゲートウェイ１３のポートの番号としての４０１が設定される。宛先ポート（ソケット）番号はマルチキャストデータパケットの中継要求が入力されるポート番号として、例えば固定されているものであり、３０１であるとする。またこの要求パケットのデータ部には、要求されているＩＰマルチキャストデータのアドレスが０００であることが示される。
【００６０】
図９においてフェーズ１、およびフェーズ２の動作は終了し、前述の第１の方法としての［１］では、後半のフェーズ３〜フェーズ５の動作は図１０の動作シーケンスチャートによって示される。
【００６１】
図１０において、まずフェーズ３の処理として、サーバ側ゲートウェイ１１によって(9) で図１６に示されるように要求されたＩＰマルチキャストデータのアドレス０００に対応して、クライアント側からのデータ送信要求に含まれる送信元ＩＰアドレス、すなわち４００と、クライアント側ゲートウェイ１3 によって生成された識別子４０１がサーバ側ゲートウェイの管理テーブル１８に格納される。
【００６２】
その後サーバ側ゲートウェイ１１は、(10)でクライアント側ゲートウェイ１３に対して復元に必要な情報を送信する。この復元情報送信用パケットのＩＰヘッダ内のアドレス、およびＵＤＰヘッダ内のポート番号は、(8) でクライアント側ゲートウェイ１３から送られたマルチキャストデータ中継要求パケット内のアドレスを宛先と送信元で逆にしたものである。データ部には、復元に必要な情報としてのＩＰマルチキャストサーバのＩＰアドレスとしての１００、宛先ポート（ソケット）番号としての１０１、送信元ポート（ソケット）番号としての１０２が格納されている。
【００６３】
クライアント側ゲートウェイ１３は、受け取った復元情報の管理テーブル１７への登録を(11)で行う。ここでの登録内容は、図１６のクライアント側ゲートウェイの管理テーブルの生成タイミング(11)で示されるように、サーバＩＰアドレス１００、宛先と送信元のポート番号としての１０１および１０２である。
【００６４】
クライアント側ゲートウェイ１３は、管理テーブルへの復元情報の登録が終了すると、(12)でサーバ側ゲートウェイ１１に対して受信準備完了を通知するパケットを送る。このパケットのＩＰアドレス内の宛先、および送信元アドレス、ＵＤＰヘッダ内の宛先、および送信元ポート番号は(8) におけるデータ中継要求パケットにおけると同じであり、パケットのデータ部には受信準備完了通知が格納されている。これでフェーズ３の動作は終了する。
【００６５】
サーバ側ゲートウェイ１１は、クライアント側ゲートウェイ１３からの受信準備完了通知を受け取ると、マルチキャストデータの中継を開始する。第１のサーバ１０からのＩＰマルチキャストデータパケットの送信は、(1) で説明したのと同様に常にサーバ側ゲートウェイ１１に対して続けられているため、サーバ側ゲートウェイ１１は(13)で、第１のサーバ１０から受信したマルチキャストデータパケットのＩＰヘッダとＵＤＰヘッダの変換を行う。
【００６６】
そしてサーバ側ゲートウェイ１１は、(14)でＩＰデータヘッダとＵＤＰヘッダが変換されたデータパケットを、ネットワーク内でユニキャストデータパケットとして、クライアント側ゲートウェイ１３に中継する。ここで中継されるデータパケットのＩＰヘッダ、ＵＤＰヘッダに含まれるＩＰアドレスや、ポート（ソケット）番号などのデータは、図１３の(14)に示されるように、(10)における復元情報送信時のパケットヘッダの内容と同じである。
【００６７】
クライアント側ゲートウェイ１３はサーバ側から中継されたデータパケットを受け取ると、(15)で管理テーブル１７の内容を参照してＩＰヘッダとＵＤＰヘッダの変換を行って、マルチキャストデータパケットを復元し、(16)で復元されたマルチキャストデータパケットを中継、すなわち同報して、クライアント１４に与える。この復元されたマルチキャストデータパケットのＩＰヘッダ内の宛先ＩＰアドレスは、マルチキャストデータのアドレスとしての０００、送信元ＩＰアドレスはサーバ１０のアドレスとしての１００、宛先ポート（ソケット）番号はあまり意味はないが、ここでは１０１、送信元ポート（ソケット）番号は第１のサーバ１０のポート番号としての１０２である。
【００６８】
図１１は前述の第２の方法、すなわち［２］における動作シーケンスの後半を示し、図１４は［２］におけるパケットのＩＰヘッダ、ＵＤＰヘッダ、およびデータ部に格納されるデータの説明図であり、図１７は［２］における管理テーブルのフォーマットと格納されるデータの例である。
【００６９】
［２］においても、動作シーケンスの前半は図９におけると全く同じである。従って図１４において(1) 〜(8) に対応するデータは図１３におけると同じであり、また図１７でサーバ側ゲートウェイとクライアント側ゲートウェイとのそれぞれに備えられる管理テーブルの内容も、生成タイミング(3) と(7) に対しては同じである。
【００７０】
図１１の後半の動作シーケンスは図１０におけると同じ部分も多いので、図１０と異なる部分についてのみ説明する。［２］においては前述のように、最終的にクライアント側ゲートウェイ１３からクライアント１４に対してＩＰマルチキャストデータパケットが中継される時、送信元ＩＰアドレスとしてクライアント側ゲートウェイ１２のＩＰアドレス４００がＩＰヘッダに格納される点が［１］と異なっている。そこでクライアント側ゲートウェイ１３において、サーバ側ゲートウェイ１１から中継されてきたＩＰユニキャストデータパケットをマルチキャストデータパケットに変換する際の復元データとして、このマルチキャストデータの配信元である第１のサーバ１０のＩＰアドレス１００は不必要となる。
【００７１】
このため(10)でサーバ側ゲートウェイ１１からクライアント側ゲートウェイ１３に送られる復元情報は、図１０の(10)と異なってサーバのＩＰアドレス１００を含む必要がなくなる。このことは図１４において(10)におけるデータ部に、図１３の(10)と異なって、サーバのＩＰアドレス＝１００が含まれていないことに示されている。
【００７２】
従って図１１の(11)で、クライアント側ゲートウェイ１３の管理テーブル１７に格納される復元情報には第１のサーバ１０のＩＰアドレス１００は含まれず、このことから図１７のクライアント側ゲートウェイの管理テーブルには、図１６と異なって、サーバＩＰアドレスの格納領域は存在せず、生成タイミング(11)では宛先ポート（ソケット）番号、および送信元ポート（ソケット）番号のみが格納されることが示されている。
【００７３】
そして図１１では、(16)でクライアント側ゲートウェイ１３からクライアント１４に対して中継されるＩＰマルチキャストデータパケットのＩＰヘッダに含まれる送信元ＩＰアドレスが図１０の(16)における１００、すなわち第１のサーバ１０のＩＰアドレスではなく、４００、すなわちクライアント側ゲートウェイ１３のＩＰアドレスである点が異なっており、このことは図１４の(16)における送信元ＩＰアドレスが４００であり、図１３の(16)における送信元ＩＰアドレスが１００であるのと異なる点に示されている。
【００７４】
図１２は前述の［３］における後半の動作シーケンスチャートであり、図１５は［３］においてＩＰヘッダ、ＵＤＰヘッダ、およびデータ部に格納されるデータを示す。［３］においても、動作シーケンスの前半は図９と同じであり、従って図１５においても(1) 〜(8) に対応するデータは、図１３および図１４と同じである。なお［３］におけるサーバ側ゲートウェイとクライアント側ゲートウェイに備えられる管理テーブルのフォーマットとその格納データは図１６と全く同じであるため、その説明を省略する。
【００７５】
図１２において、(15)までの動作は［１］に対する図１０におけると同じであり、従って図１５における(14)までのデータは、図１３におけると同じである。［１］におけると異なる動作は、(16)におけるクライアント側ゲートウェイ１３からクライアント１４に対して最終的にマルチキャストデータパケットを中継する時の動作である。［３］においては、この時ＩＰヘッダ内の送信元ＩＰアドレスとしてクライアント１４が要求したマルチキャストデータそのもののアドレス０００が使われる。これが図１０において、送信元ＩＰアドレスとして第１のサーバ１０のＩＰアドレス１００が使われる点と異なる点である。この相違に対応して、図１５でも(16)における送信元ＩＰアドレスは０００となっている。
【００７６】
最後に本発明におけるプログラムのコンピュータへのローディングについて図１８を用いて説明する。本発明におけるヘッダの変換は、例えばサーバが所属するローカルエリアネットワークとインターネットとを接続するゲートウェイ装置、およびインターネットとクライアントの属するＬＡＮとを接続するゲートウェイ装置によって実行されるが、これらのゲートウェイ装置はコンピュータをその基本要素として構成することが可能である。
【００７７】
そこで本発明の請求項１０、図７、図８などのプログラムは、コンピュータ４１のメモリ４５に格納され、本体４４によってそのプログラムが実行されることによって、ヘッダ変換が行われる。
【００７８】
このプログラムは、例えば可搬型記憶媒体４２に記録され、その記憶媒体４２をコンピュータ４１にロードすることによって、またはプログラム提供者側からネットワーク回線４３を介して転送され、コンピュータ４１にロードされることによって実行されることもできる。
【００７９】
コンピュータ４１のメモリ４５としては、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、またはハードディスクなどを使用することができ、また可搬型記憶媒体４２としてはメモリカード、フロッピーディスク、ＣＤ−ＲＯＭ、光ディスク、光磁気ディスクなど、任意のコンピュータ読み取り可能な記憶媒体を使用することができる。
【００８０】
以上の説明においては、主として１つのサーバから１つのクライアントに対して、ＩＰマルチキャストデータパケットをインターネットを介して配信する場合を対象として本発明の内容を説明したが、本発明の対象はこれに限定されるものでないことは当然である。例えばインターネットの両側に１つの企業の工場や営業所などに対応する２つのＬＡＮが存在し、営業所と工場の間で例えばテレビ会議を行う場合に相互にマルチキャストデータを送受信するような形式も当然可能である。この場合、本発明のヘッダ変換装置はゲートウェイ装置に備えられるだけとは限定されず、例えばＩＰネットワークのルータに備えられることも当然可能である。
【００８１】
【発明の効果】
以上詳細に説明したように、本発明によればマルチキャストデータパケットをヘッダ変換によってユニキャストデータパケットに変換し、マルチキャストデータ通信をサポートしていないネットワーク、あるいはマルチキャストデータ通信をサポートしているかいないかが不明のネットワークに対して入力させ、ネットワークの出口で再びマルチキャストデータパケットに変換することによって、例えば仮想公衆網（ＶＰＮ）を構成する２つのローカルエリアネットワークの間でマルチキャストデータ通信を実行することが可能になり、マルチキャストデータ通信の普及に寄与するところが大きい。
【図面の簡単な説明】
【図１】本発明の原理構成ブロック図である。
【図２】本発明のヘッダ変換方式が用いられるマルチキャストデータ通信システムの全体構成を示すブロック図である。
【図３】図２のマルチキャストデータ通信システムにおけるデータの流れを説明する図である。
【図４】ゲートウェイによるヘッダの書き換えを説明する図である。
【図５】マルチキャストデータ転送時におけるＩＰヘッダの変換を説明する図である。
【図６】ネットワークシステム内の動作の概要を説明する図である。
【図７】クライアント側ゲートウェイによる処理のフローチャートである。
【図８】サーバ側ゲートウェイによる処理のフローチャートである。
【図９】第１、第２、第３の方法において２つのゲートウェイによって実行される動作の前半部分を示すシーケンスチャートである。
【図１０】第１の方法における動作の後半部分を示すシーケンスチャートである。
【図１１】第２の方法における動作の後半部分を示すシーケンスチャートである。
【図１２】第３の方法における動作の後半部分を示すシーケンスチャートである。
【図１３】第１の方法において用いられるデータの例を示す図である。
【図１４】第２の方法において用いられるデータの例を示す図である。
【図１５】第３の方法において用いられるデータの例を示す図である。
【図１６】第１の方法における２つのゲートウェイの管理テーブルの例を示す図である。
【図１７】第２の方法における２つのゲートウェイの管理テーブルの例を示す図である。
【図１８】本発明におけるプログラムのコンピュータへのローディングを説明する図である。
【図１９】マルチキャストデータ通信の従来技術の第１の例を示す図である。
【図２０】マルチキャストデータ通信の従来技術の第２の例を示す図である。
【符号の説明】
１ パケット変換装置
２ ヘッダ変換手段
１０ サーバ
１１ サーバ側ゲートウェイ
１２ ＩＰネットワーク
１３ クライアント側ゲートウェイ
１４ クライアント
１５ａ〜１５ｅ ルータ
１７，１８ 管理テーブル
Claims (4)
- ネットワークの入口／出口に備えられ、パケットの変換を行うパケット変換システムにおいて、
ローカルエリアネットワークに属し、マルチキャストデータ転送パケットの要求元であるクライアントに接続されたクライアント側ゲートウェイ装置に備えられるクライアント側パケット変換装置は、
ネットワークから受取ったユニキャストデータ転送パケットのヘッダを書き換えてマルチキャストデータ転送パケットとして出力する動作を実行するクライアント側ヘッダ変換手段と、
クライアントからのマルチキャストデータ転送パケットの受信要求に対応する識別子を前記マルチキャストデータそのもののＩＰアドレスに対応させて記憶するクライアント側識別子記憶手段とを備え、
前記クライアントが接続されたローカルエリアネットワークと異なるローカルエリアネットワークに属し、マルチキャストデータ転送パケットを配信するサーバに接続されたサーバ側ゲートウェイ装置に設けられるサーバ側パケット変換装置は、
マルチキャストデータ転送パケットのヘッダを書き換えてユニキャストデータ転送パケットとして前記ネットワークに入力させる動作を実行するサーバ側ヘッダ変換手段と、
クライアント側パケット変換装置から通知された、クライアントからのマルチキャストデータ転送パケットの受信要求に対応する識別子を前記マルチキャストデータそのもののＩＰアドレスに対応させて記憶するサーバ側識別子記憶手段とを備え、
ることを特徴とするパケット変換システム。 - 前記サーバ側パケット変換装置とクライアント側パケット変換装置が、前記クライアント側ゲートウェイ装置及び前記サーバ側ゲートウェイ装置ではなく、前記ネットワーク内での、パケットの転送制御を実行するルータに備えられることを特徴とする請求項１記載のパケット変換システム。
- ネットワークの入口／出口に備えられ、パケットの変換を行うパケット変換システムのパケット変換方法において、
ローカルエリアネットワークに属し、マルチキャストデータ転送パケットの要求元であるクライアントに接続されたクライアント側ゲートウェイ装置に備えられるクライアント側パケット変換装置は、
ネットワークから受取ったユニキャストデータ転送パケットのヘッダを書き換えてマルチキャストデータ転送パケットとして出力する動作を実行し、
クライアントからのマルチキャストデータ転送パケットの受信要求に対応する識別子を前記マルチキャストデータそのもののＩＰアドレスに対応させて記憶し、
前記クライアントが接続されたローカルエリアネットワークと異なるローカルエリアネットワークに属し、マルチキャストデータ転送パケットを配信するサーバに接続されたサーバ側ゲートウェイ装置に設けられるサーバ側パケット変換装置は、
マルチキャストデータ転送パケットのヘッダを書き換えてユニキャストデータ転送パケットとして前記ネットワークに入力させる動作を実行し、
クライアント側パケット変換装置から通知された、クライアントからのマルチキャストデータ転送パケットの受信要求に対応する識別子を前記マルチキャストデータそのもののＩＰアドレスに対応させて記憶する、
ことを特徴とするパケット変換方法。 - ネットワークの入口／出口に備えられ、パケットの変換を行うパケット変換システムにおいて使用される記憶媒体であって、
ローカルエリアネットワークに属し、マルチキャストデータ転送パケットの要求元であるクライアントに接続されたクライアント側ゲートウェイ装置に備えられるクライアント側パケット変換装置は、
ネットワークから受取ったユニキャストデータ転送パケットのヘッダを書き換えてマルチキャストデータ転送パケットとして出力する動作を実行し、
クライアントからのマルチキャストデータ転送パケットの受信要求に対応する識別子を前記マルチキャストデータそのもののＩＰアドレスに対応させて記憶し、
前記クライアントが接続されたローカルエリアネットワークと異なるローカルエリアネットワークに属し、マルチキャリアデータ転送パケットを配信するサーバに接続されたサーバ側ゲートウェイ装置に設けられるサーバ側パケット変換装置は、
マルチキャストデータ転送パケットのヘッダを書き換えてユニキャストデータ転送パケットとして前記ネットワークに入力させる動作を実行し、
クライアント側パケット変換装置から通知された、クライアントからのマルチキャストデータ転送パケットの受信要求に対応する識別子を前記マルチキャストデータそのもののＩＰアドレスに対応させて記憶する、
ことをコンピュータに実行させるためのプログラムを格納したコンピュータ読み取り可能な可搬型記憶媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000039076A JP3774351B2 (ja) | 2000-02-17 | 2000-02-17 | パケット変換装置およびパケット変換方法 |
| US09/722,305 US6836481B1 (en) | 2000-02-17 | 2000-11-28 | Packet conversion device and packet conversion method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000039076A JP3774351B2 (ja) | 2000-02-17 | 2000-02-17 | パケット変換装置およびパケット変換方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001230774A JP2001230774A (ja) | 2001-08-24 |
| JP3774351B2 true JP3774351B2 (ja) | 2006-05-10 |
Family
ID=18562698
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000039076A Expired - Fee Related JP3774351B2 (ja) | 2000-02-17 | 2000-02-17 | パケット変換装置およびパケット変換方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6836481B1 (ja) |
| JP (1) | JP3774351B2 (ja) |
Families Citing this family (54)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3506092B2 (ja) * | 2000-02-28 | 2004-03-15 | 日本電気株式会社 | マルチキャストパケット転送装置、マルチキャストパケット転送システム及び記憶媒体 |
| JP3667586B2 (ja) | 2000-02-28 | 2005-07-06 | 日本電気株式会社 | マルチキャストパケット転送装置、マルチキャストパケット転送システム及び記憶媒体 |
| GB2371705B (en) * | 2001-01-30 | 2003-04-23 | 3Com Corp | Network switch with mutually coupled look-up engine and network processor |
| US7079501B2 (en) * | 2001-01-31 | 2006-07-18 | International Business Machines Corporation | Method and system for efficiently delivering content to multiple requesters |
| US6978308B2 (en) * | 2001-03-21 | 2005-12-20 | International Business Machines Corporation | System and method for nesting virtual private networking connections with coincident endpoints |
| US7020129B2 (en) * | 2001-06-05 | 2006-03-28 | Lucent Technologies Inc. | Dynamic assignment of telecommunications switches and packet switch gateways |
| JP4728511B2 (ja) * | 2001-06-14 | 2011-07-20 | 古河電気工業株式会社 | データ中継方法、その装置およびその装置を用いたデータ中継システム |
| US20030023739A1 (en) * | 2001-07-28 | 2003-01-30 | Lan Ngoc Vu | System and method for multi-tier multi-casting over the Internet |
| JP2003069641A (ja) * | 2001-08-29 | 2003-03-07 | Fujitsu Ltd | パケット転送装置 |
| KR100425020B1 (ko) * | 2001-11-26 | 2004-03-27 | 주식회사 케이티프리텔 | 명시적 멀티캐스트의 터널링 서비스 방법 및 장치 |
| KR100429292B1 (ko) | 2001-12-12 | 2004-04-29 | 주식회사 케이티프리텔 | 이동 아이피 네트워크에서 명시적 멀티캐스트 터널링서비스 방법 및 장치 |
| JP3925188B2 (ja) | 2001-12-20 | 2007-06-06 | 日本電気株式会社 | アプリケーションレイヤ・マルチキャスト方法及び中継ノードシステム |
| JP3998983B2 (ja) | 2002-01-17 | 2007-10-31 | 松下電器産業株式会社 | ユニキャスト−マルチキャスト変換装置および映像監視システム |
| JP4025593B2 (ja) | 2002-07-11 | 2007-12-19 | 富士通株式会社 | 放送型通信データ配送装置および放送型通信システム |
| JP3798754B2 (ja) * | 2003-03-13 | 2006-07-19 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ルータを介して接続されたサブネットワーク間のブロードキャスト |
| JP3984929B2 (ja) | 2003-06-11 | 2007-10-03 | Ｎｅｃインフロンティア株式会社 | ＶｏＩＰシステム、ＶｏＩＰサーバ、及びマルチキャストパケット通信方法 |
| JP4292890B2 (ja) * | 2003-06-26 | 2009-07-08 | 株式会社日立製作所 | マルチキャスト配信方法、配信装置およびシステム |
| JP4328283B2 (ja) | 2003-10-22 | 2009-09-09 | パナソニック株式会社 | パケット配送制御方法 |
| US7546355B2 (en) * | 2004-01-16 | 2009-06-09 | Bloomberg Finance L.P. | Network architecture for data transmission |
| JP4382528B2 (ja) | 2004-02-27 | 2009-12-16 | 富士通株式会社 | マルチキャストネットワーク装置，マルチキャストネットワークシステムおよびマルチキャスト方法 |
| US9178709B2 (en) | 2004-03-30 | 2015-11-03 | Panasonic Intellectual Property Management Co., Ltd. | Communication system and method for distributing content |
| GB2418574A (en) * | 2004-09-22 | 2006-03-29 | Motorola Inc | Translating multicast packets to unicast packets and then converting these unicast packets to multicast packets, by rewriting addresses |
| JP4128561B2 (ja) * | 2004-11-04 | 2008-07-30 | アンリツ株式会社 | マルチキャスト通信中継装置およびマルチキャスト通信中継システム |
| US8619662B2 (en) | 2004-11-05 | 2013-12-31 | Ruckus Wireless, Inc. | Unicast to multicast conversion |
| US7505447B2 (en) | 2004-11-05 | 2009-03-17 | Ruckus Wireless, Inc. | Systems and methods for improved data throughput in communications networks |
| US8638708B2 (en) | 2004-11-05 | 2014-01-28 | Ruckus Wireless, Inc. | MAC based mapping in IP based communications |
| TWI391018B (zh) | 2004-11-05 | 2013-03-21 | Ruckus Wireless Inc | 藉由確認抑制之增強資訊量 |
| EP1855420B1 (en) | 2005-03-04 | 2014-01-15 | Fujitsu Ltd. | Packet relay device |
| US7505464B2 (en) * | 2005-08-30 | 2009-03-17 | Cisco Technology, Inc. | Method of identifying a home gateway using network traffic sniffing and apparatus employing the same |
| WO2007098699A1 (fr) * | 2006-03-02 | 2007-09-07 | Huawei Technologies Co., Ltd. | Procédé de commande de flux multimédia, dispositif de conversion de flux multimédia et système de multiffusion |
| JP4967664B2 (ja) * | 2007-01-10 | 2012-07-04 | 日本電気株式会社 | ネットワーク、ノード装置及びそれらに用いるｌｌｄｐフレーム転送方法 |
| JP4966115B2 (ja) * | 2007-07-04 | 2012-07-04 | 日本放送協会 | 無線通信装置 |
| US8547899B2 (en) | 2007-07-28 | 2013-10-01 | Ruckus Wireless, Inc. | Wireless network throughput enhancement through channel aware scheduling |
| US8355343B2 (en) | 2008-01-11 | 2013-01-15 | Ruckus Wireless, Inc. | Determining associations in a mesh network |
| JP4665007B2 (ja) * | 2008-03-28 | 2011-04-06 | パナソニック株式会社 | 監視映像送信装置および方法 |
| US8416727B2 (en) * | 2008-07-31 | 2013-04-09 | Motorola Solutions, Inc. | Communicating a group message packet over a wide area network |
| US8116230B2 (en) * | 2008-07-31 | 2012-02-14 | Motorola Solutions, Inc. | Establishing communication pathways between infrastructure devices in a group communication system implemented over a wide area network |
| WO2011060454A2 (en) | 2009-11-16 | 2011-05-19 | Ruckus Wireless, Inc. | Establishing a mesh network with wired and wireless links |
| US9979626B2 (en) | 2009-11-16 | 2018-05-22 | Ruckus Wireless, Inc. | Establishing a mesh network with wired and wireless links |
| JP5392137B2 (ja) * | 2010-02-17 | 2014-01-22 | 富士通株式会社 | 通信処理のためのプログラム、コンピュータ及び方法 |
| US8380799B2 (en) * | 2010-04-15 | 2013-02-19 | Ebay Inc. | Topic-based messaging using consumer address and pool |
| US20120023533A1 (en) * | 2010-07-22 | 2012-01-26 | Alcatel-Lucent Usa Inc. | Method and apparatus for delivery of internet protocol television service |
| US9432204B2 (en) | 2013-08-24 | 2016-08-30 | Nicira, Inc. | Distributed multicast by endpoints |
| US9602385B2 (en) | 2013-12-18 | 2017-03-21 | Nicira, Inc. | Connectivity segment selection |
| US9602392B2 (en) | 2013-12-18 | 2017-03-21 | Nicira, Inc. | Connectivity segment coloring |
| JP2015122640A (ja) | 2013-12-24 | 2015-07-02 | 日立金属株式会社 | 中継システムおよびスイッチ装置 |
| JP2015122665A (ja) | 2013-12-24 | 2015-07-02 | 日立金属株式会社 | 中継システムおよびスイッチ装置 |
| US9794079B2 (en) | 2014-03-31 | 2017-10-17 | Nicira, Inc. | Replicating broadcast, unknown-unicast, and multicast traffic in overlay logical networks bridged with physical networks |
| JP6379702B2 (ja) * | 2014-06-06 | 2018-08-29 | 日本電気株式会社 | データ転送システム、データ転送サーバ、データ転送方法、および、プログラム |
| US10193763B2 (en) * | 2016-09-20 | 2019-01-29 | Fortinet, Inc. | Reducing multicast service traffic for matching and streaming in SDN (software defined networking enabled networks |
| JP6861102B2 (ja) * | 2017-06-02 | 2021-04-21 | 日本放送協会 | データ配信装置及びプログラム |
| US10778457B1 (en) | 2019-06-18 | 2020-09-15 | Vmware, Inc. | Traffic replication in overlay networks spanning multiple sites |
| US11784922B2 (en) | 2021-07-03 | 2023-10-10 | Vmware, Inc. | Scalable overlay multicast routing in multi-tier edge gateways |
| SE2151546A1 (en) * | 2021-12-16 | 2023-06-17 | Assa Abloy Ab | Routing data in a communication network |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0622492A (ja) | 1992-06-30 | 1994-01-28 | Sony Corp | 偏平モータ |
| DE69228423T2 (de) * | 1992-11-27 | 1999-09-30 | International Business Machines Corp., Armonk | Mehrfachsende-Leitweglenkung zwischen Bereichen |
| US5917819A (en) * | 1996-04-26 | 1999-06-29 | Cascade Communications Corp. | Remapping of ATM cells for multicast transmission |
| JPH10242962A (ja) | 1997-02-25 | 1998-09-11 | Nippon Telegr & Teleph Corp <Ntt> | インターネット上のマルチキャストゲートウェイ通信方法及びシステム |
| US6259701B1 (en) * | 1997-09-11 | 2001-07-10 | At&T Corp. | Method and system for a unicast endpoint client to access a multicast internet protocol (IP) session |
| US6181697B1 (en) * | 1998-03-31 | 2001-01-30 | At&T Corp. | Method for a unicast endpoint client to access a multicast internet protocol (IP) session and to serve as a redistributor of such session |
-
2000
- 2000-02-17 JP JP2000039076A patent/JP3774351B2/ja not_active Expired - Fee Related
- 2000-11-28 US US09/722,305 patent/US6836481B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6836481B1 (en) | 2004-12-28 |
| JP2001230774A (ja) | 2001-08-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3774351B2 (ja) | パケット変換装置およびパケット変換方法 | |
| JP2520563B2 (ja) | パケット交換網 | |
| JP3667586B2 (ja) | マルチキャストパケット転送装置、マルチキャストパケット転送システム及び記憶媒体 | |
| US7917948B2 (en) | Method and apparatus for dynamically securing voice and other delay-sensitive network traffic | |
| US6907037B2 (en) | Multicast routing method and an apparatus for routing a multicast packet | |
| JP3519616B2 (ja) | 中継装置 | |
| JP4598859B2 (ja) | 中継ネットワークシステム及び端末アダプタ装置 | |
| US20070195804A1 (en) | Ppp gateway apparatus for connecting ppp clients to l2sw | |
| JP3881635B2 (ja) | ネットワークアドレス変換システムおよびその方法 | |
| WO2024012001A1 (zh) | 一种在多模态网络中实现开源社区访问的方法及系统 | |
| JP2002354006A (ja) | 重複アドレスのネットワークシステム | |
| JP4011528B2 (ja) | ネットワーク仮想化システム | |
| JP5261432B2 (ja) | 通信システム、パケット転送方法、ネットワーク交換装置、アクセス制御装置、及びプログラム | |
| CN108234325B (zh) | 基于ip任播的系统及报文转发方法 | |
| JP4494279B2 (ja) | マルチキャスト制御方法、マルチキャスト制御装置、及びコンテンツ属性情報管理装置、並びにプログラム | |
| JP3759527B2 (ja) | マルチキャストデータ通信システム及び方法、クライアント側ゲートウェイ、サーバ側ゲートウェイ、コンピュータプログラム、ならびに、コンピュータプログラムを記録した記録媒体 | |
| CN112702251B (zh) | 报文检测方法、连通性协商关系建立方法以及相关设备 | |
| JP3742390B2 (ja) | Ｈｔｔｐトンネリングサーバを用いた通信方法および通信装置、プログラム | |
| JP2005323316A (ja) | ゲートウェイ装置 | |
| JPH11191790A (ja) | 通信データ処理方法及びそのネットワーク間接続装置 | |
| JP2004032453A (ja) | パケット通信システムとこのシステムで使用されるパケット転送装置及びパケット転送制御プログラム | |
| JP2006211457A (ja) | コンバータ装置及び通信制御方法 | |
| JP2000174809A (ja) | Ｐｐｐ通信装置とそれを用いたｐｐｐ通信システム | |
| JP2016149701A (ja) | ネットワークシステムおよびパケット転送方法 | |
| JPH0556050A (ja) | ネツトワークシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051003 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051011 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051205 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060214 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060217 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090224 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100224 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110224 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110224 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120224 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |