JP2017163377A - パケット処理装置，及びそのテーブル選択方法 - Google Patents

Abstract

【課題】テーブルの検索速度の低下を抑止可能とする。
【解決手段】パケット処理装置は、パケット識別情報に対応する処理を示す情報とを含むテーブルと、受信されたパケットのパケット識別情報に対応する処理をテーブルから検索する処理部と、新規のパケットの識別情報を含む新規エントリの追加要求が受信された場合に、テーブルに記憶されている既存のパケット識別情報と、新規のパケット識別情報とに基づいて、種別が異なり且つ前記新規のパケットの識別情報及び前記既存のパケットの識別情報に含まれる全てのパケットを検索可能な複数のテーブルの候補を取得する取得部と、各候補のテーブルに記憶されるパケット識別情報の数に基づいて、検索時間の短い複数のテーブルの候補の一つを、処理部による検索に用いるテーブルとして選択する選択部とを含む。
【選択図】図６

Description

本発明は、パケット処理装置，及びそのテーブル選択方法に関する。

Software Defined Networking（ＳＤＮ）は、ソフトウェアでネットワーク全体の挙動
を制御する技術である。ＳＤＮを実現する標準として、OpenFlow（オープンフロー）技術がある。OpenFlowネットワークは、データ転送機能を備える“OpenFlowスイッチ”（ＯＦ−ＳＷ：以下「スイッチ」と表記することもある）と、経路制御を司る“OpenFlowコントローラ”（ＯＦＣ：以下「コントローラ」と表記することもある）を備え、コントローラとスイッチとは“OpenFlowプロトコル”に従って、コミュニケーションを図る。

各スイッチは、自身に入力されたパケットに対する動作（アクション）を決定するための情報が記憶されたフローテーブルを備える。OpenFlowでは、「フロー」と呼ばれる通信単位で通信トラフィックが制御される。フローは、“ヘッダフィールド（マッチ条件とも呼ばれる）”，“アクション（Action）”，及び“統計情報（Statistics）”の構成要素を備える。フローテーブルは、フローに係る情報が格納されたエントリ（以下、「フローエントリ」と呼ぶ）の集合体であり、各フローエントリは、“ヘッダフィールド（マッチ条件とも呼ばれる）”，“アクション（Action）”，及び“統計情報（Statistics）”を含む。

“マッチ条件”は、パケット（トラフィック）の識別情報であり、パケットを特定するためのパラメータで形成される。マッチ条件は、パケットのヘッダ情報（ＭＡＣ（Media Access Control）アドレス、ＶＬＡＮ（Virtual Local Area Network）タグ、ＩＰ（Internet Protocol）アドレス、ＴＣＰ／ＵＤＰポート番号など）の任意の組み合わせによっ
て形成される。“アクション”は、“マッチ条件”に合致したパケットに対する処理内容（動作：アクション）を示す情報である。“統計情報”は、マッチ条件に合致し、アクションに基づく処理が行われたパケット数のような統計情報を示す。スイッチは、フローテーブルを参照し、受信されたパケットが合致するマッチ条件を含むエントリを特定し、特定されたエントリで定義されたアクション（例えば、或るポートからパケットを出力する）を行うことができる。

フローに係る情報（フローエントリ）は、コントローラによって生成され、“OpenFlowプロトコル”を用いて各スイッチに送信される。各スイッチは、コントローラから受信したフローをフローテーブルに記憶する。このように、コントローラは、コントローラ自身の配下にある各スイッチが有するフローテーブルを一元管理する。

特開平１１−１７７０４号公報 特開２０１５−１８６２１３号公報 特表２０１４−５０６４０９号公報

一般に、フローテーブルの柔軟性（フローテーブルへの登録許容範囲）を上げると性能（検索速度、スケーラビリティ）が下がる。柔軟性の高い検索方法の一つに、“マスク（Mask）付き検索”がある。マスク付き検索では、例えば、マッチ条件として設定された複
数のパラメータのそれぞれ、或いは、パラメータをなす各ビット又はバイトに対する参照・非参照を自由に設定することができる。

例えば、検索対象として、ＭＡＣアドレス及びＩＰアドレスを設定し得る場合に、ＭＡＣアドレスとＩＰアドレスとの一方をマスクするケースがある。或いは、ＩＰアドレスのような、プリフィックス（Prefix）を有する検索対象をマッチ条件とする場合がある。ＩＰアドレスをマッチ条件とするエントリが登録される場合を仮定する。ＩＰアドレスのうち、プリフィックス以外の部分は参照を要しないため、マスクすることができる。一方、プリフィックスのサイズは適宜設定可能である。このため、フローテーブルとして、マスク付き検索のテーブルを用意し、プリフィックスの異なる（マスク位置の異なる）複数のエントリを１つのテーブルにて検索可能とすることが考えられる。

しかし、マスク付き検索では、個々のエントリに対する逐次検索が行われる結果、検索速度が遅くなる。このようなテーブルの検索時間がパケットの転送処理に影響を及ぼし、スイッチにおけるパケットのスループット低下を招来するおそれがあった。

本発明は、テーブルの検索速度の低下を抑止可能となる技術を提供することを目的とする。

本発明の一態様は、パケット処理装置である。このパケット処理装置は、パケット識別情報と、前記パケット識別情報に対応する処理を示す情報とを含むテーブルと、受信されたパケットのパケット識別情報に対応する処理を前記テーブルから検索する処理部と、新規のパケットの識別情報を含む新規エントリの追加要求が受信された場合に、前記テーブルに記憶されている既存のパケット識別情報と、前記新規のパケット識別情報とに基づいて、種別が異なり且つ前記新規のパケットの識別情報及び前記既存のパケットの識別情報に含まれる全てのパケットを検索可能な複数のテーブルの候補を取得する取得部と、各候補のテーブルに記憶されるパケット識別情報の数に基づいて、検索時間の短い前記複数のテーブルの候補の一つを、前記処理部による検索に用いるテーブルとして選択する選択部とを含む。

本発明の一態様によれば、テーブルの検索速度の低下を抑止可能となる。

図１は、実施形態に係るネットワークシステムの一例を示す図である。 図２Ａは、OpenFlow ver.1.0におけるフローテーブルを模式的に示す。 図２Ｂは、OpenFlow ver.1.1におけるフローテーブルを模式的に示す。 図３は、実施形態に係る説明図である。 図４は、実施形態に係る説明図である。 図５は、コントローラ及びスイッチのそれぞれとして使用可能な情報処理装置（コンピュータ）のハードウェア構成例を示す。 図６は、スイッチ（ＯＦ−ＳＷ）の機能を模式的に示す図である。 図７は、スイッチ（ＯＦ−ＳＷ）のフローテーブル作成に係る機能を模式的に示す図である。 図８は、予測時間データベースのデータ構造例を示す。 図９は、スイッチの他の実施形態に係る構成例を示す。 図１０は、テーブル分析・選択部によって行われるテーブル種別（候補）の判定処理の一例を示すフローチャートである。 図１１は、テーブル種別「マスク付き逐次検索（Mask付き逐次検索）」の説明図である。 図１２は、「ツリー型マスク」のテーブルの説明図である。 図１３は、テーブル種別「ハッシュ型ＥＭ」の説明図である。 図１４は、テーブル種別「少エントリ型ＥＭ」の説明図である。 図１５は、テーブル種別「多段ＥＭ」の説明図である。 図１６は、テーブル種別「マスク付き逐次検索＋キャッシュ方式」の説明図である。 図１７は、複数のテーブル種別についての、エントリ数と予測所要時間との関係を示すグラフであり、予測時間データベースに記憶されるデータ内容例を示す。 図１８は、性能ナレッジ蓄積部による処理例を示すフローチャートである。 図１９は、テーブル種別の変更処理の一例を示すフローチャートである。 図２０は、テーブルの変更の説明図である。 図２１は、テーブルの追加の説明図である。

以下、図面を参照し、パケット処理装置及びそのテーブル選択方法の実施形態について説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。

図１は、実施形態に係るネットワークシステムの一例を示す図である。図１には、ＳＤＮネットワークシステムの一例として、OpenFlowネットワークシステムが示されている。但し、OpenFlowはＳＤＮの一例であり、OpenFlow以外のＳＤＮシステムについて実施形態に係る構成は適用可能である。

図１に示す例では、OpenFlowネットワークは、コントローラ（ＯＦＣ）１と、ＯＦＣ１とネットワーク３を介して接続された複数のスイッチ（ＯＦ−ＳＷ）２とを含む。図１の例では、複数のスイッチとして、ＯＦ−ＳＷ＃１，ＯＦ−ＳＷ＃２，及びＯＦ−ＳＷ＃３が図示されている。

ＯＦＣ１は、各ＯＦ−ＳＷ２とOpenFlowプロトコルを用いて通信し、各ＯＦ−ＳＷ２の動作を制御する。例えば、ＯＦ−ＳＷ＃１→ＯＦ−ＳＷ＃２→ＯＦ−ＳＷ＃３の経路でパケットを転送する場合には、ＯＦＣ１は、各ＯＦ−ＳＷ２向けのフローエントリを生成して、対応するＯＦ−ＳＷ２に送信する。

上記例では、ＯＦＣ１は、ＯＦ−ＳＷ＃１に関して、転送の対象のパケット（トラフィック）を特定する“マッチ条件”と、対象のパケットをＯＦ−ＳＷ＃２と接続されたポートへ出力する旨の“アクション”とを含むフローエントリを生成する。ＯＦＣ１は、フローエントリをＯＦ−ＳＷ＃１へ送信する。ＯＦＣ１は、ＯＦ−ＳＷ＃２に関して、ＯＦ−ＳＷ＃１から受信されたパケットをＯＦ−ＳＷ＃３と接続されたポートから出力するためのフローエントリを生成し、ＯＦ−ＳＷ＃２へ送信する。ＯＦＣ１は、ＯＦ−ＳＷ＃３に関して、ＯＦ−ＳＷ＃２から受信されたパケットを所定のポートから出力するためのフローエントリを生成し、ＯＦ−ＳＷ＃３へ送信する。

各ＯＦ−ＳＷ２は、ＯＦＣ１から受信されるフローエントリを、フローテーブル４に記憶する。各ＯＦ−ＳＷ２は、パケットが受信された場合に、パケットと合致するマッチ条件を有するフローエントリを特定し、特定したフローエントリ中のアクション情報に従った動作を行う。これによって、受信されたパケットがアクション情報に従って指定されたポートから出力される。

ＯＦＣ１は、各ＯＦ−ＳＷ２へ送信したフローエントリを一元的に管理することで、Ｏ
Ｆ−ＳＷ２の動作を制御する。ＯＦ−ＳＷ２は、フローテーブル４に記憶されたいずれのフローエントリ（マッチ条件）ともマッチしないパケットが受信された場合には、当該パケットに対応するフローエントリの提供要求メッセージをＯＦＣ１へ送信する。提供要求メッセージに応じて、ＯＦＣ１は対応するフローエントリを生成し、ＯＦ−ＳＷ２へ送信する。

ＯＦ−ＳＷ２の動作を規定するフローテーブル４は、ＯＦＣ１から受信されるフローエントリによって形成される。図２Ａは、OpenFlow ver.1.0におけるフローテーブルを模式的に示し、図２Ｂは、OpenFlow ver.1.1におけるフローテーブルを模式的に示す。OpenFlow ver.1.0では、図２Ａに示すように、ＯＦ−ＳＷ２に１つのフローテーブルが設けられ、マッチ条件は、１２個の要素（検索対象のフィールド）を有していた。

要素（検索対象のフィールド）は、受信ポート（Switch Port (Ingress Port)），送信元ＭＡＣアドレス（MAC src），宛先ＭＡＣアドレス（MAC dst），プロトコル種別，ＶＬＡＮ−ＩＤ，VLAN Priority（ＶＬＡＮ ＰＣＰ(Priority Code Point)値）などである。また、要素（検索対象のフィールド）は、送信元ＩＰアドレス（IP src），宛先ＩＰアドレス（IP dst），ＴＣＰ送信元ポート番号，ＴＣＰ宛先ポート番号，ＴｏＳ（Type of Service）値などを含む。

このため、フローテーブルは、例えば、ＴＣＡＭ（Ternary Content Addressable Memory）などを用いて作成され、要素中の任意の領域が検索対象となる（マスク付き検索が行われる）ように、要素中の検索対象以外の領域にマスクが施される。

これに対し、OpenFlow ver.1.1以降では、図２Ｂに示すように、フローテーブルを複数のテーブルに分割することが許容されている。また、OpenFlowでは、ＯＦ−ＳＷ２におけるフローテーブルの実装方法に言及していない。すなわち、ＯＦ−ＳＷ２に実装されるフローテーブルフローテーブルの個数や、各フローテーブルのデータ構造に制限はない。例えば、ＯＦ−ＳＷ２に、マッチ条件を記憶した複数のテーブルを設け、各テーブルに対応するアクション情報のエントリを含むテーブル（アクションテーブル）が１以上設けられる場合もある。実施形態に係る構成は、OpenFlow ver.1.0及びOpenFlow ver.1.1の双方について適用可能である。

以下、マスク付き検索による性能低下（検索速度低下など）によってスループットが低下するのを抑止可能とするための構成について説明する。フローテーブルのような検索テーブルに要求される要件は、マッチ条件に適合する（マッチ条件で規定される集合の要素となる）全てのパケットが検索されるように、マッチ条件のエントリがテーブルに登録されていることである。

マッチ条件の要素が、ＩＰアドレスのように、マスク位置を適宜変更可能である場合には、マスク付き検索テーブルでフローテーブルを形成する。これによって、マスク位置の異なる（例えば、異なるプレフィクス長を有する）複数のエントリ（マッチ条件）を同一のテーブル内に記憶することができる。

これは、エントリ毎にマスク位置を変更し得るマスク付きテーブルの柔軟性によってなされる。これに対し、もし、テーブルが所望のパケットを検索し得るのであれば、テーブルが柔軟性を具備することは必ずしも要求されない。すなわち、或る時点のマスク付き検索テーブルによって検索し得る全てのパケットが、個々のエントリによって表現されたマスク無し検索テーブルにて検索され得るならば、マスク付き検索テーブルとマスク無し検索テーブルとは、機能において等価と云える。

図３及び図４は、実施形態に係る説明図である。例えば、マッチ条件として、ＩＰアドレスを検索する場合を仮定する。以下の説明において、テーブルに登録され、パケットから検索キーとして抽出された情報と照合される情報を、「キー（Key）エントリ」又は「
キー情報」という場合がある。また、検索キーとして抽出された情報を、「キー情報」という場合もある。

“10.1.1.x/24(上位３バイト（byte(s)）がプレフィクスであり、下位１バイトはマス
ク可能)”というマッチ条件を含むフローエントリをフローテーブルに追加する旨のＯＦ
Ｃからの要求を、ＯＦ−ＳＷが受信する。

ＯＦ−ＳＷのテーブル作成部は、ＯＦＣからの指示に従って、“10.1.1.x”のフローエントリを含む４バイト長のマスク付きテーブルを、フローテーブルとして作成する（図３の左側参照）。

この“10.1.1.x”は、ＯＦ−ＳＷに到着するパケットのうち、10.1.1.0〜10.1.1.255の何れかのＩＰアドレスを有する２５６パターンのパケットを検出することができる。なお、ＩＰアドレスのプリフィックス長は適宜設定可能である。この場合、フローテーブルは、マスク長やマスク位置の異なるエントリ（例えば、下位２バイトがマスクである場合など）を記憶可能に形成される。

４バイト長のマスク付きテーブルに、キーエントリとして“10.1.1.x”だけが登録されている時点では、当該マスク付きテーブルは、図３の右側に示すように、“10.1.1”の３バイト長のエントリが登録されたマスク無しテーブルと等価である。すなわち、下位１バイトを検索対象に含めないテーブルでも、４バイト長のマスク付きテーブルと同じＩＰアドレスを検出することができる。但し、両テーブル間で検索速度に差がある場合、検索速度の速い（検索時間の短い）テーブルが性能の良いテーブルとされる。

次に、図４に示すように、“10.1.2.3”（４バイトでマスク無し）というＩＰアドレスがマッチ条件として、フローテーブルに追加登録される場合を仮定する。図４の左に示すように、“10.1.2.3”（マスク無し）のエントリを追加し、当該エントリについてはマスク無しの４バイトを検索対象とする検索を行う。“10.1.1.x”のエントリについては、下位１バイトをマスク（参照しない部分）とする検索を行うことができる。

一方、図３の右側に示したような３バイト長のマスク無しテーブルに“10.1.2.3”（マスク無し）のエントリを追加することはできない。検索対象のバイト長が異なるからである。この様な、既存テーブルに登録し得ないエントリの追加の指示が到着した場合、テーブルの種類を変更し、既存のエントリで検索し得るパケットの全てと、追加の指示に係るエントリで検索し得るパケットの全てとを検索可能なテーブルを構築する方法が考えられる。

図３の例では、“10.1.1”（マスク無し）のエントリは、“10.1.1.0”〜“10.1.1.255”の２５６パターンのエントリと等価と考えることができる。このため、図４の右側に示すように、“10.1.1.0”〜“10.1.1.255”に対応する２５６個のエントリと、追加指示に係る“10.1.2.3”のエントリとが登録されたテーブルを構築する。すなわち、テーブルの種類（構造）を、「３バイト長のマスクなしテーブル」から「４バイト長の完全一致検索テーブル」へ変更する。この様なテーブルは、“10.1.1.x”及び“10.1.2.3”に含まれる全ての要素（パケット）を検出することができる。

よって、図４の左側のテーブルと、右側のテーブルとは、所望のパケットの全てを検出可能である点で等価である。但し、左側のテーブルと右側のテーブルとの間に検索速度の
差がある場合には、検索速度が速いテーブルの種類が選択されるのが好ましい。例えば、一般的にマスク付きテーブルはマスク無しテーブルより性能が低いとされる。しかし、エントリ数がごく小さい場合、ハッシュ（Hash）演算を用いる完全一致検索よりも検索速度が速くなる場合もあり得る。

このため、エントリの追加に対応し得るテーブルの種類が複数の場合、各テーブルのエントリ数から、性能が高い（検索速度の速い（検索時間の短い））テーブルを選択する。これによって、エントリ追加に伴う検索速度低下を抑止し、スループット低下を回避し得る。以下、実施形態に係るスイッチ（ＯＦ−ＳＷ）の詳細について説明する。

＜スイッチ（ＯＦ−ＳＷ）の構成＞
図５は、ＯＦＣ１及びＯＦ−ＳＷ２のそれぞれとして使用可能な情報処理装置（コンピュータ）１０のハードウェア構成例を示す。情報処理装置１０として、例えば、パーソナルコンピュータ（ＰＣ），ワークステーション（ＷＳ）のような汎用コンピュータを適用できる。或いは、サーバマシンのような専用のコンピュータを適用することもできる。但し、上述したＰＣ，ＷＳ，サーバマシン以外のコンピュータを用いる場合もある。

図５に示すように、情報処理装置１０は、例えば、バスを介して相互に接続された、Central Processing Unit（ＣＰＵ）１１と、メモリ１２と、出力装置１３と、入力装置１
４と、通信インタフェース（通信ＩＦ）１５とを含む。ＣＰＵ１１は、「制御部」、「制御装置」の一例であり、メモリ１２は、「記憶装置」、「記憶部」、「記憶媒体」の一例である。

メモリ１２は、主記憶装置と補助記憶装置とを含む。主記憶装置は、プログラムの展開領域，ＣＰＵ１１の作業領域，データやプログラムの記憶領域又はバッファ領域として使用される。主記憶装置は、例えばRandom Access Memory（ＲＡＭ），或いはＲＡＭとRead
Only Memory（ＲＯＭ）との組み合わせで形成される。

補助記憶装置は、例えば、ハードディスクドライブ（ＨＤＤ），Solid State Drive（
ＳＳＤ），フラッシュメモリ，Electrically Erasable Programmable Read-Only Memory
（ＥＥＰＲＯＭ）などの不揮発性記憶媒体で形成される。補助記憶装置は、データやプログラムの記憶領域として使用される。

出力装置１３は、データや情報を出力する。出力装置１３は、例えば、ディスプレイ，プリンタなどである。入力装置１４は、情報やデータの入力に使用される。入力装置１４は、例えば、キー，ボタン，マウス等のポインティングデバイス，タッチパネルなどである。

通信ＩＦ１５は、ネットワークに接続され、他の通信装置とデータを送受信するインタフェース回路である。通信ＩＦ１５として、例えば、Local Area Network（ＬＡＮ）カードやネットワークインタフェースカード（ＮＩＣ）と呼ばれる通信インタフェースカードが適用される。

ＣＰＵ１１は、プロセッサの一例であり、メモリ１２中の主記憶装置及び補助記憶装置の少なくとも一方に記憶されたプログラムを主記憶装置にロードして実行する。これによって、ＣＰＵ１１は、情報処理装置１０をＯＦＣ１、或いはＯＦ−ＳＷ２として動作させる。

ＣＰＵ１１は、ＭＰＵ（Microprocessor）、プロセッサとも呼ばれる。ＣＰＵ１１は、単一のプロセッサに限定される訳ではなく、マルチプロセッサ構成であってもよい。また
、単一のソケットで接続される単一のＣＰＵがマルチコア構成を有していても良い。ＣＰＵ１１で行われる処理の少なくとも一部は、ＣＰＵ以外のプロセッサ、例えば、Digital Signal Processor(DSP)、Graphics Processing Unit（GPU）、数値演算プロセッサ、ベクトルプロセッサ、画像処理プロセッサ等の専用プロセッサで行われても良い。

また、ＣＰＵ１１で行われる処理の少なくとも一部は、集積回路（ＩＣ）、その他のディジタル回路で行われても良い。また、集積回路やディジタル回路はアナログ回路を含んでいても良い。集積回路は、ＬＳＩ，Application Specific Integrated Circuit（ASIC
），プログラマブルロジックデバイス（ＰＬＤ）を含む。ＰＬＤは、例えば、Field-Programmable Gate Array(FPGA)を含む。ＣＰＵ１１で行われる処理の少なくとも一部は、プ
ロセッサと集積回路との組み合わせにより実行されても良い。組み合わせは、例えば、マイクロコントローラ（ＭＣＵ），ＳｏＣ（System-on-a-chip），システムＬＳＩ，チップセットなどと呼ばれる。

図６は、スイッチ（ＯＦ−ＳＷ）２の機能を模式的に示す図であり、図７は、スイッチ（ＯＦ−ＳＷ）２のフローテーブル作成に係る機能を模式的に示す図である。ＯＦ−ＳＷ２は、「パケット処理装置」の一例である。

図６において、ＯＦ−ＳＷ２は、メッセージ送受信部４１と、パケット処理部４２と、入出力処理部４３とを含む。パケット処理部４２は、フローテーブル４と、テーブル分析・選択部４５と、性能ナレッジ蓄積部４６とを含む。但し、テーブル分析・選択部４５及び性能ナレッジ蓄積部４６は、パケット処理部４２から独立した存在であっても良い。

メッセージ送受信部４１は、ＯＦＣ１と通信を行い、メッセージ交換を行う。例えば、メッセージ送受信部４１は、フローエントリの提供要求をＯＦＣに送信したり、フローエントリの登録要求（追加要求）のメッセージをＯＦＣ１から受信したりする。

入出力処理部４３は、複数のポートを有する。図６には、複数のポートの例示として、ポートＰ１〜Ｐ６が示されている。ポートＰ１〜Ｐ６のそれぞれは、パケットの入力ポート及び出力ポートの少なくとも一方として使用可能である。

パケット処理部４２は、入出力処理部４３のポートで受信されたパケットに関するフローテーブル４の検索処理を行い、パケットと合致するマッチ条件を含むエントリを特定する。パケット処理部４２は、マッチ条件に対応するアクション情報を特定し、アクション情報に従った動作を行う。例えば、アクション情報が所定のポート（例えばポートＰ５）からのパケット出力を示す場合、入出力処理部４３において、パケットがポートＰ５から出力される。

なお、図３に示した通信ＩＦ１５は、例えば、メッセージ送受信部４１及び入出力処理部４３として動作する。ＣＰＵ１１は、パケット処理部４２，テーブル分析・選択部４５，性能ナレッジ蓄積部４６として動作する。フローテーブル４と、テーブル分析・選択部４５及び性能ナレッジ蓄積部４６が管理する情報及びデータ（予測時間ＤＢ４７、各種の判定閾値など）とは、メモリ１２に記憶される。

テーブル分析・選択部４５は、現在のフローテーブル４に登録（記憶）されたキーエントリ情報と、ＯＦＣ１から追加が要求されたフローエントリ情報（キーエントリ情報を含む）とに基づき、複数のテーブル種別から候補となりうる複数のテーブル種別を抽出する。

テーブル分析・選択部４５は、候補毎にテーブルの種別、構築後のテーブルのエントリ
数、などの情報（テーブル構成情報）を性能ナレッジ蓄積部４６に供給するとともに、当該情報に基づく予測所要時間を性能ナレッジ蓄積部４６に問合せる。なお、候補が種別の異なる複数の多段テーブルとなる場合があり得る。この場合、多段テーブルを形成する各テーブルの種別、エントリ数，テーブルの段数（ステージ数）がテーブル構成情報となる。予測所要時間は、テーブルの種別、エントリ数などから特定されるテーブルを用いて検索を行った場合における検索の所要時間の予測値を示す。予測所要時間は、検索速度を示す情報でもある。

性能ナレッジ蓄積部４６は、テーブルの種別、エントリ数毎にパケットを処理するための予測所要時間を記憶した予測時間データベース（予測時間ＤＢ）４７を管理する。図８は、予測時間ＤＢ４７のデータ構造例を示す。予測時間ＤＢ４７は、テーブル種別、エントリ数、及び予測時間が関連づけられた１以上のエントリ（レコード）で形成される。なお、候補が多段テーブルをなす場合、例えば、多段テーブルを形成するテーブル毎の予測所要時間が予測時間ＤＢ４７から読み出され、その合計値が検索時間の予測値として使用され得る。

予測時間ＤＢ４７に記憶される情報は、手入力によって予め記憶されても良い。また、実際のパケット処理時間計測によって得られた時間が予測時間ＤＢ４７に記憶されても良い。また、予測時間ＤＢ４７に手入力で記憶された値が実際の時間計測によって更新されるようにしても良い。

予測所要時間が実際のパケットの処理時間計測によって得られる場合、例えば、図９に示すＯＦ−ＳＷ２の他の実施形態に係る構成を採用することができる。図９に示す様に、ＯＦ−ＳＷ２は、時刻挿入部４８と、時刻計測部４９とを備える。時刻挿入部４８は、パケットに現在時刻情報を付与する。時刻計測部４９は、フローテーブル４を用いた検索後の時刻からパケットに付与された現在時刻を減じて、所要時間を算出する。所要時間は、性能ナレッジ蓄積部４６に通知され、性能ナレッジ蓄積部４６は、予測時間ＤＢ４７に所要時間を記憶する。このとき、性能ナレッジ蓄積部４６は、テーブル分析・選択部４５から、検索に使用中のフローテーブル４のテーブル種別及びエントリ数の情報を得ており、所要時間と関連づけて予測時間ＤＢ４７に記憶する。

これによって、予測所要時間情報が事前に予測時間ＤＢ４７に記憶されていない場合でも、予測時間ＤＢ４７を構築することができる。事前の記憶がある場合でも、所要時間の実測によって精度を高めることができる。

なお、予測時間ＤＢ４７に蓄積された情報が不十分で、パケット処理時間（例えばテーブルの検索時間）の短いテーブルを候補から選択するのが困難な場合があり得る。この場合、性能ナレッジ蓄積部４６は、テーブル分析・選択部４５から示された候補のうちの一つを選択して回答する一方で、上記した時刻挿入部４８と、時刻計測部４９とを用いて所要時間のデータを収集する。このようにして、予測時間ＤＢ４７へデータを蓄積できる。例えば、所望の頻度、回数などで、問い合わせに対して回答するテーブル種別を変更することで、複数のテーブル種別、エントリ数に対する所要時間のデータを収集し、予測時間ＤＢ４７に蓄積することができる。

フローテーブル４は、「フローテーブル４のパケット識別情報と、前記パケット識別情報に対応する処理を示す情報とを含むテーブル」の一例である。フローテーブル４に記憶されるマッチ条件は、「パケット識別情報」の一例であり、フローテーブル４に記憶されるアクションは、「パケット識別情報に対応する処理を示す情報」の一例である。フローテーブル４は、１段または複数段のテーブルで形成することができる。パケット処理部４２は、「処理部」の一例である。テーブル分析・選択部４５は「取得部」、「管理部」の
一例である。性能ナレッジ蓄積部４６は、「選択部」、「蓄積部」の一例である。予測時間ＤＢ４７は、「記憶部」の一例である。

＜テーブル分析・選択部の処理＞
図１０は、テーブル分析・選択部４５によって行われるテーブル種別（候補）の判定処理の一例を示すフローチャートである。図１０に示す処理は、テーブル分析・選択部４５として動作するＣＰＵ１１によって行われる。図１０に示す処理は、ＣＰＵ１１が既存のフローテーブル４のキー（Key）エントリ（マッチ条件）と、ＯＦＣ１から追加が要求さ
れたフローエントリのキーエントリ（マッチ条件）とを得た場合に開始される。

図１０の００１の処理では、ＣＰＵ１１は、既存のキーエントリ（既存エントリ）及び新規のキーエントリ（新規エントリ）がマスク付きか否かを判定する。既存エントリ及び新規エントリがマスク付きでない場合、処理が００２に進み、そうでない場合、処理が００３に進む。

００２に処理が進んだ場合には、ＣＰＵ１１は、現在のフローテーブル４のエントリ数に追加が指示されたフローエントリの数（１）を加えた数が、所定数（例えば１０）以下で、且つ検索対象のバイト数が所定バイト数（例えば２バイト）以下か否かを判定する。

エントリ数が所定数以下で且つ検索対象のバイト数が所定バイト数以下と判定される場合には、ＣＰＵ１１は、テーブル種別の候補を「少エントリ型ＥＭ」，「ハッシュ型ＥＭ」，「マスク付き逐次検索＋キャッシュ方式」，及び「マスク付き逐次検索」と判定する。

これに対し、エントリ数及び検索対象のバイト数の少なくとも一方が所定数を超過すると判定される場合には、ＣＰＵ１１は、テーブル種別の候補を「ハッシュ型ＥＭ」，「マスク付き逐次検索＋キャッシュ方式」，及び「マスク付き逐次検索」と判定する。

００３に処理が進んだ場合には、ＣＰＵ１１は、既存エントリのマスク位置と、新規エントリのマスク位置とが一致しているか否かを判定する。既存エントリのマスク位置と、新規エントリのマスク位置とが一致していると判定される場合には、ＣＰＵ１１は、処理を００２に進める。これに対し、既存エントリのマスク位置と、新規エントリのマスク位置とが一致していないと判定される場合には、ＣＰＵ１１は、処理を００４に進める。

なお、００１の処理において、既存エントリと新規エントリとの一方がマスク付きで、他方がマスク無しである場合にも、００３の処理が行われる。この場合、マスク位置が、マスク無しのキーエントリで検索対象となっていない部分と一致するか否かが判定される。例えば、図３に示した例のように、３バイト長のマスク無し検索で検索とならない部分（下位１バイト）と、マスク付き検索でマスクされた部分（下位１バイト）とが一致するか否かが判定される。

００４の処理では、ＣＰＵ１１は、既存エントリのマスク位置と新規エントリのマスク位置との不一致箇所のビット数が所定数（例えば３ビット）以下か否かを判定する。不一致箇所のビット数が所定数以下と判定される場合には、ＣＰＵ１１は、処理を００６に進める。これに対し、不一致箇所のビット数が所定数を超過すると判定される場合には、ＣＰＵ１１は、処理を００５に進める。

００５の処理では、ＣＰＵ１１は、既存エントリ及び新規エントリのマスクされていない部分（マスク以外）のビットが連続しているか不連続（離散的に存在する）かが判定される。ビットが連続していると判定される場合には、ＣＰＵ１１は、テーブル種別の候補
を「ツリー型マスク（Tree型Mask）」，「マスク付き逐次検索＋キャッシュ方式」及び「マスク付き逐次検索」と判定する。

これに対し、ビットが不連続と判定される場合には、ＣＰＵ１１は、テーブル種別の候補を「マスク付き逐次検索＋キャッシュ方式」及び「マスク付き逐次検索」と判定する。

００６の処理では、ＣＰＵ１１は、既存エントリ及び新規エントリのマスクされていない部分（マスク以外）のビットが連続しているか不連続（離散的に存在する）かが判定される。ビットが連続していると判定される場合には、ＣＰＵ１１は、テーブル種別の候補を「ツリー型マスク」，「多段ＥＭ」，「マスク付き逐次検索＋キャッシュ方式」及び「マスク付き逐次検索」と判定する。

これに対し、ビットが不連続と判定される場合には、ＣＰＵ１１は、テーブル種別の候補を「多段ＥＭ」，「マスク付き逐次検索＋キャッシュ方式」及び「マスク付き逐次検索」と判定する。

ここで、図１０で例示したテーブル種別のそれぞれについて説明する。図１１は、テーブル種別「マスク付き逐次検索」の説明図である。「マスク付き逐次検索」のテーブルは、キーエントリをなすビット列の一部を検索対象とし、参照不要な箇所はマスクされ得るテーブル構成を有する。「マスク付き逐次検索」では、エントリ検索において、テーブルの先頭の（上の）エントリから順に参照される。

図１１に示す例では、フローテーブル４は、ＭＡＣアドレス及びＩＰアドレス（宛先及び送信元の少なくとも一方）の少なくとも一方がマッチ条件に設定されており、さらに、ＭＡＣアドレス及びＩＰアドレスの少なくとも一方にマスクを設定することができる。マスクは、ＭＡＣアドレス及びＩＰアドレスのそれぞれの一部に設定可能である。

「マスク付き逐次検索」のテーブルは、１つのテーブル内に複数種類のマッチ条件を取り込むことが可能であるが、テーブルの構造が複雑となる。このため、テーブル中の各エントリが逐次参照されて、各エントリに施されたマスクの状況に従った照合処理が行われる。このため、「ツリー型マスク」や「ハッシュ型ＥＭ」に比べて検索速度が遅い。

図１２は、「ツリー型マスク」のテーブルの説明図である。「ツリー型マスク」のテーブルでは、キーエントリがビット単位に分解され、上位ビットから分岐しながらマッチするエントリが探索される。「ツリー型マスク」のテーブルでは、任意の数の下位ビットをマスクすることもできる（図１２では、マスクはアスタリスク（＊）で示されている。例えば“01**”）。但し。上位ビットや途中のビットをマスクすることはできない。例えば“**01”や“0**1”などのマスク設定はできない。

キーエントリの一部がマスクされている場合、マスクされていない部分の最下位ビットにおいて、当該キーエントリの検索は終了する。図１２に示す例では、キーエントリが４ビットで形成されているため、最大４回ツリーを辿ることで検索が終了する。「ツリー型マスク」は、例えば、プレフィックスによって下位ビットがマスクされるＩＰアドレスの検索に使用される。

図１３は、テーブル種別「ハッシュ型ＥＭ」の説明図である。ハッシュ型ＥＭは、完全一致（Exact Match : EM）検索方式の一つである。ハッシュ型ＥＭでは、キーエントリのビット列に対するハッシュ演算を行い得られたハッシュ値を情報格納先のメモリアドレスに設定する。

例えば、３２ビットのＩＰアドレスがキーエントリ（マッチ条件）であると仮定する。この場合、フローエントリの登録時に、登録対象のＩＰアドレス(例えば192.168.1.1)に
対するハッシュ演算が行われる。ハッシュ演算によって、ＩＰアドレスは、例えば１２ビットのハッシュ値（0x126）に縮退する。この値“0x126”のメモリアドレスに、キーエントリ（Key情報）“192.168.1.1”と、アクション情報とが関連づけて登録（記憶）される。

ＩＰアドレス“192.168.1.1”を有するパケットがＯＦ−ＳＷ２に到着すると、ＩＰア
ドレスのハッシュ演算によってハッシュ値“0x126”が算出される。そして、ハッシュ値
と合致するメモリアドレスに記憶されたキーエントリに対応するアクション情報が検索される。このように、テーブルの順次検索が不要であるため、逐次検索に比べて検索時間が短い。すなわち、高速な検索が可能である。

図１４は、テーブル種別「少エントリ型ＥＭ」の説明図である。「少エントリ型ＥＭ」は完全一致検索方式（ＥＭ）の一つである。「少エントリ型ＥＭ」では、テーブルに登録されるエントリ数が所定数（図１４の例では最大８）に限定され、検索処理が簡素化される。検索方法としては、先頭のエントリから順次検索を行う逐次検索が適用される。或いは、検索方法として、Key情報をそのままメモリアドレスに設定する方法なども考えられ
る。

図１５は、テーブル種別「多段ＥＭ」の説明図である。「多段ＥＭ」は、上記した「ハッシュ型ＥＭ」や「少エントリ型ＥＭ」のテーブル（ＥＭテーブル）を直列に並べたテーブル構成を有する。段数は２以上の数とされる。例えば、テーブル構成が２段である場合、最初のテーブルを用いた検索を行い、合致するエントリがヒットすれば、次段以降のテーブル検索がスキップされ、合致するエントリがヒットしなければ、次段のテーブル検索が実行される。

検索方法としては、ハッシュ値を用いた検索や逐次検索が適用される。例えば、複数のフローエントリを１つのテーブルに纏めると「マスク付き逐次検索」となるが、複数のフローエントリを複数のＥＭテーブルで表現できるケースでの適用が考えられる。

図１６は、テーブル種別「マスク付き逐次検索＋キャッシュ方式」の説明図である。「マスク付き逐次検索+キャッシュ方式」は、「マスク付き逐次検索」の欠点を補うために
、ハッシュ型ＥＭテーブルをキャッシュとして有するテーブル構成である。

図１６に示すように、「マスク付き逐次検索＋キャッシュ方式」では、ハッシュ型ＥＭテーブルと、マスク付き逐次検索テーブルとが用意される。パケットが到着すると、パケットからKey情報（図１６の例はＭＡＣアドレス及びＩＰアドレス）が抽出され、ＭＡＣ
アドレス及びＩＰアドレスからハッシュ値を演算し、ハッシュ値でキャッシュ（ＥＭテーブル）を検索する。このとき、対応するエントリがヒットすれば検索が完了する。これに対し、キャッシュ（ＥＭテーブル）からエントリがヒットしない場合には、マスク付き逐次検索テーブルを用いた逐次検索が実行される。

マスク付き逐次検索テーブルを用いた検索によって対応するエントリがヒットした場合には、以下が行われる。すなわち、Key情報（マスク無し）と、ヒットしたエントリ中の
“アクション（Action）”と、Key情報のハッシュ値を含むエントリが、キャッシュ（Ｅ
Ｍテーブル）に登録される。これによって、同一のKey情報を用いた検索については、キ
ャッシュ（ＥＭテーブル）を用いて逐次検索より高速に検索することが可能となる。

図１７は、複数のテーブル種別についての、エントリ数と予想所要時間との関係を示す
グラフであり、当該グラフに示されたデータが、例えば、図８に示したデータ構造によって、予測時間ＤＢ４７に記憶されている。予測時間ＤＢ４７に対する読み出し及び書き込みは、例えば、性能ナレッジ蓄積部４６によって行われる。

テーブル種別は、大略して、マスク無し型とマスク有り型とに分けられる。マスク無し型は、「少エントリ型ＥＭ」，「ハッシュ型ＥＭ」を含む。なお、「多段ＥＭ」は、マスク無し型に含まれる。マスク有り型は、「ツリー型マスク（Patriciaツリー型マスク）」，「逐次検索＋キャッシュ方式」，「逐次検索」を含む。

テーブル分析・選択部４５は、複数の候補が得られると、性能ナレッジ蓄積部４６に、予定所要時間の短いテーブル種別の問い合わせを行う。

＜性能ナレッジ蓄積部の処理＞
図１８は、性能ナレッジ蓄積部４６による処理例を示すフローチャートである。図１８の処理は、例えば、性能ナレッジ蓄積部４６として動作するＣＰＵ１１によってなされる。図１８の処理は、テーブル分析・選択部４５から、複数の候補のテーブル種別及びエントリ数を受け取ることによって開始される。

１０１の処理では、ＣＰＵ１１は、予測時間ＤＢ４７を参照し、各テーブル種別に対応する予測所要時間（予測処理時間）を読み出す。なお、テーブル種別が多段ＥＭである場合には、多段テーブルを形成する各テーブルの種別及びエントリ数（テーブル分析・選択部４５から通知される）に基づき、各テーブルの予測所要時間の合計値を多段ＥＭの予測所要時間とする。

１０２の処理では、ＣＰＵ１１が、対応する予測所要時間が予測時間ＤＢ４７に記憶されていないテーブル種別（第１の候補の一例）があるか否かを判定する。対応する予測所要時間が予測時間ＤＢ４７に記憶されていないテーブル種別がない場合には、処理が１０３に進み、対応する予測所要時間が予測時間ＤＢ４７に記憶されていないテーブル種別がある場合には、処理が１０４に進む。

１０３の処理では、ＣＰＵ１１は、複数の候補の予測所要時間を対比し、複数の候補のうち、予測所要時間が短いテーブル種別を特定し、テーブル分析・選択部４５に通知する。このように、予測所要時間が短い、すなわち、検索時間が短い（性能が高い）テーブル種別が選択される。

このように、テーブル分析・選択部４５は、複数の候補のテーブル種別がある場合に、性能の高い（検索時間の短い）テーブル種別を性能ナレッジ蓄積部４６に問い合わせる。性能ナレッジ蓄積部４６は、テーブル種別及びエントリ数に基づき、性能の高いテーブル種別をテーブル分析・選択部４５に回答する。テーブル分析・選択部４５は、性能ナレッジ蓄積部４６からの回答に応じて、作成するテーブル種別を決定する。

１０４の処理では、ＣＰＵ１１は、予測所要時間が蓄積されていないテーブル種別（「第１の候補」の一例）を問い合わせに対する回答としてテーブル分析・選択部４５に送る。予測所要時間が蓄積されていないテーブル種別が複数ある場合には、複数のテーブル種別から所定ルールに従って選択したテーブル種別の一つを、問い合わせに対する回答としてテーブル分析・選択部４５に送る。

このような選択は、所定回数連続して同一のテーブル種別が回答されるようにしても良く、回答毎にテーブル種別が異なるようにしても良い。この場合、ＣＰＵ１１は、時刻挿入部４８及び時刻計測部４９を用いて検索の所要時間を測定し、測定値に基づく予測所要
時間を予測時間ＤＢ４７に記憶する。このようにして、予測時間ＤＢ４７にデータが蓄積されるようにしても良い。すなわち、処理部が第１の候補に対応するテーブルを用いた検索を行った場合に、前記第１の候補に対応するテーブルの種別と、第１の候補に対応するテーブルに記憶されたパケットの識別情報の数と、検索に要した時間とが記憶部に記憶される。

＜テーブルの変更処理＞
図１９は、テーブルの変更処理の一例を示すフローチャートである。図２０は、テーブルの変更の説明図であり、図２１は、テーブルの追加の説明図である。図１９に示す処理は、テーブル分析・選択部４５として動作するＣＰＵ１１によって行われる。

２０１の処理では、ＣＰＵ１１は、フローエントリの追加によって、テーブル種別の変更が必要か否かを判定する。テーブル種別の変更が必要か否かは、上述した図１０や図１７の処理の結果に基づき判定される。

テーブル種別の変更が不要と判定される場合には、ＣＰＵ１１は、既存のフローテーブルに追加対象のエントリを追加する（２０２）。テーブル種別の変更が必要と判定される場合には、テーブルの置き換えか追加かが判定される（２０３）。

テーブルの置き換えとは、既存のフローテーブルを、テーブル種別の異なるフローテーブルに置き換えることを意味し、追加とは、新規のテーブルを追加して既存のフローテーブルとの多段構造にすることを意味する。

置き換えの場合、２０４〜２０７の処理が実行される。置き換えを、図２０を用いて説明する。一例として、現在（変更前：追加要求の受信前）のテーブル構成として、テーブルＩＤ（ＴＩＤ）＝９０のテーブルと、ＴＩＤ＝１００のテーブルと、ＴＩＤ＝１１０のテーブルとがあると仮定する。ＴＩＤ＝９０のテーブルには、次にＴＩＤ＝１００のテーブルへジャンプすることが指定されている。ＴＩＤ＝１００のテーブルには、次にＴＩＤ＝１１０のテーブルへジャンプすることが指定されている。なお、ＴＩＤ＝１１０のテーブルには、次にＴＩＤ＝１３０（図示せず）のテーブルへジャンプすることが指定されている。

ＴＩＤ＝１００のテーブルに対するエントリ追加の要求がＯＦＣ１からなされ、テーブル分析・選択部４５及び性能ナレッジ蓄積部４６による処理の結果、ＴＩＤ＝１００のテーブルの置き換えが決定されたと仮定する。

一例として、図３の左側に示したような、キーエントリ“10.1.1.x”のマスク付き検索テーブルが既存テーブルであり、“10.1.2.3”のような４バイトのキーエントリの追加が要求された場合を仮定する。この場合に、複数の候補から「ハッシュ型ＥＭ」が選択され、「ハッシュ型ＥＭ」への変更が決定されたと仮定する。なお、この例での「ハッシュ型ＥＭ」は、図４の右側に示した２５７パターンのエントリを有する一方、エントリに対する検索がキー情報のハッシュ値をメモリアドレスとする検索によって行われるテーブルである。この例におけるマスク付き検索テーブルは、第１テーブルの一例であり、ハッシュ型ＥＭのテーブルは、第２テーブルの一例である。テーブル分析・選択部４５（ＣＰＵ１１）は、「管理部」の一例として、第２テーブルとしての「ハッシュ型ＥＭ」テーブルを生成する。

２０４において、ＣＰＵ１１は、ＴＩＤ＝１００のテーブルのエントリ（図３の左側のテーブル参照）を参照して、図４の右側に示したような２５７パターンのエントリを有するハッシュ型ＥＭのテーブル（例えばＴＩＤ＝１０１）を生成する。

２０５において、ＣＰＵ１１は、ＴＩＤ＝１０１のテーブルの次情報（Next）をＴＩＤ＝１００のテーブルと同じ値（Next＝１１０）に設定する。２０６において、前のテーブル（ＴＩＤ＝９０）の次情報を、ＴＩＤ＝１０１に変更する。そして、ＴＩＤ＝１００のテーブルを削除する。

なお、図２０及び図２１の例では、フローテーブルが多段テーブル構成を有する例について説明しているが、フローテーブルが一段構成であっても良い。すなわち、図２０において、ＴＩＤ＝９０やＴＩＤ＝１１０のテーブルがなく、ＴＩＤ＝１００のテーブルがＴＩＤ＝１０１のテーブルに置き換えられる（交換する）場合が該当する。

追加の場合、２０８及び２０９の処理が実行される。置き換えを、図２１を用いて説明する。図２１に示す現在（変更前）のテーブル構成は、図２０と同じであるので説明を省略する。追加の一例として、例えば、図３の右側に示すテーブルが既存テーブル（ＴＩＤ＝１００：第１テーブルの一例）である一方、“10.1.2.3”のような４バイトのキーエントリの追加が要求された場合を仮定する。一例として、「多段ＥＭ」が選択され、“10.1.2.3”のＥＭテーブル（ＴＩＤ＝１０１）を作成し、“10.1.1”のＥＭテーブルと多段構成とすることが判定されたと仮定する。「多段ＥＭ」を形成するＥＭテーブルが「第２テーブル」の一例である。

この場合、ＣＰＵ１１は、ＴＩＤ＝１０１のテーブルを作成し、ＴＩＤ＝１０１のテーブルの次情報（Next）をＴＩＤ＝１００に設定し（２０８）、前のテーブル（ＴＩＤ「＝９０）の次情報をＴＩＤ＝１０１に設定する（２０９）。これによって、テーブル構成が、図２１に示すように、ＴＩＤ＝１０１のテーブルが挿入された状態となる。この例では、第２テーブルとしてのＥＭテーブルが第１テーブルとしての既存テーブルの前段に配置されているが、後段に配置されても良い。

＜動作例＞
以下、実施形態における動作例及び処理に関して説明する。実施形態では、フローテーブル４が、パケットをＩＰアドレスに基づき次ホップへ転送するフォワーディングテーブルとして使用される場合を一例に説明する。

ＯＦＣ１からは、マッチ条件として、プレフィックス付き（指定されたプレフィックス長を有する）ＩＰアドレスを含むフローエントリの追加要求がＯＦ−ＳＷ２へ送信される。初期状態ではフローテーブル４にエントリは存在せず、最初に、ＯＦ−ＳＷ２は、ＯＦＣ１からの要求に応じて、“10.1.1.x/24”というプリフィックス付きのＩＰアドレスを
マッチ条件とするフローエントリをフローテーブル４に登録したと仮定する。

ＯＦＣ１からの要求は、テーブル分析・選択部４５にて受け取られ、テーブル分析・選択部４５は、テーブルの分析を行い、候補のテーブル種別を判定する。テーブル分析・選択部４５は、図１０に示し候補抽出ロジックに基づいて候補を抽出する。例えば、テーブルにエントリがなく、“10.1.1.x/24”のエントリ追加が要求された場合、００１にて「
マスク付き」と判定され、００３にて「マスク位置一致」と判定される（既存エントリがないため）。その後、００２にて、検索対象領域が４バイト（ＩＰｖ４アドレス）であることから、「ハッシュ型ＥＭ」，「マスク付き逐次検索＋キャッシュ方式」及び「マスク付き逐次検索」がテーブル種別の候補として抽出される。

各候補のテーブル種別と現在のエントリ数（この場合１）などの情報は、性能ナレッジ蓄積部４６に渡される。性能ナレッジ蓄積部４６は、図１７に示したデータ内容を有する予測時間ＤＢ４７を管理しており、テーブル種別及びエントリ数に基づき予測所要時間が
短い（例えば候補中で最小となる）テーブル種別を導出する。但し、２位以降のテーブル種別が選択される場合もあり得る。

この例では、エントリ数が１であることから、複数の候補の中から「マスク付き逐次検索」が導出され、テーブル分析・選択部４５に通知される。テーブル分析・選択部４５は、テーブル種別「マスク付き逐次検索」のフローテーブル４を生成し、マッチ条件“10.1.1.x”のエントリを登録する。

その後、下位１バイトがマスクされるキー情報がマッチ条件とされるエントリがフローテーブル４に登録される場合を仮定する。すると、図１７における「逐次検索」のグラフからわかる様に、「逐次検索＋キャッシュ」及び「ハッシュ型ＥＭ」の予測所要時間が「逐次検索」の予測所要時間より短くなる。さらには、「ハッシュ型ＥＭ」の予測所要時間が「逐次検索＋キャッシュ」の予測所要時間を上回る。この場合、テーブル分析・選択部４５によって、図１９に示したようなテーブル変更処理が行われる。処理の詳細は既に説明したので再度の説明は省略する。その後、“10.1.2.3”のエントリの追加要求がＯＦＣ１から受信されると、上記した処理によって、テーブルの変更（交換）乃至追加（新規テーブルを既存テーブルの前段又は後段に配置）が行われる。

＜実施形態の効果＞
実施形態によれば、既存のエントリのキー情報（パケット識別情報）と、追加が要求されたエントリのキー情報（パケット識別情報）とに基づいて、種別の異なる複数のテーブルの候補が取得される。複数の候補から、エントリ数に対応する予測所要時間（検索時間）が短いテーブルが選択され、選択されたテーブルが生成され、検索に使用される。これによって、検索時間の低下を抑止でき、ＯＦ−ＳＷ２におけるスループットの低下を抑止又は回避することができる。以上説明した実施形態の構成は、適宜組み合わせることができる。

１・・・コントローラ（ＯＦＣ）
２・・・スイッチ（ＯＦ−ＳＷ）
１１・・・ＣＰＵ
４５・・・テーブル分析・選択部
４６・・・性能ナレッジ蓄積部
４７・・・予測時間データベース

Claims (10)

1. パケット識別情報と、前記パケット識別情報に対応する処理を示す情報とを含むテーブルと、
   受信されたパケットのパケット識別情報に対応する処理を前記テーブルから検索する処理部と、
   新規のパケットの識別情報を含む新規エントリの追加要求が受信された場合に、前記テーブルに記憶されている既存のパケット識別情報と、前記新規のパケット識別情報とに基づいて、種別が異なり且つ前記新規のパケットの識別情報及び前記既存のパケットの識別情報に含まれる全てのパケットを検索可能な複数のテーブルの候補を取得する取得部と、
   各候補のテーブルに記憶されるパケット識別情報の数に基づいて、前記複数のテーブル候補の中から前記処理部による検索に用いるテーブルを選択する選択部と
   を含むパケット処理装置。
2. 前記選択部は、検索時間の短い前記複数のテーブルの候補の一つを選択する
   請求項１に記載のパケット処理装置。
3. 前記処理部は、前記追加要求の受信前に前記テーブルとして第１テーブルを使用し、
   前記選択部によって選択された候補のテーブルの種別と前記第１テーブルの種別とが異なる場合に、前記処理部の検索に使用される第２テーブルとして前記選択された候補のテーブルを生成する管理部
   をさらに含む請求項１又は２に記載のパケット処理装置。
4. 前記管理部は、前記選択された候補のテーブルの種別と前記第１テーブルの種別とが同じである場合に、前記第１テーブルに前記新規エントリを追加する
   請求項３に記載のパケット処理装置。
5. 前記管理部は、前記第１テーブルを前記第２テーブルに交換する
   請求項３又は４に記載のパケット処理装置。
6. 前記管理部は、前記第２テーブルを前記第１テーブルの前段又は後段に配置する
   請求項３又は４に記載のパケット処理装置。
7. テーブルの種別及びエントリ数と検索時間とが対応づけて記憶された記憶部をさらに含み、
   前記選択部は、前記複数のテーブルの候補の種別及びエントリ数に対応する検索時間を前記記憶部から読み出して対比し、前記複数のテーブルの候補の一つを選択する
   請求項１から６のいずれか１項に記載のパケット処理装置。
8. 前記処理部がテーブルを用いて受信されたパケットに対する検索を行った場合に、前記検索に用いられたテーブルの種別及び前記検索に用いられたテーブルに記憶されたパケットの識別情報の数と、前記検索に要した検索時間とを対応づけて前記記憶装置に記憶する蓄積部をさらに含む
   請求項７に記載のパケット処理装置。
9. 前記選択部は、前記複数の候補が、テーブルの種別及びパケットの識別情報の数に対応する検索時間が前記記憶装置に記憶されていない第１の候補を含む場合に、当該第１の候補を選択し、
   前記管理部が、前記第１の候補に対応するテーブルを生成し、
   前記蓄積部が、前記処理部が前記第１の候補に対応するテーブルを用いた検索を行った
   場合に、前記第１の候補に対応するテーブルの種別と、前記第１の候補に対応するテーブルに記憶されたパケットの識別情報の数と、検索に要した時間とを前記記憶部に記憶する請求項８に記載のパケット処理装置。
10. パケット処理装置が、
    パケット識別情報と、前記パケット識別情報に対応する処理を示す情報とを含むテーブルから、受信されたパケットのパケット識別情報に対応する処理を前記テーブルから検索し、
    新規のパケットの識別情報を含む新規エントリの追加要求が受信された場合に、前記テーブルに記憶されている既存のパケット識別情報と、前記新規のパケット識別情報とに基づいて、種別が異なり且つ前記新規のパケットの識別情報及び前記既存のパケットの識別情報に含まれる全てのパケットを検索可能な複数のテーブルの候補を取得し、
    各候補のテーブルに記憶されるパケット識別情報の数に基づいて、前記複数のテーブルの候補の中から前記処理部による検索に用いるテーブルを選択する
    ことを含むパケット処理装置のテーブル選択方法。