JP3700654B2 - パケット転送装置 - Google Patents
パケット転送装置 Download PDFInfo
- Publication number
- JP3700654B2 JP3700654B2 JP2002031252A JP2002031252A JP3700654B2 JP 3700654 B2 JP3700654 B2 JP 3700654B2 JP 2002031252 A JP2002031252 A JP 2002031252A JP 2002031252 A JP2002031252 A JP 2002031252A JP 3700654 B2 JP3700654 B2 JP 3700654B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- reception
- specific
- receiving
- receiving terminal
- 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 - Lifetime
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は受信したパケットを転送あるいは廃棄する処理を行うパケット転送装置に係わり、特にストリーム系データの転送に有効なパケット転送装置に関する。
【０００２】
【従来の技術】
比較的大容量のデータの通信を可能にしたネットワークの構築やインターネットへの常時接続等の通信環境の変化によって、音声や動画等のストリーム系データを複数のホスト側のコンピュータに送信するサービスが提供され始めている。特にマルチキャスト通信を利用すると、１つの端末から多くの端末にあたかも放送局が音や映像を送信するような放送型通信サービスを実現することができる。
【０００３】
ところで現在行われているマルチキャスト通信の多くは、ＵＤＰを用いて実現されている。ＵＤＰとは、送信者が送り出すパケットに対して、これを受信する受信者から受信したことに対応する返答を受け取らないプロトコルである。ＵＤＰを用いて送り出された一連のマルチキャストパケットは、ＩＰルータのようなパケット転送装置に収容された後複数の受信者に向けて転送されていくことになる。
【０００４】
現在多くのパケット転送装置では、受信したパケットに対するルーティング処理および転送処理はその制御プログラム（ソフトウェア）に従ってＣＰＵ（中央演算処理装置）等の汎用的な制御部が行うことにより実現されている。ルーティング処理は受信したパケットのヘッダを解析して転送経路を選択する処理であり、転送処理はルーティング処理で選択された転送経路に受信したパケットを転送する処理である。したがって、パケット転送装置は、ストリーム系データについての転送処理を行う場合にマルチキャストパケットを受信するたびにルーティング処理と転送処理を繰り返し行う必要がある。
【０００５】
【発明が解決しようとする課題】
ところでマルチキャストパケットの送信者と末端の受信者との間に位置する任意のパケット転送装置に着目すると、このパケット転送装置はマルチキャスト通信の受信者が存在しない経路に対して受信したマルチキャストパケットを廃棄する必要がある。一方、上流側のマルチキャストパケットの送信者あるいはパケット転送装置はＵＤＰを用いている関係で個々の受信者がパケットを要求していない場合でもその旨のパケットに対する返答をもらっていない。このため、これらの者は今回着目しているパケット転送装置に向けてパケットを送信し続けることになる。この結果、ストリーム系データについての転送処理を行う場合に、パケット転送装置はマルチキャストパケットを受信するたびに転送先の各経路に対してそのパケットを廃棄するか否かを個々に判別し、廃棄する場合にはその処理を行うことになる。
【０００６】
このような廃棄に関する処理は従来からパケット転送装置の前記した制御部が制御プログラムあるいはソフトウェアで行っていた。このため、通常のパケットでは廃棄に関する処理の負担が少ないものの、ストリーム系データでは受信を希望しない受信者に対してその一連のパケットの送信が終了するまで転送先の経路を確認しては廃棄するといった処理がパケット単位で連続することになる。したがって、パケット転送装置の制御部の負荷が大きくなるという問題があった。
【０００７】
そこで本発明の目的は、受信したパケットについて廃棄までの処理を簡略化して処理の負荷を軽減することのできるパケット転送装置を提供することにある。
【０００８】
【課題を解決するための手段】
請求項１記載の発明では、（イ）パケットを廃棄する処理を専用で行うパケット廃棄回路を備えた第１の装置と、（ロ）特定パケットを受信する可能性のあるそれぞれの受信端末からその特定パケットの受信を希望するか否かを確認する特定パケット受信希望有無確認手段と、この受信希望有無確認手段によって受信を希望しないと判別された受信端末あるいはその特定パケットの受信を希望しない受信端末がすべてであるパケット転送側の経路を判別する転送側経路判別手段と、この転送側経路判別手段の判別結果を登録する登録手段と、パケットを宛先に転送するパケット転送手段と、特定パケットを受信する特定パケット受信手段と、この特定パケット受信手段が特定パケットを受信したとき登録手段を参照して受信を希望しないと判別された受信端末あるいはその特定パケットの受信を希望しない受信端末がすべてである経路を宛先とする特定パケットを第１の装置のパケット廃棄回路に受け渡す一方、特定パケットの受信を希望する受信端末あるいはその特定パケットの受信を希望する受信端末の存在する経路を宛先とする特定パケットをパケット転送手段に受け渡すパケット受け渡し手段とを備えた第２の装置とをパケット転送装置に具備させる。
【０００９】
すなわち請求項１記載の発明では、パケット転送装置をパケットを廃棄する処理を専用で行うパケット廃棄回路を備えた第１の装置と、これ以外の第２の装置で構成する。ここで第１の装置は、パケット廃棄回路を備えた廃棄専用の回路で構成しているので、転送装置の他の回路部分に対する影響を排除することができる。パケット廃棄回路は、パケット廃棄専用のハードウェアであってもよいし、専用のＣＰＵ等を備えたソフトウェアで構成されていてもよい。第２の装置では、特定パケット受信希望有無確認手段がたとえばストリーム系データ等を構成する特定パケットを受信する可能性のあるそれぞれの受信端末からその特定パケットの受信を希望するか否かを確認するようにしている。そして、転送側経路判別手段がこの受信希望有無確認手段によって受信を希望しないと判別された受信端末あるいはその特定パケットの受信を希望しない受信端末がすべてであるパケット転送側の経路を判別し、登録手段がこの転送側経路判別手段の判別結果を登録するようにしている。したがって、特定パケット受信手段が特定パケットを受信したとき、登録手段を参照して、受信を希望しないと判別された受信端末あるいはその特定パケットの受信を希望しない受信端末がすべてである経路を宛先とする特定パケットについてはパケット廃棄回路に受け渡してその転送先についてこの特定パケットが存在する限り廃棄させる。このように、登録手段に登録した後は不要な宛先の特定パケットが特別の処理を行うことなくパケット廃棄回路に受け渡され廃棄されるので、パケット転送装置の制御部分における負荷の軽減を実現することができる。
【００１０】
請求項２記載の発明では、（イ）パケットを廃棄する処理を専用で行うパケット廃棄回路を備えた第１の装置と、（ロ）特定の複数の受信端末のいずれかあるいはそれに至る経路を宛先としたパケットを受信するパケット受信手段と、特定の複数の受信端末あるいはそれらに至る経路のうち特定パケットの受信を希望しない受信端末あるいは特定パケットの受信を希望しない受信端末がすべてである経路をこれ以外の受信端末あるいは経路から区別する受信不要情報を記憶する受信不要情報記憶手段と、パケットを宛先に転送するパケット転送手段と、特定の複数の受信端末に対してこれらが特定パケットの受信を希望していないか否かあるいは所定の経路を経たすべての受信端末が特定パケットの受信を希望していないか否かを確認する受信希望有無確認手段と、この受信希望有無確認手段の確認結果を基にした受信不要情報を受信不要情報記憶手段に登録する受信不要情報登録手段と、パケット受信手段が特定パケットを受信したときその転送の必要の有無を受信不要情報登録手段の登録した受信不要情報によって判別し、受信を希望する受信端末の存在しない経路あるいは受信を希望しない受信端末を直接の宛先とした特定パケットを第１の装置のパケット廃棄回路に受け渡す一方、受信を希望する受信端末の存在する経路あるいは受信を希望する受信端末を直接の宛先とした特定パケットをパケット転送手段に受け渡す受信端末処理経路選択手段とを備えた第２の装置とをパケット転送装置に具備させる。
【００１１】
すなわち請求項２記載の発明では、パケット転送装置をパケットを廃棄する処理を専用で行うパケット廃棄回路を備えた第１の装置と、これ以外の第２の装置で構成する。ここで第１の装置は、パケット廃棄回路を備えた廃棄専用の回路で構成しているので、転送装置の他の回路部分に対する影響を排除することができる。パケット廃棄回路は、パケット廃棄専用のハードウェアであってもよいし、専用のＣＰＵ等を備えたソフトウェアで構成されていてもよい。第２の装置では、パケット受信手段が予め特定された複数の受信端末のいずれかあるいはそれに至る経路を宛先としたパケットを受信するようになっている。たとえばストリーム系データの配信が行われる場合を例にとると、それぞれのストリーム系データの受信を行う契約を行った特定の会員がここでいう特定の複数の受信端末に対応する。これらの受信端末を宛先としただけでなくそれに至る経路を宛先としたパケットを含めたのは、個々の受信端末を直接の宛先としない場合にも対応させたものである。本発明では受信不要情報記憶手段が設けられており、たとえば、これら特定の受信端末でパケットの受信を希望しない者、あるいはパケットの受信を希望しない受信端末がすべてである経路がこの受信不要情報記憶手段に受信不要情報として記憶されるようになっている。受信を希望する者としない者の２者択一の場合には、受信を希望する者やその経路を記憶してもよい。これに属さないものとして受信を希望しない者や経路が特定されるからである。パケット転送装置の受信したパケットは受信端末処理経路選択手段でその処理経路を選択されるが、このとき受信不要情報登録手段の登録した受信不要情報がチェックされる。したがって、廃棄するパケットかどうかを受信時に簡単に判別することができ、廃棄する場合には処理を後の回路部分に任せることなく、パケットを廃棄する専用のパケット廃棄回路に渡して、ここでパケットの廃棄処理を行わせることができる。すなわち、ストリーム系データのように宛先が同一のパケットが連続して送られてくるような場合には、ある時点でその宛先のパケットが不要であることを受信不要情報記憶手段に記憶してしまえば、受信したパケットのうちの該当するパケットは直ちにパケット廃棄回路に渡されて処理されることになる。このように請求項２記載の発明では、特定された複数の受信端末に関する受信不要情報を記憶し照合できるようにしておくことで、受信を希望する受信端末の存在しない経路あるいは受信を希望しない受信端末を直接の宛先とした特定パケットをパケット廃棄回路で廃棄させることを可能にし、パケット転送装置の制御部分における負荷の軽減を実現している。
【００１２】
請求項３記載の発明では、請求項２記載のパケット転送装置で、受信端末処理経路選択手段は、受信を希望する受信端末の存在しない経路あるいは受信を希望しない受信端末を直接の宛先とした特定パケット、あるいは受信を希望する受信端末の存在する経路あるいは受信を希望する受信端末を直接の宛先とした特定パケット以外の特定パケットが存在するときこれを受信希望有無確認手段に確認させることを特徴としている。
【００１３】
すなわち請求項３記載の発明では、受信した特定パケットが受信不要情報記憶手段の記憶内容からでは廃棄すべき対象ともされず、また積極的に受信端末へ転送する対象ともされないようなものの場合の扱いを示している。このような特定パケットについては、受信端末処理経路選択手段が受信希望有無確認手段に確認させる。したがって、確認結果としてその受信端末あるいは経路の特定パケットが廃棄されるものとなれば、受信不要情報として登録されるので、次からはその特定パケットの選別とパケット廃棄手段による廃棄とが特別の負担なく行われるようになる。なお、確認の結果としてその特定パケットが受信端末の予定していないようなパケットである場合がある。たとえば特定の複数の受信端末が前記したストリーム系データの会員の端末であるような場合で、ストリーム系データの送出側と偽って妨害用の特定パケットを連続して受信端末に送りつけるような第三者がいるような場合である。このような場合には、これらの受信端末がその特定パケットの受信を希望していないとすることで、それ以後のその特定パケットを専用の廃棄手段で処理させることができる。したがって、このような特定パケットの廃棄処理を専用の回路あるいはハードウェアで行わせることで、パケット転送装置の本来的な制御に与える影響を最小限とすることができる。
【００１４】
請求項４記載の発明では、請求項２記載のパケット転送装置で、受信不要情報登録手段は、特定の複数の受信端末のいずれかあるいはそれに至る経路に向けて特定パケットの送信が開始される時間が予め定められているとき、この特定パケットがパケット受信手段によって受信される前に受信希望有無確認手段によって確認された確認結果を受信不要情報記憶手段に登録することを特徴としている。
【００１５】
すなわち請求項４記載の発明では、特定パケットの送信が開始される時間が予め定められているとき、この特定パケットを受信する前に受信不要情報を受信不要情報記憶手段に登録する場合を扱っている。このようなことが可能な通信システムでは、ストリーム系のデータあるいはこのようなコンテンツに限らず、極端な場合にはただ一回だけ送信される特定パケットについても廃棄の処理を簡略化させることがでることになる。
【００１６】
請求項５記載の発明では、請求項２記載のパケット転送装置で、受信希望有無確認手段は、特定パケットの送信が開始された後に特定の複数の受信端末のいずれかが受信を希望するか否かについての変更を生じさせたときこれを検出する変更検出手段を備えており、受信不要情報登録手段は変更検出手段の検出した変更を登録することを特徴としている。
【００１７】
すなわち請求項５記載の発明では、特定パケットの送信開始後に発生した特定の複数の受信端末の受信の希望の要否の変更を検出して、この検出した変更を受信不要情報記憶手段に登録するようになっている。これにより受信端末側の変更に基づく転送の必要の有無の判別に用いる受信不要情報に変更が発生する可能性を検出したとき、これに応じて受信不要情報を変更することができる。たとえば、パケット転送装置を介して一連の特定パケットを受信する受信端末が受信を希望しなくなれば、この変更を検出した後の受信不要情報を基に以降受信するこれらの特定パケットを直ちに廃棄させることができる。
【００１８】
請求項６記載の発明では、請求項２記載のパケット転送装置で、特定の複数の受信端末はストリーム系のコンテンツを構成する一連のパケットの受信をコンテンツごとに契約する契約者の備える端末であり、受信希望有無確認手段は、これらの受信端末の契約によるコンテンツごとの受信の希望の有無で特定パケットの受信の有無を確認することを特徴としている。
【００１９】
すなわち請求項６記載の発明では、請求項２に記載した特定の複数の受信端末と受信希望有無確認手段について１つの具体例を示したものである。受信端末は、ストリーム系のコンテンツを、コンテンツごとに契約して受信するようになっている。同じコンテンツに対して契約を行っている受信端末が特定のコンテンツを組み込んだ特定パケットを受信することになる。特定の複数の受信端末は、この場合、個々のコンテンツの契約を行いうる会員全体である。この例の場合、受信希望有無確認手段は、会員がどのコンテンツの受信を希望するかを確認する従来行われていた手法を用いたものである。たとえばケーブルテレビ局が個別の放送について受信希望者を確認していた手法を用い、これにより得られたデータを受信不要情報として受信不要情報記憶手段の記憶内容に反映させることになる。このような確認手段との連結で、特定パケット自体が受信端末に一方的に送られる形式のものであっても、受信不要情報を取得したり変更することが可能になる。
【００２２】
【発明の実施の形態】
【００２３】
【実施例】
以下実施例につき本発明を詳細に説明する。
【００２４】
図１は本発明の一実施例における、マルチキャスト通信で送信されるパケットを転送するためのパケット処理装置を備えたマルチキャスト・ネットワークの簡略化された例を表わしたものである。このマルチキャスト・ネットワーク２１１には、マルチキャストパケット送信者が使用する送信端末２１２と、これに隣接した送信側ＩＰ（Internet Protocol）ルータ装置２１３とが配置されている。また、マルチキャストパケット受信者が使用する第１の受信端末２１４および第２の受信端末２１５と、これらにそれぞれ隣接した第１の受信側ＩＰルータ装置２１６および第２の受信側ＩＰルータ装置２１７が配置されている。送信端末２１２には、送信するマルチキャストパケットに組み込むための各種ストリーム系データを収めたライブラリ２１８が接続されている。また、第１および第２の受信端末２１４、２１５には受信希望有無確認装置２２０が接続されている。受信希望有無確認装置２２０は、ライブラリ２１８を管理する会社とは別の組織である図示しない会社の中に、この例ではＣＡＴＶ（cable television）の配信局の中に、置かれている。そして、各受信端末２１４、２１５が特定の番組あるいはコンテンツの受信を希望するか否かを、従来から確立されている手法で、受信希望有無確認装置２２０側で確認できるようになっている。受信希望有無確認装置２２０の確認結果は、通常はこのＣＡＴＶの配信局の契約者に対する料金の徴収等の自社内の用途に使用する。本実施例では、受信希望有無確認装置２２０はこの確認結果を基にして、受信を希望しているコンテンツの配信に合わせて各受信端末２１４、２１５に配信希望情報２１０を送信するようになっている。配信希望情報２１０は、送信端末２１２からの配信を受けるための配信経路の作成を要求させるものと、配信経路の削除を要求させるものとがある。このＣＡＴＶの配信局は、この配信希望情報２１０を各受信端末２１４、２１５に送信することで、契約の行われたコンテンツを対応した受信端末に配信することを可能にしている。
【００２５】
なお、この図１で第１および第２の受信側ＩＰルータ装置２１６、２１７は、図示しない幾つかの受信端末とも接続され得るが、説明を簡略化するために本実施例ではこれらについて考えないものとする。また、この図では送信側ＩＰルータ装置２１３と第１および第２の受信側ＩＰルータ装置２１６、２１７を直結して示しているが、実際のネットワークではこれらの間にも幾つかのパケット転送装置としてのＩＰルータ装置が配置され得る。
【００２６】
さて、マルチキャスト・ネットワーク２１１では、各端末を識別するためのＩＰアドレスが割り振られていて、ＩＰパケットの送信を行う際の送信先や送信元を指定するために使用することができるようになっている。マルチキャストパケットには、送信先を示す情報としてマルチキャストアドレスが組み込まれるようになっている。マルチキャストアドレスは、特定のマルチキャストパケットを受信する複数の端末に割り振られているＩＰアドレスと対応付けるための特定のＩＰアドレスである。
【００２７】
マルチキャスト・ネットワーク２１１上の送信側ＩＰルータ装置２１３、第１の受信側ＩＰルータ装置２１６および第２の受信側ＩＰルータ装置２１７では、ＲＦＣ（Request For Comment）“２３６２”により定められているＰＩＭ−ＳＭ（Protocol Independent Multicast-Sparse Mode）が動作している。ＰＩＭ−ＳＭとは、ＩＰルータ装置間でのマルチキャスト配信用のルーティングプロトコルであり、マルチキャスト用の配信木を管理しているものとする。このマルチキャスト用の配信木は、ＰＩＭ−ＳＭが動作しているＩＰルータ装置が配置されている木構造になっており、各受信端末２１４、２１５等の受信端末は、配置されているいずれかのＩＰルータ装置に接続されるようになっている。このマルチキャスト用の配信木の頂点に配置されるＩＰルータ装置は、マルチキャストパケットを送信する送信端末２１２に隣接した送信側ＩＰルータ装置２１３である。また、各受信端末２１４、２１５等の受信端末が接続されている第１および第２の受信側ＩＰルータ装置２１６、２１７等のＩＰルータ装置は、上流に配置されている送信側ＩＰルータ装置２１３等のＩＰルータ装置に対して受信端末の代理を行うようになっている。これにより、本実施例のマルチキャスト用の配信木は、マルチキャストパケットの受信を要求する受信端末に隣接したＩＰルータ装置から、頂点のＩＰルータ装置に向けて作成されるようになっている。
【００２８】
このようなマルチキャスト・ネットワーク２１１は、前記したように、たとえば楽曲の著作権を持つ会社がこれらのデータを会員へ配信するサービスを提供する通信システムとして使用されている。一例を考えると、送信端末２１２とライブラリ２１８はある会社内のサービス部門に配置されており、送信端末２１２が、ライブラリ２１８内に保持されている楽曲のストリーム系データを組み込んだ一連のマルチキャストパケット２１９を作成するようになっている。ストリーム系データとは、再生の順に先頭から連続した複数のパケットデータを指しており、たとえば楽曲のストリーム系データの場合、これらのパケットをデータを先頭から再生することで楽曲を聴くことができるようになっている。送信側ＩＰルータ装置２１３は会社内の通信部門に配置されており、送信端末２１２が楽曲から作成した一連のマルチキャストパケット（ストリーム系データ）２１９を各受信端末に向けて送信するようになっている。また第１および第２の受信端末２１４、２１５は、会員の部屋に備えられたコンピュータなどの通信端末であり、受信した一連のマルチキャストパケット２１９から楽曲のストリーム系データを取り出して楽曲を再生できるようになっている。これら第１および第２の受信端末２１４、２１５の会員は、すでに説明したように同時にＣＡＴＶの配信局の契約者となっている。なお、これらの会員が接続契約を結んでいるプロバイダを利用しても同様のサービスが可能である。この場合、プロバイダは第１および第２の受信側ＩＰルータ装置２１６、２１７を用いて、受信したマルチキャストパケット２１９をそれぞれ対応した会員の通信端末へ送信することになる。
【００２９】
サービスを提供する会社は、たとえばライブラリ２１８に納められた楽曲の中で音楽のジャンルとしての「ポップス」と「ジャズ」から１曲ずつ提供するようになっており、この楽曲の受信を希望する会員へ送信するためのマルチキャスト配信木が作成されるようになっている。送信端末２１２から送信されるマルチキャストパケット２１９は、「ポップス」あるいは「ジャズ」の楽曲のストリーム系データが先頭から分割されて組み込まれた一連のＩＰパケットである。もっとも、会員の希望に応じてジャンルごとに配信木を別々に作成するようにすることも可能である。
【００３０】
図２は、図１で示したネットワークに配置されたＩＰルータ装置の構成を表わしたものである。ここでは、送信側ＩＰルータ装置２１３について説明するが、第１および第２の受信側ＩＰルータ装置２１６、２１７も同様の構成である。送信側ＩＰルータ装置２１３には、ＩＰパケットのハードウェア処理を行うハードウェアエンジン２２１と、ＩＰパケットのＩＰヘッダ解析および転送処理を行うＩＰフォワーディング（Forwarding）処理部２２２が備えられている。ハードウェアエンジン２２１およびＩＰフォワーディング処理部２２２は、それぞれハードウェアドライバ２２３に接続されており、これを中継して各種データのやりとりを行うようになっている。また、各種プロトコルが動作するプロトコルスタック処理部２２４が備えられていて、ＩＰフォワーディング処理部２２２と接続されている。更にハードウェアエンジン２２１が管理するハードウェア管理テーブル２２５と、ＩＰフォワーディング処理部２２２が管理するルーティングテーブルであるマルチキャスト・フォワーディング・エントリ２２６とが備えられている。このような送信側ＩＰルータ装置２１３に受信されたパケットは、まずハードウェアエンジン２２１に入力されるようになっている。
【００３１】
送信側ＩＰルータ装置２１３にはＣＰＵ（中央演算処理装置）やＲＯＭ（リード・オンリ・メモリ）等の記憶媒体を備えた図示しない制御部が配置されていて、この制御部が予め定められた所定のプログラムを実行することで、制御を行うようになっている。ただし、ハードウェアエンジン２２１については、この図示しない制御部に関わりなく予め定められた処理を行うハードウェアで構成されている。
【００３２】
ハードウェアエンジン２２１は、パケットが入力されるたびにこのパケットに対応した転送用エントリあるいは廃棄用エントリが登録されているかハードウェア管理テーブル２２５を検索するようになっている。転送用エントリあるいは廃棄用エントリには、それぞれＩＰパケットのヘッダ情報に対応した送信元アドレス、送信先アドレス、プロトコル番号、送信元ポート番号、送信先ポート番号が格納されている。ハードウェアエンジン２２１は、エントリに格納されているこれらの情報が受信したＩＰパケットのヘッダ情報と一致した場合、受信したＩＰパケットとエントリが一致すると判別するようになっている。これによって一致したエントリが転送用エントリである場合はこのパケットの転送処理を行い、廃棄用エントリである場合はこのパケットの廃棄処理を行うようになっている。転送用エントリには転送処理に必要な情報も格納されており、これを用いてハードウェアエンジン２２１は転送処理を行うようになっている。また、ここでヘッダ情報がエントリと一致しない場合は、入力されたＩＰパケットをハードウェアドライバ２２３を介してＩＰフォワーディング処理部２２２へ出力するようになっている。
【００３３】
プロトコルスタック処理部２２４は、マルチキャストプロトコルであるＰＩＭ−ＳＭに従って動的なマルチキャスト用の配信木を管理するＰＩＭ−ＳＭ処理部２２７を備えている。またＰＩＭ−ＳＭ処理部２２７は、ＩＰヘッダ情報２２８をＩＰフォワーディング処理部２２２から受信するようになっている。このＰＩＭ−ＳＭ処理部２２７は検索対象となるエントリを保持するエントリテーブル２２７Ｔを備えている。このエントリには、ＩＰパケットのヘッダ情報に対応した送信先アドレスと、この送信先アドレスが組み込まれたマルチキャストパケットのマルチキャスト用の配信木で、この送信側ＩＰルータ装置２１３の直下となるＩＰルータ装置あるいは受信端末を示す情報が組み込まれるようになっている。送信側ＩＰルータ装置２１３の図示しない制御部は、エントリテーブル２２７Ｔを検索して、エントリに格納されている送信先アドレスが受信したＩＰパケットのヘッダ情報と一致した場合、このＩＰパケットとエントリが一致すると判別するようになっている。
【００３４】
マルチキャスト・フォワーディング・エントリ２２６は、ＩＰフォワーディング処理部２２２が受信したＩＰパケットのヘッダ情報で検索する検索対象であるエントリを管理するようになっている。このエントリには、ＩＰパケットのヘッダ情報に対応した送信元アドレスと送信先アドレス、またＩＰパケットを次の転送先へ送り出すために必要な情報として送信側ＩＰルータ装置２１３の図示しない出力ポートを示す情報などが組み込まれている。この次の転送先へ送り出すために必要な情報は、エントリテーブル２２７Ｔのエントリに対応してマルチキャスト配信木で直下のＩＰルータ装置あるいは受信端末に向けてパケットを出力するための情報を表わすものである。したがって、マルチキャスト配信木上には存在しない中継装置などが、次の転送先として指定される場合もある。送信側ＩＰルータ装置２１３の図示しない制御部は、エントリに格納されている送信元アドレスおよび送信先アドレスが受信したＩＰパケットのヘッダ情報と一致した場合、このＩＰパケットとエントリが一致すると判別するようになっている。
【００３５】
ＩＰフォワーディング処理部２２２は、廃棄用エントリの登録あるいは削除を要求する廃棄用エントリ登録・削除要求２２９をハードウェアドライバ２２３へ送信することになる。ハードウェアドライバ２２３は廃棄用エントリ登録・削除要求２２９を受信すると廃棄用エントリ登録・削除要求２２９をハードウェアエンジン２２１への命令である廃棄用エントリ登録・削除要求２３０に変換して、ハードウェアエンジン２２１へ送るようになっている。
【００３６】
図３は、本実施例でマルチキャスト転送を行うＩＰパケットのヘッダ情報のデータ構成を表わしたものである。ヘッダ情報３０１はＩＰヘッダ情報とＵＤＰ（User Datagram Protocol）ヘッダ情報を合わせたものを指している。ＵＤＰヘッダ情報には、本実施例のマルチキャスト転送を行う際、ＩＰプロトコルの上位のプロトコルとなるＵＤＰプロトコルの情報が格納されるようになっている。一般的にＵＤＰプロトコルを用いてマルチキャスト転送を行う際には、このＩＰパケットを受信する第１あるいは第２の受信端末２１４、２１５と送信端末２１２は直接このＩＰパケットに関する信号のやり取りを行わないようになっている。これは、送信端末から多数の受信端末にマルチキャストパケットを送信する場合に個々の受信端末と送信するＩＰパケットについての信号のやり取りを行うことは、送信端末に対する負荷が大きくなるためである。
【００３７】
ＩＰヘッダ情報は、インターネットプロトコルのバージョンを示すバージョン３０２と、ＩＰヘッダの長さを示すヘッダ長３０３と、ＩＰパケットの品質要求を示すサービスタイプ３０４と、ＩＰパケットの長さを示すパケット長３０５と、ＩＰパケットに分割して格納したデータの復元に使用する識別子３０６と、このＩＰパケットが分割されたデータの最初、中間あるいは末尾のどれにあたるかを示すフラグ３０７と、このＩＰパケットが分割された順番を示すフラグメントオフセット３０８と、ネットワーク上での生存時間を示す生存時間３０９と、ＩＰパケットに格納されたデータのプロトコルを示すプロトコル番号３１０と、誤りを検出するために用いるヘッダチェックサム３１１と、送信元のＩＰアドレスを示す送信元アドレス３１２および送信先のＩＰアドレスを示す送信先アドレス３１３で構成されている。図１で説明した送信端末２１２から送信されるマルチキャストパケット２１９には、特定のマルチキャストアドレスが、このヘッダ情報３０１の送信先アドレス３１３として組み込まれている。
【００３８】
次に同じく図３を用いてＵＤＰヘッダ情報のデータ構成について説明する。ＵＤＰヘッダ情報は、送信元装置から出力する際の出力ポートを示す送信元ポート番号３１４と、送信先装置が受信する際の入力ポートを示す送信先ポート番号３１５と、ＵＤＰパケットの長さを示すセグメント長３１６およびＵＤＰパケットの誤りを検出するために用いるチェックサム３１７で構成されている。ここでＵＤＰパケットとは、マルチキャスト転送するデータの先頭にＵＤＰヘッダ情報を付加したものを指していて、更にこの先頭にＩＰパケットのヘッダ情報を付加することで、ＩＰパケットとなるようになっている。
【００３９】
図４は、図２に示した送信側ＩＰルータ装置がマルチキャストパケットを受信したときの処理の流れと各種エントリの作成順序について表わしたものである。ただし、エントリテーブル２２７Ｔに格納されるエントリについては後で説明を行うものとする。送信側ＩＰルータ装置２１３が受信したマルチキャストパケット２１９は、ハードウェアエンジン２２１に入力されるようになっている。ここでハードウェアエンジン２２１は、受信したマルチキャストパケット２１９のヘッダ情報３０１を用いて、ハードウェア管理テーブル２２５を検索する（ステップＳ４０１）。ここでヘッダ情報３０１がエントリと一致した場合には（ステップＳ４０２：Ｙ）、更にこの一致したエントリが転送用エントリであるか否か判別する（ステップＳ４０３）。転送用エントリであった場合には（Ｙ）、ハードウェアエンジン２２１は転送用エントリの指示に従った転送処理を実施して（ステップＳ４０４）、処理を終了する（エンド）。また転送用エントリではない場合（ステップＳ４０３：Ｎ）、廃棄用エントリに一致したとみなして、ハードウェアエンジン２２１は廃棄処理を実施し（ステップＳ４０５）、処理を終了する（エンド）。ステップＳ４０２でエントリに一致しなかった場合には（Ｎ）、受信したマルチキャストパケット２１９をハードウェアドライバ２２３経由でＩＰフォワーディング処理部２２２に出力する。
【００４０】
送信側ＩＰルータ装置２１３の図示しない制御部は、ＩＰフォワーディング処理部２２２に入力されたマルチキャストパケット２１９のヘッダ情報３０１を用いて、マルチキャスト・フォワーディング・エントリ２２６を検索する（ステップＳ４０６）。ヘッダ情報３０１の送信元アドレス３１２および送信先アドレス３１３がエントリの検索対象の情報と一致した場合には（ステップＳ４０７：Ｙ）、図示しない制御部が一致したエントリを基にしてハードウェアドライバ２２３に転送エントリ登録要求を通知し、ハードウェア管理テーブル２２５への転送エントリの登録を実施する（ステップＳ４０８）。この後、マルチキャスト・フォワーディング・エントリ２２６の一致したエントリに従ったマルチキャストパケット２１９の転送処理を実施して（ステップＳ４０９）、処理を終了する（エンド）。
【００４１】
ステップＳ４０７でヘッダ情報３０１がエントリと一致しない場合には（Ｎ）、図示しない制御部はＰＩＭ−ＳＭ処理部２２７が管理するエントリテーブル２２７Ｔを更にヘッダ情報３０１で検索する（ステップＳ４１０）。ここで一致するエントリが存在した場合には（ステップＳ４１１：Ｙ）、マルチキャスト・フォワーディング・エントリ２２６に該当するマルチキャスト転送用のエントリの登録を実施する（ステップＳ４１２）。この後、ハードウェア管理テーブル２２５への転送エントリの登録とマルチキャストパケット２１９の転送処理を実施して（ステップＳ４０８、４０９）、処理を終了する（エンド）。ステップＳ４１１で一致するエントリが存在しない場合には（Ｎ）、ヘッダ情報３０１を付加した廃棄用エントリ作成要求をハードウェアドライバ２２３へ通知し、ハードウェア管理テーブル２２５への廃棄用エントリの登録を実施する（ステップＳ４１３）。この後、マルチキャストパケット２１９の廃棄処理を実施して（ステップＳ４１４）、処理を終了する（エンド）。
【００４２】
このような処理で、たとえばある「ジャズ」の楽曲が組み込まれた一連のマルチキャストパケット２１９に受信を希望する受信端末がない場合、この楽曲を配信するためのマルチキャスト配信木は作成されず、エントリテーブル２２７Ｔにもエントリは存在しない。これらが受信されるとハードウェア管理テーブル２２５へこれらを廃棄するように指示する廃棄用エントリが登録されるまでは、ＩＰフォワーディング処理部２２２に入力された後廃棄されるようになっている。しかし、ハードウェア管理テーブル２２５へこの楽曲のマルチキャストパケット２１９の廃棄を指示する廃棄用エントリが登録された後は、ハードウェアエンジン２２１によって廃棄されるようになる。したがって、ある楽曲のストリーム系データが組み込まれた一連のマルチキャストパケット２１９を連続して廃棄する場合、ハードウェア管理テーブル２２５に廃棄用エントリが登録された後は、送信側ＩＰルータ装置２１２のＩＰフォワーディング処理部２２２に廃棄処理による負荷を与えない。したがって、一連のマルチキャストパケット２１９の中で最初に受信したファーストパケットのＩＰヘッダ解析および転送あるいは廃棄をＩＰフォワーディング処理部２２２で行い、これに対応した廃棄用エントリの登録以降受信するマルチキャストパケット２１９の転送あるいは廃棄をハードウェアエンジン２２１で行うことで、送信側ＩＰルータ装置２１２の図示しない制御部の処理の負荷を軽減することができる。
【００４３】
図５は、ＰＩＭ−ＳＭ処理部２２７宛の特定のマルチキャストパケットに対しての受信要求あるいは受信停止要求が組み込まれたＩＰパケットが、ＩＰルータ装置２１３に受信された場合の処理の流れを表わしたものである。ＩＰルータ装置２１３の図示しない制御部は、受信したＩＰパケットがＰＩＭ−ＳＭ処理部２２７宛のＩＰパケットであるときマルチキャストアドレスによって特定される一連のマルチキャストパケットの受信要求あるいは受信停止を示す情報であるか否かを判別する（ステップＳ４２１）。これ以外の場合には（Ｎ）、処理を終了する（エンド）。受信要求あるいは受信停止を示す情報が組み込まれていた場合（ステップＳ４２１：Ｙ）、これが受信要求を示していれば（ステップＳ４２２：Ｙ）、この特定される一連のマルチキャストパケットの送信先を示すエントリがＰＩＭ−ＳＭ処理部２２７のエントリテーブル２２７Ｔに存在するか判別する（ステップＳ４２３）。該当するエントリが存在する場合（Ｙ）、この受信要求を送信してきた受信端末を送信先に追加するエントリの変更を行う（ステップＳ４２４）。この変更に伴ってマルチキャスト・フォワーディング・エントリ２２６に登録されているマルチキャスト転送用のエントリも変更する。この後、この特定される一連のマルチキャストパケットの転送を指示する転送用エントリのハードウェア管理テーブル２２５からの削除を要求する転送用エントリ削除要求を作成する（ステップＳ４２５）。作成された転送用エントリ削除要求は、ＩＰフォワーディング処理部２２２経由でハードウェアドライバ２２３に送信して（ステップＳ４２６）処理を終了する（エンド）。ハードウェアドライバ２２３はこの転送用エントリ削除要求をハードウェアエンジン２２１に渡して、該当する転送用エントリをハードウェア管理テーブル２２５から削除させるようになっている。
【００４４】
また、該当するエントリがＰＩＭ−ＳＭ処理部２２７のエントリテーブル２２７Ｔに存在しない場合（ステップＳ４２３：Ｎ）、この特定される一連のマルチキャストパケットの転送先を示すためのエントリを作成し、このエントリテーブル２２７Ｔに登録する（ステップＳ４２７）。この後、これらマルチキャストパケットの廃棄を指示する廃棄用エントリのハードウェア管理テーブル２２５からの削除を要求する廃棄用エントリ削除要求を作成する（ステップＳ４２８）。作成された廃棄用エントリ削除要求は、ＩＰフォワーディング処理部２２２経由でハードウェアドライバ２２３に送信して（ステップＳ４２９）処理を終了する（エンド）。ハードウェアドライバ２２３はこの転送用エントリ削除要求をハードウェアエンジン２２１に渡して、該当する転送用エントリをハードウェア管理テーブル２２５から削除させるようになっている。
【００４５】
更に、受信停止を示す情報が組み込まれていた場合（ステップＳ４２２：Ｎ）、該当するエントリがＰＩＭ−ＳＭ処理部２２７の図示しないエントリテーブル２２７Ｔに存在しなければ（ステップＳ４３０：Ｎ）、処理を終了する（エンド）。これは、これまで送信先の無かったマルチキャストパケットに対して受信停止が要求された場合であり、行うべき処理は存在しない。該当するエントリがこのエントリテーブル２２７Ｔに存在する場合には（ステップＳ４３０：Ｙ）、この受信停止を送信してきた受信端末をエントリの送信先から削除する変更を行う。この結果送信先が存在しなくなった場合には、この特定される一連のマルチキャストパケットの送信先を示すエントリ自体の削除を行う（ステップＳ４３１）。この変更に伴ってマルチキャスト・フォワーディング・エントリ２２６に登録されているマルチキャスト転送用のエントリも変更あるいは削除する。この後、このマルチキャストパケットの転送を指示する転送用エントリのハードウェア管理テーブル２２５からの削除を要求する転送用エントリ削除要求を作成する（ステップＳ４３２）。作成された転送用エントリ削除要求は、ＩＰフォワーディング処理部２２２経由でハードウェアドライバ２２３に送信して（ステップＳ４３３）処理を終了する（エンド）。ハードウェアドライバ２２３はこの転送用エントリ削除要求をハードウェアエンジン２２１に渡して、該当する転送用エントリをハードウェア管理テーブル２２５から削除させるようになっている。
【００４６】
さて、ハードウェアエンジン２２１によって廃棄処理が行われている楽曲のストリーム系データが組み込まれた一連のマルチキャストパケット２１９に受信希望者が現れた場合は、廃棄処理を停止して、受信希望者への送信を再開する必要がある。この一例として、その楽曲が組み込まれた一連のマルチキャストパケット２１９の配信経路の作成を要求させる配信希望情報２１０を受信希望有無確認装置２２０から第１の受信端末２１４に送信したときの、第１の受信端末２１４、第１の受信側ＩＰルータ装置２１６および送信側ＩＰルータ装置２１３の処理について説明する。
【００４７】
第１の受信端末２１４は、その楽曲が組み込まれた一連のマルチキャストパケット２１９の配信経路の作成を要求させる配信希望情報２１０を受け取ると、これに対応してその楽曲が組み込まれた一連のマルチキャストパケット２１９の受信を要求する受信要求を組み込んだパケットを作成して、第１の受信側ＩＰルータ装置２１６に送信する。第１の受信側ＩＰルータ装置２１６はこのとき、既にハードウェアエンジン２２１によってＩＰパケットの廃棄処理が行われているので、ＰＩＭ−ＳＭ処理部２２７の図示しないエントリテーブル２２７Ｔにその楽曲が組み込まれた一連のマルチキャストパケット２１９に対するエントリは存在しない（図５：ステップＳ４２３：Ｎ）。従って、このようなＩＰパケットを受信するとマルチキャストパケット２１９に組み込まれるマルチキャストアドレスとこの送信先として第１の受信端末２１４を示すエントリを作成して、このエントリテーブル２２７Ｔに登録する（同図：ステップＳ４２７）。この後、この楽曲が組み込まれた一連のマルチキャストパケット２１９の廃棄を指示する廃棄用エントリのハードウェア管理テーブル２２５からの削除を要求するようになっている（同図：ステップＳ４２８、ステップＳ４２９）。また、第１の受信側ＩＰルータ装置２１６は、その楽曲が組み込まれた一連のマルチキャストパケット２１９の受信を要求する受信要求を組み込んだＩＰパケットを、送信側ＩＰルータ装置２１３に送信する。送信側ＩＰルータ装置２１３はこのＩＰパケットを受信すると、エントリテーブル２２７Ｔに送信先として第１の受信側ＩＰルータ装置２１６を示すエントリを登録し、ハードウェア管理テーブル２２５からの廃棄用エントリの削除を要求する。
【００４８】
送信側ＩＰルータ装置２１３のハードウェア管理テーブル２２５から廃棄用エントリが削除された後は、その楽曲が組み込まれた一連のマルチキャストパケット２１９を受信しても、廃棄処理は実施されないようになる（図４：ステップＳ４０２：Ｎ）。また、この受信したマルチキャストパケット２１９は、ＰＩＭ−ＳＭ処理部２２７の図示しないエントリテーブル２２７Ｔが管理するエントリで、一致するエントリが存在する（同図：ステップＳ４１０、ステップＳ４１１：Ｙ）。そこで、マルチキャスト・フォワーディング・エントリ２２６とハードウェア管理テーブル２２５にそれぞれ対応するエントリと転送用エントリの登録が実施された後（同図：ステップＳ４１２、ステップＳ４０８）、第１の受信側ＩＰルータ装置２１６の転送処理が図示しない制御部によって行われる（同図：ステップＳ４０９）。以降受信されるその楽曲が組み込まれた一連のマルチキャストパケット２１９は、ハードウェアエンジン２２１が転送用エントリの指示に従って第１の受信側ＩＰルータ装置２１６へ転送処理を行うことになる（同図：ステップＳ４０２：Ｙ、ステップＳ４０３：Ｙ、ステップＳ４０４）。このようにして、第１の受信側ＩＰルータ装置２１６は、送られてくるその楽曲が組み込まれた一連のマルチキャストパケット２１９を第１の受信端末２１４に転送するようになっている。第１の受信端末２１４は、第１の受信側ＩＰルータ装置２１６から転送されてくる一連のマルチキャストパケット２１９を再生することで、その楽曲を聴くことができる。
【００４９】
以上説明したように、実施例のハードウェアエンジン２２１は、送信側ＩＰルータ装置２１３がハードウェア管理テーブル２２５に廃棄用エントリを登録することで、一連のマルチキャストパケット２１９の廃棄処理を行うようになっている。このハードウェア管理テーブル２２５への廃棄用エントリの登録は、図示しない制御部が制御して行うようになっているが、ハードウェアエンジン２２１が廃棄処理を開始すると、図示しない制御部は一連のマルチキャストパケット廃棄処理に関わらないため負荷を軽減することができる。このように、ハードウェアで転送あるいは廃棄を行えるまでの間だけ、受信した一連のマルチキャストパケット２１９のＩＰヘッダの解析および転送あるいは廃棄をソフトウェアに従った図示しない制御部が行うことで、すべてをこの制御部が行う場合と比較して処理の負荷を下げることができる。また、ハードウェアエンジン２２１にＩＰパケットの廃棄処理に最適化された回路を用いることで、廃棄処理の最適化を図ることができる。
【００５０】
また、実施例では送信側ＩＰルータ装置２１３のハードウェア管理テーブル２２５に廃棄用エントリを登録するために、配信先の無いマルチキャストパケット２１９をＩＰフォワーディング処理部２２２で少なくとも１つは廃棄する必要があった。しかし、配信が予定されている特定のマルチキャストパケット２１９に対して、配信開始時に配信先となる受信端末が無いことがＰＩＭ−ＳＭ処理部２２７等によって確認されている場合、これに対する廃棄用エントリを予めハードウェア管理テーブル２２５に登録しておいてもよい。こうすることで、配信開始時にＩＰフォワーディング処理部２２２で廃棄するマルチキャストパケット２１９の数を低減させて、送信側ＩＰルータ装置２１３の図示しない制御部の行うＩＰフォワーディング処理部２２２の処理の負荷を軽減することができる。
【００５１】
更に実施例では、マルチキャスト送信するデータをストリーム系データとしたが、同一のマルチキャストアドレスが組み込まれた一連のＩＰパケットであれば、これらにそれぞれ組み込まれるデータに関連性が無くてもよい。また、ストリーム系データは音楽だけではなく音声や動画等のデータあるいはこれらが組み合わされたデータであってもよい。
【００５２】
発明の変形の可能性
【００５３】
以上説明した実施例では、送信端末２１２では受信端末が存在することを前提としてマルチキャストパケットを作成し送信している。しかし、本発明は送信者が送信するマルチキャストパケットに対して受信端末の存在する可能性が無い、あるいは著しく低い場合に対しても同様に適用できる。このような一例として、たとえばＩＰルータ装置の機能低下あるいは機能停止を意図して、受信者の存在しないマルチキャストパケットを大量に送信するＤｏＳ（denial of service）攻撃が考えられる。このような一連のマルチキャストパケットに対しても廃棄用エントリを作成できる実施例で示したＩＰルータ装置を使用することで、会員等の特定の受信端末以外の端末を宛先とした継続的に発生するパケットとして廃棄処理を行わせることができ、特定の受信端末への影響を排除することができる。もちろん、ＩＰルータ装置等のパケット転送装置も廃棄のための専用のハードウェアあるいはソフトウェアの装置が廃棄の処理を行うので、装置本体部分あるいは制御部への影響を最低限に止めることができる。
【００５４】
【発明の効果】
以上説明したように請求項１記載の発明によれば、パケット廃棄回路を廃棄専用の回路で構成することで、転送装置の他の回路部分に対する影響を排除することができる。また、登録手段に登録した後は不要な宛先の特定パケットが特別の処理を行うことなくパケット廃棄回路に受け渡され廃棄されるので、パケット転送装置の制御部分における負荷の軽減を実現することができ、特にストリーム系データの場合に顕著な効果を持つことができる。
【００５５】
また、請求項２記載の発明によれば、パケット廃棄回路を廃棄専用の回路で構成することで、転送装置の他の回路部分に対する影響を排除することができる。また、ルータ等のパケット転送装置が受信不要情報記憶手段を備え、これで判別した結果を基にして受信端末処理経路選択手段でパケットを廃棄するか否かの振り分けを行っている。したがって、廃棄することがこの時点で判別されたパケットは直ちに廃棄処理されることになり、廃棄処理のための負担が少なくなるだけでなく、不正なパケットが同一の宛先に対して連続的に送られてくるような場合にも受信不要情報記憶手段にこれを加えるだけで迅速な対応が可能になる。
【００５６】
また、請求項３記載の発明によれば、廃棄すべき対象ともされず、また積極的に受信端末へ転送するものともされないようなパケットを対象にした処理が可能になる。したがって、たとえば受信者に対してストリーム系データの受信の開始から一定時間以内を検討期間に設定し、この間に受信の継続の希望の有無を確認させるといったビジネスに対してもパケット転送装置の処理の負担を軽減させることができる。
【００５７】
更に請求項４記載の発明によれば、ただ一回だけ送信されるパケットについて廃棄の処理を簡略化することができるだけでなく、ストリーム系データの場合にも不要なパケットが受信対象者以外の端末に送られることがないので、これによる不都合を発生させることがない。
【図面の簡単な説明】
【図１】本発明の一実施例におけるＩＰルータ装置を備えたマルチキャスト・ネットワークの構成を表わしたブロック図である。
【図２】本実施例のＩＰルータ装置の構成を表わしたブロック図である。
【図３】本実施例におけるＩＰパケットのヘッダ情報のデータ構造を表わした説明図である。
【図４】本実施例で送信側ＩＰルータ装置が入力されたマルチキャストパケットに行う処理の流れ図である。
【図５】本実施例で送信側ＩＰルータ装置が受信側ＩＰルータ装置からＩＰパケットを受信した場合の処理の流れ図である。
【符号の説明】
２１０ 配信希望情報
２１２ 送信端末
２１３、５０２ 送信側ＩＰルータ装置
２１４ 第１の受信端末
２１５ 第２の受信端末
２１６ 第１の受信側ＩＰルータ装置
２１７ 第２の受信側ＩＰルータ装置
２１８ ライブラリ
２２１ ハードウェアエンジン
２２２ ＩＰフォワーディング処理部
２２３ ハードウェアドライバ
２２４ プロトコルスタック処理部
２２５ ハードウェア管理テーブル
２２６ マルチキャスト・フォワーディング・エントリ
２２７ ＰＩＭ−ＳＭ処理部
２２７Ｔ エントリテーブル
【発明の属する技術分野】
本発明は受信したパケットを転送あるいは廃棄する処理を行うパケット転送装置に係わり、特にストリーム系データの転送に有効なパケット転送装置に関する。
【０００２】
【従来の技術】
比較的大容量のデータの通信を可能にしたネットワークの構築やインターネットへの常時接続等の通信環境の変化によって、音声や動画等のストリーム系データを複数のホスト側のコンピュータに送信するサービスが提供され始めている。特にマルチキャスト通信を利用すると、１つの端末から多くの端末にあたかも放送局が音や映像を送信するような放送型通信サービスを実現することができる。
【０００３】
ところで現在行われているマルチキャスト通信の多くは、ＵＤＰを用いて実現されている。ＵＤＰとは、送信者が送り出すパケットに対して、これを受信する受信者から受信したことに対応する返答を受け取らないプロトコルである。ＵＤＰを用いて送り出された一連のマルチキャストパケットは、ＩＰルータのようなパケット転送装置に収容された後複数の受信者に向けて転送されていくことになる。
【０００４】
現在多くのパケット転送装置では、受信したパケットに対するルーティング処理および転送処理はその制御プログラム（ソフトウェア）に従ってＣＰＵ（中央演算処理装置）等の汎用的な制御部が行うことにより実現されている。ルーティング処理は受信したパケットのヘッダを解析して転送経路を選択する処理であり、転送処理はルーティング処理で選択された転送経路に受信したパケットを転送する処理である。したがって、パケット転送装置は、ストリーム系データについての転送処理を行う場合にマルチキャストパケットを受信するたびにルーティング処理と転送処理を繰り返し行う必要がある。
【０００５】
【発明が解決しようとする課題】
ところでマルチキャストパケットの送信者と末端の受信者との間に位置する任意のパケット転送装置に着目すると、このパケット転送装置はマルチキャスト通信の受信者が存在しない経路に対して受信したマルチキャストパケットを廃棄する必要がある。一方、上流側のマルチキャストパケットの送信者あるいはパケット転送装置はＵＤＰを用いている関係で個々の受信者がパケットを要求していない場合でもその旨のパケットに対する返答をもらっていない。このため、これらの者は今回着目しているパケット転送装置に向けてパケットを送信し続けることになる。この結果、ストリーム系データについての転送処理を行う場合に、パケット転送装置はマルチキャストパケットを受信するたびに転送先の各経路に対してそのパケットを廃棄するか否かを個々に判別し、廃棄する場合にはその処理を行うことになる。
【０００６】
このような廃棄に関する処理は従来からパケット転送装置の前記した制御部が制御プログラムあるいはソフトウェアで行っていた。このため、通常のパケットでは廃棄に関する処理の負担が少ないものの、ストリーム系データでは受信を希望しない受信者に対してその一連のパケットの送信が終了するまで転送先の経路を確認しては廃棄するといった処理がパケット単位で連続することになる。したがって、パケット転送装置の制御部の負荷が大きくなるという問題があった。
【０００７】
そこで本発明の目的は、受信したパケットについて廃棄までの処理を簡略化して処理の負荷を軽減することのできるパケット転送装置を提供することにある。
【０００８】
【課題を解決するための手段】
請求項１記載の発明では、（イ）パケットを廃棄する処理を専用で行うパケット廃棄回路を備えた第１の装置と、（ロ）特定パケットを受信する可能性のあるそれぞれの受信端末からその特定パケットの受信を希望するか否かを確認する特定パケット受信希望有無確認手段と、この受信希望有無確認手段によって受信を希望しないと判別された受信端末あるいはその特定パケットの受信を希望しない受信端末がすべてであるパケット転送側の経路を判別する転送側経路判別手段と、この転送側経路判別手段の判別結果を登録する登録手段と、パケットを宛先に転送するパケット転送手段と、特定パケットを受信する特定パケット受信手段と、この特定パケット受信手段が特定パケットを受信したとき登録手段を参照して受信を希望しないと判別された受信端末あるいはその特定パケットの受信を希望しない受信端末がすべてである経路を宛先とする特定パケットを第１の装置のパケット廃棄回路に受け渡す一方、特定パケットの受信を希望する受信端末あるいはその特定パケットの受信を希望する受信端末の存在する経路を宛先とする特定パケットをパケット転送手段に受け渡すパケット受け渡し手段とを備えた第２の装置とをパケット転送装置に具備させる。
【０００９】
すなわち請求項１記載の発明では、パケット転送装置をパケットを廃棄する処理を専用で行うパケット廃棄回路を備えた第１の装置と、これ以外の第２の装置で構成する。ここで第１の装置は、パケット廃棄回路を備えた廃棄専用の回路で構成しているので、転送装置の他の回路部分に対する影響を排除することができる。パケット廃棄回路は、パケット廃棄専用のハードウェアであってもよいし、専用のＣＰＵ等を備えたソフトウェアで構成されていてもよい。第２の装置では、特定パケット受信希望有無確認手段がたとえばストリーム系データ等を構成する特定パケットを受信する可能性のあるそれぞれの受信端末からその特定パケットの受信を希望するか否かを確認するようにしている。そして、転送側経路判別手段がこの受信希望有無確認手段によって受信を希望しないと判別された受信端末あるいはその特定パケットの受信を希望しない受信端末がすべてであるパケット転送側の経路を判別し、登録手段がこの転送側経路判別手段の判別結果を登録するようにしている。したがって、特定パケット受信手段が特定パケットを受信したとき、登録手段を参照して、受信を希望しないと判別された受信端末あるいはその特定パケットの受信を希望しない受信端末がすべてである経路を宛先とする特定パケットについてはパケット廃棄回路に受け渡してその転送先についてこの特定パケットが存在する限り廃棄させる。このように、登録手段に登録した後は不要な宛先の特定パケットが特別の処理を行うことなくパケット廃棄回路に受け渡され廃棄されるので、パケット転送装置の制御部分における負荷の軽減を実現することができる。
【００１０】
請求項２記載の発明では、（イ）パケットを廃棄する処理を専用で行うパケット廃棄回路を備えた第１の装置と、（ロ）特定の複数の受信端末のいずれかあるいはそれに至る経路を宛先としたパケットを受信するパケット受信手段と、特定の複数の受信端末あるいはそれらに至る経路のうち特定パケットの受信を希望しない受信端末あるいは特定パケットの受信を希望しない受信端末がすべてである経路をこれ以外の受信端末あるいは経路から区別する受信不要情報を記憶する受信不要情報記憶手段と、パケットを宛先に転送するパケット転送手段と、特定の複数の受信端末に対してこれらが特定パケットの受信を希望していないか否かあるいは所定の経路を経たすべての受信端末が特定パケットの受信を希望していないか否かを確認する受信希望有無確認手段と、この受信希望有無確認手段の確認結果を基にした受信不要情報を受信不要情報記憶手段に登録する受信不要情報登録手段と、パケット受信手段が特定パケットを受信したときその転送の必要の有無を受信不要情報登録手段の登録した受信不要情報によって判別し、受信を希望する受信端末の存在しない経路あるいは受信を希望しない受信端末を直接の宛先とした特定パケットを第１の装置のパケット廃棄回路に受け渡す一方、受信を希望する受信端末の存在する経路あるいは受信を希望する受信端末を直接の宛先とした特定パケットをパケット転送手段に受け渡す受信端末処理経路選択手段とを備えた第２の装置とをパケット転送装置に具備させる。
【００１１】
すなわち請求項２記載の発明では、パケット転送装置をパケットを廃棄する処理を専用で行うパケット廃棄回路を備えた第１の装置と、これ以外の第２の装置で構成する。ここで第１の装置は、パケット廃棄回路を備えた廃棄専用の回路で構成しているので、転送装置の他の回路部分に対する影響を排除することができる。パケット廃棄回路は、パケット廃棄専用のハードウェアであってもよいし、専用のＣＰＵ等を備えたソフトウェアで構成されていてもよい。第２の装置では、パケット受信手段が予め特定された複数の受信端末のいずれかあるいはそれに至る経路を宛先としたパケットを受信するようになっている。たとえばストリーム系データの配信が行われる場合を例にとると、それぞれのストリーム系データの受信を行う契約を行った特定の会員がここでいう特定の複数の受信端末に対応する。これらの受信端末を宛先としただけでなくそれに至る経路を宛先としたパケットを含めたのは、個々の受信端末を直接の宛先としない場合にも対応させたものである。本発明では受信不要情報記憶手段が設けられており、たとえば、これら特定の受信端末でパケットの受信を希望しない者、あるいはパケットの受信を希望しない受信端末がすべてである経路がこの受信不要情報記憶手段に受信不要情報として記憶されるようになっている。受信を希望する者としない者の２者択一の場合には、受信を希望する者やその経路を記憶してもよい。これに属さないものとして受信を希望しない者や経路が特定されるからである。パケット転送装置の受信したパケットは受信端末処理経路選択手段でその処理経路を選択されるが、このとき受信不要情報登録手段の登録した受信不要情報がチェックされる。したがって、廃棄するパケットかどうかを受信時に簡単に判別することができ、廃棄する場合には処理を後の回路部分に任せることなく、パケットを廃棄する専用のパケット廃棄回路に渡して、ここでパケットの廃棄処理を行わせることができる。すなわち、ストリーム系データのように宛先が同一のパケットが連続して送られてくるような場合には、ある時点でその宛先のパケットが不要であることを受信不要情報記憶手段に記憶してしまえば、受信したパケットのうちの該当するパケットは直ちにパケット廃棄回路に渡されて処理されることになる。このように請求項２記載の発明では、特定された複数の受信端末に関する受信不要情報を記憶し照合できるようにしておくことで、受信を希望する受信端末の存在しない経路あるいは受信を希望しない受信端末を直接の宛先とした特定パケットをパケット廃棄回路で廃棄させることを可能にし、パケット転送装置の制御部分における負荷の軽減を実現している。
【００１２】
請求項３記載の発明では、請求項２記載のパケット転送装置で、受信端末処理経路選択手段は、受信を希望する受信端末の存在しない経路あるいは受信を希望しない受信端末を直接の宛先とした特定パケット、あるいは受信を希望する受信端末の存在する経路あるいは受信を希望する受信端末を直接の宛先とした特定パケット以外の特定パケットが存在するときこれを受信希望有無確認手段に確認させることを特徴としている。
【００１３】
すなわち請求項３記載の発明では、受信した特定パケットが受信不要情報記憶手段の記憶内容からでは廃棄すべき対象ともされず、また積極的に受信端末へ転送する対象ともされないようなものの場合の扱いを示している。このような特定パケットについては、受信端末処理経路選択手段が受信希望有無確認手段に確認させる。したがって、確認結果としてその受信端末あるいは経路の特定パケットが廃棄されるものとなれば、受信不要情報として登録されるので、次からはその特定パケットの選別とパケット廃棄手段による廃棄とが特別の負担なく行われるようになる。なお、確認の結果としてその特定パケットが受信端末の予定していないようなパケットである場合がある。たとえば特定の複数の受信端末が前記したストリーム系データの会員の端末であるような場合で、ストリーム系データの送出側と偽って妨害用の特定パケットを連続して受信端末に送りつけるような第三者がいるような場合である。このような場合には、これらの受信端末がその特定パケットの受信を希望していないとすることで、それ以後のその特定パケットを専用の廃棄手段で処理させることができる。したがって、このような特定パケットの廃棄処理を専用の回路あるいはハードウェアで行わせることで、パケット転送装置の本来的な制御に与える影響を最小限とすることができる。
【００１４】
請求項４記載の発明では、請求項２記載のパケット転送装置で、受信不要情報登録手段は、特定の複数の受信端末のいずれかあるいはそれに至る経路に向けて特定パケットの送信が開始される時間が予め定められているとき、この特定パケットがパケット受信手段によって受信される前に受信希望有無確認手段によって確認された確認結果を受信不要情報記憶手段に登録することを特徴としている。
【００１５】
すなわち請求項４記載の発明では、特定パケットの送信が開始される時間が予め定められているとき、この特定パケットを受信する前に受信不要情報を受信不要情報記憶手段に登録する場合を扱っている。このようなことが可能な通信システムでは、ストリーム系のデータあるいはこのようなコンテンツに限らず、極端な場合にはただ一回だけ送信される特定パケットについても廃棄の処理を簡略化させることがでることになる。
【００１６】
請求項５記載の発明では、請求項２記載のパケット転送装置で、受信希望有無確認手段は、特定パケットの送信が開始された後に特定の複数の受信端末のいずれかが受信を希望するか否かについての変更を生じさせたときこれを検出する変更検出手段を備えており、受信不要情報登録手段は変更検出手段の検出した変更を登録することを特徴としている。
【００１７】
すなわち請求項５記載の発明では、特定パケットの送信開始後に発生した特定の複数の受信端末の受信の希望の要否の変更を検出して、この検出した変更を受信不要情報記憶手段に登録するようになっている。これにより受信端末側の変更に基づく転送の必要の有無の判別に用いる受信不要情報に変更が発生する可能性を検出したとき、これに応じて受信不要情報を変更することができる。たとえば、パケット転送装置を介して一連の特定パケットを受信する受信端末が受信を希望しなくなれば、この変更を検出した後の受信不要情報を基に以降受信するこれらの特定パケットを直ちに廃棄させることができる。
【００１８】
請求項６記載の発明では、請求項２記載のパケット転送装置で、特定の複数の受信端末はストリーム系のコンテンツを構成する一連のパケットの受信をコンテンツごとに契約する契約者の備える端末であり、受信希望有無確認手段は、これらの受信端末の契約によるコンテンツごとの受信の希望の有無で特定パケットの受信の有無を確認することを特徴としている。
【００１９】
すなわち請求項６記載の発明では、請求項２に記載した特定の複数の受信端末と受信希望有無確認手段について１つの具体例を示したものである。受信端末は、ストリーム系のコンテンツを、コンテンツごとに契約して受信するようになっている。同じコンテンツに対して契約を行っている受信端末が特定のコンテンツを組み込んだ特定パケットを受信することになる。特定の複数の受信端末は、この場合、個々のコンテンツの契約を行いうる会員全体である。この例の場合、受信希望有無確認手段は、会員がどのコンテンツの受信を希望するかを確認する従来行われていた手法を用いたものである。たとえばケーブルテレビ局が個別の放送について受信希望者を確認していた手法を用い、これにより得られたデータを受信不要情報として受信不要情報記憶手段の記憶内容に反映させることになる。このような確認手段との連結で、特定パケット自体が受信端末に一方的に送られる形式のものであっても、受信不要情報を取得したり変更することが可能になる。
【００２２】
【発明の実施の形態】
【００２３】
【実施例】
以下実施例につき本発明を詳細に説明する。
【００２４】
図１は本発明の一実施例における、マルチキャスト通信で送信されるパケットを転送するためのパケット処理装置を備えたマルチキャスト・ネットワークの簡略化された例を表わしたものである。このマルチキャスト・ネットワーク２１１には、マルチキャストパケット送信者が使用する送信端末２１２と、これに隣接した送信側ＩＰ（Internet Protocol）ルータ装置２１３とが配置されている。また、マルチキャストパケット受信者が使用する第１の受信端末２１４および第２の受信端末２１５と、これらにそれぞれ隣接した第１の受信側ＩＰルータ装置２１６および第２の受信側ＩＰルータ装置２１７が配置されている。送信端末２１２には、送信するマルチキャストパケットに組み込むための各種ストリーム系データを収めたライブラリ２１８が接続されている。また、第１および第２の受信端末２１４、２１５には受信希望有無確認装置２２０が接続されている。受信希望有無確認装置２２０は、ライブラリ２１８を管理する会社とは別の組織である図示しない会社の中に、この例ではＣＡＴＶ（cable television）の配信局の中に、置かれている。そして、各受信端末２１４、２１５が特定の番組あるいはコンテンツの受信を希望するか否かを、従来から確立されている手法で、受信希望有無確認装置２２０側で確認できるようになっている。受信希望有無確認装置２２０の確認結果は、通常はこのＣＡＴＶの配信局の契約者に対する料金の徴収等の自社内の用途に使用する。本実施例では、受信希望有無確認装置２２０はこの確認結果を基にして、受信を希望しているコンテンツの配信に合わせて各受信端末２１４、２１５に配信希望情報２１０を送信するようになっている。配信希望情報２１０は、送信端末２１２からの配信を受けるための配信経路の作成を要求させるものと、配信経路の削除を要求させるものとがある。このＣＡＴＶの配信局は、この配信希望情報２１０を各受信端末２１４、２１５に送信することで、契約の行われたコンテンツを対応した受信端末に配信することを可能にしている。
【００２５】
なお、この図１で第１および第２の受信側ＩＰルータ装置２１６、２１７は、図示しない幾つかの受信端末とも接続され得るが、説明を簡略化するために本実施例ではこれらについて考えないものとする。また、この図では送信側ＩＰルータ装置２１３と第１および第２の受信側ＩＰルータ装置２１６、２１７を直結して示しているが、実際のネットワークではこれらの間にも幾つかのパケット転送装置としてのＩＰルータ装置が配置され得る。
【００２６】
さて、マルチキャスト・ネットワーク２１１では、各端末を識別するためのＩＰアドレスが割り振られていて、ＩＰパケットの送信を行う際の送信先や送信元を指定するために使用することができるようになっている。マルチキャストパケットには、送信先を示す情報としてマルチキャストアドレスが組み込まれるようになっている。マルチキャストアドレスは、特定のマルチキャストパケットを受信する複数の端末に割り振られているＩＰアドレスと対応付けるための特定のＩＰアドレスである。
【００２７】
マルチキャスト・ネットワーク２１１上の送信側ＩＰルータ装置２１３、第１の受信側ＩＰルータ装置２１６および第２の受信側ＩＰルータ装置２１７では、ＲＦＣ（Request For Comment）“２３６２”により定められているＰＩＭ−ＳＭ（Protocol Independent Multicast-Sparse Mode）が動作している。ＰＩＭ−ＳＭとは、ＩＰルータ装置間でのマルチキャスト配信用のルーティングプロトコルであり、マルチキャスト用の配信木を管理しているものとする。このマルチキャスト用の配信木は、ＰＩＭ−ＳＭが動作しているＩＰルータ装置が配置されている木構造になっており、各受信端末２１４、２１５等の受信端末は、配置されているいずれかのＩＰルータ装置に接続されるようになっている。このマルチキャスト用の配信木の頂点に配置されるＩＰルータ装置は、マルチキャストパケットを送信する送信端末２１２に隣接した送信側ＩＰルータ装置２１３である。また、各受信端末２１４、２１５等の受信端末が接続されている第１および第２の受信側ＩＰルータ装置２１６、２１７等のＩＰルータ装置は、上流に配置されている送信側ＩＰルータ装置２１３等のＩＰルータ装置に対して受信端末の代理を行うようになっている。これにより、本実施例のマルチキャスト用の配信木は、マルチキャストパケットの受信を要求する受信端末に隣接したＩＰルータ装置から、頂点のＩＰルータ装置に向けて作成されるようになっている。
【００２８】
このようなマルチキャスト・ネットワーク２１１は、前記したように、たとえば楽曲の著作権を持つ会社がこれらのデータを会員へ配信するサービスを提供する通信システムとして使用されている。一例を考えると、送信端末２１２とライブラリ２１８はある会社内のサービス部門に配置されており、送信端末２１２が、ライブラリ２１８内に保持されている楽曲のストリーム系データを組み込んだ一連のマルチキャストパケット２１９を作成するようになっている。ストリーム系データとは、再生の順に先頭から連続した複数のパケットデータを指しており、たとえば楽曲のストリーム系データの場合、これらのパケットをデータを先頭から再生することで楽曲を聴くことができるようになっている。送信側ＩＰルータ装置２１３は会社内の通信部門に配置されており、送信端末２１２が楽曲から作成した一連のマルチキャストパケット（ストリーム系データ）２１９を各受信端末に向けて送信するようになっている。また第１および第２の受信端末２１４、２１５は、会員の部屋に備えられたコンピュータなどの通信端末であり、受信した一連のマルチキャストパケット２１９から楽曲のストリーム系データを取り出して楽曲を再生できるようになっている。これら第１および第２の受信端末２１４、２１５の会員は、すでに説明したように同時にＣＡＴＶの配信局の契約者となっている。なお、これらの会員が接続契約を結んでいるプロバイダを利用しても同様のサービスが可能である。この場合、プロバイダは第１および第２の受信側ＩＰルータ装置２１６、２１７を用いて、受信したマルチキャストパケット２１９をそれぞれ対応した会員の通信端末へ送信することになる。
【００２９】
サービスを提供する会社は、たとえばライブラリ２１８に納められた楽曲の中で音楽のジャンルとしての「ポップス」と「ジャズ」から１曲ずつ提供するようになっており、この楽曲の受信を希望する会員へ送信するためのマルチキャスト配信木が作成されるようになっている。送信端末２１２から送信されるマルチキャストパケット２１９は、「ポップス」あるいは「ジャズ」の楽曲のストリーム系データが先頭から分割されて組み込まれた一連のＩＰパケットである。もっとも、会員の希望に応じてジャンルごとに配信木を別々に作成するようにすることも可能である。
【００３０】
図２は、図１で示したネットワークに配置されたＩＰルータ装置の構成を表わしたものである。ここでは、送信側ＩＰルータ装置２１３について説明するが、第１および第２の受信側ＩＰルータ装置２１６、２１７も同様の構成である。送信側ＩＰルータ装置２１３には、ＩＰパケットのハードウェア処理を行うハードウェアエンジン２２１と、ＩＰパケットのＩＰヘッダ解析および転送処理を行うＩＰフォワーディング（Forwarding）処理部２２２が備えられている。ハードウェアエンジン２２１およびＩＰフォワーディング処理部２２２は、それぞれハードウェアドライバ２２３に接続されており、これを中継して各種データのやりとりを行うようになっている。また、各種プロトコルが動作するプロトコルスタック処理部２２４が備えられていて、ＩＰフォワーディング処理部２２２と接続されている。更にハードウェアエンジン２２１が管理するハードウェア管理テーブル２２５と、ＩＰフォワーディング処理部２２２が管理するルーティングテーブルであるマルチキャスト・フォワーディング・エントリ２２６とが備えられている。このような送信側ＩＰルータ装置２１３に受信されたパケットは、まずハードウェアエンジン２２１に入力されるようになっている。
【００３１】
送信側ＩＰルータ装置２１３にはＣＰＵ（中央演算処理装置）やＲＯＭ（リード・オンリ・メモリ）等の記憶媒体を備えた図示しない制御部が配置されていて、この制御部が予め定められた所定のプログラムを実行することで、制御を行うようになっている。ただし、ハードウェアエンジン２２１については、この図示しない制御部に関わりなく予め定められた処理を行うハードウェアで構成されている。
【００３２】
ハードウェアエンジン２２１は、パケットが入力されるたびにこのパケットに対応した転送用エントリあるいは廃棄用エントリが登録されているかハードウェア管理テーブル２２５を検索するようになっている。転送用エントリあるいは廃棄用エントリには、それぞれＩＰパケットのヘッダ情報に対応した送信元アドレス、送信先アドレス、プロトコル番号、送信元ポート番号、送信先ポート番号が格納されている。ハードウェアエンジン２２１は、エントリに格納されているこれらの情報が受信したＩＰパケットのヘッダ情報と一致した場合、受信したＩＰパケットとエントリが一致すると判別するようになっている。これによって一致したエントリが転送用エントリである場合はこのパケットの転送処理を行い、廃棄用エントリである場合はこのパケットの廃棄処理を行うようになっている。転送用エントリには転送処理に必要な情報も格納されており、これを用いてハードウェアエンジン２２１は転送処理を行うようになっている。また、ここでヘッダ情報がエントリと一致しない場合は、入力されたＩＰパケットをハードウェアドライバ２２３を介してＩＰフォワーディング処理部２２２へ出力するようになっている。
【００３３】
プロトコルスタック処理部２２４は、マルチキャストプロトコルであるＰＩＭ−ＳＭに従って動的なマルチキャスト用の配信木を管理するＰＩＭ−ＳＭ処理部２２７を備えている。またＰＩＭ−ＳＭ処理部２２７は、ＩＰヘッダ情報２２８をＩＰフォワーディング処理部２２２から受信するようになっている。このＰＩＭ−ＳＭ処理部２２７は検索対象となるエントリを保持するエントリテーブル２２７Ｔを備えている。このエントリには、ＩＰパケットのヘッダ情報に対応した送信先アドレスと、この送信先アドレスが組み込まれたマルチキャストパケットのマルチキャスト用の配信木で、この送信側ＩＰルータ装置２１３の直下となるＩＰルータ装置あるいは受信端末を示す情報が組み込まれるようになっている。送信側ＩＰルータ装置２１３の図示しない制御部は、エントリテーブル２２７Ｔを検索して、エントリに格納されている送信先アドレスが受信したＩＰパケットのヘッダ情報と一致した場合、このＩＰパケットとエントリが一致すると判別するようになっている。
【００３４】
マルチキャスト・フォワーディング・エントリ２２６は、ＩＰフォワーディング処理部２２２が受信したＩＰパケットのヘッダ情報で検索する検索対象であるエントリを管理するようになっている。このエントリには、ＩＰパケットのヘッダ情報に対応した送信元アドレスと送信先アドレス、またＩＰパケットを次の転送先へ送り出すために必要な情報として送信側ＩＰルータ装置２１３の図示しない出力ポートを示す情報などが組み込まれている。この次の転送先へ送り出すために必要な情報は、エントリテーブル２２７Ｔのエントリに対応してマルチキャスト配信木で直下のＩＰルータ装置あるいは受信端末に向けてパケットを出力するための情報を表わすものである。したがって、マルチキャスト配信木上には存在しない中継装置などが、次の転送先として指定される場合もある。送信側ＩＰルータ装置２１３の図示しない制御部は、エントリに格納されている送信元アドレスおよび送信先アドレスが受信したＩＰパケットのヘッダ情報と一致した場合、このＩＰパケットとエントリが一致すると判別するようになっている。
【００３５】
ＩＰフォワーディング処理部２２２は、廃棄用エントリの登録あるいは削除を要求する廃棄用エントリ登録・削除要求２２９をハードウェアドライバ２２３へ送信することになる。ハードウェアドライバ２２３は廃棄用エントリ登録・削除要求２２９を受信すると廃棄用エントリ登録・削除要求２２９をハードウェアエンジン２２１への命令である廃棄用エントリ登録・削除要求２３０に変換して、ハードウェアエンジン２２１へ送るようになっている。
【００３６】
図３は、本実施例でマルチキャスト転送を行うＩＰパケットのヘッダ情報のデータ構成を表わしたものである。ヘッダ情報３０１はＩＰヘッダ情報とＵＤＰ（User Datagram Protocol）ヘッダ情報を合わせたものを指している。ＵＤＰヘッダ情報には、本実施例のマルチキャスト転送を行う際、ＩＰプロトコルの上位のプロトコルとなるＵＤＰプロトコルの情報が格納されるようになっている。一般的にＵＤＰプロトコルを用いてマルチキャスト転送を行う際には、このＩＰパケットを受信する第１あるいは第２の受信端末２１４、２１５と送信端末２１２は直接このＩＰパケットに関する信号のやり取りを行わないようになっている。これは、送信端末から多数の受信端末にマルチキャストパケットを送信する場合に個々の受信端末と送信するＩＰパケットについての信号のやり取りを行うことは、送信端末に対する負荷が大きくなるためである。
【００３７】
ＩＰヘッダ情報は、インターネットプロトコルのバージョンを示すバージョン３０２と、ＩＰヘッダの長さを示すヘッダ長３０３と、ＩＰパケットの品質要求を示すサービスタイプ３０４と、ＩＰパケットの長さを示すパケット長３０５と、ＩＰパケットに分割して格納したデータの復元に使用する識別子３０６と、このＩＰパケットが分割されたデータの最初、中間あるいは末尾のどれにあたるかを示すフラグ３０７と、このＩＰパケットが分割された順番を示すフラグメントオフセット３０８と、ネットワーク上での生存時間を示す生存時間３０９と、ＩＰパケットに格納されたデータのプロトコルを示すプロトコル番号３１０と、誤りを検出するために用いるヘッダチェックサム３１１と、送信元のＩＰアドレスを示す送信元アドレス３１２および送信先のＩＰアドレスを示す送信先アドレス３１３で構成されている。図１で説明した送信端末２１２から送信されるマルチキャストパケット２１９には、特定のマルチキャストアドレスが、このヘッダ情報３０１の送信先アドレス３１３として組み込まれている。
【００３８】
次に同じく図３を用いてＵＤＰヘッダ情報のデータ構成について説明する。ＵＤＰヘッダ情報は、送信元装置から出力する際の出力ポートを示す送信元ポート番号３１４と、送信先装置が受信する際の入力ポートを示す送信先ポート番号３１５と、ＵＤＰパケットの長さを示すセグメント長３１６およびＵＤＰパケットの誤りを検出するために用いるチェックサム３１７で構成されている。ここでＵＤＰパケットとは、マルチキャスト転送するデータの先頭にＵＤＰヘッダ情報を付加したものを指していて、更にこの先頭にＩＰパケットのヘッダ情報を付加することで、ＩＰパケットとなるようになっている。
【００３９】
図４は、図２に示した送信側ＩＰルータ装置がマルチキャストパケットを受信したときの処理の流れと各種エントリの作成順序について表わしたものである。ただし、エントリテーブル２２７Ｔに格納されるエントリについては後で説明を行うものとする。送信側ＩＰルータ装置２１３が受信したマルチキャストパケット２１９は、ハードウェアエンジン２２１に入力されるようになっている。ここでハードウェアエンジン２２１は、受信したマルチキャストパケット２１９のヘッダ情報３０１を用いて、ハードウェア管理テーブル２２５を検索する（ステップＳ４０１）。ここでヘッダ情報３０１がエントリと一致した場合には（ステップＳ４０２：Ｙ）、更にこの一致したエントリが転送用エントリであるか否か判別する（ステップＳ４０３）。転送用エントリであった場合には（Ｙ）、ハードウェアエンジン２２１は転送用エントリの指示に従った転送処理を実施して（ステップＳ４０４）、処理を終了する（エンド）。また転送用エントリではない場合（ステップＳ４０３：Ｎ）、廃棄用エントリに一致したとみなして、ハードウェアエンジン２２１は廃棄処理を実施し（ステップＳ４０５）、処理を終了する（エンド）。ステップＳ４０２でエントリに一致しなかった場合には（Ｎ）、受信したマルチキャストパケット２１９をハードウェアドライバ２２３経由でＩＰフォワーディング処理部２２２に出力する。
【００４０】
送信側ＩＰルータ装置２１３の図示しない制御部は、ＩＰフォワーディング処理部２２２に入力されたマルチキャストパケット２１９のヘッダ情報３０１を用いて、マルチキャスト・フォワーディング・エントリ２２６を検索する（ステップＳ４０６）。ヘッダ情報３０１の送信元アドレス３１２および送信先アドレス３１３がエントリの検索対象の情報と一致した場合には（ステップＳ４０７：Ｙ）、図示しない制御部が一致したエントリを基にしてハードウェアドライバ２２３に転送エントリ登録要求を通知し、ハードウェア管理テーブル２２５への転送エントリの登録を実施する（ステップＳ４０８）。この後、マルチキャスト・フォワーディング・エントリ２２６の一致したエントリに従ったマルチキャストパケット２１９の転送処理を実施して（ステップＳ４０９）、処理を終了する（エンド）。
【００４１】
ステップＳ４０７でヘッダ情報３０１がエントリと一致しない場合には（Ｎ）、図示しない制御部はＰＩＭ−ＳＭ処理部２２７が管理するエントリテーブル２２７Ｔを更にヘッダ情報３０１で検索する（ステップＳ４１０）。ここで一致するエントリが存在した場合には（ステップＳ４１１：Ｙ）、マルチキャスト・フォワーディング・エントリ２２６に該当するマルチキャスト転送用のエントリの登録を実施する（ステップＳ４１２）。この後、ハードウェア管理テーブル２２５への転送エントリの登録とマルチキャストパケット２１９の転送処理を実施して（ステップＳ４０８、４０９）、処理を終了する（エンド）。ステップＳ４１１で一致するエントリが存在しない場合には（Ｎ）、ヘッダ情報３０１を付加した廃棄用エントリ作成要求をハードウェアドライバ２２３へ通知し、ハードウェア管理テーブル２２５への廃棄用エントリの登録を実施する（ステップＳ４１３）。この後、マルチキャストパケット２１９の廃棄処理を実施して（ステップＳ４１４）、処理を終了する（エンド）。
【００４２】
このような処理で、たとえばある「ジャズ」の楽曲が組み込まれた一連のマルチキャストパケット２１９に受信を希望する受信端末がない場合、この楽曲を配信するためのマルチキャスト配信木は作成されず、エントリテーブル２２７Ｔにもエントリは存在しない。これらが受信されるとハードウェア管理テーブル２２５へこれらを廃棄するように指示する廃棄用エントリが登録されるまでは、ＩＰフォワーディング処理部２２２に入力された後廃棄されるようになっている。しかし、ハードウェア管理テーブル２２５へこの楽曲のマルチキャストパケット２１９の廃棄を指示する廃棄用エントリが登録された後は、ハードウェアエンジン２２１によって廃棄されるようになる。したがって、ある楽曲のストリーム系データが組み込まれた一連のマルチキャストパケット２１９を連続して廃棄する場合、ハードウェア管理テーブル２２５に廃棄用エントリが登録された後は、送信側ＩＰルータ装置２１２のＩＰフォワーディング処理部２２２に廃棄処理による負荷を与えない。したがって、一連のマルチキャストパケット２１９の中で最初に受信したファーストパケットのＩＰヘッダ解析および転送あるいは廃棄をＩＰフォワーディング処理部２２２で行い、これに対応した廃棄用エントリの登録以降受信するマルチキャストパケット２１９の転送あるいは廃棄をハードウェアエンジン２２１で行うことで、送信側ＩＰルータ装置２１２の図示しない制御部の処理の負荷を軽減することができる。
【００４３】
図５は、ＰＩＭ−ＳＭ処理部２２７宛の特定のマルチキャストパケットに対しての受信要求あるいは受信停止要求が組み込まれたＩＰパケットが、ＩＰルータ装置２１３に受信された場合の処理の流れを表わしたものである。ＩＰルータ装置２１３の図示しない制御部は、受信したＩＰパケットがＰＩＭ−ＳＭ処理部２２７宛のＩＰパケットであるときマルチキャストアドレスによって特定される一連のマルチキャストパケットの受信要求あるいは受信停止を示す情報であるか否かを判別する（ステップＳ４２１）。これ以外の場合には（Ｎ）、処理を終了する（エンド）。受信要求あるいは受信停止を示す情報が組み込まれていた場合（ステップＳ４２１：Ｙ）、これが受信要求を示していれば（ステップＳ４２２：Ｙ）、この特定される一連のマルチキャストパケットの送信先を示すエントリがＰＩＭ−ＳＭ処理部２２７のエントリテーブル２２７Ｔに存在するか判別する（ステップＳ４２３）。該当するエントリが存在する場合（Ｙ）、この受信要求を送信してきた受信端末を送信先に追加するエントリの変更を行う（ステップＳ４２４）。この変更に伴ってマルチキャスト・フォワーディング・エントリ２２６に登録されているマルチキャスト転送用のエントリも変更する。この後、この特定される一連のマルチキャストパケットの転送を指示する転送用エントリのハードウェア管理テーブル２２５からの削除を要求する転送用エントリ削除要求を作成する（ステップＳ４２５）。作成された転送用エントリ削除要求は、ＩＰフォワーディング処理部２２２経由でハードウェアドライバ２２３に送信して（ステップＳ４２６）処理を終了する（エンド）。ハードウェアドライバ２２３はこの転送用エントリ削除要求をハードウェアエンジン２２１に渡して、該当する転送用エントリをハードウェア管理テーブル２２５から削除させるようになっている。
【００４４】
また、該当するエントリがＰＩＭ−ＳＭ処理部２２７のエントリテーブル２２７Ｔに存在しない場合（ステップＳ４２３：Ｎ）、この特定される一連のマルチキャストパケットの転送先を示すためのエントリを作成し、このエントリテーブル２２７Ｔに登録する（ステップＳ４２７）。この後、これらマルチキャストパケットの廃棄を指示する廃棄用エントリのハードウェア管理テーブル２２５からの削除を要求する廃棄用エントリ削除要求を作成する（ステップＳ４２８）。作成された廃棄用エントリ削除要求は、ＩＰフォワーディング処理部２２２経由でハードウェアドライバ２２３に送信して（ステップＳ４２９）処理を終了する（エンド）。ハードウェアドライバ２２３はこの転送用エントリ削除要求をハードウェアエンジン２２１に渡して、該当する転送用エントリをハードウェア管理テーブル２２５から削除させるようになっている。
【００４５】
更に、受信停止を示す情報が組み込まれていた場合（ステップＳ４２２：Ｎ）、該当するエントリがＰＩＭ−ＳＭ処理部２２７の図示しないエントリテーブル２２７Ｔに存在しなければ（ステップＳ４３０：Ｎ）、処理を終了する（エンド）。これは、これまで送信先の無かったマルチキャストパケットに対して受信停止が要求された場合であり、行うべき処理は存在しない。該当するエントリがこのエントリテーブル２２７Ｔに存在する場合には（ステップＳ４３０：Ｙ）、この受信停止を送信してきた受信端末をエントリの送信先から削除する変更を行う。この結果送信先が存在しなくなった場合には、この特定される一連のマルチキャストパケットの送信先を示すエントリ自体の削除を行う（ステップＳ４３１）。この変更に伴ってマルチキャスト・フォワーディング・エントリ２２６に登録されているマルチキャスト転送用のエントリも変更あるいは削除する。この後、このマルチキャストパケットの転送を指示する転送用エントリのハードウェア管理テーブル２２５からの削除を要求する転送用エントリ削除要求を作成する（ステップＳ４３２）。作成された転送用エントリ削除要求は、ＩＰフォワーディング処理部２２２経由でハードウェアドライバ２２３に送信して（ステップＳ４３３）処理を終了する（エンド）。ハードウェアドライバ２２３はこの転送用エントリ削除要求をハードウェアエンジン２２１に渡して、該当する転送用エントリをハードウェア管理テーブル２２５から削除させるようになっている。
【００４６】
さて、ハードウェアエンジン２２１によって廃棄処理が行われている楽曲のストリーム系データが組み込まれた一連のマルチキャストパケット２１９に受信希望者が現れた場合は、廃棄処理を停止して、受信希望者への送信を再開する必要がある。この一例として、その楽曲が組み込まれた一連のマルチキャストパケット２１９の配信経路の作成を要求させる配信希望情報２１０を受信希望有無確認装置２２０から第１の受信端末２１４に送信したときの、第１の受信端末２１４、第１の受信側ＩＰルータ装置２１６および送信側ＩＰルータ装置２１３の処理について説明する。
【００４７】
第１の受信端末２１４は、その楽曲が組み込まれた一連のマルチキャストパケット２１９の配信経路の作成を要求させる配信希望情報２１０を受け取ると、これに対応してその楽曲が組み込まれた一連のマルチキャストパケット２１９の受信を要求する受信要求を組み込んだパケットを作成して、第１の受信側ＩＰルータ装置２１６に送信する。第１の受信側ＩＰルータ装置２１６はこのとき、既にハードウェアエンジン２２１によってＩＰパケットの廃棄処理が行われているので、ＰＩＭ−ＳＭ処理部２２７の図示しないエントリテーブル２２７Ｔにその楽曲が組み込まれた一連のマルチキャストパケット２１９に対するエントリは存在しない（図５：ステップＳ４２３：Ｎ）。従って、このようなＩＰパケットを受信するとマルチキャストパケット２１９に組み込まれるマルチキャストアドレスとこの送信先として第１の受信端末２１４を示すエントリを作成して、このエントリテーブル２２７Ｔに登録する（同図：ステップＳ４２７）。この後、この楽曲が組み込まれた一連のマルチキャストパケット２１９の廃棄を指示する廃棄用エントリのハードウェア管理テーブル２２５からの削除を要求するようになっている（同図：ステップＳ４２８、ステップＳ４２９）。また、第１の受信側ＩＰルータ装置２１６は、その楽曲が組み込まれた一連のマルチキャストパケット２１９の受信を要求する受信要求を組み込んだＩＰパケットを、送信側ＩＰルータ装置２１３に送信する。送信側ＩＰルータ装置２１３はこのＩＰパケットを受信すると、エントリテーブル２２７Ｔに送信先として第１の受信側ＩＰルータ装置２１６を示すエントリを登録し、ハードウェア管理テーブル２２５からの廃棄用エントリの削除を要求する。
【００４８】
送信側ＩＰルータ装置２１３のハードウェア管理テーブル２２５から廃棄用エントリが削除された後は、その楽曲が組み込まれた一連のマルチキャストパケット２１９を受信しても、廃棄処理は実施されないようになる（図４：ステップＳ４０２：Ｎ）。また、この受信したマルチキャストパケット２１９は、ＰＩＭ−ＳＭ処理部２２７の図示しないエントリテーブル２２７Ｔが管理するエントリで、一致するエントリが存在する（同図：ステップＳ４１０、ステップＳ４１１：Ｙ）。そこで、マルチキャスト・フォワーディング・エントリ２２６とハードウェア管理テーブル２２５にそれぞれ対応するエントリと転送用エントリの登録が実施された後（同図：ステップＳ４１２、ステップＳ４０８）、第１の受信側ＩＰルータ装置２１６の転送処理が図示しない制御部によって行われる（同図：ステップＳ４０９）。以降受信されるその楽曲が組み込まれた一連のマルチキャストパケット２１９は、ハードウェアエンジン２２１が転送用エントリの指示に従って第１の受信側ＩＰルータ装置２１６へ転送処理を行うことになる（同図：ステップＳ４０２：Ｙ、ステップＳ４０３：Ｙ、ステップＳ４０４）。このようにして、第１の受信側ＩＰルータ装置２１６は、送られてくるその楽曲が組み込まれた一連のマルチキャストパケット２１９を第１の受信端末２１４に転送するようになっている。第１の受信端末２１４は、第１の受信側ＩＰルータ装置２１６から転送されてくる一連のマルチキャストパケット２１９を再生することで、その楽曲を聴くことができる。
【００４９】
以上説明したように、実施例のハードウェアエンジン２２１は、送信側ＩＰルータ装置２１３がハードウェア管理テーブル２２５に廃棄用エントリを登録することで、一連のマルチキャストパケット２１９の廃棄処理を行うようになっている。このハードウェア管理テーブル２２５への廃棄用エントリの登録は、図示しない制御部が制御して行うようになっているが、ハードウェアエンジン２２１が廃棄処理を開始すると、図示しない制御部は一連のマルチキャストパケット廃棄処理に関わらないため負荷を軽減することができる。このように、ハードウェアで転送あるいは廃棄を行えるまでの間だけ、受信した一連のマルチキャストパケット２１９のＩＰヘッダの解析および転送あるいは廃棄をソフトウェアに従った図示しない制御部が行うことで、すべてをこの制御部が行う場合と比較して処理の負荷を下げることができる。また、ハードウェアエンジン２２１にＩＰパケットの廃棄処理に最適化された回路を用いることで、廃棄処理の最適化を図ることができる。
【００５０】
また、実施例では送信側ＩＰルータ装置２１３のハードウェア管理テーブル２２５に廃棄用エントリを登録するために、配信先の無いマルチキャストパケット２１９をＩＰフォワーディング処理部２２２で少なくとも１つは廃棄する必要があった。しかし、配信が予定されている特定のマルチキャストパケット２１９に対して、配信開始時に配信先となる受信端末が無いことがＰＩＭ−ＳＭ処理部２２７等によって確認されている場合、これに対する廃棄用エントリを予めハードウェア管理テーブル２２５に登録しておいてもよい。こうすることで、配信開始時にＩＰフォワーディング処理部２２２で廃棄するマルチキャストパケット２１９の数を低減させて、送信側ＩＰルータ装置２１３の図示しない制御部の行うＩＰフォワーディング処理部２２２の処理の負荷を軽減することができる。
【００５１】
更に実施例では、マルチキャスト送信するデータをストリーム系データとしたが、同一のマルチキャストアドレスが組み込まれた一連のＩＰパケットであれば、これらにそれぞれ組み込まれるデータに関連性が無くてもよい。また、ストリーム系データは音楽だけではなく音声や動画等のデータあるいはこれらが組み合わされたデータであってもよい。
【００５２】
発明の変形の可能性
【００５３】
以上説明した実施例では、送信端末２１２では受信端末が存在することを前提としてマルチキャストパケットを作成し送信している。しかし、本発明は送信者が送信するマルチキャストパケットに対して受信端末の存在する可能性が無い、あるいは著しく低い場合に対しても同様に適用できる。このような一例として、たとえばＩＰルータ装置の機能低下あるいは機能停止を意図して、受信者の存在しないマルチキャストパケットを大量に送信するＤｏＳ（denial of service）攻撃が考えられる。このような一連のマルチキャストパケットに対しても廃棄用エントリを作成できる実施例で示したＩＰルータ装置を使用することで、会員等の特定の受信端末以外の端末を宛先とした継続的に発生するパケットとして廃棄処理を行わせることができ、特定の受信端末への影響を排除することができる。もちろん、ＩＰルータ装置等のパケット転送装置も廃棄のための専用のハードウェアあるいはソフトウェアの装置が廃棄の処理を行うので、装置本体部分あるいは制御部への影響を最低限に止めることができる。
【００５４】
【発明の効果】
以上説明したように請求項１記載の発明によれば、パケット廃棄回路を廃棄専用の回路で構成することで、転送装置の他の回路部分に対する影響を排除することができる。また、登録手段に登録した後は不要な宛先の特定パケットが特別の処理を行うことなくパケット廃棄回路に受け渡され廃棄されるので、パケット転送装置の制御部分における負荷の軽減を実現することができ、特にストリーム系データの場合に顕著な効果を持つことができる。
【００５５】
また、請求項２記載の発明によれば、パケット廃棄回路を廃棄専用の回路で構成することで、転送装置の他の回路部分に対する影響を排除することができる。また、ルータ等のパケット転送装置が受信不要情報記憶手段を備え、これで判別した結果を基にして受信端末処理経路選択手段でパケットを廃棄するか否かの振り分けを行っている。したがって、廃棄することがこの時点で判別されたパケットは直ちに廃棄処理されることになり、廃棄処理のための負担が少なくなるだけでなく、不正なパケットが同一の宛先に対して連続的に送られてくるような場合にも受信不要情報記憶手段にこれを加えるだけで迅速な対応が可能になる。
【００５６】
また、請求項３記載の発明によれば、廃棄すべき対象ともされず、また積極的に受信端末へ転送するものともされないようなパケットを対象にした処理が可能になる。したがって、たとえば受信者に対してストリーム系データの受信の開始から一定時間以内を検討期間に設定し、この間に受信の継続の希望の有無を確認させるといったビジネスに対してもパケット転送装置の処理の負担を軽減させることができる。
【００５７】
更に請求項４記載の発明によれば、ただ一回だけ送信されるパケットについて廃棄の処理を簡略化することができるだけでなく、ストリーム系データの場合にも不要なパケットが受信対象者以外の端末に送られることがないので、これによる不都合を発生させることがない。
【図面の簡単な説明】
【図１】本発明の一実施例におけるＩＰルータ装置を備えたマルチキャスト・ネットワークの構成を表わしたブロック図である。
【図２】本実施例のＩＰルータ装置の構成を表わしたブロック図である。
【図３】本実施例におけるＩＰパケットのヘッダ情報のデータ構造を表わした説明図である。
【図４】本実施例で送信側ＩＰルータ装置が入力されたマルチキャストパケットに行う処理の流れ図である。
【図５】本実施例で送信側ＩＰルータ装置が受信側ＩＰルータ装置からＩＰパケットを受信した場合の処理の流れ図である。
【符号の説明】
２１０ 配信希望情報
２１２ 送信端末
２１３、５０２ 送信側ＩＰルータ装置
２１４ 第１の受信端末
２１５ 第２の受信端末
２１６ 第１の受信側ＩＰルータ装置
２１７ 第２の受信側ＩＰルータ装置
２１８ ライブラリ
２２１ ハードウェアエンジン
２２２ ＩＰフォワーディング処理部
２２３ ハードウェアドライバ
２２４ プロトコルスタック処理部
２２５ ハードウェア管理テーブル
２２６ マルチキャスト・フォワーディング・エントリ
２２７ ＰＩＭ−ＳＭ処理部
２２７Ｔ エントリテーブル
Claims (6)
- パケットを廃棄する処理を専用で行うパケット廃棄回路を備えた第１の装置と、
特定パケットを受信する可能性のあるそれぞれの受信端末からその特定パケットの受信を希望するか否かを確認する特定パケット受信希望有無確認手段と、この受信希望有無確認手段によって受信を希望しないと判別された受信端末あるいはその特定パケットの受信を希望しない受信端末がすべてであるパケット転送側の経路を判別する転送側経路判別手段と、この転送側経路判別手段の判別結果を登録する登録手段と、パケットを宛先に転送するパケット転送手段と、特定パケットを受信する特定パケット受信手段と、この特定パケット受信手段が前記特定パケットを受信したとき前記登録手段を参照して前記受信を希望しないと判別された受信端末あるいはその特定パケットの受信を希望しない受信端末がすべてである経路を宛先とする特定パケットを前記第１の装置の前記パケット廃棄回路に受け渡す一方、前記特定パケットの受信を希望する受信端末あるいはその特定パケットの受信を希望する受信端末の存在する経路を宛先とする特定パケットを前記パケット転送手段に受け渡すパケット受け渡し手段とを備えた第２の装置
とを具備することを特徴とするパケット転送装置。 - パケットを廃棄する処理を専用で行うパケット廃棄回路を備えた第１の装置と、
特定の複数の受信端末のいずれかあるいはそれに至る経路を宛先としたパケットを受信するパケット受信手段と、前記特定の複数の受信端末あるいはそれらに至る経路のうち特定パケットの受信を希望しない受信端末あるいは特定パケットの受信を希望しない受信端末がすべてである経路をこれ以外の受信端末あるいは経路から区別する受信不要情報を記憶する受信不要情報記憶手段と、パケットを宛先に転送するパケット転送手段と、前記特定の複数の受信端末に対してこれらが特定パケットの受信を希望していないか否かあるいは所定の経路を経たすべての受信端末が前記特定パケットの受信を希望していないか否かを確認する受信希望有無確認手段と、この受信希望有無確認手段の確認結果を基にした前記受信不要情報を前記受信不要情報記憶手段に登録する受信不要情報登録手段と、前記パケット受信手段が前記特定パケットを受信したときその転送の必要の有無を前記受信不要情報登録手段の登録した受信不要情報によって判別し、受信を希望する受信端末の存在しない経路あるいは受信を希望しない受信端末を直接の宛先とした特定パケットを前記第１の装置の前記パケット廃棄回路に受け渡す一方、受信を希望する受信端末の存在する経路あるいは受信を希望する受信端末を直接の宛先とした特定パケットを前記パケット転送手段に受け渡す受信端末処理経路選択手段とを備えた第２の装置
とを具備することを特徴とするパケット転送装置。 - 前記受信端末処理経路選択手段は、前記受信を希望する受信端末の存在しない経路あるいは受信を希望しない受信端末を直接の宛先とした特定パケット、あるいは前記受信を希望する受信端末の存在する経路あるいは受信を希望する受信端末を直接の宛先とした特定パケット以外の特定パケットが存在するときこれを前記受信希望有無確認手段に確認させることを特徴とする請求項２記載のパケット転送装置。
- 前記受信不要情報登録手段は、前記特定の複数の受信端末のいずれかあるいはそれに至る経路に向けて前記特定パケットの送信が開始される時間が予め定められているとき、このパケットが前記パケット受信手段によって受信される前に前記受信希望有無確認手段によって確認された確認結果を前記受信不要情報記憶手段に登録することを特徴とする請求項２記載のパケット転送装置。
- 前記受信希望有無確認手段は、前記特定パケットの送信が開始された後に前記特定の複数の受信端末のいずれかが受信を希望するか否かについての変更を生じさせたときこれを検出する変更検出手段を備えており、前記受信不要情報登録手段は変更検出手段の検出した変更を登録することを特徴とする請求項２記載のパケット転送装置。
- 前記特定の複数の受信端末はストリーム系のコンテンツを構成する一連のパケットの受信をコンテンツごとに契約する契約者の備える端末であり、前記受信希望有無確認手段は、これらの受信端末の契約によるコンテンツごとの受信の希望の有無で前記特定パケットの受信の有無を確認することを特徴とする請求項２記載のパケット転送装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002031252A JP3700654B2 (ja) | 2002-02-07 | 2002-02-07 | パケット転送装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002031252A JP3700654B2 (ja) | 2002-02-07 | 2002-02-07 | パケット転送装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003234760A JP2003234760A (ja) | 2003-08-22 |
| JP3700654B2 true JP3700654B2 (ja) | 2005-09-28 |
Family
ID=27774717
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002031252A Expired - Lifetime JP3700654B2 (ja) | 2002-02-07 | 2002-02-07 | パケット転送装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3700654B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4993202B2 (ja) * | 2007-12-10 | 2012-08-08 | 横河電機株式会社 | フィールドネットワークシステム |
| CN113114326B (zh) * | 2021-03-19 | 2022-09-27 | 中国联合网络通信集团有限公司 | 一种通信方法及装置 |
-
2002
- 2002-02-07 JP JP2002031252A patent/JP3700654B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003234760A (ja) | 2003-08-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4077330B2 (ja) | データ生成装置 | |
| JP5746688B2 (ja) | ユニキャストクライアント要求をマルチキャストクライアント要求に変換するためのシステムおよび方法 | |
| US6317434B1 (en) | Data link layer switch with multicast capability | |
| US20050281265A1 (en) | Multicast packet routing arrangements for group-membership handling | |
| US7333488B2 (en) | Multicast delivery control apparatus and method | |
| CN100435515C (zh) | 在通信网络中不同的多点传送协议之间转换请求的系统和方法 | |
| JP3792940B2 (ja) | パケットのマルチキャスト配送システム | |
| US7443851B2 (en) | Device and system for multicast communication | |
| KR100811890B1 (ko) | 인터넷 시스템에서 서비스 플로우를 보장하는 애니캐스트라우팅 방법 및 장치 | |
| JP2004531143A (ja) | 仮想マルチキャストネットワーク方法及びそのシステム | |
| EP1497965A1 (en) | Method and apparatus for identifying transport streams as networks | |
| WO2009132568A1 (zh) | 服务质量控制方法及网络设备 | |
| JP2006074132A (ja) | マルチキャスト通信方法及びゲートウェイ装置 | |
| US7876757B2 (en) | Router-assisted fast processing of packet termination in host | |
| US6765907B1 (en) | Multicast echo removal | |
| JP6699231B2 (ja) | 情報配信装置、情報配信プログラム、通信端末、通信処理プログラム及び情報配信システム | |
| JP3700654B2 (ja) | パケット転送装置 | |
| JP3457243B2 (ja) | プッシュ型ネットワーク | |
| WO2017124712A1 (zh) | 报文生成方法、报文转发方法及装置 | |
| JP3782272B2 (ja) | マルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| TWI281804B (en) | Packet forwarding method and system | |
| JP2001007835A (ja) | データ送信装置及び方法、データ中継装置及び方法、データ受信装置及び方法、並びにデータ通信システム、データ通信方法 | |
| JP2003348148A (ja) | Ｉｐマルチキャスト制御方法およびこれを用いるｉｐマルチキャスト制御システム | |
| JP6690291B2 (ja) | 情報配信システム、情報配信装置、情報配信プログラム、及び情報配信方法 | |
| JP6661931B2 (ja) | 情報配信装置、情報配信プログラム及び情報配信システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041112 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041116 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050117 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050308 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050509 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050601 |
|
| 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: 20050621 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050704 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3700654 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090722 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100722 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110722 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110722 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120722 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120722 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130722 Year of fee payment: 8 |
|
| EXPY | Cancellation because of completion of term |