doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc1692.txt b/doc/rfc/rfc1692.txt
new file mode 100644
index 0000000..82a6888
--- /dev/null
+++ b/doc/rfc/rfc1692.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                         P. Cameron
+Request for Comments: 1692                  Xylogics, International Ltd.
+Category: Standards Track                                     D. Crocker
+                                                  Silicon Graphics, Inc.
+                                                                D. Cohen
+                                                                 Myricom
+                                                               J. Postel
+                                                                     ISI
+                                                             August 1994
+
+
+                 Transport Multiplexing Protocol (TMux)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   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.
+
+Acknowledgments
+
+   This specification is the result of the merger of two documents: the
+   original TMux proposal which was the result of several discussions
+   and related initiatives through IETF working groups; and IEN 90 [1]
+   originally proposed by Danny Cohen and Jon Postel in May 1979.
+
+Applicability Statement
+
+   The 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.  In these situations, TMux can improve both
+   network and host performance.  TMux is not intended for multiplexing
+   long streams composed of large blocks of data that are typically
+   transmitted by such applications as FTP.
+
+   The TMux protocol may be applicable to other situations where small
+   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 some
+   modification.
+
+1. Introduction
+
+   When network designers consider which protocols generate the most
+   load, they naturally tend to consider protocols which transfer large
+   blocks of data (e.g., FTP, NFS).  What is often not considered is the
+   load generated by Telnet and Rlogin because of the assumption that
+   users type slowly and the packets are very small.  This is a grave
+   underestimation of the load on networks and hosts which have many
+   Telnet and Rlogin ports on multiple terminal servers.
+
+   The problem stems from the fact that the work a host must do to
+   process a 1-octet packet is very nearly as much as the work it must
+   do to process a 1500-octet packet.  That is, it is the overhead of
+   processing a packet which consumes a host's resources, not the
+   processing of the data.
+
+   In particular, communication load is not measured only in bits per
+   seconds but also in packets per seconds, and in many situation the
+   latter is the true performance limit, not the former.  The proposed
+   multiplexing is aimed at alleviating this situation.
+
+   If one assumes that most users connected to a terminal server will be
+   connecting to only a few hosts, then it should be obvious that the
+   network and host load could be greatly reduced if traffic from
+   multiple users, destined for the same host, could be sent in the same
+   packet.
+
+   TMux is designed to improve network utilization and reduce the
+   interrupt load on hosts which conduct multiple sessions involving
+   many short packets.  It does this by multiplexing transport traffic
+   onto a single IP datagram [2], thereby resulting in fewer, larger
+   packets.  TMux is highly constrained in its method of accomplishing
+   this task, seeking simplicity rather than sophistication.
+
+2. Protocol Design
+
+   IP hosts may engage in the use of TMux transparently, and may even
+   switch back and forth between use of TMux and carriage of transport
+   segments in the usual, independent IP datagrams.
+
+   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
+
+
+
+Cameron, Crocker, Cohen & Postel                                [Page 2]
+
+RFC 1692                          TMux                       August 1994
+
+
+   received in the usual IP/transport packaging.  The transport layer
+   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 following
+                  Tport segment.
+
+
+   Tport segment  refers to the entire transport segment, including
+                  transport headers.
+
+   The TMux Protocol is defined to allow the combining of transmission
+   units of different higher level protocols in one transmission unit of
+   a lower level protocol. Only segments with the same Internet Protocol
+   (IP) header, (with the possible exception of the protocol and check-
+   sum fields) may be combined. For example, the segment (H1, B1) and
+   the segment (H2, B2), where Hi and Bi are the headers and the bodies
+   of the segment, respectively, may be combined (multiplexed) only if
+   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 two
+   original segments, (H,B1), and (H,B2), arrived separately.  It is
+   recommended, though not a requirement, that the segments in the TMux
+   message should be processed in the same order that they are in the
+   TMux message.
+
+   The multiplexing is achieved by combining the individual segments,
+   (H,B1) through (H,Bn), into a single message.  This single message
+   has an IP header which is equal to H, but having in the PROTOCOL
+   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.  Each
+   segment, Bi, is preceded by a 4 octet TMux mini header. This contains
+   the number of the protocol to which this segment is addressed. It
+   also contains the total length of this segment, including this mini
+   header. Since this mini header is not otherwise protected by a check-
+   sum, it also includes a checksum field which just covers this mini
+   header.
+
+
+
+
+
+
+
+Cameron, Crocker, Cohen & Postel                                [Page 3]
+
+RFC 1692                          TMux                       August 1994
+
+
+2.1. IP Protocol field value
+
+   TMux is indicated in an IP datagram by the Protocol (ID) value of 18
+   (22 octal), see [3].
+
+2.2. Header Format
+
+   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 and
+   the following transport segment, from 0-65535 octets.  Hence, the
+   length field has a minimum value of 4.  For segments that are larger
+   than the maximum allowed for TMux (see section 5.1), individual IP
+   datagrams should be sent.
+
+   The Protocol ID field contains the value that would normally have
+   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 bit
+   alignment, where the segments being multiplexed are not a multiple of
+   32 bits long, extra octets will be added to re-align the end of the
+   segment, and hence the next segment.  These octets will be ignored on
+   input.  This padding will not affect the LENGTH field, it will still
+   contain the real length of the segment.
+
+2.3. Sending Data
+
+   Host endpoints may choose to use TMux at any time and in either (or
+   both) directions.  They also may switch back and forth between use of
+   TMux packaging and the usual individual IP datagrams for individual
+   transport associations.  The only barrier to the use of TMux is for
+   the sender to know whether TMux is supported by the receiver.  This
+   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 messages
+   to hosts from which a valid TMux message has already been received.
+   This then leaves the problem of one host starting the TMux
+   connection.  This is most easily accomplished by the host sending an
+   IP datagram with no data (i.e., with the IP total length field of
+   20), but with an IP Protocol field value of 18 for TMux.  This is
+   referred to as a TMux ENQ (enquiry) message.  The host receiving this
+   message then knows that the originator supports TMux, and can start
+   to send TMux messages. This will in turn cause the originator of the
+   ENQ message to start to use TMux.  If for any reason the receiver
+   does not intend to send TMux messages to the originator, but is
+   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 to
+   resend the ENQ a while later in case the original ENQ message was
+   lost.  If this again is lost, the ENQ may be repeated as often as
+   needed, but the time between requests should increase exponentially
+   up to a limit of about 1 hour.  Suitable times between ENQs would be
+   15 seconds, 30 seconds, 60 seconds, 120 seconds etc.
+
+   Note that this checking process does not need to impede any of the
+   transport (user) data, which may be sent as convenient, albeit in its
+   less-efficient IP datagram form.
+
+   The only problem with this scheme is that a host which supports TMux
+   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 to
+   maintain a Time To Live (TTL) value for hosts from which TMux
+   messages have been received.  This TTL is a timed TTL, rather than a
+   count as used in the IP TTL field, and this time stamp is updated
+   every time a TMux message is received.  This can then be used to
+   expire the information held by TMux on the host after a suitable
+   time, e.g., 1 minute.
+
+   This TTL time stamp is used as follows. When TMux is passed a segment
+   to be sent to a host, a check is made to see if the time to live has
+   expired.  If the TTL has not expired, the segment is sent in a TMux
+   message as normal.  If the TTL has expired, the host is marked as
+   being unable to TMux, but the segment is STILL sent as a TMux message
+   (i.e., with the normal delay to allow other segments to be
+   multiplexed).  If the host is really unable to TMux anymore (a rare
+   occurrence) then this segment will be timed out and retried by the
+   transport provider i.e., TCP.  Because the host was marked as not
+   able to TMux, the retry will be sent as a normal IP datagram.  If the
+   remote host is still able to TMux then it should send back TMux
+   traffic (even if it has been rebooted), typically a TCP window
+   update, and the local host will mark it as able to TMux again. This
+   way of operating removes any performance problem caused by
+
+
+
+Cameron, Crocker, Cohen & Postel                                [Page 5]
+
+RFC 1692                          TMux                       August 1994
+
+
+   continually dropping out of TMuxing and having to send probe
+   messages.  If the IP datagram to be sent is from UDP, then the remote
+   host may not send anything in reply. So for UDP this scheme will not
+   be any better than just stopping sending TMux messages to the host,
+   but it is also no worse.
+
+3.  Protocol Behavior
+
+3.1. Transport Flow Control
+
+   TMux operates as an extension to the IP datagram protocol.  Hence, it
+   has no impact on most flow control mechanisms, since they operate at
+   the transport layer -- above TMux.
+
+3.2. Connection Management
+
+   The concept of a connection pertains to certain transport protocols,
+   but not to IP or to TMux.  Hence, when connection management is
+   required by a transport protocol using TMux, it occurs in the same
+   fashion as it does for IP.  In fact, the transport protocol is not to
+   be aware that TMux is being used.
+
+3.3 Multiplexed Message Construction
+
+   When a transport provider (e.g., TCP or UDP) sends a segment, TMux
+   first removes the IP header (if present) and adds a TMux mini-header
+   and the segment to the Multiplexed Message under construction for the
+   host specified by the destination address of the segment.
+
+   When the first message to be transmitted is placed into the
+   Multiplexed Message under construction, a timer is started.  When the
+   timer expires, the Multiplexed Message under construction is
+   transmitted. This ensures that all segments available for sending
+   before the timer expires are sent in a single Multiplexed Message.
+   If, during construction of the Multiplexed Message, the buffer
+   holding the message fills, the Multiplexed Message is transmitted
+   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 a
+   reasonable probability of sending multiple segments but not so large
+   that the echo response time becomes a problem.  This suggests that
+   the upper limit for the timer is probably 1/10th second.  As the cost
+   of using timeouts on many systems is quite large, it is recommended
+   that a single timer be used and that all TMux messages under
+   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 included
+   data segments or the maximum size of the Multiplexed Message before
+   it is transmitted.  It is also suggested that larger segments (e.g.,
+   those over 700 octets) should be sent as standard IP datagrams, and
+   not multiplexed.  This is to ensure that the delay caused by the TMux
+   timer does not put a delay on those segments for which it is
+   inadvisable.  The size of the largest segments to be multiplexed
+   should (if possible) be configurable.
+
+4. Protocol Example
+
+   This example shows a TMux message consisting of three multiplexed
+   segments:
+
+   A TCP segment consisting of a 20 octet TCP header, 5 octets of data
+   and 3 octets of padding.  Thus the length field is
+
+             Mini header + TCP header + data
+           =     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 data
+   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 Suggestion
+
+5.1 Maximum TMux Message Size
+
+   In section 3.3, a note is made about sending messages immediately if
+   the limit on TMux message size is reached.  On systems where Path MTU
+   Discovery (as per RFC 1191 [4]) has been implemented this should be
+   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 Multiplex
+
+   It is the responsibility of the sender to decide which segments
+   should be TMux'd and which should not.  For example, segments sent by
+   FTP should not normally be multiplexed.  In many situations, it may
+   be sensible to restrict the sessions that can be multiplexed to just
+   those involved in interactive traffic (Telnet and Rlogin) by
+   examining the source and destination TCP port numbers.  However, if a
+   segment that would not normally be multiplexed is to be sent and a
+   TMux message is already under construction, then the extra segment
+
+
+
+Cameron, Crocker, Cohen & Postel                                [Page 8]
+
+RFC 1692                          TMux                       August 1994
+
+
+   can be added to the TMux message under construction, and this
+   complete message should be sent immediately, rather than waiting for
+   the timer to expire.
+
+6. Implementation notes
+
+   The following notes are the result of experience gained during the
+   testing of early implementations of TMux.  Whilst they do not form
+   part of the actual standard, they should be followed if possible to
+   ensure compatibility with other implementations.
+
+   Because the TMux mini-header does not contain a TOS field, only
+   segments with the same IP TOS field should be contained in a single
+   TMux message.  As most systems do not use the TOS feature, this is
+   not a major restriction.  Where the TOS field is used, it may be
+   desirable to hold several messages under construction for a host, one
+   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 not
+   candidates for multiplexing.
+
+   Only segments with a source or destination port that is for an
+   interactive session (i.e., Telnet and Rlogin) should be considered
+   for multiplexing using TMux.
+
+   If an error is discovered in a checksum of a TMux header, the rest of
+   the message, starting there, is ignored.  If an unknown PROTOCOL
+   field is discovered in any TMux header, this segment, and only this
+   one, is ignored.
+
+   If the TMux implementation is continually sending TMux messages
+   containing exactly one segment (because is there is little traffic to
+   multiplex), then TMux may be turned off.  This implies that TMux may
+   be switched off when there is no congestion.
+
+   To prevent intermediate nodes from fragmenting and reconstructing
+   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 have
+   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, so
+   causing B to respond and so on.  Thus if this facility is used, code
+   must be included to prevent this looping behavior happening.  Sending
+
+
+
+Cameron, Crocker, Cohen & Postel                                [Page 9]
+
+RFC 1692                          TMux                       August 1994
+
+
+   an ENQ in response to an ENQ is not recommended, except in special
+   circumstances.
+
+   It is recommended that the following aspects of the TMux protocol be
+   user configurable:
+
+      The maximum size of a segment that can be multiplexed by TMux.
+
+      The delay between the first segment being placed into the message
+      under construction and the message being sent.
+
+7. Security Considerations
+
+   Because TMux is effectively an extension to IP, it does not have any
+   more impact on site security than does IP.  Security should be dealt
+   with by upper layer protocols.
+
+   Because some routers filter packets on the TCP port numbers, any
+   segments sent using TMux will not be subject to this filtering as it
+   will obscure the TCP port number However, larger segments for the
+   same TCP connection will still be sent as IP datagrams, and so will
+   be subject to filtering, thus giving rise to a potential problem.
+   For this reason, any routers that do not support TMux, but which do
+   support this type of filtering should not allow TMux messages through
+   (in either direction).  This will cause both hosts to think the other
+   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 the
+   TMux protocol, and to inspect each of the multiplexed segments and
+   remove those segments that fail the filtering.
+
+8. References
+
+   [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/Information
+       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, DECWRL
+       and Stanford University, November 1990.
+
+
+
+
+
+
+Cameron, Crocker, Cohen & Postel                               [Page 10]
+
+RFC 1692                          TMux                       August 1994
+
+
+9. Authors' Addresses
+
+       Peter Cameron
+       Xylogics International, Ltd.
+       Featherstone Rd.
+       Wolverton Mill
+       Milton Keynes
+       MK12 5RD
+       United Kingdom
+
+       Phone: +44  908 222112
+       Fax:   +44  908 222115
+       EMail: cameron@xylint.co.uk
+
+
+       David Crocker
+       Silicon Graphics, Inc.
+       2011 N. Shoreline Blvd.
+       P.O. Box 7311
+       Mountain View, CA 94039-7311
+       USA
+
+       Phone: +1 415 390 1804
+       Fax:   +1 415 962 8404
+       EMail: dcrocker@sgi.com
+
+
+       Danny Cohen
+       Myricom
+       325 N. Santa Anita Ave.
+       Arcadia, CA 91006
+       USA
+
+       Phone: +1 818 821 5555
+       EMail: Cohen@myricom.com
+
+
+       Jon Postel
+       USC/Information Sciences Institute
+       4676 Admiralty Way
+       Marina del Rey, CA  90292-6695
+       USA
+
+       Phone: +1 310 822 1511
+       Fax:   +1 310 823 6714
+       EMail: Postel@ISI.EDU
+
+
+
+
+
+Cameron, Crocker, Cohen & Postel                               [Page 11]
+
+RFC 1692                          TMux                       August 1994
+
+
+10. Discussion List
+
+       There is a discussion list for this protocol, which for
+       historical reasons is called:
+
+           cmp-id@xylint.co.uk
+
+   Requests to join the list should be sent to:
+
+           cmp-id-request@xylint.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cameron, Crocker, Cohen & Postel                               [Page 12]
+