RFC 0905
ISO Transport Protocol specification ISO DP 8073
6.14 Resynchronization 6.14.1 Purpose The resynchronization procedures are used in Classes 1 and 3 to restore the transport connection to normal after a reset or during reassignment after failure according to 6.12. 6.14.2 Network service primitives The procedure makes use of the following network service primitive: N-RESET indication. 6.14.3 TPDUs and parameters used The procedure uses the following TPDUs and parameters: a) CR, DR, CC and DC TPDUs b) RJ TPDUs; - YR-TU-NR. c) DT TPDU; - TPDU-NR d) ED TPDU; - ED TPDU-NR. e) EA TPDU; - YR-EDTU-NR.
6.14.4 Procedure A transport entity which is notified of the occurence of an N- RESET or which is performing 'reassignment after failure' according to 6.12 shall carry out the active resynchronization procedure (see 6.14.4.1) unless any of the following hold: a) the transport entity is the responder (see note). In this case the passive resynchronization procedure is carried out (see 6.14.4.2). b) the transport entity has elected not to reassign (see 6.12.3.c). In this case no resynchronization takes place. 6.14.4.1 Active resynchronization procedures The Transport entity shall carry out one of the following actions: a) if the TTR timer has been previously started and has run out (i.e. no valid TPDU has been received), the transport connection is considered as released and the reference is frozen (see 6.18). b) otherwise, the TTR timer shall be started (unless it is already running) and the first applicable of the following actions shall be taken: 1) if a CR TPDU is unacknowledged, then the transport entity shall retransmit it; 2) if a DR TPDU is unacknowledged, then the transport entity shall retransmit it; 3) otherwise, the transport entity shall carry out the data resynchronization procedures (6.14.4.3). The TTR timer is stopped when a valid TPDU is received.
6.14.4.2 Passive resynchronization procedures The transport entity shall not send any TPDUs until a TPDU has been received. The transport entity shall start its TWR timer if it was not already started (due to a previous N-DISCONNECT or N- RESET indication). If the timer runs out prior to the receipt of a valid TPDU which commence resynchronization (i.e. CR or DR or RJ TPDU) the transport connection is considered as released and the reference is released (see 6.18). When a valid TPDU is received the transport entity shall stop its TWR timer and carry out the appropriate one of the following actions, depending on the TPDU: a) if it is a DR TPDU, then the transport entity shall send a DC TPDU; b) if it is a repeated CR TPDU (see note 1) then the transport entity shall carry out the appropriate action from the following: 1) if a CC TPDU has already been sent, and acknowledged: treat as a protocol error; 2) if a DR TPDU is unacknowledged (whether or not a CC TPDU is unacknowledged): retransmit the DR TPDU, but setting the source reference to zero; 3) if the T-CONNECT response has not yet been received from the user: take no action; 4) otherwise; retransmit the CC TPDU followed by an unacknowledged ED TPDU (see note 2) and any DT TPDU; NOTES 1. A repeated CR TPDU can be identified by being on a network connection with the appropriate network addresses and having a correct source reference.
2. The transport entity should not use network expedited
until the CC TPDU is acknowledged (see 6.5). This
rule prevents the network expedited from overtaking
the CC TPDU.
c) if it is an RJ or ED TPDU then one of the following
actions shall be taken:
1) if a DR TPDU is unacknowledged, then the transport
entity shall retransmit it;
2) otherwise, the transport entity shall carry out the
data resynchronization procedures (6.14.4.3).
3) If a CC TPDU was unacknowledge, the RJ or ED TPDU
should then be considered as acknowledging the CC
TPDU. If a CC TPDU was never sent, the RJ TPDU should
then be considered as a protocol error.
6.14.4.3 Data Resynchronization Procedures
The transport entity shall carry out the following actions in the
following order:
a) (re)transmit any ED TPDU which is unacknowledged,
b) transmit an RJ TPDU with YR-TU-NR field set to the TPDU-NR
of the next expected DT TPDU;
c) wait for the next TPDU from the other transport entity,
unless an RJ or DR TPDU has already been received; if a DR
TPDU is received the transport entity shall send a DC,
freeze the reference, inform the TS-user of the
disconnection and take no further action (i.e. it shall
not follow the procedures in 6.14.4.3.d). If an RJ TPDU
is received, the procedure of 6.14.4.3.d shall be
followed. If an ED TPDU is received the procedures as
described in 6.11 shall be followed. If it is a
duplicated ED-TPDU the transport entity shall acknowledge
it, with an EA TPDU, discard the duplicated ED TPDU and
wait again for the next TPDU.
d) (re)transmit any DT TPDUs which are unacknowledged,
subject to any applicable flow control procedures (see
note);
NOTE - The RJ TPDU may have reduced the credit.
6.15 Multiplexing and demultiplexing
6.15.1 Purpose
The multiplexing and demultiplexing procedures are used in
Classes 2, 3 and 4 to allow several transport connections to
share a network connection at the same time.
6.15.2 TPDUs and parameters used
The procedure makes use of the following TPDUs and parameters:
CC, DR, DC, DT, AK, ED, EA, RJ and ER TPDUs
- DST-REF
6.15.3 Procedure The transport entities shall be able to send and receive on the same network connection TPDUs belonging to different transport connections. NOTES 1. When performing demultiplexing the transport connection to which the TPDUs apply is determined by the procedures defined in 6.9. 2. Multiplexing allows the concatenation of TPDUs belonging to different transport connections to be transferred in the same N-DATA primitive (see 6.4). 6.16 Explicit Flow Control 6.16.1 Purpose The explicit flow control procedure is used in Classes 2, 3 and 4 to regulate the flow of DT TPDUs independently of the flow control in the other layers. 6.16.2 TPDUs and parameters used The procedure makes use of the following TPDUs and parameters: a) CR, CC, AK and RJ TPDUs - CDT. b) DT TPDU - TPDU-NR.
c) AK TPDU
- YR-TU-NR;
- subsequence number;
- flow control confirmation.
d) RJ TPDU
- YR-TU-NR.
6.16.3 Procedure
The procedures differ in different classes. They are defined in
the clauses specifying the separate classes.
6.17 Checksum
6.17.1 Purpose
The checksum procedure is used to detect corruption of TPDUs by
the NS-provider.
NOTE - Although a checksum algorithm has to be adapted to the
type of errors expected on the network connection, at present
only one algorithm is defined.
6.17.2 TPDUs and parameters used
The procedure uses the following TPDUs and parameters:
All TPDUs
- checksum
6.17.3 Procedure The checksum is used only in Class 4. It is always used for the CR TPDU, and is used for all other TPDUs except if the non-use of the procedure was agreed during connection establishment. The sending transport entity shall transmit TPDUs with the checksum parameter set such that the following formulas are satisfied: SUM(from i=1 to i=L) OF a[i] EQUALS <zero> (module 255) SUM(from i=1 to i=L) OF i*a[i] EQUALS <zero> (module 255) where i = number (i.e. position) of an octet within the TPDU (see 13.2); a[i] = value of octet in position 1; L = length of TPDU in octets. A transport entity which receives a TPDU for a transport connection for which the use of checksum has been agreed and which does not satisfy the above formulas shall discard the TPDU (see also note 2). NOTES 1. An efficient algorithm for determining the checksum parameters is given in annex B. 2. If the checksum is incorrect, it is not possible to know with certainty to which transport connection the TPDU is related; further action may be taken for all the transport connections assigned to the network connection (see 6.9). 3. The checksum proposed is easy to calculate and so will not impose a heavy burden on implementations. However, it will not detect insertion or loss of leading or trailing zeros and will not detect some octets misordering.
6.18 Frozen references 6.18.1 Purpose This procedure is used in order to prevent re-use of a reference 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.
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.
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
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.
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;
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.
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.
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.
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. | +-------------------------------------------------------------+
+----------------------------------------------------------------+
| |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
+----------------------------------------------------------------+
| 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
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:
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.
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).
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
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
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).
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).
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);
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).
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.
10.2.5 Release The transport entities shall use the explicit variant of the release procedure in 6.7.
(next page on part 4)
