rfc1008.txt

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

McCoy                                                           [Page 5]

RFC 1008                                                       June 1987


             *
             *
             *

   The symbol "X" represents a logical association through variables,
   and the denotations

           <<<<<<<

           >>>>>>>

              V
              V
              V

   indicate the passage of data, in the direction of the symbol
   vertices, by way of these associations.  The acronyms TSAP and
   NSAP denote Transport Service Access Point and Network Service
   Access Point, respectively.  The structure of the TSAPs and
   NSAPs shown is discussed further on, in Parts 1.2.2.1 and
   1.2.2.2.


             |<-----------------TSAP---------------->|
   ----------O---------O---------O---------O---------O---------
   |  TPE    *                   *         *                  |
   |         *                   *         *                  |
   |     ____O____           ____O____ ____O____              |
   |     |       |           |       | |       |              |
   |     |  TPM  |           |  TPM  | |  TPM  |              |
   |     |       |           |       | |       |              |
   |     |___X___|           |__X_X__| |___X___|              |
   |         V                  V V        V                  |
   |         V   multiplex      V V        V                  |
   |         >>>>>>>> <<<<<<<<<<< V        V                  |
   |                V V     split V        V                  |
   |                V V           V        V                  |
   |              ---X----     ---X---- ---X----              |
   |              |Slave |     |Slave | |Slave |              |
   |              |__O___|     |__O___| |__O___|              |
   |                 V            V        V                  |
   |                 V            V        V                  |
   |-----------------O------------O--------O------------------|
                   NSAP           |<------>|


                               NSAP







McCoy                                                           [Page 6]

RFC 1008                                                       June 1987


   The structuring principles of Estelle provide a formal means of
   expressing and enforcing certain synchronization properties between
   communicating processes.  It must be stressed that the scheduling
   implied by Estelle descriptions need not and in some cases should
   not be implemented.  The intent of the structure in the transport
   formal description is to state formally the synchronization of
   access tovariables shared by the transport entity and the transport
   connection endpoints and to permit expression of dynamic objects
   within the entity.  In nearly all aspects of operation except these,
   it may be more efficient in some implementation environments to
   permit the TPE and the TPMs to run in parallel (the Estelle
   scheduling specifically excludes the parallel operation of the TPE
   and the TPMs). This is particularly true of internal management
   ("housekeeping") actions and those actions not directly related to
   communication between the TPE and the TPMs or instantiation of TPMs.
   Typical actions of this latter sort are: receipt of NSDUs from the
   network, integrity checking and decoding of TPDUs, and network
   connection management. Such actions could have been collected into
   other modules for scheduling closer to that of an implementation,
   but surely at the risk of further complicating the description.
   Consequently, the formal description structure should be understood
   as expressing relationships among actions and objects and not
   explicit implementation behavior.

1.2.1.2   Transport protocol entity operation.

   The details of the operation of the TPE from a conceptual point of
   view are given in the SYS section of the formal description.
   However, there are several further comments that can be made
   regarding the design of the TPE.  The Estelle body for the TPE
   module has no state variable.  This means that any transition of
   the TPE may be enabled and executed at any time.  Choice of
   transition is determined primarily by priority.  This suggests
   that the semantics of the TPE transitions is that of interrupt
   traps.

   The TPE handles only the T-CONNECT-request from the user and the TPM
   handle all other user input.  All network events are handled by the
   TPE, in addition to resource management to the extent defined in the
   description.  The TPE also manages all aspects of connection
   references, including reference freezing.  The TPE does not
   explicitly manage the CPU resource for the TPMs, since this is
   implied by the Estelle scheduling across the module hierarchy.
   Instantiation of TPMs is also the responsibility of the TPE, as is
   TPM release when the transport connection is to be closed.  Once a
   TPM is created, the TPE does not in general interfere with TPM's
   activities, with the following exceptions:  the TPE may reduce credit
   to a Class 4 TPM without notice;  the TPE may dissociate a Class 4
   TPM from a network connection when splitting is being used.
   Communication between the TPE and the TPMs is through a set of
   exported variables owned by the TPMs, and through a channel which



McCoy                                                           [Page 7]

