JP4102502B2 - 通信制御装置および通信制御装置の制御方法 - Google Patents
通信制御装置および通信制御装置の制御方法 Download PDFInfo
- Publication number
- JP4102502B2 JP4102502B2 JP02017199A JP2017199A JP4102502B2 JP 4102502 B2 JP4102502 B2 JP 4102502B2 JP 02017199 A JP02017199 A JP 02017199A JP 2017199 A JP2017199 A JP 2017199A JP 4102502 B2 JP4102502 B2 JP 4102502B2
- Authority
- JP
- Japan
- Prior art keywords
- input information
- same
- assigned
- received input
- received
- 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
Landscapes
- Telephonic Communication Services (AREA)
- Exchange Systems With Centralized Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上のリソースを保護することに最適な通信制御装置および通信制御装置の制御方法に関する。
【０００２】
【従来の技術】
ネットワーク上で信頼性のあるデータ通信を行うためには、送信側と受信側との間で、データ通信を制御する制御イベントのやり取りを手順に従って行うことにより実現している。
ところが、ネットワークを悪用する一部の者によって、特定のネットワーク装置に対して、ネットワーク通信を制御するためのイベントを一斉に発行したり、制御手順を途中で故意に放棄する行為を繰り返す等の悪質な攻撃が、ネットワーク上の中継装置などを破壊する目的で行われている。
【０００３】
そこで、上述の攻撃を回避するために採られている方法を以下に記載する。
まず、例えば、公衆網における大規模なネットワークの交換局においては、ネットワーク上で稼働しているシステムのＣＰＵ使用率を監視することによって攻撃を回避する方法がある。具体的には、ＣＰＵ使用率がシステムの稼働に対して過剰であるとみなせる値を示した場合には、ネットワークの交換局から発信端末を収容しているトランク装置へ向けて、異常とみられる発信側ポートからのイベントを規制する指示が自動的に出され、イベントが物理的に交換局まで届かないようにしている。
【０００４】
また、公衆網における大規模なネットワークにおいては、ネットワーク全体を監視するトラフィック制御装置を設置することによって攻撃を回避する方法がある。具体的には、トラフィック制御装置によって特定地域での輻輳が異常であると判断された場合には、トラフィック制御装置から当該ネットワークの交換局に対して、輻輳している特定地域への着アドレスをもつ発信を規制する指示が自動的に出される。
【０００５】
この場合においては、ネットワーク管理者が直接介在して、輻輳している特定地域への着アドレスをもつ発信に規制をかけることによって攻撃を回避することもある。
【０００６】
例えば、インターネットの場合には、ネットワーク管理者が、サーバやゲートウェイ等の装置において制御メッセージを過剰に受けすぎていると判断したときには、ネットワーク管理者が直接介在して、該当するアプリケーションポート自体を閉じてしまうことにより、サービス自体を提供しない方法がある。
【０００７】
さらに、インターネットの場合には、ネットワーク管理者が、外部ネットワークと接続するルータ等の装置上に収容されているユーザのネットワークアドレスを確認できる範囲内で予めデータとして登録しておく方法がある。
具体的には、ルータが、データ登録されていないネットワークアドレスからのメッセージを受け付けた場合には、そのメッセージを外部のネットワークに送出しないようにする。
【０００８】
【発明が解決しようとする課題】
ところで、ネットワーク上で稼働しているシステムのＣＰＵ使用率を監視する方法では、ＣＰＵが主に通信制御だけをしているようなシステムであれば有効な方法となるが、インターネット上のルータなどは様々な制御処理を自律的に行っており、ＣＰＵ使用率が必ずしもネットワーク上のシステムでの通信制御稼働に対するＣＰＵ使用率を示しているとは限らないという問題が生じる。
【０００９】
また、ネットワーク全体を監視するトラフィック制御装置を設置する方法では、公衆網のような階層的なネットワーク構成に基づいているネットワークであれば有効な方法となるが、インターネットのように全体を監視することが不可能なネットワークには導入が困難であるという問題が生じる。
【００１０】
また、ネットワーク管理者が直接介在して規制をかける方法では、ネットワークを２４時間監視する必要があり、一般企業やプライベートネットワークでは現実的ではなく、さらに、規制の内容が、ポート自体を停止することになるため、サービスを完全に止めてしまうという問題が生じる。
【００１１】
また、ルータに収容されているネットワークアドレスを予めデータとして登録しておく方法では、ネットワークアドレスの全てを登録して管理することは不可能であることから信頼性の低下は否めないという問題が生じる。
【００１２】
本発明は、上述した事情に鑑みてなされたものであり、外部から攻撃を受けても交換局内にあるリソースの保護を自己防衛的に行い、さらに、利用者へのサービスの提供も継続する通信制御装置および通信制御装置の制御方法を提供することを目的とする。
【００１３】
【課題を解決するための手段】
上述した課題を解決するため、本発明は、ネットワーク中に介在し、送信端末と受信端末とを接続する通信制御装置において、優先度が設定された複数の待ち行列手段と、前記送信端末から受信した入力情報を分類して前記待ち行列手段のいずれかに割り当てる制御手段と、前記各待ち行列手段に割り当てられた前記入力情報を前記各待ち行列手段の優先度に応じて順次、処理する処理手段と、を具備し、前記制御手段は、前記送信端末から前記入力情報を受信すると、通信制御用のリソースに空きがあるか否かを判定し、前記リソースに空きがあれば、前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがあるか否かを判定し、同一となる組があり且つその同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第２位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一となるものがあるか否かを判定し、同一となる発アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第３位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがあるか否かを判定し、同一となる着アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第４位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがあるか否かを判定し、同一となる発ポート番号があり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第５位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがなければ、受信した前記入力情報を第１位の優先度が設定された前記待ち行列手段に割り当てることを特徴とする通信制御装置を提供する。
また、本発明は、ネットワーク中に介在し、送信端末と受信端末とを接続する通信制御装置であって、優先度が設定された複数の待ち行列手段と、前記送信端末から受信した入力情報を分類して前記待ち行列手段のいずれかに割り当てる制御手段と、前記各待ち行列手段に割り当てられた前記入力情報を前記各待ち行列手段の優先度に応じて順次、処理する処理手段とを具備する通信制御装置の制御方法において、前記制御手段は、入力情報を受け取ると、通信制御用のリソースに空きがあるか否かを判定し、前記リソースに空きがあれば、前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがあるか否かを判定し、同一となる組があり且つその同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第２位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一と なるものがあるか否かを判定し、同一となる発アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第３位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがあるか否かを判定し、同一となる着アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第４位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがあるか否かを判定し、同一となる発ポート番号があり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第５位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがなければ、受信した前記入力情報を第１位の優先度が設定された前記待ち行列手段に割り当てることを特徴とする通信制御装置の制御方法を提供する。
【００１４】
【発明の実施の形態】
[１．構成]
[１−１．全体構成]
図１に本発明の実施形態である通信制御装置の機能構成を示す。
同図に示すように通信制御装置１は、予め定めたルールに従うことによりリソースを保護するリソース保護部１６を備える。また、通信制御装置１は、主に外部からのメッセージを受信するイベント受付部１２と、主に外部へのメッセージを送信するイベント送出部１３と、通信制御装置１で扱われるデータを管理するデータ制御部１４、並びに、コネクションの接続を制御する通信制御部１５とを備える。
以下に、各構成要素を説明する。
【００１５】
[１−２．イベント受付部１２の構成]
イベント受付部１２は、発信側ポート１０から送信されてきたメッセージを内部イベントとして受信する機能と、発信側ポート１０へプロトコルのメッセージを送信する機能と、発信側ポート１０から受け取ったイベント内容の正常性などを確認する機能、およびデータ制御部１４へ通信制御に必要な情報をトランザクションとして転送する機能とを有する。
【００１６】
ここで、イベント受付部１２とリソース保護部１６の詳細構成を図２に示す。図２に示すように、イベント受付部１２は、入力イベント２２を受け取るタイミングをスケジュールするスケジューラ２１を有する。
スケジューラ２１は、周期的にキュー群２０を巡回して、予め定められたスケジュールに従って、キュー２０ａ〜２０ｅから入力イベントを１つずつ取り出して、イベント受付部１２に取り込む機能を有する。
【００１７】
[１−３．イベント送出部１３の構成]
イベント送出部１３は、着信側ポート１０へ通信制御のメッセージを送受信する機能と、着信側ポート１０から送信されてきたメッセージをイベントとして受け付ける機能と、着信側ポート１０から受け取ったイベント内容の正常性などを確認する機能と、データ制御部１４へ通信制御に必要な情報をトランザクションとして転送する機能とを有する。
【００１８】
[１−４．データ制御部１４の構成]
データ制御部１４は、イベント受付部１２およびイベント送出部１３との間で、通信制御情報のトランザクションを送受信する機能を有する。
また、データ制御部１４は、通信制御部１５に対して通信制御に必要な情報をトランザクションで送受信する機能を有する。
【００１９】
さらに、データ制御部１４は、通信状態を受信トランザクションの内容に基づいて把握し、データベースに蓄積する機能を有する。例えば、何番の回線を接続したか等をデータベースに蓄積する。
また、データ制御部１４は、受信トランザクションの着アドレスをキーにして、データベースに蓄積されているルーチングデータを検索することにより、着信端末が存在する出方路を検出する機能を有する。
データベースにデータを蓄積することにより、ネットワーク管理者が、蓄積されたデータに基づいて、回線の接続状況等を把握することが可能となり、効率の良い運用を行うための判断材料とすることができる。
【００２０】
[１−５．通信制御部１５の構成]
通信制御部１５は、発信側の端末と着信側の端末との間で、信頼性のあるデータ通信を行うための制御をする機能を有する。例えば、ＡＴＭにおけるコネクションの設定、ＴＣＰにおけるデータ順序の保証機能等に相当する。
【００２１】
[１−６．リソース保護部１６の構成]
リソース保護部１６は、システム内のコネクションの設定途中の状態も含めたリソース状態に基づいて判断することにより、システム内で処理を行わせるコネクション数を調整する機能を有する。
【００２２】
また、図２に示すように、リソース保護部１６は、イベント受付部１２に受け付けられた入力イベント２２のメッセージ内容に基づいて、予め定められたルールにしたがって、メッセージのパターンを自動的に判別し、パターンごとに定められたサービスの有効度に応じて、入力イベント２２を優先度が設定されたキュー２０ａ〜２０ｅに登録したり、過剰に受け付けられているメッセージについては廃棄するイベント制御部２３を有する。
予め定められたルールとしては、例えば、発着アドレスの組み合わせが同一であるイベントが複数受け付けられた場合には、優先度が通常よりも低く設定されたキュー２０ｂ〜２０ｅに登録する等がある。
これらにより、システムに対して、連続で高速な多くのメッセージが発信されても、リソースを枯渇することなくシステムを使用できる。
【００２３】
[２．動作]
[２−１．リソース保護部１６とイベント受付部１２の動作]
次に、リソース保護部１６とイベント受付部１２の動作例を図２を参照して説明する。
まず、イベント受付部１２が、外部からの入力イベント２２を受信すると、イベント受付部１２では、入力イベント２２の情報をリソース保護部１６に送信する。
リソース保護部１６にあるイベント制御部２３では、イベント受付部１２から受信した入力イベント２２の情報を、予め定められたルールに従ってパターン分けし、そのパターン内でのサービスの有効度に応じて、優先度が設定されたキュー２０ａ〜２０ｅに振り分けて登録する。
この場合の優先度とは、イベント受付部１２が実際に入力イベント２２の処理を受け付けるときの優先順位をいう。
【００２４】
また、優先度は、入力イベント２２の数により変化するが、その変化のさせ方は、予め定められたアルゴリズムに従う。
予め定められたアルゴリズムとしては、例えば、キューに登録された入力イベント数の多少によって、優先順位を変化させるように定められている場合がある。
以下に具体例を説明する。
【００２５】
まず最初に、優先順位が第２位である優先度２のキュー２０ｂと優先順位が第３位である優先度３のキュー２０ｃとがあり、優先度２のキュー２０ｂには入力イベントが３個あり、優先度３のキュー２０ｃには入力イベントが４個あったとする。
その後、優先度２のキュー２０ｂに２個の入力イベントが追加された場合には、優先度２に登録されている入力イベントが５個となり、優先度３に登録されている入力イベント数よりも多くなる。
そのような場合には、優先度２と優先度３のキューに設定された優先順位を入れ替える。
なお、優先度が第１位である優先度１のキュー２０ａは、最初から存在するキューであり、異常がないと判断された通常の入力イベント２２が登録される。
【００２６】
また、パターン分けされた入力イベント２２は、その入力イベント２２の情報である発アドレスや発ポート番号等ごとにインデックスが設けられてキュー２０ａ〜２０ｅに登録される。
【００２７】
キュー２０に登録された入力イベント２２は、スケジューラ２１により予め定められたスケジュールに従って、イベント受付部１２に取り込まれる。
予め定められたスケジュールとしては、例えば、各キュー２０ａ〜２０ｃを１０周巡回する場合を基準として、１０周のうちの５周は、優先度１のキュー２０ａから入力イベント２２を１つ取り出し、１０周のうちの３周は、優先度２のキュー２０ｂから入力イベント２２を１つ取り出し、１０周のうちの２周は、優先度３のキュー２０ｃから入力イベント２２を１つ取り出すというように、優先度が下がるにしたがって取り出す割合を減らしていく方法がある。
なお、スケジューラ２１を利用して入力イベント２２を取り込む場合は、キュー２０ａ〜２０ｅに割り当てられた発アドレス等のインデックスには関係なく、優先度により判断される。
【００２８】
[２−２．リソース保護部１６のイベント振り分けの動作]
次に、リソース保護部１６が、サービスの継続を目的とした場合の判断基準の有効度に基づいて優先度を決定する動作例を図３および図４に示す。
【００２９】
[２−２−１．単一ポートで受け付ける場合の動作]
まず、発信側ポート１０が、単一である場合の動作例について図３を参照して説明する。
第一のパターン例として、入力イベント２２が、特定の発アドレスから特定の着アドレスへ連続して発呼されている場合には、交換局等であるノードへの攻撃とみなすことができる。
第一のパターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、発着アドレスの組み合わせ、発ポート番号の順に設定する。
入力イベント２２は、イベント制御部２３で、有効度の高い順に判断されて、スケジューラ２１に取り込まれる際の優先度が設定されたキューに振り分けられるが、第一のパターン例におけるキューの優先度は、発着アドレスの組み合わせ、発ポート番号の順に設定される。
【００３０】
第二のパターン例として、入力イベント２２が、特定の発アドレスから任意の着アドレスへ連続して発呼されている場合には、交換局等であるノードへの攻撃とみなすことができる。
第二パターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、発アドレス、発ポート番号の順に設定する。
入力イベント２２は、イベント制御部２３で、有効度の高い順に判断されて、スケジューラ２１に取り込まれる際の優先度が設定されたキューに振り分けられるが、第二のパターン例におけるキューの優先度は、発アドレス、発ポート番号の順に設定される。
【００３１】
第三のパターン例として、入力イベント２２が、任意の発アドレスから特定の着アドレスへ連続して発呼されている場合には、同じような状況が、イベント発生時の輻輳現象として一般的に発生する場合もあるため、異常な処理とはみなさない。ただし、システムを防御する必要がある場合には、着アドレスによる規制が有効となる。
第三パターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、着アドレス、発ポート番号の順に設定する。
入力イベント２２は、イベント制御部２３で、有効度の高い順に判断されて、スケジューラ２１に取り込まれる際の優先度が設定されたキューに振り分けられるが、第三のパターン例におけるキューの優先度は、着アドレス、発ポート番号の順に設定される。
【００３２】
第四のパターン例として、入力イベント２２が、任意の発アドレスから任意の着アドレスへ連続して発呼されている場合には、通常のサービスが行われている可能性もあるため、異常な処理とはみなさない。ただし、残りのリソース数により、必要に応じて発ポート番号による規制が有効となる。
第四パターン例では、サービスの継続を優先させる場合の判断基準を、残りリソース数に設定する。
【００３３】
上述した各パターンに記された順に有効度を設定するのは、以下の理由による。
まず、残りリソース数による判断の有効度を最も高く設定したのは、残りリソース数がシステムを防御する上で最も基本となる要素だからである。
次に、発着アドレスによる判断の有効度を、発ポート番号による判断の有効度よりも高く設定したのは、発ポート番号で規制をかけると、当該ポートで受け付けられるメッセージがすべて処理できなくなるため、サービスの継続を優先させるときには、規制をかける範囲が発ポート番号よりも狭い発着アドレスによる規制の有効度を高くしたほうがよいからである。
【００３４】
また、このように有効度を設定することにより、例えば第一のパターンの場合、リソース保護部１６にあるイベント制御部２３は、入力イベント２２を受信した場合に、まず、第一の処理として残りリソース数から判断し、残りリソースがあるときには、入力イベント２２を受け付けて、残りリソースがないときにのみ、入力イベントの廃棄を行う。
そして、第二の処理としては、入力イベント２２の発着アドレスの組み合わせから判断して、連続して発生していなければ、入力イベント２２を受け付けて、連続して発生している場合には、対象の発着アドレスの組み合わせをもつ入力イベント２２の優先度を低くするか廃棄する。
さらに、第三の処理として、入力イベント２２の発ポート番号から判断して、連続して発生していなければ、入力イベント２２を受け付けて、連続して発生している場合には、対象の発ポート番号をもつ入力イベント２２の優先度を低くするか廃棄する。
【００３５】
[２−２−２．複数のポートで受け付ける場合の動作]
次に、発信側ポート１０が、複数ある場合の動作例についてを図４を参照して説明する。なお、各パターンごとの有効度の設定理由および動作は、単一ポートで受け付ける場合と同じである。
第一のパターン例として、入力イベント２２が、特定の発アドレスから特定の着アドレスへ連続して発呼されている場合には、通常、複数ポートからの発信で発生することはありえないと判断する。
第一のパターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、発着アドレスの組み合わせの順に設定する。
【００３６】
第二のパターン例として、入力イベント２２が、特定の発アドレスから任意の着アドレスへ連続して発呼されている場合には、通常、複数ポートからの発信で発生することはありえないと判断する。
第二パターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、発アドレスの順に設定する。
【００３７】
第三のパターン例として、入力イベント２２が、任意の発アドレスから特定の着アドレスへ連続して発呼されている場合には、同じような状況が、イベント発生時の輻輳現象として一般的に発生する場合もあるため、異常な処理とはみなさない。ただし、システムを防御する必要がある場合には、着アドレスによる規制が有効となる。
第三パターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、着アドレスの順に設定する。
【００３８】
第四のパターン例として、入力イベント２２が、任意の発アドレスから任意の着アドレスへ連続して発呼されている場合には、通常のサービスが行われている可能性もあるため、異常な処理とはみなさない。よって、残りのリソース数により必要に応じて規制を行う。
第四パターン例では、サービスの継続を優先させる場合の判断基準を、残りリソース数に設定する。
【００３９】
[２−３．リソース保護部１６の動作]
次に、リソース保護部１６の動作例を図５を参照して説明する。
入力イベント２２が発生すると、イベント受付部１２では、入力イベント２２の情報のうち、例えば発ポート番号および発アドレス等をリソース保護部１６へ送信する（ステップ１０）。そして、リソース保護部１６では、データ制御部１４を通じて、通信制御部１５でのコネクションの確立状態および確立途中状態を検出し、システム全体のコネクション制御用のリソースに空きがあるか否かを判断する（ステップ１１）。
【００４０】
ステップ１１の判断において、コネクション制御用のリソースに空きがない場合は（ステップ１１；Ｎｏ）、入力イベント２２を廃棄して、イベント受付部１２から入力イベント２２を解放する（ステップ１７）。
一方、ステップ１１の判断において、コネクション制御用のリソースに空きがある場合は（ステップ１１；Ｙｅｓ）、入力イベント２２の発アドレスと着アドレスとの組み合わせをキーにしてリストを作成し、リソース保護部１６内で、同一の発着アドレスの組み合わせによる処理が存在するか否かを判断する（ステップ１２）。
【００４１】
ステップ１２の判断において、リソース保護部１６内に、同一の発着アドレスの組み合わせによる処理が存在する場合は（ステップ１２；Ｙｅｓ）、処理をステップ１８に移行する。
一方、ステップ１２の判断において、リソース保護部１６内に、同一の発着アドレスの組み合わせによる処理が存在しない場合は（ステップ１２；Ｎｏ）、入力イベント２２の発アドレスをキーにしてリストを作成し、リソース保護部１６内で、同一の発アドレスによる処理が存在するか否かを判断する（ステップ１３）。
【００４２】
ステップ１３の判断において、リソース保護部１６内に、同一の発アドレスの組み合わせによる処理が存在する場合は（ステップ１３；Ｙｅｓ）、処理をステップ２１に移行する。
一方、ステップ１３の判断において、リソース保護部１６内に、同一の発アドレスの組み合わせによる処理が存在しない場合は（ステップ１３；Ｎｏ）、入力イベント２２の着アドレスをキーにしてリストを作成し、リソース保護部１６内で、同一の着アドレスによる処理が存在するか否かを判断する（ステップ１４）。
【００４３】
ステップ１４の判断において、リソース保護部１６内に、同一の着アドレスによる処理が存在する場合は（ステップ１４；Ｙｅｓ）、処理をステップ２４に移行する。
一方、ステップ１４の判断において、リソース保護部１６内に、同一の着アドレスによる処理が存在しない場合は（ステップ１４；Ｎｏ）、入力イベント２２の発ポート番号をキーにしてリストを作成し、リソース保護部１６内で、同一の発ポート番号による処理が存在するか否かを判断する（ステップ１５）。
【００４４】
ステップ１５の判断において、リソース保護部１６内に、同一の発ポート番号による処理が存在する場合は（ステップ１５；Ｙｅｓ）、処理をステップ２７に移行する。
一方、ステップ１５の判断において、リソース保護部１６内に、同一の発ポート番号による処理が存在しない場合は（ステップ１５；Ｎｏ）、通常のキューである優先度第１位のキュー２０ａに登録して（ステップ１５）、処理を終了する。
【００４５】
また、ステップ１２の判断において、リソース保護部１６内に、同一の発着アドレスの組み合わせによる処理が存在する場合は（ステップ１２；Ｙｅｓ）、同一の発着アドレスの組み合わせによる処理回数が、予め定めた設定回数を超えているか否かを判断する（ステップ１８）。
ステップ１８の判断において、同一の発着アドレスの組み合わせによる処理回数が、予め定めた設定回数を超えていない場合は（ステップ１８；Ｎｏ）、発着アドレスの組み合わせをキーとしたキューである優先度第２位のキュー２０ｂに登録して（ステップ１９）、処理を終了する。
一方、ステップ１８の判断において、同一の発着アドレスの組み合わせによる処理回数が、予め定めた設定回数を超えている場合は（ステップ１８；Ｙｅｓ）、優先度第２位のキュー２０ｂから、設定回数を超えているイベントを廃棄して（ステップ２０）、処理を終了する。
このように、同一の発着アドレスの組み合わせによる処理が連続して発生している場合には、通信制御装置１への攻撃の可能性があると判断することができる。
【００４６】
また、ステップ１３の判断において、リソース保護部１６内に、同一の発アドレスによる処理が存在する場合は（ステップ１３；Ｙｅｓ）、同一の発アドレスによる処理回数が、予め定めた設定回数を超えているか否かを判断する（ステップ２１）。
ステップ２１の判断において、同一の発アドレスによる処理回数が、予め定めた設定回数を超えていない場合は（ステップ２１；Ｎｏ）、発アドレスをキーとしたキューである優先度第３位のキュー２０ｃに登録して（ステップ２２）、処理を終了する。
一方、ステップ２１の判断において、同一の発アドレスによる処理回数が、予め定めた設定回数を超えている場合は（ステップ２１；Ｙｅｓ）、優先度第３位のキュー２０ｃから、設定回数を超えているイベントを廃棄して（ステップ２３）、処理を終了する。。
このように、同一の発アドレスによる処理が連続して発生している場合には、通信制御装置１への攻撃の可能性があると判断することができる。
【００４７】
また、ステップ１４の判断において、リソース保護部１６内に、同一の着アドレスによる処理が存在する場合は（ステップ１４；Ｙｅｓ）、同一の着アドレスによる処理回数が、予め定めた設定回数を超えているか否かを判断する（ステップ２４）。
ステップ２４の判断において、同一の着アドレスによる処理回数が、予め定めた設定回数を超えていない場合は（ステップ２４；Ｎｏ）、着アドレスをキーとしたキューである優先度第４位のキュー２０ｄに登録して（ステップ２５）、処理を終了する。
一方、ステップ２４の判断において、同一の着アドレスによる処理回数が、予め定めた設定回数を超えている場合は（ステップ２４；Ｙｅｓ）、優先度第４位のキュー２０ｄから、設定回数を超えているイベントを廃棄して（ステップ２６）、処理を終了する。
【００４８】
また、ステップ１５の判断において、リソース保護部１６内に、同一の発ポート番号による処理が存在する場合は（ステップ１５；Ｙｅｓ）、同一の発ポート番号による処理回数が、予め定めた設定回数を超えているか否かを判断する（ステップ２７）。
ステップ２７の判断において、同一の発ポート番号による処理回数が、予め定めた設定回数を超えていない場合は（ステップ２７；Ｎｏ）、発ポート番号をキーとしたキューである優先度第５位のキュー２０ｅに登録して（ステップ２８）、処理を終了する。
一方、ステップ２７の判断において、同一の発ポート番号による処理回数が、予め定めた設定回数を超えている場合は（ステップ２７；Ｙｅｓ）、優先度第５位のキュー２０ｅから、設定回数を超えているイベントを廃棄して（ステップ２９）、処理を終了する。
【００４９】
[３．本実施形態の効果]
上述のように、発信端末側からの入力イベント２２に規制をかける場合に、リソースの空き状況、発着アドレスの組み合わせの存在状況、発アドレスの存在状況、着アドレスの存在状況、発ポート番号の存在状況の順に判断をすることにより（ステップ１１〜ステップ１５）、各要素に応じた細かな設定をすることが可能となるため、サービスを停止することによる悪影響を最小限に抑えることができる。
【００５０】
また、発着アドレスの組み合わせの存在状況、発アドレスの存在状況、着アドレスの存在状況、発ポート番号の存在状況に合わせて、処理の優先度を通常よりも低く設定することにより（ステップ１９、ステップ２２、ステップ２５、ステップ２８）、攻撃の可能性がある入力イベント２２の処理を遅らせることができる。さらに、処理を遅らせた結果、処理待ちによるタイムアウトが発生することで、攻撃の可能性がある入力イベント２２を減少させることができる。
【００５１】
また、発着アドレスの組み合わせの存在状況、発アドレスの存在状況、着アドレスの存在状況、発ポート番号の存在状況が連続して過剰に存在すると判断された場合に、当該イベントを廃棄することにより（ステップ２０、ステップ２３、ステップ２６、ステップ２９）、リソースが落ちてしまうことを防ぐことができるため、その結果、リソースの保護を図ることができる。
【００５２】
[３．変形例]
[３−１．第一変形例]
上述した実施形態においては、入力イベント２２の情報に発アドレスが要素として含まれているが、入力イベント２２の情報要素には必ずしも発アドレスが含まれていなくてもよい。発アドレスが含まれていない場合は、発アドレスによる判断を除いて処理を行えば、上述の実施形態と同様の効果を得ることができる。
【００５３】
[３−２．第二変形例]
上述した実施形態における、スケジューラ２１は、予め定められたスケジュールに従って、優先度が設定されたキュー２０ａ〜２０ｅから入力イベント２２を順次取り出しているが、上述のキュー２０ａ〜２０ｅとは別に緊急用のキューを設定しておき、緊急用のキューに入力イベント２２が登録された場合には、各周期ごとに緊急用のキューから入力イベント２２を取り出すようにしてもよい。これにより、急を要する特別な処理を行う場合には、他の入力イベント２２が多数存在して、キューが混んでいるときでも、優先的に処理が行えるようになる。
【００５４】
[３−３．第三変形例]
上述した実施形態においては、キュー２０ａ〜２０ｅに登録する情報は、入力イベント２２に対応づけられたインデックスであるが、入力イベント２２の情報そのものでもよい。要するに、各キュー２０ａ〜２０ｅに対して、どのような入力イベント２２が登録されているのかが判別できればよい。
【００５５】
[３−４．第四変形例]
上述した実施形態においては、スケジューラ２１が、入力イベント２２をキュー２０ａ〜２０ｅから１つずつ取り出しているが、一度に複数の入力イベント２２を取り出してもよい。要するに、優先順位に従って、順次、入力イベント２２の処理が行えればよい。
【００５６】
[３−５．第五変形例]
上述した実施形態においては、イベント受付部１２とイベント送出部１３が別個に存在しているが、構成上１つにまとめてもよい。要するに、発信側の端末と着信側の端末との送受信が行える機能が備わっていればよい。
【００５７】
【発明の効果】
上述したように本発明によれば、外部から攻撃を受けても交換局内にあるリソースの保護を行い、さらに、利用者へのサービスの提供も継続する通信制御装置および通信制御装置の制御方法を提供することができる。
【図面の簡単な説明】
【図１】本発明の実施形態である通信制御装置の機能構成を示す図である。
【図２】同実施形態におけるイベント受付部とリソース保護部の詳細構成を示す図である。
【図３】同実施形態におけるリソース保護部が、サービスの継続を目的とした場合の判断基準の有効度に基づいて優先度を決定する例１を示す図である。
【図４】同実施形態におけるリソース保護部が、サービスの継続を目的とした場合の判断基準の有効度に基づいて優先度を決定する例２を示す図である。
【図５】同実施形態におけるリソース保護部の動作例を示すフローチャートである。
【符号の説明】
１・・・・通信制御装置
２・・・・端末（送信端末、受信端末）
１２・・・イベント受付部
１６・・・リソース保護部
２０・・・キュー（待ち行列手段）
２２・・・入力イベント（入力情報）
２３・・・イベント制御部（制御部）
２１・・・スケジューラ（処理手段）
【発明の属する技術分野】
本発明は、ネットワーク上のリソースを保護することに最適な通信制御装置および通信制御装置の制御方法に関する。
【０００２】
【従来の技術】
ネットワーク上で信頼性のあるデータ通信を行うためには、送信側と受信側との間で、データ通信を制御する制御イベントのやり取りを手順に従って行うことにより実現している。
ところが、ネットワークを悪用する一部の者によって、特定のネットワーク装置に対して、ネットワーク通信を制御するためのイベントを一斉に発行したり、制御手順を途中で故意に放棄する行為を繰り返す等の悪質な攻撃が、ネットワーク上の中継装置などを破壊する目的で行われている。
【０００３】
そこで、上述の攻撃を回避するために採られている方法を以下に記載する。
まず、例えば、公衆網における大規模なネットワークの交換局においては、ネットワーク上で稼働しているシステムのＣＰＵ使用率を監視することによって攻撃を回避する方法がある。具体的には、ＣＰＵ使用率がシステムの稼働に対して過剰であるとみなせる値を示した場合には、ネットワークの交換局から発信端末を収容しているトランク装置へ向けて、異常とみられる発信側ポートからのイベントを規制する指示が自動的に出され、イベントが物理的に交換局まで届かないようにしている。
【０００４】
また、公衆網における大規模なネットワークにおいては、ネットワーク全体を監視するトラフィック制御装置を設置することによって攻撃を回避する方法がある。具体的には、トラフィック制御装置によって特定地域での輻輳が異常であると判断された場合には、トラフィック制御装置から当該ネットワークの交換局に対して、輻輳している特定地域への着アドレスをもつ発信を規制する指示が自動的に出される。
【０００５】
この場合においては、ネットワーク管理者が直接介在して、輻輳している特定地域への着アドレスをもつ発信に規制をかけることによって攻撃を回避することもある。
【０００６】
例えば、インターネットの場合には、ネットワーク管理者が、サーバやゲートウェイ等の装置において制御メッセージを過剰に受けすぎていると判断したときには、ネットワーク管理者が直接介在して、該当するアプリケーションポート自体を閉じてしまうことにより、サービス自体を提供しない方法がある。
【０００７】
さらに、インターネットの場合には、ネットワーク管理者が、外部ネットワークと接続するルータ等の装置上に収容されているユーザのネットワークアドレスを確認できる範囲内で予めデータとして登録しておく方法がある。
具体的には、ルータが、データ登録されていないネットワークアドレスからのメッセージを受け付けた場合には、そのメッセージを外部のネットワークに送出しないようにする。
【０００８】
【発明が解決しようとする課題】
ところで、ネットワーク上で稼働しているシステムのＣＰＵ使用率を監視する方法では、ＣＰＵが主に通信制御だけをしているようなシステムであれば有効な方法となるが、インターネット上のルータなどは様々な制御処理を自律的に行っており、ＣＰＵ使用率が必ずしもネットワーク上のシステムでの通信制御稼働に対するＣＰＵ使用率を示しているとは限らないという問題が生じる。
【０００９】
また、ネットワーク全体を監視するトラフィック制御装置を設置する方法では、公衆網のような階層的なネットワーク構成に基づいているネットワークであれば有効な方法となるが、インターネットのように全体を監視することが不可能なネットワークには導入が困難であるという問題が生じる。
【００１０】
また、ネットワーク管理者が直接介在して規制をかける方法では、ネットワークを２４時間監視する必要があり、一般企業やプライベートネットワークでは現実的ではなく、さらに、規制の内容が、ポート自体を停止することになるため、サービスを完全に止めてしまうという問題が生じる。
【００１１】
また、ルータに収容されているネットワークアドレスを予めデータとして登録しておく方法では、ネットワークアドレスの全てを登録して管理することは不可能であることから信頼性の低下は否めないという問題が生じる。
【００１２】
本発明は、上述した事情に鑑みてなされたものであり、外部から攻撃を受けても交換局内にあるリソースの保護を自己防衛的に行い、さらに、利用者へのサービスの提供も継続する通信制御装置および通信制御装置の制御方法を提供することを目的とする。
【００１３】
【課題を解決するための手段】
上述した課題を解決するため、本発明は、ネットワーク中に介在し、送信端末と受信端末とを接続する通信制御装置において、優先度が設定された複数の待ち行列手段と、前記送信端末から受信した入力情報を分類して前記待ち行列手段のいずれかに割り当てる制御手段と、前記各待ち行列手段に割り当てられた前記入力情報を前記各待ち行列手段の優先度に応じて順次、処理する処理手段と、を具備し、前記制御手段は、前記送信端末から前記入力情報を受信すると、通信制御用のリソースに空きがあるか否かを判定し、前記リソースに空きがあれば、前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがあるか否かを判定し、同一となる組があり且つその同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第２位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一となるものがあるか否かを判定し、同一となる発アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第３位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがあるか否かを判定し、同一となる着アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第４位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがあるか否かを判定し、同一となる発ポート番号があり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第５位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがなければ、受信した前記入力情報を第１位の優先度が設定された前記待ち行列手段に割り当てることを特徴とする通信制御装置を提供する。
また、本発明は、ネットワーク中に介在し、送信端末と受信端末とを接続する通信制御装置であって、優先度が設定された複数の待ち行列手段と、前記送信端末から受信した入力情報を分類して前記待ち行列手段のいずれかに割り当てる制御手段と、前記各待ち行列手段に割り当てられた前記入力情報を前記各待ち行列手段の優先度に応じて順次、処理する処理手段とを具備する通信制御装置の制御方法において、前記制御手段は、入力情報を受け取ると、通信制御用のリソースに空きがあるか否かを判定し、前記リソースに空きがあれば、前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがあるか否かを判定し、同一となる組があり且つその同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第２位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一と なるものがあるか否かを判定し、同一となる発アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第３位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがあるか否かを判定し、同一となる着アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第４位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがあるか否かを判定し、同一となる発ポート番号があり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第５位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがなければ、受信した前記入力情報を第１位の優先度が設定された前記待ち行列手段に割り当てることを特徴とする通信制御装置の制御方法を提供する。
【００１４】
【発明の実施の形態】
[１．構成]
[１−１．全体構成]
図１に本発明の実施形態である通信制御装置の機能構成を示す。
同図に示すように通信制御装置１は、予め定めたルールに従うことによりリソースを保護するリソース保護部１６を備える。また、通信制御装置１は、主に外部からのメッセージを受信するイベント受付部１２と、主に外部へのメッセージを送信するイベント送出部１３と、通信制御装置１で扱われるデータを管理するデータ制御部１４、並びに、コネクションの接続を制御する通信制御部１５とを備える。
以下に、各構成要素を説明する。
【００１５】
[１−２．イベント受付部１２の構成]
イベント受付部１２は、発信側ポート１０から送信されてきたメッセージを内部イベントとして受信する機能と、発信側ポート１０へプロトコルのメッセージを送信する機能と、発信側ポート１０から受け取ったイベント内容の正常性などを確認する機能、およびデータ制御部１４へ通信制御に必要な情報をトランザクションとして転送する機能とを有する。
【００１６】
ここで、イベント受付部１２とリソース保護部１６の詳細構成を図２に示す。図２に示すように、イベント受付部１２は、入力イベント２２を受け取るタイミングをスケジュールするスケジューラ２１を有する。
スケジューラ２１は、周期的にキュー群２０を巡回して、予め定められたスケジュールに従って、キュー２０ａ〜２０ｅから入力イベントを１つずつ取り出して、イベント受付部１２に取り込む機能を有する。
【００１７】
[１−３．イベント送出部１３の構成]
イベント送出部１３は、着信側ポート１０へ通信制御のメッセージを送受信する機能と、着信側ポート１０から送信されてきたメッセージをイベントとして受け付ける機能と、着信側ポート１０から受け取ったイベント内容の正常性などを確認する機能と、データ制御部１４へ通信制御に必要な情報をトランザクションとして転送する機能とを有する。
【００１８】
[１−４．データ制御部１４の構成]
データ制御部１４は、イベント受付部１２およびイベント送出部１３との間で、通信制御情報のトランザクションを送受信する機能を有する。
また、データ制御部１４は、通信制御部１５に対して通信制御に必要な情報をトランザクションで送受信する機能を有する。
【００１９】
さらに、データ制御部１４は、通信状態を受信トランザクションの内容に基づいて把握し、データベースに蓄積する機能を有する。例えば、何番の回線を接続したか等をデータベースに蓄積する。
また、データ制御部１４は、受信トランザクションの着アドレスをキーにして、データベースに蓄積されているルーチングデータを検索することにより、着信端末が存在する出方路を検出する機能を有する。
データベースにデータを蓄積することにより、ネットワーク管理者が、蓄積されたデータに基づいて、回線の接続状況等を把握することが可能となり、効率の良い運用を行うための判断材料とすることができる。
【００２０】
[１−５．通信制御部１５の構成]
通信制御部１５は、発信側の端末と着信側の端末との間で、信頼性のあるデータ通信を行うための制御をする機能を有する。例えば、ＡＴＭにおけるコネクションの設定、ＴＣＰにおけるデータ順序の保証機能等に相当する。
【００２１】
[１−６．リソース保護部１６の構成]
リソース保護部１６は、システム内のコネクションの設定途中の状態も含めたリソース状態に基づいて判断することにより、システム内で処理を行わせるコネクション数を調整する機能を有する。
【００２２】
また、図２に示すように、リソース保護部１６は、イベント受付部１２に受け付けられた入力イベント２２のメッセージ内容に基づいて、予め定められたルールにしたがって、メッセージのパターンを自動的に判別し、パターンごとに定められたサービスの有効度に応じて、入力イベント２２を優先度が設定されたキュー２０ａ〜２０ｅに登録したり、過剰に受け付けられているメッセージについては廃棄するイベント制御部２３を有する。
予め定められたルールとしては、例えば、発着アドレスの組み合わせが同一であるイベントが複数受け付けられた場合には、優先度が通常よりも低く設定されたキュー２０ｂ〜２０ｅに登録する等がある。
これらにより、システムに対して、連続で高速な多くのメッセージが発信されても、リソースを枯渇することなくシステムを使用できる。
【００２３】
[２．動作]
[２−１．リソース保護部１６とイベント受付部１２の動作]
次に、リソース保護部１６とイベント受付部１２の動作例を図２を参照して説明する。
まず、イベント受付部１２が、外部からの入力イベント２２を受信すると、イベント受付部１２では、入力イベント２２の情報をリソース保護部１６に送信する。
リソース保護部１６にあるイベント制御部２３では、イベント受付部１２から受信した入力イベント２２の情報を、予め定められたルールに従ってパターン分けし、そのパターン内でのサービスの有効度に応じて、優先度が設定されたキュー２０ａ〜２０ｅに振り分けて登録する。
この場合の優先度とは、イベント受付部１２が実際に入力イベント２２の処理を受け付けるときの優先順位をいう。
【００２４】
また、優先度は、入力イベント２２の数により変化するが、その変化のさせ方は、予め定められたアルゴリズムに従う。
予め定められたアルゴリズムとしては、例えば、キューに登録された入力イベント数の多少によって、優先順位を変化させるように定められている場合がある。
以下に具体例を説明する。
【００２５】
まず最初に、優先順位が第２位である優先度２のキュー２０ｂと優先順位が第３位である優先度３のキュー２０ｃとがあり、優先度２のキュー２０ｂには入力イベントが３個あり、優先度３のキュー２０ｃには入力イベントが４個あったとする。
その後、優先度２のキュー２０ｂに２個の入力イベントが追加された場合には、優先度２に登録されている入力イベントが５個となり、優先度３に登録されている入力イベント数よりも多くなる。
そのような場合には、優先度２と優先度３のキューに設定された優先順位を入れ替える。
なお、優先度が第１位である優先度１のキュー２０ａは、最初から存在するキューであり、異常がないと判断された通常の入力イベント２２が登録される。
【００２６】
また、パターン分けされた入力イベント２２は、その入力イベント２２の情報である発アドレスや発ポート番号等ごとにインデックスが設けられてキュー２０ａ〜２０ｅに登録される。
【００２７】
キュー２０に登録された入力イベント２２は、スケジューラ２１により予め定められたスケジュールに従って、イベント受付部１２に取り込まれる。
予め定められたスケジュールとしては、例えば、各キュー２０ａ〜２０ｃを１０周巡回する場合を基準として、１０周のうちの５周は、優先度１のキュー２０ａから入力イベント２２を１つ取り出し、１０周のうちの３周は、優先度２のキュー２０ｂから入力イベント２２を１つ取り出し、１０周のうちの２周は、優先度３のキュー２０ｃから入力イベント２２を１つ取り出すというように、優先度が下がるにしたがって取り出す割合を減らしていく方法がある。
なお、スケジューラ２１を利用して入力イベント２２を取り込む場合は、キュー２０ａ〜２０ｅに割り当てられた発アドレス等のインデックスには関係なく、優先度により判断される。
【００２８】
[２−２．リソース保護部１６のイベント振り分けの動作]
次に、リソース保護部１６が、サービスの継続を目的とした場合の判断基準の有効度に基づいて優先度を決定する動作例を図３および図４に示す。
【００２９】
[２−２−１．単一ポートで受け付ける場合の動作]
まず、発信側ポート１０が、単一である場合の動作例について図３を参照して説明する。
第一のパターン例として、入力イベント２２が、特定の発アドレスから特定の着アドレスへ連続して発呼されている場合には、交換局等であるノードへの攻撃とみなすことができる。
第一のパターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、発着アドレスの組み合わせ、発ポート番号の順に設定する。
入力イベント２２は、イベント制御部２３で、有効度の高い順に判断されて、スケジューラ２１に取り込まれる際の優先度が設定されたキューに振り分けられるが、第一のパターン例におけるキューの優先度は、発着アドレスの組み合わせ、発ポート番号の順に設定される。
【００３０】
第二のパターン例として、入力イベント２２が、特定の発アドレスから任意の着アドレスへ連続して発呼されている場合には、交換局等であるノードへの攻撃とみなすことができる。
第二パターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、発アドレス、発ポート番号の順に設定する。
入力イベント２２は、イベント制御部２３で、有効度の高い順に判断されて、スケジューラ２１に取り込まれる際の優先度が設定されたキューに振り分けられるが、第二のパターン例におけるキューの優先度は、発アドレス、発ポート番号の順に設定される。
【００３１】
第三のパターン例として、入力イベント２２が、任意の発アドレスから特定の着アドレスへ連続して発呼されている場合には、同じような状況が、イベント発生時の輻輳現象として一般的に発生する場合もあるため、異常な処理とはみなさない。ただし、システムを防御する必要がある場合には、着アドレスによる規制が有効となる。
第三パターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、着アドレス、発ポート番号の順に設定する。
入力イベント２２は、イベント制御部２３で、有効度の高い順に判断されて、スケジューラ２１に取り込まれる際の優先度が設定されたキューに振り分けられるが、第三のパターン例におけるキューの優先度は、着アドレス、発ポート番号の順に設定される。
【００３２】
第四のパターン例として、入力イベント２２が、任意の発アドレスから任意の着アドレスへ連続して発呼されている場合には、通常のサービスが行われている可能性もあるため、異常な処理とはみなさない。ただし、残りのリソース数により、必要に応じて発ポート番号による規制が有効となる。
第四パターン例では、サービスの継続を優先させる場合の判断基準を、残りリソース数に設定する。
【００３３】
上述した各パターンに記された順に有効度を設定するのは、以下の理由による。
まず、残りリソース数による判断の有効度を最も高く設定したのは、残りリソース数がシステムを防御する上で最も基本となる要素だからである。
次に、発着アドレスによる判断の有効度を、発ポート番号による判断の有効度よりも高く設定したのは、発ポート番号で規制をかけると、当該ポートで受け付けられるメッセージがすべて処理できなくなるため、サービスの継続を優先させるときには、規制をかける範囲が発ポート番号よりも狭い発着アドレスによる規制の有効度を高くしたほうがよいからである。
【００３４】
また、このように有効度を設定することにより、例えば第一のパターンの場合、リソース保護部１６にあるイベント制御部２３は、入力イベント２２を受信した場合に、まず、第一の処理として残りリソース数から判断し、残りリソースがあるときには、入力イベント２２を受け付けて、残りリソースがないときにのみ、入力イベントの廃棄を行う。
そして、第二の処理としては、入力イベント２２の発着アドレスの組み合わせから判断して、連続して発生していなければ、入力イベント２２を受け付けて、連続して発生している場合には、対象の発着アドレスの組み合わせをもつ入力イベント２２の優先度を低くするか廃棄する。
さらに、第三の処理として、入力イベント２２の発ポート番号から判断して、連続して発生していなければ、入力イベント２２を受け付けて、連続して発生している場合には、対象の発ポート番号をもつ入力イベント２２の優先度を低くするか廃棄する。
【００３５】
[２−２−２．複数のポートで受け付ける場合の動作]
次に、発信側ポート１０が、複数ある場合の動作例についてを図４を参照して説明する。なお、各パターンごとの有効度の設定理由および動作は、単一ポートで受け付ける場合と同じである。
第一のパターン例として、入力イベント２２が、特定の発アドレスから特定の着アドレスへ連続して発呼されている場合には、通常、複数ポートからの発信で発生することはありえないと判断する。
第一のパターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、発着アドレスの組み合わせの順に設定する。
【００３６】
第二のパターン例として、入力イベント２２が、特定の発アドレスから任意の着アドレスへ連続して発呼されている場合には、通常、複数ポートからの発信で発生することはありえないと判断する。
第二パターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、発アドレスの順に設定する。
【００３７】
第三のパターン例として、入力イベント２２が、任意の発アドレスから特定の着アドレスへ連続して発呼されている場合には、同じような状況が、イベント発生時の輻輳現象として一般的に発生する場合もあるため、異常な処理とはみなさない。ただし、システムを防御する必要がある場合には、着アドレスによる規制が有効となる。
第三パターン例では、サービスの継続を優先させる場合の判断基準の有効度を、高い方から、残りリソース数、着アドレスの順に設定する。
【００３８】
第四のパターン例として、入力イベント２２が、任意の発アドレスから任意の着アドレスへ連続して発呼されている場合には、通常のサービスが行われている可能性もあるため、異常な処理とはみなさない。よって、残りのリソース数により必要に応じて規制を行う。
第四パターン例では、サービスの継続を優先させる場合の判断基準を、残りリソース数に設定する。
【００３９】
[２−３．リソース保護部１６の動作]
次に、リソース保護部１６の動作例を図５を参照して説明する。
入力イベント２２が発生すると、イベント受付部１２では、入力イベント２２の情報のうち、例えば発ポート番号および発アドレス等をリソース保護部１６へ送信する（ステップ１０）。そして、リソース保護部１６では、データ制御部１４を通じて、通信制御部１５でのコネクションの確立状態および確立途中状態を検出し、システム全体のコネクション制御用のリソースに空きがあるか否かを判断する（ステップ１１）。
【００４０】
ステップ１１の判断において、コネクション制御用のリソースに空きがない場合は（ステップ１１；Ｎｏ）、入力イベント２２を廃棄して、イベント受付部１２から入力イベント２２を解放する（ステップ１７）。
一方、ステップ１１の判断において、コネクション制御用のリソースに空きがある場合は（ステップ１１；Ｙｅｓ）、入力イベント２２の発アドレスと着アドレスとの組み合わせをキーにしてリストを作成し、リソース保護部１６内で、同一の発着アドレスの組み合わせによる処理が存在するか否かを判断する（ステップ１２）。
【００４１】
ステップ１２の判断において、リソース保護部１６内に、同一の発着アドレスの組み合わせによる処理が存在する場合は（ステップ１２；Ｙｅｓ）、処理をステップ１８に移行する。
一方、ステップ１２の判断において、リソース保護部１６内に、同一の発着アドレスの組み合わせによる処理が存在しない場合は（ステップ１２；Ｎｏ）、入力イベント２２の発アドレスをキーにしてリストを作成し、リソース保護部１６内で、同一の発アドレスによる処理が存在するか否かを判断する（ステップ１３）。
【００４２】
ステップ１３の判断において、リソース保護部１６内に、同一の発アドレスの組み合わせによる処理が存在する場合は（ステップ１３；Ｙｅｓ）、処理をステップ２１に移行する。
一方、ステップ１３の判断において、リソース保護部１６内に、同一の発アドレスの組み合わせによる処理が存在しない場合は（ステップ１３；Ｎｏ）、入力イベント２２の着アドレスをキーにしてリストを作成し、リソース保護部１６内で、同一の着アドレスによる処理が存在するか否かを判断する（ステップ１４）。
【００４３】
ステップ１４の判断において、リソース保護部１６内に、同一の着アドレスによる処理が存在する場合は（ステップ１４；Ｙｅｓ）、処理をステップ２４に移行する。
一方、ステップ１４の判断において、リソース保護部１６内に、同一の着アドレスによる処理が存在しない場合は（ステップ１４；Ｎｏ）、入力イベント２２の発ポート番号をキーにしてリストを作成し、リソース保護部１６内で、同一の発ポート番号による処理が存在するか否かを判断する（ステップ１５）。
【００４４】
ステップ１５の判断において、リソース保護部１６内に、同一の発ポート番号による処理が存在する場合は（ステップ１５；Ｙｅｓ）、処理をステップ２７に移行する。
一方、ステップ１５の判断において、リソース保護部１６内に、同一の発ポート番号による処理が存在しない場合は（ステップ１５；Ｎｏ）、通常のキューである優先度第１位のキュー２０ａに登録して（ステップ１５）、処理を終了する。
【００４５】
また、ステップ１２の判断において、リソース保護部１６内に、同一の発着アドレスの組み合わせによる処理が存在する場合は（ステップ１２；Ｙｅｓ）、同一の発着アドレスの組み合わせによる処理回数が、予め定めた設定回数を超えているか否かを判断する（ステップ１８）。
ステップ１８の判断において、同一の発着アドレスの組み合わせによる処理回数が、予め定めた設定回数を超えていない場合は（ステップ１８；Ｎｏ）、発着アドレスの組み合わせをキーとしたキューである優先度第２位のキュー２０ｂに登録して（ステップ１９）、処理を終了する。
一方、ステップ１８の判断において、同一の発着アドレスの組み合わせによる処理回数が、予め定めた設定回数を超えている場合は（ステップ１８；Ｙｅｓ）、優先度第２位のキュー２０ｂから、設定回数を超えているイベントを廃棄して（ステップ２０）、処理を終了する。
このように、同一の発着アドレスの組み合わせによる処理が連続して発生している場合には、通信制御装置１への攻撃の可能性があると判断することができる。
【００４６】
また、ステップ１３の判断において、リソース保護部１６内に、同一の発アドレスによる処理が存在する場合は（ステップ１３；Ｙｅｓ）、同一の発アドレスによる処理回数が、予め定めた設定回数を超えているか否かを判断する（ステップ２１）。
ステップ２１の判断において、同一の発アドレスによる処理回数が、予め定めた設定回数を超えていない場合は（ステップ２１；Ｎｏ）、発アドレスをキーとしたキューである優先度第３位のキュー２０ｃに登録して（ステップ２２）、処理を終了する。
一方、ステップ２１の判断において、同一の発アドレスによる処理回数が、予め定めた設定回数を超えている場合は（ステップ２１；Ｙｅｓ）、優先度第３位のキュー２０ｃから、設定回数を超えているイベントを廃棄して（ステップ２３）、処理を終了する。。
このように、同一の発アドレスによる処理が連続して発生している場合には、通信制御装置１への攻撃の可能性があると判断することができる。
【００４７】
また、ステップ１４の判断において、リソース保護部１６内に、同一の着アドレスによる処理が存在する場合は（ステップ１４；Ｙｅｓ）、同一の着アドレスによる処理回数が、予め定めた設定回数を超えているか否かを判断する（ステップ２４）。
ステップ２４の判断において、同一の着アドレスによる処理回数が、予め定めた設定回数を超えていない場合は（ステップ２４；Ｎｏ）、着アドレスをキーとしたキューである優先度第４位のキュー２０ｄに登録して（ステップ２５）、処理を終了する。
一方、ステップ２４の判断において、同一の着アドレスによる処理回数が、予め定めた設定回数を超えている場合は（ステップ２４；Ｙｅｓ）、優先度第４位のキュー２０ｄから、設定回数を超えているイベントを廃棄して（ステップ２６）、処理を終了する。
【００４８】
また、ステップ１５の判断において、リソース保護部１６内に、同一の発ポート番号による処理が存在する場合は（ステップ１５；Ｙｅｓ）、同一の発ポート番号による処理回数が、予め定めた設定回数を超えているか否かを判断する（ステップ２７）。
ステップ２７の判断において、同一の発ポート番号による処理回数が、予め定めた設定回数を超えていない場合は（ステップ２７；Ｎｏ）、発ポート番号をキーとしたキューである優先度第５位のキュー２０ｅに登録して（ステップ２８）、処理を終了する。
一方、ステップ２７の判断において、同一の発ポート番号による処理回数が、予め定めた設定回数を超えている場合は（ステップ２７；Ｙｅｓ）、優先度第５位のキュー２０ｅから、設定回数を超えているイベントを廃棄して（ステップ２９）、処理を終了する。
【００４９】
[３．本実施形態の効果]
上述のように、発信端末側からの入力イベント２２に規制をかける場合に、リソースの空き状況、発着アドレスの組み合わせの存在状況、発アドレスの存在状況、着アドレスの存在状況、発ポート番号の存在状況の順に判断をすることにより（ステップ１１〜ステップ１５）、各要素に応じた細かな設定をすることが可能となるため、サービスを停止することによる悪影響を最小限に抑えることができる。
【００５０】
また、発着アドレスの組み合わせの存在状況、発アドレスの存在状況、着アドレスの存在状況、発ポート番号の存在状況に合わせて、処理の優先度を通常よりも低く設定することにより（ステップ１９、ステップ２２、ステップ２５、ステップ２８）、攻撃の可能性がある入力イベント２２の処理を遅らせることができる。さらに、処理を遅らせた結果、処理待ちによるタイムアウトが発生することで、攻撃の可能性がある入力イベント２２を減少させることができる。
【００５１】
また、発着アドレスの組み合わせの存在状況、発アドレスの存在状況、着アドレスの存在状況、発ポート番号の存在状況が連続して過剰に存在すると判断された場合に、当該イベントを廃棄することにより（ステップ２０、ステップ２３、ステップ２６、ステップ２９）、リソースが落ちてしまうことを防ぐことができるため、その結果、リソースの保護を図ることができる。
【００５２】
[３．変形例]
[３−１．第一変形例]
上述した実施形態においては、入力イベント２２の情報に発アドレスが要素として含まれているが、入力イベント２２の情報要素には必ずしも発アドレスが含まれていなくてもよい。発アドレスが含まれていない場合は、発アドレスによる判断を除いて処理を行えば、上述の実施形態と同様の効果を得ることができる。
【００５３】
[３−２．第二変形例]
上述した実施形態における、スケジューラ２１は、予め定められたスケジュールに従って、優先度が設定されたキュー２０ａ〜２０ｅから入力イベント２２を順次取り出しているが、上述のキュー２０ａ〜２０ｅとは別に緊急用のキューを設定しておき、緊急用のキューに入力イベント２２が登録された場合には、各周期ごとに緊急用のキューから入力イベント２２を取り出すようにしてもよい。これにより、急を要する特別な処理を行う場合には、他の入力イベント２２が多数存在して、キューが混んでいるときでも、優先的に処理が行えるようになる。
【００５４】
[３−３．第三変形例]
上述した実施形態においては、キュー２０ａ〜２０ｅに登録する情報は、入力イベント２２に対応づけられたインデックスであるが、入力イベント２２の情報そのものでもよい。要するに、各キュー２０ａ〜２０ｅに対して、どのような入力イベント２２が登録されているのかが判別できればよい。
【００５５】
[３−４．第四変形例]
上述した実施形態においては、スケジューラ２１が、入力イベント２２をキュー２０ａ〜２０ｅから１つずつ取り出しているが、一度に複数の入力イベント２２を取り出してもよい。要するに、優先順位に従って、順次、入力イベント２２の処理が行えればよい。
【００５６】
[３−５．第五変形例]
上述した実施形態においては、イベント受付部１２とイベント送出部１３が別個に存在しているが、構成上１つにまとめてもよい。要するに、発信側の端末と着信側の端末との送受信が行える機能が備わっていればよい。
【００５７】
【発明の効果】
上述したように本発明によれば、外部から攻撃を受けても交換局内にあるリソースの保護を行い、さらに、利用者へのサービスの提供も継続する通信制御装置および通信制御装置の制御方法を提供することができる。
【図面の簡単な説明】
【図１】本発明の実施形態である通信制御装置の機能構成を示す図である。
【図２】同実施形態におけるイベント受付部とリソース保護部の詳細構成を示す図である。
【図３】同実施形態におけるリソース保護部が、サービスの継続を目的とした場合の判断基準の有効度に基づいて優先度を決定する例１を示す図である。
【図４】同実施形態におけるリソース保護部が、サービスの継続を目的とした場合の判断基準の有効度に基づいて優先度を決定する例２を示す図である。
【図５】同実施形態におけるリソース保護部の動作例を示すフローチャートである。
【符号の説明】
１・・・・通信制御装置
２・・・・端末（送信端末、受信端末）
１２・・・イベント受付部
１６・・・リソース保護部
２０・・・キュー（待ち行列手段）
２２・・・入力イベント（入力情報）
２３・・・イベント制御部（制御部）
２１・・・スケジューラ（処理手段）
Claims (4)
- ネットワーク中に介在し、送信端末と受信端末とを接続する通信制御装置において、
優先度が設定された複数の待ち行列手段と、
前記送信端末から受信した入力情報を分類して前記待ち行列手段のいずれかに割り当てる制御手段と、
前記各待ち行列手段に割り当てられた前記入力情報を前記各待ち行列手段の優先度に応じて順次、処理する処理手段と、
を具備し、
前記制御手段は、
前記送信端末から前記入力情報を受信すると、通信制御用のリソースに空きがあるか否かを判定し、
前記リソースに空きがあれば、前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがあるか否かを判定し、同一となる組があり且つその同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第２位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、
前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一となるものがあるか否かを判定し、同一となる発アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第３位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、
前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがあるか否かを判定し、同一となる着アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第４位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、
前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがあるか否かを判定し、同一となる発ポート番号があり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第５位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、
前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがなければ、受信した前記入力情報を第１位の優先度が設定された前記待ち行列手段に割り当てる
ことを特徴とする通信制御装置。 - 第２位以下の優先度が設定された複数の待ち行列手段に対し、当該複数の待ち行列手段に割り当てられた前記入力情報の数が多いほど高い優先度を設定する設定手段を備えることを特徴とする請求項１記載の通信制御装置。
- ネットワーク中に介在し、送信端末と受信端末とを接続する通信制御装置であって、優先度が設定された複数の待ち行列手段と、前記送信端末から受信した入力情報を分類して前記待ち行列手段のいずれかに割り当てる制御手段と、前記各待ち行列手段に割り当てられた前記入力情報を前記各待ち行列手段の優先度に応じて順次、処理す る処理手段とを具備する通信制御装置の制御方法において、
前記制御手段は、
入力情報を受け取ると、通信制御用のリソースに空きがあるか否かを判定し、
前記リソースに空きがあれば、前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがあるか否かを判定し、同一となる組があり且つその同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第２位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、
前記複数の待ち行列手段に割り当てられた入力情報の発着アドレスの組の中に、受信した前記入力情報の発着アドレスの組と同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一となるものがあるか否かを判定し、同一となる発アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第３位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、
前記複数の待ち行列手段に割り当てられた入力情報の発アドレスの中に、受信した前記入力情報の発アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがあるか否かを判定し、同一となる着アドレスがあり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第４位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、
前記複数の待ち行列手段に割り当てられた入力情報の着アドレスの中に、受信した前記入力情報の着アドレスと同一となるものがなければ、前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがあるか否かを判定し、同一となる発ポート番号があり且つ同一となる回数が予め定めた設定回数を超えていなければ、受信した前記入力情報を第５位の優先度が設定された前記待ち行列手段に割り当てる一方、前記同一となる回数が前記設定回数を超えていれば、受信した前記入力情報を廃棄し、
前記複数の待ち行列手段に割り当てられた入力情報の発ポート番号の中に、受信した前記入力情報の発ポート番号と同一となるものがなければ、受信した前記入力情報を第１位の優先度が設定された前記待ち行列手段に割り当てる
ことを特徴とする通信制御装置の制御方法。 - 前記通信装置の設定手段が、第２位以下の優先度が設定された複数の待ち行列手段に対し、当該複数の待ち行列手段に割り当てられた前記入力情報の数が多いほど高い優先度を設定することを特徴とする請求項３記載の制御方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP02017199A JP4102502B2 (ja) | 1999-01-28 | 1999-01-28 | 通信制御装置および通信制御装置の制御方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP02017199A JP4102502B2 (ja) | 1999-01-28 | 1999-01-28 | 通信制御装置および通信制御装置の制御方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000224228A JP2000224228A (ja) | 2000-08-11 |
| JP4102502B2 true JP4102502B2 (ja) | 2008-06-18 |
Family
ID=12019739
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP02017199A Expired - Fee Related JP4102502B2 (ja) | 1999-01-28 | 1999-01-28 | 通信制御装置および通信制御装置の制御方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4102502B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4546807B2 (ja) * | 2004-11-17 | 2010-09-22 | パナソニック株式会社 | 情報家電、移動端末及びｐ２ｐ接続システム |
| JP5216249B2 (ja) * | 2007-06-12 | 2013-06-19 | 株式会社 ネクストジェン | 呼制御装置及び呼制御方法 |
| US11163737B2 (en) | 2018-11-21 | 2021-11-02 | Google Llc | Storage and structured search of historical security data |
-
1999
- 1999-01-28 JP JP02017199A patent/JP4102502B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000224228A (ja) | 2000-08-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6438135B1 (en) | Dynamic weighted round robin queuing | |
| US7420962B2 (en) | Method for management of voice-over IP communications of various relative priority levels | |
| US6320845B1 (en) | Traffic management and flow prioritization on a routed computer network | |
| US7525911B2 (en) | Congestion controller for Ethernet switch | |
| EP1641232B1 (en) | Call admission control in a VoIP network | |
| US7710877B2 (en) | Communication control system | |
| US8144588B1 (en) | Scalable resource management in distributed environment | |
| JPS63176045A (ja) | 輻湊制御型パケット交換方法及びその装置 | |
| CN101436987A (zh) | QoS服务的调度配置方法和装置 | |
| US9491302B2 (en) | Telephone call processing method and apparatus | |
| EP1757044A1 (en) | Packet queuing system and method | |
| Doshi et al. | Congestion Control in ISDN Frame‐Relay Networks | |
| JP3941763B2 (ja) | クライアントサーバ型サービスにおける輻輳制御システム | |
| JP4102502B2 (ja) | 通信制御装置および通信制御装置の制御方法 | |
| Gerla et al. | Flow control protocols | |
| Comer et al. | FLOWS: Performance guarantees in best effort delivery systems | |
| JP2002044136A (ja) | マルチプロトコルネットワーク用のフロー制御装置 | |
| JP2007329617A (ja) | 通信制御処理実行方法およびシステム、ならびにそのプログラム | |
| JP4536047B2 (ja) | アドミッション制御装置および方法 | |
| EP1414213B1 (en) | Packet classifier and processor in a telecommunication router | |
| JP3888453B2 (ja) | ネットワークシステム | |
| JP3492466B2 (ja) | 帯域可変制御方法 | |
| JP2007228161A (ja) | 無線ネットワーク制御装置のバッファ管理方法および無線ネットワーク制御装置 | |
| JP4275673B2 (ja) | 通信網における帯域制御方法およびその装置 | |
| Qadeer et al. | Differential allocation of Bandwidth to services based on priority |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051226 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070913 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070918 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071112 |
|
| 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: 20080318 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080324 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110328 Year of fee payment: 3 |
|
| 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: 20110328 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120328 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130328 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130328 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140328 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |