JP2012514388A - マネージド・ネットワークでのレイヤ２のパケット集約及び断片化 - Google Patents

Abstract

第１のプロトコルに従って第１のネットワーク内部のノードからパケットを受信する方法及び装置である。各受信パケットと関連付けられた記述子は、受信パケットを格納する直接メモリアクセス（ＤＭＡ）コントローラによって読み込まれる。制御可能パラメータの値は第２のプロトコルに従って動作する第２のネットワークを介して受信パケットの内容を効率的に通信するように選択される。受信パケットの中の情報は、その後、新たに形成されたパケットに編成され、各パケットのサイズは第２のプロトコルにおけるネットワークを介した通信のためパケットを効率的にする。新たに形成されたパケットは、送信ラインバッファに格納され、プロトコル記述子と関連付けられる。プロトコル記述子は、第２のプロトコルを効率的に利用するため、送信コントローラが送信ラインバッファからのパケットを選択し集約することを可能にするように情報を送信コントローラへ供給する。

Description

相互関連出願
本願は、２００８年１２月２４日付けで出願され、名称が「Ｐａｃｋｅｔ ａｇｇｒｅｇａｔｉｏｎ ａｎｄ ｆｒａｇｍｅｎｔａｔｉｏｎ ａｔ ｌａｙｅｒ−２ ｏｖｅｒ ａ ｍａｎａｇｅｄ ｎｅｔｗｏｒｋ」であり、参照によって本明細書中に組み込まれる米国特許本出願第１２／３４３９４１号に基づく優先権を主張する。

発明の分野
開示された方法及び装置は、ネットワーク通信に関し、より詳細には、一部の実施形態は、ホーム・エンターテインメント・ネットワークにおけるパケットの効率的な通信に関する。

ホーム・エンターテインメント・コンポーネントがホーム・エンターテインメント・ネットワークを介して互いに通信することはより望ましくなっている。このような通信は、映画、音楽、インターネットコンテンツなどのようなエンターテインメント・コンテンツと、電話サービスとが、１台の特定のホーム・エンターテインメント機器に対して隔離されるのではなく、機器のネットワークによって取り扱われることを可能にする。

家庭内にホーム・エンターテインメント・ネットワークを確立するため採用されている１つの特定の規格は、ＭｏＣＡ（同軸ケーブル・マルチメディア協会）によって確立された業界標準である。このＭｏＣＡ規格は、コンポーネント（「ノード」と呼ばれることもある）がノードを接続する媒体として同軸ケーブルを使用する高速ネットワークを介して互いに通信し、そして、コンテンツを共有することを可能にする。このネットワークは、「ネットワーク・コントローラ」（ＮＣ）の機能を実行するため選択されている１つのノードを用いて確立される。ＮＣ機能は、ネットワークのすべてのノードをリンクする単一同軸ケーブルを介した通信の編成及び調停を含む。媒体（即ち、同軸ケーブル）は共有されるので、ＭｏＣＡ規格は、ＮＣがいつでも特定の時点で媒体を制御するノードを決定するための調停スキームを確立する。

本スキームによれば、ＮＣは、媒体を介するすべての通信をスケジューリングする。このスケジュールは、いわゆる媒体アクセス・プラン（ＭＡＰ）の中で、ネットワークのノードの１つずつに通信される。ＭＡＰは、定期的なスケジュールベースでＮＣによって送信される。各ＭＡＰは、ＭＡＰサイクルの先頭に置かれる。ＭＡＰは、どのノードが後に続くＭＡＰサイクルの中で時間間隔毎に送信するかを示す。

図１は、Ｍａｐ ２０１、２０２とＭａｐサイクル２０３、２０５との間のタイミング関係を図示するタイミングチャートである。Ｍａｐサイクル２０５は、以前に送信されたＭＡＰ ２０１の制御下でのチャンネル上の通信アクティビティとして定義される。従って、各ＭＡＰ ２０１は、次のＭＡＰサイクル２０５のためのすべての通信アクティビティをスケジューリングする（このような「次のＭＡＰサイクル」２０５が１つだけ図１に示される）。なお、次のＭＡＰ ２０２は、以前のＭＡＰ ２０１のスケジューリング制御下で次のＭＡＰサイクル２０５の間に送信される。従って、ＭＡＰ ２０１は、次のＭＡＰサイクル２０５で送信されるべきパケット毎に以下の情報、即ち、ｉ）パケット開始時刻、ｉｉ）パケット長さ、ｉｉｉ）発信元ノード、及び、ｉｖ）単数または複数の宛先ノードを決定する。

ＭＡＰ ２０１、２０２がスケジューリングに対する責任を担う１つの特定の型のパケットは、予約要求（ＲＲ）２０７、２０９、２１１である。６個のこのようなＲＲは、最初のＲＲ ２０７で始まり、最後のＲＲ ２０９で終わる図１の最初のＭＡＰサイクル２０３に示されている。１個のＲＲ ２１１が２番目のＭＡＰサイクル２０５に示される。クライアントノードが送信を希望するパケットを有することを示すため、そして、クライアントノードがこれらのパケットを送信可能であるときに、後続のＭＡＰサイクル中の時間をＮＣがスケジューリングすることを要求するために、ＲＲ ２０７、２０９、２１１がクライアントノードによって送信される。従って、クライアントノードが送信すべき情報を有するとき、クライアントノードは、クライアントノードがＲＲ ２０７、２０９、２１１を送信することができる時間を割り当てるために、最初にＮＣを待ち受けることが必要である。クライアントノードがＲＲ ２０７、２０９、２１１を送信可能である時間をＮＣが割り当てると、クライアントノードは、割り当てられた時間（例えば、ＲＲ ２１１のためＭＡＰ ２０１によって指示されたパケット開始時刻及びパケット長さの期間）にＲＲ ２０７、２０９、２１１をＮＣに通信する。

ＲＲ ２０７、２０９は、クライアントノードが送信することを希望するデータパケットを有していることをクライアントノードがＮＣに通信することを可能にする。さらに、ＲＲ ２０７、２０９は、これらのデータパケットのための関連付けられた単数または複数の宛先ノード、パケット長さ、パケット優先度などを示す。高優先度をもつパケットは、低優先度をもつパケットより先にスケジューリングされる。ＮＣは、クライアントノードが送信することを希望するこれらのデータパケットを送信できる時間をスケジューリングするためにこの情報を使用する。ＮＣは、その後、次のＭＡＰサイクル２０５のためのＭＡＰ ２０１を生成し送信することによりそのスケジュールを通信する。

クライアントノードからのＲＲが許可されると、クライアントノードは、ＮＣによって割り当てられた時間に通信されるべきデータパケットを送信する。データパケットは、データパケットの最大長さと、データパケットのヘッダの内容と、前方誤り訂正符号のような何か他のオーバーヘッド情報とを指示する特定のフォーマットを有している。データパケットが長くなるほど、媒体はより効率的に使用される。即ち、データパケットにロードされるデータが多いほど、データ対オーバーヘッドの比率が大きくなる。効率が測定される期間がパケット長さに関して比較的長いと仮定すると、データ対オーバーヘッドの比率が高いほど、より多くのデータを所与の期間に媒体を介して通信できる（即ち、媒体効率がより高い）。

しかし、特定のクライアントノードが送信すべきデータは、異なる発信元アプリケーションから到来することがあり、異なるパケットサイズを有することがあり、異なる宛先を有することがあり、そして、異なる優先度が割り当てられていることがある。従って、異なる発信元アプリケーションから到来した異なるパケットをソートすることは、厄介であり、一般にネットワークの非効率性に拍車をかける可能性がある。その結果、異なる発信元アプリケーションからの情報を、定義済みのパケットオーバーヘッド及び最大パケットサイズを有するＭｏＣＡネットワークのようなネットワークを介して送信されるべきパケットに割り当てるために効率的かつ比較的簡単な方法の必要性がある。

本文書は、第１のネットワーク内のノードから、第１のプロトコルに従って編成されたパケットを受信する方法及び装置を開示する。各受信パケットと関連付けられた記述子は、受信パケットを格納する直接メモリアクセス（ＤＭＡ）コントローラによって読み込まれた受信パケットに関する情報を含む。

制御可能なパラメータの値は選択される。制御可能なパラメータは、第２のプロトコルに従って動作する第２のネットワークを介して効率的に通信されるパケットのサイズを決定する。パラメータは、自動プロセスを使用するアプリケーションによって、又は、手動で選択することができる。いずれの場合でも、パラメータは、好ましくは、受信パケットのサイズ、及び、受信パケットの中で通信される情報の種類に基づいて選択される。受信パケットの中の情報は、その後、新たに形成されたパケットに編成され、これらのパケットのサイズは、第２のプロトコル内でのネットワークを介した通信のためこれらのパケットを効率的にする。制御可能なパラメータの値に依存して、新たに形成されたパケットのサイズは、受信パケットのサイズに一致すること、又は、受信パケットより大きいことがある。

新たに形成されたパケットは送信ラインバッファに格納され、初期的に同じサービス・パケットの中に存在していた新たに形成されたパケットのすべてがプロトコル記述子と関連付けられる。プロトコル記述子は、第２のプロトコルを効率的に使用するため、送信コントローラが送信ラインバッファからのパケットを選択し、集約することを可能にするように情報を送信コントローラに提供する。

１つ以上の様々な実施形態による開示された方法及び装置は、添付図面を参照して説明される。

ＭａｐとＭａｐサイクルとの間のタイミング関係を図示するタイミングチャートである。 開示された方法及び装置を含むシステムのブロック図である。 開示された方法及び装置で使用される共有メモリの８個の領域の説明図である。 ＧＥＰＨＹ受信バッファ・キューとＧＥＰＨＹ受信記述子キューとの間の関係の説明図である。 開示された方法及び装置の一実施形態による受信記述子のフォーマット及び内容の説明図である。

図面は、例示のためだけに提供され、開示された方法及び装置の一部の実施形態の実例を描写するに過ぎない。図面は、請求項に係る発明の広がり、範囲、又は、適用を限定するために考慮されるべきでない。なお、例示の明瞭さ及び容易さのため、これらの図面は必ずしも正しい縮尺ではない。

詳細な説明
ネットワーク内の通信を制御する方法及び装置が本明細書中に開示されている。以下の説明は、主として、ＭｏＣＡ規格に基づくホーム・エンターテインメント・ネットワークに言及する。しかし、開示された方法及び装置が媒体を効率的に使用することが望ましいいずれの通信ネットワークにおいても巧く使用されることは当業者によって十分に理解されるであろう。

図２は、開示された方法及び装置を含むシステムのブロック図である。ＭｏＣＡネットワークの第１のノード１０２及び第２のノード１０４は、同軸ケーブル１０６（「媒体」）によって接続されている。各ノード１０２、１０４は、本質的に同一である。従って、１つのノード１０２だけが以下で詳細に説明される。開示された方法及び装置の一実施形態によれば、ノード１０２は、メモリからの命令を実行するギガバイト・イーサネット・物理レイヤ・コントローラ（ＧＥＰＨＹ）１０８のような物理レイヤ・コントローラを含む。一実施形態では、ＧＥＰＨＹは、１ギガバイト／秒（Ｇｂ／ｓ）、１００メガバイト／秒（Ｍｂ／ｓ）、１０Ｍｂ／ｓ、及び、他の速度のサポートを含む。ノード１０２は、外部ホストインタフェース１１０も含む。ノード１０２は、ＭｏＣＡ中央処理ユニット命令／データメモリ１１２（ＭｏＣＡ ＣＰＵ Ｉ／Ｄメモリ）のようなネットワーク中央処理ユニット命令／データメモリと、ＭｏＣＡ ＣＰＵ１１４のようなネットワークＣＰＵと、ＭｏＣＡポート１１６のようなネットワークポートと、共有メモリ１１８とをさらに含む。これらのコンポーネントのうちの１つずつは、システムバス１２０によって共に結合されている。

図２に示されるように、共有メモリは、４つのバッファ、即ち、（１）ＧＥＰＨＹ受信バッファ１３４、（２）ＧＥＰＨＹ送信バッファ１３５、（３）送信ラインバッファ１５０、及び、（４）受信ラインバッファ１５１に分割される。各バッファ１３４、１３５、１５０、１５１は、２つの部分、即ち、（１）記述子キュー、及び、（２）データ・バッファ・キューにさらに分割される。図３は、共有メモリ１１８の８個すべての領域（即ち、４つのバッファの１つずつにおける記述子及びキューの１つずつ）の説明図である。なお、同じバッファと関連付けられた記述子キュー及びデータ・バッファ・キューは、共有メモリ１１８において連続するようには示されてはいない。実際には、８つの領域のうちの１つずつは、図３では、ブロックとして示されているが、開示された方法及び装置の一実施形態では、各記述子キュー及びデータ・バッファ・キューのエントリは、連続して記憶されない。それどころか、エントリは、共有メモリ１１８の至る所に散乱し、互いにリンクされている。共有メモリ１１８の８つの領域は、
（１）ＧＥＰＨＹ受信記述子キュー３０１と、
（２）ＧＥＰＨＹ送信記述子キュー３０３と、
（３）送信ラインバッファ記述子３０５と、
（４）受信ラインバッファ記述子３０７と、
（５）ＧＥＰＨＹ受信バッファ・キュー３０９と、
（６）ＧＥＰＨＹ送信バッファ・キュー３１１と、
（７）受信ラインバッファ・エントリ・キュー３１３と、
（８）送信ラインバッファ・エントリ・キュー３１５と、
を含む。

共有メモリが開示された方法及び装置の目的を達成するために数多くの異なる方式で編成できることは当業者によって理解されるであろう。開示された方法及び装置の一実施形態によれば、共有メモリの中の各データ・バッファ・キュー及び記述子キュー内に格納された情報は、共有メモリの中のどの場所にでも置くことができ、ポインタがこの情報をアドレス指定するため使用することができる。しかし、開示された方法及び装置の記述の理解の伝達を支援するため１つの特定の構成が本明細書中に提示されている。

ノード１０２の動作の概要は、ノード１０２の各コンポーネントの詳細な機能のさらなる説明のための基礎を提供する。前述されたように、ノード１０２は、媒体１０６を介して別のノード１０４に結合されている。その上、ノード１０２は、ＧＭＩＩ／ＭＩＩインターフェイス１２２のような外部ネットワークインターフェイスを介して、イーサネット・ネットワークのような外部ネットワークに結合されている。サービス・パケットは、外部ネットワークプロセッサ１２４からノード１０２内のＧＥＰＨＹコントローラ１０８に通信される。外部ネットワークがイーサネット・ネットワークである場合、サービス・パケットはイーサネット・パケットであり、そして、外部ネットワークプロセッサ１２４は、ＧＭＩＩ／ＭＩＩインターフェイス付きのネットワークプロセッサである。サービス・パケットは、マネージメントインターフェイス１２８を介して通信される制御情報と共に、データパス１２６を介して通信される。

サービス・パケットがネットワークプロセッサ１２４を介して発信元アプリケーションから受信されるとき、サービス・パケットは、最初に、共有メモリ１１８内のＧＥＰＨＹ受信バッファ・キュー３０９の中に格納される。サービス・パケットは、その後、送信ラインバッファ・エントリ・キュー（ＴＬＢＥＱ）３１５へ移される。ＴＬＢＥＱは、送信ラインバッファ記述子３０５によって定義される。一実施形態では、ＴＬＢＥＱ ３１５は、共有メモリ１１８の中にもある。サービス・パケットをＴＬＢＥＱ ３１５へ移すことにより、サービス・パケットは、パケット・データ・ユニット（ＰＤＵ）と称される所定のサイズのパケットに分割することができる。一実施形態では、ＰＤＵは、全て同じサイズである。ＰＤＵのサイズは選択的に固定される。本記述の目的で「選択的に固定される」とは、当該アプリケーションに対しノードが関与し、そして、固定され続ける特定のアプリケーションのため、ＰＤＵのサイズが選択できることを意味する。ノードが関与しているアプリケーションに適合するように選択することができる均一のサイズをＰＤＵに与えることは、後述される詳説からより明確になるように、共有メモリの効率を最適化し、ノード１０２と１０４との間のネットワークを介したパケットの送信をより効率的にする。

サービス・パケットがＰＤＵサイズと同じサイズであるとき（又は、より小さいとき）、サービス・パケット全体は、ＴＬＢＥＱ ３１５の１つのエントリ３１９の中に１つのＰＤＵとして格納される。代替的に、サービス・パケットのサイズが１つのＰＤＵより大きいとき、サービス・パケットが多数のＰＤＵに分割され、各ＰＤＵがＴＬＢＥＱ ３１５の中の１つのエントリ３１９に格納される。２つ以上のＰＤＵの中に格納するためサービス・パケットを分割するプロセスは、断片化と呼ばれる。

各サービス・パケットは、１つのプロトコル記述子（ＰＤ）と関連付けられる。従って、サービス・パケットが多数のＰＤＵに分割されている場合、１つのサービス・パケットから分割されたすべてのＰＤＵのための１つのＰＤが存在する。どのようにサービス・パケットが分割され、ＴＬＢＥＱ ３１５に格納されるかに関する詳説は後述される。

ＰＤＵの優先度やＰＤＵが送信されるべき宛先ノードのような共通特性を有する複数のＰＤＵは、その後、送信パケットの中に集約され、ＭｏＣＡネットワークを介して送信される。ノードが関与する各アプリケーションのためＰＤＵのサイズを適切に選択することは、ＰＤＵが効率的に集約されることを可能にする。ＰＤＵを集約することは、ネットワークのノード間で送信される各パケットの中のペイロードのサイズを増大させる。ペイロードを大きくすることは、ノード１０２と１０４との間のネットワークの媒体アクセス制御（ＭＡＣ）レイヤの効率を向上させることを意味する。ヘッダ（ペイロード以外の情報）のサイズは、ＭＡＣパケットのペイロードのサイズと無関係に本質的に固定されるので、ＭＡＣ効率は典型的に向上する。従って、比較的大きい送信パケットサイズを使用することによりＭＡＣレイヤ効率を最大化することが有利である。ＭｏＣＡネットワークが送信ノード１０２と受信ノード１０４との間の通信のため使用される開示された方法及び装置の実施形態では、送信パケットはＭｏＣＡパケットである。ノード１０２、１０４がＭｏＣＡネットワークを介して通信する一実施形態では、集約されたパケットを受信することができる各ノードは、この能力をＭｏＣＡネットワーク・コーディネータへ通信しなければならない。ネットワーク・コーディネータは、各ノードの能力を他の各ノードに通信する。送信ノードは、集約されたパケットをこのような集約されたパケットを受信する能力を保有することを報告したノードに送信するだけである。

開示された方法及び装置の一実施形態では、アプリケーションが固定サービス・パケット・サイズを使用するとき、サービス・パケットのサイズは、ＰＤＵのサイズとして選択される。代替的に、サービス・パケット・サイズは他の値に選択することができる。様々なアプリケーションのため（即ち、様々な長さのサービス・パケットが取り扱われる必要があるとき）、ＰＤＵサイズを再定義できることが有利である。一旦作成されると、ＰＤＵは、その後、ノード１０２と１０４との間のＭｏＣＡネットワークのようなネットワークを介した送信のため最も効率的な長さを有する送信パケットを形成するために、集合体の中にひとまとめにグループ分けされる。データフローの詳細が次に示される。

基本データフロー
図２に示された送信ノード１０２から受信ノード１０４への基本データフローについて以下に説明する。データフローは、送信ノード１０２が外部発信元又はこの送信ノードのアプリケーションレイヤからサービス・パケットを受信する場合に関して説明される。なお、ノード１０２は「送信」ノード１０２と呼ばれているが、ノード１０２は、最初に、外部発信元又はこのノードのアプリケーションレイヤからサービス・パケットを受信しなければならない。次に説明される実施形態では、送信ノード１０２が受信するサービス・パケットは、イーサネット・パケットである。その上、開示された方法及び装置の一実施形態では、送信ノード１０２から受信ノード１０４へ通信するため使用されるネットワークは、ＭｏＣＡネットワークである。しかし、任意の種類のサービス・パケットが送信ノードによって受信されてもよいことが当業者によって理解されるであろう。同様に、どのようなネットワークプロトコルが送信ノード１０２と受信ノード１０４との間の情報の通信のため使用されてもよい。

