while TPDUs associated with the old use of the reference may
still exist.
6.18.2 Procedure
When a transport entity determines that a particular connection
is released it shall place the reference which it has allocated
to the connection in a frozen state according to the procedures
of the class. While frozen, the reference shall not be re-used.
NOTE - The frozen reference procedure is necessary because
retransmission or misordering can cause TPDUs bearing a reference
to arrive at an entity after it has released the connection for
which it allocated the reference. Retransmission, for example,
can arise when the class includes either resynchronization (see
6.14) or retransmission on time out (see 6.19).
6.18.2.1 Procedure for classes 0 and 2
The frozen reference procedure is never used for these classes.
NOTE - However for consistency with the other classes freezing
the references may be done as a local decision.
68
6.18.2.2 Procedure for classes 1 and 3
The frozen reference procedure is used except in the following
cases (see note 1):
a) when the transport entity receives a DC TPDU in response
to a DR TPDU which it has sent (see note 2);
b) when the transport entity sends a DR or ER TPDU in
response to a CR TPDU which it has received (see note 3);
c) when the transport entity has considered the connection to
be released after the expiration of the TWR timer (see
note 4);
d) when the transport entity receives a DR or ER TPDU in
response to a CR TPDU which it has sent.
The period of time for which the reference remains frozen shall
be greater than the TWR time.
NOTES
1. However, even in these cases, for consistency freezing the
reference may be done as a local decision.
2. When the DC TPDU is received it is certain that the other
transport entity considers the connection released.
3. When the DR or ER TPDU is sent the peer transport entity
has not been informed of any reference assignment and thus
cannot possibly make use of a reference (this includes the
case where a CC TPDU was sent, but was lost).
4. In 6.18.2.c the transport entity has already effectively
frozen the reference for an adequate period.
69
6.18.2.3 Procedure for classes 4
The frozen reference procedure is always used in class 4. The
period for which the reference remains frozen should be greater
than L (see 12.2.1.1.6).
6.19 Retransmission on time-out
6.19.1 Purpose
The procedure is used in Class 4 to cope with unsignalled loss of
TPDUs by the NS-provider.
6.19.2 TPDUs used
The procedure makes use of the following TPDUs:
CR, CC, DR, DT, ED, AK TPDUs.
6.19.3 Procedure
The procedure is specified in the procedures for Class 4 (see
12.2.1.2.j).
6.20 Resequencing
70
6.20.1 Purpose
The resequencing procedure is used in Class 4 to cope with
misordering of TPDUs by the network service provider.
6.20.2 TPDUs and parameters used
The procedure uses the following TPDUs and parameters:
a) DT TPDU;
- TPDU-NR.
b) ED TPDU
- ED TPDU-NR
6.20.3 Procedure
The procedure is specified in the procedures for Class 4 (see
12.2.3.5).
6.21 Inactivity control
6.21.1 Purpose
The inactivity control procedure is used in Class 4 to cope with
unsignalled termination of a network connection.
71
6.21.2 Procedure
The procedure is specified in the procedures for Class 4 (see
12.2.3.3).
6.22 Treatment of protocol errors
6.22.1 Purpose
The procedure for treatment of protocol errors is used in all
classes to deal with invalid TPDUs.
6.22.2 TPDUs and parameters used
The procedure uses the following TPDUs and parameters:
a) ER TPDU;
- reject cause;
- TPDU in error.
b) DR TPDU;
- reason code.
6.22.3 Procedure
A transport entity that receives a TPDU that can be associated to
a transport connection and is invalid or constitutes a protocol
error (see 3.2.16 and 3.2.17) shall take one of the following
actions so as not to jeopardize any other transport connections
not assigned to that network connection:
a) ignoring the TPDU;
b) transmitting an ER TPDU;
72
c) resetting or closing the network connection; or
d) invoking the release procedures appropriate to the class.
If an ER TPDU is sent in Class 0 it shall contain the octets of
the invalid TPDU up to and including the octet where the error
was detected (see notes 3, 4 and 5).
If the TPDU cannot be associated to a particular transport
connection then see 6.9.
NOTES
1. In general, no further action is specified for the
receiver of the ER TPDU but it is recommended that it
initiates the release procedure appropriate to the class.
If the ER TPDU has been received as an answer to a CR TPDU
then the connection is regarded as released (see 6.6).
2. Care should be taken by a transport entity receiving
several invalid TPDUs or ER TPDUs to avoid looping if the
error is generated repeatedly.
3. If the invalid received TPDU is greater than the selected
maximum TPDU size it is possible that it cannot be
included in the invalid TPDU parameter of the ER TPDU.
4. It is recommended that the sender of the ER TPDU starts an
optional timer TS2 to ensure the release of the
connection. If the timer expires, the transport entity
shall initiate the release procedures appropriate to the
class. The timer should be stopped when a DR TPDU or an
N-DISCONNECT indication is received.
5. In classes other than 0, it is recommended that the
invalid TPDU be also included in the ER TPDU.
73
6.23 Splitting and recombining
6.23.1 Purpose
This procedure is used only in class 4 to allow a transport
connection to make use of multiple network connections to provide
additional resilience against network failure, to increase
throughput, or for other reasons.
6.23.2 Procedure
When this procedure is being used, a transport connection may be
assigned (see 6.1) to multiple network connections (see note 1).
TPDUs for the connection may be sent over any such network
connection.
If the use of Class 4 is not accepted by the remote transport
entity following the negotiation rules, then no network
connection except that over which the CR TPDU was sent may have
this transport connection assigned to it.
NOTES
1. The resequencing function of Class 4 (see 6.20) is used to
ensure that TPDUs are processed in the correct sequence.
2. Either transport entity may assign the connection to
further network connections of which it is the owner at
any time during the life of the transport connection.
74
3. In order to enable the detection of unsignalled network
connection failures, a transport entity performing
splitting should ensure that TPDUs are sent at intervals
on each supporting network connection, for example, by
sending successive TPDUs on successive network
connections, where the set of network connections is used
cyclically. By monitoring each network connection, a
transport entity may detect unsignalled network connection
failures, following the inactivity procedures defined in
12.2.3.3. Thus, for each network connection no period I
(see 12.2.3.1) may elapse without the receipt of some TPDU
for some transport connection.
75
7 Protocol Classes
Table 6 gives an overview of which elements of procedure are
included in each class. In certain cases the elements of
procedure within different classes are not identical and, for
this reason, table 6 cannot be considered as part of the
definitive specification of the protocol.
KEY TO TABLE 6
+---|---------------------------------------------------------+
| * |Procedure always included in class |
|---|---------------------------------------------------------|
| |Not applicable |
|---|---------------------------------------------------------|
| m |Negotiable procedure whose implementation in equipment is|
| |mandatory |
|---|---------------------------------------------------------|
| o |Negotiable procedure whose implementation in equipment is|
| |optional |
|---|---------------------------------------------------------|
| ao|Negotiable procedure whose implementation in equipment is|
| |optional and where use depends on availability within the|
| |network service |
|---|---------------------------------------------------------|
|(1)|Not applicable in class 2 when non-use of explicit flow |
| |control is selected |
|---|---------------------------------------------------------|
|(2)|When non use of explicit flow control has been selected, |
| |multiplexing may lead to degradation of quality of |
| |service |
|---|---------------------------------------------------------|
|(3)|This function is provided in class 4 using procedures |
| |other than those in the cross reference. |
+-------------------------------------------------------------+
76
+----------------------------------------------------------------+
| |Cross | | | | | | |
| Protocol Mechanism |refe- | Variant | 0| 1| 2| 3| 4|
| |rence | | | | | | |
|-----------------------------|------|------------|--|--|--|--|--|
| Assignment to network Conn. | 6.1 | | *| *| *| *| *|
|-----------------------------|------|------------|--|--|--|--|--|
| TPDU Transfer | 6.2 | | *| *| *| *| *|
|-----------------------------|------|------------|--|--|--|--|--|
| Segmenting and Reassembling | 6.3 | | *| *| *| *| *|
|-----------------------------|------|------------|--|--|--|--|--|
| Concatenation and Separation| 6.4 | | | *| *| *| *|
|-----------------------------|------|------------|--|--|--|--|--|
| Connection Establishment | 6.5 | | *| *| *| *| *|
|-----------------------------|------|------------|--|--|--|--|--|
| Connection Refusal | 6.6 | | *| *| *| *| *|
|-----------------------------|------|------------|--|--|--|--|--|
| Normal Release | 6.7 | implicit | *| | | | |
| | | explicit | | *| *| *| *|
|-----------------------------|------|------------|--|--|--|--|--|
| Error Release | 6.8 | | *| | *| | |
|-----------------------------|------|------------|--|--|--|--|--|
| Association of TPDUs with | | | | | | | |
| Transport Connection | 6.9 | | *| *| *| *| *|
|-----------------------------|------|------------|--|--|--|--|--|
| DT TPDU Numbering | 6.10 | normal | | *|m(1)m| m|
| | | extended | | |o(1)o| o|
|-----------------------------|------|------------|--|--|--|--|--|
| Expedited Data Transfer | 6.11 | network | | | *| | |
| | | normal | | m|(1) *| *|
| | | network | | | | | |
| | | expedited | |ao| | | |
|-----------------------------|------|------------|--|--|--|--|--|
| Reassignment after failure | 6.12 | | | *| | *|(3)
+----------------------------------------------------------------+
Table 6. (First of 2 pages) Allocation of procedures within classes
77
+----------------------------------------------------------------+
| Retention until Acknowledge-| |Conf.Receipt| |ao| | | |
| ment of TPDUs | 6.13 |AK | | m| | | *|
|-----------------------------|------|------------|--|--|--|--|--|
| Resynchronisation | 6.14 | | | *| | *|(3)
|-----------------------------|------|------------|--|--|--|--|--|
| Multiplexing and | | | | |(2) | |
| Demultiplexing | 6.15 | | | | *| *| *|
|-----------------------------|------|------------|--|--|--|--|--|
| Explicit Flow Control With | 6.16 | | | | m| *| *|
| Without | | | *| *| o| | |
|-----------------------------|------|------------|--|--|--|--|--|
| Checksum (use of) | 6.17 | | | | | | m|
| (non-use of) | | | *| *| *| *| o|
|-----------------------------|------|------------|--|--|--|--|--|
| Frozen References | 6.18 | | | *| | *| *|
|------------------------------------|------------|--|--|--|--|--|
| Retransmission on Timeout | 6.19 | | | | | | *|
|-----------------------------|------|------------|--|--|--|--|--|
| Resequencing | 6.20 | | | | | | *|
|-----------------------------|------|------------|--|--|--|--|--|
| Inactivity Control | 6.21 | | | | | | *|
|-----------------------------|------|------------|--|--|--|--|--|
| Treatment of Protocol Errors| 6.22 | | *| *| *| *| *|
|-----------------------------|------|------------|--|--|--|--|--|
| Splitting and Recombining | 6.23 | | | | | | *|
+----------------------------------------------------------------+
Table 6. (2nd of 2 pages) Allocation of procedures within classes
78
8 SPECIFICATION FOR CLASS 0. SIMPLE CLASS
8.1 Functions of class 0
Class 0 is designed to have minimum functionality. It provides
only the functions needed for connection establishment with
negotiation, data transfer with segmenting and protocol error
reporting.
Class 0 provides transport connections with flow control based on
the network service provided flow control, and disconnection
based on the network service disconnection.
8.2 Procedures for class 0
8.2.1 Procedures applicable at all times
The transport entities shall use the following procedures:
a) TPDU transfer (see 6.2);
b) association of TPDUs with transport connections (see 6.9);
c) treatment of protocol errors (see 6.22);
d) error release (see 6.8).
8.2.2 Connection establishment
The transport entities shall use the following procedures:
a) assignment to network connection (see 6.1); then
b) connection establishment (see 6.5) and, if appropriate,
connection refusal (see 6.6);
subject to the following constraints:
79
c) the CR and CC TPDUs shall contain no parameter field other
than those for TSAP-ID and maximum TPDU size;
d) the CR and CC TPDUs shall not contain a data field.
8.2.3 Data transfer
The transport entities shall use the segmenting and reassembling
procedure (see 6.3).
8.2.4 Release
The transport entities shall use the implicit variant of the
normal release procedure (see 6.7).
NOTE - the lifetime of the transport connection is directly
correlated with the lifetime of the network connection.
80
9 SPECIFICATION FOR CLASS 1: BASIC ERROR RECOVERY CLASS
9.1 Functions of Class 1
Class 1 provides transport connections with flow control based on
the network service provided flow control, error recovery,
expedited data transfer, disconnection, and also the ability to
support consecutive transport connections on a network
connection.
This class provides the functionality of Class 0 plus the ability
to recover after a failure signalled by the Network Service,
without involving the TS-user.
9.2 Procedures for Class 1
9.2.1 Procedures applicable at all times
The transport entities shall use the following procedures:
a) TPDU transfer (see 6.2);
b) association of TPDU with transport connections (see 6.9);
c) treatment of protocol errors (see 6.22);
d) reassignment after failure (see 6.12);
e) resynchronization (see 6.14), or reassignment after
failure (see 6.12) together with resynchronization (see
6.14);
f) concatenation and separation (see 6.4);
g) retention until acknowledgement of TPDU (see 6.13); the
variant used, AK or confirmation of receipt, shall be as
selected during connection establishment (see notes);
h) frozen references (see 6.18).
81
NOTES
1. The negotiation of the variant of retention until
acknowledgement of TPDUs procedure to be used over the
transport connection has been designed such that if the
initiator proposes the use of the AK variant (i.e. the
mandatory implementation option), the responder has to
accept use of this option and if the initiator proposes
use of the confirmation of receipt variant the responder
is entitled to select use of the AK variant.
2. The AK variant makes use of AK TPDUs to release copies of
retained DT TPDUs. The CDT parameter of AK TPDUs in class
1 is not significant, and is set to 1111.
3. The confirmation of receipt variant is restricted to this
class and its use depends on the availability of the
network layer receipt confirmation service, and the
expected cost reduction.
9.2.2 Connection establishment
The transport entities shall use the following procedures:
a) assignment to network connection (see 6.1); then
b) connection establishment (see 6.5) and, if appropriate,
connection refusal (see 6.6).
9.2.3 Data Transfer
9.2.3.1 General
The sending transport entity shall use the following procedures;
a) segmenting (see 6.3); then
82
b) the normal format variant of DT TPDU numbering (see 6.10).
The receiving transport entity shall use the following
procedures;
c) the normal variant of DT TPDU numbering (see 6.10,; then
d) reassembling (see 6.3).
NOTES
1. The use of RJ TPDU during resynchronization (see 6.14) can
lead to retransmission. Thus the receipt of a duplicate
DT TPDU is possible; such a DT TPDU is discarded.
2. It is possible to decide on a local basis to issue an N-
RESET request in order to force the remote entity to carry
out the resynchronization (see 6.14).
9.2.3.2 Expedited Data
The transport entities shall use either the network normal data
or the network expedited variants of the expedited data transfer
procedure (see 6.11) if their use has been selected during
connection establishment (see note 1).
The sending transport entity shall not allocate the same ED-
TPDU-NR to successive ED TPDUs (see notes 2 and 3).
When acknowledging an ED TPDU by sending and EA TPDU the
transport entity shall put into the YR-EDTU-NR parameter of the
EA TPDU the value received in the ED-TPDU-NR parameter of the ED
TPDU.
NOTES
1. The negotiation of the variant of expedited data transfer
procedure to be used over the transport connection has
been designed such that if the initiator proposes the use
of the network normal data variant (i.e. the mandatory
83
implementation option), the responder has to accept use of
this option and if the initiator proposes use of the
network expedited variant, the responder is entitled to
select use of the network normal data variant.
2. This numbering enables the receiving transport entity to
discard repeated ED TPDUs when resynchronization (see
6.14) has taken place.
3. No other significance is attached to the ED TPDU-NR
parameter. It is recommended, but not essential, that the
values used be consecutive modulo 128.
9.2.4 Release
The transport entities shall use the explicit variant of the
release procedure (see 6.7).
84
10 SPECIFICATION FOR CLASS 2 - MULTIPLEXING CLASS
10.1 Functions of class 2
Class 2 provides transport connections with or without individual
flow control; no error detection or error recovery is provided.
If the network connection resets or disconnects, the transport
connection is terminated without the transport release procedure
and the TS-user is informed.
When explicit flow control is used, a credit mechanism is defined
allowing the receiver to inform the sender of the exact amount of
data he is willing to receive and expedited data transfer is
available.
10.2 Procedures for class 2
10.2.1 Procedures applicable at all times
The transport entities shall use the following procedures
a) association of TPDUs with transport connection (see 6.9);
b) TPDU transfer (see 6.2);
c) treatment of protocol errors (see 6.22);
d) concatenation and separation (see 6.4);
e) error release (see 6.8).
Additionally the transport entities may use the following
procedure:
f) multiplexing and demultiplexing (see 6.15).
85
10.2.2 Connection establishment
The transport entities shall use the following procedures:
a) assignment to network connection (see 6.1); then
b) connection establishment (see 6.5) and, if applicable
connection refusal (see 6.6).
10.2.3 Data transfer when non use of explicit flow control
has been selected
If this option has been selected as a result of the connection
establishment, the transport entities shall use the segmenting
procedure (see 6.3).
The TPDU-NR field of DT TPDUs is not significant and may take any
value.
NOTE- -Expedited data transfer is not applicable (see 6.5).
10.2.4 Data transfer when use of explicit flow control
has been selected
10.2.4.1 General
The sending transport entity shall use the following procedures:
a) segmenting (see 6.3); then
b) DT TPDU numbering (see 6.10);
86
The receiving transport entity shall use the following
procedures:
c) DT TPDU numbering (see 6.10); if a DT TPDU is received
which is out of sequence it shall be treated as a protocol
error; then
d) reassembling (see 6.3).
The variant of the DT TPDU numbering which is used by both
transport entities shall be that which was agreed at
connection establishment.
10.2.4.2 Flow control
The transport entities shall send an initial credit (which may be
zero) in the CDT field of the CR or CC TPDU. This credit
represents the initial value of the upper window edge allocated
to the peer entity.
The transport entity that receives the CR or the CC TPDU shall
consider its lower window edge as zero, and its upper window edge
as the value of the CDT field in the received TPDU.
In order to authorize the transmission of DT TPDUs, by its peer,
a transport entity may transmit an AK TPDU at any time, subject
to the following constraints:
a) the YR-TU-NR parameter shall be at most one greater than
the TPDU-NR field of the last received DT TPDU or shall be
zero if no DT TPDU has been received;
b) if an AK TPDU has previously been sent the value of the
YR-TU-NR parameter shall not be lower than that in the
previously sent AK TPDU.
c) the sum of the YR-TU-NR and CDT fields shall not be less
than the upper window edge allocated to the remote entity
(see note 1).
87
A transport entity which receives an AK TPDU shall consider the
YR-TU-NR field as its new lower window edge, and the sum of YR-
TU-NR and CDT as its new upper window edge. If either of these
have been reduced or if the lower window edge has become more
than one greater than the TPDU-NR of the last transmitted DT
TPDU, this shall be treated as a protocol error (see 6.22).
A transport entity shall not send a DT TPDU with a TPDU-NR
outside of the transmit window (see notes 2 and 3).
NOTES
1. This means that credit reduction is not applicable.
2. This means that a transport entity is required to stop
sending if the TPDU-NR field of the next DT TPDU which
would be sent would be the upper window edge. Sending of
DT TPDU may be resumed if an AK TPDU is received which
increases the upper window edge.
3. The rate at which a transport entity progresses the upper
window edge allocated to its peer entity constrains the
throughput attainable on the transport connection.
10.2.4.3 Expedited data
The transport entities shall follow the network normal variant of
the expedited data transfer procedure in 6.11 if its use has been
agreed during connection establishment. ED and EA TPDUs
respectively are not subject to the flow control procedures in
10.2.4.2. The ED-TPDU-NR and YR-ETDU-NR fields of ED and EA
TPDUs respectively are not significant and may take any value.
88
10.2.5 Release
The transport entities shall use the explicit variant of the
release procedure in 6.7.
89
11 SPECIFICATION FOR CLASS 3: ERROR RECOVERY AND MULTIPLEXING
CLASS
11.1 Functions of Class 3
Class 3 provides the functionality of Class 2 (with use of
explicit flow control) plus the ability to recover after a
failure signalled by the Network Layer without involving the user
of the transport service.
The mechanisms used to achieve this functionality also allow the
implementation of more flexible flow control.
11.2 Procedures for Class 3
11.2.1 Procedures applicable at all times
The transport entities shall use the following procedures:
a) association of TPDUs with transport connections (see 6.9);
b) TPDU transfer (see 6.2) and retention until
acknowledgement of TPDUs (AK variant only) (see 6.13);
c) treatment of protocol errors (see 6.22);
d) concatenation and separation (see 6.4);
e) reassignment after failure (see 6.12), together with
resynchronization (see 6.14);
f) frozen references (see 6.18).
Additionally, the transport entities may use the following
procedure:
g) multiplexing and demultiplexing (see 6.15);
90
11.2.2 Connection Establishment
The transport entities shall use the following procedures;
a) assignment to network connections (see 6.1); then
b) connection establishment (see 6.5) and, if appropriate,
together with connection refusal (see 6.6).
11.2.3 Data Transfer
11.2.3.1 General
The sending transport entity shall use the following procedures:
a) segmenting (see 6.3), then
b) DT TPDU numbering (see 6.10); after receipt of an RJ TPDU
(see 11.2.3.2) the next DT TPDU to be sent may have a
value which is not the previous value of TPDU-NR plus one.
The receiving transport entity shall use the following
procedures:
c) DT TPDU numbering (see 6.10); the TPDU-NR field of each
received DT TPDU shall be treated as a protocol error if
it exceeds the greatest such value received in a previous
DT TPDU by more than one (see note); then
d) reassembling (see 6.3); duplicated TPDUs shall be
eliminated before reassembling is performed.
NOTE - The use of RJ TPDUs (see 11.2.3.2) can lead to
retransmission and reduction of credit. Thus the receipt of a DT
TPDU which is a duplicate, or which is greater than or equal to
the upper window edge allocated to the peer entity, is possible
and is therefore not treated as a protocol error.
91
11.2.3.2 Use of RJ TPDU
A transport entity may send an RJ TPDU at any time in order to
invite retransmission or to reduce the upper window edge
allocated to the peer entity (see note 1).
When an RJ TPDU is sent, the following constraints shall be
respected:
a) the YR-TU-NR parameter shall be at most one greater than
the greatest such value received in a previous DT TPDU, or
shall be zero if no DT TPDU has yet been received (see
note 2);
b) if an AK or RJ TPDU has previously been sent the YR-TU-NR
parameter shall not be lower than that in the previously
sent AK or RJ TPDU or lower than zero if no AK or RJ TPDU.
When a transport entity receives an RJ TPDU (see note 3):
c) the next DT TPDU to be transmitted, or retransmitted,
shall be that for which the value of the TPDU-NR parameter
is equal to the value of the YR-TU-NR parameter of the RJ
TPDU;
d) the sum of the values of the YR-TU-NR and CDT parameters
of the RJ TPDU becomes the new upper window edge (see note
4).
NOTES
1. An RJ TPDU can also be sent as part of the
resynchronization (see 6.14) and reassignment after
failure (see 6.12) procedures.
2. It is recommended that the YR-TU-NR parameter be equal to
the TPDU-NR parameter of the next expected DT TPDU.
3. These rules are a subset of those specified for when an RJ
TPDU is received during resynchronization (see 6.14) and
reassignment after failure (see 6.12).
92
4. This means that RJ TPDU can be used to reduce the upper
window edge allocated to the peer entity (credit
reduction).
11.2.3.3 Flow Control
The procedures shall be as defined in 10.2.4.2, except that:
a) a credit reduction may lead to the reception of a DT TPDU
with a TPDU-NR parameter whose value is not, but would
have been less than the upper window edge allocated to the
remote entity prior to the credit reduction. This shall
not be treated as a protocol error;
b) receipt of an AK TPDU which sets the lower window edge
more than one greater than the TPDU-NR of the last
transmitted DT TPDU shall not be treated as a protocol
error, provided that all acknowledged DT TPDUs have been
previously transmitted (see notes 1 and 2).
NOTES
1. This can only occur during retransmission following
receipt of an RJ TPDU.
2. The transport entity may either continue retransmission as
before or retransmit only those DT TPDUs, not acknowledged
by the AK TPDU. In either case, copies of the
acknowledged DT TPDUs, need not be retained further.
11.2.3.4 Expedited data
The transport entities shall follow the network normal data
variant of expedited data transfer procedure in 6.11 if its use
has been agreed during connection establishment.
The sending transport entity shall not allocate the same ED-
TPDU-NR to successive ED TPDUs.
93
The receiving transport entity shall transmit an EA TPDU with the
same value in its YR-EDTU-NR parameter. If, and only if, this
number is different from that of the previously received ED TPDU
shall it generate a T-EXPEDITED DATA indication to convey the
data to the TS-user (see note 2).
NOTES
1. No other significance is attached to the ED-TPDU-NR
parameter. It is recommended, but not essential, that the
values be consecutive modulo 2**n, where n is the number
of bits of the parameter.
2. This procedure ensures that the TS-user does not receive
data corresponding to the same ED TPDU more than once.
11.2.4 Release
The transport entities shall use the explicit variant of the
release procedure in 6.7.
94
12 SPECIFICATION FOR CLASS 4: ERROR DETECTION AND RECOVERY CLASS
12.1 Functions of Class 4
Class 4 provides the functionality of Class 3, plus the ability
to detect and recover from lost, duplicated, or out of sequence
TPDUs without involving the TS-user.
This detection of errors is made by extended use of the DT TPDU
numbering of Class 2 and Class 3, by time-out mechanisms, and by
additional procedures.
This class additionally detects and recovers from damaged TPDUs
by using a checksum mechanism. The use of the checksum mechanism
must be available but its use or its non-use is subject to
negotiation.
Further on this class provides additional resilience against
network failure and increased throughput capability by allowing a
transport connection to make use of multiple network connections.
12.2 Procedures for Class 4
12.2.1 Procedures available at all times
12.2.1.1 Timers used at all times
This subclause defines timers that apply at all times in class 4.
These timers are listed in table 7.
This International Standard does not define specific values for
the timers, and the derivations described in this subclause are
not mandatory. The values should be chosen so that the required
quality of service can be provided, given the known
characteristics of the network.
Timers that apply only to specific procedures are defined under
the appropriate procedure.
95
+---------------------------|------------------------------------+
|Symbol| Name | Definition |
|------|--------------------|------------------------------------|
| MLR |NSDU lifetime | A bound for the maximum time which |
| |local-to-remote | may elapse between the transmis- |
| | | sion of an NSDU by a local trans- |
| | | port entity and the receipt of any |
| | | copy of it by a remote peer entity.|
| | | |
| MRL |NSDU lifetime | A bound for the maximum time which |
| |remote-to-local | may elapse between the transmission|
| | | of an SNDU from a remote transport |
| | | entity to a remote peer entity. |
| | | |
| ELR |Expected maximum | A bound for the maximum delay suf- |
| |transit delay | fered by all but a small proportion|
| |local-to-remote | of NSDUs transferred from the local|
| | | transport entity to a remote peer |
| | | entity. |
| | | |
| ERL |Expected maximum | A bound for the maximum delay suf- |
| |transit delay | fered by all but a small proportion|
| |remote-to-local | of NSDUs transferred from a remote |
| | | transport entity to the local peer |
| | | entity. |
| | | |
| AL |Local acknowledge | A bound for the maximum time which |
| |time | can elapse between the receipt of |
| | | a TPDU by the local transport en- |
| | | tity from the network layer and |
| | | the transmission of the corres- |
| | | ponding acknowledgement. |
| | | |
| AR |Remote acknow- | As AL, but for the remote entity. |
| |ledgement time | |
+----------------------------------------------------------------+
Table 7. (First of 2 pages) Time Parameters related to class 4
96
+----------------------------------------------------------------+
| T1 |Local retrans- | A bound for the maximum time that |
| |mission time | the local transport entity will |
| | | wait for acknowledgement before re-|
| | | transmitting a TPDU. |
| | | |
| R |Persistence time | A bound for the maximum time the |
| | | the local transport entity will |
| | | continue to transmit a TPDU that |
| | | requires acknowledgement. |
| | | |
| N |Maximum number of | A bound for the maximum number of |
| |transmissions | times which the local transport |
| | | entity will continue to transmit a |
| | | TPDU that requires acknowledgement.|
| | | |
| L |Bound on references | A bound for the maximum time |
| |and sequence | between the transmission of a TPDU |
| |numbers | and the receipt of any acknow- |
| | | ledgement relating to it. |
| | | |
| I |Inactivity time | A bound for the time after which |
| | | a transport entity will, if it |
| | | does not receive a TPDU, initiate |
| | | the release procedure to terminate |
| | | the transport connection. |
| | | |
| | | NOTE - This parameter is required |
| | | for protection against unsignalled |
| | | breaks in the network connection. |
| | | |
| W |Window time | A bound for the maximum time a |
| | | transport entity will wait before |
| | | retransmitting up to date window |
| | | information. |
+----------------------------------------------------------------+
Table 7. (Second of 2 pages) Time Parameters related to class 4
97
12.2.1.1.1 NSDU lifetime (MLR, MRL)
The network layer is assumed to provide, as an aspect of its
grade of service, for a bound on the maximum lifetime of NSDUs in
the network. This value may be different in each direction of
transfer through a network between two transport entities. The
values, for both directions of transfer, are assumed to be Known
by the transport entities. The maximum NSDU lifetime local-to-
remote (MLR) is the maximum time which may elapse between the
transmission of an NSDU from the local transport entity to the
network and receipt of any copy of the NSDU from the network at
the remote transport entity. The maximum NSDU lifetime remote-
to-local (MRL) is the maximum time which may elapse between the
transmission of an NSDU from the remote transport entity to the
network and receipt of any copy of the NSDU from the network at
the local transport entity.
12.2.1.1.2 Expected maximum transit delay (ELR, ERL)
The network layer is assumed to provide, as an aspect of its
grade of service, an expected maximum transit delay for NSDUs in
the network. This value may be different in each direction of
transfer through a network between two transport entities. The
values, for both directions of transfer, are assumed to be Known
by the transport entities. The expected maximum transit delay
local-to-remote (ELR) is the maximum delay suffered by all but a
small proportion of NSDUs transferred through the network from
the local transport entity to the remote transport entity. The
expected maximum transit delay remote-to-local (ERL) is the
maximum delay suffered by all but a small proportion of NSDUs
transfer through the network from the remove transport entity to
the local transport entity.
98
12.2.1.1.3 Acknowledge Time (AR, AL)
Any transport entity is assumed to provide a bound for the
maximum time which can elapse between its receipt of a TPDU from
the Network Layer and its transmission of the corresponding
response. This value is referred to as AL. The corresponding
time given by the remote transport entity is referred to as AR.
12.2.1.1.4 Local retransmission time (T1)
The local transport entity is assumed to maintain a bound on the
time it will wait for an acknowledgement before retransmitting
the TPDU. Its value is given by:
T1 = ELR + ERL + AR + X
where:
ELR = Expected maximum transit delay local-to-remote,
ERL = Expected maximum transit delay remote-to-local,
AR = Remote acknowledge time, and
X = local processing time for a TPDU.
12.2.1.1.5 Persistence Time (R)
The local transport entity is assumed to provide a bound for the
maximum time for which it may continue to retransmit a TPDU
requiring positive acknowledgement. This value is referred to as
R.
The value is clearly related to the time elapsed between
retransmission, T1, and the maximum number of transmissions, N.
It is not less than T1 * N + X, where X is a small quantity to
allow for additional internal delays, the granularity of the
mechanism used to implement T1 and so on. Because R is a bound,
the exact value of X is unimportant as long as it is bounded and
the value of a bound is known.
99
12.2.1.1.6 Bound on References and Sequence Numbers (L)
A bound for the maximum time between the decision to transmit a
TPDU and the receipt of any response relating to it (L) is given
by:
L = MLR + MRL + R + AR
where:
MLR = NSDU lifetime local-to-remote,
MRL = NSDU lifetime remote-to-local,
R = Persistence time, and
AR = Remote acknowledgement time.
It is necessary to wait for a period L before reusing any
reference of sequence number, to avoid confusion in case a TPDU
referring to it may be duplicated or delayed.
NOTES
1. In practice, the value of L may be unacceptably large. It
may also be only a statistical figure at a certain
confidence level. A smaller value may therefore be used
where this still allows the required quality of service to
be provided.
2. The relationships between times discussed above are
illustrated in figures 3 and 4.
[Figures 3 and 4 are omitted from this copy.]
12.2.1.2 General Procedures
The transport entity shall use the following procedures:
a) TPDU transfer (see 6.2);
b) association of TPDUs with transport connections (see 6.9);
100
c) treatment of protocol errors (see 6.22);
d) checksum (see 6.17);
e) splitting and recombining (see 6.23);
f) multiplexing and demultiplexing (see 6.15);
g) retention until acknowledgement of TPDUs (see 6.13);
h) frozen references (see 6.18).
j) retransmission procedures; when a transport entity has
some outstanding TPDUs that require acknowledgement, it
will check that no T1 interval elapses without the arrival
of a TPDU that acknowledges at least one of the
outstanding TPDUs.
If the timer expires, except if the TPDU to be
retransmitted is a DT TPDU and it is outside the transmit
window due credit reduction, the first TPDU is
retransmitted and the timer is restarted. After N
transmissions (i.e. N-1 retransmissions) it is assumed
that useful two-way communication is no longer possible
and the release procedure is used, and the TS-user is
informed.
NOTES
1) This procedure may be implemented by different means. For
example:
a) one interval is associated with each TPDU. If the
timer expires the associated TPDU will be transmitted
and the timer T1 will be restarted for all subsequent
TPDUs; or
b) one interval is associated with each transport
connection:
1) if the transport entity transmits a TPDU requiring
acknowledgement, it starts timer T1;
101
2) if the transport entity receives a TPDU that
acknowledges one of the TPDUs to be acknowledged,
it restarts timer T1 unless the received TPDU is
an AK which explicitly closes the transmit window.
3) if the transport entity receives a TPDU that
acknowledges the last TPDU to be acknowledged, it
stops timer T1.
For a decision whether the retransmission timer T1 is
maintained on a per TPDU or on a per transport connection
basis, throughput considerations have to be taken into
account.
2. For DT TPDUs it is a local choice to retransmit either
only the first DT TPDU or all TPDUs waiting for an
acknowledgement up to the upper window edge.
3. It is recommended that after N transmissions of a DT TPDU,
the transport entity waits T1 + W + MRL to provide a
higher possibility of receiving an acknowledgement before
entering the release phase. For other TPDU types which
may be retransmitted, it is recommended that after N
transmissions the transport entity waits T1 + MRL to
provide a higher possibility of receiving the expected
reply.
12.2.2 Procedures for Connection Establishment
12.2.2.1 Timers used in Connection Establishment
There are no timers specific to connection establishment.
102
12.2.2.2 General Procedures
The transport entities shall use the following procedures:
a) assignment to network connection (see 6.1);
b) connection establishment (see 6.5) and if appropriate
connection refusal (see 6.6) together with the additional
procedures:
1) a connection is not considered established until the
successful completion of a 3-way TPDU exchange. The
sender of a CR TPDU shall respond to the corresponding
CC TPDU by immediately sending a DT, ED, DR or AK
TPDU;
2) as a result of duplication or retransmission, 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, or is waiting for the T-CONNECT
response from the TS-user, the receiving transport
entity shall ignore such a TPDU. Otherwise a CC TPDU
shall be transmitted;
3) 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 shall only acknowledge the duplicate CC TPDU
according to the procedure in 12.2.2.2.b.1.
4) a CC TPDU may be received specifying a reference which
is in the frozen state. The response to such a TPDU
shall be a DR TPDU;
5) the retransmission procedures (see 12.2.1.2) are used
for both the CR TPDU and CC TPDU.
103
12.2.3 Procedures for Data Transfer
12.2.3.1 Timers used in Data Transfer
The data transfer procedures use two additional timers:
a) Inactivity Time (I)
To protect against unsignalled breaks in the network
connection or failure of the peer transport entity (half-open
connections), each transport entity maintains an inactivity
interval. The interval must be greater than E.
NOTE - A suitable value for I is given by
2 * (N * maximum of (T1, W))
unless local needs indicate another more appropriate value.
b) Window Time (W)
A transport entity maintains a timer interval to ensure that
there is a bound on the maximum interval between window
updates.
12.2.3.2 General Procedures for data transfer
The transport entities shall use the following procedures:
a) inactivity control (see 6.21);
b) expedited data (see 6.11);
c) explicit flow control (see 6.16).
The sending transport entity shall use the following procedures
in the following order:
d) segmenting (see 6.3);
e) DT TPDU numbering (see 6.10).
104
The receiving transport entity shall use the following procedures
in the following order:
f) DT TPDU numbering (see 6.10);
g) resequencing (see 6.20);
h) reassembling (see 6.3).
12.2.3.3 Inactivity Control
If the interval of the inactivity timer I expires without receipt
of some TPDU, the transport entity shall initiate the release
procedures. To prevent expiration of the remote transport
entity's inactivity timer 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 procedures (see 12.2.3.8) ensure that
this requirement is met.
NOTE - It is likely that the release procedure initiated due to
the expiration of the inactivity timer will fail, as such
expiration indicates probable failure of the supporting network
connection or of the remote transport entity.
12.2.3.4 Expedited Data
The transport entities shall follow the network normal data
variant of the expedited data transfer procedures (see 6.11), if
the use of transport expedited service option has been agreed
during connection establishment.
The ED TPDU shall have a TPDU-NR which is allocated from a
separate sequence space from that of the DT TPDUs.
A transport entity shall allocate the sequence number zero to the
ED TPDU-NR of the first ED TPDU which it transmits for a
105
transport connection. For subsequent ED TPDU sent on the same
transport connection, the transport entity shall allocate a
sequence number one greater than the previous one.
Modulo 2**7 arithmetic shall be used when normal formats have
been selected and modulo 2**31 arithmetic shall be used when
extended formats have been selected.
The receiving transport entity shall transmit an EA TPDU with the
same sequence number in its YR-ETDU-NR field. If this number is
one greater than in the previously in sequence received ED TPDU,
the receiving transport entity shall transfer the data in the ED
TPDU to the TS-user.
If a transport entity does not receive an EA TPDU in
acknowledgement to an ED TPDU it shall follow the retransmission
procedures (see note and 12.2.1.2).
The sender of an ED TPDU shall not send any new DT TPDU with
higher TPDU-NR until it receives the EA TPDU.
NOTE - This procedure ensures that ED TPDUs are delivered to the
TS-user in sequence and that the TS-user does not receive data
corresponding to the same ED TPDU more than once. Also it
guarantees the arrival of the ED TPDU before any subsequently
sent DT TPDU.
12.2.3.5 Resequencing
The receiving transport entity shall deliver all DT TPDUs to the
TS-user in the order specified by the sequence number field.
DT TPDUs received out-of-sequence but within the transmit window
shall not be delivered to the TS-user until all in-sequence TPDUs
have been received. DT TPDU received out-of-sequence and outside
the transmit window shall be discarded.
Duplicate TPDUs can be detected because the sequence number
matches that of preciously received TPDUs. Sequence numbers
shall not be reused for the period L after their previous use.
106
Otherwise, a new, valid TPDU could be confused with a duplicated
TPDU which had previously been received and acknowledged.
Duplicated DT TPDUs shall 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 shall be ignored.
12.2.3.6 Explicit Flow Control
The transport entities shall send an initial credit (which may
take the value 0) in the CDT field of the CR TPDU or CC TPDU.
This credit represents the initial value of the upper window edge
of the peer entity.
The transport entity which receives the CR TPDU or CC TPDU shall
consider its lower window edge as zero and its upper window edge
as the value in the CDT field in the received TPDU.
In order to authorize the transmission of DT TPDUs by its peer, a