RFC 1007

Military supplement to the ISO Transport Protocol

📅 published June 1987, from ietf

RFC 1007: Military Supplement to the ISO Transport Protocol 💖

Okay bestie, this is RFC 1007 🎀 written by Wayne McCoy in June 1987, under the Network Working Group. Its title is Military Supplement to the ISO Transport Protocol ✨. The header doesn't list a category, and it doesn't obsolete or update any other RFC 🌸

RFC number: 1007
Authors: Wayne McCoy
Date: June 1987
Obsoletes / Updates: none listed in the title block

Status of this Memo 🦋

So this one is basically the Internet community being invited to comment 🫶 It's a draft military supplement, and the whole point is to collect feedback on it. The doc admits it might not be super relevant to the Internet's research problems, but researchers and implementors might still find it interesting 👀 Distribution is unlimited 🌈

1. SCOPE 🌸

1.1. Purpose.

Here's the vibe: this supplement sits on top of the ISO Transport Service and Protocol, which are IS 8072 and IS 8073 💅 It gives you the conventions, option selections, and parameter values you need when running the protocol inside the applicability statement in Paragraph 1.3 (that's below). Paragraph 1.4 explains the ISO standards in more detail. It does not go deep into implementation details. For that you go to a separate doc called "Implementation Guide for the ISO Transport Protocol" 🧚

1.2. Organization.

There are five sections in this supplement ✨ Section 1 explains what the Transport Protocol is for and which international standards it's built on. Section 2 lists those standards and the supporting documents, and Section 3 adds definitions that the standards don't already cover. The ISO standards work across a huge range of network environments, so there's a pile of options and parameters that have to be picked for each specific use. Section 4 picks the ones that matter for implementations this supplement applies to, and defines usage conventions for them 💜

Section 5 covers addressing conventions, how Transport connection reference numbers get used, and how a Transport connection recovers from peer deactivation 🦋

1.3. Application.

Okay, this part is the big one 🔥 Using the Transport Protocol Class 4 and the Protocol for Providing the Connectionless-Mode Network Service (IS 8473) is mandatory for all DOD packet-switched data networks where hosts might need to talk to each other across network or subnetwork boundaries 🫡 "Network" here shall include Local Area Networks, but not integrated weapons systems.

Using Class 4 and IS 8473 is strongly encouraged, especially where equipment needs to be interchangeable or survivable 💪 It's also encouraged in weapons systems, as long as that usage doesn't reduce the performance that's required 🎯

1.4. International Standards Organization Transport Protocol.

The ISO standard this supplement is based on is made up of four documents 📚

a. IS 8072, the Transport Service Definition, which defines the service Transport gives to a user, written in English text;
b. WG4 N53, the Formal Description of the Transport Service, where the Transport Service is described with a formal description language;
c. IS 8073, the Transport Protocol, where the protocol is specified in English text; and
d. N123, the formal description of the Transport Protocol, where IS 8073 is written in a formal description language.

The ISO protocol has five classes of service, Class 0 through Class 4 👑 Only Classes 4 and 2 apply to this supplement. The formal description language is Estelle, DP 9074, which describes protocols as communicating finite state automata 🤖 It has a subset language that matches the international standard Pascal. The Class 4 protocol, when it runs on top of a connectionless network service, is described in an addendum to IS 8073, N3339(rev) 🌈

2. REFERENCED DOCUMENTS 📖

2.1. Issues of Documents.

These documents form part of this supplement to the extent specified here, and they're the issues in effect on the date of the invitation for bids or request for proposal 💖

FED-STD-1037: Federal Standard 1037, Glossary of Telecommunication Terms.
Implementation Guide for the ISO Transport Protocol

2.2. Other Publications.

These documents also form part of this standard to the extent specified here 🫶 Unless the document says otherwise, the issue in effect on the invitation-for-bids or request-for-proposal date applies ✨

IS 8072: Information Processing Systems, Open Systems Interconnection, Transport Service Definition. Available from: ANSI ISO TC97/SC6 Secretariat 1430 Broadway New York, NY 10018 (212) 354-3343
IS 8073: Information Processing Systems, Open Systems Interconnection, Transport Protocol Specification. Available from ANSI (SC6 Secretariat).
N3339(rev): Draft Proposed Addendum to IS 8073 to Enable Class 4 Operation Over Connectionless Mode Network Service as Defined in ISO/ISO 8348/AD1. Available from ANSI (SC6 Secretariat).
DP 9074: Estelle, A Formal Description Technique Based on an Extended State Transition Model. Available from ANSI (SC21 Secretariat), same address as SC6 above.
WG4 N53: Information Processing Systems, Open Systems Interconnection, Formal Description of IS 8072 in Estelle. (Working draft, ISO TC 97/SC 6/WG 4)
N123: Information Processing Systems, Open Systems Interconnection, Formal Description of IS 8073 in Estelle. (Working draft, ISO TC 97/SC 6)
IS 8473: Information Processing Systems, Data Communications, Protocol for Providing the Connectionless-mode Network Service. Available from ANSI (SC6 Secretariat).

3. DEFINITIONS 🧚

3.1. Definition of terms.

Terms in this standard shall follow FED-STD-1037, ISO IS 8072, IS 8073, and IS 8473 ✨ Other terms and definitions that belong to N3756, WG4 N53, and N3339(rev) live inside those documents 💜

3.2. Abbreviations and acronyms.

These are the abbreviations and acronyms used in this supplement 🌸

a. ISO. The International Standards Organization;
b. OSI. Open Systems Interconnection;
c. TS. Transport service;
d. TSAP. Transport service access point;
e. NSAP. Network service access point;
f. TPDU. Transport protocol data unit;
g. CR. Connect request;
h. CC. Connect confirm;
i. DR. Disconnect request;
j. ER. Error;
k. AK. Acknowledgement;
l. IP. Internetwork protocol;
m. LAN. Local area network.
n. CONS. Connection oriented network service.
o. CLNS. Connectionless network service.

(Other provisions of this Section are under consideration.)

4. GENERAL REQUIREMENTS ✨

4.1. Conformance. 💅

Okay bestie, this is where we figure out what "conforming" actually means 🎀 Implementations this supplement applies to shall satisfy the conformance requirements (Clause 14, of IS 8073 and N3339(rev), as adapted for this supplement) in the following statements.

a. A system claiming to implement the procedures specified in this standard shall comply with the requirements in b. - d., below.
b. The system shall implement:
- b.1 Class 2 or Class 0 or both, if operated over a connection oriented network service; or
- b.2 Class 4 if operated over a connectionless network service.
c. If the system implements Class 4, it shall also implement Class 2, if it is operated over a connection oriented network service. Class 2 shall not be implemented if operation is exclusively over a connectionless network service.
d. For each class which the system claims to implement, the system shall be capable of:
- d.1 initiating CR TPDUs or responding to CR TPDUs with TPDUs or both;
- d.2 responding to any other TPDU and operating network service in accordance with procedures for the class;
- d.3 operating all the procedures for the class listed as mandatory in the Provisions of Options table below;
- d.4 operating those procedures for the class, listed as optional in the Provisions of Options table, for which conformance is claimed; and
- d.5 handling all TPDUs of lengths up to the lesser value of:
  - d.5.1 the maximum length for the class;
  - d.5.2 the maximum for which conformance is claimed.
e. Claims of conformance shall state:
- e.1 whether or not operation over connectionless service is implemented;
- e.2 which class or classes of protocol are implemented, if operation over a connection oriented network is implemented;
- e.3 whether the system is capable of initiating or responding to CR TPDUs or both;
- e.4 which of the procedures listed in the Provisions of Options table are implemented;
- e.5 the maximum size of TPDU implemented; the value shall be chosen from the following list and all values in the list which are less than this maximum shall be implemented:

128, 256, 512, 1024, 2048, 4096, or 8192 octets.

Provision of options (adapted from IS 8073, Table 9)

 __________________________________________________________________
|        PROCEDURE         |     CLASS 2        |     CLASS 4     |
|__________________________|____________________|_________________|
|                          |                    |                 |
|TPDU with checksum        |not applicable      |mandatory        |
|TPDU without checksum     |mandatory           |optional         |
|__________________________|____________________|_________________|
|                          |                    |                 |
|Expedited data transfer   |mandatory           |mandatory        |
|No expedited data transfer|mandatory           |mandatory        |
|__________________________|____________________|_________________|
|                          |                    |                 |
|Flow control in Class 2   |mandatory           |not applicable   |
|No flow control in Class 2|optional            |not applicable   |
|__________________________|____________________|_________________|
|                          |                    |                 |
|Normal formats            |mandatory           |mandatory        |
|Extended formats          |optional            |optional         |
|__________________________|____________________|_________________|

The explicit manner in which implementations, to which this supplement applies, shall satisfy these conformance statements is given in Paragraph 4.4. The options are described in more detail in Paragraph 4.3. 🦋

4.2. Transport Service access parameters. 🌸

Each of the services of transport has parameters that do three jobs: they identify the communicating peers, they express options for how the transport connection runs, or they carry data from one peer user to the other. The conventions for using these parameters in implementations this supplement applies to are given below. ✨

4.2.1. Connect Service. 🎀

The Connect Service is summarized below (refer to IS 8072 for detailed discussion):

 __________________________________________________________________
|             Primitives                        Parameters       |
|________________________________________________________________|
| T-CONNECT          request     |  Called Address,              |
|                    indication  |  Calling Address,             |
|                                |  Expedited Data Option,       |
|                                |  Quality of Service,          |
|                                |  TS User-Data                 |
|________________________________|_______________________________|
| T-CONNECT          response    |  Responding Address,          |
|                    confirm     |  Quality of Service,          |
|                                |  Expedited Data Option,       |
|                                |  TS User-Data                 |
|________________________________|_______________________________|

The conventions for Called Address, Calling Address and Responding Address show up in Paragraph 5.1.1. Whether the Expedited Data Option gets used depends on the nature of the transport user, and this supplement does not define how transport users decide on that. The Quality of Service parameters are discussed in IS 8072, but how they're applied in an implementation is an implementation issue, and the mechanisms for maintaining the requested quality of service are not defined. So it is recommended that these parameters not be used in implementations until a usage definition exists. 🙈 The TS User-Data passed here is constrained to 32 octets or less. (This TS User-Data parameter shall not be used for any data that requires any security protection whatever.) No implementation is required to be able to send such data received from its user, but each implementation shall be capable of passing data received from the remote peer user during connection establishment to its user. 🔥

4.2.2. Disconnect Service. 💀

 __________________________________________________________________
|             Primitives                        Parameters       |
|________________________________________________________________|
| T-DISCONNECT       request     |  TS User-Data                 |
|________________________________|_______________________________|
| T-DISCONNECT       indication  |  TS User-Data,                |
|                                |  Disconnect reason            |
|________________________________|_______________________________|

The Disconnect Service is abrupt, so data may be lost whenever it gets invoked. That's why transport user processes should make sure all the data they're meant to receive has actually been received before they issue a T-DISCONNECT-request. 😭 The data in the TS User-Data parameter is constrained to 64 octets or less in length. (The TS User-Data parameter shall not be used for data that requires any security protection whatever.) Disconnect reasons are discussed in IS 8073, and reasons other than those listed in IS 8073 are permitted. 👑

4.2.3. Data Transfer Service. 🧚

 __________________________________________________________________
|             Primitives                      Parameters         |
|________________________________________________________________|
| T-DATA             request     |  TS User-Data                 |
|                    indication  |                               |
|________________________________|_______________________________|

The length of the data carried by the TS User-Data parameter isn't constrained by the ISO Standard, but interface considerations may impose practical limits. This is discussed further in the Implementors guide, Part 3.1. For the purposes of this supplement, the TS User-Data parameter in this service is considered to be protected, and it should be used for any data requiring security protection. 🔐

4.2.4. Expedited Data Service. 🌈

 __________________________________________________________________
|               Primitives                   Parameters          |
|________________________________________________________________|
| T-EXPEDITED-DATA   request     |  TS User-Data                 |
|                    indication  |                               |
|________________________________|_______________________________|

The TS User-Data parameter is constrained to be no longer than 16 octets, and it shall not be used for data requiring any security protection whatever. The T-EXPEDITED-DATA-request cannot be used whenever non-use of expedited data was called for in either the T-CONNECT-request or T-CONNECT-response primitive. ⭐

4.3. Options. 🍓

The protocol described in IS 8073 and N3756 permits certain options that qualify or enhance the service provided. Negotiated options are the ones both communicating peer transport entities agree on during connection establishment. Local options are the ones that apply to a particular implementation of transport and may be used to enhance performance, optimize resource utilization or improve resilience to network failures. The election of a local option is invisible to the remote peer entity. 🫶

4.3.1. Negotiated options 🦋

okay so these are the IS 8073 options that peer transport entities SHALL be negotiating with each other 💖 The way an implementation makes its elections for these options is defined in Paragraph 4.4 ✨

Class of service: agreement on one of five classes of transport service, depending on which classes the entities support, the quality of the network service available, and how much resilience to network errors and failure the peer transport users need 🎀
Use of extended formats: agreement to use or not use extended formats for sequence numbering and flow control credit. Normal formats give sequence numbers in the range 0 - (2**7 - 1) and flow control credit in the range 0 - (2**15 - 1). Extended formats give sequence numbers in the range 0 - (2**31 - 1) and credit in the range 0 - (2**16 - 1) 🔢
Use of expedited data transfer: agreement to use or not use expedited data transfer during normal data transfer procedures ⚡
Maximum size of protocol data units to be exchanged: agreement to limit the size of exchanged protocol data units, depending on the buffer resources the entities have and the network quality of service. Negotiated values are in the range 2**7 - 2**13 octets (total length) 📦
Use of checksum: agreement to use or not use a 16-bit checksum on each protocol data unit exchanged between the entities, depending on the expected residual error rate in the network service used 🔍
Protection parameters: agreement on how protection will be defined and maintained on the transport connection. These parameters are defined by the communicants who elect to use them 🔐
Use of flow control in Class 2: agreement to use or not use flow control in Class 2 when Class 2 operation has been negotiated. Conformance to the ISO Standard requires that if Class 4 is supported over CONS, then Class 2 SHALL also be supported 🌈
Service quality parameters: agreement on the quality of service to expect on the transport connection. The ISO Standard does not say how these parameters are to be used by the transport entities or their users 🌸

4.3.2. Local options, Class 2 ✨

these are the options an implementor can decide on in a particular Class 2 implementation 🧚 For the recommendations and requirements on these options for the purposes of this supplement, check out Paragraph 4.5.1 💜

Multiplexing on network connection: for better usage of network resources, an implementation MAY elect to share a network connection among two or more transport connections 🍓
Acknowledgement strategy: IS 8073 doesn't require an implementation to use any particular strategy for sending acknowledgements for received data. Each data transfer protocol data unit MAY be explicitly acknowledged (one-for-one), or MAY be implicitly acknowledged by a group acknowledgement (one-for-N) 🫶
Concatenation of protocol data units: when network service data units are large compared to the protocol data units being sent, an implementation MAY elect to concatenate those protocol data units into a single network service data unit 🧩
Lockup prevention timer: when the wait-before-closing state is entered, there's a chance of deadlock if the peer transport entity never responds to the CR TPDU 😬 The standard provides for an OPTIONAL timer to ease this situation 🦋

4.3.3. Local options, Class 4 ✨

these are the options an implementor can decide on in a particular Class 4 implementation 💅 The recommendations and requirements for using these options in implementations this supplement applies to are in Paragraph 4.5.2 🎀

Withdrawal of flow control credit: when supporting several connections of different precedence or priority, resource management MUST be practiced so the precedence or priority relationships are kept intact 👑
Flow control confirmation: when flow control credit is reduced, extra delay may show up because acknowledgements carrying new flow control information get lost. This procedure helps speed up resynchronization of the flow control 🙈
Subsequenced acknowledgements: when the flow control window has been closed, this procedure clears up ambiguity caused by lost or out-of-order acknowledgements 🧠
Splitting over network connection: when operating over a connection-oriented network service, a Class 4 implementation is permitted to use more than one network connection, for better performance and better resilience to network connection failure 🚀
Acknowledgement strategy: the standard doesn't require an implementation to use any particular strategy for sending acknowledgements for received data. Each data transfer protocol data unit MAY be explicitly acknowledged (one-for-one), or MAY be implicitly acknowledged by a group acknowledgement (one-for-N) 🫶
Wait-before-closing state: when a connect request has been sent to the peer and the user asks for a disconnection before the connect confirmation arrives, an implementation MAY elect to wait for the confirmation before sending the disconnection request to the peer. This makes sure the connection to be released is positively identified 🔒
Multiplexing on network connection: for better usage of network resources, an implementation MAY elect to share a network connection among two or more transport connections 🍓
Concatenation of protocol data units: when network service data units are large compared to the protocol data units being sent, an implementation MAY elect to concatenate those protocol data units into a single network service data unit 🧩
Checksum algorithm: the Fletcher checksum algorithm in an annex to the standard is NOT part of the standard. It's only there for information. The checksum algorithm used nature of network errors expected and need only satisfy the summation criterion given in the standard 🧮

(ngl this sentence gets a little tangled in the original, so I'm keeping it exactly as the standard has it 😭)

Send network RESET when bad checksum received: it may not be possible to know with certainty which of several transport connections multiplexed on a network connection is meant to receive a protocol data unit carrying a bad checksum. A N-RESET or N-DISCONNECT MAY be sent on the network connection to all transport entities on the connection to indicate the error 🚨
Protocol data unit retransmission policy: protocol data units with no acknowledgement received MAY be retransmitted in case the originals never arrived. Whether to retransmit only the oldest unacknowledged protocol data unit or all the outstanding ones has implications for buffer management in the sending entity and for bandwidth utilization on the network transmission medium 📡

4.4. Negotiations 💅

Paragraph 4.2.1 lists the options that peer transport entities SHALL negotiate with each other 🤝 Below, you'll find conventions for these options as used in implementations this supplement applies to. These requirements reflect the conformance statement of IS 8073 and the needs of the DOD 🫧

4.4.1. Options 🌷

4.4.1.1. Class of service 🌸

An implementation operating on CONS SHALL be capable of offering Class 2 and MAY optionally support Class 0 ✨
An implementation SHALL NOT respond by proposing Class 0, and SHALL NOT respond by proposing Class 2 if the connect request was received on a CLNS 🙅‍♀️
An implementation MAY offer Class 2 as an alternative class of operation in a connect request when operating over CONS. No alternative class MAY be offered if operation is over a CLNS 🎀
An implementation SHALL respond to a connect request that proposes Class 1 or 3 as primary choice with a disconnect request, reason code 128+2 (see p. 87 of IS 8073) 💥
An implementation SHALL NOT propose Class 1 or Class 3 in response to a connect request carrying Class 1 or Class 3 as an alternative class of service 🚫
An implementation which proposes Class 4 in a connect request need not accept a Class 2 proposal from its peer if Class 2 was not offered as an alternative in the connect request, or if operation is over a CLNS. Class 2 SHALL be accepted when the responding peer proposes it, if it was offered as an alternative in the connect request 🦋

4.4.1.2. Extended formats 🧁

An implementation SHALL always propose use of extended formats when either Class 4 or Class 2 is proposed in a connect request 💖
An implementation SHALL always accept the use of extended formats when so proposed in a received connect request 🫶

4.4.1.3. Expedited data ⚡

Use of expedited data is subject to negotiation by users of Transport Service 🤍
Expedited data SHALL be supported in Class 2 ✨

4.4.1.4. Maximum protocol data unit size 📏

(The provisions of this paragraph are under consideration.) 🙈

4.4.1.5. Use of checksum 🔍

An implementation SHALL propose use of checksums consistent with the expected quality of service and security requirements 🔐

Checksums SHOULD be used when operating with the IP on catenated networks 🌐
Checksums SHOULD NOT be used if high performance is required, except when required by high error rates in the network service 🏎️
Checksums SHOULD always be used when any encryption is being used 🔒

4.4.1.6. Protection parameters 🛡️

Use of the security parameters is not defined in this supplement 🤷‍♀️

4.4.1.7. Use of flow control in Class 2 🌊

An implementation SHALL always propose the use of flow control in Class 2 whenever Class 2 is proposed as either its primary or alternative choice of service 👑
An implementation SHALL accept use of flow control in Class 2 whenever negotiation to Class 2 occurs 💅

4.4.1.8. Service quality parameters. 💅

okay so this bit is about the service quality parameters and honestly it's giving "only two of them are decided rn" 🥹

a. Using the service quality parameters in the CR and CC protocol data units isn't defined, except for the residual error rate parameter and the priority parameter ✨
b. Residual error rate (the use of this parameter is under consideration) 🔍
c. Priority (the use of this parameter is under consideration) 👑

4.4.2. Parameters. 🎀

this is where we pick the values that go in the CR and CC TPDUs, bestie 🧚

4.4.2.1. Class 2 parameters. 🦋

4.4.2.1.1. Connect request (CR) protocol data unit. 🌸

4.4.2.1.1.1. Fixed part of header. 💖

a. Connect request code: as in IS 8073.
b. Initial credit allocation: this field tells you how many TPDUs the connection initiator offers as initial credit. The field is 4 bits long, so the most credit you can offer up front is 15 🫶 These TPDUs have to stay within the maximum size set in the TPDU size field, which is listed below in Paragraph 4.4.2.1.1.2.
c. Destination reference: as in IS 8073.
d. Source reference: this reference SHALL be selected pursuant to the provisions of Paragraph 5.2.1.
e. Class and option: the class field SHALL take binary value 0010, and the option field SHALL take binary value 0010 ✨ (These values select Class 2, plus the extended formats and flow control options in Class 2.)

4.4.2.1.1.2. Variable part of header. 🧁

a. TSAP identifiers: the parameter values SHALL follow the conventions given in Paragraphs 5.1.1 and 5.1.2.
b. TPDU size: (The values to be used are under consideration.)
c. Version number: as in IS 8073.
d. Protection parameters: SHOULD NOT be used.
e. Checksum: SHALL NOT be used. 🙈
f. Additional options: this field SHALL take binary value 0001 if the initiating user has proposed the use of expedited data, and SHALL take value 0000 otherwise.
g. Alternative protocol classes: this field SHALL NOT be used unless Class 0 is going to be proposed as an alternate class of operation.
h. Throughput: SHOULD NOT be used.
i. Residual error rate: SHOULD NOT be used.
j. Priority: (Use of this parameter is under consideration.)
k. Transit delay: SHOULD NOT be used.

4.4.2.1.1.3. User data. 🔒

The CR TPDU SHALL NOT carry user data which has any requirement whatever for security protection. no security-sensitive data in here, periodt 🚫

4.4.2.1.2. Connect Confirm (CC) TPDU. 🌈

4.4.2.1.2.1. Fixed part of header. 💜

a. Connect confirm code: as in IS 8073.
b. Initial credit allocation: same as Paragraph 4.4.2.1.1.1.
c. Destination reference: this reference SHALL be the Source reference number from the received CR TPDU.
d. Source reference: this reference SHALL be selected pursuant to the provisions of Paragraph 5.2.1.
e. Class and option: the class field SHALL take binary value 0010 and the option field SHALL take binary value 0010 (selects Class 2 and the extended formats and flow control options in Class 2) 🦋

4.4.2.1.2.2. Variable part of header. 🍓

a. TSAP identifier(s): the parameter values SHALL follow the conventions given in Paragraphs 5.1.1 and 5.1.2.
b. TPDU size: (The values for this parameter are under consideration.)
c. Version number: as in IS 8073.
d. Protection parameters: SHOULD NOT be used.
e. Checksum: SHALL NOT be used.
f. Additional options: this field SHALL take binary value 0001 if the responding transport entity has proposed the use of expedited data, and SHALL take binary value 0000 otherwise.
g. Alternative protocol classes: SHALL NOT be used.
h. Throughput: SHOULD NOT be used.
i. Residual error rate: SHOULD NOT be used.
j. Priority: (The use of this parameter is under consideration.)
k. Transit delay: SHOULD NOT be used.

4.4.2.1.2.3. User data. 🙈

The CC TPDU SHALL NOT carry any data which has any requirement whatever for security protection.

4.4.2.2. Class 4 parameters. 👑

4.4.2.2.1. Connect request (CR) TPDU. ✨

4.4.2.2.1.1. Fixed part of header. 🫧

a. Connect request code: as in IS 8073.
b. Initial credit allocation: this field defines the number of TPDUs offered as initial credit by the connection initiator. The field is 4 bits long, so the maximum credit that can be initially offered is limited to 15. These TPDUs are constrained in length to the maximum size defined in the TPDU size field, listed below in Paragraph 4.4.2.2.1.2.
c. Destination reference: as in IS 8073.
d. Source reference: this reference SHALL be selected pursuant to the provisions of Paragraph 5.2.1.
e. Class and option: the class field SHALL take binary value 0100, and the option field SHALL take binary value 0010 🔥 (These values select Class 4, and the options of extended formats and flow control in Class 2. This latter option is ignored if the class negotiated is Class 2.)

4.4.2.2.1.2. Variable part of header. 🎀

a. TSAP identifiers: the parameter values SHALL follow the conventions given in Paragraphs 5.1.1 and 5.1.2.
b. PDU size: (The values for this parameter are under consideration.)
c. Version number: as in IS 8073.
d. Protection parameters: SHOULD NOT be used.
e. Checksum: if Class 4 has been selected, this parameter MAY be used. If Class 2 (or Class) has been selected, this parameter SHALL NOT be used.
f. Additional options: this field SHALL take binary value 0001 if the initiating user has proposed the use of expedited data, and SHALL take binary value 0000 otherwise.
g. Alternative protocol classes: this field SHALL be used only if Class 2 (or Class 0) is going to be proposed as an alternate class of operation, conformant to the conditions of Paragraph 4.4.1.1. If Class 2 is proposed, the field SHALL take binary value 00000010 (1 octet) 🧚
h. Acknowledge time: SHOULD NOT be used.
i. Throughput: SHOULD NOT be used.
j. Residual error rate: (The use of this parameter is under consideration.)
k. Priority: (The use of this parameter is under consideration.)
l. Transit delay: SHOULD NOT be used.

4.4.2.2.1.3. User data. 🔒

The CR TPDU SHALL NOT carry user data which has any requirement whatever for security protection. 💅

4.4.2.2.2. Connect confirm (CC) TPDU. 🌸

4.4.2.2.2.1. Fixed part of header. 🦋

a. Connect confirm code: as in IS 8073.
b. Initial credit allocation: same as Paragraph 4.4.2.2.1.1.b.
c. Destination reference: this reference SHALL be the number in Source reference from the received CR TPDU.
d. Source reference: this reference SHALL be selected pursuant to the provisions of Paragraph 5.2.1.
e. Class and option: if Class 2 has been selected, then the class field SHALL take binary value 0010 and the option field SHALL take binary value 0010. If Class 4 has been selected, then the class field SHALL take binary value 0100 and the option field SHALL take binary value 0010 💖

4.4.2.2.1.2 Variable part of header 🎀

okay so the variable part of the header has a bunch of little rules, bestie, and every single one matters 💅

a. TSAP identifier(s): the parameter values shall follow the conventions given in Paragraphs 5.1.1 and 5.1.2. 🦋
b. TPDU size: (The values for this parameter are under consideration.) 🤔
c. Version number: as in IS 8073. 🌸
d. Protection parameters: should not be used. 🙅
e. Checksum: if Class 4 has been selected, this parameter may be used. If Class 2 (or Class 0) has been selected, this parameter shall not be used. 🧮
f. Additional options: if Class 4 or Class 2 has been selected, this field shall take binary value 0001 if the responding user has proposed use of expedited data, and shall take binary value 0000 otherwise. ⚡
g. Alternate protocol classes: shall not be used. 🚫
h. Acknowledgement time: should not be used. ⏰
i. Throughput: should not be used. 💧
j. Residual error rate: (The use of this parameter is under consideration.) 🌫️
k. Priority: (The use of this parameter is under consideration.) 👑
l. Transit delay: should not be used. 🚚

4.4.2.2.1.3 User data 💌

the CC TPDU shall not carry user data that has any requirement whatsoever for security protection. no exceptions, no cap 🔒

4.5 Use of local options 🎛️

this part is all about policy and guidance for picking local options, so read it like a cheat sheet 🧚

4.5.1 Local options, Class 2 🌷

4.5.1.1 Multiplexing 🧵

any Class 2 connections may be multiplexed on the same network connection, up to the limits the network service provides. but multiplexing Class 2 and Class 4 connections together on the same network connection is not recommended. not it 🙅‍♀️ (okay, not me making the rules, but yeah, don't do it)

4.5.1.2 Acknowledgement strategy 🤷

(The provisions of this paragraph are under consideration.)

4.5.1.3 Concatenation 🔗

this lets you put certain TPDUs into a single network service data unit along with a data-bearing TPDU. it's super useful for cutting down the overhead of sending each TPDU separately ✨

4.5.1.4 Lockup prevention timer ⏲️

it is strongly recommended that this timer be used for all Class 2 connections, bestie, no debate. a description of the timer is included in the transport formal description. (This timer corresponds to the optional TS1 timer that IS 8073 recommends.) 🫶

4.5.1.5 Treatment of protocol errors 🛠️

protocol errors detected by a Class 2 transport connection shall result in that connection being terminated, and the entity shall not send an ER TPDU when it does this. (okay so no ER TPDU, periodt 💀)

Wait, I need to keep the original meaning exact: the connection is terminated without sending an ER TPDU. Rewritten properly:

protocol errors detected by a Class 2 transport connection shall result in that connection being terminated, without sending an ER TPDU. no goodbye card, just vibes 👋

4.5.1.6 Action on receipt of Error transport protocol data unit 📭

receiving an ER TPDU for a Class 2 transport connection shall cause immediate termination of that transport connection. instant ghosting, iykyk 🫠

4.5.2 Local options, Class 4 🌺

4.5.2.1 Withdrawal of flow control credit 💸

because different transport connections have different levels of operating priority, an implementation shall support withdrawing flow control credit from any Class 4 transport connection. this is how you manage resource allocation among Class 4 connections, main character energy 👑

4.5.2.2 Flow control confirmation ✅

the requirement to support withdrawal of flow control credit strongly indicates the need to use flow control confirmation. an implementation should support and use the flow control confirmation procedures of IS 8073, consistent with quality of service and other requirements. it's giving "yes, confirm that, please" 💅

4.5.2.3 Subsequenced acknowledgements 🔢

the possibility of credit withdrawal strongly indicates the requirement for subsequence numbers on acknowledgements. an implementation shall support and use subsequence numbers as defined in IS 8073. no skipping this step 🫡

4.5.2.4 Splitting over network connection ✂️

implementations may use splitting as necessary or useful in the operating environment. (Splitting is defined only for operation over a CONS. 🌐

4.5.2.5 Acknowledgement strategy 🤷

(The provisions of this paragraph are under consideration.)

4.5.2.6 Wait-before-closing state 🕰️

it is recommended that this state be used. a lockup prevention timer, like the one used in Class 2, is not necessary, because the CR TPDU retransmission timer already handles that job. two timers, one vibe 🧚

4.5.2.7 Multiplexing on network connection 🧵

multiplexing Class 4 connections on a single network connection may be used as necessary or useful, within the limits the network service allows. but Class 4 connections should not be multiplexed onto network connections serving Class 2 transport connections. keep your squads separate 🌸

4.5.2.8 Concatenation of protocol data units 🔗

concatenation may be useful when operating over a CLNS that has large capacity service data units. concatenation on connection-oriented networks may be useful if transport connections are being multiplexed. before you commit, a careful analysis of how the network service data unit gets treated in internetwork environments should be done, to figure out whether concatenating TPDUs is worth it in those circumstances. do your homework first, bestie 📚

4.5.2.9 Checksum algorithm 🧮

it is strongly recommended that the algorithm described in the Implementors Guide Part 7 be used, rather than the algorithm given in the Annex to IS 8073. the Part 7 algorithm computes the same checksum as the one in IS 8073, but it has been optimized. guidance on when to use the checksum and when not to is in the Implementors Guide, Part 7. ⚡

4.5.2.10 Send network RESET when bad checksum received 🚨

it is recommended that only an N-RESET be sent when a TPDU with a bad checksum is encountered on a CONS. an implementation shall not send an N-DISCONNECT-request in such situations, because the TPDU with the bad checksum may have come from some entity trying to interfere with communications. 😤 when operating Class 4 over a CLNS, no action shall be taken on receipt of a TPDU with a bad checksum, meaning the TPDU shall be discarded. ghosted, but make it safe 🫥

4.5.2.11 Protocol data unit retransmission policy 🔁

(The provisions of this paragraph are under consideration.)

4.5.2.12 Treatment of protocol errors 🛠️

in Class 4, a protocol error that comes from a TPDU containing unrecognized parameters shall cause a DR TPDU to be sent to the sender, but only if the TPDU is otherwise valid. all other erroneous TPDUs shall be discarded. 🗑️

4.5.2.13 Action on receipt of Error transport protocol data unit 📭

if an ER TPDU is received from a remote transport entity, an implementation to which this supplement applies shall release the transport connection that the ER TPDU is associated with, if that association can be made. when the association cannot be made, the ER TPDU shall be discarded. 🫶

5. SPECIAL REQUIREMENTS ✨

5.1 Addressing conventions 🗺️

(The provisions of Paragraph 5.1 and its subparagraphs are under consideration.)

5.1.1 Transport Service Access Point 📍

5.1.2 Connect-request/confirm protocol data units 📨

5.1.3 Network Service Access Point 📍

5.2 Convention for use of transport connection reference numbers 🔢

the ISO Transport Protocol lets you freeze reference numbers with a timer, so re-using a reference number doesn't cause confusion in communications. however, DOD implementations have certain requirements imposed on them, so this timer-based control is inadequate on its own. the ISO standard only defines the actions to follow if a timer is used. other means of reference number control are not prohibited, as long as the minimum freeze time defined in IS 8073 is exceeded for each reference number used. 💖

5.2.1 Specification of convention 📜

an implementation adhering to the application definitions in this supplement, Paragraph 1.3, shall not re-use a transport connection reference number until the set of available reference numbers has recycled to that point. put more formally: if all reference numbers are defined to be within the interval [1,N], and a reference number R in this interval is used, then R shall be prohibited from being selected again until all of the numbers R+1,...,N,1,2,...,R-1 have been used. the choice of N should be large enough that the expected recycle period exceeds the minimum freeze time specified in IS 8073. this requirement is in addition to the freeze requirement of IS 8073 and does not supersede it. a simple way to implement this convention is given in Part 9.3 of the Implementors Guide. 🧠

5.3 Operation over connectionless network service 🌍

implementations to which this supplement applies are required to operate over connectionless network services, in addition to being able to operate over connection-oriented network services. the ISO standard specifies transport only for operation over a connection-oriented network. however, the Class 4 specification has been written so that use with a connectionless network service is not precluded. the formal description offers even more flexibility in this regard. so operation over connectionless network services, whether a LAN or IP, is primarily an implementation issue for Class 4. operation of Class 2 transport over a connectionless network service is not considered a reasonable option, because Class 2 lacks sufficient error recovery. for the purposes of this supplement, operation of Class 2 on a connectionless network service is not recommended. operation of Class 4 over a connectionless network service is discussed further in parts 1.2.2.2, 3.4, and 6 of the accompanying Implementors Guide. 🛰️

5.4 Recovery from peer deactivation 🔄

the ISO Standard does not provide for re-establishing the transport connection when one of the communicating peers is deactivated ("crashes"). however, the Class 4 state tables in Annex A to IS 8073 are flexible enough that simple adaptations in an implementation can give some degree of crash recovery without changing the protocol. these adaptations are discussed in Part 9.2 of the Implementors Guide. 🌈

📦 where this page comes from

ietf: rfc1007 1987-06
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms