rfc1008.txt

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

   An NSAP may also have more than one network connection associated
   with it.  For example, the virtual circuits of X.25 correspond with
   this notion.  On the other hand, an NSAP may have no network
   connection associated with it, for example when the service at the
   NSAP is connectionless.  This certainly will be the case when
   transport operates on a LAN or over IP.  Consequently, although the
   syntactical appearance of the NSAP in the formal description is
   similar to that for the TSAP, the semantics are essentially distinct
   [NTI85].

   Distinct NSAPs can correspond or not to physically distinct networks.
   Thus, one NSAP could access X.25 service, another might access an
   IEEE 802.3 LAN, while a third might access a satellite link.  On the
   other hand, distinct NSAPs could correspond to different addresses on
   the same network, with no particular rationale other than facile
   management for the distinction.  There are performance and system
   design issues that arise in considering how NSAPs should be managed
   in such situations.  For example, if distinct NSAPs represent
   distinct networks, then a transport entity which must handle all
   resource management for the transport connections and operate these
   connections as well may have trouble keeping pace with data arriving
   concurrently from two LANs and a satellite link.  It might be a
   better design solution to separate the management of the transport
   connection resources from that of the NSAP resources and inputs, or
   even to provide separate transport entities to handle some of the
   different network services, depending on the service quality to be
   maintained.  It may be helpful to think of the (total) transport
   service as not necessarily being provided by a single monolithic
   entity--several distinct entities can reside at the transport layer
   on the same end-system.




McCoy                                                          [Page 10]

RFC 1008                                                       June 1987


   The issues of NSAP management come primarily from connection-oriented
   network services.  This is because a connectionless service is either
   available to all transport connections or it is available to none,
   representing infinite degrees of multiplexing and splitting. In the
   connection-oriented case, NSAP management is complicated by
   multiplexing, splitting, service quality considerations and the
   particular character of the network service.  These issues are
   discussed further in Part 3.4.1.  In the formal description, network
   connection management is carried out by means of a record associated
   with each possible connection and an array, associated with each TPM,
   each array member corresponding to a possible network connection.
   Since there is, on some network services, a very large number of
   possible network connections, it is clear that in an implementation
   these data structures may need to be made dynamic rather than static.
   The connection record, indexed by NSAP and NCEP_id, consists of a
   Slave module reference, virtual data connections to the TPMs to be
   associated with the network connection, a data connection (out) to
   the NSAP, and a data connection to the Slave.  There is also a
   "state" variable for keeping track of the availability of the
   connection, variables for managing the Slave and an internal
   reference number to identify the connection to TPMs.  A member of the
   network connection array associated with a TPM provides the TPM with
   status information on the network connection and input data (network)
   events and TPDUs).  A considerable amount of management of the
   network connections is provided by the formal description, including
   splitting, multiplexing, service quality (when defined), interface
   flow control, and concatenation of TPDUs. This management is carried
   out solely by the transport entity, leaving the TPMs free to handle
   only the explicit transport connection issues.  This management
   scheme is flexible enough that it can be simplified and adapted to
   handle the NSAP for a connectionless service.

   The principal issue for management of connectionless NSAPs is that of
   buffering, particularly if the data transmission rates are high, or
   there is a large number of transport connections being served.  It
   may also be desirable for the transport entity to monitor the service
   it is getting from the network.  This would entail, for example,
   periodically computing the mean transmission delays for adjusting
   timers or to exert backpressure on the transport connections if
   network access delay rises, indicating loading.  (In the formal
   description, the Slave processor provides a simple form of output
   buffer management: when its queue exceeds a threshold, it shuts off
   data from the TPMs associated with it.  Through primitive functions,
   the threshold is loosely correlated with network behavior.  However,
   this mechanism is not intended to be a solution to this difficult
   performance problem.)








McCoy                                                          [Page 11]

RFC 1008                                                       June 1987


1.2.3   Transport Protocol Machine.

   Transport Protocol Machines (TPM) in the formal description are in
   six classes: General, Class 0, Class 1, Class 2, Class 3 and Class 4.
   Only the General, Class 2 and Class 4 TPMs are discussed here.  The
   reason for this diversity is to facilitate describing class
   negotiations and to show clearly the actions of each class in the
   data transfer phase.  The General TPM is instantiated when a
   connection request is received from a transport user or when a CR
   TPDU is received from a remote peer entity.  This TPM is replaced by
   a class-specific TPM when the connect response is received from the
   responding user or when the CC TPDU is received from the responding
   peer entity.

   The General, Class 2 and Class 4 TPMs are discussed below in more
   detail.  In an implementation, it probably will be prudent to merge
   the Class 2 and Class 4 operations with that of the General TPM, with
   new variables selecting the class-specific operation as necessary
   (see also Part 9.4 for information on obtaining Class 2 operation
   from a Class 4 implementation).  This may simplify and improve the
   behavior of the implemented protocol overall.

1.2.3.1   General Transport Protocol Machine.

   Connection negotiation and establishment for all classes can be
   handled by the General Transport Protocol Machine.  Some parts of the
   description of this TPM are sufficiently class dependent that they
   can safely be removed if that class is not implemented.  Other parts
   are general and must be retained for proper operation of the TPM. The
   General TPM handles only connection establishment and negotiation, so
   that only CR, CC, DR and DC TPDUs are sent or received (the TPE
   prevents other kinds of TPDUs from reaching the General TPM).

   Since the General TPM is not instantiated until a T-CONNECT-request
   or a CR TPDU is received, the TPE creates a special internal
   connection to the module's TSAP interaction point to pass the
   T-CONNECT-request event to the TPM.  This provides automaton
   completeness according to the specfication of the protocol.  When the
   TPM is to be replaced by a class-specific TPM, the sent or received
   CC is copied to the new TPM so that negotiation information is not
   lost.

   In the IS 8073 state tables for the various classes, the majority of
   the behavioral information for the automaton is contained in the
   connection establishment phase.  The editors of the formal
   description have retained most of the information contained in the
   state tables of IS 8073 in the description of the General TPM.

1.2.3.2   Class 2 Transport Protocol Machine.

   The formal description of the Class 2 TPM closely resembles that of



McCoy                                                          [Page 12]

RFC 1008                                                       June 1987


   Class 4, in many respects.  This is not accidental, in that: the
   conformance statement in IS 8073 links Class 2 with Class 4; and the
   editors of the formal description produced the Class 2 TPM
   description by copying the Class 4 TPM description and removing
   material on timers, checksums, and the like that is not part of the
   Class 2 operation.  The suggestion of obtaining Class 2 operation
   from a Class 4 implementation, described in Part 9.4, is in fact
   based on this adaptation.

   One feature of Class 2 that does not appear in Class 4, however, is
   the option to not use end-to-end flow control.  In this mode of
   operation, Class 2 is essentially Class 0 with multiplexing.  In
   fact, the formal description of the Class 0 TPM was derived from
   Class 2 (in IS 8073, these two classes have essentially identical
   state tables).  This implies that Class 0 operation could be obtained
   from Class 2 by not multiplexing, not sending DC TPDUs, electing not
   to use flow control and terminating the network connection when a DR
   TPDU is received (expedited data cannot be used if flow control is
   not used).  When Class 2 is operated in this mode, a somewhat
   different procedure is used to handle data flow internal to the TPM
   than is used when end-to-end flow control is present.

1.2.3.3   Class 4 Transport Protocol Machine.

   Dynamic queues model the buffering of TPDUs in both the Class 4 and
   Class 2 TPMs.  This provides a more general model of implementations
   than does the fixed array representation and is easier to describe.
   Also, the fixed array representation has semantics that, carried
   into an implementation, would produce inefficiency.  Consequently,
   linked lists with queue management functions make up the TPDU
   storage description, despite the fact that pointers have a very
   implementation-like flavor.  One of the queue management functions
   permits removing several TPDUs from the head of the send queue, to
   model the acknowledgement of several TPDUs at once, as specified in
   IS 8073.  Each TPDU record in the queue carries the number of
   retransmissions tried, for timer control (not present in the Class 2
   TPDU records).

   There are two states of the Class 4 TPM that do not appear in IS
   8073. One of these was put in solely to facilitate obtaining credit
   in case no credit was granted for the CR or CC TPDU.  The other state
   was put in to clarify operations when there is unacknowledged
   expedited data outstanding (Class 2 does not have this state).

   The timers used in the Class 4 TPM are discussed below, as is the
   description of end-to-end flow control.

   For simplicity in description, the editors of the formal description
   assumed that no queueing of expedited data would occur at the user
   interface of the receiving entity.  The user has the capability to
   block the up-flow of expedited data until it is ready.  This



McCoy                                                          [Page 13]

RFC 1008                                                       June 1987


   assumption has several implications. First, an ED TPDU cannot be
   acknowledged until the user is ready to accept it.  This is because
   the receipt of an EA TPDU would indicate to the sending peer that the
   receiver is ready to receive the next ED TPDU, which would not be
   true.  Second, because of the way normal data flow is blocked by the
   sending of an ED TPDU, normal data flow ceases until the receiving
   user is ready for the ED TPDU.  This suggests that the user
   interface should employ separate and noninterfering mechanisms
   for passing normal and expedited data to the user.  Moreover,
   the mechanism for expedited data passage should be blocked only in
   dire operational conditions.  This means that receipt of expedited
   data by the user should be a procedure (transition) that operates
   at nearly the highest priority in the user process.  The alternative
   to describing the expedited data handling in this way would entail a
   scheme of properly synchronizing the queued ED TPDUs with the DT
   TPDUs received.  This requires some intricate handling of DT and ED
   sequence numbers. While this alternative may be attractive for
   implementations, for clarity in the formal description it provides
   only unnecessary complication.

   The description of normal data TSDU processing is based on the
   assumption that the data the T-DATA-request refers to is potentially
   arbitrarily long.  The semantic of the TSDU in this case is analogous
   to that of a file pointer, in the sense that any file pointer is a
   reference to a finite but arbitrarily large set of octet-strings.
   The formation of TPDUs from this string is analogous to reading the
   file in  fixed-length segments--records or blocks, for example.  The
   reassembly of TPDUs into a string is analogous to appending each TPDU
   to the tail of a file; the file is passed when the end-of-TSDU
   (end-of-file) is received.  This scheme permits conceptual buffering
   of the entire TSDU in the receiver and avoids the question of whether
   or not received data can be passed to the user before the EOT is
   received.  (The file pointer may refer to a file owned by the user,
   so that the question then becomes moot.)

   The encoding of TPDUs is completely described, using Pascal functions
   and some special data manipulation functions of Estelle (these are
   not normally part of Pascal).  There is one encoding function
   corresponding to each TPDU type, rather than a single parameterized
   function that does all of them.  This was done so that the separate
   structures of the individual types could be readily discerned, since
   the purpose of the functions is descriptive and not necessarily
   computational.

   The output of TPDUs from the TPM is guarded by an internal flow
   control flag.  When the TPDU is first sent, this flag is ignored,
   since if the TPDU does not get through, a retransmission may take
   care of it.  However, when a retransmission is tried, the flag is
   heeded and the TPDU is not sent, but the retransmission count is
   incremented.  This guarantees that either the TPDU will eventually
   be sent or the connection will time out (this despite the fact that



McCoy                                                          [Page 14]

RFC 1008                                                       June 1987


   the peer will never have received any TPDU to acknowledge).
   Checksum computations are done in the TPM rather than by the TPE,