Showing papers on "The Internet published in 1983"

Internet delay experiments

Abstract: This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP retransmission timeout calculation. This memo is both a status report on the Internet and advice to TCP implementers.

The DARPA Internet: Interconnecting Heterogeneous Computer Networks with Gateways

Abstract: Armies of spiders could not weave a wider web networks are everywhere. Networks span continents and oceans; tie office buildings in iiles of wire, fiber, and other nerse media; reach into land, air, and space vehicles; and confront microcomputers as well as large maint'rame computers. Someii networks are incredibly fast and others are pragmatically slow; some work better than others, and some do not work well at all. However, despite the present abundance, new networks are still being developed coinstantly to challeinge the competitioni. If' we had a way to initerconnect various networks, many problems could be solved. For example, a user may want to comiimuilicate with a site that is not on the same public network as the host computer. Perhaps there are sev eral hosts but no single network to which they will all coinnect. In some cases, the cost of coninection will be a factor; coninecting 100 hosts on a coaxial local net is more cost-effective than putting them all on a public net, but running 1000 miles of coaxial cable to the 101st host is ab.surd. In other cases, pragmatics or the basic laws of nature apply; for example, radio-based networks are about the only choice if mobility is needed. A network technology that supports a maximum of 256 hosts becomies a problenm when you acquire the 257th. G,iven that all hosts caninot be put on a single network, the next best option is to interconniect networks.

DCN local-network protocols

Abstract: This RFC provides a description of the DCN protocols for maintaining connectivity, routing, and clock information in a local network These procedures may be of interest to the designers and implementers of other local networks

TCP maximum segment size and related topics

Abstract: This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers".

Resource Location Protocol

Abstract: This RFC specifies a draft standard for the ARPA Internet community. It describes a resource location protocol for use in the ARPA Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet.

Character Generator Protocol

Abstract: This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Character Generator Protocol are expected to adopt and implement this standard. The Character Generator service simply sends data without regard to the input.

Telnet Option Specifications

Abstract: This memo specifies the general form for Telnet options and the directions for their specification. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651, NIC 18640.

CSNET protocol software: the IP-to-X.25 interface

Abstract: CSNET is built on the Department of Defense network (ARPANET), public packet-switched physical networks (Telenet), and a telephone-based relay network (Phonenet). Some CSNET sites have direct connections to ARPANET, some have direct connections to Telenet, and some have connections only to telephone-based relay machines. The chief objective of CSNET is to provide a network interconnection for all groups engaged in Computer Science Research.CSNET has adopted TCP/IP as its standard transport level protocols. The Transmission Control Protocol (TCP) [POST81] is an end-to-end protocol. It establishes communications between two processes that are running on different machines, detects and corrects errors, controls data flow, and provides reliable communications. Application programs call TCP to transfer data across the network. TCP, in turn, uses the Internet Protocol (IP) [POST81] to send data to the appropriate network. CSNET communications such as file transfer, remote login, and process-to-process communication over the network assume that a TCP interface is available at CSNET sites.Since ARPANET sites are required to support the TCP/IP protocols, CSNET sites connected directly to the ARPANET automatically have access to TCP/IP. Phonenet relays connect directly to the ARPANET; they too have access to TCP to relay mail onto the ARPANET. Telenet does not use the TCP/IP protocols. Consequently, CSNET sites that are connected only to Telenet need additional software before they can communicate on CSNET. That software is described in this paper -- it provides an interface between the public packet - switched protocol X.25 [CCITT78] and TCP/IP. Although the design outlined here is applicable to any vendor's system, our implemention is for a Digital Equipment Corporation VAX running the Western Electric UNIX [UNIX78] operating system as modified by the University of California at Berkeley.This report focuses on the technical issues involved in building software to interface TCP/IP and X.25. The tariff structure for public networks is discussed only to the extent that it influences our design. Other issues such as access control, and protocol selection are beyond the scope of this report.

A distributed approach to the interconnection of heterogeneous computer networks

Abstract: This paper describes a distributed architecture for the flexible interconnection of heterogeneous networks with a number of mini- and micro computers, in a research environment. The interconnected networks include the DARPA Internet, which uses the DoD protocols, and the X25-based networks PSS and SERCNET. The approach described here distributes the network access into a set of microcomputers acting as network frontends ("network access machines"), with a local area network (Cambridge Ring) as a common bus. Communication between the hosts and the network access machines uses an interprocessor communication mechanism with a standard transport-level virtualcall interface, which is described. This arrangement provides local hosts with flexible access to any of the networks, and supports a relay system which allows users on one network to access hosts and facilities on any of the other networks.

Domain names plan and schedule

Abstract: This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA Internet community. The introduction of domain style names will impact all hosts on the DDN/ARPA Internet.

Quote of the Day Protocol

Abstract: This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Quote of the Day Protocol are expected to adopt and implement this standard. The Quote of the Day service simply sends a short message without regard to the input.

Experience with Grapevine (Summary): the growth of a distributed system

Abstract: Grapevine is a distributed, replicated system that provides message delivery, naming, authentication, resource location, and access control services in an internet of computers. The system, described in a previous paper [1], was designed and implemented several years ago. We now have had operational experience with the system under substantial load. This experience has proved the original design sound in most aspects, but there also have been some surprises. In this paper we report what we have learned from using Grapevine. Our experience may offer some help to designers of new systems.Grapevine is implemented as a program that is run on a set of dedicated server computers. Client programs o f Grapevine run on various workstation and server computers attached to an internet. The services provided by Grapevine are divided into the message service and the registration service.The message service accepts messages prepared by clients for delivery to individual recipients and distribution lists. Messages are buffered in inboxes on message servers until the recipient requests them. Any message server can accept any message for delivery, thus providing a replicated submission service. A computer system mall user has inboxes on at least two message servers, thus replicating the delivery path for the user.

