[要約] RFC 6413は、リンクステートIGPデータプレーン経路収束のベンチマーキング方法論に関するものです。このRFCの目的は、異なるネットワーク構成での経路収束の性能を比較し、ネットワークの信頼性とパフォーマンスを向上させるための基準を提供することです。
Internet Engineering Task Force (IETF) S. Poretsky
Request for Comments: 6413 Allot Communications
Category: Informational B. Imhoff
ISSN: 2070-1721 Juniper Networks
K. Michielsen
Cisco Systems
November 2011
Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence
リンク状態IGPデータプレーンルートの収束のベンチマーク方法論
Abstract
概要
This document describes the methodology for benchmarking Link-State Interior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The methodology can be applied to any link-state IGP, such as IS-IS and OSPF.
このドキュメントでは、リンク状態のインテリアゲートウェイプロトコル（IGP）ルート収束のベンチマークの方法論について説明します。方法論は、外部の観察可能な（ブラックボックス）データプレーン測定を介してIGP収束時間のベンチマークに使用されます。方法論は、IS-ISやOSPFなどのリンク状態IGPに適用できます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6413.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6413で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eのセクション4で説明されているように、簡略化されたBSDライセンステキストを含める必要があります。
the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
信頼の法的規定と、簡略化されたBSDライセンスに記載されているように、保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Factors for IGP Route Convergence Time . . . . . . . . . . 4
1.3. Use of Data Plane for IGP Route Convergence
Benchmarking . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Applicability and Scope . . . . . . . . . . . . . . . . . 6
2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 6
3. Test Topologies . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Test Topology for Local Changes . . . . . . . . . . . . . 7
3.2. Test Topology for Remote Changes . . . . . . . . . . . . . 8
3.3. Test Topology for Local ECMP Changes . . . . . . . . . . . 10
3.4. Test Topology for Remote ECMP Changes . . . . . . . . . . 11
3.5. Test topology for Parallel Link Changes . . . . . . . . . 11
4. Convergence Time and Loss of Connectivity Period . . . . . . . 12
4.1. Convergence Events without Instant Traffic Loss . . . . . 13
4.2. Loss of Connectivity (LoC) . . . . . . . . . . . . . . . . 16
5. Test Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1. IGP Selection . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Routing Protocol Configuration . . . . . . . . . . . . . . 17
5.3. IGP Topology . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5. Interface Types . . . . . . . . . . . . . . . . . . . . . 18
5.6. Offered Load . . . . . . . . . . . . . . . . . . . . . . . 18
5.7. Measurement Accuracy . . . . . . . . . . . . . . . . . . . 19
5.8. Measurement Statistics . . . . . . . . . . . . . . . . . . 20
5.9. Tester Capabilities . . . . . . . . . . . . . . . . . . . 20
6. Selection of Convergence Time Benchmark Metrics and Methods . 20
6.1. Loss-Derived Method . . . . . . . . . . . . . . . . . . . 21
6.1.1. Tester Capabilities . . . . . . . . . . . . . . . . . 21
6.1.2. Benchmark Metrics . . . . . . . . . . . . . . . . . . 21
6.1.3. Measurement Accuracy . . . . . . . . . . . . . . . . . 21
6.2. Rate-Derived Method . . . . . . . . . . . . . . . . . . . 22
6.2.1. Tester Capabilities . . . . . . . . . . . . . . . . . 22
6.2.2. Benchmark Metrics . . . . . . . . . . . . . . . . . . 23
6.2.3. Measurement Accuracy . . . . . . . . . . . . . . . . . 23
6.3. Route-Specific Loss-Derived Method . . . . . . . . . . . . 24
6.3.1. Tester Capabilities . . . . . . . . . . . . . . . . . 24
6.3.2. Benchmark Metrics . . . . . . . . . . . . . . . . . . 24
6.3.3. Measurement Accuracy . . . . . . . . . . . . . . . . . 24
7. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 25
8. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Interface Failure and Recovery . . . . . . . . . . . . . . 27
8.1.1. Convergence Due to Local Interface Failure and
Recovery . . . . . . . . . . . . . . . . . . . . . . . 27
8.1.2. Convergence Due to Remote Interface Failure and
Recovery . . . . . . . . . . . . . . . . . . . . . . . 28
8.1.3. Convergence Due to ECMP Member Local Interface
Failure and Recovery . . . . . . . . . . . . . . . . . 30
8.1.4. Convergence Due to ECMP Member Remote Interface
Failure and Recovery . . . . . . . . . . . . . . . . . 31
8.1.5. Convergence Due to Parallel Link Interface Failure
and Recovery . . . . . . . . . . . . . . . . . . . . . 32
8.2. Other Failures and Recoveries . . . . . . . . . . . . . . 33
8.2.1. Convergence Due to Layer 2 Session Loss and
Recovery . . . . . . . . . . . . . . . . . . . . . . . 33
8.2.2. Convergence Due to Loss and Recovery of IGP
Adjacency . . . . . . . . . . . . . . . . . . . . . . 34
8.2.3. Convergence Due to Route Withdrawal and
Re-Advertisement . . . . . . . . . . . . . . . . . . . 35
8.3. Administrative Changes . . . . . . . . . . . . . . . . . . 37
8.3.1. Convergence Due to Local Interface Administrative
Changes . . . . . . . . . . . . . . . . . . . . . . . 37
8.3.2. Convergence Due to Cost Change . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . . 41
Convergence time is a critical performance parameter. Service Providers use IGP convergence time as a key metric of router design and architecture. Fast network convergence can be optimally achieved through deployment of fast converging routers. Customers of Service Providers use packet loss due to Interior Gateway Protocol (IGP) convergence as a key metric of their network service quality. IGP route convergence is a Direct Measure of Quality (DMOQ) when benchmarking the data plane. The fundamental basis by which network users and operators benchmark convergence is packet loss and other packet impairments, which are externally observable events having direct impact on their application performance. For this reason, it is important to develop a standard methodology for benchmarking link-state IGP convergence time through externally observable (black-box) data-plane measurements. All factors contributing to convergence time are accounted for by measuring on the data plane.
収束時間は重要なパフォーマンスパラメーターです。サービスプロバイダーは、ルーターの設計とアーキテクチャの重要なメトリックとしてIGP収束時間を使用します。高速ネットワーク収束は、高速収束ルーターの展開を通じて最適に達成できます。サービスプロバイダーの顧客は、ネットワークサービス品質の重要なメトリックとして、インテリアゲートウェイプロトコル（IGP）収束によりパケット損失を使用します。IGPルート収束は、データプレーンをベンチマークするときの品質（DMOQ）の直接的な尺度です。ネットワークユーザーとオペレーターが収束をベンチマークする基本的な基盤は、パケット損失とその他のパケット障害であり、アプリケーションのパフォーマンスに直接影響を与える外部で観察可能なイベントです。このため、外部の観察可能な（ブラックボックス）データプレーン測定を介して、リンク状態のIGP収束時間をベンチマークするための標準的な方法論を開発することが重要です。収束時間に寄与するすべての要因は、データプレーンで測定することにより説明されます。
There are four major categories of factors contributing to the measured IGP convergence time. As discussed in [Vi02], [Ka02], [Fi02], [Al00], [Al02], and [Fr05], these categories are Event Detection, Shortest Path First (SPF) Processing, Link State Advertisement (LSA) / Link State Packet (LSP) Advertisement, and Forwarding Information Base (FIB) Update. These have numerous components that influence the convergence time, including but not limited to the list below:
測定されたIGP収束時間に寄与する要因には4つの主要なカテゴリがあります。[vi02]、[ka02]、[fi02]、[al00]、[al02]、および[fr05]で説明したように、これらのカテゴリはイベント検出、最短経路最初（SPF）処理、リンク状態広告（LSA） /リンクですState Packet（LSP）広告、および転送情報ベース（FIB）アップデート。これらには、以下のリストを含むがこれらに限定されない収束時間に影響を与える多数のコンポーネントがあります。
o Event Detection
o イベント検出
* Physical-Layer Failure/Recovery Indication Time
* 身体層の故障/回復の表示時間
* Layer 2 Failure/Recovery Indication Time
* レイヤー2障害/回復指示時間
* IGP Hello Dead Interval
* IGP Hello Deadインターバル
o SPF Processing
o SPF処理
* SPF Delay Time
* SPF遅延時間
* SPF Hold Time
* SPF保持時間
* SPF Execution Time
* SPF実行時間
o LSA/LSP Advertisement
o LSA/LSP広告
* LSA/LSP Generation Time
* LSA/LSP生成時間
* LSA/LSP Flood Packet Pacing
* LSA/LSPフラッドパケットペース
* LSA/LSP Retransmission Packet Pacing
* LSA/LSP再送信パケットペーシング
o FIB Update
o FIBアップデート
* Tree Build Time
* ツリービルド時間
* Hardware Update Time
* ハードウェアの更新時間
o Increased Forwarding Delay due to Queueing
o キューイングによる転送遅延の増加
The contribution of each of the factors listed above will vary with each router vendor's architecture and IGP implementation. Routers may have a centralized forwarding architecture, in which one forwarding table is calculated and referenced for all arriving packets, or a distributed forwarding architecture, in which the central forwarding table is calculated and distributed to the interfaces for local look-up as packets arrive. The distributed forwarding tables are typically maintained (loaded and changed) in software.
上記の各要因の貢献は、各ルーターベンダーのアーキテクチャとIGPの実装によって異なります。ルーターには集中転送アーキテクチャがあり、1つの転送テーブルが計算され、到着するすべてのパケットについて参照されます。または、パケットが到着するとローカルルックアップのために、中央転送テーブルが計算され、ローカルルックアップのインターフェイスに分散されます。分散型転送テーブルは、通常、ソフトウェアで維持され（ロードおよび変更されています）。
The variation in router architecture and implementation necessitates the design of a convergence test that considers all of these components contributing to convergence time and is independent of the Device Under Test (DUT) architecture and implementation. The benefit of designing a test for these considerations is that it enables black-box testing in which knowledge of the routers' internal implementation is not required. It is then possible to make valid use of the convergence benchmarking metrics when comparing routers from different vendors.
ルーターアーキテクチャと実装のバリエーションには、収束時間に寄与するこれらすべてのコンポーネントを考慮し、テスト中のデバイス（DUT）アーキテクチャと実装に依存しない収束テストの設計が必要です。これらの考慮事項のテストを設計する利点は、ルーターの内部実装の知識が必要ないブラックボックステストを可能にすることです。その後、さまざまなベンダーのルーターを比較する際に、収束ベンチマークメトリックを有効に使用することができます。
Convergence performance is tightly linked to the number of tasks a router has to deal with. As the most important tasks are mainly related to the control plane and the data plane, the more the DUT is stressed as in a live production environment, the closer performance measurement results match the ones that would be observed in a live production environment.
収束性能は、ルーターが処理しなければならないタスクの数に緊密にリンクしています。最も重要なタスクは主にコントロールプレーンとデータプレーンに関連しているため、生産環境のようにDUTが強調されるため、パフォーマンス測定の結果は、生産環境で観察されるパフォーマンスの結果と一致します。
Customers of Service Providers use packet loss and other packet impairments as metrics to calculate convergence time. Packet loss and other packet impairments are externally observable events having
サービスプロバイダーの顧客は、収束時間を計算するためにメトリックとしてパケット損失およびその他のパケット障害を使用します。パケットの損失やその他のパケット障害は、外部的に観察可能なイベントです
direct impact on customers' application performance. For this reason, it is important to develop a standard router benchmarking methodology that is a Direct Measure of Quality (DMOQ) for measuring IGP convergence. An additional benefit of using packet loss for calculation of IGP Route Convergence time is that it enables black-box tests to be designed. Data traffic can be offered to the Device Under Test (DUT), an emulated network event can be forced to occur, and packet loss and other impaired packets can be externally measured to calculate the convergence time. Knowledge of the DUT architecture and IGP implementation is not required. There is no need to rely on the DUT to produce the test results. There is no need to build intrusive test harnesses for the DUT. All factors contributing to convergence time are accounted for by measuring on the data plane.
顧客のアプリケーションパフォーマンスに直接影響します。このため、IGP収束を測定するための品質（DMOQ）の直接的な尺度である標準のルーターベンチマーク方法論を開発することが重要です。IGPルートの収束時間の計算にパケット損失を使用することの追加の利点は、ブラックボックステストを設計できることです。データトラフィックはテスト中のデバイスに提供できます（DUT）、エミュレートされたネットワークイベントを強制することができ、パケット損失およびその他の障害パケットを外部的に測定して収束時間を計算できます。DUTアーキテクチャとIGPの実装に関する知識は必要ありません。テスト結果を作成するためにDUTに頼る必要はありません。DUTのために邪魔なテストハーネスを構築する必要はありません。収束時間に寄与するすべての要因は、データプレーンで測定することにより説明されます。
Other work of the Benchmarking Methodology Working Group (BMWG) focuses on characterizing single router control-plane convergence. See [Ma05], [Ma05t], and [Ma05c].
ベンチマーク方法論ワーキンググループ（BMWG）のその他の作業は、単一のルーター制御プレーン収束の特性評価に焦点を当てています。[MA05]、[MA05T]、および[MA05C]を参照してください。
The methodology described in this document can be applied to IPv4 and IPv6 traffic and link-state IGPs such as IS-IS [Ca90][Ho08], OSPF [Mo98][Co08], and others. IGP adjacencies established over any kind of tunnel (such as Traffic Engineering tunnels) are outside the scope of this document. Convergence time benchmarking in topologies with IGP adjacencies that are not point-to-point will be covered in a later document. Convergence from Bidirectional Forwarding Detection (BFD) is outside the scope of this document. Non-Stop Forwarding (NSF), Non-Stop Routing (NSR), Graceful Restart (GR), and any other High Availability mechanism are outside the scope of this document. Fast reroute mechanisms such as IP Fast-Reroute [Sh10i] or MPLS Fast-Reroute [Pa05] are outside the scope of this document.
このドキュメントで説明されている方法論は、IS-IS [CA90] [HO08]、OSPF [MO98] [CO08]などのIPv4およびIPv6トラフィックおよびリンク状態IGPSに適用できます。あらゆる種類のトンネル（トラフィックエンジニアリングトンネルなど）に基づいて確立されたIGPの隣接は、このドキュメントの範囲外です。ポイントツーポイントではないIGP隣接を使用したトポロジーの収束時間ベンチマークは、後のドキュメントで説明されます。双方向転送検出（BFD）からの収束は、このドキュメントの範囲外です。ノンストップ転送（NSF）、ノンストップルーティング（NSR）、優雅な再起動（GR）、およびその他の高可用性メカニズムは、このドキュメントの範囲外です。IP Fast-Reroute [SH10I]やMPLS Fast-Reroute [PA05]などの高速再ルートメカニズムは、このドキュメントの範囲外です。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [Br97]. RFC 2119 defines the use of these keywords to help make the intent of Standards Track documents as clear as possible. While this document uses these keywords, this document is not a Standards Track document.
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" ingle "、" low "obs"、 "becommended"、 ""、 "optional"は、BCP 14、RFC 2119 [BR97]に記載されているように解釈されます。RFC 2119は、これらのキーワードの使用を定義して、標準の意図を可能な限り明確に追跡するのに役立ちます。このドキュメントではこれらのキーワードを使用していますが、このドキュメントは標準トラックドキュメントではありません。
This document uses much of the terminology defined in [Po11t]. For any conflicting content, this document supersedes [Po11t]. This document uses existing terminology defined in other documents issued by the Benchmarking Methodology Working Group (BMWG). Examples include, but are not limited to:
このドキュメントでは、[PO11T]で定義されている用語の多くを使用しています。競合するコンテンツについては、このドキュメントは[PO11T]に取って代わります。このドキュメントでは、ベンチマークメソッドワーキンググループ（BMWG）によって発行された他のドキュメントで定義された既存の用語を使用します。例には、以下が含まれますが、これらに限定されません。
Throughput [Br91], Section 3.17 Offered Load [Ma98], Section 3.5.2 Forwarding Rate [Ma98], Section 3.6.1 Device Under Test (DUT) [Ma98], Section 3.1.1 System Under Test (SUT) [Ma98], Section 3.1.2 Out-of-Order Packet [Po06], Section 3.3.4 Duplicate Packet [Po06], Section 3.3.5 Stream [Po06], Section 3.3.2 Forwarding Delay [Po06], Section 3.2.4 IP Packet Delay Variation (IPDV) [De02], Section 1.2 Loss Period [Ko02], Section 4
スループット[BR91]、セクション3.17は、負荷[MA98]、セクション3.5.2転送レート[MA98]、テスト中のセクション3.6.1デバイス[MA98]、テスト中のセクション3.1.1システム（SUT）[MA98]を提供しました。、セクション3.1.2オーダーオブオーダーパケット[PO06]、セクション3.3.4重複パケット[PO06]、セクション3.3.5ストリーム[PO06]、セクション3.3.2転送遅延[PO06]、セクション3.2.4 IPパケット遅延変動（IPDV）[DE02]、セクション1.2損失期間[KO02]、セクション4
Figure 1 shows the test topology to measure IGP convergence time due to local Convergence Events such as Local Interface failure and recovery (Section 8.1.1), Layer 2 session failure and recovery (Section 8.2.1), and IGP adjacency failure and recovery (Section 8.2.2). This topology is also used to measure IGP convergence time due to route withdrawal and re-advertisement (Section 8.2.3) and to measure IGP convergence time due to route cost change (Section 8.3.2) Convergence Events. IGP adjacencies MUST be established between Tester and DUT: one on the Ingress Interface, one on the Preferred Egress Interface, and one on the Next-Best Egress Interface. For this purpose, the Tester emulates three routers (RTa, RTb, and RTc), each establishing one adjacency with the DUT.
図1は、ローカルインターフェイスの故障と回復（セクション8.1.1）、レイヤー2セッションの障害と回復（セクション8.2.1）、IGP隣接障害と回復などのローカル収束イベントによるIGP収束時間を測定するテストトポロジを示しています。セクション8.2.2）。このトポロジーは、ルートの引き出しと再承認によるIGP収束時間を測定し（セクション8.2.3）、ルートコストの変化によるIGP収束時間（セクション8.3.2）の収束イベントを測定するためにも使用されます。IGPの隣接は、テスターとDUTの間に確立する必要があります。1つはインターフェースインターフェイスに、1つは優先されたEgressインターフェイス、もう1つは次のベストEgressインターフェイスにあります。この目的のために、テスターは3つのルーター（RTA、RTB、およびRTC）をエミュレートし、それぞれがDUTに隣接する隣接を確立します。
-------
| | Preferred .......
| |------------------. RTb .
....... Ingress | | Egress Interface .......
. RTa .------------| DUT |
....... Interface | | Next-Best .......
| |------------------. RTc .
| | Egress Interface .......
-------
Figure 1: IGP convergence test topology for local changes
図1：局所的な変更のためのIGP収束テストトポロジ
Figure 2 shows the test topology to measure IGP convergence time due to local Convergence Events with a non-Equal Cost Multipath (ECMP) Preferred Egress Interface and ECMP Next-Best Egress Interfaces (Section 8.1.1). In this topology, the DUT is configured with each Next-Best Egress Interface as a member of a single ECMP set. The Preferred Egress Interface is not a member of an ECMP set. The Tester emulates N+2 neighbor routers (N>0): one router for the
図2は、非等しいコストマルチパス（ECMP）優先出力インターフェイスとECMPの次のベスト出力インターフェイスを備えたローカル収束イベントによるIGP収束時間を測定するテストトポロジを示しています（セクション8.1.1）。このトポロジでは、DUTは、単一のECMPセットのメンバーとして、次の最高の出口インターフェイスで構成されています。好ましい出口インターフェイスは、ECMPセットのメンバーではありません。テスターはn 2ネイバールーターをエミュレートします（n> 0）：1つのルーター
Ingress Interface (RTa), one router for the Preferred Egress Interface (RTb), and N routers for the members of the ECMP set (RTc1...RTcN). IGP adjacencies MUST be established between Tester and DUT: one on the Ingress Interface, one on the Preferred Egress Interface, and one on each member of the ECMP set. When the test specifies to observe the Next-Best Egress Interface statistics, the combined statistics for all ECMP members should be observed.
Ingress Interface（RTA）、ECMPセット（RTC1 ... RTCN）のメンバーの優先出力インターフェイス（RTB）の1つのルーター、およびnルーター。IGPの隣接は、テスターとDUTの間に確立する必要があります。1つは、侵入インターフェイスに1つ、ECMPセットの各メンバーに1つずつ、1つはECMPセットの各メンバーに確立する必要があります。テストが次のベスト出力インターフェイス統計を観察するように指定する場合、すべてのECMPメンバーの統合統計を観察する必要があります。
-------
| | Preferred .......
| |------------------. RTb .
| | Egress Interface .......
| |
| | ECMP Set ........
....... Ingress | |------------------. RTc1 .
. RTa .------------| DUT | Interface 1 ........
....... Interface | | .
| | .
| | .
| | ECMP Set ........
| |------------------. RTcN .
| | Interface N ........
-------
Figure 2: IGP convergence test topology for local changes with non-ECMP to ECMP convergence
図2：ECMP収束からECMP以外の局所的な変化のためのIGP収束テストトポロジ
Figure 3 shows the test topology to measure IGP convergence time due to Remote Interface failure and recovery (Section 8.1.2). In this topology, the two routers DUT1 and DUT2 are considered the System Under Test (SUT) and SHOULD be identically configured devices of the same model. IGP adjacencies MUST be established between Tester and SUT, one on the Ingress Interface, one on the Preferred Egress Interface, and one on the Next-Best Egress Interface. For this purpose, the Tester emulates three routers (RTa, RTb, and RTc). In this topology, a packet forwarding loop, also known as micro-loop (see [Sh10]), may occur transiently between DUT1 and DUT2 during convergence.
図3は、リモートインターフェイスの故障と回復によるIGP収束時間を測定するテストトポロジーを示しています（セクション8.1.2）。このトポロジでは、2つのルーターDUT1とDUT2はテスト中のシステム（SUT）と見なされ、同じモデルのデバイスが同じように構成されている必要があります。IGPの隣接は、テスターとSUTの間に、1つはインターフェイスに1つ、希望するEugressインターフェイス、もう1つは次のベストEgressインターフェイスに確立する必要があります。この目的のために、テスターは3つのルーター（RTA、RTB、およびRTC）をエミュレートします。このトポロジでは、マイクロループとしても知られるパケット転送ループ（[SH10]を参照）が、収束中にDUT1とDUT2の間で一時的に発生する可能性があります。
--------
| | -------- Preferred .......
| |--| DUT2 |------------------. RTb .
....... Ingress | | -------- Egress Interface .......
. RTa .------------| DUT1 |
....... Interface | | Next-Best .......
| |----------------------------. RTc .
| | Egress Interface .......
--------
Figure 3: IGP convergence test topology for remote changes
図3：リモート変更のIGP収束テストトポロジー
Figure 4 shows the test topology to measure IGP convergence time due to remote Convergence Events with a non-ECMP Preferred Egress Interface and ECMP Next-Best Egress Interfaces (Section 8.1.2). In this topology the two routers DUT1 and DUT2 are considered System Under Test (SUT) and MUST be identically configured devices of the same model. Router DUT1 is configured with the Next-Best Egress Interface an ECMP set of interfaces. The Preferred Egress Interface of DUT1 is not a member of an ECMP set. The Tester emulates N+2 neighbor routers (N>0), one for the Ingress Interface (RTa), one for DUT2 (RTb) and one for each member of the ECMP set (RTc1...RTcN). IGP adjacencies MUST be established between Tester and SUT, one on each interface of the SUT. For this purpose each of the N+2 routers emulated by the Tester establishes one adjacency with the SUT. In this topology, there is a possibility of a packet-forwarding loop that may occur transiently between DUT1 and DUT2 during convergence (micro-loop, see [Sh10]). When the test specifies to observe the Next-Best Egress Interface statistics, the combined statistics for all members of the ECMP set should be observed.
図4は、非ECMP優先出力インターフェイスとECMPの次のベスト出力インターフェイスを備えたリモート収束イベントによるIGP収束時間を測定するテストトポロジを示しています（セクション8.1.2）。このトポロジでは、2つのルーターDUT1とDUT2がテスト中のシステム（SUT）と見なされ、同じモデルの同一に構成されたデバイスでなければなりません。 Router DUT1は、次のベスト出力インターフェイスでECMPセットのインターフェイスで構成されています。 DUT1の好ましい出口インターフェイスは、ECMPセットのメンバーではありません。テスターは、n 2ネイバールーター（n> 0）、1つはイングレスインターフェイス（RTA）、1つはDUT2（RTB）、1つはECMPセット（RTC1 ... RTCN）の各メンバーにエミュレートします。 IGPの隣接は、SUTの各インターフェイスに1つずつ、テスターとSUTの間に確立する必要があります。この目的のために、テスターによってエミュレートされた各n 2ルーターは、SUTに1つの隣接を確立します。このトポロジでは、収束中にDUT1とDUT2の間で一時的に発生する可能性のあるパケットに向かうループの可能性があります（マイクロループ、[SH10]を参照）。テストが次のベスト出力インターフェイス統計を観察するように指定する場合、ECMPセットのすべてのメンバーの統合統計を観察する必要があります。
--------
| | -------- Preferred .......
| |--| DUT2 |------------------. RTb .
| | -------- Egress Interface .......
| |
| | ECMP Set ........
....... Ingress | |----------------------------. RTc1 .
. RTa .------------| DUT1 | Interface 1 ........
....... Interface | | .
| | .
| | .
| | ECMP Set ........
| |----------------------------. RTcN .
| | Interface N ........
--------
Figure 4: IGP convergence test topology for remote changes with non-ECMP to ECMP convergence
図4：ECMP収束から非ECMPによるリモート変更のIGP収束テストトポロジ
Figure 5 shows the test topology to measure IGP convergence time due to local Convergence Events of a member of an Equal Cost Multipath (ECMP) set (Section 8.1.3). In this topology, the DUT is configured with each egress interface as a member of a single ECMP set and the Tester emulates N+1 next-hop routers, one for the Ingress Interface (RTa) and one for each member of the ECMP set (RTb1...RTbN). IGP adjacencies MUST be established between Tester and DUT, one on the Ingress Interface and one on each member of the ECMP set. For this purpose, each of the N+1 routers emulated by the Tester establishes one adjacency with the DUT. When the test specifies to observe the Next-Best Egress Interface statistics, the combined statistics for all ECMP members except the one affected by the Convergence Event should be observed.
図5は、同等のコストマルチパス（ECMP）セット（セクション8.1.3）のメンバーのローカル収束イベントによるIGP収束時間を測定するテストトポロジを示しています。このトポロジでは、DUTは各出口インターフェイスで単一のECMPセットのメンバーとして構成され、テスターはn 1ネクストホップルーターをエミュレートします。... rtbn）。IGPの隣接は、テスターとDUTの間に、1つはIngressインターフェイスに、もう1つはECMPセットの各メンバーに確立する必要があります。この目的のために、テスターによってエミュレートされた各n 1ルーターは、DUTに隣接する隣接を確立します。テストが次のベスト出力インターフェイス統計を観察するように指定する場合、収束イベントの影響を受けるものを除くすべてのECMPメンバーの統合統計を観察する必要があります。
-------
| | ECMP Set ........
| |-------------. RTb1 .
| | Interface 1 ........
....... Ingress | | .
. RTa .------------| DUT | .
....... Interface | | .
| | ECMP Set ........
| |-------------. RTbN .
| | Interface N ........
-------
Figure 5: IGP convergence test topology for local ECMP changes
図5：ローカルECMPの変化のためのIGP収束テストトポロジ
Figure 6 shows the test topology to measure IGP convergence time due to remote Convergence Events of a member of an Equal Cost Multipath (ECMP) set (Section 8.1.4). In this topology, the two routers DUT1 and DUT2 are considered the System Under Test (SUT) and MUST be identically configured devices of the same model. Router DUT1 is configured with each egress interface as a member of a single ECMP set, and the Tester emulates N+1 neighbor routers (N>0), one for the Ingress Interface (RTa) and one for each member of the ECMP set (RTb1...RTbN). IGP adjacencies MUST be established between Tester and SUT, one on each interface of the SUT. For this purpose, each of the N+1 routers emulated by the Tester establishes one adjacency with the SUT (N-1 emulated routers are adjacent to DUT1 egress interfaces, one emulated router is adjacent to DUT1 Ingress Interface, and one emulated router is adjacent to DUT2). In this topology, there is a possibility of a packet-forwarding loop that may occur transiently between DUT1 and DUT2 during convergence (micro-loop, see [Sh10]). When the test specifies to observe the Next-Best Egress Interface statistics, the combined statistics for all ECMP members except the one affected by the Convergence Event should be observed.
図6は、同等のコストマルチパス（ECMP）セット（セクション8.1.4）のメンバーのリモート収束イベントによるIGP収束時間を測定するテストトポロジを示しています。このトポロジでは、2つのRouters DUT1とDUT2はテスト中のシステム（SUT）と見なされ、同じモデルのデバイスが同一に構成されている必要があります。 Router DUT1は、各EGMPセットのメンバーとして各出口インターフェイスで構成され、テスターはn 1ネイバールーター（n> 0）、1つはイングレスインターフェイス（RTA）、およびECMPセットの各メンバー（RTB1）をエミュレートします。 ... rtbn）。 IGPの隣接は、SUTの各インターフェイスに1つずつ、テスターとSUTの間に確立する必要があります。この目的のために、テスターによってエミュレートされた各n 1ルーターは、SUTに1つの隣接を確立します（n-1エミュレートルーターはdut1 egressインターフェイスに隣接しています。1つのエミュレートルーターはdut1イングレスインターフェイスに隣接し、1つのエミュレートされたルーターはに隣接しています。 dut2）。このトポロジでは、収束中にDUT1とDUT2の間で一時的に発生する可能性のあるパケットに向かうループの可能性があります（マイクロループ、[SH10]を参照）。テストが次のベスト出力インターフェイス統計を観察するように指定する場合、収束イベントの影響を受けるものを除くすべてのECMPメンバーの統合統計を観察する必要があります。
--------
| | ECMP Set -------- ........
| |-------------| DUT2 |---. RTb1 .
| | Interface 1 -------- ........
| |
| | ECMP Set ........
....... Ingress | |------------------------. RTb2 .
. RTa .------------| DUT1 | Interface 2 ........
....... Interface | | .
| | .
| | .
| | ECMP Set ........
| |------------------------. RTbN .
| | Interface N ........
--------
Figure 6: IGP convergence test topology for remote ECMP changes
図6：リモートECMPの変更のためのIGP収束テストトポロジ
Figure 7 shows the test topology to measure IGP convergence time due to local Convergence Events with members of a Parallel Link (Section 8.1.5). In this topology, the DUT is configured with each egress interface as a member of a Parallel Link and the Tester emulates two neighbor routers, one for the Ingress Interface (RTa) and one for the Parallel Link members (RTb). IGP adjacencies MUST be
図7は、並列リンクのメンバーとのローカル収束イベントによるIGP収束時間を測定するテストトポロジを示しています（セクション8.1.5）。このトポロジでは、DUTは各出口インターフェイスで並列リンクのメンバーとして構成され、テスターは2つの隣接ルーターをエミュレートします。IGPの隣接はそうでなければなりません
established on the Ingress Interface and on all N members of the Parallel Link between Tester and DUT (N>0). For this purpose, the routers emulated by the Tester establishes N+1 adjacencies with the DUT. When the test specifies to observe the Next-Best Egress Interface statistics, the combined statistics for all Parallel Link members except the one affected by the Convergence Event should be observed.
イングレスインターフェイスと、テスターとDUTの間の並列リンクのすべてのNメンバー（n> 0）に確立されています。この目的のために、テスターによってエミュレートされたルーターは、DUTとのn 1隣接を確立します。テストが次のベスト出力インターフェイス統計を観察するように指定する場合、収束イベントの影響を受けるものを除くすべての並列リンクメンバーの統合統計を観察する必要があります。
------- .......
| | Parallel Link . .
| |----------------. .
| | Interface 1 . .
....... Ingress | | . . .
. RTa .------------| DUT | . . RTb .
....... Interface | | . . .
| | Parallel Link . .
| |----------------. .
| | Interface N . .
------- .......
Figure 7: IGP convergence test topology for Parallel Link changes
図7：並列リンクの変更のためのIGP収束テストトポロジ
Two concepts will be highlighted in this section: convergence time and loss of connectivity period.
このセクションでは、2つの概念を強調します。収束時間と接続期間の損失。
The Route Convergence [Po11t] time indicates the period in time between the Convergence Event Instant [Po11t] and the instant in time the DUT is ready to forward traffic for a specific route on its Next-Best Egress Interface and maintains this state for the duration of the Sustained Convergence Validation Time [Po11t]. To measure Route Convergence time, the Convergence Event Instant and the traffic received from the Next-Best Egress Interface need to be observed.
ルートコンバージェンス[PO11T]時間は、収束イベントインスタント[PO11T]の間の期間を示し、DUTは次のベスト出力インターフェイスの特定のルートのトラフィックを転送する準備ができており、この状態を維持する準備ができています。持続的な収束検証時間[PO11T]の。ルートの収束時間を測定するには、収束イベントインスタントと次の最高の出口インターフェイスから受け取ったトラフィックを観察する必要があります。
The Route Loss of Connectivity Period [Po11t] indicates the time during which traffic to a specific route is lost following a Convergence Event until Full Convergence [Po11t] completes. This Route Loss of Connectivity Period can consist of one or more Loss Periods [Ko02]. For the test cases described in this document, it is expected to have a single Loss Period. To measure the Route Loss of Connectivity Period, the traffic received from the Preferred Egress Interface and the traffic received from the Next-Best Egress Interface need to be observed.
接続期間[PO11T]のルート損失は、完全な収束[PO11T]が完了するまで、収束イベントに続いて特定のルートへのトラフィックが失われる時間を示します。このルートの接続期間の損失は、1つ以上の損失期間で構成できます[KO02]。このドキュメントで説明されているテストケースでは、単一の損失期間があると予想されます。接続期間のルートの損失を測定するには、優先出力インターフェイスから受け取ったトラフィックと、次にベストの出口インターフェイスから受け取ったトラフィックを観察する必要があります。
The Route Loss of Connectivity Period is most important since that has a direct impact on the network user's application performance.
ネットワークユーザーのアプリケーションパフォーマンスに直接影響を与えるため、接続期間のルートの損失が最も重要です。
In general, the Route Convergence time is larger than or equal to the Route Loss of Connectivity Period. Depending on which Convergence Event occurs and how this Convergence Event is applied, traffic for a route may still be forwarded over the Preferred Egress Interface after the Convergence Event Instant, before converging to the Next-Best Egress Interface. In that case, the Route Loss of Connectivity Period is shorter than the Route Convergence time.
一般に、ルートの収束時間は、接続期間のルート損失期間以上です。どの収束イベントが発生するか、およびこの収束イベントの適用方法に応じて、次のベストエグレスインターフェイスに収束する前に、収束イベントインスタントの後に、ルートのトラフィックを優先される出口インターフェイスに転送することができます。その場合、接続期間のルート損失は、ルートの収束時間よりも短くなります。
At least one condition needs to be fulfilled for Route Convergence time to be equal to Route Loss of Connectivity Period. The condition is that the Convergence Event causes an instantaneous traffic loss for the measured route. A fiber cut on the Preferred Egress Interface is an example of such a Convergence Event.
ルートの収束時間がルートの接続期間の損失に等しくなるには、少なくとも1つの条件を満たす必要があります。条件は、収束イベントが測定されたルートの瞬間的なトラフィック損失を引き起こすことです。好ましい出口インターフェイスのファイバーカットは、このような収束イベントの例です。
A second condition applies to Route Convergence time measurements based on Connectivity Packet Loss [Po11t]. This second condition is that there is only a single Loss Period during Route Convergence. For the test cases described in this document, the second condition is expected to apply.
2番目の条件は、接続パケット損失[PO11T]に基づくルート収束時間測定に適用されます。この2番目の条件は、ルート収束中に1回の損失期間しかないことです。このドキュメントで説明されているテストケースの場合、2番目の条件が適用されると予想されます。
To measure convergence time benchmarks for Convergence Events caused by a Tester, such as an IGP cost change, the Tester MAY start to discard all traffic received from the Preferred Egress Interface at the Convergence Event Instant, or MAY separately observe packets received from the Preferred Egress Interface prior to the Convergence Event Instant. This way, these Convergence Events can be treated the same as Convergence Events that cause instantaneous traffic loss.
IGPコストの変更など、テスターによって引き起こされる収束イベントの収束時間ベンチマークを測定するために、テスターはコンバージェンスイベントインスタントで優先された出口インターフェイスから受け取ったすべてのトラフィックを破棄し始める可能性があります。コンバージェンスイベントインスタントの前のインターフェイス。このようにして、これらの収束イベントは、瞬間的なトラフィックの損失を引き起こす収束イベントと同じように扱うことができます。
To measure convergence time benchmarks without instantaneous traffic loss (either real or induced by the Tester) at the Convergence Event Instant, such as a reversion of a link failure Convergence Event, the Tester SHALL only observe packet statistics on the Next-Best Egress Interface. If using the Rate-Derived method to benchmark convergence times for such Convergence Events, the Tester MUST collect a timestamp at the Convergence Event Instant. If using a loss-derived method to benchmark convergence times for such Convergence Events, the Tester MUST measure the period in time between the Start Traffic Instant and the Convergence Event Instant. To measure this period in time, the Tester can collect timestamps at the Start Traffic Instant and the Convergence Event Instant.
リンク障害コンバージェンスイベントの復帰など、コンバージェンスイベントインスタントで瞬時のトラフィックの損失（テスターによって実際または誘導される）なしで収束時間ベンチマークを測定するには、テスターは次のベストエグレスインターフェイスのパケット統計のみを観察するものとします。レート由来の方法を使用して、このような収束イベントの収束時間をベンチマークする場合、テスターはコンバージェンスイベントのインスタントでタイムスタンプを収集する必要があります。損失由来の方法を使用して、このような収束イベントの収束時間をベンチマークする場合、テスターは開始トラフィックインスタントと収束イベントインスタントの間の期間を測定する必要があります。この期間を測定するために、テスターは開始トラフィックインスタントとコンバージェンスイベントのインスタントでタイムスタンプを収集できます。
The Convergence Event Instant together with the receive rate observations on the Next-Best Egress Interface allow the derivation of the convergence time benchmarks using the Rate-Derived Method [Po11t].
収束イベントは、次のベスト出力インターフェイスの受信レート観測と一緒に瞬時に瞬時に瞬時に、レート由来の方法[PO11T]を使用して収束時間ベンチマークの導出を可能にします。
By observing packets on the Next-Best Egress Interface only, the observed Impaired Packet count is the number of Impaired Packets between Traffic Start Instant and Convergence Recovery Instant. To measure convergence times using a loss-derived method, the Impaired Packet count between the Convergence Event Instant and the Convergence Recovery Instant is needed. The time between Traffic Start Instant and Convergence Event Instant must be accounted for. An example may clarify this.
次のベスト出力インターフェイスのみでパケットを観察することにより、観察されたパケットカウントの障害は、トラフィックの開始インスタントとコンバージェンス回復のインスタントの間の障害のあるパケットの数です。損失由来の方法を使用して収束時間を測定するには、コンバージェンスイベントインスタントと収束回復インスタントの間のパケットカウント障害が必要です。トラフィックの間の時間は、インスタントとコンバージェンスイベントのインスタントを考慮する必要があります。例はこれを明確にするかもしれません。
Figure 8 illustrates a Convergence Event without instantaneous traffic loss for all routes. The top graph shows the Forwarding Rate over all routes, the bottom graph shows the Forwarding Rate for a single route Rta. Some time after the Convergence Event Instant, the Forwarding Rate observed on the Preferred Egress Interface starts to decrease. In the example, route Rta is the first route to experience packet loss at time Ta. Some time later, the Forwarding Rate observed on the Next-Best Egress Interface starts to increase. In the example, route Rta is the first route to complete convergence at time Ta'.
図8は、すべてのルートの瞬間的な交通量のない収束イベントを示しています。上部グラフは、すべてのルートにわたる転送速度を示しています。下のグラフは、単一のルートRTAの転送速度を示しています。コンバージェンスイベントの瞬間後しばらくして、好ましい出口界面で観察された転送率は減少し始めます。この例では、Route RTAは、TAT TAでパケット損失を経験する最初のルートです。しばらくして、次のベスト出力インターフェイスで観察された転送率が増加し始めます。この例では、ルートRTAは、時間ta 'での収束を完了する最初のルートです。
^
Fwd |
Rate |------------- ............
| \ .
| \ .
| \ .
| \ .
|.................-.-.-.-.-.-.----------------
+----+-------+---------------+----------------->
^ ^ ^ ^ time
T0 CEI Ta Ta'
^
Fwd |
Rate |------------- .................
Rta | | .
| | .
|.............-.-.-.-.-.-.-.-.----------------
+----+-------+---------------+----------------->
^ ^ ^ ^ time
T0 CEI Ta Ta'
Preferred Egress Interface: --- Next-Best Egress Interface: ...
優先出力インターフェイス：---次のベストエグレスインターフェイス：...
T0 : Start Traffic Instant CEI : Convergence Event Instant Ta : the time instant packet loss for route Rta starts Ta' : the time instant packet impairment for route Rta ends
T0：トラフィックの開始インスタントCEI：コンバージェンスイベントインスタントTA：ルートRTAの時間インスタントパケット損失はTA 'を開始します。
Figure 8
図8
If only packets received on the Next-Best Egress Interface are observed, the duration of the loss period for route Rta can be calculated from the received packets as in Equation 1. Since the Convergence Event Instant is the start time for convergence time measurement, the period in time between T0 and CEI needs to be subtracted from the calculated result to become the convergence time, as in Equation 2.
次のベスト出力インターフェイスで受信したパケットのみが観察される場合、式1のように、ルートRTAの損失期間を受信パケットから計算できます。収束イベントインスタントは収束時間測定の開始時間であるため、T0とCEIの間の期間を計算された結果から差し引いて、式2のように収束時間になる必要があります。
Next-Best Egress Interface loss period
= (packets transmitted
- packets received from Next-Best Egress Interface) / tx rate
= Ta' - T0
Equation 1
式1
convergence time
= Next-Best Egress Interface loss period - (CEI - T0)
= Ta' - CEI
Equation 2
式2
Route Loss of Connectivity Period SHOULD be measured using the Route-Specific Loss-Derived Method. Since the start instant and end instant of the Route Loss of Connectivity Period can be different for each route, these cannot be accurately derived by only observing global statistics over all routes. An example may clarify this.
接続性のルート損失期間は、ルート固有の損失由来方法を使用して測定する必要があります。接続期間のルート損失の瞬間と終了の瞬間は、各ルートで異なる場合があるため、これらはすべてのルートでグローバルな統計のみを観察することで正確に導出することはできません。例はこれを明確にするかもしれません。
Following a Convergence Event, route Rta is the first route for which packet impairment starts; the Route Loss of Connectivity Period for route Rta starts at time Ta. Route Rtb is the last route for which packet impairment starts; the Route Loss of Connectivity Period for route Rtb starts at time Tb with Tb>Ta.
収束イベントに続いて、ルートRTAはパケット障害が始まる最初のルートです。ルートRTAの接続期間のルート損失は、時刻taで始まります。ルートRTBは、パケット障害が開始する最後のルートです。ルートRTBのルート損失は、TB> TAでTBから始まります。
^
Fwd |
Rate |-------- -----------
| \ /
| \ /
| \ /
| \ /
| ---------------
+------------------------------------------>
^ ^ ^ ^ time
Ta Tb Ta' Tb'
Tb'' Ta''
Figure 9: Example Route Loss Of Connectivity Period
図9：接続期間のルート損失の例
If the DUT implementation were such that route Rta would be the first route for which traffic loss ends at time Ta' (with Ta'>Tb), and route Rtb would be the last route for which traffic loss ends at time Tb' (with Tb'>Ta'). By only observing global traffic statistics over all routes, the minimum Route Loss of Connectivity Period would be measured as Ta'-Ta. The maximum calculated Route Loss of Connectivity Period would be Tb'-Ta. The real minimum and maximum Route Loss of Connectivity Periods are Ta'-Ta and Tb'-Tb. Illustrating this with the numbers Ta=0, Tb=1, Ta'=3, and Tb'=5 would give a Loss of Connectivity Period between 3 and 5 derived from the global traffic statistics, versus the real Loss of Connectivity Period between 3 and 4.
DUTの実装が、ルートRTAがTA '（Ta'> TBを使用）でトラフィックの損失が終了する最初のルートであり、ルートRTBがTBでトラフィックの損失が終了する最後のルートになるような場合の場合（tb '> ta'）。すべてのルートでグローバルなトラフィック統計のみを観察することにより、接続期間の最小ルート損失をTA'-TAとして測定します。接続期間の最大計算ルート損失はTB'-TAです。接続期間の実際の最小および最大ルート損失は、TA'-TAおよびTB'-TBです。これを数字= 0、Tb = 1、Ta '= 3、およびTb' = 5で説明することで、3から5の間の接続期間が失われ、3の間の接続期間の実際の損失が得られます。および4。
If the DUT implementation were such that route Rtb would be the first for which packet loss ends at time Tb'' and route Rta would be the last for which packet impairment ends at time Ta'', then the minimum and maximum Route Loss of Connectivity Periods derived by observing only global traffic statistics would be Tb''-Ta and Ta''-Ta. The real minimum and maximum Route Loss of Connectivity Periods are Tb''-Tb and Ta''-Ta. Illustrating this with the numbers Ta=0, Tb=1, Ta''=5, Tb''=3 would give a Loss of Connectivity Period between 3 and 5 derived from the global traffic statistics, versus the real Loss of Connectivity Period between 2 and 5.
DUTの実装が、ルートRTBがTB ''でパケット損失が最初に終了する最初のものであり、ルートRTAがパケット障害が時点で終了する最後のものである場合、接続の最小ルートルート損失と最大ルート損失はグローバルなトラフィック統計のみを観察することによって導出された期間は、TB '' -TAおよびTA '' -TAです。接続期間の実際の最小および最大ルート損失は、TB '' -TBおよびTA '' -TAです。これを数字= 0、tb = 1、ta '' = 5、tb '' = 3で説明すると、グローバルなトラフィック統計から派生した3〜5の間の接続期間が失われます。2と5。
The two implementation variations in the above example would result in the same derived minimum and maximum Route Loss of Connectivity Periods when only observing the global packet statistics, while the real Route Loss of Connectivity Periods are different.
上記の例の2つの実装のバリエーションは、グローバルなパケット統計のみを観察する場合、接続期間の接続期間の最小および最大ルート損失と同じ派生と最大のルート損失をもたらしますが、接続期間の実際のルート損失は異なります。
The test cases described in Section 8 can be used for link-state IGPs, such as IS-IS or OSPF. The IGP convergence time test methodology is identical.
セクション8で説明されているテストケースは、IS-ISやOSPFなどのリンク状態IGPに使用できます。IGP収束時間テスト方法は同一です。
The obtained results for IGP convergence time may vary if other routing protocols are enabled and routes learned via those protocols are installed. IGP convergence times SHOULD be benchmarked without routes installed from other protocols. Any enabled IGP routing protocol extension (such as extensions for Traffic Engineering) and any enabled IGP routing protocol security mechanism must be reported with the results.
IGP収束時間の得られた結果は、他のルーティングプロトコルが有効になり、それらのプロトコルを介して学習したルートがインストールされた場合に異なる場合があります。IGP収束時間は、他のプロトコルからルートを取り付けることなくベンチマークする必要があります。有効化されたIGPルーティングプロトコル拡張（トラフィックエンジニアリングの拡張など）および有効化されたIGPルーティングプロトコルセキュリティメカニズムは、結果とともに報告する必要があります。
The Tester emulates a single IGP topology. The DUT establishes IGP adjacencies with one or more of the emulated routers in this single IGP topology emulated by the Tester. See test topology details in Section 3. The emulated topology SHOULD only be advertised on the DUT egress interfaces.
テスターは単一のIGPトポロジをエミュレートします。DUTは、テスターによってエミュレートされたこの単一のIGPトポロジの1つ以上のエミュレートルーターを含むIGP隣接を確立します。セクション3のテストトポロジの詳細を参照してください。エミュレートされたトポロジーは、DUT Egressインターフェイスでのみ宣伝する必要があります。
The number of IGP routes and number of nodes in the topology, and the type of topology will impact the measured IGP convergence time. To obtain results similar to those that would be observed in an operational network, it is RECOMMENDED that the number of installed routes and nodes closely approximate that of the network (e.g., thousands of routes with tens or hundreds of nodes).
トポロジのIGPルート数とノードの数、およびトポロジの種類は、測定されたIGP収束時間に影響します。運用ネットワークで観察される結果と同様の結果を得るには、インストールされているルートとノードの数がネットワークの数に近いことをお勧めします（たとえば、数十または数百のノードを備えた数千のルート）。
The number of areas (for OSPF) and levels (for IS-IS) can impact the benchmark results.
領域の数（OSPF）とレベル（IS-IS）は、ベンチマークの結果に影響を与える可能性があります。
There are timers that may impact the measured IGP convergence times. The benchmark metrics MAY be measured at any fixed values for these timers. To obtain results similar to those that would be observed in an operational network, it is RECOMMENDED to configure the timers with the values as configured in the operational network.
測定されたIGP収束時間に影響を与える可能性のあるタイマーがあります。ベンチマークメトリックは、これらのタイマーの固定値で測定できます。運用ネットワークで観察される結果と同様の結果を得るには、運用ネットワークで構成されている値でタイマーを構成することをお勧めします。
Examples of timers that may impact measured IGP convergence time include, but are not limited to:
測定されたIGP収束時間に影響を与える可能性のあるタイマーの例には、以下が含まれますが、これらに限定されません。
Interface failure indication
インターフェイス障害表示
IGP hello timer
IGPハロータイマー
IGP dead-interval or hold-timer
IGP Dead-IntervalまたはHold-Timer
Link State Advertisement (LSA) or Link State Packet (LSP) generation delay
リンク状態広告（LSA）またはリンク状態パケット（LSP）生成遅延
LSA or LSP flood packet pacing
LSAまたはLSPフラッドパケットペース
Route calculation delay
ルート計算遅延
All test cases in this methodology document can be executed with any interface type. The type of media may dictate which test cases may be executed. Each interface type has a unique mechanism for detecting link failures, and the speed at which that mechanism operates will influence the measurement results. All interfaces MUST be the same media and Throughput [Br91][Br99] for each test case. All interfaces SHOULD be configured as point-to-point.
この方法論文書のすべてのテストケースは、任意のインターフェイスタイプで実行できます。メディアのタイプは、どのテストケースを実行できるかを決定する場合があります。各インターフェイスタイプには、リンク障害を検出するためのユニークなメカニズムがあり、そのメカニズムが動作する速度は測定結果に影響します。すべてのインターフェイスは、各テストケースの同じメディアとスループット[BR91] [BR99]でなければなりません。すべてのインターフェイスは、ポイントツーポイントとして構成する必要があります。
The Throughput of the device, as defined in [Br91] and benchmarked in [Br99] at a fixed packet size, needs to be determined over the preferred path and over the next-best path. The Offered Load SHOULD be the minimum of the measured Throughput of the device over the primary path and over the backup path. The packet size is selectable and MUST be recorded. Packet size is measured in bytes and includes the IP header and payload.
[BR91]で定義され、固定パケットサイズで[BR99]でベンチマークされているデバイスのスループットは、優先パスと次のベストパスで決定する必要があります。提供される負荷は、プライマリパスとバックアップパス上のデバイスの測定されたスループットの最小値である必要があります。パケットサイズは選択可能で、記録する必要があります。パケットサイズはバイトで測定され、IPヘッダーとペイロードが含まれます。
The destination addresses for the Offered Load MUST be distributed such that all routes or a statistically representative subset of all routes are matched and each of these routes is offered an equal share of the Offered Load. It is RECOMMENDED to send traffic matching all routes, but a statistically representative subset of all routes can be used if required.
提供された負荷の宛先アドレスは、すべてのルートまたはすべてのルートの統計的に代表的なサブセットが一致し、これらの各ルートが提供された負荷の平等なシェアが提供されるように分散する必要があります。すべてのルートに一致するトラフィックを送信することをお勧めしますが、必要に応じてすべてのルートの統計的に代表的なサブセットを使用できます。
Splitting traffic flows across multiple paths (as with ECMP or Parallel Link sets) is in general done by hashing on various fields on the IP or contained headers. The hashing is typically based on the IP source and destination addresses, the protocol ID, and higher-layer flow-dependent fields such as TCP/UDP ports. In practice, within a network core, the hashing is based mainly or exclusively on the IP source and destination addresses. Knowledge of the hashing algorithm used by the DUT is not always possible beforehand and would violate the black-box spirit of this document. Therefore, it is RECOMMENDED to use a randomly distributed range of source and destination IP addresses, protocol IDs, and higher-layer flow-dependent fields for the packets of the Offered Load (see also [Ne07]). The content of the Offered Load MUST remain the same during the test. It is RECOMMENDED to repeat a test multiple times with different random ranges of the header fields such that convergence time benchmarks are measured for different distributions of traffic over the available paths.
トラフィックの分割フローは、複数のパス（ECMPまたはパラレルリンクセットと同様）にわたって流れます。一般的には、IPまたは含まれているヘッダーのさまざまなフィールドをハッシュすることによって行われます。ハッシュは通常、IPソースと宛先アドレス、プロトコルID、およびTCP/UDPポートなどの高層フロー依存フィールドに基づいています。実際には、ネットワークコア内では、ハッシュは主にIPソースおよび宛先アドレスに基づいています。 DUTが使用するハッシュアルゴリズムの知識は、事前に常に可能であるとは限らず、このドキュメントのブラックボックススピリットに違反するでしょう。したがって、提供された負荷のパケットには、ソースおよび宛先IPアドレス、プロトコルID、および高層流量依存フィールドのランダムに分散された範囲の範囲を使用することをお勧めします（[NE07]も参照）。提供された負荷の内容は、テスト中は同じままでなければなりません。ヘッダーフィールドの異なるランダム範囲でテストを複数回繰り返すことをお勧めします。これにより、利用可能なパス上のトラフィックの異なる分布に対して収束時間ベンチマークが測定されるようにすることをお勧めします。
In the Remote Interface failure test cases using topologies 3, 4, and 6, there is a possibility of a packet-forwarding loop that may occur transiently between DUT1 and DUT2 during convergence (micro-loop, see [Sh10]). The Time To Live (TTL) or Hop Limit value of the packets sent by the Tester may influence the benchmark measurements since it determines which device in the topology may send an ICMP Time Exceeded Message for looped packets.
トポロジ3、4、および6を使用したリモートインターフェイス障害テストケースでは、収束中にDUT1とDUT2の間で一時的に発生する可能性のあるパケットフォワードループの可能性があります（マイクロループ、[SH10]を参照）。テスターが送信したパケットのライブ（TTL）またはホップ制限値は、トポロジ内のどのデバイスがループパケットのメッセージを超えたメッセージを送信できるかを決定するため、ベンチマーク測定に影響を与える可能性があります。
The duration of the Offered Load MUST be greater than the convergence time plus the Sustained Convergence Validation Time.
提供された負荷の期間は、収束時間と持続的な収束検証時間よりも大きくなければなりません。
Offered load should send a packet to each destination before sending another packet to the same destination. It is RECOMMENDED that the packets be transmitted in a round-robin fashion with a uniform interpacket delay.
提供された負荷は、同じ宛先に別のパケットを送信する前に、各宛先にパケットを送信する必要があります。パケットは、均一なインターパケット遅延でラウンドロビンの方法で送信することをお勧めします。
Since Impaired Packet count is observed to measure the Route Convergence Time, the time between two successive packets offered to each individual route is the highest possible accuracy of any Impaired-Packet-based measurement. The higher the traffic rate offered to each route, the higher the possible measurement accuracy.
障害のあるパケット数がルートの収束時間を測定するために観察されるため、個々のルートに提供される2つの連続したパケット間の時間は、パケットベースの障害ベースの測定の可能な限り最高の精度です。各ルートに提供されるトラフィックレートが高いほど、測定精度が高くなります。
Also see Section 6 for method-specific measurement accuracy.
また、メソッド固有の測定精度については、セクション6も参照してください。
The benchmark measurements may vary for each trial, due to the statistical nature of timer expirations, CPU scheduling, etc. Evaluation of the test data must be done with an understanding of generally accepted testing practices regarding repeatability, variance, and statistical significance of a small number of trials.
ベンチマークの測定値は、タイマーの満了、CPUスケジューリングなどの統計的性質により、試行ごとに異なる場合があります。テストデータの評価は、小規模の再現性、分散、および統計的有意性に関する一般に受け入れられているテスト慣行を理解して行う必要があります。試験数。
It is RECOMMENDED that the Tester used to execute each test case have the following capabilities:
各テストケースの実行に使用されるテスターには、次の機能があることをお勧めします。
1. Ability to establish IGP adjacencies and advertise a single IGP topology to one or more peers.
1. IGPの隣接を確立し、1つ以上のピアに単一のIGPトポロジを宣伝する能力。
2. Ability to measure Forwarding Delay, Duplicate Packets, and Out-of-Order Packets.
2. 転送遅延、重複パケット、およびオーダーアウトオブオーダーパケットを測定する機能。
3. An internal time clock to control timestamping, time measurements, and time calculations.
3. タイムスタンプ、時間測定、および時間の計算を制御するための内部タイムクロック。
4. Ability to distinguish traffic load received on the Preferred and Next-Best Interfaces [Po11t].
4. 優先され、次のベストインターフェイス[PO11T]で受信したトラフィック負荷を区別する機能。
5. Ability to disable or tune specific Layer 2 and Layer 3 protocol functions on any interface(s).
5. 特定のレイヤー2およびレイヤー3プロトコル関数を任意のインターフェイスで無効またはチューニングする機能。
The Tester MAY be capable of making non-data-plane convergence observations and using those observations for measurements. The Tester MAY be capable of sending and receiving multiple traffic Streams [Po06].
テスターは、非DATA平面収束観測を行い、測定のためにそれらの観測を使用することができる場合があります。テスターは、複数のトラフィックストリームを送信および受信できる場合があります[PO06]。
Also see Section 6 for method-specific capabilities.
メソッド固有の機能については、セクション6も参照してください。
Different convergence time benchmark methods MAY be used to measure convergence time benchmark metrics. The Tester capabilities are important criteria to select a specific convergence time benchmark method. The criteria to select a specific benchmark method include, but are not limited to:
さまざまな収束時間ベンチマークメソッドを使用して、収束時間ベンチマークメトリックを測定することができます。テスター機能は、特定の収束時間ベンチマーク法を選択するための重要な基準です。特定のベンチマークメソッドを選択する基準には、以下が含まれますが、これらに限定されません。
Tester capabilities: Sampling Interval, number of Stream statistics to collect Measurement accuracy: Sampling Interval, Offered Load, number of routes Test specification: number of routes DUT capabilities: Throughput, IP Packet Delay Variation
テスター機能：サンプリング間隔、測定精度を収集するためのストリーム統計の数：サンプリング間隔、提供された負荷、ルート数テスト仕様：ルート数DUT機能数：スループット、IPパケット遅延変動
To enable collecting statistics of Out-of-Order Packets per flow (see [Th00], Section 3), the Offered Load SHOULD consist of multiple Streams [Po06], and each Stream SHOULD consist of a single flow. If sending multiple Streams, the measured traffic statistics for all Streams MUST be added together.
フローあたりのオーダーアウトパケットの統計を収集できるようにするには（[Th00]、セクション3を参照）、提供された負荷は複数のストリーム[PO06]で構成され、各ストリームは単一のフローで構成する必要があります。複数のストリームを送信する場合、すべてのストリームの測定されたトラフィック統計を一緒に追加する必要があります。
In order to verify Full Convergence completion and the Sustained Convergence Validation Time, the Tester MUST measure Forwarding Rate each Packet Sampling Interval.
完全な収束完了と持続的な収束検証時間を検証するには、テスターは各パケットサンプリング間隔を測定する必要があります。
The total number of Impaired Packets between the start of the traffic and the end of the Sustained Convergence Validation Time is used to calculate the Loss-Derived Convergence Time.
トラフィックの開始と持続的な収束検証時間の終了の間の障害のあるパケットの総数を使用して、損失由来の収束時間を計算します。
The Loss-Derived Method can be used to measure the Loss-Derived Convergence Time, which is the average convergence time over all routes, and to measure the Loss-Derived Loss of Connectivity Period, which is the average Route Loss of Connectivity Period over all routes.
損失由来の方法を使用して、すべてのルートにわたる平均収束時間である損失由来の収束時間を測定し、接続期間の損失由来の損失を測定することができます。ルート。
The actual value falls within the accuracy interval [-(number of destinations/Offered Load), +(number of destinations/Offered Load)] around the value as measured using the Loss-Derived Method.
実際の値は[ - （宛先の数/提供された負荷の数）、（宛先数/提供された負荷の数）]の周りに、損失由来の方法を使用して測定されます。
To enable collecting statistics of Out-of-Order Packets per flow (see [Th00], Section 3), the Offered Load SHOULD consist of multiple Streams [Po06], and each Stream SHOULD consist of a single flow. If sending multiple Streams, the measured traffic statistics for all Streams MUST be added together.
フローあたりのオーダーアウトパケットの統計を収集できるようにするには（[Th00]、セクション3を参照）、提供された負荷は複数のストリーム[PO06]で構成され、各ストリームは単一のフローで構成する必要があります。複数のストリームを送信する場合、すべてのストリームの測定されたトラフィック統計を一緒に追加する必要があります。
The Tester measures Forwarding Rate each Sampling Interval. The Packet Sampling Interval influences the observation of the different convergence time instants. If the Packet Sampling Interval is large compared to the time between the convergence time instants, then the different time instants may not be easily identifiable from the Forwarding Rate observation. The presence of IP Packet Delay Variation (IPDV) [De02] may cause fluctuations of the Forwarding Rate observation and can prevent correct observation of the different convergence time instants.
テスターは、各サンプリング間隔を転送速度を測定します。パケットサンプリング間隔は、異なる収束時間の瞬間の観察に影響します。パケットサンプリング間隔が収束時間の瞬間の間の時間と比較して大きい場合、異なる時間瞬間は転送速度の観察から簡単に識別できない場合があります。IPパケット遅延変動（IPDV）[DE02]の存在は、転送速度観測の変動を引き起こし、異なる収束時間の瞬間の正しい観察を防ぐことができます。
The Packet Sampling Interval MUST be larger than or equal to the time between two consecutive packets to the same destination. For maximum accuracy, the value for the Packet Sampling Interval SHOULD be as small as possible, but the presence of IPDV may require the use of a larger Packet Sampling Interval. The Packet Sampling Interval MUST be reported.
パケットサンプリング間隔は、同じ宛先までの2つの連続したパケット間の時間以上である必要があります。最大限の精度のために、パケットサンプリング間隔の値はできるだけ小さくする必要がありますが、IPDVの存在には、より大きなパケットサンプリング間隔の使用が必要になる場合があります。パケットサンプリング間隔を報告する必要があります。
IPDV causes fluctuations in the number of received packets during each Packet Sampling Interval. To account for the presence of IPDV in determining if a convergence instant has been reached, Forwarding Delay SHOULD be observed during each Packet Sampling Interval. The minimum and maximum number of packets expected in a Packet Sampling Interval in presence of IPDV can be calculated with Equation 3.
IPDVは、各パケットサンプリング間隔中に受信パケットの数の変動を引き起こします。収束瞬間に到達したかどうかを判断する際にIPDVの存在を説明するために、各パケットサンプリング間隔で転送遅延を観察する必要があります。IPDVの存在下でパケットサンプリング間隔で予想されるパケットの最小および最大数は、式3で計算できます。
number of packets expected in a Packet Sampling Interval in presence of IP Packet Delay Variation = expected number of packets without IP Packet Delay Variation +/-( (maxDelay - minDelay) * Offered Load) where minDelay and maxDelay indicate (respectively) the minimum and maximum Forwarding Delay of packets received during the Packet Sampling Interval
IPパケット遅延変動の存在下でのパケットサンプリング間隔で予想されるパケットの数= IPパケット遅延変動なしの予想パケット数パケットサンプリング間隔中に受け取ったパケットの転送遅延
Equation 3
式3
To determine if a convergence instant has been reached, the number of packets received in a Packet Sampling Interval is compared with the range of expected number of packets calculated in Equation 3.
収束瞬間に到達したかどうかを判断するために、パケットサンプリング間隔で受信したパケットの数を、式3で計算された予想パケット数の範囲と比較します。
The Rate-Derived Method SHOULD be used to measure First Route Convergence Time and Full Convergence Time. It SHOULD NOT be used to measure Loss of Connectivity Period (see Section 4).
レート由来の方法は、最初のルート収束時間と完全な収束時間を測定するために使用する必要があります。接続期間の損失を測定するために使用しないでください（セクション4を参照）。
The measurement accuracy interval of the Rate-Derived Method depends on the metric being measured or calculated and the characteristics of the related transition. IP Packet Delay Variation (IPDV) [De02] adds uncertainty to the amount of packets received in a Packet Sampling Interval, and this uncertainty adds to the measurement error. The effect of IPDV is not accounted for in the calculation of the accuracy intervals below. IPDV is of importance for the convergence instants where a variation in Forwarding Rate needs to be observed. This is applicable to the Convergence Recovery Instant for all topologies, and for topologies with ECMP it also applies to the Convergence Event Instant and the First Route Convergence Instant. and for topologies with ECMP also Convergence Event Instant and First Route Convergence Instant).
速度由来の方法の測定精度間隔は、測定または計算されるメトリックと関連する遷移の特性に依存します。IPパケット遅延バリエーション（IPDV）[DE02]は、パケットサンプリング間隔で受信したパケットの量に不確実性を追加し、この不確実性は測定誤差に追加されます。IPDVの効果は、以下の精度間隔の計算では考慮されていません。IPDVは、転送速度の変動を観察する必要がある収束の瞬間にとって重要です。これは、すべてのトポロジーの収束回復インスタントに適用され、ECMPのトポロジには、収束イベントインスタントと最初のルートコンバージェンスインスタントにも適用されます。また、ECMPを備えたトポロジの場合、コンバージェンスイベントインスタントおよび最初のルートコンバージェンスインスタント）。
If the Convergence Event Instant is observed on the data plane using the Rate Derived Method, it needs to be instantaneous for all routes (see Section 4.1). The actual value of the Convergence Event Instant falls within the accuracy interval [-(Packet Sampling Interval + 1/Offered Load), +0] around the value as measured using the Rate-Derived Method.
レート派生法を使用してデータプレーンでコンバージェンスイベントインスタントが観察される場合、すべてのルートで瞬時に行う必要があります（セクション4.1を参照）。コンバージェンスイベントの実際の値インスタントは、精度間隔[ - （パケットサンプリング間隔1/提供された負荷）、0]の周りに、レート由来の方法を使用して測定された値に該当します。
If the Convergence Recovery Transition is non-instantaneous for all routes, then the actual value of the First Route Convergence Instant falls within the accuracy interval [-(Packet Sampling Interval + time between two consecutive packets to the same destination), +0] around the value as measured using the Rate-Derived Method, and the actual value of the Convergence Recovery Instant falls within the accuracy interval [-(2 * Packet Sampling Interval), -(Packet Sampling Interval - time between two consecutive packets to the same destination)] around the value as measured using the Rate-Derived Method.
収束回復遷移がすべてのルートで非インタンタネーである場合、最初のルートコンバージェンスインスタントの実際の値が精度間隔[ - （同じ宛先への2つの連続したパケット間のパケットサンプリング間隔時間）、0]の周りにある場合、レート由来の方法と収束回復の実際の値を使用して測定された場合、インスタントは精度間隔に該当します[ - （2 *パケットサンプリング間隔）、 - （パケットサンプリング間隔 - 同じ宛先までの2つの連続したパケット間の時間）]）レート由来の方法を使用して測定された値の周り。
The term "time between two consecutive packets to the same destination" is added in the above accuracy intervals since packets are sent in a particular order to all destinations in a stream, and when part of the routes experience packet loss, it is unknown where in the transmit cycle packets to these routes are sent. This uncertainty adds to the error.
「同じ宛先への2つの連続したパケット間の時間」という用語は、パケットがストリーム内のすべての目的地に特定の順序で送信されるため、上記の精度間隔で追加され、ルートの一部がパケットの損失を経験した場合、どこでこれらのルートへの送信サイクルパケットが送信されます。この不確実性はエラーに追加されます。
The accuracy intervals of the derived metrics First Route Convergence Time and Rate-Derived Convergence Time are calculated from the above convergence instants accuracy intervals. The actual value of First Route Convergence Time falls within the accuracy interval [-(Packet Sampling Interval + time between two consecutive packets to the same destination), +(Packet Sampling Interval + 1/Offered Load)] around the calculated value. The actual value of Rate-Derived Convergence Time falls within the accuracy interval [-(2 * Packet Sampling Interval), +(time between two consecutive packets to the same destination + 1/Offered Load)] around the calculated value.
派生メトリックの精度間隔最初のルート収束時間とレート由来の収束時間は、上記の収束瞬間精度間隔から計算されます。最初のルート収束時間の実際の値は、計算値の周りの周りの精度間隔[ - （同じ宛先への2つの連続したパケット間のパケットサンプリング間隔時間）、（パケットサンプリング間隔1/提供された負荷）内に分類されます。レート由来の収束時間の実際の値は、精度間隔[ - （2 *パケットサンプリング間隔）、（同じ宛先1/提供された負荷までの2つの連続したパケットの間の時間）に計算値の周りにあります。
The Offered Load consists of multiple Streams. The Tester MUST measure Impaired Packet count for each Stream separately.
提供された負荷は、複数のストリームで構成されています。テスターは、各ストリームの障害のあるパケット数を個別に測定する必要があります。
In order to verify Full Convergence completion and the Sustained Convergence Validation Time, the Tester MUST measure Forwarding Rate each Packet Sampling Interval. This measurement at each Packet Sampling Interval MAY be per Stream.
完全な収束完了と持続的な収束検証時間を検証するには、テスターは各パケットサンプリング間隔を測定する必要があります。各パケットサンプリング間隔でのこの測定は、ストリームごとにある場合があります。
Only the total number of Impaired Packets measured per Stream at the end of the Sustained Convergence Validation Time is used to calculate the benchmark metrics with this method.
この方法でベンチマークメトリックを計算するために、持続的な収束検証時間の終了時にストリームごとに測定された障害のあるパケットの総数のみが使用されます。
The Route-Specific Loss-Derived Method SHOULD be used to measure Route-Specific Convergence Times. It is the RECOMMENDED method to measure Route Loss of Connectivity Period.
ルート固有の損失由来の方法は、ルート固有の収束時間を測定するために使用する必要があります。接続期間のルート損失を測定するための推奨方法です。
Under the conditions explained in Section 4, First Route Convergence Time and Full Convergence Time, as benchmarked using Rate-Derived Method, may be equal to the minimum and maximum (respectively) of the Route-Specific Convergence Times.
セクション4で説明されている条件下では、レート由来の方法を使用してベンチマークされているように、最初のルート収束時間と完全な収束時間は、ルート固有の収束時間の最小値と最大（それぞれ）に等しい場合があります。
The actual value falls within the accuracy interval [-(number of destinations/Offered Load), +(number of destinations/Offered Load)] around the value as measured using the Route-Specific Loss-Derived Method.
実際の値は、ルート固有の損失由来の方法を使用して測定された値の周りの精度間隔[ - （宛先の数/提供された負荷の数）、（宛先の数/提供された負荷の数）内にあります。
For each test case, it is RECOMMENDED that the reporting tables below be completed. All time values SHOULD be reported with a sufficiently high resolution (fractions of a second sufficient to distinguish significant differences between measured values).
各テストケースについて、以下のレポート表を完了することをお勧めします。十分に高解像度（測定値の有意差を区別するのに十分な2番目の分解能）で、すべての時間値を報告する必要があります。
Parameter Units
------------------------------------- ---------------------------
Test Case test case number
Test Topology Test Topology Figure number
IGP (IS-IS, OSPF, other)
Interface Type (GigE, POS, ATM, other)
Packet Size offered to DUT bytes
Offered Load packets per second
IGP Routes Advertised to DUT number of IGP routes
Nodes in Emulated Network number of nodes
Number of Parallel or ECMP links number of links
Number of Routes Measured number of routes
Packet Sampling Interval on Tester seconds
Forwarding Delay Threshold seconds
Timer Values configured on DUT:
Interface Failure Indication Delay seconds
IGP Hello Timer seconds
IGP Dead-Interval or Hold-Time seconds
LSA/LSP Generation Delay seconds
LSA/LSP Flood Packet Pacing seconds
LSA/LSP Retransmission Packet Pacing seconds
Route Calculation Delay seconds
Test Details:
テストの詳細：
Describe the IGP extensions and IGP security mechanisms that are configured on the DUT.
DUTで構成されているIGP拡張およびIGPセキュリティメカニズムについて説明します。
Describe how the various fields on the IP and contained headers for the packets for the Offered Load are generated (Section 5.6).
提供された負荷のパケットのIPおよび含まれるさまざまなフィールドがどのように生成されるかを説明します（セクション5.6）。
If the Offered Load matches a subset of routes, describe how this subset is selected.
提供された負荷がルートのサブセットと一致する場合は、このサブセットの選択方法を説明してください。
Describe how the Convergence Event is applied; does it cause instantaneous traffic loss or not?
収束イベントの適用方法を説明してください。それは瞬間的なトラフィックの損失を引き起こしますか？
The table below should be completed for the initial Convergence Event and the reversion Convergence Event.
以下の表は、初期収束イベントとリバージョン収束イベントのために完了する必要があります。
Parameter Units
------------------------------------------- ----------------------
Convergence Event (initial or reversion)
Traffic Forwarding Metrics:
Total number of packets offered to DUT number of packets
Total number of packets forwarded by DUT number of packets
Connectivity Packet Loss number of packets
Convergence Packet Loss number of packets
Out-of-Order Packets number of packets
Duplicate Packets number of packets
Excessive Forwarding Delay Packets number of packets
Convergence Benchmarks:
Rate-Derived Method:
First Route Convergence Time seconds
Full Convergence Time seconds
Loss-Derived Method:
Loss-Derived Convergence Time seconds
Route-Specific Loss-Derived Method:
Route-Specific Convergence Time[n] array of seconds
Minimum Route-Specific Convergence Time seconds
Maximum Route-Specific Convergence Time seconds
Median Route-Specific Convergence Time seconds
Average Route-Specific Convergence Time seconds
Loss of Connectivity Benchmarks: Loss-Derived Method: Loss-Derived Loss of Connectivity Period seconds Route-Specific Loss-Derived Method: Route Loss of Connectivity Period[n] array of seconds Minimum Route Loss of Connectivity Period seconds Maximum Route Loss of Connectivity Period seconds Median Route Loss of Connectivity Period seconds Average Route Loss of Connectivity Period seconds
接続性ベンチマークの損失：損失由来方法：接続の損失由来の損失期間秒ルート固有の損失由来方法：接続性のルート損失[n]秒の配列接続期間の最小ルート損失接続期間損失秒秒の中央部のルート接続期間秒秒平均ルートの接続期間秒秒
It is RECOMMENDED that all applicable test cases be performed for best characterization of the DUT. The test cases follow a generic procedure tailored to the specific DUT configuration and Convergence Event [Po11t]. This generic procedure is as follows:
DUTの最良の特性評価のために、すべての適用可能なテストケースを実行することをお勧めします。テストケースは、特定のDUT構成および収束イベント[PO11T]に合わせた一般的な手順に従います。この一般的な手順は次のとおりです。
1. Establish DUT and Tester configurations and advertise an IGP topology from Tester to DUT.
1. DUTおよびテスターの構成を確立し、テスターからDUTまでのIGPトポロジを宣伝します。
2. Send Offered Load from Tester to DUT on Ingress Interface.
2. テスターから入力インターフェイスのDUTに提供された負荷を送信します。
3. Verify traffic is routed correctly. Verify if traffic is forwarded without Impaired Packets [Po06].
3. トラフィックが正しくルーティングされていることを確認します。障害のあるパケットなしでトラフィックが転送されているかどうかを確認します[PO06]。
4. Introduce Convergence Event [Po11t].
4. コンバージェンスイベント[PO11T]を紹介します。
5. Measure First Route Convergence Time [Po11t].
5. 最初のルート収束時間[PO11T]を測定します。
6. Measure Full Convergence Time [Po11t].
6. 完全な収束時間[PO11T]を測定します。
7. Stop Offered Load.
7. 提供された負荷を停止します。
8. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period [Po11t]. At the same time, measure number of Impaired Packets [Po11t].
8. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失[PO11T]を測定します。同時に、障害のあるパケットの数を測定します[PO11T]。
9. Wait sufficient time for queues to drain. The duration of this time period MUST be larger than or equal to the Forwarding Delay Threshold.
9. キューが排水するのに十分な時間を待ちます。この期間の期間は、転送遅延しきい値以上でなければなりません。
10. Restart Offered Load.
10. 提供された負荷を再起動します。
11. Reverse Convergence Event.
11. 逆収束イベント。
12. Measure First Route Convergence Time.
12. 最初のルート収束時間を測定します。
13. Measure Full Convergence Time.
13. 完全な収束時間を測定します。
14. Stop Offered Load.
14. 提供された負荷を停止します。
15. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets [Po11t].
15. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します[PO11T]。
Objective:
目的：
To obtain the IGP convergence measurements for Local Interface failure and recovery events. The Next-Best Egress Interface can be a single interface (Figure 1) or an ECMP set (Figure 2). The test with ECMP topology (Figure 2) is OPTIONAL.
ローカルインターフェイスの故障および回復イベントのIGP収束測定を取得します。次のベスト出力インターフェイスは、単一のインターフェイス（図1）またはECMPセット（図2）です。ECMPトポロジ（図2）を使用したテストはオプションです。
Procedure:
手順：
1. Advertise an IGP topology from Tester to DUT using the topology shown in Figures 1 or 2.
1. 図1または2に示すトポロジを使用して、テスターからDUTへのIGPトポロジを宣伝します。
2. Send Offered Load from Tester to DUT on Ingress Interface.
2. テスターから入力インターフェイスのDUTに提供された負荷を送信します。
3. Verify traffic is forwarded over Preferred Egress Interface.
3. トラフィックが優先された出力インターフェイスを介して転送されることを確認します。
4. Remove link on the Preferred Egress Interface of the DUT. This is the Convergence Event.
4. DUTの好ましい出口インターフェイスのリンクを削除します。これは収束イベントです。
5. Measure First Route Convergence Time.
5. 最初のルート収束時間を測定します。
6. Measure Full Convergence Time.
6. 完全な収束時間を測定します。
7. Stop Offered Load.
7. 提供された負荷を停止します。
8. Measure Route-Specific Convergence Times and Loss-Derived Convergence Time. At the same time, measure number of Impaired Packets.
8. ルート固有の収束時間と損失由来の収束時間を測定します。同時に、障害のあるパケットの数を測定します。
9. Wait sufficient time for queues to drain.
9. キューが排水するのに十分な時間を待ちます。
10. Restart Offered Load.
10. 提供された負荷を再起動します。
11. Restore link on the Preferred Egress Interface of the DUT.
11. DUTの優先出力インターフェイスにリンクを復元します。
12. Measure First Route Convergence Time.
12. 最初のルート収束時間を測定します。
13. Measure Full Convergence Time.
13. 完全な収束時間を測定します。
14. Stop Offered Load.
14. 提供された負荷を停止します。
15. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
15. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
Objective:
目的：
To obtain the IGP convergence measurements for Remote Interface failure and recovery events. The Next-Best Egress Interface can be a single interface (Figure 3) or an ECMP set (Figure 4). The test with ECMP topology (Figure 4) is OPTIONAL.
リモートインターフェイスの故障および回復イベントのIGP収束測定を取得します。次のベスト出力インターフェイスは、単一のインターフェイス（図3）またはECMPセット（図4）です。ECMPトポロジ（図4）を使用したテストはオプションです。
Procedure:
手順：
1. Advertise an IGP topology from Tester to SUT using the topology shown in Figures 3 or 4.
1. 図3または4に示すトポロジを使用して、テスターからSUTへのIGPトポロジを宣伝します。
2. Send Offered Load from Tester to SUT on Ingress Interface.
2. イングレスインターフェイス上のテスターからSUTに提供された負荷を送信します。
3. Verify traffic is forwarded over Preferred Egress Interface.
3. トラフィックが優先された出力インターフェイスを介して転送されることを確認します。
4. Remove link on the interface of the Tester connected to the Preferred Egress Interface of the SUT. This is the Convergence Event.
4. SUTの好ましい出口インターフェイスに接続されたテスターのインターフェイスのリンクを削除します。これは収束イベントです。
5. Measure First Route Convergence Time.
5. 最初のルート収束時間を測定します。
6. Measure Full Convergence Time.
6. 完全な収束時間を測定します。
7. Stop Offered Load.
7. 提供された負荷を停止します。
8. Measure Route-Specific Convergence Times and Loss-Derived Convergence Time. At the same time, measure number of Impaired Packets.
8. ルート固有の収束時間と損失由来の収束時間を測定します。同時に、障害のあるパケットの数を測定します。
9. Wait sufficient time for queues to drain.
9. キューが排水するのに十分な時間を待ちます。
10. Restart Offered Load.
10. 提供された負荷を再起動します。
11. Restore link on the interface of the Tester connected to the Preferred Egress Interface of the SUT.
11. SUTの好ましい出口インターフェイスに接続されたテスターのインターフェイスにリンクを復元します。
12. Measure First Route Convergence Time.
12. 最初のルート収束時間を測定します。
13. Measure Full Convergence Time.
13. 完全な収束時間を測定します。
14. Stop Offered Load.
14. 提供された負荷を停止します。
15. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
15. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
Discussion:
討論：
In this test case, there is a possibility of a packet-forwarding loop that may occur transiently between DUT1 and DUT2 during convergence (micro-loop, see [Sh10]), which may increase the measured convergence times and loss of connectivity periods.
このテストケースでは、収束中にDUT1とDUT2の間で一時的に発生する可能性のあるパケットフォワードループの可能性があります（マイクロループ、[SH10]を参照）。
8.1.3. Convergence Due to ECMP Member Local Interface Failure and Recovery
8.1.3. ECMPメンバーによる収束ローカルインターフェイスの故障と回復
Objective:
目的：
To obtain the IGP convergence measurements for Local Interface link failure and recovery events of an ECMP Member.
ECMPメンバーのローカルインターフェイスリンク障害および回復イベントのIGP収束測定を取得します。
Procedure:
手順：
1. Advertise an IGP topology from Tester to DUT using the test setup shown in Figure 5.
1. 図5に示すテストセットアップを使用して、テスターからDUTへのIGPトポロジを宣伝します。
2. Send Offered Load from Tester to DUT on Ingress Interface.
2. テスターから入力インターフェイスのDUTに提供された負荷を送信します。
3. Verify traffic is forwarded over the ECMP member interface of the DUT that will be failed in the next step.
3. 次のステップで失敗するDUTのECMPメンバーインターフェースにトラフィックが転送されることを確認します。
4. Remove link on one of the ECMP member interfaces of the DUT. This is the Convergence Event.
4. DUTのECMPメンバーインターフェイスの1つでリンクを削除します。これは収束イベントです。
5. Measure First Route Convergence Time.
5. 最初のルート収束時間を測定します。
6. Measure Full Convergence Time.
6. 完全な収束時間を測定します。
7. Stop Offered Load.
7. 提供された負荷を停止します。
8. Measure Route-Specific Convergence Times and Loss-Derived Convergence Time. At the same time, measure number of Impaired Packets.
8. ルート固有の収束時間と損失由来の収束時間を測定します。同時に、障害のあるパケットの数を測定します。
9. Wait sufficient time for queues to drain.
9. キューが排水するのに十分な時間を待ちます。
10. Restart Offered Load.
10. 提供された負荷を再起動します。
11. Restore link on the ECMP member interface of the DUT.
11. DUTのECMPメンバーインターフェイスにリンクを復元します。
12. Measure First Route Convergence Time.
12. 最初のルート収束時間を測定します。
13. Measure Full Convergence Time.
13. 完全な収束時間を測定します。
14. Stop Offered Load.
14. 提供された負荷を停止します。
15. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
15. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
8.1.4. Convergence Due to ECMP Member Remote Interface Failure and Recovery
8.1.4. ECMPメンバーのリモートインターフェイスの故障と回復による収束
Objective:
目的：
To obtain the IGP convergence measurements for Remote Interface link failure and recovery events for an ECMP Member.
ECMPメンバーのリモートインターフェイスリンク障害および回復イベントのIGP収束測定を取得します。
Procedure:
手順：
1. Advertise an IGP topology from Tester to DUT using the test setup shown in Figure 6.
1. 図6に示すテストセットアップを使用して、テスターからDUTへのIGPトポロジを宣伝します。
2. Send Offered Load from Tester to DUT on Ingress Interface.
2. テスターから入力インターフェイスのDUTに提供された負荷を送信します。
3. Verify traffic is forwarded over the ECMP member interface of the DUT that will be failed in the next step.
3. 次のステップで失敗するDUTのECMPメンバーインターフェースにトラフィックが転送されることを確認します。
4. Remove link on the interface of the Tester to R2. This is the Convergence Event Trigger.
4. テスターのインターフェイスのリンクをR2に削除します。これは、収束イベントトリガーです。
5. Measure First Route Convergence Time.
5. 最初のルート収束時間を測定します。
6. Measure Full Convergence Time.
6. 完全な収束時間を測定します。
7. Stop Offered Load.
7. 提供された負荷を停止します。
8. Measure Route-Specific Convergence Times and Loss-Derived Convergence Time. At the same time, measure number of Impaired Packets.
8. ルート固有の収束時間と損失由来の収束時間を測定します。同時に、障害のあるパケットの数を測定します。
9. Wait sufficient time for queues to drain.
9. キューが排水するのに十分な時間を待ちます。
10. Restart Offered Load.
10. 提供された負荷を再起動します。
11. Restore link on the interface of the Tester to R2.
11. R2へのテスターのインターフェイスのリンクを復元します。
12. Measure First Route Convergence Time.
12. 最初のルート収束時間を測定します。
13. Measure Full Convergence Time.
13. 完全な収束時間を測定します。
14. Stop Offered Load.
14. 提供された負荷を停止します。
15. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
15. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
Discussion:
討論：
In this test case, there is a possibility of a packet-forwarding loop that may occur temporarily between DUT1 and DUT2 during convergence (micro-loop, see [Sh10]), which may increase the measured convergence times and loss of connectivity periods.
このテストのケースでは、収束中にDUT1とDUT2の間に一時的に発生する可能性のあるパケットを使用するループ（マイクロループ、[SH10]を参照）の可能性があります。
Objective:
目的：
To obtain the IGP convergence measurements for local link failure and recovery events for a member of a parallel link. The links can be used for data load-balancing
並列リンクのメンバーのローカルリンク障害および回復イベントのIGP収束測定を取得します。リンクは、データの負荷バランスに使用できます
Procedure:
手順：
1. Advertise an IGP topology from Tester to DUT using the test setup shown in Figure 7.
1. 図7に示すテストセットアップを使用して、テスターからDUTへのIGPトポロジを宣伝します。
2. Send Offered Load from Tester to DUT on Ingress Interface.
2. テスターから入力インターフェイスのDUTに提供された負荷を送信します。
3. Verify traffic is forwarded over the parallel link member that will be failed in the next step.
3. 次のステップで失敗するパラレルリンクメンバーにトラフィックが転送されることを確認します。
4. Remove link on one of the parallel link member interfaces of the DUT. This is the Convergence Event.
4. DUTの並列リンクメンバーインターフェイスの1つでリンクを削除します。これは収束イベントです。
5. Measure First Route Convergence Time.
5. 最初のルート収束時間を測定します。
6. Measure Full Convergence Time.
6. 完全な収束時間を測定します。
7. Stop Offered Load.
7. 提供された負荷を停止します。
8. Measure Route-Specific Convergence Times and Loss-Derived Convergence Time. At the same time, measure number of Impaired Packets.
8. ルート固有の収束時間と損失由来の収束時間を測定します。同時に、障害のあるパケットの数を測定します。
9. Wait sufficient time for queues to drain.
9. キューが排水するのに十分な時間を待ちます。
10. Restart Offered Load.
10. 提供された負荷を再起動します。
11. Restore link on the Parallel Link member interface of the DUT.
11. DUTの並列リンクメンバーインターフェイスにリンクを復元します。
12. Measure First Route Convergence Time.
12. 最初のルート収束時間を測定します。
13. Measure Full Convergence Time.
13. 完全な収束時間を測定します。
14. Stop Offered Load.
14. 提供された負荷を停止します。
15. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
15. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
Objective:
目的：
To obtain the IGP convergence measurements for a local Layer 2 loss and recovery.
ローカルレイヤー2の損失と回復のIGP収束測定を取得します。
Procedure:
手順：
1. Advertise an IGP topology from Tester to DUT using the topology shown in Figure 1.
1. 図1に示すトポロジを使用して、テスターからDUTへのIGPトポロジを宣伝します。
2. Send Offered Load from Tester to DUT on Ingress Interface.
2. テスターから入力インターフェイスのDUTに提供された負荷を送信します。
3. Verify traffic is routed over Preferred Egress Interface.
3. トラフィックが優先された出力インターフェイスを介してルーティングされていることを確認します。
4. Remove Layer 2 session from Preferred Egress Interface of the DUT. This is the Convergence Event.
4. DUTの優先出力インターフェースからレイヤー2セッションを削除します。これは収束イベントです。
5. Measure First Route Convergence Time.
5. 最初のルート収束時間を測定します。
6. Measure Full Convergence Time.
6. 完全な収束時間を測定します。
7. Stop Offered Load.
7. 提供された負荷を停止します。
8. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
8. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
9. Wait sufficient time for queues to drain.
9. キューが排水するのに十分な時間を待ちます。
10. Restart Offered Load.
10. 提供された負荷を再起動します。
11. Restore Layer 2 session on Preferred Egress Interface of the DUT.
11. DUTの優先出力インターフェイスに関するレイヤー2セッションを復元します。
12. Measure First Route Convergence Time.
12. 最初のルート収束時間を測定します。
13. Measure Full Convergence Time.
13. 完全な収束時間を測定します。
14. Stop Offered Load.
14. 提供された負荷を停止します。
15. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
15. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
Discussion:
討論：
When removing the Layer 2 session, the physical layer must stay up. Configure IGP timers such that the IGP adjacency does not time out before Layer 2 failure is detected.
レイヤー2セッションを削除するときは、物理レイヤーが上昇する必要があります。Layer 2の障害が検出される前にIGP隣接がタイムアウトしないようにIGPタイマーを構成します。
To measure convergence time, traffic SHOULD start dropping on the Preferred Egress Interface on the instant the Layer 2 session is removed. Alternatively, the Tester SHOULD record the time the instant Layer 2 session is removed, and traffic loss SHOULD only be measured on the Next-Best Egress Interface. For loss-derived benchmarks, the time of the Start Traffic Instant SHOULD be recorded as well. See Section 4.1.
収束時間を測定するには、レイヤー2セッションが削除された瞬間に、優先出力インターフェイスのトラフィックが削除され始めます。あるいは、テスターは、インスタントレイヤー2セッションが削除される時間を記録する必要があり、トラフィックの損失は次のベスト出力インターフェイスでのみ測定する必要があります。損失由来のベンチマークの場合、開始トラフィックインスタントの時間も記録する必要があります。セクション4.1を参照してください。
Objective:
目的：
To obtain the IGP convergence measurements for loss and recovery of an IGP Adjacency. The IGP adjacency is removed on the Tester by disabling processing of IGP routing protocol packets on the Tester.
IGP隣接の損失と回復のためのIGP収束測定を取得します。IGP隣接は、テスター上のIGPルーティングプロトコルパケットの処理を無効にすることにより、テスターで削除されます。
Procedure:
手順：
1. Advertise an IGP topology from Tester to DUT using the topology shown in Figure 1.
1. 図1に示すトポロジを使用して、テスターからDUTへのIGPトポロジを宣伝します。
2. Send Offered Load from Tester to DUT on Ingress Interface.
2. テスターから入力インターフェイスのDUTに提供された負荷を送信します。
3. Verify traffic is routed over Preferred Egress Interface.
3. トラフィックが優先された出力インターフェイスを介してルーティングされていることを確認します。
4. Remove IGP adjacency from the Preferred Egress Interface while the Layer 2 session MUST be maintained. This is the Convergence Event.
4. Layer 2セッションを維持する必要がある間に、優先EugressインターフェイスからIGPの隣接性を削除します。これは収束イベントです。
5. Measure First Route Convergence Time.
5. 最初のルート収束時間を測定します。
6. Measure Full Convergence Time.
6. 完全な収束時間を測定します。
7. Stop Offered Load.
7. 提供された負荷を停止します。
8. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
8. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
9. Wait sufficient time for queues to drain.
9. キューが排水するのに十分な時間を待ちます。
10. Restart Offered Load.
10. 提供された負荷を再起動します。
11. Restore IGP session on Preferred Egress Interface of the DUT.
11. DUTの優先出力インターフェースでIGPセッションを復元します。
12. Measure First Route Convergence Time.
12. 最初のルート収束時間を測定します。
13. Measure Full Convergence Time.
13. 完全な収束時間を測定します。
14. Stop Offered Load.
14. 提供された負荷を停止します。
15. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
15. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
Discussion:
討論：
Configure Layer 2 such that Layer 2 does not time out before IGP adjacency failure is detected.
IGP隣接障害が検出される前にレイヤー2がタイムアウトしないようにレイヤー2を構成します。
To measure convergence time, traffic SHOULD start dropping on the Preferred Egress Interface on the instant the IGP adjacency is removed. Alternatively, the Tester SHOULD record the time the instant the IGP adjacency is removed and traffic loss SHOULD only be measured on the Next-Best Egress Interface. For loss-derived benchmarks, the time of the Start Traffic Instant SHOULD be recorded as well. See Section 4.1.
収束時間を測定するには、IGPの隣接能力が削除された瞬間に、優先出力インターフェイスのトラフィックが低下し始めるはずです。あるいは、IGP隣接が削除され、トラフィックの損失を次の最高の出口インターフェイスでのみ測定する必要がある瞬間に、テスターは記録する必要があります。損失由来のベンチマークの場合、開始トラフィックインスタントの時間も記録する必要があります。セクション4.1を参照してください。
Objective:
目的：
To obtain the IGP convergence measurements for route withdrawal and re-advertisement.
ルートの引き出しと再承認のためのIGP収束測定を取得します。
Procedure:
手順：
1. Advertise an IGP topology from Tester to DUT using the topology shown in Figure 1. The routes that will be withdrawn MUST be a set of leaf routes advertised by at least two nodes in the emulated topology. The topology SHOULD be such that before the withdrawal the DUT prefers the leaf routes advertised by a node "nodeA" via the Preferred Egress Interface, and after the withdrawal the DUT prefers the leaf routes advertised by a node "nodeB" via the Next-Best Egress Interface.
1. 図1に示すトポロジーを使用して、テスターからDUTへのIGPトポロジを宣伝します。撤回されるルートは、エミュレートトポロジーの少なくとも2つのノードによって宣伝される葉のルートのセットでなければなりません。トポロジーは、撤退する前に、DUTは、優先出力インターフェイスを介してノード「ノードア」によって宣伝されている葉のルートを好むようなものでなければならず、撤退後、DUTは次のベスト経由でノード「ノード」によって宣伝されているリーフルートを好むようにする必要があります出力インターフェイス。
2. Send Offered Load from Tester to DUT on Ingress Interface.
2. テスターから入力インターフェイスのDUTに提供された負荷を送信します。
3. Verify traffic is routed over Preferred Egress Interface.
3. トラフィックが優先された出力インターフェイスを介してルーティングされていることを確認します。
4. The Tester withdraws the set of IGP leaf routes from nodeA. This is the Convergence Event. The withdrawal update message SHOULD be a single unfragmented packet. If the routes cannot be withdrawn by a single packet, the messages SHOULD be sent using the same pacing characteristics as the DUT. The Tester MAY record the time it sends the withdrawal message(s).
4. テスターは、NodeaからIGPリーフルートのセットを引き出します。これは収束イベントです。撤回更新メッセージは、単一のフレーミングされていないパケットである必要があります。ルートを単一のパケットで撤回できない場合、メッセージはDUTと同じペーシング特性を使用して送信する必要があります。テスターは、引き出しメッセージを送信する時間を記録する場合があります。
5. Measure First Route Convergence Time.
5. 最初のルート収束時間を測定します。
6. Measure Full Convergence Time.
6. 完全な収束時間を測定します。
7. Stop Offered Load.
7. 提供された負荷を停止します。
8. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
8. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
9. Wait sufficient time for queues to drain.
9. キューが排水するのに十分な時間を待ちます。
10. Restart Offered Load.
10. 提供された負荷を再起動します。
11. Re-advertise the set of withdrawn IGP leaf routes from nodeA emulated by the Tester. The update message SHOULD be a single unfragmented packet. If the routes cannot be advertised by a single packet, the messages SHOULD be sent using the same pacing characteristics as the DUT. The Tester MAY record the time it sends the update message(s).
11. テスターによってエミュレートされたノードアから引き出されたIGPリーフルートのセットを再承認します。更新メッセージは、単一のフレーミングされていないパケットである必要があります。ルートを単一のパケットで宣伝できない場合、メッセージはDUTと同じペーシング特性を使用して送信する必要があります。テスターは、更新メッセージを送信する時間を記録できます。
12. Measure First Route Convergence Time.
12. 最初のルート収束時間を測定します。
13. Measure Full Convergence Time.
13. 完全な収束時間を測定します。
14. Stop Offered Load.
14. 提供された負荷を停止します。
15. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
15. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
Discussion:
討論：
To measure convergence time, traffic SHOULD start dropping on the Preferred Egress Interface on the instant the routes are withdrawn by the Tester. Alternatively, the Tester SHOULD record the time the instant the routes are withdrawn, and traffic loss SHOULD only be measured on the Next-Best Egress Interface. For loss-derived benchmarks, the time of the Start Traffic Instant SHOULD be recorded as well. See Section 4.1.
収束時間を測定するために、トラフィックは、テスターによってルートが撤回される瞬間に優先された出口インターフェイスのドロップを開始する必要があります。あるいは、テスターは、ルートが撤回される瞬間に時間を記録する必要があり、トラフィックの損失は次の最高の出力インターフェイスでのみ測定する必要があります。損失由来のベンチマークの場合、開始トラフィックインスタントの時間も記録する必要があります。セクション4.1を参照してください。
Objective:
目的：
To obtain the IGP convergence measurements for administratively disabling and enabling a Local Interface.
ローカルインターフェイスを管理上無効にして有効にするためのIGP収束測定を取得します。
Procedure:
手順：
1. Advertise an IGP topology from Tester to DUT using the topology shown in Figure 1.
1. 図1に示すトポロジを使用して、テスターからDUTへのIGPトポロジを宣伝します。
2. Send Offered Load from Tester to DUT on Ingress Interface.
2. テスターから入力インターフェイスのDUTに提供された負荷を送信します。
3. Verify traffic is routed over Preferred Egress Interface.
3. トラフィックが優先された出力インターフェイスを介してルーティングされていることを確認します。
4. Administratively disable the Preferred Egress Interface of the DUT. This is the Convergence Event.
4. DUTの優先出力インターフェイスを管理上無効にします。これは収束イベントです。
5. Measure First Route Convergence Time.
5. 最初のルート収束時間を測定します。
6. Measure Full Convergence Time.
6. 完全な収束時間を測定します。
7. Stop Offered Load.
7. 提供された負荷を停止します。
8. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
8. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
9. Wait sufficient time for queues to drain.
9. キューが排水するのに十分な時間を待ちます。
10. Restart Offered Load.
10. 提供された負荷を再起動します。
11. Administratively enable the Preferred Egress Interface of the DUT.
11. DUTの優先出力インターフェイスを管理上有効にします。
12. Measure First Route Convergence Time.
12. 最初のルート収束時間を測定します。
13. Measure Full Convergence Time.
13. 完全な収束時間を測定します。
14. Stop Offered Load.
14. 提供された負荷を停止します。
15. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
15. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
Objective:
目的：
To obtain the IGP convergence measurements for route cost change.
ルートコストの変更のためのIGP収束測定値を取得します。
Procedure:
手順：
1. Advertise an IGP topology from Tester to DUT using the topology shown in Figure 1.
1. 図1に示すトポロジを使用して、テスターからDUTへのIGPトポロジを宣伝します。
2. Send Offered Load from Tester to DUT on Ingress Interface.
2. テスターから入力インターフェイスのDUTに提供された負荷を送信します。
3. Verify traffic is routed over Preferred Egress Interface.
3. トラフィックが優先された出力インターフェイスを介してルーティングされていることを確認します。
4. The Tester, emulating the neighbor node, increases the cost for all IGP routes at the Preferred Egress Interface of the DUT so that the Next-Best Egress Interface becomes the preferred path. The update message advertising the higher cost MUST be a single unfragmented packet. This is the Convergence Event. The Tester MAY record the time it sends the update message advertising the higher cost on the Preferred Egress Interface.
4. 隣接ノードをエミュレートするテスターは、DUTの優先出力インターフェイスですべてのIGPルートのコストを増加させ、次のベストエグレスインターフェイスが優先パスになるようにします。高いコストを宣伝する更新メッセージは、単一のフラグメントされていないパケットでなければなりません。これは収束イベントです。テスターは、希望する出力インターフェイスで高いコストを宣伝する更新メッセージを送信する時間を記録する場合があります。
5. Measure First Route Convergence Time.
5. 最初のルート収束時間を測定します。
6. Measure Full Convergence Time.
6. 完全な収束時間を測定します。
7. Stop Offered Load.
7. 提供された負荷を停止します。
8. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
8. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
9. Wait sufficient time for queues to drain.
9. キューが排水するのに十分な時間を待ちます。
10. Restart Offered Load.
10. 提供された負荷を再起動します。
11. The Tester, emulating the neighbor node, decreases the cost for all IGP routes at the Preferred Egress Interface of the DUT so that the Preferred Egress Interface becomes the preferred path. The update message advertising the lower cost MUST be a single unfragmented packet.
11. 隣接ノードをエミュレートするテスターは、DUTの優先出力インターフェイスですべてのIGPルートのコストを削減し、優先出力インターフェイスが優先パスになるようにします。低いコストを宣伝する更新メッセージは、単一のフラグメントされていないパケットでなければなりません。
12. Measure First Route Convergence Time.
12. 最初のルート収束時間を測定します。
13. Measure Full Convergence Time.
13. 完全な収束時間を測定します。
14. Stop Offered Load.
14. 提供された負荷を停止します。
15. Measure Route-Specific Convergence Times, Loss-Derived Convergence Time, Route Loss of Connectivity Periods, and Loss-Derived Loss of Connectivity Period. At the same time, measure number of Impaired Packets.
15. ルート固有の収束時間、損失由来の収束時間、接続期間のルート損失、および接続期間の損失由来の損失を測定します。同時に、障害のあるパケットの数を測定します。
Discussion:
討論：
To measure convergence time, traffic SHOULD start dropping on the Preferred Egress Interface on the instant the cost is changed by the Tester. Alternatively, the Tester SHOULD record the time the instant the cost is changed, and traffic loss SHOULD only be measured on the Next-Best Egress Interface. For loss-derived benchmarks, the time of the Start Traffic Instant SHOULD be recorded as well. See Section 4.1.
収束時間を測定するには、テスターによってコストが変更される瞬間に、優先排出型インターフェイスのトラフィックが低下し始めるはずです。あるいは、テスターは、コストが変更される瞬間に時間を記録する必要があり、トラフィックの損失は次のベストエグレスインターフェイスでのみ測定する必要があります。損失由来のベンチマークの場合、開始トラフィックインスタントの時間も記録する必要があります。セクション4.1を参照してください。
Benchmarking activities as described in this memo are limited to technology characterization using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above.
このメモに記載されているベンチマークアクティビティは、実験室環境で制御された刺激を使用した技術特性評価に限定されており、上記のセクションで指定されている専用のアドレス空間と制約があります。
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network.
ベンチマークネットワークトポロジは、独立したテストセットアップとなり、テストトラフィックを生産ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤って転送したりするデバイスに接続してはなりません。
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT/SUT.
さらに、ベンチマークは「ブラックボックス」ベースで実行され、DUT/SUTの外部に観察可能な測定のみに依存しています。
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
特別な能力は、ベンチマークの目的で特別にDUT/SUTに存在するべきではありません。DUT/SUTから生じるネットワークセキュリティへの影響は、ラボと生産ネットワークで同一である必要があります。
Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward, Peter De Vriendt, Anuj Dewagan, Julien Meuric, Adrian Farrel, Stewart Bryant, and the Benchmarking Methodology Working Group for their contributions to this work.
Sue Hares、Al Morton、Kevin Dubray、Ron Bonica、David Ward、Peter de Vriendt、Anuj Dewagan、Julien Meuric、Adrian Farrel、Stewart Bryant、およびこの作業への寄付については、ベンチマーク方法ワーキンググループに感謝します。
[Br91] Bradner, S., "Benchmarking terminology for network interconnection devices", RFC 1242, July 1991.
[BR91] Bradner、S。、「ネットワーク相互接続デバイスのベンチマーク用語」、RFC 1242、1991年7月。
[Br97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BR97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[BR99] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク方法論」、RFC 2544、1999年3月。
[Ca90] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[CA90] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[Co08] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[Co08] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、2008年7月。
[De02] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[De02] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリック（IPPM）のIPパケット遅延変動メトリック」、RFC 3393、2002年11月。
[Ho08] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
[HO08] Hopps、C。、「IS-ISでIPv6をルーティング」、RFC 5308、2008年10月。
[Ko02] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample Metrics", RFC 3357, August 2002.
[KO02] Koodli、R。およびR. Ravikanth、「一元配置パターンサンプルメトリック」、RFC 3357、2002年8月。
[Ma05] Manral, V., White, R., and A. Shaikh, "Benchmarking Basic OSPF Single Router Control Plane Convergence", RFC 4061, April 2005.
[MA05] Manral、V.、White、R。、およびA. Shaikh、「基本的なOSPFシングルルーター制御平面収束」、RFC 4061、2005年4月。
[Ma05c] Manral, V., White, R., and A. Shaikh, "Considerations When Using Basic OSPF Convergence Benchmarks", RFC 4063, April 2005.
[MA05C] Manral、V.、White、R。、およびA. Shaikh、「基本的なOSPF収束ベンチマークを使用する場合の考慮事項」、RFC 4063、2005年4月。
[Ma05t] Manral, V., White, R., and A. Shaikh, "OSPF Benchmarking Terminology and Concepts", RFC 4062, April 2005.
[MA05T] Manral、V.、White、R。、およびA. Shaikh、「OSPFベンチマーク用語と概念」、RFC 4062、2005年4月。
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[MA98] Mandeville、R。、「LANスイッチングデバイスのベンチマーク用語」、RFC 2285、1998年2月。
[Mo98] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[MO98] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[Ne07] Newman, D. and T. Player, "Hash and Stuffing: Overlooked Factors in Network Device Benchmarking", RFC 4814, March 2007.
[NE07] Newman、D。およびT. Player、「ハッシュと詰め物：ネットワークデバイスベンチマークにおける見落とされた要因」、RFC 4814、2007年3月。
[Pa05] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[PA05] Pan、P.、Swallow、G。、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速再配置」、RFC 4090、2005年5月。
[Po06] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, "Terminology for Benchmarking Network-layer Traffic Control Mechanisms", RFC 4689, October 2006.
[PO06] Poretsky、S.、Perser、J.、Erramilli、S。、およびS. Khurana、「ネットワーク層トラフィック制御メカニズムのベンチマークの用語」、RFC 4689、2006年10月。
[Po11t] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence", RFC 6412, November 2011.
[PO11T] Poretsky、S.、Imhoff、B。、およびK. Michielsen、「リンク状態のIGPデータプレーンルート収束のベンチマークの用語」、RFC 6412、2011年11月。
[Sh10] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, January 2010.
[SH10] Shand、M。およびS. Bryant、「ループフリーコンバージェンスのフレームワーク」、RFC 5715、2010年1月。
[Sh10i] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.
[Sh10i] Shand、M。and S. Bryant、「IP Fast Reroute Framework」、RFC 5714、2010年1月。
[Th00] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[Th00] Thaler、D。およびC. Hopps、「UnicastおよびMulticast Next-Hop Selectionのマルチパスの問題」、RFC 2991、2000年11月。
[Al00] Alaettinoglu, C., Jacobson, V., and H. Yu, "Towards Millisecond IGP Convergence", NANOG 20, October 2000.
[AL00] Alaettinoglu、C.、Jacobson、V。、およびH. Yu、「Millisecond Igp Convergence」、Nanog 20、2000年10月。
[Al02] Alaettinoglu, C. and S. Casner, "ISIS Routing on the Qwest Backbone: a Recipe for Subsecond ISIS Convergence", NANOG 24, February 2002.
[AL02] Alaettinoglu、C。およびS. Casner、「QWESTバックボーン上のISISルーティング：サブセクションISIS収束のレシピ」、Nanog 24、2002年2月。
[Fi02] Filsfils, C., "Tutorial: Deploying Tight-SLA Services on an Internet Backbone: ISIS Fast Convergence and Differentiated Services Design", NANOG 25, June 2002.
[FI02] FilsFils、C。、「チュートリアル：インターネットバックボーンにタイトSLAサービスの展開：ISIS高速収束と差別化されたサービス設計」、Nanog 25、2002年6月。
[Fr05] Francois, P., Filsfils, C., Evans, J., and O. Bonaventure, "Achieving SubSecond IGP Convergence in Large IP Networks", ACM SIGCOMM Computer Communication Review v.35 n.3, July 2005.
[FR05] Francois、P.、Filsfils、C.、Evans、J。、およびO. Bonventure、「大規模なIPネットワークでのサブセクションIGP収束の達成」、ACM Sigcomm Computer Communication Review v.35 N.3、2005年7月。
[Ka02] Katz, D., "Why are we scared of SPF? IGP Scaling and Stability", NANOG 25, June 2002.
[Ka02] Katz、D。、「なぜSPF？IGPのスケーリングと安定性が怖い」、Nanog 25、2002年6月。
[Vi02] Villamizar, C., "Convergence and Restoration Techniques for ISP Interior Routing", NANOG 25, June 2002.
[VI02] Villamizar、C。、「ISPインテリアルーティングの収束と修復技術」、Nanog 25、2002年6月。
Authors' Addresses
著者のアドレス
Scott Poretsky Allot Communications 300 TradeCenter Woburn, MA 01801 USA
Scott Poretsky Allot Communications 300 Tradecenter Woburn、MA 01801 USA
Phone: + 1 508 309 2179
EMail: sporetsky@allot.com
Brent Imhoff Juniper Networks 1194 North Mathilda Ave Sunnyvale, CA 94089 USA
Brent Imhoff Juniper Networks 1194 North Mathilda Ave Sunnyvale、CA 94089 USA
Phone: + 1 314 378 2571
EMail: bimhoff@planetspork.com
Kris Michielsen Cisco Systems 6A De Kleetlaan Diegem, BRABANT 1831 Belgium
クリス・ミシエルセン・シスコ・システム6A de Kleetlaan Diegem、Brabant 1831 Belgium
EMail: kmichiel@cisco.com