IPv6用経路MTU探索(PMTU情報の格納)

広告

広告

原文

最終更新
2006-10-30T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/1981/rfc1981_52.html#source

IPv6用経路MTU探索(和訳)

最終更新
2006-10-30T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/1981/rfc1981_52.html#translation

5.2 PMTU情報の格納

   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の変更について経路を用いるパケット化層のインスタンスの通知が、パケットが消失した特別なインスタンスの通知と異なることを理解することが重要である。後者は、可能な限り早く(つまり、パケット化層のインスタンスの観点から非同期に)行われるべきであり、また前者はパケット化層がパケットの生成を望むまで遅れるかもしれない。再送は、パケット過大メッセージに示されたとして消失したと知られるそれらのパケットのみに行われるべきである。

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年10月30日 最終更新:2006年10月30日