rfc107.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 643 行 · 第 1/2 页

Network Working Group
Request for Comments # 107

NIC # 5806








                    Output of the Host-Host Protocol
                       Glitch Cleaning Committee





                                  UCLA
                             23 March 1971





                            Robert Bressler
                             Steve Crocker
                            William Crowter
                             Gary Grossman
                             Ray Tomlinson
                              James Withe



















                                                                [Page 1]

Introduction

The Host-Host Protocol Glitch Cleaning Committee met for the second
time at UCLA on 8, 9 March 1971, after canvassing the network com-
munity.  [The result of the (slightly larger) committee's first
meeting are documented in RFC #102.]  The committee agreed on
several modifications to the protocol in Document #1; these modi-
fications are listed below.

At each of the meeting, the committee quickly treated all but one
of the extant topics.  At the first meeting, the bulk of time was
spent considering the interrupt mechanism, and that discussion is
summarized in RFC #102.  At the second meeting, the committee spent
almost all of its time discussing the notion of bytes; this dis-
cussion is summarized after the list of modifications.

This RFC entirely supercedes RFC #102, and is an official modi-
fication of Document #1.  A revision of Document #1 will be written
shortly which incorporates the changes listed here.


NCP implementers are to incorporate these changes as soon as
possible.  NCP implementers also are to estimate on what date
theis NCP's will be ready and to communicate this estimate to
Steve Crocker or his secretary, Byrna Kristel.


























                                                                [Page 2]

Modifications


I Bytes

Heretofore, a connection has been a bit stream.  Henceforth, it is to
be a byte stream, with the byte size, S, indicated in the STR command
and in each message.  The byte size meets the constraints: 1 <= S <=
255.

The choice of the byte size for a connection is a 3rd level protocol
issue, but the size is constant for the life of a connection.  Each
message must contain an integral number of text bytes (see below).


II Message Format

The message format is changed to the format shown in figure 1.

The fields S and C are the byte size and byte count, respectively.
The S field is 8 bits wide and must match the byte size specified in
the STR which created the connection.  The C field is 16 bit long and
specifies the number of bytes in the text portion of the message.  A
zero value in the C field serves no purpose, but is explicitly
permitted.

The M1 and M2 field are each 8 bits long and must contain zero.  The
M3 field is zero or more bits long and must be all zero.  The M3 may
be used to fill out a message to a word boundary.  It is followed by
padding.

The text field consists of C bytes, where each byte is S bit long.
The text field starts 72 bits after the start of the message.

   The partition of a byte stream into messages is an artifact
   required by the subnet.  No semantic contents be attacched
   to message boundaries. In particular,














                                                                [Page 3]

                              32 bits
                |<--------------------------------->|


                +-----------------------------------+
                |                                   |
                |              leader               |
                |                                   |
                +--------+--------+-----------------+
                |        |        |                 |
                |   M1   |    S   |        C        |
                |        |        |                 |
                +--------+--------+-----------------+
                |        |        ^                 |
                |   M2   |        |                 |
                |        |        |                 |
                +--------+        |                 |
                |                 |                 |
                |                 |                 |
                |                                   |
                |                Text               |
                //                                 //
                |                 |                 |
                |                 |                 |
                |                 |                 |
                |                 |                 |
                |                 |        +--------+
                |                 |        |        |
                |                 |        |   M3   |
                |                 v        |        |
                +-----------------+--------+--------+
                |                 |
                |  10 --------- 0 | <-- Padding
                |                 |
                +-----------------+

                            Typical Message

                                Figure 1












                                                                [Page 4]

1.  A message with a zero value for C has no meaning, although
    it is legal and it does use up resource allocation.  (See
    Flow Control below.)

2.  A receiver may not expect to see 3rd level control infor-
    mation synchronized with message boundaries.  Particuralrly,
    if the notion of record is defined for a connection, the
    receiver must expect multiple records and/or record frag-
    ments within one message.  (However, control message obey
    special rules.  See below.)


III Message Data Types

No notion of data type is defined as part of the 2nd level pro- tocol.
3rd level protocols may include the notion. Data types cannot be
synchronized on message boundaries.


IV Reset and Reset Reply

A new pair of one bit control commands RST (reset) and RRP (reset
reply) are added.  The RST is interpreted as a signal to purge the NCP
tables of all existing entries which arose from the Host which sent to
RST.  The Host receiving the RST acknowledges by returning a RRP.  The
Host sending the RST may proceed to request connection after receiving
either a RST or RRP in return.  An RST is returned if the second Host
comes up after the first Host.


V Flow Control

The flow control techniques are changed in two ways.  First, the Cease
mechanism is discontinued.  The 10HI and 11HI message will no longer
be recognized by the Imps, and the Imps will no loger generate the
10HI, 11HI or 12HI messages.















                                                                [Page 5]

Second, the allocation mechanism now deals with two quantities, bits
and messages.  The receiver allocates each of these quantities
separately.  The sender and receiver each must mantain a 16 bit
unsigned counter for message and a 32 bit unsigned counter for bits.
When sending a message, the sender subtract one from the message
counter, and the text length from the bit counter. The receiver
decrements his counter similarly when receiving the message.  The
sender is prohibited from sending if either counter would be decre-
mented below zero.  Similarly, the receiver is prohibited from raising
the current message allocation above 2**16 - 1, or the current bit
allocation above 2**32 - 1.

The TEXT LENGTH of a message is the product of S, the byte size, and
C, the number of bytes.  These values always appear in the first part
of the message, as described under Message Format.


The ALL, GVB, and RET command are modified to treat two quantities.
Their formats are given under Control Command, below. The GVB command
is further modified to make it possible to ask for none of the
allocation to be returned.  The new GVB command has four eight bit
fields.  The first two fields are the op code and the link, as before.
The next two fields contain number fM and fB which control how much of
message and a bit allocation are to be returned.  Each of these
numbers is interpreted as "the number of 128ths of the current
allocation" to be returned if it is in the range of 0 to 128, and is
to be interpreted as "all of the current allocation", if it is in the
range 128 to 255.


VI Control Message

The control link is chsnged to link 0; link 1 is not to be used.  The
old and new protocols may thereforre coexist.