RFC1692 日本語訳

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

コメントを求めるワーキンググループP.キャメロンの要求をネットワークでつないでください: 1692Xylogics、国際株式会社カテゴリ: 標準化過程D.医者シリコングラフィックスD.コーエンMyricom J.ポステルISI1994年8月

                 Transport Multiplexing Protocol (TMux)

輸送マルチプレクシングプロトコル(TMux)

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

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.

端末のサーバの使用に関する問題の1つはそれらが発生させることができる多くの小型小包です。 頻繁に、これらのパケットの大部分は1か2人のホストだけのために運命づけられています。 TMuxは、サーバとホスト組の間で結合されるためにはアプリケーションタイプの如何にかかわらず複数の短い輸送セグメントを許容するプロトコルです。

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.

この仕様は2通のドキュメントの合併の結果です: IETFワーキンググループを通したいくつかの議論と関連するイニシアチブの結果であったオリジナルのTMux提案。 そして、IEN90[1]は1979年5月に元々、ダニー・コーエンとジョン・ポステルで提案しました。

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.

TMuxプロトコルが多くの対話的なTelnetとRloginセッションがネットワークの数人のホストに接される状況で発生する多くの小さいデータ・パケットのトランスミッションを最適化することを意図します。 これらの状況で、TMuxはネットワークとホスト性能の両方を向上させることができます。 TMuxは、FTPのようなアプリケーションで通常送られる大量株のデータで構成された長い流れを多重送信するために意図しません。

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

TMuxプロトコルは小型小包が発生しましたが、これがデザインでは考えられなかった他の状況に適切であるかもしれません。

Cameron, Crocker, Cohen & Postel                                [Page 1]

RFC 1692                          TMux                       August 1994

キャメロン、クロッカー、コーエン、およびポステル[1ページ]RFC1692TMux1994年8月

   The use of the TMux protocol in any other situation may require some
   modification.

いかなる他の状況におけるTMuxプロトコルの使用も何らかの変更を必要とするかもしれません。

1. Introduction

1. 序論

   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.

ネットワーク設計者が、どのプロトコルが最も多くの負荷を発生させるかを考えると、それらは、自然に大量株のデータ(例えば、FTP、NFS)を移すプロトコルを考える傾向があります。 しばしば考えられるというわけではないことはTelnetとRloginによってユーザがゆっくりタイプして、パケットが非常に小さいという仮定のために発生した負荷です。 これは、ネットワークにおける負荷の荘重な過小評価であり、どれに多くのTelnetがあるか、そして、複数の端末のサーバのRloginポートを接待します。

   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.

問題はホストが1八重奏のパケットを処理するためにしなければならない仕事がほとんどそれが1500八重奏のパケットを処理するためにしなければならない仕事であるという事実によります。 すなわち、それはデータの処理ではなく、ホストのリソースを消費するパケットを処理するオーバーヘッドです。

   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.

特に、通信負荷は1秒単位で単にビットで測定されるのではなく、1秒あたりのパケットで測定もされます、そして、多くの状況で、後者は前者ではなく、本当の性能限界です。 提案されたマルチプレクシングはこのような事態を改善するのを目的とされます。

   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.

TMuxは、ネットワーク利用を改良して、ホストで中断負荷を減少させるように設計されています(複数のセッションにかかわる多くの脆いパケットを行います)。 それは、単一のIPデータグラム[2]に輸送交通を多重送信することによって、その結果、より少なくて、より大きいパケットをもたらすことでこれをします。 TMuxは洗練よりむしろ簡単さを求めて、このタスクを達成する方法で非常に抑制されます。

2. Protocol Design

2. プロトコルデザイン

   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.

IPホストは、透明にTMuxの使用に従事して、普通の、そして、独立しているIPデータグラムでTMuxの使用と輸送セグメントの運搬を前後に切り換えさえするかもしれません。

   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

TMuxは、1セットの輸送区分を同じIPデータグラムに置くことによって、作動します。 各セグメントはセグメントの長さと実際のセグメントトランスポート・プロトコルを指定するTMuxミニヘッダーによって先行されています。 受信ホストは、個々の輸送セグメントを反多重送信して、まるでそれらがあったかのようにトランスポート層にそれらを提示します。

Cameron, Crocker, Cohen & Postel                                [Page 2]

RFC 1692                          TMux                       August 1994

キャメロン、クロッカー、コーエン、およびポステル[2ページ]RFC1692TMux1994年8月

   received in the usual IP/transport packaging.  The transport layer
   is, therefore, unaware of the special encapsulation which was used.

普通のIP/輸送包装では、受け取られています。 したがって、使用されたトランスポート層が特別なカプセル化に気づかない状態であります。

   Hence, a TMux message appears as:

したがって、TMuxメッセージは以下として現れます。

     | IP hdr | TM hdr | Tport segment | TM hdr | Tport segment| ...|

| IP hdr| TM hdr| Tportセグメント| TM hdr| Tportセグメント| ...|

   Where:

どこ:

   TM hdr         is a TMux mini-header and specifies the following
                  Tport segment.

TM hdrはTMuxミニヘッダーであり、以下のTportセグメントを指定します。

   Tport segment  refers to the entire transport segment, including
                  transport headers.

輸送ヘッダーを含んでいて、Tportセグメントは全体の輸送セグメントについて言及します。

   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).

TMuxプロトコルは、下のレベルプロトコルの1トランスミッションユニットにおける、トランスミッションユニットの異なったより高い平らなプロトコルの結合を許すために定義されます。 同じインターネットプロトコル(IP)ヘッダーがあるセグメントだけ、結合されるかもしれません(プロトコルとチェック合計分野の可能な例外で)。 例えば、セグメント(H1、B1)、セグメント(H2、B2)、HiとBiがどこのヘッダーであるか、そして、およびセグメントのボディーはH=H1=H2である場合にだけそれぞれ結合されるかもしれません(多重送信します)。 結合したTMuxメッセージは、(H、B1、B2)か(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.

まるで2つのオリジナルのセグメント、(H、B1)、および(H、B2)が別々に到着するかのようにこの結合したメッセージの受信機はそれを扱うはずです。 TMuxメッセージのセグメントが同次で処理されるべきであるという要件ではありませんが、それらがTMuxメッセージにあるのは、お勧めです。

   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.

マルチプレクシングは、(H、Bn)を通して個々のセグメント、(H、B1)をただ一つのメッセージに結合することによって、達成されます。 このただ一つのメッセージには、Hに堪えるIPヘッダーがありますが、プロトコル分野に値18を持っていて、どれがTMuxのプロトコル番号であるかは議定書を作ります。 このIPヘッダーはすべてのセグメント、Bnを通したB1によって続かれています。 各セグメント(Bi)は4の八重奏のTMuxのミニのヘッダーによって先行されています。 これはこのセグメントが記述されるプロトコルの数を含んでいます。 また、それはこのミニのヘッダーを含むこのセグメントの全長を含んでいます。 このミニのヘッダーが別の方法でチェック合計によって保護されないので、また、それはただこのミニのヘッダーを含むチェックサム分野を含んでいます。

Cameron, Crocker, Cohen & Postel                                [Page 3]

RFC 1692                          TMux                       August 1994

キャメロン、クロッカー、コーエン、およびポステル[3ページ]RFC1692TMux1994年8月

2.1. IP Protocol field value

2.1. IPプロトコル分野価値

   TMux is indicated in an IP datagram by the Protocol (ID) value of 18
   (22 octal), see [3].

TMuxはIPデータグラムで18(22 8進)のプロトコル(ID)値によって示されて、[3]を見てください。

2.2. Header Format

2.2. ヘッダー形式

   Each 4 octet TMux mini-header has the following general format:

それぞれの4八重奏TMuxミニヘッダーには、以下の一般形式があります:

                     +-------------------------------+
                     |         Length high           |
                     +-------------------------------+
                     |          Length low           |
                     +-------------------------------+
                     |         Protocol ID           |
                     +-------------------------------+
                     |          Checksum             |
                     +-------------------------------+
                     |      Transport segment        |
                     |       ...                     |
                     |       ...                     |

+-------------------------------+ | 長さの高値| +-------------------------------+ | 長さの安値| +-------------------------------+ | プロトコルID| +-------------------------------+ | チェックサム| +-------------------------------+ | 輸送セグメント| | ... | | ... |

   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.

LENGTH分野は0-65535 八重奏からこのミニのヘッダーと以下の輸送セグメントのための八重奏カウントを指定します。 したがって、長さの分野には、4の最小値があります。 最大がTMuxを考慮したより(セクション5.1を見てください)大きいセグメントにおいて、個々のIPデータグラムを送るべきです。

   The Protocol ID field contains the value that would normally have
   been placed in the IP header Protocol field.

プロトコルID分野は通常、IPヘッダープロトコル分野に置かれた値を含んでいます。

   The 'Checksum' field is the XOR of the first 3 octets.

'チェックサム'分野は最初の3つの八重奏のXORです。

   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.

TCP、UDP、および他のセグメントが彼らの32ビットの整列を保つのを保証すると、多重送信されるセグメントがどこの長さ32ビットの、そして、余分な八重奏の倍数でないかは、セグメントの終わりを再編成して、したがって、次のセグメントを再編成するために加えられるでしょう。 これらの八重奏は入力のときに無視されるでしょう。 この詰め物はLENGTH分野に影響しないでしょう、それでも、それがセグメントの本当の長さを含むでしょう。

2.3. Sending Data

2.3. 送付データ

   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.

ホスト終点は、いつでもであることにおいて(ともに)方向にTMuxを使用するのを選ぶかもしれません。 また、彼らはTMuxパッケージと普通の個々のIPデータグラムの個々の輸送協会の使用を前後に切り換えるかもしれません。 TMuxの使用への唯一のバリアがTMuxが受信機によって支持されるか否かに関係なく、知る送付者のためのものです。これは重要です、TMuxの早めの使用が制限されそうであるので。

Cameron, Crocker, Cohen & Postel                                [Page 4]

RFC 1692                          TMux                       August 1994

キャメロン、クロッカー、コーエン、およびポステル[4ページ]RFC1692TMux1994年8月

   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.

TMUXサポートを検出する最も簡単な方法は有効なTMuxメッセージが既に受け取られたホストへのメッセージをTMuxに送るだけであることです。 そして、これは1人のホストがTMux接続を始めるという問題を残します。 これはデータ(すなわち、20のIP全長分野がある)なしで、TMuxのための18のIPプロトコル分野価値でIPデータグラムを送るホストによって最も容易に達成されます。 これはTMux ENQ(調査)メッセージと呼ばれます。 その時このメッセージを受け取るホストは、創始者が、TMuxを支持して、メッセージをTMuxに送るのを出発できるのを知っています。 これは順番にTMuxを使用し始めるENQメッセージの創始者を引き起こすでしょう。 受信機がどんな理由のためにも創始者へのメッセージをTMuxに送らないつもりですが、それらを受け入れるように準備されるなら、それは別のENQメッセージで返答できます。

   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.

ENQメッセージが返事をもらわないなら、オリジナルのENQメッセージが失われるといけなかったので、後でしばらくENQを再送するのは妥当です。 これが再び無くなるなら、ENQは必要に応じて同じくらいしばしば繰り返されるかもしれませんが、要求の間の時間はおよそ1時間の限界まで指数関数的に増加するべきです。 ENQsの間の適当な回は秒、30秒と、60秒15であるだろう、120秒はなどです。

   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.

この照合の過程が輸送(ユーザ)データのどれかを妨害する必要はないことに注意してください、それほど効率的でないIPデータグラムフォームで。データは便利であるとして送られるかもしれません。

   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.

この計画に関する唯一の問題はTMuxがそれのサポートがそうするホストが、それを支持するのを止めるということです、ホストがリブートされるとき、起こるかもしれないとき。 他のホストは、この変化を知る必要があります。 この解決策はTMuxメッセージが受け取られたホストのためにTime To Live(TTL)値を維持することです。 このTTLはIP TTL分野で使用されるようにカウントよりむしろ調節されたTTLです、そして、TMuxメッセージが受信されているときはいつも、このタイムスタンプをアップデートします。 そして、適当な時(例えば、1分)の後にホストの上のTMuxによって保持された情報を吐き出すのにこれを使用できます。

   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

このTTLタイムスタンプは以下の通り使用されます。 ホストに送られるセグメントをTMuxに通過するとき、生きる時間が期限が切れたかどうかを見るのをチェックをします。 TTLが期限が切れていないなら、正常なTMux同じくらいメッセージでセグメントを送ります。 TTLが期限が切れたなら、ホストはTMuxにマークされますが、セグメントはTMuxメッセージ(すなわち、他のセグメントが多重送信されるのを許容する正常な遅れがある)として送られたSTILLです。 それ以上(まれな出来事)本当にTMuxにホストであることができないなら、このセグメントは、すなわち、輸送プロバイダーTCPによって外で調節されていて、再試行されるでしょう。 ホストがTMuxにできないとしてマークされたので、正常なIPデータグラムとして再試行を送るでしょう。 リモートホストがまだTMuxにできているなら、TMux交通(それがリブートされたとしても)、通常TCP窓のアップデートを返送するべきです、そして、ローカル・ホストは再びTMuxにできるとしてそれをマークするでしょう。 作動するこの方法は引き起こされたどんな性能問題も取り除きます。

Cameron, Crocker, Cohen & Postel                                [Page 5]

RFC 1692                          TMux                       August 1994

キャメロン、クロッカー、コーエン、およびポステル[5ページ]RFC1692TMux1994年8月

   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.

絶えずTMuxingを脱落して、送る有はメッセージを調べます。 送られるIPデータグラムがUDPから来ているなら、リモートホストは回答における何も送らないかもしれません。 それで、メッセージをTMuxに送るのをただ止めるよりUDPに関して、この計画はホストに少しもより良くなるというわけではないでしょうが、また、それも、より悪くはありません。

3.  Protocol Behavior

3. プロトコルの振舞い

3.1. Transport Flow Control

3.1. 輸送フロー制御

   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.

TMuxは拡大としてIPデータグラムプロトコルに作動します。 したがって、それらがTMuxの上のトランスポート層で作動するので、それはほとんどのフロー制御メカニズムに変化も与えません。

3.2. Connection Management

3.2. 接続管理

   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.

接続の概念は、あるトランスポート・プロトコルに関係しますが、IP、または、TMuxに関係するというわけではありません。 接続管理がTMuxを使用することでトランスポート・プロトコルによって必要とされるとき、したがって、それはIPのために起こるように同じファッションで起こります。 事実上、トランスポート・プロトコルはTMuxが使用されているのを意識していないことです。

3.3 Multiplexed Message Construction

3.3 多重送信されたメッセージ工事

   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.

輸送プロバイダー(例えば、TCPかUDP)がセグメントを送るとき、TMuxはセグメントの送付先アドレスによって指定されたホストのために、最初に、IPヘッダー(存在しているなら)を移して、TMuxミニヘッダーとセグメントを工事中のMultiplexed Messageに加えます。

   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.

伝えられるべき最初のメッセージが工事中のMultiplexed Messageに置かれるとき、タイマは始動されます。 タイマが期限が切れるとき、工事中のMultiplexed Messageは伝えられます。 これは、タイマが期限が切れる前に発信するのに利用可能なすべてのセグメントが独身のMultiplexed Messageで送られるのを確実にします。 メッセージを保持するバッファがMultiplexed Messageの構造の間、いっぱいになるなら、Multiplexed Messageはすぐに、伝えられます。

   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.

遅延時間はユーザ構成可能であるべきです。 妥当な時間は20〜30ミリセカンドです。 期間が複数のセグメントを送るという妥当な確率を与えることができるくらい大きいのですが、非常に大きいはずがないので、エコー応答時間は問題になります。 これは、タイマのための上限がたぶん1/第10 2番目であると示唆します。 多くのシステムの上でタイムアウトを使用する費用がかなり大きいように、単一のタイマを使用して、タイマが期限が切れるとき作成中のすべてのTMuxメッセージを送るのはお勧めです。

Cameron, Crocker, Cohen & Postel                                [Page 6]

RFC 1692                          TMux                       August 1994

キャメロン、クロッカー、コーエン、およびポステル[6ページ]RFC1692TMux1994年8月

   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.

さらに、それが伝えられる前に設定オプションは含まれているデータ・セグメントの数かMultiplexed Messageの最大サイズを制限するかもしれません。 また、より大きいセグメント(例えば、それらの700以上の八重奏)が標準のIPデータグラムとして送られて、多重送信されるべきでないと示唆されます。 これは、TMuxタイマによって引き起こされた遅れがそれが勧められないそれらのセグメントに遅れを置かないのを保証するためのものです。 (できれば、)多重送信されるべき最も大きいセグメントのサイズは構成可能であるべきです。

4. Protocol Example

4. プロトコルの例

   This example shows a TMux message consisting of three multiplexed
   segments:

この例は、3から成るのがセグメントを多重送信したのをTMuxメッセージに示します:

   A TCP segment consisting of a 20 octet TCP header, 5 octets of data
   and 3 octets of padding.  Thus the length field is

20八重奏TCPヘッダー、詰め物のデータと3つの八重奏の5つの八重奏から成るTCPセグメント。 したがって、長さの分野はそうです。

             Mini header + TCP header + data
           =     4       +     20     +  5
           =     29

ミニのヘッダー+TCPヘッダー+データ=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.

20八重奏TCPヘッダー、データの4つの八重奏から成るTCPセグメント。 このセグメントは、そっと歩くのを必要としません。

   A UDP segment consisting of a 4 octet UDP header, 41 octets of data
   and 3 octets of padding.

4八重奏UDPヘッダー、詰め物のデータと3つの八重奏の41の八重奏から成るUDPセグメント。

                     +-------------------------------+
                     |         Length = 29           |
                     |         (2 octets)            |
                     +-------------------------------+
                     |     Protocol ID = 6 (TCP)     |
                     +-------------------------------+
                     |          Checksum             |
                     +-------------------------------+
                     |         TCP Header            |
                     |        (20 octets)            |
                     +-------------------------------+
                     |          TCP data             |
                     |         (5 octets)            |
                     +-------------------------------+
                     |          Padding              |
                     |         (3 octets)            |
                     +-------------------------------+
                     |         Length = 28           |
                     |         (2 octets)            |

+-------------------------------+ | 長さ=29| | (2つの八重奏) | +-------------------------------+ | プロトコルID=6(TCP)| +-------------------------------+ | チェックサム| +-------------------------------+ | TCPヘッダー| | (20の八重奏) | +-------------------------------+ | TCPデータ| | (5つの八重奏) | +-------------------------------+ | 詰め物| | (3つの八重奏) | +-------------------------------+ | 長さ=28| | (2つの八重奏) |

Cameron, Crocker, Cohen & Postel                                [Page 7]

RFC 1692                          TMux                       August 1994

キャメロン、クロッカー、コーエン、およびポステル[7ページ]RFC1692TMux1994年8月

                     +-------------------------------+
                     |     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)            |
                     +-------------------------------+

