f OF
ILLINOIS LIBRARY
'AT URBANA-CHAMPAIGN
ENGINEERING
lunrvmr
The person charging this material is responsible for
its returp t£> the library frgmwhich it was withdrj
on or ^before the Latest D$gft(££| below.
Theft, Lla'i 4|| iri$|n|
nary action and may resainrfal
II Telephone Center, 333-8400
UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN
L161— O-1096
10. 5¥ ENGINEERING LI8RARV C-^y^^
w Mm
fjl (. 3 <L. UNI V: ITY OF ILLINOIS
UXBANA, ILLINOIS
w
wmammm
I
UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN
URBANA, ILLINOIS 61801
she Ubrery of ttie
CAC Document Number 230
CCTC-WAD Document Number 7511
Networking Research in Front Ending
and Intelligent Terminals
OFFLOADING ARPANET PROTOCOLS
TO A FRONT END
by
John D. Day
Prepared for the
Command and Control Technical Center
WWMCCS ADP Directorate
Defense Communications Agency
Washington, D.C. 20305
under contract
DCA100-76-C-0088
The person charging this material is re
sponsible for its return to the library frorr
which it was withdrawn on or before the
Latest Date stamped below.
Theft, mutilation, and underlining of books are reason
for disciplinary action and may result in dismissal fron
the University.
Center for Advanced Computatic
University of Illinois at Urbana-Ch
Urbana, Illinois 61801
11982
September 30, 1977
Approved fo
r Release: _\ ^xJ*^** T*\ - A"
Peter A. Alsberg, Prin&i
pMf
L161— O-1096
Digitized by the Internet Archive
in 2012 with funding from
University of Illinois Urbana-Champaign
http://archive.org/details/networkingresearOOdayj
Table of Contents
Page
Summary 1
Background 1
Offloading the Telnet Protocol 1
Offloading the File Transfer Protocol 2
Offloading Other ARPANET Protocols 3
Introduction 4
Host-to-Front-End Protocol 5
Future Work 6
General Characteristics of Offloading 8
Two General-Purpose Process-to-Service Protocols 12
Offloading the Telnet Protocol 14
Offloading the User Telnet Application 15
Offloading the Telnet Protocol Implementation 17
Offloading the File Transfer Protocol 24
Offloading the User FTP 26
Offloading the Server FTP 35
The File-Access Process-to-Service Protocol 40
Offloading the Network RJE Protocol 43
Offloading the User RJE 43
Offloading the Server RJE 45
Offloading Teleconferencing 47
Offloading Network Graphics Protocol 48
References 57
Table of Contents
(continued)
Page
Appendix 1. Program Access Process-to-Service
Protocol Specification 61
Appendix 2. File Access Process-to-Service
Protocol Specification 79
Appendix 3. ARPANET Host-Host Process-to-Service
Protocol Specification 119
Appendix 4. Network Virtual Terminal Process-to-Service
Protocol Specification 145
Appendix 5. User FTP Process-to-Service
Protocol Specification 185
Appendix 6. Server FTP Process-to-Service
Protocol Specification 221
Summary
Background
Under contract DCA100-76-C-0088, the Center For Advanced
Computation of the University of Illinois at Urbana-Champaign is investigating
the capabilities of network front ends. As a part of this contract, an
experimental network front end (ENFE) is being developed to interface a
WWMCCS H6000 to the ARPA Network and to conduct experiments with a host-
to-front-end protocol (HFP) . In this project, the HFP and associated
higher level process-to-service protocols are used in offloading network
access and Telnet facilities from the host to the front end. The ENFE
necessarily implements only one of many possible ways to offload Telnet
facilities. There are also other network facilities - particularly file
transfer - which one might like to offload. In this document we present
a broad survey of offloading strategies for the most important ARPA
Network facilities. This survey should be useful as a basis both for
the future design of expanded front ends and for quantitative studies to
determine optimal offloading strategies.
Offloading the Telnet Protocol
The ARPANET Telnet protocol provides a standard method for
interfacing terminals and terminal-oriented processes to each other.
Three key ideas went into the development of the Telnet protocol:
1. the concept of a network virtual terminal (NVT) ,
2. the principle of negotiated options, and
3. a symmetrical view of terminals and processes.
A Telnet implementation must handle the translation between real terminal
data representations and the NVT representation, the negotiation of
options, and the opening and closing of network connections. Connection
handling can best be handled in the front end. Translation can be done
in either the host or the front end. The best place to handle any
particular option depends on the characteristics of the option. In this
document, we discuss in detail the trade-offs involved in different
degrees of offloading and provide a brief analysis of the potential for
offloading each of the Telnet options. We also discuss which process-
to-service protocols are needed to implement the various schemes. The
symmetry of this protocol allowed us to develop a new process-to-service
protocol (the network virtual terminal PSP) designed to efficiently
implement an intermediate level of Telnet offloading. (The maximum
offloading strategy adopted for the ENFE was implemented with two separate
PSP's - one for the user side and one for the server side.)
Offloading the File Transfer Protocol
The ARPANET File Transfer Protocol (FTP) consists of two major
sections: a command-and-response section and a data transfer section.
The File Transfer Protocol is inherently asymmetric. Commands are sent
from the User FTP to the Server FTP to provide for user authentication,
to specify parameters for data transfer, and to request service. We
have identified two major aspects of FTP that are candidates for offloading:
the data transfer process and the bookkeeping and marker handling required
for restarting a transfer that has aborted. Since FTP makes use of the
Telnet protocol, the Telnet functions can also be offloaded. We found
that for User FTP there are eight possible offloading schemes that
differ from one another in important ways.
The offloading of Server FTP presents an even more complicated
problem. File systems in the host must be distinguished from file
systems in the front end. For another thing, Server FTP is not the
simple sequence of stages which characterizes User FTP. (An exception
seems to be the data translating and reformatting functions, which we
believe should generally be assigned to the front end.) We have therefore
confined ourselves to examining the individual FTP commands, classifying
them as to whether they must be handled in the host or can be handled in
the front end. In some cases (e.g., user authentication) a command is
likely to be handled by both the front end and the host.
For offloading FTP, we have designed three new process-to-
service protocols: a User FTP PSP, a Server FTP PSP, and a File Access
PSP. The last provides a general facility for transferring files between
host and front end. This facility should also be useful for purposes
other than offloading FTP.
Offloading Other ARPANET Protocols
Although our major contractual obligation was to study the
offloading of FTP (and Telnet as a natural conjunct of this) , we also
looked briefly at three other protocols: Remote Job Entry (RJE) , Teleconferencing,
and Network Graphics.
RJE makes heavy use of FTP; thus in studying FTP we have
covered the major points of interest in offloading RJE. There are a few
functions, of course, specific to RJE itself; these in general can not
be offloaded.
There is no ARPANET Teleconferencing Protocol as such. However,
we felt that teleconferencing is a sufficiently important network service
to be included in this study. Our conclusion is that teleconferencing
can and should be entirely offloaded, provided that the front end has
its own file system. If the file system of the host must be used, all
of the teleconferencing functions should still be placed in the front
end, with the File Access PSP used to read and write files when necessary.
We also find the Network Graphics Protocol highly suitable for
offloading. An exact assignment of duties, however, would depend heavily
on the capabilities of the graphics terminal, the host and the front
end.
Introduction
Network software is a significant burden on large hosts
connected to a resource sharing network. This burden might be lessened
through the use of a network front end. A network front end is a mini-
computer interposed between host and network. Some network software
functions could be "offloaded" to the network front end. This study
explores what network software functions could be offloaded to a network
front end. The Host- to-Front-End Protocol (HFP) [19] serves as the
vehicle for this study. Familiarity with HFP is assumed.
Connecting a large computer to a packet-switched network
requires a rather large investment in the development or modification of
network software. The host-to-network interface or protocol must be
implemented. An end-to-end protocol is required for general interprocess
communication. These programs are complex and, if the operating system is
unsuited to networking, may be large. Modification of the operating
system is often necessary. Moreover, in order to make network services
available to the user a host must implement one or more higher level protocols
Examples of higher level protocols are virtual terminal protocols, file
transfer protocols, remote job entry service, graphics protocols, etc.
But the network software burden on a host is not only in large one-time
costs for software development, but also in large recurring costs for
the processor, memory, and channel time consumed by the network software,
and in software maintenance. It has been hoped that most of this burden
could be offloaded to a relatively inexpensive network front end. A front
end could also transform network communications to make them more suit-
able to the host. Standardization of the front end would allow the same
system to be used to front end a variety of hosts. This would save
development and modification costs. On the other hand, tailoring the
front end to a specific host would improve performance. There is clearly
a tradeoff between these two goals.
Host-to-Front-End Protocol
The vehicle for the present study is the Host-to-Front-End
Protocol (HFP) [19]. This protocol can be divided into three major sections:
1. a link protocol for control and communication on the actual
physical connection between the two machines,
2. a channel protocol that provides a set of error-free, reliable,
logical channels between processes in the host and services in
the front end, and
3. a family of process-to-service protocols (PSP's) that provide
the means for offloading the network protocols.
The channel protocol defines a set of Command and Response
Messages. Each Message has a header field containing control information
and a text field containing data. Four pairs of Commands and Responses
provide communication between the host process and the front-end service.
The PSP's use the text fields of the channel Commands and Responses to
send PSP commands and responses between the process and the service. The
channel Commands and Responses are:
The BEGIN Command and Response are used to establish a logical
channel between the host and the front end.
The END Command and Response are used to terminate a logical
channel.
The TRANSMIT Command and Response are used to transfer data.
The EXECUTE Command and Response are used to send requests
out-of-band with the TRANSMIT Commands and Responses.
Each PSP is defined in terms of the channel protocol. A
PSP defines how the text field of each channel protocol Command and
Response is used for a particular service.
A PSP represents a class of offloading strategies for one
or more protocols. The six PSP's are:
1. The Program Access PSP, which provides a general facility by
which a process in the host may invoke a terminal-oriented
program or system command in the front end.
2. The File Access PSP, which provides a general facility for
moving bulk data between the host and the front end. It is
used in offloading FTP or similar protocols.
3. The ARPA Host-Host PSP, which provides access to the ARPANET
Host-Host protocol implementation in the front end.
4. The Network Virtual Terminal PSP, which provides low-level
process-oriented classes of offloading of the Telnet protocol.
5. The User FTP PSP, which provides low-level process-oriented
classes of offloading of the user side of the File Transfer
Protocol.
6. The Server FTP PSP, which provides classes of offloading for
the server side of a File Transfer Protocol.
Future Work
While this study explores what could be offloaded, it does
not determine what should be offloaded. A given installation will
attempt to provide a particular class of service to its users; for
example, a timesharing service, a data management service or an
archival service. The installation may have to handle a large number
of terminals or perhaps only a few. Because of the finite resources
of the front end one may not be able to offload everything and still
provide adequate performance for the preferred services. For example, a
timesharing service supporting a large number of terminals and not much
bulk transfer might maximize the offloading of Telnet and minimize
response time. On the other hand, an archival service or a data manage-
ment service might maximize the offloading of FTP and minimize the off-
loading of Telnet. The nature of these tradeoffs must be investigated.
A methodology for determining how an installation should configure its
front end must be developed. Similar work has been done for satellite
graphics processors [18, 34, 35] . This work might be extended and adapted
to the offloading problem. Also, the modeling framework [16] recently
developed at CAC could be used to aid the investigation of these questions.
General Characteristics of Offloading
It is possible to discern a pattern in the way protocols
could be offloaded. This pattern is related to the symmetry of the network
protocol. A symmetrical protocol is one whose operation is identical for
both sides. The ARPA Host-Host and Telnet protocols are symmetrical.
In the Host-Host protocol no distinction is made between source and
destination or between user and server. Either side may initiate the
connection. The passing of data from one host to another is treated
identically regardless of direction. In Telnet no distinction is made
between terminals and processes. On the other hand, the FTP protocol
is not symmetrical. One side (User) must initiate the connection, generate
commands and receive responses; while the other side (Server) receives
commands, performs the indicated task and sends responses.
As one would expect, symmetrical protocols offload in one way
and asymmetrical protocols offload in another. For a symmetrical protocol,
a single PSP is used for offloading; for an asymmetrical protocol two
PSP's are required - one for each side.
Schemes for offloading the user side of an asymmetrical protocol
show one pattern and those for offloading the server side show a distinctly
different pattern. .
This is a consequence of the structural differences between
the two sides. The user side is simply a sequence of stages. A message
from the user is transformed successively by each stage, e.g., the user
interface, the protocol interpreter, the Telnet interface, and the
NCP. But on the server side, the protocol interpreter must perform host-
specific operations. On the server side, these host-specific operations
are the crux of the matter. While the sever side has stages analogous
to those of the user side, they are of less importance, particularly
with respect to offloading.
As a general principle, the structure of the user side of an
asymmetrical protocol favors offloading in terms of stages. Thus, for
the user side, there are the following offloading strategies:
1) Offload everything, leaving a simple process in the host
which relays data between the user and the front end;
2) Leave the user interface in the host;
3) Offload nothing at this protocol level.
There may be variations on these three strategies, but as major classes
they always appear.
The structure of the server side of an asymmetrical protocol
favors offloading in terms of the operations. Most of these operations
deal with the handling of protocol commands. (See figure 1.) Some
operations must be done in the host, some must be done in the front end.
Some can be done either place. Thus the question of offloading strategy
is reduced to those cases for which there is a choice. It is then a
question of the relative advantage or disadvantage of having each such
operation performed in the host or in the front end. Since offloading
an operation to the front end may not only affect the performance of the
front end in undesirable ways, but may also require more complex mechanisms
to control the offloaded operation from the host, the net gain to be
realized by such a strategy must be carefully determined. Large variations
in operating system architectures make it difficult to determine which
operations should be offloaded without careful investigation of individual
cases.
10
PSP's may also differ by being location-dependent or location-
independent. Most are location-dependent. The process or user on whose
behalf a service is performed is located in the host and the service is
in the front end. However, there are some PSP's, such as the File
Access PSP, which make the distinction between a user and a service but
do not require their association with the host or front end.
11
Two General-Purpose Process-to-Service Protocols
Two of the PSP's used in this work to offload network software
are not associated with a particular network protocol. One is the
Program Access PSP and the other is the File Access PSP.
The Program Access PSP (see appendix 1) is a general purpose
protocol that combines some of the functions of a virtual terminal
protocol with a simple mechanism allowing host processes or users to
invoke programs or commands in the front end. The Program Access PSP
(PA-PSP) can be used to provide a direct connection from the user's
terminal to a front-end program with minimal interference by the host.
Depending on the nature of the terminals and the operating system in the
host, the process side of a PA-PSP may have to carry out such operations
as:
querying the user for usercode and password,
handling break characters from the terminal,
flushing data going to the terminal,
handling half -duplex terminals,
diverting binary or character data to auxiliary devices, and
modifying terminal parameters that control echoing.
Of course, the more items from this list that are required,
the less the savings to be gained by using this PSP. Also, since this
PSP may communicate with the front end system at the level of the user
command language interface, it will be inappropriate for use by processes.
The File Access PSP (see appendix 2) is a general purpose
protocol that facilitates the movement of files or bulk data among the
host, the front end and the network. It allows the host to access the
front-end's file system or vice versa, and the host to transfer data
12
between its file system and the network. The File Access PSP (FA-PSP)
allows the user to access any point in a file and supports a mechanism
for restarting file transfers. This mechanism is compatible with most
File Transfer Protocols.
13
Offloading the Telnet Protocol
The ARPANET Telnet protocol provides a standard method for
interfacing terminals and terminal-oriented processes to each other.
The protocol is based upon three ideas:
1. the concept of a Network Virtual Terminal (NVT) ,
2. the principle of negotiated options, and
3. a symmetrical view of terminals and processes.
When a Telnet connection is established, each end is assumed
to terminate in an NVT. The NVT represents a canonical terminal. It
was designed to strike a balance between being overly restrictive and
overly inclusive. The principle of negotiated options provides the
mechanism by which terminals and processes that find the NVT too restric-
tive may enhance its properties [23]. Such options include changing the
echo mode, the line width, or the page size, and setting tabstops. For
a more complete description of the protocol and the current options, the
reader should consult references [4-13,17,20,23-31,36,37].
In most systems there are two major uses of the Telnet protocol.
First, it is used as a general terminal-oriented communication medium.
Second, a host may have a local interactive program (User Telnet) that
uses the Telnet protocol to connect a local user to a remote host as if
that user were directly connected to the remote host. Those aspects of
the protocol itself that may be offloaded are character translation,
connection manipulation, and some of the options. The User Telnet
application program in a user host may offload all of the above func-
tions and the user interface to the User Telnet program. The section
below takes a closer look at how the offloading may be done.
14
Offloading the User Telnet Application
There are three basic schemes for offloading the User Telnet
Application: maximum offloading, placing the user interface in the
host, and placing everything in the host. (See table 1.)
Scheme
Functions
Functions in
PSP's
Number
in the Host
the Front End
Used
1
Local terminal handling
User Interface
PA-PSP
Relay Process
Telnet
Go-Aheads
Connection handling
2
User Interface
Telnet
NVT-PSP
Local Terminal Handling
Connection handling
Relay Process
Go-Aheads
3
User Interface
Telnet
Local Terminal Handling
Relay Process
Go-Aheads
Connection Handling
ARPA-HH
Table 1. User Telnet Offloading Schemes
For the maximum offloading scheme (see figure 2), the Program
Access PSP is used. As noted above, this scheme requires a "relay"
process in the host to move data between the user's terminal and the
program access service (PAS) module in the front end. There are two
disadvantages to this scheme. Firstly, as noted above, the more func-
tions required of the relay process, the more complex the relay process
must be and the less that might be saved. In fact, the relay process
may become so complex as to require a user interface for requesting
information from the user. This is exactly the part of Telnet that the
PA-PSP was intended to offload. Secondly, processes in the host that
wish to use Telnet must use a human- oriented interface. This may be
unwieldy and overly complex, and in some cases impossible. In these
cases the Network Virtual Terminal PSP (NVT-PSP) should be used.
15
cr3
RELAY
PROCESS
HOST
PROGRAM
ACCESS
MODULE
FRONT END
c^Z]
TELNET
USER
INTERFACE
TELNET
Figure 2
Maximum Offloading of User Telnet
In order to support some Telnet options, the relay process may
have to map them into local terminal parameters. The best example of
such a case is a system that wishes to support the remote controlled
transmission and echoing (RCTE) option. When the option is negotiated,
the terminal handler in the host must be notified of the change in
echoing and transmission. It may not be possible to handle this case at
all with the PA-PSP scheme, but the NVT-PSP is capable of handling it
easily.
The Network Virtual Terminal PSP (see appendix 4) provides the
facilities for the second offloading scheme shown in table 1. The user
interface is placed in the host and uses the NVT-PSP to access the User
Telnet process in the front end. (See figure 3.) The only problem
created by this scheme is that two possibly incompatible user interfaces
will be required, one in the front end and one in the host. The advantage
of this scheme is that it provides a process-oriented interface to the
16
TELNET
USER
INTERFACE
HOST
£3
FRONT END
TELNET
USER
INTERFACE
TELNET
Figure 3
Telnet User Interface in the Host
host side. Thus programs don't have to decipher responses intended for
a human. Some systems may use both the maximum offloading scheme (for
the high use User Telnet application) and the NVT-PSP for use by resource
sharing programs. Also, systems that require a rather complex relay
process to implement the PA-PSP are perhaps better off using just the
NVT-PSP. Since the NVT-PSP and the Telnet protocol are both symmetrical,
the details of using this scheme to offload the User Telnet application
are identical to the offloading of the Telnet protocol itself.
Offloading the Telnet Protocol Implementation
The functions of the Telnet implementation are manipulating
network connections, negotiating Telnet options, mapping between local
and network representations, transmitting data over connections, han-
dling special control functions, and interfacing remote terminals so
that they appear as local terminals. (Since the protocol is symmetrical,
this is true of both the User and Server sides). The offloading scheme
17
represented by this model places connection manipulating and data trans-
mitting in the front end. The interfacing of remote terminals so that
they appear as local terminals must be done in the host. The scheme is
flexible in that the remaining functions (option negotiation, special
control functions, and translation between local and network representa-
tions) may be implemented in either the front end or the host, depending
on local installation constraints. Typically the translation will be
done in the front end.
There are several Telnet control functions that one would like
to consider offloading. These are Interrupt Process, Break, Are You
There and Abort Output. Since for all of these except the last the
effect of the control function is on the process itself, the most that
can be done is to ensure that the control function arrives at the
earliest possible moment. This is done by sending it to the host via
the out-of-band EXECUTE Command.
In the case of Abort Output a little more can be done. When
the NVT service in the front end receives an Abort Output control func-
tion, it should pass the control function to the host via the EXECUTE
Command. Since this HFP Command is sent out-of-band with respect to the
data, the Abort Output will be sent to the host as early as possible.
The front end can then respond to the Abort Output control function
according to the Telnet protocol by sending a Host-Host Protocol INS
command associated with this connection to the remote host, flushing any
data it has buffered for transmission to the network and continuing to
flush data until a Telnet Data Mark is received from the host. The
front end may send a Telnet Data Mark to the remote system as soon as it
has flushed all queued data or it may wait for the Data Mark from the
host. (If it does the former, it should not pass the Data Mark received
18
from the host on to the remote system.) When the host receives the
Abort Output control function, it should flush all data it has queued
for the front end, and send a Telnet Data Mark to the front end. (Note:
Neither side should request the HFP Channel Protocol to flush data. The
Telnet protocol states that an Abort Output flushes only data, not
control functions, and a channel-level flush does not distinguish
between the two.)
An installation may take either of two basic approaches to
offloading the Telnet Options. It may offload nothing, in which case
the Telnet service in the front end need only reformat the data stream,
perhaps do character translation, and handle the network connections.
Or, the installation may wish to offioad as much as possible (given its
host's characteristics) in which case the front end must also be able to
negotiate and execute some of the Telnet options.
Unfortunately, it is not possible to say definitively for some
of the Telnet options whether they should be offloaded or not. Table 2
can be used as a guide to how easily the various options may be offloaded.
In most cases, two attributes of each option determine whether
or not it can be offloaded:
1. An option may or may not affect the host's terminal-handling
parameters.
2. An option's taking effect may or may not require synchroniza-
tion with a particular point in the data stream.
If an option affects the host's terminal-handling parameters,
then, although some of its processing may be offloaded, some processing
will have to be done in the host.
If an option requires synchronization with the data stream, it
may be very difficult, if not impossible, to offload.
19
Option Name
Telnet
Option
Num.
Host
Dep.?
Coord
w/Data
Stream
Can be
Offloaded?
Approximate Message Size
4
no
no
yes
Binary Transmission*
0
yes
yes
no
Byte Macro*
19
yes
yes
yes
Data Entry Terminal*
20
yes
yes
maybe
Echo*
1
no
yes
no
Extended ASCII
17
no
yes
yes
Logout*
18
yes
no
no
Output Carriage Ret. Dispos.
10
no
no
yes
Output Formfeed Dispos.
13
no
no
yes
Output Horz. Tab Stops
11
yes
no
no
Output Horz. Tab Stops Dispos.
12
no
no
yes
Output Linefeed Dispos.
16
no
no
yes
Output Line Width*
8
1
no
maybe
Output Page Size*
9
1
no
maybe
Output Vert. Tabstops
14
yes
no
no
Output Vert. Tabstops Dispos.
15
no
no
yes
Reconnection
2
no
yes
yes
RCTE*
7
yes
yes
no
Status*
5
yes
yes
some
Suppress Go Ahead*
3
no
no
yes
Timing Mark
6
yes
yes
no
Table 2. Classification of Telnet Options
Offloading these options is discussed in further detail in the text.
20
Table 2 lists the current ARPANET Telnet options. Those
options marked with an asterisk are discussed below in greater detail.
For the rest, the table indicates whether they can be offloaded. Note
that all options that are not supported by the host may be offloaded;
i.e., the front end can refuse negotiations without involving the host.
Binary Transmission. In most cases, this option cannot be
offloaded. However, the fact that it has been negotiated may be of
interest to the service module in the front end. If the front end has
been doing (or normally does) some translation tasks for the host, it
will be necessary to coordinate the beginning of binary data with the
cessation of such translation.
Byte Macro. If this option is supported and any other options
or functions are offloaded, then this option must be offloaded. This
option provides a means for mapping arbitrary strings into one byte.
Therefore, when this option is in effect, the macro expansion must take
place at the earliest point.
Data Entry Terminal (PET) . It may be possible to offload all
or part of this option depending on the nature of the host system. If
the host supports only one form of data entry terminal, then the front
end can map many DET option subcommands into the form required by the
local terminals or programs.
Echo. In general, it is not possible to offload this option,
since the process in the host which is connected to this terminal may
wish to echo characters other than those typed. However, there are
cases where it might be desirable if the front end did handle this
option for certain kinds of hosts.
For example, consider computers that support only half-duplex
terminals, such as IBM 360' s, Burroughs 6700* s, or Honeywell 6000' s.
Suppose that a user connects to such a host and asks it to DO ECHO. It
would be quite reasonable to have the front end handle the echoing and
present the host with an apparent line- at- a- time environment. This
would avoid many of the difficulties of trying to fit a line-at-a-time
system into a character-at-a-time mode.
Output Line Width. Once again the decision to offload this
option rests heavily on how line width regulation is enforced. If the
regulation of line width is done by simple "line folding", then this
function may be performed by the front end. However, if regulating line
width requires more fundamental adjustments or more sophisticated action,
it is quite likely that it will not be possible to offload this option.
Output Page Size. The decisions that are relevant for off-
loading this option are similar to the ones described for output line
width. Some systems may interpret the regulation of page size as fol-
lows. The maximum number of lines in a page is sent. If there is still
data to be sent, the sender pauses, waiting for an input from the user
indicating that he is ready to proceed. If this is the sort of regula-
tion desired when this option is negotiated, then it can be offloaded.
However, if more fundamental adjustments or more sophisticated action is
required, it may not be possible to offload it.
Remote Controlled Transmission and Echoing. The RCTE option
is meant as a more general mechanism to replace the Echo option. If
RCTE is used to replace the Echo option, then it may be offloaded under
the same conditions as the Echo option. Otherwise, offloading is not
possible and actually defeats the purpose of the RCTE option.
Status. Since not all options may be offloaded, it is neces-
sary to offload part of the Status option and to leave part of it in the
front end. It is suggested that the Status option be handled in the
following way:
22
When the service module in the front end receives a Status
option negotiation, it will respond favorably to the request by sending
a WILL STATUS to the sender. It will then relay the option to the host
in the normal manner and wait for a response from the host. When the
host receives the DO STATUS command from the front end, it will transmit
back to the front end the subnegotiation specifying the state of the
options it handles. When this subnegotiation is received by the front
end, it will insert into this subnegotiation the status of the options
it handles and then it will send the completed subnegotiation to the
foreign host.
If no options are supported in the host or if no options are
supported in the front end, then, of course, this procedure may be
avoided and the whole operation done in the front end or in the host,
respectively. Also, it is possible for the front end to know what
options are not supported and supply the default status information.
Suppr ess-Go-Ahead. In a sense, the Suppress-Go-Ahead option
is always off loadable. If the host always generates go-aheads, then it
is no problem for the front end to filter them out when the option is
negotiated. However, it is impossible for the front end to insert go-
aheads.
Telnet "Synch" Sequences. In some cases, searching for
"interesting" characters in the data stream may be offloaded. For
example, if the only characters deemed "interesting" are the Telnet
special characters, then this function may be offloaded. Or the front
end may be provided with a list (on either a static or dynamic basis) of
strings to be searched for. However, even if these functions are
performed in the front end, they must also be done in the host before
the "synch" sequence is received.) The only reason for offloading this
function is to increase the response to the user's request.
23
Offloading the File Transfer Protocol
The ARPANET File Transfer Protocol (FTP) [21,22] consists of
two major sections: a command-and-response section called the Protocol
Interpreter (PI) and a data transfer section called the Data Transfer
Process (DTP). The model used in the FTP specification is shown in
figure 4. The Telnet protocol is used to control the character-oriented
command connection. Commands are sent from the User FTP module to the
Server FTP module. These commands consist of a verb and single parameter.
The commands may be divided into three major classes:
1. access control commands (USER, PASSWORD, etc.),
2. transfer parameter commands (TYPE, MODE, etc.), and
3. service commands (RETRIEVE, STORE, DELETE, etc.).
USER FTP
- "I
r ■
SERVER FTP
r~
USER
INTERFACE
OPERATIONS
FTP
PI
USER
TELNET
SERVER
TELNET
FTP
PI
TO FILE
SYSTEM
1 DATA
1 FROM
DATA
TO
1 FILE
SYSTEM
DTP
DATA CONNECTION
DTP
FILE
SYSTEM
_ J
L _
1
Figure 4
ARPANET FTP Model
24
The Server FTP module responds to each command with one or more FTP
replies. A reply consists of a three digit code called a reply code and
one or more lines of text. The reply code makes the replies useful to
programs, while the text makes available more complete information to a
human user.
The transfer parameter commands are used to coordinate the
mechanism for transferring the data, and to describe the format of the
data to be transferred. Once these parameters have been agreed on, the
User and Server FTP's open a separate connection for transferring the
data. This is loosely referred to as the data transfer process or DTP.
There are two major aspects of FTP that are candidates for
offloading: the transfer restart mechanism and the data transfer pro-
cess. Although restart does require direct manipulation of the file and
this function cannot be offloaded, there is a fair amount of restart
marker "bookkeeping" that must be done. The front end can keep track of
the markers and the position they correspond to in the local file. The
primary functions of the data transfer process are manipulating the
data connection and doing any translation of the data into a form suit-
able for storage in the local file system or for sending to the remote
site. Offloading this translation function also means that, in most
cases, the transfer parameter commands that are used to define the
translation may be offloaded as well. Offloading translation should
provide considerable savings to hosts which transfer data to or from
computers unlike themselves, especially if the front end has efficient
bit-level operations.
The User and Server FTP offloading models described here use
the File Access PSP to offload the data transfer portion of the FTP. We
will note some of the properties of this File Access PSP as we describe
25
the models. We complete this section with a review of the requirements
for the File Access Service.
For systems that don't allow access to FTP from terminals
attached to the host, the File Access Service (FAS) module is the only
portion of software for a User FTP that must be in the host.
If file systems are supported in both the host and the front
end, then some way must be provided to distinguish a pathname as be-
longing to one or the other. Since remote filenames are the only ones
sent as parameters in the FTP commands, an offloaded User FTP in a
system with files in both the front end and the host only needs some
local mechanism in the user interface for distinguishing the two file
systems. Given this information as part of a command, the FTP user
interface or protocol interpreter can access the correct open file.
However, when an offloaded Server FTP which serves file systems in both
the front end and the host is involved, some property of the pathname
transferred in the data transfer command must be used to indicate where
the file is. Several techniques might be used. The pathname might be
prefixed with the characters HOST or FRONT END to indicate where the
file is. The front end might have a partial copy of the host's file
system directory indicating which files are where. Or, a non-technique
might be used: attempt to access the pathname on the front end; if the
attempt fails, try to access it on the host.
Offloading the User FTP
We have identified eight distinct schemes for offloading User FTP.
These are summarized in Table 3 and described in detail in this section.
1. Maximum offloading. This scheme is analogous to the
maximum User Telnet offloading scheme. As shown in figure 5, this model
uses the Program Access Service (PAS) to provide a full duplex path to
the User FTP in the front end. The File Access Service (FAS), which may
26
Scheme
Functions
Functions in
PSP's
Number
in the Host
the Front End
Used
1
Relay Process
User Interface
PA-PSP
FAM
FTP-PI
PTP-DTP
Telnet
Host-Host
Restart
FA-PSP
2
FTP User Interface
FTP-PI
FTP-PSP
FAM
FTP-DTP
Telnet
Host-Host
Restart
FA-PSP
3
FTP User Interface
FTP-DTP
UT-PSP
FTP-PI
Telnet
FA-PSP
FAM
Host-Host
Restart
4
FTP User Interface
FTP-DTP
ARPA-HH
FTP-PI
Host-Host
FA-PSP
FAM
Telnet
Restart
5
FTP-DTP
User Interface
PA-PSP
Relay Process
FTP-PI
Telnet
ARPA-HH
Restart
FA-PSP
6
User Interface
FTP-PI
FTP-PSP
FTP-DTP
Telnet
ARPA-HH
Restart
FA-PSP
7
FTP-DTP
Telnet
UT-PSP
User Interface
ARPA-HH
ARPA-HH
FTP-PI
Restart
8
FTP-DTP
User Interface
FTP-PI
Telnet
ARPA-HH
ARPA-HH
Table 3. User FTP Offloading Schemes
C
P
M
C
P
M
^^ — 1
RELAY
PROCESS
PROGRAM
ACCESS
MODULE
USER
FTP
DTP
r 1 —
r
FILE
ACCESS
MODULE
i
1
FILE
ACCESS
MODULE
1
HOST
FRONT END
Figure 5
Maximum User FTP Offloading
be synonymous with the data transfer process of the FTP, is used to move
the data to the proper file in the host. The FAS module must be able to
log a user into the host, open a file, read or write to it, abort a
transfer cleanly, handle restart reporting and positioning, return error
conditions on access, etc.
With this scheme, the PAS in the host and the FAS in the host
are completely independent. Any decision to transfer a file and thus
use the FA-PSP is recognized only by the User FTP in the front end.
Thus, use of the FA-PSP is initiated by the front end. There are
several ways to handle this: 1) the host can always have a BEGIN
Command outstanding for a connection to the FAS, or 2) the front end can
send a BEGIN Command to the host requesting service. The first case is
analogous to the mechanism used in the Network Virtual Terminal PSP.
However, there is one major difference. The user of the FA-PSP must be
logged in to the host in order to access the file. In order to minimize
28
the amount of negotiation required before a transfer can commence, the
BEGIN Commands should probably go to the host.
The other major requirements for this scheme are that the FAS
module must be able to report back to the User FTP in the front end that
all records on bytes preceding a restart marker have been actually
written onto the file, and that the service in the front end must be
able to translate a marker into a local file position in the event a
restart is required.
2. FTP user interface in the host. This scheme moves the FTP
user interface into the host. (See figure 6.) Several advantages
result from this configuration. First, since the user interface knows
when the user has requested a transfer, it may initiate the FA-PSP.
This strategy avoids the necessity of sending BEGIN Commands to the
host. The FA-PSP would use the "channel" connection type (see appendix 3)
to open the data connection on the default transfer sockets. For similar
reasons the protection problem encountered in the above model (i.e., the
user's having to log in to the host) is avoided. However, if the file
is in the front end's file system, the user may have to log in to the
front end. This would depend on the particular security and protection
arrangements.
Restart bookkeeping can be done in either the host or the
front end. If done in the host the FAS module in the host must be able
to pass information to the user interface to inform the user of the
markers. However, if the restart management is done in the front end,
the same mechanisms described above apply.
If there is no file system in the front end, then the FTP-PI
has very little to do except act as a relay for commands and responses
and initiate the data transfer process (DTP); the user interface can
29
t^3
HOST FILE
SYSTEM
FTP
USER
INTERFACE
FILE
ACCESS
MODULE
HOST
USER
INTERFACE
FTP
PI
DTP/ FA
MODULE
FRONT END
CT3
NETWORK
Figure 6
FTP User Interface in the Host
generate the actual FTP commands. If a file system does exist in the
front end, then the user interface must be able to tell the DTP (or the
DTP must be able to determine) in which file system the file to be
accessed resides.
The major disadvantage to this scheme is that two user inter-
faces are required to the FTP-PI (one in the host and one in the front
end), and there is every likelihood that they will not be the same.
The functions offloaded by this scheme are connection handling,
User Telnet, protocol state management, the DTP, and possibly restart.
3. Telnet and Data Transfer in the FE. This scheme (see
figure 7) primarily offloads the Telnet and data formatting functions.
It is necessary that the FTP-PI be able to explicitly coordinate the
data connection with the Telnet connection or always use the SOCK
30
r^
FTP
PI
USER
INTERFACE
=y-
rn
C
P
M
C
P
M
USER
FTP
PI
USER
TELNET
YTERFACE
J—
^
t
NETWORK
\
M
ST FILE
FILE
ACCESS
MODULE
DTP/FA
MODULE
YSTEM
HOST
FRONT END
Figure 7
Telnet and Data Transfer in the FE
command. If the PA-PSP is used to access Telnet then the FTP-PI must be
able to specify the contact socket to the Telnet user interface and it
must also be able to manipulate the human-oriented Telnet interface.
This is probably a good candidate for using the Network Virtual Terminal
PSP.
There must be communication between the FTP-PI and the FAS
in the host to specify the mode, type, etc., that will be used for the
transfer. The most reasonable way to handle this is to pass the infor-
mation through the FAS module in the host.
Although restart management could be handled in the front end,
it seems to be overly complex to consider such an assignment. (The host
31
FAS module would have to tell the front-end FAS module that data had
been written. Then the front end would have to pass that information to
the user back through the FAS module.) Thus, it seems most reasonable
to assume that restart would be done in the host for this model. Restart
management in the host could be done without additional complexity in
the FA-PSP. All that would be required would be for the restart report
to be channelled to the FTP-PI in the host rather than to send it back
to the front end.
This model requires two user interfaces and two FTP-PI' s if
access is allowed through the front end and the host. Problems might
arise since these may be significantly different.
4. Data Transfer in the Front End. In essence, this model
(see figure 8) merely offloads some of the connection manipulation and
data translation and re-formatting. Again it is necessary that the FTP-
PI in the host and FAS module in the front end be able to communicate.
This would be done through the FAS module. It is also necessary for the
FTP-PI to be able to coordinate its control connection with the data
connection opened by the FAS or to use the FTP SOCK command. If a file
system exists on the front end then it may be necessary for the FAS
module in the host to log in to the front end on behalf of the user.
Data Transfer in the Host. There is a variation of each of
the above offloading models that puts the data transfer process in the
host. We will consider each one in turn:
5. Only DTP in the host. This scheme (see figure 9) has many
of the same problems as its counterpart (scheme 1) . Since the relay
process is independent of the DTP, the front-end side of the FAS must log
in to the host. Thus BEGIN' s will generally go to the host. In this
case, however, more information (mode, type, etc.) must be sent to the
32
-IS
CO
£U
o
h-
X
(-«
to>:
o<f>
X
33
C
P
M
C
P
M
^ 1
RELAY
PROCESS
USER
INTERFACE
FTP
PI
^ u
^ '
^ '
r
DTP/ FA
MODULE
* >
FA
MODULE
u
ncT
CDftMT CTMH
Figure 9
Data Transfer in the Host
host before the transfer can commence. Of course, the DTP must be able
to report restart markers back to the front end.
6. User interface and DTP in the host. This scheme exhibits
most of the advantages of its counterpart. The DTP can be initiated by
the host, thus solving several problems. Restart management can be
handled by either side. The front-end side of the FAS becomes very
simple, since mode, type, etc., parameters could be supplied by the user
interface.
7. Telnet in the front end. The only problem this variation
presents is coordinating the Telnet connection and the data connection
if the default sockets are used.
8. Nothing is offloaded. Everything is done through the ARPA
Host-Host PSP [13]. If a file system exists in the front end, it will
be necessary to duplicate the DTP in the front end. Thus, in systems
where file systems exist in both, it is probably not worthwhile to
consider models with the DTP in the host.
34
The question may occur to some, why consider putting the DTP
in the host at all? The best example would be a situation where the
front-end's instruction set, although very well suited for message
switching, is not well-suited to the kind of bit-manipulations done by
the DTP. In such a case, considerable savings may be gained by putting
the DTP in the host.
Offloading the Server FTP
Unlike the situation for User FTP, the offloading of Server
FTP does not follow the clear functional lines of the FTP model. We
will use the model shown in figure 10 as a basic framework for the
descriptions of offloading Server FTP. This model can be used to
represent virtually all of the FTP offloading schemes. For the present,
we have placed the DTP functions of translating and reformatting the
data in the front end. Although these functions could be assigned to
the host (see User FTP scheme 5), the most likely assignment is to the
front end. We will consider this case later. The schemes described in
this section also use a File Access-PSP to move data into the host. The
requirements for this FA-PSP are virtually identical to the one described
above.
Offloading Server FTP is complicated somewhat by the fact that
a file system may exist on both the host and the front end. For the
Server FTP this means that some well publicized convention for dis-
tinguishing these two file systems may be required in the pathname.
Interestingly enough, when allocating functions between the
host FTP-PI' s and the FAS module, the division appears to be that file
management functions are performed by the FTP-PI and file transfer
functions are performed by the FAS module.
35
C
P
M
C
P
M
FTP
PI
FTP
PI
"-
>■
^
FA
MODULE
DTP/FA
MODULE
HOST
FRONT FMn
Figure 10
Server FTP Offloading
Thus, for FTP sessions that perform operations on the host
file system, the following functions must be in the host FTP-PI (see table 4) :
RENAME
DELETE
SITE
STATUS <arg>
LIST
NAME-LIST
ALLOCATE
Depending on the particular host operating system, it may not
be possible to assign the last three commands of this list to the host
FTP-PI. The LIST and NAME-LIST commands use the data connection to
transfer their results to the user. Some operating systems may require
that these functions be done by the host FTP-PI; but some implementations
may require that access to the data connection be gained only through
the host FA-PSP. Similarly, hosts which require an allocate before
36
APPEND
RETRIEVE
STORE
ALLOCATE
SITE
RENAME TO
STATUS arg
RENAME FROM
LIST
DELETE
NAME-LIST
Replies tc
all
of
the above
FTP Commands that Must Be Done in the Host
USER
ACCOUNT
PASSWORD
REINITIALIZE
BYE
BYTE
SOCKET
PASSIVE
TYPE
STRUCTURE
MODE
RESTART
STATUS
HELP
NOOP
ABORT
Replies
for
all of
these Commands
FTP Commands that Can Be Offloaded
Table 4. Offloading Server FTP
37
accepting a file may be better able to handle it if it is done through
the FAS. The FTP commands for user authentication (USER, PASS, and ACCT)
may or may not be offloaded depending on the security policy arrangement
between the host and the front end.
Although the FTP-PI in the host must report the success or
failure to the FTP-PI in the front end, it might be reasonable for the
host to generate a highly encoded reply and the front end to generate a
"proper" FTP reply. For configurations that support file systems on
both the host and front end, this strategy has the added advantage of
presenting a common reply repertoire to the network. The feasibility of
this mechanism will depend heavily on the particular host and front end.
Given that these functions must be done in the host, let us
consider the ones that may be in the front end:
Access Control Commands,
Transfer Parameter Commands,
RETRIEVE, STORE, APPEND, RESTART,
ABORT, HELP, STATUS, and
replies for all of the above.
It is not clear just how much of the Access Control Commands
(i.e., USER, PASS, and ACCT) can be done in the FE. This will depend on
the log-in arrangement between the front end and the host. It is possible
that a successful log in to the front end is equivalent to a successful
log in to the host. Or the front end may have to log the user into the
host by initiating a host FTP-PI in the user's name before indicating
success or failure of the attempt.
All of the Transfer Parameter Commands can be offloaded.
These commands affect the format and encoding of the data for trans-
mission and the manipulation of the data connection. It should be noted
38
that if these commands are not handled in the same machine as the DTP,
then some means must be provided for communicating their values to the
DTP or FAS. The DTP should be tailored to individual systems to trans-
late the data from the transmission form (determined by the MODE, TYPE,
STRUCTURE, and BYTE commands) to a form acceptable to the host. (Such
translations must be invertible.)
Because data transfers are accomplished by using the FA-PSP,
it is possible to do some of the processing of the RETRIEVE, STORE,
APPEND, and RESTART commands in the front end. The front-end FTP-PI can
interpret the command, initiate the file access process, and re-format
its responses into standard FTP replies.
It is also possible for the HELP command to be done in the
front end. Since the only function of this command is to return text
explaining the local effects of FTP commands and implementation pecu-
liarities, there is no reason this text cannot be stored in the front
end.
There are two forms of the STATUS command. One has a pathname
argument and returns information on a particular file. For files on the
host, this command cannot be offloaded. The other form of the command
does not have an argument and returns the status of a transfer that is
in progress, or, if no transfer is in progress, the current value of all
transfer parameters and the status of all connections. This function
can be offloaded to the front end.
The last major aspect of offloading FTP is handling restart
markers. There are two main cases to consider: data going out to the
net and data coming in from the net. Let us first consider data moving
out. If the front end can exert enough addressing control through the
FA-PSP, it is possible to allow the FAS in the front end to insert the
39
restart markers, thus offloading this function from the host. The only
requirement is that the FAS in the front end be able to address the same
point in the file when given the restart marker and commence the transfer
at that point. If this is not possible then these functions must be in
the host.
For data coming into the host, it is necessary for the Server
FTP to be able to report to the User FTP when the data associated with a
particular marker has been entered into the file, and to associate with
the user-specified markers a locally generated marker that can be used
to restart the transfer at this point.
A restart function can be provided in two ways: either the
FAS in the host can report the markers to the host FTP-PI, or they can
be sent back to the FAS in the front end and reported to the front-end
FTP-PI. If the latter approach is used, the FAS in the front end could
generate the local markers and send these to the remote host, while the
front-end FTP-PI handles the marker bookkeeping. If it is not possible
for the FAS in the front end to assign markers, then it must be done by
the host.
The File Access Process-to-Service Protocol
In each of the models just described we have postulated a
utility for moving files between the host and the front end. In this
section, we will review the operations that such a utility must be able
to perform and discuss some of the problems involved in its design. The
FA-PSP resembles the Bulk Transfer Facility described by [32] for EIN
or the File Access Protocol [15]. In the models described above, we
have indicated that the Data Transfer Process of FTP should be asso-
ciated with one side of the FA-PSP. Typically, the front-end imple-
mentation would perform the DTP functions, including the transformation
40
of data from the network format to a form acceptable to the host. The
host side typically would ensure that the data was written to or read
from the proper file.
The front end must be able to request that the host perform
the following operations:
open a file,
read data from the file,
write data to a file,
start a transfer from some point in the file (for restarts),
append to a file (this is a special case of the last point),
close a file, and
abort a transfer.
Some systems may also require the FAS module to
allocate space for a file, and
provide directory information.
In addition, the FAS module in the host must be able to pro-
vide a sufficiently rich set of responses to allow reasonable FTP
replies to be generated by the FTP-PI. The FAS module must also be able
to report to either the host or front-end FTP-PI that all data ahead of
a restart marker have been written on the file. Some implementations
may wish to have the front-end side generate restart markers for out-
going data. However, if marker assignment requires knowledge of the
data (i.e., record boundaries, etc.) it may have to be done in the
host.
A major concern in the use of the FA-PSP is how access control
is to be provided. The most obvious solution is to have the FA-PSP
"log-in" to the host on behalf of the user who initiated this session.
This raises the question of whether or not there are separate usercodes
for the host and the front end. As long as the only file system being
accessed is in the host, there is really no problem. The real diffi-
culties arise when there are file systems in both host and front end, so
that it may be desirable to have separate usercodes. For the time
being, resolution of this problem will have to be left as an installa-
tion policy decision.
Unlike most PSP's, the FA-PSP maintains two major communica-
tion channels. On the one hand there must be a channel for the data
that are moving between the host and the network, and on the other hand
there must be a channel for control and state information to be passed
to either the host or front-end FTP-PI. In the FA-PSP all data is sent
via TRANSMIT Commands and all Control information is sent via EXECUTE
Commands.
42
Offloading the Network RJE Protocol
This part of the study uses the ARPANET RJE Protocol (NETRJE)
as a basis for discussion. Although other RJE protocols have been
devised (the UCLA-CCN NETRJS [1] and the one proposed by Day and
Grossman [14]), the major points that must be considered are well
illustrated by the ARPANET protocol.
The ARPANET NETRJE protocol [2] is built on top of the Telnet
and File Transfer Protocols. By means of the User NETRJE program on his
local host, a user of NETRJE establishes a Telnet connection to a Server
NETRJE process at the host where he wishes to submit a job. (See figure
11.) The user then sends to the Server process appropriate commands to
log in, to describe where the job is that is to be submitted, to describe
how the job is to be transferred, and to describe what is to be done
with the output when the job is completed. The Server NETRJE process on
the foreign host then uses its User FTP program to transfer the input
file to the foreign host, and then may use FTP again later to send the
output back to the user. This protocol is very general and allows a
user to submit his input from one host, process it at a second, and send
the output to a third.
Offloading the User RJE
For User NETRJE, the only offloading scheme (see figure 12)
that is at all interesting uses the PA-PSP to get to the NETRJE user
interface. (A scheme could be constructed that put the user interface
in the host. Such a scheme would then use Telnet either through the PA-
PSP, which would require some command- language emulation, or through the
Network Virtual Terminal PSP. In either case, the resulting models are
simplified versions of those considered in the User FTP section above.)
43
TELNET
CONNECTION
FTP CONTROL
CONNECTION
FTP DATA
CONNECTION
OR CARD
READER
Figure 11
The Model of the ARPANET RJE Protocol
TO LOCAL
RJE
c^3
RELAY
PROCESS
HOST
PROGRAM
ACCESS
MODULE
RJE
USER
INTERFACE
USER
TELNET
FRONT END
Figure 12
User RJE Offloading
44
Most of the offloading that can be accomplished for NETRJE
consists of the offloading of FTP. However, for an offloaded FTP that
uses the FA-PSP, there is an additional facility that the FA-PSP must
have in order to be used with NETRJE. Since the remote host will use
FTP to retrieve input and store output, the FA-PSP should be able to
access the card readers (or their agents) for input requests and to
access line printers or spooling queues for disposing of output.
Offloading the Server RJE
There is some difficulty in determining exactly how much of
the server function can be offloaded in any general way. Many RJE or
batch systems for contemporary operating systems are rather monolithic
in their structure. Therefore it is not clear how separable some
functions are from the whole. In fact, for some implementations Server
NETRJE may be a translator between the local RJE system and the network
conventions.
Assuming that functions are fairly separable, we notice that
NETRJE functions can be divided into two types: those used to control
the FTP and those used to control the RJE system. The FTP functions can
be offloaded to as great a degree as FTP can be. Since most RJE systems
are monolithic and the tables containing the information specifying the
disposition of the jobs are in the host, the RJE functions in general
cannot be offloaded. (See table 5.)
The offloaded Server NETRJE must be able to associate job-ID 's
with host pathnames or be able to direct output from the RJE system to
the FAS. Also, it must be able to direct input from the FAS to the RJE
system and associate it with the NETRJE session.
45
REINIT
OUT +
change"1"
ABORT (output)"1"
back"1", skip"1"
STATUS
CANCEL
ALTER
NETRJE Commands that Must be Handled in the Host
REINIT
USER, PASS*
INID,INPASS
OUTID,OUTPASS
INPUT, INPATH
ABORT
RESTART,
RECOVER, HOLD
NETRJE Commands that May be Handled in the Front End
Table 5. Server NETRJE OFFLOADING
It may be possible to offload these commands, depending on how user
authentication is handled.
Some systems may spool network output to the front end, in which
case these commands could be offloaded.
46
Offloading Teleconferencing
Most teleconferencing systems exist as programs, not protocols.
The only example of a teleconferencing system that is constructed as a
protocol is Calvin's [3], In this system, the user interface for the
system is located on one host and the conferencing system itself is
located on another.
Even though such systems are not protocols, they are important
network services. Let us consider how they may be offloaded. If the
front end has its own file system, then it is possible to offload the
entire teleconf erencer . If no file system exists or there is insuffi-
cient file space in the front end, then all of the conferencing func-
tions could reside in the front end and the FA-PSP could be used to write
the transcript in a file on the host. Given the structure of most tele-
conferencing systems, it appears that most aspects of the conference
management functions are sufficiently tightly related that they should
not be separated. However, sophisticated teleconf erencers that provide
the use of such facilities as graphics displays, simulation programs and
data management systems may allow greater flexibility in offloading.
Offloading Network Graphics Protocol
Although the Graphics protocol is, strictly speaking, outside
the scope of this document, we will consider briefly how it may be
offloaded. The ARPANET Network Graphics Protocol (NGP) is much too
complex to describe in detail. It is a general purpose protocol limited
to "calligraphic pictures, to moderate interaction demands, and to 'best
effort' attempts to generate the required graphics" [33]. Several
aspects of graphic systems, such as shading and animation, are not
included because of a lack of understanding of how best to model these
fairly new facilities.
To describe the NGP model we quote directly from the protocol
document [33]. (The figures have been renumbered to keep the numbering
consistent throughout the present document.)
"The philosophy behind the network graphics protocol can be
demonstrated by giving a model of a general-purpose graphics
system and combining it with the network model of Figure 13.
The model of the system is shown in Figure 14... To avoid
misunderstandings, and for the sake of defining terminology,
it is worthwhile to describe briefly each of the elements
of Figure 14:
1. The input devices — keyboard, stylus etc. — are
used by the operator of the application program to
provide data and to control the program during
execution.
2. The application data structure contains data,
basically nongraphical, relating to the application
program.
3. The input routines receive data from the input
devices, make appropriate changes to the application
data structure, and hand control to other routines.
4. The non-1/0 routines analyze and modify the
application data structure.
5. The output routines build a structured picture
definition from data drawn from the application
data structure. Effectively they define how this
data may be visualized for display purposes.
48
^^
DISPLAY PROCESSOR
a CONSOLE
SERVER HOST
USER HOST
Figure 13
A graphics application program (AP) running in one
computer (the Server Host) drives a display console
attached to another host (the User Host).
49
APPLICATION
^n
TRANSFORMATIONS
CONCAT
M
DIS-
PLAY
Application Program:
IN Input Routines
OUT Output Routines
NON 1/0 Application Routines
DATA Application Data Structure
Graphics Package and Hardware:
IR Interrupt Routines
BUILD Routines to build the SPD
SPD Structured Picture Definition
TRACE Routines to trace the SPD
CONCAT Concatenation routine
T&C Transformation and clipping routines
DCG Display code generator
TDF Transformed Display File
DGEN Display generator
Figure 14
A Conceptual Model of a Graphics Application Program,
a Graphics Package and Display Console
50
6. The structured picture definition defines the
entire picture to be displayed, part or all of
which may be visible on the screen. The picture
definition is generally made up of a number of
elements, representing parts of the picture known
collectively as subpictures; subpictures may them-
selves be made up of other subpictures. A familiar
type of subpicture is the symbol which is often
used many times within a single picture or subpicture.
Each reference or call to a subpicture element may
denote a transformation — scale, rotation, etc. —
to be applied to the subpicture.
7. The transformation routines apply the trans-
formations specified in the structured picture
definition and clip out information that lies off-
screen. Often an arbitrary rectangular viewport
is used as the clipping boundary instead of the
screen edge. These routines also handle the
concatenation of transformations necessitated by
multi-level structured picture definitions.
8. The transformed display file is essentially
what remains of the picture after transformation
and clipping. It is defined in the screen's
coordinate system and is generally stored in a
format that allows direct refresh or regeneration
of the picture. The display file contains
"primitives" that specify lines, dots and text
to be displayed.
9. The display generator generally includes
a vector generator and a character generator,
which transform the contents of the transformed
display file into signals that the display's
deflection system can understand.
10. The display itself.
"We shall now analyze Figure 14 to see how the system can be
implemented. The diagram illustrates three information
structures (an application data structure, the structured
picture definition, and the transformed display file) , and
three processes (the output routines, the transformation,
and the display generator) . The design of a general-
purpose graphics system requires specifying the roles of
all of these elements, with the exception of the application
data structure. Our examination amounts to asking: what
can the hardware do, and what does the graphics programmer
think he can do?...
"Most display hardware is "processor" hardware, capable
of implementing some or all of the three processes in
Figure 14. If, for example, a display processor is available
that implements transformations and display generation, then
the transformed display file is absent, and we can view the
51
hardware as "an interpreter of structured picture defini-
tions." If the available hardware has fewer capabilities
(e.g. no transformation ability), the picture is refreshed
from the transformed display file, and the hardware is "an
interpreter of transformed picture definitions." Or, if
the hardware is a storage-tube terminal that does not require
a display file for refreshing purposes, part of the display
generation process is a software process. (However, a
display file is still required, as we shall see below.)
"Determination of what the programmer can do is somewhat
more subtle, because the graphics system designer has
complete control of the facilities he presents to the
programmer. For example, the programmer of the system
shown in Figure 14 would think he was creating a struc-
tured picture definition: the output routines allow
him to create, modify, and delete elements of that struc-
ture. The remaining processes (transformation and display
generation) and structures (transformed display file, if
it exists) are inaccessible to the programmer; in some
sense, he thinks that a "display processor" is inter-
preting the structured picture definition in order to
generate a display. He cannot determine whether a
transformed display file exists, nor whether transforma-
tions are done in hardware or software, etc.
"If the structured picture definition is deleted, the
programmer sees a quite different set of facilities. The
output routines create (after transformation) a transformed
display file. The programmer now thinks that the hardware
is a "transformed display file interpreter." Again, the
programmer is unaware of the details of the display generator
process (for example, if the display is a storage tube termi-
nal, the display generator is a combination of a software
display-file interpreter and some hardware vector and char-
acter generators. If, on the other hand, the transformed
display file is used to refresh a display, the display
generator is presumably entirely in hardware) .
"The discussion suggests that relative device independence
can be provided if we permit two different kinds of output
information: (1) information for building structured pic-
ture definitions, or (2) information for building trans-
formed picture definitions directly. The first of these
is matched to high-performance displays such as the LDS-2
or LDS-1; the second to standard refresh displays such as
the IMLAC or GT-40.
"How does this relate to network protocol? We can essen-
tially view the UP [user program] as a "display processor,"
i.e. an "interpreter of structured picture definitions," or
an "interpreter of transformed picture definitions." The
network protocol is used to build and modify a picture
definition contained in the user host. Various UP options
are shown in Figure 15 (the dotted lines surround those
52
TRANSFORMED FORMAT
b) STORAGE TUBE
TRANSFORMED FORMAT
-• TDF -}• DGEN —/
r
STRUCTURED
C) HIGH FORMAT
PERFORMANCE
13.
STRUCTURED
FORMAT
El
BUILD
SPD TRACE
CONCAT
I
HfDGEN-^S-
•) STORAGE TUBE
m
BUILD SPD TRACE
teONCAT|
Figure 15
Various configurations for the user program.
Dashed lines surround processes implemented with hardware.
Hatched processes are omitted in the particular configuratic
53
processes that are implemented with display processor
hardware) . Figures 15a and 15b show the network used to
transmit transformed information; the UP uses this infor-
mation to build a display file for refreshing a display
or for updating a storage- tube. Figures 15c, 15d and 15e
show the network being used to transmit information for
building a structured picture definition; the UP is an
interpreter of a structured display file.
"Figure 16 illustrates some possibilities for the server;
the server can generate either structured or transformed
display information. In Figures 16a and 16b the program-
mer "sees" a structured picture definition; in Figure 16c
a transformed picture definition.
"In the protocol, the UP tells the SP [server program] which
kinds of format it can implement. It is perfectly possible
for the UP to implement both — the display images due to
each of the formats are merged onto the screen.
"The two different kinds of output format can be summarized
as follows:
Transformed
The protocol is used to build and modify a set of
"segments" (sometimes called "records") of a trans-
formed display file, stored in the user host. A
segment is a list of graphical primitives that
specify lines, dots and text to be displayed at
specific positions on the display screen. Indivi-
dual segments may be deleted or replaced; they
may be added to or removed from a list of segments
to actually display on the screen (this is called
"posting" and "unposting" segments). If a picture
is composed of many segments, changes to the pic-
ture can often be made by replacing one or two
segments; thus segmenting the display file helps
to reduce the amount of information that must be
transmitted through the network to effect a
change. Considerable experience with this type
of picture definition has demonstrated that device
independence can easily be achieved...
One advantage of transformed format is that the UP
can be kept very simple; no transformations need
be performed in the UH [user host] . A UP along
the lines of Figure 15a should be able to be imple-
mented in an IMLAC. The burden of transformation
is left to the SH [server host] , presumably a large
computer quite capable of being programmed to do
transformations .
54
o)
NON I/O
IN
OUT
lS
STRUCTURED FORMAT
b) r
» IN
NON I/O
OUT
[™r] ;
Hi_l
BUILD
SPD
n
CONCAT
Tac
TRANSFORMED FORMAT
TRACE
c)
TRANSFORMED FORMAT
Various configurations for the server program.
These mate with the user program configurations of figure 15.
55
Structured
The protocol is used to build and modify "figures;"
each figure is a collection of "units." A unit may
be a list of graphical primitives, such as lines,
dots and text; or it may specify a "call" on another
figure, together with a transformation to apply to
the called figure. The protocol can replace indivi-
dual units; altering a figure that is called in
several places may cause widespread changes to the
visible display. The structured format requires
(in principle) even less network bandwidth for
updates than does the transformed format; many
updates may involve changing a single transforma-
tion (e.g. to change the viewing transformation
for a three-dimensional object).
Although a structured picture definition can be
interpreted directly by a few display processors
that have transformation ability, most UP's that
implement structured format will perform the trans-
formation in software. . . This implementation is
relatively difficult, and certainly requires a
fairly powerful UH computer."
As one can readily see, of all the protocols considered here
this protocol is the most suitable for offloading. Figures 14, 15
and 16 provide us with a fairly good idea of how the protocol functions
should be placed. An exact assignment of duties, however, would depend
heavily on the capabilities of the graphics terminal, the host, and the
front end. Some work along these lines has already been done by Van Dam
[35] and Foley [18]. These two investigators have considered the problem
of how to best share the load for a graphics application between a host
and a dedicated satellite graphics processor. Further work would be
necessary to evaluate a system consisting of a host, a network front
end, and a graphics display with or without its own satellite processor.
56
References
1. Braden, Bob
1971, "Interim NETRJS Specification," RFC 189, NIC #7133.
2. Bressler, R. ; Guida, R. ; and McKenzie, A.
1972, "Remote Job Entry Protocol," RFC 407.
3. Calvin, James 0.
1974, "The Design and Implementation of an Interactive
Teleconferencing Environment," Undergraduate thesis, Case
Western Reserve.
4. Crispin, Mark
1977, "Telnet Logout Option," RFC 727, NIC #40025.
5. Crocker, D.H. and Postel, J.B.
1973, "Remote Controlled Transmission and Echo Telnet Option,
NIC #19859.
6. Crocker, D.H.
1974, "Telnet Output Carriage-Return Disposition Option,"
RFC 652, NIC #31155.
7. Crocker, D.H.
1974, "Telnet Output Horizontal Tabstops Option," RFC 653,
NIC #31156.
8. Crocker, D.H.
1974, "Telnet Output Horizontal Tab Disposition Option,"
RFC 654, NIC #31157.
9. Crocker, D.H.
1974, "Telnet Output Formfeed Disposition Option," RFC 655,
NIC #31158.
10. Crocker, D.H.
1974, "Telnet Output Vertical Tabstops Option," RFC 656,
NIC #31159.
11. Crocker, D.H.
1974, "Telnet Output Vertical Tab Disposition Option,"
RFC 657, NIC #31160.
12. Crocker, D.H.
1974, "Telnet Output Linefeed Disposition Option," RFC 658,
NIC #31161.
13. Crocker, D.H.
1977, "Telnet Byte Macro Option," RFC 729, NIC #40036.
57
14. Day, J.D. and Grossman, G.R.
1977, "An RJE Protocol for a Resource Sharing Network,
RFC 715.
15. Day, J.D.
1973, "A Proposal for a File Access Protocol," RFC 520.
16. Day, J.D.
1976, "Cost and Response Time Models for Network Applications,"
Internal Modeling Memo #14, Center for Advanced Computation,
University of Illinois at Urbana-Champaign.
17. Day, J.D.
1977, "Telnet Data Entry Terminal Option," RFC 731, NIC #40652.
18. Foley, James and Brownlee, Edward
1974, "A Model of Distributed Processing in Computer Networks
with Application to Satellite Graphics," Proceedings of ICCC.
19. Grossman, G.R.
1977, The Host- to-Front-End Protocol, CAC Document #219,
Center for Advanced Computation, University of Illinois
at Urbana-Champaign.
20. Mock, Tovas and Postel, Jon
1974, "Telnet Extended ASCII Option," RFC 698, NIC #32964.
21. Neigus, N.
1973, "The File Transfer Protocol," RFC 542.
22. Neigus, N. ; Pogran, K. ; and Postel, J.
1974, "A New Schema for FTP Reply Codes," RFC 640.
23. Postel, Jon
1973, "Telnet Protocol Specification," NIC #15372.
24. Postel, Jon
1973, "Telnet Option Specifications," NIC #15373.
25. Postel, Jon
1973, "Telnet Binary Transmission Option," NIC #15389.
26. Postel, Jon
1973, "Telnet Echo Option," NIC #15390.
27. Postel, Jon
1973, "Telnet Reconnection Option," NIC #15391.
28. Postel, Jon
1973, "Telnet Suppress Go Ahead Option," NIC #15392.
29. Postel, Jon
1973, "Telnet Status Option," NIC #16237.
58
30. Postel, Jon
1973, "Telnet Timing Mark Option," NIC #16238.
31. Postel, Jon
1973, "Telnet Extended-Option-List Option," NIC 16239.
32. Schicker, Peter; Duenki, Ann; and Baechi, W.
1975, "Bulk Transfer Function," INWG Protocol #31,
EIN/ZHR/75/20.
33. Sproull, Robert F. and Thomas, Elaine L.
1974, "A Network Graphics Protocol," NIC #24308.
34. Stone, Harold
1977, "Multiprocessor Scheduling with the Aid of Network
Flow Diagrams," IEEE Transactions on Software Engineering,
Volume SE-3, No. 1.
35. Van Dam, Andries; Stabler, George M. ; and Harrington, Richard J.
1974, "Intelligent Satellites for Satellite Graphics,"
Proceedings of IEEE, Volume 62, No. 4.
36. Walden, David C.
1973, "Telnet Output Line Width Option," NIC #20196.
37. Walden, David C.
1973, "Telnet Output Page Size Option," NIC #20197.
59
Appendix 1
Program Access
Process -to-Service
Protocol Specification
CAC Technical Memorandum #81
by
John Day
Steve Holmgren
61
Program Access
Process-to-Service Protocol
Specification
I. Service Code Number
II. Description of the Service
This document is a process-to-service protocol
specification as defined in the Host-to-Front-End Protocol (HFP)
Specification [ARPANET RFC 710]. It describes a process-to-
service protocol for the execution of, or attachment to,
arbitrary programs in the front end. The intent is to provide a
general mechanism that will allow the host to access terminal-
oriented front-end services. Examples of such services are User
Telnet and teleconferencing.
This protocol allows terminals directly connected to the
host to appear to the front end as if they were local front-end
terminals. This strategy for handling host terminals has two
advantages. Users are confronted with a common command language
and services can be almost completely offloaded to the front end.
The protocol described here assumes that the program
access service itself is completely offloaded to the front end.
The only software remaining in the host is a relay process that
passes properly formatted data between a host terminal or process
and the program-access-service module in the front end. HFP
63
DRAFT
6/23/77
PA PSP
Description of the Service
Messages are used for this data transmission.
For some implementations, the relay process software must
1 . ensure that security infornation is
properly transmitted in BEGIN Commands
(this may require querying the user for
usercode and password);
2. properly handle half-duplex terminals
(via the GO AHEAD facility);
3. transform interrupt characters into
EXECUTE Commands;
M . flush data when instructed to do so;
5. accept data from terminals with differing
character sets and properly transform
them for transmission to the front end;
6. divert binary or character data to
auxiliary devices; and
7. modify terminal parameters that
control echoing.
The more items from this list that a PA-PSP host implementation
must support, the less the savings to be gained by using this
PSP. Since most implementations will give the user of this
protocol access to the front end at the command language level,
it will be inappropiate for use by processes.
The only support that the relay process requires is the
ability to access the front end and to be accessed by host
terminals or processes. Some systems may experience difficulty
providing one interface that can handle both.
The program-access-service module must have the ability
to attach to and to execute user-level programs within the front
64
b/23/77 PA PSP
Description of the Service
end and pass data to and from the user-level programs and the
channel protocol module (CPM).
The program access process-to-service protocol uses HFP
Messages to carry information between the relay process and the
service module. A brief summary of the function of specific
Message types follows.
BEGIN Command
from the process
requests access to a program in the front end.
3EGIN Response
from the service module
a) confirms that access has been accomplished or
b) reports the reason for failure.
END Command
from either side
requests that communication with the other side
be terminated.
END Response
from either side
acknowledges that an END Command has been
received and that the proper action has been
taken .
TRANSMIT Command
from either side
transfers data to the other side.
TRANSMIT Response
from either side
acknowledges receipt of data from the other
side.
EXECUTE Command and Response
are not used in this protocol.
The details of the use of HFP Messages follow.
65
DRAFT
6/23/77
PA PSP
BEGIN Command
III? ftegsa^e Use
III A. BEGIN Command
II? A 1 . When sent
When a terminal or process in the host wishes to
execute a front-end program, which may be a service in its
own right, it will start up or attach to a host relay
process. The relay process will then send a BEGIN Command
to the program-access-service module in the front end. The
TEXT of the BEGIN Command will contain a front-end command
line formatted to installation standards. The command line
will specify the front-end program to be executed and will
provide any required parameters.
Ill A 2. Action on receipt
When a BEGIN Command is received by the program-
access-service module in the front end, the module will
attempt to execute or attach to the specified program.
Once the service module has completed a connection to the
program, it should issue a BEGIN Response to the host relay
process. Subsequent communications on this channel from
the relay process to the service will be directed to the
program .
Ill A 3. TEXT field syntax
Security: VARIAELE(?)
Command: VARIABLE(?)
Ill A 4. TEXT fjgld semantics
III A 4 a. Security
This field can be used by the front end to verify
the validity of the user and his access to the program.
The actual contents of this field are installation
dependent. If the security field is empty, the effect
is to connect the user to the front end at the pre-login
stage. The Command field will be ignored in this case.
Note: At this writing, not enough is known about
security in networks and front ends to make any
statement about the utility of validation at this point
in the system. This field is included in case some
systems require validation at this point.
Ill A 4 b. Command
For most front ends the Program Access PSP
provides general access to the front end command
language or a set of procedures callable by host users.
The command field will usually contain a string of
66
DRAFT
8/23/77
PA PSP
BEGIN Command
characters to invoke that
with any parameters in
would be typed by a user.
nmand or procedure along
form similar to the way it
Example:
run telnet
If the Command field is empty but the Security field is
not, then the effect is to log the user in to the front
end.
67
DRAFT
6/23/77
PA PSP
BEGIN Response
III E. BEGIN Response
III b 1 . When seat
The BEGIN Response is generated by the service when a
determination has been made as to the success or failure of
the BEGIN Command. The Status field in the HEADER will
indicate the success or failure.
When the process receives a BEGIN Response indicating
a successful connection, it may proceed to send and receive
data on the connection. When the process receives a BEGIN
Response indicating an unsuccessful connection, it should
perform the appropriate error recovery.
Ill, B 1. TEXT field syptax
Result:
FIXED(3)
XII B 4. TEXT field semantics
III B k a. Result
If the BEGIN Command was successful, this field
will have a value of zero. A non-zero value indicates
failure. The particular value indicates the reason for
failure. The Result values and their meanings are:
0 Success
1 Access to program denied
2 Illegal Command field format
3 Program not found
k Front end terminating service
68
DRAFT
8/23/77
PA PSP
END Command
III C 1. When sent
The END Command may be issued by the program-access-
service module or the host relay process. If sent by the
relay process, it usually indicates that the user has
requested that the front-end program be terminated and the
communication path be destroyed. The service may send an
END Command because of events external to the operation of
the relay process and the program or in response to the
termination of the front-end program.
Ill C 2. Action on receipt
When the relay process receives an END Command, it
should acknowledge it promptly with an END Response and
clean up any data structures associated with the
communication path. When the program-access-service module
receives an END Command, it should generate an END Response
and terminate the process associated with the Channel.
Ill C 1, TEXT field syntax
Cause: FIXED(3)
III C H. TEXT field semantics
III C 3 ?, Cause
This field indicates the reason for termination of
communi cation .
meanings are:
0
1
2
3
k
The values of the field and their
Normal completion of the proeram
Program failure
User requested termination
Unknown
Front end terminating service
69
DRAFT
6/23/77
PA PSP
END Response
III Pt ENP Response
HI D 1, When sept
The END Response is sent either by the relay
process or by the program-access-service module to
acknowledge that an END Command has been received and the
proper action taken.
HI D 2. Action on receipt
When an END Response is received, all dialogue over the
associated logical channel is complete. All Commands over
the logical channel will be ignored until the receipt of
another BEGIN Command referencing that channel.
Ill D 3. TEXT field syntax
The TEXT field in the END Response is not used in this
process-to-service protocol. The contents of the field
will be ignored.
70
8/23/77
PA PSP
TRANSMIT Command
III E. TRANSMIT Command
The description below assumes that a Go-Ahead facility is
needed for the host relay process to handle half-duplex
terminals. Not all installations will need this facility.
Those that do not should set the Control field in the TEXT to
zero and ignore the specification of how this field is
interpreted .
Ill 6 1. When sept
The TRANSMIT Command may be sent by either side to
transfer data. Data may be sent only when the communication
path is ESTABLISHED and the flow control discipline
permits. (See the HFP specification.)
HLE iLi AgtlPP on receipt
III E 2 a* Pv the relay process
When the relay process receives a TRANSMIT Command,
it will relay the contents of the Data field to the host
process or terminal. If the Go-Ahead bit is set to 0
for data going to the host, then the host may assume
that the front end has completed sending and the host
may now send any data it has. A Go-Ahead bit set to 1
indicates that the sender has more data to send and the
receiver must wait.
Ill E 2 b. By the program-access-?ervlce module
When the service module receives a TRANSMIT Command,
it will relay the contents of the Data field to the
program. If the Go-Ahead bit is set to 0 for data going
to the front end, then the front end may assume the host
has completed sending and the front end may send any
data it has. A Go-Ahead bit set to 1 indicates that the
sender has more data to send and the receiver must wait.
Ill e Li text field syntax
Control: FIXED(1)
Go-Ahead/More Data
Data: VARIABLE(?)
Ill E k. TEXT field semantics
III E 4 a. Control
The single bit in this field indicates whether or
not the sender of the TRANSMIT Command has completed
sending data. It is used to facilitate handling half-
duplex terminals connected to the relay process. The
71
6/23/77
PA PSP
TRANSMIT Command
receiver of a TRANSMIT Command with the Go-Ahead bit set
to 0 (default) should assume the sender has completed
sending data and that the receiver is now free to send
any data that it has. If the bit is set to 1 the sender
has more data to send and the receiver should not send
data at this time.
72
DRAFT
8/23/77
PA PSP
TRANSMIT Response
III F. TRANSMIT Response
The TRANSMIT Response is used as described in the HFP
specification .
73
DRAFT
6/23/77
PA PSP
SIGNAL Command
III G. SIGNAL Command
The SIGNAL Command is not used in the process-to-
service protocol. SIGNAL Commands may be generated by process
or service to request that the CPM carry out the appropriate
potion on the logical channel. (See HFP specification.)
Thus, the effect of the SIGNAL Command is restricted to the
logical channel (HFP) level.
74
DRAFT
8/23/77
PA PSP
SIGNAL Response
III H. SIGNAL Response
The SIGNAL Response is not used by either process or
service.
75
DRAFT 8/23/77 PA PSP
EXECUTE Command/Response
HI I. EXgCVTE Command,
The EXECUTE Command is not used in this protocol. If an
EXECUTE Command is received, an EXECUTE Response with Status
equals 67 (Unused Command) should be sent.
Ill J. EXECUTE Response
The EXECUTE Response is not used in this protocol except as
noted above.
76
DRAFT
6/23/77
PA PSP
Scenario
IV. Scenario
Let us consider how the Program Access PSP would be used
to offload User Telnet. Let us assume that the host relay
process does not have to implement any of the special functions
noted in Section II. The user at a terminal connected to the
host types:
"connect ILL-CAC"
The connect command starts the relay process and hands it the
parameter ILL-CAC. The relay process then generates a BEGIN
Command :
<BEGINXC>telnet ILL-CAC
(This installation does not use the security field.) The BEGIN
Command is passed to the front end. The Program Access Service
in the front end invokes the command line present in the TEXT
field and sends a BEGIN Response to the host:
<EEGlNXCXresult = success>
The User Telnet program is started and it attempts to open a
connection to ILL-NTS, and sends a message to the user which the
Program Access Service passes on to the host:
<TRANSMITXOAttempting connection to ILL-NTS
At this point the User Telnet program thinks it is talkincr to a
user local to the front end. The Program Access Service
maintains this charade passing messages back and forth to the
user connected to the host. From the point of view of the user
he is directly connected to the front end.
77
Appendix 2
File Access
Process -to -Service
Protocol Specification
CAC Technical Memorandum #102
by
John Day
79
File Access
Process-to-Service Protocol
Speci f icati on
T. Service Code Number
6
II. Description of the Service
This document is a process-to-service protocol specification
as defined in the Host-to-Front-End Protocol (HFP) Specification
[ARPANET RFC 710]. This protocol provides a general utility for
file access between the host and the front end. This protocol is
also used for offloading the data transfer portion of a network
file transfer protocol (either user or server). This protocol
also provides a general utility for file access between the host
and the front end.
The file access process-to-service protocol differs from
most others in that the distinction between the host side and the
front-end side disappears. For this process-to-service protocol,
one distinguishes between the side requesting service (the using
side) and the side providing service (the serving side). No
distinction is made as to which one is in the host and which in
the front end. In fact, a file access module (FAM) may be
constructed in such a way as to be both using and serving,
depending on how each channel is established, (i.e., on who sends
each BEGIN Command).
DRAFT
6/23/77
FA PSP
Description of Service
This specification describes a general file access utility
that allows a process in one system to open a file and read or
write data to or from any point in that file. The protocol
provides separate indices into the file for reading and writing.
These are called the read pointer and the write pointer.
Although the ability to address within a file makes restart
markers superfluous, protocols that don't explicitly allow
addressing may require their use. Since restart marker
"bookkeeping" might be offloaded, a set of operations are
provided for controlling it. Not all fields listed in the
descriptions of message use will be used in every case. Exactly
what fields are present in the various Commands will depend on
the offloading application. Details of FTP offloading schemes
using the file access process-to-service protocol are described
in detail in CAC Document 230 [1].
The facilities required by this process-to-service protocol
depend heavily on the particular use being made of it. The
maximum requirements would be access to the file systems of both
the host and the front end, and implementations of FTP, Telnet,
and an NCP in the front end (in the ARPANET case). The minimum
requirements for the ARPANET case would be an NCP in the front
end.
The file access process-to-service protocol uses HFP
Messages to carry information between a file access module in the
host and a file access module in the front end. A brief summary
of the function of specific Message types follows:
82
DRAFT 8/23/77 FA PSP
Description of Service
BEGIN Command
from the using file access module
requests that service be provided.
BEGIN Response
from the serving file access module
a) confirms the establishment of service, or
b) reports the reason for failure.
ENP Cofnand
from either file access module
requests the termination of service and
indicates the conditions for termination.
ENP Response
from either file access module
acknowledges the termination of service.
TRANSMIT Command
from either file access module
carries data between the using and serving file
access modules.
TRANSMIT Response
from either file access module
acknowledges the receipt of data.
EXECUTE Command
from the using file access module
requests of the serving file access module that
a) data transfer parameters be set;
b) a file be opened;
c) data be read from a file;
d) data be written to a file;
e) a read pointer position be set;
f) a write pointer position be set;
g) a network connection be opened;
from either file access module (depending on which
is data source and which is data receiver)
a) sets a restart marker window width,
b) acknowledges a restart marker, or
c) aborts a transfer.
EXECUTE Response
from either file access module
a) acknowledges the completion of actions
requested via an EXECUTE Command.
b) reports the reason for failure of an EXECUTE
Command; or
c) reports on the status of the network
connection.
DRAFT 8/23/77 FA PSP
Description of Service
III- Message Use
III A, PEQ1N Cpmmand
III A 1, When sent
A BEGIN Command is sent by the using file access
module (UFAM) to the serving file access module (SFAM) to
request that a channel be established for the transfer of
one or more files between the host and the front end.
Ill A ?. Action on receipt
When a SFAM receives a BEGIN Command, it will evaluate
its ability to satisfy the request specified by the
parameters in the TEXT field and reply accordingly.
Ill A 3, TEXT field syptax
Security: VARIABLE(?)
File Parameters: COMPLEX*?)
Pathname: VARIABLE*?)
Direction: FIXED(2)
Position: FIXED( )
Size: FIXED( )
Record size: FIXED( )
Data Parameters: COMPLEX(M)
Type: FIXED(3)
Mode: FIXED(2)
Structure: FIXED(1)
Byte size: FIXED(8)
Connection Parameters: C0MPLEX(8)
Control-bits: FIXED(5)
Init/Listen
Socket/Channel
Duplex/Simplex
Relative/Absolute
Unattachable/Attachable
Host: FIXED(32)
Foreign Socket: FIXED(32)
Messages: FIXEDM6)
Bits: FIXED(32)
Local Socket: FIXED(32)
Timeout: FIXED(16)
Byte Size: FIXED(8)
III A k. TEXT field, semantics
Since the file access process-to-service protocol may
be used in a variety of offloading schemes, the parameters
of the BEGIN Command are quite extensive. They fall into
four categories: Security, File Parameters, Data Transfer
Parameters, and Connection Parameters. These groups of
84
DRAFT
8/23/77
FA PSP
BEGIN Command
parameters will be present if the UFAM is remotely
controlling the functions of validating the user,
manipulating files, controlling the FTP Data Transfer
Process, or establishing network connections, respectively.
HI A 4 a, security
This field can be used to validate the requestor's
access privileges to the file or network resources. It
is particularly important to limit access to network
security objects such as local socket 1 . The
substructure and content of this field are installation
dependent .
NOTE: At this writing, not enough is known about
security in networks and front ends to make any
statement about the utility of validation at this point
in the system. This field is included in case some
systems require validation at this point.
Ill A M frt File Parameters
These parameters specify what file is to hn
transferred, in what direction, where the transfer is to
begin, and how long the file is. These parameters will
be present if the UFAM is in the front end and the file
is in the host, or vice versa.
Ill A M t> (1), Pathname
This field contains a locally recognizable file
name for the file which is to be transferred into or
out of the system in which the SFAM resides. If this
then the pathname will be specified
Note: It is an error to issue a
the EXECUTE Command (see below)
1 pathname.
field is empty,
at a later time.
Read variant of
before specifying
III A M b (2) . Direction
This field specifies the direction of the
transfer. The values are:
1 data is transferred toward the SFAM (write)
2 data is transferred toward the UFAM (read)
3 data is transferred in both directions
The default value of this field is 3 (both).
Ill A H b H), PosiUpn
The contents of this field specify where within
the file the transfer is to begin. This facility is
85
DRAFT
8/23/77
BEGIN
FA PSP
Command
used for restarting transfers and randomly accessing
files. The position pointer that is set is
determined by the contents of the direction field.
If the direction field specifies "both", then both
the read and write pointers are set to the position
indicated. The width of . this field and the units
represented by it are installation parameters.
Ill A » b (iQt Size
The contents of this field are used to indicate
the size of the file to be written into the file
system in the SFAM's computer. Some systems require
that space be allocated for a file before beginning
the transfer. The width of the field and the units
represented by it are installation parameters.
Ill A » b (5), Record 9Ue
The contents of this field specify the maximum
record size of the file to be transferred. This
field will only be present if such specification is
required by the system and the file is record-
structured. The width of the field and units
represented by it are installation parameters.
HI A M ct patfr Transfer Parameters
For offloading schemes in which the UFAM must
remotely control the FTP data transfer process, these
parameters are used to specify how the data is expected
to arrive from the network. It is assumed that the host
and front end have agreed on what form data will be
presented by each to the other.
Ill A » c (1), Type
This field indicates the type of data to be sent
in accordance with the classifications of the ARPANET
FTP. The values of the field and their meanings are:
0 ASCII - Nonprint
1 ASCII - Telnet
2 ASCII - Carriage Control (ASA)
4 EBCDIC - Nonprint
5 EBCDIC - Telnet
6 EBCDIC - Carriage Control (ASA)
7 Image
The default value of this
Nonprint) .
field is zero (ASCII
86
8/23/77 FA PSP
BEGIN Command
III A H C (2). Mode
The contents of this field indicate the mode in
which the data is transferred over the network in
accordance with the categories used in the ARPANET
FTP. The values of the field are:
0 Stream
1 Blocked
2 Compressed
The default value of the field is zero (Stream).
Ill A ** c H)t Structure
The contents of this field indicate the
structure of the file to be transferred. The
structures supported are those used by the ARPANET
FTP. The values are:
0 File
1 Record
The default value of the field is zero (File
structure ) .
Ill A ^ g m, Evte site
This field contains the byte size for data
transfer on the connection. If this field contains
zero (default), the byte size will be 8 bits.
Ill A M d. Connection parameter?
These parameters are used for offloading schemes in
which the UFAM must remotely specify the nature of the
network connection. For example, if the only parts of
FTP that are offloaded are Telnet and the Data Transfer
Process, the UFAM in the host would have to be able to
specify the parameters for opening the data connection.
Ill A 4 d (1). Control. bits
The bits in this field govern the kind of
connection to be established, the method of its
establishment, and the interpretation of the
parameters.
Ill A l.d (1) (a), InU/Ugten
When this bit is zero (default), the
connection is to be actively initiated by the NCP.
When this bit is one, the connection is to be
87
DRAFT 8/23/77 FA PSP
BEGIN Command
passively "listened" for by the NCP.
Ill A » 4 (1) (t>)t SocKet/channel
If this bit is zero, the logical channel from
the UFAM is to be established to a new ARPANET
connection. If this bit is one, the logical
channel from the UFAM is to be attached to an
already existing HFP channel (e.g., a channel
already established to the host-host service
module and therefore providing access to an
existing network connection.) The default value
is zero.
Ill k k * (1) (g), Duplex/Simplex
When this bit is zero (default), the
connection is to be full duplex and is therefore
to consist of two ARPANET connections (one in each
direction). When this bit is one, the connection
is to be unidirectional according to the gender of
the socket numbers supplied in the Foreign Socket
and/or Local Socket fields. The use of this bit
in specifying connection sockets is detailed in
table 1.
Ill 4 * <M1) (4). ReUUve/AbspJ.ute
This field affects the value of the socket
for the local connection. Sep III A M d (6) for
details .
Ill A 4 d (1) (e). Unattachable/Attachable
When this bit is one, the SFAM is requested
to make the logical channel available for
attachment by other service modules within the
front end (such as a data transformation service).
If this bit is zero (default), the SFAM is not
requested to make the logical channel available
for attachment within the front end.
Ill A 4 d (2), Host
This field specifies the network host with which
the connection is to be made. A value of zero in
this field indicates that the connection may be
established with any host on the network. A zero
value is valid only if the Init/Listen bit is one
(Listen) .
The Host field is parsed as;
8/23/77 FA PSP
BEGIN Command
Network: FIXED(6)
IMP: FIXEDM6)
Host-at-IMP: FIXED(8)
III A M d M). Foreign Socket
This field is used as follows to construct the
effective foreign socket (e.f.s.) for making the
connection .
Case 1. Foreign Socket field = zero.
Init/Listen bit = one. Foreign host
chooses the e.f.s.
Case 2. Foreign Socket field = zero. Init/Listen
bit = zero. The e.f.s. is one.
Case 3- Foreign Socket field i zero. The e.f.s.
is the contents of the Foreign Socket
field.
The default value of this field is zero. The
relationship between the e.f.s. and the foreign
sockets for the connection is defined in table 1.
HI A 1 d m « Messages
This field and the Bits field allow the UFAM to
indicate to the SFAM the flow rate desirable on the
data connection. The SFAM may use this information
in any way its implement ors deem desirable.
This field contains the number of ARPANET Host-
Host messages the UFAM suggests be allocated on the
data connection. If the value of this field is zero
(default), the SFAM chooses the number of messages on
its own. In some cases use of this field must be
coordinated with similar information provided through
other protocols (e.g., User and Server FTP process-
to-service protocols).
Ill A H 4 (5), Pita
This field contains the number of bits the UFAM
suggests be allocated for the data connection. If
the value of this field is zero (default), the SFAM
chooses the number of bits on its own. In some cases
use of this field must be coordinated with similar
information provided through other protocols (e.g.,
User and Server FTP process-to-service protocols).
Ill A ** d (fr)t local Socket
This field is used as follows to construct the
effective local sooket (e.l.s.) for making the
connection .
89
6/23/77
FA PSP
BEGIN Command
Case 1 .
Case 2.
Case 3-
Relative/Absolut
Socket field i
contents of th
HEADER will be
low-order 20 bit
field to form th
Relative/Absolut
field = zero,
will choose a nu
bits are equal t
HEADER.
Relative/Absolut
the effective
the contents of
e bit = zero,
zero. In this c
e Group field
concatenated
of the Local
e . 1 . s .
= zero, Local
In this case,
mber whose high
o the Group fiel
e = one . In th
local socket is
the Local Socket
Local
ase, the
in the
with the
Socket
Socket
the SFAM
order 12
d in the
is case
equal to
field.
The relationship between the e.l.s. and the local
sockets for the connection is defined in table 1.
Ill A 4 d (7). Timeout
This field contains the maximum length of time,
in seconds, that the SFAM is to attempt to establish
the connection (in the absence of an error or
exceptional condition). If the SFAM has been unable
to establish the connection within this time period,
it is to abandon the attempt. If this field contains
zero (default), the time period is to be infinite.
Ill A k d ($). Byte Size
This field contains the byte size for data
transfer on the connection. If this field contains
zero (default), the byte size will be 8 bits.
90
DRAFT
8/23/77
FA PSP
BEGIN Command
Table 1
Control
Bit
Foreign Sockets
for the connection
Local Sockets
for the connection
Duplex
e. f . s . and e. f . a . ♦ 1
e. 1 . s . and e. 1 . s . ♦ 1
Simplex
e.f .a.
e.l.s.
91
DRAFT
6/23/77
FA PSP
BEGIN Response
III B. BEGIN Pcaponae
III B 1, When sent
A BEGIN Response is sent by the SFAM to report the
outcome of an attempt to access a file or establish a
transfer requested by a BEGIN Command. The Status field in
the HEADER will indicate whether the attempt was successful
or unsuccessful.
Ill P 2t Action on receipt
When the UFAM receives a BEGIN Response indicating a
successful connection, it may proceed to use the channel.
When the UFAM receives a BEGIN Response indicating an
unsuccessful connection, it should perform the appropriate
error recovery.
Ill B 1. TEXT field syntax
Security:
File Results:
Data Results:
Connection Results:
Connection State:
Host:
Foreign Socket:
Messages:
Bits:
Local Socket:
VARIABLE*?)
FIXED(4)
FIXED(5)
C0MPLEX(8)
FIXED(M)
FIXED(32)
FIXED(32)
FIXED(16)
FIXED(32)
FIXED(32)
III B U. TEXT field semantics
III B * at Security
This field may be used to validate the access
privileges of the user. The default value of the field
is empty. Note: At this time, very little work has
been done on the organization of security for networks
or these kinds of systems. It is not clear where access
control should be placed. This field has been included
in case some systems require validation at this point.
Ill B 4 b, File results
If the BEGIN Command was not successful (as
indicated by the Status field in the HEADER), this field
will contain an encoded identification of any problems
with the File Parameters. The values are:
1 File not found
2 File name not allowed
3 File too large
92
8/23/77
FA PSP
BEGIN Response
M File not presently available
5 Record size too long
6 Position information not valid
7 Direction not supported
6 Illegal parameter combination
XII B 4 c . Data t r answer results
If the EEGIN was not successful (a? indicated bv
the Status field of the HEADER), this field will contain
an encoded identification of any errors in the Data
Transfer Parameters. The values are:
1 Improper Type
2 Improper Mode
H Improper Structure
8 Byte size not supported
16 Illegal parameter combination
If there was more than one error, the associated codes
may be added to form the value of the field. This
addition amounts to just setting the proper bits. If
the reason is "illegal parameter combination" (16), the
SFAM should also try to indicate the parameters in
conflict by setting the appropriate bits.
Ill B H d« Connection results
If no connection was associated with
Command, these fields will not be present.
Ill B *♦ d (Pt connection-state
the BEGIN
If the connection attempt was successful (as
indicated by the Status field in the HEADER), this
field will contain the value 1 which will be
compatible with the "open" state value defined for
this field in the TEXT of the EXECUTE Response (See
III K H g (1).)
If the connection attempt was unsuccessful, this
field contains an encoded reason for the failure.
The codes are:
0 Illegal control bit combination
1 Invalid local socket
2 Invalid host
3 Byte size not supported by front end
4 Byte size not supported by foreign
host
5 Connection attempt timeout
6 Network not available
7 Foreign host dead
93
DRAFT
8/23/77
FA PSP
BEGIN Response
8 Connection refused
9 Front end terminating service
10 Improper access
III P * d (g)T Host
If the connection attempt was successful, this
field contains the ARPANET host address of the host
to which the connection was established (see III A 4
d (2)).
Ill P 1 d (1). Foreign Socket
If the connection attempt was successful, this
field contains the socket number at the foreign host
to which the connection was established.
Ill B U d (it). Messages and Bits
If the connection attempt was successful, these
fields contain the flow control parameters for the
connection at the time the BEGIN Response was
generated.
Ill B 4 d (5) . Local Socket
If the connection attempt was successful, this
field contains the local socket number for the
connection .
Ill B H d (6). Bvte Size
If the connection attempt was successful, this
field contains the byte size, in bits, for the
connecti on .
94
b/23/77
FA PSP
END Command
III C. END Command
III C 1. When gent
An END Command is sent by either file access module to
terminate a session on a particular channel.
Ill C 2, ActiPP UPpn receipt
When a file access module receives an END Command, it
should finish writing any data it has in hand onto the file
or network connection (unless Flush away (bit 1) is set in
the Control field of the HEADER), close the file or network
connection, and clean up whatever loose ends there may be.
When all is in order (files and connections closed, etc.),
the FAM should send an END Response.
Ill c 3, TEXT field syntax
Cause: FIXED(3)
III C L. TEXT field semantics
This field contains an encoded reason for sending the
END Command. The codes are:
0 Normal completion (default)
1 Network/process failure
2 Foreign host failure
3 User requested termination
4 Front end terminating service
5 Improper access
DRAFT
6/23/77
FA PSP
END Response
III P, END Response
III P 1, When gent
The END response is sent by either FAM to acknowledge
the receipt of an END Command and to complete the
termination of the associated logical channel.
Ill P 2« Action on receipt
When a FAM receives the END Response, it should
consider the logical channel to be terminated.
Ill P 3. TEXT field syntax
The TEXT field in the END Response is not used in this
protocol.
96
DRAFT
fe/23/77
FA PSP
TRANSMIT Command
HI E. TRANSMIT Command,
III g 1. When sent
III E 1 a. By the FAM in the host
The TRANSMIT Command is sent by the FAM in the host
to pass data and restart markers to the FAM in the front
end for transmission over the network to the foreign
host, or to the file system in the front end.
Ill E 1 b. gy the FAM in the front end
The TRANSMIT Command is sent by the FAM in the
front end to pass data from the network or the front-
end's file system to the FAM in the host.
Ill E 2. Action on receipt
III E 2 a. By the FAM in the host
When the FAM in the host receives a TRANSMIT
Command, it will treat the contents of the Data field as
data to be processed as directed by the associated
EXECUTE Command.
Ill E 2 b. By the FAM In the frpnt ep d
When the FAM in the front end receives a TRANSMIT
Command, it will treat the contents of the Data field as
data to be transmitted over the network, or to the local
file system.
Ill E 3. TEXT field syntax
Special Conditions: FIXED(2)
No-EOT/EOT
No-EOF/EOF
Marker: VARIABLE*?)
Data: VARIABLE*?)
Ill E 4. TgXT field semantics
HI E 4 a. Special Conditions
This field indicates special conditions relevant to
the transmission of the data.
Ill EM a M ) . No-EOT/EOT
When this bit is zero (default), there is more
data to follow in subsequent TRANSMIT Commands. When
this bit is one, it indicates that the data in this
97
8/23/77
FA PSP
TRANSMIT Command
TRANSMIT Command completes a read or write operation.
Ill 6 * 3 (2), NP-EQF/BQF
When this bit is zero (default), no end of file
condition exists. When this bit is one, it indicates
that the data in this TRANSMIT Command completes the
file. Note: If this bit is set, the No-EOT/EOT bit
will be set also.
Ill E » b. Marker
This field contains the restart marker. Since the
restart marker must be at the front of the message, the
FAM will have to place data into messages in such a way
that each marker falls at the beginning of a new
message. The form of the restart marker is left to the
decision of the installation. This field can also be
used to synchronize read and write EXECUTE Commands with
the data they refer to.
Ill E 4 c. Data
This field contains the data to be passed over the
channel .
98
DRAFT 8/23/77 FA PSP
TRANSMIT Response
HI F« XraaaiU Raaponae
The TRANSMIT Response is used as described in the HFP
specification.
8/23/77
FA PSP
SIGNAL Command
III Gt SIONAL Command
The SIGNAL Command is net used in the process-to-service
protocol. SIGNAL Commands may be generated by process or
service to request that the CPM carry out the appropriate
action on the logical channel. (See HFP specification.) Thus,
the effect of the SIGNAL Command is restricted to the logical
channel (HFP) level.
DRAFT 8/23/77 FA PSP
SIGNAL Response
III H. SIGNAL Rcaponae
The SIGNAL Response is not used by either process or
service.
101
DRAFT 6/23/77 FA PSP
EXECUTE Command
HI J. EXECUTE Command
III J K When sent
III J 1 a. Bv the UFAM
The UFAM sends an EXECUTE Command to request that
the SFAM
(1) set Data Transfer Parameters,
(2) open a file ,
(3) read from a file,
(4) write to a file
(5) move the read pointer in the file,
(6) move the write pointer,
(7) open a network connection, or
(8) return a description of the status of the connection.
Ill J 1 b. Bv UFAM or the SFAM
Either FAM may send EXECUTE Commands to the other
(1) to set the marker window width,
(2) to abort a transfer, or
(3) to acknowledge a marker
Which FAM may send these commands depends upon which one
is the data source and which the data receiver. The
data source sets the marker window width. Only the
receiver sends marker acknovl pd^emen t s . Either side may
abort the transfer.
Ill J 2. Action upon receipt
When the SFAM or UFAM receives an EXECUTE Command it
should decode it and attempt to perform the action
indicated.
Ill J 3, TEXT field syntax
Code: FIXED(4)
Parameters: VARIABLE(?)
Ill J 4. TEXT field semantics
III J 4 a. Code
This field contains an encoding of the type of
request. The codes are:
0 Set Data Transfer Parameters
1 Open
102
8/23/77
FA PSP
EXECUTE Command
2 Read
3 Write
4 Set read position
5 Set write position
6 Abort
7 Open network connection
8 Set marker window
9 Return connection status
10 Marker acknowledgement
HI J 1 b. Parameter?
This field contains any parameters required to
perform the request indicated in the Code field. A
discussion of these parameters follows.
Ill J » p (D , §et Pata Transfer Parameters
For offloading schemes where the UFAM must
remotely control the FTP data transfer process, these
parameters are used to specify how the data is to be
formatted for transmission over the network. It is
assumed that the host and front end have agreed on
the form in which data will be presented to each
other.
Ill J H b (1) (a), Parameter field, syntax
Type:
Mode:
Structure :
Byte Size:
FIXED(3)
FIXED(2)
FIXED( 1 )
FIXED(8)
III J *♦ P (1) (b), Parameter field semantics
For detailed semantics of these fields see
sections III A 4 c (1) - (4) above.
Ill J 4 b (2). Open
These parameters specify what file is to be
transferred in what direction, the size of the file,
and the record size, if applicable. The Security
field is provided for file passwords or simply to
revalidate the user's access privileges.
Ill J 1 b (2) (a). Parameter field syntax
Security:
Pathname :
Direction :
Position :
Size:
VARIABLE*?)
VARIABLE*? )
FIXED(2)
FIXEDC )
FIXED( )
103
DRAFT 6/23/77 FA PSP
EXECUTE Command
Record Size: FIXED( )
III J 4 b (2) (b). Parameter field semantics
For detailed semantics see sections III A 4 a
and III A 4 b. Note: Files are closed implicitly
by sending an Open request for a new file.
Ill J 4 b H). Read
This request is sent by the UFAM to the SFAM to
request that the amount of data specified by the
parameter be transferred from the file. The read
begins at the present position of the read pointer.
When the operation is complete, the pointer is
positioned one unit beyond the last unit of
information read; i.e., at the next unit of
information to be read.
Ill J 4 b (3) (a). Parameter field syntax
Amount: FIXED( )
Marker: VARIABLE( )
III J 4 b (3) (b). Parameter field semantics
The contents of the Amount field specifies
the amount of data to be read from the file. The
size of the field and the units represented by it
are installation parameters.
The Marker field is used to synchronize the
request with the data transferred by the TRANSMIT
Command. This Marker and the Marker in the first
TRANSMIT Command carrying data referred to by this
Command should be the same.
Ill J Mb (4) . Write
This request is sent by the UFAM to the SFAM to
request that the amount of data specified by the
parameter be transferred to the file. The write
begins at the present position of the write pointer.
When the operation is complete, the write pointer is
positioned one unit beyond the last unit written;
i.e. at the next unit of information to be written.
Ill J 4 b (4) (a). Parameter field syntax
Amount: FIXED( )
Marker: VARIABLE* )
104
8/23/77 FA PSP
EXECUTE Command
III J 4 b (k) (b). Parameter field semantics
The contents of the Amount field specifies
the amount of data to be written to the file. The
size of the field and the units specified by it
are installation parameters.
The Marker field is used to synchronize the
request with the data transferred by the TRANSMIT
Command. This Marker and the Marker in the first
TRANSMIT Command carrying data referred to by this
Command should be the same.
Ill J ^ b (5)f Set Read, Pointer
This request is sent by the UFAM to the SFAM to
request that the read pointer be set to the value
indicated by the parameter. The next Read request
will begin at this point.
Ill J 4 P (5) (a). Parameter Field Syptgx
Position: FIXED( )
XII J ^ P (5) (b). Parameter Field Semantics
The contents of this field indicate the new
position of the read pointer. The size and units
of the field are installation parameters. It is
recommended that special values be provided to
denote the beginning and end of the file.
Ill J 4 b (6). Set Write Pointer
This request is sent by the UFAM to the SFAM to
request that the write pointer be set to the value
indicated by the parameter. The next Write request
will begin at this point.
Ill v* 4 b (v) (a), Parameter field syntax
Position: FIXED( )
III J » b (6) (b)t Parameter fjeld semantics
The contents of this field indicate the new
position of the write pointer. The size and units
of the field are installation parameters. It is
recommended that special values be provided to
denote the beginning and end of the file.
Ill J M b (7). Abort
105
DRAFT
8/23/77
FA PSP
EXECUTE Command
This request is sent by the receiving file
access module to request that the current transfer of
data be aborted. The sending FAM should immediately
stop sending and await further commands.
Ill J 4 b (6). Open Network Connection
This request is sent by the UFAM to the SFAM to
request that a network connection be opened according
to the parameters.
Ill J 4 b (6) (a). _ Pa ram eter field sy n t a x
Connection parameters:
Con t rol-bit s :
Init/Listen
Socket/Channel
Duplex/Simplex
Relative/Absolute
Unattachable/Attachable
Host:
Foreign Socket:
Me ssages :
Bits:
Local Socket:
Timeout :
Byte Size:
COMPLEX ( b)
FIXED(5)
FIXEDC32)
FIXED(32)
FIXED( 16)
FIXED(32)
FIXED(32)
FIXED(16)
FIXED(o)
III J 4 b (6) (b). Parameter field semantics
For detailed semantics, see section III A 4
d.
Ill tl 4 b (9). Set Marker Window
This request is sent by the sender of the data
to set the width of the restart marker window. In
protocols that use restart markers, this request is
used to indicate how many markers can be sent without
receiving a Marker Acknowledgement. The marker
window should be set by the FAM sending the data.
(Note: the use of the marker window mechanism is
optional. )
III J * b (9) (a). Parameter field syntax
Window Width: FIXED( )
III J 4 b (9) (b). Parameter field semantics
The contents of this field indicate the width
of the marker window. The size of this field and
its units are installation parameters.
106
6/23/77
FA PSP
EXECUTE Command
III J H b (IP), Return Connection Status
No additional parameters need
for this request.
to be specified
III il—i-b (i1)t Marker Acknowledgement
This request is sent by the receiver of the data
to inform the sender that all data sent before a
specified marker have been written on the file. The
receiver of this request should advance the left edge
of the marker window to the position indicated by the
parameter. (Acknowledgement of several markers is
allowed . )
III J 1 b (11) (a), Parameter field, syntax
Marker: FIXED( )
III J ^ b (11) (b). Parameter fjeld semantics
This field contains the marker beinc;
acknowledged. If several markers are being
acknowledged, this field contains the last marker
in the sequence. The size of the field and the
form of the restart markers are installation
parameters.
107
DRAFT
8/23/77
FA PSP
EXECUTE Response
III Kt EXECUTE Response
ill k 1, When sent
A file access module sends an EXECUTE Response when
a) it has completed the operation requested by an
EXECUTE Command,
b) it has received an EXECUTE Command whose TEXT is
in error, or
c) report on the status of the network connection.
Ill K 2. AQtjon on receipt
When a FAM receives an EXECUTE Response, it should
examine the TEXT to see whether the Response indicates an
error. If no error is indicated, it may consider that the
action requested by the previous EXECUTE Command was
successful. If an error is indicated, appropriate error
recovery action should be initiated. This action is
idiosyncratic to the process.
Ill y 3. TEXT field syntax
Misc. -Result :
FIXED(M)
File Results:
FIXED(M)
Data Transfer Results:
FIXED(5)
Marker Results:
FIXED(3)
Ref-code:
FIXED(iJ)
Marker :
VARIABLES)
Connection Results:
C0MPLEX(8)
Connection State
FIXED(M)
Host
FIXED(32)
Foreign Socket
FIXED(32)
Messages
FIXED( 16)
Bits
FIXED(32)
Local Socket
FIXED(32)
III K M. TEXT field semantics
III k » a. Misc, -Result
This field contains an encoding of the result of
the request (in a previous EXECUTE Command) to which the
EXECUTE Response is a reply. The codes are:
1 Success
2 Illegal code in request
11 TEXT too short
8 Illegal parameter combination
HI K 4 b, File Resylts
This field contains an encoding of errors in the
108
8/23/77 FA PSP
EXECUTE Response
file parameters. The default value is zero (no
errors). The codes are:
0 Success
1 File not found
2 File name not allowed
3 File not presently available
4 Size too large
5 Record size too long
6 Position not valid
7 Direction not valid
III K 4 ct Pata Transfer Results
This field contains an encoding of any errors in
the Data Transfer Parameters. The codes are:
1 Improper type
2 Improper mode
4 Improper structure
8 Byte size not supported
16 Illegal parameter combination
III Md, Marker Result?
This field contains an encoding of any errors
resulting from the handling of restart markers. The
codes are:
0 Success
1 Marker window too wide
2 Marker window too narrow
3 Illegal marker
4 Marker outside window
III K t et Ref-code
This field contains the same value as the Code
field of the TEXT of the EXECUTE Command to which the
EXECUTE Response is a reply.
Ill Pf, Marker
The Marker field is used to identify the EXECUTE
Command for which this is the Response. This field
should match the Marker field in the EXECUTE Command.
Ill K 4 g, Connection Results
This field is used in replies to Open Network
Connection and Return Connection Status requests. It
has the same meaning as its identically named and
formatted counterpart in the TEXT of the BEGIN
109
6/23/77 FA PSP
EXECUTE Response
Response, with the following exception:
III K *« R (1)t Connection-state
When the Response is to a Return Connection
Status request, this field indicates the present
state of the connection. The possible values of
this field and their meanings are:
0 Closed
1 Open
2 Waiting for open to complete
3 Waiting for close to complete
110
6/23/77 FA PSP
Description of the File Access PSP
IV. Description of the File Access PSP
Basic Operation . Although the primary purpose of the File
Access PSP is to facilitate offloading FTP functions from a
host, it serves the more general purpose of providing the host
or front end access to the other machine's file system. This
access is controlled by the liFAM. The UFAM first sends a BEGIN
Command to the SFAM to instruct it to establish a session, to
validate or identify the user, and to prepare for access to a
particular file or network port. Once everything is in
readiness data transfer may commence with the UFAM issuing
reads and writes and transmitting data.
The File Access Process-t o-Service Protocol associates a
read pointer and a write pointer with an open file. The read
and write pointers indicate the location where the next read or
write operation will begin. After the read or write, the
respective pointer is left pointing after the last unit of
information read or written. Since the level of file
addressing varies considerably from host to host the File
Access PSP does not define the units represented by the read
and write pointers. Implementations should choose units that
allow efficient addressing and information transfer.
Implementors should also provide a mechanise for th J UFAM to
specify the beginning or end of a file without actually knowing
the address of the beginning or end.
When the transfer is complete, the UFAM may open another
8/23/77 FA PSP
Description of the File Access PSP
file and transfer data to or from it. When the UFAM has
finished its task it closes the channel by sending an END
Command .
Coordination of Commands and data . In the FA- PSP, the
operations to be performed (read, write, open, etc.) are
transferred by TRANSMIT Commands. When reads and writes are
used to access the file randomly, some way must be provided to
match operations with their data, since EXECUTE Commands and
Responses are sent out of band with TRANSMIT Commands.
Two methods may be used. The implementations in the host
and front end may be designed so that an EXECUTE Command cannot
be sent until the EXECUTE Response from the previous EXECUTE
Command has been received. The SFAM would then withhold the
EXECUTE Response until it had completed the operation. This
method, however, does not allow overlapping requests and could
significantly cut down the bandwidth. Alternatively, the
Marker fields in the read and write EXECUTE Commands and in the
TRANSMIT Commands can be used to tag the operations and the
corresponding data. fey this device the SFAM can determine what
it is to do with the data by matching the marker in the EXECUTE
Command with the data in the TRANSMIT Command. Similarly the
UFAM can determine what operations have completed by matching
the Marker field in an EXECUTE Response with the Markers for
outstanding EXECUTE Commands.
Use of markers for restart. File Transfer Protocols
112
6/23/77 FA PSP
Description of the File Access PSP
structured similarly to the File Access PSP do not require an
explicit restart mechanism for transfers of complete files. If
the host can determine the length of the file and an explicit
address for the end of the file, then a restart can be
accomplished by determining the address of the last data unit
received and setting read and/or write pointers accordingly for
the transfer. Since many FTP'S do not provide the ability to
address a file, the File Access PSP supports a fairly general
restart mechanism that should be capable of encompassing most
restart facilities found in FTP'S.
There are two major aspects to this restart facility:
1) the use of markers associated with the data, and 2) a
restart marker window (RMW). The protocol allows markers to be
placed in the TRANSMIT Command with the data. When the data
has been written on the file so that a system crash will not
cause it to be lost, the FAM controlling the data sends an
EXECUTE Command to the FAM controlling restart to acknowledge
the marker. In order that one FAM not get too far ahead of the
other, a restart marker window is provided. An EXECUTE Command
variant is provided to set the width of the RMW; however,
installations should define a default RMW width. This window
works exactly like the ones found in low-level protocols such
as TCP and the CYCLADES TS, except that in this case the window
is used to control the flow of markers and only indirectly the
flow of data. The sending FAM can continue to send data as
long as the window is open. Each marker sent or received moves
DRAFT
6/23/77 FA PSP
Description of the File Access PSP
the left edge of the window and each marker acknowledgement
sent or received moves the right edge of the window. If the
FAM controlling the data gets too far behind in acknowledging
markers, the window will close and the transfer will stop until
one or more markers are acknowledged. The File Access PSP does
not specify the form of the markers or how they relate to the
data or amount of data transferred. However, implementors
would be wise to generate markers in a form such that, when a
marker acknowledgement is received, it can be assumed to
acknowledge all preceding markers. Also, implementors should
try to define a marker form that makes it easy for the FAM
controlling the transfer to be able to tell what markers came
before the one currently under consideration and to what point
in the file this restart point corresponds.
The RMW is useful for several reasons. It can ensure that
if a failure occurs the amount that must be retransmitted is
not too large. Also, if the format of markers is such that a
table must be kept to map markers into the corresponding file
address, the window restricts the table to a fixed, manageable
size.
Use in offloading FTP. The File Access Process- to-Service
Protocol is used in several different ways to offload file
transfer protocols. Details of these schemes may be found in
"Offloading ARPANET Protocols to a Front End," CAC Document
230. The most important distinction between the schemes is
114
DRAFT
8/23/77 FA PSP
Description of the File Access PSP
whether the UFAM is in the host or in the front end.
If the UFAM is in the host, then the FA-PSP is used to
offload network access for data transfer to and from remote
hosts. If the data transfer process is in the front end, the
FA-PSP is also used to offload data translation tasks. Unless
the UFAM is attempting to access a file system in the front
end, the file parameters of the BEGIN Command will not be used.
Only the Data Connection Parameters will be present. The
restart marker apparatus will only be present if marker
bookkeeping and assignment is done in the host. These markers
will be present, however, to implement the marker mechanism of
the FTP rather than to offload it.
If the UFAM is in the front end, then the FA-PSP is being
used to offload network access for data transfer, access to the
host's file system, and possibly data translation and restart.
The Connection Parameters will never occur in the BEGIN
Command. The Data Parameters may occur if the data translation
is done in the host. (However, translation will most likely be
done in the front end.) The File Parameters will always be
present. In this case, the FA-PSP can be used to offload more
of the restart bookkeeping to the front end. Of course,
markers and marker acknowledgements may be present merely to
implement FTP rettart, regardless of whether restart is
offloaded.
115
DRAFT
8/23/77
FA PSP
Scenario
V. Scenario
Let us consider how this protocol is used to transfer
files between the host and front end. In this scenario, the
Using File Access Module (UFAM) is in the front end. Another
front-end module (e.g., the user or server FTP service module)
has passed the UFAM the necessary information to initiate a
transfer. To be specific, let us assume that the server FTP
service module (SFSM) has just given the UFAM the user
identification, pathname, and network port information for
starting a transfer across the network. The UFAM then sends a
BEGIN Command to the host to request access to the file:
<BEGINXCXsecurity = day,johnXpathname = junk.note>
<direction = 2>
The Serving File Access Module (SFAM) in the host
successfully opens the file and sends a BEGIN Response:
<BEGINXRXStatus = 0>
The UFAM is now ready to begin the transfer of the data. It
notifies the SFSM, so it can send the user the FTP reply
indicating begin of transfer, and sends a read to the SFAM:
< EXE CUTEXCX coder 2>< Amount rALL>
(This implementation has defined the string "ALL" to indicate
that the entire file is to be read.) Data begins to flow
immediately via the TRANSMIT Commands:
116
DRAFT 8/23/77 FA PSP
Scenario
<TRANSMITXCXspecialrOXthe data>.
At some time, perhaps before the first TRANSMIT Command, the
SFAM sends a response to the read:
<EXECUTEXR>
(No parameters are required since the read was successful.)
Finally the last of the file is moved across:
<TRANSMITXCXspecialr3><data>
The UFAM notifies the SFSM after the last message has been
written to the net, so that the SFSM can send the FTP reply
indicating the end of the transfer. The UFAM then waits for
another request from the SFSM. However, the user is done and
has sent an FTP EYE Command to the SFSM. The SFSM notifies the
UFAM that the session is terminating and the UFAM sends an END
Command indicating normal completion:
<ENDXCXcause = 0>
The SFAM replies immediately with an END Response:
<ENDXR>.
117
6/23/77
FA PSP
References
VJI. References
1. Day, J. "Offloading ARPANET Protocols to a Front End," CAC
Document No. 230, Center for Advanced Computation,
University of Illinois at Urbana-Champai gn , 1977.
2. Neigus, N. "The File Transfer Protocol," ARPANET RFC 542,
1973.
3. Neigus, N.; Pogran, K.; and Postel, J. "A New Schema for
FTP Reply Codes," ARPANET RFC 640, 1974.
4. Schicker, P.; Duenki, A.; and Baechi, W. "Bulk Transfer
Facility," INWG Protocol Note #31. EIN /ZHR/75/20 , 1976.
Appendix 3
ARPANET Host-Host
Process -to -Service
Protocol Specification
CAC Technical Memorandum 80
by
John Day
Gary Grossman
119
ARPANET Host-Host
Process-to-Service Protocol
Specification
If Service Code Nvaber
II. Description of the Service
This document is a process-to-service protocol specification
as defined in the Host-to-Front-End Protocol (HFP) Specification
[ARPANET RFC 710]. It specifies a process-to-service protocol
for providing ARPANET Host-Host Protocol and Initial Connection
Protocol services to a process through the HFP.
The Host-Host Protocol is the basic inter-process
communication protocol for the ARPANET [ARPANET NIC Document
8246]. The program which implements it in each host is the
Network Control Program (NCP). The service described here
provides an interface, through the HFP, between a process in a
host and an NCP in a front end. This enables the process to
establish and use ARPANET connections.
The Initial Connection Protocol (ICP) is the mechanism in
the ARPANET which enables a process in one host to connect to a
multi-user facility, such as the virtual terminal server or the
file transfer server, in another host [ARPANET NIC Documents
7101, 7155, 7103]. The service described here enables a process
121
DRAFT 8/23/77 HH PSP
Description of the Service
in a host to establish ARPANET connections via the ICP.
The ARPANET Host-Host process-to-service protocol uses HFP
Messages to carry information between the process and the service
module. A brief summary of the function of specific Message
types follows.
begin Command
from the host process
requests that a connection be established.
BEGIN Response
from the service module
a) confirms the establishment of the connection or
b) reports the reason for failure.
END Command
from the process
requests the closing of the connection,
from the service module
reports the closing of the connection by the
foreign host.
END Response
from the process
acknowledges the closing of the connection,
from the service module
acknowledges the closing of the connection.
TRANSMIT Command
from the process
carries data to the service module for
transmission to the foreign host over the
ARPANET,
from the service module
carries data received over the ARPANET to the
process .
EXECUTE Command
from the process
requests that the service module
a) send an ARPANET Host-Host INR command
referencing the connection,
b) alter flow control parameters for the
connection, or
c) report the status of the connection.
EXECUTE Response
122
DRAFT 6/23/77 HH PSP
Description of the Service
from the service module
a) acknowledges the completion of actions
requested by the process via EXECUTE Commands
and
b) reports the status of the connection.
Security and protection problems are posed by the way that
local sockets are used in the ARPANET protocols. If processes
were permitted to use any socket number without restriction, a
process could 'masquerade' as another (e.g., the logger) and gain
access to privileged information (e.g., passwords). For this
reason, two modes of access to the local socket name space are
provided. The "relative" mode restricts the process to a unique,
distinct subset of the local socket name space. This mode
requires no special privilege. The "absolute" mode allows the
process to access any local socket number. Its use requires the
process to have special privileges. The modes are distinguished
by the Relative/Absolute bit in the TEXT of the BEGIN Command.
(See sections III A H b (1) (d) and III A H b (6).)
Some front ends may be so structured that it is possible for
service modules to communicate with each other. This facility
could be used to permit service modules such as Telnet to
communicate with the ARPANET host-host service module and use
network connections which the process had already separately
established. A process could request the host-host service
module to connect to a remote host. Then the process could
request the Telnet service to "attach" to the already existing
logical channel associated with the host-host service module and
thus use the already existing network connection. The
123
DRAFT
8/23/77 HH PSP
Description of the Service
"Unattachable/Attachable" bit in the TEXT of the BEGIN Command is
used to enable this feature for a given logical channel. See
section III A 4 b (1) (e).
The detailed specification of the use of HFP Messages
follows.
124
DRAFT
8/23/77
HH PSP
BEGIN Command
III, Meaaflftc Umm
III A. BEGIN CoBBftn<3
III A 1. When sent
A BEGIN Command is sent by the process to request that
the service module attempt to establish an ARPANET
connection .
Ill A 2. Action on receipt
When the service module receives the BEGIN Command, it
will attempt to establish the connection according to the
parameters in TEXT.
Ill A 3. TEXT field syntax
VARIABLES)
C0MPLEX(8)
FIXED(5)
Security:
Establishment:
Control-bits :
Init/Listen
ICP/Direct
Duplex/Simplex
Relative/Absolute
Unattachable/Attachable
Host: FIXED(32)
Foreign Socket: FIXED(32)
Messages: FIXEDM6)
Bits: FIXED(32)
Local Socket: FIXED(32)
Timeout: FIXED(16)
Byte Size: FIXED(8)
III A L, TEXT field gjBjmiU&a
This field can be used to validate the process'
access privileges to network resources. It is
particularly important to limit access to network
security objects such as local socket 1. The
substructure and content of this field are Installation
dependent .
NOTE: At this writing, not enough is known about
security in networks and front ends to make any
statement about the utility of validation at this point
in the system. This field is included in case some
systems require validation at this point.
125
DRAFT
8/23/77
HH PSP
BEGIN Command
III A t p, Establishment
This set of parameters governs the establishment of
the network connection.
Ill A 4 b M), control-bits
The bits in this field govern the kind of
connection to be established, the method of its
establishment, and the interpretation of the
parameters.
Ill A ^ t> (1) (a)t InU/Listeji
When this bit is zero (default), the
connection is to be actively initiated by the NCP.
When this bit is one, the connection is to be
passively "listened*1 for by the NCP. The use of
this bit in specifying connection sockets is
detai led in table 1 .
Ill A 4 b (1) (b). ICP/Direct
When this bit is zero (default), the
connection is to be established via the Initial
Connection Protocol. When this bit is one, the
connection is to be established directly to the
specified foreign socket. The use of this bit in
specifying connection sockets is detailed in table
1.
This bit is relevant only if the ICP/Direct
bit is one. When this bit is zero (default), the
connection is to be full duplex and is therefore
to consist of two ARPANET connections (one in each
direction). When this bit is one, the connection
is to be unidirectional according to the sender of
the socket numbers supplied in the Foreign Socket
and/or Local Socket fields. The use of this bit
in specifying connection sockets is detailed in
table 1.
Ill A 4 b (1) (d). Relative/Absolute
This field affects the value of the socket
for the local connection. See III A 4 b (6) for
details.
Ill A 4 b (1) (c). Unattachable Ik 1 1 a chable
When this bit is one, the host-host service
126
6/23/77 KH PSP
BEGIN Command
module is requested to make the logical channel
available for attachment by other service modules
within the front end (such as Telnet or a data
transformation service). If this bit is zero
(default), the host-host service module is not
requested to make the locical channel available
for attachment within the front end.
HI A 1 b (2) . Host
This field specifies the network host to which
the connection is to be made. A value of zero in
this field indicates that the connection may be
established with any host on the network. A zero
value is valid only if the Init/Listen bit is one
(Listen) .
The Host field is parsed as:
Network: FIXED(ft)
Imp: FIXED(16)
Host-at-Imp: FIXED(fc)
III A k b (3). Foreign Socket
This field is used as follows to construct the
effect! ve foreign socket (e.f.s.) for making the
connection.
Case 1. Foreign Socket field = zero;
Init/Listen bit = one. Foreign host
chooses the e.f.s.
Case 2. Foreign Socket field = zero;
Init/Listen bit = zero. The e.f.s. is
one .
Case 3. Foreign Socket field i zero. The e.f.s.
is the contents of the Foreign Socket
field.
The default value of this field is zero. The
effective foreign socket is used in various ways,
depending upon the values of certain of the control
bits, to effect the connection. See table 1 for
detai Is .
Ill A 4 b (M). Messages
This field and the Bits field allow the process
to indicate to the service module the flow rate
desirable on the connection. The service module may
use this information in any way its implement ors deem
desirabl e.
This field contains the number of ARPANET Host-
127
DRAFT
8/23/77
HH PSP
BEGIN Command
Host messages the process suggests be allocated on the
connection. If the value of this field is zero
(default), the service module chooses the number of
messages on its own.
Ill A 1 b (5)t Pit?
This field contains the number of bits the
process suggests be allocated for the connection. If
the value of this field is zero (default), the service
module chooses the number of bits on its own.
b (6 ) . Local Socket
This field is used as f
effective local socket
connection .
Case 1. Relati ve/Absolu
Socket field
contents of the
will be conca
20 bits of the
the e. 1 . s .
Case 2. Relati ve/Absolu
Socket field
service will ch
order 12 bit
field in the HE
Case 3- Relative/Absolu
case the effec
to the conten
field.
ollows to construct the
(e.l.s.) for making the
te bit = zero, Local
i zero. In this case, the
Group field in the HEADER
tenated with the low-order
Local Socket field to form
te bit = zero, Local
= zero. In this case, the
oose a number whose high
are equal to the Group
ADER.
te bit = one. In this
tive local socket is equal
ts of the Local Socket
The effective local socket is used in various ways,
depending upon the values of certain of the control
bits, to effect the connection. See table 1 for
details.
Ill A 4 b (7), Timeout
This field contains the maximum length of time, in
seconds, that the service module is to attempt to
establish the connection (in the absence of an error or
exceptional condition). If the service module has been
unable to establish the connection within this time
period, it is to abandon the attempt. If this field
contains zero (default), the time period is to be
infinite.
Ill A 4 b (8). Bvte Size
This field contains the byte size for data
128
DRAFT
8/23/77
HH PSP
BEGIN Command
transfer on the connection. If this field
zero (default), the byte size will be b bits.
contain s
129
DRAFT
8/23/77
HH PSP
BEGIN Command
Table 1
Control Bits { Foreign Sockets ! Local Sockets
i for the connection i for the connection
! {The e.f.s. will be used!
j las the contact socket {
i Init {for the connection. {e.l.s. + 2 and e.l.s. +3
! {The data sockets will |
! !be chosen by the for- J
i ieign host. i
ICP I ------- | -___-----_-_-_---_--- { -----------------------
i ! iThe e.l.s. will be used
' * las the contact socket
I 1 {for the connection.
{Listen le.f.s. -4-2 and e.f.s. +3!The data sockets will
1 } |be chosen by the
I I 1 service as in Case 2 of
I I ! Ill A H b (6).
(Duplex | e.f.s. and e.f.s. +1 I e.l.s. and e.l.s. ♦ 1
Direct | ------- j ----------------------- { --- -_--_-_---_------
{Simplex! e.f.s. ! e.l.s.
130
DRAFT
8/23/77
HH PSP
BEGIN Response
III L. BEGIN Response
III P 1, Wnen sent
A BEGIN Response is sent by the service module to
report the outcome of an attempt to establish a connection
requested by a BEGIN Command. The Status field in the
HEADER will indicate whether the connection attempt was
successful or unsuccessful.
Ill b 2. Action on receipt
When the process receives a BEGIN Response indicating
a successful connection, it may proceed to send and receive
data on the connection. When the process receives a BEGIN
Response indicating an unsuccessful connection, it should
perform the appropriate error recovery.
Ill B 3. TEXT field syntax
Connect! on -info:
Connection-state:
Host:
Foreign Socket:
Messages :
Bits:
Local Socket:
Byte Size:
COMPLF.X(?)
FIXED(U)
FIXED(32)
FIXED(32)
FIXED( 16)
FIXED(32)
FIXED(32)
FIXED(8)
nantics
III 3 4 a, Connection-state
If the connection attempt was successful (as
indicated by the Status field in the HEADER), this field
will contain the value 1 which will be compatible with
the "open" state value defined for this field in the
TEXT of the EXECUTE Response (which see).
If the connection attempt was unsuccessful, this
field contains an encoded reason for the failure. The
codes are:
0 Illegal control bit combination
1 Invalid local socket
2 Invalid host
3 Byte size not supported by front end
4 Byte size not supported by foreisrn host
5 Connection attempt timeout
6 Network not available
7 Foreign host dead
8 Connection refused
9 Front end terminating service
131
DRAFT 8/23/77 HH PSP
BEGIN Response
III B » b, Hogt
If the connection attempt was successful, this
field contains the AEFA.NET host address of the host to
which the connection w a ? established.
Ill B 4 c. For eign Socket
If the connection attempt was successful, this
field contains the socket number at the foreign host to
which the connection was established.
Ill B U d. Messages and Bits
If the connection attempt was successful, these
fields contain the flow control parameters for the
connection at the time the BEGIN Hesponse was generated.
Ill p U et Local Socket
If the connection attempt was successful, this
field contains the local socket number for the
connection .
Ill g 4 f. Evt* Size
If the connection attempt was successful, this
field contains the byte size, in bits, for the
connection .
132
DRAFT
0/23/77
hH PSP
END Command
III C , END Command
III C 1. When sent
III C 1 a. By the process
An END Command is sent by the process to request
the service module to close the network connection.
J.II C 1 b. By the service module
An END Command is sent by the service module to
notify the process that the connection has been closed
by the foreign host or by a failure of the foreign host
or the network.
Ill C 2. Action on receipt
When the process receives an END Command, it should
consider the connection closed. The process should send
an END Response and take appropriate recovery action.
Ill C 2 b. Bv the service module
When the service module receives an END Command, it
should allow data queued for transmission to the network
to drain, unless Flush awav (bit 1) is set in the
Control field. It should then initiate the process of
closing the connection. When the connection is closed,
the service module should send an END Response.
Ill C 3 . TEXT field syntax
Cause: FIXED(3)
[II C *♦ ♦ TEXT field semantics
III C 4 a. Cause
This field contains an encoded reason
the END Command. The codes are:
for sending
0 Normal completion (default)
1 Network/process failure
2 Foreign host failure
3 User requested termination
M Front end terminating service
133
DRAFT
8/23/77
HH PSP
END Response
III D. END Response
III P 1. When gent
III P Is, Py the process
The END Response is sent by the process to
acknowledge the receipt of an END Command and complete
the termination of the associated logical channel.
Ill P 1 &. Py the service module
The END Response is sent by the service module to
acknowledge receipt of an END Command, notify the
process that the connection has been closed as
requested, and terminate the logical channel.
Ill P 2t Action on receipt
III P ? a, Py the process
When the process receives the END Response, it
should consider the ARPANET connection to be closed and
the HFP logical channel to be terminated.
Ill P 2 bt py the service module
When the service module receives the END Response,
it should consider the logical channel to be terminated.
The TEXT field in the END Response is not used in this
process-to-service protocol.
134
8/23/77
HH PSP
TRANSMIT Command
XII E. TRANSMIT Command
III E 1. When sent
III E 1 a. Bv the process
The TRANSMIT Command is sent by the process to pass
data to the service module for transmission over the
network to the foreign host.
Ill E 1 b. Bv the service module
The TRANSMIT Command is sent by the service module
to pass data that has arrived over the network from the
foreign host to the process.
Ill E 2. Action on receipt
III E 2 a. Bv the process
When the process receives a TRANSMIT Command, it
will treat the contents of the TEXT as data to be
processed .
Ill E 2 b. Bv the service module
When the service module receives a TRANSMIT
Command, it will treat the contents of the TEXT as data
to be transmitted over the network.
Ill E L, TEXT field syntax
TEXT contains the data to be transferred by the
TRANSMIT Command.
Ill E M. TEXT field semantics
The data in the TEXT have no other semantics than
those described in sections III £ 1 and III E 2.
135
DRAFT 8/23/77 HH PSP
TRANSMIT Response
III Ft TFANSHIT Bcappnge
The TRANSMIT Response is used as described in the HFP
specification .
136
DRAFT
8/23/77
HH PSP
SIGNAL Command
III C. SIGNAL Command
The SIGNAL Command is not used in the process-to-
service protocol. SIGNAL Commands may be generated by process
or service to request that the CPM carry out the appropriate
action on the logical channel. (See HFP specification.)
Thus, the effect of the SIGNAL Command is restricted to the
logical channel (HFP) level.
137
DRAFT
8/23/77
HH PSP
SIGNAL Response
XII H, SIGNAL Response
The SIGNAL Response is not used by either process or
service .
138
DRAFT
8/23/77
HH PSP
EXECUTE Command
III J. EIECUTE Command
III J 1. When sent
The process sends an EXECUTE Command to request that
the service module
a) send an ARPANET Host-Host INR command,
b) alter the suggested allocation on the connection,
or
c) return a description of the status of the
connection .
The service module does not send EXECUTE Commands for this
protocol .
Ill J 2, Action PP_T_ft.fi£lJBl
When the service module receives an EXECUTE Command,
it will decode the TEXT and act upon it.
Ill J L. TEXT field syntax
Code:
Messages:
Bits:
FIXED(2)
FIXED( 16)
FIXED(32)
III J L, TEXT field semantic?
Ill J H a, Code
This field contains an encoding of the type of
request. The codes are:
0 Send INR
1 Alter suggested allocation
2 Return connection status
The Messages and Bits fields need be present only
if the Code field contains the value 1 (Alter suggested
allocation) .
Ill J * bt Messages
This field is valid only if the request is "Alter
suggested allocation" (Code = 1). It contains the number
of ARPANET messages the process suggests be allocated on
the connection. If the value of this field is zero
(default), the service module chooses the number of
messages on its own.
This field is valid only if the request is "Alter
suggested allocation" (Code = 1). It contains the number
139
DRAFT 8/23/77 . HH PSP
EXECUTE Command
of bits the process suggests be allocated for the
connection. If the value of this field is zero
(default), the service module chooses the number of bits
on its own.
140
DRAFT 8/23/77 HH PSP
EXECUTE Response
III K. EXECUTE Regpongg
III K 1. When sent
The service module sends an EXECUTE Response when
a) it has completed tha operation requested by an
EXECUTE Command or
b) it has received an EXECUTE Command whose TEXT is
in error.
The service module does not send EXECUTE Commands for
this process-to-service protocol. Therefore, the process
does not send EXECUTE Responses.
Ill K 2. Action on receipt
When the process receives an EXECUTE Response, it
should examine the TEXT to see whether the response
indicates an error. If no error is indicated, it may
consider that the action requested by a previous EXECUTE
Command was successful. If an error is indicated,
appropriate error recovery action should be initiated. This
action is idiosyncratic to the process.
Ill K 3, TEXT field syntax
Result: FIXED(2)
Ref-code: FIXED(2)
Connection-info: COMPLEX(?)
Connection-state: FIXED(2)
Host: FIXED(32)
Foreign Socket: FIXED(32)
Messages: FIXED(16)
Bits: FIXED(32)
Local Socket: FIXED(32)
Byte Size: FIXED(8)
III K L. TEXT rigid semantics
III £ 4 a. ResyU
This field contains an encoding of the result of
the request (in a previous EXECUTE Command) to which the
EXECUTE Response is a reply. The codes are:
0 Successful
1 Illegal code in request
2 TEXT too short
The "TEXT too short" error can occur only if the request
was "Alter suggested allocation".
141
DRAFT
6/23/77
HH PSP
EXECUTE Response
III K k b. Ref-code
This field contains the same value as the Code
field of the TEXT of the EXECUTE Command to which the
EXECUTE Response is a reply.
HI K k ct Connection-info
This field has the same meaning as its identically
named and formatted counterpart in the TEXT of the BEGIN
Response, with the following exception:
III k 4 c (i), Connection-state
This field indicates the present state of the
connection. The possible values of this field and
their meanings are:
0 Closed
1 Open
2 Waiting for open to complete
3 Waiting for close to complete
142
DRAFT
6/23/77
HH PSP
Scenario
iv. Scenario
Let us consider how this PSP can be used to remotely
control a Network Control Program in the front end. We will
assume that there is a program in the host that wishes to open a
Telnet connection to remote host 12. A BEGIN Command is sent to
the front end:
<BEGINXC><host = 12Xmsgs = 15><bits = 12000>
Because the defaults for the HH-PSP favor initiating a Telnet
connection (i.e., a duplex connection established by an ICP to
socket 1) the BEGIN Command does not have to specify many of the
parameters. The HH Service in the front end opens the connection
and sends a BEGIN Response to the host:
<BEGINXRXSTATUSrO><state=1><host = 12><Fgnskt = 523 9>
<msgs= 12><bits= 12000>
indicating that the connection attempt was successful. The
program now sends and receives via TRANSMIT Commands.
At some time later the program in the host receives an
END Command:
<ENDXCXcause = Foreign host failure>
This indicates that the network connection has been closed
because the remote host crashed. The front end wishes to
terminate the service. The program immediately sends an END
Response:
<ENDXR>
The channel is now closed. At some later time the
program may attempt to re-establish the connection.
143
DRAFT 8/23/77 HH PSP
References
Y, References
1. McKenzie, A. A. "Host/Host Protocol for the ARPA Network," NIC
#7117, 1972. Also in the ARPANET Protocol Handbook.
2. Postel, J. "Official Initial Connection Protocol," NIC #7101,
1971. Also in the ARPANET Protocol Handbook.
144
Appendix 4
Network Virtual Terminal
Process-to-Service
Protocol Specification
CAC Technical Memorandum 103
by
John Day
145
Network Virtual Terminal
Process-to-Ser vi ce Protocol
Specification
I. Service Code Number
5
II. Description of the Service
This document is a process-to-service protocol specification
as defined in the Host-t o-Front-End Protocol ( H b P ) Specification
[ARPANET RFC 710]. It describes a protocol for offloading a
network virtual terminal protocol (e.g., Telnet for the ARPANET)
to a front end. This protocol allows some flexibility in the
decree of offloading that may be achieved. Although the protocol
is applicable to a general virtual terminal service, the
discussion below is in terms of the ARPANET Telnet Protocol,
which is currently the only such protocol widely used.
The functions of the typical network virtual terminal
implementation are:
1. manipulating network connections,
2. negotiating Telnet options,
3. mapping between local terminal representations
and network virtual terminal representations,
4. transmitting data over connections,
5. handling special control functions, and
147
DRAFT
8/23/77
NVTS PSP
Description of the Service
6. interfacing the remote network connections so that
they appear to the host to be local terminals.
The offloading scheme represented by this model places
manipulating connections and transmitting data over the net in
the front end. The interfacing of remote terminals so that they
appear as local terminals must be done in the host. The scheme
is flexible in that the remaining functions (option negotiation
and translation between local and network representations) nay be
implemented in either the front end or the host, depending on
local installation constraints. Typically the translation will
be done in the front end. Section IV below discusses the
offloading of Telnet options.
The only support this service requires in the front end is
access to an ARPANET NCP. In the host it is necessary for the
residual part of the Telnet implementation to be able to make its
logical channels appear as if they were terminals connected to
the host. This may require system modification in some cases.
There are several possible ways in which service could be
initiated and controlled. The scheme described in this protocol
appears to be the simplest and most flexible. In this scheme,
BEGIN Commands only go from the host to the front end. When the
front end service module receives a BEGIN Command, it either does
a listen on the contact socket or it sets up a connection as
requested. It sends a BEGIN Response to the host when a
148
8/23/77
NVTS PSF
Description of the Service
connection is established. The host process must generate a
distinct BEGIN Command lor each connection it is willing to
accept. Thus, the host is able to limit the number of Telnet
users by withholding BEGIN Commands. The front end may also
limit demand on its resources by refusing BEGIN Commands from the
hos t .
The network virtual terminal process-to-service protocol
uses HFP Messages to carry information between the residual part
of Telnet in the host (the "process") and the network virtual
terminal service module (the "service") in the front end. A
brief summary of the specific Message types follows.
BEGIN Command
is used to initiate connections.
EEGIN Response
is used to confirm the establishment of a
connection, or to refuse a BEGIN Command.
END Command
is used to terminate a connection.
END Response
is used to confirm the termination.
TRANSMIT Command
is used to transfer data (including Telnet option
negotiations and control functions) to and from the
Telnet connection.
TRANSMIT Response
is used to acknowledge data transfer.
EXECUTE COMMAND
is used by the process to request the service module
a) to send a Telnet control function,
b) to modify the suggested allocation,
c) to negotiate Telnet options, or
d) to report the status of the connection.
149
DRAFT
ft/23/77
NVTS PSP
Description of the Service
is used by the service to pass to the process out-
of-band Telnet control functions (e.g. IP, AO, and
Break) .
EXECUTE Response
a) is used to acknowledge the success or failure of the
action requested by the process via the EXECUTE
Command, and
b) if requested reports on the status of the
connection.
Systems which can easily set terminal parameters may offload many
functions using the EXECUTE Command. For such systems
adaptations of this process-to-service protocol could define
requests in a form that would allow the host to be ignorant of
the actual negotiation mechanism. For instance, an adaptation
could define an EXECUTE Command request to indicate that a
certain system primitive was to be called and given such and such
parameters. Since not all systems can do this, and the means
available to the ones that can differ considerably, we have left
the specification of such features for the adaptation
descriptions.
This process-to-service protocol requires the implementation
in the front end of the following additional protocols:
ARPANET Host-Host Protocol
ARPANET Initial Connection Protocol
ARPANET Telnet Protocol
The details of the use of HFP Messages are given in the
following section.
150
fc/23/77
NVTS P3P
ELGIN Command
III. Message Use
III A. BEGIN Command
III A 1 . When sent
A BEGIN Command is sent by the host process to
indicate that it wishes to establish a Telnet connection.
The host process sends a BEGIN Command for each Telnet
connection it will accept.
Ill A 2. Action on rece i £ t
When the service module receives a BEGIN Command, it
attempts to set up a connection as specified by the
parameters in the TEXT. The service module may refuse the
BEGIN Command by sending an appropriate BEGIN Response.
Ill A 3. TEXT field syntax
Security :
Establishment :
Control-bits :
Init/Listen
Socket /Channe 1
ICP/Direct
Relative/Absolute
Unattachable /Attachable
host :
1* oreicrn Socket :
Mess ages :
Bits:
Local Socket:
Timeout:
field semanti cs
VAhlALLL( ? )
COMPLEX (6 )
F1XED(5)
FIXED(32)
F1XED( 32)
tIXED( 16)
FIXED( 32)
F1XED(32)
F 1 X E D ( 1 b )
III A 4 a. Security
This field may be used by the host to validate the
access privileges of the sender of the BEGIN Command.
The default value of the field is empty. Note: At this
time, very little work has been done on the organization
of security for networks or these kinds of systems. It
is not clear where access control should be placed. This
field has been included in case some systems require
validation at this point.
Ill A 4 o . Establishment
This set of parameters describes the kind of
connection t > te associated with this channel. The
default values of the establishment parameters are
151
DPAFT
8/23/77
NVTS PSP
BEGIN Command
chosen to favor the Server Telnet service. This means
that a BEGIN Command specifying only defaults would
cause the front end to listen for an ICP connection on
the standard Telnet contact socket (socket 1) from any
host for an indefinite period of time. The default
values of the fields are set at zero; the default value
may be indicated by the absence of the field. Thus, a
BEGIN Command sent to the front end for a server Telnet
session may have an empty TEXT field.
Ill A 4 b (1). Control-bUs
The bits in this field govern the kind of
connection to be established and the interpretation
of the parameters.
Ill A 4 b (1) (a), Ijsten/Init
When this bit is zero (default), the connection is
to be passively listened for. When this bit is
one, the connection is to be actively initiated.
The use of this bit in specifying connection
sockets is detailed in table 1.
Ill A 4 b (1) (b). Socket/Channel
If this bit is zero, the logical channel from
the process is to be established to a new ARPANET
connection. If this bit is one, the logical
channel from the process is to be attached to an
already existing HFP channel (e.g. a channel
already established to the host-host service
module and therefore providing access to an
existing network connection.) The default value is
zero .
Ill A 4 b (1) (Q). ICP/Direct
This bit is relevant only when a new network
connection is requested. (Socket/Channel bit is
zero.) When this bit is zero (default), the
connection is to be established via the Initial
Connection Protocol. When this bit is one, the
connection is to be established directly. The use
of this bit in specifying connection sockets is
detai led in table 1 .
Ill A 4 b (1) (d). Relative/Absolute
This field affects the value of the local
sockets for the connection. See III A 4 b (6) for
details. The default case is Relative (value
zero) .
152
fa / ,: 3 / 7 7
NVTS PSt
EEG1N Command
III A k b ( 1 ) ( e ) . Una ttachable/A t tachable
When this bit is one, the network terminal
service module is reauested to make the logical
channel available for attachment bv other service
modules within the front end (such as a data
transformation service). Otherwise this bit is
zero (default). See CAC lechnical f-.emorandum No.
bO, p. 3» for a discussion of this feature.
Ill A 4 b (2) . Host
This field specifies the network hosts from
which (or tc which) the lelnet connection is to be
established. The default value is zero, indicating
that a connection from any host will be accepted.
(The default value is legal only if the Listen/lnit
bit is zero (Listen), otherwise a host must be
specified. )
The host field is parsed as:
Network :
IMP :
host-at-lK P :
frIXEPU)
H X E D ( 1 fc )
t IXED(fa )
III A k b (i). t-oreisrr Socket
This field is used as follows to construct the
e f f ect i ve foreign socket (e.f.s.) for making the
con ne c t i on .
Case 1. foreign Socket field = ?. ero;
Listen/lnit bit = zero. foreign host
choo s es the e.f.s.
Case 2. Foreign Socket field = one; Listen/lnit
bit = zero. The e.f.s. is one.
Case 3- Foreign Socket field i zero. The e.f.s.
is the contents of the Foreirn Socket
field.
1 h e default value of this field is •>. e r o . Ihe
effective foreign socket is used in various ways,
depending upon the values of certain of the control
hits, to effect the connection. See table 1 for
de tai Is .
Ill A 4 b (k) . Message?
'ihis field and the tits field allow the process
to indicate to the service module the flow rate
desirable on the connection. The service module may
use this information in any way its implementors deem
153
DRAFT
8/23/77
NVTS PSP
BEGIN Command
desi rable.
This field contains the number of Host-Host
messages the process suggests be allocated on the
connection. If the value of this field is zero
(default), the service module chooses the number of
messages on its own.
Ill A 4 b (5). bits
This field contains the number of bits the
process suggests be allocated for the connection. If
the value of this field is zero (default), the
service module chooses the number of bits on its own.
Ill A H b (6). Local Socket or Logical Channel
If the Socket/Channel bit is one, this field
contains the channel Group and Member values
specifying the HFP channel to which connection is to
be made. The format of this field is then:
<not used): F1XED(4)
Group: FIXED(12)
Member: FIXED(16)
If the Socket/Channel bit is ze
used as follows to construct th
.l.s.) for making the conne
Relative/Absolute bit
Socket field i zero
contents of the Grou
HEADER will be conca
low-order 20 bits of t
field to form the e.l.s
Relative/Absolute = zer
field = zero. In this
will choose a number wh
bits are equal to the G
HEADER .
Case 3. Relati ve/ Absolu te = one
the effective local s
the contents of the Loc
socket (e.
Case 1 ,
Case 2.
ro , this field is
e effective local
ction .
= zero, Local
In th i s case, th e
p field in the
tenated with the
he Local Socket
o, Local Socket
case, the service
ose high order 12
roup field in the
In this case
ocket is equal to
al Socket field.
The effective local socket is used in various ways,
depending upon the values of certain of the control
bits, to effect the connection. See table 1 for
detai Is .
Ill A * b (7). Timeout
This field contains the maximum length of time,
in seconds, that the service module is to attempt to
154
DRAFT
8/23/77
NVTS PSP
BEGIN Command
establish the connection (in the absence of an error
or exceptional condition). If the service module has
been unable to establish the connection within this
time period, it is to abandon the attempt. If this
field contains zero (default), the time period is to
be infinite.
155
DRAFT
b/23/77
NVTS PSP
EEGIN Command
Tab}? 1
Control Bits i Foreign Sockets ! Local Sockets
j for the connection i for the connection
i IThe e.f.s. will be used!
! las the contact socket |
{ Init i f or the connection. ie.l.s. + 2 and e.l.s. + 3
! jThe data sockets will i
! |be chosen by the for- i
! ! eign host . i
ICp j _ „__ j • „„„ _--.- .
i ! jThe e.l.s. will be used
! ! las the contact socket
! I {for the connection.
[Listen je.f.s. +2 and e.f.s. +3!The data sockets will
! ! ibe chosen by the
i i {service as in Case 2 of
! i ! Ill A 4 b (6).
Direct ! e.f.s. and e.f.s. +1 i e.l.s. and e.l.s. + 1
156
6/23/77
NVTS PSP
PEGIN Response
IU B, BEGIN Respond
III B 1 . When sent
The BEGIN Response is sent by the service module to
indicate that a successful network connection has been
established, or that the BEGIN Command has been refused.
Ill B 2. Action on receipt
When the BEGIN Response is received, the host process
should determine whether a successful connection was made.
If so, it may send or receive data. If not, it may be
appropriate to invoke an error recovery procedure.
Ill B 3, TEXT field syntax
Security :
Connection-info:
Connection-state:
Host:
Foreign Socket:
Messages:
Bits:
Local Socket:
III B 4. TEXT field semantics
111 B 4 a. Security
VARIAELE(?)
COMPLEX( ? )
FIXED (4)
FIXED(32)
FIXED(32)
F1XED( 16)
FIXED(32)
FIXED(32)
This field may be used to allow the front end to
validate the access privileges of the user (in the case
where the front end performs some user authentication
tasks) and to pass the information along to the host.
This field could be particularly important for
monitoring access by terminals directly connected to the
front end.
HI B M bt CpnnecUon-infQ
This field describes the connection associated with
this channel.
Ill B 1 b (1!
Connection-state
This field indicates the success or failure of
the BEGIN Command. The value zero indicates success
while any non-zero value indicates failure. The
particular value of the non-zero field gives the
reason for failure. The possible values of this
field and their meanings are:
157
DRAFT
8/23/77
NVTS PSP
BEGIN Response
0 Success
1 Illegal connection type
2 Invalid local socket
3 Unknown host
4 Improper access
5 Front end terminating service
6 Connection attempt timeout
7 Network not available
b Foreign host dead
9 Connection refused by foreign host
Others may be defined later, or in the adaptation
descriptions.
XII B H b (2), Host
If the connection attempt was successful, this
field contains the ARPANET host address of the host
to which the connection was established. (See III A
4 b (2). )
III B 4 b M). Foreign Socket
If the connection attempt was successful, this
field contains the socket number at the foreign host
to which the connection was established.
If the connection attempt was successful, these
fields contain the flow control parameters for the
connection at the time the BEGIN Response was
generated .
Ill B 4 b (5). loc3l Socket
If the connection attempt was successful, this
field contains the local socket number for the
connection.
158
DRAFT
6/23/77
NVTS PSP
END Command
III C. END Command
III C 1. When sent
III C 1 a, By the process
The END Command may be sent by either the process
or the service to terminate a Telnet connection. If
sent by the process, it usually indicates that the host
has requested that the connection be closed.
Ill C I bt by the service module
The service module may send an END Command because
the foreign host has closed the connection in response
to a user request, or because some failure condition has
occurred that requires that the connection be aborted.
Ill c g, Action on receipt
III C 2 a. By the process
When the process receives an END Command, it should
acknowledge it as promptly as possible by sending an END
Response.
Ill c g b. py the service module
When the service module receives an END Command, it
should close the Telnet connection. Once the connection
is closed, it should send the END Response to the
process .
Ill C ^ TEXT field syntax
Status: FIXED (3)
III C 4 at, Status
This field indicates the cause of the termination
of the TELNET connection. The values of the field and
their associated meanings are:
0 Normal close by foreign host
1 Network failure
2 Foreign host failure
3 User requested close
4 Improper Access
5 Front end terminating service
Other causes for failure may be defined at a later date.
159
DRAFT
8/23/77
NVTS PSP
END Command
The default value of the field is zero.
160
6/23/77
NVTS PSF
END Response
III D. END Response
III D 1 . When sent
The END Response is sent by either the process or the
service module to acknowledge that an cND Command has been
received and proper action taken.
Ill D 2. Action on receipt
When either the process or the service receives an END
Response, it should assume that all dialogue associated
with this logical channel has completed, and it should
ignore any other Commands on this channel except a BEGIN
Command.
Ill D 1. TEXT field syntax
The TEXT field in the END Response is not used in this
protocol .
DRAFT b/23/77 NVTS PSP
TRANSMIT Command
III E. TRANSMIT Command
The description below assumes that a Go-Ahead facility is
needed for the handling of half duplex terminals. Not all
installations will need this facility; those that do not
should set the Go-Ahead/More-Data Control bit to zero and
ignore the specification of how this bit is interpreted.
Ill 6 It When sent
The TRANSMIT Command may be sent by either side to
transfer data. Data may be sent only when the connection
is in the ESTABLISHED state and when the flow control
discipline permits. (See HFP Specification.)
Ill E 2. Action 0n receipt
III E 2 a. by the process
When the process receives a TRANSMIT Command, it
will treat the contents of the Data field of the TEXT as
data to be processed.
Ill g 2 bt By the service module
When the service module receives a TRANSMIT
Command, it will treat the contents of the Data field of
the TEXT as data to be transmitted over the Telnet
connection.
Ill E 3. TEXT field syntax
The TEXT field contains one or more instances of the
following structure.
Control-bits: FIXED(2)
Text/Control
Go-Ahead/ More-Data
Data: VARIABLES)
III E 4, Text field semantics
III e ^ a, control bits
The Control bits indicate the nature and the mode
of the information in the associated Data field being
passed to the process or service.
Ill 6 ** a d)f Text/control
When this bit is zero (default), it indicates
that the Data field contains text to be transmitted.
When this bit is one, it indicates that the Data
162
DRAFT
8/23/77
NVTS PSP
TRANSMIT Command
field contains a specific Telnet
function .
option or control
III 6 » 3 (2). Qo-Ahead/Mpre-Pata
when this bit is zero (default), it specifies
that the sender has transmitted all the data it
wishes and the receiver may now "turn the line
around" and send data. It is convenient for the host
process if the service makes each Data field of the
TEXT correspond to one line of input from the
terminal, including the end-of-line character. (This
may be agreed on by the service and process.) In this
way, only one of the processes must be bothered with
looking for end-of-line sequences. If this bit is
one, there is more data to follow.
Ill E 4 b. Data
If the Text /Con t rol bit is cnc , the Data field uill
contain the text of a Telnet option negotiation or
control function. If the Text/Control bit is zero
(default), the Data field contains text which is to be
transmitted or has been received on the Telnet
connection.
163
6/23/77
NVTS PSP
TRANSMIT Response
III Ft TRANSMIT Response
The TRANSMIT Response is used as described
specification .
in the HFP
164
b/23/77
NVTS PSP
SIGNAL Command
III G. SIGNAL Command
The SIGNAL Command is not used in the process-to-service
protocol. SIGNAL Commands may be generated by process or
service to request that the channel protocol module (CPM)
carry out the appropriate action on the logical channel. (See
HFP specification.) Thus, the effect of the SIGNAL Command is
restricted to the logical channel (HFP) level.
165
DRAFT 6/23/77 NVTS PSP
SIGNAL Response
III H. siqnal Response
The SIGNAL Response is not used by either process or
service.
166
DnAFT
6/23/77
NVTS PSP
EXECUTE Command
III J. EXECUTE Command
By the process
The process sends an EXECUTE Command to request
that the service module
a) send a Telnet control function;
b) modify the suggested allocation;
c) negotiate a Telnet option; or
d) return the status of the connection.
EY the service
The service sends an EXECUTE Command to the process
to notify it that certain Telnet control functions have
been received.
Ill J 2. Action on receipt
When the service module or process receives an EXECUTE
Command, it will decode it and perform the action
indicated. (See below.)
Ill J 3, TEXT field syntax
Code:
Parameters :
FIXED(2)
VARIABLES )
III J 4 TEXT field semantics
III J 4 a. Code
This field contains an encoding of the type of
request. The codes are:
Send control function
Modify suggested allocation
Negotiate Telnet option
Status
III J 4 b. parameters
This field, if present, contains any parameters
necessary to perform the request indicated in the code
field. A discussion of the requests and their
associated parameters follows.
Ill J 4 c. Send Control Function
III J 4 c (1). When sent
167
6/23/77
NVTS PSP
EXECUTE Command
Ev the process
This request is sent to the service to
request the service module to send one of the
out-of-band Telnet control functions (IP, AO,
AYT, or Break) to the foreign host.
By the service
This request is sent by the service to
notify the process that an out-of-band Telnet
control function has been received from the
foreign host.
Ill J 4 c (2). Action on receipt
gy the process
When the process receives a control
function request, it should take whatever action
is required according to the semantics defined
by the Telnet protocol. The only exception to
this is the Abort Output control function. When
the process receives an Abort Output, it should
flush all data buffered for transmission to the
front end. It should insert a Data Mark into
the data stream and send a SYNCH control
function to the front end.
Ey the service
Func
func
stre
acco
serv
func
buff
(exc
Mark
serv
INS
also
host
the
one
disc
Mark
Data
rece
fore
When
tion
tion )
am
r danc
ice
tion ,
ered
ept T
is
ice
me ss
send
(
Data
in
ard d
is
Mark
ived
ign h
the
req
, it
at
e wi
mod
it
fro
elne
det
odul
acre
a T
The
Mark
the
ata
f oun
in
fro
ost .
servi
uest
shoul
the
th the
ule
shou
the
t cont
ected
e shou
to be
elnet
servi
sent
data
coming
d. If
the d
m the
)
ce re
(othe
d ins
earli
Teln
recei
Id f
fro
rol f
in
Id ca
sent
Data
ce
fro
stre
from
the
ata
host
cei ve
r th
er t
est
e t pr
ves
lush
nt
uncti
the
use a
to th
Mar
odule
the h
am ,
the
servi
strea
must
in a
it i
possi
otoco
a
all
nd
ons )
data
n ARP
e for
k to
may
ost o
while
host
ce mo
m , t
not
Sen
SYN
nto
ble
1.
SYNC
dat
nd
unti
st r
ANET
ei*n
th
eith
m
con
unti
dule
he
be s
d Con
CH con
the
point
When
con
it
to the
1 a
earn .
Host-
host ,
e for
er pas
ay in
tinuin
1 the
inser
Data
ent to
trol
trol
data
in
the
trol
has
net
Data
The
Host
and
eign
s on
sert
g to
Data
ts a
Mark
the
168
DRAFT
8/23/77
NVTS PSP
EXECUTE Command
III J 4 c m. Parameter field syntax
Control Function: FIXED(8)
III J 4 c (4). Parameter field semantics
This field contains a Telnet control function.
The possible values and their meanings are:
242
243
244
245
246
SYNCH
Break
Interrupt Process
Abort Output
Are You There
Although there are other Telnet control
functions, they are dependent on their position in
the data stream and thus would not have any meaning
in this context.
Ill J 4 d. Modify suggested allocation
This request is sent by the process to the service
module to modify the allocation suggested in the BEGIN
Command. The service module may use this information in
any way it wishes to modify its flow control strategy
with the network.
Ill J H 0 M). Parameter field syntax
Messages :
Bits :
FIXED( 16)
FIXED(32)
III J 4 d (2). Parameter field semantics
The semantics of the Mepsaces and bits fields
are identical vith those described in sections III A
4 b (4) and III A 4 b (5) .
Ill J 4 e. Negotiate a Telnet option
This process-to-service protocol provides two ways
for the process to negotiate a Telnet option. It may
either do the negotiation itself by placing the option
commands in the data stream or it may request the
service module to perform the negotiation for it. The
latter way uses this variant of the EXECUTE Command. It
should be noted that this method can only be used when
the effect of the option need not be synchronized with
the data stream.
Ill J 4 e (1). Parameter field syntax
169
DRAFT
8/23/77
NVTS PSP
EXECUTE Command
Negotiation: FIXED(b)
Option Code: FIXED(8)
Subnegotiation: VARIAELE(?)
HI J 4 e (2). Parameter field semantics
HI J 4 e (2) (a). Negotiation
This field allows the process to control
option negotiation in general or to control the
negotiation of a particular option. The legal
values of the field are:
1 indicates service module should
refuse all options
2 indicates service module should
not refuse any options (i.e., it
should pass those not done by the
front end to the host process)
3 indicates service module should
refuse any options not handled by
the front end
251 WILL
252 WON'T
253 DO
254 DON'T
The meanings of WILL, WON'T, DO and DON'T are
specified in the Telnet Protocol Specification
[ARPANET NIC 18639]. The initial state (i.e.,
whether options are accepted or not) is an
installation parameter.
Ill J 4 e (2) (b). Option code
This field contains the code for the Telnet
option to be negotiated. The values of these
codes may be found in the specifications of the
respective options.
HI ^ 4 e (2) (c). Subnegotjatjon
This field, if present, will contain one or
more subnegotia ti ons for the option specified by
the option code field. These subnegotiations are
to be performed for the process. Subnegotiation
parameters will be bracketed within this field by
the Telnet control functions IAC SB and IAC SE ,
where
IAC
=
255
SB
=
250
SE
r
240
170
DRAFT
6/23/77
NVTS PSP
EXECUTE Command
III J H f. fteturn gtatvis
No additional parameters are needed for
request .
171
DRAFT
6/23/77
NVTS PSP
EXECUTE Response
III K. EXECUTE Response
III K 1. When sent
The service module sends an EXECUTE Response when
a) it has completed the operation requested by an
EXECUTE Command or
b) it has received an EXECUTE Command whose TEXT is in
error.
Note: In the case of options negotiated by the use of the
EXECUTE Command, the EXECUTE Response is sent after all
subnegotiations have been completed or the option has been
refused .
The process sends an EXECUTE Response to acknowledge
the receipt of a control function.
Ill K 2. Action on receipt
When the process receives an EXECUTE Response, it
should examine the TEXT to see whether the Response
indicates an error. If no error is indicated, it may
consider that the action requested by the EXECUTE Command
was successful. If an error is indicated, appropriate
error recovery action should be initiated. This action is
idiosyncratic to the process.
IU K 1. TEXT field syntax
Result:
Ref-code :
Parameters :
FIXED(3)
FIXEDC3)
VARIABLE(?)
Ill k Mt text field semantic?
XII K 4 a. ResuU
This field contains an encoding of the result of
the request (made in a previous EXECUTE Command) to
which the EXECUTE Response is a reply. The codes are:
0 Success
1 Illegal code in request
2 TEXT too short
3 Illegal or unsupported parameter value
III K it b. Ref-code
This field contains the same value as the Code
field of the TEXT of the EXECUTE Command to which the
EXECUTE Response is a reply.
172
DRAFT
8/23/77
NVTS PSP
EXECUTE Response
III I S c. Parameters
This field, if present, contains additional
information about the outcome of the request. A
discussion of these parameters follows. No parameters
are needed for a Response that acknowledges receipt of a
control function.
Ill K it dt New mipcmpn
These parameters are sent by the service module to
the process in response to a Modify Suggested Allocation
request .
Ul K H d (1). Parameter field syntax
Messages :
Bits:
FIXED( 16)
FIXED(32)
III K k d (2). Parameter field semantics
The semantics of the Messages and Bits fields
are identical to those described in Section III B h b
(4).
Ill k 4 et option negotiation
This reply is sent by the service module in
response to the Negotiate Telnet Option request.
LLL-JL-JL-S LLL. Parameter field SYPtax
Negotiation: FIXED(6)
Option Code: FIXED(8)
Subnegotiation: VARIABLES)
III K 4 e (2)t Parameter field semantics
III K 4 e (2) (a), Negotiation
This field will contain a code indicating the
final outcome of the negotiation. Legal values
are :
250 indicates service module is
currently accepting options
251 WILL
252 WON'T
253 DO
254 DON'T
255 indicates service module is
currently refusing all options
173
DRAFT
b/23/77
NVTS PSP
EXECUTE Response
III M ? (?) (t>) , Option code
This field contains the code of the Telnet
option that was negotiated.
Ill K 4 e (2) (c)t SubneKQUatjon
This field will contain the final state of
any subnegotiations that were performed. The
format will be consistent with the request format
for subnegotiation .
Ill K ** ft SUtvg
This reply is sent by the service module in
response to a status request.
Ill K 4 f (1). Parameter field syntax
The parameter field for this EXECUTE Response is
formatted identically to the connection-info field
specified in the TEXT of the BEGIN Response.
Ill K 4 f (2). parameter Held semantics
This field has the same meaning as the
connection-info field in the TEXT of the BEGIN
Response with the following exception:
III K 4 f (2) (a). Connection-state
This field indicates the present state of the
connection. The possible values of this field and
their meanings are:
0 Closed
1 Open
2 Waiting for open to complete
3 Waiting for close to complete
174
DRAFT
b/23/77
NVTS PSP
Offloading Telnet Options
IV. Offloading Telnet Options
An installation may take one of two two basic approaches to
offloading the Telnet options. One approach is to offload
nothing. In this case, the Telnet service in the front end need
only reformat the data stream, handle the network connections and
(perhaps) do character translation. The other approach is to
offload as much as possible, given the characteristics of the
host. In this case, the front end must also be able to negotiate
and execute some of the Telnet options. Unfortunately, for some
of the Telnet options it is not possible to say definitively
whether they can be offloaded or not. Table 2 can be used as a
guide to how readily the various options can be offloaded.
Two attributes of each option determine whether or not it
can be offloaded. An option nay or nay not affect the host's
terminal-handling parameters. The taking effect of an option Tiay
or may not have to be synchronized with the data stream. If an
option affects the host's terminal-handling parameters, then,
although some of its processing may be offloaded, some processing
will have to be done in the host. If an option requires
synchronization with the data stream, it may be very difficult,
if not impossible, to offload it. Table 2 lists the current
ARPANET Telnet options and indicates whether they may be
offloaded. Some of the options are discussed below in greater
detail. Note that all options that are not supported by the host
may be offloaded, i.e. the front end can refuse negotiations
without involving the host.
175
DRAFT 6/23/77 NVTS PSP
Offloading Telnet Options
Option Nam?
Telnet
Synch
Can
Option
Host
w/Data
Off-
Num.
Pepf?
Stream
load?
H
no
no
yes
0
yes
yes
no
19
yes
yes
yes
20
yes
yes
maybe
1
no
yes
no
17
no
yes
yes
18
yes
no
no
10
no
no
yes
13
no
no
yes
11
yes
no
no
12
no
no
yes
16
no
no
yes
8
?
no
maybe
9
?
no
maybe
n
yes
no
no
15
no
no
yes
2
no
yes
yes
7
yes
yes
no
5
yes
yes
some
3
no
no
yes
6
yes
yes
no
Approximate Message Size
Binary Transmission
Byte Macro
Data Entry Terminal
Echo
Extended ASCII
Logout
Output Carriage Ret. Dispos.
Output Formfeed Dispos.
Output Horz. Tab Stops
Output Horz. Tab Stops Dispos.
Output Linefeed Dispos.
Output Line Width
Output Page Size
Output Vert. Tabstops
Output Vert. Tabstops Dispos.
Reconnection
RCTE
Status
Suppress Go Ahead
Timing Mark
Table 2. Classification of Telnet Options
Elnarv Transmission. In most cases, this option cannot be
offloaded. However, the fact that it has been negotiated may be
of interest to the service module in the front end. If the front
end has been doing (or normally does) some translation tasks for
the host, it will be necessary to coordinate the beginning of
binary data with the cessation of such translation.
Bvte Macro. If this option is supported and any other
options or functions are offloaded, then this option must be
offloaded. This option provides a means for mapping arbitrary
strings into one byte. Therefore, when this option is in effect,
176
DhAFT
6/23/77
NVTS PSP
Offloading Telnet Options
the macro expansion must take place at the earliest point.
Data Entry Terminal (PET). It may be possible to offload all
or part of this option depending on the nature of the host
system. If the host supports only one form of data entry
terminal, then the front end can map many DET option subcommands
into the form required by the local terminals or programs.
Echo. In general, it is not possible to offload this
option, since the process in the host which is connected to this
terminal may wish to echo characters other than those typed.
However, there are cases where it might be desirable if the front
end did handle this option for certain kinds of hosts. For
example, consider computers that support only half-duplex
terminals, such as IBM 360*s, Burroughs 6700's, or Honeywell
6000's. Suppose that a user connects to such a host and asks it
to DO ECHO. It would be quite reasonable to have the front end
handle the echoing and present the host with an apparent line-
at-a-time environment. This would avoid many of the difficulties
of trying to fit a line -at-a-time system into a charact er-at-a-
tip'e mode.
Output Line Width. Once again, the decision to offload this
option rests heavily on how line-width regulation is enforced.
If the regulation of line width is done by simple "line folding",
then this function may be performed by the front end. However,
if regulating line width requires more fundamental adjustments or
more sophisticated action, it is quite likely that it will not be
177
DRAFT
b/23/77
NVTS PSP
Offloading Telnet Options
possible to offload this option.
Output Page Size. The decisions that are relevant for
offloading this option are similar to the ones described for
output-line width. Some systems may interpret the regulation of
page size as follows. The maximum number of lines in a page is
sent. If there is still data to be sent, the sender pauses,
waiting for an input from the user indicating that he is ready to
proceed. If this is the sort of regulation desired when this
option is negotiated, then it can be offloaded. However, if more
fundamental adjustments or more sophisticated action is required,
it may not be possible to offload it.
Remote Controlled Transmission and Echoing. The RCTE
option is meant as a more general mechanism to replace the Echo
option. If RCTE is used to replace the Echo option, then it may
be offloaded under the same conditions as the Echo option.
Otherwise, offloading is not possible and actually defeats the
purpose of the RCTE option.
Status . Since not all options may be offloaded, it is
necessary to offload part of the Status option and to leave part
of it in the front end. It is suggested that the Status option
be handled in the following way:
When the service module in the front end receive?. a Status
option negotiation, it will respond favorably to the request by
sending a WILL STATUS to the sender. It will then relay the
option to the host in the normal manner and wait for a response
178
DRAFT
6/23/77
NVTS PSP
Offloading Telnet Options
from the host. When the host receives the DO STATUS command from
the front end, it will transmit back to the front end the
subnegotiation specifying the state of the options it handles.
When this subnegotiation is received by the front end, it will
insert into this subnegotiation the status of the options it
handles and then it will send the completed subnegotiation to the
foreign host.
If no options are supported in the host or if no options are
supported in the front end, then, of course, this procedure may
be avoided and the whole operation done in the front end or in
the host, respectively. Also it is possible for the front end to
know what options are not supported and supply the default status
in format! on.
Suppress Go Ahead In a sense the Suppress Go Ahead Option
is always offloadable. If the host always penerates go-aheads
then it is no problem for the front end to filter them out when
the option is negotiated. However, it is impossible for the
front end to insert go aheads when the option has its default
value.
Telnet "Svnch" Sequences. In some cases, searching for
"interesting" characters in the data stream may be offloaded.
For example, if the only characters deemed interesting are the
Telnet special characters, then this function may be offloaded.
Or the front end may be provided with a list (on either a .static
or dynamic basis) of strings to be searched for. However, even
179
DRAFT
8/23/77
NVTS PSP
Offloading Telnet Options
if these functions are performed in the front end, they must also
be done in the host before the "synch" sequence is received.)
The only reason for offloadinp this function is to decrease the
response time to the user's request.
180
6/23/77
NVTS PSP
Scenario
V. Scenario
Let us consider how this protocol might be used by a process
in the host to initiate a Telnet connection. We will assume that
as many Telnet functions as possible have been offloaded.
The user initiates a Telnet connection by causing a EEG1N
Command to be sent to the front end:
<BEGINXCXcontrol-bits = initXhost = 12>
Since the default settings for a BEGIN Command favor
listening for a Telnet connection, the Command must in this case
explicitly request that the connection be initiated. The NVT
Service Module (NSM) in the front end will open the Telnet
connection to host 12. Once the connection is established, the
NSM will send a Begin Response to the host:
<BEGINXRXconnection stat e = 0Xhost = 12 Xf orei gn skt = M283>
<msg=10Xbits = 10000Xlskt=5607>
The channel is now established and data can flow. Almost
immediately the system herald message arrives from host 12 and is
passed to the local host:
<TRANSMlTXCXtext , Go-ahea d>Cen t er for Adv.
Computation<CRLF>Please log in:
(Since TRANSMIT Responses require no action by either the
service or the process, they will not be shown in this example.)
The process wishes to have the remote Telnet implementation cease
181
DRAFT
fa/23/77
NVTS PSP
Scenario
echoing characters. So it requests the front end to negotiate
with the remote Telnet process:
<EXECUTE><C><code=2><D0N'T><option code=1>
The NSM in the front end enters into an option negotiation
with the remote Telnet process and is successful in stopping the
remote character echoing. The NSM then informs the process:
<EXECUTEXRXresult = OX ref- coder 2>< WON' T>
<option code=1>
The user now continues with his Telnet session, sending data
to the remote host and receiving responses from it. Data and
responses are transferred between the host and the front end by
TRANSMIT Commands.
182
6/23/77
NVTS PSP
References
VI. References
1. Postel, Jon, "Telnet Protocol Specification," NIC #15372,
Aug. 1973-
2. Postel, Jon, "Telnet Option Specifications," NIC #15373, Aug.
1973.
3. Postel, Jon, "Telnet Binary Transmission Option," NIC #15389.
4. Postel, Jon, "Telnet Echo Option," NIC #15390.
5. Postel, Jon, "Telnet Reconnection Option," NIC #15391.
6. Postel, Jon, "Telnet Suppress Go Ahead Option," NIC #15392.
7. Postel, Jon, "Telnet Status Option," NIC #16237.
8. Postel, Jon, "Telnet Timing Mark Option," NIC #16238.
9. Postel, Jon, "Telnet Extended-Options-List Option," NIC
#16239.
10. Walden, David C, "Telnet Output Line Width Option," NIC
#20196, November 1973-
11. Walden, David C., "Telnet Output Page Size Option," NIC
#20197, November 1973.
12. Crocker, D.H. and Postel, J.B., ''Remote Controlled
Transmission and Echo Telnet Option," NIC #19059, November 1973-
13. Crocker, D.H., "Telnet Output Carriage-Return Disposition
Option," NIC #31155 (RFC 652), October 1974.
14. Crocker, D.H., "Telnet Output Horizontal Tabstops Option,"
NIC #31156 (RFC 653), October 1974.
15. Crocker, D.H., "Telnet Output Horizontal Tab Disposition
Option," NIC #31157 (RFC 654), October 1974.
16. Crocker, D.H., Telnet Output Formfeed Disposition Option,"
NIC #31158 (RFC 655), October 1974.
17. Crocker, D.H., Telnet Output Vertical Tabstops Option,'
#31159 (RFC 656), October 1974.
NIC
18. Crocker, D.H., Telnet Output Vertical Tab Disposition
Option," NIC #31160 (RFC 657), October 1974.
19. Crocker, D.H., "Telnet Output Linefeed Disposition", NIC
#31161 (RFC 656), October 1974.
183
DRAFT
8/23/77
NVTS PSP
References
20. Crocker, D.H., "Telnet Byte Macro Option", RFC 729, 1977.
21. Day, John, "Offloading ARPANET Protocols to a Front End", CAC
Document No. 230, Center for Advanced Computation, University of
Illinois at Urbana-Champai *?n , 1977.
22. Day, John, "Telnet Data Entry Terminal Option", RFC 731,
1977.
23. Grossman, G.R., "ARPANET Host-Host Process-t o-Service
Protocol Specification", CAC Technical Memorandum No. 80, Center
for Advanced Computation, University of Illinois at Urbana-
Champaign, 1977.
24. Grossman, G.R., "Hos t-t o-Fron t-End Protocol Specification",
RFC 7 10, 1977.
IRA
Appendix 5
User FTP
Process- to-Service
Protocol Specification
CAC Technical Memorandum 101
by
John Day
User FTP
Process-to-Service Protocol
Speci f ication
I, s.e_r_ylce Cole JLumb e_r
7
II. Description of the Service
This document is a process-to-service protocol (PSP)
specification as defined in the Host-to-Front-End Protocol (HFP)
Specification [ARPANET RFC 710]. It specifies a process-to-
service protocol for providing user file transfer protocol (FTP)
services to a process through the HFP.
The file transfer protocol [5] is a protocol for
transferring files between hosts on the ARPANET. FTP provides
the mechanisms not only for file transfer, but also for various
file management functions such as deleting and renaming files. A
user FTP session requires two facilities: 1) an FTP interpreter
to send FTP commands, receive FTP replies and control tl a
transfer; and 2) a data transfer facility at each host to
actually move the data and to perform any data translation
required. This document specifies a process-to-service protocol
that provides a process-oriented, rather than a human-oriented,
interface to a user FTP module (FTP interpreter) in the front
end. This process-to-service protocol would be used by resource
sharing or distributed computing application programs. In
essence, this PSP allows the user FTP interpreter to be offloaded
187
6/23/77
User FTP PSP
Description of Service
while leaving the user interface in the host. This process-to-
service protocol is analogous in many ways to the network virtual
terminal process-to-service protocol [3]-
This PSP is used in conjunction with the File Access PSP to
offload the user side of FTP. This PSP is used in two offloading
schemes (see CAC Document No. 230) that differ only in whether
data translation is done in the host or in the front end. In
either case it may be necessary for information to be passed
either between the user FTP service module and the file access
service module in the front end or between the user FTP interface
and the file access module in the host.
The user FTP process-to-service protocol uses H F P Messages
to carry information between the process and the service module.
A brief summary of the function of specific Message types
follows .
BEGIN Command
from the host process
requests that an FTP connection be established.
BEGIN Response
from the service module
a) confirms the establishment of the connection or
b) reports the reason for failure.
END Command
from the process
requests the closing of the connection.
from the service module
reports the closing of the connection by the
foreign host, or reports a system failure.
ENP Response
from the process
acknowledges the closing of the connection,
from the service module
188
b/23/77
User FTP PSP
Description of Service
acknowledges the closing of the connection.
189
DRAFT
b/23/77
User FTP PSP
Description of Service
TRANSMIT Command,
from the process
carries FTP commands (perhaps encoded) to the
service module for transmission to the foreign
host over the ARPANET.
fro;n the service module
carries FTP replies (perhaps encoded) received
over the ARPANET to the process.
TRANSMIT fiesp onse
is used to acknowledge receipt of FTP commands and
replies .
EXECUTE Command
from the host process
requests that the service module
a) report the status of a connection;
b) send a special control function to the
foreign host; or
c) modify the allocation on the connection.
EXECUTE Response
from the service module
a) acknowledges the success or failure of the
action requested by the process via the EXECUTE
Command and,
b) if requested, reports on the status of the
connec tion .
This service requires implementations in the front end of
the following additional protocols:
ARPANET Host-Host Protocol
ARPANET Initial Connection Protocol
ARPANET Telnet Protocol
ARPANET File Transfer Protocol (user side)
File Access Process -to-Servi ce Protocol
The implementation of the file access process-to-service protocol
and an interface to this PSP are required in the host.
190
DRAFT
8/23/77 User FTP PSP
Description of Service
The detailed specification of the use of HfrP hessases
follows .
191
DRAFT
b/23/77
User FTP PSP
BEGIN Command
III. Message Use
III A. BEGIN Command
III A 1 . When sent
A BEGIN Command is sent by the process to request that
the service module attempt to establish an ARPANET FTP
connection .
Ill A 2 . Acti on on receipt
When the service module receives the BEGIN Command, it
will attempt to establish the FTP connection according to
the parameters in TEXT.
VARIABLE( ?)
COMPLEX(b )
BIXED(4)
III A 3. TEXT field syntax
Security :
Establishment :
Control-bits :
Socket/Channel
ICP/Direct
Relative/Absolute
Unattachable/Attachable
host: FIXED(32)
Foreign Socket: FIXED (32)
Messages: FIXED(16)
Bits: FIXED(32)
Local Socket: FIXED(32)
Timeout: FIXED(16)
III A 4. TEXT field semantics
III A
This, field can be used to validate the process'
access privileges to network resources. It is
particularly important to limit access to network
security objects. The substructure and content of this
field are installation dependent.
NOTE: At this writing, not enough is known about
security in networks and front ends to make any
statement about the utility of validation at this point
in the system. This field is included in case some
systems require validation at this point.
192
tt/23/77
User FTP PSP
BEGIN Command
III A jj b. Establishment
the
esta
FTP
the
fore
an I
an
pro t
zero
the
end
fore
Thi
net
blis
ser
f'ron
ictn
CP t
FTP
oco 1
a
i iel
to
ign
s set
work
hmen t
vi ce .
t end
host
o the
con
Th
defau
d . T
esta
host .
of par
connec
pararae
This
specif
field w
FTP co
trol c
e defau
It valu
hus , mo
blish
ame t er
ti on .
t ers a
mean
ying o
ould c
n ta ct
onnec t
It val
e may
st bEG
an FTP
s erove
The
re oho
s that
nly d
aus e t
ocket
ion i
u e s of
be ind
IN Com
s e s s i
rn s
def
sen
a b
ef au
he f
( so
the
icat
ma nd
on w
the es
aul t
to fa
EGIN C
Its
ront e
eke t 3
ccorda
field
ed by
s sent
i 11 on
ta blish
va lues
vor th
omman d
xcep t
nd to i
) and
nee wi
s are
the a bs
to the
ly spec
ment of
for the
e user
sent to
in the
n i t i a t e
set up
th the
set at
e n c e of
f ron t
ify the
III A H b ( 1 ) . Control-bits
The bits in this field covern the kind of
connection to be established, the method of its
establishment, and the interpretation of the
parameters .
Ill A 4 b (1) (a). Socket/Channel
III A 4 b ( 1 ) ( b) . ICP/Direct
When this bit is zero (default), the
connection is to be established via the Initial
Connection Protocol. When this bit is one, the
connection is to be established directly to the
specified foreign socket. The use of this bit in
specifying connection sockets is detailed in table
1 .
Ill A 4 b (1) (c). Relative/Absolute
This field affects the values of the local
sockets for the connection. See III A k b (6) for
details. The default case is Relative (value
zero ) .
193
6/23/77
User FTP PSP
EEGIN Command
III A 4 b (1) (d). Vnattachable/Attachable
When this bit is one, the service module is
requested to make the logical channel available
for attachment by other service modules within the
front end (such as a data transformation service).
If this bit is zero (default), the service module
is not requested to make the logical channel
available for attachment within the front end.
HI A 4 b (2). host
This field specifies the network host to which
the connection is to be made. No default value of
this field is specified in the PSP. If this field is
to have a default value, the value and its meaning
must be specified in the adaptation description.
The Host field is parsed as:
Network :
Imp :
host-at-Irrn:
FlXFD(b)
F I X E D ( 1 6 )
F I X E D ( o ) .
Foreign So eke t
This field is used as follows to construct the
effective foreign socket (e.f.s.) for ma kins? the
connection .
Case 1. Foreign Socket field = zero. The e.f.s.
is three.
Case 2. Foreign Socket field i zero. The e.f.s.
is the contents of the Foreign Socket
field.
The default value of this field is zero. The e.f.s.,
in conjunction with the ICP/Direct bit, is used to
determine the foreign sockets for the connection. See
table 1 for details.
Ill A 4 b (4) . Messages
This field and the Bits field allow the process
to indicate to the service module the flow rate
desirable on the FTP data connection. The service
module may use this information in any way its
implementors deem desirable.
This field contains the number of ARPANET Host-
Host messages the process suggests be allocated on the
connection. If the value of this field is zero
(default), the service module chooses the number of
194
b/23/77
User FTP PSP
BEGIN Command
messages on its own.
Ill A 4 b (5) . bits
This field contains the number of bits the
process suggests be allocated for the FTP data
connection. If the value of this field is zero
(default), the service module chooses the number of
bits on its own.
Ill A 4 b (6) . Local Socket
This field is used as foil
effective local socket (e.
connection .
Case 1. Relative/Absolute
Socket field i z
contents of the Gr
will be concaten
20 bits of the Loc
the e . 1 . s .
Case 2. Re la t i ve/ Absolu te
Socket field = z
service will choos
order 12 bits
field in the HEADE
Case 3. Relative/Absolute
case the effectiv
to the contents
field.
ows to construct
l.s.) for making
the
the
bit = zero , Loca 1
ero. In this case, the
oup field in the HLADth
ated with the low-order
al Socket field to form
bit = zero , Loca 1
ero. In this case, the
e a number whose high
are equal to the Group
R.
bit = one . In this
local socket is equal
of the Local Socket
The relationship between the e.l.s. and the local
socket values depends upon the value of the ICP/Direct
bit. See table 1 for details.
Ill A H b (7) . Timeout
This field contains the maximum length of time, in
seconds, that the service module is to attempt to
establish the connection (in the absence of an error or
exceptional condition). If the service module has been
unable to establish the connection within this time
period, it is to abandon the attempt. If this field
contains zero (default), the time period is to be
infinite.
195
DRAFT
b/23/77
User FTP PSP
BEGIN Command
IfiLJLl.fi 1
i Control Bits i Foreien Sockets ! Local Sockets i
j ! for the connection | for the connection !
! iThe e.f.s. will be used! !
i ias the contact socket I !
i ICP i f or the connection. ie.l.s. + 2 and e.l.s. +3i
i IThe control connection ! I
! isockets will be chosen ! i
! i by the foreign host . ! !
i Direct i e.f.s. and e.f.s. +1 i e.l.s. and e.l.s. + 1 !
196
6/23/77
User FTP PSF
EEGIN Response
III B. BEGIN Response
III B 1. When sent
A BEGIN Response is sent by the service module to
report the outcome of an attempt to establish an FTP
connection requested by a BEGIN Command. The Status field
in the HEADER will indicate whether the connection attempt
was successful or unsuccessful.
Ill B 2. Action on receipt
When the process receives a BEGIN Response indicating
a successful connection, it may proceed to send and receive
data on the connection. When the process receives a BEGIN
Response indicating an unsuccessful connection, it should
perform the appropriate error recovery.
Ill B 3t TEXT field syptay
Connection-info :
Connection-state:
Host:
Foreign Socket:
Messages:
Bits:
Local Socket:
COMPLEX(b)
FIXED(4)
FIXED(32)
FIXED ( 32)
FIXED ( 16)
FIXED (32)
F1XKD(52)
III B 4. TEXT field semantics
III B 4 a. Connection-state
If the connection attempt was successful (as
indicated by the Status field in the HEADER), this field
will contain the value 1 which will be compatible with
the "open" state value defined for this field in the
TEXT of the EXECUTE Response. (See section III K 4 c
(1). )
If the connection attempt was unsuccessful, this
field contains an encoded reason for the failure. Ihe
codes are:
Illegal control bit combination
Invalid local socket
Invalid host
Connection attempt timeout
Network not available
Foreign host dead
Connection refused
Front end terminating service
Network connection incompletely specified
197
DRAFT
6/23/77
User FTP PSP
BEGIN Response
in e ** Ot vq$%
If the connection attempt was successful, this
field contains the ARPANET host address of the host to
which the connection was established. (See III A 4 b
(2). )
IU E ** Ct Foreign Socket
If the connection attempt was successful, this
field contains the socket number at the foreign host to
which the connection was established.
Ill B k d. Messages and Eits
If the connection attempt was successful, these
fields contain the flow control parameters for the
connection at the time the BEGIN Response was generated.
Ill B it e. Local Socket
If the connection attempt was successful, this
field contains the local socket number for the
connection .
198
DRAFT
6/23/77
User FTP PSP
END Command
III C. END Command
III C 1 . When sent
III C 1 a. By the process
An END Command is sent by the process to request
the service module to close the network connection.
Ill C 1 b. by the service module
An END Command is sent by the service module to
notify the process that the connection has been closed
by the foreign host or by a failure of the foreign host
or the network.
Ill C 2, Action on receipt
III C Z a. By the process
When the process receives an END Command, it should
consider the connection closed. The process should send
an END Response and take appropriate recovery action.
Ill C 2 b> 3y the service module
When the service module receives an END Command, it
should allow data queued for transmission to the network
to drain, unless Flush awav (bit 1) is set in the
Control field. It should then initiate the process of
closing the connection. When the connection is closed,
the service module should send an END Response.
HI C 1, TEXT field syntax
Cause: FIXED(3)
III C M. TEXT field semantics
III C *4 a. Cause
This field contains an encoded reason
the END Command. The codes are:
0 Normal completion (default)
1 Network/process failure
2 Foreign host failure
3 User requested termination
4 Front end terminating service
for sending
199
DRAFT
b/23/77
User FTP PSP
END Response
III D. END Response
III p 1 at By the process
The END Response is sent by the process to
acknowledge the receipt of an END Command and complete
the termination of the associated logical channel.
Ill D 1 b. Bv the service module
The END Response is sent by the service module to
acknowledge receipt of an END Command, notify the
process that the connection has been closed as
requested, and terminate the logical channel.
Ill D 2, Actjon on receipt
III D 2 at py the process
When the process receives the END Response, it
should consider the ARPANET connection to be closed and
the HFP logical channel to be terminated.
Ill P 2 b. Pv the service module
When the service module receives the END hesponse,
it should consider the logical channel to be terminated.
HI D 3. TEXT fjeld_sxDlax
The TEXT field in the END Response is not used in this
protocol .
200
DRAFT
6/23/77
User FTP PSF
TRANSMIT Command
III E. TRANSMIT Command
III E 1 . When sent
III E 1 a. Bv the process
The TRANSMIT Command is sent by the process to pass
FTP commands to the service module for transmission over
the network to the foreign host.
Ill E 1 b. Bv the service module
The TRANSMIT Command is sent by the service module
to pass FTP replies that have arrived over the network
from the foreign host to the process.
Ill £ 2. ActiQh on recej.pt
III E 2 a. Bv the process
When the process receives a TRANSMIT Command, it
will treat the contents of the TEXT as FTP replies to be
processed. (See section IV tor details.)
Ill E 2 b. By the service module
When the service module receives a TRANSMIT
Command, it will treat the contents of the TEXT rs FTP
commands to be transmitted over the network. (See
section IV for details.)
Ill E 3. TEXT field syntax
Control: FIXED(1)
Go-Ahead/More-Data
Data: VARIAhLh(?)
Ill E 4. TEXT field semantics
III E H a. Control
The single bit in this field indicates whether or
not the sender of the TRANSMIT Command has completed
sending data. It is used to facilitate handling half-
duplex terminals connected to the process. The receiver
of a TRANSMIT Command with this bit set to 0 (default)
should assume that the sender has completed sending d^i?
and that the receiver is now free to send any data that
it has. If the bit is set to 1 the sender has more data
to send and the receiver should not send data at this
t ime .
201
DRAFT
6/23/77
User FTP PSP
TRANSMIT Command
III E 4 b. Data
The Data field contains the FTP commands and
replies to be transferred. For more details see CAC
Document 230, and section IV.
202
DRAFT
8/23/77
User FTP PSP
TRANSMIT Response
UJL
The TRANSMIT Response is used
specif i cation .
descri bed in the
203
6/23/77 User FTP PSP
SIGNAL Command
III G. SIGNAL Command
The SIGNAL Command is not used in the process-to-service
protocol. SIGNAL Commands may be generated by process or
service to request that the CPM carry out the appropriate
action on the logical channel. (See HFP specification.)
Thus, the effect of the SIGNAL Command is restricted to the
logical channel level.
204
DRAFT
6/23/77
User FTP PSP
SIGNAL Response
III H. SIGNAL Response
The SIGNAL Response is not used by either process or
service.
205
6/23/77
User FTP PSP
EXECUTE Command
III J. EXECUTE Command
XII J 1. Whep Sent
The process sends an EXECUTE Command to request the
service module to
a) report the status of a specified connection,
b) send a Telnet control function,
c) handle Telnet options and FTP replies, or
d) modify the allocation for the connection.
The service module does not send EXLCUTE Commands for this
protocol .
Ill J 2. Action upon Receipt
When the service module receives an EXECUTE Command it
will decode and act on the request.
FIXED(2)
VARIABLE( ?)
Ill J V TEXT fjejd syntax
Code:
Parameters :
III J M. TEXT fiejd semantics
III J 4 a. Code
This field contains an encoding of the type of
request. The codes are:
0 Report status
1 Send control function
2 Handle Telnet options and FTP replies
3 Modify suggested allocation
III J 4 b. Parameters
This field contains the parameters for specifying
the requests. The contents will vary according to the
type of request.
Ill J 4 b (1). Report status
No parameters are required.
Ill J ^ b (2). Send control function
III J ** b (2) (a), Parameter_fjel4 syntax
Control Function: FIXED (b)
206
6/23/77
User FTP PSP
EXECUTE Command
III J 4 b (2) (b). Parameter field semantics
This field contains a parameter specifying a
Telnet control function that the User FTP module
should send on the control connection. The
parameter values and their meanings are:
242 SYNCH
243 Break
244 Interrupt process
245 Abort output
246 Are you there
III J 4 b (^). Handle options and FTP replies
III J 4 b (1) (a). Parameter fie Id syntax
Option control:
Reply text control:
F I X E D ( 2 )
FIXED( 1 )
III J 4 b (3) (b). Parameter field semantics
These fields contain parameters that indicate
1) how the front end should respond to Telnet
option negotiations on the control connection or
2) whether or not the front end should forward the
text of FTP replies to the host. How Telnet
options and FTP replies are handled before the
process sends the relevant EXECUTE Commands is
installation-specific and must be specified in the
adaptation description. The parameter values and
their meanings are:
Option control values:
1 Refuse all options
2 Refuse no options
3 Refuse options not handled by the
front end
Reply text control values:
0 Send FTP reply text
1 Don't send FTP reply text
L J 4 b ( 4 ) . Modi f v sug gested allocation
III J 4 b (4) (a). Parameter field syntax
Mess ages :
Bits:
FIXED( 16)
FIXED(32)
III J 4 b (4) (b). Parameter field seman tics
The semantics of this field are identical
207
DRAFT
b/23/77
User FTP PSP
EXECUTE Command
those described for the allocation fields in the
BEGIN Command. (See sections III A i* b ( H ) - III
A J* b (5). )
208
DRAFT
6/23/11
User FTP PSP
EXECUTE Response
III K. EXECUTE Response
III K 1. When Sent
The service module sends an EXECUTE Response when
a) it has completed the operation requested by
EXECUTE Command, or
b) it has received an EXECUTE Command whose TEXT
in error.
EXECUTE Responses for this
The process does not send
process-to-service protocol.
Ill K 2. Action on Receipt
When the process receives an EXECUTE Response, it
should examine the TEXT to see whether the Response
indicates an error. If no error is indicated, it may
consider that the action requested by a previous EXECUTE
Command was successful. If an error is indicated,
appropriate error recovery action should be initiated.
This action is idiosyncratic to the process.
Ui K 3. text field syntax
Result: FIXED(2)
Ref-Code: F1XED(2)
Connection-info: COMPLhX(?)
Control connection-state: FIXED(2)
Data connection-state: FIXED(2)
Host: FIXED(32)
Foreign Socket: FIXED(32)
Messages: FIXED(16)
Bits: FIXED(32)
Local Socket: FIXED(32)
III K 4. TEXT field semantics
III K M a. Result
This field contains an encoding of the result of
the request (made in a previous EXECUTE Command) to
which the EXECUTE Response is a reply. The codes are:
Success
Illegal code in request
TEXT too short.
Ill K 4 p. Ref-code
This field contains the same value as the Code
field of the TEXT of the EXECUTE Command to which the
209
DRAFT
6/23/77
User FTP PSP
EXECUTE Response
EXECUTE Response is a reply.
Ill K 4 c. Connection-Info
This field is present only if the Ref-code has a
value of zero or three (status or modify allocation).
The semantics of this field are identical with the
Connection-info field of the BEGIN Response (section III
B 4) with the following exception.
Ill K 4 c (1). Control connection-state
If the ref-code value is zero (status), this
field indicates the present state of the FTP control
connection. The possible values of this field and
their meanings are:
0
1
2
3
III K 4 c (2).
Closed
Open
Waiting for open to complete
Waiting for close to complete
Data
pn-s tat e
If the ref-code value is zero (status), this
field indicates the present state of the FTF Data
connection. The possible values of this field and
their meanings are:
0 Closed
1 Open
2 Waiting for open to complete
3 Waiting for close to complete
210
DRAFT
6/23/77
User FTP PSP
Details of Offloading
IV. Details of Offloading User FTP
The ARPANET File Transfer Protocol consists of two TiRjor
sections: a command-and-response section and a data transfer
section. The file access process-to-service protocol deals with
offloading the data transfer portion, while this protocol and the
program access process-to-service protocol deal with different
ways of offloading the command-and-response section.
The program access process-to-service protocol offloads the
entire command-and-response section including the user interface.
Thus programs which wish to use FTP are required to deal with the
human-oriented interface of the front end. The user FTP
process-to-service protocol defines an offloading scheme more
appropriate for the use of FTP by programs. Alternatively, one
can view this protocol as defining an offloading scheme that
leaves the user interface in the host.
In this protocol, the TRANSMIT Command can be used to send
FTP commands and replies between the service module and the
process. Some installations may wish to send some intermediate
form or encoding peculiar to their host's file system or user
interface and let the service module in the front end translate
into the proper FTP Commands. For most installations, the best
method of encoding this information is to just send the FTP
commands themselves. Since many of the parameters are character
strings, little is saved by additional encoding. The only major
exceptions would be the data transfer parameter commands such as
211
DRAFT
8/23/77
User FTP PSP
Details of Offloading
TYPE, MODE, etc. Similar arguments hold for the replies.
Because of the semantics attached to the individual decimal
digits, some coding would be possible, but of limited utility.
Some installations may wish to use the control function described
in Section III J H b (3) to send only the reply code to the
process and not the full text of the reply. Section V gives a
suggested structure for encoded FTP commands and replies.
File transfers can be handled in two ways: either the host
or the front end controls the transfer. In either case the
transfer is mediated by the file access process-to-service
protocol. If the transfers are controlled from the host (i.e.,
the using file access module in the host), then the process will
supply the file access service module in the host with the local
file name. Thus, the FTP file transfer commands (e.g. RETR,
SEND, etc.) can be sent as they are defined in the protocol to
the front end. However, if the transfers are controlled from the
front end (i.e., by the using file access module in the front
end), the process must inform the service module in the front end
of the names of both the local file and the remote file to be
used in the transfer. This will require that both pathnames
(local and foreign) be passed to the front end. For further
discussion of FTP offloading see [4].
21?
DRAFT
6/23/77
User FTP PSP
Encoding of FT? Commands
V. Suggested Encoding of FTP Commands and heplies
V A . Command Syntax
Code:
Parameters
FIXEDC5)
VARIABLE*?)
V A 1. Command Semantics
V A 1 a. Code
This field contains a code which represents
particular FTP command. The values are:
0
USER
1
PASS
2
ACCT
3
REIN
4
BYE
5
BYTE
6
SOCK
7
PASV
6
TYPE
9
STRU
10
MODE
1 1
RETR
12
STOR
13
APPE
14
ALLO
15
REST
16
RNFR
17
RNTO
1b
ABOR
19
DELE
20
LIST
21
NLST
22
SITE
23
STAT
24
HELP
V A 1 b. Parameters
This field contains any parameters necessary
the commands. They are encoded as follows:
for
V A 1 b (1). Parameters for USER, PASS, ACCT
Access Parameter: VARIABLE( )
V A 1 b ( 2 ) . Param eters for Data Transfer Commands
Byte Size:
Socket :
FIXED(8)
FIXED(32)
DRAFT
8/23/77
User «TP PSP
Encoding of FTP Commands
Type:
Stru:
Mode:
Alio:
File Transfer:
Foreign path :
Local path:
F1XED(4)
FIXED( 1 )
FIXED(2)
FIXED( )
C0MPLEX(2)
VARIAbLt(?)
VARIAbLE(? )
V B, Reply syptax
Reply code:
Reply text :
FIXED( 10)
VARIABLES )
The three-digit reply codes are coded as
Bits 0-2: 1st digit
Eits 3-5: 2nd digit
Bits 6-9: 3rd di*it
214
DRAFT
6/23/77
User FTP PSP
Scenario
VI. sgenario
Let us consider how this protocol might be used to offload a
user FTP which has its user interface in the host and uses the
file access process-to-service protocol to transfer files. The
using file access module (UFAM) and the data translation
functions are in the front end.
The user initiates the host's user FTP process (UFP) and
asks for a connection to ILL-CAC. The UFP notes that this is a
normal FTP request and sends a BEGIN Command to the front end
specifying only the foreign host (the other parameters have their
default values) :
<BEGINXCXsecurity = day,johnXcontrol-bits=0Xhost=12>
The user FTP service module (UFSto) in the front end will
then attempt an ICP to socket 3 (the FTP contact socket) at ILL-
CAC. Once the connection is established the UFSto will return a
BEGIN Response to the UFP indicating the outcome:
<EEGINXRX?tater1Xhost=12X foreign skt = 4399Xmsg=H>
<bits=2000X1skt = 23b3>
Later the herald message arrives from the FTP server at
ILL-CAC and is passed to the UFP:
<IRANSMITXC>300 Center for Adv. Computation. Please locr
in:
215
DRAFT
6/23/77
User FTP PSP
Scena rio
(Since TRANSMIT Responses require no action by either the
service or the process, they will not be shown in this example.)
The user now sends the FTP USER command which is passed from the
UFP to the UFSM and on to the net:
<TRANSMITXOUSER day
(The UFSM notes what command is being sent so that it can
know what replies it should expect in return. For most commands
this is mainly an integrity check on the operation of the server.
However, for the data transfer commands the replies indicate the
state of the transfer and may have an effect on the control of
the data connection.) The response comes from the server FTP and
is passed on to the UFP:
<TRANSMITXC>331 Please enter password
The user enters the FTP PASS command and it is passed to the
UFSM:
<TRANSMITXOPASS John
This command is then sent to the server FTP. khen the
response arrives it is passed to the UFP:
<TRAKSMITXC>230 User logged in for file transfer
The user now wishes to move a file from the server to a
local file on the host. Since such transfers are initiated and
controlled by the UFAM in the front end, both the local and
remote pathnames must be passed to the front end. The following
216
6/23/77
User FTP PSP
Scenario
command is sent to the UFSM:
<TRANSMITXORETR junk. note to note, junk
where the first pathname is the remote one and the second the
local one. The UFSM will send the portion:
RETR junk. note
to the server FTP, initiate a data connection on the default data
socket, and pass the second pathname, the local port and security
information to the UFAM. The UFAM will then establish a session
with the host and begin transfer of data into the host. Once the
transfer has begun the server FTP will send a 125 reply which
will be passed on to the UFP:
<TRANSMITXC>125 File Transfer begun
After the transfer has completed the server FTP will send a 226
which will be passed on to the UFP:
<TRANSMITXC>226 File Transfer completed
Suppose that the user then wishes to delete the file he has
just transferred. The UFP sends an FTP DELE command to the UFSM:
<TRANSMITXODELE junk. note
The UFSM passes the TEXT of this message on to the server
FTP. Later a reply is returned and passed on the UFP:
<TRANSMITXC>250 File junk. note deleted
217
b/23/77
User FTP PSP
Scenario
The user then wishes to terminate the FTP session. The UFP
passes an FTP QUIT command to the UFSM:
<TRANSMITXOQUIT
The UFSM passes the QUIT on to the server FTP. The server
FTP responds with a 221 reply. However, before this reply is
received the UFP terminates the channel by sending an END
Command :
<ENDXCXs tat us = 0> (indicating normal termination)
and the UFSM replies promptly with:
<ENDXR>
The UFSM is then left to close all network connections in
accordance with the FTP protocol and to notify the UFAM to
terminate its session also.
218
6/23/77
User FTP PSP
References
VII. References
1. Day, J. "Server FTP Process -to-Servi ce Protocol," CAC
Technical Memorandum No. 100, Center for Advanced Computation,
University of Illinois at Urbana-Champai *n , 1977.
2. Day, J. "File Access Process-t o-Ser vi ce Protocol," CAC
Technical Memorandum No. 102, Center for Advanced Computation,
University of Illinois at Ur bana-Champ ai c;n , 1977.
3. Day, J. "Network Virtual Terminal Process-t o-Service
Protocol," CAC Technical Memorandum No. 103. Center for
Advanced Computation, University of Illinois at Urbana-
ChampaiKn, 1977.
4. Day, J. "Offloadine ARPANET Protocols to a Front End," CAC
Document No. 230, Center for Advanced Computation, University
of Illinois at Urbana-Champai *n , 1977.
5. Neigus, N.
1973.
•The File Transfer Protocol,
ARPANhl
RFC 542,
6. Nei<?us, N; Poerran, K.; and Postel, J.
Reply Codes," ARPANET RFC 6U0, 1974.
■A New Schema for FTP
7. Postel, J. "Telnet Protocol Specification," NIC #1b639, 1973.
21Q
Appendix 6
Server FTP
Process -to-Service
Protocol Specification
CAC Technical Memorandum 100
by
John Day
221
Server FTP
Process-to-Service Protocol
Specification
I. Service Code Number
II. Description of the Service
This document is a process-to-service protocol specification
as defined in the Host-to-Front-End Protocol (HFP) Specification
[ARPANET RFC 710]. It describes a protocol for offloading the
server side of the ARPANET File Transfer Protocol [ *J ] .
The file transfer protocol (FTP) is a protocol for
transferring files between hosts on the ARPANET. FTP provides
the mechanisms not only for file transfer, but also for various
file management functions such as deleting and renaming files. A
Server FTP session requires an FTP protocol interpreter to
control the transfer and to perform the file management
operations and a data transfer process to actually move the data
and to perform any translations between the network data
representation and the local data representation. The file
access process-to-service protocol deals with offloading the data
transfer section. The server FTP process-to-service protocol
deals with offloading the command-and-response section. Of the
twenty-five FTP commands defined in the protocol, only seven must
be done by the residual server FTP process in the host. The
others are handled by either the file access service module or
DRAFT
b/23/77
Server FTP PSP
Description of Service
the server FTP process in the front end. Those seven commands
are :
RENAME
DELETE
SITE
STATUS (are)
ALLOCATE
LIST
NAME-LI ST
The FTP commands used for user authentication (US Eh, PASS, and
ACCT) may or may not be offloaded depending on the security
policy arrangement between the front end and the host.
The organization of some host systems may be such that the
ALLOCATE, LIST and NAME-LIST commands are best performed through
the file access process-to-service protocol. Depending on the
particular offloading environment the other commands may be
handled in either the host or the front end.
This process-to-service protocol requires implementations in
the front end of the following additional protocols:
ARPANET Host-Host Protocol
ARPANET Initial Connection Protocol
ARPANET Server Telnet
ARPANET File Transfer Protocol (Server side)
File Access Process-t o-Ser vi ce Protocol
224
DRAFT
b/23/77
Server FTP PSP
Description of Service
Implementations of the File Access PSP and a residual Server FTP
which uses the Server FTP PSP will normally be required in the
host. (Installations that only allow the transfer of data by
network users will not require the use of this protocol.)
The server FTP process-to-service protocol uses HFP Messages
to carry information between the residual part of Server FTP in
the host (the "process") and the server FTP service module (the
"service") in the front end. A brief summary of the specific
Message types follows.
bEGIN Command
is used to initiate connections.
EEGIN Response
is used to confirm the establishment of a
connection, or to report the reason for failure.
END Command
is used to terminate a connection.
ENP Response
is used to confirm the termination of a connection.
TRANSMIT Command
is used to transfer FTP commands and replies to and
from the Telnet connection.
TRANSMIT Response
is used to acknowledge the transfer of FTP commands
and replies.
EXECUTE Command and Response
a) report the status of connections,
b) perform control functions, and
c) modify suggested allocations.
The details of the use of HFP Messages are given in the
following section.
225
DRAr i
6/23/77
Server FTP PSP
Description of Service
III. Message Use
HI A. BEQXN Command
III A 1. When sent
III A 1 a. by the host process
A BEGIN Command is sent by the host process to
indicate that it is able to accept an FTP user. The
host process sends as many BEGIN Commands as the number
of connections it will accept.
I?I A 1 b. By the service module
In some offloading schemes, a BEGIN Command is sent
by the service module to request FTP service in behalf
of a particular user.
Ill A 2. Action on receipt
III A 2 a. Bv the service module
When the service module receives a BEGIN Command,
it attempts to set up a connection as specified by the
parameters in the TEXT. The service module may refuse
the BEGIN Command by sending an appropriate BEGIN
Response.
Ill A 2 b. Bv the host process
When the host receives a BEGIN Command, it should
attempt to provide FTP service for those FTP commands
not handled in the front end. The host may refuse the
request for service by sending an appropriate BEGIN
Response. The only field the host process should expect
in the TEXT of the BEGIN Command is the Security field.
Security:
Es ta blishmen t :
Control-bits :
Socket/Channel
ICP/Direct
Relative/Absolute
Unattachable/Attachable
Host:
Foreign Socket:
Messages :
Bits:
Local Socket or Logical Channel:
Timeou t :
VAR1AELEC?)
COMPLEX(tt)
FIXED(M)
FIXED(32)
FIXED(32)
FIXED( 16)
FIXED(32)
FIXED(32)
FIXED( 16)
2?6
DRAFT
8/23/77
Server FTP PSP
BEGIN Command
III A IL TEXT field semantics
Xii a a a. security
This field may be used by the front-end or the host
to validate the access privileges of the server or user,
respectively. The default value of the field is empty.
Note: At this time, very little work has been done on
the organization of security for networks or these kinds
of systems. It is not clear where access control should
be placed. This field has been included in case some
systems require validation at this point.
Ill A 4 b, Establishment
conne
def au
favor
Comma
would
for a
(sock
time,
a de
field
for a
This
ction
It for
the
nd sen
caus
n ICP
et 3)
The
fault
Thu
Serve
set
to
the
Serv
t to
e th
conne
fro
def au
valu
s, mo
r FTP
of pa
be as
establ
er FTP
the fr
e f ron
ction
ny
It val
e may
st BEG
sessi
rameter
sociate
ishment
servic
ont end
t-end S
on the
host
ues of
be indi
IN Comm
on will
par
spe
erve
stan
for
the
cate
ands
hav
escribes
ith thi
ameters
This mea
cif ying
r FTP Se
dard FTP
an indef
fields a
d by the
s ent to
e an emp
the ki
s channel
are chos
ns that a
only de
rvice to
contact
inite per
re set at
absence
the fron
ty TEXT f
nd of
The
en to
BEGIN
faults
listen
socket
iod of
zero ;
of the
t end
ield.
Ill A ** b (1), Control-bits
The bits in this field govern the kind of
connection to be established and the interpretation
of the parameters.
Ill A 4 b (1) (»), Socket/Channel
If this bit is zero, the logical channel from
the relay process is to be established to a new
ARPANET connection. If this bit is one, the
logical channel from the host process is to be
attached to an already existing HFP channel (e.*.
a channel already established to the FTP service
module and therefore providing access to an
existing network connection.) The default value is
zero.
Ill A H b (1) (b). ICP/Direct
This bit is relevant only when a new network
connection is requested. (Socket/Channel bit is
zero.) When this bit is zero (default), the
connection is to be established via the Initial
Connection Protocol. When this bit is one, the
??7
DRAFT 8/23/77 Server FTP PSP
BEGIN Command
connection is to be established directly. The use
of this bit in specifying connection sockets is
detailed in table 1.
Ill A 4 b (1) (c). Relative/Absolute
This field affects the value of the socket
for the local connection. See III A 4 b (6) for
details .
Ill A 4 b (1) (d). Unattachable/Attachable
When this bit is one, the server FTP service
module is requested to make the logical channel
available for attachment by other service modules
within the front end (such as a data
transformation service). Otherwise this bit is
zero (default). See CAC Technical Memorandum No.
60, p. 3i for a discussion of this feature.
HI A 1 b (2). Host
This field specifies the network host or hosts
from which the FTP connection is to be expected. The
default value is zero, indicating that a connection
from any host will be accepted. The Host field is
parsed as:
Network: FIXED(6)
IMP: FIXEDM6)
Host-at-IMP: FIXED(8)
III A if b (3). Forejgp Socket
This field is used as follows to construct the
effective foreign socket (e.f.s.) for making the
connection .
Case 1. Foreign Socket field = zero. The e.f.s.
is three.
Case 2. Foreign Socket field i zero. The e.f.s.
is the contents of the Foreign Socket
field.
The default value of this field is zero. The
relationship between the e.f.s. and the foreign
sockets for the connection depends upon the value of
the ICP/Direct bit. See table 1 for details.
Ill A k b (4). Mess ages
This field and the Bits field allow the process
to indicate to the service module the flow rate
228
DRAFT
6/23/77
Server FTP P S P
BEGIN Command
desirable on the FTP data connection. The service
module may use this information in any way its
implementors deem desirable.
This field contains the number of host-host
messages the process suggests be allocated on the
connection. If the value of this field is zero
(default), the NCP chooses the number of messages on
its own.
Ill A 4 b (5). Pits
This field contains the number of bits the
process suggests be allocated for the FTP data
connection. If the value of this field is zero
(default), the NCP chooses the number of bits on its
own.
Ill A 4 b (6). Local Socket or Logical Channel
If the Socket/Channel bit is one, this field
contains the channel Group and Member values
specifying the HFP channel to which connection is to
be made. The format of this field is then:
<not used): FIXED(^)
Group: FIXED(12)
Member: FIXEDM6)
If the Socket/Channel bi
used as follows to constr
socket (e.l.s.) for making th
Case 1 .
Case 2.
Case 3-
Relative/Absolut
Socket field i
contents of th
HEADER will be
low-order 20 bit
field to form th
Relative/Absolut
field = zero. I
will choose a nu
bits are equal t
HEADER .
Relative/Absolut
the effective
the contents of
t
is zero ,
uct the e
e
connect i
e
bit r
zero. In
e
Group
concat en;
s
of the
e
e.l.s.
e
= zero,
n
this cas
mber whose
0
the Groui
e
= one .
local sock
the Local ;
this field is
ffective local
on.
zero , Loca 1
this case, the
field in the
a t ed with the
Local Socket
Local Socket
e, the service
high order 12
p field in the
In. this case
et is equal to
Socket field.
The relationship between the e.l.s. and the local
sockets for the connection depends upon the value of
the ICP/Direct bit. See table 1 for details.
Ill A 4 b (7) . Timeout
229
DRAFT
b/23/77
Server FTP PSP
BEGIN Command
This field contains the maximum length of time,
in seconds, that the service module is to attempt to
establish the connection (in the absence of an error
or exceptional condition). If the service module has
been unable to establish the connection within this
time period, it is to abandon the attempt. If this
field contains zero (default), the time period is to
be infinite.
230
DRAFT
8/23/77
Server FTP PSP
BEGIN Command
Table 1
Control Bits ! Foreign Sockets i Local Sockets
! for the connection j for the connection
!The e.f.s. will be used!
las the contact socket i
ICP .for the connection. ie.l.s. + 2 and e.l.s. + 3
'The control connection ,'
{sockets will be chosen i
i by the foreign host. i
Direct i e.f.s. and e.f.s. +1 | e.l.s. and e.l.s. + 1
231
DRAFT
6/23/77
Server FTP PSP
EEGIN Response
III B. begin Response
III P 1. When sept
III p 1 a, gy the service module
The BEGIN Response is sent by the service module to
indicate that a successful network connection has been
established, or that the BEGIN Command has been refused.
Ill B 1 fri By the host propels
The BEGIN Response is sent by the host to indicate
that it has established FTP service for the non-
offloaded FTP commands, or that the host is unable to
provide such service.
Ill B 2. Action on receipt
III B g a. By the host
When the BEGIN Response is received by the host,
the process should determine whether a successful
connection was made. If so, it may send or receive
data. If not, it may be appropriate to invoke an error
recovery procedure.
Ill p 2 b. By the service module
The only field that the service module should
expect to see in the TEXT of a BEGIN Response is the
Status field. The service module should take note of
the Status field value; otherwise no action is called
for.
Ill B 3, TEXT field syntax
Security :
Connection -info:
Status:
Host:
Foreign Socket:
Messages:
Bits:
Local Socket:
III B 4, TEXT field semantics
III B 1J a. Security
VARIABLES?)
COKPLEX(?)
FIXED(4)
FIXED(32)
FIXEDC32)
FIXED( 16)
FIXED(32)
FIXED(32)
This field may be used to allow the host to
validate the access privileges of the user and to pass
the information along to the front end. This field
could be particularly important for monitoring access by
23?
6/23/77 Server FTP PSP
BEGIN Response
users directly connected to the front end.
Ill E 4 b. Connection-info
This field describes the connection associated with
this channel.
Ill B.Jj.b (1). Status
This field indicates the success or failure of
the BEGIN Command. The value zero indicates success
while any non-zero value indicates failure. The
particular value of the non-zero field Rives the
reason for failure. The possible values of this
field and their meanings are:
0 Success
1 Illegal connection type
2 Invalid local socket
3 Unknown host
4 Improper access
5 Front end terminating1 srrvice
6 Connection attempt timeout
7 Network not available
b Foreign host dead
9 Connection refused
10 Local host overloaded
Others may be defined later.
Ill B 1 b (2). host
If the connection attempt was successful, this
field contains the ARPANET host address of the host
to which the connection was established. (See III A
4 b (2). )
III B 4 b (1). Foreign Socket
If the connection attempt was successful, this
field contains the socket number at the foreign host
to which the connection was established.
Ill B 4 _ b (4) . Messages and Bits
If the connection attempt was successful, these
fields contain the flow control parameters for the
connection at the time the BEGIN Response was
gene rated .
Ill B 4 b (5). Local Socket
233
DRAFT
i/23/77
Server FTP PSP
BEGIN Response
If the connection attempt was successful, this
field contains the local socket number for the
connection.
23A
DRAFT
8/23/77
Server FTP PSP
END Command
III Ct ENP Command
III C 1 . When sent
The END Command may be sent by either the process or
the service to terminate an FTP connection. If sent by the
process, it usually indicates that the host system has
requested that the connection be closed. The service module
may send an END Command because the foreign host has closed
the connection in response to a user request, or because
some failure condition has occurred that requires that the
connection be aborted.
Ill C 2t Action on receipt
HI Q 2 af By the process
When the process receives an END Command, it should
acknowledge it as promptly as possible by sending an END
Response.
Ill C 2 b. By the service module
When the service module receives an END Command, it
should close the FTP data connection (if open), send the
proper FTP replies indicating termination (120, 221, 421
or 530), and close the control connection. Once the
connections are closed, the service module should send
the END Response to the process.
HI c T- text mid syntax
Status: FIXED (3)
III C 4tTEXT field semantics
III C 4 a. Status
This field indicates the cause of the termination
of the TELNET connection. The values of the field and
their associated meanings are:
0 Normal close by foreign host
1 Network failure
2 Foreign host failure
3 User requested close
4 Improper access
5 Front end terminating service
Other causes for termination may be defined at a later
date. The default value of the field is zero.
235
DRAFT
6/23/77
Server FTP PSP
END Response
III pt ENP Response
III D 1. When sent
The END Response is sent by either the process or the
service module to acknowledge that an END Command has been
received and proper action taken.
Ill P Zr Action on receipt
When either the process or the service receives an END
Response, it should assume that all dialogue associated
with this logical channel has completed, and it should
ignore any other Commands on this channel except a BEGIN
Command.
Ill D 3. TEXT field syntax
The TEXT field in the END Response is not used in this
protocol .
236
DRAFT
8/23/77
Server FTP PSP
END Response
III E. TRANSMIT Command
III E 1 . When sent
III E 1 a. Bv the process
The TRANSMIT Command is sent by the process to
pass FTP replies to the service module for
transmission over the network to the foreign host.
(For details of offloading see CAC Document 230.)
Ill E 1 b. By the service module
The TRANSMIT Command is sent by the service
module to pass FTP commands that have arrived over
the network from the foreign host to the process.
(For details of offloading see CAC Document 230.)
Ill E 2. Action Qh regejpt
III E 2 a. Bv the process
When the process receives a TRANSMIT Command, it
will treat the contents of the TEXT as an FTP command
to be processed. (For details see CAC Document 230.)
Ill E 2 b. Bv the service module
When the service module receives a TRANSMIT
Command, it will treat the contents of the TEXT as an
FTP reply to be transmitted over the network. (For
details see CAC Document 230.)
HI E 3. TEXT field syptax
Control: FIXED(1)
Go-Ahead/More-Data
Data: VARIAELE(?)
Ill E M. TEXT field semantics
III E 4 a. Control
The single bit in this field indicates whether
or not the sender of the TRANSMIT Command has
completed sending data. It is used to facilitate
handling half-duplex terminals connected to the
process. The receiver of a TRANSMIT Command with
this bit set to 0 (default) should assume that the
sender has completed sending data and that the
receiver is now free to send any data that it has.
If the bit is set to 1 the sender has more data to
send and the receiver should not send data at this
237
DRAFT
6/23/77
Server FTP PSP
END Response
time.
Ill E 4 b. Data
The Data field contains the FTP commands and
replies to be transferred. For more details see CAC
Document 230, and section IV.
238
DRAFT
8/23/77
Server FTP PSP
TRANSMIT Response
III F. TRANSMIT Response
The TRANSMIT Response is used as described in the hFP
specification .
23Q
DRAFT
6/23/77
Server FTP PSP
SIGNAL Command
III G. SIGNAL Command
The SIGNAL Command is not used
service protocol. SIGNAL Commands
in
may
the process-to-
be generated by-
process or service to request that the CPM carry out the
appropriate action on the logical channel. (See HFP
specification.) Thus, the effect of the SIGNAL Command is
restricted to the logical channel (HFP) level.
240
DRAFT
8/23/77
Server FTP PSP
SIGNAL Response
III H. SIGNAL Response
The SIGNAL Response is not used by either process or
service.
241
8/23/77
Server FTP PSP
EXECUTE Command
III J. P-ECUTE Command
III J 1. When Sent
The process sends an EXECUTE Command to request the
service module to
a) report the status of a specified connection,
b) send a Telnet control function,
c) handle Telnet options and FTP replies, or
d) modify the allocation for the connection.
The service module does not send EXECUTE Commands for
this protocol.
Ill J 2. Action upon Receipt
When the service module receives an EXECUTE Command
it will decode and act on the request.
FIXED(2)
VARIAbLE( ?)
Ill J 3. TEXT field syntax
Code:
Parameters :
HI J 4. TEXT field semantics
III J 4 a. Code
This field contains an encoding of the type of
request. The codes are:
0 Report status
1 Send control function
2 Handle Telnet options and FTP replies
3 Modify suggested allocation
III J 4 b. Parameters
This field contains the parameters for
specifying the requests. The contents will vary
according to the type of request.
Ill J 4 b (1). Report status
No parameters are required.
Ill J 4 b (2). Send control function
III J 4 b (2) (a). Parameter field syntax
Control Function: FIXED (b)
242
DRAFT
6/23/77
Server FTP PSP
EXECUTE Command
HI v> ^ b (?) (b), Parameter field semantics
This field contains a parameter specifying
a Telnet control function that the User FTP
module should send on the control connection.
The parameter values and their meanings are:
242 SYNCH
243 Break
244 Interrupt process
245 Abort output
246 Are you there
HI J ** P (3)t Hapdle options and FTP replies
III J 4 b (3) (a). Parameter field syntax
Option control :
Reply text control:
FIXED(2)
FIXED( 1 )
III J 4 b (3) (b). Parameter field semantics
These
indicating
respond to Te
control conn
front end sho
replies to th
FTP replies a
sends the
installation-
in the
parameter val
fields con
1 ) how the
lnet option n
ection 2) wh
uld forward
e hos t . How
re handled be
relevant EXE
specific and
daptation d
ues and their
tain pa
front end
egotiat i on
ether or
the text
Telnet opt
fore the
CUTE Comm
must be s
escription
eanings
rame
sh
s on
not
of
ions
pro
ands
peci
are :
t er s
ould
the
the
FTP
and
cess
is
tied
The
Option control values:
1 Refuse all options
2 Refuse no options
3 Refuse options not handled by the
front end
Reply text control values:
0 Send FTP reply text
1 Don't send FTP reply text
III J 4 b (4). Modify suggested allocation
III vl 4 b (4) (q). Parameter field syntax
Messages :
Bits:
FIXED( 16)
FIXEDC32)
III J 4 b (4) (b). Parameter field semantics
243
DRAFT
fa/23/77
Server FTP PSF
EXECUTE Command
The semantics of this field are
identical to those described for the
allocation fields in the BEGIN Command (see
sections III A H b ( 4 ) - III A H b (5).)
244
DRAFT
b/23/77
Server FTP PSP
EXECUTE Response
III k, EXECUTE, Response
XIX K i. When Sent
The service module sends an EXECUTE Response
when
a) it has completed the operation requested by
an EXECUTE Command, or
b) it has received an EXECUTE Command whose
TEXT is in error.
The process does not send EXECUTE Responses for this
process-to-service protocol.
Ill k 2. Action on Receipt
When the process receives an EXECUTE Response,
it should examine the TEXT to see whether the
Response indicates an error. If no error is
indicated, it may consider that the action reauested
by a previous EXECUTE Command was successful. If an
error is indicated, appropriate error recovery action
should be initiated. This action is idiosyncratic to
the process.
XXI K 3- TEXT field syntax
FIXED(2)
PIXED(2)
COMPLEX*? )
FIXED (2)
FIXEDC2)
FIXED(32)
FIXEDC32)
FIXED( 16)
FIXED(32)
FIXED(32)
Result:
Ref-Code:
Connection-info:
Control connection-state:
Data connection-state:
Host:
Foreign Socket:
Messages:
Bits:
Local Socket:
II K *J . TEXT field semantics
III K H a. Result
This field contains an encoding of the result
of the request (made in a previous EXECUTE
Command) to which the EXECUTE Response is a reply.
The codes are:
0 Success
1 Illegal code in request
2 TEXT too short.
Ill K 4 b. Ref-code
2^5
8/23/77
Server FTP PSP
EXECUTE Response
This field contains the same value as the
Code field of the TEXT of the EXECUTE Command to
which the EXECUTE Response is a reply.
Ill K M c. Connection-info
This field is present only if the Ref-code
has a value of zero or three (status or modify
allocation). The semantics of this field are
identical with those of the Connection-info field
of the EEGIN Response (section III fc 4), with the
exception of the Status field, which has been
divided into two fields with the following
meanings .
Ill K 4 c (1). Contro; connectjonj^state
If the ref-code value is zero (status),
this field indicates the present state of the
FTP control connection. The possible values of
this field and their meanings are:
0 Closed
1 Open
2 Waiting for open to complete
3 Waiting for close to complete
III K 4 c (2). Data connection-state
If the ref-code value is zero (status),
this field indicates the present state of the
FTP Data connection. The possible values of
this field and their meanings are:
0 Closed
1 Open
2 Waiting for open to complete
3 Waiting for close to complete
246
DRAFT
6/23/77 Server FTP PSP
Details of Offloading Server FTP
IV. Details of Offloading Server FTP
The ARPANET File Transfer Protocol (FTP) consists of
two major sections: a command-and-response section and a
data transfer section. The file access process-to-service
protocol deals with offloading the data transfer section
and the FTP commands for data transfer (RETRIEVE, STORE,
and APPEND). The Server FTP process-to-service protocol
deals with offloading the command-and-response section. We
here describe some of the aspects of offloading the Server
FTP. These aspects include session establishment and
control, user authentication, restart, and interaction with
the file access module.
Sess ion esta bl ishmen t and con t rol . There are several
possible ways in which service could be initiated and
controlled. The scheme described in this protocol appears
to be the simplest and most flexible. In this scheme,
BEGIN Commands only co from the host to the front end.
When the front end service module receives a BEGIN Command,
it sets up a connection as requested. In most cases, the
service module will not be requested to actively initiate a
connection but only to set up a lister on socket 3 and wait
for a request for service from a remote host. After a
connection has been established, the service module sends a
BEGIN Response to the host. The host process must generate
a distinct BEGIN Command for each connection it is willing
to accept. Thus, the host is able to limit the number of
247
DRAFT
8/23/77 Server FTP PSP
Details of Offloading Server FTP
FTP users by withholding BEGIN Commands. The front end may
also limit demand on its resources by refusing BEGIN
Commands from the host.
If user authentication is done in the front end, then
an alternative method may be used. Since most FTP sessions
consist of logging in, moving one or more files, and then
logging out, virtually no traffic is sent on the Server FTP
channel. Everything is handled by the server FTP service
module (SFSM) and the file access modules, unless the user
does a DELETE or RENAME. Therefore, it makes sense to
leave control of the service in the front end. The SFSM in
the front end would listen on socket 3 as usual. When a
user connected to the FTP contact socket, a connection
would be established. The user would be logged in, and
data transfer parameters set. When the user sent a data
transfer command, the UFAM would be asked to set up a
session. At this point the host could refuse access if it
were too heavily loaded. Normally the transfer and the
session would be done without requiring the use of a Server
FTP PSP channel.
User authentication and security. The ARPANET FTP
provides three commands for authenticating users: USER,
PASS, and ACCT. Depending on the security arrangement
between the host and the front end, it may be possible to
offload these commands. This, however, implies that the
host trusts the front end's security as much as it trusts
248
6/23/77 Server F1F PSP
Details of Offloading Server FTP
it own. Some systems may wish to restrict network access
to data transfers. For example, a data base system might
allow remote network users to query and even to update data
bases and to transfer files in and out, but the system
might wish to restrict delete and rename capabilities to
local users only. In this case, the Server FTP PSP would
not be used at all, and the Server FTP module in the front
end would use the File Access PSP only.
Restart . An important aspect of FTP that can be
offloaded is the facility to restart a transfer that has
been aborted because of a host or network failure. There
are two cases to consider: data poine out to the net and
data coming in from the net. Let us first consider data
moving out. If the front end can exert enough addressing
control through the FA-PSP, it is possible to allow the FAS
in the front end to insert the restart markers, thus
offloading this function from the host. The only
requirement is that the FAS in the front end be able to
address the same point in the file when given the restart
marker and commence the transfer at that point. If this is
not possible then these functions must be in the host.
For data coming into the host, it is necessary for the
Server FTP to be able to report to the User FTP when the
data associated with a particular marker has been entered
into the file, and to associate with the user-specified
markers a locally generated marker that can be used to
DRAFT 8/23/77 Server FTP PSP
Details of Offloading Server FTP
restart the transfer at this point.
Interaction with the file access module . Offloading
Server FTP will in most cases require the Using File Access
Module (UFAM) to be in the front end. The Server FTP
Service Module (SFSM) acts as an intelligent message
switch. The SFSM does not actually perform any of the FTP
commands, except possible those having to do with
connection control (e.g., BYE or REINITIALIZE) or user
authentication. When the SFSM receives a command that is
not offloaded, it will pass the command on to the residual
Server FTP in the host. (The command may be first
translated into some other form. If the command is one
that is offloaded (e.g., one of the data transfer parameter
commands), the SFSM will use its knowledge of the
facilities supported in the front end and send a suitable
reply to the foreign host. This information is then
communicated to the UFAM to specify the translation
requirements for the transfer. The SFSM may hold parameter
information until a data transfer command is received and
then relay all information specifying the transfer
(including the data connection sockets) or the parameters
may be relayed as they are determined depending on the
implementations and the IPC facilities in the front end.
If the translation is done in the front end, the UFAM
in the front end requires that only the file parameters be
specified in the BEGIN Command. If, however, data
250
DRAFT
b/23/77 Server FTP PSF
Details of Offloading Server FTP
translation is done in the host, the data transfer
parameters roust also be present. (See [2].)
Content of TRANSMIT Commands. In this protocol, the
TRANSMIT Command is used to send FTP commands and replies
between the service module and the host. Some
installations may wish to send some interactive form or
encoding peculiar to their host's file system and let the
service module in the front end translate it into the
proper FTP commands. For most installations, the best
method of encoding this information is to just send the FTP
commands themselves. Since many of the parameters are
character strings, little is saved by additional encodings.
The only major exceptions would be the data transfer
parameter commands such as TYPE, MODE, etc., which are not
sent to the host in most Server FTP offloading schemes.
Similar arguments hold for the replies. because of the
semantics attached to the individual decimal digits, some
encoding is possible, but it is of limited utility. Some
installations may wish to use the control function
described in section III J M b (3) to suppress the text
associated with replies. Server FTP offloadings that also
support file systems in the front end may find it useful to
pass only reply codes from the host and generate a
consistent set of reply text from the front end. For a
suggested encoding for FTP commands and replies, see
Section V of [ 1] .
251
DRAFT 6/23/77 Server FTP PSP
Scenarios
V. scenarios
User authentication in the host . Consider the
following scenario for an offloaded Server FTP. We will
assume that user authentication and the FTP commands USER,
PASS, and ACCT are done in the host. We will also assume
that the seven FTP commands listed in Section II are done
in the host. All other FTP commands are to be handled by
the front end. Further, the data transfer process is also
in the front end and the file access module is used to
transfer the file from the host. We will not describe the
behavior of the file access module in detail. For a
scenario describing its use see the specification of the
File Access Process-t o-Servi ce Protocol [?.]. Also we will
not be concerned with the detailed functioning; of the
channel protocol.
First, the residual Server FTP module (SFh) in the
host will send a BEGIN Command to the front end offering
FTP Service:
<BEGINXC>
Since no parameters are present, the defaults are assumed.
The Server FTP Service Module (SFSM) will listen for an ICP
on socket 3 (the FTP contact socket) from any host for an
indefinite period of time.
Some time later, a remote user connects to socket 3.
252
8/23/77
Server FTP PSP
Scenarios
The ICP protocol is performed and the Telnet control
connection is opened. The SFSM will then send the FTP
herald message (a 300 reply) to the remote host and a EEGIN
Response to the local host.
<EEGINXRXsuccessXKost=12XForeign Socket = 57b3^>
<Messages = 1><bitsr2000XLocal Socket=247fc>
In order to support another user, the host will now
send another
<BEGINXC> .
When the FTP USER command is received from the remote
user, the SFSM sends it to the SFM:
<TRANSMITXC>USER day
(Since TRANSMIT Responses do not require any action by the
services or the process they are not shown here.)
The SFM replies with
<TRANSMITXC>331 Please send pass command.
The SFSK sends the TEXT of this command over the net to the
user. The user responds by sending the FTP PASS command,
which is then relayed to the SFM:
<TRANSMITXOPASS John
The SFM replies with
253
DRAFT
6/23/77
Server FTP PSP
Scenarios
<TRANSMITXC>230 looped in. please proceed.
The user then sends an FTP RETR command requesting that a
file "junk. note" be moved from the local host to the
foreign (i.e., the user's) host. The SFSM will then
1) do a listen on the default data socket, and
2) pass the command, the user identification parameters,
and information on the local socket or port to the
Using File Access Module (UFAM) in the front end.
(Since no data transfer parameter commands were received,
the defaults are assumed.
The UFAM will then establish a session with the
Serving FAM (SFAM) in the host and attempt to access the
file. When a successful EEGIN Response is returned, the
UFAM will open the data connection and notify the SFSM that
the transfer can begin. The SFSM will now send the FTP 150
reply to the remote host indicating that the transfer is
ready to start. The UFAM will then transfer the data to
the network.. When the transfer is complete, the UFAM will
notify the SFSM which will send the FTP 250 reply to the
remote host indicating the end of transfer.
Now the user decides to delete the file he has just
transferred, so he sends an FTP DELE command to the SFSM.
the SFSM recognizes that this is not a command it does and
passes it on to the host:
<TRANSMITXODELE junk. note
254
DRAFT
6/23/77
Server FTP PSP
Scenarios
The host deletes the file and returns:
<TRANSMITXC>250 File junk. note deleted.
Finally the user is finished, and sends the FTP b\E
command. The SFSM will send an FTP 221 reply indicating
that it is closing the Telnet connection, close the data
connection, notify the UFAM to terminate its session, and
terminate its own session with the host by sending an END
Command :
<ENDXC><3> (indicating a user-requested close)
The host will respond with
<ENDXR>
and the interaction is complete.
User authentication in the front end . Let us consider
how this protocol would be used if user authentication is
done in the front end. Let us assume that the only FTP
commands handled by the host are the seven listed in
Section II. We will also assume that the data transfer
commands are handled by the Using File Access Module (UFAM)
in the front end.
The Server FTP Service Module (SFSM) is offering FTP
service by listening on socket 3 (the FTP contact socket).
A user at some remote host does an ICP to the contact
socket and a control connection is established. The user
255
DRAFT
8/23/77
Server FTP PSP
Scena ri os
sends the FTP USER and PASS commands and is logged in by
the SFSM for file transfer service. The user then sends a
RETR command to transfer the file "junk. note" to his host.
Ihe necessary information, including pathname, user
identification, and network data sockets, are passed to the
UFAM. The UFAM establishes a session and transfers the
file. After the transfer is complete, the user wishes to
delete the same file and sends the FTP command:
DELE junk. note
This requires establishing a Server FTP PSP channel to the
host, since one has not been required as yet. Ihe SFSM
sends a BEGIN Command to the front end:
<BEGINXCXsecurity = day,john>
The Server FTP Module (SFM) in the host acknowledges with:
<BEGINXR>
The SFSM then, sends over the command:
<TRANSMITXC>DELE junk. note
(Since TRANSMIT Responses do not require any action by
either the process or the service, they are not shown in
this example.) The file is deleted and the reply sent back
to the SFSM:
<TRANSMITXC>250 File junk. note deleted.
256
DRAFT
6/23/77
Server FTP PSP
Scenarios
The TEXT of this TRANSMIT Command is then sent over the
control connection to the user. The user decides he is
finished and sends an FTP BYE Command to the front end.
The SFSM immediately sends the proper FTP reply to the
user, notifies the UFAM to terminate its session and sends
an END Command to the SFM in the host:
<ENDXC><0> (indicating normal completion)
The SFM replies immediately with:
<ENDXR>.
Note that if the user had not asked to delete the file this
PSP would not have been used at all.
257
DRAFT
b/23/77
Server FTP PSP
References
VI. References
1. Day, J. "User FTP Process-t o-Servi ce Protocol," CAC
Technical Memorandum No. 101, Center for Advanced
Computation, University of Illinois at Urbana -Champai en ,
1977.
2. Day, J. "File Access Process-t o-Servi ce Protocol," CAC
Technical Memorandum No. 102, Center for Advanced
Computation, University of Illinois at Urbana -Champ ai em ,
1977.
3. Day, J. "Offloading ARPANET Protocols to a Front End,"
CAC Document No. 230, Center for Advanced Computation,
University of Illinois at Urbana -Champ ai gn , 1977.
Neigus , N .
5M2, 1973.
"The File Transfer Protocol,
ARPANET RFC
Neigus, N.; Posrran, K.; and Postel, J. "A New Schema
for FTP Reply Codes," ARPANET RFC 640, 1974.
Postel, J. "Telnet Protocol Specification," NIC #16639,
1973-
258
UNCLASSIFIED
SECURITY CLASSIFICATION OF THIS PAGE (When Dmtm Entered)
REPORT DOCUMENTATION PAGE
1. REPORT NUMBER
CAC Document Number 230
CCTC-UkTl Tin piitiiptH- TJimiKov 7S11
2. GOVT ACCESSION NO.
3. RECIPIENT'S CATALOG NUMBER
.. TITLE (mnd Subtitle)
Network Research in Front Ending and Intelligent
Terminals - Offloading ARPANET Protocols to a
Front End
5. TYPE OF REPORT & PERIOD COVERED
Research
6. PERFORMING ORG. REPORT NUMBER
CAC #230
7. AUTHORS
John D. Day
S. CONTRACT OR GRANT NUMBERf.)
DCA100-76-C-0088
I. PERFORMING ORGANIZATION NAME AND ADDRESS
Center for Advanced Computation
University of Illinois at Urbana-Champaign
Urbana, Illinois 61801
lenter
WWMCCS ADP Directorate, 11440 Isaac Newton Sq. , N.
Reston, Virginia 22090
12. REPORT DATE
September 30, 1977
NUMBER OF PAGES
262
14. MONITORING AGENCY NAME ft AODRESSfi/ different from Controlling Office)
15. SECURITY CLASS, (of thla report)
UNCLASSIFIED
16. DISTRIBUTION STATEMENT (of thla Repot
Copies may be requested from the address given in (11) above.
17. DISTRIBUTION STATEMENT (of the mbst
mtcred in Block 20, If different from Report)
No restriction on distribution.
18. SUPPLEMENTARY NOTES
9. KEY WORDS (Continue on r
Network front end
Network protocols
elde If neceaamry mnd Identity by block number)
20. ABSTRACT (Cot
tmry mnd identify by block n
The CAC is engaged in an investigation of the benefits to be gained by
employing a network front end. This document presents a discussion of
alternative strategies for offloading ARPANET protocol implementations to a
front end. A set of six appendices specify the host-to-front-end, process-to
service protocols required to implement the various strategies.
dd ,;■
EDITION OF 1 NOV 65 IS OBSOLETE
UNCLASSIFIED
S E CURITY CLASSIFICATION OF THIS PAGE (When Dmtm Ent ered)
M
Live Music Archive
Librivox Free Audio
Metropolitan Museum
Cleveland Museum of Art
Internet Arcade
Console Living Room
Books to Borrow
Open Library
TV News
Understanding 9/11