Summary

  • RFC 892 gave a Transport Connection its own pair of endpoint-selected references, independent of the Network Connection carrying its protocol units.
  • The mapping worked in both directions: several transport connections could share one network connection, while class 4 could split one transport connection across several carriers.
  • Independence had limits. Network quality, pervasive carrier state, negotiated class and per-class recovery rules decided whether a carrier could be reused, replaced or treated as the lifetime of the transport connection itself.

The word “connection” appears at two different layers in RFC 892. A Network Connection joined two transport entities through the service below. A Transport Connection joined two transport users through the protocol above. Confusing the two would have made the simplest class easy to describe and the rest of the architecture impossible.

Before a Transport Connection could carry data, it had to be assigned to one Network Connection—or to more than one when splitting was available. The carrier might already exist or be created for the purpose. Assignment was therefore a local operational decision, not the birth certificate of the transport state.

This distinction was published in an unusual institutional setting. RFC 892 reproduced an ISO transport specification for information and explicitly said that it did not define an ARPA-Internet standard. RFC 905 superseded it a few months later with a newer ISO DP 8073 text under the same informational boundary. The RFC series was acting as a window into another standards project, not silently converting that project into Internet law.

Two references named one transport connection

Connection establishment began with a Connection Request, or CR TPDU, and a Connection Confirm, or CC TPDU. The initiator supplied a 16-bit source reference. The responder supplied its own reference in the confirmation. Each side chose the value the other side would use as the destination reference.

The values were local and bounded. A reference could not be zero, already in use or still frozen after an earlier connection. They were not global names, public identities or credentials. Their power came from the state table at the receiving transport entity.

RFC 892 called the arrangement symmetrical. Neither partner had to be declared master or slave, and simultaneous call handling did not depend on a central reference allocator. More importantly, the document said that the references identified the Transport Connection independently of the Network Connection.

That independence was evidentiary, not metaphysical. A TPDU arriving on a carrier still needed a recognised source/destination context and a live assignment. The reference answered “which transport state?” It did not answer “who is this organisation?”, “is this action authorised?” or “will the application accept the data?”

The request proposed a class; the confirmation selected it

RFC 892 did not define one transport behavior. It defined five classes: simple class 0; basic error-recovery class 1; multiplexing class 2; error-recovery-and-multiplexing class 3; and error-detection-and-recovery class 4.

The initiator proposed a preferred class and could list alternatives, except that a class-0 preference permitted no alternatives. While waiting, it could act on the assumption that its preference would be accepted. That assumption was provisional. The responder's CC carried the selected class, and the initiator had to adjust its functions if the permitted selection differed.

Other parameters retained their own negotiation. The responder could accept the proposed maximum TPDU size or choose a smaller permitted size down to the defined floor. Proposed options in the CR became selected options in the CC. A successful network connection, a syntactically valid CR and the caller's preference were three different facts; none alone proved the final operating contract.

The available network service helped shape the choice. RFC 892 distinguished network qualities by residual errors and signalled failures. User requirements and cost also mattered. A Network Connection could be unsuitable because it could not meet the Transport Connection's quality requirement or because its existing use of a pervasive function conflicted with the proposed class.

Sharing worked in both directions

Multiplexing mapped several Transport Connections onto one Network Connection. Each TPDU carried a destination reference so the receiver could return it to the correct transport state. The carrier was shared, but the conversations were not merged.

Sharing did create coupling. Some functions were “pervasive”: once used for the first Transport Connection on a Network Connection, they applied to every Transport Connection that used that carrier during its lifetime. A lower-layer resource could therefore be non-identifying and still impose common behavior on everything above it.

The inverse mapping appeared in splitting and recombining. RFC 892 described using multiple Network Connections for one Transport Connection to improve resilience, throughput or for another reason. Its class/function table did not offer this everywhere; the mechanism belonged to the most capable error-detection-and-recovery class. The article's claim is not that every ISO transport connection was multipath. It is that the architecture had vocabulary for one transport state above several carriers.

Reassignment supplied another boundary. When a Network Connection disappeared, the recovery classes that invoked the mechanism could assign the Transport Connection to another carrier and resynchronise. The peer recognised the new assignment from a valid TPDU arriving on a Network Connection whose addresses still implied the same transport entities.

Class 0 exposes the limit. It had no explicit transport release procedure, and its Transport Connection lifetime was directly correlated with the Network Connection lifetime. The architecture did not promise independence by slogan. It made the degree of independence a class-specific capability.

A later Internet mapping changed the carrier again

The separation became concrete when designers placed ISO transport services over TCP. RFC 983 proposed an ISO TSAP-facing service whose internals used TCP/IP. Its stated aim was to let higher ISO session, presentation and application entities operate without knowing that the lower service was TCP. It also refused to claim a complete transition plan.

RFC 1006 superseded that proposal with version 3 and an Internet standard for ISO transport class 0 over TCP. TCP supplied a reliable connection-oriented service, but it delivered an octet stream rather than discrete Network Service Data Units. RFC 1006 therefore wrapped each TPDU in a length-delimited TPKT. The wrapper restored a boundary; it did not authenticate the sender or protect content integrity.

The mapping deliberately collapsed some of RFC 892's freedom. A TCP open supplied the lower connection; closing TCP supplied the disconnect; class 0 ran above it. Still, the ISO transport interface and TPDU contract survived over a carrier that the 1983 text had not specified as the ARPA standard.

RFC 2126 later refined the arrangement for TCP over IPv4 or IPv6 and described class 0 and class 2 variants. It preserved TPKT version compatibility partly to protect the installed RFC 1006 base. It also separated the registry fact from a universal routing rule: TCP port 102 was reserved, but conforming connections could use another port.

The current IANA service-name and port registry records iso-tsap at port 102. That row proves coordination of a number. It does not prove that a listener implements a particular class, that a CR was confirmed, that the reference maps to live state or that any application exchange succeeded.

Sources and limits

This account uses RFC 892, its superseding edition RFC 905, the TCP mappings in RFC 983, RFC 1006 and RFC 2126, and the IANA registry. They establish specified mechanisms, document status and the later carrier mapping. They do not establish current deployment, direct ancestry to QUIC or SCTP, universal use of splitting or reassignment, authenticated peers, successful OSI transition, or a named implementation's behavior.