RFC 1008                                                       June 1987


   passes TPDUs to be transmitted to the remote peer.  This channel is
   not directly connected to any network connection, so each
   interaction on it carries a reference number indicating which network
   connection is to be used. Since the reference is only a reference,
   this permits usage of this mechanism when the network service is
   connectionless, as well.  The mechanism provides flexibility for
   both splitting and multiplexing on network connections.

   One major function that the TPE performs for all its TPMs is that of
   initial processing of received TPDUs.  First, a set of integrity
   checks is made to determine if each TPDU in an NSDU is decodable:


     a.   PDU length indicators and their sums are checked against the
          NSDU length for consistency;

     b.   TPDU types versus minimum header lengths for the types are
          checked, so that if the TPDU can be decoded, then proper
          association to TPMs can be made without any problem;

     c.   TPDUs are searched for checksums and the local checksum is
          computed for any checksum found; and


     d.   parameter codes in variable part of headers are checked where
          applicable.

   These integrity checks guarantee that an NSDU passing the check can
   be separated as necessary into TPDUs, these TPDUs can be associated
   to the transport connections or to the Slave as appropriate and they
   can be further decoded without error.

   The TPE next decodes the fixed part of the TPDU headers to determine
   the disposition of the TPDU.  The Slave gets TPDUs that cannot be
   assigned to a TPM (spurious TPDU).  New TPMs are created in response
   to CR TPDUs that correspond to a TSAP for this TPE.

   All management of NSAPs is done by the TPE.  This consists of keeping
   track of all network connections, their service quality
   characteristics and their availability, informing the TPMs associated
   with these network connections.

   The TPE has no timer module as such.  Timing is handled by using the
   DELAY feature of Estelle, since this feature captures the essence of
   timing without specifying how the actual timing is to be achieved
   within the operating environment.  See Part 1.2.5 for more details.

1.2.2   Service Access Points.

   The service access points (SAP) of the transport entity are modeled
   using the Estelle channel/interaction point formalism.  (Note: The



McCoy                                                           [Page 8]

RFC 1008                                                       June 1987


   term "channel" in Estelle is a keyword that denotes a set of
   interactions which may be exchanged at interaction points [LIN85].
   However, it is useful conceptually to think of "channel" as denoting
   a communication path that carries the interactions between modules.)
   The abstract service primitives for a SAP are interactions on
   channels entering and leaving the TPE.  The transport user is
   considered to be at the end of the channel connected to the transport
   SAP (TSAP) and the network service provider is considered to be at
   the end of the channel connected to the network SAP (NSAP).  An
   interaction put into a channel by some module can be considered to
   move instantaneously over the channel onto a queue at the other end.
   The sender of such an interaction no longer has access to the
   interaction once it has been put into the channel.  The operation of
   the system modeled by the formal description has been designed with
   this semantics in mind, rather than the equivalent but much more
   abstract Estelle semantics.  (In the Estelle semantics, each
   interaction point is considered to have associated with it an
   unbounded queue.  The "attach" and "connect" primitives bind two
   interaction points, such that an action, implied by the keyword
   "out", at one interaction point causes a specified interaction to be
   placed onto the queue associated with the other interaction point.)
   The sections that follow discuss the TSAP and the NSAP and the way
   that these SAPs are described in the formal description.

1.2.2.1   Transport Service Access Point.

   The international transport standard allows for more than one TSAP to
   be associated with a transport entity, and multiple users may be
   associated with a given TSAP.  A situation in which this is useful is
   when it is desirable to have a certain quality of service correlated
   with a given TSAP.  For example, one TSAP could be reserved for
   applications requiring a high throughput, such as file transfer.  The
   operation of transport connections associated with this TSAP could
   then be designed to favor throughput.  Another TSAP might serve users
   requiring short response time, such as terminals.  Still another TSAP
   could be reserved for encryption reasons.

   In order to provide a way of referencing users associated with TSAPs,
   the user access to transport in the formal description is through an
   array of Estelle interaction points.  This array is indexed by a TSAP
   address (T_address) and a Transport Connection Endpoint Identifier
   (TCEP_id).  Note that this dimensional object (TSAP) is considered
   simply to be a uniform set of abstract interfaces.  The indices must
   be of (Pascal) ordinal type in Estelle.  However, the actual address
   structure of TSAPs may not conform easily to such typing in an
   implementation.  Consequently, the indices as they appear in the
   formal description should be viewed as an organizational mechanism
   rather than as an explicit way of associating objects in an
   operational setting.  For example, actual TSAP addresses might be
   kept in some kind of table, with the table index being used to
   reference objects associated with the TSAP.



McCoy                                                           [Page 9]

RFC 1008                                                       June 1987


   One particular issue concerned with realizing TSAPs is that of making
   known to the users the means of referencing the transport interface,
   i.e., somehow providing the T_addresses and TCEP_ids to the users.
   This issue is not considered in any detail by either IS 7498 [ISO84b]
   or IS 8073.  Abstractly, the required reference is the
   T_address/TCEP_id pair.  However, this gives no insight as to how the
   mechanism could work.  Some approaches to this problem are discussed
   in Part 5.

   Another issue is that of flow control on the TSAP channels.  Flow
   control is not part of the semantics for the Estelle channel, so the
   problem must be dealt with in another way.  The formal description
   gives an abstract definition of interface flow control using Pascal
   and Estelle mechanisms.  This abstraction resembles many actual
   schemes for flow control, but the realization of flow control will
   still be dependent on the way the interface is implemented.  Part 3.2
   discusses this in more detail.

1.2.2.2   Network Service Access Point.