home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc0787.txt < prev    next >
Text File  |  1996-05-07  |  85KB  |  830 lines

  1. Request For Comments:  787                              A. Lyman Chapin                                                              July 1981 
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15. Subject:  Connectionless Data Transmission Survey/Tutorial 
  16.  
  17. From:     A. Lyman Chapin 
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  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. 
  24.  
  25. 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: 
  26.  
  27.  
  28.  
  29.  A. Lyman Chapin Data General Corporation MS E111 4400 Computer Drive Westborough, MA 01580 
  30.  
  31. (617) 366-8911 x3056 
  32.  Connectionless Data Transmission, Rev. 1.00 
  33.  
  34.                                  ,---------------------------------, 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.                |                                 '---------------------------------' 
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.                    Connectionless Data Transmission 
  51.  
  52.                            A. Lyman Chapin 
  53.  
  54.                     22 May 1981     Revision  1.00 
  55.  Connectionless Data Transmission, Rev. 1.00 
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.                        ABSTRACT 
  72.  
  73.  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. 
  74.  Connectionless Data Transmission, Rev. 1.00 
  75.  
  76.  
  77.  
  78.  
  79.  
  80. 1  Introduction 
  81.  
  82.   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. 
  83.  
  84.  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 
  85.  User of (N)-services                       User of (N)-services  [an (N+1)-entity]                           [an (N+1)-entity]         \                                           /          \                                         /           \ /-----(N)-service-access-points-----\ /     (N+1) -----------o-------------------------------------o------------             \                                   /        (N)              \<-----services provided to------>/               \          (N+1)-layer          /                \                             /         ,------------,                 ,------------,         |            |                 |            |         | (N)-entity |<----"Peers"---->| (N)-entity |    (N)-LAYER         |            |                 |            |         '------------'                 '------------'                \                             /                 \<----services required---->/                  \     from (N-1)-layer    /                   \                       /              (N) -------------------o---------------------o--------------------                     \                   /               (N-1)                      \                 /                       \               /                        \             /              ,--------------------------------,              |                                |              |                                |              |           (N-1)-LAYER          |              |                                |              |                                |              '--------------------------------' 
  86.  
  87.  
  88.  
  89.          FIGURE 1 -  General Model of an OSI Layer 
  90.  
  91.  
  92.  
  93. A Note on OSI Terminology ------------------------- 
  94.  
  95. 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. 
  96.  Connectionless Data Transmission, Rev. 1.00 
  97.  
  98.  
  99.  
  100.  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. 
  101.  
  102.  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]: 
  103.  
  104.       a) the application processes which exist  within  the  Open          Systems Interconnection environment; 
  105.  
  106.       b) the connections which join the application processes and          permit them to exchange information; and 
  107.  
  108.       c) systems. 
  109.  
  110.  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. 
  111.  
  112.  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 
  113.  Connectionless Data Transmission, Rev. 1.00 
  114.  
  115.  
  116.  
  117.  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. 
  118.  
  119.   2  What Is Connectionless Data Transmission? 
  120.  
  121.   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. 
  122.  
  123.  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. 
  124.  
  125.   2.1  Connection-Oriented Data Transfer 
  126.  
  127.   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: 
  128.                       Connection Establishment                      ------------------------ 
  129.  
  130.        - Successful -                        - Unsuccessful - 
  131.  
  132.    (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         |          |                           |          | 
  133.  
  134.  
  135.  
  136.                           Data Transfer                           ------------- 
  137.  
  138.   (N)-  |          |                     (N)-  |          |   data  |          | (N)-data            data  |          | ------->|          |indication         ------->|          |  (N)- request |          |                   request |          |  data         |          |------->                   |          |indication         |(N)-LAYER |                           |(N)-LAYER |------->         |          |                     (N)-  |          |         |          |                     data  |          |         |          |                   <-------|          |         |          |                   confirm |          |         |          |                           |          | 
  139.  
  140.                           Connection Release                         ------------------ 
  141.  
  142.      - User Initiated -                   - Provider Initiated - 
  143.  
  144.  (N)-dis |          |                           |          | connect |          |                     (N)-  |          |  (N)- ------->|(N)-LAYER |(N)-disconnect   disconnect|(N)-LAYER |disconnect request |          |indication         <-------|          |------->         |          |------->         indication|          |indication         |          |                           |          | 
  145.  
  146.  
  147.  
  148.              FIGURE 2 - Connection Oriented Interaction 
  149.  Connectionless Data Transmission, Rev. 1.00 
  150.  
  151.  
  152.  
  153.           [Note: Much of the material in this  section  is          derived from reference 3] 
  154.  
  155.   1.  Prior negotiation. 
  156.  
  157.  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. 
  158.  
  159.  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. 
  160.  
  161.  2.  Three-party Agreement. 
  162.  
  163.  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] 
  164.  
  165.  3.  Connection Identifiers. 
  166.  
  167.  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 
  168.  Connectionless Data Transmission, Rev. 1.00 
  169.  
  170.  
  171.  
  172.  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. 
  173.  
  174.  4.  Data Unit Relationship. 
  175.  
  176.  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. 
  177.  
  178.   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. 
  179.  
  180.   2.2  Connectionless Data Transmission 
  181.  
  182.   In many other applications,  however,  the  interaction  between 
  183.  Connectionless Data Transmission, Rev. 1.00 
  184.  
  185.  
  186.  
  187.  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. 
  188.  
  189.  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. 
  190.  
  191.   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: 
  192.  
  193.  "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." 
  194.  
  195.  The service definition, which is intended to provide a  workable  basis  for  incorporating  a  connectionless  service  into  the 
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.                 |                       |       (N)-data  |                       |        request  |                       |       --------->|                       |                 |       (N)-LAYER       |                 |                       |--------->                 |                       |  (N)-data                 |                       | indication                 |                       | 
  203.  
  204.  
  205.  
  206.         FIGURE 3 - Connectionless Data Transmission 
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.       (N)-data  |                       |        request  |                       |       --------->|                       |                 |                       |  (N)-data                 |       (N)-LAYER       |--------->                 |                       | indication       <---------|                       |       (N)-data  |                       |        confirm  |                       | 
  219.  
  220.  
  221.  
  222.          FIGURE 4 - "Reliable Datagram" Service 
  223.  
  224.  
  225.  Connectionless Data Transmission, Rev. 1.00 
  226.  
  227.  
  228.  
  229.  service descriptions for  individual  layers  of  the  Reference  Model, is: 
  230.  
  231.  "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." 
  232.  
  233.   Both of these definitions  depend  heavily  on  the  distinction  between the terms "transmit", "transfer", and "exchange": 
  234.  
  235.  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. 
  236.  
  237.  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. 
  238.  
  239.  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. 
  240.  
  241.   These  definitions  are  clearly  of   limited   usefulness   by  themselves.  They do, however, provide a framework within  which  to explore the following characteristics of CDT: 
  242.  
  243.  1.  "One-shot" Operation. 
  244.  
  245.  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. 
  246.  
  247.  
  248.  Connectionless Data Transmission, Rev. 1.00 
  249.  
  250.  
  251.  
  252.  2.  Two-party Agreement. 
  253.  
  254.  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. 
  255.  
  256.  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. 
  257.  
  258.  3.  Self-contained Data Units. 
  259.  
  260.  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. 
  261.  
  262.  4.  Data Unit Independence. 
  263.  
  264.  The connectionless transmission of data creates no relationship,  express or implied, between data units.  Each  invocation  of  a 
  265.  Connectionless Data Transmission, Rev. 1.00 
  266.  
  267.  
  268.  
  269.  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. 
  270.  
  271.  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. 
  272.  
  273.  
  274.  
  275.   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. 
  276.  
  277.   3  The Rationale for Connectionless Data Transmission 
  278.  
  279.   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. 
  280.  
  281.  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. 
  282.  
  283.  Inward data collection involves the periodic active  or  passive  sampling of a large  number  of  data  sources.   A  sensor  net 
  284.  Connectionless Data Transmission, Rev. 1.00 
  285.  
  286.  
  287.  
  288.  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] 
  289.  
  290.  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. 
  291.  
  292.  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. 
  293.  
  294.  
  295.  Connectionless Data Transmission, Rev. 1.00 
  296.  
  297.  
  298.  
  299.  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: 
  300.  
  301.       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] 
  302.  
  303.       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] 
  304.  
  305.       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] 
  306.  
  307.  In closing, they note that "utility control centers  around  the  world use data communications in ways similar to  those  in  the  United States." 
  308.  
  309.   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. 
  310.  
  311.  Certain special applications,  such  as  digitized  voice,  data 
  312.  Connectionless Data Transmission, Rev. 1.00 
  313.  
  314.  
  315.  
  316.  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. 
  317.  
  318.  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. 
  319.  
  320.  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]: 
  321.  
  322.  1.   Periodic   status   reporting   -   telemetry   data   from  instrumentation, monitoring devices associated  with  static  or  dynamic physical environments; 
  323.  
  324.  2.  Special event reporting - fire alarms, overload or stressing  conditions; 
  325.  
  326.  
  327.  Connectionless Data Transmission, Rev. 1.00 
  328.  
  329.  
  330.  
  331.  3.  Security control - security door opening and closing, system  recovery or initialization, access control; 
  332.  
  333.  4.  File transfer; 
  334.  
  335.  5.  Interactive transactions - reservation  systems,  electronic  messaging and conferencing; 
  336.  
  337.  6.  Interactive information exchange -  communicating  text  and  word processors, electronic mail, remote job entry; 
  338.  
  339.  7. Office information exchange - store and forward of  digitized  voice messages, digitized graphic/image handling; 
  340.  
  341.  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. 
  342.  
  343.   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. 
  344.  
  345.   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; 
  346.  Connectionless Data Transmission, Rev. 1.00 
  347.  
  348.  
  349.  
  350.  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: 
  351.  
  352.          "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]]." 
  353.  
  354.  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. 
  355.  
  356.  
  357.  
  358.  4  CDT and the OSI Reference Model 
  359.  
  360.   As a concept, connectionless data transmission  complements  the  concept of connection-oriented data transfer throughout the  OSI 
  361.  Connectionless Data Transmission, Rev. 1.00 
  362.  
  363.  
  364.  
  365.  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. 
  366.  
  367.  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. 
  368.  
  369.   4.1  Physical Layer 
  370.  
  371.   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. 
  372.  
  373.   4.2  Data Link Layer 
  374.  
  375.   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 
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.          ,---------------------,            ,---------------------,          |                     |            |                     | 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   |          |                     |            |                     |          '---------------------'            '---------------------' 
  389.  
  390.  
  391.  
  392.  
  393.  
  394.      FIGURE 5 - Layered Hierarchy of Open Systems Interconnection 
  395.  Connectionless Data Transmission, Rev. 1.00 
  396.  
  397.  
  398.  
  399.  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. 
  400.  
  401.  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. 
  402.  
  403.  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. 
  404.  
  405.  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. 
  406.  
  407.  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. 
  408.  
  409.   4.3  Network Layer 
  410.  
  411.   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 
  412.  Connectionless Data Transmission, Rev. 1.00 
  413.  
  414.  
  415.  
  416.  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. 
  417.  
  418.   4.4  Transport Layer 
  419.  
  420.   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. 
  421.  
  422.   4.5  Session Layer 
  423.  
  424.   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. 
  425.  Connectionless Data Transmission, Rev. 1.00 
  426.  
  427.  
  428.  
  429.  4.6  Presentation Layer 
  430.  
  431.   Very much the same  considerations  apply  to  the  Presentation  layer as apply to the Session layer. 
  432.  
  433.   4.7  Application Layer 
  434.  
  435.   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. 
  436.  
  437.   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. 
  438.  
  439.  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. 
  440.  
  441.  Evaluating the requirements of the applications  a  system  must 
  442.  Connectionless Data Transmission, Rev. 1.00 
  443.  
  444.  
  445.  
  446.  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. 
  447.  
  448.  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. 
  449.  
  450.  
  451.  
  452.  
  453.                 ^                              ^   (N+1)-LAYER                 |                              |                 |                              | ----------------o------------------------------o----------------                 |                              |    ,-------------------------,    ,-------------------------,    | Offers a connectionless |    |   Offers a connection-  |    |       (N)-service       |    |   oriented (N)-service  |    |            |            |    |            |            |    |        (N)-LAYER        | OR |        (N)-LAYER        |    |            |            |    |            |            |    |   Uses a connection-    |    |  Uses a connectionless  |    | oriented (N-1)-service  |    |      (N-1)-service      |    '-------------------------'    '-------------------------'                 |                              | ----------------o------------------------------o----------------                 |                              |                 |                              |                 v                              v   (N-1)-LAYER 
  454.  
  455.                 FIGURE 6 - Service Type Conversion 
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.                 ^                              ^   (N+1)-LAYER                 |                              |                 |                              | ----------------o------------------------------o----------------                 |                              |    ,-------------------------,    ,-------------------------,    | Offers a connectionless |    |   Offers a connection-  |    |       (N)-service       |    |   oriented (N)-service  |    |            |            |    |            |            |    |        (N)-LAYER        | OR |        (N)-LAYER        |    |            |            |    |            |            |    |  Uses a connectionless  |    |   Uses a connection-    |    |      (N-1)-service      |    | oriented (N-1)-service  |    '-------------------------'    '-------------------------'                 |                              | ----------------o------------------------------o----------------                 |                              |                 |                              |                 v                              v   (N-1)-LAYER 
  464.  
  465.                   FIGURE 7 - Same-Service Mapping 
  466.  Connectionless Data Transmission, Rev. 1.00 
  467.  
  468.  
  469.  
  470.  5  Summary 
  471.  
  472.   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. 
  473.  
  474.   6  Acknowledgements 
  475.  
  476.                       [to be supplied] 
  477.  Connectionless Data Transmission, Rev. 1.00 Appendix A: Vocabulary 
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.                       APPENDIX A - Vocabulary 
  488.  
  489.  
  490.  
  491.  
  492.  
  493.   OSI Terminology 
  494.  
  495.  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] 
  496.  
  497.  
  498.  
  499.   (N)-connection  (N)-service-access-point  (N)-service-access-point-address  (N)-layer  system  (N)-entity  (N)-connection-endpoint-identifier 
  500.  
  501.  
  502.  
  503.  CDT Terminology 
  504.  
  505.  The  following  terms,  not  yet  part  of  the   standard   OSI  vocabulary,  relate  to  the  concept  of  connectionless   data  transmission. 
  506.  
  507.  "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." 
  508.  
  509.  "A Connectionless  (N)-Service  is  one  that  accomplishes  the 
  510.  Connectionless Data Transmission, Rev. 1.00 Appendix A: Vocabulary 
  511.  
  512.  
  513.  
  514.  transmission of a  single  self-contained  (N)-service-data-unit  between  (N+1)-entities  upon  the  performance  of   a   single  (N)-service access." 
  515.  
  516.  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. 
  517.  
  518.  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. 
  519.  
  520.  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. 
  521.  
  522.  datagram  unit-data transfer/transmission  transaction (from SC1/N688)  data transmission (from DIS 2382 Section 9) 
  523.  
  524.  
  525.  
  526.                    [End of Appendix A] 
  527.  Connectionless Data Transmission, Rev. 1.00 Appendix B: References 
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.                       APPENDIX B - References 
  538.  
  539.  
  540.  
  541.  
  542.  1.  Data Processing - Open  Systems  Interconnection  -  Basic                  Reference Model. 
  543.  
  544.          Source:         ISO/TC97/SC16          Reference:      ISO/DP7498                          X3T51/80-67                          X3S33/X3T56/80-121                          X3S37/80-115          Date:           12/80 
  545.  
  546.  
  547.  
  548.  2.  Recommended Changes to Section  3  of  97/16  N537,  Basic                  Specifications of the Reference Model of  OSI,                  to Include Connectionless Data Transmission. 
  549.  
  550.          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 
  551.  
  552.  
  553.  
  554.  3.   Report  of  the  Ad  Hoc  Group  on  Connectionless  Data                  Transmission. 
  555.  
  556.          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 
  557.  
  558.  
  559.  
  560.  4.  Definitions of the Term "Connectionless Data Transmission"                  (a letter to the chairman of ANSC  X3T51  from                  the acting chairman of ANSC X3T56). 
  561.  
  562.          Source:         ANSC X3S33/X3T56          Reference:      X3S33/X3T56/81-22                          X3T51/81-2                          X3S37/81-6          Date:           1/81 
  563.  
  564.  
  565.  
  566.  
  567.   5.  Connectionless Provisions for OSI Reference Model. 
  568.  
  569.          Source:         ANSC X3S37          Reference:      ISO/TC97/SC6/WG2/W12                          X3S37/81-16R          Date:           2/81 
  570.  
  571.  
  572.  
  573.  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. 
  574.  
  575.          Source:         DIN (FRG)          Reference:      ISO/TC97/SC6/WG2/W10          Date:           2/81 
  576.  
  577.  
  578.  
  579.  7.  Connectionless Data Transmission. 
  580.  
  581.          Source:         X3S33/X3T56 Ad Hoc  Group  on  Connec-                                  tionless Data Transmission          Reference:      X3S33/X3T56/81-26          Date:           1/81 
  582.  
  583.  
  584.  
  585.  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. 
  586.  
  587.          Source:         ISO/TC97/SC16/WG1 Ad Hoc Model  Exten-                                  sion Group B          Reference:          Date:           3/81 
  588.  
  589.  
  590.  
  591.  9.  US Position on Connectionless Data Transmission. 
  592.  
  593.          Source:         ANSC X3T5          Reference:      ISO/TC97/SC16/N605                          X3T51/81-26          Date:           3/81 
  594.  
  595.  
  596.  
  597.  
  598.   10. Revision  of  SC16/N551  to  Include  Connectionless  Data                  Transmission. 
  599.  
  600.          Source:         ANSC X3S33/X3T56          Reference:      ISO/TC97/SC16/N602                          X3S33/X3T56/81-67                          X3T51/81-20                          X3S37/81-17          Date:           3/81 
  601.  
  602.  
  603.  
  604.  11. Report of USA Vote and Comments on ISO DP7498. 
  605.  
  606.          Source:         ANSC X3T5          Reference:      ISO/TC97/SC16/N590                          X3T51/81-29          Date:           3/81 
  607.  
  608.  
  609.  
  610.  12. USA Proposed  Revision  to  Draft  Basic  Session  Service                  Specification,                  ISO TC97/SC16 N553. 
  611.  
  612.          Source:         ANSC X3S33/X3T56          Reference:      ISO/TC97/SC16/N597                          X3S33/X3T56/81-39R                          X3T51/81-28          Date:           3/81 
  613.  
  614.  
  615.  
  616.  13.  USA  Proposed  Revision  to   Draft   Transport   Service                  Specification,                  ISO TC97/SC16 N563. 
  617.  
  618.          Source:         ANSC X3S33/X3T56          Reference:      ISO/TC97/SC16/N601                          X3S33/X3T56/81-33R                          X3T51/81-17          Date:           3/81 
  619.  
  620.  
  621.  
  622.  
  623.   14. Comments on Connectionless Data Transmission. 
  624.  
  625.          Source:         Robert F. Stover, Honeywell Inc.          Reference:      Private communication          Date:           4/81 
  626.  
  627.  
  628.  
  629.  15. Proposed Changes to the OSI Transport Layer. 
  630.  
  631.          Source:         Gregory Ennis, Sytek Inc.          Reference:      X3T51 Reference  Model  Editing  Group                          V3.B          Date:           3/81 
  632.  
  633.  
  634.  
  635.  16. Review of the ISO Draft Proposal (DP  7498),  Open  System                  Interconnection   Reference   Model   (Project                  IPSC-0168). 
  636.  
  637.          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 
  638.  
  639.  
  640.  
  641.  17. Comments on Draft Proposal ISO/DP7498. 
  642.  
  643.          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 
  644.  
  645.  
  646.  
  647.  18.  Review  of  ISO  Draft  Proposal   7498   (Open   Systems                  Interconnection). 
  648.  
  649.          Source:         Department of the Air Force          Reference:      X3T51 Reference  Model  Editing  Group                          V3.J, V4.5, V1.15, V2.H          Date:           3/81 
  650.  
  651.  
  652.  
  653.  
  654.   19. Proposed Improvements to Section 6 of DP7498. 
  655.  
  656.          Source:         A. Lyman Chapin, Data General Corpora-                                  tion          Reference:      X3T51 Reference  Model  Editing  Group                          V3.M          Date:           3/81 
  657.  
  658.  
  659.  
  660.  20. Comments on Section 7.4 of DP7498. 
  661.  
  662.          Source:         ANSC X3S33/X3T56          Reference:      X3S33/X3T56/81-30                          X3T51 Reference  Model  Editing  Group                          V3.H          Date:           3/81 
  663.  
  664.  
  665.  
  666.  21. Comments on DP7498. 
  667.  
  668.          Source:         ANSC X3S33/X3T56          Reference:      X3S33/X3T56/81-60                          X3T51 Reference  Model  Editing  Group                          V3.N          Date:           3/81 
  669.  
  670.  
  671.  
  672.  22. USA Position Concerning Progression of the Reference Model                  of Open Systems Interconnection (Parts  I  and                  II of USA Comments on N309). 
  673.  
  674.          Source:         ANSC X3T5          Reference:      ISO/TC97/SC16/N405                          X3T5/80-120                          X3T51/80-43          Date:           9/80 
  675.  
  676.  
  677.  
  678.  23. Addenda to the USA Position Concerning Progression of  OSI                  Reference Model (Parts I and II). 
  679.  
  680.          Source:         ANSC X3T5          Reference:      X3T5/80-143                          X3T51/80-63          Date:           9/80 
  681.  
  682.  
  683.  
  684.  
  685.   24. US Position on the  WG1  Rapporteur's  Report  of  October                  1980. 
  686.  
  687.          Source:         ANSC X3T5          Reference:      X3T5/80-142                          X3T51/80-62          Date:           10/80 
  688.  
  689.  
  690.  
  691.  25. Resolutions: ISO/TC97/SC16 - Open Systems Interconnection:                  Berlin - November 12 - 14, 1980. 
  692.  
  693.          Source:         ISO/TC97/SC16          Reference:      ISO/TC97/SC16/N570                          X3S33/X3T56/80-11          Date:           11/80 
  694.  
  695.  
  696.  
  697.  26. NBS  Analysis  of  Major  US  Government  Requirements  of                  Transport Protocol Services. 
  698.  
  699.          Source:         National  Bureau  of   Standards,   US                                  Department of Commerce          Reference:      ISO/TC97/SC16/N404                          X3T51/80-32                          X3S33/X3T56/80-82          Date:           9/80 
  700.  
  701.  
  702.  
  703.  27. Features of the Transport and Session Protocols. 
  704.  
  705.          Source:         National  Bureau  of   Standards,   US                                  Department of Commerce          Reference:      X3S33/X3T56/80-30          Date:           3/80 
  706.  
  707.  
  708.  
  709.  28. Specification of the Transport Protocol. 
  710.  
  711.          Source:         National  Bureau  of   Standards,   US                                  Department of Commerce          Reference:      X3S33/X3T56/81-59          Date:           2/81 
  712.  
  713.  
  714.  
  715.  
  716.   29. Features of Internetwork Protocol. 
  717.  
  718.          Source:         National  Bureau  of   Standards,   US                                  Department of Commerce          Reference:      X3T51/81-23                          X3S33/X3T56/80-96                          X3S37/81-31          Date:           7/80 
  719.  
  720.  
  721.  
  722.  30. Service Specification of an Internetwork Protocol. 
  723.  
  724.          Source:         National  Bureau  of   Standards,   US                                  Department of Commerce          Reference:      X3T51/81-24                          X3S33/X3T56/81-18                          X3S37/81-32          Date:           9/80 
  725.  
  726.  
  727.  
  728.  31. DoD Standard Internet Protocol. 
  729.  
  730.          Source:         US  Department  of  Defense   Advanced                                  Research Projects Agency          Reference:      X3S33/X3T56/80-17                          X3S37/80-17          Date:           1/80 
  731.  
  732.  
  733.  
  734.  32. Connectionless Data Transfer (letter from the chairman  of                  X3T51 to X3T55, X3T56, and X3S3). 
  735.  
  736.          Source:         John Day, Digital Technology, Inc.          Reference:      X3T51/80-76          Date:           12/80 
  737.  
  738.  
  739.  
  740.  33. Local Area Networks and the OSI Reference Model. 
  741.  
  742.          Source:         Robert  R.  Shatzer,   Hewlett-Packard                                  Corp.          Reference:      X3T51/80-38          Date:           8/80 
  743.  
  744.  
  745.  
  746.  
  747.   34. An Introduction to Local Area Networks. 
  748.  
  749.          Source:         David D. Clark, et. al.          Reference:      IEEE Proceedings 66:11          Date:           11/78 
  750.  
  751.  
  752.  
  753.  35. Issues in Packet-Network Interconnection. 
  754.  
  755.          Source:         V.G. Cerf and P.T. Kirstein          Reference:      IEEE Proceedings 66:11          Date:           11/78 
  756.  
  757.  
  758.  
  759.  36. Connectionless Data Transfer. 
  760.  
  761.          Source:         John Neumann, Microdata Corp.          Reference:      X3S33/X3T56/80-120          Date:           12/80 
  762.  
  763.  
  764.  
  765.  37. A Protocol for Packet Network Interconnection. 
  766.  
  767.          Source:         V.G. Cerf and R.E. Kahn          Reference:      IEEE  Transactions  on   Communication                          COM-22 No. 5          Date:           5/74 
  768.  
  769.  
  770.  
  771.  38. The CYCLADES End-to-End Protocol. 
  772.  
  773.          Source:         H. Zimmermann          Reference:      Proceedings of the IEEE Vol. 66 No. 11          Date:           11/78 
  774.  
  775.  
  776.  
  777.  39.  Interprocess   Communication   Protocols   for   Computer                  Networks. 
  778.  
  779.          Source:         Carl Sunshine, USC/ISI          Reference:      Stanford  Digital  Systems  Laboratory                          TR105          Date:           12/75 
  780.  
  781.  
  782.  
  783.  
  784.   40. CCITT Recommendation X.25 - Interface  Between  Data  Ter-                  minal     Equipment     (DTE)     and     Data                  Circuit-Terminating   Equipment   (DCE)    for                  Terminals Operating  in  the  Packet  Mode  on                  Public Data Networks. 
  785.  
  786.          Source:         CCITT Study Group VII          Reference:      COM VII/489          Date:           11/80 
  787.  
  788.  
  789.  
  790.  41. An Analysis of ARPAnet Protocols. 
  791.  
  792.          Source:          Reference:          Date: 
  793.  
  794.  
  795.  
  796.  42. ISO High-Level Data Link Control - Elements of Procedure. 
  797.  
  798.          Source:         ISO          Reference:      ISO/IS4335          Date:           1977 
  799.  
  800.  
  801.  
  802.  43. ETHERNET Specification (Version 1.0) 
  803.  
  804.          Source:         Xerox Corporation          Reference:      X3T51/80-50          Date:           9/80 
  805.  
  806.  
  807.  
  808.  44. PUP: An Internetwork Architecture. 
  809.  
  810.          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 
  811.  
  812.  
  813.  
  814.  
  815.   45. Delta-t Protocol Preliminary Specification. 
  816.  
  817.          Source:         R.W. Watson          Reference:      Lawrence Livermore Laboratories          Date:           11/79 
  818.  
  819.  
  820.  
  821.  46. The Evolving IEEE 802 (Local Network) Standard. 
  822.  
  823.          Source:         Bryan   R.   Hoover,   Hewlett-Packard                                  Corporation          Reference:          Date: 
  824.  
  825.  
  826.  
  827.  47. A System for  Interprocess  Communication  in  a  Resource                  Sharing Computer Network. 
  828.  
  829.          Source:         D. Walden          Reference:      Communications of the ACM Vol. 15          Date:           4/72 
  830.