RFC1063 日本語訳
1063 IP MTU discovery options. J.C. Mogul, C.A. Kent, C. Partridge, K.McCloghrie. July 1988. (Format: TXT=27121 bytes) (Obsoleted by RFC1191) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Mogul
Request For Comments: 1063 C. Kent
DEC
C. Partridge
BBN
K. McCloghrie
TWG
July 1988
コメントを求めるワーキンググループJ.要人要求をネットワークでつないでください: 1063 C.ケント1988年12月のC.ヤマウズラBBN K.McCloghrie TWG7月
IP MTU Discovery Options
IP MTU発見オプション
STATUS OF THIS MEMO
このメモの状態
A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses. This is a proposal for an Experimental protocol. Distribution of this memo is unlimited.
インターネットを通して経路の最小のMTUを学ぶのに使用できる1組のIPオプションは説明されます、可能な用途と共に。 これはExperimentalプロトコルのための提案です。 このメモの分配は無制限です。
INTRODUCTION
序論
Although the Internet Protocol allows gateways to fragment packets that are too large to forward, fragmentation is not always desirable. It can lead to poor performance or even total communication failure in circumstances that are surprisingly common. (For a thorough discussion of this issue, see [1]).
ゲートウェイはインターネットプロトコルで進めることができないくらい大きいパケットを断片化できますが、断片化はいつも望ましいというわけではありません。 それは驚くほど一般的な事情での不十分な性能かトータル・コミュニケーション失敗にさえ通じることができます。 (この問題の徹底的な議論に関しては、[1])を見てください。
A datagram will be fragmented if it is larger than the Maximum Transmission Unit (MTU) of some network along the path it follows. In order to avoid fragmentation, a host sending an IP datagram must ensure that the datagram is no larger than the Minimum MTU (MINMTU) over the entire path.
それがそれが続く経路に沿った何らかのネットワークのMaximum Transmission Unit(MTU)より大きいなら、データグラムは断片化されるでしょう。 断片化を避けるために、IPデータグラムを送るホストはデータグラムが確実に全体の経路にわたって、Minimum MTU(MINMTU)より大きくならないようにしなければなりません。
It has long been recognized that the methods for discovering the MINMTU of an IP internetwork path are inadequate. The methods currently available fall into two categories: (1) choosing small MTUs to avoid fragmentation or (2) using additional probe packets to discover when fragmentation will occur. Both methods have problems.
長い間、IPインターネットワーク経路のMINMTUを発見するための方法が不十分であると認められています。 現在の2つのカテゴリへの空いている落下の間の方法: (1) 断片化がいつ起こるかを発見するのに追加徹底的調査パケットを使用することで断片化か(2)を避けるために小さいMTUsを選びます。 両方の方法には、問題があります。
Choosing MTUs requires a balance between network utilization (which requires the use of the largest possible datagram) and fragmentation avoidance (which in the absence of knowledge about the network path encourages the use of small, and thus too many, datagrams). Any choice for the MTU size, without information from the network, is likely to either fail to properly utilize the network or fail to avoid fragmentation.
MTUsを選ぶのはネットワーク利用(可能な限り大きいデータグラムの使用を必要とする)と断片化回避(ネットワーク経路に関する知識がないとき小さくて、その結果、多く過ぎるデータグラムの使用を奨励する)の間のバランスを必要とします。 MTUサイズのためのどんな選択も、適切にネットワークを利用しそうにはありませんし、ネットワークからの情報なしで断片化を避けなさそうにはありません。
Probe packets have the problem of burdening the network with
パケットにはネットワークを負うという問題がある徹底的調査
Mogul, Kent, Partridge, & McCloghrie [Page 1] RFC 1063 IP MTU Discovery Options July 1988
ムガール人、ケント、ヤマウズラ、およびMcCloghrie[1ページ]RFC1063IP MTU発見オプション1988年7月
unnecessary packets. And because network paths often change during the lifetime of a TCP connection, probe packets will have to be sent on a regular basis to detect any changes in the effective MINMTU.
不要なパケット。 そして、ネットワーク経路がTCP接続の生涯しばしば変化するので、有効なMINMTUにおけるどんな変化も検出するために定期的に徹底的調査パケットを送らなければならないでしょう。
Implementors sometimes mistake the TCP MSS option as a mechanism for learning the network MINMTU. In fact, the MSS option is only a mechanism for learning about buffering capabilities at the two TCP peers. Separate provisions must be made to learn the IP MINMTU.
作成者はネットワークMINMTUを学ぶためのメカニズムとして時々TCP MSSオプションを間違います。 事実上、MSSオプションは、2人のTCP同輩で能力をバッファリングすることに関して学ぶためのメカニズムにすぎません。 別々の条項にIP MINMTUを学ばせなければなりません。
In this memo, we propose two new IP options that, when used in conjunction will permit two peers to determine the MINMTU of the paths between them. In this scheme, one option is used to determine the lowest MTU in a path; the second option is used to convey this MTU back to the sender (possibly in the IP datagram containing the transport acknowledgement to the datagram which contained the MTU discovery option).
このメモでは、私たちは新しいIPがそれをゆだねる2を提案します、接続詞が2を可能にする中古のコネがそれらの間の経路のMINMTUを決定するためにじっと見るとき。 この計画では、1つのオプションが経路で最も低いMTUを決定するのに使用されます。 2番目のオプションは、送付者(ことによるとMTU発見オプションを含んだデータグラムに輸送承認を含むIPデータグラムの)までこのMTUを運んで戻すのに使用されます。
OPTION FORMATS
オプション形式
Probe MTU Option (Number 11)
MTUオプションを調べてください。(No.11)
Format
形式
+--------+--------+--------+--------+
|00001011|00000100| 2 octet value |
+--------+--------+--------+--------+
+--------+--------+--------+--------+ |00001011|00000100| 2 八重奏値| +--------+--------+--------+--------+
Definition
定義
This option always contains the lowest MTU of all the networks
that have been traversed so far by the datagram.
このオプションはいつも今までのところデータグラムによって横断されたすべてのネットワークの最も低いMTUを含んでいます。
A host that sends this option must initialize the value field to
be the MTU of the directly-connected network. If the host is
multi-homed, this should be for the first-hop network.
このオプションを送るホストは、直接接続されたネットワークのMTUになるように値の分野を初期化しなければなりません。 ホストがそうである、マルチ、家へ帰り、これは最初に、ホップネットワークのためのものであるべきです。
Each gateway that receives a datagram containing this option must
compare the MTU field with the MTUs of the inbound and outbound
links for the datagram. If either MTU is lower than the value in
the MTU field of the option, the option value should be set to the
lower MTU. (Note that gateways conforming to RFC-1009 may not
know either the inbound interface or the outbound interface at the
time that IP options are processed. Accordingly, support for this
option may require major gateway software changes).
このオプションを含むデータグラムを受ける各ゲートウェイは本国行きのMTUsがあるMTU分野とデータグラムのためのアウトバウンドリンクを比較しなければなりません。 オプションのMTU分野でMTUが値より低いなら、オプション価値は下側のMTUに設定されるべきです。 (ゲートウェイがRFC-1009に一致している場合IPオプションが処理される時に本国行きのインタフェースか外国行きのインタフェースのどちらかを知らないかもしれない注意。 それに従って、このオプションのサポートは主要なゲートウェイソフトウェア変化を必要とするかもしれません。).
Any host receiving a datagram containing this option should
confirm that value of the MTU field of the option is less than or
equal to that of the inbound link, and if necessary, reduce the
このオプションを含むどんなホスト受信aデータグラムも、オプションのMTU分野の値がインバウンドリンクの、よりもの以下であると確認するはずです、そして、必要なら、減少してください。
Mogul, Kent, Partridge, & McCloghrie [Page 2] RFC 1063 IP MTU Discovery Options July 1988
ムガール人、ケント、ヤマウズラ、およびMcCloghrie[2ページ]RFC1063IP MTU発見オプション1988年7月
MTU field value, before processing the option.
オプションを処理する前に、MTUは値をさばきます。
If the receiving host is not able to accept datagrams as large as
specified by the value of the MTU field of the option, then it
should reduce the MTU field to the size of the largest datagram it
can accept.
受信ホストが、オプションのMTU分野の値によって指定されるようにデータグラムが大きいと受け入れることができないなら、それは受け入れることができる中で最も大きいデータグラムのサイズにMTU分野を減少させるべきです。
Reply MTU Option (Number 12)
回答MTUオプション(No.12)
Format
形式
+--------+--------+--------+--------+
|00001100|00000100| 2 octet value |
+--------+--------+--------+--------+
+--------+--------+--------+--------+ |00001100|00000100| 2 八重奏値| +--------+--------+--------+--------+
Definition
定義
This option is used to return the value learned from a Probe MTU
option to the sender of the Probe MTU option.
このオプションは、Probe MTUオプションからProbe MTUオプションの送付者まで学習された値を返すのに使用されます。
RELATION TO TCP MSS
TCP MSSとの関係
Note that there are two superficially similar problems in choosing the size of a datagram. First, there is the restriction [2] that a host not send a datagram larger than 576 octets unless it has assurance that the destination is prepared to accept a larger datagram. Second, the sending host should not send a datagram larger than MINMTU, in order to avoid fragmentation. The datagram size should normally be the minimum of these two lower bounds.
データグラムのサイズを選ぶのにおいて2つの表面的に同様の問題があることに注意してください。 まず最初に、[2] それに目的地が、より大きいデータグラムを受け入れるように準備されるという保証がない場合ホストが576の八重奏より大きいデータグラムを送らないという制限があります。 2番目に、送付ホストは、断片化を避けるためにMINMTUより大きいデータグラムを送るべきではありません。 通常、データグラムサイズはこれらの2つの下界の最小限であるはずです。
In the past, the TCP MSS option [3] has been used to avoid sending packets larger than the destination can accept. Unfortunately, this is not the most general mechanism; it is not available to other transport layers, and it cannot determine the MINMTU (because gateways do not parse TCP options).
過去に、TCP MSSオプション[3]は、目的地が受け入れることができるより大きいパケットを送るのを避けるのに使用されました。 残念ながら、これは最も一般的なメカニズムではありません。 それは他のトランスポート層に利用可能ではありません、そして、MINMTUを決定できません(ゲートウェイがTCPオプションを分析しないので)。
Because the MINMTU returned by a probe cannot be larger than the maximum datagram size that the destination can accept, this IP option could, in theory, supplant the use of the TCP MSS option, providing an economy of mechanism. (Note however, that some researchers believe that the value of the TCP MSS is distinct from the path's MINMTU. The MSS is the upper limit of the data size that the peer will accept, while the MINMTU represents a statement about the data size supported by the path).
徹底的調査で返されたMINMTUが目的地が受け入れることができる最大のデータグラムサイズより大きいはずがないので、このIPオプションは理論上TCP MSSオプションの使用に取って代わるかもしれません、メカニズムの経済を提供して。 (しかしながら、何人かの研究者が、それがTCP MSSの値であると信じているのが、経路のMINMTUと異なっていることに注意してください。 MSSは同輩が受け入れるデータサイズの上限です、MINMTUが経路によって支持されたデータサイズに関する声明を表しますが).
Note that a failure to observe the MINMTU restriction is not normally fatal; fragmentation will occur, but this is supposed to work. A failure to observe the TCP MSS option, however, could be fatal
通常、MINMTU制限を観測しないことが致命的でないことに注意してください。 断片化は起こるでしょうが、これは働くべきです。 しかしながら、TCP MSSオプションを観測しないことは致命的であるかもしれません。
Mogul, Kent, Partridge, & McCloghrie [Page 3] RFC 1063 IP MTU Discovery Options July 1988
ムガール人、ケント、ヤマウズラ、およびMcCloghrie[3ページ]RFC1063IP MTU発見オプション1988年7月
because it might lead to datagrams that can never be accepted by the destination. Therefore, unless and until the Probe MTU option is universally implemented, at least by hosts, the TCP MSS option must be used as well.
データグラムに通じるかもしれないので、目的地はそれを決して受け入れることができません。 したがって、また、Probe MTUオプションが少なくともホストによって一般に実行されるまで、TCP MSSオプションを使用しなければなりません。
IMPLEMENTATION APPROACHES
実現アプローチ
Who Sends the Option
だれがオプションを送りますか。
There are at least two ways to implement the MTU discovery scheme.
One method makes the transport layer responsible for MTU
discovery; the other method makes the IP layer responsible for MTU
discovery. A host system should support one of the two schemes.
MTU発見計画を実行する少なくとも2つの方法があります。 1つの方法で、トランスポート層はMTU発見に責任があるようになります。 もう片方の方法で、IP層はMTU発見に責任があるようになります。 ホストシステムは2つの計画の1つを支持するはずです。
Transport Discovery
輸送発見
In the transport case, the transport layer can include the Probe
MTU option in an outbound datagram. When a datagram containing
the Probe MTU option is received, the option must be passed up to
the receiving transport layer, which should then acknowledge the
Probe with a Reply MTU option in the next return datagram. Note
that because the options are placed on unreliable datagrams, the
original sender will have to resend Probes (possibly once per
window of data) until it receives a Reply option. Also note that
the Reply MTU option may be returned on an IP datagram for a
different transport protocol from which it was sent (e.g., TCP
generated the probe but the Reply was received on a UDP datagram).
輸送場合では、トランスポート層は外国行きのデータグラムにProbe MTUオプションを含むことができます。 Probe MTUオプションを含むデータグラムが受け取られているとき、オプションに受信トランスポート層まで合格しなければなりません。(次に、Reply MTUオプションが次のリターンデータグラムにある状態で、それは、Probeを承認するはずです)。 オプションが頼り無いデータグラムに関して課されるので、それがReplyオプションを受け取るまで元の送り主が(ことによると一度データの窓あたり)Probesを再送しなければならないことに注意してください。 また、Reply MTUオプションがそれが送られた異なったトランスポート・プロトコルのためにIPデータグラムの上に返されるかもしれないことに注意してください(例えば、TCPは探測装置を発生させましたが、UDPデータグラムの上にReplyを受け取りました)。
IP Discovery
IP発見
A better scheme is to put MTU discovery into the IP layer, using
control mechanisms in the routing cache. Whenever an IP datagram
is sent, the IP layer checks in the routing cache to see if a
Probe or Reply MTU option needs to be inserted in the datagram.
Whenever a datagram containing either option is received, the
information in those options is placed in the routing cache.
より良い計画はルーティングキャッシュに制御機構を使用して、IP層にMTU発見を入れることです。 IPデータグラムを送るときはいつも、IP層は、ProbeかReply MTUオプションが、データグラムに挿入される必要であるかどうか確認するためにルーティングキャッシュを預けます。 オプションを含むデータグラムが受け取られているときはいつも、それらのオプションにおける情報はルーティングキャッシュに置かれます。
The basic working of the protocol is somewhat complex. We trace
it here through one round-trip. Implementors should realize that
there may be cases where both options are contained in one
datagram. For the purposes of this exposition, the sender of the
probe is called the Probe-Sender and the receiver, Probe-Receiver.
プロトコルの基本的な運用はいくらか複雑です。 私たちは1つの周遊旅行でそれをここにたどります。 作成者は、ケースが両方のオプションが1個のデータグラムに含まれているところにあるかもしれないとわかるべきです。 この博覧会の目的のために、Probe-送付者と受信機、Probe-受信機は徹底的調査の送付者のために呼ばれます。
When the IP layer is asked to send a Probe MTU option (see the
section below on when to probe), it makes some record in the
routing cache that indicates the next IP datagram to Probe-
Receiver should contain the Probe MTU option.
IP層がProbe MTUオプションを送るように頼まれるとき(下のいつ調べるかに関するセクションを見てください)、それはProbe受信機への次のIPデータグラムがProbe MTUオプションを含むはずであるのを示すルーティングキャッシュにおける何らかの記録を作ります。
Mogul, Kent, Partridge, & McCloghrie [Page 4] RFC 1063 IP MTU Discovery Options July 1988
ムガール人、ケント、ヤマウズラ、およびMcCloghrie[4ページ]RFC1063IP MTU発見オプション1988年7月
When the next IP datagram to Probe-Receiver is sent, the Probe MTU
option is inserted. The IP layer in Probe-Sender should continue
to send an occasional Probe MTU in subsequent datagrams until a
Reply MTU option is received. It is strongly recommended that the
Probe MTU not be sent in all datagrams but only at such a rate
that, on average, one Probe MTU will be sent per round-trip
interval. (Another way of saying this is that we would hope that
only one datagram in a transport protocol window worth of data has
the Probe MTU option set). This mechanism might be implemented by
sending every Nth packet, or, in those implementations where the
round-trip time estimate to the destination is cached with the
route, once every estimated RTT.
Probe-受信機への次のIPデータグラムを送るとき、Probe MTUオプションを挿入します。 Probe-送付者のIP層は、Reply MTUオプションが受け取られているまでその後のデータグラムで時々のProbe MTUを送り続けているはずです。 Probe MTUがすべてのデータグラム、しかし、単に平均で往復の間隔単位で1Probe MTUを送るくらいの速度で送られないことが強く勧められます。 (これを言う別の方法は私たちが、輸送における1個のデータグラムだけがProbe MTUオプションがデータの価値で設定する窓について議定書の中で述べることを望んでいるだろうということです。) このメカニズムはまたは、それらの実現で目的地への往復の時間見積りがルートでキャッシュされるところにあらゆるNthパケットを送ることによって、実行されるかもしれません、かつてのあらゆるおよそRTT。
When a Probe MTU option is received by Probe-Receiver, the
receiving IP should place the value of this option in the next
datagram it sends back to Probe-Sender. The value is then
discarded. In other words, each Probe MTU option causes the Reply
MTU option to be placed in one return datagram.
Probe-受信機でProbe MTUオプションを受け取るとき、受信IPはそれがProbe-送付者に返送する次のデータグラムのこのオプションの値を置くべきです。 そして、値は捨てられます。 言い換えれば、それぞれのProbe MTUオプションで、1個のリターンデータグラムにReply MTUオプションを置きます。
When Probe-Sender receives the Reply MTU option, it should check
the value of the option against the current MINMTU estimate in the
routing cache. If the option value is lower, it becomes the new
MINMTU estimate. If the option value is higher, Probe-Sender
should be more conservative about changing the MINMTU estimate.
If a route is flapping, the MINMTU may change frequently. In such
situations, keeping the smallest MINMTU of various routes in use
is preferred. As a result, a higher MINMTU estimate should only
be accepted after a lower estimate has been permitted to "age" a
bit. In other words, if the probe value is higher than the
estimated MINMTU, only update the estimate if the estimate is
several seconds old or more. Finally, whenever the Probe-Sender
receives a Reply MTU option, it should stop retransmitting probes
to Probe-Receiver.
Probe-送付者がReply MTUオプションを受け取るとき、それはルーティングキャッシュにおける現在のMINMTU見積りに対してオプションの値をチェックするべきです。 オプション価値が低いなら、それは新しいMINMTU見積りになります。 オプション価値が、より高いなら、Probe-送付者はMINMTU見積りを変えることに関して、より保守的であるべきです。 ルートがばたついているなら、MINMTUは頻繁に変化するかもしれません。 そのような状況で、使用中の様々なルートの最も小さいMINMTUを保つのは好まれます。 その結果、少し「年をとること」を低い見積りを許可した後により高いMINMTU見積りを受け入れるだけであるべきです。 言い換えれば、徹底的調査値がおよそMINMTUより高いなら、単に見積りか見積りが老数秒であるなら以上をアップデートしてください。 最終的に、Probe-送付者がReply MTUオプションを受け取るときはいつも、それは、Probe-受信機に探測装置を再送するのを止めるべきです。
A few additional issues complicate this discussion.
いくつかの追加設定がこの議論を複雑にします。
One problem is setting the default MINMTU when no Reply MTU
options have been received. We recommend the use of the minimum
of the supported IP datagram size (576 octets) and the connected
network MTU for destinations not on the local connected network,
and the connected network MTU for hosts on the connected network.
Reply MTUオプションを全く受け取っていないとき1つの問題はデフォルトMINMTUを設定することです。 私たちはホストのために接続ネットワークでローカルの接続ネットワーク、およびどんな接続ネットワークMTUでも支持されたIPデータグラムサイズ(576の八重奏)と接続ネットワークMTUの最小限の目的地の使用を推薦しません。
The MINMTU information, while kept by the Internet layer, is in
fact, only of interest to the transport and higher layers.
Accordingly, the Internet layer must keep the transport layer
informed of the current value of the estimated MINMTU.
Furthermore, minimal transport protocols, such as UDP, must be
prepared to pass this information up to the transport protocol
インターネット層によって保たれる間、事実上、MINMTU情報はそうです、輸送と単により高い層に興味があります。 それに従って、インターネット層は、およそMINMTUの現行価値についてトランスポート層を知らせ続けなければなりません。 その上、この情報をトランスポート・プロトコルまで通過するようにUDPなどの最小量のトランスポート・プロトコルを準備しなければなりません。
Mogul, Kent, Partridge, & McCloghrie [Page 5] RFC 1063 IP MTU Discovery Options July 1988
ムガール人、ケント、ヤマウズラ、およびMcCloghrie[5ページ]RFC1063IP MTU発見オプション1988年7月
user.
ユーザ。
It is expected that there will be a transition period during which
some hosts support this option and some do not. As a result,
hosts should stop sending Probe MTU options and refuse to send any
further options if it does not receive either a Probe MTU option
or Reply MTU option from the remote system after a certain number
of Probe MTU options have been sent. In short, if Probe-Sender
has sent several probes but has gotten no indication that Probe-
Receiver supports MTU probing, then Probe-Sender should assume
that Probe-Receiver does not support probes. (Obviously, if
Probe-Sender later receives a probe option from Probe-Receiver, it
should revise its opinion.)
何人かのホストがこのオプションをサポートして、何かがサポートしない過渡期があると予想されます。 その結果、ある数のProbe MTUオプションを送った後にリモートシステムからProbe MTUオプションかReply MTUオプションのどちらかを受け取らないなら、ホストは、オプションをProbe MTUに送るのを止めて、どんなさらなるオプションも送るのを拒否するべきです。 要するに、Probe-送付者が数個の探測装置を送りましたが、Probe受信機がMTUを支持するという指示を全く調べさせなかったなら、Probe-送付者は、Probe-受信機が探測装置を支えないと仮定するべきです。 (明らかに、Probe-送付者が後でProbe-受信機から徹底的調査オプションを受け取るなら、それは意見を変えるべきです。)
Implementations should not assume that routes to the same
destination that have a different TOS have the same estimated
MINMTU. We recommend that the MTU be probed separately for each
TOS.
実現は、同じ目的地への異なったTOSを持っているルートでMINMTUであると同じくらいを見積もっていると仮定するべきではありません。 私たちは、MTUが各TOSのために別々に調べられることを勧めます。
Respecting the TCP MSS
TCP MSSを尊敬します。
One issue concerning TCP MSS is that it is usually negotiated
assuming an IP header that contains no options. If the transport
layer is sending maximum size segments, it may not leave space for
IP to fit the options into the datagram. Thus, insertion of the
Probe MTU or Reply MTU option may violate the MSS restriction.
Because, unlike other IP options, the MTU options can be inserted
without the knowledge of the transport layer, the implementor must
carefully consider the implications of adding options to an IP
datagram.
TCP MSSに関する1冊は通常、それがオプションを全く含まないIPヘッダーを仮定しながら交渉されるということです。 トランスポート層が最大サイズセグメントを送るなら、IPがデータグラムにオプションに合うように、それは間隔を取らないかもしれません。 したがって、Probe MTUかReply MTUオプションの挿入はMSS制限に違反するかもしれません。 他のIPオプションと異なってトランスポート層に関する知識なしでMTUオプションを挿入できるので、作成者は慎重に付加オプションの含意をIPデータグラムと考えなければなりません。
One approach is to reserve 4 bytes from the MINMTU reported to the
transport layer; this will allow the IP layer to insert at least
one MTU option in every datagram (it can compare the size of the
outgoing datagram with the MINMTU stored in the route cache to see
how much room there actually is). This is simple to implement,
but does waste a little bandwidth in the normal case.
1つのアプローチはトランスポート層に報告されたMINMTUから4バイトを予約することです。 これで、IP層は少なくとも1つのMTUオプションをあらゆるデータグラムに挿入できるでしょう(それはどのくらいの余地が実際にあるかを確認するために経路キャッシュに格納されるMINMTUと発信データグラムのサイズを比較できます)。 これは実行しますが、正常な場合における少しの帯域幅を浪費するのは簡単です。
Another approach is to provide a means for the IP layer to notify
the transport layer that space must be reserved for sending an
option; the transport layer would then make a forthcoming segment
somewhat smaller than usual.
別のアプローチはIP層がオプションを送るためにスペースを予約しなければならないようにトランスポート層に通知する手段を提供することです。 そして、トランスポート層で、今度のセグメントはいくらかいつもより小さくなるでしょう。
When a Probe Can Be Sent
探測装置を送ることができるとき
A system that receives a Probe MTU option should always respond
with a Reply MTU option, unless the probe was sent to an IP or LAN
broadcast address.
Probe MTUオプションを受け取るシステムはいつもReply MTUオプションで反応するはずです、探測装置がIPかLAN放送演説に送られなかったなら。
Mogul, Kent, Partridge, & McCloghrie [Page 6] RFC 1063 IP MTU Discovery Options July 1988
ムガール人、ケント、ヤマウズラ、およびMcCloghrie[6ページ]RFC1063IP MTU発見オプション1988年7月
A Probe MTU option should be sent in any of the following
situations:
以下の状況のどれかでProbe MTUオプションを送るべきです:
(1) The MINMTU for the path is not yet known;
(1) 経路へのMINMTUはまだ知られていません。
(2) A received datagram suffers a fragmentation re-assembly
timeout. (This is a strong hint the path has changed;
send a probe to the datagram's source);
(2) 容認されたデータグラムは断片化再アセンブリタイムアウトを受けます。 (これは経路が変えた強いヒントです; データグラムのソースに探測装置を送ってください)。
(3) An ICMP Time Exceeded/Fragmentation Reassembly Timeout is
received (this is the only message we will get that
indicates fragmentation occurred along the network path);
(3) ICMP Time Exceeded/断片化Reassembly Timeoutは受け取られています(これは断片化がネットワーク経路に沿って起こったのを示す私たちが得るつもりである唯一のメッセージです)。
(4) The transport layer requests it.
(4) トランスポート層はそれを要求します。
Implementations may also wish to periodically probe a path, even
if there is no indication that fragmentation is occurring. This
practice is perfectly reasonable; if fragmentation and reassembly
is working perfectly, the sender may never get any indication that
the path MINMTU has changed unless a probe is sent. We recommend,
however, that implementations send such periodic probes sparingly.
Once every few minutes, or once every few hundred datagrams is
probably sufficient.
また、断片化が起こっているという指示が全くなくても、実現は定期的に経路を調べたがっているかもしれません。 この習慣は完全に妥当です。 断片化と再アセンブリが完全に働いているなら、送付者は探測装置が送られない場合経路MINMTUが変化したというどんな指示も決して、得ないかもしれません。 しかしながら、私たちは、実現が控えめにそのような周期的な探測装置を送ることを勧めます。 あらゆる数分、または一度かつて、数100個のデータグラム毎がたぶん十分です。
There are also some scenarios in which the Probe MTU should not be
sent, even though there may be some indication of an MINMTU
change:
また、Probe MTUが送られるべきでないいくつかのシナリオがあります、MINMTU変化のいくつかのしるしがあるかもしれませんが:
(1) Probes should not be sent in response to the receipt of
a probe option. Although the fact that the remote peer
is probing indicates that the MINMTU may have changed,
sending a probe in response to a probe causes a continuous
exchange of probe options.
(1) 徹底的調査オプションの領収書に対応して探測装置を送るべきではありません。 リモート同輩が調べているという事実は、MINMTUが変化したかもしれないのを示しますが、徹底的調査に対応して探測装置を送るのは徹底的調査オプションの連続した交換を引き起こします。
(2) Probes must not be sent in response to fragmented
datagrams except when the fragmentation reassembly
of the datagram fails. The problem in this case is
that the receiver has no mechanism for informing the remote
peer that fragmentation has occurred, unless fragmentation
reassembly fails (in which case an ICMP message is sent).
Thus, a peer may use the wrong MTU for some time before
discovering a problem. If we probe on fragmented
datagrams, we may probe, unnecessarily, for some time
until the remote peer corrects its MTU.
(2) データグラムの断片化再アセンブリが失敗する時以外の断片化しているデータグラムに対応して探測装置を送ってはいけません。 この場合、問題は受信機には断片化が起こったことをリモート同輩に知らせるためのメカニズムが全くないということです、断片化が再アセンブリに失敗しない場合(その場合、ICMPメッセージを送ります)。 したがって、問題を発見する前に、同輩はしばらく間違ったMTUを使用するかもしれません。 断片化しているデータグラムの上に調べるなら、リモート同輩がMTUを修正するまで、私たちはしばらく不必要に調べるかもしれません。
(3) For compatibility with hosts that do not implement the
option, no Probe MTU Option should be sent more than
ten times without receiving a Reply MTU Option or a
(3) オプションを実行しないホストとの互換性において、Reply MTU Optionかaを受けないで、10回以上をどんなProbe MTU Optionにも送るべきではありません。
Mogul, Kent, Partridge, & McCloghrie [Page 7] RFC 1063 IP MTU Discovery Options July 1988
ムガール人、ケント、ヤマウズラ、およびMcCloghrie[7ページ]RFC1063IP MTU発見オプション1988年7月
Probe MTU Option from the remote peer. Peers which
ignore probes and do not send probes must be treated
as not supporting probes.
リモート同輩からMTU Optionを調べてください。 徹底的調査を無視して、探測装置を送らない同輩を探測装置を支えないとして扱わなければなりません。
(4) Probes should not be sent to an IP or LAN broadcast
address.
(4) IPかLAN放送演説に探測装置を送るべきではありません。
(5) We recommend that Probe MTUs not be sent to other hosts
on the directly-connected network, but that this feature
be configurable. There are situations (for example, when
Proxy ARP is in use) where it may be difficult to determine
which systems are on the directly-connected network. In
this case, probing may make sense.
(5) 私たちは、Probe MTUsが直接接続されたネットワークで他のホストに送られませんが、この特徴が構成可能であることを推薦します。 状況(Proxy ARPが例えば使用中であるときに)がどのシステムが直接接続されたネットワークにあるかを決定するのが難しいかもしれないところにあります。 この場合、調べは理解できるかもしれません。
SAMPLE IMPLEMENTATION SKETCH
サンプル実現スケッチ
We present here a somewhat more concrete description of how an IP- layer implementation of MTU probing might be designed.
私たちはここにMTUの調べのIP層の実現がどう設計されるかもしれないかに関するいくらか具体的な記述を提示します。
First, the routing cache entries are enhanced to store seven additional values:
まず最初に、ルーティングキャッシュエントリーは7つの加算値を格納するために機能アップされます:
MINMTU: The current MINMTU of the path.
MINMTU: 経路の現在のMINMTU。
ProbeRetry: A timestamp indicating when the next probe
should be sent.
ProbeRetry: 次の探測装置がいつ送られるべきであるかを示すタイムスタンプ。
LastDecreased: A timestamp showing when the MTU was
last decreased.
LastDecreased: MTUがいつ最後であったかを示すタイムスタンプは減少しました。
ProbeReply: A bit indicating a Reply MTU option should be
sent.
ProbeReply: Reply MTUオプションを少し示すのを送るべきです。
ReplyMTU: The value to go in the Reply MTU option.
ReplyMTU: Reply MTUオプションで行く値。
SupportsProbes: A bit indicating that the remote peer
can deal with probes (always defaults to
1=true).
SupportsProbes: 少し、それをリモート同輩が対処できる示すのは調べられます(= 本当にいつも1をデフォルトとします)。
ConsecutiveProbes: The number of probes sent without
the receipt of a Probe MTU or Reply
MTU option.
ConsecutiveProbes: 徹底的調査の数はProbe MTUかReply MTUオプションの領収書なしで発信しました。
There are also several configuration parameters; these should be configurable by appropriate network management software; the values we suggest are "reasonable":
また、いくつかの設定パラメータがあります。 これらは適切なネットワークマネージメントソフトウェアで構成可能であるべきです。 私たちが勧める値は「妥当です」:
Default_MINMTU: The default value for the MINMTU field of the
_デフォルトMINMTU: MINMTU分野へのデフォルト値
Mogul, Kent, Partridge, & McCloghrie [Page 8] RFC 1063 IP MTU Discovery Options July 1988
ムガール人、ケント、ヤマウズラ、およびMcCloghrie[8ページ]RFC1063IP MTU発見オプション1988年7月
routing cache entry, to be used when the real
MINMTU is unknown. Recommended value: 576.
本当のMINMTUが未知であるときに、使用されるためにキャッシュエントリーを発送します。 推奨値: 576.
Max_ConsecutiveProbs: The maximum number of probes to send
before assuming that the destination does
not support the probe option.
Recommended value: 10.
マックス_ConsecutiveProbs: それを仮定する前に目的地を送る徹底的調査の最大数は徹底的調査オプションをサポートしません。 推奨値: 10.
ProbeRetryTime: The time (in seconds) to wait before retrying
an unanswered probe. Recommended value:
60 seconds, or 2*RTT if the the RTT is available
to the IP layer.
ProbeRetryTime: 答えのない徹底的調査を再試行する前に待つ時間(秒の)。 推奨値: 60秒、RTTがIPに利用可能であるなら、2*RTTは層にします。
ReprobeInterval: The time to wait before sending a probe after
receiving a successful Reply MTU, in order to
detect increases in the route's MINMTU.
Recommended value: 5 times the ProbeRetryTime.
ReprobeInterval: ルートのMINMTUの増加を検出するためにうまくいっているReply MTUを受けた後に探測装置を送る前に待つ時間。 推奨値: ProbeRetryTimeの5倍。
IncreaseInterval: The time to wait before increasing the MINMTU
after the value has been decreased, to prevent
flapping. Recommended value: same as
ProbeRetryTime.
IncreaseInterval: 値の後にMINMTUを増加させる前に待つ時間は、ばたつくのを防ぐために減少しました。 推奨値: ProbeRetryTimeと同じです。
When a new route is entered into the routing cache, the initial values should be set as follows:
新しいルートがルーティングキャッシュに入れられるとき、初期の値は以下の通り設定されるべきです:
MINMTU = Default_MINMTU
MINMTUはデフォルト_MINMTUと等しいです。
ProbeRetry = Current Time
ProbeRetryは現在の時間と等しいです。
LastDecreased = Current Time - IncreaseInterval
現在のLastDecreased=時間--IncreaseInterval
ProbeReply = false
ProbeReplyは偽と等しいです。
SupportsProbes = true
SupportsProbesは本当に等しいです。
ConsecutiveProbes = 0
ConsecutiveProbes=0
This initialization is done before attempting to send the first packet along this route, so that the first packet will contain a Probe MTU option.
このルートに沿って最初のパケットを送るのを試みる前にこの初期化をします、最初のパケットがProbe MTUオプションを含むように。
Whenever the IP layer sends a datagram on this route it checks the SupportsProbes bit to see if the remote system supports probing. If the SupportsProbes bit is set, and the timestamp in ProbeRetry is less than or equal to the current time, a Probe option should be sent in the datagram, and the ProbeRetry field incremented by ProbeRetryTime.
IP層がこのルートでデータグラムを送るときはいつも、それは、リモートシステムが、調べるのを支持するかどうか確認するためにSupportsProbesビットをチェックします。 SupportsProbesビットが設定されて、ProbeRetryのタイムスタンプが現在の、より時間以下であるなら、データグラム、およびProbeRetryTimeによって増加されたProbeRetry分野でProbeオプションを送るべきです。
Mogul, Kent, Partridge, & McCloghrie [Page 9] RFC 1063 IP MTU Discovery Options July 1988
ムガール人、ケント、ヤマウズラ、およびMcCloghrie[9ページ]RFC1063IP MTU発見オプション1988年7月
Whether or not the Probe MTU option is sent in a datagram, if the ProbeReply bit is set, then a Reply MTU option with the value of the ReplyMTU field is placed in the outbound datagram. The ProbeReply bit is then cleared.
データグラムでProbe MTUオプションを送るか否かに関係なく、ProbeReplyビットが設定されるなら、ReplyMTU分野の値があるReply MTUオプションは外国行きのデータグラムに置かれます。 そして、ProbeReplyビットはきれいにされます。
Every time a Probe option is sent, the ConsecutiveProbes value should be incremented. If this value reaches Max_ConsecutiveProbes, the SupportsProbe bit should be cleared.
Probeオプションを送るときはいつも、ConsecutiveProbes値は増加されるべきです。 この値がマックス_ConsecutiveProbesに達するなら、SupportsProbeビットはきれいにされるべきです。
When an IP datagram containing the Probe MTU option is received, the receiving IP sets the ReplyMTU to the Probe MTU option value and sets the ProbeReply bit in its outbound route to the source of the datagram. The SupportsProbe bit is set, and the ConsecutiveProbes value is reset to 0.
Probe MTUオプションを含むIPデータグラムが受け取られているとき、受信IPはProbe MTUオプション価値にReplyMTUを設定して、データグラムの源への外国行きのルートにProbeReplyビットをはめ込みます。 SupportsProbeビットは設定されます、そして、ConsecutiveProbes値は0にリセットされます。
If an IP datagram containing the Reply MTU option is received, the IP layer must locate the routing cache entry corresponding to the source of the Reply MTU option; if no such entry exists, a new one (with default values) should be created. The SupportsProbe bit is set, and the ConsecutiveProbes value is reset to 0. The ProbeRetry field is set to the current time plus ReprobeInterval.
Reply MTUオプションを含むIPデータグラムが受け取られているなら、IP層はReply MTUオプションの源において、対応するルーティングキャッシュエントリーの場所を見つけなければなりません。 どれかそのようなエントリーが存在していないなら、新しい作成されるべきです(デフォルト値で)。 SupportsProbeビットは設定されます、そして、ConsecutiveProbes値は0にリセットされます。 ProbeRetry分野は現在の時間とReprobeIntervalに設定されます。
Four cases are possible when a Reply MTU option is received:
Reply MTUオプションが受け取られているとき、4つのケースが可能です:
(1) The Reply MTU option value is less than the current
MINMTU: the MINMTU field is set to the new value, and
the LastDecreased field is set to the current time.
(1) Reply MTUオプション価値は現在のMINMTU以下です: MINMTU分野は新しい値に設定されます、そして、LastDecreased分野は現在の時間に設定されます。
(2) The Reply MTU option value is greater than the
current MINMTU and the LastDecreased field plus
IncreaseInterval is less than the current time: set the
ProbeRetry field to LastDecreased plus IncreaseInterval,
but do not change MINMTU.
(2) Reply MTUオプション価値は現在のMINMTUとLastDecreased分野より現在の時間より大きいです、そして、IncreaseIntervalは以下です: LastDecreasedとIncreaseIntervalにProbeRetry分野を設定しなさい、ただし、MINMTUを変えないでください。
(3) The Reply MTU option value is greater than the
current MINMTU and the LastDecreased field plus
IncreaseInterval is greater than the current time: set
the MINMTU field to the new value.
(3) Reply MTUオプション価値は現在のMINMTUとLastDecreased分野より大きいです、そして、IncreaseIntervalは現在の時間よりすばらしいです: 新しい値にMINMTU分野を設定してください。
(4) The Reply MTU option value is equal to the current
MINMTU: do nothing more.
(4) Reply MTUオプション価値は現在のMINMTUと等しいです: それ以上何もをしてください。
Whenever the MTU field is changed, the transport layer should be notified, either by an upcall or by a change in a shared variable (which may be accessed from the transport layer by a downcall).
MTU分野を変えるときはいつも、トランスポート層はupcallか共用変数(downcallによってトランスポート層からアクセスされるかもしれない)における変化によって通知されるべきです。
If a fragmentation reassembly timeout occurs, if an ICMP Time Exceeded/Fragmentation Reassembly Timeout is received, or if the IP
ICMP Time Exceeded/断片化Reassembly Timeoutが受け取られているなら、断片化再アセンブリタイムアウトが起こるか、またはIPです。
Mogul, Kent, Partridge, & McCloghrie [Page 10] RFC 1063 IP MTU Discovery Options July 1988
ムガール人、ケント、ヤマウズラ、およびMcCloghrie[10ページ]RFC1063IP MTU発見オプション1988年7月
layer is asked to send a probe by a higher layer, the ProbeRetry field for the appropriate routing cache entry is set to the current time. This will cause a Probe option to be sent with the next datagram (unless the SupportsProbe bit is turned off).
層が、より高い層のそばで探測装置を送るように頼まれて、適切なルーティングキャッシュエントリーへのProbeRetry分野は現在の時間に設定されます。 これで、次のデータグラムでProbeオプションを送るでしょう(SupportsProbeビットがオフにされない場合)。
MANAGEMENT PARAMETERS
管理パラメタ
We suggest that the following parameters be made available to local applications and remote network management systems:
私たちは、局所塗布とリモートネットワーク管理システムが以下のパラメタを入手することを提案します:
(1) The number of probe retries to be made before determining
a system is down. The value of 10 is certain to be wrong
in some situations.
(1) システムを決定する前にされる徹底的調査再試行の数は下がっています。 10の値はいくつかの状況で間違っているのが確かです。
(2) The frequency with which probes are sent. Systems may
find that more or less frequent probing is more cost
effective.
(2) 探測装置が送られる頻度。 システムは、多少頻繁な調べが、より費用効率がよいのがわかるかもしれません。
(3) The default MINMTU used to initialize routes.
(3) デフォルトMINMTUは以前はよくルートを初期化していました。
(4) Applications should have the ability to force a probe
on a particular route. There are cases where a probe
needs to be sent but the sender doesn't know it. An
operator must be able to cause a probe in such situations.
Furthermore, it may be useful for applications to "ping"
for the MTU.
(4) アプリケーションには、特定のルートに徹底的調査を押しつける能力があるべきです。 ケースが徹底的調査が送られる必要があるところにありますが、送付者はそれを知りません。 オペレータはそのような状況における徹底的調査を引き起こすことができなければなりません。 その上、アプリケーションがMTUのために「確認」であることは、役に立つかもしれません。
REFERENCES
参照
[1] Kent, C. and J. Mogul, "Fragmentation Considered
Harmful", Proc. ACM SIGCOMM '87, Stowe, VT, August 1987.
[1] ケントとC.とJ.ムガール人、「有害であると考えられた断片化」、Proc。 ACM SIGCOMM87年、ストウ、バーモント、1987年8月。
[2] Postel, J., Ed., "Internet Protocol", RFC-791,
USC/Information Sciences Institute, Marina del Rey, CA,
September 1981.
[2] ポステル、J.、エド、「インターネットプロトコル」、RFC-791、USC/情報Sciences Institute、マリナデルレイ、カリフォルニア、9月1981
[3] Postel, J., Ed., "Transmission Control Protocol", RFC-793,
USC/Information Sciences Institute, Marina del Rey, CA,
September 1981.
[3] ポステル、J.、エド、「通信制御プロトコル」、RFC-793、USC/情報Sciences Institute、マリナデルレイ、カリフォルニア、9月1981
[4] Postel, J., "The TCP Maximum Segment Size and Related Topics",
RFC-879, USC/Information Sciences Institute, Marina del Rey,
CA, November 1983.
[4] ポステル、J.、「TCPの最大のセグメントサイズの、そして、関連の話題」、RFC-879、USC/情報Sciences Institute、マリナデルレイ、カリフォルニア(1983年11月)。
Mogul, Kent, Partridge, & McCloghrie [Page 11]
ムガール人、ケント、ヤマウズラ、およびMcCloghrie[11ページ]
一覧
スポンサーリンク
