[要約] RFC 5715は、ループフリー収束のためのフレームワークを提供するものであり、ルーティングプロトコルの収束性を向上させることを目的としています。
Internet Engineering Task Force (IETF) M. Shand
Request for Comments: 5715 S. Bryant
Category: Informational Cisco Systems
ISSN: 2070-1721 January 2010
A Framework for Loop-Free Convergence
ループフリーの収束のためのフレームワーク
Abstract
概要
A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.
マイクロループは、ホップバイホップパケット転送パラダイム内の2つ以上のルーター間で一時的に発生する可能性のあるパケット転送ループです。
This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable.
このフレームワークは、マイクロループの原因と結果の要約を提供し、読者がマイクロループが特定のネットワークで対処する必要がある問題であるかどうかについて判断を下すことができます。また、IPまたはMPLSネットワークが障害、修理、または管理アクションによりトポロジの変更を受けるときに、マイクロループの形成を防止または抑制するために使用される可能性のある現在提案されているメカニズムの調査を提供します。十分に高速な収束が利用できず、トポロジーがマイクロループの影響を受けやすい場合、これらのメカニズムの1つ以上を使用することが望ましい場合があります。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5715.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5715で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
2. The Nature of Micro-Loops .......................................4
3. Applicability ...................................................5
4. Micro-Loop Control Strategies ...................................6
5. Loop Mitigation .................................................8
5.1. Fast Convergence ...........................................8
5.2. PLSN .......................................................8
6. Micro-Loop Prevention ..........................................10
6.1. Incremental Cost Advertisement ............................10
6.2. Nearside Tunneling ........................................12
6.3. Farside Tunnels ...........................................13
6.4. Distributed Tunnels .......................................14
6.5. Packet Marking ............................................14
6.6. MPLS New Labels ...........................................15
6.7. Ordered FIB Update ........................................16
6.8. Synchronised FIB Update ...................................18
7. Using PLSN in Conjunction with Other Methods ...................18
8. Loop Suppression ...............................................19
9. Compatibility Issues ...........................................20
10. Comparison of Loop-Free Convergence Methods ...................20
11. Security Considerations .......................................21
12. Acknowledgments ...............................................21
13. Informative References ........................................21
When there is a change to the network topology (due to the failure or restoration of a link or router, or as a result of management action), the routers need to converge on a common view of the new topology and the paths to be used for forwarding traffic to each destination. During this process, referred to as a routing transition, packet delivery between certain source/destination pairs may be disrupted. This occurs due to the time it takes for the topology change to be propagated around the network together with the time it takes each individual router to determine and then update the forwarding information base (FIB) for the affected destinations. During this transition, packets may be lost due to the continuing attempts to use the failed component and due to forwarding loops. Forwarding loops arise due to the inconsistent FIBs that occur as a result of the difference in time taken by routers to execute the transition process. This is a problem that may occur in both IP networks and MPLS networks that use the label distribution protocol (LDP) [RFC5036] as the label switched path (LSP) signaling protocol.
ネットワークトポロジに変更がある場合（リンクまたはルーターの障害または復元、または管理アクションの結果として）、ルーターは新しいトポロジと使用するパスの共通のビューに収束する必要があります。各宛先にトラフィックを転送するため。このプロセスでは、ルーティングトランジションと呼ばれ、特定のソース/宛先ペア間のパケット配信が破壊される場合があります。これは、各ルーターが影響を受ける目的地の転送情報ベース（FIB）を決定して更新するのにかかる時間とともに、トポロジの変化がネットワーク内で伝播するのにかかる時間とともに発生します。この遷移中、故障したコンポーネントを使用しようとする継続的な試みと転送ループのために、パケットが失われる可能性があります。転送ループは、遷移プロセスを実行するためにルーターが取った時間の違いの結果として発生する一貫性のないFIBのために発生します。これは、ラベルが切り替えられたパス（LSP）シグナル伝達プロトコルとして、ラベル分布プロトコル（LDP）[RFC5036]を使用するIPネットワークとMPLSネットワークの両方で発生する可能性のある問題です。
The service failures caused by routing transitions are largely hidden by higher-level protocols that retransmit the lost data. However, new Internet services could emerge that are more sensitive to the packet disruption that occurs during a transition. To make the transition transparent to their users, these services would require a short routing transition. Ideally, routing transitions would be completed in zero time with no packet loss.
ルーティングトランジションによって引き起こされるサービスの障害は、失われたデータを再送信する高レベルのプロトコルによって主に隠されています。ただし、移行中に発生するパケットの破壊により敏感な新しいインターネットサービスが出現する可能性があります。移行をユーザーに透明にするために、これらのサービスには短いルーティングの移行が必要になります。理想的には、ルーティングトランジションはパケット損失なしでゼロ時間で完了します。
Regardless of how optimally the mechanisms involved have been designed and implemented, it is inevitable that a routing transition will take some minimum interval that is greater than zero. This has led to the development of a traffic engineering (TE) fast-reroute mechanism for MPLS [RFC4090]. Alternative mechanisms that might be deployed in an MPLS network or an IP network are current work items in the IETF [RFC5714]. The repair mechanism may, however, be disrupted by the formation of micro-loops during the period between the time when the failure is announced and the time when all FIBs have been updated to reflect the new topology.
関係するメカニズムがどのように設計および実装されているかにかかわらず、ルーティング遷移がゼロより大きい最小間隔をとることは避けられません。これにより、MPLS [RFC4090]のトラフィックエンジニアリング（TE）高速メカニズムの開発につながりました。MPLSネットワークまたはIPネットワークに展開される可能性のある代替メカニズムは、IETF [RFC5714]の現在の作業項目です。ただし、修復メカニズムは、故障が発表される期間と、すべてのFIBが新しいトポロジを反映するために更新された期間中のマイクロループの形成によって破壊される場合があります。
One method of mitigating the effects of micro-loops is to ensure that the network reconverges in a sufficiently short time that these effects are inconsequential. Another method is to design the network topology to minimise or even eliminate the possibility of micro-loops.
マイクロループの効果を軽減する1つの方法は、ネットワークが十分に短時間でこれらの効果が取るに足らないものであることを保証することです。別の方法は、ネットワークトポロジを設計して、マイクロループの可能性を最小限に抑えるか、排除することです。
The propensity to form micro-loops is highly topology dependent, and algorithms are available to identify which links in a network are subject to micro-looping. In topologies that are critically susceptible to the formation of micro-loops, there is little point in introducing new mechanisms to provide fast reroute without also deploying mechanisms that prevent the disruptive effects of micro-loops. Unless micro-loop prevention is used in these topologies, packets may not reach the repair and micro-looping packets may cause congestion, resulting in further packet loss.
マイクロループを形成する傾向は非常にトポロジーに依存しており、アルゴリズムはネットワーク内のどのリンクがマイクロループの影響を受けるかを識別するために利用可能です。マイクロループの形成に重大な影響を受けやすいトポロジーでは、マイクロループの破壊効果を防ぐメカニズムも展開することなく、高速な再ルーティングを提供する新しいメカニズムを導入することにはほとんど意味がありません。これらのトポロジでマイクロループ予防が使用されない限り、パケットは修理に到達しない可能性があり、マイクロルーピングパケットはうっ血を引き起こし、さらにパケットの損失をもたらします。
The disruptive effect of micro-loops is not confined to periods when there is a component failure. Micro-loops can, for example, form when a component is put back into service following repair. Micro-loops can also form as a result of a network-maintenance action such as adding a new network component, removing a network component, or modifying a link cost.
マイクロループの破壊的効果は、成分の故障がある期間に限定されません。たとえば、マイクロループは、修理後にコンポーネントが使用されるときに形成できます。マイクロループは、新しいネットワークコンポーネントの追加、ネットワークコンポーネントの削除、リンクコストの変更など、ネットワークメンテナンスのアクションの結果として形成されます。
This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed micro-loop mitigation mechanisms. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable.
このフレームワークは、マイクロループの原因と結果の要約を提供し、読者がマイクロループが特定のネットワークで対処する必要がある問題であるかどうかについて判断を下すことができます。また、現在提案されているマイクロループ緩和メカニズムの調査も提供します。十分に高速な収束が利用できず、トポロジーがマイクロループの影響を受けやすい場合、これらのメカニズムの1つ以上を使用することが望ましい場合があります。
A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop, packet forwarding paradigm.
マイクロループは、ホップバイホップのパケット転送パラダイムで2つ以上のルーター間で一時的に発生する可能性のあるパケット転送ループです。
Micro-loops may form during the periods when a network is re-converging following ANY topology change and are caused by inconsistent FIBs in the routers. During the transition, micro-loops may occur over a single link between a pair of routers that temporarily use each other as the next hop for a prefix. Micro-loops may also form when each router in a cycle of three or more routers has the next router in the cycle as a next hop for a given prefix.
マイクロループは、トポロジの変更後にネットワークが再構成されている期間中に形成され、ルーターの一貫性のないFIBによって引き起こされる場合があります。遷移中、マイクロループは、プレフィックスの次のホップとして一時的に互いに使用するルーターのペア間の単一のリンクで発生する可能性があります。マイクロループは、3つ以上のルーターのサイクル内の各ルーターが、特定のプレフィックスの次のホップとして、サイクル内の次のルーターを持っている場合にも形成されます。
Cyclic loops may occur if one or more of the following conditions are met:
次の条件の1つ以上が満たされている場合、周期ループが発生する可能性があります。
1. Asymmetric link costs.
1. 非対称リンクコスト。
2. An equal-cost path exists between a pair of routers, each of which makes a different decision regarding which path to use for forwarding to a particular destination. Note that even routers that do not implement equal-cost, multi-path (ECMP) forwarding must make a choice between the available equal-cost paths, and unless they make the same choice, the condition for cyclic loops will be fulfilled.
2. ルーターのペア間に等しいコストのパスが存在し、それぞれが特定の宛先への転送に使用するパスに関して異なる決定を下します。等しいコストのマルチパス（ECMP）転送を実装していないルーターでさえ、利用可能な等しいコストのパスを選択する必要があり、同じ選択をしない限り、周期ループの条件が満たされることに注意してください。
3. Topology changes affecting multiple links, including single node and line card failures.
3. 単一ノードやラインカードの障害など、複数のリンクに影響を与えるトポロジの変更。
Micro-loops have two undesirable side effects: congestion and repair starvation.
マイクロループには、うっ血と修復の飢ationという2つの望ましくない副作用があります。
o A looping packet consumes bandwidth until it either escapes as a result of the re-synchronization of the FIBs or its time to live (TTL) expires. This transiently increases the traffic over a link by as much as 128 times, and may cause the link to become congested. This congestion reduces the bandwidth available to other traffic (which is not otherwise affected by the topology change). As a result, the "innocent" traffic using the link experiences increased latency and is liable to congestive packet loss.
o ループパケットは、FIBの再同期の結果として逃げるか、その時間（TTL）の有効期限が切れるまで、帯域幅を消費します。これにより、リンク上のトラフィックが最大128倍も増加し、リンクが混雑する可能性があります。この混雑は、他のトラフィックで利用可能な帯域幅を減らします（トポロジの変更によって影響を受けることはありません）。その結果、リンクを使用した「罪のない」トラフィックはレイテンシを増加させ、うっ血性パケットの損失を抑制します。
o In cases where the link or node failure has been protected by a fast-reroute repair, an inconsistency in the FIBs may prevent some traffic from reaching the failure, and hence being repaired. The repair may thus become starved of traffic and thereby rendered ineffective.
o リンクまたはノードの障害が急速に急速に修復された場合に保護されている場合、FIBの矛盾により、一部のトラフィックが障害に到達するのを防ぐため、修理される可能性があります。したがって、修理は交通に飢えている可能性があり、それにより効果がなくなります。
Although micro-loops are usually considered in the context of a failure, similar problems of congestive packet loss and starvation may also occur if the topology change is the result of management action. For example, consider the case where a link is to be taken out of service by management action. The link can be retained in service throughout the transition, thus avoiding the need for any repair. However, if micro-loops form, they may cause congestion loss and may also prevent traffic from reaching the link.
通常、マイクロループは障害のコンテキストで考慮されますが、トポロジの変更が管理措置の結果である場合、うっ血性パケットの損失と飢starの同様の問題も発生する可能性があります。たとえば、管理措置によりリンクが使用されない場合を検討してください。リンクは移行中に使用中に保持される可能性があるため、修理の必要性を回避できます。ただし、マイクロループが形成された場合、混雑損失を引き起こし、トラフィックがリンクに到達するのを防ぐこともあります。
Unless otherwise controlled, micro-loops may form in any part of the network that forwards (or in the case of a new link, will forward) packets over a path that includes the affected topology change. The time taken to propagate the topology change through the network, and the non-uniform time taken by each router to calculate the new shortest path tree (SPT) and update its FIB, contribute to the duration of the packet disruption caused by the micro-loops. In some cases, a packet may be subject to disruption from micro-loops that occur sequentially at links along the path, thus further extending the period of disruption beyond that required to resolve a single loop.
特に制御されていない限り、マイクロループは、影響を受けるトポロジの変化を含むパス上に、転送（または新しいリンクの場合、転送）パケットを転送するネットワークのどの部分でも形成されます。ネットワークを介したトポロジの変化を伝播するのにかかった時間、および各ルーターが取った不均一な時間は、新しい最短パスツリー（SPT）を計算し、そのFIBを更新し、マイクロによるパケット破壊の期間に寄与します。ループ。場合によっては、パケットがパスに沿ったリンクで連続して発生するマイクロループからの破壊の影響を受ける可能性があり、したがって、単一のループを解決するために必要な混乱の期間をさらに延長します。
Loop-free convergence techniques are applicable to any situation in which micro-loops may form, for example, the convergence of a network following: 1. Component failure
ループフリーの収束技術は、マイクロループが形成される可能性のあるあらゆる状況に適用できます。たとえば、次のネットワークの収束：1。コンポーネント障害
2. Component repair
2. コンポーネントの修理
3. Management withdrawal of a component
3. コンポーネントの管理撤回
4. Management insertion or a component
4. 管理挿入またはコンポーネント
5. Management change of link cost (either positive or negative)
5. リンクコストの管理変更（プラスまたはネガティブ）
6. External cost change, for example, change of external gateway as a result of a BGP change
6. たとえば、BGPの変更の結果としての外部ゲートウェイの変更、外部コストの変更
7. A Shared Risk Link Group (SRLG) failure
7. 共有リスクリンクグループ（SRLG）障害
In each case, a component may be a link, a set of links, or an entire router. Throughout this document, we use the term SRLG when describing the procedure to be followed when multiple failures have occurred, whether or not they are members of an explicit SRLG. In the case of multiple independent failures, the loop-prevention method described for SRLG may be used, provided it is known that all of these failures have been repaired.
いずれの場合も、コンポーネントはリンク、リンクのセット、またはルーター全体である場合があります。このドキュメント全体を通して、明示的なSRLGのメンバーであるかどうかにかかわらず、複数の障害が発生したときに追跡する手順を説明するときにSRLGという用語を使用します。複数の独立した障害の場合、SRLGについて説明されているループ再発生法を使用することができます。
Loop-free convergence techniques are applicable to both IP networks and MPLS-enabled networks that use LDP, including LDP networks that use the single-hop tunnel fast-reroute mechanism.
ループフリーの収束技術は、シングルホップトンネルファーストレーアウトメカニズムを使用するLDPネットワークを含む、LDPを使用するMPLS対応ネットワークの両方に適用できます。
An assessment of whether loop-free convergence techniques are required should take into account whether or not the interior gateway protocol (IGP) convergence is sufficiently fast that any micro-loops are of such short duration that they are not disruptive, and whether or not the topology is such that micro-loops are likely to form.
ループフリーの収束技術が必要かどうかの評価では、インテリアゲートウェイプロトコル（IGP）収束が十分に速く、マイクロループが破壊的ではないほど短い時間であるかどうか、およびトポロジは、マイクロループが形成される可能性が高いようなものです。
Micro-loop control strategies fall into four basic classes:
マイクロループ制御戦略は、4つの基本クラスに分類されます。
1. Micro-loop mitigation
1. マイクロループ緩和
2. Micro-loop prevention
2. マイクロループ予防
3. Micro-loop suppression
3. マイクロループ抑制
4. Network design to minimise micro-loops A micro-loop-mitigation scheme works by re-converging the network in such a way that it reduces, but does not eliminate, the formation of micro-loops. Such schemes cannot guarantee the productive forwarding of packets during the transition.
4. マイクロループを最小化するためのネットワーク設計マイクロループ緩和スキームは、マイクロループの形成を減らすが排除しないようにネットワークを再構成することにより機能します。このようなスキームは、移行中のパケットの生産的な転送を保証することはできません。
A micro-loop-prevention mechanism controls the re-convergence of the network in such a way that no micro-loops form. Such a micro-loop-prevention mechanism allows the continued use of any fast repair method until the network has converged on its new topology and prevents the collateral damage that occurs to other traffic for the duration of each micro-loop.
マイクロループ摂動メカニズムは、マイクロループが形成されないようにネットワークの再構成を制御します。このようなマイクロループ摂動メカニズムにより、ネットワークが新しいトポロジに収束し、各マイクロループの期間中に他のトラフィックに発生する付随的損傷を防ぐまで、任意の高速修復方法を継続的に使用できます。
A micro-loop-suppression mechanism attempts to eliminate the collateral damage caused by micro-loops to other traffic. This may be achieved by, for example, using a packet-monitoring method that detects that a packet is looping and drops it. Such schemes make no attempt to productively forward the packet throughout the network transition.
マイクロループ抑制メカニズムは、他のトラフィックへのマイクロループによって引き起こされる付随的損傷を排除しようとします。これは、たとえば、パケットがループしていることを検出してドロップすることを検出するパケットモニタリング方法を使用することによって達成される場合があります。このようなスキームは、ネットワーク遷移全体でパケットを生産的に転送しようとはしません。
Highly meshed topologies are less susceptible to micro-loops, thus networks may be designed to minimise the occurrence of micro-loops by appropriate link placement and metric settings. However, this approach may conflict with other design requirements, such as cost and traffic planning, and may not accurately track the evolution of the network or temporary changes due to outages.
高度にメッシュ化されたトポロジは、マイクロループの影響を受けにくいため、ネットワークは、適切なリンク配置とメートル法の設定により、マイクロループの発生を最小限に抑えるように設計されている可能性があります。ただし、このアプローチは、コストや交通計画など、他の設計要件と競合する可能性があり、ネットワークの進化や停止による一時的な変更を正確に追跡できない場合があります。
Note that all known micro-loop-prevention mechanisms and most micro-loop-mitigation mechanisms extend the duration of the re-convergence process. When the failed component is protected by a fast-reroute repair, this implies that the converging network requires the repair to remain in place for longer than would otherwise be the case. The extended convergence time means any traffic that is not repaired by an imperfect repair experiences a significantly longer outage than it would experience with conventional convergence.
既知のすべてのマイクロループ再発症メカニズムとほとんどのマイクロループ緩和メカニズムは、再構成プロセスの持続時間を延長することに注意してください。故障したコンポーネントが高速レアウトの修理によって保護されている場合、これは、収束ネットワークが修理を必要とすることを意味します。延長された収束時間は、不完全な修理によって修復されないトラフィックが、従来の収束で経験するよりも大幅に長い停止を経験することを意味します。
When a component is returned to service, or when a network management action has taken place, this additional delay does not cause traffic disruption because there is no repair involved. However, the extended delay is undesirable because it increases the time that the network takes to be ready for another failure, and hence leaves it vulnerable to multiple failures.
コンポーネントがサービスに戻された場合、またはネットワーク管理アクションが行われた場合、この追加の遅延は、修理が含まれないため、トラフィックの混乱を引き起こしません。ただし、延長された遅延は、ネットワークが別の障害に備えるために時間がかかる時間を増やすため、複数の障害に対して脆弱なままになるため、望ましくありません。
There are two approaches to loop mitigation.
ループ緩和には2つのアプローチがあります。
o Fast convergence
o 高速収束
o A purpose-designed, loop-mitigation mechanism
o 目的設計されたループ緩和メカニズム
The duration of micro-loops is dependent on the speed of convergence. Improving the speed of convergence may therefore be seen as a loop-mitigation technique.
マイクロループの持続時間は、収束の速度に依存します。したがって、収束の速度を改善することは、ループ測定技術と見なされる場合があります。
The only known purpose-designed, loop-mitigation approach is the Path Locking with Safe-Neighbors (PLSN) method described in PLSN [ANALYSIS]. In this method, a micro-loop-free next-hop safety condition is defined as follows:
唯一の既知の目的で設計されたループ緩和アプローチは、PLSN [分析]で説明されているセーフニーバー（PLSN）メソッドを備えたパスロックです。この方法では、マイクロループフリーのネクストホップ安全条件は次のように定義されます。
In a symmetric-cost network, it is safe for router X to change to the use of neighbor Y as its next hop for a specific destination if the path through Y to that destination satisfies both of the following criteria:
対称コストネットワークでは、ルーターXが次の目的地へのパスが次の基準を満たす場合、次の宛先の次の宛先に近隣Yの使用に変更することが安全です。
1. X considers Y as its loop-free neighbor based on the topology before the change, AND
1. xは、変化前のトポロジーに基づいて、yをループのない隣人と見なし、
2. X considers Y as its downstream neighbor based on the topology after the change.
2. xは、変化後のトポロジーに基づいて、yを下流の隣人と見なします。
In an asymmetric-cost network, a stricter safety condition is needed, and the criterion is that:
非対称コストネットワークでは、より厳しい安全条件が必要であり、基準は次のとおりです。
X considers Y as its downstream neighbor based on the topology both before and after the change.
xは、変更の前後の両方でトポロジーに基づいて、Yを下流の隣人と見なします。
Based on these criteria, destinations are classified by each router into three classes:
これらの基準に基づいて、目的地は各ルーターによって3つのクラスに分類されます。
o Type A destinations: Destinations unaffected by the change (type A1) and also destinations whose next hop after the change satisfies the safety criteria (type A2).
o タイプAの目的地：変更の影響を受けない目的地（タイプA1）と、変更後の次のホップが安全基準（タイプA2）を満たす目的地。
o Type B destinations: Destinations that cannot be sent via the new, primary next hop because the safety criteria are not satisfied, but that can be sent via another next hop that does satisfy the safety criteria.
o タイプBの目的地：安全基準が満たされていないため、新しいプライマリネクストホップで送信できない目的地は、安全基準を満たす別の次のホップを介して送信できます。
o Type C destinations: All other destinations.
o タイプCの宛先：他のすべての宛先。
Following a topology change, type A destinations are immediately changed to go via the new topology. Type B destinations are immediately changed to go via the next hop that satisfies the safety criteria, even though this is not the shortest path. Type B destinations continue to go via this path until all routers have changed their type C destinations over to the new next hop. Routers must not change their type C destinations until all routers have changed their type A2 and B destinations to the new or intermediate (safe) next hop.
トポロジの変更に続いて、タイプAの目的地はすぐに変更され、新しいトポロジを介して移動します。タイプBの目的地は、最短のパスではありませんが、安全基準を満たす次のホップを介してすぐに変更されます。タイプBの目的地は、すべてのルーターがタイプCの宛先を新しい次のホップに変更するまで、このパスを介して進み続けます。ルーターは、すべてのルーターがタイプA2およびBの宛先を新しいまたは中級（安全）次のホップに変更するまで、タイプCの宛先を変更してはなりません。
Simulations indicate that this approach produces a significant reduction in the number of links that are subject to micro-looping. However, unlike all of the micro-loop-prevention methods, it is only a partial solution. In particular, micro-loops may form on any link joining a pair of type C routers.
シミュレーションは、このアプローチがマイクロループの影響を受けるリンクの数を大幅に減らすことを示しています。ただし、すべてのマイクロループプレベーションメソッドとは異なり、それは部分的な解決策にすぎません。特に、マイクロループは、タイプCルーターのペアを結ぶリンクに形成される場合があります。
Because routers delay updating their type C destination FIB entries, they will continue to route towards the failure during the time when the routers are changing their type A and B destinations, and hence will continue to productively forward packets, provided that viable repair paths exist.
ルーターはタイプCの宛先FIBエントリの更新を遅らせるため、ルーターがタイプAとBの目的地を変更している間、障害に向かってルーティングを続け、したがって、実行可能な修理パスが存在する場合、生産的に転送され続けます。
A backwards-compatibility issue arises with PLSN. If a router is not capable of micro-loop control, it will not correctly delay its FIB update. If all such routers had only type A destinations, this loop-mitigation mechanism would work as it was designed. Alternatively, if all such incapable routers had only type C destinations, the "loop-prevention" announcement mechanism used to trigger the tunnel-based schemes (see Sections 6.2 to 6.4) could be used to cause the type A and B destinations to be changed, with the incapable routers and routers having type C destinations delaying until they received the "real" announcement. Unfortunately, these two approaches are mutually incompatible.
PLSNには後方互換性の問題が発生します。ルーターがマイクロループ制御ができない場合、FIBの更新を正しく遅らせません。そのようなルーターがすべてタイプAの宛先のみを持っていた場合、このループ測定メカニズムは、設計されたときに機能します。あるいは、そのようなすべての不可能なルーターがタイプCの宛先のみを持っていた場合、トンネルベースのスキームをトリガーするために使用される「ループプレベーション」アナウンスメカニズム（セクション6.2〜6.4を参照）を使用して、タイプAとBの宛先を変更することができます。、「実際の」発表を受け取るまで、タイプCの目的地が遅延していることができないルーターとルーターがあります。残念ながら、これらの2つのアプローチは相互に互換性がありません。
Note that simulations indicate that in most topologies treating type B destinations as type C results in only a small degradation in loop prevention. Also note that simulation results indicate that in production networks where some, but not all, links have asymmetric costs, using the stricter asymmetric-cost criterion actually reduces the number of loop-free destinations because fewer destinations can be classified as type A or B.
シミュレーションは、タイプBの目的地としてタイプBの目的地を扱うほとんどのトポロジでは、ループ予防のわずかな分解のみをもたらすことを示していることに注意してください。また、シミュレーションの結果は、すべてではないが、いくつかのリンクが非対称コストを持っている場合、より厳格な非対称コストの基準を使用して、タイプAまたはBに分類できるため、ループのない宛先の数を実際に減らすことができることを示していることに注意してください。
This mechanism operates identically for:
このメカニズムは、次のように同様に動作します。
o events that degrade the topology (e.g., link failure),
o トポロジを分解するイベント（例：リンク障害）、
o events that improve the topology (e.g., link restoration), and
o トポロジを改善するイベント（例：リンクの復元）、および
o shared risk link group (SRLG) failure.
o 共有リスクリンクグループ（SRLG）障害。
Eight micro-loop-prevention methods have been proposed:
8つのマイクロループ再発達方法が提案されています。
1. Incremental cost advertisement
1. 増分コスト広告
2. Nearside tunneling
2. 近くのトンネリング
3. Farside tunneling
3. ファーサイドトンネリング
4. Distributed tunnels
4. 分散トンネル
5. Packet marking
5. パケットマーキング
6. New MPLS labels
6. 新しいMPLSラベル
7. Ordered FIB update
7. 注文されたFIBアップデート
8. Synchronized FIB update
8. 同期したFIBアップデート
When a link fails, the cost of the link is normally changed from its assigned metric to "infinity" in one step. However, it can be proved [OPT] that no micro-loops will form if the link cost is increased in suitable increments, and the network is allowed to stabilize before the next cost increment is advertised. Once the link cost has been increased to a value greater than that of the lowest alternative cost around the link, the link may be disabled without causing a micro-loop.
リンクが失敗すると、リンクのコストは通常、1つのステップで割り当てられたメトリックから「無限」に変更されます。ただし、リンクコストが適切な増分で増加し、次のコスト増分が宣伝される前にネットワークが安定することが許可されている場合、マイクロループが形成されないことを証明できます。リンクコストがリンク周辺の最低代替コストの値よりも大きい値に増加すると、マイクロループを引き起こすことなくリンクが無効になる場合があります。
The criterion for a link cost change to be safe is that any link that is subjected to a cost change of x can only cause loops in a part of the network that has a cyclic cost less than or equal to x. Because there may exist links that have a cost of one in each direction, resulting in a cyclic cost of two, this can result in the link cost having to be raised in increments of one. However, the increment can be larger where the minimum cost permits. Recent work [OPT] has shown that there are a number of optimizations that can be applied to the problem in order to determine the exact set of cost values required, and hence minimise the number of increments.
リンクコストの変更の基準は、xのコスト変更にかけられるリンクは、循環コストがx以下のネットワークの一部にループを引き起こすことしか引き起こさないということです。各方向に1のコストを持つリンクが存在する可能性があるため、2つの循環コストになります。これにより、リンクコストを1つの増分で引き上げる必要があります。ただし、最小コストが許可されている場合は、増分が大きくなる可能性があります。最近の研究[OPT]は、必要なコスト値の正確なセットを決定するために問題に適用できる多くの最適化があることを示しているため、増分数を最小限に抑えることができます。
It will be appreciated that when a link is returned to service, its cost is reduced in small steps from "infinity" to its final cost, thereby providing similar micro-loop prevention during a "good-news" event. Note that the link cost may be decreased from "infinity" to any value greater than that of the lowest alternative cost around the link in one step without causing a micro-loop.
リンクがサービスに戻されると、そのコストが「無限」から最終コストまでの小さなステップでコストが削減され、それにより「おいしい」イベント中に同様のマイクロループ予防が提供されることを理解しています。リンクコストは、マイクロループを引き起こすことなく、1つのステップでリンクの周りの最低の代替コストの値よりも大きな値に減少する可能性があることに注意してください。
When the failure is an SRLG, the link cost increments must be coordinated across all failing members of the SRLG. This may be achieved by completing the transition of one link before starting the next or by interleaving the changes.
障害がSRLGの場合、リンクコストの増加は、SRLGのすべての失敗したメンバーで調整する必要があります。これは、次のリンクを開始する前に1つのリンクの遷移を完了するか、変更をインテリアすることで達成できます。
The incremental cost change approach has the advantage over all other currently known loop-prevention schemes in that it requires no change to the routing protocol. It will work in any network because it does not require any cooperation from the other routers in the network.
インクリメンタルコスト変更アプローチは、ルーティングプロトコルに変更を必要としないという点で、現在既知の他のすべてのループ再発電スキームよりも利点があります。ネットワーク内の他のルーターからの協力を必要としないため、どのネットワークでも機能します。
Where the micro-loop-prevention mechanism is being used to support a planned reconfiguration of the network, the extended total reconvergence time resulting from the multiple increments is of limited consequence, particularly where the number of increments have been optimized. This, together with the ability to implement this technique in isolation, makes this method a good candidate for use with such management-initiated changes.
ネットワークの計画的な再構成をサポートするためにマイクロループ再発生メカニズムが使用されている場合、複数の増分に起因する拡張された総再変数時間は、特に増分数が最適化されている場合、結果として限られています。これは、この手法を単独で実装する能力とともに、この方法をそのような管理によって開始された変更で使用する適切な候補になります。
Where the micro-loop-prevention mechanism is being used to support failure recovery, the number of increments required, and hence the time taken to fully converge, is significant even for small numbers of increments. This is because, for the duration of the transition, some parts of the network continue to use the old forwarding path, and hence use any repair mechanism for an extended period. In the case of a failure that cannot be fully repaired, some destinations may therefore become unreachable for an extended period. In addition, the network may be vulnerable to a second failure for the duration of the controlled re-convergence.
故障回復をサポートするためにマイクロループ再発生メカニズムが使用されている場合、必要な増分の数、したがって完全に収束するのにかかる時間は、少数の増分でも重要です。これは、移行期間中、ネットワークの一部が古い転送パスを引き続き使用し続けるため、長期間にわたって修理メカニズムを使用しているためです。したがって、完全に修理できない障害の場合、一部の目的地は長期間到達できなくなる可能性があります。さらに、ネットワークは、制御された再構成の期間中、2回目の障害に対して脆弱である可能性があります。
Where large metrics are used and no optimization (such as that described above) is performed, the incremental cost method can be extremely slow. However, in cases where the per-link metric is small, either because small values have been assigned by the network designers or because of restrictions implicit in the routing protocol (e.g., RIP restricts the metric, and BGP using the autonomous system (AS) path length frequently uses an effective metric of one or a very small integer for each inter AS hop), the number of required increments can be acceptably small even without optimizations.
大規模なメトリックが使用され、最適化（上記のようなものなど）が実行されない場合、増分コスト法は非常に遅くなる可能性があります。ただし、リンクごとのメトリックが小さい場合、ネットワークデザイナーによって小さな値が割り当てられているか、ルーティングプロトコルに暗黙の制限のために（例えば、RIPがメトリックを制限し、自律システムを使用してBGPを使用してBGPがパスの長さは、ホップとして各インターの1つまたは非常に小さな整数の有効なメトリックを使用することがよくあります。
This mechanism works by creating an overlay network using tunnels whose path is not affected by the topology change and then carrying the traffic affected by the change in that new network. When all the traffic is in the new, tunnel-based network, the real network is allowed to converge on the new topology. Because all the traffic that would be affected by the change is carried in the overlay network, no micro-loops form.
このメカニズムは、トポロジの変化によってパスが影響を受けないトンネルを使用してオーバーレイネットワークを作成し、その新しいネットワークの変更によって影響を受けるトラフィックを運ぶことで機能します。すべてのトラフィックが新しいトンネルベースのネットワークにある場合、実際のネットワークは新しいトポロジに収束することができます。変更によって影響を受けるすべてのトラフィックはオーバーレイネットワークで運ばれるため、マイクロループの形はありません。
When a failure is detected (or a link is withdrawn from service), the router adjacent to the failure issues a new "loop-prevention" routing message announcing the topology change. This message is propagated through the network by all routers but is only understood by routers capable of using one of the tunnel-based, micro-loop-prevention mechanisms.
障害が検出された場合（またはリンクがサービスから撤回されます）、障害に隣接するルーターは、トポロジの変更を発表する新しい「ループプレベーション」ルーティングメッセージを発行します。このメッセージは、すべてのルーターによってネットワークを介して伝播されますが、トンネルベースのマイクロループ再発生メカニズムの1つを使用できるルーターによってのみ理解されます。
Each of the micro-loop-preventing routers builds a tunnel to the closest router adjacent to the failure. They then determine which of their traffic would transit the failure and place that traffic in the tunnel. When all of these tunnels are in place (determined, for example, by waiting a suitable interval), the failure is announced as normal. Because these tunnels will be unaffected by the transition and because the routers protecting the link will continue the repair (or forward across the link being withdrawn), no traffic will be disrupted by the failure. When the network has converged, these tunnels are withdrawn, allowing traffic to be forwarded along its new, "natural" path. The order of tunnel insertion and withdrawal is not important, provided that the tunnels are all in place before the normal announcement is issued and that the repair remains in place until normal convergence has completed.
各マイクロループ予防ルーターは、障害に隣接する最も近いルーターへのトンネルを構築します。次に、どのトラフィックが故障を通過し、そのトラフィックをトンネルに配置するかを決定します。これらのすべてのトンネルが配置されている場合（たとえば、適切な間隔を待つことにより決定）、障害は通常のように発表されます。これらのトンネルは遷移の影響を受けません。また、リンクを保護するルーターが修理を継続する（またはリンクを横切って撤回される前方）になるため、障害によってトラフィックは破壊されません。ネットワークが収束すると、これらのトンネルが撤回され、新しい「自然な」パスに沿ってトラフィックを転送できます。トンネルの挿入と撤退の順序は重要ではありません。ただし、通常の発表が発行される前にトンネルがすべて整っており、通常の収束が完了するまで修理が施行されていることを条件としています。
This method completes in bounded time and is generally much faster than the incremental cost method. Depending on the exact design, it completes in two or three flood-SPF-FIB update cycles.
この方法は、限界時間に完了し、一般に増分コスト法よりもはるかに高速です。正確な設計に応じて、2つまたは3つの洪水SPF-FIB更新サイクルで完了します。
At the time at which the failure is announced as normal, micro-loops may form within isolated islands of non-micro-loop-preventing routers. However, only traffic entering the network via such routers can micro-loop. All traffic entering the network via a micro-loop-preventing router will be tunneled correctly to the nearest repairing router -- including, if necessary, being tunneled via a non-micro-loop-preventing router -- and will not micro-loop.
故障が通常どおり発表されている時点で、マイクロループは、非ミクロープ予防ルーターの孤立した島内で形成される可能性があります。ただし、このようなルーターを介してネットワークに入るトラフィックのみがマイクロループできます。マイクロループ予防ルーターを介してネットワークに入るすべてのトラフィックは、必要に応じて、非ミクローププレベーションルーターを介してトンネル化されるなど、最も近い修理ルーターに正しくトンネルされ、マイクロループはありません。
Where there is no requirement to prevent the formation of micro-loops involving non-micro-loop-preventing routers, a single, "normal" announcement may be made and a local timer used to determine the time at which transition from tunneled forwarding to normal forwarding over the new topology may commence.
非ミクロループ予防ルーターを含むマイクロループの形成を防ぐための要件がない場合、単一の「通常の」発表が行われ、トンネル転送から正常への移行時間を決定するためにローカルタイマーが使用される場合があります新しいトポロジを転送することができます。
This technique has the disadvantage that it requires traffic to be tunneled during the transition. This is an issue in IP networks because not all router designs are capable of high-performance IP tunneling. It is also an issue in MPLS networks because the encapsulating router has to know the label set that the decapsulating router is distributing.
この手法には、移行中にトラフィックをトンネルする必要があるという不利な点があります。これは、すべてのルーター設計が高性能IPトンネリングが可能であるわけではないため、IPネットワークの問題です。また、カプセンシングルーターが脱カプセンシングルーターが分布しているというラベルセットを知る必要があるため、MPLSネットワークの問題でもあります。
A further disadvantage of this method is that it requires cooperation from all the routers within the routing domain to fully protect the network against micro-loops.
この方法のさらに欠点は、ネットワークをマイクロループから完全に保護するために、ルーティングドメイン内のすべてのルーターからの協力が必要であることです。
When a new link is added, the mechanism is run in "reverse". When the loop-prevention announcement is heard, routers determine which traffic they will send over the new link and tunnel that traffic to the router on the near side of that link. This path will not be affected by the presence of the new link. When the "normal" announcement is heard, they then update their FIB to send the traffic normally, according to the new topology. Any traffic encountering a router that has not yet updated its FIB will be tunneled to the near side of the link, and will therefore not loop.
新しいリンクが追加されると、メカニズムは「逆」で実行されます。ループプレベーションの発表が聞こえると、ルーターは、そのリンクの近くにあるルーターへのトラフィックを新しいリンクとトンネルに送信するトラフィックを決定します。このパスは、新しいリンクの存在によって影響を受けません。新しいトポロジーによると、「通常の」発表が聞こえると、FIBを更新して正常にトラフィックを送信します。まだ更新されていないルーターに遭遇するトラフィックは、そのFIBがリンクの近くにトンネルされるため、ループしません。
When a management change to the topology is required, again exactly the same mechanism protects against micro-looping of packets by the micro-loop-preventing routers.
トポロジーの管理の変更が必要な場合、繰り返しますが、まったく同じメカニズムは、マイクロループ予防ルーターによるパケットのマイクロループから保護されます。
When the failure is an SRLG, the required strategy is to classify traffic according the furthest failing member of the SRLG that it will traverse on its way to the destination, and to tunnel that traffic to the repairing router for that SRLG member. This will require multiple tunnel destinations -- in the limiting case, one per SRLG member.
障害がSRLGの場合、必要な戦略は、目的地に向かう途中で横断するSRLGの最も遠い失敗したメンバーに従ってトラフィックを分類し、そのトラフィックをそのSRLGメンバーの修理ルーターにトンネルすることです。これには、制限的な場合、SRLGメンバーごとに1つの複数のトンネル宛先が必要です。
Farside tunneling loop prevention requires the loop-preventing routers to place all of the traffic that would traverse the failure in one or more tunnels terminating at the router (or, in the case of node failure, routers) at the far side of the failure. The properties of this method are a more uniform distribution of repair traffic than is achieved using the nearside tunnel method and, in the case of node failure, a reduction in the decapsulation load on any single router.
Farside Tunnelingループ予防には、ループを予防するルーターが、ルーターで終了する1つまたは複数のトンネルの障害を横断するすべてのトラフィックを配置する必要があります（または、ノード障害の場合、ルーター）障害の向こう側にあります。この方法の特性は、近距離トンネル法を使用して達成されるよりも修理トラフィックのより均一な分布であり、ノード障害の場合、単一のルーターの脱カプセル化負荷の減少です。
Unlike the nearside tunnel method (which uses normal routing to the repairing router), this method requires the use of a repair path to the farside router. This may be provided by the not-via [NOT-VIA] mechanism, in which case no further computation is needed.
この方法では、近距離トンネルメソッド（修理ルーターへの通常のルーティングを使用します）とは異なり、ファーサイドルーターへの修理パスを使用する必要があります。これは、not-via [not-via]メカニズムによって提供される場合があります。その場合、それ以上の計算は必要ありません。
The mode of operation is otherwise identical to the nearside tunneling loop-prevention method (Section 6.2).
それ以外の場合は、動作モードは、近距離トンネルループ再発生法と同じです（セクション6.2）。
In the distributed tunnels loop-prevention method, each router calculates its own repair and forwards traffic affected by the failure using that repair. Unlike the fast reroute (FRR) case, the actual failure is known at the time of the calculation. The objective of the loop-preventing routers is to get the packets that would have gone via the failure into Q-space [FRR-TUNN] using routers that are in P-space. Because packets are decapsulated on entry to Q-space, rather than being forced to go to the farside of the failure, more optimum routing may be achieved. This method is subject to the same reachability constraints described in [FRR-TUNN].
分散トンネルループプレベーション法では、各ルーターが独自の修理を計算し、その修理を使用して障害によって影響を受けるトラフィックを転送します。Fast Reroute（FRR）の場合とは異なり、実際の障害は計算時に知られています。ループプレベーションルーターの目的は、Pスペースにあるルーターを使用してQ-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-SPACE [FRR-TUNN]に移行したパケットを取得することです。パケットはQスペースへの入力時に脱カプセル化されているため、障害の遠方に移動することを余儀なくされるのではなく、より最適なルーティングが達成される場合があります。この方法は、[frr-tunn]で説明されている同じ到達可能性の制約の対象となります。
The mode of operation is otherwise identical to the nearside tunneling loop-prevention method (Section 6.2).
それ以外の場合は、動作モードは、近距離トンネルループ再発生法と同じです（セクション6.2）。
An alternative distributed tunnel mechanism is for all routers to tunnel to the not-via address [NOT-VIA] associated with the failure.
代替分散トンネルメカニズムは、すべてのルーターが障害に関連する非VIAアドレス[not-via]にトンネルするためのものです。
If packets could be marked in some way, this information could be used to assign them to one of:
パケットを何らかの方法でマークすることができれば、この情報を使用して次のいずれかに割り当てることができます。
o the new topology,
o 新しいトポロジー、
o the old topology, or
o 古いトポロジー、または
o a transition topology.
o 遷移トポロジ。
They would then be correctly forwarded during the transition. This mechanism works identically for both "bad-news" and "good-news" events. It also works identically for SRLG failure. There are three problems with this solution:
その後、移行中に正しく転送されます。このメカニズムは、「悪いニュース」と「おはよう」イベントの両方で同じように機能します。また、SRLG障害に対しても同様に機能します。この解決策には3つの問題があります。
o A packet-marking bit may not be available, for example, a network supporting both the differentiated services architecture [RFC2475] and explicit congestion notification [RFC3168] uses all eight bits of the IPv4 Type of Service field.
o たとえば、差別化されたサービスアーキテクチャ[RFC2475]と明示的な混雑通知[RFC3168]の両方をサポートするネットワークは、IPv4タイプのサービスフィールドの8ビットすべてを使用します。
o The mechanism would introduce a non-standard forwarding procedure.
o メカニズムは、非標準の転送手順を導入します。
o Packet marking using either the old or the new topology would double the size of the FIB; however, some optimizations may be possible.
o 古いトポロジーまたは新しいトポロジのいずれかを使用したパケットマーキングは、FIBのサイズを2倍にします。ただし、いくつかの最適化が可能になる場合があります。
In an MPLS network that is using [RFC5036] for label distribution, loop-free convergence can be achieved through the use of new labels when the path that a prefix will take through the network changes.
[RFC5036]をラベル分布に使用しているMPLSネットワークでは、ネットワークを介してプレフィックスが採用するパスが変更される場合に、新しいラベルを使用することでループフリーの収束を実現できます。
As described in Section 6.2, the repairing routers issue a loop-prevention announcement to start the loop-free convergence process. All loop-preventing routers calculate the new topology and determine whether their FIB needs to be changed. If there is no change in the FIB, they take no part in the following process.
セクション6.2で説明されているように、修理ルーターはループプレベーションアナウンスを発行して、ループフリーの収束プロセスを開始します。すべてのループプレベーションルーターは、新しいトポロジーを計算し、FIBを変更する必要があるかどうかを判断します。FIBに変更がない場合、それらは次のプロセスに参加しません。
The routers that need to make a change to their FIB consider each change and check the new next hop to determine whether it will use a path in the OLD topology that reaches the destination without traversing the failure (i.e., the next hop is in P-space with respect to the failure [FRR-TUNN]). If so, the FIB entry can be immediately updated. For all of the remaining FIB entries, the router issues a new label to each of its neighbors. This new label is used to lock the path during the transition in a similar manner to the previously described method for loop-free convergence with tunnels (Section 6.2). Routers receiving a new label install it in their FIB for MPLS label translation, but do not yet remove the old label and do not yet use this new label to forward IP packets, i.e., they prepare to forward using the new label on the new path but do not use it yet. Any packets received continue to be forwarded the old way, using the old labels, towards the repair.
FIBに変更を加える必要があるルーターは、各変更を検討し、新しい次のホップをチェックして、障害を横断せずに目的地に到達する古いトポロジのパスを使用するかどうかを判断します（つまり、次のホップはp-にあります。障害に関するスペース[frr-tunn]）。その場合、FIBエントリはすぐに更新できます。残りのすべてのFIBエントリについて、ルーターはそれぞれの隣人に新しいラベルを発行します。この新しいラベルは、トンネルとのループフリーの収束のために、前述の方法と同様の方法で遷移中にパスをロックするために使用されます（セクション6.2）。新しいラベルを受信するルーターMPLSラベル翻訳用のFIBにインストールしますが、古いラベルをまだ削除せず、この新しいラベルをまだ使用してIPパケットを転送しません。つまり、新しいパスで新しいラベルを使用して転送する準備をしますただし、まだ使用しないでください。受け取ったパケットは、古いラベルを使用して、修理に向けて古い方法で転送され続けています。
At some time after the loop-prevention announcement, a normal routing announcement of the failure is issued. This announcement must not be issued until such time as all routers have carried out all of their activities that were triggered by the loop-prevention announcement. On receipt of the normal announcement, all routers that were delaying convergence move to their new path for both the new and the old labels. This involves changing the IP address entries to use the new labels AND changing the old labels to forward using the new labels.
ループプレベーションの発表の後の時点で、障害の通常のルーティングアナウンスが発行されます。この発表は、すべてのルーターがループプレベーションの発表によって引き起こされたすべてのアクティビティを実行するまで発行されてはなりません。通常の発表を受け取ると、収束が遅れていたすべてのルーターは、新しいラベルと古いラベルの両方で新しいパスに移動します。これには、IPアドレスエントリを変更して新しいラベルを使用して、古いラベルを変更して新しいラベルを使用して転送することが含まれます。
Because the new label path was installed during the loop-prevention phase, packets reach their destinations as follows:
新しいラベルパスはループプレベーションフェーズ中にインストールされたため、パケットは次のように目的地に到達します。
o If they do not go via any router using a new label, they go via the repairing router and the repair.
o 新しいラベルを使用してルーターを介して行かない場合、修理ルーターと修理を介して移動します。
o If they meet any router that is using the new labels, they get marked with the new labels and reach their destination using the new path, back-tracking if necessary.
o 新しいラベルを使用しているルーターを満たしている場合、新しいパスを使用して新しいラベルでマークされ、必要に応じてバックトラッキングを使用して目的地に到達します。
When all routers have changed to the new path, the network is converged. At some later time, when it can be assumed that all routers have moved to using the new path, the FIB can be cleaned up to remove the, now redundant, old labels.
すべてのルーターが新しいパスに変更されると、ネットワークが収束されます。後で、すべてのルーターが新しいパスの使用に移行したと想定できる場合、FIBをクリーンアップして、現在冗長で古いラベルを削除できます。
As with other methods, the new labels may be modified to provide loop prevention for "good news". There are also a number of optimizations of this method.
他の方法と同様に、新しいラベルを変更して、「良いニュース」のループ予防を提供する場合があります。また、この方法の多くの最適化もあります。
The ordered FIB loop prevention method is described in "Loop-free convergence using oFIB" [oFIB]. Micro-loops occur following a failure or a cost increase, when a router closer to the failed component revises its routes to take account of the failure before a router that is further away. By analyzing the reverse shortest path tree (rSPT) over which traffic is directed to the failed component in the old topology, it is possible to determine a strict ordering that ensures that nodes closer to the root always process the failure after any nodes further away, and hence micro-loops are prevented.
秩序化されたFIBループ予防方法は、[Ofib]を使用した「ループフリー収束」で説明されています。マイクロループは、故障またはコストの増加に続いて発生します。故障したコンポーネントに近いルーターがルートを修正して、遠く離れたルーターの前に障害を考慮します。古いトポロジの故障したコンポーネントにトラフィックが向けられる逆の最短パスツリー（RSPT）を分析することにより、ルートに近いノードが常に障害を処理することを保証する厳格な順序を決定することができます。したがって、マイクロループが防止されます。
When the failure has been announced, each router waits a multiple of the convergence timer [LF-TIMERS]. The multiple is determined by the node's position in the rSPT, and the delay value is chosen to guarantee that a node can complete its processing within this time. The convergence time may be reduced by employing a signaling mechanism to notify the parent when all the children have completed their processing, and hence when it is safe for the parent to instantiate its new routes.
障害が発表されると、各ルーターはコンバージェンスタイマー[LFタイマー]の倍数を待ちます。倍数はRSPTにおけるノードの位置によって決定され、遅延値は選択され、ノードがこの時間内に処理を完了できることを保証します。収束時間は、すべての子供が処理を完了したときに親に通知するシグナリングメカニズムを使用することで短縮される可能性があります。
The property of this approach is therefore that it imposes a delay that is bounded by the network diameter, although in many cases it will be much less.
したがって、このアプローチの特性は、ネットワークの直径に囲まれた遅延を課すことですが、多くの場合ははるかに少なくなります。
When a link is returned to service, the convergence process above is reversed. A router first determines its distance (in hops) from the new link in the NEW topology. Before updating its FIB, it then waits a time equal to the value of that distance multiplied by the convergence timer.
リンクがサービスに返されると、上記の収束プロセスが逆転します。ルーターは、最初に新しいトポロジの新しいリンクから（ホップで）距離を決定します。FIBを更新する前に、その距離の値に収束タイマーを掛けた時間に等しい時間を待ちます。
It will be seen that network-management actions can similarly be undertaken by treating a cost increase in a manner similar to a failure and a cost decrease similar to a restoration.
ネットワーク管理アクションは、障害と同様の方法でコストの増加を扱い、復元と同様のコストの減少を扱うことにより、同様に行うことができることがわかります。
The ordered FIB mechanism requires all nodes in the domain to operate according to these procedures, and the presence of non-cooperating nodes can give rise to loops for any traffic that traverses them (not just traffic that is originated through them). Without additional mechanisms, these loops could remain in place for a significant time.
順序付けられたFIBメカニズムには、これらの手順に従って動作するためにドメイン内のすべてのノードが必要であり、非協力ノードの存在は、それらを通過するトラフィックのループを引き起こす可能性があります（それらを介して発生するトラフィックだけでなく）。追加のメカニズムがなければ、これらのループはかなりの時間を維持することができます。
It should be noted that this method requires per-router ordering but not per-prefix ordering. A router must wait its turn to update its FIB, but it should then update its entire FIB.
この方法では、ルーターごとの順序付けが必要であるが、プレフィックスごとの順序付けは必要ないことに注意する必要があります。ルーターはFIBを更新するためにターンを待つ必要がありますが、FIB全体を更新する必要があります。
When an SRLG failure occurs, a router must classify traffic into the classes that pass over each member of the SRLG. Each router is then independently assigned a ranking with respect to each SRLG member for which they have a traffic class. These rankings may be different for each traffic class. The prefixes of each class are then changed in the FIB according to the ordering of their specific ranking. Again, as for the single failure case, signaling may be used to speed up the convergence process.
SRLG障害が発生した場合、ルーターはSRLGの各メンバーを渡すクラスにトラフィックを分類する必要があります。各ルーターは、トラフィッククラスを持っている各SRLGメンバーに関して、独立してランキングを割り当てられます。これらのランキングは、トラフィッククラスごとに異なる場合があります。次に、各クラスの接頭辞は、特定のランキングの順序に応じてFIBで変更されます。繰り返しますが、単一の障害の場合については、シグナリングを使用して収束プロセスを高速化することができます。
Note that the special SRLG case of a full or partial node failure can be dealt with without using per-prefix ordering by running a single reverse-SPF computation rooted at the failed node (or common point of the subset of failing links in the partial case).
完全または部分ノードの障害の特別なSRLGケースは、障害のあるノード（または部分的なケースの故障リンクのサブセットの共通点の共通点でルート化された単一の逆SPF計算を実行することで、Prefixあたりの順序付けを使用せずに対処できることに注意してください。）。
There are two classes of signaling optimization that can be applied to the ordered FIB loop-prevention method:
順序付けられたFIBループプレベーション法に適用できる2つのクラスのシグナリング最適化があります。
o When the router makes NO change, it can signal immediately. This significantly reduces the time taken by the network to process long chains of routers that have no change to make to their FIB.
o ルーターが変更されない場合、すぐに信号を送信できます。これにより、ネットワークが取った時間が大幅に短縮され、FIBに変更するための変更がないルーターの長いチェーンを処理します。
o When a router HAS changed, it can signal that it has completed. This is more problematic since this may be difficult to determine, particularly in a distributed architecture, and the optimization obtained is the difference between the actual time taken to make the FIB change and the worst-case timer value. This saving could be of the order of one second per hop.
o ルーターが変更されたら、完了したことを示すことができます。これは、特に分散アーキテクチャで決定するのが難しい可能性があるため、これはより問題があり、得られた最適化は、FIBの変更を行うために取られた実際の時間と最悪のタイマー値の違いです。この保存は、1秒あたり1秒のオーダーである可能性があります。
There is another method of executing ordered FIB that is based on pure signaling [SIG]. Methods that use signaling as an optimization are safe because eventually they fall back on the established IGP mechanisms that ensure that networks converge under conditions of packet loss. However, a mechanism that relies on signaling in order to converge requires a reliable signaling mechanism that must be proven to recover from any failure circumstance.
純粋なシグナル伝達[SIG]に基づいた秩序化されたFIBを実行する別の方法があります。シグナリングを最適化として使用する方法は安全です。最終的には、パケット損失の条件下でネットワークが収束することを保証する確立されたIGPメカニズムに戻るためです。ただし、収束するためにシグナル伝達に依存するメカニズムには、障害の状況から回復することが証明されなければならない信頼できるシグナル伝達メカニズムが必要です。
Micro-loops form because of the asynchronous nature of the FIB update process during a network transition. In many router architectures, it is the time taken to update the FIB itself that is the dominant term. One approach would be to have two FIBs and, in a synchronized action throughout the network, to switch from the old to the new. One way to achieve this synchronized change would be to signal or otherwise determine the wall clock time of the change and then execute the change at that time, using NTP [RFC1305] to synchronize the wall clocks in the routers.
ネットワーク遷移中のFIB更新プロセスの非同期性のために、マイクロループが形成されます。多くのルーターアーキテクチャでは、支配的な用語であるFIB自体を更新するのにかかる時間です。1つのアプローチは、2つのFIBを持ち、ネットワーク全体で同期したアクションで、古いものから新しいものに切り替えることです。この同期された変化を達成する1つの方法は、NTP [RFC1305]を使用してルーターの壁の時計を同期させて、変更の壁の時計時間を信号または他の方法で決定し、その時点で変更を実行することです。
This approach has a number of major issues. Firstly, two complete FIBs are needed, which may create a scaling issue; secondly, a suitable network-wide synchronization method is needed. However, neither of these are insurmountable problems.
このアプローチには多くの大きな問題があります。第一に、2つの完全なFIBが必要であり、スケーリングの問題が発生する場合があります。第二に、適切なネットワーク全体の同期方法が必要です。ただし、これらはどちらも乗り越えられない問題ではありません。
Since the FIB change synchronization will not be perfect, there may be some interval during which micro-loops form. Whether this scheme is classified as a micro-loop-prevention mechanism or a micro-loop-mitigation mechanism within this taxonomy is therefore dependent on the degree of synchronization achieved.
FIB変更の同期は完全ではないため、マイクロループが形成される間隔があるかもしれません。したがって、このスキームがマイクロループ再発電メカニズムまたはマイクロループ緩和メカニズムとして分類されているかどうかは、したがって、達成された同期の程度に依存します。
This mechanism works identically for both "bad-news" and "good-news" events. It also works identically for SRLG failure. Further consideration needs to be given to interoperating with routers that do not support this mechanism. Without a suitable interoperating mechanism, loops may form for the duration of the synchronization delay.
このメカニズムは、「悪いニュース」と「おはよう」イベントの両方で同じように機能します。また、SRLG障害に対しても同様に機能します。このメカニズムをサポートしていないルーターとの相互運用には、さらなる考慮が必要です。適切な相互運用メカニズムがなければ、同期遅延の期間にわたってループが形成される場合があります。
All of the tunnel methods and packet marking can be combined with PLSN (see Section 5.2 of this document and [ANALYSIS]) to reduce the traffic that needs to be protected by the advanced method. Specifically, all traffic could use PLSN except traffic between a pair of routers, both of which consider the destination to be type C. The type-C-to-type-C traffic would be protected from micro-looping through the use of a loop-prevention method.
すべてのトンネルメソッドとパケットマーキングをPLSNと組み合わせることができ（このドキュメントのセクション5.2および[分析]）、高度な方法で保護する必要があるトラフィックを減らすことができます。具体的には、すべてのトラフィックは、ルーターのペア間のトラフィックを除いてPLSNを使用できます。どちらも宛先がタイプCであると考えています。タイプCからタイプのトラフィックは、ループを使用してマイクロループから保護されます。 - 摂取方法。
However, determining whether the new next-hop router considers a destination to be type C may be computationally intensive. An alternative approach would be to use a loop-prevention method for all local type C destinations. This would not require any additional computation, but would require the additional loop-prevention method to be used in cases that would not have generated loops (i.e., when the new next-hop router considered this to be a type A or B destination).
ただし、新しいNext-Hopルーターが宛先をタイプCと見なすかどうかを判断することは、計算的に集中的である可能性があります。別のアプローチは、すべてのローカルタイプCの宛先にループプレベーション方法を使用することです。これには追加の計算は必要ありませんが、生成されたループ（つまり、新しいNext-HopルーターがこれをタイプAまたはB宛先と見なした場合）で生成されなかった場合に追加のループ摂取方法を使用する必要があります。
The amount of traffic that would use PLSN is highly dependent on the network topology and the specific change, but would be expected to be in the range of 70% to 90% in typical networks.
PLSNを使用するトラフィックの量は、ネットワークトポロジと特定の変化に大きく依存しますが、典型的なネットワークでは70％から90％の範囲になると予想されます。
However, PLSN cannot be combined safely with ordered FIB. Consider the network fragment shown below:
ただし、PLSNは順序付けられたFIBと安全に組み合わせることはできません。以下に示すネットワークフラグメントを考えてみましょう。
R
/|\
/ | \
1/ 2| \3
/ | \ cost S->T = 10
Y-----X----S----T cost T->S = 1
| 1 2 |
|1 |
D---------------+
20
On failure of link XY, according to PLSN, S will regard R as a safe neighbor for traffic to D. However, the ordered FIB rank of both R and T will be zero, and hence these can change their FIBs during the same time interval. If R changes before T, then a loop will form around R, T, and S. This can be prevented by using a stronger safety condition than PLSN currently specifies, at the cost of introducing more type C routers, and hence reducing the PLSN coverage.
PLSNによると、リンクXYの障害時に、SはRをDへのトラフィックの安全な隣接と見なします。ただし、RとTの両方の順序付けられたFIBランクはゼロになり、したがって、これらは同じ時間間隔でFIBを変更する可能性があります。。rがTの前に変化する場合、ループはR、T、およびSの周りに形成されます。これは、PLSNが現在指定しているよりも強力な安全条件を使用して、より多くのタイプCルーターを導入し、PLSNカバレッジを減らすことで防止できます。。
A micro-loop-suppression mechanism recognizes that a packet is looping and drops it. One such approach would be for a router to recognize, by some means, that it had seen the same packet before. It is difficult to see how sufficiently reliable discrimination could be achieved without some form of per-router signature, such as route recording. A packet-recognizing approach therefore seems infeasible.
マイクロループ抑制メカニズムは、パケットがループしていることを認識し、ドロップします。そのようなアプローチの1つは、ルーターが以前に同じパケットを見たことがあることをルーターが認識することです。ルート記録など、何らかの形のルーターごとの署名がなければ、どれほど信頼できる差別を達成できるかを見ることは困難です。したがって、パケット認識アプローチは実行不可能と思われます。
An alternative approach would be to recognize that a packet was looping by recognizing that it was being sent back to the place from which it had just come. This would work for the types of loop that form in symmetric-cost networks, but would not suppress the cyclic loops that form in asymmetric networks or as a result of multiple failures.
別のアプローチは、パケットが来たばかりの場所に送り返されていることを認識することにより、パケットがループしていることを認識することです。これは、対称コストネットワークで形成されるが、非対称ネットワークで形成される環状ループまたは複数の障害の結果として抑制されないタイプのループで機能します。
This mechanism operates identically for both "bad-news" events, "good-news" events, and SRLG failure.
このメカニズムは、両方の「悪いニュース」イベント、「おはよう」イベント、およびSRLG障害の両方で同じように動作します。
Deployment of any micro-loop-control mechanism is a major change to a network. Full consideration must be given to interoperation between routers that are capable of micro-loop control and those that are not. Additionally, there may be a desire to limit the complexity of micro-loop control by choosing a method based purely on its simplicity. Any such decision must take into account that if a more capable scheme is needed in the future, its deployment might be complicated by interaction with the scheme previously deployed.
マイクロループ制御メカニズムの展開は、ネットワークの大きな変化です。マイクロループ制御が可能なルーターとそうでないルーター間の相互操作を完全に考慮する必要があります。さらに、純粋にそのシンプルさに基づいてメソッドを選択することにより、マイクロループ制御の複雑さを制限したいという願望があるかもしれません。そのような決定は、将来、より有能なスキームが必要な場合、以前に展開されたスキームとの相互作用によって展開が複雑になる可能性があることを考慮に入れなければなりません。
PLSN [ANALYSIS] is an efficient mechanism to prevent the formation of micro-loops but is only a partial solution. It is a useful adjunct to some of the complete solutions but may need modification.
PLSN [分析]は、マイクロループの形成を防ぐための効率的なメカニズムですが、部分的なソリューションにすぎません。これは、いくつかの完全なソリューションの一部に有用な補助ですが、変更が必要になる場合があります。
Incremental cost advertisement in its simplest form is impractical as a general solution because it takes too long to complete. Optimized incremental cost advertisement, however, completes in much less time and requires no assistance from other routers in the network. It is therefore useful for network-reconfiguration operations.
最も単純な形式での増分コスト広告は、完了するのに時間がかかりすぎるため、一般的なソリューションとして非現実的です。ただし、最適化された増分コスト広告は、はるかに短い時間で完了し、ネットワーク内の他のルーターからの支援を必要としません。したがって、ネットワーク再構成操作に役立ちます。
Packet marking is probably impractical because of the need to find the marking bit and to change the forwarding behavior.
パケットマーキングは、マーキングビットを見つけて転送動作を変更する必要があるため、おそらく非現実的です。
Of the remaining methods, distributed tunnels is significantly more complex than nearside or farside tunnels and should only be considered if there is a requirement to distribute the tunnel decapsulation load.
残りの方法のうち、分布したトンネルは、近距離またはファラサイドのトンネルよりもはるかに複雑であり、トンネルの脱カプセル化荷重を分配する必要がある場合にのみ考慮する必要があります。
Synchronised FIBs is a fast method but has the issue that a suitable synchronization mechanism needs to be defined. One method would be to use NTP [RFC1305]; however, the coupling of routing convergence to a protocol that uses the network may be a problem. During the transition, there will be some micro-looping for a short interval because it is not possible to achieve complete synchronization of the FIB changeover.
同期されたFIBは高速な方法ですが、適切な同期メカニズムを定義する必要があるという問題があります。1つの方法は、NTP [RFC1305]を使用することです。ただし、ネットワークを使用するプロトコルへのルーティング収束の結合が問題になる可能性があります。遷移中、FIB切り替えの完全な同期を達成することは不可能であるため、短い間隔のマイクロルーピングがあります。
The ordered FIB mechanism has the major advantage that it is a control-plane-only solution. However, SRLGs require a per-destination calculation and the convergence delay may be high, bounded by the network diameter. The use of signaling as an accelerator may reduce the number of destinations that experience the full delay, and hence reduce the total re-convergence time to an acceptable period.
秩序化されたFIBメカニズムには、コントロールプレーンのみのソリューションであるという主な利点があります。ただし、SRLGSには、照明ごとの計算が必要であり、収束遅延が高く、ネットワークの直径に囲まれている場合があります。加速器としてのシグナリングの使用は、完全な遅延を経験する目的地の数を減らすことができ、したがって、合計再構成時間を許容期間まで短縮する可能性があります。
The nearside and farside tunnel methods deal relatively easily with SRLGs and uncorrelated changes. The convergence delay would be small. However, these methods require the use of tunneled forwarding, which is not supported on all router hardware, and raises issues of forwarding performance. When used with PLSN, the amount of traffic that was tunneled would be significantly reduced, thus reducing the forwarding performance concerns. If the selected repair mechanism requires the use of tunnels, then a tunnel-based loop prevention scheme may be acceptable.
近距離およびファシュールトンネルの方法は、SRLGと無相関の変更を比較的簡単に処理します。収束遅延は小さいでしょう。ただし、これらの方法では、すべてのルーターハードウェアではサポートされておらず、転送パフォーマンスの問題を提起するトンネル転送の使用が必要です。PLSNとともに使用すると、トンネルにされたトラフィックの量が大幅に減少し、転送パフォーマンスの懸念が減少します。選択した修復メカニズムにトンネルの使用が必要な場合、トンネルベースのループ予防スキームが許容される場合があります。
This document analyzes the problem of micro-loops and summarizes a number of potential solutions that have been proposed. These solutions require only minor modifications to existing routing protocols and therefore do not add additional security risks. However, a full security analysis would need to be provided within the specification of a particular solution proposed for deployment.
この文書は、マイクロループの問題を分析し、提案されている多くの潜在的なソリューションを要約しています。これらのソリューションには、既存のルーティングプロトコルに対する軽微な変更のみが必要なため、セキュリティリスクを追加することはありません。ただし、展開用に提案された特定のソリューションの仕様内で、完全なセキュリティ分析を提供する必要があります。
The authors would like to acknowledge contributions to this document made by Clarence Filsfils.
著者は、Clarence Filsfilsが作成したこの文書への貢献を認めたいと考えています。
[ANALYSIS] Zinin, A., "Analysis and Minimization of Microloops in Link-state Routing Protocols", Work in Progress, October 2005.
[分析] Zinin、A。、「リンク状態ルーティングプロトコルにおけるマイクロループの分析と最小化」、2005年10月、進行中の作業。
[FRR-TUNN] Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Fast Reroute using tunnels", Work in Progress, November 2007.
[frr-tunn] Bryant、S.、Filsfils、C.、Previdi、S。、およびM. Shand、「Tunnelsを使用したIP Fast Reroute」、2007年11月、Work in Progress。
[LF-TIMERS] Atlas, A., Bryant, S., and M. Shand, "Synchronisation of Loop Free Timer Values", Work in Progress, February 2008.
[LF-Timers] Atlas、A.、Bryant、S。、およびM. Shand、「ループフリータイマー値の同期」、2008年2月の作業。
[NOT-VIA] Shand, M., Bryant, S., and S. Previdi, "IP Fast Reroute Using Not-via Addresses", Work in Progress, July 2009.
[not-via] Shand、M.、Bryant、S。、およびS. Previdi、「非Viaアドレスを使用したIP Fast Reroute」、2009年7月の作業。
[OPT] Francois, P., Shand, M., and O. Bonaventure, "Disruption free topology reconfiguration in OSPF networks", IEEE INFOCOM May 2007, Anchorage.
[Opt] Francois、P.、Shand、M。、およびO. Bonaventure、「OSPFネットワークにおける混乱のないトポロジの再構成」、IEEE Infocom 2007年5月、アンカレッジ。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装」、RFC 1305、1992年3月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Swallow、G。、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速拡張式」、RFC 4090、2005年5月。
[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月。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.
[RFC5714] Shand、M。およびS. Bryant、「IP Fast Reroute Framework」、RFC 5714、2010年1月。
[SIG] Francois, P. and O. Bonaventure, "Avoiding transient loops during IGP convergence", IEEE INFOCOM March 2005, Miami.
[SIG] Francois、P。およびO. Bonaventure、「IGP収束中の一時的なループの回避」、IEEE Infocom 2005年3月、マイアミ。
[oFIB] Francois, P., "Loop-free convergence using oFIB", Work in Progress, February 2008.
[ofib] Francois、P。、「Ofibを使用したループフリーの収束」、2008年2月に進行中の作業。
Authors' Addresses
著者のアドレス
Mike Shand Cisco Systems 250, Longwater Ave, Green Park, Reading, RG2 6GB United Kingdom
Mike Shand Cisco Systems 250、Longwater Ave、Green Park、Reading、RG2 6GBイギリス
EMail: mshand@cisco.com
Stewart Bryant Cisco Systems 250, Longwater Ave, Green Park, Reading, RG2 6GB United Kingdom
スチュワートブライアントシスコシステム250、ロングウォーターアベニュー、グリーンパーク、レディング、RG2 6GBイギリス
EMail: stbryant@cisco.com