Network Working Group ISO
Request for Comments: 905 April 1984
Status of this Memo:
This document is distributed as an RFC for information only. It does not specify a standard for the ARPA-Internet.
Notes:
1) RFC 892 is an older version of the ISO Transport Protocol Specification. Therefore this RFC should be assumed to supercede RFC 892.
2) This document has been prepared by retyping the text of ISO/TC97/SC16/N1576 and then applying proposed editorial corrections contained in ISO/TC97/SC16/N1695. These two documents, taken together, are undergoing voting within ISO as a Draft International Standard (DIS).
3) Although this RFC has been reviewed after typing, and is believed to be substantially correct, it is possible that typographic errors not present in the ISO documents have been overlooked.
Alex McKenzie
BBN
3.2.22 upper window edge allocated to the peer
entity:
i
connections
iii
RECOVERY CLASS
10 SPECIFICATION FOR CLASS 2 - MULTIPLEXING
CLASS
10.2.3 Data transfer when non use of explicit
flow control
10.2.4 Data transfer when use of explicit flow
control
v
MULTIPLEXING CLASS
12 SPECIFICATION FOR CLASS 4: ERROR DETECTION
AND RECOVERY CLASS
12.2.1.1.2 Expected maximum transit delay (ELR,
ERL)
12.2.1.1.6 Bound on References and Sequence
Numbers (L)
vi
synchronization
12.2.3.8.2 Sequence control for transmission of
AK TPDUs
12.2.3.8.3 Retransmission of AK TPDUs after CDT
set to zero
12.2.3.8.4 Retransmission procedures following
reduction of the
12.2.3.9 Use of Flow Control Confirmation
parameter
vii
The Transport Protocol Standard is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498). It is most closely related to, and lies within the field of application of the Transport Service Standard (DP 8072). It also uses and makes reference to the Network Service Standard (DP 8348), whose provisions it assumes in order to accomplish the transport protocol's aims. The interelationship of these standards is depicted in figure 1.
-------------------------TRANSPORT SERVICE DEFINITION------------
Transport | --- Reference to aims --------------
Protocol |
Specification | --- Reference to assumptions -------
-------------------------NETWORK SERVICE DEFINITION--------------
Relationaship between Transport Protocol and adjacent services Figure 1 .
The International Standard specifies a common encoding and a number of classes of transport protocol procedures to be used with different network qualities of service.
It is intended that the Transport Protocol should be simple but general enough to cater for the total range of Network Service qualities possible, without restricting future extensions.
The protocol is structured to give rise to classes of protocol which are designed to minimize possible incompatibilities and implementation costs.
1
This protocol standard defines mechanisms that can be used to optimize network tariffs and enhance the following qualities of service:
a) different throughput rates;
b) different error rates;
c) integrity of data requirements;
d) reliability requirements.
It does not require an implementation to use all of these mechanisms, nor does it define methods for measuring achieved quality of service or criteria for deciding when to release transport connections following quality of service degradation.
The primary aim of this International Standard is to provide a set of rules for communication expressed in terms of the procedures to be carried out by peer entities at the time of communication. These rules for communication are intended to provide a sound basis for development in order to serve a variety of purposes:
a) as a guide for implementors and designers;
b) for use in the testing and procurement of equipment;
c) as part of an agreement for the admittance of systems into the open systems environment;
d) as a refinement of the understanding of OSI.
It is expected that the initial users of the International Standard will be designers and implementors of equipment and the International Standard contains, in notes or in annexes, guidance on the implementation of the procedures defined in the standard.
2
This International Standard contains a section on conformance of
equipment claiming to implement the procedures in this
International Standard. Attention is drawn to the fact that the
standard does not contain any tests to demonstrate this
conformance.
The variations and options available within this International Standard are essential to enable a Transport Service to be provided for a wide variety of applications over a variety of network qualities. Thus, a minimally conforming implementation will not be suitable for use in all possible circumstances. It is important, therefore, to qualify all references to this International Standard with statements of the options provided or required or with statements of the intended purpose of provision or use.
1 SCOPE AND FIELD OF APPLICATION
a) five classes of procedures:
1) Class 0. Simple class;
2) Class 1. Basic error recovery class;
3) Class 2. Multiplexing class;
4) Class 3. Error recovery and multiplexing class;
5) Class 4. Error detection and recovery class,
3
b) the means of negotiating the class of procedures to be used by the transport entities;
c) the structure and encoding of the transport protocol data
units used for the transfer of data and control
information;
a) the interactions between peer transport entities through the exchange of transport protocol data units;
b) the interactions between a transport entity and the transport service user in the same system through the exchange of transport service primitives;
c) the interactions between a transport entity and the network service provider through the exchange of network service primitives.
These procedures are defined in the main text of the standard supplemented by state tables in annex A.
1.3
These procedures are applicable to instances of communication between systems which support the Transport Layer of the OSI Reference Model and which wish to interconnect in an open systems environment.
4
This International Standard also specifies conformance
requirements for systems implementing these procedures. It does
not contain tests which can be used to demonstrate this
conformance.
2 REFERENCES
ISO 7498 Information processing systems - Open systems
interconnection - Basic Reference Model
DP 8072 Information processing systems - Open systems
interconnection - Transport service definition
DP 8348 Information processing systems - Open systems
interconnection - Connection-oriented network service
definition.
5
NOTE - The definitions contained in this clause make use of abbreviations defined in clause 4.
3.1
This International Standard is based on the concepts developed in the Reference Model for Open Systems Interconnection (DIS 7498) and makes use of the following terms defined in that standard:
a) concatenation and separation;
b) segmenting and reassembling;
c) multiplexing and demultiplexing;
d) splitting and recombining;
e) flow control.
3.2
For the purpose of this International Standard, the following definitions apply:
6
An abstract representation of the totality of those entities within a single system that make use of the transport service.
An abstract machine that models the totality of the entities providing the network service, as viewed by a transport entity.
A decision made by a system concerning its behavior in the Transport Layer that is not subject to the requirements of this protocol.
A transport entity that initiates a CR TPDU.
7
NOTE - Initiator and responder are defined with respect to a single transport connection. A transport entity can be both an initiator and responder simultaneously.
A transport entity that sends a given TPDU.
A transport entity that receives a given TPDU.
The protocol class that the initiator indicates in a CR TPDU as its first choice for use over the transport connection.
A protocol class that the initiator indicates in a CR TPDU as an alternative choice for use over the transport connection.
8
The protocol class that the responder indicates in a CC TPDU that it has chosen for use over the transport connection.
The value for a parameter that the initiator indicates in a CR TPDU that it wishes to use over the transport connection.
The value for a parameter that the responder indicates in a CC TPDU that it has chosen for use over the transport connection.
An N-RESET indication, or an N-DISCONNECT indication with a reason code indicating an error, that a transport entity receives from the NS-provider.
9
A TPDU whose use does not comply with the procedures for the class.
a) The number in the TPDU-NR field of a DT TPDU that indicates the order in which the DT TPDU was transmitted by a transport entity.
b) The number in the YR-TU-NR field of an AK or RJ TPDU that indicates the sequence number of the next DT TPDU expected to be received by a transport entity.
The set of consecutive sequence numbers which a transport entity has been authorized by its peer entity to send at a given time on a given transport connection.
10
The sequence number which is one greater than the highest sequence number in the transmit window.
The value that a transport entity communicates to its peer entity to be interpreted as its new upper window edge.
A transmit window that contains no sequence number.
Information contained in a TPDU relating to the upper and the lower window edges.
11
A reference that is neither currently in use for identifying a transport connection or which is in a frozen state.
TS-user data that is transferred intact between transport
entities and which is unavailable for use by the transport
entities.
The transport entity that issued the N-CONNECT request leading to the creation of that network connection.
A TPDU that is subject to the retransmission procedure or retention until acknowledgement procedure and is available for possible retransmission.
12
TPDU Transport protocol data unit
TSDU Transport service data unit
NSDU Network service data unit
CR TPDU Connection request TPDU
CC TPDU Connection confirm TPDU
DR TPDU Disconnect request TPDU
DC TPDU Disconnect confirm TPDU
DT TPDU Data TPDU
ED TPDU Expedited data TPDU
AK TPDU Data acknowledge TPDU
EA TPDU Expedited acknowledge TPDU
RJ TPDU Reject TPDU
ER TPDU Error TPDU
LI Length indicator (field)
CDT Credit (field)
TSAP-ID Transport service access point
identifier (field)
DST-REF Destination reference (field)
SRC-REF Source reference (field)
EOT End of TSDU mark
TPDU-NR DT TPDU number (field)
ED-TPDU-NR ED TPDU number (field)
YR-TU-NR Sequence number response (field)
YR-EDTU-NR ED TPDU number response (field)
13
T1 Elapsed time between retransmissions
N The maximum number of transmissions
L Bound on reference
I Inactivity time
W Window time
TTR Time to try reassignment/resynchronization
TWR Time to wait for
reassignment/resynchronization
TS1 Supervisory timer 1
TS2 Supervisory time 2
MLR NSDU lifetime local-to-remote
MRL NSDU lifetime remote-to-local
ELR Expected maximum transit delay
local-to-remote
ERL Expected maximum transit delay
remote-to-local
R Persistence time
AL Local acknowledgement time
AR Remote acknowledgement time
TS-user Transport service user
TSAP Transport service access point
NS-provider Network service provider
NSAP Network service access point
QOS Quality of service
14
The protocol specified in this International Standard supports the transport service defined in DP 8072.
Information is transferred to and from the TS-user in the transport service primitives listed in table 1.
15
| Primitive | Parameter |
|--------------------------------|----------------------------|
|T-CONNECT request | Called Address, |
| indication | Calling Address, |
| | Expedited Data option, |
| | Quality of Service, |
| | TS User-Data. |
|--------------------------------|----------------------------|
|T-CONNECT response | Responding Address, |
| confirm | Quality of Service, |
| | Expedited Data option, |
| | TS User-Data. |
|--------------------------------|----------------------------|
|T-DATA request | TS User-Data. |
| indication | |
|--------------------------------|----------------------------|
|T-EXPEDITED DATA request | TS User-Data. |
| indication | |
|--------------------------------|----------------------------|
|T-DISCONNECT request | TS User-Data. |
|--------------------------------|----------------------------|
|T-DISCONNECT indication | Disconnect reason, |
| | TS User-Data. |
+--------------------------------|----------------------------+
Table 1. Transport service primitives
The protocol specified in this International Standard assumes the use of the network service defined in DP 8348.
Information is transferred to and from the NS-provider in the network service primitives listed in table 2.
16
| Primitives |X/Y| Parameters |X/Y/Z|
|----------------------------|---|------------------------|-----|
|N-CONNECT request | X | Called Address, | X |
| indication | X | Calling Address, | X |
| response | X | NS User-Data, | Z |
| confirm | X | QOS parameter set, | X |
| | | Responding address, | Z |
| | | Receipt confirmation | Y |
| | | selection. | |
|----------------------------|---|------------------------|-----|
|N-DATA request | X | NS User-Data, | X |
| indication | X | Confirmation request | Y |
|----------------------------|---|------------------------|-----|
|N-DATA ACKNOWLEDGE | | | |
| request | Y | | |
| indication | Y | | |
|----------------------------|---|------------------------|-----|
|N-EXPEDITED DATA | | | |
| request | Y | NS User-Data. | Y |
| indication | Y | | |
|----------------------------|---|------------------------|-----|
|N-RESET request | X | Originator, | Z |
| indication | X | Reason. | Z |
| response | X | | |
| confirm | X | | |
|----------------------------|---|------------------------|-----|
|N-DISCONNECT request | X | NS User-Data. | Z |
| indication | X | Originator, | Z |
| | | Reason. | Z |
+---------------------------------------------------------------+
Table 2. Network service primitives
17
Y - The Transport Protocol assumes that this facility is provided in some networks and a mechanism is provided to optionally use the facility.
Z - The Transport Protocol does not use this parameter.
NOTES:
1 - The parameters listed in this table are those in the current network service (first DP 8348).
2 - The way the parameters are exchanged between the transport entity and the NS-provider is a local matter.
The functions in the Transport Layer are those necessary to bridge the gap between the services available from the Network Layer and those to be offered to the TS-users.
The functions in the Transport Layer are concerned with the enhancement of quality of service, including aspects of cost optimization.
These functions are grouped below into those used at all times during a transport connection and those concerned with connection establishment, data transfer and release.
NOTE - This International Standard does not include the following functions which are under consideration for inclusion in future editions of this standard:
a) encryption;
18
d) blocking;
e) temporary release of network connections;
f) alternative checksum algorithm.
The following functions, depending upon the selected class and options, are used at all times during a transport connection:
a) transmission of TPDUs (see 6.2 and 6.9);
b) multiplexing and demultiplexing (see 6.15), a function used to share a single network connection between two or more transport connections;
c) error detection (see 6.10, 6.13 and 6.17), a function used to detect the loss, corruption, duplication, misordering or misdelivery of TPDUs;
d) error recovery (see 6.12, 6.14, 6.18, 6.19, 6.20, 6.21 and 6.22), a function used to recover from detected and signalled errors.
The purpose of connection establishment is to establish a
transport connection between two TS-users. The following
functions of the transport layer during this phase must match the
TS-users' requested quality of service with the services offered
by the network layer:
19
b) decide whether to multiplex multiple transport connections onto a single network connection (see 6.5);
c) establish the optimum TPDU size (see 6.5);
d) select the functions that will be operational upon
entering the data transfer phase (see 6.5);
e) map transport addresses onto network addresses;
f) provide a means to distinguish between two different transport connections (see 6.5);
g) transport of TS-user data (see 6.5).
The purpose of data transfer is to permit duplex transmission of TSDUs between the two TS-users connected by the transport connection. This purpose is achieved by means of two-way simultaneous communication and by the following functions, some of which are used or not used in accordance with the result of the selection performed in connection establishment:
a) concatenation and separation (see 6.4), a function used to collect several TPDUs into a single NSDU at the sending
transport entity and to separate the TPDUs at the
receiving transport entity;
b) segmenting and reassembling (see 6.3), a function used to segment a single data TSDU into multiple TPDUs at the sending transport entity and to reassemble them into their original format at the receiving transport entity;
20
d) flow control (see 6.16), a function used to regulate the flow of TPDUs between two transport entities on one transport connection;
e) transport connection identification, a means to uniquely identify a transport connection between the pair of transport entities supporting the connection during the lifetime of the transport connection;
f) expedited data (see 6.11), a function used to bypass the flow control of normal data TPDU. Expedited data TPDU flow is controlled by separate flow control;
g) TSDU delimiting (see 6.3), a function used to determine the beginning and ending of a TSDU.
The purpose of release (see 6.7 and 6.8) is to provide
disconnection of the transport connection, regardless of the
current activity.
The functions of the Transport Layer have been organized into classes and options.
A class defines a set of functions. Options define those functions within a class which may or may not be used.
This International Standard defines five classes of protocol:
21
c) Class 2: Multiplexing Class;
d) Class 3: Error Recovery and Multiplexing Class;
e) Class 4: Error Detection and Recovery Class.
NOTE - Transport connections of classes 2, 3 and 4 may be multiplexed together onto the same network connection.
The use of classes and options is negotiated during connection establishment. The choice made by the transport entities will depend upon:
a) the TS-users' requirements expressed via T-CONNECT service primitives;
b) the quality of the available network services;
c) the user required service versus cost ratio acceptable to the TS-user.
The following list classifies network services in terms of quality with respect to error behavior in relation to user requirements; its main purpose is to provide a basis for the decision regarding which class of transport protocol should be used in conjunction with given network connection:
22
b) Type B. Network connections with acceptable residual error rate (for example not signalled by disconnect or reset) but unacceptable rate of signalled errors.
c) Type C. Network connections with unacceptable residual error rate.
It is assumed that each transport entity is aware of the quality of service provided by particular network connections.
Class 0 provides the simplest type of transport connection and is fully compatible with the CCITT recommendation S.70 for teletex terminals.
Class 0 has been designed to be used with type A network connections.
Class 1 provides a basic transport connection with minimal overheads.
The main purpose of the class is to recover from network disconnect or reset.
Selection of this class is usually based on reliability criteria. Class 1 has been designed to be used with type B network connections.
23
Class 2 provides a way to multiplex several transport connections onto a single network connection. This class has been designed to be used with type A network connections.
The objective is to provide flow control to help avoid congestion at transport-connection-end-points and on the network connection. Typical use is when traffic is heavy and continuous, or when there is intensive multiplexing. Use of flow control can optimize response times and resource utilization.
The objective is to provide a basic transport connection with minimal overheads suitable when explicit disconnection of the transport connection is desirable. The option would typically be used for unsophisticated terminals, and when no multiplexing onto
network connections is required. Expedited data is never
available.
Class 3 provides the characteristics of Class 2 plus the ability to recover from network disconnect or reset. Selection of this class is usually based upon reliability criteria. Class 3 has been designed to be used with type B network connections.
24
This class also provides for increased throughput capability and additional resilience against network failure. Class 4 has been designed to be used with type C network connections.
A transport entity communicates with its TS-users through one or more TSAPs by means of the service primitives as defined by the transport service definition DP 8072. Service primitives will cause or be the result of transport protocol data unit exchanges between the peer transport entities supporting a transport connection. These protocol exchanges are effected using the services of the Network Layer as defined by the Network Service Definition DP 8348 through one or more NSAPs.
Transport connection endpoints are identified in end systems by an internal, implementation dependent, mechanism so that the TS- user and the transport entity can refer to each transport connection.
25
----------| TSAP |------------------------| TSAP |----------
+------+ +------+
| |
+---------------+ +---------------+
| Transport | | Transport |
| entity | | entity |
+---------------+ +---------------+
| |
| |
+------+ +------+
----------| NSAP |------------------------| NSAP |----------
+------+ +------+
| |
+-------------------------------+
Figure 2 . Model of the transport layer
NOTE - For purpose of illustration, this figure shows only one TSAP and one NSAP for each transport entity. In certain instances, more than one TSAP and/or more than one NSAP may be associated with a particular transport entity.
26
This clause contains elements of procedure which are used in the specification of protocol classes in clauses 7 to 12. These elements are not meaningful on their own.
The procedures define the transfer of TPDUs whose structure and coding is specified in clause 13. Transport entities shall accept and respond to any TPDU received in a valid NSDU and may issue TPDUs initiating specific elements of procedure specified in this clause.
NOTE - Where network service primitives and TPDUs and parameters used are not significant for a particular element of procedure, they have not been included in the specification.
The procedure is used in all classes to assign transport connections to network connections.
The procedure makes use of the following network service
primitives:
a) N-CONNECT;
b) N-DISCONNECT.
27
Each transport connection shall be assigned to a network
connection. The initiator may assign the transport connection to
an existing network connection of which it is the owner or to a
new network connection (see Note 1) which it creates for this
purpose.
The initiator shall not assign or reassign the transport
connection to an existing network connection if the protocol
class(es) proposed or the class in use for the transport
connection are incompatible with the current usage of the network
connection with respect to multiplexing (see Note 2).
During the resynchronization (see 6.14) and reassignment after failure (see 6.12) procedures, a transport entity may reassign a transport connection to another network connection joining the same NSAPs, provided that it is the owner of the network connection and that the transport connection is assigned to only one network connection at any given time.
During the splitting procedure (see 6.23), a transport entity may
assign a transport connection to any additional network
connection joining the same NSAPs, provided that it is the owner
of the network connection and that multiplexing is possible on
the network connection.
The responder becomes aware of the assignment when it receives
a) a CR TPDU during the connection establishment procedure (see 6.5); or
b) an RJ TPDU or a retransmitted CR or DR TPDU during the
resynchronization (see 6.14) and reassignment after
failure (see 6.12) procedures; or
c) any TPDU when splitting (see 6.23) is used.
28
assigned to it, may be available after initial
establishment, or because all of the transport connections
previously assigned to it have been released. It is
recommended that only the owner of such a network
connection should release it. Furthermore, it is
recommended that it not be released immediately after the
transmission of the final TPDU of a transport connection -
either a DR TPDU in response to CR TPDU or a DC TPDU in
response to DR TPDU. An appropriate delay will allow the
TPDU concerned to reach the other transport entity
allowing the freeing of any resources associated with the
transport connection concerned.
The TPDU transfer procedure is used in all classes to convey transport protocol data units in user data fields of network service primitives.
29
a) N-DATA;
b) N-EXPEDITED DATA
The transport protocol data units (TPDUs) defined for the protocol are listed in 4.2.
When the network expedited variant has been selected for class 1, the transport entities shall transmit and receive ED and EA TPDUs as NS-user data parameters of N-EXPEDITED DATA primitives.
In all other cases, transport entities shall transmit and receive TPDUs as NS-user data parameters of N-DATA primitives.
When a TPDU is put into an NS-user data parameter, the
significance of the bits within an octet and the order of octets
within a TPDU shall be as defined in 13.2.
NOTE - TPDUs may be concatenated (see 6.4).
The segmenting and reassembling procedure is used in all classes to map TSDUs onto TPDUs.
30
DT TPDUs;
- End of TSDU.
A transport entity shall map a TSDU on to an ordered sequence of one or more DT TPDUs. This sequence shall not be interrupted by other DT TPDUs on the same transport connection.
All DT TPDUs except the last DT TPDU in a sequence greater than one shall have a length of data greater than zero.
NOTES
The procedure for concatenation and separation is used in classes 1, 2, 3 and 4 to convey multiple TPDUs in one NSDU.
31
The set of concatenated TPDUs may contain:
a) any number of TPDUs from the following list: AK, EA, RJ,
ER, DC TPDUs, provided that these TPDUs come from
different transport connections;
b) no more than one TPDU from the following list: CR, DR,
CC, DT, ED TPDUs; if this TPDU is present, it shall be
placed last in the set of concatenated TPDUs.
NOTES
The procedure for connection establishment is used in all classes to create a new transport connection.
32
N-DATA
The procedure uses the following TPDUs and parameters:
a) CR TPDU;
- CDT;
- DST-REF (set to zero);
- SRC-REF
- CLASS and OPTIONS (i.e. preferred class, use of extended
format, non-use of explicit flow control in class 2);
- calling TSAP-ID;
- called TSAP-ID;
- TPDU size (proposed);
- version number;
- security parameter;
- checksum;
- additional option selection (i.e. use of network
expedited in class 1, use of receipt confirmation in
class 1, non-use of checksum in class 4, use of
transport expedited data transfer service);
- alternative protocol class(es);
- acknowledge time;
- throughput (proposed);
- residual error rate (proposed);
- priority (proposed);
- transit delay (proposed);
- reassignment time;
- user data.
b) CC TPDU;
- CDT;
- DST-REF;
33
- CLASS and OPTIONS (selected);
- calling TSAP-ID;
- called TSAP-ID;
- TPDU size (selected);
- security parameter;
- checksum;
- additional option selection (selected);
- acknowledge time;
- throughput (selected);
- residual error rate (selected);
- priority (selected);
- transit delay (selected);
- user data.
NOTE - The transport service defines transit delay as
requiring a previously stated average TSDU size as a basis
for any specification. This protocol, as specified in
13.3.4(n), uses a value of 128 octets. Conversion to and
from specifications based upon some other value is a local
matter.
A transport connection is established by means of one transport entity (the initiator) transmitting a CR TPDU to the other transport entity (the responder), which replies with a CC TPDU.
Before sending the CR TPDU, the initiator assigns the transport connection being created to one (or more if the splitting procedure is being use) network connection(s). It is this set of network connections over which the TPDUs are sent. During this exchange, all information and parameters needed for the transport entities to operate shall be exchanged or negotiated.
NOTE - Except in class 4, it is recommended that the initiator starts an optional timer TS1 at the time the CR TPDU is sent. This timer should be stopped when the
connection is considered as accepted or refused or
unsuccessful. If the timer expires, the initiator should
34
connection the procedures for reset or disconnect as
appropriate should be followed.
After receiving the CC TPDU for a class which includes the procedure for retention until acknowledgement of TPDUs the initiator shall acknowledge the CC TPDU as defined in table 5 (see 6.13).
When the network expedited variant of the expedited data transfer (see 6.11) has been agreed (possible in class 1 only), the responder shall not send an ED TPDU before the CC TPDU is acknowledged.
The following information is exchanged:
a) references. Each transport entity chooses a reference which is to be used by the peer entity is 16 bits long and which is arbitrary except for the following restrictions:
1) it shall not already be in use or frozen (see 6.18),
2) it shall not be zero.
This mechanism is symmetrical and provides identification of the transport connection independent of the network connection. The range of references used for transport connections, in a given transport entity, is a local matter.
b) addresses (optional). Indicate the calling and called transport service access points. When either network address unambiguously defines the transport address this information may be omitted.
c) initial credit. Only relevant for classes which include the explicit flow control function.
d) user data. Not available if Class 0 is the preferred class (see note). Up to 32 octets in other classes.
35
e) acknowledgement time. Only in class 4.
f) checksum parameter. Only in class 4.
g) security parameter. This parameter and its semantics are user defined.
The following negotiations take place:
h) protocol class. The initiator shall propose a preferred class and may propose any number of alternative class which permit a valid response as defined in table 3. The initiator should assume when it sends the CR TPDU that its preferred class will be agreed to, and commence the procedures associated with that class, except that if class 0 or class 1 is an alternative class, multiplexing shall not commence until a CC TPDU selecting the use of classes 2, 3 or 4 has been received.
NOTE - This means, for example, that when the preferred
class includes resynchronization (see 6.14) the
resynchronization will occur if a reset is signalled
during connection establishment.
The responder shall select one class defined in table 3 as a valid response corresponding to the preferred class and to the class(es), if any, contained in the alternative class parameter of the CR TPDU. It shall indicate the selected class in the CC TPDU and shall follow the procedures for the selected class.
If the preferred class is not selected, then on receipt of the CC TPDU the initiator shall adjust its operation according the procedures of the selected class.
36
| Pre- | Alternative class |
|ferred |----------------------------------------------------|
|class | 0 | 1 | 2 | 3 | 4 | none |
|-------|--------|--------|--------|--------|--------|-------|
| 0 |not |not |not |not |not |class |
| |valid |valid |valid |valid |valid | 0 |
|-------|--------|--------|--------|--------|--------|-------|
| 1 |class |class |not |not |not |class |
| |1 or 0 |1 or 0 |valid |valid |valid |1 or 0 |
|-------|--------|--------|--------|--------|--------|-------|
| 2 |class |not |class |not |not |class |
| |2 or 0 |valid |2 |valid |valid | 2 |
|-------|--------|--------|--------|--------|--------|-------|
| 3 |class |class 3,|class |class |not |class |
| |3,2 or 0|2,1 or 0|3 or 2 |3 or 2 |valid |3 or 2 |
|-------|--------|--------|--------|--------|--------|-------|
| 4 |class |class 4,|class |class |class |class |
| |4,2 or 0|2,1 or 0|4 or 2 |4,3 or 2|4 or 2 |4 or 2 |
+------------------------------------------------------------+
Table 3.
Valid responses corresponding to the preferred class and any alternative class proposed in the CR TPDU
NOTES:
a) if class 3 or 4 is proposed then class 2 is a valid
response;
b) if class 1 is proposed then class 0 is a valid
response.
37
j) TPDU size. The initiator may propose a maximum size for TPDUs, and the responder may accept this value or respond with any value between 128 and the proposed value in the set of values available (see 13.3.4.b).
NOTE - The length of the CR TPDU does not exceed 128 octets (see 13.3).
k) normal or extended format. Either normal or extended is available. When extended is used this applies to CDT, TPDU-NR, ED-TPDU-NR, YR-TU-NR and YR-EDTU-NR parameters.
m) checksum selection. This defines whether or not TPDUs of the connection are to include a checksum.
n) quality of service parameters. This defines the
throughput, transit delay, priority and residual error
rate.
p) the non-use of explicit flow control in class 2.
q) the use of network receipt confirmation and network expedited when class 1 is to be used.
r) use of expedited data transfer service. This allows both TS-users to negotiate the use or non-use of the expedited data transport service as defined in the transport service (ISO 8072).
The following information is sent only in the CR TPDU:
s) version number. This defines the version of the transport protocol standard used for this connection.
t) reassignment time parameter. This indicates the time for
which the initiator will persist in following the
reassignment after failure procedure.
38
In class 2, whenever a transport entity requests or agrees to the transport expedited data transfer service or to the use of extended formats, it shall also request or agree (respectively) to the use of explicit flow control.
+-------------------------------------------------------------+
| Option | Proposal Made | Valid Selection |
| | by the Initiator | by the Responder |
|-----------------------|------------------|------------------|
|Transport expedited | Yes | Yes or No |
|data transfer service | No | No |
|(Classes 1,2,3,4 only) | | |
|-----------------------|------------------|------------------|
|Use of receipt confir- | Yes | Yes or No |
|mation (Class 1 only) | No | No |
|-----------------------|------------------|------------------|
|Use of the network | Yes | Yes or No |
|expedited variant | No | No |
|(Class 1 only) | | |
|-----------------------|------------------|------------------|
|Non-use of checksum | Yes | Yes or No |
|(Class 4 only) | No | No |
|-----------------------|------------------|------------------|
|Non-use of explicit | Yes | Yes or No |
|flow control | No | No |
|(Class 2 only) | | |
|-----------------------|------------------|------------------|
|Use of extended format | Yes | Yes or No |
|(Classes 2,3,4 only) | No | No |
+-------------------------------------------------------------+
Table 4. Negotiation of options during connection establishment
39
transport connection except for the use of the transport
expedited data transfer service which may be rejected by the TS-
user. If the initiator proposes a non-mandatory implementation
option, the responder is entitled to select use of the mandatory
implementation option for use over the transport connection.
The connection refusal procedure is used in all classes when a transport entity refuses a transport connection in response to a CR TPDU.
The procedure makes use of the following TPDUs and parameters:
a) DR TPDU;
- SRC-REF;
- reason;
- user data.
b) ER TPDU;
- reject code;
- rejected TPDU parameter.
40
If a DR TPDU is received the initiator shall regard the connection as released.
The responder shall respond to an invalid CR TPDU by sending an ER or DR TPDU. If an ER TPDU is received in response to a CR TPDU, the initiator shall regard the connection as released.
NOTES
The release procedure is used by a transport entity in order to terminate a transport connection. The implicit variant is used only in class 0. The explicit variant is used in classes 1,2,3 and 4.
41
The procedure makes use of the following network service
primitives:
a) N-DISCONNECT (implicit variant only),
b) N-DATA
The procedure makes use of the following TPDUs and parameters:
a) DR TPDU;
- clearing reason;
- user data;
- SRC-REF;
- DST-REF.
b) DC TPDU.
42
When the release of a transport connection is to be initiated a transport entity
a) if it has previously sent or received a CC TPDU (see note
1), shall send a DR TPDU. It shall ignore all
subsequently received TPDUs other than a DR or DC TPDU.
On receipt of a DR or DC TPDU it shall consider the
transport connection released;
b) in other cases it shall:
1) For classes other than class 4 wait for the
acknowledgement of the outstanding CR TPDU; if it
receives a CC TPDU, it shall follow the procedures in
6.7.5.a.
2) For class 4 either send a DR TPDU with a zero value in
the DST-REF field or follow the procedure in
6.7.5.b.1.
A transport entity that receives a DR TPDU shall
c) if it has previously sent a DR TPDU for the same transport connection, consider the transport connection released;
d) if it has previously sent a CR TPDU that has not been acknowledged by a CC TPDU, consider the connection refused (see 6.6).
43
NOTES
1) This requirement ensures that the transport entity is
aware of the remote reference for the transport
connection.
2) When the transport connection is considered as released the local reference is either available for re-use or is frozen (see 6.18).
3) After the release of a transport connection the network connection can be released or retained to enable its re- use for the assignment of other transport connections (see 6.1.).
4) Except in class 4, it is recommended that, if a transport entity does not receive acknowledgement of a DR TPDU within time TS2, it should either reset or disconnect the
network connection, and freeze the reference when
appropriate (see 6.18). For all other transport
connection(s) multiplexed on this network connection the
procedures for reset or disconnect as appropriate should
be followed.
5) When a transport entity is waiting for a CC TPDU before sending a DR TPDU and the network connection is reset or released, it should consider the transport connection released and, in classes other than classes 0 and 2, freeze the reference (see 6.18).
44
The procedure makes use of the following service primitives:
a) N-DISCONNECT indication;
b) N-RESET indication.
When, on the network connection to which a transport connection is assigned, an N-DISCONNECT or N-RESET indication is received,
both transport entities shall consider that the transport
connection is released and so inform the TS-users.
NOTE - In other classes, since error recovery is used, the receipt of an N-RESET indication or N-DISCONNECT indication will result in the invocation of the error recovery procedure.
This procedure is used in all classes to interpret a received NSDU as TPDU(s) and, if possible, to associate each such TPDU with a transport connection.
45
a) N-DATA indication;
b) N-EXPEDITED DATA indication.
This procedure makes use of the following TPDUs and parameters:
a) any TPDU except CR TPDU, DT TPDU in classes 0 or 1 and AK TPDU in class 1;
- DST-REF
b) CR, CC, DR and DC TPDUs;
- SCR-REF.
c) DT TPDU in classes 0 or 1 and AK TPDU in class 1.
If the received NSDU or Expedited NSDU cannot be decoded (i.e. does not contain one or more correct TPDUs) or is corrupted (i.e. contains a TPDU with a wrong checksum) then the transport entity shall:
46
b) otherwise
1) if the NSDU can be decoded but contains corrupted TPDUs, ignore the TPDUs (class 4 only) and optionally apply 6.9.4.b.2.
2) if the NSDU cannot be decoded issue an N-RESET or N- DISCONNECT request for the network connection and for all the transport connections assigned to this network connection (if any), apply the procedures defined for handling of network signalled reset or disconnect.
If the NSDU can be decoded and is not corrupted, the transport entity shall:
c) if the network connection on which the NSDU was received has a class 0 transport connection assigned to it, then consider the NSDU as forming TPDU and associate the TPDU with the transport connection (see 6.9.4.2).
d) otherwise, invoke the separation procedures and for each of the individual TPDUs in the order in which they appear in the NSDU apply the procedure defined in 6.9.4.2.
If the received TPDU is a CR TPDU then, if it is a duplicate, as recognized by using the NSAPs of the network connection, and the SRC-REF parameter, then it is associated with the transport connection created by the original value of the CR TPDU; otherwise it is processed as requesting the creation of a new transport connection.
If the received TPDU is a DT TPDU and the network connection has a class 0 or 1 transport connection assigned to it, or an AK TPDU
47
Otherwise, the DST-REF parameter of the TPDU is used to identify the transport connection. The following cases are distinguished:
a) if the DST-REF is not allocated to a transport connection, the transport entity shall respond on the same network connection with a DR TPDU if the TPDU is a CC TPDU, with a DC TPDU if the TPDU is a DR TPDU and shall ignore the TPDU if neither a DR TPDU nor CC TPDU. No association with a transport connection is made.
b) if the DST-REF is allocated to a connection, but the TPDU
is received on a network connection to which the
connection has not been assigned then there are three
cases:
1) if the transport connection is of class 4 and if the TPDU is received on a network connection with the same pair of NSAPs as that of the CR TPDU then the TPDU is considered as performing assignment,
2) if the transport connection is not assigned to any network connection (waiting for reassignment after failure) and if the TPDU is received on a network connection with the same pair of NSAPs as that of the CR TPDU then the association with that transport connection is made.
3) Otherwise, the TPDU is considered as having a DST-REF not allocated to a transport connection (case a).
c) If the TPDU is a DC TPDU then it is associated with the transport connection to which the DST-REF is allocated, unless the SRC-REF is not the expected one, in which case the DC TPDU is ignored.
d) If the TPDU is a DR TPDU then there are three cases:
1) if the SRC-REF is not as expected then a DC TPDU with DST-REF equal to the SRC-REF of the received DR TPDU is sent back and no association is made;
48
3) otherwise, the DR TPDU is associated with the
transport connection identified by the DST-REF
parameter.
e) if the TPDU is a CC TPDU whose DST-REF parameter
identifies an open connection (one for which a CC TPDU has
been previously received), and the SRC-REF in the CC TPDU
does not match the remote reference, then a DR TPDU is
sent back with DST-REF equal to the SRC-REF of the
received CC TPDU and no association is made.
f) if none of the above cases apply then the TPDU is associated with the transport connection identified by the DST-REF parameter.
Data TPDU numbering is used in classes 1, 2 (except when the non-use of explicit flow control option is selected), 3 and 4. Its purpose is to enable the use of recovery, flow control and re-sequencing functions.
The procedure makes use of the following TPDU and parameter:
DT TPDU;
- TPDU-NR.
49
When a DT TPDU is retransmitted, the TPDU-NR parameter shall have the same value as in the first transmission of that DT TPDU.
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. In this International Standard the relationships 'greater than' and 'less than' apply to a set of contiguous TPDU numbers whose range is less than the modulus and whose starting and finishing numbers are known. The term 'less than' means 'occurring sooner in the window sequence' and the term 'greater than' means 'occurring later in the window sequence'.
Expedited data transfer procedures are selected during connection establishment. The network normal data variant may be used in classes 1, 2, 3 and 4. The network expedited variant is only used in class 1.
The procedure makes use of the following network service
primitives:
a) N-DATA;
50
The procedure makes use of the following TPDUs and parameters:
a) ED TPDU;
- ED TPDU-NR.
b) EA TPDU;
- YR-EDTU-NR.
The TS-user data parameter of each T-EXPEDITED DATA request shall be conveyed as the data field of an Expedited Data (ED) TPDU.
Each ED TPDU received shall be acknowledged by an Expedited Acknowledge (EA) TPDU.
No more than one ED TPDU shall remain unacknowledged at any time for each direction of a transport connection.
An ED TPDU with a zero length data field is a protocol error.
51
The reassignment after failure procedure is used in Classes 1 and 3 to commence recovery from an NS-provider signalled disconnect.
The procedure uses the following network service primitive:
N-DISCONNECT indication
When an N-DISCONNECT indication is received from the network connection to which a transport connection is assigned, the initiator shall apply one of the following alternatives:
a) if the TTR timer has not already run out and no DR TPDU is retained then:
52
2) while waiting for the completion of assignment if:
- an N-DISCONNECT indication is received, repeat the
procedure from 6.12.3.a,
- the TTR timer expires, begin procedure 6.12.3.b.
3) when reassignment is completed, begin
resynchronization (see 6.14) and:
- if a valid TPDU is received as the result of the
resynchronization, stop the TTR timer, or
- if TTR runs out, wait for the next event, or
- if an N-DISCONNECT indication is received, then
begin either procedure 6.12.3.a or 6.12.3.b
depending on the TTR timer.
NOTE - After the TTR timer expires and while waiting for the next event, it is recommended that the initiator starts the TWR timer. If the TWR timer expires before the next event the initiator should begin the procedure in 6.12.3.b.
b) if the TTR timer has run out, consider the transport connection as released and freeze the reference (see 6.18).
c) if a DR TPDU is retained and the TTR timer has not run
out, then follow the actions in either 6.12.3.a or
6.12.3.b.
The responder shall start its TWR timer if not already started. The arrival of the first TPDU related to the transport connection (because of resynchronization by the initiator) completes the reassignment after failure procedure. The TWR timer is stopped and the responder shall continue with resynchronization (see 6.14). If reassignment does not take place within this time, the
53
The reassignment after failure procedure uses two timers:
a) TTR, the time to try reassignment/resynchronization timer;
b) TWR, the time to wait for reassignment/resynchronization timer.
The TTR timer is used by the initiator. Its value shall not exceed two minutes minus the sum of the maximum disconnect
propagation delay and the transit delay of the network
connections (see note 1). The value for the TTR timer may be
indicated in the CR TPDU.
The TWR timer is used by the responder. If the reassignment time parameter is present in the CR TPDU, the TWR timer value shall be greater than the sum of the TTR timer plus the maximum disconnect
propagation delay plus the transit delay of the network
connections.
If the reassignment time parameter is not present in the CR TPDU, a default value of 2 minutes shall be used for the TWR timer.
NOTES
3. If the optional TS1 and TS2 timers are used, it is
recommended:
54
b) to restart TS1 or TS2 if necessary when the
corresponding TPDU (CR TPDU or DR TPDU respectively is
repeated);
c) to select for TS1 and TS2 values greater than TTR.
55
The retention until acknowledgement of TPDUs procedure is used in classes 1, 3 and 4 to enable and minimize retransmission after possible loss of TPDUs.
The confirmation of receipt variant is used only in Class 1 when it has been agreed during connection establishment (see note).
The AK variant is used in classes 3 and 4 and also in Class 1 when the confirmation of receipt variant has not been agreed during connection establishment.
NOTE - Use of confirmation of receipt variant depends on the availability of the network layer receipt confirmation service and the expected cost reduction.
The procedure uses the following network service primitives:
a) N-DATA;
b) N-DATA ACKNOWLEDGE.
The procedure uses the following TPDUs and parameters:
a) CR, CC, DR and DC TPDUs;
b) RJ and AK TPDUs;
- YR-TU-NR.
56
- TPDU-NR.
d) ED TPDU;
- ED-TPDU-NR.
e) EA TPDU;
- YR-EDTU-NR.
Copies of the following TPDUs shall be retained upon transmission to permit their later retransmission:
CR, CC, DR, DT and ED TPDUs
except that if a DR is sent in response to a CR TPDU there is no need to retain a copy of the DR TPDU.
In the confirmation of receipt variant, applicable only in Class 1, transport entities receiving N-DATA indications which convey DT TPDUs and have the confirmation request field set shall issue an N-DATA ACKNOWLEDGE request (see notes 1 and 2).
After each TPDU is acknowledged, as shown in table 5, the copy need not be retained. Copies may also be discarded when the transport connection is released.
57
58
|RETAINED| | |
| TPDU | VARIANT | RETAINED UNTIL ACKNOWLEDGED BY |
|--------|--------------|-------------------------------------|
| CR | both |CC, DR or ER TPDU. |
| | | |
| DR | both |DC or DR (in case of collision) TPDU.|
| | | |
| CC | confirmation |N-DATA Acknowledge indication, RJ, |
| | of receipt |DT, EA or ED TPDU. |
| | variant | |
| | | |
| CC | AK variant |RJ, DT, AK, ED or EA TPDU. |
| | | |
| DT | confirmation |N-DATA ACKNOWLEDGE indication cor- |
| | of receipt |responding to an N-DATA request which|
| | variant |conveyed, or came after, the DT TPDU.|
| | | |
| DT | AK variant |AK or RJ TPDU for which the YR-TU-NR |
| | |is greater than TPDU-NR in the DT |
| | |TPDU. |
| | | |
| ED | both |EA TPDU for which the YR-EDTU-NR is |
| | |equal to the ED-TPDU-NR in the |
| | |ED TPDU. |
+-------------------------------------------------------------+
Table 5. Acknowledgement of TPDUs
59
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.
The procedure makes use of the following network service
primitive:
N-RESET indication.
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.
60
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.
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.
61
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
network connection with the appropriate network
addresses and having a correct source reference.
62
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.
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;
63
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.
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.
The procedure makes use of the following TPDUs and parameters:
CC, DR, DC, DT, AK, ED, EA, RJ and ER TPDUs
- DST-REF
64
NOTES
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.
The procedure makes use of the following TPDUs and parameters:
a) CR, CC, AK and RJ TPDUs
- CDT.
b) DT TPDU
- TPDU-NR.
65
- YR-TU-NR;
- subsequence number;
- flow control confirmation.
d) RJ TPDU
- YR-TU-NR.
The procedures differ in different classes. They are defined in the clauses specifying the separate classes.
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.
The procedure uses the following TPDUs and parameters:
All TPDUs
- checksum
66
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.
67
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.
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).
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
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
69
The procedure is used in Class 4 to cope with unsignalled loss of TPDUs by the NS-provider.
The procedure makes use of the following TPDUs:
CR, CC, DR, DT, ED, AK TPDUs.
The procedure is specified in the procedures for Class 4 (see 12.2.1.2.j).
70
The procedure uses the following TPDUs and parameters:
a) DT TPDU;
- TPDU-NR.
b) ED TPDU
- ED TPDU-NR
The procedure is specified in the procedures for Class 4 (see 12.2.3.5).
The inactivity control procedure is used in Class 4 to cope with unsignalled termination of a network connection.
71
The procedure for treatment of protocol errors is used in all classes to deal with invalid TPDUs.
The procedure uses the following TPDUs and parameters:
a) ER TPDU;
- reject cause;
- TPDU in error.
b) DR TPDU;
- reason code.
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
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
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.
73
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.
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
74
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
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
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.
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).
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
d) the CR and CC TPDUs shall not contain a data field.
The transport entities shall use the segmenting and reassembling procedure (see 6.3).
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
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.
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
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.
network layer receipt confirmation service, and the
expected cost reduction.
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).
The sending transport entity shall use the following procedures;
a) segmenting (see 6.3); then
82
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
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
83
The transport entities shall use the explicit variant of the release procedure (see 6.7).
84
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.
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
a) assignment to network connection (see 6.1); then
b) connection establishment (see 6.5) and, if applicable connection refusal (see 6.6).
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).
has been selected
The sending transport entity shall use the following procedures:
a) segmenting (see 6.3); then
b) DT TPDU numbering (see 6.10);
86
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.
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 shall not send a DT TPDU with a TPDU-NR outside of the transmit window (see notes 2 and 3).
NOTES
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
89
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.
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
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).
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
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.
92
window edge allocated to the peer entity (credit
reduction).
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.
by the AK TPDU. In either case, copies of the
acknowledged DT TPDUs, need not be retained further.
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
NOTES
The transport entities shall use the explicit variant of the release procedure in 6.7.
94
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.
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
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
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.
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
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
2. The relationships between times discussed above are
illustrated in figures 3 and 4.
[Figures 3 and 4 are omitted from this copy.]
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
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
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.
There are no timers specific to connection establishment.
102
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
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.
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
f) DT TPDU numbering (see 6.10);
g) resequencing (see 6.20);
h) reassembling (see 6.3).
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.
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
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.
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
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.
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.
107
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.
108
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.
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
109
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.
110
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
111
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)
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.
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.
112
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).
There are no timers used only for release.
The transport entity shall use the explicit variant of normal release (see 6.7).
113
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.
114
| | 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
115
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 ------>
116
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.
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).
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:
117
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.
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 | |
+------------------------------------|
118
- 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.
119
Parameter Code: 1100 0011
Parameter Length: 2
Parameter Value: Result of checksum algorithm. This algorithm
is specified in 6.17.
This field contains transparent user data. Restrictions on its size are noted for each TPDU.
The length of the CR TPDU shall not exceed 128 octets.
The structure of the CR TPDU shall be as follows:
1 2 3 4 5 6 7 8 p p+1...end
+--+------+---------+---------+---+---+------+-------+---------+
|LI|CR CDT| DST - REF |SRC-REF|CLASS |VARIAB.|USER |
| |1110 |0000 0000|0000 0000| | |OPTION|PART |DATA |
+--+------+---------+---------+---+---+------+-------+---------+
120
The structure of this part shall contain:
a) CR : Connection Request Code: 1110. Bits 8-5 of
octet 2;
b) CDT : Initial Credit Allocation (set to 0000 in
Classes 0 and 1 when specified as preferred
class). Bits 4-1 of octet 2;
c) DST-REF : Set to zero;
d) SRC-REF : Reference selected by the transport entity
initiating the CR TPDU to identify the
requested transport connection;
e) CLASS and Bits 8-5 of octet 7 defines the preferred
OPTION: transport protocol class to be operated over
the requested transport connection. This
field shall take one of the following values:
0000 Class 0
0001 Class 1
0010 Class 2
0011 Class 3
0100 Class 4
The CR TPDU contains the first choice of class in the fixed part. Second and subsequent choices are listed in the variable part if required.
Bits 4-1 of octet 7 define options to be used on the requested transport connection as follows:
121
| BIT | OPTION |
|-----|-----------------------------------------------|
| 4 | 0 always |
| | |
| 3 | 0 always |
| | |
| 2 | =0 use of normal formats in all classes |
| | =1 use of extended formats in Classes 2,3,4 |
| | |
| 1 | =0 use of explicit flow control in Class 2 |
| | =1 no use of explicit flow control in |
| | Class 2 |
+-----------------------------------------------------+
NOTES
The following parameters are permitted in the variable part:
a) Transport Service Access Point Identifier (TSAP-ID)
Parameter code: 1100 0001 for the identifier of the
Calling TSAP.
1100 0010 for the identifier of the
Called TSAP
Parameter length: not defined in this standard
Parameter value: identifier of the calling or called
TSAP respectively.
122
b) TPDU size
This parameter defines the proposed maximum TPDU size (in octets including the header) to be used over the requested transport connection. The coding of this parameter is:
Parameter code: 1100 0000
Parameter Length: 1 octet
Parameter value:
0000 1101 8192 octets (not allowed in Class 0)
0000 1100 4096 octets (not allowed in Class 0)
0000 1011 2048 octets
0000 1010 1024 octets
0000 1001 512 octets
0000 1000 256 octets
0000 0111 128 octets
Default value is 0000 0111 (128 octets)
c) Version Number (not used if Class 0 is the preferred class)
Parameter code: 1100 0100
Parameter length: 1 octet
Parameter value field: 0000 0001
Default value is 0000 0001 (not used in Class 0)
d) Security Parameters (not used if Class 0 is the preferred class)
This parameter is user defined.
Parameter code: 1100 0101
Parameter length: user defined
Parameter value: user defined
e) Checksum (used only if class 4 is the preferred class) (see 13.2.3.1)
123
requesting Class 4, even if the checksum selection
parameter is used to request non-use of the checksum
facility.
f) Additional Option Selection (not used if Class 0 is the preferred class)
This parameter defines the selection to be made as to whether or not additional options are to be used.
Parameter code: 1100 0110
Parameter length: 1
Parameter value:
+------------------------------------------------------+
|BIT| OPTION |
|---|--------------------------------------------------|
| 4 | 1= Use of network expedited in Class 1 |
| | 0= Non use of network expedited in Class 1 |
| | |
| 3 | 1= Use of receipt confirmation in Class 1 |
| | 0= Use of explicit AK variant in Class 1 |
| | |
| 2 | 0= 16-bit checksum defined in 6.17 is to be used|
| | in Class 4 |
| | 1= 16-bit checksum defined in 6.17 is not to be |
| | used on Class 4 |
| | |
| 1 | 1= Use of transport expedited data transfer |
| | service |
| | 0= No use of transport expedited data transfer |
| | service |
+------------------------------------------------------+
Default value is 000 0001
Bits related to options particular to a class are not meaningful if that class is not proposed and may take any value.
124
Parameter code: 1100 0111
Parameter length: n
Parameter value encoded as a sequence of single octets. Each octet is encoded as for octet 7 but with bits 4-1 set to zero (i.e. no alternative option selections permitted).
h) Acknowledge Time (used only if class 4 is the preferred class)
This parameter conveys the maximum acknowledge time AL to the remote transport entity. It is an indication only, and is not subject to negotiation (see 12.2.1.1.3)
Parameter code: 1000 0101
Parameter length: 2
Parameter value: n, a binary number where n is the
maximum acknowledge time, expressed
in milliseconds.
j) Throughput (not used if class 0 is the preferred class)
Parameter code: 1000 1001
Parameter length: 12 or 24
Parameter value:
1st 12 Octets: maximum throughput, as follows:
1st 3 octets: Target value, calling-called user
direction
2nd 3 octets: Min. acceptable, calling-called user
direction
3rd 3 octets: Target value, called-calling user
direction
4th 3 octets: Min. acceptable, called-calling user
direction
2nd 12 octets (optional): average throughput, as follows:
5th 3 octets: Target value, calling-called user
direction
125
direction
7th 3 octets: Target value, called-calling user
direction
8th 3 octets: Min. acceptable, called-calling user
direction
Where the average throughput is omitted, it is considered to have the same value as the maximum throughput.
Values are expressed in octets per second.
k) Residual error rate (not used if class 0 is the preferred class)
Parameter code: 1000 1001
Parameter length: 12
1st 3 octets: Target value, calling-called user
direction
2nd 3 octets: Min. acceptable, calling-called user
direction
3rd 3 octets: Target value, called-calling user
direction
4th 3 octets: Min. acceptable, called-calling user
direction
l) Residual error rate (not used if class 0 is the preferred class)
Parameter code: 1000 0110
Parameter length: 3
Parameter value:
1st octet: Target value, power of 10
2nd octet: Min. acceptable, power of 10
3rd octet: TSDU size of interest, expressed as a
power of 2
m) Priority (not used if class 0 is the preferred class)
Parameter code: 1000 0111
Parameter length: 2
Parameter value: Integer (0 is the highest priority)
126
Parameter code: 1000 1000
Parameter length: 8
Parameter value:
1st 2 octets: Target value, calling-called user
direction
2nd 2 octets: Max. acceptable, calling-called user
direction
3rd 2 octets: Target value, called-calling user
direction
4th 2 octets: Max. acceptable, called-calling user
direction
Values are expressed in milliseconds, and are based upon a TSDU size of 128 octets.
p) assignment time (not used if class 0, 2 or class 4 is the preferred class)
This parameter conveys the Time to Try Reassignment (TTR) which will be used when following the procedure for Reassignment after Failure (see 6.12).
Parameter code: 1000 1011
Parameter length: 2
Parameter value: n, a binary number where n is the TTR
value expressed in seconds.
No user data are permitted in Class 0, and are optional in the other classes. Where permitted, it may not exceed 32 octets.
127
The structure of the CC TPDU shall be as follows:
1 2 3 4 5 6 7 8 p p+1 ...end
+---+----+---+---+---+---+---+-------+--------+-------------+
|LI | CC CDT|DST-REF|SRC-REF| CLASS |VARIABLE| USER |
| |1101| | | | | | OPTION| PART | DATA |
+---+----+---+---+---+---+---+-------+--------+-------------+
See 13.2.1
The fixed part shall contain:
a) CC: Connection Confirm Code: 1101. Bits 8-5 of octet 2;
b) CDT: Initial Credit Allocation (set to 0000 in Classes 0 and 1). Bits 4-1 of octet 2;
c) DST-REF: Reference identifying the requested transport connection at the remote transport entity;
d) SRC-REF: Reference identifying the requested transport connection at the remote transport entity.
e) Class and Option: Defines the selected transport protocol
class and option to be operated over the accepted
transport connection according to the negotiation rules
specified in 6.5;
128
No user data are permitted in class 0, and are optional in the other classes. Where permitted, it may not exceed 32 octets. The user data are subject to the constraints of the negotiation rules (see 6.5).
The structure of the DR TPDU shall be as follows:
1 2 3 4 5 6 7 8 p p+1 ...end
+--+---------+----+-----+----+-----+------+--------+----------+
|LI| DR | DST-REF. | SRC-REF. |REASON|VARIABLE| USER |
| |1000 0001| | | | | | PART | DATA |
+--+---------+----+-----+----+-----+------+--------+----------+
See Section 13.2.1
129
a) DR: Disconnect Request Code: 1000 0000;
b) DST-REF: Reference identifying the transport connection at the remote transport entity;
c) SRC-REF: Reference identifying the transport connection at the transport entity initiating the TPDU. Value zero when reference is unassigned;
d) REASON: Defines the reason for disconnecting the
transport connection. This field shall take one of the
following values:
The following values may be used for Classes 1 to 4:
1) 128 + 0 - Normal disconnect initiated by session
entity
2) 128 + 1 - Remote transport entity congestion at
connect request time
3) *128 + 2 - Connection negotiation failed (i.e. proposed
class(es) not supported)
4) 128 + 3 - Duplicate source reference detected for the
same pair of NSAPS.
5) 128 + 4 - Mismatched references
6) 128 + 5 - Protocol error
7) 128 + 6 - Not used
8) 128 + 7 - Reference overflow
9) 128 + 8 - Connection request refused on this network
connection
10) 128 + 9 - Not used
11) 128 + 10- Header or parameter length invalid
130
12) 0 - Reason not specified
13) 1 - Congestion at TSAP
14) *2 - Session entity not attached to TSAP
15) *3 - Address unknown
NOTE - Reasons marked with an asterisk (*) may be reported to the TS-user as persistent, other reasons as transient.
The variable part may contain
a) A parameter allowing additional information related to the clearing of the connection.
Parameter code: 1110 0000
Parameter length: Any value provided that the length of
the DR TPDU does not exceed the maximum
agreed TPDU size or 128 when the DR
TPDU is used during the connection
refusal procedure
Parameter value: Additional information. The content of
this field is user defined.
b) Checksum (see 13.2.3.1)
This field shall not exceed 64 octets and is used to carry TS-
user data. The successful transfer of this data is not
guaranteed by the transport protocol. When a DR TPDU is used in
Class 0 it shall not contain this field.
131
The structure of DC TPDU shall be as follows:
1 2 3 4 5 6 7 p
+----+-----------+-----+-----+-----+-----+-------+--------+
| LI | DC | DST REF | SRC REF | Variable Part |
| | 1100 0000 | | | | | | |
+----+-----------+-----+-----+-----+-----+-------+--------+
See 13.2.1
The fixed part shall contain:
a) DC: Disconnect Confirm Code: 1100 0000;
b) DST-REF: See 13.4.3;
c) SRC-REF: See 13.4.3.
132
Depending on the class and the option the DT TPDU shall have one of the following structures.
a) Normal format for Classes 0 and 1
1 2 3 4 5 ... end
+----+-----------+-----------+------------ - - - - - -------+
| LI | DT | TPDU-NR | User Data |
| | 1111 0000 | and EOT | |
+----+-----------+-----------+------------ - - - - - -------+
b) Normal format for Classes 2, 3 and 4
1 2 3 4 5 6 p p+1 ... end
+----+---------+---+---+-------+-----+-------+----------- - - -+
| LI | DT |DST-REF|TPDU-NR|Variable Part|User Data |
| |1111 0000| | |and EOT| | | |
+----+---------+---+---+-------+-----+-------+----------- - - -+
c) Extended Format for use in Classes 2, 3 and 4 when selected during connection establishment.
1 2 3 4 5,6 7,8 9 p p+1 ... end
+----+---------+---+---+---------+--------+---------- - - -+
| LI | DT |DST-REF| TPDU-NR |Variable|User Data |
| |1111 0000| | | and EOT | Part | |
+----+---------+---+---+---------+--------+---------- - - -+
133
The fixed part shall contain:
a) DT: Data Transfer Code: 1111 0000;
b) DST-REF: See 13.4.3;
c) EOT: When set to ONE, indicates that the current DT
TPDU is the last data unit of a complete DT TPDU
sequence (End of TSDU). EOT is bit 8 of octet 3
in class 0 and 1, bit 8 of octet 5 for normal
formats for classes 2, 3 and 4 and bit 8 of
octet 8 for extended formats;
d) TPDU-NR: TPDU send Sequence Number (zero in Class 0). May take any value in Class 2 without explicit flow control. TPDU-NR is bits 7-1 of octet 3 for classes 0 and 1, bits 7-1 of octet 5 for normal formats in classes 2, 3 and 4, octets 5, 6 and 7 together with bits 7-1 of octet 8 for extended formats.
NOTE - Depending on the class, the fixed part of the DT TPDU uses the following octets:
Classes 0 and 1: Octets 2 to 3;
Classes 2,3,4 normal format: Octets 2 to 5;
Classes 2,3,4 extended format: Octets 2 to 8.
134
This field contains data of the TSDU being transmitted.
NOTE - The length of this field is limited to the negotiated TPDU size for this transport connection minus 3 octets in Classes 0 and 1, and minus 5 octets (normal header format) or 8 octets (extended header format) in the other classes. The variable part, if present, may further reduce the size of the user data field.
The ED TPDU shall not be used in Class 0 or in Class 2 when the no explicit flow control option is selected or when the expedited data transfer service has not been selected for the connection.
Depending on the format negotiated at connection establishment the ED TPDU shall have one of the following structures:
135
1 2 3 4 5 6 p p+1 ... end
+--+---------+---+---+---------+-----+-------+---------------+
|LI| ED |DST-REF|EDTPDU-NR|Variable Part|User Data |
| |0001 0000| | |and EOT | | | |
+--+---------+---+---+---------+-----+-------+---------------+
b) Extended Format (for use in classes 2, 3, 4 when selected during connection establishment).
1 2 3 4 5,6,7,8 9 p p+1 ... end
+--+---------+---+---+---------+-----+-------+---------------+
|LI| ED |DST-REF|EDTPDU-NR|Variable Part|User Data |
| |0001 0000| | |and EOT | | | |
+--+---------+---+---+---------+-----+-------+---------------+
See 13.2.1
The fixed part shall contain:
a) ED: Expedited Data code: 0001 0000;
b) DST-REF: see 13.4.3;
c) ED-TPDU-NR: Expedited TPDU identification number. ED- TPDU-NR is used in classes 1, 3 and 4 and may take any value in Class 2. Bits 7-1 of octet 5 for normal formats and octets 5, 6 and 7
together with bits 7-1 of octet 8 for
extended formats;
136
for normal formats and bit 8 of octet 8 for
extended formats).
NOTE - Depending on the format the fixed part shall be either octets 2 to 5 or 2 to 8.
The variable part shall contain the checksum parameter if the condition defined in 13.2.3.1 applies.
This field contains an expedited TSDU (1 to 16 octets).
This TPDU shall not be used for Class 0 and Class 2 when the "no explicit flow control" option is selected, and for Class 1 when the network receipt confirmation option is selected.
Depending on the class and option agreed the AK TPDU shall have one of the following structures:
137
1 2 3 4 5 6 p
+--+--------+----------+------------+---------------+
|LI| AK CDT | DST-REF | YR-TU-NR | Variable Part |
| | 0110 | | | |
+--+--------+----------+------------+---------------+
b) Extended Format (for use in classes 2, 3, 4 when selected during connection establishment).
1 2 3 4 5,6,7,8 9,10 11 p
+--+---------+---------+----------+-----+--------+
|LI| AK | DST-REF | YR-TU-NR | CDT |Variable|
| |0110 0000| | | | Part |
+--+---------+---------+----------+-----+--------+
See 13.2.1
The fixed part shall contain (in octet 2 to 5 when normal format is used, 2 to 10 otherwise) the following parameters:
a) AK: Acknowledgement code: 0110;
b) CDT: Credit Value (set to 1111 in class 1). Bits
4-1 of octet 2 for normal formats and octets 9
and 10 for extended formats;
c) DST-REF: See 13.4.3;
d) YR-TU-NR: Sequence number indicating the next expected DT TPDU number. For normal formats, bits 7-1 of octet 5; bit 8 of octet 5 is not significant
138
The variable part contains the following parameters:
a) Checksum See 13.2.3.1 if the condition in 13.2.3.1
applies;
b) Subsequence number when optionally used under the
conditions defined in class 4. This parameter is used to
ensure that AK TPDUs are processed in the correct
sequence. If it is absent, this is equivalent to
transmitting the parameter with a value of zero.
Parameter code: 1000 1010
Parameter length: 2
Parameter value: 16-bit sub-sequence number;
c) Flow Control Confirmation Class 4 when optionally used under the conditions defined in class 4. This parameter contains a copy of the information received in an AK TPDU, to allow the transmitter of the AK TPDU to be certain of
the state of the receiving transport entity (see
12.2.3.10).
Parameter code: 1000 1011
Parameter length: 8
Parameter value: defined as follows
139
This TPDU shall not be used for Class 0 and Class 2 when the no explicit flow control option is selected.
Depending on the option (normal or extended format) the TPDU structure shall be:
a) Normal Format (classes 1,2,3,4)
1 2 3 4 5 6 p
+--+---------+---------+----------+------+------+
|LI| EA | DST-REF | YR-TU-NR |Variable Part|
| |0010 0000| | | | |
+--+---------+---------+----------+------+------+
b) Extended Format (for use in classes 2, 3, 4 if selected during connection establishment)
1 2 3 4 5,6,7,8 9 p
+--+---------+---------+----------+------+------+
|LI| EA | DST-REF | YR-TU-NR |Variable Part|
| |0010 0000| | | | |
+--+---------+---------+----------+------+------+
140
The fixed part shall contain (in octets 2 to 5 when normal format is used, in octets 2 to 8 otherwise):
a) EA: Expedited Acknowledgement code: 0010 0000;
b) DST-REF: See 13.4.3;
c) YR-EDTU-NR: Identification of the ED TPDU being
acknowledged. May take any value in Class 2;
For normal formats bits 7-1 of octet 5; bit 8 of octet 5 is not significant and shall take the value 0. For extended formats, octets 5,6 and 7 together with bits 7-1 of octet 8; bit 8 of octet 8 is not significant and shall take the value 0.
The variable part may contain the checksum parameter (see 13.2.3.1).
The RJ TPDU shall not be used in Classes 0, 2 and 4.
141
a) Normal Format (classes 1 and 3)
1 2 3 4 5
+----+----------+----+----+------------+
| LI | RJ CDT | DST-REF | YR-TU-NR |
| | 0101 | | | |
+----+----------+----+----+------------+
b) Extended Format (for use in classes 3 if selected during connection establishment).
1 2 3 4 5,6,7,8 9,10
+--+-----------+----+----+----------+-----+
|LI| RJ | DST-REF | YR-TU-NR | CDT |
| | 0101 0000 | | | | |
+--+-----------+----+----+----------+-----+
See 13.2.1.
The fixed part shall contain (in octets 2 to 5 when normal format is used, in octets 2 to 10 otherwise):
a) RJ: Reject Code: 0101. Bits 8-5 of octet 2;
b) CDT: Credit Value (set to 1111 in class 1). Bits
4-1 of octet 2 for normal formats and octets 9
and 10 for extended formats;
c) DST-REF: See 13.4.3;
142
For normal formats, bits 7-1 of octet 5; bit 8 of octet 5 is not significant and shall take the value 0. For extended formats, octets 5,6 and 7 together with bits 7-1 of octet 8; bit 8 of octet 8 is not significant and shall take the value 0.
There is no variable part for this TPDU type.
1 2 3 4 5 6 P
+----+-----------+----+----+--------+----------+
| LI | ER | DST-REF | Reject | Variable |
| | 0111 0000 | | | Cause | Part |
+----+-----------+----+----+--------+----------+
See 13.2.1
143
a) ER: TPDU Error Code: 0111 0000;
b) DST-REF: See 13.4.3;
c) REJECT CAUSE: 0000 0000 Reason not specified
0000 0001 Invalid parameter code
0000 0010 Invalid TPDU type
0000 0011 Invalid parameter value.
The variable part may contain the following parameters:
a) Invalid TPDU
Parameter code: 1100 0001
Parameter length: number of octets of the value field
Parameter Value: Contains the bit pattern of the rejected TPDU up to and including the octet
which caused the rejection. This
parameter is mandatory in Class 0.
b) Checksum
This parameter shall be present if the condition in 13.2.3.1 applies.
144
14.1
A system claiming to implement the procedures specified in this standard shall comply with the requirements in 14.2 - 14.5.
14.2
The system shall implement Class 0 or Class 2 or both.
14.3
If the system implements Class 3 or Class 4, it shall also implement Class 2.
14.4
If the system implements Class 1, it shall also implement Class 0.
145
a) initiating CR TPDUs or responding to CR TPDUs with CC TPDUs or both;
b) responding to any other TPDU and operating network service in accordance with the procedures for the class;
c) operating all the procedures for the class listed as mandatory in table 9;
d) operating those procedures for the class listed as
optional in table 9 for which conformance is claimed;
e) handling all TPDUs of lengths up to the lesser value of:
1) the maximum length for the class;
2) the maximum for which conformance is claimed.
NOTE - This requirement indicates that TPDU sizes of 128 octets are always implemented.
a) which class or classes of protocol are implemented;
b) whether the system is capable of initiating or responding to CR TPDUs or both;
c) which of the procedures listed as optional in table 9 are implemented;
146
128, 256, 512, 1024, 2048, 4096 or 8192 octets.
147
| PROCEDURE | CLASS 0 | CLASS 1 |
|--------------------------|----------------|----------------|
| | | |
|TPDU with checksum | NA | NA |
|TPDU wihout checksum | mandatory | mandatory |
| | | |
|--------------------------|----------------|----------------|
|Expedited data transfer | NA | mandatory |
|No expedited data transfer| mandatory | mandatory |
| | | |
|--------------------------|----------------|----------------|
|Flow control in Class 2 | NA | NA |
|No flow control in Class 2| NA | NA |
| | | |
|--------------------------|----------------|----------------|
|Normal formats | mandatory | mandatory |
|Extended formats | NA | NA |
| | | |
|--------------------------|----------------|----------------|
|Use of receipt confirma- | | |
|tion in Class 1 | NA | optional |
|No use of receipt con- | | |
|firmation in Class 1 | NA | mandatory |
| | | |
|--------------------------|----------------|----------------|
|Use of network expedited | | |
|in Class 1 | NA | optional |
|No use of network expedi- | | |
|ted in Class 1 | NA | mandatory |
| | | |
+------------------------------------------------------------+
NA indicates the procedure is not applicable.
Table 9. (First of 2 pages) Provision of options
148
| PROCEDURE | CLASS 2 | CLASS 3 | CLASS 4 |
|--------------------------|----------|----------|-----------|
| | | | |
|TPDU with checksum |NA |NA |mandatory |
|TPDU wihout checksum |mandatory |mandatory |optional |
| | | | |
|--------------------------|----------|----------|-----------|
|Expedited data transfer |mandatory |mandatory |mandatory |
|No expedited data transfer|mandatory |mandatory |mandatory |
| | | | |
|--------------------------|----------|----------|-----------|
|Flow control in Class 2 |mandatory |NA |NA |
|No flow control in Class 2|optional |NA |NA |
| | | | |
|--------------------------|----------|----------|-----------|
|Normal formats |mandatory |mandatory |mandatory |
|Extended formats |optional |optional |optional |
| | | | |
|--------------------------|----------|----------|-----------|
|Use of receipt confirma- | | | |
|tion in Class 1 |NA |NA |NA |
|No use of receipt con- | | | |
|firmation in Class 1 |NA |NA |NA |
| | | | |
|--------------------------|----------|----------|-----------|
|Use of network expedited | | | |
|in Class 1 |NA |NA |NA |
|No use of network expedi- | | | |
|ted in Class 1 |NA |NA |NA |
| | | | |
+------------------------------------------------------------+
NA indicates the procedure is not applicable
Table 9. (Second of 2 pages) Provision of options
149
This Annex provides a more precise description of the protocol. In the event of a discrepancy between the description in these tables and that contained in the text, the text takes precedence.
The state table also define the mapping between service and protocol events that TS-users can expect.
This annex describes the transport protocol in terms of state
tables. The state tables show the state of a transport
connection, the events that occur in the protocol, the actions
taken and the resultant state.
[The state tables have been omitted from this copy.]
150
The following symbols are used:
C0 variables used in the algorithms
C1
i number (i.e. position) of an octet within the TPDU (see
12.1)
n number (i.e. position) of the first octet of the checksum
parameter
L length of the complete TPDU
X value of the first octet of the checksum parameter
Y value of the second octet of the checksum parameter.
Addition is performed in one of the two following modes:
a) modulo 255 arithmetic;
b) one's complement arithmetic in which if any of the variables has the value minus zero (i.e. 255) it shall be regarded as though it was plus zero (i.e. 0).
151
a) adding the value of the octet to C0; then
b) adding the value of C0 to C1.
X = -C1 + (L-n).CO
Y = C1 - (L-n+1).C0
[A Note describing the above algorithm in mathematical notation has been omitted from this copy.]
a) adding the value of the octet to C0; then
b) adding the value of C0 to C1.
152
NOTE - The nature of the algorithm is such that it is not necessary to compare explicitly the stored checksum bytes.
153
At the SC16 meeting in Tokyo, June 1982, authorization was given (Resolutions 10 and 11, SC16 N 1233) to register both the
Transport Service Definition and the Transport Protocol
Specification as Draft Proposals and to circulate them for a 90-
day ballot.
Following the close of the letter ballot an Editing Group was convened to integrate editorial comments and make recommendations regarding proposed technical changes. The revised texts and proposed recommendations were reviewed by SC16/WG6 at its meeting in Vienna, March 1983. The revised text of the Transport Service Definition (SC16 N 1435) was accepted as presented whereas the revised text of the Transport Protocol (SC16 N 1433) was subjected to an additional 60-day ballot. Consistent with the SC16 decision regarding the parallel progression of both DPs, the
Transport Service Definition was held in abeyance pending
acceptance by SC16 of the revised Transport Protocol (Second DP
8073).
A second Editing Group was convened in Paris, July 1983, to review comments submitted on Second DP 8073. The Minutes and Report of this meeting are documented in SC16 N1575 and N 1574 respectively. The two negative votes (DIN and NNI) were given full consideration. The NNI concerns have been fully covered in the revised text prepared by the Editing Group. The DIN concerns have been taken into account and incorporated in their large majority.
Upon the recommendation of the Editing Group, DP 8072 and DP 8073 are forwarded for registration as Draft International Standards and letter ballot of ISO Member Bodies.
154