JP2010104059A - パケット中継装置 - Google Patents

Abstract

【課題】 本発明の目的は、特定の送信元からのマルチキャストグループにしか参加できないマルチキャストネットワークにおいて、不特定の送信元サーバからのマルチキャストグループへの参加要求しか出せない端末を、端末に手を加えることなく、ネットワーク管理者が許可する送信元からのマルチキャストグループに、端末からの要求に応じて動的に参加させたり離脱させたりすることである。
【解決手段】 送信元非限定のマルチキャストしかサポートしていない端末100からのマルチキャストグループへの参加要求に含まれるマルチキャストグループアドレスとその参加要求の発生した回線116とをもとに、そのマルチキャストネットワークへのネットワーク管理者が許可する送信元サーバをマルチキャスト送信元管理表220で算出することにより、マルチキャストルータ110は送信元非限定のマルチキャストグループへの参加要求を、ネットワーク管理者が許可する送信元サーバからのマルチキャストグループへの参加要求に変換する。
【選択図】 図２

Description

本発明は送信元サーバが限定されるマルチキャストネットワークに関し、特に送信元サーバを指定することができない端末を接続する技術に関する。

マルチキャストは、インターネットにおいて複数の送信先に同時にパケットを送信する技術である。1つの送信先にパケットを複数回送るのに比べて少ない量のパケットで複数の送信先に流すことが可能であるため、特にストリーミングやビデオ会議に代表される大容量トラフィックを必要とするリアルタイムマルチメディア通信に適している。

しかしながら今日マルチキャストネットワークはあまり世の中に普及していない。その大きな原因の一つに、マルチキャスト経路制御の繁雑さがある。DVMRP(Distance Vector M ulticast Routing Protocol: RFC1075)やPIM-DM(Protocol Independent Multicast-Dense Mode: draft-ietf-pim-dm-new-v2-01.txt)といったマルチキャスト経路制御プロトコルは単純であるものの、マルチキャストトラフィックを送信不要なセグメント（ネットワークの構成単位）にも流すためにネットワーク利用効率が悪いという欠点があった。そのためこの欠点を克服したPIM-SM(Protocol Independent Multicast-Sparse Mode: RFC2362)がマルチキャストネットワークの運用では通常用いられている。PIM-SMは必要最小限のセグメントにだけマルチキャストトラフィックを流すものの、マルチキャスト送信ツリー計算のオーバーヘッドが大きいために、プロトコルが複雑、運用が難しい、ルータの負荷が大きくなるといった難点がある。(朝枝, 「Source Specific Multicastによる新たな通信ア ーキテクチャ」, 情報処理, 2002年3月, Vol 43, No. 3, pp. 260-265)
この繁雑さを解消するために提案されている有力な技術に、ソース限定型マルチキャスト (Source-Specific Multicast)がある。従来型のn対nのマルチキャスト通信ではマルチキャスト受信端末がグループへの参加要求を送信していたが、ソース限定型マルチキャストではマルチキャスト受信端末がグループへの参加要求を送信するときに、マルチキャスト送信元を同時に指定する。受信元でマルチキャスト送信元を指定して、1対nのマルチキャスト通信に処理を限定し、マルチキャスト経路制御をより単純にすることがその狙いである(draft-ietf-ssm-overview-00.txt)。マルチキャストが用いられる事例の多くが少数のサーバからのストリーミングであることを考えると、1対nの通信に処理を限定してもマルチキャストに対するユーザニーズは満たすことが出来る。

ソース限定型マルチキャスト経路制御と従来のマルチキャスト経路制御との大きな違いは、エンドユーザの端末がマルチキャストグループに加入するときにマルチキャストグループのアドレスと一緒にその送信元サーバを指定しなければならないことである。エンドユーザの端末がソース限定型マルチキャストネットワークに参加するには、それに対応したマルチキャストグループ管理プロトコル(IPv4ではIGMPv3 = Internet Group Management Protocol Version 3、IPv6ではMLDv2 = Multicast Listener Discovery Version 2)をサポートする必要がある。しかしながら今日現在IGMPv3やMLDv2をサポートした端末の数は多くない。またIGMPv3やMLDv2は従来のソース非限定型マルチキャストグループ管理プロトコルに比べて実装コストが高いため、情報家電に代表される低コスト性が要求される端末には今後も実装されないことが予想される。

