JP4627243B2 - ネットワーク中継装置 - Google Patents

Description

本発明は、各プロトコルのヘッダフィールド内の情報に基づいてレイヤ２フレームを転送するネットワーク中継装置に関するものであり、特に、ヘッダフィールドのパターン照合、およびヘッダフィールド情報の抽出に関するものである。

インターネットの基本は、ネットワークが全てのフレームを公平にあつかうＢｅｓｔ Ｅｆｆｏｒｔ型、すなわちサービスの品質を保証しない通信サービスである。しかし、インターネットの普及に伴い、インターネットを使用したビジネスが展開され高品質のサービスや音声、動画といったリアルタイム性を要求されるデータを扱うことが多くなっている。そのため、ネットワーク間に配置されレイヤ２フレームであるＭＡＣ（Media Access Control）フレームを転送するネットワーク中継装置においても、フレーム転送の高速化が要求されている。

サーバなどの負荷分散制御を行なうロードバランサーや、不正アクセスを検出、遮断するファイヤーウォールなどのネットワーク中継装置は、ネットワーク中継装置は、ＭＡＣフレーム内のＭＡＣヘッダ（レイヤ２ヘッダ）、ＩＰ（Internet Protocol）ヘッダなどのレイヤ３ヘッダ、ＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）ヘッダなどのレイヤ４ヘッダ、ＳＩＰ（Session Initiation Protocol）ヘッダなどのレイヤ５ヘッダ、ＳＤＰ（Session Description Protocol）などのレイヤ６ヘッダ、およびアプリケーションによって規定されるレイヤ７ヘッダに含まれる情報に基づいてフレーム転送を行なう。

ＭＡＣヘッダ、レイヤ３ヘッダ、およびレイヤ４ヘッダは、それぞれに設定されている情報、たとえば送信元アドレスや宛先アドレス、送信元ポート番号、宛先ポート番号が設定されている位置はヘッダ内で固定されている。そのため、ＭＡＣフレームの先頭からのビット数、またはバイト数をカウントすることで取得することができる。

しかしながら、レイヤ５以上のヘッダの一部においてはテキスト形式であるため、ＭＡＣフレームから複数のヘッダフィールドパターンを検索し、検索した各ヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報を抽出しなければならない。すなわち、入力データであるＭＡＣフレームから複数の文字列検索を行なわなければならない。

従来から、オートマトンやＮ−ｇｒａｍ、特徴ベクトルなどの文字列検索アルゴリズムを使用して入力データから複数の文字列を検索する種々の技術が考えられている。たとえば、特許文献１に記載の従来技術では、複数の種類のパターンから１つの決定性有限オートマトンを作成し、文字列検索時には、その一つの決定性オートマトンを使用して各種類のパターンを一度に検索する文字列検索方法に関する技術が開示されている。

特開平１０−２０７９１２号公報

しかしながら、上記特許文献１に記載の従来技術では、複数のパターンを１つのオートマトンで表現するために分岐が多くなり、つぎの状態への遷移先を特定する判定処理に時間がかかってしまう。そのため、上記特許文献１に記載の従来技術の文字列検索方法をネットワーク中継装置のヘッダフィールド情報の検索に用いた場合、ヘッダフィールド情報の抽出に時間がかかってしまい、フレーム転送の高速化を計ることは難しいという問題があった。

本発明は、上記に鑑みてなされたものであって、レイヤ２フレーム内から任意のプロトコルのヘッダフィールド情報を高速に抽出して、フレームの転送処理時間を短縮することができるネットワーク中継装置を得ることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、受信したレイヤ２フレーム内の各レイヤのヘッダからレイヤに応じたプロトコルのヘッダフィールド情報を抽出し、抽出したヘッダフィールド情報に基づいて前記レイヤ２フレームの転送先を選択するネットワーク中継装置において、前記レイヤ２フレームの一部を複製して複数のフレームデータを生成するフレーム複製部と、前記フレーム複製部によって生成されたフレームデータの１つを検索対象として検索対象のフレームデータから予め定められたヘッダフィールドパターンを検索し、前記検索対象のフレームデータ内に前記ヘッダフィールドパターンを検出した場合には、検出したヘッダフィールドパターンに対応付けて検索対象のフレームデータに設定されているヘッダフィールド情報を抽出する複数の検索部と、前記複数の検索部が検出したヘッダフィールドパターンおよび抽出したヘッダフィールド情報を検索結果として出力する検索結果統合部と、を有するヘッダ抽出ユニットと、前記レイヤ２フレームの転送先の識別に有用な情報である転送先識別情報と、前記検索結果統合部が出力する検索結果とに基づいて、前記受信したレイヤ２フレームの転送先を選択して送信する転送ユニットとを備えることを特徴とする。

なお、上記転送先識別情報とは、たとえば、レイヤ３ヘッダ内の宛先アドレス、送信元アドレス、およびプロトコルと、レイヤ４ヘッダ内の宛先ポート番号および送信元ポート番号や、ＶＬＡＮ―ＩＤ（Virtual Local Area Network IDentification）など、レイヤ２フレームの転送先の識別に有用な情報である。

また、本発明の説明においてレイヤ２のプロトコルをＭＡＣフレームとして記述しているが、ＭＡＣフレームだけに限定するものではなく、たとえば、ＡＴＭ（Asynchronous Transfer Mode）やＦＤＤＩ（Fiber-Distributed Data Interface）といった他のレイヤ２プロトコルであってもかまわない。

この発明によれば、レイヤ２フレームの一部を複製して生成されたフレームデータ毎に、それぞれ異なるヘッダフィールドパターンを用いてフレームデータからヘッダフィールドパターンを検出し、検出したヘッダフィールドパターンに対応付けてフレームデータに設定されているヘッダフィールド情報を抽出する検索部を複数備えてヘッダフィールド情報の抽出を並列に処理するようにしているため、１つの検索部で異なるヘッダフィールドパターンを検出する場合と比較して、レイヤ２フレーム内から任意のプロトコルのヘッダフィールド情報を高速に抽出して、フレームの転送処理時間を短縮することができるネットワーク中継装置を得ることができるという効果を奏する。

以下に、本発明にかかるネットワーク中継装置の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。

実施の形態１．
図１〜図８を参照してこの発明の実施の形態１を説明する。図１は、この発明における実施の形態１のネットワーク中継装置が適用される通信システムの構成の一例を示す図である。図１において、通信システムは、ネットワーク中継装置であるロードバランサー１と、複数（この場合は３台）のサーバ４１ａ〜４１ｃを有するｗｅｂサーバ群４と、インターネットなどのネットワーク３と、複数（この場合は２台）の通信端末２ａ，２ｂとを備えている。

ロードバランサー１は、リンク５ａによってネットワーク３に接続されるとともに、リンク５ｂ〜５ｄによってサーバ４１ａ〜４１ｃと接続され、通信端末２ａ，２ｂは、リンク５ｅ，５ｆによってネットワーク３に接続されており、通信端末２ａ，２ｂとサーバ４１ａ〜４１ｃとは、リンク５（５ａ〜５ｆを示す）、ネットワーク３、およびロードバランサー１を介して相互通信を実現している。

図２は、図１に示した通信システムで用いるレイヤ２フレームであるＭＡＣ（Media Access Control）フレームのフォーマットを示す図である。図２において、ＭＡＣフレームは、宛先ＭＡＣアドレスや送信元ＭＡＣアドレス、フレーム長やタイプなどの情報が設定されるＭＡＣヘッダ６１と、ＩＰ（Internet Protocol）などのネットワーク層（レイヤ３）における宛先ＩＰアドレスや送信元ＩＰアドレス、プロトコルなどの情報が設定されるレイヤ３ヘッダ６２と、ＴＣＰ（Transmission Control Protocol）やＵＤＰ（User Datagram Protocol）などのトランスポート層（レイヤ４）における宛先ポート番号や送信元ポート番号などの情報が設定されるレイヤ４ヘッダ６３と、ＳＩＰ（Session Initiation Protocol）やＨＴＴＰ（HyperText Transfer Protocol）、ＦＴＰ（File Transfer Protocol）などセッション層（レイヤ５）における各プロトコルで定められた情報が設定されるレイヤ５ヘッダ６４と、データ６５と、フレーム転送中においてフレームが壊れていないかを判定するために使われるＦＣＳ（Frame Check Sequence）６６とで構成される。なお、データ６５内には、さらにレイヤ６ヘッダやレイヤ７ヘッダとユーザデータとが含まれている。

図３は、図２に示したレイヤ３ヘッダ６２のフォーマットの一例を示す図である。図３に示したレイヤ３ヘッダ６２は、ＩＰｖ４ヘッダであり、ＩＰプロトコルのバージョンを示す４ビットのバージョン（Ｖｅｒ）と、ＩＰヘッダフィールドの大きさを示す４ビットインターネットヘッダ長（ＩＨＬ）と、ＩＰデータグラムが要求するサービス品質を示す１バイトのサービスタイプ（ＴＯＳ）と、ＩＰヘッダおよびＩＰデータの長さを示す２バイトのトータル長（Ｔｏｔａｌ Ｌｅｎｇｔｈ）と、上位層から各ＩＰデータを識別するための２バイトの識別子（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）と、ＩＰデータの分割に関する情報を示す３ビットのフラグ（Ｆｌａｇ）と、各フラグメントのオリジナルデータにおける位置を示す１３ビットのフラグメント・オフセット（Ｆｌａｇｍｅｎｔ Ｏｆｆｓｅｔ）と、通過可能なルータの残り数を示す１バイトの生存時間（ＴＴＬ）と、ＩＰデータに含むＩＰの上位プロトコルを識別するためのプロトコル種別コードを示す１バイトのプロトコルタイプ（Ｐｒｏｔｏｃｏｌ）と、ＩＰヘッダにおけるエラー検出のための２バイトのヘッダ・チェックサム（Ｈｅａｄｅｒ Ｃｈｅｃｋｓｕｍ）と、送信元のＩＰアドレスを示す４バイトの送信元ＩＰアドレス（Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ）と、宛先のＩＰアドレスを示す４バイトの宛先ＩＰアドレス（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ）と、ＩＰデータグラム伝送時にルータなどに依頼する処理を指定するオプション（Ｏｐｔｉｏｎ）と、オプション・フィールドを使用した場合のビット調整のデータが設定されるパディング（Ｐａｄｄｉｎｇ）とで構成される。

