\VJfS3.

(NASA-CR-177853) STATE OF THE ART SURVEY OF N86-21352

NETWORK OPERATING SYSTEMS DEVELOPMENT

{Computer Technology Associates, Inc.)

224 p HC AIO/BF A01 CSCL 20F Dnclas

G3/74 155U5

COMPUTER TECHNOLOGY ASSOCIATES, INC.

Denver • Washington, D.C: • Colorado Springs • Albuquerque • San Jose
STATE OF THE ART SURVEY

OF

NETWORK OPERATING SYSTEMS

DEVELOPMENT

Performed for

NASA Goddard Space Flight Center

Code 700

Greenbelt, MD

CONTRACT NO.: NAS5-28583

By

Computer Technology Associates

10227 Wincopin Circle, Suite 208

Columbia, Maryland 21044

June 7, 1985
TABLE OF CONTENTS

1.0 INTRODUCTION 1-1

2.0 METHODOLOGY 2-1

3.0 OVERVIEW 3-1

3 .1 DESCRIPTION 3-1

3.2 RELATIONSHIP WITH OPEN SYSTEM 3-6

INTERCONNECTION REFERENCE MODEL

3 .3 ASSUMPTIONS 3-7

4.0 NOS FUNCTIONAL CHARACTERISTICS... 4-1

4 .1 USER COMMUNICATION 4-1

4.2 JOB MIGRATION 4-5

4 .3 DATA MIGRATION 4-11

.4.4 NETWORK CONTROL 4-16

4 .5 COMMON 4-20

5.0 SURVEY RESULTS 5-1

5 .1 KEY TRENDS AND OBSERVATIONS 5-1

5.2 INDIVIDUAL VENDOR/SOURCE SUMMARIES 5-3

5.3 RESEARCH PROJECTS 5-64

5.4 RESEARCH AND DEVELOPMENT EFFORTS 5-93

6.0 EVALUATION RELATIVE TO NASA 6-1

ENVIRONMENT

6 .1 EVALUATION OF FEATURES 6-2

6.2 DEFICIENCIES AND ISSUES 6-6

6.3 PRIORITIZATION OF FEATURES 6-19
1.0 INTRODUCTION

In this report Computer Technology Associates (CTA) presents

the results of its state-of-the-Art Survey of Network Operating

Systems performed for Goddard Space Flight Center. In this

section of the report CTA states the objective of the study,

presents the major results of the study, and describes the

organization of the report. The objective of this report is to

determine the current state-of-the-art in Network Operating

System (NOS) development. CTA has focused this study on Local

Area Networks (LAN's) in order to relate the NOS developments to

LAN's aboard the U.S. Space Station . An on-board data system

will coordinate the activities of several space station

subsystems and many users while providing access to commonly used

data. It is envisioned that the NOS will be key to integrating

these activities as well as handling requests for ancillary data

for experiments and subsystem monitoring.

CTA has drawn the following major conclusions as a result of

this study:

o Developers are primarily working in either UNIX or the

IBM PC DOS environments. Few vendors are providing

interoperability between the UNIX and PC DOS

environments. Recent announcements by commercial vendors

indicate that products with UNIX-PC DOS file service will

soon be available.

o Services offered most commonly by vendors are file

service and print services; also many vendors provide

messaging (electronic mail) and remote procedure call

services.

o Major deficiencies are the lack of data representation

service and network control service for handling failure

conditions.

o Interprocess communications services, in many cases,

provide inadequate performance and are not provided for

PC based systems. A number of research activities have

1-1
demonstrated efficient interprocess communications,

o Portability of the NOS is a major problem because of

- no standard local OS

integration of NOS and Local OS

o UNIX is a potential solution to the portability issue,

but it has not been standardized and has serious

deficiencies in interprocess communication and real time

I/O.

o Open Systems Interconnection (OSI) reference model and

protocol standards are not being implemented because

vendors have focused on maximizing performance using

simpler protocols with fewer layers in LAN environment.

o As standards evolve and there is a greater requirement

for internetworking the use of these standards will

become necessary and more common.

To address the state-of-the-art of NOS development, CTA has

partitioned this report into five sections and three appendices.

In Section 2, CTA presents its methodology for acquiring,

organizing/ evaluating, and documenting information on candidate

commercial and research NOS packages. CTA has identified

literature sources utilized for the review and evaluation

process, the organization of all material by means of

computerized data bases, and the use of a template to provide

concise, individual descriptions of commercial and research

NOS's.

In Section 3, CTA presents an overview of Network Operating

Systems to establish a common terminology and technology areas to

be addressed in the survey. The contents of this section

include:

o description of a network operating system,

o relationship to a distributed operating system,

o relationship to the ISO Open Systems Interconnection

Reference Model,

1-2
o assumptions stating specifi c types of products or

systems, though related to network operating systems, do

not qualify as networ k operating systems and are not

addressed in detail in the survey.

Wor k relating to networ k operating systems is being

performed by two research communities: computer networks and

distributed processing (and database). The forme r group deals

primarily with loosely coupled systems and builds the network

operating system upon the local host operating system. This

group has developed and sponsored the OSI technology. The latter

group deals with more tightly coupled systems and the networking

--•" - • •>•

features are closely integrated with the local operating system.

Although the work of the computer network research community

is closer to the proposed thrust of this study, CTA has attempted

to cover both areas. This is necessary because the separation of

the two groups is ambiguous. CTA believes that ultimately the

work of the two groups will converge such that the communications

will simply appear as another peripheral to the local operating

system.

The results of this report will be input to a subsequent

effort to develop a prototype Network Operating System. Thus, to

expedite this development, CTA has focused both on development of

commercial products and research and development efforts. In

particular, the prototype NOS could be more cost effectively

developed building upon an existing product rather than developed

completely anew.

In Section 4 a set of NOS functional characteristics is

presented in terms of user communication, data migration, job

migration, network control, and common functional categories.

1-3
The common category includes those functions which are common to

any two or more of the other categories.

In Section 5, CTA presents the results of its NOS survey,

which considered products (current or future) as well as research

and prototyping efforts. First the key trends and observations

are presented. Then a brief narrative is provided highlighting

the important characteristics of Network Operating Systems.

Narratives are provided only for selected NOS based on the

following criteria:

o relative importance in field based on number of

installations,

o introduction of new or advanced technology,

o completeness of functional capability.

In the last section (Section 6), CTA presents an evaluation

of the NOS products which are relevant in the space station

environment and its activities. Features provided as well as

deficiencies are described and presented. Then the required

features are prioritized to facilitate development of an

implementation plan.

CTA has also included three major appendices to this report.

They are:

o a set of product templates,

o a bibliography of relevant literature,

o a bibliography of relevant standards, and

o a bibliography of research and development efforts.

1-4
2.0 METHODOLOGY

\ In this section CTA presents its methodology for acquiring,

organizing, evaluating, and documenting information for candidate

Network Operating System. In the survey, commercial and research

products currently available or under development were included.

Tabulated results differentiate between those products which are

currently or soon-to-be commercially available versus research

projects in the academic or government environments.

CTA's methodology to survey the available NOS products and

projects involved the:

o identification and acquisition of relevant information

sources,

o review and assimilation of relevant articles, product

announcements, etc., from these sources,

o create computerized data bases with product templates to

concisely describe it,

o generation of computerized data bases to organize the

information gathered during the survey, and

o review and analysis of vendor or developer provided

information

o comparison of the features provided versus Space Station

requirements

The initial step in the survey was to define a Network

Operating System and establish to relevant products and systems

to be surveyed. In particular there are many products, and

systems, though related to the NOS technology, do not qualify as

a NOS. These were identified, but not studied in detail.

In defining a NOS, CTA distinguished between network and

distributed operating systems. These concepts are very closely

related with certain systems and products categorized in a gray

area between a network and distributed operating system. Thus

2-1
both network and distributed operating systems were considered.

The major sources of information for identifying candidate

network operating systems were:

o professional journals published by the IEEE and ACM,

o Trade journals produced for the engineering, computer,

and telecommunication industry (e.g., "Computer Design,"

"Systems and Software, " "Mini-Micr o Systems, " and

"Telecommunications Products Plus Technology"),

o PC-oriented monthly magazines (e.g., "PC-World", "PC"),

o Relevant product news releases,

o NASA specific information; in particular work done by Dr.

Edwin Foudriat at NASA Langley.

In the first area the recent papers by J. A. Stankovic (and

his colleagues in the latter paper)

"A Perspective on Distributed Computer Systems",

IEEE Transactions on Computers, December 1984

"A Review of Current Research and Critical Issues

in Distributed System Software", IEEE Distributed

Processing Technical Committee Newsletter, March

1985

was especially helpfu l in identifyin g candidate systems,

especially in the research environment, and assessing the stateof-the-art for key issues.

Also the January 1985 Workshop on Operating Systems in

Computer Systems in Computer Networks hold in Ruschlikon,

Switzerland provided a very recent summary of current work in

this area. This workshop was organized by Liba Svobodova and

session summaries are presented in the ACM publication:

Operating Systems Review, April 1985

In addition, the very recent conference proceedings; 5th

International Conference on Distributed Computing Systems was

2-2
briefly reviewed.

The trade publications were useful for assessing the

capabilities of current and futur e vendor products. The NASA

specific information was useful for relating the NOS technology

to space applications.

The assimilation and organization of the NOS information was

facilitated by the generation of a NOS template consisting of the

key characteristics of a NOS. This forma t of this template is

illustrated in Figure 2.1. CTA filled in the relevant attributes

in the template for each system or product considered, although

not all informatio n was available. The resulting set of

templates were physically created and stored on an IBM Personal

Computer using Lotus 123TM (TM of Lotus Development Corporation).

For research projects, a less detailed template was generated.

The information included in this template consists of project

name, organization, contact, and key words.

CTA then synthesized the functional characteristics for a

Network Operating System based on its assessment of:

o features implemented in vendor products or proposed for

future vendor products,

o features implemented in university, government, or

industrial research projects,

o features defined in current or proposed standards.

This set of functional characteristics is presented in Section 4.

The analysis and review activities performed by CTA involved

identification of technology trends, and comparison of the stateof-the-art technology versus space station requirements. The

capabilities of the candidate systems have been reviewed relative

to:

2-3
o completeness of functionality,

o adherence to OSI protocols,

o portability and performance.

The space station requirements were derived from the requirements

analysis performed by CTA for its Fiber Optic Demonstration

System High Level protocol study.

Having codified requirements and assessed the state-of-theart in NOS development, CTA then prioritized NOS features for

implementation. This prioritization was based on relative

importance of the feature, implementation complexity, and

technical maturity.

2-4
ITEM 1 ITEM DESCRIPTION

1 Name/Availability of

NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s))/Contact:

5 Documentation Availability/Source:

6 NOS Hardware Implementation:

- Network:

- Host Computer(s)

7 Host Operating System

Name(s):

8 Implementation Language:

9 Maintenance Support:

10 ISO Model Implementation:

11 List of Services for

Each ISO Layer:

12 Major 0/S Functions

Implemented:

13 0/S Modification(s):

14 Price:

15 User Added Applications

S/W:

Comments:

FIGURE 2.1

Product Template Format

2-5
3.0 OVERVIEW

3.1 Description

The initial effort was to define a Network Operating System

and to establish its relationship with other concepts in the

distributed computing environment such as distributed operating

systems and Open Systems Interconnection. A NOS can be viewed as

a collection of Application Servers and communication software

needed to provide User-to-Server, User-to-user, Server-to-Server

communication. A server is a computing process which performs a

specific function at the request of a client, usually a userr

process. Servers may rely on specific hardware peripheral such

as disks, printers, and modems or a server may be strictly a

computational server or process, e.g., a user may send a command

to another node for remote execution of a program.

The resulting definition of a NOS is:

"A Network Operating System provides the capabilities of:

- Reading/Writing information on remote devices,

- Sending/Receiving informatio n to/from remot e

processes or users, and

Executing/Controlling jobs on remote devices

as if they were local."

The information exchanged may be textual or non-textual. Two

characteristics which are important in defining a network

operating system and distinguishing it from distributed operating

systems are the:

o interface between the network operating system and the

local operating system

o level of transparency provided to users of the network

operating systems.

3-1
These characteristics are described below:

Network Operating Systems employ the services of the local

host operating system to perform these functions, as illustrated

in Figure 3.1. The NOS environment is homogeneous when the local

operating system is the same at all sites. This facilitates

portability of the NOS. If the NOS and the local operating

system are integrated, then the resulting operating system is

referred to as a distributed operating system. The degree of

integration is subjective, and both network and distributed

operating systems are addressed in this survey.

In an ideal situation the NOS would reside between the local

operating system and the applications. The NOS would appear as

an application to the local operating system and as an operating

system to the application, with this implementation the NOS

could be easily ported to other hosts employing the same

operating system. The NOS would handle system calls by the

applications and determine if the system call must be satisfied

by local or remote operating systems. If the system is handled

locally, then it is passed to the local operating system. If the

system call is handled remotely, then it is passed through the

NOS to the Network I/O driver for delivery through the network to

the remote system. Note that the NOS may not handle all calls,

e.g., clock and memory management services may have only local

significance.

The local operating system may also be distributed itself

because the local host may be a multiprocessor device where the

processors are distributed over a device backplane bus. Such

3-2
distribution of a tightly coupled system is not considered in

this study.

The Network Operating System employs the services of the

local operating system for a wide number of services such as

interprocess communication (among processes in the local host),

memory management, clock, and file service. Although this

implementation facilitates portability, it introduces significant

performance problems. To achieve high performance, developers

integrate the NOS and local operating system reducing the

portability. The associated tradeoffs are discussed in Section 6.

One of the major goals of a Network Operating System is to

provide transparent operation to the user, which may be either a.

person or process. Network transparency can be achieved at four

levels which introduce corresponding level of system complexity:

o name transparency in which each object and resource has a

name independent of the site from which it was invoked as

part of a system command,

o location transparency in which the location of an object

or resource is not encoded in its name,

o semantic transparency in which the commands employed to

invoke NOS services are independent of the location at

which they are invoked,

o performance transparency in which the system response

time to a service request is independent of site at which

the service request is executed.

Name transparency is a necessity for both network and distributed

operating systems because without it there would be enormous

complexities in moving or distributing software. For example as

applications software is ported to new hosts any object or

resource names employed in the software would take on new meaning

when the software is executed on the new host.

3-3
APPLICATION

u>

I

NETWORK OPERATING SYSTEM

LOCAL

I/O DRIVER

LOCAL OPERATING SYSTEM KERNEL

NETWORK

I/O DRIVER

FIGURE 3.1: System Architecture
Complementary to naming transparency, location transparency

is a desirable feature, but probably not necessary for a NOS.

For example, it is not unreasonable to define a pathname for an

object such as a file in which the location of the object is

prepended. Resources could be similarly handled with pathnames.

However since resources are not frequently created or change

status, they could be given names without encoded locations.

Location transparency for a distributed operating system is a

much more important objective because local and remote resources

are much more integrated. For example in some systems, the user

is not aware of the locations of a resource or object when a

service request is made. The system is responsible for

determining where the resource or object request is located. If

there are multiple resources or objects capable of satisfying the

request, then the system must select (via some optimization

criteria) which one should provide the service.

In summary, for a network operating system, objects such as

files will have the location name prepended to the file name.

For resources this may also be acceptable, but it is not

especially complex to use names without the site name encoded.

Semantic transparency is a necessity for both a NOS and DOS.

Without such transparency, porting and maintaining software would

be extremely difficult. Furthermore , a common set of commands

will facilitate use of the system by users who utilize more than

one host.

Performance transparency is a desirable objective for both

a DOS and NOS, but clearly the performanc e of the computer

3-5
network linking the hosts will establish a bound on how well this

objective can be achieved. Wit h its tightly integrated

architecture, performance transparency is more critical for a

DOS. Howeve r with curren t technology advances providing

increases in processing speed and communications transmission

speed, this objective can be more nearly achieved with a NOS.

3.2 Relationship with the Open System Interconnection Reference

Model

The major standard relating to a Network Operating System is

the ISO Open System Interconnection (OSI) Reference Model, which

is an architectural model for communications between two open

systems. The OSI Reference Model defines the protocol functions

to be performed by seven protocol layers. In addition, ISO is

defining (and has defined) specific protocols for each of the

seven layers of the Reference Model.

These protocols define:

o peer to peer communication roles between corresponding

layers in communicating open systems,

o primitive interfaces between adjacent layers in the same

open system. For a layer protocol, the interface is

between layers N and N+l, as well as layers N and N-l.

For N equal 7, the N to N+l layer interface is the

interface to the user.

However, these protocols do not define how the protocol is to be

implemented in the local open system. For example, buffe r

management and interface to the operating system in the local

open system are not defined by these protocols.

An implementation of these protocols in actual hardware and

software is a network operating system. However, a network

operating system does not have to adhere to the Reference Model

3-6
or ISO OSI protocols.

There are fundamental misconceptions about the OSI model

regarding subsequent implementation of OSI protocols. The OSI

Reference Model defines an architecture and OSI protocols provide

the detailed interface specification between open systems.

Nothing is specified regarding the implementation of the

protocols in the local open system. For modularity, it would be

nice to implement these protocols as separate tasks. However,

this introduces substantial overhead with buffering and local

interprocess communication. OSI imposes no constraints on how

the protocols are implemented, hence the developer of the local

system could implement two or more layers in the same task to

achieve higher performance at the expense of modularity. As long

as the OSI protocol suite appears to the outside world as defined

in the specification, no interface problems occur.

3.3 Assumpt ions

There are a large number of vendors who have or claim to

have a network operating system or provide some features. In the

survey CTA has selected vendors based on:

o relative importance in the field based on a number of

installations,

o introduction of new or advanced services,

o completeness of functional capability.

In particular, vendors providing only a disk server as opposed to

a file server were excluded. A Disk Server only provides service

pertaining to:

o one or more disk sectors,

o entire volume.

3-7
However, a File Server allows users to share individual files

rather than just share disk volumes. This distinction has

significant implications for a NOS. A typical disk server

request will be a "Write Track X, Sector Y on disk volume Z."

The client side of the software controls the file structure and

directory information. Therefore, the disk server cannot control

or resolve conflicts between different users of a disk volume.

For example, two different clients may write the same sector and

thus leave the file or even the volume directory in an undefined

state. In some cases a NOS may provide synchronization tools

such as semaphores; however, use of these tools require s

development of NOS specific applications.

A typical File Server request is "Open/Close a file,"

"Read/Write next record," "Read/Write record number n" or "Update

record with key X." The file server controls the file structures

and the volume directory. Therefore, it knows what files are

open rather than which disk blocks are in use on a particular

volume. As such it can allow multiple clients to share a file

and synchronize their requests.

Appendix A, whic h lists the NOS produc t templates,

identifies products that provide a Disk Server, but these systems

have not been analyzed in detail.

3-8
4.0 NOS Functional Characteristics

In this section CTA synthesize s the functiona l

characteristics for a Network .Operating System based on its

assessment of:

o features implemented in vendor products or proposed for

future vendor products,

o features implemented in university, government, or

industrial research projects,

o features defined in current or proposed standards.

The purpose of this section is to define the functional

requirements for an ideal NOS. It is not expected that:

o any one vendor would provide all of these features,

o all of these feature s are required in the NASA

environment.

The features provided by individual vendors are discussed in

Section 5, and the features required in the NASA environment are

discussed in Section 6.

4.1 Daer Communication

For user communication service, the Network Operating System

may support interuse r communicatio n and user-to-system

communication. Users may be able to send one another electronic

mail, communicate back and forth in a dialogue, and arrange

interactive conferences among members in a larger group.

4.1.1 Message Handling Service

The Message Handling Service provides for the store and

forward delivery of electronic mail with content of:

o text,

o facsimile,

4-1
o graphics,

o voice,

o arbitrary binary data,

o any combination of the above.

It includes the capabilities for: entry of mail by the

user, transfer of mail between electronic mail centers, delivery

of mail to the user, scan in and out boxes, message retrieval and

probing the status of messages.

The services provided include a variety of services as

illustrated in Figure 4.1 Some services may provide additional

features specifying the format of the message, such as the CCITT

Document Content Specification to assist in preparation of

messages, e.g., establish message format, etc.

Relevant standards are the CCITT X.400 message handling

service standard are ISO work in process on Office Document

Architecture and Text Preparation and Interchange.

4.1.2 Print Service

The Print Service provides the capability of outputting a

hardcopy of electronically stored information at a remote

location. The key elements of the print service are:

o spooling of print requests such that a request is queued

if the printer is busy,

o real-time service, scheduled or batch service,

o forms control such that specific paper and format is

employed,

o fault recovery.

Recovery consists of being able to complete the printing

task in progess and then continue with remaining print tasks in

4-2
TABLE I TABLE II

MESSAGE TRANSFER

SERVICES -

INTERPERSONAL MANAGING

SERVICE ELEMENTS

Service Elements

Submission and Delivery

Message Transfer

Message Identification

Submission Time Stamp

Delivery Time Stamp

Grade of DeliverySelection

Deferred Delivery

Deferred Delivery Concellation

Non-delivery Notification

Delivery Notification

Prevention of Non-delivery

Notification

Multidestination Delivery

Disclosure of Other Recipients

Alternate Recipient Allowed

Request

Query

Probe

Status and Information

Hold for Delivery

Alternate Recipient Assignment

Conversion

Content Type Registration

Original Content Type Indication

Content Type Conversion

Prohibition

Implicit Content Type

Conversion

Content Type Conversion Indication

Explicit Content Type Conversion

Primary and copy recipient

indication (i.e.,to:,cc:)

Blind copy recipient indication (i.e.,bcc:)

Authorizing users designation (nonlegal signature)

Subject indication

User-message identification (personal, private,

company confidential)

Importance indication

Cross reference indication

Expiry date indication

Obsoleting indication

(i.e.,supercodes a

previous message)

Reply request indication

(i.e., to whom and by when)

Replying user-message indication (this is in reply to)

Multipart body

Body part encryption

Forwarded user-message body

part

(Non-)receipt notification

Reference: "Message Handling Systems and Protocols", Proceedings

of the IEEE, December 1983

TABLE 4.1: X.400 SERVICES

4-3
the queue. Completion of the task in progess when a failure

occurs (such as printer out of paper, end-of-ribbon) often

requires reprinting the last few pages (rather then reprinting

the whole file which can be time consuming and wasteful) Unlike

a disk failure, sometimes a printer failure cannot be detected in

the host computer such as a paper jam or faded ribbon. This

implies the need for manual intervention and recovery procedures.

If the device malfunction cannot be repaired, than the NOS

may also attempt to route the print request to an alternate

device.

4.1.3 Terminal Handling Service

The Terminal Handling Service provides the capability of

presenting/accepting data to/from the user at his local terminal.

This includes the capabilities of:

o presenting textual (formatted and unformatted) data and

nontextual data (facsimile, voice, graphics),

o displaying the data in window in the user display,

o communicating terminal to terminal.

The key issues regarding the terminal handling service are:

o with current technology trends, terminals are really

hosts rather than non-intelligent devices, thus they must

be able to handle multiple tasks,

o implementation of a terminal handling service as a

virtual terminal or as a parameter driven device; this is

critical for environments in which there are many types

of terminals,

o handling non-textual devices as graphics and image

applications become more important.

Although there is active standardization work in this area

on virtual terminals, it does not address current requirements

4-4
for exchange of non-textual information.

4.1.4 Conferencing

The conferencing service provides the capability of on-line

multiparty user communication. In this service users would enter

messages at their workstations and the NOS would display them on

the workstations of the other participants.

The key issues in the conferencing service:

o screen formatting of the user workstation,

o maintenance of a conference record,

o templates for specific primitive action items

resolutions,

o protocol for enabling users to enter/leave the

conference.

4.2 Job Migration

When a job can be broken into a group of cooperating

processes, it is desirable that the Network Operating System be

capable of scheduling these processes to run across multiple

nodes. Concurrent processing and synchronization are included in

this service category.

4.2.1 Remote Job Execution

The Remote Job Execution service can be executed at two

levels of sophistication. An elementary capability is to provide

a service which permits a user to execute a job on a remote

computer simply by invoking a procedure call. A more

sophisticated capability is to allow the user to define a set of

input sources, processors for execution and output destination.

The first alternative is referred to as the remote procedure call

4-5
service while the latter is referred to as the Job Transfer and

Manipulation Service. Both are discussed below.

The Remote Procedure Call Service provides the capability to

execute programs on remote computers using a procedure call as if

the program were resident on the local computer. This service is

sometimes referred to as the "interactive batch" service in that

the response time of the service is usually very rapid. This

service is analogous to current batch service except results are

returned in real time. To submit a request to the Remote

Procedure Call, the user invokes a call to a procedure as^if it

were local and supplies the necessary input parameters and, if

necessary, the data structures for return of the results to the

originating process. The Network Operating System is responsible

for locating the program, establishing the remote connection,

implementing the remote procedure, and delivering data to/from

it. Depending upon the implementation, the originating process

may wait for the results of the procedure call or continue

concurrent processing while awaiting the results.

Various other application layer protocols may also employ

this service. For example, the Message Handling service proposed

by CCITT employs a Remote Procedure Call to distribute electronic

messages. The Remote Procedure calls protocol is defined in

CCITT standard X.410.

In this terminology, the local process is connected to the

remote process via the remote procedure call upon demand during

program execution. After execution of the remote procedure and

return of results, the local and remote processes have no

association. Other types of remote procedure calls bind the

4-6
local and remote processes during compilation or load time. This

connection is maintained throughou t the lifetime of the

connection. This latter type of remote procedure call is more

like the interprocess communicatio n discussed below. In

particular, the real-time performance of this protocol will be

better because the association is pre-established.

The key issues associated wit h the RFC are achieving

adequate performance with the requisite set-up procedures and

handling exception conditions. For example, if the return from

the remote procedure does not occur, what action should the

application take. For example, the remote procedure may have

successfully executed but the response was lost. Simply reexecuting the procedure would introduce an error if repeated

execution of the remote procedure does not generate the same

result. For example, adding $100 to the balance of a bank

account does not generate the same result, i.e., the first time

through, $100 is added, but if it executed twice, $200 would be

added. These problems associated with remote procedure calls

have resulted in the categorization of "at least once" or

"exactly once" semantics.

The Job Transfer and Manipulation Service, a generalization

of remote job entry protocols, provides the capability of the

user of specifying how the:

o job should be partitioned into subjobs to be run on

different processors,

o results should be processed and controlled by the

computers performing the job,

o results should be retrieved and reassembled.

4-7
This service provides the distributed computing service in

that jobs can be distributed and assigned to the optimal computer

for execution. Optimality can be defined in terms of:

o suitability of a particular computer for performing a

job, e.g. scientific computing on a "number crunching"

computer,

o optimizing communications and computer costs,

o assigning jobs to under-utilized resources.

The relevant standard for Job Transfer and Manipulation is

ISO DP 8832.

4.2.2 Interprocess Communication Service

The interprocess Communication Service provides program to

program communicaton between remote process. Its key features

are data transfer and process synchronizaton. The interprocess

synchronization is a control mechanism which enables remote

processes to:

o effect process precedence control, e.g., determining

which process currently has access to a resource,

o effect shared resource control.

It is analogous to the semaphore in conventional operating

systems.

The major issue is providing adequate throughput performance

across the network. This requires use of a message oriented

communication rather than byte oriented (as in UNIX pipes). Also

to enhance performance, it is desirable to notify the receiving

process that a message has been received from it rather than

requiring the process to keep checking to determine if a message

has been received.

The communications primitives provided will have a major

4-8
impact on performance. A categorization of these primitives

based on work by Stankovic [48] is illustrated in Figure 4.2.

Using a synchronous send, the user is blocked, i.e., must wait

until the message is received by received; thus the source and

destination are synchronized. If the no wait send is employed,

the user can initiated other tasks, but the NOS must provide

buffering to accommodate the message. If a conditional send is

employed, then the receiver is blocked waiting for the source

message.

When the receiver is blocked awaiting messages from remote

locations, either restricted unconditional in which messages from

specified processes will be accepted or blind unconditional in

which all messages will be accepted. Alternatively in the

conditional receive, the communications channels are polled.

In summary, the type of primitive will drive the level of

concurrency that can be achieved and limit the performance.

A majo r application for this service is in distributed

control. In this case it may become significantly mor e

complicated when more than two processes are involved. The issues

of updating data structures are analogous to updating distributed

data bases and are discussed below unde r Concurrenc y and

Synchronization.

Although no internationa l standards organization is

promulgating a standard for interprocess communication, IBM has

published its standard, Logical Unit (LU) 6.2 [61]. The key

features of the process-to-process communication provided by LU

6.2 are that it:

4-9
SEND

YNCHRONOUS NO-WAIT CONDITIONAL

NON-BLOCKED

RECEIVE

UNCONDITIONAL CONDITIONAL

RESTRICTED BLIND

BLOCKED NONBLOCKED

FIGURE 4.2

COMMUNICATIONS PRIMITIVES

4-10
- permits multiple applications to communicate through the

same process,

is symmetric,

- can transmit arbitrary binary data,

- employs a half-duplex protocol,

is designed with the intention to accommodate distributed

data base two phase transaction protocols. See Section 5

on Concurrency and Synchronization.

4.3 Data Migration

The Network Operating System must support the remote access

of information. Since heterogenous nodes are involved;* data

types must be preserved across the network between the nodes.

Data and character translations and even data restructuring may

be supported.

4.3.1 File Service

The File Service provides the capability to the .user of

performing operations on:

o the contents of a file,

o on entire file, or

o groups of files.

The key elements of a File Service are:

o file structures supported,

o specific operations that can be performed on contents of

a file, the file, and groups of files,

o degree of sharing,

o access control.

The file service is probably the most common service

provided by Network Operating Systems. The file service has

evolved from its rudimentary form of only transferring entire

4-11
files to remotely accessing files through commands sent over the

network. A representative set of commands is enumerated in

Figure 4.3.

The structures of the file will drive the efficiency with

which various users will be able to access files and thus

establish the suitability of the file structure for various

applications. The structure of the file can be viewed in terms

of:

o access structure describing the organization of data

contained with a file as it affects a file's contents

- flat or hierarchical

- sequential, random, indexed sequential

o presentation structure describing the syntax of the data

items in the file, e.g., are all files treated as binary

files or are specific structures supported such as

graphics files, etc.

Another major characteristic of the file service is the

degree of sharing of programs and data stored in these files and

the commands users are permitted to execute. For example, files

can be shared at the following levels:

o entire file,

o records,

o field.

When files are accessed users may be permitted to perform:

o read only operations,

o write only, modify only operations,

o read and write operations.

Another major issue is maintaining concurrency of files when

4-12
F-CONNECT - file service initiation;

F-RELEASE - file service termination (orderly);

F-ABORT - file service termination (abrupt);

F-SELECT - file selection;

F-DESELECT - file deselection;

F-CREATE - file creation;

F-DELETE - file removal;

F-READ-ATTRIB - file identity attribute inspection;

F-CHANGE-ATTRIB - file identity attribute modification

F-OPEN - file access initiation;

F-LOCATE - FADU location; ' *r

F-ERASE - FADU removal;

F-RECOVER - file access recovery;

F-CLQSE - file access termination;

F-WRITE - data storage initiation;

F-READ - data retrieval initiation;

F-DATA - data retrieval initiation;

F-DATA - data transfer

F-DATA-END - data transfer completion

F-TRANSFER-END - data transfer commitment;

E-CANCEL - data transfer cancellation;

F-CHECK - data transfer checkpoint;

F-RESTART - data transfer resumption

FIGURE 4.3

Typical File Service Commands

4-13
multiple users are accessing the file. This requires a file

locking capability to prevent multiple, concurrent modify

accesses. Furthermore, these files may be replicated at different

locations, complicating the concurrency control problem.

The relevant standards for the file service is the ISO File

Transfer, Access, and Management protocol (IS 8571). To provide

compatibility between different local file systems, this protocol

employs a virtual file store. A virtual filestore is a data

structure representation of the file and corresponds to the file

structure perceived by the remote consumer." The local server

must perform the translation from the actual file structure to

the virtual file structure. This facilitates compatibility for

exchange of files among multiple users. For example, if N users

are exchangin g information , each may have their own fil e

structure and must perform translation to the virtual filestore.

Thus N conversions would be required rather than N x (N-l)

conversions if each user had to perform conversion to every other

user's local structure.

The National Bureau of Standards enhanced the ISO FTAM

protocol with three party transfer model. The three party model

enables a user to initiate a file transfer and then proceed to

another task while the file transfer is performed. Furthermore,

the user may be resident on system A and request a file transfer

fro m System B to System C. Traditional file transfer services

provide a transfe r from only a remote host to the local user

system while the local user maintains a connection with the

remote file server.

4-14
4.3.2 Data Representation Service

The Data Representation Service enables the user to encode

data in different syntaxes. The major issues associated with the

presentation service are syntaxes supported and the capability to

switch syntaxes. The selection of syntax may allow for

representation of:

o binary data,

o character text,

o graphics,

o images.

Characters may include letters, integers, reals,

punctuations, and mosaics. Character text may be unformatted