そのためIGMPv3やMLDv2をサポートしない端末をソース限定型マルチキャストネットワークに接続するための提案がいくつかなされている。Cisco社のIGMPv3 Liteでは、エンドユーザ端末のアプリケーションに機能を限定したIGMPv3変換ライブラリを組み込むことによって、エンドユーザ端末のアプリケーションがIGMPv3をサポートしていなくても変換ライブラリを通じてソース限定型マルチキャストネットワークに参加できるようにしている。 Cisco社のURD(URL Rendezvous Discovery)では、エンドユーザがHTTP(Hyper Text Trans fer Protocol)によりルータに対して送信元サーバを指示することにより、エンドユーザの端末やアプリケーションがIGMPv3に対応していなくてもルータに対してソース限定型マルチキャストネットワークへの参加要求を通知することができる。これらの他にもルータ自身がある回線に対して特定の送信元からのマルチキャストグループに静的に参加することにより、その回線上にいるエンドユーザ端末がIGMPv3をサポートしていなくても回線上にその送信元からのマルチキャストトラフィックが流れるようにすることもできる(Cisco社 "Source-Specific Multicast with IGMPv3, IGMPv3lite, and URD feature module, Re lease 12.1(5)T", http://www.cisco.com/univercd/cc/td/doc/product/software/ios121 /121newft/121t/121t5/dtssm5t.htm)。

ソース限定型マルチキャストの利点の一つに、特定の端末からのマルチキャスト送信のみを許容するため不特定端末からのマルチキャスト送信によってネットワーク資源を無駄に消費されることを防止できることがある。この観点でソース限定型マルチキャストをより改善する提案としては、Sonera社のLehtonenによって提案されたマルチキャスト制御プロトコル(draft-lehtonen-magma-mcop-00.txt)がある。このシステムは、ソース限定型マルチキャスト参加要求をマルチキャスト中継装置が受信したときにマルチキャスト制御サーバに参加の可不可を問い合わせることにより、ソース限定型マルチキャスト参加要求のフィルタリングをマルチキャスト制御サーバで一括して管理できるシステムである。

「Source Specific Multicastによる新たな通信アーキテクチャ」, 情報処理, 2002年3月, Vol 43, No. 3, pp. 260-265

ソース限定型マルチキャストネットワークにソース限定型マルチキャスト未対応の端末を繋げる従来の技術には二つの問題点がある。一つはエンドユーザ側のコンピュータやアプリケーションに手を入れなければ対応できないことである。IGMPv3 LiteとURDとがこの欠点を有する。IGMPv3 Liteの場合はアプリケーションを変換ライブラリを用いて再構築する必要があり、URDの場合はアプリケーションとは別にユーザが別途自らソース限定型マルチキャストネットワークへの参加手続を行う必要がある。そのためソース非限定型マルチキャストネットワークに比べて、ユーザの手間が大きくなっている。ルータ自身が静的にマルチキャスト参加する場合にはこの問題点はない。しかしながら、この場合には実際にマルチキャスト参加者がいない場合もルータが静的にマルチキャストグループに加入している回線にはマルチキャストトラフィックが流れてしまう。そのため回線帯域の無駄使いによる輻輳や不要な回線コストをユーザに強いてしまう。

本発明はこれら二つの問題点を同時に解決する。即ちソース非限定型マルチキャストにしか対応していないエンドユーザ端末を、設定を変更せずにソース限定型マルチキャストネットワークに動的に参加させたり離脱させたりすることが本発明の解決するべき課題である。

本発明では端末からルータへ送られるソース非限定型マルチキャストグループ参加要求をソース限定型マルチキャストグループ参加要求に変換する。変換に際しては、マルチキャスト送信元管理表を用いる。この表ではルータ、マルチキャストグループアドレス、マルチキャストグループ管理パケット発信端末の3つと、それに対応する送信元サーバとの対応を管理する。この表はマルチキャスト制御プロトコルにて用いられる表と同様なものである。

エンドユーザ端末を収容するルータはこの表を用いて、ソース非限定型マルチキャストグループ参加要求をネットワーク管理者が許可した送信元サーバに限定されたマルチキャストグループ参加要求に変換する。又ルータがソース限定型マルチキャストグループへの参 加者の有無を問い合わせるときも、ルータは同じ表を検索してそのソースからのマルチキャストグループへの参加が認められていることを確認した後、ソース非限定マルチキャストグループへの参加者の有無を問い合わせる。

本発明の一つの観点は、マルチキャストクライアント端末を収容するパケット中継装置であって、マルチキャスト送信元を指定できないマルチキャストクライアント端末からのマルチキャストグループへの参加または離脱要求を、マルチキャスト送信元を指定したマルチキャストグループへの参加または離脱要求に変換して処理するパケット中継装置である。この中継装置では、マルチキャストクライアント端末のアドレスと、参加または離脱要求されたマルチキャストグループのアドレスを元にして、指定すべきマルチキャスト送信元を定めることができる。さらに詳細には、マルチキャストグループアドレスと、マルチキャストクライアント端末アドレスと、それらに対応するマルチキャスト送信元アドレスとの対応テーブルを用い、マルチキャスト送信元を指定できないマルチキャストクライアント端末からマルチキャストグループへの参加または離脱要求が発生したとき、対応テーブルを参照して、参加または離脱要求を行ったマルチキャストクライアント端末のアドレスと参加または離脱要求されたマルチキャストグループのアドレスを含むエントリのマルチキャスト送信元アドレスを、指定すべきマルチキャスト送信元とする。対応テーブルのマルチキャスト送信元アドレスが"Don't care"である場合には、マルチキャスト送信元を指定しないマルチキャストグループへの参加または離脱要求として処理することにしてもよい。対応テーブルは、パケット中継装置に内蔵されるか、あるいは、パケット中継装置と回線により接続されてアクセス可能な別個の装置内に配置される。

本発明の他の態様は、マルチキャストクライアント端末を収容するパケット中継装置であって、マルチキャスト参加問い合わせに対して、特定のマルチキャスト送信元からのマルチキャストグループに参加するマルチキャストクライアント端末が、あるネットワークに存在するかどうかを、マルチキャストクライアント端末がマルチキャスト送信元を特定するマルチキャスト参加問い合わせに応答する機能を持たない場合でも検出できるパケット中継装置である。この態様では、マルチキャストグループアドレスと、マルチキャストクライアント端末アドレスと、それらに対応するマルチキャスト送信元アドレスとの対応テーブルを検索することにより、特定のマルチキャスト送信元からのマルチキャストグループに参加するマルチキャストクライアント端末が、あるネットワークに存在するかどうかを検出することができる。本 発明の他の観点は、マルチキャストクライアント端末を収容するパケット中継装置であって、マルチキャストグループと、マルチキャストグループのクライアントとなる端末のアドレスと、マルチキャストグループの送信元となるアドレスとの対応を管理する管理テーブルを備えることを特徴とするパケット中継装置であり、このテーブルを用いて、ソース非限定型マルチキャストグループ参加要求をソース限定型マルチキャストグループ参加要求に変換する。

本発明の他の観点は、ソース非限定型マルチキャストグループ参加要求をソース限定型マルチキャストグループ参加要求に変換する方法である。具体的には、送信元非限定のマルチキャストしかサポートしていない端末からのマルチキャストグループへの参加要求に含まれるマルチキャストグループアドレスとその参加要求の発生した回線とをもとに、そのマルチキャストネットワークへのネットワーク管理者が許可する送信元サーバをマルチキャスト送信元管理表で算出する。マルチキャストルータは送信元非限定のマルチキャストグループへの参加要求を、ネットワーク管理者が許可する送信元サーバからのマルチキャストグループへの参加要求に変換する。また、マルチキャストルータが特定の送信元サーバからのマルチキャストグループに参加する端末があるネットワークに存在するか否かを定期的に調べる際に、そのマルチキャストグループアドレスとその参加要求の発生した回線とをもとにそのマルチキャストネットワークへのネットワーク管理者が許可する送信元サーバをマルチキャスト送信元管理表にて算出する。算出された送信元サーバが調べようとしている送信元サーバと不一致ならば、その送信元サーバからのマルチキャストアドレスに参加する端末は回線には存在しないとマルチキャストルータは判断する。算出された送信元サーバが調べようとしている送信元サーバと一致した場合には、マルチキャストルータは送信元サーバを特定せずにマルチキャストグループへ参加している端末が回線に存在するか否かを従来同様な方法で調べる。ここで該当する端末が見つかるか否かが即ちその送信元サーバからのマルチキャストアドレスに参加する端末が回線に存在するか否かである。他の観点は、マルチキャストクライアントとそのマルチキャストクライアントを収容するマルチキャスト中継装置とマルチキャストグループアドレスとマルチキャストクライアントアドレスとそれらに対応するマルチキャスト送信元アドレスとの対応表から構成されるネットワークにおいて、マルチキャストクライアントからの送信元未指定のマルチキャストグループへの参加要求が発生したとき、マルチキャスト送信元アドレス対応表を基にして、その参加要求を行ったマルチキャストクライアントのアドレスからそのマルチキャストグループアドレスに対応する送信元アドレスを検索することにより、発生した送信元未指定のマルチキャストグループへの参加要求を送信元を指定したマルチキャストグループ参加要求に変換する方法である。また、マルチキャストクライアントとそのマルチキャストクライアントを収容するマルチキャスト中継装置とマルチキャストグループアドレスとマルチキャストクライアントアドレスとそれらに対応するマルチキャスト送信元アドレスとの対応表から構成されるネットワークにおいて、マルチキャスト中継装置から特定の送信元からのマルチキャストグループへの参加問い合わせがマルチキャスト中継装置のあるインタフェースに発生したとき、マルチキャスト送信元アドレス対応表を基にして、その参加問い合わせを送信するインタフェースにおけるマルチキャスト中継装置のアドレスからマルチキャストグループに対応するネットワーク管理者が定義したマルチキャスト送信元アドレスを検索する方法である。

本発明の範囲は、上記の方法を実現するネットワークシステム、および、上記のパケット中継装置を用いたネットワークシステムを含むものである。

本発明を用いると、エンドユーザ端末を直接収容するマルチキャストルータを変更するだけで、ソース非限定型マルチキャストしかサポートしないエンドユーザ端末も、ソース限定型マルチキャストネットワークに参加できるようになる。エンドユーザ端末からの参加要求や離脱要求を元にマルチキャストルータがマルチキャストへの参加、離脱を決定するので、エンドユーザがあるマルチキャストトラフィックを必要としなくなったらそのマルチキャストトラフィックはエンドユ ーザへ流れなくなる。

本発明の対象であるマルチキャストルーティングの全体像を示すブロック図。 本発明を用いたソース限定型マルチキャストルーティング変換装置の全体ブロック図である。 マルチキャストルータのマルチキャスト参加離脱入出力インタフェースがソース非限定型マルチキャストグループ参加要求をネットワーク管理者が許可した送信元サーバに限定されたマルチキャストグループ参加要求に変換する方法を示すフローチャートである。 マルチキャストルータのマルチキャスト参加離脱入出力インタフェースがソース限定型マルチキャストグループに参加する端末の問い合わせをソース非限定型のマルチキャストグループ参加要求に変換する方法を示すフローチャートである。 マルチキャスト参加離脱入出力インタフェースをルータの外に出して本発明を実装した実現例の全体ブロック図である。 マルチキャスト送信元管理表をルータの外に出して本発明を実装した実現例の 全体ブロック図である。 マルチキャスト送信元管理表をユーザからのリクエストにより自動更新する実現例の全体ブロック図である。

以下本発明の実施形態を具体的に説明する。

図1は本発明の対象であるソース限定型マルチキャストルーティングの全体像を示す。図2は本発明を用いたソース限定型マルチキャストルーティング変換装置の全体図である。図3は、マルチキャストネットワークにおいて端末を収容する位置にあるエッジルータがソース非限定型マルチキャストグループ参加要求をネットワーク管理者が許可した送信元サーバに限定されたマルチキャストグループ参加要求に変換する方法を示すフローチャートであり、図4はソース限定型マルチキャストグループに参加する端末の問い合わせをソース非限定型のマルチキャストグループ参加要求に変換する方法を示すフローチャートである。図5、図6、図7では、本発明の別の実施例を紹介する。

図1を用いてまず一般的なマルチキャスト通信の実現方法を説明する。マルチキャストクライアント端末100はマルチキャストグループに参加するとき、端末100を直接収容する位置にあるマルチキャストルータ110に対してマルチキャストグループへの参加要求を送信する。従来型のソース非限定マルチキャストの場合にはIGMPv2やMLDv1といったマルチキャストグループ管理プロトコルが、またソース限定マルチキャストの場合にはIGMPv3やMLDv2といったマルチキャストグループ管理プロトコルが、それぞれ用いられる。マルチキャストルータ110はマルチキャストグループへの参加要求を回線116経由でマルチキャストグループ管理パケット処理部114にて受信する。マルチキャストグループ管理パケット処理部114は受信したマルチキャスト参加要求をマルチキャスト経路制御部112に対して通知する。マルチキャスト経路制御部112は隣接するマルチキャストルータ群のうち送信元方向のマルチキャストルータ121(ソース限定型マルチキャストの場合は指定されたソースアドレスにユニキャストで到達するためのネクストホップルータである。ソース非限定型マルチキャストの場合はグループアドレスに対応してネットワーク管理者によって定義されたランデブーポイントと呼ばれるアドレスにユニキャストで到達するためのネクストホップルータ)に対してそのマルチキャストグループへの参加要求があったことを通知する。このルータ間のグループ参加離脱通知にはPIM-SMなどのマルチキャストルーティングプロトコルが用いられる。マルチキャスト経路制御部112は同時に、パケット中継部118に対して、ルータ121から当該マルチキャストグループ宛に届いたパケット(ソース限定型マルチキャストの場合には、更に指定されたソースからという条件が追加される)をマルチキャストクライアント端末100のいる回線116へ中継する設定を追加する。

この通知作業とパケット中継設定追加の繰り返しにより、ネットワーク120内のマルチキャストクライアント端末と送信端末との間に位置する全マルチキャストルータがマルチキャスト経路情報を知ることが出来る(ソース非限定型マルチキャストの場合、マルチキャストクライアント端末とランデブーポイントのマルチキャストルータの間のマルチキャストルータのみがマルチキャスト経路情報を知っているため、ランデブーポイントと送信端末との間のマルチキャストルータは必ずしもマルチキャスト経路情報を知らない。しかしながら全てのルータはランデブーポイントの場所を知っていることが前提になっているため、送信端末からマルチキャストグループに対応するランデブーポイントへ到達できるので、最終的には送信端末と受信端末の間の全ルータでマルチキャスト経路情報を知ることが可能である。従って、マルチキャストネットワーク120内のマルチキャスト送信サーバ130がそのマルチキャストグループ宛に通信すると、マルチキャストルータ122、121、110を介して端末100へも通信が流れるようになる。

マルチキャストルータ110のマルチキャストグループ管理部114は端末100がマルチキャストグループに参加しているかを把握するために、端末100の存在する回線116に対してマルチキャスト参加者がいるかどうかを定期的に確認している。端末100がマルチキャストグループに参加している場合には、端末100はその確認の問合せに対してそのマルチキャストグループへの参加要求を返答する。これらのやりとりに用いられるプロトコルは、ソース限定型マルチキャストの問い合わせの場合にはIGMPv3やMLDv2であり、ソース非限定型マルチキャストの場合にはIGMPv2やMLDv1である。既に端末100がそのマルチキャストグループには参加していない場合、端末100は何も返事を返さない。そのため回線116において一定時間マルチキャスト参加要求が途絶えると、マルチキャストルータ110は回線116にはそのマルチキャストグループに参加している端末が存在しないと判断して、送信元方向の隣接マルチキャストルータ121にそのマルチキャストグループからの離脱要求をPIM-SMなどのマルチキャストルーティングプロトコルを用いて送信する。

マルチキャスト経路制御部112は同時に、パケット中継部118に対して、ルータ121から当該マルチキャストグループ宛に届いたパケット(ソース限定型マルチキャストの場合には、更に指定されたソースからという条件が追加される)をマルチキャストクライアント端末100のいるネットワークへ中継する設定を削除する。

この通知作業とパケット中継設定削除の繰り返しによりネットワーク120内の全マルチキャストルータにエッジルータ110におけるそのマルチキャストグループへの経路情報の消失が広まるので、マルチキャスト送信サーバ130がマルチキャストグループ宛に通信しても端末100へその通信が届かなくなる。

ソース非限定型マルチキャストにおいては、マルチキャストクライアント端末100からマルチキャストルータ110を介してネットワーク120全体に広告される参加要求や離脱要求にマルチキャストグループアドレスしか含まれないのに対して、ソース限定型マルチキャストへの参加要求の場合はマルチキャスト送信サーバ130のアドレスとマルチキャストグループアドレスのペアが端末100から広告される。このためソース限定型マルチキャストの場合には、指定されたマルチキャスト送信サーバ130からのトラフィックしかマルチキャストクライアント端末100に到達しないようにネットワーク120で経路制御を行うことが出来る。指定されていないマルチキャスト送信サーバ131からの同じマルチキャストアドレスへのトラフィックは、ソース非限定型マルチキャストではマルチキャスト送信サーバ130からと同じようにマルチキャストクライアント端末100へ到達する。一方ソース限定型マルチキャストでは、送信元サーバ131からのマルチキャストパケットの中継方法がネットワーク120内に存在しないために、送信元サーバが異なれば同じマルチキャストアドレスでもトラフィックが要求元には到達しないように経路制御されるからである。

ソース限定型マルチキャストを実現するためにはマルチキャストクライアント端末100とマルチキャストルータ110との間の通信、マルチキャストルータ110と隣接するマルチキャストルータ122との間の通信の両方において、送信元サーバをマルチキャストグループアドレスと共に広告する必要があるが、後者のルータ間の通信については既存のマルチキャスト制御プロトコルPIM-SM(Protocol Independent Multicast Sparse Mode, IETF RFC2362にて規定される)によって送信元サーバの情報をやりとりすることができる。前者の端末とマルチキャストルータ間の通信についてはマルチキャストグループ管理プロトコルが用いられるが、従来の技術の節にて説明したように必ずしも全ての端末が送信元サーバアドレスを通知できるマルチキャストグループ管理プロトコルを実装しているわけではない。そのためソース限定型マルチキャストを実現するためには、端末、マルチキャストルータ間のマルチキャストグループ管理方法が課題となるのである。

端末、マルチキャストルータ間のマルチキャストグループ管理に用いられるIGMPv2やMLDv1では、参加要求(Join)、参加問い合わせ(Query)、離脱要求(Leave)の3種類のパケットが定義されてい、それぞれが上述の要領で用いられている。よってこれら3種類のソース非限定型マルチキャストグループ管理パケットを、ソース限定型マルチキャストの対応するパケットに変換できれば十分である。以下これら3種類のパケットの変換方法について説明する。

図2を用いてソース非限定型マルチキャスト参加要求(Join)並びに離脱要求(Leave)をソース限定型マルチキャストに変換する方法を説明する。マルチキャスト送信元管理表220はマルチキャストグループアドレス欄222、マルチキャスト参加離脱要求発生元欄223、マルチキャスト送信元サーバアドレス欄224の3つ組の対応を管理する。本実施例ではルータ管理者が予めマルチキャスト送信元表220の中身を然るべき内容に埋めてあることを想定している。

図3に基づいて、マルチキャストルータ110のマルチキャストグループ管理パケット変換部210が回線116からのソース非限定型マルチキャスト参加要求をソース限定型に変換する方法を説明する。端末100からのマルチキャスト参加要求を受信すると(ステップ300)、マルチキャストグループ管理パケット変換部210はその要求がソース限定型マルチキャスト参加要求かソース非限定型マルチキャスト参加要求かを判断する(ステップ310)。IPv4のIGMPやIPv6のMLDの場合、具体的にはそのパケット長を基に識別可能である。ソース限定型の場合マルチキャストグループ管理パケット変換部210は、そのソース限定型マルチキャスト参加要求をそのままマルチキャストグループ管理パケット処理部114へ送信する(ステップ350)。ソース限定型でない場合、マルチキャストグループ管理パケット変換部210は、そのマルチキャスト参加要求のソースアドレスすなわち端末100のアドレスとマルチキャスト参加要求に含まれるマルチキャストグループアドレスの組が、マルチキャストグループ管理パケット発生元欄223及びマルチキャストグループアドレス欄222の両方にマッチするエントリがマルチキャスト送信元管理表220にあるかどうかを調べる(ステップ330)。エントリがない場合はそのマルチキャストへの参加要求はネットワーク管理者から拒否されたことを意味するので、マルチキャストグループ管理パケット変換部210は、参加要求を無視する(ステップ340)。エントリがあった場合には、マルチキャストグループ管理パケット変換部210は算出された送信元サーバの内容をチェックする。内容が"don't care"だった場合は、そのマルチキャストグループ参加要求はソース非限定型として処理されるべきなので、そのままマルチキャストグループ管理パケット処理部114へ渡される(ステップ360)。それ以外の場合は、ステップ330で検出したソースアドレスからのマルチキャストへの参加要求をマルチキャストグループ管理パケット処理部114に渡す(ステップ370)。
上と全く同じ方法で、マルチキャストルータ110のマルチキャストグループ管理パケット変換114は回線116からのソース非限定型マルチキャスト離脱要求をソース限定型に変換する。

図4に基づいて、マルチキャストルータ110のマルチキャストグループ管理パケット変換部210が、マルチキャスト経路制御部112からのソース限定型マルチキャスト参加問合せ(Query)をソース非限定型に変換する方法を説明する。 マルチキャスト経路制御部112からの回線116に対するマルチキャスト参加問合せをマルチキャストグループ管理パケット処理部114経由で受信すると(ステップ400)、マルチキャストグループ管理パケット変換部210はその問合わせがソース限定型マルチキャスト参加問合わせかソース非限定型マルチキャスト参加問合せかを判断する(ステップ410)。ソース非限定型の場合はマルチキャストグループ管理パケット変換処理部210は、そのマルチキャスト参加問合わせをそのまま指定された回線116に送信する(ステップ420)。ソース限定型の場合はその問合せに含まれるマルチキャストアドレス、問合せを送る先の回線116のアドレスに、マルチキャストグループアドレス欄222、マルチキャストグループ管理パケット発生元欄223がそれぞれ合致するエントリがマルチキャスト送信元管理表220に含まれているかどうかを調べる(ステップ430)。該当するエントリが存在しない場合は、そのマルチキャストグループはネットワーク管理者により運用を拒否されたことを意味するので、マルチキャストグループ管理パケット変換部210は参加問合せを送信しない(ステップ440)。エントリが存在する場合は、このエントリの送信元サーバ欄224のアドレスがそのソース限定型マルチキャスト参加問い合わせの中のソースアドレスを含むか否かを確認する(ステップ450)。含まれない場合には、そのマルチキャストへの参加要求はネットワーク管理者から拒否されたことを意味するので、マルチキャスト参加離脱管理部は問合せを送信しない(ステップ440)。含まれている場合にはその送信元アドレスはネットワーク管理者の認めたものであることになるので、マルチキャストグループ管理パケット変換部210は問合せに含まれるマルチキャストアドレスへのソース非限定型の問合せを回線116に送信すればよい(ステップ460)。

尚本発明ではマルチキャストルータ110のマルチキャストグループ管理パケット処理部114においてソース非限定型マルチキャストグループ管理パケットをソース限定型マルチキャストグループ管理パケットに変換している。そのためマルチキャストルータ110のマルチキャスト経路制御部112においては、ソース限定型マルチキャストをサポートしている端末が回線116に存在しているかのように見えるだけである。よってマルチキャストルータ110と隣接マルチキャストルータ122との間とでの経路制御については本発明によって何ら変更の必要がない。そのため本発明にて変更が必要なのはマルチキャストネットワーク120において端末100を収容するマルチキャストルータ110のみである。

本発明では、ユーザが任意のマルチキャスト送信元サーバを選ぶことができない。その点ではソース非限定マルチキャスト端末を完全にソース限定型マルチキャストに対応させる変換技術にはなっていない。しかしながら従来技術の節でも述べたように、ソース限定型マルチキャストはストリーミングのように数少ないサーバからのマルチキャスト通信を対象にしたものであること及びストリーミングサーバは一般にネットワーク管理者が運営するものであることから、実運用上の問題は少ないと考えられる。

本発明は上記実施例の形以外でも実現可能であることを、以下図5、図6および図7を用いて説明する。

上記実施例ではマルチキャストグループ管理パケット処理部114の機能をマルチキャストルータ110の中に組み込んでいる。図5はマルチキャストグループ管理パケット処理部114の機能を外に出した実施例である。この場合、マルチキャストグループ管理パケット変換装置500は、マルチキャストグループ管理パケット以外のパケットについては端末100とマルチキャストルータ110の間でそのままパケットを通過させる。マルチキャスト管理パケットが回線501または502から入力された場合は、マルチキャストグループ管理パケット変換部210でそのパケットを以下の処理によって変換した後に、それぞれ回線502または501へ出力する。すなわち図3の処理によりマルチキャスト参加要求パケット及び離脱要求パケットをソース限定マルチキャスト対応版に変換し、マルチキャストルータ110から入力されたマルチキャスト参加離脱問い合わせパケットを図4の処理によりソース非限定マルチキャスト対応版に変換する、プロトコル変換装置として機能することになる。

図2並びに図5の実施例ではマルチキャストルータ110の中にマルチキャスト送信元管理表220が存在することを前提にしている。図6ではマルチキャスト送信元管理表をマルチキャストルータ110から分離した実施例を紹介する。図3及び4の処理にて表220の検索処理を行うとき図2並びに図5の実施例では内部テーブルを引いているが、図6ではマルチキャストルータ110からマルチキャスト送信元管理サーバ600へネットワーク経由で問い合わせを行うことにより同様な検索を実現している。これにより、各マルチキャストルータのマルチキャスト送信元管理表を一括管理することも可能である。この場合は各マルチキャストルータがこのサーバに対して問い合わせを行うことにより、上で記述したマルチキャスト送信元管理表220の検索処理を行う。問い合わせに用いる通信プロトコルとしては、Radius(RFC2865)などの既存のネットワークデータベース検索プロトコルを利用すれば十分である。図 7はマルチキャスト送信元管理表をユーザからのリクエストにより自動更新する実現例の 全体図である。図2、図5および図6の実施例ではマルチキャスト送信元管理表220はネットワーク管理者が別途入力することを仮定しているが、図7のように本発明を実現することによりマルチキャスト送信元管理表220の設定を半自動化することも可能である。一般に有償コンテンツをマルチキャスト配信するケースでは、ユーザとの有償コンテンツの利用契約を契約管理サーバ700によって管理する必要がある。契約管理サーバ700で管理する契約台帳710にユーザネットワーク情報711、契約しているセッション(=送信元サーバとマルチキャストグループアドレスの組)712とを含ませ、その内容をマルチキャスト送信元管理サーバ600へネットワーク経由で反映させることによって、ユーザからのリクエストによってマルチキャスト送信元管理表220の内容を自動的に追加削除することも可能である。契約管理サーバ700からマルチキャスト送信元管理サーバ600への通信に用いるプロトコルとしては、マルチキャスト送信元管理表220の不法な更新を防ぐようなセキュリティ機能を有するHTTPSなどの既存のプロトコルを用いれば十分である。

100 マルチキャストクライアント端末
110 マルチキャストルータ
112 マルチキャスト経路制御部
114 マルチキャストグループ管理パケット処理部
116 マルチキャストルータ回線
120 ネットワーク
122 マルチキャストルータ
130 マルチキャスト送信サーバ
131 マルチキャスト送信サーバ
210 マルチキャストグループ管理パケット変換部
220 マルチキャスト送信元管理表
222 マルチキャストアドレス欄
223 マルチキャストグループ管理パケット発生元欄
224 マルチキャスト送信元サーバアドレス欄
500 マルチキャストグループ管理パケット変換装置
600 マルチキャスト送信元管理サーバ
700 契約管理サーバ。

Claims (1)

1. マルチキャストクライアント端末を収容するパケット中継装置であって、
   マルチキャスト送信元を指定できないマルチキャストクライアント端末からのマルチキャストグループへの参加または離脱要求を、マルチキャスト送信元を指定したマルチキャストグループへの参加または離脱要求に変換して処理するパケット中継装置。

Images