Telnet end of record option

Abstract: This RFC specifies a standard for the ARPA Internet community. It specifies a method for marking the end of records in data transmitted on Telnet connections.

Telnet Echo Option

Abstract: This Telnet Option enables remote echoing by the other Telnet module. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15390.

Telnet Suppress Go Ahead Option

Abstract: This Telnet Option disables the exchange of go-ahead signals between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15392.

Summary of Smallberg surveys

Abstract: This is a summary of the surveys of Telnet, FTP and Mail (SMTP) servers conducted by David Smallberg in December 1982, January and February 1983 as reported in RFC 832-843, 845-846. This memo extracts the number of hosts that accepted the connection to their server for each of Telnet, FTP, and SMTP, and compares it to the total host in the Internet (not counting TACs or ECHOS).

Experiences with a Layered Approach to Local Area Network Design

Abstract: The Nestar Plan 4000 network was designed using the ISO Open Systems Interconnection model. The Xerox Network Systems Internet Transport Protocols (XNS) were chosen for the network and transport layers, a token-passing protocol (Arcnet) for the physical and datalink layers, and existing Nestar server software for the highest layers. The physical and datalink layers are supported by a VLSI chip and their implementation was straightforward. In spite of their detailed specification, implementing the network and transport layers presented some unanticipated challenges. This paper discusses details of our experience in implementing the network with emphasis on the problems encountered and how they were solved.

Telnet Binary Transmission

Abstract: This Telnet Option enables a binary data mode between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15389.

Telnet Timing Mark Option

Abstract: This Telnet Option provides a way to check the roundtrip path between two Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16238.

Proposed standard for message header munging

Abstract: This RFC specifies a draft standard for the ARPA Internet community. It describes the rules to be used when transforming mail from the conventions of one message system to those of another message system. In particular, the treatment of header fields, and recipient addresses is specified.

ARPANET 1822L Host Access Protocol

Abstract: This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other.

Telnet Status Option

Abstract: This Telnet Option provides a way to determine the other Telnet module's view of the status of options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651 (NIC 31154).

Telnet terminal type option

Abstract: This RFC specifies a standard for the ARPA Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol.

Development of the DoD protocol reference model

Abstract: The Department of Defense has embarked on a Protocol Standardization Program aimed at the development of high-level protocol standards for the DoD internetwork environment. A major piece of this standardization program involves the development of the "DoD Protocol Reference Model" [1], which will serve to describe a basic framework for future DoD protocol standardization activities. The DoD Reference Model is in many respects similar to the ISO Reference Model [2]; in other respects, there are major differences between the two models. This paper discusses the issues faced during the development of the current draft of the DoD Reference Model. There are four fundamental differences between the DoD and ISO Reference Models: (1) the meaning of "layer"; (2) the importance of internetworking; (3) the utility of connectionless services; and (4) the approach to management functions. It has been found that well-designed computer networks have their protocols organized hierarchically. By this we mean that one protocol interpreter provides a communications service to its users by adding value to the services provided by one or more other protocols; and "good engineering practice" dictates that at no point should one protocol be implicitly using its own services, i.e. the protocols form a hierarchy. Within the ISO Model, however, this requirement for protocol hierarchies is strengthened into a requirement that protocols fit into "layers". This is the origin of a major disagreement between the ISO and DoD Reference Models. Within the ISO Model, the concept of layer has become of paramount importance, overshadowing the more fundamental notion of protocol hierarchy. Good protocol engineering does not require that protocols fit into layers; it is only required that protocols be arranged hierarchically. This latter principle is the basis of the DoD Reference Model. The second fundamental difference between the ISO and DoD Models is the relative importance given to the problems of internetworking. This is most easily seen by considering that the DoD Reference Model has explicitly identified an "Internet Layer". Although many efforts based on the ISO work are now taking the Network Layer to include an Internet Sublayer, this seems to confuse rather than clarify the issue (since it raises questions as to the meaning of sublayers). It is also difficult to correctly present the DoD approach to internetting within the confines of the ISO Model due to the ISO Model's lack of emphasis on "connectionless" services. This is the third of the fundamental differences between the two models. The primary use of connectionless service within the DoD architecture is for internetting - IP [3] being the paradigm. However, connectionless services are of great utility in other contexts as well. For example, interactions with a Name Server may involve the use of a connectionless protocol within the Transport Layer. The final fundamental difference between the ISO and the DoD Models is the manner in which various management - related functions are treated. Here we refer to functions such as the naming of resources, the control of access to resources, and the accounting for resource and network usage. Many of these functions are most naturally handled via connectionless services, they typically involve entities which are only involved at the initiation or termination of a sequence of data transfers, and many communicants may be involved besides the "users". The DoD Model identifies such protocols as typical of " session" services. Such protocols are placed within the session layer by virtue of their use of " transport layer" services and their common features. Of course, there will be many protocols defined which sit at other locations within the protocol architecture which may play a role in the management of the network and of network resources. It is not implied that all such protocols are most appropriately defined as "session" protocols. These are the differences between the two developing Models which are currently identified. Both Models will continue to evolve, most likely in directions which differ in important respects.

Telnet Extended Options: List Option

Abstract: This Telnet Option provides a mechanism for extending the set of possible options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16239.