IPv6の仕様(フローラベル)

広告

広告

原文

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

IPv6の仕様(和訳)

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

6. フローラベル

   The 24-bit Flow Label field in the IPv6 header may be used by a
   source to label those packets for which it requests special handling
   by the IPv6 routers, such as non-default quality of service or
   "real-time" service.  This aspect of IPv6 is, at the time of writing,
   still experimental and subject to change as the requirements for flow
   support in the Internet become clearer.  Hosts or routers that do not
   support the functions of the Flow Label field are required to set the
   field to zero when originating a packet, pass the field on unchanged
   when forwarding a packet, and ignore the field when receiving a
   packet.

IPv6ヘッダ内の24bitフローラベルフィールドは、非デフォルトの品質サービスや即時性サービスといったように、IPv6ルータによって特別な処理を要求するパケットへのラベル付けのために発信元によって用いられることがある。このIPv6の特性は、当文書の執筆時点で、インターネットでのフローサポートの要求事項が明確となるまでは実験的であり変更されることがある。フローラベルフィールドの機能をサポートしないホストやルータは、パケットの生成時にはそのフィールドにゼロをセットすることが要求され、転送時にはそのフィールドの内容を変更せずに転送することが要求され、パケットを受信した際はそのフィールドを無視するよう要求される。

   A flow is a sequence of packets sent from a particular source to a
   particular (unicast or multicast) destination for which the source
   desires special handling by the intervening routers.  The nature of
   that special handling might be conveyed to the routers by a control
   protocol, such as a resource reservation protocol, or by information
   within the flow's packets themselves, e.g., in a hop-by-hop option.
   The details of such control protocols or options are beyond the scope
   of this document.

フローは、経路途中のルータに特別な処理を望む特定の発信元から特定の(ユニキャストやマルチキャスト)宛先へ送信されたパケットのシーケンスである。その特別な処理の性質は、資源予約プロトコルのような管理プロトコルによって、或いはフローパケットの中の情報――例えばホップバイホップオプション――によってルータに伝えられることとなる。このような管理プロトコルやオプションの詳細については当文書の範囲外である。

   There may be multiple active flows from a source to a destination, as
   well as traffic that is not associated with any flow.  A flow is
   uniquely identified by the combination of a source address and a
   non-zero flow label.  Packets that do not belong to a flow carry a
   flow label of zero.

フローと関係のないトラフィックと同様に、発信元から宛先までの多数の有効なフローがある可能性がある。フローは、発信元アドレスと非ゼロフローラベルの組み合わせによって一意に識別される。フローに属さないパケットはゼロのフローラベルを含む。

   A flow label is assigned to a flow by the flow's source node.  New
   flow labels must be chosen (pseudo-)randomly and uniformly from the
   range 1 to FFFFFF hex.  The purpose of the random allocation is to
   make any set of bits within the Flow Label field suitable for use as
   a hash key by routers, for looking up the state associated with the
   flow.

フローラベルは、フローの発信元ノードによってフローに割り当てられる。新しいフローラベルは、1から16進数のFFFFFFの間で(擬似的)無作為に選ばれなければならない。無作為な割り当ての意図するところは、ルータがフロー状態を調べる際のハッシュキーとして用いるに相応しいビットの集合を作ることにある。

   All packets belonging to the same flow must be sent with the same
   source address, destination address, priority, and flow label.  If
   any of those packets includes a Hop-by-Hop Options header, then they
   all must be originated with the same Hop-by-Hop Options header
   contents (excluding the Next Header field of the Hop-by-Hop Options
   header).  If any of those packets includes a Routing header, then
   they all must be originated with the same contents in all extension
   headers up to and including the Routing header (excluding the Next
   Header field in the Routing header).  The routers or destinations are
   permitted, but not required, to verify that these conditions are
   satisfied.  If a violation is detected, it should be reported to the
   source by an ICMP Parameter Problem message, Code 0, pointing to the
   high-order octet of the Flow Label field (i.e., offset 1 within the
   IPv6 packet).

同一フローに属する全てのパケットは、同一の発信元アドレス、同一の宛先アドレス、同一のフローラベルにて送信されなければならない。それらがホップバイホップオプションヘッダを含むパケットであれば、それらのパケットは全て同じ内容のホップバイホップオプションヘッダ(ホップバイホップオプションヘッダのネクストヘッダフィールドは除く)でなければならない。それらがルーティングヘッダを含むパケットであれば、それらのパケットは全てルーティングヘッダ以下の全拡張ヘッダと同じ内容(ルーティングヘッダのネクストヘッダは除く)でなければならない。ルータや宛先がこれらの条件を満たすことの確認は、認められているが求められてはいない。違反が検知されたのであれば、フローラベルフィールドの最上位オクテット(つまり、IPv6パケット中のオフセット1)を示すICMP不正パラメータメッセージ、コード"0"によって発信元に通知されるべきである。

   Routers are free to "opportunistically" set up flow-handling state
   for any flow, even when no explicit flow establishment information
   has been provided to them via a control protocol, a hop-by-hop
   option, or other means.  For example, upon receiving a packet from a
   particular source with an unknown, non-zero flow label, a router may
   process its IPv6 header and any necessary extension headers as if the
   flow label were zero.  That processing would include determining the
   next-hop interface, and possibly other actions, such as updating a
   hop-by-hop option, advancing the pointer and addresses in a Routing
   header, or deciding on how to queue the packet based on its Priority
   field.  The router may then choose to "remember" the results of those
   processing steps and cache that information, using the source address
   plus the flow label as the cache key.  Subsequent packets with the
   same source address and flow label may then be handled by referring
   to the cached information rather than examining all those fields
   that, according to the requirements of the previous paragraph, can be
   assumed unchanged from the first packet seen in the flow.

コントロールプロトコル、ホップバイホップオプション、その他の手段によって、明示的なフロー設定情報が供給されなかったときでさえ、ルータは任意のフローに対して"ご都合主義的な"フローの処理状態を設定することができる。例えば、ある特定の未知の発信元からのパケットを受け取った際、ルータはフローラベルがゼロであるかのようにそのIPv6ヘッダや他の拡張ヘッダを処理してもよい。その処理には、ネクストホップのインターフェイスの決定を含み、更にはホップバイホップオプションの更新、ルーティングヘッダでポインタやアドレスを進めること、優先権フィールドに基づいてどのようにパケットを待ち行列に入れるべきかを決めることのような動作の可能性を含むだろう。ルータは、発信元アドレスとフローラベルをキャッシュのキーとして用いた情報と処理結果を記憶することを選択してもよい。同じ発信元アドレスとフローラベルを持つ2つ目以降のパケットは、前段落の要求事項によればフローを調べた1つ目のパケットから変更がないと想定できるので、フィールドすべての検査ではなくキャッシュ情報の参照により処理をしてもよい。

   Cached flow-handling state that is set up opportunistically, as
   discussed in the preceding paragraph, must be discarded no more than
   6 seconds after it is established, regardless of whether or not
   packets of the same flow continue to arrive.  If another packet with
   the same source address and flow label arrives after the cached state
   has been discarded, the packet undergoes full, normal processing (as
   if its flow label were zero), which may result in the re-creation of
   cached flow state for that flow.

全段落で触れたように、ご都合主義で決められたフロー処理状態のキャッシュは、同じフローのパケットが到着し続けるかどうかに関らずキャッシュされて6秒後には破棄されなければならない。同じ発信元アドレスとフローラベルの他のパケットがキャッシュされた情報が破棄された後に到着したのであれば、そのパケットは完全で標準的な処理(そのフローラベルがゼロであるように)が行われ、そのフローのための新しいフロー処理状態のキャッシュが作られる。

   The lifetime of flow-handling state that is set up explicitly, for
   example by a control protocol or a hop-by-hop option, must be
   specified as part of the specification of the explicit set-up
   mechanism; it may exceed 6 seconds.

例えばコントロールプロトコルやホップバイホップオプションによって、明示的にセットされたフロー処理状態の生存期間は、セットアップ機構の一部として明示されなくてはならず、それは6秒を超えるかもしれない。

   A source must not re-use a flow label for a new flow within the
   lifetime of any flow-handling state that might have been established
   for the prior use of that flow label.  Since flow-handling state with
   a lifetime of 6 seconds may be established opportunistically for any
   flow, the minimum interval between the last packet of one flow and
   the first packet of a new flow using the same flow label is 6
   seconds.  Flow labels used for explicitly set-up flows with longer
   flow-state lifetimes must remain unused for those longer lifetimes
   before being re-used for new flows.

発信元は、既に用いられたフローラベルによって設定された全てのフロー処理状態の生存期間内に、新しいフローとしてフローラベルを再利用してはならない。ご都合主義的なフローが6秒の生存期間をもつフロー処理状態を設定する可能性もあるため、同じフローラベルを用いる最後のパケットと新しいフローの最初のパケットの最小間隔は6秒である。より長い生存期間を持つよう明示的に設定されたフローを用いるフローラベルは、その生存期間の間新しいフローに再利用されないままの未使用でなければならない。

   When a node stops and restarts (e.g., as a result of a "crash"), it
   must be careful not to use a flow label that it might have used for
   an earlier flow whose lifetime may not have expired yet.  This may be
   accomplished by recording flow label usage on stable storage so that
   it can be remembered across crashes, or by refraining from using any
   flow labels until the maximum lifetime of any possible previously
   established flows has expired (at least 6 seconds; more if explicit
   flow set-up mechanisms with longer lifetimes might have been used).
   If the minimum time for rebooting the node is known (often more than
   6 seconds), that time can be deducted from the necessary waiting
   period before starting to allocate flow labels.

ノードが停止し再起動する際(例えばクラッシュの結果として)、まだ生存期限内でそれまでのフローとして用いられた可能性のあるフローラベルを用いないことに注意しなければならない。これは、クラッシュしても尚記憶可能な安定した記憶装置にフローラベルを記録することによって、又は既に確定したフローの最大生存期間の期限が切れるまで(少なくとも6秒、より長い生存期間を持つフローセットアップ機構が用いられたことが明らかであれば更に多い期間)フローラベルの使用を自粛することによって実現するだろう。ノードを再起動する最小時間が既知であれば(多くの場合6秒以上)、フローラベルの割り当て前にその時間を必要な待機時間から引くことができる。

   There is no requirement that all, or even most, packets belong to
   flows, i.e., carry non-zero flow labels.  This observation is placed
   here to remind protocol designers and implementors not to assume
   otherwise.  For example, it would be unwise to design a router whose
   performance would be adequate only if most packets belonged to flows,
   or to design a header compression scheme that only worked on packets
   that belonged to flows.

パケットの全てもしくは大部分がフローに属する――つまり非ゼロのフローラベルに含まれるという――という要求事項はない。これは考え違いをしているプロトコルの設計者や実装者への忠告である。例えば、大部分がフローに属するパケットのみを適切とするルータを設計することや、フローに属したパケットにのみ機能するヘッダ圧縮機構を設計することは適切ではない。

広告

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