RFC2991 日本語訳

Network Working Group                                           D. Thaler
Request for Comments: 2991                                      Microsoft
Category: Informational                                          C. Hopps
                                                     NextHop Technologies
                                                            November 2000

ターレルがコメントのために要求するワーキンググループD.をネットワークでつないでください: 2991年のマイクロソフトカテゴリ: 情報のC.ホップスNextHop技術2000年11月

      Multipath Issues in Unicast and Multicast Next-Hop Selection

ユニキャストにおける多重通路問題とマルチキャスト次のホップ選択

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   Various routing protocols, including Open Shortest Path First (OSPF)
   and Intermediate System to Intermediate System (ISIS), explicitly
   allow "Equal-Cost Multipath" (ECMP) routing.  Some router
   implementations also allow equal-cost multipath usage with RIP and
   other routing protocols.  The effect of multipath routing on a
   forwarder is that the forwarder potentially has several next-hops for
   any given destination and must use some method to choose which next-
   hop should be used for a given data packet.

オープンShortest Path First(OSPF)とIntermediate SystemをIntermediate System(イシス)に含む様々なルーティング・プロトコルが明らかに「等価コストマルチパス」(ECMP)ルーティングを許します。 また、いくつかのルータ実現がRIPがある用法と他のルーティング・プロトコルを等価コストマルチパスに許容します。 多重通路ルーティングの混載業者への効果は混載業者が潜在的にどんな与えられた目的地へのいくつかの次のホップも持って、どの次のホップが与えられたデータ・パケットに使用されるべきであるかを選ぶ何らかの方法を使用しなければならないということです。

1.  Introduction

1. 序論

   Various routing protocols, including OSPF and ISIS, explicitly allow
   "Equal-Cost Multipath" routing.  Some router implementations also
   allow equal-cost multipath usage with RIP and other routing
   protocols.  Using equal-cost multipath means that if multiple equal-
   cost routes to the same destination exist, they can be discovered and
   used to provide load balancing among redundant paths.

OSPFとイシスを含む様々なルーティング・プロトコルが明らかに「等価コストマルチパス」ルーティングを許します。 また、いくつかのルータ実現がRIPがある用法と他のルーティング・プロトコルを等価コストマルチパスに許容します。 等価コストマルチパスを使用するのは、同じ目的地への複数の等しい費用ルートが存在しているなら、ロードバランシングを冗長パスに提供するのにそれらを発見して、使用できることを意味します。

   The effect of multipath routing on a forwarder is that the forwarder
   potentially has several next-hops for any given destination and must
   use some method to choose which next-hop should be used for a given
   data packet.  This memo summarizes current practices, problems, and
   solutions.

多重通路ルーティングの混載業者への効果は混載業者が潜在的にどんな与えられた目的地へのいくつかの次のホップも持って、どの次のホップが与えられたデータ・パケットに使用されるべきであるかを選ぶ何らかの方法を使用しなければならないということです。 このメモは現在の実務、問題、および解決策をまとめます。

Thaler & Hopps               Informational                      [Page 1]

RFC 2991                    Multipath Issues               November 2000

情報[1ページ]のRFC2991多重通路が2000年11月に支給するターレルとホップス

2.  Concerns

2. 関心

   Several router implementations allow multipath forwarding.  This is
   sometimes done naively via round-robin, where each packet matching a
   given destination route is forwarded using the subsequent next-hop,
   in a round-robin fashion.  This does provide a form of load
   balancing, but there are several problems with approaches such as
   round-robin or random:

いくつかのルータ実現が多重通路推進を許します。 純真に連続でこれを時々します、その後の次のホップを使用することで与えられた目的地ルートに合っている各パケットを進めるところで、連続ファッションで。 これはロードバランシングのフォームを提供しますが、丸いコマドリか無作為であるようなアプローチに関するいくつかの問題があります:

   Variable Path MTU
         Since each of the redundant paths may have a different MTU,
         this means that the overall path MTU can change on a packet-
         by-packet basis, negating the usefulness of path MTU discovery.

それぞれ冗長パスの可変Path MTU Sinceには異なったMTUがあるかもしれません、総合的な経路MTUがパケットによるパケットベースで変えることができるこの手段、経路MTU探索の有用性を否定して。

   Variable Latencies
         Since each of the redundant paths may have a different latency
         involved, having packets take separate paths can cause packets
         to always arrive out of order, increasing delivery latency and
         buffering requirements.

それぞれ冗長パスの可変Latencies Sinceは異なった潜在をかかわらせるかもしれなくて、パケットに別々の経路を取らせるのは故障していた状態でパケットをいつも到着させることができます、配送潜在を高めて、要件をバッファリングして。

         Packet reordering causes TCP to believe that loss has taken
         place when packets with higher sequence numbers arrive before
         an earlier one.  When three or more packets are received before
         a "late" packet, TCP enters a mode called "fast-retransmit" [6]
         which consumes extra bandwidth (which could potentially cause
         more loss, decreasing throughput) as it attempts to
         unnecessarily retransmit the delayed packet(s).  Hence,
         reordering can be detrimental to network performance.

パケット再命令で、TCPは、より高い一連番号があるパケットが以前のものの前に到着するとき、損失が起こったと信じています。 「遅い」パケットの前に3つ以上のパケットを受け取るとき、TCPは不必要に遅れたパケットを再送するのを試みるとき余分な帯域幅(スループットを減少させて、潜在的により多くの損失をもたらすことができた)を消費するモードの呼ばれた「速く再送してください」[6]に入ります。 したがって、再命令はネットワーク性能に有害である場合があります。

   Debugging
         Common debugging utilities such as ping and traceroute are much
         less reliable in the presence of multiple paths and may even
         present completely wrong results.

ピングやトレースルートなどのデバッグCommonデバッグユーティリティは、複数の経路があるときはるかに信頼できないで、完全に間違った結果を提示さえするかもしれません。

   In multicast routing, the problem with multiple paths is that
   multicast routing protocols prevent loops and duplicates by
   constructing a single tree to all receivers of the same group
   address.  Multicast routing protocols deployed today (DVMRP, PIM-DM,
   PIM-SM) [2] construct shortest-path trees rooted at either the
   source, or another router known as a Core or Rendezvous Point.
   Hence, the way they ensure that duplicates will not arise is that a
   given tree must use only a single next-hop towards the root of the
   tree.

マルチキャストルーティングで、複数の経路に関する問題はマルチキャストルーティング・プロトコルが同じグループアドレスのすべての受信機に単一の木を組み立てることによって輪と写しを防ぐということです。 マルチキャストルーティング・プロトコルはCoreかRendezvous Pointとして知られているソースかルータのどちらかで別根づいている今日(DVMRP、PIM-DM、PIM-SM)の[2]構造物最短パス木を配備しました。 したがって、彼らが、写しが起こらないのを確実にする方法は与えられた木が木の根に向かって単一の次のホップだけを使用しなければならないということです。

Thaler & Hopps               Informational                      [Page 2]

RFC 2991                    Multipath Issues               November 2000

情報[2ページ]のRFC2991多重通路が2000年11月に支給するターレルとホップス

3.  Requirements

3. 要件

   In the remainder of this document, we will use the term "flow" to
   represent the granularity at which the router keeps state (if at all)
   for classes of traffic.  The exact definition of a flow may depend on
   the actual implementation.  For example, a flow might be identified
   solely by destination address, or it might be identified by (source
   address, destination address, protocol id) triplet.  Hence "flow" is
   not necessarily synonymous with the term "microflow" as used in RFC
   2474 [7], which also includes port numbers.  Indeed, including
   transport-layer information in the next-hop selection process can
   actually be problematic.  For example, if packets are fragmented, the
   transport-layer information may not be available in every packet.
   Furthermore, having the choice of path depend on transport-layer
   fields may negate the benefit of caching information such as MTU for
   use in subsequent connections between the same endpoints.

このドキュメントの残りでは、私たちは、ルータが交通のクラスのために、状態(せいぜい)を維持する粒状を表すのに「流れ」という用語を使用するつもりです。 流れの正確な定義は実際の実現によるかもしれません。 例えば、流れが唯一送付先アドレスによって特定されるかもしれませんか、またはそれは(ソースアドレス、送付先アドレスはイドについて議定書の中で述べます)三つ子によって特定されるかもしれません。 したがって、「流れ」は必ずRFC2474[7](また、ポートナンバーを含んでいる)で使用されるように"microflow"という用語と同義であるというわけではありません。 本当に、次のホップ選択の過程によるトランスポート層情報を含んでいるのは実際に問題が多い場合があります。 例えば、パケットが断片化されるなら、トランスポート層情報はあらゆるパケットで利用可能であるかもしれないというわけではありません。 その上、経路のこの選択がトランスポート層フィールド次第であることを持っているのが同じ終点の間のその後の接続における使用のためのMTUなどの情報をキャッシュする利益を否定するかもしれません。

   All of the problems outlined in the previous section arise when
   packets in the same unicast or multicast "flow" are split among
   multiple paths.  The natural solution is therefore to ensure that
   packets for the same flow always use the same path.

同じユニキャストかマルチキャスト「流れ」におけるパケットが複数の経路の中で分けられるとき、前項で概説された問題のすべてが起こります。 自然な解決策はしたがって、同じ流れのためのパケットがいつも同じ経路を使用するのを保証することです。

   Two additional features are desirable:

2つの付加的な機能が望ましいです:

   Minimal disruption
         When multipath is used, meaning that multiple routes contribute
         valid next-hops, the chances are higher of routes being added
         and deleted from consideration than when only the "best" route
         is used (in which case metric changes in alternate routes have
         no effect on traffic paths).  Since a higher number of routes
         may actually be used for forwarding when multipath is in use,
         the potential for packet reordering and packet loss due to
         route flaps can be much greater than when not using multipath.
         Hence, it is desirable to minimize the number of active flows
         affected by the addition or deletion of another next-hop.

最小量の分裂When多重通路は使用されています、複数のルートが有効な次のホップを寄付して、考慮から加えられて、削除されるルートで機会が「最も良い」ルートだけが使用されている(その場合、代替経路のメートル法の変化は交通経路で効き目がありません)時より高いことを意味して。 多重通路が使用中であるときに、より大きい数のルートが推進に実際に使用されるかもしれないので、パケット再命令の可能性とルートフラップによるパケット損失はいつよりはるかに多重通路を使用しないことで大きい場合があるか。 したがって、添加で影響を受けるアクティブな流れの数か別の次のホップの削除を最小にするのは望ましいです。

   Fast implementation
         The amount of additional computation required to forward a
         packet should be small.  For example, when doing round-robin,
         this computation might consist of incrementing (modulo the
         number of next-hops) a next-hop index.

追加計算の量がパケットを進めるのを必要とした速い実現は小さいはずです。 連続をするとき、例えば、この計算が増加から成るかもしれない、(法、次のホップの数) 次のホップインデックス。

4.  Solutions

4. ソリューション

   We now provide three possible methods for improving the performance
   of multipath and then discuss their applicability to unicast and
   multicast forwarding.

私たちは、現在、3つの可能な方法を多重通路の性能を向上させるのに提供して、次に、ユニキャストとマルチキャスト推進と彼らの適用性について議論します。

Thaler & Hopps               Informational                      [Page 3]

RFC 2991                    Multipath Issues               November 2000

情報[3ページ]のRFC2991多重通路が2000年11月に支給するターレルとホップス

   Modulo-N Hash
         To select a next-hop from the list of N next-hops, the router
         performs a modulo-N hash over the packet header fields that
         identify a flow.  This has the advantage of being fast, at the
         expense of (N-1)/N of all flows changing paths whenever a
         next-hop is added or removed.

法-N Hash ToはN次のホップのリストから次のホップを選択して、ルータは流れを特定するパケットヘッダーフィールドの上で法N細切れ肉料理を実行します。 これには、存在の利点が速くあります、次のホップを加えるか、または取り除くときはいつも、経路を変えるすべてのN(N-1)/流れを犠牲にして。

   Hash-Threshold
         The router first selects a key by performing a hash over the
         packet header fields that identify the flow.  The N next-hops
         have been assigned unique regions in the hash function's output
         space.  By comparing the hash value against region boundaries
         the router can determine which region the hash value belongs to
         and thus which next-hop to use.  This method has the advantage
         of only affecting flows near the region boundaries (or
         thresholds) when next-hops are added or removed.  For ECMP
         hash-threshold's lookup can be done with a simple division
         (hash_value / fixed_region_size).  When a next-hop is added or
         removed, between 1/4 and 1/2 of all flows change paths.  An
         analysis of this method can be found in [3].

ルータが最初に流れを特定するパケットヘッダーフィールドの上で細切れ肉料理を実行しながらキーを選択する細切れ肉料理敷居。 ハッシュ関数の出力スペースでN次のホップにユニークな領域を割り当ててあります。 領域境界に対してハッシュ値をたとえることによって、ルータは、ハッシュ値がどの領域に属すか、そして、その結果、どの次のホップを使用したらよいかを決定できます。 この方法には、次のホップを加えるか、または取り除くとき領域境界(または、敷居)の近くで流れに影響するだけの利点があります。 ECMPに関しては、簡単な分割と共に細切れ肉料理敷居のルックアップができます(細切れ肉料理_値/固定された_領域_サイズ)。 次のホップを加えるか、または取り除くとき、1/4〜すべての1/2回の流れが、経路を変えます。 [3]でこの方法の分析を見つけることができます。

   Highest Random Weight (HRW)
         The router computes a key for EACH next-hop by performing a
         hash over the packet header fields that identify the flow, as
         well as over the address of the next-hop.  The router then
         chooses the next-hop with the highest resulting key value [4].
         This has the advantage of minimizing the number of flows
         affected by a next-hop addition or deletion (only 1/N of them),
         but is approximately N times as expensive as a modulo-N hash.

最も高いRandom Weight、(HRW) ルータは流れを特定するパケットヘッダーフィールドの上と、そして、次のホップのアドレスの上で細切れ肉料理を実行するのによる次のホップのEACHのためにキーを計算します。 そして、ルータは最も高い結果として起こるキー値[4]がある次のホップを選びます。 これは、次のホップ添加か削除(それらの1/Nだけ)で流れの数を最小にする利点を影響を受けさせますが、法N細切れ肉料理のおよそN倍高価です。

   The applicability of these three alternatives depends on (at least)
   two factors: whether the forwarder maintains per-flow state, and how
   precious CPU is to a multipath forwarder.

これらの3つの選択肢の適用性を(少なくとも)の2つの要素に依存します: 混載業者は1流れあたりの状態を維持するかどうか、そして、多重通路混載業者にとって、CPUは何と貴重であるのでしょう!

   Some routers may maintain per-flow state for reasons other than for
   supporting multipath.  For example, routers typically keep per-flow
   state for multicast flows so that they can maintain the list of
   interfaces to which packets in the flow should be copied.

いくつかのルータがサポート多重通路以外の理由で1流れあたりの状態を維持するかもしれません。 例えば、彼らが流れにおけるパケットがコピーされるべきであるインタフェースのリストを維持できて、ルータはマルチキャスト流れのために1流れあたりの状態を通常維持します。

   If per-flow state is maintained in a multipath forwarder, then
   computation of the next-hop can be done by the router at state
   creation time.  This entails no additional computations at packet
   forwarding time compared with normal forwarding to a single next-hop,
   since the next-hop is precomputed.  In this case, any method can be
   used, including round-robin, random, modulo-N, hash-threshold or HRW.
   Hash functions such as modulo-N, hash-threshold and HRW are better if
   the forwarder state may be deleted for any reason during the lifetime
   of a flow since subsequent next-hop computations by the router will

多重通路混載業者で1流れあたりの状態を維持するなら、ルータは州の創造時間に次のホップの計算ができます。 これはパケット推進時間に単一の次のホップへの通常の推進と比べてどんな追加計算も伴いません、次のホップが前計算されるので。 この場合、丸いコマドリの、そして、無作為の法-N、細切れ肉料理敷居またはHRWを含んでいて、どんな方法も使用できます。 混載業者状態がどんな理由でも流れの生涯削除されるかもしれないなら、ルータによるその後の次のホップ計算が良くなるので、法-Nや、細切れ肉料理敷居やHRWなどのハッシュ関数は、より良いです。

Thaler & Hopps               Informational                      [Page 4]

RFC 2991                    Multipath Issues               November 2000

情報[4ページ]のRFC2991多重通路が2000年11月に支給するターレルとホップス

   always select the same path.  This also improves the usefulness of
   debugging utilities such as traceroute.  Finally, to maximize the
   stability of paths (and hence the usefulness of traceroute, etc.),
   the use of HRW is recommended over the other methods mentioned
   herein.

いつも同じ経路を選択してください。 また、これはトレースルートなどのデバッグユーティリティの有用性を改良します。 最終的に、経路(そして、したがって、トレースルートなどの有用性)の安定性を最大にするために、HRWの使用はここに言及された他の方法の上でお勧めです。

   If per-flow state is not maintained by the forwarder, then using
   multiple next-hops requires that the next-hop be calculated at packet
   arrival time.  When CPU is more precious than stability of flow
   paths, hash-threshold is recommended over the other methods mentioned
   herein.

1流れあたりの状態が混載業者によって維持されないなら、複数の次のホップを使用するのは、次のホップがパケット到着時間に計算されるのを必要とします。 CPUが流路の安定性より貴重であるときに、細切れ肉料理敷居はここに言及された他の方法の上でお勧めです。

4.1.  Unicast Forwarding

4.1. ユニキャスト推進

   Depending on the implementation, unicast forwarding may or may not
   keep per-flow state.  We recommend that where forwarder
   implementations keep flow state, routers should use HRW at state
   creation time (and next-hop deletion time) to select the next-hop,
   and that forwarders without per-flow state use hash-threshold.

実現によって、ユニキャスト推進は、流れが状態であることを保つかもしれません。 私たちは、混載業者実現が流れ状態を維持するところでルータが次のホップを選択する州の創造時間(そして、次のホップ削除時間)にHRWを使用するべきであり、1流れあたりの状態のない混載業者が細切れ肉料理敷居を使用することを勧めます。

4.2.  Multicast Forwarding

4.2. マルチキャスト推進

   Today's multicast forwarding engines use a cache of forwarding
   entries indexed by group (or group prefix) and source (or source
   prefix).  This means that today's multicast forwarder's always keep
   per-flow state, although for some multicast routing protocols, the
   "flow" may be fairly coarse (e.g., traffic from all sources to the
   same destination).  Since per-flow state is kept by the forwarder, it
   is recommended that the router always use HRW to select the next-hop.

今日のマルチキャスト推進エンジンはグループ(または、グループ接頭語)とソース(または、ソース接頭語)によって索引をつけられた推進エントリーのキャッシュを使用します。 これは、今日のマルチキャスト混載業者のものがいつも1流れあたりの状態を維持することを意味します、いくつかのマルチキャストルーティング・プロトコルには、「流れ」はかなり粗いかもしれませんが(例えば、すべてのソースから同じ目的地までの交通)。 1流れあたりの状態が混載業者によって維持されるので、ルータが次のホップを選択するのにいつもHRWを使用するのは、お勧めです。

   Routers using explicit-joining protocols such as PIM-SM [5] should
   thus use the multipath information when determining to which neighbor
   a join message should be sent.  For example, when multiple next-hops
   exist for a given Rendezvous Point (RP) toward which a (*,G) Join
   should be sent, it is recommended that HRW be used to select the
   next-hop to use for each group.

その結果、PIM-SM[5]などの明白な接合プロトコルを使用するルータはいつどの隣人aが接合するかとメッセージを決定するのを送るべきであるかという多重通路情報を使用するべきです。 複数の次のホップが当然のことのRendezvous Point(RP)のために向かって存在するとき、例えば、どのa(*、G)を接合させるべきであるか、そして、次のホップが各グループに使用するのを選択するのにおいてHRWが使用されているのは、お勧めです。

5.  Applicability

5. 適用性

   The algorithms discussed above (except round-robin) all rely on some
   form of hash function.  Equal flow distribution is achieved when the
   hash function is uniformly distributed.  Since the commonly used hash
   functions only become uniformly distributed when the number of inputs
   is relatively large, these algorithms are more applicable to routers
   used to route many flows, than in, for example, a small business
   setting.

上(連続を除いて)で議論したアルゴリズムはすべて、何らかのフォームのハッシュ関数を当てにします。 ハッシュ関数が一様に分配されるとき、等しい流れ分配は達成されます。 一般的に使用されたハッシュ関数が入力点数が比較的大きいときに、一様に分配されるようになるだけであるので、これらのアルゴリズムは例えば、中小企業設定より多くの流れを発送するのに使用されるルータに適切です、。

Thaler & Hopps               Informational                      [Page 5]

RFC 2991                    Multipath Issues               November 2000

情報[5ページ]のRFC2991多重通路が2000年11月に支給するターレルとホップス

6.  Redundant Parallel Links

6. 余分な平行なリンク

   A related problem occurs when multiple parallel links are used
   between the same pair of routers.  A common solution is to bundle the
   two links together into a "super"-link when is then used for routing.
   For multicast forwarding, this results in the two links being reduced
   to a single next-hop (over the combined link) which can be used to
   prevent duplicates.  When a unicast or multicast packet is queued to
   the combined link, some method, such as those discussed earlier, is
   still required to determine the physical link on which to transmit
   the packet.  If the parallel links are identical, then most of the
   concerns discussed in this document are avoided with the combined
   link.  The exception is packet reordering, which can still occur with
   round-robin, adversely affecting TCP.

複数の平行なリンクが同じ組のルータの間で使用されるとき、関連する問題は起こります。 一般的な解決策は発送するのにおいて、次にいつが使用されている「最高」のリンクに2個のリンクを一緒に投げ込むことです。 マルチキャスト推進のために、これは写しを防ぐのに使用できる単一の次のホップ(結合したリンクの上の)に減少する2個のリンクをもたらします。 ユニキャストかマルチキャストパケットが結合したリンクまで列に並ばせられるとき、より早く議論したものなどのように、何らかの方法が、パケットを伝える物理的なリンクを決定するのにまだ必要です。 平行なリンクが同じであるなら、本書では議論した関心の大部分は結合したリンクで避けられます。 例外はパケット再命令です。(その再命令は丸いコマドリの、そして、悪影響を与えているTCPと共にまだ起こることができます)。

7.  Security Considerations

7. セキュリティ問題

   This document discusses issues with various methods of choosing a
   next-hop from among multiple valid next-hops.  As such, it does not
   directly impact the security of the Internet infrastructure or its
   applications.

このドキュメントは複数の有効な次のホップから次のホップを選ぶ様々な方法の問題について議論します。 そういうものとして、それは直接インターネット基盤かそのアプリケーションのセキュリティに影響を与えません。

   One issue that is worth mentioning, however, is that when next-hop
   selection is predictable, an attacker can synthesize traffic that
   will all hash the same, making it possible to launch a denial-of-
   service attack that overloads a particular path.  Since a special
   case of this is when the same (single) next-hop is always selected,
   such an attack is easiest when multipath is not being used.
   Introducing multipath routing can make such an attack more difficult;
   the more unpredictable the hash is, the harder it becomes to conduct
   a denial-of-service attack against any single link.

しかしながら、言及する価値がある1冊は次のホップ選択が予測できるとき、攻撃者が同じくらいすべて論じ尽くす交通を統合できるということです、-サービス攻撃では、それが特定の経路を積みすぎるという否定に着手するのを可能にして。 この特別なケースが同じ(単一)の次のホップがいつも選択される時であるときに、多重通路が使用されていないとき、そのような攻撃は最も簡単です。 多重通路ルーティングを導入するのに、そのような攻撃は、より難しくなる場合があります。 細切れ肉料理が予測できなければ予測できないほど、それは、どんな単一のリンクに対してサービス不能攻撃を行うために、より困難になります。

Thaler & Hopps               Informational                      [Page 6]

RFC 2991                    Multipath Issues               November 2000

情報[6ページ]のRFC2991多重通路が2000年11月に支給するターレルとホップス

8.  References

8. 参照

   [1]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[1]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。

   [2]  Maufer, T., "Deploying IP Multicast in the Enterprise",
        Prentice-Hall, 1998.

[2] T. Maufer、「エンタープライズでIPマルチキャストを配備すること」での新米のホール、1998。

   [3]  Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC
        2992, November 2000.

[3] ホップス、C.、「等しい費用マルチ経路アルゴリズムの分析」、RFC2992、2000年11月。

   [4]  Thaler, D., and C.V. Ravishankar, "Using Name-Based Mappings to
        Increase Hit Rates", IEEE/ACM Transactions on Networking,
        February 1998.

[4] ターレル、D.、およびC.V.Ravishankar、「ヒット率を増加させるのに名前ベースのマッピングを使用します」、ネットワークのIEEE/ACM取引、1998年2月。

   [5]  Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
        Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei,
        "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
        Specification", RFC 2362, June 1998.

[5] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターレル、D.、デアリング、S.、ハンドレー、M.、ジェーコブソン、V.、リュウ、C.、シャルマ、P.、およびL.ウェイ、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、1998年6月。

   [6]  Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control",
        RFC 2581, April 1999.

[6] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。

   [7]  Nichols, K., Blake, S., Baker, F. and D. Black., "Definition of
        the Differentiated Services Field (DS Field) in the IPv4 and
        IPv6 Headers", RFC 2474, December 1998.

[7] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.が黒くされる、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)

Thaler & Hopps               Informational                      [Page 7]

RFC 2991                    Multipath Issues               November 2000

情報[7ページ]のRFC2991多重通路が2000年11月に支給するターレルとホップス

9.  Authors' Addresses

9. 作者のアドレス

   Dave Thaler
   Microsoft
   One Microsoft Way
   Redmond, WA  98052

デーヴターレルマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98052

   Phone: +1 425 703 8835
   EMail: dthaler@dthaler.microsoft.com

以下に電話をしてください。 +1 8835年の425 703メール: dthaler@dthaler.microsoft.com

   Christian E. Hopps
   NextHop Technologies, Inc.
   517 W. William Street
   Ann Arbor, MI 48103-4943
   U.S.A

クリスチャンのE.のNextHop技術Inc.517w.ウィリアム・通りホップスアナーバー、MI48103-4943U.S.A

   Phone: +1 734 936 0291
   EMail: chopps@nexthop.com

以下に電話をしてください。 +1 0291年の734 936メール: chopps@nexthop.com

Thaler & Hopps               Informational                      [Page 8]

RFC 2991                    Multipath Issues               November 2000

情報[8ページ]のRFC2991多重通路が2000年11月に支給するターレルとホップス

10.  Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Thaler & Hopps               Informational                      [Page 9]

ターレルでホップスInformationalです。[9ページ]