rfc983.txt

RFC 的详细文档！

Network Working Group                                  D. E. Cass (NRTC)
Request for Comments: 983                              M. T. Rose (NRTC)
                                                              April 1986

                ISO Transport Services on Top of the TCP


Status of This Memo

   This memo describes a proposed protocol standard for the ARPA
   Internet community.  The intention is that hosts in the ARPA-Internet
   that choose to implement ISO TSAP services on top of the TCP be
   expected to adopt and implement this standard.  Suggestions for
   improvement are encouraged.  Distribution of this memo is unlimited.

1.  Introduction and Philosophy

   The ARPA Internet community has a well-developed, mature set of
   transport and internetwork protocols (TCP/IP), which are quite
   successful in offering network and transport services to end-users.
   The CCITT and the ISO have defined various session, presentation, and
   application recommendations which have been adopted by the
   international community and numerous vendors.  To the largest extent
   possible, it is desirable to offer these higher level services
   directly in the ARPA Internet, without disrupting existing
   facilities.  This permits users to develop expertise with ISO and
   CCITT applications which previously were not available in the ARPA
   Internet.  It also permits a more graceful transition strategy from
   TCP/IP-based networks to ISO-based networks in the medium- and
   long-term.

   There are two basic approaches which can be taken when "porting" an
   ISO or CCITT application to a TCP/IP environment.  One approach is to
   port each individual application separately, developing local
   protocols on top of the TCP.  Although this is useful in the
   short-term (since special-purpose interfaces to the TCP can be
   developed quickly), it lacks generality.

   A second approach is based on the observation that both the ARPA
   Internet protocol suite and the ISO protocol suite are both layered
   systems (though the former uses layering from a more pragmatic
   perspective).  A key aspect of the layering principle is that of
   layer-independence.  Although this section is redundant for most
   readers, a slight bit of background material is necessary to
   introduce this concept.

   Externally, a layer is defined by two definitions:

      a service-offered definition, which describes the services
      provided by the layer and the interfaces it provides to access
      those services; and,


Cass & Rose                                                     [Page 1]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


      a service-required definitions, which describes the services used
      by the layer and the interfaces it uses to access those services.

   Collectively, all of the entities in the network which co-operate to
   provide the service are known as the service-provider. Individually,
   each of these entities is known as a service-peer.

   Internally, a layer is defined by one definition:

      a protocol definition, which describes the rules which each
      service-peer uses when communicating with other service-peers.

   Putting all this together, the service-provider uses the protocol and
   services from the layer below to offer the its service to the layer
   above.  Protocol verification, for instance, deals with proving that
   this in fact happens (and is also a fertile field for many Ph.D.
   dissertations in computer science).

   The concept of layer-independence quite simply is:

      IF one preserves the services offered by the service-provider

      THEN the service-user is completely naive with respect to the
      protocol which the service-peers use

   For the purposes of this memo, we will use the layer-independence to
   define a Transport Service Access Point (TSAP) which appears to be
   identical to the services and interfaces offered by the ISO/CCITT
   TSAP (as defined in [ISO-8072]), but we will base the internals of
   this TSAP on TCP/IP (as defined in [RFC-793,RFC791]), not on the
   ISO/CCITT transport and network protocols.  Hence, ISO/CCITT higher
   level layers (all session, presentation, and application entities)
   can operate fully without knowledge of the fact that they are running
   on a TCP/IP internetwork.

   The authors hope that the preceding paragraph will not come as a
   shock to most readers.  However, an ALARMING number of people seem to
   think that layering is just a way of cutting up a large problem into
   smaller ones, *simply* for the sake of cutting it up.  Although
   layering tends to introduce modularity into an architecture, and
   modularity tends to introduce sanity into implementations (both
   conceptual and physical implementations), modularity, per se, is not
   the end goal.  Flexibility IS.






Cass & Rose                                                     [Page 2]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


2.  Motivation

   In migrating from the use of TCP/IP to the ISO protocols, there are
   several strategies that one might undertake.  This memo was written
   with one particular strategy in mind.

   The particular migration strategy which this memo uses is based on
   the notion of gatewaying between the TCP/IP and ISO protocol suites
   at the transport layer.  There are two strong arguments for this
   approach:

      a.  Experience teaches us that it takes just as long to get good
      implementations of the lower level protocols as it takes to get
      good implementations of the higher level ones.  In particular, it
      has been observed that there is still a lot of work being done at
      the ISO network and transport layers.  As a result,
      implementations of protocols above these layers are not being
      aggressively pursued. Thus, something must be done "now" to
      provide a medium in which the higher level protocols can be
      developed.  Since TCP/IP is mature, and essentially provides
      identical functionality, it is an ideal medium to support this
      development.

      b.  Implementation of gateways at the IP and ISO IP layers are
      probably not of general use in the long term.  In effect, this
      would require each Internet host to support both TP4 and TCP.  As
      such, a better strategy is to implement a graceful migration path
      from TCP/IP to ISO protocols for the ARPA Internet when the ISO
      protocols have matured sufficiently.

   Both of these arguments indicate that gatewaying should occur at or
   above the transport layer service access point.  Further, the first
   argument suggests that the best approach is to perform the gatewaying
   exactly AT the transport service access point to maximize the number
   of ISO layers which can be developed.

      NOTE:  This memo does not intend to act as a migration or
      intercept document.  It is intended ONLY to meet the needs
      discussed above.  However, it would not be unexpected that the
      protocol described in this memo might form part of an overall
      transition plan.  The description of such a plan however is
      COMPLETELY beyond the scope of this memo.

   Finally, in general, building gateways between other layers in the
   TCP/IP and ISO protocol suites is problematic, at best.

   To summarize: the primary motivation for the standard described in


Cass & Rose                                                     [Page 3]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


   this memo is to facilitate the process of gaining experience with
   higher-level ISO protocols (session, presentation, and application).
   The stability and maturity of TCP/IP are ideal for providing solid
   transport services independent of actual implementation.

3.  The Model

   The [ISO-8072] standard describes the ISO transport service
   definition, henceforth called TP.

      ASIDE:  This memo references the ISO specifications rather than
      the CCITT recommendations.  The differences between these parallel
      standards are quite small, and can be ignored, with respect to
      this memo, without loss of generality.  To provide the reader with
      the relationships:

         Transport service      [ISO-8072]      [X.214]
         Transport protocol     [ISO-8073]      [X.224]
         Session protocol       [ISO-8327]      [X.225]

   The ISO transport service definition describes the services offered
   by the TS-provider (transport service) and the interfaces used to
   access those services.  This memo focuses on how the ARPA
   Transmission Control Protocol (TCP) [RFC-793] can be used to offer
   the services and provide the interfaces.

   +-------------+                                      +-------------+
   |   TS-user   |                                      |   TS-user   |
   +-------------+                                      +-------------+
           |                                                   |
           | TSAP interface                     TSAP interface |
           |  [ISO-8072]                                       |
           |                                                   |
   +------------+   ISO Transport Services on the TCP    +------------+
   |   client   |----------------------------------------|   server   |
   +------------+              (this memo)               +------------+
           |                                                   |
           | TCP interface                       TCP interface |
           |  [RFC-793]                                        |
           |                                                   |

   For expository purposes, the following abbreviations are used:

      TS-peer           a process which implements the protocol
                        described by this memo




Cass & Rose                                                     [Page 4]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


      TS-user           a process talking using the services of a
                        TS-peer

      TS-provider       the black-box entity implementing the protocol
                        described by this memo

   For the purposes of this memo, which describes version 1 of the TSAP
   protocol, all aspects of [ISO-8072] are supported with one exception:

      Quality of Service parameters

   In the spirit of CCITT, this is left "for further study".  Version 2
   of the TSAP protocol will most likely support the QOS parameters for
   TP by mapping these onto various TCP parameters.

   Since TP supports the notion of a session port (termed a TSAP ID),
   but the list of reserved ISO TSAP IDs is not clearly defined at this
   time, this memo takes the philosophy of isolating the TCP port space
   from the TSAP ID space and uses a single TCP port.  This memo
   reserves TCP port 102 for this purpose.  This protocol manages its
   own TSAP ID space independent of the TCP.  Appendix A of this memo
   lists reserved TSAP IDs for version 1 of this TSAP protocol.  It is
   expected that future editions of the "Assigned Numbers" document
   [RFC-960] will contain updates to this list.  (Interested readers are
   encouraged to read [ISO-8073] and try to figure out exactly what a
   TSAP ID is.)

   Finally, the ISO TSAP is fundamentally symmetric in behavior.  There
   is no underlying client/server model.  Instead of a server listening
   on a well-known port, when a connection is established, the
   TS-provider generates an INDICATION event which, presumably the
   TS-user catches and acts upon.  Although this might be implemented by
   having a server "listen" by hanging on the INDICATION event, from the
   perspective of the ISO TSAP, all TS-users just sit around in the IDLE
   state until they either generate a REQUEST or accept an INDICATION.














Cass & Rose                                                     [Page 5]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


4.  The Primitives

   The protocol assumes that the TCP [RFC-793] offers the following
   service primitives:

   Events

      connected       - open succeeded (either ACTIVE or PASSIVE)

      connect fails   - ACTIVE open failed

      data ready      - data can be read from the connection

      errored         - the connection has errored and is now closed

      closed          - an orderly disconnection has started

   Actions

      listen on port  - PASSIVE open on the given port

      open port       - ACTIVE open to the given port

      read data       - data is read from the connection

      send data       - data is sent on the connection

      close           - the connection is closed (pending data is sent)

   The protocol offers the following service primitives, as defined in
   [ISO-8072], to the TS-user:

   Events

      T-CONNECT.INDICATION

         - a TS-user (server) is notified that connection establishment
           is in progress

      T-DISCONNECT.INDICATION

         - a TS-user is notified that the connection is closed

      T-CONNECT.CONFIRMATION

         - a TS-user (client) is notified that the connection has been
           established


Cass & Rose                                                     [Page 6]



RFC 983                                                       April 1986
ISO Transport Services on Top of the TCP


      T-DATA.INDICATION

         - a TS-user is notified that data can be read from the
           connection

      T-EXPEDITED DATA.INDICATION

         - a TS-user is notified that "expedited" data can be read from
           the connection

   Actions

      T-CONNECT.RESPONSE

         - a TS-user (server) indicates that it will honor the request

      T-DISCONNECT.REQUEST

         - a TS-user indicates that the connection is to be closed

      T-CONNECT.REQUEST

         - a TS-user (client) indicates that it wants to establish a
           connection

      T-DATA.REQUEST

         - a TS-user sends data

      T-EXPEDITED DATA.REQUEST

         - a TS-user sends "expedited" data