Network Working Group
`RFO #647
`NIO #31117
`
`M. A. ~adlipskY
`MIXR~-TIP
`NovemOer 12, 1~74
`
`A PROPOSED PROTOOOL FOR OONNECTI~G HOST CUMPUTE~S TO
`ARPA-LIKE NETWORKS VIA DI~ECTLY-CUNNECTED
`FRONT END PROCESSOKS
`
`by Michael padlips~y
`
`with the advice and ~eneral agreement of
`
`Jon postel an~ Jim wh1te (SRI-ARC), Virginia strazisar (M!TRE~
`
`and the general ~greement of
`
`Tom Boynton (151)1 Frank Brignoli (NSRDC)I John Day (CAO),
`Bob Fink (I.8L), carl ElliQon (UTAH), Eric Harslem
`(RAND),
`WaYne Hathaway
`(AMES-67), John McConnell (I4~TENEX), Ari
`Ul1ik~inen (UCLA), Dave Retz (SCRL), Al Rosen£ela
`(OASE),
`Stan TaYlor (BRL), Doug Wells (MIT-MULTICS)
`
`shown only for identifying ARPANET
`All affiliations are
`involvemerlt, and do not necessarily denote organizational
`approval of the positions taken here.
`
`**************************************************
`-- repeat NO -- eXpression of general agreement should
`No
`be taken to apPly to APpendix 2 1 Which
`is exclusivelY a
`personal Viewpoint.
`********************************~*****************
`
`

`

`!WrRODUCTION
`
`tne ARPA
`the fall Of 1974~
`in
`As this propOsal is written~
`netw6rk has achieved ~uffici~rlt acceptance that ~ rather larie
`number of organi~ations are currently planning either
`to a~tach
`their general purpose computer systems directly to the ARPAN~T ~r
`to interconnect their
`systems
`emploY1ng
`"ARPANET teChnology~.
`The authors have been in touch with efforts sponsored by the -Air
`Force Systems Command, the Naval Ship Research
`and Development
`the Defense Oommunications Agency
`("PWIN"
`' t he
`Center~
`Prototype World-wide Military Command
`Control
`System
`an~
`!nterc~mputer NetworK), ARPA (the National Software WorkS), the
`AEC, and other ~overnment agencies. A cammon characteri~tic
`of
`these networkS
`and BUb-networks is the presence Of a number of
`systenIs which have no counterparts on the current ARPA~j£T;
`vnua ,
`haraware "Hpeci~l
`interfaceS" (between the Host and the nel"worx
`Interface Message processor) atId -- more
`important
`NetworK
`control Programs cannot simplY be copied from WOrking versions.
`(Systems include COO 6600'8, XDS Sigma 9's. Univac 494's. 110'('s,
`1106 i s .
`and 1110'S, and IbM 370 i s running operat1ng"systems ~ith
`no current AP.PA~ET countp.rparts).
`BecaUSe
`it is also widely
`accep~ed that the design and implementation of an NOP for . a "new"
`syste~ is a major undertaKing~ ~n immediate area of concern
`for
`involved
`is to develop an appr-oac n tor at.. t.a cnLng systems to
`a.ll
`networks which
`employs as much off-the-shelf hardware
`and
`sOftware as
`is pra.cticable.
`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
`superi~r 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 front-ending is'desir~ole that the
`topic needs alm~st no uiscussion here.
`8asically,
`a
`small
`maChine
`(a PDP-ll
`is wioe~y held
`to be most suitaole) is
`interp6 sed between the IMP ana the Host in order
`to Shield
`the
`Host
`from
`the complexities of the NCP. The advantages 'Of thiS
`fundamental apPI'6acn are apparent: I t is more economiC to develop
`a
`single NCP.
`"Outward"
`(user ~elnet) network aCcess is also
`furnished uy
`the
`front end acting as
`a
`The
`m1ni-~ost.
`potentiality eX1sts for file manipUlations on the mini-Host. Two
`operating sys~ems ~re in adVanced stages Of development on
`the
`for PDP-ll's Which will clearlY serve Well as oaseS for
`ARPAN~T
`netw~rk front endS;
`the hardware and software
`are copiaOle.
`thus 1
`So if we consider a
`model along the following lines
`Host *** Front· Ina --­
`everything t6 the right of the ~sterisks may almost be
`given.
`
`IMP --­ Network
`
`taken as
`
`

`

`sentence; neither
`the l~st
`(Caveat~ Hote the "almost" well in
`to above -- is a
`ANT S nor ELF
`the
`two
`systems ~lluded
`comPletelY finished product ill the es~imation of either
`their
`respec~ive_devel~pers qr of the knowledgeable ARPANET workers WhO
`have contributed to thiS
`report.
`60tn are capable ot being
`brought
`to fruition~ though, and in a reasonable amoun~ Of time.
`We Will assume ELF ~s the actUal front-end system here
`for
`two
`apparent consetlsus~
`a.nd current actiVity leVel of the
`reason~:
`development team. However, we h~Ve no
`reason
`to believe
`that
`readers who prefer ANTS would encountex' sUbstantive difficulties
`in implementing our proposal on it.)
`.
`.
`
`',l'ermina.
`(Explanatory notes: ANTS is an acr onya for ARPA Network
`Support
`system;
`it was developed at
`the Oenter , for Advanced
`Oomputation (CAO), University of Illinois. ELF is not an acronym
`(it
`is said t~ be German for "eleven"); it was designed at the
`Speech Oommunications Re~earcn L~b
`santa Barbara,
`(SOW~),
`Oalifornia.)
`
`THE RIGID FRONT-END ALTERNATIVE
`
`the
`the popular View of
`Referring baCK to the mOdel above,
`asterisks
`is
`to haVe the front-end system simulate a well known
`device for each Host (trpic~llY 6 remo~e
`jOb entry station a10n#
`the lines of the 200UT on the CUC 6600), effectivelY requiring no
`SOftware change~ on
`the nost Bys~em.
`characterize
`thiS
`~e
`approach as "rigid" because an iMmediate implication is that the
`Host system is constrained to handle data to and from the ne~work
`onlY
`in
`faShions Which its system alread¥ provides.
`(~.g., i f
`you SimUlate a cal'a reader, your data will necessarily ~e treated
`as batCh inpu~;
`if a
`terminal, necessarilY as time-sharing
`input.) NOW, it may be argued that Host softw~re changes are onlY
`being
`shunned
`in order to "get on the air'! quiCklY, ana 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 alternatve
`exists which
`is essentially as quick to implement an~ does not
`reauire the waste motion of constructing kno~n-dev1ce
`simulation
`hardware ana software for eaCh new Host, only ~o eventually avoid
`the simUlation in vne Host.
`
`rigid
`the
`for
`be Claimed
`~dvantage Which ~i~ht
`The maj~r
`a.pproach other
`tnan qUickneSS to implement WOUld be
`front"end
`embarrassing i£ true.
`That
`is,
`the possibility eXists
`that
`the _"new" Hosts i operating systems or system programming
`eith~r
`staffS a.re so intractable that avoiding Host Software Changes
`is
`a neceSsity
`rather than a desire. We certainlY hope neither is
`the case ana hbVe no reason to believe it to be so, but we must
`acknOWledge
`that such possibilities eXist as meta-issues to this
`report.
`
`-
`
`
`

`

`Page
`
`DISADVANTAGES Of THE RIGID f"ONX-END ALTERNATIVE
`
`some amp11flcatlon.
`The rigidity argument sketcned above merits
`The major disadvantage of interfacing with tne Host onl~ in fixed
`waYs lies in a l~ss of functionality. Granted that "Teln~t"
`arid
`be
`functions
`can
`performed
`(though we
`have " aeep
`"RJ~"
`reservations about file transfer) by simulating a
`known device
`there are more things in practice and ill theory than just using
`the Hosts l
`time"sharing and batch monitors.
`"Teleconferencing"
`is an
`instance WhiCh
`comes
`immediatelY to mind. Graphics is
`another. Neither iits naturallY
`into
`the setting a
`typical
`operating
`system
`is
`liKelY t~
`assume
`for
`a Telnet or RJE
`connectioll. Further. the ARPANET is just beginning to evolve -a
`view of "process-to-process" protocols where cooperating pr6gfams
`on dissimilar systems communicate over network sockets 1n a
`true
`Use oi
`socketa as
`interprocess communication media.
`It is
`difficult to conceive of viewing a (simUlated) line printer as an
`aostract "port" witnout consideraole contortion of the extant
`operating system.
`To attempt
`to
`summarize
`this cluster of
`a simulation of a known device may be cheaper than a
`objections,
`large enou~h number of Phone calls, but it~s not networking.
`
`For that matter, i~ is bY no meanS clear that the goal Of no Host
`sOftware chan~es can even be met.
`In the case of one particular
`system on the ARPANET Where a PDP~l~ was employed as a front end
`to a PDP~10, one of the authors discovered that on attempting to
`interrogation as vo
`lo~in oVer t~e net he was confronted by an
`the ~ype of
`terminal he was at ~~ the front end having been
`attached at the wrong point in
`the PDP-lOIs
`terminal handlirig
`code.
`<Being
`a battle-scarred veterin of Telnet pro~ocol
`development, he gave suitable answers for describing
`a
`qNetwork
`Virtual ~erminal". 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 nalf-duplex
`terminal"
`things
`really got confused}. As it happens, he later found himself in
`the neighbOrhOoa 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 ~ersonnel
`were both appreciative and cooperative, and although we have not
`had occasion to verify it, we assUme that the site
`is prooablY
`now usable
`from
`the ARPANET. The important point, though, is
`that oper~ting systems tend to make extenSiVe, often unconscious,
`assumptio~s about their operatin£ enVironments. This observation
`is particUlarlY true When it comeS to
`terminal
`types,
`ana
`the
`problem
`is
`that
`there
`is Simply no guarantee that the several
`~ystems in questio~ COUld even "do the right thing" if they Were
`a known device -- unless, of course,
`front-ended
`bY simulatin~
`the simUlation o~ the device in the mini Were s~ painstaking that
`all we'd get WOUld be an expensive way of adding an RJE station,
`period.
`
`

`

`Page
`
`4
`
`a
`tning,
`For one
`Less ~b$tract considerations also applY.
`mini-c6mputer -- even with "thirQ-generation" software -- 15 no~
`as free
`and
`convenient an
`environment
`to program 1n
`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 Hosts in order to perform
`their tasks. For that matter, it is clear that if personnel from
`the SeVeral Hosts are barred
`trom actiVe participation
`in
`to
`the
`network
`there will
`be
`natural
`(and
`attachin~
`Understandable)
`groUndS
`for
`resentment of the "intrusion" "the
`network will appear
`to be;
`systems programmers also
`nave
`territorial emotions, it may safely be assumed.
`
`the
`that
`On a still more practical level, it should oe noted
`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-ll configuration ~han
`WOUld otherwise be reasonable.
`And
`although
`there are o~her
`reasons
`for arguing that each front-end processor ough~ to oe as
`bi~ a configuration as POSSible, we must aCknOWledge ~hat · dollars
`do m~tter.
`Also on the ~op1c of numbers, it should be further
`noted that the line speedS available for known~device simula~ioris
`can be qUite
`low.
`The
`200UT, for example, is on a 4~OO oaUd
`line, Which
`is
`rather a mismatCh With
`a
`' baUd
`50,000
`communications
`sUbnet.
`(Of course,
`there's alwa~s th~ 40,800
`baud line into
`the 6600
`but it isn't expected
`to - nave
`inteX'active devices 6n it, so the extant software won't send the
`data
`to
`the "right Place" •••• ) And
`no experiencea ARPANET
`orotocol desi~ner" 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
`uUbious
`of
`fUlfillment.
`
`to poin~ out
`After all . th~t, it is perhaps gratuitouslY cruel
`still another
`level. of diffiCUlty, but we feel qUite stronglY
`that i~ shoUld be addressed.
`For,
`it must be admitted,
`the
`Question must be
`aSked as
`to wno Will do
`the fron~-ena
`implementations. Thia sort of
`thing
`is scarcelY Within ~he
`~urview of CAC or SCRL. But, as Will. be urged in APpendix 2, it
`is of the utmost
`importance
`that Whoever performs
`the
`taSk
`already have ARPANET· expertise,
`for we know of no case wnere
`"outsiders" have succeSSfUlly come aboard withou~ havlrig become
`"insiders"
`in
`the process, wnich is neithel' an easy nor a cost
`effectiVe Way to proceed.
`
`In li«ht of the aboVe, it is at least reasonable to consider an
`alternative
`to
`the
`rigid front~end approach, for : regardless of
`the wei~ht
`the
`reader may attaCh
`to an~ partiCUlar c1~ed
`in _t ot a l
`at
`least suggest
`tnat
`the
`di~advant~~e,
`~heY
`known-device simUlation tactic is not a panacea.
`
`

`

`THE FLEXI~LE FRONT-END ALTERNATIVE
`
`Our alternative approach is based on a principle Which ac~uallY
`has been around since at least a nlonth before the ARPANET began
`running User
`and Server Telnets on
`a
`regular basis.
`The
`orinciple
`is
`that it woula be nice
`to off-load as mUCh as
`possible Of the NCP from the Host, because Hosts are supposea
`to
`have better ttlings to do With their cpu CYCles than field control
`messages from other Hosts -- especially When 90% Of
`the control
`messages are m~relY ALL (ocate) commands. ThiS inSight led ~o the
`notion that all a Host "really" has to do
`is associate SOCKets
`with
`processes
`(and,
`of course, pass data along
`sociket
`connections). ~nd the fleXible front-end approach
`is no mote
`tnan an UPdating Of theSe 1971 ideaS to the following: Drop the
`hard and fast goal that there will ~e NO changes to Host software
`in
`favor 6f the more realistic ~oal of making MINIMAL changes to
`the Host;
`attaCh
`the
`front-end proc~ssor
`to any convenient
`hi~h-s~eed "channel"(
`"port"
`"mUltiplexer"
`"line"
`I
`I
`I
`I
`"cable"); le~ the front-end processor handle the NCP; define " an
`extremelY compact protocol for the Host ana front-end to follow
`(the H-FP); and let the Host H-FP mOdUle distribute
`the data
`appr6priatelY within its operating system, because "the H-FP Will
`make it clear Where the data should go and if you have to r~m the
`data int6 the teletype bUffers. it~a still cleaner than trying to
`do inter~r6cess communication over a card reader.
`(The H-FP
`is
`detailed in less bald terms in APpendix 1). Now that mignt -sound
`rather' uncompromising -- and almost surelY sounds rather cryptic
`but betWeen
`the advantages
`it engenders
`and
`the more
`comprehensive description WhiCh tOllows, we
`feel
`that it aoes
`represent a
`superior basis for solving the overridng problem of
`how best to attach "new" Hosts to an ARPA-like net.
`
`ADVANTAGES OF THE FLEXIBLE FRONT- END ALTERNAT IVE
`
`is
`end alte~natiVe
`The primary adVantage Of the fleXible front
`preciselY its fleXibility: Although minimal implementations maY
`be envisioned on given Hosts. the most minimal of implementations
`is st~ll as pOWerfUl as the rigid tront-end approach; and as the
`need for more functions is perceived. they may be codea for quite
`eaSilY With our approach.
`This is so becaUse programs in the
`Host can II~et ~heir h~nds on" data from the net (and Bend data ~o
`in a natural iaSh{on •• it i. not "t he case that onlY
`the net)
`thOSe thin~s done OR a giVen system With the data
`from,
`saY,
`a
`card reader. can convenientlY be done here.
`rhUS, in contr~st to
`the rigid front-end approach. the flexible front-end approach His
`Indeed,
`it should be noted that a major "real"
`networking~.
`ARPANET server site has expressed an interest in implementing the
`H-FP based on s6me five minutes i worth of blaCkboard explanation
`with two o~ . the authors.
`
`

`

