RFC1809 日本語訳

Network Working Group                                       C. Partridge
Request for Comments: 1809                  BBN Systems and Technologies
Category: Informational                                        June 1995

コメントを求めるワーキンググループC.ヤマウズラ要求をネットワークでつないでください: 1809台のBBNシステムと技術カテゴリ: 情報の1995年6月

                   Using the Flow Label Field in IPv6

IPv6の流れラベルフィールドを使用します。

Status of this Memo

この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.

このメモの目的はFlow Labelsの取り扱いに関してEndから終わりへのResearch Groupのいろいろな意見と提案をIPv6のための1セットの提案に蒸留することです。 このメモは、情報目的だけのためにあって、IPv6仕様の1つではありません。 このメモの分配は無制限です。

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.

このメモは議論のレポートとして1994年11月のEndから終わりへのResearch Groupミーティングで由来しました。 そのミーティングでは、グループはどうIPv6の流れ識別子を管理するかに関するいくつかの問題について議論しました。 そして、ミーティングのレポートはIPv6共同体に循環しました。 その共同体からのフィードバックは、Groupが上げたEndから終わりをいくつかの小さな問題に固定するためにこのメモとIPv6仕様への変化で変化をもたらしました。

   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.

このメモによる考えの多くがIPv6仕様に届きましたが、様々なデザイン決定がされた理由に関する説明は届いているというわけではありませんでした。 このメモが何らかの追加文脈を利害関係者に提供することを意図します。

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).

IPv6仕様の現在の草稿は、すべてのIPv6ヘッダーが24ビットのFlow Labelを含むと述べます。 (元々、仕様は28ビットのFlow ID野原を求めました。(それは、流れラベルと4ビットの優先権分野を含んでいました)。 優先権分野は現在、このメモの端で議論した理由で異なっています。).

Partridge                    Informational                      [Page 1]

RFC 1809                                                       June 1995

[1ページ]RFC1809 1995年6月の情報のヤマウズラ

   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.

Flow Labelは1とFFFFFF(魔法をかける)の間のソースアドレスに結合されるとユニークな擬似乱数です。 Flow Labelが予約されているゼロは、Flow Labelが全く使用されていないと言います。 仕様は、Flow Labelの以前の使用のためのすべての州の情報がインターネットにおけるすべてのルータから洗い流されるまでソースがFlow Label値を再利用してはいけないのを必要とします。

   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.

仕様は、同じ(非ゼロ)流れLabelがあるすべてのデータグラムには同じDestination Address、ホップによるHop Optionsヘッダー、ルート設定Header、およびSource Addressコンテンツがなければならないのをさらに必要とします。 概念はテーブルで単にFlow Labelを見上げることによって、ルータがどのようにヘッダーの残りを調べないでデータグラムを発送して、進めるかを決めることができるということです。

Flow Label Issues

流れラベル問題

   The IPv6 specification originally left open a number of questions, of
   which these three were among the most important:

仕様が元々残したIPv6は多くの質問を開きます:(それに関するこれらの3は質問のための最も重要なものの1つでした)。

        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. (非ゼロ)流れLabelがあるデータグラムが届いて、ルータにそのFlow Labelのための状態が全くないなら、ルータは何をするべきですか?

        2.   How does an internet flush old Flow Labels?

2. インターネットはどのように古いFlow Labelsを洗い流しますか?

        3.   Which datagrams should carry (non-zero) Flow Labels?

3. どのデータグラムが(非ゼロ)流れLabelsを運ぶはずですか?

   This memo summarizes the End-to-End Group's attempts to answer these
   questions.

このメモはこれらの質問に答えるEndから終わりへのGroupの試みをまとめます。

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?

非ゼロFlow Labelがあるデータグラムがルータに届いて、ルータが、それにはそのFlow Labelのための州の情報が全くないと発見するなら、ルータがする正しいことは何ですか?

   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.

IPv6仕様は、Flow Labelsを無視するためにルータを許容して、また、IPv6データグラムが彼らのオプションにおける流れセットアップ情報を運ぶかもしれない可能性を考慮します。 また、ルータが状態を墜落して、失うなら、未知のFlow Labelsは起こるかもしれません。 回復の期間、ルータはそれが知らないFlow Labelsがあるデータグラムを受けるでしょうが、これは誤りではなく、論証上むしろ回復の期間の一部です。 別々のFlow LabelがそれぞれのTCP接続に割り当てられるという論議を呼んだ提案が採用されるなら、最終的に、LRUキャッシュを使用するFlow Labelsを管理するのが必要であるかもしれない(ルータにおけるFlow Labelキャッシュオーバーフローを避ける)、その場合、アクティブな、しかし、まれに使用された流れの状態は故意に捨てられたかもしれません。

Partridge                    Informational                      [Page 2]

