RFC 1008
Network Working Group Wayne McCoy
Request for Comments: 1008 June 1987
IMPLEMENTATION GUIDE
FOR THE
ISO TRANSPORT PROTOCOL
Status of this Memo
This RFC is being distributed to members of the Internet community
in order to solicit comments on the Implementors Guide. While this
document may not be directly relevant to the research problems
of the Internet, it may be of some interest to a number of researchers
and implementors. Distribution of this memo is unlimited.
IMPLEMENTATION GUIDE FOR THE ISO TRANSPORT PROTOCOL
1 Interpretation of formal description.
It is assumed that the reader is familiar with both the formal
description technique, Estelle [ISO85a], and the transport protocol
as described in IS 8073 [ISO84a] and in N3756 [ISO85b].
1.1 General interpretation guide.
The development of the formal description of the ISO Transport
Protocol was guided by the three following assumptions.
1. A generality principle
The formal description is intended to express all of the behavior
that any implementation is to demonstrate, while not being bound
to the way that any particular implementation would realize that
behavior within its operating context.
2. Preservation of the deliberate
nondeterminism of IS 8073
The text description in the IS 8073 contains deliberate expressions
of nondeterminism and indeterminism in the behavior of the
transport protocol for the sake of flexibility in application.
(Nondeterminism in this context means that the order of execution
for a set of actions that can be taken is not specified.
Indeterminism means that the execution of a given action cannot be
predicted on the basis of system state or the executions of other
actions.)
McCoy [Page 1]
RFC 1008 June 1987
3. Discipline in the usage of Estelle
A given feature of Estelle was to be used only if the nature of
the mechanism to be described strongly indicates its usage,
or to adhere to the generality principle, or to retain the
nondeterminism of IS 8073.
Implementation efficiency was not a particular goal nor was there
an attempt to directly correlate Estelle mechanisms and features
to implementation mechanisms and features. Thus, the description
does not represent optimal behavior for the implemented protocol.
These assumptions imply that the formal description contains higher
levels of abstraction than would be expected in a description for
a particular operating environment. Such abstraction is essential,
because of the diversity of networks and network elements by which
implementation and design decisions are influenced. Even when
operating environments are essentially identical, design choice and
originality in solving a technical problem must be allowed.
The same behavior may be expressed in many different ways. The
goal in producing the transport formal description was to attempt
to capture this equivalence. Some mechanisms of transport are not
fully described or appear to be overly complicated because of the
adherence to the generality principle. Resolution of these
situations may require significant effort on the part of the
implementor.
Since the description does not represent optimal behavior for the
implemented protocol, implementors should take the three assumptions
above into account when using the description to implement the
protocol. It may be advisable to adapt the standard description in
such a way that:
a. abstractions (such as modules, channels, spontaneous
transitions and binding comments) are interpreted and realized
as mechanisms appropriate to the operating environment and
service requirements;
b. modules, transitions, functions and procedures containing
material irrelevant to the classes or options to be supported
are reduced or eliminated as needed; and
c. desired real-time behavior is accounted for.
The use in the formal description of an Estelle feature (for
instance, "process"), does not imply that an implementation must
necessarily realize the feature by a synonymous feature of the
operating context. Thus, a module declared to be a "process" in an
Estelle description need not represent a real process as seen by a
host operating system; "process" in Estelle refers to the
McCoy [Page 2]
RFC 1008 June 1987
synchronization properties of a set of procedures (transitions).
Realizations of Estelle features and mechanisms are dependent in an
essential way upon the performance and service an implementation is
to provide. Implementations for operational usage have much more
stringent requirements for optimal behavior and robustness than do
implementations used for simulated operation (e.g., correctness or
conformance testing). It is thus important that an operational
implementation realize the abstract features and mechanisms of a
formal description in an efficient and effective manner.
For operational usage, two useful criteria for interpretation of
formal mechanisms are:
[1] minimization of delays caused by the mechanism
itself; e.g.,
--transit delay for a medium that realizes a
channel
--access delay or latency for channel medium
--scheduling delay for timed transitions
(spontaneous transitions with delay clause)
--execution scheduling for modules using
exported variables (delay in accessing
variable)
[2] minimization of the "handling" required by each
invocation of the mechanism; e.g.,
--module execution scheduling and context
switching
--synchronization or protocols for realized
channel
--predicate evaluation for spontaneous
transitions
Spontaneous transitions represent nondeterminism and indeterminism,
so that uniform realization of them in an implementation must be
questioned as an implementation strategy. The time at which the
action described by a spontaneous transition will actually take
place cannot be specified because of one or more of the following
situations:
a. it is not known when, relative to any specific event defining
the protocol (e.g., input network, input from user, timer
McCoy [Page 3]
RFC 1008 June 1987
expirations), the conditions enabling the transition will
actually occur;
b. even if the enabling conditions are ultimately deterministic,
it is not practical to describe all the possible ways this
could occur, given the different ways in which implementations
will examine these conditions; and
c. a particular implementation may not be concerned with the
enabling conditions or will account for them in some other
way; i.e., it is irrelevant when the action takes place, if
ever.
As an example of a), consider the situation when splitting over the
network connection, in Class 4, in which all of the network
connections to which the transport connection has been assigned have
all disconnected, with the transport connection still in the OPEN
state. There is no way to predict when this will happen, nor is
there any specific event signalling its occurrence. When it does
occur, the transport protocol machine may want to attempt to obtain
a new network connection.
As an example of b), consider that timers may be expressed
succinctly in Estelle by transitions similar to the following:
from A to B
provided predicate delay( timer_interval )
begin
(* action driven by timeout *)
end;
But there are operations for which the timer period may need to
be very accurate (close to real time) and others in which some
delay in executing the action can be tolerated. The implementor
must determine the optimal behavior desired for each instance
and use an appropriate mechanism to realize it, rather than
using a uniform approach to implementing all spontaneous
transitions.
As an example of the situation in c), consider the closing of an
unused network connection. If the network is such that the cost
of letting the network connection remain open is small compared
cost of opening it, then an implementation might not want to
consider closing the network connection until, say, the weekend.
Another implementation might decide to close the network
connection within 30 msec after discovering that the connection
is not busy. For still another implementation, this could be
McCoy [Page 4]
RFC 1008 June 1987
meaningless because it operates over a connectionless network
service.
If a description has only a very few spontaneous transitions, then
it may be relatively easy to implement them literally (i.e., to
schedule and execute them as Estelle abstractly does) and not
incur the overhead from examining all of the variables that occur
in the enabling conditions. However, the number and complexity of
the enabling conditions for spontaneous transitions in the transport
description strongly suggests that an implementation which realizes
spontaneous transitions literally will suffer badly from such
overhead.
1.2 Guide to the formal description.
So that implementors gain insight into interpretation of the
mechanisms and features of the formal description of transport, the
following paragraphs discuss the meanings of such mechanisms and
features as intended by the editors of the formal description.
1.2.1 Transport Protocol Entity.
1.2.1.1 Structure.
The diagram below shows the general structure of the Transport
Protocol Entity (TPE) module, as given in the formal description.
>From an abstract operational viewpoint, the transport protocol
Machines (TPMs) and the Slaves operate as child processes of the the
TPE process. Each TPM represents the endpoint actions of the
protocol on a single transport connection. The Slave represents
control of data output to the network. The internal operations of
the TPMs and the Slave are discussed below in separate sections.
This structure permits describing multiple connections, multiplexing
and splitting on network connections, dynamic existence of endpoints
and class negotiation. In the diagram, interaction points are
denoted by the symbol "O", while (Estelle) channels joining these
interaction points are denoted by
McCoy [Page 5]
RFC 1008 June 1987
*
*
*
The symbol "X" represents a logical association through variables,
and the denotations
<<<<<<<
>>>>>>>
V
V
V
indicate the passage of data, in the direction of the symbol
vertices, by way of these associations. The acronyms TSAP and
NSAP denote Transport Service Access Point and Network Service
Access Point, respectively. The structure of the TSAPs and
NSAPs shown is discussed further on, in Parts 1.2.2.1 and
1.2.2.2.
|<-----------------TSAP---------------->|
----------O---------O---------O---------O---------O---------
| TPE * * * |
| * * * |
| ____O____ ____O____ ____O____ |
| | | | | | | |
| | TPM | | TPM | | TPM | |
| | | | | | | |
| |___X___| |__X_X__| |___X___| |
| V V V V |
| V multiplex V V V |
| >>>>>>>> <<<<<<<<<<< V V |
| V V split V V |
| V V V V |
| ---X---- ---X---- ---X---- |
| |Slave | |Slave | |Slave | |
| |__O___| |__O___| |__O___| |
| V V V |
| V V V |
|-----------------O------------O--------O------------------|
NSAP |<------>|
NSAP
McCoy [Page 6]
RFC 1008 June 1987
The structuring principles of Estelle provide a formal means of
expressing and enforcing certain synchronization properties between
communicating processes. It must be stressed that the scheduling
implied by Estelle descriptions need not and in some cases should
not be implemented. The intent of the structure in the transport
formal description is to state formally the synchronization of
access tovariables shared by the transport entity and the transport
connection endpoints and to permit expression of dynamic objects
within the entity. In nearly all aspects of operation except these,
it may be more efficient in some implementation environments to
permit the TPE and the TPMs to run in parallel (the Estelle
scheduling specifically excludes the parallel operation of the TPE
and the TPMs). This is particularly true of internal management
("housekeeping") actions and those actions not directly related to
communication between the TPE and the TPMs or instantiation of TPMs.
Typical actions of this latter sort are: receipt of NSDUs from the
network, integrity checking and decoding of TPDUs, and network
connection management. Such actions could have been collected into
other modules for scheduling closer to that of an implementation,
but surely at the risk of further complicating the description.
Consequently, the formal description structure should be understood
as expressing relationships among actions and objects and not
explicit implementation behavior.
1.2.1.2 Transport protocol entity operation.
The details of the operation of the TPE from a conceptual point of
view are given in the SYS section of the formal description.
However, there are several further comments that can be made
regarding the design of the TPE. The Estelle body for the TPE
module has no state variable. This means that any transition of
the TPE may be enabled and executed at any time. Choice of
transition is determined primarily by priority. This suggests
that the semantics of the TPE transitions is that of interrupt
traps.
The TPE handles only the T-CONNECT-request from the user and the TPM
handle all other user input. All network events are handled by the
TPE, in addition to resource management to the extent defined in the
description. The TPE also manages all aspects of connection
references, including reference freezing. The TPE does not
explicitly manage the CPU resource for the TPMs, since this is
implied by the Estelle scheduling across the module hierarchy.
Instantiation of TPMs is also the responsibility of the TPE, as is
TPM release when the transport connection is to be closed. Once a
TPM is created, the TPE does not in general interfere with TPM's
activities, with the following exceptions: the TPE may reduce credit
to a Class 4 TPM without notice; the TPE may dissociate a Class 4
TPM from a network connection when splitting is being used.
Communication between the TPE and the TPMs is through a set of
exported variables owned by the TPMs, and through a channel which
McCoy [Page 7]
RFC 1008 June 1987
passes TPDUs to be transmitted to the remote peer. This channel is
not directly connected to any network connection, so each
interaction on it carries a reference number indicating which network
connection is to be used. Since the reference is only a reference,
this permits usage of this mechanism when the network service is
connectionless, as well. The mechanism provides flexibility for
both splitting and multiplexing on network connections.
One major function that the TPE performs for all its TPMs is that of
initial processing of received TPDUs. First, a set of integrity
checks is made to determine if each TPDU in an NSDU is decodable:
a. PDU length indicators and their sums are checked against the
NSDU length for consistency;
b. TPDU types versus minimum header lengths for the types are
checked, so that if the TPDU can be decoded, then proper
association to TPMs can be made without any problem;
c. TPDUs are searched for checksums and the local checksum is
computed for any checksum found; and
d. parameter codes in variable part of headers are checked where
applicable.
These integrity checks guarantee that an NSDU passing the check can
be separated as necessary into TPDUs, these TPDUs can be associated
to the transport connections or to the Slave as appropriate and they
can be further decoded without error.
The TPE next decodes the fixed part of the TPDU headers to determine
the disposition of the TPDU. The Slave gets TPDUs that cannot be
assigned to a TPM (spurious TPDU). New TPMs are created in response
to CR TPDUs that correspond to a TSAP for this TPE.
All management of NSAPs is done by the TPE. This consists of keeping
track of all network connections, their service quality
characteristics and their availability, informing the TPMs associated
with these network connections.
The TPE has no timer module as such. Timing is handled by using the
DELAY feature of Estelle, since this feature captures the essence of
timing without specifying how the actual timing is to be achieved
within the operating environment. See Part 1.2.5 for more details.
1.2.2 Service Access Points.
The service access points (SAP) of the transport entity are modeled
using the Estelle channel/interaction point formalism. (Note: The
McCoy [Page 8]
RFC 1008 June 1987
term "channel" in Estelle is a keyword that denotes a set of
interactions which may be exchanged at interaction points [LIN85].
However, it is useful conceptually to think of "channel" as denoting
a communication path that carries the interactions between modules.)
The abstract service primitives for a SAP are interactions on
channels entering and leaving the TPE. The transport user is
considered to be at the end of the channel connected to the transport
SAP (TSAP) and the network service provider is considered to be at
the end of the channel connected to the network SAP (NSAP). An
interaction put into a channel by some module can be considered to
move instantaneously over the channel onto a queue at the other end.
The sender of such an interaction no longer has access to the
interaction once it has been put into the channel. The operation of
the system modeled by the formal description has been designed with
this semantics in mind, rather than the equivalent but much more
abstract Estelle semantics. (In the Estelle semantics, each
interaction point is considered to have associated with it an
unbounded queue. The "attach" and "connect" primitives bind two
interaction points, such that an action, implied by the keyword
"out", at one interaction point causes a specified interaction to be
placed onto the queue associated with the other interaction point.)
The sections that follow discuss the TSAP and the NSAP and the way
that these SAPs are described in the formal description.
1.2.2.1 Transport Service Access Point.
The international transport standard allows for more than one TSAP to
be associated with a transport entity, and multiple users may be
associated with a given TSAP. A situation in which this is useful is
when it is desirable to have a certain quality of service correlated
with a given TSAP. For example, one TSAP could be reserved for
applications requiring a high throughput, such as file transfer. The
operation of transport connections associated with this TSAP could
then be designed to favor throughput. Another TSAP might serve users
requiring short response time, such as terminals. Still another TSAP
could be reserved for encryption reasons.
In order to provide a way of referencing users associated with TSAPs,
the user access to transport in the formal description is through an
array of Estelle interaction points. This array is indexed by a TSAP
address (T_address) and a Transport Connection Endpoint Identifier
(TCEP_id). Note that this dimensional object (TSAP) is considered
simply to be a uniform set of abstract interfaces. The indices must
be of (Pascal) ordinal type in Estelle. However, the actual address
structure of TSAPs may not conform easily to such typing in an
implementation. Consequently, the indices as they appear in the
formal description should be viewed as an organizational mechanism
rather than as an explicit way of associating objects in an
operational setting. For example, actual TSAP addresses might be
kept in some kind of table, with the table index being used to
reference objects associated with the TSAP.
McCoy [Page 9]
RFC 1008 June 1987
One particular issue concerned with realizing TSAPs is that of making
known to the users the means of referencing the transport interface,
i.e., somehow providing the T_addresses and TCEP_ids to the users.
This issue is not considered in any detail by either IS 7498 [ISO84b]
or IS 8073. Abstractly, the required reference is the
T_address/TCEP_id pair. However, this gives no insight as to how the
mechanism could work. Some approaches to this problem are discussed
in Part 5.
Another issue is that of flow control on the TSAP channels. Flow
control is not part of the semantics for the Estelle channel, so the
problem must be dealt with in another way. The formal description
gives an abstract definition of interface flow control using Pascal
and Estelle mechanisms. This abstraction resembles many actual
schemes for flow control, but the realization of flow control will
still be dependent on the way the interface is implemented. Part 3.2
discusses this in more detail.
1.2.2.2 Network Service Access Point.
An NSAP may also have more than one network connection associated
with it. For example, the virtual circuits of X.25 correspond with
this notion. On the other hand, an NSAP may have no network
connection associated with it, for example when the service at the
NSAP is connectionless. This certainly will be the case when
transport operates on a LAN or over IP. Consequently, although the
syntactical appearance of the NSAP in the formal description is
similar to that for the TSAP, the semantics are essentially distinct
[NTI85].
Distinct NSAPs can correspond or not to physically distinct networks.
Thus, one NSAP could access X.25 service, another might access an
IEEE 802.3 LAN, while a third might access a satellite link. On the
other hand, distinct NSAPs could correspond to different addresses on
the same network, with no particular rationale other than facile
management for the distinction. There are performance and system
design issues that arise in considering how NSAPs should be managed
in such situations. For example, if distinct NSAPs represent
distinct networks, then a transport entity which must handle all
resource management for the transport connections and operate these
connections as well may have trouble keeping pace with data arriving
concurrently from two LANs and a satellite link. It might be a
better design solution to separate the management of the transport
connection resources from that of the NSAP resources and inputs, or
even to provide separate transport entities to handle some of the
different network services, depending on the service quality to be
maintained. It may be helpful to think of the (total) transport
service as not necessarily being provided by a single monolithic
entity--several distinct entities can reside at the transport layer
on the same end-system.
McCoy [Page 10]
RFC 1008 June 1987
The issues of NSAP management come primarily from connection-oriented
network services. This is because a connectionless service is either
available to all transport connections or it is available to none,
representing infinite degrees of multiplexing and splitting. In the
connection-oriented case, NSAP management is complicated by
multiplexing, splitting, service quality considerations and the
particular character of the network service. These issues are
discussed further in Part 3.4.1. In the formal description, network
connection management is carried out by means of a record associated
with each possible connection and an array, associated with each TPM,
each array member corresponding to a possible network connection.
Since there is, on some network services, a very large number of
possible network connections, it is clear that in an implementation
these data structures may need to be made dynamic rather than static.
The connection record, indexed by NSAP and NCEP_id, consists of a
Slave module reference, virtual data connections to the TPMs to be
associated with the network connection, a data connection (out) to
the NSAP, and a data connection to the Slave. There is also a
"state" variable for keeping track of the availability of the
connection, variables for managing the Slave and an internal
reference number to identify the connection to TPMs. A member of the
network connection array associated with a TPM provides the TPM with
status information on the network connection and input data (network)
events and TPDUs). A considerable amount of management of the
network connections is provided by the formal description, including
splitting, multiplexing, service quality (when defined), interface
flow control, and concatenation of TPDUs. This management is carried
out solely by the transport entity, leaving the TPMs free to handle
only the explicit transport connection issues. This management
scheme is flexible enough that it can be simplified and adapted to
handle the NSAP for a connectionless service.
The principal issue for management of connectionless NSAPs is that of
buffering, particularly if the data transmission rates are high, or
there is a large number of transport connections being served. It
may also be desirable for the transport entity to monitor the service
it is getting from the network. This would entail, for example,
periodically computing the mean transmission delays for adjusting
timers or to exert backpressure on the transport connections if
network access delay rises, indicating loading. (In the formal
description, the Slave processor provides a simple form of output
buffer management: when its queue exceeds a threshold, it shuts off
data from the TPMs associated with it. Through primitive functions,
the threshold is loosely correlated with network behavior. However,
this mechanism is not intended to be a solution to this difficult
performance problem.)
McCoy [Page 11]
RFC 1008 June 1987
1.2.3 Transport Protocol Machine.
Transport Protocol Machines (TPM) in the formal description are in
six classes: General, Class 0, Class 1, Class 2, Class 3 and Class 4.
Only the General, Class 2 and Class 4 TPMs are discussed here. The
reason for this diversity is to facilitate describing class
negotiations and to show clearly the actions of each class in the
data transfer phase. The General TPM is instantiated when a
connection request is received from a transport user or when a CR
TPDU is received from a remote peer entity. This TPM is replaced by
a class-specific TPM when the connect response is received from the
responding user or when the CC TPDU is received from the responding
peer entity.
The General, Class 2 and Class 4 TPMs are discussed below in more
detail. In an implementation, it probably will be prudent to merge
the Class 2 and Class 4 operations with that of the General TPM, with
new variables selecting the class-specific operation as necessary
(see also Part 9.4 for information on obtaining Class 2 operation
from a Class 4 implementation). This may simplify and improve the
behavior of the implemented protocol overall.
1.2.3.1 General Transport Protocol Machine.
Connection negotiation and establishment for all classes can be
handled by the General Transport Protocol Machine. Some parts of the
description of this TPM are sufficiently class dependent that they
can safely be removed if that class is not implemented. Other parts
are general and must be retained for proper operation of the TPM. The
General TPM handles only connection establishment and negotiation, so
that only CR, CC, DR and DC TPDUs are sent or received (the TPE
prevents other kinds of TPDUs from reaching the General TPM).
Since the General TPM is not instantiated until a T-CONNECT-request
or a CR TPDU is received, the TPE creates a special internal
connection to the module's TSAP interaction point to pass the
T-CONNECT-request event to the TPM. This provides automaton
completeness according to the specfication of the protocol. When the
TPM is to be replaced by a class-specific TPM, the sent or received
CC is copied to the new TPM so that negotiation information is not
lost.
In the IS 8073 state tables for the various classes, the majority of
the behavioral information for the automaton is contained in the
connection establishment phase. The editors of the formal
description have retained most of the information contained in the
state tables of IS 8073 in the description of the General TPM.
1.2.3.2 Class 2 Transport Protocol Machine.
The formal description of the Class 2 TPM closely resembles that of
McCoy [Page 12]
RFC 1008 June 1987
Class 4, in many respects. This is not accidental, in that: the
conformance statement in IS 8073 links Class 2 with Class 4; and the
editors of the formal description produced the Class 2 TPM
description by copying the Class 4 TPM description and removing
material on timers, checksums, and the like that is not part of the
Class 2 operation. The suggestion of obtaining Class 2 operation
from a Class 4 implementation, described in Part 9.4, is in fact
based on this adaptation.
One feature of Class 2 that does not appear in Class 4, however, is
the option to not use end-to-end flow control. In this mode of
operation, Class 2 is essentially Class 0 with multiplexing. In
fact, the formal description of the Class 0 TPM was derived from
Class 2 (in IS 8073, these two classes have essentially identical
state tables). This implies that Class 0 operation could be obtained
from Class 2 by not multiplexing, not sending DC TPDUs, electing not
to use flow control and terminating the network connection when a DR
TPDU is received (expedited data cannot be used if flow control is
not used). When Class 2 is operated in this mode, a somewhat
different procedure is used to handle data flow internal to the TPM
than is used when end-to-end flow control is present.
1.2.3.3 Class 4 Transport Protocol Machine.
Dynamic queues model the buffering of TPDUs in both the Class 4 and
Class 2 TPMs. This provides a more general model of implementations
than does the fixed array representation and is easier to describe.
Also, the fixed array representation has semantics that, carried
into an implementation, would produce inefficiency. Consequently,
linked lists with queue management functions make up the TPDU
storage description, despite the fact that pointers have a very
implementation-like flavor. One of the queue management functions
permits removing several TPDUs from the head of the send queue, to
model the acknowledgement of several TPDUs at once, as specified in
IS 8073. Each TPDU record in the queue carries the number of
retransmissions tried, for timer control (not present in the Class 2
TPDU records).
There are two states of the Class 4 TPM that do not appear in IS
8073. One of these was put in solely to facilitate obtaining credit
in case no credit was granted for the CR or CC TPDU. The other state
was put in to clarify operations when there is unacknowledged
expedited data outstanding (Class 2 does not have this state).
The timers used in the Class 4 TPM are discussed below, as is the
description of end-to-end flow control.
For simplicity in description, the editors of the formal description
assumed that no queueing of expedited data would occur at the user
interface of the receiving entity. The user has the capability to
block the up-flow of expedited data until it is ready. This
McCoy [Page 13]
RFC 1008 June 1987
assumption has several implications. First, an ED TPDU cannot be
acknowledged until the user is ready to accept it. This is because
the receipt of an EA TPDU would indicate to the sending peer that the
receiver is ready to receive the next ED TPDU, which would not be
true. Second, because of the way normal data flow is blocked by the
sending of an ED TPDU, normal data flow ceases until the receiving
user is ready for the ED TPDU. This suggests that the user
interface should employ separate and noninterfering mechanisms
for passing normal and expedited data to the user. Moreover,
the mechanism for expedited data passage should be blocked only in
dire operational conditions. This means that receipt of expedited
data by the user should be a procedure (transition) that operates
at nearly the highest priority in the user process. The alternative
to describing the expedited data handling in this way would entail a
scheme of properly synchronizing the queued ED TPDUs with the DT
TPDUs received. This requires some intricate handling of DT and ED
sequence numbers. While this alternative may be attractive for
implementations, for clarity in the formal description it provides
only unnecessary complication.
The description of normal data TSDU processing is based on the
assumption that the data the T-DATA-request refers to is potentially
arbitrarily long. The semantic of the TSDU in this case is analogous
to that of a file pointer, in the sense that any file pointer is a
reference to a finite but arbitrarily large set of octet-strings.
The formation of TPDUs from this string is analogous to reading the
file in fixed-length segments--records or blocks, for example. The
reassembly of TPDUs into a string is analogous to appending each TPDU
to the tail of a file; the file is passed when the end-of-TSDU
(end-of-file) is received. This scheme permits conceptual buffering
of the entire TSDU in the receiver and avoids the question of whether
or not received data can be passed to the user before the EOT is
received. (The file pointer may refer to a file owned by the user,
so that the question then becomes moot.)
The encoding of TPDUs is completely described, using Pascal functions
and some special data manipulation functions of Estelle (these are
not normally part of Pascal). There is one encoding function
corresponding to each TPDU type, rather than a single parameterized
function that does all of them. This was done so that the separate
structures of the individual types could be readily discerned, since
the purpose of the functions is descriptive and not necessarily
computational.
The output of TPDUs from the TPM is guarded by an internal flow
control flag. When the TPDU is first sent, this flag is ignored,
since if the TPDU does not get through, a retransmission may take
care of it. However, when a retransmission is tried, the flag is
heeded and the TPDU is not sent, but the retransmission count is
incremented. This guarantees that either the TPDU will eventually
be sent or the connection will time out (this despite the fact that
McCoy [Page 14]
RFC 1008 June 1987
the peer will never have received any TPDU to acknowledge).
Checksum computations are done in the TPM rather than by the TPE,
since the TPE must handle all classes. Also, if the TPMs can be
made to truly run in parallel, the performance may be greatly
enhanced.
The decoding of received TPDUs is partially described in the Class 4
TPM description. Only the CR and CC TPDUs present any problems in
decoding, and these are largely due to the nondeterministic order of
parameters in the variable part of the TPDU headers and the
locality-and class-dependent content of this variable part. Since
contents of this variable part (except the TSAP-IDs) do not affect
the association of the TPDU with a transport connection, the
decoding of the variable part is not described in detail. Such a
description would be very lengthy indeed because of all the
possibilities and would not contribute measurably to understanding
by the reader.
1.2.4 Network Slave.
The primary functions of the Network Slave are to provide downward
flow control in the TPE, to concatenate TPDUs into a single NSDU and
to respond to the receipt of spurious TPDUs. The Slave has an
internal queue on which it keeps TPDUs until the network is ready to
accept them for transmission. The TPE is kept informed as to the
length of queue, and the output of the TPMs is throttled if the
length exceeds this some threshold. This threshold can be adjusted
to meet current operating conditions. The Slave will concatenate
the TPDUs in its queue if the option to concatenate is exercised and
the conditions for concatenating are met. Concatenation is a TPE
option, which may be exercised or not at any time.
1.2.5 Timers.
In the formal description timers are all modeled using a spontaneous
transition with delay, where the delay parameter is the timer period.
To activate the timer, a timer identifier is placed into a set,
thereby satisfying a predicate of the form
provided timer_x in active_timers
However, the transition code is not executed until the elapsed time
;from the placement of the identifier in the set is at least equal
to the delay parameter. The editors of the formal description chose
to model timers in this fashion because it provided a simply
expressed description of timer behavior and eliminated having to
consider how timing is done in a real system or to provide special
timer modules and communication to them. It is thus recommended that
implementors not follow the timer model closely in implementations,
considering instead the simplest and most efficient means of timing
permitted by the implementation environment. Implementors should
McCoy [Page 15]
RFC 1008 June 1987
also note that the delay parameter is typed "integer" in the formal
description. No scale conversion from actual time is expressed in the
timer transition, so that this scale conversion must be considered
when timers are realized.
1.2.5.1 Transport Protocol Entity timers.
There is only one timer given in the formal description of the
TPE--the reference timer. The reference timer was placed here ;so
that it can be used by all classes and all connections, as needed.
There is actually little justification for having a reference timer
within the TPM--it wastes resources by holding the transport
endpoint, even though the TPM is incapable of responding to any
input. Consequently, the TPE is responsible for all aspects of
reference management, including the timeouts.
1.2.5.2 Transport Protocol Machine timers.
Class 2 transport does not have any timers that are required by IS
8073. However, the standard does recommend that an optional timer be
used by Class 2 in certain cases to avoid deadlock. The formal
description provides this timer, with comments to justify its usage.
It is recommended that such a timer be provided for Class 2
operation. Class 4 transport has several timers for connection
control, flow control and retransmissions of unacknowledged data.
Each of these timers is discussed briefly below in terms of how they
were related to the Class 4 operations in the formal description.
Further discussion of these timers is given in Part 8.
1.2.5.2.1 Window timer.
The window timer is used for transport connection control as well as
providing timely updates of flow control credit information. One of
these timers is provided in each TPM. It is reset each time an AK
TPDU is sent, except during fast retransmission of AKs for flow
control confirmation, when it is disabled.
1.2.5.2.2 Inactivity timer.
The primary usage of the inactivity timer is to detect when the
remote peer has ceased to send anything (including AK TPDUs). This
timer is mandatory when operating over a connectionless network
service, since there is no other way to determine whether or not the
remote peer is still functioning. On a connection-oriented network
service it has an additional usage since to some extent the continued
existence of the network connection indicates that the peer host has
not crashed.
Because of splitting, it is useful to provide an inactivity timer on
each network connection to which a TPM is assigned. In this manner,
if a network connection is unused for some time, it can be released,
McCoy [Page 16]
RFC 1008 June 1987
even though a TPM assigned to it continues to operate over other
network connections. The formal description provides this capability
in each TPM.
1.2.5.2.3 Network connection timer.
This timer is an optional timer used to ensure that every network
connection to which a TPM is assigned gets used periodically. This
prevents the expiration of the peer entity's inactivity timer for a
network connection. There is one timer for each network connection
to which the TPM is assigned. If there is a DT or ED TPDU waiting to
be sent, then it is chosen to be sent on the network connection. If
no such TPDU is waiting, then an AK TPDU is sent. Thus, the NC timer
serves somewhat the same purpose as the window timer, but is broader
in scope.
1.2.5.2.4 Give-up timer.
There is one give-up timer for a TPM which is set whenever the
retransmission limit for any CR, CC, DT, ED or DR TPDU is reached.
Upon expiration of this timer, the transport connection is closed.
1.2.5.2.5 Retransmission timers.
Retransmission timers are provided for CR, CC, DT, ED and DR TPDUs.
The formal description provides distinct timers for each of these
TPDU types, for each TPM. However, this is for clarity in the
description, and Part 8.2.5 presents arguments for other strategies
to be used in implementations. Also, DT TPDUs with distinct sequence
numbers are each provided with timers, as well. There is a primitive
function which determines the range within the send window for which
timers will be set. This has been done to express flexibility in the
retransmission scheme.
The flow control confirmation scheme specified in IS 8073 also
provides for a "fast" retransmission timer to ensure the reception of
an AK TPDU carrying window resynchronization after credit reduction
or when opening a window that was previously closed. The formal
description permits one such timer for a TPM. It is disabled after
the peer entity has confirmed the window information.
1.2.5.2.6 Error transport protocol data unit timer.
In IS 8073, there is a provision for an optional timeout to limit the
wait for a response by the peer entity to an ER TPDU. When this
timer expires, the transport connection is terminated. Each Class 2
or Class 4 TPM is provided with one of these timers in N3756.
1.2.6 End-to-end Flow Control.
Flow control in the formal description has been written in such a way
McCoy [Page 17]
RFC 1008 June 1987
as to permit flexibility in credit control schemes and
acknowledgement strategies.
1.2.6.1 Credit control.
The credit mechanism in the formal description provides for actual
management of credit by the TPE. This is done through variables
exported by the TPMs which indicate to the TPE when credit is needed
and for the TPE to indicate when credit has been granted. In this
manner, the TPE has control over the credit a TPM has. The mechanism
allows for reduction in credit (Class 4 only) and the possibility of
precipitous window closure. The mechanism does not preclude the use
of credit granted by the user or other sources, since credit need is
expressed as current credit being less than some threshold. Setting
the threshold to zero permits these other schemes. An AK TPDU is
sent each time credit is updated.
The end-to-end flow control is also coupled to the interface flow
control to the user. If the user has blocked the interface up-flow,
then the TPM is prohibited from requesting more credit when the
current window is used up.
1.2.6.2 Acknowledgement.
The mechanism for acknowledging normal data provides flexibility
sufficient to send an AK TPDU in response to every Nth DT TPDU
received where N > 0 and N may be constant or dynamically determined.
Each TPM is provided with this, independent of all other TPMs, so
that acknowledgement strategy can be determined separately for each
transport connection. The capability of altering the acknowledgement
strategy is useful in operation over networks with varying error
rates.
1.2.6.3 Sequencing of received data.
It is not specified in IS 8073 what must be done with out-of-sequence
but within-window DT TPDUs received, except that an AK TPDU with
current window and sequence information be sent. There are
performance reasons why such DT TPDUs should be held (cached): in
particular, avoidance of retransmissions. However, this buffering
scheme is complicated to implement and worse to describe formally
without resorting to mechanisms too closely resembling
implementation. Thus, the formal description mechanism discards such
DT TPDUs and relies on retransmission to fill the gaps in the window
sequence, for the sake of simplicity in the description.
1.2.7 Expedited data.
The transmission of expedited data, as expressed by IS 8073, requires
the blockage of normal data transmission until the acknowledgement is
received. This is handled in the formal description by providing a
McCoy [Page 18]
RFC 1008 June 1987
special state in which normal data transmission cannot take place.
However, recent experiments with Class 4 transport over network
services with high bandwidth, high transit delay and high error
rates, undertaken by the NBS and COMSAT Laboratories, have shown that
the protocol suffers a marked decline in its performance in such
conditions. This situation has been presented to ISO, with the
result that the the protocol will be modified to permit the sending
of normal data already accepted by the transport entity from the user
before the expedited data request but not yet put onto the network.
When the modification is incorporated into IS 8073, the formal
description will be appropriately aligned.
2 Environment of implementation.
The following sections describe some general approaches to
implementing the transport protocol and the advantages and
disadvantages of each. Certain commercial products are identified
throughout the rest of this document. In no case does such
identification imply the recommendation or endorsement of these
products by the Department of Defense, nor does it imply that the
products identified are the best available for the purpose described.
In all cases such identification is intended only to illustrate the
possibility of implementation of an idea or approach. UNIX is a
trademark of AT&T Bell Laboratories.
Most of the discussions in the remainder of the document deal with
Class 4 exclusively, since there are far more implementation issues
with Class 4 than for Class 2. Also, since Class 2 is logically a
special case of Class 4, it is possible to implement Class 4 alone,
with special provisions to behave as Class 2 when necessary.
2.1 Host operating system program.
A common method of implementing the OSI transport service is to
integrate the required code into the specific operating system
supporting the data communications applications. The particular
technique for integration usually depends upon the structure and
facilities of the operating system to be used. For example, the
transport software might be implemented in the operating system
kernel, accessible through a standard set of system calls. This
scheme is typically used when implementing transport for the UNIX
operating system. Class 4 transport has been implemented using this
technique for System V by AT&T and for BSD 4.2 by several
organizations. As another example, the transport service might be
structured as a device driver. This approach is used by DEC for the
VAX/VMS implementation of classes 0, 2, and 4 of the OSI transport
protocol. The Intel iRMX-86 implementation of Class 4 transport is
another example. Intel implements the transport software as a first
level job within the operating system. Such an approach allows the
software to be linked to the operating system and loaded with every
McCoy [Page 19]
RFC 1008 June 1987
boot of the system.
Several advantages may accrue to the communications user when
transport is implemented as an integral part of the operating system.
First, the interface to data communications services is well known
to the application programmer since the same principles are followed
as for other operating system services. This allows the fast
implementation of communications applications without the need for
retraining of programmers. Second, the operating system can support
several different suites of protocols without the need to change
application programs. This advantage can be realized only with
careful engineering and control of the user-system call interface to
the transport services. Third, the transport software may take
advantage of the normally available operating system services such as
scheduling, flow control, memory management, and interprocess
communication. This saves time in the development and maintenance of
the transport software.
The disadvantages that exist with operating system integration of the
TP are primarily dependent upon the specific operating system.
However, the major disadvantage, degradation of host application
performance, is always present. Since the communications software
requires the attention of the processor to handle interrupts and
process protocol events, some degradation will occur in the
performance of host applications. The degree of degradation is
largely a feature of the hardware architecture and processing
resources required by the protocol. Other disadvantages that may
appear relate to limited performance on the part of the
communications service. This limited performance is usually a
function of the particular operating system and is most directly
related to the method of interprocess communication provided with the
operating system. In general, the more times a message must be
copied from one area of memory to another, the poorer the
communications software will perform. The method of copying and the
number of copies is often a function of the specific operating
system. For example, copying could be optimized if true shared
memory is supported in the operating system. In this case, a
significant amount of copying can be reduced to pointer-passing.
2.2 User program.
The OSI transport service can be implemented as a user job within any
operating system provided a means of multi-task communications is
available or can be implemented. This approach is almost always a
bad one. Performance problems will usually exist because the
communication task is competing for resources like any other
application program. The only justification for this approach is the
need to develop a simple implementation of the transport service
quickly. The NBS implemented the transport protocol using this
approach as the basis for a transport protocol correctness testing
system. Since performance was not a goal of the NBS implementation,
McCoy [Page 20]
RFC 1008 June 1987
the ease of development and maintenance made this approach
attractive.
2.3 Independent processing element attached to a system bus.
Implementation of the transport service on an independent processor
that attaches to the system bus may provide substantial performance
improvements over other approaches. As computing power and memory
have become cheaper this approach has become realistic. Examples
include the Intel implementation of iNA-961 on a variety of multibus
boards such as the iSBC 186/51 and the iSXM 554. Similar products
have been developed by Motorola and by several independent vendors of
IBM PC add-ons. This approach requires that the transport software
operate on an independent hardware set running under operating system
code developed to support the communications software environment.
Communication with the application programs takes place across the
system bus using some simple, proprietary vendor protocol. Careful
engineering can provide the application programmer with a standard
interface to the communications processor that is similar to the
interface to the input/output subsystem.
The advantages of this approach are mainly concentrated upon enhanced
performance both for the host applications and the communications
service. Depending on such factors as the speed of the
communications processor and the system bus, data communications
throughput may improve by one or two orders of magnitude over that
available from host operating system integrated implementations.
Throughput for host applications should also improve since the
communications processing and interrupt handling for timers and data
links have been removed from the host processor. The communications
mechanism used between the host and communication processors is
usually sufficiently simple that no real burden is added to either
processor.
The disadvantages for this approach are caused by complexity in
developing the communications software. Software development for the
communications board cannot be supported with the standard operating
system tools. A method of downloading the processor board and
debugging the communications software may be required; a trade-off
could be to put the code into firmware or microcode. The
communications software must include at least a hardware monitor and,
more typically, a small operating system to support such functions as
interprocess communication, buffer management, flow control, and task
synchronization. Debugging of the user to communication subsystem
interface may involve several levels of system software and hardware.
The design of the processing element can follow conventional lines,
in which a single processor handling almost all of the operation of
the protocol. However, with inexpensive processor and memory chips
now available, a multiprocessor design is economically viable. The
diagram below shows one such design, which almost directly
McCoy [Page 21]
RFC 1008 June 1987
corresponds to the structure of the formal description. There are
several advantages to this design:
1) management of CPU and memory resources is at a minimum;
2) essentially no resource contention;
3) transport connection operation can be written in microcode,
separate from network service handling;
4) transport connections can run with true parallelism;
5) throughput is not limited by contention of connections for CPU
and network access; and
6) lower software complexity, due to functional separation.
Possible disadvantages are greater inflexibility and hardware
complexity. However, these might be offset by lower development
costs for microcode, since the code separation should provide overall
lower code complexity in the TPE and the TPM implementations.
In this system, the TPE instantiates a TPM by enabling its clock.
Incoming Outgoing are passed to the TPMs along the memory bus. TPDUs
TPDUs from a TPM are sent on the output data bus. The user interface
controller accepts connect requests from the user and directs them to
the TPE. The TPE assigns a connection reference and informs the
interface controller to direct further inputs for this connection to
the designated TPM. The shared TPM memory is analogous to the
exported variables of the TPM modules in the formal description, and
is used by the TPE to input TPDUs and other information to the TPM.
In summary, the off-loading of communications protocols onto
independent processing systems attached to a host processor across a
system bus is quite common. As processing power and memory become
cheaper, the amount of software off-loaded grows. it is now typical
to fine transport service available for several system buses with
interfaces to operating systems such as UNIX, XENIX, iRMX, MS-DOS,
and VERSADOS.
McCoy [Page 22]
RFC 1008 June 1987
Legend: **** data channel
.... control channel
==== interface i/o bus
O channel or bus connection point
user
input
*
*
__________V_________
| user interface | input bus
| controller |=================O==============O=======
|__________________| * *
* * *
* * _______*_______
* * | data buffers|
* * ...| TPM1 |
* * : |_____________|
* * : *
* * : *
_________ _____*__________ ________ __*____:______ *
| TPE | | TPE processor| |shared| | TPM1 | *
|buffers|***| | | TPM1 |***| processor | *
|_______| |______________| | mem. | |____________| *
* : : * |______| : *
* : : * * : *
* : : ***********O***********:********************
* : : memory bus : *
* : : : *
* : :...........................O...........*........
____*_________:___ clock enable *
| network | *
| interface |=========================================O========
| controller | output data bus
|________________|
*
*
V
to network
interface
2.4 Front end processor.
A more traditional approach to off-loading communications protocols
involves the use of a free-standing front end processor, an approach
very similar to that of placing the transport service onto a board
attached to the system bus. The difference is one of scale. Typical
front end p interface locally as desirable, as long as such additions
are strictly local (i.e., the invoking of such services does not
McCoy [Page 23]
RFC 1008 June 1987
result in the exchange of TPDUs with the peer entity).
The interface between the user and transport is by nature
asynchronous (although some hypothetical implementation that is
wholly synchronous could be conjectured). This characteristic is
due to two factors: 1) the interprocess communications (IPC)
mechanism--used between the user and transport--decouples the
two, and to avoid blocking the user process (while waiting for a
response) requires an asynchronous response mechanism, and 2)
there are some asynchronously-generated transport indications that
must be handled (e.g., the arrival of user data or the abrupt
termination of the transport connection due to network errors).
If it is assumed that the user interface to transport is
asynchronous, there are other aspects of the interface that are also
predetermined. The most important of these is that transport
service requests are confirmed twice. The first confirmation occurs
at the time of the transport service request initiation. Here,
interface routines can be used to identify invalid sequences of
requests, such as a request to send data on a connection that is
not yet open. The second confirmation occurs when the service
request crosses the interface into the transport entity. The entity
may accept or reject the request, depending on its resources and its
assessment of connection (transport and network) status, priority,
service quality.
If the interface is to be asynchronous, then some mechanism must be
provided to handle the asynchronous (and sometimes unexpected)
events. Two ways this is commonly achieved are: 1) by polling, and
2) by a software interrupt mechanism. The first of these can be
wasteful of host resources in a multiprogramming environment, while
the second may be complicated to implement. However, if the
interface is a combination of hardware and software, as in the cases
discussed in Parts 2.3 and 2.4, then hardware interrupts may be
available.
One way of implementing the abstract services is to associate with
each service primitive an actual function that is invoked. Such
functions could be held in a special interface library with other
functions and procedures that realize the interface. Each service
primitive function would access the interprocess communication (IPC)
mechanism as necessary to pass parameters to/from the transport
entity.
The description of the abstract service in IS 8073 and N3756 implies
that the interface must handle TSDUs of arbitrary length. This
situation suggests that it may be useful to implement a TSDU as an
object such as a file-pointer rather than as the message itself. In
this way, in the sending entity, TPDUs can be formed by reading
segments of TPDU-size from the file designated, without regard for
the actual length of the file. In the receiving entity, each new
McCoy [Page 24]
RFC 1008 June 1987
TPDU could be buffered in a file designated by a file-pointer, which
would then be passed to the user when the EOT arrives. In the formal
description of transport, this procedure is actually described,
although explicit file-pointers and files are not used in the
description. This method of implementing the data interface is not
essentially different from maintaining a linked list of buffers. (A
disk file is arranged in precisely this fashion, although the file
user is usually not aware of the structure.)
The abstract service definition describes the set of parameters
that must be passed in each of the service primitives so that
transport can act properly on behalf of the user. These
parameters are required for the transport protocol to operate
correctly (e.g., a called address must be passed with the
connect request and the connect response must contain a responding
address). The abstract service defintion does not preclude,
however, the inclusion of local parameters. Local parameters may be
included in the implementation of the service interface for use
by the local entity. One example is a buffer management parameter
passed from the user in connect requests and confirms, providing
the transport entity with expected buffer usage estimates. The
local entity could use this in implementing a more efficient
buffer management strategy than would otherwise be possible.
One issue that is of importance when designing and implementing
a transport entity is the provision of a registration mechanism for
transport users. This facility provides a means of identifying to
the transport entity those users who are willing to participate in
communications with remote users. An example of such a user is a
data base management system, which ordinarily responds to connections
requests rather than to initiate them. This procedure of user
identification is sometimes called a "passive open". There are
several ways in which registration can be implemented. One is to
install the set of users that provide services in a table at
system generation time. This method may have the disadvantage of
being inflexible. A more flexible approach is to implement a
local transport service primitive, "listen", to indicate a waiting
user. The user then registers its transport suffix with the
transport entity via the listen primitive. Another possibility is a
combination of predefined table and listen primitive. Other
parameters may also be included, such as a partially or fully
qualified transport address from which the user is willing to
receive connections. A variant on this approach is to
provide an ACTIVE/PASSIVE local parameter on the connect request
service primitive. Part 5 discusses this issue in more detail.
3.2 Flow control.
Interface flow control is generally considered to be a local
implementation issue. However, in order to completely specify the
behavior of the transport entity, it was necessary to include in the
McCoy [Page 25]
RFC 1008 June 1987
formal description a model of the control of data flow across the
service boundaries of transport. The international standards for
transport and the OSI reference model state only that interface flow
control shall be provided but give no guidance on its features.
The actual mechanisms used to accomplish flow control, which need not
explicitly follow the model in the formal description, are dependent
on the way in which the interface itself is realized, i.e., what
TSDUs and service primitives really are and how the transport entity
actually communicates with its user, its environment, and the network
service. For example, if the transport entity communicates with its
user by means of named (UNIX) pipes, then flow control can be
realized using a special interface library routine, which the
receiving process invokes, to control the pipe. This approach also
entails some consideration for the capacity of the pipe and blocking
of the sending process when the pipe is full (discussed further in
Part 3.3). The close correspondence of this interpretation to the
model is clear. However, such an interpretation is apparently not
workable if the user process and the transport entity are in
physically separate processors. In this situation, an explicit
protocol between the receiving process and the sending process must
be provided, which could have the complexity of the data transfer
portion of the Class 0 transport protocol (Class 2 if flow
controlled). Note that the formal model, under proper
interpretation, also describes this mechanism.
3.3 Interprocess communication.
One of the most important elements of a data communication system is
the approach to interprocess communication (IPC). This is true
because suites of protocols are often implemented as groups of
cooperating tasks. Even if the protocol suites are not implemented
as task groups, the communication system is a funnel for service
requests from multiple user processes. The services are normally
communicated through some interprocess pathway. Usually, the
implementation environment places some restrictions upon the
interprocess communications method that can be used. This section
describes the desired traits of IPC for use in data communications
protocol implementations, outlines some possible uses for IPC, and
discusses three common and generic approaches to IPC.
To support the implementation of data communications protocols, IPC
should possess several desirable traits. First, IPC should be
transaction based. This permits sending a message without the
overhead of establishing and maintaining a connection. The
transactions should be confirmed so that a sender can detect and
respond to non-delivery. Second, IPC should support both the
synchronous and the asynchronous modes of message exchange. An IPC
receiver should be able to ask for delivery of any pending messages
and not be blocked from continuing if no messages are present.
Optionally, the receiver should be permitted to wait if no messages
McCoy [Page 26]
RFC 1008 June 1987
are present, or to continue if the path to the destination is
congested. Third, IPC should preserve the order of messages sent to
the same destination. This allows the use of the IPC without
modification to support protocols that preserve user data sequence.
Fourth, IPC should provide a flow control mechanism to allow pacing
of the sender's transmission speed to that of the receiver.
The uses of IPC in implementation of data communication systems are
many and varied. A common and expected use for IPC is that of
passing user messages among the protocol tasks that are cooperating
to perform the data communication functions. The user messages may
contain the actual data or, more efficiently, references to the
location of the user data. Another common use for the IPC is
implementation and enforcement of local interface flow control. By
limiting the number of IPC messages queued on a particular address,
senders can be slowed to a rate appropriate for the IPC consumer. A
third typical use for IPC is the synchronization of processes. Two
cooperating tasks can coordinate their activities or access to shared
resources by passing IPC messages at particular events in their
processing.
More creative uses of IPC include buffer, timer, and scheduling
management. By establishing buffers as a list of messages available
at a known address at system initialization time, the potential
exists to manage buffers simply and efficiently. A process requiring
a buffer would simply read an IPC message from the known address. If
no messages (i.e., buffers) are available, the process could block
(or continue, as an option). A process that owned a buffer and
wished to release it would simply write a message to the known
address, thus unblocking any processes waiting for a buffer.
To manage timers, messages can be sent to a known address that
represents the timer module. The timer module can then maintain the
list of timer messages with respect to a hardware clock. Upon
expiration of a timer, the associated message can be returned to the
originator via IPC. This provides a convenient method to process the
set of countdown timers required by the transport protocol.
Scheduling management can be achieved by using separate IPC addresses
for message classes. A receiving process can enforce a scheduling
discipline by the order in which the message queues are read. For
example, a transport process might possess three queues: 1) normal
data from the user, 2) expedited data from the user, and 3) messages
from the network. If the transport process then wants to give top
priority to network messages, middle priority to expedited user
messages, and lowest priority to normal user messages, all that is
required is receipt of IPC messages on the highest priority queue
until no more messages are available. Then the receiver moves to the
next lower in priority and so on. More sophistication is possible by
setting limits upon the number of consecutive messages received from
each queue and/or varying the order in which each queue is examined.
McCoy [Page 27]
RFC 1008 June 1987
It is easy to see how a round-robin scheduling discipline could be
implemented using this form of IPC.
Approaches to IPC can be placed into one of three classes: 1) shared
memory, 2) memory-memory copying, and 3) input/output channel
copying. Shared memory is the most desirable of the three classes
because the amount of data movement is kept to a minimum. To pass
IPC messages using shared memory, the sender builds a small message
referencing a potentially large amount of user data. The small
message is then either copied from the sender's process space to the
receiver's process space or the small message is mapped from one
process space to another using techniques specific to the operating
system and hardware involved. These approaches to shared memory are
equivalent since the amount of data movement is kept to a minimum.
The price to be paid for using this approach is due to the
synchronization of access to the shared memory. This type of sharing
is well understood, and several efficient and simple techniques exist
to manage the sharing.
Memory-memory copying is an approach that has been commonly used for
IPC in UNIX operating system implementations. To pass an IPC message
under UNIX data is copied from the sender's buffer to a kernel buffer
and then from a kernel buffer to the receiver's buffer. Thus two
copy operations are required for each IPC message. Other methods
might only involve a single copy operation. Also note that if one of
the processes involved is the transport protocol implemented in the
kernel, the IPC message must only be copied once. The main
disadvantage of this approach is inefficiency. The major advantage
is simplicity.
When the processes that must exchange messages reside on physically
separate computer systems (e.g., a host and front end), an
input/output channel of some type must be used to support the IPC.
In such a case, the problem is similar to that of the general problem
of a transport protocol. The sender must provide his IPC message to
some standard operating system output mechanism from where it will be
transmitted via some physical medium to the receiver's operating
system. The receiver's operating system will then pass the message
on to the receiving process via some standard operating system input
mechanism. This set of procedures can vary greatly in efficiency and
complexity depending upon the operating systems and hardware
involved. Usually this approach to IPC is used only when the
circumstances require it.
3.4 Interface to real networks.
Implementations of the class 4 transport protocol have been operated
over a wide variety of networks including: 1) ARPANET, 2) X.25
networks, 3) satellite channels, 4) CSMA/CD local area networks, 5)
token bus local area networks, and 6) token ring local area
networks. This section briefly describes known instances of each use
McCoy [Page 28]
RFC 1008 June 1987
of class 4 transport and provides some quantitative evaluation of the
performance expectations for transport over each network type.
3.4.1 Issues.
The interface of the transport entity to the network service in
general will be realized in a different way from the user interface.
The network service processor is often separate from the host CPU,
connected to it by a bus, direct memory access (DMA), or other link.
A typical way to access the network service is by means of a device
driver. The transfer of data across the interface in this instance
would be by buffer-copying. The use of double-buffering reduces some
of the complexity of flow control, which is usually accomplished by
examining the capacity of the target buffer. If the transport
processor and the network processor are distinct and connected by a
bus or external link, the network access may be more complicated
since copying will take place across the bus or link rather than
across the memory board. In any case, the network service
primitives, as they appear in the formal description and IS 8073 must
be carefully correlated to the actual access scheme, so that the
semantics of the primitives is preserved. One way to do this is to
create a library of routines, each of which corresponds to one of the
service primitives. Each routine is responsible for sending the
proper signal to the network interface unit, whether this
communication is directly, as on a bus, or indirectly via a device
driver. In the case of a connectionless network service, there is
only one primitive, the N_DATA_request (or N_UNIT_DATA_request),
which has to be realized.
In the formal description, flow control to the NSAP is controlled by
by a Slave module, which exerts the "backpressure" on the TPM if its
internal queue gets too long. Incoming flow, however, is controlled
in much the same way as the flow to the transport user is controlled.
The implementor is reminded that the formal description of the flow
control is specified for completeness and not as an implementation
guide. Thus, an implementation should depend upon actual interfaces
in the operating environment to realize necessary functions.
3.4.2 Instances of operation.
3.4.2.1 ARPANET
An early implementation of the class 4 transport protocol was
developed by the NBS as a basis for conformance tests [NBS83]. This
implementation was used over the ARPANET to communicate between NBS,
BBN, and DCA. The early NBS implementation was executed on a
PDP-11/70. A later revision of the NBS implementation has been moved
to a VAX-11/750 and VAX-11/7;80. The Norwegian Telecommunication
Administration (NTA) has implemented class 4 transport for the UNIX
BSD 4.2 operating system to run on a VAX [NTA84]. A later NTA
implementation runs on a Sun 2-120 workstation. The University of
McCoy [Page 29]
RFC 1008 June 1987
Wisconsin has also implemented the class 4 transport protocol on a
VAX-11/750 [BRI85]. The Wisconsin implementation is embedded in the
BSD 4.2 UNIX kernel. For most of these implementations class 4
transport runs above the DOD IP and below DOD application protocols.
3.4.2.2 X.25 networks
The NBS implementations have been used over Telenet, an X.25 public
data network (PDN). The heaviest use has been testing of class 4
transport between the NBS and several remotely located vendors, in
preparation for a demonstration at the 1984 National Computing
Conference and the 1985 Autofact demonstration. Several approaches
to implementation were seen in the vendors' systems, including ones
similar to those discussed in Part 6.2. At the Autofact
demonstration many vendors operated class 4 transport and the ISO
internetwork protocol across an internetwork of CSMA/CD and token bus
local networks and Accunet, an AT&T X.25 public data network.
3.4.2.3 Satellite channels.
The COMSAT Laboratories have implemented class 4 transport for
operation over point-to-point satellite channels with data rates up
to 1.544 Mbps [CHO85]. This implementation has been used for
experiments between the NBS and COMSAT. As a result of these
experiments several improvements have been made to the class 4
transport specification within the international standards arena
(both ISO and CCITT). The COMSAT implementation runs under a
proprietary multiprocessing operating system known as COSMOS. The
hardware base includes multiple Motorola 68010 CPUs with local memory
and Multibus shared memory for data messages.
3.4.2.4 CSMA/CD networks.
The CSMA/CD network as defined by the IEEE 802.3 standard is the most
popular network over which the class 4 transport has been
implemented. Implementations of transport over CSMA/CD networks have
been demonstrated by: AT&T, Charles River Data Systems,
Computervision, DEC, Hewlitt-Packard, ICL, Intel, Intergraph, NCR and
SUN. Most of these were demonstrated at the 1984 National Computer
Conference [MIL85b] and again at the 1985 Autofact Conference.
Several of these vendors are now delivering products based on the
demonstration software.
3.4.2.5 Token bus networks.
Due to the establishment of class 4 transport as a mandatory protocol
within the General Motor's manufacturing automation protocol (MAP),
many implementations have been demonstrated operating over a token
bus network as defined by the IEEE 802.4 standard. Most past
implementations relied upon a Concord Data Systems token interface
module (TIM) to gain access to the 5 Mbps broadband 802.4 service.
McCoy [Page 30]
RFC 1008 June 1987
Several vendors have recently announced boards supporting a 10 Mbps
broadband 802.4 service. The newer boards plug directly into
computer system buses while the TIM's are accessed across a high
level data link control (HDLC) serial channel. Vendors demonstrating
class 4 transport over IEEE 802.4 networks include Allen-Bradley,
AT&T, DEC, Gould, Hewlett-Packard, Honeywell, IBM, Intel, Motorola,
NCR and Siemens.
3.4.2.6 Token ring networks.
The class 4 transport implementations by the University of Wisconsin
and by the NTA run over a 10 Mbps token ring network in addition to
ARPANET. The ring used is from Proteon rather than the recently
finished IEEE 802.5 standard.
3.4.3 Performance expectations.
Performance research regarding the class 4 transport protocol has
been limited. Some work has been done at the University of
Wisconsin, at NTA, at Intel, at COMSAT, and at the NBS. The material
presented below draws from this limited body of research to provide
an implementor with some quantitative feeling for the performance
that can be expected from class 4 transport implementations using
different network types. More detail is available from several
published reports [NTA84, BRI85, INT85, MIL85b, COL85]. Some of the
results reported derive from actual measurements while other results
arise from simulation. This distinction is clearly noted.
3.4.3.1 Throughput.
Several live experiments have been conducted to determine the
throughput possible with implementations of class 4 transport.
Achievable throughput depends upon many factors including: 1) CPU
capabilities, 2) use or non-use of transport checksum, 3) IPC
mechanism, 4) buffer management technique, 5) receiver resequencing,
6) network error properties, 7) transport flow control, 8) network
congestion and 9) TPDU size. Some of these are specifically
discussed elsewhere in this document. The reader must keep in mind
these issues when interpreting the throughput measures presented
here.
The University of Wisconsin implemented class 4 transport in the UNIX
kernel for a VAX-11/750 with the express purpose of measuring the
achievable throughput. Throughputs observed over the ARPANET ranged
between 10.4 Kbps and 14.4 Kbps. On an unloaded Proteon ring local
network, observed throughput with checksum ranged between 280 Kbps
and 560 Kbps. Without checksum, throughput ranged between 384 Kbps
and 1 Mbps.
The COMSAT Laboratories implemented class 4 transport under a
proprietary multiprocessor operating system for a multiprocessor
McCoy [Page 31]
RFC 1008 June 1987
68010 hardware architecture. The transport implementation executed
on one 68010 while the traffic generator and link drivers executed on
a second 68010. All user messages were created in a global shared
memory and were copied only for transmission on the satellite link.
Throughputs as high as 1.4 Mbps were observed without transport
checksumming while up to 535 Kbps could be achieved when transport
checksums were used. Note that when the 1.4 Mbps was achieved the
transport CPU was idle 20% of the time (i.e., the 1.544 Mbps
satellite link was the bottleneck). Thus, the transport
implementation used here could probably achieve around 1.9 Mbps user
throughput with the experiment parameters remaining unchanged.
Higher throughputs are possible by increasing the TPDU size; however,
larger messages stand an increased chance of damage during
transmission.
Intel has implemented a class 4 transport product for operation over
a CSMA/CD local network (iNA-960 running on the iSBC 186/51 or iSXM
552). Intel has measured throughputs achieved with this combination
and has published the results in a technical analysis comparing
iNA-960 performance on the 186/51 with iNA-960 on the 552. The CPU
used to run transport was a 6 MHz 80186. An 82586 co-processor was
used to handle the medium access control. Throughputs measured
ranged between 360 Kbps and 1.32 Mbps, depending on the parameter
values used.
Simulation of class 4 transport via a model developed at the NBS has
been used to predict the performance of the COMSAT implementation and
is now being used to predict the performance of a three processor
architecture that includes an 8 MHz host connected to an 8 MHz front
end over a system bus. The third processor provides medium access
control for the specific local networks being modeled. Early model
results predict throughputs over an unloaded CSMA/CD local network of
up to 1.8 Mbps. The same system modeled over a token bus local
network with the same transport parameters yields throughput
estimates of up to 1.6 Mbps. The token bus technology, however,
permits larger message sizes than CSMA/CD does. When TPDUs of 5120
bytes are used, throughput on the token bus network is predicted to
reach 4.3 Mbps.
3.4.3.2 Delay.
The one-way delay between sending transport user and receiving
transport user is determined by a complex set of factors. Readers
should also note that, in general, this is a difficult measure to
make and little work has been done to date with respect to expected
one-way delays with class 4 transport implementations. In this
section a tutorial is given to explain the factors that determine the
one-way delay to be expected by a transport user. Delay experiments
performed by Intel are reported [INT85], as well as some simulation
experiments conducted by the NBS [MIL85a].
McCoy [Page 32]
RFC 1008 June 1987
The transport user can generally expect one-way delays to be
determined by the following equation.
D = TS + ND + TR + [IS] + [IR] (1)
where:
[.] means the enclosed quantity may be 0
D is the one-way transport user delay,
TS is the transport data send processing time,
IS is the internet datagram send processing time,
ND is the network delay,
IR is the internet datagram receive processing
time, and
TR is the transport data receive processing time.
Although no performance measurements are available for the ISO
internetwork protocol (ISO IP), the ISO IP is so similar to the DOD
IP that processing times associated with sending and receiving
datagrams should be the about the same for both IPs. Thus, the IS
and IR terms given above are ignored from this point on in the
discussion. Note that many of these factors vary depending upon the
application traffic pattern and loads seen by a transport
implementation. In the following discussion, the transport traffic
is assumed to be a single message.
The value for TS depends upon the CPU used, the IPC mechanism, the
use or non-use of checksum, the size of the user message and the size
of TPDUs, the buffer management scheme in use, and the method chosen
for timer management. Checksum processing times have been observed
that include 3.9 us per octet for a VAX-11/750, 7.5 us per octet on a
Motorola 68010, and 6 us per octet on an Intel 80186. The class 4
transport checksum algorithm has considerable effect on achievable
performance. This is discussed further in Part 7. Typical values for
TS, excluding the processing due to the checksum, are about 4 ms for
CPUs such as the Motorola 68010 and the Intel 80186. For 1024 octet
TPDUs, checksum calculation can increase the TS value to about 12 ms.
The value of TR depends upon similar details as TS. An additional
consideration is whether or not the receiver caches (buffers) out of
order TPDUs. If so, the TR will be higher when no packets are lost
(because of the overhead incurred by the resequencing logic). Also,
McCoy [Page 33]
RFC 1008 June 1987
when packets are lost, TR can appear to increase due to transport
resequencing delay. When out of order packets are not cached, lost
packets increase D because each unacknowledged packet must be
retransmitted (and then only after a delay waiting for the
retransmission timer to expire). These details are not taken into
account in equation 1. Typical TR values that can be expected with
non-caching implementations on Motorola 68010 and Intel 80186 CPUs
are approximately 3 to 3.5 ms. When transport checksumming is used
on these CPUs, TR becomes about 11 ms for 1024 byte TPDUs.
The value of ND is highly variable, depending on the specific network
technology in use and on the conditions in that network. In general,
ND can be defined by the following equation.
ND = NQ + MA + TX + PD + TQ (2)
where:
NQ is network queuing delay,
MA is medium access delay,
TX is message transmission time,
PD is network propagation delay, and
TQ is transport receive queuing delay.
Each term of the equation is discussed in the following paragraphs.
Network queuing delay (NQ) is the time that a TPDU waits on a network
transmit queue until that TPDU is the first in line for transmission.
NQ depends on the size of the network transmit queue, the rate at
which the queue is emptied, and the number of TPDUs already on the
queue. The size of the transmit queue is usually an implementation
parameter and is generally at least two messages. The rate at which
the queue empties depends upon MA and TX (see the discussion below).
The number of TPDUs already on the queue is determined by the traffic
intensity (ratio of mean arrival rate to mean service rate). As an
example, consider an 8 Kbps point-to-point link serving an eight
message queue that contains 4 messages with an average size of 200
bytes per message. The next message to be placed into the transmit
queue would experience an NQ of 800 ms (i.e., 4 messages times 200
ms). In this example, MA is zero. These basic facts permit the
computation of NQ for particular environments. Note that if the
network send queue is full, back pressure flow control will force
TPDUs to queue in transport transmit buffers and cause TS to appear
to increase by the amount of the transport queuing delay. This
condition depends on application traffic patterns but is ignored for
McCoy [Page 34]
RFC 1008 June 1987
the purpose of this discussion.
The value of MA depends upon the network access method and on the
network congestion or load. For a point-to-point link MA is zero.
For CSMA/CD networks MA depends upon the load, the number of
stations, the arrival pattern, and the propagation delay. For
CSMA/CD networks MA has values that typically range from zero (no
load) up to about 3 ms (80% loads). Note that the value of MA as
seen by individual stations on a CSMA/CD network is predicted (by NBS
simulation studies) to be as high as 27 ms under 70% loads. Thus,
depending upon the traffic patterns, individual stations may see an
average MA value that is much greater than the average MA value for
the network as a whole. On token bus networks MA is determined by the
token rotation time (TRT) which depends upon the load, the number of
stations, the arrival pattern, the propagation delay, and the values
of the token holding time and target rotation times at each station.
For small networks of 12 stations with a propagation delay of 8 ns,
NBS simulation studies predict TRT values of about 1 ms for zero load
and 4.5 ms for 70% loads for 200 byte messages arriving with
exponential arrival distribution. Traffic patterns also appear to be
an important determinant of target rotation time. When a pair of
stations performs a continuous file transfer, average TRT for the
simulated network is predicted to be 3 ms for zero background load
and 12.5 ms for 70% background load (total network load of 85%).
The message size and the network transmission speed directly
determine TX. Typical transmission speeds include 5 and 10 Mbps for
standard local networks; 64 Kbps, 384 Kbps, or 1.544 Mbps for
point-to-point satellite channels; and 9.6 Kbps or 56 Kbps for
public data network access links.
The properties of the network in use determine the values of PD. On
an IEEE 802.3 network, PD is limited to 25.6 us. For IEEE 802.4
networks, the signal is propagated up-link to a head end and then
down-link from the head end. Propagation delay in these networks
depends on the distance of the source and destination stations from
the head end and on the head end latency. Because the maximum network
length is much greater than with IEEE 802.3 networks, the PD values
can also be much greater. The IEEE 802.4 standard requires that a
network provider give a value for the maximum transmission path
delay. For satellite channels PD is typically between 280 and 330
ms. For the ARPANET, PD depends upon the number of hops that a
message makes between source and destination nodes. The NBS and NTIA
measured ARPANET PD average values of about 190 ms [NTI85]. In the
ARPA internet system the PD is quite variable, depending on the
number of internet gateway hops and the PD values of any intervening
networks (possibly containing satellite channels). In experiments on
an internetwork containing a a satellite link to Korea, it was
determined by David Mills [RFC85] that internet PD values could range
from 19 ms to 1500 ms. Thus, PD values ranging from 300 to 600 ms
McCoy [Page 35]
RFC 1008 June 1987
can be considered as typical for ARPANET internetwork operation.
The amount of time a TPDU waits in the network receive queue before
being processed by the receiving transport is represented by TQ,
similar to NQ in that the value of TQ depends upon the size of the
queue, the number of TPDUs already in the queue, and the rate at
which the queue is emptied by transport.
Often the user delay D will be dominated by one of the components. On
a satellite channel the principal component of D is PD, which implies
that ND is a principal component by equation (2). On an unloaded
LAN, TS and TR might contribute most to D. On a highly loaded LAN,
MA may cause NQ to rise, again implying that ND is a major factor in
determining D.
Some one-way delay measures have been made by Intel for the iNA-960
product running on a 6 MHz 80186. For an unloaded 10 Mbps CSMA/CD
network the Intel measures show delays as low as 22 ms. The NBS has
done some simulations of class 4 transport over 10 Mbps CSMA/CD and
token bus networks. These (unvalidated) predictions show one-way
delays as low as 6 ms on unloaded LANs and as high as 372 ms on
CSMA/CD LANs with 70% load.
3.4.3.3 Response time.
Determination of transport user response time (i.e., two-way delay)
depends upon many of the same factors discussed above for one-way
delay. In fact, response time can be represented by equation 3 as
shown below.
R = 2D + AS + AR (3)
where:
R is transport user response time,
D is one-way transport user delay,
AS is acknowledgement send processing time, and
AR is acknowledgement receive processing time.
D has been explained above. AS and AR deal with the acknowledgement
sent by transport in response to the TPDU that embodies the user
request.
AS is simply the amount of time that the receiving transport must
spend to generate an AK TPDU. Typical times for this function are
about 2 to 3 ms on processors such as the Motorola 68010 and the
Intel 80186. Of course the actual time required depends upon factors
such as those explained for TS above.
McCoy [Page 36]
RFC 1008 June 1987
The amount of time, AR, that the sending transport must spend to
process a received AK TPDU. Determination of the actual time
required depends upon factors previously described. Note that for AR
and AS, processing when the checksum is included takes somewhat
longer. However, AK TPDUs are usually between 10 and 20 octets in
length and therefore the increased time due to checksum processing is
much less than for DT TPDUs.
No class 4 transport user response time measures are available;
however, some simulations have been done at the NBS. These
predictions are based upon implementation strategies that have been
used by commercial vendors in building microprocessor-based class 4
transport products. Average response times of about 21 ms on an
unloaded 10 Mbps token bus network, 25 ms with 70% loading, were
predicted by the simulations. On a 10 Mbps CSMA/CD network, the
simulations predict response times of about 17 ms for no load and 54
ms for a 70% load.
3.5 Error and status reporting.
Although the abstract service definition for the transport protocol
specifies a set of services to be offered, the actual set of
services provided by an implementation need not be limited to
these. In particular, local status and error information can be
provided as a confirmed service (request/response) and as an
asynchronous "interrupt" (indication). One use for this service is
to allow users to query the transport entity about the status of
their connections. An example of information that could be
returned from the entity is:
o connection state
o current send sequence number
o current receive and transmit credit windows
o transport/network interface status
o number of retransmissions
o number of DTs and AKs sent and received
o current timer values
Another use for the local status and error reporting service is for
administration purposes. Using the service, an administrator can
gather information such as described above for each open connection.
In addition, statistics concerning the transport entity as a whole
can be obtained, such as number of transport connections open,
average number of connections open over a given reporting period,
buffer use statistics, and total number of retransmitted DT TPDUs.
The administrator might also be given the authority to cancel
connections, restart the entity, or manually set timer values.
McCoy [Page 37]
RFC 1008 June 1987
4 Entity resource management.
4.1 CPU management.
The formal description has implicit scheduling of TPM modules, due to
the semantics of the Estelle structuring principles. However, the
implementor should not depend on this scheduling to obtain optimal
behavior, since, as stated in Part 1, the structures in the formal
description were imposed for purposes other than operational
efficiency.
Whether by design or by default, every implementation of the
transport protocol embodies some decision about allocating the CPU
resource among transport connections. The resource may be
monolithic, i.e. a single CPU, or it may be distributed, as in the
example design given in Part 2.3. In the former, there are two
simple techniques for apportioning CPU processing time among
transport connections. The first of these,
first-come/first-served, consists of the transport entity handling
user service requests in the order in which they arrive. No
attempt is made to prevent one transport connection from using
an inordinate amount of the CPU.
The second simple technique is round-robin scheduling of
connections. Under this method, each transport connection is
serviced in turn. For each connection, transport processes one
user service request, if there is one present at the interface,
before proceeding to the next connection.
The quality of service parameters provided in the connection request
can be used to provide a finer-grained strategy for managing the CPU.
The CPU could be allocated to connections requiring low delay more
often while those requiring high throughput would be served less
often but for longer periods (i.e., several connections requiring
high throughput might be serviced in a concurrent cluster).
For example, in the service sequence below, let "T" represent
m > 0 service requests, each requiring high throughput, let "D"
represent one service request requiring low delay and let the suffix
n = 1,2,3 represent a connection identifier, unique only within a
particular service requirement type (T,D). Thus T1 represents a set
of service requests for connection 1 of the service requirement type
T, and D1 represents a service set (with one member) for connection 1
of service requirement type D.
D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1...
If m = 4 in this service sequence, then service set D1 will get
worst-case service once every seventh service request processed.
Service set T1 receives service on its four requests only once in
McCoy [Page 38]
RFC 1008 June 1987
fourteen requests processed.
D1___D2___D3___T1___D1___D2___D3___T2___D1___D2___D3___T1...
| | | | | |
| 3 requests | 4 | 3 | 4 | 3 |
This means that the CPU is allocated to T1 29% ( 4/14 ) of the
available time, whereas D1 obtains service 14% ( 1/7 ) of the time,
assuming processing requirements for all service requests to be
equal. Now assume that, on average, there is a service request
arriving for one out of three of the service requirement type D
connections. The CPU is then allocated to the T type 40% ( 4/10 )
while the D type is allocated 10% ( 1/10 ).
4.2 Buffer management.
Buffers are used as temporary storage areas for data on its way to
or arriving from the network. Decisions must be made about buffer
management in two areas. The first is the overall strategy for
managing buffers in a multi-layered protocol environment. The
second is specifically how to allocate buffers within the
transport entity.
In the formal description no details of buffer strategy are given,
since such strategy depends so heavily on the implementation
environment. Only a general mechanism is discussed in the formal
description for allocating receive credit to a transport connection,
without any expression as to how this resource is managed.
Good buffer management should correlate to the traffic presented by
the applications using the transport service. This traffic has
implications as well for the performance of the protocol. At present,
the relationship of buffer strategy to optimal service for a given
traffic distribution is not well understood. Some work has been
done, however, and the reader is referred to the work of Jeffery
Spirn [SPI82, SPI83] and to the experiment plan for research by the
NBS [HEA85] on the effect of application traffic patterns on the
performance of Class 4 transport.
4.2.1 Overall buffer strategy.
Three schemes for management of buffers in a multilayered
environment are described here. These represent a spectrum of
possibilities available to the implementor. The first of these is a
strictly layered approach in which each entity in the protocol
hierarchy, as a process, manages its own pool of buffers
independently of entities at other layers. One advantage of this
approach is simplicity; it is not necessary for an entity to
coordinate buffer usage with a resource manager which is serving
the needs of numerous protocol entities. Another advantage is
modularity. The interface presented to entities in other layers is
McCoy [Page 39]
RFC 1008 June 1987
well defined; protocol service requests and responses are passed
between layers by value (copying) versus by reference (pointer
copying). In particular, this is a strict interpretation of the OSI
reference model, IS 7498 [ISO84b], and the protocol entities hide
message details from each other, simplifying handling at the entity
interfaces.
The single disadvantage to a strictly layered scheme derives from
the value-passing nature of the interface. Each time protocol
data and control information is passed from one layer to another
it must be copied from one layer's buffers to those of another layer.
Copying between layers in a multi-layered environment is
expensive and imposes a severe penalty on the performance of the
communications system, as well as the computer system on which it is
running as a whole.
The second scheme for managing buffers among multiple protocol
layers is buffer sharing. In this approach, buffers are a
shared resource among multiple protocol entities; protocol data and
control information contained in the buffers is exchanged by passing
a buffer pointer, or reference, rather than the values as in the
strictly layered approach described above. The advantage to
passing buffers by reference is that only a small amount of
information, the buffer pointer, is copied from layer to layer.
The resulting performance is much better than that of the strictly
layered approach.
There are several requirements that must be met to implement
buffer sharing. First, the host system architecture must allow
memory sharing among protocol entities that are sharing the
buffers. This can be achieved in a variety of ways: multiple
protocol entities may be implemented as one process, all sharing
the same process space (e.g., kernel space), or the host system
architecture may allow processes to map portions of their address
space to common buffer areas at some known location in physical
memory.
A buffer manager is another requirement for implementing shared
buffers. The buffer manager has the responsibility of providing
buffers to protocol entities when needed from a list of free
buffers and recycling used buffers back into the free list. The
pool may consist of one or more lists, depending on the level of
control desired. For example, there could be separate lists of
buffers for outgoing and incoming messages.
The protocol entities must be implemented in such a way as to
cooperate with the buffer manager. While this appears to be an
obvious condition, it has important implications for the strategy
used by implementors to develop the communications system. This
cooperation can be described as follows: an entity at layer N
requests and is allocated a buffer by the manager; each such buffer
McCoy [Page 40]
RFC 1008 June 1987
is returned to the manager by some entity at layer N - k (outgoing
data) or N + k (incoming data).
Protocol entities also must be designed to cooperate with each
other. As buffers are allocated and sent towards the network from
higher layers, allowance must be made for protocol control
information to be added at lower layers. This usually means
allocating oversized buffers to allow space for headers to be
prepended at lower layers. Similarly, as buffers move upward from
the network, each protocol entity processes its headers before
passing the buffer on. These manipulations can be handled by
managing pointers into the buffer header space.
In their pure forms, both strictly layered and shared buffer
schemes are not practical. In the former, there is a performance
penalty for copying buffers. On the other hand, it is not practical
to implement buffers that are shared by entities in all layers of the
protocol hierarchy: the lower protocol layers (OSI layers 1 - 4)
have essentially static buffer requirements, whereas the upper
protocol layers (OSI layers 5 - 7) tend to be dynamic in their buffer
requirements. That is, several different applications may be running
concurrently, with buffer requirements varying as the set of
applications varies. However, at the transport layer, this latter
variation is not visible and variations in buffer requirements will
depend more on service quality considerations than on the specific
nature of the applications being served. This suggests a hybrid
scheme in which the entities in OSI layers 1 - 4 share buffers while
the entities in each of the OSI layers 5 - 7 share in a buffer pool
associated with each layer. This approach provides most of the
efficiency of a pure shared buffer scheme and allows for simple,
modular interfaces where they are most appropriate.
4.2.2 Buffer management in the transport entity.
Buffers are allocated in the transport entity for two purposes:
sending and receiving data. For sending data, the decision of how
much buffer space to allocate is relatively simple; enough space
should be allocated for outgoing data to hold the maximum number of
data messages that the entity will have outstanding (i.e., sent but
unacknowledged) at any time. The send buffer space is determined by
one of two values, whichever is lower: the send credit received
from the receiving transport entity, or a maximum value imposed by
the local implementation, based on such factors as overall
buffer capacity.
The allocation of receive buffers is a more interesting problem
because it is directly related to the credit value transmitted the
peer transport entity in CR (or CC) and AK TPDUs. If the total
credit offered to the peer entity exceeds the total available buffer
space and credit reduction is not implemented, deadlock may
occur, causing termination of one or more transport connections. For
McCoy [Page 41]
RFC 1008 June 1987
the purposes of this discussion, offered credit is assumed to be
equivalent to available buffer space.
The simplest scheme for receive buffer allocation is allocation of
a fixed amount per transport connection. This amount is allocated
regardless of how the connection is to be used. This scheme is
fair in that all connections are treated equally. The implementation
approach in Part 2.3, in which each transport connection is handled
by a physically separate processor, obviously could use this scheme,
since the allocation would be in the form of memory chips assigned by
the system designer when the system is built.
A more flexible method of allocating receive buffer space is
based on the connection quality of service (QOS) requested by the
user. For instance, a QOS indicating high throughput would be given
more send and receive buffer space than one a QOS indicating low
delay. Similarly, connection priority can be used to determine
send and receive buffer allocation, with important (i.e., high
priority) connections allocated more buffer space.
A slightly more complex scheme is to apportion send and receive
buffer space using both QOS and priority. For each connection, QOS
indicates a general category of operation (e.g., high throughput or
low delay). Within the general category, priority determines the
specific amount of buffer space allocated from a range of
possible values. The general categories may well overlap, resulting,
for example, in a high priority connection with low throughput
requirements being allocated more buffer space than low priority
connection requiring a high throughput.
5 Management of Transport service endpoints.
As mentioned in Part 1.2.1.1, a transport entity needs some way of
referencing a transport connection endpoint within the end system: a
TCEP_id. There are several factors influencing the management of
TCEP_ids:
1) IPC mechanism between the transport entity and the session
entity (Part 3.3);
2) transport entity resources and resource management (Part 4);
3) number of distinct TSAPs supported by the entity (Part 1.2.2.1);
and
4) user process rendezvous mechanism (the means by which session
processes identify themselves to the transport entity, at a
given TSAP, for association with a transport connection);
The IPC mechanism and the user process rendezvous mechanism have more
direct influence than the other two factors on how the TCEP_id
McCoy [Page 42]
RFC 1008 June 1987
management is implemented.
The number of TCEP_ids available should reflect the resources that
are available to the transport entity, since each TCEP_id in use
represents a potential transport connection. The formal description
assumes that there is a function in the TPE which can decide, on the
basis of current resource availability, whether or not to issue a
TCEP_id for any connection request received. If the TCEP_id is
issued, then resources are allocated for the connection endpoint.
However, there is a somewhat different problem for the users of
transport. Here, the transport entity must somehow inform the
session entity as to the TCEP_ids available at a given TSAP.
In the formal description, a T-CONNECT-request is permitted to enter
at any TSAP/TCEP_id. A function in the TPE considers whether or not
resources are availble to support the requested connection. There is
also a function which checks to see if a TSAP/TCEP_id is busy by
seeing if there is a TPM allocated to it. But this function is not
useful to the session entity which does not have access to the
transport entity's operations. This description of the procedure is
clearly too loose for an implementation.
One solution to this problem is to provide a new (abstract) service,
T-REGISTER, locally, at the interface between transport and session.
___________________________________________________________________
| Primitives Parameters |
|_________________________________________________________________|
| T-REGISTER request | Session process identifier |
|________________________________|________________________________|
| T-REGISTER indication | Transport endpoint identifier,|
| | Session process identifier |
|________________________________|________________________________|
| T-REGISTER refusal | Session process identifier |
|________________________________|________________________________|
This service is used as follows:
1) A session process is identified to the transport entity by a
T-REGISTER-request event. If a TCEP_id is available, the
transport entity selects a TCEP_id and places it into a table
corresponding to the TSAP at which the T-REGISTER-request
event occurred, along with the session process identifier. The
TCEP_id and the session process identifier are then
transmitted to the session entity by means of the T-REGISTER-
indication event. If no TCEP_id is available, then a T-
REGISTER-refusal event carrying the session process identifier
is returned. At any time that an assigned TCEP_id is not
associated with an active transport connection process
(allocated TPM), the transport entity can issue a T-REGISTER-
McCoy [Page 43]
RFC 1008 June 1987
refusal to the session entity to indicate, for example, that
resources are no longer available to support a connection,
since TC resources are not allocated at registration time.
2) If the session entity is to initiate the transport connection,
it issues a T-CONNECT-request with the TCEP_id as a parameter.
(Note that this procedure is at a slight variance to the
procedure in N3756, which specifies no such parameter, due to
the requirement of alignment of the formal description with
the service description of transport and the definition of the
session protocol.) If the session entity is expecting a
connection request from a remote peer at this TSAP, then the
transport does nothing with the TCEP_id until a CR TPDU
addressed to the TSAP arrives. When such a CR TPDU arrives,
the transport entity issues a T-CONNECT-indication to the
session entity with a TCEP_id as a parameter. As a management
aid, the table entry for the TCEP_id can be marked "busy" when
the TCEP_id is associated with an allocated TPM.
3) If a CR TPDU is received and no TCEP_id is in the table for
the TSAP addressed, then the transport selects a TCEP_id,
includes it as a parameter in the T-CONNECT-indication sent to
the session entity, and places it in the table. The T-
CONNECT-response returned by the session entity will carry the
TCEP_id and the session process identifier. If the session
process identifier is already in the table, the new one is
discarded; otherwise it is placed into the table. This
procedure is also followed if the table has entries but they
are all marked busy or are empty. If the table is full and
all entries ar marked busy, then the transport entity
transmits a DR TPDU to the peer transport entity to indicate
that the connection cannot be made. Note that the transport
entity can disable a TSAP by marking all its table entries
busy.
The realization of the T-REGISTER service will depend on the IPC
mechanisms available between the transport and session entities. The
problem of user process rendezvous is solved in general by the T-
REGISTER service, which is based on a solution proposed by Michael
Chernik of the NBS [CHK85].
6 Management of Network service endpoints in Transport.
6.1 Endpoint identification.
The identification of endpoints at an NSAP is different from that for
the TSAP. The nature of the services at distinct TSAPs is
fundamentally the same, although the quality could vary, as a local
McCoy [Page 44]
RFC 1008 June 1987
choice. However, it is possible for distinct NSAPs to represent
access to essentially different network services. For example, one
NSAP may provide access to a connectionless network service by means
of an internetwork protocol. Another NSAP may provide access to a
connection-oriented service, for use in communicating on a local
subnetwork. It is also possible to have several distinct NSAPs on
the same subnetwork, each of which provides some service features of
local interest that distinguishes it from the other NSAPs.
A transport entity accessing an X.25 service could use the logical
channel numbers for the virtual circuits as NCEP_ids. An NSAP
providing access only to a permanent virtual circuit would need only
a single NCEP_id to multiplex the transport connections. Similarly,
a CSMA/CD network would need only a single NCEP_id, although the
network is connectionless.
6.2 Management issues.
The Class 4 transport protocol has been succesfully operated over
both connectionless and connection-oriented network services. In
both modes of operation there exists some information about the
network service that a transport implementation could make use of to
enhance performance. For example, knowledge of expected delay to a
destination would permit optimal selection of retransmission timer
value for a connection instance. The information that transport
implementations could use and the mechanisms for obtaining and
managing that information are, as a group, not well understood.
Projects are underway within ISO committees to address the management
of OSI as an architecture and the management of the transport layer
as a layer.
For operation of the Class 4 transport protocol over
connection-oriented network service several issues must be addressed
including:
a. When should a new network connection be opened to support a
transport connection (versus multiplexing)?
b. When a network connection is no longer being used by any
transport connection, should the network connection be closed
or remain open awaiting a new transport connection?
c. When a network connection is aborted, how should the peer
transport entities that were using the connection cooperate to
re-establish it? If splitting is not to be used, how can this
re-establishment be achieved such that one and only one
network connection results?
The Class 4 transport specification permits a transport entity to
multiplex several transport connections (TCs) over a single network
McCoy [Page 45]
RFC 1008 June 1987
connection (NC) and to split a single TC across several NCs. The
implementor must decide whether to support these options and, if so,
how. Even when the implementor decides never to initiate splitting
or multiplexing the transport entity must be prepared to accept this
behavior from other transport implementations. When multiplexing is
used TPDUs from multiple TCs can be concatenated into a single
network service data unit (NSDU). Therefore, damage to an NSDU may
effect several TCs. In general, Class 2 connections should not be
multiplexed with Class 4 connections. The reason for this is that if
the error rate on the network connection is high enough that the
error recovery capability of Class 4 is needed, then it is too high
for Class 2 operation. The deciding criterion is the tolerance of
the user for frequent disconnection and data errors.
Several issues in splitting must be considered:
1) maximum number of NCs that can be assigned to a given TC;
2) minimum number of NCs required by a TC to maintain the "quality
of service" expected (default of 1);
3) when to split;
4) inactivity control;
5) assignment of received TPDU to TC; and
6) notification to TC of NC status (assigned, dissociated, etc ).
All of these except 3) are covered in the formal description. The
methods used in the formal description need not be used explicitly,
but they suggest approaches to implementation.
To support the possibility of multiplexing and splitting the
implementor must provide a common function below the TC state
machines that maps a set of TCs to a set of NCs. The formal
description provides a general means of doing this, requiring mainly
implementation environment details to complete the mechanism.
Decisions about when network connections are to be opened or closed
can be made locally using local decision criteria. Factors that may
effect the decision include costs of establishing an NC, costs of
maintaining an open NC with little traffic flowing, and estimates of
the probability of data flow between the source node and known
destinations. Management of this type is feasible when a priori
knowledge exists but is very difficult when a need exists to adapt to
dynamic traffic patterns and/or fluctuating network charging
mechanisms.
To handle the issue of re-establishment of the NC after failure, the
ISO has proposed an addendum N3279 [ISO85c] to the basic transport
standard describing a network connection management subprotocol
McCoy [Page 46]
RFC 1008 June 1987
(NCMS) to be used in conjunction with the transport protocol.
7 Enhanced checksum algorithm.
7.1 Effect of checksum on transport performance.
Performance experiments with Class 4 transport at the NBS have
revealed that straightforward implementation of the Fletcher checksum
using the algorithm recommended in the ISO transport standard leads
to severe reduction of transport throughput. Early modeling
indicated throughput drops of as much as 66% when using the checksum.
Work by Anastase Nakassis [NAK85] of the NBS led to several improved
implementations. The performance degradation due to checksum is now
in the range of 40-55%, when using the improved implementations.
It is possible that transport may be used over a network that does
not provide error detection. In such a case the transport checksum
is necessary to ensure data integrity. In many instances, the
underlying subnetwork provides some error checking mechanism. The
HDLC frame check sequence as used by X.25, IEEE 802.3 and 802.4 rely
on a 32 bit cyclic redundancy check and satellite link hardware
frequently provides the HDLC frame check sequence. However, these
are all link or physical layer error detection mechanisms which
operate only point-to-point and not end-to-end as the transport
checksum does. Some links provide error recovery while other links
simply discard damaged messages. If adequate error recovery is
provided, then the transport checksum is extra overhead, since
transport will detect when the link mechanism has discarded a message
and will retransmit the message. Even when the IP fragments the
TPDU, the receiving IP will discover a hole in the reassembly buffer
and discard the partially assembled datagram (i.e., TPDU). Transport
will detect this missing TPDU and recover by means of the
retransmission mechanism.
7.2 Enhanced algorithm.
The Fletcher checksum algorithm given in an annex to IS 8073 is not
part of the standard, and is included in the annex as a suggestion to
implementors. This was done so that as improvements or new
algorithms came along, they could be incorporated without the
necessity to change the standard.
Nakassis has provided three ways of coding the algorithm, shown
below, to provide implementors with insight rather than universally
transportable code. One version uses a high order language (C). A
second version uses C and VAX assembler, while a third uses only VAX
assembler. In all the versions, the constant MODX appears. This
represents the maximum number of sums that can be taken without
experiencing overflow. This constant depends on the processor's word
size and the arithmetic mode, as follows:
McCoy [Page 47]
RFC 1008 June 1987
Choose n such that
(n+1)*(254 + 255*n/2) <= 2**N - 1
where N is the number of usable bits for signed (unsigned)
arithmetic. Nakassis shows [NAK85] that it is sufficient
to take
n <= sqrt( 2*(2**N - 1)/255 )
and that n = sqrt( 2*(2**N - 1)/255 ) - 2 generally yields
usable values. The constant MODX then is taken to be n.
Some typical values for MODX are given in the following table.
BITS/WORD MODX ARITHMETIC
15 14 signed
16 21 unsigned
31 4102 signed
32 5802 unsigned
This constant is used to reduce the number of times mod 255 addition
is invoked, by way of speeding up the algorithm.
It should be noted that it is also possible to implement the checksum
in separate hardware. However, because of the placement of the
checksum within the TPDU header rather than at the end of the TPDU,
implementing this with registers and an adder will require
significant associated logic to access and process each octet of the
TPDU and to move the checksum octets in to the proper positions in the
TPDU. An alternative to designing this supporting logic is to use a
fast, microcoded 8-bit CPU to handle this access and the computation.
Although there is some speed penalty over separate logic, savings
may be realized through a reduced chip count and development time.
7.2.1 C language algorithm.
#define MODX 4102
encodecc( mess,len,k )
unsigned char mess[] ; /* the TPDU to be checksummed */
int len,
k; /* position of first checksum octet
as an offset from mess[0] */
McCoy [Page 48]
RFC 1008 June 1987
{ int ip,
iq,
ir,
c0,
c1;
unsigned char *p,*p1,*p2,*p3 ;
p = mess ; p3 = mess + len ;
if ( k > 0) { mess[k-1] = 0x00 ; mess[k] = 0x00 ; }
/* insert zeros for checksum octets */
c0 = 0 ; c1 = 0 ; p1 = mess ;
while (p1 < p3) /* outer sum accumulation loop */
{
p2 = p1 + MODX ; if (p2 > p3) p2 = p3 ;
for (p = p1 ; p < p2 ; p++) /* inner sum accumulation loop */
{ c0 = c0 + (*p) ; c1 = c1 + c0 ;
}
c0 = c0%255 ; c1 = c1%255 ; p1 = p2 ;
/* adjust accumulated sums to mod 255 */
}
ip = (c1 << 8) + c0 ; /* concatenate c1 and c0 */
if (k > 0)
{ /* compute and insert checksum octets */
iq = ((len-k)*c0 - c1)%255 ; if (iq <= 0) iq = iq + 255 ;
mess[k-1] = iq ;
ir = (510 - c0 - iq) ;
if (ir > 255) ir = ir - 255 ; mess[k] = ir ;
}
return(ip) ;
}
7.2.2 C/assembler algorithm.
#include