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
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快速重路由（FRR）保护机制的基准测试方法。本文档提供了测试方法和测试台设置，用于测量快速重路由技术的故障切换时间，同时考虑可能影响绑定到MPLS流量工程（MPLS-TE）隧道的实时应用程序恢复时间的因素（如底层链路）。
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/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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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
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.
影响服务可用性的因素有两个：故障频率和故障持续时间。故障可进一步分为两类：相关故障和不相关故障。相关和不相关故障可能是计划内或计划外的。
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.
计划的失败通常是可预测的。网络实施应能够处理计划内和计划外故障，并在一个时间范围内正常恢复，以维护服务保证。因此，故障切换恢复时间是服务提供商在为其网络基础架构选择构建块时考虑的最重要基准之一。
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层（L2）链路）由于对失效的公共物理资源（例如，公共管道）的依赖而失效。在MPLS保护机制的上下文中，由共享风险链路组（SRLGs）[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-TE保护机制相关的测试场景（当应用于MPLS传输配置文件和应用于MPLS网络的IP快速重路由时），这些场景不在本文档的范围之内。然而，考虑到基于MPLS的L3和L2服务的测试设置考虑LDP超过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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。[RFC2119]主要为标准跟踪文件定义了这些关键词的使用，而本信息性文件使用了其中一些关键词。
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 |---------+ |
| |----------------------+
+--------+
+---------------------------+
| +------------|---------------+
| | | |
| | | |
+--------+ +--------+ +--------+ +--------+ +--------+
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:
标签堆栈依赖于以下三个实体：
(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) 从局部修复点（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.
到备份隧道的故障切换主要由本地修复点（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的远程侧接口关闭-带BFD的PLR侧接口关闭-带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 hellos。这些方法可用于基于以太网的链路所需的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.
使用数据包丢失计算故障转移时间的另一个好处是，它允许使用黑盒测试环境。以线路速率向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。请参阅[RCFC1212]为IGP选项考虑和报告。
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.
建议存在三个或三个以上的交通流，只要所有的交通流都有稳定且恒定的流量。为了监控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中的关键，对分布在路由表中的路由特定流进行测试将揭示这种依赖性。不建议向受保护隧道可到达的所有前缀生成通信量（可能以循环方式，其中通信量以循环方式一次发送到除一个前缀以外的所有前缀）。不建议对所有前缀生成循环通信量，因为命中所有前缀的时间可能高于故障切换时间。这种现象会降低测量结果的粒度，并且观察到的结果可能不准确。
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.
测试仪可能能够进行非数据平面收敛观测，并将这些观测用于测量。
Failover time [RFC6414] is calculated using one of the following three methods:
故障转移时间[RFC6414]使用以下三种方法之一计算：
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）：（每秒丢弃的数据包数*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）：这种故障转移计算方法基于时间戳，该时间戳作为有效负载在生成器发起的数据包中传输。流量分析器记录故障转移事件之前接收到的最后一个数据包和故障转移事件之后接收到的第一个数据包的时间戳，并根据这两个时间戳之间的差异得出时间。注意：有效负载还可能包含无序数据包计算和重复数据包的序列号。
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处的标签堆栈。可使用倒数第二跳弹出（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) 他是前端b）T/E是后端c）中间是中点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+--------+
+-------+ +--------+ +--------+
| 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流量（P-P）0 0第3层VPN（PE-PE）1第3层VPN（PE-P）2第2层VC（PE-PE）1第2层VC（PE-P）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) 对于P-P情况，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 |
+--------+
+-------+ +--------+ +--------+
| 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流量（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中点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) 对于P-P情况，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+--------+ +--------+
+--------+ +--------+ +--------+ +--------+
| 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流量（P-P）1 1第3层VPN（PE-PE）2第3层VPN（PE-P）3 3第2层VC（PE-PE）2第2层VC（PE-P）3 3中点LSP 1 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) 对于P-P情况，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 |
+--------+
+--------+ +--------+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流量（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中点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) 对于P-P情况，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 |
-----------------------------
+--------+ +--------+ +--------+ +--------+
| 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流量（P-P）10 Layer3 VPN（PE-PE）2 Layer3 VPN（PE-P）3 2 Layer2 VC（PE-PE）2 1 Layer2 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) 对于P-P情况，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 |
+--------+
+--------+ +--------+ +--------+ +--------+
| 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流量（P-P）1 1第3层VPN（PE-PE）2 2第3层VPN（PE-P）3 3第2层VC（PE-PE）2第2层VC（PE-P）3 3 3中点LSP 1 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) 对于P-P情况，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| |
--------------------------
+--------+ +--------+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流量（P-P）1 1第3层VPN（PE-PE）2 2第3层VPN（PE-P）3 3第2层VC（PE-PE）2第2层VC（PE-P）3 3 3中点LSP 1 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) 对于P-P情况，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 |
+--------+
+--------+ +--------+ +--------+ +--------+ +--------+
| 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流量（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中点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) 对于P-P情况，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.
本节中描述的程序可应用于所有八个基本测试用例和相关拓扑。备份隧道和主隧道在带宽使用方面配置相同。为了使用所有可能适用的标签堆栈深度（如当前部署所示）对故障转移进行基准测试，建议执行本节中提供的所有测试用例。在执行故障转移测试用例之前，必须先执行第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）为单位进行测量。本节提供了两个测试用例来测试转发性能。这些是DUT配置为前端PLR、中点PLR和出口PLR。
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节的八个拓扑中选择任意一个拓扑。
B. Select or enable IP, L3 VPN, or L2 VPN services with the DUT as head-end PLR.
B.选择或启用IP、L3 VPN或L2 VPN服务，DUT作为前端PLR。
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还有两个接口连接到流量发生器/分析仪。（如果PLR下游的节点不是模拟节点，则隧道入口应有一条连接到流量发生器的链路，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是否启动，以及主LSP是否受保护。
4. Verify that Fast Reroute protection is enabled and ready.
4. 验证快速重路由保护已启用并准备就绪。
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. 在主LSP上以DUT支持的吞吐量发送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. 验证提供的负载是否映射到备份通道，并测量附加备份延迟[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. 调整提供的负载并重复步骤6至10，直到主LSP和备份LSP的吞吐量值相等。
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节的八个拓扑中选择任意一个拓扑。
B. The DUT will also have two interfaces connected to the traffic generator.
B.DUT还将有两个接口连接至流量发生器。
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是否启动，以及主LSP是否受保护。
4. Verify that Fast Reroute protection is enabled and ready.
4. 验证快速重路由保护已启用并准备就绪。
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. 在主LSP上以DUT支持的吞吐量发送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. 验证提供的负载是否映射到备份通道，并测量附加备份延迟[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. 调整提供的负载并重复步骤6至10，直到主LSP和备份LSP的吞吐量值相等。
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.
由于DUT（前端PLR）经历第5.1节中所述的链路故障事件，对MPLS故障切换时间进行基准测试。
Test Setup:
测试设置：
A. Select any one topology out of the eight from Section 6.
A.从第6节的八个拓扑中选择任意一个拓扑。
B. Select or enable IP, L3 VPN, or L2 VPN services with the DUT as head-end PLR.
B.选择或启用IP、L3 VPN或L2 VPN服务，DUT作为前端PLR。
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还有两个接口连接到流量发生器/分析仪。（如果PLR下游的节点不是模拟节点，则隧道入口应有一条连接至流量发生器的链路，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是否启动，以及主LSP是否受保护。
4. Verify that Fast Reroute protection is enabled and ready.
4. 验证快速重路由保护已启用并准备就绪。
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. 验证提供的负载是否映射到备份通道，并测量附加备份延迟[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.
由于DUT（中点PLR）在第5.1节中所述的链路故障事件，对MPLS故障切换时间进行基准测试。
Test Setup:
测试设置：
A. Select any one topology out of the eight from Section 6.
A.从第6节的八个拓扑中选择任意一个拓扑。
B. The DUT will also have two interfaces connected to the traffic generator.
B.DUT还将有两个接口连接至流量发生器。
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.
由于DUT（前端PLR）在第5.1节中所述的节点故障事件，对MPLS故障切换时间进行基准测试。
Test Setup:
测试设置：
A. Select any one topology out of the eight from Section 6.
A.从第6节的八个拓扑中选择任意一个拓扑。
B. Select or enable IP, L3 VPN, or L2 VPN services with the DUT as head-end PLR.
B.选择或启用IP、L3 VPN或L2 VPN服务，DUT作为前端PLR。
C. The DUT will also have two interfaces connected to the traffic generator/analyzer.
C.DUT还有两个接口连接到流量发生器/分析仪。
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是否启动，以及主LSP是否受保护。
4. Verify that Fast Reroute protection is enabled and ready.
4. 验证快速重路由保护已启用并准备就绪。
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.
由于DUT（中点PLR）在第5.1节中所述的节点故障事件，对MPLS故障切换时间进行基准测试。
Test Setup:
测试设置：
A. Select any one topology from Sections 6.1 to 6.2.
A.从第6.1节到第6.2节中选择任意一种拓扑。
B. The DUT will also have two interfaces connected to the traffic generator.
B.DUT还将有两个接口连接至流量发生器。
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是否启动，以及主LSP是否受保护。
4. Verify that Fast Reroute protection is enabled and ready.
4. 验证快速重路由保护已启用并准备就绪。
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.
用于测试ISIS-TE/OSPF-TE接口类型Gige、POS、ATM、VLAN等的IGP。
Packet Sizes offered to the DUT Bytes (at L3)
提供给DUT字节的数据包大小（在L3）
Offered Load (Throughput) Packets per second
每秒提供的负载（吞吐量）数据包
IGP routes advertised Number of IGP routes
IGP路线广告IGP路线的数量
Penultimate Hop Popping Used/Not Used
倒数第二跳已使用/未使用
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
恢复恢复时间秒恢复数据包丢失数据包添加备份延迟秒顺序错误数据包重复数据包故障转移时间计算方法使用
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、Ravesh Janardan、Andrey Kiselev和Mohan Nanduri对本文件的正式审查。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[RFC1242]Bradner，S.，“网络互连设备的基准术语”，RFC1242，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]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年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 56952009年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.，Imhoff，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.，和S.Vapiwala，“保护性能的基准术语”，RFC 6414，2011年11月。
[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[RFC2285]Mandeville，R.，“局域网交换设备的基准术语”，RFC 22852998年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.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（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 100
1 500
1 500
1 1000
1 1000
1 2000
1 2000
1 5000
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
100 100
500 500
500 500
1000 1000
1000 1000
2000 2000
2000 2000
No. of Head-End TE Tunnels VPNv4 Prefixes
VPNv4前缀的前端数量
1 100
1 100
1 500
1 500
1 1000
1 1000
1 2000
1 2000
1 5000
1 5000
1 10000
1 10000
1 20000
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.
中点TE LSP的数量可以配置为建议的级别—100、500、1000、2000或支持的最大数量。
No. of Head-End TE Tunnels VC entries
首端隧道数目
1 100 1 500 1 1000 1 2000 1 Max 100 100 500 500 1000 1000 2000 2000
1100 1500 1 1000 1 2000 1最大100 500 500 1000 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-信号丢失LSP-标签交换路径中点MP-合并点MPLS-多协议标签交换N-Nhop-下一跳Nhop-下一跳OIR-在线插入和删除P-提供商PE-提供商边缘PHP-倒数第二跳弹出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 Papneya华为技术公司2330美国加利福尼亚州圣克拉拉中央高速公路95050电子邮件：Rajiv。papneja@huawei.com
Samir Vapiwala Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: svapiwal@cisco.com
Samir Vapiwala Cisco Systems美国马萨诸塞州Boxborough市比弗布鲁克路300号邮编01719电子邮件：svapiwal@cisco.com
Jay Karthik Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: jkarthik@cisco.com
Jay Karthik Cisco Systems美国马萨诸塞州Boxborough市比弗布鲁克路300号邮编01719电子邮件：jkarthik@cisco.com
Scott Poretsky Allot Communications 300 TradeCenter Woburn, MA 01801 USA EMail: sporetsky@allot.com
Scott Poretsky Allot Communications 300美国马萨诸塞州沃本贸易中心01801电子邮件：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美国科罗拉多州丹佛市第17街1900号套房邮编：80210电子邮件：Shankar。rao@du.edu
JL. Le Roux France Telecom 2 av Pierre Marzin 22300 Lannion France EMail: jeanlouis.leroux@orange.com
JL。法国勒鲁电信2号av Pierre Marzin 22300 Lannion France电子邮件：jeanlouis。leroux@orange.com