RFC721 日本語訳

NWG/RFC 721                                           1 SEP 76 LLG 36636
Out-of-Band Control Signals

NWG/RFC721 1 9月76日のLLG36636のバンドで出ている制御信号

Network Working Group                                      Larry Garlick
Request for Comments 721                                         SRI-ARC
NIC 36636                                                 1 September 76

ネットワークワーキンググループのラリー・ガーリックはコメント721様アークNIC36636のために1976年9月1日を要求します。

                       Out-of-Band Control Signals
                                  in a
                         Host-to-Host Protocol

バンドの外では、コントロールはホスト間プロトコルで合図します。

This note addresses the problem of implementing a reliable out-of-band
signal for use in a host-to-host protocol.  It is motivated by the fact
that such a satisfactory mechanism does not exist in the Transmission
Control Protocol (TCP) of Cerf et. al. [reference 4, 6]  In addition to
discussing some requirements for such an out-of-band signal (interrupts)
and the implications for the implementation of the requirements, a
discussion of the problem for the TCP case will be presented.

この注意はホスト間プロトコルにおける使用のための高信頼のバンドで出ている信号を実行するというその問題を訴えます。 そのような満足できるメカニズムがサーフetアルの通信制御プロトコル(TCP)で存在していないという事実によってそれは動機づけられています。 そのようなバンドで出ている信号(中断)のためのいくつかの要件と要件の実現のための含意について議論することに加えた[参照4、6]、TCPケースのための問題の議論は提示されるでしょう。

While the ARPANET host-to-host protocol does not support reliable
transmission of either data or controls, it does meet the other
requirements we have for an out-of-band control signal and will be drawn
upon to provide a solution for the TCP case.

アルパネットホスト間プロトコルがデータかコントロールのどちらかの信頼できるトランスミッションを支持していない間、それは、私たちがバンドで出ている制御信号のために持っている他の必要条件を満たして、TCPケースの解決法を提供するのに利用されるでしょう。

The TCP currently handles all data and controls on the same logical
channel.  To achieve reliable transmission, it provides positive
acknowledgement and retransmission of all data and most controls.  Since
interrupts are on the same channel as data, the TCP must flush data
whenever an interrupt is sent so as not to be subject to flow control.

TCPは現在、同じ論理チャネルですべてのデータとコントロールを扱います。 信頼できるトランスミッションを達成するために、それはすべてのデータとほとんどのコントロールの積極的な承認と「再-トランスミッション」を提供します。 データと同じチャンネルの上に中断があるので、フロー制御を受けることがないように中断を送るときはいつも、TCPはデータを洗い流さなければなりません。

Functional Requirements

機能条件書

   It is desirable to insure reliable delivery of an interrupt.  The
   sender must be assured that one and only one interrupt is delivered
   at the destination for each interrupt it sends.  The protocol need
   not be concerned about the order of delivery of interrupts to the
   user.

中断の信頼できる配信を保障するのは望ましいです。 唯一無二の1つの中断がそれが送る各中断のために目的地で提供されると送付者を確信しなければなりません。 中断の配送の注文に関してユーザにプロトコルを心配させる必要はありません。

   The interrupt signal must be independent of data flow control
   mechanisms.  An interrupt must be delivered whether or not there are
   buffers provided for data, whether or not other controls are being
   handled.  The interrupt should not interfere with the reliable
   delivery of other data and controls.

割り込み信号はデータフロー制御機構から独立しているに違いありません。データに提供されたバッファがあるか否かに関係なく、中断を提供しなければなりません、他のコントロールが扱われているか否かに関係なく。 中断は他のデータとコントロールの信頼できる配信を妨げるべきではありません。

   The host-to-host protocol need not provide synchronization between
   the interrupt channel and the data-control channel.  In fact, if
   coupling of the channels relies on the advancement of sequence
   numbers on the data-control channel, then the interrupt channel is no
   longer independent of flow control as required above.  The
   synchronization with the data stream can be performed by the user by

