rfc-2126

ISO Transport Service on top of TCP (ITOT)

Y. Pouffary, A. Young
date1997-03 streamLegacy statusPROPOSED STANDARD pages25 canonicalhttps://www.rfc-editor.org/rfc/rfc2126 doi10.17487/RFC2126 errataview
This document is a revision to STD35, RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006. [STANDARDS-TRACK]

updates

Extracted elements (27)

design-rationale §6.8

Independence of Normal and Expedited Data channels without synchronisation relaxes the Transport Service definition of Expedited Data and is explicitly noted as not consistent with ISO 8072, providing implementors with guidance on the conformance trade-off.

tcp

design-rationale §4.2.1

Multiplexing is not supported in Class 2 over TCP because, in the absence of a flow control policy, use of the ISO 8073 Multiplexing procedure leads to degradation of quality of service.

tcp

design-rationale §7

TPKT protocol version is kept at 3 (same as RFC1006) because the changes in ITOT do not conflict with RFC1006; changing the version would have prevented existing RFC1006 implementations from interoperating with the new protocol, unnecessarily fracturing the installed base.

tcp

design-rationale §6.7

Using Expedited Data Acknowledgement together with Non-blocking Expedited Data service is considered a wasted effort: since Non-blocking ED duplicates ED TPDUs on both TCP connections, acknowledgement adds overhead without benefit.

tcp

interoperability-note §6.5

Class 0 TPDU bit encoding in ITOT no longer allows credit and TPDU-NR (bits 0-6) fields to be ignored on input, correcting the inconsistent encoding rules defined in RFC1006 and aligning with ISO 8073 encoding rules.

tcp

interoperability-note §7

Implementors must be aware that some RFC1006 implementations cannot perform class negotiation; a Class 2 Connect Request with no alternative class could be accepted with a Class 0 Connect Confirm, at which point the initiator should reject the CC as specified in ISO 8073.

tcp

interoperability-note §7

ITOT maintains the same TPKT protocol version number (3) as RFC1006 to ensure that existing RFC1006 implementations which mandate version 3 can interoperate with ITOT. The reserved field in the TPKT header should be ignored on input to avoid interoperability issues with RFC1006.

tcp

normative-requirement §4.2.1 MUST NOT

Connection Request and Connection Confirmation TPDUs must not negotiate the use of Explicit Flow Control in Class 2 over TCP, because the absence of a flow control policy would cause Multiplexing to degrade quality of service; Multiplexing is therefore not supported.

tcp

normative-requirement §6.2 RECOMMENDED

For performance reasons it is suggested that the Nagle algorithm (RFC 896) be disabled using the TCP_NODELAY socket option, allowing TPKT data to be sent without delay.

tcp, congestion

normative-requirement §6.1 RECOMMENDED

Implementors are strongly suggested to enable the TCP keep-alive mechanism so that unexpected termination of the underlying TCP connection is reported to the ISO transport protocol, which relies on the network service provider for such notification.

tcp

normative-requirement §6.4 RECOMMENDED

It is strongly recommended that the CC TPDU always explicitly specify the maximum TPDU size value, because the default maximum TPDU size of 65531 octets violates the ISO Transport negotiation rule that the CC TPDU cannot propose a size greater than the CR TPDU.

tcp

normative-requirement §4 MUST

ITOT mandates the implementation of ISO 8073 Transport Protocol options negotiation, including class negotiation. The initiator proposes a preferred class and optionally an alternative; the responder selects from the defined valid combinations.

tcp

normative-requirement §3.2.3.1 REQUIRED

TCP port 102 is reserved for hosts implementing the ITOT protocol. However, the protocol does not mandate the use of TCP port 102 for all connections; use of any TCP port is conformant.

tcp, registry

normative-requirement §4.2.2 MUST

The Expedited Data TCP connection must be between the same pair of hosts as the Normal Data TCP connection, must not be shared among Transport Connections, and must remain established until the Transport Connection is terminated, at which time it must be closed.

tcp

protocol-element §4.1.1

Class 0 connection establishment allows Connect Data exchange in user data fields of CR and CC TPDUs, negotiation of Expedited Data Transfer Service, and negotiation of non-standard TPDU size up to 65531 octets (default maximum 65531 octets).

tcp

protocol-element §4.2.1

Class 2 connection establishment negotiates up to five options via bits of the Additional Option parameter: Transport Expedited Data Service (bit 1), Reverse Connection procedure (bit 4), Expedited Data Acknowledgement (bit 6), and Non-blocking Expedited Data (bit 7). Explicit Flow Control MUST NOT be negotiated.

tcp

protocol-element §4.2.3

Class 2 connection release supports both Disruptive Disconnect (DR Reason code 0x80, pending data need not be delivered) and Non-Disruptive Disconnect (DR Reason code 0x80 with Additional Information parameter 0x80, requiring all queued TPDUs to be delivered before disconnection). Both exchange DR and DC TPDUs.

tcp

protocol-element §4.2.2

Class 2 Non-blocking Expedited Data service requires the sender to transmit the ED TPDU on both the Normal Data and Expedited Data TCP connections; the receiver counts ED TPDUs on each connection and delivers only the one from the connection with the higher count, preventing Normal Data channel blocking.

tcp

protocol-element §4.2.2

Class 2 supports two procedures for establishing the separate Expedited Data TCP connection: Forward Connection (Splitting and Recombining, defined in ISO 8073) and Reverse Connection (not in ISO 8073), where the responder opens a second TCP connection back to the initiator's listening port before issuing the CC TPDU.

tcp

protocol-element §5

ITOT access point addresses may be represented as printable strings (per RFC1278, extended for IPv6) or as OSI Network Addresses (NSAPAs, per RFC1277 for IPv4 and RFC1888 for IPv6). For IPv6-encoded ITOT addresses, the default selector of the NSAPA is defined as '10000000'B.

ip, tcp

protocol-element §2.3

ITOT defines two transport protocol classes over TCP: Class 0, which refines and supersedes RFC1006 and provides connection establishment, data transfer with segmentation, and NS-provider-based disconnection; and Class 2, which adds explicit transport disconnection and independent Normal and Expedited Data channels.

tcp

protocol-element §3.2.3

TCP is mapped to the ISO 8348 Connection Oriented Network Service (CONS): TCP-OPEN_PORT maps to N-CONNECT.REQUEST, TCP-LISTEN_PORT to N-CONNECT.INDICATION, TCP-SEND_DATA (with TPKT encapsulation) to N-DATA.REQUEST, and TCP-CLOSE or TCP-ERRORED to N-DISCONNECT.INDICATION.

tcp

protocol-element §4.1.2

The Expedited Data (ED) TPDU for Class 0 is an in-band non-standard TPDU with a format nearly identical to the Normal Data (DT) TPDU, distinguished only by its TPDU code; the ED user data field is 1 to 16 octets.

tcp

security-consideration §8

Security issues are not specifically addressed in RFC 2126. The security of ITOT is equivalent to that of the underlying TCP and ISO 8073 protocols; readers are directed to those specifications for further security analysis.

security, tcp

state-machine §6.3

Class negotiation state: the initiator proposes preferred class and optional alternative in the CR TPDU; the responder selects: if preferred=0/alternative=none then class 0; if preferred=2/alternative=0 then class 2 or 0; if preferred=2/alternative=none then class 2. If the selected class differs from preferred, the initiator adjusts operation on receipt of CC.

tcp

wire-format §6.6

The Class 2 Additional Option parameter encodes options in individual bits: bit 1 = Transport Expedited Data Service, bit 4 = Reverse Connection procedure (vs. Forward Connection default), bit 6 = Expedited Data Acknowledgement, bit 7 = Non-blocking Expedited Data. Bits 2, 3, 5, and 8 are not applicable.

tcp

wire-format §4.3

The TPKT packet header consists of four fields: version (8 bits, value 3), reserved (8 bits, value 0), packet length (16 bits, total length of the entire TPKT including header), followed by the variable-length ISO 8073 TPDU. This encapsulation delimits TPDU boundaries over the TCP octet stream.

tcp