JPH10164140A - ビジーノードと欠陥ノードを有するリング・ネットワーク・システムで強くシーケンシャルに順序付けられたパケット・フローを維持するシステム - Google Patents
ビジーノードと欠陥ノードを有するリング・ネットワーク・システムで強くシーケンシャルに順序付けられたパケット・フローを維持するシステムInfo
- Publication number
- JPH10164140A JPH10164140A JP9211428A JP21142897A JPH10164140A JP H10164140 A JPH10164140 A JP H10164140A JP 9211428 A JP9211428 A JP 9211428A JP 21142897 A JP21142897 A JP 21142897A JP H10164140 A JPH10164140 A JP H10164140A
- Authority
- JP
- Japan
- Prior art keywords
- node
- packet
- busy
- packets
- subsystem
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1806—Go-back-N protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40091—Bus bridging
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/42—Loop networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/42—Loop networks
- H04L12/427—Loop networks with decentralised control
- H04L12/433—Loop networks with decentralised control with asynchronous transmission, e.g. token ring, register insertion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1809—Selective-repeat protocols
Abstract
(57)【要約】
【課題】 強力に順序付けられた非アイデンポテント・
コマンドのサポートを備えたリング・ネットワーク内で
信頼できるパケット配布を維持するためのシステムを提
供する。 【解決手段】 ネットワーク上の各消費側ノードは、最
後の既知の良好パケットとその順序番号の記録を含む、
そのノードを通過したパケットの順序とそれを通過した
時点でのそれぞれのパケットの状態の記録を保持してい
る。作成側ノードは、パケットに関する肯定応答内のエ
ラー条件を検出すると、最後の既知の良好パケットから
始まるすべてのパケットを再送信する。各消費側ノード
は、すでに処理された可能性のあるパケットを含む、再
送信したパケットを処理または拒否することができる
が、それについてはすべてのパケットに関するパケット
および状態記録によって認識する。
コマンドのサポートを備えたリング・ネットワーク内で
信頼できるパケット配布を維持するためのシステムを提
供する。 【解決手段】 ネットワーク上の各消費側ノードは、最
後の既知の良好パケットとその順序番号の記録を含む、
そのノードを通過したパケットの順序とそれを通過した
時点でのそれぞれのパケットの状態の記録を保持してい
る。作成側ノードは、パケットに関する肯定応答内のエ
ラー条件を検出すると、最後の既知の良好パケットから
始まるすべてのパケットを再送信する。各消費側ノード
は、すでに処理された可能性のあるパケットを含む、再
送信したパケットを処理または拒否することができる
が、それについてはすべてのパケットに関するパケット
および状態記録によって認識する。
Description
【０００１】
【発明の属する技術分野】本発明は、直列相互接続を使
用するプロセッサ・ベースのネットワーク内でパケット
送信をサポートするためのシステムに関する。具体的に
は、本発明のシステムは、このようなネットワーク内、
特にリングレット・トポロジ内のエラーに応答してパケ
ットの動的順序付けをサポートし、過負荷またはノード
障害のいずれかにより応答できないかまたは長時間の
間、使用中肯定応答によって応答するノードと、ネット
ワーク上のノードにおける使用中条件の両方に対応す
る。
用するプロセッサ・ベースのネットワーク内でパケット
送信をサポートするためのシステムに関する。具体的に
は、本発明のシステムは、このようなネットワーク内、
特にリングレット・トポロジ内のエラーに応答してパケ
ットの動的順序付けをサポートし、過負荷またはノード
障害のいずれかにより応答できないかまたは長時間の
間、使用中肯定応答によって応答するノードと、ネット
ワーク上のノードにおける使用中条件の両方に対応す
る。
【０００２】
【従来の技術】コンピュータ・システム内の直列相互接
続は、いくつかの様々なタイプのサービス割込みの影響
を受ける可能性がある。たとえば、ネットワーク上のノ
ードがパケット内のＣＲＣ（巡回冗長検査）エラーを検
出した場合、そのパケットは受け入れることができな
い。そのパケットを送信したノードは、一般に間接的に
（たとえば、タイムアウトによるか、アイドル・パケッ
トの使用による）エラーを認識し、結局、そのパケット
を再送信しなければならない。
続は、いくつかの様々なタイプのサービス割込みの影響
を受ける可能性がある。たとえば、ネットワーク上のノ
ードがパケット内のＣＲＣ（巡回冗長検査）エラーを検
出した場合、そのパケットは受け入れることができな
い。そのパケットを送信したノードは、一般に間接的に
（たとえば、タイムアウトによるか、アイドル・パケッ
トの使用による）エラーを認識し、結局、そのパケット
を再送信しなければならない。
【０００３】特に、ネットワークが緩和メモリ順序付け
（ＲＭＯ）、強力順次順序付け（ＳＳＯ）、その他また
は中間厳密度の順序付けなどの順序付け方式を実施する
場合には、パケットの再送信が単純なことではない可能
性がある。このような順序付け方式を備えたパケット交
換ネットワークでは、ＣＲＣエラーを発生するパケット
の前後のパケットは、作成側ノードからターゲット・ノ
ードに再送信する必要がある可能性がある。このような
パケットが非アイデンポテント・コマンド、すなわち、
ターゲット・ノードで実行すると、そのノードでコマン
ドを再実行したときに第１の実行とは異なる結果が得ら
れるようにそのノードの状態を変更するコマンドを含む
場合、特定の問題が発生する。この場合、コマンドをそ
のノードに再送信し、もう一度実行した場合、不要また
は予測できない結果が発生する可能性がある。
（ＲＭＯ）、強力順次順序付け（ＳＳＯ）、その他また
は中間厳密度の順序付けなどの順序付け方式を実施する
場合には、パケットの再送信が単純なことではない可能
性がある。このような順序付け方式を備えたパケット交
換ネットワークでは、ＣＲＣエラーを発生するパケット
の前後のパケットは、作成側ノードからターゲット・ノ
ードに再送信する必要がある可能性がある。このような
パケットが非アイデンポテント・コマンド、すなわち、
ターゲット・ノードで実行すると、そのノードでコマン
ドを再実行したときに第１の実行とは異なる結果が得ら
れるようにそのノードの状態を変更するコマンドを含む
場合、特定の問題が発生する。この場合、コマンドをそ
のノードに再送信し、もう一度実行した場合、不要また
は予測できない結果が発生する可能性がある。
【０００４】
【発明が解決しようとする課題】したがって、アイデン
ポテント・コマンドのサポートを維持しながら、ターゲ
ット・ノードにパケットを再送信することによってパケ
ットのエラーに対応可能なシステムが必要である。特
に、様々なレベルの順序付け方式もサポートするような
システムが必要である。
ポテント・コマンドのサポートを維持しながら、ターゲ
ット・ノードにパケットを再送信することによってパケ
ットのエラーに対応可能なシステムが必要である。特
に、様々なレベルの順序付け方式もサポートするような
システムが必要である。
【０００５】挙動不良のノード、すなわち、故障してい
るかまたは応答するのに不当に長い時間を要するノード
に対応できるようなシステムに対する特定の必要性が存
在する。単一受信側の挙動が不適切なトポロジでは、こ
のようなノードは、新しいパケットが導入される前に同
じ使用中パケットの反復送信を強制的に完了させること
により、新しいパケットの順方向の進行を妨げる恐れが
ある。したがって、このような潜在的な落とし穴を処理
するシステムが必要である。
るかまたは応答するのに不当に長い時間を要するノード
に対応できるようなシステムに対する特定の必要性が存
在する。単一受信側の挙動が不適切なトポロジでは、こ
のようなノードは、新しいパケットが導入される前に同
じ使用中パケットの反復送信を強制的に完了させること
により、新しいパケットの順方向の進行を妨げる恐れが
ある。したがって、このような潜在的な落とし穴を処理
するシステムが必要である。
【０００６】
【課題を解決するための手段】すべての既知の良好パケ
ットの各受信ノードで状態を維持することにより、使用
中ａｃｋを処理すると同時に結果的にＣＲＣエラーを発
生しているパケットの再送信を行うシステムを提示す
る。パケットを再送信する必要がある場合、ローカル・
ノードは、再送信されたパケットをすでに処理したかど
うかを把握し、どのパケットが最後の既知の良好パケッ
トであるかを把握し、このため、非アイデンポテント・
コマンドを含む、すでに実行されたコマンドの再処理を
回避することができる。使用中ループはエラー・ループ
が実行されている間に効率よく中断することができ、パ
ケットの再順序付けが行われると、使用中ループを完了
することができる。さらに、システムは、作成側ノード
に応答を返送しないような挙動不良、たとえば、非応答
ノードに対応する。このような挙動不良ノードは、待ち
行列化した再試行方針によって効率よく中立化すること
ができる。この場合、何らかの所定のしきい値に達する
まで再試行パケット待ち行列に使用中パケットが蓄積さ
れ、その後、作成側ノードがそのノードへのパケットを
再試行しようというその試みを終了することにより、継
続的に使用中のノードが効率よくシステムから除去され
る。このようにして、システムは他の未解決パケットの
処理を続行することができる。
ットの各受信ノードで状態を維持することにより、使用
中ａｃｋを処理すると同時に結果的にＣＲＣエラーを発
生しているパケットの再送信を行うシステムを提示す
る。パケットを再送信する必要がある場合、ローカル・
ノードは、再送信されたパケットをすでに処理したかど
うかを把握し、どのパケットが最後の既知の良好パケッ
トであるかを把握し、このため、非アイデンポテント・
コマンドを含む、すでに実行されたコマンドの再処理を
回避することができる。使用中ループはエラー・ループ
が実行されている間に効率よく中断することができ、パ
ケットの再順序付けが行われると、使用中ループを完了
することができる。さらに、システムは、作成側ノード
に応答を返送しないような挙動不良、たとえば、非応答
ノードに対応する。このような挙動不良ノードは、待ち
行列化した再試行方針によって効率よく中立化すること
ができる。この場合、何らかの所定のしきい値に達する
まで再試行パケット待ち行列に使用中パケットが蓄積さ
れ、その後、作成側ノードがそのノードへのパケットを
再試行しようというその試みを終了することにより、継
続的に使用中のノードが効率よくシステムから除去され
る。このようにして、システムは他の未解決パケットの
処理を続行することができる。
【０００７】したがって、本出願は、リングレット・ネ
ットワーク上で同時に発生する３通りの問題、すなわ
ち、エラー条件、１つまたは複数のノードでの使用中条
件、ノードの故障または過負荷の解決を達成する複雑な
システムに関する。適当なエラー再試行メカニズムにつ
いては、本明細書と、ｖａｎ Ｌｏｏ他により１９９６
年７月１日に出願され、Ｓｙｓｔｅｍ ｆｏｒ Ｄｙｎ
ａｍｉｃ Ｏｒｄｅｒｉｎｇ Ｓｕｐｐｏｒｔ ｉｎ
ａ Ｒｉｎｇｌｅｔ Ｓｅｒｉａｌ Ｉｎｔｅｒｃｏｎ
ｎｅｃｔという名称の本出願人の関連特許出願の両方に
記載されている。このようなエラー再試行メカニズムに
基づくと同時に使用中再試行動作を処理できるシステム
については、ｖａｎ Ｌｏｏ他により１９９６年７月１
日に出願され、Ｓｙｓｔｅｍ ｆｏｒ Ｐｒｅｓｅｒｖ
ｉｎｇ Ｓｅｑｕｅｎｔｉａｌ Ｏｒｄｅｒｉｎｇ ａ
ｎｄ Ｓｕｐｐｏｒｔｉｎｇ Ｉｄｅｍｐｏｔｅｎｔ
Ｃｏｍｍａｎｄｓ ｉｎ ａ Ｒｉｎｇ Ｎｅｔｗｏｒ
ｋ ｗｉｔｈ Ｂｕｓｙ Ｎｏｄｅｓという名称の本出
願人の関連特許出願に記載されている。これらの特許出
願はいずれも参照により本明細書に組み込まれる。
ットワーク上で同時に発生する３通りの問題、すなわ
ち、エラー条件、１つまたは複数のノードでの使用中条
件、ノードの故障または過負荷の解決を達成する複雑な
システムに関する。適当なエラー再試行メカニズムにつ
いては、本明細書と、ｖａｎ Ｌｏｏ他により１９９６
年７月１日に出願され、Ｓｙｓｔｅｍ ｆｏｒ Ｄｙｎ
ａｍｉｃ Ｏｒｄｅｒｉｎｇ Ｓｕｐｐｏｒｔ ｉｎ
ａ Ｒｉｎｇｌｅｔ Ｓｅｒｉａｌ Ｉｎｔｅｒｃｏｎ
ｎｅｃｔという名称の本出願人の関連特許出願の両方に
記載されている。このようなエラー再試行メカニズムに
基づくと同時に使用中再試行動作を処理できるシステム
については、ｖａｎ Ｌｏｏ他により１９９６年７月１
日に出願され、Ｓｙｓｔｅｍ ｆｏｒ Ｐｒｅｓｅｒｖ
ｉｎｇ Ｓｅｑｕｅｎｔｉａｌ Ｏｒｄｅｒｉｎｇ ａ
ｎｄ Ｓｕｐｐｏｒｔｉｎｇ Ｉｄｅｍｐｏｔｅｎｔ
Ｃｏｍｍａｎｄｓ ｉｎ ａ Ｒｉｎｇ Ｎｅｔｗｏｒ
ｋ ｗｉｔｈ Ｂｕｓｙ Ｎｏｄｅｓという名称の本出
願人の関連特許出願に記載されている。これらの特許出
願はいずれも参照により本明細書に組み込まれる。
【０００８】
【発明の実施の形態】図１は、それぞれが送受信機能を
備えた４つのノードＡ〜Ｄを含む標準的なリングレット
１を示している。要求および応答は作成側ノード、たと
えば、ノードＡによって送出され、肯定応答（たとえ
ば、ａｃｋ＿ｄｏｎｅおよびａｃｋ＿ｂｕｓｙ）は消費
側ノード、たとえば、ノードＣによって送信される。ノ
ードＣは従来通り他のリングレット２、３、４と通信す
ることもできる。本発明は、特に、リングレット１など
のリング・ネットワーク内のエラーの影響を受けるパケ
ットの解決策に関する。これは予測不能なパケットの配
達および受入れを発生する可能性がある。というのは、
作成側はそれが何を送信したかを把握しているが、肯定
応答が受信されていないパケットが実際に意図されたノ
ードによって処理されたかどうかを把握していない（間
接手段によるものを除く）からである。
備えた４つのノードＡ〜Ｄを含む標準的なリングレット
１を示している。要求および応答は作成側ノード、たと
えば、ノードＡによって送出され、肯定応答（たとえ
ば、ａｃｋ＿ｄｏｎｅおよびａｃｋ＿ｂｕｓｙ）は消費
側ノード、たとえば、ノードＣによって送信される。ノ
ードＣは従来通り他のリングレット２、３、４と通信す
ることもできる。本発明は、特に、リングレット１など
のリング・ネットワーク内のエラーの影響を受けるパケ
ットの解決策に関する。これは予測不能なパケットの配
達および受入れを発生する可能性がある。というのは、
作成側はそれが何を送信したかを把握しているが、肯定
応答が受信されていないパケットが実際に意図されたノ
ードによって処理されたかどうかを把握していない（間
接手段によるものを除く）からである。
【０００９】順序付けが必要な場合、課題はさらに大き
くなる。図２は、ノードＡによって特定の順序Ａ、Ｂ、
Ｃ・・・で送信されるコマンドと、リングレットおよび
送信時の変動のために、Ｂ、Ａ、Ａ、Ａ・・・などの他
の順序での受信とを示している。システムの挙動が適切
であれば、送信パケットを再順序付けし、最初に送信さ
れた順序でその送信パケットを適切に実行できるはずで
ある。
くなる。図２は、ノードＡによって特定の順序Ａ、Ｂ、
Ｃ・・・で送信されるコマンドと、リングレットおよび
送信時の変動のために、Ｂ、Ａ、Ａ、Ａ・・・などの他
の順序での受信とを示している。システムの挙動が適切
であれば、送信パケットを再順序付けし、最初に送信さ
れた順序でその送信パケットを適切に実行できるはずで
ある。
【００１０】図３は強力順次順序付け（ＳＳＯ）を示し
ている。すなわち、いずれのパケットも送信されたとき
の順序から外れて受信されることはなく、２回現れる可
能性はあるが、順不同で現れることはない。図４はＳＳ
Ｏと非アイデンポテント・コマンドの両方の使用を示し
ている。順序が保持されるだけでなく、非アイデンポテ
ントコマンドの特性により、従来システム内のコマンド
はいずれも宛先ノードによって２回実行することはでき
ない。ただし、図４において、｛ｐｒｏｄｕｃｅｒＩ
ｄ， ｐＬａｂｅｌ｝はｓｅｎｄ＿ｐｋｔおよび肯定応
答に共通し、また、｛ｐｒｏｄｕｃｅｒＩｄ， ｐＬａ
ｂｅｌ｝は各ノードから見えるもので、不在エラーであ
ることに留意されたい。
ている。すなわち、いずれのパケットも送信されたとき
の順序から外れて受信されることはなく、２回現れる可
能性はあるが、順不同で現れることはない。図４はＳＳ
Ｏと非アイデンポテント・コマンドの両方の使用を示し
ている。順序が保持されるだけでなく、非アイデンポテ
ントコマンドの特性により、従来システム内のコマンド
はいずれも宛先ノードによって２回実行することはでき
ない。ただし、図４において、｛ｐｒｏｄｕｃｅｒＩ
ｄ， ｐＬａｂｅｌ｝はｓｅｎｄ＿ｐｋｔおよび肯定応
答に共通し、また、｛ｐｒｏｄｕｃｅｒＩｄ， ｐＬａ
ｂｅｌ｝は各ノードから見えるもので、不在エラーであ
ることに留意されたい。
【００１１】図５は上記の課題に対する本出願人の解決
策に適したデータ構造を示している。パケットはｐｒｏ
ｄｕｃｅｒＩＤとｐＬａｂｅｌというフィールドを含む
が、詳細については以下に述べる。この２つのフィール
ドは、消費側から作成側に返送される肯定応答パケット
内に含まれる。
策に適したデータ構造を示している。パケットはｐｒｏ
ｄｕｃｅｒＩＤとｐＬａｂｅｌというフィールドを含む
が、詳細については以下に述べる。この２つのフィール
ドは、消費側から作成側に返送される肯定応答パケット
内に含まれる。
【００１２】本発明は、図６に示すようなパターンで既
知の良好な（すでに受け入れられた／実行済みの）パケ
ットとそれ以外のパケットの両方を再送信する。図６Ａ
は本発明のシステムの基本的な手法を高レベルで要約し
たものであり、有効肯定応答（「実行済み」の場合もあ
れば「使用中」の場合もある）が作成側ノードで受信さ
れるまで、必要に応じて既知の良好ＳＳＯパケットを繰
り返し再送信する。次に作成側ノードは、適切に処理さ
れたもの、すなわち、それに関してａｃｋ＿ｄｏｎｅが
受信されたものであっても、既知の良好パケットの後
で、他のすべてのパケットを再送信する。（図７を参
照。）ａｃｋは再送信パケットから戻ってくるので、作
成側ノードは、すべてが有効ａｃｋ、すなわち、「実行
済み」または「使用済み」であることを確認するために
検査する。すべてが有効ａｃｋであるわけではない場
合、すべてのａｃｋが実際に有効になるまで再送信プロ
セスを繰り返す。これにより、すべてのエラー・パケッ
トが適切に処理されたことが確認され、システムは後続
パケットについて処理を続行することができる。この手
法では、ＳＳＯを保持し、非アイデンポテント・コマン
ドをサポートするために、複雑な課題が提示され、図９
〜３９に示す論理によって解決策が提示される。その動
作については図４０以降の状態図に示す。
知の良好な（すでに受け入れられた／実行済みの）パケ
ットとそれ以外のパケットの両方を再送信する。図６Ａ
は本発明のシステムの基本的な手法を高レベルで要約し
たものであり、有効肯定応答（「実行済み」の場合もあ
れば「使用中」の場合もある）が作成側ノードで受信さ
れるまで、必要に応じて既知の良好ＳＳＯパケットを繰
り返し再送信する。次に作成側ノードは、適切に処理さ
れたもの、すなわち、それに関してａｃｋ＿ｄｏｎｅが
受信されたものであっても、既知の良好パケットの後
で、他のすべてのパケットを再送信する。（図７を参
照。）ａｃｋは再送信パケットから戻ってくるので、作
成側ノードは、すべてが有効ａｃｋ、すなわち、「実行
済み」または「使用済み」であることを確認するために
検査する。すべてが有効ａｃｋであるわけではない場
合、すべてのａｃｋが実際に有効になるまで再送信プロ
セスを繰り返す。これにより、すべてのエラー・パケッ
トが適切に処理されたことが確認され、システムは後続
パケットについて処理を続行することができる。この手
法では、ＳＳＯを保持し、非アイデンポテント・コマン
ドをサポートするために、複雑な課題が提示され、図９
〜３９に示す論理によって解決策が提示される。その動
作については図４０以降の状態図に示す。
【００１３】本発明は、消費側ノードがパケット・アク
ションに関する状態（受入れおよび拒否状態）とａｃｋ
に関する状態（実行済みおよび使用中）を継続的に維持
するという事実によって使用可能になる。これは、各ノ
ードが検出するすべてのパケットおよびａｃｋに当ては
まる。したがって、各消費側ノードは、各パケットがそ
のノードを通過したときにリングレットを移動するすべ
てのパケットの処分を認識している。この情報は再送信
プロセスでは重要なものである。しかも、各消費側ノー
ドは、通過したパケットの順序と、最後の既知の良好パ
ケット（それに関してａｃｋ＿ｄｏｎｅまたはａｃｋ＿
ｂｕｓｙが出されたもの）の順序番号の記録を保持して
いる。これは、ＣＲＣエラーなどが検出されたときに必
要であればシステムがパックアップ可能な点を示すもの
である。これについては、図４０以降の例に関する以下
の説明でより明確に示すものとする。
ションに関する状態（受入れおよび拒否状態）とａｃｋ
に関する状態（実行済みおよび使用中）を継続的に維持
するという事実によって使用可能になる。これは、各ノ
ードが検出するすべてのパケットおよびａｃｋに当ては
まる。したがって、各消費側ノードは、各パケットがそ
のノードを通過したときにリングレットを移動するすべ
てのパケットの処分を認識している。この情報は再送信
プロセスでは重要なものである。しかも、各消費側ノー
ドは、通過したパケットの順序と、最後の既知の良好パ
ケット（それに関してａｃｋ＿ｄｏｎｅまたはａｃｋ＿
ｂｕｓｙが出されたもの）の順序番号の記録を保持して
いる。これは、ＣＲＣエラーなどが検出されたときに必
要であればシステムがパックアップ可能な点を示すもの
である。これについては、図４０以降の例に関する以下
の説明でより明確に示すものとする。
【００１４】図８は、本発明に適したハードウェア環境
を示すブロック図であり、作成側ノード内で可能なパケ
ットの流れを示すためにも役に立つものである。これ
は、図４０以降の流れ図／状態図および図９〜３９の論
理図を考慮すると、詳細に理解することができる。
を示すブロック図であり、作成側ノード内で可能なパケ
ットの流れを示すためにも役に立つものである。これ
は、図４０以降の流れ図／状態図および図９〜３９の論
理図を考慮すると、詳細に理解することができる。
【００１５】図４０には、システムの基本ブロックが示
されている。ＳＳＯ順序付け拡張機能がない場合、この
システムは、以下に示す削除および変更を伴うすべての
ブロックを含むものと思われる。 −ｒｅｔｒｙ＿ｐｋｔレジスタ７−１９０を削除する −ｒｅｔｒｙ＿ｐｋｔ待ち行列７−３０を削除する −７−１００内のｏｒ＿ｌａｓｔ＿ｃｔカウンタを削除
し、ｎｏ＿ｌａｓｔ＿ｃｔを保持する −４：１マルチプレクサを３：１マルチプレクサ７−４
０に変更する −ｏｒ＿ｒｃｖｄ＿ｃｔカウンタ７−２５０を削除する その他のブロックは、ＳＳＯサポートを伴わない送信ノ
ードの動作にとって依然として基本的なものである。
されている。ＳＳＯ順序付け拡張機能がない場合、この
システムは、以下に示す削除および変更を伴うすべての
ブロックを含むものと思われる。 −ｒｅｔｒｙ＿ｐｋｔレジスタ７−１９０を削除する −ｒｅｔｒｙ＿ｐｋｔ待ち行列７−３０を削除する −７−１００内のｏｒ＿ｌａｓｔ＿ｃｔカウンタを削除
し、ｎｏ＿ｌａｓｔ＿ｃｔを保持する −４：１マルチプレクサを３：１マルチプレクサ７−４
０に変更する −ｏｒ＿ｒｃｖｄ＿ｃｔカウンタ７−２５０を削除する その他のブロックは、ＳＳＯサポートを伴わない送信ノ
ードの動作にとって依然として基本的なものである。
【００１６】図８と図４０の詳細ブロック図の両方を参
照し、システムの基本動作を以下に示す。要求および応
答ＦＩＦＯ待ち行列によりトランザクション層からリン
ク層にパケットを挿入する。図示の通り、ｓｅｎｄ＿ｐ
ｋｔレジスタ、ＣＲＣジェネレータと８／２０エンコー
ダ、シリアライザによるリングレットへの（可能な）送
信のためにマルチプレクサ（ＭＵＸ）によりパケットを
選択する。
照し、システムの基本動作を以下に示す。要求および応
答ＦＩＦＯ待ち行列によりトランザクション層からリン
ク層にパケットを挿入する。図示の通り、ｓｅｎｄ＿ｐ
ｋｔレジスタ、ＣＲＣジェネレータと８／２０エンコー
ダ、シリアライザによるリングレットへの（可能な）送
信のためにマルチプレクサ（ＭＵＸ）によりパケットを
選択する。
【００１７】このノードからの要求および応答送信パケ
ットに関する肯定応答ならびに他のノードから発信され
たがこのノードに向けられている着信要求および応答パ
ケットをデシリアライザで受信する。８／１０デコード
およびＣＲＣ検査の後、着信受信および肯定応答パケッ
トをｒｅｃ＿ｐｋｔレジスタに登録する。ｒｅｃ＿ｐｋ
ｔレジスタの前にアイドル記号を取り除く。ＣＲＣエラ
ーまたは８／１０エンコード・エラーにより、着信受信
および肯定応答パケットが無効になる。ＣＲＣエラーを
伴う肯定応答はｒｅｃ＿ｐｋｔレジスタを越えて目に見
えるものではないので、他のノードから受信した送信パ
ケットは、トランザクション層にとって見えないように
処理する。（受信バッファの説明を参照。）ａｃｋデコ
ード論理は、それがそのシリアライザにより送信した送
信パケットに関してこのノードにアドレス指定されたａ
ｃｋを検出するものである。
ットに関する肯定応答ならびに他のノードから発信され
たがこのノードに向けられている着信要求および応答パ
ケットをデシリアライザで受信する。８／１０デコード
およびＣＲＣ検査の後、着信受信および肯定応答パケッ
トをｒｅｃ＿ｐｋｔレジスタに登録する。ｒｅｃ＿ｐｋ
ｔレジスタの前にアイドル記号を取り除く。ＣＲＣエラ
ーまたは８／１０エンコード・エラーにより、着信受信
および肯定応答パケットが無効になる。ＣＲＣエラーを
伴う肯定応答はｒｅｃ＿ｐｋｔレジスタを越えて目に見
えるものではないので、他のノードから受信した送信パ
ケットは、トランザクション層にとって見えないように
処理する。（受信バッファの説明を参照。）ａｃｋデコ
ード論理は、それがそのシリアライザにより送信した送
信パケットに関してこのノードにアドレス指定されたａ
ｃｋを検出するものである。
【００１８】ａｃｋは、ａｃｋ待ち行列内に待ち行列化
し、ａｃｋ＿ｌｏｇｉｃブロック内でｓｅｎｄ＿ｐｋｔ
待ち行列内の送信待ち行列と突き合わせる。ＳＳＯサポ
ートがない場合、すべてのパケットはｎｏｎ＿ｏｒｄｅ
ｒレジスタを通って流れるはずであり、ＳＳＯの場合
は、すべてのＳＳＯパケットがｒｅｔｒｙ＿ｐｋｔレジ
スタを通って流れ、非ＳＳＯパケットはｎｏｎ＿ｏｒｄ
ｅｒレジスタにより継続する。
し、ａｃｋ＿ｌｏｇｉｃブロック内でｓｅｎｄ＿ｐｋｔ
待ち行列内の送信待ち行列と突き合わせる。ＳＳＯサポ
ートがない場合、すべてのパケットはｎｏｎ＿ｏｒｄｅ
ｒレジスタを通って流れるはずであり、ＳＳＯの場合
は、すべてのＳＳＯパケットがｒｅｔｒｙ＿ｐｋｔレジ
スタを通って流れ、非ＳＳＯパケットはｎｏｎ＿ｏｒｄ
ｅｒレジスタにより継続する。
【００１９】再送信論理は、基本的にａｃｋ状況を検査
し、パケットが完了したか（ａｃｋ＿ｄｏｎｅ）または
受信側が使用中であるために再試行が必要であるか（ａ
ｃｋ＿ｂｕｓｙ）を判定する。ａｃｋ＿ｄｏｎｅパケッ
トは、「コマンド・レベルへのａｃｋ」ブロックにより
トランザクション層に状況を返す。ＭＵＸ論理および
４：１（または、本発明の指定の実施形態に応じて３：
１）ＭＵＸにより再試行するために、非ＳＳＯ使用中再
試行パケットを選択することができる。ＳＳＯ使用中再
試行パケットはｒｅｔｒｙ＿ｐｋｔＦＩＦＯ待ち行列に
待ち行列化される。このようなパケットは、ＳＳＯ使用
中再試行論理によってＭＵＸ論理およびＭＵＸを介して
この待ち行列から選択される。これについては、システ
ム全体に分散され、図１０〜２５の送信論理用の流れ図
に記載する。
し、パケットが完了したか（ａｃｋ＿ｄｏｎｅ）または
受信側が使用中であるために再試行が必要であるか（ａ
ｃｋ＿ｂｕｓｙ）を判定する。ａｃｋ＿ｄｏｎｅパケッ
トは、「コマンド・レベルへのａｃｋ」ブロックにより
トランザクション層に状況を返す。ＭＵＸ論理および
４：１（または、本発明の指定の実施形態に応じて３：
１）ＭＵＸにより再試行するために、非ＳＳＯ使用中再
試行パケットを選択することができる。ＳＳＯ使用中再
試行パケットはｒｅｔｒｙ＿ｐｋｔＦＩＦＯ待ち行列に
待ち行列化される。このようなパケットは、ＳＳＯ使用
中再試行論理によってＭＵＸ論理およびＭＵＸを介して
この待ち行列から選択される。これについては、システ
ム全体に分散され、図１０〜２５の送信論理用の流れ図
に記載する。
【００２０】図１０〜２６の送信論理は、基本的に以下
のように動作する。その動作の詳細は、図４０以降の状
態図／流れ図に関連して流れの例に関して以下により明
確になるだろう。以下の説明の各論理ユニット（たとえ
ば、ａｃｋ＿ｌｏｇｉｃ）は図４０内のこのような要素
を指し示す。
のように動作する。その動作の詳細は、図４０以降の状
態図／流れ図に関連して流れの例に関して以下により明
確になるだろう。以下の説明の各論理ユニット（たとえ
ば、ａｃｋ＿ｌｏｇｉｃ）は図４０内のこのような要素
を指し示す。
【００２１】図１０は、エラー条件の場合に肯定応答と
照らし合わせてパケットをテストし、エラーがない場合
に使用中再試行を開始するためのａｃｋ論理である。
照らし合わせてパケットをテストし、エラーがない場合
に使用中再試行を開始するためのａｃｋ論理である。
【００２２】図１１は、エラーがない場合に通常パケッ
ト処理のためにａｃｋ論理出力を設定するためのａｃｋ
論理である。
ト処理のためにａｃｋ論理出力を設定するためのａｃｋ
論理である。
【００２３】図１２は、ｎｏｎ＿ｏｒｄｅｒレジスタに
ロードすべき非ＳＳＯパケット用のａｃｋ論理内の処理
である。
ロードすべき非ＳＳＯパケット用のａｃｋ論理内の処理
である。
【００２４】図１３は、ＣＲＣ＿ｉｎｉｔ＿ｅｒｒエラ
ー再試行ループを処理するａｃｋ論理であり、それがこ
のパケット用の有効（実行済みまたは使用中）肯定応答
を受信するまで最後の「既知の良好」ＳＳＯパケットを
再送信するものである。
ー再試行ループを処理するａｃｋ論理であり、それがこ
のパケット用の有効（実行済みまたは使用中）肯定応答
を受信するまで最後の「既知の良好」ＳＳＯパケットを
再送信するものである。
【００２５】図１４は、ＣＲＣ＿ｅｒｒエラー再試行ル
ープを処理するａｃｋ論理であり、リングレットにより
「既知の良好」パケット以降のすべてのパケットを再送
信するものである。
ープを処理するａｃｋ論理であり、リングレットにより
「既知の良好」パケット以降のすべてのパケットを再送
信するものである。
【００２６】図１５は、ＣＲＣ＿ａｃｋ＿ｃｈｋエラー
再試行ループを処理するａｃｋ論理であり、ＣＲＣ＿ｅ
ｒｒループで再試行されたすべてのパケットがエラーな
しで完了したかまたはエラーが発生しているかをテスト
するものである。エラーが検出された場合、ＣＲＣ＿ｉ
ｎｉｔ＿ｅｒｒからループを再試行する（図３１）。エ
ラーが一切検出されない場合、ＣＲＣ＿ｅｒｒ＿ｅｎｄ
を設定する。
再試行ループを処理するａｃｋ論理であり、ＣＲＣ＿ｅ
ｒｒループで再試行されたすべてのパケットがエラーな
しで完了したかまたはエラーが発生しているかをテスト
するものである。エラーが検出された場合、ＣＲＣ＿ｉ
ｎｉｔ＿ｅｒｒからループを再試行する（図３１）。エ
ラーが一切検出されない場合、ＣＲＣ＿ｅｒｒ＿ｅｎｄ
を設定する。
【００２７】図１６は、ＣＲＣ＿ａｃｋ＿ｃｈｋエラー
再試行ループを処理するａｃｋ論理であり、ＣＲＣ＿ｅ
ｒｒループ中に送信した各パケットの肯定応答について
有効肯定応答（ａｃｋ＿ｂｕｓｙまたはａｃｋ＿ｄｏｎ
ｅ）があるかどうかをテストし（図３２）、エラーが検
出された場合にエラー・ビットをを設定する。
再試行ループを処理するａｃｋ論理であり、ＣＲＣ＿ｅ
ｒｒループ中に送信した各パケットの肯定応答について
有効肯定応答（ａｃｋ＿ｂｕｓｙまたはａｃｋ＿ｄｏｎ
ｅ）があるかどうかをテストし（図３２）、エラーが検
出された場合にエラー・ビットをを設定する。
【００２８】図１７は、パケット状態情報のフォーマッ
トを処理し、ＣＲＣ＿ｉｎｉｔ＿ｅｒｒ、ＣＲＣ＿ｅｒ
ｒ、ＣＲＣ＿ａｃｋ＿ｃｈｋループの実行中にＭＵＸを
設定する再送信論理である。
トを処理し、ＣＲＣ＿ｉｎｉｔ＿ｅｒｒ、ＣＲＣ＿ｅｒ
ｒ、ＣＲＣ＿ａｃｋ＿ｃｈｋループの実行中にＭＵＸを
設定する再送信論理である。
【００２９】図１８は、ＣＲＣ＿ｅｒｒ＿ｅｎｄ制御を
完了するための条件を検出し、ｒｅｔｒｙ＿ｐｋｔ待ち
行列が空であるかどうかをテストすることにより、使用
中再試行ループの完了を検出するためにｂｕｓｙ＿ｌｏ
ｏｐ＿ｃｍｐｌｔ制御を設定するための再送信論理であ
る。
完了するための条件を検出し、ｒｅｔｒｙ＿ｐｋｔ待ち
行列が空であるかどうかをテストすることにより、使用
中再試行ループの完了を検出するためにｂｕｓｙ＿ｌｏ
ｏｐ＿ｃｍｐｌｔ制御を設定するための再送信論理であ
る。
【００３０】図１９は、実行済み（ａｃｋ＿ｄｏｎｅ）
または使用中再試行を必要とするもの（ａｃｋ＿ｂｕｓ
ｙ）としてＳＳＯパケットを検出するための再送信論理
である。使用中再試行パケットはｒｅｔｒｙ＿ｐｋｔ待
ち行列に待ち行列化し、実行済みパケットはトランザク
ション層に通知する。
または使用中再試行を必要とするもの（ａｃｋ＿ｂｕｓ
ｙ）としてＳＳＯパケットを検出するための再送信論理
である。使用中再試行パケットはｒｅｔｒｙ＿ｐｋｔ待
ち行列に待ち行列化し、実行済みパケットはトランザク
ション層に通知する。
【００３１】図２０は、実行済み（ａｃｋ＿ｄｏｎｅ）
または使用中再試行を必要とするもの（ａｃｋ＿ｂｕｓ
ｙ）として非ＳＳＯパケットを検出するための再送信論
理である。使用中再試行パケットは再試行のためにＭＵ
Ｘにより送信し、実行済みパケットはトランザクション
層に通知する。
または使用中再試行を必要とするもの（ａｃｋ＿ｂｕｓ
ｙ）として非ＳＳＯパケットを検出するための再送信論
理である。使用中再試行パケットは再試行のためにＭＵ
Ｘにより送信し、実行済みパケットはトランザクション
層に通知する。
【００３２】図２１は、リングレット内で未解決のＳＳ
Ｏパケットが一切ない場合に使用中ループを設定し、再
試行送信ブロックによりｒｅｔｒｙ＿ｐｋｔ待ち行列か
らパケットを選択するようにＭＵＸを設定することによ
り使用中再試行ループを制御するための再試行送信論理
である。
Ｏパケットが一切ない場合に使用中ループを設定し、再
試行送信ブロックによりｒｅｔｒｙ＿ｐｋｔ待ち行列か
らパケットを選択するようにＭＵＸを設定することによ
り使用中再試行ループを制御するための再試行送信論理
である。
【００３３】図２２は、使用中再試行ループを開始する
か、応答待ち行列から応答パケットを選択するか、また
は要求待ち行列から要求パケットを選択するための条件
を検出するためのＭＵＸ論理である。
か、応答待ち行列から応答パケットを選択するか、また
は要求待ち行列から要求パケットを選択するための条件
を検出するためのＭＵＸ論理である。
【００３４】図２３は、要求待ち行列から要求を選択す
るようにＭＵＸを制御するためのＭＵＸ論理である。
るようにＭＵＸを制御するためのＭＵＸ論理である。
【００３５】図２４は、応答待ち行列から応答を選択す
るようにＭＵＸを制御するためのＭＵＸ論理である。
るようにＭＵＸを制御するためのＭＵＸ論理である。
【００３６】図２５は、制御をフォーマットし、シリア
ライザへのパケットの送信をゲートするためのＣＲＣ生
成論理である。
ライザへのパケットの送信をゲートするためのＣＲＣ生
成論理である。
【００３７】図２６は、より大比較（．ＧＴ．と示す）
とより小比較（．ＬＴ．と示す）を実行するための専用
モジュロ６４比較論理である。
とより小比較（．ＬＴ．と示す）を実行するための専用
モジュロ６４比較論理である。
【００３８】図２９〜３９の受信ノード用の流れ図の要
約は以下に示す。また、図２７の受信ノード論理も参照
する。
約は以下に示す。また、図２７の受信ノード論理も参照
する。
【００３９】この開示の拡張を理解するために、まず基
礎となる論理を理解しなければならない。図２７では、
ＳＳＯ順序付け拡張機能がない場合の受信ノードの基本
ブロックは、以下に示す削除および変更を伴うすべての
ブロックを含むものと思われる。 −ｓｅｑＴａｂｌｅ２６−３０を削除する −ｓｅｑ ｒｅｇｉｓｔｅｒ２６−４０を削除する −ｓｅｑ ｕｐｄａｔｅ２６−１２０を削除する その他のブロックは、ＳＳＯサポートを伴わない受信ノ
ードの動作にとって依然として基本的なものである。
礎となる論理を理解しなければならない。図２７では、
ＳＳＯ順序付け拡張機能がない場合の受信ノードの基本
ブロックは、以下に示す削除および変更を伴うすべての
ブロックを含むものと思われる。 −ｓｅｑＴａｂｌｅ２６−３０を削除する −ｓｅｑ ｒｅｇｉｓｔｅｒ２６−４０を削除する −ｓｅｑ ｕｐｄａｔｅ２６−１２０を削除する その他のブロックは、ＳＳＯサポートを伴わない受信ノ
ードの動作にとって依然として基本的なものである。
【００４０】受信ノードと送信ノードは、共通の名前が
付いた共通の構成要素をいくつか備えている。このよう
な構成要素は以下の通りである。 送信ノード 受信ノード デシリアライザ ７．２４０ ２６．８０ ８／１０デコード／ＣＲＣ検査 ７．２３０ ２６．７０ ｒｅｃ＿ｐｋｔレジスタ ７．２２０ ２６．６０ ａｃｋデコード論理 ７．１４０ ２６．１４０ ａｃｋ待ち行列 ７．１３０ ２６．１５０
付いた共通の構成要素をいくつか備えている。このよう
な構成要素は以下の通りである。 送信ノード 受信ノード デシリアライザ ７．２４０ ２６．８０ ８／１０デコード／ＣＲＣ検査 ７．２３０ ２６．７０ ｒｅｃ＿ｐｋｔレジスタ ７．２２０ ２６．６０ ａｃｋデコード論理 ７．１４０ ２６．１４０ ａｃｋ待ち行列 ７．１３０ ２６．１５０
【００４１】非ＳＳＯパケットの流れ 上記に示唆したように、本システムは、非ＳＳＯ環境ま
たは完全ＳＳＯ環境のいずれかで使用することができ
る。
たは完全ＳＳＯ環境のいずれかで使用することができ
る。
【００４２】基本的な（非ＳＳＯ）パケットの流れの説
明ならびにＳＳＯサポートのために追加された図面の概
要については以下の通りである。
明ならびにＳＳＯサポートのために追加された図面の概
要については以下の通りである。
【００４３】基本的なパケットの流れ、非ＳＳＯパケッ
ト ＳＳＯ順序付け論理の役割は、非ＳＳＯパケットに関す
る基本的なパケットの流れとの比較から理解することが
できる。図１０から始まり、ブロック９．１０、９．２
０、９．３０では、ＣＲＣ＿ｉｎｉｔ＿ｅｒｒ、ＣＲＣ
＿ｅｒｒ、ＣＲＣ＿ａｃｋ＿ｃｈｋからなるＣＲＣエラ
ー処理制御順序が活動状態である場合に通常のパケット
処理を禁止する。すべてのパケットが非ＳＳＯである場
合、パケットを非ＳＳＯとして識別するブロック９．５
０でパケット制御をブロック１１．１０に送る。
ト ＳＳＯ順序付け論理の役割は、非ＳＳＯパケットに関す
る基本的なパケットの流れとの比較から理解することが
できる。図１０から始まり、ブロック９．１０、９．２
０、９．３０では、ＣＲＣ＿ｉｎｉｔ＿ｅｒｒ、ＣＲＣ
＿ｅｒｒ、ＣＲＣ＿ａｃｋ＿ｃｈｋからなるＣＲＣエラ
ー処理制御順序が活動状態である場合に通常のパケット
処理を禁止する。すべてのパケットが非ＳＳＯである場
合、パケットを非ＳＳＯとして識別するブロック９．５
０でパケット制御をブロック１１．１０に送る。
【００４４】図１２は、基本的な非ＳＳＯエラー検出論
理を示しているが、肯定応答がパケットと一致するかど
うかを確認するためにｓｅｎｄ＿ｐｋｔ待ち行列のヘッ
ド（図８および図４０を参照）をａｃｋ待ち行列のヘッ
ドと比較するものである。（比較はブロック１１．１０
〜１１．４０で行われる。）パケットにエラーがある場
合、ブロック１１．５０は状態「ｅｒｒ＿ｒｅｔ」を設
定し、これをエラー・パケットとして通知する。エラー
がない場合、ブロック１１．６０は「使用中」状態と
「実行済み」状態を（ａｃｋ待ち行列９．１３０のヘッ
ドで）パケットの肯定応答から転送する。どちらの場合
もパケットはｎｏｎ＿ｏｒｄｅｒ＿ｒｅｇに書き込まれ
る。
理を示しているが、肯定応答がパケットと一致するかど
うかを確認するためにｓｅｎｄ＿ｐｋｔ待ち行列のヘッ
ド（図８および図４０を参照）をａｃｋ待ち行列のヘッ
ドと比較するものである。（比較はブロック１１．１０
〜１１．４０で行われる。）パケットにエラーがある場
合、ブロック１１．５０は状態「ｅｒｒ＿ｒｅｔ」を設
定し、これをエラー・パケットとして通知する。エラー
がない場合、ブロック１１．６０は「使用中」状態と
「実行済み」状態を（ａｃｋ待ち行列９．１３０のヘッ
ドで）パケットの肯定応答から転送する。どちらの場合
もパケットはｎｏｎ＿ｏｒｄｅｒ＿ｒｅｇに書き込まれ
る。
【００４５】ブロック９．１０には、非順序付けパケッ
ト用の再送信論理が記載されているが、ここではｎｏｎ
＿ｏｒｄｅｒ＿ｒｅｇの有効性がテストされる。有効で
ある場合、パケットはブロック９．２０で「実行済み」
状況があるかどうかがテストされ、９．５０で「実行済
み」状況がトランザクション層に送信される。パケット
が「使用中」であるかまたは「ｅｒｒ＿ｒｅｔ」状態が
設定されている場合、ブロック９．６０でｒｅｓｅｎｄ
＄のために４：１＿ｍｕｘが設定され、パケットはｓｅ
ｎｄ＿ｐｋｔレジスタに転送される。最後に、このブロ
ックでは非ＳＳＯパケット用の順序カウントが増分さ
れ、この再試行パケットに割り当てられる。
ト用の再送信論理が記載されているが、ここではｎｏｎ
＿ｏｒｄｅｒ＿ｒｅｇの有効性がテストされる。有効で
ある場合、パケットはブロック９．２０で「実行済み」
状況があるかどうかがテストされ、９．５０で「実行済
み」状況がトランザクション層に送信される。パケット
が「使用中」であるかまたは「ｅｒｒ＿ｒｅｔ」状態が
設定されている場合、ブロック９．６０でｒｅｓｅｎｄ
＄のために４：１＿ｍｕｘが設定され、パケットはｓｅ
ｎｄ＿ｐｋｔレジスタに転送される。最後に、このブロ
ックでは非ＳＳＯパケット用の順序カウントが増分さ
れ、この再試行パケットに割り当てられる。
【００４６】図２５では、ｓｅｎｄ＿ｐｋｔレジスタが
ブロック２４．１０で有効性がテストされ、次にブロッ
ク２４．３０でＣＲＣ生成に転送される。ｐＬａｂｅｌ
フィールドは、これが非ＳＳＯパケットであるという事
実と、同じブロック２４．３０内の割当て済み「ｓｅ
ｑ」フィールドによって定義される。また、このパケッ
トは、もう一度ｓｅｎｄ＿ｐｋｔ待ち行列内に待ち行列
化され、肯定応答パケットを待つ。
ブロック２４．１０で有効性がテストされ、次にブロッ
ク２４．３０でＣＲＣ生成に転送される。ｐＬａｂｅｌ
フィールドは、これが非ＳＳＯパケットであるという事
実と、同じブロック２４．３０内の割当て済み「ｓｅ
ｑ」フィールドによって定義される。また、このパケッ
トは、もう一度ｓｅｎｄ＿ｐｋｔ待ち行列内に待ち行列
化され、肯定応答パケットを待つ。
【００４７】流れ図はパケットの到着から始まるが、パ
ケットは何らかの優先順位プロセスによって選択された
ものであると想定する。非ＳＳＯシステムでは、この優
先順位は本発明のシステムのものと同様になる可能性が
あるが、「使用中」および「ｒｅｔｒｙ＿ｐｋｔ待ち行
列」への参照はすべて除去されるはずである。非ＳＳＯ
システム内のそれぞれの待ち行列からの要求または応答
パケットの選択は図２３および図２４に示すものと同様
になるはずである。
ケットは何らかの優先順位プロセスによって選択された
ものであると想定する。非ＳＳＯシステムでは、この優
先順位は本発明のシステムのものと同様になる可能性が
あるが、「使用中」および「ｒｅｔｒｙ＿ｐｋｔ待ち行
列」への参照はすべて除去されるはずである。非ＳＳＯ
システム内のそれぞれの待ち行列からの要求または応答
パケットの選択は図２３および図２４に示すものと同様
になるはずである。
【００４８】ＳＳＯサポートのための論理追加 図１０〜１６の流れ図に示す残りのａｃｋ論理は、ＳＳ
Ｏ順序付けブロックを処理するための拡張機能を示して
いる。
Ｏ順序付けブロックを処理するための拡張機能を示して
いる。
【００４９】ただし、ブロック１２．２０、１３．２
０、１４．２０、１５．２０は、ｓｅｎｄ＿ｐｋｔ待ち
行列内の非ＳＳＯ送信コマンドも識別し（図４０を参
照）、非ＳＳＯパケット処理ブロック１１．１０へ分岐
することに留意されたい。しかし、このようなブロック
は、ＳＳＯと非ＳＳＯの両方のコマンドの混合プログラ
ミング環境をサポートする機能を備えたシステム内の非
ＳＳＯパケットの処理を包含する。すなわち、これらの
ブロックは、基本的な非ＳＳＯ専用環境の一部ではない
のである。
０、１４．２０、１５．２０は、ｓｅｎｄ＿ｐｋｔ待ち
行列内の非ＳＳＯ送信コマンドも識別し（図４０を参
照）、非ＳＳＯパケット処理ブロック１１．１０へ分岐
することに留意されたい。しかし、このようなブロック
は、ＳＳＯと非ＳＳＯの両方のコマンドの混合プログラ
ミング環境をサポートする機能を備えたシステム内の非
ＳＳＯパケットの処理を包含する。すなわち、これらの
ブロックは、基本的な非ＳＳＯ専用環境の一部ではない
のである。
【００５０】同様に、再送信論理ブロック内の非ＳＳＯ
パケットの処理についても、図１０の単一ページに示
す。図１７〜２０に示す再送信論理はＳＳＯサポートの
ために追加されたものである。再試行処理論理である図
２１も、ＳＳＯ処理論理に固有のものである。
パケットの処理についても、図１０の単一ページに示
す。図１７〜２０に示す再送信論理はＳＳＯサポートの
ために追加されたものである。再試行処理論理である図
２１も、ＳＳＯ処理論理に固有のものである。
【００５１】使用中ループ（２１．９０に設定されてい
る）を開始するための図２２に示すＭＵＸ論理は、ＳＳ
Ｏサポートを備えた実施態様に固有のものである。他の
論理は要求または応答パケットを選択するものであり、
ＳＳＯと非ＳＳＯのどちらの実施態様の場合にも同様の
ものになるはずである。図２３および図２４に示す要求
または応答パケットを開始するためのＭＵＸ論理は、Ｓ
ＳＯと非ＳＳＯのどちらの実施態様の場合にも同様のも
のになるはずである。
る）を開始するための図２２に示すＭＵＸ論理は、ＳＳ
Ｏサポートを備えた実施態様に固有のものである。他の
論理は要求または応答パケットを選択するものであり、
ＳＳＯと非ＳＳＯのどちらの実施態様の場合にも同様の
ものになるはずである。図２３および図２４に示す要求
または応答パケットを開始するためのＭＵＸ論理は、Ｓ
ＳＯと非ＳＳＯのどちらの実施態様の場合にも同様のも
のになるはずである。
【００５２】最後に、図２５のＣＲＣ生成論理は、２
４．４０で「ｎｏ＿ｘｍｉｔ」状態ビットをテストし、
パケットを逐次化論理に転送すべきかどうかを判定す
る。このようなゲートはＳＳＯサポートのために固有の
ものである。モジュロ６４比較をサポートする論理も、
ＳＳＯサポートのために明確に必要なものである。
４．４０で「ｎｏ＿ｘｍｉｔ」状態ビットをテストし、
パケットを逐次化論理に転送すべきかどうかを判定す
る。このようなゲートはＳＳＯサポートのために固有の
ものである。モジュロ６４比較をサポートする論理も、
ＳＳＯサポートのために明確に必要なものである。
【００５３】図２７のブロック図の概要 図２７は、図８および図４０のように、受信ノード（送
信ノードは図７）の潜在的なブロック図であり、ＳＳＯ
メカニズムの概念を実施する方法を示すために使用する
ものである。これは、このメカニズムの概念を実施する
受信（送信）ノードの数多くの可能な実例の１つにすぎ
ないことが分かっている。
信ノードは図７）の潜在的なブロック図であり、ＳＳＯ
メカニズムの概念を実施する方法を示すために使用する
ものである。これは、このメカニズムの概念を実施する
受信（送信）ノードの数多くの可能な実例の１つにすぎ
ないことが分かっている。
【００５４】図２７内のパケットの流れは基本的に以下
の通りである。−パケットは、リングレット２６．９０
からデシリアライザ２６．８０を通って受信ノードに入
る。ＣＲＣ検査と８／１０デコード論理２６．７０は非
パケット記号を取り除き、パケットを３２ビットのｒｅ
ｃ＿ｐｋｔレジスタ２６．６０にロードする。 −パケットの先頭が検出され、このレジスタ内で初期パ
ケットデコードが行われる。受信ノードが使用するパケ
ットは以下のものを含む。 −このノードにアドレス指定された送信パケット（要求
および応答） −他のノードにアドレス指定された送信パケット（要求
および応答） −他のノードにアドレス指定された肯定応答パケット このノードにアドレス指定された送信パケットには、ｒ
ｅｑｕｅｓｔ＿ｉｎ待ち行列（要求パケット）またはｒ
ｅｓｐｏｎｓｅ＿ｉｎ待ち行列（応答パケット）にそれ
ぞれ待ち行列化するためにマークが付けられる。（注：
待ち行列の使用）このノードへの肯定応答はデコードさ
れ、ａｃｋ待ち行列２６．１５０に書き込まれる。 −受信ノード・パケットはｔｅｓｔ＿ｐｋｔノードに書
き込まれる。パケットの先頭がｔｅｓｔ＿ｐｋｔレジス
タ内にある場合、ｐｒｏｄｕｃｅｒＩｄを含む３２ビッ
トがｒｅｃ＿ｐｋｔレジスタ内に入ってる。順序フィー
ルドおよび受入れフィールドを順序付けするなど、この
フィールドは受信ノード状態用のｓｅｃＴａｂｌｅアレ
イにインデックスを付ける。 −次のサイクルでは、ｓｅｑＴａｂｌｅ［ｐｒｏｄｕｃ
ｅｒＩｄ］の内容がｓｅｑレジスタ２６．４０に読み込
まれ、ｐＬａｂｅｌフィールドとｐｒｏｄｕｃｅｒＩｄ
フィールドはｔｅｓｔ＿ｐｋｔレジスタ２６．５０内に
入る。これに対応するフィールドは、受信ノード内のす
べてのパケット（送信パケットおよび肯定応答）につい
て以下のブロックで比較される。ただし、パケット処理
のタイミングは以下のようにパケットのタイプによって
決まる。 −ａｃｐｔ論理２６．１３０は、基本的に、このノード
にアドレス指定された要求および応答パケットが受け入
れられるかどうかを判定する。ｓｅｑＴａｂｌｅおよび
ＣＲＣエラー検査の両方が検討される。 −ｓｅｑ更新論理２６．１２０は、パケットの末尾でｓ
ｅｑＴａｂｌｅアレイ状態が更新されるかどうかと、そ
の更新方法を判定する。 −ａｃｋ ｇｅｎ論理２６．１１０は、ａｃｋ実行済
み、使用中、またはエラーのうち、どの種類（ＣＲＣエ
ラー検出時に禁止されるもの）の肯定応答が生成される
かを判定する。 −パケットの残りの部分が処理され（送信パケットの場
合）、送信パケット・データはｒｅｑｕｅｓｔ＿ｉｎ
（２６．１０）またはｒｅｓｐｏｎｓｅ＿ｉｎ（２６．
２０）待ち行列内に待ち行列化される。ただし、待ち行
列空間が使用可能である場合に限る。パケットが終了す
ると、ＣＲＣ検査は送信ノードのための動作を完了す
る。
の通りである。−パケットは、リングレット２６．９０
からデシリアライザ２６．８０を通って受信ノードに入
る。ＣＲＣ検査と８／１０デコード論理２６．７０は非
パケット記号を取り除き、パケットを３２ビットのｒｅ
ｃ＿ｐｋｔレジスタ２６．６０にロードする。 −パケットの先頭が検出され、このレジスタ内で初期パ
ケットデコードが行われる。受信ノードが使用するパケ
ットは以下のものを含む。 −このノードにアドレス指定された送信パケット（要求
および応答） −他のノードにアドレス指定された送信パケット（要求
および応答） −他のノードにアドレス指定された肯定応答パケット このノードにアドレス指定された送信パケットには、ｒ
ｅｑｕｅｓｔ＿ｉｎ待ち行列（要求パケット）またはｒ
ｅｓｐｏｎｓｅ＿ｉｎ待ち行列（応答パケット）にそれ
ぞれ待ち行列化するためにマークが付けられる。（注：
待ち行列の使用）このノードへの肯定応答はデコードさ
れ、ａｃｋ待ち行列２６．１５０に書き込まれる。 −受信ノード・パケットはｔｅｓｔ＿ｐｋｔノードに書
き込まれる。パケットの先頭がｔｅｓｔ＿ｐｋｔレジス
タ内にある場合、ｐｒｏｄｕｃｅｒＩｄを含む３２ビッ
トがｒｅｃ＿ｐｋｔレジスタ内に入ってる。順序フィー
ルドおよび受入れフィールドを順序付けするなど、この
フィールドは受信ノード状態用のｓｅｃＴａｂｌｅアレ
イにインデックスを付ける。 −次のサイクルでは、ｓｅｑＴａｂｌｅ［ｐｒｏｄｕｃ
ｅｒＩｄ］の内容がｓｅｑレジスタ２６．４０に読み込
まれ、ｐＬａｂｅｌフィールドとｐｒｏｄｕｃｅｒＩｄ
フィールドはｔｅｓｔ＿ｐｋｔレジスタ２６．５０内に
入る。これに対応するフィールドは、受信ノード内のす
べてのパケット（送信パケットおよび肯定応答）につい
て以下のブロックで比較される。ただし、パケット処理
のタイミングは以下のようにパケットのタイプによって
決まる。 −ａｃｐｔ論理２６．１３０は、基本的に、このノード
にアドレス指定された要求および応答パケットが受け入
れられるかどうかを判定する。ｓｅｑＴａｂｌｅおよび
ＣＲＣエラー検査の両方が検討される。 −ｓｅｑ更新論理２６．１２０は、パケットの末尾でｓ
ｅｑＴａｂｌｅアレイ状態が更新されるかどうかと、そ
の更新方法を判定する。 −ａｃｋ ｇｅｎ論理２６．１１０は、ａｃｋ実行済
み、使用中、またはエラーのうち、どの種類（ＣＲＣエ
ラー検出時に禁止されるもの）の肯定応答が生成される
かを判定する。 −パケットの残りの部分が処理され（送信パケットの場
合）、送信パケット・データはｒｅｑｕｅｓｔ＿ｉｎ
（２６．１０）またはｒｅｓｐｏｎｓｅ＿ｉｎ（２６．
２０）待ち行列内に待ち行列化される。ただし、待ち行
列空間が使用可能である場合に限る。パケットが終了す
ると、ＣＲＣ検査は送信ノードのための動作を完了す
る。
【００５５】図２８Ａおよび図２８Ｂは、受信パケット
と肯定応答のタイミング図をそれぞれ示している。受信
ノード論理については、図２９以降に示し、以下に説明
する。
と肯定応答のタイミング図をそれぞれ示している。受信
ノード論理については、図２９以降に示し、以下に説明
する。
【００５６】図２９では、ｒｅｃ＿ｐｋｔ＿ｒｅｇ２
６．６０内のヘッダ・フィールドから送信パケット（ま
たは「コマンド」）または肯定応答パケットの先頭を検
出する（図２７を参照）。送信パケットの場合、このノ
ードにアドレス指定された要求または応答のいずれかに
より、ｒｅｑｕｅｓｔ＿ｉｎ待ち行列２６．１０とｒｅ
ｓｐｏｎｓｅ＿ｉｎ待ち行列２６．２０という対応する
入力待ち行列内に待ち行列空間が存在するかどうかをテ
ストし、それに応じて制御ビットが設定される。
６．６０内のヘッダ・フィールドから送信パケット（ま
たは「コマンド」）または肯定応答パケットの先頭を検
出する（図２７を参照）。送信パケットの場合、このノ
ードにアドレス指定された要求または応答のいずれかに
より、ｒｅｑｕｅｓｔ＿ｉｎ待ち行列２６．１０とｒｅ
ｓｐｏｎｓｅ＿ｉｎ待ち行列２６．２０という対応する
入力待ち行列内に待ち行列空間が存在するかどうかをテ
ストし、それに応じて制御ビットが設定される。
【００５７】図３０では、ｓｅｑＴａｂｌｅアレイ２
６．３０をｓｅｑ＿ｒｅｇ２６．４０に読み込む。ｒｅ
ｑｕｅｓｔ＿ｉｎ待ち行列２６．１０またはｒｅｓｐｏ
ｎｓｅ＿ｉｎ待ち行列２６．２０内のパケットの妥当性
検査を禁止するための条件の有無をテストする。
６．３０をｓｅｑ＿ｒｅｇ２６．４０に読み込む。ｒｅ
ｑｕｅｓｔ＿ｉｎ待ち行列２６．１０またはｒｅｓｐｏ
ｎｓｅ＿ｉｎ待ち行列２６．２０内のパケットの妥当性
検査を禁止するための条件の有無をテストする。
【００５８】図３１では、待ち行列空間が使用可能であ
ることを制御ビットが示す場合、このノードにアドレス
指定されたパケットの残りの部分を対応する待ち行列、
すなわち、ｒｅｑｕｅｓｔ＿ｉｎ２６．１０またはｒｅ
ｓｐｏｎｓｅ＿ｉｎ２６．２０内に仮に待ち行列化す
る。制御フィールドを増分するかまたは制御ビットをリ
セットするための条件が与えられる。
ることを制御ビットが示す場合、このノードにアドレス
指定されたパケットの残りの部分を対応する待ち行列、
すなわち、ｒｅｑｕｅｓｔ＿ｉｎ２６．１０またはｒｅ
ｓｐｏｎｓｅ＿ｉｎ２６．２０内に仮に待ち行列化す
る。制御フィールドを増分するかまたは制御ビットをリ
セットするための条件が与えられる。
【００５９】図３２では、このノードにアドレス指定さ
れた送信パケットの末尾で、ＣＲＣ検査に応じて、送信
ノードへ肯定応答パケットを生成し、ｒｅｑｕｅｓｔ＿
ｉｎ待ち行列２６．１０またはｒｅｓｐｏｎｓｅ＿ｉｎ
待ち行列２６．２０内のパケットを妥当性検査する。
れた送信パケットの末尾で、ＣＲＣ検査に応じて、送信
ノードへ肯定応答パケットを生成し、ｒｅｑｕｅｓｔ＿
ｉｎ待ち行列２６．１０またはｒｅｓｐｏｎｓｅ＿ｉｎ
待ち行列２６．２０内のパケットを妥当性検査する。
【００６０】図３３では、ＣＲＣエラー検査に応じて、
図３２での肯定応答生成に使用するために仮の肯定応答
条件（実行済み、使用中、またはエラー）を生成する。
図３２での肯定応答生成に使用するために仮の肯定応答
条件（実行済み、使用中、またはエラー）を生成する。
【００６１】図３４では、有効順序を備えたＳＳＯパケ
ット用の仮の肯定応答生成（実行済み、使用中、または
エラー）を続行する。
ット用の仮の肯定応答生成（実行済み、使用中、または
エラー）を続行する。
【００６２】図３５では、パケットの終了時にｓｅｑＴ
ａｂｌｅアレイ用の更新条件を仮に設定するかまたは更
新を禁止するための条件の有無をテストする。更新は、
有効ＣＲＣ検査によって決まる。
ａｂｌｅアレイ用の更新条件を仮に設定するかまたは更
新を禁止するための条件の有無をテストする。更新は、
有効ＣＲＣ検査によって決まる。
【００６３】図３６では、パケットが有効順序で順序付
けされたＳＳＯである場合に仮の順序更新生成を続行す
る。
けされたＳＳＯである場合に仮の順序更新生成を続行す
る。
【００６４】図３７では、送信パケットの終了時に、２
６．７０内に有効ＣＲＣがあるかどうかをテストする。
ＣＲＣが有効であり、ｓｅｑＴａｂｌｅ書込みが禁止さ
れていない場合、ｓｅｑＴａｂｌｅを更新する。
６．７０内に有効ＣＲＣがあるかどうかをテストする。
ＣＲＣが有効であり、ｓｅｑＴａｂｌｅ書込みが禁止さ
れていない場合、ｓｅｑＴａｂｌｅを更新する。
【００６５】図３８では、他のノードにアドレス指定さ
れた肯定応答パケット用のｓｅｑＴａｂｌｅ更新フィー
ルドを生成する。
れた肯定応答パケット用のｓｅｑＴａｂｌｅ更新フィー
ルドを生成する。
【００６６】図３９では、パケットが有効順序で順序付
けされたＳＳＯである場合に他のノードにアドレス指定
された肯定応答パケット用のｓｅｑＴａｂｌｅ更新フィ
ールドの生成を続行する。
けされたＳＳＯである場合に他のノードにアドレス指定
された肯定応答パケット用のｓｅｑＴａｂｌｅ更新フィ
ールドの生成を続行する。
【００６７】図４０以降の例は、本発明のシステムの動
作例を実証するものであり、これらの図に示す状態およ
びアクションは上記の図の論理に適合するものである。
図４０以降は、レジスタおよび待ち行列間のパケットの
転送ごとの作成側ノードの状態をステップごとに示し、
これらの図を検査することにより、本システムが使用中
再試行ループおよび挙動不良のノードに関連してエラー
が発生した場合のＳＳＯ非アイデンポテントコマンドに
対応していることが分かる。
作例を実証するものであり、これらの図に示す状態およ
びアクションは上記の図の論理に適合するものである。
図４０以降は、レジスタおよび待ち行列間のパケットの
転送ごとの作成側ノードの状態をステップごとに示し、
これらの図を検査することにより、本システムが使用中
再試行ループおよび挙動不良のノードに関連してエラー
が発生した場合のＳＳＯ非アイデンポテントコマンドに
対応していることが分かる。
【００６８】各図の論理図／流れ図を見ると、様々な状
態が示されている。これらについては以下に定義する。
さらに、本明細書に付属の付録Ａには、現行設計に関連
して使用する用語集および変数が記載されている。 状態 解釈 ｉ ｉｎ＿ｐｒｏｃ ｂ 使用中（変形：ａｃｋ＿ｂｕｓｙ、使用中ループ再試行） ｒ ＣＲＣループ内の再試行 ｂ１ 使用中再試行ループ内の第１のパケット ｒ１ ＣＲＣ再試行ループ内の第１のパケット ｘ ａｃｋまたは使用中のいずれか ｄ ａｃｋ＿ｄｏｎｅ ＢＲＣ 使用中再送信ループ ＣＲＣ ＣＲＣエラー再送信ループ ＳＲＬ ｓｅｎｄ＿ｐｋｔ再循環ループ
態が示されている。これらについては以下に定義する。
さらに、本明細書に付属の付録Ａには、現行設計に関連
して使用する用語集および変数が記載されている。 状態 解釈 ｉ ｉｎ＿ｐｒｏｃ ｂ 使用中（変形：ａｃｋ＿ｂｕｓｙ、使用中ループ再試行） ｒ ＣＲＣループ内の再試行 ｂ１ 使用中再試行ループ内の第１のパケット ｒ１ ＣＲＣ再試行ループ内の第１のパケット ｘ ａｃｋまたは使用中のいずれか ｄ ａｃｋ＿ｄｏｎｅ ＢＲＣ 使用中再送信ループ ＣＲＣ ＣＲＣエラー再送信ループ ＳＲＬ ｓｅｎｄ＿ｐｋｔ再循環ループ
【００６９】１３９４．２規格案を考慮した本発明の好
ましい実施形態の説明 ＩＥＥＥ Ｐ１３９４．２に基づくリングレット・トポ
ロジで完全パイプライン化されたパケット開始をサポー
トするためのメカニズム案の概要および要約を以下に示
す。この場合、パイプライン化パケットは、強力順次順
序付け（ＳＳＯ）と非アイデンポテント・コマンドのサ
ポートを必要とするアドレス空間からの送信パケットお
よび応答パケットを含むことができる。このメカニズム
は、トポロジ内のすべての通信リンクが順にＳＳＯ順序
付けを維持することを確認することによって、任意のＰ
１３９４．２スイッチ・トポロジにより拡張することが
できる。
ましい実施形態の説明 ＩＥＥＥ Ｐ１３９４．２に基づくリングレット・トポ
ロジで完全パイプライン化されたパケット開始をサポー
トするためのメカニズム案の概要および要約を以下に示
す。この場合、パイプライン化パケットは、強力順次順
序付け（ＳＳＯ）と非アイデンポテント・コマンドのサ
ポートを必要とするアドレス空間からの送信パケットお
よび応答パケットを含むことができる。このメカニズム
は、トポロジ内のすべての通信リンクが順にＳＳＯ順序
付けを維持することを確認することによって、任意のＰ
１３９４．２スイッチ・トポロジにより拡張することが
できる。
【００７０】このメカニズム案は、非使用中非エラー・
パケット送信のために完全パイプライン化動作モードで
ＳＳＯおよび非アイデンポテントコマンドをサポート
し、効率のよいハードウェア再試行メカニズムによりＣ
ＲＣエラーと受信側使用中条件の両方を許容する。これ
は、再試行した使用中パケットと新しいパケットとを混
合するために様々な再送信方針をサポートする。ＣＲＣ
エラー・パケットはプログラム可能な限界まで再試行す
ることができるので、これは「訂正可能エラー」の類の
エラー処理方針を使用可能にする。この機能により、Ｃ
ＲＣエラー・パケットの正常な再試行動作を報告するノ
ード用の「予防保守」機能が可能になる。
パケット送信のために完全パイプライン化動作モードで
ＳＳＯおよび非アイデンポテントコマンドをサポート
し、効率のよいハードウェア再試行メカニズムによりＣ
ＲＣエラーと受信側使用中条件の両方を許容する。これ
は、再試行した使用中パケットと新しいパケットとを混
合するために様々な再送信方針をサポートする。ＣＲＣ
エラー・パケットはプログラム可能な限界まで再試行す
ることができるので、これは「訂正可能エラー」の類の
エラー処理方針を使用可能にする。この機能により、Ｃ
ＲＣエラー・パケットの正常な再試行動作を報告するノ
ード用の「予防保守」機能が可能になる。
【００７１】また、ブリッジ内でＳＳＯの非アイデンポ
テント機能を使用すると、より大きい（＞６４Ｂ）パケ
ット・フォーマットを有する他のプロトコルとＩＥＥＥ
Ｐ１３９４．２との間のブリッジの設計が大幅に単純
化されることも留意されたい。たとえば、ＩＥＥＥ１３
９４−１９９５ノードからの２ＫＢブロック分の書込み
コマンドは、その終了時に受信側ノードから単一応答パ
ケットを予期するが、一連の移動コマンド（応答なし）
と終了書込みとして実施することができ、ＩＥＥＥ１３
９４−１９９５パケットの動作がブリッジ上で保持され
ることを保証する。
テント機能を使用すると、より大きい（＞６４Ｂ）パケ
ット・フォーマットを有する他のプロトコルとＩＥＥＥ
Ｐ１３９４．２との間のブリッジの設計が大幅に単純
化されることも留意されたい。たとえば、ＩＥＥＥ１３
９４−１９９５ノードからの２ＫＢブロック分の書込み
コマンドは、その終了時に受信側ノードから単一応答パ
ケットを予期するが、一連の移動コマンド（応答なし）
と終了書込みとして実施することができ、ＩＥＥＥ１３
９４−１９９５パケットの動作がブリッジ上で保持され
ることを保証する。
【００７２】ＳＳＯ順序付けのコストは、リングレット
上でサポートされるノード当たり２バイト分の状態と、
状態マシン、非ＳＳＯパケット用の個別のレジスタ、Ｍ
ＵＸ、６ビットの比較器である。流れの説明は、より複
雑なアレイ構造ではなく、単純なＦＩＦＯ待ち行列およ
びレジスタに基づいて示す。リングレット用の最大構成
は６３ノードなので、これにより、最大１２８ＢまでＳ
ＳＯ（ならびにポインタと状態マシン）をサポートする
ために必要な状態が制限される。サポートする構成がよ
り小さい場合、その構成の「プロファイル」は、サポー
トするリングレット・ノード・カウントを切り詰めるこ
とにより、コストをさらに削減することができる。
上でサポートされるノード当たり２バイト分の状態と、
状態マシン、非ＳＳＯパケット用の個別のレジスタ、Ｍ
ＵＸ、６ビットの比較器である。流れの説明は、より複
雑なアレイ構造ではなく、単純なＦＩＦＯ待ち行列およ
びレジスタに基づいて示す。リングレット用の最大構成
は６３ノードなので、これにより、最大１２８ＢまでＳ
ＳＯ（ならびにポインタと状態マシン）をサポートする
ために必要な状態が制限される。サポートする構成がよ
り小さい場合、その構成の「プロファイル」は、サポー
トするリングレット・ノード・カウントを切り詰めるこ
とにより、コストをさらに削減することができる。
【００７３】ＩＥＥＥ Ｐ１３９４．２の簡単な概要 ＩＥＥＥ Ｐ１３９４．２すなわちシリアル・エクスプ
レスは、ＩＥＥＥ１３９４−１９９５すなわちシリアル
・バスをギガビット＋伝送レベルまで拡張するという提
案である。基本的に、このプロトコルは、ＩＥＥＥ１３
９４−１９９５の基本コマンド・セットをサポートしな
がら、１６Ｂのパケットおよび６４Ｂパケットにより待
ち時間の低さとスループットの高さを強調するために転
送プロトコルを再設計するものである。
レスは、ＩＥＥＥ１３９４−１９９５すなわちシリアル
・バスをギガビット＋伝送レベルまで拡張するという提
案である。基本的に、このプロトコルは、ＩＥＥＥ１３
９４−１９９５の基本コマンド・セットをサポートしな
がら、１６Ｂのパケットおよび６４Ｂパケットにより待
ち時間の低さとスループットの高さを強調するために転
送プロトコルを再設計するものである。
【００７４】ＩＥＥＥ Ｐ１３９４．２は、リングレッ
ト・トポロジを備えた挿入バッファ・アーキテクチャに
基づくものである。これが意味するのは、各ノードが２
本の単一方向ワイヤを含み、一方は着信パケットおよび
アイドル（同期およびフロー制御用）向けであり、もう
一方は発信パケットおよびアイドル向けであるというこ
とである。バイパス・バッファは、着信パケットおよび
アイドルを発信ワイヤ上にそらし、おそらく遅延が発生
する。単一の新しい送信または応答パケット（以下に定
義する）は、そのバイパス・バッファが一杯ではない場
合にノードによってリングレット内に挿入することがで
きる。これは「挿入バッファ」アーキテクチャである。
ノードが新しいパケットを挿入している間にバイパス・
バッファに入るパケットは、新しいパケットが送信され
るまで遅延される。パケット・サイズが小さいので（＜
＝６４Ｂ）、このアーキテクチャが可能になるとともに
効率のよいものになっている。
ト・トポロジを備えた挿入バッファ・アーキテクチャに
基づくものである。これが意味するのは、各ノードが２
本の単一方向ワイヤを含み、一方は着信パケットおよび
アイドル（同期およびフロー制御用）向けであり、もう
一方は発信パケットおよびアイドル向けであるというこ
とである。バイパス・バッファは、着信パケットおよび
アイドルを発信ワイヤ上にそらし、おそらく遅延が発生
する。単一の新しい送信または応答パケット（以下に定
義する）は、そのバイパス・バッファが一杯ではない場
合にノードによってリングレット内に挿入することがで
きる。これは「挿入バッファ」アーキテクチャである。
ノードが新しいパケットを挿入している間にバイパス・
バッファに入るパケットは、新しいパケットが送信され
るまで遅延される。パケット・サイズが小さいので（＜
＝６４Ｂ）、このアーキテクチャが可能になるとともに
効率のよいものになっている。
【００７５】パケット・フォーマットは、パケット経路
指定用の１６ビットのフィールドと、４８ビットの拡張
アドレスとを含む。各ノードは、別々の送信パスと受信
パスとを備えた単一ケーブルによる全二重動作をサポー
トする。複数のノード（最高６３個まで）が相互接続さ
れている場合、初期設定ソフトウェアにより冗長ループ
が切断され、これらのノードが単一リングレットとして
構成される。複数のリングレット（接続部はわずか２カ
所）は、１６Ｋノードからなる最大トポロジまでスイッ
チによって相互接続することができる。
指定用の１６ビットのフィールドと、４８ビットの拡張
アドレスとを含む。各ノードは、別々の送信パスと受信
パスとを備えた単一ケーブルによる全二重動作をサポー
トする。複数のノード（最高６３個まで）が相互接続さ
れている場合、初期設定ソフトウェアにより冗長ループ
が切断され、これらのノードが単一リングレットとして
構成される。複数のリングレット（接続部はわずか２カ
所）は、１６Ｋノードからなる最大トポロジまでスイッ
チによって相互接続することができる。
【００７６】ＩＥＥＥ Ｐ１３９４．２プロトコルは、
２通りのアドレス・モード（有向およびマルチキャス
ト）と２通りのサービス・タイプ（非同期および等時
性）に基づいて、４通りの動作モードをサポートする。
ＳＳＯ順序付けは、非同期有向サービスに関して特定の
利害があるものであり、（読取り、書込み、移動、ロッ
ク）諸動作を含むが、このメカニズム案はこのサービス
・モードのみに限定されない。
２通りのアドレス・モード（有向およびマルチキャス
ト）と２通りのサービス・タイプ（非同期および等時
性）に基づいて、４通りの動作モードをサポートする。
ＳＳＯ順序付けは、非同期有向サービスに関して特定の
利害があるものであり、（読取り、書込み、移動、ロッ
ク）諸動作を含むが、このメカニズム案はこのサービス
・モードのみに限定されない。
【００７７】ＳＳＯ順序付け：発行 ＳＳＯ順序付けサポートがない場合、任意のノードから
任意の宛先へのパケットには相互に関する制約が一切な
い。ＣＲＣエラーと受信側使用中の両方に対処する場
合、これは、２つのパケットが送信されたときとは異な
る順序で宛先ノードに到着する可能性があることを意味
する。
任意の宛先へのパケットには相互に関する制約が一切な
い。ＣＲＣエラーと受信側使用中の両方に対処する場
合、これは、２つのパケットが送信されたときとは異な
る順序で宛先ノードに到着する可能性があることを意味
する。
【００７８】この不確実性は、ネットワーク化環境を代
表するものであり、様々なソフトウェアベースのプロト
コルを使用して処理される。たとえば、従来のデータ・
パケットを伴う割込み生成書込み要求を逐次化するため
にＩＥＥＥ１３９４−１９９５で使用可能な信頼できる
メカニズムの１つは、たとえば２ＫＢの大きいパケット
用の書込みコマンド（宛先からの応答を要するもの）を
送信し、次にそのデータに関する応答が戻ってきた後で
割込みを生成するために書込みコマンドを送信すること
である。
表するものであり、様々なソフトウェアベースのプロト
コルを使用して処理される。たとえば、従来のデータ・
パケットを伴う割込み生成書込み要求を逐次化するため
にＩＥＥＥ１３９４−１９９５で使用可能な信頼できる
メカニズムの１つは、たとえば２ＫＢの大きいパケット
用の書込みコマンド（宛先からの応答を要するもの）を
送信し、次にそのデータに関する応答が戻ってきた後で
割込みを生成するために書込みコマンドを送信すること
である。
【００７９】このようなメカニズムは、かなり小さい
（＜＝６４Ｂ）パケットを備えたドメイン、すなわち、
低待ち時間転送を強調するドメインに拡張されると、複
雑かつ効率の悪いものになる可能性がある。順序付けと
データ転送完了をともに確立するためのソフトウェア・
オーバヘッドにより、使用可能な計算サイクルが減少
し、ユーザ・プロセスが、すなわちユーザ・プロセス待
ち時間が直接増加する。
（＜＝６４Ｂ）パケットを備えたドメイン、すなわち、
低待ち時間転送を強調するドメインに拡張されると、複
雑かつ効率の悪いものになる可能性がある。順序付けと
データ転送完了をともに確立するためのソフトウェア・
オーバヘッドにより、使用可能な計算サイクルが減少
し、ユーザ・プロセスが、すなわちユーザ・プロセス待
ち時間が直接増加する。
【００８０】Ｐ１３９４．２によるＳＳＯ拡張 ＳＳＯ拡張案は、リングレットの動作に関する上記の基
本的な前提事項によって決まる。
本的な前提事項によって決まる。
【００８１】（非同期、有向）モードの各コマンドは、
送信パケットを生成する発信側（送信側）ノードと、そ
のコマンドに応じて応答パケットを生成する（可能性の
ある）最終宛先ノードとによって実行される。「送信」
パケットは、送信側のローカル・リングレット上の単一
受信側ノードによって除去され、そのローカル受信側ノ
ードから送信ノードに戻る「肯定応答」パケットに置き
換えられる。ローカル受信側ノードは、送信パケット用
の最終宛先である場合もあれば、おそらくスイッチによ
りその宛先にパケットを転送するエージェントである場
合もある。コマンドのタイプに応じて、最終宛先ノード
は「応答」パケットを送信することができ、その「応
答」パケットはそのローカル・リングレット上の何らか
のノードによって捕捉され、「応答」発生側に戻る「肯
定応答」パケットによって置き換えられる。
送信パケットを生成する発信側（送信側）ノードと、そ
のコマンドに応じて応答パケットを生成する（可能性の
ある）最終宛先ノードとによって実行される。「送信」
パケットは、送信側のローカル・リングレット上の単一
受信側ノードによって除去され、そのローカル受信側ノ
ードから送信ノードに戻る「肯定応答」パケットに置き
換えられる。ローカル受信側ノードは、送信パケット用
の最終宛先である場合もあれば、おそらくスイッチによ
りその宛先にパケットを転送するエージェントである場
合もある。コマンドのタイプに応じて、最終宛先ノード
は「応答」パケットを送信することができ、その「応
答」パケットはそのローカル・リングレット上の何らか
のノードによって捕捉され、「応答」発生側に戻る「肯
定応答」パケットによって置き換えられる。
【００８２】以下の説明では、そのノードが送信パケッ
トを開始する送信側ノードであるか、応答パケットを開
始する受信側ノードであるか、送信パケットまたは応答
パケットを転送するブリッジまたはスイッチ・ノードで
あるかにかかわらず、パケットを開始したノードを示す
ために「作成側ノード」という用語を使用する場合もあ
る。
トを開始する送信側ノードであるか、応答パケットを開
始する受信側ノードであるか、送信パケットまたは応答
パケットを転送するブリッジまたはスイッチ・ノードで
あるかにかかわらず、パケットを開始したノードを示す
ために「作成側ノード」という用語を使用する場合もあ
る。
【００８３】送信パケットと受信パケット両方のターゲ
ットは、グローバルな１６ビットの「ｔａｒｇｅｔＩ
ｄ」フィールドによって識別される。エラーがない場
合、リングレット上の何らかの固有のノード、おそら
く、ブリッジまたはスイッチ・ノードは、ｔａｒｇｅｔ
Ｉｄアドレスを認識し、そのパケットを取り除く。「ｓ
ｏｕｒｃｅＩｄ」フィールドは、送信ノードのグローバ
ル・アドレスを明確に識別するものである。
ットは、グローバルな１６ビットの「ｔａｒｇｅｔＩ
ｄ」フィールドによって識別される。エラーがない場
合、リングレット上の何らかの固有のノード、おそら
く、ブリッジまたはスイッチ・ノードは、ｔａｒｇｅｔ
Ｉｄアドレスを認識し、そのパケットを取り除く。「ｓ
ｏｕｒｃｅＩｄ」フィールドは、送信ノードのグローバ
ル・アドレスを明確に識別するものである。
【００８４】その他のフィールドは、ローカル・リング
レット肯定応答を返すためにパケット内に含まれ、ＳＳ
Ｏ順序付け機能強化案にとって基本的なものである。こ
のようなものとしては、＊＊そのローカル・リングレッ
ト上で＊＊このパケットを発信したｎｏｄｅＩｄを識別
する（６ビットの）「ｐｒｏｄｕｃｅｒＩｄ」フィール
ドと、このパケットを明確に識別するために「ｐｒｏｄ
ｕｃｅｒＩｄ」ノードによって割り当てられる（８ビッ
トの）「ｐＬａｂｅｌ」フィールドがある。ｐｒｏｄｕ
ｃｅｒＩｄフィールドとｐＬａｂｅｌフィールドはどち
らも、ローカル・リングレット内に限定された意味を有
し、たとえば、パケットがスイッチにより転送される場
合に再割当てが行われる。同様に、「ｐｒｏｄｕｃｅｒ
Ｉｄ」フィールドと「ｐＬａｂｅｌ」フィールドは、宛
先ノードが応答パケットを送信するときにその宛先ノー
ドによる再割当ても行われる。
レット肯定応答を返すためにパケット内に含まれ、ＳＳ
Ｏ順序付け機能強化案にとって基本的なものである。こ
のようなものとしては、＊＊そのローカル・リングレッ
ト上で＊＊このパケットを発信したｎｏｄｅＩｄを識別
する（６ビットの）「ｐｒｏｄｕｃｅｒＩｄ」フィール
ドと、このパケットを明確に識別するために「ｐｒｏｄ
ｕｃｅｒＩｄ」ノードによって割り当てられる（８ビッ
トの）「ｐＬａｂｅｌ」フィールドがある。ｐｒｏｄｕ
ｃｅｒＩｄフィールドとｐＬａｂｅｌフィールドはどち
らも、ローカル・リングレット内に限定された意味を有
し、たとえば、パケットがスイッチにより転送される場
合に再割当てが行われる。同様に、「ｐｒｏｄｕｃｅｒ
Ｉｄ」フィールドと「ｐＬａｂｅｌ」フィールドは、宛
先ノードが応答パケットを送信するときにその宛先ノー
ドによる再割当ても行われる。
【００８５】以下に記述するその他のフィールドとして
は、「タイプ」フィールド（コマンドおよび肯定応答の
タイプを区別する）、「コード」フィールド（コマンド
識別）、ｓｏｕｒｃｅＩｄノードに対してその応答を明
確に識別するために応答パケットに入れて返されるグロ
ーバルな「ｔＬａｂｅｌ」フィールド、そのパケット用
のヘッダとデータの両方を含む３２ビットのＣＲＣコー
ドであるｃｒｃ３２フィールドがある。 （最初に送信されるもの） ３ ２ １ ０ ０ ２ ４ ６ ８ ０ ｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜ ｜ targetId ｜ ｜タイプ｜ ｜ コード ｜ ｜ tLabel ｜ ｜ pLabel ｜｜producerId｜ ｜ sourceId ｜ offsetHi(addr) ｜ ｜ offsetLo(addr)｜ （ 任意のデータ ） ｜ ｃｒｃ３２ ｜
は、「タイプ」フィールド（コマンドおよび肯定応答の
タイプを区別する）、「コード」フィールド（コマンド
識別）、ｓｏｕｒｃｅＩｄノードに対してその応答を明
確に識別するために応答パケットに入れて返されるグロ
ーバルな「ｔＬａｂｅｌ」フィールド、そのパケット用
のヘッダとデータの両方を含む３２ビットのＣＲＣコー
ドであるｃｒｃ３２フィールドがある。 （最初に送信されるもの） ３ ２ １ ０ ０ ２ ４ ６ ８ ０ ｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜ ｜ targetId ｜ ｜タイプ｜ ｜ コード ｜ ｜ tLabel ｜ ｜ pLabel ｜｜producerId｜ ｜ sourceId ｜ offsetHi(addr) ｜ ｜ offsetLo(addr)｜ （ 任意のデータ ） ｜ ｃｒｃ３２ ｜
【００８６】受信側ノードによって生成された肯定応答
パケットは、送信または応答パケットから一部のフィー
ルドをエコーして「作成側ノード」に戻すので、それは
以下のように肯定応答中のパケットを明確に認識するこ
とができる。 （最初に送信されるもの） ３ ２ １ ０ ０ ２ ４ ６ ８ ０ ｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜ ｜ localBus ｜producerId｜ ｜タイプ｜ ｜ ｐＬａｂｅｌ ｜ ｜ ｃｒｃ３２ ｜
パケットは、送信または応答パケットから一部のフィー
ルドをエコーして「作成側ノード」に戻すので、それは
以下のように肯定応答中のパケットを明確に認識するこ
とができる。 （最初に送信されるもの） ３ ２ １ ０ ０ ２ ４ ６ ８ ０ ｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜｜ ｜ localBus ｜producerId｜ ｜タイプ｜ ｜ ｐＬａｂｅｌ ｜ ｜ ｃｒｃ３２ ｜
【００８７】肯定応答アドレスを作成するために、元の
パケットの「ｔａｒｇｅｔＩｄ」アドレス・フィールド
は、「ｌｏｃａｌＢｕｓ」識別子（通常はすべて１）と
元のパケットからの６ビットのｐｒｏｄｕｃｅｒＩｄフ
ィールドによって置き換えられる。ｐＬａｂｅｌフィー
ルドは「作成側ノード」に対して元のパケットを明確に
識別するものである。「タイプ」フィールドは肯定応答
のタイプをコード化するものである。肯定応答パケット
用のｃｒｃ３２フィールドは、ここに記載するＳＳＯメ
カニズムのために普遍性を失わずに他の何らかのエラー
検出コードによって置き換えることができる。
パケットの「ｔａｒｇｅｔＩｄ」アドレス・フィールド
は、「ｌｏｃａｌＢｕｓ」識別子（通常はすべて１）と
元のパケットからの６ビットのｐｒｏｄｕｃｅｒＩｄフ
ィールドによって置き換えられる。ｐＬａｂｅｌフィー
ルドは「作成側ノード」に対して元のパケットを明確に
識別するものである。「タイプ」フィールドは肯定応答
のタイプをコード化するものである。肯定応答パケット
用のｃｒｃ３２フィールドは、ここに記載するＳＳＯメ
カニズムのために普遍性を失わずに他の何らかのエラー
検出コードによって置き換えることができる。
【００８８】ローカル・リングレット伝送が単一方向で
あり、いかなるノードもバイパスしないという想定は、
本発明の提案にとって基本的なものである。すなわち、
１つのノードが送信パケットまたは応答パケットのいず
れかを送信すると、サブリング上のすべてのノードは、
そのノードのバイパス・バッファを介してそのパケット
の流れのためにそのパケットまたは肯定応答のいずれか
を検出することになる。
あり、いかなるノードもバイパスしないという想定は、
本発明の提案にとって基本的なものである。すなわち、
１つのノードが送信パケットまたは応答パケットのいず
れかを送信すると、サブリング上のすべてのノードは、
そのノードのバイパス・バッファを介してそのパケット
の流れのためにそのパケットまたは肯定応答のいずれか
を検出することになる。
【００８９】この想定は、Ｐ１３９４．２リングレット
の基本動作の基礎となっている（ただし、Ｐ１３９４．
２オプション案では、「ショート・カット」経路指定機
能がＳＳＯ順序付けをサポートしないはずである）。こ
の結果、伝送されるすべての送信応答パケットに関し
て、リングレット上の各ノードは、送信／応答パケット
またはその肯定応答のいずれかのためにｐｒｏｄｕｃｅ
ｒＩｄフィールドとｐＬａｂｅｌフィールドの両方を監
視することができる。
の基本動作の基礎となっている（ただし、Ｐ１３９４．
２オプション案では、「ショート・カット」経路指定機
能がＳＳＯ順序付けをサポートしないはずである）。こ
の結果、伝送されるすべての送信応答パケットに関し
て、リングレット上の各ノードは、送信／応答パケット
またはその肯定応答のいずれかのためにｐｒｏｄｕｃｅ
ｒＩｄフィールドとｐＬａｂｅｌフィールドの両方を監
視することができる。
【００９０】Ｐ１３９４．２プロトコルは、応答を必要
とする分割応答トランザクションをサポートする。（非
同期、有向）サービス用のパケットには、以下のように
パケット配達を禁止する可能性のある２通りの条件があ
る。パケットまたはその肯定応答では、ＣＲＣエラーま
たはその他の検出可能なエラーが発生する可能性があ
る。パケットは、宛先ノードで「使用中」の受信側によ
って拒否される可能性がある。
とする分割応答トランザクションをサポートする。（非
同期、有向）サービス用のパケットには、以下のように
パケット配達を禁止する可能性のある２通りの条件があ
る。パケットまたはその肯定応答では、ＣＲＣエラーま
たはその他の検出可能なエラーが発生する可能性があ
る。パケットは、宛先ノードで「使用中」の受信側によ
って拒否される可能性がある。
【００９１】ＣＲＣエラーの場合、信頼できる唯一の検
出は発信側ノードで行われ、２回リングレット循環する
間に予定の肯定応答が検出されない場合にエラーを検出
することになる。（ローカル・ノード・タイムアウト検
出を支援するためにリングレット循環ごとに補足される
「スクラバ」ノードによって１つのビットが循環す
る。）使用するタイムアウト検出の正確な方法は、ここ
に記載するＳＳＯ順序付けサポート・メカニズムの動作
にとって基本的なものではない。
出は発信側ノードで行われ、２回リングレット循環する
間に予定の肯定応答が検出されない場合にエラーを検出
することになる。（ローカル・ノード・タイムアウト検
出を支援するためにリングレット循環ごとに補足される
「スクラバ」ノードによって１つのビットが循環す
る。）使用するタイムアウト検出の正確な方法は、ここ
に記載するＳＳＯ順序付けサポート・メカニズムの動作
にとって基本的なものではない。
【００９２】受信側「使用中」の場合、受信側ノードは
（非同期、有向）サービスの送信または応答パケットの
代わりにＡＣＫ＿ｂｕｓｙ肯定応答パケットを使用す
る。
（非同期、有向）サービスの送信または応答パケットの
代わりにＡＣＫ＿ｂｕｓｙ肯定応答パケットを使用す
る。
【００９３】システムの概要：ノードにおける既知の良
好情報 ｐＬａｂｅｌフィールドとｐｒｏｄｕｃｅｒＩｄフィー
ルドはリングレット・トポロジでＳＳＯ順序付けメカニ
ズムを実施するために使用できるという主張は
好情報 ｐＬａｂｅｌフィールドとｐｒｏｄｕｃｅｒＩｄフィー
ルドはリングレット・トポロジでＳＳＯ順序付けメカニ
ズムを実施するために使用できるという主張は
【００９４】この場合の基本概念は、各パケットはリン
グレットで、ＳＳＯプログラム空間でコマンドまたはデ
ータを伝送すること、およびリングレット順序状態情報
を転送することという２つの使い方が可能である。送信
パケットの順序番号は送信側だけが把握し、最後の有効
受入れパケットは受信側だけが把握している。図で示す
と以下のようになる。
グレットで、ＳＳＯプログラム空間でコマンドまたはデ
ータを伝送すること、およびリングレット順序状態情報
を転送することという２つの使い方が可能である。送信
パケットの順序番号は送信側だけが把握し、最後の有効
受入れパケットは受信側だけが把握している。図で示す
と以下のようになる。
【００９５】作成側ノード： −リングレット・ノード内のＳＳＯ動作を制御するため
の送信／応答パケット・フィールド： 各ｐｒｏｄｕｃ
ｅｒＩｄからの送信および応答パケットに関するｐＬａ
ｂｅｌフィールドを使用して３つのサブフィールド（以
下に詳述する）伝達する。 pLabel.sso（１ビット） pLabel.bzseq（１ビット） ／＊ 非ＳＳＯ空間のため
に未使用 ＊／ pLabel.seq（６ビット）
の送信／応答パケット・フィールド： 各ｐｒｏｄｕｃ
ｅｒＩｄからの送信および応答パケットに関するｐＬａ
ｂｅｌフィールドを使用して３つのサブフィールド（以
下に詳述する）伝達する。 pLabel.sso（１ビット） pLabel.bzseq（１ビット） ／＊ 非ＳＳＯ空間のため
に未使用 ＊／ pLabel.seq（６ビット）
【００９６】「ｐＬａｂｅｌ．ｓｓｏ」ビットは、この
パケット用のアドレス空間がＳＳＯ順序付き（ｓｓｏ＝
１）であるかまたはそうではない（ｓｓｏ＝０）かを動
的に定義する。「ｂｚｓｅｑ」すなわち使用中順序ビッ
トは、ＳＳＯ順序付け空間内だけで意味を有し、それが
送信／応答パケットに対して使用中再試行肯定応答を出
さなければならないかどうかを受信側ノードが判定する
のを支援するために使用する。６ビットの「ｓｅｑ」フ
ィールドは、このｐｒｏｄｕｃｅｒＩｄから有効なパケ
ット順序を識別するためにすべてのローカル・リングレ
ット・ノードが使用する折返しモジュロ６４「カウン
タ」である。
パケット用のアドレス空間がＳＳＯ順序付き（ｓｓｏ＝
１）であるかまたはそうではない（ｓｓｏ＝０）かを動
的に定義する。「ｂｚｓｅｑ」すなわち使用中順序ビッ
トは、ＳＳＯ順序付け空間内だけで意味を有し、それが
送信／応答パケットに対して使用中再試行肯定応答を出
さなければならないかどうかを受信側ノードが判定する
のを支援するために使用する。６ビットの「ｓｅｑ」フ
ィールドは、このｐｒｏｄｕｃｅｒＩｄから有効なパケ
ット順序を識別するためにすべてのローカル・リングレ
ット・ノードが使用する折返しモジュロ６４「カウン
タ」である。
【００９７】リングレット上の各ｐｒｏｄｕｃｅｒＩｄ
ノードと他のノードとの間のＳＳＯ順序付けを維持でき
るかどうかは、その送信および受信パケットを「測定」
し、そのｐＬａｂｅｌフィールドを設定して他の各ノー
ドが適切な状態情報を維持できるようにするｐｒｏｄｕ
ｃｅｒＩｄによって決まる。その状態情報をｐｒｏｄｕ
ｃｅｒＩｄからの着信ｐＬａｂｅｌフィールドと比較す
ることにより、ＳＳＯ順序付けを維持するようにパケッ
トを適切に処分することができる。
ノードと他のノードとの間のＳＳＯ順序付けを維持でき
るかどうかは、その送信および受信パケットを「測定」
し、そのｐＬａｂｅｌフィールドを設定して他の各ノー
ドが適切な状態情報を維持できるようにするｐｒｏｄｕ
ｃｅｒＩｄによって決まる。その状態情報をｐｒｏｄｕ
ｃｅｒＩｄからの着信ｐＬａｂｅｌフィールドと比較す
ることにより、ＳＳＯ順序付けを維持するようにパケッ
トを適切に処分することができる。
【００９８】「測定」では、作成側ノードが６ビットの
「ｓｅｑ」フィールドに基づいてそのローカル・リング
レット内で３２個程度の「未解決」パケットを有するこ
とができなければならない。「未解決」とは、「使用
中」肯定応答を生成したこのノードからの最も早い先行
パケットまたはそれに関して肯定応答を一切受信してい
ない最も早い先行パケットのうち、いずれか大きい方へ
返送するための現行パケットからのカウントを意味す
る。たとえば、宛先ノードで応答を待つなど、ローカル
・リングレットを越えて未解決になりうるパケットの数
については、いかなる限界も設計されていない。
「ｓｅｑ」フィールドに基づいてそのローカル・リング
レット内で３２個程度の「未解決」パケットを有するこ
とができなければならない。「未解決」とは、「使用
中」肯定応答を生成したこのノードからの最も早い先行
パケットまたはそれに関して肯定応答を一切受信してい
ない最も早い先行パケットのうち、いずれか大きい方へ
返送するための現行パケットからのカウントを意味す
る。たとえば、宛先ノードで応答を待つなど、ローカル
・リングレットを越えて未解決になりうるパケットの数
については、いかなる限界も設計されていない。
【００９９】ＳＳＯ空間での通常動作では、新しい各送
信／応答パケットまたは各再試行使用中パケットによっ
てｐＬａｂｅｌ．ｓｅｑフィールドがモジュロ６４で１
だけ増分される。ＣＲＣエラーが検出された場合、すべ
てのローカル・リングレットに関するＳＳＯ状態はま
ず、何らかのパケット（以下に示す）を再送信すること
によって再同期しなければならない。
信／応答パケットまたは各再試行使用中パケットによっ
てｐＬａｂｅｌ．ｓｅｑフィールドがモジュロ６４で１
だけ増分される。ＣＲＣエラーが検出された場合、すべ
てのローカル・リングレットに関するＳＳＯ状態はま
ず、何らかのパケット（以下に示す）を再送信すること
によって再同期しなければならない。
【０１００】以下に使用する「ＣＲＣエラー」という用
語は、一般に、ＣＲＣエラーだけでなく、送信ノードに
よって検出できるパケット（送信、応答、または肯定応
答）用の非訂正エラー条件も含むものとして理解するこ
とができる。
語は、一般に、ＣＲＣエラーだけでなく、送信ノードに
よって検出できるパケット（送信、応答、または肯定応
答）用の非訂正エラー条件も含むものとして理解するこ
とができる。
【０１０１】ＣＲＣエラー・ループ・リセット： 作成
側ノードでＣＲＣエラーが検出されると、リングレット
内のすべてのノードでこのｐｒｏｄｕｃｅｒＩｄに関し
て維持されているＳＳＯ状態値が問題になる。このｐｒ
ｏｄｕｃｅｒＩＤに関する各リングレット・ノードのＳ
ＳＯ状態情報は、このｐｒｏｄｕｃｅｒＩｄまたは他の
作成側ノードに関するＳＳＯプログラミング空間の変更
なしにリセットしなければならない。
側ノードでＣＲＣエラーが検出されると、リングレット
内のすべてのノードでこのｐｒｏｄｕｃｅｒＩｄに関し
て維持されているＳＳＯ状態値が問題になる。このｐｒ
ｏｄｕｃｅｒＩＤに関する各リングレット・ノードのＳ
ＳＯ状態情報は、このｐｒｏｄｕｃｅｒＩｄまたは他の
作成側ノードに関するＳＳＯプログラミング空間の変更
なしにリセットしなければならない。
【０１０２】これを達成するために、このメカニズムの
以下に示す２つの重要な特徴を使用する。 １．リングレット上の各受信側ノードは、ローカル・リ
ングレット上の各送信ノード用のローカルｐｒｏｄｕｃ
ｅｒＩｄによってインデックスが付けられたＳＳＯ状態
のアレイを維持する。このＳＳＯ状態は、制御ビット
と、２つの順序付けフィールドとを含む。これらのフィ
ールドの一方は、この受信側にアドレス指定された現行
リングレット・パケットが有効ＳＳＯ順序番号を有する
かどうかを判定するために使用し、もう一方のフィール
ドは、ノードの受信バッファの状態とともに、そのパケ
ットがノードによって受け入れられるかまたは拒否され
るかと、どのタイプの肯定応答（実行済み、使用中、ま
たはエラー）が返されるかを判定するために使用する。 ２．ＣＲＣエラーを検出する各ｐｒｏｄｕｃｅｒＩｄ
は、エラー・パケットより前の最後の良好ＳＳＯ順序付
きパケットから始まり、エラーの検出前にこのノードか
ら送信された最後のパケットまで至る、一連のＳＳＯ順
序付きパケットを再試行する能力を有する。リングレッ
ト内で有効順序ベース・カウントを確立するために、Ｃ
ＲＣエラー・ループを開始するように（必要であれば）
既知の良好ＳＳＯ順序付きパケットを再試行する。次
に、ＣＲＣエラー前の最後のパケットまで残りのパケッ
トが再送信される。この再試行順序でエラーが検出され
た場合、それがエラーなしで正常に行われるか、または
エラー再試行ループが正常終了なしに完了するまで、ル
ープを反復する。このような場合、よりレベルの高いプ
ロトコルがエラーを処理することができる。この順序が
エラーなしで完了すると、リングレット内のすべてのノ
ードは、そのＳＳＯ状態が一貫した既知の良好値に復元
されることになる。
以下に示す２つの重要な特徴を使用する。 １．リングレット上の各受信側ノードは、ローカル・リ
ングレット上の各送信ノード用のローカルｐｒｏｄｕｃ
ｅｒＩｄによってインデックスが付けられたＳＳＯ状態
のアレイを維持する。このＳＳＯ状態は、制御ビット
と、２つの順序付けフィールドとを含む。これらのフィ
ールドの一方は、この受信側にアドレス指定された現行
リングレット・パケットが有効ＳＳＯ順序番号を有する
かどうかを判定するために使用し、もう一方のフィール
ドは、ノードの受信バッファの状態とともに、そのパケ
ットがノードによって受け入れられるかまたは拒否され
るかと、どのタイプの肯定応答（実行済み、使用中、ま
たはエラー）が返されるかを判定するために使用する。 ２．ＣＲＣエラーを検出する各ｐｒｏｄｕｃｅｒＩｄ
は、エラー・パケットより前の最後の良好ＳＳＯ順序付
きパケットから始まり、エラーの検出前にこのノードか
ら送信された最後のパケットまで至る、一連のＳＳＯ順
序付きパケットを再試行する能力を有する。リングレッ
ト内で有効順序ベース・カウントを確立するために、Ｃ
ＲＣエラー・ループを開始するように（必要であれば）
既知の良好ＳＳＯ順序付きパケットを再試行する。次
に、ＣＲＣエラー前の最後のパケットまで残りのパケッ
トが再送信される。この再試行順序でエラーが検出され
た場合、それがエラーなしで正常に行われるか、または
エラー再試行ループが正常終了なしに完了するまで、ル
ープを反復する。このような場合、よりレベルの高いプ
ロトコルがエラーを処理することができる。この順序が
エラーなしで完了すると、リングレット内のすべてのノ
ードは、そのＳＳＯ状態が一貫した既知の良好値に復元
されることになる。
【０１０３】受信側ノード：受信側ノードは、そのＳＳ
Ｏ状態情報が正しい場合に、任意のｐｒｏｄｕｃｅｒＩ
ｄから有効パケット順序を検出することができる。この
状態は、リセット時にｐｒｏｄｕｃｅｒＩｄによって初
期設定され、ｐｒｏｄｕｃｅｒＩＤによってＣＲＣエラ
ーが検出された場合に再初期設定される。
Ｏ状態情報が正しい場合に、任意のｐｒｏｄｕｃｅｒＩ
ｄから有効パケット順序を検出することができる。この
状態は、リセット時にｐｒｏｄｕｃｅｒＩｄによって初
期設定され、ｐｒｏｄｕｃｅｒＩＤによってＣＲＣエラ
ーが検出された場合に再初期設定される。
【０１０４】受信側ノードは、ＣＲＣエラー送信パケッ
トまたは肯定応答を検出する場合もあれば、検出しない
場合もある。検出した場合でも、パケットの内容が信用
できないので、ノード状態情報は一切更新することがで
きない。タイムアウトを検出し、ＣＲＣエラー・パケッ
トを再送信するのは、送信ノードの責任である。
トまたは肯定応答を検出する場合もあれば、検出しない
場合もある。検出した場合でも、パケットの内容が信用
できないので、ノード状態情報は一切更新することがで
きない。タイムアウトを検出し、ＣＲＣエラー・パケッ
トを再送信するのは、送信ノードの責任である。
【０１０５】しかし、受信側ノードは、何らかのｐｒｏ
ｄｕｃｅｒＩＤからＣＲＣエラー・パケットに続く有効
順序付きパケットの順不同伝送を検出することができ
る。このような順不同パケットのそれぞれは、ＡＣＫ＿
ｅｒｒｏｒとして肯定応答する間に受信側で検出し拒否
しなければならない。このパケットを送信するノードは
パケットにマークを付け、そのエラー・ループでそれを
再試行する。
ｄｕｃｅｒＩＤからＣＲＣエラー・パケットに続く有効
順序付きパケットの順不同伝送を検出することができ
る。このような順不同パケットのそれぞれは、ＡＣＫ＿
ｅｒｒｏｒとして肯定応答する間に受信側で検出し拒否
しなければならない。このパケットを送信するノードは
パケットにマークを付け、そのエラー・ループでそれを
再試行する。
【０１０６】パケットは、受信側ノードが非同期動作で
拒否されるか、またはそのパケットが前に受け入れられ
たパケットの再伝送である場合にＳＳＯ順序付けサポー
トによって拒否される場合がある。ＳＳＯ順序付けモー
ドでは、所与のｐｒｏｄｕｃｅｒＩｄからの第１のパケ
ットが使用中として拒否されると、第１の使用中パケッ
トが再試行されるまで、このｐｒｏｄｕｃｅｒＩＤから
のすべての後続順序付きパケットも拒否しなければなら
ない。
拒否されるか、またはそのパケットが前に受け入れられ
たパケットの再伝送である場合にＳＳＯ順序付けサポー
トによって拒否される場合がある。ＳＳＯ順序付けモー
ドでは、所与のｐｒｏｄｕｃｅｒＩｄからの第１のパケ
ットが使用中として拒否されると、第１の使用中パケッ
トが再試行されるまで、このｐｒｏｄｕｃｅｒＩＤから
のすべての後続順序付きパケットも拒否しなければなら
ない。
【０１０７】ＳＳＯの場合の受信側の状態は、非使用中
受信側バッファへの新しいパケットの受入れと、エラー
回復のために再送信される前に受け入れられたパケット
および「使用中」拒否後に送信された新しいパケットの
拒否をサポートしなければならない。作成側に返される
肯定応答パケットはエラーの影響を受けるので、受信側
状態は、任意のパケットが再試行される場合にａｃｋ＿
ｄｏｎｅおよびａｃｋ＿ｂｕｓｙパケットを複製できな
ければならない。
受信側バッファへの新しいパケットの受入れと、エラー
回復のために再送信される前に受け入れられたパケット
および「使用中」拒否後に送信された新しいパケットの
拒否をサポートしなければならない。作成側に返される
肯定応答パケットはエラーの影響を受けるので、受信側
状態は、任意のパケットが再試行される場合にａｃｋ＿
ｄｏｎｅおよびａｃｋ＿ｂｕｓｙパケットを複製できな
ければならない。
【０１０８】これを達成するため、各受信側ノードは、
以下の６つのフィールドを含み、ｐｒｏｄｕｃｅｒＩｄ
によってインデックスが付けられた、ｓｅｑＴａｂｌｅ
という状態アレイを必要とする。 ｓｅｑＴａｂｌｅ．ｖｅｒｉｆ［ｐｒｏｄｕｃｅｒＩｄ］ （１ビット） ｓｅｑＴａｂｌｅ．ｓｓｏ［ｐｒｏｄｕｃｅｒＩｄ］ （１ビット） ｓｅｑＴａｂｌｅ．ｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］ （６ビット） ｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］ （１ビット） ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］ （１ビット） ｓｅｑＴａｂｌｅ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］ （６ビット）
以下の６つのフィールドを含み、ｐｒｏｄｕｃｅｒＩｄ
によってインデックスが付けられた、ｓｅｑＴａｂｌｅ
という状態アレイを必要とする。 ｓｅｑＴａｂｌｅ．ｖｅｒｉｆ［ｐｒｏｄｕｃｅｒＩｄ］ （１ビット） ｓｅｑＴａｂｌｅ．ｓｓｏ［ｐｒｏｄｕｃｅｒＩｄ］ （１ビット） ｓｅｑＴａｂｌｅ．ｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］ （６ビット） ｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］ （１ビット） ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］ （１ビット） ｓｅｑＴａｂｌｅ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］ （６ビット）
【０１０９】ＳＳＯ動作では、ｓｅｑＴａｂｌｅフィー
ルドを以下のように使用する。「ｖｅｒｉｆ」フィール
ドは、このｓｅｑＴａｂｌｅが初期設定されたことと、
ｐｒｏｄｕｃｅｒＩｄが検査済みソースであることの両
方を示す。「ｓｓｏ」フィールドは、ＳＳＯ順序付けを
サポートするためにこのｐｒｏｄｕｃｅｒＩｄノードの
（静的）機能を定義する。（比較によれば、ｐＬａｂｅ
ｌ．ｓｓｏビットは、作成側ノード用のアドレス空間順
序付けに応じて設定された動的ビットである。）「ｓｅ
ｑ」フィールドは、受信側ノードによるパケット順序付
けのためのｐＬａｂｅｌ「ｓｅｑ」フィールドと比較さ
れる。「ｂｚｓｅｑ」ビットは、第１の使用中パケット
の再伝送を識別するためにＳＳＯパケット用の対応する
ｐＬａｂｅｌ「ｂｚｓｅｑ」ビットと比較される。「ｂ
ｕｓｙ」ビットは、ＳＳＯパケットの第１の使用中肯定
応答時にｐｒｏｄｕｃｅｒＩｄに設定され、受信側バッ
ファに応じてこの使用中パケットが再試行されたときに
（おそらく）リセットされる。最後に、「ａｃｐｔ」フ
ィールドは、ＳＳＯパケットの受入れおよび拒否の場合
と、「実行済み」または「使用中」として肯定応答すべ
きかどうかを判定する場合の両方に使用する。このよう
な判定では、着信パケットの「ｓｅｑ」フィールドとの
比較が必要である。
ルドを以下のように使用する。「ｖｅｒｉｆ」フィール
ドは、このｓｅｑＴａｂｌｅが初期設定されたことと、
ｐｒｏｄｕｃｅｒＩｄが検査済みソースであることの両
方を示す。「ｓｓｏ」フィールドは、ＳＳＯ順序付けを
サポートするためにこのｐｒｏｄｕｃｅｒＩｄノードの
（静的）機能を定義する。（比較によれば、ｐＬａｂｅ
ｌ．ｓｓｏビットは、作成側ノード用のアドレス空間順
序付けに応じて設定された動的ビットである。）「ｓｅ
ｑ」フィールドは、受信側ノードによるパケット順序付
けのためのｐＬａｂｅｌ「ｓｅｑ」フィールドと比較さ
れる。「ｂｚｓｅｑ」ビットは、第１の使用中パケット
の再伝送を識別するためにＳＳＯパケット用の対応する
ｐＬａｂｅｌ「ｂｚｓｅｑ」ビットと比較される。「ｂ
ｕｓｙ」ビットは、ＳＳＯパケットの第１の使用中肯定
応答時にｐｒｏｄｕｃｅｒＩｄに設定され、受信側バッ
ファに応じてこの使用中パケットが再試行されたときに
（おそらく）リセットされる。最後に、「ａｃｐｔ」フ
ィールドは、ＳＳＯパケットの受入れおよび拒否の場合
と、「実行済み」または「使用中」として肯定応答すべ
きかどうかを判定する場合の両方に使用する。このよう
な判定では、着信パケットの「ｓｅｑ」フィールドとの
比較が必要である。
【０１１０】受信側ノードは、以下のような場合に所与
のｐｒｏｄｕｃｅｒＩＤから有効な新しいＳＳＯ順序付
けパケットを検出することができる。 pLabel.seq = seqTable.seq[producerId] + 1
のｐｒｏｄｕｃｅｒＩＤから有効な新しいＳＳＯ順序付
けパケットを検出することができる。 pLabel.seq = seqTable.seq[producerId] + 1
【０１１１】比較が有効である場合、seqフィールドが
更新される。 seqTable.seq[producerId] = pLabel.seq
更新される。 seqTable.seq[producerId] = pLabel.seq
【０１１２】その他の比較については、以下を参照され
たい。
たい。
【０１１３】このｐｒｏｄｕｃｅｒＩｄがＣＲＣエラー
再試行ループを初期設定することをこのノードが検出し
た場合、ｓｅｑＴａｂｌｅ．ｓｅｑ［ｐｒｏｄｕｃｅｒ
Ｉｄ］フィールドが現行のｐＬａｂｅｌ．ｓｅｑ値にリ
セットされる。これは、以下のようにこのｐｒｏｄｕｃ
ｅｒＩｄからのパケットまたはこのｐｒｏｄｕｃｅｒＩ
ｄへの肯定応答用のｓｅｑフィールドを比較することに
よって示される。 if {pLabel.seq <= seqTable.seq[producerId]} then seqTable.seq[producerId] = pLabel.seq
再試行ループを初期設定することをこのノードが検出し
た場合、ｓｅｑＴａｂｌｅ．ｓｅｑ［ｐｒｏｄｕｃｅｒ
Ｉｄ］フィールドが現行のｐＬａｂｅｌ．ｓｅｑ値にリ
セットされる。これは、以下のようにこのｐｒｏｄｕｃ
ｅｒＩｄからのパケットまたはこのｐｒｏｄｕｃｅｒＩ
ｄへの肯定応答用のｓｅｑフィールドを比較することに
よって示される。 if {pLabel.seq <= seqTable.seq[producerId]} then seqTable.seq[producerId] = pLabel.seq
【０１１４】ＣＲＣエラー・ループの初期設定中は、ｓ
ｅｑＴａｂｌｅ．ａｃｐｔ[]フィールドではなく、ｓｅ
ｑＴａｂｌｅ．ｓｅｑ値だけが変更される。パケットは
拒否されるが、通常使用するのと同じ受入れ／拒否論理
（以下に示す）を使用する。再試行したすべてのパケッ
トを「実行済み」（前に受け入れられたことを意味す
る）または「使用中」として正しく肯定応答するために
ｓｅｑＴａｂｌｅ状態情報を使用することが重要であ
る。論理については以下に説明する。
ｅｑＴａｂｌｅ．ａｃｐｔ[]フィールドではなく、ｓｅ
ｑＴａｂｌｅ．ｓｅｑ値だけが変更される。パケットは
拒否されるが、通常使用するのと同じ受入れ／拒否論理
（以下に示す）を使用する。再試行したすべてのパケッ
トを「実行済み」（前に受け入れられたことを意味す
る）または「使用中」として正しく肯定応答するために
ｓｅｑＴａｂｌｅ状態情報を使用することが重要であ
る。論理については以下に説明する。
【０１１５】「ｓｅｑ」比較が有効である場合、パケッ
トはこの比較に応じて受け入れられるかまたは拒否され
る。 ａｃｃｅｐｔ：｛ ｛ｐＬａｂｅｌ．ｂｚｓｅｑ〜＝ｓｅｑＴａｂｌｅ ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｒｅｃｅｉｖｅｒ＿ｎｏｔ＿ｂｕｓｙ｝ ｜ ｛ｐＬａｂｌｅ．ｂｚｓｅｑ＝ｓｅｑＴａｂｌｅ． ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃ ｅｒＩｄ］＝０｝ ＆｛ｒｅｃｅｉｖｅｒ＿ｎｏｔ＿ｂｕｓｙ｝ ＆｛ｐＬａｂｅｌ．ｓｅｑ＞ｓｅｑＴａｂｌｅ． ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］｝｝ ｒｅｊｅｃｔ：｛ ｛ｒｅｃｅｉｖｅｒ＿ｂｕｓｙ｝ ｜ ｛ｐＬａｂｅｌ．ｂｚｓｅｑ＝ｓｅｑＴａｂｅｌ． ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃ ｅｒＩｄ］＝１｝ ｜ ｛ｐＬａｂｅｌ．ｂｚｓｅｑ＝ｓｅｑＴａｂｅｌ． ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｐＬａｂｅｌ．ｓｅｑ＜＝ｓｅｑＴａｂｅｌ ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］｝｝ ＝〜ａｃｃｅｐｔ
トはこの比較に応じて受け入れられるかまたは拒否され
る。 ａｃｃｅｐｔ：｛ ｛ｐＬａｂｅｌ．ｂｚｓｅｑ〜＝ｓｅｑＴａｂｌｅ ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｒｅｃｅｉｖｅｒ＿ｎｏｔ＿ｂｕｓｙ｝ ｜ ｛ｐＬａｂｌｅ．ｂｚｓｅｑ＝ｓｅｑＴａｂｌｅ． ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃ ｅｒＩｄ］＝０｝ ＆｛ｒｅｃｅｉｖｅｒ＿ｎｏｔ＿ｂｕｓｙ｝ ＆｛ｐＬａｂｅｌ．ｓｅｑ＞ｓｅｑＴａｂｌｅ． ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］｝｝ ｒｅｊｅｃｔ：｛ ｛ｒｅｃｅｉｖｅｒ＿ｂｕｓｙ｝ ｜ ｛ｐＬａｂｅｌ．ｂｚｓｅｑ＝ｓｅｑＴａｂｅｌ． ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃ ｅｒＩｄ］＝１｝ ｜ ｛ｐＬａｂｅｌ．ｂｚｓｅｑ＝ｓｅｑＴａｂｅｌ． ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｐＬａｂｅｌ．ｓｅｑ＜＝ｓｅｑＴａｂｅｌ ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］｝｝ ＝〜ａｃｃｅｐｔ
【０１１６】あまり形式的ではないが、使用中再試行ル
ープが開始され、受信側バッファが使用中ではない場
合、または使用中再試行ループは開始されていないが、
「使用中」状態がリセットされ、受信側バッファが使用
中ではなく、作成側ノードがエラー再試行ループに入っ
ていないと順序比較が示している場合、パケットは受け
入れられる資格を有する。
ープが開始され、受信側バッファが使用中ではない場
合、または使用中再試行ループは開始されていないが、
「使用中」状態がリセットされ、受信側バッファが使用
中ではなく、作成側ノードがエラー再試行ループに入っ
ていないと順序比較が示している場合、パケットは受け
入れられる資格を有する。
【０１１７】「ｓｅｑ」比較が有効である場合、パケッ
トはこの比較に応じて「実行済み」または「使用中」と
して肯定応答される。 ａｃｋ＿ｄｏｎ：｛ ｛ｐＬａｂｅｌ．ｂｚｓｅｑ〜＝ｓｅｑＴａｂｌ ｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｒｅｃｅｉｖｅｒ＿ｎｏｔ＿ｂｕｓｙ｝ ｜ ｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅ ｒＩｄ］＝０｝ ＆｛ｒｅｃｅｉｖｅｒ＿ｎｏｔ＿ｂｕｓｙ｝ ｜ ｛ｐＬａｂｅｌ．ｓｅｑ＜ｓｅｑＴａｂｌｅ．ａ ｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］｝｝ ａｃｔ＿ｂｚｙ：｛ ｛ｐＬａｂｅｌ．ｂｚｓｅｑ＝ｓｅｑＴａｂｅｌ ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕ ｃｅｒＩｄ］＝１｝ ＆｛ｐＬａｂｅ．ｓｅｑ＞＝ｓｅｑＴａｂｅｌ ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］｝ ｜ ｛ｐＬａｂｅｌ．ｓｅｑ＞＝ｓｅｑＴａｂｅｌ． ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｒｅｃｅｉｖｅｒ＿ｂｕｓｙ｝ ＝〜ａｃｋ＿ｄｏｎ
トはこの比較に応じて「実行済み」または「使用中」と
して肯定応答される。 ａｃｋ＿ｄｏｎ：｛ ｛ｐＬａｂｅｌ．ｂｚｓｅｑ〜＝ｓｅｑＴａｂｌ ｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｒｅｃｅｉｖｅｒ＿ｎｏｔ＿ｂｕｓｙ｝ ｜ ｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅ ｒＩｄ］＝０｝ ＆｛ｒｅｃｅｉｖｅｒ＿ｎｏｔ＿ｂｕｓｙ｝ ｜ ｛ｐＬａｂｅｌ．ｓｅｑ＜ｓｅｑＴａｂｌｅ．ａ ｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］｝｝ ａｃｔ＿ｂｚｙ：｛ ｛ｐＬａｂｅｌ．ｂｚｓｅｑ＝ｓｅｑＴａｂｅｌ ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕ ｃｅｒＩｄ］＝１｝ ＆｛ｐＬａｂｅ．ｓｅｑ＞＝ｓｅｑＴａｂｅｌ ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］｝ ｜ ｛ｐＬａｂｅｌ．ｓｅｑ＞＝ｓｅｑＴａｂｅｌ． ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］｝ ＆｛ｒｅｃｅｉｖｅｒ＿ｂｕｓｙ｝ ＝〜ａｃｋ＿ｄｏｎ
【０１１８】あまり形式的ではないが、使用中再試行ル
ープが開始され、受信側が使用中ではない場合、または
「使用中」状態がリセットされ、受信側が使用中ではな
い場合、またはエラー再試行ループでは再試行中のパケ
ットが第１の「使用中」パケットより前に送信されたこ
とを順序比較が示している場合、パケットはａｃｋ＿ｄ
ｏｎｅとして送信される。それらがａｃｋ＿ｄｏｎとし
て肯定応答されない場合、パケットはａｃｋ＿ｂｚｙと
して肯定応答される（この場合も、有効な順序比較が前
提事項となる）。
ープが開始され、受信側が使用中ではない場合、または
「使用中」状態がリセットされ、受信側が使用中ではな
い場合、またはエラー再試行ループでは再試行中のパケ
ットが第１の「使用中」パケットより前に送信されたこ
とを順序比較が示している場合、パケットはａｃｋ＿ｄ
ｏｎｅとして送信される。それらがａｃｋ＿ｄｏｎとし
て肯定応答されない場合、パケットはａｃｋ＿ｂｚｙと
して肯定応答される（この場合も、有効な順序比較が前
提事項となる）。
【０１１９】−受信側ノードが初めて所与のｐｒｏｄｕ
ｃｅｒＩｄから使用中としてパケットを拒否する場合、
（ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩ
ｄ］＝１）を設定することにより、その「使用中」状態
を変更しなければならない。これは、「使用中」パケッ
トの順序番号でｓｅｑＴａｂｌｅ．ａｃｐｔ［］フィー
ルドをフリーズするという影響を及ぼす。このフィール
ドは、第１の使用中パケットが再試行されるまでフリー
ズしたままになる。
ｃｅｒＩｄから使用中としてパケットを拒否する場合、
（ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩ
ｄ］＝１）を設定することにより、その「使用中」状態
を変更しなければならない。これは、「使用中」パケッ
トの順序番号でｓｅｑＴａｂｌｅ．ａｃｐｔ［］フィー
ルドをフリーズするという影響を及ぼす。このフィール
ドは、第１の使用中パケットが再試行されるまでフリー
ズしたままになる。
【０１２０】「ｂｕｓｙ」フィールドと「ａｃｐｔ」フ
ィールドを設定するための条件は、使用中再試行ループ
が作成側ノードによって実行されるかどうかによって決
まる。「ｓｅｑ」比較が有効である場合、使用中再試行
ループ内の第１のパケットは以下の関係から検出するこ
とができる。 pLabel.bzseq 〜＝ seqTable.bzseq[producerId] ただし、「ｂｚｓｅｑ」フィールドは、エラー再試行ル
ープを実行中に変更されないことに留意されたい。これ
は真実なので、使用中再試行ループのパケットにおいて
以下の比較は必ず真になる。 {pLabel.seq > seqTable.acpt[producerId]}
ィールドを設定するための条件は、使用中再試行ループ
が作成側ノードによって実行されるかどうかによって決
まる。「ｓｅｑ」比較が有効である場合、使用中再試行
ループ内の第１のパケットは以下の関係から検出するこ
とができる。 pLabel.bzseq 〜＝ seqTable.bzseq[producerId] ただし、「ｂｚｓｅｑ」フィールドは、エラー再試行ル
ープを実行中に変更されないことに留意されたい。これ
は真実なので、使用中再試行ループのパケットにおいて
以下の比較は必ず真になる。 {pLabel.seq > seqTable.acpt[producerId]}
【０１２１】第１の再試行パケットが検出された場合、
ｓｅｑＴａｂｌｅの各項目は以下のように設定される。 ｛ ｓｅｑＴａｂｅｌ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］ ＝ｐＬａｂｅｌ．ｂｚｓｅｑ ｓｅｑＴａｂｅｌ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］ ＝ｒｅｃｅｉｖｅｒ＿ｂｕｓｙ ｓｅｑＴａｂｌｅ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］ ＝ｐＬａｂｅｌ．ｓｅｑ ｝
ｓｅｑＴａｂｌｅの各項目は以下のように設定される。 ｛ ｓｅｑＴａｂｅｌ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］ ＝ｐＬａｂｅｌ．ｂｚｓｅｑ ｓｅｑＴａｂｅｌ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］ ＝ｒｅｃｅｉｖｅｒ＿ｂｕｓｙ ｓｅｑＴａｂｌｅ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］ ＝ｐＬａｂｅｌ．ｓｅｑ ｝
【０１２２】ただし、第１の再試行パケットは、上記の
比較基準により拒否され、「実行済み」または「使用
中」として肯定応答されることに留意されたい。パケッ
トが第１の再試行パケットではない場合、これは以下の
関係から検出される。 pLabel.bzseq = seqTable.bzseq[producerId]
比較基準により拒否され、「実行済み」または「使用
中」として肯定応答されることに留意されたい。パケッ
トが第１の再試行パケットではない場合、これは以下の
関係から検出される。 pLabel.bzseq = seqTable.bzseq[producerId]
【０１２３】次に、ｓｅｑＴａｂｌｅの各項目は以下の
ようにパケット受入れによって決まる。 ｉｆ｛ ｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］ ＝０｝ ＆｛ｐＬａｂｅｌ．ｓｅｑ＞ｓｅｑＴａｂｌｅ．ａｃｐｔ［ ｐｒｏｄｕｃｅｒＩｄ］｝｝ ｔｈｅｎ ｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］ ＝ｒｅｃｅｉｖｅｒ＿ｂｕｓｙ ｓｅｑＴａｂｌｅ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］ ＝ｐＬａｂｅｌ．ｓｅｑ ｛ ｅｌｓｅ／＊ 前の使用中パケットまたはエラー再試行ループ ＊／ ｛ｎｏ ｕｐｄａｔｅ ｝
ようにパケット受入れによって決まる。 ｉｆ｛ ｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］ ＝０｝ ＆｛ｐＬａｂｅｌ．ｓｅｑ＞ｓｅｑＴａｂｌｅ．ａｃｐｔ［ ｐｒｏｄｕｃｅｒＩｄ］｝｝ ｔｈｅｎ ｛ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］ ＝ｒｅｃｅｉｖｅｒ＿ｂｕｓｙ ｓｅｑＴａｂｌｅ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］ ＝ｐＬａｂｅｌ．ｓｅｑ ｛ ｅｌｓｅ／＊ 前の使用中パケットまたはエラー再試行ループ ＊／ ｛ｎｏ ｕｐｄａｔｅ ｝
【０１２４】最後に、各ノードは、以下のような場合に
ｐｒｏｄｕｃｅｒＩｄから順序エラーを含むパケットを
検出することができる。 pLabel.seq > seqTable.seq[producerId] + 1
ｐｒｏｄｕｃｅｒＩｄから順序エラーを含むパケットを
検出することができる。 pLabel.seq > seqTable.seq[producerId] + 1
【０１２５】これは、このパケットには有効ＣＲＣがあ
るが一部の先行パケットにはなかった場合に発生する可
能性がある。（カウント比較は、完全６ビットの算術比
較ではない。以下の詳細を参照されたい。）順序エラー
を含むパケットについては、ｓｅｑＴａｂｌｅの各項目
は一切更新されない。
るが一部の先行パケットにはなかった場合に発生する可
能性がある。（カウント比較は、完全６ビットの算術比
較ではない。以下の詳細を参照されたい。）順序エラー
を含むパケットについては、ｓｅｑＴａｂｌｅの各項目
は一切更新されない。
【０１２６】リングレットＳＳＯ状態の初期設定： −作成側ノードは、実際のＳＳＯ送信／応答パケットを
送信する前にそのリングレット上の各ノードでの状態情
報が初期設定されることを確認しなければならない。
送信する前にそのリングレット上の各ノードでの状態情
報が初期設定されることを確認しなければならない。
【０１２７】「承認作成側」という方針は、ｓｅｑＴａ
ｂｌｅを初期設定するために提案されたｓｅｑＴａｂｌ
ｅ状態ビットおよび書込み送信パケットによってサポー
トすることができる。以下の３つのステップが必要であ
る。 １．ｓｅｑＴａｂｌｅ[]アレイは、電源がオンになる
か、またはすべてのｐｒｏｄｕｃｅｒＩｄについてｓｅ
ｑＴａｂｌｅ．ｖａｒｉｆ[]=０を指定してリセットさ
れる。 ２．非ＳＳＯアドレス空間内の（未指定）プロセスによ
り、ローカル・ノードはｐｒｏｄｕｃｅｒＩｄ案を検査
し、それ自体のｓｅｑＴａｂｌｅ．ｖｅｒｉｆ［ｐｒｏ
ｄｕｃｅｒＩｄ］＝１を書き込む。「ｖｅｒｉｆ」ビッ
トは、ローカル・ノードによって書き込まれるだけであ
る。 ３．ｓｅｑＴａｂｌｅ．ｖｅｒｉｆ［ｐｒｏｄｕｃｅｒ
Ｉｄ］が活動化された状態で、ｐｕｒｏｄｕｃｅｒＩｄ
はこのノードのｓｅｑＴａｂｌｅにアドレス指定された
書込み（または移動）コマンドを送信する。パケット
は、そのターゲット・アドレス（ｓｅｑＴａｂｌｅ）に
より初期設定パケットとして識別される。
ｂｌｅを初期設定するために提案されたｓｅｑＴａｂｌ
ｅ状態ビットおよび書込み送信パケットによってサポー
トすることができる。以下の３つのステップが必要であ
る。 １．ｓｅｑＴａｂｌｅ[]アレイは、電源がオンになる
か、またはすべてのｐｒｏｄｕｃｅｒＩｄについてｓｅ
ｑＴａｂｌｅ．ｖａｒｉｆ[]=０を指定してリセットさ
れる。 ２．非ＳＳＯアドレス空間内の（未指定）プロセスによ
り、ローカル・ノードはｐｒｏｄｕｃｅｒＩｄ案を検査
し、それ自体のｓｅｑＴａｂｌｅ．ｖｅｒｉｆ［ｐｒｏ
ｄｕｃｅｒＩｄ］＝１を書き込む。「ｖｅｒｉｆ」ビッ
トは、ローカル・ノードによって書き込まれるだけであ
る。 ３．ｓｅｑＴａｂｌｅ．ｖｅｒｉｆ［ｐｒｏｄｕｃｅｒ
Ｉｄ］が活動化された状態で、ｐｕｒｏｄｕｃｅｒＩｄ
はこのノードのｓｅｑＴａｂｌｅにアドレス指定された
書込み（または移動）コマンドを送信する。パケット
は、そのターゲット・アドレス（ｓｅｑＴａｂｌｅ）に
より初期設定パケットとして識別される。
【０１２８】ｓｅｑＴａｂｌｅに書き込まれる値は、以
下のように初期設定パケットのデータから取られる。 ｉｆ｛ｓｅｑＴａｂｅｌ．ｖｅｒｉｆ［ｐｒｏｄｕｃｅｒＩｄ］ ＝＝１｝ｔｈｅｎ ｛ｓｅｑＴａｂｌｅ．ｓｓｏ［ｐｒｏｄｕｃｅｒＩｄ］＝１ ｓｅｑＴａｂｌｅ．ｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］ ＝［ｃｕｒｒｅｎｔ”ｓｅｑ”ｆｒｏｍ ｔｈｉｓ ｐｒｏｄｕ ｃｅｒＩｄ］ ｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］ ＝［ｃｕｒｒｅｎｔ”ｂｚｓｅｑ”ｆｒｏｍ ｔｈｉｓ ｐｒｏ ｄｕｃｅｒＩｄ］ ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］＝０ ｓｅｑＴａｂｌｅ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］ ＝［ｃｕｒｒｅｎｔ”ｓｅｑ”ｆｒｏｍ ｔｈｉｓ ｐｒｏｄｕ ｃｅｒＩｄ］ ｝
下のように初期設定パケットのデータから取られる。 ｉｆ｛ｓｅｑＴａｂｅｌ．ｖｅｒｉｆ［ｐｒｏｄｕｃｅｒＩｄ］ ＝＝１｝ｔｈｅｎ ｛ｓｅｑＴａｂｌｅ．ｓｓｏ［ｐｒｏｄｕｃｅｒＩｄ］＝１ ｓｅｑＴａｂｌｅ．ｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］ ＝［ｃｕｒｒｅｎｔ”ｓｅｑ”ｆｒｏｍ ｔｈｉｓ ｐｒｏｄｕ ｃｅｒＩｄ］ ｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］ ＝［ｃｕｒｒｅｎｔ”ｂｚｓｅｑ”ｆｒｏｍ ｔｈｉｓ ｐｒｏ ｄｕｃｅｒＩｄ］ ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］＝０ ｓｅｑＴａｂｌｅ．ａｃｐｔ［ｐｒｏｄｕｃｅｒＩｄ］ ＝［ｃｕｒｒｅｎｔ”ｓｅｑ”ｆｒｏｍ ｔｈｉｓ ｐｒｏｄｕ ｃｅｒＩｄ］ ｝
【０１２９】リングレット内の各ノードは、別々に検査
し初期設定しなければならない。
し初期設定しなければならない。
【０１３０】上記のような方針を使用すると、既存のリ
ングからノードを動的に追加（または削除）すると同時
に新たに電源オンしたリングを初期設定することができ
る。
ングからノードを動的に追加（または削除）すると同時
に新たに電源オンしたリングを初期設定することができ
る。
【０１３１】上記のような方針は、選択的「承認ノー
ド」交換を可能にすることができる。たとえば、ノード
ＡはノードＢと、ノードＣはノードＢと交換することが
できるが、ＡとＢがＳＳＯ交換されるのを防止すること
ができる。
ド」交換を可能にすることができる。たとえば、ノード
ＡはノードＢと、ノードＣはノードＢと交換することが
できるが、ＡとＢがＳＳＯ交換されるのを防止すること
ができる。
【０１３２】応用空間 このメカニズム案は、以下のものを含む汎用１３９４．
２ネットワーク・トポロジで動作することができる。Ｓ
ＳＯ順序付けが可能なノードと、そうではない（静的機
能）のノード、およびＳＳＯ順序付けされたかまたはＳ
ＳＯ順序付けされていない（動的機能）複数のアドレス
空間をサポートするノード。
２ネットワーク・トポロジで動作することができる。Ｓ
ＳＯ順序付けが可能なノードと、そうではない（静的機
能）のノード、およびＳＳＯ順序付けされたかまたはＳ
ＳＯ順序付けされていない（動的機能）複数のアドレス
空間をサポートするノード。
【０１３３】ＩＥＥＥ Ｐ１３９４．２内にはＳＳＯ順
序付けされていない可能性のあるモード（等時性）が存
在するので、動的機能は重要であり、非ＳＳＯ順序付け
空間へのブリッジ（ＩＥＥＥ１３９４−１９９５など）
をサポートしなければならないことに留意されたい。一
般に、ＩＥＥＥ Ｐ１３９４．２ノードへのソフトウェ
ア・インタフェースは、潜在的に変動するプログラミン
グ・モデルを備えた１組のアドレス空間であると推定さ
れる（必須ではない）。これらのモデルのうちの少なく
とも１つは、非アイデンポテント・コマンドをサポート
するＳＳＯモデルであると推定される。
序付けされていない可能性のあるモード（等時性）が存
在するので、動的機能は重要であり、非ＳＳＯ順序付け
空間へのブリッジ（ＩＥＥＥ１３９４−１９９５など）
をサポートしなければならないことに留意されたい。一
般に、ＩＥＥＥ Ｐ１３９４．２ノードへのソフトウェ
ア・インタフェースは、潜在的に変動するプログラミン
グ・モデルを備えた１組のアドレス空間であると推定さ
れる（必須ではない）。これらのモデルのうちの少なく
とも１つは、非アイデンポテント・コマンドをサポート
するＳＳＯモデルであると推定される。
【０１３４】ＳＳＯ順序付けメカニズムはＩＥＥＥ Ｐ
１３９４．２（非同期、有向）サービスに応用されるの
で、その応用については以下に記載する。これは、この
メカニズムが他のモードには応用できないことを意味す
るわけではない。このメカニズムは、複数のアドレス空
間からの任意のコマンド・ストリームをサポートし、Ｓ
ＳＯコマンドに他のプログラミング・モデルからのコマ
ンドが散在できることを意味する。
１３９４．２（非同期、有向）サービスに応用されるの
で、その応用については以下に記載する。これは、この
メカニズムが他のモードには応用できないことを意味す
るわけではない。このメカニズムは、複数のアドレス空
間からの任意のコマンド・ストリームをサポートし、Ｓ
ＳＯコマンドに他のプログラミング・モデルからのコマ
ンドが散在できることを意味する。
【０１３５】ＳＳＯアドレス空間（またはＳＳＯドメイ
ン）から宛先ノードへの終端間でＳＳＯ順序付けを維持
する必要がある場合、ＳＳＯドメイン・コマンド用の宛
先ノードがＳＳＯ順序付け可能でなければならず、スイ
ッチまたはブリッジ内のすべての中間ノードがＳＳＯ順
序付け可能でなければならないことは明らかである。
ン）から宛先ノードへの終端間でＳＳＯ順序付けを維持
する必要がある場合、ＳＳＯドメイン・コマンド用の宛
先ノードがＳＳＯ順序付け可能でなければならず、スイ
ッチまたはブリッジ内のすべての中間ノードがＳＳＯ順
序付け可能でなければならないことは明らかである。
【０１３６】サポートに必要なＩＥＥＥ Ｐ１３９４．
２の変更 ＳＳＯサポート・メカニズム案は、文書化されていない
任意の機能として変更なしに現行規格の０．６バージョ
ンで実施することができる。しかし、このメカニズムを
含む特許を出願すると、（少なくとも）任意の機能とし
てこのメカニズムをＩＥＥＥ Ｐ１３９４．２の文書に
追加することが計画される。
２の変更 ＳＳＯサポート・メカニズム案は、文書化されていない
任意の機能として変更なしに現行規格の０．６バージョ
ンで実施することができる。しかし、このメカニズムを
含む特許を出願すると、（少なくとも）任意の機能とし
てこのメカニズムをＩＥＥＥ Ｐ１３９４．２の文書に
追加することが計画される。
【０１３７】変更は不要であるが、明確にするために１
つのコード化の追加が示唆され、費用効果の高いＩＥＥ
Ｅ１３９４−１９９５へのブリッジをサポートするため
にもう１つのコード化の追加が必要である。
つのコード化の追加が示唆され、費用効果の高いＩＥＥ
Ｅ１３９４−１９９５へのブリッジをサポートするため
にもう１つのコード化の追加が必要である。
【０１３８】明確にするためのコード化の追加は、「タ
イプ」フィールドに「ＡＣＫ＿ｅｒｒｏｒ」肯定応答を
追加し、予約コードを置き換えるものである。 Ｔｙｐｅ ｆｉｅｌｄ：０ Ｎｏｒｍａｌ， ｎｏｎ
−ＳＳＯ １ Ｅｘｔｅｎｄｅｄ， ｎｏｎ−ＳＳＯ ２［ｒｅｓｅｒｖｅｄ］ ３ ［ｒｅｓｅｒｖｅｄ］ ４ ＡＣＫ＿ｄｏｎｅ ５ ＡＣＫ＿ｂｕｓｙ ６ ＡＣＫ＿ｍｏｒｅ／*マルチキャスト・モード再
試行が必要*／*７ＡＣＫ＿ｅｒｒｏｒ*／*ＳＳＯモード
での順序エラー*／
イプ」フィールドに「ＡＣＫ＿ｅｒｒｏｒ」肯定応答を
追加し、予約コードを置き換えるものである。 Ｔｙｐｅ ｆｉｅｌｄ：０ Ｎｏｒｍａｌ， ｎｏｎ
−ＳＳＯ １ Ｅｘｔｅｎｄｅｄ， ｎｏｎ−ＳＳＯ ２［ｒｅｓｅｒｖｅｄ］ ３ ［ｒｅｓｅｒｖｅｄ］ ４ ＡＣＫ＿ｄｏｎｅ ５ ＡＣＫ＿ｂｕｓｙ ６ ＡＣＫ＿ｍｏｒｅ／*マルチキャスト・モード再
試行が必要*／*７ＡＣＫ＿ｅｒｒｏｒ*／*ＳＳＯモード
での順序エラー*／
【０１３９】ブリッジのためのコード化の追加では、よ
り長いパケット・タイプをサポートする相互接続により
その宛先に達する、開始、中間、終了の各６４Ｂパケッ
トの輪郭を示すビットを指定する。たとえば、イーサネ
ットまたは１３９４による２ＫＢパケットは、以下の３
通りのタイプのパケットに分解することができる。 開始パケット： おそらく部分ブロックであり、６４Ｂ
境界上のその末尾に位置合せされる。 中間パケット： 必ず６４Ｂで、必ず位置合せされる。 終了パケット： おそらく部分ブロックであり、６４Ｂ
境界上のその先頭に位置合せされる。
り長いパケット・タイプをサポートする相互接続により
その宛先に達する、開始、中間、終了の各６４Ｂパケッ
トの輪郭を示すビットを指定する。たとえば、イーサネ
ットまたは１３９４による２ＫＢパケットは、以下の３
通りのタイプのパケットに分解することができる。 開始パケット： おそらく部分ブロックであり、６４Ｂ
境界上のその末尾に位置合せされる。 中間パケット： 必ず６４Ｂで、必ず位置合せされる。 終了パケット： おそらく部分ブロックであり、６４Ｂ
境界上のその先頭に位置合せされる。
【０１４０】ブリッジによりＰ１３９４．２リングレッ
トに入る大きいパケットは、より小さいパケットに分解
することができる（たとえば、１つの大きい書込みパケ
ットは複数の６４Ｂの移動と１つの６４Ｂの書込みとに
分解される）。しかし、たとえば、１３９４宛先ノード
にブリッジするために、偶数のＳＳＯ順序付き６４Ｂの
パケットから１つの大きいパケットを再組立てするに
は、大きいパケットの構成要素部分が容易に識別できな
ければならない。大きいパケット用に設計されたプロト
コルで小さい６４Ｂのパケットを処理する場合、通常、
効率が悪くなるので、この必要性が特に強くなる。開始
／中間／終了コード化をＳＳＯ順序付け機能と組み合わ
せると、ブリッジは、配達のために非常に効率よくパケ
ットを再組立てすることができる。
トに入る大きいパケットは、より小さいパケットに分解
することができる（たとえば、１つの大きい書込みパケ
ットは複数の６４Ｂの移動と１つの６４Ｂの書込みとに
分解される）。しかし、たとえば、１３９４宛先ノード
にブリッジするために、偶数のＳＳＯ順序付き６４Ｂの
パケットから１つの大きいパケットを再組立てするに
は、大きいパケットの構成要素部分が容易に識別できな
ければならない。大きいパケット用に設計されたプロト
コルで小さい６４Ｂのパケットを処理する場合、通常、
効率が悪くなるので、この必要性が特に強くなる。開始
／中間／終了コード化をＳＳＯ順序付け機能と組み合わ
せると、ブリッジは、配達のために非常に効率よくパケ
ットを再組立てすることができる。
【０１４１】再試行の概要 非アイデンポテント・コマンドをサポートするＳＳＯ順
序付きアドレス空間のために、受信側ノードでの「使用
中」条件と、ローカル・リングレットで検出されるＣＲ
Ｃエラー条件という２通りのタイプの再試行条件を処理
しなければならない。後者の場合、「ＣＲＣエラー」
は、ソース・フィールドと宛先フィールドのいずれも信
頼できるデータを表さないほどのパケット（送信パケッ
ト、応答パケット、またはそのいずれかへのＡＣＫ）の
破壊を意味するものと想定されている。「ＣＲＣエラ
ー」という用語は、ＣＲＣエラー・コードのみに制限す
ることを意味するものと解釈すべきではなく、より一般
的には任意のエラー検出メカニズムを含むべきである。
順序付きドメインの効率のよい動作のために、「使用
中」再試行条件は比較的頻度が低いが、ＣＲＣエラー条
件よりかなり頻度が高いと想定する。しかし、いずれの
場合も、提案した方式の有効性は、「使用中」またはＣ
ＲＣエラーのいずれかのケースの発生頻度に依存してい
ない。
序付きアドレス空間のために、受信側ノードでの「使用
中」条件と、ローカル・リングレットで検出されるＣＲ
Ｃエラー条件という２通りのタイプの再試行条件を処理
しなければならない。後者の場合、「ＣＲＣエラー」
は、ソース・フィールドと宛先フィールドのいずれも信
頼できるデータを表さないほどのパケット（送信パケッ
ト、応答パケット、またはそのいずれかへのＡＣＫ）の
破壊を意味するものと想定されている。「ＣＲＣエラ
ー」という用語は、ＣＲＣエラー・コードのみに制限す
ることを意味するものと解釈すべきではなく、より一般
的には任意のエラー検出メカニズムを含むべきである。
順序付きドメインの効率のよい動作のために、「使用
中」再試行条件は比較的頻度が低いが、ＣＲＣエラー条
件よりかなり頻度が高いと想定する。しかし、いずれの
場合も、提案した方式の有効性は、「使用中」またはＣ
ＲＣエラーのいずれかのケースの発生頻度に依存してい
ない。
【０１４２】順序付きドメイン内の「使用中」再試行の
場合、エラーがなければ、「使用中」と応答する特定の
ドメインへのパケットの再試行だけが必要である。提案
した方式では、代替宛先ノードでの「使用中」条件を独
立したものとして扱う。ノードＡが一連のパケットをノ
ードＢとＣの両方に転送し、Ｂのみが「使用中」と応答
する場合、ノードＢへのパケットだけが再試行される。
場合、エラーがなければ、「使用中」と応答する特定の
ドメインへのパケットの再試行だけが必要である。提案
した方式では、代替宛先ノードでの「使用中」条件を独
立したものとして扱う。ノードＡが一連のパケットをノ
ードＢとＣの両方に転送し、Ｂのみが「使用中」と応答
する場合、ノードＢへのパケットだけが再試行される。
【０１４３】ＣＲＣエラー・パケット（送信／応答パケ
ットまたはＡＣＫのいずれか）は最終的に送信側ノード
で検出される。ＳＳＯ順序付きドメインでは、この検出
は、「順序エラー」（タイムアウト前にＡＣＫ＿ｅｒｒ
応答が検出される）またはリングレット・タイムアウト
（肯定応答なしで２回循環する）のいずれかになる可能
性がある。ＳＳＯ順序付きドメイン内の受信側ノード
は、何らかのノードから順序エラーが検出された場合に
ＣＲＣエラーの発生後に各送信／応答パケットを拒否す
るためにＡＣＫ＿ｅｒｒｏｒを送信するという責任を負
っているが、そうではない場合はエラー状態情報を維持
する必要はない。そのパケットまたはＡＣＫのいずれか
でＣＲＣエラーが発生したと送信側ノードが検出する
と、そのノードは、最後の有効完了パケットの点から、
エラーが検出され、パケット伝送が停止される前に送信
された最後の未解決パケットまで、すべての未解決ＳＳ
Ｏ順序付きドメイン・パケットを再試行しなければなら
ない。非ＳＳＯドメインでＣＲＣエラーを再試行するた
めの方針については、ここでは指定しない。
ットまたはＡＣＫのいずれか）は最終的に送信側ノード
で検出される。ＳＳＯ順序付きドメインでは、この検出
は、「順序エラー」（タイムアウト前にＡＣＫ＿ｅｒｒ
応答が検出される）またはリングレット・タイムアウト
（肯定応答なしで２回循環する）のいずれかになる可能
性がある。ＳＳＯ順序付きドメイン内の受信側ノード
は、何らかのノードから順序エラーが検出された場合に
ＣＲＣエラーの発生後に各送信／応答パケットを拒否す
るためにＡＣＫ＿ｅｒｒｏｒを送信するという責任を負
っているが、そうではない場合はエラー状態情報を維持
する必要はない。そのパケットまたはＡＣＫのいずれか
でＣＲＣエラーが発生したと送信側ノードが検出する
と、そのノードは、最後の有効完了パケットの点から、
エラーが検出され、パケット伝送が停止される前に送信
された最後の未解決パケットまで、すべての未解決ＳＳ
Ｏ順序付きドメイン・パケットを再試行しなければなら
ない。非ＳＳＯドメインでＣＲＣエラーを再試行するた
めの方針については、ここでは指定しない。
【０１４４】使用中再試行の例 このメカニズムがどのように機能するかをより適切に視
覚化するために、詳細説明を示す前に例を使用してＳＳ
Ｏ順序付けサポート用のメカニズム案を例示する。
覚化するために、詳細説明を示す前に例を使用してＳＳ
Ｏ順序付けサポート用のメカニズム案を例示する。
【０１４５】ケース１： ノードＡからノードＣへの使
用中再試行： 送信パケットの観点からのパケット順序付け：
用中再試行： 送信パケットの観点からのパケット順序付け：
【０１４６】この例に関するいくつかの所見：パケット
は送信ポートを介して生成されるが、使用中肯定応答は
受信ポートで非同期に検出される。使用中再試行ループ
では、第１の再試行使用中パケット（２４）を再伝送す
る前にすべての未解決先行トランザクションに肯定応答
しなければならない。また、いつ使用中パケットを再試
行すべきかという判断は、新しいトランザクションの到
着速度など、実施上の他の考慮事項によって決まる可能
性がある。この例のパケット２３は、使用中ループがパ
ケット２１および２３を再番号付けした（ｐＬａｂｅ
ｌ．ｓｅｑ）パケット２４および２５として再送信する
前に送信される最後のパケットになる。使用中のマーク
が付けられたパケット（この例では、パケット２１から
始まるノードＣへのパケットのみ）だけが再試行され
る。完了したパケットを再試行する必要はない。新しい
順序番号は、ノードＡによって再試行したパケットに割
り当てられる。第１の「使用中」パケットがノードＣ
（パケット２１）で肯定応答されると、同じかまたはそ
れ以上の順序番号がノードＣにアドレス指定されたすべ
てのパケット（この例ではパケット２３）は、第１の
「使用中」パケットが再試行される（「ｂｚｓｅｑ」の
変更によって示される）まで、「ａｃｋ＿ｂｕｓｙ」に
よって拒否しなければならない。エラー再試行ループで
は、２１の前にパケットが再伝送される可能性がある。
この場合、それが（間違って）再試行されるのを防止す
るため、そのパケットは「ａｃｋ＿ｄｏｎｅ」として拒
否され肯定応答されるはずである。第１の「使用中」パ
ケットに肯定応答する他のすべてのノードは同じように
動作しなければならない（この例には示さない）。ＳＳ
Ｏ順序付けは、送信側ノードからその潜在的な受信側ノ
ードのそれぞれへ、対単位で維持される。しかし、ノー
ドＡがノードＢに対してＳＳＯ順序付きパケットを送信
し、ＡがノードＢにもＳＳＯ順序付きパケットを送信す
る場合、結果的に、対単位のＳＳＯを正しくするために
ノードＢとＣとの間の相対的な順序付けパケット到着を
維持しなければならないというわけでは「ない」。この
ｐｒｏｄｕｃｅｒＩｄノードによる使用中再試行ループ
の開始は、ｐＬａｂｅｌ．ｂｚｓｅｑフィールドを（１
から０に）補足することにより、すべてのリングレット
・ノードに通知される。このスワップは、そのｓｅｑＴ
ａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］値を着
信ｐＬａｂｅｌ．ｂｚｓｅｑと比較することにより、各
リングレット・ノードで検出することができる。両方の
値が一致しない場合、ｓｅｑＴａｂｌｅ値は以下のよう
に書き換えられる。 ｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩ
ｄ］ ＝ ｐＬａｂｅｌ．ｂｚｓｅｑ また、再試行した使用中パケットが受信バッファに受け
入れられた場合、「使用中」ビットは以下のようにリセ
ットされる。 ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］
＝ ０ すべての他の（非受信側）ノードの場合、ｓｅｑＴａｂ
ｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］は０に設定さ
れる。
は送信ポートを介して生成されるが、使用中肯定応答は
受信ポートで非同期に検出される。使用中再試行ループ
では、第１の再試行使用中パケット（２４）を再伝送す
る前にすべての未解決先行トランザクションに肯定応答
しなければならない。また、いつ使用中パケットを再試
行すべきかという判断は、新しいトランザクションの到
着速度など、実施上の他の考慮事項によって決まる可能
性がある。この例のパケット２３は、使用中ループがパ
ケット２１および２３を再番号付けした（ｐＬａｂｅ
ｌ．ｓｅｑ）パケット２４および２５として再送信する
前に送信される最後のパケットになる。使用中のマーク
が付けられたパケット（この例では、パケット２１から
始まるノードＣへのパケットのみ）だけが再試行され
る。完了したパケットを再試行する必要はない。新しい
順序番号は、ノードＡによって再試行したパケットに割
り当てられる。第１の「使用中」パケットがノードＣ
（パケット２１）で肯定応答されると、同じかまたはそ
れ以上の順序番号がノードＣにアドレス指定されたすべ
てのパケット（この例ではパケット２３）は、第１の
「使用中」パケットが再試行される（「ｂｚｓｅｑ」の
変更によって示される）まで、「ａｃｋ＿ｂｕｓｙ」に
よって拒否しなければならない。エラー再試行ループで
は、２１の前にパケットが再伝送される可能性がある。
この場合、それが（間違って）再試行されるのを防止す
るため、そのパケットは「ａｃｋ＿ｄｏｎｅ」として拒
否され肯定応答されるはずである。第１の「使用中」パ
ケットに肯定応答する他のすべてのノードは同じように
動作しなければならない（この例には示さない）。ＳＳ
Ｏ順序付けは、送信側ノードからその潜在的な受信側ノ
ードのそれぞれへ、対単位で維持される。しかし、ノー
ドＡがノードＢに対してＳＳＯ順序付きパケットを送信
し、ＡがノードＢにもＳＳＯ順序付きパケットを送信す
る場合、結果的に、対単位のＳＳＯを正しくするために
ノードＢとＣとの間の相対的な順序付けパケット到着を
維持しなければならないというわけでは「ない」。この
ｐｒｏｄｕｃｅｒＩｄノードによる使用中再試行ループ
の開始は、ｐＬａｂｅｌ．ｂｚｓｅｑフィールドを（１
から０に）補足することにより、すべてのリングレット
・ノードに通知される。このスワップは、そのｓｅｑＴ
ａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］値を着
信ｐＬａｂｅｌ．ｂｚｓｅｑと比較することにより、各
リングレット・ノードで検出することができる。両方の
値が一致しない場合、ｓｅｑＴａｂｌｅ値は以下のよう
に書き換えられる。 ｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒＩ
ｄ］ ＝ ｐＬａｂｅｌ．ｂｚｓｅｑ また、再試行した使用中パケットが受信バッファに受け
入れられた場合、「使用中」ビットは以下のようにリセ
ットされる。 ｓｅｑＴａｂｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］
＝ ０ すべての他の（非受信側）ノードの場合、ｓｅｑＴａｂ
ｌｅ．ｂｕｓｙ［ｐｒｏｄｕｃｅｒＩｄ］は０に設定さ
れる。
【０１４７】ＣＲＣエラー再試行の例 使用中肯定応答を行わないＣＲＣエラー再試行の２つの
例を、使用中再試行ループ周辺で発生するＣＲＣエラー
の一例ととともに以下に示す。
例を、使用中再試行ループ周辺で発生するＣＲＣエラー
の一例ととともに以下に示す。
【０１４８】ケース１： ノードＣで検出されたノード
Ｃへの送信パケット上のＣＲＣエラー送信パケットの観
点からのパケット順序付け：
Ｃへの送信パケット上のＣＲＣエラー送信パケットの観
点からのパケット順序付け：
【０１４９】この例に関するいくつかの注意事項：ＣＲ
Ｃエラーの検出は、送信ノードから非同期に受信ノード
内で行われる。この例では、２１のＣＲＣエラーが検出
される前にパケット２２および２３が伝送される。ＣＲ
Ｃエラーが発生しうる個所が多いので、様々なノードは
様々なやり方でエラーを検出できる場合もあれば、検出
できない場合もある。この例では、ノードＢの後でＣＲ
Ｃエラーが発生しているので、順序エラーは決して発生
しない。これに対して、ノードＣはパケット２１を検出
できず、後続のパケット／ａｃｋ２２および２３に順序
エラーが発生していることを検出する。というのは、最
後に記録されたその順序値が２０であるからである。Ｃ
ＲＣエラーが送信側で検出されると、各ローカル・リン
グレット・ノードのｓｅｑＴａｂｌｅ．ｓｅｑ［ｐｒｏ
ｄｕｃｅｒＩｄ］フィールド内で順序カウントを（２０
まで）再確立するために、そのＣＲＣエラー・ループ
は、エラー（パケット２０）の前に、必要であれば繰返
し、まず最後の良好パケットを再伝送しなければならな
い。受信側ノードのｓｅｑＴａｂｌｅ．ａｃｐｔ［ｐｒ
ｏｄｕｃｅｒＩｄ］フィールドとの比較に基づいて、タ
ーゲットとは無関係に、このパケットは必ず拒否され
る。既知の有効パケット用の順序番号とともに、ｐｒｏ
ｄｕｃｅｒＩｄもｐＬａｂｅｌに入れて現行のｂｚｓｅ
ｑ値を送出し、すべてのｓｅｑＴａｂｌｅ．ｂｚｓｅｑ
［ｐｒｏｄｕｃｅｒＩｄ］を既知の良好状態に設定す
る。ｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒ
Ｉｄ］値はリセットされるが、各ノードのｓｅｑＴａｂ
ｌｅ．ｂｕｓｙ［］フィールドとｓｅｑＴａｂｌｅ．ａ
ｃｐｔ［］フィールドは保持しなければならない。これ
らのフィールドは、この宛先用の正しい応答ａｃｋ、実
行済み、または使用中によってＣＲＣエラー再試行ルー
プでパケットを受け入れるかまたは拒否するために必要
な状態を表す。この例では、ノードＢは送信／応答パケ
ット２２を拒否し、ノードＣはパケット２１と２３の両
方を新しいパケットとして受け入れる。送信側は、新し
いパケットを停止させた点まで、この場合はパケット２
３まで伝送されたすべてのパケットを再送信しなければ
ならない。エラーがない場合、ノードＢとＣは順序番号
を追跡する。
Ｃエラーの検出は、送信ノードから非同期に受信ノード
内で行われる。この例では、２１のＣＲＣエラーが検出
される前にパケット２２および２３が伝送される。ＣＲ
Ｃエラーが発生しうる個所が多いので、様々なノードは
様々なやり方でエラーを検出できる場合もあれば、検出
できない場合もある。この例では、ノードＢの後でＣＲ
Ｃエラーが発生しているので、順序エラーは決して発生
しない。これに対して、ノードＣはパケット２１を検出
できず、後続のパケット／ａｃｋ２２および２３に順序
エラーが発生していることを検出する。というのは、最
後に記録されたその順序値が２０であるからである。Ｃ
ＲＣエラーが送信側で検出されると、各ローカル・リン
グレット・ノードのｓｅｑＴａｂｌｅ．ｓｅｑ［ｐｒｏ
ｄｕｃｅｒＩｄ］フィールド内で順序カウントを（２０
まで）再確立するために、そのＣＲＣエラー・ループ
は、エラー（パケット２０）の前に、必要であれば繰返
し、まず最後の良好パケットを再伝送しなければならな
い。受信側ノードのｓｅｑＴａｂｌｅ．ａｃｐｔ［ｐｒ
ｏｄｕｃｅｒＩｄ］フィールドとの比較に基づいて、タ
ーゲットとは無関係に、このパケットは必ず拒否され
る。既知の有効パケット用の順序番号とともに、ｐｒｏ
ｄｕｃｅｒＩｄもｐＬａｂｅｌに入れて現行のｂｚｓｅ
ｑ値を送出し、すべてのｓｅｑＴａｂｌｅ．ｂｚｓｅｑ
［ｐｒｏｄｕｃｅｒＩｄ］を既知の良好状態に設定す
る。ｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄｕｃｅｒ
Ｉｄ］値はリセットされるが、各ノードのｓｅｑＴａｂ
ｌｅ．ｂｕｓｙ［］フィールドとｓｅｑＴａｂｌｅ．ａ
ｃｐｔ［］フィールドは保持しなければならない。これ
らのフィールドは、この宛先用の正しい応答ａｃｋ、実
行済み、または使用中によってＣＲＣエラー再試行ルー
プでパケットを受け入れるかまたは拒否するために必要
な状態を表す。この例では、ノードＢは送信／応答パケ
ット２２を拒否し、ノードＣはパケット２１と２３の両
方を新しいパケットとして受け入れる。送信側は、新し
いパケットを停止させた点まで、この場合はパケット２
３まで伝送されたすべてのパケットを再送信しなければ
ならない。エラーがない場合、ノードＢとＣは順序番号
を追跡する。
【０１５０】ケース２： ノードＡで検出されたノード
Ｃからの肯定応答パケット上のＣＲＣエラー 送信パケットの観点からのパケット順序付け： 送信パケットの観点からのパケット順序付け：
Ｃからの肯定応答パケット上のＣＲＣエラー 送信パケットの観点からのパケット順序付け： 送信パケットの観点からのパケット順序付け：
【０１５１】この例は、パケットがその宛先で受け入れ
られたかどうかを送信側ノードが検出できないことを示
している。この例のノードＣではエラーが発生していな
いので、パケット２１と２３はどちらも有効なｐＬａｂ
ｅｌ．ｓｅｑフィールドを有し、ＡＣＫ＿ｄｏｎｅ応答
が与えられる。
られたかどうかを送信側ノードが検出できないことを示
している。この例のノードＣではエラーが発生していな
いので、パケット２１と２３はどちらも有効なｐＬａｂ
ｅｌ．ｓｅｑフィールドを有し、ＡＣＫ＿ｄｏｎｅ応答
が与えられる。
【０１５２】ケース３： ノードＢ用の使用中再試行ル
ープを開始する前にノードＣで検出されたノードＣへの
送信パケット上のＣＲＣエラー 送信パケットの観点からのパケット順序付け：
ープを開始する前にノードＣで検出されたノードＣへの
送信パケット上のＣＲＣエラー 送信パケットの観点からのパケット順序付け：
【０１５３】この例は、以下の一連の事象に基づくもの
である。ノードＢには２つの送信／応答パケット２１お
よび２３が送信され、そのノードはこれらを使用中とし
て拒否する。ノードＣにはパケット２２が送信される
が、そのノードにＣＲＣエラーがあるので、このパケッ
トはそこで検出されない。ノードＢではエラーが一切検
出されない。ノードＡは、まず未解決Ａｃｋの完了を待
つことにより、ノードＢのパケットに関してその使用中
再試行を開始する。次にノードＡはＣＲＣエラーを検出
する。これはＣＲＣエラー・ループを開始するが、この
ループは２１（エラー前の最後の良好パケット）から２
３（エラーが検出される前に最後に送信したパケット）
までのすべてのパケットを含まなければならない。
である。ノードＢには２つの送信／応答パケット２１お
よび２３が送信され、そのノードはこれらを使用中とし
て拒否する。ノードＣにはパケット２２が送信される
が、そのノードにＣＲＣエラーがあるので、このパケッ
トはそこで検出されない。ノードＢではエラーが一切検
出されない。ノードＡは、まず未解決Ａｃｋの完了を待
つことにより、ノードＢのパケットに関してその使用中
再試行を開始する。次にノードＡはＣＲＣエラーを検出
する。これはＣＲＣエラー・ループを開始するが、この
ループは２１（エラー前の最後の良好パケット）から２
３（エラーが検出される前に最後に送信したパケット）
までのすべてのパケットを含まなければならない。
【０１５４】この例では、ＣＲＣエラー再試行ループに
入ると、ｐＬａｂｅｌ．ｓｅｑ値およびノードＢのｓｅ
ｑＴａｂｌｅ．ｂｕｓｙ［］フィールドとｓｅｑＴａｂ
ｌｅ．ａｃｐｔ［］フィールドに基づいて、エラー・ル
ープで再試行したノードＢへのパケットが拒否される。
ｓｅｑＴａｂｌｅ．ｂｕｓｙ［］ビットが設定されてい
るので、パケットは拒否される。また、ｓｅｑＴａｂｌ
ｅ．ｂｕｓｙ［］が設定されているが、（ｐＬａｂｅ
ｌ．ｓｅｑ値とｓｅｑＴａｂｌｅ．ａｃｐｔ［］フィー
ルドとの比較に基づいて）どちらのパケットも最初に
「使用中」のマークが付けられているので、再試行した
パケット２１と２３はどちらも「使用中」として肯定応
答される。
入ると、ｐＬａｂｅｌ．ｓｅｑ値およびノードＢのｓｅ
ｑＴａｂｌｅ．ｂｕｓｙ［］フィールドとｓｅｑＴａｂ
ｌｅ．ａｃｐｔ［］フィールドに基づいて、エラー・ル
ープで再試行したノードＢへのパケットが拒否される。
ｓｅｑＴａｂｌｅ．ｂｕｓｙ［］ビットが設定されてい
るので、パケットは拒否される。また、ｓｅｑＴａｂｌ
ｅ．ｂｕｓｙ［］が設定されているが、（ｐＬａｂｅ
ｌ．ｓｅｑ値とｓｅｑＴａｂｌｅ．ａｃｐｔ［］フィー
ルドとの比較に基づいて）どちらのパケットも最初に
「使用中」のマークが付けられているので、再試行した
パケット２１と２３はどちらも「使用中」として肯定応
答される。
【０１５５】使用中ループが最終的に開始されると、ノ
ードＡからのｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄ
ｕｃｅｒＩｄ］フィールドにより変換が行われ、パケッ
ト２１がパケット２４として再伝送される。ノードＢは
このトランザクションを検出し、その受信バッファが一
杯であるかどうかに基づいて、パケット２４を受け入れ
られるかどうかを評価する。ここで想定する例では、再
試行したパケット２４および２５がどちらも受け入れら
れる。
ードＡからのｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［ｐｒｏｄ
ｕｃｅｒＩｄ］フィールドにより変換が行われ、パケッ
ト２１がパケット２４として再伝送される。ノードＢは
このトランザクションを検出し、その受信バッファが一
杯であるかどうかに基づいて、パケット２４を受け入れ
られるかどうかを評価する。ここで想定する例では、再
試行したパケット２４および２５がどちらも受け入れら
れる。
【０１５６】潜在的にエラーが存在する場合に使用中再
試行ループを開始するための基本概念は、最初に再試行
した使用中パケットより前のすべてのパケットの肯定応
答が受信され、良好として検査されるまで、ループの開
始を待つことである。これが必要である理由は、ｐＬａ
ｂｅｌ．ｂｚｓｅｑビットの状態を変更するとすべての
ノード・パケットがそのｓｅｑＴａｂｌｅ．ｂｕｓ
ｙ［］フィールドとｓｅｑＴａｂｌｅ．ａｃｐｔ［］フ
ィールドをリセットするからである。これらのフィール
ドは、使用中再試行ループの前にパケット受入れ／拒否
および肯定応答を生成するためにエラー再試行状態を維
持している。これらのフィールドがリセットされるの
は、未解決のままのエラー条件がまったくないことをノ
ードＡが確認した場合に限られる。
試行ループを開始するための基本概念は、最初に再試行
した使用中パケットより前のすべてのパケットの肯定応
答が受信され、良好として検査されるまで、ループの開
始を待つことである。これが必要である理由は、ｐＬａ
ｂｅｌ．ｂｚｓｅｑビットの状態を変更するとすべての
ノード・パケットがそのｓｅｑＴａｂｌｅ．ｂｕｓ
ｙ［］フィールドとｓｅｑＴａｂｌｅ．ａｃｐｔ［］フ
ィールドをリセットするからである。これらのフィール
ドは、使用中再試行ループの前にパケット受入れ／拒否
および肯定応答を生成するためにエラー再試行状態を維
持している。これらのフィールドがリセットされるの
は、未解決のままのエラー条件がまったくないことをノ
ードＡが確認した場合に限られる。
【０１５７】作成側ノード： 要求待ち行列状態 好ましい実施形態の各作成側ノードは、１つのレジスタ
に加えて以下の３通りのタイプの発信側待ち行列と、２
通りのタイプの着信側待ち行列または構造（図４０を参
照）を有することができる。 発信側： １．おそらくトランザクション層（リンク層の上）内に
あって未発行要求からなる新規要求待ち行列 ２．同じくトランザクション層内にあって他のノードへ
の未発行応答パケットからなる応答保留待ち行列 ３．リンク層内にあって、リングレットに対して発行さ
れる処理中の送信および応答パケットからなる「ｓｅｎ
ｄ＿ｐｋｔ」待ち行列 ４．再試行すべき使用中パケットからなる「ｒｅｔｒｙ
＿ｐｋｔ」待ち行列［これは使用中再試行の実施形態に
のみ適用されることに留意されたい。］ ５．ｒｅｔｒｙ＿ｐｋｔ待ち行列を充填し、エラー再試
行用のパケットをｓｅｎｄ＿ｐｋｔ待ち行列にリサイク
ルするための「ｒｅｔｒｙ＿ｐｋｔ」レジスタ着信側： １．リンク層内にあってこのノードへの着信肯定応答か
らなる待ち行列 ２．トランザクション層内にあって、応答を待っている
要求用の構造
に加えて以下の３通りのタイプの発信側待ち行列と、２
通りのタイプの着信側待ち行列または構造（図４０を参
照）を有することができる。 発信側： １．おそらくトランザクション層（リンク層の上）内に
あって未発行要求からなる新規要求待ち行列 ２．同じくトランザクション層内にあって他のノードへ
の未発行応答パケットからなる応答保留待ち行列 ３．リンク層内にあって、リングレットに対して発行さ
れる処理中の送信および応答パケットからなる「ｓｅｎ
ｄ＿ｐｋｔ」待ち行列 ４．再試行すべき使用中パケットからなる「ｒｅｔｒｙ
＿ｐｋｔ」待ち行列［これは使用中再試行の実施形態に
のみ適用されることに留意されたい。］ ５．ｒｅｔｒｙ＿ｐｋｔ待ち行列を充填し、エラー再試
行用のパケットをｓｅｎｄ＿ｐｋｔ待ち行列にリサイク
ルするための「ｒｅｔｒｙ＿ｐｋｔ」レジスタ着信側： １．リンク層内にあってこのノードへの着信肯定応答か
らなる待ち行列 ２．トランザクション層内にあって、応答を待っている
要求用の構造
【０１５８】トランザクション層内の発信側送信および
応答パケットの場合、場合によっては待ち行列が複数の
待ち行列である可能性があり、その待ち行列間に順序付
けの依存関係はまったくない。一例としては、スイッチ
の複数ポートである。
応答パケットの場合、場合によっては待ち行列が複数の
待ち行列である可能性があり、その待ち行列間に順序付
けの依存関係はまったくない。一例としては、スイッチ
の複数ポートである。
【０１５９】ＳＳＯ順序付けモードでのこのノードへの
応答パケットの場合、所与の宛先ノードからの応答は必
ず順番に到着するが、異なるノード間の応答に関して順
序付けは一切保証されない。その結果、応答を待ってい
る送信パケット構造は、待ち行列ではなくむしろ構造と
して示される。
応答パケットの場合、所与の宛先ノードからの応答は必
ず順番に到着するが、異なるノード間の応答に関して順
序付けは一切保証されない。その結果、応答を待ってい
る送信パケット構造は、待ち行列ではなくむしろ構造と
して示される。
【０１６０】ＳＳＯ順序付け空間での応答パケットの使
用法 ＩＥＥＥ Ｐ１３９４．２では、宛先ノードにデータを
書き込むための動作として、応答なし移動トランザクシ
ョンと応答付き書込みトランザクションという２通りの
タイプの動作を指定している。ＳＳＯ順序付け構造は、
順序付けられたデータの配達を保証するものである。移
動トランザクションと書込みトランザクションの相違点
は何であろうか。
用法 ＩＥＥＥ Ｐ１３９４．２では、宛先ノードにデータを
書き込むための動作として、応答なし移動トランザクシ
ョンと応答付き書込みトランザクションという２通りの
タイプの動作を指定している。ＳＳＯ順序付け構造は、
順序付けられたデータの配達を保証するものである。移
動トランザクションと書込みトランザクションの相違点
は何であろうか。
【０１６１】書込み送信パケットは、書込みデータが実
際にこのノードに達したことを示す、宛先ノードによっ
て生成された明確な指示を行う。すなわち、これは、動
作の完了を明確に示す。移動送信パケットは、完了の明
確な指示は行わない。
際にこのノードに達したことを示す、宛先ノードによっ
て生成された明確な指示を行う。すなわち、これは、動
作の完了を明確に示す。移動送信パケットは、完了の明
確な指示は行わない。
【０１６２】この相違から２つの質問が発生する。 １．完了の明確な指示は何のために使用できるか。 ２．特に無効アドレスと、新しいパケットの受入れを拒
否する「膠着」受信側ノードとを含む、不完全なリンク
・トポロジで順序付けが維持されていることを確認する
ために、どのようなアーキテクチャ上の拡張を移動トラ
ンザクションと結合することができるか。書込みトラン
ザクションに関する完了の明確な指示は、トランザクシ
ョン層から見えるものになる。これより上の何らかのシ
ステム・レベルでこれが見えるようになるかどうかは、
この説明の範囲を超えたトランザクション・レベルのア
ーキテクチャによって決まる。ＳＳＯ順序付けのポイン
トは、順序付けを確保するためにいかなる構造も不要で
あるということである。
否する「膠着」受信側ノードとを含む、不完全なリンク
・トポロジで順序付けが維持されていることを確認する
ために、どのようなアーキテクチャ上の拡張を移動トラ
ンザクションと結合することができるか。書込みトラン
ザクションに関する完了の明確な指示は、トランザクシ
ョン層から見えるものになる。これより上の何らかのシ
ステム・レベルでこれが見えるようになるかどうかは、
この説明の範囲を超えたトランザクション・レベルのア
ーキテクチャによって決まる。ＳＳＯ順序付けのポイン
トは、順序付けを確保するためにいかなる構造も不要で
あるということである。
【０１６３】トランザクション層内の書込みトランザク
ションに可能な使い方は２通りある。このリストはほと
んど網羅的ではない。第１に、書込みトランザクション
は信頼性アーキテクチャ用の基礎として使用することが
できる。送信パケットが指定の期間内に応答を受信でき
なかった場合、ノード・タイムアウトが報告されるはず
である。この使用法では、次の送信パケットを開始する
前に応答を完了するための事前要件はまったく存在しな
い。
ションに可能な使い方は２通りある。このリストはほと
んど網羅的ではない。第１に、書込みトランザクション
は信頼性アーキテクチャ用の基礎として使用することが
できる。送信パケットが指定の期間内に応答を受信でき
なかった場合、ノード・タイムアウトが報告されるはず
である。この使用法では、次の送信パケットを開始する
前に応答を完了するための事前要件はまったく存在しな
い。
【０１６４】書込みトランザクション用の第２の使用法
は、可用性の高いアーキテクチャ用の基礎として使用す
ることである。この応用例では、書込みに対する応答が
「書込みコミット」の完了を安定した記憶装置に通知す
る。これに関する問題は、どのように応答を処理するか
ということである。それを使用して次の送信パケットの
伝送をゲートするのだろうか。そのような場合、これに
より、パケット配達速度は大幅に低下する。システム・
アーキテクチャは、完了バリア・インジケータとして応
答を使用するためのメカニズムをサポートしているか。
ほとんどは（ＵＰＡを含む）サポートしていない。
は、可用性の高いアーキテクチャ用の基礎として使用す
ることである。この応用例では、書込みに対する応答が
「書込みコミット」の完了を安定した記憶装置に通知す
る。これに関する問題は、どのように応答を処理するか
ということである。それを使用して次の送信パケットの
伝送をゲートするのだろうか。そのような場合、これに
より、パケット配達速度は大幅に低下する。システム・
アーキテクチャは、完了バリア・インジケータとして応
答を使用するためのメカニズムをサポートしているか。
ほとんどは（ＵＰＡを含む）サポートしていない。
【０１６５】送信パケット待ち行列構造 Ｐ１３９４．２に応じたアドレス空間は、一般に、順序
付けされる場合もあれば、順序付けされない場合もある
ので、ノードは、両方のアドレス指定モデルを識別しサ
ポートするために各コマンドごとにデータの構造を維持
しなければならない。この構造案は以下のように３つの
フィールドからなる。 Send_pktＳＳＯ構造、送信または応答パケット当たり１
つずつ send_pkt.val (1) /* 項目有効 */ send_pkt.sso (1) /* コマンド・アドレス空間か
ら */ send_pkt.done (1) /* ACK_doneを受信、応答が必
要な場合もある*/ send_pkt.busy (1) /* ACK_busyを受信、再試行待
ち */ send_pkt.init_er (1) /* エラー再試行ループ内の初
期（第１の）パケット */ send_pkt.no_xmit (1) /* エラー・ループ中にリング
レットへの伝送なし*/ send_pkt.err_ret (1) /* エラー再試行ループ内のエ
ラー再試行状態*/ send_pkt.seq (6) /* この送信／応答パケット用
の順序番号 */ send_pkt.packet (N) /* Ｎビットの送信／受信パケ
ット */ その他の制御ビットは、ここに記載するＳＳＯ順序付け
を上回る実施目的に使用することができる。
付けされる場合もあれば、順序付けされない場合もある
ので、ノードは、両方のアドレス指定モデルを識別しサ
ポートするために各コマンドごとにデータの構造を維持
しなければならない。この構造案は以下のように３つの
フィールドからなる。 Send_pktＳＳＯ構造、送信または応答パケット当たり１
つずつ send_pkt.val (1) /* 項目有効 */ send_pkt.sso (1) /* コマンド・アドレス空間か
ら */ send_pkt.done (1) /* ACK_doneを受信、応答が必
要な場合もある*/ send_pkt.busy (1) /* ACK_busyを受信、再試行待
ち */ send_pkt.init_er (1) /* エラー再試行ループ内の初
期（第１の）パケット */ send_pkt.no_xmit (1) /* エラー・ループ中にリング
レットへの伝送なし*/ send_pkt.err_ret (1) /* エラー再試行ループ内のエ
ラー再試行状態*/ send_pkt.seq (6) /* この送信／応答パケット用
の順序番号 */ send_pkt.packet (N) /* Ｎビットの送信／受信パケ
ット */ その他の制御ビットは、ここに記載するＳＳＯ順序付け
を上回る実施目的に使用することができる。
【０１６６】概念上、ｓｅｎｄ＿ｐｋｔ[]はＦＩＦＯ待
ち行列と見なすことができ、対応するＦＩＦＯ内の肯定
応答パケットが受信されると、新たに送信されたパケッ
トは一番上に入り、終了したパケットは一番下から出て
いく。「ａｃｋ＿ｄｏｎｅ」として肯定応答された送信
パケットは、応答を待っている可能性がある。
ち行列と見なすことができ、対応するＦＩＦＯ内の肯定
応答パケットが受信されると、新たに送信されたパケッ
トは一番上に入り、終了したパケットは一番下から出て
いく。「ａｃｋ＿ｄｏｎｅ」として肯定応答された送信
パケットは、応答を待っている可能性がある。
【０１６７】ｓｅｎｄ＿ｐｋｔＦＩＦＯ待ち行列に加
え、他の待ち行列、レジスタ、ＭＵＸ、状態マシン、制
御論理については、補助の流れ図に示す。
え、他の待ち行列、レジスタ、ＭＵＸ、状態マシン、制
御論理については、補助の流れ図に示す。
【０１６８】ＣＲＣエラー・ループ用の作成側ノード・
ポインタ ＣＲＣエラー・ループおよび使用中再試行ループの処理
には、所与の作成側ノード変数が必要である。ＣＲＣエ
ラー・ループ動作用のグローバル変数として以下のもの
がある。この場合、接頭部「ｏｒ＿」は「順序付き」を
意味する。 or_last_ct (6) /* ローカル・リングレットに
送信された最新ＳＳＯ順序付きｐｋｔ用の順序カウント
*/ no_last_ct (6) /* ローカル・リングレットに
送信された最新非ＳＳＯ順序付きｐｋｔ用の順序カウン
ト */ or_rcvd_ct (6) /* ローカル・リングレットか
ら受信した最新ＳＳＯ順序付きｐｋｔ用の順序カウント
*/
ポインタ ＣＲＣエラー・ループおよび使用中再試行ループの処理
には、所与の作成側ノード変数が必要である。ＣＲＣエ
ラー・ループ動作用のグローバル変数として以下のもの
がある。この場合、接頭部「ｏｒ＿」は「順序付き」を
意味する。 or_last_ct (6) /* ローカル・リングレットに
送信された最新ＳＳＯ順序付きｐｋｔ用の順序カウント
*/ no_last_ct (6) /* ローカル・リングレットに
送信された最新非ＳＳＯ順序付きｐｋｔ用の順序カウン
ト */ or_rcvd_ct (6) /* ローカル・リングレットか
ら受信した最新ＳＳＯ順序付きｐｋｔ用の順序カウント
*/
【０１６９】ローカル・リングレットにパケットが送信
されると、パケット・パスでｓｅｎｄ＿ｐｋｔレジスタ
内に伝達されるｓｅｎｄ＿ｐｋｔフィールドと一致する
ように、そのｐＬａｂｅｌフィールドが設定される。一
般に、以下のようになる。 pLabel.sso = send_pkt_reg.sso pLabel.bzseq = bzseq /* グローバル作成側ノードの
状態ビット */ pLabel.seq = send_pkt_reg.seq ｐＬａｂｅｌ．ｓｅｑにどの値が割り当てられるかは、
動作（たとえば、新しいパケット、使用中再試行パケッ
ト、またはＣＲＣ再試行）によって決まる。以下に示す
詳細を参照されたい。
されると、パケット・パスでｓｅｎｄ＿ｐｋｔレジスタ
内に伝達されるｓｅｎｄ＿ｐｋｔフィールドと一致する
ように、そのｐＬａｂｅｌフィールドが設定される。一
般に、以下のようになる。 pLabel.sso = send_pkt_reg.sso pLabel.bzseq = bzseq /* グローバル作成側ノードの
状態ビット */ pLabel.seq = send_pkt_reg.seq ｐＬａｂｅｌ．ｓｅｑにどの値が割り当てられるかは、
動作（たとえば、新しいパケット、使用中再試行パケッ
ト、またはＣＲＣ再試行）によって決まる。以下に示す
詳細を参照されたい。
【０１７０】受信側ポインタ比較：折返しモジュロ６４
カウントのサポート 上記の「提案の概要」の項により、受信側の動作にとっ
て３通りの比較が重要になる可能性があることに留意さ
れたい。 １．受信側ノードは、以下の場合に、所与のｐｒｏｄｕ
ｃｅｒＩｄから有効な新しいＳＳＯ順序付きパケットを
検出することができる。 pLabel.seq = seqTable.seq[producerId] + 1 かつ pLabel.seq > seqTable.acpt[producerId] ２．このｐｒｏｄｕｃｅｒＩｄがＣＲＣエラー・ループ
を実行していることをこのノードが検出すると、ｓｅｑ
Ｔａｂｌｅ．ｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］フィール
ドは現行のｐＬａｂｅｌ．ｓｅｑ値にリセットされる。
これは、このノードからのパケットまたは肯定応答用の
ｓｅｑフィールドを比較することによって示される。 if {pLabel.seq <= seqTable.seq[producerId]} then {seqTable.seq[producerId] = pLabel.seq } ３．最後に、各ノードは、以下の場合に、ｐｒｏｄｕｃ
ｅｒＩｄから順序エラーを含むパケットを検出すること
ができる。 pLabel.seq > seqTable.seq[producerId] + 1
カウントのサポート 上記の「提案の概要」の項により、受信側の動作にとっ
て３通りの比較が重要になる可能性があることに留意さ
れたい。 １．受信側ノードは、以下の場合に、所与のｐｒｏｄｕ
ｃｅｒＩｄから有効な新しいＳＳＯ順序付きパケットを
検出することができる。 pLabel.seq = seqTable.seq[producerId] + 1 かつ pLabel.seq > seqTable.acpt[producerId] ２．このｐｒｏｄｕｃｅｒＩｄがＣＲＣエラー・ループ
を実行していることをこのノードが検出すると、ｓｅｑ
Ｔａｂｌｅ．ｓｅｑ［ｐｒｏｄｕｃｅｒＩｄ］フィール
ドは現行のｐＬａｂｅｌ．ｓｅｑ値にリセットされる。
これは、このノードからのパケットまたは肯定応答用の
ｓｅｑフィールドを比較することによって示される。 if {pLabel.seq <= seqTable.seq[producerId]} then {seqTable.seq[producerId] = pLabel.seq } ３．最後に、各ノードは、以下の場合に、ｐｒｏｄｕｃ
ｅｒＩｄから順序エラーを含むパケットを検出すること
ができる。 pLabel.seq > seqTable.seq[producerId] + 1
【０１７１】モジュロ６４カウンタによって「より大」
比較と「より小か等しい」比較の両方をサポートするこ
とは、この比較が３１という受信側ノードにおける差を
超えないことをｐｒｏｄｕｃｅｒＩｄによって確認した
場合に達成することができ、カウントは以下のように定
義される。 以下の場合は「Ａ＜＝Ｂ」 −上位ビットが等しく、下位ビットがＡ＜＝Ｂ −上位ビットが等しくなく、残りのビットがＡ＞Ｂ 以下の場合は「Ａ＞Ｂ」 −上位ビットが等しく、下位ビットがＡ＞Ｂ −上位ビットが等しくなく、残りのビットがＡ＜＝Ｂ
比較と「より小か等しい」比較の両方をサポートするこ
とは、この比較が３１という受信側ノードにおける差を
超えないことをｐｒｏｄｕｃｅｒＩｄによって確認した
場合に達成することができ、カウントは以下のように定
義される。 以下の場合は「Ａ＜＝Ｂ」 −上位ビットが等しく、下位ビットがＡ＜＝Ｂ −上位ビットが等しくなく、残りのビットがＡ＞Ｂ 以下の場合は「Ａ＞Ｂ」 −上位ビットが等しく、下位ビットがＡ＞Ｂ −上位ビットが等しくなく、残りのビットがＡ＜＝Ｂ
【０１７２】特殊な問題 ここでは、本発明の可能な実施態様を含むある程度まで
の詳細に関する追加の説明と重要性を示す。
の詳細に関する追加の説明と重要性を示す。
【０１７３】このような問題のうちの第１の問題では、
ＣＲＣエラー後に適切なｓｅｑＴａｂｌｅ［ｐｒｏｄｕ
ｃｅｒＩｄ］フィールドを確実にリセットすることを扱
っていた。ＣＲＣエラーが発生すると、リングレット内
のすべてのノード用のｓｅｑＴａｂｌｅ．ｓｅｑ［ｐｒ
ｏｄｕｃｅｒＩＤ］内のフィールドは、リングレット内
の他のノードと同期していない値を含む可能性がある。
ＣＲＣエラー後に適切なｓｅｑＴａｂｌｅ［ｐｒｏｄｕ
ｃｅｒＩｄ］フィールドを確実にリセットすることを扱
っていた。ＣＲＣエラーが発生すると、リングレット内
のすべてのノード用のｓｅｑＴａｂｌｅ．ｓｅｑ［ｐｒ
ｏｄｕｃｅｒＩＤ］内のフィールドは、リングレット内
の他のノードと同期していない値を含む可能性がある。
【０１７４】同時に、ｓｅｑＴａｂｌｅ［］の値は、有
効かつ正しく順序付けられたパケットが受信側ノードで
識別された場合「のみ」更新されるので、これらの値は
このノードに関する限り正しいと見なさなければならな
い。しかし、これらは、送信側ノードと他のリングレッ
ト・ノードの両方に対して同期していない場合もある。
効かつ正しく順序付けられたパケットが受信側ノードで
識別された場合「のみ」更新されるので、これらの値は
このノードに関する限り正しいと見なさなければならな
い。しかし、これらは、送信側ノードと他のリングレッ
ト・ノードの両方に対して同期していない場合もある。
【０１７５】したがって、ｐｒｏｄｕｃｅｒＩｄノード
の仕事は、すべてのノードを確実に同期状態に戻すこと
である。問題はこのリセットを達成する際に発生する。
すなわち、エラー・ループ自体の第１のパケットにＣＲ
Ｃエラーが発生したらどうだろうか。
の仕事は、すべてのノードを確実に同期状態に戻すこと
である。問題はこのリセットを達成する際に発生する。
すなわち、エラー・ループ自体の第１のパケットにＣＲ
Ｃエラーが発生したらどうだろうか。
【０１７６】この問題に対する単純な解決策は、非パイ
プライン化モードで最後の既知の良好完了パケットを伝
送することにより、エラー処理ループを実行するｐｒｏ
ｄｕｃｅｒＩｄノードがそのエラー・ループを開始する
ことである。ｐｒｏｄｕｃｅｒＩＤノードは、それが有
効な肯定応答を受信するまで、このパケットを再試行す
るはずである。これを受信すると、リング上のすべての
ノードは、このｐｒｏｄｕｃｅｒＩＤ用のｓｅｑＴａｂ
ｌｅ．ｓｅｑ［］フィールドが同じ値に設定されていな
ければならない。ｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［］フ
ィールドをリセットするために同じ引数が適用される。
しかし、ｓｅｑＴａｂｌｅ．ｂｕｓｙ［］フィールド
は、このｐｒｏｄｕｃｅｒＩｄからこの受信側ノードに
配達された最後の有効完了パケットへの肯定応答の状態
を反映する。次の有効パケットの処理方法を考慮する場
合（再試行したパケットは拒否される）、このフィール
ドは有効性を有する。その結果、このフィールドは、リ
セット間隔中にリセットしてはならない。同様に、ｓｅ
ｑＴａｂｌｅ．ａｃｐｔ［］フィールドも未変更のまま
になる。
プライン化モードで最後の既知の良好完了パケットを伝
送することにより、エラー処理ループを実行するｐｒｏ
ｄｕｃｅｒＩｄノードがそのエラー・ループを開始する
ことである。ｐｒｏｄｕｃｅｒＩＤノードは、それが有
効な肯定応答を受信するまで、このパケットを再試行す
るはずである。これを受信すると、リング上のすべての
ノードは、このｐｒｏｄｕｃｅｒＩＤ用のｓｅｑＴａｂ
ｌｅ．ｓｅｑ［］フィールドが同じ値に設定されていな
ければならない。ｓｅｑＴａｂｌｅ．ｂｚｓｅｑ［］フ
ィールドをリセットするために同じ引数が適用される。
しかし、ｓｅｑＴａｂｌｅ．ｂｕｓｙ［］フィールド
は、このｐｒｏｄｕｃｅｒＩｄからこの受信側ノードに
配達された最後の有効完了パケットへの肯定応答の状態
を反映する。次の有効パケットの処理方法を考慮する場
合（再試行したパケットは拒否される）、このフィール
ドは有効性を有する。その結果、このフィールドは、リ
セット間隔中にリセットしてはならない。同様に、ｓｅ
ｑＴａｂｌｅ．ａｃｐｔ［］フィールドも未変更のまま
になる。
【０１７７】ただし、既知の良好完了パケット（有効と
して肯定応答され、リングレット内のターゲット・ノー
ドによって拒否されるはずのもの）を再試行することに
より、ｐｒｏｄｕｃｅｒＩＤノードは、そのデータ内容
ではなく、そのパケット順序番号のみに関するパケット
を伝送することに留意されたい。
して肯定応答され、リングレット内のターゲット・ノー
ドによって拒否されるはずのもの）を再試行することに
より、ｐｒｏｄｕｃｅｒＩＤノードは、そのデータ内容
ではなく、そのパケット順序番号のみに関するパケット
を伝送することに留意されたい。
【０１７８】有効なＡＣＫが返されるまで既知のパケッ
トを再送信するという同じ手法を使用すると、リングレ
ット初期設定によって上記のフィールドを初期設定する
ことができる。しかし、ｓｅｑＴａｂｌｅ．ｂｕｓ
ｙ［］およびｓｅｑＴａｂｌｅ．ａｃｐｔ［］などの他
のフィールドは、非ＳＳＯ空間を使用してｓｅｑＴａｂ
ｌｅ．ａｃｐｔ［］フィールドに値（ｐＬａｂｅｌ．ｓ
ｅｑ）を書き込むなど、他の手段によってリセットしな
ければならない。
トを再送信するという同じ手法を使用すると、リングレ
ット初期設定によって上記のフィールドを初期設定する
ことができる。しかし、ｓｅｑＴａｂｌｅ．ｂｕｓ
ｙ［］およびｓｅｑＴａｂｌｅ．ａｃｐｔ［］などの他
のフィールドは、非ＳＳＯ空間を使用してｓｅｑＴａｂ
ｌｅ．ａｃｐｔ［］フィールドに値（ｐＬａｂｅｌ．ｓ
ｅｑ）を書き込むなど、他の手段によってリセットしな
ければならない。
【０１７９】元の提案に関する第２の問題では、そのエ
ラー・ループ内のパケットが完了したかどうかを判定す
るｐｒｏｄｕｃｅｒＩＤノードの曖昧さの問題を扱って
いた。すなわち、（送信／受信）と肯定応答の対にＣＲ
Ｃエラーが発生していると検出された場合、ｐｕｒｏｄ
ｕｃｅｒＩＤノードは、パケットがそのリングレット宛
先に達する前または後のいずれでＣＲＣエラーが発生し
たかを判定することができない。したがって、これは、
再試行したパケットに「完了」というマークを確実に付
けることはできない。
ラー・ループ内のパケットが完了したかどうかを判定す
るｐｒｏｄｕｃｅｒＩＤノードの曖昧さの問題を扱って
いた。すなわち、（送信／受信）と肯定応答の対にＣＲ
Ｃエラーが発生していると検出された場合、ｐｕｒｏｄ
ｕｃｅｒＩＤノードは、パケットがそのリングレット宛
先に達する前または後のいずれでＣＲＣエラーが発生し
たかを判定することができない。したがって、これは、
再試行したパケットに「完了」というマークを確実に付
けることはできない。
【０１８０】この問題に対する解決策は、（６ビット
の）ｓｅｑＴａｂｌｅ．ａｃｐｔ［］フィールドを各受
信側ノードのｓｅｑＴａｂｌｅアレイに追加し、このｐ
ｒｏｄｕｃｅｒＩｄからのより小さい値のｐＬａｂｅ
ｌ．ｓｅｑを含むパケットによってそのｓｅｑＴａｂｌ
ｅ．ｓｅｑ［］がリセットされる前にこのノードで最後
に検出された有効順序番号を記録し、または使用中再試
行のために拒否された第１のパケットの順序番号（ｓｅ
ｑＴａｂｌｅ．ｂｕｓｙ［］フィールドによって示され
る）を記録することである。ただし、ｓｅｑＴａｂｌ
ｅ．ａｃｐｔ［］フィールドを追跡することは、以下の
意味を有することに留意されたい。 １．このノードで最後に受け入れられたパケットはｓｅ
ｑＴａｂｌｅ．ａｃｐｔ［］と等しいかそれより小さい
順序番号を備えていなければならず、したがって、新し
い未検出のパケットはｓｅｑＴａｂｌｅ．ａｃｐｔ［］
より大きい順序番号を備えていなければならない。ただ
し、ｓｅｑＴａｂｌｅ．ｂｕｓｙ［］はリセットされる
ものとする。 ２．エラーまたは使用中パケットがない場合、ｓｅｑＴ
ａｂｌｅ．ａｃｐｔは現行のｐＬａｂｅｌ．ｓｅｑ値を
追跡する。この事実は、モジュロ６４のローリング・カ
ウント定義を作成する際に非常に重要なものである。
の）ｓｅｑＴａｂｌｅ．ａｃｐｔ［］フィールドを各受
信側ノードのｓｅｑＴａｂｌｅアレイに追加し、このｐ
ｒｏｄｕｃｅｒＩｄからのより小さい値のｐＬａｂｅ
ｌ．ｓｅｑを含むパケットによってそのｓｅｑＴａｂｌ
ｅ．ｓｅｑ［］がリセットされる前にこのノードで最後
に検出された有効順序番号を記録し、または使用中再試
行のために拒否された第１のパケットの順序番号（ｓｅ
ｑＴａｂｌｅ．ｂｕｓｙ［］フィールドによって示され
る）を記録することである。ただし、ｓｅｑＴａｂｌ
ｅ．ａｃｐｔ［］フィールドを追跡することは、以下の
意味を有することに留意されたい。 １．このノードで最後に受け入れられたパケットはｓｅ
ｑＴａｂｌｅ．ａｃｐｔ［］と等しいかそれより小さい
順序番号を備えていなければならず、したがって、新し
い未検出のパケットはｓｅｑＴａｂｌｅ．ａｃｐｔ［］
より大きい順序番号を備えていなければならない。ただ
し、ｓｅｑＴａｂｌｅ．ｂｕｓｙ［］はリセットされる
ものとする。 ２．エラーまたは使用中パケットがない場合、ｓｅｑＴ
ａｂｌｅ．ａｃｐｔは現行のｐＬａｂｅｌ．ｓｅｑ値を
追跡する。この事実は、モジュロ６４のローリング・カ
ウント定義を作成する際に非常に重要なものである。
【０１８１】図４０〜６０の例に関する注意事項 図４０〜６０は、パケット処理の連続段階における本発
明のシステムの状態を示しており、その場合、使用中条
件は消費側ノードに関して発生し、ＣＲＣ（またはその
他の）エラー条件も発生し、「使用中」ノードは挙動が
不適切である。すなわち、何らかの所定の長さの時間ま
たは所定の数の送信または受信パケットの間、それが持
続的に使用中であったか、またはそれが間違ってａｃｋ
＿ｂｕｓｙ応答を伝送している。
明のシステムの状態を示しており、その場合、使用中条
件は消費側ノードに関して発生し、ＣＲＣ（またはその
他の）エラー条件も発生し、「使用中」ノードは挙動が
不適切である。すなわち、何らかの所定の長さの時間ま
たは所定の数の送信または受信パケットの間、それが持
続的に使用中であったか、またはそれが間違ってａｃｋ
＿ｂｕｓｙ応答を伝送している。
【０１８２】図４０〜６０の例では、ｏｒ＿ｌａｓｔ＿
ｃｔは最後に送信した順序付きパケットのカウント数で
あり、ｏｒ＿ｒｃｖｄ＿ｃｔは最後に受信した順序付き
パケットのカウントを指すことに留意されたい。使用中
再試行が必要な場合（再送信論理で検出される）、ｏｒ
＿ｒｃｖｄ＿ｃｔ値はフリーズされる。
ｃｔは最後に送信した順序付きパケットのカウント数で
あり、ｏｒ＿ｒｃｖｄ＿ｃｔは最後に受信した順序付き
パケットのカウントを指すことに留意されたい。使用中
再試行が必要な場合（再送信論理で検出される）、ｏｒ
＿ｒｃｖｄ＿ｃｔ値はフリーズされる。
【０１８３】この例では、以前の使用中パケット、たと
えば、５４と５９がｒｅｔｒｙ＿ｐｋｔ待ち行列内に入
っていると想定する。ただし、以下の式が成り立つこと
に留意されたい。 また、２８はその差（ｏｒ＿ｌａｓｔ＿ｃｔ − ｏｒ
＿ｒｃｖｄ＿ｃｔ）のしきい値と等しいかそれより小さ
い。
えば、５４と５９がｒｅｔｒｙ＿ｐｋｔ待ち行列内に入
っていると想定する。ただし、以下の式が成り立つこと
に留意されたい。 また、２８はその差（ｏｒ＿ｌａｓｔ＿ｃｔ − ｏｒ
＿ｒｃｖｄ＿ｃｔ）のしきい値と等しいかそれより小さ
い。
【図１】より大規模なネットワーク上のリングレットを
示すブロック図である。
示すブロック図である。
【図２】単一リングレットを示すブロック図であって、
そのリングレット上で送受信するコマンドを示す図であ
る。
そのリングレット上で送受信するコマンドを示す図であ
る。
【図３】強力順次順序付け（ＳＳＯ）の場合に送受信す
るコマンドを示す図である。
るコマンドを示す図である。
【図４】非アイデンポテント要求またはコマンドを伴う
ＳＳＯの場合に送受信するコマンドを示す図である。
ＳＳＯの場合に送受信するコマンドを示す図である。
【図５】図２のリングレットを示し、送信パケットおよ
び肯定応答のデータ構造を示す図である。
び肯定応答のデータ構造を示す図である。
【図６】図２のリングレットを示し、パケットの再送信
を示す図である。
を示す図である。
【図７】図２のリングレットを示し、消費側ノードのア
クションを示す図である。
クションを示す図である。
【図８】送信インタフェースの観点から本発明の動作を
示すブロック図である。
示すブロック図である。
【図９】送信ポートに関して本発明の使用中ループ動作
を示すタイミング図である。
を示すタイミング図である。
【図１０】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図１１】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図１２】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図１３】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図１４】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図１５】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図１６】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図１７】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図１８】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図１９】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図２０】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図２１】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図２２】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図２３】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図２４】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図２５】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図２６】本発明のシステムの論理サブシステムとその
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
動作を示す論理図であって、（非公式図面では）六角形
は判断ボックスであり、矩形は可変値が設定されるステ
ップであることを示す図である。
【図２７】受信インタフェースの観点から本発明の動作
を示すブロック図である。
を示すブロック図である。
【図２８】受信パケット・タイミングを示すタイミング
図である。
図である。
【図２９】受信ノードに関して本発明のシステムの論理
サブシステムとその動作を示す論理図である。
サブシステムとその動作を示す論理図である。
【図３０】受信ノードに関して本発明のシステムの論理
サブシステムとその動作を示す論理図である。
サブシステムとその動作を示す論理図である。
【図３１】受信ノードに関して本発明のシステムの論理
サブシステムとその動作を示す論理図である。
サブシステムとその動作を示す論理図である。
【図３２】受信ノードに関して本発明のシステムの論理
サブシステムとその動作を示す論理図である。
サブシステムとその動作を示す論理図である。
【図３３】受信ノードに関して本発明のシステムの論理
サブシステムとその動作を示す論理図である。
サブシステムとその動作を示す論理図である。
【図３４】受信ノードに関して本発明のシステムの論理
サブシステムとその動作を示す論理図である。
サブシステムとその動作を示す論理図である。
【図３５】受信ノードに関して本発明のシステムの論理
サブシステムとその動作を示す論理図である。
サブシステムとその動作を示す論理図である。
【図３６】受信ノードに関して本発明のシステムの論理
サブシステムとその動作を示す論理図である。
サブシステムとその動作を示す論理図である。
【図３７】受信ノードに関して本発明のシステムの論理
サブシステムとその動作を示す論理図である。
サブシステムとその動作を示す論理図である。
【図３８】受信ノードに関して本発明のシステムの論理
サブシステムとその動作を示す論理図である。
サブシステムとその動作を示す論理図である。
【図３９】受信ノードに関して本発明のシステムの論理
サブシステムとその動作を示す論理図である。
サブシステムとその動作を示す論理図である。
【図４０】本発明の好ましい実施形態におけるパケット
の構造と流れの両方を示すブロック図である。
の構造と流れの両方を示すブロック図である。
【図４１】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図４２】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図４３】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図４４】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図４５】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図４６】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図４７】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図４８】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図４９】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図５０】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図５１】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図５２】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図５３】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図５４】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図５５】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図５６】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図５７】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図５８】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図５９】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図６０】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
【図６１】本発明のシステムの動作による図４０のブロ
ック図の後続状態を示す図である。
ック図の後続状態を示す図である。
１〜４ リングレット１ Ａ〜Ｄ ノード
───────────────────────────────────────────────────── フロントページの続き (71)出願人 591064003 901 ＳＡＮ ＡＮＴＯＮＩＯ ＲＯＡＤ ＰＡＬＯ ＡＬＴＯ，ＣＡ 94303，Ｕ. Ｓ．Ａ.
Claims (33)
- 【請求項１】 コンピュータ・ネットワーク・サポート
内の少なくとも１つの作成側ノードによって少なくとも
１つの消費側ノードに伝送されるパケットの順序を維持
するシステムにおいて、 前記作成側ノードによって送信された少なくとも１つの
前記パケットに関する順序およびパケット状態情報を維
持するように構成された前記作成側ノードの第１の送信
サブシステムと、 前記消費側ノードによって前記作成側ノードに送信され
た肯定応答に関する順序およびパケット状態情報を維持
し、送信したパケットが結果的に肯定応答になった条件
を検出するように構成された前記作成側ノードの第１の
受信サブシステムと、 前記消費側ノードからの使用中肯定応答を検出するよう
に構成された前記作成側ノードの第２の受信サブシステ
ムと、 前記肯定応答に関する順序およびパケット状態情報を維
持するように構成された前記消費側ノードの第２の送信
サブシステムと、 前記作成側ノードによって送信された前記パケットに関
する順序およびパケット状態情報を維持し、前記作成側
ノードから前記消費側ノードが受信したすべてのパケッ
トに関する全体的な順序状態情報およびパケット受入れ
状態情報を維持するように構成され、さらに少なくとも
１つの前記使用中肯定応答が検出されたときにパケット
を拒否するように構成された前記消費側ノードの第３の
受信サブシステムと、 前記ネットワーク内の少なくとも１つの前記消費側ノー
ドが所定の応答基準を満たすことができない場合を判定
するように構成された前記作成側ノード内のノード監視
サブシステムとを含むことを特徴とするシステム。 - 【請求項２】 前記ノード監視サブシステムが前記消費
側ノードから受信した複数の使用中肯定応答を記憶する
ように構成された使用中肯定応答待ち行列を含んでいる
ことを特徴とする請求項１に記載のシステム。 - 【請求項３】 前記ノード監視サブシステムが少なくと
も所定数の前記使用中肯定応答を記憶している前記使用
中肯定応答待ち行列に基づいて前記判定を行うように構
成されていることを特徴とする請求項２に記載のシステ
ム。 - 【請求項４】 前記所定の応答基準が前記作成側ノード
が前記消費側ノードから複数の使用中肯定応答を受信す
る所定長さの時間を含んでいることを特徴とする請求項
１に記載のシステム。 - 【請求項５】 前記所定の応答基準が前記作成側ノード
が前記消費側ノードから使用中肯定応答を何も受信しな
い所定長さの時間を含んでいることを特徴とする請求項
１に記載のシステム。 - 【請求項６】 前記システムが第１のパケットを２回以
上受信したときに、前記第１のパケットがアドレス指定
されているノードの状態を未変更の状態で維持しなが
ら、非アイデンポテント要求を含む少なくとも前記第１
のパケットを処理するように構成されていることを特徴
とする請求項１に記載のシステム。 - 【請求項７】 前記再試行パケットの第２のインスタン
スを受信したときに前記消費側ノードの状態を未変更の
状態で維持しながら、非アイデンポテント要求を含む少
なくとも１つのパケットを再試行する用に構成された再
試行サブシステムを含むことを特徴とする請求項１に記
載のシステム。 - 【請求項８】 前記ネットワークがリングレット・ネッ
トワークであることを特徴とする請求項１に記載のシス
テム。 - 【請求項９】 前記ネットワークが強力順次順序付けを
維持するように構成された少なくとも１つの順序付けさ
れたノードと、強力順序付けを維持する態様以外の態様
で構成された少なくとも１つの順序付けされていないノ
ードとを含んでいることを特徴とする請求項１に記載の
システム。 - 【請求項１０】 前記ネットワークが非アイデンポテン
トコマンドをサポートするように構成された少なくとも
第１のノードと、非アイデンポテントコマンドをサポー
トしないように構成された第２のノードとを含んでいる
ことを特徴とする請求項１に記載のシステム。 - 【請求項１１】 前記ネットワークが異なる時点で、強
力順次順序付けを維持する態様と、強力順次順序付けを
維持する以外の態様の両方で構成できる少なくとも１つ
の動的ノードを含んでいることを特徴とする請求項１に
記載のシステム。 - 【請求項１２】 エラー検出サブシステムと、 現行パケットの送信時に前記エラー検出サブシステムに
よってエラーを検出したときに、それぞれの前記消費側
ノードの前記順序を共通ネットワーク値にリセットする
ように構成されたリセット・サブシステムとをさらに含
むことを特徴とする請求項１に記載のシステム。 - 【請求項１３】 前記リセット・サブシステムが前記作
成側ノードに以前送信したパケットを２回以上再送信さ
せ、かつ有効な肯定応答パケットを前記作成側パケット
が受信するまで、必要に応じ、これを繰り返させるよう
に構成されていることを特徴とする請求項１２に記載の
システム。 - 【請求項１４】 前記の以前送信したパケットが肯定応
答実行済みパケットを前記作成側ノードが受信したパケ
ットであることを特徴とする請求項１３に記載のシステ
ム。 - 【請求項１５】 前記の以前送信したパケットと前記現
行パケットを含んで、これらの間で再試行パケットを送
信するように構成されている第１の再試行サブシステム
をさらに含んでいることを特徴とする請求項１４に記載
のシステム。 - 【請求項１６】 前記再試行パケットの送信に応答して
前記作成側ノードで受信した再試行パケット肯定応答の
妥当性を判定するように構成された再試行パケット妥当
性検査サブシステムをさらに含んでいることを特徴とす
る請求項１５に記載のシステム。 - 【請求項１７】 再試行パケット肯定応答が無効状態で
あると前記再試行パケット妥当性検査サブシステムが判
定した場合に、前記再試行パケットを送信するように構
成された第２の再試行サブシステムをさらに含んでいる
ことを特徴とする請求項１６に記載のシステム。 - 【請求項１８】 前記リセット・サブシステムが再送信
前に前記の以前に送信したパケットからデータ・フィー
ルドを除去するように構成されていることを特徴とする
請求項１３に記載のシステム。 - 【請求項１９】 前記リセット・サブシステムが前記の
各消費側ノードにおいて順序妥当状態値を維持し、前記
の以前に送信したパケットの前記の各消費側ノードにお
ける受信時に前記の各順序妥当状態値を共通値にリセッ
トするように構成された順序妥当状態サブシステムを含
んでいることを特徴とする請求項１３に記載のシステ
ム。 - 【請求項２０】 前記再試行サブシステムが前記の各消
費側ノードにおいて受入れ妥当状態値を維持するように
構成された受入れ妥当状態サブシステムと、 前記再試行パケットの受入れ有効フィールドと前記の各
消費側ノードにおける前記受入れ妥当状態値との比較を
生成するように構成された受入れ妥当性比較サブシステ
ムと、 前記の比較が所定の基準に合致している前記の各再試行
パケットを拒絶する再試行パケット拒絶サブシステムと
を含んでいることを特徴とする請求項１５に記載のシス
テム。 - 【請求項２１】 複数の送信および消費側ノードを含
み、それぞれの前記消費側ノードが、前記パケットおよ
び肯定応答が前記状態情報を読み取る消費側ノード以外
のノードにアドレス指定されていても、強力順次順序付
けをサポートするすべてのノード間で共通の順序付け情
報を維持するために、複数の前記パケットおよび前記肯
定応答の状態情報をそれぞれ読み取るように構成された
前記受信サブシステムの１つを含むことを特徴とする請
求項１に記載のシステム。 - 【請求項２２】 複数の前記作成側ノードと複数の前記
消費側ノードとを含み、 前記作成側および消費側ノードの少なくとも部分集合
が、ＳＳＯパケットをそれぞれ送信および受信し、前記
ＳＳＯパケットのＳＳＯ肯定応答をそれぞれ受信および
送信するための強力順次順序付け（ＳＳＯ）ノードとし
て構成され、 前記部分集合のそれぞれの前記作成側および消費側ノー
ドが、前記ＳＳＯパケットまたは前記ＳＳＯ肯定応答あ
るいはその両方を読み取るように構成されていることを
特徴とする請求項１に記載のシステム。 - 【請求項２３】 前記ネットワーク上を作成側ノードに
よって伝送された際の要求パケットの順序を未変更の状
態に維持し、かつ前記要求パケットに応じて消費側ノー
ドによって前記ネットワーク上に生成された応答パケッ
トの順序を未変更の状態に維持するように構成されてい
ることを特徴とする請求項１に記載のシステム。 - 【請求項２４】 コンピュータ・ネットワーク内の少な
くとも１つの作成側ノードによって少なくとも１つの消
費側ノードに伝送されるパケットの順序を維持するため
のシステムにおいて、 その順序内の少なくとも１つのパケットがその順序内の
有効な位置にあるかどうかを判定するように構成された
前記消費側ノード内の順序検査サブシステムと、 受信した肯定応答が前記消費側ノード内の使用中条件を
示すかどうかを判定するように構成された前記作成側ノ
ード内の使用中肯定応答検出サブシステムと、 前記ネットワーク内の少なくとも１つの前記消費側ノー
ドが所定の応答基準を満たすことができない場合を判定
するように構成された前記作成側ノード内のノード監視
サブシステムとを含むことを特徴とするシステム。 - 【請求項２５】 前記ノード監視サブシステムが前記消
費側ノードから受信した複数の使用中肯定応答を記憶す
るように構成された使用中肯定応答待ち行列を含んでい
ることを特徴とする請求項２４に記載のシステム。 - 【請求項２６】 前記ノード監視サブシステムが少なく
とも所定数の前記使用中肯定応答を記憶している前記使
用中肯定応答待ち行列に基づいて前記判定を行うように
構成されていることを特徴とする請求項２５に記載のシ
ステム。 - 【請求項２７】 前記所定の応答基準が前記作成側ノー
ドが前記消費側ノードから複数の使用中肯定応答を受信
する所定長さの時間を含んでいることを特徴とする請求
項２４に記載のシステム。 - 【請求項２８】 前記所定の応答基準が前記作成側ノー
ドが前記消費側ノードから使用中肯定応答を何も受信し
ない所定長さの時間を含んでいることを特徴とする請求
項２４に記載のシステム。 - 【請求項２９】 コンピュータ・ネットワーク内の少な
くとも１つの作成側ノードによって少なくとも１つの消
費側ノードに伝送されるパケットの順序を維持するため
のシステムにおいて、 前に伝送され未処理のパケットに関する前記作成側ノー
ドへの肯定応答がない場合に前記作成側ノードからのパ
ケットをパイプライン化するように構成されたパイプラ
イン化サブシステムと、 第１の前記未処理パケットと現行パケットとの間の順序
カウント差を決定するように構成されたカウンタ・サブ
システムと、 前記順序カウント差が所定のしきい値に達したときに前
記パケットの前記パイプライン化を終了するように構成
された遮断サブシステムと、 前記消費側ノードで使用中条件を検出するように構成さ
れた使用中検出サブシステムと、 前記使用中条件が検出されたときに前記パケットのパイ
プライン化を中断するように構成されたパケット中断サ
ブシステムと、 前記ネットワーク内の少なくとも１つの前記消費側ノー
ドが所定の応答基準を満たすことができない場合を判定
するように構成された前記作成側ノード内のノード監視
サブシステムとを含むことを特徴とするシステム。 - 【請求項３０】 前記ノード監視サブシステムが前記消
費側ノードから受信した複数の使用中肯定応答を記憶す
るように構成された使用中肯定応答待ち行列を含んでい
ることを特徴とする請求項２９に記載のシステム。 - 【請求項３１】 前記ノード監視サブシステムが少なく
とも所定数の前記使用中肯定応答を記憶している前記使
用中肯定応答待ち行列に基づいて前記判定を行うように
構成されていることを特徴とする請求項３０に記載のシ
ステム。 - 【請求項３２】 前記所定の応答基準が前記作成側ノー
ドが前記消費側ノードから複数の使用中肯定応答を受信
する所定長さの時間を含んでいることを特徴とする請求
項２９に記載のシステム。 - 【請求項３３】 前記所定の応答基準が前記作成側ノー
ドが前記消費側ノードから使用中肯定応答を何も受信し
ない所定長さの時間を含んでいることを特徴とする請求
項２９に記載のシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/673,849 US6065052A (en) | 1996-07-01 | 1996-07-01 | System for maintaining strongly sequentially ordered packet flow in a ring network system with busy and failed nodes |
| US08/673849 | 1996-07-01 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH10164140A true JPH10164140A (ja) | 1998-06-19 |
Family
ID=24704340
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP9211428A Pending JPH10164140A (ja) | 1996-07-01 | 1997-07-01 | ビジーノードと欠陥ノードを有するリング・ネットワーク・システムで強くシーケンシャルに順序付けられたパケット・フローを維持するシステム |
Country Status (3)
| Country | Link |
|---|---|
| US (3) | US6065052A (ja) |
| EP (1) | EP0836299A3 (ja) |
| JP (1) | JPH10164140A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7489697B2 (en) | 2003-08-06 | 2009-02-10 | Samsung Electronics Co., Ltd. | IEEE 1394-based unidirectional ring system for indoor backbone network |
Families Citing this family (73)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6064672A (en) * | 1996-07-01 | 2000-05-16 | Sun Microsystems, Inc. | System for dynamic ordering support in a ringlet serial interconnect |
| FR2779301B1 (fr) * | 1998-05-26 | 2000-07-21 | Thomson Multimedia Sa | Procede d'identification d'appareils dans un reseau de communication et appareil de mise en oeuvre |
| US7159005B1 (en) | 1998-10-16 | 2007-01-02 | International Business Machines Corporation | Methods, systems and computer program products for restartable multiplexed file transfers |
| US6401136B1 (en) * | 1998-11-13 | 2002-06-04 | International Business Machines Corporation | Methods, systems and computer program products for synchronization of queue-to-queue communications |
| US7283476B2 (en) * | 1999-01-11 | 2007-10-16 | Hewlett-Packard Development Company, L.P. | Identity negotiation switch protocols |
| US6628607B1 (en) | 1999-07-09 | 2003-09-30 | Apple Computer, Inc. | Method and apparatus for loop breaking on a serial bus |
| JP2001086120A (ja) * | 1999-09-10 | 2001-03-30 | Matsushita Electric Ind Co Ltd | ネットワーク間接続機器およびネットワークシステム |
| US6691096B1 (en) | 1999-10-28 | 2004-02-10 | Apple Computer, Inc. | General purpose data container method and apparatus for implementing AV/C descriptors |
| US6959343B1 (en) | 1999-11-01 | 2005-10-25 | Apple Computer, Inc. | Method and apparatus for dynamic link driver configuration |
| US6671768B1 (en) | 1999-11-01 | 2003-12-30 | Apple Computer, Inc. | System and method for providing dynamic configuration ROM using double image buffers for use with serial bus devices |
| US6813663B1 (en) | 1999-11-02 | 2004-11-02 | Apple Computer, Inc. | Method and apparatus for supporting and presenting multiple serial bus nodes using distinct configuration ROM images |
| US8762446B1 (en) | 1999-11-02 | 2014-06-24 | Apple Inc. | Bridged distributed device control over multiple transports method and apparatus |
| US6618750B1 (en) | 1999-11-02 | 2003-09-09 | Apple Computer, Inc. | Method and apparatus for determining communication paths |
| US6631426B1 (en) | 1999-11-02 | 2003-10-07 | Apple Computer, Inc. | Automatic ID allocation for AV/C entities |
| US6636914B1 (en) | 1999-11-05 | 2003-10-21 | Apple Computer, Inc. | Method and apparatus for arbitration and fairness on a full-duplex bus using dual phases |
| US6587904B1 (en) * | 1999-11-05 | 2003-07-01 | Apple Computer, Inc. | Method and apparatus for preventing loops in a full-duplex bus |
| US6457086B1 (en) | 1999-11-16 | 2002-09-24 | Apple Computers, Inc. | Method and apparatus for accelerating detection of serial bus device speed signals |
| US7266617B1 (en) * | 2000-01-18 | 2007-09-04 | Apple Inc. | Method and apparatus for border node behavior on a full-duplex bus |
| US6639918B1 (en) | 2000-01-18 | 2003-10-28 | Apple Computer, Inc. | Method and apparatus for border node behavior on a full-duplex bus |
| US7421507B2 (en) * | 2000-02-16 | 2008-09-02 | Apple Inc. | Transmission of AV/C transactions over multiple transports method and apparatus |
| US6831928B1 (en) | 2000-02-17 | 2004-12-14 | Apple Computer, Inc. | Method and apparatus for ensuring compatibility on a high performance serial bus |
| US7050453B1 (en) * | 2000-02-17 | 2006-05-23 | Apple Computer, Inc. | Method and apparatus for ensuring compatibility on a high performance serial bus |
| US6850967B1 (en) * | 2000-02-19 | 2005-02-01 | Hewlett-Packard Development Company, L.P. | System and method for ensuring transparent sychronization of multiple applications across remote systems |
| US6618785B1 (en) | 2000-04-21 | 2003-09-09 | Apple Computer, Inc. | Method and apparatus for automatic detection and healing of signal pair crossover on a high performance serial bus |
| US6718497B1 (en) | 2000-04-21 | 2004-04-06 | Apple Computer, Inc. | Method and apparatus for generating jitter test patterns on a high performance serial bus |
| US6917588B1 (en) * | 2000-05-16 | 2005-07-12 | Nortel Networks Limited | Apparatus and method for classifying data packet flows |
| US6912608B2 (en) * | 2001-04-27 | 2005-06-28 | Pts Corporation | Methods and apparatus for pipelined bus |
| AU2002326752A1 (en) * | 2001-08-24 | 2003-03-10 | Intel Corporation (A Delaware Corporation) (A Delawware Corporation) | A general input/output architecture protocol and related methods to manage data integrity |
| US6981110B1 (en) * | 2001-10-23 | 2005-12-27 | Stephen Waller Melvin | Hardware enforced virtual sequentiality |
| US20030158883A1 (en) * | 2002-02-04 | 2003-08-21 | Drudis Antoni N. | Message processing |
| US7298746B1 (en) | 2002-02-11 | 2007-11-20 | Extreme Networks | Method and system for reassembling and parsing packets in a network environment |
| US7447777B1 (en) * | 2002-02-11 | 2008-11-04 | Extreme Networks | Switching system |
| US7321926B1 (en) | 2002-02-11 | 2008-01-22 | Extreme Networks | Method of and system for allocating resources to resource requests |
| US7584262B1 (en) | 2002-02-11 | 2009-09-01 | Extreme Networks | Method of and system for allocating resources to resource requests based on application of persistence policies |
| US7814204B1 (en) | 2002-02-11 | 2010-10-12 | Extreme Networks, Inc. | Method of and system for analyzing the content of resource requests |
| DE10223007A1 (de) * | 2002-05-22 | 2003-12-11 | Bosch Gmbh Robert | Verfahren und Vorrichtung zur Übertragung von Informationen in einem Netzwerk sowie entsprechendes Netzwerk |
| AU2003245225A1 (en) * | 2002-07-19 | 2004-02-09 | Xelerated Ab | Method and apparatus for pipelined processing of data packets |
| US7417973B1 (en) | 2002-12-31 | 2008-08-26 | Apple Inc. | Method, apparatus and computer program product for ensuring node participation in a network bus |
| US7457302B1 (en) | 2002-12-31 | 2008-11-25 | Apple Inc. | Enhancement to loop healing for malconfigured bus prevention |
| US6965564B2 (en) | 2003-02-14 | 2005-11-15 | America Online, Inc. | Wireless datagram transaction protocol system |
| US7353284B2 (en) | 2003-06-13 | 2008-04-01 | Apple Inc. | Synchronized transmission of audio and video data from a computer to a client via an interface |
| US7668099B2 (en) * | 2003-06-13 | 2010-02-23 | Apple Inc. | Synthesis of vertical blanking signal |
| US8275910B1 (en) | 2003-07-02 | 2012-09-25 | Apple Inc. | Source packet bridge |
| US7788567B1 (en) * | 2003-11-18 | 2010-08-31 | Apple Inc. | Symbol encoding for tolerance to single byte errors |
| US7995606B1 (en) | 2003-12-03 | 2011-08-09 | Apple Inc. | Fly-by and ack-accelerated arbitration for broadcast packets |
| US7308517B1 (en) * | 2003-12-29 | 2007-12-11 | Apple Inc. | Gap count analysis for a high speed serialized bus |
| US7237135B1 (en) | 2003-12-29 | 2007-06-26 | Apple Inc. | Cyclemaster synchronization in a distributed bridge |
| US7349978B2 (en) * | 2004-01-15 | 2008-03-25 | Microsoft Corporation | Spurious timeout detection in TCP based networks |
| JP4459018B2 (ja) * | 2004-10-28 | 2010-04-28 | 富士通株式会社 | ノード装置 |
| US7765305B2 (en) * | 2005-04-07 | 2010-07-27 | Microsoft Corporation | Retry request overload protection |
| US8005879B2 (en) * | 2005-11-21 | 2011-08-23 | Sap Ag | Service-to-device re-mapping for smart items |
| US20070118496A1 (en) * | 2005-11-21 | 2007-05-24 | Christof Bornhoevd | Service-to-device mapping for smart items |
| US8156208B2 (en) * | 2005-11-21 | 2012-04-10 | Sap Ag | Hierarchical, multi-tiered mapping and monitoring architecture for service-to-device re-mapping for smart items |
| US20090265485A1 (en) * | 2005-11-30 | 2009-10-22 | Broadcom Corporation | Ring-based cache coherent bus |
| US8522341B2 (en) * | 2006-03-31 | 2013-08-27 | Sap Ag | Active intervention in service-to-device mapping for smart items |
| US8296413B2 (en) * | 2006-05-31 | 2012-10-23 | Sap Ag | Device registration in a hierarchical monitor service |
| US8131838B2 (en) * | 2006-05-31 | 2012-03-06 | Sap Ag | Modular monitor service for smart item monitoring |
| US8065411B2 (en) | 2006-05-31 | 2011-11-22 | Sap Ag | System monitor for networks of nodes |
| US7792137B2 (en) * | 2006-07-05 | 2010-09-07 | Abidanet, Llc | Self-organized and self-managed ad hoc communications network |
| US7765385B2 (en) * | 2007-04-18 | 2010-07-27 | International Business Machines Corporation | Fault recovery on a parallel computer system with a torus network |
| US8396960B2 (en) * | 2009-05-08 | 2013-03-12 | Canon Kabushiki Kaisha | Efficient network utilization using multiple physical interfaces |
| US8880716B2 (en) * | 2009-05-08 | 2014-11-04 | Canon Kabushiki Kaisha | Network streaming of a single data stream simultaneously over multiple physical interfaces |
| US8325601B2 (en) * | 2009-05-08 | 2012-12-04 | Canon Kabushiki Kaisha | Reliable network streaming of a single data stream over multiple physical interfaces |
| US8396952B2 (en) * | 2009-08-12 | 2013-03-12 | International Business Machines Corporation | Provisioning and commissioning a communications network with a virtual network operations center and interface |
| US8488960B2 (en) * | 2009-08-12 | 2013-07-16 | International Business Machines Corporation | Synchronizing events on a communications network using a virtual command interface |
| US8504660B2 (en) * | 2009-08-12 | 2013-08-06 | International Business Machines Corporation | Validation of the configuration of a data communications network using a virtual network operations center |
| US8356109B2 (en) | 2010-05-13 | 2013-01-15 | Canon Kabushiki Kaisha | Network streaming of a video stream over multiple communication channels |
| US9037122B2 (en) | 2012-02-29 | 2015-05-19 | Alcatel Lucent | Fixed line extension for mobile telephones |
| US9042874B2 (en) * | 2012-02-29 | 2015-05-26 | Alcatel Lucent | System and/or method for using mobile telephones as extensions |
| US9172507B2 (en) | 2012-04-03 | 2015-10-27 | Nevion Europe As | Signal protection |
| US9402107B2 (en) | 2013-03-15 | 2016-07-26 | Time Warner Cable Enterprises Llc | Apparatus and methods for delivery of multicast and unicast content in a content delivery network |
| US9596297B2 (en) | 2013-05-16 | 2017-03-14 | Toshiba Global Commerce Solutions Holdings Corporation | Managing communications in a multi-client, multi-server environment |
| CN111224885B (zh) * | 2020-01-07 | 2023-05-26 | 联合汽车电子有限公司 | 节点标序方法、节点标序系统及车载无钥匙系统 |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0638600B2 (ja) * | 1983-12-28 | 1994-05-18 | 株式会社東芝 | ローカルエリアネットワークシステム |
| US4725834A (en) * | 1984-02-27 | 1988-02-16 | American Telephone And Telegraph Company, At&T Bell Laboratories | Reliable broadcast protocol for a token passing bus network |
| WO1986003639A1 (en) * | 1984-12-03 | 1986-06-19 | The University Of Western Australia | Queueing protocol |
| US4922408A (en) * | 1985-09-27 | 1990-05-01 | Schlumberger Technology Corporation | Apparatus for multi-processor communications |
| US4807118A (en) * | 1987-01-14 | 1989-02-21 | Hewlett-Packard Company | Method for handling slot requests over a network |
| US5341483A (en) * | 1987-12-22 | 1994-08-23 | Kendall Square Research Corporation | Dynamic hierarchial associative memory |
| US5055999A (en) * | 1987-12-22 | 1991-10-08 | Kendall Square Research Corporation | Multiprocessor digital data processing system |
| US5084877A (en) * | 1989-05-05 | 1992-01-28 | At&T Bell Laboratories | High speed transport protocol |
| JP2764896B2 (ja) * | 1992-04-09 | 1998-06-11 | 日本電気株式会社 | データ送達確認システム |
| US5260933A (en) * | 1992-05-15 | 1993-11-09 | International Business Machines Corporation | Acknowledgement protocol for serial data network with out-of-order delivery |
| US5781715A (en) * | 1992-10-13 | 1998-07-14 | International Business Machines Corporation | Fault-tolerant bridge/router with a distributed switch-over mechanism |
| AU7322694A (en) * | 1993-07-09 | 1995-02-06 | Apple Computer, Inc. | System and method for sending and responding to information requests in a communications network |
| US5577211A (en) * | 1994-05-11 | 1996-11-19 | Ibm Corporation | System and method using chained structure queues for ordering of message delivery between connected nodes wherein unsuccessful message portion is skipped and retried |
| JP3041200B2 (ja) * | 1994-07-21 | 2000-05-15 | シャープ株式会社 | データ通信装置およびその方法 |
| US5495481A (en) * | 1994-09-30 | 1996-02-27 | Apple Computer, Inc. | Method and apparatus for accelerating arbitration in a serial bus by detection of acknowledge packets |
| US5548728A (en) * | 1994-11-04 | 1996-08-20 | Canon Information Systems, Inc. | System for reducing bus contention using counter of outstanding acknowledgement in sending processor and issuing of acknowledgement signal by receiving processor to indicate available space in shared memory |
| US5592486A (en) * | 1995-03-17 | 1997-01-07 | Advanced Micro Devices, Inc. | System and method for efficiently monitoring information in a network having a plurality of repeaters |
| US5774479A (en) * | 1995-03-30 | 1998-06-30 | Motorola, Inc. | Method and system for remote procedure call via an unreliable communication channel using multiple retransmission timers |
| US5870540A (en) * | 1995-11-20 | 1999-02-09 | Ncr Corporation | Low overhead method for detecting communication failures on a network |
| US5828847A (en) * | 1996-04-19 | 1998-10-27 | Storage Technology Corporation | Dynamic server switching for maximum server availability and load balancing |
-
1996
- 1996-07-01 US US08/673,849 patent/US6065052A/en not_active Expired - Lifetime
-
1997
- 1997-06-26 EP EP97304573A patent/EP0836299A3/en not_active Withdrawn
- 1997-07-01 JP JP9211428A patent/JPH10164140A/ja active Pending
-
2000
- 2000-01-28 US US09/493,925 patent/US6233615B1/en not_active Expired - Lifetime
-
2001
- 2001-05-10 US US09/854,294 patent/US6463472B1/en not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7489697B2 (en) | 2003-08-06 | 2009-02-10 | Samsung Electronics Co., Ltd. | IEEE 1394-based unidirectional ring system for indoor backbone network |
Also Published As
| Publication number | Publication date |
|---|---|
| EP0836299A3 (en) | 2005-07-20 |
| US6233615B1 (en) | 2001-05-15 |
| US6463472B1 (en) | 2002-10-08 |
| US6065052A (en) | 2000-05-16 |
| EP0836299A2 (en) | 1998-04-15 |
| US20020059442A1 (en) | 2002-05-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH10164140A (ja) | ビジーノードと欠陥ノードを有するリング・ネットワーク・システムで強くシーケンシャルに順序付けられたパケット・フローを維持するシステム | |
| JPH10164139A (ja) | ビジーノードを有するリング・ネットワークでシーケンシャルオーダリングを保持しアイデンポテント・コマンドをサポートするシステム | |
| US6545981B1 (en) | System and method for implementing error detection and recovery in a system area network | |
| US6493343B1 (en) | System and method for implementing multi-pathing data transfers in a system area network | |
| Cerf et al. | A protocol for packet network intercommunication | |
| JP3715991B2 (ja) | 並列プロセッサ | |
| US6064672A (en) | System for dynamic ordering support in a ringlet serial interconnect | |
| JP5049100B2 (ja) | 埋め込み自己チェック非同期パイプライン型実行（ｅｓｃａｐｅ） | |
| US7106742B1 (en) | Method and system for link fabric error detection and message flow control | |
| US8774203B2 (en) | One-way message notification with out-of-order packet delivery | |
| US4622550A (en) | Data communication system | |
| JP3560423B2 (ja) | パケット送受信装置及びパケット受信装置 | |
| US8792512B2 (en) | Reliable message transport network | |
| JP2772367B2 (ja) | データ・パケットを送信する方法およびデータ処理システム | |
| JPS63220631A (ja) | 通信システムにおけるノード装置 | |
| JP4807828B2 (ja) | ブロードバンド・エンジンのためのエンベロープ・パケット・アーキテクチュア | |
| US20010030964A1 (en) | Method and apparatus for maintaining packet ordering with error recovery among multiple outstanding packets between two devices | |
| OPDERBECK et al. | WE INFLUENCE OF CONTROL PROCEDURES ON THE PERFORMANCE OF PACKET-SWITCHED NETWORKS | |
| EP0094177A2 (en) | Apparatus for direct memory-to-memory intercomputer communication | |
| JPH1117764A (ja) | シリアルインタフェース回路およびその信号処理方法 | |
| JPH1117710A (ja) | シリアルインタフェース回路 | |
| GB2120055A (en) | Data communication system | |
| JP2003338808A (ja) | データ転送装置 | |
| Gopal et al. | ARQ protocols for high speed hardware implementation | |
| JPH02135831A (ja) | 通信プロトコールの冗長化方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040608 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060516 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060816 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060821 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061113 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070306 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20070606 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20070611 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080108 |