JP2005192220A - 通信プロトコルの並列処理の方法および装置 - Google Patents

Abstract

【課題】通信プロトコルの並列処理の方法および装置を提供する。
【解決手段】本発明は、通信プロトコルの並列処理の方法および装置に関する。より詳細には、本発明は、データ・パケットの処理に用いられる通信プロトコルを並列に処理するために有限状態機械（ＦＳＭ）を実装することに関する。有限状態機械を並列実装すると、従来型の蓄積転送技術を用いることなく、迅速かつ効率的なデータ処理が可能になる。
【選択図】図１

Description

本発明は、通信プロトコルの並列処理の方法および装置に関する。より詳細には、本発明は、通信データ・パケットの処理に用いられる通信プロトコルを並列に処理するために、ワイヤード・ロジック・デバイスを有限状態機械（ＦＳＭ）の形で実装することに関する。有限状態機械（ＦＳＭ）を並列実装すると、従来型のソフトウェア・スタックや蓄積転送技術を用いることなく、迅速かつ効率的なデータ処理が可能になる。

本発明は、特に通信プロトコルの処理技術を対象としているため、特定の例を参照して説明するが、本発明が他の分野や用途でも有用であろうことは理解されよう。たとえば、本発明は、通信プロトコルをベースとする任意の製品と組み合わせて実装できる。

背景として、従来のプロトコル処理技術は、プロトコル内容の処理および生成のために高度に最適化された命令セットを用いて、種々のソフトウェア・スタック（広く用いられている蓄積プログラム制御メカニズム）をシングルスレッド・プロセッサやマルチスレッド・プロセッサやネットワーク・プロセッサに適用する。通常は、プロトコル層を順々に処理するために別々のプログラムを用いる。プロトコル層と処理の間でのメッセージのキューイング、蓄積、転送、時刻指定、およびスケジューリングには、オペレーティング・システムまたはオペレーティング・システム構造を用いる。プロトコル処理は、メッセージ全体を受け取ってから行う。つまり、蓄積転送である。

これまで知られていた、通信プロトコル処理のソフトウェアベースの実装では、プロトコルの状態変化をソフトウェアでエミュレートする。これにより、システムはより複雑になる。さらに、いつでも実行可能なのはシングル・スレッドのデータだけである。したがって、回線レートより著しく低いレートでプロトコル層を（一度に１つずつ）処理するためには、中間の構造、キュー、およびソフトウェアが必要である。通常、１つのパケットの中には、様々なプロトコル層が存在する。たとえば、パケット・データには、ＲＴＰ（リアルタイム転送プロトコル）データ、ＵＤＰ（ユーザ・データグラム・プロトコル）データ、ＩＰ（インターネット・プロトコル）データ、ＩＣＭＰ（インターネット制御メッセージ・プロトコル）データ、ＩＰＣＰ（インターネット・プロトコル制御プロトコル）データ、ＬＣＰ（リンク制御プロトコル）データ、ＨＤＬＣ（高レベル・データ・リンク制御）データなどを含めることができる。ソフトウェアを用いる場合はさらに、多数のソフトウェア層（たとえば、オペレーティング・システムやアプリケーション・プログラムなど）が必要であり、そのような層は、様々な分野や領域の多数の開発者に対応するためにさらに多くの通信技術を必要とする。また、ソフトウェアベースのシステムでは、データの保全性は事後評価のみ可能である。さらに、ソフトウェア・システムでは、ハードウェアとソフトウェアの多彩な連係が必要である。最後に、ソフトウェア・システムを用いるためには、ハードウェアとソフトウェアの堅固な結合が必要であり、これによって、プロトコル層の処理に必要なオーバーヘッドが増える。

このように、ソフトウェアベースのプロトコル層処理技術は、かなり高度な反面、複雑であり、比較的効率がよくない。これは、特定のシステムを改良するためにソフトウェアを実装する（たとえば、ソフトウェアを何層も積み重ねる）ことに重点をおいた結果である。歴史的には、コンピュータベースのシステムは、ハードウェアをソフトウェアで制御することによって、高い費用対効果で実現されていた。ソフトウェアの制御により、ハードウェアはより柔軟になる。ハードウェアをサポートするためにソフトウェア層の上にソフトウェア層を構築するというアプローチの動機付けになったのは、ハードウェアが本質的に固定されたものであるという事実である。すなわち、ハードウェアの機能は、プロセッサ、メモリ、および固定機能の半導体素子に組み込まれている。さらに、ハードウェアは相対的に（特にソフトウェアと比較して）費用がかかりがちである。このため、費用と柔軟性の観点から、どのようなシステムでも柔軟な制御機構としてソフトウェアを用いることの方が容易なものとなった。

その結果、プログラミング言語の普及によって生産性が向上した。各言語は、特定の状況での問題を解決して特定問題領域での生産性を向上させるように特化された。その結果、ソフトウェアの方言のサブセットが出現した。さらなる著しい性能向上が、トランスレータ、コンパイラ、および開発環境を用いることで実現された。この、ソフトウェアを用いてハードウェアの柔軟性を高め、コンピュータベース技術の性能を向上させるというアプローチの結果として、１２，０００を超えるソフトウェア開発言語および環境が生まれている。

逆に、ハードウェア・ロジックのほうは、ここ数年、ほとんど無視されている。ハードウェア・ロジック・デバイスは、以前から、小さく、高価であり、実用的なキャプチャ言語でプログラミングするのが困難であった。ここ数年の間に進化してきたソフトウェア開発とは対照的に、ハードウェア・ロジックに使用できるキャプチャ言語は１２を下回る。

しかしながら、近年、ハードウェア（ワイヤード）・ロジックを活かす技術として、ＦＰＧＡ（フィールド・プログラマブル・ゲートアレイ）が登場している。ＦＰＧＡは、既知のキャプチャ言語とともに、これらの技術が実装される用途に向けて、格段にシンプルかつ高効率の処理環境を提供できる。さらにＦＰＧＡは、近年いよいよ費用対効果が高まりつつある。同様に、ＡＳＩＣ（特定用途向け集積回路）も、従来のアプローチに向けてのより経済的な選択肢として進化している。

そこで、通信プロトコルを処理するために現在用いられている非効率的な技術に代わるものとして、ワイヤード・ハードウェア・ロジックを利用する通信プロトコル用並列処理システムを実装することが求められている。
本発明は、上述した問題や他の問題を解決する、通信プロトコルの並列処理のための改良された新しいシステムを企図するものである。
米国出願第０９／９７５，１１３号 米国公開第２００３／０１９６１９４ Ａ１号

通信プロトコルの並列処理の方法および装置を提供する。

本発明の一態様では、本装置は、インターフェース・モジュールと、少なくとも１つの第１の有限状態機械の集合と、第２の有限状態機械の集合とを備える。インターフェース・モジュールは、パケット・データを受信するよう動作する。第１の有限状態機械の集合の各集合は、パケット・データの複数の通信プロトコル層のうちの選択された層を処理し、処理結果に基づいて出力データを生成するよう動作する。第２の有限状態機械の集合は、パケット・データを蓄積し、出力データを処理するよう動作する。複数の第１の有限状態機械の集合と、第２の有限状態機械の集合は、並列に動作し、それによって、パケット・データの複数のプロトコル層が回線レートで処理される。

本発明の別の態様では、少なくとも１つの第１の有限状態機械の集合と、第２の有限状態機械の集合は、ＦＰＧＡ（フィールド・プログラマブル・ゲートアレイ）で形成される。

本発明の別の態様では、複数の通信プロトコル層として、ＩＰ（インターネット・プロトコル）層、ＩＣＭＰ（インターネット制御メッセージ・プロトコル）層、ＲＴＰ（リアルタイム転送プロトコル）層、ＵＤＰ（ユーザ・データグラム・プロトコル）層、ＩＰＣＰ（インターネット・プロトコル制御プロトコル）層、ＬＣＰ（リンク制御プロトコル）層、ＨＤＬＣ（高レベル・データ・リンク制御プロトコル）層などがある。

本発明の別の態様では、本装置は、パケット・データを受信するよう動作するインターフェース・モジュールと、第１のプロトコル層データを処理するよう動作する第１のワイヤード・ロジック・デバイスと、第２のプロトコル層データを処理するよう動作する第２のワイヤード・ロジック・デバイスと、第３のプロトコル層データを処理するよう動作する第３のワイヤード・ロジック・デバイスと、第４のプロトコル層データを処理するよう動作する第４のワイヤード・ロジック・デバイスと、パケット・データを蓄積し、第１、第２、第３、および第４のワイヤード・ロジック・デバイスからのデータ出力を処理するよう動作する第５のワイヤード・ロジック・デバイスとを備える。第１、第２、第３、第４、および第５のワイヤード・ロジック・デバイスは並列に動作し、それによって、パケット・データの複数のプロトコル層が回線レートで処理される。

本発明の別の態様では、本方法は、パケット・データを受信するステップ、及びパケット・データの各層を、ワイヤード・ロジックを用いて並列に、回線レートで処理するステップを含む。