`-----------------------------------------_. ~~
`page
`6
`
`Another advantage of our approach is th~t it involves personnel
`at
`the various new sites
`in the process of coming aboara the
`network.
`Not
`only
`does
`this ·
`have merit
`invo~vement
`psychologicallY
`(if Known-device
`simulation Were employed, tne
`network coUld represent an alien intrusion forced upon
`them,
`~o
`Site
`sYstems
`tYpes), but it is alSO technicall~ preferable to
`haVe the per-si~e coding done bY "experts", Which would not be
`the case
`if ~he per~Bite tailoring were done exclusiV1Y in the
`mini. Recall the PDP"lS to PDP-10 attempt discussed earlier.
`That case maY
`fairlY be Viewed
`as one of the front ending's
`haVing been Performed in i~norance of , tne conventionS of ooth t6e
`Host's operating system and Of the ARPANET? Not ' onlY ShOUld that
`sort Of thin~ be avoided bY the expedient of inVOlving experts on
`the
`target operating systems in the process of attaChing to the
`networka@ but there are practical considerations as well: We
`estimate that adding a minimal Host-Front ~nd 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
`torsee
`SchedUling advantages
`in addition
`to
`the more abs~ract oneS
`already asserted. Further,
`it ought
`to De
`a more
`friendlt
`environment to prbgrarn in on the H6st than in the mini.
`(This is
`not to saY the ELF does not appear to be a
`gOod
`enVironment
`to
`program in; ratner. it is to make the "ObVious" claim tha~ 1f the
`biK sYstems did not furnish convenient programming environments
`we WOUldn't have them.)
`
`further
`touched on earlier, another point which bears
`AS
`is
`the area of
`flow control.
`The Known-deVice
`examin~tion
`simulatioll approach appe~rs to assume
`that
`this
`too will be
`handled by
`the m1n1,
`and that the SimUlation will be aw~re of
`WhateVer flOW contrOl diScipline the Host and the PhYSical deVice
`beill£
`simUlated tollow. HoWeVer: When the one deVice "eVerYbodY
`knows" will be
`simUlated
`(CDC
`200UT)
`operates on
`a
`4800
`line.
`and
`the IMP subnetwork operates on 50~o60
`bit-~er-second
`bps lines, some attention must be paid
`to
`the m1smat~h
`especially
`in view of the fact that only one process in the Host
`is typicallY associated With a known deVice, but
`the net~orK
`actuallY
`tra.nsllii~s data on behalf of many processes.
`our
`approach, on the other hand, allows for
`a very direct,
`simple
`co~tr'o~ uiscipline to De imposed, Without getting inVOlved
`~loW
`in per-Host idiosyncrasies.
`(The option to go to more elaOorate
`_. potentiallY more efficient -- floW Control disciplines is also
`provided.) ThUs, we can simplY piCk the best line speed - a v a 1 1 ~ b l e
`on a particular Host. and a~tacn to it.
`.
`
`Notice one other level of _practical advantages: The mini!s H-FP
`modUle
`can b~
`furniShed along With its operating system bY the
`~ame network "insiders" Who are furniShing the operating
`system
`itself. _ ThuS 1
`a critical
`task need not be SUbjected to the
`perilS of sUbcorltracting.
`Indeed l
`tnis appro~ch lends itself far
`more
`reanilY to suocontracting than the other, if sUbcon~racting
`must be done fo~· the per-riost softw~re; for With the PDP-~l being
`
`

`

`~age
`
`7
`
`can be used in
`"insiderS"
`network
`aamel
`the
`almost always
`conjunction with site personnel to build Host H-FP modules e~ther
`through commercial consulting contr~cts or even from with~n the
`community.
`(The
`latter possibility exists
`oeCause
`ARPANgT
`systeM programmers is that -- althougri they
`an6ther
`fact about
`re~ent "invasions"-- they tend to erljoy getting
`insiae new
`arid
`different systems.
`if onlY to feel superior to them in con~rast
`With their own.)
`
`to
`tend
`The strengths of the flexible front-end approaCh, then,
`arise
`in exactlY those areas of weakness of the rigia front-end
`approach. perha~smost important of all,
`though,
`is
`the
`fact
`that it "makes sense" to almost every single experienced memoer
`of the ARPANET community with whom it has been discussed.
`~o, we
`might
`reasonl
`if
`the ARPANET
`is desirable,
`it is desirable
`becaUse of the ettorts of these Who made it work;
`and
`if
`they
`have gained insi~hto into networking in general in the process,
`their opinions deserve partiCUlar attention.
`
`R~COMMENDATIONS
`
`90%
`arounQ
`to be
`The protocol specified in AppendiX 1 is felt
`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 ena must apprise each other l for example. But we think
`that, in general
`tne protocol
`"WorkS".
`we
`stand Willing
`to
`discuss
`it with cognizant decision makers
`in
`the various
`interested organizations, and, for that mattef l
`to continue
`to
`debate it with our technical peers. At thiS stage, hoWeVer, the
`dominant conSideration WOUld appear. to be
`that
`the cognizant
`decisi~n makers avert
`the a~parent
`stampede
`to
`the
`rigid
`.
`front·end approach
`and
`evaluate
`the
`flexible
`front-end
`alternative
`in li~ht Of
`the preceeding arguments
`and
`the
`~ollowing protoc6l. specification.
`
`­
`

`

`APPENDIX 1. THE HOST-FRON~ END PROTOCOL
`
`ASSUMPTIONS
`
`the Host 1s
`to
`(FE)
`The Physical connection of the front end
`assumed t~ be ~ade over the "best" port (or Channel, 11n~, etc.)
`available on the Host, where "best" covers both
`line sp~ed
`ana
`Quali~y ot SOftware ava11~ble to Ph~sically manage the line. The
`choice Should be made bY site personnel.
`Hardware
`interfacing
`is assumed to be straignt!orwara; it is, at leas~, no
`capabillt~
`more c~m~lex for the H-Fp than f~r known-device simulation.
`The
`connection
`is assumed to be SUfficientlY closelY coupleu that a
`simple. explicit aCKnowledgment
`H-FP
`command
`w11l
`oifer
`satiSfactory
`flow control. That is~ distances are assumed to tie
`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 check1rlg and flow control are not first-order problem~.
`
`On the software level, bUffering is assumed to be adequate in the
`Host
`to accept at
`least a fUll (6096 bit) IMP-IMP meassage ~­
`although the FE could prObably get around this constraint' 1£
`it
`absolutely had to. Given only a minimal H-fP, module 1n the Host,
`the FE Will allow the same leVel of Telnet ~na RJE fUnc~ioning as
`would the knownMdevice simulation, as follows: The FE will always
`Shield the Host from the NCP commands
`and
`tne
`simplex SOCKets
`they deai With, dealing
`instead with ~ 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 . her e,
`but
`some
`readers may prefer, to stUdy the
`commandS Detore continuing With the balance of this section.) For
`Telnet.
`SUbsequent an~lys1s may
`lead
`to a more
`~ltnough
`SOPhisticateO trea~ment~ the present' assumption is
`that
`the FE
`will normally
`refuse all "negotiated options"
`ana strip all
`Telnet control COdeS from the data it pasSeS to the Host
`(unlesS
`the H~st orders it to pass an unaltered telnet stI'eam)~ on a
`per~installation basis, the FE will also map fr6m Telnet ASC II to
`the H~stts desired character set. ~elnet "interrupt process"
`controlS are harldled by an ij-FP command, discussed below.
`'
`
`to have
`For RJE, because the ARPANET RJE Protocol is only known
`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 6n the given connection is to be
`treate9 a8 data in the format and
`joO contrOl language of its own
`"batch" system. Again, ch~racter set m~PPing will be available
`on a per-installation basis.
`
`For file tranSfer, however. a further assumption must be made
`about Ho~t SOftware. This is bec~Use the FE cannot be expected
`
`

`

`page
`
`2
`
`tne Host
`if
`therefore,
`system;
`to manipulate the Host~s file
`wishes to participate in file trans£el' ac~ivities its HwFP mOQule
`must be able to access the Ho~t's file system
`for both
`sending
`and
`receiving ii~es.
`A~ain~ the F~ will be able ~o Shield the
`Host from the details of the underlying protocols
`to a
`large
`extent; but the Host must be able to handle FIP "stor" and "retr"
`commands, which will be passed over
`the
`(single) ' connection
`opened between
`the FE
`and
`the Host for file tranSfer.
`lFTP
`"USer" and "pass" commands might alSO
`be deSsirable.
`As ~ith
`Telne t,
`the FE Will manav.e the Various Network sockets inVOlved
`so as to all6w the Host to operate on onlY the H-FP connection,
`and will again optionallY per~orm Character set mapping. Note
`tnat 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 approprlate
`points within
`its operating
`sYstem Where
`terminal
`I/O ' is
`expected. distribute RJE data in like manner, and When it' i~ able
`to ~~ so handle FTP as sketChed aoove anO amplified on oelow.
`It
`alao on
`a when-desired basis,
`support calls from its
`~ill,
`system~s user pr~cesses for unspecified purposes I/O on ARPANET
`sockets
`to allow
`for
`such
`functions as telelconfel'encing and
`o~her process
`to process eXPlOitations Of ~he
`Net.
`our
`oVerriding assumption is that the initial H-FP modUle for a giv~n
`Host
`(Which does not
`require FTF .
`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 nas been
`Sketched here and will be returned to after the H-FP commandS are
`described.
`
`FORMAT OF THE OOMMANDS
`
`terms of
`in
`All communication between FE ana aost is performed
`fieldS Of the several commands are one or
`H-FP commandS.
`The
`more "bytes", Where a byte is a per-iclstallation parameter Of b,
`9, 12, ~6~ 18, 32, 36~ 48, 60, or 64 oit wldth, according to tfie
`coding convenience of the ~iven Host's H-FP module
`implementers?
`(6 bit bytes are not supported because they do not offer enough
`room t6 express all
`the values anticipated
`for certain code
`fiel~s; machines With 6 bit internal byte structures can specifY
`12 bit H-FP bytes and still be able to use
`their natural cyte
`oriented instructions.) Values for fieldS will be right-justified
`Within their (potentiallY SeVeral) byte WidthS.
`Note
`that
`the
`li~t 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 mac~ine is better ~uited
`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
`
`

`

`Page
`
`the binary representation of the nurober snown before its name
`the ne~t ~ection.
`(i.e., the command field is one byte w1de.~
`
`in
`
`COMNANDS
`
`(Note that all commands may be sent Oy either
`Host. )
`
`the F~ or
`
`the
`
`The BgGIN command establishes a "connection" between the Host a.nd
`the FE.
`Reg~rdle~s of internal representation, the duplex data.
`stream the connection represents will be referred to by the value
`specified in the next (INDEA) field; that is, for example, the FE
`a given Xelnet
`will Send input irom and
`receive output
`for
`"on"
`a given
`INDEX,
`eVen
`though
`it is actUallY
`c~nnegti~n
`mana~ing two NCP "sockets" for the purpose in its dealings with
`the Netwo:n~.
`
`the FE may
`ana
`the Host
`INDEX is a two-byte field. Both
`a)
`choose arbitrary values
`for
`it when openin~ connection with a
`BEGIN
`command
`implementations will
`probably
`~H·FP'
`s~mplY
`increment IND~X
`1 whenever
`they need
`a new connection};
`by
`hoWever, the value of 0 is reserved
`to
`applY.
`to
`the ~glooai"
`the FE -- thUS, When either
`connection betWeen
`the Host
`and
`machine "comes u~" the first thing it does is send
`a BEGI~
`for
`INDEX=O.
`(The
`END
`and ACKNOWLEDGE
`commands alsO follow this
`convention; for that m~tterJ there is no reason why
`the M~SSAUE
`command
`could not alsO, should it be desirect to extend thi tEfs
`functions in the future. At present, however, this is merely-a
`potential extension.) Note th~t all other fields should be set to
`o for IND~X 0 BEGINS.
`b) HOST is a
`the Host number
`It specifies
`field.
`two-byte
`in
`the next field. On FE to riost
`socket
`associated with
`the
`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.
`
`If SOCKET=l, a Telnet connection
`c) SOCKET is a four-byte field.
`is
`to be establiShed.
`If SOCKET=3, -an FTP connection is to be
`If SOOKET=5, an ARPAN~T RJE protocol connection
`establiShed.
`is
`to be. establiShed
`(no known current utility).
`If SOCKET=7?, a
`Host-specific connection is to be e~tabliShed for RJE/oatch~ · "Al l
`values are ~or connections for Unspecified purposes, to be
`~ther
`opened at the NOP level accordin~ to the OUNNEC~10N-T~PE field.
`that sockets 1. J. 5.
`and 71 are
`Note
`"known about" and
`special-cased oy the FE.
`.
`
`d) TRANSLATION-TYPE is a one-byte field. From FE to Host. it is
`informational.
`From Host
`to FE,
`it specifies character set
`mapping if desired, or characterizes the data to be
`transmitted
`o requests
`over
`the connection.
`specifies ASCII data; 1,
`I
`
`J
`~ .
`
`(
`
`

`

`Page
`
`4
`
`to
`from FE
`sent
`binary data (note that this value will not be
`Host _ under current assumptions,
`and that word size 18 to be a
`per-installation parameter); 2~ maPPing Of ASCII
`to/from
`lOcal
`ch~racter set. Other
`types Will be defined
`if needS are
`identfied.
`
`e) CONNEC~ION-TXPE is a one~bYte field. For FE to Host B~GINS it
`is
`injormational.
`For H~st to FE BEGINs it instructs the FE as
`to Which kind of NCP ccnnec vi.on discipline to folloW.
`1. requests
`a dUPleX connection (i.e., that the Initial Connection Protocol
`of ~he AR~ANEt be employed); 2~ a simplex connection (i.e.,
`that
`the
`ap~ropriate ARPANET
`"request
`for connection" Host-Host
`Protoc~l command 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 i~) user-level ~rograms on the Host begin
`to
`USe
`the Network.
`rE will open a-cit connections at the
`(The
`Network level unless otherwise directed.)
`
`2: ACKNOWLEDGE INDEX CODE
`
`in
`sent
`It must ue
`The ACKNOWLEDG~ command is multi-purpose.
`response
`to a.ll
`from
`the other machine (otner 11t1an
`comnanas
`ACKNOWLEDGEs~ of course), and is primarily used to
`indicate
`the
`success or
`failure of the command just receivea on INDEX. Note
`that tbis imPlieS that each MESSAGE on
`a giVen'
`INDEX must be
`ACKNOWLEDGEd before the next can be sent.
`
`a)
`
`INDEX 18 as abOVe.
`
`is a
`indicateS SucceSs
`CODE=O
`field.
`tWO-byte
`CODE
`I
`b)
`recentlY
`received for INDEX.
`the
`command most
`acceptance ~f
`CODE=l indicates failure I rejection of the most recent command.
`(E.g.,
`it a MESSAGE,
`bUffering was unavailable so the other
`machine must retransmit; 1£ a BEGIN,
`the
`indicated protOCOl
`I
`SOCket cann~t
`be
`serviced.) CODE=)
`indicates an
`invalid or
`inactive INDEX has been Used. CODE=4 indicates (Host to FE) that
`to be · per~ormed on the connection just o~ened.
`no
`is
`macipin~
`Other Values
`(for
`such meanings
`as "~oreign Host
`dOWn",
`reqUested"
`and
`the
`like) Will be aSSigned ~s
`"Undefined
`type
`idef! ti~1ec.i.
`
`3: MESSAGE
`
`iNDEX COUNT PAD TEXT
`
`The MESSAGE command is employed for the transmission of data.
`
`a)
`
`lNDEX is as above.
`
`b) COUNT is a tW~-byte field Which specifies the number of cit a
`field.
`Of data in the
`llEXT
`
`­
`

`

`Page
`
`.s
`
`Its width is a per-installation
`c) pAD is a l-to-n-bYte field.
`parameter used
`to enable
`the TEXT
`field
`to start on a word
`boundary if the local H-FP implementers so desire.
`(This is not
`a kindness, but it's alSO a placeholder if we decide to go
`onlY
`to a flOW control meChanisa inVOlVing sequence numbers.~
`
`It
`is coincidental.
`d) TEXT is a field Wherein byte structure
`consists of COUNT bits of data
`to be
`sent
`to the process
`implicitly associated with INDEX by. a BEGIN
`command
`(which has
`not been ENUed).
`
`a: INTERRUPT INUEX
`the Host,
`to
`the FE
`from
`The INTERRUPT command, when sent
`indicates
`th&t an