JP2024003368A

JP2024003368A - ルータ

Info

Publication number: JP2024003368A
Application number: JP2022102457A
Authority: JP
Inventors: 智史小山; Satoshi Koyama; 卓也倉掛; Takuya Kurakake
Original assignee: Nippon Hoso Kyokai NHK; Japan Broadcasting Corp
Current assignee: Japan Broadcasting Corp
Priority date: 2022-06-27
Filing date: 2022-06-27
Publication date: 2024-01-15

Abstract

【課題】マルチキャストトラフィックの無駄な転送を自動的に防ぐ機能を少ないメモリ量で実現する。【解決手段】ルータ１０は、複数の送受信部１１と、ルータ処理部１２と、マルチキャストグループへの参加要求または離脱要求を内容とするグループメッセージを監視し、受信メッセージに応じて、マルチキャストフローを受信するノードの情報を管理テーブル１５に保存するIGMP監視部１４と、グループメッセージを処理するIGMP処理部１３と、を備え、IGMP監視部１４は、マルチキャストグループ毎に、且つ、送受信部１１毎に、最初に参加要求を内容とするグループメッセージを送信したノードの識別子と、マルチキャストグループ内に複数の受信ノードが存在するか否かを示す複数受信ノード存在フラグを管理テーブル１５に保存し、グループメッセージの受信時に複数受信ノード存在フラグに応じてメッセージまたは転送停止指示をIGMP処理部１３に出力する。【選択図】図１

Description

本発明は、ルータに係り、特に、IP（Internet Protocol）ネットワークのルータに関する。

IPマルチキャストは、ノード（送信装置）から送信された1つのIPフローをネットワークスイッチの内部で複製し、受信を要求するノード（受信装置）に効率よく配信する技術である。あるマルチキャストフローの受信を行うノード（受信装置）は、IPv4システムではIGMP（非特許文献１、２参照）を用いて、また、IPv6システムではMLD（非特許文献３、４参照）を用いて、ルータに受信要求および受信停止を伝える。
IGMPv2（IGMP Version 2）とMLDv1（MLD：MLD Version 1）、IGMPv3（IGMP Version 3）とMLDv2（MLD Version 2）は、それぞれ動作するプロトコルがIPv4（Internet Protocol version 4）とIPv6（Internet Protocol version 6）であるという違いの他は、ほぼ同一のため、以下ではIGMPを用いて、従来のルータによる処理の概略を説明する。

マルチキャストフローを受信しようとする受信装置は、受信を開始するときに、IGMPメンバーシップレポート（JOINメッセージ）を受信装置からルータに向けて送信する。JOINメッセージを受信したルータは、要求されたマルチキャストフローを、JOINメッセージを受信したL2（layer 2）ネットワークへ転送する。

ルータは、転送処理中のマルチキャストフローを受信する受信装置が存在しているか確認するため、定期的にIGMPメンバーシップクエリを送信する。このメンバーシップクエリを受信したノード（受信装置）は、メンバーシップレポートを送信して、ルータにマルチキャストフローの受信装置が存在していることを通知する。メンバーシップクエリがネットワークの帯域を圧迫することを抑制するため、他の受信装置がメンバーシップレポートを送信したことを検知した受信装置はメンバーシップレポートを送信しない。

受信装置は、マルチキャストフローの受信を停止する際にはIGMPリーブグループメッセージを送信し、ルータに受信の停止を伝える。リーブグループメッセージを受信したルータは、他にマルチキャストフローの受信装置が存在するかチェックするため、IGMPメンバーシップクエリを送信し、IGMPメンバーシップレポートを受信できなかった場合、マルチキャストフローの転送を停止する。

特許第４７７５７１６号公報

W. Fenner、「Internet Group Management Protocol, Version 2」、［online］、IETF RFC 2236, Nov. 1997、［2022年5月19日検索］、インターネット〈URL：https://datatracker.ietf.org/doc/html/rfc2236〉 B. Cain、他、「Internet Group management Protocol, Version 3」、［online］、IETF RFC 3376, Oct. 2002、［2022年5月19日検索］、インターネット〈https://datatracker.ietf.org/doc/html/rfc3376〉 S. Deering、他、「Multicast Listener Discovery (MLD) for IPv6」、［online］、IETF RFC 2710, Oct. 1999、［2022年5月19日検索］、インターネット〈https://datatracker.ietf.org/doc/html/rfc2710〉 R. Vida、他、「Multicast Listener Discovery Version 2 (MLDv2) for IPv6」、［online］、IETF RFC 3810, Jun. 2004、［2022年5月19日検索］、インターネット〈https://datatracker.ietf.org/doc/html/rfc3810〉

