JP2002541732A

JP2002541732A - バルクデータトランスファのためのサービスアジャストメントの自動検出方法

Info

Publication number: JP2002541732A
Application number: JP2000610190A
Authority: JP
Inventors: スピニー，バリー，エー．; ナラヤスワミー，クリシュナ
Original assignee: トップレイヤーネットワークス，インク．
Priority date: 1999-04-03
Filing date: 2000-03-31
Publication date: 2002-12-03
Also published as: WO2000060819A9; EP1171978A1; WO2000060819A1; AU4062500A; US6426943B1

Abstract

(57)【要約】データコミュニケーションスイッチにおいて、データフローに関連するデータバイトのナンバーをトラッキングする過程並びに装置に関する発明である。データフローはセッションの一部であって、フローが電子メール又はその他ファイルの伝達の部分であることを示す領域に到達すると、フローのリマインダー伝達に付与されたプライオリティーを自動的に減少させる。

Description

【発明の詳細な説明】【発明の属する技術分野】

本願発明は一般にはコンピューターネットワーク、特に、通信方式イーサネッ
ト（登録商標）プロトコルやワイドエリアネットワーク（WANs）に、また非同期転送モード（ATMs）プロトコルにサポートされているようなローカルエリアネットワーク（LANs）の切替可能な接続に関係するものである。

【従来の技術と発明の解決しようとする課題】

（発明の背景）既存のデータコミュニケーション切替の問題点は、異なった型式のデータフロ
ーを区別することが出来ないことにあった。従って、切替や結節は過剰優先順位
の低い電子メールやファイル転送のデータ交通量によっての混雑を招くおそれが
あった。この切替の招く混雑は、よりリアルタイムであることを要する、また、
インターネット電話法やビデオ会議やなど発達によってより重要となってきて
いるビデオやオーディオストリーミングの交通を中断させてしまうおそれがある
。ネットワーク接続においての大きな問題の一つは、特有なネットワークにおい
ての異なったデータのプロセスシステム間での通信に利用される多種の異なった
ネットワークプロトコルがそのようなネットワーク間での通信を困難にしてい
ることである。他の大きな問題点は多くののネットワークプロトコルはコンピ
ューターシステムやノードをｊくわえる時に、相当なパラメーターのコンフィギ
ュレーションを要することであり、典型的にはそれがネットワーク専門の人であ
ってもミスをおかすため、、デバイスアドレスの手入力で行われた場合である。
この問題はネットワークボウンダリーをまたいでの接続である時には悪化する。

【課題を解決するための手段】

以上の課題を解決するため、本願発明では、レシーブフィジカルパスとトラン
スミットフィジカルパスとの間でデータパケットのフローをフレキシブルに接続
するための方法であって、 (a)該レシーブフィジカルパスにデータパケットを受領するステップと、 (b)該データパケットが以前に受領したデータパケットでイニシエートされ
たフローの一部であるか否かを決定し、(i)一部でなければ、新フローの一部と
して受領されたデータバイトの数のカウントに提供されたデータバイトの数を追
加し、(ii)一部であれば、前記以前にイニシエートされたフローの一部として以
前にカウントされたデータバイトの数のカウントに提供されたデータバイトの数
を追加するステップと、 (c)前記追加ステップの結果として受領されたデータバイトの数のカウント
が所定のしきい値を超えるか否かを決定し、(i)超えなければ、トランスミッシ
ョンのために第１品質のサービスセクエンスを適用し、(ii)超えれば、トランス
ミッションのために第２品質のサービスセクエンスを適用するステップと、 (d)前記適用された品質のサービスセクエンスに従って前記フローの一部で
あるデータパケットをトランスミットするステップと、を含んでいることを特徴とする方法を提案した。

【発明の実施の形態】

本明細書は、以下のように編成されている。１．ＢｌａｚｅＰａｔｈ（商標）／ＢｌａｚｅＦｉｒｅ（商標）アーキテクチ
ャ／チップ・セット２．ヘッダの「カノニカル化」およびパケットの「カノニカル化」３．ＢｌａｚｅＷｉｒｅ（商標）高速ＭＡＣバス４．データ・フロー・イン５．キュー・ポインタ管理およびオペレーション６．リライ・エンジン・オペレーション／フロー整合（ＦａｓｔＰａｔｈ（商
標））７．送信スケジューリング８．インターフェースへのダウンロード／送信クレジット・ループ９．超高速ＲＡＭＢＵＳ（登録商標）オペレーション１０．背景エンジン／初期化／監視１１．マルチメディア・データ・フローのスケジューリング１．ＢｌａｚｅＰａｔｈ（商標）／ＢｌａｚｅＦｉｒｅ（商標）アーキテクチ
ャ／チップ・セット本発明のアーキテキクチャは、ＢｌａｚｅＰａｔｈ（商標）と呼ばれ、アプリ
ケーション層フロー切替え、または、特定のフローにおけるメンバシップを特徴
付けるパケットのアプリケーション・ヘッダの情報に基づいて行われた決定によ
る、多数の仮想キューの１つまたは複数に入来するデータ・パケットを（高速デ
ータ・バッファに対するポインタによって）仮想的に割り付けることによって実
施される接続を備える。システムのスループットまたは帯域幅を改善するために
、好ましい実施形態である、ＡｐｐＳｗｉｔｃｈ（商標）アプリケーション・フ
ロー・スイッチは、フローの初期パケットにより決定し、情報のヘッダのハッシ
ュ・バージョンを整合させて、フローの後のパケットを識別する。入来するフロ
ーのヘッダ情報を「カノニカル化」し、長いフレームをより小さい内部セルに分
割することによって（ただし論理的には接続されているように保つ）、システム
は、独立した「フレームのセル」になる。図１を参照すると、好ましい実施形態において、アーキテクチャが、Ｂｌａｚ
ｅＷｉｒｅ（商標）ＭＡＣバス６０によって接続されているＢｌａｚｅＦｉｒｅ
（商標）のチップセットにおいて実施されている。アーキテクチャは、１００Ｍ
Ｈｚで動作する２８７ｋゲートのキュー・マネジャ（「ＱＭ」）ＡＳＩＣ３０の
周囲に集中している。このキュー・マネジャは、入来するパケットが一時的に格
納されるＱＭ３０に接続されている高速データ・バッファ３５および３６の位置
に、ポインタ（２４ビットの定義）の１６、０００、０００のキューを配置する
ことを可能にするキュー−ポインタ・スキームを実施する。キューは、４１０ｋ
ゲートのリライ・エンジン（「ＲＥ」）、または、検査されるパケット・ヘッダ
に対するＡｒｇｏｎａｕｔＲＩＳＣ（ＡＲＣ）中央処理ユニット３８７および
ＦＩＦＯ３０５を含む、１００ＭＨｚで動作する転送エンジン（「ＦＥ」）ＡＳ
ＩＣ４０によって行われた決定に基づいてロードされる。システムへの入力とシ
ステムからの出力は、ＢｌａｚｅＷｉｒｅ（商標）ＭＡＣバス６０上でデイジー
チェーン接続されている、３５０ｋゲートの６０ＭＨｚＭＯＭ（ＭＴＩ（メデ
ィアに無関係なインターフェース）８進法ＭＡＣ）ＡＳＩＣ１０および２０を使
用して実施される。ＭＯＭチップ１０および２０は、各々、ローカルエリアイー
サネットに対する２つのクワッド物理リンクチップ（それぞれ７１および７２と
７０および７３）、または、Ｔ１とＰＯＴＳ（「普通の従来の電話サービス」）
のＷＡＮライン６９をサービスする分散アクセス・デバイス（ＤＡＤ）ＷＡＮプ
ロセッサ６６あるいは背景エンジン（「ＢＥ」）５０に対するインターフェース
の役割りを果たすことが可能である。図２は、ＭＯＭチップ１０など、本発明の好ましい実施形態で使用される、Ｍ
ＯＭチップのブロック図である。一般に、図は、８つの２重イーサネット・ポー
トを提供するＭＩＩインターフェース６５を示す。受信インターフェース１１と
パーサ１２は、データ・パケットを受信し、以下のセクション２で記述するカノ
ニカル・ヘッダとしてフレーム・ヘッダを書き換え、結果的に得られるパケット
を１２８バイトのセルに分割する。このセルは、８つのポートの中のラウンド・
ロビン・アービトレーションにおいて、プロデューサ１３とＦＩＦＯアービタ１
４によって、ＦＩＦＯ１５に配置される。カノニカル・ヘッダを担っていないデ
ータ・セル（パケットの第１セルに続くパケット・セル）は、データの内部タグ
付けのためにバースト論理１７によって追加されたバースト・ヘッダを有する。
ＲＸクレジット・マネジャ１９は、送信クレジット（以下のセクション８におい
て議論する）を適切であるとしてヘッダに追加して、送信ＦＩＦＯ２４が送信さ
れるより多くのデータを受信することができることをＱＭ３０に通知する。トー
クン・アービタ１８は、データをＭＡＣバスＴＸセル７６に送信し、さらにＭＡ
Ｃバス６０上でＱＭ３０に送信するときを決定する。さらに図２を参照すると、ＭＡＣバス６０に入来するデータ・セルは、カノニ
カル／バースト・ヘッダの回路識別子により、送信コンシューマ２６に向けられ
る。データ・パケット・ヘッダは、送信コンシューマ２６とインターフェース２
７によって再構築および送信され、ＴＸクレジット／マネジャ２８は、クレジッ
ト情報で更新されて、ＱＭ３０に戻る。図３は、本発明の好ましい実施形態で使用されるＱＭ３０のブロック図である
。本質的に、ＱＭ３０は、（データ・バッファに連結されたポインタの連結リス
トによって仮想的に実施された）適切なキュー上でデータ・セルの配置を迅速に
実行し、ＲＥ４０によって支持されたキュー・ポリシを適用するように設計され
ているゲートと状態機械の集合体である。ＱＭ３０は、３つのクロック・レジー
ムに分割される。受信データＦＩＦＯ３０６と受信コマンドＦＩＦＯ３１２を供
給するデジタル遅延ロック・ループ３０２と受信インターフェース３０４を通り
、送信データＦＩＦＯ３０５を排出するデジタル遅延ロック・ループ３０１と送
信インターフェース３０３を通るＭＡＣバス６０とのインターフェースは、ＭＡ
Ｃバス・クロック上にある。受信したデータ・セルは、以下で議論するように、
直接２重ＲＡＭＢＵＳ（登録商標）アクセス・セル３０８を通って、ＥＲＡＭ３
５および３６にチャネリングされる。ＤＲＡＭクロック上で動作するＤＲＡＭイ
ンターフェース３０７は、ＭＡＣバスＦＩＦＯ３０５と３０６、ならびに、ヘッ
ダ・アウトＦＩＦＯ３０９（ヘッダ・データ・インターフェース７４上でＲＥ４
０（図示せず）に送信されるカノニカル・ヘッダ・セルを含む）、ヘッダ・イン
ＦＩＦＯ３１０（適切なルーティング情報でリライ・エンジン・データ・インタ
ーフェースにおいて書き直されたカノニカル・ヘッダを含む）、およびＤＲＡＭ
コマンドＦＩＦＯ３１１のオペレーションを調整する。ＤＲＡＭコマンドＦＩＦ
Ｏ３１１は、ＳＲＡＭクロック領域下の機能ネットワークにおいて示したＱＭ論
理によって実施されたＲＥの決定を含む。受信エンジン３１５、送信エンジン３
１６、およびヘッダ・プリフェッチ・エンジン２３４は、データをＤＲＡＭ３５
および３６から出し入れする命令をＤＲＡＭインターフェース３０７に提供する
ように、ＤＲＡＭアービタ３１４の機能に指示する。また、受信エンジン３１５
と送信エンジン３１６は、ＤＲＡＭ３５および３６のバッファを入来するデータ
に割り付けるように、自由バッファ・マネジャ３１８と調和する。エンキュー・
マネジャ３１９とデキュー・マネジャ３１２は、ヘッダ・プリフェッチ・エンジ
ンおよび受信キュー状態（以下のセクション５において議論するように、受信キ
ュー・ポインタのヘッドとテール）３２０と調和して、とりわけパターン整合の
ために、カノニカル・ヘッダ・データを含んでいるセルをＲＥ４０に送信し、受
信したキューから対応するパケットを取り出すときについて決定する。ヘッダ・
プリフェッチ・エンジン３１４は、リライ・エンジン・コンテキスト３２６、イ
ンターフェース７５を介してＲＥから命令を受信する命令ディスパッチ・マネジ
ャ３２７、リライ・エンジン命令インターフェース３２９、およびリライ・エン
ジン命令ＦＩＦＯ３２８と調和する。回路ポーラ３１７は、回路ごとに送信エン
ジン３１６をポーリングして、セルを送信し、ＳＲＡＭインターフェース３２３
を通して、ＳＲＡＭ３２のバッファ・ポインタ（「記述子」）の連結リストにア
クセスし、１つまたは複数のキュー上で受信および送信される際のパケットの構
成要素セルを追跡するＳＲＡＭアービタ３２２と調和する。適切なフィールド・
マッピングがハードワイヤードされているこれらのオペレーションは、非常に高
速で実行されたスケジューリングとルーティングの高度な柔軟性に備えている。図４は、ＲＥ４０のブロック図である。ＲＥ４０の主要機能は、ＱＭ３０から
インターフェース７４において受信したカノニカル化したパケット・ヘッダを検
査して、パケットが既知のフローに属するか、および、それに応じて適切なスケ
ジューリングのためにインターフェース７５上で命令を提供するかについて、迅
速に決定する（サービス品質）。ＣＰＵコア３８７（ＡＲＣプロセッサで実施さ
れる）は、命令キャッシュ３８６とデータ・キャッシュ３８５を含み、ＤＲＡＭ
インターフェース３８４（やはり、初期化時に、低速バス６２とＤＭＡ３８３を
介して、ＢＥ５０から命令を受信する）を介して、コードおよびデータＤＲＡＭ
４２と通信する。ストリング比較コプロセッサ３８９を使用して、パケットとフ
ローを整合するために使用するパターン認識を援助する。一般に、ＲＥ４０に入
るカノニカル化したパケット・ヘッダは、ＭＵＳＩｎ３９４によってデータＦＩ
ＦＯ３９４内にＭＵＸすることと併行して、ハッシュ・プリプロセッサ３９９に
よって事前処理される。併行ハッシングの結果は、ハッシュＦＩＦＯ３９３に配
置され、ハッシュ探索エンジン３９２によって、（特定のフロー特性と関連付け
られているヘッダ情報の既知のハッシュに関する）ハッシュ表３９１のオンボー
ドＬ１キャッシュのコンテンツと比較される。Ｌ１キャッシュ３９１に整合性が
見出されない場合、ハッシュ探索エンジン３２９は、ＳＲＡＭインターフェース
とアービタ３８８を介してアクセスした、探索ＳＲＡＭ４５のハッシュ表全体を
調べることになる。トライ・サーチ・コプロセッサ３９０を使用して、迅速なパ
ターン整合が適切でないかまたは失敗した状況（以下で議論する）における、適
切なフロー・パラメータを見つける。決定したフロー・パラメータにより、ＣＰ
Ｕ３８７によって、適切な命令を命令ＦＩＦＯ３９５に発行して、データＦＩＦ
Ｏ３９４からＭＵＸアウト３９７によってインターフェース７５を横切ってＱＭ
３０内に提供されたあらゆるデータで多重化された命令プッシュ３９６によって
処理する。図５は、キュー管理の観点から、本発明の好ましい実施形態のオペレーション
に関する一般的な概略図を示す。ＭＯＭ受信ポート１５’上のデータは、ＱＭ主
要受信ＦＩＦＯ３３０内に向けられる。また、データは、プロトコル６６’下お
よびＤＡＤ管理６６’下で処理されたＷＡＮ（Ｔ１およびＰＯＴＳ）ポート受信
キュー６９’からＤＡＤイーサネット送信キュー３４８’内にエンキューされて
、ＭＯＭ受信ポート３４８上に出現する。受信ＦＩＦＯ３３０のデータ・セルは
、主要システム・パケット・メモリＤＲＡＭ３５および３６に配置され、一方、
カノニカル・ヘッダは、ＦＩＦＯ３９４において、ＱＭ３０に転送される。ここ
で、ＦａｓｔＰａｔｈ（商標）処理を適用して、フローごと、優先順位ごと、お
よび各ポート・キュー３３２（以下で議論するように静的優先順位）および３３
３（以下で議論するように、重みを付けたロビン優先順位）ごとにパケットの適
切なキューイングを、送信のためにＭＯＭ送信ポート２４’（または、さらにＴ
１およびＰＯＴＳポート送信キュー６９”に分配するために、回路キュー３５０
上で分配されるＤＡＤ６６）に送信することを可能にする。スケジューリングの
微妙な同調は、「中間」キューとしてスケジューリングしたキュー３３５を使用
したフローごとのキューイングに対して、サービス品質スケジューリング・プロ
セス３３６を使用して達成することが可能である。管理キュー３３７も、重みを
付けたラウンド・ロビン・キュー３３３上で動作する管理オペレーション・プロ
セス３３８を備える。また、モニタ・キュー３３４が、ＭＩＩ２４’上で送信さ
れる情報を監視するネットワークに対して提供されている。ＢＥ５０側では、Ｍ
ＯＭポート送信キュー３３９上に配置されたデータは、ＭＩＩ（１００Ｍｂｉｔ
のイーサネット）リンク５４上で、ＢＥ受信キュー３４１内に送信される。背景
エンジン主要転送プロセス３４２は、情報を、ＢＥ送信低優先キュー３４６、ま
たは管理オペレーション・プロセス３４４によってサービスされる管理キュー３
４３内に渡し、データ（命令を服務）を開発して、ＢＥ送信高優先キュー３４５
上に配置する。両方のＢＥ送信キューとも、リンク６４を介して、ＭＯＭポート
受信キュー３４７内に排出され、ＱＭ受信キュー３３０上に配置される。図６は、本発明のプロセスに関する一般化した流れ図である。プロセスは、異
なるセルに対する図の様々な点に沿って、同時に行われることを理解されたい。
本発明の好ましい実施形態は、しばしば、入来する長いイーサネット・フレーム
を、後の再アセンブリのためにセルに分割するので、この実施形態では、元とな
ったパケットに関して、セルを特徴付けることが重要である。受信したセルは、
「パケットの開始」（「ＳＯＰ」）、「パケットの中間」（「ＭＯＰ」）、「パ
ケットの終了」（「ＥＯＰ」）とすることが可能であり、または、「パケットの
開始および終了」（「ＳＥＰ」）として１つのパケットを含むことが可能である
。好ましい実施形態におけるパケットの受信および送信は回路ごとに実行され、
回路はパケットの順序を維持する局所的な接続として定義されるので、１つの回
路上のパケットのセルは、ＭＡＣバス上など、他の回路上のパケットのセルでイ
ンタリーブすることが可能であるが、同じ回路上で受信されたセルは、同じ順序
で送信されなければならない。したがって、図６Ａでは、時間が上から下に進む
につれ、ＭＡＣバス上に現れる順序で、ＳＯＰ３７１が回路２から受信され、次
いでＳＥＰ３７２が回路１から、ＳＯＰ３７３が回路３から、ＭＯＰ３７４が回
路２から、ＥＯＰ３７６が回路３から、ＳＯＰ３７５が回路１から、ＥＯＰ３７
７が回路３から受信される。図６の示した一般化したプロセスを参照すると、オペレーション３５１におい
て、パケットはＭＩＩにおいて受信され、オペレーション３５２において、やは
りカノニカル・ヘッダ（および可能であればバースト・ヘッダ）を追加するＭＯ
Ｍ１０または２０によってセルに分割される（図１参照）。ＭＯＭ送信バッファ
のセルは、オペレーション３５３において、ＭＡＣバス上で調停され、オペレー
ション３５４において、後に送信するためにＤＲＡＭに格納され、これはまた、
本発明の好ましい実施形態で使用した仮想パケットのリンクリストなど、セルを
当初のパケットに関連付ける手順の開発を含む。セルがＳＯＰである場合、セル
をパターン整合手順に送信する決定３５５が行われ、セルは、以前に識別された
フローに関連付けられている既知のハッシュ結果に対して、ハッシュされ３５６
、次いで整合される３５７。整合が存在しない場合（おそらくはいくつかの整合
手順後）、新しいフローまたは例外が指定される３５８。いずれの場合でも、パ
ケットを適切にスケジューリングおよび経路指定するために、適切なヘッダが書
かれる。好ましい実施形態では、スケジューリングは、パケットを指定されたサ
ービス品質と特定の回路に関連付けられているキューに割り当てることによって
行われる。キュー上のセルは、適切な時間に送信３６０され、プロセスは、おそ
らくはヘッダの書換えを含む。送信されたセルがＥＯＰであった場合、パケット
は、回路からデキューされ３６１、パケットを送信するという他の要求が存在し
ない場合（オーナ３６２がもはやない場合）、データ・バッファは解放される３
６３。このプロセスは、さらに一般化して、多様な方式で実施することが可能で
ある。本発明の好ましい実施形態によるデータのフローについて、さらに以下で提示
する。これには、追加の発明が含まれる。２．ヘッダ「カノニカライゼーション」およびフレーム「セルラー化」物理レイヤ上でデータ・パケットを受信すると、この発明的なネットワーク・
スイッチは、到来パケットのレイヤ２ヘッダおよびレイヤ３ヘッダをとり（レイ
ヤ１パケット・プリアンブルがあればドロップし）、それをカノニカル形式に変
換する。本発明はさらに、可変長パケットを、高速内部バス上での通信にとって
最大限に都合のよい長さの「セル」に分割する。これにより、イーサネット「フ
レーム」やＡＴＭ「セル」などの異なるレイヤ２ヘッダ・フォーマットおよびレ
イヤ３ヘッダ・フォーマットであって異なる長さのデータ・パケットを、同じス
イッチング・プロセスおよび装置でルーティングすることができる。ヘッダの「
カノニカライゼーション」はまた、処理に都合のよい４バイト境界に沿ってヘッ
ダを整列させる。ここでの例はイーサネット・フレームの場合であるが、用語お
よびインターフェースＡＳＩＣを適切に修正すればＡＴＭセルにも適用可能であ
る。図１を参照すると、図示した８つのポートのうちの１つを介して情報のフレー
ムがＭＯＭ１チップ１０によって受信される。物理リンク・レイヤ１の処理は、
好ましい実施形態ではデュアル「オフザシェルフ」ＱｕａｄＰＨＹ集積回路（Ｌ
ｕｃｅｎｔＴｅｃｈｎｏｌｏｇｉｅｓから入手可能なものなど）によって扱い
、各回路は、１０Ｂａｓｅ−Ｔ（１０Ｍｂｉｔ／秒）または１００Ｂａｓｅ−Ｔ
Ｘ（１００Ｍｂｉｔ／秒）のイーサネットの送信／受信電子回路を扱う。ポート
の１つ、例えばＭＯＭ２からのポートを、内部または外部１０Ｍｂｉｔイーサネ
ットによって、オフザシェルフＷＡＮプロセッサ（Ｍｏｔｏｒｏｌａから入手可
能なものなど）を含むＤＡＤ集積回路に接続することができ、ＤＡＤ集積回路は
、モデムを介してＴ１およびＰＯＴＳ回線とインターフェースする。これらは共
に、ＱｕａｄＳｅｒｖｅ（商標）ＷＡＮアクセス・モジュールを形成する。図１を参照すると、メッセージを形成するデータ・ストリームの形をとる情報
のフレームまたはパケットが物理回路７０に入力され、次いで、ＭＯＭ１チップ
１０によってその８つのポートの１つを介して受信される。図１８に、典型的な
パケット・フォーマットの構成を概略的に示す。プリアンブル６２０があり、こ
れに続いて、パケットをブリッジングするための情報を含むデータ・リンク・レ
イヤ２ヘッダ６２２と、メッセージをルーティングするための情報を含むネット
ワーク・レイヤ３ヘッダ６２３と、データの使用対象であるアプリケーションに
関する情報を含むアプリケーション・ヘッダ６２４がある。これらのヘッダの後
にデータ本体６２５、および場合によってはトレーラ６２６があるが、トレーラ
６２６は通常は不要であり使用されない。ＭＯＭ１チップは、好ましい実施形態では様々なイーサネット・プロトコルを
認識するようにハードウェア中に事前プログラムされたものだが、これは、受信
フレームから、プリアンブルおよびトレーラをドロップし、レイヤ２および３の
ヘッダを読み、図７Ａの２８バイトのカノニカル・ヘッダを生成する。ＭＯＭ１
は、１ポートにつき２５６バイトのバッファ容量があるので、フレーム・データ
をそれぞれ１２８バイトのセルにセグメント化する（他の実施形態では他のセル
長を用いてもよい）。受信されたレイヤ３（ネットワーク）ヘッダ情報は、カノニカル・ヘッダをす
ぐに付加して記憶される。カノニカル・ヘッダは２８バイトなので、レイヤ３ヘ
ッダは、常にセルの開始点から４の倍数バイトで開始する。レイヤ３内の重要な
フィールドは、通常、４バイト境界に整列する。これにより、３２ビット・プロ
セッサ／メモリ・アーキテクチャの場合にこれらのフィールドの処理が非常に効
率的になる。レイヤ３ヘッダには、アプリケーション・レイヤを含めた上位レイヤからの他
のヘッダ情報が続く。カノニカル・ヘッダは、受信された各フレームまたはパケ
ットの第１のセルの最初に配置され、パケットをルーティングまたはブリッジン
グするためにＲＥ４０によって使用される。セルのストリームの形をとるパケッ
トが送信されるようにＭＯＭに送られたとき、ＭＯＭは、送信カノニカル・ヘッ
ダ中の宛先およびプロトコル情報に従って適切なヘッダ、プリアンブル、および
トレーラを再構築し、指定されたポートに接続された回線上で、再構築したパケ
ットの送信を開始する。図７Ａに、好ましい一実施形態におけるカノニカル・ヘッダの構成および内容
を示す。最初の２つのバイト４３０は、データ・パケットが受信された回路の回
路識別を保持し、バイト４３２すなわちＤＬＩｎｆｏは、元の受信ヘッダから
のデータ・リンク（レイヤ２）ヘッダに関する情報を提供する。図７Ｂに、これ
らのビットに対する具体的な割当てを示す。ビット７は、受信されたフレームが
その受信時にＶＬＡＮ（仮想ローカル・エリア・ネットワーク）でタグ付けされ
ていたかどうかを示す。送信時にこのビットがセットされている場合、送出パケ
ットは、送信を処理するＭＯＭチップによってＶＬＡＮヘッダでカプセル化され
る。ただし、ＶＬＡＮタグ付きで受信されたパケットは必ずしもＶＬＡＮタグ付
きで送出する必要はなく、その逆も同様であることに留意されたい。図７Ｂのビット６および５は、どのようにＣＲＣ（巡回冗長検査）が処理され
るかを示す。図７Ｃは改めて説明する必要はない。送出フレームが受信フレーム
と異なるときは新しいＣＲＣを生成しなければならないが、単に元のフレームが
転送される場合はＣＲＣを変更しなくてもよく、したがって、古いＣＲＣを保持
するか別のＣＲＣを生成する必要があることに留意されたい。ビット３および４
は未使用であり、０のままである。図７Ｄに、データ・リンク・フォーマットを
識別するビット２、１、および０に対する符号化を示す。カノニカル・ヘッダＮＬＩｎｆｏフィールド４３４は、ネットワーク・レイ
ヤ情報を含む。図８Ａに、ＮＬＩｎｆｏ中の８つのビットの意味を示す。受信
に関して、ビット７の真は、受信された情報の宛先アドレス（ＤＡ）が、パケッ
トが受信された回路に関連するブリッジ・グループのアドレスであることを示す
。ビット６の真は、ＤＡがそのポートに対するシステム・アドレスであることを
示す。ビット５の真は、ＤＡが、ネットワーク制御プロトコルに関連するアドレ
スなど、本発明により「周知のアドレス」として事前構成されているアドレスで
あることを示す。送信時にこのビットは無視される。送信時、ビット７および６
がセットされている場合は、ＳＡフィールドに適切なソース・アドレスが入る。ビット４〜０は、パケットのレイヤ３プロトコルを識別する。図８Ｂは、本発
明の中に事前プログラムされたこれらのプロトコルを識別するものである。これ
らは、新しいプロトコルが開発されたときに拡張することができ、このシステム
によって効率的に扱う必要がある。タイム・スタンプの４つのバイト１３８は、パケットが失効する時間を含む。
ＱＭ３０は、パケットの第１のセルの一部としてカノニカル・ヘッダを受け取っ
たときに、そのパケットが失効する時間を入力する。ＱＭ３０は、パケットの送
信時、現在時間がカノニカル・ヘッダ中のタイム・スタンプ値よりも大きいかど
うかをチェックすることになる。大きい場合は、データ・リンク・デバイスは、
そのパケットを送信せず、代わりにそれをカウントするように指示を受ける。こ
のフィールドは、ＭＯＭによって最初に生成されるときに、以下のセクションの
「ＤａｔａＦｌｏｗＩｎ」で述べるセル情報を含む。２バイト受信回路識別（ＲｘＣｋｔＩｄ）は、パケットが受信される回路
を識別する。ＱＭは、データが再送される回路の回路識別でＣｋｔＩｄフィー
ルド４３０を上書きする前に、ＭＯＭ１によって最初に供給された受信回路識別
をＣｋｔＩｄフィールド４３０からコピーする。したがって受信回路識別は、
後で使用されるように（ＢＥ５０による管理およびＲＭＯＮ機能などのために）
保持される。ＤＡは、受信パケットの４８ビット・レイヤ２（ＭＡＣ）宛先アドレスである
。ＳＡは、受信パケットの４８ビット・レイヤ２（ＭＡＣ）ソース・アドレスで
ある。ＶＬＡＮタグは、イーサネット８０２．１Ｑタグ付きで受信したパケットに対
応するための２バイト・フィールドである。前述のように、ＤＬＩｎｆｏフィ
ールド中のＶＬＡＮタグ・ビットもまたセットされる。このパケットの送信を処
理するＭＯＭチップは、送出パケットにタグ付けすることになる。Ｐ−Ｔｙｐｅ／ｌｅｎは、プロトコル・タイプ／長さのフィールドを含む２バ
イト・フィールドである。この好ましい実施形態では、この値が１５００（１０
進法）よりも大きい場合、このフィールドはプロトコルを表し、この値が１５０
０以下である場合、このフィールドは長さを表す。プロトコルは、ＮＬＩｎｆ
ｏフィールドのＰｒｏｔｏｃｏｌＫｉｎｄサブフィールド中に取り込まれる。
プロトコルがそのように構成されていない場合、ＮＬＩｎｆｏフィールドのＰ
ｒｏｔｏｃｏｌＫｉｎｄサブフィールドは、Ｕｎｋｎｏｗｎ（０）を示すこと
になり、Ｐ−Ｔｙｐｅ／ｌｅｎフィールドはその値を有することになる。例えば
、パケットがイーサネット８０２．３フォーマットである場合、このフィールド
は、レイヤ３ヘッダ中の長さを使用した妥当性チェックに使用できる長さを含む
ことになる。ＸＸバイトは、受信パケットのパケット・フォーマットに基づく他の情報を有
することができる。図８Ｃに、異なるＤＬフォーマット・タイプの場合のＸＸバ
イトの内容を示す。３．ＢｌａｚｅＷｉｒｅ（商標）高速ＭＡＣバス受信されて１つまたは複数のセルに再構築され、第１のセルがカノニカル・ヘ
ッダおよび上位レイヤ・ヘッダを含むフレームは、ＱＭとの間で、ＢｌａｚｅＷ
ｉｒｅ（商標）と呼ばれる高速ＭＡＣバス上で通信される。ＢｌａｚｅＷｉｒｅ（商標）のここでの設計は、２つの大規模集積回路チップ
間で各方向に１０個の信号および１つのクロック信号がある全二重クロック・バ
スである。このクロッキング・プロトコルにより、バス上のデータ転送をセルフ
・フレーミングかつ非対称かつ非エイリアシングにすることができる。すべての
信号は、内在伝送回線が適切に終端している２つの導体ラン間の差動信号である
。この好ましい実施形態では、差動ドライバおよびレシーバの電気的特性は、ほ
ぼ低電圧差動規格（ＳＶＤＳ）ＡＮＳＩ／ＴＩＡ／ＥＩＡ−６４４に記述されて
いるとおりである。差動信号電圧は、約２５０ミリボルト（ｍｖ）であり、ケー
ブル終端および物理信号パスは、バスにわたる高速動作に対応するように設計さ
れる。バスは、一方の大きなチップ（ＭＯＭまたはＱＭ）から他方のチップに続
くチェーンとして構成される。バスへのチップのアクセスを制御するために、後
述するように別のデイジー・チェーン型トークン・パス手法が実装される。バス
の電子設計は、場合によって異なる製造、供給電圧変動、および温度変動からく
る、チップの異なる製品ランに付きものの実際の変形を補償する。好ましい実施
形態では、バスのスピードは、ギガヘルツの範囲まで上げることができる。１０個の信号は８つのデータから構成され、１つはパリティであり１つは制御
である。これらのデータは、クロック信号の立上りと立下りの両方の線上に配置
される。データはクロック遷移における信号線上に配置されるので、信号は、受
信端でまたはクロック信号の中心の至近で読むべきである。これにより、どんな
オーバーシュートも、他のどんな信号遅延または異常も解決することができる。
両方のクロック信号遷移における信号線上にデータがロードされるので、クロッ
ク・エッジとバス上に配置されたデータとの間のスキューが最小限に抑えられた
対称クロックを有することがクリティカルである。この回路は、クロック信号の
両方の位相の中心を監視および発見するフィードバック機構を提供し、さらに、
チップを介してバスの継続の上に送出されつつある信号に対称クロックを提供す
る。図９に、各方向に１０本がグループになった２０本の信号線と各グループにつ
き１つのクロックとを有するＭＯＭ１およびＭＯＭ２として示す２つのサブシス
テム間の基本的な信号フローを図示する。図１０に、２２本の線のそれぞれの差
動特徴を示す。当技術分野で周知の差動ドライバおよびレシーバが、信号忠実度
を最大限にしてリンギングを最小限に抑えるために、それらに特徴的なインピー
ダンスで伝送回線を適切に終端する。他の実施形態で有利なように、ドライブ側
に実装する手法など他の終端技術を使用することもできる。図１１は、１０個のデータ・ビットのうちの１つをＭＯＭのうちの１つから出
力するための回路の概略である。この回路は、本質的に他のデータ・ビット用に
複製される。この回路実装により、クロック対称性が最大限になり、スキューが
最小限に抑えられる。Ａデータ４６２が、出力４６６上に配置され、Ｂデータ４
６４がそれに続く。Ａデータは、フロップ４６８中にラッチされ、論理配列に提
示される。前のＢデータがラッチ４７２中に残されており論理配列４６０に入力
されると考えてみる。論理配列は、信号をラッチ４７４にロードするように構成
され、ラッチ４７４は、ラッチ４７６中に残った信号との「排他的論理和がとら
れる」と、ゲート４６６の出力にＡ信号を提供する。次にクロック・エッジ上で
、同様の演算がＢデータ信号を出力に提供し、このＢデータ４６４は、４７２で
ラッチされ、ラッチ４７４中にある前の信号との「排他的論理和がとられ」、し
たがって、ラッチ４７６中のデータの「排他的論理和」が、「排他的論理和」４
６６の出力にＢ信号を提供することになる。図１２は、以上のことを単純化した
タイミング図である。図１２Ａに、バス・クロックと、ＭＯＭ１と２の間のバス上にある１０本のデ
ータ線との複合タイミング・チャートを示す。図１２Ａは、クロック信号の各エ
ッジの上における８つの連続したバイト（加えてパリティおよび制御）の転送を
示している。信号がＭＯＭまたはＱＭで受信されるとき、図１３に、受信クロックのある位
相の中心にエッジがある遅延クロックを提供するのに使用されるＭＯＭの回路を
示す。別の類似の回路を使用して、受信クロックの別の位相の中心にエッジがあ
る遅延クロックを提供する。これらの中心合わせしたクロックは、データを受信
ＭＯＭ中にラッチするのに使用され、また、ＭＯＭから信号を送出するのに使用
される対称クロックに対する基準となる。受信クロック８０は、ラッチ４８２お
よびラッチ４８４に入力されるデータになる。遅延クロックＤＬＹＡ（入力クロ
ックの遅延バージョン）が、クロック信号４８０をラッチ４８２にラッチし、ラ
ッチ４８２の出力はＳＡＭＰＬＥＣＬＫＡであり、遅延クロックＤＬＹＢが
、クロック信号４８０をラッチ４８４にラッチし、これは出力ＳＡＭＰＬＥＣ
ＬＫＢを伴う。ＤＬＹＡおよびＤＬＹＢは、プログラム可能な分だけ制御論理
によって遅延される。これらのＳＡＭＰＬＥＣＬＫは両方とも、信号の同期を
とるように設計された回路を介して制御論理配列９０にフィードバックされる。
動作時、制御論理は、いつＤＬＹＡが発生するかをプログラムすることができる
。このようにして、ＤＬＹＡはローのときにクロック４８０信号をラッチするこ
とができ、制御論理がＳＡＭＰＬＥＣＬＫＡ信号によってローのときを決定
することができる。制御論理は、クロック４８０信号がハイになるまで、異なる
遅延の設定を継続する。同様にして、制御論理は、クロック信号がローに戻るま
で、異なる遅延の設定を継続する。前と同様に、制御論理は、ＳＡＭＰＬＥＣ
ＬＫＡ信号を監視することからこの条件を決定する。図１３Ａを参照すると、
制御論理がクロック信号４８０の第１の立上り４８０’および立下り４８０”を
見つけると、制御論理は、ＤＬＹＡ立上り４８６を「知り」、クロック４８０の
正の位相の中心に設定することができる。このＤＬＹＡ立上り信号は効果的にも
、クロック４８０の次の連続した正の位相上のデータをラッチするのに使用され
る立上り４８６’となる。ＤＬＹＡ信号の中心合わせの間、図１３Ａの時間４８
６で受け取られる実際のデータは、前にクロック４８０の正の位相に中心合わせ
された図１３の信号ＤＬＹＢによってラッチされる。ＤＬＹＢの前の中心合わせ
は、ＳＡＭＰＬＥＣＬＫＢフィードバック信号およびＤＬＹＢ遅延信号を用
いて上に述べたのと同に方式で達成されたものである。この実施形態では、ある
遅延クロックがデータをラッチしている間に、他の遅延クロックがいくらか後で
使用されるように中心合わせされる。図１３の回路は、複製されて、反対の位相上のデータをラッチするために入力
クロック信号の負の位相の中心が正確に測定される。図１３は、受信クロックの
負の位相の中心に正確にＤＬＹＣ立上り４８９を示している。前述のように、他
方のクロック（図示していないＤＬＹＤ）がデータをラッチしている間に、ＤＬ
ＹＣクロックがクロック４８０のある負の位相の間に中心合わせされ、ＤＬＹＣ
クロックがデータをラッチする間に、ＤＬＹＤが中心合わせされる。図１４に遅延回路の各部を示す。ＩＮ信号４９４は、あるゲート４９５によっ
て遅延され、「ａｎｄ」ゲート４６６に入力される。制御１信号が論理信号であ
る場合、この信号は、９６を横断し、「ｏｒ」構造４９８を介して出力され、３
つのゲート遅延すなわち４９５、４９６、４９８によって遅延された出力信号と
なる。この遅延は、１つの遅延ユニットと見なされる。制御１信号が論理「０」
であり制御２信号が論理「１」である場合、ＩＮ信号は、ゲート４９５、４９５
’、４９６’、４９８’、４９８を通って移動する。このパスは、２つのゲート
よりも長く、ＩＮ信号は２つの単一ユニット遅延回路を通って行ったものと見な
される。各信号遅延ユニットは、２つのゲート遅延を追加する。制御論理によっ
てＩＮ信号が３つのゲート５００に到達でき、制御Ｘ信号が論理信号である場合
、ＩＮ信号は、４つのゲート、すなわち３つのゲート５００およびゲート５０４
のインクリメンタルを通っていくことになる（ゲート５０２は各遅延回路中で複
製されて前の遅延回路中でディセーブルにされた共通パスである）。この回路は
、４つのゲート遅延を追加し、２つのユニット遅延を形成する。４ユニット遅延
（図示せず）は、３つのゲート５００を７つのゲートで置き換えることになり、
したがって８つのゲート遅延または４つのユニット遅延のインクリメントを追加
する。この好ましい実施形態では、３２個の単一ユニット遅延と、１６個の２ユ
ニット遅延と、１６個の４ユニット遅延がある。この好ましい実施形態における
構成により、選択できる合計１２８個のユニット遅延までの等差数列状の遅延が
可能である。他の実施形態では、他の遅延回路構成を選択することもでき、他の
周知の遅延回路を有利に使用することもできる。この好ましい実施形態では、回
路を構築するのに使用される予想される製造プロセスに対し、かつ予想される温
度および供給電圧動作に対し、単一遅延が約０．１５ナノ秒となる。前述のパラ
メータに応じて、１ユニット遅延の変動が０．０８から０．３ナノ秒までにわた
る場合があることが予想される。図１５（表１）は、この好ましい実施形態での制御ビットの使用法を示す表で
ある。ビットはフレーミングに使用される。図１２Ａのタイミング図では、ｅ０
〜ｅ７でマークされた各クロック遷移で８バイトが転送される。表１は、偶数遷
移、ｅ０、ｅ２、ｅ４、およびｅ６に関する制御ビットの値を示すものである。
これらの組合せが、一番右の列に示された許容機能を示す。各偶数遷移で制御ビ
ットがゼロの場合、バスはアイドル状態である。行５１０に示されたいずれの組
合せも、データ・ライン上にあるデータが有効フレームであることを表示するも
のである。具体的に言えば、データの有効フレームでは、ｅ６時間の値が常にゼ
ロでありｅ０時間の値が常に１であるため、システムは制御ビットのゼロから１
の時間シーケンスを探す。ｅ０では１が想定され、行５１０に示された組合せが
存在すれば、このデータのフレーミングは８バイトの有効セットを示す。８バイト・データの有効フレームにエイリアシングが発生することのないよう
に、行５１０の値が選択される。有効な制御ビット・シーケンスの組合せ、すな
わち図１５の行５１０には、必ずゼロの次に１があり、有効フレーム内にそれ以
外のゼロ／１パターンはない。図１６では、偶数クロック遷移での制御ビット値
のパターンが、フレーム５１２を無効として示しているが、これは、フレーム５
１２のｅ２およびｅ４に、別のゼロ／１パターンがあるからである。ただし、フ
レーム５１４はフレーム５１６と同様に有効である。実際には、制御ビットの値
が各受信クロック位相で測定され、クロック位相で分けられたゼロから１への遷
移が監視される。このような遷移が発生した場合、１はｅ０時間スロット内にあ
るものとして扱われ、フレームの有効性の監視は、その相対的タイミングに基づ
くものである。ＭＯＭチップからＱＭへのデータ伝送は、好ましい実施形態では、トークン・
リングによって調停される。図１のシステム構成／概略図を再度参照すると、ト
ークン・リング調停パス６１が、ＭＯＭ１とＭＯＭ２との間に示されている
。トークン・リングとは、入力トークン信号と出力トークン信号との間に論理的
な相違が存在する場合、チップがトークンを有するループ状の信号のことである
。図１７では、チップ内に有効な反転がないため、パス内にインバータがあり、
初期設定時に１つのチップ、この場合はＭＯＭ１がトークンを得て、バスを制
御することが保証される。チップがトークンを得ると、バスを介して独自のデー
タを送信することが可能であるが、チップがトークンを得ていないと、トークン
を待たなければならず、その間他のデータは単にチップを介して渡される。チッ
プがトークンを得ると、そのチップによって送信される必要のあるすべてのデー
タが送信された後に、トークンが解放される。ＭＯＭ１がトークンを得た場合
、ＭＯＭ１が出力信号６１の状態を変えることによって、トークンがＭＯＭ
２に渡される。その後、ＭＯＭ２がトークンを得る。このトークン・パッシングは、１つのデバイスの単一トークン出力信号と、次
のデバイスの単一トークン入力信号とを接続することによって、複数のデバイス
へと延長することができる。最終デバイスのトークン出力信号が反転され、その
後、トークン・パッシング・チェーン内の最初のデバイスに送られる。エッジでトークン・パッシングを実施するか、または情報の状態を変えること
で、異なるクロック・ドメイン間での同期化が容易になる。エッジ・ベースの情
報パッシングにより、トークンが認識され、トークン・パッシング・チェーン内
の次のデバイスに渡されるまで、そのトークンは自動的に前のデバイスで有効な
ままとなる。４．データのフロー・インＭＯＭ１チップ１０は、８ポートそれぞれについて、２セルまたは２５６バ
イトまでの受信データを格納またはバッファリングすることができる。前述の「
ヘッダのカノニカライゼーション（ＨｅａｄｅｒＣａｎｏｎｉｃａｌｉｚａｔ
ｉｏｎ）」の項で述べたように、ＭＯＭチップが、受信したフレームまたはパケ
ットからレイヤ２およびレイヤ３のヘッダを読み取り、２８バイトの最初のカノ
ニカル・ヘッダを生成（この項で詳細に述べる）した後、ネットワークのレイヤ
３ヘッダおよび第１セルのアプリケーション・レイヤ・ヘッダが処理される。ＭＯＭ１０（または２０）は、ＭＯＭが前述のトークン・リング・アービト
レーション・パスのトークンを保持しているときに、高速ＭＡＣバス６０上でセ
ルをＱＭ３０に伝送する。ＭＯＭの８ポート間で、アービトレーションは順繰
りである。ＱＭがセルを受け取り、このセルをダイナミックＲＡＭ３５および
３６に格納するが、この好ましい実施形態では、以下の第９項で述べるような高
速アクセスのＤＲＡＭバンクを２つ備えた、ＲＡＭＢＵＳ（登録商標）ＤＲＡＭ
である。受け取って格納したセルを記述する情報は「記述子」と呼ばれ、ＳＲＡ
Ｍ３２に配置される。カノニカル・ヘッダは、タイム・スタンプを含むように
修正される。パケット内の第１のセルにある修正されたカノニカル・ヘッダおよ
び残りのヘッダ情報は、ＲＥ４０に転送するために、ヘッダ・アウトＦＩＦＯ
３０９内に配置される。フレームのセグメント化およびアービトレーション・スキームにより、ある回
路上で受け取られたパケットの後続セルは、他の回路上で受け取られた他のパケ
ットのセルを使ってインターリーブすることができる。ＱＭがパケットのセルの
順序を追跡できるような情報を提供するために、ＭＯＭは、パケットの第１セル
の最初のカノニカル・ヘッダの第１のオクトバイトに対応して、同じパケットの
後続セルに追加された８バイト（オクトバイト）の「バースト」ヘッダを書き込
む（最高１７オクトバイトになる）。追加情報が制御信号回線または高速ＭＡＣバスのビット上で送信されることに
より、セルの境界およびセル内に格納された情報のタイプが識別可能になる。図
２１は、オクトバイトのグループでデータを描くための、制御ビットの使用法を
示す図である。８つの連続するクロック位相上にある制御ビット７００が、８バ
イトでフレーミングし、データを区別する。制御ビットの値は、図２２の表で、
ｅ０からｅ７で示されている。図２２では、偶数の制御ビットｅ０、ｅ２、ｅ４、およびｅ６が以下のように
符号化される。８ビットの有効グループが受け取られたことを示すために、ｅ０
は常に１であり、ｅ６は常にゼロである。この符号化のエイリアシングを避ける
ために、有効グループ（偶数の制御ビットｅ０からｅ６について）を示す値は、
１０００、１１００、および１１１０のみである。ビットｅ２はセルの開始を示
し、ｅ４はパケットの開始を示す。図２３は、偶数の制御ビットの可能なシーケ
ンスを示す図であって、グループ７０２は有効なグループではないが、グループ
７０４、７０８、および７１０は有効である。丸で囲まれたゼロ／１７０８は
、有効グループの開始は、最初にゼロ、その直後が１である場合のみであり、続
く２ビット（ｅ２およびｅ４）に別のゼロ／１はあり得ないことを示す。さらに図２２を参照すると、奇数の制御ビットは、以下のように符号化される
。ｅ１は伝送クレジット（以下の考察を参照）が存在することを示し、ｅ３（コ
ード・ビット０）およびｅ５（コード・ビット１）は２ビットのエンド・コード
を形成し、ｅ７（ショート・ワード）は、オクトバイトが８つの有意バイトより
も少ないバイトを含むことを示す。ショート・ワードは、セルの開始およびセル
の終了時に使用することができる。図２４は、発生する可能性のあるいくつかのパケット・タイプを示す図である
。第１セル７２０は、１６オクトバイトまで、すなわち１２８バイトまで有する
ことができる。第１の３２ビット・ワード（オクトバイト）に関する偶数の制御
ビット７２２は１１１０である。図２２に示されるように、このコードは、この
オクトバイトがパケットの有効な第１セルの一部であることを意味するものであ
る。有効なセルにはｅ０が「１」に等しいことが必要であり、ｅ２が「１」に等
しければこの８バイト転送がセルの開始であることを意味し、ｅ４が「１」に等
しければこれがパケットの開始であることを意味し、有効なセルにはｅ６がゼロ
でなければならないことがわかる。セル７２０の場合、奇数の制御ビットはすべ
てゼロであるが、例外として、最後の８バイト転送のビットｅ５だけは「１」で
ある。図２５は、制御ビットｅ１、ｅ３、ｅ５、およびｅ７、すなわち奇数の制
御ビットの符号化を示す図である。セル７２０の場合、ｅ５は「１」、ｅ３は「
０」であり、これが「パケットの終わり」に復号化される。したがって、セル７
２０は１つのセル・パケット（ＳＥＰ）である。このセルは、全１２８バイト長
である必要はないことに留意されたい。セル７２４はパケットの有効な開始セルであり、ここで奇数制御ビット７２６
のｅ３は、「パケットの終わり」ではなく「セルの終わり」を意味するように設
定されているため、これはＳＯＰセルである。次のセル７２８は、パケットの第
２セル（ＭＯＰ）であり、ＳＯＰに続くすべてのセルは、各セルの始まりに追加
されたオクトバイト・バースト・ヘッダ３３０を含み、１７までのオクトバイト
を有することになる。この第２セルの場合、最後のオクトバイトｅ３は、このセ
ルがパケットの終わりではなくセルの終わりであることを意味するように設定さ
れる。セル７３４は、最後の８バイト・グループにｅ５を有し、これはこのセル
がパケットの終わり（ＥＯＰ）であることを意味するように設定され、さらにこ
の場合、ｅ７も設定される。ビットｅ７は、８つのうち最後のグループが一杯で
はなく、（図２５に表されたように）「ショート・ワード」であったことを意味
し、これが発生すると、最後のバイト３３８には、最後の８バイト・グループ内
の有効バイト数が格納される。たとえば、最後のグループに有効バイトが３つし
かない場合、最後のバイト（ｅ７制御ビットと同時に発生）には００１１、すな
わち１０進法の３が含まれることになる。ＭＯＭチップからＱＭへのセルの伝送に関して、第１セルの開始時に、第１の
オクトバイトには、タイム・スタンプを含めるようにＱＭによって修正されたカ
ノニカル・ヘッダの一部が含まれる。カノニカル・ヘッダ全体が、他のヘッダと
共にＤＲＡＭ内に格納され、このようなフレーム・データを１２８バイトの残り
部分に収めることができる。図２６は、ＱＭによるカノニカル・ヘッダの第１のオクトバイトの伝送を示し
た図である。図からわかるように、ＭＯＭ、ＣｋｔＩＤ、ＤＬＩｎｆｏ、お
よびＮＬＩｎｆｏが書き込まれた最初の４バイト７４０が、ＱＭによって転送
される。セル情報が含まれた２番目の４バイト７４２は、ＱＭによってタイム・
スタンプ７４８で上書きされる。（カノニカル・ヘッダはＲＥに送られ、パケッ
ト・ポリシーでのみ処理されて、セル情報には関与されない。）セル情報バイト７４２の第１のバイト７４４には、ＱＭから報告された伝送ク
レジットの数が含まれる（以下の「伝送クレジット・スキーム（Ｔｒａｎｓｍｉ
ｓｓｉｏｎＣｒｅｄｉｔＳｃｈｅｍｅ）」の項で説明）。第２のバイトには
クレジット・フラグが含まれており、ビット７はＳＹＮＣＨフラグ（初期設定用
）、ビット６は「親」フラグである（以下の第８項で説明）。第３のバイトは、
図２７に示された意味を有するセル情報を提供する。ビットはそれぞれ、ビット
７はセル・エラーを示し、ビット６はパケットのタイムアウト、ビット５は不良
パケット・キューからのパケット、ビット４は監視キューから、ビット３〜０は
前述の制御から選択されたビットを示すという意味である。ビット３はパケット
終了ビット、ビット２はパケット開始ビット、ビット１はデータ・セル・ビット
、ビット０は伝送クレジット・ビットである。セル情報バイト７４２の最後のバ
イトは、セルの長さをバイト数で表す。カノニカル・ヘッダなしのセルを追跡するのに使用されるオクトバイト長さの
バースト・ヘッダが、図２８に示される。このフィールドは、ＤＬＩｎｆｏお
よびＮＬＩｎｆｏ（ＳＯＰだけを対象とするＲＥによって使用される）が、セ
ル・シーケンス番号７５２および未使用スペースに置き換えられている点を除い
て、最初のカノニカル・ヘッダの第１のオクトバイトのフィールドと同じである
。ＣｋｔＩｄ７５０は、セル（より具体的に言えば、その代理であるバッフ
ァ記述子）を、同じＣｋｔＩｄを有し、（セルが廃棄されていない限り）逐次
シーケンス番号を有しているはずの先行セルと一致させるために使用される。Ｑ
Ｍによって、セルが先行セルと（以下で説明するように）いったんリンクされ、
クレジットが入力され、他方のセル情報に関するアクションが実行されると、バ
ースト・ヘッダは不要となり、ドロップされる。（セルは、パリティ情報がエラ
ーを検出すると廃棄される場合がある。このような場合には、ＭＯＭチップへの
信号送信によって、この時点でセルが、さらに最終的にパケットが打ち切られる
。）伝送段階でＱＭによって、セル用の新しいバースト・ヘッダが作成され、こ
こでＣＫＴＩＤはパケットが送信される場所を示す。５．ＱＭバッファおよびキューの構造と操作ＱＭによってＭＡＣバス上に受け取ったデータ・セルは、以下のセクション９
で説明する高速アクセス操作に従ってＲＡＭＢＵＳ（登録商標）ＤＲＡＭの、ア
ドレス可能な１２８バイトのデータ・バッファに、正規のヘッダはそのままだが
タイムスタンプを含むように書き直され、またバースト・ヘッダのオクトバイト
をドロップして、個別に記憶される。アドレス０００００はセル情報を含まず、
ヌル・ポインタに対応する。ＭＡＣバス上に受け取り、データ・バッファに記憶されたすべてのセルは、例
外として少数の専用キュー以外に使用される記述子／ポインタ方式を使用して単
一の仮想受信キューに編成される。この方式は、１ギガバイトまでのデータに対
応する受信キューを使用可能にする。この記述子／ポインタ方式では、ＱＭＳＲＡＭにあるデータ・バッファ「記
述子」は２つの４バイトの語を含んでおり、そのバッファに記憶されている実デ
ータの代理となり、論理パケットを形成するようにリンクされている。したがっ
て、データと共にデータ・バッファに割り当てられた記述子は、関連するセルが
記憶されているＤＲＡＭにあるバッファのアドレスを示す第１の語のフィールド
と、同一パケットの次のセルに関連するＳＲＡＭにある別の記述子８０２へのポ
インタを含む第２の語のフィールドとを有する。図２９に示すように、完全なマ
ルチセル・パケットは、ＭＯＰバッファ記述子８０２を指すＳＯＰバッファ記述
子８０１の第２の語と、ＥＯＰバッファ記述子８０３を指す記述子８０２の第２
の語と、パケットの最終セルに関連付けられた記述子８０３の第２の語と共に、
パケットの第１のセルに関連付けられた記述子８０１を指すポインタを含めて、
記述子「ｌｉｎｋ−ｌｉｓｔ」によって記述される。図２９Ｂに示すように、不
完全なパケットは、記述子８０５の第２の語にヌル・ポインタを有する。本発明では、キューは、キューの第１のパケットの第１のセルと、キューの次
のパケットの第１のセルに関連付けられた記述子の第１の語を指すフィールドと
に関連付けられた記述子の第１の語を指すキュー・ヘッド・ポインタによって形
成されており、キューの最終パケットまでこのように反復的にリンクされる。こ
のキューは図３０に示すようにそれを指すキュー・テール・ポインタを有し、受
信キュー・ヘッド・ポインタはキューの第１のパケットの第１のセルに関連付け
られた指名子８１２を指し、テール８１１は受信キューの最終パケットの第１の
セルに関連付けられた指名子８１５を指す（記述子は、それぞれＤＲＡＭ３５ま
たは３６の１２８バイトのバッファにマッピングする）。図示するように、キュ
ーに入れられたパラメータは必ずしも完全である必要はないが、このパケット志
向の実施例では、ＭＡＣバスから受信したデータ・セルは、キューの最後ではな
く、バースト・ヘッダのＲｃｖＣｋｔによって識別されるそのパケットに「付
加」される。受信動作において、ＱＭＤｅｓｃｒｉｐｔｏｒＳＲＡＭは、バッファ記述
子テーブルと受信コンテキスト（または回路）テーブルの中に編成される。この
バッファ・テーブルすなわちリストは２つの４バイトの語を含む記述子を有し、
語０はＲＡＭＢＵＳ（登録商標）ＤＲＡＭのデータ・バッファのバッファ・アド
レスを含み（したがってこのバッファ・テーブル項目は暗黙バッファである）、
語１はそのバッファ・テーブルの別の記述子へのポインタを含む。初期化の際、
このバッファ・テーブルは「フリー・バッファ・テーブル」であり、そこでは第
１のフリー・バッファの指名子をヘッド・ポインタによってＱＭハードウェアが
指し、その第２の語が次のフリー・バッファ記述子を指し、第２の語のヌル・タ
ーミネータを含む最終フリー・バッファ指名子までこのように反復的にリンクさ
れる。データ・セルがＭＡＣバスからＱＭに提示される際、ＱＭはその回路ＩＤをそ
の正規のヘッダまたはバースト・ヘッダから抽出し、その回路の活動状況に関す
る情報をもたらす受信コンテキスト（回路）テーブルの項目に対してチェックす
る。ＳＯＰが検出されると、受信コンテキスト・テーブルの項目（８バイト・回
路）が作成され、ポインタ（現行バッファ）が次のフリー・バッファ識別子を指
すように入力される。このセル・データは関連するＲＡＭＢＵＳ（登録商標）Ｄ
ＲＡＭバッファに書き込まれる。フリー・バッファ・リスト・ポインタは、「現
行バッファ」が割り当てられた後、次のフリー・バッファ指名子に移動される。受信したセルがＳＥＰでない場合、バッファ指名子の第２の語は次のフリー・
バッファ指名子を指し、関連するバッファを事前割当てし、次のバッファ項目の
第２の語に「０」が書き込まれる。受信したセルがＳＥＰまたはＥＯＰである場合、このバッファ指名子の第２の
語はそのパケットの第１のバッファ指名子を指すようにセットされ、結果として
生じるパケットを定義するリンク・リストが受信コンテキスト・テーブルからリ
ンク解除される。従って、ＭＡＣバス上にインターリーブされる場合がある同一回路ｉｄと共に
受信されたセルは、事実上、リンク・リストによってパケット内に再構成され、
先導するセルが切断動作で送信されているときでさえその一部は不完全な場合が
ある。後者の場合、図３０Ｂに示すように、受信コンテキスト・テーブル８２０
の現行バッファは、データ・セルがロードされるべきバッファに対応する次のバ
ッファ記述子８３３を指し、バッファ記述子８３３は、パケットの他のセルの記
述子８３２、８２２、および８２１にリンクされている。この記述子の１つ記述
子８３２は、送信コンテキスト・テーブルの回路項目の現行バッファ８２１とし
てリンクされている。送信コンテキスト・テーブルの回路項目が経路指定情報を
提供するので、記述子８３３に関連付けられたバッファにその後に配置されたデ
ータは「行く先を知っている」。このリンク管理システムは、「切断」すなわち
パケットの他の部分をまだ受信中にそのパケットの一部を送信することを可能に
する。６．リレー・エンジン処理／フロー・マッチング（ＦａｓｔＰａｔｈ（商標）
）ＳＯＰのリンクされた記述子の受信キューはＲＥ４０による処理を待つ。ＳＯ
Ｐセル自体は、メモリ空間が使用可能になると、リレー・エンジンによって処理
される１６個の１２８バイトのレジスタの「循環」ＦＩＦＯ３９４にロードされ
る。これは、ＳＯＰセルの処理に続くポインタ・システムによって実施され、そ
のレジスタが一杯になるまで（第２のポインタが図１９の受信ポインタに「追い
つく」とき）セルを加え、次いでヘッド・ポインタによって指されたセルの処理
が完了し、ドロップされたときだけ（かつ、受信ポインタが送信ポインタに「後
れを取った」とき）、別のセルを付加する。ＲＥの動作は４ステージのパイプラインを中心とする。パイプラインは、特に
高速ハードウェア設計における、長年に亘る当技術分野の用語であり、付随的に
言及する以外は本明細書でこれ以上説明はしない。ＲＥのタスクは、記憶されて
いるパケットの再送信を経路指定しスケジュール管理するために、フレーム・フ
ローの最良の転送を行い、それに従って転送情報をＱＭに提供する方法を決定す
ることである。この４つのステージをここで簡単に説明し、次いでフローを識別
するためのパターン・マッチングを実施するために使用されるハッシュ関数およ
び署名関数のより詳細な説明を続ける。第１のステージは、ヘッダがハッシュ・エンジンによって処理されるのと平行
して、完全なヘッダ情報（ＳＯＰセル全体）を「循環」データＦＩＦＯに記憶し
、そのパケットが、経路指定情報およびスケジュール管理情報が既にそのために
開発されている既存のフローの一部であるかどうかをチェックするためのパター
ン・マッチング関数を実施するためにハッシュ値および署名値を計算する。第２のステージは、ＨａｓｈＴａｂｌｅＬ１３９１にアドレスするため
に使用されるＨａｓｈ値を受信する。このテーブルで有効な項目が見つかると、
Ｌ１Ｔａｂｌｅからの署名が、Ｈａｓｈｅｄデータの計算された署名と比較さ
れる。一致した場合、ＨａｓｈＴａｂｌｅのＦｌｏｗＴａｇ（図示せず）が
、パイプライン処理されるＦＥ／ＲＥハードウェアの次のステージに有効なヒッ
トが見つかったという指示と共に提示される。ＦｌｏｗＴａｇは、そのフロー
に関する情報が記憶されているメモリのテーブルへの２４ビットのインデックス
である。この情報には、本明細書各所で記載するように、他のフロー関連情報と
共にパケットを転送する１つまたは複数の回路が含まれる。有効ＦｌｏｗＴａｇポインタ（指された内容をリンクする）は、この好まし
い実施形態で説明されるパターン・マッチング関数の好適な結果である。Ｌ１でマッチが見つからない場合、外部Ｌ２Ｔａｂｌｅ４５上でサーチが実施
される。前記のように署名が比較され、Ｌ２テーブルのＦｌｏｗＴａｇが次の
ステージに提示される。次のサーチを容易にするために、Ｌ２項目はＬ１テーブ
ルに書き込まれる。Ｌ１とＬ２のどちらにもヒットがない場合、計算されたハッシュおよび署名は
、ヒットが発見されなかったという指示と共に次のステージに提示される。第３のステージは前記情報を受信し、ヘッダのルックアップが成功したかどう
かを判定する。成功した場合、そのヘッダ・データは、適用されるプロトコル規
則に従って更新され、そのパケットはフロー情報に従って転送される。しかし、
そのヘッダがＴＣＰ（レイヤ４転送制御プロトコル）ＳＹＮパケットまたは別の
プロトコルの接続パケットの相当する開始であることが判明すると、またはその
フレームが知られている接続フローの一部でない場合、そのパケットはそのフロ
ー情報に従って転送されない。それらの場合、ＲＥは、完全な事前ハッシュされ
たヘッダを復号化することによってそのフロー・フレームを経路指定するように
働く。このプロセスにおいて、有用なフロー情報を作成し、ステージ１でハード
ウェアによって得られたハッシュ値および署名値を使用してＬ２ＨａｓｈＴ
ａｂｌｅにそれを指すタグを挿入する。このパイプラインの第４のステージでは、ＦｌｏｗＴａｇによって供給され
る情報または、ＲＥの完全な事前ハッシュされたヘッダの復号化によって供給さ
れる経路指定情報に従って、ヘッダは、指定のキューに送信するためにキューに
入れられるようにＱＭに戻される。そのフローの後続パケットを転送するための
情報を統合するために、ＲＥは、Ｌａｙｅｒ２およびＬａｙｅｒ３のヘッダに加
えてアプリケーション層データを検査する。さらに詳細には、図４を参照すると、パケットが受信されたとき、ＱＭ３０は
（ＮＬフィールドから判定されるような）１２８バイトの長さである場合がある
有用なヘッダを、そのヘッダ・データをＲＥのデュアルポート循環バッファにロ
ードすることによって、ＦＥ／ＲＥに提供する。図４を参照すると、ヘッダ・デ
ータはＱＭ１００からＭＵＸＩｎ１０２送信され、ＲＥ４０のＦＩＦＯスタッ
クＤＦに配置される。ＲＥは、１２８ビット項目の既に記憶されている順序付け
られたデータ・アレイにインデックスするためにネットワーク・リンク・バイト
を使用する。ここでは、各ビットは受信した完全なヘッダ・データ・バイトの１
つに対応する。１つの１と共にビットに対応するバイトが、ハッシュ関数および
署名関数によって抽出、処理される。バイト・ストリングは、複数の奇数個の４
バイトのストリングを提供するために、終端部がゼロによってパディングされる
。この好ましい実施形態では、１２８ヘッダ・バイトの６４バイトまでをハッシ
ュ／署名動作によって処理することができるが、他の好ましい実施形態を有利に
するためにはこれより少なくてもより多くてもよい。ハッシュ関数および署名関数は、異なる乗数が使用されることを除いて同一で
ある。しかし、別の好ましい実施形態では、有利にするために、異なる乗数およ
び異なる除数の他の組合わせを使用することも可能である。図４を参照すると、ＨａｓｈＰｒｅｐｒｏｃｅｓｓｏｒ３９９は、１２８バ
イトのヘッダ・データからの選択バイトを入力する。この選択バイトは、３２ビ
ット・ワード（上記のように４の倍数）のｎ番目を形成する。この３２ビット・
ワードのシーケンス中のビットは、ガロア体、ＧＦ［２］、すなわち２のガロア
体（ガロア体は当分野で知られている）で多項式として扱われる。この好ましい
実施形態では、この多項式を無作為の３２ビット多項式で乗算し、注意深く選択
した３２次の多項式で除算し、その結果３２ビットの剰余が得られる。上記で使
用した除数は、既約（ｉｒｒｅｄｕｃｉｂｌｅ）および基本（ｐｒｉｍｉｔｉｖ
ｅ）両方になるように選択される（既約および基本は当分野で知られる用語であ
る）。剰余ビットのサブセットは、ハッシュ・テーブルへの実際のインデックス
として使用される。ビット５から０は、オンチップＬ１キャッシュ３９１に割り
当てられるアドレスである。ビット１６から１は、オフチップＬ２ＲＡＭ４５中
の６４Ｋ位置をアドレス指定するのに使用される。この好ましい実施形態で使用する除数は、ｘ¹²＋ｘ⁷＋ｘ⁵＋ｘ³＋ｘ²＋ｘ＋１
であるが、既約かつ基本であれば他の除数を使用してもよい。着信フレームのＦｌｏｗＴａｇおよび／または宛先を識別するＨａｓｈＴ
ａｂｌｅの内容の編成は以下の通りである。ＨａｓｈＴａｂｌｅ１はそれぞれ６４ビットである６４ワードを含み、チッ
プ上に存在して、少数のフローだけがアクティブである共通のオカレンスにおけ
る値のリターンを最適化する。これより大きなテーブルを使用することもできる
。図２０Ａおよび図２０Ｂを見ると、各ワードで、ビット３１〜２４は、ビット
３１が真であれば有効なエントリを示す状態を形成している。ビット０〜２３は
２４ビットのＦｌｏｗＴａｇを形成し、ここには特定フローに関する情報が記
憶される。このタグは、パケットの転送先である１つまたは複数の回路について
の情報を指すポインタである。ＦｌｏｗＴａｇを獲得することは、ＲＥの主要
なタスクである。ＨａｓｈＴａｂｌｅはビット６３〜３２に３２ビットのシグ
ニチャも含み、これは衝突が発生しておらず、また結果が有効であることを保証
するために使用される。ＦｌｏｗＴａｇルック・アップの有効性をさらに確実
にするために、あいまいでない識別を行えるように事前にハッシュしたヘッダ・
データが記憶される。Ｌ１Ｈａｓｈテーブルで一致がない場合、当システムは、ハッシュ済みの結果
ビット１６〜０を使用して、６４ＫＨａｓｈＴａｂｌｅＬ２にインデック
スする。各位置は６４ビット幅になる。ビット３０はＨａｓｈＢｕｃｋｅｔポ
インタであり、このビットがゼロの場合は、Ｌ２テーブル中のビットをＬ１テー
ブルと同じように機能面から編成する。このＨａｓｈＡｄｄｒｅｓｓに有効な
エントリが１つある場合、当システムは、Ｌ２ビット０〜２３をフロー・テーブ
ルへのインデックスとして、フロー・タグを入手する。図２０Ｂを参照されたい
。このＨａｓｈＡｄｄｒｅｓｓに有効エントリがない場合、有効ビットである
Ｌ２ビット３１をゼロにセットする。このハッシュ・アドレスに２つ以上のエン
トリがある場合は、状態ワード・ビット３０が１にセットされ、当システムは、
Ｌ２ビット５５〜３６をＨａｓｈＢｕｃｋｅｔへのポインタにする。ＨａｓｈＢｕｃｋｅｔは６４ビット・ワードのエイリアス・アドレスを８つ
まで保持する。衝突ビット２９が１の場合、エイリアス状態はハッシュおよびシ
グニチャ両方の動作について存続し、また有用な情報を得ることができないので
、ハッシュ機構はそれ以上の分解を行わない。この時点で、２つの競合フローは
プロセッサに戻され、ルーティング情報を求めてトライ検索を行う。Ｈａｓｈ
Ｂｕｃｋｅｔ中の８ワードは連続して検索され、この検索を容易にするために、
アドレスはテーブルへの最下位のインデックスから始まって連続している。９つ
以上のエントリがＨａｓｈＢｕｃｋｅｔに向けられる場合、当システムは元に
戻り、トライ・ルーチンによりオーバーフローを検索する。トライ検索はコプロ
セッサ３９０を使用し、ルーティングおよびブリッジング用の大規模トライデー
タベースとして編成されている。シグニチャおよび／またはハッシュ衝突の発生は監視することができ、それが
過度である場合は、各乗数を変更することができる。このように変更すると、そ
の結果、ネットワーク中で遭遇する所与のアドレス・セットに対してより有効に
ランダム化を行うことができる。ハッシングおよびシグニチャ・ルーチンの結果はある状況では使用することが
できない。ＴＣＰＳＹＮまたはそれと同等の「接続の開始」パケットが到着す
るとき、あるいは接続フローに属さないパケットが見つかった場合、あるいはそ
のパケットが高セキュリティまたは他の特別モードの一部であるときなどに、接
続が開始される時がその例である。このような状況が見つかると、当システムは
トライ検索に戻ることができる。一般に、フロー中の後続パケットの処理は、上記のようにソフトウェア・パタ
ーン・マッチングを最適化することによって加速される。ＲＥは、アドレッシングとともに転送するのにどのキューにセルを置くべきか
を指定する命令を含む情報を戻す。ＱＭは情報を受け取ってセルを配置するが、
このセルは、送信するリスト上で、受信中であるかまたは受信されたパケットの
内容を形成するリンクされたリストに記憶される。７．送信スケジューリングＲＥはＱＭをプログラミングし、このＱＭは、種々の回路についての管理され
た優先順位により、１６，０００，０００送信キュー（２４ビット）までのＱＭ
記述子ＳＲＡＭのリンクされたポインタによって仮想的に進展する。送信段階のコアはＴｒａｎｓｍｉｔＣｏｎｔｅｘｔＴａｂｌｅであり、こ
れは回路によって編成され、図３５に示すように各回路につき４つの４バイト・
ワードがある。ワード０は、クレジットｓｙｎｃビット、送信クレジット用の７
ビット８１２（回路に対してクレジットが存在しないと送信は行われない）、パ
ケット・ビットのスタート・ビット８１４、および送信する次のバッファ（次の
バッファＩＤ）を指定する２３ビットを含む。ワード１８１６は、８つのフラ
グ・ビット８１８を含む。図３５Ａは、これらのフラグ・ビットの意味を示して
いる。ビット７はパケットがシングル・バッファであることを示し、ビット６は
、通例はＣＲＣエラーによりパケットが不良であり、ＭＯＭがそのパケットを中
止すべきであることを示し、ビット５はそのパケットがモニタ・キューからデキ
ューされ、そのパケットはトラフィック分析のためにどこか他のポートかまたは
バックグランウンド・エンジンにオフ・ロードできることを示し、ビット４はそ
のパケットが「複数所有」されており、２つ以上の回路に送信されうることを示
し、ビット３〜０は、１６バイトのグループ中の１２８バイトまでのバイトのバ
ッファ長を示している。ワード１の残りの２４ビットは、第１キューのアドレス
を含んでいる（各回路は１、２、４、８、あるいは１６個の関連するキューを有
することが可能である）。送信コンテキスト・テーブルのワード２８２０は、
モニタ・キューが添付されていることを示す１ビット８２２、キュー・サービス
・ポリシーを示す４ビット、および参照カウントを示す３ビットを含んでいる。
図３５Ｂは、この４つのキュー・サービス・ポリシー・ビットの意味を示してい
る。可能な指示は；１がキュー、２、４、８、あるいは１６が静的キュー；また
は２、４、あるいは８が重み付けラウンド・ロビン・キュー、；または２、４、
８、および１６の２分の１が静的キュー、２分の１が重み付けラウンド・ロビン
・キュー、などである。下記で述べるように、静的キューが最高の優先順位を有
し、その次に重み付けラウンド・ロビン・キューが続く。ワード３はスタンバイ
・スケジューラ・コントロール・ワードを含み、これは「次のｃｃｔＩＤ」「ペ
アレントｃｃｔＩＤ」（スタンバイ・スケジューラ回路にのみ使用される）、状
態ビット（アクティブまたはアイドル）、およびスタンバイ・スケジューラ・イ
ンターバルを含む。図３６に示すＱｕｅｕｅＴａｂｌｅは、ＴｒａｎｓｍｉｔＣｏｎｔｅｘｔ
Ｔａｂｌｅと連携して働き、キューごとに４つの４バイト・ワードを含む。ワ
ード０は、２バイトのスタンバイ回路ＩＤ（下記で説明する）、および２バイト
のキュー・サマリー・ビット（１６のキュー番号ごとにのみ）を含む。ワード１
は、キュー・サイズを示す２バイト、および２バイトのオーバーフロー・カウン
タＩＤを含む。ワード２はスタンバイ・キューの数を示す５ビット・フィールド
と、ヘッド・オブ・キュー・ポインタの２４ビットを含む。ワード３は、２４ビ
ットのテール・オブ・キュー・ポインタを含む。好ましい実施形態では、ヘッド・オブ・キュー・ポインタで始まるＳＯＰセル
を最初のＳＯＰに（かつテール・ポインタを最後のＳＯＰに）リンクすることに
よってキューが形成され、パケットの新しいセルがパケットのセルに追加される
ことを思い出されたい。したがって、図３７を参照すると、リンクした記述子８
６３で表すように、ＱｕｅｕｅＴａｂｌｅ８５０のキュー１６には４つのＳＯ
Ｐがあり、キュー１７にはリンクした記述子８６４で表すように２つのＳＯＰが
ある。リンクした記述子８６２で表すような不完全なパケットはそれでもなお送
信することができるが（「カットスルー」を許可することにより）、最後の記述
子がそれに関連するバッファが空であることを示すと送信は回路上で停止し、そ
れにより、回路上でパケット順序を保つという規則を維持する。キュー・ポリシーは、データ・パケット送信の優先順位づけ、およびスケジュ
ーリングを可能にする。したがって、固定した静的優先順位下では、特定キュー
にあるパケットはすべて別のキューにあるパケットよりも先に送信される。重み
付けラウンド・ロビン・キュー方式では、１つのキューにある特定数のパケット
が送信され、次いで次のキューにある特定数のパケットが送信され、その後も同
様である。これにより、低い優先順位クラスを「窮乏」させることなく、トラフ
ィックのクラス（キュー）に相対的な優先順位を持たせることが可能になる。静
的キューがサービスされる時に、静的キューが優先権を有する「ハーフ・アンド
・ハーフ」方式が提供される。使用中の回路についてのＳｃｈｅｄｕｌｅＴａｂｌｅは継続的に走査される
。図３７に示すように、このテーブルは、ＰｒｉｍａｒｙＳｃｈｅｄｕｌｅ
ＴａｂｌｅＡ８６５、ＰｒｉｍａｒｙＳｃｈｅｄｕｌｅＴａｂｌｅＢ
８６６、およびＳｅｃｏｎｄａｒｙＳｃｈｅｄｕｌｅＴａｂｌｅ８７０を
備えるＰｒｉｍａｒｙＳｃｈｅｄｕｌｅＴａｂｌｅからなる。Ｐｒｉｍａｒ
ｙＳｃｈｅｄｕｌｅＴａｂｌｅはオンチップに位置し、それぞれ６４のエン
トリを有する、２つの先に触れたサブテーブルからなる。ＰｒｉｍａｒｙＳｃ
ｈｅｄｕｌｅＴａｂｌｅＡ中のスロットは、すべてのＳｃｈｅｄｕｌｅＴ
ｉｍｅ時間が「時を刻む」たびに１回訪れられる。ＰｒｉｍａｒｙＴａｂｌｅ
Ａエントリは、ＰｒｉｍａｒｙＳｃｈｅｄｕｌｅＴａｂｌｅＢのエント
リへの６ビット・インデックスを含む。図３７に示すように、ＴａｂｌｅＢエ
ントリはどれも、それをポイントするＴａｂｌｅＡエントリを２つ以上有する
。ＰｒｉｍａｒｙＴａｂｌｅＢエントリは２次テーブルのサイズを含み、こ
のサイズが「０」に等しくない場合は、２次テーブル８５７へのオフセットと、
２次テーブル８６８の基底アドレスをも含む。サイズが「０」に等しい場合、残
りのフィールドは、「ＵｓｅＰａｒｅｎｔＣｉｒｃｕｉｔ」ビット８７１
、ＰａｒｅｎｔＣｉｒｃｕｉｔＩＤ８７２、およびＣｉｒｃｕｉｔＩＤ
８７３になる。セル送信イベントは、ＣｉｒｃｕｉｔＩＤを有するスケジュール・テーブル
・エントリが見つかると起動される。適切なＣｉｒｃｕｉｔＩＤをＳｃｈｅｄ
ｕｌｅＴａｂｌｅに入力することにより、セル送信順序付けパターンが生成さ
れ、これは送信イベントの回路個々の比率に応じて回路に帯域幅を有効に割り当
てる。ＳｃｈｅｄｕｌｅＴａｂｌｅの階層的性質は、広範囲の割合をプログラムす
ることを可能にする。これは、サブテーブルの３レベルまで「チェーニング」す
ることによって行われる。ＰｒｉｍａｒｙＴａｂｌｅＢエントリのサイズ・
フィールドがゼロでない場合、このエントリは、オフチップに位置するＳｅｃｏ
ｎｄａｒｙＴａｂｌｅへのポインタを含む。ＳｅｃｏｎｄａｒｙＴａｂｌｅ
８７０は、エントリを２５５個まで有することが可能であり、このエントリは
それぞれＴｅｒｔｉａｒｙＴａｂｌｅをポイントするか、またはＣｉｒｃｕｉ
ｔＩＤを含むことができる。テーブル・チェーニングに遭遇すると、オフセッ
ト・フィールド８６７を使用して、低レベル・テーブルでどのエントリにアクセ
スすべきかを追跡する。このフィールドを訪れるたびに、テーブル・サイズを法
としてオフセットが増分される。Ｓｔａｎｄ−ｂｙＳｃｈｅｄｕｌｅｒ（ＳＢＳ）は、２次スケジューリング
機構である。その名前が意味するように、Ｓｔａｎｄ−ｂｙＳｃｈｅｄｕｌｅ
ｒは、スケジュール・テーブルから後回しにされた帯域幅についてのトラフィッ
クをスケジュールする。スタンドバイ・トラフィックを伝送することができる２
つのケースがある。すなわち、（１）伝送イベントが、回路に対してデータを伝
送しなかった（クレジットの不足またはデータの不足）ケースと、（２）スケジ
ュール・テーブル中にプログラムされるＣｉｒｃｕｉｔＩＤがゼロであり、そ
れによって帯域幅うちのある量がスタンドバイ・トラフィックに事前割り振りさ
れるケースである。ＳＢＳは、ＣａｌｅｎｄａｒＱｕｅｕｅアルゴリズムのバージョン、本質的
にはリンクされたリストの配列として実装されるスロットされたタイム・リング
を使用する。配列の各要素は、異なるタイム・スロットに対応する。各タイム・
スロットには、この時にセルを送信するようにスケジュールされる回路のリスト
が装着される。スロット・インデックスは時間と共に進む。人気のあるスロット
が見つかったとき、そのスロットでのリストの先頭の回路についてのセルを伝送
することができる。セルが特定の回路に対して伝送されるとき、その回路上の次
のセルに対する適格時間が計算され、別のタイム・スロットにマップされる。図３８を参照すると、ＳｔａｎｄｂｙＳｃｈｅｄｕｌｅｒＣａｌｅｎｄ
ａｒＴａｂｌｅ８７８は、６４個のエントリからなるオンチップ・テーブル
である。各エントリは、特定のスロットに装着される回路のリンクされたリスト
を記述するヘッド・インデックスおよびテール・インデックスを含む。リンクは
、ＴｒａｎｓｍｉｔＣｏｎｔｅｘｔＴａｂｌｅ８６０中のｗｏｒｄ３の
ＮｅｘｔＣＣｔＩｄフィールド中に格納される。スロット・インデックス８７
７は、ＱＭコア・クロックに対応する期間と共に進む。ＳＢＳの機会が生じたと
き、伝送するための次の回路が、スロット・インデックスの現在値によって表さ
れる時点から前方にスキャンすることによって見つかる。送信するための次の回
路は、次に人気のあるスロットに対するリストの先頭にある回路である。次の回
路が見つかった後、その回路がリストから待機解除され、再スケジュールされる
。再スケジューリングは、回路を送信すべき次のスロットを計算することによっ
て実行される。次のスロットの計算は、ＴｒａｎｓｍｉｔＣｏｎｔｅｘｔＴ
ａｂｌｅ中のＷｏｒｄ３のＳＢＳインターバル・フィールドに基づく。このフ
ィールドは、回路についての連続する伝送イベントの間のカレンダー・テーブル
・スロットの数を表す６ビットの数である。回路についての次のスロットは、テ
ーブル・サイズを法として、現スロットとこのインターバルとの和である。ＳＢ
Ｓの正味の効果は、重み付けＷｅｉｇｈｔｅｄＦａｉｒＱｕｅｕｅｉｎｇア
ルゴリズムの近似である。所与の回路の重みは、そのＳＢＳインターバルの逆で
ある。Ｓｔａｎｄ−ｂｙＳｃｈｅｄｕｌｅｒの別の態様は、「アクティブ」な、す
なわち送信するためのデータを有する回路のみに基づく動的帯域幅割振りを実行
できることである。多くの回路をスタンドバイ帯域幅に対して可能にすることが
できる。しかし少数の回路のみが、どの時点でもアクティブである可能性が高い
。スタンドバイ帯域幅をより効果的に使用するために、ＳＢＳは、スケジューラ
中のアクティブな回路のみを保つ。ＳＢＳは、回路がアクティブになるか、また
はアイドルになったときに、ＱｕｅｕｅＴａｂｌｅを管理するプロセスからメ
ッセージを受信する。アクティブからアイドルへの移行は、パケットが待機解除
され、回路についてのすべてのキューが空になったときに行われる。アイドルか
らアクティブへの移行は、パケットがすべて空のキューを有する回路に対して待
ち行列に入れられたときに行われる。どんな回路もスケジュール・テーブルとＳＢＳの両方を同時に使用してスケジ
ュールすることができる。これは、ＡＴＭ利用可能ビット・レート（「ＡＢＲ」
）トラフィックに対して有用である。好ましい実施形態での「送信」は、パケット・ストリング（これは不完全であ
る可能性がある）をそのキューからリンク解除し（「待機解除」）、それを（図
３７に示す）ＴｒａｎｓｍｉｔＣｏｎｔｅｘｔＴａｂｌｅ８６０の現バッ
ファにリンクすることで開始する。次いでＴｒａｎｓｍｉｔＣｏｎｔｅｘｔ
Ｔａｂｌｅの回路エントリがポーリングされ、現バッファのバッファ・コンテン
トが（空でない場合に）対応する「回路」６３’に送信される。セル・データは
、以下に説明する「ピンポン（ｐｉｎｇ−ｐｏｎｇ）」方式に従ってＲＡＭＢＵ
ＳＤＲＡＭから読み取られる。パケットが完全に伝送されたとき、そのバッファは自由バッファ・リストに返
される。パケットの伝送の完了は、ｔｒａｎｓｍｉｔｃｏｎｔｅｘｔｔａｂ
ｌｅの次のバッファがパケットの第１バッファに関連するデスクリプタ８８０に
向けて送られるときに、図３９Ａのポインタ８８３を参照して、パケットの最後
のバッファのデスクリプタ８８２の第２ワードによって示される。次いで自由バ
ッファ・マネージャ（図示せず）は、ＳＯＰのデスクリプタ８８０の「所有者」
フィールドを調べることによって、他の（マルチキャスティングなどに対する）
「所有者」がいるかどうかをチェックし、図３９Ｂに示すように所有者がいない
場合（値が１である場合。そうでない場合は減分する）、自由バッファ・マネー
ジャは、デスクリプタ８９０の第２ワード中のバッファ・カウント８９１によっ
て自由カウンタ８９０を増分する。自由バッファ・マネージャは、自由バッファ
・リスト・ヘッド・ポインタを、自由バッファ・リストの先頭８９５から、デス
クリプタ８８０が指すデスクリプタ、すなわち第２セルのバッファのデスクリプ
タ８８１に移動し、デスクリプタ８８０のデスクリプタ・フィールド中に自由バ
ッファ・リスト８９６の前の先頭へのポインタを入力する。したがって図３９Ｂ
からわかるように、３つのバッファすべては自由バッファ・リストの先頭でリン
クされる。８．伝送クレジット・ループ好ましい実施形態では、多重クレジット・ループを使用することによって階層
的フローおよび輻輳制御方式を提供する。伝送のためにセルを受諾するための８
個の出力チャネルそれぞれについての、ＭＯＭチップの能力を示すクレジットの
システムが確立される。特定のチャネルについてのＭＯＭが、セルごとにパケッ
トを送信し、各セルが送信されるとき、そのＭＯＭは、前述のクレジット・ビッ
トを介して、別のセルをそのＭＯＭチップに送信できることを示す。図３１に示
すように、セルを送信している時のＭＯＭは、クレジット・カウント７６０を増
分し、ＱＭがセル７６２をＭＯＭに転送するときに、そのＱＭはクレジット・カ
ウント７６４を減分する。前述のように、クレジットは、適切なＭＯＭチャネル
・クレジットが保持されるように回路ＩＤを有する。この好ましい実施形態では
、４つの伝送セルを格納することができる。ＭＯＭは、その中でパケットがセル
から再組上げされるＦＩＦＯを有する。ＭＯＭチップからセルが伝送されるとき、ＱＭに送り返されるクレジットは、
最大長セルについてのクレジットである。それはセル・モードでは１７オクトバ
イト、またはパケット・モードでは１６オクトバイトにすることができる（パケ
ット・モードのときはＭＯＭがバースト・ヘッダを削除するからである）。しか
しＱＭは、最大セル・サイズ未満を送信する可能性がある。図３２は、ＭＯＭチ
ップに関連する各出力チャネルに対して重複するものであり、クレジットがＭＯ
Ｍチップ中で処理される機構を略図で示す。ヘッド・ポインタ７７０、テール・
ポインタ７７２、仮想テール・ポインタ７７４、およびパケット・ポインタの開
始７７６がある。この好ましい実施形態では、伝送ＦＩＦＯ中に５１２バイト・
ロケーション、または４つの全１２８バイト・ロケーションがある。図３２では
、６４個のスロットがあり、各スロット７７８は、象徴的に１オクトバイトを保
持する（この実施形態では６４オクトバイトはＦＩＦＯの記憶容量５１２バイト
に等しい）。初期設定時に、ＦＩＦＯは空であり、仮想テールは増分され、ＦＩＦＯロケー
ションを通って移動する。仮想テール・ポインタは、仮想テールがヘッド・ポイ
ンタに到達したか、またはヘッド・ポインタに到達することを試行するときに停
止する。仮想テール・ポインタが増分するごとに単一クレジットがＭＯＭチップ
中の送信クレジット・マネージャおよび受信クレジット・マネージャを介して送
信される。これらのクレジットは、この回路についてのＱＭ中に蓄積される。Ｍ
ＯＭがこの回路へのセルを受信したとき、テール・ポインタ（このポインタは実
際のセル長を表す実情報を指す）は増分される。ＱＭがセル全体未満を送信した
とき、仮想テール・ポインタは補正される。ＭＯＭが実際にセルを伝送するとき
、ヘッド・ポインタは増分される。ＭＯＭがセルを送信するとき、ヘッド・ポイ
ンタは、仮想テール・ポインタおよび実テール・ポインタから移動し、ＦＩＦＯ
中のルームを空ける。最大セル未満を送信し、ＱＭによって補正された可能性が
ある仮想テール・ポインタが、ヘッド・ポインタを循環することなく伝送ＦＩＦ
Ｏ中の最大セル長を増分することができるとき、クレジットはＱＭ中に送信され
、確立される。他の残りのポインタ、パケット・ポインタ７７６の開始は、１つの重要な機能
を有する。その機能は、パケットの開始の開始ロケーションを保持し、その結果
イーサネット・ケーブル上でコリジョンがある場合に衝突したパケットを公開さ
れた明細書に従って再伝送することができることである。図２に関して、仮想テール・ポインタは、伝送クレジット・マネージャによっ
て制御され、実テール・ポインタは、伝送ＦＩＦＯ「プロデューサ」によって制
御され、「コンシューマ」は、パケット・ポインタのヘッダおよび開始を制御す
る。すべてのポインタは、比較およびクレジットの発行のために、すべての伝送
クレジット・マネージャにとってアクセス可能である。図３３に、どのようにＭＯＭＦＩＦＯ、２ポート、６４オクトバイト・メモ
リが制御されるかを示す。アービタ７８０は、ＱＭからロードされたセルを追跡
するために、「プロデューサ」側からのＦＩＦＯの最も顕著な３つのアドレス・
ビットを制御し、５１２のロケーションをアドレス指定するために必要な全９ビ
ットの下側の６ビットは、テール・ポインタ７８２（８つのうちの１つを示す）
によって制御される。仮想テール・ポインタ７８４は実データを指さない。カウ
ンタ機構によって、クレジット・マネージャは、ＱＭに送信するクレジット数を
決定することができる。別のアービタ７８６およびヘッド・ポインタ（８つのう
ちの１つを示す）は、パケットがＭＯＭチップによって物理的に送信されるとき
にＦＩＦＯをアンローディングすること、ＦＩＦＯを空けることを制御する。ヘ
ッド・ポインタ７８８は、ＦＩＦＯのアンローディング側からＦＩＦＯの下側の
６ビットを制御する。コンシューマは、データが送信されたときにヘッド・ポイ
ンタを増分する。ヘッド・ポインタのヘッド、テール、および開始は、伝送クレ
ジット回路が利用可能である。図２６を参照すると、イニシアル・カノニカル・ヘッダの第１オクトバイトの
部分７４２が、かつ、図２７を参照すると、バースト・ヘッダが、２つのクレジ
ット・フラグ、「シンク」フラグおよび「親」フラグを含む。シンク・フラグは
、電源投入時に、前述のクレジット・サイクル・オペレーションを適切に確立す
るために使用される。電源投入時に、ＭＯＭは、１０ミリ秒ごとにシンク・フラ
グをＱＭに送信する。ＱＭが電源投入されたとき、ＱＭは、シンク・フラグを探
し、ＱＭを見つけたとき、シンク確認をＭＯＭに送信する。次いでＭＯＭは、前
述の何らかのクレジットをＱＭがクレジットを受諾す準備ができていることの保
証と共に送信する。ペアレント・フラッグは、ＭＯＭチップのチャネルにマルチプレックスされた
物理的通信パスが複数あるので、必要となる。ＭＯＭチャネルに接続されている
通信回路が１つだけで、ＭＯＭがＥｔｈｅｒｎｅｔに接続されているとき、クレ
ジット・システムは、上記のように働くが、ＭＯＭチャネルへの多数の別々のパ
スにより１つのＭＯＭチャネルに接続されたパスのそれぞれに対してクレジット
を維持する方法が設計される。このクレジット・システムの重要な態様は、１つ
のＭＯＭチャネルに接続された複数の通信パスのどれをとっても該複数通信パス
中の他のパスによってブロックまたはロックアウトされる可能性のないことを保
証する必要があることである。この実施形態で、図３４にＭＯＭチップ内の２つ
のＦＩＦＯチャネルを示す。ＦＩＦＯ８００は単一の通信パスで動作する。こ
の場合、ＭＯＭＦＩＦＯ８００は、単一の通信回路によるその動作を示すリ
ーフである。ＦＩＦＯ８０２は、ＦＩＦＯチャネルに関連付けられ、これは、
他のチップ、たとえば、本好適な実施形態のＤＡＤチップ８０４に接続されてお
り、ただし、ＤＡＤはさらに他の８個の通信回路８０４にさらに接続されている
。この場合、ＦＩＦＯ８０２は、「ペアレント」と称され、ＤＡＤに接続された
該８個の通信回路はリーフである。この回路では、ＱＭは、ＭＯＭ内のペアレン
トＦＩＦＯに接続された個々のリーフに対するクレジットを維持する。このよう
にして、ＱＭは、送信ＦＩＦＯが満たされ、さらなるセルを受入れ不可能になる
時を知ることになる。続いて、ＱＭは、ペアレントおよびリーフ内のクレジット
を単にポーリングすることによって、他のリーフにセルを転送し、結果的にセル
を送信することになる。このやり方では、１つのリーフが他のリーフのサービス
を阻止することはできない。図３８を参照すると、ＱＭ内のＳｃｈｅｄｕｌｅＴａｂｌｅ８６６には、
特定の回路に関連するペアレントがあるかどうかの指示８７１がある。ペアレン
トとして作用するＭＯＭは、ペアレントＦＩＦＯ、および該ペアレントに関連す
るリーフのそれぞれに対するクレジットを送る。ＰａｒｅｎｔＣｒｅｄｉｔＴａｂｌｅ８７５は、ＱＭ内の６４エントリ
・オンチップ・テーブルである。各エントリは、「ペアレント回路」として扱わ
れているものに対するクレジット・カウントを含んでいる。回路がペアレント回
路に結合されているとき、それは、そのＴｒａｍｓｍｉｔＣｏｎｔｅｘｔＴ
ａｂｌｅクレジット・フィールドと、ＰａｒｅｎｔＣｒｅｄｉｔＴａｂｌｅ
内にあるそのペアレント・クレジット・フィールドとの両方で使用可能なクレジ
ットを有する場合にＭＡＣバスに対してセルを送信するだけである。セルが、ペアレントを備えた回路に送信されたとき、ＴｒａｎｓｍｉｔＣｏ
ｎｔｅｘｔＴａｂｌｅクレジットおよび関連するクレジットが減分される。ペ
アレント・チャネルからのペアレント・クレジット更新セルは、ＱＭに送り返さ
れ、これによってペアレント・クレジットを増分させる。スケジュール・テーブルは、回路を所与のペアレント回路に結合させるために
使用する。ＵｓｅＰａｒｅｎｔＣｉｒｃｕｉｔＩＤフィールド８７２は
、この目的に使用する。スケジュール・テーブル・エントリがＰビットのセット
を有する場合、これは、回路がペアレントを有し、ＰａｒｅｎｔＣｒｅｄｉｔ
Ｔａｂｌｅ８７５をインデックス付けするためにＰａｒｅｎｔＣｉｒｃｕ
ｉｔＩＤ８７２を用いるべきことを意味する。９．ＲＡＭＢＵＳ（登録商標）上の超高速アクセスＲＡＭＢＵＳ（登録商標）ＤＲＡＭ３５および３６は、オフ・ザ・シェル
フ（ｏｆｆ−ｔｈｅ−ｓｈｅｌｆ）の品目である。本発明では、それらは、この
デート通信用途に対し読取りおよび書込み帯域幅を最大限高める固有の方式で使
用される。本発明は、ＲＡＭＢＵＳ（登録商標）に対するインターフェース３０８を提供
し、これは、ＲＭＢＵＳ（登録商標）メモリの有効帯域幅を増やすために、デュ
アル・バンク・オーガニゼーション（ｄｕａｌｂａｎｋｏｒｇａｎｉｚａｔ
ｉｏｎ）を使用する。ＤｕａｌＦＩＦＯスタックはコントロ−ラとともに使用
されて、ＲＡＭＢＵＳ（登録商標）内の別々のＤＲＡＭバンクを交互にアドレス
指定する。ＦＩＦＯにより待ち時間が増え、ＲＡＭＢＵＳ（登録商標）を制御す
る電子機器のハードウェア・オーバヘッドが増えることになるが、書込みまたは
読取りが行われた一連のデータを保証する試みが代替バンクから来る。この方式
では、一方のバンクがプレチャージし、その間他方のバンクがアクセスされるこ
とになり、次いで該他方のバンクがプレチャジし、その間第１バンクがアクセス
されることになる。図４０を参照すると、ＲＡＭＢＵＳ９００がブロック形式で示されており、
これの中に、フェーズロック・ループ、ＰＬＬ、および２つのダイナミックＲＡ
Ｍバンク、ＤＲＡＭ１および２が示されている（それぞれ３６、３７）。ＲＡ
ＭＢＵＳ（登録商標）に入る、またはそこから出るマルチプレックスされたデー
タ／アドレス・バスは、付属のクロックを備えた基本的に８ビット幅のシリアル
・ポートである。ＤＡＲＡＭ３５および３６内のデータ・バッファの編成は、（１２８バイト
）の偶数データ・バッファすべてが一方のバンク上にあり、奇数のデータ・バッ
ファすべてが他方のバンク上にあるようになっている。アービタ９０２は、デー
タに関する様々なリクエストがＦＩＦＯスタック９０４および９０６に対してロ
ードされる順番を決定する。リクエスト内のバッファ・アドレスは、偶数または
奇数であり、偶数バッファを有するリクエストはＦＩＦＯ９０４にロードされ
、奇数バッファを有するものはＦＩＦＯ９０６にロードされる。 ????は空である条件では、リクエストは偶数または奇数の????にロードされ、
インターリーバ???はそのリクエストをコントローラ???に送る。リクエストは多
数であるため、????のリクエストがバックアップする。リクエストが両方の????
にバックアップしたら、インターリーバー???は????とその他から交互にリクエ
ストを受け取る?“ピンポン操作”?。これらバッファアドレスは交互に偶数と奇
数になるので、コントローラは??????の?つの異なるバンクに交互またはインタ
ーリーブ的にアクセスする。この操作で、第?バンクは第?バンクがプレチャージ
されているときにアクセスされ、次のアクセスで第?バンクは第?バンクがプレチ
ャージされているときにアクセスされる。この交互アクセスは実質的に??????のライティングまたはリーディングのため
の最速アクセスを提供し、両方の????スタックにリクエストが存在するかぎり??
????メモリのスループットを最大化する。一方、純粋に????ベースに存在するリ
クエストはバックツーバック偶数またはバックツーバック奇数リクエストで分数
を有するであろう。それでタイムアウトの分数はプレチャージされる。特定のリクエストに関する待ち時間は通常の方法で発生する。この方法は高ト
ラフィック条件で??????の最大利用を保証する。 ???バックグラウンドエンジン/イニシャリゼーション本願発明の重要部分は、モニターと他の重要決定時の???ポートでインターフ
ェースされる??の使用である。これで??????????とラーンアンドロック安全シス
テムにコンフィギュレーションとコントロール機能にアクセスさせる。図?において、ブーツ????? ?????はシステムのイニシャリゼーションとスタ
ートアップのために????にアクセスできるように提供される。ブーツ???インス
トラクションはパワーアップまたは完全システムリセットが存在するときにラン
する。ブーツは?? ??????のセクションに操作性があり、信頼できることをテス
トして確認する。このセクションは???コードと???????? ??????? ??????????
??が存在するところである。?????の最初の???????または???小数?アドレスは当
初の妨害ベクトルをホールドする。アドレス?????は???情報をホールドし、????
?はコンソールサポートインターフェースルーチンをホールドし、???????は???
アトリビュートテーブルをホールドし、?????????はブーツイメージをホールド
し、???????????はシクリックリダンダンシーチェック?????のブーツイメージチ
ェックサムをホールドする。この実施例では、残りの?? ??????は????イニシャ
リゼーションプロセスと平行にテストされるであろう。ブーツはまた、?????バックグラウンドエンジンカーネル?に、例えば、タイマ
ーからインテラプトを受け取らせるようにインテラプト構造とオペレーションを
テストする。次に、ブーツは???バス??をイニシャライズし、???バスに取り付け
られたチップにアドレスをアサインする。ブーツは次にバスのチップの??を決定
する。ブーツは発見されたチップの??を調べ、イニシャライザーは実行のために
ダウンロードされたブーツディレクトリ内に発見される。メインなシステムイメージは、例えば??メガバイトのシステムソフトウエアを
含んだコンパクトフラッシュ（登録商標）カードの???????????ストレージ??に存在する。ベーシック情報は???バスで????と?????及び??に移される。完全イメージは???チャンネルで移される。以上の説明は出願時の本願発明の好適実施例である。均等な部材と機能で置き
換えが可能である。ハードとソフトの多彩な混合適用が可能である。本願発明は
非常にフレキシブルであり、スケール調整可能である。 ???バルクトランスファーのスケジュールアプリケーションの形態によってはバルクデータを、例えば、?メールで添付
資料を付けて送ることができる。バルクデータトランスファーアプリケーション
からのパケットは出て行く回路?リンク?をコンジェストすることができよう。バ
ルクデータトランスファにより引き起こされるコンジェスチオン問題に対処する
保証されたプライオリティの高品質サービスが提供される。図??は本願発明の本実施例に使用される???インターネットプロトコール?パケ
ット????の図である。??パケット????は複数のインフォメーションフィールドを
有している。バージョンナンバーとヘッダレングスフィールド????はパケットが
属する??プロトコールのバージョンとパケットヘッダの長さを??ビットワードで
ホールドする。サービスフィールド????のタイプはホストにインターネット装置
?すなわち、スイッチまたはルータ?に対してどの種類のサービスが必要かを告げ
る。データレングスフィールド????はトランスミッションのデータバイト数をホ
ールドする。データバイトカウントはフローがバルクトランスファーであるかど
うかの決定をする。アイデンティファイヤーフィールド????はどのパケットに新
規に到着したフラグメントが属するかを決定するのにデスティネーションホスト
によって必要とされる。データパケットの全フラグメントは同一の識別値を有し
ている。フラグメンテーションフィールド????はさらに多くのフラグメント情報
を与える。これには現行のフラグメントが属する現行データパケットのオフセッ
トを含んでいる。ライブフィールド????への時間はパケットライフタイムを限定
するのに使用されるカウンターである。プロトコールフィールド????はトランス
ポートインフォメーションをホールドする。ヘッダチェックサムフィールド????
はヘッダベリフィケーションのためにのみ有効である。ソース??アドレス????と
デスティネーション??アドレス????はソースとデスティネーションアドレス情報
を供給する。??オプションフィールド????はユーザに情報を加えさせる。トラン
スポートヘッダとデータフィールド????は???または???パケットをホールドする
。図??は?メールとファイルトランスファーのごときバルクデータのトランザク
ションに典型的である????トランスミッションコントロールプロトコール?パケ
ット????のプログラムである。???は?つのホストにコネクションとデータの交換
ストリームを確立させる。???はさらにデータの搬送を保証し、データパケット
が送られたときと同じ順序で搬送されることを保証する。図?を解説する。???リレーエンジン???のブロック図が提供されている。????
の主要な機能は???キューマネージャ???からインターフェース??で受領されたキ
ャノニカナイズされたパケットヘッダを検査し、パケットが知られたフローに属
するかどうかを迅速に決定し、適当なスケジュール処理のためにインターフェー
ス??でインストラクションを提供することである。??コードとデータ??????の特
殊なハンドラー????はフローのパケットが到着するときにデータバイトの蓄積デ
ータバイトカウントをホールドする。??????はフローがバルクデータトランスフ
ァーであるかどうかを決定するためにデータバイトカウントが比較されるしきい
値????をもホールドする。フロー決定は、知られたフローがデータのバルクトランスファーであるかどう
かの決定を行うことを含んでいる。????はそれぞれのフローのための蓄積データ
バイトカウントを所定のしきい値と比較する。もしデータバイトカウントがしき
い値以上であればフローはバルクトランスファーであり、????は????にサービス
品質を低下させ、さらに時間が重要なデータにスケジュールサービスを継続的に
受領させる。もしデータバイトカウントがしきい値以下であれば、フローには非
バルクトランスファー品質のサービスが提供される。層?/層?情報は所定のパケット用の出て行く回路?リンク?の発見に使用される
。本願発明の本実施例ではシステムの全ての回路は??キューでセットアップされ
ている。別実施例では別数のキューが関与する。??キューのどれがパケットを配
置するかの決定はさらに高い層の情報?層????に基く。図?を説明する。レシーブ???????のデータセルはメインシステムパケットメモ
リ??????と??に配置され、???の基準ヘッダは???????でリレーエンジン??に送り
出される。そこで????????プロセスが実施され、フロー、プライオリティ及びポ
ートキュー???、???ごとにパケットの適当なキュー処理を可能にし、???トラン
スミットポート??’に送る。各受領されたパケットのデータバイトカウントはデ
ータバイトカウントバッファのそれぞれの識別フロー用に保存される。パケット
は特定のフローの一部として識別されるので、バッファー内のカウントは漸増す
る。図??はフォーワードエンジン????コードとデータ???????図??に配置されたフ
ローインフォメーションデータストラクチャー????、????と、アプリケーション
ポリシーレコード????の一部の図である。各フローは?つのインフォメーション
データストラクチャー????、????を有している。第?フローインフォメーション
データストラクチャー????はクライエントからサーバーへのフロー方向のためで
ある。第?フローインフォメーションデータストラクチャー????はサーバーから
クライエントへのフロー方向のためである。フローインフォメーションデータストラクチャー????、????は複数のフィール
ドを有している。プレハッシュデータフィールド????はハッシュ処理が行われる
前にデータパケットから引き出された情報をホールドする。引き出されたデータ
はフロー識別プロセスに使用されるものである。フローハンドラーフィールド??
??は所定タイプのフローに必要な追加プロセスを完成させるソフトウェアルーチ
ンへのポインターである。フローキューインストラクションフィールド????は特
定のキューにフローを配置するためのインストラクションを含み、特定のキュー
の数はフローキューナンバーフィールド????に保存される。フローバイトとパケ
ットカウンターフィールド????はフロー用のバイトとパケットカウントをホール
ドする。リバースフローデータフィールド????は?つのフローインフォメーショ
ンデータストラクチャー????と????をリンクさせる。クライエント/サーバーフ
ローインフォメーションデータストラクチャー????のリバースフローデータフィ
ールドはサーバー/クライエントインフォメーションデータストラクチャー????
へのポインターを有している。その逆もある。フローポリシーデータフィールド
????はアプリケーションポリシーレコード????へポイントするポインターをホー
ルドする。本実施例においては、両方のフローインフォメーションデータストラ
クチャーのフローポリシーデータフィールド????は同じポリシーレコードにポイ
ントするが、それらはそれぞれ異なるものにポイントさせることもできる。フロ
ーメインテナンスデータフィールド????は、データストラクチャーをスイッチ内
で整合させるソフトウェアオーバーヘッドを含んでいる。アプリケーションポリシーレコード????はスイッチを通過する各タイプのフロ
ーのハンドリングデータとパラメータをホールドする。図??に示すアプリケーシ
ョンポリシーレコードの部分は?フィールド、すなわち、しきい値フィールド???
?、スタートプライオリティフィールド????、エンドプライオリティフィールド?
???を有している。それらはバルクフローとサービス品質の決定に利用される。
もしデータバイトカウントがしきい値を超えるとフローはバルクデータトランス
ファーである。スタートプライオリティフィールド????はバルクトランスファー
の決定が行われる前にフローの開始で特定のフローに提供されるプライオリティ
を保存する。エンドプライオリティフィールド????はバルクトランスファー決定
が行われた後に特定のフローに提供されたプライオリティを保存する。これら?
つのフィールドは特定タイプのフローのための受領されるサービス品質のポリシ
ーパラメータをホールドする。図??はバルクトランスファー品質のサービスをスケジュールする方法のフロー
図である。第?パケットはスイッチ到着する?ブロック?????。フォーワードエン
ジン??は当初のパケットが属するフローのタイプを決定する?ブロック?????。変
化するプライオリティサービスを得るフローが?つのプライオリティキューの?つ
に指定される。フォーワードエンジンは特定された当初のプライオリティレベル
の特定フローのポリシーレコードをコンサルトする?ブロック?????。フローはポ
リシーレコード????のスタートプライオリティフィールド????で特定された特定
フローに指定される。フォーワードエンジンコードとデータ??????の特殊ハンド
ラー????はその特定フローから受領したバイト数をカウントし始める?ブロック?
????。このカウントはフローインフォメーションデータストラクチャー????のフ
ローバイトとパケットカウントフィールド????に保存される。このデータバイト
カウント値はしきい値と比較される?決定ブロック?????。もしデータバイトカウ
ントがしきい値を超えなければ、データパケットはフローのスタートでセットさ
れたプライオリティで処理を継続する。しかし、もしデータバイトカウントがし
きい値よりも大きければ、データフローは低いプライオリティキューに再指定さ
れ、フローの残りのデータパケットはポリシーレコードのエンドプライオリティ
フィールドで特定されたキューで処理される。フローは特殊ハンドラーから通常
ハンドラーへ移動される。バルクデータトランスファーフローの残りのパケット
は低いプライオリティキューで処理される?ブロック?????。これで、同じ回路に
進む他のアピリケーションフロー及びバイトしきい値を冒さない同じアプリケー
ションの他のフローによって必要とされるバンド幅が開かれる。本願発明を実施例を利用して解説した。これら実施例には本願発明のスコープ
内で改良及び変更が可能である。

【図面の簡単な説明】

【図１】本発明の好適実施例のブロックダイアグラム。

【図２】本発明の好適実施例のメディアインターフェイスＡＳＩＣ（ＭＯＭ）
のブロックダイアグラム。

【図３】本発明の好適実施例のキューマネジャーＡＳＩＣ（ＱＭ）のブロック
ダイアグラム。

【図４】本発明の好適実施例のリレーエンジンＡＳＩＣ（ＲＥ）のブロックダ
イアグラム。

【図５】本発明の好適実施例のデータフローの概略のダイアグラム。

【図６】本発明の好適実施例で使用されている家庭の一般的なフローダイアグ
ラム。

【図７】図７Ａは、本発明の好適実施例に使用されている標準的なヘッダーの
データ構成を示す。図７Ｂは本発明の好適実施例に使用されている標準的なヘッ
ダーの一部のデータ構成を示す。図７Ｃは、データ構成及び本発明の好適実施例
に使用されている標準的なヘッダーの別の部分の可能なエントリーを示す。図７
Ｄは、データ構成及び本発明の好適実施例に使用されている標準的なヘッダーの
別の部分の可能なエントリーを示す。

【図８】図８Ａは、本発明の好適実施例に使用されている標準的なヘッダーの
別の部分のデータ構成を示す。図８Ｂは、データ構成及び本発明の好適実施例に
使用される標準的なヘッダーの別の部分の可能なエントリーを示す。図８Ｃはデ
ータ構成及び本発明の好適実施例に使用される標準的なヘッダーの別の部分の可
能なエントリーを示す。

