Download Network operating systems-An implementation approach*

Network operating systems-An implementation approach*
by STEPHEN R. KIMBLETON, HELEN M. WOOD and M. L. FITZGERALD
National Bureau of Standards
Washington, D.C.
INTRODUCTION
provide two capabilities for endusers: job ececution and data
handling.
A network job consists of a collection of network job
steps, each of which may be executed on a different machine. The Network Job Execution function of a Network
Operating System should provide the means for initiating
job steps, migrating input information as appropriate, suitably disposing of output results and interacting with the user
as required.
Network Data Support provides the means for a user to
manipUlate files using a command language and for a program to access remote records at run time. To provide a
homogeneous viewpoint across systems, the NOS must provide a Network Wide Directory listing network accessible
data resources, a common command language for manipulating files listed in this directory, and a means for limiting
user access to these files to provide appropriate security
mechanisms. At the record access level, mechanisms are
required for preserving the meaning of data being transmitted between heterogeneous systems.
Implementation of these two enduser functions requires
two major support functions: user-system interfaces which
provides a common virtual viewpoint for the user across
heterogeneous systems and system-system interfaces to
support the transmission of data between systems and preserve the meaning of the transmitted data. Such interfaces
are discussed in sections three and four, respectively. Their
implementation requires resolution of some underlying design issues.
Networking affords a communications support mechanism
among heterogeneous computers. It does not provide any
means for alleviating the effects 'of differences across systems. As a result, network users are forced to resolve such
differences; the resulting learning and programming burden
inhibits effective utilization of networking capabilities to'
achieve resource sharing.
Achieving the potential of networking would be increased
through masking system differences from the user in many,
if not most, applications. Network Operating Systems
(NOSs)1,2 are commonly viewed as the mechanism for accomplishing this objective. The functional objective of an
NOS is to support and simplify access to existing services
and to expedite the construction and subsequent accessing
of new services by simplifying interaction among systems
and between systems and users.
The remainder of the Introduction discusses the required
enduser support which must be provided by a Network
Operating System, identifies the two major resulting implementation issues and describes the constraints which affect
the complexity of NOS implementation. Thereafter, the next
section describes major NOS design decisions guiding the
implementation of an Experimental NOS (XNOS) being implemented at the National Bureau of Standards (NBS) as
part of a joint RADC/NBS effort. The third section then
discusses the implementation of the user-system interface
while the fourth section discusses the system-system interface. The fifth section provides some concluding remarks.
Design issues and alternatives
Network operating systems
The difficulty of NOS implementation is critically dependent on the hardware and software environment which
must be' accommodated. Operationally, such situations can
be divided into three categories: (i) those requiring a retrofit
of the NOS to a heterogeneous collection of computer systems; (ii) those invovling retrofit to a homogeneous collection of computer systems; and (iii) situations in which there
is no constraint to interface to existing software.
A study of these alternatives shows the following: (i) retrofitting to heterogeneous hosts is the most difficult case
but maximizes resource sharing and best accommodates
A Network Operating System providing ease of access
and utilization of systems, subnetworks, and services must
* This work is a contribution of the National Bureau of Standards and is not
subject to copyright. Partial funding for the preparation of this paper was
provided by the U. S. Air Force Rome Air Development Center (RADC)
under Contract No. F 30602-77-F-0068. Certain commercial products are
identified in this paper in order to adequately specify the procedures being
described. In no case does such identification imply recommendation or
endorsement by the National Bureau of Standards, nor does it imply that the
material identified is necessarily the best available for the purpose.
773
From the collection of the Computer History Museum (www.computerhistory.org)
774
National Computer Conference, 1978
both planned and existing systems; (ii) retrofitting to a homogeneous collection of host computers is easier than retrofitting to a heterogeneous collection of hosts, but limits
the opportunity for resource sharing-a major rationale for
network construction; while (iii) unconstrained (e.g., built
from "scratch") implementations will be the most satisfactory from a user viewpoint, but lack downwards compatibility and, as a result, will be extremely costly to implement
since significant rewriting of existing software is required. 3
USER-SYSTEM
INTERFACING
CCl
CCl
Fro"
NJE
RSEXEC
NSH
~HA'D
SYSTEr1-SYSTEM
INTEqF,II.c I~JG
'~ETvIORK
RECORD
IPC
ACCESS
y
y
y
N:j:
N
y*
y*
y*
y*
N
.~CC~T
N/A
N/A
N/A
N:j:
Y
XNOS
Y
Y
Y
Y
Y
NOS related projects
* JOBS LI M!TED TO NS'" TOOLS
Before beginning our discussion of XNOS, we first briefly
describe three NOS related projects: RSEXEC, NSW and
ACCAT.
RSEXEC 4 was the first NOS oriented project. Since it
was implemented for a homogeneous collection of computer
systems (the TENEX systems within the ARPANET), the
user-system interface problem was non-existent. Its primary
contribution was exploration of the issues in providing a
network wide file space and in resolving references to remote files. Such references were handed through an encapsulation mechanism termed a JSYS trap 5 which, upon trapping such a reference, determined where the file was actually
located and arranged its migration to the site of the executing
program.
The National Software Works 6 is designed to provide a
sophisticated program production service. This is accomplished through networking together some of the more sophisticated program production tools available on different
systems and, via NSW support mechanisms, making this
collection appear as an entitiy to the individual user. Thus,
upon issuance of a request to utilize a particular tool, the
user and any appropriate files are automatically migrated to
one of the sites at which the tool is available. As a result,
the user only sees the provided tool and is unaware of the
system on which it is being run. With the spectrum of accessible objects thus constrained, it proves feasible to provide a uniform treatment of error responses.
The Advanced Command and Control Architectural
Testbed (ACCAT) is an interesting study in the problems of
interfacing a user to a Database Management System
(DBMS). A major problem in such an interface is the requirement that the user learn the syntax and semantics of
the query language. To circumvent this, ACCAT contains
a restricted natural language interface which transforms the
user's request into an internal form. This form is then translated into a series of queries against the database. 7,8 Collectively, this provides a fairly "soft" interface of the user to
the DBMS.
The preceding projects are primarily concerned with the
utilization of networking capabilities to achieve specific
functions. An explicit investigation of the interface issues
implicit in supporting a general purpose NOS across heterogeneous hosts is being undertaken in the Experimental
Network Operating Systems (XNOS) project at NBS. The
functional components being investigated by these four proj.
ects are illustrated in Figure 1.
:j: NOT USER ACCESSIBLE
Figure I-Major NOS functional components
NOS IMPLEMENTATION
Implementation of a Network Operating System requires
a series of design decisions. This section discusses two of
the major configuration related decisions. The following two
sections then articulate the issues in supporting the usersystem and system-system interfaces and discuss implementation specific factors.
Support components
Construction of a Network Operating System requires
both the design of certain procedures and processes, as
discussed in the following two sections, and determination
of the processors on which they are to be executed. Perhaps
the major design decision relates to where computing requirements are to be provided. Two alternatives exist for
providing these requirements: the existing hosts within the
network (the unaugmented case) or, alternatively, adding
specialized processors to satisfy most of these computing
requirements (the augmented case) which we will call Network Interface Machines (NIMs).
Utilization of NIMs for satisfying most of the NOS computing requirements has four major advantages. First, it
minimizes the impact of the NOS upon the host. This was
deemed highly desirable since it is felt that few installation
managers would tolerate any significant system overhead
for NOS support. Even fewer would be willing to accept
modifications of the host operating system.
The second advantage to offloading NOS support is the
consequent minimization of the need to recode functionally
identical modules to accommodate different systems and
architectures. This approach also facilitates centralized design, implementation and support of the NOS. Hence, the
third advantage-centralization-reduces costs by minimizing the number of support personnel.
The fourth advantage is facilitation of incremental expansion, modification and enhancement of NOS capabilities.
This seems particularly important since evolving experience
driven requirements are likely to result in gradual change of
the initial NOS.
From the collection of the Computer History Museum (www.computerhistory.org)
Network Operating Systems
These four advantages must be considered in the context
of two major implementation issues: attaching NIMs to hosts
and the cost of providing the NIMs. After discussing the
first issue and describing the initial XNOS implementation,
we shall return to the second.
Attaching NIMS to hosts
Attaching a NIM to a host can be accomplished in two
ways: implementation of the NIM as dedicated host(s) on
the network or as a frontend processor to the host. To the
authors, the second approach seems appropriate when Network Operating Systems have achieved a greater degree of
maturity. A significant amount of work has been concerned
with the relationship between the host and the frontend. 9
The primary concern of those studies is with optimization
of the provided functions rather than with identification of
the functions to be supported. Since present research is
more appropriately oriented toward identification, realization of the NIM as a dedicated host(s) on the network allows
concentration on NOS support issues and therefore seems
preferable.
A major advantage of implementing the NIM as a dedicated computer attached to the subnetwork is the consequent utilization of the host-host protocol to support communication between NIM and hosts. The disadvantage is
forgoing the simplification of connecting hosts which are ill
suited to interactive use.
The initial implementation-XNOS
An Experimental Network Operating System (XNOS) has
been implemented at the National Bureau of Standards to
facilitate investigation of the interface issues (discussed in
the following two sections) which must be supported to
achieve more effective utilization of network accessible resources. Figure 2 illustrates the initial XNOS configuration
and shows that NOS support is to be provided through a
NIM attached to the communications subnetwork (the ARPANET).
Given that the NIM is to be a dedicated host on the
communications subnetwork, only one is required to support
a full feasibility demonstration. This follows since ARPA-
PDP-10
MULTICS
~
,
ARPANET
U
~.
TENEX
•
NIM
Figure 2-Initial XNOS configuration
775
NET technology permits a host (the NIM in this case) to
establish a network connection with itself. Thus, a single
NIM can provide the functions required to interface to a
host issuing a request, the functions required to interface to
the host responding to the request, and the communications
functions required to interface between two NIMs. Thus,
the basic implementation approach illustrated in Figure 2
provides a reasonable, general purpose test environment.
The preceding comments have provided a general perspective on the adopted XNOS implementation approach.
In this environment, the NIM is a PDP-1l/45 running the
UNIX operating system and attached to the ARPANET via
a slightly modified version of the University of Illinois Network Control Program (NCP).
The XNOS supported hosts are: a Honeywell 6180 running the MULTICS operating system, a PDP-I0 running
TOPS-I0, a PDP-I0 running RENEX, and a PDP-1l/45 running UNIX. Based upon present experience we foresee little
difficulty in supporting any interactive system attached to
a communications subnetwork, preferrably using full duplex
communications. Support of batch systems has not yet been
investigated.
Logging in
Two basic approaches to logging into XNOS can be considered. In the first approach the user is directly logged into
a host computer and invokes XNOS support software
thereby being indirectly logged into XNOS. In the second
the user directly logs into the NIM (and hence directly into
XNOS). The first approach potentially allows the network
user to see the network as an extension of the host and to
use the same command language used by that host compu~er.
Adoption of the second approach seems more natural from an NOS viewpoint since it permits equal treatment of all
hosts. Thus the user physically logs into the NIM, issues
commands to the NIM receives responses from the NIM
and, in general has the NIM acting as a mediator between
the user issuing the requests and the systems satisfying
them. This approach also simplifies support of utility functions.
Utility support
Effective support of network users is facilitated through
the existence of certain support capabilities, e.g., editors,
that function in an identical manner regardless of the host
to which one is attached. XNOS supports this requirement
by providing such utility functions on the NIM. Invoking
these functions requires that any required input data or files
also be located on the NIM. This is accomplished through
using the mechanisms in sections three and four .
NIM computational requirements and costs
The cost of providing NIMs is dependent upon their computational requirements and the number provided. Such
From the collection of the Computer History Museum (www.computerhistory.org)
776
National Computer Conference, 1978
costs must be carefully considered since the canonical problem in providing any type of frontend support to a host
computer is the tendency for such support to require another
'host' of size comparable to that being supported. We feel
that this is not a problem of XNOS since the only functions
provided by the NIM are those supporting user-system and
system-system interfacing tog~ther with utilities.
Computational requirements
The computational requirements for supporting user-system interfacing can be divided into: (i) support of the common command language for file manipulation and the network job execution command, and (ii)support of NIM
independent interactions. Typically, for an individual user,
the average time between issuing commands in the first
category would be on the order of minutes. The second
category of interaction occurs when no intervention by the
NIM is required, e.g., the user is interacting with a program,
and the only computational support is that of forwarding
commands or responses. We assume that the overhead in
handling such commands is minimal.
The discussion in section four shows that the computational requirements for supporting system-system interfacing are those required to provide a network wide Interprocess Communication (IPC) mechanism and those required
to support translation and transformation of records generated by remote record accesses.
IPC is used to support both user-system and system-system interfacing. As discussed above, the former is invoked
relatively infrequently. We conjecture that the mean time
between occurrences of remote record accesses by an individual program will also be on the order of minutes due to
the subnetwork delays which occur in accessing remote
hosts. Moreover, computational support of the translation
and transformation requirement generated by a remote record access is relatively minor as follows from the discussion
in section four. (These estimates are only intended to indicate that NIM computational requirements are likely to
prove acceptable. Their verification requires measurements
which can only be performed after a significant level of user
utilization of XN OS capabilities.)
Utility support, particularly editing, can require a significant fraction of system resources. However, such support
offloads the host of a function which it could provide (for
interactive systems). Since this is done, in part, as a convenience for the host, the requirement for supporting utility
functions should not be directly counted against NIM computational requirements.
Cost considerations
The cost of providing NIMs is dependent upon the number
supported and the size of each. Assuming that NIMs are
implemented as hosts on the communications subnetwork,
the minimum number of NIMs is one. A likely upper bound
is one for each host. In an operational version of XNOS,
the actual number used will probably be heavily influenced
by a combination of performance considerations and the
opportunity which NIMs afford for offloading certain utility
functions (such as editing) from the hosts. A reasonable
initial estimate for an operational environment would be one
NIM per operating system class.
Utilization of a NIM promises to become increasingly cost
effective if declining hardware costs are balanced against
increasing software implementation costs. Even now, a relatively powerful NIM can be procured for the equivalent of
the burdened cost of supporting one professional programmer. Moreover, since this approach minimizes reimplementation of functionally similar modules and facilitates modification, one must also balance the one time cost against the
continuing programmer costs.
Utilization of a NIM also permits offloading certain terminal support functions from the mainframe. As a result,
system efficiency is potentially improved and systems which
are ill suited to interactive utilization are made more usable
in a networking environment. Of course, the relation between the host and the NIM is an important factor in any
final decision.
THE USER-SYSTEM INTERFACE
A Network Operating System should present a standardized view of network resources to its users and should provide ease of access to those resources. This section describes an implementation approach for a user-system
interface that provides these functions for the XNOS.
Implementation requirements
The network user should be able to view network resources in the same manner that a user would view an
individual system. A user knows of files in his workspace,
but generally is not concerned with the complexities of the
physical device upon which they are located. Likewise, the
network user should be able to know there are files in his
(network) workspace which exist on the available systems
of the network, but should be insulated from the intricac~es
of the physical systems upon which the files reside. In addition, since the network user would like to view the network as an entity, a common command language is desirable
to support communication both with individual hosts and
across hosts.
These capabilities are provided within XNOS by a Networkwide Directory System (NWDS) that describes the
user, the user's files and the available systems of the network. The NWDS also provides a common command language facility for manipUlating known files 'and programs.
The Networkwide Directory System (NWDS)
The NWDS consists of (i) a data base, the Network Wide
Directory (NWD), that describes the files belonging to each
From the collection of the Computer History Museum (www.computerhistory.org)
Network Operating Systems
user, the hosts on the network, and the types of interactions
allowed among those entities; (ii) the software support required to access the NWD data base; and (iii) the access
control mechanisms that insure system integrity and data
security.
New users to the network are queried by the NWDS
before entries are made into the NWD data base. These
entries identify the user and the systems to be accessed.
The user's own network directory is then initialized and all
connections to hosts are made on behalf of the user by the
NWDS. Thus, the user sees the network as a large relatively
integrated system composed of the resources available to
the user on each of the accessed hosts.
From the user's viewpoint, files have no rigid naming
conventions. To accommodate individual system constraints, the NWDS maps these user file names into unique
host file names conforming to the requirements of the host
on which the file resides. Manipulation of these files is
preformed by the NWDS for the user in accordance with
user commands.
In addition to providing a common command language for
the user, the NWDS contains logical record descriptions and
host representation tables to support preservation of meaning in transmitting records between heterogeneous hosts.
This supports run time access by a program to records
contained in remote files as discussed in the following section.
777
TABLE I-The Common Command Language
File Handling Commands
APPEND
FILE t FILE2
COMPARE
FILEt FILE2
COpy
FILEt FILE2
CREATE
FILE
DELETE
FILE t
ERASE
LIST
RENAME
FILEt FILE2
TYPE
FILE
UNDELETE
FILE
File migration Commands
RETRIEVE
FILE HOST
TRANSFER
FILE HOST
it is to be executed, input data files and output data files.
Prior to initiation of the job step all input files are checked
to ensure that they are. resident at the site where the program
is to be executed. If not, appropriate transfer operations are
begun and step execution is deferred pending completion of
these transfers. The syntax for a job step is:
RUN PROG@HOSTA
IN 1= INPUT 1,IN2= INPUT2, ...
OUTl=OUTPUTl@HOSTl,OUT2=OUTPUT2@HOST2..
where
User commands
The NWDS provides a common command language for
file manipulation and a command for executing network
jobs. This section describes these commands and presents
an example of Network Job Execution.
Common command language for file manipulation
XNOS file manipulation capabilities provide a common
command structure for manipulating files residing on an
individual system and for transferring files among systems.
The chosen set of commands was developed by surveying
file manipulation commands available on the systems currently supported by XNOS.
Determination of the precise set of commands to be supported requires some care since support of a 'network' viewpoint of host resources is inconsistent with requiring detailed
local host knowledge of how files are actually mapped to
devices. As a result, only commands dealing with files as
logical entities were selected for implementation as listed in
Table I. Note that not all of the systems provided all of
these commands. Thus, the NWDS effectively extends system capabilities.
Network job execution
A network job consists of a collection of network job
steps. Each job step specifies a program, the host on which
PROG is the program to be executed
HOSTA is the execution site
INn are the logical names for input data
INPUTn are the names for the input data files
OUTn are the logical names for output data
OUTPUTn are the names for the output data files
HOSTn are the final locations for the output data
A network job and its job steps are defined by an interactive program used in conjunction with the NWDS and the
commands described above. The program queries the network user to gather all the information needed to specify a
network job. For each job step in the network job, the user
enters the program name, execution site, and for each input
or output file, the logical name (name expected by the program) and the actual name (name in the user's directory).
The program builds a macro that invokes the system interactions necessary to perform the job step. The resulting
command, called RUN, is issued like any other command
and the network job is executed. Figure 3 indicates a sample
session defining a network job.
Access controls
Acceptance of a Network Operating System requires access controls to limit the access of the user to programs and
files and to limit the access of a program. User level access
controls are provided through a profile capability which
contains a complete description of the network user, the
From the collection of the Computer History Museum (www.computerhistory.org)
778
National Computer Conference, 1978
The user wishes to execute the program TEST on the NBS PDP-tO
(TEST@NBS10). There are three input fIles, FILE1, FILE2 and FILE3
which are to be given the logical names INt, IN2 and IN3 respectively. The
program produces three output fIles: OUTl, OUT2 and OUT3. They are to
be renamed and moved to other sites as follows: DATAl goes to NBSUNIX,
DATA2 goes to BBN and DATA3 will remain at the NBS10. There will be
only one Network Job step in this job. A carriage return indicates no
response.
The following dialogue will take place between the user and the XNOS:
Enter Program Specifications: TEST@NBS10
Remote file access? (y or n) n
Logical Name for Input File 1: INI
Actual Name for Input File 1: FILEt
Logical Name for Input File 2: IN2
Actual Name for Input File 2: FILE2
Logical Name for Input File 3: IN3
Actual Name for Input File 3: FILE3
Logical Name for Input File 4:
Logical Name for Output File 1: OUTl
Actual Name for Output File 1: DATAl
HOST l=NBSUNIX
Logical Name for Output File 2: OUT2
Actual Name for Output File 2: DATA2
HOST 2-BBN
Logical Name for Output File 3: OUT3
Actual Name for Output File 3: DATA3
HOST 3=
Logical Name for Output File 4:
Figure 3-Sample Definition of a Network Job
syst~ms he is permitted to access and the types of interactions allowed.
Program access controls are supported in two ways: (i)
run time checking of individual data items to ensure that the
program has appropriate authorization, and (ii) execution of
the program in its own run time directory to limit references
by the program in a manner commensurate with the information provided by the user in issuing the job step execution
command.
.
In addition to these formal access control mechanisms
some degree of additional protection is provided by having
file names in the directories on individual hosts (Local Host
Directories) which differ from the names by which the files
are known to the user. Although the individual user will be
permitted to determine host file names corresponding to
those files in his directory under certain conditions, such
information is not available for files belonging to other users.
Support of such access controls requires that the NOS be
the "owner" of all files resdient on an individual system.
However, to facilitate interactions by a user wishing to directly manipulate files, temporary directories can be set up
which contain those files designated by the user and which
support direct access by the user rather than access mediated by XNOS.
implementation support
The common command language described above was
implemented using the capabilities provided by the Network
Access Machine (NAM)lO,l1 developed at NBS. The NAM
is implemented on a PDP-11145 minicomputer running the
UNIX operating system and provides directives which permit a user to interact with a remote system on a network.
Sequences of these directives stored in files called macro
files have been written that will generate the necessary machine-dependent dialog to perform file manipulation functions required for each of the host systems. Thus, execution
of each command in the language is actually a call to a
macro file that the NAM expands and executes.
The responses that the remote system generates are, in
tum, analyzed by the NAM. By permitting the mapping of
the varied responses from the remote systems into standardized messages for the network user to see, the NAM
facilitated the commonality of the common command language. The user can enter a standard set of commands and
see a standard set of responses, and need not become familiar with the responses of each system accessed. (Note
that this approach supports standardized error messages
across all anticipated error responses; unanticipated responses are transmitted directly to the user.)
SYSTEM-SYSTEM INTERFACING
Successful system-system interfacing within a Network
Operating System environment requires two primary functions: (1) a means for transmitting data between systems,
and (2) a mechanism for accessing and preserving the meaning of structured data as it is transmitted across heterogeneous systems. The first feature is provided by Interprocess
Communication (lPC), and the second by a Remote Record
Access (RRA) capability.
In this section we shall discuss the problems of systemsystem interfacing in more detail and identify required functional capabilities and support mechanisms, while considering some of the alternatives encountered during the implementation of XNOS. A more detailed treatment of the
problem may be found in Reference 12.
interprocess communication
Interprocess Communication (I PC) provides the basic
mechanism for initiating and controlling the flow of data
between cooperating processes. Since processes are the only
active entities within a computer system, IPC is a basic
building block for supporting communication between computers.
The National Software Works 6 has implemented a relatively sophisticated IPC mechanism termed MSG13 which
permits the SENDing process to continue execution independently of the activities of the RECEIVEing process,
whether or not the message was actually RECEIVEd. Providing such a capability requires fairly complex software
support.
The XNOS IPC mechanism might be regarded as a minimum level IPC approach requiring very little host software
to. support its functioning. This is accomplished using a
CALL/RETURN based mechanism· that functions analogously to subroutine CALLs in that the WAIT state is entered upon issuance of the CALL. The simplicity of imple-
From the collection of the Computer History Museum (www.computerhistory.org)
Network Operating Systems
menting this approach stems from using constructs available
in the major existing programming languages and requires
minimal host support.
The simplicity of XNOS IPC support derives from the
fact that, if we assume interactive jobs, IPC messages can
be transmitted over the controlling teletype channel, intercepted at the NIM and diverted from the user's terminal to
the appropriate destination where the reverse process occurs. Although the sophistication of this approach is limited
and the bandwidth between communicating processes is
constrained, the simplicity of its support coupled with the
negligible startup costs for any host supporting interactive
processing have led to its adoption.
Remote record access
Remote record access permits a process executing in one
computer to access data records located in another computer
at run time. This requires transmitting data between possibly
dissimilar hosts which is complicated by both physical incompatibilities between systems and organizational incompabitilities between the data as required/maintained by the
systems.
Physical incompatibilities include differences in word
length, character packing, sign bit location, and data encoding (e.g., character sets or use of two's vs. one's complement representation of numeric data). A translator is needed
to convert data from the internal format of one host to that
of another. Organizational incompatibilities between data
bases, on the other hand, result in the need for a transformer
to modify the format of files and data items (e.g., reorder
and concatenate the data fields of a record before transmitting that data to the requesting host).
The provision of a remote record access capability, then,
requires: (1) a mechanism for selecting a record from the
file/data base containing it, (2) a record translator to preserve
meaning in transmitting the record between dissimilar hosts,
and (3) a record transformer to permit the alternation of
record structures. Supporting these functions mandates a
means for describing the physical and organizational characteristics of the hosts. (It should be noted that the same
functions could be performed iteratively for all records,
when an entire file is migrated between dissimilar hoststhus resulting in a file transfer protocol (FTP) for structured
files.)
These functional components will now be discussed in
greater detail and, to better illustrate the associated information requirements, an example will be described in which
a process on one host requests a data record from a dissimilar host on the network. As illustrated in Figuare 4, the
host bearing the file containing the remote record is called
the Data Host (Dhost) and that bearing the accessing program is the Process Host (Phost).
Record selection
The precise mechanism which supports record selection
is dependent upon capabilities existing at the host computer
779
including those provided by a data base management system, if any. The following discussion assumes the existence
of a suitable mechanism for retrieving a record based on
utilization of a unique key, if random access techniques are
being employed or, alternatively, the keyword 'next' if sequential access is being used. Given this assumption, we
now describe the basic communication support.
Assume that the Phost issues a request for a record located on the Dhost (path a[ 1] in Figure 4). This request,
when received by the NIM, is forwarded to the Dhost (path
a[2], Figure 4), accompanied by any additional descriptive
information needed by the selector. Such information would
include the host specific file name, as determined by the
Network Wide Directory System.
Upon receipt of the request by the Dhost, a record selector is responsible for retrieving the record and transmitting
it to the record translator (path b[ 1], Figure 4). Figure 5
shows such a record, in the format maintained by the Dhost.
(The field names are included here for clarity, but would
usually not be contained within the actual record.) Although
the record in Figure 5 shows all data fields in character
notation, it should be understood that these data items are
actually in the machine representation of the appropriate
data type (e.g., integer, real, logical, character, binary).
Record translation
Record translation preserves the logical record structure
and data element type (e.g., real, binary, logical, integer,
character) and, for arithmetic data elements, precision. Thus
the record translator must know the exact format of the
record to be translated down to the data item-a level of
detail analogous to that contained in a FORTRAN format
statement (e.g., 3I5,2X,5A5,F4.2). In addition, the internal
I
I
I
I
I
REMOTE RECORD ACCESS. I
SUPPORT
I
RECORD
SELECTOR
•
I
I
I
REQUESTING
PROCESS
-----~~~~~~~:~~~~---I
I
DATA
BASE
a[l)
a[2)
b [1)
b[2)
Phost
I
I
request for data
request for data
retr ieved record
retrieved record
from network-wide data base
with access parameters
in Dhost forTllat
in phost format
Figure 4-Remote record access. components
From the collection of the Computer History Museum (www.computerhistory.org)
780
National Computer Conference, 1978
1
2
3
4
5
12345678901234567890123456789012345678901234567890
ISSN
NAME
BIRTH
1
2
3
4
5
12345678901234567890123456789012345678901234567890
ALRGYTEST HT
1-------------------------------------------------1
OA00001000
333775555/CHARLES J SMITHSON/1026920/+000000001010
1333775555CHARLES J SMITHSON
0010000000000000000000001111/+00000001000100000000
1
WT SDISEASE1
10269200200F100030182
DATE
MEDICATION
DATE
MEDICATION
DISEASE3
DISEASE4
DISEASE
00000000000000000011/+182.88/+75/M/MALARIA/0601943
1-------------------------------------------------188075MMALARIA
0601943QUININE
GOUT
/QUININE/GOUT/0801965/CORTISONE/STREP/1103969/PENI
12
1-------------------------------------------------1
0801965CORTISONE
STREP
11039
CILLIN/ANGINA PECTORIS/0703972/DIGITALIS/REBECCA B
1
MEDICATION
ON/DECEASED/+10/+20/*T*/
1
MOTHER
DATE
DATE
MEDICATION
1-------------------------------------------------169PENICILLIN
ANGINA PECTORIS0703972DIGITALIS
FATHER
ADDRESS
1-------------------------------------------------1
FREDERIC SMITHSON
DECEASED
1
Figure 6-Data host record DDR[NNF]
ADDRESS
1-------------------------------------------------1
REBECCA B SMITHSON BOX 444, TAMPA FLA 00000
1
SMITHSON/BOX 444, TAMPA FLA OOOOO/FREDERIC SMITHS
YCYMDFILLER
1-----------------------------------I
1020T
Figure 5-Data host record-DDR[D]*
- *The characters in the allergy-related fields are in hexadecimal representation. The upper digit represents the first four bits of an eight bit binary field,
while the lower digit represents the remaining four bits of that field.
format of all data types must be known for each computer
that is supported on the network.
Placement of the record translator at the host requires its
coding for each separate host architecture and increases the
impact ofthenetwork on the host. For both ofthese reasons,
the record translator has been implemented on the NIM.
Although knowledge of the internal data representations of
N hosts are still required, only 2N, rather than N(N-l) translators must be implemented (one into and one out of each
host format). Since host dependencies are reflected only in·
the tables being used to drive the translation process, 2N
becomes 2. As the process of translating into and out of
host dependent representations are very similar, it was initially conjectured that 2 would become 1. However, there
prove to be enough subtle differences to justify two separate
programs rather than consolidating them into one.
Given that translation is to be supported on the NIM, the
remaining issue is whether to map directly from source to
destination form or to proceed via a common intermediate
form. The substantial simplification in implementation afforded by the intermediate Network Normal Form (NNF)
resulted in the selection of this approach. Figure 6 shows
the Dhost record as it would appear after translation to NNF
format. (Notice that all data types are now in a character
representation.) Once the record has been transformed to
meet the needs of the requesting process (Figure 7), it is
again translated-this time into the bit representation required by the Phost, a process that is essentially the inverse
of the original, table-driven translation from Dhost format
to NNF. Figure 8 shows the record in the Phost format. The
resulting record is then transmitted to the Phost (path b[2],
Figure 4) and RETURNed to the requesting process.
The communications subnet often supports character
translation. Therefore it would at first seem reasonable to
have the translation of character data handled by the subnet,
thus reducing the translation requirements to a minimum.
However, as it is unreasonable to assume the exclusive use
of character-oriented data, such subnetwork capabilities
cannot be relied upon for the general case. It may be desirable, however, to add to XNOS a capability to default to
such subnetwork handling of data when dealing with character-only data.
Record transformation
Record transformation supports modification of both the
logical structure of the record and individual data elements.
The record transformation function matches the information
transmitted to the needs of the receiver or to ensure proper
protection of sensitive information (e.g., matching the data
to the access rights of the receiver by omitting sensitive
information from the record before transmitting it on to the
requesting process). Such transformation affects the logical
structure of the record through one of three basic transformation types: logical, arithmetic, or string.
Logical transformations such· as AND or OR generate
Boolean binary strings resulting from the bit by bit ANDing
and ORing of two successive strings. Arithmetic transformations such as: +, - ,/, x act as would be expected. String
transformations can be quite complex as evidenced by the
1
2
3
4
5
12345678901234567890123456789012345678901234567890
333775555/CHARLES J SMITHSON/M/+50/1026920/+000000
0000000000000000000000000000000011/+00000001101100
10000000000000000000001111/+165/+6.1/STREP/1103969
/PENICILLIN/ANGINA PECTORIS/0703972/DIGITALIS/*T*/
Figure 7-Phost data record-PDR[PNNF]
From the collection of the Computer History Museum (www.computerhistory.org)
Network Operating Systems
1
2
345
12345678901234567890123456789012345678901234567890
--------------------------------------------------
ISSN
NAME
SYGBIRTH
TALRGSALRGW
1--------------------------------------------I
000000;000I 333775555CHARLES J SMITHSON
IT HT DISEASE1
TREATMENT
M301026920000031200F1
DATE
DISEASE2
1-------------------------------------------------165604STREP
PENICILLIN
1103969ANGINA P
I
TREATMENT
DATE
DFILLER
1------------------------------------I ECTORISDIGITALIS
0703972T
Figure 8-Phost data record-PDR[P]
capabilities of string manipulation languages. Initially, a concatenation capability seems desirable. Among the additional
transformations that may be needed are algorithms for the
compression and/or decompression of textual information. 14
As with the record translator, support of record transformation is implemented more efficiently on the NIM. This
follows through having the transformer operate on the record in NNF format.
In XNOS a Transformation Description Table is used to
provide the information that the translator needs to establish
relationships between data items in the Phost and Dhost
records. In this table each item in the Phost data record
~PDR[i]) is expressed as a function of the appropriate item(s)
In the Dhost data record (DDR[j]). For example, the concatenation of two character fields from the Dhost record
might be expressed as follows:
PDR[j]=DDR[i] I DDR[k]
A record that could be the result of such a series of operations is shown in Figure 7.
Supporting transformation of numeric data types (i.e.,
integer, real) requires care since precision must be considered. Our approach uses a character based intermediate
representation coupled with an arbitrary precision arithmetic
package. The character representation directly accommodates varying precision while the arbitrary precision package
supports transformations of numeric types. Of course, the
precision of the result will never be better than the lesser of
that of the source and destination. However, this approach
does ensure that precision is not lost during the translation!
transformation process.
Secure environments
The enhanced access to system resources provided by a
Network Operating System requires a suitable collection of
access control mechanisms. Not only must a user's identity
be verified at login time, but access on his behalf to NOS
maintained accounts on remote systems and to files, records, and fields within those systems must also be controlled.
As part of a continuation of the joint NBS/RADC effort
781
which resulted in the work described in this paper, efforts
are currently under way to structure NOS access control
requirements and alternatives. This study will result in the
incorporation of prototype access control components into
XNOS. Since the password has been found to be a relatively
inexpensive, but highly effective mechanism for identify verification and access control when used properly 15.16 it will
no doubt be an integral part of the effort to enhance XNOS
security.
Once the decision has been made to control access to
network resources, the ability to protect data during transmission becomes a further requirement. Although it is generally accepted that an algorithm such as the Data Encryption Standard 17 would be suitable for such purposes, an
appropriate encryption key management mechanism would
have to be determined for the NOS environment. These and
other network security related issues will be addressed in
subsequent studies and reports.
CONCLUDING REMARKS
In this paper we have provided a perspective on the issues
and implementation constraints implicit in providing a gen..,
eral purpose Network Operating System for a heterogeneous
collection of host computers. One implementation of an
NOS has been described based on utilization of Network
Interface Machines to offload NOS support from the host
and to facilitate centralized design, implementation and support.
Based upon our experience in the implementation of
XNOS we are led to conclude that NOSs are feasible. However, in view of the complexity of the possible error messages, the activities of the general purpose user of such a
capability will probably be constrained to minimize unexpected error responses. Thus, we would anticipate that general purpose computing might be <;onfined to one or a few
machines while other systems would be accessed to use
unique resources known to be fairly well debugged.
Finally, it should be noted that Network Operating Systems only solve part of the problem of simplifying user
access to systems-that of providing a uniform viewpoint
across systems. The remaining part is concerned with simplifying system access given such a capability and constitutes the area of network access support. In Reference 18
it is shown that such support can be structured into four
major components: user and service profiles to simplify and
automate user interaction with services; soft user interfaces
to eliminate the need for user concern with the precise
syntactic structure of commands; expert assistance to reduce the need for entering repetitive information; and dynamic tutorial assistance to provide specific, pinpointed
problem solving information online.
REFERENCES
1. Kimbleton, S. R. and R. L. Mandell, "A Perspective on Network Operating Systems," Proc. 1976 National Computer Conference, AFIPS
Press, Montvale, New Jersey, Vol. 36, 1976, pp. 551-559.
From the collection of the Computer History Museum (www.computerhistory.org)
782
National Computer Conference, 1978
2. Forsdick, H. C., R E. Schantz, and R H. Thomas, "Operating Systems
for Computer Networks," BBN Report No. 3614, Bolt Beranek and
Newman, Cambridge, Mass., 1977.
3. Kimbleton, S. R, "Network Operating Systems: Issues, An Approach,
and Some Conclusions," in preparation.
4. Thomas, R H., "On the "Design of a Resource Sharing Executive for
the ARPANET," Proc. AFIPS 1972 National Compute, Conference,
Vol. 42, AFIPS Press, Montvale, New Jersey, 1973, pp. 155-164.
5. Thomas, R. H., "JSYS Traps-A Tenex Mechanism f~r Encapsulation
of User Processes," Proc. 1975 National Computer Conference, AFlPS
Press, Montvale, New Jersey, 1975, pp. 351-360.
6. "National Software Works," Semi-Annual Technical Report, Massachusetts Computer Associates, Inc., Wakefield, Massachusetts, 1976.
7. Moms, P. and D. Sagalowicz, "Managing Network Access to a Distributed Database," Proc. Second Berkeley Workshop on Distributed Data
Management and Computer Networks, May 1977, Berkeley, California,
pp.58-67.
8. Hendrix, G. G., "Lifer: A Natural Language Interface Facility," Proc.
Second Berkeley Workshop on Distributed Data Management and Computer Networks, 1977, Berkeley, California, pp. 196-201.
9. Padlipsky, Michael, "A Proposed Protocol for Connecting Host Computers to ARPA-like Networks via Front-end Processors," Network
Working Group, RFCNo. 672, NIC 31117, TIP, Oct. 1974.
10.
11.
12.
13.
14.
15.
16.
17.
18.
Rosenthal, Robert, A Review of Network Access Techniques with a
Case Study: The Network Access Machine, NBS Technical Note 917,
July 1976, 36 p.
Rosenthal, Robert, and Lucas, Bruce D., The Design and Implementation
of the National Bureau of Standards' Network Access Machine (NAM),
NBS Special Publication Series 500, in preparation.
Wood, H. M. and S. R Kimbleton, "Remote Record Access: Requirements, Implementation, and Analysis," in preparation.
Rivas, L. P., H. C. Ludlam, and R. T. Braden, An ImpLementation of
the MSG Interprocess Communication Protocol, Campus Computing
Network, ARPA Order No. 2543-3, May 1977, 128 p.
Schneider, G. M. and E. J. Desautels, "Creation of a File Translation
Language for Networks," Information Systems, 1975, Vol. 1, pp. 23-31.
Wood, The Use of Passwords for Controlled Access to Computer Resources, National Bureau of Standards, Special Publication 500-9, May
1977, 79 refs.
Wood, Helen M., "The Use of Passwords for Controlling Access to
Remote Computer Systems and Services," Proceedings of the National
Computer Conference, AFIPS Press, 1977, pp. 27-33, 43 refs.
National Bureau of Standards, Data Encryption Standard, FIPS PUB 46,
January 1977.
Watkins, Shirley Ward, -and Stephen R Kimbleton, "Network Access
Technology: A Perspective," in preparation.
From the collection of the Computer History Museum (www.computerhistory.org)
I