JP3955064B2 - リング型ネットワークでのマルチキャスト通信における帯域有効利用方法 - Google Patents
リング型ネットワークでのマルチキャスト通信における帯域有効利用方法 Download PDFInfo
- Publication number
- JP3955064B2 JP3955064B2 JP2004566267A JP2004566267A JP3955064B2 JP 3955064 B2 JP3955064 B2 JP 3955064B2 JP 2004566267 A JP2004566267 A JP 2004566267A JP 2004566267 A JP2004566267 A JP 2004566267A JP 3955064 B2 JP3955064 B2 JP 3955064B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- node
- transmission
- receiving
- entry information
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/42—Loop networks
Description
SONETリング用光ファイバリング型ネットワークにおけるプロトコルの一つとしてRPR(Resilient Packet Ring)がある。RPRは、リング型のIPパケット用L2(レイヤ2)ネットワークプロトコルとして、現在IEEE802.17で標準化されようとしている。
RPRの主な特徴としては、使用していない経路を他の通信に使用することでネットワーク帯域の有効利用を図る、いわゆる空間再利用ができることが挙げられる。また、RPRの他の特徴としては、双方向二重逆リング方式を用いることでリング型ネットワークの信頼性が高くなるため、障害が発生したときの復旧が迅速に行えること、等が挙げられる。
このRPR方式の特徴の一つである空間再利用とは、送信者と受信者が1:1のユニキャスト通信において、その受信者の受信元ノードで送信したパケットを取り込み、その先のノードにパケットを転送しないことを指す。空間再利用をすることで、RPRでは、受信元ノードにおける先のノードのネットワーク帯域が空く(空間になる)。即ち、リング型ネットワーク上の情報の伝達方向において、受信ノードより先のノードには、上記パケットは転送されない。従って、受信ノードより先のノードは、上記パケット以外の他のパケットの送受信が可能である。よって、このリング型ネットワークでは、ネットワーク帯域の有効利用が可能となる。
その結果、同じリング型ネットワークであるFDDIやトークンリング等のトークンを掴んで一周させる方式と違い、RPRでは、リング型ネットワーク使用率が95%と非常に高くなることが報告されている。
しかし、RPRにおけるマルチキャスト通信では、すべてのRPRノードにマルチキャストパケットを流すため、空間再利用をしない規定がされている。また、この規定は、RPRのベースとなった複数の先行ベンダーの独自方式でも同様である。
即ち、RPRの方式を用いてマルチキャスト通信する際、RPRはL2ネットワークであるため、マルチキャストパケットを含むブロードキャストフレームが全てのRPRノードに流れることになる。即ち、上記RPRにおける空間再利用は、マルチキャストにおいて有効に活用されているとは言い難かった。従って、ユニキャスト通信における、リング型ネットワークの一般的なネットワーク帯域の使用率95%に相当するネットワーク帯域の利用率をマルチキャスト通信において実現することは容易ではなかった。
ところで、ブロードキャストフレームによる帯域利用率の低下を最小限に抑える技術として以下の技術が知られている。この技術では、インターフェースモジュールとしてスイッチングハブを用いる。スイッチングハブには、フィルタリングデータベースにより中継ポートを決定する、ARPサーバモジュールを設ける。そして、このスイッチングハブは、上記インターフェースモジュールが受信したブロードキャストフレームを全て上記ARPサーバモジュールに渡し、このARPサーバモジュールがこのフレームの送信元MACアドレスと送信元ネットワークアドレスとを学習して登録する。また、ARPサーバモジュールは、そのネットワークアドレスに対応しているエントリが存在している場合には、ARP応答フレームを組み立てて受信ポートから応答する(例えば、特許文献1参照)。
また、送受信帯域の節約、マシン、スイッチ上のVC(仮想チャンネル)管理メモリの節約、マルチキャスト接続時間の短縮化を可能とするATMネットワークにおけるマルチキャストに関する技術も知られている。この技術では、非受信フラグと非送信フラグとを使用してクラスタメンバ、マルチキャストサーバが条件動作を行い、必要なバーチャル・チャンネルが設定される(例えば、特許文献2参照)。
しかしながら、上記の特許文献1及び特許文献2の技術では、リング型ネットワークにおけるIPマルチキャスト通信に対する配慮はなかった。
本発明は上記した課題を解決するために、以下の手段を採用した。
即ち、本発明は、情報伝達の方向性を有するリング型ネットワークでのマルチキャスト通信における帯域有効利用方法である。前記リング型ネットワークにおいて、マルチキャストで通信する送信ホスト及び受信ノードは、マルチキャスト通信に係るノードを示す、エントリ情報を共有する。また、この送信ノード及び受信ノードは、前記エントリ情報をリング型ネットワーク上でブロードキャストし、前記リング型ネットワーク上の位置関係に係る、トポロジ情報を各ノード間で共有する。また、前記送信ノードは、前記エントリ情報及び前記トポロジ情報を参照して、マルチキャスト送信する情報の送信方向を決定し、情報を当該送信方向にマルチキャスト送信する。さらに、前記受信ノードは、当該送信方向に前記情報を受信する他の受信ノードが存在しない場合に、前記情報を廃棄する。
マルチキャスト通信では、あるパケット送信に関して、1箇所の送信ノードと複数の受信ノードが存在する。そこで、おのおののノードに対し、同じ情報を保持することが必要である。
そこで本発明では、エントリ情報を定義し、これをすべてのリング型ネットワークのノードで保持する。また、本発明は、ノードの位置情報を格納したトポロジ情報を設けて、このトポロジ情報とエントリ情報とを組み合わせる。
従って、本発明によれば、マルチキャスト通信において、ユニキャスト通信のように送信ノードが受信ノードを認識することが可能となる。
なお、トポロジ情報には、リング型ネットワークのノード間の位置関係、例えばノードの配置順が格納される。この位置関係は、例えばノードのMAC(Media Access Control)アドレスによって認識される。
また、本発明は、前記エントリ情報には、前記送信ノードのアドレス及び前記受信ノードのアドレスが含まれてもよい。
前記エントリ情報に、送信ノードのアドレス及び受信ノードのアドレスが含まれることで、本発明によれば、エントリ情報を参照して個々のノードが互いのノードを送信ノード及び受信ノードとして認識することができる。
また、本発明は、前記トポロジ情報には、前記送信方向及び受信ノードのアドレスが含まれてもよい。
前記トポロジ情報に、前記送信方向及び受信ノードのアドレスが含まれることで、本発明によれば、個々のノードが互いのノードの位置関係を認識することができる。
また、本発明は、前記送信ノードが、当該送信ノードの配下にある送信ホストから、前記情報を受信する。この送信ノードは、前記情報に基づいて前記エントリ情報を生成する。
送信ノードが送信ホストからの情報に基づいてエントリ情報を生成し、このエントリ情報をリング型ネットワークで送信することで、本発明によれば、受信ノードがその情報(マルチキャストパケット)の送信先を知ることができる。
また、本発明は、前記受信ノードが、当該受信ノードの配下にある受信ホストから、前記情報の受信を要求する受信要求情報を受信する。この受信ノードは、前記受信要求情報に応じて受信要求コマンドを生成し、前記受信要求コマンドを前記送信ノードに送信する。
受信ノードが受信ホストから受信要求情報を受信し、この受信要求情報に応じて受信要求コマンドを生成することで、本発明によれば、個々のノードにおいて、他のノードが受信するか否かを認識できるため、リング型ネットワークでのマルチキャスト通信における帯域有効利用が可能となる。
また、本発明は、前記送信ノードが、前記受信要求コマンドに応じて、前記エントリ情報を更新する。この送信ノードは、更新した前記エントリ情報を送信する。
送信ノードが、受信要求コマンドに応じてエントリ情報を更新することで、本発明によれば、情報を受信する受信ノード数が変化してもこの送信ノードがその変化に対応することが容易になり、受信を要求するノードに効率的にマルチキャスト送信することが可能となる。
また、本発明は、前記受信ノードが、前記受信ホストから前記情報の受信停止を要求する離脱要求情報を受信する。この受信ノードは、前記離脱要求情報に応じて他の受信ホストが存在するか否かを検出し、受信ホストが存在しない場合に、削除要求コマンドを生成する。また、この受信ノードは、前記削除要求コマンドを前記送信ノードに送信する。
受信ノードが離脱要求情報に応じて受信ホストが存在するか否かを検出し、受信ホストが存在しない場合に削除要求コマンドを生成することで、本発明によれば、受信ノードがマルチキャストパケットの受信の有無を知ることができるので、リング型ネットワークでのマルチキャスト通信における帯域有効利用が可能となる。
また、本発明は、前記送信ノードが、前記削除要求コマンドに応じて、前記エントリ情報を更新する。この送信ノードは、更新した前記エントリ情報を送信する。
削除要求コマンドに応じて、送信ノードがエントリ情報を更新することで、本発明によれば、個々のノードが他の受信ノードの数を知ることができ、リング型ネットワークでのマルチキャスト通信における帯域有効利用が可能となる。
また、本発明は、前記送信ノードが、前記送信ホストから前記情報の送信が終了したことを検出する。この送信ノードは、前記情報の送信が終了したことを受信ノードに通知する送信終了コマンドを生成する。また、この送信ノードは、前記送信終了コマンドを受信ノードに送信し、前記送信が終了したことに応じて、前記エントリ情報を削除する。
送信ノードが送信終了コマンドを生成し、エントリ情報を削除することで、本発明によれば、個々のノードが互いのノードの状況を知ることができ、リング型ネットワークでのマルチキャスト通信における帯域有効利用が可能となる。
また、本発明は、以上の何れかの機能を実現させるプログラムであってもよい。また、本発明は、そのようなプログラムをコンピュータが読み取り可能な記憶媒体に記録してもよい。
また、本発明は、以上の何れかの機能を実現させる送信ノード及び受信ノードを含むリング型ネットワークにおけるシステムであってもよい。
FIG.2は、本実施の形態に係る、データ送受信時における主な手順を示すフローチャートであり、
FIG.3は、本実施の形態に係る、RPRのデータパケットのフォーマット及びマルチキャストエントリテーブルのフォーマットであり、
FIG.4は、本実施の形態で各ノードの位置関係を把握するために用いる、トポロジテーブルであり、
FIG.5は、本実施の形態に係る制御コマンドの構造であり、
FIG.6は、本実施の形態に係る制御レスポンスの構造であり、
FIG.7は、本実施の形態に係るRPRノードが送信をする際の処理の流れであり、
FIG.8は、本実施の形態に係る、リング型ネットワークにおける受信ノードの処理の様子を示す図であり、
FIG.9は、本発明を実施するリング型ネットワークにおける送信ノードN1とマルチキャストエントリテーブルの流れを示す図であり、
FIG.10は、本実施の形態における、送信ノードの状態遷移図であり、
FIG.11は、本実施の形態における、受信ノードの状態遷移図であり、
FIG.12は、本実施の形態における送信ノードの処理を示すフローチャートであり、
FIG.13は、本実施の形態における受信ノードの処理を示すフローチャートであり、
FIG.14は、本実施の形態における空間再利用の処理を示すフローチャートであり、
FIG.15は、本発明の一実施例に係る、従来のマルチキャストパケット送信方式と本発明におけるマルチキャストパケットの流れの相違を示す図であり、
FIG.16は、本実施例に係るマルチキャストエントリテーブルの一例であり、
FIG.17は、本実施例に係る、受信要求コマンドの一例であり、
FIG.18は、本実施例に係る、受信レスポンスの一例であり、
FIG.19は、本実施例に係る、受信を要求する受信ノードMACアドレスを追加したマルチキャストエントリテーブルの一例であり、
FIG.20は、本実施例に係る、各ノードの処理を示す図である。
以下、本発明の一実施の形態に係る、リング型ネットワークにおけるマルチキャスト送信時の帯域有効利用方法をFIG.1からFIG.20の図面に基づいて説明する。
《動作原理》
本実施の形態における、リング型ネットワークの基本的な概念を、FIG.1に示す。なお、本実施の形態において、本発明のリング型ネットワークとしてRPRを用いて、本発明の適用例を説明する。
本発明で使用するRPRネットワークは、光二重リング型ネットワークである。このRPRネットワークには、ノードが接続している。また、このRPRネットワークは、0系及び1系の2つのリングから構成されている。このRPRの特徴は、リング型ネットワーク上の送信ノード及び受信ノードの位置関係に応じて、伝送距離が最も短いリング(最短ルート)でデータを送信することである。このため、RPRは、0系乃至1系の何れのリングを介してデータを送信するか否かを選択できる。その際、この送信ノードは、後述する本発明のエントリ情報であるマルチキャストエントリテーブルと、同じく後述する本発明のトポロジ情報であるトポロジテーブルとによって、受信ノードの位置を知る。従って、このリング型ネットワークでは、回線利用率の高いネットワークを実現できる。
本実施の形態における送信ノードは、本発明に係る以下の手段を有する。本実施の形態に係る送信ノードは、マルチキャスト通信に係るノードを示す、エントリ情報を生成するエントリ情報生成手段を有する。また、本実施の形態に係る送信ノードは、前記エントリ情報を共有するエントリ情報共有手段をゆうする。また、本実施の形態に係る送信ノードは、前記リング型ネットワーク上の位置関係に係る、トポロジ情報を各ノード間で共有するトポロジ情報共有手段を有する。また、本実施の形態に係る送信ノードは、前記エントリ情報をリング型ネットワーク上でブロードキャストするエントリ情報送信手段を有する。また、本実施の形態に係る送信ノードは、前記エントリ情報及び前記トポロジ情報を参照して、マルチキャスト送信する情報の送信方向を決定する送信方向決定手段を有する。さらに、本実施の形態に係る送信ノードは、当該情報を当該送信方向にマルチキャスト送信する情報送信手段を有する。
また、本実施の形態における受信ノードは、本発明に係る以下の手段を有する。本実施の形態に係る受信ノードは、マルチキャスト通信に係るノードを示す、エントリ情報を受信するエントリ情報受信手段を有する。また、本実施の形態に係る受信ノードは、前記エントリ情報を共有するエントリ情報共有手段を有する。また、本実施の形態に係る受信ノードは、前記リング型ネットワーク上の位置関係に係る、トポロジ情報を各ノード間で共有するトポロジ情報共有手段を有する。また、本実施の形態に係る受信ノードは、マルチキャスト送信される情報の送信方向を参照する送信方向参照手段を有する。また、本実施の形態に係る受信ノードは、当該情報を当該送信方向に送信する送信手段を有する。さらに、本実施の形態に係る受信ノードは、当該送信方向に当該情報を受信する受信ノードが存在しない場合に、前記情報を廃棄する情報破棄手段を有する。
次に、本実施の形態におけるデータ送受信時における主な手順を、FIG.2に示す。
本実施の形態のデータ送受信手順には、送信ノードが送信時に行う送信宣言(FIG.2におけるステップ1、以下S1のように省略する)、受信ノードによる受信要求及びパケット削除要求(S2)、リング型ネットワークにおけるマルチキャストエントリテーブルの更新(S3)、並びに受信ノードによる処理がある(S4)。
上述の各手順について説明する。送信宣言について説明する。まず、RPRに接続するノードの配下のネットワークにマルチキャストパケット(本発明における情報)を送信する送信ホストがある。この配下に送信ホストを有するノードを送信ノードとする。送信宣言とは、マルチキャストパケットを送信するこの送信ノードが、他のノードにその旨を通知する処理である。受信要求とは、マルチキャストパケットを受信する受信ホストを配下のネットワークに有するノード(受信ノード)が、送信ノードにこのパケット受信を要求する処理である。パケット削除要求とは、受信ノードの配下のネットワークがこのパケットの受信を停止するときに行う処理である。マルチキャストエントリテーブルの更新処理とは、上述のパケット受信要求及び削除要求に応じて、送信ノードがマルチキャストエントリテーブルを更新する処理である。受信側の処理とは、受信ノードにおける、送信されたマルチキャストパケットに対する処理である。
《本実施の形態におけるマルチキャストエントリテーブル構造》
本実施の形態における、RPRのデータパケットのフォーマット及びマルチキャストエントリテーブルのフォーマットは、FIG.3に示す通りである。このRPRデータパケットのフォーマットを符号10で示し、マルチキャストエントリテーブルのフォーマットを符号20で示す。
RPRデータパケット10には、そのパケット10のネットワーク内におけるパケットの生存時間を示すTTL(Time To Live)(8bit)、RI(リング識別子)(1bit)、Mode(パケットタイプを選別)(3bit)、Pri(優先度:パケットの優先度を示す)(3bit)、P(パリティビット:MACヘッダの15ビットについての奇数パリティ)(1bit)、DA(宛先MACアドレス)(48bit)、SA(送信元MACアドレス)(48bit)、Protocol Type(用いるプロトコルのタイプを示す。また、0X2007はSRP(Special Reuse Protocol)制御を示す)(16bit)、Pay Load(実データを転送する情報フィールド)、FCS(フレームチェックシーケンス)(16bit)が含まれている。このうち、Pay Loadに、本実施の形態のマルチキャストエントリテーブル20が収容される。
マルチキャストエントリテーブル20とは、リング型ネットワークにおけるマルチキャストパケット(情報)を受信するマルチキャストグループに参加する送信ノード及び受信ノードの情報を含むテーブルである。即ち、マルチキャストエントリテーブル20とは、マルチキャスト通信に係るノードを示すテーブルである。
マルチキャストエントリテーブル20には、マルチキャストアドレス(マルチキャスト通信を行うために指定したアドレス)(32bit)、送信ノードのMACアドレス(個々のノードを識別するためのアドレス)(48bit)、並びに受信ノードのMACアドレスが含まれる。ただし、受信ノードのMACアドレスは、受信するノードの数だけ追加される。なお、受信ノードMACアドレスは、受信ノードの数に応じてbit数(格納できるMACアドレスの数)が増えていくので可変長になっている。
このマルチキャストエントリテーブル20において、マルチキャストアドレスと送信ノードのMACアドレスとを基本構造とし、受信ノードのMACアドレスを拡張構造とする。受信ノードのMACアドレスを拡張構造と称するのは、受信ノードの数に応じてこのMACアドレスの数が変化するためである。なお、マルチキャストアドレスは最初の4bitが(1110)となっている。
このように、本実施の形態のマルチキャストエントリテーブル20によれば、各ノードが互いのノードが送信ホスト及び受信ノードであるか否かの情報を保持し共有できる。このため、本実施の形態では、リング型ネットワークでのマルチキャスト通信における帯域有効利用が可能となる。
《本実施の形態のトポロジテーブル》
次に、本実施の形態で各ノードの位置関係を把握するために用いる、トポロジテーブルについて説明する。各ノードはトポロジテーブルをそれぞれ有する。このトポロジテーブルにより、RPRトポロジ検出の結果の格納を行う。ここで、RPRトポロジとは、RPRにおける各ノードの位置情報である。なお、トポロジテーブルとは、RPRネットワークにおいて、トポロジ検出パケットを送信し、リング上の各ノードが、定期的にトポロー検出パケットを送信し、リンク上のノードのMACアドレスとリングステータス情報で作成したものである。このトポロジテーブルにより、本実施の形態では、個々のノードが、リング0系1系の各ノードの位置関係を知ることができる。このトポロジテーブルはFIG.4のようになる。FIG.4は、本発明のトポロジテーブルの一例を示す図であり、トポロジテーブルを符号30で示す。
トポロジテーブル30には、そのテーブル30のネットワーク内におけるパケットの生存時間を示すTTL(Time To Live)(8bit)、RI(リング識別子)(1bit)、Mode(パケットタイプを選別)(3bit)、Pri(優先度:パケットの優先度を示す)(3bit)、P(パリティビット:MACヘッダの15ビットについての奇数パリティ)(1bit)、DA(宛先MACアドレス)(48bit)、SA(送信元MACアドレス)(48bit)、Protocol Type(用いるプロトコルのタイプを示す。また、0X2007はSRP制御を示す)(16bit)、Control Type(制御コマンドのタイプを示す。0X00は送信終了コマンドであり、0X01は受信要求コマンドである。)(8bit)、受信ノードのMACアドレス、MACアドレスのタイプ(8bit)、FCS(フレームチェックシーケンス)(16bit)が含まれている。
本実施の形態では、このようなトポロジテーブル30を作成することにより、他のノードで個々のノードに関する共通の位置情報を保持する。従って、本実施の形態によれば、送信ノードは、すべてのノードの位置関係を把握することができる。なお、FIG.4において、受信ノードのMACアドレスの配列は、ネットワーク上の配置と一致しているが、この配列は本発明において必ずしも一致しなくともよい。
《制御コマンド構造》
次に、本実施の形態における、制御コマンドの構造について説明する。
この制御コマンドは、送信ノードが送信を終了した場合、受信ノードが送信ノードに受信要求を出す場合、並びに受信ノードが送信ノードに削除要求を出す場合の場合に分けて用いられる。制御コマンドの構造を、この制御コマンドの一例である送信終了コマンドに基づいて説明する。FIG.5は、送信終了コマンドの一例であり、符号40を付す。
制御コマンド40には、そのコマンド40のネットワーク内におけるパケットの生存時間を示すTTL(Time To Live)(8bit)、RI(リング識別子)(1bit)、Mode(パケットタイプを選別)(3bit)、Pri(優先度:パケットの優先度を示す)(3bit)、P(パリティビット:MACヘッダの15ビットについての奇数パリティ)(1bit)、DA(送信乃至受信ノードのMACアドレス)(48bit)、SA(DAに対応する受信乃至送信ノードのMACアドレス)(48bit)、Protocol Type(用いるプロトコルのタイプを示す。また、0X2007はSRP制御を示す)(16bit)、Pay Load(実データを転送する情報フィールド)、FCS(フレームチェックシーケンス)(16bit)が含まれている。このうち、Pay Loadに、本リング型ネットワークの独自の設定である、制御パターン情報(8bit)及び送信元マルチキャストアドレス(32bit)が収容される。
本実施の形態において、制御パターンは、以下のように定義する。
(1)0X00:送信終了コマンド(送信ノードがマルチキャストパケットの送信を終了した場合に、受信ノードに対して送信されるコマンドである)
(2)0X01:受信要求コマンド(マルチキャストパケットを受信要求する受信ノードから送信ノードにユニキャスト送信されるコマンドである)
(3)0X02:削除要求コマンド(受信ノードが送信ノードにマルチキャストグループから離脱する要求として削除要求を出す場合に、送信されるコマンドである)
それぞれの制御コマンドに対応した処理を他のノードに要求するノードは、この制御コマンド40のパケットをブロードキャスト通信で他のノードに送信する。
この制御コマンドが届いたことを示すために、制御コマンドを受信したノードは、送信ノードに対して制御レスポンスを返す。FIG.6の符号50は、制御レスポンスの構造を示す。
制御レスポンス50には、そのレスポンス50のネットワーク内におけるパケットの生存時間を示すTTL(Time To Live)(8bit)、RI(リング識別子)(1bit)、Mode(パケットタイプを選別)(3bit)、Pri(優先度:パケットの優先度を示す)(3bit)、P(パリティビット:MACヘッダの15ビットについての奇数パリティ)(1bit)、DA’(SAのMACアドレス)(48bit)、SA’(DAのMACアドレス)(48bit)、Protocol Type(用いるプロトコルのタイプを示す。また、0X2007はSRP制御を示す)(16bit)、Pay Load(実データを転送する情報フィールド)、FCS(フレームチェックシーケンス)(16bit)が含まれている。このうち、Pay Loadに、本実施の形態の独自の設定である、制御パターン情報(8bit)及び送信元マルチキャストアドレス(32bit)が収容される。
本実施の形態において、制御レスポンス50の制御パターンは以下のように定義する。
(4)0X10:送信終了レスポンス(受信ノードが、送信終了コマンドを受けたことを送信ノードに通知するための応答である)
(5)0X11:受信要求レスポンス(送信ノードが、受信要求コマンドを受けたことを受信ノードに通知するための応答である)
(6)0X12:削除要求レスポンス(送信ノードが、削除要求コマンドを受けたことを受信ノードに通知するための応答である)
《送信宣言》
RPRノードが送信をする際の処理の流れをFIG.7に示す。なお、本実施の形態において、用いるルーティングプロトコルはPIM−SM(Protocol Independent Multicast Sparse Mode)とするが、本実施の形態ではこれに限定されることなく、他の代表的な複数プロトコルでも本発明を適用可能である。
FIG.7において、送信ノードN1の配下にあるL3(レイヤー3)のサブネットワーク1内にある図示しない本発明の送信ホストは、送信ノードN1にマルチキャストパケットを送信する。
送信されたマルチキャストパケットは、L3スイッチ2を経由してL2(レイヤー2)である送信ノードN1が受信する。
送信ノードN1はsnoopingを用い、配下のL3ネットワークからのマルチキャストアドレスを認識する(FIG.7における(1))。なお、snoopingとは、上位レイヤからの情報を覗き見してL2ネットワークでも認識可能とする技術であり、本実施の形態では、マルチキャストパケット、PIM−Join(加入要求)パケット、Prune(離脱要求情報)パケットをsnoopingする。
そして、送信ノードN1は、マルチキャストアドレスとRPRノードのMACアドレス、及びリング方向情報を用いて、後述するマルチキャストエントリテーブルを作成する(2)。
送信ノードN1は、ブロードキャスト通信により、ネットワークに接続する全てのノードに、作成したマルチキャストエントリテーブルを送信する(3)。これをマルチキャストエントリテーブルの送信という。マルチキャストエントリテーブルを受信したノードは、このマルチキャストエントリテーブルを保持する。
以上の(1)から(3)に示した手順によって、本実施の形態は、ネットワークに接続する全てのノードで、送信ノードN1のMACアドレスを認識することができる。従って、本実施の形態によれば、受信ノードに最初に送られてくるマルチキャストエントリテーブルにより、受信要求コマンドや削除要求コマンドなどの送付先(マルチキャストパケットの発信ノード)を知ることができる。
《受信要求》
FIG.8に、本実施の形態に係る、リング型ネットワークにおける受信ノードの処理の様子を示す。なお、本実施の形態では、受信ノードN3の配下にあるL3サブネットワーク5が受信要求を出したものとする。
まず、受信ノードN3の配下のサブネットワーク5にある図示しない本実施の形態の受信ホストがマルチキャストパケットを受信する為に、IGMP HMQ(Internet Group Management Protocol Host Membership Query)をネットワーク上で送信すると、L3スイッチ3は、隣接するL3スイッチ4に対してPIM−Joinを送信する(FIG.8における(1))。なお、このPIM−Joinとは、送信ホストがマルチキャストグループに参加することを送信ノードに宣言するときに送信する受信要求情報である。
次に、受信ノードN3は、snoopingによってL3スイッチ3からのPIM−Joinを認識する(2)。受信ノードN3は、図示しない送信ノードで作成されたマルチキャストエントリテーブルに基づき、受信要求コマンドを作成する(3)。受信ノードN3は、受信ノードN3自身のMACアドレスを含む受信要求コマンドを送信ノードN1にユニキャストで通知する。受信要求コマンドを受けた送信ノードは、マルチキャストエントリテーブルを更新する。
サブネットワーク5は、受信ノードN3によって、送信ノードN1からのマルチキャストパケットを、L3スイッチ3を介して受信する(4)。
なお、RPRノードN4では、L3配下のサブネットワーク6からのマルチキャストパケットの受信要求がない。即ち、RPRノードN4には配下に受信ホストがない。このとき、RPRノードN4は、送信ノードN1には受信要求コマンドを通知しない。また、RPRノードN4は、マルチキャストエントリテーブル更新のパケットを受信する。一方、RPRノードN4は、マルチキャストパケットを受信せず、次ノードに転送する(スルーさせる)。
従って、上記の手順により、本実施の形態は、受信しないノードがマルチキャストパケットをスルーさせることで不要なパケットがネットワークを流れることがないため、帯域有効利用が可能が可能となる。
《削除要求》
また、マルチキャストパケットの受信時に、受信ノードN3が配下のサブネットワークに対して、IGMP HMQを出しても配下のサブネットワークからの応答がない場合がある。即ち受信ホストが消滅した場合である。このとき、L3スイッチ3は、受信ノードにPrune(離脱要求情報)信号を出す。このPrune信号を受信ノードN3がsnoopingで検出する。そして、受信ノードN3は、図示しない送信ノードに対する削除要求コマンドを作成する。受信ノードN3は、自身のMACアドレスを送信ノードにユニキャストで通知する。削除要求コマンドを受けた送信ノードは、マルチキャストエントリテーブルを削除する。送信ノードは、更新したマルチキャストエントリテーブルを削除した情報を受信ノードN3にブロードキャストする。更新したマルチキャストエントリテーブルを受信した受信ノードは、マルチキャストグループから離脱する。
《マルチキャストエントリテーブルの更新》
次に、本実施の形態における、マルチキャストエントリテーブルの更新について、FIG.9に基づいて説明する。FIG.9には、本実施の形態のリング型ネットワークにおける送信ノードN1とマルチキャストエントリテーブルの流れが示されている。
本実施の形態において、受信ノードがデータを受信するときには、以下のような手順で行われる。
まず、受信要求コマンドをこの受信ノードから送信ノードN1に通知する(FIG.9における(1))。受信要求コマンドを受け取った送信ノードN1は、マルチキャストエントリテーブルを更新する(2)。そして、送信ノードN1は、各ノードに対して、更新したマルチキャストエントリテーブルをブロードキャストする(3)。
また、本発明において、受信ノードがデータの受信を停止するときには、以下のような手順で行われる。
まず、削除要求コマンドを受信ノードから送信ノードN1に通知する(FIG.9における(5))。送信ノードN1は、削除要求コマンドを受けて、マルチキャストエントリテーブルを更新する(2)。送信ノードN1は、各ノードに対して、更新したマルチキャストエントリテーブルをブロードキャストする(3)。各ノードは、受信したマルチキャストエントリテーブルを保持する(4)。
《データ送信》
送信ノードN1がマルチキャストエントリテーブルを更新し、リング型ネットワークの各ノードにマルチキャストエントリテーブルがブロードキャストされた状態で、送信ノードN1は、画像等のマルチキャストパケット情報をマルチキャスト送信で送信する。
受信ノードは、FIG.9の(4)にて保持したマルチキャストエントリテーブルに基づき、受信したマルチキャストパケット情報を次のノードに転送するか、或いは破棄するか否かを決定する。
《受信ノードの処理》
本実施の形態では、マルチキャストエントリテーブル及びトポロジ検出を組み合わせて、必要なノードのみにマルチキャスト通信を実現する。
そのために、各ノードが保持するトポロジ検出により作成したトポロジマップ及びマルチキャストエントリテーブルにより、各ノードが自ノードより先にデータ受信要求ノードがなければ、そのデータを取り込んだ上で破棄する。また、トポロジマップ及びマルチキャストエントリテーブルにより、自ノードより先にデータ受信要求ノードがあれば、そのデータを取り込んだ上で次のノードに送信することができる。
受信ノードの処理の具体的なステップは、以下に示す。
まず、受信ノードは、マルチキャストエントリテーブルが流れてきたリングを識別する。即ち、受信ノードは、このリングが0系であるか1系であるか否かを検出する。
次に、受信ノードは、検出したマルチキャストエントリテーブルとトポロジを基に、次ノード以降に情報を要求するノードが存在するか否かを確認する。
受信ノードは、このノードに情報を取り入れた後、この情報を要求するノードが次ノード以降に存在する場合には、受信ノードがネットワーク上の次ノードにこの情報を転送する。また、この情報を要求するノードが存在しない場合には、この情報が不要なトラフィックデータとなるため、この情報を破棄する。
《送信ノード、受信ノードの状態遷移》
次に、本実施の形態における、送信ノードの状態遷移をFIG.10に示す。また、本実施の形態における、受信ノードの状態遷移をFIG.11に示す。
(1)送信ノードの状態遷移
送信ノードの状態遷移について、FIG.10に示す状態遷移図に基づいて説明する。
FIG.10において、送信ノードにマルチキャストエントリテーブルがない場合を状態1とし、またマルチキャストエントリテーブルがある場合を状態2とする。
状態1のとき、送信ノードは、配下のネットワークからマルチキャストグループへの参加要求があった場合には、マルチキャストエントリテーブルを作成し、このマルチキャストエントリテーブルを他のノードに配信する。このとき、送信ノードは、状態1から状態2へと遷移する(FIG.10における1−1)。
状態2のとき、送信ノードは、配下のネットワークからマルチキャストグループへの参加要求があった場合には、(1−1)の状態を維持する(2−1)。
送信ノードは、他のノードから情報の受信要求があった場合には、マルチキャストエントリテーブルに受信を要求するノードのMACアドレスを追加し、このマルチキャストエントリテーブルを各ノードにブロードキャスト配信する(2−2)。
他のノードから情報の削除要求があった場合には、送信ノードは、マルチキャストエントリテーブルから削除を要求するノードのMACアドレスを削除し、このマルチキャストエントリテーブルを各ノードにブロードキャスト配信する(2−3)。
配下のネットワークより、マルチキャストグループからの離脱要求があった場合には、送信ノードは、保持しているマルチキャストエントリテーブルを削除し、各ノードに送信終了コマンドを送信する(2−4)。
(2)受信ノードの状態遷移
受信ノードの状態遷移について、FIG.11に示す状態遷移表に基づいて説明する。
FIG.11において、受信ノードにマルチキャストエントリテーブルがある場合を状態3とし、マルチキャストエントリテーブルがない場合を状態4とする。
状態3のとき、受信ノードは、配下のネットワークからマルチキャストグループへの参加要求を示すPIM−Joinがあった場合には、送信ノードに受信要求コマンドを送信する。(FIG.11における3−1)。これにより、マルチキャストエントリテーブルにこの受信ノードのMACアドレスが追加され、ブロードキャストされる。
配下のネットワークからPrune信号を認識した場合、受信ノードは、送信ノードに受信ノードのMACアドレスの削除要求を送信する(3−2)。
送信ノードから送信終了コマンドを受信した場合、受信ノードは、保持しているマルチキャストエントリテーブルを削除し、状態3から状態4へと遷移する(3−3)。
状態4のとき、受信ノードは、配下のネットワークからマルチキャストグループへの参加要求を示すPIM−Joinがあった場合には、マルチキャストエントリテーブルがなく送信ノードが不明のため、処理を待機する(4−1)。
配下のネットワークからPrune信号を認識した場合、受信ノードは、マルチキャストエントリテーブルがなく送信ノードが不明のため、処理を待機する(4−2)。
《処理フローチャート》
次に、本実施の形態における送信ノード、受信ノード、空間再利用の処理について、フローチャートを用いて説明する。
まず、本実施の形態における送信ノードの処理を、FIG.12のフローチャートを用いて説明する。
送信ノードは、各ノードの位置関係を把握するためにトポロジテーブルを検出する(FIG.12におけるステップ101,以下S101のように省略する)。
送信ノードは、配下のネットワークからマルチキャストアドレスが検出可能か否かを判定する(S102)。このとき、送信ノードは、マルチキャストアドレスを検出できればステップ103以降の処理を継続する。また、送信ノードは、マルチキャストアドレスを検出できなければ本処理を終了する。これにより、リング型ネットワークは、マルチキャスト以外の通常の送信処理を実行する。
マルチキャストアドレスを検出できた場合、送信ノードは、マルチキャストエントリテーブルをリング型ネットワークに送信する(S103)。
送信ノードは、受信を要求する受信ノードがあるか否かを検出する(S104)。このとき、送信ノードは、受信ノードがある場合はステップ105の処理を行い、受信ノードがない場合にはステップ106の処理を行う。
受信ノードがある場合に送信ノードは、マルチキャストエントリテーブルに受信ノードのMACアドレスを追加する更新を行い、各ノードに送信する(S105)。この場合、送信ノードは、マルチキャストエントリテーブルをブロードキャストすればよい。
次に、送信ノードは、受信要求を削除する要求があるか否かを検出する(S106)。このとき、削除要求がある場合には、送信ノードは削除要求コマンドを反映したマルチキャストエントリテーブルを更新して、各ノードに送信する(S107)。この場合も、送信ノードは、マルチキャストエントリテーブルをブロードキャストすればよい。また、削除要求がない場合には、ステップ108の処理に移行する。
送信ノードは、配下のネットワークからのマルチキャストパケットによる情報の送信が終了したか否かを検出する(S108)。このとき、マルチキャストパケットの送信が終了した場合に送信ノードは、受信ノードに送信終了コマンドをブロードキャストする(S109)。送信終了コマンド送信後、送信ノードは、マルチキャストエントリテーブルを更新して各ノードに送信して(S110)、本処理を終了する。また、マルチキャストパケットの送信が終了していない場合に送信ノードは、ステップ104の処理に戻る。
次に、本実施の形態における受信ノードの処理について、FIG.13のフローチャートを用いて説明する。
まず、受信ノードは、各ノードの位置関係を把握するためにトポロジテーブルを検出する(FIG.13におけるステップ201,以下S201のように省略する)。
受信ノードは、送信ノードからマルチキャストエントリテーブルを受信し(S202)、このマルチキャストエントリテーブルを保持する(S203)。
次に、受信ノードは、配下のネットワークからPIM−Joinがあるか否かを検出する(S204)。このとき、PIM−Joinがある場合に受信ノードはステップ205の処理を行う。また、PIM−Joinがない場合に受信ノードは本処理を終了する。これにより、リング型ネットワークは、マルチキャスト以外の通常の送信処理を実行する。
受信ノード配下のネットワークにある受信ホストからPIM−Joinがあった場合に、この受信ノードは、保持しているマルチキャストエントリテーブルの受信ホストの数を1つ加算する(S205)。
受信ノードは、送信ノードに受信要求コマンドをユニキャスト送信する(S206)。送信後、受信ノードは、マルチキャストエントリテーブルを保持する(S207)。
受信要求コマンド送信後、受信ノードは、配下のネットワークの受信ホストからPrune信号があるか否かを検出する(S208)。このとき、受信ノードは、Prune信号を受信していない場合にはステップ204の処理に戻り、Prune信号を受信した場合にはステップ209の処理を行う。
受信ノードは、マルチキャストエントリテーブルの受信ホストの数を1つ減算する(S209)。
受信ノードは、受信ホストの数が0であるか否か、即ち情報を受信するノードがあるか否かを検出する(S210)。このとき、受信ホストの数が0である場合、受信ノードは、送信ノードに削除要求コマンドを送信する(S211)。また、受信ホストの数が0でない場合、受信ノードは、送信ノードから送信終了コマンド(宣言)があるか否かを検出する(S212)。
受信ノードは、ステップ211及びステップ212の処理が完了すると、受信ノードは本処理を終了する。
次に、本実施の形態における空間再利用の処理を、FIG.14に示すフローチャートを用いて説明する。
まず、受信ノードは、情報が格納されたマルチキャストパケットを受信する(FIG.14におけるステップ301、以下S301のように省略する)。このとき、受信ノードは、受信したマルチキャストパケットが送信されてきたリング方向を0系乃至1系の何れであるか否かを認識する(S302)。リング方向が1系である場合に受信ノードは、ステップ303の処理を行い、リング方向が0系である場合にはステップ307の処理を行う。
リング方向が1系である場合、受信ノードは、リング方向1系のトポロジテーブルを選択する(S303)。リング方向の選択は、FIG.4のトポロジテーブル30において、リング方向を示すRIを参照して選択される。ただし、このリング型ネットワークは、単一のトポロジテーブルを使用してもよい。この場合、RIに基づいて、リング方向を設定すればよい。
リング方向の選択後、受信ノードは、先のノードが情報を受信するか否かを判定する(S304)。このとき、先のノードが情報を受信しない場合には、受信ノードがこの情報を破棄する(S305)。また、先のノードが情報を受信する場合には、受信ノードがこの情報を次のノードに転送する(S306)。ステップ305及びステップ306の処理が完了すると、受信ノードは本処理を終了する。
リング方向が0系である場合、受信ノードは、リング方向0系のトポロジテーブルを選択する(S307)。リング方向の選択は、FIG.4のトポロジテーブル30において、リング方向を示すRIを参照して選択される。
リング方向の選択後、受信ノードは、先のノードが情報を受信するか否かを判定する(S308)。このとき、先のノードが情報を受信しない場合には、受信ノードがこの情報を破棄する(S309)。また、先のノードが情報を受信する場合には、受信ノードがこの情報を次のノードに転送する(S310)。ステップ309及びステップ310の処理が完了すると、受信ノードは本処理を終了する。
FIG.15は、従来のマルチキャストパケット送信方式と本発明におけるマルチキャストパケットの流れの相違を示す。なお、本実施例では、ノードN1が送信ノード、ノードN2,N5が受信ノードとする。送信ホストAから送信されたマルチキャストパケット(情報)は、送信ノードN1を介して受信ノードN2,N5が受信する。
従来の方式では、マルチキャスト通信をRPRリング型ネットワーク上で行うとマルチキャストパケットが必ずすべてのノードにわたってしまう。しかしながら、本発明によれば、受信要求しているノードのみにマルチキャストパケットが流れる。
本実施例において、送信ノードおよび各受信ノードは、FIG.4に示したトポロジテーブル30によって、各ノードの位置関係を把握する。
送信ノードN1が配下ネットワークからのマルチキャストアドレスをsnoopingにより認識すると、送信ノードN1は、FIG.16に示すマルチキャストエントリテーブルを作成する。
FIG.16のマルチキャストエントリテーブルには、送信ノード配下の送信ホストのマルチキャストアドレスと、送信ノードN1のMACアドレスが格納されている。
送信ノードN1は、この作成したマルチキャストエントリテーブルをすべてのノードにブロードキャストする。
このマルチキャストエントリテーブルを受信した各受信ノードは、マルチキャストエントリテーブルを保持する。
また、snoopingにより配下のネットワークからのPIM−Joinの有無を確認する。このとき、仮にPIM−Joinがある場合に受信ノードは、マルチキャストエントリテーブル内に記載されている送信ノードN1に対し、FIG.17に示す受信要求コマンドを作成する。
FIG.17の受信要求コマンドには、そのコマンドのネットワーク内におけるDA(送信ノードN1のMACアドレス)、SA(受信ノードのMACアドレス))、Protocol Type(用いるプロトコルのタイプを示す。また、0X2007はSRP制御を示す)(16bit)、Pay Load(実データを転送する情報フィールド)には、制御パターン0X01の受信要求コマンド(マルチキャストパケットを受信要求する受信ノードから送信ノードにユニキャスト送信されるコマンドである)が含まれている。また、Pay Loadには、受信ノードのMACアドレスが格納されている。
そして、受信ノードは、送信ノードN1に受信要求コマンドをユニキャストで送信する。
上記の受信要求コマンドを受信した送信ノードN1は、この受信要求コマンドに対する受信レスポンスをそれぞれの受信を要求する受信ノードにユニキャスト送信する。FIG.18に、この受信レスポンスの一例を示す。
FIG.18の受信レスポンスには、そのレスポンスのネットワーク内におけるDA(受信ノードのMACアドレス)、SA(送信ノードのMACアドレス))、Protocol Type(用いるプロトコルのタイプを示す。また、0X2007はSRP制御を示す)(16bit)、Pay Load(実データを転送する情報フィールド)には、制御パターン0X11の受信要求レスポンス(送信ノードが、受信要求コマンドを受けたことを受信ノードに通知するための応答である)が含まれている。また、Pay Loadには、受信ノードのMACアドレスが格納されている。
さらに、受信ノードは、FIG.16のマルチキャストエントリテーブルに受信を要求する受信ノードMACアドレスを追加し、このマルチキャストエントリテーブルをマルチキャスト通信ですべてのノードに送信する。他のノードはこのマルチキャストエントリテーブルを保持する。FIG.19は、受信を要求する受信ノードMACアドレスを追加したマルチキャストエントリテーブルの一例である。
FIG.19のマルチキャストエントリテーブルには、FIG.16のマルチキャストエントリテーブルと比較して、マルチキャストパケットを受信する受信ノードのMACアドレスが追加されている。
トポロジ検出が完了した後、それぞれのノードがマルチキャストエントリテーブルを受け取った際の制御は、FIG.20の各ノードの処理表に示すとおりである。
FIG.20において、ケース1(自ノードの先のノードが受信要求を出している場合)に該当するノードは、本実施例では受信ノードN2及び情報を受信しない(空送り)RPRノードN3,N4である。また、ケース2(次ノードの先のノードが受信要求を出していない場合)は、本実施例では受信ノードN5である。このFIG.20によれば、トポロジテーブルによって、リング方向から各ノードの位置関係を認識し、またマルチキャストエントリテーブルによって受信ノードを知ることができるので、各ノードは上の表より破棄するか、或いは転送するか否かを判断する。
この受信ノードN5がケース2の処理を行うことにより、本発明は、受信ノードN5以降のノードにマルチキャストパケットが送信されることがなくなり、リング型ネットワークの帯域の有効利用、即ち空間再利用を行うことができる。
《その他の実施の形態》
また、本実施の形態において、本発明のマルチキャストネットワークにおけるRPRの帯域有効利用方法、プログラム、装置は、本実施の形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
例えば、送信ノード配下の送信ホストが送信をやめる際の処理として、以下のような方法が考えられる。
まず、一つの方法は、送信RPRノードが常に送信ホストを監視し(一定時間に1回送信ホストへQueryを発信)、送信ホストからの応答がなくなった時点で送信ノードが送信を取りやめたと判断する、と言う方法である。
また、他の方法としては、以下の方法も考えられる。マルチキャストエントリテーブルに時間制限のヘッダを追加(例えば8ビット)し、送信ノードで保持する。保持したエントリテーブルは、所定の時間が経過後、時間制限ヘッダの中の値が減少するように設定する。時間制限ヘッダの値が0になる前に、新たなマルチキャストパケットが到達した場合は、時間制限ヘッダの値は初期値に戻る。また、仮に時間制限ヘッダの値が0になってしまったら、送信ホストは無くなったものと判断する。
また、本実施の形態において、用いるルーティングプロトコルはPIM−SM(Protocol Independent Multicast Sparse Mode)とするが、本実施の形態ではこれに限定されることなく、他の代表的な複数プロトコルでも本発明を適用可能である。
また、本実施の形態は、以上の何れかの機能を実現させるプログラムであってもよい。また、本実施の形態は、そのようなプログラムをコンピュータが読み取り可能な記憶媒体に記録してもよい。
また、本実施の形態は、以上の何れかの機能を実現させる送信ノード及び受信ノードを含むリング型ネットワークにおけるシステムであってもよい。
Claims (29)
- 情報伝達の方向性を有するリング型ネットワークでのマルチキャスト通信における帯域有効利用方法であり、
前記リング型ネットワークにおいて、マルチキャストで通信する送信ノード及び受信ノードが、
マルチキャスト通信に係るノードを示す、エントリ情報を共有するエントリ情報共有ステップと、
前記エントリ情報をリング型ネットワーク上でブロードキャストするステップと、
前記リング型ネットワーク上の位置関係に係る、トポロジ情報を各ノード間で共有するステップとを実行し、
前記送信ノードが、
前記エントリ情報及び前記トポロジ情報を参照して、マルチキャスト送信する情報の送信方向を決定するステップと、
情報を当該送信方向にマルチキャスト送信するステップとを実行し、
前記受信ノードが、
当該送信方向に前記情報を受信する他の受信ノードが存在しない場合に、前記情報を廃棄するステップとを実行する、リング型ネットワークでのマルチキャスト通信における帯域有効利用方法。 - 前記エントリ情報には、
前記送信ノードのアドレス及び前記受信ノードのアドレスが含まれる、請求の範囲1に記載のリング型ネットワークでのマルチキャスト通信における帯域有効利用方法。 - 前記トポロジ情報には、
前記送信方向及び受信ノードのアドレスが含まれる、請求の範囲1または2に記載のリング型ネットワークでのマルチキャスト通信における帯域有効利用方法。 - 前記送信ノードが、
前記エントリ情報共有ステップでは、当該送信ノードの配下にある送信ホストから、前記情報を受信し、
前記情報に基づいて前記エントリ情報を生成する、請求の範囲3に記載のリング型ネットワークでのマルチキャスト通信における帯域有効利用方法。 - 前記受信ノードが、
前記エントリ情報共有ステップでは、当該受信ノードの配下にある受信ホストから、前記情報の受信を要求する受信要求情報を受信し、
前記受信要求情報に応じて受信要求コマンドを生成し、
前記受信要求コマンドを前記送信ノードに送信する、請求の範囲4に記載のリング型ネットワークでのマルチキャスト通信における帯域有効利用方法。 - 前記送信ノードが、
前記エントリ情報共有ステップでは、前記受信要求コマンドに応じて、前記エントリ情報を更新し、
前記エントリ情報をブロードキャストするステップでは、更新した前記エントリ情報を送信する、請求の範囲5に記載のリング型ネットワークでのマルチキャスト通信における帯域有効利用方法。 - 前記受信ノードが、
エントリ情報共有ステップでは、
前記受信ホストから前記情報の受信停止を要求する離脱要求情報を受信し、
前記離脱要求情報に応じて他の受信ホストが存在するか否かを検出し、
受信ホストが存在しない場合に、削除要求コマンドを生成し、
前記削除要求コマンドを前記送信ノードに送信する、請求の範囲6に記載のリング型ネットワークでのマルチキャスト通信における帯域有効利用方法。 - 前記送信ノードが、
前記エントリ情報共有ステップでは、前記削除要求コマンドに応じて、前記エントリ情報を更新し、
前記エントリ情報をブロードキャストするステップでは、更新した前記エントリ情報を送信する、請求の範囲7に記載のリング型ネットワークでのマルチキャスト通信における帯域有効利用方法。 - 前記送信ノードが、
エントリ情報共有ステップでは、前記送信ホストから前記情報の送信が終了したことを検出し、
前記情報の送信が終了したことを受信ノードに通知する送信終了コマンドを生成し、
前記送信終了コマンドを受信ノードに送信し、
前記送信が終了したことに応じて、前記エントリ情報を削除する、請求の範囲8に記載のリング型ネットワークでのマルチキャスト通信における帯域有効利用方法。 - 情報伝達の方向性を有するリング型ネットワークでマルチキャスト通信するノードに帯域有効利用をさせるプログラムであり、
マルチキャスト通信に係るノードを示す、エントリ情報を生成するエントリ情報生成ステップと、
前記エントリ情報を共有するエントリ情報共有ステップと、
前記リング型ネットワーク上の位置関係に係る、トポロジ情報を各ノード間で共有するトポロジ情報共有ステップと、
前記エントリ情報をリング型ネットワーク上でブロードキャストするステップと、
前記エントリ情報及び前記トポロジ情報を参照して、マルチキャスト送信する情報の送信方向を決定するステップと、
情報を当該送信方向にマルチキャスト送信するステップとを備え、
前記情報を受信する受信ノードに対して、
当該送信方向に当該情報を受信する他の受信ノードが存在しない場合に、前記情報を廃棄させる、プログラム。 - 前記エントリ情報には、
前記送信ノードのアドレス及び前記受信ノードのアドレスが含まれる、請求の範囲10に記載のプログラム。 - 前記トポロジ情報には、
前記送信方向及び受信ノードのアドレスが含まれる、請求の範囲10または11に記載のプログラム。 - 前記エントリ情報生成ステップでは、当該ノードの配下にある送信ホストから、前記情報を受信し、
前記情報に基づいて前記エントリ情報を生成する、請求の範囲12に記載のプログラム。 - 前記エントリ情報生成ステップでは、前記情報の受信を要求する受信ノードからの受信要求コマンドを受信し、
前記受信要求コマンドに応じて、前記エントリ情報を更新する、請求の範囲13に記載のプログラム。 - 前記エントリ情報生成ステップでは、マルチキャスト通信からの離脱を要求する受信ノードからの削除要求コマンドを受信し、
前記削除要求コマンドに応じて、前記エントリ情報を更新し、
前記エントリ情報をブロードキャストするステップでは、更新したエントリ情報を送信する、請求の範囲14に記載のプログラム。 - 前記エントリ情報生成ステップでは、前記送信ホストから前記情報の送信が終了したことを検出し、
前記情報の送信が終了したことを受信ノードに通知する送信終了コマンドを生成し、
前記送信終了コマンドを受信ノードに送信し、
前記送信が終了したことに応じて、前記エントリ情報を削除する、請求の範囲15に記載のプログラム。 - 情報伝達の方向性を有するリング型ネットワークでマルチキャスト通信するノードに帯域有効利用させるプログラムであり、
マルチキャスト通信に係るノードを示す、エントリ情報を受信するステップと、
前記エントリ情報を共有するエントリ情報共有ステップと、
前記リング型ネットワーク上の位置関係に係る、トポロジ情報を各ノード間で共有するトポロジ情報共有ステップと、
マルチキャスト送信される情報の送信方向を参照するステップと、
前記送信方向を判定するステップと、
当該送信方向に当該情報を受信する他の受信ノードが存在する場合に、当該情報を当該送信方向に転送するステップと、
当該送信方向に当該情報を受信する他の受信ノードが存在しない場合に、前記情報を廃棄するステップとを備える、プログラム。 - 前記エントリ情報共有ステップでは、当該ノードの配下にある受信ホストから、前記情報の受信を要求する受信要求情報を受信し、
前記受信要求情報に応じて受信要求コマンドを生成し、
前記受信要求コマンドを前記送信ノードに送信し、請求の範囲17に記載のプログラム。 - 前記エントリ情報共有ステップでは、前記受信ホストから前記情報の受信停止を要求する離脱要求情報を受信し、
前記離脱要求情報に応じて受信ホストが存在するか否かを検出し、
受信ホストが存在しない場合に、削除要求コマンドを生成し、
前記削除要求コマンドを前記送信ノードに送信する、請求の範囲18に記載のプログラム。 - 情報伝達の方向性を有するリング型ネットワークでマルチキャスト通信を実行する送信ノードであり、
マルチキャスト通信に係るノードを示す、エントリ情報を生成するエントリ情報生成手段と、
前記エントリ情報を共有するエントリ情報共有手段と、
前記リング型ネットワーク上の位置関係に係る、トポロジ情報を各ノード間で共有するトポロジ情報共有手段と、
前記エントリ情報をリング型ネットワーク上でブロードキャストするエントリ情報送信手段と、
前記エントリ情報及び前記トポロジ情報を参照して、マルチキャスト送信する情報の送信方向を決定する送信方向決定手段と、
当該情報を当該送信方向にマルチキャスト送信する情報送信手段とを有し、
前記情報を受信する受信ノードに対して、
当該送信方向に当該情報を受信する受信ノードが存在しない場合に、前記情報を廃棄させる、リング型ネットワークでのマルチキャスト通信における送信ノード。 - 前記エントリ情報には、
前記送信ノードのアドレス及び前記受信ノードのアドレスが含まれる、請求の範囲20に記載のリング型ネットワークでのマルチキャスト通信における送信ノード。 - 前記トポロジ情報には、
前記送信方向及び受信ノードのアドレスが含まれる、請求の範囲20または21に記載のリング型ネットワークでのマルチキャスト通信における送信ノード。 - 前記エントリ情報生成手段が、当該送信ノードの配下にある送信ホストから、前記情報を受信し、
前記情報に基づいて前記エントリ情報を生成する、請求の範囲22に記載のリング型ネットワークでのマルチキャスト通信における送信ノード。 - 前記エントリ情報生成手段が、情報の受信を要求する受信ノードからの受信要求コマンドに応じて、前記エントリ情報を更新する、請求の範囲22に記載のリング型ネットワークでのマルチキャスト通信における送信ノード。
- 前記エントリ情報生成手段が、マルチキャスト通信からの離脱を要求する受信ノードからの削除要求コマンドに応じて前記エントリ情報を更新する、請求の範囲24に記載のリング型ネットワークでのマルチキャスト通信における送信ノード。
- 前記エントリ情報生成手段が、前記送信ホストから前記情報の送信が終了したことを検出し、
前記情報の送信が終了したことを受信ノードに通知する送信終了コマンドを生成し、
前記送信が終了したことに応じて、前記エントリ情報を削除する、請求の範囲25に記載のリング型ネットワークでのマルチキャスト通信における送信ノード。 - 情報伝達の方向性を有するリング型ネットワークでマルチキャスト通信を実行する受信ノードであり、
マルチキャスト通信に係るノードを示す、エントリ情報を受信するエントリ情報受信手段と、
前記エントリ情報を共有するエントリ情報共有手段と、
報受信手段と、
前記エントリ情報を共有するエントリ情報共有手段と、
前記リング型ネットワーク上の位置関係に係る、トポロジ情報を各ノード間で共有するトポロジ情報共有手段と、
マルチキャスト送信される情報の送信方向を参照する送信方向参照手段と、
当該情報を当該送信方向に送信する送信手段と、
当該送信方向に当該情報を受信する受信ノードが存在しない場合に、前記情報を廃棄する情報破棄手段とを有する、リング型ネットワークでのマルチキャスト通信における受信ノード。 - 前記エントリ情報共有手段が、当該受信ノードの配下にある受信ホストから、前記情報の受信を要求する受信要求情報を受信し、
前記受信要求情報に応じて受信要求コマンドを生成し、
前記送信手段が、前記受信要求コマンドを前記送信ノードに送信する、請求の範囲27に記載のリング型ネットワークでのマルチキャスト通信における受信ノード。 - 前記エントリ情報共有手段が、前記受信ホストから前記情報の受信停止を要求する離脱要求情報を受信し、
前記離脱要求情報に応じて受信ホストが存在するか否かを検出し、
受信ホストが存在しない場合に、削除要求コマンドを生成し、
前記送信手段が、前記削除要求コマンドを前記送信ノードに送信する、請求の範囲28に記載のリング型ネットワークでのマルチキャスト通信における受信ノード。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2003/000274 WO2004064335A1 (ja) | 2003-01-15 | 2003-01-15 | リング型ネットワークでのマルチキャスト通信における帯域有効利用方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPWO2004064335A1 JPWO2004064335A1 (ja) | 2006-05-18 |
JP3955064B2 true JP3955064B2 (ja) | 2007-08-08 |
Family
ID=32697376
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004566267A Expired - Fee Related JP3955064B2 (ja) | 2003-01-15 | 2003-01-15 | リング型ネットワークでのマルチキャスト通信における帯域有効利用方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20050249233A1 (ja) |
JP (1) | JP3955064B2 (ja) |
WO (1) | WO2004064335A1 (ja) |
Families Citing this family (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4148949B2 (ja) * | 2003-02-12 | 2008-09-10 | 富士通株式会社 | Rpr装置 |
US7551599B2 (en) * | 2004-03-29 | 2009-06-23 | Corrigent Systems Ltd. | Layer-3 network routing with RPR layer-2 visibility |
CN100364289C (zh) * | 2004-04-30 | 2008-01-23 | 华为技术有限公司 | 在基于弹性分组环的网络中实现二层设备互连的方法 |
CN100356748C (zh) * | 2004-09-17 | 2007-12-19 | 杭州华三通信技术有限公司 | 弹性分组环流量均衡选环方法 |
JP4459018B2 (ja) * | 2004-10-28 | 2010-04-28 | 富士通株式会社 | ノード装置 |
CN1787520B (zh) * | 2004-12-08 | 2010-05-12 | 华为技术有限公司 | 弹性分组环上实现因特网组管理协议的系统及其方法 |
US7512146B1 (en) * | 2006-01-31 | 2009-03-31 | Garrettcom, Inc. | Method and apparatus for layer 2 multicast traffic management |
CN100407681C (zh) * | 2006-03-02 | 2008-07-30 | 华为技术有限公司 | 用于取得rpr的最高保护状态的方法和装置 |
CN101087243B (zh) * | 2006-06-05 | 2011-07-06 | 华为技术有限公司 | 在弹性分组环中限制多播范围的方法及装置 |
JP5092307B2 (ja) | 2006-08-04 | 2012-12-05 | 富士通株式会社 | ネットワーク装置およびデータ制御プログラム |
JP4890239B2 (ja) * | 2006-12-27 | 2012-03-07 | 富士通株式会社 | Rprの送信経路指定方法及び装置 |
CA2681002C (en) * | 2007-03-12 | 2013-05-21 | Espre Solutions, Inc. | System and method for multicast transmission |
JP5501661B2 (ja) * | 2009-06-04 | 2014-05-28 | 三菱電機株式会社 | 光伝送装置およびマルチキャスト通信方法 |
JP2012019328A (ja) * | 2010-07-07 | 2012-01-26 | Fujitsu Ltd | 通信プログラム、通信方法及び電気機器 |
JP5633469B2 (ja) | 2011-05-11 | 2014-12-03 | 富士通株式会社 | ネットワーク及びその障害救済方法及びノード装置 |
US8830999B2 (en) * | 2011-07-06 | 2014-09-09 | Telefonaktiebolaget L M Ericsson (Publ) | Dynamic updating of a label switched path |
CN102437957B (zh) * | 2011-12-16 | 2015-07-08 | 华为技术有限公司 | 一种多协议标签交换的相交环处理方法及装置 |
CN104518928A (zh) * | 2014-12-19 | 2015-04-15 | 深圳市邦彦信息技术有限公司 | 实现远程镜像报文透过rpr环网的方法及系统 |
US11575775B2 (en) * | 2017-01-04 | 2023-02-07 | Extreme Networks, Inc. | Overlay IP multicast over unicast IP networks |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5517494A (en) * | 1994-09-30 | 1996-05-14 | Apple Computer, Inc. | Method and system of multicast routing for groups with a single transmitter |
US5946316A (en) * | 1997-01-17 | 1999-08-31 | Lucent Technologies, Inc. | Dynamic distributed multicast routing protocol |
US6104711A (en) * | 1997-03-06 | 2000-08-15 | Bell Atlantic Network Services, Inc. | Enhanced internet domain name server |
JPH10276215A (ja) * | 1997-03-31 | 1998-10-13 | Toshiba Corp | スイッチノード |
JP3251537B2 (ja) * | 1997-06-16 | 2002-01-28 | 矢崎総業株式会社 | 通信方法、及び通信システム |
JP2923890B2 (ja) * | 1997-10-29 | 1999-07-26 | 日本電気株式会社 | Atmマルチキャストシステム |
SE9704457L (sv) * | 1997-12-01 | 1999-06-02 | Telia Ab | Metod och anordning för fleradressändning i ett IP/ATM-nät |
JP2000134245A (ja) * | 1998-10-26 | 2000-05-12 | Nec Corp | 片方向パス切替リングネットワークのノードシステムおよびm:nマルチキャスト通信方法 |
DE60031515T2 (de) * | 1999-03-17 | 2007-08-23 | Broadcom Corp., Irvine | Netzwerkvermittlung |
US6952397B2 (en) * | 2001-06-07 | 2005-10-04 | Corrigent Systems Ltd. | Communication in a bidirectional ring network with single-direction receiving |
CA2459286C (en) * | 2001-09-04 | 2010-07-20 | Rumi Sheryar Gonda | Method for supporting sdh/sonet aps on ethernet |
US6973049B2 (en) * | 2001-10-16 | 2005-12-06 | Corrigent Systems Ltd. | Auto-configuration of network interfaces in a bidirectional ring network |
US20040103179A1 (en) * | 2002-11-26 | 2004-05-27 | Alcatel Canada Inc. | Topology management of dual ring network |
-
2003
- 2003-01-15 JP JP2004566267A patent/JP3955064B2/ja not_active Expired - Fee Related
- 2003-01-15 WO PCT/JP2003/000274 patent/WO2004064335A1/ja active Application Filing
-
2005
- 2005-02-07 US US11/050,688 patent/US20050249233A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
US20050249233A1 (en) | 2005-11-10 |
JPWO2004064335A1 (ja) | 2006-05-18 |
WO2004064335A1 (ja) | 2004-07-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3955064B2 (ja) | リング型ネットワークでのマルチキャスト通信における帯域有効利用方法 | |
US11606312B2 (en) | Fast fail-over using tunnels | |
US11206148B2 (en) | Bit indexed explicit replication | |
JP4077330B2 (ja) | データ生成装置 | |
Levine et al. | Improving internet multicast with routing labels | |
US7590116B2 (en) | Method for forwarding multicast message in network communication | |
US10461946B2 (en) | Overlay signaling for bit indexed explicit replication | |
US7808993B2 (en) | Bidirectional multicast protocol with upstream and downstream join messages | |
US8169895B2 (en) | Network system and node | |
JP5653912B2 (ja) | マルチキャスト・グループ管理のための方法及び装置 | |
US20080075078A1 (en) | Frame Transfer System | |
US8036220B2 (en) | Pre-dropping of a packet if its time-to-live (TTL) value is not large enough to reach a destination | |
JPWO2006092915A1 (ja) | パケットリングネットワークシステム、パケットリング間の接続方法、およびリング間接続ノード | |
JP2009049635A (ja) | ネットワークシステム、ネットワーク装置及び中継装置 | |
US11245618B2 (en) | Multicast traceroute facility with batch query processing for multiple flows and reservation of resources for requested link metrics | |
US11695686B2 (en) | Source-initiated distribution of spine node identifiers of preferred spine nodes for use in multicast path selection | |
Raghavendra et al. | Multicast routing in internetworks using dynamic core based trees | |
JP5659139B2 (ja) | 集約装置、パケット転送装置、マルチキャストネットワークシステム及びマルチキャスト中継制御方法 | |
JP5495175B2 (ja) | 情報転送システム | |
JP2015032848A (ja) | スイッチおよびルータの移行方法 | |
Iyengar | Multicast Routing in Internetworks Using Dynamic Core Based Trees zyxwvutsrqpo | |
JPWO2006009109A1 (ja) | ブリッジ及び送信装置、並びに情報システム | |
Raghavendra et al. | Multicast Routing in Internetworks Using Dynamic Core Based Trees |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070109 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070308 |
|
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: 20070417 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070427 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100511 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110511 Year of fee payment: 4 |
|
LAPS | Cancellation because of no payment of annual fees |