such as an ASCII character string or formatted such as time or

data representation. Characters may include letters, numbers,

punctuations, or mosaics.

The other aspect of the data representation service is if

the capability is not provided, then the syntax to be employed

between communicating parties must be prearranged. Alternatively

the syntax may be negotiated during the setup of a connection.

The most sophisticated capability is to switch upon demand during

the correction. The ISO Presentation protocol (DP 8822) provides

the capability to switch context upon demand.

There are no specific syntaxes embedded in the ISO

presentation protocol. Rather the specific encoding can be

incorporated as a table. Applicable encoding standards are the

ISO Abstract Syntax Notation (DP 8824) and the CCITT X.409

encoding standards for message handling. These are very similar,

but do not provide the capability to represent graphics.

4-15
4.4 Network Control

The Network Operating System shall provide the means for

allocating resources and for controlling the interaction between

the network and its nodes.

4.4.1 Network Management Service

The Network Management Service ensures the on-going fault

free operation of the network including:

o network configuration,

o gathering and processing statistical information,

o fault detection, isolation, and restoration.

The Network Configuration activity includes the adding or

deleting of resources which may include hosts, workstations, as

well as server processes. For example a server process to

perform specific types of calculations or data base retrievals is

viewed as a resource.

The gathering and processing of statistical information has

widespread users. It may be for accounting, network signing, or

fault detection. Statistics such as connect time, number of

connections, lost messages, delays may be gathered and processed.

It is very desirable goal that the NOS perform fault

detection, isolation, and restoration service to ensure the error

free delivery and maintenance of data in an environment

characterized by potential device or network failures.

Features that are incorported into NOS to address these

problems are on-line diagnostics and data integrity measures such

as periodic file updates, checkpoints, transaction updates, and

4-16
shadow file servers. These may be either NOS or local operating

systems responsibility.

On-line diagnostics ensure that the network is functionally

operational at all levels. Typically, this requires a Master

Diagnostics Process which periodically communicates with local

diagnostics process in all other nodes. The Master Diagnostics

Process in responsible for collecting (either by polling or

reading a shared file) individual nodal diagnostic statistics and

interpet them to isolate abnormal incidence e.g., on high

error/retry rate for traffic originating from destinedp to.. a.

particular mode. Alternatively this function could be at least

partially distributed.

The data integrity measures ensure that data is not lost or*

the loss is minimal when a failure occurs. Specific techniques

are:

o Periodic updates to the disk file structure (file control

block) to minimize loss of data due to failure,

o Checkpoints fully exploit the above capability and

requires the application/user process to be capable of

being suspended while the failure is being fixed and then

performs a back-up restart from the most recent update.

o Transaction update is a combination of the twoapproaches

described above. The file server provides the capability

to accumulate several file operations (writes/updates)

without actually performing them on the disk. The

application can indicate when a new transaction begins

and let the server accumulate the writes/updates until

the server is informed that the transaction is complete.

At this time the server performs the actual disk updates

in such a manner that if there is a failure before all

updates have been performed the file will behave as if no

changes were made such that a transaction becomes an

atomic operation.

o Shadow file server: Provides a second file server with

the same network name and address as the primary file

server to co-exist on the LAN: it performs all the same

disk writes as the primary (active) file server but does

4-17
not respond to reads, however it does maintain control

information (such as current read printer) necessary to

respond to a read. If and when the primary server

fails, it immediately takes over and starts responding

to reads.

The key issues associated with during so are:

o degree to which recovery feature should be built into

the NOS versus the application,

o degree to which recovery features should be built into

local hardware.

o use of automatic versus manual reconfiguration.

This is closely related to maintaining concurrency of user

and directory files. In particular there is a movement, within

the OSI environment to restructure layer 7, the application

layer, to provide the recovery service. A draft proposal exists

for implementing it, namely the Commitment, Concurrency, and

Recovery Service (DP 8650) as a layer 7 protocol.

4.4.3 Directory Service

The Directory Service provides the capability to the user of

locating other users, and resources (hosts) or services in the

network. Note the file directory is included in the file service

not in the Directory Service. This separation is effected

because user and resource directories are updated infrequently

relative to updates in the file directories. Thus different

approaches are applicable.

Salient features of the the Directory Service for users and

resources are:

o naming and addressing convention,

o directory architecture (centralized, distributed,

hybrid),

o directory size and breadth limitations,

4-18
o directory access methods,

o strategy for establishing and updating the directory.

The establishment of a naming and addressing convention

requires that resources and services be uniquely identified by

name in the directory such that the requisite network address

information can be maintained. The major issue associated with

addressing is maintaining currency of the address associated with

new users or resources and modifications associated with "Named"

users whose address may change. cr:--

The network directory architecture can affec t cost and

performanc e issues. For example , whethe r the storage of

directory information is centralized or distributed will affect

response time associated with retrieving directory information,

availability of directory information , and complexity of

maintaining current information. The size of the directory

(number of entries) and breadth of the directory (number of users

and resources) will be, to a large extent, driven by the

directory architecture.

There are two primary techniques for accessing the directory

service to obtain address information. A user may either:

o query a specific directory to determine if that directory

contains the specific information,

o send a broadcast query to all directories requesting the

address information, but only the directory with the

required information will respond.

Furthermor e whe n the director y becomes distributed ,

maintenance of the directory becomes a distributed data base

problem and significantly complicates maintaining currency.

Although there is wor k currently in process for the

4-19
development of a directory standards, such as standard has not

been forthcoming.

4.5 Common

Common services consist of services provided to any two or

more of the services described above.

4.5.1 Transport Services (Layers 1-5 of OS I Reference Model)

The Transport Service provides for the logical multiplexing

of connections over a single transmission media and the delivery

of information from source process (device) to destination

process (device). Depending upon the environment this may

include OSI protocol layers one to five or some subset of these

layers. The data should be reliably delivered in the sequence

that the data was entered for most services and applications

employing the transport service.

The scope of the transport service depends on the local

environment. If the local environment is a local area network,

then only physical, data link and session layer protocols may be

required. If multiple local area networks of the same kind are

employed, then a simple network layer protocol would also be

required and a bridge device employed to concentrate the multiple

local area networks. If different types of local area network or

a wide area and local area network are concatenated then an

Internetworking protocol would be required. This would provide

such additional functionality as packet fragmentation (to allow

networks with different maximum packet sizes to be linked) and

speed conversion.

4-20
The techniques employed by layers 1-5 to provide the

transport layer service should be transparent to the user

services and applications. For example the use of connection

based protocols versus datagrams as well as the use of virtual

circuits is germane only to layers 1 to 5.

4.5.2 Network Security Service

The Networ k Securit y Service ensure s that only the

users/processes with the requisite authorization level are

permitted to use other network services. This includes:

o authorization to read or read and modify files,

o authorization to communicate only among a specified user

group,

o authorizatio n to invoke user services, e.g., fil e

service, message handlin g service, job transfer,

directory service,

o authorization to invoke system services such as network

management.

The use of authorization lists and user passwords is the

common technique for implementing the security service.

4-21
5.0 SURVEY RESULTS

In this section CTA summarizes the NOS survey results.

First the key trends in NOS development are summarized. Then

individual summaries of relevant vendor products and research

efforts are presented. Each of these narratives is supplemented

by a filled-in product/project template in the Appendix. These

templates provide concise single page summarie s of the

products/projects CTA evaluated.

5.1 Key Trends and Observations .*

Most NOS's were being developed for environments employing

UNIX or IBM PC DOS as the local operating system. Of the 28

vendors surveyed, 10 provided UNIX based systems while 16

• .'

provided PC DOS based systems. Some vendors were employing their

own proprietary operating systems such as Intel using its iRMX

operating system and DEC using various operating systems

supporting DECnet. However, Intel has formulated its Open Net

architecture which provides interoperability with a UNIX lookalike, XENIX, and with PC DOS. Also, DEC has plans to offe r

DECnet under UNIX, and Technology Concepts intends to offe r a

plugin board for the IBM PC XT and AT supporting DECnet.

The most commonly offered service is a file service because

of its historical significance. In many early developments, a

NOS was used to provide file access to workstations without local

disks. Although many workstations now have their own local disk,

the demand for information is insatiable and users still need

access to remote files. Similarly, there was an important

requirement to share printers; thus print service evolved. This

5-1
is still an important service.

These services then evolved to user-to-user communication

providing electronic mail (store and forward messaging) and

program-to-program communication using the remote procedure call.

All of these services are commonly available in NOS products.

Historicallyr the developments associated with UNIX have

preceded the PC DOS developments. Developers working with UNIX

have tended to integrate the NOS with the UNIX Kernel and

reducing its portability. Thus even though UNIX is available on

many hosts, porting the NOS to a new UNIX host is not trivial.

The PC DOS developers have tended to build a shell around the PC

DOS, which theoretically makes it more portable. However, PC DOS

is limited to PC class hosts.

Host support is largely in three main areas:

o DEC VAX in the minicomputer class,

o IBM PC in the personal computer class,

o Motorola 68000 based computers in the workstation.

Many vendors have developed their own custom hosts based on the

68000 such as SUN MICROSYSTEMS and Charles River Data Systems.

Support of the OSI model is minimal. Early LAN developers

focused on achieving performance and in doing so, implemented

simpler protocols with fewe r protocol layers. Vendors who do

adhere (or claim to adhere) to the OSI model typically do not

support all layers.

Only recently have vendors tended to provide an open system

to communicate with systems provided by other vendors. With the

increasing acceptance of the OSI Reference Model and associated

protocols interoperability among vendors will become more common.

5-2
Intel, with its Open Net architecture and Charles River Data

Systems are leaders in this area. Intel supports file service

interoperability among PC DOS, XENIX, and iRMX hosts using OSI

protocols up to layer 4 and protocol conversions in layers 5 to

7. Charles River Data Systems is developing OSI protocols for

all layers.

One of the most significant steps in the acceptance of OSI

and associated protocols is the promulgation of the Manufacturing

Automation Protocol by General Motors. Although details of the

specific protocols to be employed are yet to be determined, it is

clear that it will be OSI based. Thus, a significant part of

industrial automation applications will employ OSI.

5.2 Individual Vendor/Source,

This section provides, in narrative form, a description of

the salient characteristics of the relevant products and research

efforts identified by CTA's survey. For consistency with Section

4 of this report, each product or project address the NOS

functional service requirements listed below:

User Communication

Message Handling

Print

Terminal Handling

Conferencing

Job Migration

Remote Procedure Call

Job Transfer and Manipulation

Interprocess Communication

Data Migration

File Service

Data Representation

5-3
Network Control

Recovery Service

Network Management

Directory

Common

Transport

Security

The narrative is supplemented by the product templates

provided in Appendix A to this report.

Sections 5.2.1 through 5.2.13 present the narratives for 13

NOS products surveyed by CTA. These products were selected since

collectively they represent implementations of all NOS

functional characteristics identified in Section 4. Also, each

product described offere d a unique service(s) and/or design

feature(s) in its implementation which warranted description.

CTA has provided narratives for only a few of the many commercial

and research products identified during this survey. This was

done for two reasons. First, a greater level of detail is

provided on each of the 12 products than could otherwise be

supplied. Second, CTA recognizes that, ultimately, this survey

would be used by NASA to produce a build for an NOS. This also

caused CTA to focus principally on detailed descriptions of

commercial products only.

The first product, LOCUS (5.2.1) offers a network-wide,

replicated, distributed file system which may be accessed

transparently by any user on the network. This transparency is

extended to all devices as well as permiting remote access by all

users in a heterogeneous environment. LOCUS stands out among the

commercia l products surveye d since it offers the use r a

comprehensive set of NOS feature s in its implementation. All

5-4
seven layers of the ISO/OSI model are supported and described in

the next product, OniverseNet (5.2.2) by Charles River Data

Systems (CRDS). CRDS's product is based on a real-time ,

proprietary UNIX-based 0/S and offers efficient, fast networking

in a homogeneous environment of CRDS workstations. The real-time

performance is important in the NASA environment. Section 5.2.3

describes the Sun Microsystem's product NFS 2.0. Key features of

NFS are support of a heterogeneous UNIX-based environment and,

most importantly, standards proposed for remote procedure call

and data representation services. The Newcastle Connection.'

(5.2.4) available from Portable Software, Inc. is another UNIXbased product. Its prominent featur e is the implementation of

networking capabilities as a set of software residing between the

kernel and the shell. This implementation facilitates ease of

portability of the product since no modifications have been made

to the operating system. Many vendors have used or based their

networking product on UNIX, and specifically, the Berkeley

Software Distribution (BSD). Section 5.2.5 focuses on the

capabilities of BSD version 4.2 Its salient features extend the

basic UNIX capabilities with interprocess communication, virtual

memory support, and network file and printing services. Fusion,

a product offered by Network Research Corporation, is described

in Section 5.2.6. It offers a comprehensive implementation of

NOS characteristic s and conforms to the OS I Model. No

modification to the local 0/S kernel is required since it is

implemented as a device driver to the 0/S code. Fusion supports

a wide variety of processors and operating system environments.

OpenNet, a product offered by Intel, is described in Section

5-5
5.2.7. Its architecture is based upon the OSI model and its

salient characteristic is its interoperability with the iRMX,

XENIX, and PC-DOS operating systems. This feature emphasizes its

portability.

There are many software products for the IBM PC class (and

compatibles) that wer e surveyed by CTA. Most could be

categorized as print and/or file servers. Two products which

offered the most networking capabilities are Novell's Netware/86

(5.2.8) and Microsoft's Networks 1.0 (5.2.9). The former is a

portable product which has achieved support from a number of LAN

hardwar e vendors. The latter is an extension of MS-DOS 3.1 and

is important in light of the number of PC's and compatibles which

exist in the marketplace today. As such, this product has the

potential of becoming a de facto standard for networking IBM

PC's. Section 5.2.10 describes Digital Equipment Corporation's

produc t DECnet. It was chosen since it represents an

architecture which, although is proprietary, parallels and is a

competitor of the ISO/OSI model. DECnet currently supports many

of the NOS characteristics. Of particular interest in that (1)

it will be available for UNIX-environments, and (2) a

Massachusetts company, Technology Concepts, is producing the

printed circuit board equivalent for DECnet. Sections 5.2.11 and

5.2.12 focus on the products QNX and Apollo Domain respectively.

The forme r is offered by a Canadian company, Quantum Softwar e

Systems, and offers a UNIX-based networking environment for IBM

PC's. Apollo Domain's architectur e characterize s both a

proprietary operating system and networking (token ring LAN)

5-6
environment for their MC68000-based workstations. Apollo has

implemented an object-oriented design for the Domain network. It

is of interest since it is representative of a proprietary

distributed operating system (DOS) but,as such, was given a lower

priority in this survey.

Tables 5-1 through 5-6 summarize , in matrix form, the NOS

features supported by the vendors surveyed by CTA. Vendors and

their products are listed in alphabetical order and grouped

according to the operating system they are based upon: UNIX (or

a derivative), PC-DOS/MS-DOS (and extensions), and proprietary

implementations. Some vendors have been listed in more than one

group since their product has been implemented in more than one

O/S environment. It should be emphasized that these charts be

utilized to ascertain only whether a vendor has included some

level of the corresponding NOS characteristic. The level of

implementation for the vendors listed varies widely. Succeeding

paragraphs provide a greater level of detail regarding each

implementation.

5-7
Hatrix of Vendor Product Services

ORIGINAL PAGE IS

OF POOR QUAUnr

Vendor

Naae Product UNIX

0/5 Base

?C or HS DOE Otnsr

Apollo Coiputer, Inc

Digital Equipaent Corp.

Charles River Data Systems

Intel

"Lantech Systess r

Locus Conputing Corp.

Network Research Corp.

Portable Software,Inc

Quantua Software Systeis

Sun Hicrosysteis

Touchstone Software

AST Research

Corvus Systeas

Davong Systess

Digital Research Inc

Intel

Microsoft

Nestar

Network Research Corp.

Novell

Orchid Technology

Quadran

Televideo

3Co«

Touchstone Software

Ungenann-Bass

Xcoep

Alcyon

Apollo Computer, Inc

Digital Equipaent Corp.

Digital Research Inc

Intel

Hulti Solutions, Inc

Network Research Corp.

Network Systeas

Sun Nicrosysteis

Touchstone Software

Hang Laboratories

Apollo Doaain

DECnet

UniverseNet

OpenNet .

uNETix

LOCUS

FUSION

The Newcastle Connection

QNX 2.0

NFS 2.0

The Connectables

PCnet-II

Oaninet

Wultilink

DRNet

OpenNet

MS-NET 1.0

Plan 3000,4000

FUSION

Netware

PCnet

Quadnet

PN/16

Etherseries

The Connectables

NET/ONE

X-Net

DFS

Apollo Doiain

DECnet

DRNet

OpenNet

SI

FUSION

NETEX

NFS 2.0

The Connectables

HangMet

4 QTR 1985

Regulus

AE6IS

VHS.RSK

CP/N

iRHX

SI

VMS

IBH/HVS,DEC/VMS

VMS

Me Intosh

(TBS!

NOTE: Soae products have aultiple entries

since.they are supported in lore than

one 0/S environient.

TABLE 5.1

5-8
trix of Vender Product Services

/c-fijor

Product Prin t

olio Cospjter. Inc

gital Equipsent Corp.

arlss Rivsr Data Systess

te:

ntech Systeas

cus Coeputing Corp.

tKork Research Corp.

rtable Software, inc

antua Software Systeas

n tticrosysteas

uchstone Software

T Research

rvus Systaas

vong Systsas

gital Research Inc

tel

crosoft

star

twork Research Corp.

veil

chid Technology

adraffi

levideo

on

uchstone Software

geraann-Bass

cap

cyon

olio Coaputer, Inc

gital Equiprent Corp.

gital Research Inc

tel

I ti Solutions, inc

twork Research Corp.

twork Systeas

n Nicrcsysteas

uchstone Software

ng Laboratories

Apollo Doaain

DECnet

UniversaNet

OpenNet

uNETix

LOCUS

FUSION

The Newcastle Connection

9NX 2.0

NFS 2.0

The Connectables

PCnet-II

Oaninet

Nultilink

DRNet

OpenNet

NS-NET 1.0

Plan 3000,4000

FUSION

Netware

PCnet

Suadnet

PN/16

Etherseries

The Cannectables

NET/ONE

X-Net

DFS

Apollo Domain .

DECnet

DRNet

OpenNet

SI

FUSION

NETEX

NFS 2.0

The' Connectables

HangNet

EH

TBB

EK,TD

EN

*

EH

*

TD

EH

t

i

i

t

t

t

EN

EN

*

*

EN, TO

EN,TD

f

EN

i

» t

when released

PS ili

PS

i

t

t

i

PS

PS

,

t

«

t

*

t

i

t

t

f

t

PS

PS

t

f

t

t •

f

«

t

PS

VT

t

VT

t

»

VT

t

t

VT

*

VT

i

VT

VT

TE: Soae products have aultiple entries

since they are supported in sore than

one Q/S environsent.

TABLE 5-2

- PRINT SERVICE CQNKQN TO ALL

- NESSA6E HANDLING IN HOST PRODUCTS

- TERMINAL HANDLING PRINCIPALLY

IN UNIX I PROPRIETARY SYSTENS

- CONFERENCING LACKING

11) Virtual Teroinal cay be implemented

fay user applications software

!2) Codes: EN = Electronic Nail

TD = Terainal Dialogue

PS = Print Server

VT = Virtual Terainal

» = service is supported
Vendor

Naee. Prc;cu:t

Job Migration

RFC .HM! I PC

Apollo Cosputer, Inc •

Digital Equipment Carp. -, ,,-

Charles River Data Systess

Intel

Lantech Systeas

Locus Conputing Corp.

Network Research Corp.

Portable Software,Inc

Quantua Software Systeas

Sun Hicrosystess

Touchstone Software

AST Research

Corvjs Systess

Davong Systems

Digital Research Inc

Intel

Microsoft

Nestar

Network Research Corp.

Novell

Orchid Technology

Quadras

Televideo

Apollc Domain

Touchstone Software

lingeraann-Bass

Xconp

Alcyon

Apollo Coaputer, Inc

Digital Equipaent Corp,

Digital Research Inc

Intel

Multi Solutions, !nc

Network -Research Corp.

Network Systeas

Sun Microsystees

Touchstone Software

Wang Laboratories

NOTE: Soee products have uultiple entries

since they are supported in »ars than

one 0/3 environeent.

TABLE 5-3

DECnet

UfiiverseNei

Op en Net

uNETu

