RFC 2126
ISO Transport Service on top of TCP (ITOT)
RFC 2126: ISO Transport Service on top of TCP (ITOT) 🎀
- Network Working Group 🌸
- Request for Comments: 2126 💖
- Authors: Y. Pouffary (Digital Equipment Corporation) and A. Young (ISODE Consortium) 👑
- Category: Standards Track ✨
- Date: March 1997 📅
- Obsoletes / Updates: The header doesn't list any RFCs here. The Abstract says this is a revision of RFC1006 that will eventually supersede it 🦋
Status of the Memo
okay so this is a standards track protocol for the whole Internet community 🌐 and it's literally asking for discussion and suggestions 🫶 Check the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol 📋 And distribution of this memo is unlimited, so share away 🦋
Abstract
this doc is a revision to STD35, RFC1006, which was written by Marshall T. Rose and Dwight E. Cass 💅 Since RFC1006 dropped in May 1987, people have gotten SO much experience running ISO transport services on top of TCP 🔥 This document refines the protocol and will eventually supersede RFC1006 👑
it describes how ISO Transport Services can run over TCP over IPv4 or IPv6 🌈 It also adds a bunch of new features that RFC1006 never had ✨
the goal of this version is to minimise the number of changes to RFC1006 and ISO 8073 transport protocol definitions 🎀 while maximising performance, extending its applicability, and protecting the installed base of RFC1006 users 🫶
Table of Contents
1. Introduction, Motivation.....................................2
2. The Model....................................................3
2.1 ISO Transport Model.........................................3
2.2 ISO Transport over TCP (ITOT) Model.........................4
2.3 Overview of Protocol and Service............................5
3 Service Definition............................................5
3.1 Transport Service Definition................................5
3.1.1 Transport Service Definition Primitives...................6
3.2 Network Service Definition..................................7
3.2.1 ISO 8348 CONS primitives..................................7
3.2.2 TCP Service primitives....................................8
3.2.3 Mapping TCP as a Network Service Provider.................8
3.2.3.1 Network Connection Establishment........................8
3.2.3.2 Network Data Transfer...................................9
3.2.3.3 Network Connection Release.............................10
4. Transport Protocol Specification............................10
4.1 Class 0 over TCP...........................................10
4.1.1 Connection Establishment.................................11
4.1.2 Data Transfer............................................11
4.1.3 Connection Release.......................................11
4.2 Class 2 over TCP...........................................12
4.2.1 Connection Establishment.................................12
4.2.2 Data Transfer............................................13
4.2.3 Connection Release.......................................15
4.3 TPKT Packet Format.........................................15
5. Address representations.....................................16
5.1 String representation of ITOT access point addresses.......17
5.2 OSI Network Address encoding...............................17
6. Notes to Implementors.......................................17
6.1 TCP Connection Establishment...............................17
6.2 TCP Data transfer..........................................17
6.3 Class negotiation..........................................18
6.4 Default maximum TPDU size..................................18
6.5 Class 0 TPDU bit encoding..................................18
6.6 Class 2 Options............................................19
6.7 Class 2 Expedited Data Acknowledgement.....................21
6.8 Class 2 Normal Data and Expedited Data handling............21
6.9 Class 2 Forward Connection procedure.......................22
6.10 TPKT......................................................22
7. Rationale - Interoperability with RFC1006...................22
8. Security Considerations.....................................23
Acknowledgements...............................................23
References.....................................................23
Authors' Addresses.............................................251. Introduction, Motivation ✨
okay so there are two main ways to "port" ISO applications to TCP/IP ([RFC793],[RFC791]) and IPv6 [IPV6] environments 🧚 Approach one is to port each application separately and build local protocols on top of TCP 😩 Approach two is layering the ISO Transport Service over TCP/IP, which solves the problem for every application that uses the ISO Transport Service at once 🔥 This document is all about approach two 💅
the protocol here is built on the fact that both the Internet Protocol Suite and the ISO Protocol Suite are layered systems 🌸 A big idea behind layering is layer-independence 🎀 It means that if a layer keeps the services it offers (the Service-Provider), then the Service-User at that layer is completely unaffected by changes in the layers underneath, or by the protocol used inside that layer 👑
this document defines a Transport Service that looks identical to the Services and Interfaces in the ISO Transport Service Definition [ISO8072] 🦋 but under the hood it actually runs the ISO Transport Protocol [ISO8073] on top of TCP/IP (IPv4 or IPv6), instead of the ISO Network Service [ISO8348] 🫶
the basis of this document is STD35, RFC1006 [RFC1006], written by Marshall T. Rose and Dwight E. Cass 🌈 It defines two transport classes of service. Transport Class 0 refines and supersedes the RFC1006 protocol and is aimed at preserving the RFC1006 installed base 💖 Transport Class 2 adds a bunch of new features RFC1006 doesn't have, like independence of Normal and Expedited Data channels and Explicit Transport Disconnection ✨ These new features are mostly based on RFC1859 [RFC1859], and they extend the applicability of RFC1006 to new groups of applications 🚀
this document specifies changes to the standards mentioned above, and it must be read in the context of those standards 📚 It won't make sense on its own 🙈
the 'well known' TCP port 102 is reserved for hosts that implement the Protocol described in this document 🎀 Just note that the Protocol does not mandate the use of TCP port 102 for all connections 💅
2. The Model 🦋
this section is all about how the model used by the ISO Transport differs from the one described in this document 🌸
2.1 ISO Transport Model
okay so ISO 8072 describes the ISO Transport Service Definition (TS) 📋 It spells out the services the Transport Service Provider offers, plus the interfaces used to access those services 💅
ISO 8073 describes the ISO Transport Protocol Specification (TP) 🔥 The ISO Transport Protocol defines common encoding rules and a number of transport protocol classes that can be used with different network Quality of Service 🌈
ISO 8348 describes the ISO Network Service Definition (NS) 🫶 It spells out the services the network service Provider offers, plus the interfaces used to access them 🧚
the ISO Network Service comes in two types:
- Connection Oriented Network Service (CONS)
- ConnectionLess Network Service (CLNS)
the ISO Transport Protocol has five classes of procedures for operating over CONS, and one class for operating over CLNS 💖
here's how these ISO standards relate to each other 👇
Transport Service User
|
|-ISO Transport Service Definition [ISO8072]
|
+--------------------------------------------------+
| Transport Service Provider |
| ISO Transport Protocol Specification [ISO8073] |
+--------------------------------------------------+
|
|-ISO Network Service Definition [ISO8348]
|2.2 ISO Transport over TCP (ITOT) Model
this document defines a model that provides the ISO Transport Service, with minor extensions, running over TCP ✨
the ISO 8072 Transport Service is supported with minor modifications 💅 See section 3.1 🎀
the ISO 8073 Transport Protocol, with some modifications, is used to provide the modified Transport Service 🌸
the Transmission Control Protocol is used in place of ISO 8348 to provide a CONS-like service 🦋 See section 4 👑
this document specifies a simple encapsulation mechanism between the modified ISO 8073 Transport Protocol and TCP 🫶
ISO 8073 specifies five classes when operating over ISO 8348 CONS 🌈 This document specifies how to operate classes 0 and 2 over TCP 💖 It doesn't stop other classes from running over TCP, but specifying those is beyond the scope of this document 🧚
here's the relationship between these standards 👇
Transport Service User
|
|-ISO Transport Service (modified)
|
+--------------------------------------------------+
| Transport Service Provider |
| ISO Transport Protocol (modified) Specification |
+--------------------------------------------------+
|
|-TCP as a Connection Oriented Network Service
|2.3 Overview of Protocol and Service 🌟
this document uses the ISO Transport Protocol (with some extensions) running over TCP 🎀 Two variants are defined, "Class 0 over TCP" and "Class 2 over TCP", which are based closely on the ISO Transport Class 0 and 2 Protocol 💅
Section 3 defines the Service offered to the Transport User by this protocol, and shows how it differs from the ISO Transport Service ✨ It also defines the mapping between the ISO Network Service primitives and TCP 🦋 Section 4 defines the Transport Protocol 🫶
3 Service Definition 💜
this section describes the Transport Service offered to the Transport User 🌸 It also defines the mapping between the Network Service Definition and the TCP Service Definition 👑
3.1 Transport Service Definition
ISO 8072 Transport Service is supported with the following extensions 🔥
- Use of Quality of Service parameter is not defined
- Access to Non-disruptive Transport Disconnection
3.1.1 Transport Service Definition Primitives 💖
okay so this is where info actually moves to and from the TS-User 🎀 using these Transport Service primitives:
Actions (the stuff the TS-User does 💅)
T-CONNECT.REQUEST: a TS-User says it wants to set up a transport connection ✨T-CONNECT.RESPONSE: a TS-User says it will honour the request 🫶T-DISCONNECT.REQUEST: a TS-User says the transport connection is to be closed 👋T-DATA.REQUEST: a TS-User sends data 📨T-EXPEDITED DATA.REQUEST: a TS-User sends "expedited" data 🔥
Events (the stuff the TS-User gets told 👀)
T-CONNECT.INDICATION: a TS-User is notified that a transport connection establishment is in progress 🧚T-CONNECT.CONFIRMATION: a TS-User is notified that the transport connection has been established 🥳T-DISCONNECT.INDICATION: a TS-User is notified that the transport connection is closed 💀T-DATA.INDICATION: a TS-User is notified that data can be read from the transport connection 📖T-EXPEDITED_DATA.INDICATION: a TS-User is notified that expedited data can be read from the transport connection ⭐
3.2 Network Service Definition 🌸
this section explains how TCP gets used to provide ISO 8348 CONS, so pay attention, it's the glue 🧠
3.2.1 ISO 8348 CONS primitives 🍓
info moves to and from the NS-provider through these Network Service primitives:
Actions
N-CONNECT.REQUEST: an NS-user says it wants to set up a network connection 🌈N-CONNECT.RESPONSE: an NS-user says it will honour the request 💅N-DISCONNECT.REQUEST: an NS-user says the network connection is to be closed 👋N-DATA.REQUEST: an NS-user sends data 📨N-EXPEDITED_DATA.REQUEST: an NS-user sends "expedited" data 🔥
Events
N-CONNECT.INDICATION: an NS-user is notified that a network connection establishment is in progress 🧚N-CONNECT.CONFIRMATION: an NS-user is notified that the network connection has been established 🥳N-DISCONNECT.INDICATION: an NS-user is notified that the network connection is closed 💀N-DATA.INDICATION: an NS-user is notified that data can be read from the network connection 📖N-EXPEDITED_DATA.INDICATION: an NS-user is notified that expedited data can be read from the connection ⭐
3.2.2 TCP Service primitives 🦋
so the mapping between ISO 8348 CONS primitives and TCP Service primitives (defined in this doc) assumes that TCP offers these service primitives. iykyk 🙈
Actions
TCP-LISTEN_PORT: PASSIVE open on given port 👂TCP-OPEN_PORT: ACTIVE open to the given port 📞TCP-READ_DATA: data is read from the connection 📖TCP-SEND_DATA: data is sent on the connection 📤TCP-CLOSE: the connection is closed (pending data is sent) 🧹
Events
TCP-CONNECTED: open succeeded (either ACTIVE or PASSIVE) 🎉TCP-CONNECT_FAIL: ACTIVE open failed 😭TCP-DATA_READY: data can be read from the connection 📬TCP-ERRORED: the connection has errored and is now closed 🚨TCP-CLOSED: an orderly disconnection has started 👋
3.2.3 Mapping TCP as a Network Service Provider 🎀
3.2.3.1 Network Connection Establishment 💫
to perform an N-CONNECT.REQUEST action, the TS-Provider does a TCP-OPEN_PORT to the desired IPv4 or IPv6 address using the selected TCP port. when TCP signals success or failure, that results in an N-CONNECT.INDICATION action. literally that simple 🙌
to await an N-CONNECT.INDICATION event, a server does a TCP-LISTEN_PORT to the selected TCP port. when a client successfully connects to this port, the TCP-CONNECTED event occurs and an implicit N-CONNECT.RESPONSE action is performed 🫶
the mapping of parameters between the TCP service and the ISO 8348 CONS service goes like this:
Network Service TCP
--------------- ---
CONNECTION ESTABLISHMENT
Called address server's IPv4 or IPv6 address
and TCP port number.
Calling address client's IPv4 or IPv6 address
all others parameters ignoredplease also refer to 'Notes to Implementors' section 6.1 📝
TCP port 102 is reserved for implementations conforming to this specification. use of any TCP port is conformant to this specification too 🌈
3.2.3.2 Network Data Transfer 📦
to perform an N-DATA.REQUEST action, the TS-provider builds the desired transport protocol data unit (TPDU), wraps the TPDU in a discrete unit called TPKT, and uses the TCP-SEND_DATA primitive 📤 please also refer to 'Notes to Implementors' section 6.2 📝
to trigger an N-DATA.INDICATION action, TCP indicates that data is ready through the TCP-DATA_READY event, and a TPKT gets read using the TCP-READ_DATA primitive 📖
the mapping of parameters goes like this:
Network Service TCP
--------------- ---
DATA TRANSFER
NS User Data (NSDU) DATA3.2.3.3 Network Connection Release 👋
to perform an N-DISCONNECT.REQUEST action, the TS-provider just closes the TCP connection through the TCP-CLOSE primitive. simple 💅
to trigger an N-DISCONNECT.INDICATION, TCP indicates that the connection has been closed through the TCP-CLOSE event. if the TCP connection has failed, TCP indicates that the connection has been closed through the TCP-ERRORED event, and this triggers an N-DISCONNECT.INDICATION 💀
the mapping of parameters goes like this:
Network Service TCP
--------------- ---
CONNECTION RELEASE
all parameters ignored4. Transport Protocol Specification 👑
okay this is the big one, bestie 😭 ISO 8073 Transport Protocol Classes 0 and 2 are supported, with extensions defined in each subsection below ✨
a Transport Protocol class gets selected for a particular transport connection based on what the TS-User needs 🎯
ISO 8073 Transport Protocol swaps info between peers in discrete units called transport protocol data units (TPDUs). this protocol wraps those TPDUs in discrete units called Packets (TPKT) 📦
this document mandates implementing ISO 8073 Transport Protocol options negotiation, which includes class negotiation 🔒
please check 'Notes to Implementors' section 6.3 for class negotiation, and the 'Rationale' section 7. for interoperability with RFC1006 🧠
4.1 Class 0 over TCP 🦋
Class 0 gives you the functions needed for connection establishment with negotiation, data transfer with segmentation, and protocol error reporting. it provides a Transport Connection with flow control based on that of the NS-provider (TCP). and it provides Transport Disconnection based on the NS-provider Disconnection 💅
Class 0 is suitable for data transfer with no Explicit Transport Disconnection 🌸
4.1.1 Connection Establishment 🤝
the principles used in connection establishment are based on what's described in ISO 8073, with these extensions:
- Connect Data may be exchanged using the user data fields of Connect Request (CR) and Connect Confirm (CC) TPDUs 📨
- Use of "Expedited Data Transfer Service" may be negotiated using the negotiation mechanism specified in ISO 8073. the default is to not use "Expedited Data Transfer Service" 🔥
- Non-standard TPDU size may be negotiated using the negotiation mechanism specified in ISO 8073. the maximum TPDU size is 65531 octets. the Default maximum TPDU size is 65531 octets too. please refer to 'Notes to Implementors' section 6.4 📏
4.1.2 Data Transfer 📦
the elements of procedure used during transfer are based on those presented in ISO 8073, with this extension:
- Expedited Data may be supported (if negotiated during connection establishment) by sending the defined Expedited Data (ED) TPDU 🔥
the ED TPDU is sent inband on the same TCP connection as all of the other TPDUs 🛣️
to support Expedited Data, a non-standard TPDU is defined. the format used for the ED TPDU is nearly identical to the format for the Normal Data (DT) TPDU. the only difference is that the value used for the TPDU code is ED and not DT. the size of an Expedited Data user data field is 1 to 16 octets 🧩
for TPDU bit encoding, please refer to 'Notes to Implementors' section 6.5 📝
4.1.3 Connection Release 👋
the elements of procedure used during a connection release are identical to those presented in ISO 8073 ✨
Transport Disconnection is based on the NS-provider (TCP) Disconnection, and is therefore disruptive 💥
4.2 Class 2 over TCP 🌈
Class 2 gives you the functions needed for connection establishment with negotiation, data transfer with segmentation, and protocol error reporting. it provides a Transport Connection with flow control based on that of the NS-provider (TCP). and it provides Explicit Transport Disconnection 💖
Class 2 is suitable when independence of Normal and Expedited Data channels is required, or when Explicit Transport Disconnection is needed 🫶
4.2.1. Connection Establishment ✨
okay so connection establishment is based on ISO 8073, but with some extra glow-ups 💅 here's what changes:
- Transport Expedited Data Transfer 🚀 Connection Request and Connection Confirmation TPDUs may negotiate use of the "Transport Expedited Data Transfer" service. You select it by setting bit 1 of the "Additional Option" parameter, and it's negotiated with the mechanism from ISO 8073.
The default is to not use "Transport Expedited Data Transfer Service" 🙈
- Expedited Data Acknowledgement 🫶 Connection Request and Connection Confirmation TPDUs may also negotiate "Expedited Data Acknowledgement". You select it by setting bit 6 of the "Additional Option" parameter, and it goes through the ISO 8073 negotiation too.
The default is to not use "Expedited Data Acknowledgement" for Expedited Data transfer.
- Non-blocking Expedited Data 🌊 Connection Request and Connection Confirmation TPDUs may negotiate the "Non-blocking Expedited Data" service. You select it by setting bit 7 of the "Additional Option" parameter, using the ISO 8073 mechanism.
The default is to not use the "Non-blocking Expedited Data" service.
- Forward or Reverse Connection 🔀 Connection Request and Connection Confirmation TPDUs may negotiate either the "Forward Connection (Splitting and Recombining)" procedure or the "Reverse Connection" procedure for Expedited Data transfer.
Picking "Forward Connection" or "Reverse Connection" happens by setting bit 4 of the "Additional Option" parameter, and it's negotiated with the ISO 8073 mechanism.
The default is the "Forward Connection" procedure for Expedited Data transfer.
- Explicit Flow Control 🚫 Connection Request and Connection Confirmation TPDUs must not negotiate the use of "Explicit Flow Control". bestie, that one's a hard no 💀
- TPDU size 📦 A non-standard TPDU size may be negotiated using the ISO 8073 negotiation mechanism. The maximum TPDU size is 65531 octets, and the default maximum TPDU size is also 65531 octets. For the details, check 'Notes to Implementors' section 6.4.
Without a Flow Control policy, using the ISO 8073 Multiplexing procedure leads to a drop in quality of service 😭 So this protocol doesn't support Multiplexing at all. Not lowkey, not highkey, just no.
For the values of the "Additional Option" parameter, see 'Notes to Implementors' section 6.6.
For the Class 2 options Profile, also see 'Notes to Implementors' section 6.6.
4.2.2. Data Transfer 📨
The elements of procedure used during transfer are based on ISO 8073, with these upgrades:
- Expedited Data 💥 If it was negotiated during connection establishment, Expedited Data may be supported by sending an Expedited Data (ED) TPDU.
- Expedited Data Acknowledgement 🧾 If it was negotiated during connection establishment, "Expedited Data Acknowledgement" may be supported by sending an Expedited Data Acknowledgement (EA) TPDU.
When you're using "Expedited Data Acknowledgement", ED TPDUs need an acknowledgement. Once an ED TPDU is sent, no further DT/ED TPDUs may be sent until that outstanding ED TPDU has been acknowledged. It's a wait-your-turn situation 🙃
When non-use of "Expedited Data Acknowledgement" has been negotiated, ED TPDUs need no acknowledgement, and further DT/ED TPDUs may be sent immediately. Fast lane, let's go 🏎️
Check 'Notes to Implementors' section 6.7 and section 6.8.
- Non-blocking Expedited Data 🌀 If it was negotiated during connection establishment, the "Non-blocking Expedited Data" service may be supported.
When you're using this service, the sender of an ED TPDU shall send the ED TPDU on both the Normal Data and Expedited Data TCP connections. Sending the next DT TPDU isn't interrupted. The receiver of the ED TPDU counts how many ED TPDUs it has seen on each TCP connection, and it'll only deliver the ED TPDU from the TCP connection with the higher count to the TS-User. Two copies, one winner 👑
When non-use of "Non-blocking Expedited Data" has been negotiated, ED TPDUs will not be duplicated.
Check 'Notes to Implementors' section 6.7 and section 6.8.
- Setting up the Expedited Data TCP connection 🧩 There are two possible procedures for establishing and assigning the Expedited Data TCP connection, and the one in use is negotiated during connection establishment.
Both the "Forward Connection" procedure and the "Reverse Connection" procedure keep the Expedited Data TCP connection independent of the Normal Data TCP connection. They also make sure a busy Normal Data TCP connection cannot block an Expedited Data TCP connection. Independence goals unlocked 🔓
The Expedited Data TCP connection, whichever procedure created it, must be between the same pair of hosts as the Normal Data TCP connection. It must not be shared among Transport Connections, and it must stay established until the Transport Connection is terminated, at which point it must be closed.
TCP connections created for Expedited Data transfer should also use the TCP primitives defined in this document.
The Forward Connection (Splitting and Recombining) procedure is defined in ISO 8073. It lets a transport connection use multiple TCP connections. See 'Notes to Implementors' section 6.9.
The Reverse Connection procedure is not defined in ISO 8073 🙃 With this one, the initiator of a Transport Connection creates a Normal Data TCP connection using an arbitrarily-chosen local TCP port 'x' and a known remote TCP port (either the ITOT well-known port, or some other one). The initiator then listens for an incoming TCP connection on TCP port 'x'. Before the responder can issue a CC TPDU on the Normal Data TCP connection, it must create a second TCP connection (to be used for Expedited Data) using an arbitrarily-chosen local TCP port 'y' and the remote TCP port 'x'. Once the Expedited Data TCP connection is established, the initiator doesn't need to keep listening for more TCP connections on port 'x'. Main character sequencing 🎬
4.2.3. Connection Release 👋
The elements of procedure for a connection release are based on ISO 8073. The TS-user can end a connection in one of two ways:
- Disruptive Disconnect 💣
- Non-Disruptive Disconnect 🫧
Disconnect Request (DR) and Disconnect Confirm (DC) TPDUs get exchanged in both cases. The DR TPDU carries a Reason code that explains why the Disconnection is happening.
A Disruptive Disconnect means that TPDUs still at the source don't have to be sent to the destination before the connection is disconnected. Its DR Reason code is normal (80 hex). Yeet, but make it protocol 😤
A Non-Disruptive Disconnect means that all TPDUs already given to the local TS-provider must be delivered to the remote TS-user before the connection is disconnected. Its DR Reason code is normal (80 hex), with the Additional Information parameter value set to 80 hex. Gentle goodbye, everything gets delivered first 🫶
4.3. TPKT Packet Format 📦
okay so the big difference between TCP and the ISO Network Service that ISO Transport expects is that TCP manages a continuous stream of octets, with no explicit boundaries 🌊
ISO Transport expects information to be sent and delivered as discrete objects called Network Service Data Units (NSDUs). ISO Transport does allow more than one TPDU inside a single NSDU, but for the purposes of this discussion, an NSDU is identical to a TPDU. For the valid set of concatenated TPDUs, see ISO 8073.
This protocol uses a simple packetization scheme to delimit TPDUs. Each packet (TPKT) is an object of variable length made up of an integral number of octets. 📏
A TPKT has two parts:
- a Packet Header
- a TPDU.
The Packet Header format stays the same no matter what type of TPDU you've got. It looks like this:
+--------+--------+----------------+-----------....---------------+
|version |reserved| packet length | TPDU |
+----------------------------------------------....---------------+
<8 bits> <8 bits> < 16 bits > < variable length >where:
- Protocol Version Number length: 8 bits Value: 3
- Reserved length: 8 bits Value: 0 - (see 'Notes to Implementors' section 6.10) 🙈
- Packet Length length: 16 bits Value: Length of the entire TPKT in octets, including Packet Header
- TPDU ISO Transport TPDU as defined in ISO 8073 and as defined in this document.
5. Address representations 🗺️
It's desirable to be able to represent ITOT access point addresses as:
- Printable strings
- OSI Network Addresses (often known as NSAP addresses or simply NSAPAs)
This section defines the formats which MUST be used in each case. Non-negotiable, bestie 🫶
5.1. String representation of ITOT access point addresses 🧵
[RFC1278] defines a general string representation for OSI Presentation Addresses, including specific reference to RFC1006 addresses that encapsulate IPv4 addresses. RFC1278 also applies to ITOT addresses that encapsulate IPv4 addresses.
This RFC is currently being updated to define a string representation for ITOT addresses that encapsulate IPv6 addresses. Stay tuned 👀
ITOT access point address string representations specify an IP address (IPv4 or IPv6) and an optional TCP port number. ✨
5.2. OSI Network Address encoding 🔢
[RFC1277] defines a general mechanism for encoding addressing information within OSI Network Addresses (NSAPAs), including specific reference to RFC1006 using IPv4. RFC1277 also applies to ITOT addresses using IPv4.
The RFC "IPv6 addresses inside an NSAPA" [IPv6] defines general mechanisms for supporting NSAP addressing in an IPv6 network. It also defines how to embed an IPv6 address inside an OSI NSAP address.
This RFC applies to ITOT addresses using IPv6. For ITOT addresses, the default selector of the NSAPA has the value '10000000'B.
Since an IPv6 address can encode IPv4 addresses, this format can also encode ITOT addresses using IPv4. Big brain move 🧠
6. Notes to Implementors 📝
6.1. TCP Connection Establishment 🔌
Implementors should know that ISO transport protocols assume they'll be told by the network service provider (in this case, TCP/IP) when the network connection carrying their TPDUs is unexpectedly terminated. So it's strongly suggested that the TCP keep alive mechanism be selected, because that's what makes sure network connection loss gets reported 🚨
6.2. TCP Data transfer 🚚
For performance reasons, it's suggested that the Nagle algorithm [RFC 896] be disabled (using the TCP_NODELAY socket option). This lets TPKT data get sent without delay ⚡
6.3. Class negotiation ✨
okay so class negotiation works the same way as in ISO 8073, bestie 💅 Class and options get negotiated during Connection establishment, and whatever the Transport picks depends on what the TS-User asked for through the T-CONNECT service primitives. literally the main character energy of setup 👑
The initiator of the Transport Connection proposes a preferred class and can also propose an alternative class 🦋
The responder then picks one class from the table below 🎀
If the responder doesn't pick the preferred class, the initiator adjusts its operation to match whatever class got selected once the connect confirm TPDU comes back 🫶
+---------------------------------------------+----------------------+
| Proposed in CR TPDU | CC TPDU |
| | |
|Preferred class | Alternative class | Response |
+--------------------+------------------------+----------------------+
| | | |
|class 0 | none | class 0 |
| | | |
|class 2 | class 0 | class 2 or 0 |
| | | |
|class 2 | none | class 2 |
| | | |
+---------------------------------------------+----------------------+6.4. Default maximum TPDU size 🌸
ngl this one is a little rule-breaker 🙈 The default maximum TPDU size in this document doesn't follow the ISO Transport negotiation rule. That rule says the maximum TPDU size specified or defaulted in the CC TPDU can't be bigger than the maximum TPDU size proposed in the CR TPDU.
So to avoid the mess that comes with this, it is STRONGLY RECOMMENDED that the CC TPDU always specifies the maximum TPDU size value 💖
6.5. Class 0 TPDU bit encoding 🧚
this protocol no longer lets the credit and TPDU-NR fields (bits 0 to 6) get ignored on input, which lines up with the ISO 8073 encoding rules ✨ RFC1006 TPDU encoding had inconsistent encoding rules, so this is a glow-up 💅
6.6. Class 2 Options 🍓
Class 2 Additional Option parameter value
+--------------------------------------------------------------------+
| BIT | OPTION |
+--------------------------------------------------------------------+
| | |
| 8 | Not applicable |
| | |
| 7 | = 1 Use of Non-blocking Expedited Data |
| | = 0 Non-use of Non-blocking Expedited Data (default) |
| | |
|(*) 6 | = 1 Use of Expedited Data Acknowledgement |
| | = 0 non-use of Expedited Data Acknowledgement (default) |
| | |
| 5 | Not applicable |
| | |
|(*) 4 | = 1 Use of Reverse Connection procedure |
| | = 0 Use of Forward Connection procedure (default) |
| | |
| 3 | Not applicable |
| | |
| 2 | Not applicable |
| | |
| 1 | = 1 Use of Transport Expedited Data Service |
| | = 0 Non-use of Transport Expedited Data Service (default) |
| | |
+--------------------------------------------------------------------+(*) quick lore: in ISO 8073, bit 4 means "Network Expedited" and bit 6 means "Request Acknowledgement" 🤓
Class 2 Options Profile
+--------------------------------------------------------------------+
| Bits Service selected |
| 1 4 6 7 |
+--------------------------------------------------------------------+
| 0 x x x Non-use of Transport Expedited Data Service |
| ---------------------------------------------------------|
| Bits 4 6 7 are not applicable (*) |
+--------------------------------------------------------------------+
| 1 x x x Use of Transport Expedited Data Service |
| ---------------------------------------------------------|
| 1 0 x x Use of Expedited Data Service with Forward Connection|
| -----------------------------------------------------|
| 1 0 1 0 Forward Connection with Expedited Data |
| Acknowledgement |
| 1 0 1 1 Forward Connection with Expedited Data |
| Acknowledgement and use of Non-blocking |
| Expedited Data (**) |
| --------------------------------------------|
| 1 0 0 0 Forward Connection with non-use of Expedited|
| Data Acknowledgement (***) |
| 1 0 0 1 Forward Connection with non-use of Expedited|
| Data Acknowledgement and use of Non-blocking|
| Expedited Data |
| -----------------------------------------------------|
| 1 1 x x Use of Expedited Data Service with Reverse Connection|
| -----------------------------------------------------|
| 1 1 1 0 Reverse Connection with Expedited Data |
| Acknowledgement |
| 1 1 1 1 Reverse Connection with Expedited Data |
| Acknowledgement and use of Non-blocking |
| Expedited Data (**) |
| --------------------------------------------|
| 1 1 0 0 Reverse Connection with non-use of Expedited|
| Data Acknowledgement (***) |
| 1 1 0 1 Reverse Connection with non-use of Expedited|
| Data Acknowledgement and use of Non-blocking|
| Expedited Data |
+--------------------------------------------------------------------+(*) heads up: the default (0000) gives you an RFC1006-like service with Explicit Transport Disconnection 💜
(**) in this case, using Expedited Data Acknowledgement together with Non-blocking Expedited Data is a wasted effort (See section 6.5) 💀
(***) in this case, Normal and Expedited Data TPDU are not synchronised. (See section 6.6) 🙃
6.7. Class 2 Expedited Data Acknowledgement 🌈
the protocol in this document doesn't define any relationship between the "Expedited Data Acknowledgement" option and the "Non-blocking Expedited Data" service. no link, no drama ✨
BUT ngl, when you're using "Non-blocking Expedited Data", using "Expedited Data Acknowledgement" is a wasted effort 😭 ED TPDUs get duplicated and sent on both the Normal Data and Expedited Data TCP connections anyway, so the ack is just extra 🫠
6.8. Class 2 Normal Data and Expedited Data handling 🔥
there are two separate application requirements for Expedited Data, and the vibes are very different:
- Synchronisation of the order of delivery between Normal and Expedited Data TPDU.
- Independence of Normal and Expedited data channels. A busy Normal Data channel should not block an Expedited Data channel.
the protocol here can handle both requirements, separately or together 🫶
Synchronisation:
If synchronised order of delivery between Normal and Expedited Data TPDU is required, then either "Expedited Data Acknowledgement" TPDU or the "Non-blocking Expedited Data" service MUST be negotiated during connection establishment.
If synchronised order of delivery between Normal and Expedited Data TPDU is not required, then non-use of "Expedited Data Acknowledgement" need not be negotiated during connection establishment 🌸
Independence:
If Independence of Normal and Expedited data channels is required, then Forward or Reverse connection MUST be negotiated during connection establishment. Expedited data TPDU MUST be sent on the Expedited data channel 🦋
If Independence of Normal and Expedited data channels is not required, then Forward connection SHOULD be negotiated during connection establishment, and the Expedited data channels SHOULD NOT be established. Expedited data TPDU is then sent inband on the Normal data channel 🧚
⚠️ Finally, please note that independence of Normal and Expedited data channels without synchronisation relaxes the Transport Service definition of Expedited data, and it is not consistent with ISO 8072. Not the vibe for compliance, bestie 😭
6.9. Class 2 Forward Connection procedure 👑
as defined in ISO 8073, when the "Forward Connection" (Splitting and Recombining) procedure is used for Expedited Data transmission, ED TPDU MUST only be sent over an outgoing NS-provider TCP connection 💅
as defined in ISO 8073, this document does not mandate use of the Splitting procedure for Expedited Data transmission. The Recombination procedure, which ties together Data (normal and expedited) TPDUs arriving for a transport connection over two TCP connections, MUST be handled 🎀
it is legal to send Expedited Data TPDU inband on the Normal Data TCP connection 🍓
please note that the protocol in this document doesn't define when an Expedited Data TCP connection should be established. That's an implementation choice, iykyk 🧠
when using "Non-blocking Expedited Data" service, it is RECOMMENDED to not delay establishing the Expedited Data TCP connection ⭐
6.10. TPKT 🌸
this document specifies the value of the TPKT reserved field 🩷
implementations SHOULD NOT interpret and act upon any value in a reserved field. To avoid interoperability issues with RFC1006, this field SHOULD be ignored on input 🫶
7. Rationale - Interoperability with RFC1006 ✨
okay so bestie, we kept TPKT on version 3 in ITOT, same as [RFC1006] 🦋 The reason is that the changes in this document don't clash with RFC1006 at all. If we bumped the protocol version, every existing RFC1006 implementation that insists on version 3 would be locked out and couldn't talk to this protocol. Nobody wants that drama 😭
One consequence is class negotiation. This document brings Class 2 over TCP, so we need a way to negotiate between Class 2 and Class 0 🔥 Every Transport implementation should be able to handle class negotiation, but we know some RFC1006 implementations can't, so implementors need to be ready for this. A Class 2 Connect Request with no Alternative class could get back a Class 0 Connect Confirm, and when that happens, the Connect Confirm should be rejected as ISO 8073 specifies 💅
8. Security Considerations 🔐
ngl this section is short but it's giving serious vibes. Security issues are not specifically addressed in this document 💀 The protocol is no more and no less secure than operating TCP and ISO 8073 do. If you want the full security story, go read those specs, they're the real main characters here 🫶
Heads up: this document doesn't add any security guarantees of its own. Your security depends on TCP and ISO 8073, so check those specs before you ship anything 🙈
Acknowledgements
the authors gave a huge shoutout 🌸 to everyone who helped with suggestions and comments, and they said it was truly the best support ever 🫶 Thank you to Harald T. Alvestrand, Jim Bound, John Day, Mike Dyer, Peter Furniss, Dan Harrington, Steve Kille, Keith G. Knightson, Keith Sklower, Matt Thomas, Robert Watson, and the many other members of the IETF TOSI mailing list 💜 The support of Allison Mankin of the IESG was essential ✨
References
[ISO8072] ISO. "International Standard 8072. Information Processing
Systems - Open Systems Interconnection: Transport Service
Definition."
[ISO8073] ISO. "International Standard 8073. Information Processing
Systems - Open Systems Interconnection: Transport Protocol
Specification." ISO 8073:1992 and 8073:1992/Amd.5:1995.
[ISO8348] ISO. "International Standard 8348. Information Processing
Systems - Open Systems Interconnection: Network Service
Definition."
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC896] Nagle, J., "Congestion Control in IP/TCP Inertnetworks",
RFC 896, January 1984.
[RFC1006] Rose, M., and D. Cass, "ISO Transport Services on Top of
the TCP Version 3", STD 35, RFC 1006, May 1987.
[RFC1277] Hardcastle-Kille, S., "Encoding Network Addresses to
support operation over non-OSI lower layers", RFC 1277,
November 1991.
[RFC1278] Hardcastle-Kille, S., "String encoding of Presentation
Address", RFC 1278, November 1991.
A string encoding of Presentation Address
update to RFC1278, Work in Progress.
[RFC1859] Pouffary, Y., "ISO Transport Class 2 Non-use of Explicit
Flow Control over TCP - RFC1006 extension", RFC 1859,
October 1995.
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
Hinden,, R., and S. Deeing, "IP Version 6 Addressing
Architecture", RFC 1884, December 1995.
Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.Authors' Addresses 🧚
Yanick Pouffary
End Systems Networking
Digital Equipment Corporation
Centre Technique (Europe)
B.P. 027
950 Routes des colles
06901 Sophia antipolis, France
Phone: +33 92-95-62-85
Fax: +33 92-95-62-35
EMail: pouffary@taec.enet.dec.com
Alan Young
ISODE Consortium
The Dome
The Square
Richmond, UK
Phone: +44 181 332 9091
Fax: +44 181 332 9019
EMail: A.Young@isode.com📦 where this page comes from
- ietf: rfc2126 1997-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms