(57)【要約】データベースにおいて複数フィールドに分割して格納されたエントリの中から、全ての検索対象フィールドにおいて全ての非マスクビットと、これらに対応する検索キーのビットデータとが一致するエントリを中間検索結果とし、該中間検索結果の各検索対象フィールドのプリフィクス長の中から検索対象フィールド毎の最長プリフィクス長を求め、該中間検索結果の内、優先度が最も高い検索対象フィールドにおいて該最長プリフィクス長を有するエントリを検索結果とする。
2005013566.tif 000002
【特許請求の範囲】
【請求項１】
データベースにおいて複数フィールドに分割して格納されたエントリの中から、全ての検索対象フィールドにおいて全ての非マスクビットと、これらに対応する検索キーのデータビットとが一致するエントリを中間検索結果とする第１ステップと、
該中間検索結果の各検索対象フィールドのプリフィクス長の中から該検索対象フィールド毎の最長プリフィクス長を求める第２ステップと、
該中間検索結果の内、優先度が最も高い検索対象フィールドにおいて該最長プリフィクス長を有するエントリを検索結果とする第３ステップと、
を有することを特徴とするデータ検索方法。
【請求項２】
請求の範囲１において、
該優先度が最も高い検索対象フィールドが、該第３ステップにおいて求められた該最長プリフィクス長同士の内、最長の検索対象フィールドであることを特徴とするデータ検索方法。
【請求項３】
請求の範囲１において、
検索開始前に各フィールドに該優先度を設定することを特徴とするデータ検索方法。
【請求項４】
請求の範囲３において、
該優先度は、検索を行う度に変更可能であることを特徴とするデータ検索方法。
【請求項５】
請求の範囲３において、
該優先度として所定の値が設定されたフィールドを検索対象外にすることを特徴とするデータ検索方法。
【請求項６】
エントリを複数フィールドに分割して格納したデータベースと、
各エントリのフィールド毎のプリフィクス長を保持するプリフィクス長保持部と、
全ての検索対象フィールドにおいてエントリの全ての非マスクビットと対応する検索キーのビットデータとが一致するエントリを中間検索結果とし、該プリフィクス長保持部に保持された該中間検索結果の各検索対象フィールドのプリフィクス長から検索対象フィールド毎の最長プリフィクス長を求め、該中間検索結果の内、優先度が最も高い検索対象フィールドにおいて該最長プリフィクス長を有するエントリを検索結果とする演算部と、
を備えたことを特徴とするデータ検索装置。
【請求項７】
請求の範囲６において、
該優先度が最も高い検索対象フィールドが、該演算部によって求められた該最長プリフィクス長同士の内、最長の検索対象フィールドであることを特徴とするデータ検索装置。
【請求項８】
請求の範囲６において、
検索開始前に各フィールドに該優先度を設定したことを特徴とするデータ検索装置。
【請求項９】
請求の範囲８において、
該優先度は、検索を行う度に変更可能であることを特徴とするデータ検索装置。
【請求項１０】
請求の範囲８において、
該優先度として所定の値が設定されたフィールドを検索対象外にすることを特徴とするデータ検索装置。
【発明の詳細な説明】
【技術分野】  本発明はデータ検索方法及び装置に関し、特にデータベースの中から検索キーに一致するデータを検索するデータ検索方法及び装置に関するものである。
【背景技術】  ネットワークの中継点となるルータ又はスイッチにおいては、ネットワーク内を流れるパケット（例えばＩＰデータグラム）の宛先に応じた経路選択処理、すなわちルーティング処理を行なう必要がある。
例えば、図６に示したルータ１０１はネットワークの中継点となっており、このルータ１０１にはネットワーク回線１０２〜１０５が接続されている。また、ネットワーク回線１０３〜１０５の先にはサーバ１３０、１４０、及び１５０がそれぞれ接続されている。
図示の如く、ルータ１０１がネットワーク回線１０２を介して受信するパケット１１０のヘッダには、レイヤー３に属する宛先ＩＰアドレス１１１及び送信元ＩＰアドレス１１２や、レイヤー４に属する宛先ポート番号１１３及び送信元ポート番号１１４の各情報が含まれている。
宛先ＩＰアドレス１１１からはパケット１１０を送信すべき宛先のネットワークを識別することが出来る。また、送信元ＩＰアドレス１１２からはパケット１１０の送信者を識別することが出来るため、識別された送信者との間で締結されているネットワークの利用に関する契約の内容（回線容量等）を把握することも出来る。さらに、宛先ポート番号１１３及び送信元ポート番号１１４からはアプリケーションの種類などを判別することが出来る。
従って、ルータ１０１はこれらの情報に基づき、パケット１１０を適切なネットワーク回線１０３，１０４，１０５に出力するように、レイヤー３又はレイヤー４のルーティング処理を行なう。
例えば、ネットワーク回線１０３及び１０４の回線容量（帯域）について、それぞれの実線の太さで表される如く、ネットワーク回線１０３が大容量であり、ネットワーク回線１０４が小容量であるような場合、パケット１１０の送信者との回線容量に関する契約内容に応じてルーティング処理を行うことが可能となる。
また、アプリケーション毎にサーバ１３０、１４０、及び１５０をそれぞれ対応させておくことにより、レイヤー３のルーティング処理で負荷分散を行うこともできる。
ルータ１０１においてルーティング処理を適切に行えば、柔軟なネットワークが構築可能となる。
一般に、上記のルーティング処理はソフトウェア及びハードウェアによる宛先のデータ検索処理によって実現されている。特に、高速・大容量のルーティング処理を行なうためのデータ検索装置としては、従来より連想メモリ（Ｃｏｎｔｅｎｔ  Ａｄｄｒｅｓｓａｂｌｅ／Ａｓｓｏｃｉａｔｉｖｅ  Ｍｅｍｏｒｙ：ＣＡＭ）デバイスが主として用いられている。
なお、ＣＡＭデバイスは、上記のルータ１０１の様にレイヤー３又はレイヤー４でのルーティング処理を行うルータだけでなく、レイヤー２スイッチ（図示せず）の様にＭＡＣアドレスによるスイッチングにも用いられている。
ＣＡＭデバイスを用いたルーティング処理の一例として、ＩＰアドレスの検索処理について図７を参照して以下に説明する。
図７は、例えば図６のルータ１０１内において、ルーティング処理に関連した部分の構成例を示したものである。
ＣＡＭデバイス２００は、検索対象のエントリ群を格納したデータベース２０３を有するものであり、ネットワークプロセッサ２１０は、ネットワークの処理に特化したプロセッサである。また、コンテキストＲＡＭ（Ｃｏｎｔｅｘｔ−ＲＡＭ又はＡｓｓｏｃｉａｔｅｄ−ＲＡＭ）２２０は、ＣＡＭデバイス２００の各エントリに対応した処理内容等を格納したメモリであり、通常ＳＲＡＭ、ＤＲＡＭなどのメモリデバイスで構成されるものである。
ＣＡＭデバイス２００、ネットワークプロセッサ２１０、及びコンテキストＲＡＭ２２０は、入力インタフェース２１１、出力バス２０１及び２２１でそれぞれ相互に接続されている。
動作において、ネットワークプロセッサ２１０は受信したパケット１１０からヘッダ情報を抽出して、検索したいＩＰアドレスまたはポート番号等を検索キー２１２として入力インタフェース２１１を介してＣＡＭデバイス２００に入力する。ＣＡＭデバイス２００内部のデータベース２０３には、予めネットワーク管理者によって入力されたＩＰアドレス情報がエントリ群として収容されており、ＣＡＭデバイス２００は、検索キー２１２とデータベース２０３の各エントリとを比較する。
ここで、ＣＡＭデバイス２００による比較動作は各エントリの各ビットに対して同時に行われる。検索した結果、適切なエントリが有った（ヒットした）場合、その中で“最も”適切なエントリの物理アドレス（同図の例ではアドレス［２］）をヒットアドレス２０２として出力バス２０１を介してコンテキストＲＡＭ２２０に与える。
コンテキストＲＡＭ２２０は、例えば、同図のヒットアドレス２０２として得られたアドレス［２］に対応して、対処すべき処理内容や出力ポート（配布先）のデータを出力バス２２１を介してネットワークプロセッサ２１０に検索結果２２２として与える。
ネットワークプロセッサ２１０は、検索結果２２２に応じてパケット１１０を処理したり、再度検索を行なったりする。
上記のＣＡＭデバイス２００内における従来のＩＰアドレス検索処理について、図８を参照してより詳細に説明する。
図８は、図７のＣＡＭデバイス２００においてＩＰアドレス検索処理に関連した部分をより詳細に示したものである。従って、図７のデータベース２０３に予めネットワーク管理者によって入力されたエントリ群の内、説明の便宜上、上位４つのエントリ＃１〜＃４のみが示されている。また、各エントリ＃１〜＃４毎に一致線３２１〜３２４が設けられており、それぞれプライオリティ・エンコーダ３３０に接続されている。
各エントリ＃１〜＃４は、ＩＰアドレスとサブネットマスクが一対となってデータベース２０３に収容されたものである。同図の各エントリ＃１〜＃４の上段にはそれぞれ、ＩＰアドレスとして“Ａ１”、“Ａ２”、“Ａ３″、及び“Ａ４”が示されており、下段にはそれぞれのサブネットマスクが連続したビット“１”及び“０”で示されている。この場合、連続したビット“１”はプリフィクス部分を示しており、連続したビット“０”はマスク部分を示している。
エントリ＃１〜＃４は、図示の如くサブネットマスクのプリフィクス部分（ビット“１”）の長さ、すなわちプリフィクス長（ｐｒｅｆｉｘ  ｌｅｎｇｔｈ）が長い順に並べられている。また、各エントリ＃１〜＃４の右側に示された［１］〜［４］は、それぞれの物理アドレスを示している。
ＩＰアドレスは右側の下位ビットほどネットワークの末端を現し、地図上の住所と同様に、より詳細な内容である下位ビットまで一致している検索結果ほど適切であるということができる。すなわち、ＩＰアドレスの検索結果としては、プリフィクス長が最も長いアドレスが最も適切であり、このような検索結果はロンゲスト・プリフィクス・マッチ（Ｌｏｎｇｅｓｔ  Ｐｒｅｆｉｘ  Ｍａｔｃｈ）と呼ばれるものである。エントリをプリフィクス長に従って並べて収容するのはこのためである。
運用中のＣＡＭデバイス２００の動作においては、ネットワークプロセッサ２１０などから検索キー２１２として例えばＩＰアドレス“Ａ−ＫＥＹ”が入力される。ＣＡＭデバイス２００は全エントリに対して同時に各ビットについて比較を行なう。但し、サブネットマスクが“０”のビットに関しては比較を行なわない（ドントケア条件）。
比較したビットが１つでも「不一致」である場合、一致線３２１〜３２４に不一致をあらわす信号が出力されて、不一致エントリとして識別される。同図の例では、不一致信号３３１及び３３３がそれぞれ一致線３２１及び３２３に出力されているため、エントリ＃１及び＃３が不一致エントリとして識別されている。
比較したビットが全て「一致」している場合は、エントリ＃２及び＃４の様に一致エントリとして識別される。
このように複数ヒットした場合は、従来よりプライオリティエンコーダ３３０は、プリフィクス長の長い方、すなわちエントリ＃２の物理アドレス［２］をヒットアドレス２０２として出力する。
このように、検索キー２１２のデータビットと、エントリ＃１〜＃４のデータビットとを比較する場合、マスクビットによるマスク処理を行うＣＡＭデバイスは３値のデータを扱うことからターナリＣＡＭデバイスと呼ばれ、一方、検索キー２１２のデータビットとエントリ＃１〜＃４のデータビットとの比較のみを行ない、マスク処理を行なわないＣＡＭデバイスは２値のデータを扱うことからバイナリＣＡＭデバイスと呼ばれている。
図９は、ターナリＣＡＭデバイスにおける１ビット分に相当するターナリＣＡＭセル６００の機能及び検索結果の真理値表６１０を示したものである。
同図（１）において、ターナリＣＡＭセル６００は、データビット６０１及びマスクビット６０２を保持しており、さらに、入力された検索キー６０７とデータビット６０１とを比較する比較処理部６０３と、この比較処理部６０３が出力する比較結果に対しマスクビット６０２に応じてマスク処理を施すマスク処理部６０４を有している。
データベースの１つのエントリは共通の一致線６０６に接続された複数のターナリＣＡＭセル６００によって構成されている。
動作において、ターナリＣＡＭセル６００は、比較処理部６０３によって検索キー６０７とデータビット６０１とが比較された結果に対して、マスク処理部６０４によってマスク処理を施した結果を、最終的な検索結果６０５として一致線６０６に出力する。
すなわち、比較処理部６０３は、検索キー６０７とデータビット６０１の値が異なれば“０”、等しければ“１”を出力し、マスク処理部６０４は、マスクビット６０２の値が“１”のときは比較処理部６０３の出力をそのまま検索結果６０５として出力し、マスクビット６０２の値が“０”のときは比較処理部６０３の出力に関わらず“１”を検索結果６０５として強制的に出力する。同図（２）は、このような検索結果を真理値表の形で示したものである。
なお、ここで動作が相等しければ論理反転させても良い。
データビット６０１及びマスクビット６０２を保持する機能としては、例えばフリップフロップ、キャパシタ、ヒステリシスを有する高誘電膜あるいは磁性膜を用いられる。
上記の図７及び図８に示したＣＡＭデバイス２００がターナリＣＡＭデバイスである場合、各エントリ＃１〜＃４は、エントリのビット数に応じたターナリＣＡＭセル６００によって構成されることになる。この場合、各一致線３２１〜３２４は一致線６０６に対応している。
上記の図８においては、特定の項目、すなわち、ＩＰアドレスのみを検索する場合を例にとって説明したため、各エントリ＃１〜＃４にはＩＰアドレスのみが収容されているように示したが、実際のＣＡＭデバイス２００内のデータベース２０３には、図１０（１）に示す如く、エントリ＃１〜＃４には例えばフィールドＦ１〜Ｆ５のように複数フィールドに分割されたデータが格納されている。
すなわち、エントリ＃１〜＃４のフィールドＦ１には、それぞれ送信元ＩＰアドレスとして“ＳＡ１”〜“ＳＡ４”が格納されており、同様に、フィールドＦ２には宛先ＩＰアドレスとして“ＤＡ１”〜“ＤＡ４”が格納されている。さらに、フィールドＦ３には、それぞれ送信元ポート番号として“ＳＰ１”〜“ＳＰ４”が格納されており、フィールドＦ４には宛先ポート番号として“ＤＰ１”〜“ＤＰ４”が格納されている。
また、フィールドＦ５には、その他の情報として、例えば、エントリの有効／無効を示すタグのように、外部から通知される管理用の情報が格納されている。
なお、フィールドＦ１及びＦ２は各エントリ＃１〜＃４について上下２段で示されているが、これは、フィールドＦ１及びＦ２には通常サブネットマスクが適用されるため、それぞれのプリフィクス部分４３１，４３２及びマスク部分４４１，４４２を下段に示したものである。フィールドＦ３〜Ｆ５については、通常はサブネットマスクを適用しないため１段で示されている。
同図（２）は、同図（１）のフィールドＦ１〜Ｆ５の内、特定のフィールドのみを検索対象に指定したい場合に用いられるグローバルマスクパターン４５０を示したものである。
このようなグローバルマスクパターン４５０を用いれば、同図の例では、マスク部分４５１及び４５３が検索対象外となり、検索対象部分４５２に対応して、宛先ＩＰアドレスを示すフィールドＦ２のみが検索対象になる。
従来より提案されているＣＡＭデバイスとしては、連想メモリアレイを複数のフィールドから構成し、検索対象となるフィールドを指示することにより、指示されたフィールドには検索対象データを、その他のフィールドにマスク信号を与えて検索を行なうものがある（例えば、特許文献１参照）。
また、ＩＰアドレスとプリフィクス長との組み合せにより表現された経路情報とともに別途当該プリフィクス長の情報を格納したもの（例えば、特許文献２参照）や、データ選択の優先順序を外部から任意に設定可能としたものもある（例えば、特許文献３参照）。
さらには、低消費電力によるデータ検索を可能とし、より集積度の高いメモリ幅拡張機能を有するもの（例えば、特許文献４参照）や、可変幅のデータを検索するための可変幅のＣＡＭデバイスもある（例えば、特許文献５参照）。
【特許文献１】      特開昭５８−２００４９４号公報（特許請求の範囲、図１）
【特許文献２】      特開２００２−３０５５３９号公報（要約、図１）
【特許文献３】      特開平１１−１０２５８９号公報（要約、図１）
【特許文献４】      特開平５−１８９９７８号公報（要約、図１）
【特許文献５】      特開２００１−１６０２９２号公報（要約、図２Ａ）
ＣＡＭデバイスを用いた検索を数十ビットの幅でしか行えない状況では、例えば、フロー識別などの処理を行なうために複数回ＣＡＭ検索を繰り返す必要があったが、近年では、多くのＣＡＭデバイスが数百ビットを超える多ビット幅検索に対応しており、例えば、ＩＰｖ４によるフロー識別を例にとると、宛先ＩＰアドレス（３２ビット）、送信元ＩＰアドレス（３２ビット）、宛先ポート番号（１６ビット）、及び送信元ポート番号（１６ビット）を１つのエントリとして合計９６ビット以上を一度に検索することが可能になっている。
しかしながら、従来の技術においては、上述の如く、複数のエントリがヒットした場合にプライオリティエンコーダ３３０が出力する最終検索結果は、エントリの格納順によって決まってしまう。
別の最終検索結果を得るためには、エントリの格納順を変更する必要があるが、これには、データベース２０３の書き換えが必要になる。このようなデータベース２０３のメンテナンスを行なうためには、ルータ１０１のルーティング処理を停止する必要があり、ネットワークのダウン時間を増大させることになる。
従って、ネットワークの常時運用を実現するためには、エントリの格納順は容易に変更することが出来ない。
一方、近年における仮想閉域網（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ：ＶＰＮ）の利用の拡大に伴い、顧客毎の柔軟な対応がネットワークの運用において重要になって来ている。例えば、ネットワークの障害時において、特定の顧客の回線を優先させる必要がある場合、当初の格納順が低位のエントリを優先させることが望まれる。
また、運用中のサーバ等の負荷が集中しないように、適切な負荷分散を行なう場合にも、当初の格納順が低位のエントリを優先させることが望まれる。
従って、本発明は、データベースの中から検索キーに一致するデータを検索するデータ検索方法及び装置に関し、エントリの格納順に拘束されることなく、所望の優先度に基づく検索結果を得ることを目的とする。
【発明の開示】
上記の目的を達成するため、本発明に係るデータ検索方法は、データベースにおいて複数フィールドに分割して格納されたエントリの中から、全ての検索対象フィールドにおいて全ての非マスクビットと、これらに対応する検索キーのデータビットとが一致するエントリを中間検索結果とする第１ステップと、該中間検索結果の各検索対象フィールドのプリフィクス長の中から該検索対象フィールド毎の最長プリフィクス長を求める第２ステップと、該中間検索結果の内、優先度が最も高い検索対象フィールドにおいて該最長プリフィクス長を有するエントリを検索結果とする第３ステップと、を有することを特徴としている。
本発明の原理を図１を用いて以下に説明する。同図は、データベースに格納されたエントリ＃１〜＃５の各々について、例えば複数のフィールドＦ１及びＦ２を検索対象とする検索キー（図示せず）が入力された際の一致／不一致の状態を模式的に示したものである。
各エントリ＃１〜＃５の点線又は実線で囲まれた各フィールドＦ１及びＦ２内の白地部分において、例えば“／２４”のように示された数値は、プリフィクス長（サブネットマスクされていないプリフィクス部分の長さ）を示すビット数である。また、白地部分に隣接した網掛部分は、マスク部分（サブネットマスクされた部分）を示したものである。
すなわち、同図のエントリ＃１のフィールドＦ１のプリフィクス長は２４ビットであり、フィールドＦ２のプリフィクス長は２２ビットであることを示している。同様に、エントリ＃２〜＃５のフィールドＦ１のプリフィクス長はそれぞれ、２４ビット、２０ビット、１７ビット、１２ビットであり、フィールドＦ２のプリフィクス長はそれぞれ、１７ビット、１７ビット、２２ビット、１６ビットである。
また、点線で示したエントリ＃１，＃２，及び＃５は、プリフィクス部分の少なくとも１ビットが対応する検索キーのデータビットに一致しないために、「不一致」であると判定されている。
他方、実線で示したエントリ５０３及び５０４は、プリフィクス部分の全ビット（非マスクビット）が対応する検索キーのビットデータに「一致」しており、中間検索結果になっている。
ここで、従来の連想メモリの検索方法では、エントリ＃１〜＃５の格納順を優先順位として検索結果を出力するため、上記の如く抽出されたエントリ＃３及び＃４の内、より上位に格納されたエントリ＃３が検索結果として出力されることになる。
このような従来例とは異なり、本発明においては、上記の如く抽出されたエントリ＃３及び＃４についてプリフィクス長レジスタに保持された各検索対象フィールドＦ１及びＦ２のプリフィクス長から、フィールドＦ１及びＦ２における最長プリフィクス長を求める。
すなわち、同図において、フィールドＦ１における最長プリフィクス長は、エントリ＃３で求めた２０ビットであり、フィールドＦ２の最長プリフィクス長は、エントリ＃４で求めた２２ビットである。本発明ではさらに、優先度が最も高い検索対象フィールドにおいて最長プリフィクス長を有するエントリを最終検索結果とする。
従って、優先度が最も高い検索対象フィールドがフィールドＦ２であれば、上記の如く抽出されたエントリ＃３及び＃４の内、より下位に格納されたエントリ＃４を最終検索結果とすることが可能になる。
このように、優先度を適切に設定することにより、従来のようにエントリ＃１〜＃５の格納順に拘束されることなく、所望の優先度に基づく検索結果が得られるようになる。
上記の優先度が最も高い検索対象フィールドは、該第３ステップにおいて求められた該最長プリフィクス長同士の内、最長の検索対象フィールドであってもよい。
すなわち、上記の優先度の指標として最長プリフィクス長を用いれば、該優先度が最も高い検索対象フィールドは、該第３ステップにおいて求められた該最長プリフィクス長同士の内、最長になった検索対象フィールドである。
図１の場合に、フィールドＦ１の最長プリフィクス長である２０ビットよりも、フィールドＦ２の最長プリフィクス長である２２ビットの方が長いため、優先度が最も高い検索対象フィールドはフィールドＦ２となり、このフィールドＦ２において最長プリフィクス長（２２ビット）を有するエントリ＃４が検索結果として出力される。
このように、エントリの格納順に拘らず、より適切な検索結果を得ることが可能になる。
また、検索開始前に各フィールドに該優先度を設定してもよい。
すなわち、上記の優先度を検索開始前に各フィールドに設定する場合、例えば図１におけるフィールドＦ２の優先度をフィールドＦ１よりも高く設定しておけば、優先度が最も高い検索対象フィールドはフィールドＦ２となり、このフィールドＦ２において最長プリフィクス長（２２ビット）を有するエントリ＃４が検索結果として出力される。
このように、エントリの格納順に拘らず、検索開始前に各フィールドに設定した優先度に基づいた検索結果を得ることが可能になる。
この場合の優先度は、検索を行う度に変更可能であればよい。
すなわち、上記の優先度を固定的に設定するのではなく、検索を行う度に変更できるようにすれば、より柔軟に所望の優先度に基づいた検索結果を得ることが可能になる。
また、上記の優先度として所定の値が設定されたフィールドを検索対象外にしてもよい。
すなわち、フィールドを検索対象外とする所定の値を定めておくことにより、該優先度として所定の値が設定されたフィールドを検索対象外にすることができる。これにより、最終検索結果を判定するためだけでなく、フィールドを検索対象とするか否かの判断材料としても上記の優先度を流用することが出来る。
また、上記の目的を達成するため、本発明に係るデータ検索方法を実現する本発明に係るデータ検索装置は、エントリを複数フィールドに分割して格納したデータベースと、各エントリのフィールド毎のプリフィクス長を保持するプリフィクス長保持部と、全ての検索対象フィールドにおいてエントリの全ての非マスクビットと対応する検索キーのビットデータとが一致するエントリを中間検索結果とし、該プリフィクス長保持部に保持された該中間検索結果の各検索対象フィールドのプリフィクス長から検索対象フィールド毎の最長プリフィクス長を求め、該中間検索結果の内、優先度が最も高い検索対象フィールドにおいて該最長プリフィクス長を有するエントリを検索結果とする演算部と、を備えたことを特徴としている。
上記の優先度が最も高い検索対象フィールドは、該演算部によって求められた該最長プリフィクス長同士の内、最長の検索対象フィールドであってもよい。
また、検索開始前に各フィールドに該優先度を設定してもよく、この場合の優先度は、検索を行う度に変更可能であればよい。
さらに、上記の優先度として所定の値が設定されたフィールドを検索対象外にしてもよい。
【図面の簡単な説明】  図１は、本発明に係るデータ検索方法及び装置の原理を示したブロック図である。
図２は、本発明に係るデータ検索方法及び装置の実施例（１）及び（２）に共通したエントリの状態例を示したブロック図である。
図３は、本発明に係るデータ検索方法及び装置の実施例（１）を示したブロック図である。
図４は、本発明に係るデータ検索方法及び装置の実施例（２）を示したブロック図である。
図５は、本発明に係るデータ検索方法及び装置の実施例（２）の変形例を示したブロック図である。
図６は、一般的なルーティング処理の概要を説明するためのブロック図である。
図７は、図６におけるルータ１０１内のルーティング処理に関連した部分の構成例を示したブロック図である。
図８は、図７におけるＣＡＭデバイス２００の詳細な構成を示したブロック図である。
図９は、一般的なＣＡＭデバイスに用いられるターナリＣＡＭセルの構成例及び検索結果の真理値表を示した図である。
図１０は、一般的なＣＡＭデバイス内部のエントリ構成例及びグローバルマスクパターンを示したブロック図である。
【符号の説明】
2005013566.tif 000003
図中、同一符号は同一又は相当部分を示す。
【発明を実施するための最良の形態】  本発明の実施例として、フィールド毎の最長プリフィクス長同士を比較する場合の実施例（１）と、予めフィールド毎の優先度を設定しておく場合の実施例（２）の２種類について以下に説明する。
まず、上記の実施例（１）及び（２）に共通したエントリ＃１〜＃５の状態を図２に示す。同図は、図１と同様に、データベースに格納されたエントリ＃１〜＃５の各々について、例えば複数のフィールドＦ１及びＦ２を検索対象とする検索キー（図示せず）が入力された際の一致／不一致の状態を模式的に示したものである。
図２には、図１に加え、一致線７１１〜７１５がそれぞれエントリ＃１〜＃５に対応して示されており、エントリ＃１、＃２、及び＃５については、それぞれ一致線７１１、７１２、及び７１５に対して、下向きの矢印で不一致信号が出力されている（例えば、エントリ＃５における不一致信号７１６）。
このように、不一致信号が出力されたエントリ＃１、＃２、及び＃５は、「不一致」であるが、不一致信号が出力されていないエントリ＃３及び＃４は「一致」であるとして中間検索結果が得られる。
実施例（１）
図２の状態において、エントリ＃１〜＃５の格納順に拘らず、検索対象フィールド毎の最長プリフィクス長同士を比較することによって、最終検索結果を得る方法について図３を用いて説明する。
同図に示す如く、エントリ＃１〜＃５の各フィールドＦ１及びＦ２のプリフィクス長を保持するレジスタ８０１及び８０２を設けておく。すなわち、レジスタ８０１には、エントリ＃１〜＃５のフィールドＦ１のプリフィクス長である“２４”、“２４”、“２０”、“１７”、及び“１２”がそれぞれ保持されている。同様に、レジスタ８０２には、エントリ＃１〜＃５のフィールドＦ２のプリフィクス長である“２２”、“１７”、“１７”、“２２”、及び“１６”がそれぞれ保持されている。
なお、上記のレジスタ８０１及び８０２に対する各エントリ＃１〜＃５のプリフィクス長の値は検索運用時前に予め設定されておく必要があるが、ネットワーク管理者がエントリ作成時にプリフィクス長を入力しておけばよい。或いは、マスクビットに設定された値をＣＡＭデバイス自身がカウントしてレジスタ８０１及び８０２に自動的に入力するようにしてもよい。
同図において、中間検索結果として得られているエントリ＃３及び＃４について、点線矢印８１１〜８１４に示す如く、それぞれレジスタ８０１及び８０２を参照し、フィールドＦ１については、エントリ＃３のプリフィクス長“２０”及びエントリ＃４のプリフィクス長“１７”が得られ、フィールドＦ２については、エントリ＃３のプリフィクス長“１７”及びエントリ＃４のプリフィクス長“２２”が得られる。
これらのプリフィクス長について、点線矢印８１５及び８１６に示す如く各フィールドＦ１及びＦ２において最大値８２１及び８２２を求めると、フィールドＦ１における最大値８２１は、エントリ＃３のプリフィクス長“２０”であり、フィールドＦ２における最大値８２２は、エントリ＃４のプリフィクス長“２２”である。
次に、点線矢印８１７に示す如く各最大値８２１及び８２２同士を比較し、最大の値を求めると、最大値８２２の“２２”であることから、フィールドＦ２を優先し、ＣＡＭ検索結果としては、フィールドＦ２のプリフィクス長が最長となるエントリ＃４が最終検索結果になる。
実施例（２）
図２の状態において、エントリ＃１〜＃５の格納順に拘らず、予めフィールド毎の優先度を設定しておくことによって、最終検索結果を得る方法について図４を用いて説明する。
図４に示したレジスタ９０１及び９０２は、図３に示したレジスタ８０１及び８０２に相当するものであり、実施例（１）の場合と同様に、エントリ＃１〜＃５の各フィールドＦ１及びＦ２のプリフィクス長を保持している。
また、レジスタ９０１及び９０２における最大値９２１及び９２２も、図３に示したレジスタ８０１及び８０２における最大値８２１及び８２２と同様にして求めたものである。
図４は、図３と異なり、フィールドＦ１及びＦ２に対し、それぞれ優先度レジスタ９３１及び９３２が設けられている。なお、優先度レジスタ９３１及び９３２に設定する値は、検索を行なう度に変更可能にしておく。
図示の例では、最高の優先度を示す“１”がフィールドＦ１の優先度レジスタ９３１に設定され、フィールドＦ２の優先度レジスタ９３２には“２”が設定された状態が示されている。
この場合、点線矢印９３３に示すフィールド間の優先度の比較は、優先度レジスタ９３１及び９３２に基づいて行なわれ、より優先度が高いフィールドＦ１において、プリフィクス長が最長となるエントリ＃３が最終検索結果になる。
図５は、実施例（２）の変形例として、優先度レジスタをグローバルマスクパターンとして使用する場合を示したものである。例えば、ｎ＜２５５として、各フィールドＦ１〜Ｆｎに対する優先度レジスタＲ１〜Ｒｎが設けられているものとする。
この場合、非選択を示す優先度である“２５５”が優先度レジスタＲｎに設定されたフィールドＦｎを検索対象から外すことが可能になる。なお、フィールド数がｎとなっているため非選択を表す値はｎより大きくとる必要がある。
以上説明したように、本発明に係るデータ検索方法及び装置によれば、データベースにおいて複数フィールドに分割して格納されたエントリの中から、全ての検索対象フィールドにおいて全ての非マスクビットと、これらに対応する検索キーのビットデータとが一致するエントリを中間検索結果とし、該中間検索結果の各検索対象フィールドのプリフィクス長の中から検索対象フィールド毎の最長プリフィクス長を求め、該中間検索結果の内、優先度が最も高い検索対象フィールドにおいて該最長プリフィクス長を有するエントリを検索結果とするように構成したので、エントリの格納順に拘束されることなく、より適切な検索結果を得ることが可能になる。
【図１】
2005013566.tif 000004
【図２】
2005013566.tif 000005
【図３】
2005013566.tif 000006
【図４】
2005013566.tif 000007
【図５】
2005013566.tif 000008
【図６】
2005013566.tif 000009
【図７】
2005013566.tif 000010
【図８】
2005013566.tif 000011
【図９】
2005013566.tif 000012
【図１０】
2005013566.tif 000013
【国際調査報告】
2005013566.tif 000014
2005013566.tif 000015