RFC935 日本語訳
0935 Reliable link layer protocols. J.G. Robinson. January 1985. (Format: TXT=31625 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Robinson
Request for Comments: 935 BBN
January 1985
コメントを求めるワーキンググループJ.ロビンソンの要求をネットワークでつないでください: 935 BBN1985年1月
RELIABLE LINK LAYER PROTOCOLS
信頼できるリンクレイヤプロトコル
Status of This Memo
このメモの状態
This RFC discusses protocols proposed recently in RFCs 914 and 916, and suggests a proposed protocol that could meet the same needs addressed in those memos. The stated need is reliable communication between two programs over a full-duplex, point-to-point communication link, and in particular the RFCs address the need for such communication over an asynchronous link at relatively low speeds. The suggested protocol uses the methods of existing national and international data link layer standards. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCは最近RFCs914と916で提案されたプロトコルについて議論して、同じであるそれらのメモに記述された需要のを満たすことができた提案されたプロトコルを勧めます。 述べられた必要性は全二重の上の2つのプログラムの信頼できるコミュニケーションです、二地点間通信リンク、そして、特に、RFCsが比較的低い速度で非同期なリンクの上のそのようなコミュニケーションの必要性を記述します。 提案されたプロトコルは既存の国家的、そして、国際的なデータ・リンク層規格の方法を使用します。 このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。
Introduction
序論
This RFC is motivated by recent RFCs 914 and 916, which propose new standards for protocols that transfer serial data reliably over asynchronous communication lines. In this note, I summarize widely-used standards that have been in existence for some time that might be appropriate for this environment. I hope that the existing standards will be found to meet the needs the new proposals seek to address.
このRFCは最近のRFCs914と916によって動機づけられています。(RFCsは非同期通信線の上にシリアルデータを確かに移すプロトコルの新しい規格を提案します)。 この注意では、私はこの環境に適切な状態で力があるしばらく現存する広く使用された規格をまとめます。 既存の規格が新規案件が記述しようとする需要を満たすのがわかることを願っています。
In both the US and international standards areas, there are two major categories of serial data communication standards for the link layer. These categories are character-oriented and bit-oriented. The first is the older class; it is standardized in the US standard ANSI X3.28-1976 (which superseded the original version of 1971), and in the ISO standards IS 1745, IS 2111, IS 2628 and IS 2629. Although frequently used in synchronous environments, wherein the name binary synchronous (or bisynch) is used, these standards use the term "basic mode" to describe their procedures. The latter class is standardized in the US standard ADCCP (Advanced Data Communication Control Procedures), ANSI X3.66- 1979, and in the ISO standard HDLC (High-level Data Link Control procedures), in IS 3309, IS 4335 and IS 7809.
米国と世界規格領域の両方に、リンクレイヤのシリアルデータコミュニケーション規格の2つの大範疇があります。 これらのカテゴリは、キャラクタ指向であってビット指向です。 1番目は、より古いクラスです。 それは、ISO規格において米国の標準のANSI X3.28-1976(1971年のオリジナルバージョンに取って代わった)で標準化されて、1745であり、2111であり、2628であり、2629です。 同期環境(名前バイナリー同期と(bisynch)は使用されている)で頻繁に使用されますが、これらの規格は、それらの手順について説明するのに「基本のモード」という用語を使用します。 後者のクラスは、米国の標準のADCCP(高度なData Communication Control Procedures)、ANSI X3.66 1979とISOの標準のHDLC(ハイレベルのData Link Control手順)で標準化されています、中に3309があるということであり、4335であり、7809です。
Other international standards, draft standards and vendor standards follow the ADCCP/HDLC procedures. Among these are SDLC (IBM), X.25 LAPB (CCITT), IEEE 802.2/ISO 8802.2 LLC (LAN Logical Link Control) and ISDN LAPD (CCITT). Many vendors have built equipment which meets
他の世界規格、草稿規格、および業者規格はADCCP/HDLC手順に従います。 このうち、SDLC(IBM)、X.25 LAPB(CCITT)、IEEE802.2/ISO8802.2LLC(LAN Logical Link Control)、およびISDN LAPD(CCITT)があります。 多くの業者が満たされる設備を造りました。
Robinson [Page 1]
ロビンソン[1ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
the character-oriented standards, in both synchronous and asynchronous environments, including all the major US mainframe manufacturers.
すべての主要な米国のメインフレームメーカーを含む同時の、そして、非同期の両方環境におけるキャラクタ指向の規格。
The only other serial link layer protocol known to the author in as wide use as these is DEC's DDCMP (Digital Data Communications Message Protocol). This protocol uses a character count instead of framing characters, but is in other respects a character-oriented protocol.
作者にとってこれらと同じくらい広い使用で知られている他の唯一の連続のリンクレイヤプロトコルが12月のDDCMP(デジタルData Communications Messageプロトコル)です。 このプロトコルは、キャラクタを罪に陥れることの代わりにキャラクタカウントを使用しますが、その他の点ではキャラクタ指向のプロトコルです。
The next sections of this note will compare the three protocols above on several bases, paying particular attention to the characteristics that make particular aspects of the protocol appropriate to the low-speed, asynchronous, serial environment.
この注意の次のセクションはいくつかのベースの上の3つのプロトコルを比較するでしょう、プロトコルの特定の局面を低速で、非同期で、連続の環境に適切にする特性に関する特別の注意を向けて。
Frame Structure
枠組構造
All serial protocols divide the data to be transmitted into units known as frames. A frame is typically one to several hundred characters in length. The frame structure is the major difference used above to divide the protocols into three classes.
すべての連続のプロトコルが、フレームとして知られているユニットに伝えられるためにデータを分割します。 通常、フレームは長さにおける数100のキャラクタへの1です。 枠組構造はプロトコルを3つのクラスに分割するのに上で使用された主要な違いです。
Character-Oriented Framing
キャラクター指向の縁どり
Character-oriented protocols use two techniques for defining a frame. First, it is necessary to determine where characters start and stop. The technique used for this purpose is to transmit a number of unique characters prior to the start of a frame. The character generally used for this is the SYN character.
キャラクター指向のプロトコルは、フレームを定義するのに2つのテクニックを使用します。 まず最初に、キャラクタがどこに出発して、止まるかを決定するのが必要です。 このために使用されるテクニックはフレームの始まりの前に多くのユニークなキャラクタを伝えることです。 一般に、これに使用されるキャラクタはSYNキャラクタです。
Note that this is not required when using asynchronous transmission. Since each character is itself framed by start and stop bits, there is never a question of where characters begin and end.
非同期伝送を使用するとき、これは必要でないことに注意してください。 各キャラクタが始めとストップビットによって罪に陥れられるので、キャラクタが始まって、終わるところに関する質問が決してありません。
The main technique for structuring a frame is the use of special framing characters to delineate the start and end of a frame, and to delineate portions of the frame (such as header and text). Some uses of character-oriented protocols require that these characters never appear in the header or text of the frame, while others allow "transparent" transmission. Transparency is obtained by preceding each framing character by a unique control character, typically DLE. In this way, all characters may be sent as header or text, except for DLE. In order to allow DLE to be sent in the header or text, the DLE is doubled.
フレームを構造化するための主なテクニックはフレームの始めと端を図で表わして、フレーム(ヘッダーやテキストなどの)の一部を図で表わす特別な縁どりキャラクタの使用です。 キャラクタ指向のプロトコルのいくつかの用途が、これらのキャラクタがフレームのヘッダーかテキストに決して載っていないのを必要とします、他のものは「透明な」トランスミッションを許しますが。 ユニークな制御文字、通常DLEでそれぞれの縁どりキャラクタに先行することによって、透明を得ます。 このように、DLEを除いて、ヘッダーかテキストとしてすべてのキャラクタを送るかもしれません。 DLEがヘッダーかテキストで送られるのを許容するために、DLEは倍にされます。
Robinson [Page 2]
ロビンソン[2ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
Bit-Oriented Framing
ビット指向の縁どり
Bit-oriented protocols also use a unique character (technically, it is just an arbitrary bit-string) for frame delineation, which is the FLAG. This character provides frame synchronization. All bits between two occurrences of FLAGs constitute a frame. The FLAG is a 0 bit, followed by six 1 bits, followed by another 0 bit. In order that the FLAG character not appear mistakenly in the data of the message, the sender inserts (and the receiver removes) an extra 0 bit after any five successive 1 bits in the data stream.
また、ビット指向プロトコルはフレーム輪郭描写に、ユニークなキャラクタ(それはただ技術的に、任意のビット列である)を使用します。(それは、FLAGです)。 このキャラクタはフレーム同期化を提供します。 FLAGsの2回の発生の間のすべてのビットがフレームを設立します。 FLAGは6が1ビットいうことになった0ビットですもう0ビットがいうことになった。 FLAGキャラクタがメッセージに関するデータに誤って現れないように、送付者は余分な0ビットどんな5時以降も、連続した1ビットをデータ・ストリームに挿入します(受信機は取り外されます)。
Because this insertion of bits ("stuffing") results in arbitrary
frame bit-lengths, bit-oriented protocols are generally useful only
in synchronous transmission environments. Although it has never been
attempted, however, one could imagine an asynchronous environment
where each FLAG character that appears in the data is translated into
a two- character sequence that avoids FLAGs, and at least one other
character is similarly translated. For example, one could frame data
with FLAGS, and send DLE-F to mean FLAG and DLE-DLE to mean DLE when
these characters occur within the frame.
ビット(「詰める」)のこの挿入が任意のフレームのビット-長さをもたらすので、一般に、ビット指向プロトコルは同期転送環境だけで役に立ちます。 それは一度も試みられたことがありませんでしたが、しかしながら、人はデータに現れるそれぞれのFLAGキャラクタがFLAGsを避ける2キャラクタシーケンスに翻訳されて、他の少なくとも1つのキャラクタが同様に翻訳される非同期な環境を想像できました。 例えば、これらのキャラクタがフレームの中に起こると、1つは、FLAGSと共にデータを縁どっていて、DLEを意味するためにFLAGを意味するDLE-FとDLE-DLEを送るかもしれません。
Note that bit-oriented procedures do not require that the number of bits between FLAGs be an exact number of 8-bit characters, in distinction to character-oriented protocols and DDCMP. The necessity for character-alignment may be imposed at higher layers, as it is, for example, in X.25 Network Layer.
ビット指向の手順が、キャラクタ指向のプロトコルとDDCMPへの区別でFLAGsの間のビットの数がはっきりした数の8ビットのキャラクタであることを必要としないことに注意してください。 例えば、字並びの必要性は現状通りX.25 Network Layerで、より高い層で課されるかもしれません。
Frame Structure in DDCMP
DDCMPの枠組構造
DDCMP uses a third approach to frame structure. Like character-oriented protocols, it uses a SYN character to achieve character synchronization prior to starting a frame, but one cannot dispense with this over asynchronous lines (see below). Contained within the fixed-length header portion of the frame is a count field, which reports how many characters are contained in the variable-length text portion. Since no framing characters are required at all, transparency is not a problem. However, because the count must be received properly for the sender and receiver to stay in frame synchronization, the header is protected with a separate error control checksum, which is typically two characters long (see below). Also, once a header error has been detected, the count field must be assumed to be invalid, and so there must be a unique character sequence that introduces the next header in order that the receiver can regain synchronization with the sender.
DDCMPは枠組構造への3番目のアプローチを使用します。 キャラクタ指向のプロトコルのように、フレームを始動する前に文字同期を達成するのにSYNキャラクタを使用しますが、1つは非同期な線でこれを省くことができません(以下を見てください)。 フレームの固定長ヘッダー部分の中に含まれているのは、カウント分野(何人のキャラクタが可変長のテキスト部分に含まれていると報告する)です。 縁どりキャラクタは全く必要でないので、透明は問題ではありません。 しかしながら、送付者と受信機が船体の骨組を組み立て終えて同期するのに引きとめられるために適切にカウントを受けなければならないので、ヘッダーは別々の誤り制御チェックサムで保護されます(以下を見てください)。(通常、長い間、それは、2つのキャラクタです)。 また、ヘッダー誤りがいったん検出されると、無効であるとカウント分野を思わなければならないので、そして、受信機が送付者との同期を取り戻すことができるように次のヘッダーを紹介するユニークなキャラクタシーケンスがあるに違いありません。
Therefore, the SYN characters preceding a frame are required even on asynch lines.
したがって、フレームに先行するSYNキャラクタがasynch線の上でさえ必要です。
Robinson [Page 3]
ロビンソン[3ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
Error Detection
誤り検出
Several types of error control may be used, and the various protocols above are similar. Most synchronous uses require a cyclic redundancy check sequence be attached to each frame. This is a 16-bit sequence which can be easily generated and checked in hardware using a shift register, and can be somewhat more tediously done in software with about 5-6 instructions per character sent or received, and a 256 by 16-bit lookup table. DDCMP and Bit-oriented protocols all require use of such a sequence. As noted above, DDCMP uses a check sequence twice, once for the header and once for the data.
いくつかのタイプの誤り制御は使用されるかもしれません、そして、上の様々なプロトコルは同様です。 最も同期の用途は周期冗長検査系列を必要とします。各フレームに付けられています。 これは退屈の間にいくらか容易に発生できて、シフトレジスタを使用することでハードウェアを預けて、およそ5-6があるソフトウェアで送るか、または受け取るキャラクタ単位で指示して、16ビットのルックアップ表で256が、よりできる16ビットの系列です。 DDCMPとBit指向のプロトコルはすべて、そのような系列の使用を必要とします。 上で述べたように、ヘッダーのための一度、データのためにいったんDDCMPは二度チェック系列を使用します。
In some environments, weaker checks are used on character-oriented links. These take two forms. If the the number of significant bits per character is only 7, then the parity bit can be set to achieve either odd or even parity. ANSI standard X3.16-1976 specifies that odd parity should be used on synchronous links and even parity on asynchronous links. The second type of check is "longitudinal parity", wherein one character is added to the frame so that the number of 1 bits in each bit position summed over all the characters of the message and the check character is even. In other words, the exclusive-or of all the characters is 0. Character parity and longitudinal parity may be used together.
いくつかの環境で、より弱いチェックはキャラクタ指向のリンクの上に使用されます。 これらは2つの形を取ります。1キャラクタあたりの重要なビットの数が7にすぎないなら、パリティビットが変であるか同等の同等を達成するように設定できます。 ANSI規格X3.16-1976は、奇数パリティが非同期なリンクの上に同期リンクと同等でさえ使用されるべきであると指定します。 各ビット位置のビットがメッセージとチェックキャラクタのすべてのキャラクタの上にまとめた1の数は、2番目のタイプのチェックが「縦の同等」であるので、偶数です。(1つのキャラクタがそれでフレームに加えられます)。 言い換えれば、すべてのキャラクタの排他的論理和は0です。 キャラクターの同等と縦の同等は一緒に使用されるかもしれません。
Note also that most character-oriented control messages, such as those that poll, select, and acknowledge, are sent with only parity for error control.
また、ほとんどのキャラクタ指向のコントロールメッセージが誤り制御のために同等だけと共にそれが投票して、選択して、承認するものなどのように送られることに注意してください。
Sequence Control
シーケンス制御
All these protocol provide reliable transmission by sequencing the frames and providing positive and (in some cases) negative acknowledgments. Senders can ask the receiver for status if a reply is late.
これらが議定書の中で述べるすべてがフレームを配列して、提供することによって積極的な信頼できるトランスミッションと(いくつかの場合)否定応答を提供します。 Sendersは、回答が遅れているかどうか状態への受信機に尋ねることができます。
In character-oriented protocols, frames are implicitly numbered (typically) and only one may be outstanding at a time. Acknowledgments are explicitly numbered. One variant allows each block (frame) to be explicitly numbered as well; in this case up to 7 may be outstanding.
キャラクタ指向のプロトコルでは、それとなくフレームに付番します、そして、(通常)だけ一度に、傑出しているかもしれません。 承認は明らかに付番されます。 1つの異形が、各ブロック(フレーム)が明らかにまた、付番されるのを許容します。 この場合、最大7は傑出しているかもしれません。
In bit-oriented protocols, frames are explicitly numbered and up to 7 may be outstanding at a time. Optional control field extension allows for up to 127 outstanding. An alternate procedure that has been defined for use both in the ISDN LAPD environment and in IEEE
ビット指向プロトコルでは、明らかにフレームに付番します、そして、最大7は一度に、傑出しているかもしれません。 拡大が未払いの127まで許容する随意コントロール分野。 ISDN LAPD環境とIEEEにおける使用のために定義された代替手順
Robinson [Page 4]
ロビンソン[4ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
802 LAN environments uses, in effect, a one-bit sequence number and one outstanding frame. Also, unsequenced, unacknowledged information frames can be used when frames need not be sent reliably.
事実上、802のLAN環境用途、1ビットの一連番号、および1個の傑出しているフレーム。 また、フレームを確かに送る必要はないとき、非配列されて、不承認の情報フレームを使用できます。
In DDCMP, the frames are explicitly numbered and up to 255 may be outstanding.
DDCMPでは、フレームは明らかに付番されます、そして、最大255は傑出しているかもしれません。
Addressing
アドレシング
All of these protocols allow for addressing stations on a multipoint link separately. In LAN environments, both a sending and receiving address are required, whereas multipoint environments use a single address and assume one master station communicating with multiple addressed slave stations. In bit-oriented protocols, the address provides extra information in that frames can be categorized as commands or responses; in this sense, the address provides another control bit per frame. However, it is possible to operate without needing this distinction.
これらのプロトコルのすべてが、別々に多点リンクの上のステーションに演説すると考慮します。 LAN環境では、送付と受信アドレスの両方が必要です、多点環境は、ただ一つのアドレスを使用して、複数の記述された従局とコミュニケートする1つの主局を仮定しますが。 ビット指向プロトコルに、アドレスはコマンドか応答としてフレームを分類できるので、その他の情報を提供します。 この意味で、アドレスは1フレームあたりもう1コントロールビット提供します。 しかしながら、この区別を必要としないで作動するのは可能です。
Addresses are typically one character long; bit-oriented protocols allow for extension of this field to arbitrary length. Character-oriented protocols use two-character (controller and terminal) addresses.
長い間、通常、アドレスは1つのキャラクタです。 ビット指向プロトコルはこの分野の拡大を任意の長さまで考慮します。 キャラクター指向のプロトコルは2キャラクタ(コントローラと端末)のアドレスを使用します。
For point-point operation, the address is clearly superfluous (except to distinguish commands and replies in bit-oriented protocols); one might imagine dispensing with it.
ポイント-ポイント操作において、アドレスは明確に余計です(ビット指向プロトコルにおけるコマンドと回答を区別するのを除いて)。 人は、それを省くと想像するかもしれません。
The Asynchronous Environment
非同期な環境
Which of these protocols is best for the asynchronous environment? This depends on the definition of "best", of course. One means of judging is to compare the amount of overhead that each protocol would add to each frame sent.
非同期な環境に、これらのプロトコルのどれが最も良いですか? これが「最善」の定義による、もちろん。 判断する1つの手段は各プロトコルが送られた各フレームに加えるオーバーヘッドの量を比較することです。
We will examine the overhead costs in two groups:
私たちは2つのグループで間接費を調べるつもりです:
framing/transparency/error checking,
縁どり/透明/誤りの照合
and addressing/control.
そして、アドレシング/コントロール。
The two groups of functions are independent of each other, even though the protocols mentioned above use specific combinations of techniques from these two groups. Also, hardware available on minicomputer-class and larger machines today supports the first group of functions completely for these standard protocols; this fact should allow for far greater performance from the gateway machine.
機能の2つのグループが互いから独立しています、前記のようにプロトコルはこれらの2つのグループからテクニックの特定の組み合わせを使用しますが。 また、今日のミニコンピュータクラスと、より大きいマシンで利用可能なハードウェアは完全にこれらの標準プロトコルのために機能の最初のグループを支持します。 この事実はゲートウェイマシンからはるかに大きい性能を考慮するべきです。
Robinson [Page 5]
ロビンソン[5ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
To the extent that such hardware becomes available for personal computers, it can also be used there to reduce the protocol processing overhead. Here's a breakdown of framing costs in characters. RATP is also included for comparison.
また、そのようなハードウェアがパーソナルコンピュータに利用可能になるという範囲まで、プロトコル処理オーバヘッドを下げるのにそこでそれを使用できます。 ここに、キャラクタの縁どりコストの故障があります。 また、RATPは比較のために含まれています。
Protocol Frame Check Transp. Total F+C
フレームチェックTranspについて議定書の中で述べてください。 合計F+C
char-or. 4 2 2 8 6
bit-or. 1 2 2 5 3
DDCMP 4 4 0 8 8
RATP 2 3 0 5 5
または炭、-。 または4 2 2 8 6、ビット、-。 1 2 2 5 3DDCMP4 4 0 8 8RATP2 3 0 5 5
The transparency column indicates the anticipated cost in inserted characters to achieve transparency across a 256-byte frame. The figure for bit-oriented protocols is a pessimistic guess, because I don't know the exact answer; it is between 0 and 8 characters, with the worst case occurring when the data is all one bits. For character-oriented protocols, we would expect on average one DLE character in a 256-byte frame; the worst case overhead (256 DLEs) is 256 bytes.
透明コラムは、256バイトのフレームの向こう側に透明を達成するために挿入されたキャラクタの見込み原価を示します。 私が正確な答えを知らないので、ビット指向プロトコルのための図は悲観的な推測です。 それはデータがすべて1ビットであるときに、最悪の場合が起こっている0〜8つのキャラクタです。 キャラクタ指向のプロトコルのために、私たちは256バイトのフレームで1DLEのキャラクタを平均的に予想するでしょう。 最悪の場合オーバーヘッド(256DLEs)は256バイトです。
Because transparency is so much a function of the user data, and because we have ignored the cost of loss of frame synchronization in the counting protocols (DDCMP and RATP), I argue that we should base the comparison on the frame and checksum costs only. For these two columns, character-oriented framing costs one more character per frame than RATP. This, plus its wide use and hardware chip support, create a strong case for its use in preference to RATP for framing.
透明が利用者データのとても多くの機能であり、私たちが勘定プロトコル(DDCMPとRATP)における、フレーム同期化の損失の費用を無視したので、私たちの比較がフレームとチェックサムコストだけに基づいているべきであると主張します。 これらの2つのコラムに関しては、キャラクタ指向の縁どりはRATPよりもうひとつの1フレームあたりのキャラクタかかります。 そのこれ、広い使用、およびハードウェアチップサポートはRATPに優先した縁どりの使用のために強いケースを引き起こします。
Bit-oriented framing, as noted previously, is appropriate only on synchronous links. The character oriented variant I postulated above would have the same costs, but as it is not a standard, it is not proposed here. So we now have constructed the following frame format:
以前に注意されるビット指向の縁どりは同期リンクだけで適切です。 私が上で仮定したキャラクタ指向の異形は同じコストを持っているでしょうが、規格でないので、それはここで提案されません。 それで、私たちは現在、以下のフレーム形式を構成しました:
DLE STX <control and data ...> DLE ETX CRC CRC
DLE STX<コントロールとデータ…>DLE ETX CRC CRC
One objection to using character-oriented protocols as opposed to character-count protocols is that it is necessary to examine every character as it arrives. I respond to this objection as follows:
キャラクタカウントプロトコルと対照的にキャラクタ指向のプロトコルを使用することへの1つの異論は到着するときすべてのキャラクタを調べるのが必要であるということです。 私は以下のこの異論に応じます:
1. Under some circumstances, such as when a header has been hit
with an error, it will be necessary for the receiver to look at
every character anyway.
1. ヘッダーが誤りで打たれた時などのいくつかの状況で、受信機がとにかくすべてのキャラクタを見るのが必要でしょう。
2. The environment for this protocol is a 1200 baud link; thus
2. このプロトコルのための環境は1200年のボーリンクです。 このようにして
Robinson [Page 6]
ロビンソン[6ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
120 characters per second need to be examined at a maximum. Even
on a relatively slow personal computer, this should not present a
problem.
1秒あたり120のキャラクタが、最大で調べられる必要があります。 比較的遅いパーソナルコンピュータの上にさえ、これは問題を提示するべきではありません。
We now turn our attention to the content and format of the control information preceding each link frame. There are three components to this cost, control, address, and acknowledgment. The address field allows multipoint configurations and is superfluous for the point-to-point environment proposed, but it is present in the public standards and we restrict ourselves to those.
私たちは現在、それぞれのリンクフレームに先行する制御情報の内容と形式に関する興味を寄せます。 この費用、コントロール、アドレス、および承認への3つのコンポーネントがあります。 それは公共の規格で存在しています、そして、アドレス・フィールドは、多点構成を許して、提案された二地点間環境に、余計ですが、私たちは自分達をそれらに制限します。
Acknowledgments are shown if they are required explicitly by the protocol. A "0" indicates that the acknowledgments may be included in the control information for traffic in the opposite direction, and only need be sent explicitly when no reverse traffic is present (and thus are assumed to take no required overhead). Only character-oriented protocols have required acknowledgments.
承認はそれらがプロトコルによって明らかに必要とされるかどうかが示されます。 「0インチを承認が逆方向の交通のための制御情報に含まれるかもしれないのを示して、どんな逆の交通も存在していないとき(そして、その結果、どんな必要なオーバーヘッドも取らないと思われます)、明らかに送るだけでよいです。」 キャラクタ指向のプロトコルだけが承認を必要としました。
Cont. Addr. Ack Total
char-or. 0 3 2 5
bit-or. 1 1 0 2
DDCMP 3 1 0 4
RATP 1 0 0 1
Cont。 Addr。 またはAck Total、炭、-。 または0 3 2 5、ビット、-。 1 1 0 2DDCMP3 1 0 4RATP1 0 0 1
Again, the bit-oriented procedures provide the lowest overhead among the public standards, but in this case there is no conflict in using them in the asynchronous environment. In fact, even if all the other aspects of RATP were to be adopted, I believe the control field codings of the bit- oriented procedures represent a more efficient use of the channel, are widely implemented, and allow for addition of more functions later if desired. As stated above, there are several protocols in the bit-oriented family. I would recommend use of LAPB, since this is the most widely known of the family.
一方、ビット指向の手順は最も低いオーバーヘッドを公共の規格に提供しますが、この場合、非同期な環境でそれらを使用するのにおいて闘争が全くありません。 事実上、RATPの他のすべての局面が採用されることであったなら、望まれているなら、私は、後で噛み付いている指向の手順の制御フィールドコーディングがチャンネルの、より効率的な使用を表すと信じて、広く実行されて、より多くの機能の添加を考慮します。 上に述べられているように、ビット指向の家族にはいくつかのプロトコルがあります。 これは最も広く家族を知られているので、私はLAPBの使用を推薦するでしょう。
For those not familiar with bit-oriented control procedures, I have included a quick summary of these procedures in Appendix A. Refer to the standards listed at the end of this note for more detail.
ビット指向のコントロール手順になじみ深くないそれらに関しては、私はその他の詳細のためのこの注意の終わりに記載された規格へのこれらの手順のAppendix A.Referの短い概要を入れました。
Robinson [Page 7]
ロビンソン[7ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
RATP Compared to Public Protocols
公共のプロトコルと比較されたRATP
As can be seen from the above tables, RATP does not represent a significant savings compared to other widely-used protocols.
上のテーブルから見ることができるように、他の広く使用されたプロトコルと比べて、RATPは重要な貯蓄を表しません。
Given frame lengths of 13 bytes, which appears to be the minimum for Thinwire II (RFC 914), 8 characters' overhead using the public standards represents 61% versus 46% for RATP's 6 characters. On a 1200 baud line, the bandwidth available assuming only such short frames is thus 74 versus 82 characters per second, respectively. Since 1/13 of these are actually user data, the typing rates supported by these protocols using TCP/IP are pretty low, like 5.6 versus 6.3 characters per second. Clearly a bigger cost is still found in the 12 characters overhead in Thinwire II (or 40 for TCP/IP with no compression).
Thinwire II(RFC914)のための最小限、8つのキャラクタのオーバーヘッドであるように見える13バイトのフレームの長さを考えて、公共の規格を使用すると、61%はRATPの6つのキャラクタのために46%に対して表されます。 1200年のボー線の上では、その結果、そのような短いフレームだけを仮定する利用可能な帯域幅は74対それぞれ1秒あたり82のキャラクタです。 これらの1/13が実際に利用者データであるので、これらのプロトコルによってTCP/IPを使用することで支持されたタイプレートはかなり低いです、5.6対1秒あたり6.3のキャラクタのように。 明確に、より大きい費用はThinwire II(または、圧縮のないTCP/IPのための40)で頭上の12のキャラクタでまだ見つけられています。
The costs improve dramatically when the number of user characters per frame increases. Thus, file transfer, or even line-blocked typing, should perform adequately. As frame size grows, the cost of the extra 2 characters per frame to use standard protocols rapidly drops to a few percent or less.
1フレームあたりのユーザキャラクタの数が増加すると、コストは劇的に向上します。 したがって、ファイル転送、または線で妨げられたタイプさえ適切に働くべきです。 フレーム・サイズが成長するのに従って、余分な急速に標準プロトコルを使用するフレームあたり2つのキャラクタの費用は数パーセントか以下まで下がります。
RATP does allow one optimization which cannot be achieved in the standard protocols - the use of a one-character format that reduces the per-frame overhead to 3 characters (or 4 if a 16-bit CRC is used). However, in the scenario wherein single-character messages make sense, a user typing characters (with no higher layer protocols), the extra overhead is probably not a problem since the link is still lightly enough loaded that the extra overhead is still a small percentage of the available bandwidth. Also, allowing multiple frames in flight helps reduce the bottleneck caused by having one frame at a time outstanding.
RATPは標準プロトコルで達成できない1つの最適化を許容します--1フレームあたりのオーバーヘッドを3つのキャラクタ(4は16ビットのCRCであるなら使用されている)まで下げる1キャラクタの形式の使用。 単独のキャラクタメッセージが理解できるシナリオ、文字(より高い層のプロトコルのない)をタイプしているユーザの余分なオーバーヘッドがどのようにリンクがまだ軽く十分であるのでたぶんどんな問題もそれをロードしなかったということであっても、それでも、余分なオーバーヘッドは利用可能な帯域幅のわずかな百分率です。 また、飛行で複数のフレームを許容するのは、未払いの時に1個のフレームを持っていることによって引き起こされたボトルネックを減少させるのを助けます。
On Check Sequences
チェック系列に関して
Both RFCs 914 and 916 propose to use relatively simple check sequences, which can be easily computed in a general-purpose processor. In one case, this is an additive check and in the other it is an exclusive-or (or parity) check. Although the additive check is slightly more powerful than the exclusive-or, both are relatively weak compared to CRC techniques.
両方のRFCs914と916は、比較的簡単なチェック系列を使用するよう提案します。(容易に、メインプロセッサで系列を計算できます)。 ある場合では、これは付加的なチェックです、そして、もう片方では、それは排他的論理和(または、同等)チェックです。 付加的なチェックは排他的論理和よりわずかに強力ですが、CRCのテクニックと比べて、両方が比較的弱いです。
Since the intended network-layer protocol (IP) provides for similar checks on its header, and the transport layer (TCP) checksums its header and data, one might question whether the protection should also be provided at the link layer at all, or if it should, then are these checks good enough? Providing for recovery at the TCP layer
そして、また、全くリンクレイヤで保護を提供するべきであるか、または提供するなら(IP)がヘッダーの同様のチェック、およびヘッダーとデータ、ものが質問するかもしれないトランスポート層(TCP)チェックサムに提供する意図しているネットワーク層プロトコル以来、十分良いこれらのチェックはそうですか? TCP層に回復に備えます。
Robinson [Page 8]
ロビンソン[8ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
leads to slow recovery times, so this approach will probably yield too poor a level of service for noisy links. More importantly, the link layer control field needs a certain degree of protection to prevent needless loss or duplication of frames in the face of line errors.
回復回を遅くする先導であり、したがって、このアプローチはたぶん騒がしいリンクのための貧し過ぎるレベルのサービスをもたらすでしょう。 より重要に、リンクレイヤ制御フィールドは、線誤りに直面してフレームの不必要な損失か複製を防ぐためにある度の保護を必要とします。
A CRC check, in combination with the additive checks provided by IP and TCP, yield an error-protection that is greater than that afforded by either check by itself. This is because the two techniques address fundamentally different characteristics of the possible errors. The degree of increase is substantial compared to that of two additive checks. That is, if two additive checks are cascaded, there are many types of two-bit failures that will pass both the link layer and TCP/IP checking.
付加的なチェックと組み合わせたCRCチェックがIPとTCPによって提供されて、どちらのチェックでもそれ自体で都合されたそれより大きい誤り保護をもたらしてください。 これは2つのテクニックが可能な誤りの基本的に異なった特性を記述するからです。 2つの付加的なチェックのものと比べて、増加の度合いは実質的です。 すなわち、2つの付加的なチェックがどっと落しているなら、リンクレイヤとTCP/IPの照合を両方に渡す多くのタイプの安っぽい失敗があります。
Although I don't wish to include a detailed error analysis in this note, I would support the use of a CRC type of error check because of the far greater level of protection it affords. As I pointed out, the cost per character is roughly 5-6 instructions, assuming the use of a 256 by 16-bit lookup table. Again, at 120 characters per second, the increased cost is not deemed to be too great.
この注意に詳細なエラー解析を含みたいと思いませんが、私はそれが提供するはるかに大きいレベルの保護によるエラーチェックのCRCタイプの使用を支持するでしょう。 私が指摘したように、1キャラクタあたりの費用はおよそ5-6の指示です、16ビットのルックアップ表で256の使用を仮定して。 一方、1秒あたり120のキャラクタでは、コストの上昇がすばらし過ぎると考えられません。
Moreover, use of a standard CRC allows for the possibility that the serial line chip's own CRC generation and checking hardware may be used. Although such chips may not be present in the PCs in the environment envisioned, they are likely to be available in the gateway machine to which the PCs talk.
そのうえ、標準のCRCの使用はシリアル・ラインチップの自身のCRC世代とハードウェアをチェックするのが費やされるかもしれない可能性を考慮します。 そのようなチップは思い描かれた環境におけるPCに存在していないかもしれませんが、それらはPCが話すゲートウェイマシンで利用可能である傾向があります。
Data Compression: An Aside
データ圧縮: 余談
I find the proposed methods of data compression of RFC 914 particularly interesting. I see these as independent of the choice of the underlying link layer protocol, as it is in RFC 914. I am aware of no such character-oriented compression that is in common use in the communication world. The only techniques that come close are in statistical multiplexing devices, which sometimes also include an adaptive Huffman-coding to reduce link bandwidth. Since the Thinwire II approach can recognize much longer repeated sequences than a Huffman code, I expect that the potential savings are correspondingly greater.
私は、RFC914のデータ圧縮の提案された方法が特におもしろいのがわかりました。 私は、それがRFC914にあって基本的さの選択の独立者としてのこれらが層のプロトコルをリンクするのを見ます。 私はどんなそのようなコミュニケーション世界で共用のキャラクタ指向の圧縮も意識していません。 近接する唯一のテクニックが統計的多重化装置にあります。(また、装置は、リンク帯域幅を減少させるために時々適応型のハフマン-コード化を含んでいます)。 Thinwire IIアプローチがハフマン符号よりはるかに長い反復配列を認識できるので、私は、潜在的貯蓄に対応するよりすばらしいと予想します。
I would like to see a version of the Thinwire protocols which allows for the template idea, but which keeps it independent of the higher layer protocols in use. One way to achieve this is to allow templates to be encoded and exchanged between the communicating parties when they start up, and perhaps adaptively as conditions warrant. I would anticipate that this sort of approach might well
テンプレート考えを考慮しますが、それが使用中の、より高い層のプロトコルの独立者であることを保つThinwireプロトコルのバージョンを見たいと思います。 これを達成する1つの方法は彼らが始動して、状態が保証するように恐らく適応型であるときに、テンプレートが交信パーティーの間でコード化されて、交換されるのを許容することです。 私は、この種類のアプローチがたぶんそうするだろうと予期するでしょう。
Robinson [Page 9]
ロビンソン[9ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
have widespread applicability beyond the TCP/IP environment addressed in RFC 914. The most important gain for this environment is removal of the apparent exorbitant overhead that IP and TCP seem to present for use over slow links.
RFC914に記述されたTCP/IP環境を超えて広範囲の適用性を持ってください。 この環境のための最も重要な利得はIPとTCPが遅いリンクの上の使用のために提示するように思える見かけの法外なオーバーヘッドの取り外しです。
Summary
概要
The link layer protocol I would advocate for asynchronous, dialup communication between PCs would use transparent, character-oriented framing, a 16-bit CRC error check, and the control procedures of LAPB. The CRC should be either CRC-16 or the CCITT CRC used in X.25, with the latter probably being preferred; modern link chips tend to support both of these if they support either.
私がPCの非同期なダイアルアップコミュニケーションのために支持するリンクレイヤプロトコルはLAPBの透明で、キャラクタ指向の縁どり、16ビットのCRCエラーチェック、およびコントロール手順を用いるでしょう。 CRCはX.25でたぶん好まれる後者で使用されるCRC-16かCCITT CRCのどちらかであるべきです。 どちらかを支持するなら、近代的なリンクチップは、これらの両方を支持する傾向があります。
Evolution of integrated circuits that directly implement all of the public standards will dramatically drop the cost and raise the reliability of new implementations of standard protocols. Chip manufacturers have little motivation to address standards that are not widely used.
直接公共の規格のすべてを実行する集積回路の発展は、費用を劇的に落として、標準プロトコルの新しい実現の信頼性を上げるでしょう。 チップメーカーには、広く使用されない規格を記述する動機がほとんどありません。
Overhead for the suggested protocol is 8 characters per frame. Up to 7 frames may be outstanding at a time in either direction of transfer. Choice of an appropriate maximum frame size is application-dependent, and would certainly be influenced by the quality of the physical connection; however, I believe that IP datagrams are acceptable frames for dialup 1200 baud service.
1フレームあたり提案されたプロトコルのためのオーバーヘッドは8つのキャラクタです。 最大7個のフレームが一度に、転送のどちらかの方向に傑出しているかもしれません。 適切な最大のフレーム・サイズの選択は、アプリケーション依存していて、確かに、物理接続の品質によって影響を及ぼされるでしょう。 しかしながら、私は、IPデータグラムがダイアルアップ1200ボーサービスのための許容できるフレームであると信じています。
Non-standard modifications that would save a little link overhead would be to dispense with the one-character address field, and to use the RATP count-oriented frame structure. These are not recommended, because they depart from common practice and yield modest improvements at best.
少しのリンクオーバーヘッドを節約する標準的でない変更は、1キャラクタ・アドレスの分野を省いて、RATPのカウント指向の枠組構造を使用するだろうことです。 彼らが一般的な習慣から出発して、せいぜい穏やかな改良をもたらすので、これらは推薦されません。
Postscript
追伸
Those familiar with the early history of the Telenet Public Data Network should recognize that this proposal is essentially the same as the original link layer protocol specification for that network, circa 1976, except that the control procedures used at that time, known as LAP, have now been superseded by the more powerful and efficient LAPB, and their access links, as all X.25 access links, are synchronous rather than asynchronous. I did not set out to achieve this result, but just note it in passing.
テレネットPublic Data Networkの早めの歴史に詳しいものは、この提案がそのネットワークにおいて当初のリンクレイヤプロトコル仕様と本質的には同じであると認めるはずです、1976年頃に、その時用いられたLAPとして知られているコントロール手順が現在、より強力で効率的なLAPBによって取って代わられて、すべてのX.25アクセスがリンクされるとき非同期であるというよりむしろそれらのアクセスリンクが同時であるのを除いて。 私は、この結果を獲得しますが、通過でそれにただ注意し始めませんでした。
My personal view of where the world of personal computer access to data networks is heading is that X.25 will rapidly become the protocol of choice. One already sees third-party (for IBM PC) and
データ網へのパーソナルコンピュータアクセスの世界が向かっているところに関する私の個人的な意見はX.25が急速に選択のプロトコルになるということです。 そして人が既に、第三者(IBM PCのための)を見る。
Robinson [Page 10]
ロビンソン[10ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
vendor (for Wang PC) implementations of X.25. CCITT is circulating a proposal for accessing an X.25 data network using a dial-up X.25 connection, as recommendation X.32. Thus, I feel that the type of communication proposed in this RFC and RFCs 914 and 916 will be used for a relatively short period of time. The future holds, I believe, LAN or X.25/X.32 data link layer and access, X.25 and/or ISO IP network layer, and TCP and/or ISO TP4 transport layer.
X.25のベンダー(ワングPCのための)実装。 CCITTは推薦X.32としてダイヤルアップX.25接続を使用することでX.25データ網にアクセスするための提案を循環させています。 したがって、私は、このRFCとRFCs914と916で提案されたコミュニケーションのタイプが比較的短い期間の間使用されると感じます。 未来は成立します、と私が信じて、LANかX.25/X.32データ・リンク層とアクセス、X.25、そして/または、ISO IPネットワーク層と、TCP、ISO TP4輸送が層にされます。
References
参照
RFC 914, "Thinwire Protocol", Farber, Delp and Conte, 1984.
RFC914と「Thinwireプロトコル」とファーバーとデルプとコンテ、1984。
RFC 916, "Reliable Asynchronous Transfer Protocol", Finn, 1984.
RFC916、「信頼できる非同期な転送プロトコル」、フィンランド人、1984。
"Technical Aspects of Data Communication", McNamara, Digital Press, 1977.
「データ通信の技術的側面」、マクナマラ、デジタルプレス、1977。
ANSI X3.4-1968, "American National Standard Code for Information Interchange (ASCII)", American National Standards Institute, Inc., 1968.
ANSI X3.4-1968、「情報交換用米国標準コード(ASCII)」、American National Standards Institut Inc.、1968。
ANSI X3.16-1976, "American National Standard Character Structure and Character Parity Sense for Serial-by-Bit Data Communication in the American National Standard Code for Information Interchange", American National Standards Institute, Inc., 1976.
ANSI X3.16-1976、「キャラクター構造とキャラクターの同等が情報交換用米国標準コードのビット・データで連続のコミュニケーションのために感じるアメリカの国家規格」、American National Standards Institut Inc.、1976。
ANSI X3.28-1976, "American National Standard Procedures for the Use of the Communication Control Characters of American National Standard Code for Information Interchange in Specified Data Communication Links", American National Standards Institute, Inc., 1976.
ANSI X3.28-1976、「指定されたデータ・コミュニケーション・リンクでの情報交換用米国標準コードの通信制御文字の使用のための米国標準規格手順」、American National Standards Institut Inc.、1976。
ANSI X3.66-1979, "American National Standard for Advanced Data Communication Procedures (ADCCP)", American National Standards Institute, Inc., 1979.
ANSI X3.66-1979、「高度なデータ通信手順(ADCCP)のための米国標準規格」、American National Standards Institut Inc.、1979。
International Standard 1745, "Information Processing - Basic mode control procedures for data communication systems", International Organization for Standardization (ISO), 1975.
国際規格1745、「情報Processing--基本のモードはデータ通信システムのために手順を制御する」、国際標準化機構(ISO)、1975
International Standard 2111, "Data Communication - Basic mode control procedures - Code independent information transfer", ISO, 1973.
国際規格2111、「データCommunication(基本的なモードコントロール手順)は独立している情報転送をコード化する」ISO、1973。
International Standard 2628, "Basic mode control procedures - Complements", ISO, 1973.
1973のStandard2628、国際「基本のモードは手順--補数を制御する」ISO
International Standard 2629, "Basic mode control procedures - Conversational information message transfer", ISO, 1973.
国際規格2629、「基本のモードは手順を制御します--会話の情報メッセージは移す」ISO、1973。
Robinson [Page 11]
ロビンソン[11ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
International Standard 3309, "Data Communication - High-level data link control procedures - Frame structure", ISO, 1982.
国際規格3309、「データCommunication--ハイレベル・データリンク制御手順--枠組構造」、ISO、1982。
International Standard 4335, "Data Communication - High-level data link control procedures - Consolidation of elements of procedures", ISO, 1982.
国際規格4335、「データCommunication--ハイレベル・データリンク制御手順--手順の要素の強化」、ISO、1982。
International Standard 7809, "Data Communication - High-level data link control procedures - Consolidation of classes of procedures", ISO, 1984.
国際規格7809、「データCommunication--ハイレベル・データリンク制御手順--手順のクラスの強化」、ISO、1984。
Recommendation X.25, "Interface between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode and Connected to Public Data Networks by Dedicated Circuit", The International Telegraph and Telephone Consultative Committee (CCITT), 1980 (to be revised, 1984).
推薦X.25、「データ端末装置(DTE)とデータ回線終端装置(DCE)とのパケット形態で作動して、公衆データネットワークにつなげられた端末へのインタフェースは回路を捧げた」国際電信電話諮問委員会(CCITT)、1980、(改訂されるために1984)。
Recommendation Q.920, "ISDN User-network Interface Data Link Layer - General Aspects", CCITT, 1984 (draft E).
推薦Q.920、「ISDNユーザネットワーク・インターフェースデータ・リンク層--、一般局面、」、CCITT、1984(草稿E)。
Recommendation Q.921, "ISDN User-network Interface Data Link Layer Specification", CCITT, 1984 (draft E).
推薦Q.921、「ISDNユーザネットワーク・インターフェースデータ・リンク層仕様」、CCITT、1984(草稿E)。
Draft International Standard 8802.2, "Local Area Network Standards, Logical Link Control", ISO, 1984 (draft).
国際規格8802.2、「ローカル・エリア・ネットワーク規格、論理的なリンク制御」を作成してください。ISO、1984(草稿)。
Draft Proposed Addendum to DIS 8802.2, "Single Frame Service", IEEE, 1984 (Eighth Draft).
提案された付加物を不-8802.2、「シングルフレームサービス」、IEEE、1984(第8草稿)まで作成してください。
Robinson [Page 12]
ロビンソン[12ページ]
RFC 935 January 1985 Reliable Link Layer Protocols
RFC935 1985年1月信頼できるリンクレイヤプロトコル
Appendix A - Bit-Oriented Control Field Contents
付録A--ビット指向の制御フィールドコンテンツ
There are three control field formats. The primary one is used for data frames (called "information frames" in the standards), and is coded as follows:
3つのコントロールフィールド形式があります。 プライマリものは、データフレーム(規格で「情報フレーム」と呼ばれる)に使用されて、以下の通りコード化されます:
8 7 6 5 4 3 2 1 <- bit number, 1 sent first
0 (signifies data frame)
S S S send seq , bit 2 low-order
P/F poll/final bit, for recovery
R R R receive seq (ACK)
8 7 6 5 4 3 2 1<噛み付いている数、送られた最初の0(データフレームを意味する)S S Sがseq、ビット2下位P/Fの投票/決勝を送る1が噛み付かれて、回復R R Rに関して、seqを受けてください。(ACK)
Acknowledgments are cumulative. Recovery is typically to back up and continue from the lost frame. Use of the poll/final bit is beyond the scope of this note.
承認は累積しています。 通常、回復は、無くなっているフレームから支援して、続くことになっています。 投票/最終的なビットの使用はこの注意の範囲を超えています。
Acknowledgments may also be sent in supervisory frames, coded as follows:
また、以下の通りコード化された管理のフレームで承認を送るかもしれません:
8 7 6 5 4 3 2 1 <- bit number, 1 sent first
0 1 (signifies supervisory frame)
T T frame type (see below)
P/F poll/final bit, for recovery
R R R receive seq (ACK)
回復R R Rに関して、8 7 6 5 4 3 2 1の<の噛み付いている番号、送られた最初の0 1(管理のフレームを意味する)T Tフレームタイプ(以下を見る)P/F投票/最終的な1ビット、seqを受けてください。(ACK)
Up to four frame types are possible; only two are required. The first is called RR, for "receive ready", and indicates acknowledgment and that the receiver is prepared to process more frames. The other, RNR for "receive not ready", is used for flow control of the sender. If flow control is not necessary, I suppose even this frame could be dispensed with.
最大4つのフレームタイプが可能です。 2だけが必要です。 1番目は、「準備ができていた状態で、受信してください」のためにRRと呼ばれて、了承と、受信機が、より多くのフレームを処理するように準備されるのを示します。 もう片方(「準備ができていなかった状態で、受信してください」のためのRNR)が送付者のフロー制御に使用されます。 フロー制御は必要でないなら、私は、このフレームさえ省くことができたと思います。
The other supervisory frames, "reject" and "selective reject", are varieties of negative acknowledgement that ask for retransmission of all and one (respectively) of previously transmitted frames. Positive acknowledgment and retransmission are the only really necessary procedures, however.
他の管理のフレーム、「廃棄物」、および「選択している廃棄物」は、すべての「再-トランスミッション」を求める否定的承認のバラエティーと以前に伝えられたフレームの1つ(それぞれ)です。 しかしながら、肯定応答と「再-トランスミッション」は唯一の本当に必要な手順です。
The third frame format is called Unnumbered. Many possible functions are specified in the various standards for these frames, including initializing the link, reset sequence numbers, etc. The basic format is:
3番目のフレーム形式はUnnumberedと呼ばれます。 多くの可能な機能がリンク、リセット一連番号などを初期化するのを含むこれらのフレームの様々な規格で指定されます。 基本形式は以下の通りです。
8 7 6 5 4 3 2 1 <- bit number, 1 sent first
1 1 (signifies unnumbered frame)
T T T T T frame type
P/F poll/final bit, for recovery
8 7 6 5 4 3 2 1<は数に噛み付きました、送られた最初の1 1(無数のフレームを意味する)のT T T TフレームTタイプP/F投票/最終的な1ビット、回復のために
Robinson [Page 13]
ロビンソン[13ページ]
一覧
スポンサーリンク
