RFC4928 日本語訳
4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks. G.Swallow, S. Bryant, L. Andersson. June 2007. (Format: TXT=18376 bytes) (Also BCP0128) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Swallow Request for Comments: 4928 S. Bryant BCP: 128 Cisco Systems, Inc. Category: Best Current Practice L. Andersson Acreo AB June 2007
コメントを求めるワーキンググループG.ツバメ要求をネットワークでつないでください: 4928秒間ブライアントBCP: 128シスコシステムズInc.カテゴリ: 最も良い現在の練習L.アンデションAcreo AB2007年6月
Avoiding Equal Cost Multipath Treatment in MPLS Networks
MPLSネットワークで等しい費用多重通路処理を避けます。
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose.
このドキュメントは現在配備されたMPLSネットワークのEqual Cost Multipath(ECMP)の振舞いについて説明します。 このドキュメントは複数の異なった等しい費用経路にわたって同じ流れから異なったパケットのトランスミッションから生じることができる再命令を避けたがっているMPLSネットワークをひくためにアプリケーションを定義するだれのためにも最も良い習慣推薦状をします。 これらの推薦はパケットでのIPバージョンナンバーフィールドの点検に依存します。 推薦の発見的な本質にもかかわらず、MPLSネットワークを経営する比較的安全な方法を提供します、何らかの目的のためにIPバージョン番号の今後の配分をしたとしても。
Table of Contents
目次
1. Introduction ....................................................2 1.1. Terminology ................................................2 2. Current ECMP Practices ..........................................2 3. Recommendations for Avoiding ECMP Treatment .....................4 4. Security Considerations .........................................5 5. IANA Considerations .............................................5 6. References ......................................................6 6.1. Normative References .......................................6 6.2. Informative References .....................................6
1. 序論…2 1.1. 用語…2 2. 現在のECMPは練習します…2 3. ECMP処理を避けるための推薦…4 4. セキュリティ問題…5 5. IANA問題…5 6. 参照…6 6.1. 標準の参照…6 6.2. 有益な参照…6
Swallow, et al. Best Current Practice [Page 1] RFC 4928 Avoiding ECMP Treatment in MPLS Networks June 2007
ツバメ、他 2007年6月にMPLSネットワークでECMP処理を避ける最も良い現在の習慣[1ページ]RFC4928
1. Introduction
1. 序論
This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. We discuss cases where multiple packets from the same top-level LSP might be transmitted over different equal cost paths, resulting in possible mis-ordering of packets that are part of the same top-level LSP. This document also makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the resulting potential for mis-ordered packets. While disabling ECMP behavior is an option open to most operators, few (if any) have chosen to do so, and the application designer does not have control over the behavior of the networks that the application may run over. Thus, ECMP behavior is a reality that must be reckoned with.
このドキュメントは現在配備されたMPLSネットワークのEqual Cost Multipath(ECMP)の振舞いについて説明します。 私たちは同じトップレベルLSPからの複数のパケットが異なった等しい費用経路の上に送られるかもしれないケースについて議論します、同じトップレベルLSPの一部であるパケットの可能な誤注文をもたらして。 また、このドキュメントは誤命令されたパケットの結果として起こる可能性を避けたがっているMPLSネットワークをひくためにアプリケーションを定義するだれのためにも最も良い習慣推薦状をします。 ECMPの振舞いを無効にするのは、ほとんどのオペレータにとって、開いているオプションですが、わずか(もしあれば)しか、そうするのを選んでいません、そして、アプリケーション設計者はアプリケーションがひくかもしれないネットワークの振舞いを管理しません。その結果、ECMPの振舞いは計算しなければならない現実のものです。
1.1. Terminology
1.1. 用語
ECMP Equal Cost Multipath
ECMPの等しい費用多重通路
FEC Forwarding Equivalence Class
FEC推進同値類
IP ECMP A forwarding behavior in which the selection of the next-hop between equal cost routes is based on the header(s) of an IP packet
等しい費用ルートの間の次のホップの選択がIPパケットのヘッダーに基づいているIP ECMP A推進の振舞い
Label ECMP A forwarding behavior in which the selection of the next-hop between equal cost routes is based on the label stack of an MPLS packet
等しい費用ルートの間の次のホップの選択がMPLSパケットのラベルスタックに基づいているラベルECMP A推進の振舞い
LSP Label Switched Path
LSPラベルは経路を切り換えました。
LSR Label Switching Router
LSRラベル切り換えルータ
2. Current ECMP Practices
2. 現在のECMP習慣
The MPLS label stack and Forwarding Equivalence Classes are defined in [RFC3031]. The MPLS label stack does not carry a Protocol Identifier. Instead the payload of an MPLS packet is identified by the Forwarding Equivalence Class (FEC) of the bottom most label. Thus, it is not possible to know the payload type if one does not know the label binding for the bottom most label. Since an LSR, which is processing a label stack, need only know the binding for the label(s) it must process, it is very often the case that LSRs along an LSP are unable to determine the payload type of the carried contents.
MPLSラベルスタックとForwarding Equivalence Classesは[RFC3031]で定義されます。 MPLSラベルスタックはプロトコルIdentifierを運びません。 代わりに、MPLSパケットのペイロードは大部分がラベルする下部のForwarding Equivalence Class(FEC)によって特定されます。 したがって、人が大部分がラベルする下部で固まるラベルを知らないなら、ペイロードタイプを知るのは可能ではありません。 LSR(ラベルスタックを処理している)がそれが処理しなければならないラベルのための結合を知るだけでよいので、頻繁に、LSPに沿ってLSRsであることができないこの件が運ばれたコンテンツのペイロードタイプを決定するということです。
As a means of potentially reducing delay and congestion, IP networks have taken advantage of multiple paths through a network by splitting
潜在的に遅れと混雑を抑える手段として、IPネットワークは、ネットワークを通して分かれることによって、複数の経路を利用しました。
Swallow, et al. Best Current Practice [Page 2] RFC 4928 Avoiding ECMP Treatment in MPLS Networks June 2007
ツバメ、他 2007年6月にMPLSネットワークでECMP処理を避ける最も良い現在の習慣[2ページ]RFC4928
traffic flows across those paths. The general name for this practice is Equal Cost Multipath or ECMP. In general, this is done by hashing on various fields on the IP or contained headers. In practice, within a network core, the hashing is based mainly or exclusively on the IP source and destination addresses. The reason for splitting aggregated flows in this manner is to minimize the re-ordering of packets belonging to individual flows contained within the aggregated flow. Within this document, we use the term IP ECMP for this type of forwarding algorithm.
交通はそれらの経路の向こう側に流れます。 この習慣のための一般名は、Equal Cost MultipathかECMPです。 一般に、IPの多岐の論じ尽くすか含まれたヘッダーがこれを完了しています。 実際には、ネットワークコアの中では、論じ尽くすことは主にか排他的にIPソースと送付先アドレスに基づいています。 理由は分かれることが流れに集められたのでこの様に集められた流れの中に含まれた個々の流れに属すパケットの再注文を最小にすることです。 このドキュメントの中では、私たちはこのタイプの推進アルゴリズムにIP ECMPという用語を使用します。
For packets that contain both a label stack and an encapsulated IPv4 (or IPv6) packet, current implementations in some cases may hash on any combination of labels and IPv4 (or IPv6) source and destination addresses.
いくつかの場合、ラベルスタックと要約のIPv4(または、IPv6)パケットの両方を含むパケットに関しては、現在の実現はラベルとIPv4のどんな組み合わせのときにも(または、IPv6)のソースと送付先アドレスを論じ尽くすかもしれません。
In the early days of MPLS, the payload was almost exclusively IP. Even today the overwhelming majority of carried traffic remains IP. Providers of MPLS equipment sought to continue this IP ECMP behavior. As shown above, it is not possible to know whether the payload of an MPLS packet is IP at every place where IP ECMP needs to be performed. Thus vendors have taken the liberty of guessing the payload. By inspecting the first nibble beyond the label stack, existing equipment infers that a packet is not IPv4 or IPv6 if the value of the nibble (where the IP version number would be found) is not 0x4 or 0x6 respectively. Most deployed LSRs will treat a packet whose first nibble is equal to 0x4 as if the payload were IPv4 for purposes of IP ECMP.
MPLSの初期では、ペイロードは専らそうでした。IP。 今日さえ、運ばれた交通の圧倒的多数はIPのままで残っています。 MPLS設備のプロバイダーはこのIP ECMPの振舞いを続けようとしました。 上に示されるように、MPLSパケットのペイロードがIP ECMPが実行される必要があるあらゆる場所のIPであるかどうかを知るのは可能ではありません。 したがって、業者は失礼をも顧みずペイロードを推測しました。 ラベルスタックを超えて最初の少量を点検することによって、既存の設備は、パケットが少量(IPバージョン番号が見つけられるところ)の値がそれぞれ0×4でなくて、また0×6でもないならIPv4でなくて、またIPv6でもないと推論します。 ほとんどの配備されたLSRsが最初の少量がまるでペイロードがIP ECMPの目的のためのIPv4であるかのように0×4と等しいパケットを扱うでしょう。
A consequence of this is that any application that defines an FEC that does not take measures to prevent the values 0x4 and 0x6 from occurring in the first nibble of the payload may be subject to IP ECMP and thus having their flows take multiple paths and arriving with considerable jitter and possibly out of order. While none of this is in violation of the basic service offering of IP, it is detrimental to the performance of various classes of applications. It also complicates the measurement, monitoring, and tracing of those flows.
この結果は値0×4と0x6がペイロードの最初の少量で起こるのを防ぐ対策を実施しないFECを定義するどんなアプリケーションもIP ECMPと、その結果、それらの流れに複数の経路を取らせて、かなりのジターと共に到着することを条件としてことによると不適切であるかもしれないということです。 このなにもIPの基本サービス提供を違反していませんが、それは様々なクラスのアプリケーションの性能に有害です。 また、それはそれらの流れを測定、モニター、およびたどることを複雑にします。
New MPLS payload types are emerging, such as those specified by the IETF PWE3 and AVT working groups. These payloads are not IP and, if specified without constraint, might be mistaken for IP.
新しいMPLSペイロードタイプはIETF PWE3とAVTワーキンググループによって指定されたものなどのように現れています。 これらのペイロードは、IPでなく、規制なしで指定されるなら、IPに間違えられるかもしれません。
It must also be noted that LSRs that correctly identify a payload as not being IP most often will load-share traffic across multiple equal-cost paths based on the label stack. Any reserved label, no matter where it is located in the stack, may be included in the computation for load balancing. Modification of the label stack between packets of a single flow could result in re-ordering that
また、たいてい、IPでないとして正しくペイロードを特定するLSRsはラベルスタックに基づく複数の等しい費用経路中の負荷シェア交通がそうすることに注意しなければなりません。 それがスタックにどこに位置していても、どんな予約されたラベルもロードバランシングのための計算に含まれるかもしれません。 ただ一つの流れのパケットの間のラベルスタックの変更はそれを再命令するのに結果として生じることができました。
Swallow, et al. Best Current Practice [Page 3] RFC 4928 Avoiding ECMP Treatment in MPLS Networks June 2007
ツバメ、他 2007年6月にMPLSネットワークでECMP処理を避ける最も良い現在の習慣[3ページ]RFC4928
flow. That is, were an explicit null or a router-alert label to be added to a packet, that packet could take a different path through the network.
流れてください。 すなわち、明白なヌルかルータ警告しているラベルがパケットに加えられることになっているなら、そのパケットはネットワークを通して異なった経路を取るかもしれないでしょうに。
Note that for some applications, being mistaken for IPv4 may not be detrimental. The trivial case being where the payload behind the top label is a packet belonging to an MPLS IPv4 VPN. Here the real payload is IP and most (if not all) deployed equipment will locate the end of the label stack and correctly perform IP ECMP.
いくつかのアプリケーションには、IPv4に間違えられるのが有害でないかもしれないことに注意してください。 些細なケースはトップラベルの後ろのペイロードがMPLS IPv4 VPNに属すパケットであるところのそうです。 本当のペイロードがここの、IPであり、最も配備された(すべて)設備は、ラベルスタックの端の場所を見つけて、正しくIP ECMPを実行するでしょう。
A less obvious case is when the packets of a given flow happen to have constant values in the fields upon which IP ECMP would be performed. For example, if an Ethernet frame immediately follows the label and the LSR does ECMP on IPv4, but does not do ECMP on IPv6, then either the first nibble will be 0x4, or it will be something else. If the nibble is not 0x4 then no IP ECMP is performed, but Label ECMP may be performed. If it is 0x4, then the constant values of the MAC addresses overlay the fields that would have been occupied by the source and destination addresses of an IP header. In this case, the input to the ECMP algorithm would be a constant value and thus the algorithm would always return the same result.
それほど明白でないケースは与えられた流れのパケットがIP ECMPが実行される分野にたまたま恒常価値を持っている時です。 それは例えば、イーサネットフレームがすぐに、ラベルに続いて、LSRがIPv4でECMPをしますが、IPv6でECMPはしないなら、最初の少量が0×4になるだろうか、他の何かになるでしょう。 少量が0×4でないなら、IP ECMPは全く実行されませんが、Label ECMPは実行されるかもしれません。 それが0×4であるなら、MACアドレスの恒常価値はIPヘッダーのソースと送付先アドレスによって占領された分野をかぶせました。 この場合、ECMPアルゴリズムへの入力は恒常価値でしょう、そして、その結果、アルゴリズムはいつも同じ結果を返すでしょう。
3. Recommendations for Avoiding ECMP Treatment
3. ECMP処理を避けるための推薦
We will use the term "Application Label" to refer to a label that has been allocated with an FEC Type that is defined (or simply used) by an application. Such labels necessarily appear at the bottom of the label stack, that is, below labels associated with transporting the packet across an MPLS network. The FEC Type of the Application label defines the payload that follows. Anyone defining an application to be transported over MPLS is free to define new FEC Types and the format of the payload that will be carried.
私たちは、アプリケーションで定義される(または、単に使用されます)FEC Typeと共に割り当てられたラベルについて言及するのに「アプリケーションラベル」という用語を使用するつもりです。 そのようなラベルは必ずラベルスタックの下部に現れます、すなわち、MPLSネットワークの向こう側にパケットを輸送すると関連しているラベルの下で。 ApplicationラベルのFEC Typeは続くペイロードを定義します。 MPLSの上で輸送されるためにアプリケーションを定義するだれでも自由に運ばれるペイロードの新しいFEC Typesと書式を定義できます。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | Exp |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | Exp |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application Label | Exp |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1st Nbl| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| Exp|0| TTL| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| Exp|0| TTL| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アプリケーションラベル| Exp|1| TTL| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |最初のNbl| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Swallow, et al. Best Current Practice [Page 4] RFC 4928 Avoiding ECMP Treatment in MPLS Networks June 2007
ツバメ、他 2007年6月にMPLSネットワークでECMP処理を避ける最も良い現在の習慣[4ページ]RFC4928
In order to avoid IP ECMP treatment, it is necessary that an application take precautions to not be mistaken as IP by deployed equipment that snoops on the presumed location of the IP Version field. Thus, at a minimum, the chosen format must disallow the values 0x4 and 0x6 in the first nibble of their payload.
IP ECMP処理を避けるために、IPとしてIPバージョン分野の推定された位置で詮索される配備された設備によって間違われないようにアプリケーションの予防策を講されるのが必要です。 したがって、最小限で、選ばれた形式はそれらのペイロードの最初の少量で値0×4と0x6を禁じなければなりません。
It is REQUIRED, however, that applications depend upon in-order packet delivery restrict the first nibble values to 0x0 and 0x1. This will ensure that their traffic flows will not be affected if some future routing equipment does similar snooping on some future version(s) of IP.
それがREQUIREDである、しかしながら、アプリケーションがオーダーにおけるパケット配信によるのが最初の少量値を0×0と0×1に制限します。 これは、何らかの将来のルーティング設備がIPの何らかの将来のバージョンでの同様の詮索をするとそれらの交通の流れが影響を受けないのを確実にするでしょう。
This behavior implies that if in the future an IP version is defined with a version number of 0x0 or 0x1, then equipment complying with this BCP would be unable to look past one or more MPLS headers, and loadsplit traffic from a single LSP across multiple paths based on a hash of specific fields in the IPv0 or IPv1 headers. That is, IP traffic employing these version numbers would be safe from disturbances caused by inappropriate loadsplitting, but would also not be able to get the performance benefits.
この振舞いは、IPバージョンが将来0×0か0×1のバージョン番号で定義されるならこのBCPに従う設備が1個以上のMPLSヘッダーの先で見ることができないで、複数の経路中の独身のLSPからのloadsplit交通がヘッダーをIPv0かIPv1の特定の分野の細切れ肉料理に基礎づけたのを含意します。 すなわち、これらのバージョン番号を使うIP交通は、不適当なloadsplittingで引き起こされた騒動によって安全でしょうが、また、性能利益を得ることができないでしょう。
For an example of how ECMP is avoided in Pseudowires, see [RFC4385].
ECMPがPseudowiresでどう避けられるかに関する例に関しては、[RFC4385]を見てください。
4. Security Considerations
4. セキュリティ問題
This memo discusses the conditions under which MPLS traffic associated with a single top-level LSP either does or does not have the possibility of being split between multiple paths, implying the possibility of mis-ordering between packets belonging to the same top-level LSP. From a security point of view, the worse that could result from a security breach of the mechanisms described here would be mis-ordering of packets, and possible corresponding loss of throughput (for example, TCP connections may in some cases reduce the window size in response to mis-ordered packets). However, in order to create even this limited result, an attacker would need to either change the configuration or implementation of a router, or change the bits on the wire as transmitted in a packet.
このメモには、MPLS交通がどちらかがする独身のトップレベルLSPと交際した状態について議論するか、または複数の経路の間で分けられる可能性がありません、誤注文している同じトップレベルに属すパケットの間でLSPの可能性を含意して。 セキュリティ観点から、より悪いのは、ここで説明されたメカニズムの機密保護違反から生じることができたパケットの誤注文と、スループットの可能な対応する損失(例えば、いくつかの場合、TCP接続は誤命令されたパケットに対応してウィンドウサイズを減少させるかもしれない)でしょう。 しかしながら、この限られた結果さえ作成するために、攻撃者は、パケットで伝えられるようにルータの構成か実現を変えるか、またはワイヤのビットを変える必要があるでしょう。
Other security issues in the deployment of MPLS are outside the scope of this document, but are discussed in other MPLS specifications, such as [RFC3031], [RFC3036], [RFC3107], [RFC3209], [RFC3478], [RFC3479], [RFC4206], [RFC4220], [RFC4221], [RFC4378], AND [RFC4379].
MPLSの展開における他の安全保障問題について、このドキュメントの範囲の外にありますが、他のMPLS仕様で議論します、[RFC3031]などのように、[RFC3036]、[RFC3107]、[RFC3209]、[RFC3478]、[RFC3479]、[RFC4206]、[RFC4220]、[RFC4221]、[RFC4378]、AND[RFC4379]。
5. IANA Considerations
5. IANA問題
IANA has marked the value 0x1 in the IP protocol version number space as "Reserved" and placed a reference to this document to both values 0x0 and 0x1.
IANAは「予約される」ようにIPプロトコルバージョン数のスペースで値が0×1であるとマークして、両方の値0×0と0x1にこのドキュメントの参照を置きました。
Swallow, et al. Best Current Practice [Page 5] RFC 4928 Avoiding ECMP Treatment in MPLS Networks June 2007
ツバメ、他 2007年6月にMPLSネットワークでECMP処理を避ける最も良い現在の習慣[5ページ]RFC4928
Note that this document does not in any way change the policies regarding the allocation of version numbers, including the possible use of the reserved numbers for some future purpose.
このドキュメントが何らかの方法でバージョン番号の配分に関する方針を変えないことに注意してください、何らかの将来の目的の予約された数の活用可能性を含んでいて。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
6.2. Informative References
6.2. 有益な参照
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] アンデションとL.とDoolanとP.とフェルドマンとN.とFredette、A.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
「BGP-4インチ、RFC3107、2001年5月にラベル情報を運ぶ」[RFC3107]Rekhter、Y.、およびE.ローゼン。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478] Leelanivas、M.、Rekhter、Y.、およびR.Aggarwal、「ラベル分配プロトコルのための優雅な再開メカニズム」、RFC3478、2003年2月。
[RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479] ファレル、A.、エド、「ラベル分配プロトコル(自由民主党)のための耐障害性」、RFC3479、2月2003日
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella(K.とY.Rekhter)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、2005年10月。
[RFC4220] Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering Link Management Information Base", RFC 4220, November 2005.
[RFC4220] ドュバックとM.とナドー、T.とJ.ラング、「交通工学リンク管理情報ベース」、RFC4220、2005年11月。
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005.
[RFC4221] ナドー、T.、Srinivasan、C.、およびA.ファレル、「Multiprotocolラベルの切り換え(MPLS)マネジメントの展望」、RFC4221、2005年11月。
[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
エド[RFC4378]アラン、D.(エド)、およびT.ナドー、「マルチプロトコルラベルのための枠組みは(MPLS)操作と管理(OAM)を切り換えること」でのRFC4378(2006年2月)。
Swallow, et al. Best Current Practice [Page 6] RFC 4928 Avoiding ECMP Treatment in MPLS Networks June 2007
ツバメ、他 2007年6月にMPLSネットワークでECMP処理を避ける最も良い現在の習慣[6ページ]RFC4928
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.、およびG.は2006年2月に「マルチプロトコルのラベルの切り換えられた(MPLS)データ飛行機の故障を検出すること」でのRFC4379を飲み込みます。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385] ブライアント、S.は飲み込まれます、マティーニ、L.とD.マクファーソン、「縁から縁(PWE3)へのコントロールがMPLS PSNの上の使用のために言い表すPseudowireエミュレーション」RFC4385、G.、2006年2月。
Authors' Addresses
作者のアドレス
Loa Andersson Acreo AB Electrum 236 SE-146 40 Kista Sweden
LoaアンデションAcreo AB琥珀金236SE-146 40Kistaスウェーデン
EMail: loa@pi.se
メール: loa@pi.se
Stewart Bryant Cisco Systems 250, Longwater, Green Park, Reading, RG2 6GB, UK
スチュワートブライアントシスコシステムズ250、Longwater、グリーンパーク読書、RG2 6GB、イギリス
EMail: stbryant@cisco.com
メール: stbryant@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719
マサチューセッツAve Boxborough、ジョージツバメシスコシステムズInc.1414MA 01719
EMail: swallow@cisco.com
メール: swallow@cisco.com
Swallow, et al. Best Current Practice [Page 7] RFC 4928 Avoiding ECMP Treatment in MPLS Networks June 2007
ツバメ、他 2007年6月にMPLSネットワークでECMP処理を避ける最も良い現在の習慣[7ページ]RFC4928
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Swallow, et al. Best Current Practice [Page 8]
ツバメ、他 最も良い現在の習慣[8ページ]
一覧
スポンサーリンク