[要約] RFC 6894は、MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protectionのベンチマーク手法を提供しています。このRFCの目的は、MPLS-TE Fast Reroute保護の性能評価を標準化し、ネットワークの信頼性と可用性を向上させることです。
Internet Engineering Task Force (IETF) R. Papneja
Request for Comments: 6894 Huawei Technologies
Category: Informational S. Vapiwala
ISSN: 2070-1721 J. Karthik
Cisco Systems
S. Poretsky
Allot Communications
S. Rao
Qwest Communications
JL. Le Roux
France Telecom
March 2013
Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection
MPLSトラフィックエンジニアリング（MPLS-TE）高速リルート保護のベンチマーク手法
Abstract
概要
This document describes the methodology for benchmarking MPLS Fast Reroute (FRR) protection mechanisms for link and node protection. This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS Traffic Engineered (MPLS-TE) tunnels.
このドキュメントでは、リンクとノードの保護のためにMPLS Fast Reroute（FRR）保護メカニズムをベンチマークする方法について説明します。このドキュメントでは、MPLSトラフィックエンジニアリング（MPLS-TE）トンネルにバインドされたリアルタイムアプリケーションのリカバリ時間に影響を与える可能性のある要素（基礎となるリンクなど）を考慮しながら、高速リルート技術のフェイルオーバー時間を測定するためのテスト方法とテストベッドのセットアップについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6894.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6894で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
2. Document Scope ..................................................5
3. Existing Definitions and Requirements ...........................5
4. General Reference Topology ......................................6
5. Test Considerations .............................................7
5.1. Failover Events ............................................7
5.2. Failure Detection ..........................................8
5.3. Use of Data Traffic for MPLS Protection Benchmarking .......8
5.4. LSP and Route Scaling ......................................9
5.5. Selection of IGP ...........................................9
5.6. Restoration and Reversion ..................................9
5.7. Offered Load ...............................................9
5.8. Tester Capabilities .......................................10
5.9. Failover Time Measurement Methods .........................10
6. Reference Test Setup ...........................................11
6.1. Link Protection ...........................................12
6.1.1. Link Protection: 1-Hop Primary (from PLR)
and 1-Hop Backup Tail-End Tunnels ..................12
6.1.2. Link Protection: 1-Hop Primary (from PLR)
and 2-Hop Backup Tail-End Tunnels ..................13
6.1.3. Link Protection: 2-Hop (or More) Primary (from PLR)
and 1-Hop Backup Tail-End Tunnels ..................14
6.1.4. Link Protection: 2-Hop (or More) Primary (from PLR)
and 2-Hop Backup Tail-End Tunnels ..................15
6.2. Node Protection ...........................................16
6.2.1. Node Protection: 2-Hop Primary (from PLR)
and 1-Hop Backup Tail-End Tunnels ..................16
6.2.2. Node Protection: 2-Hop Primary (from PLR)
and 2-Hop Backup Tail-End Tunnels ..................17
6.2.3. Node Protection: 3-Hop (or More) Primary (from PLR)
and 1-Hop Backup Tail-End Tunnels ..................18
6.2.4. Node Protection: 3-Hop (or More) Primary (from PLR)
and 2-Hop Backup Tail-End Tunnels ..................19
7. Test Methodology ...............................................19
7.1. MPLS-FRR Forwarding Performance ...........................20
7.1.1. Head-End PLR Forwarding Performance ................20
7.1.2. Midpoint PLR Forwarding Performance ................21
7.2. Head-End PLR with Link Failure ............................22
7.3. Midpoint PLR with Link Failure ............................24
7.4. Head-End PLR with Node Failure ............................25
7.5. Midpoint PLR with Node Failure ............................26
8. Reporting Format ...............................................27
9. Security Considerations ........................................29
10. Acknowledgements ..............................................29
11. References ....................................................29
11.1. Normative References .....................................29
11.2. Informative References ...................................30
Appendix A. Fast Reroute Scalability Table ........................31
Appendix B. Abbreviations .........................................34
This document describes the methodology for benchmarking MPLS Fast Reroute (FRR) protection mechanisms. This document uses much of the terminology defined in [RFC6414].
このドキュメントでは、MPLS高速リルート（FRR）保護メカニズムのベンチマークの方法について説明します。このドキュメントでは、[RFC6414]で定義されている用語の多くを使用しています。
Protection mechanisms provide recovery of client services from a planned or an unplanned link or node failure. MPLS-FRR protection mechanisms are generally deployed in a network infrastructure where MPLS is used for the provisioning of point-to-point traffic engineered tunnels (tunnel). MPLS-FRR protection mechanisms aim to reduce the service disruption period by minimizing recovery time from most common failures.
保護メカニズムは、計画的または計画外のリンクまたはノード障害からのクライアントサービスの回復を提供します。 MPLS-FRR保護メカニズムは、一般に、MPLSがポイントツーポイントトラフィックエンジニアリングトンネル（トンネル）のプロビジョニングに使用されるネットワークインフラストラクチャに展開されます。 MPLS-FRR保護メカニズムは、最も一般的な障害からの回復時間を最小限に抑えることにより、サービス中断期間を短縮することを目的としています。
Network elements from different manufacturers behave differently to network failures, which impacts the network's ability and performance for failure recovery. Therefore, it becomes imperative for service providers to have a common benchmark to understand the performance behaviors of network elements.
製造元が異なるネットワーク要素は、ネットワーク障害とは異なる動作をするため、障害回復のためのネットワークの能力とパフォーマンスに影響を与えます。したがって、サービスプロバイダーがネットワーク要素のパフォーマンス動作を理解するための共通のベンチマークを持つことが不可欠になります。
There are two factors impacting service availability: frequency of failures and duration for which the failures persist. Failures can be classified further into two types: correlated and uncorrelated. Correlated and uncorrelated failures may be planned or unplanned.
サービスの可用性に影響を与える2つの要因があります。障害の頻度と、障害が持続する期間です。障害はさらに、相関と非相関の2つのタイプに分類できます。相関障害と非相関障害は、計画されている場合と計画されていない場合があります。
Planned failures are generally predictable. Network implementations should be able to handle both planned and unplanned failures and recover gracefully within a time frame to maintain service assurance. Hence, failover recovery time is one of the most important benchmarks that a service provider considers in choosing the building blocks for their network infrastructure.
計画的な障害は一般に予測可能です。ネットワークの実装は、計画的および計画外の障害の両方を処理し、サービス保証を維持するために、時間枠内で適切に回復できる必要があります。したがって、フェールオーバーの復旧時間は、サービスプロバイダーがネットワークインフラストラクチャのビルディングブロックを選択する際に考慮する最も重要なベンチマークの1つです。
A correlated failure is a result of the occurrence of two or more failures. A typical example is failure of a logical resource (e.g., Layer-2 (L2) links) due to a dependency on a common physical resource (e.g., common conduit) that fails. Within the context of MPLS protection mechanisms, failures that arise due to Shared Risk Link Groups (SRLGs) [RFC4202] can be considered as correlated failures.
相関障害は、2つ以上の障害の発生の結果です。典型的な例は、障害が発生した共通の物理リソース（例：共通コンジット）への依存関係による論理リソース（例：レイヤー2（L2）リンク）の障害です。 MPLS保護メカニズムのコンテキスト内では、共有リスクリンクグループ（SRLG）[RFC4202]が原因で発生する障害は、相関関係のある障害と見なすことができます。
MPLS-FRR [RFC4090] allows for the possibility that the Label Switched Paths (LSPs) can be reoptimized in the minutes following failover. IP traffic would be rerouted according to the preferred path for the post-failure topology. Thus, MPLS-FRR may include additional steps following the occurrence of the failure detection and failover event [RFC6414].
MPLS-FRR [RFC4090]を使用すると、フェイルオーバー後の数分でラベルスイッチドパス（LSP）を再最適化できる可能性があります。 IPトラフィックは、障害発生後のトポロジの優先パスに従って再ルーティングされます。したがって、MPLS-FRRには、障害検出とフェイルオーバーイベント[RFC6414]の発生に続く追加の手順が含まれる場合があります。
(1) Failover Event - Primary path (working path) fails
（1）フェイルオーバーイベント-プライマリパス（現用パス）が失敗する
(2) Failure Detection - Failover event is detected
（2）障害検出-フェイルオーバーイベントが検出されます
(3a) Failover - Working path switched to backup path
（3a）フェイルオーバー-作業パスがバックアップパスに切り替えられました
(3b) Reoptimization of working path (possible change from backup path)
（3b）作業パスの再最適化（バックアップパスからの変更の可能性あり）
(4) Restoration (see Section 3.3.5 of [RFC6414])
（4）復元（[RFC6414]のセクション3.3.5を参照）
(5) Reversion (see Section 3.3.6 of [RFC6414])
（5）復帰（[RFC6414]のセクション3.3.6を参照）
This document provides detailed test cases along with different topologies and scenarios that should be considered to effectively benchmark MPLS-FRR protection mechanisms and failover times on the data plane. Different failover events and scaling considerations are also provided in this document.
このドキュメントでは、MPLS-FRR保護メカニズムとデータプレーンのフェイルオーバー時間を効果的にベンチマークするために検討する必要があるさまざまなトポロジとシナリオとともに、詳細なテストケースを提供します。このドキュメントでは、さまざまなフェイルオーバーイベントとスケーリングに関する考慮事項についても説明します。
All benchmarking test cases defined in this document apply to facility backup [RFC4090]. The test cases cover a set of interesting failure scenarios and the associated procedures benchmark the performance of the Device Under Test (DUT) to recover from failures. Data-plane traffic is used to benchmark failover times. Testing scenarios related to MPLS-TE protection mechanisms when applied to MPLS Transport Profile and IP fast reroute applied to MPLS networks were not considered and are outside the scope of this document. However, the test setups considered for MPLS-based L3 and L2 services consider LDP over MPLS RSVP-TE configurations.
このドキュメントで定義されているすべてのベンチマークテストケースは、施設のバックアップ[RFC4090]に適用されます。テストケースは、一連の興味深い障害シナリオをカバーし、関連する手順は、障害から回復するためのテスト対象デバイス（DUT）のパフォーマンスをベンチマークします。データプレーントラフィックは、フェイルオーバー時間のベンチマークに使用されます。 MPLSトランスポートプロファイルに適用されるMPLS-TE保護メカニズムに関連するテストシナリオとMPLSネットワークに適用されるIP高速リルートは考慮されておらず、このドキュメントの範囲外です。ただし、MPLSベースのL3およびL2サービスで考慮されるテスト設定では、LDP over MPLS RSVP-TE構成が考慮されます。
Benchmarking of correlated failures is outside the scope of this document. Detection using Bidirectional Forwarding Detection (BFD) is outside the scope of this document, but it is mentioned in discussion sections.
相関関係のある障害のベンチマークは、このドキュメントの範囲外です。双方向転送検出（BFD）を使用した検出は、このドキュメントの範囲外ですが、ディスカッションセクションで言及されています。
The performance of the control plane is outside the scope of this document.
コントロールプレーンのパフォーマンスは、このドキュメントの範囲外です。
As described above, MPLS-FRR may include a reoptimization of the working path, with possible packet transfer impairments. Characterization of reoptimization is beyond the scope of this memo.
上記のように、MPLS-FRRには、パケット転送障害の可能性がある、現用パスの再最適化が含まれる場合があります。再最適化の特徴付けは、このメモの範囲を超えています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. While [RFC2119] defines the use of these key words primarily for Standards Track documents, this Informational document uses some of these key words.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14 [RFC2119]で説明されているように解釈されます。 [RFC2119]はこれらのキーワードの使用を主にStandards Trackドキュメントに定義していますが、この情報ドキュメントはこれらのキーワードのいくつかを使用しています。
The reader is assumed to be familiar with the commonly used MPLS terminology, some of which is defined in [RFC4090].
読者は、一般的に使用されているMPLS用語に精通していることを前提としています。その一部は[RFC4090]で定義されています。
This document uses much of the terminology defined in [RFC6414]. This document also uses existing terminology defined in other BMWG documents [RFC1242] [RFC2285] [RFC4689]. Appendix B provides abbreviations used in the document.
このドキュメントでは、[RFC6414]で定義されている用語の多くを使用しています。このドキュメントでは、他のBMWGドキュメント[RFC1242] [RFC2285] [RFC4689]で定義されている既存の用語も使用しています。付録Bは、この文書で使用されている略語を示しています。
Figure 1 illustrates the general reference topology. It shows the basic reference testbed and is applicable to all the test cases defined in this document. The Tester is comprised of a Traffic Generator (TG) and Traffic Analyzer (TA) and Emulator. A Tester is connected to the test network and, depending upon the test case, the DUT could vary. The Tester sends and receives IP traffic to the tunnel ingress and performs signaling protocol emulation to simulate real network scenarios in a lab environment. The Tester may also support MPLS-TE signaling to act as the ingress node to the MPLS tunnel. The lines in figures represent physical connections.
図1は、一般的な参照トポロジを示しています。基本的なリファレンステストベッドを示し、このドキュメントで定義されているすべてのテストケースに適用できます。テスターは、トラフィックジェネレーター（TG）、トラフィックアナライザー（TA）、およびエミュレーターで構成されています。テスターがテストネットワークに接続されており、テストケースによっては、DUTが異なる場合があります。テスターは、トンネルの入口にIPトラフィックを送受信し、シグナリングプロトコルエミュレーションを実行して、ラボ環境で実際のネットワークシナリオをシミュレートします。テスターは、MPLS-TEシグナリングをサポートして、MPLSトンネルへの入口ノードとして機能することもできます。図中の線は、物理的な接続を表しています。
+---------------------------+
| +------------|---------------+
| | | |
| | | |
+--------+ +--------+ +--------+ +--------+ +--------+
TG--| R1 |-----| R2 |----| R3 | | R4 | | R5 |
| |-----| |----| |----| |---| |
+--------+ +--------+ +--------+ +--------+ +--------+
| | | | |
| | | | |
| +--------+ | | TA
+---------| R6 |---------+ |
| |----------------------+
+--------+
Figure 1
図1
The tester MUST record the number of lost, duplicate, and out-of-order packets. It should further record arrival and departure times so that failover time, Additive Latency, and Reversion Time can be measured. The tester may be a single device or a test system emulating all the different roles along a primary or backup path.
テスターは、失われたパケット、重複したパケット、順序が正しくないパケットの数を記録する必要があります。フェイルオーバー時間、追加レイテンシ、および復帰時間を測定できるように、到着時間と出発時間をさらに記録する必要があります。テスターは、単一のデバイスでも、プライマリまたはバックアップパスに沿ってさまざまな役割をすべてエミュレートするテストシステムでもかまいません。
The label stack is dependent on the following three entities:
ラベルスタックは、次の3つのエンティティに依存しています。
(1) Type of protection (Link versus Node)
（1）保護のタイプ（リンクとノード）
(2) Number of remaining hops of the primary tunnel from the Point of Local Repair (PLR) [RFC6414]
（2）Point of Local Repair（PLR）からのプライマリトンネルの残りのホップ数[RFC6414]
(3) Number of remaining hops of the backup tunnel from the PLR
（3）PLRからのバックアップトンネルの残りのホップ数
Due to this dependency, it is RECOMMENDED that the benchmarking of failover times be performed on all the topologies provided in Section 6.
この依存関係のため、セクション6で提供されているすべてのトポロジでフェイルオーバー時間のベンチマークを実行することをお勧めします。
This section discusses the fundamentals of MPLS Protection testing:
このセクションでは、MPLS保護テストの基本について説明します。
(1) The types of network events that cause failover (Section 5.1)
（1）フェイルオーバーを引き起こすネットワークイベントのタイプ（5.1節）
(2) Indications for failover (Section 5.2)
（2）フェイルオーバーの指示（セクション5.2）
(3) The use of data traffic (Section 5.3)
（3）データトラフィックの使用（セクション5.3）
(4) Label Switched Path Scaling (Section 5.4)
（4）ラベルスイッチドパススケーリング（セクション5.4）
(5) IGP Selection (Section 5.5)
（5）IGPの選択（セクション5.5）
(6) Reversion of LSP (Section 5.6)
（6）LSPの復帰（セクション5.6）
(7) Traffic generation (Section 5.7)
（7）トラフィックの生成（セクション5.7）
The failover to the backup tunnel is primarily triggered by either link or node failures observed downstream of the Point of Local Repair (PLR). The failure events [RFC6414] are listed below.
バックアップトンネルへのフェイルオーバーは、主に、Point of Local Repair（PLR）の下流で観察されたリンクまたはノードの障害によってトリガーされます。失敗イベント[RFC6414]を以下に示します。
Link Failure Events - Interface Shutdown on PLR side with physical/link alarm - Interface Shutdown on remote side with physical/link alarm - Interface Shutdown on PLR side with RSVP hello enabled - Interface Shutdown on remote side with RSVP hello enabled - Interface Shutdown on PLR side with BFD - Interface Shutdown on remote side with BFD - Fiber Pull on the PLR side (both Transmit (TX) and Receive (RX) or just the TX) - Fiber Pull on the remote side (both TX and RX or just the RX) - Online Insertion and Removal (OIR) on PLR side - OIR on remote side - Sub-interface failure on PLR side (e.g., shutting down of a VLAN) - Sub-interface failure on remote side - Parent interface shutdown on PLR side (an interface bearing multiple sub-interfaces) - Parent interface shutdown on remote side
リンク障害イベント-物理/リンクアラームのあるPLR側のインターフェースシャットダウン-物理/リンクアラームのあるリモート側のインターフェースシャットダウン-RSVP helloが有効なPLR側のインターフェースシャットダウン-RSVP helloが有効なリモート側のインターフェースシャットダウン-PLRのインターフェースシャットダウンBFDを備えた側-BFDを備えたリモート側のインターフェースシャットダウン-PLR側のファイバープル（送信（TX）と受信（RX）の両方またはTXのみ）-リモート側のファイバープル（TXとRXの両方またはRXのみ） ）-PLR側の活性挿抜（OIR）-リモート側のOIR-PLR側のサブインターフェースの障害（例：VLANのシャットダウン）-リモート側のサブインターフェースの障害-PLR側の親インターフェースのシャットダウン（複数のサブインターフェースを持つインターフェース）-リモート側での親インターフェースのシャットダウン
Node Failure Events - A System reload initiated by either a graceful shutdown or a power failure - A system crash due to a software failure or an assert
ノード障害イベント-正常なシャットダウンまたは電源障害によってシステムのリロードが開始されました-ソフトウェア障害またはアサートによるシステムクラッシュ
Link failure detection [RFC6414] time depends on the link type and failure detection protocols running. For Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), the alarm type (such as LOS, AIS, or RDI) can be used. Other link types have L2 alarms, but they may not provide a short enough failure detection time. Ethernet-based links enabled with MPLS/IP do not have L2 failure indicators; therefore, they rely on L3 signaling for failure detection. However, for directly connected devices, remote fault indication in the ethernet auto-negotiation scheme could be considered as a type of L2 link failure indicator.
リンク障害検出[RFC6414]時間は、リンクタイプと実行中の障害検出プロトコルによって異なります。同期光ネットワーク（SONET）/同期デジタル階層（SDH）の場合、アラームタイプ（LOS、AIS、RDIなど）を使用できます。他のリンクタイプにはL2アラームがありますが、障害検出時間が十分に短いとは限りません。 MPLS / IPを有効にしたイーサネットベースのリンクには、L2障害インジケーターがありません。したがって、障害検出にはL3シグナリングを使用します。ただし、直接接続されたデバイスの場合、イーサネット自動ネゴシエーションスキームのリモート障害表示は、L2リンク障害インジケータの一種と見なすことができます。
MPLS has different failure detection techniques, such as BFD, or use of RSVP hellos. These methods can be used for the L3 failure indicators required by ethernet-based links or for some other non-ethernet-based links to help improve failure detection time. However, these fast failure detection mechanisms are out of scope.
MPLSには、BFDやRSVP helloの使用など、さまざまな障害検出技術があります。これらの方法は、イーサネットベースのリンクまたはその他の非イーサネットベースのリンクで必要なL3障害インジケータに使用して、障害検出時間を改善することができます。ただし、これらの高速障害検出メカニズムは範囲外です。
The test procedures in this document can be used for local failure or remote failure scenarios for comprehensive benchmarking and to evaluate failover performance independent of the failure detection techniques.
このドキュメントのテスト手順は、包括的なベンチマークのローカル障害またはリモート障害のシナリオに使用でき、障害検出技術とは無関係にフェイルオーバーのパフォーマンスを評価できます。
Currently, end customers use packet loss as a key metric for failover time [RFC6414]. Failover Packet Loss [RFC6414] is an externally observable event and has a direct impact on application performance. MPLS protection is expected to minimize packet loss in the event of a failure. For this reason, it is important to develop a standard router benchmarking methodology for measuring MPLS protection that uses packet loss as a metric. At a known rate of forwarding, packet loss can be measured and the failover time can be determined. Measurement of control-plane signaling to establish backup paths is not enough to verify failover. Failover is best determined when packets are actually traversing the backup path.
現在、エンドユーザーはパケット損失をフェイルオーバー時間の主要な指標として使用しています[RFC6414]。フェールオーバーパケット損失[RFC6414]は、外部から観測可能なイベントであり、アプリケーションのパフォーマンスに直接影響します。 MPLS保護は、障害発生時のパケット損失を最小限に抑えることが期待されています。このため、メトリックとしてパケット損失を使用するMPLS保護を測定するための標準ルーターベンチマーク手法を開発することが重要です。既知の転送速度で、パケット損失を測定し、フェイルオーバー時間を決定できます。コントロールプレーンシグナリングを測定してバックアップパスを確立するだけでは、フェールオーバーを確認できません。フェールオーバーは、パケットが実際にバックアップパスを通過するときに決定するのが最適です。
An additional benefit of using packet loss for calculation of failover time is that it allows use of a black-box test environment. Data traffic is offered at line-rate to the DUT, an emulated network failure event is forced to occur, and packet loss is externally measured to calculate the convergence time. This setup is independent of the DUT architecture.
フェイルオーバー時間の計算にパケット損失を使用するもう1つの利点は、ブラックボックステスト環境を使用できることです。データトラフィックはラインレートでDUTに提供され、エミュレートされたネットワーク障害イベントが強制的に発生し、パケット損失が外部で測定されて収束時間を計算します。このセットアップは、DUTアーキテクチャから独立しています。
In addition, this methodology considers the packets in error and duplicate packets [RFC4689] that could have been generated during the failover process. The methodologies consider lost, out-of-order
さらに、この方法では、エラーのあるパケットと、フェイルオーバープロセス中に生成された可能性のある重複パケット[RFC4689]が考慮されます。方法論は、失われた、順不同を考慮する
[RFC4689], and duplicate packets to be impaired packets that contribute to the failover time.
[RFC4689]、およびフェイルオーバー時間の一因となる障害パケットとなる重複パケット。
Failover time performance may vary with the number of established primary and backup tunnel LSPs and installed routes. However, the procedure outlined here should be used for any number of LSPs (L) and any number of routes protected by the PLR (R). The values of L and R must be recorded.
フェイルオーバー時間のパフォーマンスは、確立されたプライマリおよびバックアップトンネルLSPとインストールされたルートの数によって異なる場合があります。ただし、ここで説明する手順は、任意の数のLSP（L）およびPLR（R）で保護された任意の数のルートに使用する必要があります。 LとRの値を記録する必要があります。
The underlying IGP could be ISIS-TE or OSPF-TE for the methodology proposed here. See [RFC6412] for IGP options to consider and report.
基盤となるIGPは、ここで提案されている方法論のISIS-TEまたはOSPF-TEです。検討および報告するIGPオプションについては、[RFC6412]を参照してください。
Path restoration [RFC6414] provides a method to restore an alternate primary LSP upon failure and to switch traffic from the backup path to the restored primary path (reversion). In MPLS-FRR, reversion [RFC6414] can be implemented as Global Reversion or Local Reversion. It is important to include restoration and reversion as a step in each test case to measure the amount of packet loss, out-of-order packets, or duplicate packets that are produced.
パスの復元[RFC6414]は、障害発生時に代替プライマリLSPを復元し、バックアップパスから復元されたプライマリパスにトラフィックを切り替える方法（復帰）を提供します。 MPLS-FRRでは、復帰[RFC6414]は、グローバル復帰またはローカル復帰として実装できます。生成されたパケット損失、異常なパケット、または重複パケットの量を測定するために、各テストケースのステップとして復元と復帰を含めることが重要です。
Note: In addition to restoration and reversion, reoptimization can take place while the failure is still not recovered but it depends on the user configuration and reoptimization timers.
注：復元と復帰に加えて、障害がまだ回復していないときに再最適化を行うことができますが、これはユーザー構成と再最適化タイマーに依存します。
It is suggested that there be three or more traffic streams as long as there is a steady and constant rate of flow for all of the streams. In order to monitor the DUT performance for recovery times, a set of route prefixes should be advertised before traffic is sent. The traffic should be configured towards these routes.
すべてのストリームの流量が一定で一定である限り、3つ以上のトラフィックストリームが存在することが推奨されます。 DUTの回復時間を監視するには、トラフィックが送信される前に、ルートプレフィックスのセットをアドバタイズする必要があります。トラフィックはこれらのルートに向けて設定する必要があります。
Prefix-dependency behaviors are key in IP, and tests with route-specific flows spread across the routing table will reveal this dependency. Generating traffic to all of the prefixes reachable by the protected tunnel (probably in a Round-Robin fashion, where the traffic is destined to all the prefixes but one prefix at a time in a cyclic manner) is not recommended. Round-Robin traffic generation is not recommended to all prefixes, as time to hit all the prefixes may be higher than the failover time. This phenomenon will reduce the granularity of the measured results, and the results observed may not be accurate.
プレフィックス依存関係の動作はIPの重要な要素であり、ルーティング固有のフローをルーティングテーブル全体に広げてテストすると、この依存関係が明らかになります。保護されたトンネルによって到達可能なすべてのプレフィックスへのトラフィックの生成（おそらく、トラフィックが循環方式で一度に1つのプレフィックスを除くすべてのプレフィックスを宛先とするラウンドロビン方式）は推奨されません。すべてのプレフィックスにヒットする時間がフェイルオーバー時間より長くなる可能性があるため、ラウンドロビントラフィック生成はすべてのプレフィックスに推奨されません。この現象により、測定結果の粒度が低下し、観測された結果が正確でない場合があります。
It is RECOMMENDED that the Tester used to execute each test case have the following capabilities:
各テストケースを実行するために使用されるテスターには、次の機能があることが推奨されます。
1. Ability to establish MPLS-TE tunnels and push/pop labels.
1. MPLS-TEトンネルとプッシュ/ポップラベルを確立する機能。
2. Ability to produce a failover event [RFC6414].
2. フェイルオーバーイベントを生成する機能[RFC6414]。
3. Ability to insert a timestamp in each data packet's IP payload.
3. 各データパケットのIPペイロードにタイムスタンプを挿入する機能。
4. An internal time clock to control timestamping, time measurements, and time calculations.
4. タイムスタンプ、時間測定、時間計算を制御する内部タイムクロック。
5. Ability to disable or tune specific L2 and L3 protocol functions on any interface.
5. 任意のインターフェースで特定のL2およびL3プロトコル機能を無効化または調整する機能。
6. Ability to react upon the receipt of path error from the PLR.
6. PLRからのパスエラーの受信時に反応する機能。
The Tester MAY be capable of making non-data-plane convergence observations and use those observations for measurements.
テスターは、データプレーン以外の収束観測を行い、それらの観測を測定に使用できます（MAY）。
Failover time [RFC6414] is calculated using one of the following three methods:
フェイルオーバー時間[RFC6414]は、次の3つの方法のいずれかを使用して計算されます。
1. Packet-Loss-Based Method (PLBM): (Number of packets dropped/ packets per second * 1000) milliseconds. This method could also be referred to as the Loss-Derived method.
1. パケット損失ベースの方法（PLBM）：（ドロップされたパケット数/ 1秒あたりのパケット数* 1000）ミリ秒。この方法は、損失導出法とも呼ばれます。
2. Time-Based Loss Method (TBLM): This method relies on the ability of the traffic generators to provide statistics that reveal the duration of failure in milliseconds based on when the packet loss occurred (interval between non-zero packet loss and zero loss).
2. 時間ベースの損失方法（TBLM）：この方法は、トラフィックジェネレーターの機能に依存して、パケット損失が発生したとき（ゼロ以外のパケット損失とゼロ損失の間の間隔）に基づいて、ミリ秒単位で障害の期間を明らかにする統計を提供します。
3. Timestamp-Based Method (TBM): This method of failover calculation is based on the timestamp that gets transmitted as payload in the packets originated by the generator. The traffic analyzer records the timestamp of the last packet received before the failover event and the first packet after the failover and derives the time based on the difference between these two timestamps. Note: The payload could also contain sequence numbers for out-of-order packet calculation and duplicate packets.
3. タイムスタンプベースの方法（TBM）：このフェイルオーバー計算方法は、ジェネレーターが発信したパケットのペイロードとして送信されるタイムスタンプに基づいています。トラフィックアナライザーは、フェイルオーバーイベントの前に受信した最後のパケットとフェイルオーバー後の最初のパケットのタイムスタンプを記録し、これら2つのタイムスタンプの差に基づいて時間を導き出します。注：ペイロードには、順不同のパケット計算と重複パケットのシーケンス番号が含まれる場合もあります。
TBM would be able to detect reversion impairments beyond loss; thus, it is RECOMMENDED as the failover time method.
TBMは、損失を超えて復帰障害を検出できます。したがって、フェイルオーバー時間の方法として推奨されます。
In addition to the general reference topology shown in Figure 1, this section provides detailed insight into various proposed test setups that should be considered for comprehensively benchmarking the failover time in different roles along the primary tunnel.
図1に示す一般的な参照トポロジに加えて、このセクションでは、プライマリトンネルに沿ったさまざまな役割のフェールオーバー時間を包括的にベンチマークするために検討する必要のある、さまざまな提案されたテストセットアップについて詳しく説明します。
This section proposes a set of topologies that covers all the scenarios for local protection. All of these topologies can be mapped to the reference topology shown in Figure 1. Topologies provided in this section refer to the testbed required to benchmark failover time when the DUT is configured as a PLR in either head-end or midpoint role. Provided with each topology below is the label stack at the PLR. Penultimate Hop Popping (PHP) MAY be used and must be reported when used.
このセクションでは、ローカル保護のすべてのシナリオをカバーする一連のトポロジを提案します。これらのトポロジーはすべて、図1に示す参照トポロジーにマップできます。このセクションで提供されるトポロジーは、DUTがヘッドエンドまたはミッドポイントの役割でPLRとして構成されている場合のフェイルオーバー時間のベンチマークに必要なテストベッドを指します。以下の各トポロジーには、PLRのラベルスタックが用意されています。最後から2番目のホップポッピング（PHP）を使用できます（使用した場合は報告する必要があります）。
Figures 2 through 9 use the following convention and are subset of Figure 1:
図2〜9は、次の規則を使用しており、図1のサブセットです。
a) HE is Head-End b) T/E is Tail-End c) MID is Midpoint d) MP is Merge Point e) PLR is Point of Local Repair f) PRI is Primary Path g) BKP denotes Backup Path and Nodes h) UR is Upstream Router
a) HEはヘッドエンドですb）T / Eはテールエンドですc）MIDはミッドポイントですd）MPはマージポイントですe）PLRはローカル修理のポイントですf）PRIはプライマリパスですg）BKPはバックアップパスとノードを示しますh）URアップストリームルーターです
6.1.1. Link Protection: 1-Hop Primary (from PLR) and 1-Hop Backup Tail-End Tunnels
6.1.1. リンク保護：1ホッププライマリ（PLRから）および1ホップバックアップテールエンドトンネル
+-------+ +--------+ +--------+
| R1 | | R2 | PRI| R3 |
| UR/HE |--| HE/MID |----| MP/T/E |
| | | PLR |----| |
+-------+ +--------+ BKP+--------+
Figure 2
図2
Traffic No. of Labels No. of labels before failure after failure IP TRAFFIC (P-P) 0 0 Layer3 VPN (PE-PE) 1 1 Layer3 VPN (PE-P) 2 2 Layer2 VC (PE-PE) 1 1 Layer2 VC (PE-P) 2 2 Midpoint LSPs 0 0
トラフィックラベル数障害後の障害前のラベル数IPトラフィック（PP）0 0レイヤー3 VPN（PE-PE）1 1レイヤー3 VPN（PE-P）2 2レイヤー2 VC（PE-PE）1 1レイヤー2 VC（ PE-P）2 2ミッドポイントLSP 0 0
Please note the following:
次の点に注意してください：
a) For the P-P case, R2 and R3 act as P routers b) For the PE-PE cases, R2 acts as a PE and R3 acts as a remote PE c) For the PE-P cases, R2 acts as a PE router, R3 acts as a P router, and R5 acts as a remote PE router (please refer to Figure 1 for complete setup) d) For the midpoint case, R1, R2, and R3 act as HE, midpoint/PLR, and tail-end, respectively (as shown in the figure above)
a) PPの場合、R2およびR3はPルーターとして機能しますb）PE-PEの場合、R2はPEとして機能し、R3はリモートPEとして機能しますc）PE-Pの場合、R2はPEルーター、R3として機能しますPルーターとして機能し、R5はリモートPEルーターとして機能します（完全なセットアップについては図1を参照してください）d）ミッドポイントの場合、R1、R2、およびR3はHE、ミッドポイント/ PLR、およびテールエンドとして機能します。それぞれ（上の図に示すように）
6.1.2. Link Protection: 1-Hop Primary (from PLR) and 2-Hop Backup Tail-End Tunnels
6.1.2. リンク保護：1ホッププライマリ（PLRから）および2ホップバックアップテールエンドトンネル
+-------+ +--------+ +--------+
| R1 | | R2 | | R3 |
| UR/HE | | HE/MID |PRI | MP/T/E |
| |----| PLR |----| |
+-------+ +--------+ +--------+
|BKP |
| +--------+ |
| | R6 | |
|----| BKP |----|
| MID |
+--------+
Figure 3
図3
Traffic No. of Labels No. of labels before failure after failure IP TRAFFIC (P-P) 0 1 Layer3 VPN (PE-PE) 1 2 Layer3 VPN (PE-P) 2 3 Layer2 VC (PE-PE) 1 2 Layer2 VC (PE-P) 2 3 Midpoint LSPs 0 1
トラフィックラベル数障害後の障害前のラベル数IPトラフィック（PP）0 1レイヤー3 VPN（PE-PE）1 2レイヤー3 VPN（PE-P）2 3レイヤー2 VC（PE-PE）1 2レイヤー2 VC（ PE-P）2 3ミッドポイントLSP 0 1
Please note the following:
次の点に注意してください：
a) For the P-P case, R2 and R3 act as P routers b) For PE-PE cases, R2 acts as a PE and R3 acts as a remote PE c) For PE-P cases, R2 acts as a PE router, R3 acts as a P router, and R5 acts as a remote PE router (please refer to Figure 1 for complete setup) d) For the midpoint case, R1, R2, and R3 act as HE, midpoint/PLR, and tail-end, respectively (as shown in the figure above)
a) PPの場合、R2およびR3はPルーターとして機能しますb）PE-PEの場合、R2はPEとして機能し、R3はリモートPEとして機能しますc）PE-Pの場合、R2はPEルーターとして機能し、R3は次のように機能しますPルーター、およびR5はリモートPEルーターとして機能します（完全なセットアップについては図1を参照してください）d）ミッドポイントの場合、R1、R2、およびR3はそれぞれHE、ミッドポイント/ PLR、およびテールエンドとして機能します（上図に示すように）
6.1.3. Link Protection: 2-Hop (or More) Primary (from PLR) and 1-Hop Backup Tail-End Tunnels
6.1.3. リンク保護：2ホップ（またはそれ以上）のプライマリ（PLRから）および1ホップのバックアップテールエンドトンネル
+--------+ +--------+ +--------+ +--------+
| R1 | | R2 |PRI | R3 |PRI | R4 |
| UR/HE |----| HE/MID |----| MP/MID |------| T/E |
| | | PLR |----| | | |
+--------+ +--------+ BKP+--------+ +--------+
Figure 4
図4
Traffic No. of Labels Num of labels before failure after failure IP TRAFFIC (P-P) 1 1 Layer3 VPN (PE-PE) 2 2 Layer3 VPN (PE-P) 3 3 Layer2 VC (PE-PE) 2 2 Layer2 VC (PE-P) 3 3 Midpoint LSPs 1 1
トラフィックラベル数障害発生後の障害発生前のラベル数IPトラフィック（PP）1 1レイヤー3 VPN（PE-PE）2 2レイヤー3 VPN（PE-P）3 3レイヤー2 VC（PE-PE）2 2レイヤー2 VC（PE -P）3 3ミッドポイントLSP 1 1
Please note the following:
次の点に注意してください：
a) For the P-P case, R2, R3, and R4 act as P routers b) For PE-PE cases, R2 acts as a PE and R4 acts as a remote PE c) For PE-P cases, R2 acts as a PE router, R3 acts as a P router, and R5 acts as remote PE router (please refer to Figure 1 for complete setup) d) For the midpoint case, R1, R2, R3, and R4 act as HE, midpoint/PLR, and tail-end, respectively (as shown in the figure above)
a) PPの場合、R2、R3、およびR4はPルーターとして機能しますb）PE-PEの場合、R2はPEとして機能し、R4はリモートPEとして機能しますc）PE-Pの場合、R2はPEルーターとして機能します。 R3はPルーターとして機能し、R5はリモートPEルーターとして機能します（完全なセットアップについては図1を参照してください）d）ミッドポイントの場合、R1、R2、R3、およびR4はHE、ミッドポイント/ PLR、およびテールとして機能しますそれぞれ（上の図に示すように）終了
6.1.4. Link Protection: 2-Hop (or More) Primary (from PLR) and 2-Hop Backup Tail-End Tunnels
6.1.4. リンク保護：2ホップ（またはそれ以上）のプライマリ（PLRから）および2ホップのバックアップテールエンドトンネル
+--------+ +--------+PRI +--------+ PRI +--------+
| R1 | | R2 | | R3 | | R4 |
| UR/HE |----| HE/MID |----| MP/MID|------| T/E |
| | | PLR | | | | |
+--------+ +--------+ +--------+ +--------+
BKP| |
| +--------+ |
| | R6 | |
+---| BKP |-
| MID |
+--------+
Figure 5
図5
Traffic No. of Labels No. of labels before failure after failure IP TRAFFIC (P-P) 1 2 Layer3 VPN (PE-PE) 2 3 Layer3 VPN (PE-P) 3 4 Layer2 VC (PE-PE) 2 3 Layer2 VC (PE-P) 3 4 Midpoint LSPs 1 2
トラフィックラベル数障害後の障害前のラベル数IPトラフィック（PP）1 2レイヤー3 VPN（PE-PE）2 3レイヤー3 VPN（PE-P）3 4レイヤー2 VC（PE-PE）2 3レイヤー2 VC（ PE-P）3 4ミッドポイントLSP 1 2
Please note the following:
次の点に注意してください：
a) For the P-P case, R2, R3, and R4 act as P routers b) For PE-PE cases, R2 acts as a PE and R4 acts as a remote PE c) For PE-P cases, R2 acts as a PE router, R3 acts as a P router, and R5 acts as remote PE router (please refer to Figure 1 for complete setup) d) For the midpoint case, R1, R2, R3 and R4 act as HE, midpoint/PLR, and tail-end, respectively (as shown in the figure above)
a) PPの場合、R2、R3、およびR4はPルーターとして機能しますb）PE-PEの場合、R2はPEとして機能し、R4はリモートPEとして機能しますc）PE-Pの場合、R2はPEルーターとして機能します。 R3はPルーターとして機能し、R5はリモートPEルーターとして機能します（完全なセットアップについては図1を参照してください）d）ミッドポイントの場合、R1、R2、R3およびR4はHE、ミッドポイント/ PLR、およびテールエンドとして機能します、それぞれ（上の図に示すように）
6.2.1. Node Protection: 2-Hop Primary (from PLR) and 1-Hop Backup Tail-End Tunnels
6.2.1. ノード保護：2ホッププライマリ（PLRから）および1ホップバックアップテールエンドトンネル
+--------+ +--------+ +--------+ +--------+
| R1 | | R2 |PRI | R3 | PRI | R4 |
| UR/HE |----| HE/MID |----| MID |------| MP/T/E |
| | | PLR | | | | |
+--------+ +--------+ +--------+ +--------+
|BKP |
-----------------------------
Figure 6
図6
Traffic No. of Labels No. of labels before failure after failure IP TRAFFIC (P-P) 1 0 Layer3 VPN (PE-PE) 2 1 Layer3 VPN (PE-P) 3 2 Layer2 VC (PE-PE) 2 1 Layer2 VC (PE-P) 3 2 Midpoint LSPs 1 0
トラフィックラベル数障害後の障害前のラベル数IPトラフィック（PP）1 0レイヤー3 VPN（PE-PE）2 1レイヤー3 VPN（PE-P）3 2レイヤー2 VC（PE-PE）2 1レイヤー2 VC（ PE-P）3 2ミッドポイントLSP 1 0
Please note the following:
次の点に注意してください：
a) For the P-P case, R2, R3, and R4 act as P routers b) For PE-PE cases, R2 acts as a PE and R4 acts as a remote PE c) For PE-P cases, R2 acts as a PE router, R4 acts as a P router, and R5 acts as remote PE router (please refer to Figure 1 for complete setup) d) For the midpoint case, R1, R2, R3, and R4 act as HE, midpoint/PLR, and tail-end, respectively (as shown in the figure above)
a) PPの場合、R2、R3、およびR4はPルーターとして機能しますb）PE-PEの場合、R2はPEとして機能し、R4はリモートPEとして機能しますc）PE-Pの場合、R2はPEルーターとして機能します。 R4はPルータとして機能し、R5はリモートPEルータとして機能します（完全なセットアップについては図1を参照してください）d）ミッドポイントの場合、R1、R2、R3、およびR4はHE、ミッドポイント/ PLR、およびテールとして機能しますそれぞれ（上の図に示すように）終了
6.2.2. Node Protection: 2-Hop Primary (from PLR) and 2-Hop Backup Tail-End Tunnels
6.2.2. ノード保護：2ホッププライマリ（PLRから）および2ホップバックアップテールエンドトンネル
+--------+ +--------+ +--------+ +--------+
| R1 | | R2 | | R3 | | R4 |
| UR/HE | | HE/MID |PRI | MID |PRI | MP/T/E |
| |----| PLR |----| |----| |
+--------+ +--------+ +--------+ +--------+
| |
BKP| +--------+ |
| | R6 | |
---------| BKP |---------
| MID |
+--------+
Figure 7
図7
Traffic No. of Labels No. of labels before failure after failure IP TRAFFIC (P-P) 1 1 Layer3 VPN (PE-PE) 2 2 Layer3 VPN (PE-P) 3 3 Layer2 VC (PE-PE) 2 2 Layer2 VC (PE-P) 3 3 Midpoint LSPs 1 1
トラフィックラベル数障害後の障害前のラベル数IPトラフィック（PP）1 1レイヤー3 VPN（PE-PE）2 2レイヤー3 VPN（PE-P）3 3レイヤー2 VC（PE-PE）2 2レイヤー2 VC（ PE-P）3 3ミッドポイントLSP 1 1
Please note the following:
次の点に注意してください：
a) For the P-P case, R2, R3, and R4 act as P routers b) For PE-PE cases, R2 acts as a PE and R4 acts as a remote PE c) For PE-P cases, R2 acts as a PE router, R4 acts as a P router, and R5 acts as remote PE router (please refer to Figure 1 for complete setup) d) For the midpoint case, R1, R2, R3, and R4 act as HE, midpoint/PLR, and tail-end, respectively (as shown in the figure above)
a) PPの場合、R2、R3、およびR4はPルーターとして機能しますb）PE-PEの場合、R2はPEとして機能し、R4はリモートPEとして機能しますc）PE-Pの場合、R2はPEルーターとして機能します。 R4はPルータとして機能し、R5はリモートPEルータとして機能します（完全なセットアップについては図1を参照してください）d）ミッドポイントの場合、R1、R2、R3、およびR4はHE、ミッドポイント/ PLR、およびテールとして機能しますそれぞれ（上の図に示すように）終了
6.2.3. Node Protection: 3-Hop (or More) Primary (from PLR) and 1-Hop Backup Tail-End Tunnels
6.2.3. ノード保護：3ホップ（またはそれ以上）のプライマリ（PLRから）および1ホップのバックアップテールエンドトンネル
+--------+ +--------+PRI+--------+PRI+--------+PRI+--------+
| R1 | | R2 | | R3 | | R4 | | R5 |
| UR/HE |--| HE/MID |---| MID |---| MP |---| T/E |
| | | PLR | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+
BKP| |
--------------------------
Figure 8
図8
Traffic No. of Labels No. of labels before failure after failure IP TRAFFIC (P-P) 1 1 Layer3 VPN (PE-PE) 2 2 Layer3 VPN (PE-P) 3 3 Layer2 VC (PE-PE) 2 2 Layer2 VC (PE-P) 3 3 Midpoint LSPs 1 1
トラフィックラベル数障害後の障害前のラベル数IPトラフィック（PP）1 1レイヤー3 VPN（PE-PE）2 2レイヤー3 VPN（PE-P）3 3レイヤー2 VC（PE-PE）2 2レイヤー2 VC（ PE-P）3 3ミッドポイントLSP 1 1
Please note the following:
次の点に注意してください：
a) For the P-P case, R2, R3, R4, and R5 act as P routers b) For PE-PE cases, R2 acts as a PE and R5 acts as a remote PE c) For PE-P cases, R2 acts as a PE router, R4 acts as a P router, and R5 acts as remote PE router (please refer to Figure 1 for complete setup) d) For the midpoint case, R1, R2, R3, R4, and R5 act as HE, midpoint/PLR, and tail-end, respectively (as shown in the figure above)
a) PPの場合、R2、R3、R4、およびR5はPルータとして機能しますb）PE-PEの場合、R2はPEとして機能し、R5はリモートPEとして機能しますc）PE-Pの場合、R2はPEとして機能しますルーター、R4はPルーターとして機能し、R5はリモートPEルーターとして機能します（完全なセットアップについては図1を参照してください）d）ミッドポイントの場合、R1、R2、R3、R4、およびR5はHE、ミッドポイント/ PLRとして機能します、およびテールエンド（上の図に示すように）
6.2.4. Node Protection: 3-Hop (or More) Primary (from PLR) and 2-Hop Backup Tail-End Tunnels
6.2.4. ノード保護：3ホップ（またはそれ以上）のプライマリ（PLRから）および2ホップのバックアップテールエンドトンネル
+--------+ +--------+ +--------+ +--------+ +--------+
| R1 | | R2 | | R3 | | R4 | | R5 |
| UR/HE | | HE/MID |PRI| MID |PRI| MP |PRI| T/E |
| |-- | PLR |---| |---| |---| |
+--------+ +--------+ +--------+ +--------+ +--------+
BKP| |
| +--------+ |
| | R6 | |
---------| BKP |-------
| MID |
+--------+
Figure 9
図9
Traffic No. of Labels No. of labels before failure after failure IP TRAFFIC (P-P) 1 2 Layer3 VPN (PE-PE) 2 3 Layer3 VPN (PE-P) 3 4 Layer2 VC (PE-PE) 2 3 Layer2 VC (PE-P) 3 4 Midpoint LSPs 1 2
トラフィックラベル数障害後の障害前のラベル数IPトラフィック（PP）1 2レイヤー3 VPN（PE-PE）2 3レイヤー3 VPN（PE-P）3 4レイヤー2 VC（PE-PE）2 3レイヤー2 VC（ PE-P）3 4ミッドポイントLSP 1 2
Please note the following:
次の点に注意してください：
a) For the P-P case, R2, R3, R4, and R5 act as P routers b) For PE-PE cases, R2 acts as a PE and R5 acts as a remote PE c) For PE-P cases, R2 acts as a PE router, R4 acts as a P router, and R5 acts as remote PE router (please refer to Figure 1 for complete setup) d) For the midpoint case, R1, R2, R3, R4, and R5 act as HE, midpoint/PLR, and tail-end, respectively (as shown in the figure above)
a) PPの場合、R2、R3、R4、およびR5はPルータとして機能しますb）PE-PEの場合、R2はPEとして機能し、R5はリモートPEとして機能しますc）PE-Pの場合、R2はPEとして機能しますルーター、R4はPルーターとして機能し、R5はリモートPEルーターとして機能します（完全なセットアップについては図1を参照してください）d）ミッドポイントの場合、R1、R2、R3、R4、およびR5はHE、ミッドポイント/ PLRとして機能します、およびテールエンド（上の図に示すように）
The procedure described in this section can be applied to all eight base test cases and the associated topologies. The backup as well as the primary tunnels are configured to be alike in terms of bandwidth usage. In order to benchmark failover with all possible label stack depth applicable (as seen with current deployments), it is RECOMMENDED to perform all of the test cases provided in this section. The forwarding performance test cases in Section 7.1 MUST be performed prior to performing the failover test cases.
このセクションで説明する手順は、8つの基本テストケースすべてと関連するトポロジに適用できます。バックアップとプライマリトンネルは、帯域幅の使用に関して同じように構成されています。可能なすべてのラベルスタックの深さでフェールオーバーをベンチマークするために（現在の展開で見られるように）、このセクションで提供されるすべてのテストケースを実行することをお勧めします。セクション7.1の転送パフォーマンステストケースは、フェイルオーバーテストケースを実行する前に実行する必要があります。
The considerations of Section 4 of [RFC2544] are applicable when evaluating the results obtained using these methodologies as well.
[RFC2544]のセクション4の考慮事項は、これらの方法論を使用して得られた結果を評価する場合にも適用されます。
Benchmarking failover time [RFC6414] for MPLS protection first requires a baseline measurement of the forwarding performance of the test topology, including the DUT. Forwarding performance is benchmarked by the throughput as defined in [RFC5695] and measured in units of packets per second (pps). This section provides two test cases to benchmark forwarding performance. These are with the DUT configured as a head-end PLR, midpoint PLR, and egress PLR.
MPLS保護のフェイルオーバー時間[RFC6414]のベンチマークには、最初に、DUTを含むテストトポロジの転送パフォーマンスのベースライン測定が必要です。転送パフォーマンスは、[RFC5695]で定義されているスループットによってベンチマークされ、パケット/秒（pps）の単位で測定されます。このセクションでは、転送パフォーマンスをベンチマークする2つのテストケースを示します。これらは、ヘッドエンドPLR、ミッドポイントPLR、および出力PLRとして構成されたDUTで使用されます。
Objective:
目的：
To benchmark the maximum rate (pps) on the PLR (as head-end) over the primary LSP and backup LSP.
プライマリLSPおよびバックアップLSP上のPLR（ヘッドエンドとして）の最大レート（pps）をベンチマークする。
Test Setup:
テスト設定：
A. Select any one topology out of the eight from Section 6.
A.セクション6の8つのトポロジーから1つのトポロジーを選択します。
B. Select or enable IP, L3 VPN, or L2 VPN services with the DUT as head-end PLR.
B. DUTをヘッドエンドPLRとして使用して、IP、L3 VPN、またはL2 VPNサービスを選択または有効化します。
C. The DUT will also have two interfaces connected to the traffic generator/analyzer. (If the node downstream of the PLR is not a simulated node, then the ingress of the tunnel should have one link connected to the traffic generator, and the node downstream of the PLR or the egress of the tunnel should have a link connected to the traffic analyzer).
C. DUTには、トラフィックジェネレーター/アナライザーに接続された2つのインターフェイスもあります。 （PLRの下流のノードがシミュレートされたノードでない場合、トンネルの入口には1つのリンクがトラフィックジェネレーターに接続されている必要があり、PLRの下流のノードまたはトンネルの出口にはリンクが接続されている必要がありますトラフィックアナライザー）。
Procedure:
手順：
1. Establish the primary LSP on R2 required by the topology selected.
1. 選択したトポロジで必要なR2にプライマリLSPを確立します。
2. Establish the backup LSP on R2 required by the selected topology.
2. 選択したトポロジで必要なR2にバックアップLSPを確立します。
3. Verify that primary and backup LSPs are up and that the primary is protected.
3. プライマリLSPとバックアップLSPが起動しており、プライマリが保護されていることを確認します。
4. Verify that Fast Reroute protection is enabled and ready.
4. Fast Reroute保護が有効で準備ができていることを確認します。
5. Set up traffic streams as described in Section 5.7.
5. セクション5.7の説明に従って、トラフィックストリームを設定します。
6. Send MPLS traffic over the primary LSP at the throughput supported by the DUT (Section 6 of [RFC2544]).
6. DUTでサポートされているスループットでプライマリLSPを介してMPLSトラフィックを送信します（[RFC2544]のセクション6）。
7. Record the throughput over the primary LSP.
7. プライマリLSPのスループットを記録します。
8. Trigger a link failure as described in Section 5.1.
8. セクション5.1の説明に従って、リンク障害をトリガーします。
9. Verify that the offered load gets mapped to the backup tunnel and measure the Additive Backup Delay [RFC6414].
9. 提供された負荷がバックアップトンネルにマッピングされていることを確認し、Additive Backup Delay [RFC6414]を測定します。
10. 30 seconds after failover, stop the offered load and measure the throughput, packet loss, out-of-order packets, and duplicate packets over the backup LSP.
10. フェイルオーバーの30秒後、提供された負荷を停止し、スループット、パケット損失、異常パケット、およびバックアップLSP上の重複パケットを測定します。
11. Adjust the offered load and repeat steps 6 through 10 until the throughput values for the primary and backup LSPs are equal.
11. 提供される負荷を調整し、プライマリLSPとバックアップLSPのスループット値が等しくなるまで手順6〜10を繰り返します。
12. Record the final throughput, which corresponds to the offered load that will be used for the head-end PLR failover test cases.
12. ヘッドエンドPLRフェールオーバーテストケースに使用される提供された負荷に対応する最終スループットを記録します。
Objective:
目的：
To benchmark the maximum rate (pps) on the PLR (as midpoint) over the primary LSP and backup LSP.
プライマリLSPおよびバックアップLSP上のPLR（中間点として）の最大レート（pps）をベンチマークする。
Test Setup:
テスト設定：
A. Select any one topology out of the eight from Section 6.
A.セクション6の8つのトポロジーから1つのトポロジーを選択します。
B. The DUT will also have two interfaces connected to the traffic generator.
B. DUTには、トラフィックジェネレーターに接続された2つのインターフェイスもあります。
Procedure:
手順：
1. Establish the primary LSP on R1 required by the topology selected.
1. 選択したトポロジで必要なR1にプライマリLSPを確立します。
2. Establish the backup LSP on R2 required by the selected topology.
2. 選択したトポロジで必要なR2にバックアップLSPを確立します。
3. Verify that primary and backup LSPs are up and that the primary is protected.
3. プライマリLSPとバックアップLSPが起動しており、プライマリが保護されていることを確認します。
4. Verify that Fast Reroute protection is enabled and ready.
4. Fast Reroute保護が有効で準備ができていることを確認します。
5. Set up traffic streams as described in Section 5.7.
5. セクション5.7の説明に従って、トラフィックストリームを設定します。
6. Send MPLS traffic over the primary LSP at the throughput supported by the DUT (Section 6 of [RFC2544]).
6. DUTでサポートされているスループットでプライマリLSPを介してMPLSトラフィックを送信します（[RFC2544]のセクション6）。
7. Record the throughput over the primary LSP.
7. プライマリLSPのスループットを記録します。
8. Trigger a link failure as described in Section 5.1.
8. セクション5.1の説明に従って、リンク障害をトリガーします。
9. Verify that the offered load gets mapped to the backup tunnel and measure the Additive Backup Delay [RFC6414].
9. 提供された負荷がバックアップトンネルにマッピングされていることを確認し、Additive Backup Delay [RFC6414]を測定します。
10. 30 seconds after failover, stop the offered load and measure the throughput, packet loss, out-of-order packets, and duplicate packets over the backup LSP.
10. フェイルオーバーの30秒後、提供された負荷を停止し、スループット、パケット損失、異常パケット、およびバックアップLSP上の重複パケットを測定します。
11. Adjust the offered load and repeat steps 6 through 10 until the throughput values for the primary and backup LSPs are equal.
11. 提供される負荷を調整し、プライマリLSPとバックアップLSPのスループット値が等しくなるまで手順6〜10を繰り返します。
12. Record the final throughput, which corresponds to the offered load that will be used for the midpoint PLR failover test cases.
12. 最終スループットを記録します。これは、ミッドポイントPLRフェイルオーバーテストケースに使用される提供負荷に対応しています。
Objective:
目的：
To benchmark the MPLS failover time due to link failure events described in Section 5.1 experienced by the DUT, which is the head-end PLR.
ヘッドエンドPLRである、DUTが経験したセクション5.1で説明されているリンク障害イベントによるMPLSフェイルオーバー時間をベンチマークするため。
Test Setup:
テスト設定：
A. Select any one topology out of the eight from Section 6.
A.セクション6の8つのトポロジーから1つのトポロジーを選択します。
B. Select or enable IP, L3 VPN, or L2 VPN services with the DUT as head-end PLR.
B. DUTをヘッドエンドPLRとして使用して、IP、L3 VPN、またはL2 VPNサービスを選択または有効化します。
C. The DUT will also have two interfaces connected to the traffic generator/analyzer. (If the node downstream of the PLR is not a simulated node, then the ingress of the tunnel should have one link connected to the traffic generator, and the node downstream to the PLR or the egress of the tunnel should have a link connected to the traffic analyzer).
C. DUTには、トラフィックジェネレーター/アナライザーに接続された2つのインターフェイスもあります。 （PLRの下流のノードがシミュレートされたノードでない場合、トンネルの入口には1つのリンクがトラフィックジェネレーターに接続されている必要があり、PLRの下流のノードまたはトンネルの出口にはリンクが接続されている必要がありますトラフィックアナライザー）。
Test Configuration:
テスト構成：
1. Configure the number of primaries on R2 and the backups on R2 as required by the topology selected.
1. 選択したトポロジの必要に応じて、R2のプライマリとR2のバックアップの数を構成します。
2. Configure the test setup to support reversion.
2. 復帰をサポートするようにテスト設定を構成します。
3. Advertise prefixes (as per the FRR Scalability Table in Appendix A) by the tail-end.
3. 末尾でプレフィックスをアドバタイズします（付録AのFRRスケーラビリティテーブルに従って）。
Procedure:
手順：
The test case in Section 7.1.1, "Head-End PLR Forwarding Performance", MUST be completed first to obtain the throughput to use as the offered load.
セクション7.1.1「ヘッドエンドPLR転送パフォーマンス」のテストケースは、提供される負荷として使用するスループットを取得するために、最初に完了する必要があります。
1. Establish the primary LSP on R2 required by the topology selected.
1. 選択したトポロジで必要なR2にプライマリLSPを確立します。
2. Establish the backup LSP on R2 required by the selected topology.
2. 選択したトポロジで必要なR2にバックアップLSPを確立します。
3. Verify that primary and backup LSPs are up and that the primary is protected.
3. プライマリLSPとバックアップLSPが起動しており、プライマリが保護されていることを確認します。
4. Verify that Fast Reroute protection is enabled and ready.
4. Fast Reroute保護が有効で準備ができていることを確認します。
5. Set up traffic streams for the offered load as described in Section 5.7.
5. セクション5.7の説明に従って、提供された負荷のトラフィックストリームを設定します。
6. Provide the offered load from the tester at the throughput [RFC1242] level obtained from the test case in Section 7.1.1.
6. セクション7.1.1のテストケースから取得したスループット[RFC1242]レベルでテスターから提供された負荷を提供します。
7. Verify that traffic is switched over the primary LSP without packet loss.
7. トラフィックがパケット損失なしでプライマリLSP経由で切り替えられることを確認します。
8. Trigger a link failure as described in Section 5.1.
8. セクション5.1の説明に従って、リンク障害をトリガーします。
9. Verify that the offered load gets mapped to the backup tunnel and measure the Additive Backup Delay [RFC6414].
9. 提供された負荷がバックアップトンネルにマッピングされていることを確認し、Additive Backup Delay [RFC6414]を測定します。
10. 30 seconds after failover, stop the offered load and measure the total failover packet loss [RFC6414].
10. フェイルオーバーの30秒後に、提供された負荷を停止し、フェイルオーバーパケット損失の合計を測定します[RFC6414]。
11. Calculate the failover time benchmark using the selected failover time calculation method (TBLM, PLBM, or TBM) [RFC6414].
11. 選択したフェイルオーバー時間の計算方法（TBLM、PLBM、またはTBM）[RFC6414]を使用して、フェイルオーバー時間のベンチマークを計算します。
12. Restart the offered load and restore the primary LSP to verify that reversion occurs and measure the Reversion Packet Loss [RFC6414].
12. 提供された負荷を再開し、プライマリLSPを復元して、復帰が発生することを確認し、復帰パケット損失[RFC6414]を測定します。
13. Calculate the Reversion Time benchmark using the selected failover time calculation method (TBLM, PLBM, or TBM) [RFC6414].
13. 選択したフェイルオーバー時間計算方法（TBLM、PLBM、またはTBM）[RFC6414]を使用して、復帰時間のベンチマークを計算します。
14. Verify that the head-end signals new LSP and protection should be in place again.
14. ヘッドエンドが新しいLSPを通知し、保護が再度設定されていることを確認します。
It is RECOMMENDED that this procedure be repeated for each of the link failure triggers defined in Section 5.1.
この手順は、セクション5.1で定義されているリンク障害トリガーごとに繰り返すことをお勧めします。
Objective:
目的：
To benchmark the MPLS failover time due to link failure events described in Section 5.1 experienced by the DUT, which is the midpoint PLR.
中間点PLRである、DUTが経験したセクション5.1で説明されているリンク障害イベントによるMPLSフェイルオーバー時間をベンチマークするため。
Test Setup:
テスト設定：
A. Select any one topology out of the eight from Section 6.
A.セクション6の8つのトポロジーから1つのトポロジーを選択します。
B. The DUT will also have two interfaces connected to the traffic generator.
B. DUTには、トラフィックジェネレーターに接続された2つのインターフェイスもあります。
Test Configuration:
テスト構成：
1. Configure the number of primaries on R1 and the backups on R2 as required by the topology selected.
1. 選択したトポロジの必要に応じて、R1のプライマリとR2のバックアップの数を構成します。
2. Configure the test setup to support reversion.
2. 復帰をサポートするようにテスト設定を構成します。
3. Advertise prefixes (as per the FRR Scalability Table in Appendix A) by the tail-end.
3. 末尾でプレフィックスをアドバタイズします（付録AのFRRスケーラビリティテーブルに従って）。
Procedure:
手順：
The test case in Section 7.1.2, "Midpoint PLR Forwarding Performance", MUST be completed first to obtain the throughput to use as the offered load.
7.1.2項「ミッドポイントPLR転送パフォーマンス」のテストケースは、提供される負荷として使用するスループットを取得するために最初に完了しなければなりません。
1. Establish the primary LSP on R1 as required by the topology selected.
1. 選択したトポロジの必要に応じて、R1にプライマリLSPを確立します。
2. Establish the backup LSP on R2 as required by the selected topology.
2. 選択したトポロジの必要に応じて、R2にバックアップLSPを確立します。
3. Perform steps 3 through 14 from Section 7.2, "Head-End PLR with Link Failure".
3. 7.2項「リンク障害のあるヘッドエンドPLR」の手順3から14を実行します。
It is RECOMMENDED that this procedure be repeated for each of the link failure triggers defined in section 5.1.
この手順は、セクション5.1で定義されているリンク障害トリガーごとに繰り返すことをお勧めします。
Objective:
目的：
To benchmark the MPLS failover time due to node failure events described in Section 5.1 experienced by the DUT, which is the head-end PLR.
ヘッドエンドPLRである、DUTが経験したセクション5.1で説明されているノード障害イベントによるMPLSフェイルオーバー時間をベンチマークするため。
Test Setup:
テスト設定：
A. Select any one topology out of the eight from Section 6.
A.セクション6の8つのトポロジーから1つのトポロジーを選択します。
B. Select or enable IP, L3 VPN, or L2 VPN services with the DUT as head-end PLR.
B. DUTをヘッドエンドPLRとして使用して、IP、L3 VPN、またはL2 VPNサービスを選択または有効化します。
C. The DUT will also have two interfaces connected to the traffic generator/analyzer.
C. DUTには、トラフィックジェネレーター/アナライザーに接続された2つのインターフェイスもあります。
Test Configuration:
テスト構成：
1. Configure the number of primaries on R2 and the backups on R2 as required by the topology selected.
1. 選択したトポロジの必要に応じて、R2のプライマリとR2のバックアップの数を構成します。
2. Configure the test setup to support reversion.
2. 復帰をサポートするようにテスト設定を構成します。
3. Advertise prefixes (as per the FRR Scalability Table in Appendix A) by the tail-end.
3. 末尾でプレフィックスをアドバタイズします（付録AのFRRスケーラビリティテーブルに従って）。
Procedure:
手順：
The test case in Section 7.1.1, "Head-End PLR Forwarding Performance", MUST be completed first to obtain the throughput to use as the offered load.
セクション7.1.1「ヘッドエンドPLR転送パフォーマンス」のテストケースは、提供される負荷として使用するスループットを取得するために、最初に完了する必要があります。
1. Establish the primary LSP on R2 as required by the topology selected.
1. 選択したトポロジの必要に応じて、R2にプライマリLSPを確立します。
2. Establish the backup LSP on R2 as required by the selected topology.
2. 選択したトポロジの必要に応じて、R2にバックアップLSPを確立します。
3. Verify that the primary and backup LSPs are up and that the primary is protected.
3. プライマリLSPとバックアップLSPが起動しており、プライマリが保護されていることを確認します。
4. Verify that Fast Reroute protection is enabled and ready.
4. Fast Reroute保護が有効で準備ができていることを確認します。
5. Set up traffic streams for the offered load as described in Section 5.7.
5. セクション5.7の説明に従って、提供された負荷のトラフィックストリームを設定します。
6. Provide the offered load from the tester at the throughput [RFC1242] level obtained from the test case in Section 7.1.1.
6. セクション7.1.1のテストケースから取得したスループット[RFC1242]レベルでテスターから提供された負荷を提供します。
7. Verify that traffic is switched over the primary LSP without packet loss.
7. トラフィックがパケット損失なしでプライマリLSP経由で切り替えられることを確認します。
8. Trigger a node failure as described in Section 5.1.
8. セクション5.1の説明に従って、ノード障害をトリガーします。
9. Perform steps 9 through 14 in Section 7.2, "Head-End PLR with Link Failure".
9. 7.2項「リンク障害のあるヘッドエンドPLR」の手順9から14を実行します。
It is RECOMMENDED that this procedure be repeated for each of the node failure triggers defined in Section 5.1.
この手順は、セクション5.1で定義されているノード障害トリガーごとに繰り返すことをお勧めします。
Objective:
目的：
To benchmark the MPLS failover time due to node failure events described in Section 5.1 experienced by the DUT, which is the midpoint PLR.
中間点PLRである、DUTが経験したセクション5.1で説明されているノード障害イベントによるMPLSフェイルオーバー時間をベンチマークするため。
Test Setup:
テスト設定：
A. Select any one topology from Sections 6.1 to 6.2.
A.セクション6.1〜6.2からトポロジを1つ選択します。
B. The DUT will also have two interfaces connected to the traffic generator.
B. DUTには、トラフィックジェネレーターに接続された2つのインターフェイスもあります。
Test Configuration:
テスト構成：
1. Configure the number of primaries on R1 and the backups on R2 as required by the topology selected.
1. 選択したトポロジの必要に応じて、R1のプライマリとR2のバックアップの数を構成します。
2. Configure the test setup to support reversion.
2. 復帰をサポートするようにテスト設定を構成します。
3. Advertise prefixes (as per the FRR Scalability Table in Appendix A) by the tail-end.
3. 末尾でプレフィックスをアドバタイズします（付録AのFRRスケーラビリティテーブルに従って）。
Procedure:
手順：
The test case in Section 7.1.1, "Midpoint PLR Forwarding Performance", MUST be completed first to obtain the throughput to use as the offered load.
セクション7.1.1「ミッドポイントPLR転送パフォーマンス」のテストケースは、提供される負荷として使用するスループットを取得するために、最初に完了する必要があります。
1. Establish the primary LSP on R1 as required by the topology selected.
1. 選択したトポロジの必要に応じて、R1にプライマリLSPを確立します。
2. Establish the backup LSP on R2 as required by the selected topology.
2. 選択したトポロジの必要に応じて、R2にバックアップLSPを確立します。
3. Verify that the primary and backup LSPs are up and that the primary is protected.
3. プライマリLSPとバックアップLSPが起動しており、プライマリが保護されていることを確認します。
4. Verify that Fast Reroute protection is enabled and ready.
4. Fast Reroute保護が有効で準備ができていることを確認します。
5. Set up traffic streams for the offered load as described in Section 5.7.
5. セクション5.7の説明に従って、提供された負荷のトラフィックストリームを設定します。
6. Provide the offered load from the tester at the throughput [RFC1242] level obtained from the test case in Section 7.1.1.
6. セクション7.1.1のテストケースから取得したスループット[RFC1242]レベルでテスターから提供された負荷を提供します。
7. Verify that traffic is switched over the primary LSP without packet loss.
7. トラフィックがパケット損失なしでプライマリLSP経由で切り替えられることを確認します。
8. Trigger a node failure as described in Section 5.1.
8. セクション5.1の説明に従って、ノード障害をトリガーします。
9. Perform steps 9 through 14 in Section 7.2, "Head-End PLR with Link Failure".
9. 7.2項「リンク障害のあるヘッドエンドPLR」の手順9から14を実行します。
It is RECOMMENDED that this procedure be repeated for each of the node failure triggers defined in Section 5.1.
この手順は、セクション5.1で定義されているノード障害トリガーごとに繰り返すことをお勧めします。
For each test, it is RECOMMENDED that the results be reported in the following format.
テストごとに、結果を次の形式で報告することをお勧めします。
Parameter Units
パラメータ単位
IGP used for the test ISIS-TE / OSPF-TE Interface types Gige,POS,ATM,VLAN, etc.
テストに使用されるIGP ISIS-TE / OSPF-TEインターフェイスタイプGige、POS、ATM、VLANなど。
Packet Sizes offered to the DUT Bytes (at L3)
DUTバイトに提供されるパケットサイズ（at L3）
Offered Load (Throughput) Packets per second IGP routes advertised Number of IGP routes
提供される負荷（スループット）1秒あたりのパケット数アドバタイズされたIGPルートIGPルートの数
Penultimate Hop Popping Used/Not Used
最後から2番目のホップポッピングの使用/未使用
RSVP hello timers Milliseconds
RSVP helloタイマーミリ秒
Number of Protected tunnels Number of tunnels
保護されたトンネルの数トンネルの数
Number of VPN routes installed Number of VPN routes on the head-end
インストールされているVPNルートの数ヘッドエンドのVPNルートの数
Number of VC tunnels Number of VC tunnels
VCトンネルの数VCトンネルの数
Number of midpoint tunnels Number of tunnels
中点トンネル数トンネル数
Number of Prefixes protected by Number of LSPs Primary
LSPの数によって保護されているプレフィックスの数
Topology being used Section number, and figure reference
使用されているトポロジーセクション番号、および図の参照
Failover event Event type
フェイルオーバーイベントイベントタイプ
Reoptimization Yes/No
再最適化はい/いいえ
Benchmarks (to be recorded for each test case):
ベンチマーク（テストケースごとに記録される）：
Failover-Failover Time seconds Failover Packet Loss packets Additive Backup Delay seconds Out-of-Order Packets packets Duplicate Packets packets Failover Time Calculation Method Method Used
フェイルオーバー-フェイルオーバー時間秒フェイルオーバーパケット損失パケット追加バックアップ遅延秒数順序どおりでないパケットパケット重複パケットパケットフェイルオーバー時間計算方法使用される方法
Reversion-Reversion Time seconds Reversion Packet Loss packets Additive Backup Delay seconds Out-of-Order Packets packets Duplicate Packets packets Failover Time Calculation Method Method Used
Reversion-Reversion Time秒Reversionパケット損失パケットAdditive Backup Delay秒Out-of-OrderパケットパケットDuplicate Packetsパケットフェイルオーバー時間の計算方法使用される方法
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から生じるネットワークセキュリティへの影響は、ラボと実稼働ネットワークで同じである必要があります。
We would like to thank Jean Philip Vasseur for his invaluable input to the document, Curtis Villamizar for his contribution in suggesting text on the definition and need for benchmarking Correlated failures, and Bhavani Parise for his textual input and review. Additionally, we would like to thank Al Morton, Arun Gandhi, Amrit Hanspal, Karu Ratnam, Raveesh Janardan, Andrey Kiselev, and Mohan Nanduri for their formal reviews of this document.
文書への貴重な情報を提供してくれたJean Philip Vasseur、相関の失敗のベンチマークの定義と必要性に関するテキストの提案に貢献してくれたCurtis Villamizar、そして文章の入力とレビューをしてくれたBhavani Pariseに感謝します。さらに、このドキュメントの正式なレビューを提供してくれたAl Morton、Arun Gandhi、Amrit Hanspal、Karu Ratnam、Raveesh Janardan、Andrey Kiselev、およびMohan Nanduriに感謝します。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[RFC1242] Bradner、S。、「ネットワーク相互接続デバイスのベンチマーク用語」、RFC 1242、1991年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC2544] Bradner、S.およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク手法」、RFC 2544、1999年3月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P。、編、スワロー、G。、編、およびA.アトラス、編、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、2005年5月。
[RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding Benchmarking Methodology for IP Flows", RFC 5695, November 2009.
[RFC5695] Akhter、A.、Asati、R。、およびC. Pignataro、「IPフローのMPLS転送ベンチマーク手法」、RFC 5695、2009年11月。
[RFC6412] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence", RFC 6412, November 2011.
[RFC6412] Poretsky、S.、Immoff、B。、およびK. Michielsen、「ベンチマークリンクステートIGPデータプレーンルートコンバージェンスの用語」、RFC 6412、2011年11月。
[RFC6414] Poretsky, S., Papneja, R., Karthik, J., and S. Vapiwala, "Benchmarking Terminology for Protection Performance", RFC 6414, November 2011.
[RFC6414] Poretsky、S.、Papneja、R.、Karthik、J.、and S. Vapiwala、 "Benchmarking Terminology for Protection Performance"、RFC 6414、November 2011。
[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[RFC2285] Mandeville、R。、「Benchmarking Terminology for LAN Switching Devices」、RFC 2285、1998年2月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K。、編、およびY. Rekhter、編、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC4689] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, "Terminology for Benchmarking Network-layer Traffic Control Mechanisms", RFC 4689, October 2006.
[RFC4689] Poretsky、S.、Perser、J.、Erramilli、S。、およびS. Khurana、「ネットワーク層トラフィック制御メカニズムのベンチマークに関する用語」、RFC 4689、2006年10月。
This section provides the recommended numbers for evaluating the scalability of fast reroute implementations. It also recommends the typical numbers for IGP/VPNv4 Prefixes, LSP Tunnels, and VC entries. Based on the features supported by the DUT, appropriate scaling limits can be used for the testbed.
このセクションでは、高速リルート実装のスケーラビリティを評価するための推奨数を示します。また、IGP / VPNv4プレフィックス、LSPトンネル、およびVCエントリの一般的な数も推奨しています。 DUTでサポートされている機能に基づいて、適切なスケーリング制限をテストベッドに使用できます。
No. of Head-End TE Tunnels IGP Prefixes
ヘッドエンドTEトンネルIGPプレフィックスの数
1 100
１ １００
1 500
１ ５００
1 1000
１ １０００
1 2000
１ ２０００
1 5000
１ ５０００
2 (Load Balance) 100
2（ロードバランス）100
2 (Load Balance) 500
2（ロードバランス）500
2 (Load Balance) 1000
2（ロードバランス）1000
2 (Load Balance) 2000
2（ロードバランス）2000
2 (Load Balance) 5000
2（ロードバランス）5000
100 100
１００ １００
500 500
５００ ５００
1000 1000
１０００ １０００
2000 2000
２０００ ２０００
No. of Head-End TE Tunnels VPNv4 Prefixes
ヘッドエンドTEトンネルVPNv4プレフィックス数
1 100
１ １００
1 500
１ ５００
1 1000
１ １０００
1 2000
１ ２０００
1 5000
１ ５０００
1 10000
１ １００００
1 20000
１ ２００００
1 Max
1最大
2 (Load Balance) 100
2（ロードバランス）100
2 (Load Balance) 500
2（ロードバランス）500
2 (Load Balance) 1000
2（ロードバランス）1000
2 (Load Balance) 2000
2（ロードバランス）2000
2 (Load Balance) 5000
2（ロードバランス）5000
2 (Load Balance) 10000
2（ロードバランス）10000
2 (Load Balance) 20000
2（ロードバランス）20000
2 (Load Balance) Max
2（ロードバランス）最大
The number of midpoint TE LSPs could be configured at recommended levels -- 100, 500, 1000, 2000, or max supported number.
The number of midpoint TE LSPs could be configured at recommended levels -- 100, 500, 1000, 2000, or max supported number.
No. of Head-End TE Tunnels VC entries
ヘッドエンドTEトンネルVCエントリの数
1 100 1 500 1 1000 1 2000 1 Max 100 100 500 500 1000 1000 2000 2000
1 100 1 500 1 1000 1 2000 1最大100 100500 500 1000 1000 2000 2000
AIS - Alarm Indication Signal BFD - Bidirectional Fault Detection BGP - Border Gateway Protocol BKP - Backup Path and Nodes CE - Customer Edge DUT - Device Under Test FRR - Fast Reroute HE - Head-End IGP - Interior Gateway Protocol IP - Internet Protocol LOS - Loss of Signal LSP - Label Switched Path MID - Midpoint MP - Merge Point MPLS - Multiprotocol Label Switching N-Nhop - Next - Next Hop Nhop - Next Hop OIR - Online Insertion and Removal P - Provider PE - Provider Edge PHP - Penultimate Hop Popping PLBM - Packet-Loss-Based Method PLR - Point of Local Repair PRI - Primary Path RSVP - Resource reSerVation Protocol RX - Receive SRLG - Shared Risk Link Group TA - Traffic Analyzer TBM - Timestamp-Based Method TE - Traffic Engineering TG - Traffic Generator TX - Transmit UR - Upstream Router VC - Virtual Circuit VPN - Virtual Private Network
AIS-アラーム表示信号BFD-双方向障害検出BGP-ボーダーゲートウェイプロトコルBKP-バックアップパスとノードCE-カスタマーエッジDUT-テスト中のデバイスFRR-高速リルートHE-ヘッドエンドIGP-内部ゲートウェイプロトコルIP-インターネットプロトコルLOS- Loss of Signal LSP-ラベルスイッチドパスMID-ミッドポイントMP-マージポイントMPLS-マルチプロトコルラベルスイッチングN-Nhop-Next-Next Hop Nhop-Next Hop OIR-オンライン挿入および削除P-プロバイダーPE-プロバイダーエッジPHP-最後から2番目のホップポッピングPLBM-パケット損失ベースの方法PLR-ローカル修復ポイントPRI-プライマリパスRSVP-リソース再予約プロトコルRX-受信SRLG-共有リスクリンクグループTA-トラフィックアナライザーTBM-タイムスタンプベースの方法TE-トラフィックエンジニアリングTG-トラフィックジェネレーターTX-送信UR-アップストリームルーターVC-仮想回線VPN-仮想プライベートネットワーク
Authors' Addresses
著者のアドレス
Rajiv Papneja Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA EMail: rajiv.papneja@huawei.com
Rajiv Papaneja Huawei Technologies 2330 Central Expressway Santa Clara、CA 95050メールで送信：rajiv.paneja@huawei.com
Samir Vapiwala Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: svapiwal@cisco.com
Samir Vapiwala Cisco Systems 300 Beaver Brook Road Boxborough、MA 01719 USA Eメール：svapiwal@cisco.com
Jay Karthik Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: jkarthik@cisco.com
Jay Karthik Cisco Systems 300 Beaver Brook Road Boxborough、MA 01719 USA Eメール：jkarthik@cisco.com
Scott Poretsky Allot Communications 300 TradeCenter Woburn, MA 01801 USA EMail: sporetsky@allot.com
Scott Poretsky Allot Communications 300 TradeCenter Woburn、MA 01801 USAメール：sporetsky@allot.com
Shankar Rao Qwest Communications 950 17th Street Suite 1900 Denver, CO 80210 USA EMail: shankar.rao@du.edu
Shankar Rao Qwest Communications 950 17th Street Suite 1900 Denver、CO 80210 USA Eメール：shankar.rao@du.edu
JL. Le Roux France Telecom 2 av Pierre Marzin 22300 Lannion France EMail: jeanlouis.leroux@orange.com
JL。 Le Roux France Telecom 2 av Pierre Marzin 22300 Lannion Franceメール：jeanlouis.leroux@orange.com