Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
UNKNOWN
Updated by:111,124,132,154,179Network Working GroupRequest for Comments # 107NIC # 5806 Output of the Host-Host Protocol Glitch Cleaning Committee UCLA 23 March 1971Robert BresslerSteve Crocker William Crowter Gary Grossman Ray Tomlinson James Withe [Page 1]
IntroductionThe Host-Host Protocol Glitch Cleaning Committee met for the secondtime at UCLA on 8, 9 March 1971, after canvassing the network com-munity. [The result of the (slightly larger) committee's firstmeeting are documented in RFC #102.] The committee agreed onseveral modifications to the protocol in Document #1; these modi-fications are listed below.At each of the meeting, the committee quickly treated all but oneof the extant topics. At the first meeting, the bulk of time wasspent considering the interrupt mechanism, and that discussion issummarized in RFC #102. At the second meeting, the committee spentalmost 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 writtenshortly which incorporates the changes listed here.NCP implementers are to incorporate these changes as soon aspossible. NCP implementers also are to estimate on what datetheis NCP's will be ready and to communicate this estimate toSteve Crocker or his secretary, Byrna Kristel. [Page 2]
ModificationsI BytesHeretofore, a connection has been a bit stream. Henceforth, it is tobe a byte stream, with the byte size, S, indicated in the STR commandand 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 protocolissue, but the size is constant for the life of a connection. Eachmessage must contain an integral number of text bytes (see below).II Message FormatThe 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 inthe STR which created the connection. The C field is 16 bit long andspecifies the number of bytes in the text portion of the message. Azero value in the C field serves no purpose, but is explicitlypermitted.The M1 and M2 field are each 8 bits long and must contain zero. TheM3 field is zero or more bits long and must be all zero. The M3 maybe used to fill out a message to a word boundary. It is followed bypadding.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 TypesNo notion of data type is defined as part of the 2nd level pro- tocol.3rd level protocols may include the notion. Data types cannot besynchronized on message boundaries.IV Reset and Reset ReplyA new pair of one bit control commands RST (reset) and RRP (resetreply) are added. The RST is interpreted as a signal to purge the NCPtables of all existing entries which arose from the Host which sent toRST. The Host receiving the RST acknowledges by returning a RRP. TheHost sending the RST may proceed to request connection after receivingeither a RST or RRP in return. An RST is returned if the second Hostcomes up after the first Host.V Flow ControlThe flow control techniques are changed in two ways. First, the Ceasemechanism is discontinued. The 10HI and 11HI message will no longerbe recognized by the Imps, and the Imps will no loger generate the10HI, 11HI or 12HI messages. [Page 5]
Second, the allocation mechanism now deals with two quantities, bitsand messages. The receiver allocates each of these quantitiesseparately. The sender and receiver each must mantain a 16 bitunsigned counter for message and a 32 bit unsigned counter for bits.When sending a message, the sender subtract one from the messagecounter, and the text length from the bit counter. The receiverdecrements his counter similarly when receiving the message. Thesender is prohibited from sending if either counter would be decre-mented below zero. Similarly, the receiver is prohibited from raisingthe current message allocation above 2**16 - 1, or the current bitallocation above 2**32 - 1.The TEXT LENGTH of a message is the product of S, the byte size, andC, the number of bytes. These values always appear in the first partof 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 commandis further modified to make it possible to ask for none of theallocation to be returned. The new GVB command has four eight bitfields. 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 ofmessage and a bit allocation are to be returned. Each of thesenumbers is interpreted as "the number of 128ths of the currentallocation" to be returned if it is in the range of 0 to 128, and isto be interpreted as "all of the current allocation", if it is in therange 128 to 255.VI Control MessageThe control link is chsnged to link 0; link 1 is not to be used. Theold and new protocols may thereforre coexist. [Page 6]
Message sent over the control link have the same format as otherregular messages, as described above under Message Format. The bytesize field must contain the value 8.Control messages may not contain more tha 120 byte of text; thevalue in the byte count field is thus limited to 120. This limi-tation is intended to help smaller hosts.Control messages must contain an integral number of control commands.Control commands, therefore, may not be split across control messages.VII Link AssignmentThe link are now assigned as follows: 0 control link 1 old protocol's control link - to be phased out 2 - 31 links for connections 32 - 190 reserved -- not for current use 191 to be used only for measurement work under direction of the network measurement center (UCLA) 192 - 255 available for any private experimental use.VIII Fixed Length Control CommandsThe ECO, ERP and ERR commands are now fixed length. The ECO and ERP arenow 16 bit long -- 8 bits of op code and 8 bits of data. The ERR commandis now 96 bits long -- 8 bits of op code, 8 bits of error code, and 80bits of text. 80 bits is long enough to hold the longest non-ERR controlcommand. [Page 7]
IX Control Command FormatsAs mentioned above, the formats of the STR, ALL, GVB, RET, ECO, ERP andERR commands have changed; and the commands RST and RRP have been added.The formats of these commands are given here. | 8 | 32 | 32 | 8 | +-----+-----------------------+-----------------------+-----+ | | | | |1. | STR | send socket | receive socket | | | | | | ^ | +-----+-----------------------+-----------------------+--|--+ | | 8 | 8 | 16 | 32 | +-- byte size +-----+-----+-----------+-----------------------+ | | | | |2. | ALL | link| msg space | bit space | | | | | | +-----+-----+-----------+-----------------------+ | 8 | 8 | 16 | 32 | +-----+-----+-----------+-----------------------+ | | | | |3. | RET | link| msg space | bit space | | | | | | +-----+-----+-----------+-----------------------+ | 8 | 8 | 8 | 8 | +-----+-----+-----+-----+ | | | | |4. | GVB | link|fM | fB | | | | ^ | ^ | +-----+-----+--|--+--|--+ | | | +-- bit fraction +-------- message fraction | 8 | 8 | +-----+-----+ | | |5. | ECO |data | | | | +-----+-----+ [Page 8]
| 8 | 8 | +-----+-----+ | | |6. | ERP |data | | | | +-----+-----+ | 8 | 8 | 80 | +-----+-----+---------------------- // -----------------------+ | | | |7. | ERR | | text | | | ^ | | +-----+--|--+---------------------- // -----------------------+ | +-- error code | 8 | +-----+ | |8. | RST | | | +-----+ | 8 | +-----+ | |9. | RRP | | | +-----+The values of the op codes are NOP = 0 RTS = 1 STR = 2 CLS = 3 ALL = 4 GVB = 5 RET = 6 INR = 7 INS = 8 ECO = 9 ERP = 10 ERR = 11 RST = 12 RRP = 13 [Page 9]
Discussion on Byte StreamsThe previous specification that connections would be conduits of bitstreams provided maximum generality and minimum efficiency. Pressurefor greater efficiency developed and the problen was examined.Two separate kinds of inefficiency arose from bit streams. 1. Receiving Hosts were equired to engage in expensive shifting to concatenate the texts of successive messages. Sending Hosts often also had to shift text fields to align them on word boundaries. 2. Sending NCP's were prohibited from hanging onto ANY text for an indefinite time if it were possible to send even one bit. This requirement was necessary to prevent possible deadlocks. For example, suppose processes A and B have a conversation in progress over a pair of connections, one in each directions. Also suppose that these processes produce exactly one bit of output for each bit of input. Then if A's NCP fails to send a waiting bit because it wants to pack it together with later output from A, then B will not be able to output and neither will A. It is clear then, that unless there is some quantitee that the data in the sending NCP's buffers are not crucially needed on the receive side, the sending NCP must assume otherwise and transmit any waiting data as soon as it is able.These considerations led to the notion of a "transmission unit," whoseexistence would be known to the NCP's. The questions then became whatwere typical and/or possible transmission unit sizes. For [Page 10]
character-oriented interaction, 8-bit transmission units seemedreasonable. For line-oriented interaction, the transmission unit mightbest be the line itself, and therefore variable length; alternatively,it might be best consider the transmission unit to be a character. Forfile transfer, it might be desirable for the transmission unit to be amultiple of the word lengths of both machines; however, the last part ofthe file may not form a whole transmission unit, if the transmissionunit is too large. The consensus became that the transmission unitshould not be divisible under any circumstances, and should, therefore,be fairly small. The notion of transmission unit thus seems to besynonymous with the notation of byte, and the term transmission unit wasdropped.Subsequent discussion of the deadlocks and wakeup aspect revealed thatthere may be two byte sizes associated with a single connection: 1. Transmission from the sending process to the sending NCP is in bytes of size S. The sending NCP must send a message whenever the link is unblocked, the message counter is at least 1, the bit counter is at least S, and the least S bits of text are ready. The message must contain an integral number of bytes. 2. At the receiving side, there may be a different byte size R for transmission from the receiving NCP to the receiving process. An example of where R <> S, is suggested by UCSB which is providing a file system for transparently storing binary files. It is reasonable that a using HOST might send with 36 bit bytes, while the UCSB file system might want to receive 32-bit increments.It is clear that from a network protocol point of view, only the byte Sis relevant, and this is quantity which is communicated in the STRcommand in every message. The choice of the byte size R is up [Page 11]
to the receiving user, and its meaning is how often the receiving NCPshould wakeup the receiving process. It may also happen that areceiving process has an agreement with the receiving NCP which is morecomplex than "please wake me every R bits;" for example, the NCP mightscan for new-line characters before waking up the receiving process.In the new protocol, it is the option of the receiver to refuse arequest for connection on the basis of the proffered byte size.Conceptually, we imagine that NCP's are capable of handling all bytesizes, and that such a choice would be up to the third level pro- grams(user programs, loggers, telnets, etc.) Some Hosts, small ones inparticular, may know enough about their third level programs to restrictthe variety of byte sizes which can be sent or received. While it is amatter of a local policy, the committee strongly suggests that NCP's becapable of handling all byte sizes. One of our committee, moreover,feels strongly that NCP's should be written to be able to receive allbyte sizes S and provide for different byte sizes R for transmission tothe user process. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Enrico Bertone 4/97 ] [Page 12]
[8]ページ先頭