bluuebunny/crossref_metadata_2025_split huggingface dataset:
The current status of MAP
Authors: Foley J S , Weon-Yoon Y 
Published: October 2004

MAP is a standard computer networking discipline and a unified set of communications protocols which make it possible to implement a vendor independent network of computers. MAP provides a complete service to the user or application program. The major facilities, file transfer, process to process messaging, inter-machine messaging, and directory service are supported. Virtual terminal protocol support is planned for the near future.
MAP is a subset of the internationally agreed Open Systems Interconnection computer networking architecture, protocols and supporting standards. The MAP subset of OSI Protocols was originally selected by General Motors and has been agreed by a MAP Task Force comprised of nearly 100 user and vendor corporations. MAP specifications are also agreed by the NBS/OSI Implementor's Workshop, indicating that the MAP specifications are OSI compatible.
The MAP System and Protocols are described here in sufficient detail to permit the reader to gain a general understanding of MAP against a background of OSI fundamentals. The future growth trends for MAP conclude this paper.
Modeling a transport layer protocol using first-order logic
Authors: Lin H P 
Published: October 2004

We use a hybrid model based on the first-order logic to specify and verify a transport layer protocol. In this model we specify a protocol as a set of state machines. Time expressions are used to describe the temporal relations of transitions. Given the specification of a protocol, we verify its properties by logical deduction. Reasoning techniques such as decomposition and abstraction are used to reduce the verification complexity.
The transport protocol consists of an active process, a passive process, and two communication channels. Each of these components is specified by this model. An outline of verification of this protocol is given.
An architecture for a multimedia teleconferencing system
Authors: Aguilar L , Garcia-Luna-Aceves J J , Moran D , Craighill E , Brungardt R 
Published: October 2004

We present an object-oriented architecture for a computer-based, real-time, multimedia conferencing system. This architecture divides the system into five functional areas: a multimedia shared workspace, a user interface, conference management, communications, and an information base. The structure and operation of the first four areas are modeled with object-based concepts that address design requirements identified during the development of a proof-of-concept prototype, that preceded the architecture specification.
The shared workspace, the most important component, is thoroughly discussed; the other components support its realization. The modeling of workspace entities emphasizes their aggregation into composed entities and the homogeneous handling of several data media. The user interface manages uniformly the man-machine interaction for both local and remote user actions. Conference management deals with session establishment, participation, and control of multiple media floors. The communication functions replicate user actions over workspace objects in all hosts participating in a conference, matching traffic types with transmission services in the process.
A turnable protocol for symmetric surveillance in distributed systems
Authors: Walter B 
Published: October 2004

In distributed systems surveillance protocols are used for monitoring the status of remote sites. A remote site is regarded as being available as long as messages are received from this site, otherwise it is regarded as being unavailable. If a site becomes unavailable, this will be reported to other sites and recovery actions can be initiated. Using an example it will be shown that in certain cases it is necessary, that whenever some site S1 detects the unavailability of some other site S2, within a fixed amount of time S2 must also have detected an unavailability of S1. Unfortunately, this cannot be guaranteed by existing surveillance protocols. Another problem with existing protocols is, that remote sites are usually reported as being unavailable after being timed out only once, i.e. the loss of just one message might cause complete systems to back out.
Two versions of a protocol for so-called symmetric surveillance are presented. Both guarantee, that if S1 detects the unavailability of S2 at time t0, then S2 (provided that S2 has not crashed) will become aware of this fact at t1 such that [t1 - t0] < Δ. This property is of special interest for handling network partitionings. Additionally, one of the versions is tunable, i.e. it can be specified, how many timeouts may occur before a site is regarded as being unavailable.
Insights into the implementation and application of heterogeneous local area networks
Authors: Lidinsky William P. 
Published: October 2004

The ideal local area network is a mechanism which provides concurrent high speed error-free data paths over a limited geographical area and between any computational entities on the network. A computational entity may be a program running on any type of computer, any intelligent device, or any terminal. This means that such an ideal network must be able to support systems of cooperating processes within disjoint and dissimilar host environments.
Achieving such an ideal heterogeneous network (referred to as an “open” network with respect to the ISO Reference Model for Open Systems Interconnection) may be impossible in the limit. However, the ideal shows promise of being approachable. Recent work in local area networks, protocols, and multiprocessor operating systems looks promising for attacking the problem.
This paper first discusses data paths and the dilemma of heterogeneous data communications. Existing local area networks, their functionality, shortcomings, and relationship to networking standards are described. Commercial LANs are discussed and classified. Standards, high level protocols, and operating system concepts are discussed and related to networks. Finally some possible approaches to the implementation of hetergeneous networks are discussed.
A study of protocol analysis for packet switched network
Authors: Tsukamoto K. , Itoh T. , Nomura M. , Tanaka Y. 
Published: October 2004

