[要約] RFC 6976は、ループフリー収束を実現するためのフレームワークであり、oFIBアプローチを使用しています。その目的は、ネットワークの収束時間を短縮し、パケットのループを回避することです。
Internet Engineering Task Force (IETF) M. Shand
Request for Comments: 6976 Individual Contributor
Category: Informational S. Bryant
ISSN: 2070-1721 S. Previdi
C. Filsfils
Cisco Systems
P. Francois
Institute IMDEA Networks
O. Bonaventure
Universite catholique de Louvain
July 2013
Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach
Ordered Forwarding Information Base（oFIB）アプローチを使用したループフリーの収束のフレームワーク
Abstract
概要
This document describes an illustrative framework of a mechanism for use in conjunction with link-state routing protocols that prevents the transient loops that would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers.
このドキュメントでは、トポロジ変更中に発生する可能性のある一時的なループを防止するリンクステートルーティングプロトコルと組み合わせて使用するメカニズムの例示的なフレームワークについて説明します。これは、ルーターの転送情報ベース（FIB）の更新を正しく順序付けることによって行われます。
This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast reroute mechanism that converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations.
このメカニズムは、緊急ではない（管理アクション）リンクまたはノードのシャットダウンと再起動、またはリンクメトリックの変更の場合に使用できます。また、突然のリンクまたはノードの障害を緊急でないトポロジ変更に変換する高速リルートメカニズムと組み合わせて使用することもできます。これは、影響を受けるすべての宛先に完全な修復パスが提供されている場合に可能です。
After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described.
緊急でないトポロジ変更の後、各ルータはFIBを安全に更新できる時間を定義するランクを計算します。完了メッセージを使用してこのループのない収束プロセスを加速する方法についても説明します。
The technology described in this document has been subject to extensive simulation using pathological convergence behavior and real network topologies and costs. However, the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol specification. This document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.
このドキュメントで説明されているテクノロジーは、病理学的収束動作と実際のネットワークトポロジおよびコストを使用した広範なシミュレーションの対象となっています。ただし、このドキュメントで説明されているメカニズムは、一般的なアプローチの単なる例示であり、プロトコル仕様を構成するものではありません。この文書は、発行時のルーティングエリアワーキンググループの作業のスナップショットを表しており、記録文書として発行されます。実装または展開の前に、さらに作業が必要です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6976.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6976で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. The Purpose of This Document . . . . . . . . . . . . . . 4
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Required FIB Update Order . . . . . . . . . . . . . . . . 6
2.1. Single Link Events . . . . . . . . . . . . . . . . . . . 6
2.1.1. Link Down / Metric Increase . . . . . . . . . . . . . 6
2.1.2. Link Up / Metric Decrease . . . . . . . . . . . . . . 7
2.2. Multi-Link Events . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Router Down Events . . . . . . . . . . . . . . . . . 8
2.2.2. Router Up Events . . . . . . . . . . . . . . . . . . 8
2.2.3. Line-Card Failure/Restoration Events . . . . . . . . 8
3. Applying Ordered FIB Updates . . . . . . . . . . . . . . . . 9
3.1. Deducing the Topology Change . . . . . . . . . . . . . . 9
3.2. Deciding If Ordered FIB Updates Apply . . . . . . . . . . 9
4. Computation of the Ordering . . . . . . . . . . . . . . . . . 10
4.1. Link Down, Router Down, or Metric Increase . . . . . . . 10
4.2. Link Up, Router Up, or Metric Decrease . . . . . . . . . 11
5. Acceleration of Ordered Convergence . . . . . . . . . . . . . 11
5.1. Construction of the Waiting List and Notification List . 12
5.1.1. Down Events . . . . . . . . . . . . . . . . . . . . . 12
5.1.2. Up Events . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Format of Completion Messages . . . . . . . . . . . . . . 13
6. Fallback to Conventional Convergence . . . . . . . . . . . . 13
7. oFIB State Machine . . . . . . . . . . . . . . . . . . . . . 13
7.1. OFIB_STABLE . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. OFIB_HOLDING_DOWN . . . . . . . . . . . . . . . . . . . . 15
7.3. OFIB_HOLDING_UP . . . . . . . . . . . . . . . . . . . . . 16
7.4. OFIB_ONGOING . . . . . . . . . . . . . . . . . . . . . . 17
7.5. OFIB_ABANDONED . . . . . . . . . . . . . . . . . . . . . 18
8. Management Considerations . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Candidate Methods of Safely Abandoning Loop-Free
Convergence (AAH) . . . . . . . . . . . . . . . . . 20
A.1. Possible Solutions . . . . . . . . . . . . . . . . . . . 20
A.2. Hold-Down Timer Only . . . . . . . . . . . . . . . . . . 20
A.3. AAH Messages . . . . . . . . . . . . . . . . . . . . . . 21
A.3.1. Per-Router State Machine . . . . . . . . . . . . . . 22
A.3.2. Per-Neighbor State Machine . . . . . . . . . . . . . 24
Appendix B. Synchronization of Loop-Free Timer Values . . . . . 25
B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 25
B.2. Required Properties . . . . . . . . . . . . . . . . . . . 25
B.3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 26
B.4. Security Considerations Related to Router Timer Values . 27
This document describes an illustrative framework of a mechanism for use in conjunction with link-state routing protocols that prevents the transient loops that would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers.
このドキュメントでは、トポロジ変更中に発生する可能性のある一時的なループを防止するリンクステートルーティングプロトコルと組み合わせて使用するメカニズムの例示的なフレームワークについて説明します。これは、ルーターの転送情報ベース（FIB）の更新を正しく順序付けることによって行われます。
At the time of publication there is no demand to deploy this technology; however, in view of the subtleties involved in the design of extensions for loop-free convergence routing protocols, the Routing Area Working Group considered it desirable to publish this document to place on record the design consideration of the ordered FIB (oFIB) approach.
公開時点では、このテクノロジーを配備する必要はありません。ただし、ループフリーのコンバージェンスルーティングプロトコルの拡張の設計に伴う微妙な点を考慮して、ルーティングエリアワーキンググループは、このドキュメントを公開して、順序付きFIB（oFIB）アプローチの設計上の考慮事項を記録することが望ましいと考えました。
The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. This document represents a snapshot of the work of the working group at the time of publication and is published as a document of record. Additional work is needed to specify the necessary routing protocol extensions necessary to support this IP fast reroute (FRR) method before implementation or deployment.
このドキュメントに示されているメカニズムは、一般的なアプローチの単なる例示であり、プロトコル仕様を構成するものではありません。このドキュメントは、公開時のワーキンググループの作業のスナップショットを表し、記録のドキュメントとして公開されます。実装または展開の前に、このIP高速再ルーティング（FRR）メソッドをサポートするために必要なルーティングプロトコル拡張を指定するには、追加の作業が必要です。
With link-state protocols, such as IS-IS [ISO10589] and OSPF [RFC2328], each time the network topology changes, some routers need to modify their forwarding information bases (FIBs) to take into account the new topology. Each topology change causes a convergence phase. During this phase, routers may transiently have inconsistent FIBs, which may lead to packet loops and losses, even if the reachability of the destinations is not compromised after the topology change. Packet losses and transient loops can also occur in the case of a link down event implied by a maintenance operation, even if this operation is predictable and not urgent. When the link-state change is a metric update and when a new link is brought up in the network, there is no direct loss of connectivity, but transient packet loops and loss can still occur.
IS-IS [ISO10589]やOSPF [RFC2328]などのリンクステートプロトコルを使用すると、ネットワークトポロジが変更されるたびに、一部のルーターは転送情報ベース（FIB）を変更して新しいトポロジを考慮に入れる必要があります。トポロジーが変更されるたびに、収束フェーズが発生します。このフェーズでは、トポロジの変更後に宛先への到達可能性が損なわれていなくても、ルーターに一時的に不整合なFIBが発生し、パケットループや損失につながる可能性があります。この操作が予測可能で緊急ではない場合でも、メンテナンス操作によって暗示されるリンクダウンイベントの場合、パケット損失と一時ループが発生する可能性もあります。リンク状態の変化がメトリックの更新であり、ネットワークで新しいリンクが確立された場合、接続の直接的な損失はありませんが、一時的なパケットループと損失が発生する可能性があります。
In this document, a distinction is made between urgent and non-urgent network events. Urgent events are those that arise from unpredictable network outages (such as node or link failures) that are traditionally resolved through the convergence of routing protocols or by protection mechanisms reliant on fault detection and reporting (such as through Operations, Administration, and Maintenance). Non-urgent events are those that arise from predictable events such as the controlled shutdown of network resources by a management system, or the modification of network parameters (such as routing metrics). Typically, non-urgent events can be planned around, while urgent events must be handled by dynamic systems. All network events, both urgent and non-urgent, may lead to transient packet loops and loss.
このドキュメントでは、緊急のネットワークイベントと緊急ではないネットワークイベントを区別しています。緊急イベントとは、予期しないネットワーク障害（ノードやリンクの障害など）から発生するもので、従来はルーティングプロトコルの収束、または障害の検出とレポートに依存する保護メカニズム（運用、管理、保守など）によって解決されます。非緊急イベントは、管理システムによるネットワークリソースの制御されたシャットダウン、またはネットワークパラメータ（ルーティングメトリックなど）の変更などの予測可能なイベントから発生するイベントです。通常、緊急でないイベントは動的なシステムで処理する必要がある一方で、緊急でないイベントを計画することができます。緊急および非緊急の両方のすべてのネットワークイベントは、一時的なパケットループと損失につながる可能性があります。
For example, in Figure 1, if the link between X and Y is shut down by an operator, packets destined to X can loop between R and Y when Y has updated its FIB while R has not yet updated its FIB, and packets destined to Y can loop between X and S if X updates its FIB before S. According to the current behavior of IS-IS and OSPF, this scenario will happen most of the time because X and Y are the first routers to be aware of the failure, so that they will update their FIBs first.
たとえば、図1では、XとYの間のリンクがオペレーターによってシャットダウンされた場合、RがまだFIBを更新しておらず、YがFIBを更新していて、X宛てのパケットがRとYの間でループする可能性があります。 XがSの前にFIBを更新する場合、YはXとSの間でループできます。IS-ISとOSPFの現在の動作によれば、このシナリオはほとんどの場合発生します。最初にFIBを更新します。
1
X-------------/-------------Y
| |
| |
| |
| |
1 | | 1
| |
| |
| |
| |
S---------------------------R
2
Figure 1: A Simple Topology
図1：単純なトポロジ
It should be noted that the loops can occur remotely from the failure, not just adjacent to it.
ループは、隣接するだけでなく、障害からリモートで発生する可能性があることに注意してください。
[RFC5715] provides an introduction to a number of loop-free convergence methods, and readers unfamiliar with this technology are recommended to read it before studying this document in detail. Note that in common with other loop-free convergence methods, oFIB is only capable of providing loop-free convergence in the presence of a single failure.
[RFC5715]は、ループのない収束方法を紹介しています。この技術に詳しくない読者は、このドキュメントを詳細に検討する前に、この方法を読むことをお勧めします。他のループフリーの収束方法と同様に、oFIBは単一の障害が存在する場合にのみループフリーの収束を提供できることに注意してください。
The goal of this document is to describe a mechanism that sequences the router FIB updates to maintain consistency throughout the network. By correctly setting the FIB change order, no looping or packet loss can occur. This mechanism may be applied to the case of managed link-state changes, i.e., link metric change, manual link down/up, manual router down/up, and managed state changes of a set of links attached to one router. It may also be applied to the case where one or more network elements are protected by a fast reroute mechanism (FRR) [RFC5714] [RFC4090]. The mechanisms that are used in the failure case are exactly the same as those used for managed changes. For simplicity, this document makes no further distinction between managed and unplanned changes.
このドキュメントの目的は、ネットワーク全体の一貫性を維持するために、ルータのFIB更新をシーケンス処理するメカニズムを説明することです。 FIB変更順序を正しく設定することにより、ループやパケット損失は発生しません。このメカニズムは、管理されたリンク状態の変更、つまり、リンクメトリックの変更、手動のリンクのダウン/アップ、手動のルーターのダウン/アップ、および1つのルーターに接続された一連のリンクの管理された状態の変更の場合に適用できます。また、1つ以上のネットワーク要素が高速再ルーティングメカニズム（FRR）[RFC5714] [RFC4090]によって保護されている場合にも適用できます。失敗した場合に使用されるメカニズムは、管理された変更に使用されるメカニズムとまったく同じです。簡単にするために、このドキュメントでは、管理された変更と計画外の変更を区別しません。
It is assumed in the description that follows that all routers in the routing domain are oFIB capable. This can be verified in an operational network by having the routers report oFIB capability using the IGP. Where non-oFIB-capable routers exist in the network, normal convergence would be used by all routers. The operation of mixed-mode networks is for further study.
以下の説明では、ルーティングドメイン内のすべてのルーターがoFIB対応であることを前提としています。これは、IGPを使用してルーターにoFIB機能を報告させることにより、運用ネットワークで確認できます。ネットワークに非oFIB対応のルーターが存在する場合、すべてのルーターで通常の収束が使用されます。混合モードのネットワークの運用については、今後の検討課題です。
The technology described in this document has been subject to extensive simulation using pathological convergence behavior and real network topologies and costs. A variant of the technology described here has been experimentally deployed in a production network.
このドキュメントで説明されているテクノロジーは、病理学的収束動作と実際のネットワークトポロジおよびコストを使用した広範なシミュレーションの対象となっています。ここで説明するテクノロジーの変種は、実験的に本番ネットワークに展開されています。
This section provides an overview of the required ordering of the FIB updates. A more detailed analysis of the rerouting dynamics and correctness proofs of the mechanism can be found in [refs.PFOB07].
このセクションでは、FIB更新の必要な順序の概要を説明します。メカニズムの再ルーティングのダイナミクスと正確性の証明のより詳細な分析は、[refs.PFOB07]にあります。
For simplicity, the correct ordering for single link changes are described first. The document then builds on this to demonstrate that the same principles can be applied to more complex scenarios such as line-card or node changes.
簡単にするために、単一リンク変更の正しい順序を最初に説明します。次に、この文書を基にして、ラインカードやノードの変更など、より複雑なシナリオにも同じ原則を適用できることを示します。
First, consider the non-urgent failure of a link (i.e., where an operator or a network management system (NMS) shuts down a link, thereby removing it from the currently active topology) or the increase of a link metric by the operator or NMS. In this case, a router R must not update its FIB until all other routers that send traffic via R and the affected link have first updated their FIBs.
最初に、リンクの緊急ではない障害（つまり、オペレーターまたはネットワーク管理システム（NMS）がリンクをシャットダウンし、それにより現在アクティブなトポロジからリンクを削除する場合）またはオペレーターによるリンクメトリックの増加を検討します。 NMS。この場合、Rを介してトラフィックを送信する他のすべてのルーターと影響を受けるリンクが最初にFIBを更新するまで、ルーターRはそのFIBを更新してはなりません。
The following argument shows that this rule ensures the correct order of FIB changes when the link X->Y is shut down or its metric is increased.
次の引数は、リンクX-> Yがシャットダウンしたとき、またはそのメトリックが増加したときに、このルールがFIB変更の正しい順序を保証することを示しています。
An "outdated" FIB entry for a destination is defined as being a FIB entry that still reflects the shortest path(s) in use before the topology change. Once a packet reaches a router R that has an outdated FIB entry for the packet destination, then, provided the oFIB ordering is respected, the packet will continue to X only traversing routers that also have an outdated FIB entry for the destination. The packet thus reaches X without looping and will be forwarded to Y via X->Y (or in the case of FRR, the X->Y repair path) and will reach its destination.
宛先の「古い」FIBエントリは、トポロジ変更前に使用中の最短パスを反映するFIBエントリとして定義されます。パケットがパケットの宛先の古いFIBエントリを持つルーターRに到達すると、oFIBの順序が順守されている場合、パケットは、宛先の古いFIBエントリーを持つルーターのみを通過するXのみに継続します。したがって、パケットはループせずにXに到達し、X-> Y（またはFRRの場合はX-> Y修復パス）を介してYに転送され、その宛先に到達します。
Since it can be assumed that the original topology was loop-free, Y will never use the link Y->X to reach the destination, and hence the path(s) between Y and the destination are guaranteed to be unaffected by the topology change. It therefore follows that the packet arriving at Y will reach its destination without looping.
元のトポロジにはループがないと想定できるため、YはリンクY-> Xを使用して宛先に到達しないため、Yと宛先の間のパスがトポロジの変更による影響を受けないことが保証されます。 。したがって、Yに到着したパケットはループせずに宛先に到達します。
Since it can also be assumed that the new topology is loop-free, by definition a packet cannot loop while being forwarded exclusively by routers with an updated FIB entry.
新しいトポロジにはループがないと想定することもできるため、定義上、更新されたFIBエントリを持つルーターによって排他的に転送されているパケットはループできません。
In other words, when the oFIB ordering is respected, if a packet reaches an outdated router, it can never subsequently reach an updated router, and it cannot loop because from this point on it will only be forwarded on the consistent path that was used before the event. If it does not reach an outdated router, it will only be forwarded on the loop-free path that will be used after the convergence.
つまり、oFIBの順序付けが順守されている場合、パケットが古いルーターに到達すると、その後更新されたルーターに到達することはできず、この時点からは以前に使用された一貫したパスにのみ転送されるため、ループすることはできません。行事。古いルータに到達しない場合は、コンバージェンス後に使用されるループフリーパスでのみ転送されます。
According to the proposed ordering, X will be the last router to update its FIB. Once it has updated its FIB, the link X->Y can actually be shut down (or the repair removed).
提案された順序によると、XはFIBを更新する最後のルーターになります。 FIBを更新すると、リンクX-> Yを実際にシャットダウンできます（または修復を削除します）。
If the link X-Y is bidirectional, a similar process must be run to order the FIB update for destinations using the link in the direction Y->X. As has already been shown, no packet ever traverses the X-Y link in both directions, and hence the operation of the two ordering processes is orthogonal.
リンクX-Yが双方向の場合、同様のプロセスを実行して、Y-> X方向のリンクを使用する宛先のFIB更新を注文する必要があります。すでに示したように、X-Yリンクを両方向に通過するパケットはないため、2つの順序付けプロセスの動作は直交しています。
In the case of link up events or metric decreases, a router R must update its FIB before all other routers that will use R to reach the affected link.
リンクアップイベントまたはメトリックの減少の場合、Rを使用して影響を受けるリンクに到達する他のすべてのルーターよりも前に、ルーターRがFIBを更新する必要があります。
The following argument shows that this rule ensures the correct order of FIB changes when the link X->Y is brought into service or its metric is decreased.
次の引数は、リンクX-> Yがサービス状態になったとき、またはそのメトリックが減少したときに、このルールがFIB変更の正しい順序を保証することを示しています。
Firstly, when a packet reaches a router R that has already updated its FIB, all the routers on the path from R to X will also have updated their FIB, so that the packet will reach X and be forwarded along X->Y, ultimately reaching its destination.
まず、パケットがすでにFIBを更新しているルーターRに到達すると、RからXへのパス上のすべてのルーターもFIBを更新しているため、パケットはXに到達し、X-> Yに沿って転送されます。その目的地に到達。
Secondly, a packet cannot loop between routers that have not yet updated their FIB. This proves that no packet can loop.
次に、FIBをまだ更新していないルーター間でパケットがループすることはありません。これは、パケットがループできないことを証明します。
The following sections describe the required ordering for single events that may manifest as multiple link events. For example, the failure of a router may be notified to the rest of the network as the individual failure of all its attached links. The means of identifying the event type from the collection of received link events is described in Section 3.1.
次のセクションでは、複数のリンクイベントとして現れる可能性がある単一のイベントに必要な順序について説明します。たとえば、ルーターの障害は、接続されているすべてのリンクの個々の障害として、ネットワークの残りの部分に通知されます。受信したリンクイベントのコレクションからイベントタイプを識別する方法については、セクション3.1で説明します。
In the case of the non-urgent shutdown of a router, a router R must not update its FIB until all other routers that send traffic via R and the affected router have first updated their FIBs.
ルーターの緊急でないシャットダウンの場合、ルーターRは、Rを介してトラフィックを送信する他のすべてのルーターと影響を受けるルーターが最初にFIBを更新するまで、FIBを更新してはなりません。
Using a proof similar to that for link failure, it can be shown that no loops will occur if this ordering is respected [refs.PFOB07].
リンク障害の場合と同様の証明を使用して、この順序が尊重されている場合はループが発生しないことを示すことができます[refs.PFOB07]。
In the case of a router being brought into service, a router R must update its FIB BEFORE all other routers that WILL use R to reach the affected router.
稼働中のルーターの場合、影響を受けるルーターに到達するためにRを使用する他のすべてのルーターの前に、ルーターRがそのFIBを更新する必要があります。
A proof similar to that for link up shows that no loops will occur if this ordering is respected [refs.PFOB07].
リンクアップの場合と同様の証明は、この順序が尊重されている場合はループが発生しないことを示しています[refs.PFOB07]。
The failure of a line card involves the failure of a set of links, all of which have a single node in common, i.e., the parent router. The ordering to be applied is the same as if it were the failure of the parent router.
ラインカードの障害には、一連のリンクの障害が含まれます。これらのリンクにはすべて、共通の単一ノード、つまり親ルーターがあります。適用される順序は、親ルーターの障害の場合と同じです。
In a similar way, the restoration of an entire line card to service as a single event can be treated as if the parent router were returning to service.
同様に、ラインカード全体を単一のイベントとしてサービスに復元すると、親ルータがサービスに戻ったかのように扱うことができます。
As has been described, a single event such as the failure or restoration of a single link, single router, or line card may be notified to the rest of the network as a set of individual link change events. It is necessary to deduce from this collection of link-state notifications the type of event that has occurred in the network and hence the required ordering.
説明したように、単一のリンク、単一のルータ、またはラインカードの障害または復元などの単一のイベントは、一連の個別のリンク変更イベントとして残りのネットワークに通知されます。このリンク状態通知のコレクションから、ネットワークで発生したイベントのタイプ、したがって必要な順序を推測する必要があります。
When a link change event is received that impacts the receiving router's FIB, the routers at the near and far end of the link are noted.
受信ルーターのFIBに影響を与えるリンク変更イベントを受信すると、リンクの近端および遠端にあるルーターが記録されます。
If all events received within some hold-down period (the time that a router waits to acquire a set of Link State Packets (LSPs) that should be processed together) have a single router in common, then it is assumed that the change reflects an event (line-card or router change) concerning that router.
あるホールドダウン期間（一緒に処理する必要がある一連のリンクステートパケット（LSP）を取得するためにルーターが待機する時間）内に受信されたすべてのイベントに共通の単一のルーターがある場合、変更はそのルータに関するイベント（ラインカードまたはルータの変更）。
In the case of a link change event, the router at the far end of the link is deemed to be the common router.
リンク変更イベントの場合、リンクの遠端にあるルーターが共通ルーターであると見なされます。
All ordering computations are based on treating the common router as the root for both link and node events.
すべての順序付け計算は、共通ルーターをリンクイベントとノードイベントの両方のルートとして扱うことに基づいています。
There are some events (for example, a subsequent failure with conflicting repair requirements occurring before the ordered FIB process has completed) that cannot be correctly processed by this mechanism. In these cases, it is necessary to ensure that convergence falls back to the conventional mode of operation (see Section 6).
このメカニズムでは正しく処理できないいくつかのイベント（たとえば、順序付けされたFIBプロセスが完了する前に発生する、競合する修復要件による後続の障害）があります。これらの場合、コンバージェンスが従来の動作モードにフォールバックするようにする必要があります（セクション6を参照）。
In all cases, it is necessary to wait some hold-down period after receiving the first notification to ensure that all routers have received the complete set of link-state notifications associated with the single event.
いずれの場合も、最初の通知を受信した後、すべてのルーターが単一のイベントに関連付けられたリンク状態通知の完全なセットを確実に受信するように、ホールドダウン期間を待つ必要があります。
At any time, if a link change notification is received that would have no effect on the receiving router's FIB, then it may be ignored.
いつでも、受信ルーターのFIBに影響を与えないリンク変更通知が受信された場合、それは無視されます。
If no other event is received during the hold-down time, the event is treated as a link event. Note that the IGP reverse connectivity check means that only the first failure event or second up event has an effect on the FIB.
ホールドダウン時間中に他のイベントが受信されない場合、イベントはリンクイベントとして扱われます。 IGP逆接続チェックは、最初の障害イベントまたは2番目のアップイベントのみがFIBに影響することを意味することに注意してください。
If an event that is received within the hold-down period does NOT reference the common router (R), then, in this version of the specification, normal convergence is invoked immediately (see Section 6).
ホールドダウン期間内に受信されたイベントが共通ルーター（R）を参照しない場合、このバージョンの仕様では、通常の収束がただちに呼び出されます（セクション6を参照）。
Network reconvergence using the ordered FIB approach takes longer than the normal reconvergence process. Where the failure is protected by an FRR mechanism, this additional delay in convergence causes no packet loss. When the sudden failure of a link or a set of links that are not protected using an FRR mechanism occurs, the failure must be processed using the conventional (faster) mode of operation to minimize packet loss during reconvergence.
順序付きFIBアプローチを使用したネットワークの再コンバージェンスは、通常の再コンバージェンスプロセスよりも時間がかかります。障害がFRRメカニズムによって保護されている場合、この収束の追加遅延により、パケット損失は発生しません。 FRRメカニズムを使用して保護されていないリンクまたはリンクセットの突然の障害が発生した場合、再コンバージェンス中のパケット損失を最小限に抑えるために、従来の（高速）動作モードを使用して障害を処理する必要があります。
In summary, an ordered FIB process is applicable if the set of link state notifications received between the first event and the hold-down period reference a common router R, and one of the following assertions is verified:
要約すると、最初のイベントとホールドダウン期間の間で受信されたリンク状態通知のセットが共通のルーターRを参照し、次のアサーションのいずれかが検証されている場合、順序付きFIBプロセスが適用されます。
o The set of notifications refers to link down events concerning protected links and metric increase events.
o 通知のセットは、保護されたリンクとメトリック増加イベントに関するリンクダウンイベントを指します。
o The set of notifications refers to link up events and metric decrease events.
o 通知のセットは、リンクアップイベントとメトリック減少イベントを指します。
This section describes how the required ordering is computed.
このセクションでは、必要な順序の計算方法について説明します。
This computation required the introduction of the concept of a reverse Shortest Path Tree (rSPT). The rSPT uses the cost towards the root (rather than from it) and yields the best paths towards the root from other nodes in the network [IPFRR-TUNNELS].
この計算には、逆の最短パスツリー（rSPT）の概念の導入が必要でした。 rSPTは、ルートからのコストではなくルートへのコストを使用し、ネットワーク内の他のノードからルートへの最適なパスを生成します[IPFRR-TUNNELS]。
To respect the proposed ordering, routers compute a rank that will be used to determine the time at which they are permitted to perform their FIB update. In the case of a failure event rooted at router Y or an increase of the metric of link X->Y, router R computes the rSPT in the topology before the failure (rSPT_old) rooted at Y. This rSPT gives the shortest paths to reach Y before the failure. The branch of the rSPT that is below R corresponds to the set of shortest paths to R that are used by the routers that reach Y via R.
提案された順序を尊重するために、ルーターはFIB更新の実行が許可される時間を決定するために使用されるランクを計算します。ルーターYをルートとする障害イベント、またはリンクX-> Yのメトリックの増加の場合、ルーターRはトポロジーのrSPTを計算してから、Yをルートとする障害（rSPT_old）を計算します。このrSPTは到達する最短パスを提供します障害の前のY。 Rの下にあるrSPTのブランチは、Rを介してYに到達するルータによって使用されるRへの最短パスのセットに対応します。
The rank of router R is defined as the depth (in number of hops) of this branch. In the case of Equal Cost Multipath (ECMP), the maximum depth of the ECMP path set is used.
ルータRのランクは、このブランチの深度（ホップ数）として定義されます。等コストマルチパス（ECMP）の場合、ECMPパスセットの最大深度が使用されます。
Router R is required to update its FIB at time
ルーターRは、そのFIBを同時に更新する必要があります
T0 + H + (rank * MAX_FIB)
where T0 is the arrival time of the Link State Packet containing the topology change, H is the hold-down time, and MAX_FIB is a network-wide constant that reflects the maximum time required to update a FIB irrespective of the change required. The value of MAX_FIB is network specific, and its determination is out of the scope of this document. This value must be agreed to by all the routers in the network. This agreement can be performed by using a capability TLV as defined in Appendix B.
ここで、T0はトポロジ変更を含むリンクステートパケットの到着時間、Hはホールドダウン時間、MAX_FIBはネットワーク全体の定数であり、必要な変更に関係なくFIBを更新するために必要な最大時間を反映します。 MAX_FIBの値はネットワーク固有であり、その決定はこのドキュメントの範囲外です。この値は、ネットワーク内のすべてのルーターが同意する必要があります。この合意は、付録Bで定義されている機能TLVを使用して実行できます。
All the routers that use R to reach Y will compute a lower rank than R, and hence the correct order will be respected. It should be noted that only the routers that used Y before the event need to compute their rank.
Rを使用してYに到達するすべてのルーターは、Rよりも低いランクを計算するため、正しい順序が尊重されます。イベントの前にYを使用したルーターのみがランクを計算する必要があることに注意してください。
In the case of a link or router up event rooted at Y or a link metric decrease affecting link Y->W, a router R must have a rank that is higher than the rank of the routers that it will use to reach Y, according to the rule described in Section 2. Thus, the rank of R is the number of hops between R and Y in its renewed Shortest Path Tree. When R has multiple equal-cost paths to Y, the rank is the length in hops of the longest ECMP path to Y.
YをルートとするリンクまたはルーターアップイベントまたはリンクY-> Wに影響するリンクメトリック減少の場合、ルーターRは、Yに到達するために使用するルーターのランクよりも高いランクを持つ必要があります。したがって、Rのランクは、更新された最短パスツリー内のRとYの間のホップ数です。 RにYへの複数の等コストパスがある場合、ランクはYへの最長ECMPパスのホップ単位の長さです。
Router R is required to update its FIB at time
ルーターRは、FIBを同時に更新する必要があります
T0 + H + (rank * MAX_FIB)
It should be noted that only the routers that use Y after the event have to compute a rank, i.e., only the routers that have Y in their SPT after the link-state change.
イベント後にYを使用するルーターのみがランクを計算する必要があることに注意してください。つまり、リンク状態の変更後にSPTにYが含まれるルーターのみです。
The mechanism described above is conservative and hence may be relatively slow. The purpose of this section is to describe a method of accelerating the controlled convergence in such a way that ordered loop-free convergence is still guaranteed.
上記のメカニズムは保守的であるため、比較的遅くなる可能性があります。このセクションの目的は、順序付けられたループのない収束が依然として保証されるように、制御された収束を加速する方法を説明することです。
In many cases, a router will complete its required FIB changes in a time much shorter than MAX_FIB, and in many other cases, a router will not have to perform any FIB change at all.
多くの場合、ルーターは必要なFIB変更をMAX_FIBよりもはるかに短い時間で完了し、他の多くの場合、ルーターはFIB変更をまったく実行する必要がありません。
This section describes the use of completion messages to speed up the convergence by providing a means for a router to inform those routers waiting for it that it has completed any required FIB changes. When a router has been advised of completion by all the routers for which it is waiting, it can safely update its own FIB without further delay. In most cases, this can result in a sub-second reconvergence time, which is comparable with a normal convergence time.
このセクションでは、完了メッセージを使用して、必要なFIB変更が完了したことを待機しているルーターに通知する手段をルーターに提供することにより、収束を高速化する方法について説明します。ルーターは、待機しているすべてのルーターから完了を通知された場合、それ以上の遅延なしに自身のFIBを安全に更新できます。ほとんどの場合、これにより1秒未満の再収束時間が発生する可能性があり、これは通常の収束時間に匹敵します。
Routers maintain a waiting list of the neighbors from which a completion message must be received. Upon reception of a completion message from a neighbor, a router removes this neighbor from its waiting list. Once its waiting list becomes empty, the router is allowed to update its FIB immediately even if its ranking timer has not yet expired. Once this is done, the router sends a completion message to the neighbors that are waiting for it to complete. Those routers are listed in a list called the Notification List. Completion messages contain an identification of the event to which they refer.
ルーターは、完了メッセージを受信する必要がある近隣の待機リストを維持します。ネイバーから完了メッセージを受信すると、ルーターはこのネイバーを待機リストから削除します。待機リストが空になると、ランキングタイマーがまだ満了していない場合でも、ルータはすぐにFIBを更新できます。これが完了すると、ルーターは完了を待機しているネイバーに完了メッセージを送信します。これらのルーターは、通知リストと呼ばれるリストにリストされています。完了メッセージには、それらが参照するイベントのIDが含まれています。
Note that, since this is only an optimization, any loss of completion messages will result in the routers waiting their defined ranking time, and hence the loop-free properties will be preserved.
これは最適化にすぎないため、完了メッセージが失われると、ルーターは定義されたランキング時間だけ待機することになり、ループのないプロパティが保持されることに注意してください。
Consider a link or node down event rooted at router Y or the cost increase of the link X->Y. A router R will compute rSPT_old(Y) to determine its rank. When doing this, R also computes the set of neighbors that R uses to reach the failing node or link, and the set of neighbors that are using R to reach the failing node or link. The notification list of R is equal to the former set, and the waiting list of R is equal to the latter.
ルータYをルートとするリンクまたはノードのダウンイベント、またはリンクX-> Yのコスト増加を検討してください。ルータRは、rSPT_old（Y）を計算してランクを決定します。これを行うとき、Rは、Rが障害のあるノードまたはリンクに到達するために使用するネイバーのセット、およびRを使用して障害のあるノードまたはリンクに到達するネイバーのセットも計算します。 Rの通知リストは前者のセットに等しく、Rの待機リストは後者に等しい。
Note that R could include all its neighbors in the notification list except those in the waiting list; this would have no impact on the correctness of the protocol but would be unnecessarily inefficient.
Rは、待機リストにあるものを除いて、通知リストにそのすべてのネイバーを含めることができることに注意してください。これはプロトコルの正確さに影響を与えませんが、不必要に非効率的です。
Consider a link or node up event rooted at router Y or the cost decrease of the link Y->X. A router R will compute its new SPT (SPT_new(R)). The waiting list is the set of next-hop routers that R uses to reach Y in SPT_new(R).
ルータYをルートとするリンクまたはノードアップイベント、またはリンクY-> Xのコスト削減を検討してください。ルーターRは新しいSPT（SPT_new（R））を計算します。待機リストは、RがSPT_new（R）でYに到達するために使用するネクストホップルーターのセットです。
In a simple implementation, the notification list of R is all the neighbors of R excluding those in the waiting list. This may be further optimized by computing rSPT_new(Y) to determine those routers that are waiting for R to complete.
単純な実装では、Rの通知リストは、待機リストにあるものを除いて、Rのすべてのネイバーです。これは、rSPT_new（Y）を計算して、Rの完了を待機しているルーターを特定することでさらに最適化できます。
The format of completion messages and means of their delivery is routing protocol dependent and is outside the scope of this document.
完了メッセージの形式とその配信方法はルーティングプロトコルによって異なり、このドキュメントの範囲外です。
The following information is required:
以下の情報が必要です。
o Identity of the sender.
o 送信者のID。
o List of routing notifications being considered in the associated FIB change. Each notification is defined as:
o 関連するFIB変更で検討されているルーティング通知のリスト。各通知は次のように定義されます。
Node ID of the near end of the link
リンクの近端のノードID
Node ID of the far end of the link
リンクの遠端のノードID
Inclusion or removal of link
リンクの包含または削除
Old metric
古いメトリック
New metric
新しい指標
In circumstances where a router detects that it is dealing with incomplete or inconsistent link-state information, or when a further topology event is received before completion of the current ordered FIB update process, it may be expedient to abandon the controlled convergence process. A number of possible fallback mechanisms are described in Appendix A. This mechanism is referred to as "Abandoning All Hope" (AAH). The state machine defined in the body of this document does not make any assumption about which fallback mechanism will be used.
ルーターが不完全または一貫性のないリンク状態情報を処理していることをルーターが検出した場合、または現在の順序付けされたFIB更新プロセスが完了する前にさらにトポロジーイベントが受信された場合、制御された収束プロセスを中止するのが得策です。付録Aには、いくつかの可能なフォールバックメカニズムが説明されています。このメカニズムは、「Abandoning All Hope」（AAH）と呼ばれています。このドキュメントの本文で定義されているステートマシンは、どのフォールバックメカニズムが使用されるかについては想定していません。
An implementation must be capable of interworking with the model of an oFIB state machine described in this section.
実装は、このセクションで説明するoFIBステートマシンのモデルと相互作用できる必要があります。
An oFIB-capable router maintains an oFIB state value, which is one of: OFIB_STABLE, OFIB_HOLDING_DOWN, OFIB_HOLDING_UP, OFIB_ABANDONED, or OFIB_ONGOING.
oFIB対応ルーターは、OFIB_STABLE、OFIB_HOLDING_DOWN、OFIB_HOLDING_UP、OFIB_ABANDONED、またはOFIB_ONGOINGのいずれかであるoFIB状態値を維持します。
An oFIB-capable router maintains a timer, Hold_down_timer. An oFIB-capable router is configured with a value referred to as HOLD_DOWN_DURATION. This configuration can be performed manually or using Appendix B.
oFIB対応ルーターは、タイマーHold_down_timerを維持します。 oFIB対応ルーターは、HOLD_DOWN_DURATIONと呼ばれる値で構成されます。この構成は手動で、または付録Bを使用して実行できます。
An oFIB-capable router maintains a timer, rank_timer.
oFIB対応ルーターは、タイマーrank_timerを維持します。
OFIB_STABLE is the state of a router that is not currently involved in any convergence process. This router is ready to process an event by applying oFIB.
OFIB_STABLEは、現在収束プロセスに関与していないルーターの状態です。このルーターは、oFIBを適用してイベントを処理する準備ができています。
EVENT: Reception of a Link State Packet that describes an event of the type link X--Y down or metric increase and is to be processed using oFIB.
EVENT：タイプリンクX--Yダウンまたはメトリック増加のイベントを記述し、oFIBを使用して処理されるリンク状態パケットの受信。
ACTION:
アクション：
Set state to OFIB_HOLDING_DOWN.
状態をOFIB_HOLDING_DOWNに設定します。
Start Hold_down_timer.
Hold_down_timerを開始します。
ofib_current_common_set = {X,Y}.
Compute rank with respect to the event, as defined in Section 4.
セクション4で定義されているように、イベントに関するランクを計算します。
Store the waiting list and notification list for X--Y obtained from the rank computation.
ランク計算から取得したX--Yの待機リストと通知リストを保存します。
EVENT: Reception of a Link State Packet that describes an event of the type link X--Y up or metric decrease and is to be processed using oFIB.
EVENT：タイプリンクX--Yアップまたはメトリック減少のイベントを記述し、oFIBを使用して処理されるリンク状態パケットの受信。
ACTION:
アクション：
Set state to OFIB_HOLDING_UP.
状態をOFIB_HOLDING_UPに設定します。
Start Hold_down_timer.
Hold_down_timerを開始します。
ofib_current_common_set = {X,Y}.
Compute rank with respect to the event, as defined in Section 4.
セクション4で定義されているように、イベントに関するランクを計算します。
Store the waiting list and notification list for X--Y obtained from the rank computation.
ランク計算から取得したX--Yの待機リストと通知リストを保存します。
OFIB_HOLDING_DOWN is the state of a router that is collecting a set of link down or metric increase Link State Packets to be processed together using controlled convergence.
OFIB_HOLDING_DOWNは、制御された収束を使用して一緒に処理されるリンクダウンまたはメトリック増加リンク状態パケットのセットを収集しているルーターの状態です。
EVENT: Reception of a Link State Packet that describes an event of the type link up or metric decrease and can be processed using oFIB.
EVENT：タイプリンクアップまたはメトリック減少のイベントを記述し、oFIBを使用して処理できるリンク状態パケットの受信。
ACTION:
アクション：
Set state to OFIB_ABANDONED.
状態をOFIB_ABANDONEDに設定します。
Reset Hold_down_timer.
Hold_down_timerをリセットします。
Trigger AAH mechanism.
AAHメカニズムをトリガーします。
EVENT: Reception of a Link State Packet that describes an event of the type link A--B down or metric increase and can be processed using oFIB.
EVENT：タイプリンクA--Bダウンまたはメトリック増加のイベントを記述し、oFIBを使用して処理できるリンク状態パケットの受信。
ACTION:
アクション：
ofib_current_common_set = intersection(ofib_current_common_set,{A,B}).
ofib_current_common_set = intersection（ofib_current_common_set、{A、B}）。
If ofib_current_common_set is empty, then there is no longer a node in common in all the pending link-state changes.
ofib_current_common_setが空の場合、保留中のすべてのリンク状態変更に共通のノードはありません。
Set state to OFIB_ABANDONED.
状態をOFIB_ABANDONEDに設定します。
Reset Hold_down_timer.
Hold_down_timerをリセットします。
Trigger AAH mechanism.
AAHメカニズムをトリガーします。
If ofib_current_common set is not empty, update the waiting list and notification list as defined in Section 4. Note that in the case of a single link event, the Link State Packet received when the router is in this state describes the state change of the other direction of the link; hence, no changes will be made to the waiting and notification lists.
ofib_current_commonセットが空でない場合は、セクション4で定義されているように待機リストと通知リストを更新します。単一のリンクイベントの場合、ルーターがこの状態のときに受信したリンク状態パケットは、他の状態変化を示します。リンクの方向。したがって、待機リストと通知リストは変更されません。
EVENT: Hold_down_timer expires.
イベント：Hold_down_timerが期限切れになります。
ACTION:
アクション：
Set state to OFIB_ONGOING.
状態をOFIB_ONGOINGに設定します。
Start rank_timer with computed rank.
計算されたランクでrank_timerを開始します。
EVENT: Reception of a completion message.
EVENT：完了メッセージの受信。
ACTION: Remove the sender from the waiting list associated with the event identified in the completion message.
アクション：完了メッセージで識別されたイベントに関連付けられている待機リストから送信者を削除します。
OFIB_HOLDING_UP is the state of a router that is collecting a set of link up or metric decrease Link State Packets to be processed together using controlled convergence.
OFIB_HOLDING_UPは、制御された収束を使用して一緒に処理される一連のリンクアップまたはメトリック減少リンク状態パケットを収集しているルーターの状態です。
EVENT: Reception of a Link State Packet that describes an event of the type link down or metric increase and is to be processed using oFIB.
EVENT：タイプリンクダウンまたはメトリック増加のイベントを記述し、oFIBを使用して処理されるリンク状態パケットの受信。
ACTION:
アクション：
Set state to OFIB_ABANDONED.
状態をOFIB_ABANDONEDに設定します。
Reset Hold_down_timer.
Hold_down_timerをリセットします。
Trigger AAH mechanism.
AAHメカニズムをトリガーします。
EVENT: Reception of a Link State Packet that describes an event of the type link A--B up or metric decrease and is to be processed using oFIB.
EVENT：タイプリンクA--Bアップまたはメトリック減少のイベントを記述し、oFIBを使用して処理されるリンク状態パケットの受信。
ACTION:
アクション：
ofib_current_common_set = intersection(ofib_current_common_set,{A,B}).
ofib_current_common_set = intersection（ofib_current_common_set、{A、B}）。
If ofib_current_common_set is empty, then there is no longer a common node in the set of pending link-state changes.
ofib_current_common_setが空の場合、保留中のリンク状態変更のセットに共通ノードはありません。
Set state to OFIB_ABANDONED.
状態をOFIB_ABANDONEDに設定します。
Reset Hold_down_timer.
Hold_down_timerをリセットします。
Trigger AAH mechanism.
AAHメカニズムをトリガーします。
If ofib_current_common set is not empty, update the waiting list and notification list as defined in Section 4. Note that in the case of a single link event, the Link State Packet received when the router is in this state describes the state change of the other direction of the link; hence, no changes will be made to the waiting and notification lists.
ofib_current_commonセットが空でない場合は、セクション4で定義されているように待機リストと通知リストを更新します。単一のリンクイベントの場合、ルーターがこの状態のときに受信したリンク状態パケットは、他の状態変化を示します。リンクの方向。したがって、待機リストと通知リストは変更されません。
EVENT: Reception of a completion message.
イベント：完了メッセージの受信。
ACTION: Remove the sender from the waiting list associated with the event identified in the completion message.
アクション：完了メッセージで識別されたイベントに関連付けられている待機リストから送信者を削除します。
EVENT: Hold_down_timer expires.
イベント：Hold_down_timerが期限切れになります。
ACTION:
アクション：
Set state to OFIB_ONGOING.
状態をOFIB_ONGOINGに設定します。
Start rank_timer with computed rank.
計算されたランクでrank_timerを開始します。
OFIB_ONGOING is the state of a router that is applying the ordering mechanism with respect to the set of Link State Packets collected when in OFIB_HOLDING_DOWN or OFIB_HOLDING_UP state.
OFIB_ONGOINGは、OFIB_HOLDING_DOWNまたはOFIB_HOLDING_UP状態のときに収集された一連のリンク状態パケットに関して順序付けメカニズムを適用しているルーターの状態です。
EVENT: rank_timer expires or waiting list becomes empty.
イベント：rank_timerが期限切れになるか、待機リストが空になります。
ACTION:
アクション：
Perform FIB updates according to the change.
変更に応じてFIB更新を実行します。
Send completion message to each member of the notification list.
通知リストの各メンバーに完了メッセージを送信します。
Set state to OFIB_STABLE.
状態をOFIB_STABLEに設定します。
EVENT: Reception of a completion message.
EVENT：完了メッセージの受信。
ACTION: Remove the sender from the waiting list.
アクション：待機リストから送信者を削除します。
EVENT: Reception of a Link State Packet describing a link-state change event.
EVENT：リンク状態変更イベントを説明するリンク状態パケットの受信。
ACTION:
アクション：
Set state to OFIB_ABANDONED.
状態をOFIB_ABANDONEDに設定します。
Trigger AAH.
AAHをトリガーします。
Start Hold_down_timer.
Hold_down_timerを開始します。
OFIB_ABANDONED is the state of a router that has fallen back to fast convergence due to the reception of Link State Packets that cannot be dealt with together using oFIB.
OFIB_ABANDONEDは、oFIBを使用して一緒に処理できないリンクステートパケットの受信が原因で高速コンバージェンスにフォールバックしたルーターの状態です。
EVENT: Reception of a Link State Packet describing a link-state change event.
EVENT：リンク状態変更イベントを説明するリンク状態パケットの受信。
ACTION: Trigger AAH, reset AAH_Hold_down_timer.
アクション：AAHをトリガーし、AAH_Hold_down_timerをリセットします。
EVENT: AAH_Hold_down_timer expires.
イベント：AAH_Hold_down_timerが期限切れになります。
ACTION: Set state to OFIB_STABLE.
アクション：状態をOFIB_STABLEに設定します。
A system for recording the dynamics of the convergence process needs to be deployed in order to make a post hoc diagnosis of the reconvergence. The sensitivity of applications to any packet reordering introduced by the delayed convergence process will need to be studied. However, these needs apply to any loop-free convergence method and are not specific to the ordered FIB method described in this document.
再収束の事後診断を行うには、収束プロセスのダイナミクスを記録するシステムを展開する必要があります。遅延収束プロセスによって導入されたパケットの並べ替えに対するアプリケーションの感度を調査する必要があります。ただし、これらのニーズはループのない収束方法に適用され、このドキュメントで説明されている順序付きFIB方法に固有のものではありません。
This document requires only minor modifications to existing routing protocols and therefore does not add significant additional security risks. However, a full security analysis would need to be provided within the protocol-specific specifications proposed for deployment.
このドキュメントでは、既存のルーティングプロトコルにわずかな変更を加えるだけでよいため、重大なセキュリティリスクは追加されません。ただし、展開のために提案されたプロトコル固有の仕様内で、完全なセキュリティ分析を提供する必要があります。
Security considerations related to timer values set by routers are noted in Appendix B.4.
ルーターによって設定されるタイマー値に関連するセキュリティの考慮事項は、付録B.4に記載されています。
We would like to thank Jean-Philippe Vasseur and Les Ginsberg for their useful suggestions and comments.
Jean-Philippe VasseurとLes Ginsbergの有益な提案とコメントに感謝します。
[IPFRR-TUNNELS] Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Fast Reroute using tunnels", Work in Progress, November 2007.
[IPFRR-TUNNELS]ブライアント、S。、フィルスフィルス、C。、プレビディ、S。、およびM.シャンド、「トンネルを使用したIP高速リルート」、作業中、2007年11月。
[ISO10589] International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[ISO10589]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システムから中間システムのドメイン内ルーティング情報交換プロトコル」、ISO / IEC 10589：2002、第2版、2002年11月。
[LF-TIMERS] Atlas, A., Bryant, S., and M. Shand, "Synchronisation of Loop Free Timer Values", Work in Progress, February 2008.
[LF-TIMERS]アトラス、A。、ブライアント、S。、およびM.シャンド、「ループフリータイマー値の同期」、作業中、2008年2月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P。、スワロー、G。、およびA.アトラス、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、2005年5月。
[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月。
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, January 2010.
[RFC5715] Shand、M。およびS. Bryant、「A Loopwork for Loop-Free Convergence」、RFC 5715、2010年1月。
[refs.PFOB07] Francois, P. and O. Bonaventure, "Avoiding transient loops during the convergence of link-state routing protocols", IEEE/ACM Transactions on Networking, Vol. 15, No. 6, pp. 1280-1292, December 2007, <http://dx.doi.org/10.1109/TNET.2007.902686>.
[refs.PFOB07] Francois、P。およびO. Bonaventure、「リンク状態ルーティングプロトコルの収束中の一時的なループの回避」、IEEE / ACM Transactions on Networking、Vol。 15、No. 6、pp。1280-1292、December 2007、<http://dx.doi.org/10.1109/TNET.2007.902686>。
Appendix A. Candidate Methods of Safely Abandoning Loop-Free Convergence (AAH)
付録A.ループフリー収束（AAH）を安全に放棄する候補の方法
IP Fast Reroute [RFC5714] and loop-free convergence techniques [RFC5715] can deal with single topology change events, multiple correlated change events, and in some cases even certain uncorrelated events. However, in all cases, there are events that cannot be dealt with, and the mechanism needs to quickly revert to normal convergence. This is known as "Abandoning All Hope" (AAH).
IP高速リルート[RFC5714]とループフリーコンバージェンステクニック[RFC5715]は、単一のトポロジ変更イベント、複数の相関変更イベント、場合によっては特定の無相関イベントさえも処理できます。ただし、すべての場合で、処理できないイベントがあり、メカニズムはすぐに通常の収束に戻る必要があります。これは「すべての希望を放棄する」（AAH）として知られています。
This appendix describes the outcome of a design study into the AAH problem and is included here to trigger discussion on the trade-offs between complexity and robustness in the AAH solution space.
この付録は、AAH問題に対する設計研究の結果を説明し、AAHソリューション空間における複雑さと堅牢性の間のトレードオフについての議論をトリガーするためにここに含まれています。
Two approaches to this problem have been proposed:
この問題に対する2つのアプローチが提案されています。
1. Hold-down timer only.
1. ホールドダウンタイマーのみ。
2. Synchronization of AAH state using AAH messages.
2. AAHメッセージを使用したAAH状態の同期。
They are described below.
以下に説明します。
The "hold-down timer only" AAH method uses a hold-down to acquire a set of LSPs that should be processed together. On expiry of the local hold-down timer, the router begins processing the batch of LSPs according to the loop-free prevention algorithm.
「ホールドダウンタイマーのみ」のAAHメソッドは、ホールドダウンを使用して、一緒に処理する必要がある一連のLSPを取得します。ローカルホールドダウンタイマーが満了すると、ルータはループフリー防止アルゴリズムに従ってLSPのバッチの処理を開始します。
There are a number of problems with this simple approach. In some cases, the timer value will be too short to ensure that all the related events have arrived at all routers (perhaps because there was some unexpected propagation delay, or one or more of the events are slow in being detected). In other cases, a completely unrelated event may occur after the timer has expired but before the processing is complete. In addition, since the timer is started at each router on reception of the first LSP announcing a topology change, the actual starting time is dependent upon the propagation time of the first LSP. So, for a subsequent event occurring around the time of the timer expiry, because of variations in propagation delay, it may reach some routers before the timer expires and others after it has expired. In the former case, this LSP will be included in the set of changes to be considered; while in the latter, it will be excluded leading to serious routing inconsistency. In such cases, continuing to operate the loop-free convergence protocol may exacerbate the situation.
この単純なアプローチには多くの問題があります。場合によっては、タイマー値が短すぎて、関連するすべてのイベントがすべてのルーターに確実に届かないことがあります（おそらく、予期しない伝搬遅延があったか、1つ以上のイベントの検出が遅いためです）。他の場合では、タイマーが切れた後、処理が完了する前に、完全に無関係なイベントが発生する場合があります。さらに、最初のLSPがトポロジー変更をアナウンスすると、各ルーターでタイマーが開始されるため、実際の開始時間は最初のLSPの伝播時間に依存します。したがって、タイマーの有効期限の前後に発生する後続のイベントでは、伝播遅延の変動により、タイマーが期限切れになる前に一部のルーターに到達し、期限切れ後に他のルーターに到達する可能性があります。前者の場合、このLSPは考慮される一連の変更に含まれます。後者では除外され、深刻なルーティングの不整合が発生します。このような場合、ループのない収束プロトコルを操作し続けると、状況が悪化する可能性があります。
The simple approach to this would be to revert to normal convergence (AAH) whenever an LSP is received after the timer has expired. However, this also has problems for the reasons above and therefore AAH must be a synchronous operation, i.e., it is necessary to arrange that an AAH invoked anywhere in the network causes ALL routers to invoke AAH.
これに対する簡単なアプローチは、タイマーが切れた後にLSPが受信されると、通常のコンバージェンス（AAH）に戻ることです。ただし、これには上記の理由による問題もあり、したがってAAHは同期操作である必要があります。つまり、ネットワーク内のどこかで呼び出されたAAHによってすべてのルーターがAAHを呼び出すようにする必要があります。
It is also necessary to consider the means of exiting the AAH state. Again, the simplest method is to use a timer. However, while in AAH state, any topology changes that are previously received or subsequently received should be processed immediately using the traditional convergence algorithms, i.e., without invoking controlled convergence. If the exit from the AAH state is not correctly synchronized, a new event may be processed by some routers immediately (as AAH), while those that have already left AAH state will treat it as the first of a new batch of changes and attempt controlled convergence. Thus, both entry and exit from the AAH state need to be synchronized. A method of achieving this is described in Appendix A.3.
また、AAH状態を終了する方法を検討する必要があります。この場合も、最も簡単な方法はタイマーを使用することです。ただし、AAH状態では、以前に受信した、または後で受信したトポロジの変更は、従来の収束アルゴリズムを使用して、つまり制御された収束を呼び出さずにすぐに処理する必要があります。 AAH状態からの出口が正しく同期されていない場合、新しいイベントは一部のルーターによってすぐに（AAHとして）処理される可能性がありますが、すでにAAH状態を離れたルーターは、変更の新しいバッチの最初のものとして扱い、制御を試みます収束。したがって、AAH状態の開始と終了の両方を同期する必要があります。これを達成する方法は、付録A.3で説明されています。
Like the simple timer AAH method, the "AAH messages" method uses a hold-down to acquire a set of LSPs that should be processed together. On expiry of the local hold-down timer, the router begins processing the batch of LSPs according to the loop-free prevention algorithm. This is the same behavior as the hold-down timer only method. However, if any router, having started the loop-free convergence process receives an LSP that would trigger a topology change, it locally abandons the controlled convergence process and sends an AAH message to all its neighbors. This eventually triggers all routers to abandon the controlled convergence. The routers remain in AAH state (i.e., processing topology changes using normal "fast" convergence), until a period of quiescence has elapsed. The exit from AAH state is synchronized by using a two-step process. To achieve the required synchronization, two additional messages are required, AAH and AAH ACK. The AAH message is reliably exchanged between neighbors using the AAH ACK message. These could be implemented as a new message within the routing protocol or carried in existing routing hello messages. Two types of state machines are needed -- a per-router AAH state machine and a per-neighbor AAH state machine (PNSM). These are described below.
単純なタイマーAAHメソッドと同様に、「AAHメッセージ」メソッドはホールドダウンを使用して、一緒に処理する必要があるLSPのセットを取得します。ローカルホールドダウンタイマーが満了すると、ルータはループフリー防止アルゴリズムに従ってLSPのバッチの処理を開始します。これは、ホールドダウンタイマーのみの方法と同じ動作です。ただし、ループフリーのコンバージェンスプロセスを開始したルーターがトポロジの変更をトリガーするLSPを受信すると、制御されたコンバージェンスプロセスをローカルで破棄し、AAHメッセージをそのすべてのネイバーに送信します。これにより、最終的にすべてのルーターがトリガーされ、制御された収束が放棄されます。ルーターは、休止期間が経過するまで、AAH状態（つまり、通常の「高速」コンバージェンスを使用したトポロジ変更の処理）のままです。 AAH状態からの終了は、2ステップのプロセスを使用して同期されます。必要な同期を実現するには、AAHとAAH ACKの2つの追加メッセージが必要です。 AAHメッセージは、AAH ACKメッセージを使用してネイバー間で確実に交換されます。これらは、ルーティングプロトコル内の新しいメッセージとして実装するか、既存のルーティングハローメッセージに含めることができます。ルーターごとのAAHステートマシンとネイバーごとのAAHステートマシン（PNSM）の2種類のステートマシンが必要です。これらについて以下に説明します。
+-------------+----------+---------+--------+------------+----------+
| EVENT | Q | Hold | CC | AAH | AAH-hold |
+=============+==========+=========+========+============+==========+
| RX LSP | Start | - | TX-AAH | Restart | TX-AAH |
| triggering |hold-down | | Start | AAH timer. | Start |
| change | timer. | | AAH | [AAH] | AAH |
| | [Hold] | | timer. | | timer. |
| | | | [AAH] | | [AAH] |
+-------------+----------+---------+--------+------------+----------+
| RX AAH | TX-AAH | TX-AAH | TX-AAH | [AAH] | TX-AAH |
|(Neighbor's |Start AAH | Start | Start | | Start |
| PNSM | timer. | AAH | AAH | | AAH |
| processes | [AAH] | timer. | timer. | | timer. |
| RX AAH.) | | [AAH] | [AAH] | | [AAH] |
+-------------+----------+---------+--------+------------+----------+
| Timer | - | Trigger | - | Start | [Q] |
| expiry | | CC. | | AAH-hold | |
| | | [CC] | | timer. | |
| | | | | [AAH-hold] | |
+-------------+----------+---------+--------+------------+----------+
| Controlled | - | - | [Q] | - | - |
| convergence | | | | | |
| completed | | | | | |
+-------------+----------+---------+--------+------------+----------+
RX = Reception TX = Transmission TX-AAH = Send "go to TX-AAH" to all other PNSMs.
RX =受信TX =送信TX-AAH =他のすべてのPNSMに「go to TX-AAH」を送信します。
Per-Router State Table
ルーターごとの状態テーブル
Operation of the per-router state machine is as follows:
ルーターごとのステートマシンの動作は次のとおりです。
Operation of this state machine under normal topology change involves only states: Quiescent (Q), Hold-down (Hold) and Controlled Convergence (CC). The remaining states are associated with an AAH event.
通常のトポロジ変更の下でのこのステートマシンの動作には、静止（Q）、ホールドダウン（ホールド）、および制御された収束（CC）の状態のみが含まれます。残りの状態は、AAHイベントに関連付けられています。
The resting state is Quiescent. When the router in the Quiescent state receives an LSP indicating a topology change, which would normally trigger an SPF, it starts the hold-down timer and changes state to Hold-down. It normally remains in this state, collecting additional LSPs until the hold-down timer expires. Note that all routers must use a common value for the hold-down timer. When the hold-down timer expires, the router then enters Controlled Convergence (CC) state and executes the CC mechanism to reconverge the topology. When the CC process has completed on the router, the router re-enters the Quiescent state.
休止状態は静止です。静止状態のルーターがトポロジ変更を示すLSPを受信すると、通常はSPFをトリガーし、ホールドダウンタイマーを開始して状態をホールドダウンに変更します。通常はこの状態のままで、ホールドダウンタイマーが期限切れになるまで追加のLSPを収集します。すべてのルータがホールドダウンタイマーに共通の値を使用する必要があることに注意してください。ホールドダウンタイマーが期限切れになると、ルータはControlled Convergence（CC）状態に入り、CCメカニズムを実行してトポロジを再収束します。ルータでCCプロセスが完了すると、ルータは再び静止状態になります。
If this router receives a topology-changing LSP whilst it is in the CC state, it enters AAH state and sends a "go to TX-AAH" command to all per-neighbor state machines; this causes each per-neighbor state machine to signal this state change to its neighbor. Alternatively, if this router receives an AAH message from any of its neighbors whilst in any state except AAH, it starts the AAH timer and enters the AAH state. The per-neighbor state machine corresponding to the neighbor from which the AAH was received executes the RX AAH action (which causes it to send an AAH ACK), while the remainder of neighbors are sent the "go to TX-AAH" command. The result is that the AAH is acknowledged to the neighbor from which it was received and propagated to all other neighbors. On entering AAH state, all CC timers are expired, and normal convergence takes place.
このルータは、CC状態のときにトポロジ変更LSPを受信すると、AAH状態に入り、「go to TX-AAH」コマンドをすべてのネイバーごとのステートマシンに送信します。これにより、ネイバーごとの各ステートマシンは、このステートの変更をネイバーに通知します。あるいは、このルーターがAAH以外の状態にあるときに、近隣のいずれかからAAHメッセージを受信した場合、AAHタイマーを開始してAAH状態に入ります。 AAHの受信元であるネイバーに対応するネイバーごとのステートマシンは、RX AAHアクションを実行し（AAH ACKを送信させる）、残りのネイバーには「go to TX-AAH」コマンドが送信されます。その結果、AAHは、それが受信されたネイバーに確認応答され、他のすべてのネイバーに伝搬されます。 AAH状態に入ると、すべてのCCタイマーが期限切れになり、通常の収束が行われます。
Whilst in the AAH state, LSPs are processed in the traditional manner. Each time an LSP is received, the AAH timer is restarted. In an unstable network, ALL routers will remain in this state for some time, and the network will behave in the traditional uncontrolled convergence manner.
AAH状態では、LSPは従来の方法で処理されます。 LSPを受信するたびに、AAHタイマーが再起動されます。不安定なネットワークでは、すべてのルーターがしばらくこの状態のままになり、ネットワークは従来の制御されない収束方法で動作します。
When the AAH timer expires, the router enters AAH-hold state and starts the AAH-hold timer. The purpose of the AAH-hold state is to synchronize the transition of the network from AAH to Quiescent. The additional state ensures that the network cannot contain a mixture of routers in both AAH and Quiescent states. If, whilst in AAH-hold state the router receives a topology changing LSP, it re-enters AAH state and commands all per-neighbor state machines to "go to TX-AAH". If, whilst in AAH-hold state, the router receives an AAH message from one of its neighbors, it re-enters the AAH state and commands all other per-neighbor state machines to "go to TX-AAH". Note that the per-neighbor state machine receiving the AAH message will autonomously acknowledge receipt of the AAH message. Commanding the per-neighbor state machine to "go to TX-AAH" is necessary, because routers may be in a mixture of Quiescent, Hold-down, and AAH-hold states, and it is necessary to rendezvous the entire network back to AAH state.
AAHタイマーが期限切れになると、ルータはAAHホールドステートに入り、AAHホールドタイマーを開始します。 AAHホールド状態の目的は、ネットワークのAAHから静止への移行を同期させることです。追加の状態により、ネットワークにAAHと静止状態の両方のルーターを混在させることができなくなります。 AAHホールド状態のときに、ルーターがトポロジ変更LSPを受信すると、ルーターはAAH状態に戻り、すべてのネイバーステートマシンに「TX-AAHに移動」するように命令します。 AAHホールド状態のときに、ルーターがネイバーの1つからAAHメッセージを受信すると、ルーターはAAH状態に入り、他のすべてのネイバーステートマシンに「TX-AAHに移動」するように命令します。 AAHメッセージを受信するネイバーごとのステートマシンは、AAHメッセージの受信を自律的に確認することに注意してください。ルーターが静止状態、ホールドダウン状態、AAHホールド状態が混在している可能性があり、ネットワーク全体をAAHにランデブーする必要があるため、ネイバーごとの状態マシンに「TX-AAHに移動」するように命令する必要があります。状態。
When the AAH-hold timer expires, the router changes to Quiescent and is ready for loop-free convergence.
AAHホールドタイマーが期限切れになると、ルータは静止状態に変わり、ループのないコンバージェンスの準備が整います。
+----------------------------+--------------+-----------------------+
| EVENT | IDLE | TX-AAH |
+============================+==============+=======================+
| RX AAH | Send ACK. | Send ACK. |
| | [IDLE] | Cancel timer. |
| | | [IDLE] |
+----------------------------+--------------+-----------------------+
| RX ACK | ignore | Cancel timer. |
| | | [IDLE] |
+----------------------------+--------------+-----------------------+
| RX "go to TX-AAH" from | Send AAH | ignore |
| Router State Machine | [TX-AAH] | |
+----------------------------+--------------+-----------------------+
| Timer expires | impossible | Send AAH |
| | | Restart timer. |
| | | [TX-AAH] |
+----------------------------+--------------+-----------------------+
Per-Neighbor State Table
ネイバーごとの状態テーブル
There is one instance of the per-neighbor state machine (PNSM) for each neighbor within the convergence control domain.
コンバージェンス制御ドメイン内のネイバーごとに、ネイバーごとのステートマシン（PNSM）のインスタンスが1つあります。
The normal state is IDLE.
通常の状態はIDLEです。
On command ("go to TX-AAH") from the router state machine, the state machine enters TX-AAH state, transmits an AAH message to its neighbor, and starts a timer.
ルーターステートマシンからのコマンド（ "go to TX-AAH"）で、ステートマシンはTX-AAH状態に入り、AAHメッセージをそのネイバーに送信し、タイマーを開始します。
On receipt of an AAH ACK in state TX-AAH, the state machine cancels the timer and enters IDLE state.
状態TX-AAHでAAH ACKを受信すると、状態マシンはタイマーをキャンセルし、IDLE状態に入ります。
In state IDLE, any AAH ACK message received is ignored.
IDLE状態では、受信したAAH ACKメッセージは無視されます。
On expiry of the timer in state TX-AAH, the state machine transmits an AAH message to the neighbor and restarts the timer. (The timer cannot expire in any other state.)
TX-AAH状態のタイマーが満了すると、ステートマシンはAAHメッセージをネイバーに送信し、タイマーを再起動します。 （タイマーは他の状態では期限切れになりません。）
In any state, receipt of an AAH causes the state machine to transmit an AAH ACK and enter the IDLE state.
どの状態でも、AAHを受信すると、ステートマシンはAAH ACKを送信してIDLE状態に入ります。
Note that for correct operation the state machine must remain in state TX-AAH until an AAH ACK or an AAH is received or until the state machine is deleted. Deletion of the per-neighbor state machine occurs when routing determines that the neighbor has gone away or when the interface goes away.
正常に動作させるには、AAH ACKまたはAAHを受信するまで、またはステートマシンが削除されるまで、ステートマシンをTX-AAH状態のままにする必要があることに注意してください。ネイバーごとのステートマシンの削除は、ネイバーがなくなったとルーティングが判断した場合、またはインターフェイスが離れた場合に発生します。
When routing detects a new neighbor, it creates a new instance of the per-neighbor state machine in state IDLE. The consequent generation of the router's own LSP will then cause the router state machine to execute the LSP receipt actions that, if necessary, will result in the new per-neighbor state machine receiving a "go to TX-AAH" command and transitioning to TX-AAH state.
ルーティングが新しいネイバーを検出すると、ネイバーごとのステートマシンの新しいインスタンスをステートIDLEで作成します。その後、ルーター自身のLSPが生成されると、ルーターステートマシンがLSP受信アクションを実行し、必要に応じて、新しいネイバーごとのステートマシンが「go to TX-AAH」コマンドを受信してTXに移行します。 -AAH状態。
This appendix provides the reader with access to the design considerations originally described in [LF-TIMERS].
この付録は、読者に[LF-TIMERS]で最初に説明された設計上の考慮事項へのアクセスを提供します。
Most of the loop-free convergence mechanisms [RFC5715] require one or more convergence delay timers that must have a duration that is consistent throughout the routing domain. This time is the worst-case time that any router will take to calculate the new topology and to make the necessary changes to the FIB. The timer is used by the routers to know when it is safe to transition between the loop-free convergence states. The time taken by a router to complete each phase of the loop-free transition will be dependent on the size of the network and the design and implementation of the router. Therefore, it can be expected that the optimum delay will need to be tuned from time to time as the network evolves. Manual configuration of the timer is fraught for two reasons. Firstly, it is always difficult to ensure that the correct value is installed in all of the routers. Secondly, if any change is introduced into the network that results in a need to change the timer (for example, due to a change in hardware or software version), then all of the routers need to be reconfigured to use the new timer value. Therefore, it is desirable that a means be provided by which the convergence delay timer can be automatically synchronized throughout the network.
ほとんどのループのないコンバージェンスメカニズム[RFC5715]には、ルーティングドメイン全体で一貫した期間が必要な1つ以上のコンバージェンス遅延タイマーが必要です。この時間は、ルータが新しいトポロジを計算し、FIBに必要な変更を加えるのにかかる最悪の場合の時間です。タイマーは、ルーターがループフリーの収束状態間で安全に遷移できる時期を知るために使用されます。ルーターがループのない移行の各フェーズを完了するのにかかる時間は、ネットワークのサイズとルーターの設計と実装によって異なります。したがって、ネットワークの進化に伴い、最適な遅延を随時調整する必要があることが予想されます。タイマーの手動設定には2つの理由があります。まず、すべてのルーターに正しい値がインストールされていることを確認することは常に困難です。次に、ネットワークを変更してタイマーを変更する必要が生じた場合（ハードウェアまたはソフトウェアのバージョンの変更などにより）、新しいタイマー値を使用するようにすべてのルーターを再構成する必要があります。したがって、収束遅延タイマーをネットワーク全体で自動的に同期させることができる手段を提供することが望ましい。
The timer synchronization mechanism must have the following properties:
タイマー同期メカニズムには、次のプロパティが必要です。
o The convergence delay time must be consistent amongst all routers that are converging on the new topology.
o コンバージェンス遅延時間は、新しいトポロジーにコンバージェンスしているすべてのルーター間で一貫している必要があります。
o The convergence delay time must be the highest delay required by any router in the new topology.
o コンバージェンス遅延時間は、新しいトポロジのすべてのルーターで必要とされる最大の遅延でなければなりません。
o The mechanism must increase the delay when a new router that requires a higher delay than is currently in use is introduced to the network.
o 現在使用されているよりも高い遅延を必要とする新しいルーターがネットワークに導入された場合、メカニズムは遅延を増加させる必要があります。
o When the router that had the longest delay requirements is removed from the topology, the convergence delay timer value must, within some reasonable time, be reduced to the longest delay required by the remaining routers.
o 遅延要件が最も長いルーターをトポロジから削除する場合、収束遅延タイマーの値を、妥当な時間内に、残りのルーターが必要とする最長の遅延に減らす必要があります。
o It must be possible for a router to change the convergence delay timer value that it requires.
o ルーターが必要とするコンバージェンス遅延タイマー値を変更できるようにする必要があります。
o A router that is in multiple routing areas or is running multiple routing protocols may signal a different loop-free convergence delay for each area and for each protocol.
o 複数のルーティングエリアにある、または複数のルーティングプロトコルを実行しているルーターは、エリアごとおよびプロトコルごとに異なるループフリーのコンバージェンス遅延を通知する場合があります。
How a router determines the time that it needs to execute each convergence phase is an implementation issue and outside the scope of this specification. However, a router that dynamically determines its proposed timer value must do so in such a way that it does not cause the synchronized value to continually fluctuate.
ルーターが各収束フェーズの実行に必要な時間を決定する方法は実装の問題であり、この仕様の範囲外です。ただし、提案されたタイマー値を動的に決定するルーターは、同期された値が継続的に変動しないように行う必要があります。
The following mechanism is proposed.
以下のメカニズムが提案されている。
A new information element is introduced into the routing protocol that specifies the maximum time (in milliseconds) that the router will take to calculate the new topology and to update its FIB as a result of any topology change.
ルーティングプロトコルに新しい情報要素が導入され、ルーターが新しいトポロジを計算し、トポロジ変更の結果としてFIBを更新するのにかかる最大時間（ミリ秒単位）が指定されます。
When a topology change occurs, the longest convergence delay time required by any router in the new topology is used by the loop-free convergence mechanism.
トポロジーの変更が発生すると、新しいトポロジーのルーターが必要とする最長のコンバージェンス遅延時間が、ループのないコンバージェンスメカニズムによって使用されます。
If a routing protocol message is issued that changes the convergence delay timer value but does not change the topology, the new timer value must be taken into consideration during the next loop-free transition but must not instigate a loop-free transition.
コンバージェンス遅延タイマー値を変更するがトポロジーを変更しないルーティングプロトコルメッセージが発行された場合、次のループフリー移行中に新しいタイマー値を考慮する必要がありますが、ループフリー移行を引き起こしてはなりません。
If a routing protocol message is issued that changes the convergence timer value and changes the topology, a loop-free transition is instigated, and the new timer value is taken into consideration.
コンバージェンスタイマーの値を変更してトポロジを変更するルーティングプロトコルメッセージが発行されると、ループのない移行が開始され、新しいタイマーの値が考慮されます。
The loop-free convergence mechanism should specify the action to be taken if a timer change (only) message and a topology change message are independently generated during the hold-off time. A suitable action would be to take the same action that would be taken if two uncorrelated topology changes occurred in the network.
ループのない収束メカニズムでは、ホールドオフ時間中にタイマー変更（のみ）メッセージとトポロジ変更メッセージが個別に生成された場合に実行するアクションを指定する必要があります。適切なアクションは、ネットワーク内で2つの無相関トポロジー変更が発生した場合と同じアクションを実行することです。
All routers that support loop-free convergence must advertise a loop-free convergence delay time. The loop-free convergence mechanism must specify the action to be taken if a router does not advertise a convergence delay time.
ループフリーコンバージェンスをサポートするすべてのルーターは、ループフリーコンバージェンス遅延時間を通知する必要があります。ループのない収束メカニズムは、ルーターが収束遅延時間を通知しない場合に実行するアクションを指定する必要があります。
If an abnormally large timer value is proposed by a router, then there is a danger that the loop-free convergence process will take an excessive amount of time. If during that time the routing protocol signals the need for another transition, the loop-free transition will be abandoned and the default best-case (traditional) convergence mechanism used.
異常に大きなタイマー値がルーターによって提案された場合、ループのない収束プロセスに過度の時間がかかる危険があります。その間にルーティングプロトコルが別の遷移の必要性を通知した場合、ループのない遷移は放棄され、デフォルトのベストケース（従来の）収束メカニズムが使用されます。
It is still undesirable that the routers select a convergence delay time that has an excessive value. The maximum value that can be specified in the LSP or Link State Advertisement (LSA) is limited (through the use of a 16-bit field) to about 65 seconds. When sufficient implementation experience is gained, an architectural constant will be specified as the upper limit of the convergence delay timer.
ルータが過度の値を持つ収束遅延時間を選択することは依然として望ましくありません。 LSPまたはリンクステートアドバタイズメント（LSA）で指定できる最大値は、（16ビットフィールドを使用して）約65秒に制限されています。十分な実装経験が得られると、アーキテクチャー定数が収束遅延タイマーの上限として指定されます。
Authors' Addresses
著者のアドレス
Mike Shand Individual Contributor
Mike Shand個人貢献者
EMail: imc.shand@googlemail.com
Stewart Bryant Cisco Systems 10 New Square, Bedfont Lakes Feltham, Middlesex TW18 8HA United Kingdom
Stewart Bryant Cisco Systems 10 New Square、Bedfont Lakes Feltham、Middlesex TW18 8HAイギリス
EMail: stbryant@cisco.com
Stefano Previdi Cisco Systems Via Del Serafico 200 00142 Roma Italy
Stefano Previdi Cisco Systems Via Del Serafico 200 00142 Rome Rome Italy
EMail: sprevidi@cisco.com Clarence Filsfils Cisco Systems Brussels Belgium
Eメール：sprevidi@cisco.com Clarence Filsfils Cisco Systems Brussels Belgium
EMail: cfilsfil@cisco.com
Pierre Francois Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganese 28918 Spain
Pierre Francois Institute IMDEA Networks Avda。Del Mar Mediterraneo、22 Leganese 28918 Spain
EMail: pierre.francois@imdea.org
Olivier Bonaventure Universite catholique de Louvain Place Ste Barbe, 2 Louvain-la-Neuve 1348 Belgium
Olivier Bonaventureカトリックルーバン大学Place Ste Barbe、2 Louvain-la-Neuve 1348ベルギー
EMail: Olivier.Bonaventure@uclouvain.be
URI: http://inl.info.ucl.ac.be/