rfc787.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

 (N)-service-access-points without establishing an (N)-connection
 for the transmission."

 The service definition, which is intended to provide a  workable
 basis  for  incorporating  a  connectionless  service  into  the






                |                       |
      (N)-data  |                       |
       request  |                       |
      --------->|                       |
                |       (N)-LAYER       |
                |                       |--------->
                |                       |  (N)-data
                |                       | indication
                |                       |




       FIGURE 3 - Connectionless Data Transmission











      (N)-data  |                       |
       request  |                       |
      --------->|                       |
                |                       |  (N)-data
                |       (N)-LAYER       |--------->
                |                       | indication
      <---------|                       |
      (N)-data  |                       |
       confirm  |                       |




        FIGURE 4 - "Reliable Datagram" Service


Connectionless Data Transmission, Rev. 1.00



 service descriptions for  individual  layers  of  the  Reference
 Model, is:

 "A Connectionless  (N)-Service  is  one  that  accomplishes  the
 transmission of a  single  self-contained  (N)-service-data-unit
 between  (N+1)-entities  upon  the  performance  of   a   single
 (N)-service access."


 Both of these definitions  depend  heavily  on  the  distinction
 between the terms "transmit", "transfer", and "exchange":

 Transmit: "to cause to pass or be conveyed through  space  or  a
 medium."  This term refers to the act of conveying only, without
 implying anything about reception.

 Transfer: "to convey  from  one  place,  person,  or  thing,  to
 another."  A one-way peer-to-peer connotation restricts the  use
 of this term to cases in which the receiving peer  is  party  to
 and accepts the data transferred.

 Exchange: "to give and receive, or lose and take,  reciprocally,
 as things of the same kind."  A two-way peer-to-peer connotation
 restricts the use of this term to cases in which both  give  and
 receive directions are clearly evident.


 These  definitions  are  clearly  of   limited   usefulness   by
 themselves.  They do, however, provide a framework within  which
 to explore the following characteristics of CDT:

 1.  "One-shot" Operation.

 The most  user-visible  characteristic  of  connectionless  data
 transmission is the single service access required  to  initiate
 the transmission of a data unit.  All  of  the  information  re-
 quired to deliver the data unit - destination  address,  quality
 of service selection,  options,  etc.  -  is  presented  to  the
 connectionless (N)-service provider, along with the data,  in  a
 single logical service-access operation that is  not  considered
 by the (N)-service to be related in  any  way  to  other  access
 operations, prior or subsequent (note, however, that  since  OSI
 is not  concerned  with  implementation  details,  the  specific
 interface mechanism employed by a particular  implementation  of
 connectionless service might involve  more  than  one  interface
 exchange to accomplish what is, from  a  logical  standpoint,  a
 single operation).  Once the service  provider  has  accepted  a
 data unit for connectionless transmission, no further communica-
 tion occurs between the provider and the  user  of  the  service
 concerning the fate or disposition of the data.


Connectionless Data Transmission, Rev. 1.00



 2.  Two-party Agreement.

 Connection-oriented data transfer requires the establishment  of
 a three-party agreement between the participating (N+1)-entities
 and the (N)-service.  A connectionless service, however,  invol-
 ves only two-party agreements: there may be an agreement between
 the corresponding (N+1)-entities, unknown  to  the  (N)-service,
 and there may be local agreements between each (N+1)-entity  and
 its local (N)-service provider, but no (N)-protocol  information
 is ever exchanged between  (N)-entities  concerning  the  mutual
 willingness of the (N+1)-entities to engage in a  connectionless
 transmission or to accept a particular data unit.

 In practice, some sort of a priori agreement (usually  a  system
 engineering design decision) is assumed  to  exist  between  the
 (N+1)-entities and the (N)-service concerning those  parameters,
 formats, and options that affect all three parties  as  a  unit.
 However, considerable freedom of choice is preserved by allowing
 the user of a connectionless service to specify  most  parameter
 values and options - such as  transfer  rate,  acceptable  error
 rate, etc. - at the time the service is  invoked.   In  a  given
 implementation, if the  local  (N)-service  provider  determines
 immediately (from information available to it locally) that  the
 requested operation cannot be  performed  under  the  conditions
 specified, it may abort  the  service  primitive,  returning  an
 implementation-specific error message across  the  interface  to
 the user.  If the same determination is made later on, after the
 service-primitive interface event has completed,  the  transmis-
 sion is  simply  abandoned,  since  users  of  a  connectionless
 service can be expected to recover lost data if it is  important
 for them to do so.

 3.  Self-contained Data Units.

 Data units transmitted via a connectionless service, since  they
 bear no relationship either to other data units or to a  "higher
 abstraction"   (such   as   a    connection),    are    entirely
 self-contained.  All of the  addressing  and  other  information
 needed by the service provider to deliver a  data  unit  to  its
 destination must be included in each transmission.  On  the  one
 hand, this represents a greater overhead than is incurred during
 the data transfer phase of a connection-oriented interaction; on
 the other, it greatly simplifies routing, since each  data  unit
 carries a complete destination address and can be routed without
 reference to connection-related information that  may  not,  for
 example, be readily available at intermediate nodes.

 4.  Data Unit Independence.

 The connectionless transmission of data creates no relationship,
 express or implied, between data units.  Each  invocation  of  a

Connectionless Data Transmission, Rev. 1.00



 connectionless service begins the transmission of a single  data
 unit.  Nothing about the service invocation, the transmission of
 the data by the connectionless service, or the data unit  itself
 affects or is affected by any other  past,  present,  or  future
 operation, whether  connection-oriented  or  connectionless.   A
 series of data units handed one after the other to a connection-
 less service for delivery  to  the  same  destination  will  not
 necessarily be delivered to the destination in the  same  order;
 and the connectionless service will make no attempt to report or
 recover instances of non-delivery.

 Note:   A number of popular variations  on  CDT  include
         features that run  counter  to  those  described
         above.  These variations deserve to be discussed
         on their own merits, but should not be  confused
         with the architectural concept of connectionless
         data transmission.




 These characteristics make CDT attractive in  applications  that
 involve short-term request-response interactions, exhibit a high
 level of redundancy, must be flexibly reconfigurable, or  derive
 no benefit from guaranteed in-sequence delivery of data.


 3  The Rationale for Connectionless Data Transmission


 Because CDT is not as widely understood  as  connection-oriented
 data transfer, it has often been  difficult  in  the  course  of
 developing service and protocol definitions to adduce a  ration-
 ale for incorporating CDT, and even more difficult to  determine
 appropriate locations  for  connectionless  service  within  the
 layered hierarchy of OSI.   This  section  addresses  the  first
 concern; the next section will deal with the second.

 The most natural way to discover the power and  utility  of  the
 CDT  concept  is  to  examine  applications  and  implementation
 technologies that depend on it.  The following observations  are
 distilled from the specifications  and  descriptions  of  actual
 protocols and systems (many of which have been implemented), and
 from the work of individuals and organizations  engaged  in  the
 OSI standardization effort (quoted material is from reference 3,
 except where otherwise noted).   They  are  divided  into  seven
 (occassionally  overlapping)  categories  which   classify   the
 applications for which CDT is well suited.

 Inward data collection involves the periodic active  or  passive
 sampling of a large  number  of  data  sources.   A  sensor  net

Connectionless Data Transmission, Rev. 1.00



 gathering data from dedicated measurement  stations;  a  network
 status monitor constantly refreshing its knowledge of a  network
 environment; and an automatic alarm or security system in  which
 each component regularly self-tests and reports the result,  are
 all engaged in this type  of  interaction,  in  which  a  "large
 number of sources may be reporting periodically  and  asynchron-
 ously to a single reporting point.   In  a  realtime  monitoring
 situation, these readings could normally be  lost  on  occassion
 without causing distress,  because  the  next  update  would  be
 arriving shortly.  Only  if  more  than  one  successive  update
 failed to arrive within a specified time limit would an alarm be
 warranted.   If,  say,  a  fast   connect/disconnect   three-way
 handshake cost twice as much as a one-way [connectionless]  data
 transmission which had  been  system  engineered  to  achieve  a
 certain acceptable statistical reliability figure, the  cost  of
 connection-oriented inward data collection for a  large  distri-
 buted  application  could  be  substantially  greater  than  for
 [connectionless collection], without a  correspondingly  greater
 benefit to the user."[3]

 Outward data dissemination is in a  sense  the  inverse  of  the
 first category; it concerns the distribution of  a  single  data
 unit to a large  number  of  destinations.   This  situation  is
 found,  for  example,  when  a  node  joins  a  network,  or   a
 commonly-accessible server  changes  its  location,  and  a  new
 address is sent to other nodes on the network; when a synchroni-
 zing message such as a real-time clock value must be sent to all
 participants in some distributed activity; and when an  operator
 broadcasts a nonspecific message (e.g., "Network coming down  in
 five minutes").  In such cases, the distribution cost (including
 time) may far exceed the cost of generating the  data;  control-
 ling the overall cost depends on keeping the cost of  dissemina-
 tion as low as possible.

 Request-response applications are those in which  a  service  is
 provided by a commonly accessible  server  process  to  a  large
 number of distributed request sources.  The typical  interaction
 consists of a single request followed by a single response,  and
 usually only the highest-level acknowledgement  -  the  response
 itself - is either necessary  or  meaningful.   Many  commercial
 applications (point of sale terminals, credit checking, reserva-
 tion systems, inventory control, and automated banking  systems)
 and some types of industrial process control, as  well  as  more
 general information retrieval systems (such as  videotex),  fall
 into this category.  In each case, the knowledge and expectation
 of each application component as to the nature of  the  interac-
 tion is represented in an application-process design and  imple-
 mentation that is known in advance, outside of OSI; lower  level
 negotiations,  acknowledgements,  and  other  connection-related
 functions are often unnecessary and cumbersome.


Connectionless Data Transmission, Rev. 1.00



 An example of an application that combines  the  characteristics
 of inward  data  collection,  outward  data  dissemination,  and
 request-response interaction is described by the  Working  Group
 on Power System Control Centers of the  IEEE  Power  Engineering
 Society in a recent letter to the  chairman  of  ANSI  committee
 X3T51 concerning  the  use  of  data  communication  in  utility
 control centers[17].  They note that "a utility  control  center
 receives information from  remote  terminal  units  (located  at