JP6114705B2

JP6114705B2 - 検索木生成装置及び方法及びプログラム

Info

Publication number: JP6114705B2
Application number: JP2014035758A
Authority: JP
Inventors: 智也日比; 高橋　宏和; 宏和高橋; 佳宏中島
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2014-02-26
Filing date: 2014-02-26
Publication date: 2017-04-12
Anticipated expiration: 2034-02-26
Also published as: JP2015162748A

Description

本発明は、エントリにビットマスクを含むテーブルの検索装置及び方法及びプログラムに係り、特に、OpenFlow Wire ProtocolのLookupに代表されるような、各エントリが任意のdon't care bitを含むビット列からなるテーブルに対して、限定されたメモリを有効利用し、高速な検索を行うための検索木生成装置及び方法及びプログラムに関する。

近年、OpenFlow Wire Protocol等の通信制御をフロー単位で行い、より粒度の細かいサービス品質制御、経路制御を可能とするフローベースネットワーキングの利用が広がっている。フローとは、MAC(Media Access Control)アドレスやVLAN(Virtual LAN)におけるVID、IPアドレス、ポート番号等で識別される、アプリケーション毎の一連の通信のまとまりであり、フローベースネットワーキングではユーザやアプリケーションに応じたQoS制御やパケットヘッダの書き換え、経路制御が可能となる。

フローベースネットワーキングの中継ノードであるフロースイッチでは、フローテーブルに登録されたエントリを参照して、エントリに従ったパケットヘッダの書き換え、パケットの送出等を行う。エントリは、エントリの優先度、受信ポートやヘッダの各情報に相当するフィールドを持つ一致条件、一致条件に一致したパケットの処理の内容によって構成される。

OpenFlow Wire Protocolに代表される最近のプロトコルに対応するフロースイッチでは、さらに柔軟なサービス品質制御、経路制御の実現のため、エントリの各フィールドにおいて、ワイルドカード(そのフィールドを検索条件に使用するかしないか)を設定可能とし、さらに一部のフィールドでは任意のビットマスク(bitmask)を含むルールを記述可能である。

ネットワークルータのPacket Classificationの分野で、優先度と、ワイルドカードや最小プレフィックスマッチを幾つか含むようなフローテーブルに対する検索技術が知られている。これらのアルゴリズムには、それぞれ空間効率と時間効率のトレードオフがある（例えば、非特許文献１参照)。下記のアルゴリズムでは上段のアルゴリズムほど空間効率がよいが検索の時間効率が悪く、下段のアルゴリズムほど、空間効率は悪いが検索の時間効率がよい。

・Hiearchical Trie
・Set-Pruning Tre
・Grid of tire
上記のアルゴリズムは任意のビットマスクに対応していないが、一致条件の各ビットを一つのフィールドとして扱うことで任意のビットマスクを含んでいたとしてもフローテーブルを検索することが可能である。

任意のビットマスクやワイルドカードを含まない(ビットマスクやワイルドカードを全く含まない、もしくは、ビットマスクやワイルドカードの箇所が固定されている)場合において、空間効率も時間効率もよいアルゴリズムとしてハッシュが知られている。しかし、ハッシュにおいては任意のビットマスクやワイルドカードを含むことができない。そのため、ハッシュを利用した従来のシステムにおいては、各エントリに対して、一致条件の全ビットに対してdon't careかどうかを示すビット列(Mask)を作成し、作成された全種類のMaskに対して、ハッシュアルゴリズムを実行する手法が用いられている。このアルゴリズムを、本明細書では"Mask List"と呼ぶ。OpenFlowソフトウェアスイッチであるOpen vSwitchではVer1.11.0以降で、同アルゴリズムを実装している（例えば、非特許文献２参照）。

ハードウェアの分野においては任意のMaskを含んでいても高速に検索が可能なTCAM(Ternary Content Addressable Memory)と呼ばれるチップが知られている。しかし、物理的な空間効率が悪く、膨大なエントリを含むテーブルに対してはハードウェアが肥大化し、コスト面、消費電力面において課題があり、現実的には限られたエントリしかLookupを行うことができない。

