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