広告
広告
https://www.7key.jp/rfc/1981/rfc1981_52.html#source
https://www.7key.jp/rfc/1981/rfc1981_52.html#translation
Ideally, a PMTU value should be associated with a specific path traversed by packets exchanged between the source and destination nodes. However, in most cases a node will not have enough information to completely and accurately identify such a path. Rather, a node must associate a PMTU value with some local representation of a path. It is left to the implementation to select the local representation of a path.
理想では、発信元と宛先ノード間で交換されたパケットが通る特定の経路はPMTU値と結びつけるべきである。しかし殆どの場合でノードは、そのような経路を完全に且つ正確に識別する十分な情報を持ち合わせていない。むしろノードは、経路のあるローカルな表現を持つPMTU値と結び付けなければならない。経路のローカルな表現の選択は実装に任せられる。
In the case of a multicast destination address, copies of a packet may traverse many different paths to reach many different nodes. The local representation of the "path" to a multicast destination must in fact represent a potentially large set of paths.
宛先アドレスがマルチキャストの場合、パケットの複製は多くの異なるノードへ届けられるため多くの異なる経路を通ることがある。マルチキャストの宛先への経路のローカルな表現は、実際経路の広い集合を表現することが可能なものでなければならない。
Minimally, an implementation could maintain a single PMTU value to be used for all packets originated from the node. This PMTU value would be the minimum PMTU learned across the set of all paths in use by the node. This approach is likely to result in the use of smaller packets than is necessary for many paths.
最低でも、実装はノードを発信元とする全てのパケットに用いられる単一のPMTU値を維持することができる。このPMTU値は、ノードに用いられる全ての経路集合を通して学習された最小PMTUである。この方法は、多くの経路に必要であるというよりも、より小さなパケットを用いることとなりそうである。
An implementation could use the destination address as the local representation of a path. The PMTU value associated with a destination would be the minimum PMTU learned across the set of all paths in use to that destination. The set of paths in use to a particular destination is expected to be small, in many cases consisting of a single path. This approach will result in the use of optimally sized packets on a per-destination basis. This approach integrates nicely with the conceptual model of a host as described in [ND]: a PMTU value could be stored with the corresponding entry in the destination cache.
実装は、経路のローカルな表現として宛先アドレスを用いるかもしれない。宛先と結び付けられるPMTU値は、その宛先として用いられる全ての経路の集合を通して学習された最小PMTUである。多くの場合単一の経路からなるため、特定の宛先に用いられる経路の集合は小さいと予想される。この方法は、宛先ごとに最適なサイズのパケットを用いる結果となるだろう。またこの方法は、[ND]で記述されるようにホストの概念モデルとうまく合致する。この場合、1つのPMTU値は宛先キャッシュの一致するエントリと共に格納されることができる。
If flows [IPv6-SPEC] are in use, an implementation could use the flow id as the local representation of a path. Packets sent to a particular destination but belonging to different flows may use different paths, with the choice of path depending on the flow id. This approach will result in the use of optimally sized packets on a per-flow basis, providing finer granularity than PMTU values maintained on a per-destination basis.
フロー[IPv6-SPEC]が用いられる場合、実装は経路のローカルな表現としてフローIDを用いることがある。特定の宛先へ送信されるが異なるフローに属するパケットは、フローIDに依存する経路を選択して異なる経路を用いるだろう。この方法は、宛先ごとに維持されるPMTU値よりも優れた精度を提供することにより、フローごとの最適なサイズのパケットを用いる結果となるだろう。
For source routed packets (i.e. packets containing an IPv6 Routing header [IPv6-SPEC]), the source route may further qualify the local representation of a path. In particular, a packet containing a type 0 Routing header in which all bits in the Strict/Loose Bit Map are equal to 1 contains a complete path specification. An implementation could use source route information in the local representation of a path.
発信元経路制御パケット(つまり、IPv6ルーティングヘッダ[IPv6-SPEC]を含むパケット)について、発信元経路は経路のローカルな表現をさらに限定するかもしれない。特に、S/L Bit Mapの全てのビットが1であるタイプゼロルーティングヘッダを含むパケットは、完全な経路の明細を含む。実装は、経路のローカルな表現に発信元経路情報を用いることができる。
Note: Some paths may be further distinguished by different security classifications. The details of such classifications are beyond the scope of this memo.
注記:ある経路は、異なる安全性への分類によってさらに区別されるかもしれない。そのような分類の詳細については当メモの範囲外である。
Initially, the PMTU value for a path is assumed to be the (known) MTU of the first-hop link.
最初に、経路のPMTU値は最初のホップリンクの(既知の)MTUであると想定される。
When a Packet Too Big message is received, the node determines which path the message applies to based on the contents of the Packet Too Big message. For example, if the destination address is used as the local representation of a path, the destination address from the original packet would be used to determine which path the message applies to.
パケット過大メッセージを受信した際、ノードはそのパケット過大メッセージの内容に基づきメッセージがどの経路に適用されたものであるかを決定する。例えば、宛先アドレスが経路のローカルな表現として用いられる場合、原因のパケットからの宛先アドレスがメッセージが適用されるどの経路かを決定するために用いられる。
Note: if the original packet contained a Routing header, the Routing header should be used to determine the location of the destination address within the original packet. If Segments Left is equal to zero, the destination address is in the Destination Address field in the IPv6 header. If Segments Left is greater than zero, the destination address is the last address (Address[n]) in the Routing header.
注記:原因となるパケットがルーティングヘッダを含む場合、ルーティングヘッダは原因となるパケット内の宛先アドレスの位置を決定するために用いられるべきである。セグメントの残りがゼロとなる場合、宛先アドレスはIPv6ヘッダ内の宛先アドレスフィールドにある。セグメントの残りがゼロより大きいのであれば、宛先アドレスはルーティングヘッダの最後のアドレス(アドレス[n])である。
The node then uses the value in the MTU field in the Packet Too Big message as a tentative PMTU value, and compares the tentative PMTU to the existing PMTU. If the tentative PMTU is less than the existing PMTU estimate, the tentative PMTU replaces the existing PMTU as the PMTU value for the path.
また、ノードは仮のPMTU値としてパケット過大メッセージのMTUフィールドの値を用い、仮のPMTUと現在のPMTUを比較する。仮のPMTUが現在のPMTUの概算よりも小さい場合、仮のPMTUがその経路のPMTU値として現在のPMTUを置き換える。
The packetization layers must be notified about decreases in the PMTU. Any packetization layer instance (for example, a TCP connection) that is actively using the path must be notified if the PMTU estimate is decreased.
パケット化層は、PMTUの減少について通知されなければならない。経路を積極的に使用するパケット化層のインスタンス(例えば、TCPコネクション)は、PMTUの概算が減らされるのであれば通知されなければならない。
Note: even if the Packet Too Big message contains an Original Packet Header that refers to a UDP packet, the TCP layer must be notified if any of its connections use the given path.
注記:例えパケット過大メッセージがUDPパケットを参照するオリジナルのパケットヘッダを含んでいたとしても、コネクションのいずれかが与えられた経路を用いるのであれば、TCP層に通知しなければならない。
Also, the instance that sent the packet that elicited the Packet Too Big message should be notified that its packet has been dropped, even if the PMTU estimate has not changed, so that it may retransmit the dropped data.
同様に、パケット過大メッセージの原因となるパケットを送信したインスタンスは、例えPMTU概算が変更されなくても消失したデータを再送するように、消失したパケットを通知すべきである。
Note: An implementation can avoid the use of an asynchronous notification mechanism for PMTU decreases by postponing notification until the next attempt to send a packet larger than the PMTU estimate. In this approach, when an attempt is made to SEND a packet that is larger than the PMTU estimate, the SEND function should fail and return a suitable error indication. This approach may be more suitable to a connectionless packetization layer (such as one using UDP), which (in some implementations) may be hard to "notify" from the ICMP layer. In this case, the normal timeout-based retransmission mechanisms would be used to recover from the dropped packets.
注記:実装は、PMTUの概算よりも大きなパケットを送信する次の試みまで通知を延期することによって、PMTU減少の非同期通知メカニズムの使用を避けることができる。この方法では、試行がPMTUの概算よりも大きなパケットを送信させる際、SEND機能は失敗とし、適切なエラー指示を返すべきである。この方法は、(ある実装への)ICMP層からの通知を困難にするかもしれないコネクションレスパケット化層(UDPを用いるような)により適しているかもしれない。この場合、通常のタイムアウトに基づく再送メカニズムは、消失したパケットの回復に用いられる。
It is important to understand that the notification of the packetization layer instances using the path about the change in the PMTU is distinct from the notification of a specific instance that a packet has been dropped. The latter should be done as soon as practical (i.e., asynchronously from the point of view of the packetization layer instance), while the former may be delayed until a packetization layer instance wants to create a packet. Retransmission should be done for only for those packets that are known to be dropped, as indicated by a Packet Too Big message.
PMTUの変更について経路を用いるパケット化層のインスタンスの通知が、パケットが消失した特別なインスタンスの通知と異なることを理解することが重要である。後者は、可能な限り早く(つまり、パケット化層のインスタンスの観点から非同期に)行われるべきであり、また前者はパケット化層がパケットの生成を望むまで遅れるかもしれない。再送は、パケット過大メッセージに示されたとして消失したと知られるそれらのパケットのみに行われるべきである。
広告