RFC 983 (rfc983) - Page 2 of 27
ISO transport arrives on top of the TCP
Alternative Format: Original Text Document
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,RFC 791]), 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