+-------------------------------+ | プロトコルID=6(TCP)| +-------------------------------+ | チェックサム| +-------------------------------+ | TCPヘッダー| | (20の八重奏) | +-------------------------------+ | TCPデータ| | (4つの八重奏) | +-------------------------------+ | 長さ=49| | (2つの八重奏) | +-------------------------------+ | プロトコルID=17(UDP)| +-------------------------------+ | チェックサム| +-------------------------------+ | UDPヘッダー| | (4つの八重奏) | +-------------------------------+ | UDPデータ| | (41の八重奏) | +-------------------------------+ | 詰め物| | (3つの八重奏) | +-------------------------------+

5. Implementation Suggestion

5. 実現提案

5.1 Maximum TMux Message Size

5.1 最大のTMuxメッセージサイズ

   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.

セクション3.3では、TMuxメッセージサイズにおける限界に達しているなら、メモはすぐに、送付メッセージに関して作られます。 システムどこPath MTUディスカバリー、(1191[4])がRFCに従って実行されたとき、これは伝えることができる最大のメッセージサイズを発見するのに使用されるべきであり、最大のTMuxメッセージサイズとして使用されるべきであるか。

5.2 Deciding Which Segments to Multiplex

5.2 どのセグメントを多重送信したらよいかを決めること。

   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

どのセグメントがTMuxであるべきであるかを決めるのが、送付者の責任である、どれがそうするべきでないだろうか。 例えば、通常、FTPによって送られたセグメントは多重送信されるはずがありません。 多くの状況で、ソースと目的地TCPポートナンバーを調べることによってまさしく対話的な通信(telnetとRlogin)における関係者に多重送信できるセッションを制限するのは分別があるかもしれません。 しかしながら、通常、多重送信されないセグメントが送られるかどうかことであり、TMuxメッセージは既に作成中であり、その時は余分なセグメントです。

Cameron, Crocker, Cohen & Postel                                [Page 8]

RFC 1692                          TMux                       August 1994

キャメロン、クロッカー、コーエン、およびポステル[8ページ]RFC1692TMux1994年8月

   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.

作成中のTMuxメッセージに追加できて、タイマが期限が切れるのを待っているよりすぐに、むしろこの完全なメッセージを送るべきです。

6. Implementation notes

6. 実現注意

   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.

以下の注意はTMuxの早めの実現のテストの間に行われた経験の結果です。 彼らが実際の規格の一部を形成していない間、それらは、できれば、他の実現との互換性を確実にするために続かれるべきです。

   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.

TMuxミニヘッダーがTOS分野を含んでいないので、同じIP TOS分野がある唯一のセグメントがただ一つのTMuxメッセージに含まれるべきです。 ほとんどのシステムがTOSの特徴を使用しないとき、これは主要な制限ではありません。 TOS分野が使用されているところでは、ホストにとっての、作成中のいくつかのメッセージを保持するのは望ましいかもしれません、それぞれのTOS値あたり1つ。

   Segments containing IP options should not be multiplexed.

IPオプションを含むセグメントを多重送信するべきではありません。

   Only unicast addresses should be considered for multiplexing.

ユニキャストアドレスだけがマルチプレクシングのために考えられるべきです。

   Segments addressed to the loopback address (127.0.0.1) are not
   candidates for multiplexing.

セグメントがループバックアドレスに記述した、(127.0 .0 .1は)マルチプレクシングの候補ではありません。

   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.

対話的なセッション(すなわち、TelnetとRlogin)の間にあるソースか仕向港があるセグメントだけが、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.

誤りがTMuxヘッダーのチェックサムで発見されるなら、そこから始まって、メッセージの残りは無視されます。 未知のプロトコル分野がどんなTMuxヘッダーでも発見されるなら、このセグメント、およびこれだけが無視されます。

   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.

TMux実現が絶えずまさに1つのセグメントを含むメッセージをTMuxに送る、(ほとんど多重送信しない交通があるということである、)、そして、TMuxはオフにされるかもしれません。 これは、混雑が全くないとき、TMuxがスイッチを切られるかもしれないのを含意します。

   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.

中間的ノードがTMuxフレームを断片化して、再建するのを防ぐために、実現はTMuxメッセージのIPデータグラムに「断片化しないでください」という旗を設定したがっているかもしれません。

   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

また、ホストBがホストAからTMux ENQメッセージを受け取りますが、ホストAのために少しのデータも持っていないなら、それはENQメッセージを返送するかもしれません。 しかしながら、したがって、応じるBなどを引き起こして、ホストAはこれに対応して別のENQメッセージを送るかもしれません。 したがって、この施設が使用されているなら、このループの振舞いが起こるのを防ぐためにコードを含まなければなりません。 発信します。

Cameron, Crocker, Cohen & Postel                                [Page 9]

RFC 1692                          TMux                       August 1994

キャメロン、クロッカー、コーエン、およびポステル[9ページ]RFC1692TMux1994年8月

   an ENQ in response to an ENQ is not recommended, except in special
   circumstances.

特殊事情以外に、ENQに対応したENQは推薦されません。

   It is recommended that the following aspects of the TMux protocol be
   user configurable:

TMuxプロトコルの以下の局面がユーザ構成可能であることは、お勧めです:

      The maximum size of a segment that can be multiplexed by TMux.

TMuxが多重送信できるセグメントの最大サイズ。

      The delay between the first segment being placed into the message
      under construction and the message being sent.

作成中のメッセージに置かれる最初のセグメントと送られるメッセージの間の遅れ。

7. Security Considerations

7. セキュリティ問題

   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.

TMuxが事実上IPへの拡大であるので、それはIPをするよりそれ以上の影響力をサイトセキュリティに持っていません。 セキュリティは上側の層のプロトコルによって対処されるべきです。

   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.

いくつかのルータがTCPポートナンバーでパケットをフィルターにかけて、TCPポートナンバーHoweverを見えなくするので、TMuxが使用させられたどんなセグメントもこのフィルタリングを受けることがないでしょう、とフィルターにかけます同じTCP接続のための、より大きいセグメントがそれでも、IPデータグラムとして送るので受けることがある、その結果、潜在的な問題をもたらします。 この理由、そうしないどんなルータのためにも、サポートTMuxにもかかわらず、どれがフィルタリングのこのタイプを支持するかがTMuxメッセージの通ることを許すべきではありません(どちらかの方向に)。 これで、両方のホストは、もう片方がTMuxを支持しないのですべてのセグメントがIPデータグラムとして送られると考えるでしょう、その結果、この問題を解決します。

   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.

この問題の、より良い解決はルータのためのそうです。TMuxプロトコルを理解して、それぞれの多重送信されたセグメントを点検して、フィルタリングに失敗するそれらのセグメントを取り除くために。

8. References

8. 参照

   [1] Cohen, D., and Postel, J., "Multiplexing Protocol", IEN 90,
       USC/Information Sciences Institute,, May 1979.

[1] コーエン、D.とポステル、J.、「マルチプレクシングプロトコル」(IEN90、科学が設けるUSC/情報)は1979がそうするかもしれません。

   [2] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
       Sciences Institute, September 1981.

[2] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、科学が1981年9月に設けるUSC/情報。

   [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, March 1990.

レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1340、USC/情報科学が1990年3月に設ける[3]。

   [4] Mogul, J., and S. Deering, "Path MTU discovery", RFC 1191, DECWRL
       and Stanford University, November 1990.

[4] ムガール人、J.とS.デアリングと「経路MTU探索」とRFC1191とDECWRLとスタンフォード大学、1990年11月。

Cameron, Crocker, Cohen & Postel                               [Page 10]

RFC 1692                          TMux                       August 1994

キャメロン、クロッカー、コーエン、およびポステル[10ページ]RFC1692TMux1994年8月

9. Authors' Addresses

9. 作者のアドレス

       Peter Cameron
       Xylogics International, Ltd.
       Featherstone Rd.
       Wolverton Mill
       Milton Keynes
       MK12 5RD
       United Kingdom

ピーターキャメロンXylogics国際のLtd.フェザーストン通り ウォルバートンの5つのミルトンケインズMK12第工場イギリス

       Phone: +44  908 222112
       Fax:   +44  908 222115
       EMail: cameron@xylint.co.uk

以下に電話をしてください。 +44 908 222112Fax: +44 908 222115 メール: cameron@xylint.co.uk

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

デヴィッド・医者シリコングラフィックス2011N.海岸線Blvd. P.O. Box7311カリフォルニア94039-7311マウンテンビュー(米国)

       Phone: +1 415 390 1804
       Fax:   +1 415 962 8404
       EMail: dcrocker@sgi.com

以下に電話をしてください。 +1 415 390、1804Fax: +1 8404年の415 962メール: dcrocker@sgi.com

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

ダニーコーエンMyricom325N.サンタアニタAve。 理想郷、カリフォルニア91006米国

       Phone: +1 818 821 5555
       EMail: Cohen@myricom.com

以下に電話をしてください。 +1 5555年の818 821メール: Cohen@myricom.com

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

ジョンポステルUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695米国

       Phone: +1 310 822 1511
       Fax:   +1 310 823 6714
       EMail: Postel@ISI.EDU

以下に電話をしてください。 +1 310 822、1511Fax: +1 6714年の310 823メール: Postel@ISI.EDU

Cameron, Crocker, Cohen & Postel                               [Page 11]

RFC 1692                          TMux                       August 1994

キャメロン、クロッカー、コーエン、およびポステル[11ページ]RFC1692TMux1994年8月

10. Discussion List

10. ディスカッション・リスト

       There is a discussion list for this protocol, which for
       historical reasons is called:

このプロトコルのための議論リストがあります:(歴史的な理由で、リストは呼ばれます)。

           cmp-id@xylint.co.uk

cmp-id@xylint.co.uk

   Requests to join the list should be sent to:

以下のことのために、リストを接合するという要求を送るべきです。

           cmp-id-request@xylint.co.uk

cmp-id-request@xylint.co.uk

Cameron, Crocker, Cohen & Postel                               [Page 12]

キャメロン、クロッカー、コーエン、およびポステル[12ページ]