【図９】本発明の好適実施例に使用されているハイスピードバスのブロックダ
イアグラム。

【図１０】図９のバスラインの特徴を示す。

【図１１】図９に示されているバスで使用されているトランスミットサーキット
の概略。

【図１２】図１１のトランスミットサーキットのタイミングダイアグラム。図１
２Ａは、図１１のトランスミットサーキットの複合タイミング。

【図１３】図９に示されているバスの伝達に使用されるクロックディレイの概略
。図１３Ａは、図１３に示されているサーキットのシグナルのタイミングダイア
グラム。

【図１４】図１３に示されているサーキットのサーキットの詳細。

【図１５】可能な価値及び図９に示されているバスに使用されているコントロー
ルビットの意味を示す。

【図１６】図１５に示されているコントロールビットの順序を示す。

【図１７】図１に示されているインターフェースチップ間で使用されているトク
ーンリングアービトレーションに示しているブロックダイアグラム。

【図１８】本発明の好適実施例に使用されているセルトランスミッションの順序
を示す。

【図１９】本発明の好適実施例に使用されているポインターレジスター構成を示
す。

【図２０】図２０Ａは、本発明の好適実施例に使用されているハッシュテーブル
エントリのデータ構成を示す。図２０Ｂは、本発明の好適実施例に使用されてい
る別ののハッシュテーブルエントリのデータ構成を示す。

