UNIVERSITY OF;
ILLINOIS LIBRARY
/" UR3ANA-CHAMPAIGN
ENGINEERING
■mwii
Minimum Fee tor
NOTICE: Return or renew all Libra
each Lost Book is $50.00.
The oerspn charging this material is responsible for
its retWtt) tire 'jibran from ybi#*if>as withdrawn
on °^|miiff |#i*tiffflm below'
Theft, mutilationTfnl un JerkrW Joftcl JWAsons for discipli-
nary action and may result in dismissal from the University.
To renew call Telephone Center, 333-8400
UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN
L161— O-1096
Digitized by the Internet Archive
in 2012 with funding from
University of Illinois Urbana-Champaign
http://archive.org/details/networkingresearOuniv
^ ENGINEERING LIBRARY
UNIV^ITY OF ILLINOIS
URBANA. ILLINOIS
.enter for aq vance<
UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN
URBANA IILIf:
CAC Document Number 240
CCTC-WAD Document Number 7518
Networking Research in Front Ending
and Intelligent Terminals
ENFE Final Report
September 30, 1977
The person charging this material is re-
sponsible for its return to the library from
which it was withdrawn on or before the
Latest Date stamped below.
Theft, mutilation, and underlining of books
are reasons for disciplinary action and may
result in dismissal from the University
™|V«Smr_OF ,uINO,s MBRARY AT URBANA-CHAMPA.GN
JIM 6 Itfji
FEB 2L 1. jjw?
FEB 2 3
L161— O-1006
CAC Document Number 240
CCTC-WAD Document Number 7518
Networking Research in Front Ending
and Intelligent Terminals
ENFE FINAD REPORT
Prepared for the
Command and Control Technical Center
WWMCCS ADP Directorate
Defense Communications Agency
Washington, D.C. 20305
under contract
DCA100-76-C-0088
Center for Advanced Computation
University of Illinois at Urbana-Champaign
Urbana, Illinois 61801
September 30, 1977
approved for Release:
^fc^.A.
Peter A. Alsberg, Principal Investigator
TABLE OF CONTENTS
Page
SUMMARY 2
Background
ENFE Research Program 2
ENFE SOFTWARE ARCHITECTURE 7
General Description 7
Host-to-Front-End Communications 7
Channel Protocol 7
Channel Protocol module 8
Process-to-Service Communications 8
Process-to-Service Protocols 9
Service Structure 9
Host-Host Service module 10
Program Access Service module 10
Server Virtual Terminal Service module 10
PROTOCOL SPECIFICATIONS 11
Host-to-Front-End Protocol 11
ARPANET Host-Host Process-to-Service Protocol 12
Program Access Process-to-Service Protocol 12
Server Virtual Terminal Process-to-Service Protocol.. 13
Other Process-to-Service Protocols 14
Telnet Data Entry Terminal Option 14
EXPERIMENTATION 16
ENFE Experiment Plan 16
Goals 16
Tools 16
Specific Tests 17
UNIX/ENFE Experimental Performance Report 17
Experimentation Software 17
Experiment Results 18
IMPLICATIONS OF EXPERIMENT RESULTS 21
Multi-Host Study 21
OFFLOADING STRATEGIES 41
Offloading the Telnet Protocol 41
Offloading the File Transfer Protocol 41
Offloading Other ARPANET Protocols 42
ALTERNATIVE ARCHITECTURES 43
Alternative Architecture Research Plan..."/" ai
State of the Art * * ' * ,t
Research Directions ........... 43
Research Plan ,i
43
SUMMARY
background
Under contract DCA100-76-C-0088 , the Center tor Advanced
imputation of the University ot Illinois at Urbana-Champaign has
investigated the capabilities ot network front ends. As a part
that contract, an experimental network front end (ENFE) has
)een developed to interface a World-Wide Military Command and
:ontrol System (WWMCCS) H6000 to the ARPA network and to conduct
experiments with the proposed ARPANET Host-to-Front-End Protocol.
i total of 194.28 man-months were expended over a period of 12
months (1 October 1976 to 30 September 1977).
An experimental network front end (ENFE) was a primary
:ontract deliverable. Delay in GFE hardware delivery signifi-
:antly decreased the work that could have been accomplished,
digital Equipment Corporation delivered the ENFE development mm-
computer (DEC PDP-11/70) three months late. This slowed con-
struction ot critical ENFE operating system software. Associated
omputer Consultants delivered the Honeywell-DEC communications
ink three months late, which delayed software installation,
esting, and evaluation. Therefore, only a crude evaluation of
NFE capabilities is available at this time. Despite these de-
ays, however, all ot the essential work contracted for has been
uccessfully completed. The ENFE was built, tested, and is
urrently operational.
JNFE Final Report 9/30/77
■NFE Research Program
The ENFE research program was organized into two teams,
rhe first team implemented the ENFE. The ENFE uses a DEC
'DP-11/70 computer running a Unix general purpose operating sys-
:em. The Unix operating system capabilities were expanded to
>rovide more general support for Host-to-Front-End Protocol (HFP)
software. Measurement software was added to Unix to support
:ests and experiments.
The second team was concerned with protocol issues. This
:eam revised the HFP specifications, generated Telnet protocol
>ptions for Honeywell VIP terminals, conducted offloading stu-
lies, followed AUTODIN II protocol developments, and constructed
» plan for research into alternative front-end architectures.
Individuals and small groups were drawn from both of
ihese teams to generate an experiment plan and to carry out and
malyze ENFE tests and experiments.
There were some risks associated with the ENFE research
urogram. The state of the art in network communications is
jeared to machine/terminal interaction rather than
machine/machine interaction. A generalized machine-to-machine
Protocol like HFP had never been used to facilitate communica-
:ions between a large computer and a front end. Furthermore,
Jnix was not designed to support high speed message switching.
>iven the state of the art in HFP and the architecture of Unix,
-he Unix ENFE and HFP software were strictly experimental. The
Primary product of this research program was experience with the
ENFE Final Report 9/30/77
host front-ending problem.
All work (except the multi-host study) performed under
the contract has already been thoroughly documented (Tables 1 and
2). Thus, this final report will abstract those reports pro-
duced .
!NFE Final Report 9/30/77
Table 1
Contract Deliverables
AC Document CCTC-WAD Document Title Date
Number Number
220 7501
DRAFT H6000 Software 15 Nov. 1976
Specifications
221 7502 DRAFT Experimental 15 Dec. 1976
Network Front End
Functional Description
220 7501 FINAL H6000 Software 10 Jan. 1977
Specifications
221 7502 FINAL Experimental 15 Jan. 1977
Network Front End
Functional Description
227 7509 DRAFT Experimental 28 Mar. 1977
Network Front End
Experiment Plan
227 7509 FINAL Experimental 16 May 1977
Network Front End
Experiment Plan
232 7512 DRAFT Alternative 16 May 1977
Architecture Research
Plan
233 7515 DRAFT Experimental 1 July 1977
Network Front End
Software Functional
Description
233 7515 FINAL Experimental 1 Aug. 1977
Network Front End
Software Functional
Description
2NFE Final Report 9/30/77
AC Document CCTC-WAD Document Title Date
Number Number
232 7512 FINAL Alternative 30 Sept. 1977
Architecture Research
Plan
239 7517
UNIX/ENFE Experimen- 30 Sept. 1977
tal Performance Report
230 7511 Offloading ARPANET 30 Sept. 1977
Protocols to a Front
End
241 7519 ENFE Nassi-Shneider- 30 Sept. 1977
mann Flow Charts
242 7520 ENFE Listings and 30 Sept. 1977
Object Code
240 7518 ENFE Final Report 30 Sept. 1977
JNFE Final Report 9/30/77
Table 2
Unscheduled Reports Delivered
AC Technical CCTC-WAD Document Title Date
Number Number
219 7503 Host to Front End 19 Aug. 1977
Protocol/Version I
80 7504 ARPANET Host-Host 17 Mar. 1977
Process-to-Service
Protocol Specification
81 7505 Program Access Proc- 10 Mar. 1977
ess-to-Service Spec-
ification
82 7506 Server Virtual Ter- 17 Mar. 1977
minal Process-to Ser-
vice Protocol Spec-
ification
84 7507 Illinois Inter-Proc- 1 Apr. 1977
ess Communication Fa-
cility for Unix
94 7514 Telnet Data Entry 27 June 1977
Terminal Option
ENFE Final Report 9/30/77
ENFE SOFTWARE ARCHITECTURE
General Description
The offloaded network software can be thought of as a set
Df services provided to host (H6000) processes or to users,
rhese services allow the network and the various hosts connected
to the network to be conveniently used. A complete functional
description of the ENFE software architecture is contained in CAC
Document No. 233. The key features are summarized below.
■lost -to -Front -End Communications
A basic mechanism must be provided to support communica-
tion between host processes and front-end services. This mechan-
Lsm is the Host-to-Front-End Protocol (HFP) , which is defined in
:AC Document 219 (ARPA Request for Comments (RFC) 710). The HFP
specification distinguishes two protocol layers: the channel
)rotocol and the process-to-service protocols.
Channel Protocol. By means of the channel protocol, log-
cal channels are set up between host processes and the front-end
services, and messages are transmitted on these channels. Provi-
sions are made for flow control and for out-of-sequence signal-
ing. The channel protocol defines five types of HFP Messages:
SNFE Final Report 9/3B/77
1. BEGIN, which sets up logical channels;
2. END, which terminates logical channels;
3. TRANSMIT, which transmits data;
4. SIGNAL, which provides a means for synchron-
izing the ends of a logical channel, for
interrupting the other end, and for flushing
data from the other end of the channel; and
5. EXECUTE, which provides a means for passing
service-specific information "out of band;"
i.e., outside the strict sequencing required
for TRANSMIT Messages.
2ach Message type can be either a Command (requesting that the
iction defined by the Message be taken) or a Response (indicating
whether the action was taken and, if not, providing some explana-
:ion). The HFP specifications use the capitalized word, Message,
:o refer to these Message types.
Channel Protocol module. The front end contains a
ioftware module, the Channel Protocol module (CPM) , which manages
he logical channels and serves as a bi-directional multiplexor.
■he host also contains a CPM which similarly manages the other
^nds of the logical channels.
'£ocess-to-Service Communications
Communications between a host process and a front-end
ervice may be divided into three stages:
1. communications between the host process and
the host CPM (described in CSC Document No.
8
1NFE Final Report 9/30/77
R493700056-2-1, "Host to Front-End Processor
Protocol Interface Functional Description"),
2. communications between the host CPM and the
front-end CPM (described in CAC Document No.
220, "H6000 Software Specifications" and CAC
Document No. 219, "Host-to-Front-End Proto-
col") , and
3. communications between the front-end CPM and
a front-end service (described in CAC Docu-
ment No. 233, "Experimental Network Front End
Software Functional Description").
Process-to-Service Protocols. The process-to-service
protocols specify the content, sequencing, and type of HFP Mes-
ages by which host processes communicate with front-end ser-
ices. The process-to-service protocols implemented in the ENFE
re :
1. ARPANET Host-Host Process-to-Service Protocol
(CAC Technical Memorandum No. 80),
2. Program Access Process-to-Service Protocol
(CAC Technical Memorandum No. 81), and
3. Server Virtual Terminal Process-to-Service Protocol
(CAC Technical Memorandum No. 82) .
Service Structure . Each front-end service implements one
rocess-to-service protocol. All front-end services execute
ithin their own address spaces; i.e., as user-level programs.
Each program is structured as a finite state machine that
ccepts two types of inputs. HFP Message inputs are generated by
rocesses in the host requesting action from the front-end ser-
ices. I/O completion event inputs are generated by the system
;NFE Final Report 9/30/77
n response to service-initiated device I/O operations. Each
nput is associated with a specific HFP logical channel. The
nput type and current channel state determine the immediate
ction and next channel state. Most actions result in the
ransmission of data to another destination and in the generation
f an HFP Response indicating the success or failure of the ac-
ion .
Host-Host Service module. The ARPANET Host-Host Service
HHS) module enables programs running in the host to use the
RPANET Network Control Program (NCP) in the front end. It im-
lements the ARPANET Host-Host process-to-service protocol.
Program Access Service module. The Program Access Service
PAS) module enables programs running in the host to execute
rbitrary programs in the front end. It implements the Program
-cess process-to-service protocol.
Server Virtual Terminal Service module. The ARPANET
erver Virtual Terminal Service (SVTS) module enables programs on
ie host to be accessed by terminals connected to other hosts on
ie ARPANET. It implements the ARPANET Server Virtual Terminal
rocess-to-service protocol. It also implements the ARPANET Tel-
it protocol described in NIC Document No. 15372.
10
NFE Final Report 9/30/77
PROTOCOL SPECIFICATIONS
os t -to-Front -End Protocol
The performance of data communications tasks such as ter-
inal handling and network protocol interpretation can impose a
ignificant load on a host. Some of these tasks can be performed
the front end for the host. The Host-to-Front-End Protocol
HFP) defines a form of communication between the host and the
ront end to enable this "offloading" of services.
Thus, the HFP provides specifications for:
1. a channel protocol,
2. individual Commands and Responses,
3. the process-to-CPM interface, and
4. the service-to-CPM interface.
i addition, the HFP provides specifications for specifying
i:ocess-to-service protocols.
Each HFP Message contains a HEADER carrying channel pro-
>col information and may contain TEXT carrying process-to-
>rvice protocol information. Process-to-service protocols use
*?P Messages to carry information between a process and a service
'dule. The HFP Message types are:
1. BEGIN Command/Response,
2. END Command/Response,
11
1NFE Final Report 9/30/77
3. TRANSMIT Command/Response,
4. SIGNAL Command/Response, and
5. EXECUTE Command/Response.
RPANET Host-Host Process-to-Service Protocol
CAC Technical Memorandum No. 80 specifies a process-to-
ervice protocol for providing ARPANET Host-Host Protocol and
nitial Connection Protocol services to a process through the
FP. The Host-Host Protocol is the basic inter-process communica-
ion protocol for the ARPANET (ARPANET NIC Document 8246). The
rogram which implements it in each host is the Network Control
rogram (NCP) . The service described here provides an interface,
trough the HFP, between a process in a host and an NCP in a
ront end. This enables the host process to establish and use
RPANET connections.
-ogram Access Process-to-Service Protocol
CAC Technical Memorandum No. 81 specifies a process-to-
brvice protocol for the execution of, or attachment to, arbi-
:ary programs in the front end. The intent was to provide a
?neral mechanism that would allow the host to access terminal-
lented front-end services. Examples of such services are User
'lnet and teleconferencing.
The protocol assumes that the program access service
12
ENFE Final Report 9/30/77
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 TRANSMIT
:ommands are used for this data transmission.
>erver Virtual Terminal Process -to -Service Protocol
CAC Technical Memorandum No. 82 specifies a protocol for
iff loading the server side of a virtual terminal protocol; e.g.,
ierver Telnet for the ARPANET. This protocol allows some flexi-
>ility in the degree of offloading that may be achieved.
Jthough the protocol is applicable to a general virtual terminal
ervice, the discussion in the specification is in terms of the
RPANET Telnet Protocol, which is currently the only such proto-
ol widely used.
The functions of the typical Server Telnet implementation
nclude :
1. manipulating network connections,
2. negotiating Telnet options,
3. mapping between local terminal representa-
tions and network virtual terminal represen-
tations ,
4. transmitting data over connections,
5. handling special control functions, and
13
2NFE Final Report 9/30/77
6. interfacing remote terminals so that they
appear as if they were local terminals.
The server virtual terminal process-to-service protocol
ises HFP Messages to carry information between the residual part
Server Telnet in the host (the "process") and the Server Vir-
ual Terminal Service module (the "service") in the front end.
ther Process-to-Service Protocols
Further study of the problem of offloading Telnet led us
o conclude that a single, symmetric protocol should be designed
o handle both User and Server Telnet services. We have con-
tructed, but have not implemented, such a protocol (CAC Techni-
al Memorandum No. 103, "Network Virtual Terminal Process-to-
ervice Specification"). This protocol specification, inaddi-
ion to specifications for three process-to-service protocols
onstructed in connection with our study of strategies for of-
loading the ARPANET File Transfer Protocol, is appended to CAC
Jcument No. 230, "Offloading ARPANET Protocols to a Front End."
yj}et Data Entry Terminal Option
Under the current contract, we have been tasked to pro-
Lde facilities for attaching data entry terminals, specifically
»e 7705 VIP terminal, to the ENFE and the Telnet software. How-
er, the Telnet protocol was originally designed to support sim-
•e, scroll-mode terminals. To get the maximum amount of useful-
?ss out of a data entry terminal, the Telnet protocol needed to
14
1NFE Final Report 9/30/77
■e extended. Fortunately, the Telnet protocol has a built-in
:echanism, the "option negotiation" mechanism, to allow such
xtension. We have therefore defined an option to support data
ntry terminals. In effect, this option defines the Network Vir-
ual Data Entry Terminal. This option supports a minimal set of
seful functions common to most data entry terminals and also
Hows a number of highly sophisticated functions to be negotiat-
d. Details of this option may be found in "Data Entry Terminal
ption," CAC Technical Memorandum No. 94 (ARPANET RFC 731).
15
)NFE Final Report 9/30/77
EXPERIMENTATION
xperimental Network Front End Experiment Plan
This document (CAC Document No. 227) described our prel-
minary plans for the ENFE tests and experiments. The three main
ections identified:
1. goals of the experimentation,
2. tools for experimentation, and
3. scenarios for specific experiments.
Goals. The goals of the experiment plan fell into three
ategories :
1. performance testing,
2. fine-tuning of the system, and
3. investigating benefits to be
gained from design changes.
ests were proposed to determine whether the system works as it
s supposed to and is able to provide the front-ending facilities
eeded in the short term by the WWMCCS community. In particular,
throughput and terminal support tests were given high priority.
Tools. In this document we described an optimal set of
^ols for thoroughly understanding the front end. The set we
lanned to implement included:
1. timing mechanisms for generating interrupts
as specified by the experimenter and for
timestamping messages,
2. artificial traffic generators (involving both
software and hardware) at the three front-end
16
NFE Final Report 9/30/77
interfaces (the interfaces to the host, to
the network, and to the terminals), and
3. software to collect data as the experiments
are run.
ther tools described in this document such as a simulation pro-
ram and queueing theory analysis are essential to a follow-on
tudy of how the front-end design may be improved.
Specific Tests. In the last section of the report, we
resented a set of scenarios for specific tests. These were
ecessarily tentative, particularly as to details. We also mapped
at a more comprehensive program of experimentation than we ex-
scted to be able to carry out under the current contract. Tests
id experiments will continue under a follow-on contract (the
nase B work) .
jIX/ENFE Experimental Performance Report
CAC Document No. 239 reports on the results of the Phase
-program of testing and experimentation.
Experimentation Software. The front-end tests used a
>nfiguration of software modules similar to the standard ENFE
^figuration, except that local and foreign host processes were
mulated by processes resident in the ENFE itself. These
^ocesses served as message generators, sending messages to each
'•her via the standard ENFE modules. An extra copy of the Chan-
el Protocol module was also included in the ENFE to interface
"e "local host" message generator to the front-end's Channel
17
1NFE Final Report 9/30/77
'rotocol module.
In order to make accurate timing measurements, a pro-
rammable clock was attached to the PDP-11/70. System calls were
mplemented to enable the experiment software to utilize this
lock to get clock readings and to schedule interrupts. Times-
amping software was built into the front end at various points,
his software inserted clock readings (timestamps) into the texts
f messages as they were transmitted through the front end. In
his way the progress of a message through the ENFE could be
easured to a high degree of accuracy.
Small modifications were made in the standard Unix moni-
oring facilities to provide for monitoring of kernel-level as
ell as user-level processes. This allowed a detailed analysis
t processor usage.
Experiment Results. a large part of the Phase A testing
id evaluation task involved testing the software to make certain
iat it operates correctly. A certain amount of fine-tuning
nore than was anticipated in the Experiment Plan) was also car-
ned out. The Phase A measurements reported here have allowed us
identify which portions of the system need to be made more
Ificient and to draw broad conclusions regarding the system
chitecture.
The measurements reported here include:
1. timing tests of the Inter-Process Communica-
tion (IPC) primitives.
2. timing of the progress of single messages
18
INFE Final Report 9/30/77
through the front end,
3. monitoring of processor usage, and
4. saturation throughput using several different
configurations .
From timing the IPC primitives, we found that it requires
minimum of five to six milliseconds to relay a message from one
ront-end process to another. The single-message timing measure-
ents indicate that (except in the case of the NCP) the time a
essage spends being processed by the modules is a small fraction
f the time required to relay the message between modules. Moni-
oring the processor usage by the Channel Protocol module and by
he Host-Host Service shows that 85 to 90 percent of CPU time is
xpended in system calls. Furthermore, kernel-level monitoring
hows that about half of this time is just in the overhead of
aking system calls. We conclude that, as long as the front-end
rchitecture requires Unix system calls to relay messages from
ne module to another, no dramatic improvement in the efficiency
f the front-end services can be expected.
Obtaining meaningful throughput measurements has been
ade difficult by the self-contained experimentation configura-
ion, which included two passages through the NCP. In this con-
iguration, we found that throughput is severely limited by the
-P. To investigate the extent of this limitation, we have sent
usages as fast as possible from the ENFE through the Urbana IMP
3 an 11/50 at Urbana. With this configuration, each message is
andled only once by the ENFE NCP. The maximum throughput
19
■
FE Final Report 9/30/77
easured to date with this configuration is about 50 kilobaud
already enough to saturate the ARPANET) when messages are sent
/ the 11/50 to the ENFE. However, when messages are sent from
ne ENFE the throughput is roughly 40 percent less. We attribute
lis difference to inability of the slower 11/50 to receive data
apidly .
To further investigate the factors affecting throughput,
i? have separately exercised the two major portions of the mes-
sage path in the self-contained configuration. The front-end
prtion of the path (from the message generator to the Host-Host
!?rvice) has a message throughput that is four to five times
::eater than that of the network portion (from a message genera-
te through the NCP to the IMP and back through the NCP to a mes-
sige receiver). These results provide corroboration of the lim-
ping effect of the NCP.
20
ENFE Final Report y/30/77
IMPLICATIONS OF EXPERIMENT RESULTS
lulti-Host Study
In this study we examine the impact ot a multi-host conti-
nuation on a network front end (NFE) . This impact is a function
>f both the capacity and the structure ot the NFE. in this
itudy, the NFE examined is the WWMCCS Phase A Experimental NFE
ENFE). Our estimates show that the WWMCCS Phase A ENFE can sup-
ort a multi-host configuration. Minor protocol changes may be
equired.
Figure 1 shows a model NFE in a single-host configuration.
he NFE communicates with the host via a host interface. In the
NFE this is the Asynchronous Bit Serial Interlace (ABSl) . The
FE communicates with the network via a network interface. In
he ENFE this is the IMP-11A. The NFE communicates with termi-
via terminal interfaces. in the ENFE, these are DH-ll and
V-ll interfaces.
Figure 2 shows an NFE in a multi-host configuration. The
itference between this and the single-host configuration is that
l the multi-host configuration there are additional host inter-
nes (ABSI's in the ENFE).
We discuss the quantitative and qualitative effects ot ot
Uti-host configurations on the NFE. We first deal with the
antitative effects. In so doing, we develop a method for
'termining the resources required in the NFE for a given load
21
<]NFE Final Report y/30/77
mposed by the many hosts. We then deal with the qualitative el
ects on the NFE and the protocols that it uses.
22
NFE Final Report 9/30/77
Single-Host NFE Conr igurat ion
'
H
N
I
NFE
I
T I
0
/ \
/ \
/ \
0
N
E
p
T
W
T
u
R
K
were:
HI
NI
TI
PT
T
Interlace to the host
Interface to the network
Interfaces to terminals
Port
Terminal
Figure 1^.
2i
NFE Final Report y/30/77
Multi-Host NFE Conf iguratio n
P
T
N
E
T
W
U
R
K
HI
NI
TI
PT
T
Interlace to the host
Interface to the network
Interlaces to terminals
Port
Terminal
Figure 2.
24
;NFE Final Report y/30/77
When we ask whether an NFE can support a given multi-host
onf iguration, we are asking, in part, whether the resources
vailable in the NFE are sufficient to support the load imposed
y the hosts. Put another way, it Rlimit is the amount of a
iven resource R which is available in the NFE and Rreq is the
otal amount of the resource R which is required to support the
oad imposed by the hosts, we must have:
Rreq < Rlimit, for all resources R.
o determine whether or not this condition holds, we must compute
req. To do this, we break the NFE down into its component
odules, and determine the resources required by each module. We
hen analyze the load in terms of the use of NFE modules which it
ntails. Finally, we obtain the total resource requirement by
umming the resources required by each module for supporting the
oad imposed by the hosts.
Let Rmodule[m] be the amount of resource R that is required
y module m. Then Rreq is computed by the summation
M
U) Rreq = \ Rmodule lm] ,
I
m=l
lere M is the number of modules in the NFE. Rmodule [m] will in
sneral consist of two parts: the fixed part, Rfixedlm], and the
ariable part, Rvar [m] . Thus
U) Rmodule lm] = Rfixedlm] + Rvar lm] .
tixedfm] is the amount of resource R which is required by module
25
;NFE Final Report y/30/77
i independently ot the load. Rvar [m] is the amount of resource R
hich is required by module m and which varies with the load.
We can usually determine Rfixed[m] directly from m by meas-
rement. To determine Rvar [m] , we first determine the amount of
esource R that is required by module m for each unit ot load.
nis we call Rload [m] . We then determine the total load that en-
ails the use ot module m. This we call Lmodule[m]. Then
(3) Rvar [m] = Rload lm] * Lmodule [m] .
module [m] will be the sum ot the loads which are imposed by each
f the hosts and which entail the use ot module m. We let L[h,mJ
e the load which is imposed by host h and which entails the use
t module m. It H is the number ot hosts,
H
I
(4) Lmodulelm] = \ L[h,m],
h = l
H
(5) Rvarlm] = Rload [m] * ) L[h,m],
I
h = l
H
(6) RmodulelmJ = Rf ixed [m] + (Rload [m] * \ L[h,m]), and
I
h = l
26
NFE Final Report 9/30/77
M H
V V
} (Rfixed[m] + (Rloadfm] * >
(7) Rre(? = ) (Rfixedlm] + (Rloadfm] * ) Llh,m])).
m=l n = i
e note that the model we have developed employs a linear rela-
ionship between load and resource consumption. In the real
jorld, such a relationship does not always hold, particularly
<ith respect to time-limited resources such as processor time.
We now discuss this method in more detail. In an NFE, the
^sources we consider are ot two kinds: space-limited resources
hd time-limited resources. The space-limited resource we con-
fer is primary memory. The time-limited resources we consider
;:e processor time and interface bandwidth. We will discuss the
imputation of Rreq for primary memory in some detail. We will
:scuss the other two resources only insofar as their treatment
offers from that of primary memory.
We first consider the primary memory resource C. Let Climit
the total available memory in the NFE. We want to compute
eq, the total amount ot memory required to support the load im-
sed by the hosts. Then we can determine whether
Creq < (Jlimit.
this relation holds, then the memory in the NFE is sufficient
: support the load imposed by the hosts.
Consulting equation (4), we see that the first step in com-
bing Creq requires the determination ot L[h,m] for each host h
27
1NFE Final Report 9/30/77
nd for each module m. This information can be conveniently
epresented by a matrix:
L[l,l] L[l,2] .... L[1,M]
L[2,l] L[2f2] .... L[2,M]
L[H,1] L[H,2] .... L[H*,M]
ach row represents the load which is imposed by a given host,
ach column represents the load which entails a given module. We
ote that the sum of column m is Lmodule [m] .
To determine the L[h,m], we need two sets of information
nich involve the services which the NFE performs for the hosts.
B let U[h,s] be the number of simultaneous uses of service s by
bst h. This information can also be represented by a matrix:
U[l,l] U[l,2] .... U[1,S]
U[2,l] U[2,2] .... U[2,S]
• • .
U[H,1] U[H,2] .... U[H*S]
•lere S is the number of different services performed by the NFE.
Ich row represents the use of services by a given host. Each
olumn represents the use of a given service across all hosts.
We let E[s,m] be the number of unit loads imposed on module
for each use of service s. Again the information can be
'presented by a matrix:
E[l,l] E[l,2] .... E[1,M]
E[2,l] E[2,2] .... E[2,M]
• • .
E[S,1] E[S,2] .... E[S,M]
28
NFE Final Report 9/30/77
ach row represents the load on the modules of the NFE for each
ise of a given service. Each column represents the load on a
dven module when each service is used once.
Then
S
(8) L[h,m] = ) U[h,s] * E[s,m]
y„,
liat is,
s = l
L = UE.
Consulting equation (5), we see that the next step in com-
Iting Creg requires the determination of Cload [m] for each
Tdule m. This is simply the amount of memory required by module
for each instance of whatever module m does. If a copy of
*dule m is required for each instance of whatever module m does,
■en Cload [m] is the total memory used by each copy of module m.
the copies of module m all share the same reentrant program
^ each has a separate copy of the data space, then Cload [m] is
tie size of the data space for a copy of module m. If there is
Ply one copy of module m which allocates table space and buffer
fece for each instance of whatever module m does, then Cload [m]
the size of the table space and buffer space allocated for
fch instance of whatever module m does.
Consulting equations (6) and (7), we see that the final
ips in computing Creq require the determination of Cfixed[m]
29
NFE Final Report 9/30/77
br each module m. This is simply the amount of memory required
U module m independent of how many instances there are of what-
«/er module m does. If a copy of module m is required for each
jistance of whatever module m does, then Cfixed[m] is zero. If
tie copies of module m all share the same reentrant program but
cich has a separate copy of the data space, then Cf ixed [m] is the
s.ze of the reentrant program. If there is only one copy of
indule m which allocates table space and buffer space for each
iistance of whatever module m does, then Cfixed[m] is the size of
irdule m when no such table space and buffer space is allocated.
The computation of Creq thus consists of the following 9
seps :
(a.) construction of the matrix U ,
2) construction of the matrix E,
) computation of the matrix L = UE,
) computation of Lmodule[m] using equation (4),
) determination of Cload[m],
) computation of Cvar [m] using equation (5),
) determination of Cfixedfm],
) computation of Cmodule[m] using equation (6), and
) computation of Creq using equation (7).
• note that steps 1, 2, 3, and 4 are independent of the resource
J:3er consideration. Therefore these steps need be performed
a»ly once for all resources.
1
2
3
4
5
6
7
8
9
If Climit > Creq, the total memory in the NFE will be ade-
ate. But if the NFE is implemented on a mini-computer, we may
30
NFE Final Report 9/30/77
lso have to take into account the limitation on the amount of
ismory that can be addressed by each module.
We let Caddr be the address limit imposed on each module by
le structure of the NFE hardware. Then the condition that must
bid is
Caddr > Cmodule[m], for all modules m.
Ills requires no additional computation, since the Cmodule [m]
fere computed in step 7 above.
We now turn our attention to the time-limited resources:
rocessor time and interface bandwidth.
Let us first consider the processor time resource P. This
rsource will be treated differently from primary memory in three
wys:
1) We are more likely to be interested in the frac-
tional utilization of P than in absolute measures
m seconds. That is, Plimit will be 1 and
Ploadfm], Pfixedfm], Pmodule[m], and Preg will be
expressed in fractions of the available processor
time.
2) For most modules m, Pfixed[m] will be very small
or zero. Exceptions will be those modules which
implement communication protocols that require
continuous activity for maintaining communica-
tion, even when there is no data to be sent or
received.
3) Our simple linear model of the relation between
load and resource use may have to be replaced by
a more sophisticated model such as queueinq
theory.
The last resource we consider is the interface bandwidth
source B. This resource will be treated differently from pri-
31
:NFE Final Report 9/30/77
lary memory in the three ways mentioned above under processor
ime. Further, interfaces are specialized resources as opposed
0 universal resources such as memory space and processor time,
his has two consequences:
1) Use of each interface will probably be limited to
a single module.
2) The computations for each interface, or kind of
interface, will have to be made separately.
We now apply our modeling method to a concrete example using
umerical data. We set ourselves the task of computing Creq for
ie ENFE in a hypothetical multi-host configuration. Our purpose
s to illustrate the application of the method. Therefore we
till oversimplify wherever it suits our convenience.
We employ the 9-step method discussed above.
In step 1, we construct the matrix U. We recall that U[h,s]
1 the number of simultaneous uses of service s by host h. We
mst therefore define the services performed by the ENFE. There
c'e five:
1) HH performs ARPANET Host-Host Protocol interpre-
tation for each of the local hosts.
2) SVTn serves as intermediary between the local
hosts one one hand and remote terminals connected
via the ARPANET on the other.
3) SVTt serves as intermediary between the local
hosts on one hand and local terminals attached to
the ENFE on the other.
4) UVTh serves as intermediary between terminals at-
tached to the local hosts on one hand and remote
hosts connected via the ARPANET on the other.
5) UVTt serves as intermediary between local termi-
32
NFE Final Report 9/30/77
nals attached to the ENFE on one hand and remote
hosts connected via the ARPANET on the other.
e note that the service UVTt does not involve the local hosts,
t only involves local terminals attached to the ENFE. To ac-
ount for the ENFE resources consumed by this service, we intro-
uce a -phantom host" T. Let there be 3 local hosts, and let the
se of ENFE services be as shown in Figure 3. This then is the
latrix U.
service
HH SVTn SVTt UVTh UVTt
h 1 10 5 5 10
o 2 12 6 7 4
S3 9 3 11 6
t T - - - 15
Figure 3. U[h,s]
In step 2, we construct the matrix E. We recall that E[h,s]
the number of unit loads imposed on module m for each use of
service s. We must therefore examine the structure of the ENFE
t> identify the modules in the ENFE, determine what constitutes a
it load for each module, and determine how many unit loads are
uposed on each module for each use of each service.
There are 9 modules in the ENFE that are pertinent to this
cscussion :
1) CPM is the Host-to-Front-End Protocol (HFP) chan-
nel protocol module. Its unit load is a logical
channel .
2) HHS is the HFP service module that enables the
local hosts to access the ARPANET NCP. Its unit
load is a logical channel and the associated du-
33
NFE Final Report 9/30/77
plex ARPANET connection.
3) NCPD is the portion of the ARPANET NCP which is
implemented as a daemon process. Its unit load
is a duplex ARPANET connection.
4) NCPK is the portion of the ARPANET NCP which is
implemented as part of the Unix operating system
kernel. Its unit load is a simplex ARPANET con-
nection.
5) SVTS is the HFP service module that enables the
local hosts to access both remote terminals con-
nected via the ARPANET and local terminals at-
tached to the ENFE. Its unit load is a logical
channel and the associated terminal.
6) UTH is the program that enables terminals at-
tached to the local hosts to access remote hosts
connected to the ARPANET. Its unit load is a ter-
minal and the associated ARPANET connection.
7) UTT is the program that enables terminals at-
tached to the ENFE to access remote hosts con-
nected via the ARPANET. Its unit load is a termi-
nal and the associated ARPANET connection.
8) TD is the Unix terminal device driver. It enables
terminals attached to the ENFE to access other
modules in the ENFE. Its unit load is a terminal.
9) PA is the HFP service module that enables the lo-
cal hosts to access programs in the ENFE (such as
UTH). Its unit load is a logical channel and the
associated program.
Gven the functions performed by each of these modules, the ma
tix E is as shown in Figure 4.
module
CPM HHS NCPD NCPK SVTS UTH UTT TD PA
s
e
HH
1
1
1
2
0
0
0
0
0
r
SVTn
1
0
1
2
1
0
0
0
0
v
SVTt
1
0
0
0
1
0
0
1
0
i
UVTh
1
0
1
2
0
1
0
0
1
c
UVTt
0
0
1
2
0
0
1
1
0
e
F
igure 4.
E[s
rm]
34
NFE Final Report 9/30/77
In step 3, we compute the matrix L = UE. This is shown in
figure 5. We now have the load imposed on each module by each
hst. For example, host 1 imposes 30 unit loads on the CPM.
module
CPM HHS NCPD NCPK SVTS UTH UTT TD PA
h
1
30
10
25
50
10
10
0
5
10
0
2
29
12
22
44
13
4
0
7
4
s
3
29
9
18
36
14
6
0
11
6
t
T
0
0
15
30
0
0
15
15
0
Figure 5. L[h,s]
In step 4, we compute Lmodule[m] by summing the columns of
L For example, the sum for the CPM column of L is:
Lmodule[CPM] = 30 + 29 + 29 + 0 = 88.
I now have the total load imposed on each module by all hosts.
In step 5, we determine Cload [m] for each module m. For ex-
aple, by examining the ENFE program listings, we find that for
ech logical channel, the CPM requires 14 bytes of table space,
lerefore, Cload [m] for the CPM is 14 bytes.
In step 6, we compute Cvar [m] as the product of Lmodulefm]
W CLoad[m]. For example, for the CPM we have:
Cvar [CPM] = 88 * 14 = 1232 bytes.
In step 7, we determine Cfixed[m]. For example, by examining
m memory maps of the ENFE modules, we find that the CPM re-
ires 12522 bytes, exclusive of the memory required per logical
35
ENFE Final Report 9/30/77
channel. We note that the modules NCPK and TD are actually im-
plemented as parts of the Unix operating system. To account for
the memory used by the operating system, we introduce another
module called UNIX. We include the Cf ixed [m] for NCPK and TD in
the Cfixed[m] for UNIX.
In step 8, we compute Cmodule[m] as the sum of Cvar [m] and
Cfixedfm]. For example, for the CPM we have:
Cmodule[CPM] = 1232 + 12522 = 13754 bytes.
We now have the total memory required by each module under the
load that is defined by matrix U.
The results of steps 4 through 8 are shown in Figure 6.
Module m Lmodule[m] Cload[m] Cvar [m] Cfixed[m] Cmodule[m]
CPM
88
14
1232
12522
13754
HHS
31
32
992
10982
11974
NCPD
80
58
4640
17864
22504
NCPK
160
202
32320
0
32320
SVTS
37
56
2072
13162
15234
UTH
20
1294
25880
2974
28854
UTT
15
3976
59640
7183
66823
TD
38
192
7296
0
7296
PA
20
32
640
13522
14162
UNIX
0
0
Figure
0
6.
71452
71452
Finally, in step 9, we compute Creq as the sum of the
Cmodule [m] . We find that
Creq = 284373 bytes.
For a PDP-11/70
Climit = 2**22 = 4194304 bytes.
Hence we have, for the load defined by matrix U,
36
ENFE Final Report 9/30/77
Creg < Climit.
All of the foregoing deals with the quantitative aspects of
deciding whether an NFE can support a multi-host configuration.
But there are also qualitative aspects to this question. These
qualitative aspects deal with the structure of the NFE hardware
and software and with the structure of the protocols that the NFE
uses. To facilitate our discussion, we will consider the ENFE
and the protocols that it uses.
We first consider the structure of the ENFE hardware. The
hardware basis of the ENFE is the PDP-11/70 computer. A multi-
host configuration will require the addition of ABSI's to the
ENFE hardware. The UNIBUS structure of the PDP-11/70 makes the
addition of ABSI's relatively easy.
We next consider the structure of the ENFE software. The
software must take into account the existence of multiple ABSI's
and of multiple hosts connected through them. There are two ef-
fects which must be considered:
1) the effect on the Unix operating system, and
2) the effect on the CPM and on the service modules.
The existence of multiple ABSI's presents no problem in the
Unix operating system. The structure of the I/O system permits
multiple devices of the same kind to be driven by a single re-
entrant device driver without confusion. It will permit the CPM
to determine on which ABSI a given message arrived. Therefore
the CPM will be able to determine from which host the message was
37
ENFE Final Report 9/30/77
received. It will also permit the CPM to direct a message to the
proper ABSI, hence to the proper host.
The existence of multiple ABSI's, and of multiple hosts con-
nected through them, may have some effect on the structure of the
CPM and of the service modules. This effect can be very small if
a minor change is made to the HFP. We first discuss the problem.
The current version of the CPM and of the service modules
uses logical channel numbers to identify the separate logical
communications channels between the CPM and the service modules.
These are the same logical channel numbers that are used in com-
munication between the CPM in the host and the CPM in the ENFE.
If there are multiple hosts, and if no change is made in the
current policy for assigning logical channel numbers, confusion
will result in the ENFE when two or more hosts use the same logi-
cal channel number.
One solution is to add a host field to the state tables in
the CPM and in the service modules. A host field would also have
to be added to all communications between the CPM and the service
modules. This host field would be used to distinguish logical
channels with the same logical channel numbers but from different
nosts. This solution would require substantial alteration of the
CPM and the service modules.
Another solution is to allot to each of the hosts a disjoint
subset of the logical channel name space. This would require
that the CPM check the logical channel number as it receives each
38
ENFE Final Report 9/30/77
message. This would ensure that the logical channel number in
the message matches the host from which it was received. The CPM
would also have to use the logical channel number to direct each
outgoing message to the proper ABSI. This solution requires re-
latively minor changes to the CPM. It requires no change at all
to the service modules.
We last of all consider the structure of the protocols that
the ENFE uses. Two protocols could affect, or could be affected
by, a multi-host configuration: the HFP and the ARPANET Host-Host
Protocol .
The only change which might be required in the HFP is in the
way that logical channel numbers are assigned. Currently the
(single) host may attempt to establish a logical channel using
any 28-bit number whose high-order bit is zero. In a multi-host
configuration, additional high-order bits could be used for iden-
tifying which logical channels belong to which hosts. This is
not a significant change to the structure of the HFP or to its
implementation.
The ARPANET Host-Host Protocol assumes a one-to-one
correspondence between network ports, hosts, and NCP's. This
means that confusion could result if a multi-host configuration
used a single network interface as shown in Figure 2. It might
se necessary to have a network interface for each host as shown
in Figure 7. This situation should be avoided in the design of
future networks such as AUTODIN II.
39
ENFE Final Report 9/30/77
Multi-Host NFE Configuration
(Multiple Network Interfaces)
HOST
HOST
H
I
N
I
H
NFE
N
I
I
l—
i_
H
I
N
I
T I
0
/ \
/ \
/ \
0
N
E
T
W
0
R
K
where:
HI
NI
TI
PT
T
Interface to the host
Interface to the network
Interfaces to terminals
Port
Terminal
Figure 7.
40
ENFE Final Report 9/30/77
OFFLOADING STRATEGIES
In CAC Document No. 230, "Offloading ARPANET Protocols to
a Front End," we presented a broad survey of offloading stra-
tegies for the most important ARPA Network protocols. This sur-
vey 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. We discussed in detail
the trade-offs involved in different degrees of offloading and
provided a brief analysis of the potential tor offloading each of
:ne Telnet options. We also discussed which process-to-service
protocols were needed to implement the various schemes. The sym-
metry 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 tor the ENFE was imple-
•ented with two separate PSP's - one for the user side and one
'or the server side) .
Offloading the File Transfer Protocol. We identified two
ajor aspects of the File Transfer Protocol (FTP) that were can-
idates for offloading: the data transfer process and the book-
ing and marker handling required for restarting a transfer
•hat has aborted. Since FTP makes use of the Telnet protocol,
Telnet functions can also be offloaded. Considering only the
-ser FTP, we tound that there are eight possible offloading
themes that differ from one another in major ways.
With regard to the offloading of Server FTP, we confined
41
ENFE Final Report 9/30/77
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.
To make specific the schemes for offloading FTP, we
designed three new process-to-service protocols: a User FTP PSP,
a Server FTP PSP, and a File Access PSP. The latter provides a
general facility for transferring files between host and front
end.
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,
2nd Network Graphics.
42
ENFE Final Report 9/30/77
ALTERNATIVE ARCHITECTURES
Alternative Architecture Research Plan
We developed a research plan (CAC Document No. 232) lead-
ing to the specification of a network front end (NFE) designed to
meet WWMCCS needs through the 1980's. In CAC Document 232, we
briefly reviewed the current state of the art as it affects NFE
development, identified some promising directions for research,
and presented a detailed plan for conducting the research.
State of the Art. We concluded that the NFE must be
modular, efficient, and multi-level secure if it is to meet
WWMCCS needs. Three groups of systems were considered relevant
to NFE development:
1. existing network access systems,
2. secure systems, and
3. high-bandwidth communications systems.
Examination of these three groups revealed that there does not
exist, nor will there exist in the near future, a system which
will meet WWMCCS needs.
Research Directions. We presented some promising ideas
for research which might lead to solutions to NFE problems. Two
alternative hardware architectures were presented tor solving the
bandwidth problem. An alternative software architecture, the Hub
System, was presented which may solve the problems of producing a
modular, efficient, and multi-level secure system.
Research Plan . We presented a research plan with four
phases :
1. the preparation phase,
43
ENFE Final Report 9/30/77
2. the research phase,
3. the prototype phase, and
4. the specification phase.
The preparation phase will produce a set of technical constraints
for the design of the WWMCCS NFE and will select a set of design
features to be studied in the research phase. The selection will
be performed through mathematical modeling using the technical
constraints. The research phase will design and construct a
Research NFE that will be used tor evaluating architectural con-
cepts through an iterative process of implementation, testing,
and measurement. The prototype phase will design and construct a
Prototype NFE which will serve as the basis for specifying the
WWMCCS NFE. The specification phase will develop the WWMCCS NFE
specf ication.
44
UNCLASSIFIED
JCURITY CLASSIFICATION OF THIS PAGE (Whin Data Entered)
REPORT DOCUMENTATION PAGE
READ INSTRUCTIONS
BEFORE COMPLETING FORM
REPORT NUMBER
CAC Document Number 240
CCTC-WAD DnmmPnr Niimhpr 7S1fi
2. GOVT ACCESSION NO
3. RECIPIENT'S CATALOG NUMBER
TITLE tend Subtitle)
Networking Research in Front Ending -
Final Report
5. TYPE OF REPORT ft PERIOD COVERED
Research
6. PERFORMING ORG. REPORT NUMBER
CAC #240
AUTHOR(»J
8. CONTRACT OR GRANT NUMBERf*,)
DCA100-76-C-0088
PERFORMING ORGANIZATION NAME AND ADDRESS
Center for Advanced Computation
University of Illinois at Urbana-Champaign
Urbana, Illinois 61801
10. PROGRAM ELEMENT, PROJECT, TASK
AREA ft WORK UNIT NUMBERS
. CONTROLLING OFFICE NAME AND ADDRESS
Command and Control Technical Center
WWMCCS ADP Directorate, 11440 Isaac Newton Sq., N
Reston, Virginia 22090
12. REPORT DATE
September 30, 1977
13. NUMBER OF PAGES
44
4 MONITORING AGENCY NAME ft ADD R ESSf/f dltttrent horn Controlling Olllce)
15. SECURITY CLASS, (of this ruport)
UNCLASSIFIED
15a. DECLASSIFI CATION/ DOWN GRADING
SCHEDULE
5 DISTRIBUTION ST ATEMEN T (ol thit Ruport)
Copies may be requested from the address given in (11) above.
' DISTRIBUTION STATEMENT (ol the abstract entered In Block 20, II different from Report)
No restriction on distribution.
! SUPPLEMENTARY NOTES
None.
' KEY WORDS (Continue on reverse side it necessary and identity by block number)
Network front end
Network protocol
ABSTRACT (Continue on reverse side II necessary and Identity by block number)
The CAC has been engaged in an investigation of the benefits to be gained
by employing a network front end. A DEC PDP- 11/70 was used as front end for
connecting a Honeywell 6000 host to the ARPANET. All work (except the multi-
host study) performed under the contract has already been thoroughly documentec
Thus, this final report abstracts those reports produced.
)f\ FORM -i ...»
^ I JAN 73 1473 EDITION OF I NOV 65 IS OBSOLETI
UNCLASSIFIED
SECURITY CLASSIFICATION OF THIS PAGE (When Data Entered)
unui
pi
1
'III
I
J mill
UNIVERSITY OF ILLINOIS-URBANA
in 111 in mi ii mi
3 0112 005438004
I
m
Live Music Archive
Librivox Free Audio
Metropolitan Museum
Cleveland Museum of Art
Internet Arcade
Console Living Room
Books to Borrow
Open Library
TV News
Understanding 9/11