JP2707529B2 - データ通信システム - Google Patents

データ通信システム

Info

Publication number
JP2707529B2
JP2707529B2 JP3504613A JP50461391A JP2707529B2 JP 2707529 B2 JP2707529 B2 JP 2707529B2 JP 3504613 A JP3504613 A JP 3504613A JP 50461391 A JP50461391 A JP 50461391A JP 2707529 B2 JP2707529 B2 JP 2707529B2
Authority
JP
Japan
Prior art keywords
packet
node
link
error
data
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.)
Expired - Fee Related
Application number
JP3504613A
Other languages
English (en)
Other versions
JPH05503197A (ja
Inventor
シャー、ヴァイナイ、ヴェルジ
ジュウド、イアン、デヴィド
グレインジャー、バーナード、ジョン
コックバーン、ゴードン、ジョン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JPH05503197A publication Critical patent/JPH05503197A/ja
Application granted granted Critical
Publication of JP2707529B2 publication Critical patent/JP2707529B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1874Buffer management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1806Go-back-N protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1848Time-out mechanisms

Description

【発明の詳細な説明】 [技術分野] 本発明は、データ通信の分野に関し、具体的に言う
と、デジタル・システムのノード間でのデータ伝送中に
発生するエラーから回復する方法に関するものである。
[背景技術] データ通信システムおよびデータ通信システムを構成
する諸要素は、そのシステムの1ノード(たとえばコン
ピュータや端末)からリンクを介して別のノードへデー
タを電子伝送するものである。データ・リンクを介して
秩序ある形での通信を確保するためには、情報送受のた
めの均一の方法が必要である。この均一性は、通信シス
テム内のデータ・リンクの管理に使用されるプロトコル
(1組の規則)によって達成される。プロトコルは、通
信システム内の2ノード間での会話の確立、送信側と受
信側の識別、受信した情報の肯定応答、ノード初期設定
などの機能を実行するのに使用される。実際に実行され
る手順と機能は、使用されるプロトコルに応じて変わ
る。データ・リンク・プロトコルは、ビット指向プロト
コル(BOP)とバイト指向プロトコルという2つの範疇
に分類できる。
従来のビット指向プロトコルは、同期データ・リンク
制御(SDLC)プロトコルと、ハイレベル・データ・リン
ク制御(HDLC)プロトコルが含まれる。SDLCプロトコル
は、1973年にIBMによって導入された。BOPシステム内の
通信はすべて、各フィールドがそれぞれ一定の位置と正
確な意味を有する、複数のフィールドを含む均一なフォ
ーマットのフレームの形で行われる。HDLCでは一般に、
フレームは、8ビットのフラグ・シーケンスから始ま
り、その後にADDRESS(アドレス)フィールドとCONTROL
(制御)フィールドが続き、(そのフレームの機能によ
っては)その後にINFORMATION(情報)フィールドが続
くこともある。INFORMATIONフィールドの後にはFRAME
CHECK SEQUENCE(フレーム・チェック・シーケンス、F
CS)フィールドが続き、フレームの最後は、もう1つの
フラグ・シーケンスによって区切られる。HDLCのアドレ
ス・フィールドと制御フィールドは、それぞれ単一のオ
クテット・ビットからなる。情報フィールドは、整数個
のオクテットの形で所定の限界まで可変数のビットを含
むことができる。FCSフィールドは、一般に、1対のオ
クテットからなる。
HDLCでは、CONTROLフィールドが、そのフレームの機
能を定義する。基本形式には、情報、監視および無番号
の3形式があり、これらをそれぞれIフレーム、Sフレ
ームおよびUフレームと称する。Iフレームは、リンク
上での情報転送用に使用され、INFORMATIONフィールド
を含む。Sフレームは、リンクに対する監視機能の実行
に使用され、Iフレームの肯定応答またはフレームの再
送信要求に使用できる。Uフレームは、特にエラー回復
に使用される。
HDLCは、データ通信が比較的長距離にわたり、リンク
上にどの時点でも複数のデータ・フレームが存在するシ
ステムでしばしば使用される。データの受信を肯定応答
する方法は、これらのデータ・フレームのどれかが誤っ
て送信されたことを検出できるものでなければならな
い。暗黙肯定応答技法を使用すると、フレーム肯定応答
情報をIフレーム内に含めることができる。これは、順
序番号と称する識別番号を送受されるフレームに割り当
てることによって達成される。これらの番号には、個々
のノードによって送受されるフレームの数に関係する情
報が含まれる。これらの番号をチェックすることによっ
て、ノードは、受信したフレームの数と送信されたフレ
ームの数を比較でき、相違がある場合には適当なエラー
回復処置をとることができる。上述の暗黙肯定応答技法
に使用されるパケット順序番号は、Iフレーム内に含め
ることができるが、肯定応答すべきデータ・フレームを
受信中のノードが情報フレームを送信中でない場合に
は、順序番号情報を別のSフレームに含める必要があ
る。HDLCのサブセットの詳細は、ディーシントン(R.J.
Deasington)著「X25 explained」、エリス・ホアウッ
ド(Ellis Horwood Limited)刊に記載されている。
ノード間でのデータ伝送中に発生するエラーは、検出
されたエラーのタイプに応じて異なる形で訂正される。
受信側が、順序の狂ったフレームを受信した場合、拒否
(REJ)制御フィールドを含むSフレームが受信側から
送信側に送られる。これは、正しく受信された最後のフ
レームの1つ後から始めてIフレームの再送信を要求す
る。同一フレームの再送信によって回復できないエラー
が検出された場合は、そのエラーを検出したノードがU
フレームを送信する。Uフレームは、拒否されたフレー
ムの制御フィールドのコピーと、遭遇したエラーのタイ
プの指示を含む。
ビット指向プロトコルでは、送信中のノードが次のフ
レームを送信する前にフレーム受信済みの肯定応答を待
つ、送信後保留モードで動作する必要がない。したがっ
て、ビット指向プロトコルは、全二重モード(両方向同
時通信)で動作可能である。BOPシステムは、もちろん
半二重モード(両方向交互通信)でも動作できるが、半
二重モードでは、このプロトコルに固有の長所が利用さ
れない。
バイト指向プロトコルの1タイプがBISYNC(2進デー
タ同期)である。BISYNCでは、情報が、1つまたは2つ
の同期文字、1つのアドレス、制御文字群、1つの情報
フィールドおよび1つのエラー検出コードからなるブロ
ックとして伝送される。特殊ブロック制御文字を使用し
て、リンク上での情報のフローを管理する。BISYNCで
は、制御文字の1つに対応するビット・シーケンスが情
報フィールドに含まれないようにする必要がある。さも
ないと、そのビット・シーケンスは、システムによって
制御文字として誤って解釈される。BISYNCは、送信ノー
ドが第1のデータ・ブロックの肯定応答を受信した後で
なければ、第2のブロックの送信を開始できない、送信
後保留プロトコルの例である。したがって、基本的な形
のBISYNCは、全二重モードで動作することができない。
[発明の開示] 本発明は、その1態様では、データが所定のフォーマ
ットのパケット中でノード間を転送される、直列リンク
によって接続された2つのノードからなる種類のデータ
通信システム内で使用するエラー回復方法を提供する。
各ノードは、エラーがあるかどうかシステムを監視し、
一方のノードによってエラーが検出された場合、そのノ
ードが他方のノードに、そのノードが受信した最後のパ
ケットを示す順序番号を含むメッセージを送り、前記メ
ッセージの受信時に、他方のノードは前記一方のノード
に、そのノードが受信した最後のパケットを示す順序番
号を含むメッセージを送り、各ノードは、相手ノードか
らのメッセージから、相手ノードによって正しく受信さ
れなかったパケットがある場合にそのパケットの数を決
定し、失われたパケットを再送信する。
好ましい実施例では、第1のノードは、エラー検出時
にリンク・チェック状態に入り、リンク・エラー回復手
順(ERP)を呼び込む。ERPは、第1ノードに、検出され
たエラーのタイプを示すリンク状況バイトを作成させ、
そのリンク状況バイトを第2ノードに送信させる。第2
ノードは、リンク状況バイトの受信時に、示されたエラ
ーが1つまたは複数のデータ・パケットの再送信によっ
て回復できるタイプのものであるか否かを判定し、そう
である場合には、前記パケットを第1ノードに送信す
る。
このように本発明のデータ通信システムの1ノードに
おいて何らかのエラーが検出されたとき、通常のように
エラー回復手順が直ちに呼び出されるが、これに加えて
リンク状況バイトが通信の相手方ノードに送信され、こ
れを受けた相手方ノードがエラー回復手順を回復すると
共に自身のリンク状況バイトを送り返すので、両ノード
が同時にエラー回復手順を開始し、その手順においてそ
れぞれ相手方のリンク状況バイトにより相手方の状況を
知ることができる。このリンク状況バイトは相手方が受
信した最後のパケットの順序番号を含んでいるので、エ
ラーにより失われたパケットを正しく決定し、これを再
送信することができる。
この段階で、本明細書で使用する様々な用語の意味、
および従来技術の説明で使用される用語との関係を明瞭
にする必要がある。本明細書で使用する用語「パケッ
ト」は、HDLCプロトコルの従来技術の説明で使用される
用語「フレーム」と本質的に同等である。さらに、本明
細書で使用する用語「フレーム」は、HDLCの説明で使用
される用語「オクテット」と本質的に同等である。
多くのタイプのエラーの回復は、アプリケーションに
は不可視である。リンク・エラーの場合、すなわち、あ
るノードによって送信されたパケットが、受信ノードに
よって正しく受信されず、したがって受信ノードによっ
て肯定応答されない時には、そのデータは、送信ノード
の送信バッファ内に残っており、再送信に使用可能であ
る。しかし、検出されたエラーが、たとえばハードウェ
ア・エラーなど、おそらくパケットの再送信によって回
復不可能なタイプのものである場合には、そのリンクを
介して通信中のアプリケーションに警告が出される。そ
の後、このアプリケーションが、そのエラーからの回復
に必要な処置をとる。
本発明のもう1つの態様によれば、データが所定のフ
ォーマットのパケットの形でノード間で転送される、直
列リンクによって接続された2つのノードと、システム
内のエラーを検出するための各ノード内のエラー検出手
段と、少なくとも1つのノード内にあって、そのノード
のエラー検出手段によるエラーの検出に応答して、その
ノードに、前記少なくとも1つのノードによって受信さ
れた最後のパケットを示す順序番号を含むエラー・メッ
セージを相手ノードに送信させ、あるいは相手ノードか
らのエラー・メッセージの受信に応答して、前記少なく
とも1つのノードに、そのエラー・メッセージを相手ノ
ードに送信させる、送信エラー回復手段とを含み、各ノ
ードが、相手ノードからのエラー・メッセージから、相
手ノードによって正しく受信されなかったパケットがあ
る場合にそのパケットの数を決定し、失われたパケット
を再送信するように配置されている、データ通信システ
ムが提供される。
本発明に使用されるERPは、ソフトウェアで実施する
ことができるが、性能がクリティカルな場合には、シス
テムとしてハードウェアで実施することも可能である。
次に、添付の図面を参照して、1例として本発明の好
ましい実施例を説明する。
[図面の簡単な説明] 第1図は、本発明によるノード間データ・リンク構成
の主要構成要素を示す概略図である。
第2A図および第2B図は、第1図の構成要素を詳細に示
す概略図である。
第3A図および第3B図は、本発明で使用される送信機の
パケットFSMと制御FSMの状態図である。
第4A図および第4B図は、本発明の1実施例で使用され
る受信機のパケットFSMと制御FSMの状態遷移を示す状態
図である。
第5図は、データ送信に使用されるデータ・パケット
のフォーマットを示す図である。
第6図は、本発明で使用されるリンク状況バイトのフ
ォーマットを示す図である。
第7図は、ACK応答の化けからの回復に使用されるス
テップを示す流れ図である。
第8図は、マイクロプロセッサを介してデータ・バッ
ファに接続されたリンク・ハードウェアを示す図であ
る。
[発明の好ましい実施例] 以下の説明で使用する用語の一覧を、添付の表1に示
す。
第1図は、それぞれ関連するインバウンド・リンク7
とアウトバウンド・リンク5を有する、2つのノード
(ノード1およびノード2)を示す。各リンクは、接続
されたノードへのデータの送信またはそれからのデータ
の受信を制御する。送信されるデータは、アウトバウン
ド・パケット・バッファ11内に保持され、受信したデー
タは、インバウンド・パケット・バッファ11内に保持さ
れる。各パケット・バッファには、パケット状況レジス
タ(PSR)14が関連しており、パケット状況レジスタに
は、データの送信または受信に必要な情報の一部が保持
される。
データは、所定のフォーマットのパケットの形でノー
ド間を伝送される。データ・パケットのフローの制御
は、制御フレームによって管理される。次にデータ・パ
ケットおよび制御フレームの詳細を説明する。
使用されるフレームには、DATA(データ)フレームと
PROTOCOL(プロトコル)フレームという2つの基本形式
がある。本明細書で記載する実施例では、256個のデー
タ・フレームと4個のプロトコル・フレームがある。プ
ロトコル・フレームは、パケットを区切り、フロー制御
を提供するのに使用される。
第5図は、リンクを介するデータの伝送に使用される
パケット・フォーマットを示す。パケットは、両端をFL
AG(フラグ)フレーム(後述)で区切られた、少なくと
も4つの一連のデータ・フレームからなる。パケット
は、下記のように3つまたは4つの一連のフィールドに
分割される。
制御フィールド。(1フレーム、必ず存在する) アドレス・フィールド。(1フレーム、必ず存在する) データ・フィールド。(可変長、存在は任意選択) CRCフィールド。(2フレーム、必ず存在する) 可能な最も短いパケットは、データ・フィールドがな
く、4つのデータ・フレームを含む。あるノードが4つ
未満のフレームを含むパケットを受信した場合、そのノ
ードは、プロトコル・エラーを指示する。
制御フィールド:制御フィールドは、FLAGに続く最初の
データ・フレームである。受信ノードによって受信さ
れ、復号(詳細は後述)された後、結果として得られる
バイトは、下記のように解釈される。
ユーザ定義:これらは、予備ビットであり、これを使用
するシステムの必要に応じて、どのような目的に使用し
てもよい。
リンク・リセットおよびトーラル・リセット:これら
のビットは、本明細書で記載する通信方法に関連するエ
ラー回復手順で使用する。このエラー回復手順の詳細
は、本明細書で一部を説明するが、関連するエラー回復
手順の具体的な詳細は本発明を理解する上では必要でな
いのでその説明を省略する。
パケット順序番号:この2ビットは、パケットの喪失ま
たは重複に対する保護に使用される。これらは、連続す
る各パケット内で、送信機によって4の剰余系で増分さ
れ、受信機によって検査される。
アドレス・フィールド:これは、制御フィールドの直後
にある単一のデータ・フレームである。これには、通
常、遠隔ノード内の、そのパケットの符号化された宛先
アドレスが含まれる。
データ・フィールド:データ・フィールドは任意選択で
ある。存在する場合には、このフィールドは、アドレス
・フィールドに続く可変数のデータ・フレームからな
る。データ・フィールドの内容は、完全にアプリケーシ
ョンによって制御され、リンクのアーキテクチャとは無
関係である。データ・フィールドの最大長は、実施態様
に依存し、(i)使用可能なパケット・バァファのサイ
ズ、(ii)維持する必要のあるデータ速度、および(ii
i)所与のシステム環境と定義されたCRC多項式に対して
許容可能なエラー率に依存する。
実施態様によっては、データ・フィールドが偶数個の
フレームの長さになっているなどの制限がさらに加えら
れることもある。このような実施態様では、ノードは、
データ・フィールドとして誤った長さのパケットを受信
した場合、そのパケットを拒否する。
CRCフィールド:CRCフィールドは、後端FLAGの直前にあ
る2つのデータ・フレームからなる。これは、制御フィ
ールド、アドレス・フィールドおよびデータ・フィール
ドのチェックに使用される。宛先では、受信機がCRCフ
ィールドを受信し検査した後でなければ、どのフィール
ドも有効であるとは見なさない。
CRCフィールドは、データ・パケット毎に、アウトバ
ウンドCRCジェネレータによって、16ビット・レジスタ
内で下記の多項式を使用して計算される。
X16+X15+X2+1 CRCレジスタは、各パケットの先頭で、全ビット1に
プリセットされる。
インバウンド直列リンク内のインバウンドCRCアキュ
ムレータは、CRCフィールドを復号し、上記と同一の多
項式を使用してこれをチェックする。CRCレジスタは、
各パケットの先頭で全ビット1にプリセットされ、制御
フィールド、アドレス・フィールドおよびデータ・フィ
ールドにわたって累算される。入力パケットがエラーな
しで受信されたと仮定すると、累算の終了時点で、イン
バウンド・アキュムレータ内のCRCレジスタは、全ビッ
トが0になっていなければならない。
本発明の通信方法で定義されるプロトコル・フレーム
の1形式が、パケットを区切るのに使用されるFLAGフレ
ームである。FLAGフレームからデータ・フレームへの遷
移が、パケットの開始を示し、データ・フレームからFL
AGフレームへの遷移が、パケットの終了を示す。以下の
説明では、これらをそれぞれ、前端FLAGおよび後端FLAG
と称する。
オーバーヘッドを最小にするため、後端FLAGが、次の
パケットの前端FLAGを兼ねることも可能である。したが
って、連続するパケットは、最小限1つのFLAGによって
分離される。FLAGフレームのビット・パターンは、他の
有効なフレームのどのシーケンス内のどのビット位置で
も発生しないものになるように選択されている。このフ
レームおよび他の形式のプロトコル・フレームのビット
・パターンの例を、以下で説明する。FLAGフレームは、
フレーム同期を提供するという追加の目的にも役立つ。
さらに、FLAGフレームは、リンクの受信端での同期を維
持するため、リンクが遊休状態の時に送信される。
本発明の通信方法および通信システムは、データを上
述のパケットの形でソース・ノードから宛先ノードへ伝
送する手段を提供する。必要なフロー制御を実施するた
め、宛先は、ソースに、パケット毎に下記の2つの応答
を送信する。
肯定応答 1対の連続するACKプロトコル・フレーム 受信機作動可能 1対の連続するRRプロトコル・フレー
ム 制御フレームは、対で使用して、応答が送信エラーに
よって作り出されないよう保護することが好ましい。ノ
ードがある応答に作用するのは、他のフレームが介在し
ない状態で1対のフレームを両方とも受信した時に限ら
れる。
全二重動作の際には、ノードが、あるパケットを送信
している最中に、別の受信パケットに対する応答を送信
しようとするかもしれない。この場合、その送信機は、
応答を優先し、そのパケット内にこの応答をインターリ
ーブする。この方式を用いると、待ち時間が最少にな
り、送信機と受信機のそれぞれに2つのパケット・バッ
ファを設けるだけで、最大のリンク・スループットを達
成できる。
応答は、制御フレームからなるので、受信機は、パケ
ットを構成するデータ・フレームから応答を容易に分離
することができる。パケットのCRCフィールドには、イ
ンターリーブされた応答フレームは全く含まれない。
肯定応答:本発明の通信方法では、ノードが、有効なす
べての受信パケットに肯定応答を行う必要がある。パケ
ットが有効であるのは、リンク状況バイト内にリストさ
れる「受信機エラー」が、そのパケットに全く含まれて
いない場合である。宛先は、有効なパケットを受信した
時、ACK応答を送信する。ソースがこのACK応答を受信し
た時、肯定応答されたパケットを構成する情報を含んで
いたアウトバウンド・データ・バッファの一部をクリア
して、送信しようとする新規データの入力に備えること
ができる。
各ノードは、関連する2つの状態、「ACK待機中」と
「ACK保留中」を有する。次に、第4図を参照して、こ
れらの状態が肯定応答をどのように制御するかを説明す
る。
1.ノードは、「作動可能」状態(リンクの可能な状態に
ついては、以下で詳細に説明する)に入る時、「ACK待
機中」と「ACK保留中」をクリアする。
2.ノードは、パケットの後端FLAGの送信を完了してから
2フレームの後に、「ACK待機中」をセットする。ノー
ドは、ACK応答を受信した時に、「ACK待機中」をリセッ
トする。その後、対応するアウトバウンド・パケット・
バッファを割振り解除し、このバッファを別のパケット
で満たすことができる。
ノードが、あるパケットに対する「ACK待機中」をセ
ットした後、所定の時間(たとえば10ミリ秒)以内に応
答の最初のACKを受信しない場合、ACKタイム・アウトを
認識する。
ノードが、次のパケットのCRCフィールドの送信を終
了した時にまだ「ACK待機中」である場合は、このノー
ドは、後端FLAGを送信しない。その代わりに、このノー
ドは、ACK応答を受信するか、またはACKタイム・アウト
が発生するまで、NULフレームを送信する。この状態でA
CKタイム・アウトが発生する場合、このノードは、違法
フレームに続けてFLAGを送信しなければならない。違法
フレームがあると、そのパケットは打ち切られ、遠隔ノ
ードによって拒否されるようになる。
このプロトコルによれば、送信機が、伝播遅延、伝送
速度およびパケット長と無関係に、明確に各ACK応答を
対応するパケットと必ず関連づけできることが保証され
る。
ノードが、「ACK待機中」でない時にACK制御フレーム
を受信するか、またはACKフレームを1つしか受信しな
い場合、プロトコル・エラーを認識する。
3.ノードは、「作動可能」状態にある時に、有効なパケ
ットの後端FLAGを受信した時、即座に「ACK保留中」を
セットする。
4.「ACK保留中」がセットされている時には、ノード
は、できるだけ早くACK応答を送信しなければならな
い。ただし、RR応答が進行中の場合には、まずこれを完
了しなければならない。「ACK保留中」は、ACK応答を送
信し終えた時にリセットされる。
歩調合せ 歩調合せは、送信機が受信機の使用可能バッファをオ
ーバーランしないことを保証するものである。歩調合せ
の単位は、パケットである。本発明の通信の方法では、
受信機がただ1つのバッファをもつことが必要である。
ただし、リンクの連続的(全二重)動作を達成するに
は、一般に少なくとも2つのバッファが必要である。
各ノードは、歩調合せを制御する2つの状態、「RR待
機中」および「RR保留中」を有する。
1.ノードは、「作動可能」状態に入る時に、「RR待機
中」と「RR保留中」をセットする。その結果、ノード
は、即座にRR応答を送信し、また、RR応答を受信するま
でパケットを送信しない。
2.ノードがパケットの送信を開始できるのは、下記の条
件のどちらかが満足される時だけである。
・ノードが、「作動可能」状態にあり、「RR待機中」で
はない。
・ノードが、「チェック」状態にあり、パケット制御フ
ィールドでリンク・リセットまたはトータル・リセット
が指定されている。
「RR待機中」は、ノードが何らかのパケットの制御フ
ィールドを送信する時にセットされ、そのノードがRR応
答を受信した時にリセットされる。
3.下記の条件がすべて満足される時、ノードは、現フレ
ームの直後にRR応答を送信する。
・そのノードが「作動可能」状態にあり、「RR保留中」
がセットされている。
・少なくとも1つのインバウンド・バッファが、現在受
信中のパケットの他にもう1つのパケットを受信するの
に使用可能である。
・そのノードが、現在ACK応答を送信中ではなく、「ACG
保留中」がセットされていない。
「RR保留中」は、ノードが無効パケットを含めて何ら
かのパケットの制御フィールドを受信する時にセットさ
れ、そのノードがRR応答を送信した時にリセットされ
る。
パケット順序番号は、伝送エラーによるパケットの喪
失または重複に対する保護に利用される。たとえば、FL
AGが化ける場合、2つのパケットが1つになってしまう
ことがある。伝送エラーによってACK応答が化ける場
合、1つのパケットが重複することがある。これらに対
する保護のため、リンクERPは、対応するパケットが宛
先によって実際に受信されたか否かを知る必要がある。
各パケットの制御フィールドには、2ビットのパケッ
ト・順序番号(PSN)が含まれる。正常動作では、PSN
は、連続するパケット毎に、4の剰余系で増分される。
各ノードは、2ビットの送信順序番号(TSN)を維持
し、これを、送信される各パケットのPSNにコピーす
る。TSNは、「使用不能」状態で‘00'Bにリセットさ
れ、送信されるパケット毎に、受信される応答とは無関
係に、4の剰余系で増分される。
各ノードは、2ビットの受信順序番号(RSN)をも維
持する。これは、「使用不能」状態で‘00'Bにリセット
され、受信機が1パケットを受け入れる時、すなわち、
受信機がACK応答を返す時にだけ、4の剰余系で増分さ
れる。ただし、RSNは、リンク・リセットによって増分
されてはならない。パケットが受信される時、ハードウ
ェアは、下記のようにPSNをRSNと対比してチェックす
る。
・PSN=RSNである場合、そのシーケンスは正しく、受信
機は、期待していたパケットを受信済みである。他のエ
ラーが存在しないならば、このパケットが受け入れら
れ、ACK応答が返される。
・PSNがRSNに等しくなく、そのパケットがリンク・リセ
ットまたはトータル・リセットを指定するものではない
場合には、1つまたは複数のパケットが失われている。
現パケットは肯定応答されず、ノードはシーケンス・エ
ラーを認識する。
備考 受信機は、リンク・リセット・パケットまたはト
ータル・リセット・パケット内のPSNを無視する。
NULフレーム ノード送信機は、1パケットの最初のデータ・フレー
ムより後のどこにでも、NULプロトコル・フレームを挿
入できる。受信機は、NULフレームを捨てて無視する。N
ULフレームは、CRCフィールドの計算には含まれない。
この機能は、下記の場合に有用である。
(i)送信機がパケットの送信を開始したが、そのパケ
ットを完了するのに必要なデータが一時的に入手不能に
なっている場合。
(ii)送信機が、次パケットの後端FLAGを送信する準備
ができている時に、まだACK応答を待っている場合。
フレーム同期を保証するため、リンクが遊休状態の時
は、NULは許容されない。受信機がNULフレームを検出し
たが、最後のFLAGを受信した以降にデータ・フレームを
復号していない場合は、その受信機は、プロトコル・エ
ラーを指示する。
ノードが、パケットの送信中に内部ハードウェア・エ
ラーを検出した場合は、そのパケットを打ち切ることが
できる。これは、後端FALGより前のどこかに、違法フレ
ームを挿入することによって達成される。
各ノードは、少なくとも1つのパケット受信用バッフ
ァを備えなければならない。このバッファは、定義され
る最長のパケットを収容できるだけの大きさでなければ
ならない。このバッファは、受信機がデータ・フィール
ドをアプリケーションに転送するか、または制御フィー
ルドおよびアドレス・フィールドに作用する前に、CRC
フィールドを検証できるようにするために必要である。
歩調合せの単位はパケットであるので、オーバーランを
予防するためにも、このバッファが必要である。
ソース・ノードは、対応するACK応答を受け取るま
で、各パケットを保持しなければならない。ACKがない
場合、リンクERPは、最後の1つまたは2つのパケット
を再送信しなければならないことがある。
リンクの全帯域幅での連続通信を達成するためには、
一般に、格ノードが1対の送信バッファと1対の受信バ
ッファを有することが必要である。これによって、「A/
B」バッファリングがもたらされる。各バッファ対の一
方のバッファがリンクによって満たされるのと同時に、
もう一方のバッファがアプリケーションによって空にさ
れる。
バッファ管理 送信バッファは、エラーの後に正しい回復が可能にな
るように注意深く管理しなければならない。エラーの直
前に送信された最後の1つまたは2つのパケットを再送
信するかまたは捨てる必要があることもある。リンク・
ハードウェアは、これらのパケットを含むバッファと、
それらが送信された順序を識別するのに十分な状況を維
持しなければならない。N個の送信バッファがあり、送
信機が必ず循環式にこれらにアクセスする場合には、下
記の2つのポインタが十分な情報を提供する。
送信ポインタ これは、次に送信されるバッファを指す
ポインタである。このポインタは、後端FLAGが送信され
るごとに、Nの剰余系で増分される。
再試行ポインタ これは、肯定応答されるべき次のバッ
ファを指すポインタである。このポインタは、「ACK待
機中」がセットされている間にACK応答を受信するごと
に、Nの剰余系で増分される。通常、このポインタは送
信ポインタと同じところを指すが、エラー発生時には、
最大2つまで遅れることがある。
リンク使用可能性 各ノード内のリンク・ハードウェアは、下記の4つの
使用可能性状態の1つであり得る。
・使用不能。これは、リンクが動作可能状態になる前の
電源オン状態である。
・使用可能。これは、リンクを動作可能にする途中の過
渡状態である。
・作動可能。これは、パケットの正常な送受信ができる
状態である。
・チェック。この状態に入るのは、エラーが検出された
時である。リンクは、リンクERPがハードウェアを「作
動可能」状態に戻すのに成功するまで、動作可能ではな
い。
ノード・プロセッサが現在の状態を検査し変更して、
リンクの状態を決定し、リンクをイネーブルしまたディ
スエーブルすることができる。また、特定の事象が発生
した時に、ハードウェア状態が自動的に変化することも
できる。
使用不能状態 この状態では、送信機は全ビット0を出力し、受信機
はトータル・リセットだけに応答する。ローカル・リセ
ットの実行後、または他の何らかの状態でトータル・リ
セットを指定するパケットを受信した時に、自動的に
「使用不能」状態に入る。また、この状態は、リンクER
P中に明示的に選択される。
遠隔ノードによる認識を保証するため、「使用不能」
状態の最少持続時間は、5フレーム期間である。
使用可能状態 ノードが、通信を開始する準備ができた時、そのノー
ドのプロセッサは、まずライン・ドライバとライン・レ
シーバが回線障害を示していないことをチェックする。
ノード・プロセッサは、その後、ハードウェア状態を
「使用可能」に明示的に変更できる。この状態で、送信
機はFLAGを出力し、受信機はFLAGを聴取する。FLAGが検
出された時、リンク・ハードウェアは、自動的に「作動
可能」状態に入る。ノード・プロセッサが、この遷移を
検出するために、ポーリングを行う必要がある場合があ
るが、ハードウェアで割込みを行ってもよい。
作動可能状態 これは、通常の通信の状態である。
遠隔ノードに、バイト同期を獲得するのに十分な時間
を与えるために、ノードは、最初に「作動可能」になっ
た時、他のフレームを送信する前に、少なくとも5つの
FLAGを送信しなければならない。
ノードが最初に「作動可能」になった時、送信機は、
少なくとも1つのインバウンド・パケット・バッファが
使用可能な時に、1つのRR応答を送信する。同様に、送
信機は、1つのRR応答を受信するまで、パケットを送信
しない。
チェック状態 ハードウェアがエラーを検出し、またはリンク・リセ
ットを指定するパケットを受信した時、自動的にこの状
態に入る。その後、リンクERPがハードウェアを「作動
可能」状態に戻すことに成功するまで、リンクは動作不
能である。「チェック」状態に移ると、リンクERPが呼
び込まれる。
ハードウェアが「チェック」状態に入った時、送信機
は、現パケットが存在するならばその完了後にデータ・
パケットの送信を停止する。送信機はその後、下記の場
合を除き、FLAGを連続的に送信する。
・受信機が、送信機に応答の送信を指令する場合。
・ノード・プロセッサが、送信機にリンク・リセットま
たはトータル・リセットの送信を指令する場合。
受信機は、リンク・リセットまたはトータル・リセッ
トを指定する場合を除き、入力パケットをすべて捨て
る。また、受信機はRR応答をも捨てるが、ACK応答は受
け入れられ処理される。
「チェック」状態では、アプリケーションは、送信バ
ッファを満たすこと、および受信バッファを空にするこ
とを延期する。これは、誤った受信機パケットをメモリ
に転送しないようにするためである。
循環モード 上記の状態とは独立に、ノードは、そのリンク・ハー
ドウェアを「循環」モードで作動させることができる。
これは、ローカル・ハードウェアの電源オン自己試験
(POST)の実行に有用である。「循環」モードでは、送
信機出力が、受信機入力に内部的に接続される。これに
よって、パケットとその応答が同じ回線を共用する点を
除き、通常のプロトコロルを使用する半二重通信が可能
になる。遠隔ノードを必要とせずに、リンク・ハードウ
ェアが完全に試験できる。
「循環」モードの間、アウトバウンド回線は論理0に
保持され、インバウンド回線は無視される。
「循環」モードは、POST後の時点では注意して選択し
なければならない。というのは、構成によっては、ノー
ド・プロセッサがハングした場合に、それをリセットす
ることが不可能なことがあるからである。
通信の開始 リンク・ハードウェアは、電源オンの時点で「使用不
能」状態にある。ノード・プロセッサは、通信を開始し
ようとする時、下記のステップを実行しなければならな
い。
1.回線インターフェース回路が、回線障害を示していな
いことをチェックする。回線障害は、遠隔ノードが動作
不能状態であるか、またはケーブルが接続されていない
ことを示す。
2.リンク・ハードウェアを「使用可能」状態にする。こ
うすると、送信機がFLAGの送信を開始する。
3.遠隔ノードからFLAGを受信した時、リンク・ハードウ
ェアは、自動的に「作動可能」状態に変化する。
4.遠隔ノードからRR応答を受信した時、送信機は「RR待
機中」をリセットする。
5.「作動可能」状態に入った後に少なくとも5つのFLAG
が送信されたならば、この時点でパケットを送信するこ
とができる。
通信の終了 まずリンクを静止状態にしなければならないので、通
信を終了させる方法は、アプリケーションが決定しなけ
ればならない。下記の例は、必要なステップの例を示す
ものにすぎない。
1.通信を終了させようとするノードは、遠隔ノードが未
処理の要求のすべてに応答し終えるまで待つ。その後、
このノードは、リンクの遮断を要求するメッセージを送
信する。
2.遠隔ノードは、ローカル・ノードが未処理の要求のす
べてに応答し終えるまで待ち、その後、遮断を肯定応答
するメッセージを返す。
3.その後、両方のノードが、それぞれのリンク・ハード
ウェアを使用不能にする。
物理媒体 変調 データは、NRZI法を使用してベースバンド・デジタル
信号として伝送される。ビット‘1'は、回線の状態を反
転することによって信号化される。ビット‘0'の場合、
回線の状態は変化しない。
刻時 直列リンクは、同期式に動作する。受信機は、送信さ
れたデータの遷移から、適当なクロックを抽出しなけれ
ばならない。
符号化 同期式の刻時では、0の長いシーケンスを有すること
が望ましくないので、送信機の使用できるビット・パタ
ーンが制限される。したがって、送信したいデータを伝
送に適したパターンに変換する、符号化アルゴリズムが
必要である。
本明細書で説明する直列インクでは、送信されるデー
タ・ストリーム内に4個以上の0が連続することが絶対
にないことが保証されている、4B/5Bコードを使用す
る。
送信機は、入力データ・ビットを4ビットごとに、16
個の5ビット「データ記号」の1つに符号化する。また
5つの「制御信号」が、リンク制御機能のために自由に
使用できる。刻時要件に違反することを避けるように注
意を払う場合には、11個の「制限付き記号」のうちのい
くつかも使用できる。
データ・フレーム 本明細書では、下記の表記法を使用する。
符号化されないバイトのビットには、左から右に0か
ら7の番号を付ける。
符号化されたフレーム内のビットは、a、b、c、
d、e、f、g、h、j、kと呼ぶ。ビット‘a'が、最
初に回線上に送信される。
10ビットのデータ・フレームは、送信しようとするデ
ータの16進表記の各桁を4B/5Bコードに従って符号化す
ることによって構成される。ビット0〜3をまず符号化
し、その後ビット4〜7を符号化する。したがって、
‘23'xは、下記のように符号化される。
プロトコル・フレーム プロトコル・フレームは、少なくともその一方が制御
記号である、2つの記号の組合せから構成される。これ
によって、プロトコル・フレームを、必ずデータ・フレ
ームから識別できることが保証される。2つの制御記号
を含むプロトコル・フレームは、回線上のノイズに対す
る追加の保護を提供する。制御記号は、データ記号と少
なくとも1ビットが異なるので、このようなフレーム
は、データ・フレームと少なくとも2ビットが異なる。
5つの制御記号が使用可能なので、このようなプロトコ
ル・フレームが、最高25個もたらされる。
1つの制御記号と1つの制限付き記号から構成され、
かつ連続する0が3個以内という刻時要件に合致するフ
レームが、幾つか存在する。このようなフレームの1つ
を、FLAGに使用する。この特定のフレームを選択したの
は、それが、データ記号と制御記号の可能なすべての組
合せのどの相でも発生しないからである。したがって、
これを用いると、受信機が、フレーム同期を獲得し検証
できるようになる。またFLAGフレームは、リンクが遊休
状態の時のRFIを最小にするために、比較的少数の遷移
を含む。
下記の4つのプロトコル・フレームだけが定義されて
いる。
違法フレーム:10ビットのフレームは、1024通りの可能
なビット・パターンをもたらす。これらのパターンのう
ち256個がデータ・フレームであり、4個がプロトコル
・フレームであるので、未定義のパターンが764個残っ
ている。あるノードが、「作動可能」状態にある間に未
定義フレームを受信した場合、「違法フレーム」エラー
を指示する。違法フレーム‘0000000000'Bには、特別な
意味がある。これが一貫して発生する場合、遠隔ノード
が「使用不能」状態にあることが指示される。したがっ
て、受信機は、「無フレーム」指示を提供して、リンク
ERPがこの状態を検出できるようにする。
次に、データ・パケットの送信と受信を、第2図、第
3図および第5図を参照して説明する。
第8図は、DMAバスおよび入出力バスを介してマイク
ロプロセッサ10に接続された第1図のノードの1つの構
成要素を示す。マイクロプロセッサには、データ・バッ
ファ12が接続されている。マイクロプロセッサは、デー
タ・バッファのアドレッシングと制御を行う論理回路を
含んでいる。また、マイクロプロセッサは、データ・バ
ッファからリンク・ハードウェアのパケット・バッファ
へのデータ転送を制御するDMA FSMを含んでいる。DMA
転送の詳細は、本発明は直接関係せず、したがって説明
しない。本発明を利用する他のシステムでは、伝送する
データをパケット・バッファに転送する他の手段を備え
ることもできる。本明細書で説明するシステムでは、リ
ンクに入るデータとインクから出るデータが、すべてデ
ータ・バッファを経由する。パケット・バッファは、リ
ンクに到着したデータによって満たされ、また本明細書
で説明する実施態様では、データ・バッファからデータ
を取り出すDMAによって満たされる。入出力バスは、入
出力インターフェースをマイクロプロセッサに接続し、
マイクロプロセッサによって、リンク論理回路内に実施
される一連の外部レジスタにアクセスするために使用さ
れる。さらに、マイクロプロセッサは、データ・フィー
ルド内にメッセージ情報を含む点でデータ・パケットと
異なる、メッセージ・パケットを作成できる。メッセー
ジ・パケットは、アウトバウンド・リンク・メッセージ
・バッファ内に保持され、そこから通常のデータ・パケ
ットに同様の方式で伝送される。メッセージ・パケット
は、コマンドおよび状況用、ならびにデータ伝送の開始
に使用される。
第2A図および第2B図は、互いに接続した図であり、関
連するパケット・バッファRAM20およびパケット状況RAM
30を有するインバウンド・リンクおよびアウトバウンド
・リンクの主要構成要素を示す。インバウンド・リンク
用およびアウトバウンド・リンク用のA/Bパケット・バ
ッファがパケット・バッファRAM内に含まれ、各A/Bパケ
ット・バッファに関連するパケット状況レジスタがパケ
ット状況RAM内に含まれる。パケット状況レジスタは、
パケット・バッファ内に記憶されるデータ・バイトの数
のカウントを保存し、アドレス情報を保持する。アウト
バウンド・パケット・バッファとインバウンド・パケッ
ト・バッファはそれぞれ、対応するパケット状況レジス
タ(PSR)を必要とする。パケット状況レジスタは、16
ビット幅であり、それぞれが下記の2つのフィールドを
含んでいる。
(i)8ビットの宛先フィールド:アウトバウンド・パ
ケットの場合、このフィールドは、対応するパケット・
バッファ内容がリンクによって送信される時に出力パケ
ットのアドレス・フィールドにコピーされる値を保持す
る。この値は、パケットがパケット・バッファに取り出
されている時に、送信に備えてハードウェアが自動的に
ロードすることができる。インバウンド・パケットの場
合、このフィールドは、入力パケットのアドレス・フィ
ールドから抽出されたアドレスを保持する。この値は、
インバウンド・リンクFSMによってPSRに書き込まれ、そ
の値は、パケットの後続経路指定の決定に使用される。
(ii)8ビットのバイト・カウント・フィールド:アウ
トバウンド・パケットの場合、このフィールドは、対応
するパケット・バッファ内に置かれたバイト数を示す値
を保持する。リンクがこのパケットを送信する時、この
値を、バイト・カウンタ(リンク・ハードウェアの一
部)にコピーしなければならない。このバイト・カウン
タは、各データ・バイトが送信されるごとに減分され
る。PSR内のこの値は、リンク送信中のエラーのためそ
のパケットを送信しなければならない場合に備えて保存
される。インバウンド・パケットの場合、このフィール
ドは、入力パケット中で受信されたデータ・バイト(2
つのCRCバイトを除く)の数を示す値を保持する。
第3A図および第3B図は、アウトバウンド(Tx)FSMの
様々な状態と、状態間の遷移を示す。前述したように、
2つのFSMが存在し、その1つは、パケットの送信を制
御するパケットFSM(第3A図)、もう1つは、ACK応答と
RR応答の送信を制御する制御FSM(第3B図)である。Tx
FSMおよび接続されたハードウェアをブロック図の形
で示す第2A図および第2B図を参照して、Tx FSMの制御
の下でのデータ・パケットの送信を説明する。
アウトバウンド・パケット状況調停論理回路52は、各
パケット・バッファに関連するアウトバウンド・パケッ
ト状況ビットを連続的に監視して、送信の準備のできた
データがバッファ内にあるか否かを判定する。そうであ
る場合には、線110上のパルスによってTxパケットFSMに
通知される。それと同時に、調停論理回路52は線120に
パルスを送り、その結果、バイト・カウンタ58が、8ビ
ット・カウント・フィールドに記憶された値を、送信す
べきデータを含むパケット・バッファに関連するパケッ
ト状況レジスタにロードする。したがって、このバイト
・カウンタは、その特定のパケット中で送信すべきデー
タ・バイトの数に対応する値を保持する。パケット伝送
の間、このカウンタは、データ・パケット・バッファか
ら各バイトが送信されるごとに減分される。このカウン
タが0に達した時、線112上にパルスが置かれる。
パケットFSMは、線110上で信号を受信した時、Tx FS
Mとエンコーダ82の間のFLAG線をローにセットし、それ
によって、エンコーダによるFLAGフレームの送信を停止
させる。その後、パケットFSMは、制御情報を求める要
求を線102(第2A図および第2B図)上に提示する。デー
タ・パケットの制御フィールドは8ビットを含むことを
想起されたい。通常の(すなわち、リンク・リセット・
パケットでもトータル・リセット・パケットでもない)
データ・パケットの場合、制御フィールドの最初の6ビ
ットは、0にセットされる。これらの6ビットは、制御
フィールド・レジスタ54から得られ、線102上の信号
は、マルチプレクサ56に、マルチプレクサ56をマルチプ
レクサ66に接続する線104上に送り出される6ビットを
パスさせる。パケット・順序番号情報を含む制御バイト
の最後の2ビットは、TSNレジスタ70から得られ、制御
フィールド・レジスタからの6ビットに追加される。TS
Nレジスタに保持される送信順序番号は、パケットが送
信されるごとに増分され、具体的には、パケットFSMが
「制御送信」状態に入る時に増分される。
パケットFSMが「アドレス送信」状態に入る時、アド
レス要求線101にパルスが送られ、その結果、マルチプ
レクサ56が、関連するパケット状況レジスタの宛先フィ
ールドに含まれる8ビットのアドレス情報をパスする。
このアドレス情報は、その後線104に渡される。マルチ
プレクサ56の排他的な性格のために、どの時点でも制御
線、アドレス線およびデータ線のうちの1つだけがセッ
トされ、したがって、どの時点でも、制御バイト、アド
レス・バイトまたはデータ・バイトのうちの1つだけが
線104上に存在する。
次に、パケットFSMは、「アドレス送信」状態から移
行して、バイト・カウンタが0にセットされているか否
かをチェックする。そうである場合は、パケット・デー
タ・フィールド内に送信すべきデータがなく、FSMは「C
RC1、2送信」状態に移る。線112が、バイト・カウンタ
が0にセットされていることを示さない場合は、送信す
べきデータが存在し、FSMは「データ送信状態」に入
る。データ要求線103は、マルチプレクサに、線203およ
び線104を介してパケット・バッファからデータ・バイ
トをパスさせる。データ要求信号が送信されるたびに、
バイト・カウンタが4の剰余系で減分される。
送信されるデータ・パケットはまた、2つのデータ・
フレームからなるCRCフィールドを含んでいる。CRCフィ
ールドは、アウトバウンドCRCジェネレータ68内の2つ
の8ビットCRCレジスタ内で計算される。2つのレジス
タは、各パケットの開始時に、具体的には、Txパケット
FSMが「制御送信」状態に入る時、全ビット0にプリセ
ットされる。その後、CRCは、アウトバウンドCRCジェネ
レータ68内のレジスタによって、制御フィールド、アド
レス・フィールドおよびデータ・フィールドにわたって
累算される。パケット・バッファ内に含まれるデータの
最終バイトが送信された時(バイト・カウンタ58が0ま
で減分された時)、FSMは、「CRC1、2送信」状態に入
り、この状態で、2つのCRCレジスタがエンコーダによ
って10ビット・フレーム(CRC1およびCRC2)に符号化さ
れ、送信される。CRC1とCRC2を送信し終えた時、FSM
は、ACKタイマ72を走行状態にセットする。前データ・
パケット用のACKフレーム対がインバウンド・リンクに
よって受信されていない場合、FSMは、FSMとエンコーダ
の間のNUL線をハイにセットし、これによって、エンコ
ーダにNULフレームを送信させる。ACKタイム・アウトが
発生する前にACKフレームが受信された時は、NULフレー
ムの送信が停止され、FSMはFLAG線をハイにセットし、
その結果、パケットの終わりを定義するFLAGフレームが
送信される。送信を待っているデータがまだある場合
は、このパケット送信プロセス全体を繰り返す。そうで
ない場合は、FSMは、FLAGフレームを連続的に送信させ
る。
制御フィールド、アドレス・フィールド、データ・フ
ィールドおよびCRCフィールドを符号化し終えた後、パ
ケットは、シリアライザを通過し、ドライバ86によって
アウトバウンド対撚り線を介して送信される。
データ・パケット送信中の任意の時点で、RRまたはAC
Kのどちらかの応答フレームの対を送出する必要がある
かもしれない。応答の送信は、パケットの送信よりも高
い優先順位を有するので、データ・パケット送信に割り
込む手段を設ける必要がある。ACK応答またはRR応答の
送信は、Tx制御FSMによって制御される。これは、デー
タ・パケットの送信中は、通常は遊休モードである。制
御FSMが線107または線108を介してRx FSMから信号を受
信した時、TxパケットFSMが割り込まれ、制御FSMが起動
する。必要な応答がACKであるかRRであるかに応じて、
制御FSMは、Tx FSMとエンコーダの間のRR線またはACK
線をハイにセットし、その後、このエンコーダは、10ビ
ットのACKフレームまたはRRフレームの対を送出する。
これが終った時、制御FSMは遊休状態に戻り、パケットF
SMは、部分的に処理済みのデータ・パケットの送信を再
開する。
次に、直列リンクの他端にある送信機によって送信さ
れたデータ・フレームおよび応答フレーム(RRとACK)
のパケットを受信する際のRx FSMの動作について説明
する。第4A図および第4B図は、2つのRx FSM(パケッ
トFSMおよび制御FSM)の状態を示し、第2A図および第2B
図は、FSMおよび接続された構成要素を示す。第4A図を
参照すると、RxパケットFSMは、通常は遊休状態にあ
り、デシリアライザ94から線140を介してFLAGフレーム
の受信を示すパルスを受信している。前述したように、
受信機での同期を維持するため、データ・パケットが送
信されない時は、FLAGフレームが連続的に送信される。
RxパケットFSMは、FLAGフレーム以外のフレームを受信
した時に限って「覚醒」する。データ・フレーム(すな
わち、制御フレーム、アドレス・フレームまたはデータ
・フレーム)がインバウンド4/5デコーダ92によって検
出された時、デコーダとRxパケットFSMの間のデータ線
にパルスが送られ、その結果、RxパケットFSMは「制御
受信済み」状態に入る。FSMは、線152にパルスを送り、
これによってバイト・カウンタ64をリセットする。カウ
ンタ64は、パケットの末尾に期待される2つのCRCフレ
ームの分を補償するために、実際には−2にリセットさ
れる。線152上のパルスはまた、書込みポインタ62をも
リセットする。またCRCアキュムレータが、FSMが制御フ
レーム受信済み状態に入る時にプリセットされる。Rx
FSMから出るCNTRL HERE線にパルスが送られ、これによ
って、外部論理回路に、8ビット・バスrx−DATA上に提
示しようとするデータが、受信したばかりの制御フレー
ムであることを伝える。この制御フレームは、53によっ
てゲートされ、その情報は、外部論理回路からアクセス
できるようにレジスタ55内に保持される。制御フレーム
を受信し終えた後、通常は第2のデータ・フレームが期
待される。しかし、次に受信されるフレームが、デシリ
アライザによって検出されるFLAGであるという場合もあ
り得る。これは、受信されたと思われた制御フレームが
入力線上の障害によってもたらされたものであった場合
に発生し得る。FLAGが受信された場合、FSMは、プロト
コル・エラーを指示する。次フレームがデータ・フレー
ムである場合、デコーダとFSMの間のデータ線にもう一
度パルスが送られ、その結果、FSMは、「アドレス・フ
レーム受信済み」状態に入る。その後、FSMは、ADDR H
ERE線146にパルスを送り、これによって、このリンクの
外部の論理回路に、8ビット・バス150上のデータがア
ドレス・フレームであることを伝える。このアドレス・
フレームは、57によってゲートされ、このアドレス・フ
レームを構成するバイトは、一時的にレジスタ59に保持
される。外部論理回路は、このアドレスを参照し、この
アドレスが有効であるか否かを決定する。有効でない場
合、パケット拒否エラーが示される。
アドレス・バイトを受信し終えた後、次のフレーム
は、そのパケット内にデータ・フィールドがあるか否か
に応じて、データ・バイトまたはCRCバイトのいずれか
になる。FSMは、「データ/CRC受信済み」状態に入る。
この段階では、データ・ブレームとCRCフレームは互い
に区別できない。FSMは、線148にデータ・フレームの存
在を示すパルスを送る。バイト・カウンタと書込みポイ
ンタが増分され、このデータ・フレームは、パケット・
バッファに転送される。データ・フレームを受信するご
とに、パケットFSMはデータ・フレーム受信ループを循
環し、1フレームを受信するごとに、バイト・カウンタ
と書込みポインタが増分される。各フレーム(制御フレ
ームとアドレス・フレームを含む)を受信するごとに、
インバウンドCRCアキュムレータ95は、入力フレームに
わたってCRCを累算する。すべてのデータ・フレームを
受信し終えた時、FLAGがデシリアライザによって検出さ
れる。この結果、次のデータ・パケットが入り始めるま
で、Rx FSMは遊休状態に戻る。末尾のFLAGを受信してF
SMの「データ受信済み」状態から脱出する時、FSMは、
線154に最終バイトを受信し終えたことを示すパルスを
送る。さらに、そのパケットが、プロトコル・エラー、
CRCエラーまたは他のエラーを伴わずに受信された場合
には、FSMは、線156にパルスを送る。エラーが検出され
ておらず、CRCチェックサムが正しい場合は、Rx FSM
は、線107にパルスを送り、これによって、TxパケットF
SMがパケット送信の途中であるならばこれを凍結し、Tx
制御FSMに、上記の通り1対のACKフレームを送出させ
る。レジスタ内のRSNも増分される。154と156にパルス
が送られる時、バイト・カウンタ64内に記憶されたカウ
ントが、データが書き込まれたパケット・バッファに関
連するパケット状況レジスタにコピーされる。レジスタ
59内に保持されているアドレスも、この状況レジスタの
宛先フィールドにコピーされる。このレジスタのアドレ
ス・フィールドとカウント・フィールドを書き込み終え
た後、線158上のパルスによってi/bパケット満杯(i/b
pkt full)ビットがセットされ、これによって、1パケ
ットが正しく受信され、アクセスの準備ができているこ
とが、外部論理回路(その受信済みのデータを使用する
論理回路)に示される。パケットの受信中に、デコーダ
によって違法フレームが検出された場合、そのパケット
のその時点までに受信された部分が捨てられる。
前述したように、このリンクの全二重動作中に、応答
フレーム(RRまたはACK)をデータ・パケットにインタ
ーリーブすることができる。したがって、上述のように
パケットの受信中に、デコーダが1対のACKフレームま
たはRRフレームを検出することがある。通常は遊休状態
にあるRx制御FSMが起動する。RRフレームが検出される
時、制御FSMは、“Rx RR1"状態に入る。第2のRRフレ
ームが検出された場合(そうなるはずである)、FSM
は、“Rx RR2"状態に入る。その後、FSMは、有効なRR
応答を受信済みであることを示し、その結果、線160に
パルスが送られ、これによって、遠隔ノードが次データ
を受信する準備ができていることが、パケット調停論理
回路52に示される。調停論理回路は、バッファ内に送信
すべきデータがあるか否かを知っており、存在する場合
には上述の通りパケット送信を開始する。Rx制御FSM
は、1対のACKフレームを受信する場合、線162にパルス
を送らせる。調停論理回路は、活動記録ログに、有効な
ACK応答を受信済みであることを示す。活動記録ログ
は、肯定応答が必要な未処理のパケットがどれであるか
を知っている。その後、肯定応答されたパケットを含む
Txパケット・バッファを、次のデータに備えてクリアす
ることができる。
エラー回復手順(ERP) 直列リンクのこのアーキテクチャでは、パケット・レ
ベルで伝送エラーを回復する方法が定義されている。回
復は、既存の送信パケット・バッファを使用する内蔵リ
ンクERPによって実行される。これには、下記の利益が
ある。
・回復が不可視であるので、アプリケーション・ソフト
ウェアが簡単になる。
・エラー発生時に動作を終了させる必要がない。
・遠隔ノードの状態に関する不確実性がない。
・異なる実施態様の互換性が強化される。
パリティ検査などのハードウェア・エラーは、パケッ
ト・レベルでは回復可能ではない可能性があることに留
意されたい。データが失われたり、未知の状態変化が発
生している可能性がある。この場合には、やはりアプリ
ケーションが回復を実行しなければならない。使用する
システムのより高いレベルが、進行中の動作を一旦終了
させ、その動作を繰り返す。ハードウェア・エラーは、
伝送エラーよりもはるかに頻度が低いので、これは許容
できる解決方法である。
このエラー回復方法の基本原理は、次の通りである。
1.通常動作(上記で詳細に説明した)では、送信機は、
ACK応答を受信するまで、パケット・バッファを再利用
しない。ACK応答の受信は、そのパケットが宛先ノード
によって正しく受信されたことを示すものである。した
がって、エラーが発生する時は、影響を受けたパケット
は、まだ再送信のために使用可能である(ノードは、第
1パケットに対する肯定応答を受信する前に第2パケッ
トの送信を開始できるので、再送信が必要なパケットは
多くとも2つである)。
2.エラーが検出される時、両方のノードが、「チェッ
ク」状態に入り、リンクERPを呼び込み、リンク・リセ
ットによって状況を交換する。
3.回復は、回線ごとに別々に実行される。各ノードは、
そのアウトバウンド回線上で失われたパケットを回復す
る責任を負う。送信機は、ACK応答を受信する前に次の
パケットの送信を開始できるので、パケットを再送信す
る必要があるパケットは最高2つである。
4.通信を再開する前に、リンクERPは、ハードウェアを
強制的に「使用不能」状態にして、両方のノードが同等
の状態になるようにする。
5.リンク・プロトコルとリンクERPは、エラー発生時に
パケットの喪失または複製の可能性が最小になるように
設計されている。しかし、アプリケーションは、可能な
場合には必ず、これらの事象に対してそのアプリケーシ
ョン自体を保護しなければならない。たとえば、データ
転送の終了時にバイト・カウントが0になっていること
をチェックすることが可能であり、タイム・アウトを使
用して、メッセージ・パケットの喪失を検出することが
できる。
リンク・エラー 特に明記した場合を除して、以下のエラーは、そのエ
ラーの前にリンク・ハードウェアが「作動可能」状態に
ある時に限って指示される。どの場合にも、ハードウェ
アが「チェック」状態に入り、ノード・プロセッサに割
り込む。リセットを除き、それ以上のパケットは、ハー
ドウェアが「作動可能」状態に戻らない限り、受け入れ
られずまた肯定応答されない。ハードウェアが「作動可
能」状態でない場合は、一般にエラーは無視される。
ACKタイムアウト:これが指示されるのは、トータル・
リセット以外のパケットの後端FLAGの送信に対して、指
定された時間内にソースがACK応答を受け取らなかった
時である。影響を受けるパケットは、リンクERPによる
再送信の可能性があるため、送信バッファ内に残され
る。
違法フレーム:このエラーが指示されるのは、4つのプ
ロトロル・フレームのうちの1つでも、256個のデータ
・フレームのうちの1つでもないフレームを、受信機が
復号した場合である。
プロトコル・エラー:このエラーが指示されるのは、下
記の無効または予期されないフレーム・シーケンスをノ
ードが受信した時である。
1.2つのFLAGの間に3個以内のデータ・フレームを有す
る短いパケット。これは、ノイズのためにFLAGが化けた
かまたはFLAGが作成されたことによって発生し得る。
2.ノードが、リセットを指定しない制御フィールドを受
信し、使用可能なバッファがない、すなわち「RR保留
中」がセットされている時。
3.予期されないACK応答、すなわち「ACG待機中」がリセ
ットされている時。
4.孤立したACKフレーム。ACK応答が化けた場合は、送信
機もACKタイムアウトを検出する。
5.孤立したRRフレーム。
6.最後のFLAG以降に介在するデータ・フレームがないNU
Lフレーム。
エラーが検出されずにRR応答が失われた場合、たとえ
ば、リンクが遊休状態の間にRRがFLAGに変化する場合な
どには、リンクの半分がハングする。これは、非常に可
能性が低く、したがって、リンク・レベルでの回復は提
供されない。その代わりに、アプリケーションが、進行
中の動作に対するタイムアウトを提供しなければならな
い。
CRCエラー:このエラーが指示されるのは、受信パケッ
トのCRCが狂っており、上記のエラーがどれも発生しな
かった時である。
シーケンス・エラー:このエラーが指示されるのは、受
信パケットがRSNに等しくないPSNを有し、上記のエラー
がどれも発生しておらず、そのパケットがリセットを指
定していない時である。おそらく、前のパケットが、失
われている。
パケット拒否:このエラーが指示されるのは、上記のど
のエラーも伴わずに1パケットが正しく受信されたが、
下記のいずれかの理由でそのパケットが受け入れられな
い時である。
1.そのパケットが長すぎて、使用可能なバッファに収ま
らない。受信機は、FLAGの化けなどの伝送エラーが存在
しないことを検証するために、バッファがオーバーフロ
ーした後にもCRCの累算を継続しなければならないこと
に留意されたい。
2.パケット長が、上記以外の理由でその実施態様では受
け入れられない。たとえば、偶数でなければならない時
に奇数であるなど。
3.制御フィールド内のユーザ定義ビットが、その実施態
様には受け入れられない。
4.アドレス・フィールドが、現在無効なまたは実施され
ていない宛先を指定しており、制御フィールドがリセッ
トを指定していない。
この種のエラーは、プログラミング、同期、または互
換性の問題に起因するものである。リンクERPは、これ
らに対して再試行を行わない。その代わりに、ERP出口
を介してアプリケーションに警告が出され、その結果、
アプリケーションが進行中の動作を再試行または終了で
きるようになる。
回線障害:このエラーが指示されるのは、ライン・ドラ
イバまたはライン・レシーバが無効な電圧を検出し、リ
ンク・ハードウェアが「使用不能」状態にない時であ
る。ケーブルが切れているかまたは短絡しており、ある
いは遠隔ノードが電源オフになっている可能性がある。
ハードウェア・エラー:このエラーが指示されるのは、
ノードが、パリティ・チェックなどの内部ハードウェア
・エラーを検出した時である。リンクERPは、この種の
エラーに対して再試行しない。その代わりに、ERP出口
を介してアプリケーションに警告が出され、その結果、
アプリケーションが、進行中の動作を再試行または終了
できるようになる。
リンク状況バイト エラー回復の間に、各ノード内のリンクERPは、リン
ク状況バイトを作成し、このリンク状況バイトをリンク
・リセット・パケットのアドレス・フィールド中で相手
ノードに送信する。第6図に、リンク状況バイトのフォ
ーマットを示す。
H/Wエラー ‘1'の時、このビットは、そのノードが内
部ハードウェア・エラーを検出したことを示す。
回線障害 ‘1'の時、このビットは、そのノードがイン
バウンド対またはアウトバウンド対のいずれかで回線障
害を検出したことを示す。これは、情報提供だけの目的
で設けられたものであり、宛先ノード内のリンクERP
は、このビットを参照しない。
ACK T/O ‘1'の時、このビットは、ACK応答を待つ間
に送信機がタイムアウトになったことを示す。これは、
情報提供だけの目的で設けられたものであり、宛先ノー
ド内のリンクERPは、このビットを参照しない。
受信機エラー このフィールドは、その受信機によって
検出された最初のエラーを識別する3ビット・コードを
含む。
000 エラーなし 001 違法フレーム 010 プロトコル・エラー 011 CRCエラー 100 シーケンス・エラー 101 パケット拒否 2つ以上のエラーが同時に発生する時は、最も小さい
数字が報告される。
RSN これは、リンク・リセットを除く、そのノードに
よって肯定応答された最後のパケットの受信順序番号で
ある。これは、遠隔ノード内のリンクERPに必要であ
る。
次に、エラー検出時にリンク状況バイトをどのように
コンパイルするかを詳細に説明する。
エラー回復は、両方のノードに対して対称的である。
エラーが発生した時、両方のノードが「チェック」状態
に入り、リンクERPを呼び込む。リンクERPは、通常は、
ノード・プロセッサ上で走行するソフトウェア内で実施
されるものと想定する。ただし、性能がクリティカルな
場合には、これらの機能をハードウェアFSMによって実
行することも考えられる。
伝送エラーが発生したとERPが判定した場合、ERPは、
そのエラー自体の回復を試みる。回復に成功した場合、
リンクERPは終了し、アプリケーションは、そのエラー
を知ることなく継続する。
ERPは、たとえばハードウェア・エラーや永続回線障
害など、いくつかのエラーを、不可視の状態で回復する
ことができない。これらの場合には、ERPはアプリケー
ションに脱出し、アプリケーションは、その後、リセッ
トを実行し、進行中の動作を打ち切らなければならな
い。ERPは、両方のノードが必ず回復不能エラーを認識
し、同期状態に保たれるように、注意深く設計される。
本明細書の説明に含まれる時間間隔は、例示のための
ものにすぎず、実際には、時間間隔は、アプリケーショ
ンと実施態様に応じて変わることに留意されたい。
エラーを検出した第1の(または唯一の)ノードが
「チェック」状態に入り、そのリンクERPを呼び込む。
リンクERPは、下記のように機能する。
1.ERPは、送信中のパケットがあるならば、送信機が現
パケットの送信を終了するまで待つ。
2.次に、ERPは、ハードウェアを参照することによって
インク状況バイトを作成する。
3.ライン・ドライバまたはライン・レシーバが回線障害
を検出した場合、ERPは、そのエラーの回復を試みる。
これに失敗した場合は、ERP出口を介してアプリケーシ
ョンに警告が出される(「永続回線障害」)。
4.ERPは、受信機が「無フレーム」エラーを示している
か否かをチェックする。そうである場合には、遠隔ノー
ドが電源オフまたは「使用不能」状態になっている可能
性がある。ERP出口を介してアプリケーションに警告が
出される(「遠隔ノード使用不能」)。
5・ERPは、後で使用するためTSNレジスタ70に保持され
るローカルTSNをセーブする。
5.ERPは、送信機に、ローカル・リンクのリンク状況バ
イトを含むリンク・リセット・パケットを遠隔ノードへ
送るよう指令する。遠隔ノードは、まだ「チェック」状
態に入っていない場合、この時点で「チェック」状態に
入らなければならない。どちらの場合でも、遠隔ノード
は、そのリンクERPを呼び込み、遠隔ノードのリンク状
況バイトを含むリンク・リセットを返す。
7.ERPは、ERPが送信したリンク・リセットに対する肯定
応答を受信するために待つ。また、ERPは、遠隔ノード
からのリンク・リセットを受信するために待つ。ACKタ
イムアウトが発生するか、または1ミリ秒後にリンク・
リセットが受信されていない場合、ERPは、別のリンク
・リセットを送信する。ACKタイムアウトが発生する
か、またはさらに1ミリ秒後にリンク・リセットが受信
されていない場合は、ERP出口を介してアプリケーショ
ンに警告が出される(「リンク・リセット失敗」)。
8.この実施態様は、永続エラーが存在する場合のERPル
ープに対する保護を行わなければならない。エラー回復
には必ず両方のノードが関係するので、たとえば階層シ
ステムの上位にあるノードなど、1つのノードだけがこ
の保護を提供すれば十分である。以下は、使用可能な1
つの方法の例である。ERPの呼込みごとに、再試行カウ
ンタが増分される。この再試行カウンタは、タイマによ
って周期的に0にリセットされる。タイマの1周期内の
再試行の回数である最大値を超える場合、ERPは、10ミ
リ秒待って、再試行が打ち切られようとしていることを
遠隔ノードが確実に認識できるようにする。その後、ER
P出口を介してアプリケーションに警告が出される
(「再試行限界超過」)。この方式によれば、外部ノイ
ズが深刻な場合のERPの過度の使用に対する保護ももた
らされる。
9.どちらかのノードがハードウェア・エラーを検出した
場合、ERP出口を介してアプリケーションに警告が出さ
れる(「ハードウェア・エラー」)。ERP出口は、その
エラーを検出したノードをも示す。(ローカル・ノー
ド、遠隔ノードまたは両方。) 10.どちらかのノードが「パケット拒否」を指示した場
合、それ以上の通信は無意味である。ERP出口を介して
アプリケーションに警告が出される(「パケット拒
否」)。ERP出口は、そのエラーを検出したノードをも
示す。(ローカル・ノード、遠隔ノードまたは両方。) 11.そうでない場合は、ERPは、次式に従って、送信され
たが肯定応答されていないパケットの数を計算する。
Q=(Transmit_pointer−Retry_pointer)modulo N ただし、Nは設けられている送信バッファの数、Tran
smit_pointerは送信ポインタ、Retry_pointerは再試行
ポインタである。Qは、0または1パケットにならなけ
ればならない。また、ERPは、次式に従って、送信され
たが受信されていないパケットの数を計算する。
P=(Savet_local−TSN_Remote_RSN)modulo 4 ただし、Saved_local_TSNはセーブされたローカルTS
N、Remote_RSNは遠隔RSNである。Pは、Q以下にならな
ければならない。
これらのチェックのいずれかが失敗した場合、ERP
は、10ミリ秒待って、遠隔ノードが回復不能エラーを確
実に認識できるようにする。その後、ERP出口を介して
アプリケーションに警告が出される(「無効な再試行状
況」)。
12.そうでない場合は、ERPは、その送信ポインタからP
を引き、Nの剰余を取ることによって、失われたパケッ
トを再送信する手筈を整える。
13.再送信する必要のないアウトバウンド・バッファ
は、下記のアルゴリズムを使って、この時点で捨てなけ
ればならない。
Do while Retry_pointer ≠ Transmit_pointer; Retry_pointerの指すバッファを割振り解除する; Retry_pointerのNを剰余系で増分する; End; 14.ノードが、リンク状況バイト内にいずれかの「受信
機エラー」を含むパケットを受信した場合、そのパケッ
トを捨てなければならない。適当なインバウンド・バッ
ファを受信機ハードウェアによって自動的に割振り解除
することができ、ERPがこれを明示的に行うこともでき
る。後者でない場合、ERPは、インバウンド・バッファ
を扱う必要はない。捨てられるバッファが満杯の場合に
は、アプリケーションがそれらを空にする。
15.ERPは、リンクを使用不能にし、ハードウェア・エラ
ー、ACKタイムアウト、および受信機エラー用のラッチ
をすべてリセットする。
16.ERPは、遠隔ノードが「使用不能」状態に入るまで待
つ。この状態は、受信機からの「無フレーム」信号によ
って示される。この待機は、2つのリンクERPを同期さ
せ、遠隔ノードがまだ「チェック」状態にある待に送信
機がRR応答を送らないようにするために必要である。
受信機が1ミリ秒以内に「無フレーム」を指示しない
場合は、ERP出口を介してアプリケーションに警告が出
される(「使用不能状態を待つためのタイムアウ
ト」)。遠隔ノードが、回復不能なリンク・エラーを検
出している可能性がある。
17.そうでない場合、ERPは、リンクを使用可能にする。
18.ERPは、リンクが「作動可能」になるのを待つ。これ
は、遠隔ノードがその回復を完了したことを示す。階層
システムでは、下位ノードが「作動可能」状態を無限に
待つ可能性がある。別法として、下記のようにタイムア
ウトを設けることができる。リンクが1ミリ秒以内に
「作動可能」にならない場合、ERP出口を介してアプリ
ケーションに警告が出される(「作動可能状態を待つた
めのタイムアウト」)。これは、遠隔ノードが電源オフ
になっているか、またはタイプ1のエラーに遭遇した可
能性があることを示す。
19.そうでない場合、ERPは、首尾よく終了する。
各ノードは、「作動可能」になった後、少なくとも1
つのインバウンド・バッファが使用可能になっている
時、相手ノードにRR応答を送信する。これによって、
「RR待機中」がリセットされ、保留中のパケットの送信
が可能になる。
第7図は、リンクERPの動作の1例を示す。ローカル
・ノードが、2つのパケットを連続して送信する。遠隔
ノードは、これらのパケットを正しく受信するが、最初
のパケットに対するACK応答が化けている。そこで、ロ
ーカル・ノードは、違法フレームを検出する。ACK応答
だけが失われたので、パケットを再送信する必要はな
い。送信ポインタ(TP)と再試行ポインタ(RP)の動作
を示すため、ローカル・ノードが4つの送信バッファを
有すると仮定する。遠隔ノードは、2つの受信バッファ
を有する。PとQの値は、前述の式に従って計算した値
である。
エラーの検出と、その結果行われるリンク状況バイト
を含むリンク・リセット・パケットのコンパイルおよび
送信を、第2A図および第2B図を参照して詳細に説明す
る。
パケット送信中にアウトバウンド・リンクによって、
またはパケット受信中にインバウンド・リンクによっ
て、エラーが検出された時、エラー線(たとえば、受信
機回線障害を示す受信機から出る線141や、パケット拒
否エラーを示すRx FSMから出る線161など)にパルスが
送られる。このパルスによって、そのリンク・ハードウ
ェアに関連する2つのレジスタの一方の適当なビットが
セットされる。これら2つのレジスタは、リンク・エラ
ー・レジスタとリンク・ハードウェア・エラー・レジス
タである。リンク・エラー・レジスタは、8ビットのレ
ジスタであり、検出可能なエラーの大半、すなわち、違
法フレーム、プロトコル・エラー、CRCエラー、パケッ
ト拒否、ACKタイムアウト、無フレームおよび回線障害
の指示に使用される。リンク・ハードウェア・エラー・
レジスタは、検出されたハードウェア・エラーの種類を
示す。第3のレジスタとしてリンク状況レジスタがあ
る。このレジスタの2ビットは、アウトバウンド・リン
クのTSNレジスタ70内に維持される送信順序番号(TSN)
の値を示す。この値は、パケットを送信するごとに増分
される。TSNの値は、エラー回復(上述)中に、再送信
が必要なパケットの数を計算するプロセスで使用され
る。リンク状況レジスタの別の2ビットは、インバウン
ド・リンクのRSNレジスタ93によって維持される受信順
序番号(RSN)の値を示す。この値は、パケットを受信
するごとに(すなわち、ACK応答が送信されるごとに)
増分される。この値は、エラー検出時にリンクがチェッ
ク状態に入る時に、凍結される。
エラー検出時に呼び込まれるリンクERPは、これら3
つのレジスタを参照してリンク状況バイトをコンパイル
する。リンクERPは、第8図のマイクロプロセッサによ
って制御される。リンク状況バイトの各ビットはそれぞ
れ、上記3つのレジスタのうちの1つからコピーされ
る。受信機エラー(違法フレーム、プロトコル・エラ
ー、シーケンス・エラー、CRCエラーまたはパケット拒
否エラー)は、リンク状況バイト内で、上述の3ビット
・コードによって指示される。
このようにコンパイルされたリンク状況バイトは、マ
イクロプロセッサによって、アウトバウンド・リンク・
メッセージ・バッファに関連するパケット状況レジスタ
の宛先フィールドにロードされる。PSRのカウント・フ
ィールドは、0にセットされる。第2A図の線204にパル
スを送って、リセット・パケット送信の準備ができてい
ることを示す。その後、リンク・リセット・パケット
が、上記で詳細に説明したデータ・パケットと実質的に
同じ方式で、アウトバウンド・リンク・ハードウェアに
よって送信される。ただし、TxパケットFSMが要求する
制御フレームは、線204から得られ、リンク・リセット
またはトータル・リセットのいずれかを示すように適当
なビットがセットされる。アドレス・フィールドは、通
常の方式でパケット状況レジスタの宛先フィールドから
得られる。リンク・リセットの場合、パケット状況レジ
スタは、コンパイルされたリンク状況バイトを保持して
いる。メッセージ・バッファ内にはデータ・バイトがな
いので、Tx FSMは、2つのCRCバイトと末尾の後端FLAG
で、このパケットを完成する。したがって、上述の方法
を使用すると、リンク・リセット・パケットは通常のデ
ータ・パケットと同じ方式で送信されるので、リンク・
リセット・パケットを送信するために必要なリンク・ハ
ードウェア内の余分の論理回路はほとんどなくなる。
リンク・リセット・パケットが、遠隔ノードのインバ
ウンド・リンクによって正しく受信される時、このパケ
ットは、通常のパケットと同じ方式で肯定応答される。
リンク状況バイトを含むアドレス・フィールドが、リン
クERPによるアクセスの準備ができているインバウンド
・パケット・バッファのパケット状況レジスタにロード
される。このパケットがリセット・パケットであること
を示す制御フィールドは、ラッチ59に保持され、ここか
ら外部論理回路によってアクセスされる。リセット・パ
ケットを受信し終えた時、遠隔ノード内のリンクERPが
呼び込まれ、このリンクERPが、上述と同じ方式でリン
ク状況バイトをコンパイルさせ送信させる。
その後、各ノードは、受信するリンク・リセット・パ
ケット内に含まれるエラー情報を調べる。ノードがエラ
ーの各形式に応答してどのように動作するかは、そのノ
ードに接続されたシステムに応じて変わる。前述したよ
うに、ハードウェア・エラーまたはパケット拒否エラー
が検出された場合、ERPは、パケットの再送信によるエ
ラー回復を試みない。その代わりに、ERPは、ERP出口を
介してアプリケーションに警告する。そうでない場合
は、ERPは、送信済みであるが肯定応答されていないパ
ケットの数を計算する。活動記録ログ51に、この情報が
含まれる。ERPはまた、送信済みであるが受信されてい
ないパケットの数を計算する。この値は、ノードがリン
ク・チェック状態に入った時に凍結されたローカル・ノ
ード内のTSN値から、リンク状況バイトに含まれるRSN値
を引くことによって得られる。したがって、ノードは、
再送信が必要なパケットの数を知る。前述したように、
ノードは、遠隔ノードによって受信されたパケットを捨
てる。
フロントページの続き (72)発明者 ジュウド、イアン、デヴィド イギリス国ハンプシャー、ウインチェス ター、オートーボーン、コールズ・ミー ド33番地 (72)発明者 グレインジャー、バーナード、ジョン イギリス国ハンプシャー、ウインチェス ター、ウイーク、ゴードウイン・クロス 18番地 (72)発明者 コックバーン、ゴードン、ジョン イギリス国ハンプシャー、ラムズイ、ス トリート・プレイズ・ロード106番地 (56)参考文献 特開 昭64−71346(JP,A) 特開 昭62−186636(JP,A) 特開 平2−179146(JP,A)

Claims (3)

    (57)【特許請求の範囲】
  1. 【請求項1】2つのノードが直列リンクによって接続さ
    れ、データが該直列リンクを通してノード間を所定のフ
    ォーマットのパケットの形で転送されるデータ通信シス
    テムにおいて、 各ノードが、 リンクを介して送信しようとするパケットを記憶するた
    めの複数の送信パケット・バッファと、 リンク上で受信したパケットを記憶するための複数の受
    信パケット・バッファと、 パケット受信時に相手ノードに受信応答メッセージを送
    信する手段と、 当該ノードに生じたエラーを検出するためのエラー検出
    手段と、 前記エラー検出手段によるエラーの検出に応答して、エ
    ラー回復手順を呼び出してエラー回復手順を開始すると
    共に、当該ノードが相手ノードから受信した最後のパケ
    ットの順序番号を含むリンク状況バイトを相手ノードに
    送信し、かつ相手ノードがエラーを検出したことにより
    相手ノードから送信されるリンク状況バイトの受信に応
    答して、エラー回復手順を呼び出してエラー回復手順を
    開始すると共に、当該ノードが相手ノードから受信した
    最後のパケットの順序番号を含むリンク状況バイトを相
    手ノードに送信する、エラー回復手段と、 相手ノードからのリンク状況バイトから、相手ノードに
    よって正しく受信されなかったパケットの数を決定し、
    失われたパケットを前記送信パケット・バッファから再
    送信する再送信手段と、 を備えて成るデータ通信システム。
  2. 【請求項2】どの送信パケット・バッファから最後のパ
    ケットが送信されたのかを示す送信ポインタ手段と、 どの送信パケット・バッファから最後に受信応答された
    パケットが送信されたのかを示す肯定応答ポインタ手段
    と、 を更に備えることを特徴とする、請求項1に記載のシス
    テム。
  3. 【請求項3】送信されたが受信応答されていないパケッ
    トの数を送信ポインタ手段および肯定応答ポインタ手段
    を用いて計算する手段と、 この数を、相手ノードからのリンク状況バイトから決定
    される相手ノードによって正しく受信されなかったパケ
    ットの数と比較する事により、再送信の不要なパケット
    を含む送信パケット・バッファを識別する手段と、 を備えることを特徴とする、請求項2に記載のシステ
    ム。
JP3504613A 1990-12-04 1991-02-19 データ通信システム Expired - Fee Related JP2707529B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB9026338.5 1990-12-04
GB9026338A GB2250897A (en) 1990-12-04 1990-12-04 Error recovery in data communication systems.

Publications (2)

Publication Number Publication Date
JPH05503197A JPH05503197A (ja) 1993-05-27
JP2707529B2 true JP2707529B2 (ja) 1998-01-28

Family

ID=10686450

Family Applications (1)

Application Number Title Priority Date Filing Date
JP3504613A Expired - Fee Related JP2707529B2 (ja) 1990-12-04 1991-02-19 データ通信システム

Country Status (6)

Country Link
US (1) US5410536A (ja)
EP (1) EP0513232B1 (ja)
JP (1) JP2707529B2 (ja)
DE (1) DE69120659T2 (ja)
GB (1) GB2250897A (ja)
WO (1) WO1992010893A1 (ja)

Families Citing this family (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7298701B2 (en) * 2002-10-31 2007-11-20 Nokia Corporation Apparatus, and associated method, for requesting data retransmission in a packet radio communication system
US7936664B2 (en) * 1991-03-26 2011-05-03 Nokia Corporation Multi-carrier radio link protocol supervision in a radio communication system
US5509122A (en) * 1992-02-20 1996-04-16 International Business Machines Corporation Configurable, recoverable parallel bus
GB2268373A (en) * 1992-06-20 1994-01-05 Ibm Error recovery in an information communication system
JP2833387B2 (ja) * 1992-11-30 1998-12-09 日本電気株式会社 交換機バスモニタ回路
DE69330399T2 (de) * 1992-12-18 2002-05-02 Advanced Micro Devices Inc HDLC-Empfänger
US5379162A (en) * 1993-08-19 1995-01-03 International Business Machines Corporation Customized data recovery procedures selected responsive to readback errors and transducer head and disk parameters
JPH07262152A (ja) * 1994-03-24 1995-10-13 Hitachi Ltd コンピュータシステム
US6108809A (en) * 1994-11-11 2000-08-22 Siemens Aktiengesellschaft Method for sending messages from a lower-level controller to a higher-level controller
US6282203B1 (en) * 1995-06-28 2001-08-28 Hyundai Electronics Ind. Co., Ltd. Packet data transmitting apparatus, and method therefor
US5893138A (en) * 1995-10-02 1999-04-06 International Business Machines Corporation System and method for improving channel hardware performance for an array controller
US5938786A (en) * 1995-11-30 1999-08-17 International Business Machines Corporation Simplified recovery of damaged frames in a communication link
US5805063A (en) * 1996-02-09 1998-09-08 Interactive Technologies, Inc. Wireless security sensor transmitter
US5761206A (en) * 1996-02-09 1998-06-02 Interactive Technologies, Inc. Message packet protocol for communication of remote sensor information in a wireless security system
US5872512A (en) * 1996-02-09 1999-02-16 Interactive Technologies, Inc. Apparatus and method for reducing errors in a battery operated sensing circuit
US5942981A (en) * 1996-02-09 1999-08-24 Interactive Technologies, Inc. Low battery detector for a wireless sensor
US5809013A (en) * 1996-02-09 1998-09-15 Interactive Technologies, Inc. Message packet management in a wireless security system
GB2315962B (en) * 1996-07-31 2001-07-04 Internat Mobile Satellite Orga Method and apparatus for transmitting data
US6262993B1 (en) 1996-11-08 2001-07-17 Kevin Kirmse Computer and peripheral networking device permitting the practical use of buffer insertion-based networks while communicating over unshielded twisted pair conductive media
US5918002A (en) * 1997-03-14 1999-06-29 Microsoft Corporation Selective retransmission for efficient and reliable streaming of multimedia packets in a computer network
US6031818A (en) * 1997-03-19 2000-02-29 Lucent Technologies Inc. Error correction system for packet switching networks
AU737205B2 (en) * 1997-05-30 2001-08-09 Crossroads Systems, Inc. Error detection and recovery for sequential access devices in a fibre channel protocol
US6038604A (en) * 1997-08-26 2000-03-14 International Business Machines Corporation Method and apparatus for efficient communications using active messages
US6070189A (en) * 1997-08-26 2000-05-30 International Business Machines Corporation Signaling communication events in a computer network
JPH11127220A (ja) * 1997-10-20 1999-05-11 Fujitsu Ltd ネットワークシステム及び通信装置
US6330226B1 (en) * 1998-01-27 2001-12-11 Nortel Networks Limited TCP admission control
US6338090B1 (en) * 1998-03-27 2002-01-08 International Business Machines Corporation Method and apparatus for selectively using input/output buffers as a retransmit vehicle in an information handling system
US6615383B1 (en) 1998-05-29 2003-09-02 Sun Microsystems, Inc. System and method for message transmission between network nodes connected by parallel links
US6266540B1 (en) * 1998-11-30 2001-07-24 Qualcomm Inc Control interface protocol for telephone sets for a satellite telephone system
EP1699143B1 (en) * 1999-03-31 2008-01-23 Alcatel Lucent Method and arrangement to estimate transmission channel characteristics
GB2350984B (en) 1999-06-11 2003-10-15 Mitel Corp Synchronisation method and system
JP3640844B2 (ja) * 1999-09-17 2005-04-20 株式会社東芝 エラー処理機能を備えた伝送装置及びエラー処理方法
US7225383B1 (en) * 2000-01-19 2007-05-29 Sun Microsystems, Inc. System and method for enhancing communication between devices in a computer system
US7099352B1 (en) 2001-01-03 2006-08-29 Juniper Networks, Inc. System, apparatus, and method for increasing resiliency in communications
US7120149B2 (en) * 2001-02-28 2006-10-10 Ericsson Inc. Methods and system for resequencing out of order data packets
US7619886B2 (en) * 2001-09-27 2009-11-17 Alcatel-Lucent Canada Inc. Method and apparatus for providing a common support services infrastructure for a network element
US7710866B2 (en) * 2001-09-27 2010-05-04 Alcatel-Lucent Canada Inc. Method and apparatus for optimization of redundant link usage in a multi-shelf network element
US7447146B2 (en) * 2001-12-19 2008-11-04 Hewlett-Packard Development Company, L.P. Method and apparatus for supporting multiple independent failure domains
CA2369201A1 (en) * 2002-01-24 2003-07-24 Alcatel Canada Inc. System and method for providing maintenance of fabric links for a network element
US6968417B1 (en) * 2002-03-21 2005-11-22 Advanced Micro Devices, Inc. Method and apparatus for reducing latency in a peripheral interface circuit of an I/O node of a computer system
US8332694B2 (en) * 2002-09-24 2012-12-11 Hewlett-Packard Development Company, L.P. Method for notification of an error in data exchanged between a client and a server
US7720043B2 (en) * 2002-11-20 2010-05-18 Qualcomm Incorporated Use of idle frames for early transmission of negative acknowledgement of frame receipt
KR100548329B1 (ko) 2003-02-20 2006-02-02 엘지전자 주식회사 무선 프로토콜을 위한 프로시쥬어 수행방법
DE10361386B4 (de) * 2003-12-29 2006-02-16 Siemens Ag Verfahren zur Übertragung von digitalen Informationspaketen in einem Datennetz
US7957389B2 (en) * 2004-03-31 2011-06-07 Alcatel-Lucent Usa Inc. Method of stall identification and recovery
JP4576868B2 (ja) 2004-04-14 2010-11-10 富士通株式会社 無線装置、受信方法、移動局
US7747894B2 (en) * 2005-06-06 2010-06-29 Microsoft Corporation Transport-neutral in-order delivery in a distributed system
US7599396B2 (en) * 2005-07-11 2009-10-06 Magnalynx, Inc. Method of encoding and synchronizing a serial interface
US7716536B2 (en) * 2006-06-29 2010-05-11 Intel Corporation Techniques for entering a low-power link state
US7751344B2 (en) * 2006-11-08 2010-07-06 Sicortex, Inc. Computer system and method using a kautz-like digraph to interconnect computer nodes and having control back channel between nodes
US20080107116A1 (en) * 2006-11-08 2008-05-08 Sicortex, Inc. Large scale multi-processor system with a link-level interconnect providing in-order packet delivery
FR2931021A1 (fr) 2008-05-09 2009-11-13 Canon Kk Procede de synchronisation d'un flux de donnees transmis sur un reseau de communication synchrone, produit programme d'ordinateur, moyen de stockage et dispositif recepteur correspondants.
WO2010103602A1 (ja) * 2009-03-09 2010-09-16 富士通株式会社 伝送データのエラーチェック装置および方法
JP5152141B2 (ja) * 2009-10-05 2013-02-27 富士通株式会社 無線装置、受信方法、移動局
US9456470B2 (en) * 2010-12-15 2016-09-27 Qualcomm Incorporated Method and apparatus for prohibiting direct link setup in wireless local area networks (WLAN)
JP2012085244A (ja) * 2010-10-15 2012-04-26 Fujitsu Ltd シリアル伝送装置、情報処理装置、及びシリアル伝送方法
US10326577B2 (en) 2013-08-13 2019-06-18 Qualcomm Incorporated Harq design for LTE in unlicensed spectrum utilizing individual ACK/NACK
JP6287493B2 (ja) * 2014-03-31 2018-03-07 富士通株式会社 情報処理装置、転送装置、および制御方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3069762D1 (en) * 1980-08-26 1985-01-17 Ibm System for the retransmission of incorrectly received numbered frames in a data transmission system
US4422171A (en) * 1980-12-29 1983-12-20 Allied Corporation, Law Department Method and system for data communication
US4601035A (en) * 1983-10-03 1986-07-15 At&T Bell Laboratories Data communication method and circuitry
GB8329510D0 (en) * 1983-11-04 1983-12-07 Inmos Ltd Computer apparatus
CA1220830A (en) * 1984-12-28 1987-04-21 David S. Drynan Transmitting sequence numbers of information in a packet data transmission system
FR2585909B1 (fr) * 1985-08-02 1987-10-09 Lmt Radio Professionelle Procede de transmission de donnees par paquets a travers un reseau ou une chaine de transmission, et dispositif de mise en oeuvre
US4712214A (en) * 1986-01-10 1987-12-08 International Business Machines Corporation Protocol for handling transmission errors over asynchronous communication lines
JPS62186636A (ja) * 1986-02-12 1987-08-15 Fujitsu Ltd 最終情報フレ−ムの誤り回復制御方式
FR2595522A1 (fr) * 1986-03-06 1987-09-11 Cimsa Sintra Procede et dispositif de transmission de donnees numeriques par messages organises en trames
CA1249886A (en) * 1986-05-02 1989-02-07 Claude J. Champagne Method of duplex data transmission using a send-and- wait protocol
US4905234A (en) * 1987-06-03 1990-02-27 General Electric Company Apparatus and method for transmitting digital data over a radio communications channel
JPS6471346A (en) * 1987-09-11 1989-03-16 Nec Corp Data transmission system
US5010553A (en) * 1988-12-05 1991-04-23 Compuquest, Inc. High speed, error-free data transmission system and method
JPH02179146A (ja) * 1988-12-29 1990-07-12 Nec Corp エラーリカバリ制御方式
GB2229896B (en) * 1989-02-24 1993-06-30 Rosemount Inc Technique for acknowledging packets

Also Published As

Publication number Publication date
JPH05503197A (ja) 1993-05-27
GB9026338D0 (en) 1991-01-23
DE69120659D1 (de) 1996-08-08
EP0513232A1 (en) 1992-11-19
EP0513232B1 (en) 1996-07-03
GB2250897A (en) 1992-06-17
DE69120659T2 (de) 1997-01-23
WO1992010893A1 (en) 1992-06-25
US5410536A (en) 1995-04-25

Similar Documents

Publication Publication Date Title
JP2707529B2 (ja) データ通信システム
US5933435A (en) Optimized method of data communication and system employing same
EP0525985B1 (en) High speed duplex data link interface
US4368512A (en) Advanced data link controller having a plurality of multi-bit status registers
US4750165A (en) Method of duplex data transmission using a send-and-wait protocol
US4225919A (en) Advanced data link controller
US4862461A (en) Packet switch network protocol
US5165091A (en) Firmware download from a remote terminal to an optical network terminal in a digital loop carrier system
US6785241B1 (en) Method for pacing buffered data transfers over a network such as fibre channel
US6574770B1 (en) Error-correcting communication method for transmitting data packets in a network communication system
US4346440A (en) Advanced data link controller
US4358825A (en) Control circuitry for data transfer in an advanced data link controller
JPH0656994B2 (ja) チェックポイント・フレーム数低減方法
US6925096B2 (en) Method and apparatus for managing traffic flows
EP0310360B1 (en) Data communication method and apparatus
US5422877A (en) Dual bus switching
JPS60259035A (ja) 通信システム
KR950001520B1 (ko) 공통선 신호방식 메시지전달부의 신호단말 그룹버스 통신 프로토콜
JPH0354909B2 (ja)
JPS60117845A (ja) デ−タ伝送方式
JP2002158734A (ja) 通信方法及び通信装置

Legal Events

Date Code Title Description
LAPS Cancellation because of no payment of annual fees