rfc787.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,404 行 · 第 1/5 页

      c) systems.

 The assumption that a connection is a  fundamental  prerequisite
 for communication in the OSI environment permeates the Reference
 Model, and is in fact one  of  the  most  useful  and  important
 unifying concepts of the  architecture.   A  growing  number  of
 experts in the field, however, believe that  this  deeply-rooted
 connection orientation seriously and  unnecessarily  limits  the
 power and scope of the Reference  Model,  since  it  excludes  a
 large class of applications and implementation technologies that
 have an inherently connectionless nature.  They argue  that  the
 architectural objectives of the Reference Model do not depend on
 the  exclusive  use  of  connections  to  characterize  all  OSI
 interactions, and recommend that the two alternatives -  connec-
 tion oriented data transfer, and connectionless  data  transmis-
 sion - be  treated  as  complementary  concepts,  which  can  be
 applied in parallel to the different applications for which each
 is suited.

 At the November, 1980 meeting of the ISO subcommittee  responsi-
 ble for OSI (TC97/SC16), a working party laid a solid foundation
 for this argument in two documents: Report of the Ad  Hoc  Group

Connectionless Data Transmission, Rev. 1.00



 on Connectionless Data Transmission[3], and Recommended  Changes
 to Section 3 of [the Reference Model] to Include  Connectionless
 Data Transmission[2];  and  the  importance  of  the  issue  was
 recognized by the full subcommittee in a resolution[25]  calling
 for comments on the two documents from all member organizations.
 The question of how the connectionless data transmission concept
 should be reflected in the OSI architecture - and in particular,
 whether or not it should become an  integral  part  of  the  Re-
 ference Model - will be debated  again  this  summer,  when  the
 current Draft Proposed Standard Reference Model becomes a  Draft
 International Standard.  The  remainder  of  this  article  will
 explore the issues that surround this question.


 2  What Is Connectionless Data Transmission?


 Connectionless data transmission (CDT), despite  the  unfamiliar
 name, is by no means a new concept.  In one form or another,  it
 has played an important role in the  specification  of  services
 and protocols for over a decade.  The terms "message  mode"[  ],
 "datagram"[35],      "transaction      mode"[22,23,24],      and
 "connection-free"[37,47] have been used  in  the  literature  to
 describe variations on the same basic theme: the transmission of
 a  data  unit  in  a  single  self-contained  operation  without
 establishing, maintaining, and terminating a connection.

 Since connectionless data transmission  and  connection-oriented
 data transfer are complementary concepts, they are  best  under-
 stood in juxtaposition, particularly since  CDT  is  most  often
 defined by its relationship to the more familiar  concept  of  a
 connection.


 2.1  Connection-Oriented Data Transfer


 A connection (or "(N)-connection", in the formal terminology  of
 OSI) is an association established between two or more  entities
 ("(N+1)-entities")          for          conveying          data
 ("(N)-service-data-units").    The    ability    to    establish
 (N)-connections, and to convey data units over them, is provided
 to (N+1)-entities by the (N)-layer as a set of services,  called
 connection-oriented (N)-services.  Connection-oriented  interac-
 tions proceed through three distinct sequential phases:  connec-
 tion  establishment;  data  transfer;  and  connection  release.
 Figure 2 illustrates schematically the  sequence  of  operations
 associated with connection-oriented interactions.   In  addition
 to this explicitly distinguishable duration,  or  "lifetime",  a
 connection exhibits the following fundamental characteristics:

                     Connection Establishment
                     ------------------------

       - Successful -                        - Unsuccessful -


  (N)-  |          |                     (N)-  |          |
connect |          |(N)-connect        connect |          |  (N)-
------->|          |indication         ------->|          | connect
request |          |                   request |          |indication
        |          |------->                   |          |------->
        |(N)-LAYER |                           |(N)-LAYER |
  (N)-  |          |<-------            (N)-   |          |<-------
connect |          |                disconnect |          |  (N)-
<-------|          |(N)-connect        <-------|          |disconnect
confirm |          | response       indication |          | request
        |          |                           |          |



                          Data Transfer
                          -------------

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



                        Connection Release
                        ------------------

     - User Initiated -                   - Provider Initiated -


(N)-dis |          |                           |          |
connect |          |                     (N)-  |          |  (N)-
------->|(N)-LAYER |(N)-disconnect   disconnect|(N)-LAYER |disconnect
request |          |indication         <-------|          |------->
        |          |------->         indication|          |indication
        |          |                           |          |




            FIGURE 2 - Connection Oriented Interaction

Connectionless Data Transmission, Rev. 1.00




         [Note: Much of the material in this  section  is
         derived from reference 3]


 1.  Prior negotiation.

 In a connection-oriented interaction,  no  connection  is  esta-
 blished - and no data are transferred - until all parties  agree
 on the set of parameters and options that will govern  the  data
 transfer.  An incoming connection establishment request  can  be
 rejected if it asserts parameter  values  or  options  that  are
 unacceptable to the receiver, and the receiver may in many cases
 suggest alternative parameter values and options along with  his
 rejection.

 The reason for negotiation during  connection  establishment  is
 the assumption that each party  must  reserve  or  allocate  the
 resources (such as buffers and channels) that will  be  required
 to carry out data transfer operations  on  the  new  connection.
 Negotiation provides an opportunity to scuttle the establishment
 of a connection when the resources that  would  be  required  to
 support it cannot be dedicated, or to propose alternatives  that
 could be supported by the available resources.

 2.  Three-party Agreement.

 The fundamental nature of a connection involves establishing and
 dynamically maintaining a three-party agreement  concerning  the
 transfer of data.  The three parties -  the  two  (N+1)-entities
 that wish to communicate, and the (N)-service that provides them
 with a connection - must first agree on their mutual willingness
 to participate  in  the  transfer  (see  above).   This  initial
 agreement establishes a connection.  Thereafter, for as long  as
 the connection persists, they must  continue  to  agree  on  the
 acceptance of each data unit transferred  over  the  connection.
 "With a connection, there is no  possibility  of  data  transfer
 through an unwilling service to an  unwilling  partner,  because
 the mutual willingness  must  be  established  before  the  data
 transfer can take place,  and  data  must  be  accepted  by  the
 destination partner; otherwise, no  data  [are]  transferred  on
 that connection."[3]

 3.  Connection Identifiers.

 At   connection   establishment   time,    each    participating
 (N+1)-entity is identified to the (N)-service by an (N)-address;
 the (N)-service uses these addresses to  set  up  the  requested
 connection.  Subsequent  requests  to  transfer  data  over  the
 connection (or to release it) refer not to  the  (N)-address(es)
 of the intended recipient(s), but  to  a  connection  identifier

Connectionless Data Transmission, Rev. 1.00



 supplied   by   the   (N)-service   (in   OSI    parlance,    an
 "(N)-connection-endpoint-identifier").       This      is      a
 locally-significant "shorthand" reference that uniquely  identi-
 fies an established connection during its lifetime.   Similarly,
 the protocol units that carry  data  between  systems  typically
 include a mutually-understood logical identifier rather than the
 actual addresses of the correspondents.  This technique elimina-
 tes the overhead that would otherwise  be  associated  with  the
 resolution and transmission of addresses on every data transfer.
 In some  cases,  however  -  particularly  when  non-homogeneous
 networks are interconnected, and very location-sensitive addres-
 sing schemes are used - it can  make  dynamic  routing  of  data
 units extremely difficult, if not impossible.

 4.  Data Unit Relationship.

 Once a connection has  been  established,  it  may  be  used  to
 transfer one data unit after another, until  the  connection  is
 released by one of the three  parties.   These  data  units  are
 logically related to  each  other  simply  by  virtue  of  being
 transferred on  the  same  connection.   Since  data  units  are
 transferred over a connection  in  sequence,  they  are  related
 ordinally as well.  These data unit relationships are an  impor-
 tant characteristic of connections, since they create a  context
 for the interpretation of arriving data units that  is  indepen-
 dent of the data themselves.  Because a connection maintains the
 sequence  of  messages  associated  with  it,   out-of-sequence,
 missing, and duplicated messages  can  easily  be  detected  and
 recovered, and flow control techniques can be invoked to  ensure
 that the message transfer rate does not exceed  that  which  the
 correspondents are capable of handling.


 These  characteristics  make  connection-based   data   transfer
 attractive in applications that call for relatively  long-lived,
 stream-oriented interactions in stable configurations,  such  as
 direct terminal use of a remote  computer,  file  transfer,  and
 long-term attachments of remote job  entry  stations.   In  such
 applications, the interaction between communicating entities  is
 modelled very well  by  the  connection  concept:  the  entities
 initially discuss their requirements and agree to the  terms  of
 their interaction, reserving whatever resources they will  need;
 transfer a series of related  data  units  to  accomplish  their
 mutual objective; and explicitly end their interaction,  releas-
 ing the previously reserved resources.


 2.2  Connectionless Data Transmission


 In many other applications,  however,  the  interaction  between

Connectionless Data Transmission, Rev. 1.00



 entities is more naturally modelled by the  connectionless  data
 transmission concept,  which  involves  the  transmission  of  a
 single self-contained data  unit  from  one  entity  to  another
 without prior negotiation or  agreement,  and  without  the  as-
 surance of delivery normally  associated  with  connection-based
 transfers.  The users of a connectionless  (N)-service  may,  of
 course, use their (N+1)-protocol to make any  prior  or  dynamic
 arrangements they wish concerning their  interpretation  of  the
 data transmitted and received; the (N)-service itself,  however,
 attaches no significance to individual data units, and does  not
 attempt to relate them in any way.  Two (N+1)-entities  communi-
 cating by means  of  a  connectionless  (N)-service  could,  for
 example, apply whatever techniques they  might  consider  appro-
 priate  in  the  execution  of  their  own   protocol   (timers,
 retransmission, positive or negative acknowledgements,  sequence
 numbers, etc.) to achieve the level of  error  detection  and/or
 recovery they desired.  Users of a connectionless, as opposed to
 connection-oriented, (N)-service are not restricted or inhibited
 in the performance of their (N+1)-protocol;  obviously,  though,
 the assumption is that CDT  will  be  used  in  situations  that
 either do not require the characteristics of  a  connection,  or
 actively benefit from the alternative characteristics of connec-
 tionless transmission.

 Figure 3 illustrates schematically the single operation  whereby
 a connectionless service may be employed to  transmit  a  single
 data unit.   Figure  4  shows  a  widely-implemented  variation,
 sometimes called  "reliable  datagram"  service,  in  which  the
 service  provider  undertakes  to  confirm   the   delivery   or
 non-delivery of each data unit.  It must be emphasized that this
 is not a true connectionless service, but is  in  some  sense  a
 hybrid, combining the delivery assurance of  connection-oriented