ISO transport arrives on top of the TCP
RFC 983

Document Type RFC - Unknown (April 1986; No errata)
Obsoleted by RFC 1006
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 983 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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

   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]
Show full document text