summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc787.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc787.txt')
-rw-r--r--doc/rfc/rfc787.txt2097
1 files changed, 2097 insertions, 0 deletions
diff --git a/doc/rfc/rfc787.txt b/doc/rfc/rfc787.txt
new file mode 100644
index 0000000..74a4a3f
--- /dev/null
+++ b/doc/rfc/rfc787.txt
@@ -0,0 +1,2097 @@
+Request For Comments: 787 A. Lyman Chapin
+ July 1981
+
+
+
+
+
+
+
+
+
+
+
+
+
+Subject: Connectionless Data Transmission Survey/Tutorial
+
+From: A. Lyman Chapin
+
+
+
+
+
+
+The attached paper on connectionless data transmission is being
+distributed to the members of a number of US organizations that are
+involved or interested in the development of international data
+communication standards. Following a review period ending Septem-
+ber 1, 1981, a revised version of the paper - incorporating com-
+ments and suggestions received from reviewers - will be considered
+by the American National Standards Institute (ANSI) committee
+responsible for Open Systems Interconnection (OSI) Reference Model
+issues (ANSC X3T5). If approved, it will then be presented to the
+relevant International Organization for Standardization (ISO)
+groups as the foundation of a US position recommending the incor-
+poration of connectionless data transmission by the Reference Model
+and related OSI service and protocol standards.
+
+Your comments on the paper, as well as an indication of the extent
+to which the concepts and services of connectionless data transmis-
+sion are important to you and/or your organization, will help to
+ensure that the final version reflects a true US position. They
+should be directed to the author at the following address:
+
+
+
+
+A. Lyman Chapin
+Data General Corporation MS E111
+4400 Computer Drive
+Westborough, MA 01580
+
+(617) 366-8911 x3056
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+ ,---------------------------------,
+X3S33/X3T56/81-85 | WORKING PAPER |
+X3T5/81-171 | This document has not been re- |
+X3T51/81-44 | viewed or approved by the appro-|
+X3S37/81-71R | priate Technical Committee and |
+ | does not at this time represent |
+ | a USA consensus. |
+ '---------------------------------'
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Connectionless Data Transmission
+
+
+ A. Lyman Chapin
+
+
+ 22 May 1981 Revision 1.00
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ABSTRACT
+
+ The increasingly familiar and ubiquitous Re-
+ ference Model of Open Systems Interconnection,
+ currently being considered by the International
+ Organization for Standardization (ISO) for
+ promotion to the status of a Draft International
+ Standard, is based on the explicit assumption
+ that a "connection" - an association between two
+ or more communicating entities, possessing
+ certain characteristics over and above those
+ possessed by the entities themselves - is
+ required for the transfer of data in an Open
+ Systems Interconnection (OSI) environment.
+ Although the connection-oriented model of
+ communications behavior has proven to be an
+ extremely powerful concept, and has been applied
+ successfully to the design and implementation of
+ protocols and systems covering a wide range of
+ applications, a growing body of research and
+ experience suggests that a complementary concept
+ - connectionless data transmission - is an
+ essential part of the Open Systems Interconnec-
+ tion architecture, and should be embraced as
+ such by the OSI Reference Model. This paper
+ explores the concept of connectionless data
+ transmission and its relationship to the more
+ familiar concepts of connection-oriented data
+ transfer, developing a rationale for the inclu-
+ sion of the connectionless concept in the
+ Reference Model as an integral part of the
+ standard description of the OSI architecture.
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+
+
+1 Introduction
+
+
+ Over the past three years, a number of national and interna-
+ tional standards organizations have expended the time and
+ efforts of a great many people to achieve a description of an
+ architectural Reference Model for interconnecting computer
+ systems considered to be "open" by virtue of their mutual use of
+ standard communication protocols and formats. The current
+ description, the Reference Model of Open Systems Interconnection
+ (RM/OSI)[1], is generally accepted by the International Organi-
+ zation for Standardization (ISO), the International Telephone
+ and Telegraph Consultatitive Committee (CCITT), the European
+ Computer Manufacturer's Association (ECMA), and many national
+ standards bodies, including the American National Standards
+ Institute (ANSI), and has progressed to the status of a Draft
+ Proposed Standard (DP7498) within ISO. It describes the con-
+ cepts and principles of a communications architecture organized
+ hierarchically, by function, into seven discrete layers, and
+ prescribes the services that each layer must provide to the
+ layer immediately above it (the uppermost layer provides its
+ services to user applications, which are considered to be
+ outside of the Open Systems Interconnection environment).
+ Building on the services available to it from the next-lower
+ layer, each layer makes use of standard OSI protocols which
+ enable it to cooperate with other instances of the same layer
+ (its "peers") in other systems (see Figure 1). This technique
+ of grouping related functions into distinct layers, each of
+ which implements a set of well-defined services that are used by
+ the layer above, partitions a very complex, abstract problem -
+ "how can the components of a distributed application, operating
+ in potentially dissimilar environments, cooperate with each
+ other?" - into a number of more manageable problems that enjoy a
+ logical relationship to each other and can individually be more
+ readily understood.
+
+ The Reference Model was developed to serve as a framework for
+ the coordination of existing and future standards designed to
+ facilitate the interconnection of data processing systems. The
+ purpose of OSI is to enable an end-user application activity
+ (called an "application process") located in a system that
+ employs OSI procedures and protocols (an "open" system) to
+ communicate with any other appication process located in any
+ other open system. It is not the intent of OSI to specify
+ either the functions or the implementation details of systems
+ that provide the OSI capabilities. Communication is achieved by
+ mutual adherence to agreed-upon (standardized) services and
+ protocols; the only thing that an OSI entity in a given layer in
+ one system needs to know about an OSI entity in the same layer
+
+User of (N)-services User of (N)-services
+ [an (N+1)-entity] [an (N+1)-entity]
+ \ /
+ \ /
+ \ /-----(N)-service-access-points-----\ / (N+1)
+-----------o-------------------------------------o------------
+ \ / (N)
+ \<-----services provided to------>/
+ \ (N+1)-layer /
+ \ /
+ ,------------, ,------------,
+ | | | |
+ | (N)-entity |<----"Peers"---->| (N)-entity | (N)-LAYER
+ | | | |
+ '------------' '------------'
+ \ /
+ \<----services required---->/
+ \ from (N-1)-layer /
+ \ / (N)
+-------------------o---------------------o--------------------
+ \ / (N-1)
+ \ /
+ \ /
+ \ /
+ ,--------------------------------,
+ | |
+ | |
+ | (N-1)-LAYER |
+ | |
+ | |
+ '--------------------------------'
+
+
+
+ FIGURE 1 - General Model of an OSI Layer
+
+
+
+A Note on OSI Terminology
+-------------------------
+
+The construction of a formal system, such as the architecture of
+Open Systems Interconnection, necessarily involves the introduc-
+tion of unambiguous terminology (which also tends to be somewhat
+impenetrable at first glance). The terms found here and in the
+text are all defined in an Appendix. The "(N)-" notation is used
+to emphasize that the term refers to an OSI characteristic that
+applies to each layer individually. The "(N)-" prefix stands in
+generically for the name of a layer; thus, "(N)-address", for
+example, refers abstractly to the concept of an address associa-
+ted with a specific layer, while "transport-address" refers to
+the same concept applied to the transport layer.
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ of another system is how the other entity behaves, not how it is
+ implemented. In particular, OSI is not concerned with how the
+ interfaces between adjacent layers are implemented in an open
+ system; any interface mechanism is acceptable, as long as it
+ supports access to the appropriate standard OSI services.
+
+ A major goal of the OSI standardization effort is generality.
+ Ideally, the Reference Model should serve as the common archi-
+ tectural framework for many different types of distributed
+ systems employing a wide range of telecommunication
+ technologies, and certainly an important measure of the success
+ of OSI will be its ability to apply the standard architecture
+ across a broad spectrum of user applications. The way in which
+ the Reference Model has developed over the past four years
+ reflects an awareness of this goal (among others): the process
+ began with the identification of the essential concepts of a
+ layered architecture, including the general architectural
+ elements of protocols, and proceeded carefully from these basic
+ principles to a detailed description of each layer. The organi-
+ zation of the current Reference Model document [1] exhibits the
+ same top-down progression. At the highest level, three elements
+ are identified as basic to the architecture[1]:
+
+ a) the application processes which exist within the Open
+ Systems Interconnection environment;
+
+ b) the connections which join the application processes and
+ permit them to exchange information; and
+
+ c) systems.
+
+ The assumption that a connection is a fundamental prerequisite
+ for communication in the OSI environment permeates the Reference
+ Model, and is in fact one of the most useful and important
+ unifying concepts of the architecture. A growing number of
+ experts in the field, however, believe that this deeply-rooted
+ connection orientation seriously and unnecessarily limits the
+ power and scope of the Reference Model, since it excludes a
+ large class of applications and implementation technologies that
+ have an inherently connectionless nature. They argue that the
+ architectural objectives of the Reference Model do not depend on
+ the exclusive use of connections to characterize all OSI
+ interactions, and recommend that the two alternatives - connec-
+ tion oriented data transfer, and connectionless data transmis-
+ sion - be treated as complementary concepts, which can be
+ applied in parallel to the different applications for which each
+ is suited.
+
+ At the November, 1980 meeting of the ISO subcommittee responsi-
+ ble for OSI (TC97/SC16), a working party laid a solid foundation
+ for this argument in two documents: Report of the Ad Hoc Group
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ on Connectionless Data Transmission[3], and Recommended Changes
+ to Section 3 of [the Reference Model] to Include Connectionless
+ Data Transmission[2]; and the importance of the issue was
+ recognized by the full subcommittee in a resolution[25] calling
+ for comments on the two documents from all member organizations.
+ The question of how the connectionless data transmission concept
+ should be reflected in the OSI architecture - and in particular,
+ whether or not it should become an integral part of the Re-
+ ference Model - will be debated again this summer, when the
+ current Draft Proposed Standard Reference Model becomes a Draft
+ International Standard. The remainder of this article will
+ explore the issues that surround this question.
+
+
+ 2 What Is Connectionless Data Transmission?
+
+
+ Connectionless data transmission (CDT), despite the unfamiliar
+ name, is by no means a new concept. In one form or another, it
+ has played an important role in the specification of services
+ and protocols for over a decade. The terms "message mode"[ ],
+ "datagram"[35], "transaction mode"[22,23,24], and
+ "connection-free"[37,47] have been used in the literature to
+ describe variations on the same basic theme: the transmission of
+ a data unit in a single self-contained operation without
+ establishing, maintaining, and terminating a connection.
+
+ Since connectionless data transmission and connection-oriented
+ data transfer are complementary concepts, they are best under-
+ stood in juxtaposition, particularly since CDT is most often
+ defined by its relationship to the more familiar concept of a
+ connection.
+
+
+ 2.1 Connection-Oriented Data Transfer
+
+
+ A connection (or "(N)-connection", in the formal terminology of
+ OSI) is an association established between two or more entities
+ ("(N+1)-entities") for conveying data
+ ("(N)-service-data-units"). The ability to establish
+ (N)-connections, and to convey data units over them, is provided
+ to (N+1)-entities by the (N)-layer as a set of services, called
+ connection-oriented (N)-services. Connection-oriented interac-
+ tions proceed through three distinct sequential phases: connec-
+ tion establishment; data transfer; and connection release.
+ Figure 2 illustrates schematically the sequence of operations
+ associated with connection-oriented interactions. In addition
+ to this explicitly distinguishable duration, or "lifetime", a
+ connection exhibits the following fundamental characteristics:
+
+ Connection Establishment
+ ------------------------
+
+ - Successful - - Unsuccessful -
+
+
+ (N)- | | (N)- | |
+connect | |(N)-connect connect | | (N)-
+------->| |indication ------->| | connect
+request | | request | |indication
+ | |-------> | |------->
+ |(N)-LAYER | |(N)-LAYER |
+ (N)- | |<------- (N)- | |<-------
+connect | | disconnect | | (N)-
+<-------| |(N)-connect <-------| |disconnect
+confirm | | response indication | | request
+ | | | |
+
+
+
+ Data Transfer
+ -------------
+
+ (N)- | | (N)- | |
+ data | | (N)-data data | |
+------->| |indication ------->| | (N)-
+request | | request | | data
+ | |-------> | |indication
+ |(N)-LAYER | |(N)-LAYER |------->
+ | | (N)- | |
+ | | data | |
+ | | <-------| |
+ | | confirm | |
+ | | | |
+
+
+
+ Connection Release
+ ------------------
+
+ - User Initiated - - Provider Initiated -
+
+
+(N)-dis | | | |
+connect | | (N)- | | (N)-
+------->|(N)-LAYER |(N)-disconnect disconnect|(N)-LAYER |disconnect
+request | |indication <-------| |------->
+ | |-------> indication| |indication
+ | | | |
+
+
+
+
+ FIGURE 2 - Connection Oriented Interaction
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+
+ [Note: Much of the material in this section is
+ derived from reference 3]
+
+
+ 1. Prior negotiation.
+
+ In a connection-oriented interaction, no connection is esta-
+ blished - and no data are transferred - until all parties agree
+ on the set of parameters and options that will govern the data
+ transfer. An incoming connection establishment request can be
+ rejected if it asserts parameter values or options that are
+ unacceptable to the receiver, and the receiver may in many cases
+ suggest alternative parameter values and options along with his
+ rejection.
+
+ The reason for negotiation during connection establishment is
+ the assumption that each party must reserve or allocate the
+ resources (such as buffers and channels) that will be required
+ to carry out data transfer operations on the new connection.
+ Negotiation provides an opportunity to scuttle the establishment
+ of a connection when the resources that would be required to
+ support it cannot be dedicated, or to propose alternatives that
+ could be supported by the available resources.
+
+ 2. Three-party Agreement.
+
+ The fundamental nature of a connection involves establishing and
+ dynamically maintaining a three-party agreement concerning the
+ transfer of data. The three parties - the two (N+1)-entities
+ that wish to communicate, and the (N)-service that provides them
+ with a connection - must first agree on their mutual willingness
+ to participate in the transfer (see above). This initial
+ agreement establishes a connection. Thereafter, for as long as
+ the connection persists, they must continue to agree on the
+ acceptance of each data unit transferred over the connection.
+ "With a connection, there is no possibility of data transfer
+ through an unwilling service to an unwilling partner, because
+ the mutual willingness must be established before the data
+ transfer can take place, and data must be accepted by the
+ destination partner; otherwise, no data [are] transferred on
+ that connection."[3]
+
+ 3. Connection Identifiers.
+
+ At connection establishment time, each participating
+ (N+1)-entity is identified to the (N)-service by an (N)-address;
+ the (N)-service uses these addresses to set up the requested
+ connection. Subsequent requests to transfer data over the
+ connection (or to release it) refer not to the (N)-address(es)
+ of the intended recipient(s), but to a connection identifier
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ supplied by the (N)-service (in OSI parlance, an
+ "(N)-connection-endpoint-identifier"). This is a
+ locally-significant "shorthand" reference that uniquely identi-
+ fies an established connection during its lifetime. Similarly,
+ the protocol units that carry data between systems typically
+ include a mutually-understood logical identifier rather than the
+ actual addresses of the correspondents. This technique elimina-
+ tes the overhead that would otherwise be associated with the
+ resolution and transmission of addresses on every data transfer.
+ In some cases, however - particularly when non-homogeneous
+ networks are interconnected, and very location-sensitive addres-
+ sing schemes are used - it can make dynamic routing of data
+ units extremely difficult, if not impossible.
+
+ 4. Data Unit Relationship.
+
+ Once a connection has been established, it may be used to
+ transfer one data unit after another, until the connection is
+ released by one of the three parties. These data units are
+ logically related to each other simply by virtue of being
+ transferred on the same connection. Since data units are
+ transferred over a connection in sequence, they are related
+ ordinally as well. These data unit relationships are an impor-
+ tant characteristic of connections, since they create a context
+ for the interpretation of arriving data units that is indepen-
+ dent of the data themselves. Because a connection maintains the
+ sequence of messages associated with it, out-of-sequence,
+ missing, and duplicated messages can easily be detected and
+ recovered, and flow control techniques can be invoked to ensure
+ that the message transfer rate does not exceed that which the
+ correspondents are capable of handling.
+
+
+ These characteristics make connection-based data transfer
+ attractive in applications that call for relatively long-lived,
+ stream-oriented interactions in stable configurations, such as
+ direct terminal use of a remote computer, file transfer, and
+ long-term attachments of remote job entry stations. In such
+ applications, the interaction between communicating entities is
+ modelled very well by the connection concept: the entities
+ initially discuss their requirements and agree to the terms of
+ their interaction, reserving whatever resources they will need;
+ transfer a series of related data units to accomplish their
+ mutual objective; and explicitly end their interaction, releas-
+ ing the previously reserved resources.
+
+
+ 2.2 Connectionless Data Transmission
+
+
+ In many other applications, however, the interaction between
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ entities is more naturally modelled by the connectionless data
+ transmission concept, which involves the transmission of a
+ single self-contained data unit from one entity to another
+ without prior negotiation or agreement, and without the as-
+ surance of delivery normally associated with connection-based
+ transfers. The users of a connectionless (N)-service may, of
+ course, use their (N+1)-protocol to make any prior or dynamic
+ arrangements they wish concerning their interpretation of the
+ data transmitted and received; the (N)-service itself, however,
+ attaches no significance to individual data units, and does not
+ attempt to relate them in any way. Two (N+1)-entities communi-
+ cating by means of a connectionless (N)-service could, for
+ example, apply whatever techniques they might consider appro-
+ priate in the execution of their own protocol (timers,
+ retransmission, positive or negative acknowledgements, sequence
+ numbers, etc.) to achieve the level of error detection and/or
+ recovery they desired. Users of a connectionless, as opposed to
+ connection-oriented, (N)-service are not restricted or inhibited
+ in the performance of their (N+1)-protocol; obviously, though,
+ the assumption is that CDT will be used in situations that
+ either do not require the characteristics of a connection, or
+ actively benefit from the alternative characteristics of connec-
+ tionless transmission.
+
+ Figure 3 illustrates schematically the single operation whereby
+ a connectionless service may be employed to transmit a single
+ data unit. Figure 4 shows a widely-implemented variation,
+ sometimes called "reliable datagram" service, in which the
+ service provider undertakes to confirm the delivery or
+ non-delivery of each data unit. It must be emphasized that this
+ is not a true connectionless service, but is in some sense a
+ hybrid, combining the delivery assurance of connection-oriented
+ service with the single-operation interface event of connection-
+ less service.
+
+
+ Many of those involved in OSI standardization activities have
+ agreed on a pair of definitions for connectionless data
+ transmission, one for architectural and conceptual purposes, and
+ one for service-definition purposes[4]. The architectural
+ definition, which has been proposed for inclusion in the Re-
+ ference Model, is:
+
+ "Connectionless Data Transmission is the transmission (not
+ transfer) of an (N)-service-data-unit from a source
+ (N)-service-access-point to one or more destination
+ (N)-service-access-points without establishing an (N)-connection
+ for the transmission."
+
+ The service definition, which is intended to provide a workable
+ basis for incorporating a connectionless service into the
+
+
+
+
+
+
+ | |
+ (N)-data | |
+ request | |
+ --------->| |
+ | (N)-LAYER |
+ | |--------->
+ | | (N)-data
+ | | indication
+ | |
+
+
+
+
+ FIGURE 3 - Connectionless Data Transmission
+
+
+
+
+
+
+
+
+
+
+
+ (N)-data | |
+ request | |
+ --------->| |
+ | | (N)-data
+ | (N)-LAYER |--------->
+ | | indication
+ <---------| |
+ (N)-data | |
+ confirm | |
+
+
+
+
+ FIGURE 4 - "Reliable Datagram" Service
+
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ service descriptions for individual layers of the Reference
+ Model, is:
+
+ "A Connectionless (N)-Service is one that accomplishes the
+ transmission of a single self-contained (N)-service-data-unit
+ between (N+1)-entities upon the performance of a single
+ (N)-service access."
+
+
+ Both of these definitions depend heavily on the distinction
+ between the terms "transmit", "transfer", and "exchange":
+
+ Transmit: "to cause to pass or be conveyed through space or a
+ medium." This term refers to the act of conveying only, without
+ implying anything about reception.
+
+ Transfer: "to convey from one place, person, or thing, to
+ another." A one-way peer-to-peer connotation restricts the use
+ of this term to cases in which the receiving peer is party to
+ and accepts the data transferred.
+
+ Exchange: "to give and receive, or lose and take, reciprocally,
+ as things of the same kind." A two-way peer-to-peer connotation
+ restricts the use of this term to cases in which both give and
+ receive directions are clearly evident.
+
+
+ These definitions are clearly of limited usefulness by
+ themselves. They do, however, provide a framework within which
+ to explore the following characteristics of CDT:
+
+ 1. "One-shot" Operation.
+
+ The most user-visible characteristic of connectionless data
+ transmission is the single service access required to initiate
+ the transmission of a data unit. All of the information re-
+ quired to deliver the data unit - destination address, quality
+ of service selection, options, etc. - is presented to the
+ connectionless (N)-service provider, along with the data, in a
+ single logical service-access operation that is not considered
+ by the (N)-service to be related in any way to other access
+ operations, prior or subsequent (note, however, that since OSI
+ is not concerned with implementation details, the specific
+ interface mechanism employed by a particular implementation of
+ connectionless service might involve more than one interface
+ exchange to accomplish what is, from a logical standpoint, a
+ single operation). Once the service provider has accepted a
+ data unit for connectionless transmission, no further communica-
+ tion occurs between the provider and the user of the service
+ concerning the fate or disposition of the data.
+
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ 2. Two-party Agreement.
+
+ Connection-oriented data transfer requires the establishment of
+ a three-party agreement between the participating (N+1)-entities
+ and the (N)-service. A connectionless service, however, invol-
+ ves only two-party agreements: there may be an agreement between
+ the corresponding (N+1)-entities, unknown to the (N)-service,
+ and there may be local agreements between each (N+1)-entity and
+ its local (N)-service provider, but no (N)-protocol information
+ is ever exchanged between (N)-entities concerning the mutual
+ willingness of the (N+1)-entities to engage in a connectionless
+ transmission or to accept a particular data unit.
+
+ In practice, some sort of a priori agreement (usually a system
+ engineering design decision) is assumed to exist between the
+ (N+1)-entities and the (N)-service concerning those parameters,
+ formats, and options that affect all three parties as a unit.
+ However, considerable freedom of choice is preserved by allowing
+ the user of a connectionless service to specify most parameter
+ values and options - such as transfer rate, acceptable error
+ rate, etc. - at the time the service is invoked. In a given
+ implementation, if the local (N)-service provider determines
+ immediately (from information available to it locally) that the
+ requested operation cannot be performed under the conditions
+ specified, it may abort the service primitive, returning an
+ implementation-specific error message across the interface to
+ the user. If the same determination is made later on, after the
+ service-primitive interface event has completed, the transmis-
+ sion is simply abandoned, since users of a connectionless
+ service can be expected to recover lost data if it is important
+ for them to do so.
+
+ 3. Self-contained Data Units.
+
+ Data units transmitted via a connectionless service, since they
+ bear no relationship either to other data units or to a "higher
+ abstraction" (such as a connection), are entirely
+ self-contained. All of the addressing and other information
+ needed by the service provider to deliver a data unit to its
+ destination must be included in each transmission. On the one
+ hand, this represents a greater overhead than is incurred during
+ the data transfer phase of a connection-oriented interaction; on
+ the other, it greatly simplifies routing, since each data unit
+ carries a complete destination address and can be routed without
+ reference to connection-related information that may not, for
+ example, be readily available at intermediate nodes.
+
+ 4. Data Unit Independence.
+
+ The connectionless transmission of data creates no relationship,
+ express or implied, between data units. Each invocation of a
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ connectionless service begins the transmission of a single data
+ unit. Nothing about the service invocation, the transmission of
+ the data by the connectionless service, or the data unit itself
+ affects or is affected by any other past, present, or future
+ operation, whether connection-oriented or connectionless. A
+ series of data units handed one after the other to a connection-
+ less service for delivery to the same destination will not
+ necessarily be delivered to the destination in the same order;
+ and the connectionless service will make no attempt to report or
+ recover instances of non-delivery.
+
+ Note: A number of popular variations on CDT include
+ features that run counter to those described
+ above. These variations deserve to be discussed
+ on their own merits, but should not be confused
+ with the architectural concept of connectionless
+ data transmission.
+
+
+
+
+ These characteristics make CDT attractive in applications that
+ involve short-term request-response interactions, exhibit a high
+ level of redundancy, must be flexibly reconfigurable, or derive
+ no benefit from guaranteed in-sequence delivery of data.
+
+
+ 3 The Rationale for Connectionless Data Transmission
+
+
+ Because CDT is not as widely understood as connection-oriented
+ data transfer, it has often been difficult in the course of
+ developing service and protocol definitions to adduce a ration-
+ ale for incorporating CDT, and even more difficult to determine
+ appropriate locations for connectionless service within the
+ layered hierarchy of OSI. This section addresses the first
+ concern; the next section will deal with the second.
+
+ The most natural way to discover the power and utility of the
+ CDT concept is to examine applications and implementation
+ technologies that depend on it. The following observations are
+ distilled from the specifications and descriptions of actual
+ protocols and systems (many of which have been implemented), and
+ from the work of individuals and organizations engaged in the
+ OSI standardization effort (quoted material is from reference 3,
+ except where otherwise noted). They are divided into seven
+ (occassionally overlapping) categories which classify the
+ applications for which CDT is well suited.
+
+ Inward data collection involves the periodic active or passive
+ sampling of a large number of data sources. A sensor net
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ gathering data from dedicated measurement stations; a network
+ status monitor constantly refreshing its knowledge of a network
+ environment; and an automatic alarm or security system in which
+ each component regularly self-tests and reports the result, are
+ all engaged in this type of interaction, in which a "large
+ number of sources may be reporting periodically and asynchron-
+ ously to a single reporting point. In a realtime monitoring
+ situation, these readings could normally be lost on occassion
+ without causing distress, because the next update would be
+ arriving shortly. Only if more than one successive update
+ failed to arrive within a specified time limit would an alarm be
+ warranted. If, say, a fast connect/disconnect three-way
+ handshake cost twice as much as a one-way [connectionless] data
+ transmission which had been system engineered to achieve a
+ certain acceptable statistical reliability figure, the cost of
+ connection-oriented inward data collection for a large distri-
+ buted application could be substantially greater than for
+ [connectionless collection], without a correspondingly greater
+ benefit to the user."[3]
+
+ Outward data dissemination is in a sense the inverse of the
+ first category; it concerns the distribution of a single data
+ unit to a large number of destinations. This situation is
+ found, for example, when a node joins a network, or a
+ commonly-accessible server changes its location, and a new
+ address is sent to other nodes on the network; when a synchroni-
+ zing message such as a real-time clock value must be sent to all
+ participants in some distributed activity; and when an operator
+ broadcasts a nonspecific message (e.g., "Network coming down in
+ five minutes"). In such cases, the distribution cost (including
+ time) may far exceed the cost of generating the data; control-
+ ling the overall cost depends on keeping the cost of dissemina-
+ tion as low as possible.
+
+ Request-response applications are those in which a service is
+ provided by a commonly accessible server process to a large
+ number of distributed request sources. The typical interaction
+ consists of a single request followed by a single response, and
+ usually only the highest-level acknowledgement - the response
+ itself - is either necessary or meaningful. Many commercial
+ applications (point of sale terminals, credit checking, reserva-
+ tion systems, inventory control, and automated banking systems)
+ and some types of industrial process control, as well as more
+ general information retrieval systems (such as videotex), fall
+ into this category. In each case, the knowledge and expectation
+ of each application component as to the nature of the interac-
+ tion is represented in an application-process design and imple-
+ mentation that is known in advance, outside of OSI; lower level
+ negotiations, acknowledgements, and other connection-related
+ functions are often unnecessary and cumbersome.
+
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ An example of an application that combines the characteristics
+ of inward data collection, outward data dissemination, and
+ request-response interaction is described by the Working Group
+ on Power System Control Centers of the IEEE Power Engineering
+ Society in a recent letter to the chairman of ANSI committee
+ X3T51 concerning the use of data communication in utility
+ control centers[17]. They note that "a utility control center
+ receives information from remote terminal units (located at
+ substations and generating plants) and from other control
+ centers, performs a variety of monitoring and control functions,
+ and transmits commands to the remote terminals and coordinating
+ information to other control centers." During the course of
+ these operations, the following conditions occur:
+
+ 1) Some measurements are transmitted or requested from
+ remote terminals or control centers every few seconds.
+ No attempt is necessarily made to recover data lost due
+ to transmission error; the application programs include
+ provisions for proper operation when input data is
+ occassionally missing. [Inward data collection]
+
+ 2) Some data items are transferred from commonly accessed
+ remote sites or multi-utility pool coordination centers
+ on a request-response basis. [Request-response
+ interaction]
+
+ 3) In some cases, an application program may require that
+ some measurements be made simultaneously in a large
+ number of locations. In these cases, the control center
+ will broadcast a command to make th affected
+ measurements. [Outward data dissemination]
+
+ In closing, they note that "utility control centers around the
+ world use data communications in ways similar to those in the
+ United States."
+
+
+ Broadcast and multicast (group addressed) communication using
+ connection-oriented services is awkward at best and impossible
+ at worst, notwithstanding the occassional mention of
+ "multi-endpoint connections" in the Reference Model. Some
+ characteristics of connection-based data transfer, such as
+ sequencing and error recovery, are very difficult to provide in
+ a broadcast/multicast environment, and may not even be
+ desirable; and it is not at all easy to formulate a useful
+ definition of broadcast/multicast acknowledgement that can be
+ supported by a low-level protocol. Where group addressing is an
+ important application consideration, connectionless data trans-
+ mission is usually the only choice.
+
+ Certain special applications, such as digitized voice, data
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ telemetry, and remote command and control, involving a high
+ level of data redundancy and/or real-time transmission
+ requirements, may profit from the fact that CDT makes no effort
+ to detect or recover lost or corrupted data. If the time span
+ during which an individual datum is meaningful is relatively
+ short, since it is quickly superceded by the next - or if, as in
+ digitized voice transmission, the loss or corruption of one or
+ even several data units is insignificant - the application might
+ suffer far more from the delay that would be introduced as a
+ connection-oriented service dealt with a lost or out-of-sequence
+ data unit (even if retransmission or other recovery procedures
+ were not invoked) than it would from the unreported loss of a
+ few data units in the course of a connectionless exchange.
+ Other special considerations - such as the undesirability, for
+ security reasons, of maintaining connection-state information
+ between data transfers in a military command and control system
+ - add force to the argument that CDT should be available as an
+ alternative to connection-oriented data transfer.
+
+ Local area networks (LANs) are probably the most fertile ground
+ for connectionless services, which find useful application at
+ several layers. LANs employ intrinsically reliable physical
+ transmission media and techniques (baseband and broadband
+ coaxial cable, fiber optics, etc.) in a restricted range
+ (generally no greater than 1 or 2 kilometers), and are typically
+ able to achieve extremely low bit error rates. In addition, the
+ media-access contention mechanisms favored by LAN designers
+ handle transmission errors as a matter of course. The usual
+ approach to physical interconnection ties all nodes together on
+ a common medium, creating an inherently broadcast environment in
+ which every transmission can be received by every station.
+ Taking advantage of these characteristics virtually demands a
+ connectionless data link service, and in fact most current and
+ proposed LANs - the Xerox Ethernet[43], the proposed IEEE 802
+ LAN standard[14,46], and many others - depend on such a service.
+ As a bonus, because connectionless services are simpler to
+ implement - requiring only two or three service primitives -
+ inexpensive VLSI implementations are often possible.
+
+ In addition, the applications for which LANs are often installed
+ tend to be precisely those best handled by CDT. Consider this
+ list of eight application classes identified by the IEEE 802
+ Interface Subcommittee as targets for the 802 LAN standard[46]:
+
+ 1. Periodic status reporting - telemetry data from
+ instrumentation, monitoring devices associated with static or
+ dynamic physical environments;
+
+ 2. Special event reporting - fire alarms, overload or stressing
+ conditions;
+
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ 3. Security control - security door opening and closing, system
+ recovery or initialization, access control;
+
+ 4. File transfer;
+
+ 5. Interactive transactions - reservation systems, electronic
+ messaging and conferencing;
+
+ 6. Interactive information exchange - communicating text and
+ word processors, electronic mail, remote job entry;
+
+ 7. Office information exchange - store and forward of digitized
+ voice messages, digitized graphic/image handling;
+
+ 8. Real-time stimulus and response - universal product code
+ checkout readers, distributed point of sale cash registers,
+ military command and control, and other closed-loop and
+ real-time applications.
+
+
+ Of these, almost all have already been identified as classic
+ examples of applications that have an essentially connectionless
+ nature. Consider this more detailed example of (8): a local
+ area network with a large number of nodes and a large number of
+ services (e.g., file management, printing, plotting, job
+ execution, etc.) provided at various nodes. In such a
+ configuration, it is impractical to maintain a table at each
+ node giving the address of every service, since changing the
+ location of a single service would require updating the address
+ table at every node. An alternative is to maintain a single
+ independent "server lookup" service, which performs the function
+ of mapping the name of a given service to the address of a
+ server providing that service. The server-lookup server re-
+ ceives requests such as, "where is service X?", and returns the
+ address at which an instance of service X is currently located.
+ Communication with the server-lookup server is inherently
+ self-contained, consisting of a single request/response
+ exchange. Only the highest-level acknowledgement - the response
+ from the lookup service giving the requested address - is at all
+ significant. The native reliability of the local area network
+ ensures a low error rate; if a message should be lost, no harm
+ is done, since the request will simply be re-sent if a timely
+ response does not arrive. Such an interaction is poorly model-
+ led by the connection-oriented paradigm of opening a connection,
+ transferring a stream of data, and closing the connection. It
+ is perfectly suited to connectionless transmission techniques.
+
+
+ Network interconnection (internetworking) can be facilitated -
+ especially when networks of different types are involved, as is
+ often the case - if the internetwork service is connectionless;
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ and a number of related activities, such as gateway-to-gateway
+ communication, exhibit the request-response, inward data
+ collection, and outward data dissemination characteristics that
+ are well supported by CDT. One of the best examples of a
+ connectionless internetwork service is described in a document
+ published by the National Bureau of Standards (Features of
+ Internetwork Protocol[29], which includes a straightforward
+ discussion of the merits of the connectionless approach:
+
+ "The greatest advantage of connectionless
+ service at the internet level is simplicity,
+ particularly in the gateways. Simplicity is
+ manifested in terms of smaller and less compli-
+ cated computer code and smaller computer storage
+ requirements. The gateways and hosts are not
+ required to maintain state information, nor
+ interpret call request and call clear commands.
+ Each data-unit can be treated
+ independently...Connectionless service assumes a
+ minim[al] service from the underlying
+ subnetworks. This is advantageous if the
+ networks are diverse. Existing internet proto-
+ cols which are intended for interconnection of a
+ diverse variety of networks are based on a
+ connectionless service [for example the PUP
+ Internetwork protocol[44], the Department of
+ Defence Standard Internet Protocol[31], and the
+ Delta-t protocol developed at Lawrence Livermore
+ Laboratory[45]]."
+
+ The principle motivating the development of internetwork servi-
+ ces and protocols that make few assumptions about the nature of
+ the individual network services (the "lowest common denominator"
+ approach) was formulated by Carl Sunshine as the "local net
+ independence principle"[39]: "Each local net shall retain its
+ individual address space, routing algorithms, packet formats,
+ protocols, traffic controls, fees, and other network character-
+ istics to the greatest extent possible." The simplicity and
+ robustness of connectionless internetworking systems guarantee
+ their widespread use as the number of different network types -
+ X.25 networks, LANs, packet radio networks, other broadcast
+ networks, and satellite networks - increases and the pressures
+ to interconnect them grow.
+
+
+
+ 4 CDT and the OSI Reference Model
+
+
+ As a concept, connectionless data transmission complements the
+ concept of connection-oriented data transfer throughout the OSI
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ architecture. As a basis for deriving standard OSI services and
+ protocols, however, it has a greater impact on some layers of
+ the Reference Model than on others. Careful analysis of the
+ relative merits of connectionless and connection-oriented
+ operation at each layer is necessary to control the prolifera-
+ tion of incompatible or useless options and preserve a balance
+ between the power of the complementary concepts and the stabili-
+ zing objective of the OSI standardization effort.
+
+ Figure 5 illustrates the layered OSI hierarchy as it is most
+ commonly represented (it shows two instances of the hierarchy,
+ representing the relationship between two OSI systems). The
+ following sections discuss the CDT concept in the context of
+ each of the seven layers.
+
+
+ 4.1 Physical Layer
+
+
+ The duality of connections and connectionless service is diffi-
+ cult to demonstrate satisfactorily at the physical layer,
+ largely because the concept of a physical "connection" is both
+ intuitive and colloquial. The physical layer is responsible for
+ generating and interpreting signals represented for the purpose
+ of transmission by some form of physical encoding (be it
+ electrical, optical, acoustic, etc.), and a physical connection,
+ in the most general sense (and restricting our consideration, as
+ does the Reference Model itself, to telecommunications media),
+ is a signal pathway through a medium or a combination of media.
+ Is a packet radio broadcast network, then, using a
+ "connectionless" physical service? No explicit signal pathway
+ through a medium or media is established before data are
+ transmitted. On the other hand, it can easily be argued that a
+ physical connection is established with the introduction of two
+ antennae into the "ether"; and if the antennae are aimed at each
+ other and designed to handle microwave transmission, the impres-
+ sion that a physical connection exists is strengthened. Whether
+ or not one recognizes the possibility of connectionless physical
+ services - other than purely whimsical ones - will probably
+ continue to depend on one's point of view, and will have no
+ effect on the development of actual telecommunication systems.
+
+
+ 4.2 Data Link Layer
+
+
+ Many data link technologies - particularly those coming into
+ popular use with the growth of local area networking - are far
+ easier to understand and work with when the traditional
+ connection-oriented concepts (embodied, for example, in the
+ widely-used HDLC, SDLC, and ADCCP standards) are replaced by the
+
+
+
+
+
+
+
+
+
+
+
+
+ ,---------------------, ,---------------------,
+ | | | |
+Level 7 | Application Layer |<---------->| Application Layer |
+ | | | |
+ |----------|----------| |----------|----------|
+ | | | |
+Level 6 | Presentation Layer |<---------->| Presentation Layer |
+ | | | |
+ |----------|----------| |----------|----------|
+ | | | |
+Level 5 | Session Layer |<---------->| Session Layer |
+ | | | |
+ |----------|----------| |----------|----------|
+ | | | |
+Level 4 | Transport Layer |<---------->| Transport Layer |
+ | | | |
+ |----------|----------| |----------|----------|
+ | | | |
+Level 3 | Network Layer |<---------->| Network Layer |
+ | | | |
+ |----------|----------| |----------|----------|
+ | | | |
+Level 2 | Data Link Layer |<---------->| Data Link Layer |
+ | | | |
+ |----------|----------| |----------|----------|
+ | | | |
+Level 1 | Physical Layer |<---------->| Physical Layer |
+ | | | |
+ '---------------------' '---------------------'
+
+
+
+
+
+ FIGURE 5 - Layered Hierarchy of Open Systems Interconnection
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ concept of connectionless data transmission. The previous
+ discussion of local area networking has already made the point
+ that the high-speed, short-range, intrinsically reliable broad-
+ cast transmission media used to interconnect stations in local
+ area networks are complemented both functionally and concep-
+ tually by connectionless data link techniques.
+
+ One of the organizations currently developing a local area
+ network data link layer standard - the Data Link and Media
+ Access (DLMAC) subcommittee of IEEE 802 - has recognized both
+ the need to retain compatibility with existing long-haul techni-
+ ques and the unique advantages of CDT for local area networks by
+ proposing that two data link procedures be defined for the IEEE
+ 802 standard.
+
+ In one procedure, information frames are unnumbered and may be
+ sent at any time by any station without first establishing a
+ connection. The intended receiver may accept the frame and
+ interpret it, but is under no obligation to do so, and may
+ instead discard the frame with no notice to the sender. Neither
+ is the sender notified if no station recognizes the address
+ coded into the frame, and there is no receiver. This
+ "connectionless" procedure, of course, assumes the "friendly"
+ environment and higher-layer acceptance of responsibility that
+ are usually characteristic of local area network
+ implementations.
+
+ The other procedure provides all of the sequencing, recovery,
+ and other guarantees normally associated with
+ connection-oriented link procedures. It is in fact very similar
+ to the ISO standard HDLC balanced asynchronous mode procedure.
+
+ Data link procedures designed for transmission media that
+ (unlike those used in local area networks) suffer unacceptable
+ error rates are almost universally connection-based, since it is
+ generally more efficient to recover the point-to-point
+ bit-stream errors detectable by connection-oriented data link
+ procedures at the data link layer (with its comparatively short
+ timeout intervals) than at a higher layer.
+
+
+ 4.3 Network Layer
+
+
+ Connectionless network service is useful for many of the same
+ reasons that were identified in the previous discussion of
+ network interconnection: it greatly simplifies the design and
+ implementation of systems; makes few assumptions about underly-
+ ing services; and is more efficient than a connection-oriented
+ service when higher layers perform whatever sequencing, flow
+ control, and error recovery is required by user applications (in
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ fact, internetwork services are provided by the Network Layer).
+ CDT also facilitates dynamic routing in packet- and
+ message-switched networks, since each data unit (packet or
+ message) can be directed along the most appropriate "next hop"
+ unencumbered by connection-mandated node configurations.
+ Examples of more or less connectionless network layer designs
+ and implementations abound: Zilog's Z-net (which offers both
+ "reliable" and "unreliable" service options); DECNET's
+ "transport layer" (which corresponds to the OSI Network layer);
+ Livermore Lab's Delta-t protocol (although it provides only a
+ reliable service, performing error checking, duplicate
+ detection, and acknowledgement); the User Datagram protocol[48];
+ and the Cyclades network protocol[38]. In fact, even the
+ staunchly connection-oriented X.25 public data networks
+ (Canada's Datapac is the best example) generally emply what
+ amounts to a connectionless network-layer service in their
+ internal packet switches, which enables them to perform flexible
+ dynamic routing on a packet-by-packet basis.
+
+
+ 4.4 Transport Layer
+
+
+ The connectionless transport service is important primarily in
+ systems that distinguish the Transport layer and everything
+ below it as providing something generically named the "Transport
+ Service", and abandon or severely compromise adherence to the
+ OSI architecture above the Transport layer. In such systems a
+ connectionless transport service may be needed for the same
+ reasons that other (more OSI-respecting) systems need a connec-
+ tionless application service. Otherwise, the purpose of defin-
+ ing a connectionless transport service is to enable a uniformly
+ connectionless service to be passed efficiently through the
+ Transport layer to higher layers.
+
+
+ 4.5 Session Layer
+
+
+ The whole notion of a session which binds presentation-entities
+ into a relationship of some temporal duration is inherently
+ connection-oriented. The purpose of defining a connectionless
+ session service, therefore, is to enable a uniformly connection-
+ less service to be passed efficiently through the session layer
+ to higher layers. In this sense, the connectionless session
+ service stands in precisely the same relationship to the connec-
+ tionless transport service as a session-connection stands to a
+ transport-connection.
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ 4.6 Presentation Layer
+
+
+ Very much the same considerations apply to the Presentation
+ layer as apply to the Session layer.
+
+
+ 4.7 Application Layer
+
+
+ The most obvious reason to define a connectionless application
+ service - to give user application processes access to the
+ connectionless services of the architecture - is not the only
+ one. The application layer performs functions that help user
+ application processes to converse regarding the meaning of the
+ information they exchange, and is also responsible for dealing
+ with the overall system management aspects of the OSI operation.
+ Over and above the many user-application requirements for
+ connectionless service, it may be profitably employed by system
+ management functions that monitor and report on the status of
+ resources in the local open system; by application layer manage-
+ ment functions that need to interact in a request-response mode
+ with similar functions in other systems to perform security
+ access control; and by user application process functions that
+ monitor the status of activities in progress.
+
+
+ The potential availability of two complementary services at each
+ layer of the architecture raises an obvious question - how to
+ choose between them? It should be clear at this point that
+ unilateral exclusion of one or the other, although it may
+ simplify the situation for some applications, is not a general
+ solution to the problem. There are actually two parts to the
+ question: how to select an appropriate set of cooperative
+ services for all seven layers during the design of a particular
+ open system; and, if one or more layers of the system will offer
+ both connection-oriented and connectionless services, how to
+ provide for the dynamic selection of one or the other in a given
+ circumstance.
+
+ The second part is easiest to dispose of, since actual systems -
+ as opposed to the more abstract set of services and protocols
+ collected under the banner of OSI - will generally be con-
+ structed in such a way as to combine services cooperatively,
+ with some attention paid to the way in which they will interact
+ to meet specific goals. Although two services may be provided
+ at a given layer, logical combinations of services for different
+ applications will generally be assembled according to relatively
+ simple rules established during the design of the system.
+
+ Evaluating the requirements of the applications a system must
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ support and the characteristics of the preferred implementation
+ technologies will also answer the first question. A system
+ designed primarily to transport large files over a long-haul
+ network would probably use only connection-oriented services.
+ One designed to collect data from widely scattered sensors for
+ processing at a central site might provide a connectionless
+ application service but use a connection-oriented network
+ service to achieve compatibility with a public data network.
+ Another system, built around a local area network bus or ring,
+ might use a connectionless data link service regardless of the
+ applications supported; if several LANs sere to be
+ interconnected, perhaps with other network types, it might also
+ employ a connectionless internetwork service.
+
+ The definition of OSI standard services and protocols, however,
+ must consider the general case, so as to accomodate a wide range
+ of actual-system configurations. The motivating principle
+ should be to achieve a balance between the two goals of power
+ and simplicity. The service definition for each layer must
+ include both connection-oriented and connectionless services;
+ otherwise, the utility of a service at one layer could be
+ negated by the unavailability of a corresponding service else-
+ where in the hierarchy. However, the role played by each
+ service may be radically different from one layer to the next.
+ The Presentation, Session, and Transport layers, for instance,
+ need to support their respective connectionless services only
+ because the Application layer, which must provide a connection-
+ less service to user applications, cannot do so effectively if
+ they do not. Recognizing these role variations opens up the
+ possibility of restoring a measure of the simplicity lost in the
+ introduction of choice at each layer by limiting, not the
+ choices, but the places in the hierarchy where conversion from
+ one choice to the other - connection to connectionless, or vice
+ versa - is allowed (see figure 6). At this stage in the devel-
+ opment of the CDT concept, it appears that there are exscellent
+ reasons for allowing such a conversion to take place in the
+ Application, Transport, and Network layers (and in the Data Link
+ layer, if some physical interconnection strategies are deemed to
+ be connectionless). In the other layers, the provision of one
+ kind of service to the next-higher layer must always be accom-
+ plished by using the same kind of service from the next-lower
+ layer (see figure 7). (This principle of like-to-like mapping
+ is not related to multiplexing; it refers to service types
+ (connection-oriented and connectionless), not to actual
+ services.) Adopting such a restriction would contribute to the
+ achievement of the balance mentioned above, without excluding
+ those combinations of services that have demonstrated their
+ usefulness.
+
+
+
+
+ ^ ^ (N+1)-LAYER
+ | |
+ | |
+----------------o------------------------------o----------------
+ | |
+ ,-------------------------, ,-------------------------,
+ | Offers a connectionless | | Offers a connection- |
+ | (N)-service | | oriented (N)-service |
+ | | | | | |
+ | (N)-LAYER | OR | (N)-LAYER |
+ | | | | | |
+ | Uses a connection- | | Uses a connectionless |
+ | oriented (N-1)-service | | (N-1)-service |
+ '-------------------------' '-------------------------'
+ | |
+----------------o------------------------------o----------------
+ | |
+ | |
+ v v (N-1)-LAYER
+
+
+ FIGURE 6 - Service Type Conversion
+
+
+
+
+
+
+
+ ^ ^ (N+1)-LAYER
+ | |
+ | |
+----------------o------------------------------o----------------
+ | |
+ ,-------------------------, ,-------------------------,
+ | Offers a connectionless | | Offers a connection- |
+ | (N)-service | | oriented (N)-service |
+ | | | | | |
+ | (N)-LAYER | OR | (N)-LAYER |
+ | | | | | |
+ | Uses a connectionless | | Uses a connection- |
+ | (N-1)-service | | oriented (N-1)-service |
+ '-------------------------' '-------------------------'
+ | |
+----------------o------------------------------o----------------
+ | |
+ | |
+ v v (N-1)-LAYER
+
+
+ FIGURE 7 - Same-Service Mapping
+
+Connectionless Data Transmission, Rev. 1.00
+
+
+
+ 5 Summary
+
+
+ Support for incorporating connectionless data transmission as a
+ basic architectural element of the Reference Model has grown as
+ understanding of the concept has become more widespread. The
+ protocol development sponsored by various agencies of the U.S.
+ Department of Defense, for example, have long recognized connec-
+ tions and connectionless transmission as complementary concepts,
+ and have employed both. Similar work being carried out by a
+ division of the Institute for Computer Science and Technology at
+ the National Bureau of Standards, the result of which will be a
+ series of Federal Information Processing Standards, depends
+ heavily on connectionless as well as connection-oriented
+ concepts. The importance of CDT to some of these U.S. efforts
+ is reflected in comments received by ANSI committee X3T5 during
+ the recent Reference Model ballot period, one of which states
+ that "Publication of this material [DP7498] without incorpora-
+ tion of the concerns associated with Connectionless Data
+ Trans[mission] makes a mockery of U.S. interests."[18] A some-
+ what less emotional expression of the same sentiment is embodied
+ in the official U.S. Position on Connectionless Data
+ Transmission[9], in which X3T5, the responsible U.S.
+ organization, "endorses SC16/N555 [Recommended Changes to
+ Section 3 of [the Reference Model] to Include CDT] without
+ exception and announces its intention to pursue vigorously the
+ incorporation of CDT as the first major extension to the Basic
+ Reference Model of OSI." In the same document, X3T5 notes that
+ it "intends to issue and maintain a version of DP7498 to be
+ referred to as DP7498-prime, incorporating the CDT extensions."
+ That there is also significant international support for the CDT
+ concept is clear, however, from the membership of the ISO
+ SC16/WG1 Ad Hoc Group on Connectionless Data Transmission, which
+ produced the N555 document last November; it includes represen-
+ tatives from France, Japan, Germany, and the United Kingdom as
+ well as from the U.S. Those who believe that the CDT concept is
+ an essential part of the OSI architecture hope that eventually
+ the DP7498-prime document, or its successor, will replace the
+ exclusively connection-oriented Reference Model before the
+ latter becomes an International Standard.
+
+
+ 6 Acknowledgements
+
+
+ [to be supplied]
+
+Connectionless Data Transmission, Rev. 1.00
+Appendix A: Vocabulary
+
+
+
+
+
+
+
+
+
+ APPENDIX A - Vocabulary
+
+
+
+
+
+
+ OSI Terminology
+
+ The following terms are defined in either the text or the
+ vocabulary annex (or both) of the Draft Proposed Reference Model
+ of OSI (ISO/DP7498). Some terms are given more than one defini-
+ tion in different sections of the Reference Model; these are
+ marked with an asterisk (*), to indicate that selection of the
+ accompanying definition involved the author's personal
+ judgement.
+ [to be supplied]
+
+
+
+
+ (N)-connection
+ (N)-service-access-point
+ (N)-service-access-point-address
+ (N)-layer
+ system
+ (N)-entity
+ (N)-connection-endpoint-identifier
+
+
+
+ CDT Terminology
+
+ The following terms, not yet part of the standard OSI
+ vocabulary, relate to the concept of connectionless data
+ transmission.
+
+ "Connectionless Data Transmission is the transmission (not
+ transfer) of an (N)-service-data-unit from a source
+ (N)-service-access-point to one or more destination
+ (N)-service-access-points without establishing an (N)-connection
+ for the transmission."
+
+ "A Connectionless (N)-Service is one that accomplishes the
+
+Connectionless Data Transmission, Rev. 1.00
+Appendix A: Vocabulary
+
+
+
+ transmission of a single self-contained (N)-service-data-unit
+ between (N+1)-entities upon the performance of a single
+ (N)-service access."
+
+ Transmit: "to cause to pass or be conveyed through space or a
+ medium." This term refers to the act of conveying only, without
+ implying anything about reception.
+
+ Transfer: "to convey from one place, person, or thing, to
+ another." A one-way peer-to-peer connotation restricts the use
+ of this term to cases in which the receiving peer is party to
+ and accepts the data transferred.
+
+ Exchange: "to give and receive, or lose and take, reciprocally,
+ as things of the same kind." A two-way peer-to-peer connotation
+ restricts the use of this term to cases in which both give and
+ receive directions are clearly evident.
+
+ datagram
+ unit-data transfer/transmission
+ transaction (from SC1/N688)
+ data transmission (from DIS 2382 Section 9)
+
+
+
+ [End of Appendix A]
+
+Connectionless Data Transmission, Rev. 1.00
+Appendix B: References
+
+
+
+
+
+
+
+
+
+ APPENDIX B - References
+
+
+
+
+ 1. Data Processing - Open Systems Interconnection - Basic
+ Reference Model.
+
+ Source: ISO/TC97/SC16
+ Reference: ISO/DP7498
+ X3T51/80-67
+ X3S33/X3T56/80-121
+ X3S37/80-115
+ Date: 12/80
+
+
+
+ 2. Recommended Changes to Section 3 of 97/16 N537, Basic
+ Specifications of the Reference Model of OSI,
+ to Include Connectionless Data Transmission.
+
+ Source: ISO/TC97/SC16/WG1 Ad Hoc Group on
+ Connectionless Data Transmis-
+ sion
+ Reference: ISO/TC97/SC16/N555
+ X3S37/81-9
+ X3T51/80-68
+ X3S33/X3T56/80-122
+ Date: 11/80
+
+
+
+ 3. Report of the Ad Hoc Group on Connectionless Data
+ Transmission.
+
+ Source: ISO/TC97/SC16/WG1 Ad Hoc Group on
+ Connectionless Data Transmis-
+ sion
+ Reference: ISO/TC97/SC16/N566
+ X3T51/80-69
+ X3S33/X3T56/81-13
+ X3S37/81-35
+ Date: 11/80
+
+
+
+ 4. Definitions of the Term "Connectionless Data Transmission"
+ (a letter to the chairman of ANSC X3T51 from
+ the acting chairman of ANSC X3T56).
+
+ Source: ANSC X3S33/X3T56
+ Reference: X3S33/X3T56/81-22
+ X3T51/81-2
+ X3S37/81-6
+ Date: 1/81
+
+
+
+
+
+ 5. Connectionless Provisions for OSI Reference Model.
+
+ Source: ANSC X3S37
+ Reference: ISO/TC97/SC6/WG2/W12
+ X3S37/81-16R
+ Date: 2/81
+
+
+
+ 6. Comments on Recommended Changes to Section 3 of 97/16
+ N537, Basic Specification of the Reference
+ Model of OSI, to include Connectionless Data
+ Transmission, SC16/N555.
+
+ Source: DIN (FRG)
+ Reference: ISO/TC97/SC6/WG2/W10
+ Date: 2/81
+
+
+
+ 7. Connectionless Data Transmission.
+
+ Source: X3S33/X3T56 Ad Hoc Group on Connec-
+ tionless Data Transmission
+ Reference: X3S33/X3T56/81-26
+ Date: 1/81
+
+
+
+ 8. Contribution to Document ISO/TC97/SC16 N555 Concerning the
+ Extension of General Concepts from the Basic
+ Reference Model to Connectionless Data Trans-
+ fer Mode.
+
+ Source: ISO/TC97/SC16/WG1 Ad Hoc Model Exten-
+ sion Group B
+ Reference:
+ Date: 3/81
+
+
+
+ 9. US Position on Connectionless Data Transmission.
+
+ Source: ANSC X3T5
+ Reference: ISO/TC97/SC16/N605
+ X3T51/81-26
+ Date: 3/81
+
+
+
+
+
+ 10. Revision of SC16/N551 to Include Connectionless Data
+ Transmission.
+
+ Source: ANSC X3S33/X3T56
+ Reference: ISO/TC97/SC16/N602
+ X3S33/X3T56/81-67
+ X3T51/81-20
+ X3S37/81-17
+ Date: 3/81
+
+
+
+ 11. Report of USA Vote and Comments on ISO DP7498.
+
+ Source: ANSC X3T5
+ Reference: ISO/TC97/SC16/N590
+ X3T51/81-29
+ Date: 3/81
+
+
+
+ 12. USA Proposed Revision to Draft Basic Session Service
+ Specification,
+ ISO TC97/SC16 N553.
+
+ Source: ANSC X3S33/X3T56
+ Reference: ISO/TC97/SC16/N597
+ X3S33/X3T56/81-39R
+ X3T51/81-28
+ Date: 3/81
+
+
+
+ 13. USA Proposed Revision to Draft Transport Service
+ Specification,
+ ISO TC97/SC16 N563.
+
+ Source: ANSC X3S33/X3T56
+ Reference: ISO/TC97/SC16/N601
+ X3S33/X3T56/81-33R
+ X3T51/81-17
+ Date: 3/81
+
+
+
+
+
+ 14. Comments on Connectionless Data Transmission.
+
+ Source: Robert F. Stover, Honeywell Inc.
+ Reference: Private communication
+ Date: 4/81
+
+
+
+ 15. Proposed Changes to the OSI Transport Layer.
+
+ Source: Gregory Ennis, Sytek Inc.
+ Reference: X3T51 Reference Model Editing Group
+ V3.B
+ Date: 3/81
+
+
+
+ 16. Review of the ISO Draft Proposal (DP 7498), Open System
+ Interconnection Reference Model (Project
+ IPSC-0168).
+
+ Source: National Security Agency, Central
+ Security Service, Department
+ of Defense
+ Reference: NSA/CSS Serial T095/008/81
+ X3T51 Reference Model Editing Group
+ V3.F
+ Date: 3/81
+
+
+
+ 17. Comments on Draft Proposal ISO/DP7498.
+
+ Source: Working Group on Power System Control
+ Centers, IEEE Power Engineer-
+ ing Society
+ Reference: X3T51 Reference Model Editing Group
+ V3.I, V4.4
+ Date: 3/81
+
+
+
+ 18. Review of ISO Draft Proposal 7498 (Open Systems
+ Interconnection).
+
+ Source: Department of the Air Force
+ Reference: X3T51 Reference Model Editing Group
+ V3.J, V4.5, V1.15, V2.H
+ Date: 3/81
+
+
+
+
+
+ 19. Proposed Improvements to Section 6 of DP7498.
+
+ Source: A. Lyman Chapin, Data General Corpora-
+ tion
+ Reference: X3T51 Reference Model Editing Group
+ V3.M
+ Date: 3/81
+
+
+
+ 20. Comments on Section 7.4 of DP7498.
+
+ Source: ANSC X3S33/X3T56
+ Reference: X3S33/X3T56/81-30
+ X3T51 Reference Model Editing Group
+ V3.H
+ Date: 3/81
+
+
+
+ 21. Comments on DP7498.
+
+ Source: ANSC X3S33/X3T56
+ Reference: X3S33/X3T56/81-60
+ X3T51 Reference Model Editing Group
+ V3.N
+ Date: 3/81
+
+
+
+ 22. USA Position Concerning Progression of the Reference Model
+ of Open Systems Interconnection (Parts I and
+ II of USA Comments on N309).
+
+ Source: ANSC X3T5
+ Reference: ISO/TC97/SC16/N405
+ X3T5/80-120
+ X3T51/80-43
+ Date: 9/80
+
+
+
+ 23. Addenda to the USA Position Concerning Progression of OSI
+ Reference Model (Parts I and II).
+
+ Source: ANSC X3T5
+ Reference: X3T5/80-143
+ X3T51/80-63
+ Date: 9/80
+
+
+
+
+
+ 24. US Position on the WG1 Rapporteur's Report of October
+ 1980.
+
+ Source: ANSC X3T5
+ Reference: X3T5/80-142
+ X3T51/80-62
+ Date: 10/80
+
+
+
+ 25. Resolutions: ISO/TC97/SC16 - Open Systems Interconnection:
+ Berlin - November 12 - 14, 1980.
+
+ Source: ISO/TC97/SC16
+ Reference: ISO/TC97/SC16/N570
+ X3S33/X3T56/80-11
+ Date: 11/80
+
+
+
+ 26. NBS Analysis of Major US Government Requirements of
+ Transport Protocol Services.
+
+ Source: National Bureau of Standards, US
+ Department of Commerce
+ Reference: ISO/TC97/SC16/N404
+ X3T51/80-32
+ X3S33/X3T56/80-82
+ Date: 9/80
+
+
+
+ 27. Features of the Transport and Session Protocols.
+
+ Source: National Bureau of Standards, US
+ Department of Commerce
+ Reference: X3S33/X3T56/80-30
+ Date: 3/80
+
+
+
+ 28. Specification of the Transport Protocol.
+
+ Source: National Bureau of Standards, US
+ Department of Commerce
+ Reference: X3S33/X3T56/81-59
+ Date: 2/81
+
+
+
+
+
+ 29. Features of Internetwork Protocol.
+
+ Source: National Bureau of Standards, US
+ Department of Commerce
+ Reference: X3T51/81-23
+ X3S33/X3T56/80-96
+ X3S37/81-31
+ Date: 7/80
+
+
+
+ 30. Service Specification of an Internetwork Protocol.
+
+ Source: National Bureau of Standards, US
+ Department of Commerce
+ Reference: X3T51/81-24
+ X3S33/X3T56/81-18
+ X3S37/81-32
+ Date: 9/80
+
+
+
+ 31. DoD Standard Internet Protocol.
+
+ Source: US Department of Defense Advanced
+ Research Projects Agency
+ Reference: X3S33/X3T56/80-17
+ X3S37/80-17
+ Date: 1/80
+
+
+
+ 32. Connectionless Data Transfer (letter from the chairman of
+ X3T51 to X3T55, X3T56, and X3S3).
+
+ Source: John Day, Digital Technology, Inc.
+ Reference: X3T51/80-76
+ Date: 12/80
+
+
+
+ 33. Local Area Networks and the OSI Reference Model.
+
+ Source: Robert R. Shatzer, Hewlett-Packard
+ Corp.
+ Reference: X3T51/80-38
+ Date: 8/80
+
+
+
+
+
+ 34. An Introduction to Local Area Networks.
+
+ Source: David D. Clark, et. al.
+ Reference: IEEE Proceedings 66:11
+ Date: 11/78
+
+
+
+ 35. Issues in Packet-Network Interconnection.
+
+ Source: V.G. Cerf and P.T. Kirstein
+ Reference: IEEE Proceedings 66:11
+ Date: 11/78
+
+
+
+ 36. Connectionless Data Transfer.
+
+ Source: John Neumann, Microdata Corp.
+ Reference: X3S33/X3T56/80-120
+ Date: 12/80
+
+
+
+ 37. A Protocol for Packet Network Interconnection.
+
+ Source: V.G. Cerf and R.E. Kahn
+ Reference: IEEE Transactions on Communication
+ COM-22 No. 5
+ Date: 5/74
+
+
+
+ 38. The CYCLADES End-to-End Protocol.
+
+ Source: H. Zimmermann
+ Reference: Proceedings of the IEEE Vol. 66 No. 11
+ Date: 11/78
+
+
+
+ 39. Interprocess Communication Protocols for Computer
+ Networks.
+
+ Source: Carl Sunshine, USC/ISI
+ Reference: Stanford Digital Systems Laboratory
+ TR105
+ Date: 12/75
+
+
+
+
+
+ 40. CCITT Recommendation X.25 - Interface Between Data Ter-
+ minal Equipment (DTE) and Data
+ Circuit-Terminating Equipment (DCE) for
+ Terminals Operating in the Packet Mode on
+ Public Data Networks.
+
+ Source: CCITT Study Group VII
+ Reference: COM VII/489
+ Date: 11/80
+
+
+
+ 41. An Analysis of ARPAnet Protocols.
+
+ Source:
+ Reference:
+ Date:
+
+
+
+ 42. ISO High-Level Data Link Control - Elements of Procedure.
+
+ Source: ISO
+ Reference: ISO/IS4335
+ Date: 1977
+
+
+
+ 43. ETHERNET Specification (Version 1.0)
+
+ Source: Xerox Corporation
+ Reference: X3T51/80-50
+ Date: 9/80
+
+
+
+ 44. PUP: An Internetwork Architecture.
+
+ Source: D.R. Boggs, J.F. Shoch, E.A. Taft,
+ R.M. Metcalfe
+ Reference: IEEE Transactions on Communications
+ COM-28 No. 4
+ Date: 4/80
+
+
+
+
+
+ 45. Delta-t Protocol Preliminary Specification.
+
+ Source: R.W. Watson
+ Reference: Lawrence Livermore Laboratories
+ Date: 11/79
+
+
+
+ 46. The Evolving IEEE 802 (Local Network) Standard.
+
+ Source: Bryan R. Hoover, Hewlett-Packard
+ Corporation
+ Reference:
+ Date:
+
+
+
+ 47. A System for Interprocess Communication in a Resource
+ Sharing Computer Network.
+
+ Source: D. Walden
+ Reference: Communications of the ACM Vol. 15
+ Date: 4/72