Request For Comments: 787 A. Lyman Chapin
| does not at this time represent |
| a USA consensus. |
'---------------------------------'
Connectionless Data Transmission
22 May 1981 Revision 1.00
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.
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
[an (N+1)-entity] [an (N+1)-entity]
\ /
\ /
\ /-----(N)-service-access-points-----\ / (N+1)
\ / (N)
\<-----services provided to------>/
\ (N+1)-layer /
\ /
,------------, ,------------,
| | | |
| (N)-entity |<----"Peers"---->| (N)-entity | (N)-LAYER
| | | |
'------------' '------------'
\ /
\<----services required---->/
\ from (N-1)-layer /
\ / (N)
\ / (N-1)
\ /
\ /
\ /
,--------------------------------,
| |
| |
| (N-1)-LAYER |
| |
| |
'--------------------------------'
FIGURE 1 - General Model of an OSI Layer
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
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.
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:
------------------------
- 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 -
| |-------> indication| |indication
| | | |
FIGURE 2 - Connection Oriented Interaction
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.
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]
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
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.
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.
In many other applications, however, the interaction between
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
"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:
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.
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.
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.
The connectionless transmission of data creates no relationship, express or implied, between data units. Each invocation of a
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
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.
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
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;
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;
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
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.
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.
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 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
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.
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
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.
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.
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.
Very much the same considerations apply to the Presentation layer as apply to the Session 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
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.
| |
| |
| |
,-------------------------, ,-------------------------,
| 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 |
'-------------------------' '-------------------------'
| |
| |
| |
v v (N-1)-LAYER
FIGURE 6 - Service Type Conversion
^ ^ (N+1)-LAYER
| |
| |
| |
,-------------------------, ,-------------------------,
| 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 |
'-------------------------' '-------------------------'
| |
| |
| |
v v (N-1)-LAYER
FIGURE 7 - Same-Service Mapping
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]
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
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]
APPENDIX B - References
Source: ISO/TC97/SC16
Reference: ISO/DP7498
X3T51/80-67
X3S33/X3T56/80-121
X3S37/80-115
Date: 12/80
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
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
Source: ANSC X3S33/X3T56
Reference: X3S33/X3T56/81-22
X3T51/81-2
X3S37/81-6
Date: 1/81
Source: ANSC X3S37
Reference: ISO/TC97/SC6/WG2/W12
X3S37/81-16R
Date: 2/81
Source: DIN (FRG)
Reference: ISO/TC97/SC6/WG2/W10
Date: 2/81
Source: X3S33/X3T56 Ad Hoc Group on Connec-
tionless Data Transmission
Reference: X3S33/X3T56/81-26
Date: 1/81
Source: ISO/TC97/SC16/WG1 Ad Hoc Model Exten-
sion Group B
Reference:
Date: 3/81
Source: ANSC X3T5
Reference: ISO/TC97/SC16/N605
X3T51/81-26
Date: 3/81
Source: ANSC X3S33/X3T56
Reference: ISO/TC97/SC16/N602
X3S33/X3T56/81-67
X3T51/81-20
X3S37/81-17
Date: 3/81
Source: ANSC X3T5
Reference: ISO/TC97/SC16/N590
X3T51/81-29
Date: 3/81
Source: ANSC X3S33/X3T56
Reference: ISO/TC97/SC16/N597
X3S33/X3T56/81-39R
X3T51/81-28
Date: 3/81
Source: Robert F. Stover, Honeywell Inc.
Reference: Private communication
Date: 4/81
Source: Gregory Ennis, Sytek Inc.
Reference: X3T51 Reference Model Editing Group
V3.B
Date: 3/81
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
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
Source: A. Lyman Chapin, Data General Corpora-
tion
Reference: X3T51 Reference Model Editing Group
V3.M
Date: 3/81
Source: ANSC X3S33/X3T56
Reference: X3S33/X3T56/81-30
X3T51 Reference Model Editing Group
V3.H
Date: 3/81
Source: ANSC X3S33/X3T56
Reference: X3S33/X3T56/81-60
X3T51 Reference Model Editing Group
V3.N
Date: 3/81
Source: ANSC X3T5
Reference: ISO/TC97/SC16/N405
X3T5/80-120
X3T51/80-43
Date: 9/80
Source: ANSC X3T5
Reference: X3T5/80-143
X3T51/80-63
Date: 9/80
Source: ANSC X3T5
Reference: X3T5/80-142
X3T51/80-62
Date: 10/80
Source: ISO/TC97/SC16
Reference: ISO/TC97/SC16/N570
X3S33/X3T56/80-11
Date: 11/80
Source: National Bureau of Standards, US
Department of Commerce
Reference: ISO/TC97/SC16/N404
X3T51/80-32
X3S33/X3T56/80-82
Date: 9/80
Source: National Bureau of Standards, US
Department of Commerce
Reference: X3S33/X3T56/80-30
Date: 3/80
Source: National Bureau of Standards, US
Department of Commerce
Reference: X3S33/X3T56/81-59
Date: 2/81
Source: National Bureau of Standards, US
Department of Commerce
Reference: X3T51/81-23
X3S33/X3T56/80-96
X3S37/81-31
Date: 7/80
Source: National Bureau of Standards, US
Department of Commerce
Reference: X3T51/81-24
X3S33/X3T56/81-18
X3S37/81-32
Date: 9/80
Source: US Department of Defense Advanced
Research Projects Agency
Reference: X3S33/X3T56/80-17
X3S37/80-17
Date: 1/80
Source: John Day, Digital Technology, Inc.
Reference: X3T51/80-76
Date: 12/80
Source: Robert R. Shatzer, Hewlett-Packard
Corp.
Reference: X3T51/80-38
Date: 8/80
Source: David D. Clark, et. al.
Reference: IEEE Proceedings 66:11
Date: 11/78
Source: V.G. Cerf and P.T. Kirstein
Reference: IEEE Proceedings 66:11
Date: 11/78
Source: John Neumann, Microdata Corp.
Reference: X3S33/X3T56/80-120
Date: 12/80
Source: V.G. Cerf and R.E. Kahn
Reference: IEEE Transactions on Communication
COM-22 No. 5
Date: 5/74
Source: H. Zimmermann
Reference: Proceedings of the IEEE Vol. 66 No. 11
Date: 11/78
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
Source:
Reference:
Date:
Source: ISO
Reference: ISO/IS4335
Date: 1977
Source: Xerox Corporation
Reference: X3T51/80-50
Date: 9/80
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
Source: R.W. Watson
Reference: Lawrence Livermore Laboratories
Date: 11/79
Source: Bryan R. Hoover, Hewlett-Packard
Corporation
Reference:
Date:
Source: D. Walden
Reference: Communications of the ACM Vol. 15
Date: 4/72