(57)【特許請求の範囲】
【請求項１】
通信ネットワークをサービスするネットワーク処理環境内に実装されたネットワーク・プロセッサの挙動全体を制御するためのシステムであって、前記ネットワーク処理環境はガイデッド制御フレームを発生するための制御ポイント・サブシステムを含み、前記制御ポイント・サブシステムは前記ネットワーク・プロセッサを制御するために接続された汎用プロセッサ（ＧＰＰ）を含み、前記ネットワーク・プロセッサがパケット分類、パケット修正、キュー／ポリシー管理及びデータパケット転送の１つまたは複数を実施し、
前記システムが、
前記ネットワーク・プロセッサ内に位置するインタフェース・デバイスであって、デバイス制御パラメータ・データを用いて前記ネットワーク・プロセッサ内の様々な機能デバイスを設定するための１つまたは複数の制御機能を含む前記ガイデッド制御フレームを受け取るためのインタフェース・デバイスと、
受け取られた制御フレームからの前記１つまたは複数の制御機能および制御パラメータ・データを、前記ネットワーク・プロセッサ内の設定されるべき機能デバイスに転送する手段と、
前記機能デバイス内に実装された処理手段であって、前記制御フレーム中で指定されたように制御機能を実行するための処理手段であって、それによって前記機能デバイスが前記実行される制御機能およびデバイス制御パラメータ・データに従って制御される、前記処理手段と
を含む、システム。
【請求項２】
前記デバイス制御パラメータ・データが、前記ネットワーク・プロセッサの挙動全体を制御するためのものである、請求項１に記載のシステム。
【請求項３】
受け取られたフレームを解析して、前記制御フレームをどのデバイスにルーティングすべきかを前記フレームから決定するための処理機構をさらに含む、請求項１または２に記載のシステム。
【請求項４】
前記転送する手段が、前記ネットワーク・プロセッサに向けられた制御フレームを前記制御ポイント・サブシステムから受け取るための、かつ制御対象のデバイスによって生成された応答フレームを前記制御ポイント・サブシステムに転送し返すための１つまたは複数のデータ・ムーバ・インタフェースを含む、請求項２に記載のシステム。
【請求項５】
前記ネットワーク・プロセッサが、それぞれフレームを処理することのできる入口側と出口側を含み、前記転送する手段が、前記入口側と出口側の間でフレームを転送するための高速リンクを含む、請求項１ないし４のいずれかに記載のシステム。
【請求項６】
前記転送する手段が、前記ネットワーク・プロセッサ内の設定されるべき前記デバイスに前記制御フレームを転送する、請求項１に記載のシステム。
【請求項７】
前記ネットワーク・プロセッサが、フレームを前記ネットワーク・プロセッサ内の出口側から前記入口側に転送するためのラップ・データ・ムーバ・インタフェースを含む、請求項５に記載のシステム。
【請求項８】
前記ネットワーク処理環境が少なくとも２つのネットワーク・プロセッサを含み、制御フレームが第１のネットワーク・プロセッサにおいて受け取られ、前記制御フレームが、別のネットワーク・プロセッサにあるデバイスを制御するための指示制御機能およびデバイス・パラメータ・データを含み、前記転送する手段が、前記制御フレームを前記第１のネットワーク・プロセッサから前記別のネットワーク・プロセッサに通信する手段を含む、請求項１ないし７のいずれかに記載のシステム。
【請求項９】
前記制御フレームを前記第１のネットワーク・プロセッサから前記別のネットワーク・プロセッサに通信する手段が高速データ・リンクを含む、請求項８に記載のシステム。
【請求項１０】
前記制御ポイント・サブシステムに応答フレームを返す場合に前記ネットワーキング環境内における前記制御ポイント・サブシステムの位置を知るための機構をさらに含む、請求項４に記載のシステム。
【請求項１１】
前記デバイス制御パラメータ・データが、
前記ネットワーク処理環境内における前記ネットワーク・プロセッサのターゲット位置を示すためのデータであって、前記ターゲット位置が前記ネットワーク・プロセッサのアドレス位置を含むデータと、
前記ネットワーク・プロセッサ内で動作するターゲット機能デバイスを含むデータと、
前記ターゲット・ネットワーク・プロセッサ内で動作する前記ターゲット機能デバイスを設定するための制御機能および関連する制御パラメータを含むデータであって、それにより、前記制御機能および関連する制御パラメータを用いて前記ターゲット・ネットワーク・プロセッサ内の前記機能デバイスを設定するために、前記制御フレームを受け取った第１のネットワーク・プロセッサが、制御機能および関連する制御パラメータを機能デバイスに転送することができるように、前記制御フレームを前記ターゲット・ネットワーク・プロセッサに転送する、前記データと
を含む、請求項１に記載のシステム。
【請求項１２】
機能デバイスを設定する間にエラーが発生したときに応答制御フレームを構築する必要があるかどうかを示すためのデータと、
前記フレームが要求制御フレームか応答制御フレームかを示すためのデータとをさらに含む、請求項１１に記載のシステム。
【請求項１３】
前記制御フレームが前記ネットワーク・プロセッサの入口側に向けられているか出口側に向けられているかを示すためのデータをさらに含む、請求項１１または１２に記載のシステム。
【請求項１４】
前記制御フレームが、応答フレームの送り先となるソース・デバイスを示すためのデータをさらに含む、請求項１２に記載のシステム。
【請求項１５】
前記制御フレームが、前記制御フレームから設定される機能デバイスが前記制御フレームを供給する前記制御ポイント・システムのアドレス位置を知るべきかどうかを示すためのデータをさらに含む、請求項１４に記載のシステム。
【請求項１６】
前記ターゲット機能デバイスを設定するための前記制御機能および関連する制御パラメータがユーザによって設定可能である、請求項１４または１５に記載のシステム。
【請求項１７】
通信ネットワークをサービスするネットワーク処理環境内に実装されたネットワーク・プロセッサの挙動全体を制御する方法であって、前記ネットワーク処理環境はガイデッド制御フレームを発生するための制御ポイント・サブシステムを含み、前記制御ポイント・サブシステムは前記ネットワーク・プロセッサを制御するために接続された汎用プロセッサ（ＧＰＰ）を含み、前記ネットワーク・プロセッサがパケット分類、パケット修正、キュー／ポリシー管理及びデータパケット転送の１つまたは複数を実施し、
前記方法が、
ａ）制御ポイント・サブシステムによってガイデッド制御フレームを生成するステップと、
ｂ）デバイス制御パラメータ・データを用いて前記ネットワーク・プロセッサ内の様々な機能デバイスを設定するための１つまたは複数の制御機能を含む前記ガイデッド制御フレームを受け取るステップと、
ｃ）受け取られた制御フレームからの前記１つまたは複数の制御機能および制御パラメータ・データを、前記ネットワーク・プロセッサ内の設定されるべき機能デバイスに転送するステップと、
ｄ）制御フレーム中で指定されたように制御機能を実行し、それによって前記デバイスを設定するステップであって、それによって前記ネットワーク・プロセッサが、前記実行される制御機能およびデバイス制御パラメータ・データに従って制御される、前記設定するステップと
を含む、方法。
【請求項１８】
前記デバイス制御パラメータ・データが、前記ネットワーク・プロセッサの挙動全体を制御するためのものである、請求項１７に記載の方法。
【請求項１９】
受け取ったフレームを解析して、前記制御フレームをどのデバイスにルーティングすべきかを前記フレームから決定するステップをさらに含む、請求項１７または１８に記載の方法。
【請求項２０】
前記ネットワーク・プロセッサが１つまたは複数のデータ・ムーバ・インタフェースを含み、前記受け取るステップが、前記ネットワーク・プロセッサに向けられた制御ポイントを、データ・ムーバ・インタフェースを介して前記制御ポイント・サブシステムから受け取ることを含む、請求項１８に記載の方法。
【請求項２１】
前記制御フレーム中に指定されたように制御機能を実行する前記ステップの間に、または制御機能を実行するのに応答して、
前記ネットワーク・プロセッサ内の前記機能デバイス内で応答フレームを構築するステップと、
前記応答フレームを前記制御ポイント・サブシステムに転送し返すステップとを含む、請求項２０に記載の方法。
【請求項２２】
前記ネットワーク・プロセッサが、それぞれフレームを処理することのできる入口側と出口側を含み、前記転送するステップが、前記入口側と出口側の間で高速データ・リンクを介してフレームを転送するステップをさらに含む、請求項１７ないし２１のいずれかに記載の方法。
【請求項２３】
前記転送するステップが、前記ネットワーク・プロセッサ内の設定されるべき前記デバイスに転送するために前記制御フレームをキューに入れるステップを含む、請求項１７に記載の方法。
【請求項２４】
前記ネットワーク・プロセッサがラップ・データ・ムーバ・インタフェースを含み、前記転送するステップが、前記ラップ・インタフェースを介してフレームを前記出口側から前記入口側にラップするステップをさらに含む、請求項２２に記載の方法。
【請求項２５】
前記ネットワーク処理環境が少なくとも２つのネットワーク・プロセッサを含み、制御フレームが第１のネットワーク・プロセッサにおいて受け取られ、前記制御フレームが、別のネットワーク・プロセッサにあるデバイスを制御するための指示制御機能およびデバイス・パラメータ・データを含み、前記転送するステップが、前記制御フレームを前記第１のネットワーク・プロセッサから前記別のネットワーク・プロセッサに通信するステップをさらに含む、請求項１７ないし２４のいずれかに記載の方法。
【請求項２６】
前記通信するステップが高速データ・リンクを介して行われる、請求項２５に記載の方法。
【請求項２７】
前記機能デバイス内で応答フレームを構築する前記ステップが、前記制御ポイント・サブシステムに応答フレームを返す場合に前記ネットワーキング環境内における前記制御ポイント・サブシステムの位置を知るステップをさらに含む、請求項２１に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は一般にネットワーク・プロセッサ・デバイスに関し、より詳細には、ネットワーク・プロセッサの挙動全体を規定および制御するための改良型の方法に関する。
【０００２】
【従来の技術】
今日のネットワーク世界では、帯域幅がクリティカルなリソースである。インターネットおよび新しく現れるその他の用途によって押し上げられるネットワーク・トラフィックの増加は、ネットワーク・インフラストラクチャの容量に過大な負担をかけている。組織は、遅れをとらないように、トラフィック増加および音声とデータとの収束をサポートし管理するためのよりよい技術および方法を求めている。
【０００３】
今日のネットワーク・トラフィックの劇的な増加は、インターネットの普及、情報へのリモート・アクセスの必要性の増大、および新しく現れる用途に起因すると考えることができる。インターネットだけでも、電子商取引におけるその爆発的な成長に伴い、時としてサポート不可能な場合もある負荷をネットワーク・バックボーンに課してきた。インターネットはまた、音声トラフィックを初めて上回るデータ・トラフィック量の増加に対する唯一の最も重要な原因でもある。ｅメール、データベース・アクセス、ファイル転送を含めたリモート・アクセス用途の需要の増加が、さらにネットワークに過大な負担をかけている。
【０００４】
音声とデータの収束は、将来のネットワーク環境を規定する上で大きな役割を果たすであろう。現在、インターネット・プロトコル（ＩＰ）ネットワークを介したデータ伝送は、国によっては無料である。音声通信は当然ながら最低コストの道を辿ることになるので、音声は必然的にデータと収束するであろう。この変化しつつある市場では、ボイス・オーバーＩＰ（ＶｏＩＰ）、ボイス・オーバーＡＴＭ（ＶｏＡＴＭ）、ボイス・オーバー・フレーム・リレー（ＶｏＦＲ）などの技術が、コスト効果の高い代替技術である。しかし、これらの技術への移行を可能にするには、産業は、音声に対するサービス品質（ＱｏＳ）を保証し、データ回線を介した音声伝送にどのように課金するかを決定しなければならない。１９９６年の米国の電気通信自由化法令が、この環境をさらに複雑なものにしている。この法律は、好まれる音声プロトコルであるＡＴＭと好まれるデータ・プロトコルであるＩＰとの共存関係を強化することになる。
【０００５】
新しい製品および機能が利用可能になるので、レガシー・システムの統合もまた、組織にとって非常に重大な問題である。既存の装置およびソフトウェアに対する組織の投資を存続させるために、組織は、現在の操業を絶つことなく新しい技術に移行することを可能にする解決法を必要とする。
【０００６】
ネットワーク・ボトルネックをなくすことは、サービス・プロバイダにとって最も高い優先順位であり続けている。これらのボトルネックの原因はルータであることが多い。しかし、一般にネットワーク輻輳は、しばしば帯域幅の問題として誤診され、より広い帯域幅の解決法を探すことによって対処される。今日、製造業者はこの難題を認識し始めている。彼らは、帯域幅リソースをより効率的に管理し、かつルータおよびネットワーク・アプリケーション・サーバによくみられる高度なデータ・サービスをワイヤ速度で提供する、ネットワーク・プロセッサ技術に目を向けつつある。これらのサービスには、負荷平衡、ＱｏＳ、ゲートウェイ、ファイアウォール、セキュリティ、およびウェブ・キャッシングが含まれる。
【０００７】
リモート・アクセス用途では、性能、オンデマンドの帯域幅、セキュリティ、および認証が最も高い優先順位を占める。ＱｏＳとサービス・クラス（ＣｏＳ）との統合、統合音声処理、およびより複雑なセキュリティ解決法に対する需要もまた、将来のリモート・アクセス・ネットワーク・スイッチの設計を形作ることになる。さらにリモート・アクセスは、ＩＳＤＮ、Ｔ１、Ｅ１、ＯＣ−３〜ＯＣ−４８、ケーブル、ｘＤＳＬモデムなど、増え続ける物理媒体に対応しなければならないであろう。
【０００８】
産業コンサルタントは、ネットワーク・プロセッサ（本明細書では「ＮＰ」とも言う）を、以下の機能の１つまたは複数を実施することのできるプログラム可能な通信集積回路と定義している。
パケット分類−アドレスやプロトコルなど、認められる特性に基づいてパケットを識別する。
パケット修正−ＩＰ、ＡＴＭ、またはその他のプロトコルに適合するようにパケットを修正する（例えばＩＰ用のヘッダ中の存続時間（time-to-live）フィールドを更新する）。
キュー／ポリシー管理−パケット・キューイング、デキューイング、およびパケットのスケジューリングに関する設計戦略を特定の用途に向けて反映する。
パケット転送−スイッチ・ファブリックを介してデータを送受信し、パケットを適切なアドレスにルーティングする。
【０００９】
この定義は初期のＮＰの基本的な特徴を正確に述べているものの、ＮＰの完全な潜在的能力および利点はまだ実現されていない。ネットワーク・プロセッサは、以前はソフトウェア中で対処されていたネットワーキング・タスクをハードウェア中で実行できるようにすることにより、帯域幅を増加させ、広範な用途における待ち時間の問題を解決することができる。さらにＮＰは、並列分散処理やパイプライン処理設計などのアーキテクチャにより、速度向上をもたらすこともできる。これらの能力は、効率的な探索エンジンを可能にし、スループットを向上させ、複雑なタスクの高速実行を実現することができる。
【００１０】
ネットワーク・プロセッサは、ＣＰＵがＰＣにとって根本的な構成要素であるのと同じ形で、ネットワークにとって根本的な構成要素になると予想される。ＮＰによって提供される代表的な能力は、リアルタイム処理、セキュリティ、蓄積交換、スイッチ・ファブリック・インタフェース、ならびにＩＰパケット処理および学習の能力である。ＮＰは、ＩＳＯレイヤ２から５までを対象とし、ネットワーク特有のタスクを最適化するように設計される。
【００１１】
プロセッサモデルＮＰは、複数の汎用プロセッサおよび特殊化ロジックを組み込む。供給業者は、コスト効果の高い形で適時に変化に対応できるスケーラブルかつフレキシブルな解決法を提供するために、この設計に目を向け始めている。プロセッサモデルＮＰは、統合レベルのより低い分散処理を可能にし、より高いスループット、フレキシビリティ、および制御をもたらす。プログラム可能性により、新しいＡＳＩＣ設計を必要とせずに新しいプロトコルおよび技術に容易に移行することができる。
【００１２】
【発明が解決しようとする課題】
ネットワーク・プロセッサの挙動全体を規定および制御するためのデータ構造および方法は、ＮＰベースのデバイスの設計および実装に見合ったものである。本発明は、このデータ構造および方法を対象とする。
【００１３】
【課題を解決するための手段】
したがって本発明は、通信ネットワークをサービスするネットワーク処理環境内に実装されたネットワーク・プロセッサの挙動全体を制御するためのシステムを提供する。このシステムは、前記ネットワーク・プロセッサ内に位置するインタフェース・デバイスであって、デバイス制御パラメータ・データを用いて前記ネットワーク・プロセッサ内の様々な機能デバイスを設定するための１つまたは複数の制御機能を含む前記ガイデッド制御フレームを受け取るためのインタフェース・デバイスと、受け取られた制御フレームからの前記１つまたは複数の制御機能および制御パラメータ・データを、前記ネットワーク・プロセッサ内の設定されるべき機能デバイスに転送する手段と、前記機能デバイス内に実装された処理手段であって、前記制御フレーム中で指定されたように制御機能を実行するための処理手段であって、それによって前記機能デバイスが前記実行される制御機能およびデバイス制御パラメータ・データに従って制御される、前記処理手段とを含む。
【００１４】
好ましい一実施形態によれば、ネットワーク環境で制御ポイント・プロセッサ（ＣＰ）として働く汎用プロセッサ（ＧＰＰ）がネットワーク・プロセッサ（ＮＰ）の挙動全体を規定および制御できるようにするための機能をもたらすシステムおよび方法が提供される。
【００１５】
さらに、ネットワーク環境で制御ポイント・プロセッサ（ＣＰ）として働く汎用プロセッサ（ＧＰＰ）がネットワーク・プロセッサ（ＮＰ）の挙動全体を規定および制御して、ＮＰ内で稼動するフレーム転送アプリケーションに対するサポート機能を提供できるようにするための機能をもたらす方法が提供されることが好ましい。
【００１６】
好ましい一実施形態によれば、新規な制御フレーム・データ構造および通信インフラストラクチャが実装され、それにより、分散ネットワーク処理環境で動作する任意のネットワーク・プロセッサ・デバイスを、実行される制御機能およびデバイス制御パラメータ・データに従って制御することができる。制御に特に的を絞ったネットワーク・プロセッサ・デバイス内の機能ユニットは、ハードウェア・ガイデッド・フレーム・ハンドラ（ＧＦＨ）デバイスと、ハードウェア・ガイデッド・テーブル・ハンドラ（ＧＴＨ）デバイスによって制御されるフレーム転送アプリケーションとを含むことが好ましい。
【００１７】
有利にも、このシステムおよび方法は、ネットワーク処理環境における１次ブレード上でのガイデッド・フレーム・フロー、２次ブレード上でのガイデッド・フレーム・フロー、および複数ブレード上でのガイデッド・フレーム・フローを含めて、通常のＮＰシステムを通る種々の可能なフローにおいて制御フレーム（ガイデッド・フレーム・フロー）を扱い処理することができるのが好ましい。
【００１８】
他の態様では、本発明は、ネットワーク処理環境内に実装されたネットワーク・プロセッサ・デバイスに通信される制御フレームのためのデータ構造を提供する。このデータ構造は、前記ネットワーク処理環境内における前記ネットワーク・プロセッサのターゲット位置を示すためのデータであって、前記ターゲット位置が前記ネットワーク・プロセッサのアドレス位置を含むデータと、前記ネットワーク・プロセッサ内で動作するターゲット機能デバイスを含むデータと、前記ターゲット・ネットワーク・プロセッサ内で動作する前記ターゲット機能デバイスを設定するための制御機能および関連する制御パラメータを含むデータであって、それにより、前記制御機能および関連する制御パラメータを用いて前記ターゲット・ネットワーク・プロセッサ内の前記機能デバイスを設定するために、前記制御フレームを受け取った第１のネットワーク・プロセッサが、制御機能および関連する制御パラメータを機能デバイスに転送することができるように、前記制御フレームを前記ターゲット・ネットワーク・プロセッサに転送する、前記データを含む。
【００１９】
他の態様では、本発明は、信ネットワークをサービスするネットワーク処理環境内に実装されたネットワーク・プロセッサの挙動全体を制御する方法を提供する。この方法は、
ａ）制御ポイント・サブシステムによってガイデッド制御フレームを生成するステップと、
ｂ）デバイス制御パラメータ・データを用いて前記ネットワーク・プロセッサ内の様々な機能デバイスを設定するための１つまたは複数の制御機能を含む前記ガイデッド制御フレームを受け取るステップと、
ｃ）受け取られた制御フレームからの前記１つまたは複数の制御機能および制御パラメータ・データを、前記ネットワーク・プロセッサ内の設定されるべき機能デバイスに転送するステップと、
ｄ）制御フレーム中で指定されたように制御機能を実行し、それによって前記デバイスを設定するステップであって、それによって前記ネットワーク・プロセッサが、前記実行される制御機能およびデバイス制御パラメータ・データに従って制御される、前記設定するステップと
を含む。
【００２０】
次に、本発明の実施形態を、図例を参照しながら単に例として述べる。
【００２１】
【発明の実施の形態】
図１に、ネットワーク（図示せず）にサービスするための１つまたは複数のネットワーク・プロセッサ（「ＮＰ」）インタフェース・デバイス１５ａ、ｂを実装した例示的なネットワーク・プロセッサ（ＮＰ）処理環境１０を一般に示す。
【００２２】
図１に示す例示的なＮＰ処理環境１０を参照すると、第１のＮＰインタフェース・デバイス１５ａは１次ブレード（すなわちプリント回路板要素）２０ａ上に設けられ、第２のＮＰインタフェース・デバイス１５ｂは２次ブレード２０ｂ上に設けられている。このシステムは、多くのブレード（１次および２次（複数の２次））ならびに制御ポイント（「ＣＰ」）サブシステムを、例えば分散ネットワーク構成で含むように拡張することもできることを理解されたい。制御ポイント・サブシステム（「ＣＰ」）５０は、ＮＰ環境構成に接続されたシステム・プロセッサ５２を含む。ＣＰにあるシステム・プロセッサは、とりわけシステム制御フレームを発行することによってＮＰインタフェース・デバイスに初期化および設定サービスを提供することが好ましく、本明細書ではこのシステム制御フレームを「ガイデッド・フレーム」と呼ぶ。ＣＰ５０は、３つの位置、すなわちインタフェース・デバイス・チップ内と、チップが（図１に示すように）上に装着されているブレード上と、ブレード外部とのいずれかに位置することができる。ブレード外部の場合は、ＣＰはリモートとすることができる。すなわちＣＰは、どこか他の場所に収納され、インタフェース・デバイスとＣＰ５０とを接続するネットワークを介して通信する。一般にＣＰの要素には、プロセッサ５２、メモリ素子（キャッシュ、フラッシュ、およびＳＤＲＡＭ）、メモリ・コントローラ、ＰＣＩバス、バックプレーン用およびＬ１ネットワーク媒体用のコネクタが含まれる。
【００２３】
本明細書でより詳細に述べるが、好ましい実施形態では、ガイデッド・フレームは、以下の情報を含む可変ワード構造である。すなわち、１）フレームがどのブレードのためのものか、およびブレード内のどの機能ブロックに送るべきかを示すためのデータを含むフレーム制御情報、２）エラーまたは例外が発生した場合、あるいはフレーム処理が成功した場合に、応答フレームがあればどこに送るべきかをフレーム中で示すための相関関係子情報、３）ブレード内の機能ユニットを制御または管理する制御オペランドを含むガイデッド・コマンド、４）フレームの終了を示す終了区切りコマンドである。これらのそれぞれについては、図１６を参照しながらより詳細に論じる。
【００２４】
図１に示すように、各ＮＰインタフェース・デバイスは組込みプロセッサ・コンプレックス（ＥＰＣ）１６を備え、ＥＰＣ１６は２つの機能サブアセンブリを有する。すなわち、ＮＰシステム１０によってサービスされる外部ネットワークからの、ネットワーク・プロトコル特有のデータ・ムーバ・インタフェース（ＤＭ）２４ａ、ｂを介したデータを受信／処理するための入口（アップサイド）サブシステム２６ａと、ＮＰシステム１０によってサービスされるネットワークにネットワーク・プロトコル特有のデータ・ムーバ・インタフェース（ＤＭ）２４ｃ、ｄを介して出て行くデータを送信するための出口（ダウンサイド）サブシステム２６ｂである。同じＮＰインタフェース・デバイス内の入口から出口に渡されるフレームはすべて、ＤＡＳＬ（Data Align Synchronous Link）インタフェース４５ａ〜４５ｄを介して渡される。高データ・フロー・レートをサポートする他の同等タイプのインタフェース／リンクを実装することもできることを理解されたい。出口側２６ｂからプロセッサの入口側２６ａに内部で通信して戻す必要のあるフレームは、データ・ムーバ・ラップ（ＤＭ＿Ｗ）２５を介して通信することができる。
【００２５】
一般に、ＮＰインタフェース・デバイスの入口サブアセンブリ２６ａは、組込みガイデッド・フレーム・ハンドラ・ユニット１８（ＧＦＨ）および１つまたは複数のジェネラル・データ・ハンドラ（ＧＤＨ）プロセッシング・ユニット１７ａを備え、各ＧＤＨプロセッシング・ユニット１７ａは、受信フレームを分類して、フレームをどこに転送するか調べるためにルックアップを行うように機能する。ＮＰインタフェース・デバイスの出口サブアセンブリ２６ｂもまた、組込みガイデッド・フレーム・ハンドラ・ユニット１８ａ（ＧＦＨ）および１つまたは複数のクラシファイア／ルックアップ・プロセッサ１７ｂを備え、各クラシファイア／ルックアップ・プロセッサ１７ｂは、フレーム送信前に必要なら何らかのアウトバウンド修正またはルックアップを行うように機能する。出口サブアセンブリ２６ｂはさらに、ガイデッド・テーブル・ハンドラ・ユニット１９（ＧＴＨ）も備える。ＮＰプロセッサ・デバイス内では、受信されるデータ・トラフィックはすべて、本明細書でガイデッド・データ・ハンドラ（ＧＤＨ）と呼ぶ特別なクラシファイア／ルックアップ・プロセッサによって対処し、ＮＰシステム１０を管理するのに使用される制御情報は、本明細書でより詳細に述べるように、ガイデッド・フレーム・ハンドラ（ＧＦＨ）１８によって対処する。フレーム転送プロセスでは、ガイデッド・テーブル・ハンドラ（ＧＴＨ）１９が転送テーブルを実装する。
【００２６】
図１を参照すると、ＮＰインタフェース・デバイスにおいて受信されたパケットまたはフレームの一般的なフローは次のとおりである。ネットワーク、例えばＥｔｈｅｒｎｅｔ（Ｒ）ＭＡＣから受信されたフレームは、データ・ムーバ・インタフェース（ＤＭ）２４ａ、２４ｂにおいて受け取られ、そこで通常のデータ・フレームとして識別されるか、または制御プロセッサ（ＣＰ）システム５０から受信されたシステム制御フレーム（ガイデッド・フレーム）として識別される。ガイデッド・フレームはまず、一般に組込みプロセッサ・コンプレックス（ＥＰＣ）のキューに入れられる。ＥＰＣは、受信フレームのヘッダを見てそのフレームをどうするか（転送、修正、フィルタリングなど）を決定することのできるロジック（ピココード）を実行する複数のピコプロセッサ、例えばプロトコル・プロセッサを備える。ＥＰＣは、いくつかのルックアップ・テーブルにアクセスすることができ、分類ハードウェアが、ネットワーク・プロセッサの広帯域幅要件にピコプロセッサがついていけるようにアシストする。周知のフレーム・フォーマットのフレームを分類するために、分類ハードウェア・アシスト・デバイスが設けられる。組込みプロセッシング・コンプレックス（ＥＰＣ）は、ＮＰデバイス・チップのプログラム可能性を提供および制御し、コンポーネント（メモリ、ディスパッチャ、ＤＭインタフェースなど）の中でもとりわけ、共通の命令メモリに記憶されたピココードを同時に実行する１つまたは複数のプロセッシング・ユニットを備える。各プロセッシング・ユニットは、例えば３段パイプラインと汎用レジスタとＡＬＵとを含むＣＬＰプロセッシング・ユニット・コアを備えることが好ましい。動作に際しては、フレーム・ディスパッチ中に、分類ハードウェア・アシスト・デバイスからの分類結果が１つまたは複数のプロセッシング・ユニットに渡される。プロセッシング・ユニットの１つは特に、ジェネラル・データ・ハンドラ（ＧＤＨ）と呼び、これは完全なＣＬＰプロセッシング・ユニットおよび５つのコプロセッサを備え、主にフレームを転送するのに使用される。Ｎ個のプロトコル・プロセッサのうち少なくとも２つは特殊化され、１つはガイデッド・フレームを扱うためのガイデッド・フレーム・ハンドラＧＦＨ１８であり、もう１つは制御メモリ中にルックアップ・データを構築するためのガイデッド・テーブル・ハンドラＧＴＨ１９である。
【００２７】
好ましい実施形態では、ガイデッド・フレームに分類されたフレームはすべて、そのフレームを受け取っているブレード上のＧＦＨの入口キューに入れられる。図２に、ガイデッド・フレーム・ハンドラＧＦＨユニット１８の一般的な機能レイアウトを示す。ＧＦＨ１８は、ガイデッド・フレームの解析およびルーティングの機能を実施することを担うガイデッド・フレーム・プロセッサ１８１と、ガイデッド・フレーム中のガイデッド「コマンド」を解釈して、それらのコマンドが処理されるようにすることを担うガイデッド・コマンド・プロセッサ１８２とを含むソフトウェア・コンポーネントを実装したハードウェア・デバイスであることが好ましい。ガイデッド・フレーム・プロセッサ１８１は、ガイデッド・フレームを受け取って処理し、また、ガイデッド要求フレームを妥当性検査して、受け取ったフレームをＧＦＨが処理できるかどうかを決定することを担う。また、送信側によって必要とされる肯定応答（もしあれば）のタイプも決定する。ガイデッド・フレーム・プロセッサ１８１はさらに、処理すべき第１のガイデッド・コマンドを見つけるまで要求フレームをざっと調べ、次いでガイデッド・コマンド・プロセッサ１８２に制御を渡す。コマンドが完了すると、制御はガイデッド・フレーム・プロセッサ１８１に戻される。そうでない場合は、ガイデッド・コマンド・プロセッサがエラーを返すまで、またはEnd_Delimiterコマンドがみられるまで、ガイデッド・コマンド・プロセッサはフレームの各ガイデッド・コマンドを処理する。この時点で、フレーム処理は完了したと見なされる。
【００２８】
ガイデッド・コマンド・プロセッサは、ガイデッド要求フレーム中に組み込まれたガイデッド・コマンドを処理することを担う。これは、コマンドが見つかる場所である要求フレーム中の位置への参照と共に、ガイデッド・フレーム・プロセッサから呼び出される。ガイデッド・コマンド・プロセッサは、コマンド識別子を解析して、コマンドを処理できるかどうか決定する。指定されたコマンドがサポートされない場合は、フレーム・パーサにエラーが返される。そうでなければ、本明細書に述べるようにして、図２に示すブロック１８５の適切な機能ブロックに制御が転送され、この機能ブロックが実際にコマンドにサービスする。
【００２９】
図３に、ＧＴＨユニット１９の機能レイアウトを示す。ＧＴＨアーキテクチャは、遊休状態でありガイデッド要求フレームがＧＴＨキュー中で利用可能であることがＮＰディスパッチャにわかったときにディスパッチされる。着信フレームがガイデッド・フレーム・プロセッサ１９１によって妥当性検査され、コマンド処理のために制御がガイデッド・コマンド・プロセッサ１９２に渡されるという点で、ＧＴＨはＧＦＨと同様の仕方で機能する。図３に示すように、ＧＴＨ内に含まれるサービス・ブロック１９５は、ＧＦＨに含まれる機能ブロックとは異なる動作を行う。しかし、ガイデッド・フレームの目的は、図２および３に示す各動作ブロックを実際に管理および制御することであることを理解されたい。
【００３０】
続いて、ＮＰインタフェース・デバイスの挙動を制御および管理するための例示的なＧＦＨメッセージ・フロー・シナリオについて詳細に述べる。図４および５に示す第１の例には、ＣＰサブシステム５０と１次ブレード２０ａ上のガイデッド・フレーム・ハンドラ（ＧＦＨ）１８との間のメッセージ・フローを含む例示的なシナリオ２００が示されている。
【００３１】
図４に示す例示的なシナリオ２００では、ガイデッド「要求」フレームは、１次ブレードの入口ＧＦＨに向けられた組込みガイデッド・コマンドを含む。ＧＦＨは、ガイデッド要求を次のように処理する。第１のステップで、ガイデッド・フレームはＣＰ５０によって生成され、１次ブレード２０に送られる。このシナリオでは、フレームは、応答が必要であることを示すビットを含むものとする。フレームは、１次ブレード２０ａ上の入口ＧＦＨによって受け取られて解析される。解析結果は、フレームがそれ自体に向けられていることを示す。したがって、組込みガイデッド・コマンドは入口ＧＦＨによって処理され、具体的にはガイデッド・コマンド・プロセッサによって実行される。処理が成功したと仮定した場合、結果はフレームに記憶され、フレームが今や「応答」フレームであることを示すようにフレーム制御情報が修正される。次いで、１次ブレードに対応するターゲット・ブレード・アドレスと共に入口キュー（図示せず）に入れられ、ＤＡＳＬインタフェース４５ａ、ｂを介して１次ブレード２０ａの出口ＧＦＨに送られる。次いで出口ＧＦＨ１８ａは、フレームを解析し、フレームが応答フレームであることを認め、適切な出口キュー（図示せず）に入れる。これによりフレームは、例えばＤＭ２４ａなどのＤＭインタフェースを通して、ＣＰ５０に接続されたインタフェースを介して送ることができ、最終的にはＣＰ５０が応答フレームを受け取る。
【００３２】
図４に示したシナリオ２００に対する代替シナリオでは、ガイデッド「要求」フレームは、１次ブレードの出口ＧＦＨに向けられた組込みガイデッド・コマンドを含む。このシナリオでは、ガイデッド・フレームは、ＣＰ５０によって生成されて１次ブレードに送られ、またフレームは、応答が必要であることを示すビットを含むものとする。フレームは、１次ブレード上の入口ＧＦＨによって受け取られて解析される。この場合、解析結果は、フレームが出口ＧＦＨに向けられていることを示す。したがってフレームは、ターゲット・ブレードを１次ブレードに設定されて入口キューに入れられ、ＤＡＳＬインタフェース４５ａ、ｂを介して１次ブレード２０ａの出口ＧＦＨに送られる。次いで出口ＧＦＨは、フレームを解析し、フレームがそれ自体に向けられていることを決定する。したがって、フレームを処理して応答フレームを構築する。応答フレームが構築された後、応答フレームは適切な出口キューに入れられ、次いで出口キューは、ＣＰに接続されたインタフェースにＤＭインタフェースを介して応答フレームが送出されるようにする。
【００３３】
図５に示す例示的なシナリオ２１０では、ガイデッド「要求」フレームはジェネラル・データ・ハンドラ（ＧＤＨ）によって内部で生成され、１次ブレード上の入口ＧＦＨ１８に向けられた組込みガイデッド・コマンドを含む。ＧＦＨは、ガイデッド要求を次のように処理する。第１のステップで、１次ブレード上の入口ＧＤＨが、同じブレード上の入口ＧＦＨに向けたガイデッド・フレームを構築し、このフレームは入口ＧＦＨキューに入れられる。フレームは入口ＧＦＨによって受け取られ、フレーム処理の間に、フレームがそれ自体に向けられていることが決定される。したがって、入口ＧＦＨはこのフレームを処理する。処理中にエラーがみられなかったと仮定した場合、フレームは、応答フレームが必要であることを示すビット標識がなかったときは、処理された後で入口廃棄キューに入れられる。エラーがみられ、かつフレーム・ヘッダ中のビットが否定応答の必要を示す場合は、否定応答フレームが構築され、出口ＧＦＨ１８ａにディスパッチされるように入口キューに入れられる。応答フレームが出口ＧＦＨによって受け取られると、出口ＧＦＨはフレーム・ヘッダを調べ、応答フレームであることを知り、したがって、ＣＰ５０にディスパッチするために適切な出口キューに入れる。ＣＰ５０で、否定応答フレームの応答フレームが受け取られる。
【００３４】
図５に示したシナリオ２１０に対する第１の代替シナリオでは、ガイデッド「要求」フレームはジェネラル・データ・ハンドラ（ＧＤＨ）によって内部で生成され、１次ブレード上の出口ＧＦＨ１８ａに向けられた組込みガイデッド・コマンドを含む。このシナリオでは、１次ブレード上の入口ＧＤＨ２０が、出口ＧＦＨに向けたガイデッド・フレームを構築する。このフレームを構築することのできる場所が２つあることが好ましい。すなわち、１）入口データ・ストア上、および２）出口データ・ストア上である。フレームが入口データ・ストア上で構築される場合、入口ＧＤＨは、フレームを入口ＧＦＨキューに入れる。入口ＧＦＨは、フレームを受け取って解析する。フレームは出口ＧＦＨに向けられていることを示すので、入口ＧＦＨは、ターゲット・ブレードを１次ブレードに設定してフレームを入口キューに入れ、ＤＡＳＬインタフェース４５ｃ、ｄを介して１次ブレードの出口ＧＦＨ１８ａに送る。あるいは、ターゲット・ブレードを１次ブレードに設定して、ＧＤＨが直接にフレームを入口キューに入れることもできる。しかし、フレームが出口データ・ストア上で構築される場合は、入口ＧＤＨは、フレームが出口ＧＦＨによって受け取られて処理されるように、フレームを出口ＧＦＨキューに入れる。エラーがみられなかったと仮定した場合、フレームは、処理された後で出口廃棄キューに入れられる。エラーがみられ、かつフレーム・ヘッダが否定応答の必要を示すビットを含んでいた場合は、否定応答フレームが構築されて、適切な出口インタフェース・キューに入れられ、したがって最終的にはＤＭインタフェースを介してＣＰ５０によって受け取られる。
【００３５】
図５に示したシナリオ２１０に対する第２の代替シナリオでは、ガイデッド「要求」フレームは１次ブレード上の出口ＧＤＨ２０ａによって内部で生成され、１次ブレード上の出口ＧＦＨ１８ａに向けられた組込みガイデッド・コマンドを含む。このシナリオでは、１次ブレード上の出口ＧＤＨ２０ａが、出口データ・ストアを使用して、１次ブレード上の出口ＧＦＨに向けたガイデッド要求フレームを構築する。したがって、出口ＧＤＨはフレームを出口ＧＦＨキューに入れ、フレームは出口ＧＦＨによって受け取られて処理される。処理が成功したと仮定した場合、フレームは出口廃棄キューに入れられる。しかし、エラーがみられ、かつフレームが否定応答の必要を示していた場合は、否定応答フレームが構築されて、適切な出口インタフェース・キューに入れられ、したがって最終的にはＤＭインタフェースを介してＣＰ５０によって受け取られる。
【００３６】
図５に示したシナリオ２１０に対する第３の代替シナリオでは、ガイデッド「要求」フレームは１次ブレード上の出口ＧＤＨ２０ａによって内部で生成され、１次ブレード上の入口ＧＦＨ１８に向けられた組込みガイデッド・コマンドを含む。このシナリオでは、１次ブレード上の出口ＧＤＨは、出口データ・ストアと入口データ・ストアのいずれかの場所で、入口ＧＦＨに向けたガイデッド・フレームを構築する。フレームが出口データ・ストア上で構築される場合は、出口ＧＤＨは、フレームが入口ＧＦＨに到達できるようにするラップＤＭキュー２５にフレームを入れる。そうではなく、フレームが入口データ・ストア上で構築される場合は、出口ＧＤＨは、フレームが入口ＧＦＨに到達するように入口ＧＦＨキューにフレームを入れ、フレームは入口ＧＦＨによって受け取られて処理される。エラーがみられなかったと仮定した場合、フレームは、処理された後で入口廃棄キューに入れられる。エラーがみられ、フレームが否定応答の必要を示していた場合は、否定応答フレームが構築され、出口ＧＦＨによって受け取られるようにターゲット・ブレードを１次ブレードに設定されて入口キューに入れられる。フレームは出口ＧＦＨで解析される。フレームは応答フレームであることを示すので、出口ＧＦＨは、フレームを適切な出口ターゲット・ポート・キューに入れ、したがってフレームは、最終的にはＤＭインタフェースを介してＣＰ５０によって受け取られる。
【００３７】
図６および７に示す第２の例には、ＣＰサブシステム５０と２次ブレード上のガイデッド・フレーム・ハンドラ（ＧＦＨ）１８との間のメッセージ・フローを含む例示的なシナリオが示されている。
【００３８】
図６に示す例示的なシナリオ２２０では、ガイデッド「要求」フレームは、２次ブレード２０ｂ上の出口ＧＦＨに向けられた組込みガイデッド・コマンドを含む。ＧＦＨは、ガイデッド要求を次のように処理する。第１のステップで、ガイデッド・フレームはＣＰによって生成され、１次ブレードに送られる。この例示的なシナリオでは、フレーム制御情報は、フレームが２次ブレード上にある出口ＧＦＨをターゲットにしていることを示すビットと、応答が必要であることを示すビットを含むものとする。フレームは、１次ブレード２０ａ上の入口ＧＦＨ１８によって受け取られて解析される。解析の結果、フレームが２次ブレード２０ｂ上の出口ＧＦＨ１８ｃに向けられていることが決定される。したがってフレームは、ターゲット・ブレード上にある出口ＧＦＨにディスパッチされるように、ターゲット・ブレード・アドレスを適切に設定されて入口キューに入れられる。出口ＧＦＨ１８ｃは、フレームを受け取ると、フレームを解析し、フレームがそれ自体に向けられていることを決定する。出口ＧＦＨは、要求フレームを処理し、応答フレームを構築する。次いで出口ＧＦＨは、応答をラップ・キューＤＭ２５に入れることにより、同じブレード上の入口ＧＦＨ１８ｂコンポーネントに応答を送る。入口ＧＦＨフレーム１８ｂは、解析動作を実施し、フレームが応答フレームであることを決定する。したがって、ターゲット・ブレード・アドレスを１次ブレード２０ａのアドレスに設定した後で入口キューにフレームを入れることにより、フレームはＣＰ５０にルーティングされる。したがってフレームは、ＤＡＳＬインタフェース４５ｃを介して１次ブレード上の出口ＧＦＨ１８ａによって受け取られ、そこで解析される。フレーム制御情報はフレームが応答フレームであることを示すので、出口ＧＦＨ１８ａは、フレームを適切な出口インタフェース・キューに入れる。これによりフレームは、例えばＤＭ２４ａなどのＤＭインタフェースを通して、ＣＰ５０に接続されたポートを介して送ることができ、最終的にはＣＰ５０が応答フレームを受け取る。
【００３９】
図６に示したシナリオ２２０に対する代替シナリオでは、ガイデッド「要求」フレームは、入口ＧＦＨ１８ｂに向けられた組込みガイデッド・コマンドを含む。このシナリオでは、ガイデッド・フレームはＣＰ５０によって生成され、まず１次ブレードに送られる。フレーム制御情報は、フレームが２次ブレード上にある入口ＧＦＨ１８ｂをターゲットにしていることを示すビットと、応答が必要であることを示すビットを含むものとする。したがってフレームは、１次ブレード２０ａ上の入口ＧＦＨ１８によって受け取られて解析され、その結果、フレームが２次ブレード上の入口ＧＦＨに向けられていることが決定される。これに応答して、フレームは、ターゲット・ブレード上にある出口ＧＦＨにディスパッチされるように、ターゲット・ブレード・アドレスを適切に設定されて入口キューに入れられる。出口ＧＦＨは、フレームを解析して、フレームがそれ自体の入口コンポーネントに向けられていることを決定し、それに応答して、フレームが入口ＧＦＨ１８ｂによって受け取られるように、フレームをラップ・キューＤＭ２５に入れる。次いで入口ＧＦＨ１８ｂは、要求フレームを処理し、応答フレームを構築する。応答フレームは、ターゲット・ブレード・アドレスを１次ブレードのアドレスに設定した後でフレームを入口キューに入れることにより、ＣＰ５０に再びルーティングされ、ＤＡＳＬインタフェースを介して１次ブレード上の出口ＧＦＨ１８ａによって受け取られる。フレームは、１次ブレード上の出口ＧＦＨ１８ａで解析され、フレームが応答フレームであることが決定される。これに応答して、出口ＧＦＨは、フレームを適切な出口インタフェース・キューに入れる。これによりフレームは、例えばＤＭ２４ａなどのＤＭインタフェースを通して、ＣＰ５０に接続されたポートを介して送ることができ、最終的にはＣＰ５０が応答フレームを受け取る。
【００４０】
図７に示す例示的なシナリオ２４０では、ガイデッド「要求」フレームは２次ブレード２０ｂ上のＧＤＨによって生成され、２次ブレード２０ｂ上の入口ＧＦＨ１８ｂまたは出口ＧＦＨ１８ｃに向けられた組込みガイデッド・コマンドを含む。この例示的なシナリオ２４０では、フローは、図５に関して本明細書に述べた同様の１次ブレードの例示的なシナリオについて述べたフローと同一である。唯一の異なる点は、エラーの場合にＧＦＨによって生成される否定応答メッセージが辿るパスにある。すなわち、入口ＧＦＨが要求フレームを処理する場合は、１次ブレード２０ａをターゲット・フレームに指定した否定応答フレームが入口キューに入れられる。出口ＧＦＨの場合は、このメッセージはＤＭ＿Ｗインタフェース２５を介して２次ブレード上の入口ＧＦＨにラップされる。入口ＧＦＨは、ターゲット・ブレードを１次ブレードに設定してフレームを入口キューに入れることにより、フレームを１次ブレードの出口ＧＦＨにルーティングする。１次ブレードの出口ＧＦＨは、フレームを受け取ると、フレームを解析し、フレームが応答フレームであることを決定する。これに応答して、出口ＧＦＨは、フレームを適切な出口ターゲット・インタフェース・キューに入れる。これによりフレームは、例えばＤＭ２４ａなどのＤＭインタフェースを通して、ＣＰ５０に接続されたポートを介して送ることができ、最終的にはＣＰ５０が応答フレームを受け取る。
【００４１】
次に図８および９に関して述べるように、例えばＣＰサブシステム５０と１次および２次の両ブレード上のガイデッド・テーブル・ハンドラ（ＧＴＨ）１９との間のマルチブレード・メッセージ・フローを含む例示的なシナリオがある。この例示的なシナリオに関連するメッセージ・フローは、１次ブレードと２次ブレードに関して述べたメッセージ・フローを組み合わせたものである。フレームが１次ブレード１８上の入口ＧＦＨによってＣＰから受け取られると、フレームは解析される。解析結果は、フレームが複数のブレード上のＧＴＨに向けられていることを示す。したがって、フレームをターゲット・ブレードのリストと共に入口キューに入れることにより、フレームはすべてのターゲット・ブレードに転送される。フレームが各ターゲット・ブレード上の出口ＧＦＨによって受け取られたときのフレーム処理は、前述したのと同じのままである。ＣＰには、初めにターゲットとされていたブレードの数に対応する複数の応答フレームが送られることに留意されたい。ガイデッド・フレームがＧＤＨによって生成されて１次ブレードおよび２次ブレード上のＧＴＨに向けられる、関連する例示的なシナリオの場合は、前述の場合と同様だが、発信元のＧＤＨに応答は決して送り返されないという条件が付く。否定応答が指定されている場合は、エラー状況で１つまたは複数の否定応答フレームがＣＰに送られる。
【００４２】
したがって、図８に示す第３の例示的なシナリオ２６０では、ガイデッド「要求」フレームはＣＰ５０によって生成され、１次ブレード２０ａ上のＧＴＨ１９に向けられた組込みガイデッド・コマンドを含む。この例示的なシナリオでは、フレーム制御情報は、フレームが１次ブレードの出口上にあるＧＴＨをターゲットにしていることを示すビットと、応答が必要であることを示すビットを含むものとする。動作に際して、フレームは１次ブレード上の入口ＧＦＨ１８によって受け取られて解析される。解析結果は、フレームが１次ブレード２０ａ上のＧＴＨ１９に向けられていることを示す。したがってフレームは、１次ブレードに対応するターゲット・ブレード・アドレスと共に入口キューに入れられる。これによりフレームは、ＤＡＳＬインタフェース４５ａ、ｂを介して１次ブレードの出口ＧＦＨ１８ａに到達する。出口ＧＦＨ１８ａは、フレームを解析し、フレームがＧＴＨに向けられたものであることを認め、１次ブレード上のＧＴＨにディスパッチされるようにフレームを出口ＧＴＨキューに入れる。ＧＴＨは受け取ったフレームを解析する。解析結果は、応答が必要であること、および要求のソースがＣＰであったことを示す。図１６に関して本明細書でより詳細に述べるが、フレームの「相関関係子」フィールドが、フレームのソースがＣＰ５０であったことを示す。ＧＴＨは、要求フレームを処理して応答フレームを構築する。次いでＧＴＨ１９は、応答フレームを適切な出口インタフェース・キューに入れることにより、フレームをＣＰ５０に送り返す。これによりフレームは、例えばＤＭ２４ａなどのＤＭインタフェースを通して、ＣＰ５０に接続されたポートを介して送ることができ、最終的にはＣＰ５０が応答フレームを受け取る。
【００４３】
図９に示す代替シナリオ２８０では、ガイデッド「要求」フレームは、ＣＰ５０によって生成され、また、２次ブレード２０ｂ上のＧＴＨ１９に向けられた組込みガイデッド・コマンドを含む。したがってこのシナリオでは、フレームは、２次ブレード上にあるＧＴＨをターゲットとすることを示すビットと、応答が必要であることを示すビットを含むものとする。前述のフローに従って、ガイデッド・フレームはまず、１次ブレード上の入口ＧＦＨによって受け取られて解析される。解析の結果、フレームが２次ブレード２０ｂ上のＧＴＨに向けられていることが決定される。したがってフレームは、ターゲット・ブレード２０ｂ上にある出口ＧＦＨ１８ｃにディスパッチされるように、ターゲット・ブレード・アドレスを適切に設定されて入口キューに入れられる。出口ＧＦＨは、フレームを解析し、フレームがＧＴＨに向けられていることを認め、したがってフレームを出口ＧＴＨキューに入れる。これによりフレームはＧＴＨによって受け取られ、ＧＴＨは受け取ったフレームを解析する。解析結果により、応答が必要であることが決定され、フレーム制御情報（図１６）の「相関関係子」フィールドから、フレームのソースがＣＰ５０であったことが決定される。次いでＧＴＨは、要求フレームを処理し、応答フレームを構築し、ＤＭ＿Ｗインタフェース２５を介して２次ブレード上の入口ＧＦＨ１８ｂに応答を送る。次いで入口ＧＦＨは、解析動作を行い、フレームが応答フレームであることを決定する。したがって、ターゲット・ブレード・アドレスを１次ブレード２０ａのアドレスに設定した後でフレームを入口キューに入れることにより、フレームはＣＰ５０にルーティングされる。フレームは、ＤＡＳＬインタフェース４５ｂを介して１次ブレード２０ａ上の出口ＧＦＨによって受け取られ、解析される。フレームは応答フレームであることを示すので、出口ＧＦＨは、フレームを適切な出口インタフェース・キューに入れる。これによりフレームは、例えばＤＭ２４ａなどのＤＭインタフェースを通して、ＣＰ５０に接続されたポートを介して送ることができ、最終的にはＣＰ５０が応答フレームを受け取る。
【００４４】
次に図１０および１１に関して述べるように、ＧＤＨ１７ａと、１次および２次の両ブレード上のＧＴＨ１９との間のメッセージ・フローを含む例示的なシナリオがある。
【００４５】
したがって、図１０に示す第４の例示的なシナリオ２９０では、ガイデッド「要求」フレームは入口ＧＤＨ１７ａによって生成され、同じ（１次）ブレード上のＧＴＨ１９に向けられた組込みガイデッド・コマンドを含む。フレームを入口キューに入れることによって、フレームはまず１次ブレード２０ａ上の出口ＧＦＨにルーティングされ、ＤＡＳＬインタフェース４５ａ、ｂを介して出口ＧＦＨ１８ａにディスパッチされて受け取られる。出口ＧＦＨ１８ａは、フレームを解析し、フレームがＧＴＨ１９に向けられていることを認め、したがってフレームを出口ＧＴＨキューに入れる。これによりＧＴＨはフレームを受け取る。次いでＧＴＨはフレームを解析し、フレーム制御情報の相関関係子フィールドから、フレームの発信元がＧＤＨであることを決定する。次いでＧＴＨはフレームを処理し、フレームは、処理された後、出口廃棄キューに入れられることによって廃棄される。したがってＧＤＨに応答は送られない。
【００４６】
図１１に示す代替シナリオ３００では、ガイデッド「要求」フレームはＧＤＨ１７ｂによって生成され、２次ブレード２０ｂ上のＧＴＨ１９に向けられた組込みガイデッド・コマンドを含む。このシナリオでは、フローは１次ブレードについて述べたものと同一だが、唯一の異なる点は、エラーの場合にＧＴＨ１９によって生成される否定応答メッセージが辿るパスである。このメッセージは、ＤＭ＿Ｗインタフェース２５を介して２次ブレード上の入口ＧＦＨ１８ｂにラップされる。入口ＧＦＨは、フレームを入口キューに入れることによってフレームを１次ブレード２０ａの出口ＧＦＨ１８ａにルーティングし、フレームは最終的にＣＰ５０に転送される。
【００４７】
図１６に、ガイデッド・フレームのフレーム制御情報６０のフォーマットを示す。図１６に示すように、このフレーム制御情報６０は２つのワード構造を含み、各ワード６１ａ、６１ｂはそれぞれ４バイトである。第１のワード６１ａ中には、第１のデータ・バイト６３が含まれ、この第１のデータ・バイト６３は、フレームを制御フレームとして識別する数字、例えば０ＣＨである。第２のバイト６５は、様々な処理／ルーティング標識を提供するためのビット・フラグを含み、これらの指示には次のものが含まれる。すなわち、フレームが要求フレームか応答フレームかを示すためにセットされる第１のｒｅｓｐ／ｒｅｑフラグ７０と、例えばＣＰなどのソースに常に返信するか全く返信しないかを示すためにセットされる第２のａｃｋ／ｎｏａｃｋフラグ７１と、フレームがどこからきたか（フレームのソース・アドレスおよびポート）をブレードが知るべきか、またはソース・アドレス情報がフレーム中に明示的に提供されているかを示すためにセットされるｕｓｅ／ｌｅａｒｎフラグ７２と、フレームの処理中にエラーが発生した場合だけ応答を提供すべきか（ｎｅｇにセットされる）、または処理エラーが発生したかどうかにかかわらず常に応答を返すようにソースが望んでいるかを示すためにａｃｋ／ｎｏａｃｋフラグ７１と共に機能する第４のｎｅｇ／ａｌｌフラグ７３と、フレームがブレードのどちら側に向けられているか、すなわち入口側か出口側かを示すためにセットされる第５の入口／出口フラグ７４と、ブレード内のどのピコプロセッサがフレームを処理すべきかを示す第６のＧＴＨ／ＧＦＨフラグ７５と、エラーが発生してもターゲット・プロセッサがガイデッド・フレーム・コマンドの処理を継続すべきか、またはエラーが発生した場合は処理を停止すべきかを示すためにセットされる、独立／連鎖コマンド処理インディケータである第７のｉｎｄ／ｃｈｎｄフラグ７６である。次のフィールド６６は、フレームが送られるターゲット・ブレードのアドレスを含む１６ビット・フィールドである。これはユニキャストまたはマルチキャストのアドレスを含むこともできることを理解されたい。すなわちガイデッド・フレーム・プロセッサは、フレーム処理の一部として、ターゲット・ブレード・フィールド６６のブレード・アドレスを、初期化の一部としてブレード中にプログラムされたアドレスと比較することになる。これらのアドレスが一致する場合は、フレームはそのブレードだけに向けられたものと見なされる。これらのアドレスが一致しない場合は、フレームはシステム内の別のブレードをターゲットとしていると見なされ（すなわちユニキャストまたはマルチキャスト・アドレス）、その結果、フレームがターゲットとすべきブレードを決定するためのインテリジェンスを有するスイッチ・ファブリック（図示せず）に渡される。
【００４８】
フレーム制御情報６０の第２のワード６１ｂ中には、少なくとも、ガイデッド・フレームが発信されたソース・ポートを示すための第１のデータ・バイト６７が含まれる。述べたシナリオでは、このソース・ポートは、例えばデータ・ムーバ（ＤＭ）インタフェース・ポートを含む場合がある。追加の２つのデータ・バイト６８が、発信フレームについてのソース・ブレード・アドレスを含む。これらのフレームがどのように構築されるかは、ｕｓｅ／ｌｅａｒｎフラグ７２によって決まることを理解されたい。例えば、「ｌｅａｒｎ」フラグ７２がセットされていない場合は、ブレードはソース・ポートおよびソース・ブレードのアドレス・フィールドを埋めないことになる。したがって、ブレード処理は、フレームがどこから来たかを知ることを担う。一般に、内部で（例えばＧＤＨによって）生成されるガイデッド・フレームは応答フレームを必要としない。すなわちａｃｋ／ｎｏａｃｋフィールド７１はｎｏａｃｋにセットされる。したがってこれらのフィールドはセットされない。しかし、例外／エラーを例えば非送信請求応答フレームとしてＣＰに報告すべき場合は、ＮＰはソース・ブレードおよびＣＰのポートを知るように構成されることになる。
【００４９】
ガイデッド・フレームの構成に関してはさらに、提供される相関関係子情報は２〜５バイト（図示せず）の任意の場所にわたるものとすることができ、応答フレームが例えばＣＰに返されたときにガイデッド要求フレームの元のコマンドと相関されるように、固有の識別子を提供する。多くの組込みコマンドを有する単一のガイド・フレームを処理する間には要求側ＣＰに複数の応答フレームが返される場合があり、各応答を相関させる必要があるので、このことは好ましい。
【００５０】
ガイデッド・フレームの残りの構成に関しては、ＮＰネットワーキング環境でＮＰインタフェース・デバイスを設定および制御するのに使用される指示または操作を含む１つまたは複数のコマンド・フィールドが設けられる。各コマンド・フィールドは、少なくとも３つのサブフィールドを含むことが好ましい。すなわち、１）実施されるコマンドのタイプを識別するためのコマンド制御ワード、２）コマンドが作用する対象であるＮＰインタフェース・デバイス内のアドレス位置を示すアドレス・フィールド、および３）コマンド・タイプに関連するデータを含む可変長のオペランドのフィールドである。例えばコマンド・タイプは、レジスタをセットアップすること、またはメモリ位置をデータで埋めることを含む場合があり、アドレス情報サブフィールドは、オペランド・データを埋めるべきレジスタ／メモリ位置のアドレスを提供することになる。図２および３それぞれのＧＦＨおよびＧＴＨ構造内に示す機能ブロックを制御および設定するために実施できるコマンド・タイプには、多くのものがあることを理解されたい。ガイデッド・フレーム中の残りのワードは、コマンドがそれ以上提供されないこと、およびガイデッド・フレーム処理が停止すべきであることを示す、固有のフレーム終了区切りである。
【００５１】
各図に示した前述のガイデッド・フレーム・メッセージ・フローのシナリオは、これから述べるように図１２〜１５中のフロー・チャートによって実施される。
【００５２】
図１２は、ＧＦＨ内でのガイデッド・フレームの処理を示す流れ図３１０である。図１２に示すように、ステップ３１２で、着信ガイデッド・フレームがＧＦＨによって受け取られる。ステップ３１４で、フレームは、図１３に示すようにＧＦＨのガイデッド・フレーム・プロセッサによって処理されるが、この処理でフレーム制御情報が解析されて、有効フレームかどうか、すなわちガイデッド・フレーム識別子を含むかどうかが決定される。ステップ３１６で有効フレームかどうかを決定し、有効フレームでない場合すなわちガイデッド制御フレームでない場合は、ステップ３１８でフレームを廃棄し、プロセッサはステップ３２０の遊休状態に戻ることになる。ステップ３１６でフレームが有効ガイデッド・フレームであると判定された場合は、ステップ３２２で、受け取ったフレームが応答フレームか要求フレームかを決定する。フレームが応答フレームであると決定された場合は、フレームは、ステップ３２４でＧＦＨのガイデッド・フレーム・プロセッサによって処理され、図１３に示すガイデッド・フレーム・プロセッサ・フローに従って進む。そうではなく、受け取ったガイデッド・フレームが要求フレームである場合は、ステップ３２６でターゲット・ブレード・アドレスを決定する。次いでステップ３２８で、ターゲット・ブレードが、フレームを受け取った現在のブレードであるかどうかを決定する。フレーム中のターゲット・ブレードが現在のブレードに向けられていない場合は、ステップ３３０で、図１５に示す代替処理フローに従ってフレームを処理する。そうではなく、受け取ったガイデッド・フレームが現在のブレードに向けられている場合は、ステップ３３３で、フレームがブレードの出口側または入口側で処理されることになっていることを示すｕｐ（入口）／ｄｏｗｎ（出口）フラグ・ビット７４（図１６）が第１のフレーム制御ワード中でセットされているかどうかを決定する。フレームが出口側で処理されることになっている場合は、さらにステップ３３６で、フレームがブレードの出口側から来たか入口側から来たかを決定する。同様に、フレームが入口側で処理されることになっている場合は、さらにステップ３３８で、フレームがブレードの出口側から来たか入口側から来たかを決定する。ステップ３３６でフレームが出口側に向けられており出口側で発した場合は、ステップ３４０で、図１４に示すガイデッド・コマンド・プロセッサ・フローに従ってフレームを処理する。同様に、ステップ３３８でフレームが入口側に向けられており入口側で発した場合も、図１４に示すガイデッド・コマンド・プロセッサ・フローに従ってフレームを処理する。フレームが、受け取られた側と反対側に向けられている場合は、ステップ３４５に示すようにフレームを正しい側にルーティングする。
【００５３】
図１３は、ガイデッド・フレームのガイデッド・フレーム処理を示す流れ図３５０である。図１３に示すように、ステップ３５２で、ＧＦＨから着信ガイデッド「応答」フレームを受け取る。次いでステップ３５４で、応答を送るべきか廃棄すべきかを示すａｃｋ／ｎｏａｃｋフラグ・ビット７１（図１６）が第１のフレーム制御ワード中でセットされているかどうかを決定する。肯定応答が必要ない場合は、ステップ３５６でフレームを廃棄し、ステップ３５８でプロセッサは遊休状態に戻る。ステップ３５４で応答フレームを送るべきであると決定された場合は、ステップ３６０で、応答を常に送るべきかエラー発生時だけ送るべきかを示すｎｅｇ／ａｌｌフラグ・ビット７３（図１６）が第１のフレーム制御ワード中でセットされているかどうかを決定する。応答を常に送るべきである場合は、ステップ３６２で、ＣＰがローカルに取り付けられているかリモートであるかを決定する。ＣＰがローカルの場合は、ステップ３６５で応答フレームをローカルＣＰにディスパッチする。ステップ３６０でエラー発生時だけ応答を送るべきであると決定された場合は、ステップ３６６で、処理中にエラーが実際に発生したかどうかを決定する。エラーが発生した場合は、リモートかローカルかのＣＰにディスパッチするために処理はステップ３６２に進む。ステップ３６６でエラーが発生しなかったと決定された場合は、ステップ３６８でフレームを廃棄し、ステップ３７０でプロセッサは遊休状態に戻る。ステップ３６２に戻るが、応答フレームを向けるべきＣＰがリモートである場合は、ステップ３７３で、フレームがどこで処理されたかを示すｕｐ（入口）／ｄｏｗｎ（出口）フラグ・ビット７４（図１６）が第１のフレーム制御ワード中でセットされているかどうかを決定する。フレームが入口側にあると決定された場合は、ステップ３７５で、応答フレームをＣＰにディスパッチするためにＤＭインタフェースに転送する。そうではなくフレームが出口側にあると決定された場合は、ステップ３７８で、ＤＭ＿Ｗ（ラップ）インタフェースを介して応答フレームを入口側にラップアラウンドし、ステップ３８０で、図１２に示した着信ループ・フローに従って入口ＧＦＨがフレームを処理する。
【００５４】
図１４は、ガイデッド・フレーム内のコマンドに対するガイデッド・コマンド処理を示す流れ図４００である。図１４に示すように、ステップ４０２で、ガイデッド・コマンドをどこで処理すべきかを示すＧＦＨ／ＧＴＨフラグ・ビット７５（図１６）が第１のフレーム制御ワード中でセットされているかどうかについて第１の決定を行う。ステップ４０４でビット・フラグ７５がＧＦＨ処理を示す場合は、ステップ４０６でＧＦＨ処理を進め、ガイデッド・フレームから次のコマンドを取り出す。ステップ４０８で、ガイデッド・フレーム処理の終了を示すフレーム終了区切りがみられるかどうかを決定する。フレーム終了区切りがみられた場合は、ステップ４１０で制御をガイデッド・フレーム・プロセッサに戻して、図１３に示したガイデッド・フレーム・プロセッサ・フローに従って処理を行う。ステップ４０８でフレーム終了区切りがみられなかった場合は、ステップ４１５で、現在のガイデッド・コマンド・オペランドに従って必要なパラメータを、設定されるべきピコプロセッサ・レジスタにロードする。ステップ４１８で、ＧＦＨ機能を（例えばプロシージャ・コール・アプリケーション・プログラムを介して）呼び出して設定セットアップを行い、ステップ４２０で、機能からステップ４０６のＧＦＨガイデッド・コマンド・プロセッサに制御を戻して、フレームから次のコマンドを処理する。ステップ４０４に戻るが、ビット・フラグ７５がＧＴＨ処理を示すと決定された場合は、ステップ４０９でＧＴＨ処理を進め、ガイデッド・フレームから次のコマンドを取り出す。次いでステップ４１１で、ガイデッド・フレーム処理の終了を示すフレーム終了区切りがみられるかどうかを決定する。フレーム終了区切りがみられた場合は、ステップ４１３で制御をガイデッド・フレーム・プロセッサに戻して、図１３に示したガイデッド・フレーム・プロセッサ・フローに従って処理を行う。ステップ４１１でフレーム終了区切りがみられなかった場合は、ステップ４１６で、現在のガイデッド・コマンド・オペランドに従って必要なパラメータを、設定されるべきピコプロセッサ・レジスタに入力する。ステップ４１９で、ＧＴＨ機能を呼び出して設定セットアップを行い、ステップ４２２で、機能からステップ４０９のＧＴＨガイデッド・コマンド・プロセッサに制御を戻し、フレームから次のコマンドを処理する。
【００５５】
図１２のステップ３３０に関して述べたように、１次ブレードで受け取られた要求フレームが２次ブレードまたは他の複数のブレードに向けられている場合は、プロセスは、図１５のステップ４５２に示すように代替処理フロー４５０に進む。具体的には、図１５は、ユニキャストでなく現在のブレードに向けられていないガイデッド・フレームの処理４５０を示す。したがって、図１５に示す処理は、１）別のブレードをターゲットとするユニキャスト・フレーム、２）現在のブレードを除く他のブレードをターゲットとするマルチキャスト・フレーム、３）現在のブレードを含めて他のブレードをターゲットとするマルチキャスト・フレームとして分類されるフレームを対象とする。図１１に示すように、ステップ４５４で、現在のフレームが３つの範疇のどれにあてはまるかを決定する。フレームが範疇１）および２）、すなわち別のブレードをターゲットとするユニキャスト・フレームまたは現在のブレードを除く他のブレードをターゲットとするマルチキャスト・フレームであると決定された場合は、処理はステップ４５６に進み、フレームをネットワーク・プロセッサ・スイッチング・ファブリックに転送して、宛先ブレードの出口側にディスパッチする。次いでステップ４５８に示すように、各ブレードの出口ＧＦＨは、図１２に示した着信ループ・フローに従ってフレームを処理する。ステップ４５４でフレームが範疇３）、すなわち現在のブレードを含めて他のブレードをターゲットとするマルチキャスト・フレームであると決定された場合は、処理はステップ４６０に進み、フレームをネットワーク・プロセッサ・スイッチング・ファブリックに転送して、宛先ブレードの出口側と現在のブレードの出口側とを含めた出口側にディスパッチする。次いでステップ４６２に示すように、各ブレードの出口ＧＦＨは、図１３に示した着信ループ・フローに従ってフレームを処理する。
【００５６】
参考文献：
米国特許出願第０９／３８４６９１号
米国特許出願第０９／３３０９６８号
【図面の簡単な説明】
【図１】  １つまたは複数のネットワーク・プロセッサ・デバイスを実装する例示的なネットワーク処理環境を示す図である。
【図２】  本発明の一実施形態による、図１に示したネットワーク・プロセッサ・デバイスのガイデッド・フレーム・ハンドラ・コンポーネントのブロック図である。
【図３】  本発明の一実施形態による、図１に示したネットワーク・プロセッサ・デバイスのガイデッド・テーブル・ハンドラ・コンポーネントのブロック図である。
【図４】  単一ブレード上でのＣＰとＧＦＨとの間のガイデッド・フレーム・フローを表す例示的なメッセージング・シナリオを示す図である。
【図５】  単一ブレード上でのＧＤＨとＧＦＨとの間のガイデッド・フレーム・フローを表す例示的なメッセージング・シナリオを示す図である。
【図６】  ２次ブレード上でのＣＰとＧＦＨとの間のガイデッド・フレーム・フローを表す例示的なメッセージング・シナリオを示す図である。
【図７】  ２次ブレード上でのＧＤＨとＧＦＨとの間のガイデッド・フレーム・フローを表す例示的なメッセージング・シナリオを示す図である。
【図８】  単一ブレード上でのＣＰとＧＴＨとの間のガイデッド・フレーム・フローを表す例示的なメッセージング・シナリオを示す図である。
【図９】  ２次ブレード上でのＣＰとＧＴＨとの間のガイデッド・フレーム・フローを表す例示的なメッセージング・シナリオを示す図である。
【図１０】  単一ブレード上でのＣＬＰとＧＴＨとの間のガイデッド・フレーム・フローを表す例示的なメッセージング・シナリオを示す図である。
【図１１】  ２次ブレード上でのＣＬＰとＧＴＨとの間のガイデッド・フレーム・フローを表す例示的なメッセージング・シナリオを示す図である。
【図１２】  本発明の一実施形態による、ＧＦＨ内のガイデッド・フレームの処理を示す流れ図３１０である。
【図１３】  本発明の一実施形態による、ガイデッド・フレームに対するガイデッド・フレーム処理を示す流れ図３５０である。
【図１４】  本発明の一実施形態による、ガイデッド・フレーム内のコマンドに対するガイデッド・コマンド処理を示す流れ図４００である。
【図１５】  本発明の一実施形態による、ユニキャストでなく現在のブレードに向けられていないガイデッド・フレームの処理を示す流れ図４５０である。
【図１６】  本発明の一実施形態による、ガイデッド・フレームに含まれるフレーム制御情報を示す詳細な図である。
【図１】
0004034566.tif 000002
【図２】
0004034566.tif 000003
【図３】
0004034566.tif 000004
【図４】
0004034566.tif 000005
【図５】
0004034566.tif 000006
【図６】
0004034566.tif 000007
【図７】
0004034566.tif 000008
【図８】
0004034566.tif 000009
【図９】
0004034566.tif 000010
【図１０】
0004034566.tif 000011
【図１１】
0004034566.tif 000012
【図１２】
0004034566.tif 000013
【図１３】
0004034566.tif 000014
【図１４】
0004034566.tif 000015
【図１５】
0004034566.tif 000016
【図１６】
0004034566.tif 000017