受信装置がマルチキャストフローの受信停止を要求してから、つまり、IGMPリーブグループメッセージを送信してから、ルータによりメンバーシップレポートの受信確認が完了するまでの間、他にマルチキャストフローの受信装置がない場合でもマルチキャストフローは転送され続ける。例えば、テレビ番組制作で、複数の映像を切り替えるビデオスイッチャ（ノード）が受信する映像を切り替える場合には、あるマルチキャストフローの受信停止と次のマルチキャストフローの受信開始（受信要求）とを連続して行う。そのため、停止したマルチキャストフローが実際には転送されるとネットワークに負荷がかかり、余裕を持った帯域設計が必要となる。

予めルータに設定を行うことで、IGMPリーブグループメッセージを受信すると即座に、マルチキャストフローの転送を停止することができるルータも存在する。しかし、そのような設定を行うと、他にマルチキャストフローの受信装置が存在する場合にもマルチキャストフローの転送が停止されてしまう。予め設定するのではなく、その時の状況に応じて、マルチキャストフローの転送が即座に、または、他にマルチキャストフローの受信装置がないことを確認した上で停止されることが望ましい。

特許文献1に記載された従来の中継装置は、IGMPメンバーシップレポートを受信すると、レポート送信元のMACアドレスと、受信を要求しているマルチキャストグループとを紐づけて記録を行う。また、この中継装置は、IGMPリーブグループメッセージを受信した場合には、受信停止を要求しているマルチキャストグループに紐づいたレポート送信元のMACアドレスが１つである場合には、転送を即座に停止する。

しかしながら、この従来の中継装置は、IGMPメンバーシップレポートを送信してくるMACアドレスを全て記録する。この従来技術では、多くの受信装置が１つの同じマルチキャストグループでマルチキャストフローを受信することがあるため、多くのメモリが必要である。そのため、マルチキャストトラフィックの無駄な転送をより少ないメモリ量で実現することが望まれている。

本発明は、以上のような問題点に鑑みてなされたものであり、マルチキャストトラフィックの無駄な転送を自動的に防ぐ機能を少ないメモリ量で実現するルータを提供することを課題とする。

前記課題を解決するために、本発明に係るルータは、ネットワークの所定のノードとの間でIPパケットを送受信する複数の送受信部と、前記送受信部によって受信したマルチキャストフローをマルチキャストルーティングテーブルに応じて宛先の受信ノードに転送する処理を行うルータ処理部と、前記送受信部によって受信したメッセージであってマルチキャストグループへの参加要求またはマルチキャストグループからの離脱要求を内容とするグループメッセージを監視し、受信したグループメッセージに応じて、マルチキャストフローを受信するノードの情報を管理テーブルに保存するグループメッセージ監視部と、前記グループメッセージを処理するグループメッセージ処理部と、を備え、前記グループメッセージ監視部は、マルチキャストグループ毎に、且つ、前記送受信部毎に、最初に参加要求を内容とするグループメッセージを送信したノードの識別子と、マルチキャストグループ内に複数の受信ノードが存在するか否かを示す複数受信ノード存在フラグを前記管理テーブルに保存し、前記グループメッセージの受信時に前記複数受信ノード存在フラグに応じて、前記グループメッセージまたはマルチキャストフローの転送停止指示を前記グループメッセージ処理部に出力することとした。

本発明は、以下に示す優れた効果を奏するものである。
本発明に係るルータは、マルチキャストグループに２回目以降に参加要求を内容とするグループメッセージを送信したノードについて管理テーブルに個別の情報を記録せずに、フラグで管理することができる。したがって、ルータは、マルチキャストトラフィックの無駄な転送を自動的に防ぐ機能を少ないメモリ量で実現することができる。

本発明の実施形態に係るルータの構成を示すブロック図である。図１のルータに保存される管理テーブルの一例である。 IGMP監視部の処理の流れを示すフローチャートである（IGMPメンバーシップレポート受信時）。 IGMP監視部の処理の流れを示すフローチャートである（IGMPリーブグループメッセージ受信時）。ルータ内の各部で行う処理の流れを示すシーケンス図である（IGMPリーブグループメッセージ受信時）。本発明の実施形態に係るルータを含むシステムの構成例である。

本発明の実施形態に係るルータについて図面を参照して説明する。本実施形態では、ルータが送受信するグループメッセージは、IGMP（Internet Group Management Protocol）に従ったメッセージであるものとして説明する。図１に示すように、ルータ１０は、複数の送受信部１１と、ルータ処理部１２と、IGMP処理部（グループメッセージ処理部）１３と、IGMP監視部（グループメッセージ監視部）１４と、を備えている。
送受信部１１は、ネットワークの所定のノードとの間でIPパケットを送受信する。
ルータ処理部１２は、送受信部１１によって受信したマルチキャストフローをマルチキャストルーティングテーブルに応じて宛先の受信ノードに転送する処理を行う。
IGMP監視部１４は、グループメッセージを監視し、受信したグループメッセージに応じて、マルチキャストフローを受信するノードの情報を管理テーブル１５に保存する。IGMP処理部１３は、受信したグループメッセージを処理する。グループメッセージは、送受信部１１によって受信したメッセージであってマルチキャストグループへの参加要求またはマルチキャストグループからの離脱要求を内容とするものである。
IGMP監視部１４は、マルチキャストグループ毎に、且つ、送受信部１１毎に、最初に参加要求を内容とするグループメッセージを送信したノードの識別子と、マルチキャストグループ内に複数の受信ノードが存在するか否かを示す複数受信ノード存在フラグを管理テーブル１５に保存する。IGMP監視部１４は、グループメッセージの受信時に複数受信ノード存在フラグに応じて、当該グループメッセージまたはマルチキャストフローの転送停止指示をIGMP処理部１３に出力する。

本実施形態では、グループメッセージとは、IGMPメンバーシップレポートやIGMPリーブグループメッセージを指す。IGMPメンバーシップレポートやIGMPリーブグループメッセージをIGMPメッセージとも呼ぶ。複数受信ノード存在フラグを単にフラグと呼称する場合もある。マルチキャストルーティングテーブルを単にルーティングテーブルと呼称する場合もある。以下、ルータ１０の各部の構成を説明する。

送受信部１１は、ルータのポートである。各送受信部１１は、ルータ処理部１２およびIGMP監視部１４にそれぞれ接続されている。ルータ１０は、例えばN個の送受信部１１を備え、それぞれ、1，2，…，N-1，Nの番号で識別される。送受信部<1>にはノード２０ａが接続され、送受信部<2>にはL2スイッチ２１を介してノード２０ｂおよびノード２０ｃが接続される。送受信部<N-1>にはノードが接続されておらず、送受信部<N>にはノード２０Ｎが接続されている。ノードを区別しない場合、ノード２０と表記する。

所定の送受信部１１は、ネットワークの所定のノード２０からマルチキャストフローを受信する。ルータ１０内部で複製されたマルチキャストフローは、複数の他の送受信部１１から、ネットワークの他のノード２０に送信される。例えばノード２０ａがIPフローの送信装置となり、ノード２０ｂ、ノード２０ｃおよびノード２０Ｎがマルチキャストフローの受信装置となる場合、送受信部<1>は、受信ポートとなり、送受信部<2>や送受信部<N>は送信ポートとなる。

また、送受信部１１は、ネットワークの所定のノード２０から各種メッセージを受信する。各種メッセージは、IGMPメンバーシップレポートやIGMPリーブグループメッセージの他、クエリメッセージ等を含む。また、送受信部１１は、IGMPメッセージを受信すると、IGMPメッセージをIGMP監視部１４に出力する。送受信部１１は、IGMPメッセージ以外のパケットを受信すると、これらのパケットをルータ処理部１２に出力する。ルータ処理部１２は、一般的なマルチキャスト対応ルータの機能を提供するものである。

IGMP処理部１３は、IGMPの処理とマルチキャストルーティングテーブルの更新制御を行う。IGMP処理部１３は、IGMP監視部１４からIGMPメンバーシップレポートメッセージを受信すると、IGMPメンバーシップレポートを処理する。このとき、IGMP処理部１３は、必要に応じて、マルチキャストルーティングテーブルの更新制御を行う。
IGMP処理部１３は、IGMP監視部１４からIGMPリーブグループメッセージを受信すると、IGMPリーブグループメッセージを処理する。このとき、IGMP処理部１３は、該当マルチキャストグループにIGMPメンバーシップクエリを送信し、一定時間内にIGMPメンバーシップレポートを受信できない場合にマルチキャストフローの転送を停止する。
IGMP処理部１３は、IGMP監視部１４から即時転送停止指示を受信すると、即座にマルチキャストフローの転送を停止する。
IGMP処理部１３は、マルチキャストフローの転送を停止するとき、ルータ処理部１２に対してマルチキャストルーティングテーブルの該当エントリの削除更新を指示する。

