Request for Comments: 1008 June 1987
IMPLEMENTATION GUIDE
FOR THE
ISO TRANSPORT PROTOCOL
Status of this Memo
This RFCis 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.)
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
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
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
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
*
*
*
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
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
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
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.
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.
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.)
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
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
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
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
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,
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
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
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
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