Implementation guide for the ISO Transport Protocol
RFC 1008
|
Document |
Type |
|
RFC - Unknown
(June 1987; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1008 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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).
Show full document text