Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 7497 AT&T Labs
Category: Informational April 2015
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 7497 AT&T Labs
Category: Informational April 2015
ISSN: 2070-1721
Rate Measurement Test Protocol Problem Statement and Requirements
速率测量测试协议问题陈述和要求
Abstract
摘要
This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM). Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size.
本备忘录提出了一个用于测试协议的访问率测量问题陈述，以测量IP性能指标（IPPM）。密钥速率测量测试协议方面包括控制测试路径上的数据包特征的能力，例如不对称速率和不对称数据包大小。
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/rfc7497.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7497.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 6
4. Measurement Method Categories . . . . . . . . . . . . . . . . 7
5. Test Protocol Control and Generation Requirements . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Operational Considerations . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
3. Active Rate Measurement . . . . . . . . . . . . . . . . . . . 6
4. Measurement Method Categories . . . . . . . . . . . . . . . . 7
5. Test Protocol Control and Generation Requirements . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Operational Considerations . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
There are many possible rate measurement scenarios. This memo describes one rate measurement problem and presents a rate measurement problem statement for test protocols to measure IP Performance Metrics (IPPM).
有许多可能的速率测量场景。本备忘录描述了一个速率测量问题，并为测量IP性能指标（IPPM）的测试协议提供了速率测量问题说明。
When selecting a form of access to the Internet, subscribers are interested in the performance characteristics of the various alternatives. Standardized measurements can be a basis for comparison between these alternatives. There is an underlying need to coordinate measurements that support such comparisons and to test control protocols to fulfill this need. The figure below depicts some typical measurement points of access networks.
在选择互联网接入方式时，用户对各种备选方案的性能特征感兴趣。标准化测量可以作为比较这些备选方案的基础。有一种潜在的需求，需要协调支持这种比较的测量，并测试控制协议以满足这一需求。下图描述了接入网络的一些典型测量点。
User /====== Fiber ======= Access Node \
Device -|------ Copper ------- Access Node -|-- Infrastructure -- GW
or Host \------ Radio ------- Access Node /
User /====== Fiber ======= Access Node \
Device -|------ Copper ------- Access Node -|-- Infrastructure -- GW
or Host \------ Radio ------- Access Node /
GW = Gateway
GW = Gateway
The access rate scenario or use case has received widespread attention of Internet-access subscribers and seemingly all Internet-industry players, including regulators. This problem is being approached with many different measurement methods. The eventual protocol solutions to this problem (and the systems that utilize the protocol) may not directly involve users, such as when tests reach from the infrastructure to a service-specific device, such as a residential gateway. However, no aspect of the problem precludes users from developing a test protocol controlled via command line
访问速率场景或用例受到了互联网访问用户和所有互联网行业参与者（包括监管机构）的广泛关注。这个问题正在用许多不同的测量方法来解决。该问题的最终协议解决方案（以及使用该协议的系统）可能不会直接涉及用户，例如当测试从基础设施到达特定于服务的设备（如住宅网关）时。然而，问题的任何方面都不妨碍用户开发通过命令行控制的测试协议
interfaces on both ends. Thus, a very wide range of test protocols, active measurement methods, and system solutions are the possible outcomes of this problem statement.
两端的接口。因此，本问题陈述的可能结果是范围非常广泛的测试协议、主动测量方法和系统解决方案。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The scope and purpose of this memo is to define the measurement problem statement for test protocols conducting access rate measurement on production networks. Relevant test protocols include [RFC4656] and [RFC5357], but the problem is stated in a general way so that it can be addressed by any existing test protocol, such as [RFC6812].
本备忘录的范围和目的是定义在生产网络上进行访问率测量的测试协议的测量问题说明。相关的测试协议包括[RFC4656]和[RFC5357]，但问题是以一般方式说明的，因此可以通过任何现有的测试协议解决，如[RFC6812]。
This memo discusses possible measurement methods but does not specify exact methods that would normally be part of the solution.
本备忘录讨论了可能的测量方法，但未规定通常作为解决方案一部分的精确方法。
We are interested in access measurement scenarios with the following characteristics:
我们对具有以下特征的访问度量场景感兴趣：
o The access portion of the network is the focus of this problem statement. The user typically subscribes to a service with bidirectional access partly described by rates in bits per second. The rates may be expressed as raw capacity or restricted capacity, as described in [RFC6703]. These are the quantities that must be measured according to one or more standard metrics and for which measurement methods must also be agreed on as a part of the solution.
o 网络的接入部分是本问题陈述的重点。用户通常订阅双向访问的服务，部分由比特/秒的速率描述。费率可表示为原始容量或限制容量，如[RFC6703]所述。这些是必须根据一个或多个标准度量进行测量的数量，并且测量方法也必须作为解决方案的一部分达成一致。
o Referring to the reference path illustrated below and defined in [RFC7398], possible measurement points include a subscriber's host, the access service demarcation point, intra IP access (where a globally routable address is present), or the gateway between the measured access network and other networks.
o 参考下文所示并在[RFC7398]中定义的参考路径，可能的测量点包括订户的主机、接入服务分界点、IP内接入（其中存在全局可路由地址）或测量的接入网络和其他网络之间的网关。
Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
device Net #1 Net #2 Demarc. Access GW GRA GW
Subsc. -- Private -- Private -- Access -- Intra IP -- GRA -- Transit
device Net #1 Net #2 Demarc. Access GW GRA GW
GRA = Globally Routable Address, GW = Gateway
GRA=全局可路由地址，GW=网关
o Rates at some links near the edge of the provider's network can often be several orders of magnitude less than link rates in the aggregation and core portions of the network.
o 提供商网络边缘附近的某些链路的速率通常比网络聚合部分和核心部分的链路速率低几个数量级。
o Asymmetrical access rates on ingress and egress are prevalent.
o 入口和出口的非对称访问率普遍存在。
o In many scenarios of interest, services of extremely large-scale access require low-complexity devices participating at the user end of the path, and those devices place limits on clock and control timing accuracy.
o 在许多感兴趣的场景中，超大规模接入的服务需要在路径的用户端参与的低复杂度设备，并且这些设备对时钟和控制定时精度进行了限制。
This problem statement assumes that the most likely bottleneck device or link is adjacent to the remote (user-end) measurement device or is within one or two router/switch hops of the remote measurement device.
此问题陈述假设最可能的瓶颈设备或链路与远程（用户端）测量设备相邻，或者位于远程测量设备的一个或两个路由器/交换机跃点内。
Other use cases for rate measurement involve situations where the packet switching and transport facilities are leased by one operator from another, and the link capacity available cannot be directly determined (e.g., from device-interface utilization). These scenarios could include mobile backhaul, Ethernet service access networks, and/or extensions of layer 2 or layer 3 networks. The results of rate measurements in such cases could be employed to select alternate routing, investigate whether capacity meets some previous agreement, and/or adapt the rate of traffic sources if a capacity bottleneck is found via the rate measurement. In the case of aggregated leased networks, available capacity may also be asymmetric. In these cases, the tester is assumed to have a sender and receiver location under their control. We refer to this scenario below as the aggregated leased-network case.
速率测量的其他用例涉及包交换和传输设施由一个运营商从另一个运营商租用的情况，并且不能直接确定可用的链路容量（例如，从设备接口利用率）。这些场景可能包括移动回程、以太网服务接入网络和/或第2层或第3层网络的扩展。在这种情况下，速率测量的结果可用于选择备用路由、调查容量是否满足某些先前的协议，和/或在通过速率测量发现容量瓶颈时调整流量源的速率。在聚合租用网络的情况下，可用容量也可能是不对称的。在这些情况下，假定测试仪在其控制下具有发送器和接收器位置。我们在下面将此场景称为聚合租用网络案例。
This memo describes protocol support for active measurement methods consistent with the IPPM working group's traditional charter. Active measurements require synthetic traffic streams dedicated to testing and do not make measurements on user traffic. See Section 2 of [RFC2679], where the concept of a stream is first introduced in IPPM literature as the basis for collecting a sample (defined in Section 11 of [RFC2330]).
本备忘录描述了与IPPM工作组传统章程一致的主动测量方法的协议支持。主动测量需要专用于测试的合成流量流，而不对用户流量进行测量。参见[RFC2679]第2节，其中首次在IPPM文献中引入流的概念，作为收集样本的基础（定义见[RFC2330]第11节）。
As noted in [RFC2330], the focus of access traffic management may influence the rate measurement results for some forms of access, as it may differ between user and test traffic if the test traffic has different characteristics, primarily in terms of the packets themselves (see Section 13 of [RFC2330] for the considerations on packet type, or Type-P).
如[RFC2330]中所述，访问流量管理的重点可能会影响某些形式的访问的速率测量结果，因为如果测试流量具有不同的特性（主要是数据包本身），则用户和测试流量之间可能会有所不同（见[RFC2330]第13节）有关数据包类型或类型P的注意事项）。
There are several aspects of Type-P where user traffic may be examined and selected for special treatment that may affect transmission rates. Various aspects of Type-P are known to influence
在P型的几个方面，可以检查用户流量并选择可能影响传输速率的特殊处理。已知P型的各个方面会影响
Equal-Cost Multipath (ECMP) routing with possible rate measurement variability across parallel paths. Without being exhaustive, the possibilities include:
具有并行路径上可能的速率测量可变性的等成本多路径（ECMP）路由。在不详尽的情况下，可能性包括：
o Packet length
o 数据包长度
o IP addresses
o IP地址
o Transport protocol (e.g., where TCP packets may be routed differently from UDP)
o 传输协议（例如，TCP数据包的路由可能与UDP不同）
o Transport-protocol port numbers
o 传输协议端口号
This issue requires further discussion when specific solutions/ methods of measurement are proposed; for this problem statement, it is sufficient to identify the problem and indicate that the solution may require an extremely close emulation of user traffic, in terms of one or more factors above.
当提出具体的解决方案/测量方法时，需要进一步讨论该问题；对于这个问题陈述，就上述一个或多个因素而言，识别问题并指出解决方案可能需要对用户流量进行非常接近的模拟就足够了。
Although the user may have multiple instances of network access available to them, the primary problem scope is to measure one form of access at a time. It is plausible that a solution for the single access problem will be applicable to simultaneous measurement of multiple access instances, but treatment of this scenario is beyond the current scope this document.
尽管用户可能有多个可用的网络访问实例，但主要的问题范围是一次测量一种访问形式。单访问问题的解决方案可能适用于多访问实例的同时测量，但这种情况的处理超出了本文档的当前范围。
A key consideration is whether or not active measurements will be conducted with user traffic present. In-Service testing takes place with user traffic present. Out-of-Service testing occurs during pre-service assessment or during maintenance that interrupts service temporarily. Out-of-Service testing includes activities described as "service commissioning", "service activation", and "planned maintenance". Opportunistic In-Service testing (when there is no user traffic present throughout the test interval, such as outside normal business hours) is essentially equivalent to Out-of-Service testing. Both In-Service and Out-of-Service testing are within the scope of this problem.
一个关键考虑因素是，是否将在存在用户流量的情况下进行主动测量。在用户流量存在的情况下进行在用测试。在服务前评估期间或临时中断服务的维护期间，会进行停用测试。停用测试包括“服务调试”、“服务激活”和“计划维护”等活动。机会主义服务内测试（当在整个测试间隔内没有用户流量时，例如在正常工作时间之外）本质上等同于服务外测试。在用和停用测试都在这个问题的范围内。
It is a non-goal to solve the measurement protocol specification problem in this memo.
解决本备忘录中的测量协议规范问题并非目的。
It is a non-goal to standardize methods of measurement in this memo. However, the problem statement mandates support for one category of rate measurement methods in the test protocol and adequate control features for the methods in the control protocol (assuming the control and test protocols are separate).
在本备忘录中，标准化测量方法是一个非目标。然而，问题陈述要求支持测试协议中的一类速率测量方法，并为控制协议中的方法提供足够的控制功能（假设控制协议和测试协议是分开的）。
This section lists features of active measurement methods needed to measure access rates in production networks.
本节列出了在生产网络中测量访问速率所需的主动测量方法的功能。
Coordination between source and destination devices through control messages and other basic capabilities described in the methods of IPPM RFCs [RFC2679] [RFC2680], and assumed for test protocols such as [RFC5357] and [RFC4656], are taken as given.
通过IPPM RFCs[RFC2679][RFC2680]方法中描述的控制消息和其他基本功能以及[RFC5357]和[RFC4656]等测试协议假设的源设备和目标设备之间的协调视为给定。
Most forms of active testing intrude on user performance to some degree, especially In-Service testing. One key tenet of IPPM methods is to minimize test traffic effects on user traffic in the production network. Section 5 of [RFC2680] lists the problems with high measurement traffic rates ("too much" traffic); the most relevant for rate measurement is the tendency for measurement traffic to skew the results, followed by the possibility of introducing congestion on the access link. Section 4 of [RFC3148] provides additional considerations. The user of protocols for In-Service testing MUST respect these traffic constraints. Obviously, categories of rate measurement methods that use less active test traffic than others with similar accuracy are preferred for In-Service testing, and the specifications of this memo encourage traffic reduction through asymmetric control capabilities.
大多数形式的主动测试在一定程度上影响了用户性能，尤其是在服务测试中。IPPM方法的一个关键原则是最小化测试流量对生产网络中用户流量的影响。[RFC2680]第5节列出了高测量流量率（“过多”流量）的问题；与速率测量最相关的是测量流量倾向于扭曲结果，其次是在接入链路上引入拥塞的可能性。[RFC3148]第4节提供了其他注意事项。服务测试协议的用户必须遵守这些流量限制。显然，与其他具有类似精度的测试流量相比，使用较少活动测试流量的速率测量方法类别更适合于在役测试，本备忘录的规范鼓励通过不对称控制能力减少流量。
Out-of-Service tests where the test path shares no links with In-Service user traffic, have none of the congestion or skew concerns. Both types should address practical matters common to all test efforts, such as conducting measurements within a reasonable time from the tester's point of view and ensuring that timestamp accuracy is consistent with the precision needed for measurement [RFC2330]. Out-of-Service tests where some part of the test path is shared with In-Service traffic MUST respect the In-Service constraints described above.
在服务外测试中，测试路径与服务内用户通信量不共享任何链路，因此不存在拥塞或扭曲问题。这两种类型都应解决所有测试工作共同的实际问题，例如从测试人员的角度在合理的时间内进行测量，并确保时间戳精度与测量所需的精度一致[RFC2330]。当测试路径的某些部分与服务内流量共享时，服务外测试必须遵守上述服务内约束。
The intended metrics to be measured have strong influence over the categories of measurement methods required. For example, using the terminology of [RFC5136], it may be possible to measure a path capacity metric while In-Service if the level of background (user) traffic can be assessed and included in the reported result.
拟测量的指标对所需测量方法的类别有很大影响。例如，使用[RFC5136]的术语，如果可以评估背景（用户）通信量的水平并将其包括在报告的结果中，则可以在服务中测量路径容量度量。
The measurement architecture MAY be either of one-way (e.g., [RFC4656]) or two-way (e.g., [RFC5357]), but the scale and complexity aspects of end-user or aggregated access measurement clearly favor two-way (with a low-complexity user-end device and round-trip results collection, as found in [RFC5357]). However, the asymmetric rates of many access services mean that the measurement system MUST be able to evaluate performance in each direction of transmission. In the two-
测量体系结构可以是单向（例如，[RFC4656]）或双向（例如，[RFC5357]），但最终用户或聚合访问测量的规模和复杂性方面明显倾向于双向（具有低复杂性的用户端设备和往返结果收集，如[RFC5357]）。然而，许多接入服务的不对称速率意味着测量系统必须能够评估每个传输方向的性能。在两个-
way architecture, both end devices MUST include the ability to launch test streams and collect the results of measurements in both (one-way) directions of transmission (this requirement is consistent with previous protocol specifications, and it is not a unique problem for rate measurements).
在双向体系结构中，两个终端设备必须能够启动测试流，并在两个（单向）传输方向上收集测量结果（该要求与以前的协议规范一致，对于速率测量而言，这不是唯一的问题）。
The following paragraphs describe features for the roles of test packet SENDER, RECEIVER, and results REPORTER.
以下段落描述了测试数据包发送者、接收者和结果报告者角色的特性。
SENDER:
发件人：
Generate streams of test packets with various characteristics as desired (see Section 4). The SENDER MAY be located at the user end of the access path or elsewhere in the production network, such as at one end of an aggregated leased-network segment.
根据需要生成具有各种特性的测试数据包流（参见第4节）。发送方可以位于接入路径的用户端或生产网络中的其他位置，例如在聚合租用网段的一端。
RECEIVER:
接收人：
Collect streams of test packets with various characteristics (as described above), and make the measurements necessary to support rate measurement at the receiving end of an access or aggregated leased-network segment.
收集具有各种特征的测试数据包流（如上所述），并进行必要的测量，以支持接入或聚合租用网段的接收端的速率测量。
REPORTER:
记者:
Use information from test packets and local processes to measure delivered packet rates and prepare results in the required format (the REPORTER role may be combined with another role, most likely the SENDER).
使用来自测试数据包和本地进程的信息来测量发送的数据包速率，并以所需的格式准备结果（报告者角色可以与另一个角色组合，最有可能是发送者）。
A protocol that addresses the rate measurement problem MUST serve the test stream generation and measurement functions (SENDER and RECEIVER). The follow-up phase of analyzing the measurement results to produce a report is outside the scope of this problem and memo (REPORTER).
解决速率测量问题的协议必须服务于测试流生成和测量功能（发送方和接收方）。分析测量结果以生成报告的后续阶段不属于此问题和备忘录（REPORTER）的范围。
For the purposes of this problem statement, we categorize the many possibilities for rate measurement stream generation as follows:
出于本问题陈述的目的，我们将速率测量流生成的多种可能性分类如下：
1. Packet pairs, with fixed intra-pair packet spacing and fixed or random time intervals between pairs in a test stream.
1. 数据包对，具有固定的对内数据包间隔和测试流中对之间的固定或随机时间间隔。
2. Multiple streams of packet pairs, with a range of intra-pair spacing and inter-pair intervals.
2. 多个数据包对流，具有一系列对内间隔和对间间隔。
3. One or more packet ensembles in a test stream, using a fixed ensemble size in packets and one or more fixed intra-ensemble packet spacings (including zero spacing, meaning that back-to-back burst ensembles and constant rate ensembles fall in this category).
3. 测试流中的一个或多个分组集合，使用分组中的固定集合大小和一个或多个固定的集合内分组间隔（包括零间隔，这意味着背对背突发集合和恒定速率集合属于该类别）。
4. One or more packet chirps (a set of packets with specified characteristics), where inter-packet spacing typically decreases between adjacent packets in the same chirp and each pair of packets represents a rate for testing purposes.
4. 一个或多个数据包啁啾（具有指定特征的数据包集合），其中数据包间隔通常在相同啁啾中的相邻数据包之间减小，并且每对数据包表示用于测试目的的速率。
The test protocol SHALL support test packet ensemble generation (category 3), as this appears to minimize the demands on measurement accuracy. Other stream generation categories are OPTIONAL.
测试协议应支持测试数据包集成生成（3类），因为这似乎是为了最小化对测量精度的要求。其他流生成类别是可选的。
For all supported categories, the following is a list of additional variables that the protocol(s) MUST be able to specify, control, and generate:
对于所有支持的类别，以下是协议必须能够指定、控制和生成的附加变量列表：
a. variable payload lengths among packet streams;
a. 分组流之间的可变有效负载长度；
b. variable length (in packets) among packet streams or ensembles;
b. 分组流或集合之间的可变长度（以分组为单位）；
c. variable IP header markings among packet streams;
c. 分组流之间的可变IP报头标记；
d. choice of UDP transport and variable port numbers, or choice of TCP transport and variable port numbers for two-way architectures only, or both (see below for additional requirements on TCP transport generation); and
d. 选择UDP传输和可变端口号，或仅为双向体系结构选择TCP传输和可变端口号，或两者兼有（有关TCP传输生成的其他要求，请参见下文）；和
e. variable number of packet pairs, ensembles, or streams used in a test session.
e. 测试会话中使用的数据包对、集合或流的可变数量。
The ability to revise these variables during an established test session is OPTIONAL, as multiple test sessions could serve the same purpose. Another OPTIONAL feature is the ability to generate streams with VLAN tags and other markings.
在已建立的测试会话期间修改这些变量的能力是可选的，因为多个测试会话可以达到相同的目的。另一个可选功能是能够生成带有VLAN标记和其他标记的流。
For measurement systems employing TCP as the transport protocol, the ability to generate specific stream characteristics requires a sender with the ability to establish and prime the connection such that the desired stream characteristics are allowed. See [IPPM-METRICS] for more background.
对于采用TCP作为传输协议的测量系统，生成特定流特征的能力要求发送方能够建立和启动连接，从而允许所需的流特征。有关更多背景信息，请参见[IPPM-METRICS]。
Beyond a simple connection handshake and the options establishment, an "open-loop" TCP sender requires the SENDER ability to:
除了简单的连接握手和选项建立之外，“开环”TCP发送方还需要发送方能够：
o generate TCP packets with well-formed headers (all fields valid), including Acknowledgement aspects;
o 生成具有格式良好的报头（所有字段均有效）的TCP数据包，包括确认方面；
o produce packet streams at controlled rates and variable inter-packet spacings, including packet ensembles (back-to-back at server rate); and
o 以受控速率和可变数据包间隔生成数据包流，包括数据包集合（以服务器速率背靠背）；和
o continue the configured sending stream characteristics despite all control indications except receive-window exhaust.
o 尽管有除接收窗口排气外的所有控制指示，仍继续配置发送流特性。
The corresponding TCP RECEIVER performs normally, having some ability to configure the receive window sufficiently large so as to allow the SENDER to transmit at will (up to a configured target).
相应的TCP接收器正常运行，能够配置足够大的接收窗口，以便允许发送方随意发送（直到配置的目标）。
It may also be useful (for diagnostic purposes) to provide a control for the bulk transfer capacity measurement with fully-specified (and congestion-controlled) TCP senders and receivers, as envisioned in [RFC3148], but this would be a brute-force assessment, which does not follow the conservative tenets of IPPM measurement [RFC2330].
按照[RFC3148]中的设想，为具有完全指定（和拥塞控制）的TCP发送方和接收方的大容量传输容量测量提供控制也是有用的（出于诊断目的），但这将是一种蛮力评估，不符合IPPM测量[RFC2330]的保守原则。
Measurements for each UDP test packet transferred between SENDER and RECEIVER MUST be compliant with the singleton measurement methods described in IPPM RFCs [RFC2679][RFC2680]. The timestamp information or loss/arrival status for each packet MUST be available for communication to the REPORTER function.
发送方和接收方之间传输的每个UDP测试数据包的测量必须符合IPPM RFCs[RFC2679][RFC2680]中描述的单例测量方法。每个数据包的时间戳信息或丢失/到达状态必须可用于与报告程序功能的通信。
In summary, the test protocol must support the measurement features described in the sections above. This requires:
总之，测试协议必须支持上述章节中描述的测量功能。这需要：
1. Communicating all test variables to the SENDER and RECEIVER;
1. 向发送方和接收方传达所有测试变量；
2. Results collection in a one-way architecture;
2. 单向体系结构中的结果收集；
3. Remote device control for both one-way and two-way architectures; and
3. 单向和双向架构的远程设备控制；和
4. Asymmetric packet rates in a two-way measurement architecture, or coordinated one-way test capabilities with the same effect (asymmetric rates may be achieved through directional control of packet rate or packet size).
4. 双向测量体系结构中的非对称数据包速率，或具有相同效果的协调单向测试能力（可通过数据包速率或数据包大小的定向控制实现非对称速率）。
The ability to control and generate asymmetric rates in a two-way architecture is REQUIRED. Two-way architectures are RECOMMENDED to include control and generation capability for both asymmetric and symmetric packet sizes because packet size often matters in the scope of this problem and test systems SHOULD be equipped to detect directional size dependency through comparative measurements.
需要在双向体系结构中控制和生成不对称速率的能力。建议双向体系结构包括不对称和对称数据包大小的控制和生成能力，因为数据包大小通常在该问题的范围内起作用，并且应配备测试系统，以便通过比较测量来检测方向大小相关性。
Asymmetric packet size control is indicated when the result of a measurement may depend on the size of the packets used in each direction, i.e., when any of the following conditions hold:
当测量结果可能取决于每个方向上使用的数据包的大小时，即，当以下任一条件成立时，指示不对称数据包大小控制：
o there is a link in the path with asymmetrical capacity in opposite directions (in combination with one or more of the conditions below, but their presence or specific details may be unknown to the tester);
o 路径中存在反向不对称容量的链路（结合以下一个或多个条件，但测试人员可能不知道其存在或具体细节）；
o there is a link in the path that aggregates (or divides) packets into link-level frames and may have a capacity that depends on packet size, rate, or timing;
o 路径中存在将分组聚合（或划分）为链路级帧的链路，并且其容量取决于分组大小、速率或定时；
o there is a link in the path where transmission in one direction influences performance in the opposite direction;
o 路径中存在链路，其中一个方向的传输影响相反方向的性能；
o there is a device in the path where transmission capacity depends on packet header processing capacity (in other words, the capacity is sensitive to packet size);
o 路径中存在传输容量取决于分组报头处理容量的设备（换句话说，容量对分组大小敏感）；
o the target application stream is nominally MTU size packets in one direction versus ACK stream in the other (noting that there are a vanishing number of symmetrical rate application streams for which rate measurement is wanted or interesting but such streams might have some relevance at this time);
o 目标应用流在一个方向上名义上是MTU大小的分组，而在另一个方向上是ACK流（注意，对于需要速率测量或感兴趣的对称速率应用流，存在逐渐消失的数目，但是这些流此时可能具有某种相关性）；
o the distribution of packet losses is critical to rate assessment;
o 分组丢失的分布对速率评估至关重要；
and possibly other circumstances revealed by measurements comparing streams with symmetrical size and asymmetrical size.
以及通过比较对称大小和非对称大小的河流的测量可能揭示的其他情况。
Implementations may support control and generation for only symmetric packet sizes when none of the above conditions hold.
当上述条件均不成立时，实现可能仅支持对称数据包大小的控制和生成。
The test protocol SHOULD enable measurement of the capacity metric [RFC5136] either Out-of-Service, In-Service, or both; other metrics [RFC5136] are OPTIONAL.
测试协议应能够测量容量度量[RFC5136]，可以是停用的，也可以是在用的，或者两者兼而有之；其他指标[RFC5136]是可选的。
The security considerations that apply to any active measurement of live networks are relevant here as well. See [RFC4656] and [RFC5357].
适用于实时网络的任何主动测量的安全注意事项也与此相关。参见[RFC4656]和[RFC5357]。
Privacy considerations for measurement systems, particularly when Internet users participate in the tests in some way, are described in [LMAP-FRAMEWORK].
[LMAP-FRAMEWORK]中描述了测量系统的隐私注意事项，特别是当互联网用户以某种方式参与测试时。
There may be a serious issue if a proprietary service level agreement involved with the access network segment provider were somehow leaked in the process of rate measurement. To address this, test protocols SHOULD NOT convey this information in a way that could be discovered by unauthorized parties.
如果接入网段提供商涉及的专有服务级别协议在速率测量过程中不知何故泄漏，则可能会出现严重问题。为了解决这一问题，测试协议不应以未经授权方可能发现的方式传递此信息。
All forms of testing originate network traffic, either through their communications for control and results collection, from dedicated measurement packet streams, or from a combination of both types of traffic. Testing traffic primarily falls in one of two categories: subscriber traffic or network management traffic. There is an ongoing need to engineer networks so that various forms of traffic are adequately served, and publication of this memo does not change this need. Service subscribers and authorized users SHOULD obtain their network operator's or service provider's permission before conducting tests. Likewise, a service provider or third party SHOULD obtain the subscriber's permission to conduct tests, since they might temporarily reduce service quality. The protocol SHOULD communicate the permission status once the overall system has obtained it, either explicitly or through other means.
所有形式的测试都源自网络流量，或者通过其控制和结果收集通信，或者来自专用测量数据包流，或者来自这两种类型流量的组合。测试流量主要分为两类：用户流量或网络管理流量。有一个持续的需求，工程网络，使各种形式的交通得到充分的服务，本备忘录的发布不会改变这种需求。服务用户和授权用户应在进行测试之前获得其网络运营商或服务提供商的许可。同样，服务提供商或第三方应获得订户的许可进行测试，因为它们可能会暂时降低服务质量。一旦整个系统获得许可状态，协议应明确地或通过其他方式传达该许可状态。
Subscribers, their service providers and network operators, and sometimes third parties, all seek to measure network performance. Capacity testing with active traffic often affects the packet transfer performance of streams traversing shared components of the test path, to some degree. The degradation can be minimized by scheduling such tests infrequently and restricting the amount of measurement traffic required to assess capacity metrics. As a result, occasional short-duration estimates with minimal traffic are preferred to measurements based on frequent file transfers of many megabytes with similar accuracy. New measurement methodologies intended for standardization should be evaluated individually for potential operational issues. However, the scheduled frequency of testing is as important as the methods used (and schedules are not typically submitted for standardization).
订户、其服务提供商和网络运营商，有时还有第三方，都寻求衡量网络性能。使用活动流量进行容量测试通常会在一定程度上影响穿过测试路径共享组件的流的数据包传输性能。通过不频繁地安排此类测试并限制评估容量指标所需的测量流量，可以将降级降至最低。因此，与基于具有类似精度的多兆字节频繁文件传输的测量结果相比，更倾向于使用最小流量偶尔进行短期估计。针对潜在的操作问题，应单独评估用于标准化的新测量方法。但是，计划的测试频率与使用的方法一样重要（并且计划通常不提交标准化）。
The new test protocol feature of asymmetrical packet size generation in two-way testing is recommended in this memo. It can appreciably reduce the load and packet processing demands of each test and therefore reduce the likelihood of degradation in one direction of the tested path. Current IETF standardized test protocols (e.g., [RFC5357] and [RFC6812]) do not possess the asymmetric size generation capability with two-way testing.
本备忘录中推荐了在双向测试中生成非对称数据包大小的新测试协议特性。它可以显著降低每个测试的负载和数据包处理需求，从而降低测试路径一个方向上的降级可能性。当前的IETF标准化测试协议（如[RFC5357]和[RFC6812]）不具备双向测试的不对称大小生成能力。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998, <http://www.rfc-editor.org/info/rfc2330>.
[RFC2330]Paxson，V.，Almes，G.，Mahdavi，J.，和M.Mathis，“IP性能度量框架”，RFC 2330，1998年5月<http://www.rfc-editor.org/info/rfc2330>.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999, <http://www.rfc-editor.org/info/rfc2679>.
[RFC2679]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月<http://www.rfc-editor.org/info/rfc2679>.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999, <http://www.rfc-editor.org/info/rfc2680>.
[RFC2680]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向数据包丢失度量”，RFC 26801999年9月<http://www.rfc-editor.org/info/rfc2680>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006, <http://www.rfc-editor.org/info/rfc4656>.
[RFC4656]Shalunov，S.，Teitelbaum，B.，Karp，A.，Boote，J.，和M.Zekauskas，“单向主动测量协议（OWAMP）”，RFC 46562006年9月<http://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008, <http://www.rfc-editor.org/info/rfc5357>.
[RFC5357]Hedayat，K.，Krzanowski，R.，Morton，A.，Yum，K.，和J.Babiarz，“双向主动测量协议（TWAMP）”，RFC 5357，2008年10月<http://www.rfc-editor.org/info/rfc5357>.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, August 2012, <http://www.rfc-editor.org/info/rfc6703>.
[RFC6703]Morton，A.，Ramachandran，G.，和G.Maguluri，“报告IP网络性能指标：不同观点”，RFC 67032012年8月<http://www.rfc-editor.org/info/rfc6703>.
[IPPM-METRICS] Mathis, M. and A. Morton, "Model Based Bulk Performance Metrics", Work in Progress, draft-ietf-ippm-model-based-metrics-04, March 2015.
[IPPM-METRICS]Mathis，M.和A.Morton，“基于模型的批量性能度量”，正在进行的工作，草稿-ietf-IPPM-Model-Based-METRICS-042015年3月。
[LMAP-FRAMEWORK] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A framework for Large-Scale Measurement of Broadband Performance (LMAP)", Work in Progress, draft-ietf-lmap-framework-12, March 2015.
[LMAP-FRAMEWORK]Eardley，P.，Morton，A.，Bagnulo，M.，Burbridge，T.，Aitken，P.，和A.Akhter，“宽带性能大规模测量框架（LMAP）”，正在进行的工作，草案-ietf-LMAP-FRAMEWORK-12，2015年3月。
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001, <http://www.rfc-editor.org/info/rfc3148>.
[RFC3148]Mathis，M.和M.Allman，“定义经验批量传输容量指标的框架”，RFC 3148，2001年7月<http://www.rfc-editor.org/info/rfc3148>.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008, <http://www.rfc-editor.org/info/rfc5136>.
[RFC5136]Chimento，P.和J.Ishac，“定义网络容量”，RFC 5136，2008年2月<http://www.rfc-editor.org/info/rfc5136>.
[RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, S., and E. Yedavalli, "Cisco Service-Level Assurance Protocol", RFC 6812, January 2013, <http://www.rfc-editor.org/info/rfc6812>.
[RFC6812]Chiba，M.，Clemm，A.，Medley，S.，Salowey，J.，Thombare，S.，和E.Yedavalli，“思科服务水平保证协议”，RFC 6812，2013年1月<http://www.rfc-editor.org/info/rfc6812>.
[RFC7398] Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and A. Morton, "A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance", RFC 7398, February 2015, <http://www.rfc-editor.org/info/rfc7398>.
[RFC7398]Bagnulo，M.，Burbridge，T.，Crawford，S.，Eardley，P.，和A.Morton，“宽带性能大规模测量的参考路径和测量点”，RFC 7398，2015年2月<http://www.rfc-editor.org/info/rfc7398>.
Acknowledgements
致谢
Dave McDysan provided comments and text for the aggregated leased use case. Yaakov Stein suggested many considerations to address, including the In-Service vs. Out-of-Service distinction and its implication on test traffic limits and protocols. Bill Cerveny, Marcelo Bagnulo, Kostas Pentikousis (a persistent reviewer), and Joachim Fabini have contributed insightful, clarifying comments that made this a better document. Barry Constantine also provided suggestions for clarification.
Dave McDysan为聚合租赁用例提供了注释和文本。Yaakov Stein提出了许多需要考虑的问题，包括服务内与服务外的区别及其对测试流量限制和协议的影响。比尔·塞尔维尼、马塞洛·巴格努洛、科斯塔斯·彭蒂库西斯（一位持之以恒的评论家）和约阿希姆·法比尼（Joachim Fabini）发表了见解深刻、清晰的评论，使本文件成为一份更好的文件。巴里·康斯坦丁也提出了澄清的建议。
Author's Address
作者地址
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States
美国新泽西州劳雷尔大道南米德尔顿200号阿尔莫顿AT&T实验室，邮编：07748
Phone: +1 732 420 1571
Fax: +1 732 368 1192
EMail: acmorton@att.com
URI: http://home.comcast.net/~acmacm/
Phone: +1 732 420 1571
Fax: +1 732 368 1192
EMail: acmorton@att.com
URI: http://home.comcast.net/~acmacm/