Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 6201 C. Pignataro
Updates: 1242, 2544 F. Calabria
Category: Informational Cisco
ISSN: 2070-1721 C. Olvera
Consulintel
March 2011
Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 6201 C. Pignataro
Updates: 1242, 2544 F. Calabria
Category: Informational Cisco
ISSN: 2070-1721 C. Olvera
Consulintel
March 2011
Device Reset Characterization
器件复位特性
Abstract
摘要
An operational forwarding device may need to be restarted (automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.
出于各种原因，可能需要重新启动（自动或手动）可运行的转发设备，本文档中称为“重置”的事件。由于复位期间转发操作可能会中断，因此了解设备恢复转发操作所需的时间非常有用。
This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset test procedures beyond what is specified in RFC 2544. Therefore, it updates RFC 2544. This document also defines the benchmarking term "reset time" and, only in this, updates RFC 1242.
本文件规定了转发设备基准测试期间表征重置（和重置时间）的方法，并提供了RFC 2544规定之外的重置测试程序的清晰性和一致性。因此，它更新了RFC2544。本文件还定义了基准术语“重置时间”，并仅在此更新了RFC 1242。
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/rfc6201.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6201.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Reset Time .................................................4
1.3. Reset Time Measurement Methods .............................5
1.4. Reporting Format ...........................................6
2. Key Words to Reflect Requirements ...............................7
3. Test Requirements ...............................................7
4. Reset Tests .....................................................8
4.1. Hardware Reset Tests .......................................9
4.1.1. Routing Processor (RP) / Routing Engine Reset .......9
4.1.2. Line Card (LC) Removal and Insertion (REQUIRED) ....11
4.2. Software Reset Tests ......................................12
4.2.1. Operating System (OS) Reset (REQUIRED) .............12
4.2.2. Process Reset (OPTIONAL) ...........................13
4.3. Power Interruption Test ...................................14
4.3.1. Power Interruption (REQUIRED) ......................14
5. Security Considerations ........................................15
6. Acknowledgments ................................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................16
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Reset Time .................................................4
1.3. Reset Time Measurement Methods .............................5
1.4. Reporting Format ...........................................6
2. Key Words to Reflect Requirements ...............................7
3. Test Requirements ...............................................7
4. Reset Tests .....................................................8
4.1. Hardware Reset Tests .......................................9
4.1.1. Routing Processor (RP) / Routing Engine Reset .......9
4.1.2. Line Card (LC) Removal and Insertion (REQUIRED) ....11
4.2. Software Reset Tests ......................................12
4.2.1. Operating System (OS) Reset (REQUIRED) .............12
4.2.2. Process Reset (OPTIONAL) ...........................13
4.3. Power Interruption Test ...................................14
4.3.1. Power Interruption (REQUIRED) ......................14
5. Security Considerations ........................................15
6. Acknowledgments ................................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................16
An operational forwarding device (or one of its components) may need to be restarted for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation. In other words, the duration of the recovery time following the reset (see Section 1.2, "Reset Time") is what is in question.
出于各种原因，可能需要重新启动正在运行的转发设备（或其组件之一），在本文档中称为“重置”的事件。由于复位期间转发操作可能会中断，因此了解设备恢复转发操作所需的时间非常有用。换句话说，重置后恢复时间的持续时间（见第1.2节“重置时间”）是有疑问的。
However, the answer to this question is no longer simple and straightforward as the modern forwarding devices employ many hardware advancements (distributed forwarding, etc.) and software advancements (graceful restart, etc.) that influence the recovery time after the reset.
然而，这个问题的答案不再简单明了，因为现代转发设备采用了许多影响重置后恢复时间的硬件改进（分布式转发等）和软件改进（优雅重启等）。
This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset procedures beyond what is specified in [RFC2544]. Software upgrades involve additional benchmarking complexities and are outside the scope of this document.
本文件规定了转发设备基准测试期间表征重置（和重置时间）的方法，并提供了重置程序的清晰性和一致性，超出了[RFC2544]中的规定。软件升级涉及额外的基准测试复杂性，不在本文档范围内。
These procedures may be used by other benchmarking documents such as [RFC2544], [RFC5180], [RFC5695], etc., and it is expected that other protocol-specific benchmarking documents will reference this document for reset recovery time characterization. Specific Routing Information Base (RIB) and Forwarding Information Base (FIB) scaling considerations are outside the scope of this document and can be quite complex to characterize. However, other documents can characterize specific dynamic protocols' scaling and interactions as well as leverage and augment the reset tests defined in this document.
这些程序可用于其他基准测试文件，如[RFC2544]、[RFC5180]、[RFC5695]等，预计其他协议特定基准测试文件将参考本文件进行重置恢复时间表征。特定的路由信息库（RIB）和转发信息库（FIB）扩展考虑超出了本文档的范围，并且可能非常复杂。然而，其他文档可以描述特定动态协议的扩展和交互，以及利用和增强本文档中定义的重置测试。
This document updates Section 26.6 of [RFC2544] and defines the benchmarking term "reset time", updating [RFC1242].
本文件更新了[RFC2544]第26.6节，并定义了基准术语“重置时间”，更新了[RFC1242]。
This document focuses only on the reset criterion of benchmarking and presumes that it would be beneficial to [RFC5180], [RFC5695], and other IETF Benchmarking Methodology Working Group (BMWG) efforts.
本文件仅侧重于基准测试的重置标准，并假定其有利于[RFC5180]、[RFC5695]和其他IETF基准测试方法工作组（BMWG）的工作。
Definition
释义
Reset time is the total time that a device is determined to be out of operation and includes the time to perform the reset and the time to recover from it.
重置时间是确定设备停止运行的总时间，包括执行重置的时间和从中恢复的时间。
Discussion
讨论
During a period of time after a reset or power up, network devices may not accept and forward frames. The duration of this period of forwarding unavailability can be useful in evaluating devices. In addition, some network devices require some form of reset when specific setup variables are modified. If the reset period were long, it might discourage network managers from modifying these variables on production networks.
在重置或通电后的一段时间内，网络设备可能不接受和转发帧。转发不可用的持续时间可用于评估设备。此外，当修改特定设置变量时，某些网络设备需要某种形式的重置。如果重置周期很长，可能会阻止网络管理员在生产网络上修改这些变量。
The events characterized in this document are entire reset events. That is, the recovery period measured includes the time to perform the reset and the time to recover from it. Some reset events will be atomic (such as pressing a reset button) while others (such as power cycling) may comprise multiple actions with a recognized interval between them. In both cases, the duration considered is from the start of the event until full recovery of forwarding after the completion of the reset events.
本文档中描述的事件是整个重置事件。也就是说，测量的恢复期包括执行复位的时间和从复位中恢复的时间。一些重置事件将是原子性的（如按下重置按钮），而另一些（如电源循环）可能包括多个动作，它们之间有可识别的间隔。在这两种情况下，考虑的持续时间都是从事件开始到重置事件完成后完全恢复转发。
Measurement Units
计量单位
Time, in milliseconds, providing sufficient resolution to distinguish between different trials and different implementations. See Section 1.4.
时间，以毫秒为单位，提供足够的分辨率来区分不同的试验和不同的实现。见第1.4节。
Issues
问题
There are various types of resets: hardware resets, software resets, and power interruptions. See Section 4.
重置有多种类型：硬件重置、软件重置和电源中断。见第4节。
See Also
另见
This definition updates [RFC1242].
此定义更新[RFC1242]。
The reset time is the time during which traffic forwarding is temporarily interrupted following a reset event. Strictly speaking, this is the time over which one or more frames are lost. This definition is similar to that of "Loss of Connectivity Period" defined in [IGPConv], Section 4.
重置时间是指重置事件后暂时中断流量转发的时间。严格来说，这是一个或多个帧丢失的时间。该定义类似于[IGPConv]第4节中定义的“连接中断期”。
There are two accepted methods to measure the reset time:
测量重置时间有两种公认的方法：
1. Frame-Loss Method - This method requires test tool capability to monitor the number of lost frames. In this method, the offered stream rate (frames per second) must be known. The reset time is calculated per the equation below:
1. 帧丢失方法-此方法要求测试工具能够监控丢失帧的数量。在这种方法中，提供的流速率（每秒帧数）必须是已知的。重置时间根据以下等式计算：
Frames_lost (packets)
Reset_time = -------------------------------------
Offered_rate (packets per second)
Frames_lost (packets)
Reset_time = -------------------------------------
Offered_rate (packets per second)
2. Timestamp Method - This method requires test tool capability to timestamp each frame. In this method, the test tool timestamps each transmitted frame and monitors the received frame's timestamp. During the test, the test tool records the timestamp (Timestamp A) of the frame that was last received prior to the reset interruption and the timestamp of the first frame after the interruption stopped (Timestamp B). The difference between Timestamp B and Timestamp A is the reset time.
2. 时间戳方法-此方法要求测试工具能够为每个帧添加时间戳。在这种方法中，测试工具为每个发送的帧加上时间戳，并监视接收到的帧的时间戳。在测试期间，测试工具记录重置中断前最后接收到的帧的时间戳（时间戳A）和中断停止后第一帧的时间戳（时间戳B）。时间戳B和时间戳A之间的差异是重置时间。
The tester/operator MAY use either method for reset time measurement depending on the test tool capability. However, the Frame-Loss method SHOULD be used if the test tool is capable of (a) counting the number of lost frames per stream and (b) transmitting test frame despite the physical link status, whereas the Timestamp method SHOULD be used if the test tool is capable of (a) timestamping each frame, (b) monitoring received frame's timestamp, and (c) transmitting frames only if the physical link status is UP. That is, specific test tool capabilities may dictate which method to use. If the test tool supports both methods based on its capabilities, the tester/operator SHOULD use the one that provides more accuracy.
根据测试工具的性能，测试仪/操作员可使用任何一种方法进行重置时间测量。然而，如果测试工具能够（a）计算每个流的丢失帧数和（b）传输测试帧，而不管物理链路状态如何，则应使用帧丢失方法，而如果测试工具能够（a）给每个帧加时间戳，（b）监测接收到的帧的时间戳，以及（c），则应使用时间戳方法仅当物理链路状态为UP时发送帧。也就是说，特定的测试工具功能可能决定使用哪种方法。如果测试工具基于其功能支持两种方法，则测试人员/操作员应使用提供更高精度的方法。
All reset results are reported in a simple statement including the frame loss (if measured) and reset times.
所有重置结果都以简单的语句报告，包括帧丢失（如果测量）和重置时间。
For each test case, it is RECOMMENDED that the following parameters be reported in these units:
对于每个测试用例，建议在这些单元中报告以下参数：
Parameter Units or Examples
---------------------------------------------------------------
Parameter Units or Examples
---------------------------------------------------------------
Throughput Frames per second and bits per second
吞吐量每秒帧数和每秒比特数
Loss (average) Frames
丢失（平均）帧
Reset Time (average) Milliseconds
重置时间（平均）毫秒
Number of trials Integer count
试验次数整数计数
Protocol IPv4, IPv6, MPLS, etc.
协议IPv4、IPv6、MPLS等。
Frame Size Octets
帧大小八位组
Port Media Ethernet, Gigabit Ethernet (GbE), Packet over SONET (POS), etc.
端口媒体以太网、千兆以太网（GbE）、SONET数据包（POS）等。
Port Speed 10 Gbps, 1 Gbps, 100 Mbps, etc.
端口速度10 Gbps、1 Gbps、100 Mbps等。
Interface Encap. Ethernet, Ethernet VLAN, PPP, High-Level Data Link Control (HDLC), etc.
接口封装。以太网、以太网VLAN、PPP、高级数据链路控制（HDLC）等。
For mixed protocol environments, frames SHOULD be distributed between all the different protocols. The distribution MAY approximate the network conditions of deployment. In all cases, the details of the mixed protocol distribution MUST be included in the reporting.
对于混合协议环境，帧应该分布在所有不同的协议之间。分布可能近似于部署的网络条件。在所有情况下，报告中必须包括混合协议分发的详细信息。
Additionally, the DUT (Device Under Test) or SUT (System Under Test) and test bed provisioning, port and line-card arrangement, configuration, and deployed methodologies that may influence the overall reset time MUST be listed. (Refer to the additional factors listed in Section 3).
此外，必须列出可能影响整体复位时间的DUT（被测设备）或SUT（被测系统）和试验台供应、端口和线路卡安排、配置和部署方法。（参考第3节中列出的其他因素）。
The reporting of results MUST regard repeatability considerations from Section 4 of [RFC2544]. It is RECOMMENDED to perform multiple trials and report average results.
结果报告必须考虑[RFC2544]第4节中的重复性考虑。建议进行多次试验并报告平均结果。
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, RFC 2119 [RFC2119]. RFC 2119 defines the use of these key words to help make the intent of Standards-Track documents as clear as possible. While this document uses these keywords, this document is not a Standards-Track document.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。RFC 2119定义了这些关键词的使用，以帮助尽可能明确标准跟踪文档的意图。虽然本文档使用这些关键字，但本文档不是标准跟踪文档。
Tests SHOULD first be performed such that the forwarding state re-establishment is independent from an external source (i.e., using static address resolution, routing and forwarding configuration, and not dynamic protocols). However, tests MAY subsequently be performed using dynamic protocols that the forwarding state depends on (e.g., dynamic Interior Gateway Protocols (IGP), Address Resolution Protocol (ARP), PPP Control Protocols, etc.). The considerations in this section apply.
首先应执行测试，以使转发状态重建独立于外部源（即，使用静态地址解析、路由和转发配置，而不是动态协议）。然而，随后可以使用转发状态所依赖的动态协议（例如，动态内部网关协议（IGP）、地址解析协议（ARP）、PPP控制协议等）来执行测试。本节中的注意事项适用。
In order to provide consistence and fairness while benchmarking a set of different DUTs, the Network tester/operator MUST (a) use identical control and data plane information during testing and (b) document and report any factors that may influence the overall time after reset/convergence.
为了在对一组不同DUT进行基准测试时提供一致性和公平性，网络测试人员/运营商必须（a）在测试期间使用相同的控制和数据平面信息，以及（b）记录和报告可能影响重置/会聚后总时间的任何因素。
Some of these factors include the following:
其中一些因素包括：
1. Type of reset - hardware (line-card crash, etc.) versus software (protocol reset, process crash, etc.) or even complete power failures
1. 重置类型-硬件（线路卡崩溃等）与软件（协议重置、进程崩溃等）甚至完全断电
2. Manual versus automatic reset
2. 手动与自动复位
3. Scheduled versus non-scheduled reset
3. 计划重置与非计划重置
4. Local versus remote reset
4. 本地与远程重置
5. Scale - Number of line cards present versus in use
5. 刻度-存在的线卡数量与使用中的线卡数量
6. Scale - Number of physical and logical interfaces
6. Scale—物理和逻辑接口的数量
7. Scale - Number of routing protocol instances
7. Scale—路由协议实例数
8. Scale - Number of routing table entries
8. Scale—路由表项的数目
9. Scale - Number of route processors available
9. Scale—可用路由处理器的数量
10. Performance - Redundancy strategy deployed for route processors and line cards
10. 性能-为路由处理器和线路卡部署冗余策略
11. Performance - Interface encapsulation as well as achievable throughput [RFC2544]
11. 性能-接口封装以及可实现的吞吐量[RFC2544]
12. Any other internal or external factor that may influence reset time after a hardware or software reset
12. 硬件或软件复位后可能影响复位时间的任何其他内部或外部因素
The reset time is one of the key characterization results reported after each test run. While the reset time during a reset test event may be zero, there may still be effects on traffic, such as transient delay variation or increased latency. However, that is not covered and is deemed outside the scope of this document. In this case, only "no loss" is reported.
重置时间是每次测试运行后报告的关键特性结果之一。虽然重置测试事件期间的重置时间可能为零，但仍可能对流量产生影响，例如瞬时延迟变化或延迟增加。但是，本文件未涵盖该内容，且不在本文件范围内。在这种情况下，仅报告“无损失”。
This section contains descriptions of the tests that are related to the characterization of the time needed for DUTs (Devices Under Test) or SUTs (Systems Under Test) to recover from a reset. There are three types of resets considered in this document:
本节包含与DUT（被测设备）或SUT（被测系统）从复位恢复所需时间特征相关的测试说明。本文件中考虑了三种重置类型：
1. Hardware resets
1. 硬件重置
2. Software resets
2. 软件重置
3. Power interruption
3. 停电
Different types of resets potentially have a different impact on the forwarding behavior of the device. As an example, a software reset (of a routing process) might not result in forwarding interruption, whereas a hardware reset (of a line card) most likely will.
不同类型的重置可能会对设备的转发行为产生不同的影响。例如，（路由过程的）软件重置可能不会导致转发中断，而（线路卡的）硬件重置很可能会导致转发中断。
Section 4.1 describes various hardware resets, whereas Section 4.2 describes various software resets. Additionally, Section 4.3 describes power interruption tests. These sections define and characterize these resets.
第4.1节描述了各种硬件重置，而第4.2节描述了各种软件重置。此外，第4.3节描述了电源中断试验。这些章节定义和描述了这些重置。
Additionally, since device-specific implementations may vary for hardware and software type resets, it is desirable to classify each test case as "REQUIRED" or "OPTIONAL".
此外，由于特定于设备的实现可能因硬件和软件类型重置而有所不同，因此希望将每个测试用例分类为“必需”或“可选”。
A hardware reset test is a test designed to characterize the time it takes a DUT to recover from a hardware reset.
硬件重置测试是一种测试，旨在确定DUT从硬件重置中恢复所需的时间。
A hardware reset generally involves the re-initialization of one or more physical components in the DUT, but not the entire DUT.
硬件复位通常涉及DUT中一个或多个物理组件的重新初始化，而不是整个DUT。
A hardware reset is executed by the operator, for example, by physical removal of a hardware component, by pressing a reset button for the component, or by being triggered from the command line interface (CLI).
硬件重置由操作员执行，例如，通过物理移除硬件组件、按下组件的重置按钮或通过从命令行界面（CLI）触发来执行。
Reset procedures that do not require the physical removal and insertion of a hardware component are RECOMMENDED. These include using the command line interface (CLI) or a physical switch or button. If such procedures cannot be performed (e.g., because of a lack of platform support or because the corresponding test case calls for them), human operation time SHOULD be minimized across different platforms and test cases as much as possible, and variation in human operator time SHOULD also be minimized across different vendors' products as much as practical by having the same person perform the operation and by practicing the operation. Additionally, the time between removal and insertion SHOULD be recorded and reported.
建议执行不需要物理移除和插入硬件组件的重置步骤。其中包括使用命令行界面（CLI）或物理交换机或按钮。如果无法执行此类程序（例如，由于缺乏平台支持或相应的测试用例需要），则应尽可能减少不同平台和测试用例之间的人工操作时间，通过让同一人执行操作和练习操作，也应尽可能减少不同供应商产品中的人工操作时间变化。此外，应记录和报告移除和插入之间的时间。
For routers that do not contain separate Routing Processor and Line Card modules, the hardware reset tests are not performed since they are not relevant; instead, the power interruption tests MUST be performed (see Section 4.3) in these cases.
对于不包含单独路由处理器和线路卡模块的路由器，不执行硬件重置测试，因为它们不相关；相反，在这些情况下，必须进行电源中断试验（见第4.3节）。
The Routing Processor (RP) is the DUT module that is primarily concerned with Control Plane functions.
路由处理器（RP）是主要涉及控制平面功能的DUT模块。
Objective
客观的
To characterize the time needed for a DUT to recover from a Route Processor hardware reset in a single RP environment.
描述DUT在单个RP环境中从路由处理器硬件重置恢复所需的时间。
Procedure
程序
First, ensure that the RP is in a permanent state to which it will return after the reset by performing some or all of the following operational tasks: save the current DUT configuration, specify
首先，通过执行以下部分或全部操作任务，确保RP处于永久状态，复位后将返回到该状态：保存当前DUT配置，指定
boot parameters, ensure the appropriate software files are available, or perform additional operating system or hardware-related tasks.
启动参数，确保适当的软件文件可用，或执行其他操作系统或硬件相关任务。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
其次，确保在执行任何测试活动之前，DUT能够转发通信量至少15秒。流量应使用测试中使用的媒体上可能的最小帧大小，并且速率应足以使DUT达到最大转发吞吐量。这使得重置时间测量的粒度更细。
Third, perform the Route Processor (RP) hardware reset at this point. This entails, for example, physically removing the RP to later re-insert it or triggering a hardware reset by other means (e.g., command line interface, physical switch, etc.).
第三，此时执行路由处理器（RP）硬件重置。例如，这需要物理移除RP以稍后重新插入，或者通过其他方式（例如，命令行界面、物理开关等）触发硬件重置。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最后，通过记录帧丢失或时间戳（如测试工具所报告）并计算重置时间（如第1.3节所定义）来完成表征。
Reporting Format
报告格式
The reporting format is defined in Section 1.4.
报告格式见第1.4节。
Objective
客观的
To characterize the time needed for the "secondary" Route Processor (sometimes referred to as the "backup" RP) of a DUT to become active after a "primary" (or "active") Route Processor hardware reset. This process is often referred to as "RP Switchover". The characterization in this test should be done for the default DUT behavior and, if it exists, for the DUT's non-default configuration that minimizes frame loss.
描述DUT的“次要”路由处理器（有时称为“备份”RP）在“主要”（或“活动”）路由处理器硬件复位后变为活动所需的时间。该过程通常被称为“RP切换”。本测试中的特性描述应针对默认DUT行为进行，如果存在，应针对DUT的非默认配置进行，以最大限度地减少帧丢失。
Procedure
程序
This test characterizes RP Switchover. Many implementations allow for optimized switchover capabilities that minimize the downtime during the actual switchover. This test consists of two sub-cases from a switchover characteristic's standpoint: first, a default behavior (with no switchover-specific configurations) and, potentially second, a non-default behavior with switchover configuration to minimize frame loss. Therefore, the procedures hereby described are executed twice and reported separately.
本试验的特点是RP切换。许多实现允许优化切换功能，从而最大限度地减少实际切换过程中的停机时间。从切换特性的角度来看，该测试由两个子案例组成：第一，默认行为（无特定切换配置），第二，可能是非默认行为，具有切换配置以最小化帧丢失。因此，此处描述的程序执行两次并单独报告。
First, ensure that the RPs are in a permanent state such that the secondary RP will be activated to the same state as the active RP by performing some or all of the following operational tasks: save the current DUT configuration, specify boot parameters, ensure the appropriate software files are available, or perform additional operating system or hardware-related tasks.
首先，确保RPs处于永久状态，以便通过执行以下部分或全部操作任务将辅助RP激活至与激活RP相同的状态：保存当前DUT配置，指定引导参数，确保适当的软件文件可用，或执行其他操作系统或硬件相关任务。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
其次，确保在执行任何测试活动之前，DUT能够转发通信量至少15秒。流量应使用测试中使用的媒体上可能的最小帧大小，并且速率应足以使DUT达到最大转发吞吐量。这使得重置时间测量的粒度更细。
Third, perform the primary Route Processor (RP) hardware reset at this point. This entails, for example, physically removing the RP or triggering a hardware reset by other means (e.g., command line interface, physical switch, etc.). It is up to the operator to decide whether or not the primary RP needs to be re-inserted after a grace period.
第三，此时执行主路由处理器（RP）硬件重置。例如，这需要物理移除RP或通过其他方式（例如，命令行界面、物理交换机等）触发硬件重置。由操作员决定是否需要在宽限期后重新插入主RP。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最后，通过记录帧丢失或时间戳（如测试工具所报告）并计算重置时间（如第1.3节所定义）来完成表征。
Reporting Format
报告格式
The reset results are potentially reported twice, one for the default switchover behavior (i.e., the DUT without any switchover-specific enhanced configuration) and the other for the switchover-specific behavior if it exists (i.e., the DUT configured for optimized switchover capabilities that minimize the downtime during the actual switchover).
重置结果可能会报告两次，一次用于默认切换行为（即，DUT没有任何特定于切换的增强配置），另一次用于特定于切换的行为（如果存在）（即，DUT配置为优化切换能力，以最大限度地减少实际切换期间的停机时间）。
The reporting format is defined in Section 1.4 and also includes any specific redundancy scheme in place.
报告格式在第1.4节中定义，还包括任何特定的冗余方案。
The Line Card (LC) is the DUT component that is responsible for packet forwarding.
线路卡（LC）是负责数据包转发的DUT组件。
Objective
客观的
To characterize the time needed for a DUT to recover from a line-card removal and insertion event.
描述DUT从线路卡移除和插入事件中恢复所需的时间。
Procedure
程序
For this test, the line card that is being hardware-reset MUST be on the forwarding path, and all destinations MUST be directly connected.
对于此测试，正在进行硬件重置的线路卡必须位于转发路径上，并且所有目的地都必须直接连接。
First, complete some or all of the following operational tasks: save the current DUT configuration, specify boot parameters, ensure the appropriate software files are available, or perform additional operating system or hardware-related tasks.
首先，完成以下部分或全部操作任务：保存当前DUT配置，指定引导参数，确保适当的软件文件可用，或执行其他操作系统或硬件相关任务。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
其次，确保在执行任何测试活动之前，DUT能够转发通信量至少15秒。流量应使用测试中使用的媒体上可能的最小帧大小，并且速率应足以使DUT达到最大转发吞吐量。这使得重置时间测量的粒度更细。
Third, perform the Line Card (LC) hardware reset at this point. This entails, for example, physically removing the LC to later re-insert it or triggering a hardware reset by other means (e.g., CLI, physical switch, etc.).
第三，此时执行线路卡（LC）硬件重置。例如，这需要物理地移除LC以稍后重新插入，或者通过其他方式（例如CLI、物理交换机等）触发硬件重置。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最后，通过记录帧丢失或时间戳（如测试工具所报告）并计算重置时间（如第1.3节所定义）来完成表征。
Reporting Format
报告格式
The reporting format is defined in Section 1.4.
报告格式见第1.4节。
A software reset test characterizes the time needed for a DUT to recover from a software reset.
软件重置测试表征DUT从软件重置中恢复所需的时间。
In contrast to a hardware reset, a software reset involves only the re-initialization of the execution, data structures, and partial state within the software running on the DUT module(s).
与硬件重置相反，软件重置仅涉及DUT模块上运行的软件内执行、数据结构和部分状态的重新初始化。
A software reset is initiated, for example, from the DUT's CLI.
例如，从DUT的CLI启动软件复位。
Objective
客观的
To characterize the time needed for a DUT to recover from an operating system (OS) software reset.
描述DUT从操作系统（OS）软件重置中恢复所需的时间。
Procedure
程序
First, complete some or all of the following operational tasks: save the current DUT configuration, specify software boot parameters, ensure the appropriate software files are available, or perform additional operating system tasks.
首先，完成以下部分或全部操作任务：保存当前DUT配置，指定软件引导参数，确保适当的软件文件可用，或执行其他操作系统任务。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
其次，确保在执行任何测试活动之前，DUT能够转发通信量至少15秒。流量应使用测试中使用的媒体上可能的最小帧大小，并且速率应足以使DUT达到最大转发吞吐量。这使得重置时间测量的粒度更细。
Third, trigger an operating system re-initialization in the DUT by operational means such as use of the DUT's CLI or other management interface.
第三，通过诸如使用DUT的CLI或其他管理接口等操作手段触发DUT中的操作系统重新初始化。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最后，通过记录帧丢失或时间戳（如测试工具所报告）并计算重置时间（如第1.3节所定义）来完成表征。
Reporting Format
报告格式
The reporting format is defined in Section 1.4.
报告格式见第1.4节。
Objective
客观的
To characterize the time needed for a DUT to recover from a software process reset.
描述DUT从软件过程重置中恢复所需的时间。
Such a time period may depend upon the number and types of processes running in the DUT and which ones are tested. Different implementations of forwarding devices include various common processes. A process reset should be performed only in the processes most relevant to the tester and most impactful to forwarding.
这一时间段可能取决于DUT中运行的进程的数量和类型，以及测试哪些进程。转发设备的不同实现包括各种公共过程。仅在与测试仪最相关且对转发影响最大的过程中执行过程重置。
Procedure
程序
First, complete some or all of the following operational tasks: save the current DUT configuration, specify software parameters or environmental variables, or perform additional operating system tasks.
首先，完成以下部分或全部操作任务：保存当前DUT配置，指定软件参数或环境变量，或执行其他操作系统任务。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
其次，确保在执行任何测试活动之前，DUT能够转发通信量至少15秒。流量应使用测试中使用的媒体上可能的最小帧大小，并且速率应足以使DUT达到最大转发吞吐量。这使得重置时间测量的粒度更细。
Third, trigger a process reset for each process running in the DUT and considered for testing from a management interface (e.g., by means of the CLI, etc.).
第三，触发DUT中运行的每个进程的进程重置，并考虑从管理接口（例如，通过CLI等）进行测试。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最后，通过记录帧丢失或时间戳（如测试工具所报告）并计算重置时间（如第1.3节所定义）来完成表征。
Reporting Format
报告格式
The reporting format is defined in Section 1.4 and is used for each process running in the DUT and tested. Given the implementation nature of this test, details of the actual process tested should be included along with the statement.
报告格式在第1.4节中定义，并用于DUT中运行和测试的每个过程。鉴于此测试的实现性质，测试的实际过程的细节应与声明一起包含。
"Power interruption" refers to the complete loss of power on the DUT. It can be viewed as a special case of a hardware reset, triggered by the loss of the power supply to the DUT or its components, and is characterized by the re-initialization of all hardware and software in the DUT.
“电源中断”是指DUT完全断电。可将其视为硬件复位的特殊情况，由DUT或其组件的电源中断触发，其特征是DUT中所有硬件和软件的重新初始化。
Objective
客观的
To characterize the time needed for a DUT to recover from a complete loss of electric power or complete power interruption. This test simulates a complete power failure or outage and should be indicative of the DUT/SUT's behavior during such event.
描述DUT从完全断电或完全断电中恢复所需的时间。该试验模拟完全断电或断电，并应指示DUT/SUT在此类事件中的行为。
Procedure
程序
First, ensure that the entire DUT is at a permanent state to which it will return after the power interruption by performing some or all of the following operational tasks: save the current DUT configuration, specify boot parameters, ensure the appropriate software files are available, or perform additional operating system or hardware-related tasks.
首先，通过执行以下部分或全部操作任务，确保整个DUT处于永久状态，断电后将返回到该状态：保存当前DUT配置，指定引导参数，确保适当的软件文件可用，或执行其他操作系统或硬件相关任务。
Second, ensure that the DUT is able to forward the traffic for at least 15 seconds before any test activities are performed. The traffic should use the minimum frame size possible on the media used in the testing, and the rate should be sufficient for the DUT to attain the maximum forwarding throughput. This enables a finer granularity in the reset time measurement.
其次，确保在执行任何测试活动之前，DUT能够转发通信量至少15秒。流量应使用测试中使用的媒体上可能的最小帧大小，并且速率应足以使DUT达到最大转发吞吐量。这使得重置时间测量的粒度更细。
Third, interrupt the power (AC or DC) that feeds the corresponding DUT's power supplies at this point. This entails, for example, physically removing the power supplies in the DUT to later re-insert them or simply disconnecting or switching off their power feeds (AC or DC, as applicable). The actual power interruption should last at least 15 seconds.
第三，此时中断向相应DUT电源供电的电源（AC或DC）。例如，这需要实际移除DUT中的电源，以便稍后重新插入，或者简单地断开或关闭其电源馈线（AC或DC，如适用）。实际电源中断应至少持续15秒。
Finally, complete the characterization by recording the frame loss or timestamps (as reported by the test tool) and calculating the reset time (as defined in Section 1.3).
最后，通过记录帧丢失或时间戳（如测试工具所报告）并计算重置时间（如第1.3节所定义）来完成表征。
For easier comparison with other testing, 15 seconds are removed from the reported reset time.
为便于与其他测试进行比较，从报告的重置时间中删除15秒。
Reporting Format
报告格式
The reporting format is defined in Section 1.4.
报告格式见第1.4节。
Benchmarking activities, as described in this document, 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.
基准网络拓扑将是一个独立的测试设置，不得连接到可能将测试流量转发到生产网络或将流量错误路由到测试管理网络的设备。
Furthermore, benchmarking is performed on a "black-box" basis, relying solely on measurements observable externally 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对网络安全的任何影响应在实验室和生产网络中相同。
There are no specific security considerations within the scope of this document.
本文件范围内没有具体的安全注意事项。
The authors would like to thank Ron Bonica, who motivated us to write this document. The authors would also like to thank Al Morton, Andrew Yourtchenko, David Newman, John E. Dawson, Timmons C. Player, Jan Novak, Steve Maxwell, Ilya Varlashkin, and Sarah Banks for providing thorough review, useful suggestions, and valuable input.
作者要感谢Ron Bonica，是他激励我们撰写本文。作者还要感谢Al Morton、Andrew Yourtchenko、David Newman、John E.Dawson、Timmons C.Player、Jan Novak、Steve Maxwell、Ilya Varlashkin和Sarah Banks提供了全面的审查、有用的建议和宝贵的意见。
[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月。
[IGPConv] Poretsky, S., Imhoff, B., and K. Michielsen, "Benchmarking Methodology for Link-State IGP Data Plane Route Convergence", Work in Progress, February 2011.
[IGPConv]Poretsky，S.，Imhoff，B.，和K.Michielsen，“链路状态IGP数据平面路由收敛的基准测试方法”，正在进行的工作，2011年2月。
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, May 2008.
[RFC5180]Popoviciu，C.，Hamza，A.，Van de Velde，G.，和D.Dugatkin，“网络互连设备的IPv6基准测试方法”，RFC 51802008年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月。
Authors' Addresses
作者地址
Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 USA
Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
EMail: rajiva@cisco.com
EMail: rajiva@cisco.com
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA
Carlos Pignataro思科系统7200-12美国北卡罗来纳州Kit Creek路研究三角公园，邮编27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com
Fernando Calabria Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA
费尔南多·卡拉布里亚思科系统7200-12美国北卡罗来纳州基特克里克路研究三角公园，邮编27709
EMail: fcalabri@cisco.com
EMail: fcalabri@cisco.com
Cesar Olvera Morales Consulintel Joaquin Turina, 2 Pozuelo de Alarcon, Madrid, E-28224 Spain
塞萨尔·奥尔维拉·莫拉莱斯（Cesar Olvera Morales）都灵领事馆，2 Pozuelo de Alarcon，马德里，E-28224西班牙
EMail: cesar.olvera@consulintel.es
EMail: cesar.olvera@consulintel.es