[要約] RFC 5286は、IP Fast Reroute（IP FRR）の基本仕様であり、ループフリーな代替経路を提供することを目的としています。このRFCは、ネットワークの冗長性と信頼性を向上させるためのガイドラインを提供します。
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
IP高速ルートの基本仕様：ループフリーの代替
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.
Voice over 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.
[フレームワーク]で説明したように、トラフィックの損失を最小限に抑えるには、修復パスを迅速に呼び出せないことに隣接するルーターのメカニズムが必要です。これは、その後の再構成によって最小限に影響されます。この仕様は、ルーターが変更されたネットワークトポロジに基づいて新しいプライマリネクストホップをインストールするまで、ローカルリンクが事前に計算された代替にトラフィックを転送できなかったルーターを可能にするこのようなメカニズムを説明しています。この仕様で使用される用語は、[フレームワーク]に記載されています。記載されているメカニズムは、ネットワーク内のルーティングがリンク状態ルーティングプロトコル - OSPF [RFC2328] [RFC2740] [RFC5340]またはIS-IS [RFC1195] [RFC2966]（IPV4またはIPv6の場合）を使用して実行されることを前提としています。また、メカニズムは、主要なパスと代替パスの両方が同じルーティング領域にあることを想定しています。
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 Fast Reroute（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.
IP Fast Rerouteの動作を明確にするために、図1の単純なトポロジを検討してください。ルーターSがルーターDへの最短パスを計算する場合、ルーターSはルーターEへのリンクを主要なネクストホップとして使用することを決定します。IP Fast Rerouteがなければ、そのリンクは、Router SがDに到達するための唯一のネクストホップです。IPファストルアウトを使用して、Sは使用する代替のネクストホップも探します。この例では、SはルーターN_1へのリンクを使用してDに運命づけられているトラフィックを送信できるため、SはN_1へのリンクを代替のネクストホップとしてインストールできると判断します。後で、ルーター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に増加した場合、N_1からS via Sへのパスのコストは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.
この仕様では、[フレームワーク]で導入された用語を使用します。特に、dimise_opt（x、y）を使用してd_opt（x、y）に省略し、xからyまでの最短距離を示します。Sは、計算ルーターを示すために使用されます。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)
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)
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.
Alternate Next-Hopは、単一のリンク障害、単一のノード障害、共有リスクリンクグループ内の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.
リンク保護のみが提供され、ノードが失敗した場合、代替物を使用してマイクロループを経験することができます。この問題を図2に示します。リンク（s-> e）が失敗した場合、nを介したリンク保護の代替が正しく動作します。ただし、ルーターEが失敗した場合、SとNの両方が障害を検出し、代替に切り替えます。この例では、SはトラフィックをNとNにリダイレクトしてトラフィックをSにリダイレクトし、転送ループを引き起こします。このようなシナリオは、ネットワーク内の他のすべてのルーターが最短のパスに基づいて転送されているという重要な仮定が、2番目の同時相関障害のために違反されるために発生する可能性があります。ノード障害を処理する他の保護メカニズムがない場合、リンク保護LFAのみを使用する場合、ノード障害は依然として懸念事項です。
<@@@
@@@>
+-----+ +-----+
| 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.
上記のように、ノード保護LFA（セクション3.2で説明）または下流のパスのいずれかを使用すると、ノード障害が発生した場合のマイクロループに対する保護が提供されます。ノード保護LFA、下流のパス、または両方がない場合、またはどちらもない場合、トポロジがあります。ノードは、近隣ノード障害が発生した場合にマイクロループを引き起こすリスクなしに、ノード保護LFAまたは下流パスのいずれかを選択できます。リンクとノードの保護LFAは、リンクまたはノードの障害に対する保護を保証しますが、ダウンストリームパスはリンク障害に対してのみ保護を提供し、ダウンストリームノードで利用可能な保護に応じてノード障害に対する保護を提供する場合としない場合があります。しかし、マイクロループを引き起こすことはできません。たとえば、図2では、Sが下流パスとしてnを使用している場合、ループは発生しませんが、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).
リンクとノード保護のLFAの機能は、リンクを保護する下流パスの機能よりも大きいため、ルーターはリンク保護下流パスでリンクとノード保護のLFAを選択する必要があります。リンクとノードの保護LFAが利用できない目的地がある場合、定義上、コンピューティングルーターの隣人からのすべての目的地へのパスは、保護されているノード（e）を介してでなければなりません（それ以外の場合は、その宛先のLFAを保護するノードがあります）。したがって、宛先として保護されたノードへの下流のパスが存在する場合、その下流のパスは、リンクとノードを保護するLFAが利用できないすべての目的地に使用される可能性があります。下流パスの存在は、条件distany distany（n、e）<distance_opt（s、e）の単一のチェックによって決定できます。
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に属することができる共有リスクリンクグループ（SRLG）によって処理されます。一般的な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のこのサブカテゴリは、ローカルSRLGと呼ばれます。ローカルSRLGには、同じルーターに接続された一方の端を持つすべてのメンバーリンクがあります。したがって、ルーターSは、プライマリネクストホップと同じローカルSRLGのリンクを使用しないループフリーの代替を選択できます。Eに属するローカルSRLGの障害は、ノード保護を介して保護できます。つまり、ループフリーのノード保護の代替を選択します。
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またはIS-IS領域のコンテキストにあり、そのトポロジーはSPF計算で使用されてループフリーの代替を計算します。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.
このメモで説明されているIP高速再ルートメカニズムは、domain内部ルーティングのみをカバーし、OSPF [RFC2328] [RFC2740] [RFC5340]またはIS-IS [RFC1195] [RFC2966]をIGPとしてカバーします。具体的には、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:
セクション6.3で説明されているOSPF間のエリア間ルーティング動作の特定の側面と付録Aは、トラフィックの軌跡を評価するためにバックアップネクストホップを計算するルーターの能力に影響します。マイクロループを回避し、必要なカバレッジを確保するために、マルチエリア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として発表され、存在するASBが存在するネットワークの非腰ボーンエリアで、外部ルートまたは自律システムボーダールーター（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. ループフリーの代替品は、外部ルートのネットワークの非骨骨エリアでは使用しないでください。外部のプレフィックスは、異なる非バックボーン領域にある複数のASBRによって同じタイプの外部メトリックで宣伝されています。0.0.0.0の転送アドレスまたは1つ以上のASBRによる、複数の非バックボーン領域での転送アドレスを備えたASBRは、これらの非バックボーン領域の2つ以上にABRが同時に存在します。
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 Fast Rerouteをサポートするルーターは、バックアップNext-Hopのセットを計算します。局所的な障害が発生します。これらのバックアップネクストホップは、必要なタイプの保護（つまり、リンク保護および/またはノード保護）を提供し、予想される障害が発生した場合、それらを通るトラフィックを転送してもループにならないことを保証するために計算されます。このような次のホップは、この仕様全体でループフリーの代替またはLFAと呼ばれます。
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のLFAのセットを計算できるようにするには、ルーターは次の基本的な情報を知る必要があります。
o Shortest-path distance from the calculating router to the destination (Distance_opt(S, D))
o 計算ルーターから宛先までの最短パス距離（distane_opt（s、d））
o Shortest-path distance from the router's IGP neighbors to the destination (Distance_opt(N, D))
o ルーターのIGP隣人から目的地までの最短パス距離（distange_opt（n、d））
o Shortest path distance from the router's IGP neighbors to itself (Distance_opt(N, S))
o ルーターのIGPネイバーからそれ自体までの最短パス距離（distane_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 distany_opt（s、d）は、通常、リンク状態のルーティングプロトコルによって実行される通常のSPF計算から利用できます。distance_opt（n、d）およびdistany_opt（n、s）は、各IGP隣接の観点から追加のSPF計算を実行することで取得できます（すなわち、隣接の頂点をSPTのルート（N）のルートと考えると、以下 - 以下 - -SPT（S）と呼ばれる計算ルーターのものよりも驚くべきことです。
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.
この仕様は、計算ルーターが直接接続されるリンクを含むSRLGに限定されたSRLG保護の形式を定義します。SRLGのセットのみが局所的な障害を引き起こす可能性があります。計算ルーターは、局所障害を処理するために代替のみを計算します。ローカルリンクSRLGメンバーシップに関する情報は、手動で構成されています。リモートリンクSRLGメンバーシップに関する情報は、[RFC4205]または[RFC4203]を使用して動的に取得できます。srlg_local（s）を定義して、計算ルーターSが直接接続されるリンクを含むSRLGのセットであると定義します。ローカルリンク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保護を提供する利用可能なすべてのLFAを選択するには、特定のIGP隣接を通るパスが関与するsrlg_local（s）のsrlgsのセットを追跡する必要があります。そのために、ネットワークトポロジの各ノードDはSRLG_SET（N、D）に関連付けられています。これは、DへのトラフィックがNを介して転送された場合に交差するSRLGのセットです。このセットを計算するために、ルーターはSRLG_SETを初期化します（n、n）IGPのそれぞれの隣接が空になるため。SPT（n）計算中、新しい頂点vがSPTに追加されると、そのsrlg_set（n、v）が親に関連付けられたSRLGセットの結合に設定され、srlg_local（s）のsrlgセットが設定されます。Vの両親からVへのリンクに関連付けられています。候補者の次のホップに関連付けられたSRLGSのセットの結合と、その候補のネクストホップを介して到達した隣人のsrlg_set（n、d）は、SRLG保護を決定するために使用されます。
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.
次のセクションでは、LFAの計算に必要な情報を提供します。セクション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.
この仕様に続く実装で使用される代替の次のホップは、少なくとも不平等1で上記のループ繁殖条件に準拠する必要があります。この条件は、LFAへのトラフィックをリンク障害後にループに導かないことを保証します。
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.
宛先DのプライマリネイバーEのノード障害から保護する代替のネクストホップnの場合、nはEとDの両方に関してループフリーでなければなりません。不平等3が真である場合、nはループフリーの代替を提供する隣人です。
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には等しいコストパスがあり、そのうちの1つがeのノード障害に対する保護を提供できる可能性があります。ただし、Nのパスの1つがEを通過する可能性もあり、計算ルーターにはNの決定に影響を与える方法がありません。したがって、不平等3が満たされていない場合、代替のNext-Hopはノード保護を提供しないと想定する必要があります。
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)
Inequality 4: Loop-Free Link-Protecting Criterion for Broadcast Links 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.
不平等4：ブロードキャストリンクのループフリーリンク保護基準擬似ノードからの最短パスはEを通過するため、ネイバーNからのループフリーの代替がノード保護の場合、代替はリンク保護もあります。ルーターSは、同じ擬似ノードを介して代替隣接nにのみ到達できます。これは、ノード保護LFAがリンク保護ではない唯一のケースであるため、これはポイントツーポイントインターフェイスの場合、ノード保護のLFAが常にリンク保護であることを意味します。Sは最も短いパスからトラフィックを誘導して代替nを使用できるため、トラフィックはプライマリ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インターフェイス全体にある場合、代替選択中にリンク保護を検討する必要があります。明確にするには、図3のトポロジーを検討してください。Nがリンク保護を提供するには、nの最短経路が擬似ノードPNを横断しないことが最初に必要です。第二に、Sによって選択された代替の次のホップがPNを通過しないことが必要です。この例では、Sのnへの最短パスは擬似ノードを介してです。したがって、リンク保護を取得するには、sの次のホップ（この例では、この例では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保護に必要です。Sの選択された隣接nへの最短パスは、nからDへのパスが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には、dに到達するための3つの主要なネクストホップがあります。これらはL2からE1、L2からE2、L3からE3です。プライマリネクストホップL2からE1は、L3からE3へのリンクとノードの保護を取得できます。これは、他の主要なネクストホップの1つです。L2からE1は、他のプライマリネクストホップL2からE2からリンク保護を取得できません。同様に、プライマリネクストホップL2からE2は、L2からE1へのノード保護のみを取得でき、L3からE3へのリンク保護のみを取得できます。3番目のプライマリネクストホップL3からE3は、L2からE1へ、およびL2からE2へのリンクおよびノード保護を取得できます。プライマリネクストホップL2からE2とプライマリネクストホップL2からE1の両方が、L1を使用してリンクとノードの両方の保護を提供する代替のネクストホップを取得することができます。
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）。ブロードキャストリンクの場合、潜在的な代替次のホップに関連する逆コストは、ネクストホップルーターによって宣伝されている擬似ノードに対するコストです。ポイントツーポイントリンクの場合、next-Hopルーターからの特定のリンクを特定のリンクに関連付けることができない場合、考慮される逆コストは、次のホップルーターから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.
OSPFの場合、ルーターsから隣接n_iへのすべてのリンクがlsinfinityの逆コストを持っている場合、ルーター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.
同様に、IS-ISの場合、N_Iのオーバーロードビットが設定されている場合、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.
コストがかかっているリンクまたはルーターが、特定のルーターから特定の宛先へのトラフィックを保護するための唯一の可能な代替である場合、保護のために代替を提供するべきではありません。
[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]は、LFAとの相互作用を定義する必要があるいくつかのフラグを説明しています。ルーターは、LFAを獲得した結果として「利用可能なローカル保護可能」フラグを指定してはなりません。ルーターは、リンクが属性「ローカル保護パスから除外されたリンク」または属性「ローカルメンテナンスが必要」とともに宣伝されているリンクに沿った代替のネクストホップを使用しないでください。
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.
5. SRLGSを考慮した実装では、SRLG保護を使用して、ノード保護またはリンク保護の代替が使用できないことを判断する場合があります。
Following the above rules maximizes the level of protection and use of primary (ECMP) next-hops.
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と不平等を満たします。パスは、S、Sの主要な隣接E、およびSからSからEへのリンクを回避します。
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。主要なネクストホップがブロードキャストリンクを使用する場合、このネクストホップは不平等を満たします。
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保護も完全に、または完全なSRLG保護を提供しない場合もあります。たとえば、リンクは2つのSRLGS G1とG2に属している場合があります。代替経路は、G2の他のリンクを避けることができますが、G2ではなく回避できます。その場合、代替は部分的なSRLG保護のみを提供します。
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_1からN_Jがあります。候補のネクストホップは（発信リンク、隣人）で示され、IGPによって決定されるように、発信リンクは双方向に接続する必要があります。Sの次の候補は、H_1からH_Kとして列挙されています。Sは、隣人への異なるインターフェイス上に複数のネクストホップを持っている可能性があることを思い出してください。H_I.LINKは、そのNext-Hopの発信リンクを指し、H_I.NeighborはそのNext-Hopの隣人を指します。
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_i互いの隣のn_j、およびパスD_OPT（n_i、d）によって横断されるsrlgsのセット。Sに到達するために選択されたプライマリネクストホップのすべての以下の手順に従う必要があります。この手順では、P_Iの代替のNext-Hopが見つかります。
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 = {}
For each candidate next-hop H_h,
次の候補者ごとに、hop h_h、
1. Initialize variables as follows:
1. 次のように変数を初期化します。
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,
そして、H_H.LINKのコストは最大値未満であり、H_Hの逆コストは最大値よりも低く、H_H.Neighborは過負荷になりません（IS-ISの場合）、H_H.LINKは双方向です。
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はループフリーではありません。それをスキップして、次の候補者の次のホップに進みます。
5. cand_type = LOOP-FREE.
5. cand_type =ループフリー。
6. If H_h is a primary next-hop, set cand_type to PRIMARY.
6. H_Hがプライマリネクストホップの場合、cand_typeをプライマリに設定します。
7. If H_h.link is not P_i.link, set cand_link-protect to TRUE.
7. h_h.linkがp_i.linkではない場合、cand_link-protectをtrueに設定します。
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）、cand_node-protectをtrueに設定します。
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を考慮した場合、cand_srlg-protectをP_i.linkからp_i.neighborまでのパスで通過したsrlgsのセットに設定します。h_hがcand_srlg-protectから属するsrlgsのセットを削除します。cand_srlg-protect h_h.neighborからDまでパスで通過したsrlgsのセットは、cand_srlg-protectはp_iが属するsrlgsのセットを保持し、それはh_hを介してsからDまでのパスで通過しないSRLGSのセットを保持します。
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です。
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-protectがtrueで、p_i.alt_node-protectがfalseである場合、goto段落20。
13. If cand_link-protect is TRUE and P_i.alt_link-protect is FALSE, goto Step 20.
13. cand_link-protectがtrueで、p_i.alt_link-protectが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-ProtectがP_I.ALT_SRLG-PROTECTよりも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-PROTECTがP_I.ALT_SRLG-PROTECTと異なる場合、距離、IPアドレス、またはルーターローカルタイブレーカーに基づいてH_HとP_I.ALT_NEXT_HOPSを選択します。H_Hが優先される場合は、GOTOステップ20。P_I.ALT_NEXT_HOPSが優先される場合は、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.
16. 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）、h_hは下流の代替およびp_i.alt_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. 代替タイプ、代替距離、IPアドレス、またはその他のタイブレーカーに基づいて、h_hがp_i.alt_next_hopsよりも優先されるかどうかを決定します。もしそうなら、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.
18. p_i.alt_next_hopsがH_Hよりも優先されるかどうかを決定します。もしそうなら、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. h_hをp_i.alt_next_hopsに追加します。p_i.alt_typeをより良いタイプのh_h.alt_typeおよびp_i.alt_typeに設定します。次の候補者の次のホップに進みます。
20. Replace the P_i alternate next-hop set with H_h as follows:
20. 次のように、P_Iの代替ネクストホップセットをH_Hに置き換えます。
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.
LFAはさまざまな量の保護を提供でき、どのタイプを好むかについての決定は、ネットワークトポロジやネットワークで使用されている他の手法に依存します。このセクションでは、さまざまな保護レベルとそれぞれに関連するトレードオフについて説明します。
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. プライマリネクストホップ：等しいコストのプライマリネクストホップがある場合、1つを代替として使用することで、ネットワークが収束するパスを横切るトラフィックフローを伴うマイクロループを引き起こさないように保証されますが、うっ血を経験することができますトラフィックが少なく送信されるため、主要なパス。すべての主要なネクストホップは、下流のパスです。
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を含むマイクロループを引き起こさないことが保証されています。ただし、ネットワークでのこのような代替の予想されるカバレッジは貧弱であると予想されます。すべての下流パスはLFAです。
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-Protecting）として略されます。
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.
ルーターに接続されている各ヘクストホップのリンク保護LFAを1つだけ検討および計算することにより、リンク保護のみが必要な場合、LFAの計算と使用を簡素化することができます。次のホップをプライマリとして使用するすべての接頭辞は、そのネクストホップに計算された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は、プレフィックスの主要なネクストホップのもう1つである場合とそうでない場合があります。
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.
この単純化は、ネットワーク内のカバレッジを削減する可能性があります。マルチホームの接頭辞の保護を制限することに加えて（セクション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には3つのECMP Next-Hops、E1、E2、およびE3があり、Dに到達する図4を考えてみましょう。プレフィックスDの場合、E3はNext-HOPS E1およびE2のリンク保護を提供できます。E1とE2は、Next-Hops E3のリンク保護を提供できます。ただし、この単純化を使用してE1、E2、およびE3のLFAを個別に計算すると、E1にLFAを保護する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:
次のホップの障害がローカルインターフェイス障害またはその他の障害検出メカニズムを介して検出された場合（[フレームワーク]を参照）、ルーターは次のようにする必要があります。
1. Remove the primary next-hop associated with the failure.
1. 障害に関連付けられた主要なネクストホップを削除します。
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.
[順序付けられた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.
+-----+
| 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:
実装は、新しいルーティング情報が新しいネットワークトポロジに基づいて利用可能になった後でも、パケット転送に代替のNext-Hopsを引き続き使用する必要があります。パケット転送のための代替のネクストホップの使用は、次のことを終了する必要があります。
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.
これは、LDPを実行しているラベルスイッチングルーター（LSR）が、上流であるかどうかに関係なく、すべての近隣に提供できる転送等価クラス（FEC）のラベルを配布する必要があることを意味します。さらに、LDPは、現在主要な隣人ではない隣人に対応するラベルが保存されるように、リベラルなラベル保持モードで行動する必要があります。同様に、LDPはSPT以外のFECのラベルが分布するように、下流の未承諾モードである必要があります。
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.
特定のOSPF領域またはIS-ISレベルに対応する各トポロジごとにSPFのような計算が実行されます。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に到達する最短パスはEを介して行われます。プレフィックスPには、次の主要なホップとして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に1のメトリックでEに接続された別のプレフィックスxがあり、3のメトリックでFに接続されている場合、プレフィックスXはプレフィックスPに対して計算されたのと同じ代替次のホップを使用できます。
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.
LFAのマルチトポロジーIS [RFC5120]との適用性と相互作用は、この仕様の範囲外です。
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を使用することを決定する場合がありますが、そのパスは、エリア1を使用することを決定する別の代替ABR Bを横断する可能性があります。これは、図7に示すものと同様のシナリオにつながる可能性があります。
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. 外部のプレフィックスとして：プレフィックスは、異なる領域の複数のASBRによって宣伝されている場合があります。これは、そのようなABRに、プレフィックスに到達するためにどの領域を使用するかについての決定を提示します。
Loop-free alternates should not be used in an area where one of the above issues affects that area.
上記の問題の1つがその領域に影響を与える領域では、ループフリーの代替品を使用しないでください。
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-External Link State Advertisement（LSA）に設定されている場合、ネットワーク内のすべてのルーターは、ルーティングテーブルの転送アドレスの検索を行うことにより、外部プレフィックスの次のホップを計算します。ASBRのために計算されたNext-Hops。この場合、ASBRへの代替パスではなく、転送リンクへの代替パスの中から選択して、代替のネクストホップを計算する必要があります。
The applicability and interactions of LFAs with multi-topology OSPF [RFC4915] [MT-OSPFv3] is out of scope for this specification.
LFAとマルチトポロジーOSPF [RFC4915] [MT-SOSPFV3]との適用性と相互作用は、この仕様の範囲外です。
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 Next-HopとしてAS Exit RouterのルーターIDで宣伝され、IGPルートによって出口ルーターに到達するように宣伝されます。BGPは、ルーティングデータベースの潜在的な再帰検索により、宣伝された次のホップを即座に次のホップに解決します。IP Fast Rerouteは、すべてのIGP宛先に代替のNext-Hopsを計算します。これには、AS Exit RouterのルーターIDへの次のヘクストホップが含まれます。BGPは、IGPから代替のネクストホップを単に継承します。BGP決定プロセスは変更されていません。BGPは、IGP最適距離を使用して、最も近い出口ルーターを見つけ続けています。マルチキャストBGP（MBGP）ルートでは、代替のNext-Hopをコピーする必要はありません。
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 Next-HOPのセットを選択し、IGPがBGPルートがマルチホームのプレフィックスであるかのようにプライマリおよび代替の次-HOPを決定できるように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 Fast Rerouteのこの仕様の範囲外です。代替のネクストホップは、マルチキャストリバースパス転送（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.
LDPでは、FECラベル情報の幅広い分布は、信頼できるLDPセッションが確立されている隣人向けです。このより広い分布とリベラルなラベル保持モードを使用するという推奨は、重大なセキュリティへの影響がないと考えられています。
The authors would like to thank Joel Halpern, Mike Shand, Stewart Bryant, and Stefano Previdi for their assistance and useful review.
著者は、Joel Halpern、Mike Shand、Stewart Bryant、Stefano Previdiの支援と有用なレビューに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、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.、Ferguson、D。、およびJ. Moy、「OSPF for IPv6」、RFC 2740、1999年12月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「LDP仕様」、RFC 5036、2007年10月。
[FRAMEWORK] Shand, M. and S. Bryant, "IP Fast Reroute Framework", Work in Progress, February 2008.
[フレームワーク] Shand、M。and S. Bryant、「IP Fast Reroute Framework」、2008年2月、Work in Progress。
[MICROLOOP] Zinin, A., "Analysis and Minimization of Microloops in Link-state Routing Protocols", Work in Progress, October 2005.
[Microloop] Zinin、A。、「リンク状態のルーティングプロトコルにおけるマイクロループの分析と最小化」、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。and A. Roy、「OSPFV3（MT-SOSPFV3）のマルチトポロジールーティング」、2007年7月、進行中の作業。
[ORDERED-FIB] Francois, P., "Loop-free convergence using oFIB", Work in Progress, February 2008.
[Ordered-fib] Francois、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。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[RFC2966] Li、T.、Przygienda、T。、およびH. Smit、「2レベルのIS-ISを備えたドメイン全体の接頭分布」、RFC 2966、2000年10月。
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[RFC3137] Retana、A.、Nguyen、L.、White、R.、Zinin、A。、およびD. McPherson、「OSPF Stub Router Advertisement」、RFC 3137、2001年6月。
[RFC3509] Zinin, A., Lindem, A., and D. Yeung, "Alternative Implementations of OSPF Area Border Routers", RFC 3509, April 2003.
[RFC3509] Zinin、A.、Lindem、A。、およびD. Yeung、「OSPFエリアボーダールーターの代替実装」、RFC 3509、2003年4月。
[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、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、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、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートする中間システム（IS-IS）拡張」、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.、Roy、A.、Nguyen、L。、およびP. Pillay-Esnault、「Multi-Topology（MT）Routing in OSPF」、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、「IS-ISリンク属性Sub-TLVの定義」、RFC 5029、2007年9月。
[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.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）中間システムのルーティング（MT）中間システム（IS-IS）、RFC 5120、2008年2月。
[RFC5340] Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
Appendix A. OSPF Example Where LFA Based on Local Area Topology Is Insufficient
付録A. ローカルエリアトポロジに基づいたLFAが不十分な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で説明されているように、1つの問題シナリオは、ASBRがエリア内ルートを介して2つの領域で利用可能であるASBR要約のためのもので、両方の領域にあるABRまたは代替ABRが少なくとも1つあります。次の図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のパスはAを経由します。Aは、エリア2を介してASBRへのエリア内ルートも見られます。エリア2のパスのコストは30で、35未満で、エリア1のパスのコストはコストです。したがって、Aはエリア2からパスを使用し、トラフィックをFに向けます。B. BはABRでもあり、エリア1とエリア2の両方からASBRを学習します。エリア1を介したBのパスは、エリア2（コスト25）を介したBのパスよりも短い（コスト20）。したがって、Bは、Sに接続するエリア1からのパスを使用します。
Authors' Addresses
著者のアドレス
Alia K. Atlas (editor) BT
Alia K. Atlas（編集者）Bt
EMail: alia.atlas@bt.com
Alex Zinin (editor) Alcatel-Lucent 750D Chai Chee Rd, #06-06 Technopark@ChaiChee Singapore 469004
Alex Zinin（編集者）Alcatel-Lucent 750d Chai Chee Rd、＃06-06 Technopark@Chaichee Singapore 469004
EMail: alex.zinin@alcatel-lucent.com
Raveendra Torvi FutureWei Technologies Inc. 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
Raveendra Torvi FutureWei Technologies Inc. 1700 Alma Dr. Suite 100 Plano、TX 75075 USA
EMail: traveendra@huawei.com
Gagan Choudhury AT&T 200 Laurel Avenue, Room D5-3C21 Middletown, NJ 07748 USA
Gagan Choudhury AT＆T 200 Laurel Avenue、Room D5-3C21ミドルタウン、ニュージャージー07748 USA
Phone: +1 732 420-3721
EMail: gchoudhury@att.com
Christian Martin iPath Technologies
クリスチャン・マーティン・アイパス・テクノロジー
EMail: chris@ipath.net
Brent Imhoff
Juniper Networks
1194 North Mathilda
Sunnyvale, CA 94089
USA
Phone: +1 314 378 2571
EMail: bimhoff@planetspork.com
Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01821 USA
Don Fedyk Nortel Networks 600 Technology Park Billerica、MA 01821 USA
Phone: +1 978 288 3041
EMail: dwfedyk@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。