本発明の別の態様では、本装置は、パケット・データを受信する手段と、パケット・データの各層を、ワイヤード・ロジックを用いて並列に、回線レートで処理する手段とを備える。

本発明のさらなる応用範囲については、以下の詳細な説明から明らかになるであろう。ただし、以下の詳細な説明および具体例は、本発明の好ましい実施形態を示すものであるが、あくまで例示的なものであることを理解されたい。当業者であれば、本発明の趣旨および範囲の中で様々な変形や変更が可能であることは明らかだからである。

本発明は、デバイスの種々の部品の構成、配置、および組み合わせと、方法の各工程のかたちで存在する。よって、企図した目的は、以下で詳細に記載し、特許請求項で限定的に指摘し、添付図面で例示するように達成される。

本発明は、通信プロトコルの処理および実装に対する従来のアプローチからの脱却を表すものである。本発明による、この新しいアプローチは、蓄積プログラム制御にまつわるオーバーヘッドや複雑さを一掃する。そのために、本発明の実施形態では、Ｎ個の並列ワイヤード・ロジック・リソースを、有限状態機械（ＦＳＭ）または有限状態機械の集合の形で用いる。これらのＦＳＭデバイスは、プロトコル・データを受信したときに（つまり、蓄積する前に）、プロトコル層（またはプロトコル層のフラグメント）を回線において、回線レートで処理するよう機能を特化される。これらのＦＳＭを、プロトコル内容の認識、解析、時間指定、変換、ログ記録、蓄積、転送、および生成を行うために、ワイヤード・ロジックで実装する。

後で詳述するように、有限状態機械（ＦＳＭ）は、ＦＰＧＡ（フィールド・プログラマブル・ゲートアレイ）を用いて実装するのが好ましい。ただし、適切なワイヤード・ロジック・デバイスであれば何でも使用できる。たとえば、状況によっては、ＡＳＩＣデバイスを使用できる。

本発明のシステムを実装すると、様々な点で性能が向上する。第１に、有限状態機械（ＦＳＭ）のエミュレーションが不要になる。少なくとも１つの実施形態で有限状態機械（ＦＳＭ）を実際に使用するので、変換を必要とせずにプロトコルが実行される。第２に、本発明のシステムでは、複数のスレッドを回線レートで実行することが可能になる。これにより、中間の構造、キューイング、およびソフトウェア制御が不要になるか、必要性が著しく低くなる。第３に、ハードウェア・ワイヤード・ロジックを用いることで、より統一された処理にすることができる。第４に、インライン・チェッカを用いることで、保全性を回線レートで、かつリアルタイムに維持できる。第５に、ハードウェア・ワイヤード・ロジックを用いることで、必要な調整およびテストの費用が現在より少なくなる。最後に、オーバーヘッドが最小化される。

以下、例示的実施態様により、本発明を説明する。ワイヤード・ロジックを利用しやすい環境を選択する限り、本発明の実装に適する他の様々な環境が存在することを理解されたい。本発明の全体を通しての目的は、そのようなすべての実装において同じである。すなわち、ワイヤード・ロジック・デバイスを実装することによってソフトウェア・スタックの量を減らし、複数の異なるプロトコル層を並列処理することによって効率を高めることである。

以下、図面を参照していく（これらの図面は本発明の好ましい実施形態を例示する目的でのみ提示するものであり、同じものに限定することを目的としていない）。図１は、本発明を実装できるネットワークを表したものである。図に示すように、ネットワーク全体１０は、光インターフェース・ユニット１４および１６を介して通信するＩＰ（インターネット・プロトコル）バックボーン・ネットワーク１２を含んでいる。図に示すように、ＩＰバックボーン・ネットワーク１２と光インターフェース・ユニット１４との間にルータ１８を設け、ＩＰバックボーン・ネットワーク１２と光インターフェース・ユニット１６との間にＡＤＭ（アド／ドロップ・マルチプレクサ）２０を設けている。光インターフェース・ユニット１４および１６は、ＳＳ７シグナリングなどの様々なシグナリング技術の任意のいずれかを用いて互いに通信する。もちろん、様々なネットワーク構成を用いて本発明を実現できることを理解されたい。

本発明は、様々な用途に実装して、本発明の多くの利点を実現することができるが、本発明の一実施態様は、光インターフェース・ユニット１４の中に配置される。当業者であれば理解されるように、光インターフェース・ユニット１４は、ＯＦＩ（光ファシリティ・インターフェース）など様々な回路パックを内蔵する。この特定の実施態様では、ＯＦＩ（光ファシリティ・インターフェース）は、ＦＰＧＡ（フィールド・プログラマブル・ゲートアレイ）が中に実装されたパケットを内蔵する。

