この文書はRFC1809の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group C. Partridge
Request for Comments: 1809 BBN Systems and Technologies
Category: Informational June 1995
Using the Flow Label Field in IPv6
ＩＰｖ６でフローラベルフィールドの使用
Status of this Memo
この文書の状態
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
このメモはインターネット共同体のための情報を供給します。このメモはイ
ンターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
The purpose of this memo is to distill various opinions and
suggestions of the End-to-End Research Group regarding the handling
of Flow Labels into a set of suggestions for IPv6. This memo is for
information purposes only and is not one of the IPv6 specifications.
Distribution of this memo is unlimited.
このメモの目的はフローラベルの取り扱いに関するエンドエンド研究グルー
プの様々な意見と提案から要旨を抜き出し、ＩＰｖ６に提案することです。
このメモは情報の目的のみであり、ＩＰｖ６仕様書の１つではありません。
このメモの配布は無制限です。
Introduction
はじめに
This memo originated as the report of a discussion at an End-to-End
Research Group meeting in November 1994. At that meeting the group
discussed several issues regarding how to manage flow identifiers in
IPv6. A report of the meeting was then circulated to the IPv6
community. Feedback from that community resulted in changes to this
memo and in changes to the IPv6 specification to fix some minor
problems the End-to-End Group had raised.
このメモは１９９４年１１月にエンドエンド研究グループのミーティングの
論議の報告を基にします。そのミーティングにおいてグループは、どのよう
にＩＰｖ６でフロー識別子を管理するべきかに関して、いくつかの問題を論
じました。それからミーティングの報告がＩＰｖ６共同体に配布されました。
その共同体からのフィードバックがエンドエンドグループが取り上げていた
あるマイナーな問題を直すために、このメモに対する変更と、ＩＰｖ６仕様
書に対する変更をもたらしました。
While many of the ideas in this memo have found their way into the
IPv6 specification, the explanation of why various design decisions
were made have not. This memo is intended to provide some additional
context for interested parties.
このメモでの考えの多くがＩＰｖ６仕様書の中に見出されますが、種々なデ
ザイン決定がされた理由の説明はありません。このメモは興味を持った人に
ある追加の状況を提供するように意図されます。
Brief Description of the Flow Label
フローラベルの短い記述
The current draft of the IPv6 specification states that every IPv6
header contains a 24-bit Flow Label. (Originally the specification
called for a 28-bit Flow ID field, which included the flow label and
a 4-bit priority field. The priority field is now distinct, for
reasons discussed at the end of this memo).
ＩＰｖ６仕様書の現在のドラフトはすべてのＩＰｖ６ヘッダーが２４ビット
のフローラベルを含んでいると述べます。（元の仕様書はフローラベルを含
む２８ビットのフロー識別子フィールドと４ビットの優先フィールドを必要
としました。優先フィールドは、このメモの終わりにおいて論じられた理由
のために、今、分離されています）。
The Flow Label is a pseudo-random number between 1 and FFFFFF (hex)
that is unique when combined with the source address. The zero Flow
Label is reserved to say that no Flow Label is being used. The
specification requires that a source must not reuse a Flow Label
value until all state information for the previous use of the Flow
Label has been flushed from all routers in the internet.
フローラベルは１からFFFFFF（１６進数）の間の疑似乱数で、ソースアドレ
スとの組み合わせで、ユニークです。ゼロフローラベルはフローラベルが使
われていないと言うために予約されます。仕様書は、前のフローラベルの使
用に関する状態情報がインターネットの全てのルータから消されるまで、フ
ローラベル値の再利用をしてはならないことを要求します。
The specification further requires that all datagrams with the same
(non-zero) Flow Label must have the same Destination Address, Hop-
by-Hop Options header, Routing Header and Source Address contents.
The notion is that by simply looking up the Flow Label in a table,
the router can decide how to route and forward the datagram without
examining the rest of the header.
仕様書はさらにすべての同じ（非ゼロ）フローラベルを持つデータグラムが
同じ宛先アドレスと、ホップ毎オプションヘッダと、ルーティングヘッダと、
ソースアドレス内容を持っていなくてはならないことを要求します。考えは
表のフローラベルを調べるだけで、ルータがヘッダの残りを調べないで、デー
タグラムの経路を決めて、転送する方法を決定できるということです。
Flow Label Issues
フローラベル問題
The IPv6 specification originally left open a number of questions, of
which these three were among the most important:
ＩＰｖ６仕様書は多くの問題を未解決のままにしていました、以下の３つが
最も重要なものです：
1. What should a router do if a datagram with a (non-zero)
Flow Label arrives and the router has no state for that
Flow Label?
1. もし（非ゼロ）フローラベル を持つデータグラムが到着し、そし
てルーターがそのフローラベルのための状態を持っていないなら、
ルータは何をするべきですか？
2. How does an internet flush old Flow Labels?
2. どのようにインターネットが古いフローラベルを消しますか？
3. Which datagrams should carry (non-zero) Flow Labels?
3. どのデータグラムが（非ゼロ）フローラベルを運ぶべきですか？
This memo summarizes the End-to-End Group's attempts to answer these
questions.
このメモはこれらの質問に答えるエンドエンドグループの試みを要約します。
What Does a Router Do With Flow Labels for Which It Has No State?
ルータがフローラベルに関して状態をを持っていない時、何をしますか？
If a datagram with a non-zero Flow Label arrives at a router and the
router discovers it has no state information for that Flow Label,
what is the correct thing for the router to do?
もし非ゼロのフローラベルを持っているデータグラムがルータに到達し、ルー
タがそのフローラベルの状態を持っていないことに気づいたなら、ルータが
するべき正しいことは何か？
The IPv6 specification allows routers to ignore Flow Labels and also
allows for the possibility that IPv6 datagrams may carry flow setup
information in their options. Unknown Flow Labels may also occur if
a router crashes and loses its state. During a recovery period, the
router will receive datagrams with Flow Labels it does not know, but
this is arguably not an error, but rather a part of the recovery
period. Finally, if the controversial suggestion that each TCP
connection be assigned a separate Flow Label is adopted, it may be
necessary to manage Flow Labels using an LRU cache (to avoid Flow
Label cache overflow in routers), in which case an active but
infrequently used flow's state may have been intentionally discarded.
ＩＰｖ６仕様書はルータがフローラベルを無視することを許して、そして同
じくＩＰｖ６データグラムがオプションでフロー設定情報を運ぶかもしれな
いという可能性を考慮します。未知のフローラベルは、もしルータが故障し、
状態を失うなら、同じく生じるかもしれません。回復時期の間に、ルータは
知らないフローラベルでデータグラムを受け取るでしょう、しかしこれは多
分エラーではなく、どちらかと言うと回復期間の一部です。最終的に、もし
それぞれのＴＣＰ接続に別のフローラベルを割り当てるという論争の的の提
案が採用されるなら、（フローラベルキャッシュでルータが溢れるのを避け
るために）ＬＲＵキャッシュを使ってフローラベルを管理する必要があるか
もしれません、そしてその場合アクティブであるが、たまにしか使われない
フロー状態は意図的に捨てられるかもしれません。
In any case, it is clear that treating this situation as an error
and, say dropping the datagram and sending an ICMP message, is
inappropriate. Indeed, it seems likely that in most cases, simply
forwarding the datagram as one would a datagram with a zero Flow
Label would give better service to the flow than dropping the
datagram.
どんな場合でも、この状態をエラーと扱い、データグラムを捨て、ＩＣＭＰ
メッセージを送るのは、不適当であることが明確です。本当に、たいていの
場合で、ゼロフローラベルのデータグラムに対するのと同様に、データグラ
ムを転送することは、フローデータグラムを落とすより良いサービスを与え
るであろうと思われます。
Of course, there will be situations in which routing the datagram as
if its Flow Label were zero will cause the wrong result. An example
is a router which has two paths to the datagram's destination, one
via a high-bandwidth satellite link and the other via a low-bandwidth
terrestrial link. A high bandwidth flow obviously should be routed
via the high-bandwidth link, but if the router loses the flow state,
the router may route the traffic via the low-bandwidth link, with the
potential for the flow's traffic to swamp the low-bandwidth link. It
seems likely, however, these situations will be exceptions rather
than the rule. So it seems reasonable to handle these situations
using options that indicate that if the flow state is absent, the
datagram needs special handling. (The options may be Hop-by-Hop or
only handled at some routers, depending on the flow's needs).
もちろん、そのフローラベルがゼロであるように、データグラムの経路を決
めることが悪い結果をもたらす状態があるでしょう。例えばデータグラムの
宛先に、広帯域の人工衛星リンクと、低帯域の地球リンクの２つのパスを持っ
ているルータです。広帯域フローが明らかに広帯域リンクに経路を決められ
るべきですが、もしルータがフロー状態を失うなら、ルータは低帯域のリン
クにトラヒックを流し、フロートラフィックが低帯域リンクを圧倒する可能
性があるかもしれません。これはありそうに思われます、しかしながら、こ
れらの状態は規則というよりどちらかと言うと、例外であるでしょう。そこ
で、これらの状態は、もしフロー状態がないならデータグラムが特別扱いを
必要とすることを示すオプション、を使って対処することが合理的に思われ
ます。（オプションは「ホップ毎」かもしれないし、フローの必要によって、
あるルータだけが扱うかもしれません）。
It would clearly be desirable to have some method for signalling to
end systems that the flow state has been lost and needs to be
refreshed. One possibility is to add a state-lost bit to the Flow
Label field, however there is sensitivity to eating into the precious
24-bits of the field. Other possibilities include adding options to
the datagram to indicate its Flow Label was unknown or sending an
ICMP message back to the flow source.
末端システムにフロー状態が失われていて、更新する必要があると合図する
なんらかの方法を持つことは明らかに望ましいでしょう。１つの可能性が、
どんなにフィールドの貴重な２４ビットを減らす事になるが、フローラベル
フィールドに損失状態ビットを加えることです。他の可能性はそのフローラ
ベルが未知であることを示すためにデータグラムにオプションを加えるか、
あるいはフローソースにＩＣＭＰメッセージを送ることです。
In summary, the view is that the default rule should be that if a
router receives a datagram with an unknown Flow Label, it treats the
datagram as if the Flow Label is zero. As part of forwarding, the
router will examine any hop-by-hop options and learn if the the
datagram requires special handling. The options could include simply
the information that the datagram is to be dropped if the Flow Label
is unknown or could contain the flow state the router should have.
There is clearly room here for experimentation with option design.
まとめると、デフォルト規則は、もしルータが未知のフローラベルのデータ
グラムを受け取るなら、フローラベルがゼロであるかのようにデータグラム
を扱うべき、という意見です。転送機能の一部として、ルーターはホップ毎
オプションでも調べて、もしデータグラムが特別扱いを必要なら学ぶでしょ
う。オプションは、もしフローラベルが未知であるか、あるいはルータが持っ
ているべきフロー状態を持っていないなら、データグラムを廃棄すべきとい
う情報を含むことができます。オプション設計の実験のためにクリーンルー
ムがあります。
Flushing Old Flow Labels
古いフローラベルの消去
The flow mechanism assumes that state associated with a given Flow
Label is somehow deposited in routers, so they know how to handle
datagrams that carry the Flow Label. A serious problem is how to
flush Flow Labels that are no longer being used (stale Flow Labels)
from the routers.
フローメカニズムはあるフローラベルと結びついた状態がルータにあると想
定します、それでルータはどのようにフローラベルを運ぶデータグラムを処
理するべきか知っています。重大な問題はルータからもう使われていないフ
ローラベル（古いフローラベル）を消す方法です。
Stale Flow Labels can happen a number of ways, even if we assume that
the source always sends a message deleting a Flow Label when the
source finishes using a Flow. An internet may have partioned since
the flow was created. Or the deletion message may be lost before
reaching all routers. Furthermore, the source may crash before it
can send out a Flow Label deletion message. The point here is that
we cannot expect the source (or, for the same reasons, a third party)
always to clear out stale Flow Labels. Rather, routers will have to
find some mechanism to flush Flow Labels themselves.
古いフローラベルは、たとえソースがフローを使い終えるときにフロー削除
メッセージを常に送るとしても、多くの方法で起きることができます。イン
ターネットが、フローが作られた後で、分裂したかもしれません。あるいは
削除メッセージがすべてのルーターに届く前に失われたかもしれません。さ
らに、ソースがフローラベル削除メッセージを送る前に、停止するかもしれ
ません。ここで重要なのは、我々が常に古いフローラベルを整理のに、ソー
スに期待する（あるいは、同じ理由で第３者に期待する）ことができないと
いうことです。どちらかと言うと、ルータは自分自身でフローラベルを消去
するなんらかのメカニズムがを見つけなければならないでしょう。
The obvious mechanism is to use a timer. Routers should discard Flow
Labels whose state has not been refreshed within some period of time.
At the same time, a source that crashes must observe a quiet time,
during which it creates no flows, until it knows that all Flow Labels
from its previous life must have expired. (Sources can avoid quiet
time restrictions by keeping information about active Flow Labels in
stable storage that survives crashes). This is precisely how TCP
initial sequence numbers are managed and it seems the same mechanism
should work well for Flow Labels.
明らかなメカニズムはタイマを使う事です。ルータはその状態が一定期間内
に更新されなかったフローラベルを捨てるべきです。同時に、停止したソー
スは、前に作ったフローラベルの期限が切れた事を知るまで、フローを作ら
ない静かな時間をすごさなければなりません。（ソースが停止しても生き残
る安定した記憶装置にアクティブなフローラベルの情報を保管することで静
かな時間の制限を避けることができます）。これは正確にＴＣＰ初期シーケ
ンス番号が管理される方法で、同じメカニズムがフローラベルでうまく動く
と思われます。
Exactly how the Flow Label and its state should be refreshed needs
some study. There are two obvious options. The source could
periodically send out a special refresh message (such as an RSVP Path
message) to explicitly refresh the Flow Label and its state. Or, the
router could treat every datagram that carries the Flow Label as an
implicit refresh or sources could send explicit refresh options. The
choice is between periodically handling a special update message and
doing an extra computation on each datagram (namely noting in the
Flow Label's entry that the Flow Label has been refreshed).
正確にフローラベルとその状態が更新されるべき方法はいくらかの研究を必
要とします。２つの明白な選択があります。ソースは周期的に明示的にフロー
ラベルとその状態を更新する（ＲＳＶＰパスメッセージのような）特別な更
新メッセージを送ることができます。あるいは、ルータはフローラベルを運
ぶすべてのデータグラムを暗黙の更新と扱うことができます、あるいはソー
スが明示的な更新オプションを送ることができます。周期的に特別な更新メッ
セージを処理するか、それとも各データグラムに対し拡張計算をするか（す
なわちフローラベル項目があればフローラベルを更新します）の選択です。
Which Datagrams Should Carry (Non-Zero) Flow Labels?
どのデータグラムが（非ゼロ）フローラベルを運ぶべきか？
Interestingly, this is the problem on which the least progress has
been made.
興味深い事に、これは最も解決していない問題です。
There were some points of basic agreement. Small exchanges of data
should have a zero Flow Label, because it is not worth creating a
flow for a few datagrams. Real-time flows must obviously always have
a Flow Label, since flows are a primary reason Flow Labels were
created. The issue is what to do with peers sending large amounts of
best effort traffic (e.g., TCP connections). Some people want all
long-term TCP connections to use Flow Labels, others do not.
いくつかの基本的な合意がありました。少量のデータ交換はゼロフローラベ
ルを持つべきです、なぜなら少数のデータグラムのためにフローを作る価値
がありませんから。フローラベルが作られ主な理由であるので、リアルタイ
ムフローが明らかに常にフローラベルを持っていなくてはなりません。問題
は大量の最善努力トラフィックを送る状態で、何をするべきかです（例えば、
ＴＣＰ接続）。ある人々がすべての長期ＴＣＰ接続がフローラベルを使うこ
とを望みます、他の人がそうでありません。
The argument in favor of using Flow Labels on individual TCP
connections is that even if the source does not request special
service, a network provider's routers may be able to recognize a
large amount of traffic and use the Flow Label field to establish a
special route that gives the TCP connection better service (e.g.,
lower delay or bigger bandwidth). Another argument is to assist in
efficient demux at the receiver (i.e., IP and TCP demuxing could be
done once).
個別のＴＣＰ接続の上にフローラベルを使うことに賛成の議論はたとえソー
スが特別なサービスを求めないとしても、ネットワークプロバイダのルータ
が大量トラフィックを認識して、ＴＣＰ接続にもっと良いサービス（例えば、
より低遅延あるいはより大きい帯域幅）を与える特別な経路を確立するため
にフローラベルフィールドを使うことが可能であるかもしれないということ
です。他の議論は受信側で非多重送信です（すなわち、ＩＰとＴＣＰ非多重
化が１度で済む）。
An argument against using Flow Labels in individual TCP connections
is that it changes how we handling route caches in routers.
Currently one can cache a route for a destination host, regardless of
how many different sources are sending to that destination host.
I.e., if five sources each have two TCP connections sending data to a
server, one cache entry containing the route to the server handles
all ten TCPs' traffic. Putting Flow Labels in each datagram changes
the cache into a Flow Label cache, in which there is a cache entry
for every TCP connection. So there's a potential for cache
explosion. There are ways to alleviate this problem, such as
managing the Flow Label cache as an LRU cache, in which infrequently
used Flow Labels get discarded (and then recovered later). It is not
clear, however, whether this will cause cache thrashing.
個別のＴＣＰ接続でフローラベルを使うことに対しての論拠はルータで経路
キャッシュの取り扱いを変えるということです。現在あるものは、いくつの
ソースがその宛先ホストに送っているかにかかわらず、宛先ホストの経路を
キャッシュすることです。すなわち、もし５つのソースがそれぞれサーバに
データを送っている２つのＴＣＰ接続を持っているなら、サーバへの経路を
含む項目をキャッシュし、すべての１０のＴＣＰトラフィックを処理します。
各データグラムにフローラベルを入れることは、キャッシュをフローラベル
キャッシュに変え、これはすべてのＴＣＰ接続毎にキャッシュを持ちます。
それでキャッシュ急増の可能性があります。たまにしか使われないフローラ
ベルを廃棄する（そして後で回復する）、ＬＲＵキャッシュとして、フロー
ラベルキャッシュを管理する事で問題を軽減する方法があります。これが
キャッシュの破壊を起こすかどうかは、しかしながら、明確ではありません。
Observe that there is no easy compromise between these positions.
One cannot, for instance, let the application decide whether to use a
Flow Label. Those who want different Flow Labels for every TCP
connection assume that they may optimize a route without the
application's knowledge. And forcing all applications to use Flow
Labels will force routing vendors to deal with the cache explosion
issue, even if we later discover that we don't want to optimize
individual TCP connections.
これらの見解の間に容易な妥協がないと気付いてください。例えば、アプリ
ケーションにフローラベルを使うべきかどうか決めさせることができません。
すべてのＴＣＰ接続で異なったフローラベルを欲する人たちは、アプリケー
ションの知識なしで経路を最適化してもよいと想定します。そしてすべての
アプリケーションにフローラベルを使うことを強いることはルーティングの
ベンダーに、たとえ我々が後に我々が個別のＴＣＰ接続を最適化することを
望まないことを発見するとしても、キャッシュ爆発問題を扱うことを強いる
でしょう。
Note about the Priority Field
優先フィールドについてのメモ
The original IPv6 specification combined the Priority and Flow Label
fields and allowed flows to redefine the means of different values of
the Priority field. During its discussions, the End-to-End group
realized this meant that if a router forwarded a datagram with an
unknown Flow Label it had to ignore the Priority field, because the
priority values might have been redefined. (For instance, the
priorities might have been inverted). The IPv6 community concluded
this behavior was undesirable. Indeed, it seems likely that when the
Flow Label are unknown, the router will be able to give much better
service if it use the Priority field to make a more informed routing
decision. So the Priority field is now a distinct field, unaffected
by the Flow Label.
元のＩＰｖ６仕様書は優先とフローラベルフィールドを結合し、フローに毎
に優先フィールドの異なった値の再定義の手段を許しました。その議論の間
に、エンドエンドグループはこれがもしルータが未知のフローラベルのデー
タグラムを転送したなら、優先値が再定義されたかもしれないから、優先
フィールドを無視しなければならないことを意味するのを悟りました。（例
えば、優先は反転されたかもしれません）。ＩＰｖ６共同体はこの行動が望
ましくないと結論しました。実際、フローラベルが未知の時、ルータがより
理解に基づいたルーティング決定をするために優先フィールドを使うなら、
よりよい良いサービスを与えることが可能でしょう。それで、今、優先フィー
ルドは、フローラベルに影響されない別のフィールドです。
Acknowledgements
謝辞
I would like to acknowledge the assistance of the members of the
End-To-End Research Group, chaired by Bob Braden, whose discussions
produced this memo. I would also like to particularly thank Deborah
Estrin for her help in putting this memo together. Also thanks to
Richard Fox, Noel Chiappa, and Tony Li for insightful comments on the
draft.
私は、その論議がこのメモを作り出した、Bob Bradenが議長を務める、エン
ドエンド研究グループのメンバーの援助に感謝したいです。私は同じくこの
メモを組み立てることにおいて特に彼女のヘルプに対してDeborah Estrinに
感謝したいです。ドラフトについての洞察に富んだコメントのために同じく
Richard FoxとNoel ChiappaとTony Liに感謝します。
Security Considerations
セキュリティの考慮
Security issues are not discussed in this memo.
セキュリティ問題がこのメモで論じられません。
Author's Address
著者のアドレス
Craig Partridge
BBN Systems and Technologies
10 Moulton St.
Cambridge, MA 02138
EMail: craig@aland.bbn.com