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

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


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.

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

 [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 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.

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

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:


       - 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

[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

 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

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

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.

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 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

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.

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

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

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

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;

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

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

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

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

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

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.

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

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

                |                              |
                |                              |
                |                              |
   ,-------------------------,    ,-------------------------,
   | 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

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]

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
                     [to be supplied]


CDT Terminology

 The  following  terms,  not  yet  part  of  the   standard   OSI
 vocabulary,  relate  to  the  concept  of  connectionless   data

"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

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.

unit-data transfer/transmission
transaction (from SC1/N688)
data transmission (from DIS 2382 Section 9)

[End of Appendix A]

Appendix B: References

APPENDIX B - References

Reference Model.

         Source:         ISO/TC97/SC16
         Reference:      ISO/DP7498
         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-
         Reference:      ISO/TC97/SC16/N555
         Date:           11/80

3. Report of the Ad Hoc Group on Connectionless Data

         Source:         ISO/TC97/SC16/WG1  Ad  Hoc  Group   on
                                 Connectionless Data  Transmis-
         Reference:      ISO/TC97/SC16/N566
         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
         Date:           1/81

         Source:         ANSC X3S37
         Reference:      ISO/TC97/SC6/WG2/W12
         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
         Date:           3/81

9. US Position on Connectionless Data Transmission.

         Source:         ANSC X3T5
         Reference:      ISO/TC97/SC16/N605
         Date:           3/81


         Source:         ANSC X3S33/X3T56
         Reference:      ISO/TC97/SC16/N602
         Date:           3/81

11. Report of USA Vote and Comments on ISO DP7498.

         Source:         ANSC X3T5
         Reference:      ISO/TC97/SC16/N590
         Date:           3/81

12. USA Proposed Revision to Draft Basic Session Service
ISO TC97/SC16 N553.

         Source:         ANSC X3S33/X3T56
         Reference:      ISO/TC97/SC16/N597
         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

         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
         Date:           3/81

16. Review of the ISO Draft Proposal (DP 7498), Open System
                 Interconnection   Reference   Model   (Project

         Source:         National  Security   Agency,   Central
                                 Security  Service,  Department
                                 of Defense
         Reference:      NSA/CSS Serial T095/008/81
                         X3T51 Reference  Model  Editing  Group
         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

         Source:         A. Lyman Chapin, Data General Corpora-
         Reference:      X3T51 Reference  Model  Editing  Group
         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
         Date:           3/81

21. Comments on DP7498.

         Source:         ANSC X3S33/X3T56
         Reference:      X3S33/X3T56/81-60
                         X3T51 Reference  Model  Editing  Group
         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
         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
         Date:           9/80


         Source:         ANSC X3T5
         Reference:      X3T5/80-142
         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
         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
         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

         Source:         National  Bureau  of   Standards,   US
                                 Department of Commerce
         Reference:      X3T51/81-23
         Date:           7/80

30. Service Specification of an Internetwork Protocol.

         Source:         National  Bureau  of   Standards,   US
                                 Department of Commerce
         Reference:      X3T51/81-24
         Date:           9/80

31. DoD Standard Internet Protocol.

         Source:         US  Department  of  Defense   Advanced
                                 Research Projects Agency
         Reference:      X3S33/X3T56/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
         Reference:      X3T51/80-38
         Date:           8/80

         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

                 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.


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

         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

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