Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

in Index   Prev   Next  

RFC 1008

Implementation guide for the ISO Transport Protocol

Pages: 73
Group: ~rfced
Part 1 of 3 – Pages 1 to 19
None   None   Next

ToP   noToC   RFC1008 - Page 1
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.


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
ToP   noToC   RFC1008 - Page 2
                      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

   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
ToP   noToC   RFC1008 - Page 3
   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

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

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

               --module execution scheduling and context

               --synchronization or protocols for realized

               --predicate evaluation for spontaneous

   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

     a.   it is not known when, relative to any specific event defining
          the protocol (e.g., input network, input from user, timer
ToP   noToC   RFC1008 - Page 4
          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

   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 )

                 (* action driven by timeout *)

   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

   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
ToP   noToC   RFC1008 - Page 5
   meaningless because it operates over a connectionless network

   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

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.   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
ToP   noToC   RFC1008 - Page 6

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




   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 and

   |  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                  |
                   NSAP           |<------>|

ToP   noToC   RFC1008 - Page 7
   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.   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

   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
ToP   noToC   RFC1008 - Page 8
   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

   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
ToP   noToC   RFC1008 - Page 9
   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.   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.
ToP   noToC   RFC1008 - Page 10
   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.   Network Service Access Point.

   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

   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.
ToP   noToC   RFC1008 - Page 11
   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.)
ToP   noToC   RFC1008 - Page 12
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.   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

   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.   Class 2 Transport Protocol Machine.

   The formal description of the Class 2 TPM closely resembles that of
ToP   noToC   RFC1008 - Page 13
   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.   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
ToP   noToC   RFC1008 - Page 14
   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

   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
ToP   noToC   RFC1008 - Page 15
   the peer will never have received any TPDU to acknowledge).
   Checksum computations are done in the TPM rather than by the TPE,
   since the TPE must handle all classes.  Also, if the TPMs can be
   made to truly run in parallel, the performance may be greatly

   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
ToP   noToC   RFC1008 - Page 16
   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.   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.   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.   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.   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,
ToP   noToC   RFC1008 - Page 17
   even though a TPM assigned to it continues to operate over other
   network connections. The formal description provides this capability
   in each TPM.   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.   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.   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.   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
ToP   noToC   RFC1008 - Page 18
   as to permit flexibility in credit control schemes and
   acknowledgement strategies.   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.   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.  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
ToP   noToC   RFC1008 - Page 19
   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.

(page 19 continued on part 2)

Next Section