From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc905.txt | 9515 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 9515 insertions(+) create mode 100644 doc/rfc/rfc905.txt (limited to 'doc/rfc/rfc905.txt') 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 (module 255) + + SUM(from i=1 to i=L) OF i*a[i] EQUALS (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 + + + -- cgit v1.2.3