送信パス
図２に示された外部ネットワークプロセッサ１２４は、ギガバイト・イーサネット媒体アクセス制御レイヤ（ＧＥＭＡＣ）機器１３０を含む。ＧＥＭＡＣ１３０は、サービス・パケット（例えば、イーサネット・パケット）をＧＥＰＨＹコントローラ１０８へ、ＧＭＩＩ／ＭＩＩインターフェイス１２２を介して送信する。受信サービス・パケットは、共有メモリ１１８内部のＧＥＰＨＹ受信バッファ・キュー３０９の中に一時的に格納される。ＧＥＰＨＹ受信バッファ・キュー３０９は、ＧＥＰＨＹ受信記述子キュー３０１によって定義され、制御される。

サービス・パケットは、直接メモリアクセス（ＤＭＡ）コントローラ１３２によってＧＥＰＨＹ受信バッファ・キュー３０９の中に入れられる。一実施形態では、ＧＥＰＨＹコントローラ１０８は、データ・インターフェイス制御（ＤＩＣ）転送コントローラ（ＴＣ）１４０を含む。任意のサービス・パケットを受信する前に、ＤＩＣ ＴＣ １４０は、少なくとも１つの受信記述子１３６（図４を参照のこと）をＧＥＰＨＹ受信記述子キュー３０１にロードすることにより、ＧＥＰＨＹ受信記述子キュー３０１を初期化する。直接メモリアクセス（ＤＭＡ）コントローラ１３２は、ＤＩＣ ＴＣ １４０によってロードされた受信記述子を読み込む。ＤＭＡコントローラ１３２は、サービス・パケットをＧＥＰＨＹ受信バッファ・キュー３０９の中に格納するプロセスを制御するため受信記述子１３６の中の情報を使用する。

図２は、ＧＥＰＨＹコントローラ１０８に属するＤＭＡコントローラ１３２及びＤＩＣ ＴＣ １４０を示す。しかし、代替的な実施形態では、ＤＭＡコントローラ１３２、ＤＩＣ ＴＣ １４０、又は、これらの両方は、ＧＥＰＨＹコントローラ１０８から独立していることが当業者によって理解されるであろう。図３に図示されるように、ＧＥＰＨＹ受信記述子キュー３０１及びＧＥＰＨＹ受信バッファ・キュー３０９は、共有メモリ１１８内部の連続する場所に位置しなくてもよい。

図４は、ＧＥＰＨＹ受信バッファ・キュー３０９とＧＥＰＨＹ受信記述子キュー３０１との間の関係の説明図である。各サービス・パケット１３８は、ＧＥＰＨＹ受信バッファ・キュー３０９の中のエントリ１３８に格納される。記述子キュー３０１は、ＤＩＣ ＴＣ １４０によってロードされた受信記述子１３６の組を含む。各受信記述子１３６は、ＧＥＰＨＹ受信バッファ・キュー３０９のエントリ１３８のうち一意のエントリと関連付けられる。

図５は、開示された方法及び装置の一実施形態による受信記述子１３６のフォーマット及び内容を図示する。受信記述子１３６は、ＧＥＰＨＹコントローラ１０８の内部バッファからＧＥＰＨＹ受信バッファ１３４へのパケット転送を制御するために（そして逆もまた同様に）、ＤＩＣ ＴＣ １４０によって定義され設定される。ＤＩＣ ＴＣ １４０は、最初に、第１の状態にセットされたＯＷＮビット５０３を用いて受信記述子を書き込む。各受信記述子１３６は、各ワードが３２ビットを保有する４ワードを備える。１番目のワードの最初の３１ビットは、将来の使用のため予約された「第１の予約」フィールド５０１である。

受信記述子１３６の中の１番目のワードの３２番目のビットは、「ＯＷＮ」ビット５０３である。ＯＷＮビット５０３が第１の状態にある場合、このＯＷＮビットは、受信記述子１３６がＤＭＡコントローラ１３２による使用のため利用可能であることを示す。ＤＭＡコントローラは、その後、新たに受信されたサービス・パケットを転送すべき場所を示すため、受信記述子１３６を使用することができる。ＤＭＡコントローラ１３２が受信記述子１３６を読み込み、ＧＥＰＨＹ受信バッファ・キュー３０９の中の関連付けられたエントリ１３８にサービス・パケットを格納すると、ＤＭＡコントローラ１３２は、受信記述子１３６のＯＷＮビット５０３を第２の状態にセットし、再利用のため受信記述子１３６をＤＩＣ ＴＣ １４０へ戻す。従って、ＯＷＮビット５０３が第２の状態にあるとき、ＯＷＮビット５０３は、ＤＭＡコントローラ１３２が受信記述子１３６を使用し終えたことを示す。ＤＩＣ ＴＣ １４０は、その後、受信記述子１３６を再利用することができる。ＤＩＣ ＴＣ １４０は、ある種の所定の分類基準に従ってパケットイン１３６を分類し、ＧＥＰＨＹ受信バッファ・キュー３０９からＴＬＢＥＱ ３１５の中の仮想キューへサービス・パケット１３６を移す。

開示された方法及び装置の一実施形態では、オーバーフロー条件は、ＯＷＮビット５０３が第１の状態にある受信記述子１３６が存在しないときに発生する。開示された方法及び装置の一実施形態では、ＧＥＰＨＹコントローラ１０８は、高閾値を有する受信バッファ（図示せず）を含む。高閾値は、フロー制御フレーム（例えば、ポーズフレーム）の生成がトリガされる前に、コントローラの受信バッファに格納されることが可能である受信フレームの最大数である。ポーズフレームは、コントローラの受信バッファの中に十分な余裕が存在するまでサービス・パケットがこれ以上送信されないことを確実にするために送信される。同様に、低閾値（ポーズフレームが解除される点）が存在する。一実施形態では、高閾値は、ノード１０２、１０４によって実行されている特定の機能（即ち、オーバーフロー条件が発生しないことがどれだけ重要であるか、及び、オーバーフロー条件発生と、ポーズフレームを不必要に生成させるという結果をもたらす非効率性との間のトレードオフ）に依存してソフトウェアによって設定できる値である。

受信記述子１３６の中の２番目のワードのうちの最初の１１ビットは、バッファサイズ・フィールド５０５を備える（図５を参照のこと）。バッファサイズ・フィールド５０５は、「バッファ・アドレス」・フィールド５１１によって指示されたアドレスでＧＥＰＨＹ受信バッファ・キュー３０９のエントリ１３８（即ち、受信記述子１３６と関連付けられたＧＥＰＨＹ受信バッファ・キュー３０９の中のエントリ）に受信サービス・パケットを格納するため利用できるスペースの大きさを示す。２番目のワードのうちの次の１１ビットは、「第２の予約」フィールド５０７である。受信記述子１３６の２番目のワードのうちの最後の１０ビットは、「第３の予約」フィールド５０９である。

３番目のワード全体は、バッファ・アドレス・フィールド５１１である。バッファ・アドレス・フィールド５１１は、受信記述子１３６と関連付けられたＧＥＰＨＹ受信バッファ・キュー３０９の中のエントリ１３８のアドレスを指示する。バッファ・アドレス・フィールド５１１は、受信記述子１３６をＧＥＰＨＹ受信バッファ・キュー３０９の中の特定のエントリ１３８と関連付けるフィールドである。

最後に、４番目及び最後のワードの全体は、「ネクスト記述子アドレス」・フィールド５１３である。ネクスト記述子アドレス・フィールド５１３は、次の受信記述子１３６が開始するアドレスを指示する。ネクスト記述子アドレス・フィールド５１３の使用は、受信記述子１３６が順番通りでなく、かつ、ＧＥＰＨＹ受信記述子キュー３０１内部の離散的な場所に格納されることを可能にする。開示された方法及び装置の一実施形態では、ＧＥＰＨＹ受信バッファ・キュー３０９は循環キューである。従って、最後の受信記述子の中のネクスト記述子アドレス・フィールド５１３は、戻って最初の受信記述子を指示する。一実施形態では、ＧＥＰＨＹ受信バッファ・キュー３０９の中には４個のエントリが存在する。ＧＥＰＨＹ受信バッファ・キュー３０９の中のエントリ１３８とＧＥＰＨＹ受信記述子キュー３０１の中の受信記述子１３６との間には１対１の関係があるので、ＧＥＰＨＹ受信記述子キュー３０１の中に同様に４個の受信記述子１３６が存在する（図４を参照のこと）。

バッファサイズ・フィールド５０５は１１ビットを保有する。よって、サービス・パケットは、長さが最大で２０４８（即ち、２の１１乗）バイトになる。なお、このアプリケーションでは、各サービス・パケットは、ＧＥＰＨＹ受信バッファ・キュー３０９の中に１つのエントリ１３８だけを必要とする。従って、各サービス・パケット１３８と関連付けられた１つの受信記述子１３６だけが存在する。サービス・パケットがＧＥＰＨＹコントローラ１０８によって受信され、ＧＥＰＨＹ受信バッファ・キュー３０９内に格納されたとき、対応する受信記述子１３６の内部のＯＷＮビット５０３は第２の状態にセットされる。

前述の通り、ＤＭＡコントローラ１３２は、受信記述子１３６を通じて制御される。即ち、ＤＭＡコントローラ１３２は、受信記述子１３６からＯＷＮビット５０３及びバッファ・アドレス・フィールド５１１を読み込む。ＤＭＡコントローラ１３２は、ＯＷＮビット５０３及びバッファ・アドレス・フィールド５１１に基づいて、着信サービス・パケットのそれぞれを格納すべき場所を決定する。ＯＷＮビット５０３が第１の状態にある場合、受信記述子１３６は、ＤＭＡコントローラ１３２による使用のため利用可能である。ＯＷＮビット５０３が第２の状態にある場合、受信記述子１３６はＤＭＡコントローラ１３２が利用できない。ＤＭＡコントローラ１３２は、受信記述子１３６が再び利用可能になること（即ち、ＯＷＮビット５０３が第１の状態になること）を待つ必要がある。サービス・パケット１３８は、この受信記述子１３６のバッファ・アドレス・フィールド５１１によって指示された場所に格納される。なお、１つの受信記述子１３６がＤＭＡコントローラによって使用されると、ＤＭＡコントローラは、次のパケットのために次の受信記述子１３６を使用する（ＧＥＰＨＹ受信記述子キューは循環式に機能する）。

ＯＷＮビット５０３を読み込むＤＭＡコントローラ１３２の他に、ＤＩＣ ＴＣ １４０は、ＯＷＮビット５０３が第２の状態にある受信記述子を見つけるため、各受信記述子１３６からＯＷＮビット５０３を読み込む。ＤＩＣ ＴＣ １４０が第２の状態にセットされたＯＷＮビット５０３をもつ受信記述子１３６を見つけたとき、ＤＩＣ ＴＣ １４０は、ＴＬＢＥＱ ３１５の中で、サービス・パケットの１番目のＰＤＵを格納すべき空きエントリを探す。ＰＤＵがサービス・パケットと同じサイズである場合、１番目のＰＤＵはサービス・パケット全体である。従って、サービス・パケット全体がＴＬＢＥＱ ３１５の中の１つのエントリ３１９に格納される。しかし、ＰＤＵがサービス・パケットより小さい場合、ＤＩＣ ＴＣ １４０は、サービス・パケットを断片化する。ＰＤＵと等しいサイズを有するサービス・パケットの第１の部分は、サービス・パケットのうちの第１のＰＤＵを形成する。サービス・パケットのうちの第１のＰＤＵは、ＴＬＢＥＱ ３１５の中の次に利用可能なエントリ３１９に格納される。

ＤＩＣ ＴＣ １４０は、共有メモリ１１８の中の送信ラインバッファ記述子３０５に格納された「状態情報」フィールドを読み込むことにより、ＴＬＢＥＱ ３１５の中で、第１のＰＤＵが格納されるエントリ３１９を決定する。１つのこのような状態情報フィールドは、ＴＬＢＥＱ ３１５の中のエントリ３１９毎に（即ち、格納されたＰＤＵ毎に）送信ラインバッファ記述子３０５の中に維持される。送信ラインバッファ記述子３０５は、以下のフォーマットを保有する。

ＮがＴＬＢＥＱ ３１５の中のエントリ３１９の個数である場合、送信ラインバッファ記述子３０５は、０ｘ２４＋４（Ｎ−１）個のワードを含む。送信ラインバッファ記述子３０５の中の各ワードは、８ビット幅である。送信ラインバッファ記述子３０５の中の状態情報フィールドは、オフセット０ｘ２４で始まる４個のこのようなワードに格納される。従って、ＮがＴＬＢＥＱ ３１５の中のエントリ３１９の個数である場合、ＴＬＢＥＱ ３１５の中の各エントリ３１９の状態情報フィールドは、オフセットアドレス０ｘ２４＋（Ｎ−１）＊４に格納された４個のワードによって維持される。ＴＬＢＥＱ ３１５内の４番目のエントリに対し、状態情報フィールドの（送信ラインバッファ記述子３０５内部のベースアドレスからの）オフセットは、０ｘ２４＋１２である。状態情報フィールドの中の１番目のワードの１番目のビットは、関連付けられたエントリ３１９の状態情報フィールド（即ち、エントリが書き込みプロセスによって所有されるか、又は、読み込みプロセスによって所有されるか）を示す。状態情報フィールドの１番目のワードの他の７ビットは、将来の使用のため予約済みである。

状態情報フィールドの２番目及び３番目のワード（即ち、ビット８〜２３）は、ネクストＰＤＵポインタ３２７である（図３を参照のこと）。ネクストＰＤＵポインタ３２７は、状態情報フィールドが割り当てられたこのＰＤＵと同じサービス・パケットの一部分である次のＰＤＵの場所を与える。即ち、同じサービス・パケットの一部分であった各ＰＤＵは、送信ラインバッファ記述子３０５の状態情報フィールドの中のネクストＰＤＵポインタ３２７によってリンクされる。

表１は、送信ラインバッファ記述子３０５の中のフィールドのうちの１つがＴＬＢＥＱ ３１５のベースアドレスを指示することを表す。別のフィールドは、ＰＤＵのサイズを指示する（なお、開示された方法及び装置の一実施形態では、すべてのＰＤＵが同じサイズである）。開示された方法及び装置の一実施形態によれば、送信ラインバッファ記述子３０５の中の各エントリは順次に格納される。

ＤＩＣ ＴＣ １４０は、各エントリ３１９に関連付けられた状態情報フィールドを、関連付けられたエントリ３１９が書き込みプロセスによって所有されること（即ち、ＤＩＣ ＴＣ １４０がこのエントリ３１９を所有すること）を示す状態に対する状態情報フィールドを見つけるまで読み取る。ＤＩＣ ＴＣ １４０は、その後、サービス・パケットの１番目のＰＤＵをエントリ３１９に書き込む。ＤＩＣ ＴＣ １４０は、次に、エントリ３１９をＭｏＣＡポート制御ＴＣ １３３に渡す。ＴＬＢＥＱ ３１５にコピーされたサービス・パケット毎に、ＤＩＣ ＴＣ １４０は、関連付けられたＰＤ ３２１を生成する（図３を参照のこと）。ＰＤ ３２１は、以下のフォーマットを有する。

ＰＤ ３２１は、このＰＤ ３２１と関連付けられたサービス・パケットの１番目のＰＤＵを指示するインデックス（図３に示されたＰＤＵ０ポインタ３２８）を収容する。同じサービス・パケットのその他のＰＤＵは、送信ラインバッファ記述子３０５の中の各エントリ３１９の状態情報フィールド内部の「ネクストＰＤＵ」ポインタ３２７によって一緒に連結される（オフセット０ｘ２４のビット８−２３、表１を参照のこと）。ネクストＰＤＵポインタ３２７は、同じサービス・パケットの次のＰＤＵを保持するエントリを指示する。このように、同じサービス・パケットに由来するＰＤＵのすべては、一緒につなぎ合わされる。列の中の最後のＰＤＵを保持するエントリ３１９の状態情報フィールドは、ＦＦＦにセットされたネクストＰＤＵを有する。

プロトコル記述子３２１は、ＭｏＣＡ ＣＰＵ Ｉ／Ｄメモリ１１２に位置するプロトコル記述子キュー３２３に格納される。開示された方法及び装置の一実施形態によれば、プロトコル・記述子キュー３２３は、３２個のＰＤを保持することが可能である。プロトコル記述子キュー３２３は、ＭｏＣＡ ＣＰＵ １１４によって定期的に読み込まれる。ＭｏＣＡ ＣＰＵ １１４は、ノード１０２と１０４との間のＭｏＣＡネットワークを介して予約要求を生成するため、プロトコル記述子３２１を使用する。予約要求が許可されたとき、ＭｏＣＡ ＣＰＵ１１４は、送信されるべきＭｏＣＡパケット毎にＭｏＣＡ記述子を生成する。予定に入れられた送信時刻に、ＭｏＣＡポート制御ＴＣ １３３は、ＴＬＢＥＱ ３１５から同時に１つのＰＤＵを読み出す。ＰＤＵがＴＬＢＥＱ ３１５から読み出されると、ＭｏＣＡポート制御ＴＣ １３３は、ＰＤＵが読み出されたＴＬＢＥＱエントリ３１９のオーナーシップを、ＰＤ内のＳＷ＿ＯＷＮＥＲＳＨＩＰビット（図２を参照のこと）をリセットすることにより、ＤＩＣ ＴＣ １４０へ戻す。

ＭｏＣＡ ＣＰＵ １１４は、ＭｏＣＡネットワークを介して受信ノード１０４へ送信するため現在利用可能であるパケットが存在することを示すＰＤの個数（即ち、値１にセットされたＳＷ＿ＯＷＮＥＲＳＨＩＰビットを有するＰＤの個数）を調べるためにプロトコル記述子キュー３２３をチェックする。ＭｏＣＡ ＣＰＵ １１４は、同じパケット集約属性（即ち、宛先ノード及び優先度）を共有するできるだけ多数の現在利用可能なＰＤを最大ＭｏＣＡパケットサイズ（８ｋバイト）にできる限り近いサイズを有する単一のＭｏＣＡパケットにグループ分けする。ＭｏＣＡ ＣＰＵ １１４は、ＭｏＣＡパケット毎に１個のＭｏＣＡ予約要求を作成する。予約要求が許可されると、数個のＭｏＣＡパケット（１つずつが１つのこのような予約要求と関連付けられる）が送信可能である。予約要求が許可されたとき、送信ノード１０２は、ＭｏＣＡネットワークを介して受信ノード１０４へＭｏＣＡパケットを通信する機会が与えられる。

ノード１０２、１０４がＭｏＣＡを使用して通信する実施形態によれば、使用される２つのＭｏＣＡパケットフォーマットが存在する。２つのうちのどちらが選択されるかは、２つ以上のサービス・パケットからのＰＤＵがＭｏＣＡパケットに集約されるかどうかに依存する。開示された方法及び装置の一実施形態によれば、２つ以上のサービス・パケットからＰＤＵを集約するため、受信及び送信の両方のノード１０２、１０４は、集約されたパケットを取り扱う能力をもつことが必要である。しかし、送信及び受信の両方のノード１０２、１０４が集約を取り扱う能力をもつ場合でも、他の理由により２つ以上のサービス・パケットからのＰＤＵが送信ノード１０２から受信ノード１０４へ送信されるＭｏＣＡパケットの中に集約されないことがある。

第１のＭｏＣＡパケットフォーマットは、２つ以上のサービス・パケットからのＰＤＵが集約されない場合に使用される。この場合、唯一のサービス・パケットのＰＤＵが集約ヘッダを必要とすることなく連結される。

従って、このフォーマットは次の通りである。

表３に示された事例では、元のサービス・パケットは、２つのＰＤＵに分割されることが要求される長さを有するが、両方のＰＤＵは、同じＭｏＣＡパケットの中でＭｏＣＡネットワークを介して送信される。なお、この事例に関して、受信サービス・パケットをＰＤＵに分割する唯一の理由は、異なったサービス・パケットからのパケットが集約されなければならない事例との整合性である。即ち、サービス・パケットが処理されているときに、サービス・パケットの内容が別のサービス・パケットからのＰＤＵと共に集約されるかどうかは分からないので、サービス・パケットは、ＰＤＵに分割される。

第２のＭｏＣＡパケットフォーマットによれば、集約ヘッダは、ＭｏＣＡパケットの中に収容されたサービス・パケットを記述する。１つのＭｏＣＡパケットは、２つ以上のサービス・パケットからのＰＤＵを収容し得る。

表４に示されるように、第２のＭｏＣＡパケットフォーマットは、ＭｏＣＡヘッダを含む。表５は、ＭｏＣＡヘッダのためのフォーマットを示す。

ＭｏＣＡヘッダは１０個のサブフィールドを有する。表５に示されたＭｏＣＡヘッダ内の１番目のサブフィールドは、システム時刻を提供する３２ビット送信クロックサブフィールドである。ヘッダ内の２番目のサブフィールドは、パケットタイプ（即ち、第１のタイプ又は第２のタイプ）を示す。ヘッダ内の３番目のサブフィールドは、将来の使用のため予約済みである。４番目のサブフィールドは、使用されているＭｏＣＡ ＭＡＣレイヤのバージョンを示す。５番目のサブフィールドは、このＭｏＣＡパケット内のサービス・パケットが発せられた発信元ノードを示す。なお、一実施形態では、２つ以上の発信元ノードから発せられたサービス・パケットが存在する。６番目のサブフィールドは、ＭｏＣＡパケット内の各サービス・パケットが送信されている宛先ノードである。なお、ＭｏＣＡパケットの中のサービス・パケットのすべては、同じ宛先ノードを有する。しかし、ＭｏＣＡパケット内のサービス・パケットのすべてがブロードキャストされるべき場合、宛先は、ネットワーク内の他のノードのすべてである可能性もある。

表５に見られるように、７番目のサブフィールドは、ヘッダと、すべての他の内容及びオーバーヘッドとを含むＭｏＣＡパケットの長さを示す。８番目のサブフィールドは、２４ビットの予約済みビットを備える。９番目のサブフィールドは、集約−断片化制御サブフィールドと呼ばれ、４ビットを含む。集約−断片化制御サブフィールドの１番目のビットは、集約ヘッダがこのＭｏＣＡパケットの中に存在するかどうかを示す。２番目のビットは、シーケンス番号が含まれるかどうかを示す。シーケンス番号は、この特定のＭｏＣＡパケットがこのシーケンスのうちの他のパケットに関してシーケンスの数個のパケットの中でいずれのパケットであるかを示すため使用される。集約−断片化制御サブフィールドの３番目のビットは、集約ヘッダチェックサムが使用されているかどうかを示す。集約−断片化制御サブフィールドの４番目及び最後のビットは、フレーム・チェック・シーケンスがＭｏＣＡパケットの中で使用されているかどうかを示す。ＭｏＣＡヘッダ内の１０番目及び最後のサブフィールドは、前方誤り訂正のため使用されるヘッダ・チェック・シーケンスである。

ＭｏＣＡパケットの２番目のフィールドは集約ヘッダである。一般に、集約ヘッダは、このＭｏＣＡパケットの中でどのサービス・パケットが後に続くべきかを示す。表６は、集約ヘッダのフォーマットを示す。

集約ヘッダは可変長を有する。長さは、集約されるべきサービス・パケットの個数に依存する。開示された方法及び装置の一実施形態では、各サブフィールドは長さ１６ビットを有する。集約ヘッダのビット単位の長さは、３とＭｏＣＡパケット内に集約されたサービス・パケットの個数との合計の１６倍である。従って、８個のサービス・パケットがＭｏＣＡパケットの中に集約されている場合、集約ヘッダは長さ１６＊（３＋８）＝１７６ビットを有する。

集約ヘッダの１番目のサブフィールドは、シーケンス番号である。シーケンス番号は、このＭｏＣＡパケットが、送信されるべき複数のＭｏＣＡパケットのシーケンスの内部で占める相対位置を示すために使用される。集約ヘッダの２番目のフィールドは、このＭｏＣＡパケットの中に集約されるべきサービス・パケットの個数を表現するサービス・パケット・カウントである。後に続くＮ個のサブフィールドのうちの１つずつは、集約されているサービス・パケットのうちの１つずつのサイズ（バイト単位）を示すサービス・パケット・サイズである。最後のサブフィールドは、集約ヘッダ全体のチェックサムである。

開示された方法及び装置の一実施形態によれば、ノード許可フェーズ中に、そして、リンク・レイヤ・メッセージングのため、タイプＩフォーマットだけが使用される。

ＭｏＣＡ ＣＰＵ １１４は、プロトコル記述子キュー３２３からＰＤを読み込むことにより、各ＭｏＣＡパケットの中で集約されるサービス・パケット（即ち、ＰＤＵ）を選択する。プロトコル記述子キュー３２３の中の各ＰＤは、集約ＩＤ ３２５と関連付けられる。開示された方法及び装置の一実施形態では、集約ＩＤ ３２５は、宛先ノードを示すため使用される値（即ち、ＰＤと関連付けられているサービス・パケットが送信されるべきノード）をサービス・パケットの優先度を示すため使用される値と連結することにより形成される。優先度は、優先順位付け及び／又はパラメータ化されたサービス品質（ＰＱｏＳ）を採用するＭｏＣＡネットワークにおいて周知の概念である。サービス・パケットと関連付けられている優先度が存在しない実施形態では、宛先単独で集約ＩＤを決定する。集約ＩＤが他のアプリケーションのための他の方式で形成できることは、当業者によって理解されるであろう。即ち、ＰＤと関連付けられたサービス・パケットの他の特性は、１つのＭｏＣＡパケットの中で一緒に集約すべきサービス・パケット、又は、各サービス・パケットのＰＤＵを決定するため使用できる。

ＭｏＣＡ ＣＰＵ １１４は、ＭｏＣＡネットワークに置く準備ができているＰＤの個数と、これらのＰＤと関連付けられたＰＤＵがすべて１つのＭｏＣＡパケットに収まるかどうかと、各ＰＤが同じ集約ＩＤを有するかどうかとをチェックする。準備が完了し、１つのＭｏＣＡパケットの中に収まり、そして、同じ集約ＩＤを有するＰＤの全部は、１つのＭｏＣＡパケットの中に集約される。目的は、ＭｏＣＡネットワークの効率を向上させるためにＭｏＣＡパケットをできる限り大きくすることである。しかし、ＭｏＣＡネットワークの効率を単に向上させるだけでなく、本方法及び装置の他の利点がおそらく存在することは、当業者に理解されるであろう。

一実施形態によれば、ノード１０２にＭｏＣＡサイクルの範囲内で予約要求の機会が与えられるとき、予約要求が同じ集約ＩＤを有するパケットのグループに対して行われるが、十分なＰＤＵが存在し、その結果、集約されたパケット長が所定のバイト数（例えば、４ｋバイト）より長いときに限られる。そうでなければ、現在の予約要求は通過させられ、次の予約要求の機会が来るまで、ＭｏＣＡパケットは送信されない。一実施形態によれば、タイマは、所定の時間後にタイムアウトし、送信機は、このタイムアウト後に送信するため利用できるＰＤＵの予約要求を行う。

同じ集約ＩＤを有するサービス・パケットが到着する順番は、サービス・パケットと関連付けられたＰＤがプロトコル記述キュー３２３に書き込まれる順番によって定義される。同じ集約ＩＤをもつＰＤは、リンクドＰＤリストによって一緒にリンクされる。このリンケージは、少なくとも２つの異なる方法のうちの一方によって作成することができる。

リンクドＰＤリストを生成する第１の方法は、ＤＩＣ ＴＣ １４０が新たに受信されたサービス・パケット毎にＰＤを作成したとき、固有の集約ＩＤ毎に１つのリンクドＰＤリストを作成することである。図３のプロトコル記述子キュー３２３は、リンクドＰＤリストがどのように取り扱えるかについての一実施例の説明図である。本実施形態によれば、ＤＩＣ ＴＣ １４０は、集約ＩＤ３２５及びネクストＰＤポインタ３２７をプロトコル記述子キュー３２３に格納することによりリンクドＰＤリストを最初に作成する。最初に、ネクストＰＤポインタ３２７は、デフォルト値のままにされ、同じ集約ＩＤをもつ後続のサービス・パケットが受信されないことを示す。開示された方法及び装置の本実施形態によれば、ＤＩＣ ＴＣ １４０は、各リンクドＰＤリストのための「リード」ポインタ及び「プリービアスＰＤ」ポインタを維持する。

リードポインタは、リンクドＰＤリストの先頭を指示する。従って、各リンクドＰＤリストは、このリストと関連付けられた１個のリードポインタを有する。ＭｏＣＡ ＣＰＵ １１４がＭｏＣＡパケットを形成すべき時、リードポインタは、ＤＩＣ ＴＣ １４０がリストのヘッドを見つけることを可能にする。このようにして、リードポインタをＭｏＣＡ ＣＰＵ １１４に伝達することにより、ＭｏＣＡ ＣＰＵ １１４は、予約要求を行うため、相対的な時間の順番に同じ集約ＩＤをもつすべてのＰＤを読み出すことが可能である。ネクストＰＤポインタは、リンクドＰＤリスト内の各エントリを次のエントリに接続する。

従って、１番目のサービス・パケットが受信されたとき、集約ＩＤ値を集約ＩＤ ３２５にロードするのに加えて、ＤＩＣ ＴＣ １４０は、この１番目のＰＤの場所をリードポインタとプリービアスＰＤポインタの両方に保存する。新しいサービス・パケットが同じ集約ＩＤを用いて受信されたとき、このサービス・パケットのためのＰＤは、集約ＩＤ ３２５を含む。ネクストＩＤポインタ３２７は、最初に、このネクストＩＤポインタが直前に受信されたサービス・パケットと関連付けられたことを示すデフォルト値を有する。しかし、ＤＩＣ ＴＣ １４０は、リンクドＰＤリストの最後のＰＤ（この場合、リンクドＰＤリストの中の１番目のＰＤ）の位置を識別するためプリービアスＰＤポインタを使用する。ＤＩＣ ＴＣ １４０は、その後、この直前に受信されたサービス・パケットと関連付けられたＰＤの値を用いてプリービアスＰＤポインタによって示されたＰＤのネクストＰＤポインタ３２７を更新する。その上、ＤＩＣ ＴＣ １４０は、新しいＰＤの値を用いてＤＩＣ ＴＣ １４０によって保持されるプリービアスＰＤポインタを更新するので、次のサービス・パケットが到着したとき、ＤＩＣ ＴＣ １４０は、リンクドＰＤリストの最後を見つけることができる。

このように、新しいサービス・パケットが受信され、ＰＤがこのサービス・パケットのため生成されるたびに、リンクドＰＤリストは、この新しいＰＤを組み入れるように更新される。この方法では、サービス・パケットが受信された相対的な順番と、関連付けられた各ＰＤの位置とがリンクドＰＤリストによって保持されるので、ＤＩＣ ＴＣ １４０は、プロトコル記述キュー３２３の空いている場所に新しいＰＤを書き込む。

リンクドＰＤリストを生成する第２の方法は、ＤＩＣ ＴＣ １４０が最初のエントリ（エントリ番号０）から最後のエントリ（エントリＭ−１）まで順番に新しいＰＤをプロトコル記述キュー３２３に追加する。本実施形態では、プロトコル記述キュー３２３は循環式である。即ち、プロトコル記述キュー３２３の中の最後のエントリ（エントリＭ−１）は、元の最初のエントリ（エントリ０）を指示する。従って、各ＰＤと関連付けられた各サービス・パケットが受信された相対的な順番がプロトコル記述キュー３２３の中に保持される。ＭｏＣＡ ＣＰＵ １１４は、ＭｏＣＡ ＭＡＰサイクルの範囲内で時々にプロトコル記述キュー３２３からこれらのＰＤを読み出す。ＭｏＣＡ ＣＰＵ １１４は、これらのＰＤを適切なリンクドＰＤリストの中にソートし、予約要求を生成するため使用されるべきＭｏＣＡ ＣＰＵ Ｉ／Ｄメモリ１１２にこれらのＰＤを格納する。ＰＤがＭｏＣＡ ＣＰＵ １１４によって読み込まれると、プロトコル記述キュー３２３の中のこのエントリは、元のＤＩＣ ＴＣ １４０に開放されるので、次のＰＤを格納することができる。

なお、送信ラインバッファ・エントリ・キュー３１５全体がすべてのＰＤＵで利用できる場合、問題が起こる可能性がある。この問題は、各サービス・パケットが最低優先度を有するサービス・パケットの大型ブロックがＧＥＰＨＹコントローラ１０８によって受信された場合に生じる。受信サービス・パケットの１つずつは、必要に応じて断片化され、サービス・パケットから形成されたＰＤＵは、前述されたように、送信ラインバッファ・エントリ・キュー３１５の中に格納される。これらの低優先度ＰＤＵは、送信ラインバッファ・エントリ・キュー３１５全体を占有する可能性がある。従って、低優先度ＰＤＵの一部が送信ラインバッファ・エントリ・キュー３１５から追い出されるまで、より優先度の高いサービス・パケットは、ＧＥＰＨＹ受信バッファ・キュー３０９から受信することができない。このような低優先度サービス・パケットがより優先度の高いサービス・パケットが受信されることを妨げるのは望ましくない。さらに、より優先度の高いサービス・パケットの定常ストリームが、ＭｏＣＡネットワークを介してＭｏＣＡパケットを送信することができるレートと等しいレートでＭｏＣＡノードの中に入る場合、多数のこれらの低優先度サービス・パケットは、非常に長期間に亘って、送信ラインバッファ・エントリ・キュー３１５の中に「捕捉」される可能性がある（即ち、他のノード上のより優先度の高いパケットがネットワーク帯域幅の大半を使用しており、そして、検討中のノードの中のより優先度の高いパケットが同じノードの中のより優先度の低いパケットによって妨げられている）。送信ラインバッファ・エントリ・キュー３１５がより優先度の低いサービス・パケットを追い出し始めるときは、新しい優先度の高いサービス・パケットが着信するレートが、ＭｏＣＡパケットが送信ラインバッファ・エントリ・キュー３１５から生成され、ＭｏＣＡネットワークを介して送信されるレートよりも低いときに限られる。

このことを回避するため、仮想キューの概念が使用される。各集約ＩＤ ３２５は、仮想キュー３２９と関連付けられる（図３を参照のこと）。各仮想キュー３２９は、設定可能な最大サイズを有する。各仮想キュー３２９は、仮想キュー３２９が満杯状態であるときに実行すべきことを定義する設定可能な属性をさらに有する。この属性は、パケットが入ることを許可しないか、若しくは、パケットが入ることを許可するが、パケットを飛ばすようにＭＩＩ／ＧＭＩＩフロー制御（ポーズフレーム）をトリガするため、又は、仮想キュー３２９が満杯状態である限り、パケットに既存のパケットを上書きさせるためセットすることが可能である。

各サービス・パケットは、仮想キュー３２９のうちの１つを通過しなければならないので、仮想キュー３２９のサイズは、この仮想キュー３２９のための最大実現可能送信スループット（即ち、この仮想キュー３２９と関連付けられた集約ＩＤを有するこれらのサービス・パケットのためのスループット）を決定する。従って、このスループットを最適化するため、各仮想キューをできる限り大きくすることが望ましい。これに反して、低優先度集約ＩＤと関連付けられた低優先度パケットは、長期間に亘って仮想キュー３２９の中に留まる。これは、仮想キュー３２９が格納される共有メモリの効率を低下させる。従って、メモリを低優先度仮想キューに過剰に割り当てないことが望ましい。高優先度パケットが比較的少ないときに、着信する高優先度パケットを詰まらせることなく、送信ラインバッファ・エントリ・キュー３１５の効率を最大にし、そして、低優先度パケットのための最大可能なスループットを実現するための１つの方式は、各仮想キュー３２９の最大サイズのための最適値を選ぶことである。最適値は、ノード自体及びネットワークの両方のトラフィックプロファイルの関数である。開示された方法及び装置の一実施形態では、トラフィックプロファイルが変化するとき、仮想キュー３２９は動的にサイズ変更されることがある。

開示された方法及び装置の一実施形態によれば、仮想キューの動的サイズ変更は、通常動作中にアプリケーションソフトウェアによってオン・ザ・フライ（本質的にリアルタイム）で実行される。１つのこのような実施形態では、アプリケーションソフトウェアは、外部ネットワークプロセッサ１２４の中にある（図２を参照のこと）。別の実施形態では、アプリケーションソフトウェアは、ＭｏＣＡ ＣＰＵ １１４の中にある。動的サイズ変更は、フロー（即ち、サービス・パケットのストリーム）を追加又は削除するために、様々な仮想キュー３２９の相対的な最大スループット限界を再均衡化するため必要とされることがある。１つのこのような実施形態では、アプリケーション・ドライバは、各仮想キュー３２９のサイズを直接的に修正する。各仮想キュー３２９のサイズは、共有メモリ１１８の中のメモリ・ロケーションに格納される。代替的に、各仮想キュー３２９のサイズは、ＭｏＣＡ ＣＰＵ Ｉ／Ｄメモリ１１２に格納される。いずれの場合も、サイズは、外部ネットワークプロセッサ１２４、ＤＩＣ ＴＣ １４０、及び、ＭｏＣＡ ＣＰＵ １１４で利用可能である。仮想キュー３２９がサイズを削減されるとき、仮想キュー３２９の中に現在あるＰＤＵの個数は、新しいサイズの仮想キュー３２９が収容する個数を上回ることがある。しかし、開示された方法及び装置の一実施形態によれば、ＰＤＵが飛ばされることはない。一実施形態によれば、新しいサイズの仮想キュー３２９は、新たに到着するパケットだけのため効果を奏する。仮想キュー３２９のサイズの変更後に到着する新しいパケットは、仮想キュー３２９のためセットされた設定に依存して、ＧＭＩＩ／ＭＩＩ（Ｘｏｆｆ状態）によって阻止されるか、又は、飛ばされる。

各集約ＩＤは、１つのＭｏＣＡパケットに集約させることができるパケットを識別する。開示された方法及び装置の一実施形態では、集約ＩＤは、同じ宛先に送信されるべき同じ優先度レベルをもつすべてのパケットのグループと関連付けられる。Ｎ個の宛先ノード及びＰ個の優先度レベルをサポートするため、Ｎ×Ｐ個の仮想キュー３２９が必要である。例えば、Ｎ＝１５かつＰ＝４である場合、６０個の仮想キュー３２９が必要とされる。共有メモリが制限されている場合、各ラインバッファは非常に小さい。比較的小さい仮想キューは、パケット集約を行うことができる程度を制限する。なぜならば、単一のＭｏＣＡパケットに集約されるべきパケットは、同じ仮想キュー３２９の中に属する必要があるからである。良好なパケット集約を実現するため、各仮想キューは、十分な個数のＰＤＵを保持するために十分に大きくする必要がある。開示された方法及び装置の一実施形態では、実施されている特定のアプリケーションについての知識は、各仮想キューのサイズを定義し、そして、各集約ＩＤを定義するのに役立てるため使用することが可能である。一実施例では、１つの優先度レベルだけが考慮される（同じ宛先へ向けられたパケットのすべてをそれぞれの優先度と無関係に１つのＭｏＣＡパケットの中に集約する）。別の実施例では、宛先ノードの個数は限定される。当業者は、仮想キュー３２９を効率的に使用するいくつかの他のこのような方式を特定することができるだろう。

開示された方法及び装置の一実施形態によれば、すべての仮想キュー３２９のサイズの和は、送信ラインバッファ・エントリ・キュー３１５の合計サイズに等しい。開示された方法及び装置の代替的な実施形態では、すべての仮想キュー３２９のサイズの和は、送信ラインバッファ・エントリ・キュー３１５の合計サイズより大きい。これは、トラフィックの動的な性質（即ち、トラフィックのレートと各優先度のサービス・パケットの個数のいずれも一定ではないという事実）を受け入れる。開示された方法及び装置の一実施形態によれば、仮想キュー３２９のうちのいずれか１つは、この仮想キューが満杯状態であるとき、フロー制御をトリガするようにプログラムすることができる。別の実施形態によれば、仮想キュー３２９のいずれかの一部分は、この一部分のうちの一部又はこの一部分のうちの全部が満杯状態であるとき、フロー制御をトリガするためプログラムすることができる。代替的に、送信ラインバッファ・エントリ・キュー３１５が満杯状態であるとき、ＭＩＩ／ＧＭＩＩフロー制御がトリガされる。

開示された方法及び装置の１つの代替的な実施形態によれば、サービス・パケットがイーサネットを介してノード１０２へ送信される前に、外部イーサネット・ドライバは、サービス・パケットをバッファする。サービス・パケットは、集約され、時系列に入れることができるパケットのグループへ直接的に成形される。パケットは、その後、ノード１０２によって、直接的にＭｏＣＡパケットの中に集約することができるクラスタに受信される。各クラスタは、同じ宛先及び同じ優先度のためのパケットを収容することがある。代替的に、パケットは、他の集約基準を使用してクラスタ化される。クラスタは、たった１つだけのパケット（集約無し）を収容することがあり、又は、数個のパケットを収容することがある。開示された方法及び装置の実施形態によれば、送信されるべきすべてのＭｏＣＡパケットに対し１つだけの送信キューが存在する。循環式送信ラインバッファ・エントリ・キュー３１５は、逐次方式で動作する。ＭｏＣＡ ＣＰＵ １１４は、送信ラインバッファ・エントリ・キュー３１５で利用できるパケットの１つ以上のクラスタのための予約要求を行う。集約メカニズムの効率は、外部ホストにおけるトラフィック成形の関数である。

受信パス
今度は別のノード１０４から集約パケットを受信するため使用される方法及び装置を参照すると、プロセスは、ＭｏＣＡネットワークを介してノード１０２によってＭｏＣＡパケットが受信されることから始まる。送信パスについての前述の説明の場合と同様に、ノード１０２と１０４との間でネットワークを実施するため使用されるプロトコルは、パケットがノード１０２と１０４との間で通信されることを可能にするどのようなプロトコルでもよい。しかし、特定の実施形態を実証するために、ＭｏＣＡネットワーク及びプロトコルが本明細書中で説明される。

ノード１０４からノード１０２によって受信されたＭｏＣＡパケットは、最初に、ＭｏＣＡポート制御ＴＣ １３３によって受信される。ＭｏＣＡポート制御ＴＣ １３３は、共有メモリ１１８に位置している受信ラインバッファ・エントリ・キュー３１３の１つ以上のエントリへパケットを転送するようにＤＭＡをプログラムする（図２及び３を参照のこと）。開示された方法及び装置の一実施形態では、受信ラインバッファ・エントリ・キュー３１３の各エントリは、少なくとも１つの最大ＭｏＣＡパケットを保持するために十分なパケット・データ・スペースを有しキュー３１３は設定可能な個数のエントリを収容する。

ＭｏＣＡポート制御ＴＣ １３３は、情報を受信ラインバッファ記述子３０７の中にロードすることによりＤＭＡをプログラムする。受信ラインバッファ記述子３０７は、受信ラインバッファ・エントリ・キュー３１３内の関連付けられたエントリが新たに受信されたＭｏＣＡパケットを受け入れるため利用可能であるかどうかを示すオーナーフラグを含む。これらのエントリは、その後、オーナーフラグの状態を変更することにより、ＧＥＰＨＹコントローラ１０８内部のＤＩＣ ＴＣ １４０へ渡される。

ＤＩＣ ＴＣ １４０は、最初に、ＭｏＣＡパケットヘッダ及び集約ヘッダを調べる。ＤＩＣ ＴＣ １４０は、ＧＥＰＨＹ送信記述子キュー３０３の中のＧＥＰＨＹ送信記述子の内部のＯＷＮビットをさらに調べる。ＯＷＮビットは、ＧＥＰＨＹ送信バッファ・キュー３１１内部の次のＧＥＰＨＹ送信バッファ・エントリがサービス・パケットを受け入れるため利用可能であるかどうかを示す。ＤＩＣ ＴＣ １４０は、（ＭｏＣＡパケットの中の）受信サービス・パケット毎の１つの利用可能なＧＥＰＨＹ送信記述子にこのサービス・パケットを記述する情報をロードする。ＤＩＣ ＴＣ １４０は、ＭｏＣＡパケット内部に受信された集約ヘッダを読み込むことにより受信されたサービス・パケットの個数を決定する。開示された方法及び装置の一実施形態によれば、ＧＥＰＨＹ送信記述子キュー３０３は、２つのＧＥＰＨＹ送信記述子を保持するために十分なスペースを有している。従って、ＧＥＰＨＹ送信バッファ・キュー３１１は、２つの出て行くサービス・パケットを保持するために十分なスペースを有している。開示された方法及び装置の別の実施形態によれば、ＧＥＰＨＹ送信記述子キュー３０３は、設定可能な個数のＧＥＰＨＹ送信記述子を保持する。

受信ラインバッファ・エントリ・キュー３１３は、ＰＤＵのユニットで編成されるが、各ＧＥＰＨＹ送信記述子は、１つの完全なサービス・パケットを記述する。ＧＥＰＨＹ送信記述子キューは、循環式に動作し、ＤＩＣ ＴＣ １４０によってセットアップされる。ＧＥＰＨＹ送信記述子は、その後、送信記述子のＯＷＮビットをＧＥＰＨＹ ＤＭＡ１３２に切り替えることにより、ＧＥＰＨＹコントローラのＤＭＡ １３２に渡される。ＤＭＡ １３２は、サービス・パケット（イーサネット・パケット）をＧＥＰＨＹコントローラ１０８に転送し、ＧＥＰＨＹコントローラ１０８は、その後、できる限り早くＧＭＩＩ／ＭＩＩを介してイーサネット・パケットを送出する。イーサネット・パケットを送信した後、ＧＥＰＨＹ送信記述子は、ＯＷＮビットをリセットすることにより元のＤＩＣ ＴＣ １４０へ渡され、ＤＩＣ ＴＣ １４０は、送信記述子状態を処理し、この記述子を再利用する。ＤＩＣ ＴＣ １４０は、個別単位で、又は、グループ単位で送信記述子を定義し処理することが可能である。Ｒｘ受信バッファ・エントリ・キューからＧＥＰＨＹ送信バッファ・キューへＭｏＣＡパケットを転送するプロセスの間に、ＤＩＣ ＴＣ １４０は、アプリケーション依存型の所定の基準を使用して、これらのパケットにフィルタリング（サービス・パケットの一部を飛ばすことを含む）を実行できる。

開示された方法及び装置の一実施形態では、２つのＧＥＰＨＹ送信記述子が使用され、各ＧＥＰＨＹ送信記述子は、各サービス・パケットがイーサネット・ネットワークを介して送信されるべきである受信ラインバッファ・エントリ・キュー３１３内のサービス・パケットを記述する。ＧＥＰＨＹ送信記述子は、受信記述子と同じフォーマットを有する。

開示された方法及び装置の一実施形態では、受信ラインバッファ・エントリ・キューは、２個以上のＭｏＣＡパケットを保持することができる。ＭｏＣＡパケットが受信され、ＤＩＣ ＴＣ １４０へ渡されるとき、最小サイズは、ＤＩＣ ＴＣ １４０の応答処理速度の関数である。

開示された方法及び装置の一実施形態では、ＧＭＩＩ／ＭＩＩ速度は、ＭｏＣＡネットワークを介して最良スループットを実現するために、ＭｏＣＡネットワーク速度を十分に上回るように設定される。ＧＭＩＩ／ＭＩＩ速度がＭｏＣＡネットワーク速度に近いか、又は、下回る場合、受信ラインバッファ・エントリ・キュー３１９は、ＭｏＣＡネットワークを介してノード１０２に入るトラフィックのバーストを吸収するために、十分に大きく設定することが必要である。一実施形態では、受信ラインバッファ・エントリ・キュー３１９の正確なサイズは、受信ノード１０２によって使用される最大ビット−ローディングの関数である。一実施形態では、受信ノードは、送信ノードが受信ノードへ望まれるより高速にデータを送信しないようにこの受信ノードが受信するパケットのビット−ローディングを制限することがある。一実施形態では、ビットローディング限界は、パケットが外部ネットワークプロセッサ１２４から外部ネットワークを介して受信される速度に近い。

開示された方法及び装置の様々な実施形態がここまでに記載されているが、これらの実施形態は、一例として提示されているだけであり、請求項に記載された発明を限定すべきでないことが理解されるべきである。同様に、様々な図面は、開示された方法及び装置のための実例的なアーキテクチャ構成又はその他の構成を描写している。このことは、開示された方法及び装置に含まれる可能性がある特徴及び機能性の理解を助けるために行われている。請求項に記載された発明は、図示された実例的なアーキテクチャ又は構成に制限されず、それどころか、望ましい特徴は、多種多様の代替的なアーキテクチャ及び構成を使用して実施されることができる。実際に、代替的な機能的、論理的、又は、物理的な区分化及び構成が開示された方法及び装置の望ましい特徴を実施するために実施されることが可能であることは、当業者に理解できるであろう。さらに、本明細書中に描かれていない多数の異なる構成モジュール名が様々な区分に適用可能である。付加的に、フローチャートに、動作的な説明、及び、方法の請求項に関して，ステップが本明細書中に提示されている順番は、前後関係が別の指示をしない限り、様々な実施形態が列挙された機能性を同じ順番で実行するように実施されることを義務づけるものではない。

開示された方法及び装置は、様々な例示的な実施形態及び実施の観点でここまでに記載されているが、１つ以上の個別の実施形態に記載された様々な特徴、態様及び機能性が適用可能性の点でこれらの特徴、態様及び機能性が記載された特定の実施形態に限定されないことが理解されるべきである。よって、請求項に記載された発明の広がり及び範囲は、前述のいずれの例示的な実施形態によっても限定されるべきでない。

本明細書中で使用された用語及び句と、これらの変形とは、特に断らない限り、限定としてではなく、開放形式として解釈されるべきである。上記の例として、用語「含む」は、「限定無しに含む」などを意味するものとして読まれるべきであり、用語「実施例」は、検討中の項目の例示的な事例を、網羅的ではなく、又は、限定的なリストとして提供するためではなく使用され、単数形は、「少なくとも１つ」、「１つ以上」などを意味するものとして読まれるべきであり、そして、「従来的な」、「伝統的な」、「通常の」、「標準的な」、「既知の」のような形容詞と、類似した意味の用語は、記載された用語を所与の期間、又は、所与の時点に利用可能な項目に限定するものとして解釈されるべきでなく、その代わりに、現在若しくは将来のいずれかの時点で利用可能若しくは知られている、従来的な、伝統的な、通常の、又は、標準的な技術を包含するように読まれるべきである。同様に、本明細書は、当業者に明白又は公知である技術に言及しているが、このような技術は、現在又は将来のいずれかの時点での当業者に明白又は既知である技術を包含する。

接続詞「及び」を用いて結合されている項目のグループは、これらの項目の１つずつがグループ分けの中に存在することを要求するものとして読まれるべきではなく、むしろ、特に断らない限り、「及び／又は」として読まれるべきである。同様に、接続詞「又は」を用いて結合されている項目のグループは、このグループの中での相互排他性を要求するものとして読まれるべきでなく、むしろ、特に断らない限り、「及び／又は」として読まれるべきである。さらに、開示された方法及び装置の項目、要素、又は、コンポーネントは、単数形で記載又は請求項に記載されているが、単数形への制限が明示されていない限り、複数形がこれらの範囲に含まれることが考慮されている。

一部の例における「１つ以上」、「少なくとも」、「限定されることなく」、又は、同様の句のような拡張語及び拡張句の存在は、より狭義の事例がこのような拡張句が存在しない事例において意図又は要求されることを意味するように読まれるべきでない。用語「モジュール」の使用は、モジュールの一部として記載又は請求項に記載されたコンポーネント又は機能性がすべて共通のパッケージの中に構成されることを含意しない。実際に、モジュールの種々のコンポーネントのうちのいずれか又は全部は、制御ロジックであるか、又は、その他のコンポーネントであるかとは無関係に、単一のパッケージに組み合わせてもよく、又は、別々に維持されてもよく、そして、複数のグループ分け若しくはパッケージに、又は、複数の場所に亘って分散されてもよい。

付加的に、本明細書中に記載された様々な実施形態は、例示的なブロック図、フローチャート、及び、他の説明図の形で記載されている。本明細書を読んだ後に当業者に明白になるように、図示された実施形態及びこれらの種々の代案は、図示された実例への限定無しに実施することができる。例えば、ブロック図及びこれらのブロック図に付随する説明は、特定のアーキテクチャ又は構成を義務づけるものとして解釈されるべきでない。

Claims (25)

1. 通信制御システムノードであって、該システムは、
   ａ）メモリと、
   ｂ）前記メモリに連結され、
   ｉ）少なくとも１つの受信記述子を生成すること、
   ｉｉ）第１のネットワークからサービス・パケットを受信すること、
   ｉｉｉ）前記受信記述子の内容に基づいて、前記サービス・パケットを前記メモリに格納すること、
   ｉｖ）すべてが同じ長さであるパケット・データ・ユニットを定義すること、
   ｖ）プロトコル記述子を生成し、各プロトコル記述子を１つ以上のパケット・データ・ユニットと関連付けること、及び、
   ｖｉ）各プロトコル記述子を前記メモリの中のエントリに格納すること、
   を可能にさせる命令を実行する能力をもつ物理レイヤ・コントローラと、
   ｃ）ｉ）前記プロトコル記述子を読み込むこと、及び、
   ｉｉ）最小数より多くのプロトコル記述子が前記メモリに格納されている場合、予約要求を第２のネットワーク上に生成すること、
   を可能にさせる命令を実行する能力をもつネットワーク中央処理ユニット（ＣＰＵ）と、
   を備える、通信制御システムノード。
2. 前記コントローラは、直接メモリアクセス（ＤＭＡ）コントローラを含み、前記ＤＭＡコントローラは、前記受信記述子の内容に基づいて、前記サービス・パケットを前記メモリに格納する、請求項１に記載の通信制御システム。
3. 前記サービス・パケットは、第１のプロトコルに従って受信され、前記パケット・データ・ユニットは、第２のプロトコルに従って送信される、請求項１に記載の通信制御システム。
4. 前記第１のネットワークはイーサネット・ネットワークであり、前記第２のネットワークは、ＭｏＣＡネットワークである、請求項３に記載の通信制御システム。
5. 前記サービス・パケットは、イーサネット・パケットである、請求項４に記載の通信制御システム。
6. 前記受信されたサービス・パケットのサイズが前記パケット・データ・ユニットのサイズと異なる、請求項３に記載の通信制御システム。
7. 同じサービス・パケットに由来した内容を有する各パケット・データ・ユニットは、同じプロトコル記述子と関連付けられる、請求項６に記載の通信制御システム。
8. 前記受信されたサービス・パケットは、前記パケット・データ・ユニットとサイズが同じである、請求項３に記載の通信制御システム。
9. 前記物理レイヤ・コントローラは、ギガバイト・イーサネット物理レイヤ・コントローラ（ＧＥＰＨＹ）である、請求項１に記載の通信制御システム。
10. 前記メモリは、受信バッファ、受信ラインバッファ、送信バッファ、及び、送信ラインバッファに分割されている、請求項１に記載の通信制御システム。
11. 前記受信バッファは、受信バッファ・キュー及び受信記述子キューに分割されている、請求項１０に記載の通信制御システム。
12. 前記受信バッファ・キューは、前記物理レイヤ・コントローラから前記サービス・パケットを受信する、請求項１１に記載の通信制御システム。
13. 前記受信バッファ・キューは、前記受信記述子キューによって定義され、制御される、請求項１２に記載の通信制御システム。
14. 前記受信ラインバッファは、受信ラインバッファ記述子及び受信ラインバッファ・エントリ・キューに分割されている、請求項１０に記載の通信制御システム。
15. ポート制御転送コントローラ（ＴＣ）及びバスをさらに含み、ポート制御ＴＣは、前記バスを介して前記ネットワークＣＰＵ及び前記メモリに結合されている、請求項１４に記載の通信制御システム。
16. 前記第２のネットワークから受信されたパケットが前記受信ラインバッファ・エントリ・キューに格納され、前記受信ラインバッファ記述子は、前記受信ラインバッファ・エントリ・キューの中の関連付けられたエントリが前記第２のネットワークから新たに受信されたパケットを受け入れるため利用可能であるかどうかを示すオーナーフラグを含む、請求項１０に記載の通信制御システム。
17. 前記送信バッファは、送信記述子キュー及び送信バッファ・キューに分割されている、請求項１０に記載の通信制御システム。
18. 前記物理レイヤ・コントローラは、受信されたサービス・パケット毎の前記送信記述子キューに前記サービス・パケットを記述する情報をロードする、請求項１７に記載の通信制御システム。
19. 前記送信ラインバッファは、送信ラインバッファ・エントリ・キュー及び送信ラインバッファ記述子に分割されている、請求項１０に記載の通信制御システム。
20. パケット・データ・ユニットを定義することは、前記パケット・データ・ユニットのサイズを決定する制御可能パラメータのための値を選択することを含む、請求項６に記載の通信制御システム。
21. 前記制御可能パラメータの値は自動的に選択される、請求項２０に記載の通信制御システム。
22. 前記制御可能パラメータの値は手動で選択される、請求項２０に記載の通信制御システム。
23. 第１のプロトコルに従って動作するネットワークから第１のデータのパケットを受信し、第２のプロトコルを有する第２のネットワークを介する送信のため、前記第１のデータのパケットからの内容の少なくとも一部を収容する第２のデータのパケットを準備する方法であって、
    ａ）前記第１のデータのパケットを受信することと、
    ｂ）前記第１のデータのパケットを選択的に固定されたサイズをもつパケット・データ・ユニット（ＰＤＵ）に断片化することと、
    ｃ）同じ前記第２のパケットの中で送信されるべき各ＰＤＵが共通の宛先及び優先度を有するように、前記断片化された第１のパケットからのＰＤＵを前記第２のパケットに集約することと、
    を備える方法。
24. コンピュータによって読み取られる命令を記憶する有形記憶媒体であって、
    前記命令は、
    ａ）前記第１のデータのパケットを受信する機能と、
    ｂ）前記第１のデータのパケットを選択的に固定されたサイズをもつパケット・データ・ユニット（ＰＤＵ）に断片化する機能と、
    ｃ）同じ前記第２のパケットの中で送信されるべき各ＰＤＵが共通の宛先及び優先度を有するように、前記断片化された第１のパケットからのＰＤＵを前記第２のパケットに集約する機能と、
    を前記コンピュータに実行させる、有形記憶媒体。
25. コンピュータによって読み取られる命令を記憶する有形記憶媒体であって、
    前記命令は、
    ａ）少なくとも１つの受信記述子を生成する機能と、
    ｂ）第１のネットワークからサービス・パケットを受信する機能と、
    ｃ）前記受信記述子の内容に基づいて、前記サービス・パケットをメモリに格納する機能と、
    ｄ）すべてが同じ長さであるパケット・データ・ユニットを定義する機能と、
    ｅ）パケット・データ・ユニット毎にプロトコル記述子を生成する機能と、
    ｆ）各プロトコル記述子を前記メモリの内部のプロトコル記述子キューの中のエントリに格納する機能と、
    を前記コンピュータに実行させる有形記憶媒体。

Images