transmitted in either direction will have padding appended to
complete the least multiple of this width.
In the typical implementation, this parameter will be 0 and any
padding required will be appended/discarded by the line protocol
underlying FEP.
Pad Field Length
This gives the size in bits of the PAD field in the MESSAGE command.
This enable a Host to have the TEXT field start on a convenient
boundary.
Its value can be anywhere in the range 0 to 64.
Maximum of MESSAGE
This gives the maximum length of a MESSAGE command string.
Because buffer allocation in the FE is based on this parameter,
its value should be chosen with care.
Maximum number of Indexes
This gives the maximum number of indexes which may be set-up at any one
time.
Maximum Number of Paths
This gives the maximum number of paths within one index which may be
open at any one time.
Translation Types
This gives the set of required values and meanings of the TRANS-TYPE
field of the BEGIN/LISTEN commands. The TRANS-TYPE field is divided
into two 8-bit subfields; the first giving the format of data on the
***WORKING DOCUMENT***
27
RFC705
Front-End Protocol
***WORKING DOCUMENT***
network side; the second giving the format of data on the Host side.
The FE is required to translate between these formats all data
contained in the TEXT field of MESSAGE commands.
This parameter specifies the required formats and their values in the
8-bit subfields. The value 0 is reserved to mean "bit-string" and
when it appears as either (or both) of the subfields it implies no
translation is to be done.
Broadcast Option
This specifies whether the Host wants to be able to use the Broadcast
feature (see Section 3j).
Operator-to-Operator Communication Option
This specifies whether the Host wants the ability to send messages
to the FE operator or to have the Host's operator receive messages
from the FE.
Other options may be included in the protocol at some later date and these will
be available through installation parameters similar to the Broadcast option.
Note that all of these parameters affect the size and complexity of the FE
code. Thus it is important that their values be chosen carefully so as to
maximize FE efficiency while minimizing Host implementation effort.
For descriptions of individual Host implementations and a list of the options
available so far, see Appendix D.
FE Implementation 8
FEP is device independent. For the present however, an initial implementation
will be accomplished using the DEC PDP/11 computer as the FE device and the
front-end software is to be based upon an extended version of the original ELF
system developed at SCRL.
For more detailed information, see Appendix C.
by : 9
G. W. Bailey (BAILEY@OFFICE-1)
K. McCloghrie (MCCLOGHRIE@OFFICE-1)
***WORKING DOCUMENT***
28
RFC705
Front-End Protocol
***WORKING DOCUMENT***
APPENDIX A 10
References
[1] ICP is used in this document in a less strict manner than specified
in NIC 7101, in that it is not necessarily two simplex connections
that are set up as the result of the exchange of the socket number
on the initial connection.
[2] An example of connections needing to be affiliated, is in the
implementation of FTP, where the control connection and the data
connection have a defined relationship in their socket assignments.
[3] Note that a range of socket numbers is reserved for use by an index
when it is set-up (cf. AEN).
However, socket numbers for the paths of an index are not necessarily
contiguous. For instance, when the next path opened after a SEND
path is another SEND path, or when a path other than the first of an
index is opened with ICP specified. Nevertheless, if a protocol
requires contiguous sockets, then the opening of the paths in a logical
manner will provide the contiguity.
[4] One possible translation will be from a Network Virtual Terminal on
the network side to a local terminal type on the Host side.
[5] The FE will directly equate the INTERRUPT command with the Host-Host
protocol INR/INS commands.
[6] Note that the READY indication in a REPLY is, in the general case,
not directly related to a network RFNM; unless it is heavily loaded,
the FE will be buffering possibly more than one message (in either
direction) until flow control mechanism allow the messages to be sent
on.
However, it is possible that a particular Host might wish to have
knowledge of receipt of a previous message before transmitting the
next. In this case, the FEP implementation could be set up to only
indicate READY after receiving the RFNM and possibly only send RFNMs
after receiving a REPLY containing an ACK.
***WORKING DOCUMENT***
29
RFC705
Front-End Protocol
***WORKING DOCUMENT***
APPENDIX B 11
State Diagrams
In the state diagrams below the following notation is used:
REPLY(A) - REPLY with ACK=1, READY/NOT-READY irrelevant
REPLY(N) - REPLY with NAK=1, READY/NOT-READY irrelevant
REPLY(R) - REPLY with ACK=0, NAK=0, READY=1
REPLY(A+R) - REPLY with ACK=1, READY=1
REPLY(N+R) - REPLY with NAK=1, READY=1
REPLY(A+NR) - REPLY with ACK=1, NOT-READY=1
REPLY(N+NR) - REPLY with NAK=1, NOT-READY=1
State Diagram for INDEX
/ ------\ /-------\ /-----\
! !BEGIN(new index) ! ! ! !
! !->--------------->-!Index ! ! !
!Index !LISTEN(new index) !Open ! ! !
!Closed ! !Pending! !Index!
! ! REPLY(N)! !REPLY(A) !Open !
! !-<---------------<-! !->------->-! !
! ! \-------/ ! !
! ! ! !
! ! /-------\ END(Path=0)! !
! ! ! !-<-------------<-! !
! ! REPLY(A)!Index ! ! !
! !-<---------<-!Close !REPLY(N) ! !
! ! !Pending!->------------->-! !
\-------/ \-------/ \-----/
***WORKING DOCUMENT***
30
RFC705
Front-End Protocol
***WORKING DOCUMENT***
APPENDIX B (continued)
State Diagram for Whole Path
/------\BEGIN /----------\
! !->-------->-! !
! !LISTEN !Connection!
!Path ! !Pending !REPLY(A) /-------\
!Closed! REPLY(N)! !->------------>-! !
! !-<--------<-! ! ! !
! ! \----------/ !Path !
! ! !Conn- !
! ! /-----\ RESPONSE(CODE>0)! ecting!
! ! ! !-<-----------------<-! !
! ! !Path ! ! !
! ! REPLY(A)!Abort! END(PATH>0)! !
! !-<--------<-!Pend-!-<-----------------<-! !
! ! ! ing ! ! !
! ! ! !REPLY(N) ! !
\------/ ! !->----------------->-! !
\-----/ ! !
! !
/-------\ ! !
! ! RESPONSE(CODE=0)! !
/----\ !Path !-<--------------<-! !
! ! !Open ! ! !
!Path! !Pending!REPLY(N) ! !
!Open! REPLY(A)! !->-------------->-! !
! !-<--------<-! ! \-------/
\----/ \-------/
***WORKING DOCUMENT***
31
RFC705
Front-End protocol
***WORKING DOCUMENT***
APPENDIX B (continued)
State Diagram for Each Direction of Path
/----\MESSAGE /-------\ /-------\
! !->---------------->-! !REPLY(A+NR) ! !
!Path!INTERRUPT !Command!->--------->-!Message!
!Open! !Blocked!REPLY(N+NR) !Blocked!
! ! ! ! ! !
! ! REPLY(A+R)! ! INTERRUPT! !
! !-<----------------<-! !-<---------<-! !
! ! REPLY(N+R)\-------/ ! !
! ! REPLY(R)! !
! !-<----------------------<---------------<-! !
! ! ! !
! !END(PATH>0) /-------\ END(PATH>0)! !
! !->---------------->-! !-<---------<-! !
! ! ! ! ! !
! ! REPLY(N+R)!Path !REPLY(N) ! !
! !-<----------------<-!Close !->--------->-! !
\----/ !Pending! \-------/
! !
/------\ REPLY(A)! !
!Path !-<--------------<-! !
!Closed! ! !
! ! \-------/
\------/
***WORKING DOCUMENT***
32
RFC705
Front-End Protocol
***WORKING DOCUMENT***
APPENDIX C
Front-End Implementation
Introduction
A Network Access System (NAS), developed for a DEC PDP/11 computer, supports
the current Imp-Host, Host-Host and ICP protocols. The implementation of
these protocols facilitate process-process communications across the network
and multi-user TELNET access to foreign hosts. This NAS provides the FE
environment in which FEP is implemented.
The NAS system is comprised of a Kernel or executive section and a Network
Control Program (NCP) plus a collection of modules to support device
interfaces, handle terminals, and implement applications, as appropriate. The
software is modular and extensible.
The KERNEL
The Kernel of the system consists of a set of functional modules which perform
the task of resource management in a multiprocessing environment. This allows
processes to be created, vie for processor service according to priority,
intercommunicate, and be terminated. System primitives exist for various
tasks such as process creation and synchronization, storage allocation, and
sharing of the interval timer.
The term process used here describes an autonomous sequence of states brought
about by the PDP-11 processor; a process' state is characterized by the set of
processor registers, a stock, and process-owned storage areas. Process share
storage areas which are accessed only (eq. pure code). Processes also share
storage areas which may be updated (eq. control tables). In this case an
allocation mechanism is utilized to prevent simultaneous ownership of an
updatable storage area. The storage area is thus viewed as a sequentially
sharable resource which is allocated by the process, modified, and then
released.
Processes are given control of the processor by a single procedure called the
Dispatcher. Processes are said to be in a ready state or in a waiting state.
When a process blocks itself, control is given to the highest priority ready
process.
***WORKING DOCUMENT***
33
RFC705
Front-End Protocol
***WORKING DOCUMENT***
Each process has an associated input message queue. This queue is the vehicle
for interprocess communication. A process is blocked (put into a wait state)
when its input message queue becomes empty (voluntary wait), or when an
interrupt occurs (involuntary wait) because a higher priority process is to
receive control of the processor. A process may voluntarily block itself
waiting for any signal, or it may block itself for a specific event to be
posted to its input message queue.
The Network Control Program
The NCP provides "third level" protocol functions to local processes. It
contains a process which decodes and passes messages which have been received
from the IMP and placed on the IMP-Host queue. This process interacts with
other processes which call the NCP to establish connections or to transmit
data. Thus the NCP is essentially divided into two parts:
1) a process which handles incoming messages from the network,
interprets IMP-Host and Host-Host control messages, and forwards
regular messages on established connections; and
2) a set of primitives which allow local processes to establish
connections to other processes across the network, and to perform
requests for data to be transferred on these connections.
There are two primary data structures used by the NCP to monitor the status
of network connections. The first is called the Host Table, and describes
that which is peculiar to each given host; the second is referred to as a
Connection Table and contains all information on the state of a local NCP
socket (connection). Connection Tables may be created either through
external requests (e.q., an RFCis received from a remote host) or through
internal requests (e.g., a local process performs a LISTEN).
Flow control is that portion of the NCP which governs the flow of data on
connections. There are two procedures which perform this task; one which
handles receive connections and one which handles send connections. These
procedures receive control when an event has occurred which may now make it
possible to transfer data on a connection.
Both send and receive flow control procedures have the responsibility of moving
data between local process buffers and messages being received or transmitted
over the network. In addition, they handle the formatting and unpacking of
***WORKING DOCUMENT***
34
RFC705
Front-End Protocol
***WORKING DOCUMENT***
messages received. Local processes are unaware that data is being transmitted
as discrete messages.
The NCP watchdog process monitors the state of network connections, checking
for error conditions and performing garbage collection tasks. It receives
control at periodic intervals and scans the list of known hosts, looking for
existing connections. For each host to which an input or output connection
exists, the Watchdog causes a Host-Host NOP message to be sent. Thus if a
remote Host crashes while data is being awaited, local processes are informed
of the error condition. The NCP takes notice of the remote crash when it
receives a IMP--Host type 7 control message (Destination Host Dead). It then
automatically closes all connections to that Host, and notifies using processes
of that fact.
A second function of the NCP Watchdog is to check for connections hung because
of an outstanding RFNM. If a RFNM is not received for a specified interval,
the message is discarded, and the associated connection closed.
The FEP Handler
The Front-End Protocol is implemented as a collection of related, but
specialized processes which manage network connections on the one side, and
manage FEP paths and indexes on the other. Some FEP processes are NCP users.
They cause network connections to be made, rule on incoming RFCs, and both
accept and generate network data. Other FEP processes support the Host.
These processes parse incoming commands, create indexes and paths, control
the generation of replies and generally manage the paths. Certain FEP
processes control specialized tasks such as translation of data, servicing of
LISTEN commands and generation of RESPONSE commands.
Two data structures provide control information for FEP activities. An Index
Table exists for each active index. Each Index Table associates one or more
Path Table entries. Information in the Path Table reflects the state of the
path, the translation type specified for data on this path, and necessary
information to associate the path to any appropriate NCP Connection Tables.
The Path Table is the common interface for all of the FEP modules. Most FEP
processes are activated to service some event which is usually associated to
a path. The action of the process will likely be dictated by the state of the
path as indicated by the Path Table entry, and may result in altering the state
of the path or the activation of one or more other FEP processes.
***WORKING DOCUMENT***
35
RFC705
Front-End Protocol
***WORKING DOCUMENT***
Two message queues provide Host input and output to the FEP modules. A line
protocol mechanism services these queues. Commands from the Host are placed
on the FEP Input queue by the line protocol process and the FEP Host Input
process is signaled. When an FEP Host Output module places a Command for the
Host on the host Output queue it signals the line protocol process.
The FEP implementation is basically Host independent down to the level of the
Host Input and Host Output queues.
The Line Protocol Mechanism
The device interface and the line protocol between the FE and the Host are
installation dependent. Because of this dependency, only a general discussion
of the Line Protocol Mechanism is possible in this context. Detailed
descriptions of the specific line protocols are included in the section for
each Host.
The communications discipline and physical device characteristics may vary
considerably from host to host. All FEP line protocols, however, will show
certain common characteristics. The interface between the FEP handler and the
Line Protocol Mechanism will always be Host Input and Host Output queues. All
line protocol mechanisms will be expected to guarantee the integrity of the
data. This implies some form of flow control, error detection/correction and
retransmission capability, as well as normal transmit/receive responsibilities.
The Line Protocol Mechanism will be expected to report failure after
unsuccessfully attempting to perform an I/O operation. The number of retries
etc. before reporting failure is an installation parameter. The FEP Handler
works only in terms of FEP commands. The line protocol may provide for block
transfers where each physical block is comprised of one or more FEP commands.
If such is the case, it is encumbent upon the Line Protocol Mechanism to
deblock the incoming Host commands before placing them in the Host Input queue.
The Line Protocol Mechanism will, in the general case, not manage any buffers.
After successfully transmitting a command to the Host it is responsible for
reporting the I/O complete, but the buffer space is freed or reused only by
the FEP process which "owns" that space. The FEP Handler might use buffer
assignment to control the rate of incoming traffic. When the FEP Host Input
queue is ready to accept an additional command, it would acquire a buffer and
signal the Line Protocol Mechanism, passing it a pointer to a buffer. This
***WORKING DOCUMENT***
36
RFC705
Front-End Protocol
***WORKING DOCUMENT***
is effectively a "read" request. When the line protocol handler has filled
the buffer, it adds it to the Host Input queue and signals I/O complete to
the appropriate FEP process.
If the nature of the physical connection is such that the FE must accept
unsolicited input, it may be necessary for the Line Protocol Mechanism to
have its own buffer pool, in addition. If this is the case, it must be
entirely managed by the line handler and transparent to the FEP Handler.
Data Translations
The TRANS-TYPE provisions in FeP may be employed for at least two general
services. First, it can be used for normal character set substitutions. This
is where, in the general case, there is a one-to-one relationship between the
two character sets.
The second service addresses the problem of data transformation. In this case,
there need not be a one-to-one relationship between incoming data and outgoing
data.
The translation mechanism uses a token (e.g., a character) from the incoming
data stream to index into a translation table. The result may be one of the
following:
a) do nothing, drop the character
b) output the character unchanged
c) substitute input character by output character
d) substitute input character by output string
e) activate a procedure indicated by the table
f) change the translation
g) test the translation mode and do any of the above depending
on the result.
For each translation/transformation required by the Host a translation table
must be defined. For simplicity and clarity the TRANS-TYPE field in the FEP
commands allows the user to specify Host side and Network side as independent
entities. In actual execution the Host/Network pair addresses a translation
table which must have been previously defined. Note that for a duplex path
two translation tables are necessary (A->B is not the same as A<-B).
A collection of "standard" character sets will be addressed initially (EBCDIC,
ASC117, ASCII8, BCD, etc.) and at least NVT. As new requirements are defined
these will be added to a library which will then be available to subsequent
users.
***WORKING DOCUMENT***
37
RFC705
Front-End Protocol
***WORKING DOCUMENT***
APPENDIX D
Host Implementations
To be written at a later date.
***WORKING DOCUMENT***
38