As per Relevance of the word transport, we have this rfc below:
Network Working Group Wayne
Request for Comments: 1008 June 1987
IMPLEMENTATION GUIDE
FOR
ISO TRANSPORT
Status of this
This RFC is being distributed to members of the Internet
in order to solicit comments on the Implementors Guide. While
document may not be directly relevant to the research
of the Internet, it may be of some interest to a number of
and implementors. Distribution of this memo is unlimited
IMPLEMENTATION GUIDE FOR THE ISO TRANSPORT
1 Interpretation of formal description
It is assumed that the reader is familiar with both the
description technique, Estelle [ISO85a], and the transport
as described in IS 8073 [ISO84a] and in N3756 [ISO85b].
1.1 General interpretation guide
The development of the formal description of the ISO
Protocol was guided by the three following assumptions
1. A generality
The formal description is intended to express all of the
that any implementation is to demonstrate, while not being
to the way that any particular implementation would realize
behavior within its operating context
2. Preservation of the
nondeterminism of IS 8073
The text description in the IS 8073 contains deliberate
of nondeterminism and indeterminism in the behavior of
transport protocol for the sake of flexibility in application
(Nondeterminism in this context means that the order of
for a set of actions that can be taken is not specified
Indeterminism means that the execution of a given action cannot
predicted on the basis of system state or the executions of
actions.)
McCoy [Page 1]
RFC 1008 June 1987
3. Discipline in the usage of
A given feature of Estelle was to be used only if the nature
the mechanism to be described strongly indicates its usage
or to adhere to the generality principle, or to retain
nondeterminism of IS 8073.
Implementation efficiency was not a particular goal nor was
an attempt to directly correlate Estelle mechanisms and
to implementation mechanisms and features. Thus, the
does not represent optimal behavior for the implemented protocol
These assumptions imply that the formal description contains
levels of abstraction than would be expected in a description
a particular operating environment. Such abstraction is essential
because of the diversity of networks and network elements by
implementation and design decisions are influenced. Even
operating environments are essentially identical, design choice
originality in solving a technical problem must be allowed
The same behavior may be expressed in many different ways.
goal in producing the transport formal description was to
to capture this equivalence. Some mechanisms of transport are
fully described or appear to be overly complicated because of
adherence to the generality principle. Resolution of
situations may require significant effort on the part of
implementor
Since the description does not represent optimal behavior for
implemented protocol, implementors should take the three
above into account when using the description to implement
protocol. It may be advisable to adapt the standard description
such a way that
a. abstractions (such as modules, channels,
transitions and binding comments) are interpreted and
as mechanisms appropriate to the operating environment
service requirements
b. modules, transitions, functions and procedures
material irrelevant to the classes or options to be
are reduced or eliminated as needed;
c. desired real-time behavior is accounted for
The use in the formal description of an Estelle feature (
instance, "process"), does not imply that an implementation
necessarily realize the feature by a synonymous feature of
operating context. Thus, a module declared to be a "process" in
Estelle description need not represent a real process as seen by
host operating system; "process" in Estelle refers to
McCoy [Page 2]
RFC 1008 June 1987
synchronization properties of a set of procedures (transitions).
Realizations of Estelle features and mechanisms are dependent in
essential way upon the performance and service an implementation
to provide. Implementations for operational usage have much
stringent requirements for optimal behavior and robustness than
implementations used for simulated operation (e.g., correctness
conformance testing). It is thus important that an
implementation realize the abstract features and mechanisms of
formal description in an efficient and effective manner
For operational usage, two useful criteria for interpretation
formal mechanisms are
[1] minimization of delays caused by the
itself; e.g.,
--transit delay for a medium that realizes
--access delay or latency for channel
--scheduling delay for timed
(spontaneous transitions with delay clause
--execution scheduling for modules
exported variables (delay in
variable
[2] minimization of the "handling" required by
invocation of the mechanism; e.g.,
--module execution scheduling and
--synchronization or protocols for
--predicate evaluation for
Spontaneous transitions represent nondeterminism and indeterminism
so that uniform realization of them in an implementation must
questioned as an implementation strategy. The time at which
action described by a spontaneous transition will actually
place cannot be specified because of one or more of the
situations
a. it is not known when, relative to any specific event
the protocol (e.g., input network, input from user,
McCoy [Page 3]
RFC 1008 June 1987
expirations), the conditions enabling the transition
actually occur
b. even if the enabling conditions are ultimately deterministic
it is not practical to describe all the possible ways
could occur, given the different ways in which
will examine these conditions;
c. a particular implementation may not be concerned with
enabling conditions or will account for them in some
way; i.e., it is irrelevant when the action takes place,
ever
As an example of a), consider the situation when splitting over
network connection, in Class 4, in which all of the
connections to which the transport connection has been assigned
all disconnected, with the transport connection still in the
state. There is no way to predict when this will happen, nor
there any specific event signalling its occurrence. When it
occur, the transport protocol machine may want to attempt to
a new network connection
As an example of b), consider that timers may be
succinctly in Estelle by transitions similar to the following
from A to
provided predicate delay( timer_interval )
(* action driven by timeout *)
end
But there are operations for which the timer period may need
be very accurate (close to real time) and others in which
delay in executing the action can be tolerated. The
must determine the optimal behavior desired for each
and use an appropriate mechanism to realize it, rather
using a uniform approach to implementing all
transitions
As an example of the situation in c), consider the closing of
unused network connection. If the network is such that the
of letting the network connection remain open is small
cost of opening it, then an implementation might not want
consider closing the network connection until, say, the weekend
Another implementation might decide to close the
connection within 30 msec after discovering that the
is not busy. For still another implementation, this could
McCoy [Page 4]
RFC 1008 June 1987
meaningless because it operates over a connectionless
service
If a description has only a very few spontaneous transitions,
it may be relatively easy to implement them literally (i.e.,
schedule and execute them as Estelle abstractly does) and
incur the overhead from examining all of the variables that
in the enabling conditions. However, the number and complexity
the enabling conditions for spontaneous transitions in the
description strongly suggests that an implementation which
spontaneous transitions literally will suffer badly from
overhead
1.2 Guide to the formal description
So that implementors gain insight into interpretation of
mechanisms and features of the formal description of transport,
following paragraphs discuss the meanings of such mechanisms
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
Protocol Entity (TPE) module, as given in the formal description
>From an abstract operational viewpoint, the transport
Machines (TPMs) and the Slaves operate as child processes of the
TPE process. Each TPM represents the endpoint actions of
protocol on a single transport connection. The Slave
control of data output to the network. The internal operations
the TPMs and the Slave are discussed below in separate sections
This structure permits describing multiple connections,
and splitting on network connections, dynamic existence of
and class negotiation. In the diagram, interaction points
denoted by the symbol "O", while (Estelle) channels joining
interaction points are denoted
McCoy [Page 5]
RFC 1008 June 1987
*
*
*
The symbol "X" represents a logical association through variables
and the
<<<<<<<
>>>>>>>
indicate the passage of data, in the direction of the
vertices, by way of these associations. The acronyms TSAP
NSAP denote Transport Service Access Point and Network
Access Point, respectively. The structure of the TSAPs
NSAPs shown is discussed further on, in Parts 1.2.2.1
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 |<------>|
McCoy [Page 6]
RFC 1008 June 1987
The structuring principles of Estelle provide a formal means
expressing and enforcing certain synchronization properties
communicating processes. It must be stressed that the
implied by Estelle descriptions need not and in some cases
not be implemented. The intent of the structure in the
formal description is to state formally the synchronization
access tovariables shared by the transport entity and the
connection endpoints and to permit expression of dynamic
within the entity. In nearly all aspects of operation except these
it may be more efficient in some implementation environments
permit the TPE and the TPMs to run in parallel (the
scheduling specifically excludes the parallel operation of the
and the TPMs). This is particularly true of internal
("housekeeping") actions and those actions not directly related
communication between the TPE and the TPMs or instantiation of TPMs
Typical actions of this latter sort are: receipt of NSDUs from
network, integrity checking and decoding of TPDUs, and
connection management. Such actions could have been collected
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
as expressing relationships among actions and objects and
explicit implementation behavior
1.2.1.2 Transport protocol entity operation
The details of the operation of the TPE from a conceptual point
view are given in the SYS section of the formal description
However, there are several further comments that can be
regarding the design of the TPE. The Estelle body for the
module has no state variable. This means that any transition
the TPE may be enabled and executed at any time. Choice
transition is determined primarily by priority. This
that the semantics of the TPE transitions is that of
traps
The TPE handles only the T-CONNECT-request from the user and the
handle all other user input. All network events are handled by
TPE, in addition to resource management to the extent defined in
description. The TPE also manages all aspects of
references, including reference freezing. The TPE does
explicitly manage the CPU resource for the TPMs, since this
implied by the Estelle scheduling across the module hierarchy
Instantiation of TPMs is also the responsibility of the TPE, as
TPM release when the transport connection is to be closed. Once
TPM is created, the TPE does not in general interfere with TPM'
activities, with the following exceptions: the TPE may reduce
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
exported variables owned by the TPMs, and through a channel
McCoy [Page 7]
RFC 1008 June 1987
passes TPDUs to be transmitted to the remote peer. This channel
not directly connected to any network connection, so
interaction on it carries a reference number indicating which
connection is to be used. Since the reference is only a reference
this permits usage of this mechanism when the network service
connectionless, as well. The mechanism provides flexibility
both splitting and multiplexing on network connections
One major function that the TPE performs for all its TPMs is that
initial processing of received TPDUs. First, a set of
checks is made to determine if each TPDU in an NSDU is decodable
a. PDU length indicators and their sums are checked against
NSDU length for consistency
b. TPDU types versus minimum header lengths for the types
checked, so that if the TPDU can be decoded, then
association to TPMs can be made without any problem
c. TPDUs are searched for checksums and the local checksum
computed for any checksum found;
d. parameter codes in variable part of headers are checked
applicable
These integrity checks guarantee that an NSDU passing the check
be separated as necessary into TPDUs, these TPDUs can be
to the transport connections or to the Slave as appropriate and
can be further decoded without error
The TPE next decodes the fixed part of the TPDU headers to
the disposition of the TPDU. The Slave gets TPDUs that cannot
assigned to a TPM (spurious TPDU). New TPMs are created in
to CR TPDUs that correspond to a TSAP for this TPE
All management of NSAPs is done by the TPE. This consists of
track of all network connections, their service
characteristics and their availability, informing the TPMs
with these network connections
The TPE has no timer module as such. Timing is handled by using
DELAY feature of Estelle, since this feature captures the essence
timing without specifying how the actual timing is to be
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
using the Estelle channel/interaction point formalism. (Note:
McCoy [Page 8]
RFC 1008 June 1987
term "channel" in Estelle is a keyword that denotes a set
interactions which may be exchanged at interaction points [LIN85].
However, it is useful conceptually to think of "channel" as
a communication path that carries the interactions between modules.)
The abstract service primitives for a SAP are interactions
channels entering and leaving the TPE. The transport user
considered to be at the end of the channel connected to the
SAP (TSAP) and the network service provider is considered to be
the end of the channel connected to the network SAP (NSAP).
interaction put into a channel by some module can be considered
move instantaneously over the channel onto a queue at the other end
The sender of such an interaction no longer has access to
interaction once it has been put into the channel. The operation
the system modeled by the formal description has been designed
this semantics in mind, rather than the equivalent but much
abstract Estelle semantics. (In the Estelle semantics,
interaction point is considered to have associated with it
unbounded queue. The "attach" and "connect" primitives bind
interaction points, such that an action, implied by the
"out", at one interaction point causes a specified interaction to
placed onto the queue associated with the other interaction point.)
The sections that follow discuss the TSAP and the NSAP and the
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
be associated with a transport entity, and multiple users may
associated with a given TSAP. A situation in which this is useful
when it is desirable to have a certain quality of service
with a given TSAP. For example, one TSAP could be reserved
applications requiring a high throughput, such as file transfer.
operation of transport connections associated with this TSAP
then be designed to favor throughput. Another TSAP might serve
requiring short response time, such as terminals. Still another
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
array of Estelle interaction points. This array is indexed by a
address (T_address) and a Transport Connection Endpoint
(TCEP_id). Note that this dimensional object (TSAP) is
simply to be a uniform set of abstract interfaces. The indices
be of (Pascal) ordinal type in Estelle. However, the actual
structure of TSAPs may not conform easily to such typing in
implementation. Consequently, the indices as they appear in
formal description should be viewed as an organizational
rather than as an explicit way of associating objects in
operational setting. For example, actual TSAP addresses might
kept in some kind of table, with the table index being used
reference objects associated with the TSAP
McCoy [Page 9]
RFC 1008 June 1987
One particular issue concerned with realizing TSAPs is that of
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
T_address/TCEP_id pair. However, this gives no insight as to how
mechanism could work. Some approaches to this problem are
in Part 5.
Another issue is that of flow control on the TSAP channels.
control is not part of the semantics for the Estelle channel, so
problem must be dealt with in another way. The formal
gives an abstract definition of interface flow control using
and Estelle mechanisms. This abstraction resembles many
schemes for flow control, but the realization of flow control
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
with it. For example, the virtual circuits of X.25 correspond
this notion. On the other hand, an NSAP may have no
connection associated with it, for example when the service at
NSAP is connectionless. This certainly will be the case
transport operates on a LAN or over IP. Consequently, although
syntactical appearance of the NSAP in the formal description
similar to that for the TSAP, the semantics are essentially
[NTI85].
Distinct NSAPs can correspond or not to physically distinct networks
Thus, one NSAP could access X.25 service, another might access
IEEE 802.3 LAN, while a third might access a satellite link. On
other hand, distinct NSAPs could correspond to different addresses
the same network, with no particular rationale other than
management for the distinction. There are performance and
design issues that arise in considering how NSAPs should be
in such situations. For example, if distinct NSAPs
distinct networks, then a transport entity which must handle
resource management for the transport connections and operate
connections as well may have trouble keeping pace with data
concurrently from two LANs and a satellite link. It might be
better design solution to separate the management of the
connection resources from that of the NSAP resources and inputs,
even to provide separate transport entities to handle some of
different network services, depending on the service quality to
maintained. It may be helpful to think of the (total)
service as not necessarily being provided by a single
entity--several distinct entities can reside at the transport
on the same end-system
McCoy [Page 10]
RFC 1008 June 1987
The issues of NSAP management come primarily from connection-
network services. This is because a connectionless service is
available to all transport connections or it is available to none
representing infinite degrees of multiplexing and splitting. In
connection-oriented case, NSAP management is complicated
multiplexing, splitting, service quality considerations and
particular character of the network service. These issues
discussed further in Part 3.4.1. In the formal description,
connection management is carried out by means of a record
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
possible network connections, it is clear that in an
these data structures may need to be made dynamic rather than static
The connection record, indexed by NSAP and NCEP_id, consists of
Slave module reference, virtual data connections to the TPMs to
associated with the network connection, a data connection (out)
the NSAP, and a data connection to the Slave. There is also
"state" variable for keeping track of the availability of
connection, variables for managing the Slave and an
reference number to identify the connection to TPMs. A member of
network connection array associated with a TPM provides the TPM
status information on the network connection and input data (network
events and TPDUs). A considerable amount of management of
network connections is provided by the formal description,
splitting, multiplexing, service quality (when defined),
flow control, and concatenation of TPDUs. This management is
out solely by the transport entity, leaving the TPMs free to
only the explicit transport connection issues. This
scheme is flexible enough that it can be simplified and adapted
handle the NSAP for a connectionless service
The principal issue for management of connectionless NSAPs is that
buffering, particularly if the data transmission rates are high,
there is a large number of transport connections being served.
may also be desirable for the transport entity to monitor the
it is getting from the network. This would entail, for example
periodically computing the mean transmission delays for
timers or to exert backpressure on the transport connections
network access delay rises, indicating loading. (In the
description, the Slave processor provides a simple form of
buffer management: when its queue exceeds a threshold, it shuts
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
performance problem.)
McCoy [Page 11]
RFC 1008 June 1987
1.2.3 Transport Protocol Machine
Transport Protocol Machines (TPM) in the formal description are
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.
reason for this diversity is to facilitate describing
negotiations and to show clearly the actions of each class in
data transfer phase. The General TPM is instantiated when
connection request is received from a transport user or when a
TPDU is received from a remote peer entity. This TPM is replaced
a class-specific TPM when the connect response is received from
responding user or when the CC TPDU is received from the
peer entity
The General, Class 2 and Class 4 TPMs are discussed below in
detail. In an implementation, it probably will be prudent to
the Class 2 and Class 4 operations with that of the General TPM,
new variables selecting the class-specific operation as
(see also Part 9.4 for information on obtaining Class 2
from a Class 4 implementation). This may simplify and improve
behavior of the implemented protocol overall
1.2.3.1 General Transport Protocol Machine
Connection negotiation and establishment for all classes can
handled by the General Transport Protocol Machine. Some parts of
description of this TPM are sufficiently class dependent that
can safely be removed if that class is not implemented. Other
are general and must be retained for proper operation of the TPM.
General TPM handles only connection establishment and negotiation,
that only CR, CC, DR and DC TPDUs are sent or received (the
prevents other kinds of TPDUs from reaching the General TPM).
Since the General TPM is not instantiated until a T-CONNECT-
or a CR TPDU is received, the TPE creates a special
connection to the module's TSAP interaction point to pass
T-CONNECT-request event to the TPM. This provides
completeness according to the specfication of the protocol. When
TPM is to be replaced by a class-specific TPM, the sent or
CC is copied to the new TPM so that negotiation information is
lost
In the IS 8073 state tables for the various classes, the majority
the behavioral information for the automaton is contained in
connection establishment phase. The editors of the
description have retained most of the information contained in
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
McCoy [Page 12]
RFC 1008 June 1987
Class 4, in many respects. This is not accidental, in that:
conformance statement in IS 8073 links Class 2 with Class 4; and
editors of the formal description produced the Class 2
description by copying the Class 4 TPM description and
material on timers, checksums, and the like that is not part of
Class 2 operation. The suggestion of obtaining Class 2
from a Class 4 implementation, described in Part 9.4, is in
based on this adaptation
One feature of Class 2 that does not appear in Class 4, however,
the option to not use end-to-end flow control. In this mode
operation, Class 2 is essentially Class 0 with multiplexing.
fact, the formal description of the Class 0 TPM was derived
Class 2 (in IS 8073, these two classes have essentially
state tables). This implies that Class 0 operation could be
from Class 2 by not multiplexing, not sending DC TPDUs, electing
to use flow control and terminating the network connection when a
TPDU is received (expedited data cannot be used if flow control
not used). When Class 2 is operated in this mode, a
different procedure is used to handle data flow internal to the
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
Class 2 TPMs. This provides a more general model of
than does the fixed array representation and is easier to describe
Also, the fixed array representation has semantics that,
into an implementation, would produce inefficiency. Consequently
linked lists with queue management functions make up the
storage description, despite the fact that pointers have a
implementation-like flavor. One of the queue management
permits removing several TPDUs from the head of the send queue,
model the acknowledgement of several TPDUs at once, as specified
IS 8073. Each TPDU record in the queue carries the number
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
8073. One of these was put in solely to facilitate obtaining
in case no credit was granted for the CR or CC TPDU. The other
was put in to clarify operations when there is
expedited data outstanding (Class 2 does not have this state).
The timers used in the Class 4 TPM are discussed below, as is
description of end-to-end flow control
For simplicity in description, the editors of the formal
assumed that no queueing of expedited data would occur at the
interface of the receiving entity. The user has the capability
block the up-flow of expedited data until it is ready.
McCoy [Page 13]
RFC 1008 June 1987
assumption has several implications. First, an ED TPDU cannot
acknowledged until the user is ready to accept it. This is
the receipt of an EA TPDU would indicate to the sending peer that
receiver is ready to receive the next ED TPDU, which would not
true. Second, because of the way normal data flow is blocked by
sending of an ED TPDU, normal data flow ceases until the
user is ready for the ED TPDU. This suggests that the
interface should employ separate and noninterfering
for passing normal and expedited data to the user. Moreover
the mechanism for expedited data passage should be blocked only
dire operational conditions. This means that receipt of
data by the user should be a procedure (transition) that
at nearly the highest priority in the user process. The
to describing the expedited data handling in this way would entail
scheme of properly synchronizing the queued ED TPDUs with the
TPDUs received. This requires some intricate handling of DT and
sequence numbers. While this alternative may be attractive
implementations, for clarity in the formal description it
only unnecessary complication
The description of normal data TSDU processing is based on
assumption that the data the T-DATA-request refers to is
arbitrarily long. The semantic of the TSDU in this case is
to that of a file pointer, in the sense that any file pointer is
reference to a finite but arbitrarily large set of octet-strings
The formation of TPDUs from this string is analogous to reading
file in fixed-length segments--records or blocks, for example.
reassembly of TPDUs into a string is analogous to appending each
to the tail of a file; the file is passed when the end-of-
(end-of-file) is received. This scheme permits conceptual
of the entire TSDU in the receiver and avoids the question of
or not received data can be passed to the user before the EOT
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
and some special data manipulation functions of Estelle (these
not normally part of Pascal). There is one encoding
corresponding to each TPDU type, rather than a single
function that does all of them. This was done so that the
structures of the individual types could be readily discerned,
the purpose of the functions is descriptive and not
computational
The output of TPDUs from the TPM is guarded by an internal
control flag. When the TPDU is first sent, this flag is ignored
since if the TPDU does not get through, a retransmission may
care of it. However, when a retransmission is tried, the flag
heeded and the TPDU is not sent, but the retransmission count
incremented. This guarantees that either the TPDU will
be sent or the connection will time out (this despite the fact
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
made to truly run in parallel, the performance may be
enhanced
The decoding of received TPDUs is partially described in the Class 4
TPM description. Only the CR and CC TPDUs present any problems
decoding, and these are largely due to the nondeterministic order
parameters in the variable part of the TPDU headers and
locality-and class-dependent content of this variable part.
contents of this variable part (except the TSAP-IDs) do not
the association of the TPDU with a transport connection,
decoding of the variable part is not described in detail. Such
description would be very lengthy indeed because of all
possibilities and would not contribute measurably to
by the reader
1.2.4 Network Slave
The primary functions of the Network Slave are to provide
flow control in the TPE, to concatenate TPDUs into a single NSDU
to respond to the receipt of spurious TPDUs. The Slave has
internal queue on which it keeps TPDUs until the network is ready
accept them for transmission. The TPE is kept informed as to
length of queue, and the output of the TPMs is throttled if
length exceeds this some threshold. This threshold can be
to meet current operating conditions. The Slave will
the TPDUs in its queue if the option to concatenate is exercised
the conditions for concatenating are met. Concatenation is a
option, which may be exercised or not at any time
1.2.5 Timers
In the formal description timers are all modeled using a
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
provided timer_x in active_
However, the transition code is not executed until the elapsed
;from the placement of the identifier in the set is at least
to the delay parameter. The editors of the formal description
to model timers in this fashion because it provided a
expressed description of timer behavior and eliminated having
consider how timing is done in a real system or to provide
timer modules and communication to them. It is thus recommended
implementors not follow the timer model closely in implementations
considering instead the simplest and most efficient means of
permitted by the implementation environment. Implementors
McCoy [Page 15]
RFC 1008 June 1987
also note that the delay parameter is typed "integer" in the
description. No scale conversion from actual time is expressed in
timer transition, so that this scale conversion must be
when timers are realized
1.2.5.1 Transport Protocol Entity timers
There is only one timer given in the formal description of
TPE--the reference timer. The reference timer was placed here ;
that it can be used by all classes and all connections, as needed
There is actually little justification for having a reference
within the TPM--it wastes resources by holding the
endpoint, even though the TPM is incapable of responding to
input. Consequently, the TPE is responsible for all aspects
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
8073. However, the standard does recommend that an optional timer
used by Class 2 in certain cases to avoid deadlock. The
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
control, flow control and retransmissions of unacknowledged data
Each of these timers is discussed briefly below in terms of how
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
providing timely updates of flow control credit information. One
these timers is provided in each TPM. It is reset each time an
TPDU is sent, except during fast retransmission of AKs for
control confirmation, when it is disabled
1.2.5.2.2 Inactivity timer
The primary usage of the inactivity timer is to detect when
remote peer has ceased to send anything (including AK TPDUs).
timer is mandatory when operating over a connectionless
service, since there is no other way to determine whether or not
remote peer is still functioning. On a connection-oriented
service it has an additional usage since to some extent the
existence of the network connection indicates that the peer host
not crashed
Because of splitting, it is useful to provide an inactivity timer
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
network connections. The formal description provides this
in each TPM
1.2.5.2.3 Network connection timer
This timer is an optional timer used to ensure that every
connection to which a TPM is assigned gets used periodically.
prevents the expiration of the peer entity's inactivity timer for
network connection. There is one timer for each network
to which the TPM is assigned. If there is a DT or ED TPDU waiting
be sent, then it is chosen to be sent on the network connection.
no such TPDU is waiting, then an AK TPDU is sent. Thus, the NC
serves somewhat the same purpose as the window timer, but is
in scope
1.2.5.2.4 Give-up timer
There is one give-up timer for a TPM which is set whenever
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
TPDU types, for each TPM. However, this is for clarity in
description, and Part 8.2.5 presents arguments for other
to be used in implementations. Also, DT TPDUs with distinct
numbers are each provided with timers, as well. There is a
function which determines the range within the send window for
timers will be set. This has been done to express flexibility in
retransmission scheme
The flow control confirmation scheme specified in IS 8073
provides for a "fast" retransmission timer to ensure the reception
an AK TPDU carrying window resynchronization after credit
or when opening a window that was previously closed. The
description permits one such timer for a TPM. It is disabled
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
wait for a response by the peer entity to an ER TPDU. When
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
McCoy [Page 17]
RFC 1008 June 1987
as to permit flexibility in credit control schemes
acknowledgement strategies
1.2.6.1 Credit control
The credit mechanism in the formal description provides for
management of credit by the TPE. This is done through
exported by the TPMs which indicate to the TPE when credit is
and for the TPE to indicate when credit has been granted. In
manner, the TPE has control over the credit a TPM has. The
allows for reduction in credit (Class 4 only) and the possibility
precipitous window closure. The mechanism does not preclude the
of credit granted by the user or other sources, since credit need
expressed as current credit being less than some threshold.
the threshold to zero permits these other schemes. An AK TPDU
sent each time credit is updated
The end-to-end flow control is also coupled to the interface
control to the user. If the user has blocked the interface up-flow
then the TPM is prohibited from requesting more credit when
current window is used up
1.2.6.2 Acknowledgement
The mechanism for acknowledging normal data provides
sufficient to send an AK TPDU in response to every Nth DT
received where N > 0 and N may be constant or dynamically determined
Each TPM is provided with this, independent of all other TPMs,
that acknowledgement strategy can be determined separately for
transport connection. The capability of altering the
strategy is useful in operation over networks with varying
rates
1.2.6.3 Sequencing of received data
It is not specified in IS 8073 what must be done with out-of-
but within-window DT TPDUs received, except that an AK TPDU
current window and sequence information be sent. There
performance reasons why such DT TPDUs should be held (cached):
particular, avoidance of retransmissions. However, this
scheme is complicated to implement and worse to describe
without resorting to mechanisms too closely
implementation. Thus, the formal description mechanism discards
DT TPDUs and relies on retransmission to fill the gaps in the
sequence, for the sake of simplicity in the description
1.2.7 Expedited data
The transmission of expedited data, as expressed by IS 8073,
the blockage of normal data transmission until the acknowledgement
received. This is handled in the formal description by providing
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
services with high bandwidth, high transit delay and high
rates, undertaken by the NBS and COMSAT Laboratories, have shown
the protocol suffers a marked decline in its performance in
conditions. This situation has been presented to ISO, with
result that the the protocol will be modified to permit the
of normal data already accepted by the transport entity from the
before the expedited data request but not yet put onto the network
When the modification is incorporated into IS 8073, the
description will be appropriately aligned
2 Environment of implementation
The following sections describe some general approaches
implementing the transport protocol and the advantages
disadvantages of each. Certain commercial products are
throughout the rest of this document. In no case does
identification imply the recommendation or endorsement of
products by the Department of Defense, nor does it imply that
products identified are the best available for the purpose described
In all cases such identification is intended only to illustrate
possibility of implementation of an idea or approach. UNIX is
trademark of AT&T Bell Laboratories
Most of the discussions in the remainder of the document deal
Class 4 exclusively, since there are far more implementation
with Class 4 than for Class 2. Also, since Class 2 is logically
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
integrate the required code into the specific operating
supporting the data communications applications. The
technique for integration usually depends upon the structure
facilities of the operating system to be used. For example,
transport software might be implemented in the operating
kernel, accessible through a standard set of system calls.
scheme is typically used when implementing transport for the
operating system. Class 4 transport has been implemented using
technique for System V by AT&T and for BSD 4.2 by
organizations. As another example, the transport service might
structured as a device driver. This approach is used by DEC for
VAX/VMS implementation of classes 0, 2, and 4 of the OSI
protocol. The Intel iRMX-86 implementation of Class 4 transport
another example. Intel implements the transport software as a
level job within the operating system. Such an approach allows
software to be linked to the operating system and loaded with
McCoy [Page 19]
RFC 1008 June 1987
boot of the system
Several advantages may accrue to the communications user
transport is implemented as an integral part of the operating system
First, the interface to data communications services is well
to the application programmer since the same principles are
as for other operating system services. This allows the
implementation of communications applications without the need
retraining of programmers. Second, the operating system can
several different suites of protocols without the need to
application programs. This advantage can be realized only
careful engineering and control of the user-system call interface
the transport services. Third, the transport software may
advantage of the normally available operating system services such
scheduling, flow control, memory management, and
communication. This saves time in the development and maintenance
the transport software
The disadvantages that exist with operating system integration of
TP are primarily dependent upon the specific operating system
However, the major disadvantage, degradation of host
performance, is always present. Since the communications
requires the attention of the processor to handle interrupts
process protocol events, some degradation will occur in
performance of host applications. The degree of degradation
largely a feature of the hardware architecture and
resources required by the protocol. Other disadvantages that
appear relate to limited performance on the part of
communications service. This limited performance is usually
function of the particular operating system and is most
related to the method of interprocess communication provided with
operating system. In general, the more times a message must
copied from one area of memory to another, the poorer
communications software will perform. The method of copying and
number of copies is often a function of the specific
system. For example, copying could be optimized if true
memory is supported in the operating system. In this case,
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
operating system provided a means of multi-task communications
available or can be implemented. This approach is almost always
bad one. Performance problems will usually exist because
communication task is competing for resources like any
application program. The only justification for this approach is
need to develop a simple implementation of the transport
quickly. The NBS implemented the transport protocol using
approach as the basis for a transport protocol correctness
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
attractive
2.3 Independent processing element attached to a system bus
Implementation of the transport service on an independent
that attaches to the system bus may provide substantial
improvements over other approaches. As computing power and
have become cheaper this approach has become realistic.
include the Intel implementation of iNA-961 on a variety of
boards such as the iSBC 186/51 and the iSXM 554. Similar
have been developed by Motorola and by several independent vendors
IBM PC add-ons. This approach requires that the transport
operate on an independent hardware set running under operating
code developed to support the communications software environment
Communication with the application programs takes place across
system bus using some simple, proprietary vendor protocol.
engineering can provide the application programmer with a
interface to the communications processor that is similar to
interface to the input/output subsystem
The advantages of this approach are mainly concentrated upon
performance both for the host applications and the
service. Depending on such factors as the speed of
communications processor and the system bus, data
throughput may improve by one or two orders of magnitude over
available from host operating system integrated implementations
Throughput for host applications should also improve since
communications processing and interrupt handling for timers and
links have been removed from the host processor. The
mechanism used between the host and communication processors
usually sufficiently simple that no real burden is added to
processor
The disadvantages for this approach are caused by complexity
developing the communications software. Software development for
communications board cannot be supported with the standard
system tools. A method of downloading the processor board
debugging the communications software may be required; a trade-
could be to put the code into firmware or microcode.
communications software must include at least a hardware monitor and
more typically, a small operating system to support such functions
interprocess communication, buffer management, flow control, and
synchronization. Debugging of the user to communication
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
the protocol. However, with inexpensive processor and memory
now available, a multiprocessor design is economically viable.
diagram below shows one such design, which almost
McCoy [Page 21]
RFC 1008 June 1987
corresponds to the structure of the formal description. There
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
and network access;
6) lower software complexity, due to functional separation
Possible disadvantages are greater inflexibility and
complexity. However, these might be offset by lower
costs for microcode, since the code separation should provide
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 from a TPM are sent on the output data bus. The user
controller accepts connect requests from the user and directs them
the TPE. The TPE assigns a connection reference and informs
interface controller to direct further inputs for this connection
the designated TPM. The shared TPM memory is analogous to
exported variables of the TPM modules in the formal description,
is used by the TPE to input TPDUs and other information to the TPM
In summary, the off-loading of communications protocols
independent processing systems attached to a host processor across
system bus is quite common. As processing power and memory
cheaper, the amount of software off-loaded grows. it is now
to fine transport service available for several system buses
interfaces to operating systems such as UNIX, XENIX, iRMX, MS-DOS
and VERSADOS
McCoy [Page 22]
RFC 1008 June 1987
Legend: **** data
.... control
==== interface i/o
O channel or bus connection
*
*
__________V_________
| user interface | input
| 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
|________________|
*
*
to
2.4 Front end processor
A more traditional approach to off-loading communications
involves the use of a free-standing front end processor, an
very similar to that of placing the transport service onto a
attached to the system bus. The difference is one of scale.
front end p interface locally as desirable, as long as such
are strictly local (i.e., the invoking of such services does
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
