JP2009506645A - 高速ネットワークでの再構成可能ビットストリーム処理のための全プロトコルエンジン - Google Patents

Abstract

再構成可能なプロトコルに無関係なビットストリーム処理エンジン、及び関連するシステムとデータ通信方法論が、少なくとも毎秒１０ギガビットの速度で動作する高速ネットワーク間のファブリック間相互作用性を提供するという目標を達成するように適応される。ビットストリーム処理エンジンは、既存の通信プロトコル間で相互作用性を可能にするだけではなく、将来の通信プロトコルを提供する能力も持つシームレスなネットワークファブリックを作成するために、適切なスイッチと関連するネットワーク要素で構成できる全プロトコル多段階プロセッサとして動作する。本発明の方法及びシステムは、ストレージネットワーク、通信ネットワーク及びプロセッサネットワークを含むネットワークに適用できる。
【選択図】 図１Ａ

Description

本発明は、概してネットワークにおけるデータ通信の分野に関する。さらに詳細には、本発明は再構成可能なプロトコルに無関係なビットストリーム処理エンジンに関し、少なくとも毎秒１０ギガビットの速度で動作する高速ネットワークに適応した関連システム及びデータ通信方法論に関する。

（関連出願）
本願は、それぞれの開示が参照することにより本書に組み込まれている、２００５年８月２３日に出願された「高速ネットワークでの再構成可能ビットストリーム処理のための全プロトコルエンジン（Ｏｍｎｉ−Ｐｒｏｔｏｃｏｌ Ｅｎｇｉｎｅ ｆｏｒ Ｒｅｃｏｎｆｉｇｕｒａｂｌｅ Ｂｉｔ−Ｓｔｒｅａｍ Ｐｒｏｃｅｓｓｉｎｇ ｉｎ Ｈｉｇｈ−Ｓｐｅｅｄ Ｎｅｔｗｏｒｋｓ）」と題される米国仮特許出願番号第６０／７１０，５６１号、２００６年１月２３日に出願された「ハードウェア／ソフトウェアにより実現された二重冗長構成のシェルフ管理コントローラ（Ｓｈｅｌｆ Ｍａｎａｇｅｍｅｎｔ Ｃｏｎｔｒｏｌｌｅｒ ｗｉｔｈ Ｈａｒｄｗａｒｅ／Ｓｏｆｔｗａｒｅ Ｉｍｐｌｅｍｅｎｔｅｄ Ｄｕａｌ Ｒｅｄｕｎｄａｎｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）」と題される米国仮特許出願番号第６０／７６１，１２９号、２００６年７月２５日に出願された「高度ＴＣＡベースのパッケージング及びイーサネット（登録商標）スイッチ型ファブリックを有する電気通信プラットホーム及び計算プラットホーム（Ｔｅｌｅｃｏｍｍｕｎｉｃaｔｉｏｎ ａｎｄ Ｃｏｍｐｕｔｉｎｇ Ｐｌａｔｆｏｒｍｓ Ｈａｖｉｎｇ Ａｄｖａｎｃｅｄ ＴＣＡ Ｂａｓｅｄ Ｐａｃｋａｇｉｎｇ ａｎｄ Ｅｔｈｅｒｎｅｔ（登録商標） Ｓｗｉｔｃｈｅｄ Ｆａｂｒｉｃ）」と題される米国仮特許出願番号第６０／８２０，２４３号、及び２００６年８月１１日に出願された「一意ＩＤに基づいて制約を受けた近傍の中での短縮されたデータフレームのために強化されたイーサネット（登録商標）プロトコル（Ｅｎｈａｎｃｅｄ Ｅｔｈｅｒｎｅｔ（登録商標） Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｓｈｏｒｔｅｎｅｄ Ｄａｔａ Ｆｒａｍｅｓ Ｗｉｔｈｉｎ ａ Ｃｏｎｓｔｒａｔｉｎｅｄ Ｎｅｉｇｈｂｏｒｈｏｏｄ ｂａｓｅｄ ｏｎ Ｕｎｉｑｕｅ ＩＤ）」と題される米国仮特許出願番号第６０／８２２，１８１号に対する優先権を主張する。

従来、ネットワークは、既定のネットワークの目的に基づきさまざまな種類のインフラストラクチャまたはファブリックに分けられている。結果として、さまざまな種類のネットワークが、それぞれが異なるプロトコルと異なるネットワーク要件を有し、それぞれがそのファブリック内でのデータ通信のための特定の要件を満たすように設計されている、ストレージネットワーク、通信ネットワーク、及びプロセッサネットワークのために開発されてきた。

プロセッサネットワークのケースでは、ネットワーク性能は高性能クラスタコンピューティング（ＨＰＣＣ）アプリケーションにおける重要な要素である。通常は、ＨＰＣＣアプリケーションは長期間実行し、クライアントとサーバ間だけではなく、プロセッサ間でもネットワーク上で大きなデータセットのＩ／Ｏが持続されることを必要とする。インフラストラクチャが、ハイエンドなクラスタプロセス間通信のための絶対的な要件であるマルチギガビットの帯域幅で、低遅延の非常に高い可用性のサービスをサポートできなければならないのは予想どおりである。従来、ＨＰＣＣネットワークはスイッチ型ギガビットイーサネット（登録商標）を活用する。例えば、ミリネット（Ｍｙｒｉｎｅｔ）、インフィニバンド（ＩｎｆｉｎｉＢａｎｄ）、及びクアドリクス（Ｑｕａｄｒｉｃｓ）等の独自仕様のプロトコルはＨＰＣＣ環境において処理クラスタを接続する上でも幅広く使用されている。

大量のデータに対するニーズは、例えばＨＰＣＣアプリケーションでのネットワーク化されたプロセッサがストレージネットワークファブリックに効率的に接続されることを必要とする。従来、インフラをサポートするＨＰＣＣは、ファイバチャネルスイッチ等のストレージ接続ネットワーク（ＳＡＮ）スイッチングファブリック、またはギガビットイーサネット（登録商標）ベースのネットワーク接続ストレージ（ＮＡＳ）環境のどちらかを含む。ファイバチャネルは、クライアントとストレージデバイスの間での大量のブロックストレージデータの移動に最適化されるマルチギガビット速度とトランスポートプロトコルのためにＳＡＮファブリックにとって優勢なプロトコル及びトランスポートである。

インターネットプロトコル（ＩＰ）通信ネットワークが、より幅広いインターネットファブリック上のクライアントとサーバ間の一般的な通信だけではなく、異なるＨＰＣＣアプリケーション間の通信のためのファブリックも支配する傾向がある。インターネットＳＣＳＩ（ｉＳＣＳＩ）、インターネットファイバチャネルプロトコル（ｉＦＣＰ）、及びファイバーチャネルオーバーＩＰ（ＦＣＩＰ）等のＩＰストレージネットワーク上でブロックストレージデータを移動するのに適したピギーバックプロトコルを採用したストレージネットワークもある。しかしながら、これらのピギーバックプロトコルは、必ずしも通信ネットワークとストレージネットワークの間の直接的な相互作用性を可能にしない。

これらの異なる種類のネットワークファブリック全体でファブリック間相互作用性を提供するという目標は周知の目標である。ネットワーク内で必要とされる処理のすべてが標準的なプログラム可能プロセッサで達成できるであろう低速ネットワークの関連でこの目標を達成することは簡単である可能性があるが、このような解決策は1秒あたり１０ギガビット以上で動作する高速ネットワークに必要とされる高い通信速度では単に実行可能ではない。大部分、ファブリックの特定のプロトコルと中心スイッチノードでの共通プロトコルの間で遷移を行うために特殊化されたアダプタが使用されてきた。この手法はエンドユーザに対してトランスペアレントであるが、このようなアダプタのパッチワークが増え続けるプロトコル数という点で飛躍的に増える問題を呈することは、当業者にとって容易に明らかである。複数のプロトコルを処理できるであろう高速ネットワークスイッチを提供する能力は、少なくともいくつかのネットワーク装置製造メーカが可能ではないと考える解決策である。Ｓｉｌｖａｎｏ Ｇａｉ、「ＬＡＮ／ＷＡＮ／ＷＬＡＮ／ＳＡＮスイッチ及びルータのための統一されたアーキテクチャに向けて（Ｔｏｗａｒｄ ａ ｕｎｉｆｉｅｄ ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ＬＡＮ／ＷＡＮ／ＷＬＡＮ／ＳＡＮ ｓｗｉｔｃｈｅｓ ａｎｄ ｒｏｕｔｅｒｓ）」、２３ページ、ＨＳＰＲ２００３、シスコシステムズ社（Ｃｉｓｃｏ Ｓｙｓｔｅｍｓ，Ｉｎｃ．）（毎秒１０Ｇｂの安価なＬＡＮスイッチの非可用性を留意する）。したがって、ネットワーク間のファブリック間相互作用性を提供するという目標に対する、高速ネットワークにとって効率的であるだけではなく、スケーラブルでもある解決策を発見するニーズがある。

本発明は再構成可能なプロトコルに無関係なビットストリーム処理エンジン、及び少なくとも毎秒１０ギガビットの速度で動作する高速ネットワークの間のファブリック間相互作用性を提供するという目標を達成するために適応した関連システムとデータ通信方法論を提供する。ビットストリーム処理エンジンは、既存の通信プロトコル間だけではなく、将来の通信プロトコルに対処する能力も備えて、相互作用性を可能にするシームレスネットワークファブリックを作り出すために適切なスイッチと関連ネットワーク要素で構成できる全プロトコル多段プロセッサとして動作する。本発明の方法及びシステムはストレージネットワーク、通信ネットワーク及びプロセッサネットワークを含むネットワークに適用可能である。

本発明の一実施形態では、全プロトコル処理エンジンは、各部が少なくとも１つのビットストリーム段階プロセッサを有する進入部分と退出部分の両方を含むデータフロー処理エンジンとして動作する。好ましくは、各段階プロセッサは、データフローにおける特定の段階のために最適化される。データの流れが処理エンジンを通って移動するので、異なる処理がアセンブリラインの異なる段階として達成され、処理のすべてがデータの流れに合わせて調節されるという点で、データフロー処理エンジンは、概念上、かなり生産アセンブリラインのように機能する。処理エンジンを通過するデータの流れは、処理エンジンが接続されるネットワーク（複数の場合がある）の回線速度での処理エンジンの継続動作を可能にする速度で確立される。本実施形態で活用されるデータフローモデルは、従来のプロトコルプロセッサで必要となるであろうようなデータを追跡調査するために深く広範囲なバッファ管理に対するニーズを回避する。さらに、任意の段階でのエンジンは、スケーラビリティをサポートするために本来カスケード可能である。

全プロトコル処理エンジン（ＯＰＥ）の一実施形態では、複数の段階は、少なくとも１つの進入段階ビットストリームプロセッサと、二次段階状態機械と、トラフィックプロセッサと、スケジューラと、退出段階ビットストリームプロセッサとを含む。進入段階ビットストリームプロセッサはデータフローの物理層と接続し、ビットストリームのために決定されたプロトコルに従ってビットストリームのためのフレーム及び／またはフローを確立する。二次段階状態機械は、好ましくはキー生成をパイプライン化する、プログラム可能な超長命令語（ＶＬＩＷ）フロー分類子を使用して、決定されたプロトコルに従ってフレーム／フローを構文解析する。フレーム／フロー処理はトラフィックプロセッサによって処理される。スケジューラはトラフィックプロセッサからのデータフロー出力を管理し、進入段階ビットストリームプロセッサは全プロトコル処理エンジンの中からデータフローの物理層と接続する。段階のすべては、ＯＰＥがプロトコル無関係となることができるように、動的に再構成可能且つプログラム可能である。

一実施形態では、二次段階状態機械とトラフィックプロセッサは、ＯＰＥの効率を改善するために新規のキールックアップ機構を活用する。トラフィックプロセッサは、トラフィックプロセッサ内のセグメントがフレーム／フローの既定のプロトコルに応じて実現される、複数セグメント化データフロープロセッサ機構として実現できる。トラフィックプロセッサの実施形態では、複数セグメント化データフロープロセッサは、フレーム／フローのデータフローが常駐する共通の共有バッファメモリにアクセスすることに対する仲裁された、及び／または時分割多重化（ＴＤＭ）の手法を実現する。このようにして、各データフロープロセッサがフレーム／フロー内のデータのいくらかまたはすべてを、そのデータを処理するためにそのプロセッサ内の内部バッファの中にコピーする必要はない。さらに、データフロープロセッサはカスケード可能であり、段階抽象化とクロック抽象化の両方の結果として拡張可能である。

本発明の一実施形態では、全プロトコル４８ポート非ブロック化ＱｏＳギガビットスイッチは、ＳＰＩ４．２デジタルスイッチと接続される４台のＯＰＥを使用して実現される。本実施形態では、各ＯＰＥは、ＳＰＩ４．２デジタルスイッチへの接続のために、外部接続用に１２のシリアライザ／デシリアライザ（ＳｅｒＤｅｓ）ポートと、３つのＳＰＩ４．２ポートに接続される。ストレージネットワーク、ＨＰＣＣプロセッサクラスタ、イントラネット、及びインターネット通信ネットワークの真中に設置されるとき、このようなスイッチはこれらのネットワークのどれかまたはすべての中でプロトコルに無関係なネットワーク接続を可能にする収束ファブリックとして効率的に動作する。本発明のこの実施形態は、スイッチが再構成可能であるだけではなくオンザフライでプログラム可能であり、各パケットを、「ポートプロセッサ」を備える瞬時にプログラミングし直される／再構成可能なＯＰＥ、つまり中心的なスイッチング構造を形成するデジタルスイッチに従って違う風に（つまり例えば、毎秒１０ギガビットで１００％のパケットバイパケットルーティング）処理できるようにするという点で、インテリジェントスイッチング解決策を提供する。このようにして、スイッチング解決策は、数千のノードにスケーラブルであり、既存のネットワークインフラストラクチャと相互作用し、電話会社に信頼性／フォルトトレランス（つまり、５つの９の可用性）を費用効果が高い方法で提供する、高性能（＞＝ポート帯域幅あたり毎秒１０ギガビット）で低遅延（＜５ｕｓｅｃスイッチング）の、プロトコルに無関係なポリシーをベースにしたスイッチングを提供する。

本発明の別の実施形態では、ＯＰＥと関連付けられたネットワーク要素は、システムのための診断と保守だけではなく、符号生成、フロー制御、性能プロファイリングと統計も管理するＧＵＩ管理システムとともに、レジスタアクセス制御（ＲＡＣ）及びサブモジュールアクセス制御（ＳＡＣ）装置を使用して、すべて動的に再構成可能であり、プログラム可能である。特定の実施形態では、ＧＵＩ管理システムはシステムを仮想設計するためのモジュールと、「ウィジウィグ」（ＷＹＳＩＷＹＧ）様式で設計されたとおりのアーキテクチャの予想性能をシミュレーションできるシミュレーションエンジンと、必要とされる場合、ＯＰＥと他の再プログラム可能／再構成可能なネットワークデバイスをプログラムし直すためのマイクロコードを生成する符号生成部（マイクロコードマネージャ）を含む。

本発明はネットワークにおけるワイヤスピードデータ経路処理のための新規の装置、システム及び方法を備える。図１Ａは、本発明によるシステムの一実施形態のブロック図を描く。本実施形態にとって中心にあるのは、全プロトコルエンジン（ＯＰＥ）である。ＯＰＥは、１）ビットストリーム中のビットを、関連するプロトコルに従って適切な定義されたプロトコルデータユニットにアセンブルする機能性と、２）遭遇するプロトコルに関わらず、アセンブルされたプロトコルデータユニットを処理し、ワイヤスピードスループットを提供する機能性という二重機能性を含むプロトコルに無関係なビットストリーム多段階プロセッサである。従来の技術で一般的な特殊化されたアダプタとは異なり、ＯＰＥにおけるこれらの機能の両方とも動的にプログラム可能である。したがって、既定のプロトコルまたはプロトコルデータユニットに適用する処理規則に対するプロトコルデータユニットのどちらかまたは両方が動的に変更可能である。

別段に示されない限り、本発明のために、用語プロトコルは制御ビット及び（ヌルであってよい）データビットまたは情報ビットの定義された分類（複数の場合がある）を有する直列化されたパケット通信プロトコルを指し、そのすべてが一式の標準的な命令または規則に従う。表１は、本発明の全プロトコルエンジンの一実施形態の属性のいくつかの概略を示す。

図１Ｂに示されるように、ＯＰＥは、それがいくつかの一意の処理ブロックを備えるという点で多段階プロセッサ機構である。各ブロックは、全プロトコルフロー処理機能のために最適化されている。各処理ブロックは、データ経路に沿ってワイヤスピードでの追加処理のための「ゲート」を提供する。ゲートインタフェースは、処理ブロックの待ち時間要件を満たすために高速パラレルレーンだけではなく、高速シリアルＩ／Ｏレーンも使用する。各処理ブロックの状態、特長、及び関数パラメータは、説明されるように、好ましくは「オンザフライ」でプログラム可能である。その結果として、ＯＰＥは再プログラム可能であるだけではなく、再構成可能でもある。

図４１を参照すると、基本レベルで、各段階または処理ブロックは、構成成分、つまりデータフローの依存性を改変する成分と制御構造間のデータフロー依存性という点で抽象化できる。最高レベルの抽象化では、各段階は、段階が入力パケットフローオブジェクトを受け入れ、入力パケットフローと処理済みのパケットフローのどちらかまたは両方と関連するメタデータオブジェクトだけではなく、処理済みのパケットフローオブジェクトを出力できるようにするために制御構造を実現するジェネリックインタフェースを実現する。各段階は、ベースクラスのメンバーである。各ベースクラスは、それがベースクラスのために実現するメソッドのセットによって指定されるインタフェースを実現する。抽象化の中間レベルでは、各ベースクラスは、ベースクラスの機能性を拡張し、サブクラスを形成する追加モジュールを追加することによって拡張されてよい。各サブクラスは、ベースクラスメソッドの機能性を拡張する追加のメソッドを提供する専用のサブクラスインタフェースを実現する。抽象化の最低レベルでは、サブクラスによって提供されるインタフェースが、ベースクラスに存在しなかった成分を提供するために他のメソッドを提供することによって、及び／またはサブモジュールを追加することによってさらに拡張できる。クラスとそのサブクラスは、メソッドと、メソッドが作用するオブジェクトを変更することで再構成可能である。このようにして、ビットストリームプロセッサの各段階は、分化されたリソースとサービスを提供するためにプログラム自在に再構成できる。このようにして、多様な段階は、プロトコルと無関係なアーキテクチャでデータ（パケット）フローマシンに構成される。

フレームはビットのストリームとして定義され、ありとあらゆるビットの意味が１つまたは複数の事前に定義されたプロトコルフレーミング規則によって定義される。抽象化モデルはビットのストリームを入力として受け入れるためのメソッドを有する。ありとあらゆるビットの意味は、各段階がビットのストリームを受け入れることができるように、メソッドによって抽象化される。プロトコル処理は、ビットストリームの中のどこかに位置する、ビットのストリームの内の１つまたは複数のビットの中の情報に基づくアクションのセットを実行する別のメソッドで定義される。メソッドのような実現できる任意のクラスまたはサブクラスはプロトコル処理ステップを潜在的に実施できる。代替実施形態では、各クラスまたはサブクラスは、クラスまたはサブクラスによって提示されるジェネリックインタフェース内のメソッドを実現することにより特定のプロトコルを処理するようにプログラムできる。インプリメンテーションの詳細は、このようにして、符号または成分の再利用を可能にするために１つまたは複数のメソッドの後に「非表示」にすることができる。抽象化の結果、データフローアーキテクチャは、本来、既定の段階の処理がパケット間のギャップ間隔で、つまり次のパケットが到達する前に完了されるように配置される一連のパイプライン化された、予測可能な待ち時間段階となる。

各段階の抽象化は、１つまたは複数のパイプラインサブ段階の各段階への追加を可能にする。パイプラインの段階の中の各サブ段階は段階の中でサブ段階数で除算されるパケット到着時刻に等しい時間内でパケットに対するその作用を完了する。したがって、第１の段階は、パケット復号のためにメソッドを実現するサブクラスを構成してよい――つまり、それはデータパケットについてのメタデータを作成する。メタデータは入信パケットストリームの中の特定のプロトコルの特殊なビットパターンの位置についての情報を含んでよい。この点で、パケットデコーダはフレーム（定義されたビットのストリーム）を「分析する」。用語「実現する」が、本書ではファームウェアとハードウェアの１つまたは複数という点でのインプリメンテーションを意味するために使用されることを留意する。任意のファームウェア、ハードウェア、または前述された基本的な機能を実現するファームウェア−ハードウェアの組み合わせは、前記に参照されたメソッドを実現するために使用されてよい。例えば、パケット復号段階は、比較加速器付きのプログラム可能状態機械として実現されてよい。プロトコルタイプを考慮すると、ＰＳＭは例えばアドレスルックアップのために段階プロセッサによって必要とされるパケット内でフィールドを抽出する。パケットデコーダは、これらの３つの層のヘッダから情報を抽出するために第２層／第３層／第４層の構文解析を実行する。したがって、この機能性を実現するメソッドは、これらの３つの層のプロトコルを処理し、このようにしてベースクラスを拡張するために調整できる。

一実施形態では、データフロー処理エンジンの進入部分と退出部分はそれぞれ、マルチポートデータフローパケットメモリと接続される複数のビットストリーム段階プロセッサを有する。各ビットストリーム段階プロセッサは一意の命令メモリを備える。一実施形態では、第１のスイッチバスが、データフローパケットメモリとファブリックインタフェースとプロセッサインタフェース間で接続され、第２のスイッチバスはデータフローパケットメモリと複数のビットストリーム段階プロセッサの間で接続される。この実施形態では、第３のスイッチバスは複数のビットストリーム段階プロセッサと共通メモリインタフェースの間で接続される。共通メモリインタフェースは、外部メモリと、または内容アドレス可能メモリ（ＣＡＭ）インタフェースと接続できる。

一実施形態では、ＯＰＥは、最も一般的に遭遇するプロトコルに必要とされる共通処理ブロックのセットをサポートする。コンピュータ集約型プロトコル処理のような追加の特長は、独自仕様のプログラム可能多機能処理ブロックを追加することによって実現できる。これらの計算処理ブロックは、ＯＰＥに、収束ネットワークファブリックを達成しようとする従来の技術の試みの特徴である種類のコストまたは性能のペナルティを招くことなく、任意のプロトコル環境で動作するために必要とされる拡張性を与える「オンザフライ」プログラム可能性も備えることができる。事実上ＯＰＥは、マルチプロトコル処理機能、つまり異なる高速プロトコルの間でゲートウェイとスイッチを必要とすることなくコンピューティングセンタの異種成分をマージする能力を提供することにより収束型のファブリックを可能にする。該ＯＰＥ解決策は、ＯＳＩ第２層から第７層に対して機能する。

一実施形態では、ＯＰＥの処理ブロックは、好ましくは、その開示が参照することにより本書に組み込まれている「プログラム可能回路をグラフィックでプログラムするための方法及び装置（Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｇｒａｐｈｉｃａｌｌｙ Ｐｒｏｇｒａｍｍｉｎｇ ａ Ｐｒｏｇｒａｍｍａｂｌｅ Ｃｉｒｃｕｉｔ）」と題される米国特許番号第６，６７１，８６９号に説明されるようなＧＵＩをベースにした符号生成部によってプログラムされる。プロトコルテンプレートが提示され、特殊フィールド上のアクションがアクションバケットにドラッグアンドドロップされ、それによりシステムは通信エンジンコードを生成する。さらに、ＧＵＩは「ウィジウィグ」（ＷＹＳＩＷＹＧ）様式で、エンジンの予想性能を示す。システムは、最大性能を取得するために必要とされるアクションについてユーザにプロンプトを出す。チップ環境では、これらの機能は適切なリンクスピードを選択するために使用される。例えばＦＰＧＡ等のプログラム可能プラットホーム環境では、さらに高容量のチップを選択できる。

図３５Ａ及び図３５Ｂに描かれているようなＧＵＩベースの符号生成部の特殊な実施形態では、プロトコルテンプレートが提示され、特殊なフィールドでのアクションがアクションバケットにドラッグアンドドロップされる。システムは通信エンジンコードを生成し、「ウィジウィグ」（ＷＹＳＩＷＹＧ）様式でエンジンの予想性能を示す。このシステムは、最大性能を取得するために必要とされるアクションについてユーザにプロンプトを出す。チップ環境では、これらの機能は適切なリンクスピードを選択するために使用できるであろう。（前述のＦＰＧＡ例のような）プログラム可能プラットホーム環境では、さらに高容量のチップが選択できるであろう。

「オンザフライ」機能性は、共通のローカルバスを共有する１台または複数の汎用プロセッサ（ＣＰＵ）と関連して、例えばフィールドプログラム可能ゲートアレイによって提供されてよい。１つのこのような手法は、開示が参照することにより本書に組み込まれている「再構成可能なネットワークインタフェースアーキテクチャ（Ｒｅｃｏｎｆｉｇｕｒａｂｌｅ Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ）」と題される米国特許番号第６，７２１，８７２号で開示されている。このような「オンザフライ」機能性を提供するための代替手法は、開示が参照することにより本書に組み込まれている「マイクロプロセッサのローカルバスでのフィールドプログラム可能ゲートアレイによる媒体処理（Ｍｅｄｉａ Ｐｒｏｃｅｓｓｉｎｇ ｗｉｔｈ Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙｓ ｏｎ ａ Ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ’ｓ Ｌｏｃａｌ Ｂｕｓ）」、Ｂｏｖｅ Ｊｒ．ら、ＭＩＴメディアラボ（ＭＩＴ Ｍｅｄｉａ Ｌａｂ）、米国０２１３９マサチューセッツ州ケンブリッジ（Ｃａｍｂｒｉｄｇｅ，ＭＡ ０２３１９ ＵＳＡ）に説明されている。

ここで図２を参照すると、図１に示されているＯＰＥの進入動作の一実施形態が説明される。ポート集約は、ＰＨＹデバイスとＭＡＣデバイスに特有である物理層プロトコルのフレーミングと、媒体に特殊なパケットデータをＳＰＩ４．２バーストフレームに変換することを含む。複数のポートからの小型ＳＰＩ４．２バーストは、ラウンドロビン、時分割多重化様式でＳＰＩ４．２エンジンに渡される。ＳＰＩ４．２チャネルは集約されているポート数に基づいた時間スロットに分けられる。８ポートアグレゲータが、ＳＰＩ４．２チャネルを８個の等しい部分に分ける。アイドルバーストは、非アクティブである、または転送するデータがないポート用スロットのためのバスで生成される。

本実施形態のためのＭＡＣデバイスは、８ｘ１ＧｂＥ ＭＡＣチップ（「ＭＡＣチップ」）である。ＭＡＣチップは、各１ＧｂＥ ＭＡＣからのイーサネット（登録商標）パケットデータの構成可能なバイト数（例えば３２バイト）が、ＳＰＩ−４．２インタフェースへの伝送のために、ラウンドロビン様式（ポート０からポート９）で予定されることを意味する「バーストインタリーブ」モードと呼ばれるものに対して構成される。１ＧｂＥ ＭＡＣからのバーストは、次にＳＰＩ−４．２バスでインタリーブされ、伝送される。小型（Ｒｕｎｔ）バースト（３２バイトより小さいバースト）がパケットデリミタの開始と最後で考えられる。ＭＡＣチップにより実行されるイーサネット（登録商標）パケット上での動作は（１）プリアンブルとフレーム開始デリミタ（ＳＦＤ）を取り除くことと、（２）ＦＣＳを保持することとを含む。

ＳＰＩ４．２エンジンは、好ましくは、ＳＰＩ４．１に類似する内部フレーミングフォーマットにＳＰＩ−４．２フレーミングを変換するＳＰＩ−４．２エンジンの材料機能性を提供するコアを含む。データは１６ビットのバーストでＳＰＩ４．２バスから到着し、バーストの最初の１６ビットワードは、バーストがパケットの始まりであるのか、パケットの最後であるのか、あるいはパケットと、バーストの調達元のチャネル番号の続行であるのかを含むバーストについての情報を含む制御ワードを含む。１６ビットの制御ワードが内部ルーティングタグに変換される一方、チャネルからの最高８個の１６ビットデータワードが、６４ビットのワードにアセンブルされ、渡される。

この実施形態では、内部ルーティングタグは、フレームが転送論理回路を通って移動するにつれてパケットバーストデータとともに内部バスに渡される。内部ルーティングタグはデータ有効のための１ビット、パケットの始まりのための１ビット、パケットの最後のための１ビット、データエラーのための１ビット、バーストサイズのための３ビット（０から７はそれぞれ１から８のバーストサイズを示す）とチャネルアドレスのための３ビットを含む。チャネルアドレスは、バーストが関連付けられているポートを示す。別の実施形態では、内部ルーティングタグが、ネットワーク層優先順位決定またはＶＬＡＮ指定の優先順位に基づくＱＯＳ／ＣＯＳ情報を含んでよい。

フレームプロセッサによるフレーム処理は、ネットワークパケットの興味深い特徴を特定することを必要とする。これらの特徴は、宛先アドレスとソースアドレス、パケットタイプ、第３層と第４層のデータグラムとセッションアドレス指定を含む。加えて、フレームプロセッサは転送論理回路により処理される各パケットのために状態機械を維持する。

図３に示されるように、パケット状態機械は、データスチームの構成を追跡調査する。ＨＰＣ解決策の場合、データストリームは、ＳＰＩ４．２制御ワードのビットフィールドに基づいて分類される、パケットデータの複数のバーストから構成される。パケット状態機械は、ＳＰＩ４．２で受信されるまたはＳＰＩ４．２から送信されるパケットごとにインスタンス化される。ＳＰＩ有効（ＰＡＣＫＥＴ＿ＶＡＬＩＤ）信号がアサートされるとパケットはＶＡＬＩＤ（有効）状態に入る。パケット信号のＳＰＩ開始がアサートされると、パケットはＳＴＡＲＴ＿ＯＦ＿ＰＡＣＫＥＴ状態に入り、パケットのＳＰＩの最後がＥＮＤ＿ＯＦ＿ＰＡＣＫＥＴ状態への遷移を引き起こす。エラーステータスがエラーを示すと、状態機械はＥＲＲＯＲ状態に入り、それ以外の場合状態機械はＩＮＩＴに遷移する。

再び図２を参照すると、構文解析エンジン（パーサ）の責任は、フレームプロセッサによって提供される情報から複数のタプル分類子キーを構築することである。一実施形態では、分類子キーの生成には宛先アドレスだけが必要である。代替実施形態では、ルックアップエンジンは、分類子キーを構築し、このようにしてスイッチが個々のパケットまたはパケットストリームを転送するのにつれてスイッチの動作を修正するときに、任意の数のパケット特徴あるいはパケット状態／ポート状態も含むように機能強化されてよい。

パーサによって生成される分類子キーを使用して、ルックアップエンジンは退出宛先ポートを発見するために転送ＣＡＭに変換する。退出宛先ポートは内部ルーティングヘッダの中に入れられる。一実施形態では、内部ルーティングヘッダは、完全に進入ポート番号だけで構成される。代わりに、内部ルーティングヘッダは追加情報を含むことができる。転送ＣＡＭエントリは、ＳＮＭＰベースの管理ステ−ション等の管理エンティティにアクセス可能となる。

トラフィックディレクタは、内部ルーティングヘッダで検出されるポートアドレスに基づいてＣＰＵにフレームを転送する、及び／または対処することに関与する。適切なインタフェース論理が、転送論理回路とＦＰＧＡ内のマイクロプロセッサの間で提供される。

スイッチファブリックとポートカードのフレーム処理論理回路の間でのデータの流れを処理することは待ち行列エンジンの責任である。待ち行列エンジンは、仮想待ち行列につながる８ポートカードスイッチで、スイッチファブリックの中の１ＧｂＥ ＭＡＣごとに仮想待ち行列を含む。各仮想待ち行列は複数のジャンボ（９Ｋ）パケットを保持するほど十分に大きい。各仮想待ち行列のためのインデックスは、仮想待ち行列の中のどこに次の６４ビットのデータが格納されるのかを追跡調査するために維持され、そのインデックスはＶＱエンキューインデックスと呼ばれる。ＶＱデキューは、スケジューラに渡される必要のあるデータの次の６４ビットを決定するために調べられる。したがって、トラフィックディレクタからのデータは、ＶＱエンキューインデックスによって示されるオフセット時に、宛先ポートのＶＱの中に格納される。逆に、ＶＱデキューインデックスは、どのデータがスケジューラに渡されるのかを決定するために使用される。また待ち行列エンジンは、スイッチファブリックと仮想待ち行列の間に速度変更ＦＩＦＯを、スイッチファブリックと転送論理回路の間の背圧を提示するフロー制御機構も提供する。

スケジューラは、スイッチファブリックにフレームを渡すときに待ち行列エンジンのデキュー機構を使用する。フレームはポート０からポート３１までラウンドロビン様式でスイッチファブリックに渡されるために予定される。デキューは、ＸＡＵＩコアがフレームをＸＡＵＩに変換する前にＸＧＭＩＩでフレームをカプセル化することを含む。内部ルーティングタグと内部ルーティングヘッダは変換の間使用される。

ここで図３を参照すると、ＯＰＥの進入動作の一実施形態が説明される。待ち行列エンジンは、進入の逆である退出側で待ち行列を提供する。スイッチファブリックからのＸＡＵＩフレームは、ＸＡＵＩコアによってＸＧＭＩＩに変換される。ＸＧＭＩＩフレームはＸＧＭＩＩフレーム内のポート番号に基づいて仮想待ち行列に待ち行列化される。

スケジューラは、進入とほぼ同じ様式で退出スケジューリングを達成する。フレームはラウンドロビン様式で待機解除されるが、退出データフレームがローカルバスインタフェースに変換され、内部ルーティングタグが生成されなければならない。一実施形態では、スケジューラは、単に放送を探し、ＣＡＭをソースアドレスで更新することによって、帯域外転送ＣＡＭ更新を削減するために適応可能且つ発見的であるように設計される。

図４に示されているような退出ＳＰＩ４．２変換は、進入の保存である。ローカルフレーミングフォーマットは、独自仕様のコアを使用してＳＰＩ４．２に変換される。退出ポート集約は、ＳＰＩ４．２フレームバーストデータを媒体パケットにアセンブルし、それらのアドレス指定された退出インタフェースを通してそれらを送出することを含む。再び、これらは好ましくは、前記に参照されたＭＡＣチップである。退出動作は侵入の逆である。イーサネット（登録商標）パケットデータはインタリーブされたイーサネット（登録商標）パケットデータ（ポート０からポート９）のバーストでＳＰＩ−４．２から退出ＦＩＦＯで受信される。退出ＦＩＦＯが５つのバーストを受信するとき（またはＥＯＰがパケット長に応じて到着するとき）退出ＦＩＦＯは１ＧｂＥ ＭＡＣへの転送を開始する。好ましくは、退出フレーム処理は、フレームエージング、ＶＬＡＮヘッダストリッピング、内部転送ヘッダ削除、及び類似した動作等のフレームステータスチェックを実行するポート状態機械も維持する。ＭＡＣチップによって実行されるイーサネット（登録商標）パケットでの動作は、（１）プリアンブルを追加する、（２）フレーム検出器の開始（ＳＦＤ）を追加する、及び任意で（３）ＦＣＳを追加することを含む。

図５と図６に描かれている例示的な実施形態では、ＯＰＥが段階―０、段階―１、段階２．．．段階−ｎと命名されたパイプライン化された段階エンジンの選択されたシーケンスを提供する。各段階エンジンは、ＯＰＥが利用される機能性に基づいて別の拡張可能な再プログラム可能アーキテクチャを有してよい。したがって、パケットが、それが採取するソフトウェア命令に関して特徴付けられる従来の技術のプロセッサとは異なり、本発明は回線を下降するデータの変更を反映するためにオンザフライでインスタンス化できる特殊化された段階のアセンブリラインである。

本発明は進入ポート数に制限的ではないが、本発明は単一のポートに到達し、ＯＰＥを通るデータ経路に沿ったパケットの生涯を追跡調査するデータパケットという点で最もうまく説明される。これらのデータビットストリームのそれぞれの幅が複数ビットであることに留意することが重要である。幅は、ワイヤスピードスループットを可能にするために、パイプラインの各段階エンジンで使用できる処理時間（つまりクロックサイクル）の測度を提供する。任意の１つの段階での処理が予備段階で設定された時間制約の中で達成できない可能性が高いと考えられるとき、各段階エンジンは、各段階を構成するエンジン数を増やすことによって、特定の時間エンベロープ内で動作するように制約されている。

図７は、本来、部分的にプログラム可能状態機械（ＰＳＭ）を含むプリプロセッサパケットフレーマである段階−０エンジンに備える本発明の実施形態の内の１つを描く。パケットが一度に６４ビット幅で入信すると、フレーマは図１に描かれているような多様なフレームタイプを識別し、区別する。フレーマは、ロード可能な値と選択論理とともに、プログラム可能メモリベース状態機械と、高速メモリベースルックアップテーブルと、多様なコンパレータとから構成される。状態機械は、関心のあるパケットフィールドを選択し、設定値または、フレームタイプを決定するだけではなく、関心のあるフレームに印を付ける状態機械アルゴリズムを駆動する他のフレームデータに対して比較する。次にこの情報は、それがフレームを構文解析する方法に関してパーサに指示するのに役立つパーサに渡される。

プリプロセッサビットストリームプロセッサの本実施形態のさらに詳細な説明については、開示が参照することにより本書に組み込まれている付録Ａが参照される。また、開示が参照することにより本書に組み込まれている、転送論理回路レジスタファイルの一実施形態を明示する付録Ｂも参照される。

ＯＰＥは、好ましくは少なくとも１台の予測可能なプログラム可能状態機械（ＰＳＭ）を含む。一実施形態では、各ＰＳＭは３２状態機械であり、１５６ＭＨｚの内部クロックの５０ｎｓ／ＰＳＭが１０命令あたり５ｎｓに同等である。しかしながら、各ＰＳＭは、可変数のクロックを有することがある。段階−０エンジンは、相対的に高速のシリアルビットストリームを相対的に低速のパラレルｎ−ビット幅データストリームに変換することにより帯域幅処理滞留時間を設定する。帯域幅処理滞留時間は、回線速度に調整される。例えば１０Ｍｂｐｓのデータレートを処理するために、滞留時間はＯＰＥの１段階あたり５０ｎｓである。

好ましくは、レジスタベースは、構成の部分としてロードされる値で事前設定されるプログラム可能ルックアップテーブルから成る。これらのレジスタは、次にマスク、コンパレータ、及び段階エンジンの動作に一体化したカウンタとの使用のために選択される。段階エンジン構成の例示的な構成は以下のように描かれている。つまり、プログラム可能ルックアップテーブルは、比較される最高３４個の１６ビット値を含む。テーブル出力ビットは、なされた場合には一致に対応する。例では、４台の８ビット幅のコンパレータと、２５６という最大ダウンカウントにとって最大ロード可能値が８ビットである２台のダウンカウンタがあってよい。パケットデータ選択幅は１バイトであってよく、レジスタ値フィールドサイズは１６個の８ビット幅事前設定レジスタによって表現されてよい。状態機械命令は単語命令（ＳＷＩ）であってよい。単語命令のセットは、セット、テスト、及び分岐から構成されるセットから選択されてよく、各命令の各フィールドは以下に示すような複数のスタブフィールドを取ってよく、各サブフィールドはカンマで分けられ、各メインフィールドはセミコロンで分けられる。例：ＳＷＩ：ｓｅｔ１，ｓｅｔ２，ｓｅｔ３，．．．ｓｅｔｎ；ｔｅｓｔ１，ｔｅｓｔ２，ｔｅｓｔ３，．．．，ｔｅｓｔｎ；ｂｒ１，ｂｒ２，ｂｒ３，．．．ｂｒｎ；
動作中、状態機械は、選択可能なベクトル入力に基づき条件付きの分岐を始めるであろう。このようにして、例えば条件（フレームバイト２＝＝Ｒ２）は、事前設定されたレジスタＲ２値に対して、８のパケットロケーションバイト２を比較するであろう。分岐は、通常は次の制御状態を決定するが、プログラム可能状態機械の現在の状態の運転モードを変更するためにも使用できるであろう。

ここで図８Ａ及び図８Ｂを参照すると、プリプロセッサパケットフレーミング方法の、ＸＧＭＩＩインタフェースから入信するイーサネット（登録商標）パケットへの適用が描かれている。このことから、ＸＧＭＩＩインタフェースブロックはプリアンブルを取り除き、図８Ｂ：イーサネット（登録商標）の標準フォーマットに図示されるように３２ビットインタフェースを内部６４ビット表現に変換する。

６４ビット幅のパケットがパイプラインを通って流れるに従い、状態機械は、それがどの１６ビットフィールドをプログラム可能復号ラムに送信することを希望するのかを選択する。図９：パケットタイプ選択及び図１０：プログラム可能復号ＲＡＭを参照すること。

状態機械は、プログラム可能レジスタに対して比較されるパケットからの他の情報も選択し、結果は図１０に示されるように状態機械にフィードバックされる。図１０は、例えばＶＬＡＮとＳＮＡＰの入力が選択され、選択されたレジスタに対して比較され、結果は分析のために状態機械にフィードバックされるのを示す。

本発明の一実施形態による状態機械の目的は、プロトコル層ヘッダ情報の抽出を制御することである。状態機械は、５本の出力データ回線が次の状態クロッキングのために５つのアドレス入力にフィードバックされる、プログラム可能ブロックメモリから構成される。他の出力の状態機械は、例えば、状態機械自体に対する次の入力だけではなく、比較論理のための取り込むフレームデータ、フレームレイヤオフセット検出、及び多様な入力選択のための多様な関数も制御する。

プログラム可能状態機械の１つの目的はパケットデータの復号と抽出を制御することである。図１４の状態図は、この状態機械がイーサネット（登録商標）パケットを処理するためにどのようにセットアップできるのかを描く。この例では、状態機械はイーサネット（登録商標）第２層だけを行ったが、例えば第４層までずっと続行することもあるであろう。

復号ＲＡＭは選択されたフィールドの高速プログラム可能復号を行うための方法を提供する。この復号ＲＡＭ回路に対する入力はパケットから出現する選択可能な１６ビットフィールドであり、出力は図１０に前記に描かれているように４ビットのタイプ復号である。これを行う１つの方法は、最初に全ゼロでメモリを充填し、次に復号を希望するタイプの復号ビットを書き込むことである。１６ビットアドレスは「タイプ」に相当し、データはそのタイプに所望される復号値に一致する。通常の状況では、２ビットだけが設定され、１ビットがポートＢに設定され、同がポートＡに設定される。復号ビットは、ポートＢとポートＡの両方にとって同じ値でなければならない。この例は、０ｘ８０９Ｂ ＡｐｐｌｅＴａｌｋフェーズ１を有することが所望される場合に、「１」の復号値となり、０ｘ８１３７ ＩＰＸ（ノベルネットウェア）を有することが所望される場合、「２」の復号値となり、０ｘ８８４７ ＭＰＬＳユニキャストを有することが所望される場合、復号値「３」となり、０ｘ８８４８ ＭＰＬＳマルチキャストを有することが所望される場合は、復号値「４」を取ることであろう。この結果は図１５に示されている。

図１６がプリプロセッサフレーマの基本機能ブロックのさらに完全な図を示す。

図１７は、入力選択を増加する方法と、状態の中でサブステートを有する能力とを描く。

図１８は、状態機械から出現する出力制御を拡大する方法を描く。

図１９は、状態機械によって選択できるマスク比較論理を示す。

図２０は、この状態機械によってプログラムできるであろうイーサネット（登録商標）フローチャートの例である。

図５と図６を参照すると、プリプロセッサフレーマはパケット選択を行う上でさらに柔軟性、つまりパイプライン選択に戻って選択可能なステップを行う能力を提供するように構成されてよい。さらに大きな機能が所望される場合には、それはつねに１つまたは複数の状態機械及び／またはプログラム可能復号ＲＡＭを追加することによって提供できるであろう。また、図示されているＲＡＭがブロックＲＡＭとしてＸＩＬＩＮＸに埋め込まれており、別に構成及びグループ化等することができ、この設計は、一方が状態機械に、他方がＴＹＰＥ（タイプ）復号に使用されている２つのブロックＲＡＭを示したにすぎないことにも留意する。最少のＸｉｌｉｎｘ ＸＣ２ＶＰ２は１２ブロックのＲＡＭを有し、次のサイズは２８を有し、最大のＸＣ２ＶＰ１２５は５５６のブロックＲＡＭを有する。

図２６で示されている本発明の一般的な実施形態では、ＯＰＥのデータパスは段階−０エンジンから段階−１エンジンにパイプラインする。段階１エンジンは、規則に基づいたパケットの分類を実行する。分類は、真のワイヤスピードスループットがあるように、段階＿０で定められる時間間隔内で発生しなければならないため、多くのエンジンが所望される結果を得るためにカスケードできる。各エンジンは、従来の蓄積転送モデルの代わりにデータフローモデルに基づいている。この段階の出力の１つが、パケットの関連コンテンツの事前知識を前提としたキー生成である。現在のインプリメンテーションでは、この段階は２つの命令サイクルを必要とする。各エンジンは単独のバッファを利用する。浮動小数点コプロセッサとは異なり、すべてのエンジンは動的にプログラム可能である。つまり、命令は、それらが特定のアプリケーションに適応できるように再プログラム可能である。通常、段階＿１は、少なくとも１台の超長命令語（ＶＬＩＷ）プロセッサを備える。代替実施形態では、段階−１エンジンが、前述されたように、タスクカスタマイズプロセッサのように構成されてよい。

図２７に描かれている本発明の明細書の実施形態では、段階−０と段階−１のエンジンはフィードバックループで動作し、ＰＳＭを使用する段階−０ビットストリームの状態情報が段階−１分類エンジンに渡され、分類子からの情報は段階−０エンジンの動作を知らせるためにフィードバックされる。フィードフォワード／フィードバックワードエンジンアーキテクチャにより、ＯＰＥによってサポートされている可能性のある複数のフローから、任意の既定のフローのコンテンツのビットストリームを採取し、エンジンを通るデータフローとしてコンテンツを構文解析し（または分類し）、次の動作が従来の状態の分類結果だけではなく、従来の状態にも基づくように従前の段階に戻る動作によって得られる情報を送ることが可能になる。

このような手法は、例えば可変長／可変プロトコルパケットを処理し、シーケンスパケットの中から、または他のエラー制御機能性のために動的に並べ替えるために有利に使用することができる。データの要素単位は、システムメモリ、つまり各ビットが、その前に行ったあるいはそれに続く各ビットに関連できるようにする接着剤を提供するフィードバックとフィードフォワードのあるビットになる。このパラダイムは、待ち時間と蓄積転送アーキテクチャのハードウェアオーバヘッドを招くことはないが、段階の特定の目的に応じて「メモリ」を、バイト、ワード、フレームまたはセッション全体等のマクロ要素データ構造のシステムの中に注入するためにスケーリングできる。このようなマクロ要素データ構造は、データが特定の特徴を有し、すべての以後のデータフローのためにＯＰＥの動作を再プログラムするために使用される間それらが持続するという点で短命である。このようにして、動作が結線されている従来のプロトコルプロセッサとは異なり、ＯＰＥは決定論的にではあるが進化するデータフローに適応する適応可能ハードウェアデバイスである。つまり、状態機械の数、及び増加したデータフローを処理するための状態を拡大することによって解決策を提供しようとする従来の技術の試みを特徴付ける「状態爆発」は、本発明により提供される解決策で克服される。

本発明の実施形態を複数段階ビットストリームプロセッサのために実現するデータフロー機構の実施形態が図４０に示されている。

多段階方法論の魅力的な特長の１つは、多様な段階エンジンのパラメータが効果的に減結合されるという点である。例えば、多様な段階間に１つの共通のクロックに対するニーズはない。これはＯＰＥの設計を大きく簡略化する。各段階はつねにその段階の操作ニーズに合わせられる１台または複数のエンジンで入力されてよい。各エンジンは、それに、ある特定の時点でＯＰＥが遭遇するデータフローの特徴に一致する機能性を与えることによってオンザフライでプログラムできる。

本発明の一般的な実施形態では、段階−２エンジンの後には段階−３エンジンが続く。段階−３エンジンは、ルーティング、信号伝達、プロトコルスタック、ポリシー定義、テーブル維持、データ平面に対するインタフェース等のさらに高水準の制御平面機能性を提供する。前記段階のように、段階−３は、ＯＰＥに課された処理時間と機能性の要件に一致するように複製されてよい特殊化されたエンジンである。図２８から図３１は、本発明のＯＰＥを特長とするＰ−ＳＥＲＤＥＳとコアエンジン及びＨＰＣポートカード付きの拡張可能なフレームプロセッサを描く。

一実施形態では、例えば前述された図に描かれているのは、スイッチ内の各ポートカードに３２エントリ掛ける４８ビットのＣＡＭである。各エントリは、スイッチ内の特定のポートを表す。したがって、ポートカード転送ＣＡＭの第1のエントリは、スイッチのポート１を表す。これらのＣＡＭは取り付けられているＬＡＮセグメント上で複数のノードを収容するためにサイズが大きくされてよいことが留意される。好ましくは、ポートカードの転送ＣＡＭにおける実践的なエントリだけを保持するエージング機構が定義される。ＨＰＣＣはＬＡＮセグメントを活用しないので、エージング機構は必要がない場合がある。

設計目標の１つは、ＳＮＭＰを介して転送ＣＡＭに対するアクセスを可能にすることであるので、シェルフマネージャで実行中のＳＮＭＰエージェントは、キャリアカードに常駐する転送ＣＡＭキャッシュに対する読み取り／書き込みアクセスを必要とする。転送テーブルキャッシュに対する変更は、更新ＣＡＭ ＩＰＭＩメッセージを介してポートカードを押し下げられ、前述されたように処理される。

動的ＭＡＣアドレス学習。スイッチがあらゆる２つのスイッチポートの間でパケットを転送するためには、入信パケットが送信される宛先スイッチポートを検出するために宛先ＭＡＣアドレスでルックアップが実行されなければならない。（転送テーブルとしても知られている）ルックアップテーブルは、好ましくは、６ビットスイッチポート識別子とともに宛先ＭＡＣアドレスを含む４８ビット値を含む。スイッチにより維持される転送テーブルは、個々のポートカードで管理される転送テーブルの間で分散される。（ＣＡＭによってハードウェアの中で実現される）これらの転送テーブルは、入力される必要がある。転送テーブルを入力するための２つの方法がある。つまり、動的に、と静的にである。これらのＣＡＭの静的な入力は、ＲＦＣ１４９３に説明される転送データベースに類似する転送ＣＡＭをＳＮＭＰ企業ＭＩＢを介して管理エンティティにさらすことによって達成される。

この設計の目標の１つは、ブロードキャストパケットとマルチキャストパケットの使用を管理することである。これは、ブロードキャストフレームが帯域幅とスイッチリソースという点で高価であり、マルチキャストフレームがなおさらに高価であるためである。全数検索は、スイッチがどのようなトポロジに配備されてよいのかに関係なく、このスイッチが各スイッチポートに接続されるＬＡＮセグメント上でＭＡＣアドレス（複数の場合がある）を動的に学習するためのメソッドを検出するために、及びブロードキャストまたはマルチキャストパケットを使用せずに、接続されるポートネットワークロジックに修正なくこれを行うために実行された。現在、スイッチがすべてのケースで、スイッチポートに接続されてよいすべてのＭＡＣアドレスを動的に決定できるようにする単一のメソッドまたはステップのセットはない。要するに、ＩＥＴＦ ＲＦＣによって定義されるようなインターネットまたはイントラネットは、スイッチ／ブリッジ／ルータが、接続されている、ＭＡＣアドレスを受動的に学習することを期待するか、あるいはスイッチ／ブリッジ／ルータが管理が転送テーブルを静的に入力する機構を提供するかのどちらかである。

したがって、本発明の本実施形態によるスイッチは学習するブリッジの挙動をエミュレートする。図２３に描かれている標準的なイーサネット（登録商標）フレーム等の入信ブロードキャストは構文解析され、ソースアドレスは適切な転送ＣＡＭに格納される。これは、ＦＰＧＡの内部のパケット転送論理回路とは無関係に埋め込まれたＦＰＧＡマイクロプロセッサによって達成される。以下は動的なＭＡＣアドレス発見を説明する。

ブロードキャストパケットはスイッチ進入ポートで受信される。パケットは、トラフィックディレクタがフレームＦＩＦＯを介してモバイル管理コントローラ（ＭＭＣ）にフレームを渡すまで転送論理回路を通過する。

ＭＭＣはデータリンク層ヘッダのソースアドレスを抽出する。

ＭＭＣはソースアドレスと進入スイッチポート番号をＩＰＭＩメッセージの中にカプセル化し、キャリアカード（ＩＰＭＣ）上のマイクロプロセッサにＳＰＩベースのＩＰＭＩバスを介してメッセージを転送する。

ＩＰＭＣは、ＲＡＣを介してＳＮＭＰをベースにした管理エンティティによって評価可能となる転送テーブルキャッシュの中にソースアドレスとスイッチポート番号を取り込む。

ＩＰＭＣはＣＡＭ更新メッセージをスイッチの中のすべての他のＭＭＣにブロードキャストする。

内部マイクロプロセッサはＣＡＭ更新メッセージを受信し、ＣＡＭ更新メッセージのＭＡＣアドレスを、スイッチポート番号によって表されるオフセットでのＣＡＭエントリの中に入れることによってその転送ＣＡＭを更新する。

この転送テーブル手順全体がよりロバストなトポロジ、つまり接続されているＬＡＮセグメント上の複数のノードをサポートするために広範囲に修正される必要があることが留意される。

好ましくは、データストリームの中の選択されたフレームにアクセスするために内部マイクロプロセッサによって読み取られる３２ビット幅のＦＩＦＯ。ＦＩＦＯは、内部ルーティングタグと入信パケットの最初の３２バイトで転送論理回路によって書き込まれる。ステータスレジスタは、いつＦＩＦＯが空であるのかを決定するために読み取られる。

前述されたように、ＦＰＧＡ制御及びステータスレジスタのファイルは、それによってＩＰＭＩによってカプセル化されたメッセージが実際のレジスタ読み取りまたは書き込みを実行するＦＰＧＡ内のマイクロプロセッサに向けられる、レジスタアクセス制御機構を通してアクセスできる。一実施形態では、マイクロプロセッサは、ＲＡＣメッセージを解釈するレジスタアクセスコントローラ（ＲＡＣ）として働き、どの転送論理要素／サブモジュールアクセスコントローラ（ＳＡＣ）にメッセージがアドレス指定されるのかを決定し、ＳＡＣによるレジスタアクセスを容易にする。結果として生じるステータス／応答はメッセージ発信元に返される。図２２はＳＡＣバスの一実施形態のブロック図を示す。ＳＡＣバスがサブモジュールにとって一意であり、多くの形式を取ってよいことが理解される。

ＩＥＥＥ規格はＰＡＵＳＥ（休止）パケットの宛先アドレスが、休止されるステーションの一意のＤＡに、または大局的に割り当てられるマルチキャストアドレス０１−８０−Ｃ２−００−００−０１（１６進）のどちらかに設定されてよいと記載している。加えて、ＰＡＵＳＥ（休止）パケットマルチキャストアドレスの付いたパケットは、フレームがローカルリンクセグメントを越えて伝搬できないことを確実にするブリッジによって転送されない。ＭＡＣ制御パラメータフィールドは、０から６５５３５の休止するビット時間数を指定する。過去のＰＡＵＳＥ（休止）期間の期限切れの前に受信されたＰＡＵＳＥ（休止）は、現在のＰＡＵＳＥ（休止）期間値を置き換える新しいビット時間値を生じさせる。これによりＰＡＵＳＥ（休止）期間をゼロにリセットすることができ、トラフィックを再開できる。

好ましくは、ＭＡＣチップは２つのフロー制御モードに提供する。全二重モードで構成されるとき、ＭＡＣチップは自動的にＰＡＵＳＥ（休止）パケットを生成できる。ＳＰＩ−４．２バスからの背圧が、ＭＡＣチップが開始ＰＡＵＳＥ（休止）信号伝達と停止ＰＡＵＳＥ（休止）信号伝達を管理する適切な高いまたは低いウォーターマークを設定することにより、ＭＡＣチップ進入ＦＩＦＯに充填させる。第２のモードはＦＩＦＯを迂回し、ＰＡＵＳＥ（休止）開始パケットと停止パケットを生成するためにＳＰＩ−４．２フロー制御メッセージングに依存する。

ポート状態機械はポートカード上のスイッチポートごとに維持される。状態機械はＦＧＰＡ論理回路とマイクロプロセッサの両方によってアクセス可能となる。本書で説明されるような状態機械は３つの基本要素、つまりイベント、定義状態、及びその状態に入るときに実行されるアクションを含む。前記に定義されたイベントは、同様に図２４の中の図と図２５の中の状態図が示すようにアクションを実行する状態への状態遷移をトリガする。

図３２は、適応可能なハードウェアデバイス、つまりＶｉｒｔｅｘ ＬＸ２００通信エンジンが、進入「ポート」と退出「ポート」を構成するＶｉｒｔｅｘ Ｐｒｏ４通信エンジンにそれを結合することによって４８ポートスイッチに構成される実施形態を描く。この構成での問題は、スイッチ装置がＶｉｒｔｅｘ Ｐｒｏ４通信エンジンによってサポートされるであろうスイッチ装置を通して切り替えられるデータパケットのための単一プロトコルを処理することに制限されるという点である。

図３３は、ＯＰＥがポートプロセッサエンジンを形成し、デジタルスイッチがＶｉｒｔｅｘ ＬＸ２００通信エンジンか、またはインテリジェントで、再プログラム可能なスイッチング構造を形成する特殊目的ＯＰＥのどちらかであってよい本発明によるスイッチの特殊アーキテクチャを描く。図３２に示されるスイッチ機構とは異なり、本発明によるＯＰＥを活用する図３３の実施形態は、ＯＰＥによってサポートされている複数のプロトコルのどれかのデータパケットを処理できる全プロトコルスイッチ／ブリッジ機構を提供する。図３３は、本発明のスイッチの特殊構成を概略的に描く。

マイクロプロセッサは、状態に入るときに生成されるイベントに加えて、ＭＡＣチップ、ＳＦＰを監視し、スイッチポート状態の遷移を引き起こすイベントを提供するためにＩＰＭＩイベントとメッセージを傾聴する必要がある。任意のイベントが任意の状態で発生する可能性があり、適切に捕らえられ、処理されなければならないことに留意する。明確にするため、状態図はすべての潜在的な状態遷移を示さない。また、大部分のイベント遷移はＩＰＭＩイベントメッセージを生成させ、潜在的なＳＮＭＰトラップを引き起こす。

ＩＮＩＴ状態は、ポート状態機械のインスタンス化でのスイッチポートの初期状態である。この状態に入ると、ポートが管理上無効とされていない限り、最初にＳＦＰが有効にされ、ＴＸ＿ＥＮＡＢＬＥイベントが生成される。

スイッチポートがＥＮＡＢＬＥＤ（有効）状態に入ると、ＳＦＰが存在するかどうかを判断するためにチェックが実行される。ＳＦＰが存在する場合、ＭＯＤ＿ＤＥＴＥＣＴイベントが生成される。

ＦＡＵＬＴＥＤ（障害）状態に入るスイッチポートは、ダウンしていると見なされる。この状態から遷移するためには人間の介入が必要とされる。

ＭＯＤ＿ＥＸＩＳＴＳ−この状態に入ると光信号でチェックが実行される。信号が正常である場合、ＳＩＧＮＡＬ＿ＤＥＴＥＣＴイベントが生成される。

ワード同期はＳＩＧＮＡＬ（信号）状態で検証される。信号が同期すると、ＳＩＧＮＡＬ＿ＳＹＮＣイベントが生成される。

ＳＹＮＣｅｄ（同期済み）。信号が同期した後、イーサネット（登録商標）自動交渉が完了したかどうかを決定するためにチェックが実行される。イーサネット（登録商標）自動交渉が完了すると、ＡＵＴＯ＿ＮＥＧ＿ＤＯＮＥイベントが生成される。

ＵＰ（アップ）状態では、スイッチポートはＵＰ（アップ）であり、フレームをスイッチファブリックに転送できる。しかしながら、接続されているノードのＭＡＣアドレスは学習されていない。

ＲＥＡＤＹ（準備完了）状態では、スイッチポートは作動可能である。

本発明の別の実施形態では、無損失パケットスイッチングが、Ｄｒ．Ｌａｗｒｅｎｃｅ Ｇ．Ｒｏｂｅｒｔｓ、創立者、ＳＳＧＲＲ ２００３Ｓ国際会議、イタリア、ラクイラ（Ｌ‘Ａｑｕｉｌａ Ｉｔａｌｙ）、２００３年７月２９日でのＣＴＯカスピアンネットワークス（Ｃａｓｐｉａｎ Ｎｅｔｗｏｒｋｓ）によるＩＰの次世代―フロールーティング（Ｔｈｅ Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ ｏｆ ＩＰ−Ｆｌｏｗ Ｒｏｕｔｉｎｇ）で検討されたフロールーティングの検討と同じ回線に沿って、説明されたような全プロトコルエンジン構成を使用してであるが実現される。文書の内容は参照することにより本書に組み込まれている。加えて、論文に説明される概念は、フロー制御及び輻輳管理に関するＩＥＥＥ ８０２．３ＡＲ作業部会の推奨策に従って、本発明のＯＰＥでエンドツーエンドフロー制御を実現するために拡張できる。

本書に開示されるＯＰＥの一実施形態を含む段階に適用されると、ＱＯＳレベルごとの休止は（３段階プロセッサ、（ａ）２つの必要とされるＸＡＵＩインタフェースのそれぞれに取り付けられるビットストリームプロセッサ、（ｂ）フロー識別または規則をベースにしたトラフィック優先順位識別フロー分類段階のためのルックアップキー生成、（ｃ）フロー制御及び輻輳管理に関するＩＥＥＥ ８０２．３ＡＲ作業部会の予想される推奨策を満足させるために、さらに高い層のプロトコルスタックまたはバッファマネージャに対する適切な背圧通知を生成するためのプロセッサ段階から成る）エンジンで実現できる。優先順位識別のニーズは、内容が参照することにより本書に組み込まれている、Ｐ８０２．３ａｒ「輻輳管理、優先順位／クラスをベースにしたＰＡＵＳＥ（休止）はなぜ必要とされるのか（Ｃｏｎｇｅｓｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｗｈｙ Ｐｒｉｏｒｉｔｙ／Ｃｌａｓｓ Ｂａｓｅｄ ＰＡＵＳＥ ｉｓ Ｒｅｑｕｉｒｅｄ？）」、Ａｓｉｆ Ｈａｚａｒｉｋａ（ａｈａｚｉｒｉｋ＠ｆｍａ．ｆｕｊｉｔｓｕ．ｃｏｍ）、及びＢｏｂ Ｂｒｕｎｎｅｒ（Ｒｏｂｅｒｔ．Ｂｒｕｎｎｅｒ＠ｅｒｉｃｓｓｏｎ．ｃｏｍ）で強調される。

ブロックは、次に、段階プロセッサで実現された２つのＸＡＵＩインタフェースと、１つまたは２つのＳＰＩ ４．２インタフェースとを有する。トラフィックディレクタまたはスイッチング段階の追加により、ブロックは、暗号文に対する入信トラフィックと案内（Ｔｒａｆｆｉｃ ａｎｄ Ｄｉｒｅｃｔ ｔｏ Ｃｒｙｐｔｏ）エンジン、あるいは帯域識別におけるＶＬＡＮタグまたは他に基づいた処理エンジンの識別のためにも使用できるであろう。これは、８ ＳｅｒＤｅｓポートＸｉｌｉｎｘ（ＦＸ−４０）で実現できるであろう。代わりに、ＡＭＣが使用できるであろう。これは、（ＲＴＭまたはフロントパネルのどちらかからＩ／ＯのためにＸＡＵＩを選択する）第３の要件も満足させることができる。

本発明のＯＰＥによるフロー処理に関して、機能性がクロックサイクルごとに変更できる場合には、回路がプログラム可能と呼ばれることが理解される。これは通常プロセッサと呼ばれる。プロセッサは命令セットアーキテクチャ（ＩＳＡ）及びレジスタファイル（ＲＦ）によって定義される。これが、いわゆるプロセッサのプログラマの視点、つまりプロセッサを構成するハードウェアとプロセッサで実行できるソフトウェアの間のインタフェースである。内容が参照することにより本書に組み込まれている、Ｔｈｏｍａｓ Ｈｅｎｒｉｋｓｓｏｎ、「パケット内データフロープロトコルプロセッサ（Ｉｎｔｒａ−Ｐａｃｋｅｔ Ｄａｔａ−Ｆｌｏｗ Ｐｒｏｔｏｃｏｌ Ｐｒｏｃｅｓｓｏｒ）」、科学技術におけるＬｉnｋoｐｉｎｇ究（Ｌｉｎｋoｐｉｎｇ Ｓｔｕｄｉｅｓ ｉｎ Ｓｃｉｅｎｃｅ ａｎｄ Ｔｅｃｈｎｏｌｏｇｙ）、学位論文第８１３番、及びＪｏｈｎ Ｌ．Ｈｅｎｅｓｓｙ及びＤａｖｉｄ Ａ．Ｐａｔｔｅｒｓｏｎ、「コンピュータアーキテクチャ：定量的手法（Ｃｏｍｐｕｔｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ： Ａ Ｑｕａｎｔｉｔａｔｉｖｅ Ａｐｐｒｏａｃｈ）」、モルガンカーフマン出版社（Ｍｏｒｇａｎ Ｋａｕｆｍａｎ Ｐｕｂｌｉｓｈｅｒｓ，Ｉｎｃ．）、ＩＳＢＮ １−５５８６０−３２９−８、第２版１９９６年を参照すること。本発明の関連では、あらゆるサイクルが、データが処理されなければならない―データ到着間隔―になる。ＩＳＡに類似し、ＯＰＥの段階はフローＰＳＡ―フロー処理設定アーキテクチャ―として定義でき、ＲＦはパイプラインレジスタファイルとして定義できる。ＩＳＡは、フェッチ（命令及びまたはデータ）、復号、延期（さらに多くのデータを取得するため）、実行（データに関する命令）、シーケンス記憶（フォンノイマン（Ｖｏｎ Ｎｅｗｍａｎ）モデル）を実行するマイクロコードのセットである。フローＰＳＡの機能性は同様に示すことができる。

すべてのＩＰＭコントローラを本発明の一実施形態の筐体に接続するために使用されるＩＰＭＩ拡張の実施形態が説明される。本発明の実施形態の本態様のさらに詳細な説明については、「ハードウェア／ソフトウェアが二重冗長構成で実現されるシェルフ管理コントローラ（Ｓｈｅｌｆ Ｍａｎａｇｅｍｅｎｔ Ｃｏｎｔｒｏｌｌｅｒ ｗｉｔｈ Ｈａｒｄｗａｒｅ／Ｓｏｆｔｗａｒｅ Ｉｍｐｌｅｍｅｎｔｅｄ Ｄｕａｌ Ｒｅｄｕｎｄａｎｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）」と題される前記に特定された仮特許出願が参照される。

図３６Ａ及び図３６Ｂは、本発明の一実施形態によるシェルフ管理コントローラまたはＳｈＭＣ２３０を描くブロック図を描く。図３６Ａと図３６Ｂのブロック図に描かれているように、本発明は、自動フェイルオーバ付きのアクティブ／スタンバイアーキテクチャを活用する冗長シェルフ管理機能性を提供するために、対称配置で第２のＳｈＭＣ３１５に通信で結合される第１のＳｈＭＣ３１０を提供する。第１の実施形態では、ＳｈＭＣ３１０と３１５のそれぞれはアーキテクチャ的に同一である。各ＳｈＭＣ３１０（３１５）は、例えば、薄いスタックのｕｃＬｉｎｕｘＯＳ等の小さな設置面積のオペレーティングシステム（ＯＳ）３２５を実行する独立プロセッサ３２０を含む。ＳｈＭＣ３１０（３１５）はスタンバイパワーで動作し、インテリジェントプラットホーム管理コントローラ（ＩＰＭＣ）２３５を自動的にポーリングすることによってシステム健康変数を取得する。ＳｈＭＣ ３１０（３１５）は、異常を検出し、イベントを記録し、システムに異常を通知するために警報を生成し送信し、回復アクションを起動するように構成される。

図３６Ａに描かれているように、各ＳｈＭＣ ３１０（３１５）は少なくとも２つのＩ２Ｃ／ＩＰＭＢバス、ＩＰＭＢ−Ａ２７０とＩＰＭＢ−Ｂ２７５に接続されている。ＳｈＭＣ３１０（３１５）はアクティブ−アクティブモードまたはアクティブ−パッシブＩ２Ｃ／ＩＰＭＢフェイルオーバモードで配置されてよい。本発明の本実施形態は、抽象化チャネル（ＡｂＣｈ）でメッセージを渡す統一メッセージシステムを意図する。本発明の本実施形態では、チャネルは例えば、Ｉ２ＣＪＴＡＧ、更新チャネル及び自由空間等の物理リンクである。ＡｂＣｈのビューでは、各チャネルは、例えばクライアントサーバチャネル、ピアチャネル、照会と応答の方向、帯域幅、待ち時間及びＣｏＳまたはＱｏＳに関する容量、一次経路、代替経路、例えばエコー、または肯定応答メッセージング等のフィードバックチャネルを示すマスタスレーブチャネル等の属性を有する。属性はプログラム可能、または例えばバッファを用いてハードウェアで支援されていると見なされる。すべての属性状態は随意に綿密に調べることができるため、例えばレジスタをサポートできる。ＡｂＣｈは、メッセージングシステムが随意に、またはシステム変更のニーズとしてメッセージを送ることを可能にする。好ましくは、ＧＵＩプログラミングツールは、属性をハードウェアプラットホームに渡すため、性能を測定するため、シミュレーションを実行するために等、既定のハードウェアプラットホームのための１つまたは複数のチャネルを作成するために使用することができる。当業者は、ＥＥＰＲＯＭで命令を実行する能力が、アプリケーションをスケーリングできるようにすることを容易に認識する。

再び図３６Ａを参照すると、本発明によるＩＰＭＩメッセージングシステムモデルが二重クライアント−サーバメッセージングシステムとして描かれている。複数のシェルフ構成要素の中でのクライアント−サーバメッセージング方式は、層の独立を維持するためにチャネル抽象化層を使用する。ＳｈＭＣ３１０は、専用の更新チャネル３３０とアクティブ制御チャネル３３５によってＳｈＭＣ３１５に通信で結合されている。更新チャネル３３０は、サニティ及び状態情報をＳｈＭＣ３１０（３１５）間で双方向で送信するように適応されている。クライアント−サーバをベースにしたメッセージングシステムの２つのインスタンスが各ＳｈＭＣ３１０（３１５）上で動作する。例示的な実施形態では、アクティブなＳｈＭＣ３１０（例えば）が、本発明の範囲から逸脱することなく、システム起動時に例えばサーバと指定されてよい。次にＳｈＭＣ３１５がクライアントと指定される。アクティブなＳｈＭＣ３１０は、ＩＰＭＣ２３５から状態情報を受信するとシェルフ管理機能を実行するためのコマンドセットを実行する。

図３６Ａと図３６Ｂの図の実施形態では、ＳｈＭＣ３１０（３１５）の独立プロセッサ３２０が、ＩＰＭＢ上のＩＰＭＩ１．５、シリアルポート上のコマンドラインインタフェース（ＣＬＩ）、テルネット、及びＳＳＨセキュアシェルを含むがこれに限定されるものではないすべての物理インターフェイスタイプにとって一般的である少なくとも１つのプロセッサインタフェースとともに配置されるビットストリームプロセッサ（ＢＳＰ）３４０と通信して配置される。一実施形態では、ＳｈＭＣ３１０（３１５）は、例えば、ＲＭＣＰ上で架橋するＢＳＰ３４０、及びＩＰＭＩメッセージを使用して実現されるＲＣＭＰ−ＩＰＭＩブリッジ３１２を含む。ＲＭＣＰメッセージパケットがシステムマネージャから受信されると、パケットは開かれ、ＵＤＰ ポート＃について調べられる。ＵＤＰポート＃がＩＰＭＩメッセージと一致すると、パケットはそのヘッダが削除され、ＩＰＭＩヘッダ（存在する場合）がカプセル化される。次に、メッセージは適切なインタフェースに送信される。ＳｈＭＣカーネルがコピーバックを要求できる。システムマネージャに対するＩＰＭＩメッセージがカプセル化され、システムマネージャ物理ポート上で送信される。

図３７Ａ及び図３７Ｂは、ＢＳＰ４４０を使用する１２Ｃハードウェア有限状態機械（ＨＦＳＭ）４７５の例示的なインプリメンテーションを描く。本実施形態では、ＢＳＰは本発明に従って説明されるような全プロトコルビットストリームプロセッサである。ＢＳＰは、ＩＰＭＢ−Ａ２７０バスとＩＰＭＢ−Ｂ２７５バスでのビットストリームのワイヤスピードパケットデータ経路処理のために構成される。ＢＳＰはビットストリーム内のビットを定義プロトコルデータ（情報）単位にアセンブルし、遭遇したプロトコルに関係なくワイヤスピードスループットを提供するために、アセンブルされたプロトコルデータ（情報）単位を処理するように適応される。これらの機能の両方とも、後述されるように、例えばＲＡＣ／ＳＡＣ（４８７／４８９）を使用して動的にプログラム可能である。したがって、プロトコルデータ（情報）単位に適応するプロトコルの情報単位または処理規則のどちらかは動的に固有に変更可能である。

一実施形態では、ＨＦＳＭ４７５は、パイプライン化された段階エンジンの選択されたシーケンスで構成されるＢＳＰ４４０を含む。各段階エンジンは、メッセージ（例えば、システム健康、温度、ファン回転等）をＨＦＳＭ４７５に送信するＩＰＭＣ２３５ごとにデバイス有限状態機械（ＤＦＳＭ）４８０のインスタンス化を引き起こす別の拡張可能且つ再プログラム可能なアーキテクチャを有してよい。ＤＦＳＭ４８０はメッセージング有限状態機械（ＭＦＳＭ）４８５をインスタンス化するように適応されたＢＳＰ４４０の段階エンジンに対するデータフロー通信のために有利に構成される。一般的には、（ＤＦＳＭとＭＦＳＭだけではなく）ＨＦＳＭも３つの基本構成物を使用する。ＨＦＳＭは、ＦＳＭが既定の状態にある間に既定のイベントが受信されるときに実行するアクションと、ＦＳＭが既定の状態にある間に既定のイベントが受信されると入る次の状態を含む次の状態テーブルと、イベントを提示されるとイベント処理を駆動し、必要なアクションを調べ実行し、現在状態の情報を更新するイベントハンドラとを含む。段階機械（またはＢＳＰまたはＦＰＧＡ）制御ファイル及びステータスレジスタファイルは、レジスタアクセス制御（ＲＡＣ）４８７機構を通してアクセス可能であり、それによりＩＰＭＩカプセル化メッセージは次に実際のレジスタ書き込みと読み取りを実行する段階機械（またはＢＳＰまたはＦＰＧＡ）の中のマイクロプロセッサに導かれる。マイクロプロセッサは、ＲＡＣメッセージを解釈し、どの転送論理回路要素／サブモジュールアクセスコントローラ（ＳＡＣ）４８９にメッセージがアドレス指定されるのかを決定し、ＳＡＣとのレジスタアクセスを容易にするレジスタアクセスコントローラ（ＲＡＣ）として働く。結果として生じるステータス／応答はメッセージ発信元に返される。ＲＡＣ／ＳＡＣ ４８７／４８９は、オンザフライでデバイス（つまりＩＰＭＣ２３５）ごとにメッセージング方法を設定するまたは変更する手段を提供し、このようにして本発明のプログラム可能性と柔軟性のレベルを実現する１つの機構を提供する。

一実施形態では、ＨＦＳＭ４７５は、デバイス故障だけではなくＩ２Ｃバス故障も検出するように適応される。故障がＩＰＭＣ２３５の内の１つによって監視されているデバイス上であると決定されると、ＳｈＭＣ３１０（３１５）はそのデバイスがバックプレーンにアクセスするのを無効にする。

再び図３６Ａを参照すると、クライアント３１５は更新チャネル３３０を使用してアクティブＳｈＭＣ３１０の照会と応答を監視し、トランザクションの状態を計算し、これらの状態をアクティブＳｈＭＣ３１０と同期させる。クライアントＳｈＭＣ３１５がＳｈＭＣ３１０のエラー状態を検出するケースでは、それは審判員として働き、アクティブなＳｈＭＣ３１０を取り除き、スタンバイＳｈＭＣ３１５が時間消費状態更新なしにフェイルオーバを完了できるようにするシステムマネージャ２６５にイベントを報告する。本実施形態はＡｄｖａｎｃｅｄＴＣＡに準拠するシステムとの動作に適しているが、それは図３６Ｂに描かれているように、トライステート化されたスタンバイが規定されるＭｉｃｒｏＴＣＡ環境でも機能する。

別の実施形態では、ＳｈＭＣ３１０（３１５）は、ハードウェアによって支援される薄いプロトコルスタックによって拡大される。システムの別の実施形態は、とても小さく管理可能なＳｈＭＣインプリメンテーションを保証するためにＯＳバイパス方式を実現する。一次実施形態は、例えば、ＳｈＭＣプロセッサ３２０の機能のコストの点でのスケーリングを可能にするであろうシステムオンチップ（ＳＯＣ）概念を使用するＴＩＮＹ ＣＨＩＰ（タイニーチップ）付きのＥＥＰＲＯＭのような命令を実行するためのＥＥＰＲＯＭを含む。

一実施形態では、二重冗長ＳｈＭＣ３１０（３１５）構成が、シェルフ管理コントローラのフォルトトレラント動作を導入するために使用される。第１の実施形態では、ＨＦＳＭ４７５で追加チェックポイント状態を追加することによって、チェックポイントが挿入される。ＨＦＳＭ４７５内での現在の状態がチェックポイント状態であるとき、チェックポイントプロセスが開始されてよい。エラーが示されると、ＨＦＳＭ４７５は、独占使用バス３３５の上でのＳｈＭＣ３１５に対するフェイルオーバ、及びＳｈＭＣ３１０で起動された回復プロセスを、ＡＴＣＡシェルフ内に異常を生じさせることなく起動してよい。回復プロセスは、ＳｈＭＣ３１０の故障前の状態を再現するために、その元の順序でＳｈＭＣ３１５に記憶されているログ状態をリプレイすることによってＳｈＭＣ３１０の内部の障害状態を復元することによって行なわれてよい。別の実施形態では、追加のＳｈＭＣ４９２はＳｈＭＣ３１０（３１５）を拡大するために使用されてよく、正しい状態は３つまたは４つ以上のＳｈＭＣの間で保持される状態の３つまたは４つ以上のコピーの間で投票することによって得られる。一実施形態では、投票された結果は、あらゆる矛盾する投票を解決する目的でＨＦＳＭ４７５のそれぞれのレジスタの中にロードされる。

図３８に描かれている本発明の一実施形態では、ＸＵＡＩ双方向ブリッジアーキテクチャにＳＰＩ ４．２に提供するビットスチームプロトコルプロセッサ（代わりにビットストリームプロトコルプロセッサをベースにしたブリッジ、または単にビットストリームプロトコルプロセッサと呼ばれる）が示される。第１のタイプのシリアルデータ伝送インタフェースはＳＰＩ４．２インタフェースに一致し、第２のタイプのシリアルデータ伝送インタフェースはＸＡＵＩインタフェースである。

この実施形態のビットストリームプロトコルプロセッサは、ＸＡＵＩブリッジに二重ＳＰＩ４．２を提供する。ＳＰＩ４．２は並列ポイントツーポイント双方向インタフェースを提供する。ＳＰＩ４．２フレーミングは最大２５６ポートまでサポートする。データは、１個の完全なパケットとして、またはポートごとの複数のデータバーストとして、１６のＬＶＤＳデータレーンを使用してＳＰＩ−４．２フレームを通して送信される。サブチャネルデータに付加される制御語ヘッダがバーストを区切る。制御語の中のパケットビットの始まり（Ｓ）とパケットステータスビットの終わり（ＥＯＰＳ）は、複数のバーストから構成されてよい１個の完全なパケットを識別するために使用される。アドレスビット［０：７］は、サブチャネルを定義するために使用される。フロー制御及びステータス情報はサブチャネルごとに帯域外でトランスポートされる。インタフェース帯域幅は、低オーバヘッドアプリケーションの場合の毎秒１０Ｇｂｉｔからオーバヘッド情報をサポートするために帯域幅の加速を必要とするスイッチファブリックのようなアプリケーションの場合の毎秒２０Ｇｂｉｔに及ぶことがある。

１０ＧｉｇＥの場合、各ビットストリームプロトコルプロセッサが、ポートごとに１０Ｇｂｐｓ全二重をサポートし、２．５６０Ｔｂｐｓスイッチングスループット容量を達成することを可能にすることが分かる。４０ＧｉｇＥの場合、各ビットストリームプロトコルプロセッサはポートごとに４０Ｇｂｐｓ全二重をサポートし、１０Ｔｂｐｓスイッチングスループット容量を達成することを可能にする。一般的には、本発明による全プロトコルエンジンの再構成可能且つプログラム可能な性質が一連のクロック速度でプロセッサが本質的にスケーラブルとなることを可能にすることが認識される。

本発明の一実施形態によるビットストリームプロトコルプロセッサが、例えばＰＣのシステムプロセッサ（ＣＰＵ）とシステムメモリの間でＮ個の相互接続を提供できることが認識される。Ｎ個の相互接続のそれぞれは、１０Ｎ Ｇｂｐｓのスケーリングされたスループットを生じさせる１０Ｇｂｐｓでデータを転送するように構成されてよい。ＳＰＩ４．２は、互いから数インチで設置されるデバイス間のポイントツーポイントインタフェースである。システムでは、多くの場合、バックプレーンを介して筐体内のさまざまなカード上に位置する（筐体内）、あるいは別の筐体に位置する（筐体間）ＳＰＩ４．２デバイスを相互接続することが望ましい。こうした状況では、高い帯域幅の接続を筐体内環境または筐体間環境で提供する、本発明のシリアルポイントツーポイントリンクを使用することが有利である。例示的なシリアルリンクはＰＣＩエキスプレスを使用するＡＳＩ、ＸＡＵＩを使用するイーサネット（登録商標）、及びＩＢを使用するインフィニバンドを含む。これは事実上、考えられる数百の地理的に分離されたＳＰＩ４．２デバイスの中から任意の２つを、「バーチャルワイヤ」インタフェースに接続することになる。一実施形態では、本発明は単一ボードコンピュータ（ＰＣ）として構成されてよい。別の実施形態では、本発明は、エンドユーザの更新を行うにつれてフィールドペイをサポートする取り外し自在に取り付けられたブレード付きの（例えばｐｉｃｏＴＣＡ等の）業界規格エンクロージャを提供する。

シリアルリンクを使用して、あるいはバーチャルワイヤを介して、ポートアドレスを含む制御語、並列ＳＰＩ４．２インタフェースで入手可能なデータ及び帯域外フロー制御情報をトランスポートするために、トンネリングプロトコルが活用される。高帯域幅使用を保証するために、これらのトンネリングプロトコルは好ましくは軽量である。トンネリング特長はＳＰＩ４．２デバイスの中に埋め込まれてよい、あるいはブリッジチップがこの変換を提供するためにＳＰＩ４．２デバイスとの関連で使用できるであろう。成熟トンネリングプロトコルを使用する多様なシリアルインタフェースを使用してこのブリッジをＳＰＩ４．２デバイスの間でサポートするために、ブリッジはプログラム可能である。この実施形態では、ビットストリームプロトコルプロセッサをベースにしたブリッジが、ＳＰＩ４．２インタフェースをＸＡＵＩ及び他のシリアルインタフェースに提供し、多様なトンネリングプロトコルに柔軟な手段を提供する。ビットストリームプロトコルプロセッサはその全体として本書に組み込まれている付録Ａに説明されているように、動的なプログラミング及び関数の拡張性を提供する。

ここで図３９を参照すると、ビットストリームプロトコルプロセッサの別の実施形態が示されている。本実施形態では、ビットストリームプロトコルプロセッサは直接的にフロントサイドバス（ＦＳＢ）と接続し、それにより図３８に関連して説明されているビットストリームプロトコルプロセッサの中の特定の変換プロセスを排除する。加えて、図３９のビットストリームプロトコルプロセッサは、細いパイプと太いパイプのパラレル−シリアルトランスレータの両方を提供し、このようにして太いパイプ構成のために１つまたは複数のイーサネット（登録商標）との選択的な集約を可能にする。

一実施形態では、ビットストリームプロトコルプロセッサは、イーサネット（登録商標）で単純なトークンをベースにした通信を実現するために活用される回線速度ＱｏＳパケットスイッチングを可能にする。ソースアドレス（ＳＡ）と宛先アドレス（ＤＡ）、及びＶＬＡＮタグのようなＥタイプが通信リンク上でのエンドポイント間の一意のトークンを交渉するために使用される。Ｅタイプの拡張は、例えば、ＵＮＩＱＵＥ ＩＤ（一意のＩＤ）またはＴＯＫＥＮ ＧＲＡＮＴ（トークン許可）の要求、許可されたトークンを用いるデータ通信、及びＴＯＫＥＮ（トークン）を回収する要求であってよい。いったんＴＯＫＥＮ（トークン）が許可されると、ＳＡフィールドとＤＡフィールドは、短期をパスするためにＥタイプとともに使用される。これは、ＳＴＡ及びＳＡＳのためのデータの大きなブロックを含むために拡張されてもよい。他の実施形態では、いったんＵＮＩＱＵＥ ＩＤ（一意のＩＤ）がエンドポイントと、これらのエンドポイントを接続する中間ノードの間で交渉されると、固定フレームサイズが、固定フレームサイズを転送する上で予測可能な性能をリンクに与え、その結果多様な待ち時間要件を満たすために使用される。例えば、ＳＡ／ＤＡ組は、従来のイーサネット（登録商標）パケットのための従来の６４バイトペイロードの代わりに１２バイトのデータ、２Ｅタイプのバイト及び２バイトのＴＡＧを送信するために使用できるであろう。この拡張されたイーサネット（登録商標）通信技法の一実施形態のさらに詳細な説明のために、「一意ＩＤに基づいて制約を受けた近傍の中での短縮されたデータフレームのために強化されたイーサネット（登録商標）プロトコル（Ｅｎｈａｎｃｅｄ Ｅｔｈｅｒｎｅｔ（登録商標） Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｓｈｏｒｔｅｎｅｄ Ｄａｔａ Ｆｒａｍｅｓ Ｗｉｔｈｉｎ ａ Ｃｏｎｓｔｒａｉｎｅｄ Ｎｅｉｇｈｂｏｒｈｏｏｄ ｂａｓｅｄ ｏｎ Ｕｎｉｑｕｅ ＩＤ）」と題される前記に特定された特許仮出願が参照される。

別の実施形態では、同じインタフェースがディスクに固定２Ｋブロックサイズのフレームを提供できるであろう（データはＥタイプとＴＡＧに従う）。この点で、技術に公知の可変フレームサイズの構成物と対照的に、本発明はプログラム可能フレームサイズのイーサネット（登録商標）構造物を可能にする。この機能は、それがＡＴＣＡのフレームワーク内でパケット化するＴＤＭトラフィックを可能にするため、ｉＴＤＭタイプのアプリケーションにおいて特に有効となることがある。

一実施形態では、イーサネット（登録商標）ＶＬＡＮヘッダは、業界規格のイーサネット（登録商標）スイッチを、筐体内環境または筐体間環境に位置する任意の２台のＳＰＩ４．２デバイス間で切り替えるために使用できるようにするトンネリングプロトコルとして使用される。本発明の一次実施形態は、第２のデータ伝送プロトコルとしてギガビットイーサネット（登録商標）（ＧｂＥ）を使用する。他のプロトコルは本発明の範囲から逸脱することなく使用されてよい。ＳＰＩ４．２制御語及びフロー制御情報は標準イーサネット（登録商標）ＶＬＡＮヘッダに変換される。ＳＰＩ４．２サブチャネルデータは、進入時にヘッダ情報とカプセル化される。退出時、ヘッダ情報はイーサネット（登録商標）フレームから取り除かれ、ＳＰＩ４．２フレームに変換して戻され、フロー制御情報はＳＰＩ４．２電気信号に変換される。さらに、ビットストリームプロトコルプロセッサは、サービス情報のクラスを埋め込むための効率的な手段と、輻輳管理メッセージを作成し、伝搬するためのプログラム可能手段とを提供する。

一実施形態では、ビットストリームプロトコルプロセッサは、それをＡＴＣＡシステムとｍｉｃｒｏＴＣＡシステムで使用するための理想的な汎用デバイスにするために、ＧｂＥ、ＰＣＩ−エキスプレス（ＰＣＩ−Ｅｘｐｒｅｓｓ）、ＲＧＭＩＩ、ＰＣＩバス及びシリアルバス等のインタフェースをサポートするように構成される。当業者は、ＳＰＩ４．２インタフェースをＸＡＵＩインタフェースに架橋し、デバイスブリッジ（例えば、イーサネット（登録商標）スイッチへのＮＰＵ）、シリアルバックプレーンアプリケーションＳＯＮＥＴ／ＳＤＨ上のパケットまたはＳＯＮＥＴ／ＳＤＨ上のイーサネット（登録商標）アプリケーション等の複数の設計要件を満たすための、例えばＭｏｒｅｔｈａｎＩＰからのＸＳ４ １０ギガビットイーサネット（登録商標）及びＨｉＧｉｇ ＳＰＩ４．２ブリッジ等の他の相互接続技術を認識する。

バックプレーンを介して筐体内のさまざまなカード上に位置する（筐体内）、あるいは別の筐体に位置する（筐体間）ＳＰＩＰ４．２デバイスを相互接続する本発明により与えられる能力が、本発明の一実施形態に、例えばｐｉｃｏＴＣＡまたはｍｉｃｒｏＴＣＡ規格をベースにしたＰＣアーキテクチャ等の規格をベースにしたＰＣを達成できるようにする。

図３８及び図３９に描かれているビットストリームプロトコルプロセッサの一実施形態は、有利なことに、ビットストリームプロトコルプロセッサに動的なプログラミング及び関数機能性を与えるＲＡＣ／ＳＡＣコントローラを活用する。ＲＡＣ／ＳＡＣコントローラ構造はオンザフライでビットストリームプロトコルプロセッサをプログラムするために使用される。この能力は、ビットストリームプロトコルプロセッサが常駐するブレード（基板）を構成するために使用されてよい。一実施形態では、オンザフライ動的プログラミング機能は、ブレード（基板）をオン、またはオフにするために使用され、それによりブレードを含む、またはコンピュータシステムから取り除く。別の実施形態では、オンザフライ動的プログラミング機能は、それが例えばＳＰＩ４．２及びＰＣＩ−エキスプレス（ＰＣＩ−Ｅｘｐｒｅｓｓ）の間で架橋するようにブリッジの特徴を変更するために使用されてよい。当業者は、他の構成の変更が、ＲＡＣ／ＳＡＣコントローラを使用する本発明の範囲内で影響を及ぼされる可能性があることを認識する。例えば、プログラム可能性は、コンピュータシステムを通した多様なトラフィックフローのために本当のエンドツーエンドＱｏＳを実現するために使用されてよい。

別の実施形態では、ビットストリームプロトコルプロセッサは、優先順位が付けられたスイッチングを可能にする。前記段落のモジュール式のスケーラブルなｐｉｃｏＴＣＡ ＰＣアーキテクチャと連動して、本発明は、Ｎがハードウェアと無関係であるだけではなく、ビットストリームプロトコルプロセッサによって仲介されるファブリック内のプロセッサの異なる部分集合に与えられる優先順位を変えることによって動的に選択可能でもある、マルチプロセッサのＮ層の階層の作成を可能にする。本実施形態により、ＰＣを、メッセージを渡すモデルマルチプロセッサマシンだけではなく、共有メモリモデルマシンとしても構成できるようになる。代わりに、本発明の一実施形態によるＰＣは、サーバ、ストレージエリアネットワークコントローラ、グリッドコンピューティングをベースにしたモデルの中の高性能ネットワークノード、または電気通信ネットワーク内のスイッチ／ルータとして構成されてよい。同じ基本的な機械は、所望されるように、及び所望されるときに、前述された特殊目的のマシンの１台または複数にプログラム的にまたは手動で変換されてよいことが認識される。

方法の多様な変型が本開示を読んだ当業者に明らかとなってよい。前記は、以下の請求項によってのみ制限される本発明の範囲を制限するために意図されていない。

本発明の一実施形態による全プロトコルエンジンの機能ブロック図である。 本発明の一実施形態による全プロトコルエンジンの機能ブロック図である。 図１のＯＰＥの進入データフローのさらに詳細なブロック図である。 図２に示されるような進入データフローの一部として実現されるパケット状態機械の状態図である。 図１のＯＰＥの退出データフローのさらに詳細なブロック図である。 本発明の一実施形態による多段エンジンの初期部分を備えるプリプロセッサパケットフレーミングシステムの概略表現である。 本発明の一実施形態による多段エンジンの初期部分を備えるプリプロセッサパケットフレーミングシステムの概略表現である。 プリプロセッサを実現する本発明によるビットストリーム段階プロセッサの一実施形態のブロック図である。 ＸＧＭＩＩからの一般イーサネット（登録商標）フォーマットとイーサネット（登録商標）の一般フォーマットの概略図である。 ＸＧＭＩＩからの一般イーサネット（登録商標）フォーマットとイーサネット（登録商標）の一般フォーマットの概略図である。 多段ＯＰＥの選択された部分の概略図である。 多段ＯＰＥの選択された部分の概略図である。 多段ＯＰＥの選択された部分の概略図である。 本発明の一実施形態のプログラム可能状態機械の概略図である。 図１２のプログラム可能状態機械のための例示的な拡張可能テーブルである。 図１２のプログラム可能状態機械のための例示的な状態図である。 プログラム可能な復号テーブルのための例示的なテーブルである。 プリプロセッサフレーマの基本関数ブロックのさらに完全な図である。 入力選択を増加する方法、及び状態の中にサブステートを有する能力を描く。 状態機械から出現する出力制御を拡大する方法を描く。 状態機械によって選択できるマスク比較論理を示す。 この状態機械によってプログラムできるであろうイーサネット（登録商標）フローチャートの例である。 本発明の一実施形態による全体的なフロー制御のブロック図である。 ＯＰＥの相互接続段階の動作を監視し、制御するためのＲＡＣ／ＳＡＣの動作を描く概略図である。 本発明による退出装置で遭遇する標準イーサネット（登録商標）フレームの概略図である。 本発明の一実施形態によるプログラム可能状態機械と、マスク及び比較回路の操作構成を描く概略表現である。 本発明の一実施形態によるプログラム可能状態機械と、マスク及び比較回路の操作構成を描く概略表現である。 本発明の一実施形態による例示的なフレーム分類子を概略的に描く。 本発明の例示的な実施形態によるフィードバックループで動作する段階−０と段階−１のエンジンを描く。 フレームプロセッサがＰ−ＳｅｒＤｅｓエンジンとコアエンジンを含む、本発明の特定の実施形態による拡張可能なフレームプロセッサの概略図である。 本発明の全プロトコルエンジンを特長とするＨＰＣポートカードを概略的に描く。 本発明の全プロトコルエンジンを特長とするＨＰＣポートカードを概略的に描く。 本発明の全プロトコルエンジンを特長とするＨＰＣポートカードを概略的に描く。 スイッチング構造を実現するためにサードパーティのＦＰＧＡを使用する例示的なスイッチの実施形態である。 本発明の一般的な実施形態によるスイッチの概略図である。 本発明の特定の実施形態によるＡＴＭＣＡ ｍＴＣＡ ＦＡＴパイプスイッチを描く概略図である。 本発明の特定の実施形態によるＡＴＭＣＡ ｍＴＣＡ ＦＡＴパイプスイッチを描く概略図である。 典型的なプログラミングモデル及び環境である。 典型的なプログラミングモデル及び環境である。 本発明の一次実施形態によるシェルフ管理コントローラ（ＳｈＭＣ）を描くブロック図を示す。 本発明の一次実施形態によるシェルフ管理コントローラ（ＳｈＭＣ）を描くブロック図を示す。 本発明による例示的な１２Ｃハードウェア有限状態機械（ＨＦＳＭ）インプリメンテーションを描く。 多様なインタフェースを使用してデバイス間の架橋の例示的なインプリメンテーションを描くブロック図である。 本発明の一実施形態によるビットストリームプロトコルプロセッサの一実施形態のブロック図を描く。 本発明の一実施形態によるビットストリームプロトコルプロセッサの別の実施形態のブロック図を描く。 本発明の一実施形態によるデータフロー機構のブロック図である。 異なるＯＳＩレベルに関する本発明の抽象化のブロック図である。

Claims (9)

1. プロセッサと、少なくとも毎秒１０Ｇｂの回線速度を有する高速ネットワークファブリック間のデータパケットの通信を管理するための全プロトコルデータパケット処理エンジンであって、
   各進入ビットストリーム段階プロセッサがその進入ビットストリーム段階プロセッサにとって一意のプログラム可能な制御メモリを有する、複数の進入ビットストリーム段階プロセッサと、
   該プロセッサに対する進入プロセッサインタフェースと、
   該ネットワークファブリックに対する進入ネットワークインタフェースと、
   該複数の進入ビットストリーム段階プロセッサと、該進入プロセッサインタフェースと、及び該進入ネットワークインタフェースとに作動可能に接続されているマルチポートデータフローパケットメモリと、
   を含む該データパケット処理エンジンの進入部分と、
   各退出ビットストリーム段階プロセッサがその退出ビットストリーム段階プロセッサにとって一意のプログラム可能な制御メモリを有する、複数の退出ビットストリーム段階プロセッサと、
   該プロセッサに対する退出プロセッサインタフェースと、
   該ネットワークファブリックに対する退出ネットワークインタフェースと、
   該複数の退出ビットストリーム段階プロセッサと、該退出プロセッサインタフェースと、該退出ネットワークインタフェースとに作動可能に接続されているマルチポートデータフローパケットメモリと、
   を含む該データパケット処理エンジンの退出部分と、
   を備え、
   該ビットストリーム段階プロセッサのそれぞれの該制御メモリが１個または複数のデータパケットの既定のデータフローのために決定される複数のプロトコルの内の１つに基づいて個別に選択的に動的にプログラム可能であり、該複数のビットストリーム段階プロセッサによる該既定のデータフローの処理がビットストリームデータの該フローに従って時刻を決められ、該ビットストリームデータの該フローが、実質的に該高速ネットワークファブリックの該回線速度に少なくとも等しい速度で該複数のプロトコルのすべてのための該データパケット処理エンジンの連続動作を可能にする速度で確立されるように、該ビットストリーム段階プロセッサが該マルチポートデータフローパケットメモリを通るビットストリームデータのフローとして該既定のデータフローを処理するデータパケット処理エンジン。
2. 該データパケット処理エンジンの該進入部分のための該複数のビットストリーム段階プロセッサが、
   該進入ネットワークインタフェースの物理層と接続し、該既定のデータパケットのために決定される該複数のプロトコルの該１つに従ってビットストリームデータの該フローのためにフレームを確立する入力段階ビットストリームプロセッサと、
   該既定のデータパケットのために決定される該複数のプロトコルの内の該１つに従って該フレームを構文解析する二次段階状態機械と、
   該二次段階状態機械によって構文解析される該フレームのためのフレーム処理を処理するトラフィック段階プロセッサと、
   該トラフィック段階プロセッサから該フレームの出力を管理するスケジューラ段階プロセッサと、
   該退出プロセッサインタフェースの物理層と、該予定された状態プロセッサからの該フレームを接続する出力段階ビットストリームプロセッサと、
   を備える請求項１に記載のデータパケット処理エンジン。
3. 該二次段階状態機械が、該二次段階状態機械がキールックアップ機構のためのキー発生をパイプライン化するプログラム可能な超長命令語（ＶＬＩＷ）フロー分類子を組み込む該フレームを構文解析するにつれて該キールックアップ機構を活用する請求項２に記載のデータパケット処理エンジン。
4. 該トラフィック段階プロセッサが、該トラフィック段階プロセッサにおける複数のセグメントが該既定データフローのために決定される該複数のプロトコルの該１つに応じて動的に実現される該複数のセグメントを有するデータフロープロセッサとして実現される請求項２に記載のデータパケット処理エンジン。
5. 該ビットストリーム段階プロセッサの少なくとも一部が、該ビットストリーム段階プロセッサのそれぞれが該既定データフローの中の該データのいくらかまたはすべてを、そのデータを処理するためにコピーする必要を排除するために、仲裁された手法または時分割多重化手法の１つを使用して該対応するマルチポートデータフローパケットメモリと接続する請求項１に記載のデータパケット処理エンジン。
6. 該ビットストリーム段階プロセッサのそれぞれの該制御メモリが命令メモリまたは状態メモリの１つから選択可能であり、レジスタアクセス制御（ＲＡＣ）とサブモジュールアクセス制御（ＳＡＣ）システムを使用して個別に選択的に動的に再構成可能であり、プログラム可能である請求項１に記載のデータパケット処理エンジン。
7. 該ＲＡＣ及びＳＡＣシステムが、該データパケット処理エンジンのための符号生成、フロー制御、性能報告、診断及び保守を管理するグラフィックユーザインタフェース（ＧＵＩ）によって制御される請求項６に記載のデータパケット処理エンジン。
8. 該高速ネットワークファブリックが、ストレージネットワーク、通信ネットワーク、プロセッサネットワークまたはその任意の組み合わせから成る集合から選択される請求項１に記載のデータパケット処理エンジン。
9. マルチポート高速データパケットスイッチと、
   をさらに備え、
   複数のデータパケット処理エンジンが、全プロトコルブリッジ機構を形成するために該マルチポートスイッチにそれぞれ作動可能に接続されており、該複数のデータパケット処理エンジンがそれぞれ別のプロトコルを使用して通信する別の高速ネットワークに接続される請求項１に記載のデータパケット処理エンジン。

Images