| | | | |
|TPDU with checksum |NA |NA |mandatory |
|TPDU wihout checksum |mandatory |mandatory |optional |
| | | | |
|--------------------------|----------|----------|-----------|
|Expedited data transfer |mandatory |mandatory |mandatory |
|No expedited data transfer|mandatory |mandatory |mandatory |
| | | | |
|--------------------------|----------|----------|-----------|
|Flow control in Class 2 |mandatory |NA |NA |
|No flow control in Class 2|optional |NA |NA |
| | | | |
|--------------------------|----------|----------|-----------|
|Normal formats |mandatory |mandatory |mandatory |
|Extended formats |optional |optional |optional |
| | | | |
|--------------------------|----------|----------|-----------|
|Use of receipt confirma- | | | |
|tion in Class 1 |NA |NA |NA |
|No use of receipt con- | | | |
|firmation in Class 1 |NA |NA |NA |
| | | | |
|--------------------------|----------|----------|-----------|
|Use of network expedited | | | |
|in Class 1 |NA |NA |NA |
|No use of network expedi- | | | |
|ted in Class 1 |NA |NA |NA |
| | | | |
+------------------------------------------------------------+
NA indicates the procedure is not applicable
Table 9. (Second of 2 pages) Provision of options
149
ANNEX A - STATE TABLES
This annex is an integral part of the body of this International
Standard.
This Annex provides a more precise description of the protocol.
In the event of a discrepancy between the description in these
tables and that contained in the text, the text takes precedence.
The state table also define the mapping between service and
protocol events that TS-users can expect.
This annex describes the transport protocol in terms of state
tables. The state tables show the state of a transport
connection, the events that occur in the protocol, the actions
taken and the resultant state.
[The state tables have been omitted from this copy.]
150
ANNEX B - CHECKSUM ALGORITHMS
(This annex is provided for information for implementors and is
not an integral part of the body of the standard.)
B.1 SYMBOLS
The following symbols are used:
C0 variables used in the algorithms
C1
i number (i.e. position) of an octet within the TPDU (see
12.1)
n number (i.e. position) of the first octet of the checksum
parameter
L length of the complete TPDU
X value of the first octet of the checksum parameter
Y value of the second octet of the checksum parameter.
B.2 ARITHMETIC CONVENTIONS
Addition is performed in one of the two following modes:
a) modulo 255 arithmetic;
b) one's complement arithmetic in which if any of the
variables has the value minus zero (i.e. 255) it shall be
regarded as though it was plus zero (i.e. 0).
B.3 ALGORITHM FOR GENERATING CHECKSUM PARAMETERS
151
B.3.1 Set up the complete TPDU with the value of the checksum
parameter field set to zero.
B.3.2 Initialize C0 and C1 to zero.
B.3.3 Process each octet sequentially from i = 1 to L by:
a) adding the value of the octet to C0; then
b) adding the value of C0 to C1.
B.3.4 Calculate X and Y such that
X = -C1 + (L-n).CO
Y = C1 - (L-n+1).C0
B.3.5 Place the values X and Y in octets n and (n + 1)
respectively.
[A Note describing the above algorithm in mathematical notation
has been omitted from this copy.]
B.4 ALGORITHM FOR CHECKING CHECKSUM PARAMETERS
B.4.1 Initialize C0 and C1 to zero.
B.4.2 Process each octet of the TPDU sequentially from i = 1 to
L by:
a) adding the value of the octet to C0; then
b) adding the value of C0 to C1.
152
B.4.3 If, when all the octets have been processed, either or
both of C0 and C1 does not have the value zero, the checksum
formulas in 6.17 have not been satisfied.
NOTE - The nature of the algorithm is such that it is not
necessary to compare explicitly the stored checksum bytes.
153
Explanatory Report
The Transport Layer Services and Protocols have been under study
within TC97/SC16 since 1979. It was agreed by SC16 at its
meeting in Berlin, November 1980, that the Service and Protocol
documents would be progressed concurrently.
At the SC16 meeting in Tokyo, June 1982, authorization was given
(Resolutions 10 and 11, SC16 N 1233) to register both the
Transport Service Definition and the Transport Protocol
Specification as Draft Proposals and to circulate them for a 90-
day ballot.
Following the close of the letter ballot an Editing Group was
convened to integrate editorial comments and make recommendations
regarding proposed technical changes. The revised texts and
proposed recommendations were reviewed by SC16/WG6 at its meeting
in Vienna, March 1983. The revised text of the Transport Service
Definition (SC16 N 1435) was accepted as presented whereas the
revised text of the Transport Protocol (SC16 N 1433) was
subjected to an additional 60-day ballot. Consistent with the
SC16 decision regarding the parallel progression of both DPs, the
Transport Service Definition was held in abeyance pending
acceptance by SC16 of the revised Transport Protocol (Second DP
8073).
A second Editing Group was convened in Paris, July 1983, to
review comments submitted on Second DP 8073. The Minutes and
Report of this meeting are documented in SC16 N1575 and N 1574
respectively. The two negative votes (DIN and NNI) were given
full consideration. The NNI concerns have been fully covered in
the revised text prepared by the Editing Group. The DIN concerns
have been taken into account and incorporated in their large
majority.
Upon the recommendation of the Editing Group, DP 8072 and DP 8073
are forwarded for registration as Draft International Standards
and letter ballot of ISO Member Bodies.