summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc905.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc905.txt')
-rw-r--r--doc/rfc/rfc905.txt9515
1 files changed, 9515 insertions, 0 deletions
diff --git a/doc/rfc/rfc905.txt b/doc/rfc/rfc905.txt
new file mode 100644
index 0000000..5c2cf74
--- /dev/null
+++ b/doc/rfc/rfc905.txt
@@ -0,0 +1,9515 @@
+
+
+
+
+
+
+
+
+
+ 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
+ BBN
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Table 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
+
+
+
+ i
+
+
+
+
+
+
+
+
+
+
+
+ 3.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
+
+
+
+ ii
+
+
+
+
+
+
+
+
+
+
+
+ 6.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
+
+
+
+ iii
+
+
+
+
+
+
+
+
+
+
+
+ 6.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
+
+
+
+ iv
+
+
+
+
+
+
+
+
+
+
+
+ 6.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
+
+
+
+ v
+
+
+
+
+
+
+
+
+
+
+
+ 10.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
+
+
+
+ vi
+
+
+
+
+
+
+
+
+
+
+
+ 12.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
+
+
+
+ vii
+
+
+
+
+
+
+
+
+
+
+
+ 13.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
+
+
+
+ viii
+
+
+
+
+
+
+
+
+
+
+
+ 14.2 ................................................. 145
+ 14.3 ................................................. 145
+ 14.4 ................................................. 145
+ 14.5 ................................................. 146
+ 14.6 Claims of Conformance Shall State................ 146
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ix
+
+
+
+
+
+
+
+
+
+
+
+ INTRODUCTION
+
+ 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.
+
+
+
+ 1
+
+
+
+
+
+
+
+
+
+
+
+ The 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.
+
+
+
+ 2
+
+
+
+
+
+
+
+
+
+
+
+ It 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,
+
+
+
+
+ 3
+
+
+
+
+
+
+
+
+
+
+
+ for 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.
+
+
+
+
+
+
+
+ 4
+
+
+
+
+
+
+
+
+
+
+
+ 1.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
+
+
+
+
+
+
+
+
+
+
+
+ SECTION 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:
+
+
+
+
+
+
+
+
+
+
+ 6
+
+
+
+
+
+
+
+
+
+
+
+ 3.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.
+
+
+
+
+
+
+
+
+
+
+ 7
+
+
+
+
+
+
+
+
+
+
+
+ 3.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.
+
+
+
+
+
+
+
+
+ 8
+
+
+
+
+
+
+
+
+
+
+
+ 3.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.
+
+
+
+
+
+
+
+
+
+
+ 9
+
+
+
+
+
+
+
+
+
+
+
+ 3.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.
+
+
+
+
+
+
+
+
+
+
+
+
+ 10
+
+
+
+
+
+
+
+
+
+
+
+ 3.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.
+
+
+
+
+
+
+
+
+
+
+
+
+ 11
+
+
+
+
+
+
+
+
+
+
+
+ 3.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.
+
+
+
+
+
+
+
+
+ 12
+
+
+
+
+
+
+
+
+
+
+
+ 4 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)
+
+
+
+
+
+
+ 13
+
+
+
+
+
+
+
+
+
+
+
+ 4.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
+
+
+
+
+
+
+
+
+
+
+
+
+ 14
+
+
+
+
+
+
+
+
+
+
+
+ 5 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
+
+
+
+
+
+
+
+
+
+
+ 17
+
+
+
+
+
+
+
+
+
+
+
+ Key:
+
+ 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;
+
+
+
+ 18
+
+
+
+
+
+
+
+
+
+
+
+ b) 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:
+
+
+
+
+ 19
+
+
+
+
+
+
+
+
+
+
+
+ a) 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;
+
+
+
+
+
+
+ 20
+
+
+
+
+
+
+
+
+
+
+
+ c) 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:
+
+
+
+ 21
+
+
+
+
+
+
+
+
+
+
+
+ a) 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:
+
+
+
+
+
+
+ 22
+
+
+
+
+
+
+
+
+
+
+
+ a) 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.
+
+
+
+
+
+
+ 23
+
+
+
+
+
+
+
+
+
+
+
+ 5.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.
+
+
+
+
+
+
+ 24
+
+
+
+
+
+
+
+
+
+
+
+ 5.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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 26
+
+
+
+
+
+
+
+
+
+
+
+ SECTION 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.
+
+
+
+
+ 27
+
+
+
+
+
+
+
+
+
+
+
+ 6.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.
+
+
+
+
+
+
+
+
+
+ 28
+
+
+
+
+
+
+
+
+
+
+
+ NOTES
+
+ 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.
+
+
+
+
+
+ 29
+
+
+
+
+
+
+
+
+
+
+
+ 6.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.
+
+
+
+
+
+
+
+
+ 30
+
+
+
+
+
+
+
+
+
+
+
+ 6.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.
+
+
+
+
+
+
+
+
+
+ 31
+
+
+
+
+
+
+
+
+
+
+
+ 6.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.
+
+
+
+
+
+
+
+
+
+ 32
+
+
+
+
+
+
+
+
+
+
+
+ 6.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
+
+
+
+ 34
+
+
+
+
+
+
+
+
+
+
+
+ reset 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.
+
+
+
+
+ 35
+
+
+
+
+
+
+
+
+
+
+
+ NOTE - 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.
+
+
+
+ 37
+
+
+
+
+
+
+
+
+
+
+
+ 2. 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.
+
+
+
+
+ 38
+
+
+
+
+
+
+
+
+
+
+
+ The 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
+
+
+
+
+
+ 39
+
+
+
+
+
+
+
+
+
+
+
+ NOTE - 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.
+
+
+
+
+
+
+
+
+ 40
+
+
+
+
+
+
+
+
+
+
+
+ 6.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.
+
+
+
+
+
+
+
+
+
+ 41
+
+
+
+
+
+
+
+
+
+
+
+ NOTES
+
+ 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.
+
+
+
+
+
+
+
+
+
+ 42
+
+
+
+
+
+
+
+
+
+
+
+ 6.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).
+
+
+
+
+ 43
+
+
+
+
+
+
+
+
+
+
+
+ e) 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
+
+
+
+
+
+
+
+
+
+ 44
+
+
+
+
+
+
+
+
+
+
+
+ 6.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.
+
+
+
+
+
+ 45
+
+
+
+
+
+
+
+
+
+
+
+ 6.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:
+
+
+
+
+
+
+
+ 46
+
+
+
+
+
+
+
+
+
+
+
+ a) 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
+
+
+
+ 47
+
+
+
+
+
+
+
+
+
+
+
+ where 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;
+
+
+
+ 48
+
+
+
+
+
+
+
+
+
+
+
+ 2) 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.
+
+
+
+
+
+ 49
+
+
+
+
+
+
+
+
+
+
+
+ 6.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;
+
+
+
+
+ 50
+
+
+
+
+
+
+
+
+
+
+
+ b) 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 51
+
+
+
+
+
+
+
+
+
+
+
+ NOTES
+
+ 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:
+
+
+
+
+ 52
+
+
+
+
+
+
+
+
+
+
+
+ 1) 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
+
+
+
+ 53
+
+
+
+
+
+
+
+
+
+
+
+ transport 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:
+
+
+
+ 54
+
+
+
+
+
+
+
+
+
+
+
+ a) 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 55
+
+
+
+
+
+
+
+
+
+
+
+ 6.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.
+
+
+
+
+ 56
+
+
+
+
+
+
+
+
+
+
+
+ c) 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 57
+
+
+
+
+
+
+
+
+
+
+
+ NOTES
+
+ 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 |
+ | | |ED TPDU. |
+ +-------------------------------------------------------------+
+
+ Table 5. Acknowledgement of TPDUs
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 59
+
+
+
+
+
+
+
+
+
+
+
+ 6.14 Resynchronization
+
+ 6.14.1 Purpose
+
+ The resynchronization procedures are used in Classes 1 and 3 to
+ restore the transport connection to normal after a reset or
+ during reassignment after failure according to 6.12.
+
+
+
+
+ 6.14.2 Network service primitives
+
+ The procedure makes use of the following network service
+ primitive:
+
+ N-RESET indication.
+
+
+
+
+ 6.14.3 TPDUs and parameters used
+
+ The procedure uses the following TPDUs and parameters:
+
+ a) CR, DR, CC and DC TPDUs
+
+ b) RJ TPDUs;
+
+ - YR-TU-NR.
+
+ c) DT TPDU;
+
+ - TPDU-NR
+
+ d) ED TPDU;
+
+ - ED TPDU-NR.
+
+ e) EA TPDU;
+
+ - YR-EDTU-NR.
+
+
+
+
+ 60
+
+
+
+
+
+
+
+
+
+
+
+ 6.14.4 Procedure
+
+ A transport entity which is notified of the occurence of an N-
+ RESET or which is performing 'reassignment after failure'
+ according to 6.12 shall carry out the active resynchronization
+ procedure (see 6.14.4.1) unless any of the following hold:
+
+ a) the transport entity is the responder (see note). In this
+ case the passive resynchronization procedure is carried
+ out (see 6.14.4.2).
+
+ b) the transport entity has elected not to reassign (see
+ 6.12.3.c). In this case no resynchronization takes place.
+
+
+
+
+ 6.14.4.1 Active resynchronization procedures
+
+ The Transport entity shall carry out one of the following
+ actions:
+
+ a) if the TTR timer has been previously started and has run
+ out (i.e. no valid TPDU has been received), the transport
+ connection is considered as released and the reference is
+ frozen (see 6.18).
+
+ b) otherwise, the TTR timer shall be started (unless it is
+ already running) and the first applicable of the following
+ actions shall be taken:
+
+ 1) if a CR TPDU is unacknowledged, then the transport
+ entity shall retransmit it;
+
+ 2) if a DR TPDU is unacknowledged, then the transport
+ entity shall retransmit it;
+
+ 3) otherwise, the transport entity shall carry out the
+ data resynchronization procedures (6.14.4.3).
+
+ The TTR timer is stopped when a valid TPDU is received.
+
+
+
+
+
+ 61
+
+
+
+
+
+
+
+
+
+
+
+ 6.14.4.2 Passive resynchronization procedures
+
+ The transport entity shall not send any TPDUs until a TPDU has
+ been received. The transport entity shall start its TWR timer if
+ it was not already started (due to a previous N-DISCONNECT or N-
+ RESET indication). If the timer runs out prior to the receipt of
+ a valid TPDU which commence resynchronization (i.e. CR or DR or
+ RJ TPDU) the transport connection is considered as released and
+ the reference is released (see 6.18).
+
+ When a valid TPDU is received the transport entity shall stop its
+ TWR timer and carry out the appropriate one of the following
+ actions, depending on the TPDU:
+
+ a) if it is a DR TPDU, then the transport entity shall send a
+ DC TPDU;
+
+ b) if it is a repeated CR TPDU (see note 1) then the
+ transport entity shall carry out the appropriate action
+ from the following:
+
+ 1) if a CC TPDU has already been sent, and acknowledged:
+ treat as a protocol error;
+
+ 2) if a DR TPDU is unacknowledged (whether or not a CC
+ TPDU is unacknowledged): retransmit the DR TPDU, but
+ setting the source reference to zero;
+
+ 3) if the T-CONNECT response has not yet been received
+ from the user: take no action;
+
+ 4) otherwise; retransmit the CC TPDU followed by an
+ unacknowledged ED TPDU (see note 2) and any DT TPDU;
+
+ NOTES
+
+ 1. A repeated CR TPDU can be identified by being on a
+ network connection with the appropriate network
+ addresses and having a correct source reference.
+
+
+
+
+
+
+
+ 62
+
+
+
+
+
+
+
+
+
+
+
+ 2. The transport entity should not use network expedited
+ until the CC TPDU is acknowledged (see 6.5). This
+ rule prevents the network expedited from overtaking
+ the CC TPDU.
+
+ c) if it is an RJ or ED TPDU then one of the following
+ actions shall be taken:
+
+ 1) if a DR TPDU is unacknowledged, then the transport
+ entity shall retransmit it;
+
+ 2) otherwise, the transport entity shall carry out the
+ data resynchronization procedures (6.14.4.3).
+
+ 3) If a CC TPDU was unacknowledge, the RJ or ED TPDU
+ should then be considered as acknowledging the CC
+ TPDU. If a CC TPDU was never sent, the RJ TPDU should
+ then be considered as a protocol error.
+
+
+
+
+ 6.14.4.3 Data Resynchronization Procedures
+
+ The transport entity shall carry out the following actions in the
+ following order:
+
+ a) (re)transmit any ED TPDU which is unacknowledged,
+
+ b) transmit an RJ TPDU with YR-TU-NR field set to the TPDU-NR
+ of the next expected DT TPDU;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 63
+
+
+
+
+
+
+
+
+
+
+
+ c) wait for the next TPDU from the other transport entity,
+ unless an RJ or DR TPDU has already been received; if a DR
+ TPDU is received the transport entity shall send a DC,
+ freeze the reference, inform the TS-user of the
+ disconnection and take no further action (i.e. it shall
+ not follow the procedures in 6.14.4.3.d). If an RJ TPDU
+ is received, the procedure of 6.14.4.3.d shall be
+ followed. If an ED TPDU is received the procedures as
+ described in 6.11 shall be followed. If it is a
+ duplicated ED-TPDU the transport entity shall acknowledge
+ it, with an EA TPDU, discard the duplicated ED TPDU and
+ wait again for the next TPDU.
+
+ d) (re)transmit any DT TPDUs which are unacknowledged,
+ subject to any applicable flow control procedures (see
+ note);
+
+ NOTE - The RJ TPDU may have reduced the credit.
+
+
+
+
+ 6.15 Multiplexing and demultiplexing
+
+ 6.15.1 Purpose
+
+ The multiplexing and demultiplexing procedures are used in
+ Classes 2, 3 and 4 to allow several transport connections to
+ share a network connection at the same time.
+
+
+
+
+ 6.15.2 TPDUs and parameters used
+
+ The procedure makes use of the following TPDUs and parameters:
+
+ CC, DR, DC, DT, AK, ED, EA, RJ and ER TPDUs
+
+ - DST-REF
+
+
+
+
+
+
+ 64
+
+
+
+
+
+
+
+
+
+
+
+ 6.15.3 Procedure
+
+ The transport entities shall be able to send and receive on the
+ same network connection TPDUs belonging to different transport
+ connections.
+
+ NOTES
+
+ 1. When performing demultiplexing the transport connection to
+ which the TPDUs apply is determined by the procedures
+ defined in 6.9.
+
+ 2. Multiplexing allows the concatenation of TPDUs belonging
+ to different transport connections to be transferred in
+ the same N-DATA primitive (see 6.4).
+
+
+
+
+ 6.16 Explicit Flow Control
+
+ 6.16.1 Purpose
+
+ The explicit flow control procedure is used in Classes 2, 3 and 4
+ to regulate the flow of DT TPDUs independently of the flow
+ control in the other layers.
+
+
+
+
+ 6.16.2 TPDUs and parameters used
+
+ The procedure makes use of the following TPDUs and parameters:
+
+ a) CR, CC, AK and RJ TPDUs
+
+ - CDT.
+
+ b) DT TPDU
+
+ - TPDU-NR.
+
+
+
+
+
+ 65
+
+
+
+
+
+
+
+
+
+
+
+ c) AK TPDU
+
+ - YR-TU-NR;
+ - subsequence number;
+ - flow control confirmation.
+
+ d) RJ TPDU
+
+ - YR-TU-NR.
+
+
+
+
+ 6.16.3 Procedure
+
+ The procedures differ in different classes. They are defined in
+ the clauses specifying the separate classes.
+
+
+
+
+ 6.17 Checksum
+
+ 6.17.1 Purpose
+
+ The checksum procedure is used to detect corruption of TPDUs by
+ the NS-provider.
+
+ NOTE - Although a checksum algorithm has to be adapted to the
+ type of errors expected on the network connection, at present
+ only one algorithm is defined.
+
+
+
+
+ 6.17.2 TPDUs and parameters used
+
+ The procedure uses the following TPDUs and parameters:
+
+ All TPDUs
+ - checksum
+
+
+
+
+
+ 66
+
+
+
+
+
+
+
+
+
+
+
+ 6.17.3 Procedure
+
+ The checksum is used only in Class 4. It is always used for the
+ CR TPDU, and is used for all other TPDUs except if the non-use of
+ the procedure was agreed during connection establishment.
+
+ The sending transport entity shall transmit TPDUs with the
+ checksum parameter set such that the following formulas are
+ satisfied:
+
+ SUM(from i=1 to i=L) OF a[i] EQUALS <zero> (module 255)
+
+ SUM(from i=1 to i=L) OF i*a[i] EQUALS <zero> (module 255)
+
+ where
+
+ i = number (i.e. position) of an octet within the TPDU
+ (see 13.2);
+ a[i] = value of octet in position 1;
+ L = length of TPDU in octets.
+
+ A transport entity which receives a TPDU for a transport
+ connection for which the use of checksum has been agreed and
+ which does not satisfy the above formulas shall discard the TPDU
+ (see also note 2).
+
+ NOTES
+
+ 1. An efficient algorithm for determining the checksum
+ parameters is given in annex B.
+
+ 2. If the checksum is incorrect, it is not possible to know
+ with certainty to which transport connection the TPDU is
+ related; further action may be taken for all the transport
+ connections assigned to the network connection (see 6.9).
+
+ 3. The checksum proposed is easy to calculate and so will not
+ impose a heavy burden on implementations. However, it
+ will not detect insertion or loss of leading or trailing
+ zeros and will not detect some octets misordering.
+
+
+
+
+
+
+ 67
+
+
+
+
+
+
+
+
+
+
+
+ 6.18 Frozen references
+
+ 6.18.1 Purpose
+
+ This procedure is used in order to prevent re-use of a reference
+ while TPDUs associated with the old use of the reference may
+ still exist.
+
+
+
+
+ 6.18.2 Procedure
+
+ When a transport entity determines that a particular connection
+ is released it shall place the reference which it has allocated
+ to the connection in a frozen state according to the procedures
+ of the class. While frozen, the reference shall not be re-used.
+
+ NOTE - The frozen reference procedure is necessary because
+ retransmission or misordering can cause TPDUs bearing a reference
+ to arrive at an entity after it has released the connection for
+ which it allocated the reference. Retransmission, for example,
+ can arise when the class includes either resynchronization (see
+ 6.14) or retransmission on time out (see 6.19).
+
+
+
+
+ 6.18.2.1 Procedure for classes 0 and 2
+
+ The frozen reference procedure is never used for these classes.
+
+ NOTE - However for consistency with the other classes freezing
+ the references may be done as a local decision.
+
+
+
+
+
+
+
+
+
+
+
+
+ 68
+
+
+
+
+
+
+
+
+
+
+
+ 6.18.2.2 Procedure for classes 1 and 3
+
+ The frozen reference procedure is used except in the following
+ cases (see note 1):
+
+ a) when the transport entity receives a DC TPDU in response
+ to a DR TPDU which it has sent (see note 2);
+
+ b) when the transport entity sends a DR or ER TPDU in
+ response to a CR TPDU which it has received (see note 3);
+
+ c) when the transport entity has considered the connection to
+ be released after the expiration of the TWR timer (see
+ note 4);
+
+ d) when the transport entity receives a DR or ER TPDU in
+ response to a CR TPDU which it has sent.
+
+ The period of time for which the reference remains frozen shall
+ be greater than the TWR time.
+
+ NOTES
+
+ 1. However, even in these cases, for consistency freezing the
+ reference may be done as a local decision.
+
+ 2. When the DC TPDU is received it is certain that the other
+ transport entity considers the connection released.
+
+ 3. When the DR or ER TPDU is sent the peer transport entity
+ has not been informed of any reference assignment and thus
+ cannot possibly make use of a reference (this includes the
+ case where a CC TPDU was sent, but was lost).
+
+ 4. In 6.18.2.c the transport entity has already effectively
+ frozen the reference for an adequate period.
+
+
+
+
+
+
+
+
+
+
+ 69
+
+
+
+
+
+
+
+
+
+
+
+ 6.18.2.3 Procedure for classes 4
+
+ The frozen reference procedure is always used in class 4. The
+ period for which the reference remains frozen should be greater
+ than L (see 12.2.1.1.6).
+
+
+
+
+ 6.19 Retransmission on time-out
+
+ 6.19.1 Purpose
+
+ The procedure is used in Class 4 to cope with unsignalled loss of
+ TPDUs by the NS-provider.
+
+
+
+
+ 6.19.2 TPDUs used
+
+ The procedure makes use of the following TPDUs:
+
+ CR, CC, DR, DT, ED, AK TPDUs.
+
+
+
+
+ 6.19.3 Procedure
+
+ The procedure is specified in the procedures for Class 4 (see
+ 12.2.1.2.j).
+
+
+
+
+ 6.20 Resequencing
+
+
+
+
+
+
+
+
+
+ 70
+
+
+
+
+
+
+
+
+
+
+
+ 6.20.1 Purpose
+
+ The resequencing procedure is used in Class 4 to cope with
+ misordering of TPDUs by the network service provider.
+
+
+
+
+ 6.20.2 TPDUs and parameters used
+
+ The procedure uses the following TPDUs and parameters:
+
+ a) DT TPDU;
+ - TPDU-NR.
+
+ b) ED TPDU
+ - ED TPDU-NR
+
+
+
+
+ 6.20.3 Procedure
+
+ The procedure is specified in the procedures for Class 4 (see
+ 12.2.3.5).
+
+
+
+
+ 6.21 Inactivity control
+
+ 6.21.1 Purpose
+
+ The inactivity control procedure is used in Class 4 to cope with
+ unsignalled termination of a network connection.
+
+
+
+
+
+
+
+
+
+
+
+ 71
+
+
+
+
+
+
+
+
+
+
+
+ 6.21.2 Procedure
+
+ The procedure is specified in the procedures for Class 4 (see
+ 12.2.3.3).
+
+
+
+
+ 6.22 Treatment of protocol errors
+
+ 6.22.1 Purpose
+
+ The procedure for treatment of protocol errors is used in all
+ classes to deal with invalid TPDUs.
+
+
+
+
+ 6.22.2 TPDUs and parameters used
+
+ The procedure uses the following TPDUs and parameters:
+
+ a) ER TPDU;
+ - reject cause;
+ - TPDU in error.
+
+ b) DR TPDU;
+ - reason code.
+
+
+
+
+ 6.22.3 Procedure
+
+ A transport entity that receives a TPDU that can be associated to
+ a transport connection and is invalid or constitutes a protocol
+ error (see 3.2.16 and 3.2.17) shall take one of the following
+ actions so as not to jeopardize any other transport connections
+ not assigned to that network connection:
+
+ a) ignoring the TPDU;
+
+ b) transmitting an ER TPDU;
+
+
+
+ 72
+
+
+
+
+
+
+
+
+
+
+
+ c) resetting or closing the network connection; or
+
+ d) invoking the release procedures appropriate to the class.
+
+ If an ER TPDU is sent in Class 0 it shall contain the octets of
+ the invalid TPDU up to and including the octet where the error
+ was detected (see notes 3, 4 and 5).
+
+ If the TPDU cannot be associated to a particular transport
+ connection then see 6.9.
+
+ NOTES
+
+ 1. In general, no further action is specified for the
+ receiver of the ER TPDU but it is recommended that it
+ initiates the release procedure appropriate to the class.
+ If the ER TPDU has been received as an answer to a CR TPDU
+ then the connection is regarded as released (see 6.6).
+
+ 2. Care should be taken by a transport entity receiving
+ several invalid TPDUs or ER TPDUs to avoid looping if the
+ error is generated repeatedly.
+
+ 3. If the invalid received TPDU is greater than the selected
+ maximum TPDU size it is possible that it cannot be
+ included in the invalid TPDU parameter of the ER TPDU.
+
+ 4. It is recommended that the sender of the ER TPDU starts an
+ optional timer TS2 to ensure the release of the
+ connection. If the timer expires, the transport entity
+ shall initiate the release procedures appropriate to the
+ class. The timer should be stopped when a DR TPDU or an
+ N-DISCONNECT indication is received.
+
+ 5. In classes other than 0, it is recommended that the
+ invalid TPDU be also included in the ER TPDU.
+
+
+
+
+
+
+
+
+
+
+ 73
+
+
+
+
+
+
+
+
+
+
+
+ 6.23 Splitting and recombining
+
+ 6.23.1 Purpose
+
+ This procedure is used only in class 4 to allow a transport
+ connection to make use of multiple network connections to provide
+ additional resilience against network failure, to increase
+ throughput, or for other reasons.
+
+
+
+
+ 6.23.2 Procedure
+
+ When this procedure is being used, a transport connection may be
+ assigned (see 6.1) to multiple network connections (see note 1).
+ TPDUs for the connection may be sent over any such network
+ connection.
+
+ If the use of Class 4 is not accepted by the remote transport
+ entity following the negotiation rules, then no network
+ connection except that over which the CR TPDU was sent may have
+ this transport connection assigned to it.
+
+ NOTES
+
+ 1. The resequencing function of Class 4 (see 6.20) is used to
+ ensure that TPDUs are processed in the correct sequence.
+
+ 2. Either transport entity may assign the connection to
+ further network connections of which it is the owner at
+ any time during the life of the transport connection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 74
+
+
+
+
+
+
+
+
+
+
+
+ 3. In order to enable the detection of unsignalled network
+ connection failures, a transport entity performing
+ splitting should ensure that TPDUs are sent at intervals
+ on each supporting network connection, for example, by
+ sending successive TPDUs on successive network
+ connections, where the set of network connections is used
+ cyclically. By monitoring each network connection, a
+ transport entity may detect unsignalled network connection
+ failures, following the inactivity procedures defined in
+ 12.2.3.3. Thus, for each network connection no period I
+ (see 12.2.3.1) may elapse without the receipt of some TPDU
+ for some transport connection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 75
+
+
+
+
+
+
+
+
+
+
+
+ 7 Protocol Classes
+
+ Table 6 gives an overview of which elements of procedure are
+ included in each class. In certain cases the elements of
+ procedure within different classes are not identical and, for
+ this reason, table 6 cannot be considered as part of the
+ definitive specification of the protocol.
+
+
+
+ KEY TO TABLE 6
+
+ +---|---------------------------------------------------------+
+ | * |Procedure always included in class |
+ |---|---------------------------------------------------------|
+ | |Not applicable |
+ |---|---------------------------------------------------------|
+ | m |Negotiable procedure whose implementation in equipment is|
+ | |mandatory |
+ |---|---------------------------------------------------------|
+ | o |Negotiable procedure whose implementation in equipment is|
+ | |optional |
+ |---|---------------------------------------------------------|
+ | ao|Negotiable procedure whose implementation in equipment is|
+ | |optional and where use depends on availability within the|
+ | |network service |
+ |---|---------------------------------------------------------|
+ |(1)|Not applicable in class 2 when non-use of explicit flow |
+ | |control is selected |
+ |---|---------------------------------------------------------|
+ |(2)|When non use of explicit flow control has been selected, |
+ | |multiplexing may lead to degradation of quality of |
+ | |service |
+ |---|---------------------------------------------------------|
+ |(3)|This function is provided in class 4 using procedures |
+ | |other than those in the cross reference. |
+ +-------------------------------------------------------------+
+
+
+
+
+
+
+
+
+
+ 76
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ +----------------------------------------------------------------+
+ | |Cross | | | | | | |
+ | Protocol Mechanism |refe- | Variant | 0| 1| 2| 3| 4|
+ | |rence | | | | | | |
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Assignment to network Conn. | 6.1 | | *| *| *| *| *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | TPDU Transfer | 6.2 | | *| *| *| *| *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Segmenting and Reassembling | 6.3 | | *| *| *| *| *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Concatenation and Separation| 6.4 | | | *| *| *| *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Connection Establishment | 6.5 | | *| *| *| *| *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Connection Refusal | 6.6 | | *| *| *| *| *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Normal Release | 6.7 | implicit | *| | | | |
+ | | | explicit | | *| *| *| *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Error Release | 6.8 | | *| | *| | |
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Association of TPDUs with | | | | | | | |
+ | Transport Connection | 6.9 | | *| *| *| *| *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | DT TPDU Numbering | 6.10 | normal | | *|m(1)m| m|
+ | | | extended | | |o(1)o| o|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Expedited Data Transfer | 6.11 | network | | | *| | |
+ | | | normal | | m|(1) *| *|
+ | | | network | | | | | |
+ | | | expedited | |ao| | | |
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Reassignment after failure | 6.12 | | | *| | *|(3)
+ +----------------------------------------------------------------+
+
+ Table 6. (First of 2 pages) Allocation of procedures within classes
+
+
+
+
+
+ 77
+
+
+
+
+
+
+
+
+
+
+
+ +----------------------------------------------------------------+
+ | Retention until Acknowledge-| |Conf.Receipt| |ao| | | |
+ | ment of TPDUs | 6.13 |AK | | m| | | *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Resynchronisation | 6.14 | | | *| | *|(3)
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Multiplexing and | | | | |(2) | |
+ | Demultiplexing | 6.15 | | | | *| *| *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Explicit Flow Control With | 6.16 | | | | m| *| *|
+ | Without | | | *| *| o| | |
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Checksum (use of) | 6.17 | | | | | | m|
+ | (non-use of) | | | *| *| *| *| o|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Frozen References | 6.18 | | | *| | *| *|
+ |------------------------------------|------------|--|--|--|--|--|
+ | Retransmission on Timeout | 6.19 | | | | | | *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Resequencing | 6.20 | | | | | | *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Inactivity Control | 6.21 | | | | | | *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Treatment of Protocol Errors| 6.22 | | *| *| *| *| *|
+ |-----------------------------|------|------------|--|--|--|--|--|
+ | Splitting and Recombining | 6.23 | | | | | | *|
+ +----------------------------------------------------------------+
+
+ Table 6. (2nd of 2 pages) Allocation of procedures within classes
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 78
+
+
+
+
+
+
+
+
+
+
+
+ 8 SPECIFICATION FOR CLASS 0. SIMPLE CLASS
+
+ 8.1 Functions of class 0
+
+ Class 0 is designed to have minimum functionality. It provides
+ only the functions needed for connection establishment with
+ negotiation, data transfer with segmenting and protocol error
+ reporting.
+
+ Class 0 provides transport connections with flow control based on
+ the network service provided flow control, and disconnection
+ based on the network service disconnection.
+
+
+
+
+ 8.2 Procedures for class 0
+
+ 8.2.1 Procedures applicable at all times
+
+ The transport entities shall use the following procedures:
+
+ a) TPDU transfer (see 6.2);
+
+ b) association of TPDUs with transport connections (see 6.9);
+
+ c) treatment of protocol errors (see 6.22);
+
+ d) error release (see 6.8).
+
+
+
+
+ 8.2.2 Connection establishment
+
+ The transport entities shall use the following procedures:
+
+ a) assignment to network connection (see 6.1); then
+
+ b) connection establishment (see 6.5) and, if appropriate,
+ connection refusal (see 6.6);
+
+ subject to the following constraints:
+
+
+
+ 79
+
+
+
+
+
+
+
+
+
+
+
+ c) the CR and CC TPDUs shall contain no parameter field other
+ than those for TSAP-ID and maximum TPDU size;
+
+ d) the CR and CC TPDUs shall not contain a data field.
+
+
+
+
+ 8.2.3 Data transfer
+
+ The transport entities shall use the segmenting and reassembling
+ procedure (see 6.3).
+
+
+
+
+ 8.2.4 Release
+
+ The transport entities shall use the implicit variant of the
+ normal release procedure (see 6.7).
+
+ NOTE - the lifetime of the transport connection is directly
+ correlated with the lifetime of the network connection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 80
+
+
+
+
+
+
+
+
+
+
+
+ 9 SPECIFICATION FOR CLASS 1: BASIC ERROR RECOVERY CLASS
+
+ 9.1 Functions of Class 1
+
+ Class 1 provides transport connections with flow control based on
+ the network service provided flow control, error recovery,
+ expedited data transfer, disconnection, and also the ability to
+ support consecutive transport connections on a network
+ connection.
+
+ This class provides the functionality of Class 0 plus the ability
+ to recover after a failure signalled by the Network Service,
+ without involving the TS-user.
+
+
+
+
+ 9.2 Procedures for Class 1
+
+ 9.2.1 Procedures applicable at all times
+
+ The transport entities shall use the following procedures:
+
+ a) TPDU transfer (see 6.2);
+
+ b) association of TPDU with transport connections (see 6.9);
+
+ c) treatment of protocol errors (see 6.22);
+
+ d) reassignment after failure (see 6.12);
+
+ e) resynchronization (see 6.14), or reassignment after
+ failure (see 6.12) together with resynchronization (see
+ 6.14);
+
+ f) concatenation and separation (see 6.4);
+
+ g) retention until acknowledgement of TPDU (see 6.13); the
+ variant used, AK or confirmation of receipt, shall be as
+ selected during connection establishment (see notes);
+
+ h) frozen references (see 6.18).
+
+
+
+
+ 81
+
+
+
+
+
+
+
+
+
+
+
+ NOTES
+
+ 1. The negotiation of the variant of retention until
+ acknowledgement of TPDUs procedure to be used over the
+ transport connection has been designed such that if the
+ initiator proposes the use of the AK variant (i.e. the
+ mandatory implementation option), the responder has to
+ accept use of this option and if the initiator proposes
+ use of the confirmation of receipt variant the responder
+ is entitled to select use of the AK variant.
+
+ 2. The AK variant makes use of AK TPDUs to release copies of
+ retained DT TPDUs. The CDT parameter of AK TPDUs in class
+ 1 is not significant, and is set to 1111.
+
+ 3. The confirmation of receipt variant is restricted to this
+ class and its use depends on the availability of the
+ network layer receipt confirmation service, and the
+ expected cost reduction.
+
+
+
+
+ 9.2.2 Connection establishment
+
+ The transport entities shall use the following procedures:
+
+ a) assignment to network connection (see 6.1); then
+
+ b) connection establishment (see 6.5) and, if appropriate,
+ connection refusal (see 6.6).
+
+
+
+
+ 9.2.3 Data Transfer
+
+ 9.2.3.1 General
+
+ The sending transport entity shall use the following procedures;
+
+ a) segmenting (see 6.3); then
+
+
+
+
+ 82
+
+
+
+
+
+
+
+
+
+
+
+ b) the normal format variant of DT TPDU numbering (see 6.10).
+
+ The receiving transport entity shall use the following
+ procedures;
+
+ c) the normal variant of DT TPDU numbering (see 6.10,; then
+
+ d) reassembling (see 6.3).
+
+ NOTES
+
+ 1. The use of RJ TPDU during resynchronization (see 6.14) can
+ lead to retransmission. Thus the receipt of a duplicate
+ DT TPDU is possible; such a DT TPDU is discarded.
+
+ 2. It is possible to decide on a local basis to issue an N-
+ RESET request in order to force the remote entity to carry
+ out the resynchronization (see 6.14).
+
+
+
+
+ 9.2.3.2 Expedited Data
+
+ The transport entities shall use either the network normal data
+ or the network expedited variants of the expedited data transfer
+ procedure (see 6.11) if their use has been selected during
+ connection establishment (see note 1).
+
+ The sending transport entity shall not allocate the same ED-
+ TPDU-NR to successive ED TPDUs (see notes 2 and 3).
+
+ When acknowledging an ED TPDU by sending and EA TPDU the
+ transport entity shall put into the YR-EDTU-NR parameter of the
+ EA TPDU the value received in the ED-TPDU-NR parameter of the ED
+ TPDU.
+
+ NOTES
+
+ 1. The negotiation of the variant of expedited data transfer
+ procedure to be used over the transport connection has
+ been designed such that if the initiator proposes the use
+ of the network normal data variant (i.e. the mandatory
+
+
+
+ 83
+
+
+
+
+
+
+
+
+
+
+
+ implementation option), the responder has to accept use of
+ this option and if the initiator proposes use of the
+ network expedited variant, the responder is entitled to
+ select use of the network normal data variant.
+
+ 2. This numbering enables the receiving transport entity to
+ discard repeated ED TPDUs when resynchronization (see
+ 6.14) has taken place.
+
+ 3. No other significance is attached to the ED TPDU-NR
+ parameter. It is recommended, but not essential, that the
+ values used be consecutive modulo 128.
+
+
+
+
+ 9.2.4 Release
+
+ The transport entities shall use the explicit variant of the
+ release procedure (see 6.7).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 84
+
+
+
+
+
+
+
+
+
+
+
+ 10 SPECIFICATION FOR CLASS 2 - MULTIPLEXING CLASS
+
+ 10.1 Functions of class 2
+
+ Class 2 provides transport connections with or without individual
+ flow control; no error detection or error recovery is provided.
+
+ If the network connection resets or disconnects, the transport
+ connection is terminated without the transport release procedure
+ and the TS-user is informed.
+
+ When explicit flow control is used, a credit mechanism is defined
+ allowing the receiver to inform the sender of the exact amount of
+ data he is willing to receive and expedited data transfer is
+ available.
+
+
+
+
+ 10.2 Procedures for class 2
+
+ 10.2.1 Procedures applicable at all times
+
+ The transport entities shall use the following procedures
+
+ a) association of TPDUs with transport connection (see 6.9);
+
+ b) TPDU transfer (see 6.2);
+
+ c) treatment of protocol errors (see 6.22);
+
+ d) concatenation and separation (see 6.4);
+
+ e) error release (see 6.8).
+
+ Additionally the transport entities may use the following
+ procedure:
+
+ f) multiplexing and demultiplexing (see 6.15).
+
+
+
+
+
+
+
+ 85
+
+
+
+
+
+
+
+
+
+
+
+ 10.2.2 Connection establishment
+
+ The transport entities shall use the following procedures:
+
+ a) assignment to network connection (see 6.1); then
+
+ b) connection establishment (see 6.5) and, if applicable
+ connection refusal (see 6.6).
+
+
+
+
+ 10.2.3 Data transfer when non use of explicit flow control
+
+ has been selected
+
+ If this option has been selected as a result of the connection
+ establishment, the transport entities shall use the segmenting
+ procedure (see 6.3).
+
+ The TPDU-NR field of DT TPDUs is not significant and may take any
+ value.
+
+ NOTE- -Expedited data transfer is not applicable (see 6.5).
+
+
+
+
+ 10.2.4 Data transfer when use of explicit flow control
+
+ has been selected
+
+
+
+ 10.2.4.1 General
+
+ The sending transport entity shall use the following procedures:
+
+ a) segmenting (see 6.3); then
+
+ b) DT TPDU numbering (see 6.10);
+
+
+
+
+
+ 86
+
+
+
+
+
+
+
+
+
+
+
+ The receiving transport entity shall use the following
+ procedures:
+
+ c) DT TPDU numbering (see 6.10); if a DT TPDU is received
+ which is out of sequence it shall be treated as a protocol
+ error; then
+
+ d) reassembling (see 6.3).
+
+ The variant of the DT TPDU numbering which is used by both
+ transport entities shall be that which was agreed at
+ connection establishment.
+
+
+
+
+ 10.2.4.2 Flow control
+
+ The transport entities shall send an initial credit (which may be
+ zero) in the CDT field of the CR or CC TPDU. This credit
+ represents the initial value of the upper window edge allocated
+ to the peer entity.
+
+ The transport entity that receives the CR or the CC TPDU shall
+ consider its lower window edge as zero, and its upper window edge
+ as the value of the CDT field in the received TPDU.
+
+ In order to authorize the transmission of DT TPDUs, by its peer,
+ a transport entity may transmit an AK TPDU at any time, subject
+ to the following constraints:
+
+ a) the YR-TU-NR parameter shall be at most one greater than
+ the TPDU-NR field of the last received DT TPDU or shall be
+ zero if no DT TPDU has been received;
+
+ b) if an AK TPDU has previously been sent the value of the
+ YR-TU-NR parameter shall not be lower than that in the
+ previously sent AK TPDU.
+
+ c) the sum of the YR-TU-NR and CDT fields shall not be less
+ than the upper window edge allocated to the remote entity
+ (see note 1).
+
+
+
+
+ 87
+
+
+
+
+
+
+
+
+
+
+
+ A transport entity which receives an AK TPDU shall consider the
+ YR-TU-NR field as its new lower window edge, and the sum of YR-
+ TU-NR and CDT as its new upper window edge. If either of these
+ have been reduced or if the lower window edge has become more
+ than one greater than the TPDU-NR of the last transmitted DT
+ TPDU, this shall be treated as a protocol error (see 6.22).
+
+ A transport entity shall not send a DT TPDU with a TPDU-NR
+ outside of the transmit window (see notes 2 and 3).
+
+ NOTES
+
+ 1. This means that credit reduction is not applicable.
+
+ 2. This means that a transport entity is required to stop
+ sending if the TPDU-NR field of the next DT TPDU which
+ would be sent would be the upper window edge. Sending of
+ DT TPDU may be resumed if an AK TPDU is received which
+ increases the upper window edge.
+
+ 3. The rate at which a transport entity progresses the upper
+ window edge allocated to its peer entity constrains the
+ throughput attainable on the transport connection.
+
+
+
+
+ 10.2.4.3 Expedited data
+
+ The transport entities shall follow the network normal variant of
+ the expedited data transfer procedure in 6.11 if its use has been
+ agreed during connection establishment. ED and EA TPDUs
+ respectively are not subject to the flow control procedures in
+ 10.2.4.2. The ED-TPDU-NR and YR-ETDU-NR fields of ED and EA
+ TPDUs respectively are not significant and may take any value.
+
+
+
+
+
+
+
+
+
+
+
+ 88
+
+
+
+
+
+
+
+
+
+
+
+ 10.2.5 Release
+
+ The transport entities shall use the explicit variant of the
+ release procedure in 6.7.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 89
+
+
+
+
+
+
+
+
+
+
+
+ 11 SPECIFICATION FOR CLASS 3: ERROR RECOVERY AND MULTIPLEXING
+ CLASS
+
+ 11.1 Functions of Class 3
+
+ Class 3 provides the functionality of Class 2 (with use of
+ explicit flow control) plus the ability to recover after a
+ failure signalled by the Network Layer without involving the user
+ of the transport service.
+
+ The mechanisms used to achieve this functionality also allow the
+ implementation of more flexible flow control.
+
+
+
+
+ 11.2 Procedures for Class 3
+
+ 11.2.1 Procedures applicable at all times
+
+ The transport entities shall use the following procedures:
+
+ a) association of TPDUs with transport connections (see 6.9);
+
+ b) TPDU transfer (see 6.2) and retention until
+ acknowledgement of TPDUs (AK variant only) (see 6.13);
+
+ c) treatment of protocol errors (see 6.22);
+
+ d) concatenation and separation (see 6.4);
+
+ e) reassignment after failure (see 6.12), together with
+ resynchronization (see 6.14);
+
+ f) frozen references (see 6.18).
+
+ Additionally, the transport entities may use the following
+ procedure:
+
+ g) multiplexing and demultiplexing (see 6.15);
+
+
+
+
+
+
+ 90
+
+
+
+
+
+
+
+
+
+
+
+ 11.2.2 Connection Establishment
+
+ The transport entities shall use the following procedures;
+
+ a) assignment to network connections (see 6.1); then
+
+ b) connection establishment (see 6.5) and, if appropriate,
+ together with connection refusal (see 6.6).
+
+
+
+
+ 11.2.3 Data Transfer
+
+ 11.2.3.1 General
+
+ The sending transport entity shall use the following procedures:
+
+ a) segmenting (see 6.3), then
+
+ b) DT TPDU numbering (see 6.10); after receipt of an RJ TPDU
+ (see 11.2.3.2) the next DT TPDU to be sent may have a
+ value which is not the previous value of TPDU-NR plus one.
+
+ The receiving transport entity shall use the following
+ procedures:
+
+ c) DT TPDU numbering (see 6.10); the TPDU-NR field of each
+ received DT TPDU shall be treated as a protocol error if
+ it exceeds the greatest such value received in a previous
+ DT TPDU by more than one (see note); then
+
+ d) reassembling (see 6.3); duplicated TPDUs shall be
+ eliminated before reassembling is performed.
+
+ NOTE - The use of RJ TPDUs (see 11.2.3.2) can lead to
+ retransmission and reduction of credit. Thus the receipt of a DT
+ TPDU which is a duplicate, or which is greater than or equal to
+ the upper window edge allocated to the peer entity, is possible
+ and is therefore not treated as a protocol error.
+
+
+
+
+
+
+ 91
+
+
+
+
+
+
+
+
+
+
+
+ 11.2.3.2 Use of RJ TPDU
+
+ A transport entity may send an RJ TPDU at any time in order to
+ invite retransmission or to reduce the upper window edge
+ allocated to the peer entity (see note 1).
+
+ When an RJ TPDU is sent, the following constraints shall be
+ respected:
+
+ a) the YR-TU-NR parameter shall be at most one greater than
+ the greatest such value received in a previous DT TPDU, or
+ shall be zero if no DT TPDU has yet been received (see
+ note 2);
+
+ b) if an AK or RJ TPDU has previously been sent the YR-TU-NR
+ parameter shall not be lower than that in the previously
+ sent AK or RJ TPDU or lower than zero if no AK or RJ TPDU.
+
+ When a transport entity receives an RJ TPDU (see note 3):
+
+ c) the next DT TPDU to be transmitted, or retransmitted,
+ shall be that for which the value of the TPDU-NR parameter
+ is equal to the value of the YR-TU-NR parameter of the RJ
+ TPDU;
+
+ d) the sum of the values of the YR-TU-NR and CDT parameters
+ of the RJ TPDU becomes the new upper window edge (see note
+ 4).
+
+ NOTES
+
+ 1. An RJ TPDU can also be sent as part of the
+ resynchronization (see 6.14) and reassignment after
+ failure (see 6.12) procedures.
+
+ 2. It is recommended that the YR-TU-NR parameter be equal to
+ the TPDU-NR parameter of the next expected DT TPDU.
+
+ 3. These rules are a subset of those specified for when an RJ
+ TPDU is received during resynchronization (see 6.14) and
+ reassignment after failure (see 6.12).
+
+
+
+
+
+ 92
+
+
+
+
+
+
+
+
+
+
+
+ 4. This means that RJ TPDU can be used to reduce the upper
+ window edge allocated to the peer entity (credit
+ reduction).
+
+
+
+
+ 11.2.3.3 Flow Control
+
+ The procedures shall be as defined in 10.2.4.2, except that:
+
+ a) a credit reduction may lead to the reception of a DT TPDU
+ with a TPDU-NR parameter whose value is not, but would
+ have been less than the upper window edge allocated to the
+ remote entity prior to the credit reduction. This shall
+ not be treated as a protocol error;
+
+ b) receipt of an AK TPDU which sets the lower window edge
+ more than one greater than the TPDU-NR of the last
+ transmitted DT TPDU shall not be treated as a protocol
+ error, provided that all acknowledged DT TPDUs have been
+ previously transmitted (see notes 1 and 2).
+ NOTES
+
+ 1. This can only occur during retransmission following
+ receipt of an RJ TPDU.
+
+ 2. The transport entity may either continue retransmission as
+ before or retransmit only those DT TPDUs, not acknowledged
+ by the AK TPDU. In either case, copies of the
+ acknowledged DT TPDUs, need not be retained further.
+
+
+
+
+ 11.2.3.4 Expedited data
+
+ The transport entities shall follow the network normal data
+ variant of expedited data transfer procedure in 6.11 if its use
+ has been agreed during connection establishment.
+
+ The sending transport entity shall not allocate the same ED-
+ TPDU-NR to successive ED TPDUs.
+
+
+
+ 93
+
+
+
+
+
+
+
+
+
+
+
+ The receiving transport entity shall transmit an EA TPDU with the
+ same value in its YR-EDTU-NR parameter. If, and only if, this
+ number is different from that of the previously received ED TPDU
+ shall it generate a T-EXPEDITED DATA indication to convey the
+ data to the TS-user (see note 2).
+
+ NOTES
+
+ 1. No other significance is attached to the ED-TPDU-NR
+ parameter. It is recommended, but not essential, that the
+ values be consecutive modulo 2**n, where n is the number
+ of bits of the parameter.
+
+ 2. This procedure ensures that the TS-user does not receive
+ data corresponding to the same ED TPDU more than once.
+
+
+
+
+ 11.2.4 Release
+
+ The transport entities shall use the explicit variant of the
+ release procedure in 6.7.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 94
+
+
+
+
+
+
+
+
+
+
+
+ 12 SPECIFICATION FOR CLASS 4: ERROR DETECTION AND RECOVERY CLASS
+
+ 12.1 Functions of Class 4
+
+ Class 4 provides the functionality of Class 3, plus the ability
+ to detect and recover from lost, duplicated, or out of sequence
+ TPDUs without involving the TS-user.
+
+ This detection of errors is made by extended use of the DT TPDU
+ numbering of Class 2 and Class 3, by time-out mechanisms, and by
+ additional procedures.
+
+ This class additionally detects and recovers from damaged TPDUs
+ by using a checksum mechanism. The use of the checksum mechanism
+ must be available but its use or its non-use is subject to
+ negotiation.
+
+ Further on this class provides additional resilience against
+ network failure and increased throughput capability by allowing a
+ transport connection to make use of multiple network connections.
+
+
+
+
+ 12.2 Procedures for Class 4
+
+ 12.2.1 Procedures available at all times
+
+ 12.2.1.1 Timers used at all times
+
+ This subclause defines timers that apply at all times in class 4.
+ These timers are listed in table 7.
+
+ This International Standard does not define specific values for
+ the timers, and the derivations described in this subclause are
+ not mandatory. The values should be chosen so that the required
+ quality of service can be provided, given the known
+ characteristics of the network.
+
+ Timers that apply only to specific procedures are defined under
+ the appropriate procedure.
+
+
+
+
+
+ 95
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ +---------------------------|------------------------------------+
+ |Symbol| Name | Definition |
+ |------|--------------------|------------------------------------|
+ | MLR |NSDU lifetime | A bound for the maximum time which |
+ | |local-to-remote | may elapse between the transmis- |
+ | | | sion of an NSDU by a local trans- |
+ | | | port entity and the receipt of any |
+ | | | copy of it by a remote peer entity.|
+ | | | |
+ | MRL |NSDU lifetime | A bound for the maximum time which |
+ | |remote-to-local | may elapse between the transmission|
+ | | | of an SNDU from a remote transport |
+ | | | entity to a remote peer entity. |
+ | | | |
+ | ELR |Expected maximum | A bound for the maximum delay suf- |
+ | |transit delay | fered by all but a small proportion|
+ | |local-to-remote | of NSDUs transferred from the local|
+ | | | transport entity to a remote peer |
+ | | | entity. |
+ | | | |
+ | ERL |Expected maximum | A bound for the maximum delay suf- |
+ | |transit delay | fered by all but a small proportion|
+ | |remote-to-local | of NSDUs transferred from a remote |
+ | | | transport entity to the local peer |
+ | | | entity. |
+ | | | |
+ | AL |Local acknowledge | A bound for the maximum time which |
+ | |time | can elapse between the receipt of |
+ | | | a TPDU by the local transport en- |
+ | | | tity from the network layer and |
+ | | | the transmission of the corres- |
+ | | | ponding acknowledgement. |
+ | | | |
+ | AR |Remote acknow- | As AL, but for the remote entity. |
+ | |ledgement time | |
+ +----------------------------------------------------------------+
+
+ Table 7. (First of 2 pages) Time Parameters related to class 4
+
+
+
+
+ 96
+
+
+
+
+
+
+
+
+
+
+
+ +----------------------------------------------------------------+
+ | T1 |Local retrans- | A bound for the maximum time that |
+ | |mission time | the local transport entity will |
+ | | | wait for acknowledgement before re-|
+ | | | transmitting a TPDU. |
+ | | | |
+ | R |Persistence time | A bound for the maximum time the |
+ | | | the local transport entity will |
+ | | | continue to transmit a TPDU that |
+ | | | requires acknowledgement. |
+ | | | |
+ | N |Maximum number of | A bound for the maximum number of |
+ | |transmissions | times which the local transport |
+ | | | entity will continue to transmit a |
+ | | | TPDU that requires acknowledgement.|
+ | | | |
+ | L |Bound on references | A bound for the maximum time |
+ | |and sequence | between the transmission of a TPDU |
+ | |numbers | and the receipt of any acknow- |
+ | | | ledgement relating to it. |
+ | | | |
+ | I |Inactivity time | A bound for the time after which |
+ | | | a transport entity will, if it |
+ | | | does not receive a TPDU, initiate |
+ | | | the release procedure to terminate |
+ | | | the transport connection. |
+ | | | |
+ | | | NOTE - This parameter is required |
+ | | | for protection against unsignalled |
+ | | | breaks in the network connection. |
+ | | | |
+ | W |Window time | A bound for the maximum time a |
+ | | | transport entity will wait before |
+ | | | retransmitting up to date window |
+ | | | information. |
+ +----------------------------------------------------------------+
+
+ Table 7. (Second of 2 pages) Time Parameters related to class 4
+
+
+
+
+
+
+
+
+ 97
+
+
+
+
+
+
+
+
+
+
+
+ 12.2.1.1.1 NSDU lifetime (MLR, MRL)
+
+ The network layer is assumed to provide, as an aspect of its
+ grade of service, for a bound on the maximum lifetime of NSDUs in
+ the network. This value may be different in each direction of
+ transfer through a network between two transport entities. The
+ values, for both directions of transfer, are assumed to be Known
+ by the transport entities. The maximum NSDU lifetime local-to-
+ remote (MLR) is the maximum time which may elapse between the
+ transmission of an NSDU from the local transport entity to the
+ network and receipt of any copy of the NSDU from the network at
+ the remote transport entity. The maximum NSDU lifetime remote-
+ to-local (MRL) is the maximum time which may elapse between the
+ transmission of an NSDU from the remote transport entity to the
+ network and receipt of any copy of the NSDU from the network at
+ the local transport entity.
+
+
+
+
+ 12.2.1.1.2 Expected maximum transit delay (ELR, ERL)
+
+ The network layer is assumed to provide, as an aspect of its
+ grade of service, an expected maximum transit delay for NSDUs in
+ the network. This value may be different in each direction of
+ transfer through a network between two transport entities. The
+ values, for both directions of transfer, are assumed to be Known
+ by the transport entities. The expected maximum transit delay
+ local-to-remote (ELR) is the maximum delay suffered by all but a
+ small proportion of NSDUs transferred through the network from
+ the local transport entity to the remote transport entity. The
+ expected maximum transit delay remote-to-local (ERL) is the
+ maximum delay suffered by all but a small proportion of NSDUs
+ transfer through the network from the remove transport entity to
+ the local transport entity.
+
+
+
+
+
+
+
+
+
+
+
+ 98
+
+
+
+
+
+
+
+
+
+
+
+ 12.2.1.1.3 Acknowledge Time (AR, AL)
+
+ Any transport entity is assumed to provide a bound for the
+ maximum time which can elapse between its receipt of a TPDU from
+ the Network Layer and its transmission of the corresponding
+ response. This value is referred to as AL. The corresponding
+ time given by the remote transport entity is referred to as AR.
+
+
+
+
+ 12.2.1.1.4 Local retransmission time (T1)
+
+ The local transport entity is assumed to maintain a bound on the
+ time it will wait for an acknowledgement before retransmitting
+ the TPDU. Its value is given by:
+
+ T1 = ELR + ERL + AR + X
+
+ where:
+
+ ELR = Expected maximum transit delay local-to-remote,
+ ERL = Expected maximum transit delay remote-to-local,
+ AR = Remote acknowledge time, and
+ X = local processing time for a TPDU.
+
+
+
+
+ 12.2.1.1.5 Persistence Time (R)
+
+ The local transport entity is assumed to provide a bound for the
+ maximum time for which it may continue to retransmit a TPDU
+ requiring positive acknowledgement. This value is referred to as
+ R.
+
+ The value is clearly related to the time elapsed between
+ retransmission, T1, and the maximum number of transmissions, N.
+ It is not less than T1 * N + X, where X is a small quantity to
+ allow for additional internal delays, the granularity of the
+ mechanism used to implement T1 and so on. Because R is a bound,
+ the exact value of X is unimportant as long as it is bounded and
+ the value of a bound is known.
+
+
+
+ 99
+
+
+
+
+
+
+
+
+
+
+
+ 12.2.1.1.6 Bound on References and Sequence Numbers (L)
+
+ A bound for the maximum time between the decision to transmit a
+ TPDU and the receipt of any response relating to it (L) is given
+ by:
+
+ L = MLR + MRL + R + AR
+
+ where:
+
+ MLR = NSDU lifetime local-to-remote,
+ MRL = NSDU lifetime remote-to-local,
+ R = Persistence time, and
+ AR = Remote acknowledgement time.
+
+ It is necessary to wait for a period L before reusing any
+ reference of sequence number, to avoid confusion in case a TPDU
+ referring to it may be duplicated or delayed.
+
+ NOTES
+
+ 1. In practice, the value of L may be unacceptably large. It
+ may also be only a statistical figure at a certain
+ confidence level. A smaller value may therefore be used
+ where this still allows the required quality of service to
+ be provided.
+
+ 2. The relationships between times discussed above are
+ illustrated in figures 3 and 4.
+
+ [Figures 3 and 4 are omitted from this copy.]
+
+
+
+
+ 12.2.1.2 General Procedures
+
+ The transport entity shall use the following procedures:
+
+ a) TPDU transfer (see 6.2);
+
+ b) association of TPDUs with transport connections (see 6.9);
+
+
+
+
+ 100
+
+
+
+
+
+
+
+
+
+
+
+ c) treatment of protocol errors (see 6.22);
+
+ d) checksum (see 6.17);
+
+ e) splitting and recombining (see 6.23);
+
+ f) multiplexing and demultiplexing (see 6.15);
+
+ g) retention until acknowledgement of TPDUs (see 6.13);
+
+ h) frozen references (see 6.18).
+
+ j) retransmission procedures; when a transport entity has
+ some outstanding TPDUs that require acknowledgement, it
+ will check that no T1 interval elapses without the arrival
+ of a TPDU that acknowledges at least one of the
+ outstanding TPDUs.
+
+ If the timer expires, except if the TPDU to be
+ retransmitted is a DT TPDU and it is outside the transmit
+ window due credit reduction, the first TPDU is
+ retransmitted and the timer is restarted. After N
+ transmissions (i.e. N-1 retransmissions) it is assumed
+ that useful two-way communication is no longer possible
+ and the release procedure is used, and the TS-user is
+ informed.
+
+ NOTES
+
+ 1) This procedure may be implemented by different means. For
+ example:
+
+ a) one interval is associated with each TPDU. If the
+ timer expires the associated TPDU will be transmitted
+ and the timer T1 will be restarted for all subsequent
+ TPDUs; or
+
+ b) one interval is associated with each transport
+ connection:
+
+ 1) if the transport entity transmits a TPDU requiring
+ acknowledgement, it starts timer T1;
+
+
+
+
+ 101
+
+
+
+
+
+
+
+
+
+
+
+ 2) if the transport entity receives a TPDU that
+ acknowledges one of the TPDUs to be acknowledged,
+ it restarts timer T1 unless the received TPDU is
+ an AK which explicitly closes the transmit window.
+
+ 3) if the transport entity receives a TPDU that
+ acknowledges the last TPDU to be acknowledged, it
+ stops timer T1.
+
+ For a decision whether the retransmission timer T1 is
+ maintained on a per TPDU or on a per transport connection
+ basis, throughput considerations have to be taken into
+ account.
+
+ 2. For DT TPDUs it is a local choice to retransmit either
+ only the first DT TPDU or all TPDUs waiting for an
+ acknowledgement up to the upper window edge.
+
+ 3. It is recommended that after N transmissions of a DT TPDU,
+ the transport entity waits T1 + W + MRL to provide a
+ higher possibility of receiving an acknowledgement before
+ entering the release phase. For other TPDU types which
+ may be retransmitted, it is recommended that after N
+ transmissions the transport entity waits T1 + MRL to
+ provide a higher possibility of receiving the expected
+ reply.
+
+
+
+
+ 12.2.2 Procedures for Connection Establishment
+
+ 12.2.2.1 Timers used in Connection Establishment
+
+ There are no timers specific to connection establishment.
+
+
+
+
+
+
+
+
+
+
+
+ 102
+
+
+
+
+
+
+
+
+
+
+
+ 12.2.2.2 General Procedures
+
+ The transport entities shall use the following procedures:
+
+ a) assignment to network connection (see 6.1);
+
+ b) connection establishment (see 6.5) and if appropriate
+ connection refusal (see 6.6) together with the additional
+ procedures:
+
+ 1) a connection is not considered established until the
+ successful completion of a 3-way TPDU exchange. The
+ sender of a CR TPDU shall respond to the corresponding
+ CC TPDU by immediately sending a DT, ED, DR or AK
+ TPDU;
+
+ 2) as a result of duplication or retransmission, a CR
+ TPDU may be received specifying a source reference
+ which is already in use with the sending transport
+ entity. If the receiving transport entity is in the
+ data transfer phase, having completed the 3-way TPDU
+ exchange procedure, or is waiting for the T-CONNECT
+ response from the TS-user, the receiving transport
+ entity shall ignore such a TPDU. Otherwise a CC TPDU
+ shall be transmitted;
+
+ 3) as a result of duplication or retransmission, a CC
+ TPDU may be received specifying a paired reference
+ which is already in use. The receiving transport
+ entity shall only acknowledge the duplicate CC TPDU
+ according to the procedure in 12.2.2.2.b.1.
+
+ 4) a CC TPDU may be received specifying a reference which
+ is in the frozen state. The response to such a TPDU
+ shall be a DR TPDU;
+
+ 5) the retransmission procedures (see 12.2.1.2) are used
+ for both the CR TPDU and CC TPDU.
+
+
+
+
+
+
+
+
+ 103
+
+
+
+
+
+
+
+
+
+
+
+ 12.2.3 Procedures for Data Transfer
+
+ 12.2.3.1 Timers used in Data Transfer
+
+ The data transfer procedures use two additional timers:
+
+ a) Inactivity Time (I)
+
+ To protect against unsignalled breaks in the network
+ connection or failure of the peer transport entity (half-open
+ connections), each transport entity maintains an inactivity
+ interval. The interval must be greater than E.
+
+ NOTE - A suitable value for I is given by
+ 2 * (N * maximum of (T1, W))
+ unless local needs indicate another more appropriate value.
+
+ b) Window Time (W)
+
+ A transport entity maintains a timer interval to ensure that
+ there is a bound on the maximum interval between window
+ updates.
+
+
+
+
+ 12.2.3.2 General Procedures for data transfer
+
+ The transport entities shall use the following procedures:
+
+ a) inactivity control (see 6.21);
+
+ b) expedited data (see 6.11);
+
+ c) explicit flow control (see 6.16).
+
+ The sending transport entity shall use the following procedures
+ in the following order:
+
+ d) segmenting (see 6.3);
+
+ e) DT TPDU numbering (see 6.10).
+
+
+
+
+ 104
+
+
+
+
+
+
+
+
+
+
+
+ The receiving transport entity shall use the following procedures
+ in the following order:
+
+ f) DT TPDU numbering (see 6.10);
+
+ g) resequencing (see 6.20);
+
+ h) reassembling (see 6.3).
+
+
+
+
+ 12.2.3.3 Inactivity Control
+
+ If the interval of the inactivity timer I expires without receipt
+ of some TPDU, the transport entity shall initiate the release
+ procedures. To prevent expiration of the remote transport
+ entity's inactivity timer when no data is being sent, the local
+ transport entity must send AK TPDUs at suitable intervals in the
+ absence of data, having regard to the probability of TPDU loss.
+ The window synchronization procedures (see 12.2.3.8) ensure that
+ this requirement is met.
+
+ NOTE - It is likely that the release procedure initiated due to
+ the expiration of the inactivity timer will fail, as such
+ expiration indicates probable failure of the supporting network
+ connection or of the remote transport entity.
+
+
+
+
+ 12.2.3.4 Expedited Data
+
+ The transport entities shall follow the network normal data
+ variant of the expedited data transfer procedures (see 6.11), if
+ the use of transport expedited service option has been agreed
+ during connection establishment.
+
+ The ED TPDU shall have a TPDU-NR which is allocated from a
+ separate sequence space from that of the DT TPDUs.
+
+ A transport entity shall allocate the sequence number zero to the
+ ED TPDU-NR of the first ED TPDU which it transmits for a
+
+
+
+ 105
+
+
+
+
+
+
+
+
+
+
+
+ transport connection. For subsequent ED TPDU sent on the same
+ transport connection, the transport entity shall allocate a
+ sequence number one greater than the previous one.
+
+ Modulo 2**7 arithmetic shall be used when normal formats have
+ been selected and modulo 2**31 arithmetic shall be used when
+ extended formats have been selected.
+
+ The receiving transport entity shall transmit an EA TPDU with the
+ same sequence number in its YR-ETDU-NR field. If this number is
+ one greater than in the previously in sequence received ED TPDU,
+ the receiving transport entity shall transfer the data in the ED
+ TPDU to the TS-user.
+
+ If a transport entity does not receive an EA TPDU in
+ acknowledgement to an ED TPDU it shall follow the retransmission
+ procedures (see note and 12.2.1.2).
+
+ The sender of an ED TPDU shall not send any new DT TPDU with
+ higher TPDU-NR until it receives the EA TPDU.
+
+ NOTE - This procedure ensures that ED TPDUs are delivered to the
+ TS-user in sequence and that the TS-user does not receive data
+ corresponding to the same ED TPDU more than once. Also it
+ guarantees the arrival of the ED TPDU before any subsequently
+ sent DT TPDU.
+
+
+
+
+ 12.2.3.5 Resequencing
+
+ The receiving transport entity shall deliver all DT TPDUs to the
+ TS-user in the order specified by the sequence number field.
+
+ DT TPDUs received out-of-sequence but within the transmit window
+ shall not be delivered to the TS-user until all in-sequence TPDUs
+ have been received. DT TPDU received out-of-sequence and outside
+ the transmit window shall be discarded.
+
+ Duplicate TPDUs can be detected because the sequence number
+ matches that of preciously received TPDUs. Sequence numbers
+ shall not be reused for the period L after their previous use.
+
+
+
+ 106
+
+
+
+
+
+
+
+
+
+
+
+ Otherwise, a new, valid TPDU could be confused with a duplicated
+ TPDU which had previously been received and acknowledged.
+
+ Duplicated DT TPDUs shall be acknowledged, since the duplicated
+ TPDU may be the result of a retransmission resulting from the
+ loss of an AK TPDU.
+
+ The data contained in a duplicated DT TPDU shall be ignored.
+
+
+
+
+ 12.2.3.6 Explicit Flow Control
+
+ The transport entities shall send an initial credit (which may
+ take the value 0) in the CDT field of the CR TPDU or CC TPDU.
+ This credit represents the initial value of the upper window edge
+ of the peer entity.
+
+ The transport entity which receives the CR TPDU or CC TPDU shall
+ consider its lower window edge as zero and its upper window edge
+ as the value in the CDT field in the received TPDU.
+
+ In order to authorize the transmission of DT TPDUs by its peer, a
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 12.2.3.7 Sequencing of received AK TPDUs
+
+ To allow a receiving transport entity to properly sequence a
+ series of AK TPDUs that all contain the same sequence number and
+ thereby use the correct CDT value, AK TPDUs may contain a
+ subsequence parameter. For the purpose of determining the
+ correct sequence of AK TPDUs, the absence of the subsequence
+ parameter shall be equivalent to the value of the parameter set
+ to zero.
+
+ An AK TPDU is defined to be in sequence if:
+
+ a) the sequence number is greater than in any previously
+ received AK TPDU, or
+
+ b) the sequence number is equal to the highest in any
+ previously received AK TPDU, and the subsequence parameter
+ is greater than in any previously received AK TPDU having
+ the same value for YR-TU-NR field, or
+
+ c) the sequence number and subsequence parameter are both
+ equal to the highest in any previously received AK TPDU
+ and the credit field is greater than or equal to that in
+ any previously received AK TPDU having the same YR-TU-NR
+ field.
+
+ A transport entity is not required to include the subsequence
+ number in its AK TPDUs. It may also choose not to use the
+ subsequence parameter in sequencing received AK TPDUs. If a
+ transport entity chooses not to recognize the subsequence
+ parameter it shall still sequence received AK TPDUs according to
+ 12.2.3.7.a.
+
+ When the receiving transport entity recognizes an out of sequence
+ AK TPDU it shall ignore it.
+
+
+
+
+
+
+
+
+
+
+
+ 108
+
+
+
+
+
+
+
+
+
+
+
+ 12.2.3.8 Procedure for transmission of AK TPDUs
+
+ 12.2.3.8.1 Retransmission of AK TPDUs for window synchronization
+
+ A transport entity shall not allow an interval W to pass without
+ the transmission of an AK TPDU. if the transport entity is not
+ using the procedure following setting CDT to zero (see
+ 12.2.3.8.3) or reduction of the upper window edge (see
+ 12.2.3.8.4), and does not have to acknowledge receipt of any DT
+ TPDU, then it shall achieve this by retransmission of the most
+ recent AK TPDU, with up-to-date window information.
+
+ NOTE - The use of the procedures defined in 12.2.3.8.3 and
+ 12.2.3.8.4 are optional for any transport entity. The protocol
+ operates correctly either with or without these procedures which
+ are defined to enhance the efficiency of its operation. However,
+ if these procedures are not used then W must be set to ensure
+ enough retransmissions of the AK TPDU so that release of TC is
+ avoided. The value of W should be approximately
+ W = (T1 * N)/(N-1) when the procedures are not used.
+
+
+
+
+ 12.2.3.8.2 Sequence control for transmission of AK TPDUs
+
+ To allow the receiving transport entity to process AK TPDUs in
+ the correct sequence, as described in 12.2.3.7, the subsequence
+ parameter may be included following reduction of CDT. If the
+ value of the subsequence number to be transmitted is zero, then
+ the parameter should be omitted.
+
+ The value of the subsequence parameter, if used, shall be zero
+ (either explicitly or by absence of the parameter) if the
+ sequence number is greater than the field in previous AK TPDUs,
+ sent by the transport entity.
+
+ If the sequence number is the same as the previous AK TPDU sent
+ and the CDT field is equal to or greater than the CDT field in
+ the previous AK TPDU sent then the subsequence parameter, if
+ used, shall be equal to that in the previously sent AK TPDU.
+
+ If the sequence number is the same as the previous AK TPDU sent
+
+
+
+ 109
+
+
+
+
+
+
+
+
+
+
+
+ and the CDT field is less than the value of the CDT field in the
+ previous AK TPDU sent than the subsequence parameter, if used,
+ shall be one greater than the value in the previous AK TPDU..
+
+
+
+
+ 12.2.3.8.3 Retransmission of AK TPDUs after CDT set to zero
+
+ Due to the possibility of loss of AK TPDUs, the upper window edge
+ as perceived by the transport entity transmitting an AK TPDU may
+ differ from that perceived by the intended recipient. To avoid
+ the possibility of extra delay, the retransmission procedure (see
+ 12.2.1.2) should be followed for an AK TPDU, if it opens the
+ transmit window which has previously been closed by sending an AK
+ TPDU with CDT field set to zero.
+
+ The retransmission procedure, if used, terminates and the
+ procedure in 12.2.3.8.1 is used when:
+
+ a) an AK TPDU is received containing the flow control
+ confirmation parameter, whose lower window edge and your
+ subsequence fields are equal to the sequence number and
+ subsequence number in the retained AK TPDU and whose
+ credit field is not zero.
+
+ b) an AK TPDU is transmitted with a sequence number higher
+ than that in the retained AK TPDU, due to reception of a
+ DT TPDU whose sequence number is equal to the lower window
+ edge;
+
+ c) N transmissions of the retained AK TPDU have taken place.
+ In this case the transport entity shall continue to
+ transmit the AK TPDU at an interval of W.
+
+ An AK TPDU which is subject to the retransmission procedure shall
+ not contain the flow control confirmation parameter. If it is
+ required to transmit this parameter concurrently, an additional
+ AK TPDU shall be transmitted having the same values in the
+ sequence, subsequence (if applicable) and credit fields.
+
+
+
+
+
+
+ 110
+
+
+
+
+
+
+
+
+
+
+
+ 12.2.3.8.4 Retransmission procedures following reduction of the
+
+ upper window edge
+
+ This subclause specifies the procedure for retransmission of AK
+ TPDUs after a transport entity has reduced the upper window edge
+ (see 12.2.3.6) or for an AK TPDU with the credit field set to
+ zero. This procedure is used until the lower window edge exceeds
+ the highest value of the upper window edge ever transmitted (i.e.
+ the value existing at the time of credit reduction, unless a
+ higher value is retained from a previous credit reduction).
+
+ This retransmission procedure should be followed for any AK TPDU
+ which increases the upper window edge, unless an AK TPDU has been
+ received containing a flow control confirmation parameter, which
+ corresponds to an AK TPDU transmitted following credit reduction,
+ for which the sum of the credit and lower window edge fields
+ (i.e. the upper window edge value) is greater than the lower
+ window edge (YR-TU-NR field) of the transmitted AK TPDU.
+
+ This retransmission procedure for any particular AK TPDU shall
+ terminate when:
+
+ a) an AK TPDU is received containing the flow control
+ confirmation parameter, whose lower window edge and your
+ subsequence fields are equal to the lower window edge and
+ subsequence number in the retained AK TPDU; or
+
+ b) N transmissions of the retained AK TPDU have taken place.
+ In this case the transport entity shall continue to
+ transmit the AK TPDU at an interval of W.
+
+ An AK TPDU which is subject to the retransmission procedure shall
+ not contain the flow control confirmation parameter. If it is
+ required to transmit this parameter concurrently, an additional
+ AK TPDU shall be transmitted having the same values in the
+ sequence, subsequence (if applicable) and credit fields.
+
+ NOTE - Retransmission of AK TPDUs is normally not necessary,
+ except following explicit closing of the window (i.e.
+ transmission of an AK TPDU with CDT field set to zero). If
+ data is available to be transmitted, the retransmission
+ procedure for DT TPDUs will ensure that an AK TPDU is received
+
+
+
+ 111
+
+
+
+
+
+
+
+
+
+
+
+ granting further credit where this is available. Following
+ credit reduction, this may no longer be so, because
+ retransmission may be inhibited by the credit reduction. The
+ rules described in this clause avoid extra delay.
+
+ The rules for determining whether to apply the retransmission
+ procedure to an AK TPDU may be expressed alternatively as
+ follows. Let:
+
+ LWE = lower window edge
+ UWE = upper window edge
+ KUWE = lower bound on upper window edge
+ held by remote transport entity
+
+ The retransmission procedure is to be used whenever:
+
+ (UWE>LWE) and (KUWE = LWE)
+
+ i.e. when the window is opened and it is not known definitely
+ that the remote transport entity is aware of this.
+
+ KUWE is maintained as follows. When credit is reduced, KUWE is
+ set to LWE. Subsequently, it is increased only upon receipt of a
+ valid flow control confirmation (i.e. one which matches the
+ retained lower window edge and subsequence). In this case KUWE
+ is set to the implied upper window edge of the flow control
+ confirmation, i.e. the sum of its lower window edge and your
+ credit fields. By this means, it can be ensured that KUWE is
+ always less than or equal to the actual upper window edge in use
+ by the transmitter of DT TPDUs.
+
+
+
+
+ 12.2.3.9 Use of Flow Control Confirmation parameter
+
+ At any time, an AK TPDU may be transmitted containing a flow
+ control confirmation parameter. The lower window edge, your
+ subsequence and your credit fields shall be set to the same
+ values as the corresponding fields in the most recently received
+ in sequence AK TPDU.
+
+
+
+
+
+ 112
+
+
+
+
+
+
+
+
+
+
+
+ An AK TPDU containing a flow control confirmation parameter
+ should be transmitted whenever:
+
+ a) a duplicate AK TPDU is received, with the value of YR-TU-
+ NR, CDT, and subsequence fields equal to the most recently
+ received AK TPDU, but not itself containing the flow
+ control confirmation parameter;
+
+ b) an AK TPDU is received which increases the upper window
+ edge but not the lower window edge, and the upper window
+ edge was formerly equal to the lower window edge; or
+
+ c) an AK TPDU is received which increases the upper window
+ edge but not the lower window edge, and the lower window
+ edge is lower than the highest value of the upper window
+ edge received and subsequently reduced (i.e. following
+ credit reduction).
+
+
+
+
+ 12.2.4 Procedures for Release
+
+ 12.2.4.1 Timers used for Release
+
+ There are no timers used only for release.
+
+
+
+
+ 12.2.4.2 General Procedures for Release
+
+ The transport entity shall use the explicit variant of normal
+ release (see 6.7).
+
+
+
+
+
+
+
+
+
+
+
+
+ 113
+
+
+
+
+
+
+
+
+
+
+
+ 13 STRUCTURE AND ENCODING OF TPDUs
+
+ 13.1 Validity
+
+ Table 8 specifies those TPDUs which are valid for each class and
+ the code for each TPDU.
+
+ KEY: xxxx (bits 4-1): used to signal the CDT (set to 0000
+ in classes 0 and 1)
+
+ zzzz (bits 4-1): used to signal CDT in classes 2, 3,
+ 4 set to 1111 in class 1
+
+ NF: Not available when the non explicit
+ flow control option is selected.
+
+ NRC: Not available when the receipt
+ confirmation option is selected.
+
+ NOTE - These codes are already in use in related protocols
+ defined by standards oganizations other than CCITT/ISO.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 13.2 Structure
+
+ All the transport protocol data units (TPDUs) shall contain an
+ integral number of octets. The octets in a TPDU are numbered
+ starting from 1 and increasing in the order they are put into an
+ NSDU. The bits in an octet are numbered from 1 to 8, where bit 1
+ is the low-ordered bit.
+
+ When consecutive octets are used to represent a binary number,
+ the lower octet number has the least significant value.
+
+ NOTE - When the encoding of a TPDU is represented using a
+ diagram in this clause, the following representation is used:
+
+ a) octets are shown with the lowest numbered octet to the
+ left, higher numbered octets being further to the right;
+
+ b) within an octet, bits are shown with bit 8 to the left and
+ bit 1 to the right.
+
+ TPDUs shall contain, in the following order:
+
+ a) the header, comprising:
+
+ 1) the length indicator (LI) field;
+
+ 2) the fixed part;
+
+ 3) the variable part, if present;
+
+ b) the data field, if present.
+
+ This structure is illustrated below:
+
+ octet 1 2 3 4 ... n n+1 ... p p+1 ...end
+ +---+-------------+--------------+-----------+
+ | LI| fixed part | variable part| data field|
+ +---+-------------+--------------+-----------+
+ <--------------- header ------>
+
+
+
+
+
+
+
+ 116
+
+
+
+
+
+
+
+
+
+
+
+ 13.2.1 Length indicator field
+
+ This field is contained in the first octet of the TPDUs. The
+ length is indicated by a binary number, with a maximum value of
+ 254 (1111 1110). The length indicated shall be the header length
+ in octets including parameters, but excluding the length
+ indicator field and user data, if any. The value 255 (1111 1111)
+ is reserved for possible extensions. If the length indicated
+ exceeds the size of the NS-user data which is present, this is a
+ protocol error.
+
+
+
+
+ 13.2.2 Fixed part
+
+ 13.2.2.1 General
+
+ The fixed part contains frequently occurring parameters including
+ the code of the TPDU. The length and the structure of the fixed
+ part are defined by the TPDU code and in certain cases by the
+ protocol class and the formats in use (normal or extended). If
+ any of the parameters of the fixed part have an invalid value, or
+ if the fixed part cannot be contained with the header (as defined
+ by LI) this is a protocol error.
+
+ NOTE - In general, the TPDU code defines the fixed part
+ unambiguously. However, different variants may exist for the
+ same TPDU code (see normal and extended formats).
+
+
+
+
+ 13.2.2.2 TPDU code
+
+ This field contains the TPDU code and is contained in octet 2 of
+ the header. It is used to define the structure of the remaining
+ header. This field is a full octet except in the following
+ cases:
+
+
+
+
+
+
+
+ 117
+
+
+
+
+
+
+
+
+
+
+
+ 1110 xxxx Connection Request
+ 1101 xxxx Connection Confirm
+ 0101 xxxx Reject
+ 0110 xxxx Data Acknowledgement
+
+ where xxxx (bits 4-1) is used to signal the CDT.
+
+ Only those codes defined in 13.1 are valid.
+
+
+
+
+ 13.2.3 Variable part
+
+ The variable part is used to define less frequently used
+ parameters. If the variable part is present, it shall contain
+ one or more parameters.
+
+ NOTE - The number of parameters that may be contained in the
+ variable part is indicated by the length of the variable part
+ which is LI minus the length of the fixed part.
+
+ Each parameter contained within the variable part is structured
+ as follows:
+
+ Bits 8 7 6 5 4 3 2 1
+ Octets +------------------------------------+
+ n+1 | Parameter Code |
+ |------------------------------------|
+ n+2 | Parameter Length |
+ | Indication (e.g. m) |
+ |------------------------------------|
+ n+3 | |
+ | Parameter Value |
+ n+2+m | |
+ +------------------------------------|
+
+
+
+
+
+
+
+
+
+
+ 118
+
+
+
+
+
+
+
+
+
+
+
+ - The parameter code field is coded in binary;
+
+ NOTE - Without extensions, it provides a maximum number of 255
+ different parameters. However, as noted below, bits 8 and 7
+ cannot take every possible value, so the practical maximum
+ number of different parameters is less. Parameter code 1111
+ 1111 is reserved for possible extensions of the parameter code.
+
+ - The parameter length indication indicates the length, in
+ octets, of the parameter value field.
+
+ NOTE - The length is indicated by a binary number, m, with a
+ theoretical maximum value of 255. The practical maximum value
+ of m is lower. For example, in the case of a single parameter
+ contained within the variable part, two octets are required for
+ the parameter code and the parameter length indication itself.
+ Thus, the value of m is limited to 248. For larger fixed parts
+ of the header and for each succeeding parameter, the maximum
+ value of m decreases.
+
+ - The parameter value field contains the value of the parameter
+ identified in the parameter code field.
+
+ - No parameter codes use bits 8 and 7 with the value 00.
+
+ - The parameters defined in the variable part may be in any
+ order. If any parameter is duplicated then the later value
+ shall be used. A parameter not defined in this International
+ Standard shall be treated as a protocol error in any received
+ TPDU except a CR TPDU; in a CR TPDU it shall be ignored. If
+ the responding transport entity selects a class for which a
+ parameter of the CR TPDU is not defined, it may ignore this
+ parameter, except the class and option, and alternative
+ protocol class parameters which shall always be interpreted. A
+ parameter defined in this International Standard but having an
+ invalid value shall be treated as a protocol error in any
+ received TPDU except a CR TPDU. In a CR TPDU it shall be
+ treated as a protocol error if it is either the class and
+ option parameter or the alternative class parameter or the
+ additional option parameter; otherwise it shall be either
+ ignored or treated as a protocol error.
+
+
+
+
+
+ 119
+
+
+
+
+
+
+
+
+
+
+
+ 13.2.3.1 Checksum Parameter (Class 4 only)
+
+ All TPDU types may contain a 16-bit checksum parameter in their
+ variable part. This parameter shall be present in a CR TPDU and
+ shall be present in all other TPDUs except when the non use of
+ checksum option is selected.
+
+ Parameter Code: 1100 0011
+ Parameter Length: 2
+ Parameter Value: Result of checksum algorithm. This algorithm
+ is specified in 6.17.
+
+
+
+
+ 13.2.4 Data Field
+
+ This field contains transparent user data. Restrictions on its
+ size are noted for each TPDU.
+
+
+
+
+ 13.3 Connection Request (CR) TPDU
+
+ The length of the CR TPDU shall not exceed 128 octets.
+
+
+
+
+ 13.3.1 Structure
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 13.3.2 LI
+
+ See 13.2.1
+
+
+
+
+ 13.3.3 Fixed Part (Octets 2 to 7)
+
+ 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
+
+ 1. The connection establishment procedure (see 6.5) does not
+ permit a given CR TPDU to request use of transport expedited
+ data transfer service (additional option parameter) and no
+ use of explicit flow control in Class 2 (bit 1 = 1).
+
+ 2. Bits 4 to 1 are always zero in Class 0 and have no meaning.
+
+
+
+
+ 13.3.4 Variable Part (Octets 8 to p)
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ If a TSAP-ID is given in the request it may be returned in
+ the confirmation.
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ This parameter shall always be present in a CR TPDU
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ g) Alternative protocol class(es) (not used if Class 0 is the
+ preferred class)
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 6th 3 octets: Min. acceptable, calling-called user
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ n) Transit delay (not used if class 0 is the preferred class)
+
+ 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.
+
+
+
+
+ 13.3.5 User Data (Octets p+1 to the end)
+
+ No user data are permitted in Class 0, and are optional in the
+ other classes. Where permitted, it may not exceed 32 octets.
+
+
+
+
+
+
+
+
+
+
+
+ 127
+
+
+
+
+
+
+
+
+
+
+
+ 13.4 Connection Confirm (CC) TPDU
+
+ 13.4.1 Structure
+
+ 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 |
+ +---+----+---+---+---+---+---+-------+--------+-------------+
+
+
+
+
+ 13.4.2 LI
+
+ See 13.2.1
+
+
+
+
+ 13.4.3 Fixed Part (Octets 2 to 7)
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 13.4.4 Variable Part (Octet 8 to p)
+
+ The parameters are defined in 13.3.4 and are subject to the
+ constraints states in 6.5 (connection establishment). Parameters
+ ruled out by selection of an alternative class and option shall
+ not be present.
+
+
+
+
+ 13.4.5 User Data (Octets p+1 to the end)
+
+ 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).
+
+
+
+
+ 13.5 Disonnect Request (DR) TPDU
+
+ 13.5.1 Structure
+
+ 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 |
+ +--+---------+----+-----+----+-----+------+--------+----------+
+
+
+
+
+ 13.5.2 LI
+
+ See Section 13.2.1
+
+
+
+
+
+
+
+
+ 129
+
+
+
+
+
+
+
+
+
+
+
+ 13.5.3 Fixed Part (Octets 2 to 7
+
+ The fixed part shall contain:
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ The following values can be used for all classes:
+
+ 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.
+
+
+
+
+ 13.5.4 Variable Part (Octets 8 to p)
+
+ 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)
+
+
+
+
+ 13.5.5 User Data (Octets p+1 to the end)
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 13.6 Disconnect Confirm (DC) TPDU
+
+ This TPDU shall not be used in Class 0.
+
+
+
+
+ 13.6.1 Structure
+
+ 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 | | | | | | |
+ +----+-----------+-----+-----+-----+-----+-------+--------+
+
+
+
+
+ 13.6.2 LI
+
+ See 13.2.1
+
+
+
+
+ 13.6.3 Fixed Part (Octets 2 to 6)
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 13.6.4 Variable Part
+
+ The variable part shall contain the checksum parameter if the
+ condition in (see 13.2.3.1) applies.
+
+
+
+
+ 13.7 Data (DT) TPDU
+
+ 13.7.1 Structure
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 13.7.2 LI
+
+ See 13.2.1
+
+
+
+
+ 13.7.3 Fixed Part
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 13.7.4 Variable Part
+
+ The variable part shall contain the checksum parameter if the
+ condition in see 13.2.3.1 applies.
+
+
+
+
+ 13.7.5 User Data Field
+
+ 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.
+
+
+
+
+ 13.8 Expedited Data (ED) TPDU
+
+ 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.
+
+
+
+
+ 13.8.1 Structure
+
+ Depending on the format negotiated at connection establishment
+ the ED TPDU shall have one of the following structures:
+
+
+
+
+
+
+
+
+
+
+
+ 135
+
+
+
+
+
+
+
+
+
+
+
+ a) Normal Format (classes 1, 2, 3, 4)
+
+ 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 | | | |
+ +--+---------+---+---+---------+-----+-------+---------------+
+
+
+
+
+ 13.8.2 LI
+
+ See 13.2.1
+
+
+
+
+ 13.8.3 Fixed Part
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ d) EOT: end of TSDU always set to 1 (bit 8 of octet 5
+ 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.
+
+
+
+
+ 13.8.4 Variable Part
+
+ The variable part shall contain the checksum parameter if the
+ condition defined in 13.2.3.1 applies.
+
+
+
+
+ 13.8.5 User Data Field
+
+ This field contains an expedited TSDU (1 to 16 octets).
+
+
+
+
+ 13.9 Data Acknowledgement (AK) TPDU
+
+ 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.
+
+
+
+
+ 13.9.1 Structure
+
+ Depending on the class and option agreed the AK TPDU shall have
+ one of the following structures:
+
+
+
+
+
+
+
+
+ 137
+
+
+
+
+
+
+
+
+
+
+
+ a) Normal Format (classes 1, 2, 3, 4)
+
+ 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 |
+ +--+---------+---------+----------+-----+--------+
+
+
+
+
+ 13.9.2 LI
+
+ See 13.2.1
+
+
+
+
+ 13.9.3 Fixed Part
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+ 13.9.4 Variable Part
+
+ 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
+
+ 1. Lower Window Edge (32 bits)
+ Bit 8 of octet 4 is set to zero, the remainder
+ contains the YR-TU-NR value of the received AK TPDU.
+ When normal format has been selected, only the least
+ significant seven bits (bits 1 to 7 of octet 1) of
+ this field are significant.
+
+ 2. Your Sub-Sequence (16 bits)
+ Contains the value of the sub-sequence parameter of
+
+
+
+ 139
+
+
+
+
+
+
+
+
+
+
+
+ the received AK TPDU, or zero if this parameter was
+ not present.
+
+ 3. Your Credit (16 bits)
+ Contains the value of the CDT field of the received AK
+ TPDU. When normal format has been selected, only the
+ least significant four bits (bits 1 to 4 of octet 1)
+ of this field are significant.
+
+
+
+
+ 13.10 Expedited Data Acknowledgement (EA) TPDU
+
+ This TPDU shall not be used for Class 0 and Class 2 when the no
+ explicit flow control option is selected.
+
+
+
+
+ 13.10.1 Structure
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 13.10.2 LI
+
+ See 13.2.1
+
+
+
+
+ 13.10.3 Fixed Part
+
+ 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.
+
+
+
+
+ 13.10.4 Variable Part
+
+ The variable part may contain the checksum parameter (see
+ 13.2.3.1).
+
+
+
+
+ 13.11 Reject (RJ) TPDU
+
+ The RJ TPDU shall not be used in Classes 0, 2 and 4.
+
+
+
+
+
+
+ 141
+
+
+
+
+
+
+
+
+
+
+
+ 13.11.1 Structure
+
+ The RJ TPDU shall have one of the following formats:
+
+ 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 | | | | |
+ +--+-----------+----+----+----------+-----+
+
+
+
+
+ 13.11.2 LI
+
+ See 13.2.1.
+
+
+
+
+ 13.11.3 Fixed Part
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ d) YR-TU-NR: Sequence number indicating the next expected
+ TPDU from which retransmission should occur.
+
+ 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.
+
+
+
+
+ 13.11.4 Variable Part
+
+ There is no variable part for this TPDU type.
+
+
+
+
+ 13.12 TPDU Error (ER) TPDU
+
+ 13.12.1 Structure
+
+ 1 2 3 4 5 6 P
+ +----+-----------+----+----+--------+----------+
+ | LI | ER | DST-REF | Reject | Variable |
+ | | 0111 0000 | | | Cause | Part |
+ +----+-----------+----+----+--------+----------+
+
+
+
+
+ 13.12.2 LI
+
+ See 13.2.1
+
+
+
+
+
+
+
+
+
+
+ 143
+
+
+
+
+
+
+
+
+
+
+
+ 13.12.3 Fixed Part
+
+ The fixed part shall contain:
+
+ 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.
+
+
+
+
+ 13.12.4 Variable Part
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ SECTION THREE. CONFORMANCE
+
+
+
+
+ 14 CONFORMANCE
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ 14.5
+
+ For each class which the system claims to implement, the system
+ shall be capable of:
+
+ 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.
+
+
+
+
+ 14.6 Claims of Conformance Shall State
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ d) the maximum size of TPDU implemented; the value shall be
+ chosen from the following list and all values in the list
+ which are less than this maximum shall be implemented:
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ ANNEX A - STATE TABLES
+
+
+ This annex is an integral part of the body of this International
+ Standard.
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+ ANNEX B - CHECKSUM ALGORITHMS
+
+ (This annex is provided for information for implementors and is
+ not an integral part of the body of the standard.)
+
+
+
+ B.1 SYMBOLS
+
+ 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.
+
+
+
+ B.2 ARITHMETIC CONVENTIONS
+
+ 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).
+
+
+
+ B.3 ALGORITHM FOR GENERATING CHECKSUM PARAMETERS
+
+
+
+
+
+ 151
+
+
+
+
+
+
+
+
+
+
+
+ B.3.1 Set up the complete TPDU with the value of the checksum
+ parameter field set to zero.
+
+
+ B.3.2 Initialize C0 and C1 to zero.
+
+
+
+ B.3.3 Process each octet sequentially from i = 1 to L by:
+
+ a) adding the value of the octet to C0; then
+
+ b) adding the value of C0 to C1.
+
+
+
+ B.3.4 Calculate X and Y such that
+
+ X = -C1 + (L-n).CO
+ Y = C1 - (L-n+1).C0
+
+
+
+ B.3.5 Place the values X and Y in octets n and (n + 1)
+ respectively.
+
+ [A Note describing the above algorithm in mathematical notation
+ has been omitted from this copy.]
+
+
+
+ B.4 ALGORITHM FOR CHECKING CHECKSUM PARAMETERS
+
+
+ B.4.1 Initialize C0 and C1 to zero.
+
+
+ B.4.2 Process each octet of the TPDU sequentially from i = 1 to
+ L by:
+
+ a) adding the value of the octet to C0; then
+
+ b) adding the value of C0 to C1.
+
+
+
+ 152
+
+
+
+
+
+
+
+
+
+
+
+ B.4.3 If, when all the octets have been processed, either or
+ both of C0 and C1 does not have the value zero, the checksum
+ formulas in 6.17 have not been satisfied.
+
+ NOTE - The nature of the algorithm is such that it is not
+ necessary to compare explicitly the stored checksum bytes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 153
+
+
+
+
+
+
+
+
+
+
+
+ Explanatory Report
+
+ The Transport Layer Services and Protocols have been under study
+ within TC97/SC16 since 1979. It was agreed by SC16 at its
+ meeting in Berlin, November 1980, that the Service and Protocol
+ documents would be progressed concurrently.
+
+ 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
+
+
+