IGMP処理部１３は、IGMP監視部１４から、マルチキャストの即時転送停止指示を受信すると、停止対象のマルチキャストグループに関する処理を中止する。IGMP処理部１３は、この転送停止指示で指定されたマルチキャストグループのエントリをルーティングテーブルから削除する更新指示をルータ処理部１２に出力する。ルータ処理部１２がマルチキャストルーティングテーブルからエントリの削除を行った場合、すなわち、マルチキャストの転送を停止する更新を行った場合、IGMP処理部１３は、その内容をIGMP監視部１４に出力する。IGMP監視部１４は、IGMP処理部１３から、ルーティングテーブルの更新通知を受領した後に、管理テーブル１５から、当該マルチキャストグループのエントリを削除する。

IGMP監視部１４は、IGMPメンバーシップレポートの受信やIGMPリーブグループメッセージの受信に応じて、管理テーブル１５を更新する。図２に示す管理テーブル１５は、マルチキャスト受信ノード管理テーブルである。管理テーブル１５は、項目として、例えば、送受信部番号１５１と、マルチキャストグループ１５２と、送信元IPアドレス１５３と、ノード識別子１５４と、複数受信ノード存在フラグ１５５と、を備えている。

送受信部番号１５１は、ルータ１０の複数の送受信部１１を識別する識別子である。ここでは、送受信部１１の個数に対応した番号で識別しているが、これに限定されるものではない。マルチキャストグループ１５２は、グループ固有の識別子であり、IPマルチキャストグループアドレスを示す。送信元IPアドレス１５３は、IPパケット（マルチキャストフロー）の送信装置の識別子であり、送信装置のIPアドレスである。ノード識別子１５４は、IGMPメッセージを送信したノードの識別子である。ノード識別子として、例えば、IGMPメンバーシップレポートの送信元MACアドレス、または、送信元IPアドレスが利用できる。管理テーブル１５においてノード識別子１５４の項目については、送受信部毎に、かつ、マルチキャストグループ毎に、最初にJOINメッセージを送信してきたノードの識別子が記録される。

複数受信ノード存在フラグ１５５は、同じ送受信部１１に接続されたノードを含むマルチキャストグループに、複数の受信ノードが存在していれば真であり、そうでなければ偽となる。例えば、送受信部番号が「1」であり、かつ、マルチキャストグループが「232.0.0.1」である第１のエントリにおいて、複数受信ノード存在フラグ１５５は「真」である。また、送受信部番号が「2」であり、かつ、マルチキャストグループが「232.0.0.1」である第２のエントリにおいて、複数受信ノード存在フラグ１５５は「偽」である。これら第１のエントリと第２のエントリとは、マルチキャストグループ１５２のレコードは同一であるが、送信元IPアドレス１５３およびノード識別子１５４のレコードが相違する。
なお、図２に示す管理テーブル１５のレコードは、ある時点における一例である。

IGMP監視部１４は、IGMPメンバーシップレポートを送信したノードの情報に一致するエントリが管理テーブル１５に存在しない場合、管理テーブル１５において、当該IGMPメンバーシップレポートを送信したノードの識別子とフラグを偽とした値を有する新しいエントリを追加する。
IGMP監視部１４は、IGMPメンバーシップレポートを送信したノードの情報に一致し、かつ、フラグが偽であるエントリが管理テーブル１５に保存され、かつ保存されたエントリにおけるノードの識別子がIGMPメンバーシップレポートを送信したノードの識別子と異なる場合、フラグを真とする。IGMP監視部１４は、フラグのレコードが偽であった場合、真に置き換え、また、フラグのレコードが真であった場合、その値を維持する。

IGMP監視部１４は、IGMPリーブグループメッセージを送信したノードの情報に一致するエントリが管理テーブル１５に存在しない場合、IGMPリーブグループメッセージで指定されたマルチキャストグループの転送停止指示をIGMP処理部１３に出力する。

IGMP監視部１４は、IGMPリーブグループメッセージを送信したノードの情報に一致し、かつ、フラグが偽であるエントリが管理テーブル１５に保存され、かつ保存されたエントリにおけるノードの識別子がIGMPリーブグループメッセージを送信したノードの識別子に一致する場合、IGMPリーブグループメッセージで指定されたマルチキャストグループの転送停止指示をIGMP処理部１３に出力する。

上記した構成により、ルータ１０は、予め設定を行うことなく、ネットワークの状態に合わせて、あるマルチキャストフローの受信ノードが1つの場合に、受信ノードが受信を停止する際に即座に当該ルータからの転送を停止し無駄な帯域を消費することを防ぐことができる。また、ルータ１０は、ポート（送受信部１１）ごとに、各マルチキャストグループについて、最初にJOINメッセージ（IGMPメンバーシップレポート）を送信してきたデバイスの情報と、そのデバイス以外の受信装置からのJOINメッセージを受信したかどうかを表すフラグ（複数受信装置存在フラグ）を記録する管理テーブル１５を有している。これにより、多くの受信装置が１つの同じマルチキャストグループでマルチキャストフローを受信することがあったとしても、従来技術のように多くのメモリを必要とすることはない。そのため、ルータ１０は、マルチキャストトラフィックの無駄な転送をより少ないメモリ量で実現することができる。

［ルータの動作］
次に、ルータ１０の動作について説明する。
＜IGMPメンバーシップレポート受信時の処理＞
まず、IGMPメンバーシップレポートを受信したときにIGMP監視部１４が行う処理の流れについて図３を参照して説明する。この場合、IGMP監視部１４は、送受信部番号と、IGMPメンバーシップレポート内のマルチキャストグループアドレスおよびマルチキャスト送信元IPアドレスと、に一致するエントリが、管理テーブル１５に存在するかどうかを確認する（ステップＳ３１）。ここで、IGMPメンバーシップレポートに、マルチキャスト送信元IPアドレスが指定されていない場合、マルチキャスト送信元IPアドレスが指定されていないことを示す値（例えば0）を用いる。

前記ステップＳ３１において、IGMPメンバーシップレポートの情報に一致するエントリが管理テーブル１５に存在しない場合（ステップＳ３１：Ｎｏ）、IGMP監視部１４は、新しいエントリを管理テーブル１５に追加する（ステップＳ３２）。新しいエントリは、確認に用いた送受信部番号、マルチキャストグループアドレス、マルチキャスト送信元IPアドレス、IGMPメンバーシップレポートを送信したノードのノード識別子、複数受信ノード存在フラグを偽とした値によるエントリである。

具体的には、図２の管理テーブル１５において、送受信部番号=1、マルチキャストグループアドレス=239.1.1.1、マルチキャスト送信元ＩＰアドレス=0(なし)、IGMPメンバーシップレポートを送信したノードのノード識別子=00:00:5e:00:53:ff、複数受信ノード存在フラグ=偽、とした値によるエントリは、ステップＳ３２で追加された例である。

ステップＳ３２に続いて、IGMP監視部１４は、受信したIGMPメンバーシップレポートをIGMP処理部１３に出力し（ステップＳ３３）、IGMPメンバーシップレポート受信時の処理を終了する。なお、IGMP処理部１３は、受け取ったIGMPメンバーシップレポートを処理する。

一方、前記ステップＳ３１において、一致するエントリが存在し（ステップＳ３１：Ｙｅｓ）かつ、複数受信ノード存在フラグが偽である場合（ステップＳ３４：Ｙｅｓ）、IGMP監視部１４は、対象エントリのノード識別子がIGMPメンバーシップレポートの送信ノードのノード識別子と異なるか否か判別する（ステップＳ３５）。ここで、対象エントリのノード識別子とは、当該送受信部番号かつ当該マルチキャストグループに最初にJOINメッセージを送信してきたデバイスのノード識別子である。ノード識別子が互いに異なる場合（ステップＳ３５：Ｙｅｓ）、IGMP監視部１４は、対象エントリの複数受信ノード存在フラグを真として（ステップＳ３６）、ステップＳ３３に進む。なお、ステップＳ３６では、IGMP監視部１４は、対象エントリの複数受信ノード存在フラグのレコードを偽から真に置き換える。

前記ステップＳ３５の判別処理においてＮｏである場合、すなわち、対象エントリのノード識別子がIGMPメンバーシップレポートの送信ノードのノード識別子に一致する場合、IGMP監視部１４は、ステップＳ３３に進む。なお、この場合、IGMP監視部１４は、対象エントリの複数受信ノード存在フラグのレコードが偽であるので、その値を維持する。
前記ステップＳ３４の判別処理においてＮｏである場合、すなわち、IGMPメンバーシップレポートの情報に一致するエントリが管理テーブル１５に存在し、その複数受信ノード存在フラグが真である場合、IGMP監視部１４は、ステップＳ３３に進む。なお、この場合、IGMP監視部１４は、対象エントリの複数受信ノード存在フラグのレコードが真であるので、その値を維持する。

＜IGMPリーブグループメッセージ受信時の処理＞
次に、IGMPリーブグループメッセージを受信したときにIGMP監視部１４が行う処理の流れについて図４を参照して説明する。この場合、IGMP監視部１４は、送受信部番号と、IGMPリーブグループメッセージ内のマルチキャストグループアドレスおよびマルチキャスト送信元IPアドレスと、に一致するエントリが、管理テーブル１５に存在するかどうかを確認する（ステップＳ４１）。IGMPリーブグループメッセージの情報に一致するエントリが管理テーブル１５に存在しない場合（ステップＳ４１：Ｎｏ）、IGMP監視部１４は、マルチキャストグループアドレスで指定されたマルチキャストグループの即時転送停止指示をIGMP処理部１３に出力し（ステップＳ４２）、IGMPリーブグループメッセージ受信時の処理を終了する。なお、即時転送停止指示を受けたIGMP処理部１３の処理については後記する。

前記ステップＳ４１において、IGMPリーブグループメッセージの情報に一致するエントリが管理テーブル１５に存在する場合（ステップＳ４１：Ｙｅｓ）、IGMP監視部１４は、対象エントリの複数受信ノード存在フラグが偽であるか否かを判別する（ステップＳ４３）。複数受信ノード存在フラグが偽である場合（ステップＳ４３：Ｙｅｓ）、IGMP監視部１４は、対象エントリのノード識別子がIGMPリーブグループメッセージの送信ノードのノード識別子と異なるか否か判別する（ステップＳ４４）。ここで、対象エントリのノード識別子とは、当該送受信部番号かつ当該マルチキャストグループに最初にJOINメッセージを送信してきたデバイスのノード識別子である。

前記ステップＳ４４において、ノード識別子が一致した場合（ステップＳ４４：Ｎｏ）、IGMP監視部１４は、ステップＳ４２に進み、マルチキャストグループアドレスで指定されたマルチキャストグループの即時転送停止指示をIGMP処理部１３に出力する。
一方、前記ステップＳ４４において、ノード識別子が互いに異なる場合（ステップＳ４４：Ｙｅｓ）、IGMP監視部１４は、IGMPリーブグループメッセージをIGMP処理部１３に出力し（ステップＳ４５）、IGMPリーブグループメッセージの処理をIGMP処理部１３に任せる。IGMP処理部１３は、IGMPリーブグループメッセージを従来と同様に処理する。
また、前記ステップＳ４３の判別処理においてＮｏである場合、すなわち、IGMPリーブグループメッセージの情報に一致するエントリが管理テーブル１５に存在し、かつ、その複数受信ノード存在フラグが真である場合、IGMP監視部１４は、IGMPリーブグループメッセージをIGMP処理部１３に出力し（ステップＳ４５）、IGMPリーブグループメッセージの処理をIGMP処理部１３に任せる。なお、このように対象エントリの複数受信ノード存在フラグのレコードが真である場合、IGMP処理部１３は、IGMPリーブグループメッセージを従来と同様に処理する。

＜即時転送停止の処理＞
次に、即時転送停止を行うときにルータ１０内の各部で行う処理の流れについて図５を参照（適宜図４参照）して説明する。この場合、まず、IGMP監視部１４が、マルチキャストの即時転送停止指示をIGMP処理部１３に出力する（ステップＳ４２：図４）。そして、IGMP処理部１３は、マルチキャストの即時転送停止指示を受信すると（ステップＳ４２１）、停止対象のマルチキャストグループに関する処理を中止する（ステップＳ４２２）。そして、IGMP処理部１３は、ルータ処理部１２に対して、ルーティングテーブルから該当のエントリを削除する更新指示を出力する（ステップＳ４２３）。

ルータ処理部１２は、ルーティングテーブルからエントリを削除する更新指示を受信すると（ステップＳ４２４）、ルーティングテーブルから、該当のエントリを削除する（ステップＳ４２５）。一方、IGMP処理部１３は、IGMP監視部１４に対して、ルーティングテーブルの更新通知を出力する（ステップＳ４２６）。そして、IGMP監視部１４は、ルーティングテーブルの更新通知を受信すると（ステップＳ４２７）、管理テーブル１５からマルチキャストグループのエントリを削除する（ステップＳ４２８）。このように、ルータ１０では、ルータ処理部１２がルーティングテーブルにおいてマルチキャストの即時転送停止の対象エントリを削除するのにあわせて、IGMP監視部１４は、管理テーブル１５においてマルチキャストの即時転送停止の対象エントリを削除する。

［システムの構成例］
次に、ルータを含むシステムの構成例について図６を参照して説明する。図６に示すように、システム１００は、IPマルチキャストを用いる番組制作システムであって、例えば放送局のスタジオ内に、２台のルータ１０ａ，１０ｂと、１０台のノード２０と、を備えている。ルータ１０ａは、ルータ1であり、ルータ１０ｂは、ルータ2である。

ルータ１０ａは、例えば３個の送受信部（ポート）を備えている。このうち、１個の送受信部には、L2スイッチ２１ａを介して３つのノード（ノード２０ａ、ノード２０ｃおよびノード２０ｅが通信可能に接続されている。また、ルータ１０ａの他の送受信部には、L2スイッチ２１ｂを介して３つのノード（ノード２０ｂ、ノード２０ｄおよびノード２０ｆ）が通信可能に接続されている。ノード２０ａは、カメラ1であり、ノード２０ｂは、カメラ2である。ノード２０ｃは、マイク1であり、ノード２０ｄは、マイク2である。ノード２０ｅは、モニタ1であり、ノード２０ｆは、モニタ2である。

ルータ１０ｂは、例えば５個の送受信部（ポート）を備えている。このうち、４個の送受信部には、それぞれ、１つのノード（ノード２０ｇ、ノード２０ｈ、ノード２０ｋおよびノード２０ｍ）が通信可能に接続されている。ノード２０ｇは、ビデオスイッチャであり、ノード２０ｈは、オーディオミキサである。ノード２０ｋは、モニタ3であり、ノード２０ｍは、モニタ4である。ルータ１０ａのもう１つの送受信部と、ルータ１０ｂのもう１つの送受信部とは、通信可能に接続されている。

システム１００において、例えば、ノード２０ａ（送信装置）から送信された1つのIPフローを、５台の受信ノード（ノード２０ｅ，２０ｆ，２０ｇ，２０ｋ，２０ｍ）に配信する場合について説明する。この例では、カメラ1で撮影した映像を、ビデオスイッチャと、モニタ1～モニタ4に配信する。比較として、ユニキャストにより映像を伝送するには、受信装置それぞれに対し、カメラ1で映像信号を複製して伝送する必要があるため、5本分の映像信号がカメラ1から出力されることになる。

一方、IPマルチキャストを用いる場合、映像信号はルータ１０で複製される。具体的には、カメラ1から、1本分の映像信号が出力され、ルータ1では、モニタ1、モニタ2、ルータ2に伝送するために映像信号が複製される。ルータ1は、第１の送受信部から映像信号をL2スイッチ２１ａを介してモニタ1に伝送し、また、第２の送受信部から映像信号をL2スイッチ２１ｂを介してモニタ2に伝送する。また、ルータ1の第３の送受信部から、1本分の映像信号が出力され、ルータ2に伝送される。
さらに、ルータ2では、モニタ3、モニタ4、ビデオスイッチャに伝送するために再び映像信号が複製される。番組制作システムでは、多数のモニタが、同じ信号を受信することがよくあるため、マルチキャストを利用することが一般的である。

本実施形態のルータ１０は、この例ではノード２０ａ（カメラ1）のIPアドレスを、図２の管理テーブル１５の送信元IPアドレス１５３の項目に記録する。また、ルータ１０は、５台の受信ノード（ノード２０ｅ，２０ｆ，２０ｇ，２０ｋ，２０ｍ）のうち、最初にJOINメッセージ（IGMPメンバーシップレポート）を送信してきたデバイスの情報を、管理テーブル１５のノード識別子１５４の項目に記録する。ルータ１０は、この記録時点では、複数受信ノード存在フラグ１５５の項目を、「偽」とする。ルータ１０は、次にJOINメッセージを送信してきたデバイスの情報を、管理テーブル１５の新たなエントリにすることなく、複数受信ノード存在フラグ１５５の項目を、「真」とする。ルータ１０は、３番目にJOINメッセージを送信してきたデバイスの情報を、管理テーブル１５の新たなエントリにすることなく、複数受信ノード存在フラグ１５５の項目を、「真」のまま維持する。ルータ１０は、４番目および５番目にJOINメッセージを送信してきたデバイスについては、３番目のデバイスのときと同様の処理をする。
なお、各デバイス（ノード）がマルチキャストグループから離脱する順番は任意である。グループ離脱時、ルータ１０は、管理テーブル１５のエントリにおいて複数受信ノード存在フラグが真となった段階で、そのエントリで示すマルチキャストグループについて、通常の処理を実行するようになる。ここで、通常の処理とは、IGMPリーブグループメッセージを受け取ると、受信確認を行ってから転送を終了する処理である。

従来技術の中継装置を用いた場合、メモリには、５台の受信ノードのために例えば５行のエントリデータが記録されるが、本実施形態のルータ１０の場合、メモリには、５台の受信ノードのために例えば１行のエントリデータが記録される。そのため、ルータ１０は、マルチキャストトラフィックの無駄な転送をより少ないメモリ量で実現することができる。

以上、本発明の実施形態に係るルータについて説明したが、本発明の趣旨はこれらの記載に限定されるものではなく、特許請求の範囲の記載に基づいて広く解釈されなければならない。また、これらの記載に基づいて種々変更、改変などしたものも本発明の趣旨に含まれることはいうまでもない。
例えば、ルータ１０を含むシステム１００のネットワークは、放送局のスタジオ内のネットワークに限らず、放送局内のネットワークや、放送局を超えたより広範なネットワークであってもよい。

また、グループメッセージは、IGMPに従うとして説明したが、MLD（Multicast Listener Discovery）プロトコルに従ったメッセージであってもよい。

１０，１０ａ，１０ｂルータ
１１送受信部
１２ルータ処理部
１３ IGMP処理部（グループメッセージ処理部）
１４ IGMP監視部（グループメッセージ監視部）
１５管理テーブル
２０，２０ａ，２０ｂ，２０ｃ，２０ｄ，２０ｅ，２０ｆノード
２０ｇ，２０ｈ，２０ｋ，２０ｍノード
２１，２１ａ，２１ｂ L2スイッチ
１００システム

Claims

ネットワークの所定のノードとの間でIPパケットを送受信する複数の送受信部と、
前記送受信部によって受信したマルチキャストフローをマルチキャストルーティングテーブルに応じて宛先の受信ノードに転送する処理を行うルータ処理部と、
前記送受信部によって受信したメッセージであってマルチキャストグループへの参加要求またはマルチキャストグループからの離脱要求を内容とするグループメッセージを監視し、受信したグループメッセージに応じて、マルチキャストフローを受信するノードの情報を管理テーブルに保存するグループメッセージ監視部と、
前記グループメッセージを処理するグループメッセージ処理部と、を備え、
前記グループメッセージ監視部は、マルチキャストグループ毎に、且つ、前記送受信部毎に、最初に参加要求を内容とするグループメッセージを送信したノードの識別子と、マルチキャストグループ内に複数の受信ノードが存在するか否かを示す複数受信ノード存在フラグを前記管理テーブルに保存し、前記グループメッセージの受信時に前記複数受信ノード存在フラグに応じて、前記グループメッセージまたはマルチキャストフローの転送停止指示を前記グループメッセージ処理部に出力することを特徴とするルータ。
前記グループメッセージ監視部は、
前記送受信部によってマルチキャストグループへの参加要求を内容とするグループメッセージを受信したときに、
当該グループメッセージを送信したノードの情報に一致するエントリが前記管理テーブルに存在しない場合、前記管理テーブルにおいて、当該グループメッセージを送信したノードの識別子および前記複数受信ノード存在フラグを偽とした値を有する新しいエントリを追加し、
当該グループメッセージを送信したノードの情報に一致し、かつ、前記複数受信ノード存在フラグが偽であるエントリが前記管理テーブルに保存され、かつ保存されたエントリにおけるノードの識別子が当該グループメッセージを送信したノードの識別子と異なる場合、前記複数受信ノード存在フラグを真とすることを特徴とする請求項１に記載のルータ。
前記グループメッセージ監視部は、
前記送受信部によってマルチキャストグループからの離脱要求を内容とするグループメッセージを受信したときに、
当該グループメッセージを送信したノードの情報に一致し、かつ、前記複数受信ノード存在フラグが偽であるエントリが前記管理テーブルに保存され、かつ保存されたエントリにおけるノードの識別子が当該グループメッセージを送信したノードの識別子に一致する場合、当該グループメッセージで指定されたマルチキャストグループの転送停止指示を前記グループメッセージ処理部に出力する、ことを特徴とする請求項２に記載のルータ。
前記グループメッセージ処理部は、前記転送停止指示で指定されたマルチキャストグループのエントリを前記マルチキャストルーティングテーブルから削除する更新指示を前記ルータ処理部に出力し、
前記グループメッセージ監視部は、前記グループメッセージ処理部から、前記マルチキャストルーティングテーブルの更新通知を受領した後に、前記管理テーブルから、当該マルチキャストグループのエントリを削除する、ことを特徴とする請求項３に記載のルータ。
前記グループメッセージは、IGMP（Internet Group Management Protocol）に従ったメッセージであることを特徴とする請求項１から請求項４のいずれか一項に記載のルータ。
前記グループメッセージは、MLD （Multicast Listener Discovery）プロトコルに従ったメッセージであることを特徴とする請求項１から請求項４のいずれか一項に記載のルータ。