Search

The Dod's efforts in the late sixties and seventies to develop a robust computer communications network capability has evolved into today's Internet. Amid all the discussion of the utility of the Internet for business and government there seems to be growing consensus on only one issue - security is a problem. The ARPANET, from which the Internet has grown, was built to survive large scale war in a physical domain. Today's level of unauthorized and increasingly malicious activity occurring within corporate and worldwide internets threatens the value of internetworking.

This was a joint Rome Laboratory/ARPA advanced development effort that: (1) provided wide area high speed networking services for the New York State (NYS) Arpanet; (2) created the National Networking Testbed (NNET); and (3) developed Simple Network Management Protocol (SNMP) software tools. Under the first task, existing NYS Arpanet users were provided Transmission Control Protocol/Internet Protocol (TCP/IP) network service and support, access to the Defense Research Internet (DRI) with connectivity to the Internet, and upgraded service from 56 kbps to 1.544 mbps. The second task involved the installation and operation of the NNT, a nationwide, high-speed computer data network dedicated to ARPA's use to support domestic military and NASA sites, with access provided to the U.S. Dept. of Energy. The NNT provided a non-production network environment to field test a variety of network infrastructure devices and management control software tools. The third task involved the development of network management software technology to operate and maintain reliable end-to-end NNT connectivity. In addition to SNMP software tools, some software development work involved applications related to the International Standards Organization Development Environment (ISODE) and X.5OO Directory areas.

The report discusses fabrication of high technology electronics equipment, particularly digitally based systems, by specifying, designing and fabricating equipments on a fully automated basis. A hypothetical universal machine is proposed, operating under computer netted control, combining developments in the automated design, numerical control, and integrated circuit packaging fields. The intended results include computer-engraved PC boards, computer modified equipment, automatic testing, engineering design change drawings, computer repair and maintenance, and computer-made, fully assembled printed circuits at remote locations.

The report discusses technical and economic feasibility of widespread computer-netting technology to aid DOD procurement effectiveness, and describes procurement automation system development, the software and hardware required, and provides a hardware configuration. Next steps are logically detailed in a procurement automation system. Cost-benefit analysis and a survey of procurement automation systems presently in use is provided. It is indicated that savings in excess of $1 billion per year might be achievable in the future.

This report represents effort expended in attempting to meet the needs of the ARPA-IPTO Image Understanding community in providing the availability of a digital image data base. The data base will never be complete as it is the intention of the USC-IMAGE Processing Institute to update and maintain the base as long as the sponsor and scientific community indicates a need for same. The picture files are individually or collectively accessible either over the ARPANET or via the U.S. mails.

The principal objective of this effort was to establish a functional copy of the SRI Image Understanding Testbed system of hardware and software at the U.S. Army Engineer Topographic Laboratories (ETL) Research Institute at Fort Belvoir, Virginia. Representative tasks included advising on the preparation of the ETL site for the Testbed system installation, purchasing the required hardware for installation at ETL, and arranging for availability of Testbed software systems. Other major tasks included supplementary hardware acquisition, installing Testbed software systems, and developing support software to enhance the overall capabilities of the system. We also assisted in establishing the ETL site as a node on the DDN ARPANET/MILNET network. Final tasks included installation of Lisp Machine software and associated consultation, as well as other general assistance and troubleshooting. The main beneficial results of this effort were the establishment at ETL of a state of the art research facility and the transfer to ETL of a large body of research technology carried out by SRI, as well as by other contributors to the DARPA Image Understanding research program. This project has provided essential elements of the foundation required to support the mission of the newly formed ETL Center for Artificial Intelligence. Additional keywords: image processing; technology transfer.

The uptime of the NORSAR online detection processor system has averaged 91.9%, which represents an improvement of 3% compared to the previous period. Almost half of the downtime was due to problems in connection with the termination of the NOrSAR ARPANET circuit. The SPS has been working well and has caused less than 1% downtime. A total of 1681 events were reported in this period, giving a daily average of 9.2 events. The number of reported events per month varies from 210 in February to 363 in December. There have been no major breakdowns on the communications lines, but some lines have had periods with bad performance, especially the 02C line. The new DP system to be implemented on IBM 4331/MODCOMP is now, except for some EOC functions, ready. The communication problem between IBM 4331 and Modcomp has been solved, and test runs have been done with no errors. Some improvements in programs and some more testing still needs to be done before the new DP is ready to replace the current system. The research activity is briefly described with a summary of seven technical reports/papers prepared.

This report covers work performed during the first year of the extension of the ARPANET Routing Algorithm Improvements Contract. Network buffer management issues are discussed and a new buffer management scheme for the ARPANET is designed. Logical addressing is discussed, and a design is given for a logical addressing scheme suitable for ARPANET or DIN II. The applicability of ARPANET Routing to DIN II is evaluated. The possibility of extending ARPANET's routing algorithm to provide multiple routes between a given pair of nodes is discussed, and a preliminary design is proposed, which, however, still contains a number of unsolved problems. A set of metrics for evaluating congestion control algorithms is proposed, and AUTODIN II congestion control scheme is evaluated. A new congestion control scheme, suitable for networks containing ARPANET routing, is proposed. BBN's network simulator is described, and its command language is specified. Various simulation design decisions are discussed. The statistical properties of simulation data are discussed and various techniques for analyzing and interpreting simulation data are proposed.

This report describes a tutorial for introducing novice users to a collection of computer programs which support interpersonal communication. The tutorial is designed to reduce the apparent complexity of the multiple command languages involved. The instructional strategy used provides a model for other training situations in which a collection of computer programs must be taught simultaneously. The tutorial first presents concepts which facilitate understanding of the various command languages. This is followed by a series of exercises leading up to the new user's performance of a sample task involving a limited subset of all commands. The tutor monitors the new user's progress and offers advice. This approach puts the new user in an active, problem-solving role from the beginning. The collection of programs described in this tutorial is called the Tenex Electronic Notebook-Conference (TEN-C) System. Included in this 'system' are the XED text editor, the MSG message handling program, the ZCONFER conferencing program (a modification of FORUM 5). These programs operate under the TENEX executive on the PDP-10 computers at the USC/Information Sciences Institute.

The National Software Works (NSW) is a facility, resident on the Arpanet, intended to support the construction, use, maintenance, modification, verification, and storage of programs and bodies of information on which these programs operate. It is principally aimed at the construction of programs and at providing software tools which can be used in the construction activity. NSW is intended to facilitate both the administrative and technical aspects of these activities. Thus, it provides mechanisms for the exercise of fiscal and access control in the operation of a programming project, and also access and storage conveniences to programmers for the management of their files. The salient factor in the conception of NSW is the expectation that the hardware, software, and human resources needed for the execution of a task may be geographically and administratively dispersed, although connected through the network. Tools whose use is to be coordinated may be resident at different computer installations, possibly under the control of different organizations.

Interoperability can be viewed as a layered process in much the same way as protocols are often characterized. Each layer has particular concerns and different possible techniques for dealing with these problems. In this paper the various issues germane to each layer are identified and discussed in light of current military equipment. The issue of gateway interoperability is dealt with separately from both a theoretical standpoint and by example. Keywords: ARPANET; Packet radios; Radio communications; PRNET(Packet Radio Network); Cryptography.

The ARPANET was originally conceived to support high-data-rate distant communication between large mainframe computers. Because of the hardware limitations of the Honeywell 316/516 processor, which was selected as the original ARPANET interface message processor (IMP), most ARPANET IMPs are resticted to supporting a maximum of four host attachments (computers or gateways to other networks). As the ARPANET community expanded many sites experienced the need for more than four host ports. The response was to install additional IMPS. With the H316/516 no longer available and the C/30 IMP, being developed by the BBN Computer Company not expected to arrive until 1981. no more ARPANET community, hosts attached to IMPs have increasingly tended toward less powerful types, such as the DEC PDP-11 minicomputer. Many of these microcomputer hosts require only moderate data-rate network communication or occasional access. Newer node-switching equipment utilizes the Bolt Beranek and Newman Pluribus, which eliminates hardware constraints upon the number of host attachments. Nevertheless, the large majority of deployed IMPs are still of the older Honeywell type. The desire to attach a large number of minicomputers or microcomputers to the ARPANET induced DARPA to assign SRI the task of developing the port expander concept into a working product. This manual describes the functions, installations, and operation of the port expander.

For several years ARPANET has been subjected to occasional disturbances (referred to as network glitches or network disturbances). Frequency of these disturbances increased from once every 2 or 3 days to 3 or 4 a day in April 1977. This increase was traced to a change in the IMP software governing the satellite line between SDAC and NORSAR reducing the number of packets per flight. When the software was changed back to allow 16 packets per flight the number of disturbances decreased dramatically. However network disturbances are not the result of this one isolated bug. Other causes include: faulty IMP hardware, software bugs, circuit difficulties, traffic overloads, etc. The real problem is not any particular irritant but the vulnerability of the ARPANET to congestion caused by such irritants.

Computer Corporation of America continued to provide Datacomputer and SIP service to the ARPAnet community throughout the final quarter of 1979. The Datacomputer is a network-oriented database management utility which is used in diverse general networking applications. The Datacomputer's software system is designed to allow convenient and timely access to large on-line databases and to promote data sharing by multiple remote users communicating over a network. The seismic application was heretofore the largest user of the Datacomputer. This was true not only in terms of the amount of data stored, but also in terms of its complexity and the required bandwidth of transfer. CCA developed and operated a dedicated Seismic Input Processor (SIP) to field the real-time input stream. Both the real-time data stream storage via the SIP and the SRO files storage from the Albuquerque Seismological Laboratory were shut down during this reporting period.

This report describes progress during the first six months of a contract to make several improvements to ARPANET routing. Some principal conclusions are: Several problems have been discovered in the present congestion control, line up/down procedures, and loop suppression techniques through the use of a new real-time monitoring capability. Solutions to most of these problems have been developed; operational experience with these changes is presented. A new set of line up/down procedures with much better performance was developed and analyzed. Extensive measurements of network delay were carried out; delays fluctuate rapidly over a large range, making it difficult to devise effective estimation techniques. The present routing algorithm is itself a major contributor to network delay due to the computations and update messages it requires. A set of improvements was designed for the present routing algorithm to make it more efficient and effective. However, a new algorithm, based on performing the entire shortest path calculation at each node, incrementally for each network change, appears to be a better choice for installation in work change, appears to be a better choice for installation in the ARPANET.

The purpose of this IDA Paper is to analyze the results of the Federal Government's transition to the ISO OSI communication protocols as mandated by the Government Open System Interconnection Profile (GOSIP). This document analyzes the interoperability issues that will affect the communications between C2Is during the transition from DoD to ISO protocols. Information for the analysis was gathered from the open (unclassified) literature, correspondence with protocol implementors on the ARPANET, attendance at the NBS OSI Implementors workshop, and the authors' implementation experience with communications protocols.

This memorandum report is based on analyses of working papers, contact reports, ARPANET messages, and other records maintained by IDA as required to perform the assessment of the validation process as required by the Ada Joint Program Office (AJPO). The time frame of the assessment was from November 1984 through December 1985. The role of IDA is to adjudicate procedural and technical issues, interpret existing policies, and to retain an objective viewpoint concerning the issues and alternatives for their resolution. Recommendations are made which can improve the validation process.

Welcome to the Defense Data Network, or the DDN as it is more commonly called. The DDN is a powerful operational military network. It might be thought of as an umbrella network composed of several large segments or subnetworks. The unclassified portion of the DDN is a subnetwork known as the MILNET. It is the MILNET on which this document will focus, and on which you are invited to try your hand. The DDN New User Guide describes the policies, concepts, and conventions of the DDN, with major emphasis on the MILNET. The guide contains an overview and a tutorial introduction to the DDN, along with a description of some of its interesting network programs and services. It is not intended to be a highly technical document, and does not cover the process of attaching hardware, terminals, or other equipment to the network. This information is provided in other documents. As you will subsequently learn, the MILNET recently split off from the unclassified DoD experimental research and development network known as the ARPANET; therefore, most of what is described in this document applies to the ARPANET as well as to the MILNET, although, as stated above, the emphasis of this guide is on MILNET. A wealth of services and resources is available on the DDN. Many of your colleagues already work on the network, and you will be able to communicate easily and quickly with them, even though they may be hundreds of miles away. It is also easy to participate in discussions about topics of interest and to use network programs and tools to enhance your own capabilities.

This report describes modifications made to the TOPS-20 operating system in order to enable ARPA research programs previously supported by the TENEX operating system to be supported by TOPS-20. In addition, it describes modifications to the ARPANET network control programs (NCPs) for both TENEX and TOPS-20 to enable those hosts to use the 'new style' extended host/IMP leaders. The changes to TOPS-20 have been delivered to DEC and merged with the standard DEC version of the system, and will be maintained by DEC along with the rest of the system.

This document is the Final Technical Report under DARPA contract MDA903-85-C-0130, entitled Continued Development of Internet Protocols under the IBM OS/MVS Operating System. Under this contract, the contractor continued the development and distribution of network software for the DoD Internet protocols, to execute on an IBM 370 mainframe under the OS/MVS operating system. The central component of this network software is a subsystem called the ARPANET control Program or ACP. This report covers the major areas of development of the ACP under this contract: revision of the Local Network Interface, the introduction of name resolver code, and the use of the C language within the ACP. Finally, it summarizes the most important features of the latest ACP distribution, Release 1.6, and lists areas for future ACP development.

This report covers the work performed during the second year of the extension to the ARPANET Routing Algorithm Improvements Contract. The ARPANET simulator developed during the first year of the extension is used to investigate the performance and behavior of a number of routing algorithms, including the current ARPANET SPF algorithm. Results from the simulator are compared to measurements of SPF running on a small test network, measurements of the line protocol on the operational ARPANET, and the predictions of a stability model developed during the original contract. The simulation was run on a 14- node network using fixed single-path, fixed multi-path, and SPF (adaptive) routing. The performance of each routing method as a function of network load is compared to the predictions of a queueing model. As part of the design of an Internet, this report discusses design issues in the implementation of gateways, including the host interface to the Internet, interoperability of autonomous gateway systems, congestion control, and logical addressing.

This report represents the current state of a bibliography on the subject of protection in computer operating systems. 'Current state' means that the bibliography is incomplete; it is a byproduct of a research project in the field of protection, recently completed. The bibliography is being published in the belief that it may be useful as is, and that it might serve as the basis of a continuing effort to collect, annotate and index the more significant documents (reports, papers, articles, books, etc.) in the field. Ideally (especially in these days of computerized information bases and communication networks) workers in a research field will collaborate in developing and sharing their bibliographies--not only with simple annotations like this one but with more extensive comments and review. Perhaps this document can be a contribution in that direction and will stimulate owners of other 'working' bibliographies to publish theirs. As noted below, this bibliography is online and may be accessed via the ARPANET, (Defense Advanced Research Projects Agency network of interconnected scientific computers).

This report describes an ARPANET remote job entry facility developed by UCLA-CCN as part of the National Software Works (NSW) project, making the CCN 360/91 a batch tool-bearing host for NSW. The implementation of this facility is based on a server process for the interim NSW protocol IP, which was originally designed for Tenex-to-B4700 batch job control. The main component of the IP server at CCN, the Message Processor or MP, is largely written in PL/1 and runs as a pseudo-user under TSO.

The ARPANET was originally conceived to support high-data-rate distant communication between large mainframe computers. Because of the hardware limitations of the Honeywell 316/516 processor, which was selected as the original ARPANET interface processor (IMP), most ARPANET IMPs are restricted to supporting a maximum of four host attachments (computers or gateways to other networks). As the ARPANET community expanded many sites experienced the need for more than four host ports. The response was to install additional IMPs. With the H316/516 no longer available and the C/30 IMP, being developed by the BBN computer Company not expected to arrive until 1981, no more ARPANET nodes/host ports were available. Simultaneously with this growth in the ARPANET community, hosts attached to IMPs have increasingly tended toward less powerful types, such as the DEC PDP-11 minicomputer. Many of these minicomputer hosts require only moderate data-rate network communication or occasional access. The desire to attach a large number of minicomputers or microcomputers to the ARPANET induced DARPA to assign SRI the task of developing the port expander concept into a working product. This manual describes the functions, installation, and operation of the port expander.

The goals of the National Software Works Project were to demonstrate the feasibility and practicality of providing users uniform access to services on a diverse set of computers and operating systems. We have, indeed, succeeded in showing that such access is possible by building, running, and maintaining a system called NSW, which ran on the Arpanet in one form or another between 1976 and 1983. In its final version, NSW connected an IBM 370, two TOPS-20s, a MULTICS and several UNIXes. The need to interact with different computer systems is ever increasing in both military and commercial sectors. The lessons learned from the construction of NSW can help those building the next generation of these systems. This report is about those lessons we learned.

This is the final technical report for services relative to the use of the ARPANET. Major areas of responsibility were: (1) The development and implementation of an ARPANET training program for the DARPA staff, selected agents and contractors; (2) The development of a comprehensive ARPANET User's Guide for the DARPA staff and DARPA sponsored ARPANET users; (3) The development and implementation of procedures to monitor ARPANET usage by the DARPA testbed- user community, to include the addition of new users; deletion of departing users; and a quarterly review of DARPA sponsored users to ensure that DARPA sponsorship would still be desirable; (4) The quarterly preparation of a submission to the Network Information Center (NIC) relating to the DARPA, users of ARPANET hosts; and (5) The provision and responsive ARPANET user support services for the DARPA staff, its agents, and selected contractors.

Some specific topics addressed in the present Quarterly Technical Report include: (1) Consideration of system modules necessary for a large set of procurement related functions; (2) Description of an early list of evolutionary functions felt to be most applicable; (3) Determination of the file sizes for the records considered; (4) Determination of the state of the art of inputting and storing the large text database implied in automating procurement; (5) Consideration of secrecy protection means that are more effectively built into the initial system configuration design rather than as an afterthought; (6) Survey of present procurement information automation efforts, and consideration of evolutionary growth from this presently highly advanced basis; (7) Analysis of the cost of sending one-way text messages via a number of alternatives ranging from postal mail to various forms of electronic transmittal; (8) Work in progress in evaluating present day legal interpretation of governmental secrecy provisions and private proprietary information protection legislation of import to procurement automation.

The North American Network for collecting and storing seismic data uses the ARPANET for communication between the Communications and Control Processor (CCP), the Detection Processor (DP), and the Seismic Input Processor (SIP). This document describes the Host protocols and message formats used for communication among these processors.

New research results on the following major questions are reported: Growth and cost performance tradeoffs for the ARPANET, traffic sensitivity analyses with measured traffic and with possible ILLIAC IV traffic effects and ARPANET capacity expansion. Initial cost, delay, throughput and reliability analyses for a 1000 node packet switched network based on ARPANET technology. Development of efficient algorithms for location and line layout for local and regional access to Terminal Interface Processors. The development of an interactive data handling system based on an IMLAC display and distributed ARPANET computation. Study of flow control, routing and time delay and system organization for broadcast packet systems.

The Terminal Access Controller (TAC) is a terminal controller for the ARPANET. The present document describes what the TAC does, what it does not do, and what its relationship is to the network.

The ARPANET is an unclassified, packet-switched data network originally built by the Defense Advanced Research Projects Agency (DARPA) and used for Department of Defense computer science and networking research. It is now one of the subnetworks of the Defense Data Network (DDN) and, as such, is managed by the Defense Data Network Program Management Office (DDN PMO). Policy for the ARPANET is established by DARPA and they also decide who may become subscribers. Subscribers are required to follow certain technical and administrative procedures to connect host computers or other equipment to the DDN. This document describes these procedures as they apply to the ARPANET, provides background and technical information on the ARPANET, and suggests sources of further information on protocol implementations and interface equipment.

Research activities covered in this document include the interconnection of hosts and networks, the development of a system SWITCH for virtual network connection, and our connction to the UK Post Office Experimental Packet Switched Service. Two topics covered in particular detail are the packet satellite project and the Transmission Control Program (TCP) experiments. These have particular relevance to other ARPA supported projects and so are treated in space depth. Finally, our measurement and facsimile activities are described, and UK use of ARPANET through the ULC TIP is evaluated. A list of conclusions that may be drawn from our research activities during 1976 is given at the end of the report. (Author)

The report presents a recommendation of a system design for a worldwide seismic data network. Particular attention has been paid to recent or imminent developments in the areas of digital communication, processing, and storage. Both sensor stations currently expected to be operational about 1975 and possible future expansion or modification of the network are considered. The major conclusions of the system design are (1) seismic event detection should be done at the array site in the majority of cases, (2) the ARPANET is generally a suitable and cost effective communication facility for seismic data transmission, (3) a communications control center should be established at SDAC in order to coordinate and monitor the seismic data network operation centrally, (4) network event processing can evolve from the existing large array event processing system at SDAC, (5) long period event processing should be done off- line using ARPANET computing resources with special consideration given to eventual use of the ILLIAC IV array processor, and (6) the Datacomputer service can provide an appropriate data management system for the seismic data network.

The report describes progress made in the development of network- oriented system for teleconferencing. The program is called FORUM. Most of the preliminary software tests have now been completed. The current version (Release 4) follows the specifications given in the previous semiannual report, of which the general systems features of the Programmer's, Chairman's, and Respondent's Guides are still applicable. The present document addresses itself more specifically to a review of practical experience in the use of FORUM both at the Institute and within the ARPANET community. It is divided into three sections describing: (1) the current program status; (2) user experience to date; and (3) implementation plans beyond Release 4. An analysis of user reaction at USC- ISE is described in the second section of the report, with background data as a special appendix to the report.

The document describes research efforts to determine: (1) the most economical configurations to meet growth requirements in the ARPANET, (2) properties of packet switched computer communication networks, (3) analysis and design techniques for large scale networks, (4) cost/throughput/reliability characteristics of large packet switched networks for potential application to Defense Department computer communication requirements. The heart of the research program has been the dual attack on basic network theoretical problems and the development of computational techniques for handling large network structures. Results on properties of the ARPANET, properties of large networks, and new computational techniques are described for subjects as traffic sensitivity, peak bandwidth, reliability, cost and throughput and routing.