local networks

Upload: swati-hello

Post on 05-Apr-2018

214 views

Category:

Documents


0 download

TRANSCRIPT

  • 7/31/2019 Local Networks

    1/23

    This is a copy of a paper that was presented at the Fourth Conference on Local

    Networks, Minneapolis, 1979. It was later republished (with permission) in the North-

    Holland Publishing Companies Computer Networks 3 (1979) pp. 389-399.

    This online version resulted from scanning and OCRing a computer generated

    original. Since optical character recognition is certainly not perfect, if you notice any

    errors, please let me ([email protected]) know. Thanks!

    A note on the references - to jump to the references section of the paper to look at a

    citation, click on the numeric reference entry in bracketed references. E.g. in "[1,2]"

    click on the1or on the2to go to the corresponding citation in the references at the

    end of the paper. Where possible the references will link to Web accessible content.

    A note on the figures - since the figures were also scanned in, they are certainly not

    perfect. In case you are unable to read some of the detail on the versions included with

    the text, you can click on the figures themselves to see somewhat larger versions

    where more detail is visible.

    If you are somehow looking at a hardcopy version of this paper and wish to view it on

    the WWW, you can find it at the URL:

    http://www.nersc.gov/~jed/papers/Components/

    for now - naturally...

    Last update to this HTML version, August 18, 2006 --Jed

    Components of a Network Operating SystemJames E. (Jed) Donnelley

    Lawrence Livermore National Laboratory, Livermore, California, USA"James E (Jed) Donnelley"

    http://www.webstart.com/jed/

    Abstract:Recent advances in hardware interconnection techniques for local networks

    have highlighted the inadequacies in existing software interconnection

    technology. Though the idea of using a pure message-passing operating system

    to improve this situation is not a new one, in the environment of a mature, highspeed, local area network it is an idea whose time has come. A new timesharing

    system being developed at the Lawrence Livermore Laboratory is a pure

    message-passing system. In this system, all services that are typically obtained

    directly by a system call (reading and writing files, terminal I/O, creating and

    controlling other processes, etc.) are instead obtained by communicating via

    messages with system service processes (which may be local or remote). The

    mailto:[email protected]:[email protected]:[email protected]://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#2http://www.webstart.com/jed/papers/Components/#2http://www.webstart.com/jed/papers/Components/#2http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#2http://www.webstart.com/jed/papers/Components/#2http://www.webstart.com/jed/papers/Components/#2http://www.nersc.gov/~jed/papers/Components/http://www.nersc.gov/~jed/papers/Components/mailto:[email protected]:[email protected]://www.webstart.com/jed/http://www.webstart.com/jed/http://www.webstart.com/jed/mailto:[email protected]://www.nersc.gov/~jed/papers/Components/http://www.webstart.com/jed/papers/Components/#2http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#2http://www.webstart.com/jed/papers/Components/#1mailto:[email protected]
  • 7/31/2019 Local Networks

    2/23

    motivation for the development of this new system and some design and

    implementation features needed for its efficient operation are discussed.

    Keywords:Network, local network, operating system, network operating system, message,

    protocol, distributed

    1. Introduction

    The basic job performed by an operating system is multiplexing the physical resources

    available on its system (Fig. l). By a variety of techniques such as time slicing,

    spooling, paging, reservation, allocation, etc. the operating system transforms the

    available physical resources into logical resources that can be utilized by the active

    processes running under it (Fig. 2).

    Figure 1 - Physical resources directly attached to a single processor.

    Figure 2 - Logical resources made available to a user process.

    http://www.webstart.com/jed/papers/Components/Figure-2.gifhttp://www.webstart.com/jed/papers/Components/Figure-1.gifhttp://www.webstart.com/jed/papers/Components/Figure-2.gifhttp://www.webstart.com/jed/papers/Components/Figure-1.gif
  • 7/31/2019 Local Networks

    3/23

    The interface between a process running under an operating system and the world

    outside its memory space is the "system call", a request for service from the operating

    system. The usual approach taken in operating system design has been to provide

    distinct system calls to obtain service for each type of available local resource (Fig. 3).

    Figure 3 - Request structure for a typical third generation operating system.

    If a network becomes available, system calls for network communication are added to

    the others already supported by the operating system. Some problems with this

    approach are the Dual Access and Dual Service Dichotomies discussed below. It is

    argued here that operating systems to be connected to a network (particularly a high

    speed local area network) should be based on a pure message-passing monitor (Fig. 4)

    http://www.webstart.com/jed/papers/Components/Figure-3.gif
  • 7/31/2019 Local Networks

    4/23

    Figure 4 - Resource interface for a message-passing operating system.

    The title of this paper has at least two interpretations that are consistent with the intent

    of the author:

    If the term "Network Operating System" is taken to refer to a collection ofcooperating computer systems working together to provide services by

    multiplexing the hardware resources available on a network, then the title

    "Components of a Network Operating System" suggests a discussion of the"Component" systems.

    On the other hand, the term "Network Operating System" can also be taken torefer to a single machine monitor to which the adjective "Network" is applied

    to indicate a design that facilitates network integration. In this case the title

    "Components of a Network Operating System" suggests a discussion of the

    component pieces or modules that comprise such a single machine operating

    system.

    The basic approach taken here will be to describe the components of a single machine

    operating system being implemented at the Lawrence Livermore Laboratory (LLL).The presentation will be largely machine independent, however, and will include

    discussion of the integration of the described system into a network of similar and

    dissimilar systems.

    2. Historical Perspective

    http://www.webstart.com/jed/papers/Components/Figure-4.gif
  • 7/31/2019 Local Networks

    5/23

    LLL has a long history of pushing the state of the art in high speed scientific

    processing to satisfy the prodigious raw processing requirements of the many physics

    simulation codes run at the laboratory. The high speed, often few of a kind computing

    engines (For example, Univac-1, 1953, Larc, Remington Rand, 1960, Stretch, IBM,

    1961, 6600, CDC, 1964, Star-100, CDC, 1974, Cray-1, Cray Research, 1978) utilized

    at LLL are usually purchased before mature operating system software is available for

    them [22]. The very early operating systems implemented at LLL were quite simpleand were usually coded in assembly language. By the time of the CDC 6600 (1965),

    however, they were becoming more comp1ex timesharing systems. By 1966 it was

    decided to write the operating system for the 6600 in a higher level language. This

    decision made it easier to transfer that system (dubbed LTSS, Livermore Time

    Sharing System) to new machines as they arrived: CDC 7600, CDC Star-100, and the

    Cray-l.

    Another important development at LLL that began about the time of the first LTSS

    was networking. It started with a local packet switched message network for sharing

    terminals and a star type local file transport network for sharing central file storage(e.g. the trillion bit IBM photodigital storage device). These early networks worked

    out so well that they eventually multiplied to include a Computer Hardcopy Output

    Recording network, a Remote Job Entry Terminal network, a data acquisition

    network, a tape farm, a high speed MASS storage network, and others. The entire

    interconnected facility has retained the name "Octopus" [12,27] from its earliest days

    as a star topology.

    Recent developments in high speed local networking [5,11,17] are making it easier to

    flexibly connect new high speed processors into a comprehensive support network

    like Octopus. This very ease of hardware interconnection, however, is forcing somerethinking of software interconnection issues to ensure that the software interconnects

    as easily as the hardware [26,27].

    3. Motivation for Network LTSS

    Recently the network systems group at LLL has started down a significant new fork in

    the LTSS development path. The new version of LTSS is different enough from the

    existing versions that it has been variously called New LTSS or Network LTSS

    (NLTSS). Many of the reasons for the new development have little to do withnetworking. For example, NLTSS shares resources with capabilities

    [4,8,10,16,20,21,28]. This allows it to combine the relatively ad hoc sharing

    mechanisms of older LTSS versions into a more general facility providing principal-

    of-least-priviledge domain protection. It is only the lowest level network related

    motivations for the NLTSS development, however, that we will consider here.

    When a processor is added to a mature high speed local area network like Octopus, it

    needs very little in the way of peripherals [27]. For example, when a Cray-1 computer

    http://www.webstart.com/jed/papers/Components/#22http://www.webstart.com/jed/papers/Components/#22http://www.webstart.com/jed/papers/Components/#22http://www.webstart.com/jed/papers/Components/#12http://www.webstart.com/jed/papers/Components/#12http://www.webstart.com/jed/papers/Components/#12http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#5http://www.webstart.com/jed/papers/Components/#5http://www.webstart.com/jed/papers/Components/#5http://www.webstart.com/jed/papers/Components/#11http://www.webstart.com/jed/papers/Components/#11http://www.webstart.com/jed/papers/Components/#17http://www.webstart.com/jed/papers/Components/#17http://www.webstart.com/jed/papers/Components/#17http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#4http://www.webstart.com/jed/papers/Components/#4http://www.webstart.com/jed/papers/Components/#4http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#20http://www.webstart.com/jed/papers/Components/#20http://www.webstart.com/jed/papers/Components/#20http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#28http://www.webstart.com/jed/papers/Components/#28http://www.webstart.com/jed/papers/Components/#28http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#28http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#20http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#4http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#17http://www.webstart.com/jed/papers/Components/#11http://www.webstart.com/jed/papers/Components/#5http://www.webstart.com/jed/papers/Components/#27http://www.webstart.com/jed/papers/Components/#12http://www.webstart.com/jed/papers/Components/#22
  • 7/31/2019 Local Networks

    6/23

    was recently added to Octopus, it came with only some disks, a console, and a high

    speed net- work interface. All of the other peripherals (terminals, mass storage,

    printers, film output, tape drives, card readers, etc. etc.) are accessed through the

    network. The operating system on a machine like this faces two basic problems when

    it is connected to the network:

    A. How to make all the facilities available on the network available to itsprocesses, and

    B. How to make all of the resources that it and its processes supply available toprocesses out on the network (as well as its own processes).

    Typical third generation operating systems have concerned themselves with supplying

    local processes access to local resources. They do this via operating system calls.

    There are system calls for reading and writing files (access to the storage resource),

    running processes (access to the processing resource), reading and writing tapes

    (access to a typical peripheral resource), etc. When networks came along, it was

    natural to supply access to the network resources by supporting system calls to sendand receive data on the network (Fig. 3).

    3.1 The Dual Access Dichotomy

    Unfortunately, however, this approach is fraught with difficulties for existing

    operating systems. Just supporting general network communication is not at all an

    easy task, especially for operating systems without a flexible interprocess

    communication facility. In fact, if flexible network communication system calls are

    added to an operating system, they provide a de facto interprocess communication

    mechanism (though usually with too much overhead for effective local use).

    Even systems that are able to add flexible network communication calls create a dual

    access problem for their users (Fig. 5). For example, consider a user programming a

    utility to read and write magnetic tapes. If a tape drive is remote, it must be accessed

    via the network communication system calls. On the other hand, if the drive is local, it

    must be accessed directly via a tape access operating system call. Since any resource

    may be local or remote, users must always be prepared to access each resource in two

    possible ways.

  • 7/31/2019 Local Networks

    7/23

    Figure 5 - The Dual Access Dichotomy for direct call operating systems.

    3.2 The Dual Service Dichotomy

    The problem of making local resources available to a network has proven difficult for

    existing operating systems. The usual approach is to have one or more "server"

    processes waiting for requests from the network (Fig. 6). These server processes then

    make local system calls to satisfy the remote requests and return results through the

    network. Examples of this type of server (though somewhat complicated by access

    control and translation issues) are the ARPA network file transfer server and Telnet

    user programs [6,7]. With this approach there are actually two service codes for each

    resource, one in the system monitor for local service and one in the server process forremote access.

    http://www.webstart.com/jed/papers/Components/#6http://www.webstart.com/jed/papers/Components/#6http://www.webstart.com/jed/papers/Components/#6http://www.webstart.com/jed/papers/Components/#7http://www.webstart.com/jed/papers/Components/#7http://www.webstart.com/jed/papers/Components/#7http://www.webstart.com/jed/papers/Components/Figure-6.gifhttp://www.webstart.com/jed/papers/Components/Figure-5.gifhttp://www.webstart.com/jed/papers/Components/Figure-6.gifhttp://www.webstart.com/jed/papers/Components/Figure-5.gifhttp://www.webstart.com/jed/papers/Components/#7http://www.webstart.com/jed/papers/Components/#6
  • 7/31/2019 Local Networks

    8/23

    Figure 6 - The Dual Service Dichotomy for direct call operating systems.

    The major network motivation for the New LTSS development is to solve problems

    A. and B. in future versions of LTSS in such a way as to avoid the dual access and

    dual service dichotomies. By doing so, NLTSS also reaps some consequential benefits

    such as user and server mobility, user extendibility, and others.

    4. The Overall NLTSS Philosophy

    NLTSS provides only a single message system call (described in the next section).

    Figure 7 illustrates the view that an NLTSS process has of the world outside its

    memory space. Deciding how and where to deliver message data is the responsibility

    of the NLTSS message system and the rest of the distributed data delivery network.

    Figure 7 - NLTSS processes have only the distributed message system for dealing

    with the world outside their memory spaces.

    4.1 Avoiding The Dual Access and Dual Service Dichotomies

    There are two fundamentally opposite methods of avoiding the dual access

    dichotomy: either make all resource accesses appear local, or make all resource

    accesses appear remote. The TENEX Resource Sharing EXECutive (RSEXEC) is an

    example of the former approach [23]. Under the RSEXEC, system calls are trapped

    http://www.webstart.com/jed/papers/Components/#23http://www.webstart.com/jed/papers/Components/#23http://www.webstart.com/jed/papers/Components/Figure-7.gifhttp://www.webstart.com/jed/papers/Components/#23
  • 7/31/2019 Local Networks

    9/23

    and interpreted to see if they refer to local or remote resources. The interpreter must

    then be capable of both access modes (Fig. 8).

    Figure 8 - Emulation technique for removing dual access from user codes.

    NLTSS uses the opposite approach. Since all NLTSS resource requests are made and

    serviced with message exchanges, the message system is the only part of NLTSS that

    need distinguish between local and remote transfers (Fig. 9). Also, since the

    distinction made by the message system is independent of the message content,

    NLTSS eliminates the dual access dichotomy rather than just moving it away from the

    user as the RSEXEC and similar systems do.

    Figure 9 - Uniform remote access in a message-passing operating system.

    NLTSS is able to avoid the dual service dichotomy by having the resource service

    processes be the only codes that service resource requests (Fig. 10). This means,

    however, that all "system calls" must go through the NLTSS message system. The

    http://www.webstart.com/jed/papers/Components/Figure-9.gifhttp://www.webstart.com/jed/papers/Components/Figure-8.gifhttp://www.webstart.com/jed/papers/Components/Figure-9.gifhttp://www.webstart.com/jed/papers/Components/Figure-8.gif
  • 7/31/2019 Local Networks

    10/23

    major difficulty faced in the NLTSS design is to supply resource access with this pure

    message-passing mechanism and yet still keep system overhead at least as low as that

    found in the competing third generation operating systems available to LLL.

    Figure 10 - Uniform remote service in a message-passing operating system.

    4.2 Comparable Systems

    There have been many operating system designs and implementations that supply all

    resource access through a uniform interprocess communication facility

    [1,2,3,8,10,15,16,21,24,28]. These interprocess communication mechanismsgenerally do not extend readily into a network, however. For example, in a system

    that utilizes shared memory for communication, remote processes have difficulty

    communicating with processes that expect such direct memory access. Capability

    based systems generally experience difficulty extending the capability passing

    mechanism into the network[4,8,10,16,20,21,28].

    NLTSS is certainly not the first pure message-passing system [1,15,24]. In fact, it is

    remarkably similar to a system proposed by Walden [24]. Any contributions that

    NLTSS has to make will come from the care that was given to exclude system

    overhead and yet still support full service access to local and remote resourcesthrough a uniform message-passing mechanism.

    5. The NLTSS Message System Interface

    Since all resource access in NLTSS is provided through the message system, the

    message system interface is a key element in the system design. The major goal of the

    NLTSS message system interface design was to supply a simple, flexible

    http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#2http://www.webstart.com/jed/papers/Components/#2http://www.webstart.com/jed/papers/Components/#2http://www.webstart.com/jed/papers/Components/#3http://www.webstart.com/jed/papers/Components/#3http://www.webstart.com/jed/papers/Components/#3http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#15http://www.webstart.com/jed/papers/Components/#15http://www.webstart.com/jed/papers/Components/#15http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/#28http://www.webstart.com/jed/papers/Components/#28http://www.webstart.com/jed/papers/Components/#28http://www.webstart.com/jed/papers/Components/#4http://www.webstart.com/jed/papers/Components/#4http://www.webstart.com/jed/papers/Components/#4http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#20http://www.webstart.com/jed/papers/Components/#20http://www.webstart.com/jed/papers/Components/#20http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#28http://www.webstart.com/jed/papers/Components/#28http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#15http://www.webstart.com/jed/papers/Components/#15http://www.webstart.com/jed/papers/Components/#15http://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/Figure-10.gifhttp://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/#15http://www.webstart.com/jed/papers/Components/#1http://www.webstart.com/jed/papers/Components/#28http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#20http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#4http://www.webstart.com/jed/papers/Components/#28http://www.webstart.com/jed/papers/Components/#24http://www.webstart.com/jed/papers/Components/#21http://www.webstart.com/jed/papers/Components/#16http://www.webstart.com/jed/papers/Components/#15http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#8http://www.webstart.com/jed/papers/Components/#3http://www.webstart.com/jed/papers/Components/#2http://www.webstart.com/jed/papers/Components/#1
  • 7/31/2019 Local Networks

    11/23

    communication facility with an average local system overhead comparable to the cost

    of copying the communicated data. To do this it was necessary to minimize the

    number of times that the message system must be called. Another important goal was

    to allow data transfers from processes directly to and from local peripherals without

    impacting the uniformity of the message system interface.

    5.1 The Buffer Table

    The most important element in the NLTSS message system design is a data structure

    that has been called a Buffer Table (Fig. 11). A linked list of buffer tables is passed to

    the NLTSS message system when a user process executes a system call (Fig. 12).The NLTSS Buffer Table

    1. Link2.3. Action bits (Activate, Cancel, and Wait)4.5. Send/Receive bit6.7. Done bit8.9. Beginning (BOM) and end (EOM) of message bits10.11. Receive-From-any and Receive-To-Any bits12.13. To and From network addresses14.15. Base and length buffer description16.17. Buffer offset pointer18.19. Status20.

    Figure 11 - The NLTSS Buffer Table.

  • 7/31/2019 Local Networks

    12/23

    Figure 12 - The NLTSS message system call.

    The Buffer Table fields are used as follows:

    1. The Link field is a pointer to the next Buffer Table (if any) to be processed bythe message system. When the message system is called, it is passed the head

    of this linked list of Buffer Tables. The linkage mechanism provides for data

    chaining of message pieces to and from a single address pair, for activation of

    parallel data transfers, and for waiting on completion of any number of data

    transfers.

    2. The Action bits indicate what actions are to be performed by the messagesystem during a call:

    o The Activate bit requests initiation of a transfer. If the transfer can't becompleted immediately because the matching Buffer Table is remote orbecause of an insufficient matching buffer size, the message system

    remembers the active Buffer Table for later action.

    o The Cancel bit requests deactivation of a previously activated BufferTable. The Cancel operation completes immediately unless a peripheral

    is currently transferring into or out of the buffer.

    o The Wait action bit requests that the process be awakened when thisBuffer Table is Done (see Done bit below).

    http://www.webstart.com/jed/papers/Components/Figure-12.gif
  • 7/31/2019 Local Networks

    13/23

    3. The Send/Receive bit indicates the direction of the data transfer.4. The Done bit is set by the message system when a previously activated Buffer

    Table is deactivated due to completion, error, or explicit Cancel.

    5. The BOM and EOM bits provide a mechanism for logical messagedemarcation. In a send Buffer Table, the BOM bit indicates that the first data

    bit in the buffer marks the beginning of a message. Similarly, the EOM bit

    indicates that the last bit in the buffer marks the end of a message. For receiveBuffer Tables the BOM and EOM bits are set to indicate the separation in

    incoming data.

    6. The Receive-From-Any and Receive-To-Any bits are only meaningful forreceive Buffer Tables. If on, they indicate that the Buffer Table will match (for

    data transfer) a send Buffer Table with anything in the corresponding address

    field (see below). Of course data will only be routed to this receive buffer if it's

    "To" address actually addresses the activating process. If an "Any" bit is set,

    the corresponding address is filled in upon initiation of a transfer and the "Any"

    bit is turned off.

    7. The To and From address fields indicate the address pair (or association) overwhich the data transfer occurs. The From address is checked for validity.

    8. The Base and Length fields define the data buffer (bit address and bit length).9. The Offset field is updated to point just after the last bit of data in the buffer

    successfully transferred (relative to Base).

    10.The Status field is set by the message system to indicate the current state of thetransfer. It should be noted that the NLTSS message system call is designed to

    minimize the number of times that a process must execute a system call.

    Generally a process will call the message system only when it has no

    processing left to do until some communication completes. It is also important

    that messages of arbitrary length can be exchanged (even by processes that

    have insufficient memory space to hold an entire message).

    The BOM and EOM message separators are in many ways like virtual circuit opening

    and closing indicators. It is expected that for NLTSS message systems interfacing

    with virtual circuit networks (e.g. an X.25 network) that circuits will be opened at the

    beginning of a message and closed at the end. The first network protocol that the

    NLTSS message system will be interfaced with, however, has been designed to

    eliminate the opening and closing of circuits while still maintaining logical message

    separation very much as the NLTSS message system interface does [13,25,26].

    6. The Structure of the NLTSS Monitor

    The paucity and simplicity of the NLTSS system calls allow its monitor to be quite

    small and simple (a distinct advantage at LLL where memory is always in short

    supply and security is an important consideration).

    http://www.webstart.com/jed/papers/Components/#13http://www.webstart.com/jed/papers/Components/#13http://www.webstart.com/jed/papers/Components/#13http://www.webstart.com/jed/papers/Components/#25http://www.webstart.com/jed/papers/Components/#25http://www.webstart.com/jed/papers/Components/#25http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#25http://www.webstart.com/jed/papers/Components/#13
  • 7/31/2019 Local Networks

    14/23

    Essentially all that is in the NLTSS monitor is the message call handler and device

    drivers for directly attached hardware devices (figure 4). In the case of the CPU

    device, the driver contains the innermost parts of the scheduler (the so-called

    Alternator) and memory manager (that is those parts that implement mechanism, not

    policy).

    One property of the current NLTSS monitor implementations is that each devicedriver must share some resident memory with a hardware interface process for its

    device. For example, the storage driver must share some memory with the storage

    access process, and the alternator must share some memory with the process server.

    This situation is a little awkward on machines that don't have memory mapping

    hardware. On systems with only base and bounds memory protection, for example, it

    forces the lowest level device interface processes to be resident.

    7. The NLTSS file system

    The file system illustrates several features of the NLTSS design and implementations.

    The basic service provided by the file system is to allow processes to read and write

    data stored outside their memory spaces. The way in which a process gets access to a

    file involves the NLTSS capability protocol [26] and is beyond the scope of this

    paper. We will assume that the file server has been properly instructed to accept

    requests on a file from a specific network address. The trust that the servers have in

    the "From" address delivered by the message system is the basis for the higher-level

    NLTSS capability protection mechanisms [10,14].

    The simplest approach for a file server to take might be to respond to a message of theform "Read', portion description (To file server, From requesting process) with a

    message containing either "OK, data or "Error" (To requesting process, From fileserver).

    Unfortunately, this approach would require that the file server be responsible for both

    storage allocation (primarily a policy matter) and storage access (a mechanism).

    Either that or the file server would have to flush all data transfers through itself on

    their way to or from a separate storage access process.

    The mechanism implemented in NLTSS is pictured in figure 13. To read or write afile, a process must activate three Buffer Tables. For reading, it activates a send of the

    command to the file server, a receive for the returned status, and a separate receive for

    the data returned from the storage access process. For writing, it activates similar

    command status Buffer Tables, but in place of a data receive, it activates a data send

    to the storage access process.

    http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#14http://www.webstart.com/jed/papers/Components/#14http://www.webstart.com/jed/papers/Components/#14http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#26
  • 7/31/2019 Local Networks

    15/23

    Figure 13 - The NLTSS file system.

    This example illustrates the importance of the linkage mechanism in the message

    system interface. In most systems a file access request requires only one system call.

    Through the linkage mechanism, NLTSS shares this property. In fact, in NLTSS a

    process can initiate and/or wait on an arbitrary number of other transfers at the same

    time. For example, when initiating a file request, it may be desirable to also send an

    alarm request (return a message after T units of time) and wait for either the file status

    message or the alarm response.

    When the file server gets a read or write request, it translates the logical file access

    request into one or more physical storage access requests that it send to the storage

    access process. In this request it includes the network address for the data transfer

    (this was included in the original "Read" or "Write" request). Having received the

    storage access request, the access process can receive the written data and write it to

    storage or read the data from storage and send it to the "Read"ing process.

    This mechanism works fine in the case where the requesting process and the storage

    access process are on separate machines (note that the file server can be on yet a third

    machine). In this case the data must be buffered as it is transferred to or from storage.

    In the case where the requesting process and the storage access processes are on the

    same machine, however, it is possible to transfer the data directly to or from the

    http://www.webstart.com/jed/papers/Components/Figure-13.gif
  • 7/31/2019 Local Networks

    16/23

    memory space of the requesting process. In fact, many third generation operating

    systems perform this type of direct data transfer.

    To be a competitive stand-alone operating system, NLTSS must also take advantage

    of this direct transfer opportunity. In our implementations, the mechanism to take

    advantage of direct I/O requires an addition to the message system.

    There are two additional action bits available in the Buffer Tables of device access

    processes, IOLock and IOUnLock. If a device access process wants to attempt a direct

    data transfer, it sets the IOLock bit in its Buffer Table before activation. If the

    message system finds a match in a local process, instead of copying the data, it will

    lock the matching process in memory and return the Base address (absolute), Length

    and Offset of its buffer in the IOLocking Buffer Table. The device access process can

    then transfer the data directly to or from storage. The IOUnLock operation releases

    the lock on the requesting processes memory and updates the status of the formerly

    locked Buffer Table.

    The most important aspect of this direct I/0 mechanism is that it has no effect on the

    operation of the requesting process OR on that of the file server. Only the device

    access process (which already has to share resident memory to interact with its device

    driver) and the message system need be aware of the direct I/O mechanism.

    8. A Semaphore Server Example

    The example of an NLTSS semaphore [9,10] server can be used to further illustrate

    the flexibility of the NLTSS message system. The basic idea of the semaphore server

    is to implement a logical semaphore resource to support the following operations:

    1. "P": semaphore number (To semaphore server, From requester) - Decrementthe integer value of the semaphore by 1. If its new value is less than zero then

    add the "From" address of the request to a list of pending notifications.

    Otherwise send a notification immediately.

    2. "V": semaphore number (To semaphore server, From requester) - Increment thevalue of the semaphore by 1. If its value was less than zero then send a

    notification to the oldest address in the pending notification list and remove the

    address from the list.

    Typically such a semaphore resource is used by several processes to coordinate

    exclusive access to a shared resource (a file for example). In this case, after the

    semaphore value is initialized to 1, each process sends a "P" request to the semaphore

    server to lock the resource and awaits notification before accessing it (note that the

    first such locking process will get an immediate notification). After accessing the

    resource, each process sends a "V" request to the semaphore server to unlock the

    resource.

    http://www.webstart.com/jed/papers/Components/#9http://www.webstart.com/jed/papers/Components/#9http://www.webstart.com/jed/papers/Components/#9http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#9
  • 7/31/2019 Local Networks

    17/23

    An NLTSS implementation of such a server might keep the value of the semaphore

    and a notification list for each supported semaphore. The server would at all times

    keep a linked list of Buffer Tables used for submission to the message system. This

    list would be initialized with some number (chosen to optimize performance) of

    receive Buffer Tables "To" the semaphore server and "From" any. These Buffer

    Tables would also have their activate and wait action bits turned on.

    The semaphore server need only call the message system after making a complete

    scan of its receive Buffer Tables without finding any requests to process (i.e. any with

    Done bits on). Any Done receive requests can be processed as indicated above (l. and

    2.). If a notification is to be sent, an appropriate send Buffer Table with only the

    Activate action bit on can be added to the Buffer Table list for the next message

    system call. These send Buffer Tables are removed from the list after every message

    system call.

    Processes may in general be waiting on some receive completions to supply more

    data, and for some send completions to free up more output buffer space. Even in thismost general situation, however, they need only call the message system when they

    have no processing left to do.

    This semaphore server example can be compared with that given in [10] to illustrate

    how the network operating system philosophy has evolved at LLL over the years. In

    earlier designs, for example, capabilities were handled only by the resident monitor.

    In the NLTSS implementations, the resident monitor handles only the communication

    and hardware multiplexing described here. Resource access in NLTSS is still

    managed by capabilities, but this matter is handled as a protocol between the users

    and servers [26]. The integrity of the capability access protection mechanism is builton the simpler data protection and address control implemented in the distributed

    network message system of which NLTSS can be a component [10,14]

    9. Some implementation issues

    There are currently two versions of NLTSS running in an emulation mode, one on a

    CDC 7600 and one on a Cray-1. These fledgling implementations are being used to

    experiment with higher-level system protocols, to develop and debug libraries, etc.

    The systems will be made completely operational in his mode (except for device

    drivers) before being installed as the resident monitor on any machines.

    The NLTSS monitor and most of the servers are being written in a language named

    Model [18,19], a Pascal based language with data type extension that was developed

    at the Los Alamos Scientific Laboratory. Model generates an intermediate language,

    U-Code (similar to Pascal's P-Code). We expect this feature to help somewhat in

    moving NLTSS from machine to machine.

    http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#14http://www.webstart.com/jed/papers/Components/#14http://www.webstart.com/jed/papers/Components/#14http://www.webstart.com/jed/papers/Components/#18http://www.webstart.com/jed/papers/Components/#18http://www.webstart.com/jed/papers/Components/#18http://www.webstart.com/jed/papers/Components/#19http://www.webstart.com/jed/papers/Components/#19http://www.webstart.com/jed/papers/Components/#19http://www.webstart.com/jed/papers/Components/#19http://www.webstart.com/jed/papers/Components/#18http://www.webstart.com/jed/papers/Components/#14http://www.webstart.com/jed/papers/Components/#10http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#10
  • 7/31/2019 Local Networks

    18/23

    9.1 Backward Software Compatibility

    An important issue facing NLTSS is compatibility with existing software. We expect

    little difficulty in supporting the type of requests available from most of the library

    support routines at LLL. Reading and writing files, terminal IIO, etc., pose no

    difficulty. The areas that cause the most compatibility problems are those library

    routines that deal with very system specific features of the existing LTSS systems.

    For example, some existing software at LLL depends on a linear process chain

    structure supported by the LTSS system. Even though the NLTSS message system

    and capability-type process access protection are much more general, we do plan to

    implement a fairly elaborate service facility under NLTSS that mimics the linear

    LTSS process structure. It is hoped that the use of this type of software will gradually

    lessen as users become more familiar with the basic NLTSS Services. In any case,

    since this mimicry is not part of the NLTSS monitor, its use causes no more

    performance degradation than that caused by running a brief additional user program.

    9.3 Resource sharing with other systems

    Since NLTSS supplies all of its services through its message system, processes on

    machines that can communicate with the NLTSS machine can access NLTSS

    resources just as if they were local (except for performance). Also, since NLTSS

    allows its processes to communicate with other machines via the message system, any

    resources available on the network are available to NLTSS processes.

    Resource sharing is somewhat complicated by problems at both the very low and very

    high end of the communication protocol scale. At the low end, there is the problem ofmapping the NLTSS message exchange into whatever transport level protocol is

    available on the network (for example, what do you do with the X.25 qualifier bit?).

    This problem is somewhat eased at LLL by using an in-house protocol developed

    particularly to suit local network applications [13,25].

    At the high end of the protocol scale, there is the problem of service request-reply

    standards. The greatest difficulties involved in design of message standards for a pure

    message-passing service are those resulting from the domain restriction of the serving

    process(es). Access control and accounting are examples of mechanisms that require

    distributed coordination. Most third generation operating systems assume that theycontrol the entire computing facility. This assumption is incorrect in a network like

    Octopus and creates some serious problems. For example, resources serviced on one

    machine can't be accessed from another, accounts may "run out" on one machine and

    not on another, etc. Discussion of the distributed mechanisms that NLTSS utilizes for

    services that require distributed control is beyond the scope of this paper. Some of

    these mechanisms are described in [26]. Additional details of the NLTSS message

    standards will be described in later publications.

    http://www.webstart.com/jed/papers/Components/#13http://www.webstart.com/jed/papers/Components/#13http://www.webstart.com/jed/papers/Components/#13http://www.webstart.com/jed/papers/Components/#25http://www.webstart.com/jed/papers/Components/#25http://www.webstart.com/jed/papers/Components/#25http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#26http://www.webstart.com/jed/papers/Components/#25http://www.webstart.com/jed/papers/Components/#13
  • 7/31/2019 Local Networks

    19/23

    10. Conclusions

    Implementation of a pure message-passing operating system that efficiently utilizes

    the hardware resources available to it is a considerable technical challenge. It is a

    challenge that must be met, however, if the current software difficulties involved in

    interconnecting operating systems to networks are to be overcome. These software

    interconnection issues are particularly pressing in a mature high performance local

    network like the LLL Octopus network. It is hoped that the NLTSS development

    effort will further the state of the art in software network interconnections by giving

    birth to a viable message-passing operating system in the demanding environment of

    the Octopus network.

    11. References

    1. [AkB74]

    E. Akkoyunlu, A. Bernstein, R. Schantt,"Interprocess Communication Facilities for Network Operating Systems,"Computer 7, 6, 1974.

    2. [Bal71]

    R. M. Balzer,

    "Ports - A method for Dynamic Interprocess communication and Job

    Control,"Proc. SJCC, Vol. 38,1971.

    3. [BaH77]

    F. Basket, J. H. Howard, J. T. Montague,

    "Task Communication in Demos",Proc. of the Sixth Symposium on Operating System Principles, Purdue

    University, 1977, pp. 2331.

    4. [ChF78]

    P.L. Chaum, R.S. Fabry,

    "Implementing Capability-Based-Protection Using Encryption",University of California, Berkeley, Electronics Research Laboratory,

    Memorandum UCB/ERL M78/46 July 17, 1978.

    5. [Don76]

    C. B. Christensen,

    "Hyperchannel Data Trunk Contention,"Proc. Second U. of Minnesota Conf. on Local Computer Networks (Univ. of

    Minnesota, Minneapolis, 1977).

    6. [Cro72]

    S.D. Crocker et al.,

    "Function Oriented Protocols for the ARPA Computer Network,"AFIPS-SJCC, Vol. 40, May 1972, pp. 271-279.

    7. [DaM77]

  • 7/31/2019 Local Networks

    20/23

    J. Davidson, N. Mimno, R. Thomas, D. Walden, W. Hathaway, and J. Postel,

    "The Arpanet Telnet Protocol: Its Purpose, Principles, Implementation

    and Impact on Host Operating System Design,"Proceedings of the Fifth Data Communications Symposium, Snowbird, Utah,

    September 1977, pp. 4-10 to 4-18.

    8. [DeV66]

    J. B. Dennis, and E. C. Van Horn,"Programmed Semantics for Multiprogrammed Computations,"Commun. ACM 9(3), 143 (March 1966).

    9. [Dij68]

    E. W. Dijkstra,

    "Cooperating Sequential Porcesses,"in Programming Languages, F. Genuys Editor (Academic Press, 1968), pp. 43-

    112.

    10. [Don76]

    J. E. Donnelley,

    "A Distributed Capability Computing System,"Proceedings of the Third International Conference on Computer

    Communication, August, 1976.

    11. [DoY78]

    J. E. Donnelley and J. Yeh,

    "Interaction Between Protocol Levels in a Prioritized CSMA Broadcast

    Network,"Proc. Third Berkely Workshop on Distributed Data Management and Computer

    Networks, Berkeley, Calif., 1978, pp. 123-143. Also in 3 (1979) pp. 9-23.

    12. [Fle73]

    J. G. Fletcher,

    "The Octopus Computer Network,"Datamation 19(4), April, 1973, pp. 58-63.

    13. [FlW78]

    J. G. Fletcher, and R. W. Watson,

    "Mechanisms for a Reliable Timer-Based Protocol,"Computer Networks 2, 271 (Sept./Oct. 1978). Also in Proc. Computer Network

    Protocols Symposium, Liege, Belgium (February 1978), pp. C5-1/C5-17.

    14. [FlW80]

    J. G. Fletcher, and R. W. Watson,"Service Support in a Network Operating System,"in VLSI: New Architectural Horizons (Digest of Papers, COMPCON Spring

    80, 20th IEEE Computer Society International Conference, San Francisco,

    Calif., February 25-28, 1980), IEEE Catalog No. 80CH1491-0 C (IEEE, 1980),

    pp. 415-424.

    15. [Han73]

    http://www.nersc.gov/~jed/papers/DCCS/http://www.nersc.gov/~jed/papers/DCCS/http://www.nersc.gov/~jed/papers/DCCS/
  • 7/31/2019 Local Networks

    21/23

    P. Brinch Hansen,

    Operating System Principles,Prentice-Hall, Englewood Cliffs, N.J., 1973.

    16. [Lan75]

    C. R. Landau"The RATS Operating System,"

    Lawrence Livermore Laboratory, Report UCRL-77378 (1975).17. [MeB76]

    R. M. Metcalfe and D. R. Boggs,

    "Ethernet: Distributed Packet Switching for Local Computer Networks,"Comm. of the ACM 19(7), 395-404 (1976).

    18. [MoJ76]

    J. Morris and R. Johnson,

    "Abstract Data Types in the Model Programming Language,"Proc. Sigplan/Sigmod Conference on Data: Abstraction, Definition, and

    Structure, Salt Lake City, 1976, pp. 36-46.

    19. [Mor79]J. Morris,

    "Data Abstraction, A Static Implementation Strategy,"Proc. Sigplan Symposium on Compiler Construction, Denver, 1979.

    20. [Nee79]

    R. M. Needham,

    "Adding Capabilities Access to Conventional File Services,"ACM Operating Systems Review, Vol. 13, No. 1, January 1979, pp. 34.

    21. [New77]

    P. Newmann, et. al.,

    "A Provably Secure Operating System: the System, Its Applications, and

    Proofs",Stanford Research Institute, Menlo Park, Calif. (January, 1977).

    22. [Req76]

    J. E. Requa,

    "In-House Vs. Vendor-Supplied Software: A Case Study at Lawrence

    Livermore Laboratory,"Lawrence Livermore Laboratory report UCRL-74217.

    23. [Tho73]

    R. H. Thomas,

    "A Resource Sharing Executive for the Arpanet,"AFIPS Conference Proceedings, Vol. 42, 1973, SJCC, pp.155-163.

    24. [Wal72]

    D. Walden,

    "A System for Interprocess Communication in a Resource Sharing

    Network,"CACM, Vol. 15, No. 4 (April) 1972, pp. 221-430.

    25. [Wat82]

    http://www.webstart.com/jed/papers/RATS/RATS.pdfhttp://www.webstart.com/jed/papers/RATS/RATS.pdfhttp://www.webstart.com/jed/papers/RATS/RATS.pdf
  • 7/31/2019 Local Networks

    22/23

    R. W. Watson,

    "Delta-t Protocol Specification,"In preparation.

    26. [WaF79]

    R. W. Watson, J. G. Fletcher,

    "An Architecture for support of Network Operating System Services,"

    in Proc. Third USA-Japan Computer Conference, San. Francisco, Calif,(October 1978), pp, 12-21.

    27. [Wat78]

    R. W. Watson,

    "The LLL Octopus Network: Some Lessons and Future Directions,"Proceedings Third USA-Japan Computer Conference, San Fransisco, October

    1978.

    28. [Wul74]

    W. Wulf, et. al.,

    "Hydra: Kernel of a Multiproprocessor Operating System,"

    Communications of the ACM, Vol. 17, Number 6, June 1974.

    DISCLAIMERThis work has been performed under the auspices of the U.S. Department of Energy

    by the Lawrence Livermore Laboratory under contract number W-7405-ENG-48.

    About the author

    James E. (Jed) Donnelley received bachelors degrees in Physics

    and Mathematics (1970) and a masters degree in Mathematics

    from the Davis campus of the University of California. Since1972 he has been a computer scientist at the Lawrence

    Livermore Laboratory (LLL). Jed was technical liaison for LLL's

    ARPA network node from 1973 to 1978 and has participated in

    research projects at LLL on operating system security,

    distributed data bases, local networks, and high performance

    computer architectures. Since 1978 he has been primarily

    working on design and implementation of a network operating system. His principal

    research interests are in distributed computation, cellular data flow computer

    architectures, and brain modeling. Jed is a member of the ACM and the IEEE

    Computer Society.

    Acknowledgements

    The author wishes to acknowledge the assistance of his colleagues on the NLTSS

    design and implementation teams: Pete DuBois, Jim Minton, Chuck Athey, Bob

    Cralle and Dick Watson. Particular thanks go to John Fletcher, who carried the day in

    some early message system debates, and to Dick Watson, whose continued support in

  • 7/31/2019 Local Networks

    23/23

    the area of network protocols has had a profound impact on NLTSS. This paper is a

    revised version of a paper originally presented at the 4th Conference on Local

    Networks, Minneapolis, Minnesota, 22-23 October, 1979. The original paper was

    published in the proceedings of that conference copyright 1979 IEEE. The permission

    of the IEEE to utilize the original material is gratefully acknowledged.

    Contact theauthorfor comments about this page.

    http://www.webstart.com/jed/http://www.webstart.com/jed/http://www.webstart.com/jed/http://www.webstart.com/jed/