As per Relevance of the word transport, we have this rfc below:
Network Working Group P.
Request for Comments: 1692 Xylogics, International Ltd
Category: Standards Track D.
Silicon Graphics, Inc
D.
J.
August 1994
Transport Multiplexing Protocol (TMux
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
One of the problems with the use of terminal servers is the
number of small packets they can generate. Frequently, most of
packets are destined for only one or two hosts. TMux is a
which allows multiple short transport segments, independent
application type, to be combined between a server and host pair
This specification is the result of the merger of two documents:
original TMux proposal which was the result of several
and related initiatives through IETF working groups; and IEN 90 [1]
originally proposed by Danny Cohen and Jon Postel in May 1979.
Applicability
The TMux protocol is intended to optimize the transmission of
numbers of small data packets that are generated in situations
many interactive Telnet and Rlogin sessions are connected to a
hosts on the network. In these situations, TMux can improve
network and host performance. TMux is not intended for
long streams composed of large blocks of data that are
transmitted by such applications as FTP
The TMux protocol may be applicable to other situations where
packets are generated, but this was not considered in the design
Cameron, Crocker, Cohen & Postel [Page 1]
RFC 1692 TMux August 1994
The use of the TMux protocol in any other situation may require
modification
1.
When network designers consider which protocols generate the
load, they naturally tend to consider protocols which transfer
blocks of data (e.g., FTP, NFS). What is often not considered is
load generated by Telnet and Rlogin because of the assumption
users type slowly and the packets are very small. This is a
underestimation of the load on networks and hosts which have
Telnet and Rlogin ports on multiple terminal servers
The problem stems from the fact that the work a host must do
process a 1-octet packet is very nearly as much as the work it
do to process a 1500-octet packet. That is, it is the overhead
processing a packet which consumes a host's resources, not
processing of the data
In particular, communication load is not measured only in bits
seconds but also in packets per seconds, and in many situation
latter is the true performance limit, not the former. The
multiplexing is aimed at alleviating this situation
If one assumes that most users connected to a terminal server will
connecting to only a few hosts, then it should be obvious that
network and host load could be greatly reduced if traffic
multiple users, destined for the same host, could be sent in the
packet
TMux is designed to improve network utilization and reduce
interrupt load on hosts which conduct multiple sessions
many short packets. It does this by multiplexing transport
onto a single IP datagram [2], thereby resulting in fewer,
packets. TMux is highly constrained in its method of
this task, seeking simplicity rather than sophistication
2. Protocol
IP hosts may engage in the use of TMux transparently, and may
switch back and forth between use of TMux and carriage of
segments in the usual, independent IP datagrams
TMux operates by placing a set of transport segments into the same
datagram. Each segment is preceded by a TMux mini-header
specifies the segment length and the actual segment
protocol. The receiving host demultiplexes the individual
segments and presents them to the transport layer as if they had
Cameron, Crocker, Cohen & Postel [Page 2]
RFC 1692 TMux August 1994
received in the usual IP/transport packaging. The transport
is, therefore, unaware of the special encapsulation which was used
Hence, a TMux message appears as
| IP hdr | TM hdr | Tport segment | TM hdr | Tport segment| ...|
Where
TM hdr is a TMux mini-header and specifies the
Tport segment
Tport segment refers to the entire transport segment,
transport headers
The TMux Protocol is defined to allow the combining of
units of different higher level protocols in one transmission unit
a lower level protocol. Only segments with the same Internet
(IP) header, (with the possible exception of the protocol and check
sum fields) may be combined. For example, the segment (H1, B1)
the segment (H2, B2), where Hi and Bi are the headers and the
of the segment, respectively, may be combined (multiplexed) only
H=H1=H2. The combined TMux message is either (H, B1, B2) or (H, B2,
B1).
The receiver of this combined message should treat it as if the
original segments, (H,B1), and (H,B2), arrived separately. It
recommended, though not a requirement, that the segments in the
message should be processed in the same order that they are in
TMux message
The multiplexing is achieved by combining the individual segments
(H,B1) through (H,Bn), into a single message. This single
has an IP header which is equal to H, but having in the
field the value 18 which is the protocol number of the TMux protocol
This IP header is followed by all the segments, B1 through Bn.
segment, Bi, is preceded by a 4 octet TMux mini header. This
the number of the protocol to which this segment is addressed.
also contains the total length of this segment, including this
header. Since this mini header is not otherwise protected by a check
sum, it also includes a checksum field which just covers this
header
Cameron, Crocker, Cohen & Postel [Page 3]
RFC 1692 TMux August 1994
2.1. IP Protocol field
TMux is indicated in an IP datagram by the Protocol (ID) value of 18
(22 octal), see [3].
2.2. Header
Each 4 octet TMux mini-header has the following general format
+-------------------------------+
| Length high |
+-------------------------------+
| Length low |
+-------------------------------+
| Protocol ID |
+-------------------------------+
| Checksum |
+-------------------------------+
| Transport segment |
| ... |
| ... |
The LENGTH field specifies the octet count for this mini header
the following transport segment, from 0-65535 octets. Hence,
length field has a minimum value of 4. For segments that are
than the maximum allowed for TMux (see section 5.1), individual
datagrams should be sent
The Protocol ID field contains the value that would normally
been placed in the IP header Protocol field
The 'Checksum' field is the XOR of the first 3 octets
To ensure that TCP, UDP and other segments keep their 32
alignment, where the segments being multiplexed are not a multiple
32 bits long, extra octets will be added to re-align the end of
segment, and hence the next segment. These octets will be ignored
input. This padding will not affect the LENGTH field, it will
contain the real length of the segment
2.3. Sending
Host endpoints may choose to use TMux at any time and in either (
both) directions. They also may switch back and forth between use
TMux packaging and the usual individual IP datagrams for
transport associations. The only barrier to the use of TMux is
the sender to know whether TMux is supported by the receiver.
is important, since early use of TMux is likely to be limited
Cameron, Crocker, Cohen & Postel [Page 4]
RFC 1692 TMux August 1994
The easiest way to detect TMUX support is to only send TMux
to hosts from which a valid TMux message has already been received
This then leaves the problem of one host starting the
connection. This is most easily accomplished by the host sending
IP datagram with no data (i.e., with the IP total length field
20), but with an IP Protocol field value of 18 for TMux. This
referred to as a TMux ENQ (enquiry) message. The host receiving
message then knows that the originator supports TMux, and can
to send TMux messages. This will in turn cause the originator of
ENQ message to start to use TMux. If for any reason the
does not intend to send TMux messages to the originator, but
prepared to accept them, then it can reply with another ENQ message
If an ENQ message does not get a response, then it is reasonable
resend the ENQ a while later in case the original ENQ message
lost. If this again is lost, the ENQ may be repeated as often
needed, but the time between requests should increase
up to a limit of about 1 hour. Suitable times between ENQs would
15 seconds, 30 seconds, 60 seconds, 120 seconds etc
Note that this checking process does not need to impede any of
transport (user) data, which may be sent as convenient, albeit in
less-efficient IP datagram form
The only problem with this scheme is that a host which supports
may stop supporting it, as might happen when the host is re-booted
Other hosts need to learn of this change. The solution to this is
maintain a Time To Live (TTL) value for hosts from which
messages have been received. This TTL is a timed TTL, rather than
count as used in the IP TTL field, and this time stamp is
every time a TMux message is received. This can then be used
expire the information held by TMux on the host after a
time, e.g., 1 minute
This TTL time stamp is used as follows. When TMux is passed a
to be sent to a host, a check is made to see if the time to live
expired. If the TTL has not expired, the segment is sent in a
message as normal. If the TTL has expired, the host is marked
being unable to TMux, but the segment is STILL sent as a TMux
(i.e., with the normal delay to allow other segments to
multiplexed). If the host is really unable to TMux anymore (a
occurrence) then this segment will be timed out and retried by
transport provider i.e., TCP. Because the host was marked as
able to TMux, the retry will be sent as a normal IP datagram. If
remote host is still able to TMux then it should send back
traffic (even if it has been rebooted), typically a TCP
update, and the local host will mark it as able to TMux again.
way of operating removes any performance problem caused
Cameron, Crocker, Cohen & Postel [Page 5]
RFC 1692 TMux August 1994
continually dropping out of TMuxing and having to send
messages. If the IP datagram to be sent is from UDP, then the
host may not send anything in reply. So for UDP this scheme will
be any better than just stopping sending TMux messages to the host
but it is also no worse
3. Protocol
3.1. Transport Flow
TMux operates as an extension to the IP datagram protocol. Hence,
has no impact on most flow control mechanisms, since they operate
the transport layer -- above TMux
3.2. Connection
The concept of a connection pertains to certain transport protocols
but not to IP or to TMux. Hence, when connection management
required by a transport protocol using TMux, it occurs in the
fashion as it does for IP. In fact, the transport protocol is not
be aware that TMux is being used
3.3 Multiplexed Message
When a transport provider (e.g., TCP or UDP) sends a segment,
first removes the IP header (if present) and adds a TMux mini-
and the segment to the Multiplexed Message under construction for
host specified by the destination address of the segment
When the first message to be transmitted is placed into
Multiplexed Message under construction, a timer is started. When
timer expires, the Multiplexed Message under construction
transmitted. This ensures that all segments available for
before the timer expires are sent in a single Multiplexed Message
If, during construction of the Multiplexed Message, the
holding the message fills, the Multiplexed Message is
immediately
The delay time should be user configurable; a reasonable time is 20
to 30 milliseconds. The time period should be large enough to give
reasonable probability of sending multiple segments but not so
that the echo response time becomes a problem. This suggests
the upper limit for the timer is probably 1/10th second. As the
of using timeouts on many systems is quite large, it is
that a single timer be used and that all TMux messages
construction are sent when the timer expires
Cameron, Crocker, Cohen & Postel [Page 6]
RFC 1692 TMux August 1994
Additionally, configuration options may limit the number of
data segments or the maximum size of the Multiplexed Message
it is transmitted. It is also suggested that larger segments (e.g.,
those over 700 octets) should be sent as standard IP datagrams,
not multiplexed. This is to ensure that the delay caused by the
timer does not put a delay on those segments for which it
inadvisable. The size of the largest segments to be
should (if possible) be configurable
4. Protocol
This example shows a TMux message consisting of three
segments
A TCP segment consisting of a 20 octet TCP header, 5 octets of
and 3 octets of padding. Thus the length field
Mini header + TCP header +
= 4 + 20 + 5
= 29
The padding is NOT included in the length
A TCP segment consisting of a 20 octet TCP header, 4 octets of data
This segment does not require padding
A UDP segment consisting of a 4 octet UDP header, 41 octets of
and 3 octets of padding
+-------------------------------+
| Length = 29 |
| (2 octets) |
+-------------------------------+
| Protocol ID = 6 (TCP) |
+-------------------------------+
| Checksum |
+-------------------------------+
| TCP Header |
| (20 octets) |
+-------------------------------+
| TCP data |
| (5 octets) |
+-------------------------------+
| Padding |
| (3 octets) |
+-------------------------------+
| Length = 28 |
| (2 octets) |
Cameron, Crocker, Cohen & Postel [Page 7]
RFC 1692 TMux August 1994
+-------------------------------+
| Protocol ID = 6 (TCP) |
+-------------------------------+
| Checksum |
+-------------------------------+
| TCP Header |
| (20 octets) |
+-------------------------------+
| TCP data |
| (4 octets) |
+-------------------------------+
| Length = 49 |
| (2 octets) |
+-------------------------------+
| Protocol ID = 17 (UDP) |
+-------------------------------+
| Checksum |
+-------------------------------+
| UDP Header |
| (4 octets) |
+-------------------------------+
| UDP data |
| (41 octets) |
+-------------------------------+
| Padding |
| (3 octets) |
+-------------------------------+
5. Implementation
5.1 Maximum TMux Message
In section 3.3, a note is made about sending messages immediately
the limit on TMux message size is reached. On systems where Path
Discovery (as per RFC 1191 [4]) has been implemented this should
used to discover the maximum message size that can be transmitted
and this should be used as the maximum TMux message size
5.2 Deciding Which Segments to
It is the responsibility of the sender to decide which
should be TMux'd and which should not. For example, segments sent
FTP should not normally be multiplexed. In many situations, it
be sensible to restrict the sessions that can be multiplexed to
those involved in interactive traffic (Telnet and Rlogin)
examining the source and destination TCP port numbers. However, if
segment that would not normally be multiplexed is to be sent and
TMux message is already under construction, then the extra
Cameron, Crocker, Cohen & Postel [Page 8]
RFC 1692 TMux August 1994
can be added to the TMux message under construction, and
complete message should be sent immediately, rather than waiting
the timer to expire
6. Implementation
The following notes are the result of experience gained during
testing of early implementations of TMux. Whilst they do not
part of the actual standard, they should be followed if possible
ensure compatibility with other implementations
Because the TMux mini-header does not contain a TOS field,
segments with the same IP TOS field should be contained in a
TMux message. As most systems do not use the TOS feature, this
not a major restriction. Where the TOS field is used, it may
desirable to hold several messages under construction for a host,
for each TOS value
Segments containing IP options should not be multiplexed
Only unicast addresses should be considered for multiplexing
Segments addressed to the loopback address (127.0.0.1) are
candidates for multiplexing
Only segments with a source or destination port that is for
interactive session (i.e., Telnet and Rlogin) should be
for multiplexing using TMux
If an error is discovered in a checksum of a TMux header, the rest
the message, starting there, is ignored. If an unknown
field is discovered in any TMux header, this segment, and only
one, is ignored
If the TMux implementation is continually sending TMux
containing exactly one segment (because is there is little traffic
multiplex), then TMux may be turned off. This implies that TMux
be switched off when there is no congestion
To prevent intermediate nodes from fragmenting and
TMux frames, implementations may want to set the "do not fragment
flag in the IP datagram of TMux messages
If host B receives a TMux ENQ message from host A, but does not
any data for host A, then it may also send back an ENQ message
However, host A may send another ENQ message in response to this,
causing B to respond and so on. Thus if this facility is used,
must be included to prevent this looping behavior happening.
Cameron, Crocker, Cohen & Postel [Page 9]
RFC 1692 TMux August 1994
an ENQ in response to an ENQ is not recommended, except in
circumstances
It is recommended that the following aspects of the TMux protocol
user configurable
The maximum size of a segment that can be multiplexed by TMux
The delay between the first segment being placed into the
under construction and the message being sent
7. Security
Because TMux is effectively an extension to IP, it does not have
more impact on site security than does IP. Security should be
with by upper layer protocols
Because some routers filter packets on the TCP port numbers,
segments sent using TMux will not be subject to this filtering as
will obscure the TCP port number However, larger segments for
same TCP connection will still be sent as IP datagrams, and so
be subject to filtering, thus giving rise to a potential problem
For this reason, any routers that do not support TMux, but which
support this type of filtering should not allow TMux messages
(in either direction). This will cause both hosts to think the
does not support TMux, so all segments will be sent as IP datagrams
thus eliminating this problem
A better solution to this problem, is for routers to understand
TMux protocol, and to inspect each of the multiplexed segments
remove those segments that fail the filtering
8.
[1] Cohen, D., and Postel, J., "Multiplexing Protocol", IEN 90,
USC/Information Sciences Institute,, May 1979.
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/
Sciences Institute, September 1981.
[3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, March 1990.
[4] Mogul, J., and S. Deering, "Path MTU discovery", RFC 1191,
and Stanford University, November 1990.
Cameron, Crocker, Cohen & Postel [Page 10]
RFC 1692 TMux August 1994
9. Authors'
Peter
Xylogics International, Ltd
Featherstone Rd
Wolverton
Milton
MK12 5
United
Phone: +44 908 222112
Fax: +44 908 222115
EMail: cameron@xylint.co.
David
Silicon Graphics, Inc
2011 N. Shoreline Blvd
P.O. Box 7311
Mountain View, CA 94039-7311
Phone: +1 415 390 1804
Fax: +1 415 962 8404
EMail: dcrocker@sgi.
Danny
325 N. Santa Anita Ave
Arcadia, CA 91006
Phone: +1 818 821 5555
EMail: Cohen@myricom.
Jon
USC/Information Sciences
4676 Admiralty
Marina del Rey, CA 90292-6695
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: Postel@ISI.
Cameron, Crocker, Cohen & Postel [Page 11]
RFC 1692 TMux August 1994
10. Discussion
There is a discussion list for this protocol, which
historical reasons is called
cmp-id@xylint.co.
Requests to join the list should be sent to
cmp-id-request@xylint.co.
Cameron, Crocker, Cohen & Postel [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