【図２１】図９に示されているバスで使用されているコントロールシグナルのた
めのタイミングダイアグラム。

【図２２】可能な価値及び図９で示されているバスに使用されているコントロー
ルビットの意味を示す。

【図２３】図９に示されているバスに見られうるコントロールビットの順序の例
を示す。

【図２４】図９に示されているバスに伝達される可能性のあるセルのためのセル
トランスミッションを図式的に示す。

【図２５】可能な価値及び図９で示されているバスに使用されているコードの意
味を示す。

【図２６】異なった時間に好適実施例で使用されている標準的なヘッダーの分野
のデータ構成を示す。

【図２７】図２６に示されているサブフィールドの一つのデータ構成の詳細を示
す。

【図２８】本発明の好適実施例に使用されている一時的な「バースト」ヘッダー
のデータ構成を示す。

【図２９】好適実施例に使用されているデータパケットに描かれている一連の詳
細を示す。図２９Ｂは、不完全なパケットを描写するために好適実施例に使用されている一
連の詳細を示す。

【図３０】バーチャルキューを作るために好適実施例に使用されている一連の詳
細を示し、図３０Ｂは、パケットを形成するデータセルを探知するために好適実
施例に使用されているコンテクストテーブルを受信したり伝達したりするバッフ
ァーディスクリプターの関連を示す。

【図３１】本発明の好適実施例に使用されているクレジットマネージドトランス
ミッションシステムの説明。

【図３２】クレジットが図３１で説明したシステムに発行されるべきかどうか決
定するために本発明の好適実施例に使用されているリングポインターシステムの
説明。

【図３３】図３１で説明されているシステムのより詳細な説明。

【図３４】本発明の好適実施例に使用されている階層的なキューシステムの説明
。

【図３５】本発明の好適実施例に使用されているトランスミットコンテクストテ
ーブルエントリーのデータ構成を示す。

【図３５】図３５Ａは、図３５に示されているデータ構成の分野のデータ構成を
示し、図３５Ｂは、図３５に示されているデータ構成のＱＳＶＣポリシー分野
で記号化されている可能なサービスポリシーを示す。

【図３６】好適実施例に使用されているキューテーブルのデータ構成を示す。

【図３７】好適実施例のトランスミッションフェーズにおける可能なリンクとキ
ューの説明。

【図３８】本発明の好適実施例に使用されている予備のスケジューラーの操作を
示す。

【図３９】図３９Ａは、好適実施例のメモリーの完全なパケットを説明している
リンクされたディスクリプターセットを表し、図３９Ｂは、図３９Ａに示されて
いるリンクされたディスクリプターによって表されたバッファーをフリーにする
ために図３９Ａに示されたディスクリプターセットの分離を説明している。