I (1PMC

Lu'^u^'

FUSION

The Newcastle Connection

9NX 2.0

NFS 2.0

The Connectables

PCnet-II

Canine:

U.. i V ; ' ^ r- .-

"vji •.; . i .11.

DRHet

OpenNet

HS-NET 1.0

Plan 3000,4000

FUSION,

Netware

PCne:

Buadnet

PM/16

Etherserie;

The Connectabies

NET/ONE

X-Net

DFS

ftpclio Dosain

BECnet

DRNet

OpenNet

SI

FUSION

NETEX

NFS 2.0

The Connectabies

Han.gNet

TBD when released

*

* *

*

* »

t

* *

* t *

t

t

»

i

*

* t

. i

t

t

*

^

» *

JOB MIGRATION LACKING

IN DOS SYSTEMS

DEFFICIENC'f IK JTiM

OVERALL

5-10
Hatrix of Vendor Product Services

Vendor

NoSE Product

Data Migration

FUE Svc Data Rep

Apollo Coaputer, [nc

Digital Equipment Corp.

Charles River Data Systeias

Intel

Lantech Systess

Locus Coaputing Corp.

Network Research Corp.

Portable Software, Inc

Quantuo Software Systess

Sun flicrosysteas

Touchstone Software

AST Research

Corvus Systeas

Davonq Systeas

Digital Research Inc

Intel

Kicrosoft

Nestar

Network Research Corp.

Novell

Orchid Technology

Quadrats

Televideo

SCofl

rouchstone Software

Ungereann-Bass

(coap

Ucyon

Ipollo Computer, Inc

Hgital Equipaent Corp.

ligital Research Inc

Intel

lulti Solutions, Inc

letwork Research Corp.

letwork Systees

kin Microsystem

ouchstone Software

lang Laboratories

Apolla Ooeain

DECnet

UniverseNet

OpenNet

uKETis

LOCUS

FUSION

The Newcastle Connection

9NJ 2.0

NFS 2.0

The Connectables

PCnet-II

Oan i net

Multilink

DRNet

OpenNet

HS-NET 1.0

Plan 3000,4000

FUSION

Netware

PCnet

Quadnet

PH/16

Etherseries

The Connectables

NET/ONE

X-Net

DFS

Apollo Docain

DECnet

DRNet

CpenNet

SI

FUSION

NETEX

NFS 2.0

The Connectables

HanqNet

OTE: Soae products have nultiple entries

since they are supported

one 0/S environeent.

in sore than

»

TBS when released

FT.FL.RL

F-A.SH

FT, FA

FT,SH,FR «

FT *

FA

FT,5H *

t *

* «

t

«

t

FA,FL,RL

Fft.SH

t

t

i »

t

t

t

i

FS

t *

»

t

FA

t

FT,SH »

FA.FL.RL

Ffl.SH

FT,SH

* «

FT i

t *

t *

FT

- FILE SERVICE

IS UNIVERSAL

- DATA REP IS

LftCKINB

ORIGINAL PAGE IS

OF POOR QUALITY

TABLE 5-4

(1! Codes: FT - File Transfer

SH - File Sharing

FS - File Server

FL - File Locking

RL - Record locking

Ffl = File Access

FR - File Replication

5~H § = service is supported
Matrix of vendor Product Services

Vendor

Naae

Apollo Coaputer, Inc

Digital Equipaent Corp.

Charles River Data Systeas

Intel

Lantech Systess

Locus Computing Corp.

Network Research Corp.

Portable Software,Inc

Quantum Software Systeas

Sun Nicrosystees

Touchstone Software

Product

Apollo Doaain

DECnet

UniverseNet

OpenNet

uNETix

LQCUS

FUSIOM

The Newcastle Connection

QNK 2.0

NFS 2.0

The Connectables

Netnork Control

Recovery Net Mgist Directory

TED when released

*

NS

AST Research

Corvus Systeus

Davong Systess

Digital Research Inc

Intel

Microsoft

Nestar

Network Research Corp.

Novell

Orchid Technology

Quadras

Televideo

3Com

Touchstone Software

Ungeraann-Bass

Xcoap

ftlcyon

Apollo Coaputer, Inc

Digital Equipaent Corp.

Digital Research Inc

Intel

rtulti Solutions, Inc

Network Research Corp.

Network Systets

Sun hicrosysteas

Touchstone Software

Hang Laboratories

PCnet-II

Osninet

Multilink

DRNet

OpenNet

MS-NET 1.0

Plan 3000,4000

FUSION

Netware

PCnet

Buadnet

PM/16

Etherseries

The Connectables

NET/ONE

X-Net

DFS

Apollo Detain

DECnet

DRNet

OpenNet

SI

FUSION

NETEX

NFS 2.0

The Connectables

UangNet

NS

NOTE: Soae products have aultiple entries

since they are supported in eore than

one 0/S environaent.

TABLE 5-5

- RECOVERY PRQC. LACKING

- MINIMAL NET. MANAGEMENT

(1) Codes: NS = Network Statistics

5-12
Katrix of Vendor Product Service;

Vendor

Sase Product

Coeaon

Transport Security

Apollo Couputer, Inc

Digital Equipsent Corp.

Charles River Data Systeus

Intel

Lantech Systems

Locus Coaputing Corp.

Network Research Corp.

Portable Software, Inc

Quaniua Software Systeis

Sun Microsystens

Touchstone Software

AST Research

Corvus Systess

Davcp.q Systems

Digital Research Inc

Intel

Microsoft

Sestar

Network Research Corp.

Novell

Orchid Technology

Quadras

Televideo

3Co«

Touchstone Software

Ungeraann-Bass

Kcoap

fticyon

Apollo CcflGuter, Inc

Digital Equipaent Corp.

Digital Research Inc

Intel

Multi Solutions, Inc

Net nor k Research Corp.

Netxork Systess

Sun Kicrcsysteas

Touchstone Software

Hang Laboratories

Apollo Doaain

DECnet

UniverseNet

OpenNet

uNETix

LOCUS

FUSION

The Newcastle Connection

QNX 2.0

NFS 2.0

The Connectables

PCnet-11

Oaninet

Hultilink

DRNet

CpenNet

HS-NET 1.0

Plan 3000,4000

FUSION

Netware

PCnet

Quadnet

PH/1&

Etherseries

The Connectables

NET/ONE

X-Net

DFS

Apolla Oosain

DECnet

DRNet

OpenNet

SI

FUSION

NETEX

NFS 2.0

The Connectables

HangNet

*

TBD when

i

»

«

»

t

t

t

t

4

1

t

t

f

*

f

i

{

t

4

f

i

1

4

1

«

t

t

t

t

t

f

t

*

*

*

released

*

i

t

LP

OS

*

i

t

t

FP.OS

t

•f

t

t

t

t

FP

t

LP,FP,OS

FP,OS

t

*

t

t

NOTE: Sose products have aultiple entries

since they are supported in sore than

one 0/S environaent.

TABLE 5-6

c T-J

- SECURITY:

-USUALLY PASSWORDS

-L060N

-FILE i RECORD ACCESS

CONTROL

(1) Codes: LP = Logon Password

FP = File Passiord

OS = 'Other' Security

(e.q.,private volu»es)

« = service is supported
5.2.1 LOCOS

Locus is a distributed operating system (DOS) produced by

the LOCUS Computing Corporation of Santa Monica, CA. This UNIXbased product represents an outgrowth of research originally

performed at UCLA (See "The LOCUS Distributed Operating System"

by G. Popek et al, ACM June 1983). Its derivation from UNIX

includes modifications of its internals and the incorporation of

considerable extensions. LOCUS operates on an Ethernet network

utilizing a propriety data transfer protocol. A heterogeneous

computer environment consisting of DEC VAX and Motorola M68000

CPU's is supported.

Salient features of the LOCUS DOS include:

o its distributed file system,

o remote tasking,

o dynamic reconfiguration,

o heterogeneous computer environments, and

o system management.

LOCUS supports: transparent access to data through a

network-wide file system (a superset of the UNIX tree structure

namin g hierarchy); automati c replication of storage; and

transparent distributed process execution.

As a distributed version of UNIX, LOCUS is object code

compatible with Berkeley UNIX V4.1 and V4.2, and UNIX System V.

The ISO/OSI seven layer model is not implemented in LOCUS'

design. This decision appears to have been made in order to

provide users maximum product performance. Because the protocols

have been simplified, LOCUS minimizes the protocol and message

processing overhead by performing much of the processing at

5-14
interrupt level rather than in a user process. Telephone

conversations with the vendor emphasize d that due to the

extensive efforts to develop the existing product, the ISO/OSI

Model was not likely to be implemented in the near future .

Nevertheless, LOCUS provides valuable insight to state-of-the-art

NOS technology.

Transparency is the key thrust of the LOCUS DOS. This is

•

accomplished by making a collection of machines appear to the

user as a single processor with a root file system. Programs can

run on any machine in the system. A unique pathname is

associated with each file in the system. This lends itself to

data and name transparency allowing uniform access to data in the

system regardless of location. Coupled with the transparency

philosophy is LOCUS' design feature of file replication. This

significantly increases the system reliability and data

availability. LOCUS goes to great pains to assure the user that

in the event of a file update failure, the file is left in either

its old or new state and not something inbetween. Updated files

are copied as appropriate throughout the system automatically to

assure consisting of replicated files throughout the network.

Informatio n maintained at nodes allows the system to

automatically select the latest version of a file. Replication

of files is dynamic and the degree of it is under direct user

control. To assure pathnames to all files (remote or local) are

still accessible to the user in the event of failure, LOCUS

extends it replication philosophy to the entire directory as

well.

5-15
Transparency is extended to devices in general allowing, for

example, remote computer access from a user's terminal, remote

access to line printers, and host access of remote disks. The

installation does not rely on the need for a dedicated file

server in the network, although, any machine may be so designated

if some benefit may be derived from doing this. Remote accesses

are performe d efficientl y in LOCUS primaril y due to the

networking operations being firmly embedded within the operating

system kernel. As a result, all messages take place between

local and remote operating systems. Overhead is thus reduced to

an absolute minimum and the actions are invisible to user

programs.

LOCOS' distributed file system is its dominant architecture

feature. Four essential elements of the file system are its

distributed naming , catalog, synchronizatio n facilities,

integrated replicated storage supports, and the mechanisms to

allow partitioned operation. The file system is a functional

superset of the UNIX tree structure naming system. LOCUS has

extended this in three areas. First, all file system objects on

all machines are represented by the single LOCUS tree structure.

Since LOCUS names are fully transparent, it is not possible to

determine the location of a resource within the network from its

name. Second, as noted earlier, LOCUS files are replicated. It

is the system's responsiblity to keep all copies current and

assure that access requests are provided by the most recent

version. Third, LOCUS provides a "multiple reader, single

writer" synchronization scheme.

5-16
The LOCUS approach to support remote service was to build a

fast but limited process facility called server processes.

Network requests are enqueued for processing by each server

process which in turn serially dequeues each request. This

design permits efficient network request processing, keeping

protocol overhead low. LOCOS' design also includes a "filter" to

discern whether a request is for the local or a remote site.

This concept has also been implemented by Microsoft in the form

of a "redirector". A description of this implementation is

, ii%r -

provided in Section 5.2.9 - MS-NET 1.0. Local site requests

bypass message processing logic usually performed for remote site

access and instead, are handled immediately the the local system

call processor. This philosophy is in tune with LOCOS' emphasis

on the importance of system performance.

Atomic file commit is an important concept in LOCOS.

Essentially, this means that all file changes are handled

atomically. No changes to a file are permanent until a commit

operation is performed. Commit and abort (to undo changes back

to previous commit) system calls are supplied. Closing a file

commits it. Opdates are done using a "shadow page" mechanism

which keeps copies of pages in the fil e whic h have been

updated/changed. These shadow pages are marked in order to track

__^

the new/old information. At commit time, the old pages are

replaced by the new ones. To abort a set of changes, pages on

disk remain on disk and shadowed disk page space is deallocated

for reuse . Files may also be share d in LOCOS and a

synchronization mechanism for doing so in a networked environment

using normal ONIX semantics is supported.

5-17
LOCUS supports interprocess communication with the network

equivalent of UNIX local pipes (i.e., one way communications

between programs). Names and unnamed pipes are supported

transparent to the user and are implemented as FIFO circular

queues. Intertask communications is accomplished by writing to

and reading from pipes. If a reader task is asleep (i.e.,

suspended) on an empty pipe, it is awakened (i.e., put into

active state) when a message is written to the pipe.

Remote tasking is also supported by LOCUS. The major

process control functions have been extended from UNIX. The UNIX

"fork" call creates a new process running the same program as the

caller. The UNIX "exec" call replaces the code and date of a

running process with a new program and data image. LOCUS

utilizes forks to cause a new process to be created locally or

remotely. Exec has been extended to allow a process to migrate

to another site as it replaces its image. "Run" is a new (LOCUS)

system call which creates a new process and invokes a new program

from it immediately. This may be done locally or remotely.

Finally, to permit a process to change its execution site, while

in the midst of execution, LOCUS has added a fourth call;

"migrate". The user can influence and/or control process

execution sites. Default execution is the user's local site.

Via the "setxsites" system call, the user provides specifications

required of a site for process execution, a list of sites to be

tried in order, or a list of site types (e.g., DEC/VAX, M6800,

IBM/PC, etcetera).

The transparency of LOCUS has also been applied to network

5-18
topology. The system strives to insulate users from network

reconfigurations. Key to this is the assumption that the network

is fully-connected (the underlying LOCUS protocols assume this!).

Heterogenous compute r environments are also handled

transparently by LOCUS. LOCUS may be ported to other machines in

a manner similar to porting UNIX. It is written in a strongly

typed version of the "C" programming language to minimize machine

dependencies. LOCUS handles byte recording (if necessary) for

different word (2 byte) and long word (4 byte) representations;

ASCII/EBCDIC and similar data translations; contains functions in

its kernel to transform incoming network message formats.

LOCUS also supports a product, PC-Bridge, which enables PC

users to communicate with mainframe hosts. At present, only AT&T

SB-series host processors are supported. Hosts must be equipped

with either the UNIX or LOCUS distributed UNIX operating system.

Personal computers must run in a PC-DOS or MS-DOS environment

under Version 2 or subsequent releases. Utilizing an Omninet,

Ethernet, or RS-232 facilities, PC-Bridge enables the PC to

utilize the mainframe as a file server. There are four software

elements which comprise this package.

1. Bridge - Runs on PC - it logs-in and connects user to

mainframe host.

2. Bridge Server - Runs on host - it translates and performs I/O

requests from the PC.

3. Bridge Handler - Runs on PC - it redirects all system calls

to MS-DOS on the host as appropriate.

4. Terminal Emulator - Emulates terminals connected to the host.

5-19
This section has attempted to describe the salient

characteristics of the LOCUS architecture. Virtually all of the

NOS functional service characteristics identified in Section 4

are supported by LOCOS. Although it does not conform to the

ISO/OSI model, the LOCUS designers have made the conscious

decision to trade this layered approach for system performance

considerations. The reader is referred to "The LOCUS Distributed

System Architecture" manual (Edition 3.1, June 1984) which

provides an excellent description of the LOCUS internals.

5.2.2 OniverseNet

Charles River Data Systems (CRDS) of Framingham, MA sells a

networking product, UniverseNet, which implements all seven

layers of the ISO/OSI model. UniverseNet applications layer

software invokes UN/System V or UNOS, both UNIX compatibles, to

provide operating system support and implement all other lower

layers of the model. Figure 5-1 illustrates the UniverseNet

architecture with respect to the layered OSI model and the 0/S

kernel. Computers (i.e., nodes) communicate via the Ethernet

protocol. The CRDS Universe 68 Super microcomputers from a

homogeneous (MC68000-based).networking environment for users

running UniverseNet. Computers from other vendors which have

implemented OSI communications protocols may communicate with

those on the UniverseNet via a LAN. UniverseNet has run under

the auspice s of NBS test and ha s approve d standar d

implementations for protocol levels 1-L4 including Class 4

Transport protocols. In keeping with the OSI philosophy, CRDS

provides network interfaces to the following protocols: TCP/IP,

5-20
Virtual

Terminal

^ \

Electron ic

Mail

Mcnafiag

/ .

^--*

Application! Layer

UNOS

KERNEL

Pnttotation Layer

(allowt UNIX file iy<tem interface)

PhyiicjJ Layer

-

— Local et Loaf-haul Network —

FIGURE 5-1

UniverseNet Layers in the UNOS Environment

5-21
Table 5-1

y»W»Jos

I/O redirection

File independent I/O

Pipe process management

Multi-server queues

Named pipes

Signal/alarm facility

Process synchronization

Multiplexed files

Keyed file facilities

DBMS facilities

Max lile size (bytes)

File name length (bytes)

File allocation

Record/file locking

Multi-level directories

Bad block handling

Exception handling

Symbolic debugger

Graphics packages

Text formatting

Typesetting package

Compiler writing aids

Environments

Process locking

User controlled priority

scheduling

Heuristic timesharing

scheduling

Shared text

Shared data

User support

Update service

yes

yes

yes

yes

yes

yes

yes

no

opt.

opt

2i.

30

Bit

map

yes

yes

yes

yes

w/

Macros

no

yes

opt

opt.

yes

yes

yes

yes

yes

yes

yes

yes

yes

yes

yes

no

no

ltd

no

no

no

no

2"

14

Linked

list

no

yes

no

no

ltd

no

yes

no

no

no

no

no

yes

yes

no

no

no

yes

yes

yes

no

no

yes

no

yes

yes

no

2»

14

Linked

list

no

yes

no

no

ltd

yes

yes

yes

yes

yes

yes

no

yes

yes

no

no

no

yes

y«*

yes

no

yes

yes

no

no

no

no

2"

14

Linked

list

no

yes

no

no

yes

yes

yes

yes

yes

yes

yes

no

yes

yes

no

no

no

yes

yes

yes

no

yes

yes

ltd

no

-no

no

2»

14

Linked

list

no

yes

7

no

yes

7

yes

yes

yes

yes

yes

no

yes

yes

no

ltd

ltd

5-22
XNS, BSC, and SNA. Salient features of OniverseNet are listed

below:

o Maximum efficiency via kernel integration with UN/System

V or DNOS kernel.

o Applications include: electronic mail, messaging,

printer sharing, file transfer, and remote command

execution.

o Distributed File System

o Written in "C" -^--,

o LAN and WAN network support

o Built-in test facilities

Key to universeNet are the UN/System V and UNOS Operating

Systems. UN/System V is derived from UNIX System V under license

fro m AT&T. It includes the entire UNI X System V program

development tool set. UNOS is a CRDS proprietary UNIX-compatible

0/S. Its key feature is the incorporation of real-time extensions

not available with UNIX. UN/System V and UNOS share the same

device drivers, file formats, and object formats to facilitate a

fully transportable environment. Table 5-1 depicts the salient

features of these two operating systems as well as other UNIX

implementations. Both implementations of these two operating

systems are linked to the program code of UniverseNet layers 1-5.

The system thus treats the network layers as a device accessible

via a standard I/O driver. Network performance is thus maximized

via this integration of code since it has direct access to system

calls and can share data without passing it from layer to layer.

Network access to both programs and the file system is identical

5-23
to any other device access. Existing standard OPEN, CLOSE, READ,

and WRITE system calls can still be used without modification.

As with LOCUS, UniverseNet takes advantage of the UNIX pipe

facility. Pipes have two implicit limitations:

o All processes in a pipe must be initiated by the same

parent process, and

o byte streams in pipes consist of data with no status or

identification.

CRDS notes that these limitations restrict a server process

since it cannot use pipe input to handle multiple processes or

processes that were not connected to it at the beginning of its

operation. UNOS provides a queue package for server - user

situations, event counts for process synchronization, and a

numbe r of extensions for production oriented environments to

overcome these pipe limitations.

Event counts are the focal point for scheduling and

synchronization in the UNOS kernel and user process. They are

dynamically defined resources developed to meet the needs of

network synchronization. Event counts may be opened by unrelated

processes and used concurrently by many processes. They may be

used as counters whose value increases monotonically. This

facilitates indications of event transitions as well as keeping a

record of the number of occurrences of an event. They may also

be used for process synchronization such as access to critical

resources. By waiting for one or many events, event counts may

also be utilized for inter-process communication. Interprocess

communication facilities are built such that the two processes

may be local or based on two different machines. This is

supported by developing a close relationship between local

5-24
interprocess communications capabilities and the session control

layer (L5). Finally, since event counts are not owned by any

single process, they may be monitored independently by other

processes which take appropriate actions based upon their value.

An additional UNOS extension is file locking. Any process

can lock any region of a file. Processes are ensured of reading,

updating, and writing any type of logical record without the risk

of race conditions. Processes may also be locked (i.e., memory

resident) to assur e fast response. Pre-emptive priority,

scheduling and fast context switchin g are two additiona l

enhancements supplied by UNOS.

The followin g paragraphs summariz e the UniverseNe t

Applications layer software supplied by CRDS.

Electronic Mail enables users to transparently create, edit,

send, receive, and handle messages. This is done utilizing a

'mailbox1 structure integrated with UniverseNet. Certified mail

can be sent which sends a verification message to the sender.

Electronic Mail is invoked with the email command and

permits users to send, receive, and handle messages. The mailer

allows users to perform the following functions:

o Create and send messages to yourself and to other users,

o Read and edit messages,

o Respond to messages,

o Copy messages to files and printers,

o Create and use additional mailboxes as an on-line filing

system,

o Create and use distribution lists.

Messaging is invoked with the WRITE command. Users can thus

5-25
send a message directly to anyone logged on to the network. This

provides short immediate notice messages that don't wait for

users to check their mailboxes.

Systems in the CRDS UniverseNet can share resources (e.g.,

printers) for maximum efficiency and economy. Systems can be

configure d to use any printe r in the networ k for default

printing.

The file transfer application provides the basis for a

distributed file service in the UNOS operating system kernel!

The protocol is a subset of the remote file access protocol

defined by ISO.

Remote execution application permits users connected- to

UniverseNet to send commands to remote systems for execution on

that system.

A distributed fil e system links the files on several

machines through presentation control (from the OSI reference

model's layer 6). These linked files then appear to be on one

machine. Programs can reference files without regard for actual

file location.

UniverseNet development for this featur e allows users to

reference UNOS features (such as event counts) across machines.

Once the UniverseNet distributed system links the application

with the remote file system, only UniverseNet (and the system

administrator) know the actual file location.

UniverseNet allows development of a virtual terminal

application that could eliminate cable stringing for attaching

terminals to other systems. Such an application would allow

5-26
terminals to interact with remote systems as if they were

physically attached.

5.2.3 Sun Microsystems NFS 2.0

NFS 2.0 is a product scheduled for release in the June 1985

timeframe by Sun Microsystems, Inc. of California. NFS utilizes

the Ethernet protocol to enable Sun Workstations, DEC VAX, and

IBM PC computers to communicat e in primaril y UNI X 0/S

environments. Mt. Xinu, a California based company, recently

announced its implementation of NFS on VAX computers which run

UNIX 4.2BSD. Non-UNIX operating systems (e.g., VAX/VMS) from

other vendors are also supported. It is intended for use in a

networked environment of multiple server and client workstations.

Salient features of NFS 2.0 are:

o heterogeneous computer environment support,

o transparent access to shared network resources,

o shared access to one original file copy for all users,

o remote procedure call service (RFC),

o external data representation package (XDR).

NFS does not conform to the ISO/OSI model standard but,

instead, has implemented its own protocols. NFS is based upon

the UNIX 4.2BSD implementatio n (see Section 5.2.5 for a

description of 4.2BSD features) and resides in the UNIX kernel.

The remainder of this section addresses the three facets of the

NFS implementation: the network file system, remote procedure

call, and external data representation. At present, since this

is a soon-to-be-released product, CTA was unable to obtain

information on NFS other than the proposed NFC, RFC, and XDR

5-27
standards.

NFS permits file system sharing in a heterogeneous network

of machines, operating systems, and networks. "Servers" are the

machines in. the network which supply resources to "client"

machines which access the network resources. Users are logged-in

at clients which in turn run applications programs. VNODES (a

re-implementation of UNIX inodes) supply the interface to a

particular type of file system (called virtual file systems;

VFS's) such as UNI X or DOS. The NFS interfac e define s

traditional file system operations for reading directories,

creating files, reading and writing files, and setting file

attributes. A UNIX-style file protection is implemented by

making use of RFC authentication mechanisms.

RFC is implemented on top of TCP/IP transport protocols. It

is similar to the local procedure call model where the caller

places arguments to a procedure; transfers control to the

procedures; and eventually receives control back from the

procedure with its associated results. In the remote version of

the procedure call, NFS sends a call message to the server and

waits for a reply message. Once received, the message results

are extracted and the caller's execution is resumed. The NFS RFC

mechanism is applicable for both local and remote process

intercommunication.

The XDR is a library of routines which describes arbitrary

data structures in a machine-independent fashion. It also

supplies primitive s to enable users to writ e the own XDR

routines.

5-28
5.2.4 The Newcastle Connection

The Newcastle Connection (TNC) is a product of Advanced

Microelectronics, Ltd. . It is available from Portable Software,

Inc. in Redwood City, CA. Key feature s of the Newcastl e

Connection are:

o UNIX to UNIX Networking

o Resides between Kernel and shell

o Appears to Kernel as an Application Program

o Appears to Application Program as an unchanged Kernel

o Independent of Hardware Network Communications

o Provide s a distribute d capabilit y whic h is

functionally indistinguishable from a conventional single

processor UNIX system

o No modification of existing Source Code necessary to

operating System or user programs

o Provides means to read/write any file, use any device,

execute any command or inspect any directory regardless

of which system it belongs to

o Namin g structure s for files, devices command s and

directories of each component UNIX System and joined

together into a single naming structure

o Operates under UNIX and UNIX look-alikes

o Directories are available across machines

o Shell commands and System calls apply unchanged across

Inter-Machine Communication

The implementation philosophy of TNC is the addition of a

software subsystem to standard UNIX. Then, in contrast to the

LOCUS or UniverseNet packages, no modification to the UNIX kernel

has been performed. By adding TNC software subsystem on top of

the UNIX kernel to host computers running UNIX, and connecting

them in a local area ring network, users may communicate, share

files, execute remote commands, and in general are provided with

5-29
a distributed computing capability.

All of the standard UNI X conventions are applicable

transparently to the user including:

o file and device access, naming/ and protection,

o interprocess communication, and

o I/O redirection.

The implementation is not specific to any particular UNIX

but is instead applicable to any UNIX look-alike which provides

system call level compatibility with the original.

TNC filters out system calls that have to be redirected to

another UNIX system and it accepts system calls that have been

received from other UNIX systems on the network. A remote

procedure call is the key mechanism for communications between

the Connection layers on the UNIX systems. The Connection layers

accepts names and, by use of mapping tables, determines whether

an objec t is local or remote . It also selects actual

communications paths and manages alternative routes transparent

to the user and his program.

5.2.5 Berkeley UNIX 4.2

Version 4.2 of the Berkeley Software Distribution of UNIX

(UNIX 4.2BSD) enhances the basic UNIX capabilities with:

o virtual memory support,

o faster and more flexible file access,

o network file and printing services,

o interprocess communication supporting a multi-window

interface,

o foreground-background job control,

5-30
o automatic reboot after system crashes, and

o a new symbolic debugger.

UNIX 4.2BSD represents the results of a DARPA funded project

to further develop the 3BSD (i.e., third BSD for UNIX) system.

These enhancements were begun in 1983. A brief description of

4.2BSD's salient characteristics and its networking enhancement

follows.

Virtual memory support allows processes as large as 16

megabytes to be run under 4.2BSD. Two processors supporting this

£' • • -

capability are the DEC VAX ll/7xx and Motorol a MC68020 .

Increases in the number of users time sharing the CPU and overall

system responsiveness can be realized.

A new fil e system implementation is the second key

enhancement included in 4.2BSD. Better structures and algorithms

have improved overall file I/O performance. Poor layout of disk

blocks and I/O operations involving a maximum of only 512 bytes

on traditiona l UNI X systems wer e inadequat e for large

applications or networking environments. UNIX 4.2BSD takes

)

advantage of disk geometry and rotational latency characteristics

to build in improved performance. It places consecutive data

blocks and related indexing information in neighboring areas on

the disk. By storing directory files on a single track or

cylinder of the disk, seek time is substantially reduced, thus

decreasing overall file access time. File access has been

further reduced by minimizing multiple seek and I/O operations to

retrieve large files. This is due to the fact that most 4.2BSD

files are stored in 4096 byte blocks versus the traditional UNIX

size of 512 bytes per block. A 32KB file in traditional UNIX

5-31
required 64 distinct I/O operations of 512 byte data transfers.

Total read time is on the order of two seconds or more. By

taking advantage of the 4.2BSD disk I/O enhancements, this time

can be reduced to about one tenth the two second file access

time.

Networking feature s in the UNIX kernel are one of the most

prominent enhancements to standard UNIX. UNIX pipes support

byte-stream communications between processes on a single machine,

however, they do not support message-oriented communications nor

communication s wit h processe s on othe r hosts. Both

unidirectional datagrams and bidirectional virtual circuit.,

connection s ar e supporte d i n 4.2BSD. Th e forme r ar e

unacknowledged and thus potentially unreliable messages whereas

the latter are acknowledged and thus reliable messages. Data in

the messages are not interpreted by the system. It is the

responsibility of the application software to perform data

conversion, representation, or transformation as required.

Communication s in 4.2BSD take place between "sockets".

SOCK_DGRAM and SOCK_STREAM define datagram and virtual circuit

socket types respectively. Server sockets are created and then

named in order for processes to contact and use the service.

Names are used whenever message exchange between sockets takes

place or to establish a connection. The call

S = SOCKET (DOMAIN, TYPE)

creates the socket and

BIND (S, NAME)

associates an address to the socket.

5-32
Datagram-based network services may create sockets to

send/receive datagrams using the

SENDTO (S,MSG,TO)

and

RECVFROM (S,MSG,FROM)

system calls respectively: where S is the socket to send or

receive the message; MSG is an array of bytes; and TO/FROM is the

socket address. Virtual circuits use system calls to establish a

socket, bind it to an address, then issue calls to queue

. .. ... .;*'•" '."•;"

connections (using LISTEN) and service connections (using

ACCEPT). CONNECT-CONFIRM and CONNECT-REFUSE messages notify

users of a successful or unsuccessful enqueuing respectively.

UNIX 4.2BSD is marketed by several vendors, one of which is

MT XINU of Berkeley, CA.

5.2.6 Network Research Corporation - FUSION

FUSION is a networking software package developed by Network

Research Corporation (NRC) of Los Angeles, CA. It is developed

in the "C" programming language and is available for IBM-PC,

M68000, VAX, PDP-11, 16032, and 8086 processors. FUSION supports

UNIX (4.1BSD, 4.2BSD, V7, Systems, System 5, Xenix, Ultrix, and

Venix), MS and PC-DOS, and VAX/VMS operating systems.

FUSION has implemented both<the TCP/IP and XNS protocols and

runs in an Ethernet environment. Ethernet controller cards

developed by 3Com, Interlan, Ungerman-Bass, and CMC are among

those currently supported.

FUSION implements LI and L2 of the OS I model by means of

Ethernet. The FUSION Socket Manager is responsible for L3 and

5-33
L4. It is integrated into the local 0/S kernel as a device

driver and thus does not require any modifications to the local

0/S code. OS I layers 5-7 are represented by FUSION'S Remote

Execution and Virtual Terminal facilities. The FUSION Socket

Manager is the interface between the host CPU and the network

controller. It also performs as the interface between

applications programs and the networking package.

User communication, job migration, data migration, network

control, and common services identified in Section 4 of this

report are all supported in varying degrees by FUSION. Some of

these features are inherent in the support supplied by the local

operating system (e.g., networking facilities offered in UNIX

4.2BSD) .

In the domain of User Communication, many features of UNIX

4.2BSD (see Section 5.2.5) facilitiate the message handling

service. Terminal handling service is supported by FUSION'S

cirtual Terminal capability. For example, a personal computer

under MS-DOS can function as a terminal to a VAX running UNIX or

VMS. When using the Virtual Terminal command, the local computer

becomes a standard terminal. The user then functions under

control of the remote 0/S and thus uses its set of commands.

Job Migration services supported include interprocess

communication (4.2BSD support) and remote procedure call.

Commands executed remotely may be handled by a processor with a

different CPU, different operating system, or different network

hardware.

Data migration capabilities offered by file services and

5-34
data representation services are also supported. A single file

or complete directories of files may be transferred between

different computers and operating systems. FUSION supplies a

utility program which reconciles differences in file formats when

transferring, for example, a file between a MS-DOS and UNIX-based

system.

FUSION offers various network control capabilities primarily

as network management services. Network performance analyses and

traffic monitoring are supported by the product. These utilities

provide the user with a chart of network activity and calculate

network data transfer speeds.

As part of the Transport Services, NRC is currently working

on an implementation for the TCP/IP protocol. In addition, they

plan to offer a gateway between TCP/IP and XNS.

Users are able to develop and add applications programs to

the FUSION library routines. These routines are implemented so

as to be fully compatible with the network system calls of UNIX

4.2BSD.

5.2.7 INTEL OpenNet

The Intel OpenNet architecture provides file service between

hosts running the XENIX, iRNX, and PC-DOS operating systems.

This architectur e is based on the ISO Open Systems

Interconnection Reference Model although not all layers are

supported. The architecture consists of the following layers:

o layers 1 and 2 ETHERNET (TM of XEROX Corporation),

o layer 3 Null,

o layer 4 ISO Class 4 Transport protocol,

5-35
o layer 5 Intel Session protocol,

o laye r 6 Nul l (althoug h Inte l claims to hav e a

presentation layer protocol, the functions included in it

appea r to be application s functions, not dat a

representation functions,

o layer 7 Intel Network File Access protocol.

This architecture is illustrated for each operating system

in Figure 5-2. When this architecture is implemented, layers 1

to 4 reside on an outboard communications board while layers 5 to

7 reside on the host. For PC-DOS, layers 1 to 4 execute on an

Ungerman-Bass Networ k Interfac e Unit card hosted in a EC

expansion slot while layers 5-7 execute on the PC native 8088

CPU. For XENIX and iRMX, layers 1-4 reside on the SXM 552

transport and layers 5-7 run under the XENIX or iRMX operating

systems in the host. The typical host is an i310 computer which

interfaces the SXM 552 over a MULTIBUS (TM of Intel Corporation).

The relatively simply Intel session layer is responsible

for mapping symbolic names into network addresses and mapping

sessions into transport connections.

The file service enables users to read, write, open, close

and manipulate file from a remote location. Thus, a true file

access is provided rather than disk sharing or simple file

transfer. The salient aspects of the network file access service

are:

o hierarchical file structure,

o use of pathnames with the name of the system on which the

file resides as the first element in the name,

o mapping of server's fil e protection feature s to

consumer's operating system format,

o record level locking,

5-36
MS DOS OPENNET ARCHITECTURE

*4*<<*Ork.M*

cor>tu***<

««nu OtxnNtl Mtxon Uftf

XENIX OPENNET ARCHITECTUKE

iRMX OPENNET ARCHITECTURE

FIGURE 5.2: INTEL OPENNET ARCHITECTURES

5-37

irce: "Systems G> Software"

March 1985
o file sharing.

A remot e print service is also provide d for these

operating systems.

In addition, selected features of the operating systems will

operate across the network when communicating with the same

operating system at the remote location. For example, a XENIX

system can exchange mail or execute batch jobs. Stream files

similar to XENIX pipes can be exchanged using iRMX.

The utility of the OpenNet is in two areas. First, as a

retrofit to existing operating systems, it provides networking

capability between incompatible systems. However, OpenNet is not

a single software module transportable between systems. Second,

the XENIX version of OpenNet has the potential to be a portable

network operating system. This version is written in "C" and

source licenses are available. In addition to running on the

Intel 310 Multibus computer, it could be ported to other systems

supporting XENIX such as a PC/AT and VAX class machines.

5.2.8 NOVELL NETWARE/86

Netware is a local area network operating system (LANDS)

designed for the IBM PC (and compatibles) that can be configured

to work with a variety of (over 10) LAN hardware. It does not

require a specific PC-LAN board, although Novell does sell its

own networking hardwar e under the name Netware/86.

This section summarizes the Netware/86 product which uses an

IBM PC-XT or IBM PC-AT as a central file server. Novell claims

to have adapted the Netware/86 software for the following PC-LAN

boards:

5-38
Corvus Netware/0 (Omninet)

3Com Netware/E (Etherlink)

Proteon Netware/P (Pronet)

Davong . Netware/D

Nestar Netware/N

Orchid Tech Netware/PC (PCnet)

The PCnet is also sold by AST, Santa Clara Systems and IDE

Associates.

Netware is an example of a Dedicated Server. There is one

distinct machine which is a dedicated server ~and other distinct

machines which are user machines.

Novell provides its own proprietary multi-tasking Network

Operating System that runs on the IBM PC and converts it into a

multi-tasking LAN server. This server provides the following

functions:

o File services,

o Print services,

o Interprocess Communication (Pipes),

o Message services,

o Directory services,

o Network Management and File Security.

At this time, Netware does not provide:

o Remote Procedure Call,

o Job Transfer and Manipulation,

o Data Representation Services,

o Terminal handling,

o Recovery Services.

5-39
All Netware/86 networks require the following components:

o DEDICATED PILE SERVER - The PC used as the file server

may be an IBM PC-XT, IBM PC-AT, IBM PC with a third-party

"hardware compatible" hard disk expansion on any one of

serveral "IBM PC compatibles" with a hard disk. The

maximum disk size currently supported by Netware/86 is

292 MBytes. A 20 MByte File Server requires a minimum of

380 KByte RAM. An additional 1 KByte RAM is needed in

the File Server for each additional MByte of disk storage

over 20 MBytes.

o PC Workstations - with at least 128 KRAM

o One Network Communication Card for each PC

A block diagram of a typical Netware/86 configuration is shown

in Figure 5-3.

The Netwar e File Server is a superset of the PC-DOS file

system. It supports all PC-DOS file commands. A program can

access local disk files (i.e., a disk attached to the user workstation) or network disk files (i.e., files residing in the File

Server).

Network files can be opened either for exclusive use of a

particular program (private files) or in a non-exclusive mode for

concurrent shared usage by several programs. Multiple programs

can open a file simultaneously in read-only mode as a private

file. Netware provides file-sharing synchronization functions at

several different levels:

1. TRANSACTION UPDATE/PROCESSING:

This metho d allows application softwar e to obtain

exclusive control of a set of non-exclusive files when a

5-40
transaction update is to be performed. The exclusive

• [

control is temporary and must be released after each

transaction. This technique avoids deadlock conditions

that may occur if an application relies on record

locking.

2. FILE/RECORD LOCKING:

This mechanism allows different applications to modify

records of the same file concurrently by giving an

application exclusive access to particular record(s) as

needed.

An application can specify an entire set of records to

the server befor e actually requesting that the lock be

implemented. The server can therefor e ensure that all

records needed by the application are available before a

lock is put on them. This avoids deadlocks between

processes whic h may be workin g on the same set of

records, e.g., two different order processing clerks

sharing a common inventory file.

Netware allows application to a lock record(s) for query

purposes only. Thus, multiple applications can lock the

same records for query. This assures that the selected

data is not modified until the lock has been released.

3. SEMAPHORES

Netwar e supports a softwar e library whic h call on

application programs to manage record locking themselves

by using general-purpose semaphore mechanisms.

5-41
ORIGINAL PAGE IS

OF POOR QUALITY

TcraUutor

FIGURE 5.3: NETWARE/86 - CONFIGURATION EXAMPLE

5-42
Several features maximiz e the performanc e of shared file

service. Specifically, Novell claims that use of Disk Caching,

Directory Caching and Hashing and Elevation seeking results in

the highest performance File Server for PC LAN marketplace.

Netware requires a user password for logging in, i.e.,

accessing the network server for the first time. It furthe r

allows users to set passwords within MS-DOS volumes on individual

directories as well as individual files. It does not provide

security at record or field level. Also, there is only one level

of security. If a user has access to a file and then one can

perform any operation on it.

Other file services offered by Netware are:

NCOPY: File-to-file copy within the file server without

sending the file to the user station

SHOW Commands: To display individual directories and

parameters of a particular file such as whether

the password has been set.

WHOAMI Commands: Provides the user's network address.

Netware supports a flexible print spooler. It can support

up to five independent spooled printers, although the PC-XT is

limited to a maximum of three due to hardware restrictions. The

spooler allows a user to:

set forms,

- change queues,

reroute a print request from one printer to another,

kill a request before or during printing,

rewind a print request certain number of pages,

start and stop a printer,

- spool (print) existing files,

5-43
get printer status.

Netware supports the following messaging services:

send/receive broadcast messages,

- send/receive personal message,

- send message to system console.

Netware supports a "Message Pipe" for direct communication

between two or more processes through the Network Server.

Novell has recently announced its intention to support MSDOS 3.1. In particular, it claims that the Advanced Netware will

be compatible with MS-DOS 3.1 and provide a product superior to

the Microsoft MS-Net (described in next section). The product is

under development and as such details are not available at this

time.

5.2.9 Microsoft/IBM-PC Network

The Microsoft MS-NET is the most recent product introduced to

the marketplace by IBM and Microsoft. IBM is the first OEM

customer of the software and it has packaged it with Network

hardware supplied by Sytek and sells it under the name PC Network

(which is different from PC Cluster) First retail shipments of

the product were made in May 1985.

Microsoft claims that the following network vendors will be

supporting MS-NET:

AST Research

Corvus Systems

Davong Systems

Nestar Systems, Inc.

Proteon, Inc.

5-44
Ungermann-Bass

Western Digital

Interlan, Inc.

3COM

Techmar

Orchid

The PC Networking software is being sold as two separate

packages.

MS-DOS 3.1 is the most recent extension of MS-DOS which

provides support needed for networking and expands the file-name

structure to include addressing multiple nodes across the

network. IBM's version is called PC-DOS 3.1 and includes certain

additional utilities specific to the IBM PC. Both MS-DOS and PCDOS 3.1 provide an interfac e (INT 21 hex) to the network

redirection program which recognizes requests for I/O as local or

remote. It can be viewed as the Client Software.

MS-NET 1.0 is an extension of MS-DOS 3.1. It provides an

operating environment that implements the session layer (layer 5

of the ISO model) and has a file and print server at layer 7.

The presentation layer (layer 6) is not implemented (i.e., a null

layer). The server runs as an application in a server machine

and provides fil e and print services to the network . In

addition, it includes the Redirector and several networking

utilities.

The Microsoft Server requires dedicated system resources in

the single-tasking MS-DOS operating environment, whereas the IBM

PC-Network Program is a non-dedicated server.

5-45
In addition, the IBM PC-Network Program includes a Message

Service application that enables users to send short messages

between workstations.

The IBM.PC Network hardware consists of an adapter (in each

PC) and a broadband head-end frequency translation unit. The PCNetwork adapter supplies processing for five of the seven OSI

layers, extending from the physical layer up through the session

layer. The NET BIOS handles the interface between the adapter

and the host computer (INT 5C HEX). As of May 1985, IBM is the

only vendor delivering products based on the MS-DOS 3.1 and MSNET 1.0. It is not clear whether other vendors will use the

Microsoft session layer software or build it in the adapter to

minimize load on the main processor. MS-NET does not have a NET

BIOS, however, it supports the 5C interface. These differences

are shown in Figure 5-4.

Since the IBM PC-Network is the only released program at this

time, the following description is specific to it.

As indicated, the IBM PC Network Program includes the Server,

the Redirector and a Message Service. The server is nondedicated and as such, can reside in any user station. Each PC

(node ) on the networ k must have PC-DOS 3.1 and PC-Net 1.0

software loaded. However, the individual user can decide, where

resources connected to his/her PC can be shared by other users or

not. A user must have a local hard disk to allow sharing of

devices attached to the particular node. However, a node without

a hard disk can access shared devices on other nodes. Also, a

diskette drive on a node with hard disk can be shared by other

nodes. A maximum of 25 nodes on the network can use the disks,

5-46
SERVER

21

REDIRECTOR

INT 2A

IBM

SESSION

IBM

ADAPTER

CARD

MS SESSION

— — INT 5C

NET CARD

INT 5B .

(MS TRANSPORT

INTERFACE)

FIGURE 5.4: MS-NET

5-47
directories and printers that are permitted for sharing. A

particular user can access up to 32 (local or remote) disks,

directories and printers. Thus although the PC-Network can

connect up to 72 nodes (or up to 1000 nodes using more expensive

hardware supplied by SYTEK), a user cannot access all the shared

resources on the network at any one time. This is not usually a

problem in the PC environment since the PC imposes more severe

restrictions due to its limited memory capacity (buffe r space)

and single-task operating system (PC-DOS).

USER COMMUNICATION: The PC-Network provides the following user

communication services:

o Message Handling

- Send/Receive Messages

Pause/Continue Receiving Message

Save/View Messages

- Forward Messages

o Print Services

- Share a Print Queue

Pause/Continue using a Remote Print Queue

- Stop/Restart a Shared Printer

- Check/Change Print Queue

- Change Print Size for a Shared Printer

- Print a Separate Page (between files)

The PC-Network does not have any facility for Terminal

Emulation and Conferencing.

JOB MIGRATION: The PC-Network does not provide any job migration

services.

DATA MIGRATION; The PC-Network provides sharing of files or a

group of files (contained within a directory) at the file level

only i.e., only one user can access (open) a shared data-file at

any one time.

5-48
The PC-Network does not provide any data-migration services.

NETWORK CONTROLt The PC-Network provides a large set of utilities

for Network Management:

Display names that can receive messages at the user's

node,

Display shared devices at the user's node

- Display remote devices being used by the user

Pause/Continue using Remote Disk/Directories

Pause/Continue Sharing devices at the user's station

Save/Cancel the user's Network Set-up

The PC-Network does not offer any facilities for security and

centralized directory services. In fact, it does not seem to

provide any metho d for a user to determin e the networ k

configuration (i.e./ who are all the users and resources on the

network). It seems that a user must have prior knowledge of

other users and shared resources on the network, in order to

communicate with other users or access remote resources.

The PC-Network is a new product and as such, not much is

known about its reliability, performance and other limitations.

Also at this time, its functionality is significantly inferior

compared to Netware which has been on the marke t for over two

years.

5.2.10 DECnet

DECnet is a family of hardwar e and softwar e communications

products offere d by Digital Equipment Corporation (Maynard,

Mass). It is currently in Phase IV development and supports many

of the functional characteristic features of a NOS identified in

5-49
Section 4 of this report. DECnet is based entirely on the

Digital Networ k Architectur e (DNA). DNA, a propriet y

architecture, is similar to the seven layer ISO/OSI architecture

model. The relationships between the OSI and DNA layers are

illustrated in Figure 5-5. DNA modules resident in a typical

DECne t node are illustrated in Figur e 5-6. Node-to-node

communications protocols are shown in Figure 5-7.

DECnet is designed to run only on the DEC family of computers

and operating system environments listed below:

CPU 0/S

VAX VMS

PDP-11 RSX, RT-11, RSTS

DECsystem-10,-20 TOPS-10, TOPS-20

MicroVAX MicroVMS, VAXELN

Professional 350 P/OS

DECnet LAN's are based upon the Ethernet link protocol and

support up to 1023 nodes in the DNA environment. Phase IV

development efforts will enhance some of the DNA features

including the support of up to 64,000 nodes in the network.

DECnet is an example of a propriety networking architecture

supporting a homogeneous family of processors. Any combination

of DEC computers and their associated native operating system is

supported by DNA. Communication between DNA-based DEC computers

and computers supplied by other vendors is accomplished by means

of gateways. The DECnet/SNA Gateway enables DECnet nodes to

communicat e wit h IBM System Networ k Architectur e (SNA)

environment processors. The second alternative offered by DEC is

the DECnet Router/X.25 Gateway. This enables DECnet nodes to

5-50
communicate with processors which support the X.25 protocol on a

packet switched data network.

DNA's architecture parallels the seven layer ISO model.

Although it is not specifically named an NOS by DEC, DNA

does support many of the major high-level network functions

characteristic of an NOS. Some of these functions include:

o Task-to-task Communication,

o Remote file and record access,

o Terminal-to-terminal communication,

o Network virtual terminal,

o Problem isolation and network management,

o Downline loading,

o Upline dumping.

The salient implementation characteristics of some of these

high-level functions are described below.

DECnet enables two programs or tasks running on different

nodes in the network to exchange data over a logical link.

Interprocess communicatio n is implemente d muc h like I/O

operations; the logical link is similar to an I/O channel over

which both programs can transmit and receive data.

DECnet's remote file and record access enables nodes"to

open/close files, create/delete files and read/write remote file

records. Nodes may be differen t (DEC) processors runnin g under

differen t (DEC) operating systems. DNA/ISO layer 7 softwar e

enables users to invoke an interactive Networ k File Transfe r

(NFT) utility. A user may invoke NFT from any terminal and thus

access and manipulate remote files. Network File Access Routines

5-51
ORIGINAL PAGE IS

OF POOR QUALITY

Architecture Layert

ISC) DNA.

AppluMlion

I'resoilJlion

SfSSIOn

Transport

Network

O.KJ Link

I'liysiol Link

7

1,

£

f

J

i

/

U*T

Network

MjllJm'MK-IK

Nctwtirk

Application

Session (x)nlrol

Hnd-to-End

Oiniinunicalion

Uonting

Oati Link

I'liysicjl Link

FIGURE 5.5: ISO-DNA ARCHITECTURE

Source: "Digital's Networks: An

Architecture with a Future" -

DEC

5-52
ORIGINAL PAGE IS

OF POOR QUALITY

<D A met fmjfcrjm

rum mui Ur«< ing

with •

ri**i k MC prnf<riui

<Z> A met

User

Layer

Network

Management

Network

Application

Layer

Session

Control

End-to-End

Corn rnunicat ion

Layer

Routing

Layer

Data

Link

Layer

Physical

Link

Layer

Communication*

Facilities

NCI1

Utility

l

—._-}.

0 UM*r ® U*i-r

Nctwufk

Uoulinci

'T

--> -.

't

!(<•„..«>• F,k

Aro-x KOIIIUKA

pi''

Sf\\M4i Cxmirt4

M»d»ULine A (e.g.. i Line U(c.g.. i LineC(c.g..i

trlcphoiir line) local cable) telephone line) (Ethernet cabin)

FIGURE- 5.6: TYPICAL DNA MODULES

rce: "Digital's Networks: An

Architecture With a Future" -

DEC

5-53
ORIGINAL PAGE US

OF POOR QUAlfTY

Node 1

Modulet

User Program

1 Network

Management

| Module

1 Network File

Access Routines

1 (NFAUs)

|

Session Control

Module

1

NSP Module

|~B BMtHliil;

.

l)l)CMPM.Kluli1 >cv ice

Controller

1

Node 2

Protocolt Module*

User Layer

« User-Defined Protocol 4- User Program

Network Management Layer

Network Information and Network

• -- •-- Control Exchange -4 Management

Protocol (NICE) 1 Module

Network Application Layer

., A File Access

- i. ?mCAi.i -• T Liiiciicr Protocol (DAP) | (FAL1

Session Control Layer

.- • f~ i ,, i 1 Session Control

•• — Session Control Protocol — «t ,. . i Moilule

End-to- End Communication Layer

Network Services

- Protocol - •» NSP Module

(NSP) 1

Routing Layer

• Routing Protocol •• KoiKmi; Modulo

Data Link Layer

• Cxiinmumcations Mes>age *T DDCMP MtKlule

Protocol (DDCMP) J

Physical Link Layer

. Electrical Signals — 4 ,-

IVv'C

»

" CiMiirollcr

Communication lines

forming physical

connection

FIGURE 5.7: DECNET NODE-TO-NODB PROTOCOL COMMUNICATIONS

Source: "Digital's Networks: An

Architecture With a Future" -

DEC

5-54
(NFAR's) provide the DECnet user with a set of FORTRAN-callable

subroutines that become a part of the user's process and enables

access to remote files for application specific processing.

DNA supports several network terminal facilities. Users at

two DECnet terminals can communicate interactively through Phone

or TLK utilities. Phone is a utility of the VAX/VMS 0/S while

TLK is a DECnet utility supported by DECnet-RSX. One line/one

way messages and dialogue nodes are supported.

The Network virtual Terminal (NVT) facility logically

connects a user at a local terminal to a remote node. DECnet

Phase III requires that both the local and remote nodes run under

the same 0/S. Phase IV implementations lift this restriction.

NVT services are handled by DNA/ISO layer. The Networ k

Application/Presentation layers respectively.

DEC does support a UNIX operating system for the VAX-class

computer. However, as of this writing, DECnet is not supported

in the UNIX environment. During telephone conversations with DEC

representatives, CTA was informed that this capability will very

likely be supported by DEC by the end of 1985.

5.2.11 QNX

QNX 2.0 is a multi-user, multitasking real-time UNIX-based

operating system supplied by Quantum Software Systems, Inc. of

Ottawa, Ontario, Canada. QNX is designed for IBM PC and other

processors which utilize the Intel 8088/8086 and 80186 chips. It

provides a UNIX-like environment for single user configurations

as well as configurations supporting a maximum of seventeen

users. It does not depend upon any specific LAN technology.

5-55
QNX is a message based operating system. Tasks communicate

by sending messages up to 64KB long. Inter-task messaging may

take place between tasks residing in the same processor or in

different processors on the network. An example cited by Quantum

Software is the use of a message by a task to print data on a

network printer. The task transmits a message to the Device

Administrator task which prints the message and then returns a

completion status message to the originator. The Device

Administrator task need not be on the same processor as the

originator since, to the originating task, the operation occurs

transparently.

The Device Administrator handles all serial I/O devices for

QNX. It is one of several administrators in QNX which are

responsible for task creation and start-up, file maintenance,

.*

networ k communications, asynchronou s time-out exception

processing, and other functions.

The QNX network model is viewed as a collection of tasks

executing on a collection of processors which have access to a

collection of resources. QNX does not impose restrictions upon

resource s or processors available to a task. The key to

accessing these objects is the idea of a unique node ID. For

example, the command

P my_file > $lpt

prints a file to a local workstation printer. If this was to be

printed on the printer located on node 3, the command would be:

p my_file > [3]$lpt.

QNX also supports remote task creation/execution. The

5-56
command string

[1] sort < [2]/dirl/filel > [3]$lpt

causes a sort program to be executed on node 1, accept input from

a file on node 2, and produce line printer output on node 3.

Remote log-in (i.e., remote virtual terminal) is also supported

by QNX. All I/O is defaulted to the requestor's terminal.

By means of bidirectiona l virtua l circuits, QNX also

supports the capability of intertask communication between

processors. A user uses the system call

vc_create (nid, tid, buffer-size)

to create a virtual task ID supplying the node and task ID'S, and

buffer size of the largest message expected. Subsequent intertask communication takes place utilizing the virtual circuit

ID'S.

The messaging philosophy utilized by QNX may also be applied

to provide for task synchronization. Tasks may be attached to

"ports" which can then be used for inter-task handshaking via

semaphores. Asynchronous interrupts, (i.e., exceptions) are also

provided by QNX. Of the 32 exceptions available in QNX, sixteen

are defined by the system (e.g., timer expiration, break, task

kill) and sixteen are available for user defined conditions.

This supplements the messagin g technique for inter-task

communication. In the QNX networking environment, QNX extends

the exception processing capability to enable exceptions to be

set on virtual tasks. This causes the exception request to be

sent over the network and set on the real task running on another

processor.

5-57
5.2.12 Apollo Domain

Apollo Computer, Inc. of Chelmsford , MA markets a token

ring-board LAN product, the Apollo Domain, for its famil y of

MC680X0-base d workstations. Th e Domai n system softwar e

environmen t is illustrated in Figur e 5-8. Apollo offers two

operating system environments for its Domain product: AEGIS/ a

proprietary 0/S by Apollo and AUX, Apolla's implementation of

UNIX. Both utilize Apollo's proprietary 0/S kernel which

provides virtua l memory management and access to the Domain's

high-resolution, bit mapped workstation displays and token-ring

LAN. Salient features of AEGIS are listed below:

o Virtual memory for direct execution of large programs

o Network-distributed file system with access control list

security and protection facility

o Concurrent, multiwindow Display Manage r Environment

provides "virtual terminals " to programs, text, and

graphics; includes screen-oriented editing

o Interprocess communication, process creation, and event

synchronization to coordinate execution of separate

programs

o Online HELP facility, including documentation of access

to system services

o Shell command line interpreter for application control:

an interactive programmin g language whose "verbs" are

user and utility programs

o Logical, extensible set of system commands and utility

programs

o Support for a variety of programming languages and data

management techniques

o Graphics support

o Support for diskless, shared server, and standalone

equipment configurations

o Network system reliability and maintenance utilities

The AUX 0/S is based upon the Bell Labs System III Berkeley

versions of UNIX. It supplements these features with:

o support for I/O redirection, pipes, and forks,

o support for Bourne and Berkeley C shell, and

o the ability to initiate asynchronous processes

5-58
FIGURE 5-a Apollo Domain Software Environment

ORiGINAL PAGE (S

OF POOR QUALITY

.DOMAIN Graphic* Reaource*

Graphics Primitives

Resource (GPR)

Graphics Metafile

Resource (GMR)

Document

Mail

Calc

Dliplay Management

Network-Wide Utllltlet

. Interprocess \

V Communications /

Spooler

DOMAIN Professional

Support Services

DOMAIN Distributed \

Oala Management (03M) /

VT100 Emulator

Software Development

DOMAIN Software

Engineering Environment^

FORTRAN 77

Pascal

LISP

High Level

Language Debugger

Common Code

Generator

•Apollo Standard of Optional UNIX Command and Execution Environments

5-59
Both operating system environments offe r demand paged

virtual memory enabling users to execute programs which exceed

the amo'unt of physical memory in the user's computer. This

capability has been extended across the Domain network.

The Domain is comprised of a homogeneous famil y of

processors and operating systems which facilitates Apollo's

support for programs to be directly executed on any node without

recompilation or binding.

Apollo has integrated the network communications functions

within the 0/S kernel. A conscious decision has been made

against a layered approach to achieve high network performance.

Apollo has taken the opposite approach of LOCUS (see Section

5.2.1) in that only one copy of a file is maintained in the

system. It may be shared by multiple users and Apollo justifies

this design for the following reasons:

o it reduces the amount of mass storage devoted to

redundant files and

o it eliminates the need to assure that copies of files

reflect the same information.

Apollo has implemented an object oriented design in its

approach for the Domain network. Each object is uniquely defined

and made available across the network by a 96-bit virtual address

(64 bits for a unique object name and 32 bits address within an

object). Objects may be "typed" as text or graphics files, file

security access control lists, database storage areas, and

similar uses. They are byte addressable and can be located

anywhere in the network.

Apollo's distributed network file structure utilized a

5-60
hierarchical tree structure. A uniform naming convention permits

access to any node, application program, data file, or resource

in the network.

Access Control Lists (ACL's) have been implemented by Apollo

for security access control to all objects. Objects may be

accessed only when so established by an entry in the ACL.

Combinations of user name, project membership, or node ID may be

specified for authorized access control. Since the ACL also

protects file system directories (an object), knowledge of a

file's existence may also be denied if desired-.

Apollo has implemented a server approach to promote resource

sharing. Key to this is its implementation of interprocess

communications (IPC). IPC permits users to communicate with

servers via virtual circuits and it facilitates the exchange of

messages between processes running in different workstations.

Outside the realm of the Domain network, Apollo also

provides support for file transfers, remote virtual terminal, and

virtual circuit services for X.25 communications. Ethernet in

conjunction with TCP/IP supports file transfer and remote logon

functions.

5.2.13 XEROX

XEROX Corporation has defined and published a suite of

communications protocols, referred to as the XEROX Network System

(XNS), that implement a Network Operating System. XEROX has

incorporated these protocols in some of their workstation

products, e.g., 8010 workstation. However, since XEROX has

published these protocols, other vendors have implemented them in

5-61
thei r products. Thes e vendors includ e 3COM , Bridg e

Communications, and Associated Computer Communications.

The XEROX Networ k System and the DARPA protocol suite are

similar in that both are:

o independent of the local operating system,

o based on connectionless internetwork protocol,

o employ fewer protocol levels than OS I (the DARPA protocol

architecture is not layered).

The architecture (shown in Figure 5-9) of the Xerox protocol

suite is similar to the DARPA protocol suite which provides

printing, filing, directory, and time of day services. The

director y servic e know n a s CLEARINGHOUS E is distribute d

implementation used for locating both users and resources. For

example , the user may select a file server and then the local

workstatio n will invoke a CLEARINGHOUSE retrieve primitiv e to

obtain the network address. .Then, this address is passed to the

transport layer to establish communication . It include s

procedures for creating and modifying the directory as well.

The printing, filing, and directory service employ the XEROX

Courie r protocol, which is a remote procedur e call. The X.410

standard is very similar to Courie r indicating a significant

XEROX contribution.

The transport and networ k layers are very similar to the

DARPA protocol suite in functionality and operate over a wid e

variety of networks. However, XEROX also includes diagnostic

protocols, ECHO in which the remote hosts return the bit stream

entered by the user, and ERROR for reporting exception systems.

5-62
XEROX NETWORK SYSTEM

Levels (our and above

Application protocols

Laval three

Control protocols:

Conventions (or

data structuring and

process Interaction

Lovot two

Transport protocols:

Interprocess

communication

primitives

Printing

i

Filing

i

Clearinghouse

i

Courier

Time o( day

Echo Error

Sequenced

Packet

Packet

Exchange

Routing

Information

Level one

Transport Protocols:

Internet packet format.

Internet addressing and

routing

Internetwork Datagram Protocol

(Internet Packet)

Level zero

Transmission media

protocols:

Packet transport

mechanism

X.2S Ethernet

Leased

lines

FIGURE 5. 9

5-63
5.3 Research Projects

As illustrated in Figure 5-10,current research efforts can

be categorized into the following areas:

o real-time node performance including hardwar e and local

operating system software enhancements,

o job schedulin g algorithm s for optima l resourc e

management,

o reliability includin g faul t toleran t systems and

reconfiguration,

o concurrency and recovery software procedures,

o implementing new functionality in the NOS or implementing

common functionality in new environments,

o enhancemen t of programmin g language s to provid e

specialized feature s for concurrent programmin g and

debugging of distributed software.

In the following sections, activities in each of the above

areas are highlighted wit h reference s to specific activities

particularly relevant to NASA.

A list of the research projects considered is included in

the appendix. For each project, the following information is

presented:

name of project,

organization,

- name of investigator(s),

keywords identifying specific research areas.

T h e specifi c area s wher e th e res'earch efforts ar e

contributing (beyond what is currently available in commercial

products) are in concurrency synchronization, and recovery and

5-64
EFFICIENCY

REAL TIME

PERFORMANCE

JOB

SCHEDULING RELIABILITY

CONCURRENCY &

SYNCHRONIZATION

PROGRAM

FUNCTIONALITY ENVIRONMENT

INTERPROCESS

COMMUNICATION

COST HEURISTICS FAULT TOLERANT SCHEDULING

ALGORITHMS

REMOTE PROC

CALL

INTERPROCESS

COMM

BIDDING AUTOMATIC

RECONFIGURATION

INTERPROCESS

COMM

DEBUGGING

en

I

a\

Ul

NETWORK FILE

SERVER

FIGURE 5.10: RESEARCH AREAS
programming language enhancement, especially with the use of Ada

(TM of Department of Defense).

To report some of the very recent results, CTA has relied

upon session summaries of the January 1985 Workshop on Operating

Systems in Computer Networks [46], There were no proceedings of

this workshop and hence, the technical discussion is necessarily

brief.

The ARCHONS research project at Carnegie-Mellon is worth

noting because of its scope and long-term duration. In

particular, researchers are addressing many of the issues listed

above, e.g., optima l resourc e managemen t and high system

availability for real-time control application (military combat

platform, industrial automation). Their work addresses the

problem from the establishment of a set of requirements (atypical

for research) through implementation. The objective is to

enhance system robustness and modularity which tend to dominate

life cycle cost. The approach being taken is development of a

tightly coupled system with a system wide operating system, which

is"diametrically opposed to computer networks and network

operating system". Hence, this significant project is not

considered.

5.3.1 Real-Time Node Performance

The Real-Time Node Performanc e has been significantly

enhanced with the continuing improvements in semi-conductor

component performance. As the price/speed ratio of processors,

memories, and other components continued to decrease, increased

functionalit y can be incorporate d into nodes and highe r

5-66
throughputs can be achieved. In fact, it is the rapid

improvements in the semiconductor history which have triggered

the advances in computer communications. These advances are now

being illustrated in the commercia l marketplac e wit h

implementation of specialized communications printed on circuit

boards.

The primary activities in the local operating system support

focus on more efficient interprocess communications. Work at IBM

Switzerland [46] has addressed communication between OS I protocol,

layers such that data is being operated on by different protocol

layers rather than being copied. These researchers claim that

buffer management is facilitated because only application buffers

are required and that no system buffers are required. Thus, with

a single layer allocating buffers, flow control is simplified.

Wor k on the SWIFT project [46 ] at MIT has developed and

implemented upward procedure calls for passing received data from

lower layers to higher layers; these are referred to as "upcalls11

by the researchers. The basis for this research is that

procedure calls are more efficient than message passing between

tasks or downward procedure calls that remain pending awaiting

receipt of data. Some researchers argue that "upcalls" are

simply software interrupts.

In the SWIFT project, TCP has been implemented using

"upcalls". Some of the problems identified were harder to read

code, security issues associated with passing data to less

trusted higher layers, and garbage collection of the shared

address space.

5-67
Work at Stanford on the Distributed V Kernel (not to be

confused with the AT&T Unix System V) has focused on performance

using interprocess communications. In this project, the

researchers hide the intermachine communication from the user by

providing an object-oriented interface to the users[50]. Since

i

it is impractical to provide a universal set of objects to the

users, they claim that the process group is the optimal set of

objects to include in the interface because:

- processes are necessarily needed in the kernel,

- processes can support other types of objects such as

files,

- processes are useful for supporting parallel competition,

- multiple processes easily support replicated processes.

In this work, they have incorporated message oriented process-toprocess communication in the kernel and measured its performance.

They have also built a file server employing this interprocess

communication technique and intend to employ them for replicated

data, job control, distribute d naming , and multi-serve r

transactions.

In subsequent work [51], they have investigated implementing

a pipes feature, i.e., a one directional byte stream by either

incorporating it into the kernel or building a server process

using the interprocess communication service of the kernel. They

have found that the latter approach was preferable because it was

nearly as efficient and the kernel size could be minimized.

In its DISTRI X project, Convergent Technologies is

developing a message based implementation of the UNIX System V

for a network of workstations [46], Note System V is the latest

5-68
AT&T supported version of UNIX. In this implementation, the user

is unaware of the location of server processes, thus this is a

distributed operating system mode of operation.

The implementation of this system is based on a real-time,

message based operating system, the Foundation System.

Presumably, this is proprietary to Convergent Technologies. The

evolutionar y development of DISTRIX has consisted of the

following steps:

- implementation of UNIX as a single Foundation process.,

implementation of each DISTRIX process as a Foundation

process.

- distributing each UNIX file as a DISTRIX file.

This project is significant because it would provide UNIX

compatibility and alleviate performance problems associated with

UNIX.

AT&T Bell Laboratorie s have been investigating the

performanc e of UNI X based systems in a multi-processor

environment. In this project, a VAX 11/750 running UNIX is

off-loaded by Motorola 68006 processors running MEGLOS [52],

Users are connected directly to the VAX and the 68000's and VAX

are interconnected by a high speed local area network.

By employing the UNIX TX command, a user can run a program

on a specified 68000. The key features of this project are:

- extending the UNIX environment to the 68000 processors,

- efficient interprocessor communications based on full

duplex channels employing message oriented primitives,

however, these channels are pre-established and centrally

5-69
controlled,

real processing executive in MEGLOS with subprocesses

(which provides a multitasking capability) and semaphores

for synchronization; the real-time capability provides

efficient interfaces with disks, robot arms, video image

processors, etc.

Performance measurements with MEGLOS indicate communications

latencies of 750 microseconds and interprocess throughputs

exceeds 300 kbytes, far exceeding standard UNIX capabilities.

5.3.2 Job Scheduling

Although there have been a numbe r of theoretical

formulations of optimal job scheduling, there is no algorithm

available for optimal scheduling [22]. The problem can be

addressed at two levels: entire job or task where multiple tasks

comprise a job.

A typical approach for task scheduling is heuristic based on

assumed processing costs for each task and interprocess

communications costs. Using this information and possibly

current system states data, the local system can execute an

algorithm to optimally determine wher e the job should be

executed. The problem formulations are usually very complex,

employing team theory, control theory, or mathematica l

programming as discribed by Stankovic [22], Because of the realtime requirements for execution, these algorithms must run very

quickly ; thus optimality is not usually achieved. These

algorithms employ heuristics which tend to produce good, but not

optimal solutions. Furthermore , significant overhead can be

5-7l
incurred in gathering status information. In practice, these

heuristic algorithms typically have parameters which are left

unspecified such that they can be tuned as system parameters for

the local environment. This approach is used in the Apollo

Domain structure [48],

Another approach typically used for job scheduling is the

bidding scheme in which the local node issues a bid in which it

queries other nodes regarding their capability and/or capacity to

perform the current job. Based upon the responses received from

the queried node, the originating node will assign the job to a

particular node. These schemes are suboptimal and excessive

overhead may be incurred in executing the bid process. There

have been numerous research activities focusing on variations of

this idea as summarized by Stankovic [48].

In the area of job migration, researchers at the University

of California, Berkeley have developed a process migration

(processes in execution) for the DEMOS/MP operating system. This

operating system includes a message oriented interprocessor

communication mechanism. The process migration implemented was

dynamic in the sense that processes in execution could be moved.

The criteria for deciding when a process should be moved was

arbitrary, but adding a decision role to initiate such migration

should not be difficult. The steps involved in performing this

migration are:

- halt process execution,

ask destination kernel for permission to move process,

- allocate process state in destination host,

transfer the process state,

5-71
- transfer the program

- forward pending messages

- cleanup process state

restart process.

The implementation of this capability was straightforward

according to the researchers because the process state

description was concise and not hidden in any functional modules

in the operating system.

5.3.3 Reliability

This section addresses research in hardware fault tolerance

and the area of concurrency, synchronization, and recovery.

5.3.3.1 Hardware

There is substantial work in the area of generic faulttolerant computers which would be applicable to distributed

computin g systems. Wor k being performe d by C.S. Drape r

Laboratories for NASA Johnson Space Center addresses this issue

specifically for embedded computer systems.

In its Advanced Information Processing System, Draper is

developing a fault-tolerant processor and a network node which is

being implemented in a proof-of-concept network architecture.

The node is employed as either an intercomputer network node or

an I/O network node. The intercomputer network connects multiple

fault-tolerant processors while the I/O network connects sensors,

effectors, and general purpose computers to the fault-tolerant

processors. In the proof-of-concept intercomputer network

architecture, there are three independent subnetworks each having

5-72
five nodes. Each of the five nodes in a subnetwork are connected

to each of the other fou r nodes via a point-to-point port. The

fift h port on the node is used to interfac e a host such as the

fault-tolerant processor. Thus the intercompute r networ k

provides a highly reliable means to interconnecting a set of

hosts.

The significant characteristics of the Draper proof-ofconcept intercomputer network are:

o circuit switche d connection s betwee n sourc e and

destination nodes;

o point-to-point communication between" nodes is employed,

but the architecture could be enhanced to multiple access

communication;

o OSI protocol layers 1-3 are implemented in the OSI; there

are no high level protocols implemented. Thus this

system is essentially a LAN rathe r than a Networ k

Operating System.

Key characteristics of the fault-tolerant processor are:

o the architectur e is based on two processors: a

computationa l processor to perfor m protocol and

applications processing and an I/O processor to perform

I/O operations; the processors communicat e via shared

memory.

o triply replicated hardwar e in the node with a voting

algorithm to determine the "correct" result.

The intercomputer communication s for the computational

processor is simplified in AIPS because all remote devices appear

to be memor y mapped as shown in Figur e 5.11 . Whe n a

computational processor wants to send a message to a remote

processor, it inserts the message into the appropriate location

in the shared memory. Then the I/O processors (local and remote)

and the intercomputer network deliver the message to the remote

computational processor. The remot e I/O processor inserts the

5-73
DEVICE A

^1

RAM

< . XI

SHARED

RAM

1

DEV

1

1

V

I/O RAM

CPU

f^

>

l^

_r^

>

v

 — .~-N

is

\

CP\

1 — .

TERCOMPUTER

NETWORK DEVICE B

DBV

FIGURE 5.11: AIPS MEMORY MAPPED I/O

5-74
message in the appropriate location in the remote shared memory.

The major contribution of the Draper results is the fault

tolerant hardwar e architecture memory mapped interprocessor

communication rather than any specific networking or networ k

operating system contribution. Apparently, Draper and JSC have

future plans for incorporating high level protocol features into

the AIPS, but details were not provided in the documentation.

Also, in the hardwar e area, the ENCHERE project [46] has

developed a stable RAM with non-volatile memory banks to support

failure atomicity and permanence for small objects. It has eight,

non-volatile memory banks mapped into the address space of the

application processor. Hardwar e faults of a single bank are

mapped by writing data into two banks (sequentially). The nonvolatile RAM is also equipped with protection mechanisms to

protect against illegal memory accesses.

The thrust of the CLOUDS project at Georgia Tech [5],

partially funded by NASA, is to develop a reliable distributed

operating system. The major contribution of this project is the

development of the job scheduler with features to ensure reliable

operation and to provide load leveling. The CLOUDS operating

system has the following properties:

- multiple schedulers may reside in the same network;

for each scheduler, there is a backup scheduler which is

employed to detect failure conditions and assume control;

- servers, e.g., a print server, could be implemented

across multiple hosts;

processes communicate via remote procedure calls;

use of the two phase protocol to ensure committment (see

5-75
Section 5.3.4) .

The hardware components consist of multiple VAX and IBM PC

hosts which are all connected by an ETHERNET. In addition, the

VAX hosts are linked by a DEC CI interface. However, the initial

distributed operating system wor k is focusing on the VAX. At

this time, it appears that the IBM PC is used primarily for user

interface.

5.3.4 Reconfiguration

Automatic reconfiguration has been implemented as part of

the NASA Langley Research Center activities by employing multiple

interfaces to multiple ETHERNET LAN's. In their network, a

typical node had backplane connections to two ETHERNET

communications units, one of which was connected to two parallel

ETHERNETS while the other was connected to two independent

ETHERNETS. Although multiple paths provide reliability, these

researchers assign routes to messages based on delivery time

requirements. For example, time critical messages are assigned

shortest paths through the network.

In work partially supported by NASA, researchers at the SUNY

at Stony Brook have developed the "UNCLE" algorithm for automatic

topologica l reconfiguratio n of compute r network s and

theoretically analyzed its performance [69]. However, it has

apparently not been implemented in their MICROS network.

In this work, the researchers consider failure of a node(s)

in a tree shaped control hierarchy. When one of the non-leaf

nodes (i.e., a node with at least one descendant) fails, then the

control hierarchy must be reconfigured such that the orphans

5-76
(descendants of the failed nodes) are re-connected to the control

hierarchy. Thus, the reconfiguration algorithms must determine

how to perform this reconnection subject to cost and performance

considerations. The criteria employed in UNCLE are:

localize the effect of the reconfiguration,

distribute the reassignment of the disconnected nodes

over more than one control node,

- do not increase the height of the tree.

In the algorithm, the father of the failed node acts as

t*

coordinator of the reconfiguration process and each orphaned node

issues a message announcing the failure. The father node

(grandfather of the orphans) performs a heuristic algorithm in

which the reassignment of orphans is determined by the current

computed loading. After the father determines the reassignment,

messages are sent announcing the reassignment. A key feature of

the algorithm is that it allows for detachment of nodes from the

current hierarchy and reassignment to "UNCLES" in order to

minimize tree height.

The theoretical analysis of the UNCLE algorithm has

quantified total number of nodes with changes, change in tree

length, and message traffic, which indicate the algorithm design

criteria are achieved.

There has been substatial related work in the

reconfiguration area for wide area networks including theoretical

work with task force networks [62] as well as experimental work

with packet radio networks [63]. Since the focus of this study

is on local area networks, this area was not carefully surveyed.

5-77
5.3.4 Concurrency. Synchronization, and Recovery

The area of Concurrency, Synchronization, and Recovery is

one where there is substantial research is being conducted. The

focus of this research is to maintain data integrity when

multiple users are attempting to access the data and device

failures occur.

The OSI protocols address this issue and provide partial

solutions. For example, some of the procedures included in the

OSI protocols are: . .

o retransmission at the link and transport protocol layers,

o alternate routing at the network layer; NASA Langley has

built an Ethernet network with the capability to provide

this capability,

o checkpointing and synchronization at the session layer,

which are employed by higher layer such as the file

service.

Also, there is the aforementioned work in progress to

develop the Commitment, Concurrency, and Recovery standard at

layer 7.

However, the OSI wor k is typically based on a connection

betwee n two parties. Thus, it needs to be enhanced to

accommodate multiparty communication with processing and updates

performe d at multiple sites. The relevant research has

originated in the data base community for handling file or

database access. However, as Allchin and McKendr y [45] point

out, it is applicable in a more general programming environment

such as updates of specialized queues, directory, storage

allocation module. Although this was deemed an NOS application,

this area

5-78
was reviewed briefly for completeness.

The scope of the work in this area is comprehensively

surveyed in a number of relatively recent articles:

Andres, G. and F. Schreider

"Concepts and Notations for Concurrent Programming",

ACM Computing Surveys

March 1983

Kohler, W.

"A Survey of Techniques for Synchronization and Recovery in

Decentralized Computer Systems",

ACM Computing Surveys

June 1981

Bernstein, P. and N. Goodman

"Concurrency Control in Distributed Database Systems",

ACM Computing Surveys

June 1981

Also, there was a conference on this subject area which is

documented in

Distributed Computing Systems Synchronization. Control* and.

Communication

ed. Paker, Y. and J. Verjus

Academic Press 1983

The fundamental concepts in this area are objects, actions,

and atomicity. Objects are comprised of data and associated

procedures acting upon them. An action (or transaction) is a

partial order of operations on objects. The action is atomic if

it can be viewed as either happening completely or not happening

at all. However, the action is not implemented in an atomic way,

i.e., computers could possibly fail during the execution of an

action. Thus recovery and synchronization procedures are

implemented such that the action appears atomic. The effect of

an action on an object is not made permanent until the action is

completed, this is referred to as committing. If a failure

occurs or a user requests termination of an action during the

5-79
execution of the action, then the action is aborted and the

status of all objects reverts back to the original state as if

the action was never initiated.

Another key concept is serializability meaning that a set of

actions appear to execute in some sequential order even though

they execute concurrently. Clearly, in order to provide

acceptable response time to users, it would not be practical to

execute all systemwide actions in a sequential manner. Bernstein

[50] has done this fundamental work in specifying the conditions

under which a set of actions are serializable. A serial set of

transactions would introduce no concurrency or control problems

because each action would be completed before the previous one

finished. Since LAN actions are not going to be executed

sequentially, the focus of the research is to develop action

schedules that schedule transactions that are serializable.

Thus, the correctness of a set of actions is judged by its

serializability.

The basic protocol currently employed for effecting an

update to a set of objects is the two phase protocol illustrated

in Figure 5-12. In this protocol, all updates to the objects are

tentatively performed and the centralized coordinator for the

action initiates execution by transmitting a PREPARE message to

all subordinates. If the subordinate is not prepared to complete

execution of the action, then the subordinate returns a NO

message. The coordinator will then abort the action.

If the subordinate is prepared to complete the action, then

it writes a YES record to its log. Then it sends a YES message

to the coordinator. If any NO messages are received, then the

5-80
FIGURE 5.11: 2 PHASE PROTOCOL

1. TENTATIVELY EXECUTE TRANSACTION

2. SEND PREPARE MESSAGE

J. IF ANY NO's, ABORT

4. if ALL YES's , SEND COffHiTT

01

oo

SUBORDINATE

FORCE - WRITES

Si

> O

- rn

3 31

5. ASSUME ANY FAILED DEVICE ULTIMATELY RECOVERS SUBORDINATE
coordinator aborts the action.

If all YES messages are received, then the coordinator

writes a commit record to the log and then sends COMMITT message

to each subordinate, upon receipt of the COMMITT message, the

subordinate will writ e an ACK record and then forwar d a YES

message to the coordinator. Upon receipt of all YES messages,

the coordinator will write an END record to its log completing

the action.

The handling of all failur e conditions is tedious, but it

can be established that the above protocol will successfully

terminate under the assumption that all failed units ultimately

recover.

Research topics in this area include:

- developin g schedulin g algorithm s t o ensur e

serializability,

identifying conditions for scheduling algorithms which

will provide correctness in a non-serializabl e

environment,

developing efficient techniques for implementing these

techniques.

Recent work by Weihl [44] and Allchin and McKendry [45] have

addressed the scheduling problems. Traditional scheduling

algorithms have based their approach on the logical operations

being performed to ensure concurrency. Weihl has extended this

to develop data dependent scheduling algorithsm. In practical

terms, Weihl's work is best illustrated by an example. Consider

a bank account balance as an object with deposit and withdrawal

operations. Traditional algorithms would not permit concurrent

withdrawa l operations because the first withdrawa l operation

could exhaust the fund s in the account such that the second

5-82
withdrawal could not be performed. Weihl develops the concept of

dynamic atomicity which allow the concurrent withdrawal operating

providing their sum does not exceed the current balance. Weihl

carefully defines the concepts of dynamic and hybrid atomicity

and proves a set of theorems to support his schedulin g

algorithms.

In the CLOUDS system, the researchers have implemented an

object-oriented scheduler which has fou r levels of support

facilitie s to enable users to achieve variou s levels of

concurrency; these options are (in increasing orde r of

concurrency):

1. Fallback to traditional locking schemes at the object level

based on usual semantics of read/write.

2. Permit users to specify commutativity of object operations

which must be true for all operations.

3. Provides programmer controlled locks which permits any item

in the domain of interest to be locked.

4. User supplied procedures to specify to the scheduler object

dependencies. The scheduler can then build a "template"

object scheduler.

In their work , these researchers have developed theoretical

conditions which enable use of these procedures.

Research wor k in this area addressing efficiency has been

performed by Lindsay [47], who developed techniques to reduce the

number of network messages and file accesses in special cases.

For example, when a transaction is being performed across

multiple nodes, some nodes may perform only read operations.

Lindsay has developed modifications to the basic two phase

algorithm to minimiz e the numbe r of writes to the log and

messages that must be delivered by the network.

5-83
5.3.5 Functionality

The functionality being implemented in research efforts, is

very similar to that being implemented in commercial products,

e.g., distributed file servers and remote procedure calls. In

fact, many research projects are now offered as commercial

products, LOCUS, The Newcastle Connection, Berkeley UNIX.

There are many research projects, implementing distributed

file servers and remote procedure calls with specialized research

objectives. Some typical projects include (and there are many

others):

o ATHENA of MIT to interconnect many types of personal

computers used for undergraduate education with IBM and

DEC hosts,

o the IBM Carnegie-Mellon Information Technology Center

project to provide a network-wide file system usable from

personal computers providing interfaces and semantics of

UNIX,

o Mayflowe r projec t developing connectionless remote

procedur e calls wit h binding done at call time by

specifying a network address.

o NASA LRC project developing remote procedure calls with

binding done at load time (although compile or runtime

binding could be incorporated). This appears more like'a

process-to-process communication because the association

is maintained rather than terminated after the exchange

of data.

Some of the research projects have protocols for

interprocess communication such as CHORUS (TM of INRIA) and

MICROS. CHORUS [58, 64] introduces the concept of an actor,

consisting of code and data. An actor can also send/receive

messages but processing of such messages is sequential.

To send a message, an actor must open a port to establish an

5-84
association with another actor. Afte r the association is

established, the actor invokes the send primitive service of the

local operating system:

SEND (source port, destination port(s), message)

The operating system then takes responsibility for delivery

of the message. Details of the message delivery protocol and

exception condition handling were not specified. CHORUS is

implemented on using CNET SM90 processors over an ETHERNET. The

SM90 processors have been developed by the Centre National de

Etudes des Telecommunications in France and employ Motorola 68000

or National Semiconductor 1600/32000 microprocessors.

The- basic CHORUS system has also been enhanced with a number

of fault-tolerant computing features. In CHORUS, a distributed

application is implemented using actors distributed over the

network. The key features of the architecture that provide the

fault-tolerance are the introduction of protocls to provide:

"coupling of actors" to provide backu p computin g

resources over multiple sites,

- "activity message" to introduce a notion of atomicity and

recovery beyond a transaction.

The activity message is used to defin e a protocol to

synchronize and control the distributed processes.

MICROS [58] implements process-to-process communication

using datagram transmission, i.e., all messages are transmitted

independently. All possible sources and destinations/processes

or devices, have global addresses that are pre-established.

Communication is implemented using mailboxes. The source

process logically appends a header to the message containing

5-85
source, destination, and length. The communication functions

examine the mailbox to determine if the message is destined for a

local or remote process. If it is local, then pointers are

adjusted to pass the message to the local process. For remote

processes, the message is transmitted over the communications

network and then distributed to the destination process.

For high throughput applications, MICROS provides a service

referred to as a "channel". Processes simply read from and write

to pre-allocated buffers associated with the channel. The

communications systems automatically sends messages corresponding

to the pre-established buffer size.

The MICROS hardwar e currently consists of seven Heurikon

HK68k Motorola 68000, two DEC LSI 11/23 systems, and a VAX

11/750. These systems are connected via an ETHERNET and the

XEROX Networking System protocols at the higher layers. Although

prototype networks are small, the goal of the MICROS project is

to develop techniques applicable for very large networks, e.g.,

10,000 hosts.

Also, at Carnegie Mellon University, the IBM LU6.2 has been

implemented under UNIX to provide process-process communication.

The interesting results of this project are [46]:

o 85% of the protocol code was generated automatically,

o protocol is large and cannot run in the Kernel,

o simulating full duplex UNIX sockets using half duplex SNA

connections; this required an extension of SNA.

In the area of data representation, Bolt, Beronek and Newman

(BBN) has developed software to facilitate implementation of the

CCITT X.409 Presentation Transfer Syntax [56]. This standard

5-86
defines a technique for encoding exchange of information between

heterogeneous computer systems. Example data types include

Boolean, integer, bit string, and International Alphabet No. 5

string. In addition to specifyin g the encoding for the

information to be transmitted over the communication network,

this standard also specifies a notation for describing in a human

readable representation the form and content of the information

to be transmitted. The BBN software facilitates, both encoding

and decoding of X.409 data streams.

They have developed a compiler, PRES, which converts modules

of type definitions (specified according to the human readable

form) ink type tables. The X.409 notation is input directly into

PRES which:

performs consistency checks on the data,

generates type tables which are 'C1 language source code

files containing 'C1 data declarations with initializers.

These tables are then compiled and made memory resident.

The remaining softwar e consists of library routines to

perform manipulations using file type tables. These routines

include:

o print_type, which prints a type table out in its original

form as a type definition expressed in notation. This

routine performs the inverse of Pres; it is used for

checking the accuracy of Pres.

o parse_value, which converts a value expressed in notation

into a value table. Parse_value reads notation from a

file, parses it according to information contained in a

type table, and constructs a value table.

o print_value, which prints a value table out in its

original form as a value expressed in notation. This

routine performs the inverse of parse_value.

o encode_value , whic h converts a value table into a

5-87
sequence of octects encoded according to the X.409

encoding syntax.

o a routine, decode_value, which converts a value, encoded

according to the X.409 encoding syntax, into a value

table.

Sinc e the valu e table s are typically not in a

computationally usefu l form , BEN has allowed the user to

incorporate code fragments in the type spejcification indicating

where the data is stored. Then the encoding/decoding routines

can appropriately extract/enter the data from/to these locations.

5.3.6 Programming Environment

The major issue associated with programming languages is

interprocess communication, especially with the use of Ada. The

PULSE project [46] addressed this problem and considered the

following alternatives:

1. Allow any Ada program to be arbitrarily distributed - this

will only work if there is shared memory.

2. Distributed at the Ada task level and do all inter-machine

communication via rendezvous.

3. Extend Ada with primitives for distributed computing.

4. Put separate Ada programs on each processor and build an

inter-machine communication facility.

In essence, the issue is whethe r the Ada rendezvou s

technique used in local interprocess communication should be

extended to remote interprocess communication. In this case,

there would be a single Ada program with tasks in multiple nodes.

This introduces substantial complexity and the Ada compiler must

consider remote access. Alternatively, Ada could employ messagebased communication based on OSI protocols for this interprocess

communication. In this case, there would be separate Ada

5-88
programs in each node. This issue highlights an issue that has

been addressed for other programming languages in the past.

The PULSE project employed the standard approach and put

separate Ada programs on each processor and built an intermachine communication facility, which is the traditional

approach.

Among the other distributed systems being implemented in Ada

is the Cnet project at I.E.I. - C.N.R., Italy [46]. Although

only limited information was obtained on this project, this

effort will allow dynamic configuration to establish runtime

linking of the new module. This requires a limited extension to

Ada to allow for this runtime binding.

Experience has shown that debugging distributed software is

extremely complex and has received relatively little attention.

To facilitate distributed development, researchers for NASA

Langley are developing specialized debugging techniques. The

issues that are addressed are:

o techniques for triggering event sequences; NASA work has

implemented using an extension of the path expression in

Path PASCAL [57].

o monitoring and playing back the events occurring on the

communications channel. This is typically done by

employing a/monitor node on the communications channel.

o local debug/trace debug facilities in each node.

The MICROS project is also developing BUGNET, which provides

similar capabilities BUGNET, which is written in MODULA-2, is

designed to allow the programmer to control re-execution of

software; it operates as a logic analyzer by saving all process

interaction messages and checkpointing processes onto disk. To

date, only a time-sliced version running under VMS on the VAX has

5-89
been completed, but it is planned to develop a version for a

network of MODULA-2 workstations.

At the University of California, Berkeley, researchers have

enhance d Berkele y UNI X wit h a meterin g capabilit y fo r

interprocess communication [65]. As shown in Figure 5.13,

processes A and B are communicating, but are also being metered.

Associated with processes A and B, there are daemon processes

which communicate with a filter process.

The measurement capability enables the user to determine

when and how frequently calls are effected. The gathering of the

information is performed by the Kernel and passed to the metering

daemo n "process. The daemo n mete r process reports this

information via interprocess communication to the filter. The

filte r will then record the informatio n requested by the user.

For example, the measurement capability could create a log of all

messages sent between A and B for a user-selected set of message

types. The recorded information would include source process ID,

destination process ID, message type, time of event.

To facilitate debugging of distributed software , it is

necessary to maintain global time such that relative timing of

events can be determined. Berkeley UNI X researchers [2] have

developed algorithms to estimate correct time based on observed

delays in a single ETHERNET as part of their TEMPO time services.

With clocks having movement of 10 ms, they determined that

accuracy of global time could be achieved within an accuracy of

40 ms.

The technique that these researchers employ is to measur e

5-90
metered processes

filter

control process

meterdaemon

IPC connections

FIGURE 5.13* STRUCTURE OF 4.2BSD METERING TOOLS [65]
the delay from system A to B as

(^ = TIMESTAMPg - TIMESTAMPA

where

TIMESTAMPA is a timestamp of the start transmission event

entered at system A and incorporated in a control

message sent to system B.

TIMESTAMPg is a timestamp at system B entered upon receipt

of the control message.

The delay from B to A is analogously measured. Multiple

experiments are made to determine observations

d1(i) , d2(i) r i = If2,...

Then minimum values are taken

dj = minimum.dj(i)

&2

 = minimum.

The clock difference is estimated as

- = d2 - dx

The use of the minimum rather than an arithmetic average was

utilized in the above calculation in order to eliminate the

effects of transmission delay variance.

The general algorithm to update clocks is as follows:

1. The maste r selects, usin g the Inter-Process

Communication mechanism described above, one of the

machines.

2. It calls measure and stores in an array the differenc e

between its own clock and the clock of that machine,

3. After all the machines have been polled, it computes the

networ k average delta as the average of all the

different deltas.

4. It asks all the computers to correct their clocks by a

quantity equal to the differenc e between the network

average delta and their individual deltas.

Witte [66] has subsequently addressed the problem of correcting

5-92
clocks and formulated the following alternatives:

(1) A single master can serve the entire network by polling all

nodes for local time information, calculating the new times,

and sending the new times to each node.

(2) Communicating masters can each keep time in a local area

that does not overlap with others and can poll all other

masters for input to the time calculation.

(3) Independent masters can keep time in overlapping areas so

that each client node has fanout masters.

(4) All nodes can be autonomous with equal responsibility as

master and client for its fanout neighbors.

Alternative (4) was selected as optimal because of its capability

to accommodate nodes entering and leaving (including failures)

the network.

These tools may facilitate development of distributed

systems, but such development is still complex.

5.4 Research and Development Efforts

This section of CTA's survey addresses efforts of the

research and development community relevant to this survey. The

DARPA protocol suites has an historical significance and is

described in Section 5.4.1. Ther e are many commercia l

implementations of these protocols. Acceptance of the OSI

reference model and use of OSI protocols in the General Motors

Manufacturing Automation Protocol (MAP) is described in Section

5.4.2. The third effort , CRONUS, is a distributed operating

system under development by Bolt Beranek and Newman, Inc. for the

Rome Air Development Center (RADC), Griffis Air Force Base. This

project is detailed in the last section (5.4.3).

5-93
5.4.1 Defense Advanced Research Projects Agency (DARPA)

The DARPA protocol suites are relevant to the state-of-theart of Network Operating Systems because of their historical and

operational significance. DARPA has support definitio n and

implementation of a suite of protocols to implement a networ k

operatin g system. Ther e ar e numerou s vendors tha t have

implemented the DARPA TCP/IP protocol and offe r it as part of a

networking package; in particular, these protocols are included

in Berkely 4.2 BSD. The DARPA protocol suite is a standard

within DOD, but the National Academy of Sciences has recently

recommended that DOD adopt ISO protocols at layers 3 and 4.

The similarities of the DARPA and XEROX protocol suite are

that both are:

o independent of the local operating system,

o based on connectionless internetwork protocol,

o employ fewer protocol levels than OS I

(the DARPA protocol architecture is not layered)

The DARPA protocol suite illustrated in Figure 5-14 provides

the virtual terminal, file transfer, and electronic mail servers

as well as host servers providing time of day and internet

addresses corresponding to a user supplied name. These services

employ either a reliable transport protocol, Transmission Control

Protocol (TCP), or user datagram protocol. The network protocol

is the internetwork Protocol (IP) which is a connectionless

networ k protocol performin g such function s a s packe t

fragmentation and reassembly, packet lifetime control, as well as

notification of security level, and network address. This

protocol suite has been over a wide range of network s such as

5-94
APPLICATIONS:

SERVICE

PROTOCOLS:

INTERNET;

NETWORKS

VIRTUAL

TERMINAL

FILE

TRAN

USER-USER

[L

NAME

SERVER

TIME

SERVER

ARPANET

TRANSMISSION

CONTROL PROTOCOL

USER DATAGRAM

PROTOCOL

INTERNET PROTOCOL

SATELLITE

NETWORK

PACKET

RADIO

LOCAL

NETWORK

FIGURE 5.14; DARPA PROTOCOL SUITE

5-95
ARPANET, packet radio, satellite networks, X.25 networks, and

local area networks.

t

5.4.2 Manufacturing Automation Protocol (NAP)

A significant event in the acceptance of the OSI Reference

Model is the promulgation of the Manufacturing Automation

Protocol by General Motors. Although the specifics of this

standard are still evolving, it is clear that it will be based on

OSI Reference Model and employ OSI protocols. Thus, OSI will

make a significant penetration into a very large portion of the

industrial automation market.

At the 1984 NCC, a multivendor demonstration was performed

for a limited subset of the MAP. For this demonstration, a file

transfer based on the ISO protocol (used with the ISO Class 4

transport) was performed over IEEE 802 type networks (token bus,

carrier sense). Networ k and host components were supplied by

different vendors, thus the successful file transfer empirically

validated the concept of Open System Interconnection.

The architecture of the real-time network is still evolving,

e.g., types of nodes, backbone network, access networks, bridge

that will be required, etc. The protocols identified for

inclusion of Version 2.1 are enumerated in Figure 5-15, but again

the details of these protocols are still to be defined.

Although there are still many details to be finalized

regarding MAP, it appears that many vendors will support it.

Some examples of this support include (Systems and Software ,

March 1985, p. 30):

DEC providing a UNIBUS interface for the VAX/VMS environment

to a MAP token interface module.

5-96
FIGURE 5-15

MAP PROTOCOLS

1

2

3

4

5

6

7

7

OTHER

OTHER

OTHER

OTHER

OTHER

IEEE 802.4 TOKEN RING

IEEE 802.2 LOGICAL LINK

ISO CONNECTIONLESS

NETWORK SERVICE

ISO TRANSPORT

ISO SESSION

PRESENTATION

ISO COMMUNICATIONS

APPLICATION

SERVICE ELEMENT

FILE TRANSFER/ACCESS

METHOD (FTAM)

MANUFACTURING

MESSAGE-FORMAT

STANDARD (MMFS)

APPLICATION INTERFACE

DIRECTORY INTERFACE

NETWORK MANAGEMENT

PBX INTERCONNECTION

5-97
Texas Instrument announcing its TIWAY21 will be based on

MAP.

Allen Bradley introducing VISTANET family of products,

supporting MAP based on a SMBps broadband network.

OEM Software products for layers 3 to 7 for the VAX/VMS

environment.

Concord Data Systems providing a Network Control Computer

and token SCOPE analyzer.

In summary, although still in its early development phases, MAP

is a significant element of OSI activities.

5.4.3 CRONUS

CRONUS is a distributed operating system being developed for

the Rome Air Development Center (RADC), Griffis Air Force Base by

Bolt Beranek and Newman, Inc. (BBN). It is intended to promote

resource sharing among computers and manage the collection of

shared resources within a heterogeneous processor environment.

One of its primary goals is to support the development and use of

distributed applications. RADC, through its Distributed System

Technology Program, has recognized the potential that a

distributed systems architecture has for meeting future command

and control requirements. BBN has divided the project into four

phases: functiona l description, system design, system

implementation, and test and evaluation.

Key to the CRONUS design (FIGURE 5-16) is an object-oriented

view of the system. All system activity can be thought of as

operations on a collection of objects managed by the system and

organize d into objec t types. Objec t types may be files,

processors, devices, user records, and directories of catalog

entries. Operations invoked on objects depend upon its type.

5-98
Manager Design Conventions

Access Control Conventions

Object Manager Standards

Request & Reply standards (OP)

Message Encodement (OP)

Message Passing Protocols

small [packet] & large [stream]

IP Protocols

LAN

FIGURE 5.16: CRONUS LAYERED ARCHITECTURE

5-99
The CRONUS system kernel contains an object-based interprocess

communication facility which invokes operations on objects. This

facility is designed to be host transparent. A CRONUS library

will provide for a standardized interface to invoke operations on

objects. This includes conversions to and from a standard data

exchange format which facilitates interprocessor communication in

a heterogeneous computer environment. CRONUS will implement an

initial set of four object managers which will be used as

building blocks to support CRONUS applications software. They

are: ... .... -jo Catalog Managers - which, collectively, implement a

system-wide symbolic name space.

o Authentication Managers - which handle authorization and

access control

o File Managers - to implement the distributed file system

o Device Managers - to permit the correction of terminals,

printers, and other device resources.

Monitoring and control, and a user interface will be the two

r

initial applications software implementations.

To verify the CRONUS distributed operating system concept,

BBN will develop and implement a hardware testbed facility. The

initial hardware components to be utilized in this testbed are a

C/70 processor running UNIX, a DEC VAX running VMS, and special

purpose microcomputers called Generic Computing Elements (GCE's).

The GCE's are dedicated-function computers (all utilizing the

same architecture) and support: file and data storage, user

authentication, catalog management, device control and terminal

access. The C/70 and DEC/VAX will be utilized as general purpose

applications hosts and demonstrate processor and operating system

5-100
heterogeneity. In addition, to test the idea of a dedicated

processor for use as a C2 workstation, BBN will also augment the

computer in the network with a Sun Microsystems workstation.

Inexpensive .personal computers (e.g., Apple, IBM PC) are under

consideration for adding these processors to the network in the

future. All computing elements will be clustered and networked

utilizing an Ethernet LAN. Clusters will communicate using

internet gateways. TCP/IP protocol will be implemented.

Host processor operating systems have been modified only

minimally. Instead, the softwar e necessary^to integrate them

into CRONUS runs as an adjunct to the host 0/S.

5-101
6.0 Evaluation Relative to RASA

The detailed NOS requirements for the NASA environment are

obviously mission dependent, and during the course of this study

such requirements were being formulated for Space Station as part

of the NASA sponsored Data System Architecture Study (performed

by teams led by the TRW and McDonnell Douglas.) However, high

level NOS requirments can be formulated given the known operation

in the space environment. The unique characteristics of the space

environment are:

- diverse applications

applications with stringent delay requirements

- applications with very high throughput requirements

- high system availability requirements

Nearly all of the characteristics discussed in Section 4

would be useful in Space Station. The notable exception is that

terminal handling of classic TTY terminals probably would not be

required. Instead personal computers employed as workstations

would provide the terminal function (plus many other services)

These workstations would access the host via a local area

network rather being attached directly to the host. Because of

their intelligence, the workstations would function more like

hosts than classic TTY's.

Thus the CTA approach to addressing requirements is to

evaluate how vendors provide the characteristics described in

Section 4; this evaluation is discussed in Section 6.1. Then,

based on this analysis, CTA identifie d deficiencie s and

associated technical development issues; they are discussed in

Section 6.2. Finally havin g define d the broad range of

6-1
requirements and assessed the state-of-the-art of NOS

development, CTA prioritized implementation of the NOS features;

this prioritization is presented in Section 6.3.

6.1 Evaluation of Features

CTA did not identify any NOS product which featured a

comprehensive set of all of the NOS functional characteristics.

Many products featured either:

o a comprehensiv e implementatio n of a subset of the

functional characteristics, or

o a somewhat less comprehensive implementation of a larger

subset of the functional characteristics.

User-to-user communications service requires that the NOS

support inter-use r communicatio n an d user-to-system

communication. Services facilitating these capabilities include

message handling, printing, terminal handling, and conferencing.

CTA has indentified several products which support the first

three services. The latter service (i.e., conferencing),

however, was lacking in virtually all products. The electronic

mail capability of the message handling service emphasized text

and arbitrar y binary data transmission. Graphic s data

transmission was not explicitly featured in the vendor products,

however, bit-mapped displays in some cases would be handled.

This is a technology dependent issue too since there are various

mechanisms by whic h graphics data can be represented and

subsequently displayed. Raster scan, storage tube, and refreshed

vector monitors are the three principal technologies in use today

and require differen t methods with which to represent the

displayed data. None of the products offered supported the

6-2
capability for facsimile or voice data transmission. Packetized

voice and digital facsimile are at the forefron t of technology

and thus these two capabilities are usually handled as

independent transmissions. Print service dominated the message

handling capability of virtually all NOS products identified

during the survey. These were often handled by print servers

which spool requests from users on the network. Some vendors

permitted any workstation to act as a print server and this could

be dynamically assigned by the user. On many of the PC based

systems, the print server was a specialized processor dedicated

to just that one function. Furthermore , these systems often

limited the quantity of print servers to just one or two such

systems. Most ofte n their use was advocated for offic e

environments which shared an expensive letter quality printer for

final document preparation. Virtually all vendors offered

terminal handling services, often with a windowing capability.

Again this was primarily for presentation of textual data.

Facsimile, voice, and graphics were not handled. Some of the

more sophisticated systems offered a virtual terminal capability

thus enabling a user to utilize his/her host workstation as a

dumb terminal to access and utilize a remote host and its

resources.

Job Migration was most often manifested by implementions for

remote procedure call and interprocess communications services.

Job transfer and manipulation services were conspicuous by their

absence. Interprocess communication s was evident in the

extensions to the UNIX pipe mechanism offered by several vendors

6-3
as well as a proprietary implementation by DEC in its DNA

architecture. Remote procedure call (RFC) is most prominent in

UNIX extensions. The extensions have been to the UNIX for k and

exec calls. A description of the most comprehensive

implementation may be found in Section 5 of this report for the

Locus Computing Corporation produc t LOCUS. Yet anothe r

implementation has been done by Sun Microsystems' NFS product.

Charles River Data Systems' UNOS/Universenet product line have

also extended the basic UNIX featur e to implement an RFC (see

Section 5).

Data migration , and specifically File Service was a

prominent feature of virtually all NOS products surveyed.

Implementations were as basic as disk servers, which offered

little if any protection of multi-user access conflicts, to file

servers offerin g some security and multi-use r protection

features. File servers were found also to be at two ends of the

spectrum: some vendors offered a single, dedicated file server

whereas others offered a more sophisticated approach to enable

users to access a file anywhere on the network. The LOCUS

product is an example of the latter capability. In addition,

many sophisticated systems (e.g., LOCUS) offe r complete

transparency such that the user does not know (or care) where the

file is located. Locus, for example, also offers multiple copies

of files on the system; automatically tracks and updates them;

and assures the users access to the most recent version. UNIX

based systems, (e.g., 4.2 BSD) have also improved upon

traditional file structuring to offer improved performance in a

distributed file system environment. Data representation

6-4
services were minimal for most vendors surveyed. This was due

primaril y to the fac t that most NOS products wer e for a

homogeneous computer environment (e.g., PC's and compatibles; or

DECNET) and thus required few data translation requests. Vendors

supporting heterogeneous computer environments (e.g., NRC Fusion)

did supply utilities to convert, for example, UNIX file formats

into MS-DOS (and vice versa) compatible formats.

Network control is comprised of three elements: recovery

service, network management, and directory service. Locus was

once again conspicuous because it went to great pains to assure

that its replicated, distributed file system maintained its

integrity in the event of system failure. It assures this with

its atomic update feature which makes an updated file available

to a user only after all modifications have been successfully

performed to the data set. In the event of a failure, the user

may access either a copy of the file stored elsewhere or safely

V

access the previous version of the file. Locus assures that a

file is not contaminated by "partial updates". This featur e is

of particular importance to many processing environments, notably

space station. It demonstrates at least one element of fault

tolerance required in such an environment. Network management

capabilities ranged from simple statistics gathering packages

(e.g., number of packets processed, network speed) to dynamic

configuration of the system.

Also lacking was an adequate directory service for most

systems. Most products made the assumption that the user knows

wher e the other services (e.g., print, fil e servers) wer e

6-5
located. Locus' file transparency made the file issue moot since

the user was not concerned "where" the file was as long as it

could be accessed.

Common features to other services identified are the

transport and network security. Some vendors have planned (e.g.,

(NRC Fusion) to incorporate TCP/IP or class 4 ISO transports, but

most vendors have relied upon LAN technology reliability and have

not emphasized this capability. Network security was also

minimal to best. Most offered multi-user lockout access to file

servers but terminal and file access was usually limited to

password protection. Encryption (e.g. DES) of data files and/or

transmission was not an "advertised" capability. Other potential

forms for user 'authorization access was minimal at best.

6.2 Deficiencies and Issues

In this section, CTA identifies the functional requirements

of NOS that are not available in the current NOS technology (as

evidenced by lack of commercial products or demonstrations) also

the technical issues associated with providing these features are

discussed. Three major areas are addressed:

- portability and performance,

- adherence to OSI protocols,

- completeness of functionality.

6.2,1 Portability and Performance

In its review of the state-of-the-art in Network Operating

Systems development, CTA has determined that there are major

tradeoffs between portability of the NOS softwar e and the NOS

performance, especially in the UNIX environment.To achieve the

6-6
portability objective, the NOS software could be implemented as

an application (relative to the local operating system) and

employ a standard set of system calls to invoke the services of

the local operating system. There are two difficulties with this

approach, namely:

there is no standard set of operating system calls

applicable for a range of computers from micros through

mini's to mainframes.

communications software implemention requires real time

I/O features that may not be provided to applications by

the local operating system.

There are three standardization efforts that are currently

ongoing to establish an operating system interface:

IEEE P1003 Committe e standardizin g a UNI X based

interface,

IEEE 855 Committeestandardizin g a microprocessor

operating system interface,

- ISO TC 97 SC 5 WG 7 standardizing Operating system

Command and Response Language.

Unfortunately none of these efforts are close to establishing an

accepted standard, but the IEEE P1003 effort is of the most

interest because of the pervasiveness of UNIX in the current

market.

Currently there are a large number of variations of UNIX

(including the most popular versions AT&t Systems V, Berkeley

4.2, and Microsoft XENIX) which the IEEE P1003 Committee is

attempting to standardize. The scope and purpose of this project

per its charter are "to define a standard operating system

interface and environment to support application portability at

the source level".

6-7
This effort entails three major components:

1. Definitions - Terminology and objects referred to in the

document. In the case of objects, the structure,

operations that modify these, and the affects of these

operations need to be documented as well. (Sample Term:

Pipe, Sample Object: File Descriptor)

2. Systems Interface and Subroutines (C-Language Binding)

including:

A. The rang e of interfac e & Subroutine s in

the/usr/group document.

B. IQCTL/TermlO

C. IFDEF Specifications

D. Real Time (Contiguous files, synchronization, shared

data, priority scheduling, etc.)

E. Device interface, including Termcaps/Terml0

F. Job Control, Windowing

G. Network Interface (but not Protocol)

H. Distributed Systems

I. Device Drivers

J. Error Handling & Recovery

3. User interface issues, including:

A. Shell, Command Set, Syntax

B. Portability - Media/Formats

C. Error Handling & Recovery

In all of these areas, consideration will be given to

defining the impact on security, international usage (language

and character sets, etc.) and application needs such as

transaction processing.

Unfortunately network protocols (along with graphics, data

base management, record I/O) are outside the scope of the current

P1003 project. However this provides the opportunity to use OSI

protocol primitives as the network protocols. Ultimately this

offers the opportunity to employ the ISO OSI protocols in

conjunction with UNIX.

The relationship between the NOS and the local operating

system is depicted in Figure 6-1. As shown in the figure the NOS

intercepts all calls that could have remote significance; typical

6-8
LOCAL

r

I •*

I

«—>

I/O

i

vo

LOCAL

OJT

-oS

O 2

o g •30 r

§-< t-o

Figure 6-1 Software System Architecture
examples are file access and interprocess communication service

requests. The redirector is responsible for processing these

requests and determining if the request should be processed

locally or remotely. There are some requests the the operating

system that would always have local signiface, e.g. clock service

requests to read the local time as to be interrupted often a

specified time cust, memory management operations.

Note in the OSI environment the redirector must reside above

layer 7 of the OSI and is only concerned with remote access.

However in some cases such as the IBM PC, the redirector is shown

to reside directly above layer 5, the session layer. In this

implementation OSI layers 6 and 7 are null.

If the redirector NOS interface software determines that a

service request can be handled locally, then the NOS interface

passes the request directly to the local operating system. Then

the local operating system with its local hardwar e I/O driver

interfaces with the hardware.

If the redirector determines that a service request must be

handled remotely, then the redirector passes the request to

communications protocol software. As shown in Figure 6-2, this

communications protocol software could be an implementation of

ISO OSI protocol suite or an appropriat e subset. This

communications software would employ a network I/O driver to

physically pass bits to the communication network. The OSI ISO

layer 1 protocol is typically implemente d in hardwar e as

indicated in the figure.

Since the communications software employs a substantial

amount of real time I/O, the keys to providing performance are

6-10
LOCAL

* V

LOCAL

i —1

01?

oil

OU'

on

I ,

Figure 6-2 Software System Architecture with OSI

OST

C

>IT

3 a
efficient means of interprocess communications and responding to

interrupts. If adequate services are not provided by the local

operating systems, then the NOS may have to be integrated with

the local operating system to implement special services.

Typically the services provided by UNIX , which was

originally developed for timesharing, do not provide adequate

performance with respect to these requirements. Specific

features that are required are:

o message oriented interprocess communication (rather

than byte oriented)

o interrupt driven communication to alert a process that

ther e is a message waitin g for it (rathe r than

implementing polled I/O)

o semaphores to synchronize communication (rather than

requirin g a process to implement synchronization

techniques)

More recent versions of UNIX (e.g. AT&T System V) do provide more

efficient interprocess local communication using shared memory

and semaphores.

The handling of interrupts associated with the real-time I/O

may impose stringent scheduling requirements on the local

operating system, which are typically not provided. Thus special

servicing may have to be provided to the NOS.

Because of these stringent service requirements the local

operating system and the NOS may be integrated. This integration

may involve either:

o special service request available only to the NOS or

other local operating system modules,

o access to specific local operating system data

structures.

Wit h these special requirements, the NOS is no longer an

6-12
application, and the difficulty of porting the NOS is

substantially increased.

CTA believes that the standardization efforts will not

culminate in a useful interface within the needed time frame.

These standardization activities should be tracked, but CTA

recommends development of a standard operating systems with

networking for NASA. This interface should be UNIX based

complemented with a selected set of OBI protocol primitives. The

actual implementation of the NOS with the OSI protocols is

discussed in the following section.

6.2.2 Adherence to OSI Protocols

Although many systems and products have been developed, very

few adhere to the ISO OSI Reference Model defining a seven layer

protocol architecture. Even fewer vendors have implemented ISO

protocols corresponding to the OSI layers. The latter point is

not surprising since these protocols are just emerging as

standards.

The lack of adherence to the basic OSI Reference Model can

be explained in terms of the systems environment and requirements

being addressed. Most of the development associated with network

operating systems has been for local area networks where the

developers have attempted to achieve performance transparency.

In order to do so, they have developed simpler protocols with

fewer layers. This is a reasonable approach because of the low

error rate and low variability in transport delays. For example

sophisticated transport protocols with capabilities to handle

packets frequently received in error or occasionally arriving out

6-13
V

of order, or having long transport delays are not needed.

Similarly with only a single LAN, there is no need for any type

of routing.

Another motivation for not implementing the OS I protocols is

the memory requirements. To achieve high performance many of the

UNIX networking capabilities are being integrated into the local

operating system kernel. In fact most of systems developed are

closer to distributed systems rather than network operating

systems. To incorporate the ISO protocols into the kernel would

make the local operating system memory requirements very large.

Note IBM PC based systems build on the operating systems rather

integrate the NOS into it.

For the problems currently being addressed, the approaches

being implemented are probably optimal. However as problem

complexity increases with internetworking of multiple LANs as

well as interconnecting LAN's with Wide Area Networks, the ISO

OSI protocols will become more appropriate and most likely

necessary.

Ther e are a large numbe r of vendors developing OSI

protocols. These products will likely be used in conjunction

with local area networks. This will achieve the standardization

and interoperability, but may still introduce a performance

problem. To alleviate this problem, specialized communications

printed circuit boards with faster processors will be developed.

Potentially, all seven layers could be off-loaded to a

communications board with the redirector processing service

requests to determine if they should be processed locally or

passed to the communications board for remote processing.

6-14
However, there are some practical considerations. For example

the file service needs access to the local file system, similarly

the commitment, concurrency, and recovery service would need to

access to the file system to store data that could not be stored

in onboard memory.

Partitioning the NOS such that layer 7 resides on the local

host processor and layer 6 resides on the outboard communications

processor is feasible. However special attention must be given

to the layer 6-7 interface because the presentation layer

" • '«.

performs syntax conversions which are local operating systems

dependent. It would not be desirable to make the communications

processor local operating system dependent.

If layer 6 is implemented in the communications board and

the layer 6-7 interface employs an Abstract Syntax Notation or

X.409 encoding, then the communications board would be local

operating system independent thus is a desirable implementation.

In the long term these are all potential solutions and

vendors are beginning to provide products to implement them.

6.2.3 Completeness of Functionality

In this CTA presents the major functional deficiencies in

current NOS technology; these include fault handling, remote

interprocess communication, interoperability, conferencing, and

directory.

6.2.3.1 Fault Handling

Response to fault conditions in the network is one of the

serious deficiencies in Network Operating Systems development.

6-15
However, it is an area where substantial research is ongoing and

recent OS I standards are incorporating features to handle these

conditions. OSI protocol layers 1 to 4 will detect that a

message cannot be successfully delivered, and it is the

responsibility of the higher layers and the application to

rectify the fault conditions.

As discussed in Section 4 one of the key issues associated

with fault handling is the partition of responsibility between

the NOS and the local operating system. This functionality is

being incorporated in the OSI architecture at the:

o session layer with the provision of checkpointing

features, and

o application layer with the committment concurrency, and

and recovery protocol.

With the implementation of these protocols substantial

progress will be made in the fault handling area. However this

problem must be addressed in total including NOS and local

operating system responsibility.

6.2.3.2 jlemote Interprocess Communications

Interprocess communications service will be required to

support distributed control programs executing in remotely

located hosts. In this survey few vendors have been identified

that provide this capability. The required features of this

service are:

o connection control to establish, maintain and release the

connection

o message oriented communication (as opposed to byte

oriented communications provided by the original UNIX

pipes)

6-16
o short delivery times (1 second as opposed to many

seconds or minutes)

o very high throughput applications

o synchronization procedures to coordinate access to

resources; this may be implemented via a semaphore or

event counts.

In particular, the use of the Remote Procedure call to

implement distributed control is not adequate because of

deficient response times, especially in light of high throughput

requirements. The remote program may not be loaded. Reading in

the program from disk and loading it will take substantial time.

Furthermore there is no ongoing dialogue between the local and

and remote programs so program loading may have to be repeated

with each communication.

Potential solutions for implementation are message

communications enhancement to the UNIX pipes and the IBM LU 6.2

protocol.

Although the underlying hardwar e usually has a broadcast

capability, multi-destination communication is not usually

provided by the NOS. Instead, users must typically request

transmission to each individual. This capability is lacking

because of the complexity in handling the associated

acknowledgement and retransmission protocols. However, a multidestination capability has been incorporated in some research

projects such as MICROS and STARMOD [67, 68].

6.2.3.3 Interoperability

As discussed above, developers have been categorized into two

groups, UNIX and IBM PC based vendors. To date there has been

6-17
very little work done to make these systems interoperable. The

notable exceptions to this are the Intel OpenNet and Digital

Research Fusion and PC DOS systems.

The most significant incompatibilities are the structure and

the data representation services. In particular there are few

efforts to distribute graphics or images between incompatible

systems.

The purpose of Open Systems Interconnection is to provide

this compatibility, but so far such interoperability has been

achieved in practice only up to the transpor-t level. With the

development of presentation layer and file service protocols in

particular, this interoperability will be achieved. Currenly it

is technically feasible, but the requisite standards are still

emerging and not yet widely accepted and implemented. Thus,

although this is a current deficiency, it will be ameliorated.

6.2.3.4

A conferencing capability was not included in any vendor NOS

product that was surveyed. However, conferencing capabilities

have been developed in the research community and DECoffers a

product VAXPHONE (TM of Digital Equipment Corporation) but it is

not included in DECNET.

The lack of a conferencing capability is not viewed as a

major limitation because voice communications can be used for

conferencing. Ultimately voice communications may be integrated

into the LAN further reducing the requirement for conferencing.

However, there are still useful, but not critical, features of

of the conferencing service (such as the conference record and

6-18
templates for action items, resolutions/ etc.) that could be

implemented.

6.2.3.5 Directory

The lack of a Directory Service for locating users and

resource s in nearly all of the commercia l products was

surprising. Successful directory services have been implemented

by XEROX (CLEARINGHOUSE) and DARPA (Name Server). In some cases

such as the IBM Network feature, protocols are implemented to

query the network upon demand to locate a resource.

The lack of the directory service for the prototype is a

major deficiency.

6.3 Prioritization of Features

In this section CTA ranks the features of an NOS relative to

their importance in the NASA environment. The prioritization of

features is inherently a subjective judgement considering that

the requirements set is not firm To prioritize features for

implementation CTA has employed the following criteria:

o importance of feature,

o implementation complexity,

o technical maturity.

Using these criteria has categorized the features of a

Network Operating System into the following priority areas as

shown in Table 6-1:

o Connectivity features necessary to deliver bits through

the computer network.

6-19
Table 6-1: Prioritization of Functionality

Connectivity

Layers 1 to 5 depending upon LAN functionality

1. BASIC

Pile Service

Message Handling

Remote Procedure Call

Print Service

Directory Service

Security

Screen Interface

2. Advanced

Level i

Process-Process

Fault Isolation-Recovery

Data Presentation

Level 2.

Conference

Statistics Gathering

Job Execution Language

Level 3.

Job Transfer and Manipulation

Data Base Management

Document Architecture

6-20
o Basic features providing a broad range of essential

capabilities implemented in a straightforward fashion

which provide user-user, user-device, and process-process

communication.

o Advanced features introducing capabilites to make the NOS

operation more sophisticated. These features, are

furthe r broken down by levels one (highest) to three

(lowest) based on subjective evaluation of value added

versus implementation complexity.

The connectivity features are absolutely essential in order

to exchange information. However the scope of the functionality

needed will depend upon the particular network over which the NOS

will operate. For example if the network is a single LAN such as

the Sperry Fiber Optic Bus Demonstration System or an Ethernet

(TM of XEROX Corp.) then a reliable link protocol (between source

and destination hosts) with a session protocol to provide the

logical multiplexin g of connections would be sufficient.

However, if multiple local area networks are to be employed then

protocol layers 3 and 4 would also have to be included. This may

include a initial circuit protocol such as X.25 to preallocate

resources in bridges, as well as ISO transport protocol. If the

LAN is to be internetworked with a long haul network , then the

class 4 transport protocol may be required with its packet

retransmission schemes. In summar y the specification of the

protocols will be application dependent, but they will easily fit

into the 061 architecture.

The Basic set of features would provide a wide range of

services for user-server communication (file service and print

service), user-user communication (message handling), and

process-to-process communication (remote procedure call). For

the file service and message handling service a complete set of

6-21
the ISO protocols would not have to be implemented to achieve a

very useful level of functionality. The set of specific features

to be implemented is a subjective judgement, but a set of key

features can be identified. Key features that would be required

in the file service are:

file sharing at the record level

file ownership and access control-reading, writing, and

modifying

- file locking to ensure concurrent updates are not made

hierarchical file structure

The message service should include primitives for document

submission delivery, delivery of copies, and probing of status.

Also local in-box and out-box utilities should be provided to

facilitate tracking documents transmitted or received.

The print service should include a spooling capability with

elementary capabilities to recover printing from a specified

point and routing of this print request to an alternative

printer.

The remote procedure call is included in the Basic set

because it would provide an elementary means of implementing

distributed control. Furthermore it has been usually implemented

and is offered with many systems. However, as discussed above it

will not provide adequate performance for applications with

stringent response time requirements. Thus a true process-process

communication will be ultimately required.

Also the file service requires the definition of a virtual

filestore. Since the on-board Space Station computer selection

is a design issue, the virtual filestore and physical filestore

6-22
could be identical. However, this woul d not address the

interoperability problem with ground hosts or workstations which

may not employ a compatible file structure.

Note that implementation of an arbitrary subject of features

in a protocol does not conform to the guidelines for

implementing the protocol. Thus it would not be possible to

communicate with non-Space Station implementations, which

implement a specific subject defined in the standard. This may be

acceptable for a prototype implementation, but certainly not for

deployment in an operational environment.

The Directory Service is included in the Basic features

because of its utility to enable the users to employ the other

services. For example users would be able to determine where

available resources such as file services or applications are

located or be connected directly (to them) as well as user

locations.

Termina l handling is not a requiremen t in the NASA

environment because PC's appear as hosts. However, a screen

interface is required in order to display information on the user

device. It would also include a user help feature such as a menu

of commands and on-line user documentation.

Security features are essential to allow access to resources

as permitted. It is envisioned that initially passwords would be

implemented to enable users to access file or print servers and

execute jobs on remote systems. These features are commonly

available.

The advanced set of features included in level 1 are very

6-23
important, but not quite sufficiently important to be included in

the kerne l of Basic features. The process to process

communicatio n functio n is very important, especially for

distributed control applications. However, some rudimentary

feature of distributed control could be implemented with the

remote procedure call (although stringent response times could

not be achieved) Thus the process-process communication is

included in the advanced set. The specific process-process

protocol is still to be determined but the IBM LU 6.2 is a

possible candidate because of the lack of an ISO standard.

Fault Isolation and Recovery is also very important, but it

is not included in the kernel because

o Relatively low rate of failures in the LAN environment,

especially with the Fiber Optic Bus Distribution System

which has redundant network transmission media and

interface unit components.

o Research is currently on-going in the fault recovery

area.

o The uncertainty of acceptance of the ISO commitment,

Concurrency, and Recovery standard.

However, as a first step in the NOS, checkpointing should be

implemented as part of the session layer.

Data Representation is another very important feature but it

is not included in the kernel because there will likely be a

large degree of homogeneity in the initial implementation. This

reduces the importance of providing data representation services.

However , as heterogeneity is introduced, the data representation

service will be required. It should be implemented with an

incremental capability.

o Static set of syntax tables for each user established

in advance;

6-24
o Negotiation of the syntax during establishment of the

connection;

o Dynamic switching of context during a connection; this

would require implementation of the ISO presentation

layer protocol.

In particular, communications of graphics will be required.

The features in level 2 of the advanced set are not nearly

as important as the level 1 features, but they are useful

additions. Conferencing is given a low priority because voice

communications already provides a means of conferencing which

will be both to both prototype and space station users. In fact,

voice communications could possibly be accommodated by high speed

LAN's such as the Fiber Optic Bus Demonstration System.

Statistics gathering was assigned a low priority because of

its minimal utility in providing user services. However, it may

be assigned a higher priority because of administrative

procedures, e.g. accounting procedure may have to be implemented

to effect chargeback to the users.

The Job Execution Language is a useful enhancement to enable

users to employ the Remote Procedure Call. This would provide

them with a means to specify:

o on what processor a job should be executed,

o when it should be executed, and

o alternate procedures in case of fault conditions

Protocols in level 3 may be useful but are not recommended

for immediate implementation. The Job Transfer and Manipulation

Standard is complex and a useful capability can be provided with

just the remote procedure call and a job execution language. It

need not be implemented at all.

6-25
The Document Architectur e and Distribute d Data Base

Management System (DBMS) are useful capabilities which build upon

the Message Handling Service and File Service respectively. Thus

they are defined as advanced features. Ultimately the DBMS

service will be required and should be implemented while the

requirements for Document Architecture are less clear.

6-26
APPENDIX A

Product Templates

(In Alphabetical Order by Vendor Name)
Advancsd Coaputer Coaaunications (ACC) - ACCES jNS

ORIGINAL PAGE ?S

OF POOR QUALfTY

ITEM DESCRIPTION

1 Naas/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone Nc'si/Contact:

5 Docusentation Availability/Source:

6 NQS Hardware Ispleffientation:

—-NetHork

—Host Coeputerts)

7 Host Operating Systea Naaefs):

S Ifiplsflintation Language:

9 Maintenance Support:

Advanced CcaputEr Comsunirations (ACCi

720 Santa Barbara St

Santa Barbara, CH 93101

ia05) 963-9431

TBS

Ethernet,others

DEC PDP-11,VAX ;

Charles Rivar 3ata Syitsss procesiDrs

UNIX (Eystssi V, Version 7.4^2 BSD, UNQS!

DEC RS!! and VHS

T50 t Uu

TBS

Xsrox KNS Architecture

Netvicrk Uyer iL3! to Presentation (L6)

11 List of Services for Each 1SG Layer;

12 Hajor 0/3 Functions laplsnented:

13 0/3 Hodificationisi:

14 Pries:

15 User Added HDalications S/H:

Network Hanageaent and Statistics

Reiote Procedure Call

Data Representation

Reaote File Transfer Service

TBS

TES

Applications prcgra&s Britten in C

isay interface with ACCES l\S protocol packace

1. Supports fero;: W. CQisaunications protocol

2. File Transfer and Virtual Tarainal support

for XNS networks

3. XNS protocols supported:

SFP - Sequenced Packet Protocol (transport layer of ISO!

IBP - Internet Bataoras Protocol (ISO netsork layer!
flicyon Corporation - Distributed Fil e SysteetBFS)

ORIGINAL PAGE IS

OF POOR QUALITY

ITEh i ITEH DESCRIPTIO N

1 Nase/Availafaility of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone Nols)/Contact:

5 Dacuaentstion Availability/Source:

6 NOS Hardware lapleisentation:

—-Network

—-Host CcfsputeHs)

7 Host Operating Systes Naseish

8 Implementation Language:

9 Maintenance Support:

10 ISO Bode; lapleasntation:

11 List of Services for Each ISO Layer:

12 Major G/S Functions Ispleaented:

13 0/S Hodificationis):

14 Price:

15 User added Aoplications S/W;

Diitributid Fil e Syslea (DPS)

Alcyori Corporation

8716 Production Avenue

San Diego, CS 92121

(619! 578-0860

Source code availabl e

Ethernet

HCsSGXO-faaseri workstation

RESULUS Scoapatible with UNIX y5,V7,3III,SV}

"C» (for DPS)

res

not iaplassented

,-/a

Resets file access

Seaote prograa execution

REEULyS is a p"rietary o/s

$2400 - single copy binary s/C compiler

?220CO - single espy source a/'C cospiier

Price of DPS is (TBS)

TBS

Cosaents: 1. DPS protocol is based upon DELTA-! packet transport

oroioccl developed at Laurence Liysrscre

National Laboratory. It is described in "DELTft-T

Protocol Specification" by R» Satsor 4/15/83.

2. Heterogeneous CPU environment is possible aith DPS

3. Pile and Record locking supported

4. Diskless workstations possible since ail

iils I/O aay bs done at rsaote workstation B/O

the need to transfer fil e ta local workstation

5. Future ispiesentations planned for DPS:

- SEC VMS.support

- Data General fiOS support

- 4.2SSD UN IK support

- AT4T Systes III support

- Lintech uNETis suooort
ftoolio CoiBDuter. Inc - Aoollo DOMAIN

ITEM ITEM DESCRIPTION

1 Naie/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Docuaentation Availabilitv/Source:

6 NOS Hardware lapleaentation:

—NetHork

—Host Cosputerls)

7 . Host Operating Svstea Nase(s):

8 laplefflentation Language:

9 Maintenance Support:

10 ISO Model laplesentation:

11 List of Services for Each ISO Layer:

12 Major D/S Functions lapleaented:

13 0/S Modification(s):

14 Price:

15 User Added Applications S/N:

Aoollo DOMAIN

Aoollo Coaouter. Inc

15 Elizabeth Drive

Chelssford. MA 01824

(617) 256-6600

Donovan Buell. Jr.

TBS

Token Ring LAN

Apollo workstations - Motorola M680xO-based

AEGIS (proprietarv)

AUX (UNIX - based)

•C"

TBS

Not ispleaented - uses non-layered

proprietary approach

N/A

Real-tiae.fflultitasking

Message handling,print service.terninal handling

reaote procedure call.interprocess coeas

file service

network aanageaent.network security

AEGIS is a prorietary 0/S:

AUX - proprietary UNIX iapleaentation

Servers: $9750 - $56.500

Coaputational Nodes: $9900 - $74000

AUX $300 per node: $6500 per site (up to 100 nodes)

see vendors cosprehensive price list

for detailed pricing inforaiation

Available via software developaent tools

under AEGIS and AUX Q/S's

Coaaents:
AST Research - PCnet-II

ORIGINAL PAGE SS

OF POOR QUALfTY

ITCH i i i_;t ITEM DESCRIPTION

1 Naoe/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone Noisi/Contact:

5 Documentation Availability/Source:

6 NOS Hardnare lapleaentation:

—Network

—Host Computer is)

1 Host Operating Systes Naaeis!:

8 Implementation Language:

? Haintanance Support:

10 ISO Model Isipieaientaticn:

11 List of Services for Each ISO Layer:

12 Hsjor.G/ S Functions Iflipleiented:

13 Q/S «oditication(s):

14 Price:

15 User Added Applications S/H:

PCnet-il -

AST Research Inc.

2121 Alton Avs

Irvine, CA 927S4

(714) 963-1333

Debbie Hassstt

Users formal

Installatio n ilanual

Prin t Spcciing Manua l

Technica l Reference - Manua l

twisted pair (baseband bus (CSilft/CA!

IBH PC.XT.AT, or portable

PC-DOS 2.0.2.1,3.0,3.11«icrasoft Networks 1.0

Assembly and

 !'Ca

board return or exchange

no field maintenance

5/3 updates orovided

Does not confers to ISO ssodei

File sharing, print spooling

File, record security protsction

TBS

«95 and uc

TBS

1. Coaas boards by Orchid TecnnQioqy

2. Proprietary C3HA/CA protocol

3. u'ses reliable datagras service

4. SNA/BSC Qdtesay vs/3270 cosiaunication

5. PC's can access up to 16 disk voiuaes

6. Dedicated file and print servers are not

reouired, Shared PC's can also function as workstations.
Bolt. Bsranek, Newman - CRONUS

ITEil DESCRIPTION

1 Nase/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone Noisl/Contact:

5 Documentation ftvailability/Source:

6 NQS Hardwar e Iffipieiaentatian:

—Network

—Host Computer is)

7 Host Operating Systeis Nsissis):

8 Ispleaentatinn Language:

9 Maintenance Support;

10 ISO Hocel Ifflplesentatiori:

11 List of Services for Each 130 Layer;

12 Hajor Q/S Functions laplesented;

13 'Q/S rlooificationls;;

15 User Added Applications E/W;

CRONUS

Bolt, Seransk, NewBan (BBN)

SO ilouiton Street

Coabridge,i1asa. 02238

Richard E. Schant: - principal investigator

!617; 491-1330

SEN Report 13835 - CRONOS, ft Distributed Operating Systsss:

Phase 1 Final Report January 1985

BBN Report S5879 - CRONUS, A Distributed Operating System

Functional Detiniticn and Systss Concept June 1982 (revised 1/85)

currently Ethernet

DEC VAK,C/70, Sun iiicrosystess sorkstation

UNiIiC/70}, vMEiVAiO, 4,2B£DivAX;

see no'e i ueiow

net ISO. but a layered approach

n/a

Object sanacsaent

Standard interprocess CDissunications facilit y

Systii? wide distributed file systes

Sy=t33 wide symbolic ase space for all types of objects

Facilities for process Jiansgssent

User and process authentication

Standard access control discipline for all object types

iJser interface for all CRONUS and asplications services

Monitoring and control services

TBS

not applicabl e - see note 1 belovs

TBS

1. CRONUS is a research project currently in progress

at BBN Labs for the Ross Air Sevelopsent Center

Sriffiss Air Force Ease

2. HEtergsnecus clusters cf cpu's supported

3. lisa of object oriented design

4.

 c!he CRONUS distributed operating system is intended

to proaots rssourrs sharing asong inte'connected

ccsputsr systess and sanaqe the collection of resources

vihich are shared. Its isajor purpose is to provide a coherent

and iritsgrat-id systtia based on clusters of intsrcornected

hpyO1" "!*.£.-;.-HHC rrilT.r:!- f j»" - f" ^ii-inn-ir ^ f S -

 r-Z\:

~-'. - H;Ti TTf 5~;T

i:C '- _ : ; _ :) i. -j ii_- '_ 'Jui v -u i. •_ - ? ', .• j-^J J'^^ J: _ '_ . ! : - - _ ^ ii: _ 11 - 2:i d

: • .- .1 .-1 1 -I • r- i ^ 1 '-. r : f - fl - -! f !-'.--.*•' .1 - .- ^ u C'

 SJ C -1 -. - I- - - C u ~

-:-- V: Jir-\.i l..-U:.ZiJ viUy 1 i. •-.«'-- «irl J i-^E* fi:>:'_ll

 !

_ u L'u J
Charles River Data Systeas - UNIVERSE-NET

ORIGJ1MAL iS

OF POOR QUALITY

ITEH ITEM DESCRIPTION

1 Nase/Availability of MOS:

2 Developer/Vendor:

3 Address:

4 Telephone Nois)/Contact:

5 Documentation Availability/Source:

£ NOS Hardware Iinplesentatian:

—Network

—Host Coaputer(s)

7 Host Operating Systea Naoels):

8 laplenentation Language:

9 Maintenance Support:

10 ISO Model lapleaentation:

11 List of Services for Each ISO Layer

12 Major Q/S Functions iapleaentsd:

14 Price:

15 User Added Apolications S/M:

UNIVERSE-NET

Charles River Data Systeas

933 Concord Street

Fraainghaa. hass. 01701

(617) S26-1000

Dick Swes, Manager

Network Software i Operating Systea Deveiopaent

List TBS

802,3!Ethernet) i 802.4«Tokan Ring!

PC,HCR,KDneywell,!r,tel,CRBS Universe (68000-based)

UNOS and UN/Systea V (UNIi-based)

npu

u

Built-in test facilities

Ispleaierits all 7 ISO/OS! layer protocols

L6 File 5Ystsa interface

L7 Electronic sail.messaging'UNIX Write coMand;,

Printer sharing.virtual tarsinai

interprocess cofflfflunicatioRs,fiie sharing,

electronic raailiiiiessagingjprintsr sharing,

virtual tsrsina!,fi!e transfer using draft ISO FTP

Network OSI layers 1-5 are included in the

G/S by linking the network code with UNOS

kernal to optisite performance and allow

faster access to systea functions. Network

is linked to ONOS as i. standard driver

so that the network can be called as if it

were using a driver using standard OPEN,

CLOSE.READ, etc.

Appro;;. $1500 per node

Supported as an initial objective of the

product. Easy addition of different network

sedia via addition ot UNl'S device Driver.

Consents: (15 Session control functions are acre available. Thus

applications wii i tenu to use '.hese iunctior;s ratner titan

duplicate session functions in each applications prograa.

!2) Since netaork code is linked to 'JNGS and is treated

as a device driver, network access is provided to orcgraas

and fil e systea in a aiannsr identical to traditional

device access.

:7\ •I-,,,-..-,-..-'-- k.-H- 'ip.--.|(i^yi "J -ina iHAM\ -ra- -.--)•«-"•!'.- \.- w'L'ju-J. --:- J'."-ii i'_"_al \Lr.j'.; s-S'-i ^l'_c? .f.nn? 2: ia Sir'.i.ui fi I

;4! Suilt-in test facilities available.

(55 UNOS devrljped to support real-tiae and netsiorkinc

snvirofisents. LiKOS supports:

.. .Synchronizati::r,prioriti:ition,i allocation of resources

...Resident locking of processes

,,.Pressptive priority scheduling

.. .Llssr-controiied priorities

...Fast interprocess contest Snitching i interrupt service

...Ssnsrslized exception processing

...Synchronisation and scheduling aechanisas

...Designed for sulti-user systsas
Corvus Svsteas - Qinishare.Offlninet ,.

ITEM ITEM DESCRIPTION

1 Nase/flvailability of NOS:

2 Develooer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Documentation Availabilitv/Source:

6 NOS Hardware Implementation:

—Network

—Host Coaputer(s)

7 Host Operating Systesi Na§e(s):

8 lapleaentation Language:

9 Maintenance Support:

10 ISO tlodel laoleaentation:

11 List of Services for Each ISO Layer:

12 Major 0/S Functions Ifflpleaented:

13 0/S Modification^):

14 Price:

15 User Added Applications S/W:

Oaininet.Oini share

Corvus Systeffls

2100 Corvus Drive

San Jose. CA 95124

(408) 559-7000

Tos Dowd - sales

Bruce Bvrd - technical

°Svstei Manager Guide"

"Mass Storage General Technical Inforaation"

"Osminet 5TP

RS-422 twisted pair CSMA/CA

PC's or coapatibles,Apples

DEC Rainbow, TI Professional

PC-DOS 3.0

USCD - P svsteu

s/w updates for bug "fixes" onlv

h/H board exchange,800 nuiber for support,

and on-site consulting available

Unknown

TBS

Printer sharing,log-on security

no sods to local o/s's

system voluses are added to each drive

CSMA/CA transporter card about $500 per node

software about $150

disk drives !5MB - 126MB) about $1500 - $5000

print server about $900

TBS

Cofflients: 1. Share printers through a dedicated

print server.

2. Some file- security

3. Read onlv and read/write access

to public voluaes

4. User ID and password log-on

5. SNA gateway access to aainfraies

6. Each voluae of hard disk can

support different o/s foraat (e.g..

PC-DOS,Apple DOS,or CP/M)

7. Different coiouters an not however

share sinale voluie
Davono Svstess - Hultilink

ORIGINAL PAGE IS

OF POOR QUALITY

ITEM I I TEH DESCRIPTION

1 Naie/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Docusentation Availabilitv/Sourre:

6 NOS Hardware Iioleaentaticr:

—Netitork

—Host Cofflputer(s)

7 Host Ooerating Svstet Nase(s):

8 lipleaentatipn Language:

9 Maintenance Support:

10 ISO Model laoieaentation:

11 List of Services for Each ISO Laver:

12 Major 0/S Functions Ispleaented:

13 0/S Moditication(s):

14 Price:

15 User Added Apolications S/H:

Multilink

Davono Svstess

217 Huabolt rt.

Sunnyval°.CA 94089

(409) 734-4900

TBS

Token rinq

IBM PC's (also Colustna.AT&T,CoBoaq,and ITT)

Support for workstations froo:

...Nestar.Datapoint.& Standard Hicrosvsteas

PC-DOS.MS-DOS

TBS

On-site provided bv RCA

Carrv-in service by Sorbus

TBS

File sharing, printer spooling

TBS

TBS

Workstation at 1700

Starter kit at $2395

Cements: 1. Must have at least one PC

on the network as file server

and network controller

2. File lockinq via iodule SHRDOS

3. Supports uo to 255 stations

and 20.000; cable

4. Token-passing scheae based

on ARCnet philosophy

5. Ring speeds at 2.5!1bps
Dioitai Equiosent Corooration - DECnet

ITEM ITEM DESCRIPTION

1 Nate/Avail ability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Documentation Availabilitv/Source:

6 NOS Hardware lapleaentation:

—Network

—Host Cofflputer(s)

7 Host Operating Svstes Naae(s):

8 lapleaentation Language:

9 Maintenance Support:

10 ISO Model Ispleaentation:

11 List of Services for Each ISO Laver:

12 Major 0/S Functions lupleaented:

13 0/S Modification(s):

14 Price:

15 User Added Applications S/N:

DECnet

Digital Equipaent Corporation

8301 Professional Place

Landover. MD 20785

(301) 459-7900

Garv Brown - Sales Rep.

Handbook: "Digital Networks - An Architecture

with a Future"

Software Product Description

Contact DEC for coaprehensive literature list

Source code is available at no charge - users applv

for it and agree not to disseainate it to others

Ethernet.X.25,DDCHP

DEC VAX.PDP,HicroVAX,DECSysteilO.DECSystea20.

Professional 300.Rainbow

VHS,RSX.RT-ll.TOP-10.TOP-20.HicroVHS

TBS

Software update service:

Comprehensive H/H field engineering support

Proprietary Digital Network Architecture (DNft)

Model siailar to 7 laver ISO aodel

Laver

7

b

DNA Label

User/Net. flngit.

Net. Apolic.

Function

Reaote file access

File transfer

Reaote terainal and resource access

Network virtual terainal

X.25 access

SNA gatewav access

Reaote coasand file subaission

Prograa - to - Prograa coass.

Assures against lost.duplicated packets

Best effort basis packet deliverv

X.25.Ethernet.DDCMP

5 Session Control

4 End-to-End Corass.

3 Routing

2 Data Link

! Physical

Task-to-task coaaunications.reaote file and

record access.file transfer.terainal coaaunications.

network virtual terainal

Runs under local o/s (e.g.. VMS). DECnet in

a UNIX environaent available CY1985

Each node licensed based on CPU tyoe

(e.g., VAX 11/750, 11/780) cost is $1050

for DECnet license olus $630 for software

Done via VMS devleooaent facilities

Ccaaents: 1. DNA nodes inreased froa 255 to 1023

2. DECnet/SNA gateway available

3. Phase IV developaent in progress

with current support for VAX svsteas

4. X.25 catewav available
Digital Research Inc - SR NET

ORIGINAL PAGE IS

OF POOR QUALITY

HER ITEM DESCRIPTION

9

10

11

Nase/Availability of NOS:

Oevelopsr/Vendor:

Address:

Telephone Na!5i/Contact:

Docuientation Availability/Source:

NOS Hardware Isplesentation:

—-Network

—Host Coiputeris)

Host Operating Systea Naaeis!:

lapleaentation Language:

Maintenance Support;

ISO Model Implementation:

List of Services for Each ISO Layer:

Major 0/S Functions lapleaented:

13 0/S Modification!*!;

14

15

Price:

User Added Applications S/8:

OR NET

Digital Research Inc

110 South Jefferson Rd

shippany, No 07981

(201) 428-1900

TBS

TBS

8086/8088-based coaputers

CP/fl, PC-BOS and DR's Concurrent DOS

TBS

TBS

vendor claiis "product lends itself

to be built along OSI guidelines"

Reacts file access (with file and record locking)

Resote printer access

No aodificatioii to OR'; Concurrent DOS

Modification to other o/s is TBS

TE3

T3S

Coaaents: 1. Offered a; indepsndsnt module for latest release

of DR Concurrsnt DOS Q/S

2. OEM's responsible tor N10S I/O to

server and end-to-end provision af reliable

virtual circuit service

3, Password protection on servers and private

disk drives supported

4, NDOS act; as i redirecter to route local vs reiiote

o/s calls
Fox Research - 10-NET

ITEH i ITEfl DESCRIPTION

1 Name/Avallabilitv of NOS:

2 Develooer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Docuaentation Availabilitv/Source:

10-NET

Fox Research. Inc

7005 Corporate May

Dayton. OH 45459

(513) 433-2238

TBS

6

7

8

9

10

11

12

13

14

15

NOS Hardware Ifflolesentation:

— Network

—Host Coisputer(s)

Host Operating Systee Naae(s):

Iiiplesentation Language:

Maintenance Support:

ISO Model lepleaentation:

List of Services for Each ISO Laver:

Major 0/S Functions Iiolenented:

0/S Modification Is):

Price:

User Added Applications S/B:

Ethernet

PC.XT.AT

PC-DOS

TBS

TBS

TBS

File server

Electronic

Electronic

TBS

Extensions

TBS

TBS

News

Hail

to PC-DOS

Coiaents: 1. Unsucessful reaching vendor via phone calls
"Intel Corporation - QpenNet

ORIGINAL PAGE IS

OF POOR QUALITY

I TEH i ITEM

1 Nase/Avaiiability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(5)/Contact:

5 Docuuentation Availability/Source:

6 NQS Hardware lapleaentation:

—Network

—Host Coiputer(s)

7 Host Operating Systea Nasals):

8 isplesientation Language:

9 Kaintenance Support:

10 ISO Hodel laplsasntation:

11 List of Services for Each ISO Layer:

12 Major C/S Functions iaplsnented:

13 0/S fiodificationfs!:

14 Price:

15 User Added Applications S/H:

OpsnHat

Intel Corporation

3065 Boaers Ave.

Santa Clara, Cft 95051 '

(301) 796-7500

John Hollis.Chac k HcKinne y (HD ofc.)

Source Cede available

Ethernet (IEEE 802.3)

Intal 1310(3086,80286!

IBH PC

iRHX, Xenix,PC-B03,«S-9QS

SC"(Xenix version!

PLHiiRhX ver=ion)

Software Update Service

isiplensents ISO/OSI Hods!

L1.L2 - Ethernet

L3 - Null

L4 - ISO Class 4 Transport

L5 - Intal Session protocol!

Li - Null

i./ ~ intei network tii e access

access protocol

Electronic Hail (XENIX)

Reaote execution of batch jobs SiSENIXi

Reacts print service

Record locking

File sharing,fi1e access

Hierarchical tile structure

no sc'dificatious

TBS

via iRMX or XENIX deveiopssnt s/s

Cosffients: 1. LI - L4 of OS! sodei isplesented in VLSI

oil a single board:

- Intel 3XH 552 transport engine

- 186/51 Computer board

- iHA9i« transport layer -=,'«

- 323S6 LAN coprocessor

- 32501 Ethernet controller

2. L5 - L7 support transparent interoperability

betseen PC-DOS, HS-DOS. XENIX, i iRhX-3i

3. CQ3pati;l= sith !BM-PC netsorking

softvisre and Hicro;oft HS-NET prodiict

i. QpenNet to be i?p!;a=ntec in DEC VWVHS

snviroras^t by 4 QTR 1985
Lantech Bysteas, Inc. - uNETix

ITEM I ITEH DESCRIPTIO N

1 Nasie/Avai labilit y of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone Nols!/Contact:

5 Documentat ion Availability/Source:

i NOS Hardware Ispieaentation:

—Network

—-Host Coapaterts)

7 Host Operating Systeu Naae(s):

3 lupleaentation Language:

9 Maintenance Support:

SO ISO Hodel lapiaffientation:

11 List of Services for Each ISO Layer:

12 Major 0/S Functions Isplesented:

13 0/S Modificationfs):

14 Price:

15 User Added Application s S/M:

Coafflsnts:

uNETix

Lantech Systsas, Inc.

9635 Bendell Road

Dallas, H 75243

(214) 340-4932

Paul Sr£use!

TBS

Ethernet,Corvus,Qflninet

and Percoffl LANs supported

I8K PC and cospatibles

UNI X V7 irsd Systess III coispatibility

•Ca

TBS

Not iaiplenented

N/A

Virtual TeriEinai

Resets Fils and Device access

virtual Fiis Systss

i or i i Lu?IETix kerna i is proprietary

iiiiplsisentition

1300 to $600 per node

Softwar e developiasnt tools

available under uHETix

1. Dynamic load balancing to

bs offered

2. Systes administrator provides audit

trail of user accessed files

3. Compatible with UNIX fil e systes

4. Up to 10 user defined vandoHS
Locus Coaputir.g Corporation - LOCUS

ORIGINAL PAGE IS

OF POOR QUALITY

ITEM i I TEH 5ESCRIPTIQH

1 Haste/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Tsisphone Nois)/Contact:

'j Docuaentation Availability/Source1,

6 NQS Hardware lEpleaentatiGn:

—Netsork

—Host Computer!s)

7 Host Operating Systea NaaeisS:

LOCUS

Locus Coffiputing Corporation

3330 Ocean'Park Blvd

Santa Monica, CA 90405

Judi Uttal, Kktg. flngr.

(213! 452-2435 '

Source cede prices:

-OEM license $150,000

—Subsequent licenses saae organization $10,000

—Right to provide binary sublicenses $25,000

•The LOCUS Distributed Systea Architecture' Edition 3.1 June 1934

Prograaaers Guide

Enhanceaents to UNIX

Ethernet (can also coexist vi/XNS and ISO)

DEC VAX,Motorola MC68000

Locus distributed UNIX

...object code cospatibility sith:

- Berkeley UNIX (¥4.1 and 4,2)

- UNIX Systei V

...hig h degree of compatibilit y sith others

8 Ispiessntation Language: °C'

9 Maintenance Support: new releases of software

h/s to OEM's only - no saint, avail,

10 ISO Hodel laplsssntation: not iipieaented - uses proprietary protocol

11 List of Services for Each ISO Layer: Vituaily all services supported including:

File Service

Print Service..

Hessags Handling

Reacts Procedure Call...

•Job Transfer 4 Mania....

Terminal Handling

Directory Service

Data Representation.....

Interprocess Coaas

Transport Services

Recovery Services

Network Management......

Metsork Security

12 Hajor 0/S Functions laplemented: Load leveling

Reaots fil e access

13 Q/3 MGdification(i): A sis step procedure (LOCUS Architecture Hanuai op is-i/)

is uses to convert a UNIX sysiea to i LGCUJ systeia. This

is done by rsciacing ths UNIX ksrnii and associitsd systess softwart

(all the root fil e systsaS. LOCUS al=o requires sore disk space

than convsntionai UNIX.

14 Fries: 4500.000 to port LOCUS

S5 User Added Applications S/S: Eisiiy dons in UMIX environasnt

"•:-S2efit = : 1. LOCUS is sold prisarily to JER's

2. TCP/IP to be supported in f^sar future

3. No ISO/OS! support snvisigned -for

nsar futurs due to extensive
"""•';jA: V- ,

sputing Corporation - LOCOS

strorts to producs existing product

4. Custoaer asust have an appropriate UNIX

lirenjs to run LOCUS distributed UNIX
Microsoft Corooration - MS-DOS & networks

I TEH i ITEM DESCRIPTION

1 Naie/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Docuientation Availability/Source:

7

8

9

10

11

12

13

14

15

NOS Hardware laoleaentation:

—Network

—Host Cosputer(s)

Host Operating Svstesi Naoe(s):

lapleaentation Language:

Maintenance Support;

ISO Model laoleaentation:

List of Services for Each ISO Laver:

Major 0/S Functions Inpleaented:

0/S Modification(s):

Price:

User Added Applications S/«:

Networks

Microsoft Corooration

3075 112 Ave. HE

Bellvue. Wft 98004

(206) 828-8080 (sales)

(206) 826-8089 (tech support)

1-800-426-9400 (Bellvue)

'Guidelines for Networking Product Developaent"

"MS-DOS 3.1 Prograaaers Guide"

"Microsoft Networks Users Guide"

"Microsoft Networks Managers Guide"

"Server/Redirector File Sharainq Protocol"

"Transport Laver Interface Guide'

"IBM PC Coapatibilitv'

Various

IBM-PC's

MS-DOS 3.1

TBS

TBS

laplenents ISO L5.fi,7

L7 - File and print server

L6 - Redirector

L5 - MS-DOS 3.1

L4.L3 - Network device driver s/w

L3.L2.L1 - Network hardware

TBD

TBD

TBD

TBD

Coaoents: Requires following:

-192KB RAH for workstations and server

-MS-DOS 3.1

-Networks 1.0

-LAN card suoplied bv other vendors

-Single floppv drive (ainieua)

-Transport interface card

Hardware independent

Password protection for directory or subdirectory

Read onlv/write only/create (or coabination)

permission granted

Anv block of characters in afile §av be locked

File sharing. peripheral sharing (e.g., printer)

High level protocol between server and applications

8. Server coa§ands:SHARE. PRINT, DEBUG, STATUS. STOP, HELP
nulti Solutions. Inc - Si

I TEH « ITEM DESCRIPTION

! Haas/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No!s)/Contact:

5 Documentation Availability/Source:

6 NOS Hardsare Implementation:

—Network

—-Host Computer is!

7 Host Operating Systes Naue(s):

8 Implementation Language:

9 Maintenance Support:

10 ISO Modal Implementation:

11 List of Services for Each ISO Layer:

12 Major D/S Functions laiplssented:

f; r» 'c > • 11 Qu ; _ .' *

fd D»;.- = , * -i i i i uc i

15 User Added Applications S/N:

Multi Solutions Inc

123 Franklin Corner Rd

Suite 207

Lasrencaviils, NJ 08648

Patrici a ffcMahcn

(609) 896-4100

Source code not available

TBS

ISO,68000,others

SI

Pascal-lik e

TBS

Hot implemented

TJjC

i Cw

Electroni c Mai l

Fil e and Device sharing

Intertask cosisuni cat ions

proprietary o/s

TEC

i Vlj

via Si utilities (editor,compilers

Cassents: 1. Suited for real-tise applications via priority

scheduler and contiguous file support

2. Task waka-up on events
Nestar Systsas Inc. - Plan 3000

ORIGINAL PAGE IS

OF POOR QUALITY

ITEB i ITEH DESCRIPTION

1 Naze/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone Noisi/Contact:

5 Docuaentation Avail ability/source:

6 NOS Hardware lapisasntation:

—Netsork

—Host Coapuierls)

7 Host Operating Systea Naae(s):

8 lapieaentation Language:

9 Maintenance Support:

SO ISO Made! Implementation:

11 List af Services for Each ISO Layer;

12 Major 0/S Functions la?!

13 0/S Hcditicationis/:

14 Pries:

15 User Added Applications

Plan 3000,4000

Nsstar Syiteas Inc.

2585 t. Eayshore fid.

Palo Alto, CA 94303

(415) 493-2223

(2025 2S?-!672 - Craig Harr or J bullard

!703) ?68-i554 - J. Builard

Source code not available

Other docusantaticn T8D

Arbitrary tr»3,baseband,token passing

IB?! PC's, ApplesSpriaarily as print servers!

SQ3 2.1,3,0

Pascal

h/w - RCA contract

s/w - Nestar Baintenance contracts

Con^orss tj I3C/03I iodei ino add'i info!

Shared disks.print servers

-i5Ci.rjnic ^aii,CnS'.,Horu processor

spreadsheet.accounting pracraa

and sulti-us=r database

Password accsss security

Log-on 15 security

Fiie.record c-rntEction

Nans to DGS en PC's

workstation $600

Dedicated server $12,995

Possible

1. Dtdicatec tils servers c-f up to

56i1B sacn

2. Can nstwork up to 255 stations

3. Fibre optic cabling supported

t. A workstation can aount up to

26 drives ct cne tisis

3. Public. group, and private controlled

acciss to virtual disks

fr. Any PC can be designated a; a

print server

. SNA 'Hcssay availabl e
Network Research Corporation - FUSION

ITEM ITEM DESCRIPTION

1 Name/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone Nois)/Contact:

5 Docuaentation Availabilitv/Source:

6 NOS Hardware laplesentation:

—Network

—Host Cofflouter(s)

7 Host Operating Svstes Naie(s):

8 Isoleaentation Language:

9 Maintenance Support:

10 ISO Model laoleaentation:

11 List of Services for Each ISO Laver:

12 Major 0/S Functions laoleaented:

13 0/S Hodification(s):

14 Price:

15 User Added Aoolications S/W:

FUSION

Network Research Corporation

1964 Hestwood Blvd. Suite 200

Los Angeles. CA 90025

213-474-7717

525-4141/Lee Cowan

Source code available '- contact vendor

List of available documentation - TBS

Ethernet

IBH-PC, MC68000, VAX, PDP-11. Intel 8086,8088.

NS 16032. F-ll

UNIX

— Berkelev 4.1,4.2

— Version 7

— Svstea 3

— Svstei 5

— Venix

— Xenix

— Ultrix

MS-DOS 2.0

PC-DOS

VMS

Installation and maintenance orovided

Provides user with functionalitv of

ISO/OSI lavers 3-7. Supports Xerox XNS:

protocols.

Lavers 1.2: Ethernet H/H interface

Lavers 3.4: FUSION Socket Manager

Lavers 5,6.7: Reaote execution and

virtual terainal

File Transfer

Virtual Terainal

Reaote Execution

Network Utilitiesstraffic ionitoring;

file. sail, and print servers; oerforsance

analysis

none - FUSION Socket Manager

is integrated into the kernal

as a device driver

$750 - $8000 (CPU fc 0/S dependent)

Add to librarv routines - coapatible

svstei calls

TCP/IP

Coesents:

(1) File Transfer - A single file or coaplete directories

of files can be transferred between a wide variety of

different coiouters and operating systeis.

!2) Virtual Teriinal - Each coaputer can act as a tersiinal

to anv other coaputer on the FUSION network.

(3) Reiote Execution - Coasands aav be executed en a reaote

coaputer having a different operating svstea.different

orocessor.or different network hardware.
Network Research Corooration - FUSION

(4) The FUSION Socket Manager (ISO L3-4) requires aporoxisatelv

18KB of proqrai space and 10-20KB buffer space. PC's require

about 13KB prograi space.

(5) IHbps throughput rates on a virtual circuit, application-toapplication connections (i.e.. ISO 17 to L7).
Network Svstens Corporation - NETEX

ITEM t I TEH DESCRIPTION

1 Name/Avallabilitv of NOS:

2 Developer/Vendor:

3 Address:

4 Teleohone No(s)/Contact:

5 Docuaentation Availability/Source:

6 NOS Hardware lapleaentation:

—Network

—Host Coaputer(s)

7 Host Ooeratinq Systea Nasefs):

8 laoleaentation Language:

9 Maintenance Support:

10 ISO Model Ifflpleaentation:

11 List of Services for Each ISO Laver:

12 Major 0/S Functions laoleaented:

13 0/S Modificationfs):

14 Price:

15 User Added Aoplications S./W:

NETEX

Network Svstess Corporation

7600 Boone Avenue North

Minneapolis. «N 55428-1099

(612) 425-2202

Bob Sfflvth

•Network Executive (NETEX) Software

and NETEX Utilities"

— Add'l docuientation TBS —

Source code available only to existing custoaers

HYPERchannel

IBHJEC.Univac. & CDC

IBM MVS/SP3 & VM/SP

DEC PDP-11 RSX-11H/M+ Release 3.2

DEC VAX VMS Release 2.2

Univac QS1100

CDC NOS & NOS/BE

Pascal

Extensive field engineerin for h/w

Software tape uodate service ala IBM

Idplesents ISO 7 laver aodel

LI,2 - HYPERchannel

L3.4.5 - NETEX and host 0/S (interorocess conns)

L6.7 - User written s/w and utilities

e.g.. NSC Bulk File Transfer(BFX) and

and Data Representation Service

L7 - User written s/w

L6 - User s/w and NSC utilities

L5 - prograa-to-prografl connection

- read/write data

- disconnection

- statistics gathering

L4 - data delivery assurance

- buffering for FDX coBtunications

L3 - driver and host sublavers

-Driver Sublayer

NETEX implemented as a separate prograa under

the local o/s control and called bv applications

prograas.

About $1300 - $6000 (depending upon iapleaentation

and specific svstei)

NSC periits user's to write Applications and

Presentation layer oroorais usina NETEX

Cofflaents: 1. NETEX §av be used in a heterogeneous coaputer

environaent provided each cosputer is provided with

HYPERchannel interface and proper version of NETEX

2. Handles delav coapensation for Tl satellite

coisunications links

3. Does not suDport peripheral devices attached to

the HYPERchannel: it is for host-to-host coaas.

4. Not transoarent to the user. It aust be called bv an
Network Svsteas Corooration - HETEX

application or utilitv to use its services

5. Security relies on host o/s iioleientation features

6. BFX utilitv efficient for files over 1MB

7. Future develooaent efforts:

-NETEX for Aoollo coaputers

-NETEX on boards for Multibus and PC-bus aachines
Novell Inc. - NET8ARE

I TEH ITEM DESCRIPTION

1 Naise/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Docuaentation Availabilitv/Source:

6 NOS Hardware laoleaentation:

—Network

—Host CoBPuter(s)

7 Host Operating Svstea Nane(s):

8 lapleaentation Language;

9 Maintenance Support:

10 ISO Model Ifflolesentation:

11 List of Services for Each ISO Laver:

12 Ma.ior 0/S Functions laoleaiented:

13 0/S Kodification(s):

14 Price:

15 User Added Applications S/H:

NETWARE (available since 1983)

Novell.Inc.

1170 N. Industrial Park Drive

Ores. UT 84.057

1-800-453-1267

Robert Walton

Svsteas Guide

Prograaaers Guide

Technical Reference Manual

Star network w/ twisted pair

Compatible with: 3COM Etherlink.

Nestar PLAN 2000.Orchid's PCNet.

1BH PC Cluster. Davong HULTILINK.

and Proteon PRONET.

IBM PC's and plug coipatibles. Manv MS-DOS

coaputers.

PC-DOS.MS-DOS

Lattice "C"

Hardware through distributors/dealers

Software through update service

lipleaents ISO sodel

TBS

File server,Print spooler, and Electronic aail

Network interface shell over

PC-DOS for interpreting network cosaands'network coaaands

Server has sultiuser-aultitasking o/s

$1495 for NETWARE 10,E.P

(ie: Corvus.3COM.and Proteon look-alikes)

$795 for Electronic Hail

Hardware price is a function of the

network hardware selected

Suppoted via Proqranaers Reference Guide and

Technical Reference Manual

Consents: (1) Protocol is a proprietary,polled differential line

(2) Bandwidth at baseband is 600 kbps

(3) Proprietary server based on 68000 processor

(4) Securitv - liaited access to subdirectories and

voluaes: file and record locking: nase and password logon

(5! Up to 5 printers on server: print spooling

(6) Runs DOS 3.00 and 3.10 S/H

(7! Additional function nuabers have been added

to DOS and defined for Netware to allow

operations not supported in native 0/S

(a.o.. File Lock).
Orchid Technoloov - PCnet

ORIGINAL PAGE IS

OF POOR QUALITY

ITEM I I TEH DESCRIPTION

1 Name/Aval lability of NOS:

2 Develooer/Vendor:

3- Address:

4 Telephone No(s)/Contact:

5 Docusentation Availability/Source:

6 NOS Hardware lioleaentation:

—Network

—Host Coiputer(s)

7 Host (berating Svstea Naae(s):

8 laoleaentation Language:

9 Maintenance Support:

10 ISO Model Ifflpleaentatipn:

11 List of Services for Each ISO Laver:

12 ttajor 0/5 Functions laplesented:

13 0/S flodification(s):

14 Price:

15 User Added Applications S/H:

PCnet

Orchid Tecnologv

47790 Westinohouse Drive

Freesont. Cfl 94539

(415) 490-8586

TBS

CSHA/CD coax cable

IBM PC's. XT'5

PC-DOS, US-DOS

TBS

TBS

TBS

File and device sharing

(e.g.. aodeas,disks,printers)

File locking

Liaited RPC

Messaging

TBS

Workstation $495

Starter kit $1090

TBS

Coenents: 1. Up to 256 PC's supoorted

2. IHbos network data rates via CSHA/CD

3. Each user workstation can access uo

to 14 servers

4. Anv PC in the svstes can

function as server or workstation
Plexus Coaouters - NOS

ITEM ITEfl DESCRIPTION

1 Nase/Availabilitv of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No!s)/Contact:

5 Docueentation Availabilitv/Source:

6 NOS Hardware lapleaentation:

—Network

—Host Coaputer(s)

7 Host Operating Svstes Naie(s):

6 lipleeentation Language:

9 Maintenance Support:

10 ISO Hodel Isplefientation:

11 List of Services for Each ISO Layer:

12 Major 0/S Functions laplesented:

13 0/S Hodification(s):

14 Price:

15 User Added Applications S/B:

NOS

Plexus Coflouters

3833 N. First St.

San Jose. CA 95134

(408) 943-9433 California

(201) 843-7766 New Jersev

TBS - telecon 4/29

TBS - telecon 4/29

TBS - telecon 4/29

TBS - telecon 4/29

TBS - telecon 4/29

TBS - telecon 4/29

TBS - telecon 4/29

TBS - telecon 4/29

TBS - telecon 4/29

TBS - telecon 4/29

TBS - telecon 4/29

TBS - telecon 4/29

TBS - telecon 4/29

Contents: TBS - telecon 4/29
Portable Software Inc. - The Newcastle Connection

ORIGINAL PAGE IS

OF POOR QUALITY

[TEH ITEH DESCRIPTION

1 Nase/Availability of NO.S:

2 Developer/Vendor:

3 Address:

4 Telephone No(s5/Contact:

5 Docuaentation Availability/Source:

6 NOS Hardware lapleaentation:

—Network

—Host Coaputer(s)

7 Host Operating Systea Naae(s):

3 lapleaentation Language :

9 Maintenance Support:

SO ISO Model Implementation:

11 List of Services for Each ISO Layer

12 llajor G/S Functions Isplesented:

13 0/3 nodificatiofiis):

14 Price:

15 User Added Applications 3/W:

The Newcastle Connection

Portable Software Inc

650 fair Island Road

Suite 204

Redsood City, CA 94063

Keit h Clark

(415) 367-6264

Source Cade Available

Manuals: Installation Procedures

Interfacing to the Network

The RPC Protocol

Ethernet,OaninetjCasbrige Token Ring Net"

ATiT 3B)6SOOO-based(Coryus,Sun).PDP-11

VAX,Pyraaid,6auld SEL

and castes bit slice processor

UNIX Systaa V, System III, V7

4.2BSD and XENIX

=C"

Software Update Service

Applications Layer

Electronic sail

File Service

Rsaote Procedure Call

Interprocess Coasunicition

None

OEM binary licence per nods: J750

Source Code license: $3000

Yes - via host 0/5 softsars development packages

losaents: 1, TNC uses 'redirector' to send

calls out to the network instead of

local o/s shen required
Quadraa Corooration - Quadnet VI

I TEH I ITEM DESCRIPTION

1 Naie/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Documentation Availability/Source:

6 NOS Hardware Isplesentation:

—Network

—Host CoBDuter(s)

7 Host Operating Systei Naaets):

8 lapleaentation Language:

9 Maintenance Support:

10 ISO Model Ispleaentation:

11 List of Services for Each ISO Layer:

12' Major 0/S Functions Ispleaented:

13 0/S Modification(s):

14 Price:

15 User Added Applications S/H:

Quadnet VI

Quadras Corooration

4357 Park Drive

Norcross. 6A 30093

!404) 923-6666

TBS

CSHA (with both CD and CA)

IBM PC's, XT's. or coapatibles

PC-DOS, MS-DOS

TBS

Liaited diagnostics.return shipping

for repairs. Telephone tech assistance

TBS

Electronic nail,word processing

Shared devices (printers,disks,plotters)

Print spooling

Log-on ID security

File,record protection

TBS

Workstation $595

Server station $1295

TBS

Cofflsents: 1. Network uses both CA and CD aspects

of CSMA orotocol. Using both increases

reliability but decreases s/w overhead.

2. Up to 255 workstations; 1 server

3. Server is a dedicated XT

4. Workstation devices cannot be shared

but can only be used locally.

5. Uses Novell Netware software

6. Applications designed to operate

on CP/M 86. Concurrent DOS, UNIX,

and Xenix are not usable.

Hard disk server is public

(SYS:PUBLIC) - user voluaes are

DOS subdirectories.

7
Quadras Corooration - Quadnet IX

ITEM I I TEH DESCRIPTION

1 Nase/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Docuaentation Availabilitv/Source:

6 NOS Hardware lapleaentation:

—Network

—Host Cosputer(s)

7 Host Operating Systea Naae(s):

8 lapleaentation Language:

9 Maintenance Support:

10 ISO Model Ifflpleaentation:

11 List of Services for Each ISO Layer:

12 flajor 0/S Functions Isplesented:

13 0/S Hodification(s):

14 Price:

15 User Added Apolications S/H:

Quadnet IX

Quadrat Corooration

4357 Park Drive

Norcross. 6A 30093

(404) 923-6666

TBS

Token star-rinq,10Mbps n/proprietarv h/w

twisted pair or fibre ootics

IBM PC's. XT's. or coaoatibles

PC-DOS, MS-DOS

TBS

Lisited diagnostics,return shipping

for repairs. Telephone tech assistance -

TBS

Electronic aail(EMS).word processing

Shared devices (printers,disks,plotters)

Print spooling

Log-on ID security

File,record protection

TBS

Workstation $795

Server station $1495

4-station connector $195

4-station confiq. $9265

TBS

Coaaents: 1. Uses Novell Netware software

2. Apparently uses proprietary

h/w frofl Proteon

3. 4.8, or 16 workstations per ring

4. Up to 255 nodes

5. Interfaces available for:

-DEC Unibus (POP & VAX)

-DEC Q-bus

-Intel Multibus

6. Use of Novell s/» aeans lack of

compatibility with standard

DOS device drivers

7. Proprietarv Novell file server

6. 1 XT fil e server
Quantum Software Systeas Ltd. - GNX

ORIGINAL PAGE IS

OF POOR QUALITY

HEN t I TEH DESCRIPTION

1 Nanse/Availabilit y of NOS:

2 Osvelopsr/Vendor:

3 Address:

4 Telephone NG!S)/Contact:

5 Docusentation Availability/Source:

b NQS Hardware lapleaentation:

—Network

—Host Computer is!

7 Host Operating Systeii Naas(s):

8 lapleaentaticn Language:

9 Maintenance Support:

10 ISG Model Implementation:

SI List of Services tor Each ISO Layer:

12 Major 0/3 Functions lapieiEented:

13 Q.'S Modification'^):

14 Price:

i-j L-ser ndoeG hp-plications ^/ni

QNX 2.0 -

Quantua Software Systees Ltd.

Hoodie Drive High Tech Park

215 Stafford Road, Unit 104

Ottawa, Ontario K2H 9C1

Canada

11171 711-10Q7

\ '-.'1--'J /iC- iU7-J

Sandy Kingston

Source code not avil.

Other doc. TBS

ftrcnet

IBH PC,AT and compatibles

aiso other 3083.8086,80186, fc 80236 cpu's

fliiT V HIM TV H« r i v hm. n \bi» i A L'C! i v

h/s - board exchange policy

5/s - telephone technical support

- on-line bulletin board service w/dosn-line

load of nes s/8 revs.

TBS (Unknown;

Nstsork Security V

Development of QNSS! (UNIX like) o/s

QNIK - sultiuser,iaultitasking,real-tise LAN

1-4 nodes is $1300 (per node)

5 or oiore nodes $2600

Possible in QN!S! environsient

Hsssage Handling..... .

Seacte Procedure Call. ,

J ob Transfe r & Manip. .

Tsrisinal Handlin g

Directory Service

Data Representation...,

Interprocess COMS

Transport Services

Recovery Services

1, L23 public network access

z. iiipports GisirioutS'j processinQ

as sell as distributed devices

3. Pure processing eiesents (i.e., computers

without ksyboards or displsys can be

plugged into the nstviork

4. SuoDort DCS emulator to enable PC DOS tasks under QNiJ
Standard Hicrosvstefls Corooration - Arcnet LAN

ITEft I I TEH DESCRIPTIOH

1 Naae/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

Arcnet LAN

Standard Microsvsteas Corooration

35 Harcus Blvd.

Hauppauqe. NY 11738

(516) 273-3100

Jia Hall

5

6

7

8

9

10

11

12

13

14

15

Documentation Availability/Source:

NOS Hardware lapleaentation:

—Network

—Host Coaputer(s)

Host Operating Svstea Naae(s):

lipleaentation Language:

Maintenance Support:

ISO Model lapleaentation:

List of Services for Each ISO Layer:

Major 0/S Functions lapleaented:

0/S Hodification(s):

Price:

User Added Applications S/H:

TBS

Token-ring

IBM-PC and S-100 bus svsteas

TBS

TBS

TBS

TBS

TBS

TBS

TBS

TBS

TBS

Cosaents: 1, Telecon w/ J Hall 4/24 - will send lit

didn't know what ISO Has
Sun Microsvsteas' - NFS

ITEH I ITEH DESCRIPTION

1 Naae/Availabilitv of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Docuaentation Availability/Source:

6 NOS Hardware lapleaentation:

—Network

—Host Coaputer(s)

7 Host Operating Systea Naae(s):

B lapleaentation Language:

9 Maintenance Support:

10 ISO Model Implementation:

11 List of Services for Each ISO Layer:

12 Major 0/S Functions lapleaented:

13 0/S Modification(s):

14 Price:

15 User Added Apolications S/W:

NFS 2.0 (April 1985!

Sun-Microsvsteas Inc.

8233 Old Courthouse Road. Suite 200

Vienna, VA 22180

(703) 883-0444

"Overview of the Sun Network File Systea"

"Reaote Procedure Call Protocol Specification"

"Reaote Procedure Call Reference Manual"

"External Data Representation Reference Manual'

Source Code Available - $25,000

Ethernet

Sun Workstations,DEC/VAX,IBM-PC

UNIX (also non-UNIX environaents)

VAX/VMS, VAX/UNIX

TBD

TBS

Does not confors to ISO

File sharing

Reaote Procedure Call

File sharing in an heterogeneous

coiputer environaent.

Reaote Procedure Call (with authentication)

Extension of UNIX 0/S

$1200 per Sun Workstation

TBS

Cossents: (1) The intent of NFS is to aake it transaission technology

and ooerating svsteia independent.

(2) NFS orovides an environaent that can accoaodate

hardware froa other vendors.

(3) Sun's ijiplesentation resides in the UNIX kernal

(UNIX 4.2) and are proprietary.

(4) Yellow Pages will be another network service. It is

a phone book of available network resources for clients.

(5) Reaote copying rates are expected to be greater

than 100 KBytes/sec.

(6) NFS increases UNIX kernal size 20-25L They

suggest 2MB aain leaory to ainiaize adverse

effects on perforaance.

(7) File locking capability is expected future

enhanceaent.
TeleVideo Svsteas. Inc. - F'fl/16

ORIGINAL PAGE IS

OF POOR QUALITY

ITEM I TEH DESCRIPTION

1 Hase/Availabilitv of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Docuaentation Availability/Source:

6 NOS HardHare laplesentation:

—Network

—Host Coaputer(s)

7 Host Operating Svstes Naae(s):

9 Maintenance Support:

10 ISO Model lapleeentation:

11 List of Services for Each ISO Laver:

12 (lajor 0/S Functions lapleaented:

13 0/S Hodification(s):

14 Price:

15 User Added Applications S/H:

Pfl/16 (since June 1984)

TeleVideo Svsteas. Inc.

1170 Morse Ave.

Sunnyvale. CA 94086

1408) 745-7760

(408) 471-0255

400 page prograaaers ianual to be released

IBfl PC's and coapatibles

HS-DOS. PC-DOS VI,1. V2.x

Note: V3.0 and 3.1 avail, soon

6-fflonth warranty

TRW i Xerox offer on-site/denot service

TBS

Shared printers.disks.pi otters,sodeas

User-User aessaging

Network Management (see coaaents)

Securitv:

-file level r/H.open.create,delete access peraission

-directory search peraission

-logon passwords '

TBS'

About $2500 oer node

TBS

Cofliaents: 1. Infoshare is TeleVideo custoa version

of Novell Netware

2. Uses dedicated fil e server

connected in star topology

Nith workstations

3. Up to 16 workstations eav

be connected to server

4. Fibre optic nodes available

5. 3270 SNA gateway available

6. Network aanaqer can:

-broadcast sessages to all users logged on

-log stations off

-prevent add'l. log-ons

-control print spooling (e.g., reroute print tasks!

-perfors overall network usage aonitoring

7. Electronic aail not currentlv avail.
3Co§ Corporation - Etherseries

ITEM f I TEH DESCRIPTION

1 Naie/Avallability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Docunentation Availability/Source:

6 NOS Hardware lipleientation:

—NetHork

—Host Coaputerls)

7 Host Operating Systes Naaeis):

8 Ifloleraentation Language:

9 Maintenance Support:

10 ISO Model Ispleoentation:

11 List oi Services for Each ISO Layer:

12 Major 0/S Functions Ifflpleaented:

13 0/S Modification(s):

14 Price:

15 User Added Applications S/W:

EtherSeries

3Coffl Corporation

1365 Shore Bird Hav

Hountainview. CA 94043

(415) 961-9602

Jeff Perez

Source Code negotiated individually

User Software Guide

Network Administrators Guide

Internals software quide

Ethernet (IEEE 802 CSHA/CD)

IBM PC,XT.AT

PC-DOS

Software Updates provided

5 dav turnaround on boards

XEROX Asericare for servicing

L1.L2: Ethernet

L3 - L5: XNS protocol

L6.L7:Proprietary

Electronic sail

Disk.printer sharing

TBS

The onlv departure froa standard

PC-DOS usre interface are coasands

and utilities to support

multiple users in a networked

environient.

$650 and UP

Possible - use internals software ouide

Coieients:
Touchstone Software Corooration - The Connectables Network

ITEH I ITEH

1 Naee/Availability of NOS:

2 Develoner/Vendor:

3 Address:

4 Teleohone No(s)/Contact:

5 Docuaentation Availabilitv/Source:

6 NOS Hardware lapleaentation:

—Network

—Host Coaputer(s)

7 Host Operating Systea Nase(s):

8 Ispleaentation Language:

9 Maintenance Support:

10 ISO Hodel Iffipleeentation:

11 List of Services for Each ISO Layer:

DESCRIPTION

12 Major 0/S Functions lapleaented:

13 0/S Modification(s):

14 Price:

15 User Added Apolications S/M:

Coaaents:

The Connectables Network

—PCworks for PC's

—UniHost for UNIX.Xenix svsteas

—MacLine for Macintosh

Touchstone Software Corooration

909 Electric Avenue

Seal Beach.CA 90740

(213) 598-774i

Stephen Onstott

Corporate Account Reoresentative

Source code not available

Manuals for PCworks.UniHost,HacLine

Dial-uo, proprietary protocol

PC's.UNIX systeas. % Macintosh

UNIX.PC-DOS

•C"

No custoa hardware required

Software uodate sevice charge (""$30)

Not isplesented

File transfer

Electronic Hail

Kenote terainal

Liaited shared devices

Status reporting

Reaote printing

File Service... V

Print Service Y

Message Handling........Y

Remote Procedure Call...N

Job Transfer i Manip....N

Terminal Handling Y

Directorv Service ..N

Data Representation Y

Interprocess Coans N

Transport Services Y

Recovery Services Y

Network Manageaent Y

Network Securitv Y

none to PC-DOS

UNIX sods unknown

UniHost license - *295

PCworks license - $195

MacLine license - $195

Hooks are there for add-ons but

onlv for internal use for now

1. Reaote terainal suoport for standard

ANSI.TTY. or VT100/52

2. UniHost reouires:

-UNIX o/s

-30-60 KB disk/aefiorv soace

-serial log-in oort
Touchstone Software Corporation - The Connectables Network

-RS232C interface cable

3. PCwcrks requires;

-128KB IBH/Cosptible PC

-DOS 2.0 Operating Svstei

-280 KB disk storage

-Asynchronous adapter

-RS232C interface cable

4. HacLine requires:

-128KB Macintosh

-RS232C serial interface cable

5. Proprietary cossunications

protocol
Unoeraann-Bass - NET/ONE

ITEM ITEM DESCRIPTION

1 Naae/Availability of NOS:

2 Oevelooer/Vendor:

3 Address:

4 Teleohone No(s)/Contact:

5 Docuaentation Availability/Source:

6 NOS Hardware laoleaentation:

—Network

—Host Cofflouterls)

7 Host Operating Svstea Nase(s):

8 Isplefflentation Language:

9 Maintenance Suoport:

10 ISO Model Inoleflentation:

11 List of Services for Each ISO Laver:

12 Major 0/S Functions laolefented:

13 0/S Modification(s):

14 Price:

15 User Added Applications S/W:

NET/ONE Personal Connection (avail Fall 1984)

Ungeraann-Bass Inc.

2560 Mission College Blvd.

Santa Clara.. CA 950509

(408) 496-0111

Pat Bolqer

Source code avail. - negotiated orice

•NET/ONE 0/S MANUAL"

'NET/ONE MANAGEMENT CONTROL"

Ethernet.twin-coax baseband (R6-58)

Broadband.& Fibre Ootic Star

IBM PC and plug coioatibles

Machines with RS-232C.IEEE 48B.or

DEC DR-11-W/B ports.or 32 bit parallel I/F's

PC-DOS 2.0 or higher

Microsoft Network (future)

TBS

About 1/10'th s/w cost for annual updates

Field engineers for on-site saint.

Monthly saint, contracts avail.

LI - L3 onlv

L4 -L7 proprietary

High level applicationsi'Crosstalk'.Bord Processing.

soae InterDrocess COBSS.

Diskshare (not a fil e server)

Printshare (Spooled printing)

Mailshare (Electronic aail)

K.25 Gateway (requires special H/H)

0/5 sods made - details unavail.

$1095 for NIU board

$1000 for Diskshare or Printshare

$ TBD for Hailshare

Is possible (e.g.. Lotus 123.WordStar)

Coaaents: (1) Provides" file locking

(2) Logon with naae and password

(3) Bus and aodified star with fibre ootics available

(4) CSMA/CD or CSMA protocol

(5) PC XT or coapatible server

(6) Anv node can be used as a server and run

applications at the saae tviae

(7) Voluues siav be private or shared: password voluae

protection available

(B) Anv node can be used as a orint server
vUNstix , Inc - viaNe t

ORIGINAL PAGE IS

OF POOR QUALITY

ITEM i ITEM

1 Hase/Availability of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone Noisi/Ccntact:

5 Docusentation fivailability/Source:

6 NOS Hardware Implementation:

—Network

—-Host Coaputeris!

7 Host Operating Systes Naae(s):

8 Isplesentation Language;

9 Maintenance Support:

10 ISO Model Implementation:

11 List of Services for Each ISO Layer

12 Hajor 0/S Functions Ispleaented:

53 Q/S HodificaUonis):

54 Price;

15 User Added Applications S/S:

ViaNet

ViaNetix.Inc

5766 Central ftve

Boulder, CO 80301

(303) 440-0700

Hoaard Kelly, V? Business Operations

John Ingals, West Coast Regional Sales figr.

Source code available - negotiable

ViaNet Seneral Inforsation flanaai

ViaNet Interaediate Users Reference "anual

ViaNet Netsork Administrators Suide

ArcnetjOsninst,Ethernet,IBM networks

IBPS PC

US-DOS,UNI* III , SystsiB V (Mural

yes

Presentation - XLAT which intercepts all system

Session - Local Router (i.e.. a redirected

Transport - format Converter Out (converts

system call to network ssssage;

fletwork - Nstsark Router nandles network

I/O driver

File I/G

Interprocess Coissunications v:a naaed pipes

Directory service of use-s logged on

siinGr uSOu i : i CCL i ons to u/^

approx. fiOO per node

TBS

calls

1. File protection (read only, R/S fil e iccessi

2. Data,progra35 and devices are sharable

3. File and record locking

4. ViaNet is HS-DOS applications prcqras in .EXE file foraat

5. All systes calls pass through network software

t. Uses interrupt 21H for ViaNet csiSisunications

7. Uses redirector'concspt

8. UNO and DOS can coexist with file •

iranster service

v, Ofiyiodil y done by XENIX and purchased in prototype
Hana Laboratories - HanoNet

I TEH I TEH DESCRIPTION

1 Naie/Availabilitv of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone No(s)/Contact:

5 Docusentation Aval I ability/Source:

6 NOS Hardware lapleaentation:

—Network

—Host Coiputerls)

7 Host Operating Systea Naee(s):

8 laplesentation Language;

9 Maintenance Support:

10 ISO Hodel lapleaentation:

11 List of Services for Each ISO Layer:

12 Major 0/S Functions lapleaented:

13 0/S Modification!*):

14 Price:

15 User Added Applications S/W:

HanqNet

Hang Laboratories

Lowell. Mass.

1-800-225-0234

Hallv <last naae ?>

TBS

Dual cable broadband.FDH and TDH

Hang VS coaouter

TBS

TBS

TBS

Uses coapressed fora to just 3 layers

ISO Laver(s) Hanq Naee

1 - 4 Transport

5 -6 Services

7 Applications

Transport: X.25.SNA/BSC,PTP.HanqBand

Services: File Transfer Hanaqer

Reaote Operating Svstea Access

Hanq VS Coaputer Terainal Esulation

Virtual Terainal Interface

Applications: Hanq Office Software

Applications Services Architecture

Hanq Inforiation Transfer Architecture, and

Hord Processing Svstes - Coaaunications Specific

Exchange files

Duab Tersinal Eaulation

Prograa-to-Prograa conns between

Hanq VS hosts

Resource Sharing

TBS

TBS

TBS

Consents:
JfcosD - X-NET

ITEH « ITEfl DESCRIPTION

1 Nane/Availabilitv of NOS:

2 Developer/Vendor:

3 Address:

4 Telephone Nofs)/Contact:

5 Docuaentation Availability/Source:

6 NOS Hardware laolesentation:

—Network

—Host Coaouter(s)

7 Host Operating Systei Naae(s):

8 lapleaentation Language:

? Maintenance Support:

10 ISO Model Ispleientation:

11 List of Services for Each ISO Laver:

12 Major 0/S Functions laoleaented:

13 0/S Modification(s):

14 Price:

15 User Added Aoolications 5/H:

X-Net

XCOfflP

4223 Ponderosa Ave.

San Diego, CA 92123

(619) 573-0077

TBS

bus architecture

IBM PC's

HS-DOS 2.0

TBS

TBS

TBS

Device sharing (disk.printer.any RS-232 device)

RPC

Cooies files

TBS

Workstation $395

Starter kit $995

Four station config. $6180

TBS

Coffiaents: 1. Coffles «ith no applications software

2. Does not support:

-electronic sail

-chat between users

-create print oueue

3. No network status reporting
APPENDIX B

Bibliography of

Relevant Literature
ORIGINAL PAGE FS

OF POOR QUALFTY

NASA/GSFC : Netsork Operating Systeas Bibliography of Relevant Literature

Document i

14

la

Author is)

Ferrari-,D.

Title

The Evolution of Berkely UNIX

Gu5Bla,R. i Zatti.S. TEHPO - ft Network Tise Controller for

3 Distributed UNIX Systea

Jensen, E.D. & Fleszkcch,N. ArchGS: ft Physically Dispersed

Operating Systea

Goscinski, ft. 4 Indulska, J. An 'Object Approach To Network

Operating Systea ilodei Construction

KcKendry,N.S. Clauds: A Fault Tolerant Distributed

Operating Systea

Shoth, J.F, i Hupp,J,A, Nates en the "Serin" proqrass — soise early

experience with distributed computation

Hatscn, R.8. '; Fletcher,J.3. Ar. Architecture tor Support of Network

Operating Systsa Services

NBSsett,D.H. ' A Systematic Hethodoiogy for Analyzing

Security Threats to Interprocess Ccssunication

in a Distributed Systes

Zhongxiu, S,,Du Z, k Feigen Y. ZCZOS: A Distributed Operating Systea

for a LSI-li Hicrocomputer Network

Sha L, Jensen. E,D., Rashid,R,F,, Distributed Co-operating Processes and

and Northcutt J,D. Trinsactions

Battarel.S.J. & 3avary,H.Fi Interprocess Coissunication Systes of tha

HT35 Digital Exchange

Tokuda,H. ^ fanning,£. ftn Interprocess Cosisunication Hodel for a

Distributed Software Testbsd

Liu.H.T. i Tsay.Duen-Ping -HIKE: A Network Operating Systsa for the

Distributed Double-Loop Computer Network

Copeiand,J.. Schnatsaier

 1L , and Locus: A Transparently Clear Solution

Winsto^ A.

Winston.A.

 The LOCUS PC Bridge

Brsreton. P. Detection and Resolution of Inconsistencies

aiiiong Distributed Replicates of Files

Hairak. S.A. Leinbaugh.D. and A Progress Rspcrt on the Despsranto Research

Berk, T.S. Project - Software Support for Distributed

Processing

Peinl, P. and Reutar, A. Synchronizing Multiple Database Processes in

a Tight!,1/ Coupled Kuitiprocsssor Environment

Chesley, H.R. and Hunt, V.S. Squire - A Coffisunicaticns-Oriented Operating

Systes

Foster, 9.V., Dowdy, L.MM and Fils AssigniBirrit in a Computer NetHO-'k

Aass, J.E.

Joilins, K.R. Copying Structured Objects in a Distributed

A Psrsorctivs on Distributed Coaouter Systess

23 Spsctor, A.I. and Schnsri, P.H. Transactior.s: ft Construct for Reliable Di =

tributid Coaputing

24 - variouB - ~ various -

USENET: Spanning che Gic-ba
ORIGINAL PAGE !S

Of POOR

NASA/8SFC : Network Operating Systsss Bibliography o? Relevant Literature

Docusent i Source Publication Cats

1

-(1.

3

4

C

J

6

7

8

9

!0

} •;

i n ii

13

!4

1 D

i £

i G

IEEE: Distributed Processing Technical

Cossittee Newsletter

IEEE: Distributed Processing Technical

Coasittee Newsletter

IE££;Bistributsd Processing Technical

Coaaittee Newsletter

SEEEsBistributed Processing Technical

Coaaittee Newsletter

lEEE:Diatributed Processing Technical

Ccsaittee Newsletter

XEROX Palo Alto Research Center

Coaouter Networks 4

IEEE Transactions on Coaaynications

ACM Operating Systems Raviea

ACR Coaoutsr Coasar.i cations Revisvi

Vcl 1 , No 2 - SI6COK 'S3 Syspasius

ACR C sputer Cosaunications Review

u^; i w.i • _ OTprnn 'OT Ci.«nn^-: .,., Vul i . Flu *. -jlCuun uv jl/iupuziu3l

ACH C sputer Cosaunications Revisw

Voi i , No 2 - SI8CQH 'S3 SyiBpas;ua

IEEE ransacticns on Softwar* Engin=;ring

UN!X/Sorld

UNIX/jiorld

SrW H-ar^*'"1

^ ?*,l-lnfn- C'-t,- -tl.i

..ut, upeio

 ;.i ;:u jy:tcfi:r i-!C-**zn

June 1934

June 1934

Juns 1984

June 1984

June 1984

September 1990

April!?; 1980

September 1983

' July i9S3

?1arch 1993

March 1993

ilarch 1?S3

Harcn 1983

Vai 1, No 6 1924

Vai 1, ND 4 1984

January !983

17 ACR Operating Syst-eas Review

Key Words/Phrases

UNIX,distributed environment

UNIX,synchronization

Decentralized

NOS,distributed resources

Fault-tolerance,distributed 0/5

Distributed computing,Ethernet

HCS.network architecture,distributed

coaputing

Network security,distributed systea,

interprocess cosaunication

Distributed systes,5ynchroni:ation,NOS

Interprocess cosEunication,fault

tolerance,ISO layers

<ji str i buted software, interprocess

coaaunkation

NQS,di5tributed systems,cosputer networks,

resource sharing,synchronization

UNIX.Ethernet,synchronization.reliability

UNiX.LAN.!BH-?C,Ethernet

NOS,file access,file replication

January 1983 Distributed computing,resource sharing.

13 ACM Operating Systeas Review

19 Coaputer Networks

20 Computer Networks

21 Coaputer Nstsarks

22 IEEE Transactions en Ccaputers

23 ACS - QpErating Systsss Review

24 ACh - Opjrating Sysisu Review

SpecisL issue - Freezings jf the

PrinciplEs 10-13 October 1983

25 UNiX/«o'ld

January 1983 Database systsss.synchrcniiation

September 1981 Real-tise operatino systeis. jultitasking,

si coprocessors, distributed processors

Septaaber 19S1 NQS,distributed databassi.coaputer nstsorks

Septeibsr 1981 Distributed syst;s

Deceeber 1934 Coasiunicatiofii subnet,coiputer nstworks.

distributed computer systss.distributed

dstabases,distributee operating systees.

distributed processing

April 1983 Distributed cosputing,syr,chroni:ation.

Vcl 17. No. 5 Distributed coscutino.network ccisunicsiicn

Voi 1, No 7, 1934 UNHjfietsGrk cotSJun

network

, broadcast
W3A/GSFC ; Netsork Operating Systeas Bibliography of Relevant Literature

Document i Author is)

2i

27

28

29

30 '

31

32

7?

•_• J

34

35

Jensen, E.D,

McGann,- L.B.

Unite, J.E.

Nelson, D.L.

Jarvis.P,

Ulrich; M.E,

Ennis, S.

Wesei. G.W.

Davidson, J,H.

r.aUCiiSiI HClPi • 'A. 3.

Physic:

Couriei

S=3ot=

Distri!

Netsori

Virtua

Passini

Disk Ei

Sharif

Cosputi

or Disi

Routini

Broadbi

Transpi

NetHori

User-Pi

r T 0 i.

 :-'C \

Netsav

Physically -Dispersing an Operating Systeis

Courier Protocol Accesses Services «ith

Ksaots Procedure Caiis

Distributed, Replicated Scftsare Locates

Network Resources

Virtua: fteiscry/Addressing Pianages TokenPassing Ring's Resources

Disk Emulation Allows Ethernet Resource

Sharing

Computer-Based Message Systeas: Centralized

or Distributed ?

Routing Tables Locate Resources in Bridged

Broadband Networks

Transport Layer Utility Progras Supports

Network Hanagsssent

Ussr-Progrsffiisable Local Network Handles Seven

Protocol Layers

Netsay Connects Diverse Equipsent and Protocol;

46

47

Walker E, Popek G, ingiish R,

Kline C. ;nd Thiel S

Tansnbausi A,Hal lender S

Frit: I E. Hefner J E, and

Raieioh T M

n c *c d n n t i_ 2 r i a n

Hac,finna

Bsihl,ail!ia« E.

Hllchin, J. E. and HcKendry, M.

Svcbodova, Liba ,ed.

Mohan,C. ?i Lindsay,B.

Stankovic, J. et al

Bernstein, P, and Soodsan. N.

Cheriton.D and Zyaenpoei, )i

Powell, H and niiier. 3

Hctann, L

Whiti, J.

Upper-Level Network Protocols

Advanced Netware

The LOCUS Distributad Operating System

An Overview of the Asoeba Distribute d

Operatin g Systea

sling's Broad Approach

A Network of Coaputers Runnin g the UNI X Systes

Application-Leve l Batesays

Distributed Fil e Systess - ft Survey

Data-Dependent Concurrency Control and Recovery

S.Synchronization and Recovery of Action s

Workshop Susiisary-Opsratinq Systess in

Efficien t Casiiait Protocols for the Tree of

Processes Model of Distributed Transaction s

Review of Research and Critica l Issues

in Distribute d Bystss Soft^s

Concurrency in Distribute d Dat a Bases

Tha Distribute d ¥ Ksrnal and its

Performanc e for Diskless viorksataticns

isoleiientaion and Performanc e of Pipes

in v Systsa

«E6LOS: An Operatin g Systes for a

H'altiprocessor Environmen t

Process Hicratic n in DE«QS/HP

Courie r ProtocDi Access Services viith

KeniOie r'roceoure Lai i

'j~.s"r'.outec, Kepiicate d t-OT-.Hare Locates
ORIGINAL PAGE iS

OF POOR QUALITY

NAEA/GSFC ; Network Operating Systess Bibliography of Relevant Literature

Docusent i Source Publication Date Key Words/Phrases

26 ACR Coiputer Cossunications Review

27 Systeas i Set tsars'

23 Systeas Si Soft-ware

29 Systess & Software

30 Systeas & Software

31 Systess & Software

32 Systeus

 ;5s Software

33 Systess & Software

34 Systems i Sot tsars

35 Systass i Softnara

34

77

40

42

44

45

46

47

Systems & Software

Jiicro Cossunications

AM Operating Systeas Review - v'c-1 17.;I5

ACH Opera-ting Systess Keviaw - vol 15,13

Micro Cossunicstiar.s

AT&T Beii Laboratories Technical JournalVol 63, No B

KS i Softsars

ACH Operating Systeus Review - Vol 19,11

ACM Operating Systeas Review - Vol 19, i!

ACH Operating Systess Review - Vol 19,11

ACS Operating Systess Review - Vol 19,12

ACH Operating Systets Review - Vol 19,s2

48 IEEE Distributed Processing Newsletter

49 ftCrl Computin g Surveys

50 ACH Operating Systess Ssvia« - vol 17.15

9th ACS SvsQosii.'S on Oz.eratir.q Systass

~ r I'C?? ji nos -IT la? c^f1. ini^rnanondi

ConferShCS on Distributed Ceaputi^v Syst^

?^oci=dinqs of th; 5th Ifitsrratior.ii

Canfersrica on Distributed Ccsputiiiv Systs

ACil Operating Syst3iss Ssviea - V;l 17.15

?th ACR Syaposiea on Qperitinc Sy;tai3r

Systass and Software

Systems and Softsare

June 1934

March 1983

narch 1983

Harch 1993 '

March 1983

Harch 1933

. Morch 1933

(larch 1983

Harch 1983

Harch 1903

Harch ;9S3

Harch 1935

June 19S3

July 1931

Jinuary 1985

October 1964

January 1985

January 1935

April 1985-

April 1985

?hrch 1985

Hirch 1?33

ilarch 1983

NOS,distributed coaputer systass

ISO OS!-Presentation layer,aetsorkjvirtual

processing systas

Internetwork,server.distributed database

Local network,distributed cosputing,Apollo .

Bcaain

Server.Ethernet,virtual disks

Electronic sail,centralized/distributed

5ysteE5,reliability,systea recovery

ISO Layer 3.broadband LAN,routing

ISO Transport layer,ISO Ll-4 statistics,

datagram,virtual circuit,LAN,long-haul

ISO QSI.local network,user prograsaable NIU

Distributed processors,cosiunicationsoriented operating systea,upper level protocol

ISO QSI,netnorking

Novell NetWare, BOS 3.1, LAN 0/3,

FiU server

Bistributed Q/S,Unix,Ethernet.

Distributed 0/S.Unix,Sarvar

Broadbe-d LAN, Reiaote Operating Systesi

ftccass

UNIX.high-speed LAN,Heterogeneous processor

cosaunication

LHii b j Hpp i. 1 Lai i OH"* i a\: 5T pTOt u

;

.Ci »itST'nOr t-.

ills sanigsisent systsiB
HASA/SSFi : Network Operating Systess Bibliography of Relevant LitsraturE

53

59

60

61

62

64

£5

66

Author(s)

Pops,ft

Foudriatj E.

Faker, Y

Andreas, 6 and Schreider, 'F

Kohier, a

Parr. F,, J. Auerback and

E. Goldstein

Baker D, J. Hieselthiar, and

A. Ephresiides

Desbrisay. 8. st a!

Eanino, J. S. st ai

"iiier, B,, C. Hacrinder. and

S, Sechrsst

Mittsi, L. and R, Curtis

Fank, A.,L. Kittle, and

A. Bernstein

LsBanc. T, and S, Ccok

Hohan, C. and L, Sittie

Title

Network Resource

Encoding CCITT X.409 Presentation Transfer

Syntax

Embedded Network Coaputer Research for Future

Space Systsss

Huitiprocessor Systeas

Concepts and Notations for Concurrent

Prograsaing

A Survey of Techniques for Synchronization and

Recovery in Decentralized Computer Systeas

Distribute Processing Involving Persona!'

Computers

Distributed Control Algoritha for Scheduling

the Activation of Links in a Self Organizing

Hobiis Radio Network

Airborne Caasunicaticr.s Reccnstitution Experiment

10*8 Fault Tolerant Aspects of the CHORUS

Distributed Systes

A Distributee Programs Monitor for Berkeley UNIX

TiiBe Hanaqesent for Debucging Distributed

Systeits

Multicast Cosaunication on Network Coipaters

High Level Broadcast Ccaisunication in Local

Area Networks

Local Reconfiguration of Hanagesent Tress in

Laroe Networks
NASA/BSFC : Network Operating Systeas Bibliography of Relevant Literatur;

Docuasnt f Source Publication Date Key Mortis/Phrases

56 Ceaputer Ccaaunicalion Review October 1984

-JJ (to lie published in IEEE Distributed

Processing Technical Cceaittee Newsletter;

58 ftcadeaic Press 19B3

59 ACF, Coaputinq Surveys ilarch 1933

SO ftCH Coapating Surveys June 19B1

61 IEEE Journal on Selectes Areas in Ccaauni- Hay 1983

cations

62 International Conference on CQsiaur.ications 19B2

63 EA3CON 1984

64 The 5th Intarnationai CG^tsrsnca on Di=- !985

tributes Coapating Systeas

65 The 5th International Conference on Dis- !9S5

tributed Coaputing Systsas

66 The 5th Intarnationai Conference on Dis- 1965

tributed Computing Systeas

67 IEEE ScftMare Hay 1935

08 IEEE Softsare Hay 19S5

69 The 5th international Confarence on Dis- 1985

tributed Coaputing Systeas
APPENDIX C

Bibliography of Relevant

Standards
PROTOCOL REFERENCES

n - working memos

dp - draft proposal

dis - draft international standard

is - international standard

GENERAL

ISO Internationa l Standard 7498 Open Systems Interconnection

Reference Model (also CCITT X.200 )

APPLICATION LAYER

ISO n!60 Architectural Detail of the Upper Three Layers of OS!

ISO DP 8649/1 OSI Definitio n of Common Application Service

Elements Part I: Introduction

ISO DP 8649/3 OSI Definition of Common Application Service

Elements Part III: Commitment Concurrency and Recovery

ISO DP 8650/3 OSI Specificatio n of Protocols for Commo n

Application Service Elements Part III: Commitment Concurrency

and Recovery

ISO DP 8650/1 OSI Specificatio n of Protocols for Commo n

Application Service Elements Part I: Introduction

CCITT E.410 Internationa l Networ k Managemen t - Genera l

Information.

CCITT E.411 Internationa l Networ k Management - Operational

Guidance.

CCITT E.412 International Network Management - Planning.

CCITT C.413 International Network Management - Organization.

ISO n278 Reference Model for Text Preparation and Interchange

ISO DP 8613/4 Text Preparation Text Structure s Part IV: Offic e

Document Interchange Formats

ISO DP 8613/3 Text Preparatio n Text Structure s Part III:

Document Profile

ISO DP 8613/2 Text Preparation Text Structures Part II: Offic e

Document Architecture

ISO n63 Director y Service for OSI Systems Draf t Servic e

Specification
ISO n61 Management Information Service Definition

ISO DP 8832 OSI Specification of the Basic Class Protocol for Job

Transfer and Manipulation

ISO DP 8831 OSI Job Transfer and Manipulation Concepts and

Services

ISO n!75 OSI Virtual Terminal Service — Basic Class

ISO n223 OSI Virtual Terminal Protocol — Basic Class

ISO DP 8571/1 OSI File Transfer Access and Management Part I:

General Description

ISO DP 8571/2 OSI File Transfer Access and Management Part II:

The Virtual Filestore

ISO DP 8571/3 OSI File Transfer Access and Management Part III:

The File Service Definition

ISO DP 8571/4 OSI File Transfer Access and Management Part IV:

The File Protocol Specification

CCITT X.401, Message Handling Systems: Basic Service Elements

and Optional User Facilities.

CCITT X.411, Message Handling Systems: Message Transfer Layer.

CCITT X.420, Message Handling Systems: Interpersonal Messaging

User Agent Layer.

CCITT X.409, Message Handling Systems: Presentation Transfer

Syntax and Notation.

CCITT X.408, Message Handling Systems: Encoded Information Type

Conversion Rules.

CCITT X.430, Message Handling Systems: Access Protocol for

Teletex Terminal.

NETWORK LAYER.

CCITT X.121 International Numbering Plan for Public Data

Networks.

CCITT X.25 Interface between Data Terminal Equipment (DTE) and

Data Circuit-terminating Equipment (DCE) for Terminals Operating

in the Packet Mode on Public Data Networks.

ISO DP 8473 Protocol for Providing the Connectionless Network

Service.
APPENDIX D

RESEARCH PROJECTS
CNET

N. Lijtmaer and P. Inverardi, IEI-CNR Italy

Distributed system implementation in Ada

CRONUS

Bolt, Beranek, and Newman, Cambridge, MA

Distributed Operating System with heterogeneous local

operating system, DOD environment

DEMOS

Michael Powell and Barton Miller, University of California

Process Migration

DISTOS

Dietov Wybranietz, University of Kaiserslautern, W. Germany

Distributed Interprocess Communication, LADY programming

environment

ENCHERE

J.-P. Banatre

IRISA (Institut de Recherche pour Information et Systems

Aleatoires

High Availability, Non-volatile RAM

IBM SAN JOSE

Bruce Lindsay

Efficiency of Concurrency and Synchronization

IBM SWITZERLAND

Phil Janson, IBM Research

Efficient Inter-Layer (OSI) Communication

MAYFLOWER

Graham Hamilton, University of Cambridge, UK

Remote Procedure Call, Run time binding
RESEARCH PROJECTS

ARCHONS

Douglas Jenson, L. Sha, Carnegie Mellon

Tightly coupled distributed system, high availability,

modularity, optimal resource management

ATHENA

Jerry Saltzer, MIT

Network of diverse personal computers, clusters of file and

disk servers

BOLT, BERANEK, AND NEWMAN (BBN) - X.409

Arthur Pope

X.409 Data Representation Utility Software

CARNEGIE-MELLON - LU6.2

J. Rosenberg, Carnegie-Mellon and IBM

Program-Program Communication, LU6.2 under UNIX

CARNEGIE-MELLON - IBM Network File System

Alfred Spector

Distributed Verion of ANDREW, move server functions to

personal computer, UNIX interface

CHORUS

J.-S. Banino

INRIA (Institute National de Recherche en Informatique et

Automatique)

LeChesnay Cedex, France

Interprocess Communication, High Availability

CLOUDS

Martin McKendry

Georgia Tech

Concurrenc y an d Synchronizatio n Algorithms, hig h

availability
MEGLOS

R. Gaglianello and H. Kafseff, AT&T Bell Laboratories

Job Migration in UNIX

MICROS

Larry Wittie, SUNY Stoney Brook

Interprocess Communication, High Availability, Distributed

System Debugging

PULSE

Andrew Wellings, University of York, UK

Distributed System Implementation in Ada, file system,

interprocess communication

SWIFT

Larry Swift, MIT

Interprocess Communication, Upcalls

DISTRIBUTED V SYSTEM

David Cheriton, Stanford University

Distributed System Performance, Efficiency Distributed

Interprocess Communication, Process Groups

NASA Langley

Edwin Foudriat

High Availability, Multipathing

DISTRIX

David Christie, Convergent Technologies

UNI X System V, message based kernel, single user

workstations network

LINGS

John Fletcher, Lawrence Livermore National Laboratory

High throughput networks
CAMBRIDGE DISTRIBUTED SYSTEM/PROJECT UNIVERSE

Roger Needham, University of Cambridge, UK

ANDREW

M. Satya

Very large distributed file system (to 5000 nodes), UNIX

file systems

Single, system wide shared name space

ARGUS

William E. Weihl, MIT

Concurrency and Synchronization