非特許文献３の技術では、ビットマスクやワイルドカードを含まないエントリに対してハッシュ検索を行い、ビットマスクやワイルドカードを含むものに対して、線形探索を行っている。非特許文献４の技術では同手法をGPU（Graphics Processing Unit）で並列化し、高速化している。しかし、線形探索を用いるため、Maskを持つものに対してはエントリ数が増大するに従い、検索性能が線形に劣化することを避けられない。

Pankaj Gupta and Nick McKeown. Algorithms for packet classification. Network, IEEE, 15(2):24-32, 2001 Open vswitch, http://openvswitch.org/. Voravit Tanyingyong, Markus Hidell, and Peter Sjodin. Improving pc-based openflow switching performance. In Proceedings of the 6th ACM/IEEE Symposium on Architectures for Networking and Communications Systems, page 13. ACM, 2010. Sangjin Han, Keon Jang, KyoungSoo Park, and Sue Moon. Packetshader: a gpu-accelerated software router. ACM SIGCOMM Computer Communication Review, 40(4):195-206, 2010. Gerth Stolting Brodal, Rolf Fagerberg, and Riko Jacob. Cache oblivious search trees via binary trees of small height. In Proceedings of the thirteenth annual ACM-SIAM symposium on Discrete algorithms, pages 39-48. Society for Industrial and Applied Mathematics, 2002. Guy Jacobson. Space-efficient static trees and graphs. In Foundations of Computer Science, 1989., 30th Annual Symposium on, pages 549-554. IEEE, 1989. Donald R Morrison. Patricia - practical algorithm to retrieve information coded in alphanumeric. Journal of the ACM (JACM), 15(4):514-534, 1968.

しかしながら、上記のHiearchical TrieやMask Listではフローテーブルの検索速度が遅く、またSet-Pruning TrieやGred of trie等のアルゴリズムではメモリを多く使用してしまい、メモリ不足や、検索木を作成できないか、ディスクアクセスが発生し、検索の性能劣化が発生してしまう。

これらは、フロースイッチをソフトウェアとして実現し、別の処理を行うソフトウェアを同時に動作させた場合、計算資源の競合が発生し、性能劣化の要因となる。

本発明は、上記の点に鑑みなされたもので、フロースイッチにおいて、使用可能な計算資源（CPU、メモリ）を指定または推定する機能と、それによって限られたメモリ環境におけるワイルドカードや任意のビットマスクを含むエントリをもつフローテーブルを高速に検索可能な検索木を生成する検索木生成装置及び方法及びプログラムを提供することを目的とする。

ここで、限られたメモリ環境とは、以下の３種類がある。

また、ユーザによる指定や他のアプリケーションが動作時の未使用のメモリ量も含まれるが、以下の領域内である。

・〜数十MB: CPUキャッシュ(現在は20MB程度)
・〜数GB:組み込みマシンなどのメモリ
・〜数百GB:メインメモリ(現在は8GB〜256GB程度)

一態様によれば、エントリにビットマスクを含むテーブルの検索に利用される検索木を生成する検索木生成装置であって、
取得した、エントリの情報、メモリやストレージの使用率、利用可能な記憶領域の情報に基づいて、検索木の根から任意の深さ及びノード数までは、計算速度の速いデータ構造のアルゴリズムＡで構成し、それ以降はメモリ効率の高いデータ構造のアルゴリズムＢで構成するもの、又は検索木の根から任意の深さ及びノード数までは、メモリ効率の高いデータ構造のアルゴリズムAで構成し、それ以降は計算速度の速いデータ構造のアルゴリズムBで構成するものとする、アルゴリズムの境界を決定する検索木管理手段と、
前記アルゴリズムの境界に基づいて、前記アルゴリズムＡと前記アルゴリズムＢを有する検索木を生成する検索木生成手段と、を有する検索木生成装置が提供される。

一態様によれば、限られたメモリ、キャッシュを可能な限り活用した検索木を構築し、ディスクアクセスなどによる性能劣化や他の処理との計算資源の競合を防ぎ、できる限りフローテーブルのエントリ数による性能劣化を抑えることにより、フローテーブルの検索性の向上、運用上のスケール性の向上という効果を奏する。

本発明の一実施の形態におけるフロー検索装置の構成例。本発明の一実施の形態における2つ以上のアルゴリズムを組み合わせて作成された検索木の例。本発明の一実施の形態における両アルゴリズムのメインメモリ容量が計算可能な場合のフローチャート。本発明の一実施の形態における両アルゴリズムのメインメモリ容量が計算困難な場合のフローチャート。本発明の一実施の形態における初期状態（境界となるノード）の例。本発明の一実施の形態におけるa⊂ｃでなかった場合の動作例（a=00**,c=*00*）。本発明の一実施の形態におけるａ∪ｂ⊆ｃの結果。本発明の一実施の形態におけるａ⊂ｃでなくかつｂ⊂ｃであった場合の動作結果例（a＝0*，b＝1*，c＝*1の場合）。本発明の一実施の形態におけるａ⊂ｃでなくかつｂ⊂ｃでなかった場合のDAGを許容した動作結果例（a=0*,b=1*,c=*1の場合）。本発明の一実施の形態におけるａ⊂ｃでなかったときの頂点追加手順例（検索との並列実行可能）。

以下、図面と共に本発明の実施の形態を説明する。

図１は、本発明の一実施の形態におけるフロー検索装置の構成例を示す。

同図に示すフロー検索装置１００は、パケット情報受信部１１０、検索処理制御部１２０、検索木（検索テーブル）１３０、検索木（検索テーブル）作成・最適化部１４０、検索木（検索テーブル）管理部１５０を有する。

上記の構成要素を有するフロー検索装置１００は、パケット情報受信部１１０から検索に必要なパケット情報のビット列を取得し、検索木（検索テーブル）１３０を参照し、一致するエントリ情報を検索して、検索結果を検索結果送信部１６０で返す。また、検索木（検索テーブル）１３０は、検索木（検索テーブル）管理部１５０に入力されたエントリ、使用可能なコア、使用可能な記憶領域から検索木（検索テーブル）作成・最適化部１４０によって、構築及び更新される。

フロー検索装置１００の各構成について説明する。

検索木（検索テーブル）管理部１５０に接続される外部のフロールール入力部１０は、別システムから、自動もしくは手動でエントリの入力を受け付け、入力されるエントリをシステムに適したデータ形式に変換を行い、検索木（検索テーブル）管理部１５０にエントリの情報を送る。

検索木（検索テーブル）管理部１５０に接続される使用可能コア測定部３０は、別システムから自動、もしくは手動で使用可能なメモリ容量等、検索木作成に必要な情報を取得し、その情報を検索木（検索テーブル）管理部１５０に送る。取得する情報は、利用可能なCPUのコアの情報や、他に動作しているプロセスが使用するメモリ使用量などがある。

検索木（検索テーブル）管理部１５０に接続されるメモリ・ストレージ構成測定部２０は、使用可能コア測定部３０と同様に別システム、もしくは、手動でシステムの可能なメモリ、キャッシュ、ストレージの入力や推定結果を受け付け、検索木（検索テーブル）管理部１５０に入力する。また、利用可能な記憶領域情報の入力がない場合においても、その時点でのキャッシュ使用率やメモリ使用率、ストレージ使用率などから、別途記憶領域利用のポリシなどを設定し、それに従った利用可能な記憶領域の推定を行う機能を備えることも好ましい。また、利用可能な記憶領域の量の他にも、記憶領域とコア、及び周辺機器の位置及び接続関係も入力する、または、推定する機能を備えることが好ましい。

検索木（検索テーブル）管理部１５０は、フロールール入力部１０、メモリ・ストレージ構成測定部２０、使用可能コア測定部３０から入力されたフロールール、メモリやストレージの使用率、使用可能なメモリ容量等のエントリ情報及びシステム環境情報を受け取り、その情報からアルゴリズム及びデータ構造を選定し、アルゴリズムを組み合わせ、検索アルゴリズムとデータ構造を決定し、検索木（検索テーブル）作成・最適化部１４０に送る。当該検索木（検索テーブル）管理部１５０の具体的な動作については後述する。

