Network Working Group ISO
Request for Comments: 905 April 1984
ISO Transport Protocol Specification
ISO DP 8073
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
BBNTable of Contents
1 SCOPE AND FIELD OF APPLICATION........................ 3
1.1 This International Standard specifies:.............. 3
1.2 The procedures are defined in terms of:............. 4
1.3 .................................................... 4
1.4 .................................................... 5
2 REFERENCES............................................ 5
3 DEFINITIONS........................................... 6
3.1 .................................................... 6
3.2 .................................................... 6
3.2.1 equipment:........................................ 7
3.2.2 transport service user:........................... 7
3.2.3 network service provider:......................... 7
3.2.4 local matter:..................................... 7
3.2.5 initiator:........................................ 7
3.2.6 responder:........................................ 8
3.2.7 sending transport entity:......................... 8
3.2.8 receiving transport entity:....................... 8
3.2.9 preferred class:.................................. 8
3.2.10 alternative class:............................... 8
3.2.11 proposed class:.................................. 9
3.2.12 selected class:.................................. 9
3.2.13 proposed parameter:.............................. 9
3.2.14 selected parameter:.............................. 9
3.2.15 error indication:................................ 9
3.2.16 invalid TPDU:................................... 10
3.2.17 protocol error:................................. 10
3.2.18 sequence number:................................ 10
3.2.19 transmit window:................................ 10
3.2.20 lower window edge:.............................. 11
3.2.21 upper window edge:.............................. 11
3.2.22 upper window edge allocated to the peer
entity:
.................................................... 11
3.2.23 closed window:.................................. 11
3.2.24 window information:............................. 11
3.2.25 frozen reference:............................... 12
3.2.26 unassigned reference:........................... 12
3.2.27 transparent (data):............................. 12
i3.2.28 owner (of a network connection):................ 12
3.2.29 retained TPDU:.................................. 12
4 SYMBOLS AND ABBREVIATIONS............................ 13
4.1 Data units......................................... 13
4.2 Types of transport protocol data units............. 13
4.3 TPDU fields........................................ 13
4.4 Times and associated variables..................... 14
4.5 Miscellaneous...................................... 14
5 OVERVIEW OF THE TRANSPORT PROTOCOL................... 15
5.1 Service provided by the transport layer............ 15
5.2 Service assumed from the network layer............. 16
5.3 Functions of the Transport Layer................... 18
5.3.1 Overview of functions............................ 18
5.3.1.1 Functions used at all times.................... 19
5.3.1.2 Connection Establishment....................... 19
5.3.1.3 Data Transfer.................................. 20
5.3.1.4 Release........................................ 21
5.4 Classes and options................................ 21
5.4.1 General.......................................... 21
5.4.2 Negotiation...................................... 22
5.4.3 Choice of network connection..................... 22
5.4.4 Characteristics of Class 0....................... 23
5.4.5 Characteristics of Class 1....................... 23
5.4.6 Characteristics of Class 2....................... 24
5.4.6.1 General........................................ 24
5.4.6.2 Use of explicit flow control................... 24
5.4.6.3 Non-use of explicit flow control............... 24
5.4.7 Characteristics of Class 3....................... 24
5.4.8 Characteristics of Class 4....................... 25
5.5 Model of the transport layer....................... 25
6 ELEMENTS OF PROCEDURE................................ 27
6.1 Assignment to network connection................... 27
6.1.1 Purpose.......................................... 27
6.1.2 Network service primitives....................... 27
6.1.3 Procedure........................................ 28
6.2 Transport protocol data unit (TPDU) transfer....... 29
6.2.1 Purpose.......................................... 29
6.2.2 Network Service Primitives....................... 30
6.2.3 Procedure........................................ 30
6.3 Segmenting and reassembling........................ 30
6.3.1 Purpose.......................................... 30
6.3.2 TPDUs and parameter used......................... 31
6.3.3 Procedure........................................ 31
ii6.4 Concatenation and separation....................... 31
6.4.1 Purpose.......................................... 31
6.4.2 Procedure........................................ 32
6.5 Connection establishment........................... 32
6.5.1 Purpose.......................................... 32
6.5.2 Network service primitives....................... 33
6.5.3 TPDUs and parameters used........................ 33
6.5.4 Procedure........................................ 34
6.6 Connection refusal................................. 40
6.6.1 Purpose.......................................... 40
6.6.2 TPDUs and parameters used........................ 40
6.6.3 Procedure........................................ 41
6.7 Normal release..................................... 41
6.7.1 Purpose.......................................... 41
6.7.2 Network service primitives....................... 42
6.7.3 TPDUs and parameters used........................ 42
6.7.4 Procedure for implicit variant................... 43
6.7.5 Procedure for explicit variant................... 43
6.8 Error Release...................................... 44
6.8.1 Purpose.......................................... 45
6.8.2 Network service primitives....................... 45
6.8.3 Procedure........................................ 45
6.9 Association of TPDUs with transport
connections
.................................................... 45
6.9.1 Purpose.......................................... 45
6.9.2 Network service primitives....................... 46
6.9.3 TPDUs and parameters uses........................ 46
6.9.4 Procedures....................................... 46
6.9.4.1 Identification of TPDUs........................ 46
6.9.4.2 Association of individual TPDUs................ 47
6.10 Data TPDU numbering............................... 49
6.10.1 Purpose......................................... 49
6.10.2 TPDUs and parameters used....................... 49
6.10.3 Procedure....................................... 50
6.11 Expedited data transfer........................... 50
6.11.1 Purpose......................................... 50
6.11.2 Network service primitives...................... 50
6.11.3 TPDUs and parameter used........................ 51
6.11.4 Procedures...................................... 51
6.12 Reassignment after failure........................ 52
6.12.1 Purpose......................................... 52
6.12.2 Network service primitives...................... 52
iii6.12.3 Procedure....................................... 52
6.12.4 Timers.......................................... 54
6.13 Retention until acknowledgement of TPDUs.......... 56
6.13.1 Purpose......................................... 56
6.13.2 Network service primitives...................... 56
6.13.3 TPDUs and parameters used....................... 56
6.13.4 Procedures...................................... 57
6.14 Resynchronization................................. 60
6.14.1 Purpose......................................... 60
6.14.2 Network service primitives...................... 60
6.14.3 TPDUs and parameters used....................... 60
6.14.4 Procedure....................................... 61
6.14.4.1 Active resynchronization procedures........... 61
6.14.4.2 Passive resynchronization procedures.......... 62
6.14.4.3 Data Resynchronization Procedures............. 63
6.15 Multiplexing and demultiplexing................... 64
6.15.1 Purpose......................................... 64
6.15.2 TPDUs and parameters used....................... 64
6.15.3 Procedure....................................... 65
6.16 Explicit Flow Control............................. 65
6.16.1 Purpose......................................... 65
6.16.2 TPDUs and parameters used....................... 65
6.16.3 Procedure....................................... 66
6.17 Checksum.......................................... 66
6.17.1 Purpose......................................... 66
6.17.2 TPDUs and parameters used....................... 66
6.17.3 Procedure....................................... 67
6.18 Frozen references................................. 68
6.18.1 Purpose......................................... 68
6.18.2 Procedure....................................... 68
6.18.2.1 Procedure for classes 0 and 2................. 68
6.18.2.2 Procedure for classes 1 and 3................. 69
6.18.2.3 Procedure for classes 4....................... 70
6.19 Retransmission on time-out........................ 70
6.19.1 Purpose......................................... 70
6.19.2 TPDUs used...................................... 70
6.19.3 Procedure....................................... 70
6.20 Resequencing...................................... 70
6.20.1 Purpose......................................... 71
6.20.2 TPDUs and parameters used....................... 71
6.20.3 Procedure....................................... 71
6.21 Inactivity control................................ 71
6.21.1 Purpose......................................... 71
iv6.21.2 Procedure....................................... 72
6.22 Treatment of protocol errors...................... 72
6.22.1 Purpose......................................... 72
6.22.2 TPDUs and parameters used....................... 72
6.22.3 Procedure....................................... 72
6.23 Splitting and recombining......................... 74
6.23.1 Purpose......................................... 74
6.23.2 Procedure....................................... 74
7 Protocol Classes..................................... 76
8 SPECIFICATION FOR CLASS 0. SIMPLE CLASS.............. 79
8.1 Functions of class 0............................... 79
8.2 Procedures for class 0............................. 79
8.2.1 Procedures applicable at all times............... 79
8.2.2 Connection establishment......................... 79
8.2.3 Data transfer.................................... 80
8.2.4 Release.......................................... 80
9 SPECIFICATION FOR CLASS 1: BASIC ERROR
RECOVERY CLASS
.................................................... 81
9.1 Functions of Class 1............................... 81
9.2 Procedures for Class 1............................. 81
9.2.1 Procedures applicable at all times............... 81
9.2.2 Connection establishment......................... 82
9.2.3 Data Transfer.................................... 82
9.2.3.1 General........................................ 82
9.2.3.2 Expedited Data................................. 83
9.2.4 Release.......................................... 84
10 SPECIFICATION FOR CLASS 2 - MULTIPLEXING
CLASS
.................................................... 85
10.1 Functions of class 2.............................. 85
10.2 Procedures for class 2............................ 85
10.2.1 Procedures applicable at all times.............. 85
10.2.2 Connection establishment........................ 86
10.2.3 Data transfer when non use of explicit
flow control
.................................................... 86
10.2.4 Data transfer when use of explicit flow
control
.................................................... 86
10.2.4.1 General....................................... 86
10.2.4.2 Flow control.................................. 87
10.2.4.3 Expedited data................................ 88
v10.2.5 Release......................................... 89
11 SPECIFICATION FOR CLASS 3: ERROR RECOVERY AND
MULTIPLEXING CLASS
.................................................... 90
11.1 Functions of Class 3.............................. 90
11.2 Procedures for Class 3............................ 90
11.2.1 Procedures applicable at all times.............. 90
11.2.2 Connection Establishment........................ 91
11.2.3 Data Transfer................................... 91
11.2.3.1 General....................................... 91
11.2.3.2 Use of RJ TPDU................................ 92
11.2.3.3 Flow Control.................................. 93
11.2.3.4 Expedited data................................ 93
11.2.4 Release......................................... 94
12 SPECIFICATION FOR CLASS 4: ERROR DETECTION
AND RECOVERY CLASS
.................................................... 95
12.1 Functions of Class 4.............................. 95
12.2 Procedures for Class 4............................ 95
12.2.1 Procedures available at all times............... 95
12.2.1.1 Timers used at all times...................... 95
12.2.1.1.1 NSDU lifetime (MLR, MRL).................... 98
12.2.1.1.2 Expected maximum transit delay (ELR,
ERL)
.................................................... 98
12.2.1.1.3 Acknowledge Time (AR, AL)................... 99
12.2.1.1.4 Local retransmission time (T1).............. 99
12.2.1.1.5 Persistence Time (R)........................ 99
12.2.1.1.6 Bound on References and Sequence
Numbers (L)
................................................... 100
12.2.1.2 General Procedures........................... 100
12.2.2 Procedures for Connection Establishment........ 102
12.2.2.1 Timers used in Connection Establishment...... 102
12.2.2.2 General Procedures........................... 103
12.2.3 Procedures for Data Transfer................... 104
12.2.3.1 Timers used in Data Transfer................. 104
12.2.3.2 General Procedures for data transfer......... 104
12.2.3.3 Inactivity Control........................... 105
12.2.3.4 Expedited Data............................... 105
12.2.3.5 Resequencing................................. 106
12.2.3.6 Explicit Flow Control........................ 107
12.2.3.7 Sequencing of received AK TPDUs.............. 108
vi12.2.3.8 Procedure for transmission of AK TPDUs....... 109
12.2.3.8.1 Retransmission of AK TPDUs for window
synchronization
................................................... 109
12.2.3.8.2 Sequence control for transmission of
AK TPDUs
................................................... 109
12.2.3.8.3 Retransmission of AK TPDUs after CDT
set to zero
................................................... 110
12.2.3.8.4 Retransmission procedures following
reduction of the
................................................... 111
12.2.3.9 Use of Flow Control Confirmation
parameter
................................................... 112
12.2.4 Procedures for Release......................... 113
12.2.4.1 Timers used for Release...................... 113
12.2.4.2 General Procedures for Release............... 113
13 STRUCTURE AND ENCODING OF TPDUs.................... 114
13.1 Validity......................................... 114
13.2 Structure........................................ 116
13.2.1 Length indicator field......................... 117
13.2.2 Fixed part..................................... 117
13.2.2.1 General...................................... 117
13.2.2.2 TPDU code.................................... 117
13.2.3 Variable part.................................. 118
13.2.3.1 Checksum Parameter (Class 4 only)............ 120
13.2.4 Data Field..................................... 120
13.3 Connection Request (CR) TPDU..................... 120
13.3.1 Structure...................................... 120
13.3.2 LI............................................. 121
13.3.3 Fixed Part (Octets 2 to 7)..................... 121
13.3.4 Variable Part (Octets 8 to p).................. 122
13.3.5 User Data (Octets p+1 to the end).............. 127
13.4 Connection Confirm (CC) TPDU..................... 128
13.4.1 Structure...................................... 128
13.4.2 LI............................................. 128
13.4.3 Fixed Part (Octets 2 to 7)..................... 128
13.4.4 Variable Part (Octet 8 to p)................... 129
13.4.5 User Data (Octets p+1 to the end).............. 129
13.5 Disonnect Request (DR) TPDU...................... 129
13.5.1 Structure...................................... 129
vii13.5.2 LI............................................. 129
13.5.3 Fixed Part (Octets 2 to 7...................... 130
13.5.4 Variable Part (Octets 8 to p).................. 131
13.5.5 User Data (Octets p+1 to the end).............. 131
13.6 Disconnect Confirm (DC) TPDU..................... 132
13.6.1 Structure...................................... 132
13.6.2 LI............................................. 132
13.6.3 Fixed Part (Octets 2 to 6)..................... 132
13.6.4 Variable Part.................................. 133
13.7 Data (DT) TPDU................................... 133
13.7.1 Structure...................................... 133
13.7.2 LI............................................. 134
13.7.3 Fixed Part..................................... 134
13.7.4 Variable Part.................................. 135
13.7.5 User Data Field................................ 135
13.8 Expedited Data (ED) TPDU......................... 135
13.8.1 Structure...................................... 135
13.8.2 LI............................................. 136
13.8.3 Fixed Part..................................... 136
13.8.4 Variable Part.................................. 137
13.8.5 User Data Field................................ 137
13.9 Data Acknowledgement (AK) TPDU................... 137
13.9.1 Structure...................................... 137
13.9.2 LI............................................. 138
13.9.3 Fixed Part..................................... 138
13.9.4 Variable Part.................................. 139
13.10 Expedited Data Acknowledgement (EA) TPDU........ 140
13.10.1 Structure..................................... 140
13.10.2 LI............................................ 141
13.10.3 Fixed Part.................................... 141
13.10.4 Variable Part................................. 141
13.11 Reject (RJ) TPDU................................ 141
13.11.1 Structure..................................... 142
13.11.2 LI............................................ 142
13.11.3 Fixed Part.................................... 142
13.11.4 Variable Part................................. 143
13.12 TPDU Error (ER) TPDU............................ 143
13.12.1 Structure..................................... 143
13.12.2 LI............................................ 143
13.12.3 Fixed Part.................................... 144
13.12.4 Variable Part................................. 144
14 CONFORMANCE........................................ 145
14.1 ................................................. 145
viii14.2 ................................................. 145
14.3 ................................................. 145
14.4 ................................................. 145
14.5 ................................................. 146
14.6 Claims of Conformance Shall State................ 146
ixINTRODUCTION
The Transport Protocol Standard is one of a set of International
Standards produced to facilitate the interconnection of computer
systems. The set of standards covers the services and protocols
required to achieve such interconnection.
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.
1The classes are selectable with respect to the Transport and
Network Services in providing the required quality of service for
the interconnection of two session entities (note that each class
provides a different set of functions for enhancement of service
qualities).
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.
2It should be noted that, as the number of valid protocol
sequences is very large, it is not possible with current
technology to verify that an implementation will operate the
protocol defined in this International Standard correctly under
all circumstances. It is possible by means of testing to
establish confidence that an implementation correctly operates
the protocol in a representative sample of circumstances. It is,
however, intended that this International Standard can be used in
circumstances where two implementations fail to communicate in
order to determine whether one or both have failed to operate the
protocol correctly.
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
1.1 This International Standard specifies:
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,
3for the connection oriented transfer of data and control
information from one transport entity to a peer transport
entity;
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;
1.2 The procedures are defined in terms of:
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.
41.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.
5SECTION ONE. GENERAL
3 DEFINITIONS
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:
63.2.1 equipment:
Hardware or software or a combination of both; it need not be
physically distinct within a computer system.
3.2.2 transport service user:
An abstract representation of the totality of those entities
within a single system that make use of the transport service.
3.2.3 network service provider:
An abstract machine that models the totality of the entities
providing the network service, as viewed by a transport entity.
3.2.4 local matter:
A decision made by a system concerning its behavior in the
Transport Layer that is not subject to the requirements of this
protocol.
3.2.5 initiator:
A transport entity that initiates a CR TPDU.
73.2.6 responder:
A transport entity with whom an initiator wishes to establish a
transport connection.
NOTE - Initiator and responder are defined with respect to a
single transport connection. A transport entity can be both an
initiator and responder simultaneously.
3.2.7 sending transport entity:
A transport entity that sends a given TPDU.
3.2.8 receiving transport entity:
A transport entity that receives a given TPDU.
3.2.9 preferred class:
The protocol class that the initiator indicates in a CR TPDU as
its first choice for use over the transport connection.
3.2.10 alternative class:
A protocol class that the initiator indicates in a CR TPDU as an
alternative choice for use over the transport connection.
83.2.11 proposed class:
A preferred class or an alternative class.
3.2.12 selected class:
The protocol class that the responder indicates in a CC TPDU that
it has chosen for use over the transport connection.
3.2.13 proposed parameter:
The value for a parameter that the initiator indicates in a CR
TPDU that it wishes to use over the transport connection.
3.2.14 selected parameter:
The value for a parameter that the responder indicates in a CC
TPDU that it has chosen for use over the transport connection.
3.2.15 error indication:
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.
93.2.16 invalid TPDU:
A TPDU that does not comply with the requirements of this
International Standard for structure and encoding.
3.2.17 protocol error:
A TPDU whose use does not comply with the procedures for the
class.
3.2.18 sequence number:
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.
3.2.19 transmit window:
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.
103.2.20 lower window edge:
The lowest sequence number in a transmit window.
3.2.21 upper window edge:
The sequence number which is one greater than the highest
sequence number in the transmit window.
3.2.22 upper window edge allocated to the peer entity:
The value that a transport entity communicates to its peer entity
to be interpreted as its new upper window edge.
3.2.23 closed window:
A transmit window that contains no sequence number.
3.2.24 window information:
Information contained in a TPDU relating to the upper and the
lower window edges.
113.2.25 frozen reference:
A reference that is not available for assignment to a connection
because of the requirements of 6.18.
3.2.26 unassigned reference:
A reference that is neither currently in use for identifying a
transport connection or which is in a frozen state.
3.2.27 transparent (data):
TS-user data that is transferred intact between transport
entities and which is unavailable for use by the transport
entities.
3.2.28 owner (of a network connection):
The transport entity that issued the N-CONNECT request leading to
the creation of that network connection.
3.2.29 retained TPDU:
A TPDU that is subject to the retransmission procedure or
retention until acknowledgement procedure and is available for
possible retransmission.
124 SYMBOLS AND ABBREVIATIONS
4.1 Data units
TPDU Transport protocol data unit
TSDU Transport service data unit
NSDU Network service data unit
4.2 Types of transport protocol data units
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
4.3 TPDU fields
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)
134.4 Times and associated variables
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
4.5 Miscellaneous
TS-user Transport service user
TSAP Transport service access point
NS-provider Network service provider
NSAP Network service access point
QOS Quality of service
145 OVERVIEW OF THE TRANSPORT PROTOCOL
NOTE - This overview is not exhaustive and has been provided for
guidance to the reader of this International Standard.
5.1 Service provided by the transport layer
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
5.2 Service assumed from the network layer
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
17Key:
X - The Transport Protocol assumes that this facility is
provided in all networks.
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.
5.3 Functions of the Transport Layer
5.3.1 Overview of functions
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;
18b) accounting mechanisms;
c) status exchanges and monitoring of QOS;
d) blocking;
e) temporary release of network connections;
f) alternative checksum algorithm.
5.3.1.1 Functions used at all times
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.
5.3.1.2 Connection Establishment
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:
19a) select network service which best matches the requirement
of the TS-user taking into account charges for various
services (see 6.5);
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).
5.3.1.3 Data Transfer
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;
20c) splitting and recombining (see 6.23), a function allowing
the simultaneous use of two or more network connections to
support the same transport connection;
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.
5.3.1.4 Release
The purpose of release (see 6.7 and 6.8) is to provide
disconnection of the transport connection, regardless of the
current activity.
5.4 Classes and options
5.4.1 General
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:
21a) Class 0: Simple Class;
b) Class 1: Basic Error recovery Class;
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.
5.4.2 Negotiation
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.
5.4.3 Choice of network connection
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:
22a) Type A. Network connection with acceptable residual error
rate (for example not signalled by disconnect or reset)
and acceptable rate of signalled errors.
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.
5.4.4 Characteristics of Class 0
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.
5.4.5 Characteristics of Class 1
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.
235.4.6 Characteristics of Class 2
5.4.6.1 General
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.
5.4.6.2 Use of explicit flow control
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.
5.4.6.3 Non-use of explicit flow control
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.
5.4.7 Characteristics of Class 3
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.
245.4.8 Characteristics of Class 4
Class 4 provides the characteristics of Class 3, plus the
capability to detect and recover from errors which occur as a
result of the low grade of service available from the NS-
provider. The kinds of errors to be detected include: TPDU
loss, TPDU delivery out of sequence, TPDU duplication and TPDU
corruption. These errors may affect control TPDUs as well as
data TPDUs.
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.
5.5 Model of the transport layer
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.
26SECTION TWO. TRANSPORT PROTOCOL SPECIFICATION
6 ELEMENTS OF PROCEDURE
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.
6.1 Assignment to network connection
6.1.1 Purpose
The procedure is used in all classes to assign transport
connections to network connections.
6.1.2 Network service primitives
The procedure makes use of the following network service
primitives:
a) N-CONNECT;
b) N-DISCONNECT.
276.1.3 Procedure
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.
28NOTES
1. When a new network connection is created, the quality of
service requested is a local matter, although it will
normally be related to the requirements of transport
connection(s) expected to be assigned to it.
2. An existing network connection may also not be suitable
if, for example, the quality of service requested for the
transport connection cannot be attained by using or
enhancing the network connection.
3. A network connection with no transport connection(s)
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.
4. After the failure of a network connection, transport
connections which were previously multiplexed together may
be assigned to different network connections, and vice
versa.
6.2 Transport protocol data unit (TPDU) transfer
6.2.1 Purpose
The TPDU transfer procedure is used in all classes to convey
transport protocol data units in user data fields of network
service primitives.
296.2.2 Network Service Primitives
The procedure uses the following network service primitives:
a) N-DATA;
b) N-EXPEDITED DATA
6.2.3 Procedure
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).
6.3 Segmenting and reassembling
6.3.1 Purpose
The segmenting and reassembling procedure is used in all classes
to map TSDUs onto TPDUs.
306.3.2 TPDUs and parameter used
The procedure makes use of the following TPDU and parameter:
DT TPDUs;
- End of TSDU.
6.3.3 Procedure
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
1. The EOT parameter of a DT TPDU indicates whether or not
there are subsequent DT TPDUs in the sequence.
2. There is no requirement that the DT TPDUs shall be of the
maximum length selected during connection establishment.
6.4 Concatenation and separation
6.4.1 Purpose
The procedure for concatenation and separation is used in classes
1, 2, 3 and 4 to convey multiple TPDUs in one NSDU.
316.4.2 Procedure
A transport entity may concatenate TPDUs from the same or
different transport connections.
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
1. The TPDUs within a concatenated set may be distinguished
by means of the length indicator parameter.
2. The end of a TPDU containing data is indicated by the
termination of the NSDU.
3. The number of concatenated TPDUs referred to in 6.4.2.a is
bounded by the maximum number of transport connections
which are multiplexed together except during assignment or
reassignment.
6.5 Connection establishment
6.5.1 Purpose
The procedure for connection establishment is used in all classes
to create a new transport connection.
326.5.2 Network service primitives
The procedure uses the following network service primitive:
N-DATA
6.5.3 TPDUs and parameters used
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- SRC-REF;
- 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.
6.5.4 Procedure
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
34reset or disconnect the network connection and, in classes 1
and 3 freeze the reference (see 6.18). For all other
transport connection(s) multiplexed on the same network
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.
35NOTE - If class 0 is a valid response according to table
3, inclusion of user data in the CR TPDU may cause the
responding entity to refuse the connection (e.g. if it
only supports class 0).
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:
1. The valid responses indicated in table 3 result from both
explicit negotiation, whereby each of the classes proposed
is a valid response, and implicit negotiation whereby:
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.
372. Negotiation from class 2 to class 1 and from any class to
an higher-numbered class is not valid.
3. Redundant combinations are not a protocol error.
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.
38The negotiation rules for the options are such that the initiator
may propose either to use or not to use the option. The
responder may either accept the proposed choice or select an
alternative choice as defined in table 4.
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
39NOTE - Table 4 defines the procedures for negotiation of options.
This negotiation has been designed such that if the initiator
proposes the mandatory implementation option specified in clause
14, the responder has to accept use of this option over the
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.
6.6 Connection refusal
6.6.1 Purpose
The connection refusal procedure is used in all classes when a
transport entity refuses a transport connection in response to a
CR TPDU.
6.6.2 TPDUs and parameters used
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.
406.6.3 Procedure
If a transport connection cannot be accepted, the responder shall
respond to the CR TPDU with a DR TPDU. The reason shall indicate
why the connection was not accepted. The source reference field
in the DR TPDU shall be set to zero to indicate an unassigned
reference.
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
1. When the invalid CR TPDU can be identified as having class 0
as the preferred class, it is recommended to respond with an
ER TPDU. For all other invalid CR TPDUs either an ER TPDU or
DR TPDU may be sent.
2. If the optimal supervisory timer TS1 has been set for this
connection then the entity should stop the timer on receipt
of the DR or ER TPDU.
6.7 Normal release
6.7.1 Purpose
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.
41NOTES
1. When the implicit variant is used (i.e. in class 0), the
lifetime of the transport connection is directly correlated
with the lifetime of the network connection.
2. The use of the explicit variant of the release procedure
enables the transport connection to be released independently
of the underlying network connection.
6.7.2 Network service primitives
The procedure makes use of the following network service
primitives:
a) N-DISCONNECT (implicit variant only),
b) N-DATA
6.7.3 TPDUs and parameters used
The procedure makes use of the following TPDUs and parameters:
a) DR TPDU;
- clearing reason;
- user data;
- SRC-REF;
- DST-REF.
b) DC TPDU.
426.7.4 Procedure for implicit variant
In the implicit variant either transport entity disconnects a
transport connection by disconnecting the network connection to
which it is assigned. When a transport entity receives an N-
DISCONNECT this should be considered as the release of the
transport connection.
6.7.5 Procedure for explicit variant
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).
43e) in other cases, send a DC TPDU and consider the transport
connection released.
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).
6.8 Error Release
446.8.1 Purpose
This procedure is used only in classes 0 and 2 to release a
transport connection on the receipt of an N-DISCONNECT or N-RESET
indication.
6.8.2 Network service primitives
The procedure makes use of the following service primitives:
a) N-DISCONNECT indication;
b) N-RESET indication.
6.8.3 Procedure
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.
6.9 Association of TPDUs with transport connections
6.9.1 Purpose
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.
456.9.2 Network service primitives
This procedure makes use of the following network service
primitives:
a) N-DATA indication;
b) N-EXPEDITED DATA indication.
6.9.3 TPDUs and parameters uses
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.
6.9.4 Procedures
6.9.4.1 Identification of TPDUs
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:
46a) if the network connection on which the error is detected
has a class 0 or class 1 transport connection assigned to
it, then treat as a protocol error (see 6.22) for that
transport connection;
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.
6.9.4.2 Association of individual TPDUs
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
47where a class 1 transport connection is assigned, then the TPDU
is associated with the transport connection.
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;
482) if a CR TPDU is unacknowledged then the DR TPDU is
associated with the transport connection, regardless
of the value of its SRC-REF parameter;
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.
6.10 Data TPDU numbering
6.10.1 Purpose
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.
6.10.2 TPDUs and parameters used
The procedure makes use of the following TPDU and parameter:
DT TPDU;
- TPDU-NR.
496.10.3 Procedure
A Transport entity shall allocate the sequence number zero to the
TPDU-NR of the first DT TPDU which it transmits for a transport
connection. For subsequent DT TPDUs sent on the same transport
connection, the transport entity shall allocate a sequence number
one greater than the previous one.
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'.
6.11 Expedited data transfer
6.11.1 Purpose
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.
6.11.2 Network service primitives
The procedure makes use of the following network service
primitives:
a) N-DATA;
50b) N-EXPEDITED DATA.
6.11.3 TPDUs and parameter used
The procedure makes use of the following TPDUs and parameters:
a) ED TPDU;
- ED TPDU-NR.
b) EA TPDU;
- YR-EDTU-NR.
6.11.4 Procedures
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.
51NOTES
1. The network normal data variant is used, except when the
network expedited variant (available in Class 1 only), has
been agreed, in which case ED and EA TPDUs are conveyed in
the data fields of N-EXPEDITED DATA primitives (see
6.2.3).
2. No TPDUs can be transmitted using network expedited until
the CC TPDU becomes acknowledged, to prevent the network
expedited from overtaking the CC TPDU.
6.12 Reassignment after failure
6.12.1 Purpose
The reassignment after failure procedure is used in Classes 1 and
3 to commence recovery from an NS-provider signalled disconnect.
6.12.2 Network service primitives
The procedure uses the following network service primitive:
N-DISCONNECT indication
6.12.3 Procedure
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:
521) assign the transport connection to a different network
connection (see 6.1) and start its TTR timer if not
already started.
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
53transport connection is considered released and the reference is
frozen (see 6.18).
6.12.4 Timers
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
1. Provided that the required quality of service is met, TTR may
be set to zero (i.e. no assignment). This may be done, for
example, if the rate of NS-provider generated disconnects is
very low.
2. Inclusion of the reassignment time parameter in the CR TPDU
allows the responder to use a TWR value of less than 2
minutes.
3. If the optional TS1 and TS2 timers are used, it is
recommended:
54a) to stop TS1 or TS2 if running when TTR or TWR is
started;
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.
556.13 Retention until acknowledgement of TPDUs
6.13.1 Purpose
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.
6.13.2 Network service primitives
The procedure uses the following network service primitives:
a) N-DATA;
b) N-DATA ACKNOWLEDGE.
6.13.3 TPDUs and parameters used
The procedure uses the following TPDUs and parameters:
a) CR, CC, DR and DC TPDUs;
b) RJ and AK TPDUs;
- YR-TU-NR.
56c) DT TPDU;
- TPDU-NR.
d) ED TPDU;
- ED-TPDU-NR.
e) EA TPDU;
- YR-EDTU-NR.
6.13.4 Procedures
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.
57NOTES
1. It is a local matter for each transport entity to decide
which N-DATA requests should have the confirmation request
parameter set. This decision will normally be related to
the amount of storage available for retained copies of the
DT TPDUs.
2. Use of the confirmation request parameter may affect the
quality of network service.
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 |
| | 