JP2008236230A - ネットワークシステム - Google Patents

ネットワークシステム Download PDF

Info

Publication number
JP2008236230A
JP2008236230A JP2007071241A JP2007071241A JP2008236230A JP 2008236230 A JP2008236230 A JP 2008236230A JP 2007071241 A JP2007071241 A JP 2007071241A JP 2007071241 A JP2007071241 A JP 2007071241A JP 2008236230 A JP2008236230 A JP 2008236230A
Authority
JP
Japan
Prior art keywords
packet transfer
transfer device
user terminal
distribution
group address
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
JP2007071241A
Other languages
English (en)
Other versions
JP4773387B2 (ja
Inventor
Kozo Ikegami
幸三 池上
Hiroaki Miyata
裕章 宮田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Communication Technologies Ltd
Original Assignee
Hitachi Communication Technologies Ltd
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 Hitachi Communication Technologies Ltd filed Critical Hitachi Communication Technologies Ltd
Priority to JP2007071241A priority Critical patent/JP4773387B2/ja
Priority to US12/022,376 priority patent/US20080232368A1/en
Priority to CN200810009045XA priority patent/CN101272322B/zh
Publication of JP2008236230A publication Critical patent/JP2008236230A/ja
Application granted granted Critical
Publication of JP4773387B2 publication Critical patent/JP4773387B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/16Multipoint routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5069Address allocation for group communication, multicast communication or broadcast communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】ユーザ端末とルータが、レイヤ2スイッチを介してPoint to Point接続されるネットワーク上で、トラヒックを抑えつつマルチキャスト通信し、認証・課金を実現する。
【解決手段】ユーザ端末H1が接続要求を行うと、ルータ200は認証サーバS2から、ユーザ端末H1が参加できるグループアドレスを取得する。ルータ200の情報を、参加確認(Query)時にパケットに付与し、レイヤ2スイッチ100に送信する。レイヤ2スイッチ100は、参加確認受信によりユーザ端末H1がどのグループアドレスに参加できるかを把握でき、レイヤ2スイッチ100で認証を伴う配信制御が可能となる。レイヤ2スイッチ100では、配信開始/終了時間、トラヒック等の課金に必要な情報を収集し、ルータ200へ送信する。ルータ200は、該情報を基に課金情報を作成し課金サーバS2へ送信する。
【選択図】図3

Description

本発明は、ネットワークシステムに係り、特に、放送などのコンテンツ情報配信に用いられるマルチキャストの認証及び課金を行うためのネットワークシステムに関する。
ユニキャスト通信を放送型通信に用いた場合、データを配信するサーバとそのデータを受信するユーザ端末が1対1となるため、配信サーバはユーザ端末数分のデータを同時に配信する。このため、配信サーバに負荷がかかりかつトラヒック量も増大する。
これらの課題を解決する技術として、ある特定の複数の宛先に同時にデータを配信する放送型の通信技術としてマルチキャスト通信がある。配信サーバとユーザ端末間に設置されるパケット転送装置(ルータ、ゲートウェイなど)に、IETF(Internet Engineering Task Force)で標準となっているIGMP(Internet Group Membership Protocol:非特許文献1、2参照)やMLD(Multicast Listener Discovery:非特許文献3参照)を実装することで、パケット転送装置が配信サーバからのデータをコピーし、配信要求のあったユーザ端末だけにデータを送信する。これによって配信サーバはパケット転送装置宛てにデータを送信するだけで済むため配信サーバの負荷が抑えられ、かつ配信サーバとパケット転送装置間のトラヒックも抑えられる。
また、マルチキャスト通信を用いてデータ配信のサービスを行う場合、認証や課金が必要な場合もある。これらの実現方法の一例として、IGAP(Internet Group membership Authentication Protocol:非特許文献4)がIETFのドラフトとなっている。IGMPパケットにユーザ識別情報やパスワードなど認証に必要な情報を付加し、マルチキャストルータがその情報を基にRADIUS(Remote Authentication Dial In User Service:非特許文献5、6参照)を用いて認証・課金サーバに問い合わせを行う。その問い合わせ結果を基に、マルチキャストルータは要求のあったユーザ端末に対してデータ配信するかを判断する。接続記録から課金処理も可能となる。
上記方法を用いた場合、ユーザ端末が多数となると高価なマルチキャストルータを多数必要とする。少しでも高価なマルチキャストルータを減らす方法が、例えば、特開2004−357200号公報(特許文献1)に開示されている。この技術では、ユーザ端末とルータ間に設置されるレイヤ2スイッチなどにIGAPパケットをスヌーピングする機能を持たせ、レイヤ2スイッチでデータ配信の制御を行うことでルータの数を抑えることができる。特開2004−357200で号公報に開示された技術では、レイヤ2スイッチの配下のユーザ端末が同一サブネット内に存在することが前提条件となる。ユーザ端末が同一サブネットに存在している場合、セキュリティにもあまい。
一方、上記のようなマルチキャスト通信を用いたサービスが行われる実際のアクセス系のネットワークでは、インターネット接続のユーザ認証や、セキュリティ確保のためにユーザ端末とルータ間はPPPoE(Point to Point Protcol over Ethernet(Ethernetは登録商標):非特許文献7参照)で接続されている場合が多い。PPPoEを用いた場合、ユーザ端末とルータは論理的にPoint to Pointで接続される。そのため、このようなネットワーク上でマルチキャスト通信を行う場合、ルータの物理的な回線数以上にユーザ端末と論理的に接続できるので、一旦レイヤ2スイッチでユーザ端末を終端することでマルチキャストルータの数を抑えて、マルチキャストの認証・課金、配信データの制御が可能となる。さらにこの場合に、ユーザ端末のPPPoEの認証時にルータが認証サーバからユーザがどのマルチキャストグループに参加可能であるかという情報を受信し、ルータでPPPoEとマルチキャストとの対応テーブルを持つことで、ユーザ端末から配信要求を受信すると、認証サーバに問い合わせすることなく配信の可否が行える(例えば、特許文献2、特許文献3参照)。
しかし、上記のようにユーザ端末とルータ間がPoint to Pointで接続されると、ルータが配信データをそのルータ配下に接続されるユーザ端末数分だけコピーして送信しなければならない。そのため、レイヤ2スイッチとルータ間のトラヒックは特開2004−357200号公報の場合と比較してユーザ端末数分だけ倍増し、コピーを行うルータにも負荷がかかってしまう。
この課題を解決する技術のひとつが、特開2006−109047号公報(特許文献4)に開示されている。この技術では、ユーザ端末とルータ間が論理的にPoint to Pointで接続されている場合に、ユーザ端末とルータ間に設置されるレイヤ2スイッチが、ルータとの間にマルチキャスト専用のコネクションをはり、配下に接続されるユーザ端末の代わりに配信データを受信、コピー、送信することでレイヤ2スイッチとルータ間のトラヒックを抑えられ、ルータの負荷も低減できる。
RFC1112 RFC2236 RFC2710 http://www.potaroo.net/ietf/all−ids/draft−hayashi−igap−03.txt RFC2865 RFC2866 RFC2516 特開2004−357200号公報 特開2006−42223号公報 特開2006−148750号公報 特開2006−109047号公報
ユーザ端末とルータ間が、セキュリティやユーザ管理のためにPPPoEなどにより論理的にPoint to Pointとなっているネットワークにおいて、マルチキャスト通信を用いてデータ配信サービスを実施する場合に、特開2006−109047号公報の技術ではユーザ端末とルータ間に設置されるレイヤ2スイッチが配下に接続されるユーザ端末に代わって配信要求や配信データの受信を行う。これによって、トラヒックやルータへの負荷を低減させることができる。
しかし、ルータはユーザ端末からではなくレイヤ2スイッチから配信要求を受け、またユーザ端末宛てにデータを配信するのではなくレイヤ2スイッチに配信データを送信する。そのため、ルータは、マルチキャストパケットに関するユーザ情報を把握することができないので、IGAPや特開2006−148750号公報などの方法で、ルータがマルチキャストサービス時に認証・課金を行うことができない場合がある。
例えば、レイヤ2スイッチの配下に接続されているユーザ端末があるマルチキャストデータの自端末への配信要求をすると、その配信要求はレイヤ2スイッチで受信され、レイヤ2スイッチは代理でルータに、自スイッチへの配信要求をする。従って、ルータは、レイヤ2スイッチへの配信要求を受信するので、どのユーザ端末からの配信要求なのかを知る術がない。従って、ルータは、端末の認証等をするための認証サーバへ問い合わせができない場合がある。
また、ルータは、レイヤ2スイッチからの配信要求に応じて、レイヤ2スイッチにマルチキャストデータを配信するため、どの端末がデータを受信しているかわからない。従って、ルータが課金サーバなどを用いて端末毎の課金をすることができない場合がある。
さらに、レイヤ2スイッチでは、どの端末がマルチキャストデータの配信が許可され、及び、配信が拒否されているのか、配信可否の判断ができない場合がある。
本発明は、以上の点に鑑み、上記ネットワークにおいてレイヤ2スイッチで管理するユーザ情報をルータが知る手段、その情報をもとにルータが認証・課金のための処理を行う手段を有するネットワークシステムを提供することを目的のひとつとする。また、本発明は、認証結果をもとにレイヤ2スイッチが配信データの制御を行う手段を提供することを目的のひとつとする。本発明は、トラヒックを抑えつつ安価で認証や課金を伴うマルチキャストサービスを実現するためのネットワークシステムを提供することを目的のひとつとする。
本発明は、セキュリティやユーザ管理のためにPPPoEなどで、ユーザ端末とルータ間が論理的にPoint to Pointとなっているアクセス系のネットワーク上で、マルチキャスト通信によるデータ配信サービスを行う場合に、安価な装置構成で、かつトラヒックや装置への負荷を抑えて、様々な認証・課金サービス、ユーザ管理を実現することを目的のひとつとする。
また、本発明は、ユーザ端末ユーザ端末に対して新たに機能追加や設定が不要で、PPP接続の認証だけで済むため、マルチキャスト用のユーザID(ユーザ識別子)やパスワードも不要であり、ユーザがマルチキャストサービスを受けるために再度認証することを必要としないため、ユーザに負担をかけることなく実現することを目的のひとつとする。
ユーザ端末がルータに対してPPP接続要求をすると、それを受けたルータは認証サーバへ問い合わせを行う。認証サーバでは、ユーザID、パスワード、そのユーザが参加できるグループアドレスの情報を管理しており、PPP接続の認証結果と、参加できるグループアドレスとをルータへ送信する。この後に、ユーザ端末からあるマルチキャストグループへの参加要求(Join)が送信されると、レイヤ2スイッチでユーザ端末からの参加要求(Join)を終端する。しかし、レイヤ2スイッチはそのユーザ端末に対する配信許可/拒絶がわからないので、ルータに対してこのユーザ端末の情報を付与した参加要求(Join)をルータに対して送信する。
ルータは、参加要求の情報と認証サーバから受信したユーザ情報と比較し、情報に差分がある場合にはレイヤ2スイッチにルータが保持している情報を参加確認(Query)に付与し送信する。このルータからの情報によって、レイヤ2スイッチではそのユーザ端末に対する配信の許可/拒絶が分かるようになり、データを配信するかどうかを判断できるようになる。さらに、ルータの定期的な参加確認(Query)により常にルータの情報とレイヤ2スイッチの情報の整合性を維持する。これにより、上記のようにレイヤ2スイッチがルータへ確認することなく、レイヤ2スイッチだけで配信の許可/拒絶を判断できるようになる。ただし、ユーザ端末がPPP接続後に、あるグループアドレスへの参加許可となるとルータの情報を更新する必要があるので、レイヤ2スイッチからのユーザ情報でルータの管理するユーザ情報に該当するものがなかった場合、ルータが認証サーバに対して再度問い合わせを行う。また、ルータのユーザ情報を更新し、その更新した情報をレイヤ2スッチへ送信する。これにより、レイヤ2スイッチでも最新のユーザ情報を把握することが可能となる。
さらに、レイヤ2スイッチが、あるユーザ端末を「拒絶」とした場合、その後にそのユーザ端末が参加許可となってもそのユーザ端末がPPP再接続をしない限り、ルータが認証サーバへ問い合わせる契機がないとレイヤ2スイッチで「許可」となることがない。そこで、レイヤ2スイッチで「拒絶」となっているユーザ情報には有効期限を設けることで、その有効期限が切れてからそのユーザ端末から参加要求(Join)があればルータが認証サーバへ問い合わせる。これにより、ユーザ端末がPPP再接続をしなくてもレイヤ2スッチのユーザ情報更新を可能にする。
また、レイヤ2スイッチは、配信の許可/拒絶だけでなく、実際にユーザ端末への配信ログを記録する。ユーザ端末が参加していたグループアドレスから離脱したことを契機に、レイヤ2スイッチは、配信ログをルータへ送信する。ルータが、ユーザIDなど課金に必要な情報を追加し、課金サーバへ送信することで課金を可能とする。ユーザ端末が離脱する契機としては、例えば、ユーザ端末からの離脱宣言をレイヤ2スイッチが受信したとき、レイヤ2スイッチからユーザ端末への参加確認(Query)に対する応答(Report)がなかったとき、PPP接続が切断されたときなどがある。1つ目と2つ目はレイヤ2スイッチが離脱を認識することができるが、3つ目の契機についてはレイヤ2スイッチだけでは離脱を認識することができない。そこで、PPP接続が切断されたことを知ることができるルータが、PPP切断時にユーザ情報をレイヤ2スイッチに参加確認(Query)に付与して送付する。これにより、レイヤ2スイッチが切断を認識することができる。
さらに、PPP接続時に、認証サーバから参加できるグループアドレスだけでなくその有効期限を送信し、ルータがレイヤ2スイッチに対してユーザ情報を送信する際にその有効期限を合わせて送信する。レイヤ2スイッチではその有効期限の間だけ配信を「許可」とすることで、例えばプリペイド式課金が可能となる。このとき、有効期限の代わりにトラヒックを指定し、あるトラヒックを配信したら配信をとめるようにしてもよい。
また、課金方法の別手段として、
マルチキャスト制御パケットに関しては、レイヤ2スイッチで終端するのではなく、レイヤ2スイッチでスヌーピングして配信制御テーブルを更新し、そのマルチキャスト制御パケットは通常パケットと同様に転送する。ルータは、ユーザ端末からの参加要求(Join)の受信を契機に課金サーバへ課金開始通知をする。また、ユーザ端末からの離脱宣言(Leave)を受信した場合、参加確認(Query)に対する応答(Report)がなかった場合、PPP接続が切断された場合などに、課金サーバへ課金終了通知を行う。課金サーバは、ユーザ端末が参加した時刻と、離脱した時刻を把握することで課金が可能となる。さらに、課金終了通知時には、レイヤ2スイッチからの課金情報を合わせて課金サーバへ送信することでより正確な課金や従量課金が実現できる。
また、本発明では、上記課題を解決する手段として、レイヤ2スイッチやルータは、例えば複数の回線インタフェース、回線インタフェース制御部、パケットの解析/編集処理を行うプロセッサを具備する。メモリ上に保持するテーブルとしては、ユーザ情報を管理するテーブル、装置間のマルチキャスト用コネクションの管理をおこなうテーブルを具備する。
本発明の第2のパケット転送装置(ルータ)は、例えば、
複数のユーザ端末とPoint to Ponitで接続されるパケット転送装置であって、
ユーザ端末の管理を行うユーザ管理テーブルと、配下に接続される下位パケット転送装置とのマルチキャスト用コネクション管理テーブルと、配下に接続される下位パケット転送装置からマルチキャストパケットを受信すると処理を行うプロセッサを備え、
前記プロセッサは配下に接続される下位パケット転送装置からユーザ情報を受信すると、パケット転送装置が管理しているユーザ管理テーブルと比較し、下位パケット転送装置のユーザ情報で配信許可が不明となっていた場合に、パケット転送装置のユーザ情報を下位パケット転送装置に送信し、下位パケット転送装置からユーザ情報がパケット転送装置のユーザ情報になかった場合には認証サーバへ問い合わせを行う。
また、本発明の第1のパケット転送装置(レイヤ2スイッチ)は、例えば、
上述の第2のパケット転送装置の配下に接続され、複数のユーザ端末を終端する下位パケット転送装置であって、
ユーザ端末への配信を制御する配信制御テーブルと、上位に接続される第2のパケット転送装置とのマルチキャスト用コネクション管理テーブルと、配下に接続されるユーザ端末からマルチキャストパケットを受信すると処理を行うプロセッサを備え、
前記プロセッサは、配下に接続されるユーザ端末からのマルチキャストパケットを受信すると、配信制御テーブルを更新し、上位パケット転送装置へ参加要求や参加確認に対する応答時にユーザ情報を送信し、上位パケット転送装置からユーザ情報を受信すると、その情報を元に配信制御テーブルを更新し、配信制御テーブルの情報を元に各ユーザ端末へのマルチキャストパケットの転送制御を行う。
上述の第1のパケット転送装置は、前記ユーザ管理テーブルには課金に必要な情報が記録され、前記プロセッサはユーザ端末から離脱宣言を受信すると、またユーザ端末から参加確認に対する応答がなかった場合、また上位パケット転送装置からユーザ情報を受信し配信制御テーブルを更新したときに配信を止めたとき、上位パケット転送装置にユーザ情報を送信することを特徴のひとつとする。
上述の第2のパケット転送装置は、ユーザ端末のPPP接続が切断されると、前記配信情報テーブルを更新し下位パケット転送装置に送信することを特徴のひとつとする。
上述の第2のパケット転送装置は、下位パケット転送装置から課金情報を含むユーザ情報を受信すると、管理しているユーザ情報を追加して、課金サーバへ送信することを特徴のひとつとする。
本発明の第1の解決手段によると、
複数のユーザ端末を終端し、受信したマルチキャストデータをコピーして前記ユーザ端末へ転送する第1のパケット転送装置と、
前記第1のパケット転送装置を介して複数の前記ユーザ端末とポイント トゥ ポイント接続される第2のパケット転送装置と、
前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを前記第2のパケット転送装置に出力するサーバと
を備え、
前記第1のパケット転送装置は、
グループアドレスと、前記ユーザ端末の端末識別情報と、配信許可及び配信拒絶のいずれかを示す情報とを含むエントリが記憶される配信制御テーブル
を有し、
前記第2のパケット転送装置は、前記ユーザ端末からポイント トゥ ポイント接続の接続要求を受信すると、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを取得し、
前記第2のパケット転送装置は、受信されたグループアドレスと、前記ユーザ端末の端末識別情報とを対応して記憶し、
前記第1のパケット転送装置は、前記ユーザ端末から、予め定められたグループアドレスと該ユーザ端末の端末識別情報を含み、該ユーザ端末を送信元としたマルチキャストグループへの第1の参加要求を受信すると、該第1の参加要求を終端し、及び、前記配信制御テーブルに該グループアドレスと該端末識別情報とを対応して記憶し、
前記第1のパケット転送装置は、受信したグループアドレスと端末識別情報を含み、自装置を送信元とした第2の参加要求を前記第2のパケット転送装置に送信し、
前記第2のパケット転送装置は、第2の参加要求に含まれるグループアドレス及び端末識別情報と、記憶されたグループアドレス及び端末識別情報とを比較し、一致するものが記憶されていれば配信許可を示し、及び、記憶されていなければ配信拒絶を示す通知を前記第1のパケット転送装置に送信し、
前記第1のパケット転送装置は、該通知に従い、該グループアドレスと該端末識別情報とに対応して、配信許可又は配信拒絶を示す情報を前記配信制御テーブルに記憶し、
前記第1のパケット転送装置は、前記第2のパケット転送装置からグループアドレスを含むマルチキャストデータを受信し、前記配信制御テーブルを参照して、該グループアドレスに対応して配信許可を示す情報が記憶されたエントリの端末識別情報に従い、受信されたマルチキャストデータ及び/又はコピーしたマルチキャストデータをひとつ又は複数の前記ユーザ端末に送信するネットワークシステムが提供される。
本発明の第2の解決手段によると、
複数のユーザ端末を終端し、受信したマルチキャストデータをコピーして前記ユーザ端末へ転送する第1のパケット転送装置と、
前記第1のパケット転送装置を介して複数の前記ユーザ端末とポイント トゥ ポイント接続される第2のパケット転送装置と、
前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを前記第2のパケット転送装置に出力するサーバと
を備え、
前記第1のパケット転送装置は、
グループアドレスと、前記ユーザ端末の端末識別情報と、配信許可及び配信拒絶のいずれかを示す情報と、参加要求の受信及び未受信のいずれかを示す情報とを含むエントリが記憶される配信制御テーブル
を有し、
前記第2のパケット転送装置は、前記ユーザ端末からポイント トゥ ポイント接続の接続要求を受信すると、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを取得し、
前記第2のパケット転送装置は、受信されたグループアドレスと、前記ユーザ端末の端末識別子とを含む通知を前記第1のパケット転送装置に送信し、
前記第1のパケット転送装置は、該通知に含まれるグループアドレス及び端末識別子と、配信許可を示す情報とを対応して前記配信制御テーブルに記憶し、
前記第1のパケット転送装置は、前記ユーザ端末から予め定められたグループアドレスと該ユーザ端末の端末識別情報を含むマルチキャストグループへの参加要求を受信すると、前記配信制御テーブルの該当するグループアドレスと端末識別情報に対応して、参加要求の受信を示す情報を記憶し、
前記第1のパケット転送装置は、前記第2のパケット転送装置からグループアドレスを含むマルチキャストデータを受信し、前記配信制御テーブルを参照して、該グループアドレスに対応して参加要求の受信を示す情報及び配信許可を示す情報が記憶されたエントリの端末識別情報に従い、受信されたマルチキャストデータ及び/又はコピーしたマルチキャストデータをひとつ又は複数の前記ユーザ端末に送信するネットワークシステムが提供される。
本発明の第3の解決手段によると、
複数のユーザ端末を終端し、受信したマルチキャストデータをコピーして前記ユーザ端末へ転送する第1のパケット転送装置と、
前記第1のパケット転送装置を介して複数の前記ユーザ端末とポイント トゥ ポイント接続される第2のパケット転送装置と、
前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを前記第2のパケット転送装置に出力し、及び、課金開始通知及び課金終了通知を受信することにより端末識別情報毎に課金を行うサーバと
を備え、
前記第1のパケット転送装置は、
グループアドレスと、前記ユーザ端末の端末識別情報と、配信許可及び配信拒絶のいずれかを示す情報とを含むエントリが記憶される配信制御テーブル
を有し、
前記第2のパケット転送装置は、前記ユーザ端末からポイント トゥ ポイント接続の接続要求を受信すると、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを取得し、
前記第2のパケット転送装置は、受信されたグループアドレスと前記ユーザ端末の端末識別情報とを対応して記憶し、
前記第1のパケット転送装置は、前記ユーザ端末から、予め定められたグループアドレスと該ユーザ端末の端末識別情報を含むマルチキャストグループへの参加要求を受信すると、該参加要求をスヌーピングして、前記配信制御テーブルに該グループアドレスと該端末識別情報とを記憶し、及び、該参加要求を前記第2のパケット転送装置に転送し、
前記第2のパケット転送装置は、受信した参加要求に含まれるグループアドレス及び/又は端末識別情報を含む課金開始通知を前記サーバに送信し、
前記第2のパケット転送装置は、受信した参加要求に含まれるグループアドレス及び端末識別情報と、記憶されたグループアドレス及び端末識別情報とを比較し、一致するものが記憶されていれば配信許可を示し、及び、記憶されていなければ配信拒絶を示す通知を前記第1のパケット転送装置に送信し、
前記第1のパケット転送装置は、該通知に従い、グループアドレスと端末識別情報とに対応して、配信許可又は配信拒絶を示す情報を前記配信制御テーブルに記憶し、
前記第1のパケット転送装置は、前記第2のパケット転送装置からグループアドレスを含むマルチキャストデータを受信し、前記配信制御テーブルを参照して、該グループアドレスに対応して配信許可を示す情報が記憶されたエントリの端末識別情報に従い、受信されたマルチキャストデータ及び/又はコピーしたマルチキャストデータをひとつ又は複数の前記ユーザ端末に送信し、
前記第2のパケット転送装置は、前記第1のパケット転送装置を介して前記ユーザ端末から、グループアドレスと端末識別情報を含む離脱宣言を受信すると、受信した離脱宣言に含まれるグループアドレス及び/又は端末識別情報を含む課金終了通知を前記サーバに送信するネットワークシステムが提供される。
本発明によると、上記ネットワークにおいてレイヤ2スイッチで管理するユーザ情報をルータが知る手段、その情報をもとにルータが認証・課金のための処理を行う手段を有するネットワークシステムを提供することができる。また、本発明によると、認証結果をもとにレイヤ2スイッチが配信データの制御を行う手段を提供することができる。本発明によると、トラヒックを抑えつつ安価で認証や課金を伴うマルチキャストサービスを実現するためのネットワークシステムを提供することができる。
本発明によると、セキュリティやユーザ管理のためにPPPoEなどで、ユーザ端末とルータ間が論理的にPoint to Pointとなっているアクセス系のネットワーク上で、マルチキャスト通信によるデータ配信サービスを行う場合に、安価な装置構成で、かつトラヒックや装置への負荷を抑えて、様々な認証・課金サービス、ユーザ管理が実現できる。
また、本発明によると、ユーザ端末ユーザ端末に対して新たに機能追加や設定が不要で、PPP接続の認証だけで済むため、マルチキャスト用のユーザIDやパスワードも不要であり、ユーザがマルチキャストサービスを受けるために再度認証することを必要としないため、ユーザに負担をかけることなく実現できる。
以下、本実施の形態を図面を用いて説明する。以下の例では、IPv4、IGMPで説明しているが、IPv6、MLDにおいても基本的な動作は同等であるのでIPv6、MLDの例を提示した説明は省略する。また、以下の例ではユーザ端末とルータ間がPPPoEで接続されている場合を説明しているが、PPPoA(PPP over ATM)やVLAN(Virtual LAN)などユーザ端末とルータが論理的にPoint to Pointとなる場合にも同様に動作する。プロトコルは、上述のものに限らず適宜のプロトコルを用いることができる。装置としては、レイヤ2スイッチとルータを例に挙げているが、同等の機能を実装できる装置(例えばBAS(Broadband Access Server))であれば適宜装置に適用できる。また、以下の例では、認証サーバと課金サーバを同一サーバとして説明しているが、各サーバが分かれていた場合でも同様に動作する。さらに、以下の例では、各処理をソフトウェアで実行していることを前提に説明しているが、ハードウェアでも同様に実現できる。
1.第1の実施の形態
1.1 システム構成
図1に本実施の形態におけるネットワークシステムの構成図を示す。
ネットワークシステムは、例えば、レイヤ2スイッチ(L2SW、第1のパケット転送装置)100、101と、ルータ(第2のパケット転送装置)200と、コンテンツ配信サーバS1と、課金・認証サーバS2を備える。
このネットワーク構成例では、ユーザ端末(H1−1〜H1−n、H2−1〜H2−n)は一旦レイヤ2スイッチ(100、101)に収容される。また、それぞれアクセスネットワーク(NW1、NW2)、及び、ISP網(NW3)内にあるルータ(200)を介して、インターネット(300)やコンテンツ配信サーバ(S1)、課金・認証サーバ(S2)に接続される。なお、ユーザ端末(H1−1〜H1−n、H2−1〜H2−n)とルータ(200)の間は、PPPoEで接続される。
図2は、従来技術を用いた場合のパケットの流れ及びその課題の説明図である。
ユーザ端末(H1−1〜H1−n)にはそれぞれに対しMACアドレス(00−00−87−00−11−11〜00−00−87−00−nn−nn)、ユーザID(user1@isp1、user2@isp1、usern@isp1)が割り付けられているものとして説明する。ユーザ端末(H1−1〜H1−n)とルータ(1200)は論理的なコネクション(LP1〜LPn)で接続される。インターネット接続を行う場合、これらのコネクション(LP1〜LPn)を通して接続する。また、ユーザ端末(H1−1、H1−n)は予めコンテンツ配信業者と契約しており、マルチキャストグループ(グループアドレス224.10.10.10)に参加する資格を有している。配信サーバ(S1)からのマルチキャストパケットの場合も同様に、コネクション(LP1、LPn)を通して配信される。この場合マルチキャストパケットのコピー点はルータ(1200)となる。そのため、参加するユーザ端末やL2SWの数が増えると、その分だけルータでのコピーが必要となり、ルータ(1200)に負荷がかかる。また、レイヤ2スイッチ(1100)とルータ(1200)間のトラヒックも増えてしまう。
図3は、本実施の形態のパケットの流れを示した図である。
インターネット接続に用いる論理的なコネクション(LP1〜LPn)とは別に、L2SW(100)とルータ(200)間にマルチキャスト用の論理的なコネクション(LM)をはり、マルチキャストパケットをこのコネクション(LM)を通して配信する。この場合のマルチキャストパケットのコピー点はレイヤ2スイッチ(100)となる。そのため、参加するユーザ端末が増えても、ルータ(200)への負荷と、レイヤ2スイッチ(100)とルータ(200)間のトラヒックも抑えられる。
図4に、本実施の形態におけるレイヤ2スイッチ(100)の内部構成図を示す。なお、本実施の形態とは直接関係しないレイヤ2スイッチの機能については適宜省略する。
レイヤ2スイッチ(100)は、例えば、複数の入出力回線の回線インタフェース(100−1−1〜100−1−n)と、回線インタフェース(100−1−1〜100−1−n)の制御を行う回線インタフェース制御部(100−2)と、パケットの解析、編集などを行うプロセッサ(100−3)と、プロセッサ(100−3)が処理を行うために使用するメモリ(100−4)と、外付けの制御端末(100−6)とのインタフェースを行う制御端末インタフェース(100−5)と、送受信するパケットを一時的に格納する送受信バッファ(100−7)とを備える。メモリ(100−4)は、例えば、プロセッサ(100−3)が実行するプログラム(100−4−3)と、レイヤ2スイッチ(100)の配下に接続されているユーザ端末(H1−1〜H1−n)へのマルチキャストデータの配信を制御するための配信制御テーブル(100−4−1)と、ルータ(200)との間のマルチキャスト用コネクション管理テーブルL(100−4−2)とが格納されている。また、送受信バッファ(100−7)は、送信バッファ(100−7−1)と受信バッファ(100−7−2)を有する。
回線インタフェース(100−1−1〜100−1−n)には、それぞれに対し個別のMACアドレスが割り付けられている。本例では、回線インタフェース#1(100−1−1)には00−00−87−11−11−11が、回線インタフェース#2(100−1−2)には00−00−87−22−22−22が、回線インタフェース#3(100−1−3)には00−00−87−33−33−33が、回線インタフェース#n(100−1−n)には00−00−87−nn−nn−nnがそれぞれ割り付けられているものとして説明する。
図5(a)に、配信制御テーブル(100−4−1)の詳細構成例を示す。
配信制御テーブル(100−4−1)は、レイヤ2スイッチの配下に接続される、ユーザ端末(H1−1〜H1−n)がどのマルチキャストグループに属しているか、参加要求のあり/なし、配信の許可/拒絶、配信時間やトラヒック量の記録などを管理するものである。配信制御テーブル(100−4−1)は、例えば、グループアドレス(100−4−1−1)、回線インタフェースのID(100−4−1−2)、Session ID(100−4−1−3)、ユーザ端末MACアドレス(100−4−1−4)、参加要求の有無(受信又は未受信)(100−4−1−5)、配信許可情報(配信許可又は配信拒絶又は不明)(100−4−1−6)、配信開始時刻(100−4−1−7)、配信終了時刻(100−4−1−8)、及び、トラヒック情報(100−4−1−9)を含む。図5(b)〜(d)、図6、図22は、配信制御テーブル(100−4−1)が更新されたものである。
図7に、マルチキャスト用コネクション管理テーブルL(100−4−2)の詳細構成例を示す。
マルチキャスト用コネクション管理テーブル(100−4−2)は、例えば、ルータ(200)との間でどのグループアドレスのパケットを、どのコネクションを用いて送受信するかを管理するテーブルである。マルチキャスト用コネクション管理テーブル(100−4−2)は、例えば、グループアドレス(100−4−2−1)、回線インタフェースのID(100−4−2−2)、Session ID(100−4−2−3)、及び、ルータMACアドレス(100−4−2−4)を含む。
図8に、本実施の形態におけるルータ(200)の内部構成図を示す。なお、本実施の形態とは直接関係しないルータの機能については適宜省略する。
ルータ(200)は、例えば、複数の入出力回線の回線インタフェース(200−1−1〜200−1−n)と、回線インタフェース(200−1−1〜200−1−n)の制御を行う回線インタフェース制御部(200−2)と、パケットの解析、編集などを行うプロセッサ(200−3)と、プロセッサ(200−3)が処理を行うために使用するメモリ(200−4)と、外付けの制御端末(200−6)とのインタフェースを行う制御端末インタフェース(200−5)と、送受信するパケットを一時的に格納する送受信バッファ(200−7)とを備える。
メモリ(200−4)には、例えば、プロセッサ(200−3)が実行するプログラム(200−4−3)と、ルータ(200)の配下に接続されているユーザ端末(H1−1〜H1−n)を管理するための配信情報テーブル(200−4−1)と、レイヤ2スイッチ(100)との間のマルチキャスト用コネクション管理テーブルR(200−4−2)とが格納されている。また、送信バッファ(200−7)は、送信バッファ(200−7−1)と受信バッファ(200−7−2)を有する。
回線インタフェース(200−1−1〜200−1−n)には、それぞれに対し個別のMACアドレスが割り付けられている。本例では、回線インタフェース#1(200−1−1)には00−00−87−00−00−11が、回線インタフェース#2(200−1−2)には00−00−87−00−00−22が、回線インタフェース#3(200−1−3)には00−00−87−00−00−33が、回線インタフェース#n(200−1−n)には00−00−87−00−00−nnがそれぞれ割り付けられているものとして説明する。
図9(a)に、配信情報テーブル(200−4−1)の詳細構成例を示す。
配信情報テーブル(200−4−1)は、例えば、ルータ(200)が認証・課金サーバ(S2)とのやり取りに必要な情報や、ユーザ端末(H1−1〜H1−n)がどのグループアドレスに参加可能かを管理するテーブルである。配信情報テーブル(200−4−1)は、例えば、ユーザID(200−4−1−1)、パスワード(200−4−1−2)、グループアドレス(200−4−1−3)、回線インタフェースのID(200−4−1−4)、Session ID(200−4−1−5)、及び、ユーザ端末MACアドレス(200−4−1−6)を含む。図9(b)、(c)、図23は、配信情報テーブル(200−4−1)が更新されたものである。
図10に、マルチキャスト用コネクション管理テーブルR(200−4−2)の詳細構成例を示す。
マルチキャスト用コネクション管理テーブルR(200−4−2)は、例えば、レイヤ2スイッチ(100)との間でどのグループアドレスのパケットを、どのコネクションを用いて送受信するかを管理するテーブルである。マルチキャスト用コネクション管理テーブルR(200−4−2)は、例えば、グループアドレス(200−4−2−1)、回線インタフェースのID(200−4−2−2)、Session ID(200−4−2−3)、及び、レイヤ2スイッチMACアドレス(200−4−2−4)を含む。
図11(a)に、ユーザ端末(H1−1〜H1−n)とルータ(200)間で送受信されるマルチキャストパケット以外のパケットの構成例を示す。
マルチキャストパケット以外のパケットは送信先物理アドレスであるMAC DA(300)、送信元物理アドレスであるMAC SA(301)、PPPoEヘッダ情報(302)、PPPヘッダ情報(303)、送信元IPアドレスであるIP SA(304)、送信先IPアドレスであるIP DA(305)、及び、データ(306)を含む。
図11(b)に、ユーザ端末(H1−1〜H1−n)とルータ(200)間で送受信されるマルチキャストパケットの構成例を示す。
マルチキャストパケットは、上述のパケットの構成に、マルチキャスト制御情報であるIGMP(307)が付与され、レイヤ2スイッチ(100)とルータ(200)間では、各装置が管理しているユーザ管理テーブル(100−4−1、200−4−1)の情報が付与される。
図12に、認証・課金サーバ(S2)が保持しているユーザ管理テーブルの詳細構成例を示す。
ユーザ管理テーブルは、例えば、PPP接続認証時に用いられるものであり、ユーザID(S2−1−1)、パスワード(S2−1−2)、グループアドレス(S2−1−3)を含む。このテーブルは、ユーザ識別やユーザ管理のためにISP業者によって登録・更新されることができる。
1.2 動作
図13に、参加資格を有するユーザ端末(H1−1)のPPP接続要求からマルチキャストのデータを受信するまでの動作シーケンスを示す。図14に、ユーザ端末(H1−1)がマルチキャストデータを受信している場合に、さらに参加資格を有するユーザ端末(H1−n)のPPP接続要求からマルチキャストのデータを受信するまでの動作シーケンスを示す。図15に、ユーザ端末(H1−1、H1−n)がマルチキャストデータを受信している場合に、参加資格がないユーザ端末(H1−2)のPPP接続要求からマルチキャスト参加要求が拒絶されるまでの動作シーケンスを示す。
図16に、レイヤ2スイッチ(100)における、配下に接続されているユーザ端末(H1−1〜H1−n)からパケットを受信した場合の処理フローを示す。図17に、ルータ(200)における、レイヤ2スイッチからマルチキャスト用コネクション(LM)を介してパケットを受信した場合の処理フローを示す。
図18に、マルチキャストサービスに参加中であるユーザ端末(H1−1、H1−n)がLeaveパケットを送信して離脱した場合の課金動作シーケンスを示す。図19に、マルチキャストサービスに参加中であるユーザ端末(H1−1)がReportパケットを返信しなくなり、離脱した場合の課金動作シーケンスを示す。図20に、マルチキャストサービスに参加中であるユーザ端末(H1−1)がPPPセッション切断により離脱した場合の課金動作シーケンスを示す。
図21に、レイヤ2スイッチ(100)がユーザ端末(H1−1〜H1−n)からLeaveパケットを受信した場合の処理フローを示す。
(マルチキャストサービス認証方法)
まず、例えば、グループアドレス224.10.10.10のマルチキャストサービスへの参加資格を有するユーザ端末(H1−1)が、配信サーバ(S1)からの配信データを受信するまでの流れについて図13を用いて説明する。
ユーザ端末(H1−1)は始めに、ルータ(200)に対してPPP接続要求(SQ1−1)を行う(SQ1−1)。このときに、接続認証に必要となるユーザ端末(H1−1)のユーザID(user1@isp1)とパスワード(user1p)を送信する。なお、ユーザ端末(H1−1)のMACアドレスを含んでもよい。要求を受信したルータ(200)は、ユーザ端末(H1−1)からの情報を含む認証依頼(Access−Request)を、認証・課金サーバ(S2)に送信する(SQ1−2)。認証・課金サーバ(S2)では、受信したユーザIDとパスワードの組み合わせに基づき、管理しているユーザ管理テーブル(図12)で保持しているユーザID(S2−1−1)とパスワード(S2−1−2)と同じ組み合わせがあるかを検索する(SQ1−3)。存在した場合、対応するグループアドレス(ここでは224.10.10.10)を取得し、インターネット接続に対するアクセス許可通知(Access−Accept)を、ルータ(200)に対して送信する(SQ1−4)。認証・課金サーバ(S2)のユーザ管理テーブル(図12)には、ユーザが参加できるマルチキャストのグループアドレス(S2−1−3)も記録されていて、アクセス許可通知(Access−Accept)とグループアドレスとがルータ(200)に送信される。
このアクセス許可通知(Access−Accept)を受信したルータ(200)では、受信バッファ(200−7−2)に格納されたパケットをプロセッサ(200−3)が読み出し、配信情報テーブル(200−4−1)を更新する(図9(a)、SQ1−5)。ユーザID(200−4−1−1)には、ユーザ端末(H1−1)のユーザID:user1@isp1が、パスワード(200−4−1−2)には、ユーザ端末(H1−1)のパスワード:user1pが、グループアドレス(200−4−1−3)には、認証・課金サーバ(S2)から受信した224.10.10.10が、回線インタフェース(200−4−1−4)には、レイヤ2スイッチ(100)に接続される回線インタフェースのID:例えば#3が、Session ID(200−4−1−5)には、レイヤ2スイッチ(100)とのセッションのID:例えば10が、ユーザ端末MACアドレス(200−4−1−6)には、ユーザ端末(H1−1)のMACアドレス:00−00−87−00−11−11が、それぞれ登録される。
なお、ユーザ端末MACアドレスは、PPP接続要求に含まれていてもよいし、認証・課金サーバ(S2)でユーザIDに対応して記憶しておき、アクセス許可通知に含めるなどによりルータ(200)が取得してもよい。また、ユーザ端末MACアドレスは、MACアドレス以外にも、ユーザ端末を識別する適宜の端末識別情報であってもよい。例えば、ユーザIDなどでもよい。
ルータ(200)は、認証が完了したことを、ユーザ端末(H1−1)に通知する(SQ1−6)。これによって、ユーザ端末(H1−1)は、インターネット接続が可能となる。
その後、ユーザ端末(H1−1)が、グループアドレス224.10.10.10のマルチキャストサービスに参加するために、IGMP Join(第1の参加要求)を送信する(SQ1−7)。なお、ユーザ端末(H1−1)は、予めマルチキャストのグループアドレスを取得していることができる。送信されるIGMP Joinは、例えば、予め定められたグループアドレスとユーザ端末の端末識別情報を含み、ユーザ端末を送信元(すなわちマルチキャストデータの配信先)としたパケットである。そのIGMP Joinパケットは、例えば、ユーザ端末(H1−1)が接続されるレイヤ2スイッチ(100)の回線インタフェース#1(100−1−1)で受信される。回線インタフェース制御部(100−2)が、IGMP Joinパケットを受信バッファ(100−7−2)に格納し、プロセッサ(100−3)に対して、パケットを受信したことを通知する。通知を受けたプロセッサ(100−3)は図16のフローに従って、以下の処理を行う。
レイヤ2スイッチ(100)のプロセッサ(100−3)は、ユーザ端末からパケットを受信(図16:F1−1)すると、受信したパケットがIGMPパケットかを判別する(F1−2)。プロセッサ(100−3)は、IGMPパケットでない場合は(F1−2)、送信バッファ(100−7−1)に格納して通常の転送処理をする(F1−3)。例えば、送信バッファ(100−7−1)に格納されたパケットは、回線インタフェース制御部(100−2)がパケットの送信先物理アドレスであるMAC DA(300)を基に、回線インタフェース#3(100−1−3)を介して送信する。通常、送信先物理アドレスであるMAC DA(300)は00−00−87−00−00−33であり、ルータ(200)宛てとなる。なお、前述のPPP接続要求時のパケットはこれら通常処理となる。
一方、受信パケットがIGMPパケットの場合(F1−2)、プロセッサ(100−3)は、パケットがJoin(Report)かLeaveかを判別する(F1−4)。Leaveの場合は、詳細は後述するが、図21に示すフローで処理を進める(F1−5)。Joinの場合、パケットの送信先IPアドレス(IP DA)(305)となっているグループアドレスで、ルータ(200)との間にコネクションが張られているかをマルチキャスト用コネクション管理テーブル(100−4−2)を参照して確認する(F1−6)。
コネクションがない場合(該当するグループアドレスが記憶されていない場合)は(F1−6)、ルータ(200)との間でマルチキャスト用コネクションを張り、その結果をマルチキャスト用コネクション管理テーブル(100−4−2)に反映させる(F1−7、SQ1−8、SQ1−9)。図7は、反映後のテーブルの例である。このとき、ルータ(200)のマルチキャスト用コネクション管理テーブル(200−4−2)も同様に更新される。図10は、更新後のテーブルの例である。その後、処理F1−10に移る。
一方、コネクションがすでにあった場合(該当するグループアドレスが記憶されている場合)は(F1−6)、配信制御テーブル(100−4−1)に登録済みかどうかを、パケットの送信元物理アドレスであるMAC DA(301)であるユーザ端末(H1−1)のMACアドレスと、グループアドレスとを検索キーにして確認する(F1−8)。登録済みの場合、受信バッファ(100−7−2)からパケットを破棄する(F1−9)。一方、配信制御テーブル(100−4−1)に未登録の場合、処理F1−10に移る。
処理F1−10では、図5(a)に示すように配信制御テーブル(100−4−1)を更新する(F1−11、SQ1−10)。この時点で、配信許可(100−4−1−6)はわからないので、例えば「不明」とする。
最後に、更新した配信制御テーブル(100−4−1)の情報をJoinパケット(第2の参加要求)のデータ領域(308)に付与し、送信元物理アドレスであるMAC SA(301)を回線インタフェース#3のMACアドレスである00−00−87−33−33−33に書き換え、送信バッファ(100−7−1)に格納する。送信バッファ(100−7−1)から回線インタフェース制御部(100−2)がパケットの送信先物理アドレスであるMAC DA(300)を基に、回線インタフェース#3(100−1−3)を介してルータ(200)に送信する(F1−11、SQ1−11)。ただし、配信制御テーブル(100−4−1)の回線インタフェース(100−4−1−2)の情報は、付与する情報には含めなくてもよい。
配信制御テーブル(100−4−1)の情報が付与されたJoinパケットがルータ(200)の回線インタフェース#3に到着すると、レイヤ2スイッチ(100)と同様に受信バッファ(200−7−2)に格納される。パケットを受信してからのプロセッサ(200−3)の処理は図17に示すフローですすめられる。
ルータ(200)のプロセッサ(200−3)は、パケットを受信すると(F2−1)、まずJoinかLeaveかを判別する(F2−2)。Leaveの場合は、詳細は後述するが、配信情報テーブル(200−4−1)を更新し、配信サーバ(S1)に対して、配信の停止要求であるPIM Leaveを送信する(F2−3)。
Joinの場合、パケットに付与されている配信制御テーブル(図5(a))の情報と、ルータ(200)が管理している配信情報テーブル(図9(a))とを比較する(SQ1−11)。具体的には、まず配信制御テーブル(100−4−1)に基づくSession ID(100−4−1−3)とユーザ端末MACアドレス(100−4−1−4)の組み合わせが、配信情報テーブル(200−4−1)にあるかを検索する(F2−4)。なお、いずれか一方でもよい。該当しない場合はパケットを破棄する(F2−5)。該当するものがある場合、さらにグループアドレス(100−4−1−1)が、配信情報テーブル(200−4−1)のグループアドレス(200−4−1−3)に該当するかを検索する(F2−6)。
該当するものがない場合には(F2−6)、配信情報テーブル(200−4−1)のSession ID(200−4−1−5)、ユーザ端末MACアドレス(200−4−1−6)に対応するユーザID(200−4−1−1)とパスワード(200−4−1−2)を利用して、認証・課金サーバ(S2)へ認証依頼(Access−Request)を再送信して(F2−7)、最新のグループアドレス情報を確認する。また、配信情報テーブル(200−4−1)を更新し(F2−8)、更新した配信情報テーブル(200−4−1)の情報をQueryパケットのデータ領域(308)に付与し、送信元物理アドレスであるMAC SA(301)を回線インタフェース#3のMACアドレスである00−00−87−00−00−33に、送信先物理アドレスであるMAC DA(300)を図10のレイヤ2スイッチMACアドレス(200−4−2−4)に記録されている00−00−87−33−33−33に書き換え、送信バッファ(200−7−1)に格納する。送信バッファ(200−7−1)から回線インタフェース制御部(200−2)が、パケットのMAC DA(300)を基に回線インタフェース#3を介して送信する(F2−9)。このときに、Queryパケットには配信情報テーブル(200−4−1)のグループアドレス(200−4−1−3)、Session ID(200−4−1−5)、ユーザ端末MACアドレス(200−4−1−6)が付与される。
一方、管理している配信情報テーブル(200−4−1)にグループアドレスが該当する場合には(F2−6)、受信した配信制御テーブル(100−4−1)の情報に基づく配信許可(100−4−1−6)を確認する(F2−10)。このデータは、受信したパケットに含まれている。配信許可情報が「不明」となっている場合には、グループアドレスが該当しなかった場合と同様に、配信情報テーブル(200−4−1)の情報を付与しQueryパケットを送信する(F2−9、SQ1−13)。なお、配信許可を示す適宜の通知を行ってもよい。すでに「許可」となっている場合には(F2−10)、グループアドレス224.10.10.10のデータをレイヤ2スイッチ(100)に配信中であれば(F2−11)、受信バッファ(200−7−2)からそのパケットを破棄する(F2−13)。配信中でなければ(F2−11)、配信サーバ(S1)に対して、グループアドレス224.10.10.10の配信要求PIM Joinを送信する(F2−12、SQ1−17)。
Queryパケットを受信したレイヤ2スイッチ(100)は、レイヤ2スイッチ(100)の配下に参加しているユーザ端末、つまり配信制御テーブル(100−4−1)の配信許可(100−4−1−6)が「許可」、かつ参加要求(100−4−1−5)が「あり」となっているユーザ端末宛てにQueryパケットを送信する。送信後、受信した配信情報テーブル(200−4−1)の情報をもとに配信制御テーブル(100−4−1)を更新する。具体的には、この時点で受信した配信情報テーブル(200−4−1)には、グループアドレス(200−4−1−4)には224.10.10.10、Session ID(200−4−1−5)には10、ユーザ端末MACアドレス(200−4−1−6)には00−00−87−00−11−11が記録されている。
プロセッサ(100−3)は、受信した配信情報テーブル(200−4−1)の情報に含まれるユーザ端末は配信許可されていると判断する。従って、図5(b)に示すように、配信制御テーブル(100−4−1)の該当するユーザ端末MACアドレスに対応する配信許可(100−4−1−6)を、「不明」から「許可」に更新する(SQ1−14)。更新した配信制御テーブル(100−4−1)の情報をReportパケットに付与し、ルータ(200)に送信する(SQ1−15)。ルータ(200)では先に述べたように、テーブルを比較し(SQ1−16)、配信サーバ(S1)に、データの配信要求であるPIM Joinを送信する(SQ1−17)。配信サーバ(S1)からデータが配信される(SQ1−18)。
ルータ(200)ではデータを受信すると、マルチキャスト用コネクション管理テーブル(200−4−2)を参照して(SQ1−19)、グループアドレスに対応する回線インタフェースのID等に従い、レイヤ2スイッチ(100)へデータを転送する(SQ1−20)。レイヤ2スイッチ(100)ではデータを受信すると、配信制御テーブル(100−4−1)を参照し(SQ1−21)、参加要求(100−4−1−5)が「あり」、かつ、配信許可(100−4−1−6)が「許可」となっているエントリの、ユーザ端末MACアドレス、回線インタフェースのID等に従い、ユーザ端末(H1−1)宛てにデータを転送する(SQ1−22)。
このときレイヤ2スイッチ(100)では、図5(c)に示すように、配信制御テーブル(100−4−1)の配信開始時刻(100−4−1−7)を記録し、配信データを転送するたびにトラヒック(100−4−1−9)を更新していく(SQ1−23)。
また、ルータ(200)からは参加確認のために、定期的にQueryパケットが送信され(SQ1−24)、レイヤ2スイッチ(100)が配信制御テーブル(100−4−1)を参照して(SQ1−25)、ユーザ端末(H1−1)へQueryパケットを送信する(SQ1−26)。ユーザ端末(H1−1)が参加を継続する場合には、継続を要求するReportパケットを返信する(SQ1−27)。レイヤ2スイッチ(100)では図16のフローに従い配信制御テーブル(100−4−1)を更新し(SQ1−28)、ルータ(200)宛てにReportパケットを返信する(SQ1−29)。
ルータ(200)は定期的な参加確認によって、配信データの要否だけでなく、レイヤ2スイッチ(100)の配信制御テーブル(100−4−1)とルータ(200)の配信情報テーブル(100−4−2)を比較する(SQ1−30)ことで、互いのテーブルの整合性を保つことができる。
次に、図14を参照して、ユーザ端末(H1−1)がグループアドレス224.10.10.10のマルチキャストサービスに参加している場合に、さらに参加資格を有するユーザ端末(H1−n)がPPP接続をし、グループアドレス224.10.10.10のマルチキャストサービスへの参加要求をし、配信データが転送されるまでの流れを説明する。
配信サーバ(S1)から配信データがルータ(200)へ転送され(SQ2−1)、前述と同様に配信情報テーブル(200−4−1)を参照し(SQ2−2)、レイヤ2スイッチ(100)へ転送する(SQ2−3)。レイヤ2スイッチ(100)では配信制御テーブル(100−4−1)を参照し(SQ2−4)、ユーザ端末(H1−1)へデータを転送する(SQ2−5)。このとき、データを転送するたびに、配信制御テーブル(100−4−1)のトラヒック(100−4−1−9)を更新する。
ここで、ユーザ端末(H1−n)がPPP接続要求をする(SQ2−7)。ルータ(200)は、ユーザ端末(H1−1)のときと同様に、認証・課金サーバ(S2)へ認証依頼(Access−Request)を送信(SQ2−8)する。認証・課金サーバ(S2)は、ユーザ管理テーブル(図12)を検索し(SQ2−9)、アクセス許可通知(Access−Accept)とともに、このユーザ端末(H1−n)が参加できるグループアドレス情報を返信する(SQ2−10)。ルータ(200)は、この情報をもとに配信情報テーブル(200−4−1)を更新し(図9(b)、SQ2−11)、ユーザ端末(H1−n)へ認証完了通知を行う(SQ2−12)。
ここで、ルータ(200)がグループアドレス224.10.10.10への参加者がいるかどうかの確認と、レイヤ2スイッチ(100)とのテーブルの整合性維持のためにレイヤ2スイッチ(100)宛てに、図9(b)の配信情報テーブルの各情報を含むQueryパケットを送信した(SQ2−13)場合について説明する。なお、Queryパケットを送信せず、後述するSQ2−20の処理へ移ってもよい。レイヤ2スイッチ(100)では配信制御テーブル(100−4−1)を参照し(SQ2−14)、ユーザ端末(H1−1)へQueryを送信し(SQ2−15)、ユーザ端末(H1−1)がその応答を返信する(SQ2−16)。その後、レイヤ2スイッチ(100)は図5(d)に示すように、配信制御テーブル(100−4−1)を更新し(SQ2−17)、更新した配信制御テーブル(100−4−1)の情報をReportパケットに付与してルータ(200)へ送信する(SQ2−18)。この場合、ルータ(200)がテーブル(図5(d)と図9(b))を比較すると(SQ2−19)、グループアドレス224.10.10.10は既に配信中であるため整合性を確認後、パケットを破棄する(F2−13)。
ユーザ端末(H1−n)がグループアドレス224.10.10.10への参加を要求すると(SQ2−20)、レイヤ2スイッチ(100)は配信制御テーブル(100−4−1、図5(d))の参加要求(100−4−1−5)を「なし」から「あり」へ変更する(SQ2−21)。配信制御テーブル(100−4−1)がこの状態のとき、配信サーバ(S1)からデータ配信される(SQ2−22)と、ルータ(200)ではユーザ端末が増えたことは関係なく、図13のときと同様にマルチキャスト用コネクション管理テーブル(200−4−2)を参照し(SQ2−23)、データをレイヤ2スイッチ(100)へ転送する(SQ2−24)。このときにレイヤ2スイッチ(100)で参照する(SQ2−25)配信制御テーブル(100−4−1)には、2つのユーザ端末(H1−1、H1−n)情報が参加要求(100−4−1−5)があり、配信許可(100−4−1−6)が許可となっている。そのため配信データをコピーし、2つのユーザ端末(H1−1、H1−n)へ転送する(SQ−26)。このとき、配信制御テーブル(100−4−1)は図6(a)のように更新される(SQ2−27)。
また、ルータ(200)の定期的なQueryパケット(SQ2−28)に対しても図6(a)の配信制御テーブル(100−4−1)が参照される(SQ2−29)ため、レイヤ2スイッチ(100)は2つのユーザ端末(H1−1、H1−n)宛てにQueryパケットを送信する(SQ2−30)。レイヤ2スイッチ(100)ではある一定時間ユーザ端末(H1−1、H1−n)からの応答であるReportパケット(SQ2−31)を待ち、その後配信制御テーブル(100−4−1)を更新し(SQ2−32)(ただし、この場合は更新処理を行っても情報に変化はない。しかし、ルータ(200)からの情報と整合性をとるために更新処理を行う。)、ルータ(200)にReportパケットを返信し(SQ2−33)、ルータ(200)ではテーブルを比較する(SQ2−34)ことで参加確認とテーブルの整合性を確認する。
これによって、あるグループアドレスへ新たなユーザ端末が同一グループアドレスへの参加要求をした場合、ルータ(200)の定期的な参加確認よって、配信制御テーブル(100−4−1)が更新されていれば図13のSQ1−12〜SQ1−15が省略できる。
次に、図15を参照して、ユーザ端末(H1−1、H1−n)がグループアドレス224.10.10.10のマルチキャストサービスに参加している場合に、さらに参加資格がないユーザ端末(H1−2)がPPP接続をし、グループアドレス224.10.10.10のマルチキャストサービスへの参加要求をし、配信データが転送されない場合の流れについて説明する。
配信サーバ(S1)からデータが配信され、ユーザ端末(H1−1、H1−n)へデータが配信されるまでの流れ(SQ3−1〜SQ3−5)は前述と同じであるため省略する。またこの時点で更新された(SQ3−6)配信制御テーブル(100−4−1)は図6(a)となる。また、グループアドレス224.10.10.10への参加資格がないユーザ端末(H1−2)が、上述と同様にPPP接続要求から認証が完了すると(SQ3−7〜SQ3−12)、ルータ(200)の配信情報テーブル(200−4−1)は図9(c)の状態となる。
そこに、ユーザ端末(H1−2)から参加要求であるJoinパケットが送信されると(SQ3−13)、配信制御テーブル(100−4−1)は図6(b)に示すように更新される(SQ3−14)。レイヤ2スイッチ(100)がこの情報をJoinパケットに付与してルータ(200)に送信し(SQ3−15)、ルータ(200)ではテーブル(図6(b)と図9(c))の比較を行う(SQ3−16)。すると、配信情報テーブル(200−4−2)には、Session ID(200−4−1−5)が20で、ユーザ端末MACアドレス(200−4−1−6)が00−00−87−00−22−22の組み合わせに対応して、グループアドレス224.10.10.10は登録されていないため、ユーザID(200−4−1−1)のuser2@isp1と、パスワード(200−4−1−2)のuser2pを用いて、認証・課金サーバ(S2)へ認証依頼(Access−Request)を再送信する(F2−7、SQ3−17)。その応答であるアクセス許可通知(Access−Accept)と合わせて、ユーザ端末(H1−2)が参加資格を有するグループアドレスが送信され(SQ3−18、SQ3−19)、ルータ(200)はその応答を受信すると配信情報テーブル(200−4−1)を更新する(SQ3−20)。認証・課金サーバへの再確認でもユーザ端末(H1−2)が参加できるグループアドレスがなければ、配信情報テーブル(200−4−1)は図9(c)のままとなる。
ルータ(200)は、再確認結果を反映させた情報をQueryパケットに付与し、レイヤ2スイッチ(100)へ送信する(SQ3−21)。そのパケットを受信したレイヤ2スイッチ(100)では、まず現時点での配信制御テーブル(100−4−1)を参照し(SQ3−22)、参加・配信中であるユーザ端末(H1−1、H1−n)へQueryパケットを送信する(SQ3−23)。ある一定時間、ユーザ端末(H1−1、H1−n)からのReportパケット(SQ3−24)を待ち、その後ルータ(200)からの情報を基に配信制御テーブル(100−4−1)を更新する(SQ3−25、図6(c))。この場合、具体的には図6(b)では端末(H1−2)の配信許可(100−4−1−6)が「不明」となっていたが、ルータ(200)からの情報にはグループアドレスがないことから、「拒絶」と更新する。更新した配信制御テーブル(100−4−1)の情報をReportパケットに付与し、ルータ(200)へ返信する(SQ3−26)。ルータ(200)ではこのパケットを受信すると、テーブル(図6(c)と図9(c))の整合性を確認する(SQ3−27)。
レイヤ2スイッチ(100)の配信制御テーブル(100−4−1)が図6(c)の状態のときに、ユーザ端末(H1−2)が再度参加要求であるJoinパケットを送信した場合(SQ3−28)でも、配信制御テーブル(100−4−1)は更新されない。このため、配信サーバ(S1)からデータが送信されても、参加要求(100−4−1−5)がありで、かつ配信許可(100−4−1−6)が許可となっているユーザ端末(H1−1、H1−n)だけにしか転送されないようにできる(SQ3−29〜SQ3−34)。また、レイヤ2スイッチ(100)は、配信許可が「拒絶」となっているため、Joinパケットを破棄する。
ここで、ルータ(200)が認証・課金サーバ(S2)に再確認する必要性について説明する。PPP接続要求(SQ3−7)の時点では、認証・課金サーバ(S2)にはユーザ端末(H1−2)が参加できるグループアドレスがなかったが、認証完了(SQ3−12)後に認証・課金サーバ(S2)で保持している情報が更新されて、グループアドレス224.10.10.10に参加できるようになったことを想定する。その場合、ユーザ端末(H1−2)のPPP接続再要求がなければルータ(200)の配信情報テーブル(200−4−1)が更新されなくなってしまう。そのため、ルータ(200)ではレイヤ2スイッチ(100)からの情報で、該当するグループアドレスがなかった場合は再確認をする。
さらに、この再確認時にはまだ参加グループはなかったが、その後認証・課金サーバ(S2)で保持している情報が更新されて、グループアドレス224.10.10.10に参加できるようになったことを想定すると、レイヤ2スイッチ(100)の配信制御テーブル(100−4−1)の配信許可(100−4−1−6)は「拒絶」となっているため、何度ユーザ端末(H1−2)が参加要求をリトライしても、許可されなくなってしまう。そこで、この配信許可(100−4−1−6)が「拒絶」と更新した場合には、その情報の有効時間(規定回数)を設定して、有効時間(規定回数)を過ぎたら「拒絶」から「不明」へ変更するようにしてもよい。これによってルータ(200)が認証・課金サーバ(S2)へ再確認をする契機ができる。
以上のように、ユーザ端末のマルチキャストサービスへの参加要求を把握できないルータ(200)で許可、拒絶の制御をするのではなく、レイヤ2スイッチ(100)がルータ(200)の情報を受け取り、かつ定期的に整合性を確認することで、ユーザ端末から参加要求があるたびにルータ(200)もしくは認証・課金サーバ(S2)へ認証確認が不要であり、必要最小限の認証確認で正確にレイヤ2スイッチ(100)で制御できるようになる。
(マルチキャストサービス課金方法)
本実施の形態が想定するネットワーク構成では、ルータが配信データのユーザ端末への転送制御を行わないため、ユーザ端末がマルチキャストサービスにいつ参加して、いつ離脱するかをルータで把握できない。そのため、例えば特開2006−148750号公報に開示された技術のように、ルータが、ユーザ端末の参加と離脱を契機に、課金サーバに対して課金開始通知と課金終了通知を送信することができない。そこで本実施の形態では、配信データのユーザ端末への転送制御を行うレイヤ2スイッチで課金に必要となる情報を収集し、例えばユーザ端末のグループからの離脱を契機にそれらの情報をルータへ送信し、ルータが課金サーバへ転送することで課金を実現させる。
ここで、ユーザ端末のグループからの離脱とは、例えば、ユーザ端末からのLeaveパケット受信、定期的な参加確認(Query)に対する応答(Report)なし、PPPセッション切断の3つがある。なお、これら以外によるものでもよい。以下、これらについて順に説明する。
まず、図18、図21を参照して、参加しているユーザ端末(H1−1)から離脱宣言であるLeaveパケットを受信した場合の流れを説明する。
配信サーバ(S1)からデータが配信され(SQ4−1)、ルータ(200)はマルチキャスト用コネクション管理テーブル(200−4−2)を参照し(SQ4−1)、レイヤ2スイッチ(100)にデータを転送する(SQ4−3)。レイヤ2スイッチ(100)は配信制御テーブル(例えば図6(a))を参照し(SQ4−4)、ユーザ端末(H1−1、H1−n)へデータを転送している(SQ4−5)。
ここで、ユーザ端末(H1−1)からグループアドレス224.10.10.10からの離脱宣言であるLeaveパケットが送信される(SQ4−7)。Leaveパケットは、例えば、グループアドレスと端末MACアドレスを含む。レイヤ2スイッチ(100)のプロセッサ(100−3)では、ユーザ端末からLeaveパケットを受信する(F1−5−1)と、図21に示すフローで処理をすすめる。
まず、レイヤ2スイッチ(100)は、配信制御テーブル(100−4−1)のユーザ端末(H1−1)のMACアドレスに対応する配信終了時刻(100−4−1−8)に現在時刻を記録する(F1−5−2、SQ4−8、図22(a))。次に、グループアドレス224.10.10.10に参加しているユーザ端末が他にあるかを確認し(F1−5−3)、他のユーザ端末(H1−n)が参加している場合にはJoinパケットに配信制御テーブル(100−4−1)の情報を付与し、ルータ(200)へ送信する(F1−5−4、SQ4−9)。送信後、離脱したユーザ端末(H1−1)の情報を配信制御テーブル(100−4−1)から削除する(F1−5−6、SQ4−10、図22(b))。
配信終了(100−4−1−8)に時刻が記録されている情報をルータ(200)が受信すると、配信情報テーブル(200−4−1)の対応するユーザ情報のグループアドレス(200−4−1−3)を削除し(SQ4−11、図23)、レイヤ2スイッチ(100)から受け取った、配信開始/終了時刻、トラヒック量、グループアドレスとユーザID(200−4−1−1)を課金情報として認証・課金サーバ(S2)へ送信する(F2−3、SQ4−12)。配信業者は認証・課金サーバに残された情報から課金を実現できる。
また、ユーザ端末(H1−1)が離脱後、さらにユーザ端末(H1−n)がLeaveパケットを送信する(SQ4−13)と、レイヤ2スイッチ(100)では同様に配信制御テーブル(100−4−1)を更新する(SQ4−14)。この場合、他にグループアドレス224.10.10.10に参加している他ユーザ端末はないため、Leaveパケットに配信制御テーブル(100−4−1)の情報を付与し送信する(F1−5−5、SQ4−15)。送信後、配信制御テーブル(100−4−1−)からユーザ端末(H1−n)の情報を削除する(F1−5−6、SQ4−16)。
ルータ(200)は、レイヤ2スイッチ(100)からLeaveパケットを受信すると(SQ4−15)、配信情報テーブル(200−4−1)のグループアドレスを削除し(SQ4−17)、配信サーバ(S2)に対して配信停止要求であるPIM Leaveを送信する(SQ4−18)。そして、最初に離脱したユーザ端末(H1−1)のときと同様に、ユーザ端末(H1−n)の課金情報を認証・課金サーバへ送信する(SQ4−19)。
次に、図19を参照して、定期的な参加確認(Query)に対するユーザ端末(H1−1)の応答(Report)がなかった場合について説明する。
まず、ルータ(200)から参加確認であるQueryパケットがレイヤ2スイッチ(100)送信される(SQ5−1)と、そのパケットを受信したレイヤ2スイッチ(100)は配信制御テーブル(100−4−1)を参照し(SQ5−2)、ユーザ端末(H1−1、H1−n)へQueryパケットを送信する(SQ5−3)。レイヤ2スイッチ(100)ではある一定時間内にユーザ端末(H1−1、H1−n)から参加継続を示すReportパケットが返信されない場合(SQ5−4)、端末が離脱したと判断し、Leaveパケットを受信したときと同様の処理を行う。例えば、レイヤ2スイッチ(100)は、配信制御テーブル(100−4−1)を更新し(SQ5−5、図22(a))、その情報をルータ(200)へ送信し(SQ5−6)、ユーザ情報を削除する(SQ5−7、図22(b))。ルータ(200)でも同様に課金情報を認証・課金サーバ(S2)へ送信することで、ユーザ端末から参加確認(Query)に対する応答(Report)がなかった場合でも、課金が実現できる(SQ5−8、SQ5−9)。
ただし、レイヤ2スイッチ(100)がReportパケットを待っている時間や、複数回連続でReportパケットが返信されなかった場合に離脱と判断するなど、通常のマルチキャストルータのような機能をレイヤ2スイッチ(100)持たせることでサービス内容や課金方法、ユーザ端末数などの環境に対応できる。
次に、図20を参照して、PPPセッション切断時の場合について説明する。
本実施の形態の想定するネットワーク構成では、PPPセッションが切断された場合、そのセッション上で行っているマルチキャストサービスも継続できなくなる。
ユーザ端末(H1−1)とルータ(200)間のPPPセッションが切断されると(SQ6−1)、ルータ(200)は配信情報テーブル(200−4−1)を図23のように更新し(SQ6−2)、更新した後の情報をQueryパケットに付与しレイヤ2スイッチ(100)へ送信する(SQ−6−3)。
レイヤ2スイッチ(100)では、PPPセッションが切断されたユーザ端末(H1−1)は配信許可(100−4−1−6)が拒絶であると判断し、配信制御テーブル(100−4−1)の配信終了(100−4−1−8)時刻を記録し(SQ6−4、図22(a))、その情報をルータへ送信する(SQ6−5)。その後、配信制御テーブル(100−4−1)からユーザ端末(H1−1)の情報を削除する(SQ6−6、図22(b))。このとき、レイヤ2スイッチ(100)では本来であれば、ルータ(200)からQueryパケットを受信すると、配信制御テーブル(100−4−1)を更新する前に配信制御テーブル(100−4−1)を参照してユーザ端末(H1−1、H1−n)へQueryパケットを送信する。しかし、参加中のユーザ端末(H1−1)がルータ(200)のQueryパケットにより拒絶となった場合には、配信制御テーブル(100−4−1)を更新しルータ(200)へ情報を送信するようにしてもよい。
以上のように、ルータ(200)ではなくレイヤ2スイッチ(100)で課金に必要な情報を収集し、ルータ(200)を介して認証・課金サーバへ送信することで課金を実現できる。
また、ルータ(200)の配信情報テーブル(200−4−1)のグループアドレス(200−4−1−3)に有効期限を設定し、その情報も合わせてレイヤ2スイッチ(100)へ送信することで、レイヤ2スイッチ(100)ではその有効期限が切れた場合に配信データの転送をやめるなど、時間によるプリペイド式課金も可能となる。さらに、有効期限のかわりにトラヒック量を設定し、そのトラヒック量を超えた場合に転送をやめるなどトラヒック量によるプリペイド式課金も可能となる。
2. 第2の実施の形態
第2の実施の形態では、認証を伴う配信データの制御については第1の実施の形態と同様に行う。
(マルチキャストサービス課金方法)
図24に、第2の実施の形態による課金動作シーケンスを示す。
第1の実施の形態では、ユーザ端末からのIGMPパケットをレイヤ2スイッチで終端していたが、第2の実施の形態では、レイヤ2スイッチは終端はせずにスヌーピングする。
図24を参照して、グループアドレス224.10.10.10のマルチキャストサービスへの参加資格を有するユーザ端末(H1−1)が配信サーバ(S1)からの配信データを受信し、離脱宣言(Leave)により離脱した場合の流れについて説明する。
グループアドレス224.10.10.10への参加資格を有するユーザ端末(H1−1)が、PPP接続要求をし、ルータ(200)から認証完了通知を受信するまでの動作(SQ7−1〜SQ7−5)は第1の実施の形態の場合と同じである。PPP接続完了後、ユーザ端末(H1−1)がJoinパケットを送信すると(SQ7−6)、レイヤ2スイッチ(100)はパケットの中身をスヌーピングし、そのパケットをルータ(200)へ転送する。Joinパケットは、例えば、グループアドレスとユーザ端末のMACアドレスとを含む。レイヤ2スイッチ(100)は、スヌーピングした情報から図16のフローに従い、第1の実施の形態と同様に処理をすすめる(SQ7−10〜SQ7−13)。
一方、レイヤ2スイッチ(100)で転送されたパケットをルータ(200)が受信すると、配信情報テーブル(200−4−1)を参照し(SQ7−7)、課金開始通知(Access−Request−Start)を認証・課金サーバ(S2)へ送信する(SQ7−8)。課金開始通知は、例えば、グループアドレスとユーザ端末のMACアドレスとを含む。認証・課金サーバ(S2)では課金開始通知を受信した時刻を、例えば端末のMACアドレス毎に記録し、ルータ(200)へ応答(Access−Request−Response)を返す(SQ7−9)。また、ルータ(200)は、配信サーバ(S1)へ配信要求(PIM Join)を送信する(SQ7−14)。
ルータ(200)はマルチキャスト用コネクション(LM)を介してレイヤ2スイッチ(100)からパケットを受信すると図17のフローに従い、第1の実施の形態と同様に処理をすすめ、各装置で管理するユーザ情報の整合性をとる(SQ7−15〜SQ7−17)。ルータ(200)からの配信要求(SQ7−14)により、第1の実施の形態と同様に配信データがユーザ端末(H1−1)へ転送される(SQ7−20〜SQ7−24)。なお、本実施の形態では、ルータ(200)はユーザ端末からJoinを受信しているが、例えば、レイヤ2スイッチ(100)との間に確立されたマルチキャスト用のコネクションを介して、配信データをレイヤ2スイッチ(100)に送信し、レイヤ2スイッチ(100)がデータをコピーしてユーザ端末(H1−1)に配信するようにしてもよい。
グループアドレス224.10.10.10へ参加中であるユーザ端末(H1−1)が、Leaveパケットを送信すると(SQ7−25)、レイヤ2スイッチ(100)はパケットの中身をスヌーピングし、そのパケットをルータ(200)へ転送する。Leaveパケットは、例えば、グループアドレスとユーザ端末のMACアドレスとを含む。レイヤ2スイッチ(100)は、スヌーピングした情報から図21のフローに従い、第1の実施の形態と同様に処理をすすめる(SQ7−26〜SQ7−28)。
一方、レイヤ2スイッチ(100)で転送されたLeaveパケットをルータ(200)が受信すると、配信情報テーブル(200−4−1)を更新し(SQ7−29)、課金終了通知(Access−Request−Stop)を認証・課金サーバ(S2)へ送信する(SQ7−31)。課金終了通知は、例えば、グループアドレスとユーザ端末のMACアドレスとを含む。また、ルータ(200)は、配信サーバ(S1)へ配信停止要求(PIM Leave)を送信する(SQ7−30)。認証・課金サーバ(S2)では課金終了通知を記録し、ルータ(200)へ応答(Access−Request−Response)を返す(SQ7−32)。
以上により、認証・課金サーバ(S2)では、ユーザ端末(H1−1)がグループアドレス224.10.10.10に参加した時刻と、離脱した時刻を把握することができ配信業者はマルチキャストサービスの課金が実現できる。例えば、ユーザ端末毎の課金、グループアドレスに応じた課金が実現できる。
また、ルータ(200)が課金終了通知送信するときに、レイヤ2スイッチ(100)から受信した(SQ7−27)課金情報を付与することでより正確な課金や従量課金が実現できる。
本発明は、例えば、IPv6、MLD等の各種方式に適用することができる。また、本発明は、レイヤ2スイッチに限らず、各手段を実装でき、ルータとユーザ端末間に配置されるBAS(Broadband Access Server)のような通信装置であれば装置は選ばない。さらに、本発明は、ルータ以外にも、マルチキャスト配信をするものであれば、適宜のパケット転送装置を採用することができる。
本実施の形態が想定するネットワーク構成図。 従来技術を用いた場合のパケットの流れを示す図。 本実施の形態を用いた場合のパケットの流れを示す図。 本実施の形態のレイヤ2スイッチの内部構成の一例を示す図。 レイヤ2スイッチの配信制御テーブルの一例を示す図(1)。 レイヤ2スイッチの配信制御テーブルの一例を示す図(2)。 レイヤ2スイッチのマルチキャスト用コネクション管理テーブルの一例を示す図。 本実施の形態のルータの内部構成の一例を示す図。 ルータの配信情報テーブルの一例を示す図(1)。 ルータのマルチキャスト用コネクション管理テーブルの一例を示す図。 ユーザ端末とルータ間で送受信されるマルチキャストパケット以外のパケット、及び、マルチキャストパケットの構成例。 認証・課金サーバのユーザ管理テーブルの一例を示す図。 ユーザ端末(H1−1)のPPP接続要求からマルチキャストのデータを受信するまでの動作シーケンスを示す図。 図13の状態から、ユーザ端末(H1−n)のPPP接続要求からマルチキャストのデータを受信するまでの動作シーケンスを示す図。 図14の状態から、ユーザ端末(H1−2)のPPP接続要求からマルチキャスト参加要求が拒絶されるまでの動作シーケンスを示す図。 レイヤ2スイッチがユーザ端末からパケットを受信した場合の処理フローを示す図。 ルータがレイヤ2スイッチからIGMPパケットを受信した場合の処理フローを示す図。 ユーザ端末(H1−1、H1−n)がLeaveパケットを送信して離脱した場合の課金動作シーケンスを示す図。 ユーザ端末(H1−1)がReportパケットを返信しなくなり、離脱した場合の課金動作シーケンスを示す図。 ユーザ端末(H1−1)がPPPセッション切断により離脱した場合の課金動作シーケンスを示す図。 レイヤ2スイッチがユーザ端末からLeaveパケットを受信した場合の処理フローを示す図。 レイヤ2スイッチの配信制御テーブルの一例を示す図(3)。 ルータの配信情報テーブルの一例を示す図(2)。 第2の実施の形態の手段を用いた場合の課金動作シーケンスを示す図。
符号の説明
H1−1〜H1−n、H2−1〜H2−n:ユーザ端末
S1:配信サーバ
S2:認証・課金サーバ
100、101:レイヤ2スイッチ
200:ルータ
300:インターネット網
NW1、NW2:アクセスネットワーク
NW3:ISP網
LP1〜LPn:PPPコネクション
LM:マルチキャスト用コネクション
100−1−1〜100−1−n:回線インタフェース
100−2:回線インタフェース制御部
100−3:プロセッサ
100−4:メモリ
100−4−1:配信制御テーブル
100−4−2:マルチキャスト用コネクション管理テーブル
100−4−3:プログラム
100−5:制御端末インタフェース
100−6:制御端末
100−4−1−1:グループアドレス
100−4−1−2:回線インタフェース
100−4−1−3:Session ID
100−4−1−4:ユーザ端末MACアドレス
100−4−1−5:参加要求(あり/なし)
100−4−1−6:配信許可(許可/拒絶/不明)
100−4−1−7:配信開始(時刻)
100−4−1−8:配信終了(時刻)
100−4−1−9:トラヒック(Mbyte)
100−4−2−1:グループアドレス
100−4−2−2:回線インタフェース
100−4−2−3:Session ID
100−4−2−4:ルータMACアドレス
200−1−1〜200−1−n:回線インタフェース
200−2:回線インタフェース制御部
200−3:プロセッサ
200−4:メモリ
200−4−1:配信情報テーブル
200−4−2:マルチキャスト用コネクション管理テーブル
200−4−3:プログラム
200−5:制御端末インタフェース
200−6:制御端末
200−4−1−1:ユーザID
200−4−1−2:パスワード
200−4−1−3:グループアドレス
200−4−1−4:回線インタフェース
200−4−1−5:Session ID
200−4−1−6:ユーザ端末MACアドレス
200−4−2−1:グループアドレス
200−4−2−2:回線インタフェース
200−4−2−3:Session ID
200−4−2−4:レイヤ2スイッチMACアドレス
300:送信先MACアドレス
301:送信元MACアドレス
302:PPPoEヘッダ情報
303:PPPヘッダ情報
304:送信元IPアドレス
305:送信先IPアドレス
306:データ領域
307:IGMPヘッダ情報
308:データ領域

Claims (10)

  1. 複数のユーザ端末を終端し、受信したマルチキャストデータをコピーして前記ユーザ端末へ転送する第1のパケット転送装置と、
    前記第1のパケット転送装置を介して複数の前記ユーザ端末とポイント トゥ ポイント接続される第2のパケット転送装置と、
    前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを前記第2のパケット転送装置に出力するサーバと
    を備え、
    前記第1のパケット転送装置は、
    グループアドレスと、前記ユーザ端末の端末識別情報と、配信許可及び配信拒絶のいずれかを示す情報とを含むエントリが記憶される配信制御テーブル
    を有し、
    前記第2のパケット転送装置は、前記ユーザ端末からポイント トゥ ポイント接続の接続要求を受信すると、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを取得し、
    前記第2のパケット転送装置は、受信されたグループアドレスと、前記ユーザ端末の端末識別情報とを対応して記憶し、
    前記第1のパケット転送装置は、前記ユーザ端末から、予め定められたグループアドレスと該ユーザ端末の端末識別情報を含み、該ユーザ端末を送信元としたマルチキャストグループへの第1の参加要求を受信すると、該第1の参加要求を終端し、及び、前記配信制御テーブルに該グループアドレスと該端末識別情報とを対応して記憶し、
    前記第1のパケット転送装置は、受信したグループアドレスと端末識別情報を含み、自装置を送信元とした第2の参加要求を前記第2のパケット転送装置に送信し、
    前記第2のパケット転送装置は、第2の参加要求に含まれるグループアドレス及び端末識別情報と、記憶されたグループアドレス及び端末識別情報とを比較し、一致するものが記憶されていれば配信許可を示し、及び、記憶されていなければ配信拒絶を示す通知を前記第1のパケット転送装置に送信し、
    前記第1のパケット転送装置は、該通知に従い、該グループアドレスと該端末識別情報とに対応して、配信許可又は配信拒絶を示す情報を前記配信制御テーブルに記憶し、
    前記第1のパケット転送装置は、前記第2のパケット転送装置からグループアドレスを含むマルチキャストデータを受信し、前記配信制御テーブルを参照して、該グループアドレスに対応して配信許可を示す情報が記憶されたエントリの端末識別情報に従い、受信されたマルチキャストデータ及び/又はコピーしたマルチキャストデータをひとつ又は複数の前記ユーザ端末に送信するネットワークシステム。
  2. 前記第1のパケット転送装置は、端末識別情報毎に、マルチキャストデータの配信開始時刻と配信終了時刻を記憶し、
    前記ユーザ端末が、マルチキャストグループから離脱したと判断すると、該ユーザ端末の端末識別情報と配信開始時刻と配信終了時刻を前記第2のパケット転送装置に送信し、
    前記第2のパケット転送装置は、配信開始時刻と配信終了時刻に基づく課金情報を、課金の管理を行う課金サーバに送信する請求項1に記載のネットワークシステム。
  3. 前記第1のパケット転送装置は、端末識別情報毎に、マルチキャストデータを配信したトラヒック量を記憶し、
    前記ユーザ端末が、マルチキャストグループから離脱したと判断すると、該ユーザ端末の端末識別情報とトラヒック量を前記第2のパケット転送装置に送信し、
    前記第2のパケット転送装置は、トラヒック量に基づく課金情報を、課金の管理を行う課金サーバに送信する請求項1に記載のネットワークシステム。
  4. 前記第1のパケット転送装置は、前記ユーザ端末がマルチキャストグループから離脱したことを、
    該ユーザ端末から離脱宣言を受信したこと、又は、該ユーザ端末に参加確認を送信し、該参加確認に対する応答が所定時間内に受信されたかったこと、又は、前記第2のパケット転送装置から該ユーザ端末とのポイント トゥ ポイント接続が切断された通知を受けたことにより判断する請求項2又は3に記載のネットワークシステム。
  5. 前記第2のパケット転送装置は、
    グループアドレスに対応して、前記第1のパケット転送装置とのコネクションを識別するためのコネクション識別情報が記憶されるコネクション管理テーブル
    を有し、
    前記第1のパケット転送装置と前記第2のパケット転送装置の間で、マルチキャストデータを通信するためのコネクションを確立し、
    前記第2のパケット転送装置は、前記コネクション管理テーブルに、グループアドレスとコネクション識別情報を対応して記憶し、
    前記第2のパケット転送装置は、グループアドレスを含むマルチキャストデータを受信すると、前記コネクション管理テーブルを参照して、該グループアドレスに対応するコネクション情報に従い、確立されたマルチキャストデータを通信するためのコネクションを介して、前記第1のパケット転送装置にマルチキャストデータを送信する請求項1に記載のネットワークシステム。
  6. 前記第2のパケット転送装置は、前記サーバから受信されたグループアドレスに対応して前記ユーザ端末の端末識別情報が記憶される配信情報テーブルを有し、
    前記第2のパケット転送装置は、前記配信情報テーブルの各情報を前記第1のパケット転送装置に送信し、
    前記第1のパケット転送装置は、前記配信制御テーブルの各情報を前記第1のパケット転送装置に送信し、
    前記第1のパケット転送装置の前記配信制御テーブルと、前記第2のパケット転送装置の前記配信情報テーブルとで情報の整合を取ることを特徴とする請求項1に記載のネットワークシステム。
  7. 前記第2のパケット転送装置は、第2の参加要求に含まれるグループアドレス及び端末識別情報と一致するグループアドレス及び端末識別情報が記憶されていない場合、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを再度取得して、新たに取得されたグループアドレスを用いて、再度前記比較を行う請求項1に記載のネットワークシステム。
  8. 複数のユーザ端末を終端し、受信したマルチキャストデータをコピーして前記ユーザ端末へ転送する第1のパケット転送装置と、
    前記第1のパケット転送装置を介して複数の前記ユーザ端末とポイント トゥ ポイント接続される第2のパケット転送装置と、
    前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを前記第2のパケット転送装置に出力するサーバと
    を備え、
    前記第1のパケット転送装置は、
    グループアドレスと、前記ユーザ端末の端末識別情報と、配信許可及び配信拒絶のいずれかを示す情報と、参加要求の受信及び未受信のいずれかを示す情報とを含むエントリが記憶される配信制御テーブル
    を有し、
    前記第2のパケット転送装置は、前記ユーザ端末からポイント トゥ ポイント接続の接続要求を受信すると、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを取得し、
    前記第2のパケット転送装置は、受信されたグループアドレスと、前記ユーザ端末の端末識別子とを含む通知を前記第1のパケット転送装置に送信し、
    前記第1のパケット転送装置は、該通知に含まれるグループアドレス及び端末識別子と、配信許可を示す情報とを対応して前記配信制御テーブルに記憶し、
    前記第1のパケット転送装置は、前記ユーザ端末から予め定められたグループアドレスと該ユーザ端末の端末識別情報を含むマルチキャストグループへの参加要求を受信すると、前記配信制御テーブルの該当するグループアドレスと端末識別情報に対応して、参加要求の受信を示す情報を記憶し、
    前記第1のパケット転送装置は、前記第2のパケット転送装置からグループアドレスを含むマルチキャストデータを受信し、前記配信制御テーブルを参照して、該グループアドレスに対応して参加要求の受信を示す情報及び配信許可を示す情報が記憶されたエントリの端末識別情報に従い、受信されたマルチキャストデータ及び/又はコピーしたマルチキャストデータをひとつ又は複数の前記ユーザ端末に送信するネットワークシステム。
  9. 複数のユーザ端末を終端し、受信したマルチキャストデータをコピーして前記ユーザ端末へ転送する第1のパケット転送装置と、
    前記第1のパケット転送装置を介して複数の前記ユーザ端末とポイント トゥ ポイント接続される第2のパケット転送装置と、
    前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを前記第2のパケット転送装置に出力し、及び、課金開始通知及び課金終了通知を受信することにより端末識別情報毎に課金を行うサーバと
    を備え、
    前記第1のパケット転送装置は、
    グループアドレスと、前記ユーザ端末の端末識別情報と、配信許可及び配信拒絶のいずれかを示す情報とを含むエントリが記憶される配信制御テーブル
    を有し、
    前記第2のパケット転送装置は、前記ユーザ端末からポイント トゥ ポイント接続の接続要求を受信すると、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを取得し、
    前記第2のパケット転送装置は、受信されたグループアドレスと前記ユーザ端末の端末識別情報とを対応して記憶し、
    前記第1のパケット転送装置は、前記ユーザ端末から、予め定められたグループアドレスと該ユーザ端末の端末識別情報を含むマルチキャストグループへの参加要求を受信すると、該参加要求をスヌーピングして、前記配信制御テーブルに該グループアドレスと該端末識別情報とを記憶し、及び、該参加要求を前記第2のパケット転送装置に転送し、
    前記第2のパケット転送装置は、受信した参加要求に含まれるグループアドレス及び/又は端末識別情報を含む課金開始通知を前記サーバに送信し、
    前記第2のパケット転送装置は、受信した参加要求に含まれるグループアドレス及び端末識別情報と、記憶されたグループアドレス及び端末識別情報とを比較し、一致するものが記憶されていれば配信許可を示し、及び、記憶されていなければ配信拒絶を示す通知を前記第1のパケット転送装置に送信し、
    前記第1のパケット転送装置は、該通知に従い、グループアドレスと端末識別情報とに対応して、配信許可又は配信拒絶を示す情報を前記配信制御テーブルに記憶し、
    前記第1のパケット転送装置は、前記第2のパケット転送装置からグループアドレスを含むマルチキャストデータを受信し、前記配信制御テーブルを参照して、該グループアドレスに対応して配信許可を示す情報が記憶されたエントリの端末識別情報に従い、受信されたマルチキャストデータ及び/又はコピーしたマルチキャストデータをひとつ又は複数の前記ユーザ端末に送信し、
    前記第2のパケット転送装置は、前記第1のパケット転送装置を介して前記ユーザ端末から、グループアドレスと端末識別情報を含む離脱宣言を受信すると、受信した離脱宣言に含まれるグループアドレス及び/又は端末識別情報を含む課金終了通知を前記サーバに送信するネットワークシステム。
  10. 前記第2のパケット転送装置が前記ユーザ端末から参加要求を受信すると、前記第1のパケット転送装置と前記第2のパケット転送装置の間で、マルチキャストデータを通信するためのコネクションを確立し、
    前記第2のパケット転送装置は、グループアドレスを含むマルチキャストデータを受信すると、確立された前記コネクションを介して、前記第1のパケット転送装置にマルチキャストデータを転送する請求項9に記載のネットワークシステム。
JP2007071241A 2007-03-19 2007-03-19 ネットワークシステム Expired - Fee Related JP4773387B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2007071241A JP4773387B2 (ja) 2007-03-19 2007-03-19 ネットワークシステム
US12/022,376 US20080232368A1 (en) 2007-03-19 2008-01-30 Network system
CN200810009045XA CN101272322B (zh) 2007-03-19 2008-01-30 网络系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007071241A JP4773387B2 (ja) 2007-03-19 2007-03-19 ネットワークシステム

Publications (2)

Publication Number Publication Date
JP2008236230A true JP2008236230A (ja) 2008-10-02
JP4773387B2 JP4773387B2 (ja) 2011-09-14

Family

ID=39774620

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007071241A Expired - Fee Related JP4773387B2 (ja) 2007-03-19 2007-03-19 ネットワークシステム

Country Status (3)

Country Link
US (1) US20080232368A1 (ja)
JP (1) JP4773387B2 (ja)
CN (1) CN101272322B (ja)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013042375A1 (en) * 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, control apparatus, communication system, communication control method, and computer program
WO2013042358A1 (en) * 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, communication system, communication control method, and program
WO2013042374A1 (en) * 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, control apparatus, communication system, communication control method, and program
WO2013145724A1 (en) * 2012-03-28 2013-10-03 Nec Corporation Communication system, control apparatus, communication apparatus, accounting server, communication method and program
JP2014504842A (ja) * 2011-02-04 2014-02-24 テケレック,インク. Diameterバインディングリポジトリを供給する方法、システム及びコンピュータ読取り可能媒体
JP2014042188A (ja) * 2012-08-23 2014-03-06 Nippon Telegr & Teleph Corp <Ntt> オペレーションサポートシステム、マルチキャスト通信システム、及びプログラム
JP2014045509A (ja) * 2013-11-01 2014-03-13 Nec Corp 通信装置、制御装置、通信システム、通信制御方法及びプログラム
JP2014093605A (ja) * 2012-11-01 2014-05-19 Nippon Telegr & Teleph Corp <Ntt> マルチキャスト番組時間課金システム及び方法
JP2017200012A (ja) * 2016-04-26 2017-11-02 株式会社ナカヨ 統合脅威管理システム、統合脅威管理装置、および統合脅威管理方法
JP2021536711A (ja) * 2018-09-13 2021-12-27 テレフオンアクチーボラゲット エルエム エリクソン(パブル) 通信可能に結合される通信デバイスのネットワークでのメッセージの選択的転送をサポートする方法およびデバイス

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7787375B2 (en) * 2007-08-06 2010-08-31 International Business Machines Corporation Performing a recovery action in response to a credit depletion notification
US7975027B2 (en) * 2007-08-06 2011-07-05 International Business Machines Corporation Credit depletion notification for transmitting frames between a port pair
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
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
JP4942686B2 (ja) 2008-03-18 2012-05-30 株式会社リコー ネットワーク同期システム及び情報処理装置
CN101651553B (zh) * 2009-09-03 2013-02-27 华为技术有限公司 用户侧组播业务主备保护系统、方法及路由设备
CN102045315B (zh) * 2009-10-22 2014-06-04 华为技术有限公司 进行网络会议的方法、系统、控制器和复制分发器
CN102694663A (zh) * 2011-03-25 2012-09-26 中国移动通信集团公司 中转多播传输方法、系统、中转选择服务器、中转节点及终端
EP2814213A4 (en) 2012-02-10 2015-09-09 Nec Corp CONTROL DEVICE, COMMUNICATION SYSTEM, COMMUNICATION PROCESS AND PROGRAM
CN103379444B (zh) * 2012-04-23 2017-12-05 中兴通讯股份有限公司 多播信息处理方法、多播信息发送方法及装置
US9300483B2 (en) * 2013-03-15 2016-03-29 International Business Machines Corporation Self-routing multicast in a software defined network fabric
CN107211483B (zh) * 2015-01-19 2020-07-24 华为技术有限公司 一种数据通信方法及终端
WO2019187551A1 (ja) * 2018-03-26 2019-10-03 三菱電機株式会社 マルチキャスト配信先指定方法、送信局及び受信局
US20230130865A1 (en) * 2021-10-27 2023-04-27 Arris Enterprises Llc Multicast state synchronization

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004043019A1 (ja) * 2002-11-05 2004-05-21 Fujitsu Limited ネットワーク中継方法及び装置
JP2004357200A (ja) * 2003-05-30 2004-12-16 Nippon Telegr & Teleph Corp <Ntt> マルチキャスト通信システム、マルチキャスト通信システムの制御方法およびスヌーピング装置
JP2005142656A (ja) * 2003-11-04 2005-06-02 Nippon Telegr & Teleph Corp <Ntt> Ipマルチキャスト配信制御システム
JP2006042223A (ja) * 2004-07-30 2006-02-09 Hitachi Communication Technologies Ltd パケット転送装置
JP2006109047A (ja) * 2004-10-05 2006-04-20 Hitachi Communication Technologies Ltd レイヤ2スイッチ
JP2006148750A (ja) * 2004-11-24 2006-06-08 Hitachi Communication Technologies Ltd マルチキャスト課金制御システム及びブロードバンドアクセスサーバ

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7061880B2 (en) * 2001-10-11 2006-06-13 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for multicast communications
US7305010B2 (en) * 2002-01-11 2007-12-04 Nippon Telegraph And Telephone Corporation Multicast communication system
CN1192574C (zh) * 2002-01-30 2005-03-09 华为技术有限公司 受控组播的系统及其实现方法
US20050111474A1 (en) * 2002-10-31 2005-05-26 Fujitsu Limited IP multicast communication system
US7983205B1 (en) * 2003-06-20 2011-07-19 Juniper Networks, Inc. Outgoing interface mapping for multicast traffic
US20050080901A1 (en) * 2003-10-14 2005-04-14 Reader Scot A. Method and apparatus for controlling access to multicast data streams
KR100738526B1 (ko) * 2005-06-02 2007-07-11 삼성전자주식회사 다중 영구가상회선 접속환경을 위한 중간 인증관리 시스템및 그 방법
KR101338035B1 (ko) * 2005-08-16 2013-12-09 지멘스 악티엔게젤샤프트 정보를 전송하기 위한 방법, 통신 설비 및 통신 장치
US8503446B2 (en) * 2005-08-29 2013-08-06 Alcatel Lucent Multicast host authorization tracking, and accounting

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004043019A1 (ja) * 2002-11-05 2004-05-21 Fujitsu Limited ネットワーク中継方法及び装置
JP2004357200A (ja) * 2003-05-30 2004-12-16 Nippon Telegr & Teleph Corp <Ntt> マルチキャスト通信システム、マルチキャスト通信システムの制御方法およびスヌーピング装置
JP2005142656A (ja) * 2003-11-04 2005-06-02 Nippon Telegr & Teleph Corp <Ntt> Ipマルチキャスト配信制御システム
JP2006042223A (ja) * 2004-07-30 2006-02-09 Hitachi Communication Technologies Ltd パケット転送装置
JP2006109047A (ja) * 2004-10-05 2006-04-20 Hitachi Communication Technologies Ltd レイヤ2スイッチ
JP2006148750A (ja) * 2004-11-24 2006-06-08 Hitachi Communication Technologies Ltd マルチキャスト課金制御システム及びブロードバンドアクセスサーバ

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014504842A (ja) * 2011-02-04 2014-02-24 テケレック,インク. Diameterバインディングリポジトリを供給する方法、システム及びコンピュータ読取り可能媒体
CN103891221A (zh) * 2011-09-21 2014-06-25 日本电气株式会社 通信装置、控制装置、通信系统、通信控制方法和计算机程序
WO2013042358A1 (en) * 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, communication system, communication control method, and program
WO2013042374A1 (en) * 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, control apparatus, communication system, communication control method, and program
JP2013070183A (ja) * 2011-09-21 2013-04-18 Nec Corp 通信装置、制御装置、通信システム、通信制御方法及びプログラム
WO2013042375A1 (en) * 2011-09-21 2013-03-28 Nec Corporation Communication apparatus, control apparatus, communication system, communication control method, and computer program
WO2013145724A1 (en) * 2012-03-28 2013-10-03 Nec Corporation Communication system, control apparatus, communication apparatus, accounting server, communication method and program
JP2015515153A (ja) * 2012-03-28 2015-05-21 日本電気株式会社 通信システム、制御装置、通信装置、課金サーバ、通信方法およびプログラム
JP2014042188A (ja) * 2012-08-23 2014-03-06 Nippon Telegr & Teleph Corp <Ntt> オペレーションサポートシステム、マルチキャスト通信システム、及びプログラム
JP2014093605A (ja) * 2012-11-01 2014-05-19 Nippon Telegr & Teleph Corp <Ntt> マルチキャスト番組時間課金システム及び方法
JP2014045509A (ja) * 2013-11-01 2014-03-13 Nec Corp 通信装置、制御装置、通信システム、通信制御方法及びプログラム
JP2017200012A (ja) * 2016-04-26 2017-11-02 株式会社ナカヨ 統合脅威管理システム、統合脅威管理装置、および統合脅威管理方法
JP2021536711A (ja) * 2018-09-13 2021-12-27 テレフオンアクチーボラゲット エルエム エリクソン(パブル) 通信可能に結合される通信デバイスのネットワークでのメッセージの選択的転送をサポートする方法およびデバイス
JP7157242B2 (ja) 2018-09-13 2022-10-19 テレフオンアクチーボラゲット エルエム エリクソン(パブル) 通信可能に結合される通信デバイスのネットワークでのメッセージの選択的転送をサポートする方法およびデバイス
US11552815B2 (en) 2018-09-13 2023-01-10 Telefonaktiebolaget Lm Ericsson (Publ) Method of and devices for supporting selective forwarding of messages in a network of communicatively coupled communication devices
US11750411B2 (en) 2018-09-13 2023-09-05 Telefonaktiebolaget Lm Ericsson (Publ) Method of and devices for supporting selective forwarding of messages in a network of communicatively coupled communication devices

Also Published As

Publication number Publication date
CN101272322A (zh) 2008-09-24
JP4773387B2 (ja) 2011-09-14
CN101272322B (zh) 2012-05-16
US20080232368A1 (en) 2008-09-25

Similar Documents

Publication Publication Date Title
JP4773387B2 (ja) ネットワークシステム
CN100456740C (zh) 二层交换器
JP4297875B2 (ja) ネットワーク中継方法及び装置
JP4673752B2 (ja) マルチキャストパケット制御装置
US7627690B2 (en) Data generating device
Holbrook et al. IP multicast channels: EXPRESS support for large-scale single-source applications
EP2154821B1 (en) Method and apparatus for sending and receiving multicast packets
US7751394B2 (en) Multicast packet relay device adapted for virtual router
EP2241091B1 (en) Combining locally addressed devices and wide area network (wan) addressed devices on a single network
US7443851B2 (en) Device and system for multicast communication
EP0888029A2 (en) Method for managing multicast addresses for transmitting and receiving multimedia conferencing information on an internet protocol (IP) network implemented over an ATM network
JP2005516544A (ja) 制御されたマルチキャストのシステム及び実行方法
JP2003158547A (ja) マルチキャスト認証方法、その認証サーバ、ネットワーク間接続装置およびマルチキャスト認証システム
WO1998051040A1 (en) Method for managing multicast addresses in an internet protocol (ip) network
JP2006042223A (ja) パケット転送装置
JP2004172932A (ja) データ配信システム
JP2008060631A (ja) 通信装置及びマルチキャストユーザ認証方法
US9065669B2 (en) Method and apparatus for authorizing multicast forwarding states
JP2000349818A (ja) 情報通信システム、情報提供装置、情報中継装置及び情報通信方法
JP4554420B2 (ja) ゲートウェイ装置及びそのプログラム
KR100764063B1 (ko) 멀티캐스트 기반 다자간 협업 환경에서의 유디피멀티캐스트 터널링 방법 및 그 시스템
JP3794634B2 (ja) マルチキャスト通信システムにおけるルーティング装置、そのルーティング方法およびプログラム
JP3500087B2 (ja) パケット通信方法
JP4036369B2 (ja) マルチキャスト通信システム、マルチキャスト通信システムの制御方法およびスヌーピング装置
JP3239865B2 (ja) 自動的にマルチキャストグループへ参加する方法及びシステム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090617

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20100122

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101102

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101222

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20110222

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110519

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20110526

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

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110623

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

Free format text: PAYMENT UNTIL: 20140701

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