Transport Multiplexing Protocol (TMux)

One of the problems with the use of terminal servers is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts. TMux is a protocol which allows multiple short transport segments, independent of application type, to be combined between a server and host pair.

- TMux protocol is intended to optimize the transmission of large numbers of small data packets that are generated in situations where many interactive Telnet and Rlogin sessions are connected to a few hosts on the network.

- TMux protocol may be applicable to other situations where small packets are generated, but this was not considered in the design.

- TMux is designed to improve network utilization and reduce the interrupt load on hosts which conduct multiple sessions involving many short packets.

- TMux is highly constrained in its method of accomplishing this task, seeking simplicity rather than sophistication.

Protocol Design

TMux operates by placing a set of transport segments into the same IP datagram. Each segment is preceded by a TMux mini-header which specifies the segment length and the actual segment transport protocol. The receiving host demultiplexes the individual transport segments and presents them to the transport layer as if they had been received in the usual IP/transport packaging.
Hence, a TMux message appears as:
| IP hdr | TM hdr | Tport segment | TM hdr | Tport segment| ...|

where:
TM hdr : It is a TMux mini-header and specifies the following Tport segment.
Tport segment : It refers to the entire transport segment, including
transport headers.

Header Format

Each 4 octet TMux mini-header has the following general format:
Length high |
+-------------------------------+
| Length low |
+-------------------------------+
| Protocol ID |
+-------------------------------+
| Checksum |
+-------------------------------+
| Transport segment |
| ... |
| ...
Length : It specifies the octet count for this mini header and the following transport segment, from 0-65535 octets.
Protocol ID : It contains the value that would normally have been placed in the IP header Protocol field.
Checksum : This field is the XOR of the first 3 octets.

CLNP (Connectionless Network Protocol)

CLNP is a datagram network protocol. It provides fundamentally the same underlying service to a transport layer as IP. CLNP provides essentially the same maximum datagram size, and for those circumstances where datagrams may need to traverse a network whose maximum packet size is smaller than the size of the datagram, CLNP provides mechanisms for fragmentation (data unit identification, fragment/total length and offset). Like IP, a checksum computed on the CLNP header provides a verification that the information used in processing the CLNP datagram has been transmitted correctly, and a lifetime control mechanism ("Time to Live") imposes a limit on the amount of time a datagram is allowed to remain in the internet system.

CLNP (Connectionless Network Protocol) may be used between network-entities in end systems or in Network Layer relay systems (or both). CLNP is intended for use in the Subnetwork Independent Convergence Protocol (SNICP) role, which operates to construct the OSI Network Service over a defined set of underlying services, performing functions necessary to support the uniform appearance of the OSI Connectionless-mode Network Service over a homogeneous or heterogeneous set of interconnected subnetworks.

CLNP Protocol Structure

- NLP ID - Network Layer Protocol Identifier : The value of this field is set to binary 1000 0001 to identify this Network Layer protocol as ISO 8473. The value of this field is set to binary 0000 0000 to identify the Inactive Network Layer protocol subset.
- Length ID : Length Indicator is the length in octets of the header.
- Version : Version/Protocol Id Extension identifies the standard Version of ISO 8473.
- Lifetime : PDU Lifetime representing the remaining lifetime of the PDU, in units of 500 milliseconds.
- Flags : There are three flags : segmentation permitted, more segments, error report.
- Type : The Type code field identifies the type of the protocol data unit, which could be data PDU or Error Report PDU.
- Segment Length : The Segment Length field specifies the entire length, in octets, of the Derived PDU, including both header and data (if present).
- Checksum : The checksum is computed on the entire PDU header.