JP4342966B2 - パケット転送装置 - Google Patents

パケット転送装置 Download PDF

Info

Publication number
JP4342966B2
JP4342966B2 JP2004017495A JP2004017495A JP4342966B2 JP 4342966 B2 JP4342966 B2 JP 4342966B2 JP 2004017495 A JP2004017495 A JP 2004017495A JP 2004017495 A JP2004017495 A JP 2004017495A JP 4342966 B2 JP4342966 B2 JP 4342966B2
Authority
JP
Japan
Prior art keywords
multicast
l2tp
lns
packet
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.)
Expired - Fee Related
Application number
JP2004017495A
Other languages
English (en)
Other versions
JP2005210631A (ja
Inventor
▲琢▼ 太田
裕章 宮田
淳 中嶋
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 JP2004017495A priority Critical patent/JP4342966B2/ja
Priority to US10/898,430 priority patent/US7388877B2/en
Priority to CNB2004100589756A priority patent/CN100428734C/zh
Publication of JP2005210631A publication Critical patent/JP2005210631A/ja
Application granted granted Critical
Publication of JP4342966B2 publication Critical patent/JP4342966B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling

Landscapes

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

Description

本発明は、パケット転送装置に係り、特にL2TP(Layer2 Tunneling Protocol)プロトコルを加入者側で終端するパケット転送装置に関する。
加入者端末がインターネット接続事業者(ISP:Internet Service Provider)を介しインターネットに接続する際、加入者のユーザ認証を行うためにPPP(Point to Point Protocol)プロトコルを用いる方法が存在する。PPPプロトコルは加入者端末とISPのアクセスポイント間を1対1接続する第2層相当のプロトコルである。PPPプロトコルは当初ダイヤルアップ接続により各ISPのアクセスポイントに直接接続し、認証を受けインターネットに接続するという形態で使用されてきた。しかし、昨今のインターネット常時接続化に伴い、現在では加入者端末からISPサーバまでの間を電話網とは別にIP(Internet Protocol)を用いたアクセスキャリアネットワークを介する形態がとられている。ここで、アクセスキャリアネットワークは第3層のネットワークであるため、アクセスキャリアネットワークを介しPPPで認証を行うためにはPPPパケットをISP側PPP終端装置まで転送する手段が必要となる。この手段としてL2TPプロトコルが使用されている。
L2TPプロトコルは、アクセスキャリアネットワーク内に加入者端末とインターネット接続事業者の間に論理的な専用線をはり、PPPの終端をアクセスキャリアネットワークの出口(ISP側)にもってくることを可能とする。この論理的な専用線はL2TPトンネル及びL2TPセッションと呼ばれる。L2TPコネクションは、加入者側のL2TP終端装置(LAC:L2TP Access Concentrator)、インターネット接続事業者側のL2TP終端装置(LNS:L2TP Network Server)によって張られ、PPPパケットはL2TPコネクションを介してISP側のL2TP及びPPP終端装置であるLNSで終端される。ここで、LNSはPPPの終端も実施することから、加入者の増加に伴いL2TPのセッションが増加する。なお、L2TPによるPPPコネクションの延長及びLAC/LNSの機能については、RFC2661に示されている。
また、特許文献1には、インターネット接続業者との接続にはL2TP等のIPトンネリング技術を使用し、且つマルチキャストコンテンツの配信には、一般的なルータやレイヤ3のスイッチを具備しているIGMP等のマルチキャストプロトコルやマルチキャストルーティングプロトコルを使用する通信方法が記載されている。
特開2002−164930号公報
一般に、アクセスキャリアネットワーク内をL2TPコネクションによって加入者−ISP間を接続するような形態において、アクセスキャリアネットワークのコスト削減のため、LACとLNS間のトラヒック削減のニーズが高い。
ここで、インターネット上に存在するサーバから番組等をマルチキャスト配信され、加入者が本マルチキャストパケットを受信する場合、LACとLNS間のトラヒック削減のため、LAC部でマルチキャストパケットをコピーし加入者へ配布することが考えられる。しかし、L2TPタイプのアクセスネットワークの場合、ユーザのIPパケットはPPPコネクション内を転送され、一般のLACではPPPコネクションの受け渡しのみを行い、IPパケットレベルの処理は行えないため、LACではマルチキャストパケットの配信先の管理ができない。そこで、IETFドラフト(draft-ietf-12tpext-mcast-03.txt)によればLNSでマルチキャストパケットの配信先リストを管理し、LACに通知することでLACでのマルチキャストパケットのコピー配信を実現している。しかし、この方法ではマルチキャストパケットグループへの加入者の追加・削除依頼が出される度、LNSにて配信先リストを更新しLACに通知するためのシーケンスを実施する必要があり、加入者の追加・削除にタイムラグが生じる、と同時に、配信先リスト転送用のシーケンス分帯域が使用されてしまうという課題がある。
そこで、本発明は、以上の点に鑑み、LACでマルチキャストパケットの配信先を管理し、LACでのマルチキャストパケットのコピー配信を実現することを課題とする。
本発明ではLACにてPPPパケットの中身をスヌーピングしマルチキャストグループの加入者情報を管理する手段を備える。また、マルチキャストグループに参加するために加入者が発行するIGMP join(IGMP:Internet Group Management Protocol)またはMLD join(MLD:Multicast Listener Discovery)等のIGMP/MLDパケットがLNSに到達すると、マルチキャストパケット配信時にLNS側で加入者数分パケットがコピーされてしまうため、LACにて加入者側からのIGMP/MLDパケットを終端する手段を備えることで、LNSでの加入者分のコピー処理を防ぐ。加えて、マルチキャストパケットをL2TPコネクションを介しLNSからLACが受信する手段として、マルチキャスト用のL2TPトンネル及びセッションを張ることを可能とし、これはLAC内の仮想端末がLNSに対しインターネット接続要求を出す手段を具備することで実現する。マルチキャスト用L2TPコネクション確立後、本コネクションにマルチキャストパケットが転送されるための手段として、LAC内の仮想端末からIGMP/MLDパケットをLNSに向け発行することで実現する。本発明は、主に、以上の手段をLACに備えることで前述の課題を解決する。
また、本発明では上記手段を実現するために、装置としては、複数の回線インタフェース部、複数のパケット処理部、内部スイッチ、制御部を備え、外付けで制御端末の接続を可能とする。また、機能及びメモリ上に保持するテーブルとしては、LAC機能と、加入者側からのIGMPパケットのスヌーピング機能、及び、加入者側からのIGMPパケット終端機能を具備し、加入者側からのMLDパケットのスヌーピング機能、及び、加入者側からのMLDパケット終端機能を具備し、マルチキャストグループ用のLNSとのセッション管理を行うIPv4用のLNS―マルチキャストグループ情報テーブル、IPv6用のLNS−マルチキャストグループ情報テーブル、L2TPをデカプセルするためのL2TPデカプセルテーブル、マルチキャストパケットの配信先を決定するIPv4用マルチキャストルーティングテーブル、IPv6用マルチキャストルーティングテーブル、マルチキャストindexテーブルを具備し、パケットコピー機能、ヘッダ付加機能を具備する。
本パケット転送装置は、例えば、それぞれIP網に接続された複数のプロトコル処理部と、上記各プロトコル処理部の間でIPパケットを交換するスイッチ部とを備え、L2TPトンネル及びL2TPセッションが張られたネットワークにおいて、加入者側に位置しL2TPプロトコルを終端するパケット転送装置で、加入者側からのIGMPパケット及びMLDパケットを終端する手段と、マルチキャストパケット用のL2TPトンネル及びL2TPセッションを張る手段と、マルチキャストグループに所属する加入者情報を管理する手段と、マルチキャストパケット用のL2TPトンネル及びL2TPセッションを通してIGMP及びMLDパケット生成し送信する手段と、マルチキャストパケット用のL2TPトンネル及びL2TPセッションから受信したマルチキャストパケットをマルチキャストグループに所属する加入者情報を元にコピーし、加入者へ配信する手段とを備える。
また、本パケット転送装置は、マルチキャストグループと本グループのマルチキャストパケットを受信可能なインターネット側L2TP終端装置のアドレス群と、マルチキャストパケットを受信可能なインターネット側L2TP終端装置群の中からマルチキャスト用のL2TPトンネル及びセッションを張る対向のインターネット側L2TP終端装置を選択するための情報を管理するテーブルを有し、マルチキャストパケットの転送経路を本パケット転送装置と複数のインターネット側L2TP終端装置間で経路の負荷分散を実施することができる。
本パケット転送装置は、あるISPが1つの加入者側L2TP終端装置に対して複数のインターネット側L2TP終端装置を有する場合に、上記のマルチキャスト用のL2TPトンネル及びセッションを張る対向のインターネット側L2TP終端装置を選択するための情報を管理するテーブルを有することで、マルチキャストパケットの転送経路を1つのインターネット側L2TP終端装置に集約することができる。
さらに、本パケット転送装置は、回線異常検出手段を備えることで、別の出力ポートを使用してマルチキャスト用のL2TPトンネル及びL2TPセッションの冗長が、単数または複数のインターネット側L2TP終端装置との間で可能である。
本パケット転送装置は、上記のマルチキャスト用L2TPトンネル及びセッションを張る際、本パケット転送装置からインターネット側L2TP終端装置に対しL2TPトンネル及びセッションを張りにいくことで、既存のマルチキャストに対応したインターネット側L2TP終端装置を利用することが可能である。
本発明の解決手段によると、
L2TP(Layer2 Tunneling Protocol)トンネル及びL2TPセッションが張られたネットワークにおいて、加入者側に位置しL2TPプロトコルを終端するパケット転送装置において、
加入者端末が所属するLNS(L2TP Network Server)アドレス及びマルチキャストグループアドレスに対応して、マルチキャスト用のL2TPコネクションを張るLNSアドレス、L2TPコネクションの確立済みフラグ、上りL2TPトンネル識別子及びセッション識別子を記憶したLNS−マルチキャストグループ情報テーブルと、
LACアドレス、下りL2TPトンネル識別子及びセッション識別子に対応して、マルチキャスト用のL2TPコネクションであることを示すマルチキャストセッションフラグを記憶したL2TPデカプセルテーブルと、
マルチキャスト用のLNSアドレス及びマルチキャストグループアドレスに対応して、マルチキャストパケットをコピー配信する出力インタフェース情報及びポート情報を含む回線情報を記憶したマルチキャストテーブルと、
各前記テーブルにアクセス可能で、インタフェースを介してネットワークに接続されたプロトコル処理部と、
を備え、
前記プロトコル処理部は、
マルチキャストパケットの受信を希望する加入者端末から、加入者端末が所属するLNSアドレス及びマルチキャストグループアドレスを含むマルチキャストグループに参加するためのマルチキャスト受信要求メッセージのパケットを受信する手段と、
加入者端末側からのパケットがマルチキャスト受信要求メッセージを含むか否かを、ヘッダ又はデータ部分から判断し、マルチキャスト受信要求メッセージを含む場合、L2TPカプセル化処理を実施せず、受信したパケットを終端する手段と、
前記LNS−マルチキャストグループテーブルを参照して、受信したLNSアドレス及びマルチキャストグループアドレスに基づいて、マルチキャストグループ用のL2TPコネクションが既に張られているか否かを、L2TPコネクションの確立済みフラグから判断する手段と、
L2TPコネクションが張られている場合、前記マルチキャストテーブルに、LNSアドレス及びマルチキャストグループアドレスに対応して、マルチキャスト受信要求メッセージを送信した加入者端末の出力インタフェース情報及びポート情報を含む回線情報を登録する手段と、
サーバよりマルチキャストパケットを受信し、ヘッダ内のL2TPトンネル識別子及びセッション識別子、宛先アドレスに基づき、前記L2TPデカプセルテーブルを検索し、配信されたパケットがマルチキャスト用のL2TPコネクションから受信したマルチキャストパケットか否かを、マルチキャストセッションフラグにより判断する手段と、
マルチキャスト用パケットと判断すると、L2TPデカプセル処理を行い、LNSアドレスとマルチキャストグループアドレスに基づき、前記マルチキャストテーブルから配信先である加入者端末の出力インタフェース情報及びポート情報を含む回線情報を検索し、回線情報に対応する加入者端末に対しマルチキャストパケットをコピーして配信する手段と
を有するパケット転送装置が提供される。
L2TPを使用したマルチキャスト通信において、従来の技術ではLACでマルチキャストパケットの配布先の管理を伴ったマルチキャストパケット配信を実施することができなかったが、本発明によれば、加入者側からのIGMP/MLDパケットをPPPコネクションから選択的に取り出すことにより、LACでのマルチキャストパケットの配布先管理を伴ったマルチキャストパケット配信機能を実現することができる。これにより、配布先リストの更新が早くなり、かつ、IETFドラフト(draft-ietf-12tpext-mcast-03.txt)にあるLNS−LAC間での配布先リストを同期するためのシーケンス分、アクセスキャリアネットワーク内のトラヒックを軽減させる事ができる。また、1つのLACと複数LNS間で張られる複数L2TPセッションを張るような構成であってもマルチキャスト用のL2TPセッションを1つのLAC−LNS間のセッションに集約し、かつ、複数のL2TPセッションにおける経路の負荷分散を可能とすることにより、アクセスキャリアネットワークの帯域を柔軟かつ有効に活用することが可能となる。加えて、本発明はLACのみに実装されるため、従来のマルチキャスト配信機能を備えたLNSを利用することが可能である。
1.システム構成
図1は、本実施の形態を適用するネットワーク構成例を示す図である。
本システムは、一例として、加入者端末(H1i−j)(i=1〜n、j=1〜n)、LAC(1−i)、LNS(2−i)、サーバ(S1)、ネットワーク(NW1、NW2)を備える。
本実施の形態は、加入者端末(H1i−j)がPPPを用いてインターネットサービスプロバイダ(ISP)を介し、IPでインターネットに接続する形態で、加入者とISP間にアクセスキャリアネットワーク(NW1)が存在し、本アクセスキャリアネットワーク(NW1)内をL2TPプロトコルを使用し論理的なパスを使用する形態に適用する。L2TPトンネル及びセッションはLAC(1−i)及びLNS(2−i)間で張られ、LNSはインターット等のネットワーク(NW2)に接続され、L2TPコネクションを通して加入者とインターネット間のデータ転送が行われる。LNS(2−i)とサーバS1との間は、ルータを有するネットワーク(NW2)で接続される。本実施の形態は、ネットワーク(NW2)上に存在するサーバ(S1)が番組配信等でマルチキャストパケットを加入者に配信する場合に、LAC(1−i)で加入者情報を管理し、かつ、加入者分のパケットコピー及び配信が可能なパケット転送装置を提供するものである。
また、図2に、このときのパケットフォーマットを示す。図示のように、パケットPK1、PK2、PK3は、各装置間で伝送されるパケットのフォーマットをそれぞれ示す。
サーバ(S1)から配信されたパケットは、NW2のIPアドレス規則に従い配信される(パケットPK1)。LNS(2−1)からLAC(1−i)に送信される際は、PPPヘッダ及びL2TPヘッダ、NW1のIPパケットでカプセル化される(パケットPK2)。その後、LAC(1−i)にてL2TPデカプセル処理が実施され、PPPヘッダ、NW2のIPアドレス規則に従ったIPヘッダが付与されたパケットの形(パケットPK3)で加入者端末に配信される。L2ヘッダはそれぞれのネットワークの第2層の形態に従い付与される。
図6に、本実施の形態のLAC内のパケット転送装置の構成図を示す。
パケット転送装置(1)は複数の入出力回線(60−i)と複数の回線インタフェース(30−i)と複数のプロトコル処理部(10−i)、内部スイッチ(20)、及び、内部スイッチ・プロトコル処理部・回線インタフェースを制御する制御部(40)を備え、また、外付けの制御端末(50)による制御を可能とする。
回線インタフェース(30−i)は、IP網の受信信号からIPパケットを再生し、プロトコル処理部(10−i)に転送すると共に、プロトコル処理部(10−i)から受信した出力IPパケットを入出力回線(60−i)上の通信プロトコル、例えば、イーサネット(登録商標)やATM等に従った通信フレーム形式に変換して、IP網に送出する。
各プロトコル処理部(10−i)は、回線インタフェース(30−i)から受信したIPパケット毎に、IPヘッダに含まれる宛先IPアドレスに従ってルーティングテーブルを参照し、出力ポート番号を得るIPルーティングや、後述するマルチキャストパケットルーティング、及び、マルチキャストパケットコピー処理等を実装する。制御部(40)はプロトコル処理部(10−i)、及び、内部スイッチ(20)の状態を監視し、ノード内部状態として制御端末に通知すると共に、制御端末からの指示に応答して、各プロトコル処理部(10−i)への各種の制御パラメータ設定を行う。また、制御部(40)は状態監視が必要なプロトコル処理、例えばL2TPトンネル接続処理等の機能を備える。内部スイッチ(20)は各プロトコル処理部(10−i)から受信したパケットを出力ポートが存在する回線インタフェース(30−i)と接続されるプロトコル処理部(10−i)へ転送する。
図7に、制御部の構成図を示す。
制御部(40)は、処理を実行するプロセッサ(401)、処理内容が記述されたメモリ(41i)、制御端末とのインタフェース(402)、及び、プロトコル処理部(10−i)のプロトコル処理プロセッサと通信するためのプロセッサ間インタフェース(403)を備える。制御部(40)は、メモリ上に処理機能として、例えば、加入者側からのIGMPの終端処理(414)、加入者側からのMLD終端処理(415)、L2TPトンネル及びセッションをLNSと張るためのトンネル処理(413)及びセッション処理(412)、また、IPアドレスを取得する際のIPCP/IPv6CP処理(411)を実装する。
図8に、プロトコル処理部の構成図を示す。
プロトコル処理部(10−i)は、回線インタフェース(30−i)からパケットを受け取るためのインタフェース側受信バッファ(102)、プロトコル処理を実行するプロトコル処理プロセッサ(101)、内部スイッチ(20)へパケットを送信するためのSW側送信バッファ(103)、内部スイッチ(20)からパケットを受信するためのSW側受信バッファ(104)、及び、回線インタフェース(30−i)にパケットを送信するためのインタフェース側送信バッファ(105)を備える。また、プロトコル処理プロセッサ(401)と制御部(40)のプロセッサの通信に使用するプロセッサ間インタフェース(106)を有する。
また、メモリ上には、処理機能として、パケット転送制御処理(111)、L2TPカプセル化処理(112)、L2TPデカプセル化処理(113)、マルチキャスト配信におけるパケットコピー処理(114)、及び、出力ヘッダ付加処理(115)を実装する。また、各処理で使用するテーブルとして、各マルチキャストグループをどのLNSから受信するか決定するために用いるv4LNS−マルチキャスト(MC)グループ情報テーブル(121)、v6LNS−マルチキャストグループ情報テーブル(122)、デカプセルするL2TPパケットがマルチキャスト用セッションかユニキャスト用セッションかを判断するために用いるL2TPデカプセルテーブル(123)、マルチキャストパケットの転送先の回線インタフェース(30−i)を決定するためのv4マルチキャストルーティングテーブル(124)、v6マルチキャストルーティングテーブル(125)、マルチキャストパケットの出力ポートを決定し、出力ヘッダを決定するためのv4マルチキャストindexテーブル(126)、v6マルチキャストindexテーブル(127)をメモリ上に保持する。また、通常のユニキャストパケットを転送する際のv4/v6ルーティングテーブル(128/129)も備える。
なお、本明細書中、v4/v6マルチキャストルーティングテーブル124/125とv4/v6マルチキャストindexテーブル126/127を総称してv4/v6マルチキャストテーブルと呼ぶ。また、IPv4又はIPv6の一方のみをサポートする場合、他方のための各テーブルは省略してもよい。
つぎに、各テーブルについて説明する。各テーブルでは、そのテーブルを検索するための検索キーと、その検索結果として求められるデータについても付記してある。また、フラグは「0」/「1」以外、「ON」/「OFF」、又は、これらの逆の値でもよい。
図9は、LNS−マルチキャストグループ情報テーブルの構成を示す図である。
また、図10は、L2TPデカプセルテーブルの構成を示す図である。
IPv4について、図11は、v4マルチキャストルーティングテーブルの構成を示す図であり、図12は、v4マルチキャストindexテーブルの構成を示す図である。一方、IPv6について、図13は、v6マルチキャストルーティングテーブルの構成を示す図であり、図14は、v6マルチキャストindexテーブルの構成を示す図である。
なお、図12及び図14は、それぞれ、図11のデータ1243及び図13のデータ1253に示される出力1F毎にテーブル126−1〜126−n及び127−1〜127−nが設けられていることを示す。
2.動作概要
図3に、本実施の形態のネットワークにおいて、加入者がマルチキャストパケットを受信するまでの基本シーケンス図を示す。なお、以下の各シーケンスの説明では、一例としてIGMPについて説明するが、これに限らずMLD等の適宜のマルチキャストプロトコルに適用することができる。
まず、LAC(1−1)の制御端末よりLAC上のLNS-マルチキャストグループ情報テーブル(図8:121、122)にエントリを作成する(SQ1−1)。本テーブルは、各マルチキャストグループについて受信可能なLNSの情報を有し、受信可能なLNSが複数個あった場合、LACがどのLNSとマルチキャスト用のL2TPコネクションを張るか、つまり、どのLNSからマルチキャストパケットを受信するようにするか定義するテーブルである。本テーブルの詳細例は図9に示した通りである。
例えばLNS(2−1)のIP−LNS1−1に所属する加入者(NW2に接続するときに張るL2TPセッションのLNS側における終端IPアドレスがIP−LNS1−1となる加入者)がマルチキャストグループG1のパケットを受信するよう登録する場合、図9のデータ1211にIP−LNS1−1(加入者が所属するLNS)を登録し、図9のデータ1212にG1(受信したいグループアドレス)を登録する。次に本マルチキャストグループG1用のL2TPコネクションをどのLNSと張るか定義するため、図9のデータ1213にLNSのIPアドレスを登録する。例えばIP−LNS1−1との間で本マルチキャスト用のL2TPコネクションを張る場合、IP−LNS1−1をデータ1213に登録する。ここで、LNS1−1に所属する加入者に向けたマルチキャストグループG1用のL2TPコネクションは未確立であるため、図9のデータ1214は「0」であり、データ1215及び1216の値はデータ1214が0の段階では無効である。なお、L2TPコネクションが確立されると、このフラグは「1」となる。
次に、マルチキャストパケットを受信するにあたり2通りの契機がある。1つはLNS(2−1)から定期的にマルチキャストパケット受信希望者の有無を確認する場合と、加入者端末が自発的にマルチキャストパケット受信の要求を出す場合である。
LNS(2−1)から受信希望者の有無を確認する場合は、LNS(2−1)は各加入者用に既に張られているL2TPトンネル及びセッションを通して(図1:T1内のL2TPセッション)、各加入者(H11−i)に向けIGMP Queryパケットを送信する(SQ1−2、SQ1−3)。
マルチキャストグループG1のマルチキャストパケットの受信を希望する加入者は、IGMP joinメッセージを返答する(SQ1−4、SQ1−5)。加入者端末が自発的にマルチキャストパケット受信要求を出す場合は、本フェーズから始まる。
LAC(1−1)では通常加入者側からのパケットはL2TPカプセル化処理を実施しIGMP Queryが配信されたL2TPコネクションT1を通じてパケットを転送するが、本実施の形態では加入者側からのパケットがIGMP joinメッセージか否かをPK3のIP2ヘッダの内容及びデータ部分から判断し、IGMPパケットであった場合L2TPカプセル化処理を実施せず、本IGMPパケットを終端する(SQ1−4、SQ1−5)。その後、LNS−マルチキャストグループテーブルからマルチキャストグループG1用のL2TPコネクションが既に張られているか否かを判断する(図9:データ1214で判断する。SQ1−6)。
ここで、L2TPコネクションが張られていない場合、図9のデータ1213に登録されているLNSに対してマルチキャストパケット用のL2TPコネクションT3の接続処理に移る。本接続処理はL2TPプロトコルに従う(SQ1−7〜SQ1−14)。本シーケンス上で上り方向(LAC→LNS方向)のL2TPトンネルID(図9:データ1215)とセッションID(図9:データ1216)、及び、下り方向(LNS→LAC方向)のL2TPトンネルID(図10:データ1232)とセッションID(図10:データ1233)が決定され、LNS−マルチキャストグループ情報テーブルのエントリを更新、及び、L2TPデカプセルテーブルにエントリを追加する(SQ1−15)。すなわち、LNS−マルチキャストグループ情報テーブルについては、図9のデータ1214をセッション確立済みを示す「1」にし、データ1215と1216に先で決定した値を書き込む。また、L2TPデカプセルテーブルについては、図10のデータ1231にLAC側のL2TP終端を行うIPアドレスIP−LAC1−1、データ1232、1233に先で決定したトンネルID及びセッションIDを、データ1234にマルチキャスト用のL2TPコネクションであることを示す「1」を書き込む。
その後、LACはIPCP(Internet Protocol Control Protocol)でアドレス要求を行い(SQ1−16)、マルチキャスト用L2TPコネクションを介してIPv4アドレスが割り当てられる(SQ1−17)。LACでは割り当てられたIPv4アドレスをLAC内の仮想端末のアドレスとして扱う。次にLACはIGMP joinメッセージを上記で張られたマルチキャスト用L2TPセッションを通してLNSに送信する(SQ1−18)。LNSはIPCPで割り振ったIPアドレスの仮想の端末がマルチキャストグループG1に参加するものとして認識し、一方、LACではIGMP joinを送信した各加入者情報をT1を張る際に保持している加入者情報を元にマルチキャストテーブル(図8:124〜127)に登録する(SQ1−20)。マルチキャストテーブルはマルチキャストパケットをコピー配信する際のコピー先リストを管理するテーブル群である。各対応するエリアに登録する内容は、受信したIGMP joinメッセージを送信した端末に対する回線情報(出力回線インタフェース)番号、物理ポート(出力ポート)番号、回線種、PPPoEセッションID、VPI、VCI等)であり、コピー先リストはマルチキャストindexで装置内で一意に管理され、マルチキャストルーティングテーブルは装置で1つ、マルチキャストindexテーブルは回線インタフェースに括り付けられるプロトコル処理部毎(図12:126−1〜126−n、図14:127−1〜127−n)に管理される。
IGMP joinメッセージを受信したLNSはPIM join(Protocol Independent Multicast join)等によりマルチキャストパケットの配信元(マルチキャスト配信を行っているサーバまたはランデブーポイント)に返信する(SQ1−19)。
サーバよりマルチキャストパケットの配信が実施されると、マルチキャストパケットはLNSまで転送され、LNSはLNSのマルチキャストパケット配信規則に従い配信する。LNSが把握するマルチキャストパケット配信先には前述のマルチキャスト用のL2TPコネクションが登録されているため、マルチキャストパケットはマルチキャスト用L2TPコネクションT3を通してLACまで配信される(SQ1−21)。LACは本セッションで配信されたパケットがLACでコピー配信を行うマルチキャスト用のL2TPコネクションからきたものか否かをL2TPデカプセルテーブルから判断する(SQ1−22)。具体的にはPK2のL2TPヘッダ内に格納されているL2TPトンネルID及びセッションID、また、PK2のIP1ヘッダ内の宛先アドレスを検索KeyとしてL2TPデカプセルテーブル(図10:データ1231−1233でマッチするエントリを検索する)を検索し、マルチキャストセッションフラグ(図10:データ1234)にて判断する。その後、LACはマルチキャストテーブルから配信先である加入者情報を検索し(図11:出力1F、v4/v6MCindex、図12)、登録されている加入者に対しマルチキャストパケットをコピーし配信する(SQ1−23、SQ1−24)。
(配信先の追加)
図4に、配信中のマルチキャストパケットに対し、配信先を加える場合のシーケンス図を示す。
サーバからマルチキャストグループG1のマルチキャストパケットが配信され(SQ2−1、SQ2−5)、加入者C(H11−3)と加入者D(H11−n)が本マルチキャストパケットを受信している(SQ2−3、SQ2−4、SQ2−7、SQ2−8)状態にあるとする。
ここで、加入者B(H11−2)がマルチキャストグループG1に参加するため、IGMP joinメッセージを送信する(SQ2−9)。LAC(1−1)は、加入者側からのパケットがIGMP joinメッセージか否かをPK3のIP2ヘッダの内容及びデータ部分から判断し、本IGMPパケットに対してはL2TPカプセル化処理を実施せず終端する(SQ2−9)。その後、LNS−マルチキャストグループテーブルからマルチキャストグループG1用のL2TPコネクションが既に張られているか否かを判断する(図9:1214で判断する)。今回の場合は、既にマルチキャストグループG1用のL2TPコネクションが張られていると判断し、新たにL2TPコネクションを張らずに、LAC(1−1)は加入者情報を管理しているマルチキャストテーブルに加入者BをマルチキャストグループG1の配信先として追加する(SQ2−10)。その後、サーバよりマルチキャストパケットが配信されると(SQ2−11)、LACにて加入者B、C、Dに対しパケットがコピーされ配信される(SQ2−13〜SQ2−15)。さらに、加入者A(H11−1)がマルチキャストグループG1に参加する場合も、同様な手順でマルチキャストテーブルが更新され、加入者A、B、C、Dにパケットが配信される(SQ2−25〜SQ2−28)。
(配信先の削除)
図5に、配信中のマルチキャストパケットに対し、配信先を削除する場合のシーケンス図を示す。
サーバからマルチキャストグループG1のマルチキャストパケットが配信され(SQ3−1)、加入者A、B、C、D(H11−1〜H11−3、H11−n)が本マルチキャストパケットを受信している(SQ3−3〜SQ3−6)状態にあるとする。
ここで、加入者A(H11−1)がマルチキャストグループG1から脱退するため、IGMP Leaveメッセージを送信する(SQ3−7)。LAC(1−1)は、加入者側からのパケットがIGMP Leaveメッセージか否かをPK3のIP2ヘッダの内容及びデータ部分から判断し、本IGMPパケットに対してはL2TPカプセル化処理を実施せず終端する(SQ3−7)。そして、LAC(1−1)は加入者情報を管理しているマルチキャストテーブルのマルチキャストグループG1の配信先から加入者Aを削除する(SQ3−8)。その後、サーバよりマルチキャストパケットが配信されると(SQ3−9)、LACにて加入者B、C、Dに対しパケットがコピー配信される(SQ3−11〜SQ3−13)。
さらに加入者B、CがマルチキャストグループG1から脱退する場合も同様な手順でマルチキャストテーブルが更新され、加入者Dのみにパケットが配信される(SQ3−14〜SQ3−19)。ここで、マルチキャストグループG1の最後の配布先である加入者D(H11−n)が脱退希望を出すと(SQ3−20)、LAC(1−1)はマルチキャストテーブルのマルチキャストグループG1から加入者Dを削除し、マルチキャストグループG1の加入者がいないと認識する(SQ3−21)。LAC(1−1)はマルチキャストグループG1用のL2TPコネクションを解放するために、まずLAC内の仮想端末がマルチキャストグループG1から脱退することをIGMP
LeaveメッセージにてLNS(2−1)に通知する(SQ3−22)。その後、仮想端末用に取得したIPアドレスを解放し(SQ3−23、SQ3−24)、マルチキャストパケットG1用に張られたL2TPコネクションを解放する(SQ3−25〜SQ3−28)。その後L2Tデカプセルテーブルから本マルチキャスト用L2TPコネクションのエントリを削除し、LNS−マルチキャストグループテーブルの該当するエントリのマルチキャストセッション確率済みフラグ(図9:1214)を0にする(SQ3−29)。
3.詳細フローチャート
(コネクション接続処理)
図15に、本装置におけるIPv4マルチキャスト用L2TPコネクション接続処理のフローチャートを示す。本実施の形態は図3のSQ1−4〜SQ1−20におけるLAC内での処理に相当する。
まず、加入者端末からIGMP joinパケット(図3:SQ1−4)を受信したとする。本発明のパケット転送装置(1)では、回線インタフェース用受信バッファ(102)からパケット情報を読み出し、プロトコル処理プロセッサ(101)は、パケットからPPPか否か判定する(141)。PPPであった場合、加入者側からのパケットと判断しパケットの内容からIGMPか否か判定を行う(142)。IGMPの場合、IGMP joinメッセージか否か判定を行う(143)。IGMP joinの場合は、IGMPパケットに記されたマルチキャストグループアドレス(図9:1212)、及び、加入者が接続するLNSアドレス(図9:1211)でv4LNS−マルチキャストグループ情報テーブル(図9)を検索し(SQ1−6)、すでに本グループアドレス用にL2TPセッションが確立されているか否かをマルチキャストセッション確立済みフラグ(図9:1214)から判断する(144)。
セッションが確立されている場合(図9:1214が1の場合)、ステップ153に移る。
一方、セッションが確立されていない場合(図9:1214が0の場合)、v4LNS−マルチキャストグループ情報テーブルの検索結果からマルチキャスト用L2TPセッションを張る対向のLNSであるマルチキャストセッションLNSアドレス(図9:1213)を得る。その後、L2TPコネクションを張る契機としてプロトコル処理部(10−i)は、受信したIGMP joinパケットとLNSのアドレスを制御部(40)に通知する。制御部(40)ではIGMP joinパケットを終端し、L2TPプロトコルの手順に従いトンネル接続処理(145)、及び、セッション接続処理(146)を実施する(SQ1−7〜SQ1−14)。セッション確立後、制御部(40)の指示によりプロトコル処理プロセッサ(101)は、本セッション情報をv4LNS−マルチキャストグループ情報テーブルの上りL2TP Tunnel ID(図9:1215)、及び、上りL2TP Session ID(図9:1216)領域に書き込み、また、L2TPデカプセルテーブルに、マルチキャスト用L2TPコネクションを終端するLAC側のIPアドレス(図10:1231)がIP−LAC1−1で、かつ、先のL2TPコネクション接続処理で決定された下り用のL2TPコネクションを示す下りL2TP Tunnel ID(図10:1232)と下りL2TP Session ID(図10:1233)のエントリを作成し、マルチキャストセッションフラグ(図10:1234)に1を書き込む(147、SQ1−15)。
続いて、制御部(40)では仮想端末のIPアドレスを得るためにIPCP処理(148)へと移行する。IPCP処理(SQ1−16、SQ1−17)後、制御部(40)のプロセッサでIGMP joinメッセージ(149)を作成し、プロトコル処理プロセッサ(101)へ通知を行う。プロトコル処理プロセッサ(101)では、IGMP joinパケットを本マルチキャスト用セッションを使用しLNSへ送信するためのPPPカプセル化処理(150)、及び、L2TPカプセル化処理(151)を実施しパケットを送信する(152、SQ1−18)。
また、制御部(40)はv4マルチキャストテーブル(v4マルチキャストルーティングテーブル:124、v4マルチキャストindexテーブル:126)への加入者情報登録指示をプロトコル処理プロセッサ(101)に出す。プロトコル処理プロセッサ(101)は本命令に従いv4マルチキャストテーブルを更新する(153、SQ1−20)。
図17に、本装置におけるIPv6マルチキャスト用L2TPコネクション接続処理のフローチャートを示す。
IPv6の場合は前述のIPv4マルチキャスト用セッション処理と比較してIGMPのスヌーピングがMLDに置き換わり(241、242、248、251)、IPCP処理がIPv6CPに置き換わり(247)、v4マルチキャストテーブルがv6マルチキャストテーブルに(252)、v4 LNS−マルチキャストグループ情報テーブルがv6 LNS−マルチキャストグループ情報テーブルに置き換わる(243、246)のみで処理フローの内容はIPv4マルチキャスト用セッション処理と同様である。
(配信処理)
図19に、本装置における受信側のマルチキャストパケット配信処理のフローチャートを示す。
本処理は図3の、マルチキャスト用のL2TPセッションを通してサーバからマルチキャストパケットを受信し(例:SQ1−21)、マルチキャストパケットを加入者分コピーし配信する(例:SQ1−23、SQ1−24)までの本装置内における受信側処理である。
まず、入力回線(60−i)、及び、回線インタフェース(30−i)を介して、プロトコル処理部(10−i)にパケットが到達すると、プロトコル処理プロセッサ(101)は受信バッファ(102)からパケットを読み出し(181)、パケットの内容からパケットがL2TPか否か判定する(182)。L2TPの場合、L2TPデカプセルテーブル(図10)を検索しマルチキャスト用のL2TPセッションから受信したものか否か(図10:1234)判断する(188)。このときの検索Keyはマルチキャスト用のセッションを終端しているLACのアドレス(図10:1231)、L2TPトンネルID及びセッションID(図10:1232、1233)であり、これらの情報はパケットから得る。
マルチキャスト用セッションからのパケットであった場合、プロトコル処理プロセッサ(101)はL2TPデカプセル処理(184、図8:113)を行い、デカプセル後のIPヘッダのバージョンからIPv4かIPv6か判断する(185)。
IPv4の場合はマルチキャスト用L2TPセッションを張っているLNSのアドレス(図11:1241)、及び、宛先アドレスからマルチキャストグループアドレス(図11:1242)を検索Keyとしてv4マルチキャストルーティングテーブル(図11)を検索し(186、図8:111)、マルチキャストパケットを出力する回線インタフェース(図11:1243)とv4マルチキャストindex(図11:1244)を得る。
また、IPv6の場合もIPv4と同様に、LNSのアドレス及び宛先アドレスであるマルチキャストグループアドレスを検索Keyとしてv6マルチキャストルーティングテーブル(図13)を検索し(187、図8:111)、マルチキャストパケットを出力する回線インタフェース情報とv6マルチキャストindexを得る。v4/v6マルチキャストindexは、出力回線インタフェースが接続されるプロトコル処理部で出力ポート及び出力ヘッダを得るために必要となる。
出力回線インタフェースの情報を得た後、出力回線インタフェース分パケットをコピーし(188、図8:114)、内部スイッチを介し、各出力回線インタフェースに向け転送する(189)。
図20に、本装置における送信側のマルチキャストパケット配信処理のフローチャートを示す。
本処理は図3の、マルチキャスト用のL2TPセッションを通してサーバからマルチキャストパケットを受信し(例:SQ1−21)、マルチキャストパケットを加入者分コピーし配信する(例:SQ1−23、SQ1−24)までの本装置内における送信側処理である。
各出力回線インタフェースに括り付けられるプロトコル処理部(10−i)のプロトコル処理プロセッサ(101)は、スイッチ側の受信バッファ(104)からパケットを読み出した後(191)、パケットのIPバージョンからIPv4かIPv6か判断する(192)。
IPv4の場合、IPv4マルチキャストindex(図12:1261)を検索Keyにして、各回線インタフェース毎に保持するIPv4マルチキャストindexテーブル(図12)を検索する。検索結果から出力ポート情報を得る。具体的には配信先の加入者の回線種(図12:1262)、回線種がPPPoEまたはPPPoEoAの場合はPPPoEセッションID(図12:1263)、回線種がPPPoAの場合はATMのVP/VC(図12:1264/1265)を取得し、出力ポート番号(図12:1266)を得る。その後、加入者数分パケットコピーを実施し(195、114)、上記の検索結果を元に出力ヘッダ(下位レイヤのヘッダ)を付加し(196、115)、送信バッファ(105)へ書き込む(197)。ステップ195から197の動作はマルチキャストグループに所属する加入者数分繰り返される(198、114)。(例:SQ1−23、SQ1−24)
IPv6の場合もIPv4と同様で、IPv6マルチキャストindex(図14:1271)を検索Keyとして、IPv6マルチキャストindexテーブル(図14)を検索する(194)。その後の処理の説明は割愛する。
(配信先の増加)
既に加入者に対するマルチキャスト配信を実施している状態で、新たに受信希望者が増加した場合(SQ2−9)の実施の形態について、図15で説明する。
加入者端末からIGMP joinパケット(図4:SQ2−9)を受信すると、プロトコル処理部(10―i)のプロトコル処理プロセッサ(101)は、回線インタフェース用受信バッファ(102)からパケット情報を読み出し(141)、パケットからPPPか否か判定する(142)。PPPであった場合、加入者側からのパケットと判断しパケットの内容からIGMPか否か判定を行う(143)。IGMPの場合、IGMP joinメッセージか否か判定を行う(143)。IGMP joinの場合は、IGMPパケットに記されたマルチキャストグループアドレス(図9:1212)、及び、加入者が接続するLNSアドレス(図9:1211)でv4LNS−マルチキャストグループ情報テーブル(図10)を検索し、すでに本グループアドレス用にL2TPセッションが確立されているか否かをマルチキャストセッション確立済みフラグ(図9:1214)から判断する。今回は、セッションが確立されているため(図9:1214がセッションが確立している意味の1がたっている)、受信したIGMP joinパケットとマルチキャスト用セッションが既に存在することを制御部(40)に通知する。制御部(40)ではIGMP joinパケットを終端(414)し、v4マルチキャストテーブル(v4マルチキャストルーティングテーブル:124、v4マルチキャストindexテーブル:126)にIGMP joinを送信した加入者情報の追加指示をプロトコル処理プロセッサ(101)に出す。プロトコル処理プロセッサ(101)は本命令に従いv4マルチキャストテーブルを更新する(153)。
IPv6の場合は、前述の処理においてIGMPがMLDに、IPCPがIPv6CPに置き換わり、v4マルチキャストテーブルがv6マルチキャストテーブル(v6マルチキャストルーティングテーブル:125、v6マルチキャストindexテーブル:127)に置き換わることで実現する。
(脱退)
図16は、v4マルチキャスト用L2TPコネクション解放処理を示す図である。
既に加入者に対するマルチキャスト配信を実施している状態で、マルチキャストグループから加入者が脱退する場合の本装置の実施例を図15、図16で説明する(SQ3−15およびSQ3−20を例とする)。
SQ3−13のIGMP Leaveメッセージを受信した場合、図15のフローのステップ143において、IGMP joinではないと判定される。その後v4マルチキャストセッション解放処理(160)に移行し(図16)、プロトコル処理プロセッサ(101)によってIGMP Leaveか否か判定する(161)。IGMP Leaveメッセージの場合、プロトコル処理プロセッサ(101)はv4マルチキャストテーブル(v4マルチキャストルーティングテーブル:124、v4マルチキャストindexテーブル:126)から加入者Cのエントリを削除し(162)、v4マルチキャストテーブルからマルチキャストグループG1に参加している加入者の存在の有無を判定する(163)。SQ3−15の場合は、加入者Dが存在するため、削除処理を終了する。
一方、SQ3−20のIGMP Leaveメッセージを受信した場合、まず、上述と同様に、図15のフローのステップ143において、IGMP joinではないと判定される。その後v4マルチキャストセッション解放処理(160)に移行し(図16)、プロトコル処理プロセッサ(101)によってIGMP Leaveか否か判定する(161)。IGMP Leaveメッセージの場合、プロトコル処理プロセッサ(101)はv4マルチキャストテーブル(v4マルチキャストルーティングテーブル:124、v4マルチキャストindexテーブル:126)から加入者Dのエントリを削除し(162)、v4マルチキャストテーブルからマルチキャストグループG1に参加している加入者の存在の有無を判定する(163)。
ここで、SQ3−20の場合は、加入者が存在しないため、プロトコル処理プロセッサ(101)は、制御部(40)に対して受信したIGMP Leaveパケットと既に加入者が存在しないことを通知する。制御プロセッサ(401)はこれを受け、IGMP Leaveメッセージを終端し、IGMP Leaveメッセージを生成し(164)、プロトコル処理部(10)へ転送する。プロトコル処理プロセッサ(101)は、PPPカプセル化処理(165)、及び、L2TPカプセル化処理(166)を実施しパケットをLNSに対して送信する(167、SQ3−22)。次に、制御部(40)はIPCP処理を実行し仮想端末用のIPアドレスを解放し(168、SQ3−23〜SQ3−24)、L2TPセッション解放処理(169、SQ3−25〜SQ3−26)、L2TPトンネル解放処理(170、SQ3−27〜SQ3−28)を実施し、マルチキャスト用のL2TPコネクションを解放する。最後に、制御プロセッサ(401)は、解放したセッション情報をv4LNS−マルチキャストグループ情報テーブル(図9)、及び、L2Tデカプセルテーブル(図10)から削除するようプロトコル処理部(10)に通知し、プロトコル処理プロセッサ(101)は指示に従い、v4LNS−マルチキャストグループ情報テーブルとL2Tデカプセルテーブルを更新する(171)。
図18に、v6マルチキャスト用L2TPコネクション解放処理を示す。
IPv6の場合の例を図に示すが、処理の流れはIPv4と同様であるため説明は割愛する。
4.ひとつのLACに対して複数のLNSが接続されているシステム
(マルチキャスト)
図21は、1つのLACに複数ISPのLNSが接続されている場合の本装置の適用例を示す図である。
また、図22に、このときの接続シーケンスを示す。図22では既にマルチキャストグループG1のL2TPコネクションは確立されており、新たにマルチキャストグループG2用の接続を実施する場合を例としている。まず、LNS−マルチキャストグループ情報テーブルの加入者が属するLNSアドレス(図9:1211)とマルチキャスト用のL2TPコネクションをはるLNSアドレス(図9:1213)に同じアドレスを設定する(SQ4−1)。例えばISP2の場合、両方のLNSアドレスフィールド(1211、1213)にLNS2−2のアドレスが入る。また、マルチキャストグループアドレス(図9:1212)をDon’t care(D.C)にすることで、全てのマルチキャストグループに関して図9:1213に設定したLNSに対しセッションを確立しにいく設定となる。
LACは、加入者からのIGMP joinパケットをLAC(1−1)が受け取ると(SQ4−4、SQ4−5)、LNS‐マルチキャストグループ情報テーブルの情報を元にLNS2−1に対する加入者(H11−i)用のマルチキャストG2用L2TPコネクション、及び、LNS2−2に対する加入者(H12−i)用のマルチキャストG2用L2TPコネクションをそれぞれLNS2−1、LNS2−2に張りに行く(SQ4−6〜SQ4−25、SQ4−26、SQ4−28)。L2TPコネクションの接続シーケンスそのものは、図3と同様である。その後、マルチキャストテーブルに加入者H11−i及び加入者H12−iの情報を登録する。
加えて、LNS−マルチキャストグループ情報テーブルのマルチキャストグループ設定がDon’t careだった場合、セッション確立後はセッション確立したマルチキャストグループに関する情報を新たにLNS−マルチキャストグループ情報テーブルのエントリとして作成する。つまり、ISP2のLNSとマルチキャストグループG2に関するL2TPセッションが確立した場合、LNS−マルチキャストグループ情報テーブル(図9)に対し、LNSアドレス(図9:1211)にISP2のLNS(2−2)のアドレス、マルチキャストグループアドレス(1212)にマルチキャストグループアドレスG2、マルチキャストセッションLNSアドレス(1213)にLNS(2−2)のアドレス、マルチキャストセッション確立済みフラグ(1214)は確立済みを示し(例えば、フラグON)、L2TPトンネルID(1215)、セッションID(1216)にはマルチキャストG2用に確立されたL2TPコネクションの上りの各IDが入ったエントリが新たに追加される。
これにより、マルチキャストパケットが図21のように配信されることとなる。
(集約)
図23に、同一ISPに属する複数LNSのマルチキャストパケットの集約に関するシーケンス図を示す。また、図24は、マルチキャスト用L2TPセッションを集約機能を実施例を示した図であり、図25は、マルチキャスト用L2TPセッションにおける経路の負荷分散の実施例を示した図である。
加入者H11−i(i=1〜n)はLAC1−1を介してLNS2−1との間に張られたL2TPコネクションを通してインターネットNW2に接続している。また、加入者H12−i(i=1〜n)はLAC1−1を介してLNS2−2との間に張られたL2TPコネクションを通してインターネットNW2に接続している。ここで、LNS2−1とLNS2−2は同一ISPが管理する装置である。マルチキャストグループとしてG1とG2が存在し、G1はLNS2−1のみで受信可能で、G2はLNS2−1とLNS2−2の両方で受信可能とする。このとき、マルチキャストグループG1はLNS2−1を介し配信するようLNS−マルチキャストグループ情報テーブルに設定する(SQ5−1)。次に、マルチキャストG2は、基本的にLNS2−1とLNS2−2を介して2本のマルチキャスト用L2TPセッションが張られるが、LNS2−1とLNS2−2は同一ISPに属することから、1本のマルチキャスト用L2TPセッションに集約することが可能である。
そこで、LNS−MCグループ情報テーブル(図9)の設定をLNS2−2(図9:1211はLNS2−2のアドレス)のG2マルチキャストパケット(図9:1212はG2)のセッション終端先をLNS2−1(図9:1213はLNS2−1のアドレス)として登録する(SQ5−1)。なお、LNS2−1のG2マルチキャストパケットのセッション終端先はLNS2−1として登録されているものとする。このような設定登録は、例えば、操作者によりマニュアルで設定したり、適当な条件で自動的に設定することができる。
LNS2−1、LNS2−2は既に張られている加入者用のL2TPトンネル及びセッションを通して、IGMP又はMLDパケットを用いてマルチキャストグループG2への参加確認のパケットを送信する(SQ5−4、SQ5−5)。ここで、加入者H12−nとH11−1がマルチキャストグループG2に参加依頼を出したとすると(SQ5−6、SQ5−7)、LAC(1−1)はLNS−マルチキャストグループ情報テーブルを元にG2用のL2TPコネクションがLAC1−1及びLNS2−1間で張られ(SQ5−8〜SQ5−18)、加入者H11−1、及び、本来LNS2−2の加入者であるH12−nにおいてもマルチキャストルーティングテーブルにLNS2−1から受信したG2の配布先としてテーブルエントリを作成する(SQ5−19)。
この結果、加入者H12−nはG2のマルチキャストパケットをLNS2−1を介して受け取る(SQ5−22、SQ5−27)。こうして、LNS2−2に属する加入者はLNS2−1を介してG2のパケットを受信することが可能となりL2TPセッションが集約される(図24)。
また、マルチキャストグループが複数存在する場合、各々の集約したL2TPセッションの終端先としてLNSを振り分ける設定をLNS−マルチキャストグループ情報テーブルに適宜行うことで、図25のように経路の負荷分散が実現される。
(障害)
図26、図27、及び、図28に本装置を用いたLAC−LNS間におけるマルチキャスト用L2TPトンネル及びセッションの冗長機能の実施の形態を示す。
図28は、マルチキャスト用L2TPセッションの冗長機能適用時のシーケンスを示す図である。
また、図26に、回線異常発生前の状態の説明図を示す。図27は、マルチキャスト用L2TPセッション冗長機能適用後の状態を示す図である。
マルチキャストサーバS1からのマルチキャストパケットG1をLNS2−1の加入者H11−iがLNS2−1を介して受信しているとする。また、LNS2−2もマルチキャストグループG1のマルチキャストパケットを受信可能だが、LNS2−2の加入者H12−iはマルチキャストグループG1に参加していないとする。
図28のシーケンスのLNS2−1とLAC1−1間でマルチキャストパケットG1用のL2TPコネクション確立(SQ6−1)後、LAC1−1とLNS2−2の間にもマルチキャストグループG1用のL2TPトンネル及びセッションを確立することが可能であることをLNS−マルチキャストグループ情報テーブル(図9)に登録する(SQ6−2)。つまり、LNS−マルチキャストグループ情報テーブルのLNSアドレス(図9の1211)にLNS2−1を、マルチキャストグループアドレス(図9の1212)にG1を、マルチキャストセッションLNSアドレス(図9の1213)にLNS2−2のアドレス、マルチキャストセッション確立済みフラグ(図9の1214)に未確立の意味の0を登録する。
ここで、LAC1−1に何かしらの回線障害検出手段を備えることで、LAC1−1とLNS2−1の間マルチキャスト用L2TPセッションの回線に異常が発生し(SQ6−7)、L2TPコネクションが切断されたことを検出すると(SQ6−8)、LAC1−1はLNS−マルチキャストグループ情報テーブルから切断されたG1用のL2TPセッションの情報を削除する(SQ6−9)。また、LAC1−1はLNS−マルチキャストグループ情報テーブルからLNS2−1のアドレスとG1を検索KeyとしてLNS2−2がG1用のL2TPトンネル及びセッションを確立可能であると認識し、LNS2−2に対しG1用のL2TPトンネル及びセッションを張りにいく(SQ6−10〜SQ6−20)。その後の動作は前述したマルチキャストセッション処理とマルチキャストパケット配信処理と同じである。これにより二台のLNSでの冗長が完了する(図27)。
また、本例では二台のLNSを用いた冗長を示したが、LNS−マルチキャストグループテーブルにn台のLNS情報を追加し、マルチキャスト用のL2TPコネクションをはる優先度をLNS−マルチキャストグループテーブルに追加することで、二台以上のLNS構成でも冗長が可能であり、また、LNS−マルチキャストグループ情報テーブルに物理ポートの情報を追加することにより一台のLNSに対して複数物理ポートによる冗長も可能である。
本実施の形態のネットワーク構成例を示す図 本パケットフォーマットを示す図 加入者がマルチキャストパケットを受信するまでの基本シーケンス例を示す図 加入者追加に関するシーケンス例を示す図 加入者削除に関するシーケンス例を示す図 パケット転送装置の構成例を示す図 パケット転送装置の制御部を示す図 パケット転送装置のプロトコル処理部を示す図 LNS−マルチキャストグループ情報テーブルの構成を示す図 L2TPデカプセルテーブルの構成を示す図 v4マルチキャストルーティングテーブルの構成を示す図 v4マルチキャストindexテーブルの構成を示す図 v6マルチキャストルーティングテーブルの構成を示す図 v6マルチキャストindexテーブルの構成を示す図 v4マルチキャスト用L2TPコネクション接続処理を示す図 v4マルチキャスト用L2TPコネクション解放処理を示す図 v6マルチキャスト用L2TPコネクション接続処理を示す図 v6マルチキャスト用L2TPコネクション解放処理を示す図 受信側プロトコル処理部におけるマルチキャスト配信処理を示す図 送信側プロトコル処理部におけるマルチキャスト配信処理を示す図 1つのLACに複数ISPのLNSが接続されている場合の適用例を示す図 1つのLACに複数ISPのLNSが接続されている場合に加入者がマルチキャストパケットを受信するまでのシーケンス例を示す図 マルチキャスト用L2TPセッションを集約機能を実施した場合のシーケンス例を示す図 マルチキャスト用L2TPセッションを集約機能を実施の形態を示した図 マルチキャスト用L2TPセッションにおける経路の負荷分散の実施の形態を示した図 マルチキャスト用L2TPセッションの冗長機能適用前の状態を示す図 マルチキャスト用L2TPセッションの冗長機能適用後の状態を示す図 マルチキャスト用L2TPセッションの冗長機能適用時のシーケンスを示す図
符号の説明
H11−1〜H11−i:加入者端末
H12−1〜H12−i:加入者端末
1−1〜1−2:LAC
2−1〜2−2:LNS
S1〜S2:マルチキャストパケット配信サーバ
NW1:アクセスキャリアネットワーク
NW2:インターネット
T1、T2:既存のL2TPトンネル(通常のNW2へのアクセスで使用)
T3、T4:マルチキャスト用のL2TPトンネル
PK1:LNS−S1間におけるパケットフォーマット
PK2:LAC−LNS間におけるパケットフォーマット
PK3:加入者端末-LAC間におけるパケットフォーマット
1:本発明のパケット転送装置
10−1〜10−n:プロトコル処理部
20:内部スイッチ
30−1〜30−n:回線インタフェース
40:制御部
50:制御端末
60−1〜60−n:入出力回線
401:プロセッサ
402:端末インタフェース
403:プロセッサ間インタフェース
411:IPCP/IPv6CP処理
412:L2TPセッション処理
413:L2TPトンネル処理
414:IGMP終端処理
415:MLD終端処理
101:プロトコル処理プロセッサ
102:インタフェース側受信バッファ
103:スイッチ側送信バッファ
104:スイッチ側受信バッファ
105:インタフェース側送信バッファ
106:プロセッサ間インタフェース
111:パケット転送制御処理
112:L2TPカプセル化処理
113:L2TPデカプセル化処理
114:パケットコピー処理
115:出力ヘッダ付加処理
121:v4LNS−マルチキャストグループ情報テーブル
122:v6LNS−マルチキャストグループ情報テーブル
123:L2TPデカプセルテーブル
124:v4マルチキャストルーティングテーブル
125:v6マルチキャストルーティングテーブル
126:v4マルチキャストindexテーブル
127:v6マルチキャストindexテーブル
128:v4ルーティングテーブル
129:v6ルーティングテーブル
1211:LNSアドレス
1212:マルチキャストグループアドレス
1213:マルチキャスト用L2TPセッション接続先LNSアドレス
1214:マルチキャスト用L2TPセッション確立済みフラグ
1215:LAC→LNS方向L2TPトンネルID
1216:LAC→LNS方向L2TPセッションID
1231:LACアドレス
1232:LNS→LAC方向L2TPトンネルID
1233:LNS→LAC方向L2TPセッションID
1234:マルチキャスト用L2TPセッション判定フラグ
1235:出力回線情報
1241:LNSアドレス
1242:宛先アドレス
1243:出力インタフェース
1244:v4マルチキャストindex
1261:v4マルチキャストindex
1262:回線種
1263:PPPoEセッションID
1264:VP
1265:VC
1266:出力Port
1251:LNSアドレス
1252:宛先アドレス
1253:出力インタフェース
1254:v4マルチキャストindex
1271:v4マルチキャストindex
1272:回線種
1273:PPPoEセッションID
1274:VP
1275:VC
1276:出力Port

Claims (8)

  1. L2TP(Layer2 Tunneling Protocol)トンネル及びL2TPセッションが張られたネットワークにおいて、加入者側に位置しL2TPプロトコルを終端するパケット転送装置において、
    加入者端末が所属するLNS(L2TP Network Server)アドレス及びマルチキャストグループアドレスに対応して、マルチキャスト用のL2TPコネクションを張るLNSアドレス、L2TPコネクションの確立済みフラグ、上りL2TPトンネル識別子及びセッション識別子を記憶したLNS−マルチキャストグループ情報テーブルと、
    LACアドレス、下りL2TPトンネル識別子及びセッション識別子に対応して、マルチキャスト用のL2TPコネクションであることを示すマルチキャストセッションフラグを記憶したL2TPデカプセルテーブルと、
    マルチキャスト用のLNSアドレス及びマルチキャストグループアドレスに対応して、マルチキャストパケットをコピー配信する出力インタフェース情報及びポート情報を含む回線情報を記憶したマルチキャストテーブルと、
    各前記テーブルにアクセス可能で、インタフェースを介してネットワークに接続されたプロトコル処理部と、
    を備え、
    前記プロトコル処理部は、
    マルチキャストパケットの受信を希望する加入者端末から、加入者端末が所属するLNSアドレス及びマルチキャストグループアドレスを含むマルチキャストグループに参加するためのマルチキャスト受信要求メッセージのパケットを受信する手段と、
    加入者端末側からのパケットがマルチキャスト受信要求メッセージを含むか否かを、ヘッダ又はデータ部分から判断し、マルチキャスト受信要求メッセージを含む場合、L2TPカプセル化処理を実施せず、受信したパケットを終端する手段と、
    前記LNS−マルチキャストグループテーブルを参照して、受信したLNSアドレス及びマルチキャストグループアドレスに基づいて、マルチキャストグループ用のL2TPコネクションが既に張られているか否かを、L2TPコネクションの確立済みフラグから判断する手段と、
    L2TPコネクションが張られている場合、前記マルチキャストテーブルに、LNSアドレス及びマルチキャストグループアドレスに対応して、マルチキャスト受信要求メッセージを送信した加入者端末の出力インタフェース情報及びポート情報を含む回線情報を登録する手段と、
    サーバよりマルチキャストパケットを受信し、ヘッダ内のL2TPトンネル識別子及びセッション識別子、宛先アドレスに基づき、前記L2TPデカプセルテーブルを検索し、配信されたパケットがマルチキャスト用のL2TPコネクションから受信したマルチキャストパケットか否かを、マルチキャストセッションフラグにより判断する手段と、
    マルチキャスト用パケットと判断すると、L2TPデカプセル処理を行い、マルチキャスト用のL2TPコネクションを張っているLNSアドレスとマルチキャストパケットの宛先アドレスのマルチキャストグループアドレスに基づき、前記マルチキャストテーブルから配信先である加入者端末の出力インタフェース情報及びポート情報を含む回線情報を検索し、回線情報に対応する加入者端末に対しマルチキャストパケットをコピーして配信する手段と
    を有するパケット転送装置。
  2. 請求項1に記載のパケット転送装置において、
    L2TPコネクションが張られていないと判断した場合、前記LNS−マルチキャストグループ情報テーブルを参照し、受信したLNSアドレスに対して登録されている、マルチキャスト用のL2TPコネクションを張るLNSアドレスに対してマルチキャストパケット用のL2TPコネクションの接続処理を実行し、前記LNS−マルチキャストグループ情報テーブルに、上りL2TPトンネル識別子及びセッション識別子とL2TPコネクションの確立済みフラグを設定し、及び、前記L2TPデカプセルテーブルに、LACアドレスに対して下りL2TPトンネル識別子及びセッション識別子とマルチキャストセッションフラグを設定する手段と
    マルチキャスト受信要求メッセージをカプセル化処理してマルチキャスト用L2TPセッションを通してLNSに送信する手段と
    をさらに備えたパケット転送装置。
  3. 請求項1又は2に記載のパケット転送装置において、
    LNSからマルチキャストパケットの受信を希望する加入者端末の有無を確認する場合、各加入者端末用に既に張られているL2TPトンネル及びセッションを通して、LNSから各加入者端末に向けマルチキャスト受信問合せパケットを転送する手段とをさらに備えたパケット転送装置。
  4. 請求項1に記載のパケット転送装置において、
    追加加入者端末から受信したパケットがマルチキャスト受信要求メッセージを含むか否かを、ヘッダ及び/又はデータ部分から判断し、マルチキャスト受信要求メッセージを含むパケットに対してはL2TPカプセル化処理を実施せず終端する手段と、
    前記LNS−マルチキャストグループテーブルからマルチキャストグループ用のL2TPコネクションが既に張られているか否かを判断する手段と、
    既にマルチキャストグループ用のL2TPコネクションが張られていると判断したら、前記マルチキャストテーブルに追加加入者端末の回線情報を前記マルチキャストグループの配信先として追加する手段と
    を備えたパケット転送装置。
  5. 請求項1に記載のパケット転送装置において、
    削除する加入者端末から受信したパケットがマルチキャスト脱退メッセージを含むか否かをヘッダ及び/又はデータ部分から判断し、マルチキャスト脱退メッセージを含むパケットに対してはL2TPカプセル化処理を実施せず終端する手段と、
    前記マルチキャストテーブルのマルチキャストグループの配信先から前記削除する加入者端末の回線情報を削除する手段と、
    を備えたパケット転送装置。
  6. 請求項5に記載のパケット転送装置において、
    さらに、マルチキャストグループの配布先である最後の加入者からマルチキャスト脱退メッセージを受信すると前記マルチキャストテーブルのマルチキャストグループから前記最後の加入者端末の回線情報を削除し、マルチキャストグループの加入者端末がなくなったことを認識する手段と、
    マルチキャストグループから脱退することをマルチキャスト脱退メッセージにてLNSに通知する手段と、
    マルチキャストパケット用に張られたL2TPコネクションを解放する手段と、
    前記L2Tデカプセルテーブルから該当するマルチキャスト用L2TPコネクションのエントリを削除し、前記LNS−マルチキャストグループテーブルの該当するエントリのマルチキャストセッション確立済みフラグを未確立にする手段と
    を備えたパケット転送装置。
  7. 請求項1に記載のパケット転送装置において、
    前記LNS−マルチキャスト情報テーブルを、加入者が所属するLNSアドレス及びマルチキャストグループに対応する複数エントリに対して、マルチキャスト用のL2TPコネクションを張るLNSアドレスを同一アドレスと設定することで、マルチキャストパケットの転送経路を1つのLNSに集約するパケット転送装置。
  8. 請求項1に記載のパケット転送装置において、
    回線異常検出手段をさらに備え、
    前記LNS−マルチキャスト情報テーブルに、加入者が所属するLNSアドレス及びマルチキャストグループに対応して、複数のマルチキャスト用のL2TPコレクションを張るLNSアドレスを設定し、
    ひとつのL2TPコネクションに障害を検出した場合、加入者が所属するLNSアドレス及び使用していたマルチキャストグループにより前記LNS−マルチキャストグループ情報テーブルを検索し、他のマルチキャスト用のL2TPコネクションを確立することによりマルチキャストパケットを転送するパケット転送装置。
JP2004017495A 2004-01-26 2004-01-26 パケット転送装置 Expired - Fee Related JP4342966B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2004017495A JP4342966B2 (ja) 2004-01-26 2004-01-26 パケット転送装置
US10/898,430 US7388877B2 (en) 2004-01-26 2004-07-26 Packet transfer apparatus
CNB2004100589756A CN100428734C (zh) 2004-01-26 2004-07-26 数据包传送装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004017495A JP4342966B2 (ja) 2004-01-26 2004-01-26 パケット転送装置

Publications (2)

Publication Number Publication Date
JP2005210631A JP2005210631A (ja) 2005-08-04
JP4342966B2 true JP4342966B2 (ja) 2009-10-14

Family

ID=34792510

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004017495A Expired - Fee Related JP4342966B2 (ja) 2004-01-26 2004-01-26 パケット転送装置

Country Status (3)

Country Link
US (1) US7388877B2 (ja)
JP (1) JP4342966B2 (ja)
CN (1) CN100428734C (ja)

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4529144B2 (ja) * 2004-08-11 2010-08-25 日本電気株式会社 仮想lanシステムおよびノード装置
JP2006074132A (ja) * 2004-08-31 2006-03-16 Matsushita Electric Ind Co Ltd マルチキャスト通信方法及びゲートウェイ装置
JP4401942B2 (ja) * 2004-12-08 2010-01-20 株式会社日立コミュニケーションテクノロジー パケット転送装置および通信ネットワーク
WO2006099540A2 (en) 2005-03-15 2006-09-21 Trapeze Networks, Inc. System and method for distributing keys in a wireless network
WO2007044986A2 (en) 2005-10-13 2007-04-19 Trapeze Networks, Inc. System and method for remote monitoring in a wireless network
US7573859B2 (en) 2005-10-13 2009-08-11 Trapeze Networks, Inc. System and method for remote monitoring in a wireless network
US7724703B2 (en) 2005-10-13 2010-05-25 Belden, Inc. System and method for wireless network monitoring
US8638762B2 (en) 2005-10-13 2014-01-28 Trapeze Networks, Inc. System and method for network integrity
US7936702B2 (en) * 2005-12-01 2011-05-03 Cisco Technology, Inc. Interdomain bi-directional protocol independent multicast
CN100420220C (zh) * 2006-01-09 2008-09-17 华为技术有限公司 二层隧道协议网络服务器及其隧道建立方法
KR100656487B1 (ko) * 2006-01-17 2006-12-11 삼성전자주식회사 Ip 디지털 방송 시스템에서의 igmp 네트워크 장비 및그 신호 처리 제어방법
US7558266B2 (en) 2006-05-03 2009-07-07 Trapeze Networks, Inc. System and method for restricting network access using forwarding databases
US8966018B2 (en) 2006-05-19 2015-02-24 Trapeze Networks, Inc. Automated network device configuration and network deployment
US9191799B2 (en) 2006-06-09 2015-11-17 Juniper Networks, Inc. Sharing data between wireless switches system and method
US9258702B2 (en) 2006-06-09 2016-02-09 Trapeze Networks, Inc. AP-local dynamic switching
US8818322B2 (en) 2006-06-09 2014-08-26 Trapeze Networks, Inc. Untethered access point mesh system and method
US8340110B2 (en) 2006-09-15 2012-12-25 Trapeze Networks, Inc. Quality of service provisioning for wireless networks
US8023446B2 (en) * 2006-09-28 2011-09-20 Hang Zhang Systems and methods for facilitating intra-cell-peer-to-peer communication
KR100837704B1 (ko) * 2006-09-29 2008-06-13 한국전자통신연구원 진화된 umts 망 시스템에서의 데이터 전송 방법
JP4680866B2 (ja) * 2006-10-31 2011-05-11 株式会社日立製作所 ゲートウェイ負荷分散機能を備えたパケット転送装置
US7873061B2 (en) 2006-12-28 2011-01-18 Trapeze Networks, Inc. System and method for aggregation and queuing in a wireless network
US8166205B2 (en) * 2007-07-31 2012-04-24 Cisco Technology, Inc. Overlay transport virtualization
US8902904B2 (en) 2007-09-07 2014-12-02 Trapeze Networks, Inc. Network assignment based on priority
US20090109859A1 (en) * 2007-10-31 2009-04-30 At&T Knowledge Ventures, Lp Method and System for Detecting a Fault Condition Based on Failed IGMP Join Attempts
US7962161B1 (en) * 2007-11-21 2011-06-14 L-3 Communications Corp. Method and apparatus for FDD and TDD terminal entry into a wireless communication network
US8238942B2 (en) 2007-11-21 2012-08-07 Trapeze Networks, Inc. Wireless station location detection
US8150357B2 (en) 2008-03-28 2012-04-03 Trapeze Networks, Inc. Smoothing filter for irregular update intervals
CN101272403B (zh) * 2008-05-27 2011-02-09 华为技术有限公司 实现dhcp用户业务批发的方法、系统和设备
CN101304387B (zh) * 2008-06-18 2010-09-01 中兴通讯股份有限公司 一种实现二层隧道协议隧道转换的方法
US8978105B2 (en) 2008-07-25 2015-03-10 Trapeze Networks, Inc. Affirming network relationships and resource access via related networks
US8238298B2 (en) 2008-08-29 2012-08-07 Trapeze Networks, Inc. Picking an optimal channel for an access point in a wireless network
KR101358838B1 (ko) 2008-11-17 2014-02-10 퀄컴 인코포레이티드 로컬 네트워크에 대한 원격 액세스
EP2364535A2 (en) * 2008-11-17 2011-09-14 QUALCOMM Incorporated Remote access to local network via security gateway
US20100157870A1 (en) * 2008-12-19 2010-06-24 Qualcomm Incorporated Managing a multicast group membership table at an access network within a wireless communications system
US8488491B2 (en) * 2009-11-12 2013-07-16 Cisco Technology, Inc. Compressed virtual routing and forwarding in a communications network
CN102130818B (zh) * 2010-01-20 2014-03-19 杭州华三通信技术有限公司 一种接入网络接入服务器的方法和网络接入服务器
US8694664B2 (en) 2010-11-23 2014-04-08 Cisco Technology, Inc. Active-active multi-homing support for overlay transport protocol
CN102377671B (zh) * 2011-11-02 2014-10-29 中国联合网络通信集团有限公司 负载均衡方法及系统、宽带远程接入服务器设备
US9100302B2 (en) 2012-01-13 2015-08-04 Nomura Holdings, Inc. Methods and systems for monitoring multicast availability
US8953618B2 (en) * 2012-10-10 2015-02-10 Telefonaktiebolaget L M Ericsson (Publ) IP multicast service leave process for MPLS-based virtual private cloud networking
CN103841627B (zh) * 2012-11-22 2017-12-12 中国电信股份有限公司 通过虚拟私有拨号网络使用运营商业务的方法与系统
JP5894546B2 (ja) * 2013-02-05 2016-03-30 日本電信電話株式会社 マルチキャスト通信システム、及びマルチキャスト通信方法
US9548887B2 (en) 2013-08-09 2017-01-17 Cisco Technology, Inc. Proactive creation of multicast state in an overlay transport network to achieve fast convergence on failover
FR3011414A1 (fr) * 2013-10-01 2015-04-03 Orange Procede d'abonnement a des flux en provenance de clients multicast
CN106664258A (zh) * 2014-08-29 2017-05-10 柏思科技有限公司 通过聚合连接传输数据包的方法和系统
US9762545B2 (en) 2014-11-03 2017-09-12 Cisco Technology, Inc. Proxy forwarding of local traffic by edge devices in a multi-homed overlay virtual private network
US9680664B2 (en) 2015-09-28 2017-06-13 Juniper Networks, Inc. Using a multicast address as a tunnel remote gateway address in a layer 2 tunneling protocol access concentrator
US11012418B2 (en) 2018-02-15 2021-05-18 Forcepoint Llc Multi-access interface for internet protocol security
CN112769581A (zh) * 2020-12-30 2021-05-07 网神信息技术(北京)股份有限公司 数据组播方法、装置、电子设备、介质和程序产品
JP2023131231A (ja) * 2022-03-09 2023-09-22 日本電気株式会社 通信システム、通信装置、通信方法及び通信プログラム

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6157649A (en) * 1995-11-17 2000-12-05 3 Com Corporation Method and system for coordination and control of data streams that terminate at different termination units using virtual tunneling
US6463475B1 (en) * 1997-09-26 2002-10-08 3Com Corporation Method and device for tunnel switching
US6094437A (en) * 1998-10-09 2000-07-25 Asc - Advanced Switching Communications Layer two tunneling protocol (L2TP) merging and management
US6970459B1 (en) * 1999-05-13 2005-11-29 Intermec Ip Corp. Mobile virtual network system and method
US6654792B1 (en) * 2000-02-28 2003-11-25 3Com Corporation Method and architecture for logical aggregation of multiple servers
JP3855595B2 (ja) * 2000-04-25 2006-12-13 株式会社日立製作所 通信システム、通信方法及び通信装置
JP2002164930A (ja) * 2000-11-29 2002-06-07 Nippon Telegr & Teleph Corp <Ntt> 通信方法
US7461157B2 (en) * 2001-06-27 2008-12-02 Hyglo Systems Ab Distributed server functionality for emulated LAN
US6996110B1 (en) * 2001-08-31 2006-02-07 3Com Corporation Distributed MPLS architecture
CN1194508C (zh) * 2002-05-15 2005-03-23 华为技术有限公司 一种基于二层交换设备的组播报文转发方法

Also Published As

Publication number Publication date
US20050163146A1 (en) 2005-07-28
JP2005210631A (ja) 2005-08-04
CN100428734C (zh) 2008-10-22
US7388877B2 (en) 2008-06-17
CN1649325A (zh) 2005-08-03

Similar Documents

Publication Publication Date Title
JP4342966B2 (ja) パケット転送装置
JP4516397B2 (ja) レイヤ2スイッチ
US9166807B2 (en) Transmission of layer two (L2) multicast traffic over multi-protocol label switching networks
JP4728511B2 (ja) データ中継方法、その装置およびその装置を用いたデータ中継システム
JP3142433B2 (ja) ブリッジ装置及びブリッジ接続方法
CN104052666B (zh) 实现主机路由可达的方法和装置
CN1992676B (zh) 在通信网络中多个业务路径之间共享转发状态的方法和设备
US20080075078A1 (en) Frame Transfer System
CN102316030B (zh) 一种实现数据中心二层互联的方法和装置
US9100198B2 (en) Network provider bridge MMRP registration snooping
WO2006095508A1 (ja) フラッディング抑制方法
JP2009094832A (ja) マルチキャストデータ配信装置、その配信方法およびその配信制御プログラム
JP4436960B2 (ja) パケット通信システムおよび移動通信システム
JP2000125277A (ja) マルチキャスト通信装置及びマルチキャスト通信方法
CN103975556A (zh) 远程多播复制网络的改进复制管理
US20090225660A1 (en) Communication device and operation management method
CN108964940A (zh) 消息发送方法及装置、存储介质
US6580722B1 (en) Bypassing topological restrictions with tunnels
WO2022117018A1 (zh) 报文传输的方法和装置
US7715391B1 (en) System and method for optimal delivery of multicast content
WO2021077991A1 (zh) 报文检测方法、连通性协商关系建立方法以及相关设备
Cisco Configuring the Catalyst 8500 Software
JP5224418B2 (ja) データ中継方法、その装置およびその装置を用いたデータ中継システム
JP2006129359A (ja) マルチキャスト回線の確立方法、その方法を用いた通信システム、通信装置、通信装置の制御方法、およびプログラム
WO2024016869A1 (zh) 一种组播配置方法及装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20061002

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20081218

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090113

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090313

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

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

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

Free format text: PAYMENT UNTIL: 20120717

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

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

Free format text: PAYMENT UNTIL: 20120717

Year of fee payment: 3

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

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

Free format text: PAYMENT UNTIL: 20130717

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees