RFC 0892
ISO Transport Protocol specification
In class 4, the transport entity associates a response time
with TPDUs sent requiring a response. If an appropriate response is
not received within time T1, the recovery procedure must be invoked
by the sender. This will usually involve the retransmission of the
corresponding TPDU.
A TPDU may be transmitted a maximum number of times,
This number is referred to a N. The value of N is chosen so that
the required quality of service can be provided given the known
characteristics of the network connection.
7.4.3.10 Relationship of Times and Intervals
The following note describes the relationship between
the time described in Section 7.4.3.1 - 7.4.3.9.
Note:
a. The interrelationship of times for the worst case
is as follows:
M: maximum transit delay of the network (see
7.4.3.1)
Ar maximum acknowledgement time of the remote
transport entity (see 7.4.3.3)
R: maximum local retransmission time (see
7.4.3.5)
N: maximum number of transmission for a single
TPDU (see 7.4.3.9)
L: maximum time for a TPDU to be valid (see
7.4.3.6)
R = T * (N-1)
1
R
*
M
L *
A =2*M + A + R
R R
*
M
t t
b. The interrelationship of times for the average
case is as follows (see 7.4.3.4)
E: average transit delay for the network
(E<<M)
X: TPDU processing time
T : average time from sending a TPDU until
1 the receipt of its acknowledgement (see
7.4.3.4)
A : maximum acknowledgement time of the
R remote transport entity (see 7.4.3.3)
X
E
A T = 2*E + X + A
R 1 R
E
t t
7.4.3.11 Sequence Numbering
In Class 4 sequence numbering is applied to certain
control TPDUs and their acknowledgements, as well as to DT TPDUs.
These are ED and its acknowledgement EA.
The length of sequence numbers may be negotiated at
connection establishment. Where other than the default length is
used, an extended header format is used for sequenced TPDUs
containing additional octets of sequence numbers. Extended header
format includes a credit field on the appropriate TPDU types
allowing extended credit allocation.
7.4.4 Procedures for Connection Establishment Phase
The following features pertain to connection
establishment for Class 4:
o In Class 4, a connection is not considered
established until the successful completion
of a 3-way TPDU exchange. The sender of a
CR TPDU must respond to the corresponding CC
TPDU by immediately sending a DT, ED or AK TPDU.
o As a result of duplication, a CR TPDU may be
received specifying a source reference which
is already in use with the sending transport
entity. If the receiving transport entity
is in the data transfer phase, having
completed the 3-way TPDU exchange procedure,
the receiving transport entity should ignore
such a TPDU. Otherwise a CC TPDU should be
transmitted.
o As a result of duplication or
retransmission, a CC TPDU may be received
specifying a paired reference which is
already in use. The receiving transport
entity should ignore such a CC TPDU.
o A CC TPDU may be received specifying a
reference which is in the frozen state. The
response to such a TPDU should be a DR TPDU.
7.4.4.1 Connection Request
When a transport entity transmits a CR TPDU it starts
timer T1. If this timer expires before a CC TPDU is received, the
CR TPDU is retransmitted and the timer restarted. After
transmission of the CR TPDU N times, the connection establishment
procedure is abandoned and the failure reported to the transport
user. The reference must be placed in the frozen state for a period
L (see section 7.4.3.6).
7.4.4.2 Incomimg Connection Request
An incoming connection request is processed as for Class 3
7.4.4.3 Connection Confirm
When a transport entity transmits a CC TPDU it starts
timer T1. If this timer expires before an AK or DT TPDU is
received, the CC TPDU is retransmitted according to the
retransmission principles in Section 7.4.3.9
7.4.4.4 Incoming Connection Confirm
When a CC TPDU is received, the receiving transport entity
enters the data transfer phase. It must immediately transmit an
AK, ED or DT TPDU to complete the 3-way TPDU exchange. The
CC TPDU is subject to the usual rules of the data transfer phase
regarding retransmission, see Section 7.4.5.3.
7.4.4.5 Incoming Acknowledgement
When an AK, DT or ED TPDU is received the receiving
transport entity can enter the data transfer phase. If the entity
has data to send it may send DT TPDUs or an ED TPDU. The DT TPDUs
are subject to flow control. Otherwise, the transport entity must
obey the inactivity principles (see Section 7.4.5.8).
7.4.4.6 Unsuccessful Connection
When a DR TPDU is received in response to a CR TPDU,
the timer T1 is cancelled and the reference placed in the frozen
state for a period L (see Section 7.4.6.1).
7.4.4.7 Initial Credit Allocation
The CR and CC TPDUs may allocate an initial credit value
to their respective recipients. This value is limited to 15 by the
encoding of the TPDU. Where the extended header format is in use,
credit values greater than 15 must be allocated using AK TPDUs.
7.4.4.8 Exchange of Acknowledge Time
A transport entity may transmit the value it intends
to use for AL at connection establishment, as the 'Acknowledge
Time' parameter in the CR or CC TPDU (depending on whether the
transport entity is initiating or accepting the transport
connection). If this parameter is present in a received CR or CC
TPDU, the value of AR should be set accordingly. If this
parameter is not present, AR may be assumed to be insignificant in
comparison to E the typical maximum transit delay.
7.4.5 Procedure for Data Transfer Phase
7.4.5.1 Sequence Control
The receiving transport entity is responsible for
maintaining the proper sequence of DT TPDUs.
DT TPDUs received out of sequence must not be
delivered to the TS-user until in-sequence TPDUs have also been
received.
AK TPDUs also contain information allowing the
receiving transport entity to process them in the correct order.
7.4.5.2 Duplicate DT TPDUs
Duplicate TPDUs can be detected because the T(S) value
matches that of previously received TPDUs. T(S) values must not be
reused for the period L after their previous use. Otherwise, a
new, valid TPDU could be confused with a duplicated TPDU which had
previously been received and acknowledged.
Duplicated DT TPDUs must be acknowledged, since the
duplicated TPDU may be the result of a retransmission resulting from
the loss of an AK TPDU.
The data contained in a duplicated DT TPDU should be
ignored.
7.4.5.3 Retransmission Principles
When a transport entity has some outstanding DT or ED
TPDUs that require acknowledgement, it will check that no T1
interval elapses without the arrival of an AK or EA TPDU that
acknowledges one of them. If the timer expires, the first TPDU is
retransmitted and the timer is restarted. After N transmissions
(N-1 retransmissions) the connection is assumed to have failed and
the release phase is entered, and the transport user is informed.
DT TPDUs which fall beyond the current window (due to
reduction of the upper window edge) are not retransmitted until
advancement of the upper window edge so permits.
Note: This requirement can be met by different
means, for example.
1. One timer is associated with each TPDU. If the
timer expires, the associated TPDU will be
retransmitted, and the timer T1 will be
restarted for all subsequent DT TPDUs.
2. One timer is associated with each TC:
if the transport entity transmits a DT TPDU
requiring acknowledgement, it starts timer
T1,
if the transport entity receives a TPDU that
acknowledges one of the TPDUs to be
acknowledged, timer T1 is restarted,
if the transport entity receives a TPDU that
acknowledges the last TPDU to be
acknowledged, timer T1 is stopped.
For the decision whether the retransmission timer T1
is maintained on a per TPDU or on a per TC basis, throughput
considerations have to be taken into account.
7.4.5.4 Acknowledgement Principles
A transport entity operating class 4 must acknowledge
all TPDUs received requiring acknowledgment. To avoid unnecessary
retransmissions and to avoid delays to transmission by the remote
transport entity, the delay for acknowledgement should not exceed
timer A (see Section 7.4.3.2).
L
There are two TPDU types that must be acknowledged:
ED and DT. Receipt of an ED TPDU must be acknowledged by an EA
TPDU. A DT TPDU is acknowledged with an AK TPDU.
An AK TPDU has the sequence number of the next DT
TPDU the receiving transport entity expects to receive. It thus
acknowledges receipt of all DT TPDUs with sequence numbers less than
the acknowledgement number.
An AK TPDU may be repeated at any time, using the
sequence number in the last AK TPDU sent.
7.4.5.5 Flow Control Principles
Flow control in Class 4 is subject to the same
principles as in Classes 2 and 3. The credit mechanism and window
principle of those classes still apply, except that in class 4, the
upper window edge can be reduced by the receiving transport entity
by sending an AK TPDU with a smaller credit.
A receiving transport entity may send an AK TPDU at
any time to change the window size. This AK TPDU may acknowledge a
new DT TPDU or may repeat a previous acknowledgement.
7.4.5.6 Window Synchronization Principles
To ensure the synchronization of flow control
information the window timer provokes the frequent exchange of AK
TPDUs between transport entities. The window timer maintains a
minimum level of TPDU traffic between transport entities cooperating
in a transport connection.
In Class 4 the window size can be reduced in any AK
TPDU. Due to the possibility of misordering of AK TPDUs and the
associated loss of efficiency, the AK TPDU for class 4
includes an additional field called the AK TPDU subsequence
parameter.
An AK TPDU should contain the subsequence parameter
whenever a duplicate AK TPDU is sent with the same sequence number
but with reduced credit. The value of the subsequence parameter is
set to one for the first time the AK TPDU is resent with reduced
credit.
When an AK TPDU is transmitted whose sequence
number is increased, the 'sub-sequence' parameter is omitted
until credit reduction takes place.
When an AK TPDU is received, it must be processed
(i.e., its contents made use of) only if:
o The sequence number is greater than in any
previously received AK TPDU, or,
o The sequence number is equal to the highest
in any previously received AK TPDU, and the
sub-sequence parameter is greater than in
any previously received AK TPDU having the
same sequence number (where an
absent sub-sequence parameter is regarded
as having a value of zero), or
o The sequence number and sub-sequence
parameter are both equal to the highest in
any previously received AK TPDU (where an
absent sub-sequence parameter is regarded as
having a value of zero), and the credit
field is greater than in any previously
received AK TPDU having the same sequence
and sub-sequence numbers.
When an AK TPDU is transmitted which opens a closed
window (i.e. increases credit from zero), it should be retransmitted
at an interval of T1. Transmission should occur a maximum of N
times, after which the usual inactivity retransmission timer should
be reverted to. Retransmission may also cease if the local
transport entity becomes sure that the new credit information has
been received by the remote transport entity.
If a transport entity receives an AK TPDU containing
a 'Flow Control Confirmation' parameter, whose Lower Window Edge and
Your-Sub-Sequence fields are equal to its own lower window edge and
sub-sequence number, it may note that the credit available at the
remote transport entity (relative the Lower Window Edge field) is at
least equal to the value conveyed as Your Credit. This enables the
transport entity to cease the frequent retransmission of window
information, if it thereby knows that the remote window is open.
A transport entity need not retransmit window
information (except as described under Inactivity Principles) if it
is aware by the receipt of DT TPDUs that the remote transport entity
has sufficient credit to prevent deadlock. When an AK TPDU is
transmitted in response to a DT TPDU, the transport entity may
normally assume that the transmitter of the DT TPDU will ensure that
the AK TPDU is received, be retransmission of the DT TPDU if
necessary. Therefore, it can normally be assumed that the credit
conveyed in such an AK TPDU will be available to the remote
transport entity, and frequent retransmission is unnecessary.
The assumption that the DT TPDU will be retransmitted
may be incorrect if credit reduction has taken place. Therefore, a
transport entity may not make this assumption if the
sequence number of the DT TPDU is less than or equal to the highest
value for which permission to transmit (i.e., credit) has been given
and subsequently withdrawn.
Upon receipt of an AK TPDU which increases the upper
window edge, a transport entity may transmit an AK TPDU which
repeats the information contained in the received TPDU in a 'Flow
Control Confirmation' parameter in its variable part an thereby
assures the transmitter of the original AK TPDU of its own state.
Such an AK TPDU may be tranmmitted:
o Upon receipt of a duplicated AK TPDU
(i.e., one which is identical in all fields,
including the sub-sequence parameter if
present, to the most recently received AK
TPDU which was not discarded due to
detection of a sequence error), not
containing the 'Flow Control Confirmation'
parameter.
o Upon receipt of an AK TPDU which increases
the upper window edge but does not increase
the lower window edge, when the upper window
edge was formerly equal to the lower window
edge.
7.4.5.7 Procedure for Expedited Data
The procedure for expedited data is as for Class 3,
with the following exceptions.
The ED TPDU has a sequence number which is allocated
from a separate sequence space from that of the DT TPDUs. The EA
TPDU carries the same sequence number as the corresponding ED TPDU.
Only a single ED TPDU may be transmitted and awaiting
acknowledgements at any time.
Upon receipt of an unduplicated ED TPDU, a transport
entity immediately forwards the data to the transport user. The ED
TPDU sequence number is recorded in an EA TPDU sent to the other
transport entity.
The sender of an ED TPDU shall not send any new DT
TPDU with higher T(S) until it receives the EA TPDU. This
guarantees the arrival of the ED TPDU before any subsequently sent
DT TPDUs.
7.4.5.8 Inactivity Principles
If the Inactivity Time I passes without receipt of
some TPDU, the transport entity will terminate the TC by making use
of the release procedure. To present expiration of the remote
transport entity's inactivity times when no data is being sent, the
local transport entity must send AK TPDUs at suitable intervals in
the absence of data, having regard to the probability of TPDU loss.
The Window Synchronization Principles (see 7.4.5.6) may ensure that
this requirement is met.
Note: It is likely that the release procedure
initiated due to inactivity timer expiration will fail, as such
expiration indicates probable failure of the supporting NC or of the
remote transport entity. This case is described in Section 7.4.6.
7.4.6 Procedures for Release Phase
The rules for class 3 apply. The DR TPDU is subject
to the usual retransmission procedure. After N retransmissions, the
transport connection is considered disconnected, the Reference is
placed in the frozen state for a period L and retransmission ceases.
The DC TPDU is sent only in response to a DR TPDU, and
is not subject to the retransmission procedure.
The DC TPDU when received allows the transport entity
to release all resources maintained for the transport connection.
The DR TPDU does not carry a sequence number. Any
previously transmitted TPDUs (including DT and ED) which are
received after the DR TPDU result in a further DR TPDU but are
otherwise ignored. After disconnection, for whatever reason, the
Reference is placed in the frozen state for a period L.
7.4.6.1 Unassigned Frozen References
When a transport connection is terminated, the
corresponding references cannot be immediately reused since TPDUs
containing these references may continue to exist in the network for
a time up to L. Therefore, these references will be placed in an
unassignable, frozen state for this peiod.
After an event involving loss of transport entity
state information, including the status of reference assignments,
all references relating to network connections whose transport
state information has been lost must be placed in the frozen state
for a period L.
If a DC TPDU is received for a local reference which
is in the frozen state, or with a remore reference not matching the
already recorded one, this DC TPDU shall be ignored.
7.4.7 Treatment of Invalid TPDUs
The 'Treatment of Protocol Erorrs' function is used.
7.4.8 Supported Options
Non use of checksum.
Use of extended formats.
8. ENCODING
8.1 Summary
Classes
0 1 2 3 4 Sect. Code
CR Connection Request x x x x x 8.3 1110xxxx
CC Connection Confirm x x x x x 8.4 1101xxxx
DR Disconnect Request x x x x x 8.5 10000000
DC Disconnect Confirm x x x x 8.6 11000000
DT Data x x x x x 8.7 11110000
ED Expedited Data x NF x x 8.8 00010000
AK Data Acknowledgement NRC NF x x 8.9 0110xxxx
(Note 1)
EA Expedited Data x NF x x 8.10 00100000
Acknowledgement
RJ Reject (Note 1) x x 8.11 0101xxxx
ERR TPDU Error x x x x x 8.12 01110000
not available (Note 2) - 00000000
not available (Note 2) - 00110000
not available (Note 2) - 1001xxxx
not available (Note 2) - 1010xxxx
Where xxxx (bits 4-1) is used to signal the CDT
Note 1: In extended header format, the code for AK=0110 0000 and the
code for RJ=0101 0000.
Note 2: These codes are already in use in compatible protocols
defines by standards organizations other than CCITT/ISO.
NF: Not available when the non explicit flow control option is
selected.
NRC: Not available when the receipt confirmation option is
selected.
8.2 Structure
As defined in the previous sections, all the Transport
Protocol Data Units (TPDU) shall contain an integral number of
octets. The octets in a TPDU are numbered starting from 1 and
increasing in the order of transmission. The bits in an octet are
numbered from 1 to 8, where bit 1 is the low-ordered bit.
There are tao types of TPDUs:
o Data TPDUs, used to transfer Transport Service
Data Units (TSDUs). The structure of the TSDUs is
maintained by means of the TSDU End Mark.
o Control TPDUs, used to control the transport
protocol functions, including the optional
functions.
Octets 1 2 3 4 n n+1 p p+1
------------ -------------- -------------- --------
LI| | | | ... | | | .... | | | .... |
------------ -------------- -------------- --------
<--- Fixed Part -----><-- Variable Part->
(including checksum
where applicable)
<--------------Header-------------------><----Data Field->
A TPDU is divided into four parts:
o Length Indicator Field (LI)
o Fixed Part
o Variable Part (may be omitted)
o Data Field (may be omitted)
The length Indicator Field, Fixed Part and Variable Part constitute
the Header of the TPDU.
8.2.1 Length Indicator Field
This field is contained in the first octet of the
TPDUs. The length is indicated by a binary number, with a maximum
value of 254 (11111110). The length indicated is the header length,
including parameters, but excluding the length indicator field and
user data, if any. The value 255 (11111111) is reserved for
possible extensions.
8.2.2 Fixed Part
The fixed part contains frequently occurring functions
including the code of the TPDU. The length and the structure of the
fixed part are defined by the TPDU code, defined by bits 5 to 8 of
the second octet of the header.
8.2.2.1 TPDU Code
This field contains the TPDU code and is contained in
Octet 2 of the header. It is used to define the structure of the
remaining header. This field is a full octet except in the
following cases:
1110 xxxx Connecting Request
1101 xxxx Connection Confirm
0101 xxxx Reject
0110 xxxx Data Acknowledgement
Where xxxx (bits 4-1) is used to signal the CDT.
Any other bit pattern may be used to define a TPDU Code.
Only those codes defined in Section 8.1 are currently valid.
8.2.3 Variable Part
The variable part is used to define parameters
relating to optional functions. If the variable part is present, it
shall contain one or more parameters. The number of parameters that
may be contained in the varialbe part is indicated by the length of
the variable part which is a LI minus the length of the fixed part.
Since the currently defined minimum fixed part for
headers which allow parameters is four octets, and since the length
indication field is limited to a maximum of 254, the maximum length
of the variable part is 250 octets.
Each parameter contained within the variable part is
coded as follows:
Bits 8 7 6 5 4 3 2 1
Octets
n+1 Parameter Code
n+2 Parameter Length
Indication (e.g."m")
n+3 Parameter Value
n+2+m
o The parameter code field is coded in binary and,
without extensions, provides a maximum number of
255 different parameters. However, as noted below,
bits 8 and 7 indicates the source of definition,
so the practical maximum number of different
parameters is less. Parameter code 1111 1111 is
reserved for possible extensions of the parameter code.
o The parameter length indication indicates the length,
in octets, of the parameter value field. The length
is indicated by a binary number, "m" with a theoretical
maximum value of 255. The practical maximum value of
"m" is lower. For example, in the case of a single parameter
contained within the variable part, two octets
are required for the Parameter Code and the Parameter Length
Indication itself. Thus, the value of "m" is limited
to 248. For larger fixed parts of the header and for
each succeedimg parameter, the maximum value of "m" decreases.
o The parameter value field contains the value of the
parameter identified in the parameter code field.
o No standard parameter codes use bits 8 and 7 with the
value 00.
o Implementations shall accept the parameters defined in
the variable part in any order. If any parameter is
duplicated then the later value will be used.
8.2.3.1 Checksum Parameter (Class 4 only)
All TPDU types may contain a checksum parameter in
their variable part. This parameter must always be present except
when the non use of checksum option is selected.
Parameter Code: 1100 0011
Parameter Length: 2
Parameter Value: Result of checksum algorithm.
This algorithm is specified in
Section 6.18.
8.2.4 Data Field This field contains transparent user data.
Restrictions on its size are noted for each command.
8.3 Connections Request (CR)
8.3.1 Structure
1 2 3 4 5 6 7 8 p p+1
LI CR CDT 00000000 00000000 SOURCE- class VARIABLE USER DATA
REFERENCE options PART
8.3.2 LI
See Section 8.2.1
8.3.3 Fixed Part (Octets 2 to 7)
CR: Connection Request Code: 1110
CDT: Initial Credit Allocation (set to 0000 in
Classes 0 and 1 when specified as preferred class).
SOURCE REFERENCE: Reference selected by the transport
entity initiating the CR TPDU to
identify the requested TC.
CLASSES: Bits 8-5 octer 7 defines the preferred Transport
Protocol class to be operated over the requested
TC. This field may take on one of the following
values.
0000 Class 0
0001 Class 1
0010 Class 2
0011 Class 3
0100 Class 4
The CR contains the first choice of class in the fixed
part as above. Second and subsequent choices are listed in the
variable part if required.
Bits 4-1 of octet 7 are reserved for options to be
used on the requested transport connection.
The use of bits 4-1 is as follows:
BIT OPTION
4 0 always
3 0 always
2 =0 use of normal formats
=1 use of extended formats
1 =0 use of explicit flow control
in Class 2
=1 no use of explicit flow
control in Class 2
Note:
1. It is not valid to request 'use of expedited data
transfer' (Additional option parameter) and no use of
explicit flow control in Class 2' (bit 1 = 1).
2. Bits 4 to 1 are always zero in Class 0 and have
no meaning.
8.3.4 Variable Part (Octets 8 to p)
The following parameters are permitted in the variable part:
o Transport Service Access Point Identifier (TSAP-ID)
Parameter code 11000001 for the identifier of the Calling TSAP.
11000010 for the identifier of the Called TSAP.
If a TSPA-ID is given in the request it may be
returned in the confirmation.
o TPDU size
This parameter defines the proposed maximum TPDU size
(in octets including the header) to be used over the requested
transport connection. The coding of this parameter is:
Parameter Code 11000000
Parameter value field
00001101 8192 octets (not allowed in Class 0 of 1)
00001100 4096 octets (not allowed in Class 0 of 1)
00001011 2048 octets
00001010 1024 octets
00001001 512 octets
00001000 256 octets
00000111 128 octets
Default value is 00000111 (128 octets)
Version Number (not used in Class 0)
Parameter code 11000100
Parameter value field 00000001
Default value 00000001
Default value 00000001 (not used in Class 0)
o Security Parameter (not used in Class 0)
This parameter is user defined.
Parameter code 11000101
Parameter value and length field are user defined
o Checksum (not used in Classes 0 through 3)
See Section 8.2.3.1
This parameter must always be present in a CR TPDU
requesting Class 4, even if the checksum selection
parameter is used to request non-use of the checksum facility.
o Additional Option Selection (not used in Class 0)
This parameter defines the selection to be made as to
whether or not additional options are to be used.
Parameter code 11000110
Parameter length: 1
Parameter value field:
Bits related to options particular to one class are
not meaningful and may take any value in the other classes.
BITS OPTION
4 1= Use of network expedited in Class 1
0= Non use of network expedited in Class 1
3 1= Use of receipt confirmation in Class 1
0= Use of explicit AK variant in Class 1
2 0= Checksums are to be used in Class 4
1= Checksums are not to be used in Class 4
1 1= Use of transport expedited data transfer
service
0= No use of transport expedited data transfer
service
Default falue is 00000001
o Alternative protocol class (not used in Class 0)
Parameter code 11000111
Parameter length n
Parameter value encoded as a sequence of single
octets. Each octet is encoded as for octet 7 but with bits 4-1 set
to zero (i.e., no alternative option selections permitted).
o Acknowledge Time
This parameter conveys the maximum acknowledge time
AL to the remote transport entity. It is an indication only, and
is not subject to negotiation (see section 7.4.5.3).
Parameter Code 10000101
Parameter Value field: n a binary number (2 octets)
n is the maximum acknowledge time, expressed in
milliseconds.
o Throughput Parameter code: 10001001
Length : 12
1st 3 octets : Targer value,
calling-called user
direction
2nd 3 octets : Min. acceptable,
calling-called
user direction
3rd 3 octets : Target value,
called-calling user
direction
4th 3 octets : Min. acceptable,
called-calling user
direction
Values are expressed in octets per second.
o Residual Parameter code: 10000110
error rate
Length : 3
1st octet : Target value, power
of 10
2nd octet : Min. acceptable,
power of 10
3rd octet : TSDU size of
interest, expressed
as a power of 2
o Priority Parameter code: 10000111
Length : 2
Value : Integer
o Transit Parameter code: 10001000
delay
Length : 8
1st 2 octets : Target value,
calling-called user
direction
2nd 2 octets : Max. acceptable,
calling-called user
direction.
3rd 2 octets : Target value,
called-calling user
direction.
4th 2 octets : Max. acceptable,
called-calling user
direction
Values are expressed in milliseconds.
8.3.5 User Data (Octets p+1 to the end)
No user data are permitted in class 0, and are
optional in the other classes. Where permitted, it may not exceed
32 octets.
8.4 Connection Confirm (CC)
8.4.1 Structure
1 2 3 4 5 6 7 8 p p+1
LI CC CDT DST-REF SOURCE-REF class VARIABLE USER DATA
1101 options Part
8.4.2 LT
See Section 8.2.1.
8.4.3 Fixed Part (Octets 2 to 7)
CC : Connection Confirm
Code: 1101
CDT : Initial Credit
Allocation (set to
0000 in Classes 0
and 1).
DST-REFERENCE : Reference
identifying the
requested transport
connection at the
remote transport
entity.
SOURCE REFERENCE : Reference selected
by the transport
entity initiating
the CC TPDU to
identify the
confirmed TC.
CLASSES : Defines the selected
transport protocol class to
be operated over the accepted
TC according to the
negotiation rules specified
in Section 6.5.
8.4.4 Variable part (Octet 8 to p)
See Section 8.3.4
8.4.5 User Data (Octets p+1 to the end)
See Section 8.3.5
8.5 Disconnect Request (DR)
8.5.1 Structure
LI DR DST-REF SOURCE-REF REASON VARIABLE USER DATA
10000000 PART
8.5.2 LI
See Section 8.2.1
8.5.3 Fixed Part (Octets 2 to 7)
DR : Disconnect Request Code: 1000
DST-REFERENCE : Reference identifying the TC at
the remote transport entity.
SOURCE REFERENCE : Reference identifying the TC at
the transport entity initiating
the command. Value zero when
reference is unassigned.
REASON : Defines the reason for
disconnecting the TC. This field
shall take one of the following
values:
The following values can be used
for class 1 to 4:
128 + 0 - Normal disconnect
initiated by session entity.
128 + 1 - Remote transport entity
congestion at connect request time
*128 + 2 - Connection negotiation failed
(i.e. proposed class(es) not supported).
128 + 3 - Duplicated connection detected
128 + 4 - Mismatched references
128 + 5 - Protocol error
128 + 6 - Not used
128 + 7 - Reference overflow
128 + 8 - Connection request refused on this
network connection
128 + 9 - Not used
128 + 10 - Header or parameter length invalid
The following values can be used for all classes.
0 - Reason not specified
1 - Congested at TSAP
*2 Session entity not attached to TSAP
*3 Address unknown
Note: Reasons marked with '*' may be reported to
the TS-user as 'persistent', other reasons
as 'transient'.
8.5.4 Variable Part (Octets 8 to 10)
o A parameter may be provided to allow additional
information related to the clearing of the connection.
Parameter code: 11100000
Parameter Value Field: Additional information. This
field is intended to be used by the transport service
provider for internal purposes.
o Checksum (see 8.2.3.1)
8.5.5 User Data (Octets p+1 to the end)
Not allowed in class 0,
This field may not exceed 64 octers and is used
to carry TS-User data. The successful transfer of this data is not
guaranteed.
8.6 Disconnect Confirm (DC)
(Not used in Class 0)
8.6.1 Structure
1 2 3 4 5 6 7 p
LI DST-REFERENCE SOURCE-REFERENCE Variable Part
11000000
8.6.2 LI
See Section 8.2.1
8.6.3 Fixed Part (Octets 2 to 6)
DC : Disconnect Confirm Code: 1100
DST-REFERENCE : See Section 8.3.3
SOURCE-REFERENCE: See Section 8.4.3
8.6.4 Variable Part
Checksum (see 8.2.3.1)
8.7 Data (DT)
8.7.1 Structure
Normal Format for Class 0 to 1
1 2 3 4 5
LI DT E TPDU-NR User Data
11110000 0
T
Normal format for Class 2, 3 and 4
1 2 3 4 5 6 p p+1
LI DST-REFERENCE E TPDU-NR Variable Part User Data
11110000 O
T
Extended Format for optional use in Classes 2,3 and 4
1 2 3 4 5,6,7,8 9 p p+1
LI DT DST-REFERENCE E TPDU-NR Variable User Data
11110000 O
T
8.7.2 LI
Section 8.2.1
8.7.3 Fixed Part
(Classes 0 to 1 : - Octets 2 to 3; classes 2,3,4
normal format: Octets 2 to 5; classes 2,3,4 extended format: -
Octets 2 to 8)
DT : Data Transfer Code: 1111
DST-REFERENCE : See Section 8.4.3
EOT : When set to ONE, indicates that
the current DT TPDU is the last
Data Unit of a complete DT TPDU
sequence (End of TSDU).
TPDU-NR : TPDU Send Sequence Number (Zero in
Class 0), may take any value in
Class 2 without explicit flow
control.
8.7.4 Variable Part
Checksum (See 8.2.3.1)
8.7.5 User Data Field
This field contains data of the TSDU being transmitted.
The length of this field is limited to the negotiated TPDU size for
this transport connection minus 3 octets in Classes 0 and 1,
and minus 5 octets (normal header format) or
8 octets (extended header format) in the other classes. The
variable part, if presemt, amy further reduce the size of the user
data field.
8.8 Expedited Data (ED)
(Not used in Class 2 when "no explicit flow
control" option is selected.)
8.8.1 Structure
Normal Format
1 2 3 4 EOT 5 6 p p + 1
LI ED DST-REFERENCE EDTPDU-NR Variable Part User Data
00010000 1.
Extended Format
1 2 3 4 EOT 5,6,7,8 9 p p + 1
LI ED DST-REFERENCE EDTPDU-NR Variable Part User Data
00010000 1.
8.8.2 LI
See Section 8.2.1
8.8.3 Fixed Part
(Octets 2 to 5, normal format: 2 to 8, extended format)
ED: Expedited Data command code: 0001
DST-REFERENCE: Same as Section 8.4.3
ED TPDU-NR: Expedited TPDU identification number
(Classes 1, 3, and 4; may take any value in
Class 2).
8.8.4 Variable Part
Checksum (See 8.2.3.1)
8.8.5 User Data Field
This field contains an expedited TSDU. Up to 16 octets.
8.9 Data Acknowledgement (AK)
Not applicable for Class 0 and Class 2 when the "no
explicit flow control" option is selected, and for Class 1 when the
network receipt confirmation option is selected.
Flow Control Confirmation (class 4 only - optionally used)
This parameter contains a copy of the information received
in an AK TPDU, to allow the transmitter of the AK TPDU to be certain
of the state of the receiving transport entity (See Section 7.4.5.6).
Parameter Code: 100001011
Parameter value field 64 bits, used as follows:
o Lower Window Edge (32 bits)
Bit 32 is set to zero, bits 31 to 1 contain the
YR-TU-NR value of the received AK TPDU. When normal
format is in use, only the least significant seven
bits (bits 1 to 7) of this field are significant.
o Your Sub-Sequence (16 bits)
Contains the value of the sub-sequence parameter of
the received AK TPDU, or zero if this parameter was
not present.
o Your Credit (16 bits)
Contains the value of the CDT field of the received AK
TPDU. When normal format is in use, only the least
significant four bits (bits 1 to 4) of this field are
significant.
8.10 Expedited Data Acknowledgement (EA)
(Not applicable for Class 0 and Class 2 when the no
explicit flow control option is selected).
8.10.1 Structure
Normal Format
1 2 3 4 5 6 p
LI EA DST-REFERENCE . YR-TU-NR Variable Part
00100000 0.
Extended Format
1 2 3 4 5,6,7,8 9 p
LI EA DST-REFERENCE . YR-TU-NR Variable Part
00100000 0.
8.9.1 Structure
Normal Format
1 2 3 4 5 6 p
LI AK CDT DST-REFERENCE . YR-TU-NR Variable Part
0110 0.
Extended Format
1 2 3 4 5,6,7,8 9,10 11 p
LI AK DST-REFERENCE . YR-TU-NR CDT Variable Part
01100000 0.
8.9.2 LI
See Section 8.2.1
8.9.3 Fixed Part
(Octets 2 to 5, normal format: 2 to 10, extended format)
AK: Acknowledgement command code: 0110
CDT: Credit Value (set to 0 in class 1)
DST-REFERENCE: Same as Section 8.4.3
YR-TU-NR: Sequence number indicating the next expected
DT TPDU number.
8.9.4 Variable Part
Checksum (See 8.2.3.1)
Sub-sequence number (class 4 only - optionally used).
This parameter is used to ensure that AK TPDUs are
processed in the correct sequence. If it is absent, this is
equivalent to transmitting the parameter with a value of zero.
Parameter Code: 100001010
Parameter Value: 16-bit sub-sequence number.
8.10.2 LI
See Section 8.2.1
8.10.3 Fixed Part
(Octets 2 to 5, normal format; 2 to 8, extended
format)
EA: Acknowledgement command code: 0010
DST-REFERENCE: Same as Section 8.4.3
YR-TU-NR: Identification of the ED TPDU being
acknowledged. May take any value in Class 2.
8.10.4 Variable Part
Checksum (See 8.2.3.1)
8.11 Reject (RJ)
(Not used in Classes 0, 2, and 4)
8.11.1 Structure
Normal Format
1 2 3 4 EOT 5 6 p
LI RJ CDT DST-REFERENCE . YR-TU-NR Variable Part
0101 0.
Extended Format
1 2 3 4 EOT 5,6,7,8 9,10 11 p
LI RJ DST-REFERENCE . YR-TU-NR CDT Variable
0l0l0000 Part
8.11.2 LI
See Section 8.2.1
8.11.3 Fixed Part
(Octets 2 to 5, normal format; 2 to 10, extended format)
RJ: Reject Command Code: 0101
CDT: Credit Value (set to 0 in class 1)
DST-REFERENCE: Same as Section 8.4.3
YR-TU-NR: Sequence number indicating the next expected
TPDU from which retransmission should occur.
8.11.4 Variable Part
No parameters exclusive to this TPDU type.
8.12 TPDU Error (ERR)
1 2 3 4 5 6
LI ERR DST-REFERENCE Reject Parameters
01110000 Cause
8.12.1 LI
See Section 8.2.1
8.12.2 Fixed Part
ERR: TPDU Error Code: 0111
DST-REFERENCE: Same as Section 8.4.3
REJECT CAUSE:
00000000 Reason not specified
00000001 Invalid parameter code
00000010 Invalid TPDU type
00000011 Invalid parameter value
8.12.3 Variable Part (Octets 6 to the end)
Parameter Code: 1100001
Parameter Value Field:
Contains the bit pattern of the rejected TPDU up to and
including the octet which caused the rejection. This parameter is
mandatory in Class 0.
Checksum (See Section 8.2.3.1)
SECTION THREE - CONFORMANCE
9. CONFORMANCE
Implementations claiming conformance to this standard shall:
1. Implement either Class 0 or Class 2 or both.
2. If other classes are implemented, the following rules
shall be observed:
a) If Class 3 or Class 4 is implemented then Class 2
must be implemented
b) If Class 1 is implemented then Class 0 must be
implemented.
3. The following table defines the requirements for the
implementation of the options defined in previous
sections:
Class
0 1 2 3 4
TPDU with Checksum no no no no m
TPDU without Checksum m m m m o
Expedited Data Transfer no m m m m
No Expedited Data Transfer m m m m m
Flow Control in Class 2 no no m no no
No Flow Control in Class 2 no no o no no
7 bits format (normal) m m m m m
31 bits format (extended) no no o o o
Use of Receipt Confirmation in no o no no no
Class 1
No use of Receipt Confirmation in no m no no no
Class 1
Use of Network Expedited in Class no o no no no
1, if T-EXPEDITED DATA necessary
No use of Network Expedited in no m no no no
Class 1, if T-EXPEDITED DATA necessary
o - optional: An implementation may or may not
provide this user-selected option.
m - mandatory: An implementation must provide for this
option
no - An implementation shall not provide
this option.
4. Implementations claiming conformance shall support a
TPDU length of 128 octets. If larger maximum TPDU
sizes can be supported in Classes 1,2,3, or 4, then
all permitted TPDU sizes between the maximum and 128
octets shall be supported.
5. Claims of conformance shall state:
a) which class of protocol is supported.
b) which additional options indicated by the letter
'o' in the above table are supported.