【図４０】本発明の好適実施例に使用されているＤＲＡＭコントロールシステム
のブロックダイアグラム。

【図４１】現在の発明の原則による前エンジンコードとデータＤＲＡＭ４５（図
１）に配置されているフローインフォメーションデータ構成１１００，１１０２
のダイアグラム。

【図４２】現在の発明の原則による応用スイッチのコントロールコネクション過
程のフローチャート。

【図４３】現在の発明の原則によるビデオやヴォイスコネクションデータフロー
のフローチャート。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者ナラヤスワミー，クリシュナアメリカ合衆国マサチューセッツ州 01581−1770 ウェストボロコンピュータドライブ 2400，トップレイヤーネットワークス，インク．内Ｆターム(参考） 5K030 GA11 HA08 HD03 KA03 LB13 LC01 5K033 AA01 CB06 DA15 DB13 DB18

Claims

【特許請求の範囲】

【請求項１】レシーブフィジカルパスとトランスミットフィジカルパスとの間
でデータパケットのフローをフレキシブルに接続するための方法であって、 (a)該レシーブフィジカルパスにデータパケットを受領するステップと、 (b)該データパケットが以前に受領したデータパケットでイニシエートされ
たフローの一部であるか否かを決定し、(i)一部でなければ、新フローの一部と
して受領されたデータバイトの数のカウントに提供されたデータバイトの数を追
加し、(ii)一部であれば、前記以前にイニシエートされたフローの一部として以
前にカウントされたデータバイトの数のカウントに提供されたデータバイトの数
を追加するステップと、 (c)前記追加ステップの結果として受領されたデータバイトの数のカウント
が所定のしきい値を超えるか否かを決定し、(i)超えなければ、トランスミッシ
ョンのために第１品質のサービスセクエンスを適用し、(ii)超えれば、トランス
ミッションのために第２品質のサービスセクエンスを適用するステップと、 (d)前記適用された品質のサービスセクエンスに従って前記フローの一部で
あるデータパケットをトランスミットするステップと、を含んでいることを特徴とする方法。
【請求項２】受領したデータバイトのカウントが所定のしきい値を超えるか否
かを決定するステップ(c)は、該しきい値が所定のフローに関して最初に超えら
れた後に該フローのコンスタントな肯定であることを特徴とする請求項１記載の
方法。
【請求項３】ステップ(b)は、(b1)フローを識別するデータパケットのフィー
ルドの内容を以前に受領したデータパケットの対応するフィールドの内容と比較
するステップをさらに含んでいることを特徴とする請求項１記載の方法。
【請求項４】ステップ(b1)はフィールドのハッシュ処理の結果を比較すること
で行われることを特徴とする請求項３記載の方法。
【請求項５】ステップ(b1)で比較されたフィールドはデータパケットの層２ま
たはさらに高い層のヘッダの対応部分であることを特徴とする請求項３記載の方
法。
【請求項６】データパケットの受領によって受領されたデータを基準セルに分
割させるステップをさらに含んでいることを特徴とする請求項１記載の方法。
【請求項７】ステップ(d)は受領されたデータパケットから引き出されたそれ
ぞれの基準セルのデータを順番にトランスミットすることで実行されることを特
徴とする請求項６記載の方法。
【請求項８】受領されたパケットのそれぞれ順番のセルはメモリロケーション
に保存され、論理的にリンクされ、トランスミッション用にキュー処理されるこ
とを特徴とする請求項７記載の方法。
【請求項９】論理リンク処理とキュー処理はセルが保存されているそれぞれの
メモリロケーションにポインターをリンクさせることで実行されることを特徴と
する請求項８記載の方法。
【請求項１０】サービスセクエンスはポインターに対するポインターのそれぞれ
のテーブルのエントリーのそれぞれのセクエンスによって決定されることを特徴
とする請求項９記載の方法。
【請求項１１】カウントされたデータバイトの所定のしきい値はトランスファー
されているバルクドキュメントを表示し、第２品質のサービスセクエンスは、全
アクティブフローに関係するデータパケットに対するポインターの割合でフロー
に関係するデータパケットに対するポインターのさらに小さい割合を含んでいる
ことを特徴とする請求項１０記載の方法。
【請求項１２】カウントされたデータバイトの所定のしきい値はトランスファー
されているバルクドキュメントを表示し、第２品質のサービスセクエンスは、第
１品質のサービスセクエンスの場合よりも、所定期間のフローに関係する少ない
データパケットのトランスミッションとなることを特徴とする請求項２記載の方
法。
【請求項１３】レシーブフィジカルパスとトランスミットフィジカルパスとの間
でデータパケットのフローを、バルクデータトランスファーと関係すると決定さ
れたフローのためのサービスの下方アジャストメントとフレキシブルに接続する
方法であって、 (a)前記フィジカルパスにデータパケットを受領するステップと、 (b)該受領されたデータパケットを基準セルに分割するステップと、 (c)該セルのそれぞれのセクエンスに対して、 (i)該セルを保存し、それを同じデータパケットから分割された以前のセ
ルと論理的にリンクさせ、 (ii)データパケットの一部のセルの前記セクエンスが以前に受領されたデ
ータパケットでイニシエートされたフローの一部であるか否かを、該フローを特
定する前記データパケットのそれぞれのデータフィールドから引き出されたそれ
ぞれの情報を比較することで決定し、(A)一部でなければ、新フローの一部とし
て受領されたデータバイトの数のカウントに提供されたデータバイトの数を追加
し、(B)一部であれば、前記以前にイニシエートされたフローの一部として以前
にカウントされたデータバイトの数を追加し、 (iii)前記追加から得られた受領されたデータバイトの数のカウントが特
定のアプリケーションのためのバルクデデータトランスファーと関係する所定の
しきい値を超えるか否かを決定し、(A)超えていなければ、前記フローのデータ
パケットのトランスミッションのために第１品質のサービスセクエンスを適用し
、(B)超えていれば、さらに少ない頻度のトランスミッションを提供する第２品
質のサービスキューを適用するステップと、 (d)前記セルのリンクと前記適用された品質のサービスキューに従って前記
フローの一部であるデータパケットをトランスミットするステップと、を含んでいることを特徴とする方法。
【請求項１４】レシーブフィジカルパスとトランスミットフィジカルパスとの間
でデータパケットをフレキシブルに接続する装置であって、 (a)該レシーブフィジカルパスにデータパケットを受領するための受領手段
と、 (b)該データパケットが以前に受領したデータパケットでイニシエートされ
たフローの一部であるか否かを決定するフロー決定手段であって、該フロー決定
手段はデータバイトカウントを創出するためのデータバイトカウント手段を有し
ており、さらに、 (i)前記データパケットが前記以前にイニシエートされたフローの一部で
なければ新フローの一部として受領されたデータバイトの数のカウントに提供さ
れたデータバイトの数を追加する第１追加手段と、 (ii)一部であれば、前記以前にイニシエートされたフローの一部として以
前にカウントされたデータバイトの数のカウントに提供されたデータバイトの数
を追加する第２追加手段と、を含んでおり、 (c)前記追加の結果として受領されたデータバイトの数のカウントが所定の
しきい値を超えるか否かを決定するしきい値手段であって、該しきい値手段は、 (i)超えなければ、トランスミッションのために第１品質のサービスセク
エンスを適用する手段と、 (ii)超えれば、トランスミッションのために第２品質のサービスセクエン
スを適用する手段と、を含んでおり、 (d)前記適用された品質のサービスセクエンスに従って前記フローの一部で
あるデータパケットをトランスミットする手段と、を含んでいることを特徴とする装置。
【請求項１５】受領したデータバイトのカウントが所定のしきい値を超えるか否
かを決定する手段は、該しきい値が所定のフローに関して最初に超えられた後に
該フローのコンスタントな肯定であることを特徴とする請求項１４記載の装置。
【請求項１６】フロー決定手段は、フローを識別するデータパケットのフィール
ドの内容を以前に受領したデータパケットの対応するフィールドの内容と比較す
る手段をさらに含んでいることを特徴とする請求項１４記載の装置。
【請求項１７】比較手段はフィールドのハッシュ処理の結果を比較する手段をさ
らに含んでいることを特徴とする請求項１６記載の装置。
【請求項１８】比較手段で比較されたフィールドはデータパケットの層２または
さらに高い層のヘッダの対応部分であることを特徴とする請求項１６記載の装置
。
【請求項１９】データパケットの受領によって受領されたデータを基準セルに分
割させる手段をさらに含んでいることを特徴とする請求項１４記載の装置。
【請求項２０】データパケットをトランスミットする手段は受領されたデータパ
ケットから引き出されたそれぞれの基準セルのデータを順番にトランスミットす
る手段をさらに含んでいることを特徴とする請求項１９記載の装置。
【請求項２１】受領されたパケットのそれぞれ順番のセルをメモリロケーション
に保存し、論理的にリンクし、トランスミッション用にキュー処理すり手段をさ
らに含んでいることを特徴とする請求項２０記載の装置。
【請求項２２】論理リンク処理とキュー処理はセルが保存されているそれぞれの
メモリロケーションにポインターをリンクさせるキューポインターをさらに含ん
でいることを特徴とする請求項２１記載の装置。
【請求項２３】サービスセクエンスはポインターに対するポインターのそれぞれ
のテーブルのエントリーのそれぞれのセクエンスによって決定されることを特徴
とする請求項２２記載の装置。
【請求項２４】カウントされたデータバイトの所定のしきい値はトランスファー
されているバルクドキュメントを表示し、第２品質のサービスセクエンスは、全
アクティブフローに関係するデータパケットに対するポインターの割合でフロー
に関係するデータパケットに対するポインターのさらに小さい割合を含んでいる
ことを特徴とする請求項２３記載の装置。
【請求項２５】カウントされたデータバイトの所定のしきい値はトランスファー
されているバルクドキュメントを表示し、第２品質のサービスセクエンスは、第
１品質のサービスセクエンスの場合よりも、所定期間のフローに関係する少ない
データパケットのトランスミッションとなることを特徴とする請求項１５記載の
装置。
【請求項２６】レシーブフィジカルパスとトランスミットフィジカルパスとの間
でデータパケットのフローを、バルクデータトランスファーと関係すると決定さ
れたフローのためのサービスの下方アジャストメントとフレキシブルに接続する
装置であって、 (a)前記フィジカルパスにデータパケットを受領する手段と、 (b)該受領されたデータパケットを基準セルに分割する手段と、 (c)前記セルの各セクエンスを保存し、以前のセルが存在すれば各セルを同
じデータから分割された以前のセルに論理的にリンクさせる手段と、 (d)各セルの各セクエンスに関して、該セルが以前に受領されたデータパケ
ットによってイニシエートされたフローのデータパケットの一部であるか否かを
、該フローを特定する前記データパケットのそれぞれのデータフィールドから引
き出されたそれぞれの情報を比較する手段と、 (e)新フローの一部として受領されたデータバイトの数のカウントに提供さ
れたデータバイトの数を追加する第１データバイトカウント手段と、 (f)前記以前にイニシエートされたフローの一部として以前にカウントされ
たデータバイトの数のカウントに提供されたデータバイトの数を追加する第２デ
ータバイトカウント手段と、 (g)前記追加で得られたデータバイトの数のカウントがアプリケーションの
ためのバルクデータトランスファーと関係する所定のしきい値を超えるか否かを
決定するしきい値手段と、 (h)前記データパケットが前記以前にイニシエートされたフローの一部でな
ければ新フローの一部として受領されたデータバイトの数のカウントに提供され
たデータバイトの数を追加する第１追加手段と、 (i)前記データパケットが以前にイニシエートされたフローの一部であれば
前記以前にイニシエートされたフローの一部として以前にカウントされたデータ
バイトの数のカウントに提供されたデータバイトの数を追加する第２追加手段と
、 (j)前記セルのリンクと前記適用されたサービスセクエンスに従って前期フ
ローの一部であるデータパケットをトランスミットするトランスミット手段と、
を含んでいることを特徴とする装置。
【請求項２７】レシーブフィジカルパスとトランスミットフィジカルパスとの間
でデータパケットのフローをフレキシブルに接続するネットワークスイッチであ
って、レシーブフィジカルパスとトランスミットフィジカルパスとの間で接続され
たネットワークインターフェースであって、前記レシーブフィジカルパスでデー
タパケットを受領するものであり、該ネットワークインターフェースは前記デー
タパケットに提供されたデータバイトをカウントするネットワークインターフェ
ースと、該ネットワークインターフェースと接続され、前記データパケットが新フロ
ーまたは以前にイニシエートされたフローの一部であるか否かを決定するフォー
ワードエンジンと、該フォーワードエンジンに接続され、前記ネットワークインターフェースと
該フォーワードエンジンに従って各特定されたフローのデータバイトカウントを
保存するフォーワードエンジンであって、該エンジンは前記データバイトのカウ
ントバッファに保存された各フローのデータバイトカウントを所定のしきい値と
比較し、特定のフローがバルクトランスファーであるか否かを決定し、データカ
ウントバイト比較に従って特定フローに対するサーブスを決定するエンジンと、該エンジンに接続され、該エンジンの決定に対応するデータパケットのトラ
ンシミッションをスケジュールするキューマネージャと、を含んでいることを特徴とするネットワークスイッチ。
【請求項２８】レシーブフィジカルパスとトランスミットフィジカルパスとの間
でデータパケットのフローをフレキシブルに接続する装置であって、データパケットを受領するインターフェースと、該データパケットを保存し、しきい値を保存するメモリと、前記インターフェースで受領したフローのデータバイトカウントをキープし
、パケットが該インターフェースで受領されるとデータバイトを漸増させるする
カウンターと、前記メモリと前記カウンターとインターアクトするマイクロプロセッサーで
あって、該データパケットが特定フローの一部であるか否かを決定し、該データ
カウントが前記しきい値を越えて前記フローがバルクフローであることを示すか
否かを決定し、該フロー決定に従って前記データパケットをトランスミットする
サービスを特定し、該データパケットのトランスミットは前記サービスに従って
いることを特徴とするマイクロプロセッサーと、を含んでいることを特徴とする装置。
【請求項２９】インフォメーションパケットスイッチであって、 A)少なくとも１つのパケットレシーバと、 B)該レシーバに接続されたパーサであって、該レシーバから受領された情報
を前記パケットのアプリケーションを特定するヘッダ情報を含むに充分な要領の
均一なセルに分割するパーサと、 C)該パーサに接続されており、前記セルを収容する位置に組織化されている
ファーストメモリであって、前記パーサはポインターをセットし、前記受領情報
パケットに関レさせて維持するファーストメモリと、 D)該パーサに接続されたコンパレータであって、以前のタイムウィンドー中
に受領されたパケットから得られた情報を含んだメモリに接続されており、該コ
ンパレータが、以前の情報とマッチしないなら該メモリーに新しく受領されたパ
ケットの情報を追加し、前記新しく受領されたパケットのセルに対するポインタ
ーを以前に受領されたパケットで特定するコンパレータと、 E)前記ファーストメモリに接続された少なくとも１つのトランスミッターと
、 F)該トランスミッターに前記ファーストメモリからの情報をトランスミット
させるようにプログラムされた論理プロセッサーであって、特定タイプのアプリ
ケーションストリームに関連するサービスポリシーに従っていり論理プロセッサ
ーと、を含んでおり、 G)アプリケーションがバルクトランスファータイプのアプリケーションスト
リームであるか否かを決定するために該論理プロセッサーはA-B-C-Eのパスに沿
った情報量カウンターにさらに対応することを特徴とする情報パケットスイッチ
。