GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc647

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

  1. - 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc647.txt · Last modified: 2010/01/07 00:36 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki