rfc1692.txt

中、英文RFC文档大全打包下载完全版 .


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: [phone]
       Fax:   [phone]
       EMail: [e-mail]


       David Crocker
       Silicon Graphics, Inc.
       2011 N. Shoreline Blvd.
       P.O. Box 7311
       Mountain View, CA 94039-7311
       USA

       Phone: [phone]
       Fax:   [phone]
       EMail: [e-mail]


       Danny Cohen
       Myricom
       325 N. Santa Anita Ave.
       Arcadia, CA 91006
       USA

       Phone: [phone]
       EMail: [e-mail]


       Jon Postel
       USC/Information Sciences Institute
       4676 Admiralty Way
       Marina del Rey, CA  90292-6695
       USA

       Phone: [phone]
       Fax:   [phone]
       EMail: [e-mail]





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:

           [e-mail]

   Requests to join the list should be sent to:

           [e-mail]









































Cameron, Crocker, Cohen & Postel                               [Page 12]