Network Working Group S. Shalunov
Request for Comments: 3763 B. Teitelbaum
Category: Informational Internet2
April 2004
Network Working Group S. Shalunov
Request for Comments: 3763 B. Teitelbaum
Category: Informational Internet2
April 2004
One-way Active Measurement Protocol (OWAMP) Requirements
单向主动测量协议（OWAMP）要求
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) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss.
随着良好时间源对网络节点的可用性不断提高，以高精度测量单向IP性能指标变得越来越可能。为了以可互操作的方式进行测量，需要一个用于此类测量的通用协议。本文件规定了单向主动测量协议（OWAMP）标准的要求。该协议可以测量单向延迟以及其他单向特性，如单向损耗。
The IETF IP Performance Metrics (IPPM) working group has proposed standards track metrics for one-way packet delay [RFC2679] and loss [RFC 2680] across Internet paths. Although there are now several measurement platforms that implement the collection of these metrics ([CQOS], [BRIX], [RIPE], [SURVEYOR]), there is not currently a standard for interoperability. This requirements document is aimed at defining a protocol that allows users to do measurements using devices from different vendors at both ends and get meaningful results.
IETF IP性能度量（IPPM）工作组提出了跨互联网路径的单向数据包延迟[RFC2679]和丢失[RFC 2680]的标准跟踪度量。尽管现在有几个度量平台实现这些度量的集合（[CQO]、[BRIX]、[Rime]、[SURVEYOR]），但目前还没有一个互操作性标准。本需求文件旨在定义一个协议，允许用户使用两端不同供应商的设备进行测量，并获得有意义的结果。
With the increasingly wide availability of affordable global positioning system (GPS) and CDMA based time sources, hosts increasingly have available to them time sources that allow hosts to time-stamp packets with accuracies substantially better than the delays seen on the Internet--either directly or through their proximity to NTP primary (stratum 1) time servers. By standardizing a technique for collecting IPPM one-way active measurements, we hope to create an environment where these metrics may be collected across
随着价格合理的全球定位系统（GPS）和基于CDMA的时间源的可用性越来越广泛，主机越来越多地拥有时间源，这些时间源允许主机对数据包进行时间戳，其准确度大大优于互联网上所见的延迟——直接或通过其接近NTP主数据包（第1层）时间服务器。通过标准化收集IPPM单向活动度量的技术，我们希望创建一个跨平台收集这些度量的环境
a far broader mesh of Internet paths than is currently possible. One particularly compelling vision is of widespread deployment of open one-way active measurement beacons that would make measurements of one-way delay as commonplace as measurements of round-trip time are today using ICMP-based tools like ping. Even without very accurate timestamps one can measure characteristics such as loss with quality acceptable for many practical purposes, e.g., network operations.
一个比目前更广泛的互联网路径网。一个特别引人注目的愿景是广泛部署开放式单向主动测量信标，这将使单向延迟测量变得像今天使用基于ICMP的工具（如ping）测量往返时间一样常见。即使没有非常精确的时间戳，人们也可以测量诸如损耗等特性，其质量可为许多实际目的所接受，例如网络操作。
To support interoperability between alternative OWAMP implementations and make possible a world where "one-way ping" could become commonplace, a standard is required that specifies how test streams are initiated, how test packets are exchanged, and how test results are retrieved. Detailed functional requirements are given in the subsequent section.
为了支持可选OWAMP实现之间的互操作性并使“单向ping”成为可能，需要一个标准来指定如何启动测试流、如何交换测试数据包以及如何检索测试结果。详细的功能要求见下一节。
The protocol(s) should provide the ability to measure, record, and distribute the results of measurements of one-way singleton network characteristics such as characteristics defined in [RFC2679] and [RFC2680]. Result reporting, sampling, and time stamps are to be within the framework of [RFC2330].
协议应提供测量、记录和分发单向单例网络特性测量结果的能力，如[RFC2679]和[RFC2680]中定义的特性。结果报告、取样和时间戳应在[RFC2330]的框架内。
It should be possible to measure arbitrary one-way singleton characteristics (e.g., loss, median delay, mean delay, jitter, 90th percentile of delay, etc.); this is achieved by keeping all the raw data for post-processing by the final data consumer, as specified in section 2.1. Since RFC2679 and RFC2680 standardize metrics based on Poisson sampling processes, Poisson streams must be supported by the protocol(s).
应能够测量任意单向单态特性（例如，损耗、中值延迟、平均延迟、抖动、延迟的第90个百分位数等）；按照第2.1节的规定，这是通过保留所有原始数据以供最终数据使用者进行后处理来实现的。由于RFC2679和RFC2680标准化了基于泊松采样过程的度量，协议必须支持泊松流。
Non-singleton characteristics (such as those related to trains of packets, back-to-back tuples, and so forth) and application traffic simulation need not be addressed. However, they may be addressed if considered practical and not in contradiction to other design goals.
非单例特性（例如与数据包序列、背对背元组等相关的特性）和应用程序流量模拟不需要解决。但是，如果认为它们是可行的，并且与其他设计目标不矛盾，则可以解决这些问题。
To facilitate the broadest possible use of obtained measurement results, the protocol(s) should not necessitate any required post-processing. (This does not apply to implementation details such as converting timestamps from ticks since midnight into a canonical form or applying calibration constants; such details should naturally be hidden.) All data obtained during a measurement session should be available after the session is finished if desired by the data consumer so that various characteristics can be computed from the raw data using arbitrary algorithms.
为了尽可能广泛地使用所获得的测量结果，协议不需要进行任何必要的后处理。（这不适用于实现细节，例如将时间戳从午夜后的滴答声转换为标准形式或应用校准常数；这些细节应该自然隐藏。）如果数据使用者需要，在测量会话期间获得的所有数据应在会话结束后可用，以便可以使用任意算法从原始数据计算各种特性。
A means to distribute measurement results (between hosts participating in a measurement session and beyond) should be provided. Since there can exist a wide variety of scenarios as to where the final data destination should be, these should be invoked separately from measurement requests (e.g., receiver should not have to automatically send measurement results to the sender, since it may be the receiver or a third host that are the ultimate data destination).
应提供一种分发测量结果的方法（在参与测量会话的主机之间以及其他主机之间）。由于最终数据目的地的位置可能存在各种各样的场景，因此这些场景应与测量请求分开调用（例如，接收方不必自动向发送方发送测量结果，因为接收方或第三台主机可能是最终数据目的地）。
At the same time, ability to transfer results directly to their destination (without need for potentially large intermediate transfers) should be provided.
同时，应提供将结果直接传输到目的地的能力（无需潜在的大型中间传输）。
Since measurement session setup and the actual measurement session (i) are different tasks; (ii) require different levels of functionality, flexibility, and implementation effort; (iii) may need to run over different transport protocols, there should exist two protocols: one for conducting the actual measurement session and another for session setup/teardown/confirmation/retrieval. These protocols are further referred to as OWAMP-Test and OWAMP-Control, respectively.
由于测量会话设置和实际测量会话（i）是不同的任务；（ii）需要不同级别的功能、灵活性和实施工作；（iii）可能需要运行不同的传输协议，应存在两个协议：一个用于执行实际测量会话，另一个用于会话设置/拆卸/确认/检索。这些协议进一步分别称为OWAMP测试和OWAMP控制。
It should be possible to use devices that only support OWAMP-Test but not OWAMP-Control to conduct measurement sessions (such devices will necessarily need to support one form of session setup protocol or the other, but it doesn't have to be known to external parties).
应该可以使用仅支持OWAMP测试但不支持OWAMP控制的设备来进行测量会话（此类设备必须支持一种或另一种形式的会话设置协议，但外部各方不必知道）。
OWAMP-Control would thus become a common protocol for different administrative domains, which may or may not use it for session setup internally.
因此，OWAMP控制将成为不同管理域的通用协议，这些管理域可能在内部使用它进行会话设置，也可能不使用它。
The test protocol needs to be implemented on all measurement nodes and should therefore have the following characteristics:
测试协议需要在所有测量节点上实施，因此应具有以下特征：
+ Be lightweight and easy to implement.
+ 轻量级且易于实现。
+ Be suitable for implementation on a wide range of measurement nodes.
+ 适用于广泛的测量节点。
+ Allow UDP as the transport protocol, since the protocol needs to be able to measure individual packet delivery times and has to run on various machines (see the section "Support for Measurements with Different Packet Types" below for further discussion).
+ 允许UDP作为传输协议，因为该协议需要能够测量单个数据包的交付时间，并且必须在各种机器上运行（有关进一步讨论，请参阅下面的“对不同数据包类型的测量的支持”一节）。
+ Support varying packet sizes and network services (e.g., DSCP marking).
+ 支持不同的数据包大小和网络服务（例如，DSCP标记）。
+ Be as simple as possible, but no simpler than necessary to implement requirements set forth in this document; the OWAMP-Test packet format should include only universally meaningful fields, and minimum number of them.
+ 尽可能简单，但不应比实施本文件规定要求所需的简单；OWAMP测试数据包格式应仅包括具有普遍意义的字段，以及它们的最小数量。
+ If practical, it should be possible to generate OWAMP-Test packets small enough, so that when encapsulated, each fits inside a single ATM cell.
+ 如果可行，应该可以生成足够小的OWAMP测试数据包，以便在封装时，每个数据包都可以装入单个ATM信元中。
+ Data needed to calculate experimental errors on the final result should be included in every OWAMP-Test packet.
+ 计算最终结果的实验误差所需的数据应包含在每个OWAMP测试包中。
Control protocol needs to provide the capability to:
控制协议需要提供以下能力：
+ authenticate peers to each other using a common authentication method that doesn't require building any new authentication infrastructure, such as user ID and a shared secret;
+ 使用不需要构建任何新的身份验证基础设施（如用户ID和共享秘密）的通用身份验证方法相互验证对等点；
+ schedule zero or more OWAMP-Test sessions (which do not have to be between the peers of OWAMP-Control conversation);
+ 安排零个或多个OWAMP测试会话（不必在OWAMP控制会话的对等方之间）；
+ start OWAMP-Test sessions simultaneously or at a pre-scheduled per-session times;
+ 同时启动OWAMP测试会话，或按预定的每次会话时间启动；
+ retrieve OWAMP-Test session results (of OWAMP-Test sessions scheduled in the current and other OWAMP-Control sessions);
+ 检索OWAMP测试会话结果（当前和其他OWAMP控制会话中计划的OWAMP测试会话的结果）；
+ confirm graceful completion of sessions and allow either side to abort a session prematurely.
+ 确认会话正常完成，并允许任意一方提前中止会话。
The OWAMP-Control design should not preclude the ability to record extended periods of losses. It should always provide peers with the ability to distinguish between network and peer failures.
OWAMP控制设计不应排除记录长时间损失的能力。它应始终为对等方提供区分网络故障和对等方故障的能力。
Since the notion of a packet of type P from [RFC2330], section 13 doesn't always imply precise definition of packet type, some decisions narrowing the scope of possible packet types need to be made at measurement protocol design stage. Further, measurement with packets of certain types, while feasible in more closed settings than those implied by OWAMP, become very hard to perform in an open inter-domain fashion (e.g., measurements with particular packets with broken IP checksum or particular loose source routing options).
由于[RFC2330]中类型为P的数据包的概念，第13节并不总是暗示数据包类型的精确定义，因此需要在测量协议设计阶段做出一些缩小可能数据包类型范围的决定。此外，使用特定类型的数据包进行测量，虽然在比OWAMP所暗示的更封闭的设置中是可行的，但在开放域间方式中变得非常难以执行（例如，使用具有中断IP校验和或特定松散源路由选项的特定数据包进行测量）。
In addition, very general packet type specification could result in several problems:
此外，非常通用的数据包类型规范可能会导致几个问题：
+ Many OWAMP-Test speakers will be general purpose computers with a multitasking operating system that includes a socket interface. These will inevitably have higher losses when listening to raw network traffic. Raw sockets will induce higher loss rate than one would have with UDP measurements.
+ 许多OWAMP测试扬声器将是带有多任务操作系统的通用计算机，该操作系统包括一个套接字接口。在收听原始网络流量时，这些将不可避免地有更高的损失。原始套接字将导致比UDP测量更高的丢失率。
+ It's not at all clear (short of standardizing tcpdump syntax) how to describe formally the filter that a receiver should use to listen for test traffic.
+ 如何正式地描述接收器应该用来监听测试流量的过滤器还不清楚（缺少标准化的tcpdump语法）。
+ Suppose an identity of an authenticated user becomes compromised. Now the attacker could use that to run TCP sessions to the rlogin port of machines around servers that trust this user to perform measurements (or, less drastically, to send spam from that network). The ability to perform measurements is transformed into an ability to generate arbitrary traffic on behalf of all the senders an OWAMP-Control server controls.
+ 假设经过身份验证的用户的身份被泄露。现在，攻击者可以利用它在信任该用户执行测量的服务器周围的计算机的rlogin端口上运行TCP会话（或者，不太激烈地从该网络发送垃圾邮件）。执行测量的能力转化为代表OWAMP控制服务器控制的所有发送方生成任意通信量的能力。
+ Carefully crafted packets could cause disruption to some link-layer protocols. Implementors can't know what to disallow (scrambling is different for different link-layer technologies).
+ 精心编制的数据包可能会中断某些链路层协议。实现者不知道禁止什么（对于不同的链路层技术，加扰是不同的）。
It appears that allowing one to ask a measurement server to generate arbitrary packets becomes an unmanageable security hole and a formidable specification and implementation hurdle.
看来，允许一个测量服务器生成任意数据包会成为一个难以管理的安全漏洞和一个强大的规范和实现障碍。
For these reasons, we only require OWAMP to support a small subspace of the whole packet type space. Namely, it should be possible to conduct measurements with a given Differentiated Services Codepoint (DSCP) [RFC2474] or a given Per Hop Behavior Identification Code (PHB ID) [RFC3140].
由于这些原因，我们只需要OWAMP来支持整个数据包类型空间的一个子空间。也就是说，应该可以使用给定的区分服务代码点（DSCP）[RFC2474]或给定的每跳行为标识码（PHB ID）[RFC3140]进行测量。
While some measurement architecture designs have inherent scalability problems (e.g., a full mesh of always-on measurements among N measurement nodes requires O(N^2) total resources, such as storage space and link capacity), OWAMP itself should not exaggerate the problem or make it impossible (where it is in principle possible) to design other architectures that are free of scalability deficiencies.
虽然一些测量体系结构设计存在固有的可伸缩性问题（例如，N个测量节点之间的全网格始终在线测量需要O（N^2）总资源，如存储空间和链路容量），但OWAMP本身不应夸大问题或使其不可能（在原则上可能的情况下）设计其他没有可伸缩性缺陷的架构。
It is the protocol user's responsibility to decide how to use the protocol and which measurements to conduct.
协议用户有责任决定如何使用协议以及进行哪些测量。
It should be possible to authenticate peers to each other using a user ID and a shared secret. It should be infeasible for any external party without knowledge of the shared secret to obtain any information about it by observing, initiating, or modifying protocol transactions.
应该可以使用用户ID和共享秘密相互验证对等点。在不知道共享秘密的情况下，任何外部方都不可能通过观察、发起或修改协议事务来获取有关共享秘密的任何信息。
It should also be infeasible for such party to use any information obtained by observing, modifying or initiating protocol transactions to impersonate (other) valid users.
该方也不可能使用通过观察、修改或启动协议事务获得的任何信息来冒充（其他）有效用户。
Authorization shall normally be performed on the basis of the authenticated identity (such as username) and the specification shall require all implementations to support such a mode of authorization. Different identities (or classes of identities) can have different testing privileges. The use of authorization for arriving at specific policy decisions (such as whether to allow a specific test with a specific source and destination and with a given test send schedule -- which would determine the average network capacity utilization -- at a given time) is up to the users.
授权通常应基于经过身份验证的身份（如用户名）执行，规范应要求所有实现支持这种授权模式。不同的身份（或身份类别）可以具有不同的测试权限。用户可以使用授权来做出特定的策略决策（例如是否允许使用特定的源和目标以及给定的测试发送时间表进行特定的测试，这将决定在给定时间的平均网络容量利用率）。
4.3. Being Hard to Interfere with by Applying Special Treatment to Measurement Packets
4.3. 对测量数据包进行特殊处理，不易干扰
The design of the protocol should make it possible to run sessions that would make it very difficult for any intermediate party to make results appear better than they would be if no interference was attempted.
协议的设计应使运行会话成为可能，这将使任何中间方都很难使结果看起来比不进行干扰时更好。
This is different from cryptographic assurance of data integrity, because one can manipulate the results without changing any data in the packets. For example, if OWAMP-Test packets are easy to identify (e.g., they all come to a well-known port number), an intermediate party might place OWAMP-Test traffic into a priority queue at a congested link thus ensuring that the results of the measurement appear better than what would be experienced by other traffic. It should not be easy for intermediate parties to identify OWAMP-Test packets (just as it should not be easy for restaurants to identify restaurant critics).
这与数据完整性的加密保证不同，因为可以在不更改数据包中任何数据的情况下操作结果。例如，如果OWAMP测试数据包很容易识别（例如，它们都到达一个众所周知的端口号），中间方可能会将OWAMP测试流量放入拥塞链路的优先级队列中，从而确保测量结果比其他流量更好。对于中间方来说，识别OWAMP测试包应该不容易（就像餐厅识别餐厅批评者一样）。
It should be possible to make it infeasible for any outside party without knowledge of the shared secret being used to learn what information is exchanged using OWAMP-Control by inspecting an OWAMP-Control stream or actively modifying it.
通过检查OWAMP控制流或主动修改OWAMP控制流，在不知道使用共享秘密来了解使用OWAMP控制交换的信息的情况下，应该可以使任何外部方都不可行。
(It is recognized that some information will inevitably leak from the mere fact of communication and from the presence and timing of concurrent and subsequent OWAMP-Test traffic.)
（人们认识到，一些信息将不可避免地从单纯的通信事实以及并发和后续OWAMP测试流量的存在和定时中泄漏。）
So that it is possible to detect any interference during a conversation (other than the detention of some messages), facility must be provided to authenticate each message of the OWAMP-Control protocol, its attribution to a given session, and its exact placement in the sequence of control protocol exchanges.
为了能够在对话过程中检测到任何干扰（某些消息的保留除外），必须提供设施来验证OWAMP控制协议的每条消息、其对给定会话的属性以及其在控制协议交换序列中的确切位置。
It must also be possible to authenticate each message of the test protocol and its attribution to a specific session, so that modifications of OWAMP-Test messages can be detected. It must be possible to do this in a fashion that does not require timestamps themselves to be encrypted; in this case, security properties are valid only when an attacker cannot observe valid traffic between the OWAMP-Test sender and receiver.
还必须能够验证测试协议的每条消息及其对特定会话的属性，以便能够检测到OWAMP测试消息的修改。必须能够以不需要对时间戳本身进行加密的方式实现这一点；在这种情况下，只有当攻击者无法观察到OWAMP测试发送方和接收方之间的有效通信量时，安全属性才有效。
OWAMP-Control must be resistant to any replay attacks.
OWAMP控件必须抵抗任何重播攻击。
OWAMP-Test, on the other hand, is a protocol for network measurement. One of the attributes of networks is packet duplication. OWAMP-Test has to be suitable for measurement of duplication. This would make it vulnerable to attacks that involve replaying a recent packet. For the recipient of such a packet it is impossible to determine whether the duplication is malicious or naturally occurring.
另一方面，OWAMP测试是一种网络测量协议。网络的属性之一是数据包复制。OWAMP测试必须适用于重复测量。这将使它容易受到涉及重播最近数据包的攻击。对于此类数据包的接收者，不可能确定复制是恶意的还是自然发生的。
OWAMP-Test should measure all duplication -- malicious or otherwise. Note that this is similar to delay attacks: an attacker can hold up a packet for some short period of time and then release it to continue on its way to the recipient. There's no way such delay can be reliably distinguished from naturally occurring delay by the recipient.
OWAMP测试应测量所有复制--恶意复制或其他复制。请注意，这类似于延迟攻击：攻击者可以在短时间内保留数据包，然后释放数据包以继续发送给收件人。接受者无法可靠地将这种延迟与自然发生的延迟区分开来。
OWAMP-Test should measure the network as it was. Note, however, that this does not prevent the data from being sanitized at a later stage of processing, analysis, or consumption. Some sanity checks (those that are deemed reliable and erring on the side of inclusion) should be performed by OWAMP-Test recipient immediately.
OWAMP测试应按原样测量网络。但是，请注意，这并不妨碍在后期处理、分析或使用阶段对数据进行消毒。OWAMP测试接受者应立即进行一些健全性检查（那些被认为是可靠的且在纳入方面存在错误的检查）。
Since the protocol(s) will be used in widely varying circumstances using widely varying equipment, it is necessary to be able to support varying degrees of security modes of operation. The parameters to be considered include: confidentiality, data origin authentication, integrity and replay protection.
由于协议将在使用各种设备的各种情况下使用，因此必须能够支持不同程度的安全操作模式。需要考虑的参数包括：机密性、数据源身份验证、完整性和重播保护。
It should also be possible to operate in a mode where all security mechanisms are enabled and security objectives are realized to the fullest extent possible. We call this "encrypted mode".
还应能够在启用所有安全机制并尽可能充分实现安全目标的模式下运行。我们称之为“加密模式”。
Since timestamp encryption takes a certain amount of time, which may be hard to predict on some devices (with a time-sharing OS), a mode should be provided that is similar to encrypted mode, but in which timestamps are not encrypted. In this mode, all security properties of the encrypted mode that can be retained without timestamp encryption should be present. We call this "authenticated mode".
由于时间戳加密需要一定的时间，这在某些设备（使用分时操作系统）上可能很难预测，因此应提供一种类似于加密模式但时间戳不加密的模式。在此模式下，应存在加密模式的所有安全属性，这些属性可以在不使用时间戳加密的情况下保留。我们称之为“认证模式”。
It should be possible to operate in a completely "open" mode, where no cryptographic security mechanisms are used. We call this "unauthenticated mode". In this mode, mandatory-to-use mechanisms must be specified that prevent the use of the protocol for network capacity starvation denial-of-service attacks (e.g., only sending test data back to the client that requested them to be sent with the request delivered over a TCP connection), and that prevent a worm from using the protocol to send test data to a very large number of hosts in a short time (e.g., ensuring that open mode requests can only be made by humans, rate-limiting the acceptance of open mode requests).
它应该可以在完全“开放”模式下运行，其中不使用加密安全机制。我们称之为“未经验证的模式”。在此模式下，必须指定强制使用机制，以防止将协议用于网络容量不足拒绝服务攻击（例如，仅将测试数据发送回请求通过TCP连接发送的客户端），防止蠕虫使用协议在短时间内向大量主机发送测试数据（例如，确保开放模式请求只能由人发出，限制开放模式请求的接受率）。
To make implementation more manageable, the number of other options and modes should be kept to the absolute practical minimum. Where choosing a single mechanism for achieving anything related to security is possible, such choice should be made at specification phase and be put into the standard.
为了使实施更易于管理，其他选项和模式的数量应保持在绝对实用的最低限度。如果可以选择单一机制来实现与安全相关的任何功能，则应在规范阶段进行选择，并将其纳入标准。
Relevant IANA considerations will be placed into the protocol specification document itself, and not into the requirements document.
相关IANA注意事项将放在协议规范文件本身中，而不是放在需求文件中。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]Paxson，V.，Almes，G.，Mahdavi，J.和M.Mathis，“IP性能度量框架”，RFC 2330，1998年5月。
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes，G.，Kalidini，S.和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月。
[RFC2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680]Almes，G.，Kalidini，S.和M.Zekauskas，“IPPM的单向分组丢失度量”，RFC 2680，1999年9月。
[RFC3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC3140]Black，D.，Brim，S.，Carpenter，B.和F.Le Faucheur，“每跳行为识别码”，RFC 31402001年6月。
[BRIX] Brix 1000 Verifier,
http://www.brixnet.com/products/brix1000.html
[BRIX] Brix 1000 Verifier,
http://www.brixnet.com/products/brix1000.html
[CQOS] CQOS Home Page, http://www.cqos.com/
[CQOS] CQOS Home Page, http://www.cqos.com/
[RIPE] RIPE NCC Test-Traffic Measurements home,
http://www.ripe.net/test-traffic/
[RIPE] RIPE NCC Test-Traffic Measurements home,
http://www.ripe.net/test-traffic/
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/
Stanislav Shalunov
斯坦尼斯拉夫·沙卢诺夫
EMail: shalunov@internet2.edu
EMail: shalunov@internet2.edu
Benjamin Teitelbaum
本杰明·泰特尔鲍姆
EMail: ben@internet2.edu
EMail: ben@internet2.edu
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。