RFC 1809                                                       June 1995

[2ページ]RFC1809 1995年6月の情報のヤマウズラ

   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.

どのような場合でも、それは、この状況を誤りとして扱いながらそれをクリアすることであり、データグラムを落としながら言って、ICMPメッセージを送って、不適当です。 本当に、多くの場合、1は進めるでしょう、したがって、単にデータグラムを進めて、流れに対するデータグラムを落とすより良いサービスがFlow Labelがないデータグラムは与えられそうでしょう。

   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).

もちろん、まるでFlow Labelがゼロであるかのようにデータグラムを発送すると間違った結果が引き起こされる状況があるでしょう。 例は低バンド幅の地球のリンクを通してデータグラムの目的地への2つの経路、高帯域衛星中継を通した1つ、およびもう片方を持っているルータです。 高帯域流動は高帯域リンクを通して明らかに発送されるべきですが、ルータが流れ状態を失うなら、ルータは低バンド幅リンクを通して交通を発送するかもしれません、流れの交通が低バンド幅リンクを浸す可能性で。 それはありそうに見えて、しかしながら、これらの状況は例外になるでしょう規則よりむしろ。 それで、流れ状態が欠けるなら、データグラムが特別な取り扱いを必要とするのを示すオプションを使用するこれらの状況を扱うのは妥当に思えます。 (流れの必要性によって、オプションはいくつかのルータで扱われるだけであるかもしれません。)

   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.

流れ州が、失われて、リフレッシュされる必要があるのは、エンドシステムに合図するための何らかの方法を持つのにおいて明確に望ましいでしょう。 1つの可能性は状態が無くなっているビットをFlow Label分野に加えることです、分野の貴重な24ビットに食い込むのに感度がどんなにそこにあっても。 他の可能性は、Flow Labelが未知であったのを示すためにデータグラムにオプションを加えるか、またはICMPメッセージを流れ源に送り返すのを含んでいます。

   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.

概要では、視点は省略時の解釈がルータが未知のFlow Labelと共にデータグラムを受けるなら、まるでFlow Labelがゼロであるかのようにデータグラムを扱うということであるべきであるということです。 推進の一部として、ルータは、ホップごとのどんなオプションも調べて、データグラムが特別な取り扱いを必要とするかどうか学ぶでしょう。 オプションは、単に、Flow Labelが未知であるならデータグラムが落とされることになっているという情報を含むことができたか、またはルータが持つべきである流れ状態を含むかもしれません。 明確に、余地が実験のためにオプションデザインと共にここにあります。

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.

流れメカニズムは、与えられたFlow Labelに関連している状態がどうにかルータに預けられるので彼らがFlow Labelを運ぶデータグラムを扱う方法を知っていると仮定します。 深刻な問題はルータからもう使用されていないFlow Labels(聞き古したFlow Labels)をどう洗い流すかということです。

   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

聞き古したFlow Labelsが起こることができる、私たちが、道ソースがいつもaを送ると思っても数がFlow Labelを削除しながら通信する、いつ

Partridge                    Informational                      [Page 3]

RFC 1809                                                       June 1995

[3ページ]RFC1809 1995年6月の情報のヤマウズラ

   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.

ソースは、Flowを使用し終えます。 流れが引き起こされたので、インターネットはpartionedされたかもしれません。 または、すべてのルータに達する前に、削除メッセージは失われるかもしれません。 その上、Flow Label削除メッセージを出すことができる前にソースはクラッシュするかもしれません。 私たちが聞き古したFlow Labelsを取り除くために、いつも、ソース(または、同じ理由による第三者)を期待できるというわけではないというポイントがここにあります。 むしろ、ルータは、Flow Labels自身を洗い流すために何らかのメカニズムを見つけなければならないでしょう。

   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.

明白なメカニズムはタイマを使用することです。 ルータは状態がいつかの期間以内にリフレッシュされていないFlow Labelsを捨てるべきです。 同時に、クラッシュする情報筋は静かな時間を観測しなければなりません、前世からのすべてのFlow Labelsが期限が切れたに違いないのを知るまで。(それは時間、流れを全く引き起こしません)。 (ソースはクラッシュを乗り切る安定貯蔵にアクティブなFlow Labelsの情報を保つことによって、落ち着いた時間制限を避けることができます。) これは正確にTCP初期シーケンス番号が管理されて、同じメカニズムが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).

Flow Labelとその状態がちょうどどうリフレッシュされるべきであるかが何らかの研究を必要とします。 2つの明白なオプションがあります。 ソースは定期的に明らかにFlow Labelとその状態をリフレッシュするメッセージ(RSVP Pathメッセージなどの)を特別番組がリフレッシュするアウトに送ることができました。 リフレッシュしてください。さもないと、ソースは明白な状態で発信できました。または、ルータがそれがFlow Labelを運ぶあらゆるデータグラムを扱うかもしれない、暗黙、オプションをリフレッシュしてください。 定期的の間には、選択が、各データグラム(すなわち、Flow Labelのエントリーでは、Flow Labelがリフレッシュされたことに注意する)で特別なアップデートメッセージを扱って、余分な計算をしながら、あります。

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.

