JP2013513269A - 信頼性のあるパケットカットスルー - Google Patents

Abstract

カットスルーデータパケット機構が説明される。中間ノードにより、カットスルーデータパケットを転送することで、パケットにフレームＣＲＣを行う前に、カットスルーデータパケットのパケット送信を開始することを可能にする。ＣＲＣは、代わりに、パケットの送信が発生している間に行われる。カットスルーデータパケットに、１つまたは複数のエラーが発見された場合には、そのようなエラーを示すパケットトレーラーが、カットスルーパケットを受信する終点ノードに向けて送信される。

Description

（関連する出願）
本出願は、２００９年１２月４日に出願された“信頼性のあるパケットカットスルーの方法およびシステム”と題された米国仮特許出願第６１／２６６，７４７号に関連し、その優先権を主張するものであり、先の出願の開示の全ては、参考のために本明細書に組み込まれる。

本発明は、概して、デジタル回路に関し、より具体的には、デジタル回路のエネルギー使用に関する。

モバイル産業プロセッサインターフェイスアライアンス[ＭＩＰＩ：Mobile Industry Processor Interface Alliance]において、いくつかの規格が定義されている。これら規格の１つは、ＵｎｉＰｒｏ（Unified Protocol）と呼ばれており、このＵｎｉＰｒｏは、高速シリアルリンク［UniPro1］を用いたチップ間ネットワークを対象としている。ＵｎｉＰｒｏは、エラー処理、フロー制御、ルーティングまたは仲裁などの、一般的な相互接続の問題を解決する汎用プロトコルとして定義されている。ＵｎｉＰｒｏは、新しいデバイスを容易に作製するために、場合によっては異なるベンダーからの、異なる機能を有するチップを混合および整合することによって、電話製造業者の柔軟性を高めることを意図している。

ＵｎｉＰｒｏは、リンクレベルで信頼性のある通信を提供するために、かなり複雑なエラー処理手順を有する。ＵｎｉＰｒｏエラー処理は、ＣＲＣコードに基づくエラー検出、ＮＡＣフレームを用いたエラー報告、およびエラーがあった場合のデータフレーム再送信に基づいている。シーケンス番号が、データフレームが順番に設定されていることを保証し、かつ、フレームの紛失や複製を防止する。ひとたびフレームが正しく受信されたことが報告されると、フレームを再送信バッファから取り除くことにより、トランスミッタ側で再送信バッファを管理することにおいても、シーケンス番号は重要である。

ＣＲＣベースのエラー検出に加えて、ＵｎｉＰｒｏは、また、タイマを用いて、エラーのまれなケース（corner case）に対処する。２つのタイマが用いられており、それぞれ、フレーム肯定応答および失われたフロー制御クレジットに対する保護に用いられる。

このエラー処理は、データフレームのＣＲＣが確認された後でのみ、データフレームが処理されることを必要とする。このＣＲＣの前処理は、パケットがレシーバアプリケーションにおいて配送された際に、必要条件となることがある一方で、介在ノードにおいて、例えば、ＵｎｉＰｒｏスイッチなどのＵｎｉＰｒｏネットワークノードにおいては非効率的であり、そのようなノードでは、データフレーム配送と関連するレイテンシを増加させる。

現在の処理は十分ではあるが、本発明者は、このような通信システムにおいて、より少ないレイテンシを有する方法およびノードを有すること、および、より信頼性のあるパケットカットスルー機構を提供することが望ましいことを見出した。

カットスルーデータパケット機構が説明される。中間ノードにより、カットスルーデータパケットを転送することで、パケットにフレームＣＲＣを行う前に、カットスルーデータパケットのパケット送信を開始することを可能にする。ＣＲＣは、代わりに、パケットの送信が発生している間に行われる。カットスルーデータパケットに、１つまたは複数のエラーが発見された場合には、そのようなエラーを示すパケットトレーラーが、カットスルーパケットを受信する終点ノードに向けて送信される。

１つの例示的な実施形態によると、終点ノードに向けてデータを送信する方法は、中間ノードにおいて、第１のデータフレームを受信するステップと、第１のデータフレーム内のフレームＣＲＣフィールドを用いて、第１の周期的冗長性検査（ＣＲＣ：cyclic redundancy check）を行う前に、中間ノードによって、第２のデータフレームにおいて終点ノードに向けた第１のデータフレームに含まれるデータパケットの再送信を開始するステップであって、フレームＣＲＣフィールドが、第１のデータフレームの少なくとも１つの非ＣＲＣフィールドに基づき計算されている、ステップと、中間ノードによって、かつ再送信を開始した後に、フレームＣＲＣフィールドを用いて、第１のデータフレームに対して第１のＣＲＣを行うステップと、第１のＣＲＣの結果として、中間ノードによって、第１のデータフレームが、１つまたは複数のエラーを含み破損していることを決定するステップと、第２のデータフレームと関連するフレームトレーラーを、中間ノードによって、終点ノードに向けて送信するステップであって、フレームトレーラーは、第２のデータフレームに含まれるデータパケットが破損していることを示す、ステップと、を含む。

もう１つの例示的な実施形態によると、スイッチングデバイスは、第１のデータフレームを受信するように構成された第１のインターフェイスと、第１のデータフレーム内のフレームＣＲＣフィールドを用いて、第１の周期的冗長性検査（ＣＲＣ）を行う前に、終点に向けた第２のデータフレームとしての第１のデータフレームに含まれるデータパケットの再送信を開始するものであって、フレームＣＲＣフィールドは、第１のデータフレームの少なくとも１つの非ＣＲＣフィールドに基づき計算されている、ように構成された第２のインターフェイスと、第１および第２のインターフェイスを制御するように構成されたインターフェイスコントローラと、再送信を開始した後に、フレームＣＲＣフィールドを用いて、第１のデータフレームに対して第１のＣＲＣを行い、かつ、第１のデータフレームに対するＣＲＣの結果として、第１のデータフレームが１つまたは複数のエラーを含み破損していることを決定するように構成されたプロセッサと、を含み、スイッチングデバイスは、第２のデータフレームに含まれたデータパケットが破損していることを示す第２のデータフレームと関連するフレームトレーラーを、第２のインターフェイスを介して送信するようにさらに構成されている。

もう１つの例示的な実施形態によると、レシーバは、カットスルーデータフレームを受信するように構成されたインターフェイスと、カットスルーデータフレームと関連する周期的冗長性検査（ＣＲＣ）フィールド以外のデータフィールドを評価し、カットスルーデータフレームが１つまたは複数のエラーを含み破損しているか否かを決定するように構成されたプロセッサと、を含む。

さらにもう１つの例示的な実施形態によると、データパケットを含み、かつ第１のフレームトレーラーを有するデータフレームを、フレームデータレシーバにおいて受信する方法は、フレームデータレシーバの第１のインターフェイスにおいて、データフレームを受信するステップと、フレームデータレシーバによって、データフレーム内のフレームＣＲＣフィールドを用いて、周期的冗長性検査（ＣＲＣ）を行うステップであって、フレームＣＲＣフィールドは、データフレームの少なくとも１つの非ＣＲＣフィールドに基づき計算されている、ステップと、第１のＣＲＣの結果として、フレームデータレシーバによって、データフレームが破損していないことを決定するステップと、データパケットが破損していることを、フレームトレーラーから決定し、かつ関連する動作を行うステップと、を含む。

添付の図面は、特に、本発明の例示的な実施形態を示している。

ＥＯＦベースのデータフレームを示す図。 長さベースのデータフレームを示す図。 ヘッダＣＲＣフィールドを有する、長さベースのデータフレームを示す図。 ＡＦＣ制御フレームを示す図。 ＮＡＣ制御フレームを示す図。 ＵｎｉＰｒｏエラー処理機構を例示するメッセージシーケンス図。 エラー検出用のレシーバシンボルパーサーを示す図。 エラー検出の後に呼び出される手順を示す図。 ＮＡＣフレームの開始を検出した際に呼び出される手順を示す図。 ＡＦＣフレームの開始を検出した際に呼び出される手順を示す図。 ＴＣ１でのデータフレームの開始を検出した際に呼び出される手順を示す図。 ＴＣ０でのデータフレームの開始を検出した際に呼び出される手順を示す図。 例示的な実施形態に係るＵｎｉＰｒｏパケットカットスルーの例を示す図。 例示的な実施形態に係るパケットトレーラーを含むパケットフォーマットを示す図。 例示的な実施形態に係るパケットトレーラーを含むパケットフォーマットを示す図。 例示的な実施形態に係るパケットカットスルーをサポートするＴＣ０ ＵｎｉＰｒｏレシーバの変更を示す図。 もう１つの例示的な実施形態に係るＴＣ０／ＴＣ１パケットカットスルーを示す図。 図１６の例示的な実施形態と関連する、対応するトランスミッタ状態機械およびレシーバ状態機械を示す図。 図１６の例示的な実施形態と関連する、対応するトランスミッタ状態機械およびレシーバ状態機械を示す図。 図１６の例示的な実施形態と関連する、対応するトランスミッタ状態機械およびレシーバ状態機械を示す図。 例示的な実施形態に係る中間ノードから終点に向けてデータを送信する方法を示すフローチャート。 例示的な実施形態に係るノード、例えば中間ノードまたは終点ノードを示す図。 例示的な実施形態に係るデータフレームを受信する方法を示すフローチャート。

（略語および頭字語の一覧）
ＡＣＫ Acknowledge Message（肯定応答メッセージ）
ＡＦＣ Acknowledgement and Flow Control（肯定応答およびフロー制御）
ＣＯＦ Continuation Of Frame（フレームの継続）
ＣＲＣ Cyclic Redundancy Check（周期的冗長性検査）
ＣＲＣＦ Cyclic Redundancy Check Frame（周期的冗長性検査フレーム）
ＣＲＣＨ Cyclic Redundancy Check Header（周期的冗長性検査ヘッダ）
ＣＴＲＬ＿ＩＤ Control Identifier（制御識別子）
ＤＬ＿ＭＴＵ Data Link Maximum Transmission Unit（データリンク最大送信単位、すなわちフレームの最大ペイロード）
ＥＯＦ End Of Frame（フレーム終了）
ＥＯＦ＿ＥＲＲ End Of Frame Error（フレーム終了エラー）
ＥＯＦ＿ＰＡＤ End Of Frame（パディングバイトを有するフレーム終了）
ＥｏＭ End of Message（メッセージ終了）
ＥＳＣ＿ＤＬ ESCape character for Data Link Layer（データリンク層用のエスケープキャラクタ）
ＦＣＴ Flow Control token（フロー制御トークン）
Ｌ３ｓ Layer 3 Short header（レイヤ３ショートヘッダ）
Ｌ４ｓ Layer 4 Short header（レイヤ４ショートヘッダ）
ＭＩＰＩ Mobile Industry Processor Interface（モバイル産業プロセッサインターフェイス）
ＮＡＣ Negative Acknowledgement Control（否定応答制御）
ＮＡＣＣｒｃ Negative Acknowledgement Control Cyclic Redundancy Check（否定応答制御周期的冗長性検査）
ＮＡＣＧｅｎ Negative Acknowledgement Control Generation（否定応答制御生成）
ＰＡｅｒｒ (P)HY Adapter (err)or（ＰＨＹアダプタエラー）
ＰＥＲＲ Packet ERRor（パケットエラー）
ＲＲＲ Remote Reset Request（遠隔リセット要求、ＲＲｅｑ（Reset (Req)est）とも呼ばれる）
Ｒｘ Receiver（レシーバ）
ＳＤＬ Specification Description Language（仕様記述言語）
ＳＯＦ Start Of Frame（フレーム開始）
ＴＣ Traffic Class（トラフィッククラス）
ＴＣ０＿ｃｒｃ Traffic Class 0 CRC（トラフィッククラス０ ＣＲＣ）
ＵｎｉＰｒｏ Unified Protocol（統一プロトコル）

以下の例示的な実施形態の詳細な説明は、添付の図面を参照する。異なる図面における同一の参照番号は、同一または類似の要素を識別する。また、以下の詳細な説明は、本発明を限定しない。代わりに、本発明の範囲は、添付の特許請求の範囲によって定義される。

例示的な実施形態によると、データフレームまたはパケットは、レイテンシを改善するために、“カットスルー”することができる。ここで、パケット“カットスルー”は、例えば、パケット送信者とパケット受信者との間の介在ＵｎｉＰｒｏノードにおいて、ＣＲＣ検査が行われる前に、到来パケット（incoming packet）をさらに送信できることを意味する。本発明において、我々は、ＵｎｉＰｒｏネットワークにおいてパケットカットスルーを行う方法を提示する。中でも、例示的な実施形態は、パケットカットスルーをエラー処理と組み合わせることを提供し、これにより、カットスルーパケットの送信に関して検出されたエラーがネットワーク内で伝播され、エラーのあるパケットが止められることを保証する。例示的な実施形態は、エラーのあるパケットが配送されることを防止し、かつ、順番通りのデータ送信を保証する。例示的な実施形態の考察についてのいくつかの状況を提供するために、ＵｎｉＰｒｏプロトコルおよびこれらの例示的な実施形態を用いることができるシステムに関して、いくつかの情報が最初に提供される。しかし、本発明は、ＵｎｉＰｒｏ標準化システムでの使用に限定されないことを理解されたい。

ＵｎｉＰｒｏプロトコルは、そのリンクレベル通信のためのデータおよび制御フレームを定義する。データフレームは、アプリケーションからのデータをカプセル化し、一方で、制御フレームは、ＵｎｉＰｒｏのデータリンクレイヤプロトコルによって、その内部機構のために使用される。ＵｎｉＰｒｏプロトコル規格（１．００．００）は、図１に示すようなデータフレームを定義する。ここで、ＵｎｉＰｒｏデータフレームの１つ目のシンボルと最後の２つのシンボルは、それぞれフレームヘッダとトレーラーである。ヘッダは、制御シンボル（１の値を有する１６番目のビットによって識別される）からなり、制御シンボルは、以下のフィールドを有する。
・エスケープバイト（ＥＳＣ＿ＤＬ）：符号化されたＰｈｙにおいて、エスケープシンボルに変換されるものであり、かつ、制御シンボルを示す。
・シンボル制御ｉｄフィールドＣＴＲＬ＿ＩＤ：データフレームヘッダの場合に、０の値を有し、図１ではＳＯＦ（Start Of Frame）で示される。
・トラフィッククラスＴＣｘ：ＵｎｉＰｒｏ１．０は、トラフィッククラスＴＣｘに対して、値０および１を許可する。
・３つの予約ビット。

トレーラーは、２つのシンボル：ＥＯＦ制御シンボル（１６番目のビットが１）、およびエラー検出用のＣＲＣデータシンボル（１６番目のビットが０）、からなる。ＥＯＦ制御シンボルは、以下のものからなる。
・エスケープバイト（ＥＳＣ＿ＤＬ）：ヘッダ内のＳＯＦ制御シンボルに関する。
・シンボル制御ｉｄフィールド：データフレームトレーラーの場合に、偶数のバイトを有するペイロードに対して、ＥＯＦ（End Of Frame）によって示される１の値か、または、奇数のバイトを有するペイロードに対して、ＥＯＦ＿ＰＡＤ（パディングバイトを有するEnd Of Frame）によって示される２の値かを有する。
・フレームシーケンス番号

ＵｎｉＰｒｏバージョン１．５において、フレーム長（ＥＯＦ／ＥＯＦ＿ＰＡＤ制御シンボルの代わりに）フィールドを用いて、フレームの終わる箇所を識別するように、データフレームフォーマットが変わる可能性があり、この例が、図２に示されている。図１のＥＯＦベースのデータフレームと比べて、データシンボルは、ＳＯＦ制御シンボルの直後のフレームヘッダに挿入されている。この新しいデータシンボルは、フレーム長と、フレームシーケンス番号とを含む。ＥＯＦ制御シンボルは、もはや存在しない。残りのデータフレーム構造に変更はない。

