idnits 2.17.1 draft-mckenzie-arpanet-host-host-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 33 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 8, 2011) is 4644 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. McKenzie 2 Internet Draft S. Crocker 3 Intended Status: Historic August 8, 2011 5 Host/Host Protocol for the ARPA Network 6 draft-mckenzie-arpanet-host-host-protocol-01.txt 8 Abstract 10 This document reproduces the Host/Host Protocol developed by the ARPA 11 Network Working Group during 1969, 1970 and 1971. It describes a 12 protocol used to manage communication between processes residing on 13 independent Hosts. It addresses issues of multiplexing multiple 14 streams of communication over a single hardware interface including 15 addressing, flow control, connection establishment/disestablishment, 16 and other signaling. It was the official protocol of the ARPA 17 Network from January 1972 until the switch to TCP/IP in January 1983. 18 It is offered as an "intended RFC" at this late date to help complete 19 the historical record available through the RFC series. 21 IPR-Related Notice 23 Copyright (c) 2011 IETF Trust and the persons identified as the 24 document authors. All rights reserved. 26 This document is subject to BCP 78 and the IETF Trust's Legal 27 Provisions Relating to IETF Documents 28 (http://trustee.ietf.org/license-info) in effect on the date of 29 publication of this document. Please review these documents 30 carefully, as they describe your rights and restrictions with respect 31 to this document. 33 Status of this Document 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. Internet-Drafts are working 37 documents of the Internet Engineering Task Force (IETF). Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. The list of current Internet-Drafts is at 40 http://datatracker.ietf.org/drafts/current. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 9, 2012. 49 Table of Contents 51 1. Introduction........................................................3 52 2. A Few Comments on Nomenclature and Key Concepts.....................4 53 3. Host/Host Protocol Document (with its own table of contents 54 on page 7).......................................................5 55 4. Security Considerations............................................33 56 5. Authors' Addresses.................................................33 57 1. Introduction 59 The Host/Host Protocol for the ARPA Network was created during 1969, 60 1970 and 1971 by the Network Working Group, chaired by Steve Crocker, a 61 graduate student at UCLA. Many of the RFCs with numbers less than 72, 62 plus RFCs 102, 107, 111, 124, 132, 154, and 179 dealt with the 63 development of this protocol. The first official document defining the 64 protocol was issued by Crocker on August 3, 1970 as "Host-Host Protocol 65 Document No. 1" (see citation in RFC #65), which was based on RFC #54 by 66 Crocker, Postel, Newkirk, and Kraley. Revision of Document No. 1 began 67 in mid-February 1971, as discussed in RFC #102. Although McKenzie is 68 listed as the author of the January 1972 document, which superseded 69 Document No. 1, it is more correct to say McKenzie was the person who 70 compiled and edited the document. Most or all of the ideas in the 71 document originated with others. 73 At the time "Host-Host Protocol Document No. 1" was issued it was not 74 given an RFC number because it was not to be viewed as a "request for 75 comments" but as a standard for implementation. It was one of a set of 76 such standards maintained as a separate set of documentation by the 77 Network Information Center (NIC) at Stanford Research Institute (SRI). 78 The January 1972 version reproduced here also followed that approach. 79 It has been noted by many that all subsequent standards were issued as 80 RFCs, and the absence of the Host/Host Protocol specification from the 81 RFC series creates a curious gap in the historical record. It is to 82 fill that gap that this "intended RFC" is offered. 84 In 1972 most ARPA Network documents, RFCs and others, were prepared 85 and distributed in hard copy. The Host/Host Protocol document was typed 86 on a typewriter (probably an IBM Selectric) which had interchangeable 87 print elements, and used both italic and boldface fonts in addition to 88 the regular font. Diagrams were drawn by a graphic artist and pasted 89 into the typed document. Since RFCs are constrained to use a single 90 typeface we have tried to indicate boldface by the use of either all 91 capitals or by a double underline, and to indicate italics by the use of 92 underscores around words in place of spaces. The resulting document is 93 a bit more difficult to read, but preserves the emphases of the 94 original. Of course, the pagination has changed, and we hope we have 95 correctly modified all of the page numbers. There were three footnotes 96 in the original document and we have moved these into the text, set off 97 by indentation and square brackets. A .pdf image of the original 98 document can be found at http://alexmckenzie.weebly.com/hosthost- 99 protocol-for-the-arpa-network.html. 101 2. A Few Comments on Nomenclature and Key Concepts 103 In the protocol definition "RFC" is used to mean "Request for 104 Connection," which refers to either a "Sender to Receiver" or a 105 "Receiver to Sender" request to initiate a connection. In retrospect, 106 this seems like an unnecessarily confusing choice of terminology. 108 At the time this protocol was defined, it was given the undistinguished 109 name "Host-Host Protocol." The acronym "NCP" meant "Network Control 110 Program" and referred to the code that had to be added to the operating 111 system within each host to enable it to interact with its IMP and manage 112 multiple connections. Over time, and particularly in the context of the 113 change from this protocol to TCP/IP, this protocol was commonly called 114 "NCP" and the expansion changed to "Network Control Protocol." 116 This protocol was superseded by TCP. In this document, the protocol is 117 referred to as a second layer (or "level") protocol, where as in current 118 writings TCP is usually referred to as a layer 3 protocol. When this 119 protocol was created, it was expected that over time new layers would be 120 created on top of, below and even in between existing layers. 122 This protocol used a separate channel (the control link) to manage 123 connections. This was abandoned in future protocols. 125 There was no checksum or other form of error control except for the RST 126 in this design. There had been in earlier versions, but it was removed 127 at the insistence of the IMP designers who argued vigorously that the 128 underlying network of IMPs would never lose a packet or deliver one with 129 errors. Although the IMP network was generally quite reliable, there 130 were instances where the interface between the IMP and the host could 131 drop bits, and, of course, experience with congestion control as the 132 network was more heavily used made it clear that the host layer would 133 have to deal with occasional losses in transmission. These changes 134 were built into TCP. 136 Uncertainty about timing constraints in the design of protocols is 137 evident in this document and remains a source of ambiguity, limitation 138 and error in today's design processes. 140 3. Host/Host Protocol Document 142 Host/Host Protocol 143 for the 144 ARPA Network 146 Prepared for the Network Working Group by 147 Alex McKenzie 148 BBN 149 January 1972 150 PREFACE 152 This document specifies a protocol for use in communication between 153 Host computers on the ARPA Network. In particular, it provides for 154 connection of independent processes in different Hosts, control of the 155 flow of data over established connections, and several ancillary 156 functions. Although basically self-contained, this document specifies 157 only one of several ARPA Network protocols; all protocol specifications 158 are collected in the document _Current_Network_Protocols,_ NIC #7104. 160 This document supersedes NIC #7147 of the same title. Principal 161 differences between the documents include: 163 - prohibition of spontaneous RET, ERP, and RRP commands 164 - a discussion of the problem of unanswered CLS commands (page 16) 165 - a discussion of the implications of queuing and not queuing RFCs 166 (page 14) 167 - the strong recommendation that received ERR commands be logged, 168 and some additional ERR specifications. 170 In addition to the above, several minor editorial changes have been 171 made. 173 Although there are many individuals associated with the network who 174 are knowledgeable about protocol issues, individuals with questions 175 pertaining to Network protocols should initially contact one of the 176 following: 178 Steve Crocker 179 Advanced Research Projects Agency 180 1400 Wilson Boulevard 181 Arlington, Virginia 22209 182 (202) 694-5921 or 5922 184 Alex McKenzie 185 Bolt Beranek and Newman Inc. 186 50 Moulton Street 187 Cambridge, Massachusetts 02133 188 (617) 491-1350 ext. 441 190 Jon Postel 191 University of California at Los Angeles 192 Computer Science Department 193 3732 Boelter Hall 194 Los Angeles, California 90024 195 (213) 325-2363 1/72 196 TABLE OF CONTENTS 198 I. INTRODUCTION.....................................................8 199 An overview of the multi-leveled protocol structure in the ARPA 200 Network. 202 II. COMMUNICATION CONCEPTS..........................................10 203 Definitions of terminology and a description of the overall 204 strategy used in Host-to-Host communication. 206 III. NCP FUNCTIONS...................................................13 207 The meat of the document for the first-time reader. Host-to-Host 208 "commands" are introduced with descriptions of conditions of 209 their use, discussion of possible problems, and other background 210 material. 212 Connection Establishment..........................13 213 Connection Termination............................15 214 Flow Control......................................17 215 Interrupts........................................19 216 Test Inquiry......................................20 217 Reinitialization..................................20 219 IV. DECLARATIVE SPECIFICATIONS.....................................22 220 Details for the NCP implementer. A few additional "commands" 221 are introduced, and those described in Section III are 222 reviewed. Formats and code and link assignments are specified. 224 Message Format....................................22 225 Link Assignment...................................24 226 Control Messages..................................24 227 Control Commands..................................24 228 Opcode Assignment.................................31 229 Control Command Summary...........................31 230 I. INTRODUCTION 232 The ARPA Network provides a capability for geographically separated 233 computers, called Hosts, to communicate with each other. The Host 234 computers typically differ from one another in type, speed, word length, 235 operating system, etc. Each Host computer is connected into the network 236 through a local small computer called an _Interface_Message_Processor_ 237 _(IMP)._ The complete network is formed by interconnecting these IMPs, 238 all of which are virtually identical, through wideband communications 239 lines supplied by the telephone company. Each IMP is programmed to 240 store and forward messages to the neighboring IMPs in the network. 241 During a typical operation, a Host passes a message to its local IMP; 242 the first 32 bits of this message include the "network address" of a 243 destination Host. The message is passed from IMP to IMP through the 244 Network until it finally arrives at the destination IMP, which in turn 245 passes it along to the destination Host. 247 Specifications for the physical and logical message transfer between 248 a Host and its local IMP are contained in Bolt Beranek and Newman (BBN) 249 Report No. 1822. These specifications are generally called the _first_ 250 _level_protocol_ or Host/IMP Protocol. This protocol is not by itself, 251 however, sufficient to specify meaningful communication between 252 processes running in two dissimilar Hosts. Rather, the processes must 253 have some agreement as to the method of initiating communication, the 254 interpretation of transmitted data, and so forth. Although it would be 255 possible for such agreements to be reached by each pair of Hosts (or 256 processes) interested in communication, a more general arrangement is 257 desirable in order to minimize the amount of implementation necessary 258 for Network-wide communication. Accordingly, the Host organizations 259 formed a Network Working Group (NWG) to facilitate an exchange of ideas 260 and to formulate additional specifications for Host-to-Host 261 communications. 263 The NWG has adopted a "layered" approach to the specification of 264 communications protocol. The inner layer is the Host/IMP protocol. The 265 next layer specifies methods of establishing communications paths, 266 managing buffer space at each end of a communications path, and 267 providing a method of "interrupting" a communications path. This 268 protocol, which will be used by all higher-level protocols, is known as 269 the _second_level_protocol,_ or Host/Host protocol. (It is worth noting 270 that, although the IMP sub-network provides a capability for _message_ 271 _switching,_ the Host/Host protocol is based on the concept of _line_ 272 _switching._) Examples of further layers of protocol currently developed 273 or anticipated include: 275 1) An _Initial_Connection_Protocol_ (ICP) which provides a convenient 276 standard method for several processes to gain simultaneous access to 277 some specific process (such as the "logger") at another Host. 279 2) A _Telecommunication_Network_ (TELNET) protocol which provides for 280 the "mapping" of an arbitrary keyboard-printer terminal into a 281 Network Virtual Terminal (NVT), to facilitate communication between a 282 terminal user at one Host site and a terminal-serving process at some 283 other site which "expects" to be connected to a (local) terminal 284 logically different from the (remote) terminal actually in use. The 285 TELNET protocol specifies use of the ICP to establish the 286 communication path between the terminal user and the terminal-service 287 process. 289 3) A _Data_Transfer_ protocol to specify standard methods of formatting 290 data for shipment through the network. 292 4) A _File_Transfer protocol to specify methods for reading, writing, 293 and updating files stored at a remote Host. The File Transfer 294 protocol specifies that the actual transmission of data should be 295 performed in accordance with the Data Transfer protocol. 297 5) A _Graphics_ protocol to specify the means for exchanging graphics 298 display information. 300 6) A _Remote_Job_Service_ (RJS) protocol to specify methods for 301 submitting input to, obtaining output from, and exercising control 302 over Hosts which provide batch processing facilities. 304 The remainder of this document describes and specifies the Host/Host, 305 or second level, protocol as formulated by the Network Working Group. 307 II. COMMUNICATION CONCEPTS 309 The IMP sub-network imposes a number of physical restrictions on 310 communications between Hosts; these restrictions are presented in BBN 311 Report Number 1822. In particular, the concepts of leaders, messages, 312 padding, links, and message types are of interest to the design of 313 Host/Host protocol. The following discussion assumes that the reader is 314 familiar with these concepts. 316 Although there is little uniformity among the Hosts in either 317 hardware or operating systems, the notion of multiprogramming dominates 318 most of the systems. These Hosts can each concurrently support several 319 users, with each user running one or more processes. Many of these 320 processes may want to use the network concurrently, and thus a 321 fundamental requirement of the Host/Host protocol is to provide for 322 process-to-process communication over the network. Since the first 323 level protocol only takes cognizance of Hosts, and since the several 324 processes in execution within a Host are usually independent, it is 325 necessary for the second level protocol to provide a richer addressing 326 structure. 328 Another factor which influenced the Host/Host protocol design is the 329 expectation that typical process-to-process communication will be based, 330 not on a solitary message, but rather upon a sequence of messages. One 331 example is the sending of a large body of information, such as a data 332 base, from one process to another. Another example is an interactive 333 conversation between two processes, with many exchanges. 335 These considerations led to the introduction of the notions of 336 connections, a Network Control Program, a "control link", "control 337 commands", connection byte size, message headers, and sockets. 339 A _connection_ is an extension of a link. A connection couples two 340 processes so that output from one process is input to the other. 341 Connections are defined to be simplex (i.e., unidirectional), so two 342 connections are necessary if a pair of processes are to converse in both 343 directions. 345 Processes within a Host are envisioned as communicating with the rest 346 of the network through a _Network_Control_Program_ (NCP), resident in 347 that Host, which implements the second level protocol. The primary 348 function of the NCP is to establish connections, break connections, and 349 control data flow over the connections. We will describe the NCP as 350 though it were part of the operating system of a Host supporting 351 multiprogramming, although the actual method of implementing the NCP may 352 be different in some Hosts. 354 In order to accomplish its tasks, the NCP of one Host must 355 communicate with the NCPs of other Hosts. To this end, a particular 356 link between each pair of Hosts has been designated as the 357 _control_link._ Messages transmitted over the control link are called 358 _control_ _messages_*, and must always be interpreted by an NCP as a 359 sequence of one or more _control_commands_. For example, one kind of 360 control command is used to initiate a connection, while another kind 361 carries notification that a connection has been terminated. 363 [*Note that in BBN Report Number 1822, messages of non-zero type 364 are called control messages, and are used to control the flow of 365 information between a Host and its IMP. In this document, the term 366 "control message" is used for a message of type zero transmitted 367 over the control link. The IMPs take no special notice of these 368 messages.] 370 The concept of a message, as used above, is an artifact of the IMP 371 sub-network; network message boundaries may have little intrinsic 372 meaning to communicating processes. Accordingly, it has been decided 373 that the NCP (rather than each transmitting process) should be 374 responsible for segmenting interprocess communication into network 375 messages. Therefore, it is a principal of the second level protocol 376 that no significance may be inferred from message boundaries by a 377 receiving process. _The_only_exception_to_this_principle_is_in_ 378 _control_messages,_each_of_which_must_contain_an_integral_number_of_ 379 _control_commands._ 381 Since message boundaries are selected by the transmitting NCP, the 382 receiving NCP must be prepared to concatenate successive messages from 383 the network into a single (or differently divided) transmission for 384 delivery to the receiving process. The fact that Hosts have different 385 word sizes means that a message from the network might end in the middle 386 of a word at the receiving end, and thus the concatenation of the next 387 message might require the receiving Host to carry out extensive bit- 388 shifting. Because bit-shifting is typically very costly in terms of 389 computer processing time, the protocol includes the notions of 390 connection byte size and message headers. 392 As part of the process of establishing a connection, the processes 393 involved must agree on a _connection_byte_size._ Each message sent over 394 the connection must then contain an integral number of bytes of this 395 size. Thus the pair of processes involved in a connection can choose a 396 mutually convenient byte size, for example, the least common multiple of 397 their Host word lengths. It is important to note that the ability to 398 choose a byte size _must_ be available to the processes involved in the 399 connection; an NCP is prohibited from imposing an arbitrary byte size on 400 any process running in its own Host. In particular, an outer layer of 401 protocol may specify a byte size to be used by that protocol. If some 402 NCP is unable to handle that byte size, then the outer layer of protocol 403 will not be implementable on that Host. 405 The IMP sub-network requires that the first 32 bits of each message 406 (called the leader) contain addressing information, including 407 destination Host address and link number. The second level protocol 408 extends the required information at the beginning of each message to a 409 total of 72 bits; these 72 bits are called the _message_header._ A 410 length of 72 bits is chosen since most Hosts either can work 411 conveniently with 8-bit units of data or have word lengths of 18 or 36 412 bits; 72 is the least common multiple of these lengths. Thus, the 413 length chosen for the message header should reduce bit-shifting problems 414 for many Hosts. In addition to the leader, the message header includes 415 a field giving the byte size used in the message, a field giving the 416 number of bytes in the message, and "filler" fields. The format of the 417 message header is fully described in Section IV. 419 Another major concern of the second level protocol is a method for 420 reference to processes in other Hosts. Each Host has some internal 421 scheme for naming processes, but these various schemes are typically 422 different and may even be incompatible. Since it is not practical to 423 impose a common internal process naming scheme, a standard intermediate 424 name space is used, with a separate portion of the name space allocated 425 to each Host. Each Host must have the ability to map internal process 426 identifiers into its portion of this name space. 428 The elements of the name space are called _sockets._ A socket forms 429 one end of a connection, and a connection is fully specified by a pair 430 of sockets. A socket is identified by a Host number and a 32-bit socket 431 number. The same 32-bit number in different Hosts represents different 432 sockets. 434 A socket is either a _receive_socket_ or a _send_socket,_ and is so 435 marked by its low-order bit (0 = receive; 1 = send). This property is 436 called the socket's _gender._ The sockets at either end of a connection 437 must be of opposite gender. Except for the gender, second level 438 protocol places no constraints on the assignment of socket numbers 439 within a Host. 441 III. NCP FUNCTIONS 443 The functions of the NCP are to establish connections, terminate 444 connections, control flow, transmit interrupts, and respond to test 445 inquiries. These functions are explained in this section, and control 446 commands are introduced as needed. In Section IV the formats of all 447 control commands are presented together. 449 Connection Establishment 450 ======================== 452 The commands used to establish a connection are STR (sender-to-receiver) 453 and RTS (receiver- to-sender). 455 8* 32 32 8 456 +----------------------------------------------+ 457 | STR | send socket | receive socket | size | 458 +----------------------------------------------+ 460 [*The number shown above each control command field is the length 461 of that field in bits.] 463 8 32 32 8 464 +----------------------------------------------+ 465 | RTS | receive socket | send socket | link | 466 +----------------------------------------------+ 468 The STR command is sent from a prospective sender to a prospective 469 receiver, and the RTS from a prospective receiver to a prospective 470 sender. The send socket field names a socket local to the prospective 471 sender; the receive socket field names a socket local to the prospective 472 receiver. In the STR command, the "size" field contains an unsigned 473 binary number (in the range 1 to 255; zero is prohibited) specifying the 474 byte size to be used for all messages over the connection. In the RTS 475 command, the "link" field specifies a link number; all messages over the 476 connection must be sent over the link specified by this number. These 477 two commands are referred to as requests-for-connection (RFCs). An STR 478 and an RTS match if the receive socket fields match and the send socket 479 fields match. A connection is established when a matching pair of RFCs 480 have been exchanged. Hosts_are_prohibited_from_establishing_more_than_ 481 _one_connection_to_any_local_socket. 483 With respect to a particular connection, the Host containing the send 484 socket is called the _sending_Host_ and the Host containing the receive 485 socket is called the _receiving_Host._ A Host may connect one of its 486 receive sockets to one of its send sockets, thus becoming both the 487 sending Host and the receiving Host for that connection. These terms 488 apply only to data flow; control messages will, in general, be 489 transmitted in both directions. 491 A Host sends an RFC either to request a connection, or to accept a 492 foreign Host's request. Since RFC commands are used both for requesting 493 and for accepting the establishment of a connection, it is possible for 494 either of two cooperating processes to initiate connection 495 establishment. As a consequence, a family of processes may be created 496 with connection- initiating actions built-in, and the processes within 497 this family may be started up (in different Hosts) in arbitrary order 498 provided that appropriate queueing is performed by the Hosts involved 499 (see below). 501 _There_is_no_prescribed_lifetime_for_an_RFC._ A Host is permitted to 502 queue incoming RFCs and withhold a response for an arbitrarily long 503 time, or, alternatively, to reject requests (see Connection Termination 504 below) immediately if it does not have a matching RFC outstanding. It 505 may be reasonable, for example, for an NCP to queue an RFC that refers 506 to some currently unused socket until a local process takes control of 507 that socket number and tells the NCP to accept or reject the request. 508 Of course, the Host which sent the RFC may be unwilling to wait for an 509 arbitrarily long time, so it may abort the request. On the other hand, 510 some NCP implementations may not include any space for queueing RFCs, 511 and thus can be expected to reject RFCs unless the RFC sequence was 512 initiated locally. 514 _Queueing_Considerations_ 516 The decision to queue, or not queue, incoming RFCs has important 517 implications which NCP implementers must not ignore. Each RFC which is 518 queued, of course, requires a small amount of memory in the Host doing 519 the queueing. If each incoming RFC is queued until a local process 520 seizes the local socket and accepts (or rejects) the RFC, but no local 521 process ever seizes the socket, the RFC must be queued "forever." 522 Theoretically this could occur infinitely many times (there is no reason 523 not to queue several RFCs for a single local socket, letting the local 524 process decide which, if any, to accept) thus requiring infinite storage 525 for the RFC queue. On the other hand, if no queueing is performed the 526 cooperating processes described above will be able to establish a 527 desired connection only by accident (when they are started up such that 528 one issues its RFC while the RFC of the other is in transit in the 529 network - clearly an unlikely occurrence). 531 Perhaps the most reasonable solution to the problems posed above is 532 for _each_ NCP to give processes running in its own Host two options for 533 attempting to initiate connections. The first option would allow a 534 process to cause an RFC to be sent to a specified remote socket; with 535 the NCP notifying the process as to whether the RFC were accepted or 536 rejected by the remote Host. The second option would allow a process to 537 tell _its_own_ NCP to "listen" for an RFC to a specified local socket 538 from some remote socket (the process might also specify the particular 539 remote socket and/or Host it wishes to communicate with) and to accept 540 the RFC (i.e., return a matching RFC) if and when it arrives. Note that 541 this also involves queueing (of "listen" requests), but it is internal 542 queueing which is susceptible to reasonable management by the local 543 Host. If this implementation were available, one of two cooperating 544 processes could "listen" while the other process caused a series of RFCs 545 to be sent to the "listening" socket until one was accepted. Thus, no 546 queueing of incoming RFCs would be required, although it would do no 547 harm. 549 _It_is_the_intent_of_the_protocol_that_each_NCP_should_provide_ 550 _either_the_"listen"_option_described_above_or_a_SUBSTANTIAL_queueing_ 551 _facility._ This is not, however, an absolute requirement of the 552 protocol. 554 Connection Termination 555 ====================== 557 The command used to terminate a connection is CLS (close). 559 8 32 32 560 +-----+-------------+-------------+ 561 | CLS | my socket | your socket | 562 +-----+-------------+-------------+ 564 The "my socket" field contains the socket local to the sender of the CLS 565 command. The "your socket" field contains the socket local to the 566 receiver of the CLS command. _Each_side_must_send_and_receive_a_CLS_ 567 _command_before_connection_termination_is_completed_and_the_sockets_are_ 568 _free_to_participate_in_other_connections._ 570 It is not necessary for a connection to be established (i.e., for 571 _both_ RFCs to be exchanged) before connection termination begins. For 572 example, if a Host wishes to refuse a request for connection, it sends 573 back a CLS instead of a matching RFC. The refusing Host then waits for 574 the initiating Host to acknowledge the refusal by returning a CLS. 575 Similarly, if a Host wishes to abort its outstanding request for a 576 connection, it sends a CLS command. The foreign Host is obliged to 577 acknowledge the CLS with its own CLS. Note that even though the 578 connection was never established, CLS commands must be exchanged before 579 the sockets are free for other use. 581 After a connection is established, CLS commands sent by the receiver 582 and sender have slightly different effects. CLS commands sent by the 583 sender indicate that no more messages will be sent over the connection. 584 _This_command_must_not_be_sent_if_there_is_a_message_in_transit_over_ 585 _the_connection._ A CLS command sent by the receiver acts as a demand 586 on the sender to terminate transmission. However, since there is a 587 delay in getting the CLS command to the sender, the receiver must expect 588 more input. 590 A Host should "quickly" acknowledge an incoming CLS so the foreign 591 Host can purge its tables. However, _there_is_no_prescribed_time_ 592 _period_in_which_a_CLS_must_be_acknowledged._ 594 Because the CLS command is used both to initiate closing, aborting 595 and refusing a connection, and to acknowledge closing, aborting and 596 refusing a connection, race conditions can occur. However, they do not 597 lead to ambiguous or erroneous results, as illustrated in the following 598 examples. 600 EXAMPLE 1: Suppose that Host A sends Host B a request for connection, 601 and then A sends a CLS to Host B because it is tired of waiting for a 602 reply. However, just when A sends its CLS to B, B sends a CLS to A 603 to refuse the connection. A will "believe" B is acknowledging the 604 abort, and B will "believe" A is acknowledging its refusal, but the 605 outcome will be correct. 607 EXAMPLE 2: Suppose that Host A sends Host B an RFC followed by a CLS 608 as in example 1. In this case, however, B sends a matching RFC to A 609 just when A sends its CLS. Host A may "believe" that the RFC is an 610 attempt (on the part of B) to establish a new connection or may 611 understand the race condition; in either case it can discard the RFC 612 since its socket is not yet free. Host B will "believe" that the CLS 613 is breaking an _established_ connection, but the outcome is correct 614 since a matching CLS is the required response, and both A and B will 615 then terminate the connection. 617 Every NCP implementation is faced with the problem of what to do if a 618 matching CLS is not returned "quickly" by a foreign Host (i.e., if the 619 foreign Host appears to be violating protocol in this respect). One 620 naive answer is to hold the connection in a partially closed state 621 "forever" waiting for a matching CLS. There are two difficulties with 622 this solution. First, the socket involved may be a "scarce resource" 623 such as the "logger" socket specified by an Initial Connection Protocol 624 (see NIC # 7101) which the local Host cannot afford to tie up 625 indefinitely. Second, a partially broken (or malicious) process in a 626 foreign Host may send an unending stream of RFCs which the local Host 627 wishes to refuse by sending CLS commands and waiting for a match. This 628 could, in worst cases, require 2-to-the-32nd-power! socket pairs to be 629 stored before duplicates began to appear. Clearly, no Host is prepared 630 to store (or search) this much information. 632 A second possibility sometimes suggested is for the Host which is 633 waiting for matching CLS commands (Host A) to send a RST (see page 20) 634 to the offending Host (Host B), thus allowing all tables to be 635 reinitialized at both ends. This would be rather unsatisfactory to any 636 user at Host A who happened to be performing useful work on Host B via 637 network connections, since these connections would also be broken by 638 the RST. 640 Most implementers, recognizing these problems, have adopted some 641 unofficial timeout period after which they "forget" a connection even if 642 a matching CLS has not been received. The danger with such an 643 arrangement is that if a second connection between the same pair of 644 sockets is later established, and a CLS finally arrives for the first 645 connection, the second connection is likely to be closed. This 646 situation can only arise, however, if one Host violates protocol in two 647 ways; first by failing to respond quickly to an incoming CLS, and second 648 by permitting establishment of a connection involving a socket which it 649 believes is already in use. It has been suggested that the network 650 adopt some standard timeout period, but the NWG has been unable to 651 arrive at a period which is both short enough to be useful and long 652 enough to be acceptable to every Host. Timeout periods in current use 653 seem to range between approximately one minute and approximately five 654 minutes. _It_must_be_emphasized_that_all_timeout_periods,_although_ 655 _they_are_relatively_common,_reasonably_safe,_and_quite_useful,_are_in_ 656 _violation_of_the_protocol_since_their_use_can_lead_to_connection_ 657 _ambiguities._ 659 Flow Control 660 ============ 662 After a connection is established, the sending Host sends messages 663 over the agreed-upon link to the receiving Host. The receiving NCP 664 accepts messages from its IMP and queues them for its various processes. 665 Since it may happen that the messages arrive faster than they can be 666 processed, some mechanism is required which permits the receiving Host 667 to quench the flow from the sending Host. 669 The flow control mechanism requires the receiving Host to allocate 670 buffer space for each connection and to notify the sending Host of how 671 much space is available. The sending Host keeps track of how much room 672 is available and never sends more data than it believes the receiving 673 Host can accept. 675 To implement this mechanism, the sending Host keeps two counters 676 associated with each connection, a _message_counter_ and a_bit_counter._ 677 Each counter is initialized to zero when the connection is established 678 and is increased by allocate (ALL) control commands sent from the 679 receiving Host as described below. When sending a message, the NCP of 680 the sending Host subtracts one from the message counter and the _text_ 681 _length_ (defined below) from the bit counter. The sender is prohibited 682 from sending if either counter would be decremented below zero. The 683 sending Host may also return all or part of the message or bit space 684 allocation with a return (RET) command upon receiving a give-back (GVB) 685 command from the receiving Host (see below). 687 The _text_length_ of a message is defined as the product of the 688 connection byte size and the byte count for the message; both of these 689 quantities appear in the message header. Messages with a zero byte 690 count, hence a zero text length, are specifically permitted. Messages 691 with zero text length do not use bit space allocation, but do use 692 message space allocation. The flow control mechanisms do not pertain to 693 the control link, since connections are never explicitly established 694 over this link. 696 The control command used to increase the sender's bit counter and 697 message counter is ALL (allocate). 699 8 8 16 32 700 +------------------------------------+ 701 | ALL | link | msg space | bit space | 702 +------------------------------------+ 704 This command is sent only from the receiving Host to the sending Host, 705 and is legal only when a connection using the link number appearing in 706 the "link" field is established. The "msg space" field and the "bit 707 space" field are defined to be unsigned binary integers specifying the 708 amounts by which the sender's message counter and bit counter 709 (respectively) are to be incremented. The receiver is prohibited from 710 incrementing the sender's counter above (2-to-the-16th-power minus 1), 711 or the sender's bit counter above (2-to-the 32nd-power minus 1). In 712 general, this rule will require the receiver to maintain counters which 713 are incremented and decremented according to the same rules as the 714 sender's counters. 716 The receiving Host may request that the sending Host return all or 717 part of its current allocation. The control command for this request is 718 GVB (give-back). 720 8 8 8 8 721 +----------------------+ 722 | GVB | link | fm | fb | 723 +----------------------+ 725 This command is sent only from the receiving Host to the sending Host, 726 and is legal only when a connection using the link number in the "link" 727 field is established. The fields fm and fb are defined as the fraction 728 (in 128ths) of the current message space allocation and bit space 729 allocation (respectively) to be returned. If either of the fractions is 730 equal to or greater than one, _all_ of the corresponding allocation must 731 be returned. Fractions are used since, with messages in transit, the 732 sender and receiver may not agree on the actual allocation at every 733 point in time. 735 Upon receiving a GVB command, the sending Host must return _at_ 736 _least_* the requested portions of the message and bit space 737 allocations. (A sending Host is prohibited from spontaneously returning 738 portions of the message and bit space allocations.) The control command 739 for performing this function is RET (return). 741 [*In particular, fractional returns must be rounded up, not 742 truncated.] 744 8 8 16 32 745 +------------------------------------+ 746 | RET | link | msg space | bit space | 747 +------------------------------------+ 749 This command is sent only from the sending Host to the receiving Host, 750 and is legal only when a connection using the link number in the "link" 751 field is established and a GVB command has been received from the 752 receiving Host. The "msg space" field and the "bit space" field are 753 defined as unsigned binary integers specifying the amounts by which the 754 sender's message counter and bit counter (respectively) have been 755 decremented due to the RET activity (i.e., the amounts of message and 756 bit space allocation being returned). NCPs are obliged to answer a GVB 757 with a RET "quickly"; however, there is _no_ prescribed time period in 758 which the answering RET must be sent. 760 Some Hosts will allocate only as much space as they can guarantee for 761 each link. These Hosts will tend to use the GVB command only to reclaim 762 space which is being filled very slowly or not at all. Other Hosts will 763 allocate more space than they have, so that they may use their space 764 more efficiently. Such a Host will then need to use the GVB command 765 when the input over a particular link comes faster than it is being 766 processed. 768 Interrupts 769 ========== 771 The second level protocol has included a mechanism by which the 772 transmission over a connection may be "interrupted." The meaning of the 773 "interrupt" is not defined at this level, but is made available for use 774 by outer layers of protocol. The interrupt command sent from the 775 receiving Host to the sending Host is INR (interrupt-by-receiver). 777 8 8 778 +------------+ 779 | INR | link | 780 +------------+ 782 The interrupt command sent from the sending Host to the receiving Host 783 is INS (interrupt-by-sender). 785 8 8 786 +------------+ 787 | INS | link | 788 +------------+ 790 The INR and INS commands are legal only when a connection using the link 791 number in the "link" field is established. 793 Test Inquiry 794 ============ 796 It may sometimes be useful for one Host to determine if some other 797 Host is capable of carrying on network conversations. The control 798 command to be used for this purpose is ECO (echo). 800 8 8 801 +------------+ 802 | ECO | data | 803 +------------+ 805 The "data" field may contain any bit configuration chosen by the Host 806 sending the ECO. Upon receiving an ECO command an NCP must respond by 807 returning the data to the sender in an ERP (echo-reply) command. 809 8 8 810 +------------+ 811 | ERP | data | 812 +------------+ 814 A Host should "quickly" respond (with an ERP command) to an incoming ECO 815 command. However, there is no prescribed time period, after the receipt 816 of an ECO, in which the ERP must be returned. A Host is prohibited from 817 sending an ERP when no ECO has been received, or from sending an ECO to 818 a Host while a previous ECO to that Host remains "unanswered." Any of 819 the following constitute an "answer" to an ECO: information from the 820 local IMP that the ECO was discarded by the network (e.g., IMP/Host 821 message type 7 - Destination Dead), ERP, RST, or RRP (see below). 823 Reinitialization 824 ================ 826 Occasionally, due to lost control messages, system "crashes", NCP 827 errors, or other factors, communication between two NCPs will be 828 disrupted. One possible effect of any such disruption might be that 829 neither of the involved NCPs could be sure that its stored information 830 regarding connections with the other Host matched the information stored 831 by the NCP of the other Host. In this situation, an NCP may wish to 832 reinitialize its tables and request that the other Host do likewise; for 833 this purpose the protocol provides the pair of control commands RST 834 (reset) and RRP (reset-reply). 836 8 837 +-----+ 838 | RST | 839 +-----+ 841 8 842 +-----+ 843 | RRP | 844 +-----+ 846 The RST command is to be interpreted by the Host receiving it as a 847 signal to purge its NCP tables of any entries which arose from 848 communication with the Host which sent the RST. The Host sending the 849 RST should likewise purge its NCP tables of any entries which arise from 850 communication with the Host to which the RST was sent. The Host 851 receiving the RST should acknowledge receipt by returning an RRP. 852 _Once_the_first_Host_has_sent_an_RST_to_the_second_Host,_the_first_Host_ 853 _is_not_obliged_to_communicate_with_the_second_Host_(except_for_ 854 _responding_ _to_RST)_until_the_second_Host_returns_an_RRP._ In fact, 855 to avoid synchronization errors, the first Host _should_not_ communicate 856 with the second until the RST is answered. Of course, if the IMP 857 subnetwork returns a "Destination Dead" (type 7) message in response to 858 the control message containing the RST, an RRP should not be expected. 859 If both NCPs decide to send RSTs at approximately the same time, then 860 each Host will receive an RST and each must answer with an RRP, even 861 though its own RST has not yet been answered. 863 Some Hosts may choose to "broadcast" RSTs to the entire network when 864 they "come up." One method of accomplishing this would be to send an RST 865 command to each of the 256 possible Host addresses; the IMP subnetwork 866 would return a "Destination Dead" (type 7) message for each non-existent 867 Host, as well as for each Host actually "dead." _However,_no_Host_is_ 868 _ever_obliged_to_transmit_an_RST_command._ 870 Hosts are prohibited from sending an RRP when no RST has been 871 received. Further, Hosts may send only one RST in a single control 872 message and should wait a "reasonable time" before sending another RST 873 to the same Host. Under these conditions, a single RRP constitutes an 874 "answer" to _all_ RSTs sent to that Host, and any other RRPs arriving 875 from that Host should be discarded. 877 IV. DECLARATIVE SPECIFICATIONS 879 Message Format 880 ============== 882 All Host-to-Host messages (i.e., messages of type zero) shall have a 883 header 72 bits long consisting of the following fields (see Figure 1): 885 Bits 1-32 Leader - The contents of this field must be constructed 886 according to the specifications contained in BBN Report 887 Number 1822. 889 Bits 33-40 Field M1 - Must be zero. 891 Bits 41-48 Field S - Connection byte size. This size must be 892 identical to the byte size in the STR used in 893 establishing the connection. If this message is being 894 transmitted over the control link the connection byte 895 size must be 8. 897 Bits 49-64 Field C - Byte Count. This field specifies the number of 898 bytes in the text portion of the message. A zero value 899 in the C field is explicitly permitted. 901 Bits 65-72 Field M2 - Must be zero. 903 Following the header, the message shall consist of a text field of C 904 bytes, where each byte is S bits in length. Following the text there 905 will be field M3 followed by padding. The M3 field is zero or more bits 906 long and must be all zero; this field may be used to fill out a message 907 to a word boundary. 909 |<---------------------------32 bits--------------------------->| 910 |<----8 bits--->|<----8 bits--->|<-----------16 bits----------->| 912 +---------------------------------------------------------------+ 913 | | 914 | LEADER | 915 | | 916 +---------------------------------------------------------------| 917 | | | | 918 | FIELD M1 | FIELD S | FIELD C | 919 | | | | 920 +---------------+---------------+-------------------------------+ 921 | | ^ | 922 | FIELD M2 | | | 923 | | | | 924 +---------------+ | | 925 | | | 926 | | | 927 | | | 928 | | | 929 | TEXT | 930 | | | 931 | | | 932 | | | 933 | | | 934 | | +--------------------+ 935 | | | | 936 | | | FIELD M3 | 937 | V | | 938 +-----------------------------------+------+--------------------+ 939 | | 940 | 10-----------------0 |<-------PADDING 941 | | 942 +-----------------------------------+ 944 Figure 1 945 ======== 947 The message header must, among other things, enable the NCP at the 948 receiving Host to identify correctly the connection over which the 949 message was sent. Given a set of messages from Host A to Host B, the 950 only field in the header under the control of the NCP at Host B is the 951 link number (assigned via the RTS control command). Therefore, each NCP 952 must insure that, at a given point in time, for each connection for 953 which it is the receiver, a unique link is assigned. Recall that the 954 link is specified by the sender's address and the link number; thus a 955 unique link number must be assigned to each connection to a given Host. 957 Link Assignment 958 =============== 960 Links are assigned as follows: 962 Link number Assignment 963 =========== ========== 965 0 Control link 967 2-71 Available for connections 969 1, 72-190 Reserved - not for current use 971 191 To be used only for measurement work under the 972 direction of the Network Measurement Center at UCLA 974 192-255 Available for private experimental use. 976 Control Messages 977 ================ 979 Messages sent over the control link have the same format as other 980 Host-to-Host messages. The connection byte size (Field S in the message 981 header) must be 8. Control messages may not contain more than 120 bytes 982 of text; thus the value of the byte count (Field C in the message 983 header) must be less than or equal to 120. 985 Control messages must contain an integral number of control commands. 986 A single control command may not be split into parts which are 987 transmitted in different control messages. 989 Control Commands 990 ================ 992 Each control command begins with an 8-bit _opcode._ These opcodes 993 have values of 0, 1, ... to permit table lookup upon receipt. Private 994 experimental protocols should be tested using opcodes of 255, 254, ... 995 Most of the control commands are more fully explained in Section III. 997 NOP - No operation 998 ================== 1000 8 1001 +-----+ 1002 | NOP | 1003 +-----+ 1005 The NOP command may be sent at any time and should be discarded by the 1006 receiver. It may be useful for formatting control messages. 1008 RST - Reset 1009 =========== 1011 8 1012 +-----+ 1013 | RST | 1014 +-----+ 1016 The RST command is used by one Host to inform another that all 1017 information regarding previously existing connections, including 1018 partially terminated connections, between the two Hosts should be purged 1019 from the NCP tables of the Host receiving the RST. Except for 1020 responding to RSTs, the Host which sent the RST is not obliged to 1021 communicate further with the other Host until an RRP is received in 1022 response. 1024 RRP - Reset reply 1025 ================= 1027 8 1028 +-----+ 1029 | RRP | 1030 +-----+ 1032 The RRP command must be sent in reply to an RST command. 1034 RTS - Request connection, receiver to sender 1035 ============================================ 1037 8 32 32 8 1038 +----------------------------------------------+ 1039 | RTS | receive socket | send socket | link | 1040 +----------------------------------------------+ 1042 RTS receive socket send socket link The RTS command is used to establish 1043 a connection and is sent from the Host containing the receive socket to 1044 the Host containing the send socket. The link number for message 1045 transmission over the connection is assigned with this command; the 1046 "link" field must be between 2 and 71, inclusive. 1048 STR - Request connection, sender to receiver 1049 ============================================ 1051 8 32 32 8 1052 +----------------------------------------------+ 1053 | STR | send socket | receive socket | size | 1054 +----------------------------------------------+ 1056 The STR command is used to establish a connection and is sent from the 1057 Host containing the send socket to the Host containing the receive 1058 socket. The connection byte size is assigned with this command; the 1059 size must be between 1 and 255, inclusive. 1061 CLS - Close 1062 =========== 1064 8 32 32 1065 +-----+-------------+-------------+ 1066 | CLS | my socket | your socket | 1067 +-----+-------------+-------------+ 1069 The CLS command is used to terminate a connection. A connection need 1070 not be completely established before a CLS is sent. 1072 ALL - Allocate 1073 ============== 1075 8 8 16 32 1076 +------------------------------------+ 1077 | ALL | link | msg space | bit space | 1078 +------------------------------------+ 1080 The ALL command is sent from a receiving Host to a sending Host to 1081 increase the sending Host's space counters. This command may be sent 1082 only while the connection is established. The receiving Host is 1083 prohibited from incrementing the Host's message counter above (2-to-the- 1084 16th-power minus 1) or bit counter above (2-to-the-32nd-power minus 1). 1086 GVB - Give back 1087 =============== 1089 8 8 8 8 1090 +----------------------+ 1091 | GVB | link | fm | fb | 1092 +----------------------+ 1093 ^ ^ 1094 | +--- bit fraction 1095 +-------- message fraction 1097 The GVB command is sent from a receiving Host to a sending Host to 1098 request that the sending Host return all or part of its message space 1099 and/or bit space allocations. The "fractions" specify what portion (in 1100 128ths) of each allocation must be returned. This command may be sent 1101 only while the connection is established. 1103 RET - Return 1104 ============ 1106 8 8 16 32 1107 +------------------------------------+ 1108 | RET | link | msg space | bit space | 1109 +------------------------------------+ 1111 The RET command is sent from the sending Host to the receiving Host to 1112 return all or a part of its message space and/or bit space allocations 1113 in response to a GVB command. This command may be sent only while the 1114 connection is established. 1116 INR - Interrupt by receiver 1117 =========================== 1119 8 8 1120 +------------+ 1121 | INR | link | 1122 +------------+ 1124 The INR command is sent from the receiving Host to the sending Host when 1125 the receiving process wants to interrupt the sending process. This 1126 command may be sent only while the connection is established. 1128 INS - Interrupt by sender 1129 ========================= 1131 8 8 1132 +------------+ 1133 | INS | link | 1134 +------------+ 1136 The INS command is sent from the sending Host to the receiving Host when 1137 the sending process wants to interrupt the receiving process. This 1138 command may be sent only while the connection is established. 1140 ECO - Echo request 1141 ================== 1143 8 8 1144 +------------+ 1145 | ECO | data | 1146 +------------+ 1148 The ECO command is used only for test purposes. The data field may be 1149 any bit configuration convenient to the Host sending the ECO command. 1151 ERP - Echo reply 1152 ================ 1154 8 8 1155 +------------+ 1156 | ERP | data | 1157 +------------+ 1159 The ERP command must be sent in reply to an ECO command. The data field 1160 must be identical to the data field in the incoming ECO command. 1162 ERR - Error detected 1163 ==================== 1165 8 8 80 1166 +-----+------+---------------------------- ~ -------------+ 1167 | ERR | code | data | 1168 +-----+------+---------------------------- ~ -------------+ 1170 The ERR command may be sent whenever a second level protocol error is 1171 detected in the input from another Host. In the case that the error 1172 condition has a predefined error code, the "code" field specifies the 1173 specific error, and the data field gives parameters. For other errors 1174 the code field is zero and the data field is idiosyncratic to the 1175 sender. Implementers of Network Control Programs are expected to 1176 publish timely information on their ERR commands. 1178 The usefulness of the ERR command is compromised if it is merely 1179 discarded by the receiver. Thus, sites are urged to record incoming 1180 ERRs if possible, and to investigate their cause in conjunction with the 1181 sending site. The following codes are defined. Additional codes may be 1182 defined later. 1184 a. Undefined (Error code = 0) 1185 The "data" field is idiosyncratic to the sender. 1187 b. Illegal opcode (Error code = 1) 1188 An illegal opcode was detected in a control message. The "data" 1189 field contains the ten bytes of the control message beginning with 1190 the byte containing the illegal opcode. If the remainder of the 1191 control message contains less than ten bytes, fill will be 1192 necessary; the value of the fill is zeros. 1194 c. Short parameter space (Error code = 2) 1195 The end of a control message was encountered before all the 1196 required parameters of the control command being decoded were 1197 found. The "data" field contains the command in error; the value 1198 of any fill necessary is zeros. 1200 d. Bad parameters (Error code = 3) 1201 Erroneous parameters were found in a control command. For 1202 example, two receive or two send sockets in an STR, RTS, or CLS; 1203 a link number outside the range 2 to 71 (inclusive); an ALL 1204 containing a space allocation too large. The "data" field 1205 contains the command in error; the value of any fill necessary is 1206 zeros. 1208 e. Request on a non-existent socket (Error code = 4) 1209 A request other than STR or RTS was made for a socket (or link) 1210 for which no RFC has been transmitted in either direction. This 1211 code is meant to indicate to the NCP receiving it that functions 1212 are being performed out of order. The "data" field contains the 1213 command in error; the value of any fill necessary is zeros. 1215 f. Socket (link) not connected (Error code = 5) 1216 There are two cases: 1218 1. A control command other than STR or RTS refers to a socket (or 1219 link) which is not part of an established connection. This 1220 code would be used when one RFC had been transmitted, but the 1221 matching RFC had not. It is meant to indicate the failure of 1222 the NCP receiving it to wait for a response to an RFC. The 1223 "data" field contains the command in error; the value of any 1224 fill necessary is zeros. 1226 2. A message was received over a link which is not currently being 1227 used for any connection. The contents of the "data" field are 1228 the message header followed by the first eight bits of text (if 1229 any) or zeros. 1231 Opcode Assignment 1232 ================= 1234 Opcodes are defined to be eight-bit unsigned binary numbers. The 1235 values assigned to opcodes are: 1237 NOP = 0 1238 RTS = 1 1239 STR = 2 1240 CLS = 3 1241 ALL = 4 1242 GVB = 5 1243 RET = 6 1244 INR = 7 1245 INS = 8 1246 ECO = 9 1247 ERP = 10 1248 ERR = 11 1249 RST = 12 1250 RRP = 13 1252 Control Command Summary 1253 ======================= 1255 8 1256 +-----+ 1257 | NOP | 1258 +-----+ 1260 8 32 32 8 1261 +----------------------------------------------+ 1262 | RTS | receive socket | send socket | link | 1263 +----------------------------------------------+ 1265 8 32 32 8 1266 +----------------------------------------------+ 1267 | STR | send socket | receive socket | size | 1268 +----------------------------------------------+ 1270 8 32 32 1271 +-----+-------------+-------------+ 1272 | CLS | my socket | your socket | 1273 +-----+-------------+-------------+ 1275 8 8 16 32 1276 +------------------------------------+ 1277 | ALL | link | msg space | bit space | 1278 +------------------------------------+ 1279 8 8 8 8 1280 +----------------------+ 1281 | GVB | link | fm | fb | 1282 +----------------------+ 1284 8 8 16 32 1285 +------------------------------------+ 1286 | RET | link | msg space | bit space | 1287 +------------------------------------+ 1289 8 8 1290 +------------+ 1291 | INR | link | 1292 +------------+ 1294 8 8 1295 +------------+ 1296 | INS | link | 1297 +------------+ 1299 8 8 1300 +------------+ 1301 | ECO | data | 1302 +------------+ 1304 8 8 1305 +------------+ 1306 | ERP | data | 1307 +------------+ 1309 8 8 80 1310 +-----+------+---------------------------- ~ -------------+ 1311 | ERR | code | data | 1312 +-----+------+---------------------------- ~ -------------+ 1314 8 1315 +-----+ 1316 | RST | 1317 +-----+ 1319 8 1320 +-----+ 1321 | RRP | 1322 +-----+ 1324 [ This is the end of the January 1972 document. ] 1325 4. Security Considerations 1327 This document does not discuss any security considerations. 1329 5. Authors' Addresses 1331 Alexander McKenzie 1332 PMB #4334, PO Box 2428 1333 Pensacola, FL 32513 1334 amckenzie3 at yahoo dot com 1336 Steve Crocker 1337 5110 Edgemoor Lane 1338 Bethesda, MD 20814 1339 USA 1340 steve at stevecrocker dot com 1342 This Internet-Draft will expire on February 9, 2012.