JP2015162024A

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

Info

Publication number: JP2015162024A
Application number: JP2014035954A
Authority: JP
Inventors: 智也日比; Tomoya Hibi; 高橋　宏和; Hirokazu Takahashi; 宏和高橋; 佳宏中島; Yoshihiro Nakajima
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: 2015-09-07
Anticipated expiration: 2034-02-26
Also published as: JP6085577B2

Abstract

【課題】メモリ使用量を抑え、また、検索速度の劣化を抑える検索木を作成し、コンパクトな検索木を生成する。
【解決手段】本発明は、ソフトウェアOpenFlowスイッチにおいて、各エントリが「don't care bit」を含み、優先度を有する検索木（検索テーブル）を生成し、該検索木を検索する検索木生成・検索装置であって、パケットのマッチ条件や処理を記述したフロールールが与えられると、検索木の配列を、１つか２つのビット列と検索結果を示すデータを保持する構成として生成する検索木管理手段と、受信したパケットを用いて前記検索木（検索テーブル）を辿ることによりエントリの検索を行い、検索結果を返却する検索処理制御手段と、を有する。
【選択図】図２

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 Trie
・Grid of Tire
多くの検索アルゴリズムは木構造の一つであるトライ木の構造をとる。木構造はノードとノード間を結ぶ辺で構成される。木構造の各ノードは、辺によって結ばれた0個以上の子ノードを持ち（今後、子ノードを単に「子」と記す）、根以外のノードは高々１つの親ノードを持つ。根は木構造の中で唯一存在する、親ノードを持たないノードである。また、子を持たないノードは特別に葉と称する。多くの検索木では、葉に検索結果を保存し、本発明で扱う検索木も同様に検索結果は葉に保存する。

多くの検索アルゴリズムはトライ木の構造をとるが、トライ木における分木をできる限り削除したデータ構造としては、Patricia treeがある（例えば、非特許文献２参照）。Patricia treeはトライ木の中で子が一つしかないノードをまとめたトライ木である。トライ木（Patricia tree）の具体例を図１に示す。同図中の丸が頂点、四角が各辺に割り当てられたラベルを示す。通常のトライ木では各辺にラベルが一文字ずつ割り当てられるが、Patricia treeでは子が一つしかないノードをまとめたため、複数字のラベルを持つ辺ができる。

高速なトライ木の実装方法として、Double Arrayが知られている（例えば、非特許文献３参照）。Double Array は高速にLookupが可能であるが、各ノードに子のノードを示すbaseと呼ばれる値を保持する必要があり、空間効率が最適とはいえない。これに対し、LOUDSと呼ばれる簡潔データ構造が知られている（例えば、非特許文献４参照）。これらの実装では空間効率がよいが、Lookupに対し、rankやselectと呼ばれる操作が必要であり、時間効率は高くない。

また、各エントリに対してもbit scatterやbit gatherと呼ばれる手法を用いることによって、時間効率を犠牲にし、空間効率を上げることができる。

Pankaj Gupta and Nick McKeown. Algorithm by using a double-array structure. Software Engineering, IEEE Transactions on, 15(9): 1066-1077, 1989. Donald R Morrison. Patricia - ractical algorithm to retrieve information coded in alphanumeric. Journal of the ACM (JACM), 15(4): 514- 534, 1968. J-I Aoe. An efficient digital search algorithm by using a double-array structure. Software Engineering, IEEE Transactions on, 15(9): 1066-1077, 1989. Guy Jacobson. Space-efficient static trees and graphs. In Foundations of Computer Science, 1989., 30th Annual Symposium on, pages 549-554. IEEE, 1989.

しかしながら、システムが備えるキャッシュメモリやメインメモリに対して、大量のエントリをフローテーブルに追加した際、記憶領域が足りずエントリが追加できない問題や、キャッシュヒット率の低下、ディスクアクセス発生により急激に検索性能の劣化が発生する問題がある。

また、Set-Pruning trieのようなメモリを多く使用するアルゴリズムを検索に使用した際、メモリが足りなくなり、ディスクアクセスが発生し検索速度の劣化が発生する。

これに対し、LOUDSと呼ばれる簡潔データ構造を利用すれば、ビット列や文字列を検索するようなトライ木の検索木をメモリ使用量を抑えて表現することができるが、検索速度が遅くなってしまう。

本発明は、上記の点に鑑みなされたもので、LOUDSのデータ構造を改良することによって、メモリ使用量を抑え、また、検索速度の劣化を抑える検索木を作成し、コンパクトな検索木を生成することが可能な検索木生成・検索装置及び方法及びプログラムを提供することを目的とする。

一態様によれば、テーブルの各エントリが「don't care bit」を含み、優先度を有する検索木（検索テーブル）を生成し、該検索木を検索する検索木生成・検索装置であって、
パケットのマッチ条件や処理を記述したフロールールが与えられると、前記検索木（検索テーブル）の配列を、１つか２つのビット列と検索結果を示すデータを保持する構成として生成する検索木（検索テーブル）管理手段と、
受信したパケットを用いて前記検索木（検索テーブル）を辿ることによりエントリの検索を行い、検索結果を返却する検索処理制御手段と、を有する検索木生成・検索装置が提供される。

一態様によれば、検索木をLOUDSに似たbit列で表現することによって、検索木のポインタ表現のデータ量が抑制され、さらに、bit列ではselect操作を行わずにrank操作のみで検索できることから、検索木のポインタ表現のデータ量が抑制され、検索速度の劣化も抑えることができる。

トライ木（Patricia tree）の例。本発明の一実施の形態におけるフロー検索装置の構成例。本発明の一実施の形態におけるHiearchical trieに対する簡潔データ構造の例。

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

本発明は、OpenFlowのフロースイッチ、Packet filtering，Policy routing，QoS(Quality of Service), Accounting & Billing等を実現するフローを扱う機器に適用可能な技術であるが、以下では、OpenFlowのフロースイッチを例として説明する。

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

フロー検索装置１００は、パケット情報受信部１１０、検索処理制御部１２０、検索木（検索テーブル）１３０、検索木（検索テーブル）管理部１４０、検索結果送信部１５０を有し、検索木（検索テーブル）管理部１４０は、外部のフロールール入力部１０に接続されている。フロールール入力部１０は、パケットのマッチ条件や処理を記述したフロールールを検索木（検索テーブル）管理部１４０に入力する。

本発明のフロー検索装置１００は、フロールール入力部１０から入力されたエントリ（一致条件）から検索bit列を作成し、パケット情報受信部１１０で受信したパケットの情報（パケットの一部また全部のbit列，またはパケットのbit列から生成したbit列）に基づいて検索木（検索テーブル）１３０の検索bit列を用いてエントリの検索を行い、一致するエントリを検索する。

検索木は、通常のアドレスポインタを使用したものではなく、木の構成情報をbit列によって表現されたものを生成する。

フロー検索装置１００は、パケット情報受信部１１０から検索に必要なパケット情報を取得し、検索木（検索テーブル）１３０を参照し、一致するエントリ情報を検索して、検索結果を検索結果送信部１５０で返す。また、検索木（検索テーブル）１３０は、検索木（検索テーブル）管理部１４０に入力されたFlowエントリから検索木（検索テーブル）管理部１４０によって、検索木を構築し、検索木（検索テーブル）１３０を更新する。

従来技術とは、フロー検索装置１００における、検索木をLOUDSのようなbit列（簡潔データ構造）で生成し、検索に使用する点において異なる。

以下に、図２の各構成要素について説明する。

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

検索木（検索テーブル）管理部１４０は、フロールール入力部１０から入力されたエントリ情報を受け取り、その情報から検索木（検索テーブル）１３０を作成する。また、フローの修正等のトリガによって、検索木（検索テーブル）１３０の修正を行う。

検索木（検索テーブル）１３０は、検索木（検索テーブル）管理部１４０によって作成された検索木であり、検索処理制御部１２０でこの検索木を用いて検索処理を行う。具体的な木の構造（bit列）と木の辿り方については後述する。

検索処理制御部１２０は、パケット情報受信部１１０からパケット情報を受信し、受信したパケット情報を用いて検索木（検索テーブル）１３０を用いてエントリの検索を行う。検索は検索木を辿ることで行う。検索した後、結果を検索結果送信部１５０に送信する。

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

・パケットのヘッダだけ切り出す。

・パケットのヘッダのうち、一致条件に使用するものだけ切り出す。

最後に整形した情報を検索処理制御部１２０に送る。

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

以下に、検索木（検索テーブル）管理部１４０によって生成される検索木について説明する。

システムがキャッシュメモリやメインメモリに対して、大量のエントリをフローテーブルに追加した場合に、記憶領域が足りずエントリが追加できない場合や、キャッシュヒット率の低下やディスクアクセスが発生し、急激に検索性能の劣化が発生してしまう問題がある。

簡潔データ構造であるLOUDSを用いた場合、メモリ使用量の削減が期待できるが、計算時間のオーバヘッドが大きくなる。そのため、本発明では、トライ木のLOUDSを工夫し、検索のボトルネックとなるselect操作をせず、Lookupを行うbit列を生成する。

本発明で生成する検索木は１つか２つのbit列と検索結果を示すdataを保持する配列で構成される。以下にbit列の詳細を説明する。

以下の説明で使用する

とは、ビット列ａに対して１番目からid番目のビット列の中に何個の0が含まれるかを計算する機能であり、

とはビット列ａに対して、id番目の0はビット列ａの中の何番目のビットかを計算する機能である。一般に、rankよりもselectの方が計算時間がかかる。

本発明における検索ビット列を説明する前に、LOUDSにおけるビット列を説明する。LOUDSでは各ノードに幅優先探索で探索される順序でノードに番号idを振り、その順にビット列を構築する。ビット列はid順にidのノードの子の数だけ１を並べ、その後0を置く。このようなビット列に以下の操作を行うことでidがiであるノードのm番目の子のid(child_id)を求めることができる。

child_id=select₀(rank₁(i))+m
＜Patricia treeにおける検索ビット列＞
トライ木はPatricia treeの構造をとることによって、ノードの数を削減することができる。Patricia treeでは、子が一つしかないようなノードを削除することから、ビット列の検索においては、Patricia treeによって生成された検索木は葉以外のノードが必ず２つ子を持つことになる。

図１のトライ木(Patricia tree)のデータ構造例を表１に示す。

表1のように、幅優先探索で探索される順序でノードに番号idを振り、その番号の順に検索ビット列ａの先頭ビットから１ビットずつ割り当てる。各ノードに対してこのビットの値は、対応するノードが子を持っている場合は「１」（または「０」）、持っていない場合は「０」（または「１」）とする。

この変換を行った場合、番号がidであるノードからn番目の子を辿る場合、次の計算でn番目の子の番号id(child_{_}id)を得ることができる（但し、nは１か２）。

通常のLOUDSによる表現ではselect操作が必要であるが、本ビット列ではPatricia treeの特性を活かすことで、上式のようにrankのみで木を辿ることができる。

また、Patricia treeでは全ての葉はエントリのデータを持っている。検索木を辿ることにより、葉まで辿った後実際のエントリデータにアクセスする。

エントリデータは各葉のidでソートした配列を用意する。Lookupにより、葉まで辿って得たidに対して次計算でエントリデータを持ったデータ配列のdata_indexを得ることができる。

また、この構造は、この数が0か2で固定されていなかったとしても、ダミーの頂点（ダミーノード）を挿入することによって、子の数を定数mで固定し、同様の操作を実現することができる。但し、その場合はエントリデータを持たない葉が存在してしまうため、エントリデータを格納する配列に無駄が生じる。

＜一般のトライ木における検索ビット列＞
前述の手法をHiearchical trieに対しても適用するために一般化したものを示す。前述の手法はLOUDSによる表現を、Patricia treeの子の数が固定である特性を利用して拡張したものであったが、各ノードが持ちうる子の数で最も大きい数をmとしたとき、葉以外の各ノードで子の数がｍでないものに対して、子の数がmになるようにダミーノードを挿入する。例えば、Hiearchical trieであれば、子の数が最大３であるが、子の数が1または2のノードに対して、ダミーノードを加え、子の数を3と変換する。

その後、前述の手法と同様に、幅優先探索で探索される順序でノードに番号を振り、その番号順に検索bitmapの各ビットを割り当てる。各ノードに対してビットの値は、そのノードが子を持っている場合は「1」（または「0」）、持っていない場合は「0」（または「1」）とする。これをビット列ａとする。この変換を行った場合、あるidを持ったノードからn番目の子を辿る場合、次の計算でn番目の子のidchild_idを得ることができる（但し、nは１か２）。

この手法では、ダミーノードが増えるため、エントリデータを持たない葉が存在してしまうため、エントリデータを格納する配列に無駄が生じる。そこでビット列ｂを用意する。ビット列ｂは長さが葉の数と等しく、各ビットは葉をidでソートした順に割り当てられる。各ビットの値はその葉がエントリを表すものならば「1」（または「0」）、持たないならば「0」（または「1」）を持つ。このようなビット列を持つことにより、次の式でデータへのインデックス番号data_indexを計算することができる。

この手法では各ノードが持ちうる子の数が大きいと、ビット列が長くなり無駄が発生するが、フロースイッチのような0,1,don't careの三種類で構成される列を検索する場合など、各ノードが持ちうるこの数が制限されていた場合には、LOUDSの構造にをとるよりも、高速に動作し、使用するビット列の長さも抑えることができる。

具体例を図３と表２に示す。図３において、丸がノード、四角がラベルを示す。エントリ及びラベルにある*は1ビットのdon't careである。

上記のように、本発明では、検索木をLOUDSのようなbit列で表すことによって、検索木のポインタ表現のデータ量を抑制し、検索木にダミーノードを挿入するなど、検索木とビット列の値の取り方を工夫することによって検索木を辿る際のSelect操作を排除し、検索木をビット列で表すことによる検索性能の劣化を抑える。

具体的には、エントリから生成されるトライ木のノード数をNとし、各ノードは子ノードへのポインタpを子の数mとノードの情報fを持つとしたとき、通常のポインタによる実装で必要なメモリは以下のメモリが必要なのに対し、

Double Arrayでは、

本発明では、

となる。よって、本発明によって、Double ArrayよりN(p-1)分のメモリ削減ができ、その分多くのエントリを登録することができる。

このことにより、システムが備えるキャッシュメモリやメインメモリに対して、投入可能なエントリ数が増加し、大量のエントリを扱えるようになり、大容量なネットワークへのフロースイッチの適用が可能となる。さらにメモリが制限された機器でもより多くのフローを追加することができるようになり、フロースイッチの小型化、低価格化の効果が得られる。

また、フローあたりに使用するメモリ量が削減されることから、削減されたメモリ資源を他の処理（仮想マシンの実行等）に割り当てることができ、本発明を組み込んだサーバはフロースイッチの高機能化が可能となる。

なお、本発明は、上記の図２のフロー検索装置１００の各構成要素の処理をプログラムとして構築し、検索木生成・検索装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

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

１０フロールール入力部
１００フロー検索装置
１１０パケット情報受信部
１２０検索処理制御部
１３０検索木（検索テーブル）
１４０検索木（検索テーブル）管理部
１５０検索結果送信部

Claims

テーブルの各エントリが「don't care bit」を含み、優先度を有する検索木（検索テーブル）を生成し、該検索木を検索する検索木生成・検索装置であって、
パケットのマッチ条件や処理を記述したフロールールが与えられると、前記検索木（検索テーブル）の配列を、１つか２つのビット列と検索結果を示すデータを保持する構成として生成する検索木（検索テーブル）管理手段と、
受信したパケットを用いて前記検索木（検索テーブル）を辿ることによりエントリの検索を行い、検索結果を返却する検索処理制御手段と、
を有することを特徴とする検索木生成・検索装置。
前記検索木（検索テーブル）管理手段は、
Patricia treeの子ノードの数が固定であるという特性によるビット列を生成するビット列生成手段を有し、
前記ビット列生成手段は、
幅優先探索の順でノードに番号idを割り当て、該番号順に検索木のビットマップに各ビットを割り当て、該番号のノードが子ノードを持っていれば「１」（または「０」）を、持っていなければ「０」（または「１」）に変換し、該検索木の葉のエントリデータを、該葉のidでソートしたエントリデータに変換する変換手段を含み、
前記検索処理制御手段は、
前記番号idのノードからn番目の子ノードを辿る場合は、

によりn番目の子ノードの番号child_idを得る手段と、
前記検索木を葉まで辿って得たidに対し、

によりエントリデータを持ったデータ配列のdata_indexを得る手段と、
を有する
請求項１記載の検索木生成・検索装置。
前記検索木（検索テーブル）管理手段は、
各ノードが持つ子ノードの数で最も大きい数をmとしたとき、葉以外の各ノードで子ノードの数がｍでないノードに対して、子ノードの数がｍになるようダミーノードを挿入し、幅優先探索で探索される順序で各ノードに番号を割り当て、番号順に検索ビットマップの各ビットを割り当て、該番号のノードが子ノードを持っていれば「１」（または「０」）を、持っていなければ「０」（または「１」）に変換し、検索木の葉の数を長さとするビット列bを用意し、葉のidでソートした順に各ビットを割り当て、該各ビットの値を、該葉がエントリを表すものであれば「１」を、そうでない場合は「０」に変換する変換手段を含み、
前記検索処理制御手段は、
前記番号idのノードからn番目の子ノードを辿る場合は、

によりn番目の子ノードの番号child_idを得る手段と、
前記検索木を葉まで辿って得たidに対し、

によりエントリデータを持ったデータ配列のdata_indexを得る手段と、
を有する
請求項１記載の検索木生成・検索装置。
テーブルの各エントリが「don't care bit」を含み、優先度を有する検索木（検索テーブル）を生成し、該検索木を検索する検索木生成・検索方法であって、
前記検索木を生成する機能と、受信したパケット情報に基づいて該検索木を検索する機能を有する装置において、
パケットのマッチ条件や処理を記述したフロールールが与えられると、前記検索木（検索テーブル）の配列を、１つか２つのビット列と検索結果を示すデータを保持する構成として生成する検索木（検索テーブル）管理ステップと、
受信したパケットを用いて前記検索木（検索テーブル）を辿ることによりエントリの検索を行い、検索結果を返却する検索処理制御ステップと、
を行うことを特徴とする検索木生成・検索方法。
前記検索木（検索テーブル）管理ステップにおいて、
Patricia treeの子ノードの数が固定であるという特性によるビット列を生成するビット列生成ステップを含み、
前記ビット列生成ステップにおいて、
幅優先探索の順でノードに番号idを割り当て、該番号順に検索木のビットマップに各ビットを割り当て、該番号のノードが子ノードを持っていれば「１」（または「０」）を、持っていなければ「０」（または「１」）に変換し、該検索木の葉のエントリデータを、該葉のidでソートしたエントリデータに変換し、
前記検索処理制御ステップにおいて、
前記番号idのノードからn番目の子ノードを辿る場合は、

によりn番目の子ノードの番号child_idを取得し、
前記検索木を葉まで辿って得たidに対し、

によりエントリデータを持ったデータ配列のdata_indexを得る
請求項４記載の検索木生成・検索方法。
前記検索木（検索テーブル）管理ステップにおいて、
各ノードが持つ子ノードの数で最も大きい数をmとしたとき、葉以外の各ノードで子ノードの数がｍでないノードに対して、子ノードの数がｍになるようダミーノードを挿入し、幅優先探索で探索される順序で各ノードに番号を割り当て、番号順に検索ビットマップの各ビットを割り当て、該番号のノードが子ノードを持っていれば「１」（または「０」）を、持っていなければ「０」（または「１」）に変換し、検索木の葉の数を長さとするビット列bを用意し、葉のidでソートした順に各ビットを割り当て、該各ビットの値を、該葉がエントリを表すものであれば「１」（または「０」）を、そうでない場合は「０」（または「１」）に変換し、
前記検索処理制御ステップにおいて、
前記番号idのノードからn番目の子ノードを辿る場合は、

によりn番目の子ノードの番号child_idを取得し、
前記検索木を葉まで辿って得たidに対し、

によりエントリデータを持ったデータ配列のdata_indexを得る
請求項４記載の検索木生成・検索方法。
コンピュータを、
請求項１乃至３のいずれか１項に記載の検索木生成・検索装置の各手段として機能させるための検索木生成・検索プログラム。