この新しいフレームフォーマットは、任意の１６ビットヘッダＣＲＣの導入を可能とするために導入され、このヘッダＣＲＣは、リアルタイムトラフィッククラス（ＵｎｉＰｒｏ２．０仕様の一部であると予想されるもの）によって必要とされ、この例が、図３に示される。ヘッダＣＲＣの存在は、１つ目のヘッダシンボル内のｈＣＲＣビットによって示される。ヘッダＣＲＣは、また、Ｌ３ヘッダ（図３に３番目のワードのビット８：１６として示される）と、Ｌ４ヘッダ（図３に３番目のワードのビット０：７として示される）とを保護する。ヘッダＣＲＣの位置は、Ｌ３およびＬ４ヘッダにおけるビット（すなわち、Ｌ３ｓ，Ｌ４ｓと、長いヘッダにのみ使用され、ここでは図示されない拡張子を示すビットと）を用いて、実行中に（動的に変化する状態で）（on the fly）計算される。フレーム内の２つのＣＲＣを区別するために、“ヘッダＣＲＣ”を用いて、ヘッダを保護するＣＲＣが示され、かつ、“フレームＣＲＣ”を用いて、フレーム全体を保護するＣＲＣが示される。

ＵｎｉＰｒｏ１．００．００プロトコルは、２つの制御フレーム：図４に示されるＡＦＣ（Acknowledgement and Flow Control）制御フレーム、および、図５に示されるＮＡＣ（Negative Acknowledgement）制御フレーム、を有する。ＡＦＣ制御フレームは、３つのシンボル：ＡＦＣ制御シンボル（１６番目のビットは１）、および、２つのデータシンボル、からなる。ＡＦＣ制御シンボルは、以下のものからなる。
・エスケープバイト（ＥＳＣ＿ＤＬ）：ヘッダ内のＳＯＦ制御シンボルに関する。
・シンボル制御ｉｄフィールド：データフレームトレーラーの場合に、ＡＦＣ（Acknowledgement and Flow Control）によって示される６の値か、ＵｎｉＰｒｏ１．０が値０および１を可能にする、トラフィッククラスＴＣｘかを有する。
・トラフィッククラスＴＣｘ：ＵｎｉＰｒｏ１．０は、トラフィッククラスＴＣｘに対して、値０および１を許可する。
・Ｒｅｑビット：ピア側に、このトラフィッククラスでのＡＦＣ制御フレームを送ることを要求するために用いられる。
・２つの予約ビット。
図５に示されるＮＡＣ制御フレームは、２つのシンボル：ＮＡＣ制御シンボル（１６番目のビットは１）、および、１つのデータシンボル、エラー検出に用いられるＣＲＣ、からなる。ＮＡＣ制御シンボルは、以下のものからなる。
・エスケープバイト（ＥＳＣ＿ＤＬ）：ヘッダ内のＳＯＦ制御シンボルに関する。
・シンボル制御ｉｄフィールド：データフレームトレーラーの場合に、ＮＡＣ（Negative Acknowledgement）によって示される５の値のいずれかを有する。
・４つの予約ビット。
・ＲＲＲビット：ピア側に、リンクの再同期を要求するために用いられる。
ＮＡＣ制御フレームにおける第２のデータシンボルは、エラー検出に用いられるＣＲＣである。

ＵｎｉＰｒｏリンクレベルエラー処理スキームは、エラー検出およびデータフレーム再送信に基づいており、かつ、２つの安全策からなる。第１の安全策は、高速であり、かつ、典型的なエラーを処理する。第２の安全策は、より遅く、かつ、まれなケースを処理する。ＵｎｉＰｒｏシステムは、ＣＲＣ（Cyclic Redundancy Check）エラー検出コードを、送信された各フレームに追加する。レシーバは、ＣＲＣを再計算し、かつ、再計算したＣＲＣを、フレームの終わりに受信されたＣＲＣに対して確認する。受信されたフレームが正しい場合には、レシーバは、このフレームを受信バッファに引き渡し、かつ、トランスミッタに対してフレームの肯定応答を行う（データフレームに関する）か、または、フレームを処理する（制御フレームに関する）。レシーバがエラーを検出した場合には、レシーバは、ＮＡＣフレームを用いて、トランスミッタにエラーを報告する。

全ての送信されるデータフレームには、シーケンス番号が割り当てられており、この番号も、データフレームにおいて送信され、かつ、レシーバによって肯定応答に用いられる。ＵｎｉＰｒｏシーケンス番号は、５ビットを有する。リセット値は０であり、かつ、第１のデータフレーム送信に用いられる。シーケンス番号は、送受信されるフレームごとに増加され、かつ、３１の周囲に配置される。ＵｎｉＰｒｏでは、最大で１６フレームを、肯定応答を受信することなく送信することができる。フレーム肯定応答は、ＡＣＫ制御フレームを用いて行われる。フレームを肯定応答する場合には、ＡＦＣフレーム内のシーケンス番号は、シーケンス番号によって識別されるデータフレームまで、このデータフレームも含めて全ての肯定応答されていないデータフレームを肯定応答する。

トランスミッタは、再送信バッファ内の全ての送信されたデータフレームを、肯定応答されるまで保存する。ＮＡＣ制御フレームが受信された（エラーを報告している）場合には、再送信バッファ内の全てのデータフレームは、最も古い肯定応答されていないフレームから開始して、再送信される。

第２の安全策は、ＡＦＣまたはＮＡＣフレームの１つまたは複数が失われた場合に用いられる。そのような場合には、ＡＦＣフレーム内に含まれる肯定応答および／またはリンクレベルのフロー制御クレジットが失われているか、または、ＮＡＣフレームに含まれているエラー指示（error indication）が失われている。このような（まれな）エラーから保護するために、各トラフィッククラスに対して、２つのタイマ：再生タイマと呼ばれるデータ用のタイマ、および、クレジットタイマと呼ばれるクレジット用のタイマ、が用いられる。再生タイマが切れると、このトラフィッククラスの全ての肯定応答されていないフレームが再送信される。クレジットタイマが切れると、Ｒｅｑビットセットを有するＡＦＣフレームが、このトラフィッククラスのために送信される。両方の場合で、ＵｎｉＰｒｏ１．００．００は、リンクの再同期を要求し、その後、ＲＲＲビットを有するＮＡＣフレームが送信され、到来するリンクの再同期を要求する。

ＣＲＣエラーに加えて、第１の安全策の一部として、レシーバは、以下の多くの他のエラーを検出する。
・レシーババッファオーバーフロー（例えば、ＴＣｘフィールドでのビット送信エラーによる）
・最大フレームサイズＤＬ＿ＭＴＵよりも大きい、到来するデータフレーム長（例えば、ＥＯＦ制御シンボルを、有効なデータシンボルに変更する送信エラーによる）
・データフレーム内の誤ったシーケンス番号
・後に２つのデータシンボルが続かないＡＦＣフレーム
・後に１つのデータシンボルが続かないＮＡＣフレーム
・後に１つのデータシンボルが続かないＥＯＦ／ＥＯＦ＿ＰＡＤ
・データフレームが開始されていない場合の、ＣＯＦ、ＥＯＦまたはＥＯＦ＿ＰＡＤ制御シンボルの受信
・同じトラフィッククラスのデータフレームが、既に進行中であり、かつ、データフレームが、現在、先取されていない場合の、ＳＯＦシンボルの受信（ＡＦＣおよび／またはＮＡＣによる先取の間、ＳＯＦ受信は、再送信の開始を示すことがあり、よって、エラーとみなされない）
・ＴＣ１データフレームが既に進行中の場合の、ＴＣ０に関するＳＯＦシンボルの受信（ＴＣ０は、ＴＣ１を先取できない）
・同じトラフィッククラスのデータフレームの間の、このデータフレームが先取されていない場合の、ＣＯＦシンボルの受信
・異なるＴＣのデータフレームを継続するＣＯＦシンボルの受信
・データフレームが先取されておらず、かつ、先取しているフレームが終了した場合の、ＥＯＦ、ＥＯＦ＿ＰＡＤまたはデータシンボルの受信（先取されたフレーム、ＣＯＦシンボルに関しては、ＥＯＦでないものが後に続くべきである）
・定義済みフィールドに関する無効な値、例えば未定義のＣＴＲＬ＿ＩＤまたはＴＣ、を有する制御シンボルの受信
・Ｐｈｙ Ａｄａｐｔｅｒからのエラー指示の受信
Ｐｈｙ Ａｄａｐｔｅｒは、以下の場合でのエラーを示す。
・悪いＰｈｙシンボルが受信された場合
・正しい例外Ｐｈｙシンボルが受信されたが、この例外Ｐｈｙシンボルが、有効なＵｎｉＰｒｏシンボルにマッピングされていない場合
・データＰｈｙシンボルが予想される場合に、他の例外Ｐｈｙシンボルの直後に、正しい例外Ｐｈｙシンボルが受信された場合
・ＥＳＣ＿ＰＡの後に、有効なデータＰｈｙシンボルの誤った値が受信される場合
上記のエラーのいずれかが検出されると、ＮＡＣ制御フレームが送信され、場合によっては、その前に、不要な再送信を避けるための一対のＡＦＣ制御フレームが先行する。