基本合意の諸点がありました。 データの小さい交換にはFlow Labelが全くそうあるべきではありません、いくつかのデータグラムのために流れを引き起こす価値がないので。リアルタイムの流れにはFlow Labelが明らかにいつもなければなりません、流れがFlow Labelsが作成された第一の理由であるので。 問題は同輩が多量のベストエフォート型交通を送ってするべきこと(例えば、TCP接続)です。 何人かの人々が、すべての長期のTCP接続にFlow Labelsを使用して欲しく、他のものはそうしません。

   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

個々のTCP接続のときにFlow Labelsを使用することを支持して議論はネットワーク内の提供者のルータがTCPの接続の、より良いサービス(例えば、下側の遅れか、より大きい帯域幅)を与える特別なルートを証明するのに多量の交通を認識して、情報筋が特別なサービスを要求しないでも、Flow Label分野を使用できるかもしれないということです。 別の議論が受信機で効率的なdemuxを助けることである、(すなわち、IPとTCP demuxingはそうであるかもしれません。

Partridge                    Informational                      [Page 4]

RFC 1809                                                       June 1995

[4ページ]RFC1809 1995年6月の情報のヤマウズラ

   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.

個々のTCP接続にFlow Labelsを使用することに対する議論がどのようにを変えるかということである、私たち、ルータにおける経路キャッシュを扱います。 現在、1つはあて先ホストのためにルートをキャッシュできます、何人のさまざまな原因がそのあて先ホストに発信するかにかかわらず。 すなわち、5つのソースが2つのTCP接続にデータをサーバにそれぞれ送らせるなら、サーバにルートを含む1つのキャッシュエントリーがすべての10TCPsの交通を扱います。 各データグラムにFlow Labelsを入れると、キャッシュはFlow Labelキャッシュに変化します、どれがすべてのTCP接続のためのキャッシュエントリーがあるかで。 それで、キャッシュ爆発の可能性があります。 この問題を軽減する方法があります、LRUキャッシュとしてFlow Labelキャッシュを管理するのなどように。(そこでは、まれに使用されたFlow Labelsが捨てられるのと(次に、後で回復されています)であるのに得ます)。 しかしながら、これがキャッシュの打つことを引き起こすかどうかは、明確ではありません。

   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.

これらの位置の間には、安易な妥協が全くないのを観測してください。 例えば、1つで、アプリケーションは、Flow Labelを使用するかどうか決めることができません。 すべてのTCP接続単位で異なったFlow Labelsが欲しい人は、彼らがアプリケーションの知識なしでルートを最適化するかもしれないと仮定します。 そして、すべてのアプリケーションにFlow Labelsを使用させるので、ルーティング業者はやむを得ずキャッシュ爆発問題に対処するでしょう、私たちが、後で個々のTCP接続を最適化したいと思わないと発見しても。

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.

当初のIPv6仕様は、PriorityとFlow Label分野を結合して、流れがPriority分野の異価の手段を再定義するのを許容しました。 議論の間、Endから終わりへのグループは、これが、ルータが未知のFlow Labelがあるデータグラムを進めたならPriority分野を無視しなければならないことを意味したとわかりました、優先順位の値が再定義されたかもしれないので。 (例えば、プライオリティは逆にされたかもしれません。) IPv6共同体は、この振舞いが望ましくないと結論づけました。 本当に、より知識があるルーティング決定をするのはFlow Labelが未知であるときに、Priority分野を使用するとルータがはるかに良いサービスを与えることができそうなように思えます。 それで、現在、Priority分野は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.

Endから終わりへのボブ・ブレーデンによってまとめられた議論がこのメモを製作したResearch Groupのメンバーの支援を承諾したいと思います。 また、彼女のためのEstrinが、このメモを組み立てるのを手伝うのをデボラに特に感謝申し上げます。 また、草稿の洞察に満ちたコメントのためにリチャードフォックス、クリスマスChiappa、およびトニー・李をありがとうございます。

Partridge                    Informational                      [Page 5]

RFC 1809                                                       June 1995

[5ページ]RFC1809 1995年6月の情報のヤマウズラ

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

クレイグヤマウズラBBNシステムとケンブリッジ、技術10モールトン通りMA 02138

   EMail: craig@aland.bbn.com

メール: craig@aland.bbn.com

Partridge                    Informational                      [Page 6]

ヤマウズラ情報です。[6ページ]