Implementation guide for the ISO Transport Protocol
RFC 1008

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                                        Wayne McCoy
Request for Comments: 1008                                     June 1987

                             IMPLEMENTATION GUIDE 

                                    FOR THE

                            ISO TRANSPORT PROTOCOL

Status of this Memo

   This RFC is being distributed to members of the Internet community
   in order to solicit comments on the Implementors Guide. While this
   document may not be directly relevant to the research problems
   of the Internet, it may be of some interest to a number of researchers
   and implementors. Distribution of this memo is unlimited.

            IMPLEMENTATION GUIDE FOR THE ISO TRANSPORT PROTOCOL

1   Interpretation of formal description.

   It is assumed that the reader is familiar with both the formal
   description technique, Estelle [ISO85a], and the transport protocol
   as described in IS 8073 [ISO84a] and in N3756 [ISO85b].

1.1   General interpretation guide.

   The development of the formal description of the ISO Transport
   Protocol was guided by the three following assumptions.

                      1. A generality principle

   The formal description is intended to express all of the behavior
   that any implementation is to demonstrate, while not being bound
   to the way that any particular implementation would realize that
   behavior within its operating context.

                      2. Preservation of the deliberate
                         nondeterminism of IS 8073

   The text description in the IS 8073 contains deliberate expressions
   of nondeterminism and indeterminism in the behavior of the
   transport protocol for the sake of flexibility in application.
   (Nondeterminism in this context means that the order of execution
   for a set of actions that can be taken is not specified.
   Indeterminism means that the execution of a given action cannot be
   predicted on the basis of system state or the executions of other
   actions.)

McCoy                                                           [Page 1]
RFC 1008                                                       June 1987

                      3. Discipline in the usage of Estelle

   A given feature of Estelle was to be used only if the nature of
   the mechanism to be described strongly indicates its usage,
   or to adhere to the generality principle, or to retain the
   nondeterminism of IS 8073.

   Implementation efficiency was not a particular goal nor was there
   an attempt to directly correlate Estelle mechanisms and features
   to implementation mechanisms and features.  Thus, the description
   does not represent optimal behavior for the implemented protocol.

   These assumptions imply that the formal description contains higher
   levels of abstraction than would be expected in a description for
   a particular operating environment.  Such abstraction is essential,
   because of the diversity of networks and network elements by which
   implementation and design decisions are influenced.  Even when
   operating environments are essentially identical, design choice and
   originality in solving a technical problem must be allowed.
   The same behavior may be expressed in many different ways.  The
   goal in producing the transport formal description was to attempt
   to capture this equivalence.  Some mechanisms of transport are not
   fully described or appear to be overly complicated because of the
   adherence to the generality principle.  Resolution of these
   situations may require significant effort on the part of the
   implementor.

   Since the description does not represent optimal behavior for the
   implemented protocol, implementors should take the three assumptions
   above into account when using the description to implement the
   protocol.  It may be advisable to adapt the standard description in
   such a way that:

     a.   abstractions (such as modules, channels, spontaneous
          transitions and binding comments) are interpreted and realized
          as mechanisms appropriate to the operating environment and
          service requirements;

     b.   modules, transitions, functions and procedures containing
          material irrelevant to the classes or options to be supported
          are reduced or eliminated as needed; and

     c.   desired real-time behavior is accounted for.

   The use in the formal description of an Estelle feature (for
   instance, "process"), does not imply that an implementation must
   necessarily realize the feature by a synonymous feature of the
   operating context.  Thus, a module declared to be a "process" in an
   Estelle description need not represent a real process as seen by a
   host operating system; "process" in Estelle refers to the

McCoy                                                           [Page 2]
RFC 1008                                                       June 1987

   synchronization properties of a set of procedures (transitions).