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