ホスト間プロトコルは割り込みチャネルとデータコントロールチャンネルの間に同期を供給する必要はありません。 事実上、チャンネルのカップリングがデータコントロールチャンネルにおける一連番号の前進に依存するなら、割り込みチャネルはもうフロー制御の如何にかかわらず必要に応じて上にいません。 ユーザはデータ・ストリームとの同期を実行できます。

                                   1

1

NWG/RFC 721                                           1 SEP 76 LLG 36636
Out-of-Band Control Signals

NWG/RFC721 1 9月76日のLLG36636のバンドで出ている制御信号

   marking the data stream when an interrupt is generated.  The
   interrupt need not be coupled with other controls since it in no way
   affects the state of a connection.

中断が発生するとき、データ・ストリームをマークします。 接続の状態に決して影響しないので、中断は他のコントロールに結びつけられる必要はありません。

   Once the interrupt has been delivered to the user, no other semantics
   are associated with it at the host-to-host level.

いったん中断に配送すると、ユーザ、他のどんな意味論もホストからホストへのレベルでそれに関連していません。

Implications

含意

   To provide for reliable delivery and accountability of interrupt
   delivery, an acknowledgement scheme is required.  To associate
   interrupt acknowledgements with the correct interrupt, some naming
   convention for interrupts is necessary.  Sequence numbers provide
   such a naming convention, along with the potential for providing an
   ordering mechanism.

中断配送の信頼できる配信と責任に備えるために、承認計画が必要です。 中断承認を正しい中断に関連づけるために、中断のためのいくらかの命名規則が必要です。 一連番号は注文メカニズムを提供する可能性に伴うそのような命名規則を供給します。

   A separate interrupt channel is required to make interrupts
   independent of flow control.  A separate sequence number space for
   naming interrupts is also necessary.  If the sequence numbers are
   from the same sequence number space as some other channel, then
   sending an interrupt can be blocked by the need to resynchronize the
   sequence numbers on that channel.

別々の割り込みチャネルが、フロー制御の如何にかかわらず中断をするのに必要です。 また、中断を命名するための別々の一連番号スペースも必要です。 一連番号がある他のチャンネルと同じ一連番号スペースから来ているなら、そのチャンネルの一連番号を再連動させる必要性は中断を送るのを妨げることができます。

   In the current TCP, which uses one channel for data, controls, and
   interrupts, flushing of data is combined with the interrupt to bypass
   the flow control mechanism.  However, flushing of resynchronization
   controls is not allowed and receipt of these controls is dependent on
   the acknowledgement of all previous data.  The ARPANET protocol,
   while not providing for reliable transmission, does provide for the
   separation of the interrupt-control channel and the data channel.

現在のTCPでは、データを洗い流すことは、フロー制御メカニズムを迂回させるために中断に結合されます。(TCPはデータ、コントロール、および中断に1個のチャンネルを使用します)。 しかしながら、再同期コントロールを洗い流すことは許されていません、そして、これらのコントロールの領収書は前のすべてのデータの承認に依存しています。 アルパネットプロトコルは信頼できるトランスミッションに備えていない間、割り込み制御チャンネルとデータ・チャンネルの離別に備えます。

Multiple Channels and Sequence Numbers

複数のチャンネルと一連番号

   If multiple channels are to be used for a connection, then it becomes
   interesting to determine how the sequence numbers of the channels can
   be coupled so that sequence number maintenance can be done
   efficiently.

複数のチャンネルが接続に使用されるつもりであるなら、効率的に一連番号維持ができるようにどうしたらチャンネルの一連番号を結合できるかを決定するのがおもしろくなります。

   Assigning sequence numbers to each octet of data and control, as in
   the TCP, allows positive acknowledgement and ordering.  However,
   since packets are retransmitted on timeout, and since multi-path
   packet switch networks can cause a packet to stay around for a long
   time, the presence of duplicate packets and out-of-order packets must
   be accounted for.  A sequence number acceptability test must be
   performed on each packet received to determine if one of the
   following actions should be taken:

TCPのようにデータとコントロールの各八重奏に一連番号を割り当てると、積極的な承認と注文は許されます。 しかしながら、パケットがタイムアウト、およびネットワークが長い間の写しパケットの存在の周りにパケットを残らせることができるマルチ経路パケット交換機以来再送されて、故障しているので、パケットの原因にならなければなりません。 以下の動作の1つが取られるべきであるかどうか決定するために受け取られた各パケットに一連番号受容性テストを実行しなければなりません:

                                   2

2

NWG/RFC 721                                           1 SEP 76 LLG 36636
Out-of-Band Control Signals

NWG/RFC721 1 9月76日のLLG36636のバンドで出ている制御信号

      Acknowledge the packet and pass it on to the user.

パケットを承認してください、そして、それをユーザに渡してください。

      Acknowledge the packet, but do not send it to the user, since it
      has already been delivered.

既にそれを届けたのでそれをユーザに送らないのを除いて、パケットを承認してください。

      Discard the packet; the sequence number is not believable.

パケットを捨ててください。 一連番号は信用できません。

   Acceptability on Channel 0

チャンネル0の上の受容性

      To determine the action to be taken for a packet, acceptability
      ranges are defined.  The following three ranges are mutually
      exclusive and collectively exhaustive of the sequence number space
      (see Figure 1):

行動がパケットに取られることを決定するために、受容性範囲は定義されます。 以下の3つの範囲が、互いに排他的であって、一連番号スペースでまとめて徹底的です(図1を見てください):

         Ack-deliver range (ADR)

範囲をAck送ってください。(ADR)

         Ack-only range (AOR)

Ackだけ範囲(AOR)

         Discard range (DR)

範囲を捨ててください。(博士)

                    ACCEPTABILITY RANGES

受容性範囲

          DR       AOR             ADR              DR
      \\=====)[===========)[===================](========\\
              ^           ^^                   ^^
              !           !\                   !\
              !           ! FCLE               ! DRLE
            AOLE       AORE                 ADRE

博士AOR ADR\\博士=====)[===========)[===================](========\\ ^ ^^ ^^ ! !\ !\ ! ! FCLE ! DRLE AOLE AORE ADRE

                          Figure 1

図1

      Let  S = size of sequence number space (number per octet)

Sを一連番号スペースのサイズとの等しさにしてください。(1八重奏あたりの数)

         x = sequence number to be tested

xは、テストされるために一連番号と等しいです。

         FCLE = flow control left window edge

FCLE=フロー制御左窓縁

                                   3

3

NWG/RFC 721                                           1 SEP 76 LLG 36636
Out-of-Band Control Signals

NWG/RFC721 1 9月76日のLLG36636のバンドで出ている制御信号

         ADRE = (FCLE+ADR) mod S = Ack-deliver right edge (Discard
                  left edge - 1)

ADRE=(FCLE+ADR)モッズSは正しいAck配送している縁と等しいです。(左の縁を捨ててください--1)

         AOLE = (FCLE-AOR) mod S =  Ack-only left edge (Discard
                  right edge + 1)

あとAOLE=(FCLE-AOR)モッズS=Ackだけが斜めに進みます。(破棄正しい縁+1つ)

         TSE = time since connection establishment (in sec)

コネクション確立以来の東京証券取引所=時間(秒の)

         MPL = maximum packet lifetime (in sec)

MPLは最大のパケット生存期間と等しいです。(秒の)

         TB = TCP bandwidth (in octets/sec)

TBはTCP帯域幅と等しいです。(八重奏/秒における)

      For any sequence number, x, and packet text length, l, if

どんな一連番号、xとパケットテキストの長さ、l

         (AOLE <= x <= ADRE) mod S  and

そして(x AOLE<=<はADREと等しいです)モッズS。

         (AOLE <= x+l-1 <= ADRE) mod S

(x+l-1AOLE<=<はADREと等しいです) モッズS

      then the packet should be acknowledged.

そして、パケットは承認されるべきです。

      If x and l satisfy

xとlが満足させられるなら

         (FCLE <= x <= ADRE) mod S  and

そして(x FCLE<=<はADREと等しいです)モッズS。

         (FCLE <= x+l-1 <= ADRE) mod S

(x+l-1FCLE<=<はADREと等しいです) モッズS

      then x can also be delivered to the user; however, ordered
      delivery requires that x = FCLE.

次に、また、xをユーザに渡すことができます。 しかしながら、命令された配送は、xがFCLEと等しいのを必要とします。

      A packet is not in a range only if all of it lies outside a range.
      When a packet falls in more than one range, precedence is ADR,
      then AOR, then DR.  When a packet falls in the AOR then an ACK
      should be sent, even if a packet has to be created.  The ACK will
      specify the current left window edge.  This assures acknowledgment
      of all duplicates.

皆が範囲の外に横たわる場合にだけ、パケットが範囲にありません。 パケットが1つ以上の範囲で転ぶと、先行はADR、AOR、当時のDRです。パケットがその時AORに落ちるとき、ACKを送るべきです、パケットが作成されなければならなくても。 ACKは左の現在の窓の縁を指定するでしょう。 これはすべての写しを承認に保証します。

      ADRE is exactly the maximum sequence number ever "advertised"
      through the flow control window, plus one.  This allows for
      controls to be accepted even though permission for them may never
      have been explicitly given.  Of course, each time a control with a
      sequence number equal to the ADRE is sent, the ADRE must be
      incremented by one.

ADREはちょうど今までフロー制御ウィンドウ、および1を通して「広告を出した」最大の一連番号です。 明らかにそれらのための許可を一度も与えたことがないかもしれませんが、これは、コントロールが受け入れられるのを許容します。 もちろん、ADREと等しい一連番号があるコントロールが送られる各回、ADREを1つ増加しなければなりません。

      AOR is set so that old duplicates (from previous incarnations of
      the connection) can be detected and discarded.  Thus

AORは、古い写し(接続の前の肉体化からの)を検出して、捨てることができるように用意ができています。 このようにして

         AOR = Min(TSE, MPL) * TB

AORは分(東京証券取引所、MPL)*Tbと等しいです。

                                   4

4

NWG/RFC 721                                           1 SEP 76 LLG 36636
Out-of-Band Control Signals

NWG/RFC721 1 9月76日のLLG36636のバンドで出ている制御信号

   Synchronization and Resynchronization Problems

同期とResynchronization問題

      A special problem arises concerning detection of packets (old
      duplicates) in the network that have sequence numbers assigned by
      old instances of a connection.  To handle this reliably, careful
      selection of the initial sequence number is required [ref. 2, 3]
      as well as periodic checks to determine if resynchronization of
      sequence numbers is necessary.  The overhead of such elaborate
      machinery is expensive and repeating it for each additional
      channel is undesirable.

特別な問題はネットワークにおける接続の古い例で一連番号を割り当てるパケット(古い写し)の検出に関して起こります。 これを確かに扱うために、初期シーケンス番号の厳選が必要です。[審判。 2, 3] 確認する定期点検と同様に、一連番号の再同期が必要です。 そのような精巧な機械のオーバーヘッドは高価です、そして、それぞれの追加チャンネルのためにそれを繰り返すのは望ましくありません。

   Acceptability on Channel i

Channel iの上の受容性

      We have concluded that the only savings realizable in the muiltple
      channel case is to use channel zero's initial sequence number and
      resynchronization maintenance mechanism for the additional
      channels.  This can be accomplished by coupling each additional
      channel to channel zero's sequence numbers (CZSN), so that each
      item on channel i carries a pair of sequence numbers, the current
      CZSN and the current channel i's sequence number (CISN).

私たちは、ケースが使用することになっているmuiltpleチャンネルで実現可能な唯一の貯蓄が追加チャンネルのためにゼロの初期シーケンス番号と再同期維持メカニズムを向けると結論を下しました。 ゼロの一連番号(CZSN)を向けるためにそれぞれの追加チャンネルを結合することによって、これを達成できます、チャンネルiに関する各個条が1組の一連番号、現在のCZSN、およびiの一連番号の現在のチャンネル(CISN)を運ぶように。

      The acceptablility test of items on channel i is a composite test
      of both sequence numbers.  First the CZSN is checked to see if it
      would be acknowledged if it were an octet received on channel
      zero.  Only if it would have been discarded would the item on
      channel i be discarded.  Having passed the CZSN test, the CISN is
      checked to see if the item is deliverable and acknowledgable with
      respect to the CISN sequence number space.  The CISN test is a
      check for everything but the existence of old duplicates from old
      instances of the connection and is performed like the check for
      channel zero items.

チャンネルiにおける項目のacceptablilityテストは両方の一連番号の合成テストです。 まず最初に、CZSNは、それがチャンネルゼロで受けられた八重奏であるなら承認されるかどうか確認するためにチェックされます。 それが捨てられた場合にだけ、チャンネルiの上の項目は捨てられるでしょうか? CZSNテストに合格したので、CISNは項目がCISN一連番号スペースに関する提出物と承認可能であるかどうか確認するためにチェックされます。 CISNテストは、接続の古い例からの古い写しの存在以外のすべてのためのチェックであり、チャンネルのためのチェックが項目のゼロに合っているように実行されます。

      It has been shown that to implement additional channels for a TCP
      connection, two alternatives are available-- (1) provide each
      channel with its own initial sequence number and resynchronization
      maintenance mechanism or (2) provide one initial sequence number
      and resynchronization maintenance mechanism for all channels
      through channel zero's mechanism.  It is hard for us to compare
      the two alternatives, since we have no experience implementing any
      resynchronization maintenance mechanism.

(1) それ自身の初期シーケンス番号と再同期維持メカニズムを各チャンネルに提供するか、またはそれは追加チャンネルを実行するためにTCP接続に、2つの選択肢が利用可能であることが示されました--(2) チャンネルによるオール・チャンネルのための1つの初期シーケンス番号と再同期維持メカニズムにゼロのメカニズムを供給してください。 どんな再同期維持メカニズムも実行するという経験が全くないので、私たちは2つの選択肢を比較しにくいです。

TCP Case

TCPケース

   To implement a completely reliable separate interrupt channel for TCP
   requires a channel with a full sequence number space.  It is possible
   to compromise here and make the interrupt number space smaller than
   that required to support consumption of numbers at the TCP's

TCPのために完全に高信頼の別々の割り込みチャネルを実行するのは完全な一連番号スペースがあるチャンネルを必要とします。 割り込み番号でそれがTCPのところで数の消費を支持するのが必要であるより小さいスペースにここで妥協して、するのは可能です。

                                   5

5

NWG/RFC 721                                           1 SEP 76 LLG 36636
Out-of-Band Control Signals

NWG/RFC721 1 9月76日のLLG36636のバンドで出ている制御信号

   bandwidth.  What is lost is the total independence of the flow
   control from the data-control channel.  Normally, the data-control
   sequence numbers will change often enough so that wraparound in the
   interrupt number space causes no problems.

帯域幅。 無くなっていることはデータコントロールチャンネルからのフロー制御の全面独立です。 通常、データコントロール一連番号が十分しばしば変化するので、したがって、割り込み番号スペースのその巻きつけて着るドレスは問題を全く引き起こしません。

   Things become slightly messy when many interrupts are generated in
   quick succession.  Even if the interrupt numbers are acknowledged,
   they cannot be reused if they refer to the same data-control sequence
   number, until a full packet lifetime has elapsed.  This can be
   remedied in all but one case by sending a NOP on the data-control
   channel so that the next set of interrupts can refer to a new
   data-control sequence number.  However, if the data-control channel
   is blocked due to flow control and a resynchronizing control (DSN in
   the TCP case) was just sent, a NOP cannot be created until the
   resynchronization is complete and a new starting sequence number is
   chosen.  Thus to send another interrupt, the TCP must wait for a
   packet lifetime or an indication that it can send a NOP on the
   data-control channel.  (In reality, a connection would probably be
   closed long before a packet lifetime elapsed if the sender is not
   accepting data from the receiver. [reference 1])

多くの中断が間断なく発生するとき、いろいろなことはわずかに乱雑になります。 割り込み番号が承認されても、彼らが同じデータコントロール一連番号について言及するなら、それらを再利用できません、完全なパケット生存期間が経過するまで。 1つのケース以外のすべてで中断の次のセットが新しいデータコントロール一連番号について言及できるようにデータコントロールチャンネルでNOPを送ることによって、これを治すことができます。 しかしながら、フロー制御のためデータコントロールチャンネルを妨げて、ただ、再連動コントロール(TCP場合におけるDSN)を送ったなら、再同期が完全になるまで、NOPを作成できません、そして、新しい始めの一連番号を選びます。 したがって、別の中断を送るために、TCPはデータコントロールチャンネルでNOPを送ることができるというパケット生存期間か指示を待たなければなりません。 (接続はたぶんほんとうは、長い間閉じられて、送付者が受信機からデータを受け入れていないならパケット生存期間の前に. [参照1]が経過していたということでしょう)

                                   6

6

NWG/RFC 721                                           1 SEP 76 LLG 36636
Out-of-Band Control Signals

NWG/RFC721 1 9月76日のLLG36636のバンドで出ている制御信号

REFERENCES

参照

   (1)  J. Postel, L. Garlick, R. Rom, "TCP Specification (AUTODIN II),"
        ARC Catalog #35938, July 1976.

(1) J.ポステル、L.ガーリック、R.Rom、「TCP仕様(AUTODIN II)」、アークカタログ#35938、1976年7月。

   (2)  R. Tomlinson, "Selecting Sequence Numbers," INWG Protocol Note
        #2, September 1974.

(2) R.トムリンスン、「セレクティングシーケンス番号」、INWGプロトコル注意#2、1974年9月。

   (3)  Y. Dalal, "More on Selecting Sequence Numbers," INWG Protocol
        Note #4, October 1974.

(3) INWGが「さらにセレクティングシーケンス番号」で議定書の中で述べるY.Dalalは#4、1974年10月に注意します。

   (4)  V. Cerf, Y. Dalal, C. Sunshine, "Specification of Internet
        Transmission Control Program," INWG General Note #72, December
        1974 (Revised). [Also as RFC 675, NIC Catalog #31505.]

(4) サーフに対してY.Dalal、C.サンシャイン、「インターネットトランスミッション制御プログラムの仕様」、INWG一般は#72、1974(改訂される)年12月に注意します。 [RFC675としてもNICカタログ#31505。]

   (5)  Cerf, V., "TCP Resynchronization," SU-DSL Technical Note #79,
        January 1976.

1976年1月の(5) サーフ、V.、"TCP Resynchronization"SU-DSLテクニカルノート#79。

   (6)  Cerf, V. and R. Kahn, "A Protocol for Packet Network
        Intercommunication," IEEE Transactions on Communication, Vol
        COM-20, No. 5, May 1974.

(6) サーフ、V.、およびR.カーン(「パケット網相互通信のためのプロトコル」、コミュニケーション、Vol COM-20、No.5におけるIEEE取引)は1974がそうするかもしれません。

   (7)  C. Sunshine, "Interprocess Communication Protocols for Computer
        Networks," Digital Systems Laboratory Technical Note #105,
        December 1975.

(7)C.日光、「コンピュータネットワークのためのプロセス間通信プロトコル」、デジタル・システム研究所技術的な注意#105、1975年12月。

                                   7

7