図２は、そのようなＦＰＧＡ（フィールド・プログラマブル・ゲートアレイ）５０の一部を示している。図に示すように、この回路は、一連の有限状態機械の集合に接続されたインターフェース・モジュール５２を含む。本発明の教示が実装されるシステムの設計、目的、および構成に応じて、単一の有限状態機械（ＦＳＭ）または複数の有限状態機械（ＦＳＭ）を含むことができるように、有限状態機械（ＦＳＭ）が集合の形で配置されていることを理解されたい。用途に応じて、異なる集合を組み合わせることもできる。１つの通信プロトコル層を処理するために複数の有限状態機械（ＦＳＭ）が集合の形で実装される場合は、個々の有限状態機械（ＦＳＭ）のそれぞれが１つの通信プロトコル層の一部分ずつを処理することを理解されたい。

本発明の一実施形態では、これらの有限状態機械の集合は、ＩＰ（インターネット・プロトコル）オブザーバ５４を形成する第１の有限状態機械（ＦＳＭ）の集合と、ＩＰＣＰ（インターネット・プロトコル制御プロトコル）オブザーバ５６を形成する第２の有限状態機械（ＦＳＭ）の集合と、ＬＣＰ（リンク制御プロトコル）オブザーバ５８を形成する第３の有限状態機械（ＦＳＭ）の集合と、ＨＤＬＣ（高レベル・データ・リンク制御）オブザーバ６０を形成する第４の有限状態機械（ＦＳＭ）の集合と、受信パケット・ローダ６２を形成する第５の有限状態機械（ＦＳＭ）の集合とを含む。さらに表示されている受信パケット・バッファおよび制御ロジック６４は、パケット・ローダからデータを受け取り、そのデータをパケット・ハンドラ６８および６９に転送するよう動作する。受信パケット・バッファおよび制御ロジック６４は、様々な形をとることができ、有限状態機械（ＦＳＭ）ロジックの使用を含むことができる。

この構成では、データを、インターフェース・モジュール５２の内部で、通信ネットワークからパケットの形で受信し、有限状態機械（ＦＳＭ）の集合５４〜６２で処理し、最後に、ＡＴＭ（非同期転送モード）スイッチに関連付けられたスイッチ・ファブリックなどのスイッチ・ファブリックに転送するか、そうでなければ、送信処理モジュール７０に送信することを理解されたい。明確化のために、パケット・データは、特に指定がない限り、データ・コンテンツと制御フィールドの両方を含むことを理解されたい。実際は、場合によって、パケットの中にある通信プロトコルの制御フィールドが、別の通信プロトコルのデータ・コンテンツとして機能することもある。

図に示すように、また、上記で暗に述べたように、回路５０の一部分はパケット・データの送信も処理する。この点においては、パケット・データをスイッチ・ファブリックまたはパケット・ハンドラ６９から取得し、（図では参照要素７０として示されている）様々な送信処理モジュールで処理することが可能である。送信処理モジュール７０には、バッファ、ローダ（たとえば、ローダ６２に近いもの）、制御ロジック、アンローダなど、データ送信に有用な様々な要素を含めることができることを理解されたい。一実施形態では、それらの要素は、有限状態機械や類似のロジック・デバイスの形をとることができる。もちろん、そのような有限状態機械（ＦＳＭ）は、ＦＰＧＡなどを用いて実装できる。処理されたパケット・データは、宛先への送信のために、インターフェース・モジュール５２に転送される。

動作としては、まず、インターフェース・モジュール５２が、データをパケット・データの形で受信する。インターフェース・モジュール５２は、パケット・データ・ネットワークとのインターフェースに必要なハンドシェーク機能を備えており、それによって、実際にパケット・データを受信する。インターフェース・モジュール５２は、受信したパケット・データに対し、特定の処理機能を実行する。たとえば、インターフェース・モジュール５２は、パケット・データが存在することを確認し、そのパケット・データが有効かどうかを判別する。インターフェース・モジュール５２はさらに、パケットの開始、パケットの終了、パケット・データの転送にエラーがないかどうか、および特定タイプのデータ（つまり、モジュロ２のデータ）を受信したかどうかを判別する。インターフェース・モジュールは、これらの予備判別を実施した後、独自の出力信号を、有限状態機械（ＦＳＭ）の集合５４〜６２への入力信号として供給する。

図３では、以下に述べるインターフェース・モジュールの各出力信号を、時間ｔを基準として示している。まず、受信データ信号（ｒｄａｔ）８０が示されている。この信号は、受信パケット・データからの入力信号として供給される。また、有効性信号（ｒｖａｌ）８２も示されている。信号値「１」は、パケット・データが有効であることを意味する。また、パケット信号の開始（ｒｓｏｐ）８４も示されている。信号値「１」は、任意の時刻ｔにおけるパケットの開始を示す。同様に、パケット信号の終了（ｒｅｏｐ）８６も示されている。特定の時刻ｔにおける信号値「１」は、パケットの終了を示す。特殊なタイプのデータ信号（ｒｍｏｄ）８８は、モジュロ２のデータが、たとえば、受信されたかどうかを示す。最後に、エラー信号（ｒｅｒｒ）９０が示されている。信号値「１」は、受信したパケットの転送においてエラーが発生したことを意味する。

注目すべきは、これらのインターフェース信号が、実際のパケット・データとともに、有限状態機械（ＦＳＭ）の集合５４〜６２に、並列に供給されることである。この実施形態では、パケット・データは有限状態機械（ＦＳＭ）の集合に１６ビットずつ転送されるのが好ましい。ただし、１６ビットより大きいサイズでも、小さいサイズでも、有限状態機械（ＦＳＭ）の集合がそのような転送サイズのばらつきを吸収するように構成されていれば、転送可能である。有限状態機械（ＦＳＭ）の集合５４〜６２のそれぞれは、それぞれの目的を達成するために、それぞれの方式でパケット・データを処理する。この処理の結果のデータは、パケット・ローダ６２で蓄積され、さらなる処理のために、パケット・データとともに出力される。このシステムの利点は、通信プロトコルの各層を並列に回線レートで処理できることである。この処理には、ソフトウェア・スタック（ソフトウェアの階層）は関与しない。したがって、効率は、これまで認識されていたレベルから格段に向上している。

図４は、ＩＰオブザーバ５４の機能４００を示している。ＩＰオブザーバは、まず、パケット・データを受け取る（４０２）。パケット・データを受け取ったら、そのパケットを観察する（４０４）。この点においては、ＩＰオブザーバ５４は、たとえば、パケット・データ内のＩＰヘッダとＩＰペイロードを検出しようとし、ＨＤＬＣアドレス・データや制御データなど、パケット・データ内の他のデータ・フィールドは無視する。一実施形態では、ＩＰオブザーバはさらに、ＩＣＭＰ（インターネット制御メッセージ・プロトコル）パケット・データ、ＵＤＰ（ユーザ・データグラム・プロトコル）パケット・データ、およびＲＴＰ（リアルタイム転送プロトコル）パケット・データのヘッダ情報とペイロード情報を検出しようとする。次にＩＰオブザーバは、しかるべきヘッダ情報を処理する（４０６）。同様に、対応するペイロードを処理する（４０８）。この情報のすべての処理（すなわち、通信プロトコル層の処理）には、１）パケット・データの認識（識別または解析）、２）パケット・フォーマットとしかるべきパラメータの検査、３）選択した情報（パケット・エラー、イベント、統計など）のログ記録、４）パケットの到着および送信の時刻の監視、５）プロトコルの状態およびコンテキストの遷移の実施、６）応答またはパケット・データ（コンテンツあり）の生成が含まれることを理解されたい。通信プロトコル層の処理により、パケットをさらに転送するか、処理またはドロップするかの決定が下される。通常、パケット・データの処理は、適用可能な標準および業界の同意に照らして行われることをさらに理解されたい。たとえば、処理の特定の態様（検査など）には、特定の受信値が既知または想定内かどうかの判別を、適用可能な標準または同意に基づいて行うことが含まれる。最後に、処理したデータを出力する（４１０）。この出力データは、いずれかのデータ型が認識されたかどうかの判別と、処理に関して上記で示したように、他のステータス照会（たとえば、データの各部分が有効かどうか）を含むことが好ましい。

ＩＰオブザーバは、ＩＰ（インターネット・プロトコル）データの処理だけを行うように構成することも可能であることを理解されたい。この場合、他の有限状態機械（ＦＳＭ）は、ＩＣＭＰ（インターネット制御メッセージ・プロトコル）パケット・データ、ＵＤＰ（ユーザ・データグラム・プロトコル）パケット・データ、およびＲＴＰ（リアルタイム転送プロトコル）パケット・データを処理するように実装される。これらの機械の構成は、もちろん、ＩＰオブザーバ５４の構成と同様になる。

同様に、ＩＰＣＰオブザーバ５６は、その固有の目的に従ってパケット・データを処理する。図５に示すように、ＩＰＣＰオブザーバ５６は、まず、パケット・データを受け取る（５０２）。次に、パケットを観察する（５０４）。もちろん、この観察には、ＩＰＣＰ（インターネット・プロトコル制御プロトコル）データ（ＩＰＣＰコードやパケット長など）の存在を確認することが含まれる。注目すべきは、ＨＤＬＣ（高レベル・データ・リンク制御）アドレス・フィールドと他の制御データ・フィールドが無視されることである。次に、ＩＰＣＰデータを処理する（５０６）。ここでも同様に、この情報の処理（すなわち、ＩＰＣＰ通信プロトコル層の処理）には、１）パケット・データの認識（識別または解析）、２）パケット・フォーマットとしかるべきパラメータの検査、３）選択した情報（パケット・エラー、イベント、統計など）のログ記録、４）パケットの到着および送信の時刻の監視、５）プロトコルの状態およびコンテキストの遷移の実施、６）応答またはパケット・データ（コンテンツあり）の生成が含まれることを理解されたい。通信プロトコル層の処理により、パケットをさらに転送するか、処理またはドロップするかの決定が下される。通常、パケット・データの処理は、適用可能な標準および業界の同意に照らして行われることをさらに理解されたい。たとえば、処理の特定の態様（検査など）には、特定の受信値が既知または想定内かどうかの判別を、適用可能な標準または同意に基づいて行うことが含まれる。処理を終了したら、データを出力する（５０８）。出力データは、たとえば、ＩＰＣＰパケットが観察されたかどうかの表示を含むことが好ましい。出力データはさらに、パケット長データが不良か、コードがサポートされていないか、データ型がサポートされていないかの理由でパケットをドロップするかどうかの表示を含む場合がある。出力データは、もちろん、処理内容に基づく。

同様かつ同時に、図６に示すように、ＬＣＰオブザーバ５８は、まず、パケット・データを受け取る（６０２）。次に、そのパケット・データを観察する（６０４）。ここでも同様に、この観察は、ＬＣＰ（リンク制御プロトコル）パケット・コードが存在することの確認を含む。他のデータ・フィールド（ＨＤＬＣ（高レベル・データ・リンク制御）アドレス・フィールドや制御フィールド）は無視される。次にＬＣＰオブザーバは、検出したＬＣＰ（リンク制御プロトコル）パケット・データを処理する（６０６）。ここでも同様に、この情報の処理（すなわち、ＬＣＰ通信プロトコル層の処理）には、１）パケット・データの認識（識別または解析）、２）パケット・フォーマットとしかるべきパラメータの検査、３）選択した情報（パケット・エラー、イベント、統計など）のログ記録、４）パケットの到着および送信の時刻の監視、５）プロトコルの状態およびコンテキストの遷移の実施、６）応答またはパケット・データ（コンテンツあり）の生成が含まれることを理解されたい。通信プロトコル層の処理により、パケットをさらに転送するか、処理またはドロップするかの決定が下される。通常、パケット・データの処理は、適用可能な標準および業界の同意に照らして行われることをさらに理解されたい。たとえば、処理の特定の態様（検査など）には、特定の受信値が既知または想定内かどうかの判別を、適用可能な標準または同意に基づいて行うことが含まれる。次に、処理したデータを出力する（６０８）。この出力データは、ＬＣＰパケットを受け取ったかどうかの表示と、他のステータス情報を含むことが好ましい。たとえば、出力データは、いずれかのコード、プロトコル、またはデータ型がサポートされていないかどうかの情報を含むことができる。さらに、無効なデータ長の表示も出力データに含めることができる。ここでも同様に、これらの出力形態は、処理工程に基づく。

ＬＣＰパケット・データとＩＰＣＰパケット・データの両方を処理することが、ＰＰＰ（ポイントツーポイント・プロトコル）の確立に有効であることを理解されたい。この点においては、ＬＣＰデータの処理は、リンク・パラメータのネゴシエートが目的であり、ＩＰＣＰデータの処理は、ＩＰパラメータのネゴシエートが目的である。

図７に示すように、ＨＤＬＣオブザーバ６０は、処理７００を、前述の諸処理と同様かつ同時に実行する。まず、パケット・データを受け取る（７０２）。次に、ＨＤＬＣ（高レベル・データ・リンク制御）アドレス・フィールドと選択された制御フィールドを調べる（７０４）。次に、データに対して、適切なテストを行う（７０６）。テストされるのは、アドレスおよび制御データの有効性である。ここでも同様に、パケット・データの処理は、通常、適用可能な標準および業界の同意に照らして行われることを理解されたい。たとえば、処理の特定の態様（アドレスおよび制御フィールドの検査など）には、特定の受信値が既知または想定内かどうかの判別を、適用可能な標準または同意に基づいて行うことが含まれる。無効なデータがあれば、さらなる処理の必要を示す、しかるべきインジケータが設定される。

