doc: Add RFC documents

1 files changed, 4307 insertions, 0 deletions

diff --git a/doc/rfc/rfc1008.txt b/doc/rfc/rfc1008.txt
new file mode 100644
index 0000000..5aead01
--- /dev/null
+++ b/doc/rfc/rfc1008.txt
@@ -0,0 +1,4307 @@
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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.
+
+   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,
+   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
+   technique for System V by AT&T and for BSD 4.2 by several
+   organizations.  As another example, the transport service might be
+   structured as a device driver.  This approach is used by DEC for the
+   VAX/VMS implementation of classes 0, 2, and 4 of the OSI transport
+   protocol.  The Intel iRMX-86 implementation of Class 4 transport is
+   another example.  Intel implements the transport software as a first
+   level job within the operating system.  Such an approach allows the
+   software to be linked to the operating system and loaded with every
+
+
+
+McCoy                                                          [Page 19]
+
+RFC 1008                                                       June 1987
+
+
+   boot of the system.
+
+   Several advantages may accrue to the communications user when
+   transport is implemented as an integral part of the operating system.
+   First,  the interface to data communications services is well known
+   to the application programmer since the same principles are followed
+   as for other operating system services.  This allows the fast
+   implementation of communications applications without the need for
+   retraining of programmers.  Second, the operating system can support
+   several different suites of protocols without the need to change
+   application programs.  This advantage can be realized only with
+   careful engineering and control of the user-system call interface to
+   the transport services.  Third, the transport software may take
+   advantage of the normally available operating system services such as
+   scheduling, flow control, memory management, and interprocess
+   communication.  This saves time in the development and maintenance of
+   the transport software.
+
+   The disadvantages that exist with operating system integration of the
+   TP are primarily dependent upon the specific operating system.
+   However, the major disadvantage, degradation of host application
+   performance, is always present.  Since the communications software
+   requires the attention of the processor to handle interrupts and
+   process protocol events, some degradation will occur in the
+   performance of host applications.  The degree of degradation is
+   largely a feature of the hardware architecture and processing
+   resources required by the protocol.  Other disadvantages that may
+   appear relate to limited performance on the part of the
+   communications service.  This limited performance is usually a
+   function of the particular operating system and is most directly
+   related to the method of interprocess communication provided with the
+   operating system.  In general, the more times a message must be
+   copied from one area of memory to another, the poorer the
+   communications software will perform.  The method of copying and the
+   number  of copies is often a function of the specific operating
+   system.  For example, copying could be optimized if true shared
+   memory is supported in the operating system.  In this case, a
+   significant amount of copying can be reduced to pointer-passing.
+
+2.2   User program.
+
+   The OSI transport service can be implemented as a user job within any
+   operating system provided a means of multi-task communications is
+   available or can be implemented.  This approach is almost always a
+   bad one.  Performance problems will usually exist because the
+   communication task is competing for resources like any other
+   application program.  The only justification for this approach is the
+   need to develop a simple implementation of the transport service
+   quickly.  The NBS implemented the transport protocol using this
+   approach as the basis for a transport protocol correctness testing
+   system.  Since performance was not a goal of the NBS implementation,
+
+
+
+McCoy                                                          [Page 20]
+
+RFC 1008                                                       June 1987
+
+
+   the ease of development and maintenance made this approach
+   attractive.
+
+2.3   Independent processing element attached to a system bus.
+
+   Implementation of the transport service on an independent processor
+   that attaches to the system bus may provide substantial performance
+   improvements over other approaches.  As computing power and memory
+   have become cheaper this approach has become realistic.  Examples
+   include the Intel implementation of iNA-961 on a variety of multibus
+   boards such as the iSBC 186/51 and the iSXM 554.  Similar products
+   have been developed by Motorola and by several independent vendors of
+   IBM PC add-ons.  This approach requires that the transport software
+   operate on an independent hardware set running under operating system
+   code developed to support the communications software environment.
+   Communication with the application programs takes place across the
+   system bus using some simple, proprietary vendor protocol.  Careful
+   engineering can provide the application programmer with a standard
+   interface to the communications processor that is similar to the
+   interface to the input/output subsystem.
+
+   The advantages of this approach are mainly concentrated upon enhanced
+   performance both for the host applications and the communications
+   service.  Depending on such factors as the speed of the
+   communications processor and the system bus, data communications
+   throughput may improve by one or two orders of magnitude over that
+   available from host operating system integrated implementations.
+   Throughput for host applications should also improve since the
+   communications processing and interrupt handling for timers and data
+   links have been removed from the host processor.  The communications
+   mechanism used between the host and communication processors is
+   usually sufficiently simple that no real burden is added to either
+   processor.
+
+   The disadvantages for this approach are caused by complexity in
+   developing the communications software.  Software development for the
+   communications board cannot be supported with the standard operating
+   system tools.  A method of downloading the processor board and
+   debugging the communications software may be required; a trade-off
+   could be to put the code into firmware or microcode.  The
+   communications software must include at least a hardware monitor and,
+   more typically, a small operating system to support such functions as
+   interprocess communication, buffer management, flow control, and task
+   synchronization.  Debugging of the user to communication subsystem
+   interface may involve several levels of system software and hardware.
+
+   The design of the processing element can follow conventional lines,
+   in which a single processor handling almost all of the operation of
+   the protocol.  However, with inexpensive processor and memory chips
+   now available, a multiprocessor design is economically viable.  The
+   diagram below shows one such design, which almost directly
+
+
+
+McCoy                                                          [Page 21]
+
+RFC 1008                                                       June 1987
+
+
+   corresponds to the structure of the formal description.  There are
+   several advantages to this design:
+
+    1) management of CPU and memory resources is at a minimum;
+
+    2) essentially no resource contention;
+
+    3) transport connection operation can be written in microcode,
+       separate from network service handling;
+
+    4) transport connections can run with true parallelism;
+
+    5) throughput is not limited by contention of connections for CPU
+       and network access; and
+
+    6) lower software complexity, due to functional separation.
+
+   Possible disadvantages are greater inflexibility and hardware
+   complexity.  However, these might be offset by lower development
+   costs for microcode, since the code separation should provide overall
+   lower code complexity in the TPE and the TPM implementations.
+
+   In this system, the TPE instantiates a TPM by enabling its clock.
+   Incoming Outgoing are passed to the TPMs along the memory bus.  TPDUs
+   TPDUs from a TPM are sent on the output data bus.  The user interface
+   controller accepts connect requests from the user and directs them to
+   the TPE.  The TPE assigns a connection reference and informs the
+   interface controller to direct further inputs for this connection to
+   the designated TPM.  The shared TPM memory is analogous to the
+   exported variables of the TPM modules in the formal description, and
+   is used by the TPE to input TPDUs and other information to the TPM.
+
+   In summary, the off-loading of communications protocols onto
+   independent processing systems attached to a host processor across a
+   system bus is quite common.  As processing power and memory become
+   cheaper, the amount of software off-loaded grows.  it is now typical
+   to fine transport service available for several system buses with
+   interfaces to operating systems such as UNIX, XENIX, iRMX, MS-DOS,
+   and VERSADOS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCoy                                                          [Page 22]
+
+RFC 1008                                                       June 1987
+
+
+   Legend:    ****  data channel
+              ....  control channel
+              ====  interface i/o bus
+               O    channel or bus connection point
+
+
+                  user
+                  input
+                    *
+                    *
+          __________V_________
+          |  user interface  |       input bus
+          |    controller    |=================O==============O=======
+          |__________________|                 *              *
+                    *                          *              *
+                    *                          *       _______*_______
+                    *                          *       | data buffers|
+                    *                          *    ...|     TPM1    |
+                    *                          *    :  |_____________|
+                    *                          *    :         *
+                    *                          *    :         *
+   _________   _____*__________   ________   __*____:______   *
+   |  TPE  |   | TPE processor|   |shared|   |    TPM1    |   *
+   |buffers|***|              |   | TPM1 |***|  processor |   *
+   |_______|   |______________|   | mem. |   |____________|   *
+       *         :    :    *      |______|        :           *
+       *         :    :    *          *           :           *
+       *         :    :    ***********O***********:********************
+       *         :    :       memory bus          :           *
+       *         :    :                           :           *
+       *         :    :...........................O...........*........
+   ____*_________:___         clock enable                    *
+   |    network     |                                         *
+   |   interface    |=========================================O========
+   |   controller   |         output data bus
+   |________________|
+           *
+           *
+           V
+      to network
+       interface
+
+
+2.4   Front end processor.
+
+   A more traditional approach to off-loading communications protocols
+   involves the use of a free-standing front end processor, an approach
+   very similar to that of placing the transport service onto a board
+   attached to the system bus.  The difference is one of scale.  Typical
+   front end p interface locally as desirable, as long as such additions
+   are strictly local (i.e., the invoking of such services does not
+
+
+
+McCoy                                                          [Page 23]
+
+RFC 1008                                                       June 1987
+
+
+   result in the exchange of TPDUs with the peer entity).
+
+   The interface between the  user  and  transport  is  by nature
+   asynchronous (although some hypothetical implementation that is
+   wholly synchronous could be conjectured).  This characteristic  is
+   due  to two factors: 1) the interprocess communications (IPC)
+   mechanism--used  between  the  user  and transport--decouples the
+   two, and to avoid blocking the user process (while waiting for a
+   response) requires  an  asynchronous response  mechanism,  and  2)
+   there are some asynchronously-generated transport indications that
+   must  be handled (e.g.,  the  arrival of user data or the abrupt
+   termination of  the  transport  connection  due  to  network errors).
+
+   If it is assumed that the user interface to transport is
+   asynchronous,  there are other aspects of the interface that are also
+   predetermined.  The most important of these is that transport
+   service  requests are confirmed twice.  The first confirmation occurs
+   at the time  of  the  transport  service request  initiation.  Here,
+   interface routines can be used to identify invalid sequences of
+   requests, such as a request to  send  data  on  a  connection that is
+   not yet open.  The second confirmation occurs when the service
+   request crosses the interface into the transport entity.  The entity
+   may accept or reject the request, depending on its resources and its
+   assessment of connection (transport and network) status, priority,
+   service quality.
+
+   If the interface is to be asynchronous, then some mechanism must be
+   provided to handle the asynchronous (and sometimes unexpected)
+   events.  Two ways this is commonly achieved are: 1) by polling, and
+   2) by a software interrupt mechanism.  The first of these can be
+   wasteful of host resources in a multiprogramming environment, while
+   the second may be complicated to implement.  However, if the
+   interface is a combination of hardware and software, as in the cases
+   discussed in Parts 2.3 and 2.4, then hardware interrupts may be
+   available.
+
+   One way of implementing the abstract services is to associate with
+   each service primitive an actual function that is invoked.  Such
+   functions could be held in a special interface library with other
+   functions and procedures that realize the interface.  Each service
+   primitive function would access the interprocess communication (IPC)
+   mechanism as necessary to pass parameters to/from the transport
+   entity.
+
+   The description of the abstract service in IS 8073 and N3756 implies
+   that the interface must handle TSDUs of arbitrary length.  This
+   situation suggests that it may be useful to implement a TSDU as an
+   object such as a file-pointer rather than as the message itself.  In
+   this way, in the sending entity, TPDUs can be formed by reading
+   segments of TPDU-size from the file designated, without regard for
+   the actual length of the file.  In the receiving entity, each new
+
+
+
+McCoy                                                          [Page 24]
+
+RFC 1008                                                       June 1987
+
+
+   TPDU could be buffered in a file designated by a file-pointer, which
+   would then be passed to the user when the EOT arrives.  In the formal
+   description of transport, this procedure is actually described,
+   although explicit file-pointers and files are not used in the
+   description.  This method of implementing the data interface is not
+   essentially different from maintaining a linked list of buffers.  (A
+   disk file is arranged in precisely this fashion, although the file
+   user is usually not aware of the structure.)
+
+   The abstract service definition describes  the  set  of parameters
+   that must be passed in each of the service primitives so that
+   transport can act properly on  behalf  of  the user.   These
+   parameters are required for the transport protocol to operate
+   correctly (e.g., a called address  must  be passed  with  the
+   connect  request and the connect response must contain a responding
+   address).   The  abstract  service defintion does not preclude,
+   however, the inclusion of local parameters.  Local parameters may be
+   included in the implementation  of  the  service  interface  for use
+   by the local entity.  One example is a buffer management parameter
+   passed from  the  user  in connect requests and confirms, providing
+   the transport entity with expected buffer  usage  estimates.  The
+   local  entity  could  use  this  in implementing a more efficient
+   buffer management strategy than would otherwise be possible.
+
+   One issue that is  of  importance  when  designing  and implementing
+   a transport entity is the provision of a registration mechanism for
+   transport users.  This facility provides a means of identifying to
+   the transport entity those users who are willing to participate in
+   communications with remote users.  An example of such a user is a
+   data base management system, which ordinarily responds to connections
+   requests rather than to initiate them.  This procedure of user
+   identification is sometimes called a "passive open".  There are
+   several ways in which registration can be implemented.  One is to
+   install the set of users that  provide services  in  a table at
+   system generation time.  This method may have the disadvantage of
+   being  inflexible.   A  more flexible  approach is to implement a
+   local transport service primitive, "listen", to indicate a waiting
+   user.   The  user then  registers  its transport suffix with the
+   transport entity via the listen primitive.  Another possibility is a
+   combination of predefined table and listen primitive.  Other
+   parameters may also be included,  such  as a partially or fully
+   qualified transport address from which the user is willing  to
+   receive  connections.  A  variant  on  this  approach  is  to
+   provide  an ACTIVE/PASSIVE local parameter on the connect  request
+   service primitive.  Part 5 discusses this issue in more detail.
+
+3.2   Flow control.
+
+   Interface flow control is generally considered to be a local
+   implementation issue.  However, in order to completely specify the
+   behavior of the transport entity, it was necessary to include in the
+
+
+
+McCoy                                                          [Page 25]
+
+RFC 1008                                                       June 1987
+
+
+   formal description a model of the control of data flow across the
+   service boundaries of transport.  The international standards for
+   transport and the OSI reference model state only that interface flow
+   control shall be provided but give no guidance on its features.
+
+   The actual mechanisms used to accomplish flow control, which need not
+   explicitly follow the model in the formal description, are dependent
+   on the way in which the interface itself is realized, i.e., what
+   TSDUs and service primitives really are and how the transport entity
+   actually communicates with its user, its environment, and the network
+   service.  For example, if the transport entity communicates with its
+   user by means of named (UNIX) pipes, then flow control can be
+   realized using a special interface library routine, which the
+   receiving process invokes, to control the pipe.  This approach also
+   entails some consideration for the capacity of the pipe and blocking
+   of the sending process when the pipe is full (discussed further in
+   Part 3.3).  The close correspondence of this interpretation to the
+   model is clear.  However, such an interpretation is apparently not
+   workable if the user process and the transport entity are in
+   physically separate processors.  In this situation, an explicit
+   protocol between the receiving process and the sending process must
+   be provided, which could have the complexity of the data transfer
+   portion of the Class 0 transport protocol (Class 2 if flow
+   controlled).  Note that the formal model, under proper
+   interpretation, also describes this mechanism.
+
+3.3   Interprocess communication.
+
+   One of the most important elements of a data communication system is
+   the approach to interprocess communication (IPC).  This is true
+   because suites of protocols are often implemented as groups of
+   cooperating tasks.  Even if the protocol suites are not implemented
+   as task groups, the communication system is a funnel for service
+   requests from multiple user processes.  The services are normally
+   communicated through some interprocess pathway.  Usually, the
+   implementation environment places some restrictions upon the
+   interprocess communications method that can be used.  This section
+   describes the desired traits of IPC for use in data communications
+   protocol implementations, outlines some possible uses for IPC, and
+   discusses three common and generic approaches to IPC.
+
+   To support the implementation of data communications protocols, IPC
+   should possess several desirable traits.  First,  IPC should be
+   transaction based.  This permits sending a message without the
+   overhead of establishing and maintaining a connection.  The
+   transactions should be confirmed so that a sender can detect and
+   respond to non-delivery.  Second,  IPC should support both the
+   synchronous and the asynchronous modes of message exchange.  An IPC
+   receiver should be able to ask for delivery of any pending messages
+   and not be blocked from continuing if no messages are present.
+   Optionally, the receiver should be permitted to wait if no messages
+
+
+
+McCoy                                                          [Page 26]
+
+RFC 1008                                                       June 1987
+
+
+   are present, or to continue if the path to the destination is
+   congested.  Third, IPC should preserve the order of messages sent to
+   the same destination.  This allows the use of the IPC without
+   modification to support protocols that preserve user data sequence.
+   Fourth, IPC should provide a flow control mechanism to allow pacing
+   of the sender's transmission speed to that of the receiver.
+
+   The uses of IPC in implementation of data communication systems are
+   many and varied.  A common and expected use for IPC is that of
+   passing user messages among the protocol tasks that are cooperating
+   to perform the data communication functions.  The user messages may
+   contain the actual data or, more efficiently, references to the
+   location of the user data.  Another common use for the IPC is
+   implementation and enforcement of local interface flow control.  By
+   limiting the number of IPC messages queued on a particular address,
+   senders can be slowed to a rate appropriate for the IPC consumer.  A
+   third typical use for IPC is the synchronization of processes.  Two
+   cooperating tasks can coordinate their activities or access to shared
+   resources by passing IPC messages at particular events in their
+   processing.
+
+   More creative uses of IPC include buffer, timer, and scheduling
+   management.  By establishing buffers as a list of messages available
+   at a known address at system initialization time, the potential
+   exists to manage buffers simply and efficiently.  A process requiring
+   a buffer would simply read an IPC message from the known address.  If
+   no messages (i.e., buffers) are available, the process could block
+   (or continue, as an option).  A process that owned a buffer and
+   wished to release it would simply write a message to the known
+   address, thus unblocking any processes waiting for a buffer.
+
+   To manage timers, messages can be sent to a known address that
+   represents the timer module.  The timer module can then maintain the
+   list of timer messages with respect to a hardware clock.  Upon
+   expiration of a timer, the associated message can be returned to the
+   originator via IPC.  This provides a convenient method to process the
+   set of countdown timers required by the transport protocol.
+
+   Scheduling management can be achieved by using separate IPC addresses
+   for message classes.  A receiving process can enforce a scheduling
+   discipline by the order in which the message queues are read.  For
+   example, a transport process might possess three queues:  1) normal
+   data from the user, 2) expedited data from the user, and 3) messages
+   from the network.  If the transport process then wants to give top
+   priority to network messages, middle priority to expedited user
+   messages, and lowest priority to normal user messages, all that is
+   required is receipt of IPC messages on the highest priority queue
+   until no more messages are available.  Then the receiver moves to the
+   next lower in priority and so on.  More sophistication is possible by
+   setting limits upon the number of consecutive messages received from
+   each queue and/or varying the order in which each queue is examined.
+
+
+
+McCoy                                                          [Page 27]
+
+RFC 1008                                                       June 1987
+
+
+   It is easy to see how a round-robin scheduling discipline could be
+   implemented using this form of IPC.
+
+   Approaches to IPC can be placed into one of three classes:  1) shared
+   memory, 2) memory-memory copying, and 3) input/output channel
+   copying. Shared memory is the most desirable of the three classes
+   because the amount of data movement is kept to a minimum.  To pass
+   IPC messages using shared memory, the sender builds a small message
+   referencing a potentially large amount of user data.  The small
+   message is then either copied from the sender's process space to the
+   receiver's process space or the small message is mapped from one
+   process space to another using techniques specific to the operating
+   system and hardware involved.  These approaches to shared memory are
+   equivalent since the amount of data movement is kept to a minimum.
+   The price to be paid for using this approach is due to the
+   synchronization of access to the shared memory.  This type of sharing
+   is well understood, and several efficient and simple techniques exist
+   to manage the sharing.
+
+   Memory-memory copying is an approach that has been commonly used for
+   IPC in UNIX operating system implementations.  To pass an IPC message
+   under UNIX data is copied from the sender's buffer to a kernel buffer
+   and then from a kernel buffer to the receiver's buffer.  Thus two
+   copy operations are required for each IPC message. Other methods
+   might only involve a single copy operation.  Also note that if one of
+   the processes involved is the transport protocol implemented in the
+   kernel, the IPC message must only be copied once.  The main
+   disadvantage of this approach is inefficiency.  The major advantage
+   is simplicity.
+
+   When the processes that must exchange messages reside on physically
+   separate computer systems (e.g., a host and front end), an
+   input/output channel of some type must be used to support the IPC.
+   In such a case, the problem is similar to that of the general problem
+   of a transport protocol.  The sender must provide his IPC message to
+   some standard operating system output mechanism from where it will be
+   transmitted via some physical medium to the receiver's operating
+   system.  The receiver's operating system will then pass the message
+   on to the receiving process via some standard operating system input
+   mechanism.  This set of procedures can vary greatly in efficiency and
+   complexity depending upon the operating systems and hardware
+   involved.  Usually this approach to IPC is used only when the
+   circumstances require it.
+
+3.4   Interface to real networks.
+
+   Implementations of the class 4 transport protocol have been operated
+   over a wide variety of networks including:  1) ARPANET, 2) X.25
+   networks, 3) satellite channels, 4) CSMA/CD local area networks, 5)
+   token bus local area networks, and  6) token ring local area
+   networks.  This section briefly describes known instances of each use
+
+
+
+McCoy                                                          [Page 28]
+
+RFC 1008                                                       June 1987
+
+
+   of class 4 transport and provides some quantitative evaluation of the
+   performance expectations for transport over each network type.
+
+3.4.1   Issues.
+
+   The interface of the transport entity to the network service in
+   general will be realized in a different way from the user interface.
+   The network service processor is often separate from the host CPU,
+   connected to it by a bus, direct memory access (DMA), or other link.
+   A typical way to access the network service is by means of a device
+   driver.  The transfer of data across the interface in this instance
+   would be by buffer-copying.  The use of double-buffering reduces some
+   of the complexity of flow control, which is usually accomplished by
+   examining the capacity of the target buffer.  If the transport
+   processor and the network processor are distinct and connected by a
+   bus or external link, the network access may be more complicated
+   since copying will take place across the bus or link rather than
+   across the memory board.  In any case, the network service
+   primitives, as they appear in the formal description and IS 8073 must
+   be carefully correlated to the actual access scheme, so that the
+   semantics of the primitives is preserved.  One way to do this is to
+   create a library of routines, each of which corresponds to one of the
+   service primitives.  Each routine is responsible for sending the
+   proper signal to the network interface unit, whether this
+   communication is directly, as on a bus, or indirectly via a device
+   driver.  In the case of a connectionless network service, there is
+   only one primitive, the N_DATA_request (or N_UNIT_DATA_request),
+   which has to be realized.
+
+   In the formal description, flow control to the NSAP is controlled by
+   by a Slave module, which exerts the "backpressure" on the TPM if its
+   internal queue gets too long.  Incoming flow, however, is controlled
+   in much the same way as the flow to the transport user is controlled.
+   The implementor is reminded that the formal description of the flow
+   control is specified for completeness and not as an implementation
+   guide.  Thus, an implementation should depend upon actual interfaces
+   in the operating environment to realize necessary functions.
+
+3.4.2   Instances of operation.
+
+3.4.2.1   ARPANET
+
+   An early implementation of the class 4 transport protocol was
+   developed by the NBS as a basis for conformance tests [NBS83].  This
+   implementation was used over the ARPANET to communicate between NBS,
+   BBN, and DCA.  The early NBS implementation was executed on a
+   PDP-11/70.  A later revision of the NBS implementation has been moved
+   to a VAX-11/750 and VAX-11/7;80. The Norwegian Telecommunication
+   Administration (NTA) has implemented class 4 transport for the UNIX
+   BSD 4.2 operating system to run on a VAX [NTA84].  A later NTA
+   implementation runs on a Sun 2-120 workstation.  The University of
+
+
+
+McCoy                                                          [Page 29]
+
+RFC 1008                                                       June 1987
+
+
+   Wisconsin has also implemented the class 4 transport protocol on a
+   VAX-11/750 [BRI85]. The Wisconsin implementation is embedded in the
+   BSD 4.2 UNIX kernel.  For most of these implementations class 4
+   transport runs above the DOD IP and below DOD application protocols.
+
+3.4.2.2   X.25 networks
+
+   The NBS implementations have been used over Telenet, an X.25 public
+   data network (PDN).  The heaviest use has been testing of class 4
+   transport between the NBS and several remotely located vendors, in
+   preparation for a demonstration at the 1984 National Computing
+   Conference and the 1985 Autofact demonstration.  Several approaches
+   to implementation were seen in the vendors' systems, including ones
+   similar to those discussed in Part 6.2.  At the Autofact
+   demonstration many vendors operated class 4 transport and the ISO
+   internetwork protocol across an internetwork of CSMA/CD and token bus
+   local networks and Accunet, an AT&T X.25 public data network.
+
+3.4.2.3   Satellite channels.
+
+   The COMSAT Laboratories have implemented class 4 transport for
+   operation over point-to-point satellite channels with data rates up
+   to 1.544 Mbps [CHO85].  This implementation has been used for
+   experiments between the NBS and COMSAT.  As a result of these
+   experiments several improvements have been made to the class 4
+   transport specification within the international standards arena
+   (both ISO and CCITT). The COMSAT implementation runs under a
+   proprietary multiprocessing operating system known as COSMOS.  The
+   hardware base includes multiple Motorola 68010 CPUs with local memory
+   and Multibus shared memory for data messages.
+
+3.4.2.4   CSMA/CD networks.
+
+   The CSMA/CD network as defined by the IEEE 802.3 standard is the most
+   popular network over which the class 4 transport has been
+   implemented. Implementations of transport over CSMA/CD networks have
+   been demonstrated by: AT&T, Charles River Data Systems,
+   Computervision, DEC, Hewlitt-Packard, ICL, Intel, Intergraph, NCR and
+   SUN.  Most of these were demonstrated at the 1984 National Computer
+   Conference [MIL85b] and again at the 1985 Autofact Conference.
+   Several of these vendors are now delivering products based on the
+   demonstration software.
+
+3.4.2.5   Token bus networks.
+
+   Due to the establishment of class 4 transport as a mandatory protocol
+   within the General Motor's manufacturing automation protocol (MAP),
+   many implementations have been demonstrated operating over a token
+   bus network as defined by the IEEE 802.4 standard.  Most past
+   implementations relied upon a Concord Data Systems token interface
+   module (TIM) to gain access to the 5 Mbps broadband 802.4 service.
+
+
+
+McCoy                                                          [Page 30]
+
+RFC 1008                                                       June 1987
+
+
+   Several vendors have recently announced boards supporting a 10 Mbps
+   broadband 802.4 service.  The newer boards plug directly into
+   computer system buses while the TIM's are accessed across a high
+   level data link control (HDLC) serial channel.  Vendors demonstrating
+   class 4 transport over IEEE 802.4 networks include Allen-Bradley,
+   AT&T, DEC, Gould, Hewlett-Packard, Honeywell, IBM, Intel, Motorola,
+   NCR and Siemens.
+
+3.4.2.6   Token ring networks.
+
+   The class 4 transport implementations by the University of Wisconsin
+   and by the NTA run over a 10 Mbps token ring network in addition to
+   ARPANET.  The ring used is from Proteon rather than the recently
+   finished IEEE 802.5 standard.
+
+3.4.3   Performance expectations.
+
+   Performance research regarding the class 4 transport protocol has
+   been limited.  Some work has been done at the University of
+   Wisconsin, at NTA, at Intel, at COMSAT, and at the NBS.  The material
+   presented below draws from this limited body of research to provide
+   an implementor with some quantitative feeling for the performance
+   that can be expected from class 4 transport implementations using
+   different network types.  More detail is available from several
+   published reports [NTA84, BRI85, INT85, MIL85b, COL85].  Some of the
+   results reported derive from actual measurements while other results
+   arise from simulation.  This distinction is clearly noted.
+
+3.4.3.1   Throughput.
+
+   Several live experiments have been conducted to determine the
+   throughput possible with implementations of class 4 transport.
+   Achievable throughput depends upon many factors including:  1) CPU
+   capabilities, 2) use or non-use of transport checksum, 3) IPC
+   mechanism, 4) buffer management technique, 5) receiver resequencing,
+   6) network error properties, 7) transport flow control, 8) network
+   congestion and 9) TPDU size.  Some of these are specifically
+   discussed elsewhere in this document.  The reader must keep in mind
+   these issues when interpreting the throughput measures presented
+   here.
+
+   The University of Wisconsin implemented class 4 transport in the UNIX
+   kernel for a VAX-11/750 with the express purpose of measuring the
+   achievable throughput.  Throughputs observed over the ARPANET ranged
+   between 10.4 Kbps and 14.4 Kbps.  On an unloaded Proteon ring local
+   network, observed throughput with checksum ranged between 280 Kbps
+   and 560 Kbps.  Without checksum, throughput ranged between 384 Kbps
+   and 1 Mbps.
+
+   The COMSAT Laboratories implemented class 4 transport under a
+   proprietary multiprocessor operating system for a multiprocessor
+
+
+
+McCoy                                                          [Page 31]
+
+RFC 1008                                                       June 1987
+
+
+   68010 hardware architecture.  The transport implementation executed
+   on one 68010 while the traffic generator and link drivers executed on
+   a second 68010.  All user messages were created in a global shared
+   memory and were copied only for transmission on the satellite link.
+   Throughputs as high as 1.4 Mbps were observed without transport
+   checksumming while up to 535 Kbps could be achieved when transport
+   checksums were used.  Note that when the 1.4 Mbps was achieved the
+   transport CPU was idle 20% of the time (i.e., the 1.544 Mbps
+   satellite link was the bottleneck).  Thus, the transport
+   implementation used here could probably achieve around 1.9 Mbps user
+   throughput with the experiment parameters remaining unchanged.
+   Higher throughputs are possible by increasing the TPDU size; however,
+   larger messages stand an increased chance of damage during
+   transmission.
+
+   Intel has implemented a class 4 transport product for operation over
+   a CSMA/CD local network (iNA-960 running on the iSBC 186/51 or iSXM
+   552).  Intel has measured throughputs achieved with this combination
+   and  has published the results in a technical analysis comparing
+   iNA-960 performance on the 186/51 with iNA-960 on the 552.  The CPU
+   used to run transport was a 6 MHz 80186.  An 82586 co-processor was
+   used to handle the medium access control.  Throughputs measured
+   ranged between 360 Kbps and 1.32 Mbps, depending on the parameter
+   values used.
+
+   Simulation of class 4 transport via a model developed at the NBS has
+   been used to predict the performance of the COMSAT implementation and
+   is now being used to predict the performance of a three processor
+   architecture that includes an 8 MHz host connected to an 8 MHz front
+   end over a system bus.  The third processor provides medium access
+   control for the specific local networks  being modeled.  Early model
+   results predict throughputs over an unloaded CSMA/CD local network of
+   up to 1.8 Mbps.  The same system modeled over a token bus local
+   network with the same transport parameters yields throughput
+   estimates of up to 1.6 Mbps.  The token bus technology, however,
+   permits larger message sizes than CSMA/CD does.  When TPDUs of 5120
+   bytes are used, throughput on the token bus network is predicted to
+   reach 4.3 Mbps.
+
+3.4.3.2   Delay.
+
+   The one-way delay between sending transport user and receiving
+   transport user is determined by a complex set of factors.  Readers
+   should also note that, in general, this is a difficult measure to
+   make and little work has been done to date with respect to expected
+   one-way delays with class 4 transport implementations.  In this
+   section a tutorial is given to explain the factors that determine the
+   one-way delay to be expected by a transport user.  Delay experiments
+   performed by Intel are reported [INT85], as well as some simulation
+   experiments conducted by the NBS [MIL85a].
+
+
+
+
+McCoy                                                          [Page 32]
+
+RFC 1008                                                       June 1987
+
+
+   The transport user can generally expect one-way delays to be
+   determined by the following equation.
+
+
+     D = TS + ND + TR + [IS] + [IR]        (1)
+
+
+   where:
+
+      [.] means the enclosed quantity may be 0
+
+      D is the one-way transport user delay,
+
+      TS is the transport data send processing time,
+
+      IS is the internet datagram send processing time,
+
+      ND is the network delay,
+
+      IR is the internet datagram receive processing
+      time, and
+
+      TR is the transport data receive processing time.
+
+
+   Although no performance measurements are available for the ISO
+   internetwork protocol (ISO IP), the ISO IP is so similar to the DOD
+   IP that processing times associated with sending and receiving
+   datagrams should be the about the same for both IPs.  Thus, the IS
+   and IR terms given above are ignored from this point on in the
+   discussion.  Note that many of these factors vary depending upon the
+   application traffic pattern and loads seen by a transport
+   implementation.  In the following discussion, the transport traffic
+   is assumed to be a single message.
+
+   The value for TS depends upon the CPU used, the IPC mechanism, the
+   use or non-use of checksum, the size of the user message and the size
+   of TPDUs, the buffer management scheme in use, and the method chosen
+   for timer management.  Checksum processing times have been observed
+   that include 3.9 us per octet for a VAX-11/750, 7.5 us per octet on a
+   Motorola 68010, and 6 us per octet on an Intel 80186.  The class 4
+   transport checksum algorithm has considerable effect on achievable
+   performance. This is discussed further in Part 7.  Typical values for
+   TS, excluding the processing due to the checksum, are about 4 ms for
+   CPUs such as the Motorola 68010 and the Intel 80186.  For 1024 octet
+   TPDUs, checksum calculation can increase the TS value to about 12 ms.
+
+   The value of TR depends upon similar details as TS.  An additional
+   consideration is whether or not the receiver caches (buffers) out of
+   order TPDUs.  If so, the TR will be higher when no packets are lost
+   (because of the overhead incurred by the resequencing logic).  Also,
+
+
+
+McCoy                                                          [Page 33]
+
+RFC 1008                                                       June 1987
+
+
+   when packets are lost, TR can appear to increase due to transport
+   resequencing delay.  When out of order packets are not cached, lost
+   packets increase D because each unacknowledged packet must be
+   retransmitted (and then only after a delay waiting for the
+   retransmission timer to expire).  These details are not taken into
+   account in equation 1.  Typical TR values that can be expected with
+   non-caching implementations on Motorola 68010 and Intel 80186 CPUs
+   are approximately 3 to 3.5 ms.  When transport checksumming is used
+   on these CPUs, TR becomes about 11 ms for 1024 byte TPDUs.
+
+   The value of ND is highly variable, depending on the specific network
+   technology in use and on the conditions in that network.  In general,
+   ND can be defined by the following equation.
+
+
+     ND = NQ + MA + TX + PD + TQ   (2)
+
+
+   where:
+
+     NQ is network queuing delay,
+
+     MA is medium access delay,
+
+     TX is message transmission time,
+
+     PD is network propagation delay, and
+
+     TQ is transport receive queuing delay.
+
+   Each term of the equation is discussed in the following paragraphs.
+
+   Network queuing delay (NQ) is the time that a TPDU waits on a network
+   transmit queue until that TPDU is the first in line for transmission.
+   NQ depends on the size of the network transmit queue, the rate at
+   which the queue is emptied, and the number of TPDUs already on the
+   queue.  The size of the transmit queue is usually an implementation
+   parameter and is generally at least two messages.  The rate at which
+   the queue empties depends upon MA and TX (see the discussion below).
+   The number of TPDUs already on the queue is determined by the traffic
+   intensity (ratio of mean arrival rate to mean service rate).  As an
+   example, consider an 8 Kbps point-to-point link serving an eight
+   message queue that contains 4 messages with an average size of 200
+   bytes per message.  The next message to be placed into the transmit
+   queue would experience an NQ of 800 ms (i.e., 4 messages times 200
+   ms).  In this example, MA is zero.  These basic facts permit the
+   computation of NQ for particular environments.  Note that if the
+   network send queue is full, back pressure flow control will force
+   TPDUs to queue in transport transmit buffers and cause TS to appear
+   to increase by the amount of the transport queuing delay.  This
+   condition depends on application traffic patterns but is ignored for
+
+
+
+McCoy                                                          [Page 34]
+
+RFC 1008                                                       June 1987
+
+
+   the purpose of this discussion.
+
+   The value of MA depends upon the network access method and on the
+   network congestion or load.  For a point-to-point link MA is zero.
+   For CSMA/CD networks MA depends upon the load, the number of
+   stations, the arrival pattern, and the propagation delay.  For
+   CSMA/CD networks MA has values that typically range from zero (no
+   load) up to about 3 ms (80% loads).  Note that the value of MA as
+   seen by individual stations on a CSMA/CD network is predicted (by NBS
+   simulation studies) to be as high as 27 ms under 70% loads.  Thus,
+   depending upon the traffic patterns, individual stations may see an
+   average MA value that is much greater than the average MA value for
+   the network as a whole. On token bus networks MA is determined by the
+   token rotation time (TRT) which depends upon the load, the number of
+   stations, the arrival pattern, the propagation delay, and the values
+   of the token holding time and target rotation times at each station.
+
+   For small networks of 12 stations with a propagation delay of 8 ns,
+   NBS simulation studies predict TRT values of about 1 ms for zero load
+   and 4.5 ms for 70% loads for 200 byte messages arriving with
+   exponential arrival distribution.  Traffic patterns also appear to be
+   an important determinant of target rotation time.  When a pair of
+   stations performs a continuous file transfer, average TRT for the
+   simulated network is predicted to be 3 ms for zero background load
+   and 12.5 ms for 70% background load (total network load of 85%).
+
+   The message size and the network transmission speed directly
+   determine TX.  Typical transmission speeds include 5 and 10 Mbps for
+   standard local networks;  64 Kbps, 384 Kbps, or 1.544 Mbps for
+   point-to-point satellite channels;  and 9.6 Kbps or 56 Kbps for
+   public data network access links.
+
+   The properties of the network in use determine the values of PD. On
+   an IEEE 802.3 network, PD is limited to 25.6 us.  For IEEE 802.4
+   networks, the signal is propagated up-link to a head end and then
+   down-link from the head end.  Propagation delay in these networks
+   depends on the distance of the source and destination stations from
+   the head end and on the head end latency. Because the maximum network
+   length is much greater than with IEEE 802.3 networks, the PD values
+   can also be much greater.  The IEEE 802.4 standard requires that a
+   network provider give a value for the maximum transmission path
+   delay.  For satellite channels PD is typically between 280 and 330
+   ms.  For the ARPANET, PD depends upon the number of hops that a
+   message makes between source and destination nodes.  The NBS and NTIA
+   measured ARPANET PD average values of about 190 ms [NTI85].  In the
+   ARPA internet system the PD is quite variable, depending on the
+   number of internet gateway hops and the PD values of any intervening
+   networks (possibly containing satellite channels).  In experiments on
+   an internetwork containing a a satellite link to Korea, it was
+   determined by David Mills [RFC85] that internet PD values could range
+   from 19 ms to 1500 ms.  Thus, PD values ranging from 300 to 600 ms
+
+
+
+McCoy                                                          [Page 35]
+
+RFC 1008                                                       June 1987
+
+
+   can be considered as typical for ARPANET internetwork operation.
+
+   The amount of time a TPDU waits in the network receive queue before
+   being processed by the receiving transport is represented by TQ,
+   similar to NQ in that the value of TQ depends upon the size of the
+   queue, the number of TPDUs already in the queue, and the rate at
+   which the queue is emptied by transport.
+
+   Often the user delay D will be dominated by one of the components. On
+   a satellite channel the principal component of D is PD, which implies
+   that ND is a principal component by equation (2).  On an unloaded
+   LAN, TS and TR might contribute most to D.  On a highly loaded LAN,
+   MA may cause NQ to rise, again implying that ND is a major factor in
+   determining D.
+
+   Some one-way delay measures have been made by Intel for the iNA-960
+   product running on a 6 MHz 80186.  For an unloaded 10 Mbps CSMA/CD
+   network the Intel measures show delays as low as 22 ms.  The NBS has
+   done some simulations of class 4 transport over 10 Mbps CSMA/CD and
+   token bus networks.  These (unvalidated) predictions show one-way
+   delays as low as 6 ms on unloaded LANs and as high as 372 ms on
+   CSMA/CD LANs with 70% load.
+
+3.4.3.3   Response time.
+
+   Determination of transport user response time (i.e., two-way delay)
+   depends upon many of the same factors discussed above for one-way
+   delay.  In fact, response time can be represented by equation 3 as
+   shown below.
+
+      R = 2D + AS + AR     (3)
+
+   where:
+
+     R is transport user response time,
+
+     D is one-way transport user delay,
+
+     AS is acknowledgement send processing time, and
+
+     AR is acknowledgement receive processing time.
+
+   D has been explained above.  AS and AR deal with the acknowledgement
+   sent by transport in response to the TPDU that embodies the user
+   request.
+
+   AS is simply the amount of time that the receiving transport must
+   spend to generate an AK TPDU.  Typical times for this function are
+   about 2 to 3 ms on processors such as the Motorola 68010 and the
+   Intel 80186.  Of course the actual time required depends upon factors
+   such as those explained for TS above.
+
+
+
+McCoy                                                          [Page 36]
+
+RFC 1008                                                       June 1987
+
+
+   The amount of time, AR, that the sending transport must spend to
+   process a received AK TPDU.  Determination of the actual time
+   required depends upon factors previously described.  Note that for AR
+   and AS, processing when the checksum is included takes somewhat
+   longer. However, AK TPDUs are usually between 10 and 20 octets in
+   length and therefore the increased time due to checksum processing is
+   much less than for DT TPDUs.
+
+   No class 4 transport user response time measures are available;
+   however, some simulations have been done at the NBS.  These
+   predictions are based upon implementation strategies that have been
+   used by commercial vendors in building microprocessor-based class 4
+   transport products.  Average response times of about 21 ms on an
+   unloaded 10 Mbps token bus network, 25 ms with 70% loading, were
+   predicted by the simulations.  On a 10 Mbps CSMA/CD network, the
+   simulations predict response times of about 17 ms for no load and 54
+   ms for a 70% load.
+
+3.5   Error and status reporting.
+
+   Although the abstract service definition for the  transport protocol
+   specifies  a set of services to be offered, the actual set of
+   services  provided  by  an  implementation need  not  be limited to
+   these.  In particular, local status and error information can be
+   provided as a confirmed service (request/response) and as an
+   asynchronous "interrupt" (indication).  One use for this service  is
+   to  allow  users  to query the transport entity about the status of
+   their connections.  An example of information  that  could  be
+   returned from the entity is:
+
+        o  connection state
+        o  current send sequence number
+        o  current receive and transmit credit windows
+        o  transport/network interface status
+        o  number of retransmissions
+        o  number of DTs and AKs sent and received
+        o  current timer values
+
+   Another use for the local status and error reporting service is  for
+   administration  purposes.   Using  the  service, an administrator can
+   gather information such as described above for  each open connection.
+   In addition, statistics concerning the transport entity as a whole
+   can be obtained, such as number of transport connections open,
+   average number of connections open over a  given  reporting  period,
+   buffer  use statistics, and total number of retransmitted DT TPDUs.
+   The administrator might also be given the  authority  to  cancel
+   connections,  restart  the  entity,  or  manually  set timer values.
+
+
+
+
+
+
+
+McCoy                                                          [Page 37]
+
+RFC 1008                                                       June 1987
+
+
+4   Entity resource management.
+
+4.1   CPU management.
+
+   The formal description has implicit scheduling of TPM modules, due to
+   the semantics of the Estelle structuring principles.  However, the
+   implementor should not depend on this scheduling to obtain optimal
+   behavior, since, as stated in Part 1, the structures in the formal
+   description were imposed for purposes other than operational
+   efficiency.
+
+   Whether by design or by default,  every  implementation of the
+   transport protocol embodies some decision about allocating the CPU
+   resource among transport connections.   The resource may be
+   monolithic, i.e. a single CPU, or it may be distributed, as in the
+   example design given in Part 2.3.  In the former, there are  two
+   simple techniques  for apportioning CPU processing time  among
+   transport  connections.   The first of these,
+   first-come/first-served, consists of the transport entity handling
+   user service requests in the order in which they arrive.  No
+   attempt  is  made  to  prevent one transport connection from using
+   an inordinate amount of the CPU.
+
+   The second simple technique is  round-robin  scheduling of
+   connections.   Under this method, each transport connection is
+   serviced in turn.  For  each  connection,  transport processes one
+   user service request, if there is one present at the interface,
+   before proceeding to the next connection.
+
+   The quality of service parameters provided in the connection request
+   can be used to provide a finer-grained strategy for managing the CPU.
+   The CPU could be allocated to connections requiring low delay more
+   often while those requiring high throughput would be served less
+   often but for longer periods (i.e., several connections requiring
+   high throughput might be serviced in a concurrent cluster).
+
+   For example, in the service sequence below, let "T" represent
+   m > 0 service requests, each requiring high throughput, let "D"
+   represent one service request requiring low delay and let the suffix
+   n = 1,2,3 represent a connection identifier, unique only within a
+   particular service requirement type (T,D).  Thus T1 represents a set
+   of service requests for connection 1 of the service requirement type
+   T, and D1 represents a service set (with one member) for connection 1
+   of service requirement type D.
+
+   D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1...
+
+
+   If m = 4 in this service sequence, then service set D1 will get
+   worst-case service once every seventh service request processed.
+   Service set T1 receives service on its four requests only once in
+
+
+
+McCoy                                                          [Page 38]
+
+RFC 1008                                                       June 1987
+
+
+   fourteen requests processed.
+
+   D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1...
+   |              |    |              |    |              |
+   |  3 requests  |  4 |       3      |  4 |       3      |
+
+   This means that the CPU is allocated to T1 29% ( 4/14 ) of the
+   available time, whereas D1 obtains service 14% ( 1/7 ) of the time,
+   assuming processing requirements for all service requests to be
+   equal.  Now assume that, on average, there is a service request
+   arriving for one out of three of the service requirement type D
+   connections.  The CPU is then allocated to the T type 40% ( 4/10 )
+   while the D type is allocated 10% ( 1/10 ).
+
+4.2   Buffer management.
+
+   Buffers are used as temporary storage areas for data on its  way to
+   or arriving from the network.  Decisions must be made about buffer
+   management in two areas.  The first is the overall  strategy  for
+   managing  buffers in a multi-layered protocol environment.  The
+   second  is  specifically  how  to allocate buffers within the
+   transport entity.
+
+   In the formal description no details of buffer strategy are given,
+   since such strategy depends so heavily on the implementation
+   environment.  Only a general mechanism is discussed in the formal
+   description for allocating receive credit to a transport connection,
+   without any expression as to how this resource is managed.
+
+   Good buffer management should correlate to the traffic presented by
+   the applications using the transport service.  This traffic has
+   implications as well for the performance of the protocol. At present,
+   the relationship of buffer strategy to optimal service for a given
+   traffic distribution is not well understood.  Some work has been
+   done, however, and the reader is referred to the work of Jeffery
+   Spirn [SPI82, SPI83] and to the experiment plan for research by the
+   NBS [HEA85] on the effect of application traffic patterns on the
+   performance of Class 4 transport.
+
+4.2.1   Overall buffer strategy.
+
+   Three schemes for management of  buffers  in  a  multilayered
+   environment  are described here.  These represent a spectrum of
+   possibilities available to the implementor.  The first  of these is a
+   strictly layered approach in which each entity in the protocol
+   hierarchy, as a process, manages its own pool of buffers
+   independently  of  entities  at  other layers.  One advantage of this
+   approach  is  simplicity;   it is not necessary for an entity  to
+   coordinate  buffer  usage with a resource manager which is serving
+   the needs of numerous  protocol entities.  Another advantage is
+   modularity.  The interface presented to entities in other layers is
+
+
+
+McCoy                                                          [Page 39]
+
+RFC 1008                                                       June 1987
+
+
+   well  defined; protocol  service  requests and responses are passed
+   between layers by value (copying) versus by reference (pointer
+   copying). In particular, this is a strict interpretation of the OSI
+   reference model, IS 7498 [ISO84b], and the protocol entities hide
+   message details from each other, simplifying handling at the entity
+   interfaces.
+
+   The single disadvantage to a  strictly  layered  scheme derives  from
+   the  value-passing  nature  of the interface.  Each time protocol
+   data and control  information  is  passed from  one layer to another
+   it must be copied from one layer's buffers to those of another layer.
+   Copying  between  layers in  a  multi-layered  environment is
+   expensive and imposes a severe penalty on the performance of the
+   communications system, as  well as the computer system on which it is
+   running as a whole.
+
+   The second scheme for managing buffers  among  multiple protocol
+   layers  is  buffer  sharing.   In  this  approach, buffers are a
+   shared resource among multiple protocol  entities; protocol data and
+   control information contained in the buffers is exchanged by passing
+   a buffer pointer, or  reference, rather  than  the  values  as in the
+   strictly layered approach  described  above.   The  advantage  to
+   passing buffers by reference is that only a small amount of
+   information, the buffer pointer, is copied  from  layer  to  layer.
+   The  resulting  performance  is much better than that of the strictly
+   layered approach.
+
+   There are several requirements  that  must  be  met  to implement
+   buffer sharing.  First, the host system architecture must allow
+   memory sharing among protocol entities  that are  sharing the
+   buffers.  This can be achieved in a variety of ways:  multiple
+   protocol entities may be  implemented  as one  process, all sharing
+   the same process space (e.g., kernel space),  or  the  host  system
+   architecture  may  allow processes  to  map portions of their address
+   space to common buffer areas at some known location in physical
+   memory.
+
+   A buffer manager is another requirement for implementing shared
+   buffers.  The buffer manager has the responsibility of providing
+   buffers  to  protocol entities when needed from a list of free
+   buffers and recycling used buffers  back into  the  free  list. The
+   pool may consist of one or more lists, depending on the level of
+   control desired.  For example, there  could be separate lists of
+   buffers for outgoing and incoming messages.
+
+   The protocol entities must be implemented in such a way as to
+   cooperate with the buffer manager.  While this appears to be an
+   obvious condition, it has important implications for the strategy
+   used by implementors to develop the communications system.  This
+   cooperation can be described as follows:  an entity at layer N
+   requests and is allocated a buffer by the manager; each such buffer
+
+
+
+McCoy                                                          [Page 40]
+
+RFC 1008                                                       June 1987
+
+
+   is returned to the manager by some entity at layer N - k (outgoing
+   data) or N + k (incoming data).
+
+   Protocol  entities also must be designed to cooperate with each
+   other.  As buffers are allocated and sent towards the  network  from
+   higher  layers, allowance must be made for protocol control
+   information to be added at lower layers.  This usually means
+   allocating  oversized buffers to allow space for headers to be
+   prepended at lower layers.  Similarly, as buffers move upward from
+   the network, each protocol entity processes its headers before
+   passing the buffer on.  These  manipulations  can  be handled by
+   managing pointers into the buffer header space.
+
+   In their pure forms, both strictly layered  and  shared buffer
+   schemes are not practical.  In the former, there is a performance
+   penalty for copying buffers.  On the other hand, it  is not practical
+   to implement buffers that are shared by entities in all layers of the
+   protocol hierarchy: the  lower protocol layers (OSI layers 1 - 4)
+   have essentially static buffer requirements, whereas the upper
+   protocol layers (OSI layers 5 - 7) tend to be dynamic in their buffer
+   requirements.  That is, several different applications may be running
+   concurrently, with buffer requirements varying as the set of
+   applications varies.  However, at the transport layer, this latter
+   variation is not visible and variations in buffer requirements will
+   depend more on service quality considerations than on the specific
+   nature of the applications being served.  This suggests a hybrid
+   scheme in which the entities in OSI layers 1 - 4 share buffers while
+   the entities in each of the OSI layers 5 - 7 share in a buffer pool
+   associated with each layer.  This approach provides most of the
+   efficiency of a pure shared buffer scheme and allows for simple,
+   modular interfaces where they are most appropriate.
+
+4.2.2   Buffer management in the transport entity.
+
+   Buffers are allocated in the transport entity  for  two purposes:
+   sending and receiving data.  For sending data, the decision of how
+   much buffer space to allocate is  relatively simple;  enough  space
+   should be allocated for outgoing data to hold the maximum number of
+   data messages that the  entity will have outstanding (i.e., sent but
+   unacknowledged) at any time.  The send buffer space is determined  by
+   one  of  two values,  whichever  is lower:  the send credit received
+   from the receiving transport entity, or a maximum  value  imposed by
+   the  local  implementation,  based  on  such  factors as overall
+   buffer capacity.
+
+   The allocation of receive buffers is a more interesting problem
+   because  it is directly related to the credit value transmitted the
+   peer transport entity in CR (or CC) and AK TPDUs.  If the total
+   credit offered to the peer entity exceeds the total available buffer
+   space and credit reduction  is  not  implemented, deadlock  may
+   occur, causing termination of one or more transport connections.  For
+
+
+
+McCoy                                                          [Page 41]
+
+RFC 1008                                                       June 1987
+
+
+   the purposes of  this discussion,  offered  credit  is assumed to be
+   equivalent to available buffer space.
+
+   The simplest scheme for receive buffer  allocation  is allocation of
+   a fixed amount per transport connection.  This amount is allocated
+   regardless of how the connection  is  to be  used.   This  scheme is
+   fair in that all connections are treated equally.  The implementation
+   approach in Part 2.3, in which each transport connection is handled
+   by a physically separate processor, obviously could use this scheme,
+   since the allocation would be in the form of memory chips assigned by
+   the system designer when the system is built.
+
+   A more flexible method  of  allocating  receive  buffer space  is
+   based  on the connection quality of service (QOS) requested by the
+   user.  For instance, a QOS indicating  high throughput would be given
+   more send and receive buffer space than one a QOS indicating low
+   delay.  Similarly, connection priority can  be  used  to  determine
+   send and receive buffer allocation, with important (i.e., high
+   priority) connections  allocated  more buffer space.
+
+   A slightly more complex scheme is to apportion send and receive
+   buffer  space using both QOS and priority.  For each connection, QOS
+   indicates a general category of  operation  (e.g., high throughput or
+   low delay).  Within the general category, priority determines the
+   specific  amount  of  buffer  space allocated  from  a range of
+   possible values.  The general categories may well overlap, resulting,
+   for example, in a high priority connection with low throughput
+   requirements being allocated more buffer space than low priority
+   connection requiring a high throughput.
+
+5   Management of Transport service endpoints.
+
+   As mentioned in Part 1.2.1.1, a transport entity needs some way of
+   referencing a transport connection endpoint within the end system: a
+   TCEP_id.  There are several factors influencing the management of
+   TCEP_ids:
+
+    1)  IPC mechanism between the transport entity and the session
+        entity (Part 3.3);
+
+    2)  transport entity resources and resource management (Part 4);
+
+    3)  number of distinct TSAPs supported by the entity (Part 1.2.2.1);
+        and
+
+    4)  user process rendezvous mechanism (the means by which session
+        processes identify themselves to the transport entity, at a
+        given TSAP, for association with a transport connection);
+
+   The IPC mechanism and the user process rendezvous mechanism have more
+   direct influence than the other two factors on how the TCEP_id
+
+
+
+McCoy                                                          [Page 42]
+
+RFC 1008                                                       June 1987
+
+
+   management is implemented.
+
+   The number of TCEP_ids available should reflect the resources that
+   are available to the transport entity, since each TCEP_id in use
+   represents a potential transport connection.  The formal description
+   assumes that there is a function in the TPE which can decide, on the
+   basis of current resource availability, whether or not to issue a
+   TCEP_id for any connection request received.  If the TCEP_id is
+   issued, then resources are allocated for the connection endpoint.
+   However, there is a somewhat different problem for the users of
+   transport.  Here, the transport entity must somehow inform the
+   session entity as to the TCEP_ids available at a given TSAP.
+
+   In the formal description, a T-CONNECT-request is permitted to enter
+   at any TSAP/TCEP_id.  A function in the TPE considers whether or not
+   resources are availble to support the requested connection.  There is
+   also a function which checks to see if a TSAP/TCEP_id is busy by
+   seeing if there is a TPM allocated to it.  But this function is not
+   useful to the session entity which does not have access to the
+   transport entity's operations.  This description of the procedure is
+   clearly too loose for an implementation.
+
+   One solution to this problem is to provide a new (abstract) service,
+   T-REGISTER, locally, at the interface between transport and session.
+
+   ___________________________________________________________________
+   |           Primitives                       Parameters           |
+   |_________________________________________________________________|
+   |  T-REGISTER        request     |  Session process  identifier   |
+   |________________________________|________________________________|
+   |  T-REGISTER        indication  |  Transport endpoint identifier,|
+   |                                |  Session process  identifier   |
+   |________________________________|________________________________|
+   |  T-REGISTER        refusal     |  Session process  identifier   |
+   |________________________________|________________________________|
+
+   This service is used as follows:
+
+
+     1)   A session process is identified to the transport entity by a
+          T-REGISTER-request event.  If a TCEP_id is available,  the
+          transport entity selects a TCEP_id and places it into a table
+          corresponding to the TSAP at which the T-REGISTER-request
+          event occurred, along with the session process identifier. The
+          TCEP_id and the session process identifier are then
+          transmitted to the session entity by means of the T-REGISTER-
+          indication event. If no TCEP_id is available, then a T-
+          REGISTER-refusal event carrying the session process identifier
+          is returned.  At any time that an assigned TCEP_id is not
+          associated with an active transport connection process
+          (allocated TPM), the transport entity can issue a T-REGISTER-
+
+
+
+McCoy                                                          [Page 43]
+
+RFC 1008                                                       June 1987
+
+
+          refusal to the session entity to indicate, for example, that
+          resources are no longer available to support a connection,
+          since TC resources are not allocated at registration time.
+
+
+     2)   If the session entity is to initiate the transport connection,
+          it issues a T-CONNECT-request with the TCEP_id as a parameter.
+          (Note that this procedure is at a slight variance to the
+          procedure in N3756, which specifies no such parameter, due to
+          the requirement of alignment of the formal description with
+          the service description of transport and the definition of the
+          session protocol.) If the session entity is expecting a
+          connection request from a remote peer at this TSAP, then the
+          transport does nothing with the TCEP_id until a CR TPDU
+          addressed to the TSAP arrives.  When such a CR TPDU arrives,
+          the transport entity issues a T-CONNECT-indication to the
+          session entity with a TCEP_id as a parameter.  As a management
+          aid, the table entry for the TCEP_id can be marked "busy" when
+          the TCEP_id is associated with an allocated TPM.
+
+
+     3)   If a CR TPDU is received and no TCEP_id is in the table for
+          the TSAP addressed, then the transport selects a TCEP_id,
+          includes it as a parameter in the T-CONNECT-indication sent to
+          the session entity, and places it in the table. The T-
+          CONNECT-response returned by the session entity will carry the
+          TCEP_id and the session process identifier.  If the session
+          process identifier is already in the table, the new one is
+          discarded; otherwise it is placed into the table. This
+          procedure is also followed if the table has entries but they
+          are all marked busy or are empty.  If the table is full and
+          all entries ar marked busy, then the transport entity
+          transmits a DR TPDU to the peer transport entity to indicate
+          that the connection cannot be made.  Note that the transport
+          entity can disable a TSAP by marking all its table entries
+          busy.
+
+
+   The realization of the T-REGISTER service will depend on the IPC
+   mechanisms available between the transport and session entities. The
+   problem of user process rendezvous is solved in general by the T-
+   REGISTER service, which is based on a solution proposed by Michael
+   Chernik of the NBS [CHK85].
+
+6   Management of Network service endpoints in Transport.
+
+6.1   Endpoint identification.
+
+   The identification of endpoints at an NSAP is different from that for
+   the TSAP.  The nature of the services at distinct TSAPs is
+   fundamentally the same, although the quality could vary, as a local
+
+
+
+McCoy                                                          [Page 44]
+
+RFC 1008                                                       June 1987
+
+
+   choice.  However, it is possible for distinct NSAPs to represent
+   access to essentially different network services.  For example, one
+   NSAP may provide access to a connectionless network service by means
+   of an internetwork protocol.  Another NSAP may provide access to a
+   connection-oriented service, for use in communicating on a local
+   subnetwork.  It is also possible to have several distinct NSAPs on
+   the same subnetwork, each of which provides some service features of
+   local interest that distinguishes it from the other NSAPs.
+
+   A transport entity accessing an X.25 service could use the logical
+   channel numbers for the virtual circuits as NCEP_ids.  An NSAP
+   providing access only to a permanent virtual circuit would need only
+   a single NCEP_id to multiplex the transport connections.  Similarly,
+   a CSMA/CD network would need only a single NCEP_id, although the
+   network is connectionless.
+
+6.2   Management issues.
+
+   The Class 4 transport protocol has been succesfully operated over
+   both connectionless and connection-oriented network services.  In
+   both modes of operation there exists some information about the
+   network service that a transport implementation could make use of to
+   enhance performance.  For example, knowledge of expected delay to a
+   destination would permit optimal selection of retransmission timer
+   value for a connection instance.  The information that transport
+   implementations could use and the mechanisms for obtaining and
+   managing that information are, as a group, not well understood.
+   Projects are underway within ISO committees to address the management
+   of OSI as an architecture and the management of the transport layer
+   as a layer.
+
+   For operation of the Class 4 transport protocol over
+   connection-oriented network service several issues must be addressed
+   including:
+
+
+     a.   When should a new network connection be opened to support a
+          transport connection (versus multiplexing)?
+
+     b.   When a network connection is no longer being used by any
+          transport connection, should the network connection be closed
+          or remain open awaiting a new transport connection?
+
+     c.   When a network connection is aborted, how should the peer
+          transport entities that were using the connection cooperate to
+          re-establish it?  If splitting is not to be used, how can this
+          re-establishment be achieved such that one and only one
+          network connection results?
+
+   The Class 4 transport specification permits a transport entity to
+   multiplex several transport connections (TCs) over a single network
+
+
+
+McCoy                                                          [Page 45]
+
+RFC 1008                                                       June 1987
+
+
+   connection (NC) and to split a single TC across several NCs.  The
+   implementor must decide whether to support these options and, if so,
+   how.  Even when the implementor decides never to initiate splitting
+   or multiplexing the transport entity must be prepared to accept this
+   behavior from other transport implementations.  When multiplexing is
+   used TPDUs from multiple TCs can be concatenated into a single
+   network service data unit (NSDU).  Therefore, damage to an NSDU may
+   effect several TCs.  In general, Class 2 connections should not be
+   multiplexed with Class 4 connections.  The reason for this is that if
+   the error rate on the network connection is high enough that the
+   error recovery capability of Class 4 is needed, then it is too high
+   for Class 2 operation.  The deciding criterion is the tolerance of
+   the user for frequent disconnection and data errors.
+
+   Several issues in splitting must be considered:
+
+    1) maximum number of NCs that can be assigned to a given TC;
+
+    2) minimum number of NCs required by a TC to maintain the "quality
+       of service" expected (default of 1);
+
+    3) when to split;
+
+    4) inactivity control;
+
+    5) assignment of received TPDU to TC; and
+
+    6) notification to TC of NC status (assigned, dissociated, etc ).
+
+   All of these except 3) are covered in the formal description.  The
+   methods used in the formal description need not be used explicitly,
+   but they suggest approaches to implementation.
+
+   To support the possibility of multiplexing and splitting the
+   implementor must provide a common function below the TC state
+   machines that maps a set of TCs to a set of NCs.  The formal
+   description provides a general means of doing this, requiring mainly
+   implementation environment details to complete the mechanism.
+   Decisions about when network connections are to be opened or closed
+   can be made locally using local decision criteria.  Factors that may
+   effect the decision include costs of establishing an NC, costs of
+   maintaining an open NC with little traffic flowing, and estimates of
+   the probability of data flow between the source node and known
+   destinations.  Management of this type is feasible when a priori
+   knowledge exists but is very difficult when a need exists to adapt to
+   dynamic traffic patterns and/or fluctuating network charging
+   mechanisms.
+
+   To handle the issue of re-establishment of the NC after failure, the
+   ISO has proposed an addendum N3279 [ISO85c] to the basic transport
+   standard describing a network connection management subprotocol
+
+
+
+McCoy                                                          [Page 46]
+
+RFC 1008                                                       June 1987
+
+
+   (NCMS) to be used in conjunction with the transport protocol.
+
+7   Enhanced checksum algorithm.
+
+7.1   Effect of checksum on transport performance.
+
+   Performance experiments with Class 4 transport at the NBS have
+   revealed that straightforward implementation of the Fletcher checksum
+   using the algorithm recommended in the ISO transport standard leads
+   to severe reduction of transport throughput.  Early modeling
+   indicated throughput drops of as much as 66% when using the checksum.
+   Work by Anastase Nakassis [NAK85] of the NBS led to several improved
+   implementations.  The performance degradation due to checksum is now
+   in the range of 40-55%, when using the improved implementations.
+
+   It is possible that transport may be used over a network that does
+   not provide error detection.  In such a case the transport checksum
+   is necessary to ensure data integrity. In many instances, the
+   underlying subnetwork provides some error checking mechanism.  The
+   HDLC frame check sequence as used by X.25, IEEE 802.3 and 802.4 rely
+   on a 32 bit cyclic redundancy check and satellite link hardware
+   frequently provides the HDLC frame check sequence.  However, these
+   are all link or physical layer error detection mechanisms which
+   operate only point-to-point and not end-to-end as the transport
+   checksum does.  Some links provide error recovery while other links
+   simply discard damaged messages.  If adequate error recovery is
+   provided, then the transport checksum is extra overhead, since
+   transport will detect when the link mechanism has discarded a message
+   and will retransmit the message.  Even when the IP fragments the
+   TPDU, the receiving IP will discover a hole in the reassembly buffer
+   and discard the partially assembled datagram (i.e., TPDU).  Transport
+   will detect this missing TPDU and recover by means of the
+   retransmission mechanism.
+
+7.2   Enhanced algorithm.
+
+   The Fletcher checksum algorithm given in an annex to IS 8073 is not
+   part of the standard, and is included in the annex as a suggestion to
+   implementors.  This was done so that as improvements or new
+   algorithms came along, they could be incorporated without the
+   necessity to change the standard.
+
+   Nakassis has provided three ways of coding the algorithm, shown
+   below, to provide implementors with insight rather than universally
+   transportable code.  One version uses a high order language (C).  A
+   second version uses C and VAX assembler, while a third uses only VAX
+   assembler.  In all the versions, the constant MODX appears.  This
+   represents the maximum number of sums that can be taken without
+   experiencing overflow.  This constant depends on the processor's word
+   size and the arithmetic mode, as follows:
+
+
+
+
+McCoy                                                          [Page 47]
+
+RFC 1008                                                       June 1987
+
+
+    Choose n such that
+
+     (n+1)*(254 + 255*n/2) <= 2**N - 1
+
+
+   where N is the number of usable bits for signed (unsigned)
+   arithmetic.  Nakassis shows [NAK85] that it is sufficient
+   to take
+
+
+
+     n <= sqrt( 2*(2**N - 1)/255 )
+
+
+   and that n = sqrt( 2*(2**N - 1)/255 ) - 2 generally yields
+   usable values.  The constant MODX then is taken to be n.
+
+
+   Some typical values for MODX are given in the following table.
+
+
+    BITS/WORD                MODX          ARITHMETIC
+        15                     14             signed
+        16                     21           unsigned
+        31                   4102             signed
+        32                   5802           unsigned
+
+   This constant is used to reduce the number of times mod 255 addition
+   is invoked, by way of speeding up the algorithm.
+
+   It should be noted that it is also possible to implement the checksum
+   in separate hardware.  However, because of the placement of the
+   checksum within the TPDU header rather than at the end of the TPDU,
+   implementing this with registers and an adder will require
+   significant associated logic to access and process each octet of the
+   TPDU and to move the checksum octets in to the proper positions in the
+   TPDU. An alternative to designing this supporting logic is to use a
+   fast, microcoded 8-bit CPU to handle this access and the computation.
+   Although there is some speed penalty over separate logic, savings
+   may be realized through a reduced chip count and development time.
+
+7.2.1   C language algorithm.
+
+   #define MODX 4102
+
+
+     encodecc( mess,len,k )
+     unsigned char mess[] ;    /* the TPDU to be checksummed */
+     int      len,
+              k;               /* position of first checksum octet
+                                  as an offset from mess[0]  */
+
+
+
+McCoy                                                          [Page 48]
+
+RFC 1008                                                       June 1987
+
+
+     { int ip,
+           iq,
+           ir,
+           c0,
+           c1;
+       unsigned char *p,*p1,*p2,*p3 ;
+
+       p = mess ; p3 = mess + len ;
+
+       if ( k > 0) { mess[k-1] = 0x00 ; mess[k] = 0x00 ; }
+            /* insert zeros for checksum octets */
+
+       c0 = 0 ; c1 = 0  ; p1 = mess ;
+       while (p1 < p3)    /* outer sum accumulation loop */
+       {
+        p2 = p1 + MODX ; if (p2 > p3) p2 = p3 ;
+        for (p = p1 ; p < p2 ; p++) /*  inner sum accumulation loop */
+        { c0 = c0 + (*p) ; c1 = c1 + c0 ;
+        }
+        c0 = c0%255 ; c1 = c1%255 ; p1 = p2 ;
+            /* adjust accumulated sums to mod 255 */
+        }
+        ip = (c1 << 8) + c0 ;     /* concatenate c1 and c0 */
+
+        if (k > 0)
+        {     /* compute and insert checksum octets */
+
+         iq = ((len-k)*c0 - c1)%255 ; if (iq <= 0) iq = iq + 255 ;
+         mess[k-1] = iq ;
+         ir = (510 - c0 - iq) ;
+         if (ir > 255) ir = ir - 255 ; mess[k] = ir ;
+       }
+       return(ip) ;
+     }
+
+7.2.2   C/assembler algorithm.
+
+   #include <math>
+
+     encodecm(mess,len,k)
+     unsigned char *mess ;
+     int      len,k      ;
+     {
+       int i,ip,c0,c1 ;
+
+       if (k > 0) { mess[k-1] = 0x00 ; mess[k] = 0x00 ; }
+       ip = optm1(mess,len,&c0,&c1) ;
+       if (k > 0)
+       { i = ( (len-k)*c0 - c1)%255 ; if (i <= 0) i = i + 255 ;
+         mess[k-1] = i ;
+         i = (510 - c0 - i) ; if (i > 255) i = i - 255 ;
+
+
+
+McCoy                                                          [Page 49]
+
+RFC 1008                                                       June 1987
+
+
+         mess[k] = i ;
+       }
+       return(ip) ;
+     }
+    ;       calling sequence optm(message,length,&c0,&c1) where
+    ;       message is an array of bytes
+    ;       length   is the length of the array
+    ;       &c0 and &c1 are the addresses of the counters to hold the
+    ;       remainder of; the first and second order partial sums
+    ;       mod(255).
+
+            .ENTRY   optm1,^M<r2,r3,r4,r5,r6,r7,r8,r9,r10,r11>
+            movl     4(ap),r8      ; r8---> message
+            movl     8(ap),r9      ; r9=length
+            clrq     r4            ; r5=r4=0
+            clrq     r6            ; r7=r6=0
+            clrl     r3            ; clear high order bytes of r3
+            movl     #255,r10      ; r10 holds the value 255
+            movl     #4102,r11     ; r11= MODX
+    xloop:  movl     r11,r7        ; if r7=MODX
+            cmpl     r9,r7         ; is r9>=r7 ?
+            bgeq     yloop         ; if yes, go and execute the inner
+                                   ; loop MODX times.
+            movl     r9,r7         ; otherwise set r7, the inner loop
+                                   ; counter,
+    yloop:  movb     (r8)+,r3      ;
+            addl2    r3,r4         ; sum1=sum1+byte
+            addl2    r4,r6         ; sum2=sum2+sum1
+            sobgtr   r7,yloop      ; while r7>0 return to iloop
+                              ; for mod 255 addition
+      ediv     r10,r6,r0,r6  ; r6=remainder
+      ediv     r10,r4,r0,r4  ;
+      subl2    r11,r9        ; adjust r9
+      bgtr     xloop         ; go for another loop if necessary
+      movl     r4,@12(ap)    ; first argument
+      movl     r6,@16(ap)    ; second argument
+      ashl     #8,r6,r0      ;
+      addl2    r4,r0         ;
+      ret
+
+7.2.3  Assembler algorithm.
+
+   buff0:  .blkb   3              ; allocate 3 bytes so that aloop is
+                          ; optimally aligned
+   ;       macro implementation of Fletcher's algorithm.
+   ;       calling sequence ip=encodemm(message,length,k) where
+   ;       message is an array of bytes
+   ;       length   is the length of the array
+   ;       k        is the location of the check octets if >0,
+   ;                an indication not to encode if 0.
+   ;
+
+
+
+McCoy                                                          [Page 50]
+
+RFC 1008                                                       June 1987
+
+
+   movl     4(ap),r8      ; r8---> message
+   movl     8(ap),r9      ; r9=length
+   clrq     r4            ; r5=r4=0
+   clrq     r6            ; r7=r6=0
+   clrl     r3            ; clear high order bytes of r3
+   movl     #255,r10      ; r10 holds the value 255
+   movl     12(ap),r2     ; r2=k
+   bleq     bloop         ; if r2<=0, we do not encode
+   subl3    r2,r9,r11     ; set r11=L-k
+   addl2    r8,r2         ; r2---> octet k+1
+   clrb     (r2)          ; clear check octet k+1
+   clrb     -(r2)         ; clear check octet k, r2---> octet k.
+   bloop:  movw     #4102,r7   ; set r7 (inner loop counter) = to MODX
+   cmpl     r9,r7         ; if r9>=MODX, then go directly to adjust r9
+   bgeq     aloop         ; and execute the inner loop MODX times.
+   movl     r9,r7         ; otherwise set r7, the inner loop counter,
+                          ; equal to r9, the number of the
+                          ; unprocessed characters
+   aloop:  movb     (r8)+,r3      ;
+   addl2    r3,r4         ; c0=c0+byte
+   addl2    r4,r6         ; sum2=sum2+sum1
+   sobgtr   r7,aloop      ; while r7>0 return to iloop
+                                  ; for mod 255 addition
+   ediv     r10,r6,r0,r6  ; r6=remainder
+   ediv     r10,r4,r0,r4  ;
+   subl2    #4102,r9      ;
+   bgtr     bloop         ; go for another loop if necessary
+   ashl     #8,r6,r0      ; r0=256*r6
+   addl2    r4,r0         ; r0=256*r6+r4
+   cmpl     r2,r7         ; since r7=0, we are checking if r2 is
+   bleq     exit          ; zero or less: if yes we bypass
+                                  ; the encoding.
+   movl     r6,r8         ; r8=c1
+   mull3    r11,r4,r6     ; r6=(L-k)*c0
+   ediv     r10,r6,r7,r6  ; r6 = (L-k)*c0 mod(255)
+   subl2    r8,r6         ; r6= ((L-k)*c0)%255 -c1 and if negative,
+   bgtr     byte1         ; we must
+   addl2    r10,r6        ; add 255
+   byte1:  movb     r6,(r2)+ ; save the octet and let r2---> octet k+1
+   addl2    r6,r4         ; r4=r4+r6=(x+c0)
+   subl3    r4,r10,r4     ; r4=255-(x+c0)
+   bgtr     byte2         ; if >0 r4=octet (k+1)
+   addl2    r10,r4        ; r4=255+r4
+   byte2:  movb     r4,(r2)       ; save y in octet k+1
+   exit:   ret
+
+8   Parameter selection.
+
+8.1   Connection control.
+
+   Expressions for timer values used to control the general transport
+
+
+
+McCoy                                                          [Page 51]
+
+RFC 1008                                                       June 1987
+
+
+   connection behavior are given in IS 8073.  However, values for the
+   specific factors in the expressions are not given and the expressions
+   are only estimates.  The derivation of timer values from these
+   expressions is not mandatory in the standard.  The timer value
+   expressions in IS 8073 are for a connection-oriented network service
+   and may not apply to a connectionless network service.
+
+   The following symbols are used to denote factors contributing to
+   timer values, throughout the remainder of this Part.
+
+    Elr = expected maximum transit delay, local to remote
+
+    Erl = expected maximum transit delay, remote to local
+
+    Ar  = time needed by remote entity to generate an acknowledgement
+
+    Al  = time needed by local entity to generate an acknowledgement
+
+    x   = local processing time for an incoming TPDU
+
+    Mlr = maximum NSDU lifetime, local to remote
+
+    Mrl = maximum NSDU lifetime, remote to local
+
+    T1  = bound for maximum time local entity will wait for
+          acknowledgement before retransmitting a TPDU
+
+    R   = bound for maximum local entity will continue to transmit a
+          TPDU that requires acknowledgment
+
+    N   = bound for maximum number of times local entity  will transmit
+          a TPDU requiring acknowledgement
+
+    L   = bound for the maximum time between the transmission of a
+          TPDU and the receipt of any acknowledgment relating to it.
+
+    I   = bound for the time after which an entity will initiate
+          procedures to terminate a transport connection if a TPDU is
+          not received from the peer entity
+
+    W   = bound for the maximum time an entity will wait before
+          transmitting up-to-date window information
+
+   These symbols and their definitions correspond to those given in
+   Clause 12 of IS 8073.
+
+8.1.1   Give-up timer.
+
+   The give-up timer determines the  amount  of  time  the transport
+   entity  will continue to await an acknowledgement (or other
+   appropriate reply) of a transmitted message  after the  message
+
+
+
+McCoy                                                          [Page 52]
+
+RFC 1008                                                       June 1987
+
+
+   has  been  retransmitted the maximum number of times.    The
+   recommendation given in IS 8073 for values of this timer is
+   expressed by
+
+    T1 + W + Mrl, for DT and ED TPDUs
+
+    T1 + Mrl, for CR, CC, and DR TPDUs,
+
+   where
+
+    T1 = Elr + Erl + Ar + x.
+
+   However, it should be noted that Ar will not be known for either the
+   CR or the CC TPDU, and that Elr and Erl may vary considerably due to
+   routing in some conectionless network services.  In Part 8.3.1, the
+   determination of values for T1 is discussed in more detail.  Values
+   for Mrl generally are relatively fixed for a given network service.
+   Since Mrl is usually much larger than expected values of T1, a
+   rule-of-thumb for the give-up timer value is 2*Mrl + Al + x for the
+   CR, CC and DR TPDUs and 2*Mrl + W for DT and ED TPDUs.
+
+8.1.2   Inactivity timer.
+
+   This timer measures  the  maximum  time  period  during which a
+   transport connection can be inactive, i.e., the maximum time an
+   entity can wait without receiving incoming messages.  A usable value
+   for the inactivity timer is
+
+    I = 2*( max( T1,W )*N ).
+
+   This accounts for the possibility that the remote peer is using a
+   window timer value different from that of the local peer.  Note that
+   an inactivity timer is important for operation over connectionless
+   network services, since the periodic receipt of AK TPDUs is the only
+   way that the local entity can be certain that its peer is still
+   functioning.
+
+8.1.3   Window timer.
+
+   The window timer has two purposes.  It is used to assure that the
+   remote peer entity periodically receives the current state of the
+   local entity's flow control, and it ensures that the remote peer
+   entity is aware that the local entity is still functioning.  The
+   first purpose is necessary to place an upper bound on the time
+   necessary to resynchronize the flow control should an AK TPDU which
+   notifies the remote peer of increases in credit be lost.  The second
+   purpose is necessary to prevent the inactivity timer of the remote
+   peerfrom expiring.  The value for the window timer, W, depends on
+   several factors, among which are the transit delay, the
+   acknowledgement strategy, and the probability of TPDU loss in the
+   network.  Generally, W should satisfy the following condition:
+
+
+
+McCoy                                                          [Page 53]
+
+RFC 1008                                                       June 1987
+
+
+     W > C*(Erl + x)
+
+   where C is the maximum amount of credit offered.  The rationale for
+   this condition is that the right-hand side represents the maximum
+   time for receiving the entire window.  The protocol requires that all
+   data received be acknowledged when the upper edge of the window is
+   seen as a sequence number in a received DT TPDU.  Since the window
+   timer is reset each time an AK TPDU is transmitted, there is usually
+   no need to set the timer to any less than the value on the right-hand
+   side of the condition.  An exception is when both C and the maximum
+   TPDU size are large, and Erl is large.
+
+   When the probability that a TPDU will be lost is small, the value of
+   W can be quite large, on the order of several minutes.  However, this
+   increases the delay the peer entity will experience in detecting the
+   deactivation of the local transport entity.  Thus, the value of W
+   should be given some consideration in terms of how soon the peer
+   entity needs to detect inactivity.  This could be done by placing
+   such information into a quality of service record associated with the
+   peer's address.
+
+   When the expected network error rate is high, it may be necessary to
+   reduce the value of W to ensure that AK TPDUs are being received by
+   the remote entity, especially when both entities are quiescent for
+   some period of time.
+
+8.1.4   Reference timer.
+
+   The reference timer measures  the  time  period  during which a
+   source reference must not be reassigned to another transport
+   connection, in order that spurious duplicate  messages not
+   interfere  with a new connection.  The value for this timer
+   given in IS 8073 is
+
+    L = Mlr + Mrl + R + Ar
+
+   where
+
+    R = T1*N + z
+
+   in which z is a small tolerance quantity to allow for factors
+   internal to the entity.  The use of L as a bound, however, must be
+   considered carefully.  In some cases, L may be very large, and not
+   realistic as an upper or a lower bound.  Such cases may be
+   encountered on routes over several catenated networks where R is set
+   high to provide adequate recovery from TPDU loss.  In other cases L
+   may be very small, as when transmission is carried out over a LAN and
+   R is set small due to low probability of TPDU loss.  When L is
+   computed to be very small, the reference need not be timed out at
+   all, since the probability of interference is zero.  On the other
+   hand, if L is computed to be very large a smaller value can be used.
+
+
+
+McCoy                                                          [Page 54]
+
+RFC 1008                                                       June 1987
+
+
+   One choice for the value  might be
+
+    L = min( R,(Mrl + Mlr)/2 )
+
+   If the reference number assigned to  a  new  connection  by  an
+   entity  is monotonically incremented for each new connection through
+   the entire available reference space (maximum 2**16 - 1), the timer
+   is not critical: the sequence space is large enough that it is likely
+   that there will be no spurious messages in  the network by the time
+   reference numbers are reused.
+
+8.2   Flow control.
+
+   The peer-to-peer flow control mechanism  in  the  transport protocol
+   determines  the  upper bound on the pace of data exchange that occurs
+   on  transport  connections.   The transport  entity  at  each end of
+   a connection offers a credit to its peer representing the number of
+   data  messages it  is  currently willing to accept.  All received
+   data messages are acknowledged,  with  the  acknowledgement  message
+   containing  the  current  receive  credit  information.  The three
+   credit allocation schemes discussed  below  present  a diverse  set
+   of  examples  of  how one might derive receive credit values.
+
+8.2.1   Pessimistic credit allocation.
+
+   Pessimistic credit allocation is perhaps the simplest form of flow
+   control.  It is similar in concept to X-on/X-off control.  In this
+   method, the receiver always offers a credit of one TPDU.  When the DT
+   TPDU is received, the receiver responds with an AK TPDU carrying a
+   credit of zero.  When the DT TPDU has been processed by the receiving
+   entity, an additional AK TPDU carrying a credit of one will be sent.
+   The advantage to this approach is  that  the data  exchange  is  very
+   tightly controlled by the receiving entity.  The disadvantages are:
+   1) the  exchange  is  slow, every data  message requiring at least
+   the time of two round trips to complete the transfer transfer, and 2)
+   the ratio of acknowledgement to data messages sent is 2:1.  While not
+   recommeneded, this scheme illustrates one extreme method of credit
+   allocation.
+
+8.2.2   Optimistic credit allocation.
+
+   At the other extreme from pessimistic credit allocation is optimistic
+   credit  allocation,  in  which  the  receiver offers more credit than
+   it has buffers.  This scheme  has  two  dangers.  First, if the
+   receiving user is not accepting data at a fast enough rate, the
+   receiving transport's  buffers  will  become filled.  Since  the
+   credit  offered  was optimistic, the sending entity will continue to
+   transmit data, which must be dropped  by the receiving entity for
+   lack of buffers. Eventually,  the  sender  may  reach  the  maximum
+   number   of retransmissions and terminate the connection.
+
+
+
+
+McCoy                                                          [Page 55]
+
+RFC 1008                                                       June 1987
+
+
+   The second danger in using optimistic flow  control  is that the
+   sending entity may transmit faster than the receiving entity can
+   consume.  This could result from  the  sender being  implemented  on
+   a faster machine or being a more efficient implementation.  The
+   resultant behavior is essentially the same as described above:
+   receive buffer saturation, dropped data messages, and connection
+   termination.
+
+   The two dangers  cited  above  can  be  ameliorated  by implementing
+   the credit reduction scheme as specified in the protocol.  However,
+   optimistic credit allocation works  well only  in  limited
+   circumstances.   In most situations it is inappropriate and
+   inefficient even when using credit reduction.  Rather  than seeking
+   to avoid congestion, optimistic allocation causes it, in most cases,
+   and credit reduction simply allows  one to recover from congestion
+   once it has happened.  Note that optimistic credit allocation
+   combined with caching out-of-sequence messages requires a
+   sophisticated buffer management scheme to avoid reasssembly deadlock
+   and subsequent loss of the transport connection.
+
+8.2.3   Buffer-based credit allocation.
+
+   Basing the receive  credit  offered  on  the  actual availability  of
+   receive  buffers  is  a  better method for achieving flow control.
+   Indeed, with few exceptions, the implementations that have been
+   studied used this method.  It continuous  flow  of  data  and
+   eliminating the need for the credit-restoring  acknowledgements.
+   Since  only  available buffer space is offered, the dangers of
+   optimistic credit allocation are also avoided.
+
+   The amount of buffer space needed to  maintain  a  continuous bulk
+   data  transfer,  which represents the maximum buffer requirement, is
+   dependent on round trip  delay  and network  speed.  Generally, one
+   would want the buffer space, and hence the credit, large enough to
+   allow  the  sender  to send continuously, so that incremental credit
+   updates arrive just prior to the sending entity  exhausting  the
+   available credit.   One example is a single-hop satellite link
+   operating at 1.544  Mbits/sec.   One  report [COL85]  indicates  that
+   the buffer requirement necessary for continuous flow is approximately
+   120 Kbytes.  For 10 Mbits/sec. IEEE 802.3 and 802.4 LANs, the figure
+   is on the order of 10K to 15K bytes [BRI85, INT85, MIL85].
+
+   An interesting modification to the buffer-based  credit allocation
+   scheme is suggested by R.K. Jain [JAI85].  Whereas the approach
+   described above is based strictly on the available buffer space, Jain
+   suggests a scheme in which credit is reduced  voluntarily  by  the
+   sending  entity  when  network congestion  is  detected.  Congestion
+   is implied by the occurrence of retransmissions.  The sending
+   entity,  recognizing retransmissions,  reduces  the local value of
+   credit to one, slowly raising it to the actual receive credit
+   allocation as error-free transmissions continue to occur.  This
+
+
+
+McCoy                                                          [Page 56]
+
+RFC 1008                                                       June 1987
+
+
+   technique can overcome various types of network congestion occurring
+   when a fast sender overruns a slow receiver when no link level flow
+   control is available.
+
+8.2.4   Acknowledgement policies.
+
+   It is useful first to  review the four uses of the acknowledgement
+   message in Class 4 transport.  An acknowledgement message:
+
+          1) confirms correct receipt of data messages,
+
+          2) contains a credit allocation, indicating how  many
+             data  messages  the  entity  is willing to receive
+             from the correspondent entity,
+
+          3) may  optionally  contain  fields   which   confirm
+             receipt   of  critical  acknowledgement  messages,
+             known as flow control confirmation (FCC), and
+
+          4) is sent upon expiration of  the  window  timer  to
+             maintain  a minimum level of traffic on an
+             otherwise quiescent connection.
+
+   In choosing an acknowledgement strategy, the first and  third uses
+   mentioned  above,  data  confirmation and FCC, are the most relevant;
+   the second, credit allocation, is  determined according  to  the
+   flow  control  strategy  chosen, and the fourth,  the  window
+   acknowledgement,  is  only   mentioned briefly in the discussion on
+   flow control confirmation.
+
+8.2.4.1   Acknowledgement of data.
+
+   The primary purpose of the acknowledgement  message  is to  confirm
+   correct  receipt  of  data messages.  There are several choices that
+   the implementor must make when  designing a  specific
+   implementation.   Which  choice to make is based largely on the
+   operating  environment  (e.g.,  network error  characteristics).
+   The issues to be decided upon are discussed in the sections below.
+
+8.2.4.1.1  Misordered data messages.
+
+   Data messages received out  of  order  due  to  network misordering
+   or loss can be cached or discarded.  There is no single determinant
+   that guides the implementor to one or  the  other choice.  Rather,
+   there are a number of issues to be considered.
+
+   One issue is the importance of maintaining a low  delay as  perceived
+   by  the user.  If transport data messages are lost or damaged in
+   transit, the absence of a  positive acknowledgement  will trigger a
+   retransmission at the sending entity.  When the retransmitted data
+   message arrives at  the receiving  transport,  it  can be delivered
+
+
+
+McCoy                                                          [Page 57]
+
+RFC 1008                                                       June 1987
+
+
+   to the user.  If subsequent data messages had  been  cached,  they
+   could  be delivered  to  the user at the same time.  The delay
+   between the sending  and  receiving  users  would,  on  average, be
+   shorter  than  if messages subsequent to a lost message were
+   dependent on retransmission for recovery.
+
+   A second factor that influences the caching choice is  the cost of
+   transmission.  If transmission costs are high, it is more economical
+   to cache  misordered  data,  in  conjunction with the use of
+   selective acknowledgement (described below), to avoid
+   retransmissions.
+
+   There are two resources that are conserved by not caching misordered
+   data: design and implementation time for the transport entity and CPU
+   processing time during execution.  Savings  in  both  categories
+   accrue  because a non-caching implementation is simpler in its buffer
+   management.  Data TPDUs are discarded rather than being reordered.
+   This avoids the overhead of managing the gaps  in  the  received
+   data  sequence space, searching of sequenced message lists, and
+   inserting retransmitted data messages into the lists.
+
+8.2.4.1.2   Nth acknowledgement.
+
+   In general, an acknowledgement message  is  sent  after receipt of
+   every N data messages on a connection. If N is small compared to the
+   credit offered, then a finer granularity of buffer  control  is
+   afforded  to  the  data sender's buffer management function.  Data
+   messages are confirmed in small groups,  allowing buffers to be
+   reused sooner than if N were larger.  The cost of having N small is
+   twofold.  First, more acknowledgement  messages must be generated by
+   one transport entity and processed by another, consuming some of  the
+   CPU resource  at  both  ends  of a connection.  Second, the
+   acknowledgement messages consume transmission bandwidth,  which may
+   be expensive or limited.
+
+   For larger  N,  buffer  management  is  less  efficient because the
+   granularity with which buffers are controlled is N times the maximum
+   TPDU size.  For example, when data  messages are  transmitted to a
+   receiving entity employing this strategy with large N, N data
+   messages must be  sent  before an  acknowledgement  is  returned
+   (although the window timer causes the acknowledgement to  be  sent
+   eventually regardless  of  N).  If the minimum credit allocation for
+   continuous operation is actually  a  fraction  of  N,  a credit  of N
+   must still be offered, and N receive buffers reserved, to achieve a
+   continuous  flow  of  data  messages.  Thus,  more  receive  buffers
+   are used than are actually needed.  (Alternatively, if one relies on
+   the timer,  which  must  be adjusted to the receipt time for N and
+   will not expire until some time after the fraction of N has been
+   sent,  there  may be idle time.)
+
+   The choice of values for N depends on several factors.  First, if the
+
+
+
+McCoy                                                          [Page 58]
+
+RFC 1008                                                       June 1987
+
+
+   rate at which DT TDPUs are arriving is relatively low, then there is
+   not much justification for using a value for N that exceeds 2.  On
+   the other hand, if the DT TPDU arrival rates is high or the TPDU's
+   arrive in large groups (e.g., in a frame from a satellite link), then
+   it may be reasonable to use a larger value for N, simply to avoid the
+   overhead of generating and sending the acknowledgements while
+   procesing the DT TPDUs.  Second, the value of N should be related to
+   the maximum credit to be offered. Letting C be the maximum credit to
+   be offered, one should choose N < C/2, since the receipt of C TPDUs
+   without acknowledging will provoke sending one in any case. However,
+   since the extended formats option for transport provides max C =
+   2**16 - 1, a choice of N = 2**15 - 2 is likely to cause some of the
+   sender's retransmission timers to expire.  Since the retransmitted
+   TPDU's will arrive out of sequence, they will provoke the sending of
+   AK TPDU's.  Thus, not much is gained by using an N large.  A better
+   choice is N = log C (base 2).  Third, the value of should be related
+   to the maximum TPDU size used on the connection and the overall
+   buffer management. For example, the buffer management may be tied to
+   the largest TPDU that any connection will use, with each connection
+   managing the actual way in which the negotiated TPDU size relates to
+   this buffer size.  In such case, if a connection has negotiated a
+   maximum TPDU size of 128 octets and the buffers are 2048 octets, it
+   may provide better management to partially fill a buffer before
+   acknowledging.  If the example connection has two buffers and has
+   based offered credit on this, then one choice for N could be 2*log(
+   2048/128 ) = 8.  This would mean that an AK TPDU would be sent when a
+   buffer is half filled ( 2048/128 = 16 ), and a double buffering
+   scheme used to manage the use of the two buffers.  the use of the t
+   There are two studies which indicate that, in many cases, 2 is a good
+   choice for N [COL85, BRI85].  The increased granularity in buffer
+   management is reasonably small when compared to the credit
+   allocation, which ranges from 8K to 120K octets in the studies cited.
+   The benefit is that the number of acknowledgements generated (and
+   consumed) is cut approximately in half.
+
+8.2.4.1.3   Selective acknowledgement.
+
+   Selective acknowledgement is an option that allows misordered data
+   messages to be confirmed even in the presence of gaps in the received
+   message sequence.   (Note that selective  acknowledgement  is  only
+   meaningul whe caching out-of-orderdata messags.)  The  advantage  to
+   using  this mechanism  is hat i grealy reduces the number of
+   unnecessary retransmissions, thus saving both  computing  time  and
+   transmission bandwidth [COL85] (see the discussion in Part 8.2.4.1.1
+   for  more  details).
+
+8.2.4.2   Flow control confirmation and fast retransmission.
+
+   Flow control confirmation (FCC) is a mechanism of the transport
+   protocol whereby acknowledgement messages containing critical flow
+   control information are confirmed.  The critical  acknowledgement
+
+
+
+McCoy                                                          [Page 59]
+
+RFC 1008                                                       June 1987
+
+
+   messages are those  that open a closed flow control window and
+   certain ones that occur subsequent  to a credit reduction.  In
+   principle, if these critical messages are lost, proper
+   resynchroniztion of the flow control relies on the window timer,
+   which is generally of relatively long duration.   In order to reduce
+   delay in resynchronizing the flow control, the receiving entity can
+   repeatedly send, within short intervals, AK TPDUs carrying a request
+   for confirmation of the flow control state, a procedure known as
+   "fast" retransmission (of the acknowledgement).  If the sender
+   responds with an AK TPDU carrying an FCC parameter, fast
+   retransmission is halted.  If no AK TPDU carrying the FCC parameter
+   is received, the fast transmission halts after having reached a
+   maximum number of retransmissions, and the window timer resumes
+   control of AK TPDU transmission.  It should be noted that FCC is an
+   optional mechanism of transport and the data sender is not required
+   to respond to a request for confirmation of the flow control state
+   wih an AK TPDU carrying the FCC parameter.
+
+   Some considerations for deciding whether or not to use FCC and fast
+   retransmisson procedures are as follows:
+
+    1) likelihood of credit reduction on a given transport connection;
+
+    2) probability of TPDU loss;
+
+    3) expected window timer period;
+
+    4) window size; and
+
+    5) acknowledgement strategy.
+
+   At this time, there is no reported experience with using FCC and fast
+   retransmission.  Thus, it is not known whether or not the procedures
+   produce sufficient reduction of resynchronization delay to warrant
+   implementing them.
+
+   When implementing fast retransmission, it is suggested that the timer
+   used for the window timer be employed as the fast timer, since the
+   window is disabled during fast retransmission in any case.  This will
+   avoid having to manage another timer.  The formal description
+   expressed the fast retransmission timer as a separate timer for
+   clarity.
+
+8.2.4.3   Concatenation of acknowledgement and data.
+
+   When full duplex communication is being operated by two transport
+   entities, data and acknowledgement TPDUs from each one of the
+   entities travel in the same direction.  The transport protocol
+   permits concatenating AK TPDUs in the same NSDU as a DT TPDU.  The
+   advantage of using this feaure in an implementation is that fewer
+   NSDUs will be transmitted, and, consequently, fewer total octets will
+
+
+
+McCoy                                                          [Page 60]
+
+RFC 1008                                                       June 1987
+
+
+   be sent, due to the reduced number of network headers transmitted.
+   However, when operating over the IP, this advantage may not
+   necessarily be recognized, due to the possible fragmentation of the
+   NSDU by the IP.  A careful analysis of the treatment of the NSDU in
+   internetwork environments should be done to determine whether or not
+   concatenation of TPDUs is of sufficient benefit to justify its use in
+   that situation.
+
+8.2.5   Retransmission policies.
+
+   There are primarily two  retransmission  policies  that can be
+   employed in a transport implementation.  In the first of these, a
+   separate retransmission timer  is  initiated  for each  data  message
+   sent by the transport entity.  At first glance, this approach appears
+   to be simple and  straightforward to implement.  The deficiency of
+   this scheme is that it is inefficient.  This derives from two
+   sources.  First,  for each data message transmitted, a timer must be
+   initiated and cancelled, which consumes a significant amount of  CPU
+   processing  time  [BRI85].   Second, as the list of outstanding
+   timers grows, management of the list also  becomes  increasingly
+   expensive.   There  are  techniques  which  make list management more
+   efficient, such as a list per connection and hashing,  but
+   implementing  a  policy of one retransmission timer per transport
+   connection is a superior choice.
+
+   The second retransmission policy, implementing one retransmission
+   timer for each transport conenction, avoids some of the
+   inefficiencies cited above: the  list  of  outstanding  timers  is
+   shorter by approximately an order of magnitude.  However, if the
+   entity receiving the data is generating an  acknowledgement for
+   every  data message, the timer must still be cancelled and restarted
+   for each  data/acknowledgement  message pair  (this is an additional
+   impetus for implementing an Nth acknowledgement policy with N=2).
+
+   The rules governing the  single  timer  per  connection scheme are
+   listed below.
+
+          1) If  a  data  message  is   transmitted   and   the
+             retransmission  timer  for  the  connection is not
+             already running, the timer is started.
+
+          2) If an acknowledgement for previously unacknowledged
+             data is received, the retransmission timer is restarted.
+
+          3) If an acknowledgement message is received for  the
+             last  outstanding  data  message on the connection
+             then the timer is cancelled.
+
+          4) If the retransmission timer expires, one  or  more
+             unacknowledged  data  messages  are retransmitted,
+             beginning with the one sent earliest.  (Two
+
+
+
+McCoy                                                          [Page 61]
+
+RFC 1008                                                       June 1987
+
+
+             reports [HEA85, BRI85] suggest that the number
+             to retransmit is one.)
+
+8.3   Protocol control.
+
+8.3.1   Retransmission timer values.
+
+8.3.1.1   Data retransmission timer.
+
+   The value for the reference timer may have a significant impact on
+   the performance of the transport protocol [COL85].  However,
+   determining the proper value to use is sometimes difficult.
+   According to IS 8073, the value for the timer is computed using the
+   transit delays, Erl and Elr, the acknowledgement delay, Ar, and the
+   local TPDU processing time, x:
+
+    T1 = Erl + Elr + Ar + x
+
+   The  difficulty  in  arriving at a good retransmission timer value is
+   directly related to the variability of  these  factors Of the two,
+   Erl and Elr are the most susceptible to variation, and therefore have
+   the most impact on  determining a  good  timer  value.   The
+   following  paragraphs  discuss methods for choosing retransmission
+   timer  values  that  are appropriate in several network environments.
+
+   In a single-hop satellite environment, network delay (Erl or Elr) has
+   small variance because of the constant propagation delay of about 270
+   ms., which overshadows the other components  of network  delay.
+   Consequently, a fixed retransmission timer provides good performance.
+   For example, for a 64K  bit/sec.  link  speed and network queue size
+   of four, 650 ms. provides good performance [COL85].
+
+   Local area  networks  also  have  constant  propagation delay.
+   However, propagation delay is a relatively unimportant factor in
+   total network delay for a local area network.  Medium  access  delay
+   and  queuing delay are the significant components of network delay,
+   and (Ar + x) also plays a significant  role  in determining an
+   appropriate retransmission timer.  From the discussion presented in
+   Part 3.4.3.2 typical numbers for (Ar + x) are on the order of 5 - 6.5
+   ms and for Erl or Elr, 5 - 35 ms.  Consequently, a reasonable value
+   for  the  retransmission  timer is 100 ms.  This value works well for
+   local area networks, according to one cited report [INT85] and
+   simulation work performed at the NBS.
+
+   For better performance in an environment with long propagation
+   delays and significant variance, such as an internetwork an adaptive
+   algorithm is preferred, such as the one suggested value  for  TCP/IP
+   [ISI81].  As analyzed by Jain [JAI85], the algorithm uses an
+   exponential averaging scheme to  derive  a round trip delay estimate:
+
+               D(i)  = b * D(i-1)  +  (1-b) * S(i)
+
+
+
+McCoy                                                          [Page 62]
+
+RFC 1008                                                       June 1987
+
+
+   where D(i) is the update of the delay estimate, S(i) is  the sample
+   round  trip  time measured between transmission of a given packet and
+   receipt of its acknowledgement, and b is  a weighting   factor
+   between  0  and  1,  usually  0.5.   The retransmission timer is
+   expressed as some multiplier, k,  of D.  Small values of k cause
+   quick detection of lost packets, but result in a higher number of
+   false timeouts and,  therefore, unnecessary   retransmissions.    In
+   addition,  the retransmission timer should  be  increased
+   arbitrarily  for each case of multiple transmissions; an exponential
+   increase is suggested, such that
+
+               D(i) = c * D(i-1)
+
+   where c is a dimensionless parameter greater than one.
+
+   The remaining parameter for the adaptive  algorithm  is the  initial
+   delay  estimate,  D(0).   It  is preferable to choose a slightly
+   larger value than needed, so that unnecessary retransmissions  do
+   not  occur at the beginning.  One possibility is to measure the round
+   trip delay  during connection  establishment.   In  any  case, the
+   timer converges except under conditions of sustained congestion.
+
+8.3.1.2   Expedited data retransmission timer.
+
+   The timer which  governs  retransmission  of  expedited data should
+   be set using the normal data retransmission timer value.
+
+8.3.1.3   Connect-request/confirm retransmission timer.
+
+   Connect request and confirm  messages  are  subject  to Erl + Elr,
+   total network delay, plus  processing  time  at  the receiving
+   transport entity, if these values are known.  If an accurate estimate
+   of the round trip time is not known, two  views  can be espoused in
+   choosing the value for this timer.  First,  since  this  timer
+   governs  connection establishment, it is desirable to minimize delay
+   and so a small value can be chosen, possibly resulting in unnecessary
+   retransmissions.  Alternatively, a larger value can be used, reducing
+   the possibility of unnecessary retransmissions, but resulting in
+   longer delay in connection establishment should the connect request
+   or confirm message be lost.  The choice between these two views is
+   dictated largely by local requirements.
+
+8.3.1.4  Disconnect-request retransmission timer.
+
+   The timer which governs retransmission of  the  disconnect request
+   message  should  be  set from the normal data retransmission timer
+   value.
+
+8.3.1.5   Fast retransmission timer.
+
+   The fast  retransmission  timer  causes  critical acknowledgement
+
+
+
+McCoy                                                          [Page 63]
+
+RFC 1008                                                       June 1987
+
+
+   messages to be retransmitted avoiding delay in resynchronizing
+   credit.  This timer should be set to approximately Erl + Elr.
+
+8.3.2   Maximum number of retransmissions.
+
+   This transport parameter determines the maximum  number of  times  a
+   data message will be retransmitted.  A typical value is eight.  If
+   monitoring of network service is performed then this value can be
+   adjusted according to observed error rates.  As a high error rate
+   implies a high probability of TPDU loss, when it is desirable to
+   continue sending despite the decline in quality of service, the
+   number of TPDU retransmissions (N) should be increased and the
+   retransmission interval (T1) reduced.
+
+8.4   Selection of maximum Transport Protocol data unit size.
+
+   The choice of maximum size for TPDUs in negotiation proposals depends
+   on the application to be served and the service quality of the
+   supporting network.  In general, an application which produces large
+   TSDUs should use as large TPDUs as can be negotiated, to reduce the
+   overhead due to a large number of small TPDUs.  An application which
+   produces small TSDUs should not be affected by the choice of a large
+   maximum TPDU size, since a TPDU need not be filled to the maximum
+   size to be sent.  Consequently, applications such as file transfers
+   would need larger TPDUs while terminals would not.  On a high
+   bandwidth network service, large TPDUs give better channel
+   utilization than do smaller ones.  However, when error rates are
+   high, the likelihood for a given TPDU to be damaged is correlated to
+   the size and the frequency of the TPDUs.  Thus, smaller TPDU size in
+   the condition of high error rates will yield a smaller probability
+   that any particular TPDU will be lost.
+
+   The implementor must choose whether or not to apply a uniform maximum
+   TPDU size to all connections.  If the network service is uniform in
+   service quality, then the selection of a uniform maximum can simplify
+   the implementation.  However, if the network quality is not uniform
+   and it is desirable to optimize the service provided to the transport
+   user as much as possible, then it may be better to determine the
+   maximum size on an individual connection basis.  This can be done at
+   the time of the network service access if the characteristics of the
+   subnetwork are known.
+
+   NOTE: The maximum TPDU size is important in the calculation of the
+   flow control credit, which is in numbers of TPDUs offered.  If buffer
+   space is granted on an octet base, then credit must be granted as
+   buffer space divided by maximum TPDU size.  Use of a smaller TPDU
+   size can be equivalent to optimistic credit allocation and can lead
+   to the expected problems, if proper analysis of the management is not
+   done.
+
+
+
+
+
+McCoy                                                          [Page 64]
+
+RFC 1008                                                       June 1987
+
+
+9   Special options.
+
+   Special options may be obtained by taking advantage of the manner in
+   which IS 8073 and N3756 have been written.  It must be emphasized
+   that these options in no way violate the intentions of the standards
+   bodies that produced the standards.  Flexibility was deliberately
+   written into the standards to ensure that they do not constrain
+   applicability to a wide variety of situations.
+
+9.1   Negotiations.
+
+   The negotiation procedures in IS 8073 have deliberate ambiguities in
+   them to permit flexibility of usage within closed groups of
+   communicants (the standard defines explicitly only the behavior among
+   open communicants).  A closed group of communicants in an open system
+   is one which, by reason of organization, security or other special
+   needs, carries on certain communication among its members which is
+   not of interest or not accessible to other open system members.
+   Examples of some closed groups within DOD might be:  an Air Force
+   Command, such as the SAC; a Navy base or an Army post; a ship;
+   Defense Intelligence; Joint Chiefs of Staff. Use of this
+   characteristic does not constitute standard behavior, but it does not
+   violate conformance to the standard, since the effects of such usage
+   are not visible to non-members of the closed group.  Using the
+   procedures in this way permits options not provided by the standard.
+   Such options might permit,for example, carrying special protection
+   codes on protocol data units or for identifying DT TPDUs as carrying
+   a particular kind of message.
+
+   Standard negotiation procedures state that any parameter in a
+   received CR TPDU that is not defined by the standard shall be
+   ignored.  This defines only the behavior that is to be exhibited
+   between two open systems.  It does not say that an implementation
+   which recognizes such non-standard parameters shall not be operated
+   in networks supporting open systems interconnection.  Further, any
+   other type TPDU containing non-standard parameters is to be treated
+   as a protocol error when received.  The presumption here is that the
+   non-standard parameter is not recognized, since it has not been
+   defined.  Now consider the following example:
+
+   Entity A sends Entity B a CR TPDU containing a non-standard
+   parameter.
+
+   Entity B has been implemented to recognize the non-standard parameter
+   and to interpret its presence to mean that Entity A will be sending
+   DT TPDUs to Entity B with a special protection identifier parameter
+   included.
+
+   Entity B sends a CC TPDU containing the non-standard parameter to
+   indicate to Entity A that it has received and understood the
+   parameter, and is prepared to receive the specially marked DT TPDUs
+
+
+
+McCoy                                                          [Page 65]
+
+RFC 1008                                                       June 1987
+
+
+   from Entity A.  Since Entity A originally sent the non-standard
+   parameter, it recognizes the parameter in the CC TPDU and does not
+   treat it as a protocol error.
+
+   Entity A may now send the specially marked DT TPDUs to Entity B and
+   Entity B will not reject them as protocol errors.
+
+
+   Note that Entity B sends a CC TPDU with the non-standard parameter
+   only if it receives a CR TPDU containing the parameter, so that it
+   does not create a protocol error for an initiating entity that does
+   not use the parameter.  Note also that if Entity B had not recognized
+   the parameter in the CR TPDU, it would have ignored it and not
+   returned a CC TPDU containing the parameter.  This non-standard
+   behavior is clearly invisible and inaccessible to Transport entities
+   outside the closed group that has chosen to implement it, since they
+   are incapable of distinguishing it from errors in protocol.
+
+9.2   Recovery from peer deactivation.
+
+   Transport does not directly support the recovery of the transport
+   connection from a crashed remote transport entity.  A partial
+   recovery is possible, given proper interpretation of the state tables
+   in Annex A to IS 8073 and implementation design.  The interpretation
+   of the Class 4 state tables necessary to effect this operation is as
+   follows:
+
+   Whenever a CR TPDU is received in the state OPEN, the entity is
+   required only to record the new network connection and to reset the
+   inactivity timer.  Thus, if the initiator of the original connection
+   is the peer which crashed, it may send a new CR TPDU to the surviving
+   peer, somehow communicating to it the original reference numbers
+   (there are several ways that this can be done).
+
+
+      Whenever a CC TPDU is received in the
+
+   state OPEN, the receiver is required only to record the new network
+   connection, reset the inactivity timer and send either an AK, DT or
+   ED TPDU.  Thus, if the responder for the original connection is the
+   peer which crashed, it may send a new CC TPDU to the surviving peer,
+   communicating to it the original reference numbers.
+
+   In order for this procedure to operate properly, the situation in a.,
+   above, requires a CC TPDU to be sent in response.  This could be the
+   original CC TPDU that was sent, except for new reference numbers.
+   The original initiator will have sent a new reference number in the
+   new CR TPDU, so this would go directly into the CC TPDU to be
+   returned.  The new reference number for the responder could just be a
+   new assignment, with the old reference number frozen.  In the
+   situation in b., the originator could retain its reference number (or
+
+
+
+McCoy                                                          [Page 66]
+
+RFC 1008                                                       June 1987
+
+
+   assign a new one if necessary), since the CC TPDU should carry both
+   old reference numbers and a new one for the responder (see below).
+   In either situation, only the new reference numbers need be extracted
+   from the CR/CC TPDUs, since the options and parameters will have been
+   previously negotiated.  This procedure evidently requires that the CR
+   and CC TPDUs of each connection be stored by the peers in nonvolatile
+   memory, plus particulars of the negotiations.
+
+   To transfer the new reference numbers, it is suggested that the a new
+   parameter in the CR and CC TPDU be defined, as in Part 9.1, above.
+   This parameter could also carry the state of data transfer, to aid in
+   resynchronizing, in the following form:
+
+    1) the last DT sequence number received by the peer that crashed;
+
+    2) the last DT sequence number sent by the peer that
+       crashed;
+
+    3) the credit last extended by the peer that crashed;
+
+    4) the last credit perceived as offered by the surviving peer;
+
+    5) the next DT sequence number the peer that crashed expects to
+       send (this may not be the same as the last one sent, if the last
+       one sent was never acknowledged);
+
+    6) the sequence number of an unacknowledged ED TPDU, if any;
+
+    7) the normal data sequence number corresponding to the
+       transmission of an unacknowledged ED TPDU, if any (this is to
+       ensure the proper ordering of the ED TPDU in the normal data
+       flow);
+
+   A number of other considerations must be taken into account when
+   attempting data transfer resynchronization.  First, the recovery will
+   be greatly complicated if subsequencing or flow control confirmation
+   is in effect when the crash occurs.  Careful analysis should be done
+   to determine whether or not these features provide sufficient benefit
+   to warrant their inclusion in a survivable system.  Second,
+   non-volatile storage of TPDUs which are unacknowledged must be used
+   in order that data loss at the time of recovery can be minimized.
+   Third, the values for the retranmsission timers for the communicating
+   peers must allow sufficient time for the recovery to be attempted.
+   This may result in longer delays in retransmitting when TPDUs are
+   lost under normal conditions. One way that this might be achieved is
+   for the peers to exchange in the original CR/CC TPDU exchange, their
+   expected lower bounds for the retransmission timers, following the
+   procedure in Part 9.1.  In this manner, the peer that crashed may be
+   determine whether or not a new connection should be attempted. Fourth,
+   while the recovery involves directly only the transport peers when
+   operating over a connectionless network service, recovery when
+
+
+
+McCoy                                                          [Page 67]
+
+RFC 1008                                                       June 1987
+
+
+   operating over a connection-oriented network service requires some
+   sort of agreement as to when a new network connection is to be
+   established (if necessary) and which peer is responsible for doing
+   it.  This is required to ensure that unnecessary network
+   connections are not opened as a result of the recovery.  Splitting
+   network connections may help to ameliorate this problem.
+
+9.3   Selection of transport connection reference numbers.
+
+   In N3756, when the reference wait period for a connection begins, the
+   resources associated with the connection are released and the
+   reference number is placed in a set of frozen references.  A timer
+   associated with this number is started, and when it expires, the
+   number is removed from the set.  A function which chooses reference
+   numbers checks this set before assigning the next reference number.
+   If it is desired to provide a much longer period by the use of a
+   large reference number space, this can be met by replacing the
+   implementation dependent function "select_local_ref" (page TPE-17 of
+   N3756) by the following code:
+
+    function select_local_ref : reference_type;
+
+    begin
+    last_ref := (last_ref + 1) mod( N+1 ) + 1;
+    while last_ref in frozen_ref[class_4] do
+              last_ref := (last_ref + 1) mod( N+1 ) + 1;
+    select_local_ref := last_ref;
+    end;
+
+   where "last_ref" is a new variable to be defined in declarations
+   (pages TPE-10 - TPE-11), used to keep track of the last reference
+   value assigned, and N is the length of the reference number cycle,
+   which cannot exceed 2**16 - 1 since the reference number fields in
+   TPDUs are restricted to 16 bits in length.
+
+9.4   Obtaining Class 2 operation from a Class 4 implementation.
+
+   The operation of Class 4 as described in IS 8073 logically contains
+   that of the Class 2 protocol.  The formal description, however, is
+   written assuming Class 4 and Class 2 to be distinct.  This was done
+   because the description must reflect the conformance statement of IS
+   8073, which provides that Class 2 alone may be implemented.
+
+   However, Class 2 operation can be obtained from a Class 4
+   implementation, which would yield the advantages of lower complexity,
+   smaller memory requirements, and lower implementation costs as
+   compared to implementing the classes separately.  The implementor
+   will have to make the following provisions in the transport entity
+   and the Class 4 transport machine to realize Class 2 operation.
+
+
+
+
+
+McCoy                                                          [Page 68]
+
+RFC 1008                                                       June 1987
+
+
+     1)   Disable all timers.  In the formal description, all Class 4
+          timers except the reference timer are in the Class 4 TPM.
+          These timers can be designed at the outset to be enabled or
+          not at the instantiation of the TPM.  The reference timer is
+          in the Transport Entity module (TPE) and is activated by the
+          TPE recognizing that the TPM has set its "please_kill_me"
+          variable to "freeze".  If the TPM sets this variable instead
+          to "now", the reference timer for that transport connection is
+          never started.  However, IS 8073 provides that the reference
+          timer can be used, as a local entity management decision, for
+          Class 2.
+
+          The above procedure should be used when negotiating from Class
+          4 to Class 2.  If Class 2 is proposed as the preferred class,
+          then it is advisable to not disable the inactivity timer, to
+          avoid the possibility of deadlock during connection
+          establishment if the peer entity never responds to the CR
+          TPDU.  The inactivity timer should be set when the CR TPDU is
+          sent and deactivated when the CC TPDU is received.
+
+     2)   Disable checksums.  This can be done simply by ensuring that
+          the boolean variable "use_checksums" is always set to "false"
+          whenever Class 2 is to be proposed or negotiated.
+
+     3)   Never permit flow control credit reduction. The formal
+          description makes flow control credit management a function of
+          the TPE operations and such management is not reflected in the
+          operation of the TPM.  Thus, this provision may be handled by
+          always making the "credit-granting" mechanism aware of the
+          class of the TPM being served.
+
+     4)   Include Class 2 reaction to network service events.  The Class
+          4 handling of network service events is more flexible than
+          that of Class 2 to provide the recovery behavior
+          characteristic of Class 4.  Thus, an option should be provided
+          on the handling of N_DISCONNECT_indication and
+          N_RESET_indication for Class 2 operation.  This consists of
+          sending a T_DISCONNECT_indication to the Transport User,
+          setting "please_kill_me" to "now" (optionally to "freeze"),
+          and transitioning to the CLOSED state, for both events.  (The
+          Class 4 action in the case of the N_DISCONNECT is to remove
+          the network connection from the set of those associated with
+          the transport connection and to attempt to obtain a new
+          network connection if the set becomes empty.  The action on
+          receipt of the N_RESET is to do nothing, since the TPE has
+          already issued the N_RESET_response.)
+
+     5)   Ensure that TPDU parameters conform to Class 2.  This implies
+          that subsequence numbers should not be used on AK TPDUs, and
+          no flow control confirmation parameters should ever appear in
+          an AK TPDU.  The checksum parameter is prevented from
+
+
+
+McCoy                                                          [Page 69]
+
+RFC 1008                                                       June 1987
+
+
+          appearing by the "false" value of the "use_checksums"
+          variable.  (The acknowledgement time parameter in the CR and
+          CC TPDUs will not be used, by virtue of the negotiation
+          procedure.  No special assurance for its non-use is
+          necessary.)
+
+          The TPE management of network connections should see to it
+          that splitting is never attempted with Class 4 TPMs running as
+          Class 2.  The handling of multiplexing is the same for both
+          classes, but it is not good practice to multiplex Class 4 and
+          Class 2 together on the same network connection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCoy                                                          [Page 70]
+
+RFC 1008                                                       June 1987
+
+
+10   References.
+
+     [BRI85]  Bricker, A., L. Landweber, T.  Lebeck,  M.  Vernon,
+              "ISO  Transport Protocol Experiments," Draft Report
+              prepared by DLS Associates for the  Mitre  Corporation,
+              October 1985.
+
+     [COL85]  Colella, Richard,  Marnie  Wheatley,  Kevin  Mills,
+              "COMSAT/NBS  Experiment Plan for Transport Protocol,"
+              NBS, Report No. NBSIR 85-3141, May l985.
+
+     [CHK85]  Chernik, C. Michael, "An NBS Host to Front End
+              Protocol," NBSIR 85-3236, August 1985.
+
+     [CHO85]  Chong, H.Y., "Software Development and Implementation
+              of NBS Class 4 Transport Protocol," October 1985
+              (available from the author).
+
+     [HEA85]  Heatley, Sharon, Richard Colella, "Experiment Plan:
+              ISO Transport Over IEEE 802.3 Local Area Network,"
+              NBS, Draft Report (available from the authors),
+              October 1985.
+
+     [INT85]  "Performance Comparison Between  186/51  and  552,"
+              The  Intel Corporation, Reference No. COM,08, January
+              1985.
+
+     [ISO84a] IS 8073 Information Processing - Open Systems
+              Interconnection - Transport Protocol Specification,
+              available from ISO TC97/SC6 Secretariat, ANSI,
+              1430 Broadway, New York, NY 10018.
+
+     [ISO84b] IS 7498 Information Processing - Open Systems
+              Interconnection - Basic Reference Model, available
+              from ANSI, address above.
+
+     [ISO85a] DP 9074 Estelle - A Formal Description Technique
+              Based on an Extended State Transition Model,
+              available from ISO TC97/SC21 Secretariat, ANSI,
+              address above.
+
+     [ISO85b] N3756 Information Processing - Open Systems
+              Interconnection - Formal Description of IS 8073
+              in Estelle. (Working Draft, ISO TC97/SC6)
+
+
+
+
+
+
+
+
+
+
+McCoy                                                          [Page 71]
+
+RFC 1008                                                       June 1987
+
+
+     [ISO85c] N3279 Information Processing - Open Systems
+              Interconnection - DAD1, Draft Addendum to IS 8073
+              to Provide a Network Connection Management
+              Service, ISO TC97/SC6 N3279, available from
+              SC6 Secretariat, ANSI, address above.
+
+     [JAI85]  Jain, Rajendra K., "CUTE: A Timeout  Based  Congestion
+              Control Scheme for Digitial Network Architecture,"
+              Digital Equipment Corporation (available from the
+              author), March 1985.
+
+     [LIN85]  Linn, R.J., "The Features and Facilities of Estelle,"
+              Proceedings of the IFIP WG 6.1 Fifth International
+              Workshop on Protocol Specification, Testing and
+              Verification, North Holland Publishing, Amsterdam,
+              June 1985.
+
+     [MIL85a] Mills, Kevin L., Marnie Wheatley, Sharon Heatley,
+              "Predicting Transport Protocol Performance",
+              (in preparation).
+
+     [MIL85b] Mills, Kevin L., Jeff Gura, C. Michael Chernik,
+              "Performance Measurement of OSI Class 4 Transport
+              Implementations," NBSIR 85-3104, January 1985.
+
+     [NAK85]  Nakassis, Anastase, "Fletcher's Error Detection
+              Algorithm: How to Implement It Efficiently and
+              How to Avoid the Most Common Pitfalls," NBS,
+              (in preparation).
+
+     [NBS83]  "Specification of a Transport Protocol for
+              Computer Communications, Volume 3: Class 4
+              Protocol," February 1983 (available from
+              the National Technical Information Service).
+
+     [NTA84]  Hvinden, Oyvind, "NBS Class 4 Transport Protocol,
+              UNIX 4.2 BSD Implementation and User Interface
+              Description," Norwegian Telecommunications
+              Administration Establishment, Technical Report
+              No. 84-4053, December 1984.
+
+     [NTI82]  "User-Oriented Performance Measurements on the
+              ARPANET: The Testing of a Proposed Federal
+              Standard," NTIA Report 82-112 (available from
+              NTIA, Boulder CO)
+
+     [NTI85]  "The OSI Network Layer Addressing Scheme, Its
+              Implications, and Considerations for Implementation",
+              NTIA Report 85-186, (available from NTIA, Boulder CO)
+
+     [RFC85]  Mills, David, "Internet Delay Experiments," RFC889,
+
+
+
+McCoy                                                          [Page 72]
+
+RFC 1008                                                       June 1987
+
+
+              December 1983 (available from the Network Information
+              Center).
+
+     [SPI82]  Spirn, Jeffery R., "Network Modeling with Bursty
+              Traffic and Finite Buffer Space," Performance
+              Evaluation Review, vol. 2, no. 1, April 1982.
+
+     [SPI84]  Spirn, Jeffery R., Jade Chien, William Hawe,
+              "Bursty Traffic Local Area Network Modeling,"
+              IEEE Journal on Selected Areas in Communications,
+              vol. SAC-2, no. 1, January 1984.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCoy                                                          [Page 73]
+