図４および図５は、先の図２に示したレイヤ４ヘッダ６３のフォーマットの一例を示す図である。図４に示したレイヤ４ヘッダ６３は、ＴＣＰヘッダであり、ＴＣＰを使用するアプリケーションに対する宛先ポート番号を示す２バイトの宛先ポート番号（Ｓｏｕｒｃｅ Ｐｏｒｔ）と、ＴＣＰを使用するアプリケーションに対する送信元ポート番号を示す２バイトの送信元ポート番号（Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ）と、送信データ・ストリーム中のデータセグメントのバイト位置を示す４バイトのシーケンス番号（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）と、受信した最上位のバイトの次のバイト位置を示す４バイトの確認応答番号（Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ Ｎｕｍｂｅｒ）と、セグメント内でのデータの開始位置を示す４ビットのオフセット（Ｏｆｆｓｅｔ）と、固定値「０」が設定される６ビットの予約（Ｒｅｓｅｒｖｅｄ）と、セグメントのタイプを示す６ビットのコード・ビット（Ｃｏｄｅ Ｂｉｔ）と、セグメント転送中の送受信バッファサイズの指定を示す２バイトのウィンドウ（Ｗｉｎｄｏｗ Ｓｉｚｅ）と、ＴＣＰヘッダにおけるセグメントのエラー検出のための２バイトのチェックサム（Ｃｈｅｃｋｓｕｍ）と、緊急データのストリーム上の終了バイト位置を示す２バイトのアージェント・ポインタ（Ｕｒｇｅｎｔ Ｐｏｉｎｔｅｒ）と、最大セグメント長などを示す（Ｏｐｔｉｏｎ）と、ビット調整のデータが設定されるパディング（Ｐａｄｄｉｎｇ）とで構成される。

図５に示したレイヤ４ヘッダ６３は、ＵＤＰヘッダであり、ＵＤＰを使用するアプリケーションに対する宛先ポート番号を示す２バイトの宛先ポート番号（Ｓｏｕｒｃｅ Ｐｏｒｔ）と、ＵＤＰを使用するアプリケーションに対する送信元ポート番号を示す２バイトの送信元ポート番号（Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ）と、データ長を示す２バイトのデータ長（Ｌｅｎｇｔｈ）と、ＵＣＰヘッダにおけるデータのエラー検出のための２バイトのチェックサム（Ｃｈｅｃｋｓｕｍ）とで構成される。

図６は、図２に示したレイヤ５ヘッダ６４のフォーマットの一例を示す図である。図６に示したレイヤ５ヘッダ６４はＳＩＰヘッダの一例である。図６において、ＳＩＰヘッダは、ＳＩＰクライアントからユーザまたはサービスに対するコールセッションへの参加要求を出力させるＩＮＶＩＴＥと、要求によって取られるパスを示すＶｉａ：と、要求メッセージの転送の残り回数を示すＭａｘ−Ｆｏｒｗａｒｄｓ：と、要求の受信者を識別するための情報を示すＴｏ：と、要求の発信者を識別するための情報を示すＦｒｏｍ：と、特定のクライアントに関する特定のインビテーションまたは全ての登録を一意に認識させるＣａｌｌ−ＩＤ：と、セッション開始から１ずつインクリメントされる連続番号（セッション開始時は１）と、メソッドが登録されるＣＳｅｑ：と、以後のリクエストの送信先を示すＣｏｎｔａｃｔ：と、メッセージの本体のメディア・タイプを示すＣｏｎｔｅｎｔ−Ｔｙｐｅ：と、メッセージの本体のサイズを示すＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：とで構成される。

図１に戻って、ロードバランサー１は、リンク５を介して受信したＭＡＣフレーム（図２参照）内の転送先識別情報（レイヤ３ヘッダ内の宛先アドレス、送信元アドレス、およびプロトコルと、前記ＭＡＣフレーム内のレイヤ４ヘッダ内の宛先ポート番号および送信元ポート番号等といった転送先の識別に有用な情報）、およびレイヤ５ヘッダ６４、データ６５からＭＡＣフレームの転送に必要な情報を抽出し、抽出した情報に基づいて受信したＭＡＣフレームを送信する。

図７は、ロードバランサー１の構成を示すブロック図である。図７において、ロードバランサー１は、複数（この場合は２つ）の送受信ユニット１１−１，１１−２と、転送ユニット１２−１，１２−２と、ヘッダ抽出ユニット１３とを備えている。

送受信ユニット１１−１，１１−２は、リンク５のインタフェース機能を備えており、通信端末２ａ，２ｂ、またはサーバ４１ａ〜４１ｃからのＭＡＣフレームを受信すると、受信したＭＡＣフレームを転送ユニット１２−１，１２−２に出力する。また、送受信ユニット１１−１，１１−２は、転送ユニット１２−１，１２−２から入力される通信端末２ａ，２ｂまたはサーバ４１ａ〜４１ｃへのＭＡＣフレームをリンク５に送信する。

転送ユニット１２−１，１２−２は、送受信ユニット１１−１，１１−２から入力されるＭＡＣフレームのレイヤ５ヘッダ６４、およびデータ６５、すなわちＭＡＣフレームからＭＡＣヘッダ６１、レイヤ３ヘッダ６２、レイヤ４ヘッダ６３、およびＦＣＳ６６を除いたフレームデータをヘッダ抽出ユニット１３に出力する。また、ＭＡＣフレームの転送先識別情報（レイヤ３ヘッダ内の宛先アドレス、送信元アドレス、およびプロトコルと、前記ＭＡＣフレーム内のレイヤ４ヘッダ内の宛先ポート番号および送信元ポート番号等といった転送先の識別に有用な情報）から転送処理に必要な情報を抽出する。具体的には、転送ユニット１２−１，１２−２は、レイヤ３ヘッダ６２から宛先ＩＰアドレス、送信元ＩＰアドレス、およびプロトコルを抽出し、レイヤ４ヘッダ６３から宛先ポート番号および送信元ポート番号を抽出する。

転送ユニット１２−１，１２−２は、抽出した宛先ＩＰアドレス、送信元ＩＰアドレス、プロトコル、宛先ポート番号、および送信元ポート番号と、ヘッダ抽出ユニット１３からの検索結果と、予め定められているルーティング情報とに基づいて、ＭＡＣフレームのルーティング判定処理を実行してＭＡＣフレームを送信する送受信ユニット１１−１，１１−２を選択する。転送ユニット１２−１，１２−２は、ＭＡＣフレームを選択した送受信ユニット１１−１，１１−２に出力する。

ヘッダ抽出ユニット１３は、転送ユニット１２−１，１２−２から入力されるフレームデータ内に、予め定め登録されているヘッダフィールドパターンと一致するパターンを検索する。ヘッダ抽出ユニット１３は、フレームデータ内にヘッダフィールドパターンと一致するパターンを検出した場合には、ヘッダフィールドパターンと、フレームデータ内の当該ヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報とを検索結果として転送ユニット１２−１，１２−２に出力する。

図８は、ヘッダ抽出ユニット１３の構成を示すブロック図である。図８において、ヘッダ抽出ユニット１３は、入出力制御部１３１と、コピー部１３２（特許請求の範囲でいうところのフレーム複製部）と、ｎ（１＜ｎ，ｎは自然数）個の検索部１３３−１〜１３３−ｎと、検索結果統合部１３４とを備えている。

入出力制御部１３１は、転送ユニット１２−１，１２−２から入力されるフレームデータを調停してコピー部１３２に出力するとともに、検索結果統合部１３４から出力される検索結果を転送ユニット１２−１，１２−２に出力する。

コピー部１３２は、入出力制御部１３１から出力されるデータフレームをｎ個（検索部１３３−１〜１３３−ｎの数だけ）コピーして、検索部１３３−１〜１３３−ｎにそれぞれ１つのデータフレームを出力する。また、コピー部１３２は、検索開始通知および検索終了通知を検索結果統合部１３４に出力する。

検索部１３３−１〜１３３−ｎには、予めそれぞれ異なるヘッダフィールドパターンが１つ登録されている。検索部１３３−１〜１３３−ｎは、コピー部１３２から入力されるフレームデータ内から自身に登録されているヘッダフィールドパターンを検索する。検索部１３３−１〜１３３−ｎは、フレームデータ内にヘッダフィールドパターンと一致するパターンを検出した場合には、ヘッダフィールドパターンと、フレームデータ内の当該ヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報とを検索結果統合部１３４に出力する。検索部１３３−１〜１３３−ｎは、フレームデータ内にヘッダフィールドパターンと一致するパターンを検出することができなかった場合には、検索結果統合部１３４に対して何も出力を行なわない。

検索結果統合部１３４は、コピー部１３２から検索開始通知を受けてから検索終了通知を受けるまでの間に検索部１３３−１〜１３３−ｎから入力されるヘッダフィールドパターンとヘッダフィールド情報とを統合する。検索結果統合部１３４は、統合したヘッダフィールドパターンとヘッダフィールド情報とを検索結果として入出力制御部１３１に出力する。

つぎに、図１〜図８を参照して、この実施の形態１のロードバランサー１の動作について説明する。送受信ユニット１１−１，１１−２は、リンク５を介して通信端末２ａ，２ｂ、またはサーバ４１ａ〜４１ｃが送信したＭＡＣフレームを受信する。送受信ユニット１１−１，１１−２は、受信したＭＡＣフレームを転送ユニット１２−１，１２−２に出力する。

転送ユニット１２−１，１２−２は、送受信ユニット１１−１，１１−２から入力されたＭＡＣフレームのフレームデータを入出力制御部１３１に出力する。入出力制御部１３１は、転送ユニット１２−１，１２−２から入力されるフレームデータを調停してコピー部１３２に出力する。

コピー部１３２は、入出力制御部１３１から入力されたフレームデータをｎ個コピーする。コピー部１３２は、コピーしたフレームデータを検索部１３３−１〜１３３−ｎに１つずつ出力するとともに、検索開始通知を検索結果統合部１３４に出力する。

検索部１３３−１〜１３３−ｎは、予め所定のプロトコル（ここでは、ＳＩＰ）のヘッダフィールドパターンが１つずつ登録されている。検索部１３３−１〜１３３−ｎは、コピー部１３２から入力されるフレームデータ内から自身に登録されているヘッダフィールドパターンを検索する。検索部１３３−１〜１３３−ｎは、フレームデータ内にヘッダフィールドパターンと一致するパターンを検出した場合には、ヘッダフィールドパターンと、検出したヘッダフィールドパターンに対応付けてフレームデータに設定されているヘッダフィールド情報とを検索結果統合部１３４に出力する。

具体的には、たとえば、検索部１３３−１にはヘッダフィールドパターンとして「ＩＮＶＩＴＥ」が登録され、検索部１３３−２にはヘッダフィールドパターンとして「Ｔｏ：」が登録されているものとする。

検索部１３３−１は、ヘッダフィールドパターン「ＩＮＶＩＴＥ」を検索キーとして、コピー部１３２から入力されたフレームデータを検索する。フレームデータ内には、先の図６に示したＳＩＰヘッダが含まれている。検索部１３３−１は、ＳＩＰヘッダ内の「ＩＮＶＩＴＥ」を検出する。検索部１３３−１は、ヘッダフィールドパターン「ＩＮＶＩＴＥ」とＳＩＰヘッダ内に「ＩＮＶＩＴＥ」に対応付けられているヘッダフィールド情報である「ｓｉｐ：ｂｏｂ＠ｂｉｌｏｘｉ．ｃｏｍ ＳＩＰ／２．０」を検索結果統合部１３４に出力する。

一方、検索部１３３−２は、ヘッダフィールドパターン「Ｔｏ：」を検索キーとして、コピー部１３２から入力されたフレームデータを検索する。検索部１３３−２は、ＳＩＰヘッダ内の「Ｔｏ：」を検出する。検索部１３３−２は、ヘッダフィールドパターン「Ｔｏ：」とＳＩＰヘッダ内に「Ｔｏ：」に対応付けられているヘッダフィールド情報である「Ｂｏｂ＜ｓｉｐ：ｂｏｂ＠ｂｉｌｏｘｉ．ｃｏｍ＞を検索結果統合部１３４に出力する。

コピー部１３２は、検索開始通知を出力してから図示していない自装置内の計時機能を用いて所定の時間を計測する。所定の時間とは、検索部１３３−１〜１３３−ｎがフレームデータ内からヘッダフィールドパターンを検出するために必要な時間以上である。コピー部１３２は、検索開始通知を出力してから所定の時間が経過した後に、検索終了通知を検索結果統合部１３４に出力する。

検索終了通知を受けると、検索結果統合部１３４は、検索開始通知を受けてから検索終了通知を受けるまでの間に検索部１３３−１〜１３３−ｎから入力されたヘッダフィールドパターンと当該ヘッダフィールドパターンに対応付けられたヘッダフィールド情報との組を全て検索結果として入出力制御部１３１に出力する。入出力制御部１３１は、検索結果統合部１３４から入力された検索結果を、検索対象となるフレームデータを入力した転送ユニット１２−１，１２−２に出力する。

一方、転送ユニット１２−１，１２−２は、ＭＡＣフレームのフレームデータを入出力制御部１３１に出力する際に、ＭＡＣフレームから転送先識別情報（レイヤ３ヘッダ内の宛先アドレス、送信元アドレス、およびプロトコルと、前記ＭＡＣフレーム内のレイヤ４ヘッダ内の宛先ポート番号および送信元ポート番号等といった転送先の識別に有用な情報）を抽出している。たとえば、レイヤ３ヘッダ６２が先の図３に示したＩＰヘッダの場合、プロトコルタイプに設定されているプロトコルと、送信元ＩＰアドレスに設定されている送信元ＩＰアドレスと、宛先ＩＰアドレスに設定されている宛先ＩＰアドレスとを抽出している。また、レイヤ４ヘッダ６３が、先の図４に示したＴＣＰヘッダ、または先の図５に示したＵＤＰヘッダの場合、宛先ポート番号に設定されている宛先ポート番号、および送信元ポート番号に設定されている送信元ポート番号を抽出している。レイヤ３ヘッダ６２およびレイヤ４ヘッダ６３においては、プロトコルや送信元ＩＰアドレス、宛先アドレス、宛先ポート番号、送信元ポート番号の設定位置は固定である。したがって、転送ユニット１２−１，１２−２は、それぞれのヘッダの先頭からのビット数またはバイト数をカウントすることで転送処理に必要な情報である転送先識別情報（プロトコルや送信元ＩＰアドレス、宛先アドレス、宛先ポート番号、送信元ポート番号等）を抽出することができる。

転送ユニット１２−１，１２−２は、レイヤ３ヘッダ６２、およびレイヤ４ヘッダ６３から抽出した転送処理に必要な情報である転送先識別情報と、入出力制御部１３１から入力される検索結果と、予め定められているルーティング情報とに基づいて、ＭＡＣフレームのルーティング判定処理を実行してＭＡＣフレームを送信する送受信ユニット１１−１，１１−２を選択する。このルーディング判定処理は、サーバ４１ａ〜４１ｃの負荷分散などを考慮した判定処理であるが、一般的なロードバランサーの処理であるのでここではその説明を省略する。転送ユニット１２−１，１２−２は、ＭＡＣフレームを選択した送受信ユニット１１−１，１１−２に出力する。送受信ユニット１１−１，１１−２は、転送ユニット１２−１，１２−２から入力されたＭＡＣフレームをリンク５に送信する。

このようにこの実施の形態１においては、ＭＡＣフレームのレイヤ５ヘッダ６４、およびデータ６５をｎ個コピー（複製）して生成されたフレームデータ毎に、それぞれ異なるヘッダフィールドパターンを用いてフレームデータからヘッダフィールドパターンを検出し、検出したヘッダフィールドパターンに対応付けてフレームデータに設定されているヘッダフィールド情報を抽出する検索部１３３−１〜１３３−ｎを備えてヘッダフィールド情報の抽出を並列に処理するようにしているため、１つの検索部で異なるヘッダフィールドパターンを検出する場合と比較して、ＭＡＣフレーム内から任意のプロトコルのヘッダフィールド情報を高速に抽出して、フレームの転送処理時間を短縮することができる。

なお、この実施の形態１においては、コピー部１３２が検索開始通知を出力してから所定の時間が経過した後に検索終了通知を検索結果統合部１３４に出力するようにしたが、コピー部１３２が検索終了通知を検索結果統合部１３４に出力するのではなく、検索部１３３−１〜１３３−ｎが、それぞれフレームデータの検索を終了したことを通知する検索終了通知を検索結果統合部１３４、およびコピー部１３２に出力するようにしてもよい。この場合、検索結果統合部１３４は、コピー部１３２から検索開始通知を受けた後に、全ての検索部１３３−１〜１３３−ｎから検索終了通知を受けた時に、検索結果を転送ユニット１２−１，１２−２に出力すればよい。また、コピー部１３２は、全ての検索部１３３−１〜１３３−ｎから検索終了通知を受けた後に、入出力制御部１３１から入力された新たなフレームデータを検索部１３３−１〜１３３−ｎに出力するようにすればよい。

実施の形態２．
図９を参照してこの発明の実施の形態２を説明する。この発明における実施の形態２のネットワーク中継装置が適用される通信システムは、先の図１に示した実施の形態１の通信システムと同様であるのでここではその説明を省略する。

この実施の形態２のロードバランサー１は、先の図７に示した実施の形態１のロードバランサー１のヘッダ抽出ユニット１３の代わりに、ヘッダ抽出ユニット１３ａを備えている。図９は、この実施の形態２のロードバランサー１のヘッダ抽出ユニット１３ａの構成を示すブロック図である。

図９に示したヘッダ抽出ユニット１３ａは、先の図８に示した実施の形態１のロードバランサー１のヘッダ抽出ユニット１３の検索部１３３−１〜１３３−ｎに代えて、プロトコルＡのヘッダフィールドパターンが設定されている検索部１３５１−１〜１３５１−ｎを有する検索処理部１３５と、プロトコルＢのヘッダフィールドパターンが設定されている検索部１３６１−１〜１３６１−ｎを有する検索処理部１３６とを備えている。すなわち、この実施の形態２のロードバランサー１のヘッダ抽出ユニット１３ａは、複数（この場合は２つ）のプロトコルＡ，Ｂのヘッダフィールドパターンの抽出に対応するものである。なお、先の図８に示した実施の形態１のロードバランサー１のヘッダ抽出ユニット１３と同じ機能を持つ構成部分には同一符号を付し、重複する説明は省略する。

検索処理部１３５の検索部１３５１−１〜１３５１−ｎには、それぞれプロトコルＡの異なるヘッダフィールドパターンが１つ登録されている。たとえば、プロトコルＡがＳＩＰである場合、検索部１３５１−１〜１３５１−ｎには、それぞれＳＩＰヘッダの異なるヘッダフィールドパターンが１つ登録されている。

検索処理部１３６の検索部１３６１−１〜１３６１−ｎには、それぞれプロトコルＢの異なるヘッダフィールドパターンが１つ登録されている。たとえば、プロトコルＢがＳＤＰである場合、検索部１３６１−１〜１３６１−ｎには、それぞれＳＤＰヘッダの異なるヘッダフィールドパターンが１つ登録されている。

検索部１３５１−１〜１３５１−ｎ，１３６１−１〜１３６１−ｎは、コピー部１３２から入力されるフレームデータ内から自身に登録されているヘッダフィールドパターンを検索する。検索部１３５１−１〜１３５１−ｎ，１３６１−１〜１３６１−ｎは、フレームデータ内にヘッダフィールドパターンと一致するパターンを検出した場合には、ヘッダフィールドパターンと、フレームデータ内の当該ヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報とを検索結果統合部１３４に出力する。検索部１３５１−１〜１３５１−ｎ，１３６１−１〜１３６１−ｎは、フレームデータ内にヘッダフィールドパターンと一致するパターンを検出することができなかった場合には、検索結果統合部１３４に対して何も出力しない。

なお、この実施の形態２のロードバランサー１と、先の実施の形態１のロードバランサー１との相違点は、実施の形態１のロードバランサー１は、ヘッダ抽出ユニット１３内の検索部１３３−１〜１３３−ｎに１つのプロトコルに対するヘッダフィールドパターンが登録され１つのプロトコルのヘッダに対応するものであるのに対し、この実施の形態２のロードバランサー１は、ヘッダ抽出ユニット１３ａ内の検索部１３５１−１〜１３５１−ｎにプロトコルＡに対するヘッダフィールドパターンが登録され、検索部１３６１−１〜１３６１−ｎにプロトコルＢに対するヘッダフィールドパターンが登録され２つのプロトコルのヘッダに対するものである。すなわち、各検索部１３５１−１〜１３５１−ｎ，１３６１−１〜１３６１−ｎが検索するヘッダフィールドパターンが異なるだけであり、実施の形態１のロードバランサー１と実施の形態２のロードバランサー１との動作は同様のものとなるため、ここでは実施の形態２のロードバランサー１の動作の説明を省略する。

このようにこの実施の形態２においては、検索部１３５１−１〜１３５１−ｎを有する検索処理部１３５と、検索部１３６１−１〜１３６１−ｎを有する検索処理部１３６とを備え、検索処理部１３５はプロトコルＡのヘッダフィールドパターンを検索し、検索処理部１３６はプロトコルＡとは異なるプロトコルＢのヘッダフィールドパターンを検索するようにしている。すなわち、プロトコル毎に検索部をグループ化するようにしている。これにより、１つの検索部で異なるプロトコルのヘッダフィールドパターンを検出する場合と比較して、ＭＡＣフレーム内から異なるプロトコルのヘッダフィールド情報を高速に抽出して、フレームの転送処理時間を短縮することができる。

なお、この実施の形態２においては、検索処理部１３５が有する検索部１３５１−１〜１３５１−ｎと、検索処理部１３６が有する検索部１３６１−１〜１３６１−ｎの数をそれぞれｎ個としたが、検索処理部１３５の検索部の数と検索処理部１３６の検索部の数とは異なっていてもかまわない。

また、コピー部１３２が検索終了通知を検索結果統合部１３４に出力するのではなく、検索部１３５１−１〜１３５１−ｎ，１３６１−１〜１３６１−ｎが、それぞれフレームデータの検索を終了したことを通知する検索終了通知を検索結果統合部１３４、およびコピー部１３２に出力するようにしてもよい。この場合、検索結果統合部１３４は、コピー部１３２から検索開始通知を受けた後、全ての検索部１３５１−１〜１３５１−ｎ，１３６１−１〜１３６１−ｎから検索終了通知を受けた時に、検索結果を転送ユニット１２−１，１２−２に出力すればよい。また、コピー部１３２は、全ての検索部１３５１−１〜１３５１−ｎ，１３６１−１〜１３６１−ｎから検索終了通知を受けた後に、入出力制御部１３１から入力された新たなフレームデータを検索部１３３−１〜１３３−１に入力するようにすればよい。

実施の形態３．
図１０を参照してこの発明の実施の形態３を説明する。この発明における実施の形態３のネットワーク中継装置が適用される通信システムは、先の図１に示した実施の形態１の通信システムと同様であるのでここではその説明を省略する。

この実施の形態３のロードバランサー１は、先の図７に示した実施の形態１のロードバランサー１のヘッダ抽出ユニット１３の代わりに、ヘッダ抽出ユニット１３ｂを備えている。図１０は、この実施の形態３のロードバランサー１のヘッダ抽出ユニット１３ｂの構成を示すブロック図である。

図１０に示したヘッダ抽出ユニット１３ｂは、先の図８に示した実施の形態１のロードバランサー１のヘッダ抽出ユニット１３の検索部１３３−１〜１３３−ｎに代えて、プロトコルパターンテーブル１３７１および検索部１３７２を有するｘ（ｘは自然数）個の検索処理部１３７−１〜１３７−ｘを備えている。図８に示した実施の形態１のロードバランサー１のヘッダ抽出ユニット１３と同じ機能を持つ構成部分には同一符号を付し、重複する説明は省略する。

検索処理部１３７−１〜１３７−ｘのプロトコルパターンテーブル１３７１には、それぞれ異なるプロトコルのヘッダフィールドパターンが全て登録される。たとえば、検索処理部１３７−１がＳＩＰに対応する場合、検索処理部１３７−１のプロトコルパターンテーブル１３７１にはＳＩＰのヘッダフィールドパターンが全て登録され、検索処理部１３７−２がＳＤＰに対応する場合、検索処理部１３７−２のプロトコルパターンテーブル１３７１にはＳＤＰのヘッダフィールドパターンが全て登録される。

検索処理部１３７−１〜１３７−ｘの検索部１３７２は、コピー部１３２から入力されるフレームデータ内から、自身が存在する検索処理部１３７−１〜１３７−ｘのプロトコルパターンテーブル１３７１に登録されているヘッダフィールドパターンを検索する。検索部１３７２は、フレームデータ内に自身が存在する検索処理部１３７−１〜１３７−ｎのプロトコルパターンテーブル１３７２に登録されている全てのヘッダフィールドパターンの中の少なくとも１つと一致するパターンを検出した場合には、一致したヘッダフィールドパターンと、フレームデータ内の当該ヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報とを検索結果統合部１３４に出力する。検索部１３７２は、フレームデータ内にヘッダフィールドパターンと一致するパターンを検出することができなかった場合には、検索結果統合部１３４に対して何も出力を行なわない。

つぎに、図１０を参照してこの実施の形態３のロードバランサー１の動作を説明する。なお、この実施の形態３のロードバランサー１と先の実施の形態１のロードバランサー１の相違点は、ヘッダ抽出ユニット１３の代わりにヘッダ抽出ユニット１３ｂを備えていることであるので、ここでは、転送ユニット１２−１，１２−２からの入力されたフレームデータからヘッダフィールドパターンおよびヘッダフィールド情報を検索する動作、すなわちヘッダ抽出ユニット１３ｂの動作のみを説明する。

コピー部１３２は、入出力制御部１３１から入力されたフレームデータをｘ個コピーする。コピー部１３２は、コピーしたフレームデータを検索処理部１３７−１〜１３７−ｘの検索部１３７２に１つずつ出力するとともに、検索開始通知を検索結果統合部１３４に出力する。

検索処理部１３７−１の検索部１３７２は、検索処理部１３７−１のプロトコルパターンテーブル１３７１に登録されているヘッダフィールドパターンを読み出す。検索処理部１３７−１の検索部１３７２は、コピー部１３２から入力されるフレームデータ内から、読み出したヘッダフィールドパターンを検索する。

たとえば、検索処理部１３７−１のプロトコルパターンテーブル１３７１に、ＳＩＰのヘッダフィールドパターンとして「Ｔｏ：」および「Ｆｒｏｍ：」が登録されている場合、検索処理部１３７−１の検索部１３７２は、コピー部１３２から入力されるデータフレーム内から、ヘッダフィールドパターン「Ｔｏ：」、「Ｆｒｏｍ：」を検索する。そして、ヘッダフィールドパターン「Ｔｏ：」を検出した場合には、ヘッダフィールドパターン「Ｔｏ：」に対応付けられてフレームデータに設定されているヘッダフィールド情報（図６の場合は、「Ｂｏｂ：＜ｓｉｐ：ｂｏｂ＠ｂｉｌｏｘｉ。ｃｏｍ＞）を抽出し、ヘッダフィールドパターン「Ｔｏ：」と抽出したヘッダフィールド情報とを検索結果統合部１３４に出力する。さらにフィールドパターン「Ｆｒｏｍ：」を検出した場合には、ヘッダフィールドパターン「Ｆｒｏｍ：」に対応付けられてフレームデータに設定されているヘッダフィールド情報（図６の場合は、Ａｌｉｃｅ＜ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ。ｃｏｍ；ｔａｇ＝１９２８３０１７７４）を抽出し、ヘッダフィールドパターン「Ｆｒｏｍ：」と抽出したヘッダフィールド情報とを検索結果統合部１３４に出力する。また、検索部１３７２は、フレームデータ内にヘッダフィールドパターンと一致するパターンを１つも検出することができなかった場合には、検索結果統合部１３４に対して何も出力を行なわない。

検索処理部１３７−２〜１３７−ｘの検索部１３７２も、それぞれ検索処理部１３７−１の検索部１３７２と同様に、自身が存在する検索処理部１３７−２〜１３７−ｘのプロトコルパターンテーブル１３７１に登録されている全てのヘッダフィールドパターンについて、コピー部１３２から入力されるデータフレーム内を検索して、ヘッダフィールドパターンと一致するパターンを検出した場合には、一致したヘッダフィールドパターンと、ヘッダフィールドパターに対応付けられているヘッダフィールド情報を検索結果統合部１３４に出力する。

コピー部１３２は、検索開始通知を出力してから図示していない自装置内の計時機能を用いて所定の時間を計測する。所定の時間とは、検索処理部１３７−１〜１３７−ｘの検索部１３７２がフレームデータ内からヘッダフィールドパターンを検出するために必要な時間以上である。コピー部１３２は、検索開始通知を出力してから所定の時間が経過した後に、検索終了通知を検索結果統合部１３４に出力する。

検索終了通知を受けると、検索結果統合部１３４は、検索開始通知を受けてから検索終了通知を受けるまでの間に検索処理部１３７−１〜１３７−ｘの検索部１３７２から入力されたヘッダフィールドパターンと当該ヘッダフィールドパターンに対応付けられたヘッダフィールド情報との組を全て検索結果として入出力制御部１３１に出力する。入出力制御部１３１は、検索結果統合部１３４から入力された検索結果を、検索対象となるフレームデータを入力した転送ユニット１２−１，１２−２に出力する。

このようにこの実施の形態３においては、ヘッダフィールドパターンが複数登録されるプロトコルパターンテーブル１３７１と、プロトコルパターンテーブル１３７１に登録されているヘッダフィールドパターンを用いて検索対象のフレームデータを検索して、フレームデータからヘッダフィールドパターンを検出し、検出したヘッダフィールドパターンに対応付けてフレームデータに設定されているヘッダフィールド情報を抽出する検索部１３７２とを有する検索処理部１３７−１〜１３７−ｘを備え、検索処理部１３７−１〜１３７−ｘにそれぞれ異なるプロトコルを割当ててヘッダフィールド情報の抽出を並列に処理するようにしているため、１つの検索部で異なるプロトコルのヘッダフィールドパターンを検出する場合と比較して、ＭＡＣフレーム内から異なるプロトコルのヘッダフィールド情報を高速に抽出して、フレームの転送処理時間を短縮することができる。

なお、この実施の形態３においては、検索処理部１３７−１〜１３７−ｘのプロトコルパターンテーブル１３７１には、それぞれ異なるプロトコルのヘッダフィールドパターンを全て登録する場合を例に挙げて説明したが、検索処理部１３７−１〜１３７−ｘのプロトコルパターンテーブル１３７１に同一プロトコルのヘッダフィールドパターンが登録することを避ければ、１つの検索処理部１３７−１〜１３７−ｘのプロトコルパターンテーブル１３７１に複数のプロトコルのヘッダフィールドパターンを全て登録してもかまわない。

また、この実施の形態３においては、コピー部１３２が検索開始通知を出力してから所定の時間が経過した後に検索終了通知を検索結果統合部１３４に出力するようにしたが、コピー部１３２が検索終了通知を検索結果統合部１３４に出力するのではなく、検索処理部１３７−１〜１３７−ｘの検索部１３７２が、それぞれフレームデータの検索を終了したことを通知する検索終了通知を検索結果統合部１３４、およびコピー部１３２に出力するようにしてもよい。この場合、検索結果統合部１３４は、コピー部１３２から検索開始通知を受けた後に、全ての検索処理部１３７−１〜１３７−ｘの検索部１３７２から検索終了通知を受けた時に、検索結果を転送ユニット１２−１，１２−２に出力すればよい。また、コピー部１３２は、全ての検索処理部１３７−１〜１３７−ｘの検索部１３７２から検索終了通知を受けた後に、入出力制御部１３１から入力された新たなフレームデータを検索処理部１３７−１〜１３７−ｘの検索部１３７２に出力するようにすればよい。

実施の形態４．
図１１および図１２を用いてこの発明の実施の形態４を説明する。この発明におけるネットワーク中継装置が適用される通信システムは、先の図１に示した実施の形態１の通信システムと同様であるのでここではその説明を省略する。

この実施の形態４のロードバランサー１は、先の図７に示した実施の形態１のロードバランサー１のヘッダ抽出ユニット１３の代わりに、ヘッダ抽出ユニット１３ｃを備えている。図１１は、この実施の形態４のロードバランサー１のヘッダ抽出ユニット１３ｃの構成を示すブロック図である。

図１１において、ヘッダ抽出ユニット１３ｃは、入出力制御部１３１と、検索データ分割部１３８と、プロトコルパターンテーブル１４１と、ｎ個の検索部１４２−１〜１４２−ｎと、分割検索結果統合部１３９とを備えている。

入出力制御部１３１は、転送ユニット１２−１，１２−２から入力されるフレームデータを調停して検索データ分割部１３８に出力するとともに、検索結果統合部１３４から出力される検索結果を転送ユニット１２−１，１２−２に出力する。

検索データ分割部１３８は、入出力制御部１３１から入力されるフレームデータを予め定められた任意の文字数毎に分割し、分割したフレームデータ（分割フレームデータ）を分割した順番に検索部１４２−１〜１４２−ｎに出力する。また、検索データ分割部１３８は、分割フレームデータがフレームデータの何番目に位置するかの位置情報も分割フレームデータとともに検索部１４２−１〜１４２−ｎに出力する。また、検索データ分割部１３８は、分割検索結果統合部１３９からの分割フレームデータ要求によって分割フレームデータを分割検索結果統合部１３９に出力する。

プロトコルパターンテーブル１４１には、図１２に示すように、ヘッダフィールドパターンに対応付けてプロトコルが登録される。検索部１４２−１〜１４２−ｎは、検索データ分割部１３８から入力された分割フレームデータ内から、プロトコルパターンテーブル１４１に登録されているヘッダフィールドパターンを検索する。検索部１４２−１〜１４２−ｎは、分割フレームデータ内にヘッダフィールドパターンと一致するパターンを検出した場合には、分割フレームデータ内にヘッダフィールドパターンと一致するパターンを検出したことを通知する検出通知を出力する。このとき、検索部１４２−１〜１４２−ｎは、検索通知に分割フレームデータの位置情報と、ヘッダフィールドパターンとを含めておく。

分割検索結果統合部１３９は、検出通知を受けると分割フレームデータ要求を検索データ分割部１３８に出力して分割フレームデータを受け取る。分割検索結果統合部１３９は、受け取った分割フレームデータ内から検索通知に含まれるヘッダフィールドパターンを検索し、ヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報を抽出する。

つぎに、図１１を参照して、この実施の形態４のロードバランサー１の動作について説明する。なお、この実施の形態４のロードバランサー１と先の実施の形態１のロードバランサー１の相違点は、ヘッダ抽出ユニット１３の代わりにヘッダ抽出ユニット１３ｃを備えていることであるので、ここでは、転送ユニット１２−１，１２−２からの入力されたフレームデータからヘッダフィールドパターンおよびヘッダフィールド情報を検索する動作、すなわちヘッダ抽出ユニット１３ｃの動作のみを説明する。

入出力制御部１３１は、転送ユニット１２−１，１２−２から入力されるフレームデータを調停して検索データ分割部１３８に出力する。入出力制御部１３１からフレームデータが入力されると、検索データ分割部１３８は、検索開始通知を分割検索結果統合部１３９に出力する。検索データ分割部１３８は、入出力制御部１３１から入力されるフレームデータを予め定められた任意の文字数毎に分割して分割フレームデータを生成して、１つの検索部１４２−１〜１４２−ｎに対して１つの分割フレームデータと当該分割フレームデータの位置情報とをそれぞれ出力する。

具体的には、検索データ分割部１３８は、たとえば、分割した１番目の分割フレームデータと１番目の分割フレームの位置情報とを検索部１４２−１に出力し、２番目の分割フレームデータと２番目の分割フレームデータの位置情報とを検索部１４２−２に出力し、…、ｎ番目の分割フレームデータとｎ番目の分割フレームデータの位置情報とを検索部１４２−ｎに出力する。その後、検索データ分割部１３８は、検索部１４２−１〜１４２−ｎから検索終了通知を受けると、最初に検索終了通知を出力した検索部１４２−１〜１４２−ｎに、ｎ＋１番目の分割フレームデータとｎ＋１番目の分割フレームデータの位置情報とを出力し、２番目に検索終了通知を出力した検索部１４２−１〜１４２−ｎに、ｎ＋２番目の分割フレームデータとｎ＋２番目の分割フレームデータの位置情報とを出力するというように、フレームデータを任意の文字数で分割した分割フレームデータと当該分割フレームデータの位置情報とを、検索部１４２−１〜１４２−ｎの何れか一つに振り分ける。

検索部１４２−１〜１４２−ｎは、検索データ分割部１３８から入力された分割フレームデータ内から、プロトコルパターンテーブル１４１に登録されているヘッダフィールドパターンを検索する。検索部１４２−１〜１４２−ｎは、分割フレームデータ内にヘッダフィールドパターンと一致するパターンを検出した場合には、分割フレームデータ内にヘッダフィールドパターンと一致するパターンを検出したことを通知する検出通知を出力する。このとき検出通知に、分割フレームデータの位置情報と、ヘッダフィールドパターンとを含めておく。また、検索部１４２−１〜１４２−ｎは、分割フレームデータの検索が終了すると検索終了通知を検索データ分割部１３８、および分割検索結果統合部１３９に出力する。

プロトコルパターンテーブル１４１には、先の図１２に示したように、ヘッダフィールドパターンとして「Ｔｏ」および「ｏ：」が登録されている。たとえば、検索部１４２−１〜１４２−ｎは、検索データ分割部１３８から入力された分割フレームデータ内から、ヘッダフィールドパターン「Ｔｏ」、「ｏ：」を検索する。そして、ヘッダフィールドパターン「Ｔｏ」を検出した場合にはヘッダフィールドパターン「Ｔｏ」と分割フレームデータの位置情報とを含む検出通知を検索結果統合部１３４に出力する。さらにフィールドパターン「ｏ：」を検出した場合にはヘッダフィールドパターン「ｏ：」と分割フレームデータの位置情報とを含む検出通知を分割検索結果統合部１３９に出力する。また、検索部１４２−１〜１４２−ｎは、分割フレームデータの検索が終了すると検索終了通知を検索データ分割部１３８、および分割検索結果統合部１３９に出力する。

検索データ分割部１３８は、検索終了通知を受けると、前に分割して出力したフレームデータの直後から、また予め定められた任意の文字数毎に分割して分割フレームデータを生成し、その新たな分割フレームデータと当該分割フレームの位置情報とを検索終了通知を出力した検索部１４２−１〜１４２−ｎに出力する動作を、分割フレームデータがなくなるまで繰り返す。検索データ分割部１３８は、最後の分割フレームデータを検索部１４２−１〜１４２−ｎに出力した後に入力完了通知を分割検索結果統合部１３９、および検索部１４２−１〜１４２−ｎに出力する。

検索部１４２−１〜１４２−ｎは、入力完了通知を受けた時に既に分割フレームデータの検索が終了している場合には、検索終了通知を再度分割検索結果統合部１３９に出力し、入力完了通知を受けた時に分割フレームデータの検索中である場合には、検索中の分割フレームデータの検索が終了した後に、検索終了通知を分割検索結果統合部１３９に出力する。

一方、検索部１４２−１〜１４２−ｎから検出通知を受けると、分割検索結果統合部１３９は、検出通知内に含まれる分割フレームデータの位置情報を含む分割フレームデータ要求を検索データ分割部１３８に出力する。検索データ分割部１３８は、分割フレームデータ要求に含まれる分割フレームデータの位置情報に対応する分割フレームデータを分割検索結果統合部１３９に出力する。

分割検索結果統合部１３９は、検索データ分割部１３８から受け取った分割フレームデータ内から検索通知に含まれるヘッダフィールドパターンを検索し、ヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報を抽出する。分割検索結果統合部１３９は、ヘッダフィールドパターンとヘッダフィールド情報とを対応付けて記憶しておく。

分割検索結果統合部１３９は、検索開始通知を受けてから、入力完了通知を受けた後に全ての検索部１４２−１〜１４２−ｎからの検索終了通知を受けるまでの間、検索部１４２−１〜１４２−ｎから検出通知を受けると、検出通知内に含まれる分割フレームデータの位置情報を含む分割フレームデータ要求を検索データ分割部１３８に出力して分割フレームデータを受け取り、受け取った分割フレームデータからヘッダフィールドパターンを検索し、ヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報を抽出し、ヘッダフィールドパターンと抽出したヘッダフィールド情報とを対応付けて記憶する動作を繰り返す。

検索データ分割部１３８からの入力完了通知を受けた後に全ての検索部１４２−１〜１４２−ｎからの検索終了通知を受けると、分割検索結果統合部１３９は、記憶しているヘッダフィールドパターンとヘッダフィールド情報との組の全てを検索結果として入出力制御部１３１に出力する。入出力制御部１３１は、分割検索結果統合部１３９から入力された検索結果を、検索対象となるフレームデータを入力した転送ユニット１２−１，１２−２に出力する。

このようにこの実施の形態４においては、ＭＡＣフレームのレイヤ５ヘッダ６４、およびデータ６５を、予め定められた文字数ごとに分割して生成した分割フレームデータの１つを検索対象として、検索対象となる分割フレームデータからプロトコルパターンテーブルに登録されている複数のヘッダフィールドパターンを検出する検索部１４２−１〜１４２−ｎと、検索部１４２−１〜１４２−ｎが検出したヘッダフィールドパターンに対応付けて分割フレームデータに設定されているヘッダフィールド情報を抽出する分割検索結果統合部１３９と備え、ヘッダフィールド情報の抽出を並列に処理するようにしているため、１つの検索部で異なるヘッダフィールドパターンを検出する場合と比較して、ＭＡＣフレーム内から任意のプロトコルのヘッダフィールド情報を高速に抽出して、フレームの転送処理時間を短縮することができる。

実施の形態５．
図１３を参照してこの発明の実施の形態５を説明する。この発明における実施の形態５のネットワーク中継装置が適用される通信システムは、先の図１に示した実施の形態１の通信システムと同様であるのでここではその説明を省略する。

この実施の形態５のロードバランサー１は、先の図７に示した実施の形態１のロードバランサー１のヘッダ抽出ユニット１３の代わりに、ヘッダ抽出ユニット１３ｄを備えている。図１３は、この実施の形態５のロードバランサー１のヘッダ抽出ユニット１３ｄの構成を示すブロック図である。

図１３に示したヘッダ抽出ユニット１３ｄは、先の図８に示した実施の形態１のロードバランサー１のヘッダ抽出ユニット１３の検索部１３３−１〜１３３−ｎに代えて、プロトコルパターンテーブル１４３１および検索部１４３２を有するｍ（１＜ｍ，ｍは自然数）個の検索処理部１４３−１〜１４３−ｍを備えている。図８に示した実施の形態１のロードバランサー１のヘッダ抽出ユニット１３と同じ機能を持つ構成部分には同一符号を付し、重複する説明は省略する。

転送ユニット１２−１，１２−２は、ＭＡＣフレームのフレームデータを入出力制御部１３１に出力する際に、ＭＡＣフレームの転送先識別情報（レイヤ３ヘッダ内の宛先アドレス、送信元アドレス、およびプロトコルと、前記ＭＡＣフレーム内のレイヤ４ヘッダ内の宛先ポート番号および送信元ポート番号等といった転送先の識別に有用な情報）から転送処理に必要な情報を抽出し、ヘッダ抽出ユニット１３ｄにも出力する。

検索処理部１４３−１は検索対象となるプロトコルの中で最下位のプロトコルのヘッダフィールドパターンを検索し、検索処理部１４３−２は検索処理部１４３−１より１つ上位のプロトコルのヘッダフィールドパターンを検索し、…、検索処理部１４３−ｍは検索対象となるプロトコル中で最上位のプロトコルのヘッダフィールドパターンを検索する。

検索処理部１４３−１〜１４３−ｍは、プロトコルパターンテーブル１４３１と、検索部１４３２とを備えている。検索処理部１４３−１〜１４３−ｍのプロトコルパターンテーブル１４３１には、それぞれのプロトコルの順位に応じたプロトコルのヘッダフィールドパターンに対応付けられてプロトコル名が登録される。

検索処理部１４３−１〜１４３−ｍの検索部１４３２は、前段の検索処理部の検索部１４３２から通知されるプロトコル候補に対応するヘッダフィールドパターンを自身が存在する検索処理部１４３−１〜１４３−ｍのプロトコルパターンテーブルから読み出す。検索処理部１４３−１〜１４３−ｍの検索部１４３２は、コピー部１３２から入力されたフレームデータ内から読み出したヘッダフィールドパターンを検索する。検索処理部１４３−１〜１４３−ｍの検索部１４３２は、フレームデータ内にヘッダフィールドパターンと一致するパターンを検出した場合には、ヘッダフィールドパターンと、フレームデータ内の当該ヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報とを検索結果統合部１３４に出力する。検索処理部１４３−１〜１４３−ｍの検索部１４３２は、フレームデータ内にヘッダフィールドパターンと一致するパターンを検出することができなかった場合には、検索結果統合部１３４に対して検索終了通知を出力する。

なお、検索処理部１４３−１は、前段の検索処理部が存在しない。この場合は、転送ユニット１２−１，１２−２にて抽出した転送先識別情報（レイヤ３ヘッダ内の宛先アドレス、送信元アドレス、およびプロトコルと、前記ＭＡＣフレーム内のレイヤ４ヘッダ内の宛先ポート番号および送信元ポート番号等といった転送先の識別に有用な情報）から自身が検索するプロトコル候補を選択すればよい。

また、登録されているプロトコルのうち、レイヤ５になりうるプロトコル全てを検索するプロトコル候補とするようにしてもよい。

検索処理部１４３−１〜１４３−ｍの検索部１４３２は、検出したヘッダフィールドパターンおよびヘッダフィールド情報に基づいて上位プロトコル候補を抽出する。検索処理部１４３−１〜１４３−ｍの検索部１４３２は、抽出した上位プロトコル候補を後段の検索処理部の検索部１４３２に通知する。

つぎに、図１３を参照してこの実施の形態５のロードバランサー１の動作を説明する。なお、この実施の形態５のロードバランサー１と先の実施の形態１のロードバランサー１の相違点は、ヘッダ抽出ユニット１３の代わりにヘッダ抽出ユニット１３ｄを備えていることであるので、ここでは、転送ユニット１２−１，１２−２からの入力されたフレームデータからヘッダフィールドパターンおよびヘッダフィールド情報を検索する動作、すなわちヘッダ抽出ユニット１３ｄの動作のみを説明する。また、ここでは、転送ユニット１２−１，１２−２が、ＭＡＣフレームから抽出した転送先識別情報（レイヤ３ヘッダ内の宛先アドレス、送信元アドレス、およびプロトコルと、前記ＭＡＣフレーム内のレイヤ４ヘッダ内の宛先ポート番号および送信元ポート番号等といった転送先の識別に有用な情報）をフレームデータとともにヘッダ抽出ユニット１３に出力するものとする。

入出力制御部１３１は、転送ユニット１２−１，１２−２から入力されたフレームデータおよび転送先識別情報をコピー部１３２に出力する。コピー部１３２は、入出力制御部１３１から入力されたフレームデータをｍ個コピーする。コピー部１３２は、コピーしたフレームデータを検索処理部１４３−１〜１４３−ｍの検索部１４３２に１つずつ出力するとともに、検索開始通知を検索結果統合部１３４に出力する。また、コピー部１３２は、検索処理部１４３−１〜１４３−ｍの中で最下位のレイヤ（この場合は、レイヤ５）に対応付けられている検索処理部１４３−１の検索部１４３２に転送先識別情報を出力する。

検索処理部１４３−１の検索部１４３２は、転送先識別情報（フレームデータのレイヤ３ヘッダ６２のプロトコルタイプと、レイヤ４ヘッダ６３の宛先ポート番号および送信元ポート番号に設定されているプロトコル、宛先ポート番号、および送信元ポート番号等）に基づいて、自身が検索するレイヤ５のプロトコルを選択する。

検索処理部１４３−１の検索部１４３２は、選択したプロトコル候補のプロトコルに対応付けられているヘッダフィールドパターンを検索処理部１４３−１のプロトコルパターンテーブル１４３１から読み出す。検索処理部１４３−１の検索部１４３２は、フレームデータ内から読み出したヘッダフィールドパターンを検索する。たとえば、抽出したプロトコル、宛先ポート番号、および送信元ポート番号からレイヤ５のプロトコルであるＳＩＰを選択した場合、検索処理部１４３−１の検索部１４３２は、プロトコルパターンテーブル１４３１のプロトコルのＳＩＰに対応付けられているヘッダフィールドパターンを読み出す。そして、フレームデータ内から読み出したヘッダフィールドパターンを検索する。

検索処理部１４３−１の検索部１４３２は、フレームデータ内にヘッダフィールドパターンと一致するパターンを検出した場合には、ヘッダフィールドパターンと、フレームデータ内の当該ヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報とを検索結果統合部１３４に出力する。また、検索処理部１４３−１の検索部１４３２は、検出したヘッダフィールドパターン、当該ヘッダフィールドパターンに対応付けられているヘッダフィールド情報、およびヘッダフィールドパターンのプロトコルに基づいて、上位プロトコル（この場合は、プレゼンテーション層であるレイヤ６のプロトコル）候補を選択する。検索処理部１４３−１の検索部１４３２は、選択した上位プロトコル候補を後段の検索処理部１４３−２の検索部１４３２に通知する。

検索処理部１４３−２の検索部１４３２は、検索処理部１４３−１の検索部１４３２から通知された上位プロトコル候補のプロトコルに対応付けられているヘッダフィールドパターンを検索処理部１４３−２のプロトコルパターンテーブル１４３１から読み出す。たとえば、検索処理部１４３−１の検索部１４３２から上位プロトコル候補としてＳＤＰが通知された場合、検索処理部１４３−２の検索部１４３２は検索処理部１４３−２のプロトコルパターンテーブル１４３１からＳＤＰに対応付けられているヘッダフィールドパターンを読み出す。

検索処理部１４３−２の検索部１４３２は、フレームデータ内にヘッダフィールドパターンと一致するパターンを検出した場合には、ヘッダフィールドパターンと、フレームデータ内の当該ヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報とを検索結果統合部１３４に出力する。また、検索処理部１４３−２の検索部１４３２は、検出したヘッダフィールドパターン、当該ヘッダフィールドパターンに対応付けられているヘッダフィールド情報、およびヘッダフィールドパターンのプロトコルに基づいて、レイヤ６のプロトコル候補を選択する。検索処理部１４３−１の検索部１４３２は、選択したレイヤ６のプロトコル候補を上位プロトコル候補として後段の検索処理部の検索部１４３２に通知する。

このように、検索処理部１４３−２〜１４３−ｍの検索部１４３２は、前段の検索処理部１４３−１〜１４３−ｍ−１の検索部１４３２から通知された上位プロトコル候補に対応付けられて登録されているヘッダフィールドパターンを検索処理部１４３−２〜１４３−ｍのプロトコルパターンテーブル１４３１から読み出し、読み出したヘッダフィールドパターンをコピー部１３２から入力されたフレームデータから検出し、検出したヘッダフィールドパターンと当該ヘッダフィールドパターンに対応付けてフレームデータに設定されているヘッダフィールド情報とを検索結果統合部１３４に出力する。この処理は、上位プロトコルがなくなるまで続けられる。

コピー部１３２は、検索開始通知を出力してから図示していない自装置内の計時機能を用いて所定の時間を計測する。所定の時間とは、検索処理部１４３−１〜１４３−ｍの検索部１４３２がフレームデータ内からヘッダフィールドパターンを検出するために必要な時間以上である。コピー部１３２は、検索開始通知を出力してから所定の時間が経過した後に、検索終了通知を検索結果統合部１３４に出力する。

検索終了通知を受けると、検索結果統合部１３４は、検索開始通知を受けてから検索終了通知を受けるまでの間に検索処理部１４３−１〜１４３−ｍの検索部１４３２から入力されたヘッダフィールドパターンと当該ヘッダフィールドパターンに対応付けられたヘッダフィールド情報との組を全て検索結果として入出力制御部１３１に出力する。入出力制御部１３１は、検索結果統合部１３４から入力された検索結果を、検索対象となるフレームデータを入力した転送ユニット１２−１，１２−２に出力する。

このようにこの実施の形態５においては、ヘッダフィールドパターンに対応付けて当該ヘッダフィールドパターンを用いるプロトコルが登録されるプロトコルパターンテーブル１４３１と、上位プロトコル候補のプロトコルに対応付けてプロトコルパターンテーブル１４３１に登録されているヘッダフィールドパターンを用いて、検索対象のフレームデータからヘッダフィールドパターンを検出し、検出したヘッダフィールドパターンに対応付けて設定されているヘッダフィールド情報を抽出するとともに、検出したヘッダフィールドパターンおよびヘッダフィールド情報に基づいて１つ上位のプロトコルの候補を選択する検索部１４３２とを有する検索処理部１４３−１〜１４３−ｍを備え、この検索処理部１４３−１〜１４３−ｍをレイヤに対応付けておき、自身が存在する検索処理部１３４−１〜１４３−ｍより１つ下位のレイヤに対応付けられている検索処理部１４３−１〜１４３−ｍの検索部１４３２が選択した１つ上位のプロトコルの候補を上位プロトコル候補として用いるようにしている。これにより、検索すべきヘッダフィールドパターンの数を少なくすることが可能となり、ＭＡＣフレーム内から任意のプロトコルのヘッダフィールド情報を高速に抽出して、フレームの転送処理時間を短縮することができる。

なお、この実施の形態５においては、最下位のプロトコルのヘッダフィールドパターンを検索する検索処理部１４３−１の検索部１４３２に転送ユニット１２−１，１２−２が抽出した転送先識別情報を入力するようにしたが、転送ユニット１２−１，１２−２からの転送先識別情報を用いることなく、検索処理部１４３−１のプロトコルパターンテーブル１４３１に登録されているプロトコルの中で、最下位のプロトコルであるレイヤ５になりうるプロトコルを全てプロトコル候補として選択するようにしてもよい。

また、この実施の形態５においては、コピー部１３２が検索開始通知を出力してから所定の時間が経過した後に検索終了通知を検索結果統合部１３４に出力するようにしたが、コピー部１３２が検索終了通知を検索結果統合部１３４に出力するのではなく、検索処理部１４３−１〜１４３−ｍの検索部１４３２が、それぞれフレームデータの検索を終了したことを通知する検索終了通知を検索結果統合部１３４、およびコピー部１３２に出力するようにしてもよい。この場合、検索結果統合部１３４は、コピー部１３２から検索開始通知を受けた後に、全ての検索処理部１４３−１〜１４３−ｍの検索部１４３２から検索終了通知を受けた時に、検索結果を転送ユニット１２−１，１２−２に出力すればよい。また、コピー部１３２は、全ての検索処理部１４３−１〜１４３−ｍの検索部１４３２から検索終了通知を受けた後に、入出力制御部１３１から入力された新たなフレームデータを検索処理部１４３−１〜１４３−ｍの検索部１４３２に出力するようにすればよい。

実施の形態６．
図１４および図１５を用いてこの発明の実施の形態６を説明する。上述した実施の形態１〜５では、ネットワーク中継装置としてロードバランサーを例に挙げて説明した。この実施の形態６では、ネットワーク中継装置としてフィヤーウォールを用いる場合を説明する。

図１４は、この発明における実施の形態６のネットワーク中継装置が適用される通信システムの構成の一例を示す図である。図１４に示した通信システムは、先の図１に示した実施の形態１の通信システムのロードバランサー１の代わりに、ファイヤーウォール７とルータ８とを備えており、ファイヤーウォール７とネットワーク３とがリンク５ａによって接続され、ファイヤーウォール７とルータ８とはリンク５ｅによって接続され、ルータ８とサーバ４１ａ〜４１ｃとはリンク５ｂ〜５ｄによって接続されており、通信端末２ａ，２ｂは、リンク５ｇ，５ｆによってネットワーク３に接続されている。

この実施の形態６の通信システムで用いるＭＡＣフレームは、先の図２〜図６を用いて説明した実施の形態１の通信システムで用いるＭＡＣフレームと同一であるので、ここではその説明を省略する。

ファイヤーウォール７は、リンク５を介して受信したＭＡＣフレーム（図２参照）内の転送先識別情報（レイヤ３ヘッダ６２内の宛先アドレス、送信元アドレス、およびプロトコルと、前記ＭＡＣフレーム内のレイヤ４ヘッダ６３内の宛先ポート番号および送信元ポート番号等といった転送先の識別に有用な情報）、およびレイヤ５ヘッダ６５、データ６６からＭＡＣフレームの転送に必要な情報を抽出し、抽出した情報に基づいて受信したＭＡＣフレームを送信する。

図１５は、ファイヤーウォール７の構成を示すブロック図である。図１５に示したファイヤーウォール７は、先の図７に示した実施の形態１のロードバランサー１の転送ユニット１２−１，１２−２とヘッダ抽出ユニット１３との間にコード／デコードユニット７３−１，７３−２を備えている。図７に示した実施の形態１のロードバランサー１と同じ機能を持つ構成部分には同一符号を付し、重複する説明は省略する。

コード／デコードユニット７３−１，７３−２は、転送ユニット１２−１，１２−２から入力されるフレームデータを予め定められた圧縮アルゴリズムに基づいて圧縮し、圧縮したフレームデータ（圧縮フレームデータ）をヘッダ抽出ユニット１３に出力する。また、コード／デコードユニット７３−１，７３−２は、ヘッダ抽出ユニット１３から入力される検索結果を予め定められた圧縮アルゴリズムに基づいてデコードし、デコードした検索結果を転送ユニット１２−１，１２−２に出力する。

ヘッダ抽出ユニット１３は、先の実施の形態１では、フレームデータを検索対象としたが、この実施の形態６では、コード／デコードユニット７３−１，７３−２から入力される圧縮フレームデータを検索対象とする。すなわち、入出力制御部１３１は、コード／デコードユニット７３−１，７３−２から入力される圧縮フレームデータを調停してコピー部１３２に出力するとともに、検索結果統合部１３４から出力される検索結果をコード／デコードユニット７３−１，７３−２に出力する。コピー部１３２は、圧縮フレームデータをｎ個コピーして検索部１３３−１〜１３３−ｎにそれぞれ１つの圧縮フレームデータを出力する。

検索部１３３−１〜１３３−ｎには、予めそれぞれ異なるヘッダフィールドパターンを圧縮した圧縮ヘッダフィールドパターンが１つ登録され、圧縮フレームデータ内からこの圧縮ヘッダフィールドパターンを検索する。検索部１３３−１〜１３３−ｎは、圧縮フレームデータ内に圧縮ヘッダフィールドパターンと一致するパターンを検出した場合には、圧縮ヘッダフィールドパターンと、圧縮フレームデータ内の当該圧縮ヘッダフィールドパターンに対応付けて設定されている圧縮されたヘッダフィールド情報（圧縮ヘッダフィールド情報）とを検索結果統合部１３４に出力する。

検索結果統合部１３４は、コピー部１３２から検索開始通知を受けてから検索終了通知を受けるまでの間に検索部１３３−１〜１３３−ｎから入力される圧縮ヘッダフィールドパターンと、圧縮フレームデータ内の当該圧縮ヘッダフィールドパターンに対応付けて設定されている圧縮ヘッダフィールド情報とを統合する。検索結果統合部１３４は、統合した圧縮ヘッダフィールドパターンと、圧縮フレームデータ内の当該圧縮ヘッダフィールドパターンに対応付けて設定されている圧縮ヘッダフィールド情報とを検索結果として入出力制御部１３１に出力する。

この実施の形態６のファイヤーウォール７の動作は、先の実施の形態１のロードバランサー１とほぼ同じであり、相違点は、コード／デコードユニット７３−１，７３−２が検索対象となるフレームデータを圧縮した圧縮フレームデータを生成し、ヘッダ抽出ユニット１３が圧縮フレームデータを検索対象として用いることであるので、ここでは動作の説明を省略する。

このようにこの実施の形態６においては、フレームデータを圧縮するようにしているため、検索部１３３−１〜１３３−ｎの検索対象となるフレームデータのデータ量を削減することが可能となり、ＭＡＣフレーム内から任意のプロトコルのヘッダフィールド情報を高速に抽出して、フレームの転送処理時間を短縮することができる。

なお、この実施の形態６においては、ファイヤーウォール７に、先の実施の形態１のロードバランサー１のヘッダ抽出ユニット１３を用いる場合を例に挙げて説明したが、先の実施の形態２〜５で説明したロードバランサー１のヘッダ抽出ユニット１３ａ〜１３ｄをヘッダ抽出ユニット１３の代わりに用いるようにしてもよい。この場合、ヘッダフィールドパターンの代わりに、コード／デコードユニット７３−１，７３−２で用いる圧縮アルゴリズムによって圧縮されたヘッダフィールドパターンを用いることはいうまでもない。

また、実施の形態１〜５では、ネットワーク中継装置としてロードバランサー１を例に挙げ、実施の形態６では、ネットワーク中継装置としてファイヤーウォール７を例に挙げて説明したが、この発明のネットワーク中継装置はロードバランサー１やファイヤーウォール７に限るものではなく、ＭＡＣフレーム内から文字列検索によって情報を抽出し、抽出した情報を用いてフレーム転送を行なう装置であればよい。

さらに、この実施の形態１〜６では、レイヤ２フレームとしてＭＡＣフレームを例に挙げて説明したが、レイヤ２フレーム、すなわちレイヤ２のプロトコルはこれに限るものではなく、たとえば、ＡＴＭ（Asynchronous Transfer Mode）やＦＤＤＩ（Fiber-Distributed Data Interface）などであってもかまわない。

以上のように、本発明にかかるネットワーク中継装置は、レイヤ５以上のヘッダフィールド情報を用いてＭＡＣフレームの転送先を選択する場合に有用であり、特に、ロードバランサーやファイヤーウォールに適している。

この発明における実施の形態１のネットワーク中継装置が適用される通信システムの構成の一例を示す図である。 図１に示した通信システムで用いるＭＡＣフレームのフォーマットを示す図である。 図２に示したレイヤ３ヘッダのフォーマットの一例を示す図である。 図２に示したレイヤ４ヘッダのフォーマットの一例を示す図である。 図２に示したレイヤ４ヘッダのフォーマットの一例を示す図である。 図２に示したレイヤ５ヘッダのフォーマットの一例を示す図である。 図１に示したロードバランサーの構成を示すブロック図である。 図７に示したヘッダ抽出ユニットの構成を示すブロック図である。 実施の形態２のロードバランサーのヘッダ抽出ユニットの構成を示すブロック図である。 実施の形態３のロードバランサーのヘッダ抽出ユニットの構成を示すブロック図である。 実施の形態４のロードバランサーのヘッダ抽出ユニットの構成を示すブロック図である。 図１１に示したプロトコルパターンテーブルの構成を示す図である。 実施の形態５のロードバランサーのヘッダ抽出ユニットの構成を示すブロック図である。 この発明における実施の形態６のネットワーク中継装置が適用される通信システムの構成の一例を示す図である。 図１４に示したファイヤーウォールの構成を示すブロック図である。

符号の説明

１ ロードバランサー
２ａ，２ｂ 通信端末
３ ネットワーク
４ ｗｅｂサーバ群
５ａ，５ｂ，５ｃ，５ｄ，５ｅ，５ｆ，５ｇ リンク
７ ファイヤーウォール
８ ルータ
１１−１，１１−２ 送受信ユニット
１２−１，１２−２ 転送ユニット
１３，１３ａ，１３ｂ，１３ｃ，１３ｄ ヘッダ抽出ユニット
４１ａ，４１ｂ，４１ｃ サーバ
７３−１，７３−２ コード／デコードユニット
１３１ 入出力制御部
１３２ コピー部
１３３−１，１３３−２，１３３−ｎ，１３５１−１，１３５１−２，１３５１−ｎ，１３６１−１，１３６１−２，１３６１−ｎ，１４２−１，１４２−２，１４２−ｎ，１３７２，１４３２ 検索部
１３４ 検索結果統合部
１３５，１３６，１３７−１，１３７−２，１３７−ｘ，１４３−１，１４３−２，１４３−ｍ 検索処理部
１３８ 検索データ分割部
１３９ 分割検索結果統合部
１４１，１３７１，１４３１ プロトコルパターンテーブル

Claims (7)

1. 受信したレイヤ２フレーム内の各レイヤのヘッダからレイヤに応じたプロトコルのヘッダフィールド情報を抽出し、抽出したヘッダフィールド情報に基づいて前記レイヤ２フレームの転送先を選択するネットワーク中継装置において、
   前記レイヤ２フレームの一部を複製して複数のフレームデータを生成するフレーム複製部と、
   前記フレーム複製部によって生成されたフレームデータの１つを検索対象として検索対象のフレームデータから予め定められたヘッダフィールドパターンを検索し、前記検索対象のフレームデータ内に前記ヘッダフィールドパターンを検出した場合には、検出したヘッダフィールドパターンに対応付けて検索対象のフレームデータに設定されているヘッダフィールド情報を抽出する複数の検索部と、
   前記複数の検索部が検出したヘッダフィールドパターンおよび抽出したヘッダフィールド情報をフィールド情報抽出結果として出力する検索結果統合部と、
   を有するヘッダ抽出ユニットと、
   前記レイヤ２フレームの転送先の識別に有用な情報である転送先識別情報と、前記検索結果統合部が出力するフィールド情報抽出結果とに基づいて、前記受信したレイヤ２フレームの転送先を選択して送信する転送ユニットと、
   を備え、
   さらに、ヘッダフィールドパターンに対応付けて当該ヘッダフィールドパターンを用いるプロトコルが登録されるプロトコルパターンテーブルをレイヤ毎に備え、
   前記複数の検索部は、自身が対応付けられているレイヤのプロトコルより１つ下位レイヤのプロトコルに対応付けられている検索部から通知される上位プロトコル候補に対応付けられているヘッダフィールドパターンを用いて検索対象のレイヤ２フレームを検索し、この検索結果から自身が対応付けられているプロトコルより１つ上位レイヤのプロトコルの候補を選択し、選択した上位レイヤのプロトコルを、自身が対応付けられているプロトコルより１つ上位レイヤのプロトコルを検索する検索部に通知すること、
   を特徴とするネットワーク中継装置。
2. 前記複数の検索部の中で最下位のレイヤに対応付けられている検索部は、前記転送先識別情報から選択したプロトコル、または自身が対応付けられているプロトコルパターンテーブルに登録されているプロトコルの中で最下位のレイヤとなる全てのプロトコルを自身が検索するプロトコル候補とすること、
   を特徴とする請求項１に記載のネットワーク中継装置。
3. 前記フレーム複製部は、
   前記受信したレイヤ２フレーム内のレイヤ５ヘッダからレイヤ２フレームの最後までを複製すること、
   を特徴とする請求項１または２に記載のネットワーク中継装置。
4. 予め定められた圧縮アルゴリズムに基づいて前記受信したレイヤ２フレームを圧縮した圧縮フレームデータを生成して前記フレーム複製部に出力するとともに、圧縮された検索結果を伸張するコード／デコードユニット、
   をさらに備え、
   前記ヘッダ抽出ユニットは、
   前記圧縮アルゴリズムに基づいて圧縮された圧縮フレームデータ、および圧縮ヘッダフィールドパターンを用いること、
   を特徴とする請求項１、２または３に記載のネットワーク中継装置。
5. 受信したレイヤ２フレーム内の各レイヤのヘッダからレイヤに応じたプロトコルのヘッダフィールド情報を抽出し、抽出したヘッダフィールド情報に基づいて前記レイヤ２フレームの転送先を選択するネットワーク中継装置において、
   ヘッダフィールドパターンが複数登録されるプロトコルパターンテーブルと、
   前記レイヤ２フレームの一部を予め定められた文字数毎に分割した分割フレームデータを生成する検索データ分割部と、
   前記検索データ分割部によって生成された分割フレームデータの１つを検索対象として検索対象の分割フレームデータから前記プロトコルパターンテーブルに登録されているヘッダフィールドパターンを検索し、検索が終了すると検索終了通知を前記検索データ分割部へ出力する複数の検索部と、
   前記検索部が検索対象の分割フレームデータから前記プロトコルパターンテーブルに登録されているヘッダフィールドパターンを検出した場合には、当該ヘッダフィールドパターに対応付けて分割フレームデータに登録されているヘッダフィールド情報を抽出し、抽出したヘッダフィールド情報とヘッダフィールドパターンとをフィールド情報抽出結果として出力する分割検索結果統合部と、
   を有するヘッダ抽出ユニットと、
   前記受信したレイヤ２フレームの転送先の識別に有用な情報である転送先識別情報と、前記分割検索結果統合部が出力するフィールド情報抽出結果とに基づいて、前記レイヤ２フレームの転送先を選択して送信する転送ユニットと、
   を備え、
   前記検索データ分割部は、前記分割フレームデータのうち前記検索部による検索が行なわれていない分割フレームデータである未検索分割データが存在する場合には、前記検索終了通知の出力元の検索部へ前記未検索分割フレームデータを検索対象として出力する、
   ことを特徴とするネットワーク中継装置。
6. 前記検索データ分割部は、
   前記受信したレイヤ２フレーム内のレイヤ５ヘッダからレイヤ２フレームの最後までを分割すること、
   を特徴とする請求項５に記載のネットワーク中継装置。
7. 予め定められた圧縮アルゴリズムに基づいて前記受信したレイヤ２フレームを圧縮した圧縮フレームデータを生成して前記検索データ分割部に出力するとともに、圧縮された検索結果を伸張するコード／デコードユニット、
   をさらに備え、
   前記ヘッダ抽出ユニットは、
   前記圧縮アルゴリズムに基づいて圧縮された圧縮データフレーム、および圧縮ヘッダフィールドパターンを用いること、
   を特徴とする請求項５または６に記載のネットワーク中継装置。

Images