すべての有限状態機械が同時に動作しているため、生成されたデータはその近くに蓄積される。この点においては、図８に示すように、パケット・ローダ６２がこの機能８００を実行する。パケット・ローダは、まず、パケット・データを受け取る（８０２）。パケット・ローダは、データを受け取ると、受信パケット・バッファ６４にパケットをロードする（８０４）。パケット・ローダはさらに、ＩＰオブザーバ５４、ＩＰＣＰオブザーバ５６、ＬＣＰオブザーバ５８、およびＨＤＬＣオブザーバ６０から受け取ったパケット・ステータス情報をロードし、１つにまとめる（８０６）。次に、この情報を使用して、さらなる処理をハンドラに指示する。次に、しかるべきデータを出力する（８０８）。

本発明によって実装される有限状態機械（および／または有限状態機械の集合）は、ＦＰＧＡ（フィールド・プログラマブル・ゲートアレイ）として実装されることが好ましいことを理解されたい。当業者であれば、しかるべきキャプチャ言語による、そのようなデバイスのプログラミングの詳細については理解されよう。しかしながら、少なくとも１つの実施形態においては、参照により本明細書に組み込まれている同時係属の、２００１年１０月１１日に出願し（米国出願第０９／９７５，１１３号）、２００３年１０月１６日に公開された（米国公開第２００３／０１９６１９４ Ａ１号）米国特許出願「Ｈａｒｄｗａｒｅ Ｄｅｓｉｇｎ Ｐｒｏｔｏｃｏｌ ａｎｄ Ｓｙｓｔｅｍ」（Ｃｌｉｆｆｏｒｄ Ｒ．Ｊｏｈｎｓ、Ｄａｖｉｄ Ａ．Ｐｉｅｒｃｅら）で開示および説明されている言語を使用するのが有利であろう。さらに、ＦＰＧＡの代替となるものの使用も可能である。そのような代替として、ＡＳＩＣ（特定用途向け集積回路）がある。

有限状態機械をこの回路部分に実装することは、本発明の単なる例示であることを理解されたい。同様の機能性は、通信プロトコルの処理の役割を担う他のネットワーク部分でも、有限状態機械を用いて実装することが可能である。たとえば、ハンドラ６８および６９も同様に、有限状態機械を用いて実装することが可能である。図２に戻ると、ハンドラ６８は、ＲＴＰハンドラ６８ａ、ＩＣＭＰハンドラ６８ｂ、ＩＰＣＰハンドラ６８ｃ、およびＬＣＰハンドラ６８ｄを有するように示されている。同様に、ハンドラ６９は、ＲＴＰハンドラ６９ａ、ＩＣＭＰハンドラ６９ｂ、ＩＰＣＰハンドラ６９ｃ、およびＬＣＰハンドラ６９ｄを有するように示されている。これらのハンドラは、オブザーバ５４〜６０と同様または同等に構成され、運用され、機能する。ただし、これらは、パケット・データを受信のために処理するのではなく（オブザーバ内では受信のために処理する）、パケット・データを送信のために処理する。すなわち、ハンドラ６８は、パケット・データを、スイッチ・ファブリックへの送信のために処理し、ハンドラ６９は、パケット・データを、送信処理回路７０およびインターフェース・モジュール５２を介して送信するために処理する（たとえば、応答パケットなどを生成する）。注目すべきは、両ハンドラとも、要素５４〜６２との関連で前述した同じ技法を用いて、種々の通信プロトコル層を並列に処理するようにパケット・データを処理する点である（パケット送信か、パケット受信かという点が異なる）。ただし、この処理段階にはすべての通信プロトコル層が存在しているわけではないことは理解されよう。たとえば、ＩＰ層は、ハンドラでは処理されない。さらに、ハンドラは、様々な方式で、特定のハンドラで複数の層の処理を合体するよう構成することもできる。たとえば、ハンドラ６８および６９では、ＨＤＬＣ層の処理を他のハンドラ内（つまり、ＲＴＰ、ＩＣＭＰ、ＩＰＣＰ、またはＬＣＰハンドラ内）で行う。

回路内の様々な場所や他の環境での本発明のあらゆる実施態様において、目的はほぼ同じである。すなわち、様々なプロトコル層を並列に、ほんの数クロック・サイクル以内で処理することにより、処理の効率と連続性を高めることができる。処理は回線レートで行うことができ、通信プロトコルを処理するために多数のソフトウェア層を実装した状況で用いていた従来型の蓄積転送アプローチを用いずにすむ。
以上の説明は、単に、本発明の特定の実施形態を開示するものであり、それらの実施形態と同じに限定することを意図したものではない。したがって、本発明は、前述の実施形態のみには限定されない。むしろ、当業者であれば、本発明の範囲内で代替の実施形態を考案することが可能であろうことが認識される。

本発明を組み込むことができるネットワークを示す図である。 本発明の実施態様を示す図である。 パケット・インターフェースの信号方式を、本発明の一実施形態との関係で示す図である。 本発明に従う実施形態を示すフローチャートである。 本発明に従う実施形態を示すフローチャートである。 本発明に従う実施形態を示すフローチャートである。 本発明に従う実施形態を示すフローチャートである。 本発明に従う実施形態を示すフローチャートである。

Claims (10)

1. 複数の通信プロトコル層を有するパケット・データの処理装置であって、
   前記パケット・データを受信するよう動作するインターフェース・モジュール、
   各有限状態機械の集合が、前記パケット・データの前記複数の通信プロトコル層のうちの選択された層を処理し、処理結果に基づく出力データを生成するよう動作する少なくとも１つの第１の有限状態機械の集合、及び
   前記パケット・データを蓄積し、前記出力データを処理するよう動作する第２の有限状態機械の集合からなり、
   前記少なくとも１つの第１の有限状態機械の集合と前記第２の有限状態機械の集合が並列に動作し、これによって、前記パケット・データの前記複数のプロトコル層が回線レートで処理される装置。
2. 請求項１に記載の装置であって、前記少なくとも１つの第１の有限状態機械の集合と前記第２の有限状態機械の集合がフィールド・プログラマブル・ゲートアレイで形成される装置。
3. 請求項１に記載の装置であって、前記少なくとも１つの第１の有限状態機械の集合と前記第２の有限状態機械の集合が特定用途向け集積回路で形成される装置。
4. 請求項１に記載の装置であって、前記複数の通信プロトコル層が、ＩＰ（インターネット・プロトコル）層、ＩＣＭＰ（インターネット制御メッセージ・プロトコル）層、ＲＴＰ（リアルタイム転送プロトコル）層、ＵＤＰ（ユーザ・データグラム・プロトコル）層、ＩＰＣＰ（インターネット・プロトコル制御プロトコル）層、ＬＣＰ（リンク制御プロトコル）層、およびＨＤＬＣ（高レベル・データ・リンク制御プロトコル）層を含む装置。
5. 請求項１に記載の装置であって、前記少なくとも１つの第１の有限状態機械の集合のうちのいずれかがＩＰ（インターネット・プロトコル）データ、ＩＣＭＰ（インターネット制御メッセージ・プロトコル）データ、ＵＤＰ（ユーザ・データグラム・プロトコル）データ、およびＲＴＰ（リアルタイム転送プロトコル）データを処理する装置。
6. 請求項１に記載の装置であって、前記少なくとも１つの第１の有限状態機械の集合のうちのいずれかがＩＰＣＰ（インターネット・プロトコル制御プロトコル）データを処理する装置。
7. 請求項１に記載の装置であって、前記少なくとも１つの第１の有限状態機械の集合のうちのいずれかがＬＣＰ（リンク制御プロトコル）データを処理する装置。
8. 請求項１に記載の装置であって、前記少なくとも１つの第１の有限状態機械の集合のうちのいずれかがＨＤＬＣ（高レベル・データ・リンク制御プロトコル）データを処理する装置。
9. 複数の通信プロトコル層を有するパケット・データの処理装置であって、
   前記パケット・データを受信するよう動作するインターフェース・モジュール、
   第１のプロトコル層データを処理するよう動作する第１のワイヤード・ロジック・デバイス、
   第２のプロトコル層データを処理するよう動作する第２のワイヤード・ロジック・デバイス、
   第３のプロトコル層データを処理するよう動作する第３のワイヤード・ロジック・デバイス、
   第４のプロトコル層データを処理するよう動作する第４のワイヤード・ロジック・デバイス、及び
   前記パケット・データを蓄積し、前記第１、第２、第３、および第４のワイヤード・ロジック・デバイスから出力されたデータを処理するよう動作する第５のワイヤード・ロジック・デバイスからなり、
   前記第１、第２、第３、第４、および第５のワイヤード・ロジック・デバイスが並列に動作し、これによって、前記パケット・データの前記複数のプロトコル層が回線レートで処理される装置。
10. 複数の通信プロトコル層を有するパケット・データの処理方法であって、
    前記パケット・データを受信するステップ、及び
    ワイヤード・ロジックを用いて前記パケット・データの各層を並列に回線レートで処理するステップ
    からなる方法。
    

Images