Network Working Group A. Akhter
Request for Comments: 5695 R. Asati
Category: Informational C. Pignataro
Cisco Systems
November 2009
Network Working Group A. Akhter
Request for Comments: 5695 R. Asati
Category: Informational C. Pignataro
Cisco Systems
November 2009
MPLS Forwarding Benchmarking Methodology for IP Flows
IP流的MPLS转发基准测试方法
Abstract
摘要
This document describes a methodology specific to the benchmarking of Multiprotocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows. It builds upon the tenets set forth in RFC 2544, RFC 1242, and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm.
本文档描述了一种特定于多协议标签交换（MPLS）转发设备基准测试的方法，仅限于最常见的MPLS数据包转发场景和每个场景的延迟测量，并考虑了IP流。它建立在RFC 2544、RFC 1242和其他IETF基准方法工作组（BMWG）工作中规定的原则基础上。本文档旨在将这些工作扩展到MPLS范式。
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 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
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，其衍生作品可能会
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.
不得在IETF标准流程之外创建，除非将其格式化以RFC形式发布，或将其翻译成英语以外的语言。
Table of Contents
目录
1. Introduction ....................................................2
2. Document Scope ..................................................3
3. Key Words To Reflect Requirements ...............................4
4. Test Methodology ................................................4
4.1. Test Considerations ........................................5
4.1.1. Abbreviations Used ..................................5
4.1.2. IGP Support .........................................6
4.1.3. Label Distribution Support ..........................6
4.1.4. Frame Formats .......................................7
4.1.5. Frame Sizes .........................................9
4.1.6. Time-to-Live (TTL) or Hop Limit ....................12
4.1.7. Trial Duration .....................................12
4.1.8. Traffic Verification ...............................12
4.1.9. Address Resolution and Dynamic Protocol State ......13
5. Reporting Format ...............................................13
6. MPLS Forwarding Benchmarking Tests .............................14
6.1. Throughput ................................................15
6.1.1. Throughput for MPLS Label Push .....................16
6.1.2. Throughput for MPLS Label Swap .....................17
6.1.3. Throughput for MPLS Label Pop (Unlabeled) ..........18
6.1.4. Throughput for MPLS Label Pop (Aggregate) ..........19
6.1.5. Throughput for MPLS Label Pop (PHP) ................20
6.2. Latency Measurement .......................................21
6.3. Frame-Loss Rate (FLR) Measurement .........................22
6.4. System Recovery ...........................................23
6.5. Reset .....................................................23
7. Security Considerations ........................................25
8. Acknowledgement ................................................25
9. References .....................................................25
9.1. Normative References ......................................25
9.2. Informative References ....................................26
1. Introduction ....................................................2
2. Document Scope ..................................................3
3. Key Words To Reflect Requirements ...............................4
4. Test Methodology ................................................4
4.1. Test Considerations ........................................5
4.1.1. Abbreviations Used ..................................5
4.1.2. IGP Support .........................................6
4.1.3. Label Distribution Support ..........................6
4.1.4. Frame Formats .......................................7
4.1.5. Frame Sizes .........................................9
4.1.6. Time-to-Live (TTL) or Hop Limit ....................12
4.1.7. Trial Duration .....................................12
4.1.8. Traffic Verification ...............................12
4.1.9. Address Resolution and Dynamic Protocol State ......13
5. Reporting Format ...............................................13
6. MPLS Forwarding Benchmarking Tests .............................14
6.1. Throughput ................................................15
6.1.1. Throughput for MPLS Label Push .....................16
6.1.2. Throughput for MPLS Label Swap .....................17
6.1.3. Throughput for MPLS Label Pop (Unlabeled) ..........18
6.1.4. Throughput for MPLS Label Pop (Aggregate) ..........19
6.1.5. Throughput for MPLS Label Pop (PHP) ................20
6.2. Latency Measurement .......................................21
6.3. Frame-Loss Rate (FLR) Measurement .........................22
6.4. System Recovery ...........................................23
6.5. Reset .....................................................23
7. Security Considerations ........................................25
8. Acknowledgement ................................................25
9. References .....................................................25
9.1. Normative References ......................................25
9.2. Informative References ....................................26
Over the past several years, there has been an increase in the use of MPLS as a forwarding architecture in new and existing network designs. MPLS, defined in [RFC3031], is a foundation technology and the basis for many advanced technologies such as Layer 3 MPLS VPNs, Layer 2 MPLS VPNs, and MPLS Traffic Engineering.
在过去几年中，在新的和现有的网络设计中，越来越多地使用MPLS作为转发架构。MPLS是[RCF303]中定义的一种基础技术，是第3层MPLS VPN、第2层MPLS VPN、MPLS流量工程等先进技术的基础。
However, there is no standard method defined to compare and contrast the foundational MPLS packet forwarding capabilities of network devices. This document proposes a methodology using common criteria (such as throughput, latency, frame-loss rate, system recovery, reset, etc.) to evaluate MPLS forwarding of any implementation.
然而，没有定义标准方法来比较和对比网络设备的基本MPLS包转发能力。本文档提出了一种使用通用标准（如吞吐量、延迟、帧丢失率、系统恢复、重置等）来评估任何实现的MPLS转发的方法。
The benchmarking methodology principles outlined in RFC 2544 [RFC2544] are independent of forwarding techniques; however, they don't fully address MPLS benchmarking. The workload on network forwarding device resources that MPLS forwarding places is different from that of IP forwarding; therefore, MPLS forwarding benchmarking specifics are desired.
RFC 2544[RFC2544]中概述的基准方法原则独立于转发技术；然而，它们并没有完全解决MPLS基准测试问题。MPLS转发所处的网络转发设备资源负载与IP转发不同；因此，需要MPLS转发基准测试细节。
The purpose of this document is to describe a methodology specific to the benchmarking of MPLS forwarding devices. The methods described are limited in scope to the most common MPLS packet forwarding scenarios and corresponding performance measurements in a laboratory setting. It builds upon the tenets set forth in RFC 2544 [RFC2544], RFC 1242 [RFC1242], and other IETF Benchmarking Methodology Working Group (BMWG) efforts. In other words, this document is not a replacement for, but a complement to, RFC 2544.
本文档旨在描述MPLS转发设备基准测试的特定方法。所描述的方法在范围上仅限于最常见的MPLS分组转发场景和实验室环境中的相应性能测量。它以RFC 2544[RFC2544]、RFC 1242[RFC1242]和其他IETF基准方法工作组（BMWG）工作中规定的原则为基础。换句话说，本文件不是RFC 2544的替代品，而是RFC 2544的补充。
This document focuses on the MPLS label stack [RFC3032] that has only one entry, as it is the fundamental of MPLS forwarding. It is expected that future documents may cover the benchmarking of MPLS applications such as Layer 3 VPN (L3VPN) [RFC4364], Layer 2 VPN (L2VPN) [RFC4664], Fast ReRoute [RFC4090], etc., which require more than one entry in the MPLS label stack.
本文档重点介绍只有一个条目的MPLS标签堆栈[RFC3032]，因为它是MPLS转发的基础。预计未来的文档可能涵盖MPLS应用程序的基准测试，如第3层VPN（L3VPN）[RFC4364]、第2层VPN（L2VPN）[RFC4664]、快速重路由[RFC4090]等，这些应用程序需要MPLS标签堆栈中的多个条目。
Moreover, to address the majority of current deployments' needs, this document focuses on having IP packets as the MPLS payload. In other words, label distribution for IP Forwarding Equivalence Class (FEC) [RFC3031] is prescribed (see Section 4.1.3) by this document. It is expected that future documents may focus on having non-IP packets as the MPLS payload.
此外，为了满足当前部署的大多数需求，本文档重点介绍将IP数据包作为MPLS有效负载。换句话说，本文件规定了IP转发等价类（FEC）[RFC3031]的标签分布（见第4.1.3节）。预计未来的文档可能会侧重于将非IP分组作为MPLS有效负载。
Note that the presence of an MPLS label stack does not require the length of MPLS payload (which is an IP packet, per this document) to be changed; hence, the effective maximum size of a frame can increase by Z octets (where Z = 4 x number of label stack entries), as observed in current deployments. This document focuses on benchmarking such a scenario.
注意，MPLS标签栈的存在不需要改变MPLS有效载荷的长度（根据本文档，它是IP分组）；因此，如当前部署中所观察到的，帧的有效最大大小可以增加Z个八位字节（其中Z=4 x标签堆栈条目数）。本文档的重点是对此类场景进行基准测试。
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定义了这些关键词的使用，以帮助尽可能明确标准跟踪文档的意图。虽然本文档使用这些关键字，但本文档不是标准跟踪文档。
The set of methodologies described in this document will use the topology described in this section. An effort has been made to exclude superfluous equipment needs such that each test can be carried out with a minimal number of devices. Figure 1 illustrates the sample topology in which the Device Under Test (DUT) is connected to the test ports on the test tool in accord with Figure 1 of RFC 2544.
本文档中描述的方法集将使用本节中描述的拓扑。已努力排除多余的设备需求，以便每次试验都能用最少数量的设备进行。图1说明了根据RFC 2544图1将被测设备（DUT）连接到测试工具上的测试端口的示例拓扑。
+-----------------+
+---------+ | | +---------+
| Test | | | | Test |
| Port A1 +-----+ DA1 DB1 +-----+ Port B1 |
+---------+ | | +---------+
+---------+ | DUT | +---------+
| Test | | | | Test |
| Port A2 +-----+ DA2 DB2 +-----+ Port B2 |
+---------+ | | +---------+
... | ... ... | ...
+---------+ | | +---------+
| Test | | | | Test |
| Port Ap +-----+ DAp DBp +-----+ Port Bp |
+---------+ +-----------------+ +---------+
+-----------------+
+---------+ | | +---------+
| Test | | | | Test |
| Port A1 +-----+ DA1 DB1 +-----+ Port B1 |
+---------+ | | +---------+
+---------+ | DUT | +---------+
| Test | | | | Test |
| Port A2 +-----+ DA2 DB2 +-----+ Port B2 |
+---------+ | | +---------+
... | ... ... | ...
+---------+ | | +---------+
| Test | | | | Test |
| Port Ap +-----+ DAp DBp +-----+ Port Bp |
+---------+ +-----------------+ +---------+
Figure 1: Topology for MPLS Forwarding Benchmarking
图1:MPLS转发基准测试的拓扑
A represents a Tx-side Module of the test tool, whereas B represents an Rx-side Module of the same test tool. Of course, the suffixed numbers (1, 2, ..., p) represent ports on a Module.
A代表测试工具的Tx侧模块，而B代表同一测试工具的Rx侧模块。当然，后缀数字（1，2，…，p）表示模块上的端口。
Similarly, DA represents an Rx-side Module of the DUT, whereas DB represents a Tx-side Module. The suffixed numbers (1, 2, ..., p) represent ports on a Module.
类似地，DA代表DUT的Rx侧模块，而DB代表Tx侧模块。带后缀的数字（1，2，…，p）表示模块上的端口。
p = the number of {DA, DB} pair ports on the DUT. It is determined by the maximum unidirectional forwarding throughput of the DUT and the load capacity of the port media (e.g., interface) connecting the DUT to the test tool.
p=DUT上{DA，DB}对端口的数量。它由DUT的最大单向转发吞吐量和将DUT连接到测试工具的端口介质（例如接口）的负载容量决定。
For example, if the DUT's maximum forwarding throughput is 100 frames per second (fps) and the load capacity of the port media (e.g., interface) is 50 fps, then p >= 2 is needed to sufficiently test the maximum frame forwarding.
例如，如果DUT的最大转发吞吐量为每秒100帧（fps），并且端口介质（例如，接口）的负载容量为每秒50帧，则需要p>=2来充分测试最大帧转发。
The exact throughput is a measured quantity obtained through testing. Throughput may vary depending on the number of ports used and other factors. The number of ports (p) used SHOULD be reported. Please see "Test Setup" in Section 6. Following Figure 1 from Section 6 of RFC 2544 is recommended.
准确的吞吐量是通过测试获得的测量数量。吞吐量可能因使用的端口数和其他因素而异。应报告使用的端口数（p）。请参阅第6节中的“测试设置”。建议遵循RFC 2544第6节中的图1。
This methodology assumes a full-duplex, uniform medium topology. The medium used MUST be reported in each test result. Issues regarding mixed transmission media, speed mismatches, media header differences, etc., are not under consideration. Traffic affecting features such as Flow control, Quality of Service (QoS), Graceful Restart, etc. MUST be disabled, unless explicitly requested in the test case. Additionally, any non-essential traffic MUST also be avoided.
此方法假定为全双工、统一介质拓扑。每次试验结果中必须报告所用的培养基。有关混合传输介质、速度不匹配、介质头差异等问题不在考虑之列。除非测试用例中明确要求，否则必须禁用影响流量控制、服务质量（QoS）、优雅重启等功能的流量。此外，还必须避免任何非必要的交通。
The terms used in this document remain consistent with those defined in "Benchmarking Terminology for Network Interconnect Devices" RFC 1242 [RFC1242]. This terminology SHOULD be consulted before using or applying the recommendations of this document.
本文件中使用的术语与“网络互连设备基准术语”RFC 1242[RFC1242]中定义的术语保持一致。在使用或应用本文件的建议之前，应参考本术语。
Please refer to Figure 1 for a topology view of the network. The following abbreviations are used in this document:
请参考图1以查看网络的拓扑视图。本文件中使用了以下缩写：
M := Module on a device (i.e., Line-Card or Slot; could be A or B)
M := Module on a device (i.e., Line-Card or Slot; could be A or B)
p := Port number (i.e., port on the Module; could be 1, 2, etc.)
p:=端口号（即模块上的端口；可以是1、2等）
RN := Remote Network (i.e., network that is reachable via a port of a module; could be B1RN1 or B2RN5 to mean the first network reachable via port 1 of module B, e.g., B1, or the fifth network reachable via port 2 of module B, etc.). RN is considered to be the IP Prefix FEC from the MPLS perspective.
RN:=远程网络（即，可通过模块的端口访问的网络；可以是B1RN1或B2RN5，表示可通过模块B的端口1访问的第一个网络，例如B1，或可通过模块B的端口2访问的第五个网络，等等）。从MPLS的角度来看，RN被认为是IP前缀FEC。
It is RECOMMENDED that all of the ports (A1, DA1, DB1, and A2) on the DUT and test tool support a dynamic Interior Gateway Protocol (IGP) for routing such as IS-IS, OSPF, RIP, etc. Furthermore, there are testing considerations in this document that the device be able to provide a stable control plane during heavy forwarding workloads. In particular, the procedures defined in Section 11.3 of RFC 2544 must be followed. This is to ensure that control plane instability during load conditions is not the contributing factor towards frame forwarding performance.
建议DUT和测试工具上的所有端口（A1、DA1、DB1和A2）支持用于路由的动态内部网关协议（IGP），如is-is、OSPF、RIP等。此外，本文件中还有测试考虑，即设备能够在重转发工作负载期间提供稳定的控制平面。特别是，必须遵守RFC 2544第11.3节中规定的程序。这是为了确保负载条件下的控制平面不稳定性不是影响帧转发性能的因素。
The route distribution method (OSPF, IS-IS, Enhanced Interior Gateway Routing Protocol (EIGRP), RIP, Static, etc.), if used, MUST be reported. Furthermore, if any specific configuration is used to maintain control plane stability during the test (i.e., Control Plane Protection, Control Plane Rate Limiting, etc.), then it MUST also be reported.
必须报告路由分配方法（OSPF、IS-IS、增强型内部网关路由协议（EIGRP）、RIP、静态等）（如果使用）。此外，如果在试验期间使用任何特定配置来保持控制面稳定性（即控制面保护、控制面速率限制等），则还必须报告。
The DUT and test tool must support at least one protocol for exchanging MPLS label/FEC bindings for Prefix Forwarding Equivalence Class (FEC) [RFC3031]. The DUT and test tool MUST be capable of learning and advertising MPLS label/FEC bindings via the chosen protocol(s) and use them during packet forwarding all the time (including when the label/FEC bindings change). The most commonly used protocols are Label Distribution Protocol (LDP) [RFC5036], Resource Reservation Protocol-Traffic Engineering (RSVP-TE) [RFC3209], and Border Gateway Protocol (BGP) [RFC3107].
DUT和测试工具必须至少支持一种协议，用于交换前缀转发等价类（FEC）的MPLS标签/FEC绑定[RFC3031]。DUT和测试工具必须能够通过所选协议学习和宣传MPLS标签/FEC绑定，并在数据包转发期间始终使用它们（包括标签/FEC绑定更改时）。最常用的协议是标签分发协议（LDP）[RFC5036]、资源预留协议流量工程（RSVP-TE）[RFC3209]和边界网关协议（BGP）[RFC3107]。
All of the ports (A1, DA1, DB1, B1, etc.) either on the DUT or the test tool used in the testing SHOULD support LDP, RSVP-TE, and BGP for IPv4 or IPv6 Prefix Forwarding Equivalence Classes (FECs).
DUT或测试中使用的测试工具上的所有端口（A1、DA1、DB1、B1等）都应支持IPv4或IPv6前缀转发等价类（FEC）的LDP、RSVP-TE和BGP。
Static labels SHOULD NOT be used to establish the MPLS label switched paths (LSPs), unless specified explicitly by the test case.
除非测试用例明确指定，否则不应使用静态标签来建立MPLS标签交换路径（LSP）。
This is because the use of a static label is quite uncommon in the production networks.
这是因为在生产网络中使用静态标签是非常少见的。
The IPv4 and IPv6 Explicit NULL labels (label values 0 and 2) are sometimes used to identify the payload of an MPLS packet on an LSP [RFC3032]. Explicit NULL labels are not used in the tests described in this document because the tests are limited to the use of no more than one non-reserved MPLS label in the label stack of all packets to, from, or through the DUT.
IPv4和IPv6显式空标签（标签值0和2）有时用于标识LSP上MPLS数据包的有效负载[RFC3032]。本文档中描述的测试中不使用显式空标签，因为测试仅限于在所有数据包的标签堆栈中使用一个以上的非保留MPLS标签，这些数据包往返于DUT或通过DUT。
This section explains the frame formats for IP and MPLS packets (Section 4.1.4.1), the usage of IP as the mandatory Layer 3 protocol and as the MPLS packet payload (Section 4.1.4.2), change in frame format during forwarding (Section 4.1.4.3), and recommended frame formats for the MPLS benchmarking (Section 4.1.4.4).
本节说明IP和MPLS数据包的帧格式（第4.1.4.1节）、IP作为强制性第3层协议和MPLS数据包有效载荷的使用（第4.1.4.2节）、转发期间帧格式的变化（第4.1.4.3节）以及MPLS基准测试的推荐帧格式（第4.1.4.4节）。
A test frame carrying an IP packet is illustrated in Figure 2 below. Note that RFC 2544 [RFC2544] prescribes using such a frame as the test frame over the chosen Layer 2 media.
承载IP数据包的测试帧如下图2所示。注意，RFC 2544[RFC2544]规定在选择的第2层介质上使用这样的帧作为测试帧。
+---------+--------------+-----------------------+
| Layer 2 | Layer 3 = IP | Layer 4 = UDP |
+---------+--------------+-----------------------+
+---------+--------------+-----------------------+
| Layer 2 | Layer 3 = IP | Layer 4 = UDP |
+---------+--------------+-----------------------+
Figure 2: Frame Format for IP Packets
图2:IP数据包的帧格式
Unlike a test frame carrying an IP packet, a test frame carrying an MPLS packet contains an "MPLS label stack" [RFC3032] immediately after the Layer 2 header (and before the IP header, if any) as illustrated in Figure 3 below.
与承载IP数据包的测试帧不同，承载MPLS数据包的测试帧包含一个“MPLS标签堆栈”[RFC3032]，紧跟在第2层报头之后（IP报头之前，如果有），如下图3所示。
+---------+-------+--------------+-----------------------+
| Layer 2 | MPLS | Layer 3 = IP | Layer 4 = UDP |
+---------+-------+--------------+-----------------------+
+---------+-------+--------------+-----------------------+
| Layer 2 | MPLS | Layer 3 = IP | Layer 4 = UDP |
+---------+-------+--------------+-----------------------+
Figure 3: Frame Format for MPLS Packets
图3:MPLS数据包的帧格式
The MPLS label stack is represented as a sequence of "label stack entries", where each label stack entry is 4 octets, as illustrated in Figure 1 of [RFC3032]. This document requires exactly one entry in the MPLS label stack in an MPLS packet.
MPLS标签堆栈表示为一系列“标签堆栈条目”，其中每个标签堆栈条目为4个八位字节，如[RFC3032]的图1所示。本文档要求MPLS数据包中的MPLS标签堆栈中只有一个条目。
MPLS label values used in any test case MUST be outside the reserved label value (0-15) unless stated otherwise.
除非另有说明，否则在任何测试用例中使用的MPLS标签值必须在保留标签值（0-15）之外。
This document prescribes using an IP packet as the MPLS payload (as illustrated in Figure 3 above). Generically speaking, this document mandates the test frame to include IP (either IPv4 or IPv6) as the Layer 3 protocol, in accord with Section 8 of [RFC2544] and independent of the MPLS label stack presence, for three reasons:
本文档规定使用IP数据包作为MPLS有效负载（如上图3所示）。一般而言，根据[RFC2544]第8节的规定，本文件要求测试帧将IP（IPv4或IPv6）作为第3层协议，且独立于MPLS标签堆栈的存在，原因有三：
1. This enables using IP Prefix Forwarding Equivalence Class (FEC) [RFC3031], which is a must for every MPLS network.
1. 这允许使用IP前缀转发等价类（FEC）[RFC3031]，这是每个MPLS网络必须使用的。
2. This provides the foundation or baseline for the benchmarking of various other MPLS applications such as L3VPN, L2VPN, TE-FRR, etc.
2. 这为其他各种MPLS应用（如L3VPN、L2VPN、TE-FRR等）的基准测试提供了基础或基准。
3. This enables leveraging RFC 2544 [RFC2544], which prescribes using IP packets with UDP data as the test frames. (Note that [RFC5180] also uses this prescription for IPv6 benchmarking).
3. 这使得可以利用RFC2544[RFC2544]，它规定使用具有UDP数据的IP数据包作为测试帧。（请注意，[RFC5180]也使用此处方进行IPv6基准测试）。
While the usage of non-IP payloads is possible, it requires an MPLS application, e.g., L2VPN, whose benchmarking may be covered in separate BMWG documents (MPLS L2VPN Benchmarking, for example) in the future. This is also explained in Section 2.
虽然可以使用非IP有效负载，但它需要MPLS应用程序，例如L2VPN，其基准测试可能在将来的单独BMWG文档（例如MPLS L2VPN基准测试）中介绍。第2节也对此进行了解释。
A frame carrying an IP or MPLS packet may go through any of the three MPLS forwarding operations: label push (or LSP Ingress), label swap, and label pop (or LSP Egress), as defined in [RFC3031]. It is important to understand the change of the frame format from IP to MPLS or vice versa depending on the forwarding operation.
承载IP或MPLS数据包的帧可以通过三种MPLS转发操作中的任何一种：标签推送（或LSP入口）、标签交换和标签pop（或LSP出口），如[RFC3031]中所定义。根据转发操作，了解帧格式从IP到MPLS或从MPLS到MPLS的变化非常重要。
In a label push (or LSP Ingress) operation, the DUT receives a frame containing an IP packet and forwards a frame containing an MPLS packet if the corresponding forwarding lookup for the IP destination points to a label push operation.
在标签推送（或LSP入口）操作中，如果IP目的地的相应转发查找指向标签推送操作，则DUT接收包含IP分组的帧并转发包含MPLS分组的帧。
In a label swap operation, the DUT receives a frame containing an MPLS packet and forwards a frame containing an MPLS packet if the corresponding forwarding lookup for the label value points to a label swap operation.
在标签交换操作中，如果标签值的相应转发查找指向标签交换操作，则DUT接收包含MPLS分组的帧并转发包含MPLS分组的帧。
In a label pop (or LSP Egress) operation, the DUT receives a frame containing an MPLS packet and forwards a frame containing an IP packet if the corresponding forwarding lookup for the label value points to a label pop operation.
在标签pop（或LSP出口）操作中，如果标签值的对应转发查找指向标签pop操作，则DUT接收包含MPLS分组的帧并转发包含IP分组的帧。
This document prescribes using two test frame formats to appropriately test the forwarding operations: (1) Frame format for IP and (2) Frame format for MPLS. Both formats are explained in Section 4.1.4.1. Additionally, the format of the test frame may change depending on the forwarding operation.
本文件规定使用两种测试帧格式来适当测试转发操作：（1）IP帧格式和（2）MPLS帧格式。第4.1.4.1节解释了这两种格式。此外，测试帧的格式可根据转发操作而改变。
1. For test cases involving the label push operation, the test tool must use the frame format for IP packets (Figure 2) to send the test frames to the DUT, and must use the frame format for MPLS packets (Figure 3) to receive the test frames from the DUT.
1. 对于涉及标签推送操作的测试用例，测试工具必须使用IP数据包的帧格式（图2）向DUT发送测试帧，并且必须使用MPLS数据包的帧格式（图3）从DUT接收测试帧。
2. For test cases involving the label swap operation, the test tool must use the frame format for MPLS packets (Figure 3) to send the test frames to the DUT, and must use the frame format for MPLS packets (Figure 3) to receive the test frames from the DUT.
2. 对于涉及标签交换操作的测试用例，测试工具必须使用MPLS数据包的帧格式（图3）向DUT发送测试帧，并且必须使用MPLS数据包的帧格式（图3）从DUT接收测试帧。
3. For test cases involving the label pop operation, the test tool must use the frame format for MPLS packets (Figure 3) to send the test frames to the DUT, and must use the frame format for IP packets (Figure 2) to receive the test frames from the DUT.
3. 对于涉及标签pop操作的测试用例，测试工具必须使用MPLS数据包的帧格式（图3）向DUT发送测试帧，并且必须使用IP数据包的帧格式（图2）从DUT接收测试帧。
Two types of port media are commonly deployed: Ethernet and POS (Packet Over Synchronous Optical Network). This section identifies the frame sizes that SHOULD be used for each media type, if supported by the DUT; Section 4.1.5.1 covers Ethernet and Section 4.1.5.2 covers POS.
通常部署两种类型的端口介质：以太网和POS（同步光网络上的数据包）。本节确定了DUT支持的每种媒体类型应使用的帧尺寸；第4.1.5.1节涵盖以太网，第4.1.5.2节涵盖POS。
First, it is important to note the possible increase in frame size due to the presence of an MPLS label stack in the frame (as explained in Section 4.1.4.3).
首先，需要注意的是，由于帧中存在MPLS标签堆栈，帧大小可能会增加（如第4.1.4.3节所述）。
As observed in the current deployments, presence of an MPLS label stack in a Layer 2 frame is assumed to be transparent to Layer3=IP, which continues to follow the conventional maximum frame payload size [RFC3032] (1500 octets for Ethernet, say). This means that the effective maximum frame payload size [RFC3032] of the resulting Layer 2 frame is Z octets more than the conventional maximum frame payload size, where Z = 4 x number of entries in the label stack.
如在当前部署中所观察到的，假定第2层帧中存在MPLS标签堆栈对第3层=IP是透明的，其继续遵循传统的最大帧有效负载大小[RFC3032]（例如，以太网为1500个八位字节）。这意味着产生的第2层帧的有效最大帧有效负载大小[RFC3032]比传统的最大帧有效负载大小多Z个八位字节，其中Z=4 x标签堆栈中的条目数。
Hence, to ensure successful delivery of Layer 2 frames carrying MPLS packets and realistic benchmarking, it is RECOMMENDED to set the media MTU value to the effective maximum frame payload size [RFC3032], which equals Z octets + conventional maximum frame payload size. It is expected that such a change in the media MTU value only impacts the effective Maximum Frame Payload Size for MPLS packets, but not for IP packets.
因此，为了确保成功交付承载MPLS数据包的第2层帧和现实的基准测试，建议将媒体MTU值设置为有效的最大帧有效负载大小[RFC3032]，其等于Z八位字节+传统的最大帧有效负载大小。预期媒体MTU值中的这种改变仅影响MPLS分组的有效最大帧有效载荷大小，而不影响IP分组的有效最大帧有效载荷大小。
Note that this document requires exactly a single entry in the MPLS label stack in an MPLS packet. In other words, the depth of the label stack is set to one, e.g., Z = 4 x 1 = 4 octets. Furthermore, in accord with Sections 9 and 9.1 of RFC 2544, this document prescribes that each test case is run with different (Layer 2) frame
请注意，本文档要求MPLS数据包中的MPLS标签堆栈中只有一个条目。换句话说，标签堆栈的深度设置为1，例如，Z=4 x 1=4个八位字节。此外，根据RFC 2544第9节和第9.1节，本文件规定每个测试用例使用不同的（第2层）框架运行
sizes in different trials. Additionally, results MAY also be collected with multiple simultaneous frame sizes (sometimes referred to as an Interactive Multimodal Information Extraction (IMIX) to simulate real network traffic according to the frame size ordering and usage). There is no standard for mixtures of frame sizes, and the results are subject to wide interpretation (see Section 18 of RFC 2544). When running trials using multiple simultaneous frame sizes, the DUT configuration MUST remain the same.
不同试验中的尺寸。此外，还可以使用多个同时的帧大小收集结果（有时称为交互式多模式信息提取（IMIX），以根据帧大小顺序和使用情况模拟真实的网络流量）。框架尺寸的混合物没有标准，结果受到广泛的解释（见RFC 2544第18节）。当同时使用多个帧尺寸进行试验时，DUT配置必须保持不变。
Ethernet media, in all its types, has become the most commonly deployed port media in MPLS networks. If any test case execution (such as the Label Push case) requires the test tool to send (or receive) a Layer 2 frame containing an IP packet, then the following frame sizes SHOULD be used for benchmarking over Ethernet media: 64, 128, 256, 512, 1024, 1280, and 1518 octets. This is in-line with Sections 9 and 9.1 of RFC 2544. Figure 4 illustrates the header sizes for an untagged Ethernet frame containing an IP payload (per RFC 2544).
各种类型的以太网介质已成为MPLS网络中最常用的端口介质。如果任何测试用例执行（如标签推送用例）需要测试工具发送（或接收）包含IP数据包的第2层帧，则应使用以下帧大小通过以太网媒体进行基准测试：64、128、256、512、1024、1280和1518个八位字节。这符合RFC 2544第9节和第9.1节的规定。图4说明了包含IP有效负载的未标记以太网帧的报头大小（根据RFC 2544）。
<----------------64-1518B------------------------>
<--18B---><-----------46-1500B------------------->
+---------+---------+----------------------------+
| Layer 2 | Layer 3 | Layer 4 (and higher) |
+---------+---------+----------------------------+
<----------------64-1518B------------------------>
<--18B---><-----------46-1500B------------------->
+---------+---------+----------------------------+
| Layer 2 | Layer 3 | Layer 4 (and higher) |
+---------+---------+----------------------------+
Figure 4: Frame Size for Label Push Cases
图4：标签推送盒的框架尺寸
Note 1: The 64- and 1518-octet frame size represents the minimum and maximum length of an untagged Ethernet frame, as per IEEE 802.3 [IEE8023]. A frame size commonly used in operational environments may range from 68 to 1522 octets, which are the minimum and maximum lengths of a single VLAN-tagged frame, as per IEEE 802.1D [IEE8021].
注1：根据IEEE 802.3[IEE8023]，64和1518八位字节帧大小表示未标记以太网帧的最小和最大长度。根据IEEE 802.1D[IEE8021]，操作环境中常用的帧大小可能在68到1522个八位字节之间，这是单个VLAN标记帧的最小和最大长度。
Note 2: While jumbo frames are outside the scope of the 802.3 IEEE standard, tests SHOULD be executed with the frame sizes that are supported by the DUT. Examples of commonly used jumbo (Ethernet) frame sizes are: 4096, 8192, and 9216 octets.
注2：虽然巨型帧不在802.3 IEEE标准的范围内，但应使用DUT支持的帧大小执行测试。常用的巨型（以太网）帧大小的示例有：4096、8192和9216个八位字节。
If any test case execution (such as Label Swap and Label Pop cases) requires the test tool to transmit (or receive) a Layer 2 frame containing an MPLS packet, then the untagged Layer 2 frame must
如果任何测试用例执行（如标签交换和标签Pop用例）需要测试工具发送（或接收）包含MPLS数据包的第2层帧，则必须发送未标记的第2层帧
include an additional 4 octets for the MPLS header, resulting in the following frame sizes to be used for benchmarking over Ethernet media: 68, 132, 260, 516, 1028, 1284, and 1522 octets. Figure 5 illustrates the header sizes for an untagged Ethernet frame containing an MPLS packet.
为MPLS报头包含额外的4个八位字节，从而产生以下用于以太网介质基准测试的帧大小：68、132、260、516、1028、1284和1522个八位字节。图5说明了包含MPLS数据包的未标记以太网帧的报头大小。
<------------------68-1522B------------------------------>
<--18B---><--4B--><-----------46-1500B------------------->
+---------+-------+---------+----------------------------+
| Layer 2 | MPLS | Layer 3 | Layer 4 (and higher) |
+---------+-------+---------+----------------------------+
<------------------68-1522B------------------------------>
<--18B---><--4B--><-----------46-1500B------------------->
+---------+-------+---------+----------------------------+
| Layer 2 | MPLS | Layer 3 | Layer 4 (and higher) |
+---------+-------+---------+----------------------------+
Figure 5: Frame Size for Label Swap and Pop Cases
图5：标签交换和弹出框的框架尺寸
Note: The Media MTU on the link between the test tool and the DUT must be changed, if needed, to accommodate the effective maximum frame payload size [RFC3032] resulting from adding an MPLS label stack to the IP packet. As clarified in Section 3.1 of RFC 3032, most Layer 2 media drivers are capable of sending and receiving Layer 2 frames with effective maximum frame payload size. Many vendors also allow the Media MTU to be changed for MPLS, without changing it for IP. The recommended link MTU value for MPLS is Z octets more than the conventional maximum frame payload size [RFC3032] (for example, the conventional maximum frame payload size for Ethernet is 1500 octets). This document prescribes Z=4 octets. If a vendor DUT doesn't allow such an MTU change, then the benchmarking cannot be performed for the true maximum frame payload size [RFC3032] and this must be reported.
注：如果需要，必须更改测试工具和DUT之间链路上的媒体MTU，以适应在IP数据包中添加MPLS标签堆栈所产生的有效最大帧有效负载大小[RFC3032]。如RFC 3032第3.1节所述，大多数第2层媒体驱动程序能够发送和接收具有有效最大帧有效负载大小的第2层帧。许多供应商还允许将媒体MTU更改为MPLS，而无需将其更改为IP。MPLS的推荐链路MTU值为Z个八位字节，大于传统的最大帧有效负载大小[RFC3032]（例如，以太网的传统最大帧有效负载大小为1500个八位字节）。本文件规定Z=4个八位字节。如果供应商DUT不允许这样的MTU更改，则无法对真实最大帧有效负载大小[RFC3032]执行基准测试，并且必须对此进行报告。
Packet over SONET (POS) media are commonly used for edge uplinks and high-bandwidth core links. POS may use one of various encapsulations techniques (such as PPP, High-Level Data Link Control (HDLC), Frame Relay, etc.), resulting in the Layer 2 header (~4 octets) being less than that of the Ethernet media. The rest of the frame format (illustrated in Figures 2 and 3) remains pretty much unchanged.
SONET分组（POS）媒体通常用于边缘上行链路和高带宽核心链路。POS可以使用各种封装技术（例如PPP、高级数据链路控制（HDLC）、帧中继等）中的一种，导致第2层报头（~4个八位字节）小于以太网媒体的报头。帧格式的其余部分（如图2和图3所示）基本保持不变。
If the MPLS forwarding characterization of POS interfaces on the DUT is desired, then the following frame sizes SHOULD be used:
如果需要DUT上POS接口的MPLS转发特性，则应使用以下帧大小：
Label Push test cases: 47, 64, 128, 256, 512, 1024, 1280, 1518, 2048, and 4096 octets.
标签推送测试用例：47、64、128、256、512、1024、1280、1518、2048和4096个八位字节。
Label Swap and Pop test cases: 51, 68, 132, 260, 516, 1028, 1284, 1522, 2052, and 4100 octets.
标签交换和Pop测试用例：51、68、132、260、516、1028、1284、1522、2052和4100个八位字节。
The TTL value in the frame header MUST be large enough to allow a TTL decrement to happen and still be forwarded through the DUT. The aforementioned TTL field may be referring to either the MPLS TTL, IPv4 TTL, or IPv6 Hop Limit depending on the exact forwarding scenario under evaluation.
帧头中的TTL值必须足够大，以允许TTL减量发生，并且仍然通过DUT转发。上述TTL字段可能是指MPLS TTL、IPv4 TTL或IPv6跃点限制，具体取决于评估中的确切转发场景。
If TTL/Hop Limit decrement, as specified in [RFC3443], is a configurable option on the DUT, the setting SHOULD be reported.
如果[RFC3443]中规定的TTL/Hop限制减量是DUT上的可配置选项，则应报告该设置。
Unless otherwise specified, the test portion of each trial SHOULD be no less than 30 seconds when static routing is in place, and no less than 200 seconds when a dynamic routing protocol and LDP (default LDP holddown timer is 180 seconds) are being used. If the holddown timer default value is changed, then it should be reported and the trial duration should still be 20 seconds more than the holddown timer value.
除非另有规定，当静态路由处于适当位置时，每次试验的试验部分应不少于30秒，当使用动态路由协议和LDP（默认LDP保持计时器为180秒）时，试验部分应不少于200秒。如果按下计时器默认值发生变化，则应报告该值，且试验持续时间仍应比按下计时器值多20秒。
The longer trial time used for dynamic routing protocols is to verify that the DUT is able to maintain a stable control plane when the data-forwarding plane is under stress.
用于动态路由协议的较长试验时间用于验证DUT在数据转发平面受到压力时能够保持稳定的控制平面。
In all cases, sent traffic MUST be accounted for, whether it was received on the wrong port, the correct port, or not received at all. Specifically, traffic loss (also referred to as frame loss) is defined as the traffic (i.e., one or more frames) not received where expected (i.e., received on the incorrect port, or received with incorrect Layer 2 or above header information, etc.). In addition, the presence or absence of the MPLS label stack, every field value inside the label stack, if present, ethertype (0x8847 or 0x8848 versus 0x0800 or 0x86DD), frame sequencing, and frame check sequence (FCS) MUST be verified in the received frame.
在所有情况下，必须考虑发送的流量，无论它是在错误的端口、正确的端口接收的，还是根本没有接收到的。具体而言，业务丢失（也称为帧丢失）被定义为未在预期位置接收的业务（即，一个或多个帧）（即，在不正确的端口上接收，或使用不正确的第2层或以上报头信息接收，等等）。此外，必须在接收到的帧中验证MPLS标签堆栈的存在与否、标签堆栈内的每个字段值（如果存在）、以太网类型（0x8847或0x8848与0x0800或0x86DD）、帧序列和帧检查序列（FCS）。
Many test tools may, by default, only verify that they have received the embedded signature on the receive side. However, for MPLS header presence verification, some tests will require the MPLS header to be pushed while others will require a swap or pop. Hence, this document requires the test tool to verify the MPLS stack depth. An even greater level of verification would be to check if the correct label was pushed. However, some test tools are not capable of checking the received label value for correctness. Test tools SHOULD verify that the packets received carry the expected MPLS label.
默认情况下，许多测试工具可能只验证它们已在接收端接收到嵌入的签名。然而，对于MPLS报头存在性验证，一些测试将要求推送MPLS报头，而其他测试将要求交换或pop。因此，本文档要求测试工具验证MPLS堆栈深度。更高级别的验证将是检查是否按下了正确的标签。但是，一些测试工具无法检查接收到的标签值的正确性。测试工具应验证接收的数据包是否带有预期的MPLS标签。
If a test setup utilizes any dynamic protocols for control plane signaling (e.g., ARP, PPP (including MPLSCP), OSPF, LDP, etc.), then all state for the protocols MUST be pre-established before the test case is executed (i.e., packet streams are started).
如果测试设置使用任何用于控制平面信令的动态协议（例如，ARP、PPP（包括MPLSCP）、OSPF、LDP等），则必须在执行测试用例之前预先建立协议的所有状态（即，开始分组流）。
For each test case, it is RECOMMENDED that the following variables be reported in addition to the specific parameters requested by the test case:
对于每个测试用例，除了测试用例要求的特定参数外，建议报告以下变量：
Parameter Units or Examples
参数单位或示例
Prefix Forwarding Equivalence IPv4, IPv6, Both Class (FEC)
前缀转发等效IPv4、IPv6、两类（FEC）
Label Distribution Protocol LDP, RSVP-TE, BGP (or combinations)
标签分发协议LDP、RSVP-TE、BGP（或组合）
MPLS Forwarding Operation Push, Swap, Pop
MPLS转发操作推送、交换、Pop
IGP ISIS, OSPF, EIGRP, RIP, static.
IGP ISIS、OSPF、EIGRP、RIP、静态。
Throughput Frames per second and bits per second
吞吐量每秒帧数和每秒比特数
Port Media GigE (Gigabit Ethernet), POS, ATM, etc.
端口媒体GigE（千兆以太网）、POS、ATM等。
Port Speed 1 gbps, 100 Mbps, etc.
端口速度1 gbps、100 Mbps等。
Interface Encapsulation Ethernet, Ethernet VLAN, PPP, HDLC, etc.
接口封装以太网、以太网VLAN、PPP、HDLC等。
Frame Size (Section 4.1.5) Octets
帧大小（第4.1.5节）八位字节
p (Number of {DA, DB} pair 1,2, etc. ports per Figure 1)
p（图1中的{DA，DB}对1,2等端口数）
The individual test cases may have additional reporting requirements that may refer to other RFCs.
个别测试用例可能有额外的报告要求，可参考其他RFC。
MPLS is a different forwarding paradigm from IP. Unlike IP packets and IP forwarding, an MPLS packet may contain more than one MPLS header and may go through one of three forwarding operations: push (or LSP Ingress), swap, or pop (or LSP Egress), as defined in [RFC3031]. Such characteristics desire further granularity in MPLS forwarding benchmarking than those described in RFC 2544. Thus, the benchmarking may include, but is not limited to:
MPLS是一种不同于IP的转发模式。与IP数据包和IP转发不同，MPLS数据包可能包含多个MPLS报头，并可能经历[RFC3031]中定义的三种转发操作之一：推送（或LSP入口）、交换或pop（或LSP出口）。与RFC 2544中描述的特性相比，这些特性要求MPLS转发基准测试具有更高的粒度。因此，基准可包括但不限于：
1. Throughput
1. 吞吐量
2. Latency
2. 延迟
3. Frame-Loss Rate
3. 帧丢失率
4. System Recovery
4. 系统恢复
5. Reset
5. 重置
6. MPLS TC (previously known as EXP [RFC5462]) field Operations (including explicit-null cases)
6. MPLS TC（以前称为EXP[RFC5462]）字段操作（包括显式空情况）
7. Negative Scenarios (TTL expiry, etc.)
7. 负面情景（TTL到期等）
8. Multicast
8. 多播
However, this document focuses only on the first five categories, inline with the spirit of RFC 2544. All the benchmarking test cases described in this document are expected to, at a minimum, follow the "Test Setup" and "Test Procedure" below:
然而，本文件仅关注前五个类别，符合RFC 2544的精神。本文件中描述的所有基准测试用例至少应遵循以下“测试设置”和“测试程序”：
Test Setup
测试设置
Referring to Figure 1, a single port (p = 1) on both A and B Modules SHOULD be used. However, if the forwarding throughput of the DUT is more than that of the media rate of a single port, then additional ports on A and B Modules MUST be enabled as follows: if the DUT can be configured with the A and B ports so as to exceed the DUT's forwarding throughput without overloading any B ports, then those MUST be enabled; if, on the other hand, the DUT's forwarding throughput capacity is greater than what can be achieved enabling all ports, then all An and Bn ports MUST be enabled. In the case where more than one A and B port is enabled, the procedures described in Section 16 of RFC 2544 must be
参考图1，应在a和B模块上使用单个端口（p=1）。但是，如果DUT的转发吞吐量大于单个端口的媒体速率，则必须按如下方式启用a和B模块上的其他端口：如果DUT可以配置a和B端口，以便在不过载任何B端口的情况下超过DUT的转发吞吐量，则必须启用这些端口；另一方面，如果DUT的转发吞吐量大于启用所有端口所能实现的吞吐量，则必须启用所有An和Bn端口。如果启用了多个A和B端口，则必须执行RFC 2544第16节中描述的程序
followed to accommodate the multi-port scenario. The frame formats transmitted and received must be in accord with Sections 4.1.4.3 and 4.1.4.4, and frame sizes must be in accord with Section 4.1.5.
遵循以下步骤以适应多端口场景。传输和接收的帧格式必须符合第4.1.4.3节和第4.1.4.4节的要求，帧尺寸必须符合第4.1.5节的要求。
Note: The test tool must be configured not to advertise a prefix or FEC to the DUT on more than one port. In other words, the DUT must associate a FEC with one and only one DB port. The Equal Cost Multi-Path (ECMP) behavior in MPLS networks uses heuristics [RFC4928]; hence, the usage of ECMP is NOT permitted by this document to ensure the deterministic forwarding behavior during benchmarking.
注意：测试工具必须配置为不在多个端口上向DUT播发前缀或FEC。换句话说，DUT必须将FEC与一个且仅一个DB端口相关联。MPLS网络中的等成本多路径（ECMP）行为使用启发式[RFC4928]；因此，本文档不允许使用ECMP来确保基准测试期间的确定性转发行为。
Test Procedure
试验程序
In accord with Section 26 of RFC 2544 [RFC2544], the traffic is sent from test tool port(s) Ap to the DUT at a constant load for a fixed-time interval, and is received from the DUT on test tool port(s) Bp. As described in Section 4.1.4.3, the frame may contain either an IP packet or an MPLS packet depending on the test case need. Furthermore, the IP packet must be either an IPv4 or IPv6 packet, depending on whether the MPLS benchmarking is done for IPv4 or IPv6.
根据RFC 2544[RFC2544]第26节的规定，流量从测试工具端口Ap以固定时间间隔的恒定负载发送至DUT，并从测试工具端口Bp上的DUT接收。如第4.1.4.3节所述，根据测试用例的需要，帧可以包含IP数据包或MPLS数据包。此外，IP数据包必须是IPv4或IPv6数据包，这取决于MPLS基准测试是针对IPv4还是IPv6进行的。
If any frame loss is detected, then a new iteration is needed where the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss.
如果检测到任何帧丢失，则需要一个新的迭代，其中提供的负载将减少，发送方将再次发送。必须使用迭代搜索算法来确定零帧丢失情况下的最大提供帧速率。
This maximum offered frame rate that results in zero frame loss through the DUT is defined as the Throughput in Section 3.17 of [RFC1242] for that test case. Informally, this rate is referred to as the No-Drop Rate (NDR).
在[RFC1242]第3.17节中，对于该测试用例，通过DUT导致零帧丢失的最大提供帧速率被定义为吞吐量。非正式地说，这一比率被称为无下降率（NDR）。
Each iteration should involve varying the offered load of the traffic, while keeping the other parameters (test duration, number of ports, number of addresses, frame size, etc.) constant, until the maximum rate at which none of the offered frames are dropped is determined.
每次迭代应涉及改变提供的流量负载，同时保持其他参数（测试持续时间、端口数、地址数、帧大小等）不变，直到确定不丢弃任何提供帧的最大速率。
This section contains the description of the tests that are related to the characterization of a DUT's MPLS traffic forwarding.
本节描述了与DUT MPLS流量转发特性相关的测试。
Objective
客观的
To obtain the DUT's Throughput (as per RFC 2544) during label push or LSP Ingress forwarding operation (i.e., IP to MPLS).
在标签推送或LSP入口转发操作（即IP到MPLS）期间获得DUT的吞吐量（根据RFC 2544）。
Test Setup
测试设置
In addition to the "Test Setup" described in Section 6, the test tool must advertise the IP prefix(es), i.e., RNx (using a routing protocol as per Section 4.1.2) and associated MPLS label-FEC binding(s) (using a label distribution protocol as per Section 4.1.3) on its receive ports Bp to the DUT. The test tool may learn the IP prefix(es) on its transmit ports Ap from the DUT.
除第6节所述的“测试设置”外，测试工具还必须在其接收端口Bp上向DUT公布IP前缀，即RNx（根据第4.1.2节使用路由协议）和相关MPLS标签FEC绑定（根据第4.1.3节使用标签分发协议）。测试工具可从DUT中学习其传输端口Ap上的IP前缀。
MPLS and/or the label distribution protocol must be enabled only on the test tool receive ports Bp and DUT transmit ports DBp.
必须仅在测试工具接收端口Bp和DUT传输端口DBp上启用MPLS和/或标签分发协议。
Discussion
讨论
The DUT's MPLS forwarding table (also referred to as Incoming Label Map (ILM) to Next Hop Label Forwarding Entry (NHLFE) mapping table per Section 3.11 of [RFC3031]) must contain a non-reserved MPLS label value as the outgoing label for each learned IP prefix corresponding to the label-FEC binding, resulting in the DUT performing the IP-to-MPLS forwarding operation. The test tool must receive MPLS packets on receive ports Bp (from the DUT) with the same label values that were advertised.
DUT的MPLS转发表（根据[RFC3031]第3.11节，也称为传入标签映射（ILM）到下一跳标签转发条目（NHLFE）映射表）必须包含一个非保留MPLS标签值，作为与标签FEC绑定对应的每个已读入IP前缀的传出标签，导致DUT执行IP到MPLS转发操作。测试工具必须在接收端口Bp（来自DUT）上接收MPLS数据包，其标签值与公布的标签值相同。
Procedure
程序
Please see "Test Procedure" in Section 6. Additionally, the test tool MUST send the frames containing IP packets (with the IP destination belonging to the advertised IP prefix(es)) on transmit ports Ap, and expect to receive frames containing MPLS packets on receive ports Bp, as described in Section 4.1.4.4.
请参见第6节中的“测试程序”。此外，如第4.1.4.4节所述，测试工具必须在发送端口Ap上发送包含IP数据包（IP目的地属于播发的IP前缀）的帧，并期望在接收端口Bp上接收包含MPLS数据包的帧。
Reporting Format
报告格式
The result should be reported as per Section 5 and RFC 2544.
应根据第5节和RFC 2544报告结果。
Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes. Additional columns SHOULD include offered load and measured throughput.
每项测试的结果应以表格的形式呈现，每种测试框架尺寸对应一行。附加列应包括提供的负载和测量的吞吐量。
Objective
客观的
To obtain the DUT's Throughput (as per RFC 2544) during label swapping operation (i.e., MPLS-to-MPLS).
在标签交换操作（即MPLS到MPLS）期间获得DUT的吞吐量（根据RFC 2544）。
Test Setup
测试设置
In addition to the setup described in Section 6, the test tool must advertise IP prefix(es) (using a routing protocol as per Section 4.1.2) and associated MPLS label-FEC bindings (using a label distribution protocol as per Section 4.1.3) on the receive ports Bp, and then learn the IP prefix(es) as well as the label-FEC binding(s) on the transmit ports Ap. The test tool must use the learned MPLS label values and learned IP prefix values in the frames transmitted on ports Ap to the DUT.
除了第6节所述的设置外，测试工具还必须在接收端口Bp上公布IP前缀（使用第4.1.2节规定的路由协议）和相关MPLS标签FEC绑定（使用第4.1.3节规定的标签分发协议），然后学习IP前缀和标签FEC绑定在传输端口Ap上。测试工具必须在Ap端口传输至DUT的帧中使用读入的MPLS标签值和读入的IP前缀值。
MPLS and/or label distribution protocol must be enabled on the test tool ports Bp and Ap, and the DUT ports DBp and DAp.
必须在测试工具端口Bp和Ap以及DUT端口DBp和DAp上启用MPLS和/或标签分发协议。
Discussion
讨论
The DUT's MPLS forwarding table (also referred to as ILM to NHLFE mapping table per Section 3.11 of [RFC3031]) must contain non-reserved MPLS label values as the outgoing and incoming labels for the learned IP prefixes, resulting in an MPLS-to-MPLS forwarding operation, e.g., label swap. The test tool must receive MPLS packets on receive ports Bp (from the DUT) with the same label values that were advertised using the label distribution protocol. The received frames must contain the same number of MPLS headers as those of transmitted frames.
DUT的MPLS转发表（根据[RFC3031]第3.11节，也称为ILM到NHLFE映射表）必须包含非保留MPLS标签值，作为读入IP前缀的传出和传入标签，从而导致MPLS到MPLS转发操作，例如标签交换。测试工具必须在接收端口Bp（来自DUT）上接收MPLS数据包，其标签值与使用标签分发协议公布的标签值相同。接收到的帧必须包含与传输帧相同数量的MPLS报头。
Procedure
程序
Please see "Test Procedure" in Section 6. Additionally, the test tool must send frames containing MPLS packets (with the IP destination belonging to the advertised IP prefix(es)) on its transmit ports Ap, and expect to receive frames containing MPLS packets on its receive ports Bp, as described in Section 4.1.4.4.
请参见第6节中的“测试程序”。此外，如第4.1.4.4节所述，测试工具必须在其发送端口Ap上发送包含MPLS数据包的帧（IP目的地属于播发的IP前缀），并期望在其接收端口Bp上接收包含MPLS数据包的帧。
Reporting Format
报告格式
The result should be reported as per Section 5 and RFC 2544.
应根据第5节和RFC 2544报告结果。
Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes.
每项测试的结果应以表格的形式呈现，每种测试框架尺寸对应一行。
Objective
客观的
To obtain the DUT's Throughput (as per RFC 2544) during label pop or LSP Egress forwarding operation (i.e., MPLS-to-IP) using "Unlabeled" outgoing label.
使用“未标记”出站标签在标签pop或LSP出站转发操作（即MPLS到IP）期间获得DUT的吞吐量（根据RFC 2544）。
Test Setup
测试设置
In addition to the setup described in Section 6, the test tool must advertise the IP prefix(es) (using a routing protocol as per Section 4.1.2) without any MPLS label-FEC bindings on the receive ports Bp, and then learn the IP prefix(es) as well as the FEC-label binding(s) on the transmit ports Ap. The test tool must use the learned MPLS label values and learned IP prefix values in the frames transmitted on ports Ap.
除了第6节中描述的设置外，测试工具还必须在接收端口Bp上公布IP前缀（使用第4.1.2节规定的路由协议），而不进行任何MPLS标签FEC绑定，然后学习IP前缀以及发送端口Ap上的FEC标签绑定。测试工具必须在Ap端口上传输的帧中使用读入的MPLS标签值和读入的IP前缀值。
MPLS and/or label distribution protocol must be enabled only on the test tool port(s) Ap and DUT port(s) DAp.
必须仅在测试工具端口Ap和DUT端口DAp上启用MPLS和/或标签分发协议。
Discussion
讨论
The DUT's MPLS forwarding table (also referred to as ILM to NHLFE mapping table per Section 3.11 of [RFC3031]) must contain an Unlabeled outgoing label (also known as untagged) for the learned IP prefix, resulting in an MPLS-to-IP forwarding operation.
DUT的MPLS转发表（根据[RFC3031]第3.11节，也称为ILM到NHLFE映射表）必须包含学习到的IP前缀的未标记的传出标签（也称为未标记），从而导致MPLS到IP转发操作。
Procedure
程序
Please see "Test Procedure" in Section 6. Additionally, the test tool must send frames containing MPLS packets on its transmit ports Ap (with the IP destination belonging to the IP prefix(es) advertised on port Bp), and expect to receive frames containing IP packets on its receive ports Bp, as described in Section 4.1.4.4.
请参见第6节中的“测试程序”。此外，测试工具必须在其传输端口Ap上发送包含MPLS数据包的帧（IP目的地属于端口Bp上公布的IP前缀），并期望在其接收端口Bp上接收包含IP数据包的帧，如第4.1.4.4节所述。
Reporting Format
报告格式
The result should be reported as per Section 5 and RFC 2544.
应根据第5节和RFC 2544报告结果。
Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes.
每项测试的结果应以表格的形式呈现，每种测试框架尺寸对应一行。
Objective
客观的
To obtain the DUT's Throughput (as per RFC 2544) during label pop or LSP Egress forwarding operation (i.e., MPLS-to-IP) using the "Aggregate" outgoing label [RFC3031].
使用“聚合”出站标签[RFC3031]，在标签pop或LSP出站转发操作（即MPLS到IP）期间获得DUT的吞吐量（根据RFC 2544）。
Test Setup
测试设置
In addition to the setup described in Section 6, the DUT must be provisioned such that it allocates an aggregate outgoing label (please see Section 3.20 in [RFC3031]) to an IP prefix, which aggregates a set of prefixes learned on ports DBp from the test tool. The prefix aggregation can be performed using BGP aggregation (Section 9.2.2.2 of [RFC4271]), IGP aggregation (Section 16.5 of [RFC2328]), etc.
除了第6节中所述的设置外，还必须对DUT进行设置，以使其能够将聚合出站标签（请参见[RFC3031]中的第3.20节）分配给IP前缀，该IP前缀聚合从测试工具在端口DBp上学习到的一组前缀。前缀聚合可以使用BGP聚合（第9.2.2.2节[RFC4271]）、IGP聚合（第16.5节[RFC2328]）等执行。
The DUT must advertise the aggregating IP prefix along with the associated MPLS label-FEC binding on ports DAp to the test tool.
DUT必须将聚合IP前缀以及端口DAp上的相关MPLS标签FEC绑定公布到测试工具。
The test tool then must use the learned MPLS label values and learned IP prefix values in frames transmitted on ports Ap to the DUT. The test tool must receive frames containing IP packets on ports Bp from the DUT.
然后，测试工具必须在Ap端口传输到DUT的帧中使用读入的MPLS标签值和读入的IP前缀值。测试工具必须从DUT接收端口Bp上包含IP数据包的帧。
MPLS and/or label distribution protocol must be enabled only on the test tool port(s) Ap and DUT port(s) DAp.
必须仅在测试工具端口Ap和DUT端口DAp上启用MPLS和/或标签分发协议。
Discussion
讨论
The DUT's MPLS forwarding table (also referred to as ILM to NHLFE mapping table per Section 3.11 of [RFC3031]) must contain an aggregate outgoing label and IP forwarding table must contain a valid entry for the learned prefix(es), resulting in MPLS-to-IP forwarding operation (i.e., MPLS header removal followed by IP lookup).
DUT的MPLS转发表（根据[RFC3031]第3.11节，也称为ILM到NHLFE映射表）必须包含一个聚合的传出标签，IP转发表必须包含一个有效的读取前缀条目，从而导致MPLS到IP转发操作（即，删除MPLS报头，然后进行IP查找）。
Procedure
程序
Please see "Test Procedure" in Section 6. Additionally, the test tool must send frames containing MPLS packets on its transmit ports Ap (with IP destination belonging to the IP prefix(es) advertised on port Bp), and expect to receive frames containing IP packets on its receive ports Bp, as described in Section 4.1.4.4.
请参见第6节中的“测试程序”。此外，测试工具必须在其发送端口Ap上发送包含MPLS数据包的帧（IP目的地属于端口Bp上公布的IP前缀），并期望在其接收端口Bp上接收包含IP数据包的帧，如第4.1.4.4节所述。
Reporting Format
报告格式
The result should be reported as per Section 5 and RFC 2544.
应根据第5节和RFC 2544报告结果。
Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes.
每项测试的结果应以表格的形式呈现，每种测试框架尺寸对应一行。
Objective
客观的
To obtain the DUT's Throughput (as per RFC 2544) during label pop (i.e., MPLS-to-IP) or penultimate hop popping (PHP) using the "imp-null" outgoing label.
使用“imp null”输出标签在标签弹出（即MPLS到IP）或倒数第二跳弹出（PHP）期间获得DUT的吞吐量（根据RFC 2544）。
Test Setup
测试设置
In addition to the setup described in Section 6, the test tool must be set up to advertise the IP prefix(es) (using a routing protocol as per Section 4.1.2) and associated MPLS label-FEC binding with a reserved MPLS label value = 3 (using a label distribution protocol as per Section 4.1.3) on its receive ports Bp. The test tool must learn the IP prefix(es) as well as the MPLS label-FEC bindings on its transmit ports Ap. The test tool then must use the learned MPLS label values and learned IP prefix values in the frames transmitted on ports Ap to the DUT. The test tool must receive frames containing IP packets on receive ports Bp (from the DUT).
除了第6节中所述的设置外，还必须将测试工具设置为在其接收端口Bp上公布IP前缀（根据第4.1.2节使用路由协议）和相关MPLS标签FEC绑定，保留MPLS标签值=3（根据第4.1.3节使用标签分发协议）。测试工具必须了解其传输端口Ap上的IP前缀以及MPLS标签FEC绑定。然后，测试工具必须在通过端口Ap传输到DUT的帧中使用读入的MPLS标签值和读入的IP前缀值。测试工具必须在接收端口Bp（来自DUT）上接收包含IP数据包的帧。
MPLS and/or label distribution protocol must be enabled on the test tool ports Bp and Ap, and DUT ports DBp and DAp.
必须在测试工具端口Bp和Ap以及DUT端口DBp和DAp上启用MPLS和/或标签分发协议。
Discussion
讨论
This test case characterizes Penultimate Hop Popping (PHP), which is described in RFC 3031.
这个测试用例描述了倒数第二跳弹出（PHP），这在RFC3031中有描述。
The DUT's MPLS forwarding table (also referred to as ILM to NHLFE mapping table per Section 3.11 of [RFC3031]) must contain a reserved MPLS label value = 3 (e.g., pop or imp-null) as the outgoing label for the learned prefix(es), resulting in MPLS-to-IP forwarding operation.
DUT的MPLS转发表（根据[RFC3031]第3.11节，也称为ILM到NHLFE映射表）必须包含一个保留的MPLS标签值=3（例如，pop或imp null），作为读入前缀的传出标签，从而导致MPLS到IP转发操作。
This test case characterizes DUT's penultimate hop popping (PHP) functionality.
这个测试用例描述了DUT的倒数第二跳弹出（PHP）功能。
Procedure
程序
Please see "Test Procedure" in Section 6. Additionally, the test tool must send frames containing MPLS packets on its transmit ports Ap (with IP destination belonging to advertised IP prefix(es)), and expect to receive frames containing IP packets on its receive ports Bp, as described in Section 4.1.4.4.
请参见第6节中的“测试程序”。此外，如第4.1.4.4节所述，测试工具必须在其发送端口Ap（IP目的地属于播发IP前缀）上发送包含MPLS数据包的帧，并期望在其接收端口Bp上接收包含IP数据包的帧。
Reporting Format
报告格式
The result should be reported as per Section 5 and RFC 2544.
应根据第5节和RFC 2544报告结果。
Results for each test SHOULD be in the form of a table with a row for each of the tested frame sizes.
每项测试的结果应以表格的形式呈现，每种测试框架尺寸对应一行。
Latency measurement measures the time taken by the DUT to forward the MPLS packet during various MPLS switching paths such as IP-to-MPLS, MPLS-to-MPLS, or MPLS-to-IP involving an MPLS label stack.
延迟测量测量DUT在各种MPLS交换路径（如IP到MPLS、MPLS到MPLS或涉及MPLS标签堆栈的MPLS到IP）期间转发MPLS数据包所花费的时间。
Objective
客观的
To obtain the average latency induced by the DUT during MPLS packet forwarding for each of five forwarding operations.
获取五个转发操作中每个操作在MPLS数据包转发期间DUT引起的平均延迟。
Test Setup
测试设置
Follow the "Test Setup" guidelines established for each of the five MPLS forwarding operations in Sections 6.1.1 (for IP-to-MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), one by one.
逐一遵循第6.1.1节（针对IP到MPLS）、第6.1.2节（针对MPLS到MPLS）、第6.1.3节（针对MPLS到IP未标记）、第6.1.4节（针对MPLS到IP聚合）和第6.1.5节（针对MPLS到IP PHP）中为五个MPLS转发操作中的每一个操作制定的“测试设置”指南。
Procedure
程序
Please refer to Section 26.2 in RFC 2544 in addition to following the associated procedure for each MPLS forwarding operation in accord with the test setup described earlier:
请参考RFC 2544中的第26.2节，以及根据前面描述的测试设置进行的每个MPLS转发操作的相关程序：
IP-to-MPLS forwarding (Push) Section 6.1.1 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-IP forwarding (Pop) Section 6.1.3 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (PHP) Section 6.1.5
IP到MPLS转发（推送）第6.1.1节MPLS到MPLS转发（交换）第6.1.2节MPLS到IP转发（Pop）第6.1.3节MPLS到IP转发（聚合）第6.1.4节MPLS到IP转发（PHP）第6.1.5节
Reporting Format
报告格式
The result should be reported as per Section 5 and RFC 2544.
应根据第5节和RFC 2544报告结果。
Frame-Loss Rate (FLR) measurement measures the percentage of MPLS frames that were not forwarded during various switching paths such as IP-to-MPLS (push), MPLS-to-IP (swap), or MPLS-IP (pop) by the DUT under overloaded state.
帧丢失率（FLR）测量测量在过载状态下DUT在各种交换路径（如IP到MPLS（推送）、MPLS到IP（交换）或MPLS-IP（pop））期间未转发的MPLS帧的百分比。
Please refer to RFC 2544, Section 26.3, for more details.
请参考RFC 2544第26.3节了解更多详细信息。
Objective
客观的
To obtain the frame-loss rate, as defined in RFC 1242, for each of the three MPLS forwarding operations of a DUT, throughout the range of input data rates and frame sizes.
在整个输入数据速率和帧大小范围内，为DUT的三个MPLS转发操作中的每一个获得RFC 1242中定义的帧丢失率。
Test Setup
测试设置
Follow the "Test Setup" guidelines established for each of the five MPLS forwarding operations in Sections 6.1.1 (for IP-to-MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), one by one.
逐一遵循第6.1.1节（针对IP到MPLS）、第6.1.2节（针对MPLS到MPLS）、第6.1.3节（针对MPLS到IP未标记）、第6.1.4节（针对MPLS到IP聚合）和第6.1.5节（针对MPLS到IP PHP）中为五个MPLS转发操作中的每一个操作制定的“测试设置”指南。
Procedure
程序
Please refer to Section 26.3 of RFC 2544 [RFC2544] and follow the associated procedure for each MPLS forwarding operation one-by-one in accord with the test setup described earlier:
请参考RFC 2544[RFC2544]第26.3节，并按照前面描述的测试设置，逐一执行每个MPLS转发操作的相关程序：
IP-to-MPLS forwarding (Push) Section 6.1.1 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-IP forwarding (Pop) Section 6.1.3 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (PHP) Section 6.1.5
IP到MPLS转发（推送）第6.1.1节MPLS到MPLS转发（交换）第6.1.2节MPLS到IP转发（Pop）第6.1.3节MPLS到IP转发（聚合）第6.1.4节MPLS到IP转发（PHP）第6.1.5节
A misdirected frame, that is, a frame received on the wrong Bn, is considered lost. If the test tool is capable of checking received MPLS label values, a frame with the wrong MPLS label is considered lost.
错误定向的帧，即在错误的Bn上接收的帧，被视为丢失。如果测试工具能够检查收到的MPLS标签值，则具有错误MPLS标签的帧被视为丢失。
Reporting Format
报告格式
The result should be reported as per Section 5 and RFC 2544.
应根据第5节和RFC 2544报告结果。
Objective
客观的
To characterize the speed at which a DUT recovers from an overload condition.
描述DUT从过载状态恢复的速度。
Test Setup
测试设置
Follow the "Test Setup" guidelines established for each of the five MPLS forwarding operations in Sections 6.1.1 (for IP-to-MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), one by one.
逐一遵循第6.1.1节（针对IP到MPLS）、第6.1.2节（针对MPLS到MPLS）、第6.1.3节（针对MPLS到IP未标记）、第6.1.4节（针对MPLS到IP聚合）和第6.1.5节（针对MPLS到IP PHP）中为五个MPLS转发操作中的每一个操作制定的“测试设置”指南。
Procedure
程序
Please refer to Section 26.5 of RFC 2544 and follow the associated procedure for each MPLS forwarding operation in the referenced sections one-by-one in accord with the test setup described earlier:
请参考RFC 2544第26.5节，并按照前面描述的测试设置，逐一遵循参考章节中每个MPLS转发操作的相关程序：
IP-to-MPLS forwarding (Push) Section 6.1.1 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-IP forwarding (Pop) Section 6.1.3 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (PHP) Section 6.1.5
IP到MPLS转发（推送）第6.1.1节MPLS到MPLS转发（交换）第6.1.2节MPLS到IP转发（Pop）第6.1.3节MPLS到IP转发（聚合）第6.1.4节MPLS到IP转发（PHP）第6.1.5节
Reporting Format
报告格式
The result should be reported as per Section 5 and RFC 2544.
应根据第5节和RFC 2544报告结果。
The "reset" aspects of benchmarking are described in [RFC2544], but these procedures need to be clarified in order to ensure consistency. This document does not specify the reset procedures. These need to be addressed in a separate document and will more generally apply to IP and MPLS test cases.
[RFC2544]中描述了基准测试的“重置”方面，但需要澄清这些程序以确保一致性。本文件未规定重置程序。这些问题需要在单独的文档中解决，并将更普遍地应用于IP和MPLS测试用例。
The text below describes the MPLS forwarding benchmarking-specific setup that will have to be used in conjunction with the procedures from the separate document to make this test case meaningful.
下面的文本描述了MPLS转发基准测试特定的设置，该设置必须与单独文档中的过程结合使用，以使该测试用例具有意义。
Objective
客观的
To characterize the speed at which a DUT recovers from a device or software reset.
描述DUT从设备或软件复位中恢复的速度。
Test Setup
测试设置
Follow the "Test Setup" guidelines established for each of the five MPLS forwarding operations in Sections 6.1.1 (for IP-to-MPLS), 6.1.2 (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for MPLS-to-IP Aggregate), and 6.1.5 (for MPLS-to-IP PHP), one by one.
逐一遵循第6.1.1节（针对IP到MPLS）、第6.1.2节（针对MPLS到MPLS）、第6.1.3节（针对MPLS到IP未标记）、第6.1.4节（针对MPLS到IP聚合）和第6.1.5节（针对MPLS到IP PHP）中为五个MPLS转发操作中的每一个操作制定的“测试设置”指南。
For this test case, the requirements of LDP and a routing protocol are removed and replaced by static configurations. For the IP-to-MPLS forwarding, static route configurations should be applied. For the MPLS-to-MPLS and MPLS-to-IP, static label configurations must be applied.
对于这个测试用例，LDP和路由协议的要求被删除，并被静态配置所取代。对于IP到MPLS的转发，应该应用静态路由配置。对于MPLS到MPLS和MPLS到IP，必须应用静态标签配置。
For this test, all Graceful Restart features MUST be disabled.
对于此测试，必须禁用所有正常重启功能。
Discussion
讨论
This test case is intended to provide insight into how long an MPLS device could take to be fully operational after any of the reset events. It is quite likely that the time an IP/MPLS device takes to become fully operational after any of the reset events may be different from that of an IP-only device.
此测试用例旨在深入了解MPLS设备在任何重置事件后完全运行所需的时间。在任何重置事件之后，IP/MPLS设备完全运行所需的时间很可能与仅IP设备的时间不同。
Modern devices now have many more reset options that were not available when Section 26.6 of RFC 2544 was published. Moreover, different reset events on modern devices may produce different results, hence, needing clarity and consistency in reset procedures beyond what's specified in RFC 2544.
现代设备现在有更多的重置选项，这些选项在RFC 2544第26.6节发布时不可用。此外，现代设备上的不同重置事件可能会产生不同的结果，因此，除了RFC 2544中规定的内容外，重置程序需要清晰一致。
Procedure
程序
Please follow the procedure from the separate document for each MPLS forwarding operation one-by-one:
对于每个MPLS转发操作，请按照单独文档中的程序逐一执行：
IP-to-MPLS forwarding (Push) Section 6.1.1 MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-IP forwarding (Pop) Section 6.1.3 MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (PHP) Section 6.1.5
IP到MPLS转发（推送）第6.1.1节MPLS到MPLS转发（交换）第6.1.2节MPLS到IP转发（Pop）第6.1.3节MPLS到IP转发（聚合）第6.1.4节MPLS到IP转发（PHP）第6.1.5节
Reporting Format
报告格式
The result should be reported as per Section 5 and as per the separate document.
应根据第5节和单独文件报告结果。
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.
基准网络拓扑将是一个独立的测试设置，不得连接到可能将测试流量转发到生产网络或将流量错误路由到测试管理网络的设备。
Furthermore, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT/SUT (System Under Test).
此外，基准测试是在“黑盒”的基础上进行的，仅依赖于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 Mo Khalid, who motivated us to write this document. We would like to thank Rodney Dunn, Chip Popoviciu, Jeff Byzek, Jay Karthik, Rajiv Papneja, Samir Vapiwala, Silvija Andrijic Dry, Scott Bradner, Al Morton, and Bill Cerveny for their careful review and suggestions.
作者要感谢Mo Khalid，是他激励我们撰写本文件。我们要感谢罗德尼·邓恩、奇普·波波维西奥、杰夫·比泽克、杰伊·卡尔蒂克、拉吉夫·帕普尼亚、萨米尔·瓦皮瓦拉、西尔维嘉·安德里奇·德瑞、斯科特·布拉德纳、艾尔·莫顿和比尔·塞文尼的仔细审查和建议。
This document was originally prepared using 2-Word-v2.0.template.dot.
本文件最初使用2-Word-v2.0.template.dot编制。
[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月。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[RFC1242]Bradner，S.，“网络互连设备的基准术语”，RFC1242，1991年7月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107]Rekhter，Y.和E.Rosen，“在BGP-4中携带标签信息”，RFC 3107，2001年5月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[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月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664]Andersson，L.，Ed.，和E.Rosen，Ed.，“第二层虚拟专用网络（L2VPN）框架”，RFC 4664，2006年9月。
[IEE8021] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", Feb 2004.
[IEE8021]Mick Seaman（编辑），“IEEE标准802.1D-2004，MAC桥”，2004年2月。
[IEE8023] LAN/MAN Standards Committee of the IEEE Computer Society, "IEEE Std 802.3as-2006, Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, Amendment 3: Frame format extensions", Nov 2006.
[IEE8023]IEEE计算机协会局域网/城域网标准委员会，“IEEE标准802.3as-2006，第3部分：带冲突检测的载波侦听多址（CSMA/CD）接入方法和物理层规范，修改件3：帧格式扩展”，2006年11月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.
[RFC4928]Swallow，G.，Bryant，S.和L.Andersson，“避免MPLS网络中的等成本多路径处理”，BCP 128，RFC 4928，2007年6月。
[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月。
Authors' Addresses
作者地址
Aamer Akhter Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA
美国北卡罗来纳州基特克里克路RTP Aamer Akhter Cisco Systems 7025 Kit Creek Road 27709
EMail: aakhter@cisco.com
EMail: aakhter@cisco.com
Rajiv Asati Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA
Rajiv Asati Cisco Systems 7025 Kit Creek Road RTP，美国北卡罗来纳州27709
EMail: rajiva@cisco.com
EMail: rajiva@cisco.com
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road RTP, NC 27709 USA
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road RTP，美国北卡罗来纳州27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com