Network Working Group A. Atlas, Ed.
Request for Comments: 5286 BT
Category: Standards Track A. Zinin, Ed.
Alcatel-Lucent
September 2008
Basic Specification for IP Fast Reroute: Loop-Free Alternates
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network.
この文書は、リンク、ノード、または共有リスクリンクグループ（SRLG）かどうかを、単一障害が発生した場合に、純粋なIPおよびMPLS / LDPネットワークでユニキャストトラフィックのローカルな保護を提供するために、ループのない交互の使用を記載しています。この技術の目標は、ルータが故障によりトポロジ変更後に収束しながら起こるパケット損失を低減することです。迅速な故障の修理は、分散ネットワークコンバージェンスプロセスが完了するまでループフリーで安全に使用するためにある事前に計算バックアップネクストホップを使用することによって達成されます。この単純なアプローチは、他のルータからのサポートを必要としません。この目標は、この仕様によって満たされることができる範囲は、ネットワークのトポロジーに依存しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Failure Scenarios . . . . . . . . . . . . . . . . . . . . 5
1.2. Requirement Language . . . . . . . . . . . . . . . . . . . 8
2. Applicability of Described Mechanisms . . . . . . . . . . . . 8
3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 9
3.1. Basic Loop-Free Condition . . . . . . . . . . . . . . . . 10
3.2. Node-Protecting Alternate Next-Hops . . . . . . . . . . . 10
3.3. Broadcast and Non-Broadcast Multi-Access (NBMA) Links . . 11
3.4. ECMP and Alternates . . . . . . . . . . . . . . . . . . . 12
3.5. Interactions with IS-IS Overload, RFC 3137, and Costed
Out Links . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.1. Interactions with IS-IS Link Attributes . . . . . . . 14
3.6. Selection Procedure . . . . . . . . . . . . . . . . . . . 14
3.7. LFA Types and Trade-Offs . . . . . . . . . . . . . . . . . 18
3.8. A Simplification: Per-Next-Hop LFAs . . . . . . . . . . . 19
4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Terminating Use of Alternate . . . . . . . . . . . . . . . 20
5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 22
6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 22
6.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3.1. OSPF External Routing . . . . . . . . . . . . . . . . 24
6.3.2. OSPF Multi-Topology . . . . . . . . . . . . . . . . . 25
6.4. BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 25
6.5. Multicast Considerations . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. OSPF Example Where LFA Based on Local Area
Topology Is Insufficient . . . . . . . . . . . . . . 27
Applications for interactive multimedia services such as Voice over IP (VoIP) and pseudowires can be very sensitive to traffic loss, such as occurs when a link or router in the network fails. A router's convergence time is generally on the order of hundreds of milliseconds; the application traffic may be sensitive to losses greater than tens of milliseconds.
そのようなボイスオーバーIP（VoIP）のと疑似回線などのインタラクティブなマルチメディアサービスのためのアプリケーションは、ネットワーク内のリンクやルーターが故障したときに生じるような、トラフィック損失に非常に敏感である可能性があります。ルーターの収束時間は数百ミリ秒のオーダーで、一般的です。アプリケーショントラフィックは、数十ミリ秒よりも大きな損失に敏感です。
As discussed in [FRAMEWORK], minimizing traffic loss requires a mechanism for the router adjacent to a failure to rapidly invoke a repair path, which is minimally affected by any subsequent re-convergence. This specification describes such a mechanism that allows a router whose local link has failed to forward traffic to a pre-computed alternate until the router installs the new primary next-hops based upon the changed network topology. The terminology used in this specification is given in [FRAMEWORK]. The described mechanism assumes that routing in the network is performed using a link-state routing protocol -- OSPF [RFC2328] [RFC2740] [RFC5340] or IS-IS [RFC1195] [RFC2966] (for IPv4 or IPv6). The mechanism also assumes that both the primary path and the alternate path are in the same routing area.
【FRAMEWORK]で議論するように、トラフィック損失を最小化する最小任意のその後の再収束に影響され、急速に修復経路を呼び出すために失敗に隣接ルータのメカニズムを必要とします。この仕様は、ローカルリンクルータが変更されたネットワークトポロジに基づいて、新しいプライマリ次ホップをインストールするまで、予め計算交互にトラフィックを転送するために失敗したルータを可能にするような機構が記載されています。本明細書において使用される用語は[FRAMEWORK]で与えられます。 OSPF [RFC2328]、[RFC2740]、[RFC5340]、または（IPv4またはIPv6の場合）[RFC1195]、[RFC2966]-ISは、 - 説明したメカニズムは、ネットワークにおけるルーティングはリンク状態ルーティングプロトコルを用いて行われることを想定しています。機構はまた、一次パスと代替パスの両方が同一のルーティングエリア内にあることを前提としています。
When a local link fails, a router currently must signal the event to its neighbors via the IGP, recompute new primary next-hops for all affected prefixes, and only then install those new primary next-hops into the forwarding plane. Until the new primary next-hops are installed, traffic directed towards the affected prefixes is discarded. This process can take hundreds of milliseconds.
ローカルリンクに障害が発生した場合、ルータは現在、IGP経由して隣国にイベントを通知影響を受けるすべてのプレフィックスのための新しいプライマリネクストホップを再計算し、その後にのみフォワーディングプレーンにそれらの新しいプライマリネクストホップをインストールする必要があります。新しいプライマリネクストホップがインストールされるまで、影響を受けたプレフィックスに向けられたトラフィックは廃棄されます。このプロセスは、数百ミリ秒を取ることができます。
<--
+-----+
/------| S |--\
/ +-----+ \
/ 5 8 \
/ \
+-----+ +-----+
| E | | N_1 |
+-----+ +-----+
\ /
\ \ 4 3 / /
\| \ / |/
-+ \ +-----+ / +-
\---| D |---/
+-----+
Figure 1: Basic Topology
図1：基本トポロジ
The goal of IP Fast Reroute (IPFRR) is to reduce failure reaction time to 10s of milliseconds by using a pre-computed alternate next-hop, in the event that the currently selected primary next-hop fails, so that the alternate can be rapidly used when the failure is detected. A network with this feature experiences less traffic loss and less micro-looping of packets than a network without IPFRR. There are cases where traffic loss is still a possibility since IPFRR coverage varies, but in the worst possible situation a network with IPFRR is equivalent with respect to traffic convergence to a network without IPFRR.
代替が急速にできるようにIP高速再ルーティング（IPFRR）の目標は、現在選択された一次次のホップが故障した場合に、予め計算代替次のホップを使用して、10ミリ秒に不良反応時間を減少させることです障害が検出されたときに使用されます。この機能を持つネットワークが少ないトラフィック損失とIPFRRないネットワークよりもパケットの小さいマイクロループを経験します。 IPFRRカバレッジが変化するため、トラフィックの損失がまだ可能性があるが、最悪の事態にIPFRRとのネットワークがIPFRRなしでネットワークへのトラフィックの収束に関して同等である場合があります。
To clarify the behavior of IP Fast Reroute, consider the simple topology in Figure 1. When router S computes its shortest path to router D, router S determines to use the link to router E as its primary next-hop. Without IP Fast Reroute, that link is the only next-hop that router S computes to reach D. With IP Fast Reroute, S also looks for an alternate next-hop to use. In this example, S would determine that it could send traffic destined to D by using the link to router N_1 and therefore S would install the link to N_1 as its alternate next-hop. At some later time, the link between router S and router E could fail. When that link fails, S and E will be the first to detect it. On detecting the failure, S will stop sending traffic destined for D towards E via the failed link, and instead send the traffic to S's pre-computed alternate next-hop, which is the link to N_1, until a new SPF is run and its results are installed. As with the primary next-hop, an alternate next-hop is computed for each destination. The process of computing an alternate next-hop does not alter the primary next-hop computed via a standard SPF.
ルータSはDのルータへの最短パスを計算するときにIP高速再ルーティングの動作を明確にするために、図1の単純なトポロジーを考慮し、ルータSは、その一次ネクストホップとしてEをルータへのリンクを使用することを決定します。 IP高速リルートがなければ、そのリンクは、ルータSは、IP高速リルートでDまで計算のみネクストホップがある別のネクストホップを使用するために、Sにも見えます。この例では、Sは、N_1をルータおよび従ってSは、その代替のネクストホップとしてN_1へのリンクをインストールすることになるリンクを使用してD宛てのトラフィックを送信することができることを決定するであろう。しばらくして、ルータのSとルータE間のリンクが失敗する可能性があります。そのリンクに障害が発生した場合、SとEは、それを検出する初めてとなります。故障を検出すると、Sは失敗したリンクを介してEに向けてD宛てのトラフィックの送信を停止し、代わりに新しいSPFが実行されるまで、N_1へのリンクであるSの事前計算された別のネクストホップへのトラフィックを送信し、その結果がインストールされています。プライマリネクストホップと同様に、代替のネクストホップは、宛先毎に計算されます。代替のネクストホップを計算するプロセスは、標準的なSPFを介して計算された一次次ホップを変更しません。
If in the example of Figure 1, the link cost from N_1 to D increased to 30 from 3, then N_1 would not be a loop-free alternate, because the cost of the path from N_1 to D via S would be 17 while the cost from N_1 directly to D would be 30. In real networks, we may often face this situation. The existence of a suitable loop-free alternate next-hop is dependent on the topology and the nature of the failure for which the alternate is calculated.
図1の例では、N_1からDへのリンクコストは3から30に増加した場合はSを介しN_1からDへの経路のコストがコストながら17になるので、その後N_1は、ループフリーの代替ではないであろうN_1から直接Dに本物のネットワークでは30になり、私たちはしばしばこのような状況に直面する可能性があります。好適なループフリー代替のネクストホップの存在は、トポロジーおよび代替が計算される障害の性質に依存しています。
This specification uses the terminology introduced in [FRAMEWORK]. In particular, it uses Distance_opt(X,Y), abbreviated to D_opt(X,Y), to indicate the shortest distance from X to Y. S is used to indicate the calculating router. N_i is a neighbor of S; N is used as an abbreviation when only one neighbor is being discussed. D is the destination under consideration.
この仕様は[FRAMEWORK]で導入された用語を使用します。特に、それはXからYのSへの最短距離を示すために、D_opt（X、Y）と略記する、Distance_opt（X、Y）を使用するが、計算のルータを示すために使用されます。 N_iはSの隣人です。 Nは、ただ1つのネイバーが議論されている略語として使用されます。 Dは、検討中の宛先です。
A neighbor N can provide a loop-free alternate (LFA) if and only if
近隣Nはループのない代替（LFA）を提供することができ、場合のみなら
Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)
Distance_opt（N、D）<Distance_opt（N、S）+ Distance_opt（S、D）
Inequality 1: Loop-Free Criterion
不平等1：ループフリー基準
A subset of loop-free alternates are downstream paths that must meet a more restrictive condition that is applicable to more complex failure scenarios:
ループのない交互のサブセットは、より複雑な障害シナリオに適用可能であるより多くの制約条件を満たしている必要があり、下流経路です。
Distance_opt(N, D) < Distance_opt(S, D)
Distance_opt（N、D）<Distance_opt（S、D）
Inequality 2: Downstream Path Criterion
不平等2：ダウンストリームパスの基準
The alternate next-hop can protect against a single link failure, a single node failure, failure of one or more links within a shared risk link group, or a combination of these. Whenever a failure occurs that is more extensive than what the alternate was intended to protect, there is the possibility of temporarily looping traffic (note again, that such a loop would only last until the next complete SPF calculation). The example where a node fails when the alternate provided only link protection is illustrated below. If unexpected simultaneous failures occur, then micro-looping may occur since the alternates are not pre-computed to avoid the set of failed links.
代替のネクストホップは、単一リンク故障、単一ノード障害、共有リスク・リンク・グループ内の1つのまたは複数のリンクの故障、又はこれらの組み合わせから保護することができます。障害が代替を保護することを目的としたものよりも、より広範囲で発生するたびに、一時的に（このようなループのみが次の完全なSPF計算まで続くであろうと、再び注意してください）トラフィックをループする可能性があります。代替的にはリンクのみ保護を提供した場合、ノードに障害が発生した例を以下に示します。予想外の同時障害が発生した場合は交互に失敗したリンクのセットを避けるために、事前に計算されていないので、その後、マイクロループが発生することがあります。
If only link protection is provided and the node fails, it is possible for traffic using the alternates to experience micro-looping. This issue is illustrated in Figure 2. If Link(S->E) fails, then the link-protecting alternate via N will work correctly. However, if router E fails, then both S and N will detect a failure and switch to their alternates. In this example, that would cause S to redirect the traffic to N and N to redirect the traffic to S and thus causing a forwarding loop. Such a scenario can arise because the key assumption, that all other routers in the network are forwarding based upon the shortest path, is violated because of a second simultaneous correlated failure -- another link connected to the same primary neighbor. If there are not other protection mechanisms to handle node failure, a node failure is still a concern when only using link-protecting LFAs.
リンクのみの保護が提供され、ノードに障害が発生している場合は、マイクロループを体験するために交互に使用してトラフィックのために可能です。リンク（S-> E）が失敗した場合、この問題は、図2に示されている、その後、Nを介してリンク保護の代替が正常に動作します。ルータEが失敗した場合は、その後、SとNの両方が障害を検出し、その交互に切り替わります。この例では、これはSをSにトラフィックをリダイレクトし、したがって、転送ループを発生させるためにNとNにトラフィックをリダイレクトする原因となります。同じ主ネイバーに接続された他のリンク - 重要な仮定は、ネットワーク内の他のすべてのルータは、最短経路に基づいて転送されること、なぜなら第二同時相関障害の違反されているので、このようなシナリオが生じ得ます。ノード障害を処理するために、他の保護メカニズムが存在しない場合は、ノード障害は、まだリンクのみ保護LFAsを使用して懸念されます。
<@@@
@@@>
+-----+ +-----+
| S |-------| N |
+-+---+ 5 +-----+
| |
| 5 4 | |
| | | \|/
\|/ | |
| +-----+ |
+----| E |---+
+--+--+
|
|
| 10
|
+--+--+
| D |
+-----+
Figure 2: Link-Protecting Alternates Causing Loop on Node Failure
図2：ノード障害にループを引き起こして交互にリンク保護
Micro-looping of traffic via the alternates caused when a more extensive failure than planned for occurs can be prevented via selection of only downstream paths as alternates. A micro-loop due to the use of alternates can be avoided by using downstream paths because each succeeding router in the path to the destination must be closer to the destination than its predecessor (according to the topology prior to the failures). Although use of downstream paths ensures that the micro-looping via alternates does not occur, such a restriction can severely limit the coverage of alternates. In Figure 2, S would be able to use N as a downstream alternate, but N could not use S; therefore, N would have no alternate and would discard the traffic, thus avoiding the micro-loop.
交互介してトラフィックのマイクロループ発生のために計画されたよりも広範障害が交互としてのみ下流経路の選択を介して防止することができる場合。引き起こさ交互の使用によるマイクロループは、（故障前にトポロジーに従う）宛先へのパス内の各後続のルータは、その前任者より先に近くなければならないので、下流経路を使用することによって回避することができます。下流経路の使用は、マイクロループ交互介しが発生しないことを保証するが、このような制限は厳しく交互の適用範囲を制限することができます。図2において、Sは、下流代替としてNを使用することができるであろうが、NはSを使用することができませんでした。従って、Nには代替を持っていないことになるので、マイクロループを回避すること、トラフィックを廃棄することになります。
As shown above, the use of either a node-protecting LFA (described in Section 3.2) or a downstream path provides protection against micro-looping in the event of node failure. There are topologies where there may be either a node-protecting LFA, a downstream path, both, or neither. A node may select either a node-protecting LFA or a downstream path without risk of causing micro-loops in the event of neighbor node failure. While a link-and-node-protecting LFA guarantees protection against either link or node failure, a downstream path provides protection only against a link failure and may or may not provide protection against a node failure depending on the protection available at the downstream node, but it cannot cause a micro-loop. For example, in Figure 2, if S uses N as a downstream path, although no looping can occur, the traffic will not be protected in the event of the failure of node E because N has no viable repair path, and it will simply discard the packet. However, if N had a link-and-node-protecting LFA or downstream path via some other path (not shown), then the repair may succeed.
上記のように、（セクション3.2を参照）、ノード保護LFAまたは下流経路のいずれかを使用することは、ノードに障害が発生した場合に、マイクロループに対する保護を提供します。ノード保護のいずれかLFA、下流経路の両方、またはいずれもが存在してもよいトポロジが存在します。ノードは、隣接ノードに障害が発生した場合にマイクロループを引き起こすリスクなしノード保護LFAまたは下流経路のいずれかを選択してもよいです。リンク及びノード保護LFAは、リンクまたはノードの障害のいずれかに対する保護を保証しながら、下流経路は、リンク障害に対する保護を提供し、又は、下流ノードで利用可能な保護に応じてノード障害に対する保護を提供してもしなくてもよいですそれはマイクロループが発生することはできません。何ループが発生しないことができるがSは、下流経路としてNを使用する場合、例えば、図2において、Nは全く生存修復経路を有していないので、トラフィックは、ノードEの障害が発生した場合に保護されないであろう、そしてそれは単に破棄されますパケット。 Nは、いくつかの他の経路（図示せず）を介して、LFAまたは下流経路をリンクとノード保護であった場合は、その後、修復が成功してもよいです。
Since the functionality of link-and-node-protecting LFAs is greater than that of link-protecting downstream paths, a router SHOULD select a link-and-node-protecting LFA over a link-protecting downstream path. If there are any destinations for which a link-and-node-protecting LFA is not available, then by definition the path to all of those destinations from any neighbor of the computing router (S) must be through the node (E) being protected (otherwise there would be a node protecting LFA for that destination). Consequently, if there exists a downstream path to the protected node as destination, then that downstream path may be used for all those destinations for which a link-and-node-protecting LFA is not available; the existence of a downstream path can be determined by a single check of the condition Distance_opt(N, E) < Distance_opt(S, E).
リンク及びノード保護LFAsの機能は、リンク保護下流経路のそれよりも大きいので、ルータはリンク保護ダウンストリームパス上のリンクおよびノード保護LFAを選択すべきです。リンク及びノード保護LFAが利用できるされていない任意の宛先が存在する場合、定義により、コンピューティングルータ（S）のいずれかの隣からそれらの宛先の全てのパスが保護される（E）ノードを介してでなければなりません（そうでなければ、その宛先のLFA保護ノードが存在することになります）。先として保護されたノードへのダウンストリームパスが存在する場合、結果として、その下流経路は、リンク及びノード保護LFA不明であるすべてのそれらの宛先に使用することができます。下流経路の存在は、条件Distance_opt（N、E）<Distance_opt（S、E）の1つのチェックによって決定することができます。
It may be desirable to find an alternate that can protect against other correlated failures (of which node failure is a specific instance). In the general case, these are handled by shared risk link groups (SRLGs) where any links in the network can belong to the SRLG. General SRLGs may add unacceptably to the computational complexity of finding a loop-free alternate.
（ノード障害が特定のインスタンスである）他の相関障害から保護することができる代替を見つけることが望ましいかもしれません。一般的なケースでは、これらは、ネットワーク内の任意のリンクがSRLGに属することができ、共有リスク・リンク・グループ（SRLGs）によって処理されます。一般SRLGsは、ループフリーの代替を見つけるの計算の複雑さに許容できないほど追加することができます。
However, a sub-category of SRLGs is of interest and can be applied only during the selection of an acceptable alternate. This sub-category is to express correlated failures of links that are connected to the same router, for example, if there are multiple logical sub-interfaces on the same physical interface, such as VLANs on an Ethernet interface, if multiple interfaces use the same physical port because of channelization, or if multiple interfaces share a correlated failure because they are on the same line-card. This sub-category of SRLGs will be referred to as local-SRLGs. A local-SRLG has all of its member links with one end connected to the same router. Thus, router S could select a loop-free alternate that does not use a link in the same local-SRLG as the primary next-hop. The failure of local-SRLGs belonging to E can be protected against via node protection, i.e., picking a loop-free node-protecting alternate.
しかしながら、SRLGsのサブカテゴリは、関心のあるのみ許容される代替の選択時に適用することができます。このサブカテゴリは、複数のインターフェイスが同じを使用する場合は、イーサネットインターフェイス上のVLANと同じ物理インタフェース上で複数の論理サブインターフェースがある場合、例えば、同じルータに接続されているリンクの相関障害を発現させることですなぜならチャネルの物理ポート、またはそれらは同じラインカード上にあるため、複数のインタフェースは、相関故障を共有する場合。 SRLGsのこのサブカテゴリは、ローカルSRLGsと呼ぶことにします。ローカルSRLGは、同じルータに接続されている一端とそのメンバーリンクのすべてを持っています。このように、ルータのSは、プライマリのネクストホップと同じローカル・SRLG内のリンクを使用していないループフリーの代替を選択することができます。 Eに属するローカルSRLGsの故障は、ノード保護を介して保護することができる、すなわち、ループフリーノード保護代替ピッキング。
Where SRLG protection is provided, it is in the context of the particular OSPF or IS-IS area, whose topology is used in the SPF computations to compute the loop-free alternates. If an SRLG contains links in multiple areas, then separate SRLG-protecting alternates would be required in each area that is traversed by the affected traffic.
SRLG保護が提供される場合、それは特定のOSPFのコンテキストにある又はそのトポロジーループフリー交互に計算するためにSPFの計算に使用される領域は、IS-IS。 SRLGは、複数の領域のリンクが含まれている場合、別SRLG保護交互には、影響を受けたトラフィックによってトラバースされた各領域に必要とされるであろう。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
IP Fast Reroute mechanisms described in this memo cover intra-domain routing only, with OSPF [RFC2328] [RFC2740] [RFC5340] or IS-IS [RFC1195] [RFC2966] as the IGP. Specifically, Fast Reroute for BGP inter-domain routing is not part of this specification.
IGPとしてOSPF [RFC2328]、[RFC2740]、[RFC5340]またはIS-IS [RFC1195]、[RFC2966]でのみ、このメモカバードメイン内ルーティングに記載のIP高速再ルーティングメカニズム。具体的には、BGPドメイン間ルーティングのための高速リルートは、本明細書の一部ではありません。
Certain aspects of OSPF inter-area routing behavior explained in Section 6.3 and Appendix A impact the ability of the router calculating the backup next-hops to assess traffic trajectories. In order to avoid micro-looping and ensure required coverage, certain constraints are applied to multi-area OSPF networks:
OSPFのエリア間のルーティング動作の特定の態様は、セクション6.3および付録の影響を説明し、バックアップを計算するルータの能力は、トラフィック軌道を評価するために、次ホップ。マイクロループ回避し、必要なカバレッジを確保するために、特定の制約がマルチエリアOSPFネットワークに適用されます。
a. Loop-free alternates should not be used in the backbone area if there are any virtual links configured unless, for each transit area, there is a full mesh of virtual links between all Area Border Routers (ABRs) in that area. Loop-free alternates may be used in non-backbone areas regardless of whether there are virtual links configured.
A。しない限り、設定された任意の仮想リンクがある場合はループのない交互のバックボーンエリアに使用すべきではない、それぞれのトランジットエリアのために、その領域内のすべてのエリア境界ルータ間の仮想リンク（のABR）のフルメッシュがあります。ループフリー交互にかかわらず、構成された仮想リンクがあるかどうかの非バックボーンエリアで使用することができます。
b. Loop-free alternates should not be used for inter-area routes in an area that contains more than one alternate ABR [RFC3509].
B。ループフリー交互には、複数の代替ABR [RFC3509]を含む領域におけるエリア間のルートのために使用すべきではありません。
c. Loop-free alternates should not be used for AS External routes or Autonomous System Border Router (ASBR) routes in a non-backbone area of a network where there exists an ABR that is announced as an ASBR in multiple non-backbone areas and there exists another ABR that is in at least two of the same non-backbone areas.
C。ループフリー交互に複数の非バックボーンエリアのASBRとして発表して存在さABRが存在するネットワークの非バックボーンエリアにAS外部ルートや自律システム境界ルータ（ASBR）ルートに使用すべきではありません同じ非バックボーンエリアの少なくとも2である別のABR。
d. Loop-free alternates should not be used in a non-backbone area of a network for AS External routes where an AS External prefix is advertised with the same type of external metric by multiple ASBRs, which are in different non-backbone areas, with a forwarding address of 0.0.0.0 or by one or more ASBRs with forwarding addresses in multiple non-backbone areas when an ABR exists simultaneously in two or more of those non-backbone areas.
D。ループフリー交互にして、AS外部プレフィックスが異なる非バックボーンエリア内にある複数のASBRによって外部のメトリックの同じタイプでアドバタイズされるAS外部ルートのネットワークの非バックボーンエリアに使用すべきではありません0.0.0.0のアドレスを転送するか、ABRは、これらの非骨格領域の2つ以上に同時に存在する場合、複数の非バックボーン領域にアドレスを転送有する1つの以上のASBRによって。
In addition to the set of primary next-hops obtained through a shortest path tree (SPT) computation that is part of standard link-state routing functionality, routers supporting IP Fast Reroute also calculate a set of backup next-hops that are engaged when a local failure occurs. These backup next-hops are calculated to provide the required type of protection (i.e., link-protecting and/or node-protecting) and to guarantee that when the expected failure occurs, forwarding traffic through them will not result in a loop. Such next-hops are called loop-free alternates or LFAs throughout this specification.
標準的なリンクステートルーティング機能の一部であり、最短経路ツリー（SPT）演算により得られた一次次ホップのセットに加えて、IP高速再ルーティングをサポートするルータは、係合されているバックアップの次のホップの集合を計算します地元の障害が発生しました。これらのバックアップ次のホップは、保護の必要な型（すなわち、リンク保護および/またはノード保護）を提供すると予想される障害が発生した場合、それらを介してトラフィックを転送するループを生じないことを保証するために計算されます。このようなネクストホップは、本明細書を通してループフリー交互またはLFAsと呼ばれています。
In general, to be able to calculate the set of LFAs for a specific destination D, a router needs to know the following basic pieces of information:
一般的に、特定の宛先DためLFAsのセットを計算することができるように、ルータは、情報の次の基本的な部分を知る必要があります。
o Shortest-path distance from the calculating router to the destination (Distance_opt(S, D))
目的地までの計算のルータからO最短パス距離（Distance_opt（S、D））
o Shortest-path distance from the router's IGP neighbors to the destination (Distance_opt(N, D))
宛先へのルータのIGPネイバからO最短パス距離（Distance_opt（N、D））
o Shortest path distance from the router's IGP neighbors to itself (Distance_opt(N, S))
O自体のルータのIGPネイバから最短経路距離（Distance_opt（N、S））
o Distance_opt(S, D) is normally available from the regular SPF calculation performed by the link-state routing protocols. Distance_opt(N, D) and Distance_opt(N, S) can be obtained by performing additional SPF calculations from the perspective of each IGP neighbor (i.e., considering the neighbor's vertex as the root of the SPT--called SPT(N) hereafter--rather than the calculating router's one, called SPT(S)).
O Distance_opt（S、D）は、リンクステートルーティングプロトコルによって実行される正規のSPF計算から通常入手可能です。 Distance_opt（N、D）およびDistance_opt（N、S）は、各IGPネイバーの観点から追加のSPF計算を行うことによって得ることができる（すなわち、SPTのルートとして隣人の頂点考慮 - ）SPT（N呼ばをhereafter-計算のルータの1、SPT（S）と呼ばれる）よりも-rather。
This specification defines a form of SRLG protection limited to those SRLGs that include a link to which the calculating router is directly connected. Only that set of SRLGs could cause a local failure; the calculating router only computes alternates to handle a local failure. Information about local link SRLG membership is manually configured. Information about remote link SRLG membership may be dynamically obtained using [RFC4205] or [RFC4203]. Define SRLG_local(S) to be the set of SRLGs that include a link to which the calculating router S is directly connected Only SRLG_local(S) is of interest during the calculation, but the calculating router must correctly handle changes to SRLG_local(S) triggered by local link SRLG membership changes.
この仕様は、計算のルータが直接接続されたリンクを含むものSRLGsに限定SRLG保護の形式を定義します。 SRLGsの唯一のそのセットは、ローカルの障害を引き起こす可能性があります。計算のルータは、ローカルの失敗を処理するために交互に計算します。ローカルリンクSRLGメンバーシップに関する情報は手動で設定されています。リモートリンクSRLGメンバーシップに関する情報は、動的に[RFC4205]か[RFC4203]を使用して得ることができます。 SRLG_localは、（S）計算のルータのSが直接接続されているリンクを含んSRLGsのセットであることを定義するだけSRLG_local（S）の計算時に重要であるが、計算のルータが正しくトリガSRLG_local（S）への変更を処理しなければなりませんローカルリンクSRLGメンバーシップの変化によって。
In order to choose among all available LFAs that provide required SRLG protection for a given destination, the calculating router needs to track the set of SRLGs in SRLG_local(S) that the path through a specific IGP neighbor involves. To do so, each node D in the network topology is associated with SRLG_set(N, D), which is the set of SRLGs that would be crossed if traffic to D was forwarded through N. To calculate this set, the router initializes SRLG_set(N, N) for each of its IGP neighbors to be empty. During the SPT(N) calculation, when a new vertex V is added to the SPT, its SRLG_set(N, V) is set to the union of SRLG sets associated with its parents, and the SRLG sets in SRLG_local(S) that are associated with the links from V's parents to V. The union of the set of SRLGs associated with a candidate alternate next-hop and the SRLG_set(N, D) for the neighbor reached via that candidate next-hop is used to determine SRLG protection.
所与の宛先に必要なSRLGの保護を提供し、利用可能なすべてのLFAsの中から選択するために、計算のルータは、特定のIGP隣接通る経路が関与することSRLG_local（S）でSRLGsのセットを追跡する必要があります。これを行うには、ネットワークトポロジ内の各ノードDは、Dへのトラフィックは、このセットを計算するためにNを介して転送された場合に交差されるSRLGsの集合であるSRLG_set（N、D）に関連付けられ、ルータは（SRLG_setを初期化しますそのIGP隣人のそれぞれについて、N、N）が空になります。新しい頂点VがSPTに添加するSPT（N）の計算の間、そのSRLG_set（Nは、V）は、その親に関連付けられているSRLGセットの和集合に設定されているSRLG_local（S）でSRLGセットその候補次ホップがSRLG保護を決定するために使用される介し候補代替のネクストホップ及び隣人のためSRLG_set（N、D）に関連SRLGsの集合の和集合に達するVの両親からV.へのリンクに関連付けられています。
The following sections provide information required for calculation of LFAs. Sections 3.1 through 3.4 define different types of LFA conditions. Section 3.5 describes constraints imposed by the IS-IS overload and OSPF stub router functionality. Section 3.6 defines the summarized algorithm for LFA calculation using the definitions in the previous sections.
次のセクションでは、LFAsの計算に必要な情報を提供します。セクション3.1 3.4までは、LFA条件の異なるタイプを定義します。 3.5節は、IS-ISの過負荷とOSPFスタブルータ機能による制約を記述する。セクション3.6は、前のセクションでの定義を使用してLFA計算のための要約アルゴリズムを定義します。
Alternate next hops used by implementations following this specification MUST conform to at least the loop-freeness condition stated above in Inequality 1. This condition guarantees that forwarding traffic to an LFA will not result in a loop after a link failure.
本明細書の以下の実施態様によって使用される代替の次のホップは、LFAにトラフィックを転送するリンク障害の後にループを生じないことをこの条件を保証不平等1の上述した少なくともループろ水度条件に従わなければなりません。
Further conditions may be applied when determining link-protecting and/or node-protecting alternate next-hops as described in Sections 3.2 and 3.3.
セクション3.2および3.3に記載されているように、リンク保護および/またはノード保護代替のネクストホップを決定する際にさらに条件を適用することができます。
For an alternate next-hop N to protect against node failure of a primary neighbor E for destination D, N must be loop-free with respect to both E and D. In other words, N's path to D must not go through E. This is the case if Inequality 3 is true, where N is the neighbor providing a loop-free alternate.
代替のネクストホップN宛先Dのプライマリ隣接Eのノードの障害から保護するために、Nは、換言すれば、EおよびDの両方に対してループフリーでなければならないため、DのNの経路はE.これを通過してはなりませんNはループフリーの代替を提供する隣人である不等式3が真である場合場合は、です。
Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, D)
Distance_opt（N、D）<Distance_opt（N、E）+ Distance_opt（E、D）
Inequality 3: Criteria for a Node-Protecting Loop-Free Alternate
不平等3：ノードの保護ループフリーの代替のための基準
If Distance_opt(N,D) = Distance_opt(N, E) + Distance_opt(E, D), it is possible that N has equal-cost paths and one of those could provide protection against E's node failure. However, it is equally possible that one of N's paths goes through E, and the calculating router has no way to influence N's decision to use it. Therefore, it SHOULD be assumed that an alternate next-hop does not offer node protection if Inequality 3 is not met.
Distance_opt（N、D）= Distance_opt（N、E）+ Distance_opt（E、D）場合、Nが等しいコストパスを有しており、それらの一つはEのノード障害に対する保護を提供することが可能です。しかし、NのパスのいずれかがEを通過することも同様に可能であり、計算のルータは、それを使用するNの決定に影響を与える方法はありません。従って、不等式3が満たされない場合、代替次ホップノード保護を提供しないことが想定されるべきです。
Verification of the link-protection property of a next-hop in the case of a broadcast link is more elaborate than for a point-to-point link. This is because a broadcast link is represented as a pseudo-node with zero-cost links connecting it to other nodes.
ブロードキャストリンクの場合、ネクストホップのリンク保護特性の検証は、ポイントツーポイントリンクのためのより精巧です。放送リンクは、他のノードに接続するゼロコストのリンクを持つ擬似ノードとして表されるためです。
Because failure of an interface attached to a broadcast segment may mean loss of connectivity of the whole segment, the condition described for broadcast link protection is pessimistic and requires that the alternate is loop-free with regard to the pseudo-node. Consider the example in Figure 3.
ブロードキャストセグメントに取り付けられたインターフェイスの障害が全体のセグメントの接続性の喪失を意味する可能性があるため、放送リンク保護のために記述された条件は、悲観的であり、代替の擬似ノードに関してループフリーであることを必要とします。図3の例を考えます。
+-----+ 15
| S |--------
+-----+ |
| 5 |
| |
| 0 |
/----\ 0 5 +-----+
| PN |-----| N |
\----/ +-----+
| 0 |
| | 8
| 5 |
+-----+ 5 +-----+
| E |----| D |
+-----+ +-----+
Figure 3: Loop-Free Alternate That Is Link-Protecting
図3：リンク保護してループフリーの代替
In Figure 3, N offers a loop-free alternate that is link-protecting. If the primary next-hop uses a broadcast link, then an alternate SHOULD be loop-free with respect to that link's pseudo-node (PN) to provide link protection. This requirement is described in Inequality 4 below.
図3において、Nは、リンク保護でループフリーの代替を提供しています。プライマリネクストホップブロードキャストのリンクを使用する場合、代替リンク保護を提供するために、そのリンクの擬似ノード（PN）に対してループフリーであるべきです。この要件は、以下の不等式4に記載されています。
D_opt(N, D) < D_opt(N, PN) + D_opt(PN, D)
D_opt（N、D）<D_opt（N、PN）+ D_opt（PN、D）
Inequality 4: Loop-Free Link-Protecting Criterion for Broadcast Links
不平等4：ブロードキャストリンクのループフリーリンク保護基準
Because the shortest path from the pseudo-node goes through E, if a loop-free alternate from a neighbor N is node-protecting, the alternate will also be link-protecting unless the router S can only reach the alternate neighbor N via the same pseudo-node. Since this is the only case for which a node-protecting LFA is not link-protecting, this implies that for point-to-point interfaces, an LFA that is node-protecting is always link-protecting. Because S can direct the traffic away from the shortest path to use the alternate N, traffic might pass through the same broadcast link as it would when S sent the traffic to the primary E. Thus, an LFA from N that is node-protecting is not automatically link-protecting for a broadcast or NBMA link.
擬似ノードからの最短経路がEを通過するため、隣接Nからループのない代替ノード保護である場合、ルータSは、同じ介して代替隣人Nに到達することができなければ、代替的には、リンク保護になり擬似ノード。これはノード保護LFAがリンク保護されていない場合のみであるため、これは、ポイントツーポイントインターフェイスのため、ノード保護であるLFAが常にリンク保護であることを意味します。 S離れ代替Nを使用する最短経路からのトラフィックを導くことができるので、トラフィックは、S。したがって、一次Eにトラフィックを送信する場合と同様に、ノード保護であるNからLFAが同じブロードキャストリンクを通過する可能性がありますない自動的にリンク保護ブロードキャストまたはNBMAリンクに。
To obtain link protection, it is necessary both that the path from the selected alternate next-hop does not traverse the link of interest and that the link used from S to reach that alternate next-hop is not the link of interest. The latter can only occur with non-point-to-point links. Therefore, if the primary next-hop is across a broadcast or NBMA interface, it is necessary to consider link protection during the alternate selection. To clarify, consider the topology in Figure 3. For N to provide link protection, it is first necessary that N's shortest path to D does not traverse the pseudo-node PN. Second, it is necessary that the alternate next-hop selected by S does not traverse PN. In this example, S's shortest path to N is via the pseudo-node. Thus, to obtain link protection, S must find a next-hop to N (the point-to-point link from S to N in this example) that avoids the pseudo-node PN.
リンク保護を得るためには、選択された代替のネクストホップからのパスは、対象のリンクを通過しないことの両方及びSから使用されるリンクは、その代替のネクストホップは、対象のリンクではない到達することが必要です。後者は唯一の非ポイントツーポイントリンクで発生する可能性があります。プライマリネクストホップブロードキャストまたはNBMAインタフェースを横切っている場合、したがって、代替選択中のリンク保護を考慮する必要があります。 、明確Nは、リンク保護を提供するために図3のトポロジーを考慮するためには、DのNの最短経路は、擬似ノードPNを横断しないことが最初に必要です。第二に、Sによって選択された代替のネクストホップはPNを通過しないことが必要です。この例では、NのSの最短経路は、擬似ノードを介してです。したがって、リンク保護を得るために、Sは、擬似ノードPNを回避N（この例ではSからNへのポイントツーポイントリンク）へのネクストホップを見つけなければなりません。
Similar consideration of the link from S to the selected alternate next-hop as well as the path from the selected alternate next-hop is also necessary for SRLG protection. S's shortest path to the selected neighbor N may not be acceptable as an alternate next-hop to provide SRLG protection, even if the path from N to D can provide SRLG protection.
同様の次ホップ選択交互にSからリンクの考慮、ならびに選択された代替パスから次ホップSRLGの保護のためにも必要です。選択された隣接NにSの最短経路は、DのNからパスがSRLGの保護を提供することができたとしても、SRLGの保護を提供するために、次ホップの代替として許容されないかもしれません。
With Equal-Cost Multi-Path (ECMP), a prefix may have multiple primary next-hops that are used to forward traffic. When a particular primary next-hop fails, alternate next-hops should be used to preserve the traffic. These alternate next-hops may themselves also be primary next-hops, but need not be. Other primary next-hops are not guaranteed to provide protection against the failure scenarios of concern.
等価コストマルチパス（ECMP）では、接頭辞はトラフィックを転送するために使用されている複数のプライマリネクストホップを有することができます。特定の一次次ホップが失敗した場合、代替のネクストホップトラフィックを保存するために使用されるべきです。これらの代替ネクストホップ自体はまた、主要なネクストホップであってもよいが、である必要はないことがあります。その他の主なネクストホップは懸念の障害シナリオに対する保護を提供するために保証されていません。
20 L1 L3 3
[ N ]----[ S ]--------[ E3 ]
| | |
| 5 | L2 |
20 | | |
| --------- | 2
| 5 | | 5 |
| [ E1 ] [ E2 ]-----|
| | |
| 10 | 10 |
|---[ A ] [ B ]
| |
2 |--[ D ]-| 2
Figure 4: ECMP Where Primary Next-Hops Provide Limited Protection
図4：プライマリネクストホップは限定的な保護を提供ECMP
In Figure 4 S has three primary next-hops to reach D; these are L2 to E1, L2 to E2, and L3 to E3. The primary next-hop L2 to E1 can obtain link and node protection from L3 to E3, which is one of the other primary next-hops; L2 to E1 cannot obtain link protection from the other primary next-hop L2 to E2. Similarly, the primary next-hop L2 to E2 can only get node protection from L2 to E1 and can only get link protection from L3 to E3. The third primary next-hop L3 to E3 can obtain link and node protection from L2 to E1 and from L2 to E2. It is possible for both the primary next-hop L2 to E2 and the primary next-hop L2 to E1 to obtain an alternate next-hop that provides both link and node protection by using L1.
図4にSは、一次三Dに到達するための次のホップを有します。これらは、E3にE1にL2、E2にL2、およびL3です。 E1の一次ネクストホップL2はL3から他の一次次ホップの一つであるE3へのリンクおよびノード保護を得ることができます。 E1へのL2は、E2の他の一次次ホップL2からリンク保護を取得することはできません。同様に、E2の主要ネクストホップL2のみE1にL2からノード保護を得ることができるのみE3にL3からリンク保護を得ることができます。 E3の第一次のネクストホップL3は、L2からのE1およびL2からE2へのリンクおよびノード保護を得ることができます。これは、E2の主要ネクストホップL2およびL1を用いて、リンクおよびノード保護の両方を提供する代替のネクストホップを得るE1一次ネクストホップL2の両方が可能です。
Alternate next-hops are determined for each primary next-hop separately. As with alternate selection in the non-ECMP case, these alternate next-hops should maximize the coverage of the failure cases.
代替のネクストホップは別々に各一次次ホップのために決定されます。非ECMPの場合に、代替の選択と同様に、これらの代替の次のホップは、障害ケースのカバレッジを最大化すべきです。
As described in [RFC3137], there are cases where it is desirable not to have a router used as a transit node. For those cases, it is also desirable not to have the router used on an alternate path.
[RFC3137]に記載されているように、中継ノードとして使用されるルータを持たないことが望ましい場合があります。そのような場合のために、代替パスで使用されるルータを有さないことが望ましいです。
For computing an alternate, a router MUST NOT use an alternate next-hop that is along a link whose cost or reverse cost is LSInfinity (for OSPF) or the maximum cost (for IS-IS) or that has the overload bit set (for IS-IS). For a broadcast link, the reverse cost associated with a potential alternate next-hop is the cost towards the pseudo-node advertised by the next-hop router. For point-to-point links, if a specific link from the next-hop router cannot be associated with a particular link, then the reverse cost considered is that of the minimum cost link from the next-hop router back to S.
代替を計算するために、ルータは、そのコスト又はコストを逆LSInfinity（OSPF）または（IS-ISのための）最大コストであるか、またはそれは過負荷ビットセット（用を有するリンクに沿って交互の次のホップを使用してはいけませんIS-IS）。放送リンクのために、潜在的な代替のネクストホップに関連付けられた逆コストは、ネクストホップルータによってアドバタイズ疑似ノードに向けコストです。ネクストホップルータから特定のリンクは、特定のリンクに関連付けることができない場合にポイントツーポイントリンクのために、次に考え逆コストバックS.へのネクストホップルータから最小コストのリンクのことです
In the case of OSPF, if all links from router S to a neighbor N_i have a reverse cost of LSInfinity, then router S MUST NOT use N_i as an alternate.
隣人N_iへのルータSからのすべてのリンクがLSInfinityの逆のコストを持っている場合、OSPFの場合は、その後、Sは、代替としてN_iを使用してはならないルータ。
Similarly in the case of IS-IS, if N_i has the overload bit set, then S MUST NOT consider using N_i as an alternate.
N_iが過負荷ビットが設定されている場合も同様にIS-ISの場合には、その後、Sは、代替としてN_iの使用を検討してはいけません。
This preserves the desired behavior of diverting traffic away from a router that is following [RFC3137], and it also preserves the desired behavior when an operator sets the cost of a link to LSInfinity for maintenance that is not permitting traffic across that link unless there is no other path.
これは、[RFC3137]以下れるルータから離れて、トラフィックを迂回させるの所望の動作を維持し、オペレータがない限り、リンク間でトラフィックを許可されていない保守のためにLSInfinityへのリンクのコストを設定するとき、それはまた、所望の動作を維持します他のパスはありません。
If a link or router that is costed out was the only possible alternate to protect traffic from a particular router S to a particular destination, then there should be no alternate provided for protection.
アウト負けましれるリンクやルータが特定の宛先に特定のルータSからのトラフィックを保護するための唯一の可能な代替した場合には、保護のためにありません代替があってはなりません。
[RFC5029] describes several flags whose interactions with LFAs need to be defined. A router SHOULD NOT specify the "local protection available" flag as a result of having LFAs. A router SHOULD NOT use an alternate next-hop that is along a link for which the link has been advertised with the attribute "link excluded from local protection path" or with the attribute "local maintenance required".
[RFC5029]は、その相互作用LFAsと定義される必要があるいくつかのフラグを記述する。ルータはLFAsを持っていることの結果として、「ローカル保護可能な」フラグを指定しないでください。ルータはリンクが属性「ローカル保護パスから除外リンク」または属性「必要なローカル保守」と宣伝されたリンクに沿っている代替のネクストホップを使用しないでください。
A router supporting this specification SHOULD attempt to select at least one loop-free alternate next-hop for each primary next-hop used for a given prefix. A router MAY decide to not use an available loop-free alternate next-hop. A reason for such a decision might be that the loop-free alternate next-hop does not provide protection for the failure scenario of interest.
この仕様をサポートするルータは、所定のプレフィクスのために使用される各一次次ホップのために少なくとも1つのループを含まない代替の次のホップを選択することを試みるべきです。ルータは、使用可能なループフリーの代替ネクストホップを使用しないことを決定することができます。そのような決定の理由は、ループフリーの代替ネクストホップが関心の障害シナリオのための保護を提供していないことかもしれません。
The alternate selection should maximize the coverage of the failure cases.
別の選択は失敗例カバレッジを最大化すべきです。
When calculating alternate next-hops, the calculating router S applies the following rules.
別のネクストホップを計算する場合、計算のルータのSは、次のルールが適用されます。
1. S SHOULD select a loop-free node-protecting alternate next-hop, if one is available. If no loop-free node-protecting alternate is available, then S MAY select a loop-free link-protecting alternate.
利用可能な場合1. Sは、ループフリーノード保護代替の次のホップを選択すべきです。何ループフリーノード保護代替が利用可能でない場合、Sはループフリーリンク保護の代替を選択することができます。
2. If S has a choice between a loop-free link-and-node-protecting alternate and a loop-free node-protecting alternate that is not link-protecting, S SHOULD select a loop-free link-and-node-protecting alternate. This can occur as explained in Section 3.3.
2. Sがループフリーリンク及びノード保護代替とリンク保護ないループフリーノード保護代替の選択がある場合、Sはループフリーリンク及びノード保護を選択すべきです代わりの。 3.3節で説明したようにこれが発生する可能性があります。
3. If S has multiple primary next-hops, then S SHOULD select as a loop-free alternate either one of the other primary next-hops or a loop-free node-protecting alternate if available. If no loop-free node-protecting alternate is available and no other primary next-hop can provide link-protection, then S SHOULD select a loop-free link-protecting alternate.
3. Sは、複数の一次次ホップがある場合、Sはループのない代替の他の一次次ホップの一つまたはループフリーノード保護の代替可能な場合のいずれかとして選択すべきです。何ループフリーノード保護代替が利用可能でなく、他の一次次ホップリンク保護を提供することができない場合、Sはループフリーリンク保護の代替を選択すべきです。
4. Implementations SHOULD support a mode where other primary next-hops satisfying the basic loop-free condition and providing at least link or node protection are preferred over any non-primary alternates. This mode is provided to allow the administrator to preserve traffic patterns based on regular ECMP behavior.
4.実装は、任意の非プライマリ交互より好ましい他の一次次ホップは、基本的なループフリー条件を満足し、少なくともリンクまたはノードの保護を提供するモードをサポートする必要があります。このモードは、通常のECMPの挙動に基づいてトラフィックパターンを維持するために管理者を可能にするために設けられています。
5. Implementations considering SRLGs MAY use SRLG protection to determine that a node-protecting or link-protecting alternate is not available for use.
SRLGsを考慮5.実装は、ノード保護またはリンク保護の代替が使用可能でないことを決定するために、SRLGの保護を使用するかもしれません。
Following the above rules maximizes the level of protection and use of primary (ECMP) next-hops.
上記の規則に従うことで保護し、プライマリ（ECMP）を使用する次ホップのレベルを最大にします。
Each next-hop is associated with a set of non-mutually-exclusive characteristics based on whether it is used as a primary next-hop to a particular destination D, and the type of protection it can provide relative to a specific primary next-hop E:
各次ホップは、それが特定の宛先Dへのプライマリのネクストホップとして使用されているか否かに基づいて、非相互排他的な特性の組、およびそれが特異的な一次ネクストホップに対して提供することができる保護のタイプに関連付けられていますE：
Primary Path - The next-hop is used by S as primary.
プライマリパス - ネクストホップは、プライマリとしてSで使用されています。
Loop-Free Node-Protecting Alternate - This next-hop satisfies Inequality 1 and Inequality 3. The path avoids S, S's primary neighbor E, and the link from S to E.
ループフリーノード保護の代替 - このネクストホップ不等式1と不平等3.パスがS、Sの主な隣人E、およびEにSからのリンクを避け
Loop-Free Link-Protecting Alternate - This next-hop satisfies Inequality 1 but not Inequality 3. If the primary next-hop uses a broadcast link, then this next-hop satisfies Inequality 4.
ループフリーリンク保護代替 - このネクストホップ満たす不平等1ではなく、不平等3.プライマリのネクストホップは、ブロードキャストリンクは、このネクストホップ満たす不平等4を使用している場合。
An alternate path may also provide none, some, or complete SRLG protection as well as node and link or link protection. For instance, a link may belong to two SRLGs G1 and G2. The alternate path might avoid other links in G1 but not G2, in which case the alternate would only provide partial SRLG protection.
代替パスは、またどれ、一部、または完全なSRLG保護並びにノード及びリンク又はリンクの保護を提供しないことができます。例えば、リンクは、2つのSRLGs G1及びG2に属していてもよいです。代替パスは、代替のみ部分的SRLGの保護を提供するであろう場合には、G2 G1内の他のリンクを避けるためではなく、可能性があります。
Below is an algorithm that can be used to calculate loop-free alternate next-hops. The algorithm is given for informational purposes, and implementations are free to use any other algorithm as long as it satisfies the rules described above.
以下ループフリー代替のネクストホップを計算するために使用することができるアルゴリズムです。アルゴリズムは情報提供の目的のために与えられ、実装があれば、上述したルールを満たすように、他のアルゴリズムを使用して自由にされています。
The following procedure describes how to select an alternate next-hop. The procedure is described to determine alternate next-hops to use to reach each router in the topology. Prefixes that are advertised by a single router can use the alternate next-hop computed for the router to which they are attached. The same procedure can be used to reach a prefix that is advertised by more than one router when the logical topological transformation described in Section 6.1 is used.
次の手順では、代替のネクストホップを選択する方法について説明します。手順は、トポロジ内の各ルータに到達するために使用する代替次のホップを決定するために記載されています。単一ルータによってアドバタイズされたプレフィックスは、次のホップは、それらが結合しているルータに対して計算代替を使用することができます。同じ手順は、6.1節で説明した論理トポロジー的変換を使用する場合、複数のルータによってアドバタイズされたプレフィックスに到達するために使用することができます。
S is the computing router. S has neighbors N_1 to N_j. A candidate next-hop is indicated by (outgoing link, neighbor) and the outgoing link must be bidirectionally connected, as is determined by the IGP. The candidate next-hops of S are enumerated as H_1 through H_k. Recall that S may have multiple next-hops over different interfaces to a neighbor. H_i.link refers to the outgoing link of that next-hop and H_i.neighbor refers to the neighbor of that next-hop.
Sは、コンピューティング・ルータです。 SはN_jに隣人N_1を持っています。 IGPによって決定されるように、候補次ホップは、（発信リンク、ネイバー）と双方向に接続されている必要があり、送信リンクによって示されています。 Sの候補ネクストホップはなH_kてH_1として列挙されています。 Sは、隣接する異なるインタフェース上に複数の次ホップを有することができることを想起されたいです。 H_i.linkは、ネクストホップの発信リンクを参照しH_i.neighborは、ネクストホップの隣人を指します。
For a particular destination router D, let S have already computed D_opt(S, D), and for each neighbor N_i, D_opt(N_i, D), D_opt(N_i, S), and D_opt(N_i, N_j), the distance from N_i to each other neighbor N_j, and the set of SRLGs traversed by the path D_opt(N_i, D). S should follow the below procedure for every primary next-hop selected to reach D. This set of primary next-hops is represented P_1 to P_p. This procedure finds the alternate next-hop(s) for P_i.
特定の宛先ルータDは、Sが既にD_opt（S、D）を計算し、各隣接N_i、D_opt（N_i、D）、D_opt（N_i、S）、及びD_opt（N_i、N_j）から距離を持たせます互いに隣接N_j、パスD_opt（N_i、D）が横断SRLGsのセットにN_i。 D.主なネクストホップのこのセットに到達するために選択されたすべての主要なネクストホップがP_PにP_1を表現するためにSは、以下の手順に従ってください。この手順は、P_Iの代替のネクストホップ（S）を求めます。
First, initialize the alternate information for P_i as follows:
次のように最初、P_Iの代替情報を初期化します。
P_i.alt_next_hops = {} P_i.alt_type = NONE P_i.alt_link-protect = FALSE P_i.alt_node-protect = FALSE P_i.alt_srlg-protect = {}
P_i.alt_next_hopsの= {} P_i.alt_type = NONE P_i.alt_linkプロテクト= FALSE P_i.alt_nodeプロテクト= FALSE P_i.alt_srlgプロテクト= {}
For each candidate next-hop H_h,
各候補のネクストホップH_h、
cand_type = NONE
cand_link-protect = FALSE
cand_node-protect = FALSE
cand_srlg-protect = {}
2. If H_h is P_i, skip it and continue to the next candidate next-hop.
2. H_hがP_Iある場合は、それをスキップして、次の候補ネクストホップに進みます。
3. If H_h.link is administratively allowed to be used as an alternate,
3. H_h.linkは管理代替として使用することが許可されている場合、
and the cost of H_h.link is less than the maximum,
and the reverse cost of H_h is less than the maximum,
and H_h.neighbor is not overloaded (for IS-IS),
and H_h.link is bidirectional,
then H_h can be considered as an alternate. Otherwise, skip it and continue to the next candidate next-hop.
次いでH_h代替として考えることができます。それ以外の場合は、それをスキップして次の候補ネクストホップに進みます。
4. If D_opt( H_h.neighbor, D) >= D_opt( H_h.neighbor, S) + D_opt(S, D), then H_h is not loop-free. Skip it and continue to the next candidate next-hop.
4. D_opt（H_h.neighbor、D）> = D_opt（H_h.neighbor、S）+ D_opt（S、D）場合、H_hはループフリーではありません。それをスキップして次の候補ネクストホップに進みます。
8. If D_opt(H_h.neighbor, D) < D_opt(H_h.neighbor, P_i.neighbor) + D_opt(P_i.neighbor, D), set cand_node-protect to TRUE.
8. D_opt（H_h.neighbor、D）<D_opt（H_h.neighbor、P_i.neighbor）+ D_opt（P_i.neighbor、D）は、TRUEにプロテクトcand_nodeを設定した場合。
9. If the router considers SRLGs, then set the cand_srlg-protect to the set of SRLGs traversed on the path from S via P_i.link to P_i.neighbor. Remove the set of SRLGs to which H_h belongs from cand_srlg-protect. Remove from cand_srlg-protect the set of SRLGs traversed on the path from H_h.neighbor to D. Now cand_srlg-protect holds the set of SRLGs to which P_i belongs and that are not traversed on the path from S via H_h to D.
その後、9ルータがSRLGsを考慮した場合、SRLGsのセットにcand_srlg-保護を設定するには、P_i.neighborにP_i.linkを経由してSからのパスに横断しました。 H_hがcand_srlg-守るから所属するSRLGsのセットを削除します。削除cand_srlg-保護SRLGsのセットはD.へH_h.neighborからのパスにトラバースさて、保護cand_srlgはSRLGsのセットを保持しているP_Iが属するとDにH_hを経由してSからのパスでトラバースされていないことに
10. If cand_type is PRIMARY, the router prefers other primary next-hops for use as the alternate, and the P_i.alt_type is not PRIMARY, goto Step 20.
10. cand_typeがプライマリである場合、ルータは、代替として使用するための他の主要次のホップを好む、およびP_i.alt_typeは、Gotoステップ20 PRIMARYありません。
11. If cand_type is not PRIMARY, P_i.alt_type is PRIMARY, and the router prefers other primary next-hops for use as the alternate, then continue to the next candidate next-hop
11. cand_typeがプライマリでない場合、P_i.alt_typeが主であり、ルータは、代替として使用するための他の一次次ホップを優先し、その後、次のホップ次の候補に進み
12. If cand_node-protect is TRUE and P_i.alt_node-protect is FALSE, goto Paragraph 20.
12. cand_nodeプロテクトはTRUEであり、P_i.alt_nodeプロテクト場合FALSE、後藤段落20です。
13. If cand_link-protect is TRUE and P_i.alt_link-protect is FALSE, goto Step 20.
13. cand_linkプロテクトはTRUEであり、P_i.alt_linkプロテクト場合FALSE、Gotoステップ20です。
14. If cand_srlg-protect has a better set of SRLGs than P_i.alt_srlg-protect, goto Step 20.
14. cand_srlgプロテクトがP_i.alt_srlgがプロテクトよりSRLGs、Gotoステップ20のより良いセットを持っている場合。
15. If cand_srlg-protect is different from P_i.alt_srlg-protect, then select between H_h and P_i.alt_next_hops based upon distance, IP addresses, or any router-local tie-breaker. If H_h is preferred, then goto Step 20. If P_i.alt_next_hops is preferred, skip H_h and continue to the next candidate next-hop.
15.場合cand_srlgプロテクトする距離、IPアドレス、または任意のルータローカルタイブレーカ基づいH_hとP_i.alt_next_hops間で選択し、P_i.alt_srlgプロテクト異なります。 H_hが好ましい場合P_i.alt_next_hopsが好ましい場合には、ジャンプステップ20は、H_hをスキップして次の候補の次のホップを続けます。
16. If D_opt(H_h.neighbor, D) < D_opt(P_i.neighbor, D) and D_opt(P_i.alt_next_hops, D) >= D_opt(P_i.neighbor, D), then H_h is a downstream alternate and P_i.alt_next_hops is simply an LFA. Prefer H_h and goto Step 20.
D_opt（H_h.neighbor、D）<D_opt（P_i.neighbor、D）およびD_opt（P_i.alt_next_hops、D）> = D_opt（P_i.neighbor、D）であれば16、次いでH_h下流代替とP_i.alt_next_hopsあります単にLFAです。 H_hとGotoステップ20を好みます。
17. Based upon the alternate types, the alternate distances, IP addresses, or other tie-breakers, decide if H_h is preferred to P_i.alt_next_hops. If so, goto Step 20.
17. H_hがP_i.alt_next_hopsに好まれている場合、代替のタイプ、代替距離、IPアドレス、または他のタイブレーカーに基づいて、決定します。もしそうなら、Gotoステップ20。
18. Decide if P_i.alt_next_hops is preferred to H_h. If so, then skip H_h and continue to the next candidate next-hop.
P_i.alt_next_hopsがH_hに好ましい場合18が決めます。もしそうなら、H_hをスキップして、次の候補ネクストホップに進みます。
19. Add H_h into P_i.alt_next_hops. Set P_i.alt_type to the better type of H_h.alt_type and P_i.alt_type. Continue to the next candidate next-hop.
19. P_i.alt_next_hopsにH_hを追加します。 H_h.alt_typeとP_i.alt_typeのよりよいタイプにP_i.alt_typeを設定します。次の候補ネクストホップに進みます。
P_i.alt_next_hops = {H_h}
P_i.alt_type = cand_type
P_i.alt_link-protect = cand_link-protect
P_i.alt_node-protect = cand_node-protect
P_i.alt_srlg-protect = cand_srlg-protect
Continue to the next candidate next-hop.
次の候補ネクストホップに進みます。
LFAs can provide different amounts of protection, and the decision about which type to prefer is dependent upon network topology and other techniques in use in the network. This section describes the different protection levels and the trade-offs associated with each.
LFAsは、保護の異なる量を提供することができ、かつ好むタイプについての決定は、ネットワークトポロジとネットワークで使用されている他の技術に依存しています。このセクションでは、異なる保護レベルとそれぞれに関連するトレードオフについて説明します。
1. Primary Next-hop: When there are equal-cost primary next-hops, using one as an alternate is guaranteed not to cause micro-loops involving S. Traffic flows across the paths that the network will converge to, but congestion may be experienced on the primary paths since traffic is sent across fewer. All primary next-hops are downstream paths.
1.プライマリネクストホップ：等価コストプライマリネクストホップがある場合、代替としていずれかを使用すると、ネットワークはに収束するパス全体S.トラフィックフローを含むマイクロループが発生しないことが保証されるが、輻輳があってもよいですトラフィックが少ない介して送信されるので、プライマリパスに経験しました。すべての主要なネクストホップは、下流のパスです。
2. Downstream Paths: A downstream path, unlike an LFA, is guaranteed not to cause a micro-loop involving S regardless of the actual failure detected. However, the expected coverage of such alternates in a network is expected to be poor. All downstream paths are LFAs.
2.ダウンストリームパス：ダウンストリームパスは、LFAとは異なり、関係なく検出された実際の故障のSを含むマイクロループが発生しないことが保証されます。しかし、ネットワーク内のそのような交互の予想カバレッジが貧弱であると予想されます。すべてのダウンストリームパスがLFAsです。
3. LFA: An LFA can have good coverage of a network, depending on topology. However, it is possible to get micro-loops involving S if an unprotected failure occurs (e.g., a node fails when the LFA only was link-protecting).
3. LFA：LFAは、トポロジに応じて、ネットワークの良好なカバレッジを持つことができます。しかし、保護されていない障害が発生した場合、Sを含むマイクロループを取得することが可能である（例えば、ノードは、LFAのみリンク保護たとき失敗します）。
The different types of protection are abbreviated as LP (link-protecting), NP (node-protecting), and SP (SRLG-protecting).
保護の異なるタイプのLP（リンク保護）、NP（ノード保護）、およびSP（SRLG保護）と略記されます。
a. LP, NP, and SP: If such an alternate exists, it gives protection against all failures.
A。 LP、NP、およびSPは：そのような代替が存在する場合、それはすべての障害に対する保護を提供します。
b. LP and NP only: Many networks may handle SRLG failures via another method or may focus on node and link failures as being more common.
B。 LPおよびNPのみ：多くのネットワークは、他の方法を介して、SRLGの障害を処理することができるか、より一般的であるようにノード及びリンク障害に焦点を当てることができます。
c. LP only: A network may handle node failures via a high-availability technique and be concerned primarily about protecting the more common link failure case.
C。 LPのみ：ネットワークは、高可用性技術を介してノード障害を処理し、主に、より一般的なリンク障害ケースを保護する心配であってもよいです。
d. NP only: These only exist on interfaces that aren't point-to-point. If link protection is handled in a different layer, then an NP alternate may be acceptable.
D。 NPのみ：これらは、ポイントツーポイントされていないインターフェイス上に存在します。リンク保護が異なる層で処理される場合、NPの代替は、許容可能であり得ます。
It is possible to simplify the computation and use of LFAs when solely link protection is desired by considering and computing only one link-protecting LFA for each next-hop connected to the router. All prefixes that use that next-hop as a primary will use the LFA computed for that next-hop as its LFA.
単にリンク保護は、1つのリンクだけ保護ルータに接続された各次のホップのためにLFAを考慮し、計算することによって、所望される場合LFAsの計算および使用を簡素化することができます。プライマリとしてその次のホップを使用するすべてのプレフィックスは、そのLFAとしてその次のホップのために計算されたLFAを使用します。
Even a prefix with multiple primary next-hops will have each primary next-hop protected individually by the primary next-hop's associated LFA. That associated LFA might or might not be another of the primary next-hops of the prefix.
複数のプライマリネクストホップでさえ、接頭辞は、プライマリネクストホップの関連LFAによって個別に保護された各プライマリネクストホップを持つことになります。それに関連するLFAは、またはプレフィックスの主なネクストホップの他にはならない場合があります。
This simplification may reduce coverage in a network. In addition to limiting protection for multi-homed prefixes (see Section 6.1), the computation per next-hop may also not find an LFA when one could be found for some of the prefixes that use that next-hop.
この単純化は、ネットワーク内のカバレッジを減らすことができます。 1は、その次のホップを使用するプレフィックスのいくつかのために見つけることができるとき（6.1節を参照）マルチホームプレフィックスの保護を制限することに加えて、ネクストホップあたりの計算はまた、LFAを見つけられないことがあります。
For example, consider Figure 4 where S has three ECMP next-hops, E1, E2, and E3 to reach D. For the prefix D, E3 can give link protection for the next-hops E1 and E2; E1 and E2 can give link protection for the next-hops E3. However, if one uses this simplification to compute LFAs for E1, E2, and E3 individually, there is no link-protecting LFA for E1. E3 and E2 can protect each other.
例えば、Sは、接頭辞DのD.に到達するために、E1、E2、およびE3の3 ECMP次ホップを有する図4は、E3は、ネクストホップE1およびE2のリンク保護を与えることができる考えます。 E1およびE2は、ネクストホップE3用のリンク保護を与えることができます。 1を個別にE1、E2、およびE3用のLFAsを計算するために、この単純化を使用する場合は、何のリンク保護E1のためのLFAはありません。 E3およびE2は、お互いを保護することができます。
If an alternate next-hop is available, the router redirects traffic to the alternate next-hop in case of a primary next-hop failure as follows.
ネクストホップの代替が利用可能である場合、以下のように、ルータは、プライマリネクストホップ障害が発生した場合の代替の次のホップにトラフィックをリダイレクトします。
When a next-hop failure is detected via a local interface failure or other failure detection mechanisms (see [FRAMEWORK]), the router SHOULD:
ネクストホップ障害がローカルインタフェースの障害または他の障害検出メカニズムを介して検出された場合、ルータはSHOULD（[FRAMEWORK]参照）。
2. Install the loop-free alternate calculated for the failed next-hop if it is not already installed (e.g., the alternate is also a primary next-hop).
2.既にインストールされていない場合は失敗したネクストホップについて計算ループフリーの代替をインストールする（例えば、代替の一次次のホップです）。
Note that the router MAY remove other next-hops if it believes (via SRLG analysis) that they may have been affected by the same failure, even if it is not visible at the time of failure detection.
それは、障害検出時に表示されていない場合でも、それは彼らが同じ障害の影響を受けてきたこと（SRLG分析を経由して）と考えている場合、ルータは他のネクストホップを削除することがあります。
The alternate next-hop MUST be used only for traffic types that are routed according to the shortest path. Multicast traffic is specifically out of scope for this specification.
代替のネクストホップのみ最短経路に従ってルーティングされるトラフィックのタイプに使用されなければなりません。マルチキャストトラフィックは、この仕様の範囲外、具体的です。
A router MUST limit the amount of time an alternate next-hop is used after the primary next-hop has become unavailable. This ensures that the router will start using the new primary next-hops. It ensures that all possible transient conditions are removed and the network converges according to the deployed routing protocol.
ルータは、プライマリネクストホップが利用できなくなった後、代替のネクストホップが使用される時間の量を制限しなければなりません。これは、ルータが新しいプライマリネクストホップを使用して開始することを保証します。これは、すべての可能な過渡状態が除去されることを保証し、ネットワークが展開ルーティングプロトコルに応じて収束します。
There are techniques available to handle the micro-forwarding loops that can occur in a networking during convergence.
収束時のネットワークで発生する可能性がマイクロ転送ループを処理するために利用できる技術があります。
A router that implements [MICROLOOP] SHOULD follow the rules given there for terminating the use of an alternate.
【MICROLOOP】実装するルータは、代替の使用を終了するためにそこに与えられた規則に従うべきです。
A router that implements [ORDERED-FIB] SHOULD follow the rules given there for terminating the use of an alternate.
実装[ORDERED-FIB]は、代替の使用を終了するためにそこに与えられた規則に従うべきであるルータ。
It is desirable to avoid micro-forwarding loops involving S. An example illustrating the problem is given in Figure 5. If the link from S to E fails, S will use N1 as an alternate and S will compute N2 as the new primary next-hop to reach D. If S starts using N2 as soon as S can compute and install its new primary, it is probable that N2 will not have yet installed its new primary next-hop. This would cause traffic to loop and be dropped until N2 has installed the new topology. This can be avoided by S delaying its installation and leaving traffic on the alternate next-hop.
SからEへのリンクに障害が発生した場合、図5に示され、Sは、代替としてN1を使用し、Sは、新しいプライマリネクストとしてN2を計算する問題を示すS.を含むマイクロ転送ループを例を回避することが望ましいですSはSを計算し、その新しいプライマリをインストールすることができ次第、N2を使用して起動した場合はDまでホップ、N2が、まだその新しいプライマリのネクストホップをインストールしていない可能性が高いです。これは、ループへのトラフィックを引き起こすとN2は、新しいトポロジをインストールするまで落とされます。これは、Sは、その設置を遅らせ、代替のネクストホップ上のトラフィックを残すことによって回避することができます。
+-----+
| N2 |-------- |
+-----+ 1 | \|/
| |
| +-----+ @@> +-----+
| | S |---------| N1 |
10 | +-----+ 10 +-----+
| | |
| 1 | | |
| | \|/ 10 |
| +-----+ | |
| | E | | \|/
| +-----+ |
| | |
| 1 | | |
| | \|/ |
| +-----+ |
|----| D |--------------
+-----+
Figure 5: Example Where Continued Use of Alternate Is Desirable
図5：例代替の継続使用が望ましいです
This is an example of a case where the new primary is not a loop-free alternate before the failure and therefore may have been forwarding traffic through S. This will occur when the path via a previously upstream node is shorter than the path via a loop-free alternate neighbor. In these cases, it is useful to give sufficient time to ensure that the new primary neighbor and other nodes on the new primary path have switched to the new route.
これは、新しいプライマリが故障する前にループフリーの代替ではない場合の例であり、以前に上流のノードを介して経路がループを介してパスよりも短い場合従ってS.このを通じてトラフィックを転送されていてもよいして発生しますフリー代替隣人。これらのケースでは、新しいプライマリパス上の新しいプライマリ隣人と他のノードが新しい経路に切り替えていることを確実にするために十分な時間を与えるために有用です。
If the newly selected primary was loop-free before the failure, then it is safe to switch to that new primary immediately; the new primary wasn't dependent on the failure and therefore its path will not have changed.
新しく選択されたプライマリが故障する前にループフリーだった場合、すぐにその新しい主に切り替えることが安全です。新しいプライマリが障害に依存しなかったため、そのパスが変更されていません。
Given that there is an alternate providing appropriate protection and while the assumption of a single failure holds, it is safe to delay the installation of the new primaries; this will not create forwarding loops because the alternate's path to the destination is known to not go via S or the failed element and will therefore not be affected by the failure.
そこに適切な保護を提供する代替であり、単一故障の仮定が保持している間、新しい原色のインストールを遅らせるために安全であることを考えます。これは、宛先への代替の経路がSを介して移動したか失敗した要素ではないことが知られている、したがって、故障によって影響されないため、転送ループを作成しないであろう。
An implementation SHOULD continue to use the alternate next-hops for packet forwarding even after the new routing information is available based on the new network topology. The use of the alternate next-hops for packet forwarding SHOULD terminate:
実装も新しいルーティング情報は、新たなネットワークトポロジに基づいて、利用可能になった後、パケット転送のための代替の次のホップを使用し続けなければなりません。ネクストホップパケット転送のための代替の使用を終了する必要があります。
a. if the new primary next-hop was loop-free prior to the topology change, or
A。新しいプライマリネクストホップはループフリートポロジーの変更に先立っていた場合、または
b. if a configured hold-down, which represents a worst-case bound on the length of the network convergence transition, has expired, or
B。最悪の場合を表す構成ホールドダウンは、ネットワーク収束遷移の長さに結合した場合、有効期限が切れている、または
c. if notification of an unrelated topological change in the network is received.
C。ネットワーク内の無関係なトポロジカル変更の通知を受信した場合。
Since LDP [RFC5036] traffic will follow the path specified by the IGP, it is also possible for the LDP traffic to follow the loop-free alternates indicated by the IGP. To do so, it is necessary for LDP to have the appropriate labels available for the alternate so that the appropriate out-segments can be installed in the forwarding plane before the failure occurs.
LDP [RFC5036]トラフィックは、IGPによって指定された経路をたどるのでLDPトラフィックはIGPによって示されるループフリー交互に追従する、ことも可能です。 LDPは、障害が発生する前に適切な外セグメントが転送プレーンに設置することができるように、代替のために使用可能な適切なラベルを持っているためにそうすることが必要です。
This means that a Label Switching Router (LSR) running LDP must distribute its labels for the Forwarding Equivalence Classes (FECs) it can provide to all its neighbors, regardless of whether or not they are upstream. Additionally, LDP must be acting in liberal label retention mode so that the labels that correspond to neighbors that aren't currently the primary neighbor are stored. Similarly, LDP should be in downstream unsolicited mode, so that the labels for the FEC are distributed other than along the SPT.
これは自民党が転送等価クラス（FEC）にのためにそのラベルを配布する必要があります実行しているラベルスイッチングルータ（LSR）が、それは関係なく、上流にあるかどうかの、すべての隣人に提供できることを意味します。現在、主要な隣人でない隣人に対応したラベルが格納されているように、また、LDPは、リベラルラベル保持モードで動作している必要があります。 FECのためのラベルがSPTに沿って以外に分布するように同様に、LDPは、下流迷惑モードであるべきです。
If these requirements are met, then LDP can use the loop-free alternates without requiring any targeted sessions or signaling extensions for this purpose.
これらの要件が満たされている場合は、LDPは、任意の対象のセッションを必要とするか、この目的のために拡張をシグナリングなしループフリー交互に使用することができます。
An SPF-like computation is run for each topology, which corresponds to a particular OSPF area or IS-IS level. The IGP needs to determine loop-free alternates to multi-homed routes. Multi-homed routes occur for routes obtained from outside the routing domain by multiple routers, for subnets on links where the subnet is announced from multiple ends of the link, and for routes advertised by multiple routers to provide resiliency.
SPFのような計算は、特定のOSPFエリアに対応するまたはレベル-IS各トポロジーのために実行されます。 IGPは、マルチホームルートにループフリー交互に決定する必要があります。マルチホームルート複数のルータによりルーティングドメイン外部から取得したルートの、サブネットはリンクの複数の端部から発表されているリンク上のサブネットのため、および弾力性を提供するために、複数のルータによってアドバタイズされたルートのために起こります。
Figure 6 demonstrates such a topology. In this example, the shortest path to reach the prefix p is via E. The prefix p will have the link to E as its primary next-hop. If the alternate next-hop for the prefix p is simply inherited from the router advertising it on the shortest path to p, then the prefix p's alternate next-hop would be the link to C. This would provide link protection, but not the node protection that is possible via A.
図6は、このようなトポロジを示しています。この例では、プレフィックスPに到達する最短経路プレフィックスPは、その一次ネクストホップとしてEへのリンクを有することになるE.を介してです。プレフィックスPのための代替のネクストホップは単にpまでの最短経路上のルータ広告からそれを継承している場合、プレフィックスPの代替ネクストホップは、これはリンク保護を提供するC.へのリンクではなく、ノードになりますA.を介して可能である保護
5 +---+ 8 +---+ 5 +---+
------| S |------| A |-----| B |
| +---+ +---+ +---+
| | |
| 5 | 5 |
| | |
+---+ 5 +---+ 5 7 +---+
| C |---| E |------ p -------| F |
+---+ +---+ +---+
Figure 6: Multi-Homed Prefix
図6：マルチホームプレフィックス
To determine the best protection possible, the prefix p can be treated in the SPF computations as a node with unidirectional links to it from those routers that have advertised the prefix. Such a node need never have its links explored, as it has no out-going links.
可能な限り最高の保護を決定するには、接頭辞pはプレフィックスを宣伝しているそれらのルータから、それまでの単方向リンクを持つノードとしてSPF計算で処理することができます。それは、アウトゴーイングリンクを持っていないようなノードは、そのリンクが調査していません必要は。
If there exist multiple multi-homed prefixes that share the same connectivity and the difference in metrics to those routers, then a single node can be used to represent the set. For instance, if in Figure 6 there were another prefix X that was connected to E with a metric of 1 and to F with a metric of 3, then that prefix X could use the same alternate next-hop as was computed for prefix p.
同じ接続およびそれらのルータへのメトリックの差を共有する複数のマルチホームプレフィックスが存在する場合、単一のノードセットを表すために使用することができます。例えば、図6の場合は3のメトリック、プレフィックスPについて計算したように、そのプレフィックスXは、同じ代替のネクストホップを使用することができると1のメトリックとし、FをEに接続された別のプレフィックスXがありました。
A router SHOULD compute the alternate next-hop for an IGP multi-homed prefix by considering alternate paths via all routers that have announced that prefix.
ルータは、プレフィックスと発表したすべてのルータを経由して代替パスを考慮してIGPマルチホームプレフィックスの代替のネクストホップを計算すべきです。
In all cases, a router MAY safely simplify the multi-homed prefix (MHP) calculation by assuming that the MHP is solely attached to the router that was its pre-failure optimal point of attachment. However, this may result in a prefix not being considered repairable, when the full computation would show that a repair was possible.
全ての場合において、ルータは、安全MHPは単にアタッチメントのその前故障最適点であったルータに接続されていることを仮定することにより、マルチホームプレフィックス（MHP）の計算を単純化することができます。しかし、これは完全な計算は修復が可能であったことを示しているだろうというとき、修理考慮されていない接頭辞をもたらすことができます。
The applicability and interactions of LFAs with multi-topology IS-IS [RFC5120] is out of scope for this specification.
マルチトポロジがIS-IS [RFC5120]と適用とLFAsの相互作用は、本明細書の範囲外です。
OSPF introduces certain complications because it is possible for the traffic path to exit an area and then re-enter that area. This can occur whenever a router considers the same route from multiple areas. There are several cases where issues such as this can occur. They happen when another area permits a shorter path to connect two ABRs than is available in the area where the LFA has been computed. To clarify, an example topology is given in Appendix A.
トラフィックパスは、面積を終了し、その領域を再入力することが可能であるため、OSPFは、特定の合併症を紹介します。ルータが複数の領域から同じルートを考慮したときにこれが発生する可能性があります。このような問題が発生する可能性がありますいくつかの例があります。他のエリアは、LFAが計算されたエリアで利用可能であるよりも、2つのABRを接続する短いパスを許可するとき、彼らが起こります。明確にするために、トポロジの例は、付録Aに記載されています
a. Virtual Links: These allow paths to leave the backbone area and traverse the transit area. The path provided via the transit area can exit via any ABR. The path taken is not the shortest path determined by doing an SPF in the backbone area.
A。仮想リンク：これらは、パスはバックボーンエリアを離れ、トランジットエリアを通過することができます。通過領域を介して提供されるパスは、任意のABRを介して出ることができます。撮影したパスは、バックボーンエリアでのSPFを行うことによって決定された最短経路ではありません。
b. Alternate ABR [RFC3509]: When an ABR is not connected to the backbone, it considers the inter-area summaries from multiple areas. The ABR A may determine to use area 2 but that path could traverse another alternate ABR B that determines to use area 1. This can lead to scenarios similar to that illustrated in Figure 7.
B。代替ABR [RFC3509]：ABRは、バックボーンに接続されていない場合には、複数のエリアからエリア間の要約を考慮する。 ABR Aは領域2を使用することを決定してもよいが、その経路は、図7に示したものと同様のシナリオにつながる可能領域1にこれを使用することを決定する別の代替のABR Bを横断する可能性があります。
c. ASBR Summaries: An ASBR may itself be an ABR and can be announced into multiple areas. This presents other ABRs with a decision as to which area to use. This is the example illustrated in Figure 7.
C。 ASBRサマリー：ASBR自体はABRとすることができ、複数のエリアに発表されることができます。これは、使用するエリアを判定して他のABRを提示します。これは、図7に示した例です。
d. AS External Prefixes: A prefix may be advertised by multiple ASBRs in different areas and/or with multiple forwarding addresses that are in different areas, which are connected via at least one common ABR. This presents such ABRs with a decision as to which area to use to reach the prefix.
D。外部プレフィックスAS：プレフィックスおよび/または少なくとも一つの共通ABRを介して接続されている異なる領域内にある複数の転送アドレスと異なる領域に複数のASBRによってアドバタイズされてもよいです。これは、接頭辞に到達するために使用するエリアを判定して、そのようなのABRを提示します。
Loop-free alternates should not be used in an area where one of the above issues affects that area.
ループフリー交互には、上記の課題の一つは、その領域に影響を与える領域で使用すべきではありません。
When a forwarding address is set in an OSPF AS-external Link State Advertisement (LSA), all routers in the network calculate their next-hops for the external prefix by doing a lookup for the forwarding address in the routing table, rather than using the next-hops calculated for the ASBR. In this case, the alternate next-hops SHOULD be computed by selecting among the alternate paths to the forwarding link(s) instead of among alternate paths to the ASBR.
転送先アドレスは、OSPF AS外部リンクステートアドバタイズメント（LSA）に設定されている場合は、ネットワーク内のすべてのルータは、ルーティングテーブルに転送アドレスのルックアップを行うのではなく、使用して、外部プレフィックスのための彼らの次のホップを計算しますASBRのために計算された次ホップ。この場合には、代替のネクストホップ代わりASBRへの代替パス間の転送リンク（単数または複数）への代替パス間で選択することによって、計算されるべきです。
The applicability and interactions of LFAs with multi-topology OSPF [RFC4915] [MT-OSPFv3] is out of scope for this specification.
LFAsの適用と相互作用マルチトポロジーOSPF [RFC4915] [MT-OSPFv3のこの仕様の範囲外です。
Typically, BGP prefixes are advertised with the AS exit router's router-id as the BGP next-hop, and AS exit routers are reached by means of IGP routes. BGP resolves its advertised next-hop to the immediate next-hop by potential recursive lookups in the routing database. IP Fast Reroute computes the alternate next-hops to all IGP destinations, which include alternate next-hops to the AS exit router's router-id. BGP simply inherits the alternate next-hop from IGP. The BGP decision process is unaltered; BGP continues to use the IGP optimal distance to find the nearest exit router. Multicast BGP (MBGP) routes do not need to copy the alternate next-hops.
典型的には、BGPプレフィクスは、BGPネクストホップとしてASの出口ルータのルータIDでアドバタイズされ、出口ルータはIGP経路によって到達された通りです。 BGPは、ルーティングデータベースにおける潜在的再帰ルックアップすることによって直ちに次ホップへのアドバタイズネクストホップを解決します。 IP高速リルートは、AS出口ルータのルータIDへの代替ネクストホップが含まれるすべてのIGPの宛先に別のネクストホップを計算します。 BGPは、単に、IGPから代替の次のホップを継承します。 BGP決定プロセスは不変です。 BGPは、最寄りの出口ルーターを見つけるために、IGP最適な距離を継続して使用します。マルチキャストBGP（MBGP）ルートは、代替ネクストホップをコピーする必要はありません。
It is possible to provide ASBR protection if BGP selected a set of BGP next-hops and allowed the IGP to determine the primary and alternate next-hops as if the BGP route were a multi-homed prefix. This is for future study.
BGPは、BGPネクストホップのセットを選択し、BGPルートがマルチホームプレフィックスであるかのようにIGPは、一次および代替次のホップを決定するために許可されている場合には、ASBR保護を提供することが可能です。これは今後の検討課題です。
Multicast traffic is out of scope for this specification of IP Fast Reroute. The alternate next-hops SHOULD NOT be used for multicast Reverse Path Forwarding (RPF) checks.
マルチキャストトラフィックは、IP高速リルートのこの仕様の範囲外です。代替のネクストホップマルチキャストリバースパス転送（RPF）チェックには使用できません。
The mechanism described in this document does not modify any routing protocol messages, and hence no new threats related to packet modifications or replay attacks are introduced. Traffic to certain destinations can be temporarily routed via next-hop routers that would not be used with the same topology change if this mechanism wasn't employed. However, these next-hop routers can be used anyway when a different topological change occurs, and hence this can't be viewed as a new security threat.
この文書で説明するメカニズムは、任意のルーティングプロトコルメッセージを変更しない、したがって、パケットの修正やリプレイ攻撃に関連した新たな脅威が導入されていません。特定の宛先へのトラフィックが一時的にこのメカニズムが採用されなかった場合にも、同じトポロジの変更では使用できませんネクストホップルータを経由してルーティングすることができます。異なるトポロジカル変更が発生した場合しかし、これらのネクストホップルータはとにかく使用することができるので、これは新たなセキュリティ上の脅威と見なすことはできません。
In LDP, the wider distribution of FEC label information is still to neighbors with whom a trusted LDP session has been established. This wider distribution and the recommendation of using liberal label retention mode are believed to have no significant security impact.
自民党では、FECラベル情報の広い分布は、信頼LDPセッションが確立されてきた人と隣人にまだあります。この広い分布とリベラルラベル保持モードを使用しての勧告は、有意なセキュリティ影響を与えないと考えられています。
The authors would like to thank Joel Halpern, Mike Shand, Stewart Bryant, and Stefano Previdi for their assistance and useful review.
著者は、彼らの支援と便利なレビューのためにジョエル・ハルパーン、マイク・シャンド、スチュワートブライアント、とステファノ・Previdiに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740] Coltun、R.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、RFC 2740、1999年12月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、Minei、I.、およびB.トーマス、 "LDP仕様"、RFC 5036、2007年10月。
[FRAMEWORK] Shand, M. and S. Bryant, "IP Fast Reroute Framework", Work in Progress, February 2008.
[フレームワーク]シャンド、M.とS.ブライアント、「IP高速リルートフレームワーク」、進歩、2008年2月に作業。
[MICROLOOP] Zinin, A., "Analysis and Minimization of Microloops in Link-state Routing Protocols", Work in Progress, October 2005.
[MICROLOOP]ジニン、A.、「分析およびリンクステートルーティングプロトコルでMicroloopsの最小化」、進歩、2005年10月に作業。
[MT-OSPFv3] Mirtorabi, S. and A. Roy, "Multi-topology routing in OSPFv3 (MT-OSPFv3)", Work in Progress, July 2007.
[MT-のOSPFv3] Mirtorabi、S.およびA.ロイ、 "OSPFv3の（MT-のOSPFv3）におけるマルチトポロジルーティング"、進歩、2007年7月の作業。
[ORDERED-FIB] Francois, P., "Loop-free convergence using oFIB", Work in Progress, February 2008.
[ORDERED-FIB]フランソワ、P.、 "oFIBを使用してループフリーコンバージェンス"、進歩、2008年2月に作業。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[RFC2966]李、T.、Przygienda、T.、およびH.スミット、RFC 2966、2000年10月の "2レベルでドメイン全体のプレフィックス配布は-IS IS"。
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[RFC3137] Retana、A.、グエン、L.、ホワイト、R.、ジニン、A.、およびD.マクファーソン、 "OSPFスタブルータアドバタイズメント"、RFC 3137、2001年6月。
[RFC3509] Zinin, A., Lindem, A., and D. Yeung, "Alternative Implementations of OSPF Area Border Routers", RFC 3509, April 2003.
[RFC3509]ジニン、A.、Lindem、A.、およびD.ヨン、RFC 3509、2003年4月 "OSPFエリア境界ルータの代替実装"。
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.とY. Rekhter、RFC 4203、 "（GMPLS）をスイッチング汎用マルチプロトコルラベルのサポートでOSPF拡張機能" を2005年10月。
[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4205] Kompella、K.とY. Rekhter、 "中間システムへの中間システムは、（IS-IS）一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで拡張機能"、RFC 4205、2005年10月。
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[RFC4915] Psenak、P.、Mirtorabi、S.、ロイ、A.、グエン、L.、およびP. Pillay-Esnault、 "OSPFにおけるマルチトポロジー（MT）ルーティング"、RFC 4915、2007年6月。
[RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link Attribute Sub-TLV", RFC 5029, September 2007.
[RFC5029] Vasseur、JP。そして、S. Previdiは、RFC 5029、2007年9月 "IS-ISリンクの定義は、サブTLV属性"。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120] Przygienda、T.、シェン、N.、およびN. Shethは、 "M-ISIS：中間システムへの中間システムにおけるマルチトポロジー（MT）ルーティング（IS-ISS）"、RFC 5120、2008年2月。
[RFC5340] Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
Appendix A. OSPF Example Where LFA Based on Local Area Topology Is Insufficient
LFAローカルエリアトポロジに基づいて付録A. OSPF例が不足しています
This appendix provides an example scenario where the local area topology does not suffice to determine that an LFA is available. As described in Section 6.3, one problem scenario is for ASBR summaries where the ASBR is available in two areas via intra-area routes and there is at least one ABR or alternate ABR that is in both areas. The following Figure 7 illustrates this case.
この付録では、ローカル・エリア・トポロジはLFAが利用可能であることを決定するために十分ではない例示的なシナリオを提供します。セクション6.3で説明したように、一つの問題シナリオは、ASBRは、エリア内の経路を介して二つの領域で提供され、両方の領域にある少なくとも一つのABRまたは代替ABRがあるASBR要約するためのものです。次の図7は、この場合を示しています。
5
[ F ]-----------[ C ]
| |
| | 5
20 | 5 | 1
| [ N ]-----[ A ]*****[ F ]
| | # *
| 40 | # 50 * 2
| | 5 # 2 *
| [ S ]-----[ B ]*****[ G ]
| | *
| 5 | * 15
| | *
| [ E ] [ H ]
| | *
| 5 | * 10**
| | *
|---[ X ]----[ ASBR ]
5
---- Link in Area 1
**** Link in Area 2
#### Link in Backbone Area 0
Figure 7: Topology with Multi-Area ASBR Causing Area Transiting
図7：地域移行の原因となるマルチエリアASBRとトポロジ
In Figure 7, the ASBR is also an ABR and is announced into both area 1 and area 2. A and B are both ABRs that are also connected to the backbone area. S determines that N can provide a loop-free alternate to reach the ASBR. N's path goes via A. A also sees an intra-area route to ASBR via area 2; the cost of the path in area 2 is 30, which is less than 35, the cost of the path in area 1. Therefore, A uses the path from area 2 and directs traffic to F. The path from F in area 2 goes to B. B is also an ABR and learns the ASBR from both areas 1 and area 2; B's path via area 1 is shorter (cost 20) than B's path via area 2 (cost 25). Therefore, B uses the path from area 1 that connects to S.
図7に、ASBRはまた、ABRであり、領域1と領域2のA及びBの両方にもバックボーンエリアに接続されている両方のABRであると発表されています。 S NはASBRに到達するためにループフリーの代替を提供することができると判断します。 Nの経路は、領域2を介して、ASBRにエリア内のルートを見ても、A. Aを介して進みます。領域2におけるパスのコストは35未満、したがって、領域1のパスのコストは30であり、Aがエリア2からパスを使用し、2に進む領域にFにFからパストラフィックを向けますB. Bはまた、ABRであり、両方の領域1及び領域2からASBRを学習します。領域1を介してBの経路は、領域2（25費用）を介してBのパスよりも短い（コスト20）です。したがって、Bは、Sに接続領域1からのパスを使用し
Authors' Addresses
著者のアドレス
Alia K. Atlas (editor) BT
アリアアトラスK.（編集者）BT
EMail: alia.atlas@bt.com
メールアドレス：alia.atlas@bt.com
Alex Zinin (editor) Alcatel-Lucent 750D Chai Chee Rd, #06-06 Technopark@ChaiChee Singapore 469004
アレックスジニン（編集者）アルカテル・ルーセント750DチャイチーRdを、＃06-06テクノ@ ChaiCheeシンガポール469004
EMail: alex.zinin@alcatel-lucent.com
メールアドレス：alex.zinin@alcatel-lucent.com
Raveendra Torvi FutureWei Technologies Inc. 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
Raveendra Torvi FutureWeiテクノロジーズ株式会社1700アルマ博士スイート100プラノ、TX 75075 USA
EMail: traveendra@huawei.com
メールアドレス：traveendra@huawei.com
Gagan Choudhury AT&T 200 Laurel Avenue, Room D5-3C21 Middletown, NJ 07748 USA
GAGANチョードリーAT＆T 200ローレルアベニュー、ルームD5-3C21ミドルタウン、NJ 07748 USA
Phone: +1 732 420-3721 EMail: gchoudhury@att.com
電話：+1 732 420-3721 Eメール：gchoudhury@att.com
Christian Martin iPath Technologies
クリスチャン・マーティンIPATHテクノロジーズ
EMail: chris@ipath.net
メールアドレス：chris@ipath.net
Brent Imhoff Juniper Networks 1194 North Mathilda Sunnyvale, CA 94089 USA
ブレントImhoff氏ジュニパーネットワークスの1194北マチルダサニーベール、CA 94089 USA
Phone: +1 314 378 2571 EMail: bimhoff@planetspork.com
電話：+1 314 378 2571 Eメール：bimhoff@planetspork.com
Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01821 USA
ドン・ルブランNortel Networksの600テクノロジーパーク、ビレリカ、MA 01821 USA
Phone: +1 978 288 3041 EMail: dwfedyk@nortelnetworks.com
電話：+1 978 288 3041 Eメール：dwfedyk@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。