RFC 0905
ISO Transport Protocol specification ISO DP 8073
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);
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.
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).
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.
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.
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.
+---------------------------|------------------------------------+
|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
+----------------------------------------------------------------+
| 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
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.
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.
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);
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;
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.
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.
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).
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
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.
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
transport entity may transmit an AK TPDU at any time.
The sequence number of an AK TPDU shall not exceed the sequence
number of the next expected DT TPDU, i.e. it shall not be greater
than the highest sequence number of a received DT TPDU, plus one.
A transport entity may send a duplicate AK TPDU containing the
same sequence number, CDT, and subsequence number field at any
time.
A transport entity which receives an AK TPDU shall consider the
value of the YR-TU-NR field as its new lower window edge if it is
greater than any previously received in a YR-TU-NR field, and the
sum of YR-TU-NR and CDT as its new upper window edge subject to
the procedures for sequencing AK TPDUs (see 12.2.3.8). A
transport entity shall not transmit or retransmit a DT TPDU with
a sequence number outside the transmit window.
12.2.3.7 Sequencing of received AK TPDUs To allow a receiving transport entity to properly sequence a series of AK TPDUs that all contain the same sequence number and thereby use the correct CDT value, AK TPDUs may contain a subsequence parameter. For the purpose of determining the correct sequence of AK TPDUs, the absence of the subsequence parameter shall be equivalent to the value of the parameter set to zero. An AK TPDU is defined to be in sequence if: a) the sequence number is greater than in any previously received AK TPDU, or b) the sequence number is equal to the highest in any previously received AK TPDU, and the subsequence parameter is greater than in any previously received AK TPDU having the same value for YR-TU-NR field, or c) the sequence number and subsequence parameter are both equal to the highest in any previously received AK TPDU and the credit field is greater than or equal to that in any previously received AK TPDU having the same YR-TU-NR field. A transport entity is not required to include the subsequence number in its AK TPDUs. It may also choose not to use the subsequence parameter in sequencing received AK TPDUs. If a transport entity chooses not to recognize the subsequence parameter it shall still sequence received AK TPDUs according to 12.2.3.7.a. When the receiving transport entity recognizes an out of sequence AK TPDU it shall ignore it.
12.2.3.8 Procedure for transmission of AK TPDUs 12.2.3.8.1 Retransmission of AK TPDUs for window synchronization A transport entity shall not allow an interval W to pass without the transmission of an AK TPDU. if the transport entity is not using the procedure following setting CDT to zero (see 12.2.3.8.3) or reduction of the upper window edge (see 12.2.3.8.4), and does not have to acknowledge receipt of any DT TPDU, then it shall achieve this by retransmission of the most recent AK TPDU, with up-to-date window information. NOTE - The use of the procedures defined in 12.2.3.8.3 and 12.2.3.8.4 are optional for any transport entity. The protocol operates correctly either with or without these procedures which are defined to enhance the efficiency of its operation. However, if these procedures are not used then W must be set to ensure enough retransmissions of the AK TPDU so that release of TC is avoided. The value of W should be approximately W = (T1 * N)/(N-1) when the procedures are not used. 12.2.3.8.2 Sequence control for transmission of AK TPDUs To allow the receiving transport entity to process AK TPDUs in the correct sequence, as described in 12.2.3.7, the subsequence parameter may be included following reduction of CDT. If the value of the subsequence number to be transmitted is zero, then the parameter should be omitted. The value of the subsequence parameter, if used, shall be zero (either explicitly or by absence of the parameter) if the sequence number is greater than the field in previous AK TPDUs, sent by the transport entity. If the sequence number is the same as the previous AK TPDU sent and the CDT field is equal to or greater than the CDT field in the previous AK TPDU sent then the subsequence parameter, if used, shall be equal to that in the previously sent AK TPDU. If the sequence number is the same as the previous AK TPDU sent
and the CDT field is less than the value of the CDT field in the
previous AK TPDU sent than the subsequence parameter, if used,
shall be one greater than the value in the previous AK TPDU..
12.2.3.8.3 Retransmission of AK TPDUs after CDT set to zero
Due to the possibility of loss of AK TPDUs, the upper window edge
as perceived by the transport entity transmitting an AK TPDU may
differ from that perceived by the intended recipient. To avoid
the possibility of extra delay, the retransmission procedure (see
12.2.1.2) should be followed for an AK TPDU, if it opens the
transmit window which has previously been closed by sending an AK
TPDU with CDT field set to zero.
The retransmission procedure, if used, terminates and the
procedure in 12.2.3.8.1 is used when:
a) an AK TPDU is received containing the flow control
confirmation parameter, whose lower window edge and your
subsequence fields are equal to the sequence number and
subsequence number in the retained AK TPDU and whose
credit field is not zero.
b) an AK TPDU is transmitted with a sequence number higher
than that in the retained AK TPDU, due to reception of a
DT TPDU whose sequence number is equal to the lower window
edge;
c) N transmissions of the retained AK TPDU have taken place.
In this case the transport entity shall continue to
transmit the AK TPDU at an interval of W.
An AK TPDU which is subject to the retransmission procedure shall
not contain the flow control confirmation parameter. If it is
required to transmit this parameter concurrently, an additional
AK TPDU shall be transmitted having the same values in the
sequence, subsequence (if applicable) and credit fields.
12.2.3.8.4 Retransmission procedures following reduction of the upper window edge This subclause specifies the procedure for retransmission of AK TPDUs after a transport entity has reduced the upper window edge (see 12.2.3.6) or for an AK TPDU with the credit field set to zero. This procedure is used until the lower window edge exceeds the highest value of the upper window edge ever transmitted (i.e. the value existing at the time of credit reduction, unless a higher value is retained from a previous credit reduction). This retransmission procedure should be followed for any AK TPDU which increases the upper window edge, unless an AK TPDU has been received containing a flow control confirmation parameter, which corresponds to an AK TPDU transmitted following credit reduction, for which the sum of the credit and lower window edge fields (i.e. the upper window edge value) is greater than the lower window edge (YR-TU-NR field) of the transmitted AK TPDU. This retransmission procedure for any particular AK TPDU shall terminate when: a) an AK TPDU is received containing the flow control confirmation parameter, whose lower window edge and your subsequence fields are equal to the lower window edge and subsequence number in the retained AK TPDU; or b) N transmissions of the retained AK TPDU have taken place. In this case the transport entity shall continue to transmit the AK TPDU at an interval of W. An AK TPDU which is subject to the retransmission procedure shall not contain the flow control confirmation parameter. If it is required to transmit this parameter concurrently, an additional AK TPDU shall be transmitted having the same values in the sequence, subsequence (if applicable) and credit fields. NOTE - Retransmission of AK TPDUs is normally not necessary, except following explicit closing of the window (i.e. transmission of an AK TPDU with CDT field set to zero). If data is available to be transmitted, the retransmission procedure for DT TPDUs will ensure that an AK TPDU is received
granting further credit where this is available. Following
credit reduction, this may no longer be so, because
retransmission may be inhibited by the credit reduction. The
rules described in this clause avoid extra delay.
The rules for determining whether to apply the retransmission
procedure to an AK TPDU may be expressed alternatively as
follows. Let:
LWE = lower window edge
UWE = upper window edge
KUWE = lower bound on upper window edge
held by remote transport entity
The retransmission procedure is to be used whenever:
(UWE>LWE) and (KUWE = LWE)
i.e. when the window is opened and it is not known definitely
that the remote transport entity is aware of this.
KUWE is maintained as follows. When credit is reduced, KUWE is
set to LWE. Subsequently, it is increased only upon receipt of a
valid flow control confirmation (i.e. one which matches the
retained lower window edge and subsequence). In this case KUWE
is set to the implied upper window edge of the flow control
confirmation, i.e. the sum of its lower window edge and your
credit fields. By this means, it can be ensured that KUWE is
always less than or equal to the actual upper window edge in use
by the transmitter of DT TPDUs.
12.2.3.9 Use of Flow Control Confirmation parameter
At any time, an AK TPDU may be transmitted containing a flow
control confirmation parameter. The lower window edge, your
subsequence and your credit fields shall be set to the same
values as the corresponding fields in the most recently received
in sequence AK TPDU.
An AK TPDU containing a flow control confirmation parameter
should be transmitted whenever:
a) a duplicate AK TPDU is received, with the value of YR-TU-
NR, CDT, and subsequence fields equal to the most recently
received AK TPDU, but not itself containing the flow
control confirmation parameter;
b) an AK TPDU is received which increases the upper window
edge but not the lower window edge, and the upper window
edge was formerly equal to the lower window edge; or
c) an AK TPDU is received which increases the upper window
edge but not the lower window edge, and the lower window
edge is lower than the highest value of the upper window
edge received and subsequently reduced (i.e. following
credit reduction).
12.2.4 Procedures for Release
12.2.4.1 Timers used for Release
There are no timers used only for release.
12.2.4.2 General Procedures for Release
The transport entity shall use the explicit variant of normal
release (see 6.7).
13 STRUCTURE AND ENCODING OF TPDUs 13.1 Validity Table 8 specifies those TPDUs which are valid for each class and the code for each TPDU. KEY: xxxx (bits 4-1): used to signal the CDT (set to 0000 in classes 0 and 1) zzzz (bits 4-1): used to signal CDT in classes 2, 3, 4 set to 1111 in class 1 NF: Not available when the non explicit flow control option is selected. NRC: Not available when the receipt confirmation option is selected. NOTE - These codes are already in use in related protocols defined by standards oganizations other than CCITT/ISO.
+-------------------------------------------------------------+
| | Validity within | | |
| | classes | see | Code |
| |-------------------| Clause| |
| | 0 | 1 | 2 | 3 | 4 | | |
|-----------------------|-------------------|-------|---------|
|CR Connection Request | x | x | x | x | x | 13.3 |1110 xxxx|
|-----------------------|---|---|---|---|---|-------|---------|
|CC Connection Confirm | x | x | x | x | x | 13.4 |1101 xxxx|
|-----------------------|---|---|---|---|---|-------|---------|
|DR Disconnect Request | x | x | x | x | x | 13.5 |1000 0000|
|-----------------------|---|---|---|---|---|-------|---------|
|DC Disconnect Confirm | | x | x | x | x | 13.6 |1100 0000|
|-----------------------|---|---|---|---|---|-------|---------|
|DT Data | x | x | x | x | x | 13.7 |1111 0000|
|-----------------------|---|---|---|---|---|-------|---------|
|ED Expedited Data | | x | NF| x | x | 13.8 |0001 0000|
|-----------------------|---|---|---|---|---|-------|---------|
|AK Data Acknowledgement| |NRC| NF| x | x | 13.9 |0110 zzzz|
|-----------------------|---|---|---|---|---|-------|---------|
|EA Expedited Data | | x | NF| x | x | 13.10 |0010 0000|
|Acknowledgement | | | | | | | |
|-----------------------|---|---|---|---|---|-------|---------|
|RJ Reject | | x | | x | | 13.11 |0101 zzzz|
|-----------------------|---|---|---|---|---|-------|---------|
|ER TPDU Error | x | x | x | x | x | 13.12 |0111 0000|
|-----------------------|---|---|---|---|---|-------|---------|
| | | | | | | - |0000 0000|
| |---|---|---|---|---|-------|---------|
|not available | | | | | | - |0011 0000|
| (see note) |---|---|---|---|---|-------|---------|
| | | | | | | - |1001 xxxx|
| |---|---|---|---|---|-------|---------|
| | | | | | | - |1010 xxxx|
+-------------------------------------------------------------+
Table 8. TPDU code
13.2 Structure All the transport protocol data units (TPDUs) shall contain an integral number of octets. The octets in a TPDU are numbered starting from 1 and increasing in the order they are put into an NSDU. The bits in an octet are numbered from 1 to 8, where bit 1 is the low-ordered bit. When consecutive octets are used to represent a binary number, the lower octet number has the least significant value. NOTE - When the encoding of a TPDU is represented using a diagram in this clause, the following representation is used: a) octets are shown with the lowest numbered octet to the left, higher numbered octets being further to the right; b) within an octet, bits are shown with bit 8 to the left and bit 1 to the right. TPDUs shall contain, in the following order: a) the header, comprising: 1) the length indicator (LI) field; 2) the fixed part; 3) the variable part, if present; b) the data field, if present. This structure is illustrated below: octet 1 2 3 4 ... n n+1 ... p p+1 ...end +---+-------------+--------------+-----------+ | LI| fixed part | variable part| data field| +---+-------------+--------------+-----------+ <--------------- header ------>
13.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 (1111 1110). The length indicated shall be the header length in octets including parameters, but excluding the length indicator field and user data, if any. The value 255 (1111 1111) is reserved for possible extensions. If the length indicated exceeds the size of the NS-user data which is present, this is a protocol error. 13.2.2 Fixed part 13.2.2.1 General The fixed part contains frequently occurring parameters including the code of the TPDU. The length and the structure of the fixed part are defined by the TPDU code and in certain cases by the protocol class and the formats in use (normal or extended). If any of the parameters of the fixed part have an invalid value, or if the fixed part cannot be contained with the header (as defined by LI) this is a protocol error. NOTE - In general, the TPDU code defines the fixed part unambiguously. However, different variants may exist for the same TPDU code (see normal and extended formats). 13.2.2.2 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 Connection Request
1101 xxxx Connection Confirm
0101 xxxx Reject
0110 xxxx Data Acknowledgement
where xxxx (bits 4-1) is used to signal the CDT.
Only those codes defined in 13.1 are valid.
13.2.3 Variable part
The variable part is used to define less frequently used
parameters. If the variable part is present, it shall contain
one or more parameters.
NOTE - The number of parameters that may be contained in the
variable part is indicated by the length of the variable part
which is LI minus the length of the fixed part.
Each parameter contained within the variable part is structured
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 | |
+------------------------------------|
- The parameter code field is coded in binary;
NOTE - Without extensions, it provides a maximum number of 255
different parameters. However, as noted below, bits 8 and 7
cannot take every possible value, so the practical maximum
number of different parameters is less. Parameter code 1111
1111 is reserved for possible extensions of the parameter code.
- The parameter length indication indicates the length, in
octets, of the parameter value field.
NOTE - 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 succeeding parameter, the maximum
value of m decreases.
- The parameter value field contains the value of the parameter
identified in the parameter code field.
- No parameter codes use bits 8 and 7 with the value 00.
- The parameters defined in the variable part may be in any
order. If any parameter is duplicated then the later value
shall be used. A parameter not defined in this International
Standard shall be treated as a protocol error in any received
TPDU except a CR TPDU; in a CR TPDU it shall be ignored. If
the responding transport entity selects a class for which a
parameter of the CR TPDU is not defined, it may ignore this
parameter, except the class and option, and alternative
protocol class parameters which shall always be interpreted. A
parameter defined in this International Standard but having an
invalid value shall be treated as a protocol error in any
received TPDU except a CR TPDU. In a CR TPDU it shall be
treated as a protocol error if it is either the class and
option parameter or the alternative class parameter or the
additional option parameter; otherwise it shall be either
ignored or treated as a protocol error.
(next page on part 5)