図６において、メッセージシーケンス図が示され、ＵｎｉＰｒｏエラー処理機構の第１および第２の安全策を例示している。簡略化のために、単一のトラフィッククラスが仮定されている。ここで、データフレーム＃１および＃２を正しく受信した後に、ノードＢは、これらフレームの正しさを、最後に正しく受信されたフレームのシーケンス番号、この場合は＃２、を保持するＡＦＣフレームを、ノードＡに送ることによって、報告する。ノードＡは、ＡＦＣフレームを受信すると、フレーム＃２までの全てのフレームを、再送信バッファから取り除く。ノードＡは、フレーム＃３および＃４を送り続けるが、しかしフレーム＃３のみが正しく受信され、フレーム＃４の送信中にエラーが起こる。このエラーは、ノードＢで検出されるものであり、ノードＢは、最初にＡＦＣをノードＡに送り、フレーム＃３の正しい受信を肯定応答し、その後にエラーを報告するＮＡＣフレームが続く。ＮＡＣを受信する際に、ノードＡは、最も古いフレーム、この例ではフレーム＃４、から開始して、全ての肯定応答されていないフレームを再送信する（第１の安全策）。

ノードＡは、再送信されたフレーム４の次に、フレーム５を続ける。フレーム＃４は正しく受信されるが、ノードＢによって、フレーム５にエラーが検出される。その結果、前の場合と同様に、ＡＦＣフレームを送って、フレーム４の正しい受信を報告し、かつ、ＮＡＣフレームを送って、エラーを報告する。不都合なことに、ＮＡＣフレームも、送信エラーに遭遇する。ノードＡは、このエラーをＮＡＣにより報告するが、しかしフレーム＃５を再送信すべきか否かが分からない。最終的に、ノードＡの再生タイマが切れ、かつ、ノードＡがフレーム＃５を再送信する（第２の安全策）。

図７は、ＳＤＬフローチャートを用いて、ＵｎｉＰｒｏエラー検出機構の可能な部分的実施を例示している。ここで、レシーバに見出されるシンボルパーサーの最上位図が説明されている。シンボルパーサーは、３つの変数：ＴＣ０およびＴＣ１のそれぞれで進行中のデータフレームがあるか否かを示す、ｔｃ０およびｔｃ１、ならびに、ＮＡＣ生成が有効化されている（真）か否（偽）かを示すＮＡＣＧｅｎＯｋ、を維持する。最初は進行中のデータフレームはないので、ｔｃ０およびｔｃ１は、両方とも偽（false）に設定されている。ＮＡＣによりエラーが報告された後に、良いＣＲＣを有するフレームが受信されるまで、ＮＡＣ生成は一時的に無効化される。最初は検出されるエラーはないので、ＮＡＣＧｅｎＯｋは、真（true）に設定される。

最初は、レシーバシンボルパーサーは、どのフレームも開始しておらず、ＮｏＦｒａｍｅ状態で待機する。フレーム開始のシンボル（ＮＡＣ、ＡＦＣ、０または１のＴＣを有するＳＯＦ）が受信されると、対応する手順が呼び出され、フレーム全体（それぞれ、ＮＡＣ、ＡＦＣ、ＴＣ１およびＴＣ０）を受信する。他の何らかのシンボル（データ、ＣＯＦ、ＥＯＦまたはＥＯＦ＿ＰＡＤ、簡略化のために不図示）が受信された場合には、パラメータｆａｌｓｅによりＥｒｒｏｒ手順が呼び出される。どの状態でも、Ｐｈｙ Ａｄａｐｔｅｒからエラー指示が受信された場合には、パラメータｆａｌｓｅによりＥｒｒｏｒが呼び出される。

図８には、Ｅｒｒｏｒ手順が示されており、この手順は、ＲＲＲと呼ばれるパラメータを取る。ＮＡＣ生成が有効化されている場合には、ＮＡＣフレームがトリガされ、ＮＡＣ生成が無効化される。このＮＡＣフレームは、手順パラメータとして受信されたＲＲＲ値に設定されたＲＲＲビットを有する。エラーが検出された後は、パーサープロセスは、常に状態ＮｏＦｒａｍｅに戻る。

図９には、ＮＡＣフレームを受信する手順が示されている。ＮＡＣシンボルを受信した後に、ＮＡＣ手順が呼び出されるが、このＮＡＣ手順は、データシンボル（ＣＲＣ）が受信されるまで、状態ＮＡＣで待機する。もう１つのシンボルが受信された場合には、このシンボルは、Ｅｒｒｏｒを呼び出す際に報告されるエラーである。データシンボルが受信された場合には、このデータシンボルは、ＮＡＣフレームのＣＲＣのはずであり、かつ、レシーバで計算されたＣＲＣに対して確認される（簡略化のために、これらの図面ではＣＲＣ計算は図示せず）。ＣＲＣが正しくない場合には、Ｅｒｒｏｒが呼び出される。ＣＲＣが正しい場合には、ＮＡＣＣｒｃＯｋによりＮＡＣフレームが引き渡されるが、ここで、ＮＡＣ受信に続く動作が行われる。この後に、ＮＡＣＧｅｎＯｋが真に設定される（良いフレームを受信した後に、ＮＡＣ生成が有効化される）。ｔｃ１が真である場合には、ＴＣ１が先取されており、かつ、継続されるべきである。したがって、シンボルパーサープロセスは、状態ＴＣ１＿ＣｏＦに移行する。そうではなく、ｔｃ０が真である場合には、パーサープロセスは、状態ＴＣ０＿ＣｏＦに移行する。ｔｃ１とｔｃ０のいずれも真でない場合には、パーサープロセスは、状態ＮｏＦｒａｍｅに戻る。

図１０には、ＡＦＣフレームを受信する手順が示されている。ＡＦＣシンボルを受信した後に、ＡＦＣ手順が呼び出されるが、このＡＦＣ手順は、ＡＦＣフレームの第２のデータシンボルが受信されるまで、状態ＡＦＣで待機する。もう１つのシンボルが受信された場合には、このシンボルは、Ｅｒｒｏｒを呼び出す際に報告されるエラーである。次いで、ＡＦＣ手順は、第２のデータシンボル（ＣＲＣ）が受信されるまで、ＡＦＣ＿ｃｒｃ状態で待機する。再び、他の何らかのシンボルが受信された場合には、このシンボルは、エラーであり、このエラーは、Ｅｒｒｏｒにより報告される。第２のデータシンボルが受信された場合には、このデータシンボルは、ＡＦＣフレームのＣＲＣのはずであり、このＣＲＣは、レシーバで計算されたＣＲＣに対して確認される（簡略化のために、これらの図面ではＣＲＣ計算は示さず）。ＣＲＣが正しくない場合には、Ｅｒｒｏｒが呼び出される。ＣＲＣが正しい場合には、ＡＦＣＣｒｃＯｋによりＡＦＣフレームが引き渡され、ここで、ＡＦＣ受信に続く動作が行われる。この後に、ＮＡＣＧｅｎＯｋが真に設定される（良いフレームを受信した後に、ＮＡＣ生成が有効化される）。ｔｃ１が真である場合には、ＴＣ１が先取されており、かつ、継続されるべきである。したがって、シンボルパーサープロセスは、状態ＴＣ１＿ＣｏＦに移行する。そうではなく、ｔｃ０が真である場合には、パーサープロセスは、状態ＴＣ０＿ＣｏＦに移行する。ｔｃ１とｔｃ０のいずれも真でない場合には、パーサープロセスは、状態ＮｏＦｒａｍｅに戻る。

図１１には、ＴＣ１においてデータフレームを受信する手順が示されている。パーサーが、トラフィッククラスフィールドが１に設定されたＳＯＦシンボルを受信した後に、ＴＣ１手順が呼び出されるが、このＴＣ１手順は、ｔｃ１を真に設定してＴＣ１フレームが開始したことを示し、次いで、データシンボルを受信している限り、状態ＴＣ１＿ｄａｔａで待機する。データが受信されている間に、２つのエラー：バッファオーバーフローおよびＤＬ＿ＭＴＵを超えたフレーム、が生じることがあるが、これらのエラーは、図面では示されていない。両方の場合において、エラーは、Ｅｒｒｏｒによって報告される。状態ＴＣ１＿ｄａｔａから、フレームは、ＥＯＦシンボルまたはＥＯＦ＿ＰＡＤシンボル（簡略化のためにＥＯＦ＿ＰＡＤは図示せず）で終わることがある。ＥＯＦ／ＥＯＦ＿ＰＡＤシンボルの後は、データが予想される（ＣＲＣ）。他の何らかのシンボルが受信された場合には、これは、Ｅｒｒｏｒによって報告されるエラーである。ＣＲＣが受信された場合には、フレームは終了する（ｔｃ１が偽となる）。フレームは、そのＣＲＣが正しい場合には、引き渡されるが、正しくない場合には、Ｅｒｒｏｒが呼び出される。この後、ＮＡＣＧｅｎＯｋが真に設定される（良いフレームを受信した後に、ＮＡＣ生成が有効化される）。ｔｃ０を用いてＴＣ０データフレーム先取がチェックされ、真である場合には、状態ＴＣ１＿ＣｏＦで、ＴＣ０データフレーム受信が継続される。真でない場合には、パーサープロセスは状態ＮｏＦｒａｍｅに戻る。

ＴＣ１＿ｄａｔａにおいて、先取が発生した場合（ＮＡＣまたはＡＦＣシンボルが受信される場合）には、このフレーム（それぞれ、ＮＡＣまたはＡＦＣ）を受信するための手順が呼び出される。他の何らかのシンボルが、ＴＣ１＿ｄａｔａ状態で受信され（すなわち、ＳＯＦまたはＣＯＦ）、Ｅｒｒｏｒによってエラーが報告される。ＴＣ１データフレームが先取され、先取されたフレームが終了した場合には、パーサーは、状態ＴＣ１＿ＣｏＦに戻る。この状態で、（１）ＴＣフィールドが１に設定されたＣＯＦを受信する際に、ＴＣ１データフレームを継続することができ、その後、パーサーは、状態ＴＣ１＿ｄａｔａを継続する、または、（２）ＮＡＣ、ＡＦＣによる他の先取が開始する場合がある、または（３）可能な再送信を示す、ＴＣフィールドが１に設定されたＳＯＦシンボルが受信される場合がある。その他のシンボルはエラーであり、Ｅｒｒｏｒを用いて報告される。

図１２には、ＴＣ０においてデータフレームを受信する手順が示されている。これは、ＴＣ１の場合と類似している。２つの違いがある。１つ目は、ＴＣ０フレームが、ＴＣ１フレームで先取される可能性があることであり、これは、ＴＣフィールドが１に設定されたＳＯＦシンボルが、ペイロード（ＴＣ０＿ｄａｔａ状態）の間または先取（ＴＣ０＿ＣｏＦ状態）の間に受信させることで示されている。２つ目は、ＴＣ０フレームが終了した際に、他に継続され得るフレームがないため、パーサーは常に状態ＮｏＦｒａｍｅに戻ることである（ＴＣ１の場合では、ＴＣ０が先取されることがあるので、状態ＴＣ０＿ＣｏＦでＴＣ０を継続する必要があるか否かを決定するためのチェックが必要であり、または進行中のフレームがなく、この場合はパーサーが状態ＮｏＦｒａｍｅに戻る）。

例示的な実施形態によると、例えば、ＣＲＣチェックが行われる前にパケットが送信される中間ノードにおいて、パケットカットスループロセスを行ってもよい。図１３は、リンク１でパケットを送るノードＡと、リンク１で送られたパケットを受信し、パケットをリンク２でカットスルーするノードＢと、パケットを受信するノードＣとを示している。よって、この例では、ノードＢは、中間ノード、例えばスイッチングデバイスとみなすことができ、一方で、ノードＣは、終点ノード、例えば、フレームデータレシーバとみなすことができる。パケットは、任意でヘッダＣＲＣ（crch）によって保護することができるヘッダと、ペイロードのいくつかのシンボルと、フレームＣＲＣ（crcf）を含むトレーラーと、を有して示されている。

フレームは、例示的な実施形態によると、Ｌ３ ＤｅｖｉｃｅＩＤ（アドレス）が受信された直後にのみ、カットスルーすることができる。ヘッダがヘッダＣＲＣによって保護されている場合には、例えばフレームヘッダ内の少なくとも１つの非ＣＲＣフィールド（および場合によっては、フレームヘッダ内の非ＣＲＣフィールドの全て）に基づいて、ＣＲＣを計算することにより、ヘッダＣＲＣが確認された後でのみカットスルーを開始することがベターであり、これにより、Ｌ２〜Ｌ４ヘッダが正しいことを保証する。ヘッダＣＲＣが破損している場合には、フレームは破棄され、かつ、エラーが報告される。図１３の例では、第１のフレーム（リンク１のシーケンス番号＃５を有する）は、ノードＢでヘッダＣＲＣが正しいことが証明されており、リンク１での正しい送信を示している。その結果、フレームは、リンク２でノードＣにカットスルーされる（リンク２のシーケンス番号＃９を有する）。ヘッダＣＲＣがなかった場合には、フレームは、Ｌ３ ＤｅｖｉｃｅＩＤが受信された際に、カットスルーされていた可能性がある。Ｌ３ ＤｅｖｉｃｅＩＤ受信は、ノードＢでトランスミッタポートを選択する必要がある。

この例では、フレーム＃５は、そのリンク１でのペイロード送信の間に、エラーに遭遇する。しかし、エラーは、フレームＣＲＣがチェックされる際にのみ検出されるが、これは、フレームがカットスルーされることを防ぐには遅すぎる。その結果、例えば、フレーム内の少なくとも１つの非ＣＲＣフィールドと、場合によってはフレーム内の全ての非ＣＲＣフィールドとに基づきＣＲＣを計算することにより、フレームＣＲＣがチェックされ、エラーが発見された後に、カットスルーフレーム（リンク２のフレーム＃９）に、ペイロードにエラーが存在することを示すトレーラーが付加される。ペイロードエラーを示すことができる１つのやり方は、フレームトレーラーに特殊レイヤ２シンボルを追加することである（例えば、長さベースのフレームを示す図１４ＡおよびＥＯＦフレームを示す図１４Ｂを参照されたい）。この文脈での「特殊」とは、レイヤ２シンボルが、適切に適合されたレシーバまたは中間ノードによって、ペイロードエラーがあるか否かを示していると解釈されるべきものである、ことを意味する。ペイロードエラーは、フレームトレーラーにフラグを設定することによって示すことができる。これは、中間ノードにおいて追加されたであろう新しいフレームトレーラー内か、または既存のフレームトレーラー、すなわち中間ノードに到着するフレームのフレームトレーラー内である可能性がある。当業者には、ペイロードエラーの有無の区別は、ペイロードエラーがある場合は設定されたフラグを有すること、およびペイロードエラーがない場合はクリアされたフラグを有すること、または逆に、ペイロードエラーがない場合は設定されたフラグを有すること、およびペイロードエラーがある場合はクリアされたフラグを有すること、のいずれかによって行えることが明らかである。ペイロードエラーが、特殊レイヤ２シンボルにより示されようと、フラグにより示されようと、トランスミッタによって正しいフレームＣＲＣが付加される。両方の選択肢により、フレームのレシーバは、フレームを同じ様に処理する。フレームに信頼性がある場合には、フレームは破棄される。任意で、ＮＡＣフレームを用いて、トランスミッタに対してエラーが示される。フレームがリアルタイムの場合には、フレームは破棄され、その再生フラグにより示されるように、リアルタイムフレームを再送信できる場合にのみ、エラー報告が返される。そうでない場合（再送信が許可されていない場合）には、リアルタイムフレームが受け付けられ、さらに送信されるが、しかし、エラーのあるペイロードを保持しているとマークされる。

ペイロードエラーを示す代わりのやり方は、トランスミッタで、フレームＣＲＣを悪化させる（すなわち、エラーのあるＣＲＣを挿入する）ことである。しかし、この場合には、現在のリンクで生じるエラーと前のリンクで生じるエラーとを、区別することができない。その結果、この方法を用いたプロトコルは、これらのエラーを処理する際に、方法が有する選択肢の選択が制限されるであろう。

ＮＡＣフレームは、シーケンス番号を保持して示されている。これは、プロトコルでは原理的に可能であるが、ＵｎｉＰｒｏでは許可されていない。ＵｎｉＰｒｏでのシーケンス番号の欠如を補償するために、ＮＡＣフレームにＡＦＣフレームを先行させて、最後に正しく受信されたフレームのシーケンス番号を保持させることができる。フレームが、ヘッダＣＲＣによって保護されている場合には、フレームトラフィッククラスは、正しいことが知られている。その結果、エラーを報告するＮＡＣフレームにフラグを立て、エラーが生じたトラフィッククラスを示してもよい。このやり方では、トランスミッタはより選択的とすることができ、影響されるトラフィッククラスに対してのみ、再送信動作を行う。

ＮＡＣがリンク１で受信された後に、フレーム４（正しく受信されたことがＮＡＣにより報告されている）は、ノードＡの再送信バッファから除去され、フレーム５が再送信される。リンク２において、ＮＡＣフレームは、フレーム８が正しく受信されたことを報告しており、その結果、フレーム８は、フレームＢの再送信バッファから除去されている。しかし、元のカットスルーは、再送信することができず、それは、破損しているとフラグが立てられ、かつ、ノードＢの再送信バッファに保存されなかったからである（フレームＣＲＣによって正しいと証明された場合にのみ、フレームは再送信バッファに引き渡される）。他のリンクから、他のフレームが利用可能な場合もあり、かつ、それらのフレームを送信することができる（例えば、図１３の第２のフレーム＃９）再送信フレーム（例えば、信頼性のあるフレーム）の場合には、結局は、元のカットスルーフレームが来て、フレーム１０として再送信される。

図１３では、フレーム９エラーの検出に応じて送られたＮＡＣフレームが、リアルタイムデータフレームのために必要である。ＥＯＦ＿ＥＲＲトレーラーにより、破損しているとラベル付けされた信頼性のあるデータフレーム（あるいはＰＥＲＲトレーラーとも呼ばれる）の場合には、ＮＡＣフレームの送信はスキップすることができる。代替の実施形態では、ノードＢは、ＥＯＦ＿ＥＲＲ表示を受信すると、再送信バッファからフレーム９を直接除去し、かつ、フレームシーケンス番号およびクレジットを自動的にロールバックすることができる。

図１３ならびに図１４Ａおよび（ｂ）の例示的な実施形態に係る上述のパケットカットスルー技術を実施するために、例えば、ＵｎｉＰｒｏノードに対するいくつかの変更を行うことができる。例えば、ＵｎｉＰｒｏ Ｌ２レシーバパーサーは、正しいフレームＣＲＣを有するフレーム内の破損したペイロードを示す追加のシンボルを処理できることが必要である。図１５では、ＥｏＦベースのフレームを用いたレシーバの例が示されている。このような場合には、Ｒｘは、ＥＯＦ Ｌ２シンボルの代わりに来るＥＯＦ＿ＥＲＲ Ｌ２シンボルも受信可能でなければならない。ＥＯＦ＿ＥＲＲシンボルが受信された場合には、ＥＯＦ＿ＥＲＲ変数が真に設定されるので、状態ＴＣＯ＿ｃｒｃにおいて、フレームＣＲＣが正しいと証明された場合には、通常のエラー手順が行われる（有効化されていればＮＡＣ生成）が、これは、ＮＡＣＧｅｎＯｋを真に設定せずに行われる。Ｒｘの他の部分（例えばＴＣ１、ＡＦＣ等）またはフレームフォーマットの変更されたバージョン用のＲｘについては、変更点は同様である。

カットスルーパッケージを扱う必要がないＵｎｉＰｒｏ Ｌ２レシーバは、フレームＣＲＣが、フレームが正しいと証明するまで、Ｒｘバッファに到来データを保存する。フレームは、フレームが正しいと証明された後にのみ、レイヤ３に対して利用可能となる。しかし、カットスルーの場合では、フレームは、ＣＲＣチェックの前に、レイヤ３に対して利用可能となる必要がある。自然時間が、レイヤ２ヘッダが受信された直後に、レイヤ３にフレームの供給を開始することとなるが、他の代替案も可能である。この例示的な実施形態に係るＵｎｉＰｒｏレイヤ２も、フレームペイロードが破損している（そのようにラベル付けされているため、またはフレームＣＲＣが誤っているためのいずれかで）ことを示すレイヤ３への表示を提供する。パケットがレイヤ３で経路指定されると、この表示は、トランスミッタポートで、レイヤ２に供給される。ＵｎｉＰｒｏレイヤ２トランスミッタは、外部に向かうデータフレームに、誤りのあるペイロードを有するとラベル付けする（例えば、ＥＯＦ＿ＥＲＲシンボルを付加することによって）。再送信することができる、信頼性のあるフレームおよびリアルタイムフレームに対して、ペイロードが破損している場合には、フレームは再送信バッファから除去される。この結果、再送信されたフレームのシーケンス番号が１ロールバックされる。信頼性のあるフレームでは、フロー制御クレジットを使用した利用可能なレイヤ２が、カットスルーフレームを送信する際に消費されたクレジットの分だけロールバックされる。再送信することができる、信頼性のあるフレームおよびリアルタイムのフレームでは、レシーバは、また、ＥＯＦ＿ＥＲＲとマークされたフレームを、そのＲｘバッファから除去する。この結果、予想されるシーケンス番号も進まない（正しいフレームの場合と同様）。

例示的な実施形態によると、方法、デバイスおよびシステムは、ネットワーク内で早く、すなわちフレームＣＲＣが受信され、かつ、確認される前に、パケットの送信開始を可能にする。このようにして、パケットが最終送付先に供給される際に、ＣＲＣチェックにより導入される遅延ペナルティは、１度だけ受けられる。その結果、送信レイテンシは、著しく減少する。この利益を定量化するため、および純粋に例示として、パケットが３つのリンクを介して送られる場合には、各リンクで約１μｓを要し（フレームＣＲＣチェックのため）、合計のパケットレイテンシは３μｓである。カットスルーする場合には、最初の２つのリンクでのパケット遅延は、約１００ｎｓまで減少することができ、１．２μｓの合計パケット遅延時間をもたらす。

図１３の実施形態と同様に、もう１つの例示的な実施形態が、ＴＣ０／ＴＣ１パケットカットスルーを示す図１６として提供される。スイッチでは、ＤｅｖｉｃｅＩＤが受信される際に、カットスルーを開始することができるのに対して、終点では、ペイロードは、ＣＲＣチェックが行なわれているはずなので、カットスルーは行われない。レシーバでエラーが検出された場合には、全ての進行中のカットスルーパケットは、ＥＯＦ＿ＥＲＲトレーラーによりエラーがあるとラベル付けされ、かつ、ＮＡＣが生成される。カットスルーパケットは、Ｔｘ再生バッファに格納され、かつ、良いフレームＣＲＣの場合には、引き渡され、または、ローカルＲｘから報告された（ＣＲＣ）エラーもしくはＥＯＦ＿ＥＲＲの場合には、削除される。ＴｘがＮＡＣを受信した場合には、Ｔｘは、全ての肯定応答されていない引き渡されたフレームを再生し、かつ、無効なカットスルーフレームが受信された場合には、フレームに番号が付け直される。例示的な実施形態に係るこの機能に対応するために、ＥＯＦ＿ＥＲＲ制御シンボルが付加されるが、このシンボルは、ＴＣ２でも、ペイロードエラーを示すために使用される。エラーの場合には、ＥＯＦ＿ＥＲＲにより既に送信されているフレームは、Ｌ２再送信によってスキップされ、かつ、Ｌ２再送信は、スキップされた無効フレームのために、番号を付け直してもよい。対応するトランスミッタ状態機械およびレシーバ状態機械が、図１７Ａ−１７Ｂおよび図１８として、それぞれ示されている。

これらの例示的な実施形態によれば、ヘッダＣＲＣを有する長さベースのフレームは、ヘッダエラーが起こった場合には、より早いエラーリカバリを提供する。ＴＣが正しいと証明された場合には、これは、誤ったＴＣにより生じたバッファオーバーフローを回避し、かつ、帯域幅予約（ｖ２．０）の場合の、偶発的な帯域幅請求を回避する。ＤｅｖｉｃｅＩＤが正しいと証明された場合には、これは、ＤｅｖｉｃｅＩＤエラーによる他のリンクの偶発的なロードを防止する。

よって、１つの例示的な実施形態によれば、中間ノードから終点ノードに向けてデータを送信する方法は、図１９のフローチャートに示されるステップを含む。ここで、ステップ１９００において、中間ノード、例えば図１３のノードＢにおいて、第１のデータフレームが受信される。ステップ１９０２において、第１のデータフレーム内のフレームＣＲＣフィールドを用いて、第１の周期的冗長性検査（ＣＲＣ）を行う前に、第２のデータフレームにおいて、終点ノード（例えば図１３のノードＣ）に向けた第１のデータフレームに含まれるデータパケットの再送信を開始するが、このフレームＣＲＣフィールドは、第１のデータフレームの少なくとも１つの非ＣＲＣフィールドに基づき計算されたものである。中間ノードは、データパケットの再送信を開始した後に、図１９０４に示されるように、フレームＣＲＣフィールドを用いて、第１のデータフレームに対して第１のＣＲＣを行う。次いで、中間ノードは、ステップ１９０６において、第１のデータフレームが破損している、すなわち１つまたは複数のエラーを含む、ことを決定する。その結果、ステップ１９０８において、中間ノードは、第２のデータフレームに含まれているデータパケットが破損していることを示す、第２のデータフレームと関連するフレームトレーラーを送信する。

図１９に示される方法および上述の例示的な実施形態と関連する他の方法は、相互接続システムの一部として、様々なノード構造およびアーキテクチャを用いて実施することができることを、当業者は理解するであろう。上述のやり方でカットスルーパケットを処理する中間ノード（スイッチングデバイス）または終点ノード（例えば、フレームデータレシーバ）２０００の概略的な例示が、図２０として提供される。ここで、例えば中間ノードとして動作する場合に、ノード２０００は、第１のデータフレームを受信するように構成された第１のインターフェイス２００２と、第１のデータフレーム内のフレームＣＲＣフィールドを用いて、第１の周期的冗長性検査（ＣＲＣ）を行う前に、終点ノードに向けた第２のデータフレームとしての第１のデータフレームに含まれるデータパケットの再送信を開始するように構成された第２のインターフェイス２００４であって、フレームＣＲＣフィールドは、第１のデータフレームの少なくとも１つの非ＣＲＣフィールドに基づき計算された、第２のインターフェイス２００４と、を含むことができる。第１および第２のインターフェイスは、インターフェイスコントローラ２００５によって制御することができる。ノード２０００は、また、再送信を開始した後に、フレームＣＲＣフィールドを用いて、第１のデータフレームに対して第１のＣＲＣを行い、第１のデータフレームに対するＣＲＣの結果として、第１のデータフレームが１つまたは複数のエラーを含み破損していることを決定するように構成された、プロセッサ２００６を含むことができる。スイッチングデバイスは、第２のデータフレームに含まれたデータパケットを示す第２のデータフレームと関連するフレームトレーラーを、第２のインターフェイス２００４を介して送信するように、例えばプロセッサ２００６と併せて、さらに構成することができる。また、メモリデバイス２００８を設けることができるが、このメモリデバイスは、特に、上述したような再送信バッファとして動作することができる。

ノード２０００が、終点ノード（または任意のカットスルーフレームデータレシーバ）として動作する場合には、第１のインターフェイス２００２は、カットスルーデータフレームを受信するように構成することができる。プロセッサ２００６は、次いで、カットスルーデータフレームと関連する周期的冗長性検査（ＣＲＣ）フィールド以外のデータフィールドを評価して、カットスルーデータパケットが破損しているか否か、すなわち１つまたは複数のエラーを含むか否か、を決定するように構成することができる。

よって、データパケットを含み、かつ、第１のフレームトレーラーを有するデータフレームを、フレームデータレシーバにおいて受信する、例示的な実施形態に係る方法が、図２１のフローチャートに示されている。ステップ２１００において、フレームデータレシーバの第１のインターフェイスにおいて、データフレームが受信される。ステップ２１０２において、フレームデータレシーバによって、前記データフレーム内のフレームＣＲＣフィールドを用いて、周期的冗長性検査（ＣＲＣ）が行われるが、フレームＣＲＣフィールドは、データフレームの少なくとも１つの非ＣＲＣフィールドに基づき計算されている。第１のＣＲＣの結果として、フレームデータレシーバによって、ステップ２１０４において、データフレームが破損していないことが決定される。しかし、ステップ２１０６において、データパケットが破損していることをフレームトレーラーから決定し、かつ、関連する動作、例えば上述した動作のいずれかが行われる。

上述の例示的な実施形態の様々な変形が考えられる。上述の例示的な実施形態は、全ての点で、本発明の限定ではなく例示であることを意図している。よって、本発明は、当業者によって、ここに含まれる説明から得ることができる詳細な実施において、様々な変形が可能である。このような変形および変更の全ては、添付の特許請求の範囲で定義されるように、本発明の範囲および要旨内にあるとみなされる。本発明の説明に用いられた要素、動作、または指示は、そのように明らかに説明されていない限り、本発明にとって重要または必須であると解釈されるべきではない。また、ここで用いられるように、冠詞ａ（１つの）は、１つまたは複数の項目を含むことを意図している。

Claims (25)

1. 終点ノードに向けてデータを送信する方法であって、
   中間ノードにおいて、データパケットを含む第１のデータフレームを受信するステップと、
   前記第１のデータフレーム内のフレームＣＲＣフィールドを用いて、第１の周期的冗長性検査（ＣＲＣ：cyclic redundancy check）を行う前に、前記中間ノードによって、第２のデータフレームにおいて前記終点ノードに向けた前記第１のデータフレームに含まれるデータパケットの再送信を開始するステップであって、前記フレームＣＲＣフィールドは、前記第１のデータフレームの少なくとも１つの非ＣＲＣフィールドに基づいて計算されている、ステップと、
   前記中間ノードによって、かつ、前記再送信を開始した後に、前記フレームＣＲＣフィールドを用いて、前記第１のデータフレームに対して前記第１のＣＲＣを行うステップと、
   前記第１のＣＲＣの結果として、前記中間ノードによって、前記第１のデータフレームが、１つまたは複数のエラーを含み破損していることを決定するステップと、
   前記第２のデータフレームに含まれる前記データパケットが１つまたは複数のエラーを含み破損していることを示す、前記第２のデータフレームと関連するフレームトレーラーを、前記中間ノードによって前記終点ノードに向けて送信するステップと、を含むことを特徴とする方法。
2. 前記フレームＣＲＣフィールドは、前記第１のデータフレームの全ての非ＣＲＣフィールドに基づき計算される、ことを特徴とする請求項１に記載の方法。
3. 前記第１のデータフレームは、ヘッダＣＲＣフィールドをさらに含み、前記ヘッダＣＲＣフィールドは、前記第１のフレームのヘッダの少なくとも１つの非ＣＲＣフィールドと、前記データパケットのヘッダと、前記データパケットのペイロードの少なくとも一部分とに基づき計算されており、前記方法は、
   前記データパケットの再送信を開始する前に、前記中間ノードによって、前記ヘッダＣＲＣフィールドを用いて第２のＣＲＣを行うステップと、
   前記少なくとも１つのヘッダフィールドが、前記第２のＣＲＣに失敗した場合に、前記データパケットを再送信する代わりに、前記データパケットを破棄するステップと、をさらに含むことを特徴とする請求項１に記載の方法。
4. 前記第１のデータフレームは、ヘッダＣＲＣフィールドを含まず、
   前記再送信ステップは、
   前記データパケット内のレイヤ３（Ｌ３）送付先デバイス識別フィールドが、前記中間ノードによって受信された場合に、前記データパケットの再送信を開始するステップをさらに含む、ことを特徴とする請求項１に記載の方法。
5. 前記中間ノードによって、前記フレームトレーラーを送信するステップは、
   前記第２のデータフレーム内の前記フレームトレーラーとして、特殊レイヤ２シンボルを追加するステップであって、前記特殊レイヤ２シンボルは、前記第２のデータフレームが破損していることを示す、ステップをさらに含む、ことを特徴とする請求項１に記載の方法。
6. 前記フレームトレーラーを送信する前記ステップは、
   前記第２のデータフレーム内のフレームトレーラーにおいて、フラグを設定するステップであって、前記フラグは、前記第２のデータフレームが破損していることを示す、ステップをさらに含む、ことを特徴とする請求項１に記載の方法。
7. 再送信されている前記第２のデータフレームのための第２のフレームＣＲＣフィールドを計算し、前記第２のフレームＣＲＣフィールドを、前記第２のデータフレームに付加し、かつ、前記第２のフレームＣＲＣフィールドを、前記第２のデータフレームと共に送信するステップをさらに含む、ことを特徴とする請求項５に記載の方法。
8. スイッチングデバイスであって、
   第１のデータフレームを受信するように構成された第１のインターフェイスと、
   前記第１のデータフレーム内のフレームＣＲＣフィールドを用いて、第１の周期的冗長性検査（ＣＲＣ）を行う前に、終点に向けた第２のデータフレームとしての前記第１のデータフレームに含まれる前記データパケットの再送信を開始するものであり、前記フレームＣＲＣフィールドが、前記第１のデータフレームの少なくとも１つの非ＣＲＣフィールドに基づき計算されている、ように構成された第２のインターフェイスと、
   前記第１のインターフェイスおよび前記第２のインターフェイスを制御するように構成されたインターフェイスコントローラと、
   前記再送信を開始した後に、前記フレームＣＲＣフィールドを用いて、前記第１のデータフレームに対して前記第１のＣＲＣを行い、かつ、前記第１のデータフレームに対する前記ＣＲＣの結果として、前記第１のデータフレームが１つまたは複数のエラーを含み破損していることを決定するように構成されたプロセッサと、を備え、
   前記スイッチングデバイスは、前記第２のインターフェイスを介して、前記第２のデータフレームに含まれた前記データパケットが破損していることを示す前記第２のデータフレームと関連するフレームトレーラーを送信するようにさらに構成される、ことを特徴とするスイッチングデバイス。
9. 前記フレームＣＲＣフィールドは、前記第１のデータフレームの全ての非ＣＲＣフィールドに基づき計算される、ことを特徴とする請求項８に記載のスイッチングデバイス。
10. 前記第１のデータフレームは、ヘッダＣＲＣフィールドをさらに含み、前記ヘッダＣＲＣフィールドは、前記第１のフレームのヘッダの少なくとも１つの非ＣＲＣフィールドと、前記パケットのヘッダと、前記データパケットのペイロードの少なくとも一部分とに基づき計算されており、前記プロセッサは、前記第２のインターフェイスを介して、前記データパケットの再送信を開始する前に、前記少なくとも１つのヘッダフィールドに対して第２のＣＲＣを行うようにさらに構成されており、
    前記スイッチングデバイスは、前記第２のＣＲＣが失敗した場合に、前記データパケットを再送信する代わりに、前記データパケットを破棄するようにさらに構成される、ことを特徴とする請求項８に記載のスイッチングデバイス。
11. 前記第１のデータフレームは、ヘッダＣＲＣフィールドを含まず、前記スイッチングデバイスは、前記データパケット内のレイヤ３（Ｌ３）送付先デバイス識別フィールドが、前記第１のインターフェイスにおいて受信された場合に、前記第２のインターフェイスを介して、前記データパケットの再送信を開始するようにさらに構成される、ことを特徴とする請求項８に記載のスイッチングデバイス。
12. 前記フレームトレーラーは、前記フレームトレーラーに対する特殊レイヤ２シンボルとして追加され、前記特殊レイヤ２シンボルは、前記第２のデータパケットが破損していることを示す、ことを特徴とする請求項８に記載のスイッチングデバイス。
13. 前記フレームトレーラーは、設定されている場合に、前記第２のデータフレームが破損していることを示すフラグをさらに含む、ことを特徴とする請求項８に記載のスイッチングデバイス。
14. 前記プロセッサは、送信されている前記第２のデータフレームに対して、正しいフレームＣＲＣフィールドを付加するようにさらに構成される、ことを特徴とする請求項１２に記載のスイッチングデバイス。
15. データパケットを含み、かつ、第１のフレームトレーラーを有する、データフレームを、フレームデータレシーバにおいて、受信する方法であって、
    前記フレームデータレシーバの第１のインターフェイスにおいて、前記データフレームを受信するステップと、
    前記フレームデータレシーバによって、前記データフレーム内のフレームＣＲＣフィールドを用いて、周期的冗長性検査（ＣＲＣ）を行うステップであって、前記フレームＣＲＣフィールドは、前記データフレームの少なくとも１つの非ＣＲＣフィールドに基づき計算されている、ステップと、
    前記ＣＲＣの結果として、前記フレームデータレシーバによって、前記データフレームが破損していないことを決定するステップと、
    前記データパケットが１つまたは複数のエラーを含み破損していることを、前記フレームトレーラーから決定し、かつ、関連する動作を行うステップと、を含むことを特徴とする方法。
16. 前記関連する動作は、前記データパケットを破棄することである、ことを特徴とする請求項１５に記載の方法。
17. 前記関連する動作は、前記データパケットを保持し、かつ、前記データパケットが破損していることを示す信号を送信することである、ことを特徴とする請求項１５に記載の方法。
18. 前記データパケットが破損していることを決定する前記ステップは、前記フレームトレーラーに特殊レイヤ２シンボルが存在することを検出するステップであって、前記特殊レイヤ２シンボルは、前記データパケットが破損していることを示す、ステップを含む、ことを特徴とする請求項１５に記載の方法。
19. 前記データパケットが破損していることを決定する前記ステップは、前記フレームトレーラーが、設定されている場合に、フラグを含むことを検出するステップであって、前記フラグは、前記データフレームが破損していることを示す、ステップを含む、ことを特徴とする請求項１５に記載の方法。
20. 前記関連する動作は、否定応答制御（ＮＡＣ：negative acknowledgement control）フレームの送信をスキップすることをさらに含む、ことを特徴とする請求項１５に記載の方法。
21. 前記関連する動作は、再送信バッファから、前記データフレームを除去し、フレームシーケンス番号をロールバックすることをさらに含む、ことを特徴とする請求項１５に記載の方法。
22. フレームデータレシーバであって、
    データパケットを含み、かつ、フレームトレーラーを有する、カットスルーデータフレームを受信するように構成されたインターフェイスと、
    １または複数のプロセッサと、を備え、
    前記１または複数のプロセッサは、
    前記データフレーム内のフレームＣＲＣフィールドを用いて、周期的冗長性検査（ＣＲＣ）を行い、前記フレームＣＲＣフィールドは、前記データフレームの少なくとも１つの非ＣＲＣフィールドに基づき計算されており、
    前記ＣＲＣの結果として、前記データフレームが破損していないことを決定し、
    前記データパケットが１つまたは複数のエラーを含み破損していることを、前記フレームトレーラーから決定し、関連する動作を開始するように構成される、ことを特徴とするフレームデータレシーバ。
23. 前記データパケットが破損していることを決定することは、前記フレームトレーラーに特殊レイヤ２シンボルが存在することを検出することを含み、前記特殊レイヤ２シンボルは、前記データパケットが破損していることを示す、ことを特徴とする請求項２２に記載のフレームデータレシーバ。
24. 前記データパケットが破損していることを決定することは、前記フレームトレーラーがフラグを含むことを検出することを含み、前記フラグは、前記データフレームが破損していることを示す、ことを特徴とする請求項２３に記載のフレームデータレシーバ。
25. 前記カットスルーデータフレームが破損していないことを決定することは、前記データフレームに正しいフレームＣＲＣフィールドが存在することを検出することを含む、ことを特徴とする請求項２２に記載のフレームデータレシーバ。

Images