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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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のトラフィックエンジニアリング（TE）高速再ルーティングメカニズム[RFC4090]の発展につながっています。 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.
マイクロループの影響を緩和する一つの方法は、ネットワークがこれらの効果が重要でないあることを十分に短い時間で再コンバージェンスことを保証することです。別の方法は、最小あるいはマイクロループの可能性を排除するために、ネットワークトポロジーを設計することです。
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によって引き起こされる場合、マイクロループは、期間中形成していてもよいです。移行中、マイクロループが一時的プレフィックスの次ホップとして互いを使用するルータのペア間の単一のリンクを介して起こり得ます。三つ以上のルータのサイクルの各ルータは、与えられたプレフィックスの次ホップとしてのサイクルで次のルータを有する場合、マイクロループも形成することができます。
Cyclic loops may occur if one or more of the following conditions are met:
次のいずれかまたは複数の条件が満たされた場合に巡回ループが発生する可能性があります。
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.
渋滞や修理飢餓：マイクロループは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.
それのFIBの再同期の結果として、エスケープのいずれかまたは生きてその時間（TTL）が経過するまでOループパケットは、帯域幅を消費します。これは一過性に限り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.
マイクロループは、通常、障害の文脈で考えられているが、トポロジ変更は、管理アクションの結果である場合に、うっ血パケットロスと飢餓の同様の問題が起こり得ます。例えば、リンクは、管理アクションによってサービスから取り出すことがある場合を考えます。リンクは、このように任意の修理の必要性を回避する、移行期間にサービス内に保持することができます。マイクロループが形成している場合しかし、彼らは渋滞損失を引き起こす可能性があり、また、リンクに到達するトラフィックを防ぐことができます。
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:
ループフリーコンバージェンス技術は、マイクロループは、例えば、以下のネットワークの収束を形成し得る任意の状況に適用可能です。
6. External cost change, for example, change of external gateway as a result of a BGP change
6.外部コストの変化、例えば、BGPの変化の結果として外部ゲートウェイの変更
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.
ループフリーコンバージェンス技術は、IPネットワークとシングルホップトンネル高速再ルーティング機構を使用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つの基本的なクラスに分類されます。
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.
マイクロループ緩和方式は、マイクロループの形成が減少するようにネットワークを再収束することによって動作するが、排除しません。このようなスキームは、移行中のパケットの生産転送を保証することはできません。
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 [ANALYSIS]に記載のセーフ・ネイバーズ（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:
両方の以下の基準のその宛先満たすまでY通る経路場合ルータ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).
変更の影響を受けない目的地（タイプA1）ともネクストホップの変更は、安全基準（タイプA2）を満たした後、目的地：Oの宛先を入力します。
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の宛先はすぐに、これは最短パスでなくても、安全基準を満たしているネクストホップを経由するように変更されています。すべてのルータが新しい次のホップにかけて自分のタイプCの目的地を変更したまで、タイプBの宛先は、このパスを経由して行くことを続けています。すべてのルータが（安全な）新規または中間の次のホップにそのタイプ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の更新を遅らせることはありません。このようなすべてのルータが宛先のみを入力した場合、それが設計されたとして、このループの緩和メカニズムが働くだろう。全てのこのような不可能なルータのみC地を入力した場合あるいは、トンネルベースのスキームをトリガーするために使用される「ループ防止」発表機構（6.4のセクション6.2を参照）は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.
シミュレーションが最もトポロジでループ防止にのみ小さな劣化タイプCの結果としてタイプ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:
八マイクロループ防止方法が提案されています。
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つのステップで「無限大」に、その割り当てられたメトリックから変更されています。しかしながら、リンクコストは、適切な増分で増加され、次のコスト増分がアドバタイズされる前に、ネットワークが安定化するために許可されている場合何マイクロループを形成しないこと[OPT]証明することができます。リンクコストは、リンクの周りに最低代替コストよりも大きな値に増加されると、リンクは、マイクロループを生じさせることなく無効にすることができます。
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
安全のためにリンクコスト変更の基準は、xのコスト変化に供される任意のリンクだけサイクリック費用x以下を有するネットワークの一部にループを引き起こす可能性があることです。各方向の一方のコストを持っているリンクが存在する可能性があるため、両者の環状コストで、その結果、これは1の増分で上昇させリンクコストをもたらすことができます。しかし、増分はどこ最小コストの許す大きくすることができます。最近の研究[OPT]は持っています
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.
必要なコスト値の正確なセットを決定するために、問題に適用され、したがって増分の数を最小限にすることができる最適化の数が存在することを示します。
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.
リンクがサービスに戻されると、そのコストは、これにより、「良いニュース」イベント中に同様のマイクロループ防止を提供し、最終的なコストへの「無限大」から小さなステップで減少していることは理解されるであろう。リンクコストは、マイクロループを引き起こすことなく、一の段階でのリンクの周りに最低代替コストよりも大きい任意の値に「無限」から減少されてもよいことに留意されたいです。
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のすべての失敗のメンバー間で調整する必要があります。これは、次を開始する前や変更をインターリーブすることによって一つのリンクの遷移を完了することによって達成することができます。
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.
マイクロループ防止機構は、障害回復をサポートするために使用されている場合、増分の数が必要であり、従って完全に収束するのに要する時間は、偶数インクリメントの少数のために重要です。遷移の期間中、ネットワークのいくつかの部分は、古い転送パスを使用し、従って長期間いかなる修復機構を使用し続けるからです。完全に修復できない障害が発生した場合に、いくつかの目的地は、したがって、長期間到達不能になってもよいです。加えて、ネットワークは、制御され、再収束の期間第二の故障に対して脆弱であり得ます。
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は、自律システム（AS）を用い経路長が頻繁に一又は各インターASホップのために非常に小さい整数）の効果的なメトリックを使用して、必要な増分の数も最適化することなく、許容可能に小さくすることができます。
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.
障害が検出された（またはリンクがサービスから取り出される）場合、障害に隣接ルータがトポロジの変更を発表し、新しい「ループ防止」ルーティング・メッセージを発行します。このメッセージは、すべてのルータによりネットワークを介して伝播されるだけトンネルベース、マイクロループ防止メカニズムのいずれかを使用することが可能なルータによって理解されます。
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部材ごとにで - これは、複数のトンネルの宛先を必要とするであろう。
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トンネリングループの防止は、障害の奥側に（、ノードに障害が発生した場合に、ルータまたは）ルータで終端する一本の以上のトンネルの障害を横切ることになるトラフィックの全てを配置するループ防止ルータを必要とします。この方法の特性は、手前側トンネル方法と、ノードに障害が発生した場合に、任意の単一のルータのデカプセル負荷の軽減を用いて達成されるより修理トラフィックのより均一な分布です。
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.
（補修ルータに通常のルーティングを使用して）手前側トンネル方法とは異なり、この方法はfarsideルータに修復経路の使用を必要とします。これは、さらなる計算が必要とされない場合にないビア[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].
分散トンネルループ防止方法において、各ルータは、それ自身の修復を算出し、その修復を用いて、障害によって影響を受けるトラフィックを転送。高速再ルーティング（FRR）の場合とは異なり、実際の故障は、計算時に知られています。ループ防止ルータの目的は、[FRR-TUNN]はP-スペースにあるルータを使用してQ-空間に故障を経由して行っていたパケットを取得することです。パケットはQ-スペースへのエントリ上でカプセル化が解除されているためではなく、故障のfarsideに行くことを余儀なくされ、より最適なルーティングを達成することができます。この方法は、[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.
代替分散トンネル機構は、障害に関連付けられていないビアアドレス[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への変更は、それぞれの変更を検討し、それが失敗（すなわちを横断せずに目的地に到達したOLDトポロジーにパスを使用するかどうかを判断するための新たなネクストホップを確認するようにする必要があり、ルータは、次のホップは、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「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計算（または共通点を実行して、プレフィクス単位の順序付けを使用することなく扱うことができることに注意してください）。
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秒程度のものであってもよいです。
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を持っていると、ネットワーク全体の同期アクションで、新しい古いから切り替えることであろう。この同期変化を達成する一つの方法は、ルータの壁クロックを同期させるため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を参照）と組み合わせることができます。具体的には、すべてのトラフィックは、タイプC・ツー・タイプCのトラフィックがループの使用を介してマイクロループから保護される宛先のタイプC.であると考える両方とも、ルータのペア間のトラフィックを除いPLSNを使用することができ-prevention方法。
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).
しかし、新しいネクストホップルータはタイプCであると先を考慮するかどうかを決定することは計算集約的であってもよいです。別のアプローチは、すべてのローカルC型宛先のループ防止方法を使用することであろう。これは、任意の付加的な計算を必要としないが、（新しいネクストホップルータが、これはタイプ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.
リンクXYの失敗時に、PLSNによれば、Sは、しかしながら、R及びTの両方の順序付けられたFIBランクがゼロになり、したがってこれらは、同じ時間間隔中にそれらのFIBを変更することができるD.へのトラフィックのための安全な隣人としてRを考えるであろう。 Rは、Tの前に変更された場合、その後、ループは、より多くのC型ルータの導入コストで、これはPLSNは、現在指定よりも強い安全条件を使用することによって防止することができ、R、T、およびSの周りに形成され、従って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 [ANALYSIS]はマイクロループの形成を防止するための効率的なメカニズムであるが、唯一の部分的な解決です。これは、完全なソリューションの一部に有用な補助であるが、修正が必要な場合があります。
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.
残りの方法のうち、分散トンネルは、表側またはfarsideトンネルよりも著しく複雑であり、トンネルカプセル化解除の負荷を分散する必要がある場合にのみ考慮されるべきです。
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高速な方法ですが、適切な同期メカニズムを定義する必要が問題を持っています。一つの方法は、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.
手前側とfarsideトンネル方法はSRLGsと無相関変化に比較的容易に取り扱います。収束遅延が小さいことでしょう。しかし、これらの方法は、すべてのルータのハードウェアでサポート、および転送のパフォーマンスの問題を提起されていないトンネリングさフォワーディング、使用する必要があります。 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.
著者は、クラレンスFilsfilsによって作られたこの文書への貢献を認めたいと思います。
[ANALYSIS] Zinin, A., "Analysis and Minimization of Microloops in Link-state Routing Protocols", Work in Progress, October 2005.
[ANALYSIS]ジニン、A.、「リンクステートルーティングプロトコルでの分析とMicroloopsの最小化」、進歩、2005年10月に作業。
[FRR-TUNN] Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Fast Reroute using tunnels", Work in Progress, November 2007.
"トンネルを使用してIP高速リルート" [FRR-TUNN]ブライアント、S.、Filsfils、C.、Previdi、S.、およびM.シャンドは、進歩、2007年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月に作業。
[NOT-VIA] Shand, M., Bryant, S., and S. Previdi, "IP Fast Reroute Using Not-via Addresses", Work in Progress, July 2009.
"使用しない - を経由してIPアドレス高速リルート" [NOT-VIA]シャンド、M.、ブライアント、S.、およびS. Previdi、進歩、2009年7月での作業。
[OPT] Francois, P., Shand, M., and O. Bonaventure, "Disruption free topology reconfiguration in OSPF networks", IEEE INFOCOM May 2007, Anchorage.
[OPT]フランソワ、P.、シャンド、M.、およびO.ボナベンチャー、 "OSPFネットワークの中断のないトポロジの再構成"、IEEE INFOCOM 2007年5月、アンカレッジ。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]ミルズ、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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、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.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、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]パン、P.、ツバメ、G.、およびA.アトラスは、RFC 4090、2005年5月 "高速リルート機能拡張は、LSPトンネルの-TEをRSVPに"。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、Minei、I.、およびB.トーマス、 "LDP仕様"、RFC 5036、2007年10月。
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.
[RFC5714]シャンド、M.とS.ブライアント、 "IP高速リルートフレームワーク"、RFC 5714、2010年1月。
[SIG] Francois, P. and O. Bonaventure, "Avoiding transient loops during IGP convergence", IEEE INFOCOM March 2005, Miami.
"IGPの収束時の過渡的なループを回避" [SIG]フランソワ、P.およびO.ボナベンチャー、IEEE INFOCOM 2005年3月、マイアミ。
[oFIB] Francois, P., "Loop-free convergence using oFIB", Work in Progress, February 2008.
[oFIB]フランソワ、P.、 "oFIBを使用してループフリーコンバージェンス"、進歩、2008年2月に作業。
Authors' Addresses
著者のアドレス
Mike Shand Cisco Systems 250, Longwater Ave, Green Park, Reading, RG2 6GB United Kingdom
マイク・シャンドシスコシステムズ250、Longwaterアベニュー、グリーンパーク、読書、RG2 6ギガバイトイギリス
EMail: mshand@cisco.com
メールアドレス：mshand@cisco.com
Stewart Bryant Cisco Systems 250, Longwater Ave, Green Park, Reading, RG2 6GB United Kingdom
スチュワートブライアントシスコシステムズ250、Longwaterアベニュー、グリーンパーク、読書、RG2 6ギガバイトイギリス
EMail: stbryant@cisco.com
メールアドレス：stbryant@cisco.com