検索木（検索テーブル）作成・最適化部１４０は、検索木（検索テーブル）管理部１５０からアルゴリズムの組み合わせに関する情報及びデータ構造の情報を受け、それに合わせ検索木（検索テーブル）１３０を作成する。また、最適化手順の実行指示を検索木（検索テーブル）管理部１５０から受ける機能を備え、検索機能の提供を中断せずに、検索木（検索テーブル）１３０を最適化する機能を備えることも好ましい。また、検索木（検索テーブル）管理部１５０からの指示があったタイミングのみならず、定期的、またはフローの修正等のトリガによって、検索木（検索テーブル）１３０の最適化を行う機能を備えることも好ましい
検索木（検索テーブル）１３０は、検索木（検索テーブル）作成・最適化部１４０によって作成された検索木であり、検索処理制御部１２０でこの検索木を用いて検索処理を行う。

検索処理制御部１２０は、パケット情報受信部１１０からパケット情報を受信し、受信したパケット情報からbit列を取得し、そのbit列を用いて検索木（検索テーブル)１３０を用いてエントリの検索を行う。検索は検索木にあわせたそれぞれの検索手法を用いて、検索木を辿る手段を用いる。また、検索した後、結果を検索結果送信部１６０に送る。

パケット情報受信部１１０は、他のシステムから受信パケットの情報を受け取り、その情報をシステムに合わせた形に整形する。例えば、以下の整形を行う。

・パケットのヘッダだけ切り出す；
・パケットのヘッダのうち、一致条件に使用するものだけを切り出す；
最後に整形した情報を検索処理制御部１２０に出力する。

検索結果送信部１６０は、検索処理制御部１２０によって検索されたエントリの結果を他のシステムに送信する。

以下に、検索木（検索テーブル）１３０に対する処理について説明する。

＜検索木の境界決定手法＞
検索木（検索テーブル）管理部１５０は、図２に示すような検索木（検索テーブル）１３０の２つのアルゴリズムの境界を決定する。図２に示すとおり、根からある深さ、ノード数まではSet-Pruning Trie等、計算速度の速いデータ構造で検索木（algorithm A）を構築し、それ以降は、Hiearchical TrieやMask List等のメモリ効率の高いデータ構造（algorithmB）を使用することで、限られたメモリ量で高速なLookupを実現する。もしくは、メモリ効率が高い検索木を"algorithmA"とし、計算効率の高い検索木を"algorithmB"とする。

algorithmAとalgorithmＢの境界は、テーブルに対する各アルゴリズムのメモリ使用量が計算できる場合には、図３に示すような二分探索などによって最適な境界を検出する。

もし、algorithmAとalgorithmBのうち、片方が計算できない場合には、まず、空間効率の高い検索木を作成し、その検索木の根から（もしくは葉から）数ノードずつメモリ使用量の大きいアルゴリズムを適用することを繰り返すことで実現する（図４（葉から変換する場合の例））。図３、図４のフローチャートにおいて、Tree(h)は基準h（高さやノード数）であり、図２のalgorithmAとalgorithmBを分割した木を作成した場合のメモリ使用量を返すものとする。Tree(h)はアルゴリズムから計算式で求めるほか、実際に検索木を作成することによって使用メモリ量を計算する。またHは、検索木が取り得る最大の深さや検索木が取り得るノードの最大数等とする。これにより二分探索の最初の基準を決定する。

メモリに余裕があるか否かの評価は、実際のメモリ使用量とキャッシュやメインメモリ、ストレージのアクセス速度の差を考慮し、実際のLookupで辿る必要のあるノード数等で評価する。メモリに余裕があるとは、アルゴリズムの境界を下げて(上げて)もメモリの上限を越えることはないということである。但し、アルゴリズムの境界を下げて(上げて)、アルゴリズムが高速化できたとしても、メインメモリの容量を超え、ストレージなどメモリアクセスが遅い記憶領域を使用しなければならない場合も、メモリに余裕がないものとする。

また、実装方法によって使用するメモリ領域が違うため、各実装方法のメモリ使用量にてついて考慮する。

計算速度の速いアルゴリズムとメモリ効率のよいアルゴリズムを組み合わせることによって、計算速度の速いアルゴリズムが実行できないようなテーブルや、メモリサイズであったとしても、検索木を構築可能とし、単体でメモリ効率のよいアルゴリズムを用いた場合に対して、メモリを有効活用した検索木を構築できる。

＜検索木の境界決定手法詳細＞
以下では、Set-Pruning TrieとHiearchical Trieの組み合わせる場合について説明する。

Set-Pruning Trieは、エントリに対して、作成された木がどれだけのノード数を持つか計算することが難しい、そのため、上記の検索木の境界決定手法では図４に示す2つのアルゴリズムのメインメモリ容量の計測困難な場合のフローを使用する。

まず、h=0の場合の検索木として、Hiearchical Trieの検索木を作成する。Hiearchical Trieのノードは{0,1,*}の最大３種類の子を持つ。また、検索木はPatricia treeのように検索木を縮約したものとする（例えば、非特許文献７）。この検索木を根から順にSet-Pruning Trieの構造に切り替える。

Set-Pruning TrieとHiearchical Trieが変化する境界となっているノードに注目し、その境界を一つ深くする操作を以下に示す。

この操作を図４のフローチャートに従い実行する。注目するノードはh=0の時では根のノードであり、そのノードが浅い順、またはそのノードの子であるHiearchical Trieの中での最長となる検索の道が長い順に境界を一つ深くする操作を実行する。

［１］Hiearchical TrieとSet-Pruning Trieの境界となるノードを一つ選ぶ。選ぶ基準はノードが位置する浅さ、またはそのノード以下のHiearchical Trieの中で最長となる検索の道の長さなどで決める。このノードは図５に示すようなノードであるとする。ノードはaというラベルを持った辺とその先に続く部分木A、bのラベルとその先に続く部分木B、cのラベルとその先に続く部分木Cが付いている。ラベルや部分木が空集合と考えれば一般性は失われない。

［２］ｃのラベルとa、ｂのラベルを比較し、次のように木を修正する。

ラベルの長さが違う場合には、短い方のラベルの末尾を"*"で埋め、ビット列の長さを合わせる。下記では、aの場合のみを説明するが、bの場合も同様の動作である。

a⊂ｃ：Ｃに含むエントリのaの部分を全てaに置き換え、改めて検索木に追加する（追加する方法はHiearchical Trieと同じである）。この操作によりＡの部分木にはＡ∪Ｃであるようなエントリが挿入される。

ａ∩ｃ＝０：何も操作しない。または、下記の

と同じ動作を行う。何も動作しなかった場合には、Set-Pruning Trieでの各節の子の数が３になる可能性があるが、ａとｃの両方同時に一致することはないため、一致する枝を辿るという操作でバックトラックが発生することはない。

ａ_i，ｃ_iをi番目までのラベルの値とする。ａ_i⊂ｃ_iである最大のiを求める。i番目までのラベルとそれ以降のラベルで辺を分割し、新しいノードを追加する。このような変換をした後、再度Ｃのエントリをａに追加することを試みる。動作例を図６に示す。

［３］ａ∪ｂ⊆ｃである場合、辺ｅ_cとＣを削除する。動作結果は図７となる。

［４］

である場合、図８の例（z=0*,b=1*,c=*1の場合）のように、Cと同じ部分木が２つ存在してしまう。そのため、この木を統合する操作を行う。なお、当該操作は必須ではなく、行わなくともよい。統合した結果、図９のようなDAG（Directed Acyclic Graph）の構造となるが、検索のために必要な動作に変化はない。このとき、Hiearchical Trie同士が部分木を共有する構造になるため、その後のノードの追加、削除には、共有構造を一旦戻し、追加・削除を行う必要がある。

上記の［１］〜［４］の操作により、Set-Pruning TrieとHiearchical Trieの境界が一段深い位置となる。この操作で余分に必要なるノードの数はCの部分木が含むノード数の2倍＋2（DAGを許容するならば1倍＋2）を超えない。そのため、Cの部分木が含むノード数の2倍+2ノード分の余裕がメモリにあれば、境界を深くする操作が可能と判断できる。

Set-Pruning TrieとHiearchical Trieの境界を下げる操作は、同時に検索を行っていたとしても、注意して実装することで、矛盾なく検索を行うことができる。ここで、検索と境界による矛盾とは、境界を下げるためには、ラベルの変更とポインタの付け替えの2つの操作が必要であるが、ラベルが変更した時点で、並列に動いていた検索が動作しようとすると、変更後のラベルで比較し、変更前のポインタで次のノードに移動してしまうことである。

図１０に、

であった際の動作例を示す。まず、初期状態から、境界となる頂点をコピーし、その頂点よりも深い箇所へのポインタ接続を変更する（図１０（ｂ））。次にコピー元の親からのポインタ（コピー元の頂点が根であれば根へのポインタ）を付け替える（図１０（ｃ））。最後に使用しなくなった頂点を削除する。最後の削除の際には、検索にそのポインタを使用している頂点がないことを確認する（頂点が使われなくなったかどうかの判断は、各頂点にセマフォなどを実装しておけば知ることができる）。境界の頂点をコピーしている理由は、頂点追加によるラベルの分割によって、頂点追加のためにはラベルの値の変更とポインタの付け替えの2つの操作が必要となり、2つの操作の間に並列で処理している検索の処理が起きると、処理に矛盾が起きる可能性があるためである。境界の頂点をコピーすることによって、ポインタの付け替えのみで新しい部分木に切り替えることができ、検索との並列化による矛盾を消すことができる。

また、エントリの追加と削除についても同様に平行して検索操作を行うことが可能である。図１０の例と同様に、削除したいノード、追加したいノードの親となるノードを新しくコピーし、コピーした頂点以下のポインタ接続の処理を行い、最後にコピーした頂点の親のポインタを付け直す。使わなくなった頂点は、検索等で使用されなくなったことを確認した後、削除する。

これらの更新の動作は新しいノードと古いノードを別に用意する必要があるため、その分メモリの空きが必要である。

＜検索木（検索テーブル）最適化（配列上のデータの並び替え）＞
検索木（検索テーブル）作成・最適化部１４０は、利用可能な計算資源を最大限利用すると共に、各検索木（検索テーブル）１３０に対して最適なメモリマッピングを行う。double array等で配列に木をマッピングする際に、有効なマッピング手法としては、van Emde Boas layout（非特許文献5参照）が知られており、何も考慮せずに頂点を配列に配置するよりも、キャッシュヒット率が向上する。

また、Hiearchical Trieを利用する場合、トラックバックが性能劣化の原因となるが、検索するbit列の順序を入れ替えることでバックトラックの回数や距離を減らすことができる。具体例としては、Hiearchical Trieはプレフィックスマッチのようなビットマスクに対するLookupではバックトラックがほぼないため、プレフィックスの形をしたビットマスクを持つフィールドを検索木の最後に持っていく操作がある。

従来技術とは、以下の手法や機能が異なる。

本発明において、検索木（検索テーブル）作成・最適化部１４０で生成される検索木は、図２のような２つ以上のアルゴリズムを組み合わせて作成された検索木（検索テーブル）１３０である。この検索木のアルゴリズム間の境界を決定するとき、本発明では、別途入力された使用可能な記憶領域の量、及びキャッシュやメインメモリ、ストレージ等のアクセス速度差やアルゴリズムの速度差を加味し、検索木の境界を決定する。これにより図2に示すパターンのalgorithm A（Set-Pruning Trie）とalgorithm B（Hiearchical Trie）を組み合わせた場合のアルゴルリズム間の境界を決定する。

本発明は、上記の機能において、さらにキャッシュメモリのヒット率を向上させるよう、検索木のメモリのマッピングを最適化する検索木（検索木テーブル）作成・最適化部１４０を有し、検索木を連続したメモリ空間(配列)上にマッピングした場合、幅優先、深さ優先、van Emde Boas layout等によってノードを再配置することでキャッシュメモリのヒット率を向上させることができる(例えば、非特許文献５参照)。LOUDS(Level Order Unary Degree Sequence)という簡潔データ構造を用いることによって、計算時間は大きくなるが、メモリ使用量は小さくすることができる（例えば、非特許文献６参照）。

また、本発明では、検索木（検索テーブル）管理部１５０において、検索木を作成する前に、エントリが含むフィールドの順番をアルゴリズムに併せて並べ替える機能を有する。Hiearchical Trieのようなtrie木の構造を持つアルゴリズムでは、プレフィックスマッチの形をしたビットマスクに対して、高速に検索することができる。そのため、プレフィックスマッチの形をしたビットマスクが多いフィールドを検索するビット列の最後に移動させることでフロー検索を高速化することが可能となる。

なお、本発明は、図１に示す探索木（検索テーブル）管理部１５０、検索木（検索テーブル）作成・最適化部１４０の動作をプログラムとして構築し、検索木生成装置や検索装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。

１０フロールール入力部
２０メモリ・ストレージ構成測定部
３０使用可能コア測定部
１００フロー検索装置
１１０パケット情報受信部
１２０検索処理制御部
１３０検索木（検索テーブル）
１４０検索木（検索テーブル）作成・最適化部
１５０検索木（検索テーブル）管理部

Claims

エントリにビットマスクを含むテーブルの検索に利用される検索木を生成する検索木生成装置であって、
取得した、エントリの情報、メモリやストレージの使用率、利用可能な記憶領域の情報に基づいて、検索木の根から任意の深さ及びノード数までは、計算速度の速いデータ構造のアルゴリズムＡで構成し、それ以降はメモリ効率の高いデータ構造のアルゴリズムＢで構成するもの、又は検索木の根から任意の深さ及びノード数までは、メモリ効率の高いデータ構造のアルゴリズムAで構成し、それ以降は計算速度の速いデータ構造のアルゴリズムBで構成するものとする、アルゴリズムの境界を決定する検索木管理手段と、
前記アルゴリズムの境界に基づいて、前記アルゴリズムＡと前記アルゴリズムＢを有する検索木を生成する検索木生成手段と、
を有することを特徴とする検索木生成装置。
前記検索木管理手段は、
前記アルゴリズムの境界を、前記メモリやストレージの使用率、利用可能な記憶領域の情報に基づいて、前記アルゴリズムＡと前記アルゴリズムＢのメモリ使用量を算出し、二分探索によって決定する手段を含む
請求項１記載の検索木生成装置。
前記検索木管理手段は、
前記アルゴリズムＡを、各頂点でマッチする可能性のあるエントリを集合として扱い、木を辿る毎に該集合を刈り取ることで検索を行うSet-Pruning Trieとし、
前記アルゴリズムＢを、マッチする可能性のある辺を全て辿るバックトラッキングのアルゴリズムであるHiearchical Trieとする
請求項１または２記載の検索木生成装置。
前記検索木生成手段で生成された前記アルゴリズムＡと前記アルゴリズムＢを有する検索木に対し、幅優先、深さ優先、ノードの再配置、LOUDS(Level Order Unary Degree Sequence)のいずれかにより、メモリのマッピングを最適化する検索木最適化手段を更に有する
請求項１乃至３のいずれか1項に記載の検索木生成装置。
前記検索木管理手段は、
前記検索木が生成される前に、前記エントリの情報の各エントリが含むフィールドの順番をアルゴリズムに合わせて並べ替える手段を含む
請求項１乃至４のいずれか１項に記載の検索木生成装置。
エントリにビットマスクを含むテーブルの検索に利用される検索木を生成する検索木生成方法であって、
取得した、エントリの情報、メモリやストレージの使用率、利用可能な記憶領域の情報に基づいて、検索木の根から任意の深さ及びノード数までは、計算速度の速いデータ構造のアルゴリズムＡで構成し、それ以降はメモリ効率の高いデータ構造のアルゴリズムＢで構成するもの、又は検索木の根から任意の深さ及びノード数までは、メモリ効率の高いデータ構造のアルゴリズムAで構成し、それ以降は計算速度の速いデータ構造のアルゴリズムBで構成するものとする、アルゴリズムの境界を決定する検索木管理ステップと、
前記アルゴリズムの境界に基づいて、前記アルゴリズムＡと前記アルゴリズムＢを有する検索木を生成する検索木生成ステップと、
を行うことを特徴とする検索木生成方法。
前記検索木管理ステップにおいて、
前記アルゴリズムの境界を、前記メモリやストレージの使用率、利用可能な記憶領域の情報に基づいて、前記アルゴリズムＡと前記アルゴリズムＢのメモリ使用量を算出し、二分探索によって決定する
請求項６記載の検索木生成方法。
コンピュータを、
請求項１乃至５のいずれか１項に記載の検索木生成装置の各手段として機能させるための検索木生成プログラム。