RFC 905
ISO Transport Protocol specification ISO DP 8073
ISO Transport Protocol Specification 💖
- Series: Network Working Group 🎀, RFC 905 (Request for Comments)
- Originator: ISO
- Date: April 1984 🌸
- Document designation: ISO DP 8073 🦋
- Category: For information only. This does not specify a standard for the ARPA-Internet ✨
- Obsoletes: Nothing listed in the header. The notes say this one should be assumed to supersede RFC 892 💅
- Updates: Nothing listed in the header 🧚
- Author: Credited at the end of the notes as Alex McKenzie, BBN 🫶
Status of This Memo ✨
Bestie, this doc is shared as an RFC for information only 🌈. It is not a standard for the ARPA-Internet, so it's more of a reference you can read and learn from than a rulebook 💜.
Notes 📝
- RFC 892 is an older version of the ISO Transport Protocol Specification, so this RFC should be assumed to supersede RFC 892 💅.
- The author retyped the text of ISO/TC97/SC16/N1576 and then applied the proposed editorial corrections from ISO/TC97/SC16/N1695. Together, those two documents were going through an ISO vote as a Draft International Standard (DIS) 🔥.
- This RFC was reviewed after the retyping and is believed to be substantially correct 🙈. Still, typos that aren't in the ISO originals may have slipped through, so double-check anything important 🍓.
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
iiiokay bestie, the table of contents is still going and it's giving main character energy 🎀✨ every section number stays exactly where it lives 🫶
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.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
viithat's the whole contents list wrapped up for this part 💖 more of the doc comes next 🦋
INTRODUCTION ✨
okay so this is the bit where the standard explains itself 💅 The Transport Protocol Standard is one of a whole family of International Standards made to help computer systems talk to each other 🖥️🫶 The family covers the services and protocols you need to get that interconnection working.
The Transport Protocol Standard sits in a particular spot among its related standards, using the layers from the Reference Model for Open Systems Interconnection (ISO 7498) as its map 🗺️ It's most closely related to, and lives inside the field of application of, the Transport Service Standard (DP 8072). It also leans on the Network Service Standard (DP 8348) and assumes that standard's provisions so it can do its job 🌸 The way all these standards connect is shown 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 gives you a common encoding, plus a bunch of classes of transport protocol procedures, for use with different network qualities of service 🎀
The protocol is meant to be simple but still general enough to handle the whole range of Network Service qualities that might exist, without boxing in future extensions 🌈 It's also structured into classes of protocol that are designed to keep incompatibilities and implementation costs as low as possible 💜
The classes can be picked based on the Transport and Network Services, so you get the quality of service you need for connecting two session entities 🧚 (Note that each class offers a different set of functions for boosting service qualities, so choose wisely, bestie 👑)
This protocol standard defines mechanisms you can use to optimize network tariffs and enhance these 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 🙅♀️ It also doesn't define methods for measuring the quality of service you actually achieve, or criteria for deciding when to release transport connections after quality of service degrades 💀
The main goal of this International Standard is to give a set of rules for communication, written as the procedures that peer entities carry out at the time of communication 🫶 These rules are meant to be a solid base for development, serving a few different 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.
The first people using this standard are expected to be designers and implementors of equipment 🛠️ The International Standard includes guidance on implementing the procedures, either in notes or in annexes 📖
Heads up: the number of valid protocol sequences is huge, so with current technology you can't verify that an implementation will operate the protocol correctly under all circumstances 😭 Testing can build confidence that an implementation behaves correctly in a representative sample of circumstances. The standard is still intended to be used when two implementations fail to communicate, so you can work out whether one or both of them failed to operate the protocol correctly 🔍
This International Standard has a section on conformance for equipment that claims to implement these procedures 🎀 Just a heads up though: the standard doesn't contain any tests that demonstrate this conformance 🙈
The variations and options in this International Standard are essential, because they let a Transport Service be provided for lots of different applications over lots of different network qualities 🌸 That means a minimally conforming implementation won't be suitable for every possible situation 🫠 So it matters that every reference to this International Standard is qualified with statements of the options provided or required, or the intended purpose of that 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,
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 that support the Transport Layer of the OSI Reference Model and that wish to interconnect in an open systems environment 🌐
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.
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 🎀
3.2.1 equipment:
Hardware or software or a combination of both 🖥️ It need not be physically distinct within a computer system, so don't get it twisted, bestie 🫶
3.2.2 transport service user:
3.2.3 network service provider ✨
okay so this one is the NS-provider's glow-up 💅 It's an abstract machine that models the whole collection of entities providing the network service, as seen from a transport entity 🌸
3.2.4 local matter 🎀
a local matter is a decision a system makes about how it behaves in the Transport Layer, and it's NOT subject to the requirements of this protocol. the system gets to make that call on its own 🙈
3.2.5 initiator 🦋
an initiator is a transport entity that starts a CR TPDU. it's the one making the first move, bestie 💖
3.2.6 responder 🫶
a responder is a transport entity that an initiator wants to set up a transport connection with.
NOTE - initiator and responder are defined with respect to a single transport connection. a transport entity can be both an initiator and a responder at the same time. the multitasking queen 👑
3.2.7 sending transport entity 🌈
a sending transport entity is whichever transport entity sends a given TPDU ✈️
3.2.8 receiving transport entity ⭐
a receiving transport entity is whichever transport entity receives a given TPDU. so basically the sender's other half 🧚
3.2.9 preferred class 💜
the preferred class is the protocol class the initiator puts in a CR TPDU as its number one pick for the transport connection. first choice energy 🍓
3.2.10 alternative class 🌸
an alternative class is a protocol class the initiator puts in a CR TPDU as a backup option for the transport connection. the plan B era ✨
3.2.11 proposed class 🦋
a proposed class is either a preferred class or an alternative class. so it's the whole shortlist 💅
3.2.12 selected class 👑
the selected class is the protocol class the responder puts in a CC TPDU to say "yep, this is the one I picked" for the transport connection 🫶
3.2.13 proposed parameter 🎀
a proposed parameter is the value for a parameter that the initiator puts in a CR TPDU, saying it wants to use that value over the transport connection 💖
3.2.14 selected parameter 🌈
a selected parameter is the value for a parameter that the responder puts in a CC TPDU, saying it has chosen that value for use over the transport connection ✨
3.2.15 error indication 💀
an error indication is either an N-RESET indication, or an N-DISCONNECT indication with a reason code that indicates an error. a transport entity gets these from the NS-provider and yes, it's a whole vibe check 😭
3.2.16 invalid TPDU 🙈
an invalid TPDU is a TPDU that does not comply with the requirements of this International Standard for structure and encoding. the structure is giving... wrong 💀
3.2.17 protocol error 🔥
a protocol error is a TPDU whose use does not comply with the procedures for its class. the TPDU is valid, but it's using the class wrong, which is a whole different kind of messy 🙃
3.2.18 sequence number 🧚
there are two flavours here 💅
- a) it's the number in the
TPDU-NRfield of a DT TPDU that shows the order in which the DT TPDU was sent by a transport entity. - b) it's the number in the
YR-TU-NRfield of an AK or RJ TPDU that shows the sequence number of the next DT TPDU a transport entity expects to receive.
3.2.19 transmit window 🦋
a transmit window is the set of consecutive sequence numbers that a transport entity has been authorized by its peer entity to send at a given time on a given transport connection. permission slip vibes 🎟️
3.2.20 lower window edge 🌸
the lower window edge is the lowest sequence number in a transmit window 🍓
3.2.21 upper window edge 🌈
the upper window edge is the sequence number that's one greater than the highest sequence number in the transmit window. the edge is literally just past the last one, iykyk 🙈
3.2.22 upper window edge allocated to the peer entity 💜
this one is the value a transport entity tells its peer entity to read as its new upper window edge. it's a whole handoff 🫶
3.2.23 closed window 💀
a closed window is a transmit window that contains no sequence number. zero vibes, zero sends 😭
3.2.24 window information 🎀
window information is the info in a TPDU about the upper and the lower window edges ✨
3.2.25 frozen reference 🧊
a frozen reference is a reference that can't be assigned to a connection because of the requirements of 6.18. it's on ice, bestie ❄️
3.2.26 unassigned reference 👑
an unassigned reference is a reference that is neither currently in use for identifying a transport connection, nor in a frozen state. it's free real estate 🏡
3.2.27 transparent (data) 🦋
transparent data is TS-user data that is transferred intact between transport entities, and it's unavailable for use by the transport entities. the transport entities just carry it, they never touch it 🤐
3.2.28 owner (of a network connection) 🌈
the owner of a network connection is the transport entity that issued the N-CONNECT request which led to the creation of that network connection. it's the one who started the whole thing 👑
3.2.29 retained TPDU 💖
a retained TPDU is a TPDU that is subject to the retransmission procedure, or to the retention until acknowledgement procedure, and it's available for possible retransmission. it's kept on standby just in case 🫶
4 SYMBOLS AND ABBREVIATIONS ✨
4.1 Data units 🍓
TPDU Transport protocol data unit
TSDU Transport service data unit
NSDU Network service data unit4.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 TPDU4.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)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 time4.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 service5 OVERVIEW OF THE TRANSPORT PROTOCOL 🧚
NOTE - This overview is not exhaustive and has been provided for guidance to the reader of this International Standard. it's a little tour, not the full map 🗺️
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.
| 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 primitives5.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.
+---------------------------------------------------------------+
| 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 primitivesOkay bestie, so that's Table 2, the network service primitives lineup 📋✨ Here's the decoder ring for the letters:
- X means the Transport Protocol assumes this facility is provided in all networks 💖
- Y means it's provided in some networks, and there's a mechanism to optionally use it 🦋
- Z means 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 - How the parameters get 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
Okay so the functions in the Transport Layer are the ones needed to bridge the gap between what the Network Layer gives you and what you're offering your TS-users 🌸 It's giving "make the network behave the way the app actually needs" 💅
The Transport Layer's functions are all about boosting quality of service, and that includes cost optimization too. Main character energy, honestly 👑
These functions are sorted into two buckets: the ones used at all times during a transport connection, and the ones for connection establishment, data transfer and release 🧚
NOTE - This International Standard does not include the following functions, which are still under consideration for future editions of this standard 👀 - a) encryption; - 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
Depending on the selected class and options, these functions 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), which is 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), which is 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), which is a function used to recover from detected and signalled errors 💪
5.3.1.2. Connection Establishment
The whole point of connection establishment is to set up a transport connection between two TS-users 🎀 During this phase, the following functions of the transport layer have to match the TS-users' requested quality of service with what the network layer is offering:
- a) select the network service that best matches the TS-user's requirement, taking into account charges for the 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
Data transfer is where the magic happens: it lets the two TS-users connected by the transport connection send TSDUs to each other in duplex 🦋 It gets this done with two-way simultaneous communication plus the following functions. Some of them get used or skipped depending on what got selected during connection establishment 💖
- a) concatenation and separation (see 6.4), which collects several TPDUs into a single NSDU at the sending transport entity and separates the TPDUs at the receiving transport entity 🧩
- b) segmenting and reassembling (see 6.3), which splits a single data TSDU into multiple TPDUs at the sending transport entity and puts them back into their original format at the receiving transport entity ✂️
- c) splitting and recombining (see 6.23), which lets two or more network connections support the same transport connection at once 🌈
- d) flow control (see 6.16), which regulates the flow of TPDUs between two transport entities on one transport connection 🚦
- e) transport connection identification, which is a means to uniquely identify a transport connection between the pair of transport entities supporting it, for the whole lifetime of that connection 🪪
- f) expedited data (see 6.11), which bypasses the flow control of normal data TPDUs. Expedited data TPDU flow is controlled by separate flow control 🚀
- g) TSDU delimiting (see 6.3), which determines where a TSDU begins and ends 📏
5.3.1.4. Release
Release (see 6.7 and 6.8) exists to disconnect the transport connection, no matter what's currently happening on it 🙅♀️💀
5.4. Classes and options
5.4.1. General
The Transport Layer's functions are organized into classes and options 🗂️
A class defines a set of functions. Options define the functions within a class that may or may not be used 💅
This International Standard defines five classes of protocol:
- 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
Classes and options get negotiated during connection establishment 🤝 The transport entities make their choice based on:
- a) the TS-users' requirements, expressed via T-CONNECT service primitives;
- b) the quality of the available network services;
- c) the service-versus-cost ratio the TS-user finds acceptable.
5.4.3. Choice of network connection
This list sorts network services by their quality when it comes to error behavior, measured against user requirements. Its main job is to give you a basis for deciding which class of transport protocol to use with a given network connection 🔍
- a) Type A. Network connection with acceptable residual error rate (for example, not signalled by disconnect or reset) and an acceptable rate of signalled errors. ✅
- b) Type B. Network connections with an acceptable residual error rate (for example, not signalled by disconnect or reset) but an unacceptable rate of signalled errors. ⚠️
- c) Type C. Network connections with an unacceptable residual error rate. 🚫
It's assumed that each transport entity is aware of the quality of service that particular network connections provide 🧠
5.4.4. Characteristics of Class 0
Class 0 is the simplest type of transport connection, and it's fully compatible with CCITT recommendation S.70 for teletex terminals 📠🌸
Class 0 was designed to be used with type A network connections 💖
5.4.5. Characteristics of Class 1
Class 1 gives you a basic transport connection with minimal overheads 🪶
The main purpose of this class is to recover from network disconnect or reset 🔄
Choosing this class is usually based on reliability criteria 🛡️ Class 1 was designed to be used with type B network connections 🦋
5.4.6.1. General
Class 2 gives you a way to multiplex several transport connections onto a single network connection 🧵 It was designed to be used with type A network connections 💜
5.4.6.2. Use of explicit flow control
The goal here is to provide flow control that helps avoid congestion at transport-connection-end-points and on the network connection 🚧 It's typically used when traffic is heavy and continuous, or when there's intensive multiplexing 📈 Using 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, and that's the sweet spot when explicit disconnection of the transport connection is desirable 💅. This 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 gives you everything Class 2 does, plus the ability to recover from network disconnect or reset 🔥. Picking it is usually about reliability, bestie. Class 3 was designed to be used with type B network connections 💖.
Class 4 is giving main character energy 👑. It has everything Class 3 has, plus the capability to detect and recover from errors caused by the low grade of service the NS-provider offers 😭. The errors it catches are TPDU loss, TPDU delivery out of sequence, TPDU duplication and TPDU corruption. These errors can hit control TPDUs as well as data TPDUs 🫶.
This class also gives you increased throughput capability and extra resilience against network failure 🚀. Class 4 was designed to be used with type C network connections 🌈.
5.5. Model of the transport layer 🦋
A transport entity talks to its TS-users through one or more TSAPs, using 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 use 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. That way the TS-user and the transport entity can both refer to each transport connection 💜.
----------| 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.
SECTION TWO. TRANSPORT PROTOCOL SPECIFICATION 👑
6. Elements of Procedure 💅
This clause contains the elements of procedure used in specifying the protocol classes in clauses 7 to 12 🧠. They aren't meaningful on their own, so don't try 🙃.
The procedures define the transfer of TPDUs, whose structure and coding are 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.
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. This is allowed 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. This is allowed 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.
- When a new network connection is created, the quality of service requested is a local matter. It will normally be related to the requirements of transport connection(s) expected to be assigned to it 🎀.
- 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 🤔.
- 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 🕰️.
- 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 💌.
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 🗺️.
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
- The EOT parameter of a DT TPDU indicates whether or not there are subsequent DT TPDUs in the sequence.
- 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 📬.
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
- The TPDUs within a concatenated set may be distinguished by means of the length indicator parameter.
- The end of a TPDU containing data is indicated by the termination of the NSDU.
- 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 🌱.
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;
Okay bestie, so the CR TPDU is the connection request, and this part is where we list everything it carries 💅✨
- 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;
- 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 needing a previously stated average TSDU size as the basis for any specification. This protocol, as specified in 13.3.4(n), uses a value of 128 octets. Converting to and from specifications based on some other value is a local matter.
6.5.4 Procedure ✨
A transport connection gets set up when one transport entity (the initiator) sends a CR TPDU to the other transport entity (the responder), and the responder replies with a CC TPDU. It's giving handshake 🤝
Before the initiator sends the CR TPDU, it assigns the transport connection being created to one (or more, if the splitting procedure is being use) network connection(s). That set of network connections is what the TPDUs get sent over. During this exchange, all of the information and parameters the transport entities need 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 accepted, refused or unsuccessful. If the timer expires, the initiator SHOULD 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 getting the CC TPDU for a class that includes the procedure for retention until acknowledgement of TPDUs, the initiator SHALL acknowledge the CC TPDU as defined in table 5 (see 6.13). Main character energy 👑
When the network expedited variant of the expedited data transfer (see 6.11) has been agreed (which is only possible in class 1), the responder SHALL NOT send an ED TPDU before the CC TPDU is acknowledged. Not me waiting 🙈
The following information gets exchanged:
- a) references. Each transport entity picks a reference for its peer to use. It's 16 bits long and is arbitrary, except for these restrictions:
- it SHALL NOT already be in use or frozen (see 6.18),
- it SHALL NOT be zero. This mechanism is symmetrical, and it identifies the transport connection independently of the network connection. The range of references used for transport connections, within a given transport entity, is a local matter 🌈
- b) addresses (optional). These 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 that 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.
NOTE 🍓 If class 0 is a valid response according to table 3, including 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 classes that permit a valid response as defined in table 3. When it sends the CR TPDU, the initiator SHOULD assume its preferred class will be agreed to, and commence the procedures associated with that class. The exception is 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 🧚 For example, 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 to the procedures of the selected class. 🔄
| 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 come from both explicit negotiation, where each of the classes proposed is a valid response, and implicit negotiation, where: 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. 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. The responder MAY accept this value or respond with any value between 128 and the proposed value, from 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 the 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 lets both TS-users 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. ⏳
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. Choices, choices 💅
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. 🫶🔥
The table below is the cheat sheet for option negotiation, and it's giving organized 🎀
+-------------------------------------------------------------+
| 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
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. Connection refusal 🚫
6.6.1. Purpose
Okay so the connection refusal procedure is used in all classes whenever a transport entity turns down a transport connection in response to a CR TPDU. Not every connection gets a yes, bestie 💅
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.
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
- 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.
- 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. Two main vibes here:
- 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.
- The use of the explicit variant of the release procedure enables the transport connection to be released independently of the underlying network connection. Independent exits, very mature ✨
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.
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. So the network connection going down is the transport connection going down too 🥀
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).
- e) in other cases, send a DC TPDU and consider the transport connection released.
NOTES
- This requirement ensures that the transport entity is aware of the remote reference for the transport connection.
- When the transport connection is considered as released the local reference is either available for re-use or is frozen (see 6.18).
- 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.).
- 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.
- 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 🧯
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. Basically sorting the mail 📬
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:
- 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
Okay so this is where the entity figures out which transport connection each incoming TPDU belongs to 🎀✨
First up, CR TPDUs. If it's a duplicate (the entity checks using the NSAPs of the network connection and the SRC-REF parameter), it gets associated with the transport connection that the original CR TPDU created 🦋. If it's NOT a duplicate, it's processed as a request to create a brand new transport connection 💖
Next, if the TPDU is a DT TPDU and the network connection already has a class 0 or 1 transport connection assigned to it, OR it's an AK TPDU where a class 1 transport connection is assigned, then bestie, the TPDU gets associated with that transport connection 🫶
If none of that applies, the entity uses the DST-REF parameter to find the transport connection. There are a bunch of cases here, so let's go 💅
a) If the DST-REF isn't allocated to any transport connection, the transport entity SHALL respond on the same network connection with a DR TPDU if the TPDU is a CC TPDU, and with a DC TPDU if the TPDU is a DR TPDU. It SHALL ignore the TPDU if it's neither a DR TPDU nor a CC TPDU. No association with a transport connection gets made 🙈
b) If the DST-REF IS allocated to a connection, but the TPDU came in on a network connection that the connection hasn't been assigned to, then there are three cases 👑
- If the transport connection is class 4, AND the TPDU arrives on a network connection with the same pair of NSAPs as the CR TPDU, then the TPDU counts as performing assignment ✨
- If the transport connection isn't assigned to any network connection (it's waiting for reassignment after a failure), AND the TPDU arrives on a network connection with the same pair of NSAPs as the CR TPDU, then the association with that transport connection gets made 🌸
- Otherwise, the TPDU is treated as having a
DST-REFthat isn't allocated to a transport connection, which is case a) 🧚
c) If the TPDU is a DC TPDU, it's associated with the transport connection the DST-REF is allocated to, UNLESS the SRC-REF isn't the expected one. In that case the DC TPDU gets ignored 🥀
d) If the TPDU is a DR TPDU, there are three cases 💜
- If the
SRC-REFisn't as expected, aDC TPDUwithDST-REFequal to theSRC-REFof the receivedDR TPDUgets sent back, and no association is made 🙃 - If a
CR TPDUis unacknowledged, then theDR TPDUis associated with the transport connection, regardless of the value of itsSRC-REFparameter 🦄 - Otherwise, the
DR TPDUis associated with the transport connection identified by itsDST-REFparameter 🌈
e) If the TPDU is a CC TPDU whose DST-REF parameter identifies an open connection (one that already got a CC TPDU before), and the SRC-REF in the CC TPDU doesn't match the remote reference, then a DR TPDU gets 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, 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 whole purpose in life is to make recovery, flow control and re-sequencing functions possible 🔥
6.10.2 TPDUs and parameters used
The procedure makes use of the following TPDU and parameter:
DT TPDU;TPDU-NR.
A Transport entity SHALL allocate the sequence number zero to the TPDU-NR of the first DT TPDU it transmits for a transport connection. For each later DT TPDU sent on that 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. "Less than" means "occurring sooner in the window sequence", and "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;
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 🚫
- The network normal data variant is used, except when the network expedited variant (available in Class 1 only) has been agreed. In that case,
EDandEATPDUs are conveyed in the data fields ofN-EXPEDITED DATAprimitives (see 6.2.3) 🚀 - No TPDUs can be transmitted using network expedited until the
CC TPDUbecomes acknowledged, so the network expedited can't overtake theCC TPDU🏃♀️
6.12 Reassignment after failure
6.12.1 Purpose
The reassignment after failure procedure is used in Classes 1 and 3 to kick off 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 the transport connection is assigned to, 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:
- Assign the transport connection to a different network connection (see 6.1), and start its
TTRtimer if it isn't already started. - While waiting for the completion of assignment, if:
- an
N-DISCONNECT indicationis received, repeat the procedure from 6.12.3.a, - the
TTRtimer expires, begin procedure 6.12.3.b.
- an
- When reassignment is completed, begin resynchronization (see 6.14) and:
- if a valid TPDU is received as the result of the resynchronization, stop the
TTRtimer, or - if
TTRruns out, wait for the next event, or - if an
N-DISCONNECT indicationis received, then begin either procedure 6.12.3.a or 6.12.3.b, depending on theTTRtimer.
- if a valid TPDU is received as the result of the resynchronization, stop the
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 it isn't already started. The arrival of the first TPDU related to the transport connection (because the initiator resynchronized) 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 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
- Provided that the required quality of service is met,
TTRMAY 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 🌤️ - Including the reassignment time parameter in the
CR TPDUallows the responder to use aTWRvalue of less than 2 minutes 💫 - If the optional
TS1andTS2timers are used, it is RECOMMENDED:
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 values for TS1 and TS2 greater than TTR 🌸
6.13 Retention until acknowledgement of TPDUs
6.13.1 Purpose 🎀
Okay bestie, this is the retention until acknowledgement of TPDUs procedure 🧚 It's used in classes 1, 3 and 4 to enable and minimize retransmission after possible loss of TPDUs, so if something gets lost we can resend it without starting over 💖
The confirmation of receipt variant is only used in Class 1, and only 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,DRandDCTPDUs; - b)
RJandAKTPDUs;YR-TU-NR
- c)
DTTPDU;TPDU-NR
- d)
EDTPDU;ED-TPDU-NR
- e)
EATPDU;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 🌸
- 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
DTTPDUs. - Use of the confirmation request parameter may affect the quality of network service.
|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 📊
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,CCandDCTPDUs - b)
RJTPDUs;YR-TU-NR
- c)
DTTPDU;TPDU-NR
- d)
EDTPDU;ED TPDU-NR
- e)
EATPDU;YR-EDTU-NR
A transport entity which is notified of the occurrence 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
CRTPDU is unacknowledged, then the transport entity SHALL retransmit it; - 2) if a
DRTPDU 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).
- 1) if a
The TTR timer is stopped when a valid TPDU is received 🫶
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
DRTPDU, then the transport entity SHALL send aDCTPDU; - b) if it is a repeated
CRTPDU (see note 1), then the transport entity SHALL carry out the appropriate action from the following:- 1) if a
CCTPDU has already been sent, and acknowledged: treat as a protocol error; - 2) if a
DRTPDU is unacknowledged (whether or not aCCTPDU is unacknowledged): retransmit theDRTPDU, 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
CCTPDU followed by an unacknowledgedEDTPDU (see note 2) and anyDTTPDU;
- 1) if a
NOTES
- A repeated
CRTPDU can be identified by being on a network connection with the appropriate network addresses and having a correct source reference. 🔍 - The transport entity SHOULD NOT use network expedited until the
CCTPDU is acknowledged (see 6.5). This rule prevents the network expedited from overtaking theCCTPDU. 🚫
- c) if it is an
RJorEDTPDU, then one of the following actions SHALL be taken:- 1) if a
DRTPDU 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
CCTPDU was unacknowledged, theRJorEDTPDU SHOULD then be considered as acknowledging theCCTPDU. If aCCTPDU was never sent, theRJTPDU SHOULD then be considered as a protocol error. 🙈
- 1) if a
6.14.4.3 Data Resynchronization Procedures 🌸
The transport entity SHALL carry out the following actions in the following order:
- a) (re)transmit any
EDTPDU which is unacknowledged, - b) transmit an
RJTPDU withYR-TU-NRfield set to theTPDU-NRof the next expectedDTTPDU; - c) wait for the next TPDU from the other transport entity, unless an
RJorDRTPDU has already been received. If aDRTPDU is received, the transport entity SHALL send aDC, 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 anRJTPDU is received, the procedure of 6.14.4.3.d SHALL be followed. If anEDTPDU is received, the procedures as described in 6.11 SHALL be followed. If it is a duplicatedED-TPDU, the transport entity SHALL acknowledge it, with anEATPDU, discard the duplicatedEDTPDU and wait again for the next TPDU. 🎀 - d) (re)transmit any
DTTPDUs 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
The transport entities SHALL be able to send and receive on the same network connection TPDUs belonging to different transport connections 🌈
NOTES
- When performing demultiplexing, the transport connection to which the TPDUs apply is determined by the procedures defined in 6.9. 🔍
- 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 💅
okay so 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
okay the procedure uses these TPDUs and parameters 🎀
- a)
CR,CC,AKandRJTPDUsCDT
- b)
DTTPDUTPDU-NR
- c)
AKTPDUYR-TU-NR;- subsequence number;
- flow control confirmation.
- d)
RJTPDUYR-TU-NR.
6.16.3 Procedure
the procedures are different for each class 🦋 they get defined in the clauses for each separate class, so go check those out 💖
6.17 Checksum
6.17.1 Purpose
the checksum procedure exists to catch corruption of TPDUs by the NS-provider 🔍
NOTE - the checksum algorithm has to match the kinds of errors you expect on the network connection, but right now only one algorithm is defined 🌸
6.17.2 TPDUs and parameters used
the procedure uses these TPDUs and parameters:
- All TPDUs
checksum
the checksum is only used in Class 4 🧚 it's always used for the CR TPDU, and it's used for every other TPDU too, unless both sides agreed to skip it during connection establishment 🙈
the sending transport entity SHALL transmit TPDUs with the checksum parameter set so that these formulas are satisfied 🔥
SUM(from i=1 to i=L) OF a[i] EQUALS <zero> (module 255)
SUM(from i=1 to i=L) OF i*a[i] EQUALS <zero> (module 255)where:
i = number (i.e. position) of an octet within the TPDU
(see 13.2);
a[i] = value of octet in position 1;
L = length of TPDU in octets.if a transport entity gets a TPDU for a connection where checksum use was agreed, and that TPDU doesn't pass the formulas above, it SHALL discard the TPDU (see also note 2) 💀
NOTES
- there's an efficient algorithm for working out the checksum parameters in annex B ✨
- if the checksum is wrong, you can't be totally sure which transport connection the TPDU belongs to 😭 so further action MAY be taken for all the transport connections assigned to that network connection (see 6.9)
- the checksum is super easy to calculate, so it won't be a heavy burden on implementations 🍓 but it won't catch insertion or loss of leading or trailing zeros, and it won't catch some octets being in the wrong order 🙃
6.18 Frozen references
6.18.1 Purpose
this procedure stops a reference from getting re-used while TPDUs tied to its old use might still be floating around 👻
6.18.2 Procedure
when a transport entity decides a connection is released, it SHALL put the reference it allocated for that connection into a frozen state, following the procedures for the class 🧊 while it's frozen, the reference SHALL NOT be re-used 🚫
NOTE - freezing is needed because retransmission or misordering can make TPDUs carrying a reference show up at an entity after it already released the connection that reference was for 😱 retransmission, for example, can happen 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 - for consistency with the other classes, freezing the references MAY be done as a local decision 🎀
6.18.2.2 Procedure for classes 1 and 3
the frozen reference procedure is used except in these cases (see note 1) 👑
- a) when the transport entity gets a DC TPDU in response to a DR TPDU it sent (see note 2);
- b) when the transport entity sends a DR or ER TPDU in response to a CR TPDU it received (see note 3);
- c) when the transport entity has considered the connection released after the TWR timer expires (see note 4);
- d) when the transport entity gets a DR or ER TPDU in response to a CR TPDU it sent.
the frozen period for the reference SHALL be greater than the TWR time ⏳
NOTES
- even in these cases, freezing the reference MAY still be done as a local decision, just for consistency 🌈
- once the DC TPDU arrives, the other transport entity is definitely done and considers the connection released 🫶
- when the DR or ER TPDU is sent, the peer hasn't been told about any reference assignment, so it can't possibly use one 🧚 (this includes the case where a CC TPDU was sent but got lost 😭)
- in case c) above, the transport entity has already effectively frozen the reference for a good amount of time ⭐
6.18.2.3 Procedure for classes 4
the frozen reference procedure is always used in class 4 🔥 the period the reference stays frozen SHOULD be greater than L (see 12.2.1.1.6) 🦋
6.19 Retransmission on time-out
6.19.1 Purpose
this procedure is used in Class 4 to deal with unsignalled loss of TPDUs by the NS-provider 🥺
6.19.2 TPDUs used
the procedure makes use of these TPDUs:
CR,CC,DR,DT,ED,AKTPDUs.
6.19.3 Procedure
the procedure is spelled out in the Class 4 procedures (see 12.2.1.2.j) 💖
6.20 Resequencing
the resequencing procedure is used in Class 4 to handle misordering of TPDUs by the network service provider 🌀
6.20.2 TPDUs and parameters used
the procedure uses these TPDUs and parameters:
- a)
DTTPDU;TPDU-NR.
- b)
EDTPDUED TPDU-NR
6.20.3 Procedure
the procedure is spelled out in the Class 4 procedures (see 12.2.3.5) 🎀
6.21 Inactivity control
6.21.1 Purpose
the inactivity control procedure is used in Class 4 to handle unsignalled termination of a network connection 🫥
the procedure is spelled out in the Class 4 procedures (see 12.2.3.3) ✨
6.22 Treatment of protocol errors
6.22.1 Purpose
the protocol error treatment procedure is used in all classes to deal with invalid TPDUs 🚨
6.22.2 TPDUs and parameters used
the procedure uses these TPDUs and parameters:
- a)
ERTPDU;- reject cause;
- TPDU in error.
- b)
DRTPDU;- reason code.
6.22.3 Procedure
if a transport entity gets a TPDU that can be tied to a transport connection, and that TPDU is invalid or counts as a protocol error (see 3.2.16 and 3.2.17), it SHALL take one of these actions, making sure not to hurt any other transport connections that aren't assigned to that network connection 🫶
- a) ignoring the TPDU;
- b) transmitting an
ERTPDU; - 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 can't be tied to a particular transport connection, then see 6.9 🙈
NOTES
- generally, no further action is specified for the receiver of the ER TPDU, but it is RECOMMENDED that it starts the release procedure appropriate to the class 🔥 if the ER TPDU was an answer to a CR TPDU, then the connection counts as released (see 6.6) 🌸
- careful, bestie: if you're getting several invalid TPDUs or ER TPDUs, make sure you don't get stuck in a loop when the error keeps happening 🔁 Care SHOULD be taken here 😭
- if the invalid received TPDU is bigger than the selected maximum TPDU size, it might not fit inside the invalid TPDU parameter of the ER TPDU 🍓
- it is RECOMMENDED that the sender of the ER TPDU starts an OPTIONAL timer TS2 to make sure the connection gets released 🧚 if that timer expires, the transport entity SHALL start the release procedures for the class 💀 the timer SHOULD be stopped when a DR TPDU or an
N-DISCONNECTindication shows up 🦋 - in classes other than 0, it is RECOMMENDED that the invalid TPDU also gets included in the ER TPDU 🌈
6.23 Splitting and recombining
6.23.1 Purpose
this procedure is only used in class 4 ✨ it lets a transport connection use multiple network connections for extra resilience against network failure, more throughput, or other reasons 🚀
6.23.2 Procedure
when this procedure is in use, 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 of those network connections 💜
if the remote transport entity doesn't accept Class 4 under the negotiation rules, then no network connection except the one the CR TPDU went over MAY have this transport connection assigned to it 🙅♀️
NOTES
- the resequencing function of Class 4 (see 6.20) makes sure TPDUs get processed in the right order 🎀
- either transport entity MAY assign the connection to more network connections that it owns, at any point during the life of the transport connection 🫶
- to make unsignalled network connection failures detectable 🔍, a transport entity doing splitting SHOULD send TPDUs at intervals on each supporting network connection, for example by sending successive TPDUs on successive network connections, cycling through the set of network connections 🔁 by monitoring each network connection, a transport entity MAY detect unsignalled network connection failures, following the inactivity procedures defined in 12.2.3.3 💖 so for each network connection, no period I (see 12.2.3.1) MAY pass without receiving some TPDU for some transport connection 🌊
7 Protocol Classes ✨
Table 6 is basically the cheat sheet 📋💖 showing which procedures show up in each class. Heads up, bestie: some procedures are not 100% identical from class to class, so this table is not part of the official spec, just a helpful overview ✨
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 giving minimum functionality, and I'm obsessed with how lean it is 🫶 It only covers what's needed for connection establishment with negotiation, data transfer with segmenting, and protocol error reporting.
Class 0 gives transport connections flow control that rides on the flow control the network service already provides, and disconnection that rides on the network service's disconnection. Iconic minimalism 💅
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 gives transport connections flow control based on the network service's flow control, plus error recovery, expedited data transfer, disconnection, and the ability to support consecutive transport connections on a network connection. Main character energy 👑
This class is Class 0 plus the ability to recover after a failure signalled by the Network Service, all without involving the TS-user. Bestie, that's the glow-up 💖
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 on item g) 📝
- 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.
- 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. - 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
- bestie, using RJ TPDU during resynchronization (see 6.14) can lead to retransmission 🔁 so getting a duplicate DT TPDU is totally possible 👀 and when that happens, the duplicate DT TPDU just gets discarded 🗑️✨
- also, it's possible to decide locally to issue an N-RESET request 💅 which forces the remote entity to do the resynchronization (see 6.14). main character move 👑
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 an 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
- ok so the negotiation of which expedited data transfer variant gets used on the transport connection was designed super carefully 🧠 if the initiator proposes the network normal data variant (the mandatory implementation option), the responder has to accept it 🙌 but if the initiator proposes the network expedited variant, the responder is allowed to pick the network normal data variant instead 🌸
- this numbering lets the receiving transport entity throw away repeated ED TPDUs once resynchronization (see 6.14) has happened 🗑️💜
- no other significance is attached to the
ED-TPDU-NRparameter 🤷♀️ it's 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) 👋
10 SPECIFICATION FOR CLASS 2 - MULTIPLEXING CLASS 🌈
10.1 Functions of class 2 💅
class 2 provides transport connections with or without individual flow control 🌊 and 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 that allows the receiver to tell the sender the exact amount of data they're willing to receive 🧁 and expedited data transfer is available too ⚡
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).
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);
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 that's used by both transport entities shall be the one that 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 0️⃣ 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-NRparameter shall be at most one greater than theTPDU-NRfield 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-NRparameter shall not be lower than that in the previously sent AK TPDU; - c) the sum of the
YR-TU-NRandCDTfields shall not be less than the upper window edge allocated to the remote entity (see note 1) 🫧
a transport entity that 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
- this means that credit reduction is not applicable 🙅♀️
- this means that a transport entity is required to stop sending if the
TPDU-NRfield of the next DT TPDU that would be sent would be the upper window edge 🛑 sending of DT TPDUs may be resumed if an AK TPDU is received which increases the upper window edge 🟢 - 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 🎲
10.2.5 Release 🎀
the transport entities shall use the explicit variant of the release procedure in 6.7 👋
11 SPECIFICATION FOR CLASS 3: ERROR RECOVERY AND MULTIPLEXING CLASS 🦋
11.1 Functions of Class 3 🛡️
class 3 provides the functionality of class 2 (with use of explicit flow control) plus the ability to recover after a failure signalled by the Network Layer, without involving the user of the transport service 🙌
the mechanisms used to achieve this functionality also allow the implementation of more flexible flow control 🌸
11.2 Procedures for Class 3 ✨
11.2.1 Procedures applicable at all times 💅
the transport entities shall use the following procedures:
- a) association of TPDUs with transport connections (see 6.9);
- b) TPDU transfer (see 6.2) and retention until acknowledgement of TPDUs (AK variant only) (see 6.13);
- c) treatment of protocol errors (see 6.22);
- d) concatenation and separation (see 6.4);
- e) reassignment after failure (see 6.12), together with resynchronization (see 6.14);
- f) frozen references (see 6.18).
additionally, the transport entities may use the following procedure:
- g) multiplexing and demultiplexing (see 6.15);
11.2.2 Connection Establishment 🤝
the transport entities shall use the following procedures:
- a) assignment to network connections (see 6.1); then
- b) connection establishment (see 6.5) and, if appropriate, together with connection refusal (see 6.6).
11.2.3 Data Transfer 🧁
11.2.3.1 General
the sending transport entity shall use the following procedures:
- a) segmenting (see 6.3), then
- b) DT TPDU numbering (see 6.10); after receipt of an RJ TPDU (see 11.2.3.2), the next DT TPDU to be sent may have a value which is not the previous value of
TPDU-NRplus one 🔢
the receiving transport entity shall use the following procedures:
- c) DT TPDU numbering (see 6.10); the
TPDU-NRfield of each received DT TPDU shall be treated as a protocol error if it exceeds the greatest such value received in a previous DT TPDU by more than one (see note); then - d) reassembling (see 6.3); duplicated TPDUs shall be eliminated before reassembling is performed 🧩
NOTE - the use of RJ TPDUs (see 11.2.3.2) can lead to retransmission and reduction of credit 🔁 thus the receipt of a DT TPDU which is a duplicate, or which is greater than or equal to the upper window edge allocated to the peer entity, is possible and is therefore not treated as a protocol error 💭
11.2.3.2 Use of RJ TPDU 🎀
a transport entity may send an RJ TPDU at any time in order to invite retransmission or to reduce the upper window edge allocated to the peer entity (see note 1) 💌
when an RJ TPDU is sent, the following constraints shall be respected:
- a) the
YR-TU-NRparameter 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-NRparameter 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 the one for which the value of the
TPDU-NRparameter is equal to the value of theYR-TU-NRparameter of the RJ TPDU 🎯 - d) the sum of
YR-TU-NRandCDTin the RJ TPDU becomes the new upper window edge (see note 4). 🪟✨
NOTES 📝
- An RJ TPDU can also get sent as part of the resynchronization (see 6.14) and reassignment after failure (see 6.12) procedures. 🔁
- It is recommended that the
YR-TU-NRparameter be equal to theTPDU-NRparameter of the next expected DT TPDU. 💭 - 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). 🧩
- This means an 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-NRparameter 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-NRof 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 📝
- This can only occur during retransmission following receipt of an RJ TPDU. 🔄
- 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 the expedited data transfer procedure in 6.11 if its use has been agreed during connection establishment. 🤝
The sending transport entity shall not allocate the same ED-TPDU-NR to successive ED TPDUs. 🚫🔢
The receiving transport entity shall transmit an EA TPDU with the same value in its YR-EDTU-NR parameter. If, and only if, this number is different from that of the previously received ED TPDU, shall it generate a T-EXPEDITED DATA indication to convey the data to the TS-user (see note 2). 📬💖
NOTES 📝
- No other significance is attached to the
ED-TPDU-NRparameter. It is recommended, but not essential, that the values be consecutive modulo2**n, wherenis the number of bits of the parameter. 🔢🌈 - This procedure ensures that the TS-user does not receive data corresponding to the same ED TPDU more than once. 🙅♀️💯
11.2.4 Release 👋
The transport entities shall use the explicit variant of the release procedure in 6.7. 💌
12 SPECIFICATION FOR CLASS 4: ERROR DETECTION AND RECOVERY CLASS 🦋👑
12.1 Functions of Class 4 🧁
Class 4 provides the functionality of Class 3, plus the ability to detect and recover from lost, duplicated, or out of sequence TPDUs without involving the TS-user. It's giving reliability, bestie 💖
This detection of errors is made by extended use of the DT TPDU numbering of Class 2 and Class 3, by time-out mechanisms, and by additional procedures. 🕰️🔍
This class additionally detects and recovers from damaged TPDUs by using a checksum mechanism. The use of the checksum mechanism must be available, but its use or its non-use is subject to negotiation. ✅🤍
Further on, this class provides additional resilience against network failure and increased throughput capability by allowing a transport connection to make use of multiple network connections. 🌐🚀
12.2 Procedures for Class 4 🎀
12.2.1 Procedures available at all times 🌸
12.2.1.1 Timers used at all times ⏰
This subclause defines timers that apply at all times in class 4. These timers are listed in table 7. 📋
This International Standard does not define specific values for the timers, and the derivations described in this subclause are not mandatory. The values should be chosen so that the required quality of service can be provided, given the known characteristics of the network. 🧠✨
Timers that apply only to specific procedures are defined under the appropriate procedure. 📌
+---------------------------|------------------------------------+
|Symbol| Name | Definition |
|------|--------------------|------------------------------------|
| MLR |NSDU lifetime | A bound for the maximum time which |
| |local-to-remote | may elapse between the transmis- |
| | | sion of an NSDU by a local trans- |
| | | port entity and the receipt of any |
| | | copy of it by a remote peer entity.|
| | | |
| MRL |NSDU lifetime | A bound for the maximum time which |
| |remote-to-local | may elapse between the transmission|
| | | of an SNDU from a remote transport |
| | | entity to a remote peer entity. |
| | | |
| ELR |Expected maximum | A bound for the maximum delay suf- |
| |transit delay | fered by all but a small proportion|
| |local-to-remote | of NSDUs transferred from the local|
| | | transport entity to a remote peer |
| | | entity. |
| | | |
| ERL |Expected maximum | A bound for the maximum delay suf- |
| |transit delay | fered by all but a small proportion|
| |remote-to-local | of NSDUs transferred from a remote |
| | | transport entity to the local peer |
| | | entity. |
| | | |
| AL |Local acknowledge | A bound for the maximum time which |
| |time | can elapse between the receipt of |
| | | a TPDU by the local transport en- |
| | | tity from the network layer and |
| | | the transmission of the corres- |
| | | ponding acknowledgement. |
| | | |
| AR |Remote acknow- | As AL, but for the remote entity. |
| |ledgement time | |
+----------------------------------------------------------------+Table 7. (First of 2 pages) Time Parameters related to class 4 📊
| T1 |Local retrans- | A bound for the maximum time that |
| |mission time | the local transport entity will |
| | | wait for acknowledgement before re-|
| | | transmitting a TPDU. |
| | | |
| R |Persistence time | A bound for the maximum time the |
| | | the local transport entity will |
| | | continue to transmit a TPDU that |
| | | requires acknowledgement. |
| | | |
| N |Maximum number of | A bound for the maximum number of |
| |transmissions | times which the local transport |
| | | entity will continue to transmit a |
| | | TPDU that requires acknowledgement.|
| | | |
| L |Bound on references | A bound for the maximum time |
| |and sequence | between the transmission of a TPDU |
| |numbers | and the receipt of any acknow- |
| | | ledgement relating to it. |
| | | |
| I |Inactivity time | A bound for the time after which |
| | | a transport entity will, if it |
| | | does not receive a TPDU, initiate |
| | | the release procedure to terminate |
| | | the transport connection. |
| | | |
| | | NOTE - This parameter is required |
| | | for protection against unsignalled |
| | | breaks in the network connection. |
| | | |
| W |Window time | A bound for the maximum time a |
| | | transport entity will wait before |
| | | retransmitting up to date window |
| | | information. |
+----------------------------------------------------------------+Table 7. (Second of 2 pages) Time Parameters related to class 4 📊
12.2.1.1.1 NSDU lifetime (MLR, MRL) ⌛
The network layer is assumed to provide, as an aspect of its grade of service, for a bound on the maximum lifetime of NSDUs in the network. This value may be different in each direction of transfer through a network between two transport entities. The values, for both directions of transfer, are assumed to be Known (capital K and all) 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 part 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 between two transport entities. Both directions' values 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 transferred through the network from the remote transport entity to the local transport entity. 💖
12.2.1.1.3 Acknowledge Time (AR, AL)
Any transport entity is assumed to provide a bound for the maximum time which can elapse between its receipt of a TPDU from the Network Layer and its transmission of the corresponding response. 🎀 This value is referred to as AL. The corresponding time given by the remote transport entity is referred to as AR. 💅
12.2.1.1.4 Local retransmission time (T1)
The local transport entity is assumed to maintain a bound on the time it will wait for an acknowledgement before retransmitting the TPDU. ⏰ Its value is given by:
T1 = ELR + ERL + AR + Xwhere:
- 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 retransmissions, T1, and the maximum number of transmissions, N. 🌸 It is not less than T1 * N + X, where X is a small quantity to allow for additional internal delays, the granularity of the mechanism used to implement T1 and so on. 🙈 Because R is a bound, the exact value of X is unimportant as long as it is bounded and the value of a bound is known. 🧚
12.2.1.1.6 Bound on References and Sequence Numbers (L)
A bound for the maximum time between the decision to transmit a TPDU and the receipt of any response relating to it (L) is given by:
L = MLR + MRL + R + ARwhere:
- 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 or sequence number, to avoid confusion in case a TPDU referring to it may be duplicated or delayed. 😭
NOTES
- 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. 🍓
- The relationships between times discussed above are illustrated in figures 3 and 4.
[Figures 3 and 4 are omitted from this copy.]
12.2.1.2 General Procedures
The transport entity SHALL use the following procedures:
- a) TPDU transfer (see 6.2);
- b) association of TPDUs with transport connections (see 6.9);
- c) treatment of protocol errors (see 6.22);
- d) checksum (see 6.17);
- e) splitting and recombining (see 6.23);
- f) multiplexing and demultiplexing (see 6.15);
- g) retention until acknowledgement of TPDUs (see 6.13);
- h) frozen references (see 6.18);
- j) retransmission procedures: when a transport entity has some outstanding TPDUs that require acknowledgement, it will check that no T1 interval elapses without the arrival of a TPDU that acknowledges at least one of the outstanding TPDUs. 👑
If the timer expires, except if the TPDU to be retransmitted is a DT TPDU and it is outside the transmit window due to 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
- 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:
- if the transport entity transmits a TPDU requiring acknowledgement, it starts timer T1;
- 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;
- 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. 🌈
- 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.
- It is RECOMMENDED that after N transmissions of a DT TPDU, the transport entity waits T1 + W + MRL to provide a higher possibility of receiving an acknowledgement before entering the release phase. For other TPDU types which MAY be retransmitted, it is RECOMMENDED that after N transmissions the transport entity waits T1 + MRL to provide a higher possibility of receiving the expected reply. ✨
12.2.2 Procedures for Connection Establishment
12.2.2.1 Timers used in Connection Establishment
There are no timers specific to connection establishment. 🫶
12.2.2.2 General Procedures
The transport entities SHALL use the following procedures:
- a) assignment to network connection (see 6.1);
- b) connection establishment (see 6.5) and if appropriate connection refusal (see 6.6) together with the additional procedures:
- 1) a connection is not considered established until the successful completion of a 3-way TPDU exchange. The sender of a CR TPDU SHALL respond to the corresponding CC TPDU by immediately sending a DT, ED, DR or AK TPDU;
- 2) as a result of duplication or retransmission, a CR TPDU MAY be received specifying a source reference which is already in use with the sending transport entity. If the receiving transport entity is in the data transfer phase, having completed the 3-way TPDU exchange procedure, or is waiting for the T-CONNECT response from the TS-user, the receiving transport entity SHALL ignore such a TPDU. Otherwise a CC TPDU SHALL be transmitted;
- 3) as a result of duplication or retransmission, a CC TPDU MAY be received specifying a paired reference which is already in use. The receiving transport entity SHALL only acknowledge the duplicate CC TPDU according to the procedure in 12.2.2.2.b.1;
- 4) a CC TPDU MAY be received specifying a reference which is in the frozen state. The response to such a TPDU SHALL be a DR TPDU;
- 5) the retransmission procedures (see 12.2.1.2) are used for both the CR TPDU and CC TPDU.
12.2.3 Procedures for Data Transfer
12.2.3.1 Timers used in Data Transfer
The data transfer procedures use two additional timers:
- a) Inactivity Time (I)
To protect against unsignalled breaks in the network connection or failure of the peer transport entity (half-open connections), each transport entity maintains an inactivity interval. The interval MUST be greater than E. 🧸
NOTE - A suitable value for I is given by:
2 * (N * maximum of (T1, W))unless local needs indicate another more appropriate value.
- b) Window Time (W)
A transport entity maintains a timer interval to ensure that there is a bound on the maximum interval between window updates. 🪟
12.2.3.2 General Procedures for data transfer
The transport entities SHALL use the following procedures:
- a) inactivity control (see 6.21);
- b) expedited data (see 6.11);
- c) explicit flow control (see 6.16).
The sending transport entity SHALL use the following procedures in the following order:
- d) segmenting (see 6.3);
- e) DT TPDU numbering (see 6.10).
The receiving transport entity SHALL use the following procedures in the following order:
- f) DT TPDU numbering (see 6.10);
- g) resequencing (see 6.20);
- h) reassembling (see 6.3).
12.2.3.3 Inactivity Control
If the interval of the inactivity timer I expires without receipt of some TPDU, the transport entity SHALL initiate the release procedures. To prevent expiration of the remote transport entity's inactivity timer when no data is being sent, the local transport entity MUST send AK TPDUs at suitable intervals in the absence of data, having regard to the probability of TPDU loss. The window synchronization procedures (see 12.2.3.8) ensure that this requirement is met. 🥹
NOTE - It is likely that the release procedure initiated due to the expiration of the inactivity timer will fail, as such expiration indicates probable failure of the supporting network connection or of the remote transport entity. 🫠
12.2.3.4 Expedited Data
The transport entities SHALL follow the network normal data variant of the expedited data transfer procedures (see 6.11), if the use of transport expedited service option has been agreed during connection establishment. 🚨
The ED TPDU gets its own TPDU-NR 💖, and it comes from a totally separate sequence space from the DT TPDUs. No mixing them up, bestie 🎀
A transport entity SHALL allocate the sequence number zero to the ED TPDU-NR of the first ED TPDU which it transmits for a transport connection. For each later ED TPDU sent on the same transport connection, the transport entity SHALL allocate a sequence number one greater than the previous one ✨
Modulo 27 arithmetic SHALL be used when normal formats have been selected, and modulo 231 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. It also 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 TPDUs received out-of-sequence and outside the transmit window SHALL be discarded 🗑️
Duplicate TPDUs can be detected because the sequence number matches that of previously received TPDUs. Sequence numbers SHALL NOT be reused for the period L after their previous use 👑
Otherwise, a new, valid TPDU could be confused with a duplicated TPDU which had previously been received and acknowledged 😭
Duplicated DT TPDUs SHALL be acknowledged, since the duplicated TPDU may be the result of a retransmission resulting from the loss of an AK TPDU 🦋
The data contained in a duplicated DT TPDU SHALL be ignored 🙈
12.2.3.6 Explicit Flow Control 🌸
The transport entities SHALL send an initial credit (which MAY take the value 0) in the CDT field of the CR TPDU or CC TPDU. This credit represents the initial value of the upper window edge of the peer entity 🎀
The transport entity which receives the CR TPDU or CC TPDU SHALL consider its lower window edge as zero, and its upper window edge as the value in the CDT field in the received TPDU 🧚
In order to authorize the transmission of DT TPDUs by its peer, a transport entity MAY transmit an AK TPDU at any time 🔥
The sequence number of an AK TPDU SHALL NOT exceed the sequence number of the next expected DT TPDU, i.e. it SHALL NOT be greater than the highest sequence number of a received DT TPDU, plus one 🙅♀️
A transport entity MAY send a duplicate AK TPDU containing the same sequence number, CDT, and subsequence number field at any time 🍓
A transport entity which receives an AK TPDU SHALL consider the value of the YR-TU-NR field as its new lower window edge if it is greater than any previously received in a YR-TU-NR field, and the sum of YR-TU-NR and CDT as its new upper window edge, subject to the procedures for sequencing AK TPDUs (see 12.2.3.8). A transport entity SHALL NOT transmit or retransmit a DT TPDU with a sequence number outside the transmit window 🌈
12.2.3.7 Sequencing of received AK TPDUs 🦋
To allow a receiving transport entity to properly sequence a series of AK TPDUs that all contain the same sequence number, and thereby use the correct CDT value, AK TPDUs MAY contain a subsequence parameter. For the purpose of determining the correct sequence of AK TPDUs, the absence of the subsequence parameter SHALL be equivalent to the value of the parameter set to zero 💜
An AK TPDU is defined to be in sequence if:
- a) the sequence number is greater than in any previously received AK TPDU, or
- b) the sequence number is equal to the highest in any previously received AK TPDU, and the subsequence parameter is greater than in any previously received AK TPDU having the same value for
YR-TU-NRfield, 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-NRfield.
A transport entity is not REQUIRED to include the subsequence number in its AK TPDUs. It MAY also choose not to use the subsequence parameter in sequencing received AK TPDUs. If a transport entity chooses not to recognize the subsequence parameter, it SHALL still sequence received AK TPDUs according to 12.2.3.7.a 🎀
When the receiving transport entity recognizes an out of sequence AK TPDU, it SHALL ignore it 🙈
12.2.3.8 Procedure for transmission of AK TPDUs 💅
12.2.3.8.1 Retransmission of AK TPDUs for window synchronization 🌸
A transport entity SHALL NOT allow an interval W to pass without the transmission of an AK TPDU. If the transport entity is not using the procedure following setting CDT to zero (see 12.2.3.8.3) or reduction of the upper window edge (see 12.2.3.8.4), and does not have to acknowledge receipt of any DT TPDU, then it SHALL achieve this by retransmission of the most recent AK TPDU, with up-to-date window information ⏰
NOTE - The use of the procedures defined in 12.2.3.8.3 and 12.2.3.8.4 are OPTIONAL for any transport entity. The protocol operates correctly either with or without these procedures, which are defined to enhance the efficiency of its operation. However, if these procedures are not used, thenWMUST be set to ensure enough retransmissions of the AK TPDU so that release ofTCis avoided. The value ofWSHOULD be approximatelyW = (T1 * N)/(N-1)when the procedures are not used 🧠
12.2.3.8.2 Sequence control for transmission of AK TPDUs 🦋
To allow the receiving transport entity to process AK TPDUs in the correct sequence, as described in 12.2.3.7, the subsequence parameter MAY be included following reduction of CDT. If the value of the subsequence number to be transmitted is zero, then the parameter SHOULD be omitted 🍓
The value of the subsequence parameter, if used, SHALL be zero (either explicitly or by absence of the parameter) if the sequence number is greater than the field in previous AK TPDUs sent by the transport entity 💖
If the sequence number is the same as the previous AK TPDU sent, and the CDT field is equal to or greater than the CDT field in the previous AK TPDU sent, then the subsequence parameter, if used, SHALL be equal to that in the previously sent AK TPDU 🫶
If the sequence number is the same as the previous AK TPDU sent, and the CDT field is less than the value of the CDT field in the previous AK TPDU sent, then the subsequence parameter, if used, SHALL be one greater than the value in the previous AK TPDU. 🔥
12.2.3.8.3 Retransmission of AK TPDUs after CDT set to zero 🌈
Due to the possibility of loss of AK TPDUs, the upper window edge as perceived by the transport entity transmitting an AK TPDU may differ from that perceived by the intended recipient. To avoid the possibility of extra delay, the retransmission procedure (see 12.2.1.2) SHOULD be followed for an AK TPDU if it opens the transmit window which has previously been closed by sending an AK TPDU with CDT field set to zero 👑
The retransmission procedure, if used, terminates, and the procedure in 12.2.3.8.1 is used when:
- a) an AK TPDU is received containing the flow control confirmation parameter, whose lower window edge and your subsequence fields are equal to the sequence number and subsequence number in the retained AK TPDU, and whose credit field is not zero.
- b) an AK TPDU is transmitted with a sequence number higher than that in the retained AK TPDU, due to reception of a DT TPDU whose sequence number is equal to the lower window edge;
- c) N transmissions of the retained AK TPDU have taken place. In this case the transport entity SHALL continue to transmit the AK TPDU at an interval of W.
An AK TPDU which is subject to the retransmission procedure SHALL NOT contain the flow control confirmation parameter. If it is REQUIRED to transmit this parameter concurrently, an additional AK TPDU SHALL be transmitted, having the same values in the sequence, subsequence (if applicable) and credit fields 🎀
12.2.3.8.4 Retransmission procedures following reduction of the upper window edge ✨
This subclause specifies the procedure for retransmission of AK TPDUs after a transport entity has reduced the upper window edge (see 12.2.3.6), or for an AK TPDU with the credit field set to zero. This procedure is used until the lower window edge exceeds the highest value of the upper window edge ever transmitted (i.e. the value existing at the time of credit reduction, unless a higher value is retained from a previous credit reduction) 🧚
This retransmission procedure SHOULD be followed for any AK TPDU which increases the upper window edge, unless an AK TPDU has been received containing a flow control confirmation parameter, which corresponds to an AK TPDU transmitted following credit reduction, for which the sum of the credit and lower window edge fields (i.e. the upper window edge value) is greater than the lower window edge (YR-TU-NR field) of the transmitted AK TPDU 💜
This retransmission procedure for any particular AK TPDU SHALL terminate when:
- a) an AK TPDU is received containing the flow control confirmation parameter, whose lower window edge and your subsequence fields are equal to the lower window edge and subsequence number in the retained AK TPDU; or
- b) N transmissions of the retained AK TPDU have taken place. In this case the transport entity SHALL continue to transmit the AK TPDU at an interval of W.
Okay so this is where the retransmission rules get really specific 🎀. An AK TPDU that goes through the retransmission procedure SHALL NOT contain the flow control confirmation parameter 🙅♀️. If you need to send that parameter at the same time, you send an extra AK TPDU with the exact same sequence, subsequence (if applicable) and credit fields ✨.
NOTE 💭 Retransmitting AK TPDUs is usually not needed, except after an explicit window close (an AK TPDU with the CDT field set to zero). If data is waiting to go out, the retransmission procedure for DT TPDUs makes sure an AK TPDU arrives that grants more credit, as long as that credit is available. After a credit reduction, that might not be true anymore, because the reduction can stop retransmission from happening. The rules in this clause are there to avoid extra delay 🦋.
The same rules can be written another way, and honestly the math version is kind of iconic 🧮. The rules for deciding 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 entityThe retransmission procedure is to be used whenever:
(UWE>LWE) and (KUWE = LWE)Basically, that's when the window has opened and it isn't known for sure that the remote transport entity knows about it 👀.
KUWE is maintained like this 💅. When credit is reduced, KUWE is set to LWE. After that, it only goes up when a valid flow control confirmation shows up (meaning one that matches the retained lower window edge and subsequence). In that case, KUWE is set to the implied upper window edge of the flow control confirmation, which is the sum of its lower window edge and your credit fields. This is how it's guaranteed that KUWE is always less than or equal to the actual upper window edge being used 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 🎁. Its lower window edge, your subsequence and your credit fields SHALL be set to the same values as the matching fields in the most recently received in sequence AK TPDU 🫶.
An AK TPDU containing a flow control confirmation parameter SHOULD be transmitted whenever:
- a) a duplicate AK TPDU shows up, with the YR-TU-NR, CDT and subsequence fields equal to the most recently received AK TPDU, but it doesn't itself contain the flow control confirmation parameter 👯;
- b) an AK TPDU is received that increases the upper window edge but not the lower window edge, and the upper window edge used to be equal to the lower window edge; or
- c) an AK TPDU is received that increases the upper window edge but not the lower window edge, and the lower window edge is lower than the highest upper window edge value received and later reduced (meaning following credit reduction) 🌈.
12.2.4. Procedures for Release 🚪
12.2.4.1. Timers used for Release ⏰
There are no timers used only for release 😌.
12.2.4.2. General Procedures for Release 👋
The transport entity SHALL use the explicit variant of normal release (see 6.7) 💜.
13. STRUCTURE AND ENCODING OF TPDUs 🧚
13.1. Validity 📋
Table 8 is the list of which TPDUs are valid for each class, plus the code for each TPDU 🍓. Here's the key:
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 being used in related protocols that are defined by standards organisations other than CCITT/ISO 🌸.
| | Validity within | | |
| | classes | see | Code |
| |-------------------| Clause| |
| | 0 | 1 | 2 | 3 | 4 | | |
|-----------------------|-------------------|-------|---------|
|CR Connection Request | x | x | x | x | x | 13.3 |1110 xxxx|
|-----------------------|---|---|---|---|---|-------|---------|
|CC Connection Confirm | x | x | x | x | x | 13.4 |1101 xxxx|
|-----------------------|---|---|---|---|---|-------|---------|
|DR Disconnect Request | x | x | x | x | x | 13.5 |1000 0000|
|-----------------------|---|---|---|---|---|-------|---------|
|DC Disconnect Confirm | | x | x | x | x | 13.6 |1100 0000|
|-----------------------|---|---|---|---|---|-------|---------|
|DT Data | x | x | x | x | x | 13.7 |1111 0000|
|-----------------------|---|---|---|---|---|-------|---------|
|ED Expedited Data | | x | NF| x | x | 13.8 |0001 0000|
|-----------------------|---|---|---|---|---|-------|---------|
|AK Data Acknowledgement| |NRC| NF| x | x | 13.9 |0110 zzzz|
|-----------------------|---|---|---|---|---|-------|---------|
|EA Expedited Data | | x | NF| x | x | 13.10 |0010 0000|
|Acknowledgement | | | | | | | |
|-----------------------|---|---|---|---|---|-------|---------|
|RJ Reject | | x | | x | | 13.11 |0101 zzzz|
|-----------------------|---|---|---|---|---|-------|---------|
|ER TPDU Error | x | x | x | x | x | 13.12 |0111 0000|
|-----------------------|---|---|---|---|---|-------|---------|
| | | | | | | - |0000 0000|
| |---|---|---|---|---|-------|---------|
|not available | | | | | | - |0011 0000|
| (see note) |---|---|---|---|---|-------|---------|
| | | | | | | - |1001 xxxx|
| |---|---|---|---|---|-------|---------|
| | | | | | | - |1010 xxxx|
+-------------------------------------------------------------+Table 8. TPDU code 🎀
13.2. Structure 🧱
All the transport protocol data units (TPDUs) SHALL contain an integral number of octets 🔢. The octets in a TPDU are numbered starting from 1 and go up in the order they're 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 a TPDU's encoding is shown with a diagram in this clause, this is the layout: octets are drawn with the lowest numbered octet on the left, and higher numbered octets are further to the right. Within an octet, bits are drawn with bit 8 on the left and bit 1 on the right.
TPDUs SHALL contain, in this order:
- a) the header, which is made of:
- 1) the length indicator (LI) field;
- 2) the fixed part;
- 3) the variable part, if present;
- b) the data field, if present.
Here's the picture 📸:
octet 1 2 3 4 ... n n+1 ... p p+1 ...end
+---+-------------+--------------+-----------+
| LI| fixed part | variable part| data field|
+---+-------------+--------------+-----------+
<--------------- header ------>13.2.1. Length indicator field 📏
This field is in the first octet of the TPDUs 🥇. The length is 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 any user data. The value 255 (1111 1111) is reserved for possible extensions 🚧. If the length indicated is bigger than the NS-user data that's actually present, that's a protocol error 🚨.
13.2.2. Fixed part 🧩
13.2.2.1. General 🌷
The fixed part holds the frequently used parameters, including the TPDU code 💕. The length and structure of the fixed part are defined by the TPDU code and, in some cases, by the protocol class and the formats in use (normal or extended). If any of the fixed part's parameters have an invalid value, or if the fixed part can't fit inside the header (as defined by LI), that's a protocol error 🙅♀️.
NOTE 🤓 In general, the TPDU code defines the fixed part unambiguously. However, different variants can exist for the same TPDU code (see normal and extended formats).
13.2.2.2. TPDU code 🔑
This field holds the TPDU code and sits in octet 2 of the header 📍. It's used to define the structure of the rest of the header. This field is a full octet, except in these cases:
1110 xxxx Connection Request
1101 xxxx Connection Confirm
0101 xxxx Reject
0110 xxxx Data Acknowledgementwhere xxxx (bits 4-1) is used to signal the CDT.
Only the codes defined in 13.1 are valid 💯.
13.2.3. Variable part 🎀
The variable part is used for less frequently used parameters 🗂️. If the variable part is present, it SHALL contain one or more parameters.
NOTE 🧮 The number of parameters that can be 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 in the variable part is structured like this:
Bits 8 7 6 5 4 3 2 1
Octets +------------------------------------+
n+1 | Parameter Code |
|------------------------------------|
n+2 | Parameter Length |
| Indication (e.g. m) |
|------------------------------------|
n+3 | |
| Parameter Value |
n+2+m | |
+------------------------------------|- The parameter code field is coded in binary;
NOTE - bestie, without extensions you only get 255 different parameters 🎀 but bits 8 and 7 can't take every possible value, so the practical max is even lower. Parameter code 1111 1111 is reserved for possible extensions of the parameter code 🧚
- The parameter length indication tells you how many octets are in the parameter value field 📏
NOTE - The length is a binary number, m, with a theoretical max of 255. The practical max of m is lower. For example, if there's a single parameter in the variable part, two octets are needed for the parameter code and the length indication itself, so m is capped at 248. For bigger fixed parts and each parameter after the first, the max of m keeps going down 📉
- The parameter value field holds the value of the parameter named in the parameter code field 💜
- No parameter codes use bits 8 and 7 with the value
00. - The parameters in the variable part MAY be in any order. If a parameter is duplicated, then the later value SHALL be used. A parameter that isn't defined in this International Standard SHALL be treated as a protocol error in any received TPDU except a CR TPDU, and in a CR TPDU it SHALL be ignored. If the responding transport entity picks a class that doesn't define a parameter from the CR TPDU, it MAY ignore that parameter, except for the class and option and alternative protocol class parameters, which SHALL always be interpreted. A parameter defined in this International Standard but with 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's the class and option parameter, the alternative class parameter, or the additional option parameter. Otherwise it SHALL be either ignored or treated as a protocol error 🙈
13.2.3.1 Checksum Parameter (Class 4 only) 💖
Every TPDU type MAY contain a 16-bit checksum parameter in its variable part. This parameter SHALL be present in a CR TPDU, and it SHALL be present in every other TPDU unless 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 carries 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 |
+--+------+---------+---------+---+---+------+-------+---------+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
0000in Classes0and1when 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 OPTION: Bits 8-5 of octet 7 define the preferred 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 4The CR TPDU carries the first choice of class in the fixed part. Second and later choices are listed in the variable part if needed.
Bits 4-1 of octet 7 define the options to be used on the requested transport connection, as follows 👑
+-----|-----------------------------------------------+
| BIT | OPTION |
|-----|-----------------------------------------------|
| 4 | 0 always |
| | |
| 3 | 0 always |
| | |
| 2 | =0 use of normal formats in all classes |
| | =1 use of extended formats in Classes 2,3,4 |
| | |
| 1 | =0 use of explicit flow control in Class 2 |
| | =1 no use of explicit flow control in |
| | Class 2 |
+-----------------------------------------------------+NOTES
- The connection establishment procedure (see 6.5) does not permit a given CR TPDU to request use of the transport expedited data transfer service (additional option parameter) and no use of explicit flow control in Class 2 (bit 1 = 1).
- Bits 4 to 1 are always zero in Class 0 and have no meaning 🙈
13.3.4 Variable Part (Octets 8 to p)
These 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.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 octetsDefault 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 0001Default 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)
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 they MAY take any value 💀
- g) Alternative protocol class(es) (not used if Class 0 is the preferred class)
Parameter code: 1100 0111
Parameter length: nThe parameter value is 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 it 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:okay so the throughput thing isn't finished yet bestie 🎀 here's the rest of its layout, with the average throughput part in its own little box:
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
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
directionif you leave out the average throughput, it just copies the maximum throughput value 🦋 and everything here is measured in octets per second ✨
- k) Residual error rate (only bother if class 0 isn't 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 (again, not needed 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 (skip this one if class 0 is the preferred class 🍓)
Parameter code: 1000 0111
Parameter length: 2
Parameter value: Integer (0 is the highest priority)- 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
directionthe values here are in milliseconds, and they're based on a TSDU size of 128 octets 🌸
- p) Assignment time (not used if class 0, 2 or class 4 is the preferred class 🧚)
this one carries the Time to Try Reassignment (TTR) 💖 which gets used when you follow the procedure for Reassignment after Failure (see 6.12). it's giving retry planning 👑
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 they're optional in the other classes. where they are permitted, they may not go over 32 octets 🌈
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
0000in Classes 0 and 1). Bits 4-1 of octet 2; - c) DST-REF: the reference identifying the requested transport connection at the remote transport entity 🌸
- d) SRC-REF: the 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, following the negotiation rules specified in 6.5 🔥
13.4.4. Variable Part (Octet 8 to p) 🧚
the parameters are defined in 13.3.4 and they're subject to the constraints stated in 6.5 (connection establishment). parameters ruled out by picking an alternative class and option shall not be present, no exceptions 🙈
13.4.5. User Data (Octets p+1 to the end) 🫶
no user data are permitted in class 0, and they're optional in the other classes. where they're permitted, they may not exceed 32 octets. the user data also follow 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
13.5.3. Fixed Part (Octets 2 to 7 🦋
the fixed part shall contain:
- a) DR: Disconnect Request Code:
1000 0000; - b) DST-REF: the reference identifying the transport connection at the remote transport entity 🌸
- c) SRC-REF: the reference identifying the transport connection at the transport entity initiating the TPDU. Value zero when the 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 invalidthe 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 unknownNOTE - 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 clearing 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 it's 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 🙅♀️
13.6. Disconnect Confirm (DC) TPDU 👑
this TPDU shall not be used in Class 0. 💀
13.6.1. Structure 🌸
the structure of the 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.
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 | |
+----+---------+---+---+---------+--------+---------- - - -+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: Set this to ONE and it's basically saying "this is the last piece of the whole TSDU" 🎀 (End of TSDU). It lives in bit 8 of octet 3 for classes 0 and 1, bit 8 of octet 5 for normal formats in classes 2, 3 and 4, and bit 8 of octet 8 for extended formats; ✨
d) TPDU-NR: This is the TPDU send Sequence Number 🧚 (it's zero in Class 0). It 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, and 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 these 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 —
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 —
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 —
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- 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.
- Your Sub-Sequence (16 bits): Contains the value of the sub-sequence parameter of the received AK TPDU, or zero if this parameter was not present.
- 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. It 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;
d) YR-TU-NR 🎀: this is the sequence number that tells the other side which TPDU to retransmit from, aka the "resend from here" pointer 💅
For normal formats, it lives in bits 7-1 of octet 5. Bit 8 of octet 5 is not significant and SHALL take the value 0 🌸
For extended formats, it's 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 🧚
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 0000Reason not specified0000 0001Invalid parameter code0000 0010Invalid TPDU type0000 0011Invalid 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.
- Parameter code:
- b) Checksum: This parameter SHALL be present if the condition in 13.2.3.1 applies. 🙈
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 🍓
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. 128 is the baseline, bestie 🌸
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;
- 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.
| 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 📋
| 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 🌟
ANNEX A - STATE TABLES 🧩
This annex is an integral part of the body of this International Standard. It's basically part of the main spec, not an add-on 💅
It gives a more precise description of the protocol. If the tables and the text ever disagree, the text wins, so don't you forget it 🫶
The state tables 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. They 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.]
ANNEX B - CHECKSUM ALGORITHMS 🔥
This annex is provided for information for implementors and is not an integral part of the body of the standard. Think of it as the helpful study guide, not the rulebook 📚
B.1 SYMBOLS
The following symbols are used:
C0,C1: variables used in the algorithmsi: 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 parameterL: length of the complete TPDUX: value of the first octet of the checksum parameterY: 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
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
C0toC1.
B.3.4
Calculate X and Y such that:
X = -C1 + (L-n).CO
Y = C1 - (L-n+1).C0B.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
C0toC1.
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. Math that checks itself, iconic 🧚
Explanatory Report ✨
okay so this is the backstory bit, and it's giving history class but make it lowkey dramatic 🎀 The Transport Layer Services and Protocols have been under study within TC97/SC16 since 1979. 💅 In Berlin, November 1980, SC16 agreed that the Service and Protocol documents would be progressed concurrently. 🫶
Then at the SC16 meeting in Tokyo, June 1982, they gave the green light (Resolutions 10 and 11, SC16 N 1233) to register both the Transport Service Definition and the Transport Protocol Specification as Draft Proposals and circulate them for a 90-day ballot. 🦋
After the letter ballot closed, an Editing Group got together to fold in the editorial comments and make recommendations about the proposed technical changes. 🌸 The revised texts and those recommendations were reviewed by SC16/WG6 at its meeting in Vienna, March 1983. 🔥 The revised Transport Service Definition (SC16 N 1435) was accepted as presented, but the revised Transport Protocol (SC16 N 1433) had to go through an extra 60-day ballot. 😭 Because both DPs were being progressed in parallel, the Transport Service Definition was put on hold (held in abeyance) until SC16 accepted the revised Transport Protocol, which became Second DP 8073. 🧚
A second Editing Group was convened in Paris, July 1983, to review the comments submitted on Second DP 8073. 💜 The Minutes and Report of that meeting are documented in SC16 N1575 and N 1574 respectively. 🍓 There were two negative votes, DIN and NNI, and both got full consideration. ✨ The NNI concerns were fully covered in the revised text the Editing Group prepared, and the DIN concerns were taken into account and incorporated in their large majority. 👑
So, 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. 🌈💖 Main character era, honestly. 🙈
📦 where this page comes from
- ietf: rfc905 1984-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms