rfc1008.txt

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

   since the TPE must handle all classes.  Also, if the TPMs can be
   made to truly run in parallel, the performance may be greatly
   enhanced.

   The decoding of received TPDUs is partially described in the Class 4
   TPM description.  Only the CR and CC TPDUs present any problems in
   decoding, and these are largely due to the nondeterministic order of
   parameters in the variable part of the TPDU headers and the
   locality-and class-dependent content of this variable part.  Since
   contents of this variable part (except the TSAP-IDs) do not affect
   the association of the TPDU with a transport connection, the
   decoding of the variable part is not described in detail.  Such a
   description would be very lengthy indeed because of all the
   possibilities and would not contribute measurably to understanding
   by the reader.

1.2.4   Network Slave.

   The primary functions of the Network Slave are to provide downward
   flow control in the TPE, to concatenate TPDUs into a single NSDU and
   to respond to the receipt of spurious TPDUs.  The Slave has an
   internal queue on which it keeps TPDUs until the network is ready to
   accept them for transmission.  The TPE is kept informed as to the
   length of queue, and the output of the TPMs is throttled if the
   length exceeds this some threshold.  This threshold can be adjusted
   to meet current operating conditions.  The Slave will concatenate
   the TPDUs in its queue if the option to concatenate is exercised and
   the conditions for concatenating are met.  Concatenation is a TPE
   option, which may be exercised or not at any time.

1.2.5   Timers.

   In the formal description timers are all modeled using a spontaneous
   transition with delay, where the delay parameter is the timer period.
   To activate the timer, a timer identifier is placed into a set,
   thereby satisfying a predicate of the form

   provided timer_x in active_timers

   However, the transition code is not executed until the elapsed time
   ;from the placement of the identifier in the set is at least equal
   to the delay parameter.  The editors of the formal description chose
   to model timers in this fashion because it provided a simply
   expressed description of timer behavior and eliminated having to
   consider how timing is done in a real system or to provide special
   timer modules and communication to them.  It is thus recommended that
   implementors not follow the timer model closely in implementations,
   considering instead the simplest and most efficient means of timing
   permitted by the implementation environment.  Implementors should



McCoy                                                          [Page 15]

RFC 1008                                                       June 1987


   also note that the delay parameter is typed "integer" in the formal
   description. No scale conversion from actual time is expressed in the
   timer transition, so that this scale conversion must be considered
   when timers are realized.

1.2.5.1   Transport Protocol Entity timers.

   There is only one timer given in the formal description of the
   TPE--the reference timer.  The reference timer was placed here ;so
   that it can be used by all classes and all connections, as needed.
   There is actually little justification for having a reference timer
   within the TPM--it wastes resources by holding the transport
   endpoint, even though the TPM is incapable of responding to any
   input.  Consequently, the TPE is responsible for all aspects of
   reference management, including the timeouts.

1.2.5.2   Transport Protocol Machine timers.

   Class 2 transport does not have any timers that are required by IS
   8073.  However, the standard does recommend that an optional timer be
   used by Class 2 in certain cases to avoid deadlock.  The formal
   description provides this timer, with comments to justify its usage.
   It is recommended that such a timer be provided for Class 2
   operation.  Class 4 transport has several timers for connection
   control, flow control and retransmissions of unacknowledged data.
   Each of these timers is discussed briefly below in terms of how they
   were related to the Class 4 operations in the formal description.
   Further discussion of these timers is given in Part 8.

1.2.5.2.1   Window timer.

   The window timer is used for transport connection control as well as
   providing timely updates of flow control credit information.  One of
   these timers is provided in each TPM.   It is reset each time an AK
   TPDU is sent, except during fast retransmission of AKs for flow
   control confirmation, when it is disabled.

1.2.5.2.2   Inactivity timer.

   The primary usage of the inactivity timer is to detect when the
   remote peer has ceased to send anything (including AK TPDUs).  This
   timer is mandatory when operating over a connectionless network
   service, since there is no other way to determine whether or not the
   remote peer is still functioning.  On a connection-oriented network
   service it has an additional usage since to some extent the continued
   existence of the network connection indicates that the peer host has
   not crashed.

   Because of splitting, it is useful to provide an inactivity timer on
   each network connection to which a TPM is assigned.  In this manner,
   if a network connection is unused for some time, it can be released,



McCoy                                                          [Page 16]

RFC 1008                                                       June 1987


   even though a TPM assigned to it continues to operate over other
   network connections. The formal description provides this capability
   in each TPM.

1.2.5.2.3   Network connection timer.

   This timer is an optional timer used to ensure that every network
   connection to which a TPM is assigned gets used periodically.  This
   prevents the expiration of the peer entity's inactivity timer for a
   network connection.  There is one timer for each network connection
   to which the TPM is assigned.  If there is a DT or ED TPDU waiting to
   be sent, then it is chosen to be sent on the network connection.  If
   no such TPDU is waiting, then an AK TPDU is sent.  Thus, the NC timer
   serves somewhat the same purpose as the window timer, but is broader
   in scope.

1.2.5.2.4   Give-up timer.

   There is one give-up timer for a TPM which is set whenever the
   retransmission limit for any CR, CC, DT, ED or DR TPDU is reached.
   Upon expiration of this timer, the transport connection is closed.

1.2.5.2.5   Retransmission timers.

   Retransmission timers are provided for CR, CC, DT, ED and DR TPDUs.
   The formal description provides distinct timers for each of these
   TPDU types, for each TPM.  However, this is for clarity in the
   description, and Part 8.2.5 presents arguments for other strategies
   to be used in implementations.  Also, DT TPDUs with distinct sequence
   numbers are each provided with timers, as well.  There is a primitive
   function which determines the range within the send window for which
   timers will be set.  This has been done to express flexibility in the
   retransmission scheme.

   The flow control confirmation scheme specified in IS 8073 also
   provides for a "fast" retransmission timer to ensure the reception of
   an AK TPDU carrying window resynchronization after credit reduction
   or when opening a window that was previously closed.  The formal
   description permits one such timer for a TPM.  It is disabled after
   the peer entity has confirmed the window information.

1.2.5.2.6   Error transport protocol data unit timer.

   In IS 8073, there is a provision for an optional timeout to limit the
   wait for a response by the peer entity to an ER TPDU.  When this
   timer expires, the transport connection is terminated.  Each Class 2
   or Class 4 TPM is provided with one of these timers in N3756.

1.2.6   End-to-end Flow Control.

   Flow control in the formal description has been written in such a way



McCoy                                                          [Page 17]

RFC 1008                                                       June 1987


   as to permit flexibility in credit control schemes and
   acknowledgement strategies.

1.2.6.1   Credit control.

   The credit mechanism in the formal description provides for actual
   management of credit by the TPE.  This is done through variables
   exported by the TPMs which indicate to the TPE when credit is needed
   and for the TPE to indicate when credit has been granted.  In this
   manner, the TPE has control over the credit a TPM has.  The mechanism
   allows for reduction in credit (Class 4 only) and the possibility of
   precipitous window closure.  The mechanism does not preclude the use
   of credit granted by the user or other sources, since credit need is
   expressed as current credit being less than some threshold.  Setting
   the threshold to zero permits these other schemes.  An AK TPDU is
   sent each time credit is updated.

   The end-to-end flow control is also coupled to the interface flow
   control to the user.  If the user has blocked the interface up-flow,
   then the TPM is prohibited from requesting more credit when the
   current window is used up.

1.2.6.2   Acknowledgement.

   The mechanism for acknowledging normal data provides flexibility
   sufficient to send an AK TPDU in response to every Nth DT TPDU
   received where N > 0 and N may be constant or dynamically determined.
   Each TPM is provided with this, independent of all other TPMs, so
   that acknowledgement strategy can be determined separately for each
   transport connection.  The capability of altering the acknowledgement
   strategy is useful in operation over networks with varying error
   rates.

1.2.6.3  Sequencing of received data.

   It is not specified in IS 8073 what must be done with out-of-sequence
   but within-window DT TPDUs received, except that an AK TPDU with
   current window and sequence information be sent.  There are
   performance reasons why such DT TPDUs should be held (cached): in
   particular, avoidance of retransmissions.  However, this buffering
   scheme is complicated to implement and worse to describe formally
   without resorting to mechanisms too closely resembling
   implementation.  Thus, the formal description mechanism discards such
   DT TPDUs and relies on retransmission to fill the gaps in the window
   sequence, for the sake of simplicity in the description.

1.2.7   Expedited data.

   The transmission of expedited data, as expressed by IS 8073, requires
   the blockage of normal data transmission until the acknowledgement is
   received.  This is handled in the formal description by providing a



McCoy                                                          [Page 18]

RFC 1008                                                       June 1987


   special state in which normal data transmission cannot take place.
   However, recent experiments with Class 4 transport over network
   services with high bandwidth, high transit delay and high error
   rates, undertaken by the NBS and COMSAT Laboratories, have shown that
   the protocol suffers a marked decline in its performance in such
   conditions.  This situation has been presented to ISO, with the
   result that the the protocol will be modified to permit the sending
   of normal data already accepted by the transport entity from the user
   before the expedited data request but not yet put onto the network.
   When the modification is incorporated into IS 8073, the formal
   description will be appropriately aligned.


2   Environment of implementation.

   The following sections describe some general approaches to
   implementing the transport protocol and the advantages and
   disadvantages of each.  Certain commercial products are identified
   throughout the rest of this document.  In no case does such
   identification imply the recommendation or endorsement of these
   products by the Department of Defense, nor does it imply that the
   products identified are the best available for the purpose described.
   In all cases such identification is intended only to illustrate the
   possibility of implementation of an idea or approach.  UNIX is a
   trademark of AT&T Bell Laboratories.

   Most of the discussions in the remainder of the document deal with
   Class 4 exclusively, since there are far more implementation issues
   with Class 4 than for Class 2.  Also, since Class 2 is logically a
   special case of Class 4, it is possible to implement Class 4 alone,
   with special provisions to behave as Class 2 when necessary.

2.1   Host operating system program.

   A common method of implementing the OSI transport service is to
   integrate the required code into the specific operating system
   supporting the data communications applications.  The particular
   technique for integration usually depends upon the structure and
   facilities of the operating system to be used.  For example, the
   transport software might be implemented in the operating system
   kernel, accessible through a standard set of system calls.  This
   scheme is typically used when implementing transport for the UNIX
   operating system.  Class 4 transport has been implemented using this