diff options
Diffstat (limited to 'doc/rfc/rfc647.txt')
| -rw-r--r-- | doc/rfc/rfc647.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc647.txt b/doc/rfc/rfc647.txt new file mode 100644 index 0000000..934ea66 --- /dev/null +++ b/doc/rfc/rfc647.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group M. A. Padlipsky +Request for Comments: 647 MITRE-TIP +NIC: 31117 November 1974 + + + A PROPOSED PROTOCOL FOR CONNECTING HOST COMPUTERS TO + ARPA-LIKE NETWORK VIA DIRECTLY-CONNECTED + FRONT END PROCESSORS + + by Michael Padlipsky + + with the advice and general agreement of + + Jon Postel and Jim White (SRI-ARC), Virginia Strazisar (MITRE) + + and the general agreement of + + + Tom Boynton (ISI), Frank Brignoli (NSRDC), John Day (CAC), Bob Fink + (LBL), Carl Ellison (UTAH), Eric Harslem (RAND), Wayne Hataway + (AMES-67), John McConnell (I4-TENEX), Ari Ollikainen (UCLA), Dave + Retz (SCRL), Al Rosenfeld (CASE), Stan Taylor (BRL), Doug Wells + (MIT-MULTICS). + + All affiliations are shown only for identifying ARPANET involvement, + and do not necessarily denote organizational approval of the + positions taken here. + + No -- repeat NO -- expression of general agreement should be taken to + apply to Appendix 2, which is exclusively a personal viewpoint. + + + + + + + + + + + + + + + + + + + + + +Padlipsky [Page 1] + +RFC 647 November 1974 + + +INTRODUCTION + + As this proposal is written, in the fall of 1974, the ARPA network + has achieved sufficient acceptance that a rather large number of + organizations are currently planning either to attach their general + purpose computer systems directly to the ARPANET or to interconnect + their systems employing "ARPANET technology". The authors have been + in touch with efforts sponsored by the Air Force systems command, the + Naval Ship Research and Development Center, the Defense + Communications Agency ("PWIN" -- the Prototype World-Wide Military + command and Control system Intercomputer Network), ARPA (The National + Software Works), the AEC, and other government agencies. A common + characteristic of these networks and the sub-networks is the presence + of a number of systems which have no counterparts on the current + ARPANET; thus, hardware "special interfaces" (between the host and + the network Interface Message Processor) and -- more important -- + Network Control Programs cannot simply be copied from working + versions. (Systems include CDO 6600's, XDS Sigma 9's, Univac 494's, + 1107's, 1108's, 1110's, and IBM 370's running operating systems with + no current ARPANET counterparts.) Because it is also widely accepted + that the design and implementation of an NCP for a "new" system is a + major undertaking, an immediate area of concern for networks which + employs as much off-the-shelf hardware and software as is + practicable. This paper addresses two such approaches, one which + apparently is popularly assumed as of now to be the way to go and + another which the authors feel is superior to the more widely known + alternative. + +FRONT-ENDING + + In what might be thought of as the greater network community, the + consensus is so broad that the front-ending is desirable that the + topic needs almost no discussion here. Basically, a small machine (a + PDP-11 is widely held to be most suitable) is interposed between the + IMP and the host in order to shield the host from the complexities of + the NCP. The advantages of this fundamental approach are apparent: + It is more economic to develop a single NCP. "Outward" (User Telnet) + network access is also furnished by the front end acting as a mini- + Host. The potentiality exists for file manipulations on the mini- + Host. Two operating systems are in advanced stages of development on + the ARPANET for PDP-11's which will clearly serve well as bases for + network front ends; thus, the hardware and software are copiable. So + if we consider a model along the following lines + + Host *** Front End --- IMP --- Network + + everything to the right of the asterisks may almost be taken as + given. + + + +Padlipsky [Page 2] + +RFC 647 November 1974 + + + (Caveat: Note the "almost" well in last sentence neither ANTS nor ELF + -- the two systems alluded to above -- is a completely finished + product in the estimation of either their respective developers or of + the knowledgeable ARPANET workers who have contributed to this + report. Both are capable of being brought to fruition, though, and + in a reasonable amount of time. We will assume ELF as the actual + front-end system here for two reasons: apparent consensus, and + current activity level of the development team. However, we have no + reason to believe that readers who prefer ANTS would encounter + substantive difficulties in implementing our proposal on it.) + + (Explanatory notes: ANTS is an acronym for ARPA Network Terminal + Support system; it was developed at the Center for Advanced + Computation (CAC), University of Illinois. ELF is not an acronym (It + is said to be German for "eleven"); it was designed at the Speech + Communications Research Lab (SCRL), Santa Barbara, California.) + +THE RIGID FRONT-END ALTERNATIVE + + Referring back to the model above, the popular view of the asterisks + is to have the front-end system simulate a well known device for each + Host (typically a remote job entry station along the lines of the + 200UT on the CDC 6600), effectively requiring no software changes on + the Host system. We characterize this approach as "rigid" because an + immediate implication is that the Host system is constrained to + handle data to and from the network only in fashions which its system + already provides. (E.g., if you simulate a card reader, your data + will necessarily be treated as batch input if a terminal, necessarily + as time-sharing input.) Now, it may be argued that Host software + changes are only being shunned in order to "get on the air" quickly, + and may be introduced at a later date in order to allow unconstrained + channelling of network data within the Host; but this reasoning may + surely be refuted if it can be shown that an alternative exists which + is essentially as quick to implement and does not require the waste + motion of constructing known-device simulation hardware and software + for each new Host, only to eventually avoid the simulation in the + Host. + + The major advantage which might be claimed for the rigid front-end + approach other than quickness to implement would be embarrassing if + true. That is, the possibility exists that either the "new" Host's + operating systems or system programming staffs are so intractable + that avoiding Host software changes is a necessity rather than a + desire. We certainly hope neither is the case and have no reason to + believe it to be so, but we must acknowledge that such possibilities + exist as meta-issues to this report. + + + + + +Padlipsky [Page 3] + +RFC 647 November 1974 + + +DISAVANTAGES OF THE RIGID FRONT-END ALTERNATIVE + + The rigidity argument sketched above merits some amplification. The + major disadvantage of interfacing with the Host only in fixed ways + lies in a loss of functionality. Granted that "Telnet" and "RJE" + functions can be performed (though we have deep reservations about + file transfer) by simulating a known device there are more things in + practice and in theory than just using the Hosts' time-sharing and + batch monitors. "Teleconferencing" is an instance which comes + immediately to mind. Graphics is another. Neither fits naturally + into the setting a typical operating system is likely to assume for a + Telnet or RJE connection. Further, the ARPANET is just beginning to + evolve a view of "process-to-process" protocols where cooperating + programs on dissimilar systems communicate over network sockets in a + true use of sockets as interprocess communication media. It is + difficult to conceive of viewing a (simulated) line printer as an + abstract "port" without considerable contortion of the extant + operating system. To attempt to summarize this cluster of + objections, a simulation of a known device may be cheaper than a + large enough number of phone calls, but it's not networking. + + For that matter, it is by no means clear that the goal of Host + software changes can even met. In the case of one particular system + on the ARPANET where a PDP-15 was employed as a front end to a PDP- + 10, one of the authors discovered that on attempting to login over + the net he was confronted by an interrogation as to the type of + terminal he was at -- the front end having been attached at the wrong + point in the PDP-10's terminal handling code. (Being a battle- + scarred veteran of Telnet protocol development, he gave suitable + answers for describing a "Network Virtual Terminal". Unfortunately, + however, the NVT apparently had no counterpart in the Hosts' normal + complement of local terminals. And when he tried such Telnet control + functions as "don't echo, I'm at a physically half-duplex terminal" + things really got confused). As it happens, he later found himself + in the neighbrohood of the Host in question, and found himself + spending an afternoon attempting to explain the philosophy and + importance to the Telnet protocol of the NVT. The site personnel + were both appreciative and cooperative, and although we have not had + occasion to verify it, we assume that the site is probably now usable + from the ARPANET. The important point, though, is that operating + systems tend to make extensive, very often unconscious, assumptions + about their operating environments. This observation is particularly + true when it comes to terminal types, and the problem is that there + is simply no guarantee that the several systems in question could + even "do the right thing" if they were front-ended by simulating a + known device -- unless, of course, the simulation of the device in + the mini were so painstaking that all we'd get would be an expensive + way of adding an RJE station, period. + + + +Padlipsky [Page 4] + +RFC 647 November 1974 + + + Less abstract considerations also apply. For one thing, a mini- + computer -- even with "third-generation" software -- is not as free + and convenient an environment to program in as a full-scale Host + therefore, implementing the several simulations will not be trivial + pieces of software engineering. Further, if the simulation software + is prepared by front-end experts, they will encounter repeated + start-up transients in learning enough about the expectations of the + several Host in order to perform their tasks. For that matter, it is + clear that if personnel from the several Host are barred from active + participation in attaching to the network there will be natural (and + understandable) grounds for resentment of the "intrusion" the network + will appear to be; systems programmers also have territorial + emotions, it may safely be assumed. + + On a still more practical level, it should be noted that the + potential need to simulate more than one known device -- and even the + potential complexity of any single device simulation -- may well lead + to a requirement for a larger PDP-11 configuration than would + otherwise be reasonable. And although there are other reasons for + arguing that each front-end processor ought to be as big a + configuration as possible, we must acknowledge that dollars do + matter. Also on the topic of numbers, it should be further noted + that the line speed available for known-device simulations can be + quite low. The 200UT, for example, is on a 4800 baud line, which is + rather a mismatch with a 50,000 baud communication subnet. (Of + course, there's always the 40,800 baud line into the 6600 -- but it + is'nt expected to have interactive devices on it, so the extant + software won't send the data to the "right place"....) And no + experienced ARPANET protocol designer would be willing to overlook + the possibility that there will probably have to be a flow control + discipline between the Host and the front-end processor anyway, so + the no change to Host software goal becomes rather dubious of + fulfillment. + + After all that, it is perhaps gratuitously cruel to point out still + another level of difficulty, but we feel quite strongly that it + should be addressed. For, it must be admitted, the question must be + asked as to who will do the front-end implementations. This sort of + thing is scarcely within the purview of CAC of SCRL. But, as will be + urged in Appendix 2, it is of the outmost importance that whoever + performs the task already have ARPANET expertise, for we know of no + case where "outsiders" have successfully come aboard without having + become "insiders" in the process, which is neither an easy nor cost + effective way to proceed. + + + + + + + +Padlipsky [Page 5] + +RFC 647 November 1974 + + + In light of the above, it is at least reasonable to consider an + alternative to the rigid front-end approach, for regardless of the + weight the reader may attach to any particular cited disadvantage, in + total they at least suggest that the known-device simulation tactic + is not a panacea. + +THE FLEXIBLE FRONT-END ALTERNATIVE + + Our alternative approach is based on a principle which actually has + been around since at least a month before the ARPANET began running + User and Server Telnets on a regular basis. The principle is that it + would be nice to off-load as much as possible of the NCP from the + Host, because Hosts are supposed to have better things to do with + their cpu cycles than field control messages from other Hosts -- + especially when 90% of the control messages are merely ALL(ocate) + commands. This insight led to the notion that all a Host "really" + has to do is associate sockets with processes (and, of course, pass + data along socket connections). And the flexible front-end approach + is no more than an updating of these 1971 ideas to the following: + Drop the hard and fast goal that there will be NO changes to Host + software in favor of the more realistic goal of making MINIMAL + changes to the Host attach the front-end processor to any convenient + high-speed "channel" ( / "port" / "multiplexer" / "line" / "cable"); + let the fro nt-end processor handle the NCP; define an extremely + compact protocol for the Host and front-end to follow (the H-FP); and + let the Host H-FP module distribute the data appropriately within its + operating system, because the H-FP will make it clear where the data + should go and if you have to ram the data into the teletype buffers, + it's still cleaner than trying to do interprocess communication over + a card reader. (The H-FP is detailed in less bald terms in Appendix + 1). Now that might sound rather uncompromising -- and almost surely + sounds rather cryptic -- but between the advantages it engenders and + the more comprehensive description which follows, we feel that it + does represent a superior basis for solving the overriding problem of + how best to attach "new" Hosts to an ARP-like net. + +ADVANTAGES OF THE FLEXIBLE FRONT-END ALTERNATIVE + + The primary advantage of the flexible front-end alternative is + precisely its flexibility: Although minimal implementations may be + envisioned on given Hosts, the most minimal of the implementations is + still as powerful as the rigid front-end approach; and as the need + for more functions is perceived, they may be coded for quite easily + with our approach. This is so because programs in the Host can "get + their hands on" data from the net (and send data to the net) in a + natural fashion -- it is not the case that only those things done on + a given system with the data from, say, a card reader, can + conveniently be done here. Thus, in contrast to the rigid front-end + + + +Padlipsky [Page 6] + +RFC 647 November 1974 + + + approach, the flexible front-end approach "is networking". Indeed, + it should be noted that a major "real" ARPANET server site has + expressed an interest in implementing the H-FP based on some five + minutes' worth of the blackboard explanation with two of the authors. + + Another advantage of our new approach is that it involves personnel + at the various new sites in the process of coming aboard the network. + Not only does this involvement have merit psychologically (if known- + device simulation were employed, the network could represent an alien + intrusion forced upon them, to site systems types), but it is also + technically preferable to have per-site coding done by "experts", + which would not be the case if the per-site tailoring were done + exclusively in the mini. Recall the PDP-15 to PDP-10 attempt + discussed earlier. That case may fairly be viewed as one of the + front-ending's having been performed in ignorance of the conventions + of both the Host's operating system and of the ARPANET? Not only + should that sort of thing be avoided by the expedient of involving + experts on the target operating systems in the process of attaching + to the network but there are practical considerations as well: we + estimate that adding a minimal Host-Front End Protocol routine in a + given operating system would require no longer than the same few man + months to develop than would the adding of a new known-device + simulation package to the mini. So that we foresee scheduling + advantages in addition to the more abstract ones already asserted. + Further, it ought to be a more friendly environment to program in on + the Host than in the mini. (This is not to say the ELF does not + appear to be good environment to program in; rather, it is to make + the "obvious" claim that if the big systems did not furnish + convenient programming environments we wouldn't have them.) + + As touched on earlier, another point which bears further examination + is the area of flow control. The known-device simulation approach + appears to assume that this too will be handled by the mini, and that + the simulation will be aware of whatever flow control discipline the + host and the physical device being simulated follow. However, when + the one device "everybody knows" will be simulated (CDC 200UT) + operates on a 4800 bit-per-second line, and the IMP subnetwork + operates on a 50,000 bps lines, some attention must be paid to the + mismatch -- especially in view of the fact that only one process in + the Host is typically associated with a known device, but the network + actually transmits data on behalf of many processes. Our approach, + on the other hand, allows for a very direct, simple flow control + discipline to be imposed, without getting involved in per-Host + idiosyncrasies. (The option to go more elaborate -- potentially more + efficient -- flow control disciplines is also provided.) Thus, we + can simply pick the beat line speed available on a particular Host, + and attach to it. + + + + +Padlipsky [Page 7] + +RFC 647 November 1974 + + + Notice one other level of practical advantages: The min's H-FP module + can be furnished along with its operating system by the same network + "insiders" who are furnishing the operating system itself. Thus, a + critical task need not be subjected to the perils of subcontracting. + Indeed, this approach lends itself far more readily to subcontracting + than other, if subcontracting must be done for the per-cost software + for with the PDP-11 being almost always the same, network "insiders" + can be used in conjunction with site personnel to build Host H-FP + modules either through commercial consulting contracts or even from + within the ARPANET community. (The latter possibilities exists + because another fact about system programmers is that -- although + they resent "invasions" -- they tend to enjoy getting inside new and + different systems, if only to feel superior to them in contrast with + their own.) + + The strengths of the flexible front-end approach, then, tend to arise + in exactly those areas of weakness of the rigid front-end approach. + Perhaps most important of all, though, is the fact that it "makes + sense" to almost every single experienced member of the ARPANET + community with whom it has been discussed. So, we might reason, if + the ARPANET is desirable, it is desirable because efforts of those + who made it work and if they have gained insights into networking in + general in the process, their opinions deserve particular attention. + +RECOMMENDATIONS + + The protocol specified in Appendix 1 is felt to be around 90% + complete. We are aware that we have not specified all the codes that + will be needed to describe conditions of which the Host and Front-End + must apprise each other, for example. But we think that, in general + the protocol "Woks". We stand willing to discuss it with cognizant + decision makers in the various interested organizations, and, for + that matter, to continue to debate it with our technical peers. At + this stage, however, the dominant makers avert the apparent stampede + to the rigid front-end approach and evaluate the flexible front-end + alternative in light of the preceding arguments and the following + protocol specification. + +APPENDIX 1. THE HOST-FRONT END PROTOCOL + +ASSUMPTIONS + + The physical connection of the front end (FE) to the Host is assumed + to be made over the "best" port (or channel, line, etc.) available on + the Host, where "best" covers both line speed and quality of software + available to physically manage the line. The choice should be made + by site personnel. Hardware interfacing capability is assumed to be + straightforward; it is, at least, no more complex for the H-FP than + + + +Padlipsky [Page 8] + +RFC 647 November 1974 + + + for known-device simulation. The connection is assumed to be + sufficiently closely coupled that a simple, explicit acknowledgment + H-FP command will offer satisfactory flow control. That is, + distances are assumed to be short and bit rates high; thus, the same + assumptions are made here as are made in the case of Local IMP-Host + interfaces: that error checking and flow control are not first-order + problems. + + On the software level, buffering is assumed to be adequate in the + Host to accept at least a full (8096 bit) IMP-IMP message-- although + the FE could probably get around this constraint if it absolutely had + to. Given only a minimal H-FP module in the Host, the FE will allow + the same level of Telnet and RJE functioning as would the known- + device simulation, as follows: The FE will always shield the Host + from the NCP commands and the simplex sockets they deal with, dealing + instead with a repertoire of but five H-FP commands and conversing + over duplex data streams with the appropriate management of Network + sockets left to the FE. (The commands are described below; we + continue with the discussion of assumptions here, but some readers + may prefer to study the commands before continuing with the balance + of this section.) For Telnet, although subsequent analysis may lead + to a more sophisticated treatment, the present assumption is that the + FE will normally refuse all "negotiated options" and strip all Telnet + control codes from the data it passes to the Host (unless the Host + orders it to pass an unaltered Telnet stream); on a pre-installation + basis, the FE will also map from Telnet ASCII to the Host's desired + character set. Telnet "interrupt process" controls are handled by an + H-FP command, discussed below. + + For RJE, because the ARPANET RJE Protocol is only known to have been + implemented on one Host in the ARPANET and is generally considered to + be too cumbersome, the standard socket for RJE will be reserved for + future use, and a special designator will indicate to the Host that + input on the given connection is to be treated as data in the format + and job control language of its own "batch" system. Again, character + set mapping will be available on a per-installation basis. + + For file transfer, however, a further assumption must be made about + Host software. This is because the FE cannot be expected to + manipulate the Host's file system; therefore, if the host whishes to + participate in file transfer activities its H-FP module must be able + to access the Host's file system for both sending and receiving + files. Again, the FE will be able to shield the Host from the + details of the underlying protocols to a large extent; but the Host + must be able to handle FTP "stor" and "retr" commands, which will be + passed over the (single) connection opened between the FE and the + Host for file transfer. (FTP "user" and "pass" commands might also + be desirable. As with Telnet, the FE will manage the Various Network + + + +Padlipsky [Page 9] + +RFC 647 November 1974 + + + sockets involved so as to allow the Host to operate on only the H-FP + connection, and will again optionally perform character set mapping. + Note that Hosts may refuse to open FTP connections until and unless + they choose to, with no impact on the FE. + + The Host's H-FP module, in short, will interpret the commands of the + protocol, distribute Telnet data to and from the appropriate points + within its operating system where terminal I/O is expected, + distribute RJE data like manner, and when it is able to do so handle + FTP as sketched above and amplified on below. It will, also on a + when-desired basis, support calls from its system's user processes + for unspecified purposes I/O on ARPANET sockets to allow for such + functions as teleconferencing and other process exploitations of the + Net. Our overriding assumption is that the initial H-FP module for a + given Host (which does not require FTP or unspecified socket + capability) will not be appreciably harder to implement than a + known-device simulation; that it will offer extensibility to more + interesting uses of the network than the alternative has been + sketched here and will be returned to after the H-FP commands are + described. + +FORMAT OF THE COMMANDS + + All communication between FE and Host is performed in terms of H-FP + commands. The fields of the several commands are one or more + "bytes", where a byte is per-installation parameter of 8, 9, 12, 16, + 18, 32, 36, 48, 60 or 64 bits width, according to the coding + convenience of the given Host's H-FP module implementers? (6 bit + bytes are not supported because they do not offer enough room to + express all the values anticipated for certain code fields machines + with 6 bit internal byte structure can specify 12 bit H-FP bytes and + still be able to use their natural byte oriented instructions.) + Values for fields will be right-justified within their (potentially + several) byte widths. Note that the list of byte sizes is 1) not + meant to be exhaustive, and 2) probably unnecessarily extensive -- as + 8,9, and 12 are probably the only "reasonable" sizes in actual + practice (but if a particular machine is better suited for handling + whole words rather than fractions thereof, the FE can certainly make + life more convenient for it.) + + Although the commands are given names for documentation purposes, the + value transmitted in the first byte of each command will be the + binary representation of the number shown before its name in the next + section. (i,e., the command field is one byte wide.) + +COMMANDS + + (Note that all commands may be sent by either the FE or the Host.) + + + +Padlipsky [Page 10] + +RFC 647 November 1974 + + +1. BEGIN INDEX HOST SOCKET TRANSLATION-TYPE CONNECTION-TYPE + + The begin command establishes a "connection" between the Host and the + FE. Regardless of internal representation, the duplex data stream + the connection represents will be referred to by the value specified + in the next (INDEX) field that is, for example, the FE will send + input from and receive output for a given Telnet connection "on" a + given INDEX, even though it is actually managing two "sockets" for + the purpose in its dealings with the Network. + + a) INDEX is a two-byte field. Both the Host and the FE may choose + arbitrary values for it when opening connection with a BEGIN command + (H-FP implementations will probably simply increment INDEX by 1 + whenever they need a new connection); however, the value of 0 is + reserved to apply to the "global" connection between the Host and the + FE -- thus, when either machine "come up" the first thing it does is + send a BEGIN for INDEX=0. (The END and ACKNOWLEDGE commands also + follow this convention; for that matter, there is no reason why the + MESSAGE command could not also, should it be desired to extend the + FE's functions in the future. At present, however, this is merely a + potential extension.) Note that all other fields should be set to 0 + for INDEX 0 BEGINS. + + b) HOST is a two-byte field. It specifies the Host number associated + with the socket in the next field. On FE to Host BEGINS this is + purely informational. However, on Host to FE BEGINS it is necessary + to enable the FE to identify the foreign Host with which to + communicate at the NCP level. + + c) SOCKET is a four-byte field. If SOCKET=1, a Telnet connection is + to be established. If SOCKET=3, an FTP connection is to be + established. If SOCKET=5, an ARPANET RJE Protocol connection is to + be established (no known current utility). If SOCKET=77, a Host- + specific connection is to be established for RJE/batch. All other + values are for connections for unspecified purposes, to be opened at + the NCP level according to the CONNECTION-TYPE field. Note that + sockets 1, 3, 5 and 77 are "known about" and special-cased by the FE. + + d) TRANSLATION-TYPE is a one-byte field. From FE Host, it is + informational. From Host to FE, it specifies character set mapping + if desired, or characterizes the data to be transmitted over the + connection. 0 request / specifies ASCII data 1; binary data (note + that this value will not be sent from FE to Host under current + assumptions, and that word size is to be a per-installation + parameter); 2, mapping of ASCII to/from local character set. Other + types will be defined if needs are identified. + + + + + +Padlipsky [Page 11] + +RFC 647 November 1974 + + + e) CONNECTION-TYPE is a one-byte field. For FE to Host BEGINS it is + informational. For Host to FE BEGINS it instructs the FE as to which + kind of NCP connection discipline to follow. 1 requests a duplex + connection (i.e., that the Initial Connection Protocol of the ARPANET + be employed) 2, a simplex connection (i.e., that the appropriate + ARPANET "request for connection" Host-Host Protocol commmand be + employed for the gender of the socket at hand). Note that this + extended use of the H-FP will be of interest when (and if) User-level + programs on the Host begin to use the Network. (The FE will open 8- + bit connections at the Network level unless otherwise directed.) + +2. ACKNOLEDGE INDEX CODE + + The ACKNOWLDEGE command is multi-purpose. It must be sent in + response to all commands from the other machine (other than + ACKNOWLEDGES, of course), and is primarily used to indicate the + success or failure of the command just received on INDEX. Note that + this implies that each MESSAGE on a given INDEX must be ACKNOWLEDGEd + before the next can be sent. + + a) INDEX is as above. + + b) CODE is a two-byte field. CODE=0 indicates success / acceptance + of the command most recently received for INDEX. CODE=1 indicates + failure /rejection of the most recent command. (E.g., if a MESSAGE, + buffering was unavailable so the other machine must retransmit; if a + BEGIN, the indicated protocol / socket cannot be serviced.) CODE=3 + indicates an invalid or inactive INDEX has been used. CODE=4 + indicates (HOST to FE) that no mapping is to be performed on the + connection just opened. Other values (for such meanings as "foreign + Host down", "undefined type requested" and the like) will be assigned + as identified. + +3. MESSAGE INDEX COUNT PAD TEXT + + The MESSAGE command is employed for the transmission of data. + + a) INDEX is as above. + + b) COUNT is a two-byte field which specifies the number of bits of + data in the TEXT field. + + c) PAD is a 1-to-n-byte field. Its width is a per-installation + parameter used to enable the TEXT field to start on a word boundary + if the local H-FP implementers so desire. (This is not only a + kindness, but it's also a placeholder if we decide to go to a flow + control mechanism involving sequence numbers.) + + + + +Padlipsky [Page 12] + +RFC 647 November 1974 + + + d) TEXT is a field wherein byte structure is coincidental. It + consists of COUNT bits of data to be sent to the process implicitly + associated with INDEX by a BEGIN command (which has not been ENDed.) + + +4. INTERRUPT INDEX + + The INTERRUPT command, when sent from the FE to the Host, indicates + that an FCP interrupt command (INS or INR) has been received for the + process associated with INDEX; the Host should interrupt the + associated process and whatever fashion is "normal" to it. (The most + common use of the NCP is in Telnet, where it is defined as being the + functional equivalent of having struck a terminal's ATTN, INT, of + BREAK key, or input a "control-c" on certain character-at-a-time + systems; essentially, it requests a "quit button" push. Note that + the FE will take care of the associated Telnet control code in the + input stream.) When sent from the Host to the FE (in process to + process applications), it will indicate that an appropriate NCP + interrupt be sent, according to the gender of the socket associated + with INDEX. + +5. END INDEX CODE + + The END command is used to terminate a connection. It may be sent + either because one system or the other is about to go down, or + because the FE have received an NCP "CLS" command or because the + destination system or IMP has gone down, or at the behest of a Host + user process. + + a) INDEX is as above. Note that if INDEX=0 the END refer to the + "global" connection between the Host and the FE in such case, the + high-order bit of CODE will be set to 1 and the low-order bits will + specify the number of the minutes to shutdown if this information is + available. (Furnished because the associated IMP often informs the + FE of such a condition.) + + b) CODE is a two-byte field. CODE=1 indicates the general "close" + case (either received or ordered) 2, foreign systems has gone down; + 3, foreign IMP has gone down; 4, local IMP has gone down. Other + values will be assigned as identified. + +EXTENSIBILITY + + Simplicity and compactness being major goals of the protocol, the + small repertoire of commands just presented represent "all there is". + Recall that we are specifically omitting from consideration such + issues as error and flow control, which could turn the H-FP into + another Host-Host Protocol. (should error and flow control prove + + + +Padlipsky [Page 13] + +RFC 647 November 1974 + + + desirable in practice, we have, of course, thought of some suitable + mechanism within the H-FP framework; but they are not considered + germane in the present context.) The primary intention here is to + specify a protocol, which lends itself to minimal initial + implementations in the Hosts, on the same time scale as would have + otherwise been required for known-device simulations -- but which + offers great flexibility in the use of the network than would be + achieved through known-device simulation. + + The astute reader will have noticed that most of the commands have + been specified with an eye toward the future. Because the same + protocol, which allows the Host and the FE to communicate can easily + allow user processes on the Host to use the Network, we have tried to + encourage this desirable end by furnishing all the necessary hoods + and handholds for it in the FE's H-FP module through the broad + definitions of the commands. A Hosts's H-FP module can furnish a + trivial interface for user programs in terms of a very few entry + points (open, read, write, and close appear to be the minimal set) + and allow the user program considerable flexibility in its use of the + net. For example, a "User" FTP program could be straightforwardly + created even for a Host, which did not choose to field the BEGINs on + socket 3 (necessary for "Server" FTP capability), and files could + still be "pulled" to the Host even if they could not be "pushed" to + it. (the FE will be required to recognize and special-case BEGINs on + socket 3, but that's a small price to pay). So, if the specification + of the h-FP command repertoire seems somewhat more complex than it + need be, remember that not all of it has to coped with on any given + Host -- and that any give host ca take advantage of more functions as + it desires. (Although it's not really within the present scope, we + stand willing to invent per-Host H-FP to user program interfaces on + request.) + +FTP + + To amplify a bit on the problem of file transfer, it must be observed + that in general only a file system can manage its files. This + borders on tautology and is difficult to deny. Therefore, although + the FE can shield the Host from a great deal of the mechanism + included in the FTP for functions not directly germane to the + transferring of files, Host's operating system and place or extract a + given file, even though it "has" the file's name available to it. + There is no in-principle reason why the H-FP module on the Host can't + invoke an appropriate routine when it receives a BEGIN on socket 3, + though. (The FE will handle all the type and mode negotiations, pass + the "stor" or "retr" line along, and be ready to transmit or receive + on the appropriate socket but "somebody" in the Host has to receive + or transmit the MESSAGE to or from the right place.) But if that + seems hard to do on any particular Host, its H-FP module can merely + + + +Padlipsky [Page 14] + +RFC 647 November 1974 + + + negatively ACKNOWLEDGE any BEGINs for socket 3. The real point to be + noted is that the H-FP still allows in principle for User FTP, as + explained above, even so -- and that the simulation of known device + offers neither (User nor Server FTP) function. + + (Files could, of course, be transferred into the FE, then somehow + gotten into the Host "later" -- perhaps by faxing up a batch job -- + but that route requires either an awful lot of buffering in the mini + or a very sophisticated file system there, or both. It also requires + an awful lot of per-Host information in each FE -- or perhaps human + intervention. We're not saying it can't be done... eventually. But + it's not going to be clean, or quick, or easy, or cheap.) + +SUMMATION + + Several important themes have unavoidably been dealt with piecemeal + in the foreign attempt to specify the H-FP in the abstract. To + gather the threads together, it might be useful to consider the + various ways in which the protocol can be employed, in the context of + their ARPANET counterparts. A. "SERVER" FUNCTIONS: There are, in + essence, three levels on which a Host can use the H-FP to fulfill + ARPANET "Server" functions. 1) For Hosts which choose to take FULL + advantage of the flexibility of the H-FP, all "fourth level" (user + process to user process) protocols can be managed by the Host. The + FE will perform NCP (Host-Host protocol) and IMP-Host protocol + functions (the associated IMP will, of course, perform IMP-IMP + protocol functions), thus shielding the Host from the necessity of + implementing a full-blown NCP with the attendant complexity of being + aware of the 11 to 14 "states" of a socket, flow control, + retransmission, and the like (as well as shielding it from the IMP- + Host protocol, with the attendant complexity of mapping "links" + to/from "sockets", dealing with message types forming and parsing + "leaders", and the like). This mode of use is effected by giving the + "no mapping" code when the Host acknowledge a BEGIN on socket 1 and 3 + (and by simply accepting BEGINs on all other sockets). 2) For Hosts + which choose to take PARTIAL advantage of the flexibility of the H- + FP, many aspects of the fourth level protocols (in particular Telnet + and FTP) can be managed by the FE on the Host's behalf, by virtue of + making assumptions about which Telnet and/or FTP "commands" are to be + permitted and only referring search matter as the association of data + which processes and/or file names to the Host. (Note that the CODE + field of the ACKNOWLEDGE command furnishes the mechanism for + conveying such error information as "file not found" from the Host to + the FE, which in turn will send out appropriate FTP error messages.) + This mode of use is effected by simply accepting (with code 0) BEGINs + on sockets 1 and/or 3 (and doing as one chooses for all other + sockets); that is, fourth level shielding is anticipated to be + commonplace, and is the FE's default case. 3) For Hosts which choose + + + +Padlipsky [Page 15] + +RFC 647 November 1974 + + + to take NO advantage of the flexibility of the H-FP, the "private" + RJE/batch connection type will still provide for the desirable + functions of load sharing and transferring files even though other + fourth level protocols were to be rejected by a given Host (by + refusing BEGINs on all sockets other than 77). Even in this most + restricted case, the ability to upgrade to either of the broader base + is additively implicit in the H-FP, with no changes required to the + FE's own H-FP module -- whereas it would entail considerable + alteration of the Host's operating system had the first step been a + known-device simulation. B. "USER" FUNCTIONS: 1) On the "User" side, + a Host could again elect to handle such fourth level protocols as + Telnet and FTP itself. However, particularly in the Telnet case, + there is no real need for this, as a User Telnet "comes with" the FE + and it is unnecessary to burden the Host with such use unless so many + of its local terminals are hardwired that it would be expensive to + access the FE directly. (Note that for a User FTP, the Host's H-FP + module would, as discussed above, in all likelihood require a user + program callable interface.) 2) On a less ambitious level, the FE + could be induced to perform the same shielding as it offers the + Server FTP (cf. case A2, above), given an "FTP mapping" TRANSLATION- + TYPE on the BEGIN command or the previously suggested special casting + by the FE on socket 3. 3) Finally, "User" functions could be + completely finessed, as per case A3.C. PROCESS TO PROCESS FUNCTIONS: + Irrespective of the positions taken in A and B, given only a user + program callable interface to the Host's H-FP module, all other + fourth level protocols which might evolve -- or, simply, general use + of sockets as interprocess communication ports -- can be achieved + directly. Again, this would fundamentally be an "add-on" to the + system, not an alteration of existing software. + +APPENDIX 2 - SOME NOTES ON IMPLEMENTERS + +INTRODUCTORY DISCLAIMER + + This appendix represents strictly the personal views of one of the + authors; I (now that I can admit to being Mike Padlipsky) have not + even permitted the other authors to agree with the views expressed + here, much less disagree with them, for they are insights which I've + gained the hard way during nearly four years of involvement with the + ARPANET and I feel they need saying -- regardless of the polite + fiction of refraining from finger pointing. Please note at the + outset, however, that I am motivated not by a sense of vindictiveness + -- nor even of righteous indignation -- but rather by a desire to + present some history in the hope that the reader will not be + condemned to repeat it. Note also that even though it makes the + prose more convoluted than it might otherwise have been, the + convention will be observed of "naming no names". I am not, I + + + + +Padlipsky [Page 16] + +RFC 647 November 1974 + + + repeat, out to get these guys; merely to get away from them and their + like in the future. (The reader can stop here with no loss to the + main argument of the paper.) + +SEVERAL HORROR STORIES FROM THE WONDERFUL WORLD OF NETWORKING + + Consider first the tale already told of the PDP 15/PDP 10 front + ending effort. Having been involved in the writing of both the "old" + (1971) and the "new" (1973) Telnet Protocols, I feel a certain sense + of shame by the association that they were not so compellingly clear + that the power of the Network Virtual Terminal / common intermediate + representation approach could not have been missed, ever by system + programmers operating in pretty much of a vacuum with respect to + contact with knowledgeable ARPANET workers. Having said that -- and + meant it -- I still feel we did a good enough job for average-plus + system types to cope with. (The fact that numerous Hosts are on the + Net is evidence of this.) Unfortunately, however, average-minus + system types do exist and must also be contended with. Therefore, if + we do not make a concerted effort to "idiot proof" our protocols, we + may anticipate further repetitions of the sad state the site under + discussion found itself in before it happened upon them. (And, it + must regretfully be observed, support of the "real" ARPANET has + deteriorated to the point that the massive effort required to over- + explain ourselves probably could not be launched in the prevailing + climate. More on this point later.) + + Case in point number two is potentially far graver than a mere + "philosophical" muddle over bringing one site aboard. It involves an + attempt by one of the Armed Services to network a large number of + large machines using the ARPANET as a model. The implementation of + the software house with no known ARPANET expertise. The + communications subnet and the hardware interfacing to the Hosts was + subcontracted to a well-known hardware manufacturer with no known + ARPANET expertise. (As an aside, but because it's so startling I + can't forbear, the "system architect" for the target network is still + another well-known hardware manucfacturer (!), with, of course, no + known ARPANET expertise.) To make a long, continuing story short, it + is currently the case that the "real" ARPANET system whose hardware + corresponds most closely to the machines being netted here (even + though it is benchmarked at a rather lower "mips" (million + instructions per second) rate than the target net's machines) can + transfer files at rates in excess of 28,000 bits per second + (following the rather cumbersome full ARPANET FTP) from a small + configuration developement machine to a lightly loaded (but still + running in excess of 20 users) service machine one Network "hop" + away, while the new system achieves rates which I am apparently not + permitted to quantify but are very considerably lower even though + only one process is being run on each machine -- also one "hop" away + + + +Padlipsky [Page 17] + +RFC 647 November 1974 + + + -- and the protocol for file transfer is nowhere near so general as + in the ARPANET. Given a year or two, the situation can presumably be + rectified, but at present it is fair -- if somewhat fanciful -- to + say that if the Japanese were capable of only like level of + technology transfer they'd still be trying to make up their balance + of trade with those cute little parasols on matchsticks. + + Yet what has gone amiss here in Horror Story 2? I submit that the + choice of subcontractors was based upon a misapprehension of the + level of technological sophistication associated with the ARPANET, + and that what was (is?) needed is a subcontract to a knowledgeable + ARPANET source (and I don't mean to the usual, profit-marking place + -- though I guess I trust them for the subnet), rather than to + "outsiders". (I don't even mean to any particular place on the Net; + maybe what's needed is to form a meta-place out of the whole Net. + More on this, too, later.) The real point is that the model was + essentially ignored by the putative model-followers, and -- + demonstrably -- it shouldn't have been. + + Case three should go a long way toward dispelling any impressions + that might be building in the reader's mind that I'm some sort of + hardcore ARPANET chauvinist. For even "insiders" have blown some. + This is actually a dual case, for it involves two unsuccessful + attempts to furnish terminal support mini-Hosts for the Net. In one + case, the choice of machine was faulty; even with additional core + memory field retrofitted, buffers cannot be furnished to support + reasonable data rates without imposing considerable unnecessary Host + overhead in the processing of too frequent Host-Host Allocation + commands. Nor is there enough room to furnish more than a + rudimentary command language in the mini. Now these were + knowledgeable, reasonably well managed "insiders" -- but they were + contractually not in a position to heed the technical intuitions of + several of themselves and the technical intuitions of many of their + colleagues throughout the Network Working Group that they'd been + painted into a corner. + + In the second sub-case, the hardware and contractual obligations + appear to have been right, but ill-considered choice of + implementation language and inadequate management have prevented the + project's full completion to this time (some two years after its + inception). Again, there was forewarnings from the NWG, in that we + had tried to alert them quite early about the language issue. (On + the management level, we could only sympathize -- and in some cases + empathize -- but it is at least a tentacle position to take that the + ARPANET as a whole happened despite, not because of, management.) (I + guess I am an ace system programmer chauvinist.) + + The final case to be cited here involves another military effort. + + + +Padlipsky [Page 18] + +RFC 647 November 1974 + + + This one I'm not even sure I'm supposed to know about, much less talk + about. But I can say that it involves a subcontractor's attempt to + attach several special purpose machines to a major ARPANET server by + means of an internally invented set of machines and protocols. My + information suggests that when asked why they failed to follow the + apparently obvious course of using ARPANET technology (facilities for + which do, of course, already exist on the target server), the + subcontractors essentially replied that they hadn't felt like it. + They also made their approach work yet, and it's been something like + a couple of years they've been trying. + + Then three's the fad to simulate RJE terminals... but to use that as + Horror Story 5 would be begging the question -- for now. + +SOME MORALS + + Rather than search out any more dirty linen, let's pause and look for + the lessons to be learned. In the first place, it borders on the + obvious that for any technical project the "right" technicians must + be found and empowered to perform it. Despite the generation of + over-sell on the "power of computers", they still absolutely require + intelligent, competent programming -- which in turn requires + intelligent, competent programmers. And, at the risk of gilding the + ragweed, not all self-professed programmers are intelligent and/or + competent. + + In the second, and more interesting, place, all unknowing the ARPANET + has attracted or engendered an "in-group" of extremely good system + types -- who have learned through some sort of natural selection + process to work well together despite the immense handicap of the + heterogeneity of our various "nome" systems' assumptions. We not + only have developed a common tongue, but some of us even like each + other. (It should be noted that Appendix 1 was specified on a + Wednesday afternoon and a little bit of a Thursday morning. Jon and + Jim and I had been there before.) It seems quite clear to me that + the organizations for whom this report is intended should avail + themselves of the expertise which exists in the NWG; we've got a + reasonable track record, after all, especially in comparison to + others who have attempting networking. Many of us also feel quite + strongly that we didn't get a chance to finish the job on the + ARPANET, and would like to be given the chance to "do it right" -- + especially in view of the errors which have been committed in our + name. (This is particularly important because the old gang is + beginning to scatter. For myself, I expect this will be my last RFC. + Well, at least I've tried to make the most of it.) The ARPANET is no + more a finished product than ANTS or ELF -- but all of them could and + should be. + + + + +Padlipsky [Page 19] + +RFC 647 November 1974 + + + In the final place now, a rather trite moral must be drawn: Technical + competence is extremely difficult to assess a priori. (I'm + inordinately fond of saying "Don't ask me what I'm going to say, I + haven't said it yet" myself.) But "track records" ARE important, and + competence CAN be demonstrated -- to a suitable jury of technical + peers. Therefore, beware of plausible sounding subcontractors who + tell you "It's easy". In our field, and particularly in getting all + those strange machines which were developed by people who by and + large didn't talk to each other to "talk" to each other, it's NOT + easy. I'm willing to claim that it will be easier letting some NWG + types do it with the H-FP approach, but it might never be really easy + -- where "never" means for the next 10 years or so, until "real" + networking comes off the shelf with the operating system (which + itself scarcely comes off the shelf today) -- but don't get me + started on The Manufacturers. + +BEYOND THE PAIN PRINCIPLE + + So it's not easy. It's also not impossible. Indeed, the time + appears to be ripe right now avoiding generating a whole new + generation of horror stories, by sensitizing decision makers to + technical realities and "doing things right" this time around. + Having seized this occasion to say some things to that end which I + think are important, I must in good conscience stand ready to defend + the assertions I've made of error in some camps and of correctness in + what I might loosely call "our" camp. I do so stand, with a right + good will. If any reader desires more corroborative detail -- or + merely to see if I rant like this in contexts other than RFCs (or + even to have a go at my explanation of the common intermediate + representation principle), well, I'm still in the ARPANET Directory + -- even though the phone number's different (try 703-790-6375). The + mailbox remains accurate (even though there is no "ARPANET mail + protocol" it's marvelous how stopgaps endure). + + [This RFC was put into machine readable form for entry] + [into the online RFC by Helene Morin, Viagenie,12/1999] + + + + + + + + + + + + + + + +Padlipsky [Page 20] + |