Communication failures may occur because of residual hardware or software implementation flaws, operator errors, transmission noises and transient or permanent machine failures. For packet switched network operation, some means are necessary to detect the errors and to analyze the phenomena to identify the causes of the errors, since, generally, it is almost impossible to predict errors or to implement systems without errors or failures.
This paper describes general aspects of communication protocol analysis, protocol analysis technologies for CCITT X.25 and the protocol analyzer to be used in DDX packet switched network operation.
A versatile queueing model for data switching
Authors: Laue Richard V. 
Published: October 2004

In a data network, when messages arrive at a switch to be served (transmitted) on a line, it seems reasonable to assume that the arrival process can be described as a Poisson (random) process. However, when messages are divided into a number of packets of a maximum length, these packets arrive bunched together. This gives rise to what is referred to as “peaked” traffic. The degree of peakedness depends on 1) the interarrival time of packets associated with a particular message and 2) the distribution of the number of packets per message. In this paper we describe a queueing model which accounts for the non-Poissonian nature of the packet arrival process as a function of these two factors. Since packets are of a fixed maximum length, the model assumes that the packet service time is constant, as opposed to the mathematically more tractable but less realistic assumption of exponentially-distributed service time.
This queueing model is then used to describe the network delay as affected by:
1. Message switching versus packet switching,
2. A priority discipline in the queues,
3. Packet interarrival time per message, which is probably controlled by the line speed at the packet origination point, and
4. A network which carries only short inquiry-response traffic as opposed to a network which also carries longer low-priority printer traffic.
The general conclusions are that the peakedness in the arrival process caused by a short interarrival time of packets per message and the longer printer traffic would cause excessive delays in a network. If inquiry-response traffic with a short response-time requirement is also to be carried on the same network a priority discipline has considerable value. Message switching for such a combination of traffic should be avoided.
Bidirectional token flow system
Authors: Ulug M. E. , White G. M. , Adams W. J. 
Published: October 2004

Over the last few years there has been an avalanche of technical literature on techniques for allowing nodes to access and share one of the most valuable resources of a computer communication network, i.e., the bandwidth of the communication media.
1
This report describes the design of a new type of Local Area Computer Network called BID that uses a bidirectional token flow as a form of token passing.
2
The design of BID not only allows it to process messages having various properties but also makes it possible to operate simultaneously in a packet and circuit-switching mode. This latter mode, using minipackets, enables BID to be used for those applications having real-time response requirements.

In describing BID this report defines the basic concepts of the implicit token, token carrier, token generator, and token wait time. It also describes a new preemption technique which reduces the walk time normally associated with token and polling systems.
A GPSS computer simulation was made of the BID system to determine the average delay times experienced by the various priority classes of messages. An analytical model using a single priority class of messages is presented, and the results of the computer simulation are compared with this. The simulation results also indicate the uniformity of the average delays experienced by the Bus Interface Units across the bus resulting from the use of bidirectional flow of tokens.
Proposal for a connection-oriented internetwork protocol
Authors: Callon Ross 
Published: October 2004

Current OSI approaches to internetworking occur at the network layer, and can be split into two main divisions [1,2]: connectionless internetwork protocol intended for use over dissimilar networks, and relay approaches intended for interconnection of networks offering identical, reliable, connection-oriented service.
This article briefly introduces these two approaches and discusses the need for a somewhat different approach: a connection-oriented internetwork protocol. I discuss the reasons for defining such a protocol, and considering these reasons, I propose a general design. I conclude that the present connectionless internetwork protocol should be augmented by a complementary connection-oriented protocol of a much simpler design than traditional connection-oriented protocols.
Source routing in computer networks
Authors: Sunshine Carl A. 
Published: October 2004

As plans for network interconnection develop, the problems of internet routing and addressing become increasingly important. In one popular model of internet addressing, a hierarchical form of network and local (within network) address is used, with the source providing only the destination address while the intermediate network(s) and/or Gateways between networks take care of routing packets to that destination by various paths. This and related techniques requiring some form of routing table and knowledge at intermediate nodes are more fully discussed in [1,2,3].
This paper considers another technique for internet routing in which the source of internet packets specifies the complete internet route. When the entire route accompanies each internet packet, no routing decisions or tables are required at Gateways, but the packet format is complicated and overhead increases. In particular, the packet must carry a varying number of intermediate addresses depending on the path and destination [4]. This overhead may be reduced by setting up a fixed route with connection tables [1] when a connection is established.
A virtual terminal protocol based on the use of zones
Authors: Barber D. L. A. 
Published: October 2004

Companion papers have considered the concept of the Virtual Terminal in the context of a network (ref 1) and as an interface between users and computers (ref 2). These papers give a background for the present paper which proposes a Virtual Terminal protocol for use between an applications program and a remote terminal handler, based on the concept of the dynamic assignment of zones, introduced by Luca (ref 3).
The paper by Luca contains an excellent discussion of the concept and use of zones, which seem well suited for a Virtual Terminal protocol although this was not considered in his paper. Some simplification of Luca's work is appropriate because he is concerned both with the interface between an application and the terminal handler, which he calls the programmable communications controller (PCC), and with the mapping between the PCC and a real terminal. The first aspect only will be considered here as the basis of a simple applications level protocol for a Virtual Terminal. However, Luca's paper is also a useful guide for the designers of the terminal handler and users who are concerned with mapping the Virtual Terminal onto particular real terminals.
This paper draws on the ideas contained in the earlier papers reviewed in Appendix 1 of ref 2, and uses the notation introduced in Appendix 2 of ref 2. The zones concept is similar to the idea of the Communication Unit introduced by Schulze (ref 4) and this has also influenced the proposals set out below.
An RJE protocol for a resource sharing network
Authors: Day John , Grossman Gary R. 
Published: October 2004

For many users of networks like the ARPANET, an RJE protocol is probably as important in terms of utility as the TELNET (or Virtual Terminal) protocol. In fact, the facilities provided by a TELNET and an RJE protocol are probably of most interest to the majority of users of computer networks. For these users, the network provides a fast, cheap telephone surrogate to a variety of computers for RJE and terminal access. The collection (and layers) of protocols that are used to provide these services must be organized to efficiently support a wide variety of applications and user needs. They should not pose an undue software burden on the user.
The "official" NETRJE protocol for the ARPANET is built on top of the Telnet and File Transfer Protocols (FTP). A user of NETRJE establishes a Telnet connection using the User NETRJE program on his local host to a Server NETRJE process at the host where he wishes to submit a job (see Figure 1). The user then sends to the Server process appropriate commands to log in, to describe where the job is that is to be submitted, to describe how the job is to be transferred, and to describe what is co be done with output when the job is completed. The Server NETRJE process on the foreign host then uses the FTP to transfer the input file to the foreign host, and then may use FTP again later to send the output back to the user. This protocol is very general and allows a user to submit his input from one host, process it at a second, and send the output to a third.
X.25 link access procedure
Authors: Cosell Bernard , Nemeth Alan , Walden David 
Published: October 2004

We prepared this description of the X.25 link access protocol for a commercial packet-switching network installation in which we participated. Our goal was to provide the network's users with a version of the link access procedures specification which was easier to read and understand than the X.25 specification documents available at the time. No attempt was made to change or improve the X.25 link access procedure; we merely attempted to write the procedure down more clearly.
We have written the description in terms of "Nodes" and "Hosts", terms which are in common use in the packet-switching network field. Others desiring to adopt this description may decide to use the CCITT terms "DCE" and "DTE", or still other terms, for the same functional entities.
The X.25 specification of its link access procedure includes a detailed description of the mechanisms used to provide bit error detection and data transparency on the link, i.e., a specific 16-bit checksum and a method of inserting and later deleting additional 1-bits which provides the equivalent of the BSC escape character mechanism. We do not view the detailed specification of these aspects of the (presumably hardware) interface as fundamental to the X.25 link access procedure. Both the error control and transparency functions must be provided, but it is easiest to use whichever specific mechanisms are provided in the communications interface line of the vendor of the Host computer rather than requiring the X.25 specification to be used.
We were aided in learning the X.25 link access procedure by Marie Rousseau. Our colleague, Alex McKenzie, provided important editorial assistance and guidance regarding the presentation of this description, and by rights he should be considered a co-author.
A problem with the X.25 link access procedure
Authors: Gostl Jack 
Published: October 2004

In the first half of 1977 I was involved in the design and implementation of a network control program (NCP) which interfaced a PDP-11/70 Host computer to a packet switching network (similar to ARPANET (1)). The NCP was responsible for both Host to Host message control and Host to network link control. The Host to network interface used a subset of X.25 (2) for its Link Access Pro cedure (LAP).
During the development and debugging of the NCP, it was discovered that the Host-network link could get into a deadlock condition which could not be rectified by any mechanism specified in the current X.25 protocol. The LAP, the problem and several possible solutions are described.
Some problems with the X.25 packet level protocol
Authors: Belsnes Dag , Lynning Ejvind 
Published: October 2004

During the last year recommendation X.25 [1] of the CCITT specifying a packet mode interface between a DTE and a DCE has been the subject of study and discussion. X.25 defines a link access and a packet level protocol the latter of which is of interest here. According to X.25 a number of logical connections, called virtual calls, may share one physical link between DTE and DCE. The sharing is achieved by asynchronous time-division multiplexing of so-called logical channels. For each channel, call setup and clearing, data transfer, and flow control takes place by the exchange of packets. There are different types of packets for the different tasks mentioned. A scheme involving a number of states for logical channels is used in the protocol.
In this paper we discuss two aspects of the packet level protocol which we feel are insufficiently or erroneously specified in X.25. First, the insufficient description of the DTE-to-DTE packet level protocol which X.25 implies. Second, some problems relating to the states and state transitions for logical channels as specified by X.25. These problems we consider to be the result of erroneous design, and repair is suggested.
A file transfer protocol and implementation
Authors: Butscher B. , Heinze W. 
Published: October 2004

This paper presents a file transfer service in a heterogeneous computer network (HMINET). The basic architecture models are presented, the file transfer protocol is described and the implementation in the HMINET is shown with the functional capabilities and the command structure.
A transfer of files between different computer system can be regarded as a service, which is divided into four steps:
A: access to a file, which is administrated in a File Management System (FMS), residing on one computer system
B: transfer the file data by any transport medium
C: creation of a file copy in another EMS
D: additional operations on the transferred file, e.g. print out or conversion
The usual case of file transfer (FT) between different computer systems is an offline transport by means of any storage medium (disks, tapes, etc.). Some disadvantages arise by this method:
- offline transfer takes a long time
- incompatibility of peripheral devices, storage medium and dat a representation can make file transfer impossible or lead to an additional overhead
- for step A and C the user must be familiar with the control languages of every participated operating and file management system
- additional operations on the transferred file must be organised under the system control of the destination host
A lot of advantages offers a File Transfer Service, integrated in a network, which links together the above mentioned computer systems (hosts):
- with a reliable transport system in the network a fast online transfer of the file data can satisfy step B
- step A and C are controlled by the File Transfer Service with only one standard interface to the user
- additional operations on the copied file can he managed during the transfer of the data (conversion of file structure, file dat a and subsequent operations e.g. print)
- peripheral device support by involved operating and file management system under File Transfer Service control
The HMINET is a private star-shaped, heterogeneous network, which connects 22 process control computers and 3 mainframes. One basic function in that computer network is such a file transfer service. Typical applications of this service are:
Copy of data files from and to mainframes and process control computers
Transfer of programms and runable modules
Remote Job Entry and remote spool services, etc.
Encoding CCITT X.409 presentation transfer syntax
Authors: Pope Arthur R. 
Published: October 2004

CCITT Draft Recommendation X.409 [1] defines a manner of encoding information for communication among computer systems. This scheme includes not only an encoding syntax--rules by which communicated bits and octets are assigned meaning--but also a language for describing the form and content of communicated information in a human-readable notation. In this notation one may define the form of a protocol data unit (PDU), specifying how the PDU is composed of individual fields of integer values, bit flags, characters, etc. One may also use the notation to define specific instances of PDUs: a PDU containing the integer value 3, the bit flag "on" and the character "A", for example. From the notational description of the PDU one may directly infer its encoded representation by applying the rules of the encoding syntax.
As a language for documenting the encoding of standard protocols, the notation is intended primarily for human consumption. Being a formal language, however, it is also well suited to automated processing. This paper describes some software tools developed at BBN for processing the notation. The principle purpose of the tools is to permit rapid construction of PDU encoding and decoding software from notational descriptions of PDUs.
The next section of this paper contains a brief overview of the X.409 notation and syntax for those not already familiar with the Draft Recommendation. The following section describes the tools and their method of operation. Some notes about the implementation and its performance complete the paper.