RFC 892
ISO Transport Protocol specification
RFC 892: ISO Transport Protocol Specification 🎀
Okay bestie, this is RFC 892, the ISO Transport Protocol Specification ✨ It's from the Network Working Group and the author is listed as ISO 💅 The date is December 1983 🍓 Category: it's informational 🧚 It's distributed as an RFC for information only, and it does not specify a standard for the ARPA Internet 🙈 The original doesn't list anything it obsoletes or updates, so there's nothing to report there.
Note: This document appeared in: ISO/TC97/SC16/WG6. Information Processing Systems - Open Systems Interconnection - Transport Protocol Specification. Computer Communication Review 12, 3-4 (July/October 1982), pp. 24-67, and differs from it only in format.
Table of Contents 📖
0. Introduction
1. Scope and Field of Application
2. References
Section One - General
3. Definitions
4. Symbols and Abbreviations
5. Overview
5.1 Service provided by the transport layer
5.2 Service assumed from the network layer
5.3 Functions of the transport layer
5.4 Model of the transport layer
Section Two - Transport Protocol Specification
6. Protocol Mechanisms
6.1 Assignment to network connection
6.2 Transport protocol data unit (TPDU) transfer
6.3 Data TPDU length and segmenting
6.4 Concatenation and separation
6.5 Connection establishment
6.6 Connection refusal
6.7 Release
6.8 Implicit termination
6.9 Spurious disconnect
6.10 Data TPDU numbering
6.11 Expedited data transfer
6.12 Reassignment
6.13 Reassignment after failure
6.14 Retention until acknowledgement of TPDUs
6.15 Resynchronization
6.16 Multiplexing and demultiplexing
6.17 Explicit flow control
6.18 Checksum
6.19 Frozen references
6.20 Retransmission on timeout
6.21 Resequencing
6.22 Inactivity control
6.23 Treatment of protocol errors
6.24 Splitting and recombining
7. Protocol Classes
7.0 Protocol description of class 0: simple class
7.1 Protocol description of class 1: basic error recovery class
7.2 Protocol description of class 2: multiplexing class
7.3 Protocol description of class 3: error recovery and multiplexing
class
7.4 Protocol description of class 4: error detection and recovery class
8. Encoding
8.1 Summary
8.2 Structure
8.3 Connection Request (CR)
8.4 Connection Confirm (CC)
8.5 Disconnect Request (DR)
8.6 Disconnect Confirm (DC)
8.7 Data (DT
8.8 Expedited Data (ED)
8.9 Data Acknowledgement (AK)
8.10 Expedited Data Acknowledgement (EA)
8.11 Reject (RJ)
8.12 TPDU Error (ERR)
Section Three - Conformance
9. Conformance0. Introduction 🌸
Okay so the Transport Protocol Standard is one of a set of International Standards made to help computer systems interconnect with each other 💖 The set covers the services and protocols needed to make that happen ✨
It sits in the layers defined by the Reference Model for Open Systems Interconnection (ISO 7498) 🧚 It's most closely related to, and lives within the field of application of, the Transport Service Standard (DP aaaa). It also uses and references the Network Service Standard (DP bbbb), and it assumes that standard's provisions so it can reach its aims 🫶 Figure 1 shows how all these standards fit together:
-----------------------------------TRANSPORT SERVICE DEFINITION-----
Transport --Reference to aims---------------
Protocol
Specification --Reference to assumptions--------
------------------------------------NETWORK SERVICE DEFINITION------Figure 1 - Relationship between the transport protocol and adjacent services
The standard gives you one common encoding plus a number of classes of transport protocol procedures, for use with different network qualities of service 🦋
The Transport Protocol is meant to be simple but general enough to handle the whole range of Network Service qualities that are possible, without blocking future extensions 🌈
The protocol is structured into classes, designed to keep possible incompatibilities and implementation costs low 💜
You can select the classes with respect to the Transport and Network Services, to deliver the required quality of service for interconnecting two session entities. Each class provides a different set of functions for enhancing service qualities, so it's a whole vibe 👑
This protocol standard is concerned with optimisation of network tariffs and these qualities of service:
- a) different throughput rates;
- b) different error rates;
- c) integrity of data requirements;
- d) reliability requirements.
The aim of this standard is mainly to give implementors a definition. The protocol is complex, so the document has a lot of material that is advisory or descriptive, but mandatory requirements on implementations are clearly identified 🙈
Here's the tea: with so many valid protocol sequences, it isn't possible with current technology to verify that an implementation will run the protocol correctly under all circumstances 😭 Testing can build confidence that an implementation correctly runs the protocol in a representative sample of circumstances. This standard can still be used when two implementations fail to communicate, to figure out whether one or both failed to operate the protocol correctly 🔍
The variations and options in this standard are essential, so a Transport Service can be provided for a wide variety of applications over a variety of network qualities. That means a minimally conforming implementation won't be suitable in every possible circumstance 💅
Important: it's important to qualify all references to this standard with statements of the options provided or required, or with statements of the intended purpose of provision or use. Don't skip this, bestie 🫶
1. Scope and Field of Application ✨
1.1 This International Standard Specifies:
- a) five classes of procedures:
- Class 0. Simple class;
- Class 1. Basic error recovery class;
- Class 2. Multiplexing class;
- Class 3. Error recovery class;
- Class 4. Error detection and recovery class,
for the 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 encoding of the transport protocol data units used for the transfer of data and control information;
- d) the functional requirements of equipment within a computer system claiming to implement these procedures.
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.
1.3 This International Standard is applicable to equipment which supports the Transport Layer of the OSI Reference Model and which wishes to interconnect in an open systems environment 🦋
2. References 📚
ISO 7498 Information processing systems - Open systems inter-
connection - Basic Reference Model
DP aaaa Information processing systems - Open systems inter-
connection - Transport service definition (N1169).
DP bbbb Information processing systems - Open systems inter-
connection - Connection-oriented network service
definition (N729)Section One - General 🎀
3. Definitions 💅
3.1 Equipment
Equipment: hardware or software or a combination of both. It doesn't need to be physically distinct within a computer system ✨
3.2 Transport service user
An abstract representation of the totality of those entities within a single system that make use of the transport service 🌸
3.3 Network service provider
An abstract machine which models the totality of the entities providing the network service, as viewed by a transport entity 🧚
Explanatory Notes
- Definitions 3.1 to 3.3 relate to terms used in clause 1.
- This standard makes use of the terms, concepts, and definition defined in ISO 7498.
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 Rejected TPDU
ERR 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)
SCE-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)4.4 Parameters
T (R) Receive sequence number
T (S) Send sequence number4.5 Timer variables
T1 Elapse time between retransmissions
N The maximum number of retransmissions
L Bound for the maximum time between the
decision to transmit a TPDU and the receipt of
any response relating to it
T-WAIT Maximum time for a reassignment to take place
before TC failure is assumed
I Inactivity timer - Maximum time allowed to
elapse between receipt of TPDUs before TC
failure is assumed
W Window timer - Maximum interval between trans-
mission of up to date window information4.6 Other variables
n The number of bits in the sequence number
field
p The number of bits in the credit field of a
CR, CC or AK TPDU4.7 Miscellaneous
TS-user Transport service user
TSAP Transport service access point
NSAP Network service access point
TC Transport connection
NC Network Connection5. Overview of the Transport Protocol 🦋
5.1 Service Provided by the Transport Layer
Okay so the services this protocol gives you are connection-oriented services 🔥 They're defined in document DP aaaa. The Transport Service primitives provided are
Here's the full lineup, summarized in Figure 1 ✨
Primitive Parameters
------------------------------------------------------------------------
T-CONNECT Request To Transport Address, From
Indication Transport Address, Expedited
Data Option, Quality of
Service, TS-User data.
------------------------------------------------------------------------
T-CONNECT Response Responding Address, Quality
Confirmation of Service, Expedited Data
Option, TS-User data.
------------------------------------------------------------------------
T-DATA Request TS-User data.
Indication
------------------------------------------------------------------------
T-EXPEDITED Request TS-User data.
DATA Indication
------------------------------------------------------------------------
T-DISCONNECT Request TS-User data.
------------------------------------------------------------------------
T-DISCONNECT Indication Disconnect reason, TS-User
data.
------------------------------------------------------------------------
Figure 1. Transport Service Primitives5.2. Service Assumed from the Network Layer 🦋
Okay so the transport protocol in this doc assumes stuff from the Network Services described in DP bbbb 🌸. The Network Service primitives it uses are summarized in Figure 2, and it's giving a lot of "who's providing what" energy 💅.
Primitive X/Y Parameters X/Y/Z
------------------------------------------------------------------------
N-CONNECT Request X Called Address, X
Indication X Calling Address, X
Response X NS-User data, Z
Confirmation X QOS. X
------------------------------------------------------------------------
N-DATA Request X NS-User data, X
Indication X Conf. Request Y
------------------------------------------------------------------------
N-DATA Request Y
ACKNOWLEDGE Indication
------------------------------------------------------------------------
N-EXPEDITED Request Y
DATA Indication NS-User data Y
------------------------------------------------------------------------
N-RESET Request X
Indication X
Response X
Confirmation X
------------------------------------------------------------------------
N-DISCONNECT Request X NS-User data Z
Indication X
------------------------------------------------------------------------
X - The Transport Protocol assumes that this facility is
provided in all networks.
Y - The Transport Protocol assumes that this facility is
provided in some networks and a mechanism is provided
to optionally use the facility.
Z - The Transport Protocol does not use this parameter.
Figure 2. Network Service PrimitivesQuick decoder ring for those letters 🔑:
Xmeans the transport protocol assumes this facility is provided in all networks 👑.Ymeans it assumes the facility is provided in some networks, and there's a mechanism to optionally use it 🎀.Zmeans the transport protocol doesn't use that parameter 🙈.
5.3. Functions of the Transport Layer 🧚
5.3.1. Connection Oriented Functions 💜
5.3.1.1. Overview of Functions 🌈
The functions in the transport layer are at least the ones needed to bridge the gap between what the network layer offers and what gets offered to the transport users. That's the bare minimum, bestie 🫶.
The functions in the transport layer are also about boosting quality of service, including every aspect of cost optimization ✨. They're described below, grouped into the establishment phase, the data transfer phase, and the release phase.
5.3.1.1.1. Establishment Phase 🍓
The goal of the establishment phase is to set up a transport connection, i.e., between two transport users. During this phase, the transport layer's functions must match the requested class of services with the services the network layer provides, like this:
- Select the network service that best matches the TS-user's requirements, taking charges for various services into account 💰.
- Decide whether to multiplex multiple transport connections onto a single network connection 🔀.
- Establish the optimum TPDU size 📏.
- Select the functions that will be operational when entering the data transfer phase 🎬.
- Map transport addresses onto network addresses 🗺️.
- Provide a means to distinguish between two different transport connections 🆔.
- Transportation of user's data 📦.
5.3.1.1.2. Data Transfer Phase 💌
The purpose of the data transfer phase is to let two-way simultaneous transport of TSDUs happen between the session entities connected by the transport connection 🔁. This purpose is achieved through two-way simultaneous communication in the Transport protocol, plus the functions below. Each one gets used or not used depending on what got selected in the establishment phase, so it's all very intentional 💅.
- Concatenation and Separation A function used to collect several TPDUs into a single NSDU; the destination transport entity separates the TPDUs 🧃.
- Segmenting and Reassembling The splitting of a single data TSDU into multiple TPDUs, which are reassembled into their original format at the destination 🧩.
- Multiplexing and Demultiplexing A function used to share a single network connection between two or more transport connections 🚦.
- Splitting and Recombing A function allowing the simultaneous use of two or more network connections to support the same transport connection 🌊.
- Flow Control A function used to regulate the flow of TPDUs between two transport entities on one transport connection 🚰.
- Error Detection A function used to detect the loss, corruption, duplication, misordering or misdelivery of TPDUs 🕵️♀️.
- Transport Connection Identification A means to uniquely identify a transport connection between the pair of transport entities supporting the connection during the lifetime of the transport connection 🪪.
- Error Recovery A function used to recover from detected and signalled errors 🩹.
- Expedited Data A function used to bypass the flow control of normal data TPDUs. Expedited data TPDUs' flow is controlled by separate flow control 🚑.
- TSDU Delimiting A function used to determine the beginning and ending of a TSDU ✂️.
5.3.1.1.3. Release Phase 🎈
A function to provide a disconnection of the transport connection, regardless of the current activity. Bye bye, transport connection 👋.
5.3.1.2. Classes and Options 🎀
A class defines a set of functions. In this protocol, five classes are defined:
- Class 0: Simple Class
- Class 1: Basic Error Recovery Class
- Class 2: Multiplexing Class
- Class 3: Error Recovery and Multiplexing Class
- Class 4: Error Detection and Recovery Class.
Note that, with the exception of classes 0 and 1, transport connections of different class may be multiplexed together onto the same network connection 💫.
5.3.1.2.2. Options within Classes 🌷
Options define potential functions which may be used within a class 🪄.
5.3.1.2.3. Negotiation 🤝
Classes and options within classes are negotiated during the connection establishment phase 🗣️.
5.3.1.2.4. Choice of the Class of Protocol 👑
The choice will be made by the transport entities according to:
- The user's requirements, expressed via T-CONNECT service primitives. In particular, for the choice of the class of protocol, the following rules apply:
- If the TS-User requests either transmission of user data during the connection phase, or use of Expedited data transfer, then Class 0 cannot be selected.
- If the TS-User requests use of Expedited data transfer, then Class 2 with the non-explicit flow control option cannot be selected.
- The quality of the available Network services.
- The user-required service versus cost ratio acceptable for the transport user 💸.
Here's the classification of network services in terms of quality, with respect to error behavior relative to the user requirements. Its main purpose is to give a basis for deciding which class of transport connection should be used on top of a given network connection 🧐.
- Type A: Network connection with acceptable residual error rate (for example, not signalled by
'clear'or'reset') and acceptable rate of signalled failures ✅. - Type B: Network connections with acceptable residual error rate (for example, not signalled by
'clear'or'reset') but unacceptable rate of signalled failures 😬. - Type C: Network connections with residual error rate not acceptable to the TS-user 💀.
It is assumed that each transport entity is aware of the quality of service provided by particular network connections 👀.
5.3.1.3. Potential Functions 🌙
The protocol described in this document does not include the following set of functions, which have been identified as potential transport layer functions 🔮:
- provision for encryption
- provision for accounting mechanisms
- provision for status exchanges and monitoring of quality of service
- provision for blocking
- temporary release of network connections
5.4. Model of the Transport Layer 🏗️
TSAP TSAP
Transport Protocol Transport Protocol
Entity Entity
NSAP ------- NSAP -------
| (NSAP) | (NSAP)
| | | |
| |-------------------------|--------
| |
-----------------------------------A Transport Protocol entity within the Transport Layer communicates with a Transport User through a TSAP, using the service primitives defined in the transport service definition DP aaaa 💬. Service primitives will cause, or be the result of, Transport Protocol Data Unit exchanges between the peer Transport Protocol entities supporting a Transport Connection. These protocol exchanges are carried out using the services of the Network Layer, as defined by the Network Service Definition DP bbbb, through one or more NSAPs 🛰️.
Transport connection endpoints are identified in end systems by an internal, implementation-dependent mechanism, so the Transport User and the Transport Protocol entity can both refer to each transport connection 🪞.
Section Two - Transport Protocol Specification 🎬
6. Protocol Mechanisms ✨
Several functions are described as 'inherent' or 'pervasive'. Inherent functions must be invoked for every transport connection. Pervasive functions are optional, but if one is invoked for the first
transport connection over a network connection, it MUST also be invoked for any and all other transport connections which use that network connection during its lifetime. 🦋
6.1. Assignment to Network Connection ✨
Purpose: Assigning transport connections to network connections 🎀
Network Service Primitives: N-CONNECT, N-DISCONNECT
Description: This function is inherent 🌸
Okay, so before a transport connection can be created or used, it MUST be assigned to one (or more if the splitting function is being used) network connection(s). Both transport entities involved MUST become aware of this assignment. ngl this part is so important. A transport connection MAY be assigned to a suitable existing network connection, and one or more new network connections MAY also be created for the purpose. 💅
An existing network connection, which connects the relevant transport entities, is unsuitable for assignment of a transport connection if, for example:
- the quality of service needed for the transport connection can not be met by using or enhancing the network connection. 😭
- the protocol class preferred or in use for the transport connection is incompatible with the current usage of the network connection as regards the use of pervasive functions (e.g., multiplexing). 🙈
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, so it's giving planning ahead 🧚
A Network Connection with no transport connections will be available after initial establishment, or because explicit disconnection of all the transport connections previously assigned to it has taken place. Either Transport entity MAY as a local matter choose to disconnect the Network Connection or assign other Transport Connections to it. Main character energy, the choice is theirs 👑
6.2. Transport Protocol Data Unit (TPDU) Transfer 💜
Purpose: To convey transport protocol data units in the user data fields of network service primitives 📦
Network Service Primitives: N-DATA, N-EXPEDITED DATA
Description: This function is inherent 🌈
The Transport Protocol Data Units (TPDUs) defined for the protocol are listed in Figure 3. Here's the full squad 👯♀️
TPDU name Abbreviation
Connection Request CR
Connection Confirm CC
Disconnect Request DR
Disconnect Confirm DC
Data DT
Expedited Data ED
Data Acknowledge AK
Expedited Acknowledge EA
Reject RJ
TPDU Error ERR
Figure 3. Transport Protocol Data UnitsTPDUs are conveyed using the NS-User data parameters of the Network Service primitives, mostly with N-DATA, but also with N-EXPEDITED primitives. ✨
Transport entities SHALL accept all permissible assignments and MAY issue any permissible assignments. The permissible assignments of TPDUs to these primitives are shown in Figure 4. Concatenation of TPDUs is also permitted (see section 6.4) 🎀
Primitive Applicable TPDUs Note
N-DATA CR, CC, DR, DT, ED,
AK, EA, RJ, DC, ERR
N-EXPEDITED ED, EA 1
Notes:
1. This assignment is permissible only when using class 1 and when
the network expedited variant has been agreed.
Figure 4. Network Service Primitives which can convey TPDUs.6.3. Data TPDU Length and Segmenting 🍓
Purpose: Mapping between one TSDU and TPDUs 🧩
TPDUs and fields used:
DTEnd of TSDU (1 bit)
Description: The data field of Data TPDUs MAY contain any number of octets, up to an agreed maximum that gets negotiated at connection time. 💖
A transport entity uses an End of TSDU mark as defined below:
In each Data TPDU, a transport entity MAY indicate the end of a TSDU. 🦋
- Category 1: Having the End of TSDU mark set to yes. These TPDUs MAY or may not have the maximum length. 🌸
- Category 2: Having the End of TSDU mark set to no. These TPDUs do not necessarily have the maximum length. 🌷
A complete Data TPDU sequence is defined as being composed of either a single category 1 DT TPDU, or consecutive category 2 followed by a category 1 DT TPDU. It's a whole vibe 🎶
6.4. Concatenation and Separation 🧃
Purpose: Conveyance of multiple TPDUs in one NSDU 📬
Description: All TPDUs carry a length indicator in their TPDU header (see Section 8.2.1). On top of that, TPDUs are classified as either Data TPDUs or Control TPDUs. Control TPDUs MAY or may not contain a data field. For TPDUs containing data, the length of the data field is indicated by the length of the NSDU. These provisions permit any number of Control TPDUs that MAY not contain data to be concatenated with a single control TPDU which MAY contain data, or with a single Data TPDU. The control TPDUs without data MUST precede the TPDU with data, if any. The number of TPDUs so concatenated is terminated by the end of the NSDU. Bestie, that's a lot of packing, but it's organized 📦✨
The concatenated set of TPDUs MAY be for the same or different transport connections. An implementation SHALL accept concatenated TPDUs and MAY concatenate TPDUs before transmission. The transport entity SHALL NOT send a concatenated set of TPDUs which exceeds twice the overall maximum TPDU length for all the TCs assigned to the network connection. Never go over that limit, periodt 🚫💀
6.5. Connection Establishment 🤝
Purpose: Creation of a new transport connection 🌟
Network Service Primitives: N-DATA
TPDUs and fields used:
CR, CC
- source reference (16 bits)
- initial credit (if applicable)
- calling transport address (optional)
- called transport address (optional)
- user data (optional)
- TPDU size (optional)
- sequence number length (optional)
- checksum selection (optional)
- acknowledgement time (optional)
- quality of service (optional)
CR
- preferred protocol class
- alternative protocol classes (zero or more)
- version number (optional)
- security (optional)
- proposed options
CC
- destination reference (16 bits)
- selected protocol class
- selected optionsDescription: This function is inherent:
A transport connection is established when one transport entity (the initiator) transmits a Connection Request (CR) TPDU to the other transport entity (the responder), which replies with a Connection Confirm (CC) TPDU. Before sending the CR TPDU, the initiator assigns the transport connection being created to one (or more if the splitting function is being used) network connection(s). This set of network connections is the one the TPDUs get sent over. During this exchange, all information and parameters needed for the transport entities to operate MUST be exchanged or negotiated. It's a whole group project 🫶
The following information is exchanged:
- references. Each transport entity chooses a reference which is 16 bits long and which is arbitrary, except for the following restrictions:
- it cannot already be in use or "frozen" (see "Frozen References", Section 6.19).
- it cannot be zero.
Each transport entity is responsible for selecting the Reference which the partner will use. This mechanism is symmetrical, so it avoids the need to assign a status of master or slave to partners and avoids call collision. It's giving fairness 👑 This mechanism also provides identification of the transport connection independent of the network connection. The range of References used for transport connections, in a given transport entity, is a local system parameter.
- addresses (optional). Indicate the calling and called transport service access points. When either network address unambiguously defines the transport address, this information MAY be omitted. 🗺️
- initial credit. Only relevant for classes which include the Explicit Flow Control Function. 🚰
- user data. Not available in class 0. Up to 32 octets in other classes. 💌
The following negotiations take place:
- protocol class. The initiator SHALL propose a preferred class and any number of alternatives. (Except that no alternatives are allowed when class 0 is the preference.) The initiator SHOULD assume, when it sends the CR TPDU, that its preferred class will be agreed to, and commence the functions associated with that class. Confidence arc 😤🔥
Note: This means, for example, that when a class which includes resynchronization (see "Resynchronization", Section 6.15) is preferred, resynchronization will occur if a reset is signalled during connection establishment. 🔄
When the responder has decided which class is to be used, it SHALL indicate this in the CC TPDU and SHALL invoke the appropriate functions for the class. The responder MAY select the preferred class, or any of the alternative classes, or MAY select class 0 if class 1 is proposed, or class 2 if class 3 or 4 is proposed. (see Section 9) 🧠
If the preferred class is not selected, then on receipt of the CC TPDU, the initiator SHALL adjust its functions accordingly. Flexible queen 💅
- TPDU Size. The initiator MAY propose a maximum size for TPDUs, and the responder MAY accept this value or respond with any value between the proposed value and 128 in the set of values available (see "Encoding", Section 8). 📏
- sequence number length. Either normal or extended is available. When the sequence number is extended, the credit field (if applicable) is also extended. 🔢
- checksum selection. This defines whether or not TPDUs of the connection are to include a checksum. ✅
- version number. This defines the version of the transport protocol standard used for this connection. 🏷️
- security parameter. This parameter and its semantics are user defined. 🔐
- quality of service parameter. This defines the throughput, delay, priority and residual error rate. 🚀
- The non-use of explicit flow control in class 2 is negotiated. 🙅♀️
- The use of Network Receipt Confirmation and Network expedited is negotiated when class 1 is to be used. 🧾
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 the mandatory alternative defined in Section 9. Lowkey a lot of options, but everyone gets a say 🌈
During the establishment phase of the transport connection, the use of the expedited data option field of CR/CC allows both Transport Service users to negotiate the use or non-use of the expedited data transport service, as described in the transport service definitions. ⚡
The following table summarizes the negotiation possibilities
Proposition Made Possible
by the Initiator Selection by
Option the Responder
Transport expedited data Yes Yes or No
transfer service No No
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 (class 2 only) No No
Use of extended format Yes Yes or No
No Nook so this table is literally the cheat sheet for who can ask for what and who gets the final say 📋💅 the initiator proposes Yes or No for each option, and the responder can answer Yes or No to the Yes proposals. a No proposal just stays No, no cap 🫶
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 must also request or agree (respectively) to the use of explicit flow control. bestie that's a package deal 🎀✨
6.6. Connection Refusal
Purpose: Refusal of the transport connection. 🙅♀️
TPDUs and fields used:
DR
- reason (1 octet)
- user data (maximum of 64 octets)
ERR
- reject code (1 octet)
- rejected TPDU parameterDescription:
okay so if a transport connection can't be accepted, the called transport entity has to answer the CR TPDU with a DR TPDU 💀 the clearing reason is what tells the other side why it got rejected. the source reference field in the DR TPDU is set to zero, which means "this reference isn't assigned" 🧚
if the CR is considered an invalid TPDU, the called transport entity will respond by sending an ERR TPDU instead. when the calling entity gets that ERR TPDU, it treats the connection as closed. literally a clean "nope" 🌸
6.7. Release
Variants: 'implicit' or 'explicit'
Purpose: Termination of the transport connection. 👋
Network Service Primitives:
N-DISCONNECT (implicit variant only)
N-DATATPDUs and fields used:
DR
- clearing reason (1 octet)
- user data (maximum of 64 octets)
DCDescription:
this function is inherent, it's just part of who the transport entity is 💖
in the 'implicit' variant, either transport entity disconnects a transport connection by disconnecting the network connection it's assigned to. and if a transport entity hears that the network connection got disconnected by its peer, that should count as a transport disconnect. ghosted but make it official 😭
in the 'explicit' variant, either transport entity sends a Disconnect Request (DR) TPDU, and the other one replies with a Disconnect Confirm (DC) TPDU. once a transport entity sends or receives the DC TPDU, it should consider the transport connection not to exist (note 1). after sending a DR TPDU, any other TPDUs received before the DC TPDU get ignored 🙈 sometimes both sides send a DR at the same time, which is a disconnect collision. then each one gets a DR after sending its own, and each one counts the received DR as the confirmation of its DR. so neither side sends or expects a DC in that case. iconic teamwork ✨
the DR can carry a little bit of data, up to 64 octets 🎁
6.8. Implicit Termination
Purpose: Termination of a Transport Connection on the occurrence of a signalled error for which recovery functions are not operative. 🚨
Network Service Primitives:
N-DISCONNECT Indication
N-RESET IndicationDescription:
when an N-DISCONNECT or N-RESET Indication happens on the network connection that a Transport Connection is assigned to, both transport entities should consider that the transport connection no longer exists, and then tell their session entities. the drama is over and everyone knows 💅
Note 1:
when a connection has been released after the DR and DC exchange, the reference can be re-used immediately (except in Class 4, where the Frozen Reference function is used, see Section 6.19). that's because the releasing transport entity can't be sure the remote transport entity has stopped using the reference. so the reference should not be re-used for further connections. (in practice, the reference may be re-used after a reasonable period, once it's reasonably certain the remote transport entity won't keep using it.) patience is a virtue, babe 🦋
6.9. Spurious Disconnect
Purpose: To deal with the arrival of an "unknown" DR TPDU. 👀
TPDUs and fields used:
DR, DC
- source reference
- destination referenceDescription:
a DR TPDU can show up for a transport connection that doesn't exist. instead of calling it an error, a DC TPDU should be sent back that reflects the references of the DR TPDU. no drama, just a polite reply 🫶
Note:
this only applies when one or more transport connections using a multiplexing class exist over the network connection, or when no transport connections exist. at other times it is a protocol error. ngl the exceptions are where the tea is 🍵
6.10. Data TPDU Numbering
Variants: 'normal' or 'extended'
Purpose: Numbering of DT TPDUs for use in recovery, flow control, or sequencing functions. 🔢
TPDUs and Fields Used:
DT
- TPDU-NR (7 or 31 bits)Description:
DT TPDUs sent in each direction on a transport connection carry a sequence number called 'TPDU-NR'. the first DT TPDU in each direction after connection establishment has a value of zero. after that, each TPDU has a 'TPDU-NR' one greater than the previous one. the 'normal' variant uses modulo 27 arithmetic, and the 'extended' variant uses modulo 231 🧮✨
in the sections that follow, the terms 'greater than' and 'less than' are used with TPDU numbers. in every one of those uses, the numbers being compared cover a range smaller than the modulus, and they all sit inside a contiguous set of TPDU numbers called a 'window'. the window has a known starting TPDU number and a finishing number. 'less than' means 'occurring sooner in the window sequence', and 'greater than' means 'occurring later in the window sequence'. it's giving number line energy 📏💜
6.11. Expedited Data Transfer
Variants: 'network expedited' or not
Purpose: Provision of the expedited data service 🚀
Network Service Primitives:
N-DATA
N-EXPEDITED DATATPDUs and Fields Used:
ED
- ED TPDU-NR (7 or 31 bits)
EA
- YR-TU-NR (7 or 31 bits)Description:
each expedited TSDU is carried in the data field of an Expedited Data (ED) TPDU. every ED TPDU received must be acknowledged with an Expedited Acknowledge (EA) TPDU. only one ED TPDU can be unacknowledged at any time for each direction of a transport connection, so no pile-ups allowed 🙅♀️
in the 'network expedited' variant (available in class 1 only), ED and EA TPDUs travel in the data fields of N-EXPEDITED DATA primitives. otherwise, N-DATA is used instead 🦋
6.12. Reassignment
Purpose: Assignment of a Transport Connection to a different Network Connection. 🔀
TPDUs and Fields Used:
CR
- source reference
RJ, DR
- destination referenceDescription:
when the Network Connection that a Transport Connection was assigned to no longer exists, the Transport Connection can be assigned to another Network Connection 💫
once one transport entity has assigned the Transport Connection, it's super important that the other transport entity recognises which Network Connection it was assigned to. that can only happen when the other side gets a TPDU for the Transport Connection on a Network Connection whose calling and called network addresses imply the same transport entities as the old one. that TPDU will have been sent because the assigning transport entity started resynchronization, so it'll be an RJ, or a retransmitted CR or DR 🧩
the Transport Connection shall be recognised as assigned to the Network Connection on which that TPDU was received. the vibes are fully reassigned 🫶
6.13. Reassignment After Failure
Purpose: Recovery from network provider initiated disconnect. 🛠️
Network Service Primitives:
N-DISCONNECT IndicationDescription:
when an N-DISCONNECT Indication arrives for the network connection a transport connection is assigned to, the transport connection must be reassigned by its initiator (see "Reassignment") 🔁
if the reassignment hasn't successfully happened within T-wait seconds, then both transport entities must consider the transport connection as non-existent. the clock is ticking, bestie ⏰
- The CR TPDU does not have a destination reference; nevertheless it can be distinguished from a new connection attempt by having the same source reference.
NOTE: The value of T-wait has to be agreed by the communicating transport entities. 🤝
6.14. Retention Until Acknowledgement of TPDUs
Variants: 'confirmation of receipt' or 'AK'
Purpose: To enable and minimize retransmission after possible loss of TPDUs. 🔄
Network Service Primitives:
N-DATA
N-DATA ACKNOWLEDGETPDUs and Fields Used:
CR, CC, DR, DC
RJ, AK, EA
- YR-TU-NR (7 or 31 bits)
DT
- TPDU-NR (7 or 31 bits)
ED
- ED TPDU-NR (7 or 31 bits)Description:
copies of the following TPDUs shall be retained upon transmission so they can be retransmitted later if needed 💾
CR, CC, DR, DT, ED.NOTE: If DR is sent in response to CR there is no need to retain a copy of the DR. 🙌
in the 'confirmation of receipt' variant, which only applies in Class 1, transport entities that receive N-DATA Indications carrying DT TPDUs with the confirmation request field set shall issue a N-DATA Acknowledge Request at the earliest possible opportunity (1). ✅
(1) It is a local matter for each transport entity to decide which N-DATA Requests should have the confirmation request parameter set. This decision will normally be related to the amount of storage available for retained copies of the DT TPDUs. Use of the confirmation request parameter may affect the quality of network service. 🧠
after each TPDU is acknowledged, as shown in Figure 5, the copy doesn't need to be kept anymore. copies may also be discarded when
...until the transport connection ceases to exist. 🦋
Okay, so here's the acknowledgement cheat sheet 📋 Figure 5 shows which TPDU gets acked by which one, and the notes explain the two variants 💅
TPDU ACKNOWLEDGED BY
CR receipt of CC, DR, or ERR, TPDU
DR receipt of DC or DR (in case of collision)
TPDU
CC receipt of RJ, DT, AK, ED, EA TPDUs (or
N-DATA ACKNOWLEDGE Indication.)
DT N-DATA ACKNOWLEDGE Indication when the
(Note 1) DT TPDU was sent before or with the oldest
N-DATA which had the confirmation request
field set.
DT receipt of Data Acknowledge (AK) or
(Note 2) Reject (RJ) TPDU for which 'YR-TU-NR'
is greater than 'TPDU-NR' in the DT TPDU.
ED receipt of EA TPDU for which 'YR-TU-NR'
is equal to 'ED-TPDU-NR' in the ED TPDU. Notes:
1. Applies to 'confirmation of receipt' variant.
2. Applies to 'AK' variant.
Figure 5. Acknowledgement of TPDUs6.15. Resynchronization
Purpose: 🩹 To restore the connection to normal after an error. Basically, get things back on track after something goes sideways.
Network Service Primitives: N-RESET Indication
TPDUs and Fields Used:
CR, DR, CC, DC
RJ, EA
- YR-TU-NR (7 or 31 bits)
DT
- TPDU-NR (7 or 31 bits)
ED
- ED TPDU-NR (7 or 31 bits)Description: 🔄 Once an underlying network connection has been reset, both transport entities run the resynchronization procedures below. Totally a team effort, bestie 🫶
After a network connection failure, the reassignment after failure function gets invoked first, and then the resynchronization function kicks in. Here's the play-by-play at the two transport entities 👀
Events at the transport entity initiating reassignment: (the transport entity immediately commences resynchronization by sending a TPDU) 🚀
- if a CR is retained then retransmit it.
- if a DR is retained then retransmit it.
- otherwise, resynchronize data:
- send RJ TPDU with 'YR-TU-NR' field set to the 'TPDU-NR' of the first unreceived DT TPDU
- when RJ TPDU has been received retransmit any ED TPDUs then DT TPDUs which are unacknowledged
- any ED TPDUs received which are duplicates shall be acknowledged (by EA TPDUs) and discarded.
Events at the other transport entity: 🙈
The transport entity shall not send any TPDUs until after receipt of the TPDU which commenced resynchronization. This TPDU therefore serves two purposes, namely indication of re-assignment and commencement of resynchronization. So it's doing double duty, iconic ✨
- if the first received TPDU is a DR, then transmit a DC TPDU.
- if the first received TPDU is a CR and the transport connection is not idle, this means that a CC TPDU is retained: then retransmit it followed by any ED TPDU and then DT TPDUs which are outstanding (that may or may not have been transmitted previously).
- if the first received TPDU is a RJ, then act as follows:
- if a DR TPDU is retained, then retransmit it
- if a CC TPDU remains unacknowledged, then carry out the data resynchronization procedure described below
- otherwise resynchronize data:
- send RJ TPDU with 'YR-TU-NR' field set to the 'TPDU-NR' of the first unreceived DT TPDU
- retransmit any ED TPDUs then DT TPDUs which are unacknowledged
- any ED TPDUs received which are duplicates should be acknowledged (by EA TPDUs) and discarded.
NOTE: no TPDUs can be transmitted using network expedited until CC becomes acknowledged, to prevent the network expedited overtaking the CC. 🚫 Don't let expedited jump the queue, periodt 💅
NOTE: It is possible for a transport entity using the Class 1 protocol to decide on a local basis to issue an N-RESET Request. The effect of this request at the remote transport entity is to force it to perform the resynchronization mechanism. This possibility may be used to remove congestion within the network connection. 🌊 Lowkey a clever escape hatch for congestion, no cap.
6.16. Multiplexing and Demultiplexing
Purpose: 🧚 Concurrent sharing of a network connection by several transport connections. Sharing is caring, fr fr.
TPDUs and Fields Used:
CC, DR, DC, DT, AK, ED, EA, RJ, ERR
- destination referenceDescription: This function is pervasive, so it's literally everywhere 🌈
When this function is in operation, more than one transport connection can be simultaneously assigned to the same network connection. Multiple besties, one network connection, the group chat is thriving 💜
Every TPDU (including DT TPDUs) must carry the destination reference, to identify the transport connection to which it refers. No exceptions, not even for DT, it's giving strict bouncer energy 🎀
6.17. Explicit Flow Control
Purpose: 🌸 Regulation of flow of DT TPDUs independently of the flow control in the other layers. Think of it as its own little traffic cop 🚦
TPDUs and Fields Used:
CR, CC, AK, RJ
- CDT (4 or 16 bits)
DT
- TPDU-NR (7 or 31 bits)
AK, RJ
- YR-TU-NR (7 or 31 bits)
- subsequence number (optional)
- flow control confirmation (optional)Description: The mechanism depends on the class. Thus the description can be found in the section describing the class. So go check that section, it's the real tea ☕
6.18. Checksum
Purpose: 🔍 To detect corruption of TPDUs by the network service provider. Catching the glitches before they ruin the vibe 💀
TPDUs and Fields Used:
All TPDUs
- checksum (16 bits - 32 bits)Description: 🧮 Buckle up, this one's math-heavy but honestly so iconic.
When a TPDU is to be transmitted for a TC which has selected the checksum option, the sending transport entity must generate a checksum for the TPDU and store it in the checksum parameter in the variable part of the TPDU header. The checksum must be generated as follows:
- Set up the complete TPDU, including the header and user data (if any). The header must include the checksum parameter in its variable part. The value field of the checksum parameter must be set to zero at this point.
- Initialize two variables to zero. Let these variables be called C0 and C1.
- For each octet of the TPDU, including the header, variable part of the header and the user data, add the octet value to C0, and then add the value of C0 to C1. Octets should be processed sequentially, starting with the first octet (the Length Indicator) and proceeding through the TPDU. All addition is to be performed modulo 255.
- Calculate the value field of the checksum parameter as follows. Let the offset into the TPDU of the first octet of the value field be 'n' (where the first octet of the TPDU, the Length Indicator of the header, is considered to be at offset 1). Let the length of the TPDU, i.e. the number of times the above operation was repeated, be 'L'. Let the first octet of the checksum value, i.e., the one at offset 'n' be called 'X', and the second octet, at offset 'n+1', be called 'Y'. Then:
X = (((L - n) * C0) - C1) modulo 255
Y = (((L - n + 1) * (-C0)) + C1) modulo 255- Place the computed values of X and Y in the appropriate octets of the TPDU.
NOTE: An implementation may use one's complement arithmetic as an alternative to modulo 255 arithmetic. However, if either of the checksum octets X and Y has the value minus zero (i.e., 255) then it must be converted to plus zero (i.e., 0) before being stored. ➕➖ Minus zero is a no-go, it has to become plus zero.
When a TPDU is received for a TC for which the checksum option has been selected, the TPDU must be verified to ensure that it has been received correctly. This is done by computing the checksum, using the same algorithm by which it was generated. The nature of the checksum algorithm is such that it is not necessary to compare explicitly the stored checksum bytes. The procedure described below may be used to verify that a TPDU has been correctly received. Basically, the math does the checking for you 🪄
- Initialize two variables to zero. Let these variables be called C0 and C1.
- For each octet in the received TPDU, add the value of the octet to C0 and then add the value of C0 to C1, starting with the first octet and proceeding sequentially through the TPDU. All addition is to be performed modulo 255.
- When all octets have been sequentially processed, the values of C0 and C1 should be zero. If either or both of them is non-zero, the TPDU has been received incorrectly and the verification has failed. Otherwise, the TPDU has been received correctly and the TPDU should be processed normally.
NOTE: An implementation may use one's complement arithmetic as an alternative to modulo 255 arithmetic. In this case, if either C0 or C1 has the value minus zero (i.e., 255) it is to be regarded as though it was plus zero (i.e., 0).
If a checksum verification failure occurs, it is not possible to determine the TC that the TPDU relates to, since the Reference field of the TPDU may have been received incorrectly. Therefore, all TCs multiplexed onto the same NC must be treated as though a network signalled error has occurred. 😭 One bad packet and suddenly the whole squad is affected, so dramatic, but that's the rule.
6.19. Frozen References
Purpose: 🧊 To prevent re-use of a reference while TPDUs associated with the old use of the reference may still exist. Let the old stuff chill before anyone reuses it 🫠
Description: When a transport entity determines that a particular connection has terminated, the reference shall be placed in a frozen state during which time it will not be reused. The circumstances under which this is done, and the period of time for which the reference remains frozen depends on the class. Class-dependent, so check your class section ✨
6.20. Retransmission on Timeout
Purpose: 🔁 To cope with unsignalled loss of TPDUs by the network service provider. When TPDUs just vanish without a word, this is the comeback 💪
TPDUs and Fields Used:
CR, CC, DR, DT, ED, AKDescription: The description is given in the section related to class 4. 🎀 Class 4 has got you covered.
6.21. Resequencing
Purpose: 🧩 To cope with misordering of TPDUs by the network service provider. Putting the puzzle pieces back in order 🧩
TPDUs and Field Used:
DT
- TPDU NR
ED
- ED TPDU NRDescription: The description is given in the section related to class 4. Same deal, go hang out with class 4 🌸
6.22. Inactivity Control
Purpose: 👻 To cope with unsignalled termination of a network connection. When the connection ghosts you without saying goodbye 💔
TPDUs and Fields Used:
AKDescription: The description is given in the section related to class 4. Class 4 again, bestie, it's the answer to everything 👑
6.23. Treatment of Protocol Errors
Purpose: 🚨 To deal with invalid TPDUs. Not the vibe, so we handle it.
TPDUs and Fields Used:
ERR
- reject cause
- TPDU in error (string of octets)
DR
- reason codeDescription: This function is inherent. 🧬 It's just built right in.
Any received TPDU which is invalid or which cannot be dealt with by any operative function, or which is regarded as a violation of the protocol rules of the class in use (e.g., receipt in a wrong state, window error, sequencing error, TPDU with incorrect format), shall be considered as a protocol error. Like, anything that's out of line with the rules, it's a protocol error, no debate 🙅♀️ Such an error shall be signalled to the transport entity responsible by the sending of an TPDU Error (ERR) TPDU or by initiating a release. The ERR TPDU conveys the octets of the offending TPDU up to and including the octet where the error was detected. So the receiver gets the receipts, down to the exact octet that went wrong 🔍
In general, no further action is defined for the sender of
6.23 Continued 💌
ERR TPDU, since it is expected that the offender will either correct the error, or close the connection. That's the whole vibe 🙄 The offender is supposed to fix it or dip. 💅
What the receiver does next is up to its local implementation 🛠️ For example, it could freeze the connection, report to management, or disconnect. Your call, bestie ✨
Notes:
- What happens after is a local implementation issue 🤷♀️ Be careful if your transport entity gets several invalid TPDUs or ERR TPDUs, so you don't end up looping forever if the error keeps getting generated 🌀
- There are two cases where the receiver of an ERR TPDU has specific action defined (check Sections 6.6 and 7.0.7) 💖
6.24 Splitting and Recombining 🦋
Purpose: letting one transport connection use multiple network connections for extra resilience against network failure, more throughput, or other reasons 🌈
Description:
This one is only available in Class 4 👑
When this function is in use, a transport connection is assigned (see Section 6.1) to multiple network connections. TPDUs for the connection may be sent over any assigned network connection. The resequencing function of Class 4 (see Section 6.21) is used to make sure TPDUs are processed in the correct order 🧚
If the remote transport entity doesn't accept Class 4 following the negotiation rules, only the network connection that the CR TPDU was sent over may be used for this transport connection 🙈
The splitting function should only be used where the supporting network connections provide similar transmit delay ⭐
Here's the mechanism chart:
Protocol Mechanism Variant 0 1 2 3 4
Assignment to Network Conn. * * * * *
TPDU Transfer * * * * *
DT TPDU Length and Segmenting * * * * *
Concatenation and Separation * * * *
Connection Establishment * * * * *
Connection Refusal * * * * *
Release implicit *
explicit * * * *
Implicit Termination * *
DT TPDU Numbering normal * m m m
extended (1)o o o
Expedited Data Transfer network exp. ao
not " m * * *
(1)
Reassigment * *
Reassignment after Failure * *
Retention until Acknowledge- Conf. Receipt ao
ment of TPDUs AK m * *
Resynchronization * *
Multiplexing and * * *
Demultiplexing
Explicit Flow Control With m * *
Without * * o
Checksum (use of) m
(non-use of) * * * * o
Frozen References *
Retransmission on Timeout *
Resequencing *
Inactivity Control *
Treatment of Protocol Errors * * * * *
Splitting and recombining *
(1) not applicable in class 2 when the non use of explicit flow
control is selected.7. PROTOCOL CLASSES 💅
Okay so the details of how the protocol mechanisms get implemented can be different from class to class 🌸 That's why the table below isn't a full description of each class. It's more like a quick overview of how each class works ✨ The exact definition lives in the sections that follow 💜
Here's the key for the table:
* include in the class (always)
m mandatory function (negotiable but always implemented)
o additional function (negotiable but not necessarily implemented)
ao additional function (negotiable but not necessarily implemented).
Use of this option depends on the willingness of both transport
entities and availability of network service.
na not applicable.7.0 PROTOCOL DESCRIPTION OF CLASS 0: SIMPLE CLASS 🎀
7.0.1 Characteristics of Class 0
Class 0 is the simplest kind of transport connection 🍓 It's fully compatible with the CCITT recommendations S.70 for Teletex terminals, so it's giving classic 💅
This class is designed to be used with network connections of type A (see 5.3.1.2.4.) 🦋
7.0.2 Functions of Class 0
Class 0 has minimum functionality on purpose 🤍 It only includes what's needed for connection establishment with negotiation, data transfer with segmenting, and protocol error reporting.
Flow control is based on the flow control the network service provides, and disconnection is based on the network service disconnection 🫶
7.0.3 Protocol Mechanisms of Class 0
7.0.3.1 Connection Establishment Phase
Connection is made following the general rules (Assignment of Network Connection, Connection Establishment and Connection Refusal), with these restrictions:
- No exchange of user data is allowed 🙅♀️
- Only TSAP-ID and TPDU size parameters are allowed.
7.0.3.2 Data Transfer Phase
- Segmenting (DT TDPU length and Segmenting) ✂️
- Detection and indication of procedural errors 🚨
7.0.3.3 Release Phase
Class 0 has no explicit transport connection release procedure 🙃 The lifetime of the transport connection is directly tied to the lifetime of the network connection 🔗
7.0.4 Connection Establishment for Class 0
Connection establishment works with a constraint: only the transport entity that requested the network connection may send the CR TPDU 👑 If the calling transport entity receives a CR TPDU, it shall send a TPDU Error (ERR) TPDU to tell the called transport entity about the procedure error 🙅♀️
7.0.5 Data Transfer Procedures
7.0.5.1 General
The data transfer procedures in the subsections below only apply when the transport layer is in the data transfer phase, meaning after Transport Connection establishment is complete ✨
7.0.5.2 Transport Data TPDU maximum length
For Class 0, the standard maximum transport data TPDU length is 128 octets, including the data TPDU header octets 📏
Other maximum TPDU lengths can be supported with the optional transport data TPDU size negotiation function (see Section 8.3 and 8.4) 🌟 Optional maximum data field lengths shall be chosen from this list: 256, 512, 1024 and 2048 octets.
TSDUs are transmitted using the segmenting function 🧩
7.0.6 Release Procedure
The "implicit" variant of the release function is used 🌙
7.0.7 Treatment of invalid TPDUs
The "treatment of protocol errors' function is used 🚨
7.0.8 Behaviour after an error signalled by the network service
The implicit termination function is used, and the high layer is informed about this disconnection 📣
7.0.9 Supported Options
None 🫧
7.1 PROTOCOL DESCRIPTION OF CLASS 1: BASIC ERROR RECOVERY CLASS 🛟
7.1.1 Characteristics of Class 1
Class 1 gives you a basic transport connection with minimal overheads 🍃
Its main purpose is to recover from errors signalled by the network (network disconnect or reset) 🔄 Picking this class is usually about reliability 💖 Class 1 was designed for use with type B network connections.
7.1.2 Functions of Class 1
Class 1 provides transport connections with flow control based on the flow control the network service provides, plus error recovery, expedited data transfer, disconnection, and the ability to support consecutive Transport connections on a network connection 🧠
Basically it does everything Class 0 does, plus it can recover after a failure signalled by the Network Service, without involving the user of the Transport Service 🦸♀️
7.1.3 Protocol Mechanisms of Class 1
Class 1 includes the Class 0 protocol mechanisms plus the following:
7.1.3.1 User Data in the Connection Phase
Class 1 lets you convey data in the connection request and confirm commands 📨
7.1.3.2 Numbering of Data TPDU
Every Data TPDU sent between transport entities in each direction of a transport connection gets a sequential number 🔢
7.1.3.3 Release
The "explicit" variant of the release function is used 🎬
7.1.3.4 Error Recovery
The sending transport entity keeps a copy of each transmitted TPDU until it gets an acknowledgment that lets it release those copies 📋 After the network service signals a failure (Reset, Disconnect), the resynchronization function is used to figure out which TPDUs must be retransmitted 🔁
A transport entity can also invoke resynchronization as a local matter. For that, the Resynchronization function is used (see the note at the end of Section 6.15) 💫
7.1.3.5 Acknowledgement
Acknowledgements are used to release copies of retained TPDUs 🫧
Two methods of acknowledgment are provided in the Retention until Acknowledgement of TPDUs function:
- use of AK TPDU ("AK" variant) - mandatory 💌
- Note: the credit field of the AK TPDU is not used in this class (always Set to zero) 0️⃣
- use of network layer Confirmation of Receipt Service ('confirmation of receipt' variant) - optional 🧾
The variant to be used is negotiated during the Connection Establishment Phase. The default option is the "AK TPDU" variant 🤝 Network Layer Receipt Confirmation is only allowed in Class 1. It depends on whether the network layer receipt confirmation service is available, the expected cost reduction, and whether both transport entities agree to use it 💅
7.1.4 Connection Establishment Procedures for Class 1
The 'assignment to network connection' and 'connection establishment' mechanisms are used. From the point where a transport entity issues a CR proposing Class 1, or a CC accepting Class 1, the following mechanisms must be available to deal with signalled errors during connection establishment 🚦
- Reassignment after failure
- Retention until Acknowledgement of TPDUs
- Resynchronization
If no DT or ED TPDU is going to be sent, receipt of a CC should be acknowledged 🙏
7.1.5 Data Transfer Phase
Data transfer uses the 'TPDU transfer', 'Concatenation' and 'DT TPDU Length and Segmenting' mechanisms 📦 'DT TPDU Numbering' and 'Retention until Acknowledgement of TPDUs' support error recovery 🛡️
7.1.5.1 Behaviour after an error
After receiving a network reset, the Resynchronization mechanism is invoked. After receiving a network disconnect, the 'Reassignment after Failure' mechanism is invoked first, and then the 'Resynchronization' mechanism is invoked ⏭️
The 'Spurious Disconnect' mechanism is used to deal with receiving a DR TPDU for an unrecognised Transport Connection 👻
7.1.5.2 Procedure for Expedited Data Transfer
The Expedited Data Transfer mechanism is used 🚀
7.1.6. Release Procedures ✨
The 'explicit' variant of the Release mechanism is the one used here 💅
When a transport entity gets an error indication, and it had already sent a DR before that happened, it has to send the DR again 🔁 Only DC and DR TPDUs count as finishing the connection release sequence, so those are the only ones that get accepted and interpreted that way. After that, the related Reference becomes unassigned 🫶
7.1.7. Treatment of Unknown TPDUs 🙈
The 'Treatment of Protocol Errors' mechanism is used for this.
7.1.8. Supported Options 🎀
- Use of network receipt confirmation.
- Use of network expedited.
7.2. PROTOCOL DESCRIPTION OF CLASS 2: MULTIPLEXING CLASS 🦋
7.2.1. Characteristics of Class 2
Okay so Class 2 is all about multiplexing, which means squeezing several transport connections onto one single network connection 🧚 This class was designed to be used with type A network connections 👑
Use of Explicit Flow Control 🌸
The goal here is flow control, which helps avoid congestion at the end-points and on the network connection 💜 It's most useful when traffic is heavy and continuous, or when there's a lot of intensive multiplexing going on. Using flow control can optimize response times and resource utilization ✨
Non Use of Explicit Flow Control (OPTIONAL) 🍓
This one gives you a basic transport connection with minimal overhead 💅 It's a good fit when you want the independence of transport and network connection lifetimes. The class would typically be used for unsophisticated terminals, and when no multiplexing onto network connections is required. Expedited data is never available here 🙈
7.2.2. Functions of Class 2
Class 2 gives you transport connections with or without individual flow control. No error detection or error recovery is provided, so it's not the one for error handling 🫣
If the network resets or clears, the transport connection is terminated without the transport clearing sequence, and the transport user is informed 😭
When explicit flow control is used, a credit mechanism is defined. This lets the receiver tell the sender the exact amount of data it's willing to receive 🎀 Expedited data transfer is available too 🔥
7.2.3. Protocol Mechanisms of Class 2
7.2.3.1. Connection Establishment Phase
The connection establishment function SHALL be used 💖
7.2.3.1.1. User Data in the Connection Phase
Class 2 lets you send data along with the connection request and confirm commands 🫶
7.2.3.2. Connection Identification
In Class 2, each TPDU carries a Destination Reference 🦋 That uniquely identifies the transport connection inside the receiving transport entity, and that's what makes multiplexing possible 👑
7.2.3.3. Release Phase
A transport connection gets released either through the 'explicit' variant of the release function, or through the Implicit Termination function ✨
7.2.3.4. Protocol Mechanisms when Explicit Flow Control is used.
These mechanisms are provided 💅
7.2.3.4.1. Numbering of Data TPDU
Each Data TPDU sent between transport entities, in each direction of a transport connection, gets a sequence number 🔢 Each Data TPDU also contains a Send Sequence Number T(S) 🌈
7.2.3.4.2. Flow Control Principles
The receiver of data TPDUs keeps a count of the sequence number of the next TPDU it expects. That count is called the Receive Sequence Number, T(R) 🧚 The receiver tells the sender how many Data TPDUs it's ready to receive using a 'credit' mechanism 💖 Credits are given in the credit field of the AK TPDU.
The value of the credit field, together with the T(R) value carried in the YR-TU-NR (your TPDU number) field of the AK TPDU, is what the receiver of the AK TPDU uses to work out whether, and how many, Data TPDUs may be accepted by the sender of that AK TPDU 🤓 The precise definition of the flow control principles appears in Section 7.2.5.5.3 📚
7.2.3.4.3. Expedited Flow
The non network expedited variant is used here 🔥 Normal flow is the flow of data subject to the flow control mechanism. Expedited flow is the flow of data that the sender MAY send without explicit agreement from the receiver ✨ This expedited flow has limited capability, and could for example be used to carry session supervisory commands 🫶
The number of expedited data units outstanding at any time is limited to one, and the amount of TS-user data is limited (up to 16 octets) 💅
Expedited data MAY arrive before normal data that was submitted earlier 😭 Normal data submitted after the expedited data will arrive after the expedited data 🦋
7.2.4. Connection Establishment Procedures for Class 2 💜
7.2.4.1. References
See Section 6.5 for reference assignment 📚 Receipt of any TPDU with a reference that is not assigned to a transport connection will be ignored, unless it's a Disconnect Request (DR) or Connection Request (CR) 🙈
Receipt of a Disconnect Request (DR) for an unassigned Reference will result in a Disconnect Confirm (DC) response 🌸
7.2.4.2. Connection Eastablishment
This phase is achieved by exchanging CR/CC TPDUs using the 'connection establishment' function ✨ Since the multiplexing function is in use, more than one transport connection may be assigned to the same network connection at the same time 🧚 The restrictions of Class 0 do not apply to this class or the other higher classes 👑
7.2.5. Data Transfer Procedures for Class 2 🎀
The data transfer procedures in the following section apply independently to each transport connection that exists between two transport entities 🫶
7.2.5.1. TPDU Maximum Length and Segmenting
The general rules defined in Section 6.3 apply 💅
7.2.5.2. Concatenation
The general rules defined in Section 6.4 apply 💖
7.2.5.3. Sending Data TPDU (No Explicit Flow Control Option)
In this case the data TPDU is built according to the rules in Sections 6.2 and 6.3, and sent without any additional mechanisms 🦋 So the DT TPDU NR field MAY take any value, and no AK TPDU is used 🙈
7.2.5.4. Sending Data TPDU (When Explicit Flow Control is Used)
On each transport connection, transmission of Data TPDUs is controlled separately for each direction, and it's based on authorization from the receiver 👑
This authorization comes through the TPDUs Credit field. Credit field values are only present in the following TPDUs: CR, CC, AK. 💜
7.2.5.4.1. Numbering of Data TPDUs
Each Data TPDU sent between transport entities, for each direction of a transport connection, is sequentially numbered 🔢
The sender of Data TPDUs keeps a count of the next TPDU to be sent. That count is called the Send Sequence Number T(S) 🧚 The sender tells the receiver the number of the data TPDU it sends by putting the current T(S) value into the TPDU-NR field of the data TPDU ✨
Sequence numbering is performed modulo 2n, where n is the number of bits of the sequence number field. The T(S) counter cycles through the entire range 0 to (2n)-1 🌈
At connection establishment time, both Transport entities initialize their T(S) and T(R) counts to zero. That means the first Data TPDU sent between transport entities for a given direction of data transmission after connection establishment has a TPDU-NR field set to zero 🫶
Receipt of a Data TPDU whose TPDU-NR field is not equal to the expected value T(R) is to be regarded as a protocol error 🙈
Here's the operations summary in one place 🤓
o initalization
T(S) = 0 T(R) = 0
Sending of Data TPDU
put T(S) into the TPDU-NR field of
the Data TPDU to be sent
T(S) = (T(S) + 1) (modulo 2**n)
Receiving of Data TPDU
TPDU-NR field of the received data
TPDU which is not equal to T(R) is
a protocol error.
T(R) = (T(R) + 1) (modulo 2**n)7.2.5.4.2. Window Definition
For each transport connection, and for each direction of data transmission, a 'transmit window' is defined. It's the (possibly null) ordered set of consecutive data TPDUs authorized to be transmitted in that direction 🪟 At any given time, the lowest sequence number of a data TPDU that a transport entity is authorized to transmit is called the 'lowest window edge' 🦋
The 'upper window edge' is calculated by adding the credit allocation, given by the value of the Credit (CDT) field in a received TPDU, to the lower window edge 💖 Note that a transport entity is authorized to send data TPDUs with sequence numbers up to, but not including, the upper window edge 👑
7.2.5.4.3. Flow Control
Flow control works like this 💅
- initialization time
Lower window edge = 0
Upper window edge = N (Credit received either in
CR or in CC and N < 2**p < 2** (n-1), where P is the number of
bits in credit field of CR and CC.- Sending of a Data TPDU
Send data TPDUs while T(S) is less than the upper window edge. If T(S) equals the upper window edge, then wait for additional credit before sending 🫶
- Reception of Data TPDU (with TPDU NR = T(R)
If T(R) is greater than or equal to the upper window edge
authorized to the sending transport entity, then the receiving
transport entity SHALL use the Treatment of Protocol Errors
function. Otherwise T(R) SHALL be incremented.Sending Credit:
Send AK TPDU with YR-TU-NR = T(R) and Credit equals N.
(Where N = number of additional data
TPDUs the entity is prepared to receive.)Receiving Credit in AK:
Lower window edge = YR-TU-NR received.
Upper window edge = Lower window edge + N.Heads up: in the Reception bullet above, the rule that says T(R) SHALL be incremented is the one doing the heavy lifting, so don't skip it 🙈
7.2.5.4.4. Reducing the Upper Window Edge
The value of the upper window edge cannot be decreased in this class 🚫 If, at a certain point in time, the upper window edge value is U, then receiving an AK TPDU with YR-TU-NR = M and CDT = N, such that:
(U-M) (mod. 2**n) > Nis a protocol error 😭
As long as the previous statements are respected, the CDT field MAY take any value, including zero 🌸
7.2.5.4.5. Procedure for Expedited Data Transfer
The expedited data transfer procedure lets a transport entity send data to the remote transport entity without following the flow control procedure of the normal data flow 🔥 This procedure can only apply in the transfer phase 🧚
The expedited procedure has no effect on the transfer and flow control that apply to normal Data TPDUs ✨
To send expedited data, the transport entity sends an expedited data TPDU (ED TPDU) 💖 The size of a data field is limited (up to 16 octets), and the data field contains a complete ED TSDU 🎀 Then the remote transport will confirm the receipt of the ED
…TPDU by sending back an expedited TPDU acknowledgement (EA TPDU) 🦋 okay so the sender can only send another ED TPDU once it has gotten an EA TPDU back for the one before it 💅 In class 2, the ED TPDU NR field of the ED and the YR-TU-NR field of the EA TPDU aren't defined at all, so they may take any value 🌸
7.2.6 Release Procedures for Class 2 🌈
The data phase is over once a transport entity has sent or received a Disconnect Request (DR) 💀 After that, the entity ignores any incoming TPDU except DC or DR 🙈
If the network resets or clears the network connection, all transport connections get terminated without the transport clearing sequence 😭 The References become frozen. 🧊
For class 2, the explicit variant of the 'release' mechanism is used, which means transport connections can be cleared on their own, independently of the underlying network connection ✨
7.2.7 Treatment of Invalid TPDUs 🎀
The 'Treatment of Protocol Error' mechanism in Section 6.23 is the one that gets used here 💅
7.2.8 Behaviour after an Error signalled by the Network Layer. 🫶
The implicit termination mechanism is used 👑
7.2.9 Supported Options 🍓
Here's what's supported in class 2:
- Non use of explicit flow control.
- Extended formats.
7.3 PROTOCOL DESCRIPTION OF CLASS 3: ERROR RECOVERY AND MULTIPLEXING CLASS 🦋
7.3.1 Characteristics of Class 3 💖
Class 3 does everything class 2 does, plus it masks errors that the network indicates 🫧 Picking this class is usually about reliability, bestie 🔥 Class 3 was designed to be used with type B network connections.
7.3.2 Functions of Class 3 ✨
This class gives you the functionality of class 2 (with explicit flow control) plus the ability to recover after a failure signalled by the Network Layer, without the user of the transport service ever having to get involved 🧚 The mechanisms that make this work also allow for more flexible flow control, which is so clean 💜
7.3.3 Protocol Mechanisms of Class 3 🌸
Class 3 mechanisms include the class 2 mechanisms (with the explicit flow control option), plus the ability to recover after a failure signalled by the network without telling the user of the transport connection 🫶
7.3.3.1 Error Recovery Principles 🔁
The sending transport entity keeps a copy of every Data TPDU and ED TPDU it transmits, until it gets a positive acknowledgement that lets it release those copies 📦 It can also receive an RJ command, inviting it to retransmit (or transmit) all Data TPDUs, if there are any, from the point in the sequence that the RJ command points to 🎀
This is especially the case when the network indicates a failure 😭 The transport entity sends an RJ command to say which sequence number it expects next 💅
Error recovery for ED TPDU is achieved by retransmission (see 7.3.5.3) ✨
7.3.3.2 Relationship between Flow Control and Error Recovery 💞
Acknowledgement is done using the T(R) count 🌷 Each acknowledgement comes with a credit, which may be equal to or greater than zero. So it's totally possible to acknowledge data without giving anyone the right to send new data 🙈 Credit may also be reduced, using the RJ TPDU 🧊
7.3.4 Connection Establishment Procedure for Class 3 🛎️
The rules for class 2 (with explicit flow control) still apply, plus these extra rules that kick in when the entity gets an error indication from the Network layer 🚨
- Reception of an error indication by a transport entity which, before this event, has sent a
CRand has not yet received aCC, causes the transport entity to retransmitCR. - Reception of an error indication by a transport entity to wait for reception of
CR,RJorDRTPDU. In this case:- Reception of
CRwill cause the transport entity to retransmitCC. - Reception of
RJwill cause the transport entity to transmit anRJwith aYR-TU-NRequal to zero and enter the data phase. - Reception of a
DRwill cause termination of the transport connection as for Classes 1 and 2 (see 7.1.4).
- Reception of
7.3.5 Data Transfer Procedures for Class 3 🌈
7.3.5.1 Acknowledgement 🩵
The 'AK' variant of the Retention until Acknowledgement of TPDUs function is used 🎀
7.3.5.2 Retransmission Procedure 🔄
TPDU retransmission is a procedure that lets a transport entity ask the remote transport entity to resend one or several consecutive Data TPDUs 📨 A transport reject condition gets signalled to the remote transport entity by sending an RJ TPDU, whose YR-TU-NR field shows the sequence number of the next expected Data TPDU 💌
On receipt of an RJ TPDU, a Transport entity shall accept credit up to the value in the credit field, and shall re-transmit TPDUs, starting with the one whose number is in the YR-TU-NR field of the received RJ TPDU, subject to the new credit 🔁
The transport entity shall not specify a T(R) in the RJ TPDU that is less than what has already been acknowledged. Receiving an RJ TPDU with a T(R) that has already been acknowledged will be considered a protocol error 🙅♀️
Additional DT TPDUs that are still waiting for their first transmission may follow the retransmitted DT TPDU(s), as long as the window isn't closed 🌊
7.3.5.3 Reducing the upper window edge 🪟
It's possible to decrease the upper window edge, all the way down to the sequence number carried in the YR-TU-NR field of the RJ TPDU 📉 Receiving a DT TPDU that would have been inside the window before the reduction is not a protocol error, and that TPDU may be discarded 🗑️
Note: In such a case, the credit equal to zero achieves the effect of a Receive not Ready Condition.
7.3.5.4 Behaviour after an error signalled by the network layer 🧯
After receiving an error indication from the Network Service, the transport entity shall transmit to the remote entity an RJ TPDU, with its YR-TU-NR field showing the sequence number of the next expected Data TPDU 💫
7.3.5.5 Procedure for Expedited Data Transfer ⚡
In class 3, the ED TPDU-NR field of the Expedited Data (ED) TPDU holds an identification number. This number must be different for successive ED TPDUs. That means when an ED TPDU has been sent and an EA TPDU for it has come back, the next ED TPDU must have a different value in its NR field. No other significance is attached to this field. It is recommended, however, that the values used be consecutive modulo 2**n. When a transport entity receives an ED TPDU for a transport connection, it shall respond by transmitting an expedited acknowledgement (EA) TPDU 🎯
It puts the value from the NR field of the received ED TPDU into the YR-TU-NR field. If, and only if, this value is different from the NR field of the previously received ED TPDU, the data in the TPDU is to be passed to the session entity 🫧
If an error indication from the Network layer comes in before the expected Expedited Acknowledgement (EA) TPDU arrives, the transport entity shall retransmit the ED TPDU with the same value in its NR field 🔁 Thanks to the rule in the previous paragraph, the session entity never receives data for the same expedited TPDU more than once 🫶
7.3.6 Release Procedures for Class 3 🌙
The rules for class 2 apply, with one addition:
Receipt of an error indication by a transport entity, which before this event has sent a DR, causes this transport entity to retransmit DR. Only DC and DR will be accepted and interpreted as completing the connection clearing sequence. The related Reference will become unassigned. 🫥
7.3.7 Treatment of Invalid TPDUs 🎀
The 'Treatment of Protocol Errors' mechanism is used 💅
7.3.8 Supported Options 🍓
- Extended formats.
7.4 PROTOCOL DESCRIPTION OF CLASS 4: ERROR DETECTION AND RECOVERY CLASS 👑
7.4.1 Characteristics of Class 4 🔍
Class 4 builds on class 3 and adds the detection of errors that happen because the network layer gives a low grade of service 😤 The kinds of errors it detects include: TPDU loss, TPDU delivery out of sequence, and TPDU duplication. These errors can hit control TPDUs as well as Data TPDUs 🙀 Class 4 was designed to be used with network connections of type C 🧠
7.4.2 Functions of Class 4 🧩
This class gives you the functionality of class 3, plus the ability to detect and recover from lost, duplicated or out-of-sequence TPDUs, without the user of the transport service getting involved 🦋 The error detection is done by extending how the sequence numbering of classes 2 and 3 is used, by a timeout mechanism, and by additional protocol mechanisms ⏱️
Class 4 also detects and recovers from damaged TPDUs by using a checksum mechanism 🧮 The checksum mechanism must be available, but whether it is used or not is subject to negotiation 🤝 Class 4 does not try to deal with detecting errors caused by misdelivery of TPDUs 🙅♀️
7.4.3 Protocol Mechanisms of Class 4 🛠️
7.4.3.1 Network Service Data Unit Lifetime ⏳
The network layer is assumed to provide, as part of its grade of service, a bound on the maximum lifetime of NSDUs in the network 🔒 The Transport Layer knows this value. The maximum time that may pass between an NSDU being transmitted into the network layer and the receipt of any copy of it is referred to as M 🫧
7.4.3.2 Average Transit Delay 🚀
It is assumed that there is some network transmit delay, typically much less than M, which is the maximum delay suffered by all but a small proportion of NSDUs. This value is referred to as E 💫
7.4.3.3 Remote Acknowledge Time Assumptions 🕰️
Any transport entity is assumed to provide a bound on the maximum time that can pass between its receipt of a TPDU from the Network Layer and its transmission of the corresponding response. This value is referred to as A/L. The corresponding time given by the remote transport entity is referred to as A/R 💌 The values for these timers may be conventionally established, or they may be established at connection establishment time 🌸
7.4.3.4 Local Retransmission Time ⏰
The local transport entity is assumed to maintain a bound on how long it will wait for an acknowledgement before retransmitting the TPDU 🔁 This time is the local retransmission time, referred to as T1 🎀
T1 = 2*E + X + Ar?Where X is a value that allows for TPDU processing in the local transport entity 🧁
7.4.3.5 Persistence Time 🫧
The local transport entity is assumed to provide a bound on the maximum time it may keep retransmitting a TPDU that requires positive acknowledgment 💪 This value is referred to as R 🌟
The value is clearly related to the time elapsed between retransmissions, T1, and the maximum number of retransmissions, N. It is not less than T1*N+X, where X is a small quantity that allows 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 the bound is known 🫶
7.4.3.6 Bound on Reference Identifier and Sequence Numbers 🔐
Using the values above, a bound L may be established for the maximum time between the decision to transmit a TPDU and the receipt of any response relating to it. The value of L is given by:
L = 2*M+R+ArIt 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 is duplicated or delayed 🥹
(Note: In practice, the value of L may be
...unacceptably large 🙈 It may also be only a statistical figure at a certain confidence level. So a smaller value may therefore be used where this still allows the required quality of service to be provided) ✨
7.4.3.7 Inactivity Time ⏳
Okay so, to protect against unsignalled breaks in the network connection (Half-open connections) 👻, each transport entity keeps an inactivity time interval running. If that interval passes without receiving some TPDU, the transport entity will terminate the TC by using the release procedure. This interval is called I 💅
7.4.3.8 Window Time 🪟
A transport entity keeps a time so there's always a maximum interval between sending up-to-date window information. This interval is called the window time, W 🫶
7.4.3.9 Class 4 Error Recovery Principles 🔁
In class 4, the transport entity links a response time with TPDUs that need a response. If an appropriate response isn't received within time T1, the recovery procedure must be invoked by the sender. This will usually mean retransmitting the corresponding TPDU 🔥
A TPDU may be transmitted a maximum number of times. This number is referred to as N. The value of N is chosen so that the required quality of service can be provided given the known characteristics of the network connection 🌈
7.4.3.10 Relationship of Times and Intervals ⏱️
Here's how all the times from Section 7.4.3.1 - 7.4.3.9 vibe together 💜
Note:
- a. The interrelationship of times for the worst case is as follows:
- M: maximum transit delay of the network (see 7.4.3.1)
- Ar: maximum acknowledgement time of the remote transport entity (see 7.4.3.3)
- R: maximum local retransmission time (see 7.4.3.5)
- N: maximum number of transmission for a single TPDU (see 7.4.3.9)
- L: maximum time for a TPDU to be valid (see 7.4.3.6)
R = T * (N-1)
1
R
*
M
L *
A =2*M + A + R
R R
*
M
t t- b. The interrelationship of times for the average case is as follows (see 7.4.3.4)
- E: average transit delay for the network (E<<M)
- X: TPDU processing time
- T1: average time from sending a TPDU until the receipt of its acknowledgement (see 7.4.3.4)
- AR: maximum acknowledgement time of the remote transport entity (see 7.4.3.3)
X
E
A T = 2*E + X + A
R 1 R
E
t t7.4.3.11 Sequence Numbering 🔢
In Class 4, sequence numbering is applied to certain control TPDUs and their acknowledgements, as well as to DT TPDUs. These are ED and its acknowledgement EA 🎀
The length of sequence numbers may be negotiated at connection establishment. Where other than the default length is used, an extended header format is used for sequenced TPDUs containing additional octets of sequence numbers. Extended header format includes a credit field on the appropriate TPDU types allowing extended credit allocation ✨
7.4.4 Procedures for Connection Establishment Phase 🤝
The following features pertain to connection establishment for Class 4 💖
- In Class 4, a connection is not considered established until the successful completion of a 3-way TPDU exchange. The sender of a CR TPDU must respond to the corresponding CC TPDU by immediately sending a DT, ED or AK TPDU.
- As a result of duplication, 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, the receiving transport entity should ignore such a TPDU. Otherwise a CC TPDU should be transmitted.
- 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 should ignore such a CC TPDU.
- A CC TPDU may be received specifying a reference which is in the frozen state. The response to such a TPDU should be a DR TPDU.
7.4.4.1 Connection Request 📨
When a transport entity transmits a CR TPDU it starts timer T1. If this timer expires before a CC TPDU is received, the CR TPDU is retransmitted and the timer restarted. After transmission of the CR TPDU N times, the connection establishment procedure is abandoned and the failure reported to the transport user. The reference must be placed in the frozen state for a period L (see section 7.4.3.6) 🧊
7.4.4.2 Incomimg Connection Request 📥
An incoming connection request is processed as for Class 3 💅
7.4.4.3 Connection Confirm ✅
When a transport entity transmits a CC TPDU it starts timer T1. If this timer expires before an AK or DT TPDU is received, the CC TPDU is retransmitted according to the retransmission principles in Section 7.4.3.9 🔁
7.4.4.4 Incoming Connection Confirm 🎉
When a CC TPDU is received, the receiving transport entity enters the data transfer phase. It must immediately transmit an AK, ED or DT TPDU to complete the 3-way TPDU exchange. The CC TPDU is subject to the usual rules of the data transfer phase regarding retransmission, see Section 7.4.5.3 🫶
7.4.4.5 Incoming Acknowledgement 💌
When an AK, DT or ED TPDU is received the receiving transport entity can enter the data transfer phase. If the entity has data to send it may send DT TPDUs or an ED TPDU. The DT TPDUs are subject to flow control. Otherwise, the transport entity must obey the inactivity principles (see Section 7.4.5.8) 🌸
7.4.4.6 Unsuccessful Connection 🥀
When a DR TPDU is received in response to a CR TPDU, the timer T1 is cancelled and the reference placed in the frozen state for a period L (see Section 7.4.6.1) 🧊
7.4.4.7 Initial Credit Allocation 💳
The CR and CC TPDUs may allocate an initial credit value to their respective recipients. This value is limited to 15 by the encoding of the TPDU. Where the extended header format is in use, credit values greater than 15 must be allocated using AK TPDUs 🍓
7.4.4.8 Exchange of Acknowledge Time ⏲️
A transport entity may transmit the value it intends to use for AL at connection establishment, as the 'Acknowledge Time' parameter in the CR or CC TPDU (depending on whether the transport entity is initiating or accepting the transport connection). If this parameter is present in a received CR or CC TPDU, the value of AR should be set accordingly. If this parameter is not present, AR may be assumed to be insignificant in comparison to E the typical maximum transit delay 🧚
7.4.5 Procedure for Data Transfer Phase 📦
7.4.5.1 Sequence Control 🧭
The receiving transport entity is responsible for maintaining the proper sequence of DT TPDUs. DT TPDUs received out of sequence must not be delivered to the TS-user until in-sequence TPDUs have also been received. AK TPDUs also contain information allowing the receiving transport entity to process them in the correct order 👑
7.4.5.2 Duplicate DT TPDUs 👯
Duplicate TPDUs can be detected because the T(S) value matches that of previously received TPDUs. T(S) values must 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 must 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 should be ignored 🙈
7.4.5.3 Retransmission Principles 🔄
When a transport entity has some outstanding DT or ED TPDUs that require acknowledgement, it will check that no T1 interval elapses without the arrival of an AK or EA TPDU that acknowledges one of them. If the timer expires, the first TPDU is retransmitted and the timer is restarted. After N transmissions (N-1 retransmissions) the connection is assumed to have failed and the release phase is entered, and the transport user is informed 💀
DT TPDUs which fall beyond the current window (due to reduction of the upper window edge) are not retransmitted until advancement of the upper window edge so permits 🦋
Note: This requirement can be met by different means, for example.
- One timer is associated with each TPDU. If the timer expires, the associated TPDU will be retransmitted, and the timer T1 will be restarted for all subsequent DT TPDUs.
- One timer is associated with each TC:
- if the transport entity transmits a DT TPDU requiring acknowledgement, it starts timer T1,
- if the transport entity receives a TPDU that acknowledges one of the TPDUs to be acknowledged, timer T1 is restarted,
- if the transport entity receives a TPDU that acknowledges the last TPDU to be acknowledged, timer T1 is stopped.
For the decision whether the retransmission timer T1 is maintained on a per TPDU or on a per TC basis, throughput considerations have to be taken into account 🧠
7.4.5.4 Acknowledgement Principles ✅
A transport entity operating class 4 must acknowledge all TPDUs received requiring acknowledgment. To avoid unnecessary retransmissions and to avoid delays to transmission by the remote transport entity, the delay for acknowledgement should not exceed timer A_L (see Section 7.4.3.2) ⏰
There are two TPDU types that must be acknowledged: ED and DT. Receipt of an ED TPDU must be acknowledged by an EA TPDU. A DT TPDU is acknowledged with an AK TPDU 💌
An AK TPDU has the sequence number of the next DT TPDU the receiving transport entity expects to receive. It thus acknowledges receipt of all DT TPDUs with sequence numbers less than the acknowledgement number 🎯
An AK TPDU may be repeated at any time, using the sequence number in the last AK TPDU sent 🔂
7.4.5.5 Flow Control Principles 🌊
Flow control in Class 4 is subject to the same principles as in Classes 2 and 3. The credit mechanism and window principle of those classes still apply, except that in class 4, the upper window edge can be reduced by the receiving transport entity by sending an AK TPDU with a smaller credit 🛟
A receiving transport entity may send an AK TPDU at any time to change the window size. This AK TPDU may acknowledge a new DT TPDU or may repeat a previous acknowledgement 🌷
7.4.5.6 Window Synchronization Principles 🪟🔁
To keep flow control information in sync, the window timer makes AK TPDUs get swapped out super often, like, a LOT, so
TPDUs between transport entities. The window timer keeps a minimum level of TPDU traffic flowing between the transport entities cooperating in a transport connection 💖 It's basically the heartbeat that stops the chat from going silent 🫶
In Class 4 the window size can be reduced in any AK TPDU ✨ AK TPDUs can get misordered, and that wrecks efficiency 😭 so the AK TPDU for class 4 gets an extra field called the AK TPDU subsequence parameter 🎀
An AK TPDU SHOULD contain the subsequence parameter whenever a duplicate AK TPDU is sent with the same sequence number but reduced credit 💅 The subsequence parameter is set to one the first time the AK TPDU is resent with reduced credit.
When an AK TPDU goes out with an increased sequence number, the sub-sequence parameter gets left off until credit reduction actually happens 🦋
When an AK TPDU comes in, it MUST be processed (aka its contents actually get used) ONLY if one of these is true 👑
- The sequence number is greater than in any previously received AK TPDU, or,
- The sequence number equals the highest in any previously received AK TPDU, and the sub-sequence parameter is greater than in any previously received AK TPDU with that same sequence number (a missing sub-sequence parameter counts as zero), or,
- The sequence number and sub-sequence parameter are both equal to the highest in any previously received AK TPDU (a missing one counts as zero), and the credit field is greater than in any previously received AK TPDU with that same sequence and sub-sequence numbers.
When an AK TPDU is sent that opens a closed window (aka credit goes up from zero), it SHOULD be retransmitted at an interval of T1 🌸 Transmission SHOULD happen a maximum of N times, after which the usual inactivity retransmission timer SHOULD be reverted to. Retransmission MAY also stop if the local transport entity becomes sure that the new credit info has been received by the remote transport entity 🙌
If a transport entity receives an AK TPDU containing a Flow Control Confirmation parameter, and its Lower Window Edge and Your-Sub-Sequence fields match its own lower window edge and sub-sequence number, it MAY note that the credit available at the remote transport entity (relative to the Lower Window Edge field) is at least equal to the value conveyed as Your Credit ✨ This lets the transport entity stop the constant retransmitting of window info, if it knows the remote window is already open 🧚
A transport entity need not retransmit window information (except as described under Inactivity Principles) if it can tell from receiving DT TPDUs that the remote transport entity has enough credit to prevent deadlock 🍓 When an AK TPDU is sent in response to a DT TPDU, the transport entity MAY normally assume that the sender of the DT TPDU will make sure the AK TPDU gets received, by retransmitting the DT TPDU if needed 💜 So it can usually be assumed that the credit in that AK TPDU is available to the remote transport entity, and frequent retransmission is unnecessary 😌
That assumption can break if credit reduction has happened 😬 So a transport entity may not make this assumption if the sequence number of the DT TPDU is less than or equal to the highest value for which permission to transmit (aka credit) has been given and then withdrawn.
Upon receipt of an AK TPDU that increases the upper window edge, a transport entity MAY transmit an AK TPDU that repeats the information from the received TPDU in a Flow Control Confirmation parameter in its variable part 🦋 This assures the sender of the original AK TPDU of its own state. Such an AK TPDU MAY be transmitted:
- Upon receipt of a duplicated AK TPDU (one that is identical in all fields, including the sub-sequence parameter if present, to the most recently received AK TPDU that wasn't discarded due to detection of a sequence error), not containing the
Flow Control Confirmationparameter. - Upon receipt of an AK TPDU that increases the upper window edge but does not increase the lower window edge, when the upper window edge was formerly equal to the lower window edge.
7.4.5.7 Procedure for Expedited Data
The procedure for expedited data is the same as for Class 3, with the following exceptions 🎀
The ED TPDU has a sequence number allocated from a separate sequence space from the DT TPDUs. The EA TPDU carries the same sequence number as the matching ED TPDU. Only a single ED TPDU MAY be transmitted and awaiting acknowledgements at any time 🔥
Upon receipt of an unduplicated ED TPDU, a transport entity immediately forwards the data to the transport user 🚀 The ED TPDU sequence number is recorded in an EA TPDU sent back to the other transport entity.
The sender of an ED TPDU SHALL NOT send any new DT TPDU with higher T(S) until it receives the EA TPDU 🙈 This guarantees the ED TPDU arrives before any DT TPDUs sent after it. Iconic ✨
7.4.5.8 Inactivity Principles
If the Inactivity Time I passes without receipt of some TPDU, the transport entity will terminate the TC using the release procedure 💀 To prevent the remote transport entity's inactivity timers from expiring when no data is being sent, the local transport entity MUST send AK TPDUs at suitable intervals in the absence of data, taking the probability of TPDU loss into account 🫶 The Window Synchronization Principles (see 7.4.5.6) may ensure this requirement is met.
Note: It's likely that the release procedure started by inactivity timer expiration will fail, since that expiration points to a probable failure of the supporting NC or of the remote transport entity 😭 This case is described in Section 7.4.6.
7.4.6 Procedures for Release Phase
The rules for class 3 apply 💅 The DR TPDU is subject to the usual retransmission procedure. After N retransmissions, the transport connection is considered disconnected, the Reference is placed in the frozen state for a period L, and retransmission stops.
The DC TPDU is sent only in response to a DR TPDU, and is NOT subject to the retransmission procedure 🌈
When a DC TPDU is received, the transport entity can release all resources it was holding for the transport connection 🧹
The DR TPDU does not carry a sequence number 🦋 Any previously sent TPDUs (including DT and ED) that arrive after the DR TPDU trigger a further DR TPDU but are otherwise ignored. After disconnection, for whatever reason, the Reference is placed in the frozen state for a period L.
7.4.6.1 Unassigned Frozen References
When a transport connection is terminated, its references can't be reused right away, since TPDUs containing these references may still be floating around in the network for up to L 🧚 So these references get placed in an unassignable, frozen state for this period.
After an event that loses transport entity state information (including the status of reference assignments), all references tied to network connections whose transport state info was lost MUST be placed in the frozen state for a period L 😱
If a DC TPDU arrives for a local reference that is in the frozen state, or with a remote reference that doesn't match the one already recorded, this DC TPDU SHALL be ignored 🙅♀️
7.4.7 Treatment of Invalid TPDUs
The 'Treatment of Protocol Erorrs' function is used 🎀
7.4.8 Supported Options
- Non use of checksum.
- Use of extended formats.
8. ENCODING 🍓
8.1 Summary
Here's the big summary table, copied exactly as-is 💖
Classes
0 1 2 3 4 Sect. Code
CR Connection Request x x x x x 8.3 1110xxxx
CC Connection Confirm x x x x x 8.4 1101xxxx
DR Disconnect Request x x x x x 8.5 10000000
DC Disconnect Confirm x x x x 8.6 11000000
DT Data x x x x x 8.7 11110000
ED Expedited Data x NF x x 8.8 00010000
AK Data Acknowledgement NRC NF x x 8.9 0110xxxx
(Note 1)
EA Expedited Data x NF x x 8.10 00100000
Acknowledgement
RJ Reject (Note 1) x x 8.11 0101xxxx
ERR TPDU Error x x x x x 8.12 01110000
not available (Note 2) - 00000000
not available (Note 2) - 00110000
not available (Note 2) - 1001xxxx
not available (Note 2) - 1010xxxx
Where xxxx (bits 4-1) is used to signal the CDT
Note 1: In extended header format, the code for AK=0110 0000 and the
code for RJ=0101 0000.
Note 2: These codes are already in use in compatible protocols
defines by standards organizations other than CCITT/ISO.
NF: Not available when the non explicit flow control option is
selected.
NRC: Not available when the receipt confirmation option is
selected.8.2 Structure
As defined in the previous sections, all the Transport Protocol Data Units (TPDU) SHALL contain an integral number of octets 🧮 The octets in a TPDU are numbered starting from 1 and increasing in the order of transmission. The bits in an octet are numbered from 1 to 8, where bit 1 is the low-ordered bit.
There are two types of TPDUs 👑
- Data TPDUs, used to transfer Transport Service Data Units (TSDUs). The structure of the TSDUs is maintained by means of the TSDU End Mark.
- Control TPDUs, used to control the transport protocol functions, including the optional functions.
Here's how a TPDU is laid out 🎀
Octets 1 2 3 4 n n+1 p p+1
------------ -------------- -------------- --------
LI| | | | ... | | | .... | | | .... |
------------ -------------- -------------- --------
<--- Fixed Part -----><-- Variable Part->
(including checksum
where applicable)
<--------------Header-------------------><----Data Field->A TPDU is split into four parts 🦋
- Length Indicator Field (LI)
- Fixed Part
- Variable Part (MAY be omitted)
- Data Field (MAY be omitted)
The Length Indicator Field, Fixed Part and Variable Part together make up the Header of the TPDU 💜
8.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 (11111110). The length indicated is the header length, including parameters, but excluding the length indicator field and user data, if any. The value 255 (11111111) is reserved for possible extensions ✨
8.2.2 Fixed Part
The fixed part holds frequently occurring functions, including the code of the TPDU 🧚 The length and structure of the fixed part are defined by the TPDU code, which is set by bits 5 to 8 of the second octet of the header.
8.2.2.1 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
okay so the TPDU code is basically the rest of octet 2 and it's giving structured 🎀 this field is a full octet EXCEPT for these cases:
1110 xxxx Connecting Request
1101 xxxx Connection Confirm
0101 xxxx Reject
0110 xxxx Data Acknowledgementwhere xxxx (bits 4-1) is used to signal the CDT 🦋 any other bit pattern MAY be used to define a TPDU Code, but only the codes defined in Section 8.1 are currently valid. not me being picky, but that's the rule ✨
8.2.3 Variable Part
okay the variable part is where the optional extras live 🧚 it's used to define parameters relating to optional functions. if the variable part is present, it SHALL contain one or more parameters. the number of parameters that may be contained in the variable part is indicated by the length of the variable part, which is LI minus the length of the fixed part. literally just math 💅
since the currently defined minimum fixed part for headers that allow parameters is four octets, and the length indication field is capped at a maximum of 254, the maximum length of the variable part is 250 octets. so cute, the numbers all lock together 🌸
each parameter inside the variable part gets coded 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+msome bullet tea about each piece 🫶
- the parameter code field is binary and, without extensions, gives a max of 255 different parameters. BUT bits 8 and 7 indicate the source of definition, so the practical max is lower. and
1111 1111is reserved for possible extensions of the parameter code 👑 - the parameter length indication tells you how many octets the parameter value field is. it's a binary number, m, with a theoretical max of 255, but the practical max of m is lower. like, for a single parameter in the variable part, two octets are needed for the Parameter Code and the Parameter Length Indication itself, so m gets limited to 248. for bigger fixed parts of the header, and for each succeeding parameter, the max of m goes down 📉
- the parameter value field holds the value of the parameter named in the parameter code field 💜
- no standard parameter codes use bits 8 and 7 with the value 00 🙈
- implementations SHALL accept the parameters defined in the variable part in any order. and if any parameter is duplicated, the later value is the one that gets used 🦋
8.2.3.1 Checksum Parameter (Class 4 only)
all TPDU types MAY contain a checksum parameter in their variable part. this parameter MUST always be present except when the non use of checksum option is selected 🔥
Parameter Code: 1100 0011
Parameter Length: 2
Parameter Value: Result of checksum algorithm.
This algorithm is specified in
Section 6.18.8.2.4 Data Field
this field holds transparent user data 🍓 restrictions on its size are noted for each command, so check there bestie ✨
8.3 Connections Request (CR)
8.3.1 Structure
the CR is laid out like this, and yes it's a whole vibe 🌈
1 2 3 4 5 6 7 8 p p+1
LI CR CDT 00000000 00000000 SOURCE- class VARIABLE USER DATA
REFERENCE options PART8.3.2 LI
see Section 8.2.1 💖
8.3.3 Fixed Part (Octets 2 to 7)
the fixed part is octets 2 to 7, and each piece has its own job 🧚
CR: Connection Request Code:1110🎀CDT: Initial Credit Allocation (set to0000in Classes 0 and 1 when specified as preferred class) 🌸SOURCE REFERENCE: reference selected by the transport entity initiating the CR TPDU to identify the requested TC. it's the initiator's little name tag for the connection 🦋CLASSES: bits 8-5 of octet 7 define the preferred Transport Protocol class to be operated over the requested TC. this field may take on one of these values:
0000 Class 0
0001 Class 1
0010 Class 2
0011 Class 3
0100 Class 4the CR carries the first choice of class in the fixed part, like above. second and later choices go in the variable part if they're needed 💅
bits 4-1 of octet 7 are reserved for options to be used on the requested transport connection. here's how those bits work:
BIT OPTION
4 0 always
3 0 always
2 =0 use of normal formats
=1 use of extended formats
1 =0 use of explicit flow control
in Class 2
=1 no use of explicit flow
control in Class 2Note: 1. it is not valid to request 'use of expedited data transfer' (Additional option parameter) and no use of explicit flow control in Class 2' (bit 1 = 1). absolutely do not do this 💀 2. bits 4 to 1 are always zero in Class 0 and have no meaning 🙈
8.3.4 Variable Part (Octets 8 to p)
okay the CR's variable part is where the extra parameters go, and these are the ones that are permitted 💜
- Transport Service Access Point Identifier (TSAP-ID) 🌈 the Calling TSAP and the Called TSAP each get their own parameter code:
Parameter code 11000001 for the identifier of the Calling TSAP.
11000010 for the identifier of the Called TSAP.if a TSAP-ID is given in the request, it MAY be returned in the confirmation ✨
- 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 is:
Parameter Code 11000000
Parameter value field
00001101 8192 octets (not allowed in Class 0 of 1)
00001100 4096 octets (not allowed in Class 0 of 1)
00001011 2048 octets
00001010 1024 octets
00001001 512 octets
00001000 256 octets
00000111 128 octets
Default value is 00000111 (128 octets)- Version Number (not used in Class 0) 🎀
Parameter code 11000100
Parameter value field 00000001
Default value 00000001
Default value 00000001 (not used in Class 0)- Security Parameter (not used in Class 0) 🔐 this one is user defined, so the value and length field are user defined too 💖
Parameter code 11000101
Parameter value and length field are user defined- Checksum (not used in Classes 0 through 3) ✨ see Section 8.2.3.1. this parameter MUST 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 🔥
- Additional Option Selection (not used in Class 0) 🌸 this parameter defines whether or not additional options are to be used:
Parameter code 11000110
Parameter length: 1
Parameter value field:bits related to options particular to one class are not meaningful and MAY take any value in the other classes 🧚
BITS 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= Checksums are to be used in Class 4
1= Checksums are not to be used in Class 4
1 1= Use of transport expedited data transfer
service
0= No use of transport expedited data transfer
service
Default falue is 00000001- Alternative protocol class (not used in Class 0) 🦋
Parameter code 11000111
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). That's the whole vibe 💅✨
- Acknowledge Time ⏰
Okay so this one tells the remote transport entity the maximum acknowledge time AL 🦋. It's an indication only, so it's not up for negotiation (see section 7.4.5.3).
Parameter code: 10000101
Parameter Value field: n, a binary number (2 octets)
n is the maximum acknowledge time, expressed in milliseconds.
- Throughput 🌸
Parameter code: 10001001
Length : 12
1st 3 octets : Targer 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
directionValues are expressed in octets per second.
- Residual error rate 🍓
Parameter code: 10000110
Length : 3
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- Priority 👑
Parameter code: 10000111
Length : 2
Value : Integer- Transit delay 🧚
Parameter code: 10001000
Length : 8
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
directionValues are expressed in milliseconds.
8.3.5. User Data (Octets p+1 to the end) 🫶
No user data are permitted in class 0, and are OPTIONAL in the other classes. Where permitted, it may not exceed 32 octets.
8.4. Connection Confirm (CC) 🎀
8.4.1. Structure
1 2 3 4 5 6 7 8 p p+1
LI CC CDT DST-REF SOURCE-REF class VARIABLE USER DATA
1101 options Part8.4.2. LT
See Section 8.2.1.
8.4.3. Fixed Part (Octets 2 to 7)
- CC: Connection Confirm Code:
1101 - CDT: Initial Credit Allocation (set to
0000in Classes 0 and 1). - DST-REFERENCE: Reference identifying the requested transport connection at the remote transport entity.
- SOURCE REFERENCE: Reference selected by the transport entity initiating the CC TPDU to identify the confirmed TC.
- CLASSES: Defines the selected transport protocol class to be operated over the accepted TC according to the negotiation rules specified in Section 6.5.
8.4.4. Variable part (Octet 8 to p)
See Section 8.3.4
8.4.5. User Data (Octets p+1 to the end)
See Section 8.3.5
8.5. Disconnect Request (DR) 💅
8.5.1. Structure
LI DR DST-REF SOURCE-REF REASON VARIABLE USER DATA
10000000 PART8.5.2. LI
See Section 8.2.1
8.5.3. Fixed Part (Octets 2 to 7)
- DR: Disconnect Request Code:
1000 - DST-REFERENCE: Reference identifying the TC at the remote transport entity.
- SOURCE REFERENCE: Reference identifying the TC at the transport entity initiating the command. Value zero when reference is unassigned.
- REASON: Defines the reason for disconnecting the TC. This field SHALL take one of the following values:
The following values can be used for class 1 to 4:
128 + 0 - Normal disconnect
initiated by session entity.
128 + 1 - Remote transport entity
congestion at connect request time
*128 + 2 - Connection negotiation failed
(i.e. proposed class(es) not supported).
128 + 3 - Duplicated connection detected
128 + 4 - Mismatched references
128 + 5 - Protocol error
128 + 6 - Not used
128 + 7 - Reference overflow
128 + 8 - Connection request refused on this
network connection
128 + 9 - Not used
128 + 10 - Header or parameter length invalidThe following values can be used for all classes.
0 - Reason not specified
1 - Congested at TSAP
*2 Session entity not attached to TSAP
*3 Address unknownNote: Reasons marked with '*' MAY be reported to the TS-user as 'persistent', other reasons as 'transient'.
8.5.4. Variable Part (Octets 8 to 10)
- A parameter MAY be provided to allow additional information related to the clearing of the connection.
Parameter code: 11100000
Parameter Value Field: Additional information. This field is intended to be used by the transport service provider for internal purposes.
- Checksum (see 8.2.3.1)
8.5.5. User Data (Octets p+1 to the end)
Not allowed in class 0,
This field may not exceed 64 octets and is used to carry TS-User data. The successful transfer of this data is not guaranteed.
8.6. Disconnect Confirm (DC) ✨
(Not used in Class 0)
8.6.1. Structure
1 2 3 4 5 6 7 p
LI DST-REFERENCE SOURCE-REFERENCE Variable Part
110000008.6.2. LI
See Section 8.2.1
8.6.3. Fixed Part (Octets 2 to 6)
- DC: Disconnect Confirm Code:
1100 - DST-REFERENCE: See Section 8.3.3
- SOURCE-REFERENCE: See Section 8.4.3
8.6.4. Variable Part
Checksum (see 8.2.3.1)
8.7. Data (DT) 🔥
8.7.1. Structure
Normal Format for Class 0 to 1
1 2 3 4 5
LI DT E TPDU-NR User Data
11110000 0
TNormal format for Class 2, 3 and 4
1 2 3 4 5 6 p p+1
LI DST-REFERENCE E TPDU-NR Variable Part User Data
11110000 O
TExtended Format for OPTIONAL use in Classes 2,3 and 4
1 2 3 4 5,6,7,8 9 p p+1
LI DT DST-REFERENCE E TPDU-NR Variable User Data
11110000 O
T8.7.2. LI
Section 8.2.1
8.7.3. Fixed Part
(Classes 0 to 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)
- DT: Data Transfer Code:
1111 - DST-REFERENCE: See Section 8.4.3.
- EOT: When set to ONE, indicates that the current DT TPDU is the last Data Unit of a complete DT TPDU sequence (End of TSDU).
- TPDU-NR: TPDU Send Sequence Number (Zero in Class 0), MAY take any value in Class 2 without explicit flow control.
8.7.4. Variable Part
Checksum (See 8.2.3.1)
8.7.5. User Data Field
This field contains data of the TSDU being transmitted. 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
And that's the whole data field, bestie 🎀
8.8 Expedited Data (ED) 🦋
Heads up: this one isn't used in Class 2 when the "no explicit flow control" option is selected 💅
8.8.1 Structure
Normal Format
1 2 3 4 EOT 5 6 p p + 1
LI ED DST-REFERENCE EDTPDU-NR Variable Part User Data
00010000 1. Extended Format
1 2 3 4 EOT 5,6,7,8 9 p p + 1
LI ED DST-REFERENCE EDTPDU-NR Variable Part User Data
00010000 1.8.8.2 LI
Check Section 8.2.1 for the LI details ✨
8.8.3 Fixed Part
(Octets 2 to 5, normal format: 2 to 8, extended format)
- ED: Expedited Data command code:
0001💖 - DST-REFERENCE: Same as Section 8.4.3
- ED TPDU-NR: Expedited TPDU identification number (Classes 1, 3, and 4; MAY take any value in Class 2). 🌈
8.8.4 Variable Part
Checksum (See 8.2.3.1)
8.8.5 User Data Field
This field contains an expedited TSDU. Up to 16 octets. 🍓
8.9 Data Acknowledgement (AK) 🌸
Not applicable 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.
Flow Control Confirmation (class 4 only - optionally used) 🫶
This parameter contains a copy of the information received in an AK TPDU, so the transmitter of the AK TPDU can be certain of the state of the receiving transport entity (See Section 7.4.5.6).
Parameter Code: 100001011
Parameter value field 64 bits, used as follows:
- Lower Window Edge (32 bits): Bit 32 is set to zero, bits 31 to 1 contain the YR-TU-NR value of the received AK TPDU. When normal format is in use, only the least significant seven bits (bits 1 to 7) 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 is in use, only the least significant four bits (bits 1 to 4) of this field are significant. ✨
8.10 Expedited Data Acknowledgement (EA) 🧚
(Not applicable for Class 0 and Class 2 when the no explicit flow control option is selected).
8.10.1 Structure
Normal Format
1 2 3 4 5 6 p
LI EA DST-REFERENCE . YR-TU-NR Variable Part
00100000 0. Extended Format
1 2 3 4 5,6,7,8 9 p
LI EA DST-REFERENCE . YR-TU-NR Variable Part
00100000 0.8.9.1 Structure
Normal Format
1 2 3 4 5 6 p
LI AK CDT DST-REFERENCE . YR-TU-NR Variable Part
0110 0. Extended Format
1 2 3 4 5,6,7,8 9,10 11 p
LI AK DST-REFERENCE . YR-TU-NR CDT Variable Part
01100000 0.8.9.2 LI
Check Section 8.2.1 for the LI details ✨
8.9.3 Fixed Part
(Octets 2 to 5, normal format: 2 to 10, extended format)
- AK: Acknowledgement command code:
0110💅 - CDT: Credit Value (set to 0 in class 1)
- DST-REFERENCE: Same as Section 8.4.3
- YR-TU-NR: Sequence number indicating the next expected DT TPDU number.
8.9.4 Variable Part
Checksum (See 8.2.3.1)
Sub-sequence number (class 4 only - optionally used).
This parameter makes sure AK TPDUs get processed in the correct sequence. If it's absent, that's the same as sending the parameter with a value of zero. 🎀
Parameter Code: 100001010
Parameter Value: 16-bit sub-sequence number.
8.10.2 LI
Check Section 8.2.1 for the LI details ✨
8.10.3 Fixed Part
(Octets 2 to 5, normal format; 2 to 8, extended format)
- EA: Acknowledgement command code:
0010🦋 - DST-REFERENCE: Same as Section 8.4.3
- YR-TU-NR: Identification of the ED TPDU being acknowledged. MAY take any value in Class 2.
8.10.4 Variable Part
Checksum (See 8.2.3.1)
8.11 Reject (RJ) 🌷
(Not used in Classes 0, 2, and 4)
8.11.1 Structure
Normal Format
1 2 3 4 EOT 5 6 p
LI RJ CDT DST-REFERENCE . YR-TU-NR Variable Part
0101 0. Extended Format
1 2 3 4 EOT 5,6,7,8 9,10 11 p
LI RJ DST-REFERENCE . YR-TU-NR CDT Variable
0l0l0000 Part8.11.2 LI
Check Section 8.2.1 for the LI details ✨
8.11.3 Fixed Part
(Octets 2 to 5, normal format; 2 to 10, extended format)
- RJ: Reject Command Code:
0101 - CDT: Credit Value (set to 0 in class 1)
- DST-REFERENCE: Same as Section 8.4.3
- YR-TU-NR: Sequence number indicating the next expected TPDU from which retransmission SHOULD occur. 🍓
8.11.4 Variable Part
No parameters exclusive to this TPDU type.
8.12 TPDU Error (ERR) 🚨
1 2 3 4 5 6
LI ERR DST-REFERENCE Reject Parameters
01110000 Cause8.12.1 LI
Check Section 8.2.1 for the LI details ✨
8.12.2 Fixed Part
- ERR: TPDU Error Code:
0111 - DST-REFERENCE: Same as Section 8.4.3
- REJECT CAUSE:
00000000 Reason not specified
00000001 Invalid parameter code
00000010 Invalid TPDU type
00000011 Invalid parameter value8.12.3 Variable Part (Octets 6 to the end)
Parameter Code: 1100001
Parameter Value Field:
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. 💀
Checksum (See Section 8.2.3.1)
SECTION THREE - CONFORMANCE 🎀
9. CONFORMANCE ✨
Implementations claiming conformance to this standard SHALL:
- Implement either Class 0 or Class 2 or both.
- If other classes are implemented, the following rules SHALL be observed:
- a) If Class 3 or Class 4 is implemented then Class 2 MUST be implemented.
- b) If Class 1 is implemented then Class 0 MUST be implemented.
- The following table defines the requirements for the implementation of the options defined in previous sections:
Class
0 1 2 3 4
TPDU with Checksum no no no no m
TPDU without Checksum m m m m o
Expedited Data Transfer no m m m m
No Expedited Data Transfer m m m m m
Flow Control in Class 2 no no m no no
No Flow Control in Class 2 no no o no no
7 bits format (normal) m m m m m
31 bits format (extended) no no o o o
Use of Receipt Confirmation in no o no no no
Class 1
No use of Receipt Confirmation in no m no no no
Class 1
Use of Network Expedited in Class no o no no no
1, if T-EXPEDITED DATA necessary
No use of Network Expedited in no m no no no
Class 1, if T-EXPEDITED DATA necessary
o - optional: An implementation may or may not
provide this user-selected option.
m - mandatory: An implementation must provide for this
option
no - An implementation shall not provide
this option.- Implementations claiming conformance SHALL support a TPDU length of 128 octets. If larger maximum TPDU sizes can be supported in Classes 1,2,3, or 4, then all permitted TPDU sizes between the maximum and 128 octets SHALL be supported. 🌈
- Claims of conformance SHALL state:
- a) which class of protocol is supported.
- b) which additional options indicated by the letter 'o' in the above table are supported.
📦 where this page comes from
- ietf: rfc892 1983-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms