JP2010531586A - マルチキャストグループを管理する方法と装置 - Google Patents

マルチキャストグループを管理する方法と装置 Download PDF

Info

Publication number
JP2010531586A
JP2010531586A JP2010513667A JP2010513667A JP2010531586A JP 2010531586 A JP2010531586 A JP 2010531586A JP 2010513667 A JP2010513667 A JP 2010513667A JP 2010513667 A JP2010513667 A JP 2010513667A JP 2010531586 A JP2010531586 A JP 2010531586A
Authority
JP
Japan
Prior art keywords
source
router
record
host
message
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.)
Granted
Application number
JP2010513667A
Other languages
English (en)
Other versions
JP2010531586A5 (ja
JP5196685B2 (ja
Inventor
グティエレス， アルバロ フェルナンデス
Original Assignee
メディア パテンツ エセ．エレ．
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by メディア パテンツ エセ．エレ． filed Critical メディア パテンツ エセ．エレ．
Publication of JP2010531586A publication Critical patent/JP2010531586A/ja
Publication of JP2010531586A5 publication Critical patent/JP2010531586A5/ja
Application granted granted Critical
Publication of JP5196685B2 publication Critical patent/JP5196685B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

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/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

本発明は、データネットワーク内のマルチキャストトラフィックを管理する方法と、方法を用いる装置に関する。ホスト（２００、２２０、２２５、２３０）は、各マルチキャストグループについて包含ソースレコードおよび除外ソースレコードを格納し、ホストのネットワークインタフェースは、包含ソースレコードについての情報および／または除外ソースレコードについての情報を含むメッセージをルータ（２６０）に送付する。ルータ（２６０）はまた、各マルチキャストグループについて包含ソースレコードおよび除外ソースレコードを格納し、そのネットワークインタフェースを介して包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージをホスト（２００、２２０、２２５、２３０）から受信すると、それらレコードを更新する。本装置は、本方法に適合したルータ、ホスト機器およびネットワーク機器である。

Description

本発明は、データネットワークにおけるマルチキャスト技術の分野に含まれる。具体的には、本発明は、データネットワークにおけるマルチキャストトラフィックを管理する方法に関し、このネットワークでは、ソースが、少なくとも一つのマルチキャストグループにアドレス指定されたデータを送付し、複数のホストが、前記マルチキャストグループ中の、送付を行う前記ソースの一又は複数によって送付されたデータをルータから受信するもので、前記ホストと前記ルータとは、たとえばＩＧＭＰプロトコル（インターネットグループ管理プロトコル）やＭＬＤ（マルチキャストリスナ発見）プロトコルなどの通信プロトコルを用いて互いと通信してホスト−ルータ間マルチキャスト通信を可能にし、前記ホストは、そのプロトコルにより、前記マルチキャストグループに関して、前記リストのソースによって送付されるデータの受信を望むことを示すための包含ソースリストと、前記リストのソースを除く前記マルチキャストグループのソースすべてからのトラフィックの受信を望むことを示すための除外ソースリストとを前記ホストが定義することができる。
本発明は、前記方法を適用する装置にも関する。
マルチキャスト技術により、ユニキャスト通信、すなわち一対一の個別通信をソースと各受信機との間にセットアップする必要なく、データネットワークを通して単一ソースから多くの受信機にデータを送付することが可能になる。このために、ソースは、データパケットの形のデータを、前記データ送付の受信機になることを希望した機器が受信登録することができるマルチキャストグループに関連づけられた単一アドレスに送付する。このアドレスは、マルチキャストアドレスまたはマルチキャストグループアドレスとも呼ばれ、マルチキャストアプリケーション用に予約された範囲内で選ばれるＩＰ（インターネットプロトコル）アドレスである。ソースによってマルチキャストアドレスに送付されたデータパケットは、次いでマルチキャストグループに加入している受信機に届き得るように、異なるネットワークルータ内で複製される。
マルチキャストグループ中のデータ送付受信機は一般に、プロキシまたはルータを用いてデータネットワークに接続された機器である。これ以降、ホストという一般用語を、前記機器を指すのに使用する。ホストは、たとえば、コンピュータでも、テレビセットに接続されたセットトップボックスでもよい。
ホストは、マルチキャストグループの一又は複数のソースによって送付される情報を受信したいとき、前記グループに受信登録するための受信登録メッセージを、最も近いルータまたは中間プロキシに送付し、それによりルータは、データネットワークを通して到着した、マルチキャストグループのソースによって送付されたデータをホストに伝送する。同様に、ホストは、マルチキャストグループにおけるデータ送付の受信の停止を望むとき、送付の受信を停止するための登録解除メッセージをルータまたはプロキシに送付する。
ホストと最も近いルータとの間で交換される、マルチキャストグループへの所属を管理するためのメッセージは、ルータがＩＰプロトコル（インターネットプロトコル）のバージョン４（ＩＰｖ４）またはバージョン６（ＩＰｖ６）と連動するかどうかによって、それぞれＩＧＭＰプロトコル（インターネットグループ管理プロトコル）またはＭＬＤ（マルチキャストリスナ発見）プロトコルを用いる。
ホストとルータとの間にプロキシがある場合、そのプロキシは、ホスト、最も近いルータまたは他の中間プロキシと、マルチキャストグループ所属メッセージを交換するのに、ＩＧＭＰ／ＭＬＤプロトコルも用いる。これらの場合、プロキシは、マルチキャストグループに受信登録し、または登録解除するための申請を異なるホストから受信することができ、これらの申請をアセンブルすることによって、ルータに送付するＩＧＭＰ／ＭＬＤメッセージトラフィックを削減する。
さらに、ルータは、マルチキャストグループに受信登録したホストに、データをソースから効率的に経路指定することを可能にする経路制御を定義するために、ルータ同士でメッセージを交換する。このために、ルータは、非常によく知られているＰＩＭ−ＳＭ（プロトコル非依存マルチキャスト−スパースモード）を含む特定のプロトコルを用いる。
要するに、ルータは、どのマルチキャストグループからトラフィックを受信したいかを指定する情報を、ＩＧＭＰ／ＭＬＤメッセージの形でホストから受信し、ホストによって要求されたトラフィックを受け入れる経路指定をこのようなホストまでセットアップするために、たとえば、ＰＩＭ−ＳＭプロトコルを用いて他のルータと通信する。
言及したプロトコルはすべて、インターネット通信技術作業部会（ＩＥＴＦ）によって定義され文書化されている。
現在使われているＩＧＭＰプロトコルバージョンはＩＧＭＰｖ３であり、これは、ＩＥＴＦによってオンラインで公表されているＲＦＣ３３７６仕様（Ｂ．Ｃａｉｎら、Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ、Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ３３７６、２００２年１０月。現在、インターネットアドレスｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ３３７６から入手可能）に記載されている。
ＭＤＬプロトコルに関しては、現在使われているバージョンはＭＤＬｖ２であり、これは、ＩＥＴＦによってオンラインで公表されているＲＦＣ３８１０仕様（Ｒ．Ｖｉｄａら、Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ、Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ３８１０、２００４年６月。現在、インターネットアドレスｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ３８１０から入手可能）に記載されている。
ＩＧＭＰ／ＭＬＤプロトコルを用いるＩＧＭＰプロキシの動作は、ＩＥＴＦによってオンラインで公表されているＲＦＣ４６０５仕様（Ｂ．Ｆｅｎｎｅｒら、Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ、Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ４６０５、２００６年８月。現在、インターネットアドレスｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４６０５から入手可能）に記載されている。
ルータ間の通信に用いられるＰＩＭ−ＳＭプロトコルは、ＩＥＴＦによってオンラインで公表されているＲＦＣ４６０１仕様（Ｂ．Ｆｅｎｎｅｒら、Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ、Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ４６０１、２００６年８月。現在、インターネットアドレスｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４６０１から入手可能）に記載されている。
マルチキャスト技術は当初、主として、ＡＳＭ（全ソースマルチキャスト）として知られる多対多の通信モデルに適用されるために実装された。この通信モデルでは、多数のユーザが互いに通信し、ユーザの誰もがデータを送付し、また他の全員からデータを受信することができる。典型的なＡＳＭアプリケーションは、インターネットを介して複数通信者呼出しである。
マルチキャスト技術はその後、ＳＳＭ（ソース特定マルチキャスト）として知られる１対多通信モデルに適用されるために実装された。この通信モデルでは、単一ソースが多くの受信機向けにデータを送付する。インターネット経由のラジオおよびテレビは、ＳＳＭアプリケーションである。このため、ＳＳＭに対する関心は現在非常に大きい。
それ以前のＩＧＭＰプロトコルバージョンでは、ホストは、マルチキャストグループ中で受信登録したいデータ送付ソースを選ぶことができず、ソースすべてに関してグループに受信登録または登録解除することしかできなかった。ホストがルータに送付するメッセージは非常に単純だった。すなわち、マルチキャストグループＧからトラフィックを受信するにはＪｏｉｎ（Ｇ）、および受信を停止するにはＬｅａｖｅ（Ｇ）である。したがって、それ以前のＩＧＭＰプロトコルバージョンは、ＳＳＭを許容していなかった。
ホストによるマルチキャストグループ中のソース選択は、ＩＧＭＰプロトコルのＩＧＭＰｖ３バージョンにおいて可能になり、ＳＳＭが可能となった。このために、ホストは、以下の二つの型のＩＧＭＰメッセージを送付することができる。
・ＩＮＣＬＵＤＥメッセージ：ホストがデータの受信を望む送付元のソースＩＰアドレスの指示からなる。ＲＦＣ３３７６仕様の用語によると、包含されたこれらのソースのＩＰアドレスは、ＩＮＣＬＵＤＥソースと呼ばれる。
・ＥＸＣＬＵＤＥメッセージ：ホストがデータの受信を望まない送付元のソースＩＰアドレスの指示からなる。この場合、ホストは、メッセージ中で除外と示されるソースを除くソースすべてによって送付されるデータの受信を望むと解釈される。やはりＲＦＣ３３７６仕様の用語によると、これらの除外ソースのＩＰアドレスは、ＥＸＣＬＵＤＥソースと呼ばれる。
メモリ、データトラフィックを節約するため、または他の理由により、ＩＧＭＰｖ３バージョンにおいて、各ネットワークインタフェースおよびマルチキャストグループは以下の二つのモードの一方でのみ動作することができ、一方から他方に切り換え可能であることが決められた。前記二つのモードとは、ネットワークインタフェースがＩＮＣＬＵＤＥソースリストをその中で定義するＩＮＣＬＵＤＥモード、またはネットワークインタフェースがＥＸＣＬＵＤＥソースリストをその中で定義するＥＸＣＬＵＤＥモードである。
ネットワークインタフェースは、各マルチキャストグループＧ１について複数の異なる要求を受信することができる。各要求は、同一マルチキャストグループに関するＩＮＣＬＵＤＥソースリストまたはＥＸＣＬＵＤＥソースリストを含む。この状況を解消し、各ネットワークインタフェースがＩＮＣＬＵＤＥモードおよびＥＸＣＬＵＤＥモードのいずれかでのみ動作し得るという制約を保つために、ＩＧＭＰｖ３プロトコルは、ネットワークインタフェースが以下の規則を適用しなければならないとしている。
規則１：グループＧ１のデータソースのいずれかがＥＸＣＬＵＤＥの場合、ネットワークインタフェースは、グループＧ１についてＥＸＣＬＵＤＥモードで動作し、ネットワークインタフェースのソースリストは、ＥＸＣＬＵＤＥソースリストからＩＮＣＬＵＤＥリストのソースを引いた共通部分である。
規則２：ソースすべてがＩＮＣＬＵＤＥソースの場合、ネットワークインタフェースは、グループＧ１についてＩＮＣＬＵＤＥモードで動作し、ネットワークインタフェースのソースリストは、ＩＮＣＬＵＤＥソースすべての和集合である。
後述では、本発明の複数の実施形態の説明により、これらの規則が通信を有意に複雑にすることが理解されよう。
ＡＳＭマルチキャストでは、ホストが特定のマルチキャストグループＧからのトラフィックを受信したい場合、以下の技術的問題を解決することが必要である。すなわち、ホストは、マルチキャストグループＧのアドレスのみを知っており、データを送付しているそのグループＧのソースＩＰアドレスを知らない。この問題を異なる方法で解決する、ルータ間で異なるマルチキャスト通信プロトコルがある。今日では、ＰＩＭ−ＳＭプロトコルが主として適用され、ランデブーポイントと呼ばれるルータ（これ以降ＲＰルータ）を、単一マルチキャストドメイン（同じＲＰルータを使用するルータのグループ）のソースすべての認知を担うルータとして指定することによって問題を解決する。ソースＩＰアドレスを見つけ出すために、各ルータは、ＲＰルータとの第１のマルチキャスト通信をセットアップし、それにより、ＲＰルータは、要求されたマルチキャストトラフィックを各ルータに送付する。ルータは、第１のマルチキャストトラフィックデータを受信すると、ソースＩＰアドレスを発見する。次いで、最終ルータ、すなわちホストからＩＧＭＰメッセージを直接受信するルータが、ＳＰＴパスと呼ばれる、ネットワークを通る最短パスをセットアップするＳＰＴツリー（最短パスツリー）を使用して、データをソースから直接受信しようとする。ルータは、ＲＰルータを介して、およびＳＰＴパスにより直接、共に複写の形でデータの受信を始めると、ＲＰルータとの通信を切断し、ＳＰＴパスによる直接通信のみを維持する。
ＳＳＭでは、マルチキャストグループのソースＩＰアドレスを見つけ出すという問題は存在しない。というのは、ユーザ自身がマルチキャストトラフィックの受信を望む送付元のソースを選ぶためである。したがって、ホストは、ルータまたはプロキシにソースＩＰアドレスを示せばよい。その結果、ＳＳＭでは、ＡＳＭの特性である複数の技術的に複雑な問題をなくすことが可能である。具体的には、ソースＩＰアドレスを見つけ出すのに関連した技術的に複雑な問題をなくすことが可能である。たとえば、ＳＳＭでは、ルータは、マルチキャストグループに受信登録する際に、ホストによって指示されるソースＩＰアドレスを知ることができるので、ＲＰルータを使用する必要はない。したがって、ＳＳＭでは、今日用いられているものよりも効率的なアルゴリズムを適用することができる。
ＩＧＭＰｖ３プロトコルに関する前述の規則により、ＳＳＭシステムのこれらの利点が活用できなくなる。ネットワークインタフェースは、ＥＸＣＬＵＤＥモードで動作する際、ソースＩＰアドレスを知らず、したがって、ＡＳＭに関して前述したように、ＲＰルータを介して前記ＩＰアドレスを見つけ出すことを強制され、ＡＳＭ用の経路指定プロセスがより複雑になるという欠点がある。
ＩＥＴＦは最近、言及した欠点の解消を試みるために、ＩＧＭＰおよびＭＤＬプロトコルのＩＧＭＰｖ３およびＭＬＤｖ２バージョン仕様を修正する新たな提案を発表しており、この提案は、ＩＥＴＦによってオンラインで公表されているＲＦＣ４６０４仕様（Ｈ．Ｈｏｌｂｒｏｏｋら、Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ、Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ４６０４、２００６年８月。現在、インターネットアドレスｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４６０４から入手可能）に記載されている。提案された修正は基本的に、ＳＳＭマルチキャストアドレス用の範囲を予約すること、およびＳＳＭマルチキャストシステム内のホストがＥＸＣＬＵＤＥメッセージを送付するのを禁止することからなる。この制約は、ホストが同じマルチキャストグループ中の他の新規ソースをリッスンできないようにするので、ＳＳＭの十分な開発を不要に阻んでいる。
マルチキャスト通信における異なる改良を提案する複数の特許または特許出願が公知である。米国特許第６４３４６２２号、米国特許第６７８５２９４号、米国特許第６９７７８９１号、米国特許出願公開第２００３／００６７９１７号、米国特許出願公開第２００５／０２０７３５４号、米国特許出願公開第２００６／０１２０３６８号、米国特許出願公開第２００６／０１８２１０９号およびＷＯ２００６／００１８０３Ａ１を挙げておく。しかし、これらのいずれもが、上述した問題を解決していない。
本発明の主な目的は、特にＳＳＭ通信に適用される、データネットワークにおけるマルチキャスト通信を管理する改良型システムを提供することである。
本発明の目的は、データ送付ソースと、前記データ送付の受信を要求したホストとの間の経路指定効率を上げることである。
本発明の別の目的は、既存プロトコルを基礎として用いる改良型ホスト−ルータ間マルチキャスト通信プロトコルの形で、およびこれらのプロトコルの以前のバージョンに適合した方法で上記システムを実装できるようにすることである。
このために、冒頭で示したタイプのデータネットワークにおけるマルチキャストトラフィックを管理する方法が開発された。この方法は、ホスト−ルータ間マルチキャスト通信を可能にする前記通信プロトコルに従って、
・ホストが、各マルチキャストグループおよびネットワークインタフェースについて、包含ソースリストを含む包含ソースレコードおよび除外ソースリストを含む除外ソースレコードという二つの別々のレコードを格納し、
・各ホストのネットワークインタフェースが、単一マルチキャストグループについての前記ホストの包含ソースレコードのソースリストの情報および／または前記ホストの除外ソースレコードのソースリストの情報を含むメッセージを前記ルータに送付し、
・ルータが、各マルチキャストグループについて、包含ソースリストの情報を含む包含ソースレコードおよび除外ソースリストの情報を含む除外ソースレコードという二つの別々のレコードを格納し、
・前記ルータが、前記ルータのネットワークインタフェースを介してホストから包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信したとき、前記ルータの包含ソースレコードおよび／または前記ルータの除外ソースレコードを、各マルチキャストグループについて更新することを特徴とする。
本発明は、各ホストのネットワークインタフェースが前記ルータに送付する前記メッセージが、前記ホストの包含ソースレコードのソースリストおよび前記ホストの除外ソースレコードのソースリストを含む状態メッセージであることを意図している。
本発明は、各ホストのネットワークインタフェースが前記ルータに送付する前記メッセージが、前記ホストが前記ホストの包含ソースレコードの変化または前記ホストの除外ソースレコードの変化を検出したときに送付される状態変更メッセージであり、前記状態変更メッセージが、各マルチキャストグループについて一つまたは二つのデータブロックを含み、前記データブロックの各々が、包含ソースレコードのソースリストの修正についての情報または除外ソースレコードのソースリストの修正についての情報を含み、前記データブロックの各々が、データブロックが包含ソースリストの修正に関するのか、それとも除外ソースリストの修正に関するのかを示すフィールドを含むことも意図している。
ルータは、有利には、受信した前記メッセージに含まれる包含ソースリストについての情報を用いて、前記包含ソースによって送付されるデータトラフィックを要求する。
ネットワークインタフェースがホストのネットワークインタフェースである場合、前記ネットワークインタフェースを用いる各ソケットおよび各マルチキャストグループ用に包含ソースレコードおよび除外ソースレコードが保持され、ソケット用の前記包含ソースレコードの内容およびソケット用の前記除外ソースレコードに基づいてそれぞれ更新される包含ソースレコードおよび除外ソースレコードが、前記ネットワークインタフェース用に保持される。
有利な実施形態では、ルータのネットワークインタフェースに届く前記状態メッセージが、前記ルータが前記包含ソースから前記ルータへの経路指定ツリーをセットアップするために適用しなければならない方法についての命令を含む。好ましくは、前記命令を状態メッセージに組み込むために、前記状態メッセージが、マルチキャストアドレス用に予約された範囲外のマルチキャストアドレスを指示し、ルータが、指示されたマルチキャストアドレスが範囲外であることを検出し、前記マルチキャストアドレスが前記命令を含むと解釈し、前記マルチキャストアドレスに含まれる数字コードの形で前記命令を読み出す。
ルータとホストとの間の通信プロトコルは、好ましくは、ＩＧＭＰプロトコル（インターネットグループ管理プロトコル）またはＭＬＤ（マルチキャストリスナ発見）プロトコルのバージョンであり、このバージョンでは、ネットワークインタフェースまたは機器インタフェースによって送付される状態メッセージが、同一メッセージ中に包含ソースリストおよび除外ソースリストを含んでよい。
本発明は、本発明による方法に適合したネットワーク機器にも関し、前記ネットワーク機器は、ネットワークインタフェースを備えており、前記ホストと前記ルータとの間の交換線路中で動作するのに適しており、
・各マルチキャストグループ用に、包含ソースレコードおよび除外ソースレコードを保持し、
・前記ルータへの近接ネットワークインタフェースに対し、マルチキャストグループに関する前記包含ソースレコードのソースリストの情報および／または前記除外ソースレコードのソースリストの情報を含むメッセージを送付し、
・前記ネットワーク機器のネットワークインタフェースが、別のネットワークインタフェースから、包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信すると、前記包含ソースレコードおよび／または前記除外ソースレコードを各マルチキャストグループについて更新する実行可能命令を格納することを特徴とする。
本発明は、本発明による方法に適合した機器にも関し、前記機器は、ネットワークインタフェースを備えており、ホストとして動作するのに適しており、前記ネットワークインタフェースを用いる各ソケット用、および各マルチキャストグループ用に、包含ソースレコードおよび除外ソースレコードを保持し、前記ネットワークインタフェース用に、ソケット用前記包含ソースレコードの内容およびソケット用前記除外ソースレコードに基づいてそれぞれ更新される包含ソースレコードおよび除外ソースレコードを保持するための実行可能命令を格納することを特徴とする。
本発明は、本発明による方法に適合したルータにも関し、
・各マルチキャストグループ用に、二つの別々のレコード、すなわち包含ソースレコードおよび除外ソースレコードを保持し、
・前記ルータが、前記ルータのネットワークインタフェースを介して包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信すると、各マルチキャストグループに関する前記包含ソースレコードおよび／または前記除外ソースレコードを更新する
ための実行可能命令を格納することを特徴とする。
前記ルータは、好ましくは、ルータによって受信される前記メッセージに含まれる包含ソースリストの情報を用いて、前記包含ソースによって送付されるデータトラフィックを他のルータに対して要求する。
前記包含ソースによって送付される前記データトラフィックを要求するために、前記ルータは、好ましくは、ＰＩＭ−ＳＭ（プロトコル非依存マルチキャスト−スパースモード）プロトコルを用いる。
好ましい実施形態では、特定のマルチキャストグループおよび特定の包含ソースからのトラフィックの受信をホストが以降望まないことを通知するメッセージを受信すると、前記ルータは、前記マルチキャストグループの除外ソースレコードがあるかどうかを調べ、前記レコードが存在し、かつ前記包含ソースと同じＩＰアドレスを有する除外ソースを含まない場合、前記ルータが、前記特定のマルチキャストグループおよび前記特定の包含ソースの前記トラフィックを伝送し続け、前記トラフィックの受信を依然として望む別のホストがあるかどうかを調べるための、ＩＧＭＰプロトコルにおける「グループおよびソース特定照会」型メッセージを送付しない。
好ましい実施形態ではまた、除外ソースレコードについての情報を更新するためのメッセージであって、特定のソースおよびマルチキャストグループからのトラフィックを遮断することを要求する前記メッセージを受信すると、前記ルータは、前記マルチキャストグループの包含ソースレコードがあるかどうかを調べ、前記レコードが存在し、かつ前記メッセージが遮断を要求するソースと同じＩＰアドレスを有する包含ソースを含む場合、前記ルータは、前記特定のマルチキャストグループおよび前記特定のソースの前記トラフィックを伝送し続け、前記トラフィックの受信を依然として望む別のホストがあるかどうかを調べるための、ＩＧＭＰプロトコルにおける「グループおよびソース特定照会」型メッセージを送付しない。
本発明の他の利点および特徴は、後述の説明に見ることができる。後述の説明では、非限定的なキャラクタを用いて、添付の図面に関する本発明の好ましい実施形態に言及する。
データネットワークにおけるマルチキャストシステムの基本的実施例を示す。 データネットワークにおけるマルチキャストシステムの詳細な実施例を示す。 ＩＧＭＰｖ３プロトコルで、すなわちＩＧＭＰｖ３プロトコルおよび本発明による修正ＩＧＭＰプロトコル両方で、ルータによってホストに送付される「所属照会」メッセージの形式を示す。 ＩＧＭＰｖ３プロトコルおよび本発明による修正ＩＧＭＰプロトコル両方で、ホストによってルータに送付される「所属報告」メッセージの形式を示す。 ＩＧＭＰｖ３プロトコルにおける各「所属照会」または「所属報告」メッセージに含まれる「グループレコード」データブロックの内部形式を示す。 本発明による修正ＩＧＭＰプロトコルが適用されたとき、図２のシステムにおいて、ＤＳＬＡＭ２４０によってルータ２６０に送付されるメッセージに対応する「所属報告」メッセージの形式を示す。
図１は、データネットワークにおけるマルチキャストシステムの基本的な実施例を示す。この実施例では、３つのホスト１０１、１０２、１０３が、ＣＰＥ１０４、１０５（ＣＰＥ：顧客構内機器）を介してデータネットワークに接続されている。ＣＰＥとは、加入者アクセス回線側に配置されたネットワークに接続する端末であり、たとえばＤＳＬ（デジタル加入者線）モデムを用いて通信を行う。ホスト１０１は、加入者線のＣＰＥ１０４に接続されており、ホスト１０２、１０３は両方とも別の加入者線の別のＣＰＥ１０５に接続されている。ＣＰＥ１０４、１０５は、異なるＣＰＥ１０４、１０５からのトラフィックを、スイッチ１０７を介してルータ１０８に向けるＤＳＬＡＭ１０６（ＤＳＬＡＭ：デジタル加入者線アクセスマルチプレクサ）に接続され、ルータ１０８は、ＩＰ（インターネットプロトコル）ネットワーク１０９に接続される。別のルータ１１０は、ＩＰネットワーク１０９の別のポイントに接続されており、このルータは、マルチキャストグループの複数のソース１１１、１１２によって送付されるデータパケットを集める。
分かりやすくするために、図１は、ルータ１０８に接続された複数のホスト１０１、１０２、１０３によって形成される単一グループ、およびルータ１１０に接続されたソース１１１、１１２からなる単一グループを示す。当然ながら、マルチキャストシステムは実際には、これらの多数の集まりおよびグループから成り立っている。
図１は、ＩＧＭＰおよびＰＩＭ−ＳＭプロトコルそれぞれの範囲も示す。すなわち、ＩＧＭＰプロトコルは、ＣＰＥおよびＤＳＬＡＭを介した受信ホストとルータとの間の通信に適用され、ＰＩＭ−ＳＭプロトコルは、ＩＰネットワークを介した、異なるルータ間の通信に適用される。
この実施例では、ルータはＩＰプロトコルのＩＰｖ４バージョンで動作するので、このシステムはＩＧＭＰプロトコルを用いると想定されている。ただし、記載した理由は、ＭＬＤプロトコル（ＩＰプロトコルのバージョンＩＰｖ６）を用いるシステムにも適用される。
ＣＰＥおよびＤＳＬＡＭは、複数のＩＧＭＰ要求を受信すること、およびこれらの要求をアセンブルして、ルータに送付されるＩＧＭＰメッセージの分量を削減することからなるＩＧＭＰプロキシ機能を実施することができる機器である。この動作は、冒頭で言及したＩＥＴＦのＲＦＣ４６０５仕様に記載されている。
図１に示すマルチキャストシステムの基本動作は、以下の通りである。
ホスト１０１、１０２、１０３は、グループのマルチキャストアドレスおよびホストが受信を希望するデータの送付元のソースアドレスを識別するための複数のＩＧＭＰメッセージをＣＰＥ１０４、１０５に送付する。図１の実施例におけるＣＰＥ１０５のケースのように、異なるホストから複数のＩＧＭＰメッセージを受信するＣＰＥは、これらのＩＧＭＰメッセージをアセンブルして、単一のＩＧＭＰメッセージをＤＳＬＡＭに送付する。一方、ＤＳＬＡＭ１０６は、異なるＣＰＥ、この場合ＣＰＥ１０４、１０５からＩＧＭＰメッセージを受信し、これらのメッセージをアセンブルして、各マルチキャストグループについてＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥソースのみが中に示されるＩＧＭＰメッセージを、スイッチ１０７を介してルータ１０８に送付する。
ルータ１０８は、スイッチ１０７を介してＤＳＬＡＭ１０６によって送付されたＩＧＭＰメッセージを受信し、ＰＩＭ−ＳＭプロトコルを用いて他のＩＰネットワークルータと通信することによって、ルータ１０８によって受信されたＩＧＭＰメッセージ中に指定されるソースによって送付されたデータをルータ１０８に届かせるようにする経路指定を、ＩＰネットワークを通してセットアップする。
さらに詳細な実施例において以下に示すように、従来技術では、ルータ１０８は、ホストによって指定されているソースＩＰアドレスを常に知っているわけではない。というのは、この情報は、元々はホストによって送付されたＩＧＭＰメッセージをネットワークインタフェースがアセンブルしたときに失われてしまっているからである。したがって、ルータ１０８は、複雑で多少非効率なプロセスを適用することによってソースＩＰアドレスを見つけ出さなければならない。
従来技術の方法を適用するマルチキャストシステムの動作例（ＩＧＭＰｖ３プロトコル）
図２は、マルチキャストシステムおよびこのシステムが動作するのに必要な異なる通信を詳細に示す。
図２に基づいて本発明の原理および利点を明らかにするために、ＩＧＭＰｖ３プロトコルを適用する従来技術による動作について最初に説明する。次いで、図２のこの同じ図表を参照して本発明による動作を説明する。
ホスト２００は、マルチキャストトラフィックを要求することができる二つのアプリケーション２０１、２０２が実行されるパーソナルコンピュータＰＣである。コンピュータ２００は、ＣＰＥ２０８に接続されるネットワークカード２０３を装備し、ＣＰＥ２０８は、ＤＳＬＡＭ２４０に接続される。
ホスト２２０、２２５は、単一のＣＰＥ２２８に接続されたネットワークカード２２２、２２３をそれぞれ装備する二つのパーソナルコンピュータＰＣであり、ＣＰＥ２２８はＤＳＬＡＭ２４０に接続される。それぞれマルチキャストトラフィックを要求することができる単一のアプリケーション２２１、２２６は、各コンピュータ２２０、２２５内で実行される。
ホスト２３１は、インターネットを経由したテレビチャンネルの受信を可能にするテレビセット２３０に接続されたＳＴＢ（セットトップボックス）デコーダである。デコーダ２３１は、ＣＰＥ２２９に接続されたネットワークカード２３２を装備し、ＣＰＥ２２９はＤＳＬＡＭ２４０に接続される。
ＤＳＬＡＭ２４０は、スイッチ２５０を介してルータ２６０に接続される。ルータ２６０は、この例ではルータ２６１、２６２、２６３、２６４、２６５、２６６、２６７、２６８である他のルータによって形成されるＩＰネットワークに接続される。
ルータ２６４は、ＲＰ（ランデブーポイント）ルータ、すなわち、マルチキャストグループの送付ソースと、ホストがソースのＩＰアドレスを知らないときにこれらのソースからの送付の受信を望むホストとの間の経路指定をセットアップするのに、ＰＩＭ−ＳＭプロトコルによって使用されるルータである。
図２の実施例では、単一マルチキャストグループＧ１に属す５つの送付ソース２９５、２９６、２９７、２９８、２９９が存在する。説明を簡単にするために、以下の説明では、図２に示すように、それぞれＳ１、Ｓ２、Ｓ３、Ｓ４、Ｓ５である各ＩＰアドレスにより、これらのソースを参照する。
ソースＳ１、Ｓ２、Ｓ３は、ルータ２６６を介してＩＰネットワークに接続され、ソースＳ４、Ｓ５は、ルータ２６２を介して接続される。
ホスト２００内で実行されるアプリケーション２０１、２０２は、マルチキャストグループＧ１中のデータ送付の受信を望むが、各アプリケーションは、以下のように異なるソースからの送付の受信を望む。
・アプリケーション２０１は、ソースＳ１、Ｓ２からの送付を受信することを望み、そのために、ＩＮＣＬＵＤＥ（｛Ｓ１，Ｓ２｝；Ｇ１）型要求を行う。
・アプリケーション２０２は、Ｓ４を除くソースすべてからの送付を受信することを望み、そのために、ＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）型要求を行う。
ネットワークカード２０３は、ＩＧＭＰｖ３プロトコル規則を適用するアプリケーション２０１、２０２に関連づけられた異なるソケットの状態を組み合わせなければならないネットワークインタフェースである。ソケットの一つはＥＸＣＬＵＤＥモードで動作するので、ネットワークインタフェース２０３はＥＸＣＬＵＤＥモードでのみ動作することになり、ＣＰＥ２０８にＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）というメッセージを送付する。
理論上は、ＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）メッセージを送付すると、ＩＮＣＬＵＤＥ（｛Ｓ１，Ｓ２｝；Ｇ１）メッセージを送付する必要がなくなると思われる。というのは、第１のメッセージは、Ｓ４を除くソースをすべて暗黙のうちに含み、したがって、ソースＳ１、Ｓ２を含むからである。ただし、このように動作することによって、アプリケーション２０１によって送付されるＩＧＭＰメッセージに含まれていた有益な情報、すなわちソースＳ１、Ｓ２のＩＰアドレスが失われてしまっている。
ネットワークカード２０３によって送付されるＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）メッセージは、ＣＰＥ２０８によってソースの情報が修正されずに、ＤＳＬＡＭ２４０に伝送される。というのは、ＤＳＬＡＭ２４０は、一つの起点からのＩＧＭＰメッセージしか受信しないためである。
コンピュータ２２０内で実行されるアプリケーション２２１は、ソースＳ５からの送付の受信を望むことを示すＩＮＣＬＵＤＥ（｛Ｓ５｝，Ｇ１）型要求を行う。ネットワークカード２２２は、アプリケーション２２１が関連づけられるソケットからの要求を受信するだけなので、複数の要求を組み合わせる必要はない。したがって、ネットワークカード２２２は、アプリケーション２２１の要求と同じ情報を含むＩＧＭＰメッセージ、すなわちＩＮＣＬＵＤＥ（｛Ｓ５｝，Ｇ１）メッセージをＣＰＥ２２８に送付する。
コンピュータ２２５内で実行されるアプリケーション２２６は、ソースＳ３からの送付の受信を望むことを示すＩＮＣＬＵＤＥ（｛Ｓ３｝，Ｇ１）型要求を行う。ネットワークカード２２３は、アプリケーション２２６が関連づけられるソケットからの要求を受信するだけなので、複数の要求を組み合わせる必要はない。したがって、ネットワークカード２２３は、アプリケーション２２６の要求と同じ情報を含むＩＧＭＰメッセージ、すなわちＩＮＣＬＵＤＥ（｛Ｓ３｝，Ｇ１）メッセージをＣＰＥ２２８に送付する。
ＣＰＥ２２８は、ＩＧＭＰプロキシとして振る舞い、ＩＧＭＰｖ３プロトコル規則を適用して、ネットワークインタフェース２２２、２２３によってそれぞれ送付されるメッセージを組み合わせる。受信されたメッセージはすべてＩＮＣＬＵＤＥ型メッセージなので、ネットワークインタフェース２２８はＩＮＣＬＵＤＥモードでのみ動作することになり、ＤＳＬＡＭ２４０にＩＮＣＬＵＤＥ（｛Ｓ３，Ｓ５｝；Ｇ１）というメッセージを伝送する。
ＳＴＢ２３１は、ソースＳ１からの送付の受信を望むことを示すＩＮＣＬＵＤＥ（｛Ｓ１｝，Ｇ１）メッセージを送付する。ＤＳＬＡＭ２４０は単一起点からのＩＧＭＰメッセージを受信するので、ＣＰＥ２２９は、このメッセージをそのままＤＳＬＡＭ２４０に伝送する。
したがって、ＤＳＬＡＭ２４０は、以下の三つのＩＧＭＰメッセージを受信する。
ＣＰＥ２０８からのＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）
ＣＰＥ２２８からのＩＮＣＬＵＤＥ（｛Ｓ３，Ｓ５｝；Ｇ１）
ＣＰＥ２２９からのＩＮＣＬＵＤＥ（｛Ｓ１｝，Ｇ１）
ＤＳＬＡＭ２４０は、これらの異なるメッセージを、ＩＧＭＰｖ３プロトコル規則を適用して組み合わせなければならないプロキシである。マルチキャストグループＧ１に関して受信されたメッセージの一つがＥＸＣＬＵＤＥ型メッセージなので、ネットワークインタフェース２４０は、前記マルチキャストグループＧ１に対してはＥＸＣＬＵＤＥモードでのみ動作することになり、Ｓ４を除くグループＧ１のソースすべてからの送付をルータ２６０がＤＳＬＡＭ２４０に伝送しなければならないことを示すＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）というメッセージを、スイッチ２５０を通してルータ２６０に伝送する。
次いでルータ２６０は、ＰＩＭ−ＳＭプロトコルを用いて他のＩＰネットワークルータと通信し、ソースＳ４を除くマルチキャストグループＧ１のソース全部である、ＩＧＭＰメッセージ中で要求されたソースによって送付されるデータを受信する。ＰＩＭ−ＳＭプロトコルは、二つの経路指定ツリー型、すなわちＲＰルータ（この場合、ルータ２６４）を中心とするＲＰＴ（ランデブーポイントツリー）ツリーおよび最短パスをセットアップするＳＰＴ（最短パスツリー）のセットアップを可能にする複雑なプロトコルである。ＲＰルータは、マルチキャストグループのソースすべてのＩＰアドレスの認知を担うルータとして、ＰＩＭ−ＳＭプロトコルによって指定されるルータである。ルータ２６０は最初、ＲＰルータのみがソースＩＰアドレスを知っているので、マルチキャストグループからのトラフィックを、ＲＰＴツリーを通して常に受信する。後述で説明する一定の条件が満たされると、ルータ２６０は、ＳＰＴツリーを使用し、ＲＰツリーを通した伝送を中止する。
図２の実施例において、最初にＲＰＴツリーを使用すると、ルータ２６０は、点線で示すパス２８１を通してソースＳ１、Ｓ２、Ｓ３からの送付を受信し、点線で示すパス２８２を通してソースＳ５からの送付を受信する。したがって、ルータ２６０は、実線で示すパス２９１、２９２であるＳＰＴツリーによる最短パスを通してではなく、最長パスを通してデータを受信している。
ルータ２６０は、ＤＳＬＡＭ２４０からＥＸＣＬＵＤＥ（｛Ｓ４｝；Ｇ１）メッセージを受信しただけなので、包含ソースのＩＰアドレスを知らない。したがって、ルータ２６０は、ＳＰＴツリーを直接使用して包含ソースからのトラフィックを要求することはできない。冒頭で述べたように、これは重大な欠点である。別の欠点は、ルータがＳＳＭマルチキャストにおいてのみ動作する場合、ＥＸＣＬＵＤＥメッセージを受信しないという事実である。さらに、ルータは、ソースと直接接続することしかできない簡略ルータである場合、ソースのＩＰアドレスを知らない場合は、直接接続することができない。
特定のチャネル（Ｓ，Ｇ）、すなわちマルチキャストグループＧ中のソースＳによって定義されるチャネルをＲＰＴツリーからＳＰＴツリーに切り換えるための、ＰＩＭ−ＳＭプロトコルによって与えられる条件は、ＲＦＣ４６０１仕様、具体的にはＣｈｅｃｋＳｗｉｔｃｈＴｏＳｐｔ（Ｓ，Ｇ）と呼ばれる関数を定義する「Ｌａｓｔ Ｈｏｐ Ｓｗｉｔｃｈｏｖｅｒ ｔｏ ｔｈｅ ＳＰＴ」というセクション４．２．１に詳述されている。
Figure 2010531586

＃注：ＫＡＴをリスタートすると、ＳＰＴ切換えという結果になる。ＫｅｅｐａｌｉｖｅＴｉｍｅｒ（Ｓ，Ｇ）をＫｅｅｐａｌｉｖｅ＿Ｐｅｒｉｏｄにセットする
ＣｈｅｃｋＳｗｉｔｃｈＴｏＳｐｔ（Ｓ，Ｇ）関数は、設定可能な「ＳｗｉｔｃｈＴｏＳｐｔＤｅｓｉｒｅｄ（Ｓ，Ｇ）」関数によって定義される設定可能部分、および設定不可能部分を有する。ＲＰＴツリーからＳＰＴツリーへの切換えは、条件の両方の部分が満たされるときに実施される。
通常、前記閾値を超えていない場合はＲＰＴツリーからＳＰＴツリーへの切換えが実施されないように、設定可能な「ＳｗｉｔｃｈＴｏＳｐｔＤｅｓｉｒｅｄ（Ｓ，Ｇ）」関数が、ソースＳからのトラフィックの分量の閾値を確立するのに使用される。
ＰＩＭ−ＳＭプロトコルプログラミングコードの一部を形成する設定不可能部分は、以下の通りである。
Figure 2010531586
この設定不可能条件は、ＩＮＣＬＵＤＥ（Ｓ，Ｇ）というＩＧＭＰメッセージを受信済みであるルータのネットワークインタフェースがある場合、またはグループＧのソースすべてからのトラフィックの受信を望むことを示すＩＧＭＰ型メッセージを受信済みであるルータのネットワークインタフェースがあり、前記ネットワークインタフェースがＥＸＣＬＵＤＥ（Ｓ，Ｇ）というＩＧＭＰメッセージを受信していない場合に、ルータが特定のチャネル（Ｓ，Ｇ）をＲＰＴツリーからＳＰＴツリーに切り換えるだけであることを定めるものである。この設定不可能条件は、ＩＧＭＰメッセージにのみ関するので、ＳＰＴツリーへの切換えを開始してチャネル（Ｓ，Ｇ）の入力ルータとの直接接続をセットアップすることができる唯一のルータは、ＩＧＭＰメッセージを受信するルータ、すなわち図２の実施例ではルータ２６０である。ネットワークインタフェースを介してＩＧＭＰメッセージを直接受信しないルータでは、これらのルータがＳＰＴツリーへの切換えを開始することがないように、この条件が満たされることはない。
図２の実施例において、ルータ２６０が受信する唯一のメッセージは、前記設定不可能条件が満たされないＥＸＣＬＵＤＥ（｛Ｓ４｝，Ｇ１）である。したがって、ルータ２６０は、ＲＰＴツリーからＳＰＴツリーに切り換えることができず、トラフィックは、最短パス２９１、２９２を通るのではなく、ＲＰルータ２６４を通して最長パス２８１、２８２をいつまでも通り続けることになる。このように、トラフィックはむしろ非効率な方法で配信され、ＲＰルータに不必要に負荷がかかる。
要するに、この例は、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥ型メッセージを組み合わせるためにＩＧＭＰｖ３プロトコル規則を適用すると、経路指定システムの効率に悪影響を与えることを示す。この状況は、図２に示すものとは異なる組合せを有する他のマルチキャストシステムにおいても起こることが、当業者には容易に理解されよう。
本発明による修正ＩＧＭＰプロトコル
本発明は、修正ＩＧＭＰプロトコルを適用することによってこれらの問題を解決し、その結果、ネットワークインタフェースは、ホストによって送付されるメッセージを、前記メッセージに含まれる情報を失うことなく伝送することができる。
本発明による修正ＩＧＭＰプロトコルは、ネットワークインタフェースがデュアルモードで動作し得る点で、ＩＧＭＰｖ３プロトコルとは異なる。すなわち、インタフェースは、ＩＮＣＬＵＤＥ型ＩＧＭＰメッセージに含まれる情報およびＥＸＣＬＵＤＥ型ＩＧＭＰメッセージに含まれる情報を別々に格納および伝送する。
本発明による修正ＩＧＭＰプロトコルについては、後述で説明する。説明を容易にするために、冒頭で言及したＩＥＴＦのＲＦＣ３３７６仕様によるＩＧＭＰｖ３プロトコルの説明を参照し、前記ＩＧＭＰｖ３プロトコルに対する、修正ＩＧＭＰプロトコルにおける変更のみを詳しく記述する。詳しく記述しない部分は、ＩＧＭＰｖ３プロトコルに該当するので、当業者の理解の範囲内である。
説明は、以下のセクションにまとめられる。
１）インタフェースの説明／状態情報／ソースのアセンブル法
２）状態レコードの消去法
３）ネットワークインタフェースレコードを導出する規則
４）ＩＧＭＰメッセージの説明
５）レコードの情報が変更する際の挙動
６）ホストが「所属照会」メッセージを受信する際の挙動
７）ルータ用プロトコルの説明
８）ＩＧＭＰｖ３ホストとの互換性
９）改良型ＩＧＭＰプロキシ
１）インタフェースの説明／状態情報／ソースのアセンブル法
ＩＧＭＰｖ３プロトコルのＲＦＣ３３７６仕様では、システムが以下の関数によるＩＧＭＰメッセージをサポートし、ホストがマルチキャストデータソースを選択することができなければならないと記載している。
ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ（ｓｏｃｋｅｔ，ｉｎｔｅｒｆａｃｅ，ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ｆｉｌｔｅｒ−ｍｏｄｅ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
上記関数で、
「ｓｏｃｋｅｔ」は、システム内で実行される異なるアプリケーションを区別することを可能にし、ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数を呼び出すパラメータである。たとえば、データネットワークに接続された単一コンピュータ内で実行される異なるアプリケーションとすることができる。
「ｉｎｔｅｒｆａｃｅ」は、受信するべきマルチキャストデータソースを示すネットワークカードまたはネットワークインタフェースのローカル識別子である。
「ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ」は、マルチキャストグループのアドレスである。
「ｆｉｌｔｅｒ−ｍｏｄｅ」は、ＩＮＣＬＵＤＥでもＥＸＣＬＵＤＥでもよいネットワークインタフェースモードである。ＩＮＣＬＵＤＥモードでは、ネットワークインタフェースは、ｓｏｕｒｃｅ−ｌｉｓｔをＩＮＣＬＵＤＥとして定義し、このことは、リスト上のソースすべてによって送付されるトラフィックが送付されなければならないことを意味する。ＥＸＣＬＵＤＥモードでは、ネットワークインタフェースは、ｓｏｕｒｃｅ−ｌｉｓｔをＥＸＣＬＵＤＥと定義し、このことは、マルチキャストグループ中の送付を行うソースのうち、リスト上のソースを除くすべてからのトラフィックが送付されなければならないことを意味する。
「ｓｏｕｒｃｅ−ｌｉｓｔ」は、ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥソースリストである。
ＲＦＣ３３７６仕様は、特定のソケット、ネットワークインタフェースおよびマルチキャストグループの組合せに対して、ＩＮＣＬＵＤＥでもＥＸＣＬＵＤＥでもよい一つのｆｉｌｔｅｒ−ｍｏｄｅしかあり得ないと明白に記述している。
システムは、各アクティブソケットに対して状態レコードを保存する。このレコードは、以下の情報を含む。
（ｉｎｔｅｒｆａｃｅ，ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ｆｉｌｔｅｒ−ｍｏｄｅ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
各ソケットに対し、レコードのｆｉｌｔｅｒ−ｍｏｄｅは、ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥでしかあり得ない。
システムは、各ネットワークインタフェースに関するレコードも保存する。このレコードは、以下の情報を含む。
（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ｆｉｌｔｅｒ−ｍｏｄｅ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
各ネットワークインタフェースおよびマルチキャストグループに対し、レコードのｆｉｌｔｅｒ−ｍｏｄｅは、ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥでしかあり得ない。各ネットワークインタフェースのレコードは、ソケットレコードから導出される。ネットワークインタフェースのレコードが異なるレコードの組合せから生じなければならない場合、冒頭に記載し、下に転記する規則が適用される。
規則１：グループＧ１のデータソースのいずれかがＥＸＣＬＵＤＥの場合、ネットワークインタフェースは、グループＧ１用にＥＸＣＬＵＤＥ ｆｉｌｔｅｒ−ｍｏｄｅを有することになり、ネットワークインタフェースのソースリストは、ＥＸＣＬＵＤＥソースリストからＩＮＣＬＵＤＥリストのソースを引いた共通部分である。
規則２：ソースすべてがＩＮＣＬＵＤＥ型ソースの場合、ネットワークインタフェースは、グループＧ１用にＩＮＣＬＵＤＥ ｆｉｌｔｅｒ−ｍｏｄｅを有することになり、ソースリストは、ＩＮＣＬＵＤＥソースすべての和集合である。
ここまでは、ＲＦＣ３３７６仕様によるＩＧＭＰｖ３プロトコルの特性について記述した。
本発明による修正ＩＧＭＰプロトコルは、ＩＧＭＰｖ３プロトコルのＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数の同じ構造を維持する。
ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ（ｓｏｃｋｅｔ，ｉｎｔｅｒｆａｃｅ，ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ｆｉｌｔｅｒ−ｍｏｄｅ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
しかし、各ソケットおよび各ネットワークインタフェースに対して、システムが二つのレコード、すなわちＥＸＣＬＵＤＥ ｆｉｌｔｅｒ−ｍｏｄｅ用に一つ、ＩＮＣＬＵＤＥ ｆｉｌｔｅｒ−ｍｏｄｅ用にもう一つを保存するという違いがある。
したがって、システムは、各ソケットに対して二つのレコードを保存する。
ＩＮＣＬＵＤＥレコード：（ｉｎｔｅｒｆａｃｅ，ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＩＮＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
ＥＸＣＬＵＤＥレコード：（ｉｎｔｅｒｆａｃｅ，ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＥＸＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｆｉｓｔ｝）
また、各ネットワークインタフェースおよびマルチキャストグループに対して二つのレコードを保存する。
ＩＮＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＩＮＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
ＥＸＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＥＸＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
ＩＮＣＬＵＤＥソースだけがある、またはＥＸＣＬＵＤＥソースだけがある場合は、システムは一つのレコードしか必要としない。ただし、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソース情報を有する同じマルチキャストグループに対してＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数への異なる呼出しがある場合、システムは、ＩＧＭＰｖ３プロトコルを用いた従来技術において行われるように情報を混合するのではなく、二つのレコードに情報を格納する。
ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数の各呼出しにより、特定のマルチキャストグループに対するレコードの内容が置き換えられ、レコードがない場合は、関数呼出しによって一つのレコードが作成される（これは、たとえば、前記マルチキャストグループ用に初めて関数を呼び出すときに起こる）。
２）状態レコードの消去法
ＩＧＭＰｖ３プロトコルにおいて、特定のグループＧ１のレコードを消去するために、空のソースリストを有するＩＮＣＬＵＤＥ型メッセージ、すなわちＩＮＣＬＵＤＥ（｛｝，Ｇ１）が送付される。さらに、特定のグループＧ１の、ＥＸＣＬＵＤＥモードでのレコードは、一定の時間が経過した後、いかなるメッセージを送付する必要もなく、ＩＮＣＬＵＤＥモードに自動的に切り換わる。そのために、ＩＧＭＰｖ３プロトコルでのレコードは、レコード状態がＥＸＣＬＵＤＥの場合、各マルチキャストグループ用に、ゼロとは異なるタイマを有する。タイマがゼロに達すると、レコードは、ＥＸＣＬＵＤＥモードからＩＮＣＬＵＤＥモードに切り換わる。
本発明による修正ＩＧＭＰプロトコルにおいて、特定のグループＧ１のＩＮＣＬＵＤＥレコードを消去するために、ＩＧＭＰｖ３プロトコルの場合と同じ仕組みが使用される。すなわち、空のソースリストを有するＩＮＣＬＵＤＥ型メッセージ、すなわちＩＮＣＬＵＤＥ（｛｝）が送付される。
特定のグループＧ１のＥＸＣＬＵＤＥレコードを自動的に消去するために、修正ＩＧＭＰプロトコルでは、ＥＸＣＬＵＤＥレコードもＩＧＭＰｖ３プロトコルでのように各マルチキャストグループ用にタイマを有するが、その動作は、ＩＮＣＬＵＤＥモードからＥＸＣＬＵＤＥモードに切り換わる必要がないのでより単純である。すなわち、タイマがゼロに達すると、ＥＸＣＬＵＤＥレコードが単に消去される。
修正ＩＧＭＰシステムは、以下のものに適用される、ＥＸＣＬＵＤＥ状態レコードをより素早く消去する新たな仕組みを、任意選択で追加する。
・ホストレコード：ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数で更新される。
・プロキシおよびルータレコード：ＩＧＭＰメッセージを用いて更新される。
Ｆｉｌｔｅｒ＿Ｄｅｌｅｔｅ＿Ｅｘｃｌｕｄｅと呼ばれる新規のｆｉｌｔｅｒ−ｍｏｄｅパラメータが、ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数を用いてＥＸＣＬＵＤＥレコードを消去するために、修正ＩＧＭＰプロトコルに組み込まれている。ＩＰＭｕｌｔｉｃａｓｔＬｉｓｔｅｎ関数は、このパラメータを有する呼出しを受信するとき、ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓに示されるマルチキャストグループからＥＸＣＬＵＤＥレコードを消去しなければならないことを知っている。
ＩＧＭＰメッセージを用いてプロキシおよびルータからＥＸＣＬＵＤＥレコードを消去するために、「所属報告」メッセージの「グループレコード型」フィールド用の新規の値が、修正ＩＧＭＰプロトコルにおいて以下の簡略な記述により定義されている。
Figure 2010531586
この新規の値は、以下の簡略記述によりＩＧＭＰｖ３プロトコルに既に存在する「グループレコード型」フィールドの値１〜６（ＲＦＣ３３７６仕様のセクション４．２．１２）に追加される。
Figure 2010531586

上記において、ｘは、ソースＩＰアドレスのリストである。
３）ネットワークインタフェースレコードを導出する規則
セクション１）に示したように、修正ＩＧＭＰプロトコルは、各ネットワークインタフェースおよびマルチキャストグループについて二つのレコードを保存することを可能にする。
ＩＮＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＩＮＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
ＥＸＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＥＸＣＬＵＤＥ，｛ｓｏｕｒｃｅ−ｌｉｓｔ｝）
上で、ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓはマルチキャストグループのアドレスであり、ｓｏｕｒｃｅ−ｌｉｓｔはソースのリストである。
ＩＧＭＰｖ３プロトコルでのように、ネットワークインタフェースレコードは、ソケットレコードから導出される。ただし、修正ＩＧＭＰプロトコルを適用すると、単一マルチキャストグループのＩＮＣＬＵＤＥソースとＥＸＣＬＵＤＥソースを混合する必要がないので、プロセスははるかに単純になる。
修正ＩＧＭＰプロトコルは、各ネットワークインタフェースおよびマルチキャストグループに以下の規則を適用する。
規則１：各マルチキャストグループについて、ネットワークインタフェースの各ＩＮＣＬＵＤＥレコードは、前記ネットワークインタフェースを用いるソケットのＩＮＣＬＵＤＥレコードのソースすべての和集合を含む。
規則２：各マルチキャストグループについて、ネットワークインタフェースの各ＥＸＣＬＵＤＥレコードは、前記ネットワークインタフェースを用いるソケットのＥＸＣＬＵＤＥレコードのソースの共通部分を含む。
４）ＩＧＭＰメッセージの説明
説明を簡単にするために、ルータとホストとの間のＩＧＭＰメッセージについて、このセクションでは、両者の間にＩＧＭＰプロキシがないと想定して記載する。ＩＧＭＰプロキシの挙動については、後でセクション９において説明する。
ホストとルータとの間の通信のために、修正ＩＧＭＰプロトコルでは、ＲＦＣ３３７６仕様のセクション４に記載されているＩＧＭＰｖ３プロトコルと同じメッセージを使用するが、後述で説明するような修正を施す。
図３は、ＩＧＭＰｖ３プロトコルにおいて、すなわちＩＧＭＰｖ３プロトコルおよび本発明による修正ＩＧＭＰプロトコルの両方において、ルータによってホストに送付されるメッセージの形式を示す。これらのメッセージは、「所属照会」メッセージと呼ばれる。図３に示す形式は、ＩＧＭＰｖ３プロトコルおよび修正ＩＧＭＰプロトコル両方に適用される。
図４は、ＩＧＭＰｖ３プロトコルにおいて、ホストによってルータに送付されるメッセージの形式を示す。これらのメッセージは、「所属報告」メッセージと呼ばれる。図４に示す形式は、ＩＧＭＰｖ３プロトコルおよび修正ＩＧＭＰプロトコル両方に適用される。
図５は、各「所属報告」メッセージに含まれる「グループレコード」と呼ばれるデータブロックの内部形式を示す。「グループアドレス」フィールドは、マルチキャストグループアドレスを含む。「ソースアドレス」フィールドは、ソースについての情報を含む。「ソース数」フィールドは、各「グループレコード」に存在する「ソースアドレス」フィールドの数を示す。図５に示す形式は、ＩＧＭＰｖ３プロトコルに適用される。
修正ＩＧＭＰプロトコルにおいて、「所属報告」型メッセージが送付される際はＩＧＭＰｖ３プロトコルの場合と同じメッセージ形式が使用されるが、同じマルチキャストグループに対してＩＮＣＬＵＤＥソースとＥＸＣＬＵＤＥソースもある場合には、後で論じる図６に示すように、二つの「グループレコード」が送付される。これらのソースは混合されず、各ネットワークインタフェースおよびマルチキャストグループについて二つのレコードが存在し得るので、システムは、単一のマルチキャストアドレスまたはグループ用に２通りの「グループレコード」を有するメッセージを伝送することができる。すなわち、「グループレコード」の一つは、ＩＮＣＬＵＤＥソースについての情報を伝送し、もう一つは、ＥＸＣＬＵＤＥソースについての情報を伝送する。
ＩＧＭＰｖ３プロトコルでは、ルータは、ホストにホストの状態について尋ねるために、「一般照会」型「所属照会」メッセージを送付する。このメッセージに応答して、ホストは、「現状レコード」型「所属報告」状態メッセージを送付する。この仕組みは、修正ＩＧＭＰプロトコルにおいて維持されるが、ホストによって送付される「現状レコード」メッセージは、単一マルチキャストグループ用に、一つはＩＮＣＬＵＤＥモードで、およびもう一つはＥＸＣＬＵＤＥモードで二つの「グループレコード」を含み得る。ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥモードは、ＩＧＭＰｖ３プロトコルでのように、それぞれ、「レコード型」フィールドの内容によって識別される。
レコード型＝１＝ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥ
レコード型＝２＝ＭＯＤＥ＿ＩＳ＿ＥＸＣＬＵＤＥ
したがって、二つのレコードについての情報は、単一の「現状レコード」メッセージ内で伝送される。
ＩＧＭＰｖ３プロトコルでは、ホストは、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースに生じた変更を報告するために、「Ｓｏｕｒｃｅ−Ｌｉｓｔ−Ｃｈａｎｇｅレコード」メッセージを送付する。「現状レコード」メッセージとは異なり、「Ｓｏｕｒｃｅ−Ｌｉｓｔ−Ｃｈａｎｇｅレコード」メッセージは、ルータによって送付される「所属照会」メッセージに応答して送付されるのではなく、そのソースレコードに変更が起きたことを示すためにホストによって送付される。
ＩＧＭＰｖ３プロトコルでのように、修正ＩＧＭＰプロトコルでは、ホストは、「Ｓｏｕｒｃｅ−Ｌｉｓｔ−Ｃｈａｎｇｅレコード」メッセージも送付するが、以下の違いがある。単一マルチキャストグループ用にニ通りのレコード（ＩＮＣＬＵＤＥレコードおよびＥＸＣＬＵＤＥレコード）があり得るので、「Ｓｏｕｒｃｅ−Ｌｉｓｔ−Ｃｈａｎｇｅレコード」メッセージは、それが二つのレコードのどちらを指すのか示さなければならない。そのために、修正ＩＧＭＰプロトコルでは四つの新規「グループレコード」型が以下の簡略表現で定義される。
Figure 2010531586

上記において、ｘは、ソースＩＰアドレスのリストである。
新規の「グループレコード型」８、９、すなわちＡＬＬＯＷＩＮ（ｘ）およびＢＬＯＣＫＩＮ（ｘ）表現が、それぞれ、ＩＮＣＬＵＤＥレコード中のソースリストに要素を追加または削除するメッセージを送付するために使用される。
新規の「グループレコード型」１０、１１、すなわちＡＬＬＯＷＥＸ（ｘ）およびＢＬＯＣＫＥＸ（ｘ）表現のそれぞれが、ソースｘによって送付されるトラフィックを許容または遮断するメッセージを送付するために使用される。
図６は、本発明による修正ＩＧＭＰプロトコルが適用されたとき、図２の図表において、ＤＳＬＡＭ２４０によってルータ２６０に送付されるメッセージに対応する「所属報告」メッセージの一実施例を示す。このメッセージの内容については、後で詳しく説明する。ＤＳＬＡＭ２４０は、ルータ２６０とホスト２００、２２０、２２５、２３１との間に配置されたＩＧＭＰプロキシとして振る舞う。したがって、この場合、ルータとホストとの間のＩＧＭＰメッセージについての先述の説明は、前記ホストをＤＳＬＡＭ２４０で置き換えて当てはまる。ＩＧＭＰプロキシは、ＩＧＭＰルータとの通信ではホストとして振る舞い、ホストとの通信ではＩＧＭＰルータとして振る舞う。
本発明による修正ＩＧＭＰプロトコルが適用される場合に図２の各機器に格納されるレコードを、以下に示す。
ＰＣ２００において、アプリケーション２０１、２０２が、それぞれソケット１およびソケット２を使用する場合、ソケット１およびソケット２の状態レコードは、それぞれ以下のようになる。
ＩＮＣＬＵＤＥレコード：（インタフェース２０３，グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ１，Ｓ２｝）
ＥＸＣＬＵＤＥレコード：（インタフェース２０３，グループＧ１，ＥＸＣＬＵＤＥ，｛Ｓ４｝）
ＣＰＥ２０８のネットワークインタフェースの状態と一致するＰＣ２００のネットワークインタフェース２０３の状態レコードは、以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ１，Ｓ２｝）
ＥＸＣＬＵＤＥレコード：（グループＧ１，ＥＸＣＬＵＤＥ，｛Ｓ４｝）
ＰＣ２２０において、アプリケーション２２１がソケット１を使用する場合、ソケット１の状態レコードは以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ５｝）
ＰＣ２２５において、アプリケーション２２６がソケット１を使用する場合、ソケット１の状態レコードは以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ３｝）
ソースをアセンブルした後、ＩＧＭＰプロキシとして動作するＣＰＥ２２８のネットワークインタフェースの状態レコードは、以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ３，Ｓ５｝）
ＳＴＢ２３１において、ＣＰＥ２２９のネットワークインタフェースの状態と一致するネットワークインタフェース２３２の状態レコードは、以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ１｝）
ＣＰＥ２０８、２２８、２２９の各々は、そのＩＧＭＰメッセージをＤＳＬＡＭ２４０に送付し、ＤＳＬＡＭ２４０は、これらのメッセージを再度アセンブルするが、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースを混合することはない。
ソースをアセンブルした後、ＩＧＭＰプロキシとして動作するＤＳＬＡＭ２４０のネットワークインタフェースの状態レコードは、以下のようになる。
ＩＮＣＬＵＤＥレコード：（グループＧ１，ＩＮＣＬＵＤＥ，｛Ｓ１，Ｓ２，Ｓ３，Ｓ５｝）
ＥＸＣＬＵＤＥレコード：（グループＧ１，ＥＸＣＬＵＤＥ，｛Ｓ４｝）
ルータ２６０によって送付される「一般照会」メッセージに応答して、ＤＳＬＡＭ２４０は、以下で分析される図６に示すメッセージをルータ２６０に送付する。
「型」＝＝０ｘ２２は「所属報告」であることを示し、「グループレコード数」＝２は、同じマルチキャストグループＧ１に関して二つのデータブロックまたは「グループレコード」が送付されることを示す。「グループレコード」の一つは、ＩＮＣＬＵＤＥソースについての情報を含み、もう一つは、ＥＸＣＬＵＤＥソースについての情報を含む。第１の「グループレコード」は、１に等しい「レコード型」を有する。このことは、ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥ型であること、すなわちＩＮＣＬＵＤＥソースについての情報を含むことを意味する。このデータブロックにおいて、「ソース数」は４に等しく、４つのＩＮＣＬＵＤＥソースの情報が送付される予定であることを意味する。マルチキャストグループＧ１は、「マルチキャストアドレス」フィールドに示される。「ソースアドレス［１］」〜「ソースアドレス［４］」の四つのフィールドは、四つのＩＮＣＬＵＤＥソース、すなわちＳ１、Ｓ２、Ｓ３、Ｓ５についての情報を含む。２に等しい「レコード型」を有する第２の「グループレコード」が下段に示されている。このことは、ＭＯＤＥ＿ＩＳ＿ＥＸＣＬＵＤＥ型であること、すなわちＥＸＣＬＵＤＥソースについての情報を含むことを意味する。「ソース数」は１に等しく、一つのＥＸＣＬＵＤＥソースについての情報が送付される予定であることを意味する。マルチキャストグループＧ１が、「マルチキャストアドレス」フィールドに示される。「ソースアドレス［１］」フィールドは、ＥＸＣＬＵＤＥソース、すなわちＳ４についての情報を含む。
ルータ２６０は、ソースすべての完全な情報を受信している。ここで、ＲＰＴツリーをＳＰＴツリーに切り換えるための、ＰＩＭ−ＳＭプロトコルによって与えられる要件が、後述で説明するように満たされる。
ＰＩＭ−ＳＭプロトコルのＳｗｉｔｃｈＴｏＳｐｔＤｅｓｉｒｅｄ（Ｓ，Ｇ）条件は、チャネル（Ｓ，Ｇ）をＲＰＴツリーからＳＰＴツリーに切り換えるための切換え条件の設定可能部分であり、第１のデータパケットがＳＰＴツリーを通してソースＳから届くときにこの条件が満たされるように、デフォルトで設定される。前記切換え条件の設定不可能条件は、修正ＩＧＭＰプロトコルが適用されるときは常に満たされる。というのは、ソースＳからの受信トラフィックに関心があるルータは、ＩＮＣＬＵＤＥ（Ｓ，Ｇ）というＩＧＭＰメッセージを常に受信していることになり、またはグループＧのソースすべてからのトラフィックの受信を望むことを示すＩＧＭＰ型メッセージを受信していることになり、ＥＸＣＬＵＤＥ（Ｓ，Ｇ）というＩＧＭＰメッセージを受信していることにならないためである。
したがって、修正ＩＧＭＰプロトコルが適用される際、ソースに関するトラフィック要求を受信済みであるルータはすべてＳＰＴツリーに進み、最短パスを通して前記ソースからのトラフィックを受信することができる。
したがって、図２の例において、ソースＳ１、Ｓ２、Ｓ３によって送付されるトラフィックは、最短パス２９１を通ることになり、ソースＳ５によって送付されるトラフィックは、最短パス２９２を通ることになる。
ルータ２６０は、任意選択で、最初から、ソースＳ１、Ｓ２、Ｓ３、Ｓ５それぞれのＳＰＴツリーと直接接続することができる。というのは、これらのソースのＩＰアドレスを知っており、したがってＳＰＴツリーを直接使用することができるからである。そのために、ＳｗｉｔｃｈＴｏＳｐｔＤｅｓｉｒｅｄ（Ｓ，Ｇ）関数を常に真にすれば十分である。
さらに、各ホストは、任意選択で、各ソースによりＲＰＴツリーからＳＰＴツリーへの切換えを開始しなければならないときを、実際のＩＧＭＰメッセージ中でルータ２６０に示すことができる。そのために、本発明によると、マルチキャストアドレスの範囲外の、マルチキャストアドレスの代わりにメッセージが配置されたマルチキャストアドレスフィールドが使用される。たとえば、マルチキャストアドレスの最初の２バイトは０にセットされ、次の２バイトはルータにメッセージを送付するのに使用される。これら次の２バイトには以下の意味が関連づけられる。
１００＝ＳＰＴツリーを使って直接接続する
２００＝ルータのデフォルト設定を使用し、ＳｗｉｔｃｈＴｏＳｐｔＤｅｓｉｒｅｄ（Ｓ，Ｇ）関数を評価して、ＳＰＴツリーに切り換えることを決める
３００＝常にＲＰＴツリーを使用し、決してＳＰＴツリーには切り換えない
ルータは、アドレスがマルチキャストアドレスの範囲外であることを検出し、これらの４バイトを、同じ「グループレコード」の後に含まれるマルチキャストアドレス中で、ルータがＲＰＴツリーからＳＰＴツリーに切り換えなければならない場合の方法を示すメッセージと解釈する。
５）レコードの情報が変更する際の挙動
修正ＩＧＭＰプロトコルにおいて、特定のマルチキャストグループに対するネットワークインタフェースの状態レコードが変更された場合、システムは、前セクションで示した「Ｓｏｕｒｃｅ−Ｌｉｓｔ−Ｃｈａｎｇｅレコード」メッセージを送付することによって、そのような変更を伝送しなければならないだけである。
このプロセスは、システムがｆｉｌｔｅｒ−ｍｏｄｅおよびこのモードに起こり得る変更を考慮に入れなければならないので、ＩＧＭＰｖ３プロトコルではより複雑である。修正ＩＧＭＰプロトコルでは、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースの情報は別々に格納および伝送されるので、このような複雑さはない。
６）ホストが「所属照会」メッセージを受信する際の挙動
ＩＧＭＰｖ３プロトコルおよび修正ＩＧＭＰプロトコルでは、ルータは「所属照会」メッセージと呼ばれるメッセージをホストに送付し、それにより、ホストは、受信を望むマルチキャストグループおよびチャネルについて通知する。修正ＩＧＭＰプロトコルにおいてホストは、ＩＧＭＰｖ３プロトコルで送付するものと同様の応答メッセージをルータに送付するが、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースについての情報が別々に送付されるという違いがある。
ホストが同時に応答することを防止するために複数のタイマが使用され、これらのタイマは、「所属照会」メッセージ中で指定されたタイムスロットの間ホストの応答を配信するように、応答を遅らせる。これは、修正ＩＧＭＰプロトコルおよびＩＧＭＰｖ３プロトコルの場合と同じように作用する。
三つのタイプの「所属照会」メッセージ、すなわち「一般照会」、「グループ特定照会」および「グループおよびソース特定照会」がある。
「一般照会」型メッセージは、一定期間（デフォルトでは１２５秒）毎にルータによって送付され、それによりホストのすべては、「現状レコード」と呼ばれる「所属報告」メッセージを送付することによって、受信を望むマルチキャストグループおよびチャネルについて通知を行う。ホストが「一般照会」要求に応答するためのメッセージは、「グループレコード」と呼ばれるデータブロックを含む。このデータブロックは、以下の二つの型を採り得る。
レコード型＝１ ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥ
レコード型＝２ ＭＯＤＥ＿ＩＳ＿ＥＸＣＬＵＤＥ
上に示したように、図５に示すような「グループレコード」と呼ばれる複数のデータブロックが、単一メッセージまたは図４に示すような「所属報告」に入れて送付される。図５、すなわち「グループレコード」の第１フィールドは、各データブロックの意味を示す「レコード型」フィールドである（図５の例では、「レコード型」フィールドは、「型」として示されるフィールドである）。
ＩＧＭＰｖ３プロトコルでは、各マルチキャストグループはＩＮＣＬＵＤＥ状態またはＥＸＣＬＵＤＥ状態のみであり得るので、各ホストは、各マルチキャストグループについて一つの「グループレコード」を送付するだけであり、その「レコード型」は、ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥグループの状態によってそれぞれ値１または値２を有する。
修正ＩＧＭＰプロトコルでは、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースの情報が別々に格納および送付されるという事実の結果、ホストは、単一マルチキャストグループに関して二つの「グループレコード」を送付する必要があり得る。すなわち、第１の「グループレコード」はレコード型＝１を有してＩＮＣＬＵＤＥソースについて通知し、第２の「グループレコード」はレコード型＝２を有してＥＸＣＬＵＤＥソースについて通知する。このことは、同一マルチキャストグループＧ１に対して二つの「グループレコード」がある図６に見ることができる。
上述と同じ違いが、「グループ特定照会」および「グループおよびソース特定照会」型メッセージに対して存在する。すなわち、ホストは、これらのメッセージに返信するとき、二つの「グループレコード」を使用して、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースから別々に情報を送付することができる。
７）ルータ用プロトコルの説明
修正ＩＧＭＰプロトコルによる動作は、ＩＧＭＰｖ３およびＭＬＤｖ２プロトコルのものと非常に類似している。したがって、後述では、冒頭で言及したＲＦＣ３３７６仕様（ＩＧＭＰｖ３プロトコル）およびＲＦＣ３８１０仕様（ＭＬＤｖ２プロトコル）で使用されるものと同じ名称を、理解を助けるために使用する。
従来技術によるＩＧＭＰｖ３およびＭＬＤｖ２プロトコルに関する主な違いは、修正ＩＧＭＰプロトコルでは、ルータが各マルチキャストグループについて二つの状態レコード、すなわちＩＮＣＬＵＤＥレコードおよびＥＸＣＬＵＤＥレコードを有することである。
修正ＩＧＭＰプロトコルにより、ルータがＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースについての詳細な情報をホストから受信する結果、ルータは、経路指定アルゴリズムをさらに利用することできる。ルータは、ルータが直接接続されるネットワークすべてにおいてＩＧＭＰプロトコルを実行する。マルチキャストルータは、同じネットワークに接続された複数のネットワークインタフェースを有する場合、そのネットワークに接続されたネットワークインタフェースの一つにおいてプロトコルを実行する必要があるだけである。ＩＧＭＰｖ３プロトコルとは異なり、修正ＩＧＭＰプロトコルでは、ルータは、各マルチキャストグループおよびネットワークインタフェースに対して、ＩＮＣＬＵＤＥまたはＥＸＣＬＵＤＥモードのみで作用することはない。したがって、ルータは、ルータをＩＮＣＬＵＤＥモードからＥＸＣＬＵＤＥモードへ、およびその逆への変更を可能にする機構すべてを必要とするわけではない。
各ネットワークカードまたはネットワークインタフェース、およびマルチキャストグループに、修正ＩＧＭＰプロトコルを用いるルータは、マルチキャストＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースからの情報を二つのレコードに別々に格納する。
ＩＮＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＩＮＣＬＵＤＥ，｛ｓｏｕｒｃｅ ｌｉｓｔ ａｎｄ ｔｉｍｅｒｓ｝）
ＥＸＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ｇｒｏｕｐ−ｔｉｍｅｒ，ＥＸＣＬＵＤＥ，｛ｓｏｕｒｃｅ ｌｉｓｔ ａｎｄ ｔｉｍｅｒｓ｝）
上記レコード中、｛ｓｏｕｒｃｅ ｌｉｓｔ ａｎｄ ｔｉｍｅｒｓ｝は、要素（ｓｏｕｒｃｅ−ａｄｄｒｅｓｓ、ｓｏｕｒｃｅ−ｔｉｍｅｒ）のリストであり、ｓｏｕｒｃｅ−ａｄｄｒｅｓｓはソースＩＰアドレスであり、ｓｏｕｒｃｅ−ｔｉｍｅｒは前記ソースに関連づけられたタイマである。
ｔｉｍｅｒは、ゼロに達するまで時間とともに規則正しく減少する値を含むメモリ中の変数である。
したがって、ルータに格納される二つのＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥレコードは、各ｓｏｕｒｃｅ−ａｄｄｒｅｓｓに関連づけられた一つのｓｏｕｒｃｅ−ｔｉｍｅｒを含む。
レコードの消去法に関するポイント２において上で説明したように、マルチキャストグループに関連づけられた各ＥＸＣＬＵＤＥレコードは、ＥＸＣＬＵＤＥ型トラフィック要求を有する報告をルータが受信することなく特定の時間が経過したときに、ＥＸＣＬＵＤＥ状態のレコードの除去に使用されるｇｒｏｕｐ−ｔｉｍｅｒをさらに含む。
上で説明したように、ルータは、図３に示すような、「所属照会」メッセージと呼ばれるメッセージをホストに定期的に送付し、それにより、ホストは、マルチキャストトラフィックの受信を望むグループおよびソースについての通知を返信する。ホストは、ホストが「所属照会」メッセージを送付するのを待たずに、マルチキャストトラフィックを要求するためのメッセージをルータに送付することもできる。
ルータは、「グループ特定照会」メッセージまたは「グループおよびソース特定照会」メッセージを送付した後で、ホストすべてが前記メッセージに返信するのに十分な時間があったことを確認するためにタイマを使用する。タイマの値は、時間とともに徐々に低下し、ルータがホストから「所属報告」メッセージを受信した場合、ルータは、対応するタイマを再度リスタートする。
ＩＮＣＬＵＤＥレコード中のタイマは以下のように動作する。すなわち、特定のネットワークインタフェース、特定のマルチキャストグループおよび特定の包含ソースアドレスに関して、ｓｏｕｒｃｅ−ｔｉｍｅｒがゼロより大きい限り、ルータは、チャネル（ソース、マルチキャストグループ）から前記ネットワークインタフェースを介してマルチキャストトラフィックを伝送し続け、ｓｏｕｒｃｅ−ｔｉｍｅｒがゼロに達すると、ルータは前記トラフィックの伝送を停止し、そのマルチキャストグループのＩＮＣＬＵＤＥソースリストからソースを除去する。
ＥＸＣＬＵＤＥレコード中のタイマは同様に動作するが、ＥＸＣＬＵＤＥソースが二つのリストに分類されるという違いがある。すなわち、そのｓｏｕｒｃｅ−ｔｉｍｅｒがゼロより大きい値もつソースを含む「要求リスト」と呼ばれる第１のリストと、そのｓｏｕｒｃｅ−ｔｉｍｅｒがゼロの値を有するソースを含む「除外リスト」と呼ばれる第２のリストである。
各グループＧｉに関して、ルータは、ＩＮＣＬＵＤＥソースによって要求されたトラフィックすべてを伝送する。さらなるグループＧｉのＥＸＣＬＵＤＥレコードが存在する場合、ルータは、「除外リスト」からＥＸＣＬＵＤＥソースを除き、グループＧｉの残りのトラフィックすべてをさらに伝送する。
「要求リスト」が存在する理由は、ルータにメッセージを送付する複数のホストを有するネットワークにおいて、異なるホストの要求間に衝突があり得るためである。これは、たとえば、ホストが特定のソースからのトラフィックを要求し、別のホストが前記ソースを除くトラフィックを要求するときに起こる。たとえば、ホスト１は第１のＥＸＣＬＵＤＥ（｛Ｓ１｝，Ｇ１）メッセージを送付し、次いで、同じイーサネットネットワーク内の別のホスト２が、第２のＥＸＣＬＵＤＥ（｛Ｓ１，Ｓ２，Ｓ３｝，Ｇ１）メッセージを同じルータに送付する。第２のメッセージを受信すると、ルータが第２のメッセージのソース｛Ｓ１，Ｓ２，Ｓ３｝を「除外リスト」中に置く場合、ホスト１は、ソースＳ１からのトラフィックを除くトラフィックすべてを受信したかったのであるから、受信したかったソースＳ２、Ｓ３からのトラフィックの受信を停止することになる。この問題を回避するために、ルータは、新規メッセージのソースセットと、メッセージを受信する前に「除外リスト」中にあったソースセットとの共通部分のみを「除外リスト」中に置く。残っているＥＸＣＬＵＤＥソースは「要求リスト」に入り、ルータは、任意選択で、グループＧ１のソースＳ２、Ｓ３からのトラフィックの受信を依然として希望するホストがあるかどうかを尋ねるための「グループおよびソース特定照会」メッセージをホストに送付する。
ｓｏｕｒｃｅ−ｔｉｍｅｒの値によってＥＸＣＬＵＤＥソースを二つのリスト、すなわち「要求リスト」および「除外リスト」に分類するための原理は、ＩＧＭＰｖ３およびＭＬＤｖ２プロトコルにおいて適用されるものと同様である。冒頭で言及したＲＦＣ３８１０仕様（ＭＬＤｖ２プロトコル）がこの原理の説明を含んでいる。
表１（この文書の末尾にある）は、本発明による修正ＩＧＭＰプロトコルを適用する改良型ルータの動作を示す。初期状態において、ルータは特定のマルチキャストグループＧについて、ＩＮＣＬＵＤＥソースを有し、またＥＸＣＬＵＤＥソースを有するので、前記マルチキャストグループＧに関する二つの状態レコードを有する。表１において、第１列の「状態１」は、ルータのＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥレコードの初期状態を示す。第２列の「メッセージ」は、ルータによって受信される「所属報告」メッセージの内容を示す。第３列の「状態２」は、「所属報告」メッセージを受信した後のルータの前記レコードの状態を示す。第４であり最後の列の「アクション」は、ルータが前記「所属報告」メッセージを受信した後で実施するアクションを示す。表は、点線で分けられた６行を含む。表の各行は、初期状態に基づき、かつルータが受信したメッセージに依存するルータの動作例である。
表１は、各マルチキャストグループＧを個々に指す。各マルチキャストグループＧは、前記Ｇグループに関してルータが受信するメッセージの影響を受ける独自のＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥ状態レコードを有する。
表１では、以下の名称が使われている。
・（Ａ＋Ｂ）は、ソースセットＡ、Ｂの和集合を意味する。
・（Ａ＊Ｂ）は、ソースセットＡ、Ｂの共通部分を意味する。
・（Ａ−Ｂ）は、ソースセットＡから、Ｂにも見られるソースを引いたものを意味する。
・ＩＮＣＬＵＤＥ（Ａ）は、Ａと呼ばれるソースセットを有するＩＮＣＬＵＤＥレコードをルータがもつことを示す。
・ＥＸＣＬＵＤＥ（Ｘ，Ｙ）は、ＥＸＣＬＵＤＥソースがあるので、ルータがＥＸＣＬＵＤＥ状態レコードを有することを示す。
・Ｘは、「要求リスト」である。
・Ｙは、「除外リスト」である。
・ＧＭＩは、時間値を含む「グループ所属間隔」と呼ばれるパラメータである。２５０秒という値がデフォルトで使用される。
・ＬＭＱＴは、時間値を含む、「最終メンバ照会時間」と呼ばれるパラメータである。これは、ホストが「グループおよびソース特定照会」型メッセージに返信しなければならない時間である。この時間の後、このデータに関心があることをいずれのホストも返信しない場合、ルータはデータの伝送を停止する。
・Ｔ（Ｓ）は、ソースＳのソースタイマである。
・ＧＴは、「グループタイマ」、すなわちマルチキャストグループ全体に対するＥＸＣＬＵＤＥレコードのタイマである。
・ＳＥＮＤ Ｑ（Ｇ，Ｓ）は、マルチキャストグループＧのソースＳに関心があるホストが依然としてあるかどうかを調べるために、ルータが「グループおよびソース特定照会」メッセージをホストに送付することを意味する。このアクションが実施されると、ルータは、ソースＳのタイマもＬＭＱＴ値まで下げる。ルータは、ソースＳのいずれかに興味を示すメッセージを応答中で受信した場合、関心を持たれたホストがある前記ソースのタイマ値を、ＧＭＩに等しい初期値に初期化する。
修正ＩＧＭＰプロトコルのさらなる利点は、ソースすべてが除去される場合もメッセージを消すことができるように、ルータが「ソースおよびグループ特定照会」型メッセージを送付し、メッセージのソースリストから一部のソースを除去する前に二つのＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥレコードを照会することを可能にすることである。
そのために、ルータは、表１の行４に示す実施例のようなＢＬＯＣＫＩＮ（Ｂ）型メッセージを受信すると、ＳＥＮＤ Ｑ（Ｇ，Ａ＊Ｂ）というアクションを実施する前に、同じグループＧに対してＥＸＣＬＵＤＥレコードがあるかどうかを調べ、「除外リスト」中にないソースすべてをメッセージＱ（Ｇ，Ａ＊Ｂ）から除去することができる。というのは、「除外リスト」にないということは、ＥＸＣＬＵＤＥメッセージを用いて誰かがそれらソースを要求していることを意味するからである。
同じ方法で、ルータは、表１の行６に示す実施例のようなＢＬＯＣＫＥＸ（Ｂ）型メッセージを受信すると、ルータは、ＩＮＣＬＵＤＥレコードのソースリストを照会し、その情報を用いて、ＩＮＣＬＵＤＥレコード中に見られるソースをメッセージＱ（Ｇ，Ｂ−Ｙ）から消すことができる。
これら二つの調査によって、多数の「グループおよびソース特定照会」メッセージを除去することができ、その結果、ネットワーク内のトラフィック、およびホストおよびルータが処理しなければならないメッセージの数が削減される。
８）ＩＧＭＰｖ３ホストとの互換性
修正ＩＧＭＰプロトコルを用いるルータは、これ以降は改良型ルータと呼ぶが、ＩＧＭＰｖ３プロトコルを用いるホストと通信することができる。たとえば、イーサネットネットワークは、ＩＧＭＰｖ３プロトコルにより動作するホスト、および自ネットワークに接続されたホストおよび本発明による修正ＩＧＭＰプロトコルにより動作するホストを有することができる。
そのために、改良型ルータは、修正ＩＧＭＰプロトコルの新規メッセージに対処することができ、修正ＩＧＭＰプロトコルにおいて使用されるＩＧＭＰｖ３およびＭＬＤｖ２プロトコルによって使用されるメッセージにも対処する。
改良型ルータは、ＡＬＬＯＷ（Ｂ）型メッセージを受信すると、ＩＮＣＬＵＤＥレコード中のＢ上のソースに対するＡＬＬＯＷＩＮ（Ｂ）メッセージを受信したかのように動作し、ＥＸＣＬＵＤＥ状態レコードを有する、Ｂ上のソースに対するＡＬＬＯＷＥＸ（Ｂ）メッセージを受信したかのように動作する。
ＡＬＬＯＷ（Ｂ）メッセージのＢ上のソースがルータのＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥレコード両方に含まれる場合、ルータの動作は、二つのＡＬＬＯＷＩＮ（Ｂ）およびＡＬＬＯＷＥＸ（Ｂ）メッセージを受信したかのように、またはこの二つのメッセージの一方のみを受信したかのように動作するように設定することができる。ルータ設定では、これらの二つの選択肢のどちらかを選ぶことが可能である。
ルータがＢＬＯＣＫ（Ｂ）型メッセージを受信するケースは、同じ方法で扱われる。すなわち、ルータの動作は、二つのＢＬＯＣＫＩＮ（Ｂ）および／またはＢＬＯＣＫＥＸ（Ｂ）メッセージを受信したかのように動作するように設定することができる。
ルータは、ＴＯ＿ＩＮ（Ｂ）メッセージを受信すると、そのメッセージをＩＳ＿ＩＮ（Ｂ）メッセージであるかのように取り扱う。というのは、ルータはデュアルモードで動作することができるので、ＩＮＣＬＵＤＥモードからＥＸＣＬＵＤＥモードに、およびその逆に変わる必要がないためである。
同様に、ルータは、ＴＯ＿ＥＸ（Ｂ）メッセージを受信すると、そのメッセージをＩＳ＿ＥＸ（Ｂ）メッセージであるかのように取り扱う。
９）改良型ＩＧＭＰプロキシ
本発明による改良型ＩＧＭＰプロキシは、ＩＮＣＬＵＤＥおよびＥＸＣＬＵＤＥソースについての情報を別々に格納および伝送するという点で、冒頭で言及したＲＦＣ４６０５仕様で定義されるＩＧＭＰプロキシとは異なる。
改良型ＩＧＭＰプロキシは、各ネットワークインタフェースおよびマルチキャストグループについて二つのレコードを保存することができる。
ＩＮＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＩＮＣＬＵＤＥ，｛ｓｏｕｒｃｅ ｌｉｓｔ｝）
ＥＸＣＬＵＤＥレコード：（ｍｕｌｔｉｃａｓｔ−ａｄｄｒｅｓｓ，ＥＸＣＬＵＤＥ，｛ｓｏｕｒｃｅ ｌｉｓｔ｝）
ＩＧＭＰプロキシの機能は、ホストに接続されたそのネットワークインタフェースから受信したメッセージをアセンブルして、ＩＧＭＰプロキシをＩＧＭＰルータまたは別のＩＧＭＰプロキシと接続するネットワークインタフェースによってアセンブルまたは要約されたメッセージを送付することである。ＩＧＭＰルータ用の前記ネットワークインタフェースは一般に、上流インタフェースと呼ばれる。
そのために、ＩＧＭＰプロキシは、セクション３において上述したものと同様の規則を適用し、ソケットレコードに基づいてホストのネットワークインタフェースからレコードを推論するが、ＩＮＣＬＵＤＥソース用とＥＸＣＬＵＤＥソース用という二つの別々のレコードがあるのでＥＸＣＬＵＤＥソースレコードからソースリストを推論し、ＩＮＣＬＵＤＥソースについての情報はＩＮＣＬＵＤＥソースレコードに前記情報が含まれるので考慮する必要がないという違いがある。
改良型ＩＧＭＰプロキシが各ネットワークインタフェースおよびマルチキャストグループに対して適用するこれらの規則は以下の通りである。
規則１：各マルチキャストグループについて、各ＩＮＣＬＵＤＥレコードは、プロキシのネットワークインタフェースすべてにおいて受信される前記マルチキャストグループに関するＩＮＣＬＵＤＥメッセージの、ＩＮＣＬＵＤＥソースすべての和集合を含む。
規則２：各マルチキャストグループについて、各ＥＸＣＬＵＤＥレコードは、プロキシのネットワークインタフェースすべてにおいて受信される前記マルチキャストグループに関するＥＸＣＬＵＤＥメッセージの、ＥＸＣＬＵＤＥソースすべての共通部分を含む。
ＩＮＣＬＵＤＥソースおよびＥＸＣＬＵＤＥソースの両方を含むマルチキャストグループについての情報をルータに別々に伝送するために、ポイント４で説明したものと同じ、二つの「グループレコード」を有するメッセージシステムが使用される。
改良型ＩＧＭＰプロキシは、ＩＧＭＰｖ３プロトコルを用いるホストおよび本発明による修正ＩＧＭＰプロトコルを用いるホストと同時に働くことができる。
Figure 2010531586

Claims (15)

  1. データネットワーク内のマルチキャストトラフィックを管理する方法であって、ソース（２９５、２９６、２９７、２９８、２９９）が、少なくとも一つのマルチキャストグループにアドレス指定されたデータを送付し、複数のホスト（２００、２２０、２２５、２３０）が、前記マルチキャストグループ中の、送付を行う前記ソース（２９５、２９６、２９７、２９８、２９９）の一又は複数によって送付される前記データをルータ（２６０）から受信し、前記ホスト（２００、２２０、２２５、２３０）と前記ルータ（２６０）とが、ホスト−ルータ間マルチキャスト通信を可能にする通信プロトコルにより互いに通信するもので、この通信プロトコルにより、前記ホスト（２００、２２０、２２５、２３０）は、前記マルチキャストグループに対して、前記ホスト（２００、２２０、２２５、２３０）が包含ソースリスト上のソースによって送付される前記データの受信を望むことを示す前記包含ソースリストと、前記ホスト（２００、２２０、２２５、２３０）が除外ソースリスト上のソースを除く前記マルチキャストグループのソースすべてからトラフィックの受信を望むことを示す前記除外ソースリストとを定義することができ、前記通信プロトコルに従って、
    ・ホスト（２００、２２０、２２５、２３０）が、各マルチキャストグループおよびネットワークインタフェースについて、二つの別々のレコード、すなわち包含ソースリストを含む包含ソースレコードおよび除外ソースリストを含む除外ソースレコードを格納し、
    ・各ホスト（２００、２２０、２２５、２３０）のネットワークインタフェースが、単一マルチキャストグループに関する、前記ホスト（２００、２２０、２２５、２３０）の包含ソースレコードのソースリストについての情報および／または前記ホスト（２００、２２０、２２５、２３０）の除外ソースレコードのソースリストについての情報を含むメッセージをルータ（２６０）に送付し、
    ・ルータ（２６０）が、各マルチキャストグループについて、二つの別々のレコード、すなわち包含ソースリストについての情報を含む包含ソースレコードおよび除外ソースリストについての情報を含む除外ソースレコードを格納し、
    ・前記ルータ（２６０）が、ホスト（２００、２２０、２２５、２３０）からルータのネットワークインタフェースを介して、包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信したとき、各マルチキャストグループについてルータの包含ソースレコードおよび／またはルータの除外ソースレコードを更新する
    ことを特徴とする方法。
  2. 各ホスト（２００、２２０、２２５、２３０）のネットワークインタフェースが前記ルータ（２６０）に送付するメッセージが、前記ホスト（２００、２２０、２２５、２３０）の包含ソースレコードのソースリストおよび前記ホスト（２００、２２０、２２５、２３０）の除外ソースレコードのソースリストを含む状態メッセージであることを特徴とする、請求項１に記載の方法。
  3. 各ホスト（２００、２２０、２２５、２３０）のネットワークインタフェースが前記ルータ（２６０）に送付するメッセージが、前記ホスト（２００、２２０、２２５、２３０）がホストの包含ソースレコードの変化またはホストの除外ソースレコードの変化を検出したときに送付される状態変更メッセージであり、前記状態変更メッセージが、各マルチキャストグループについて一つまたは二つのデータブロックを含み、前記データブロックの各々が、包含ソースレコードのソースリストの修正についての情報または除外ソースレコードのソースリストの修正についての情報を含み、かつ前記データブロックの各々が、データブロックが包含ソースリストの修正に関するか、それとも除外ソースリストの修正に関するかを示すフィールドを含むことを特徴とする、請求項１に記載の方法。
  4. 前記ルータ（２６０）が、受信したメッセージに含まれる包含ソースリストについての情報を用いて、前記包含ソースによって送付されるデータトラフィックを要求することを特徴とする、請求項１から３のいずれか一項に記載の方法。
  5. 前記通信プロトコルに従って、ホスト（２００、２２０、２２５、２３０）のネットワークインタフェース（２０３、２２２、２２３、２３２）用、前記ネットワークインタフェース（２０３、２２２、２２３、２３２）を用いる各ソケット用、および各マルチキャストグループ用に、一つの包含ソースレコードおよび一つの除外ソースレコードが保持され、ソケット用の前記包含ソースレコードの内容とソケット用の前記除外ソースレコードとに基づいてそれぞれ更新される包含ソースレコードと除外ソースレコードとが、ネットワークインタフェース（２０３、２２２、２２３、２３２）用に保持されることを特徴とする、請求項１から４のいずれか一項に記載の方法。
  6. ルータ（２６０）のネットワークインタフェースに届く前記状態メッセージが、前記ルータ（２６０）が前記包含ソースから前記ルータ（２６０）への経路指定ツリーをセットアップするために適用しなければならない方法についての命令を含むことを特徴とする、請求項１から５のいずれか一項に記載の方法。
  7. 状態メッセージに前記命令を組み込むために、マルチキャストアドレス用に予約された範囲外のマルチキャストアドレスが状態メッセージ中で指示され、ルータ（２６０）が、指示されたマルチキャストアドレスが範囲外であることを検出し、前記マルチキャストアドレスが前記命令を含むと解釈し、かつ前記マルチキャストアドレスに含まれる数字コードの形で前記命令を読み出すことを特徴とする、請求項６に記載の方法。
  8. ルータ（２６０）とホスト（２００、２２０、２２５、２３０）との間の通信プロトコルが、ネットワークインタフェースまたは機器インタフェースによって送付される状態メッセージがＩＧＭＰプロトコル（インターネットグループ管理プロトコル）またはＭＬＤ（マルチキャストリスナ発見）プロトコルのバージョンであり、かつ同一メッセージ中に包含ソースリストおよび除外ソースリストを含むことができることを特徴とする、請求項１から７のいずれか一項に記載の方法。
  9. 請求項１に記載の方法に適合したネットワーク機器（２０３、２０８、２２２、２２３、２３２、２０８、２２８、２２９、２４０）であって、ネットワークインタフェースを備えており、前記ホスト（２００、２２０、２２５、２３０）と前記ルータ（２６０）との間の交換線路中で動作するのに適しており、
    ・各マルチキャストグループ用に、包含ソースレコードおよび除外ソースレコードを保持し、
    ・ルータ（２６０）への近接ネットワークインタフェースに対し、マルチキャストグループに関する前記包含ソースレコードのソースリストについての情報および／または前記除外ソースレコードのソースリストについての情報を含むメッセージを送付し、かつ
    ・前記ネットワーク機器のネットワークインタフェースが別のネットワークインタフェースから包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信するとき、各マルチキャストグループについて包含ソースレコードおよび／または除外ソースレコードを更新する
    ための実行可能な命令を格納することを特徴とする機器。
  10. 請求項５に記載の方法に適合した機器（２００、２２０、２２５、２３０）であって、ネットワークインタフェース（２０３、２２２、２２３、２３２）を備えており、ホストとして動作するのに適しており、前記ネットワークインタフェース（２０３、２２２、２２３、２３２）を用いる各ソケット用、および各マルチキャストグループ用に、包含ソースレコードおよび除外ソースレコードを保持し、前記ネットワークインタフェース（２０３、２２２、２２３、２３２）用に、前記ソケット用包含ソースレコードの内容と前記ソケット用除外ソースレコードとに基づいてそれぞれ更新される包含ソースレコードと除外ソースレコードとを保持するための実行可能な命令を格納することを特徴とする機器。
  11. 請求項１に記載の方法に適合したルータ（２６０）であって、
    ・各マルチキャストグループ用に、二つの別々のレコード、すなわち包含ソースレコードおよび除外ソースレコードを保持し、
    ・前記ルータ（２６０）が、ルータのネットワークインタフェースを介して、包含ソースリストについての情報および／または除外ソースリストについての情報を含むメッセージを受信すると、各マルチキャストグループ用に前記包含ソースレコードおよび／または前記除外ソースレコードを更新する
    ための実行可能な命令を格納することを特徴とする、ルータ。
  12. 前記ルータ（２６０）が、ルータ（２６０）によって受信される前記メッセージに含まれる包含ソースリストについての情報を用いて、前記包含ソースによって送付されるデータトラフィックを他のルータから要求することを特徴とする、請求項１１に記載のルータ（２６０）。
  13. 前記包含ソースによって送付される前記データトラフィックを要求するために、前記ルータ（２６０）が、ＰＩＭ−ＳＩＭ（プロトコル非依存マルチキャスト−スパースモード）プロトコルを用いることを特徴とする、請求項１２に記載のルータ（２６０）。
  14. 特定のマルチキャストグループおよび特定の包含ソースからのトラフィックの受信をホストがそれ以上望まないことを通知するメッセージを受信すると、前記ルータがマルチキャストグループの除外ソースレコードがあるかどうかを調べ、前記レコードが存在し、かつ前記包含ソースと同じＩＰアドレスを有する除外ソースを含まない場合、前記ルータ（２６０）が、前記特定のマルチキャストグループおよび前記特定の包含ソースの前記トラフィックを伝送し続け、前記トラフィックの受信を依然として望む別のホストがあるかどうかを調べるための、ＩＧＭＰプロトコルにおける「グループおよびソース特定照会」型メッセージを送付しないことを特徴とする、請求項１１に記載のルータ（２６０）。
  15. 除外ソースレコードについての情報を更新するためのメッセージであって、特定のソースおよび前記マルチキャストグループからのトラフィックの遮断を要求するメッセージを受信すると、前記ルータ（２６０）が、前記マルチキャストグループの包含ソースレコードがあるかどうかを調べ、前記レコードが存在し、かつ前記メッセージが遮断を要求しているソースと同じＩＰアドレスを有する包含ソースを含む場合、前記ルータ（２６０）が、前記特定のマルチキャストグループおよび前記特定のソースの前記トラフィックを伝送し続け、前記トラフィックの受信を依然として望む別のホストがあるかどうかを調べるための、ＩＧＭＰプロトコルにおける「グループおよびソース特定照会」型メッセージを送付しないことを特徴とする、請求項１１に記載のルータ（２６０）。
JP2010513667A 2007-06-26 2007-10-05 マルチキャストグループを管理する方法と装置 Expired - Fee Related JP5196685B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
ES200701775 2007-06-26
ES200701775 2007-06-26
PCT/EP2007/008655 WO2009000306A1 (en) 2007-06-26 2007-10-05 Method and device for managing multicast groups

Publications (3)

Publication Number Publication Date
JP2010531586A true JP2010531586A (ja) 2010-09-24
JP2010531586A5 JP2010531586A5 (ja) 2010-11-18
JP5196685B2 JP5196685B2 (ja) 2013-05-15

Family

ID=39092048

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010513667A Expired - Fee Related JP5196685B2 (ja) 2007-06-26 2007-10-05 マルチキャストグループを管理する方法と装置

Country Status (8)

Country Link
US (6) US7640333B1 (ja)
EP (2) EP2276198B1 (ja)
JP (1) JP5196685B2 (ja)
CN (1) CN101766000A (ja)
AT (2) ATE493811T1 (ja)
DE (1) DE602007011653D1 (ja)
ES (2) ES2381175T3 (ja)
WO (1) WO2009000306A1 (ja)

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080114695A1 (en) 2006-11-10 2008-05-15 Semantic Components S.L. Process for implementing a method for the on-line sale of software product use licenses through a data network, and software component which allows carrying out said process
EP2276198B1 (en) 2007-06-26 2012-01-18 Media Patents, S. L. Device for managing multicast groups
US20100046516A1 (en) * 2007-06-26 2010-02-25 Media Patents, S.L. Methods and Devices for Managing Multicast Traffic
US8184630B2 (en) 2007-10-15 2012-05-22 Media Patents, S.L. Method for managing multicast traffic in a data network and network equipment using said method
US8064449B2 (en) 2007-10-15 2011-11-22 Media Patents, S.L. Methods and apparatus for managing multicast traffic
EP2215772A1 (en) 2007-10-30 2010-08-11 Media Patents, S. L. Method for managing multicast traffic between routers communicating by means of a protocol integrating the pim protocol; and router and switch involved in said method
US9031068B2 (en) 2008-02-01 2015-05-12 Media Patents, S.L. Methods and apparatus for managing multicast traffic through a switch
WO2009095041A1 (en) 2008-02-01 2009-08-06 Soporte Multivendor S.L. Method for managing multicast traffic through a switch operating in the layer 2 of the osi model, and router and switch involved in said method
WO2009109684A1 (es) * 2008-03-05 2009-09-11 Media Patents, S. L. Procedimiento para monitorizar o gestionar equipos conectados a una red de datos
US7984097B2 (en) 2008-03-18 2011-07-19 Media Patents, S.L. Methods for transmitting multimedia files and advertisements
ES2326949B1 (es) 2008-03-18 2010-07-14 Clarity Systems, S.L. Procedimiento utilizado por un servidor de streaming para realizar una transmision de un fichero multimedia en una red de datos.
US8588056B1 (en) * 2009-04-15 2013-11-19 Sprint Communications Company L.P. Elimination of unwanted packets entering a restricted bandwidth network
US9154532B2 (en) 2009-04-27 2015-10-06 Zaron Remote Llc Methods and apparatus for transmitting multimedia files in a data network
US8325725B2 (en) * 2009-07-20 2012-12-04 Telefonaktiebolaget L M Ericsson (Publ) Efficient host management protocol on multicast capable router
US8379641B2 (en) * 2009-07-20 2013-02-19 Telefonaktiebolaget L M Ericsson (Publ) Light host management protocol on multicast capable router
US8189584B2 (en) 2009-07-27 2012-05-29 Media Patents, S. L. Multicast traffic management in a network interface
CN101719919B (zh) * 2009-12-09 2012-09-05 中兴通讯股份有限公司 一种实现组播源控制的方法及装置
US20110149960A1 (en) * 2009-12-17 2011-06-23 Media Patents, S.L. Method and apparatus for filtering multicast packets
US8495497B2 (en) * 2010-01-28 2013-07-23 International Business Machines Corporation Graphical guides to aid user selection of groups of instruction packages
CN101808004B (zh) * 2010-03-23 2014-04-30 中兴通讯股份有限公司 一种实现任意播汇聚点机制的方法和系统
US20110274107A1 (en) * 2010-05-05 2011-11-10 Telefonaktiebolaget L M Ericsson (Publ) Source selection by routers
CN102340409B (zh) * 2010-07-23 2016-09-07 希姆通信息技术（上海）有限公司 网络设备的管理方法
WO2012137311A1 (ja) 2011-04-05 2012-10-11 三菱重工業株式会社 再生エネルギー型発電装置
WO2012137370A1 (ja) 2011-04-05 2012-10-11 三菱重工業株式会社 再生エネルギー型発電装置
JP5736972B2 (ja) * 2011-05-30 2015-06-17 富士ゼロックス株式会社 蓄積装置及び通信システム
US9590856B1 (en) 2011-07-08 2017-03-07 The Boeing Company Multicast stream mapping
UA113291C2 (xx) 2011-08-04 2017-01-10 Метаболіти транскломіфену і їх застосування
CN103152748B (zh) 2011-12-07 2015-11-25 华为技术有限公司 通信监听方法、基站和终端
US9306836B2 (en) * 2012-07-30 2016-04-05 Hewlett Packard Enterprise Development Lp Searching for multicast consumers in a network of interconnected nodes
AU2013338311A1 (en) 2012-11-02 2015-05-14 Repros Therapeutics Inc. Trans-clomiphene for use in cancer therapy
CN102970152A (zh) * 2012-11-23 2013-03-13 上海斐讯数据通信技术有限公司 静态实现IGMP Snooping的方法
CN104104606B (zh) * 2013-04-01 2018-06-12 南京中兴软件有限责任公司 一种调制解调器及其实现igmp报文版本自适应的方法
US9438435B2 (en) * 2014-01-31 2016-09-06 Intenational Business Machines Corporation Secure, multi-tenancy aware and bandwidth-efficient data center multicast
US9674075B1 (en) * 2014-12-22 2017-06-06 Juniper Networks, Inc. Multicast only fast re-route for PIM ASM mode
US11575775B2 (en) * 2017-01-04 2023-02-07 Extreme Networks, Inc. Overlay IP multicast over unicast IP networks
EP3367122B1 (en) * 2017-02-27 2020-10-14 Nxp B.V. Apparatus for a radio device
US11082294B2 (en) * 2017-08-15 2021-08-03 Mueller International, Llc Broadcast remote firmware update
US10797900B2 (en) * 2018-01-05 2020-10-06 Arista Networks, Inc. System and method of filtering control plane data
US11039374B2 (en) 2018-09-07 2021-06-15 Blackberry Limited Indicating support for a broadcast service
US20200221262A1 (en) * 2019-01-08 2020-07-09 Blackberry Limited Controlling transmission of group-addressed data
US11431635B2 (en) * 2020-03-09 2022-08-30 Vmware, Inc. Load balancing designated routers for multicast groups

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004179811A (ja) * 2002-11-26 2004-06-24 Hitachi Ltd パケット中継装置
JP2005277948A (ja) * 2004-03-25 2005-10-06 Nec Access Technica Ltd マルチキャストパケット配信システム
US20060262792A1 (en) * 2005-05-17 2006-11-23 Alcatel Co-existing static and dynamic IP multicast

Family Cites Families (105)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4024505A (en) 1974-11-18 1977-05-17 Compucorp Interface system for coupling an indeterminate number of peripheral devices to a central processing unit
US4149238A (en) 1977-08-30 1979-04-10 Control Data Corporation Computer interface
US6370142B1 (en) 1995-07-12 2002-04-09 Nortel Networks Limited Method and apparatus for performing per-port IP multicast pruning
JP3123417B2 (ja) 1995-12-26 2001-01-09 日本ビクター株式会社 小規模ネットワークにおける通信方法及び同通信方法に適用される制御装置と従属装置
US5778187A (en) 1996-05-09 1998-07-07 Netcast Communications Corp. Multicasting method and apparatus
US6331983B1 (en) * 1997-05-06 2001-12-18 Enterasys Networks, Inc. Multicast switching
JP4080599B2 (ja) 1998-06-17 2008-04-23 富士通株式会社 通信制御装置およびマルチキャスト対応ｌａｎに適用される通信制御方法
US6219720B1 (en) 1998-08-10 2001-04-17 Micron Technology, Inc. Core logic unit with internal register for peripheral status
US6442617B1 (en) 1999-03-31 2002-08-27 3Com Corporation Method and system for filtering multicast packets in a peripheral component environment
US6721318B1 (en) 1999-07-29 2004-04-13 Nortel Networks Limited Extending router functionality to report static group membership
US6914907B1 (en) 1999-08-05 2005-07-05 Alcatel Canada Inc. Method and apparatus for providing multi-cast transmissions using a distributed router
US6785294B1 (en) 1999-12-30 2004-08-31 Intel Corporation Methods and apparatuses for supporting IGMP and GMRP concurrently
WO2001080590A1 (fr) 2000-04-14 2001-10-25 Ntt Docomo, Inc. Systeme et procede de prestation de services multidiffusion, distributeur d'informations, terminal radio et station radio fixe
AU7170301A (en) 2000-06-29 2002-01-14 Cachestream Corp Virtual multicasting
JP5140225B2 (ja) * 2000-08-14 2013-02-06 オーソ−マクニール・フアーマシユーチカル・インコーポレーテツド 置換ピラゾール
US6847638B1 (en) * 2000-10-16 2005-01-25 Cisco Technology, Inc. Multicast system for forwarding desired multicast packets in a computer network
US7283521B1 (en) 2000-10-26 2007-10-16 Nortel Networks Limited System and method for reporting communication related information in a packet mode communication
US7068598B1 (en) 2001-02-15 2006-06-27 Lucent Technologies Inc. IP packet access gateway
US6977891B1 (en) 2001-06-30 2005-12-20 Extreme Networks, Inc. Method and system for multicast traffic reduction
US20030067917A1 (en) 2001-10-04 2003-04-10 Adc Broadband Access Systems, Inc. IGMP proxy
US7355970B2 (en) 2001-10-05 2008-04-08 Broadcom Corporation Method and apparatus for enabling access on a network switch
WO2003049357A2 (en) 2001-12-07 2003-06-12 Telefonaktiebolaget Lm Ericsson (Publ) Lawful interception of end-to-end encrypted data traffic
EP1318628B1 (en) 2001-12-10 2005-01-12 Alcatel Method and apparatus of directing multicast traffic in an Ethernet MAN
US7272652B1 (en) 2002-04-30 2007-09-18 Alcatel Lucent Facilitating accelerated processing of internet group management protocol messages
US7346053B1 (en) * 2002-05-07 2008-03-18 Cisco Technology, Inc. Methods and apparatus for supporting IP multicast for a mobile router
US6741595B2 (en) 2002-06-11 2004-05-25 Netrake Corporation Device for enabling trap and trace of internet protocol communications
US7236465B2 (en) * 2002-06-13 2007-06-26 International Business Machines Corporation System and method for gathering multicast content receiver data
US7526523B2 (en) 2002-06-21 2009-04-28 British Telecommunications Public Limited Company Timer-based feedback in multicast communication
US7936752B2 (en) 2002-07-31 2011-05-03 Cisco Technology, Inc. Source specific multicast group to source mapping
ES2229073T3 (es) 2002-08-08 2005-04-16 Alcatel Interceptacion legal de llamadas voip en redes basadas en ip.
US7228356B2 (en) 2002-12-12 2007-06-05 Alcatel Canada Inc. IGMP expedited leave triggered by MAC address
US7233987B2 (en) * 2002-12-20 2007-06-19 Alcatel Canada Inc. System and method for converting requests between different multicast protocols in a communication network
JP4077330B2 (ja) * 2003-02-06 2008-04-16 富士通株式会社 データ生成装置
US7797459B1 (en) 2003-02-11 2010-09-14 At&T Intellectual Property Ii, L.P. Access independent common architecture for real-time communications services for networking environments
US20040165709A1 (en) 2003-02-24 2004-08-26 Pence Robert Leslie Stealth interception of calls within a VoIP network
US20040219911A1 (en) 2003-03-25 2004-11-04 Kouchri Farrokh Mohammadzadeh Virtual communications assistance for law enforcement act (CALEA) device
JP4066867B2 (ja) * 2003-03-31 2008-03-26 富士通株式会社 移動ノード、パケット中継装置、パケット転送方法
US7447909B2 (en) 2003-06-05 2008-11-04 Nortel Networks Limited Method and system for lawful interception of packet switched network services
US7532622B2 (en) * 2003-06-16 2009-05-12 National University Of Singapore Methods, devices and software for merging multicast groups in a packet switched network
US7450551B2 (en) * 2003-07-14 2008-11-11 Samsung Electronics Co., Ltd. Multicast transmission method in GEM mode in Gigabit-capable passive optical network and method of processing frame
JP2005065045A (ja) 2003-08-18 2005-03-10 Kddi Corp Ｌ２スイッチ装置及びその制御方法
US7412726B1 (en) 2003-12-08 2008-08-12 Advanced Micro Devices, Inc. Method and apparatus for out of order writing of status fields for receive IPsec processing
DE60324821D1 (de) * 2003-12-23 2009-01-02 Motorola Inc Routen-optimierter Multicast-Verkehr für einen mobilen Netzknoten
US20050175156A1 (en) 2004-02-05 2005-08-11 Afshar Siroos K. Calea in a VPN environment (formerly called restricted anti-calea
US7587757B2 (en) 2004-02-11 2009-09-08 Texas Instruments Incorporated Surveillance implementation in managed VOP networks
JP4382528B2 (ja) * 2004-02-27 2009-12-16 富士通株式会社 マルチキャストネットワーク装置，マルチキャストネットワークシステムおよびマルチキャスト方法
US7502474B2 (en) 2004-05-06 2009-03-10 Advanced Micro Devices, Inc. Network interface with security association data prefetch for high speed offloaded security processing
ES2297351T3 (es) * 2004-05-28 2008-05-01 Alcatel Lucent Sistema de telecomunicacion de banda ancha y metodo utilizado para reducir la latencia del cambio de canal por un receptor multimedia.
EP1759488A1 (en) 2004-06-14 2007-03-07 Bryan Shadish Distributed igmp processing
US8688834B2 (en) * 2004-07-09 2014-04-01 Toshiba America Research, Inc. Dynamic host configuration and network access authentication
US20060018255A1 (en) 2004-07-26 2006-01-26 Avaya Technology Corp. Defining a static path through a communications network to provide wiretap law compliance
DE102004040454B4 (de) 2004-08-20 2006-05-18 Siemens Ag Vorrichtung zum Nutzdatenabgriff multimedialer Verbindungen in einem Paketnetz
EP1782293A2 (en) 2004-08-20 2007-05-09 Enterasys Networks, Inc. System, method and apparatus for traffic mirror setup, service and security in communication networks
DE102004040482B4 (de) 2004-08-20 2006-05-24 Siemens Ag Vorrichtung zum Nutzdatenabgriff multimedialer Verbindungen in einem Paketnetz
JP2006101471A (ja) * 2004-09-06 2006-04-13 Hitachi Communication Technologies Ltd マルチキャスト冗長経路ルータ、マルチキャスト冗長化方式
US8619774B2 (en) * 2004-10-26 2013-12-31 Cisco Technology, Inc. Method and apparatus for providing multicast messages within a virtual private network across a data communication network
US7464267B2 (en) 2004-11-01 2008-12-09 Innomedia Pte Ltd. System and method for secure transmission of RTP packets
WO2006053027A2 (en) * 2004-11-09 2006-05-18 Nexthop Technologies, Inc. Systems and methods for multicast routing on packet switched networks
US7783880B2 (en) 2004-11-12 2010-08-24 Microsoft Corporation Method and apparatus for secure internet protocol (IPSEC) offloading with integrated host protocol stack management
US8014390B2 (en) 2004-11-30 2011-09-06 Broadcom Corporation Policy based routing using a fast filter processor
US7489684B2 (en) 2004-12-08 2009-02-10 Alcatel Lucent Access network architecture for multicasting using xDSL and IGMP
US7701938B1 (en) * 2004-12-13 2010-04-20 Cisco Technology, Inc. Advanced multicast support for cable
US7835276B2 (en) * 2004-12-30 2010-11-16 Cisco Technology, Inc. Admission control mechanism for multicast receivers
US8194640B2 (en) 2004-12-31 2012-06-05 Genband Us Llc Voice over IP (VoIP) network infrastructure components and method
US20060159091A1 (en) * 2005-01-19 2006-07-20 Arjen Boers Active multicast information protocol
CN100396055C (zh) * 2005-02-04 2008-06-18 华为技术有限公司 组播源过滤的处理方法
US7577137B2 (en) 2005-02-15 2009-08-18 Telefonaktiebolage L M Ericsson (Publ) Optimized multicast distribution within a hybrid PPPoE/IPoE broadband access network
US7724739B2 (en) * 2005-03-18 2010-05-25 Cisco Technology, Inc. Source specific multicast layer 2 networking device and method
US8089964B2 (en) * 2005-04-05 2012-01-03 Cisco Technology, Inc. Transporting multicast over MPLS backbone using virtual interfaces to perform reverse-path forwarding checks
US7646739B2 (en) * 2005-04-05 2010-01-12 Cisco Technology, Inc. Multicast routing over unidirectional links
US7477654B2 (en) 2005-04-14 2009-01-13 Alcatel Lucent Method and system for managing access to multicast groups
US7710983B2 (en) * 2005-04-21 2010-05-04 Cisco Technology, Inc. Method and apparatus for determining information associated with a particular multicast channel in a multicast network
US7599289B2 (en) 2005-05-13 2009-10-06 Lockheed Martin Corporation Electronic communication control
US20070041558A1 (en) 2005-05-17 2007-02-22 Parayil Shiby S Subscriber status determination and call content interception
CN1881913A (zh) * 2005-06-15 2006-12-20 上海贝尔阿尔卡特股份有限公司 一种网络接入设备中用户接口组播管理方法及其装置
US8503446B2 (en) 2005-08-29 2013-08-06 Alcatel Lucent Multicast host authorization tracking, and accounting
US8689317B2 (en) 2005-12-19 2014-04-01 Level 3 Communications, Llc Providing SIP signaling data for third party surveillance
US20070168555A1 (en) * 2006-01-18 2007-07-19 Dorenbosch Jheroen P Efficient multicast call setup method and system
US7839850B2 (en) * 2006-01-30 2010-11-23 Juniper Networks, Inc. Forming equal cost multipath multicast distribution structures
US7512146B1 (en) 2006-01-31 2009-03-31 Garrettcom, Inc. Method and apparatus for layer 2 multicast traffic management
US7684547B2 (en) 2006-02-07 2010-03-23 International Business Machines Corporation Wiretapping VoIP calls
CN101438256B (zh) * 2006-03-07 2011-12-21 索尼株式会社 信息处理设备、信息通信系统、信息处理方法
US7693146B2 (en) * 2006-03-10 2010-04-06 Cisco Technology, Inc. Method and system for filtering traffic from unauthorized sources in a multicast network
US7599393B1 (en) 2006-03-24 2009-10-06 Sierra Wireless, Inc. Architecture for emulating an ethernet network interface card
US7953089B1 (en) * 2006-05-16 2011-05-31 Cisco Technology, Inc. Systems and methods for multicast switching in a private VLAN
CN101079728B (zh) * 2006-05-26 2010-11-10 华为技术有限公司 一种优化组管理协议的方法、服务器及系统
US8934609B2 (en) 2006-06-21 2015-01-13 Genband Us Llc Method and apparatus for identifying and monitoring VoIP media plane security keys for service provider lawful intercept use
US8050273B2 (en) 2006-06-22 2011-11-01 Alcatel Lucent Lawful interception in IP networks
US8249068B2 (en) * 2006-10-20 2012-08-21 Alcatel Lucent Method and apparatus for establishing multicast groups
US7672325B2 (en) 2006-11-28 2010-03-02 Alcatel Lucent Method and apparatus for improved IGMP group membership messaging
CN101652974B (zh) 2007-02-09 2013-01-02 诺基亚西门子通信有限责任两合公司 Ip网络中用于动态带宽管理的方法和装置
US8724533B2 (en) * 2007-03-07 2014-05-13 Cisco Technology, Inc. Multicast support by mobile routers in a mobile ad hoc network
EP2276198B1 (en) 2007-06-26 2012-01-18 Media Patents, S. L. Device for managing multicast groups
US20100046516A1 (en) 2007-06-26 2010-02-25 Media Patents, S.L. Methods and Devices for Managing Multicast Traffic
US7813287B2 (en) * 2007-08-29 2010-10-12 Alcatel Lucent Fast TV channel changing in IPTV network
US8064449B2 (en) 2007-10-15 2011-11-22 Media Patents, S.L. Methods and apparatus for managing multicast traffic
US8184630B2 (en) 2007-10-15 2012-05-22 Media Patents, S.L. Method for managing multicast traffic in a data network and network equipment using said method
US8346912B2 (en) 2007-10-15 2013-01-01 Dell Products, Lp System and method of emulating a network controller within an information handling system
EP2215772A1 (en) 2007-10-30 2010-08-11 Media Patents, S. L. Method for managing multicast traffic between routers communicating by means of a protocol integrating the pim protocol; and router and switch involved in said method
EP2215595B1 (en) 2007-11-23 2012-02-22 Media Patents S.L. A process for the on-line distribution of audiovisual contents with advertisements, advertisement management system, digital rights management system and audiovisual content player provided with said systems
US8649309B2 (en) * 2008-01-24 2014-02-11 Samsung Electronics Co., Ltd. Apparatus and method for creating data path for broadcasting service in cellular network
WO2009095041A1 (en) 2008-02-01 2009-08-06 Soporte Multivendor S.L. Method for managing multicast traffic through a switch operating in the layer 2 of the osi model, and router and switch involved in said method
US9031068B2 (en) 2008-02-01 2015-05-12 Media Patents, S.L. Methods and apparatus for managing multicast traffic through a switch
WO2009109684A1 (es) 2008-03-05 2009-09-11 Media Patents, S. L. Procedimiento para monitorizar o gestionar equipos conectados a una red de datos
US8189584B2 (en) 2009-07-27 2012-05-29 Media Patents, S. L. Multicast traffic management in a network interface

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004179811A (ja) * 2002-11-26 2004-06-24 Hitachi Ltd パケット中継装置
JP2005277948A (ja) * 2004-03-25 2005-10-06 Nec Access Technica Ltd マルチキャストパケット配信システム
US20060262792A1 (en) * 2005-05-17 2006-11-23 Alcatel Co-existing static and dynamic IP multicast

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JPN6012027651; 'Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ，　Ｖｅｒｓｉｏｎ　３' Ｎｅｔｗｏｒｋ　Ｗｏｒｋｉｎｇ　Ｇｒｏｕｐ　Ｒｅｑｕｅｓｔ　ｆｏｒ　Ｃｏｍｍｅｎｔｓ：　３３７６ , 200210, Ｐａｇｅ１-５３ *

Also Published As

Publication number Publication date
WO2009000306A1 (en) 2008-12-31
ES2381175T3 (es) 2012-05-23
US20100054248A1 (en) 2010-03-04
ATE493811T1 (de) 2011-01-15
US20100054247A1 (en) 2010-03-04
ES2358546T3 (es) 2011-05-11
EP2276198A1 (en) 2011-01-19
US7921198B2 (en) 2011-04-05
US7908354B2 (en) 2011-03-15
US20100054249A1 (en) 2010-03-04
US7640333B1 (en) 2009-12-29
US8086716B2 (en) 2011-12-27
CN101766000A (zh) 2010-06-30
EP2078376B1 (en) 2010-12-29
EP2078376A1 (en) 2009-07-15
DE602007011653D1 (de) 2011-02-10
US8094602B2 (en) 2012-01-10
US20090310609A1 (en) 2009-12-17
US20090319689A1 (en) 2009-12-24
US20120063456A1 (en) 2012-03-15
JP5196685B2 (ja) 2013-05-15
EP2276198B1 (en) 2012-01-18
ATE542327T1 (de) 2012-02-15

Similar Documents

Publication Publication Date Title
JP5196685B2 (ja) マルチキャストグループを管理する方法と装置
US20100046516A1 (en) Methods and Devices for Managing Multicast Traffic
US8571028B2 (en) Methods and apparatus for managing multicast traffic
US8416777B2 (en) Method for managing multicast traffic in a data network and network equipment using said method
JP5343127B2 (ja) 端末マルチキャスト状態の取得方法
Semeria et al. Introduction to IP multicast routing
WO2008138248A1 (fr) Procédé, carte d'interface et routeur destinés à transmettre un message
Ballardie et al. Core Based Tree (CBT) Multicast
US20100135298A1 (en) Method and system for providing source specific multicast service on ethernet network
KR20070108968A (ko) 디지털 가입자 회선 장치의 멀티캐스트 그룹 가입자관리방법

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100928

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100928

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120523

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120605

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20120814

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20120821

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: 20130108

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130204

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160215

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees