rfc1008.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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).

   Realizations of Estelle features and mechanisms are dependent in an
   essential way upon the performance and service an implementation is
   to provide.  Implementations for operational usage have much more
   stringent requirements for optimal behavior and robustness than do
   implementations used for simulated operation (e.g., correctness or
   conformance testing).  It is thus important that an operational
   implementation realize the abstract features and mechanisms of a
   formal description in an efficient and effective manner.

   For operational usage, two useful criteria for interpretation of
   formal mechanisms are:

        [1] minimization of delays caused by the mechanism
            itself; e.g.,

               --transit delay for a medium that realizes a
                 channel

               --access delay or latency for channel medium

               --scheduling delay for timed transitions
                 (spontaneous transitions with delay clause)

               --execution scheduling for modules using
                 exported variables (delay in accessing
                 variable)

        [2] minimization of the "handling" required by each
            invocation of the mechanism; e.g.,

               --module execution scheduling and context
                 switching

               --synchronization or protocols for realized
                 channel

               --predicate evaluation for spontaneous
                 transitions

   Spontaneous transitions represent nondeterminism and indeterminism,
   so that uniform realization of them in an implementation must be
   questioned as an implementation strategy.  The time at which the
   action described by a spontaneous transition will actually take
   place cannot be specified because of one or more of the following
   situations:


     a.   it is not known when, relative to any specific event defining
          the protocol (e.g., input network, input from user, timer



McCoy                                                           [Page 3]

RFC 1008                                                       June 1987


          expirations), the conditions enabling the transition will
          actually occur;

     b.   even if the enabling conditions are ultimately deterministic,
          it is not practical to describe all the possible ways this
          could occur, given the different ways in which implementations
          will examine these conditions; and


     c.   a particular implementation may not be concerned with the
          enabling conditions or will account for them in some other
          way; i.e., it is irrelevant when the action takes place, if
          ever.

   As an example of a), consider the situation when splitting over the
   network connection, in Class 4, in which all of the network
   connections to which the transport connection has been assigned have
   all disconnected, with the transport connection still in the OPEN
   state.  There is no way to predict when this will happen, nor is
   there any specific event signalling its occurrence.  When it does
   occur, the transport protocol machine may want to attempt to obtain
   a new network connection.

   As an example of b), consider that timers may be expressed
   succinctly in Estelle by transitions similar to the following:


                 from A to B
                 provided predicate delay( timer_interval )

                 begin
                 (* action driven by timeout *)
                 end;


   But there are operations for which the timer period may need to
   be very accurate (close to real time) and others in which some
   delay in executing the action can be tolerated.  The implementor
   must determine the optimal behavior desired for each instance
   and use an appropriate mechanism to realize it, rather than
   using a uniform approach to implementing all spontaneous
   transitions.

   As an example of the situation in c), consider the closing of an
   unused network connection.  If the network is such that the cost
   of letting the network connection remain open is small compared
   cost of opening it, then an implementation might not want to
   consider closing the network connection until, say, the weekend.
   Another implementation might decide to close the network
   connection within 30 msec after discovering that the connection
   is not busy.  For still another implementation, this could be



McCoy                                                           [Page 4]

RFC 1008                                                       June 1987


   meaningless because it operates over a connectionless network
   service.

   If a description has only a very few spontaneous transitions, then
   it may be relatively easy to implement them literally (i.e., to
   schedule and execute them as Estelle abstractly does) and not
   incur the overhead from examining all of the variables that occur
   in the enabling conditions.  However, the number and complexity of
   the enabling conditions for spontaneous transitions in the transport
   description strongly suggests that an implementation which realizes
   spontaneous transitions literally will suffer badly from such
   overhead.

1.2   Guide to the formal description.

   So that implementors gain insight into interpretation of the
   mechanisms and features of the formal description of transport, the
   following paragraphs discuss the meanings of such mechanisms and
   features as intended by the editors of the formal description.

1.2.1   Transport Protocol Entity.

1.2.1.1   Structure.

   The diagram below shows the general structure of the Transport
   Protocol Entity (TPE) module, as given in the formal description.
   >From an abstract operational viewpoint, the transport protocol
   Machines (TPMs) and the Slaves operate as child processes of the the
   TPE process.  Each TPM represents the endpoint actions of the
   protocol on a single transport connection.  The Slave represents
   control of data output to the network.  The internal operations of
   the TPMs and the Slave are discussed below in separate sections.

   This structure permits describing multiple connections, multiplexing
   and splitting on network connections, dynamic existence of endpoints
   and class negotiation.  In the diagram, interaction points are
   denoted by the symbol "O", while (Estelle) channels joining these
   interaction points are denoted by