Network Working Group S. Shalunov
Request for Comments: 4656 B. Teitelbaum
Category: Standards Track A. Karp
J. Boote
M. Zekauskas
Internet2
September 2006
Network Working Group S. Shalunov
Request for Comments: 4656 B. Teitelbaum
Category: Standards Track A. Karp
J. Boote
M. Zekauskas
Internet2
September 2006
A One-way Active Measurement Protocol (OWAMP)
一种单向主动测量协议（OWAMP）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements.
单向主动测量协议（OWAMP）测量单向特性，如单向延迟和单向损耗。随着良好时间源（如GPS和CDMA）的更广泛可用性，这些单向IP性能指标的高精度测量成为可能。OWAMP支持这些度量的互操作性。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Relationship of Test and Control Protocols .................3
1.2. Logical Model ..............................................4
2. Protocol Overview ...............................................5
3. OWAMP-Control ...................................................6
3.1. Connection Setup ...........................................6
3.2. Integrity Protection (HMAC) ...............................11
3.3. Values of the Accept Field ................................11
3.4. OWAMP-Control Commands ....................................12
3.5. Creating Test Sessions ....................................13
3.6. Send Schedules ............................................18
3.7. Starting Test Sessions ....................................19
3.8. Stop-Sessions .............................................20
3.9. Fetch-Session .............................................24
1. Introduction ....................................................2
1.1. Relationship of Test and Control Protocols .................3
1.2. Logical Model ..............................................4
2. Protocol Overview ...............................................5
3. OWAMP-Control ...................................................6
3.1. Connection Setup ...........................................6
3.2. Integrity Protection (HMAC) ...............................11
3.3. Values of the Accept Field ................................11
3.4. OWAMP-Control Commands ....................................12
3.5. Creating Test Sessions ....................................13
3.6. Send Schedules ............................................18
3.7. Starting Test Sessions ....................................19
3.8. Stop-Sessions .............................................20
3.9. Fetch-Session .............................................24
4. OWAMP-Test .....................................................27
4.1. Sender Behavior ...........................................28
4.1.1. Packet Timings .....................................28
4.1.2. OWAMP-Test Packet Format and Content ...............29
4.2. Receiver Behavior .........................................33
5. Computing Exponentially Distributed Pseudo-Random Numbers ......35
5.1. High-Level Description of the Algorithm ...................35
5.2. Data Types, Representation, and Arithmetic ................36
5.3. Uniform Random Quantities .................................37
6. Security Considerations ........................................38
6.1. Introduction ..............................................38
6.2. Preventing Third-Party Denial of Service ..................38
6.3. Covert Information Channels ...............................39
6.4. Requirement to Include AES in Implementations .............39
6.5. Resource Use Limitations ..................................39
6.6. Use of Cryptographic Primitives in OWAMP ..................40
6.7. Cryptographic Primitive Replacement .......................42
6.8. Long-term Manually Managed Keys ...........................43
6.9. (Not) Using Time as Salt ..................................44
6.10. The Use of AES-CBC and HMAC ..............................44
7. Acknowledgements ...............................................45
8. IANA Considerations ............................................45
9. Internationalization Considerations ............................46
10. References ....................................................46
10.1. Normative References .....................................46
10.2. Informative References ...................................47
Appendix A: Sample C Code for Exponential Deviates ................49
Appendix B: Test Vectors for Exponential Deviates .................54
4. OWAMP-Test .....................................................27
4.1. Sender Behavior ...........................................28
4.1.1. Packet Timings .....................................28
4.1.2. OWAMP-Test Packet Format and Content ...............29
4.2. Receiver Behavior .........................................33
5. Computing Exponentially Distributed Pseudo-Random Numbers ......35
5.1. High-Level Description of the Algorithm ...................35
5.2. Data Types, Representation, and Arithmetic ................36
5.3. Uniform Random Quantities .................................37
6. Security Considerations ........................................38
6.1. Introduction ..............................................38
6.2. Preventing Third-Party Denial of Service ..................38
6.3. Covert Information Channels ...............................39
6.4. Requirement to Include AES in Implementations .............39
6.5. Resource Use Limitations ..................................39
6.6. Use of Cryptographic Primitives in OWAMP ..................40
6.7. Cryptographic Primitive Replacement .......................42
6.8. Long-term Manually Managed Keys ...........................43
6.9. (Not) Using Time as Salt ..................................44
6.10. The Use of AES-CBC and HMAC ..............................44
7. Acknowledgements ...............................................45
8. IANA Considerations ............................................45
9. Internationalization Considerations ............................46
10. References ....................................................46
10.1. Normative References .....................................46
10.2. Informative References ...................................47
Appendix A: Sample C Code for Exponential Deviates ................49
Appendix B: Test Vectors for Exponential Deviates .................54
The IETF IP Performance Metrics (IPPM) working group has defined metrics for one-way packet delay [RFC2679] and loss [RFC2680] across Internet paths. Although there are now several measurement platforms that implement collection of these metrics [SURVEYOR] [SURVEYOR-INET] [RIPE] [BRIX], there is not currently a standard that would permit initiation of test streams or exchange of packets to collect singleton metrics in an interoperable manner.
IETF IP性能度量（IPPM）工作组定义了跨互联网路径的单向数据包延迟[RFC2679]和丢失[RFC2680]的度量。尽管现在有几个度量平台实现这些度量的收集[SURVEYOR][SURVEYOR-INET][RIME][BRIX]，但目前还没有一个标准允许启动测试流或交换数据包以互操作的方式收集单例度量。
With the increasingly wide availability of affordable global positioning systems (GPS) and CDMA-based time sources, hosts increasingly have available to them very accurate time sources, either directly or through their proximity to Network Time Protocol (NTP) primary (stratum 1) time servers. By standardizing a technique for collecting IPPM one-way active measurements, we hope to create an environment where IPPM metrics may be collected across a far broader mesh of Internet paths than is currently possible. One particularly compelling vision is of widespread deployment of open OWAMP servers
随着价格合理的全球定位系统（GPS）和基于CDMA的时间源的可用性日益广泛，主机越来越多地可以直接或通过接近网络时间协议（NTP）主（第1层）时间服务器获得非常精确的时间源。通过标准化收集IPPM单向活动度量的技术，我们希望创建一个环境，在这个环境中，IPPM度量可以通过比当前更广泛的互联网路径网格进行收集。一个特别引人注目的愿景是广泛部署开放式OWAMP服务器
that would make measurement of one-way delay as commonplace as measurement of round-trip time using an ICMP-based tool like ping.
这将使单向延迟的测量与使用基于ICMP的工具（如ping）测量往返时间一样常见。
Additional design goals of OWAMP include: being hard to detect and manipulate, security, logical separation of control and test functionality, and support for small test packets. (Being hard to detect makes interference with measurements more difficult for intermediaries in the middle of the network.)
OWAMP的其他设计目标包括：难以检测和操作、安全性、控制和测试功能的逻辑分离，以及对小测试包的支持。（很难检测到中间的中间人对测量的干扰更困难。）
OWAMP test traffic is hard to detect because it is simply a stream of UDP packets from and to negotiated port numbers, with potentially nothing static in the packets (size is negotiated, as well). OWAMP also supports an encrypted mode that further obscures the traffic and makes it impossible to alter timestamps undetectably.
OWAMP测试流量很难检测，因为它只是来自协商端口号和到协商端口号的UDP数据包流，数据包中可能没有任何静态内容（大小也是协商的）。OWAMP还支持一种加密模式，该模式进一步模糊了通信量，使得无法检测到时间戳的改变。
Security features include optional authentication and/or encryption of control and test messages. These features may be useful to prevent unauthorized access to results or man-in-the-middle attacks that attempt to provide special treatment to OWAMP test streams or that attempt to modify sender-generated timestamps to falsify test results.
安全功能包括控制和测试消息的可选身份验证和/或加密。这些功能可用于防止未经授权访问结果或中间人攻击，这些攻击试图对OWAMP测试流进行特殊处理，或试图修改发送方生成的时间戳以伪造测试结果。
In this document, the key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" are to be interpreted as described in [RFC2119].
在本文件中，关键词“必须”、“要求”、“应该”、“建议”和“可能”应按照[RFC2119]中所述进行解释。
OWAMP actually consists of two inter-related protocols: OWAMP-Control and OWAMP-Test. OWAMP-Control is used to initiate, start, and stop test sessions and to fetch their results, whereas OWAMP-Test is used to exchange test packets between two measurement nodes.
OWAMP实际上由两个相互关联的协议组成：OWAMP控制和OWAMP测试。OWAMP控制用于启动、启动和停止测试会话并获取其结果，而OWAMP测试用于在两个测量节点之间交换测试数据包。
Although OWAMP-Test may be used in conjunction with a control protocol other than OWAMP-Control, the authors have deliberately chosen to include both protocols in the same RFC to encourage the implementation and deployment of OWAMP-Control as a common denominator control protocol for one-way active measurements. Having a complete and open one-way active measurement solution that is simple to implement and deploy is crucial to ensuring a future in which inter-domain one-way active measurement could become as commonplace as ping. We neither anticipate nor recommend that OWAMP-Control form the foundation of a general-purpose extensible measurement and monitoring control protocol.
尽管OWAMP测试可与OWAMP控制以外的控制协议结合使用，但作者有意选择将这两个协议包括在同一RFC中，以鼓励将OWAMP控制作为单向主动测量的公共分母控制协议来实施和部署。拥有一个易于实施和部署的完整、开放的单向主动测量解决方案，对于确保未来跨域单向主动测量能够像ping一样普及至关重要。我们既不预期也不建议OWAMP控制形成通用可扩展的测量和监控控制协议的基础。
OWAMP-Control is designed to support the negotiation of one-way active measurement sessions and results retrieval in a straightforward manner. At session initiation, there is a
OWAMP控制旨在以直接的方式支持单向主动测量会话的协商和结果检索。在会话启动时，有一个
negotiation of sender and receiver addresses and port numbers, session start time, session length, test packet size, the mean Poisson sampling interval for the test stream, and some attributes of the very general [RFC 2330] notion of packet type, including packet size and per-hop behavior (PHB) [RFC2474], which could be used to support the measurement of one-way network characteristics across differentiated services networks. Additionally, OWAMP-Control supports per-session encryption and authentication for both test and control traffic, measurement servers that can act as proxies for test stream endpoints, and the exchange of a seed value for the pseudo-random Poisson process that describes the test stream generated by the sender.
协商发送方和接收方地址和端口号、会话开始时间、会话长度、测试数据包大小、测试流的平均泊松采样间隔，以及数据包类型的非常普遍的[RFC 2330]概念的一些属性，包括数据包大小和每跳行为（PHB）[RFC2474]，可用于支持跨差异化服务网络的单向网络特性测量。此外，OWAMP Control支持测试和控制流量的每会话加密和身份验证，可以充当测试流端点代理的测量服务器，以及描述发送方生成的测试流的伪随机泊松过程种子值的交换。
We believe that OWAMP-Control can effectively support one-way active measurement in a variety of environments, from publicly accessible measurement beacons running on arbitrary hosts to network monitoring deployments within private corporate networks. If integration with Simple Network Management Protocol (SNMP) or proprietary network management protocols is required, gateways may be created.
我们相信，OWAMP Control可以有效地支持各种环境中的单向主动测量，从运行在任意主机上的公共可访问测量信标到私有公司网络中的网络监控部署。如果需要与简单网络管理协议（SNMP）或专有网络管理协议集成，则可以创建网关。
Several roles are logically separated to allow for broad flexibility in use. Specifically, we define the following:
多个角色在逻辑上是分开的，以便在使用中具有广泛的灵活性。具体而言，我们定义如下：
Session-Sender The sending endpoint of an OWAMP-Test session;
会话发送方OWAMP测试会话的发送端点；
Session-Receiver The receiving endpoint of an OWAMP-Test session;
会话接收器OWAMP测试会话的接收端点；
Server An end system that manages one or more OWAMP-Test sessions, is capable of configuring per-session state in session endpoints, and is capable of returning the results of a test session;
服务器管理一个或多个OWAMP测试会话的终端系统，能够在会话端点中配置每个会话状态，并且能够返回测试会话的结果；
Control-Client An end system that initiates requests for OWAMP-Test sessions, triggers the start of a set of sessions, and may trigger their termination; and
控制客户端：一种终端系统，用于启动OWAMP测试会话的请求，触发一组会话的启动，并可能触发会话的终止；和
Fetch-Client An end system that initiates requests to fetch the results of completed OWAMP-Test sessions.
Fetch Client一个终端系统，它启动请求以获取已完成的OWAMP测试会话的结果。
One possible scenario of relationships between these roles is shown below.
这些角色之间关系的一个可能场景如下所示。
+----------------+ +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+ +------------------+
^ ^
| |
| |
| |
| +----------------+<----------------+
| | Server |<-------+
| +----------------+ |
| ^ |
| | |
| OWAMP-Control OWAMP-Control
| | |
v v v
+----------------+ +-----------------+
| Control-Client | | Fetch-Client |
+----------------+ +-----------------+
+----------------+ +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+ +------------------+
^ ^
| |
| |
| |
| +----------------+<----------------+
| | Server |<-------+
| +----------------+ |
| ^ |
| | |
| OWAMP-Control OWAMP-Control
| | |
v v v
+----------------+ +-----------------+
| Control-Client | | Fetch-Client |
+----------------+ +-----------------+
(Unlabeled links in the figure are unspecified by this document and may be proprietary protocols.)
（图中未标记的链接未在本文件中指定，可能是专有协议。）
Different logical roles can be played by the same host. For example, in the figure above, there could actually be only two hosts: one playing the roles of Control-Client, Fetch-Client, and Session-Sender, and the other playing the roles of Server and Session-Receiver. This is shown below.
同一主机可以扮演不同的逻辑角色。例如，在上图中，实际上可能只有两台主机：一台扮演控制客户端、获取客户端和会话发送方的角色，另一台扮演服务器和会话接收方的角色。如下所示。
+-----------------+ +------------------+
| Control-Client |<--OWAMP-Control-->| Server |
| Fetch-Client | | |
| Session-Sender |---OWAMP-Test----->| Session-Receiver |
+-----------------+ +------------------+
+-----------------+ +------------------+
| Control-Client |<--OWAMP-Control-->| Server |
| Fetch-Client | | |
| Session-Sender |---OWAMP-Test----->| Session-Receiver |
+-----------------+ +------------------+
Finally, because many Internet paths include segments that transport IP over ATM, delay and loss measurements can include the effects of ATM segmentation and reassembly (SAR). Consequently, OWAMP has been designed to allow for small test packets that would fit inside the payload of a single ATM cell (this is only achieved in unauthenticated mode).
最后，由于许多Internet路径包括通过ATM传输IP的段，因此延迟和损耗测量可以包括ATM分段和重组（SAR）的影响。因此，OWAMP被设计为允许在单个ATM信元的有效负载内容纳小型测试数据包（这仅在未经验证的模式下实现）。
As described above, OWAMP consists of two inter-related protocols: OWAMP-Control and OWAMP-Test. The former is layered over TCP and is used to initiate and control measurement sessions and to fetch their results. The latter protocol is layered over UDP and is used to send singleton measurement packets along the Internet path under test.
如上所述，OWAMP由两个相互关联的协议组成：OWAMP控制和OWAMP测试。前者在TCP上分层，用于启动和控制测量会话，并获取其结果。后一种协议是在UDP上分层的，用于沿被测Internet路径发送单例测量数据包。
The initiator of the measurement session establishes a TCP connection to a well-known port, 861, on the target point and this connection remains open for the duration of the OWAMP-Test sessions. An OWAMP server SHOULD listen to this well-known port.
测量会话的发起方在目标点上建立到已知端口861的TCP连接，并且该连接在OWAMP测试会话期间保持打开状态。OWAMP服务器应该侦听这个众所周知的端口。
OWAMP-Control messages are transmitted only before OWAMP-Test sessions are actually started and after they are completed (with the possible exception of an early Stop-Sessions message).
OWAMP控制消息仅在OWAMP测试会话实际启动之前和完成之后传输（早期停止会话消息可能除外）。
The OWAMP-Control and OWAMP-Test protocols support three modes of operation: unauthenticated, authenticated, and encrypted. The authenticated or encrypted modes require that endpoints possess a shared secret.
OWAMP控制和OWAMP测试协议支持三种操作模式：未经验证、已验证和加密。认证或加密模式要求端点拥有共享秘密。
All multi-octet quantities defined in this document are represented as unsigned integers in network byte order unless specified otherwise.
除非另有规定，否则本文件中定义的所有多个八位字节数量均以网络字节顺序表示为无符号整数。
The type of each OWAMP-Control message can be found after reading the first 16 octets. The length of each OWAMP-Control message can be computed upon reading its fixed-size part. No message is shorter than 16 octets.
读取前16个八位字节后，可以找到每个OWAMP控制消息的类型。每个OWAMP控制消息的长度可在读取其固定大小部分时计算。没有短于16个八位字节的消息。
An implementation SHOULD expunge unused state to prevent denial-of-service attacks, or unbounded memory usage, on the server. For example, if the full control message is not received within some number of minutes after it is expected, the TCP connection associated with the OWAMP-Control session SHOULD be dropped. In absence of other considerations, 30 minutes seems like a reasonable upper bound.
实现应删除未使用状态，以防止服务器上的拒绝服务攻击或无限内存使用。例如，如果在预期的几分钟内未收到完全控制消息，则应断开与OWAMP控制会话关联的TCP连接。在没有其他考虑的情况下，30分钟似乎是一个合理的上限。
Before either a Control-Client or a Fetch-Client can issue commands to a Server, it has to establish a connection to the server.
在控制客户端或获取客户端向服务器发出命令之前，它必须建立与服务器的连接。
First, a client opens a TCP connection to the server on a well-known port 861. The server responds with a server greeting:
首先，客户机在一个众所周知的端口861上打开到服务器的TCP连接。服务器以服务器问候语回应：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Unused (12 octets) |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Salt (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Unused (12 octets) |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Salt (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following Mode values are meaningful: 1 for unauthenticated, 2 for authenticated, and 4 for encrypted. The value of the Modes field sent by the server is the bit-wise OR of the mode values that it is willing to support during this session. Thus, the last three bits of the Modes 32-bit value are used. The first 29 bits MUST be zero. A client MUST ignore the values in the first 29 bits of the Modes value. (This way, the bits are available for future protocol extensions. This is the only intended extension mechanism.)
以下模式值有意义：1表示未经验证，2表示已验证，4表示已加密。服务器发送的Modes字段的值是按位的，或者是它在此会话期间愿意支持的模式值。因此，使用模式32位值的最后三位。前29位必须为零。客户端必须忽略模式值前29位中的值。（这样，位可用于未来的协议扩展。这是唯一预期的扩展机制。）
Challenge is a random sequence of octets generated by the server; it is used subsequently by the client to prove possession of a shared secret in a manner prescribed below.
挑战是服务器生成的八位字节的随机序列；客户随后使用该信息以下述方式证明其拥有共享秘密。
Salt and Count are parameters used in deriving a key from a shared secret as described below.
Salt和Count是用于从共享密钥派生密钥的参数，如下所述。
Salt MUST be generated pseudo-randomly (independently of anything else in this document).
Salt必须伪随机生成（与本文档中的任何其他内容无关）。
Count MUST be a power of 2. Count MUST be at least 1024. Count SHOULD be increased as more computing power becomes common.
计数必须是2的幂。计数必须至少为1024。随着更多的计算能力变得普遍，计数应该增加。
If the Modes value is zero, the server does not wish to communicate with the client and MAY close the connection immediately. The client SHOULD close the connection if it receives a greeting with Modes equal to zero. The client MAY close the connection if the client's desired mode is unavailable.
如果Modes值为零，则服务器不希望与客户端通信，可能会立即关闭连接。如果客户端收到模式为零的问候语，则应关闭连接。如果客户端所需的模式不可用，客户端可能会关闭连接。
Otherwise, the client MUST respond with the following Set-Up-Response message:
否则，客户端必须响应以下设置响应消息：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. KeyID (80 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Token (64 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Client-IV (16 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. KeyID (80 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Token (64 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Client-IV (16 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here Mode is the mode that the client chooses to use during this OWAMP-Control session. It will also be used for all OWAMP-Test sessions started under control of this OWAMP-Control session. In Mode, one or zero bits MUST be set within last three bits. If it is one bit that is set within the last three bits, this bit MUST indicate a mode that the server agreed to use (i.e., the same bit MUST have been set by the server in the server greeting). The first 29 bits of Mode MUST be zero. A server MUST ignore the values of the first 29 bits. If zero Mode bits are set by the client, the client indicates that it will not continue with the session; in this case, the client and the server SHOULD close the TCP connection associated with the OWAMP-Control session.
此处模式是客户端在此OWAMP控制会话期间选择使用的模式。它还将用于在此OWAMP控制会话控制下启动的所有OWAMP测试会话。在模式中，必须在最后三位内设置一位或零位。如果在最后三位内设置了一位，则该位必须指示服务器同意使用的模式（即，服务器在服务器问候语中必须设置相同的位）。模式的前29位必须为零。服务器必须忽略前29位的值。如果客户端设置了零模式位，则客户端指示它将不会继续会话；在这种情况下，客户端和服务器应关闭与OWAMP控制会话相关联的TCP连接。
In unauthenticated mode, KeyID, Token, and Client-IV are unused. Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the string is shorter, it is padded with zero octets), that tells the server which shared secret the client wishes to use to authenticate or encrypt, while Token is the concatenation of a 16-octet challenge, a 16-octet AES Session-key used for encryption, and a 32-octet HMAC-SHA1 Session-key used for authentication. The token itself is encrypted using the AES (Advanced Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be performed using an Initialization Vector (IV) of zero and a key derived from the shared secret associated with KeyID. (Both the server and the client use the same mappings from KeyIDs to shared secrets. The server, being prepared to conduct sessions with more than one client, uses KeyIDs to choose the appropriate secret key; a client would typically have different secret keys for different servers. The situation is analogous to that with passwords.)
在未经身份验证的模式下，KeyID、令牌和客户端IV未使用。否则，KeyID是一个UTF-8字符串，长度最多为80个八位字节（如果字符串较短，则用零个八位字节填充），它告诉服务器客户端希望使用哪个共享密钥进行身份验证或加密，而Token是16个八位字节的质询的串联，16个八位字节的AES会话密钥用于加密，以及用于身份验证的32个八位组HMAC-SHA1会话密钥。令牌本身使用密码块链（CBC）中的AES（高级加密标准）[AES]进行加密。必须使用零的初始化向量（IV）和从与KeyID关联的共享密钥派生的密钥来执行加密。（服务器和客户端都使用从KeyID到共享机密的相同映射。准备与多个客户端进行会话的服务器使用KeyID选择适当的密钥；客户端通常会为不同的服务器使用不同的密钥。这种情况类似于密码。）
The shared secret is a passphrase; it MUST not contain newlines. The secret key is derived from the passphrase using a password-based key derivation function PBKDF2 (PKCS #5) [RFC2898]. The PBKDF2 function requires several parameters: the PRF is HMAC-SHA1 [RFC2104]; the salt and count are as transmitted by the server.
共享秘密是一个密码短语；它不能包含换行符。使用基于密码的密钥派生函数PBKDF2（PKCS#5）[RFC2898]从密码短语派生出密钥。PBKDF2函数需要几个参数：PRF为HMAC-SHA1[RFC2104]；盐和计数由服务器传输。
AES Session-key, HMAC Session-key and Client-IV are generated randomly by the client. AES Session-key and HMAC Session-key MUST be generated with sufficient entropy not to reduce the security of the underlying cipher [RFC4086]. Client-IV merely needs to be unique (i.e., it MUST never be repeated for different sessions using the same secret key; a simple way to achieve that without the use of cumbersome state is to generate the Client-IV values using a cryptographically secure pseudo-random number source: if this is done, the first repetition is unlikely to occur before 2^64 sessions with the same secret key are conducted).
AES会话密钥、HMAC会话密钥和客户端IV由客户端随机生成。AES会话密钥和HMAC会话密钥必须以足够的熵生成，以不降低基础密码的安全性[RFC4086]。客户机IV只需要是唯一的（即，对于使用同一密钥的不同会话，不得重复该操作；在不使用繁琐状态的情况下，实现该操作的简单方法是使用加密安全的伪随机数源生成客户端IV值：如果这样做，则第一次重复不太可能在使用相同密钥的2^64个会话之前发生。）y）进行。
The server MUST respond with the following Server-Start message:
服务器必须响应以下服务器启动消息：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (15 octets) |
| |
| +-+-+-+-+-+-+-+-+
| | Accept |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Server-IV (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time (Timestamp) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (15 octets) |
| |
| +-+-+-+-+-+-+-+-+
| | Accept |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Server-IV (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time (Timestamp) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MBZ parts MUST be zero. The client MUST ignore their value. MBZ (MUST be zero) fields here and after have the same semantics: the party that sends the message MUST set the field so that all bits are equal to zero; the party that interprets the message MUST ignore the value. (This way, the field could be used for future extensions.)
MBZ部件必须为零。客户必须忽略其价值。此处和之后的MBZ（必须为零）字段具有相同的语义：发送消息的一方必须设置该字段，以便所有位都等于零；解释消息的一方必须忽略该值。（这样，该字段可用于将来的扩展。）
Server-IV is generated randomly by the server. In unauthenticated mode, Server-IV is unused.
服务器IV由服务器随机生成。在未经验证的模式下，服务器IV未使用。
The Accept field indicates the server's willingness to continue communication. A zero value in the Accept field means that the server accepts the authentication and is willing to conduct further transactions. Non-zero values indicate that the server does not accept the authentication or, for some other reason, is not willing to conduct further transactions in this OWAMP-Control session. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field".
Accept字段表示服务器愿意继续通信。Accept字段中的零值表示服务器接受身份验证并愿意执行进一步的事务。非零值表示服务器不接受身份验证，或者出于其他原因，不愿意在此OWAMP控制会话中执行进一步的事务。第3.3节“接受字段的值”中描述了可用接受值的完整列表。
If a negative (non-zero) response is sent, the server MAY (and the client SHOULD) close the connection after this message.
如果发送了否定（非零）响应，则服务器可能（并且客户端应该）在此消息之后关闭连接。
Start-Time is a timestamp representing the time when the current instantiation of the server started operating. (For example, in a multi-user general purpose operating system, it could be the time when the server process was started.) If Accept is non-zero, Start-
Start Time是一个时间戳，表示服务器的当前实例化开始运行的时间。（例如，在多用户通用操作系统中，它可能是服务器进程启动的时间。）如果Accept为非零，则启动-
Time SHOULD be set so that all of its bits are zeros. In authenticated and encrypted modes, Start-Time is encrypted as described in Section 3.4, "OWAMP-Control Commands", unless Accept is non-zero. (Authenticated and encrypted mode cannot be entered unless the control connection can be initialized.)
时间应设置为其所有位均为零。在认证和加密模式下，除非Accept为非零，否则启动时间将按照第3.4节“OWAMP控制命令”中所述进行加密。（除非可以初始化控制连接，否则无法进入身份验证和加密模式。）
Timestamp format is described in Section 4.1.2. The same instantiation of the server SHOULD report the same exact Start-Time value to each client in each session.
时间戳格式见第4.1.2节。服务器的相同实例化应该在每个会话中向每个客户机报告相同的确切启动时间值。
The previous transactions constitute connection setup.
以前的事务构成连接设置。
Authentication of each message (also referred to as a command in this document) in OWAMP-Control is accomplished by adding an HMAC to it. The HMAC that OWAMP uses is HMAC-SHA1 truncated to 128 bits. Thus, all HMAC fields are 16 octets. An HMAC needs a key. The HMAC Session-key is communicated along with the AES Session-key during OWAMP-Control connection setup. The HMAC Session-key SHOULD be derived independently of the AES Session-key (an implementation, of course, MAY use the same mechanism to generate the random bits for both keys). Each HMAC sent covers everything sent in a given direction between the previous HMAC (but not including it) and up to the beginning of the new HMAC. This way, once encryption is set up, each bit of the OWAMP-Control connection is authenticated by an HMAC exactly once.
OWAMP控件中每个消息（在本文档中也称为命令）的身份验证都是通过向其添加HMAC来完成的。OWAMP使用的HMAC是被截断为128位的HMAC-SHA1。因此，所有HMAC字段都是16个八位字节。HMAC需要一把钥匙。在OWAMP控制连接设置期间，HMAC会话密钥与AES会话密钥进行通信。HMAC会话密钥应独立于AES会话密钥导出（当然，一个实现可以使用相同的机制为两个密钥生成随机位）。发送的每个HMAC涵盖了从上一个HMAC（但不包括它）到新HMAC开始之前按给定方向发送的所有内容。这样，一旦设置了加密，OWAMP控制连接的每一位都会被HMAC准确地验证一次。
When encrypting, authentication happens before encryption, so HMAC blocks are encrypted along with the rest of the stream. When decrypting, the order, of course, is reversed: first one decrypts, then one checks the HMAC, then one proceeds to use the data.
加密时，身份验证发生在加密之前，因此HMAC块与流的其余部分一起加密。解密时，顺序当然是相反的：首先解密，然后检查HMAC，然后继续使用数据。
The HMAC MUST be checked as early as possible to avoid using and propagating corrupt data.
必须尽早检查HMAC，以避免使用和传播损坏的数据。
In open mode, the HMAC fields are unused and have the same semantics as MBZ fields.
在开放模式下，HMAC字段未使用，并且与MBZ字段具有相同的语义。
Accept values are used throughout the OWAMP-Control protocol to communicate the server response to client requests. The full set of valid Accept field values are as follows:
整个OWAMP控制协议都使用Accept值来传递服务器对客户端请求的响应。全套有效的Accept字段值如下所示：
0 OK.
0好的。
1 Failure, reason unspecified (catch-all).
1失败，原因不明（包罗万象）。
2 Internal error.
2内部错误。
3 Some aspect of request is not supported.
3请求的某些方面不受支持。
4 Cannot perform request due to permanent resource limitations.
4由于永久资源限制，无法执行请求。
5 Cannot perform request due to temporary resource limitations.
由于临时资源限制，5无法执行请求。
All other values are reserved. The sender of the message MAY use the value of 1 for all non-zero Accept values. A message sender SHOULD use the correct Accept value if it is going to use other values. The message receiver MUST interpret all values of Accept other than these reserved values as 1. This way, other values are available for future extensions.
所有其他值均保留。消息的发送方可以对所有非零接受值使用值1。如果要使用其他值，则消息发送者应使用正确的Accept值。消息接收方必须将除这些保留值以外的所有Accept值解释为1。这样，其他值可用于将来的扩展。
In authenticated or encrypted mode (which are identical as far as OWAMP-Control is concerned, and only differ in OWAMP-Test), all further communications are encrypted with the AES Session-key (using CBC mode) and authenticated with HMAC Session-key. The client encrypts everything it sends through the just-established OWAMP-Control connection using stream encryption with Client-IV as the IV. Correspondingly, the server encrypts its side of the connection using Server-IV as the IV.
在认证或加密模式下（就OWAMP控制而言相同，仅在OWAMP测试中不同），所有进一步的通信都使用AES会话密钥（使用CBC模式）进行加密，并使用HMAC会话密钥进行认证。客户端通过刚刚建立的OWAMP控制连接使用流加密（客户端IV作为IV）对其发送的所有内容进行加密。相应地，服务器使用服务器IV作为IV对其连接端进行加密。
The IVs themselves are transmitted in cleartext. Encryption starts with the block immediately following the block containing the IV. The two streams (one going from the client to the server and one going back) are encrypted independently, each with its own IV, but using the same key (the AES Session-key).
IVs本身以明文传输。加密从紧跟在包含IV的块之后的块开始。两个流（一个从客户端到服务器，一个返回）分别进行加密，每个流都有自己的IV，但使用相同的密钥（AES会话密钥）。
The following commands are available for the client: Request-Session, Start-Sessions, Stop-Sessions, and Fetch-Session. The command Stop-Sessions is available to both the client and the server. (The server can also send other messages in response to commands it receives.)
以下命令可用于客户端：请求会话、启动会话、停止会话和获取会话。命令停止会话对客户端和服务器都可用。（服务器还可以发送其他消息以响应其接收到的命令。）
After the client sends the Start-Sessions command and until it both sends and receives (in an unspecified order) the Stop-Sessions command, it is said to be conducting active measurements. Similarly, the server is said to be conducting active measurements after it receives the Start-Sessions command and until it both sends and receives (in an unspecified order) the Stop-Sessions command.
在客户端发送Start Sessions命令之后，直到它发送和接收（以未指定的顺序）Stop Sessions命令，它被称为正在进行活动测量。类似地，服务器在接收到Start Sessions命令后，直到发送和接收（以未指定的顺序）Stop Sessions命令为止，都在进行活动测量。
While conducting active measurements, the only command available is Stop-Sessions.
在进行活动测量时，唯一可用的命令是停止会话。
These commands are described in detail below.
下面将详细描述这些命令。
Individual one-way active measurement sessions are established using a simple request/response protocol. An OWAMP client MAY issue zero or more Request-Session messages to an OWAMP server, which MUST respond to each with an Accept-Session message. An Accept-Session message MAY refuse a request.
使用简单的请求/响应协议建立单独的单向主动测量会话。OWAMP客户端可能会向OWAMP服务器发出零条或多条请求会话消息，而OWAMP服务器必须使用Accept会话消息响应每条请求会话消息。接受会话消息可以拒绝请求。
The format of Request-Session message is as follows:
请求会话报文格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Address (cont.) or MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receiver Address (cont.) or MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout, (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Address (cont.) or MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receiver Address (cont.) or MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout, (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by one or more schedule slot descriptions (the number of schedule slots is specified in the "Number of Schedule Slots" field above):
紧接着是一个或多个计划槽描述（计划槽数量在上面的“计划槽数量”字段中指定）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Type | |
+-+-+-+-+-+-+-+-+ MBZ (7 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Parameter (Timestamp) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Type | |
+-+-+-+-+-+-+-+-+ MBZ (7 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Parameter (Timestamp) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are immediately followed by HMAC:
紧随其后的是HMAC：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these messages constitute one logical message: the Request-Session command.
所有这些消息构成一个逻辑消息：请求会话命令。
Above, the first octet (1) indicates that this is the Request-Session command.
上面的第一个八位组（1）表示这是请求会话命令。
IPVN is the IP version numbers for Sender and Receiver. When the IP version number is 4, 12 octets follow the 4-octet IPv4 address stored in Sender Address and Receiver Address. These octets MUST be set to zero by the client and MUST be ignored by the server. Currently meaningful IPVN values are 4 and 6.
IPVN是发送方和接收方的IP版本号。当IP版本号为4时，在发送方地址和接收方地址中存储的4-octet IPv4地址之后会有12个八位字节。客户端必须将这些八位字节设置为零，服务器必须忽略这些八位字节。当前有意义的IPVN值为4和6。
Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the client. The server MUST interpret any non-zero value as 1. If the value is 1, the server is being asked to configure the corresponding agent (sender or receiver). In this case, the corresponding Port value SHOULD be disregarded by the server. At least one of Conf-Sender and Conf-Receiver MUST be 1. (Both can be set, in which case the server is being asked to perform a session between two hosts it can configure.)
客户端必须将Conf Sender和Conf Receiver设置为0或1。服务器必须将任何非零值解释为1。如果该值为1，则要求服务器配置相应的代理（发送方或接收方）。在这种情况下，服务器应忽略相应的端口值。Conf发送方和Conf接收方中必须至少有一个为1。（两者都可以设置，在这种情况下，服务器被要求在它可以配置的两台主机之间执行会话。）
Number of Schedule Slots, as mentioned before, specifies the number of slot records that go between the two blocks of HMAC. It is used by the sender to determine when to send test packets (see next section).
如前所述，Schedule slot的数量指定了HMAC两个块之间的插槽记录的数量。发送方使用它来确定何时发送测试数据包（参见下一节）。
Number of Packets is the number of active measurement packets to be sent during this OWAMP-Test session (note that either the server or the client can abort the session early).
Number of Packets是此OWAMP测试会话期间要发送的活动测量数据包的数量（请注意，服务器或客户端可以提前中止会话）。
If Conf-Sender is not set, Sender Port is the UDP port from which OWAMP-Test packets will be sent. If Conf-Receiver is not set, Receiver Port is the UDP port OWAMP-Test to which packets are requested to be sent.
如果未设置Conf Sender，则Sender Port是将从中发送OWAMP测试数据包的UDP端口。如果未设置Conf Receiver，Receiver Port是请求向其发送数据包的UDP端口OWAMP测试。
The Sender Address and Receiver Address fields contain, respectively, the sender and receiver addresses of the end points of the Internet path over which an OWAMP test session is requested.
发送方地址和接收方地址字段分别包含请求OWAMP测试会话的Internet路径端点的发送方地址和接收方地址。
SID is the session identifier. It can be used in later sessions as an argument for the Fetch-Session command. It is meaningful only if Conf-Receiver is 0. This way, the SID is always generated by the receiving side. See the end of the section for information on how the SID is generated.
SID是会话标识符。它可以在以后的会话中用作Fetch会话命令的参数。仅当Conf Receiver为0时才有意义。这样，SID总是由接收方生成。有关如何生成SID的信息，请参见本节末尾。
Padding length is the number of octets to be appended to the normal OWAMP-Test packet (see more on padding in discussion of OWAMP-Test).
Padding length是附加到普通OWAMP测试数据包的八位字节数（请参阅OWAMP测试讨论中有关填充的更多信息）。
Start Time is the time when the session is to be started (but not before Start-Sessions command is issued). This timestamp is in the same format as OWAMP-Test timestamps.
开始时间是会话开始的时间（但不是在发出启动会话命令之前）。此时间戳与OWAMP测试时间戳的格式相同。
Timeout (or a loss threshold) is an interval of time (expressed as a timestamp). A packet belonging to the test session that is being set up by the current Request-Session command will be considered lost if it is not received during Timeout seconds after it is sent.
超时（或丢失阈值）是一个时间间隔（表示为时间戳）。如果在发送后的超时秒内未收到属于当前请求会话命令设置的测试会话的数据包，则该数据包将被视为丢失。
Type-P Descriptor covers only a subset of (very large) Type-P space. If the first two bits of the Type-P Descriptor are 00, then the subsequent six bits specify the requested Differentiated Services Codepoint (DSCP) value of sent OWAMP-Test packets, as defined in [RFC2474]. If the first two bits of Type-P descriptor are 01, then the subsequent 16 bits specify the requested PHB Identification Code (PHB ID), as defined in [RFC2836].
Type-P描述符只覆盖（非常大的）Type-P空间的一个子集。如果P型描述符的前两位为00，则随后的六位指定所发送OWAMP测试数据包的请求区分服务码点（DSCP）值，如[RFC2474]中所定义。如果P型描述符的前两位为01，则随后的16位指定所请求的PHB标识码（PHB ID），如[RFC2836]中所定义。
Therefore, the value of all zeros specifies the default best-effort service.
因此，全零的值指定默认的尽力而为服务。
If Conf-Sender is set, the Type-P Descriptor is to be used to configure the sender to send packets according to its value. If Conf-Sender is not set, the Type-P Descriptor is a declaration of how the sender will be configured.
如果设置了Conf Sender，则将使用Type-P描述符配置发送方，以根据其值发送数据包。如果未设置Conf Sender，则Type-P描述符是如何配置发送器的声明。
If Conf-Sender is set and the server does not recognize the Type-P Descriptor, or it cannot or does not wish to set the corresponding attributes on OWAMP-Test packets, it SHOULD reject the session request. If Conf-Sender is not set, the server SHOULD accept or reject the session, paying no attention to the value of the Type-P Descriptor.
如果设置了Conf Sender，并且服务器无法识别Type-P描述符，或者无法或不希望在OWAMP测试数据包上设置相应的属性，那么它应该拒绝会话请求。如果未设置Conf Sender，服务器应接受或拒绝会话，而不注意Type-P描述符的值。
To each Request-Session message, an OWAMP server MUST respond with an Accept-Session message:
对于每个请求会话消息，OWAMP服务器必须以接受会话消息进行响应：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | MBZ | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | MBZ | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this message, zero in the Accept field means that the server is willing to conduct the session. A non-zero value indicates rejection of the request. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field".
在此消息中，Accept字段中的零表示服务器愿意执行会话。非零值表示拒绝请求。第3.3节“接受字段的值”中描述了可用接受值的完整列表。
If the server rejects a Request-Session message, it SHOULD not close the TCP connection. The client MAY close it if it receives a negative response to the Request-Session message.
如果服务器拒绝请求会话消息，则不应关闭TCP连接。如果客户端接收到对请求会话消息的否定响应，则可以将其关闭。
The meaning of Port in the response depends on the values of Conf-Sender and Conf-Receiver in the query that solicited the response. If both were set, the Port field is unused. If only Conf-Sender was set, Port is the port from which to expect OWAMP-Test packets. If
响应中端口的含义取决于请求响应的查询中Conf Sender和Conf Receiver的值。如果两者都已设置，则端口字段未使用。如果只设置了Conf Sender，则Port是期望OWAMP测试数据包的端口。如果
only Conf-Receiver was set, Port is the port to which OWAMP-Test packets are sent.
仅设置了Conf Receiver，端口是向其发送OWAMP测试数据包的端口。
If only Conf-Sender was set, the SID field in the response is unused. Otherwise, SID is a unique server-generated session identifier. It can be used later as handle to fetch the results of a session.
如果仅设置了Conf Sender，则响应中的SID字段未使用。否则，SID是唯一的服务器生成的会话标识符。它以后可以用作句柄来获取会话的结果。
SIDs SHOULD be constructed by concatenation of the 4-octet IPv4 IP number belonging to the generating machine, an 8-octet timestamp, and a 4-octet random value. To reduce the probability of collisions, if the generating machine has any IPv4 addresses (with the exception of loopback), one of them SHOULD be used for SID generation, even if all communication is IPv6-based. If it has no IPv4 addresses at all, the last four octets of an IPv6 address MAY be used instead. Note that SID is always chosen by the receiver. If truly random values are not available, it is important that the SID be made unpredictable, as knowledge of the SID might be used for access control.
应该通过将属于生成机器的4个八位字节的IPv4 IP号、8个八位字节的时间戳和4个八位字节的随机值串联起来来构建SID。为了减少冲突的可能性，如果生成计算机有任何IPv4地址（环回除外），则应使用其中一个地址生成SID，即使所有通信都基于IPv6。如果它根本没有IPv4地址，则可以使用IPv6地址的最后四个八位字节。请注意，SID始终由接收方选择。如果真正的随机值不可用，则必须使SID不可预测，因为对SID的了解可能用于访问控制。
The sender and the receiver both need to know the same send schedule. This way, when packets are lost, the receiver knows when they were supposed to be sent. It is desirable to compress common schedules and still to be able to use an arbitrary one for the test sessions. In many cases, the schedule will consist of repeated sequences of packets: this way, the sequence performs some test, and the test is repeated a number of times to gather statistics.
发送方和接收方都需要知道相同的发送计划。这样，当数据包丢失时，接收方知道应该在何时发送数据包。我们希望压缩通用的时间表，并且仍然能够在测试会话中使用任意的时间表。在许多情况下，时间表将由重复的数据包序列组成：这样，序列将执行一些测试，测试将重复多次以收集统计数据。
To implement this, we have a schedule with a given number of slots. Each slot has a type and a parameter. Two types are supported: exponentially distributed pseudo-random quantity (denoted by a code of 0) and a fixed quantity (denoted by a code of 1). The parameter is expressed as a timestamp and specifies a time interval. For a type 0 slot (exponentially distributed pseudo-random quantity), this interval is the mean value (or 1/lambda if the distribution density function is expressed as lambda*exp(-lambda*x) for positive values of x). For a type 1 (fixed quantity) slot, the parameter is the delay itself. The sender starts with the beginning of the schedule and executes the instructions in the slots: for a slot of type 0, wait an exponentially distributed time with a mean of the specified parameter and then send a test packet (and proceed to the next slot); for a slot of type 1, wait the specified time and send a test packet (and proceed to the next slot). The schedule is circular: when there are no more slots, the sender returns to the first slot.
为了实现这一点，我们有一个具有给定插槽数的时间表。每个插槽都有一个类型和一个参数。支持两种类型：指数分布伪随机量（由0代码表示）和固定量（由1代码表示）。该参数表示为时间戳并指定时间间隔。对于类型0时隙（指数分布伪随机量），此间隔是平均值（如果分布密度函数表示为λ*exp（-lambda*x）的正值，则为1/lambda）。对于类型1（固定数量）插槽，参数为延迟本身。发送方从计划的开头开始，并执行插槽中的指令：对于类型为0的插槽，使用指定参数的平均值等待指数分布的时间，然后发送测试数据包（并继续到下一个插槽）；对于类型1的插槽，请等待指定的时间并发送测试数据包（然后继续下一个插槽）。时间表是循环的：当没有更多的插槽时，发送方返回到第一个插槽。
The sender and the receiver need to be able to reproducibly execute the entire schedule (so, if a packet is lost, the receiver can still attach a send timestamp to it). Slots of type 1 are trivial to
发送方和接收方需要能够重复执行整个计划（因此，如果数据包丢失，接收方仍然可以向其附加发送时间戳）。类型1的插槽对您来说是微不足道的
reproducibly execute. To reproducibly execute slots of type 0, we need to be able to generate pseudo-random exponentially distributed quantities in a reproducible manner. The way this is accomplished is discussed later in Section 5, "Computing Exponentially Distributed Pseudo-Random Numbers".
重复执行。要重复执行0类型的插槽，我们需要能够以可重复的方式生成伪随机指数分布量。第5节“计算指数分布的伪随机数”将在后面讨论实现这一点的方法。
Using this mechanism, one can easily specify common testing scenarios. The following are some examples:
使用这种机制，可以很容易地指定常见的测试场景。以下是一些例子：
+ Poisson stream: a single slot of type 0.
+ 泊松流：类型为0的单个插槽。
+ Periodic stream: a single slot of type 1.
+ 周期流：类型1的单个插槽。
+ Poisson stream of back-to-back packet pairs: two slots, type 0 with a non-zero parameter and type 1 with a zero parameter.
+ 背对背数据包对的泊松流：两个时隙，类型0带有非零参数，类型1带有零参数。
Further, a completely arbitrary schedule can be specified (albeit inefficiently) by making the number of test packets equal to the number of schedule slots. In this case, the complete schedule is transmitted in advance of an OWAMP-Test session.
此外，通过使测试包的数量等于调度时隙的数量，可以指定完全任意的调度（尽管效率低下）。在这种情况下，在OWAMP测试会话之前传输完整的时间表。
Having requested one or more test sessions and received affirmative Accept-Session responses, an OWAMP client MAY start the execution of the requested test sessions by sending a Start-Sessions message to the server.
在请求了一个或多个测试会话并接收到肯定的接受会话响应之后，OWAMP客户端可以通过向服务器发送开始会话消息来开始执行所请求的测试会话。
The format of this message is as follows:
此消息的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | |
+-+-+-+-+-+-+-+-+ |
| MBZ (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | |
+-+-+-+-+-+-+-+-+ |
| MBZ (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server MUST respond with an Start-Ack message (which SHOULD be sent as quickly as possible). Start-Ack messages have the following format:
服务器必须以Start Ack消息（应尽快发送）进行响应。开始确认消息的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | |
+-+-+-+-+-+-+-+-+ |
| MBZ (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | |
+-+-+-+-+-+-+-+-+ |
| MBZ (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If Accept is non-zero, the Start-Sessions request was rejected; zero means that the command was accepted. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field". The server MAY, and the client SHOULD, close the connection in the case of a rejection.
如果Accept为非零，则开始会话请求被拒绝；零表示该命令已被接受。第3.3节“接受字段的值”中描述了可用接受值的完整列表。在拒绝的情况下，服务器可以并且客户端应该关闭连接。
The server SHOULD start all OWAMP-Test streams immediately after it sends the response or immediately after their specified start times, whichever is later. If the client represents a Sender, the client SHOULD start its OWAMP-Test streams immediately after it sees the Start-Ack response from the Server (if the Start-Sessions command was accepted) or immediately after their specified start times, whichever is later. See more on OWAMP-Test sender behavior in a separate section below.
服务器应在发送响应后立即启动所有OWAMP测试流，或在指定的启动时间后立即启动所有OWAMP测试流，以较晚者为准。如果客户端代表发送方，则客户端应在看到来自服务器的start Ack响应（如果接受start Sessions命令）后立即启动其OWAMP测试流，或在指定的启动时间后立即启动其OWAMP测试流，以较晚者为准。请参阅下面单独一节中有关OWAMP测试发送器行为的更多信息。
The Stop-Sessions message may be issued by either the Control-Client or the Server. The format of this command is as follows:
停止会话消息可以由控制客户端或服务器发出。此命令的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Accept | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Accept | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by zero or more session description records (the number of session description records is specified in
紧接着是零个或多个会话描述记录（会话描述记录的数量在中指定）
the "Number of Sessions" field above). The session description record is used to indicate which packets were actually sent by the sender process (rather than skipped). The header of the session description record is as follows:
上面的“会话数”字段）。会话描述记录用于指示发送方进程实际发送了哪些数据包（而不是跳过了哪些数据包）。会话描述记录的标题如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by zero or more Skip Range descriptions as specified by the "Number of Skip Ranges" field above. Skip Ranges are simply two sequence numbers that, together, indicate a range of packets that were not sent:
紧接着是零个或多个跳过范围描述，如上面的“跳过范围数”字段所指定。跳过范围只是两个序列号，它们一起表示未发送的数据包范围：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Skip Ranges MUST be in order. The last (possibly full, possibly incomplete) block (16 octets) of data MUST be padded with zeros, if necessary. This ensures that the next session description record starts on a block boundary.
跳过范围必须按顺序排列。如有必要，最后一个（可能是完整的，可能是不完整的）数据块（16个八位字节）必须用零填充。这确保下一个会话描述记录从块边界开始。
Finally, a single block (16 octets) of HMAC is concatenated on the end to complete the Stop-Sessions message.
最后，将HMAC的单个块（16个八位字节）连接在端部，以完成Stop Sessions消息。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these records comprise one logical message: the Stop-Sessions command.
所有这些记录都包含一条逻辑消息：Stop Sessions命令。
Above, the first octet (3) indicates that this is the Stop-Sessions command.
上面的第一个八位组（3）表示这是Stop Sessions命令。
Non-zero Accept values indicate a failure of some sort. Zero values indicate normal (but possibly premature) completion. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field".
非零接受值表示某种类型的故障。零值表示正常（但可能过早）完成。第3.3节“接受字段的值”中描述了可用接受值的完整列表。
If Accept had a non-zero value (from either party), results of all OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be considered invalid, even if a Fetch-Session with SID from this session works for a different OWAMP-Control session. If Accept was not transmitted at all (for whatever reason, including the TCP connection used for OWAMP-Control breaking), the results of all OWAMP-Test sessions spawned by this OWAMP-control session MAY be considered invalid.
如果Accept具有非零值（来自任何一方），则此OWAMP控制会话生成的所有OWAMP测试会话的结果都应被视为无效，即使具有来自此会话的SID的提取会话适用于不同的OWAMP控制会话。如果根本没有传输Accept（无论出于何种原因，包括用于OWAMP控制中断的TCP连接），则此OWAMP控制会话生成的所有OWAMP测试会话的结果可能被视为无效。
Number of Sessions indicates the number of session description records that immediately follow the Stop-Sessions header.
Sessions Number of Sessions表示紧跟在Stop Sessions标头之后的会话描述记录数。
Number of Sessions MUST contain the number of send sessions started by the local side of the control connection that have not been previously terminated by a Stop-Sessions command (i.e., the Control-Client MUST account for each accepted Request-Session where Conf-Receiver was set; the Control-Server MUST account for each accepted Request-Session where Conf-Sender was set). If the Stop-Sessions message does not account for exactly the send sessions controlled by that side, then it is to be considered invalid and the connection SHOULD be closed and any results obtained considered invalid.
Sessions Number of Sessions必须包含由控制连接的本地端启动的发送会话的数量，这些会话之前未被Stop Sessions命令终止（即，控制客户端必须说明设置了Conf-Receiver的每个接受请求会话；控制服务器必须说明设置了Conf-Sender的每个接受请求会话）。如果Stop Sessions（停止会话）消息没有准确说明由该方控制的发送会话，则该消息将被视为无效，并且应关闭连接，获得的任何结果都将被视为无效。
Each session description record represents one OWAMP-Test session.
每个会话描述记录代表一个OWAMP测试会话。
SID is the session identifier (SID) used to indicate which send session is being described.
SID是用于指示正在描述哪个发送会话的会话标识符（SID）。
Next Seqno indicates the next sequence number that would have been sent from this send session. For completed sessions, this will equal NumPackets from the Request-Session.
Next Seqno表示将从此发送会话发送的下一个序列号。对于已完成的会话，这将等于来自请求会话的numpacket。
Number of Skip Ranges indicates the number of holes that actually occurred in the sending process. This is a range of packets that were never actually sent by the sending process. For example, if a send session is started too late for the first 10 packets to be sent and this is the only hole in the schedule, then "Number of Skip Ranges" would be 1. The single Skip Range description will have First Seqno Skipped equal to 0 and Last Seqno Skipped equal to 9. This is described further in the "Sender Behavior" section.
跳过范围数表示发送过程中实际发生的孔数。这是发送进程从未实际发送的数据包范围。例如，如果发送会话启动太晚，无法发送前10个数据包，并且这是计划中唯一的漏洞，则“跳过范围数”将为1。单个跳过范围描述的第一个跳过的Seqno等于0，最后一个跳过的Seqno等于9。这将在“发送者行为”一节中进一步描述。
If the OWAMP-Control connection breaks when the Stop-Sessions command is sent, the receiver MAY not completely invalidate the session results. It MUST discard all record of packets that follow (in other words, that have greater sequence number than) the last packet that was actually received before any lost packet records. This will help differentiate between packet losses that occurred in the network and packets the sending process may have never sent.
如果在发送Stop Sessions命令时OWAMP控制连接中断，则接收器可能不会完全使会话结果无效。它必须丢弃在任何丢失的数据包记录之前实际收到的最后一个数据包之后（换句话说，序列号大于）的所有数据包记录。这将有助于区分网络中发生的数据包丢失和发送过程可能从未发送过的数据包。
If a receiver of an OWAMP-Test session learns, through an OWAMP-Control Stop-Sessions message, that the OWAMP-Test sender's last sequence number is lower than any sequence number actually received, the results of the complete OWAMP-Test session MUST be invalidated.
如果OWAMP测试会话的接收方通过OWAMP控制停止会话消息得知OWAMP测试发送方的最后序列号低于实际接收到的任何序列号，则必须使完整OWAMP测试会话的结果无效。
A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control Stop-Sessions command, MUST discard any packet records -- including lost packet records -- with a (computed) send time that falls between the current time minus Timeout and the current time. This ensures statistical consistency for the measurement of loss and duplicates in the event that the Timeout is greater than the time it takes for the Stop-Sessions command to take place.
OWAMP测试会话的接收器在收到OWAMP控制停止会话命令后，必须丢弃任何数据包记录（包括丢失的数据包记录），其（计算的）发送时间介于当前时间减去超时和当前时间之间。这确保了在超时时间大于Stop Sessions命令执行时间的情况下，丢失和重复测量的统计一致性。
To effect complete sessions, each side of the control connection SHOULD wait until all sessions are complete before sending the Stop-Sessions message. The completed time of each session is determined as Timeout after the scheduled time for the last sequence number. Endpoints MAY add a small increment to the computed completed time for send endpoints to ensure that the Stop-Sessions message reaches the receiver endpoint after Timeout.
为了完成会话，控制连接的每一方都应该等到所有会话完成后再发送Stop sessions消息。每个会话的完成时间被确定为最后一个序列号的计划时间之后的超时。端点可以向发送端点的计算完成时间添加一个小增量，以确保Stop Sessions消息在超时后到达接收方端点。
To effect a premature stop of sessions, the party that initiates this command MUST stop its OWAMP-Test send streams to send the Session Packets Sent values before sending this command. That party SHOULD wait until receiving the response Stop-Sessions message before stopping the receiver streams so that it can use the values from the received Stop-Sessions message to validate the data.
要提前停止会话，启动此命令的一方必须在发送此命令之前停止其OWAMP测试发送流，以发送会话数据包发送值。该方应在停止接收器流之前等待，直到接收到响应停止会话消息，以便可以使用接收到的停止会话消息中的值来验证数据。
The format of this client command is as follows:
此客户端命令的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | |
+-+-+-+-+-+-+-+-+ |
| MBZ (7 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | |
+-+-+-+-+-+-+-+-+ |
| MBZ (7 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Begin Seq is the sequence number of the first requested packet. End Seq is the sequence number of the last requested packet. If Begin Seq is all zeros and End Seq is all ones, complete session is said to be requested.
Begin Seq是第一个请求的数据包的序列号。End Seq是最后一个请求的数据包的序列号。若Begin Seq为全零，End Seq为全一，则表示请求完成会话。
If a complete session is requested and the session is still in progress or has terminated in any way other than normally, the request to fetch session results MUST be denied. If an incomplete session is requested, all packets received so far that fall into the requested range SHOULD be returned. Note that, since no commands can be issued between Start-Sessions and Stop-Sessions, incomplete requests can only happen on a different OWAMP-Control connection (from the same or different host as Control-Client).
如果请求了一个完整的会话，并且该会话仍在进行中或以正常情况以外的任何方式终止，则必须拒绝获取会话结果的请求。如果请求的会话不完整，则应返回到目前为止接收到的属于请求范围的所有数据包。请注意，由于启动会话和停止会话之间不能发出任何命令，因此不完整的请求只能发生在不同的OWAMP控制连接上（与控制客户端来自相同或不同的主机）。
The server MUST respond with a Fetch-Ack message. The format of this server response is as follows:
服务器必须响应Fetch Ack消息。此服务器响应的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Finished | MBZ (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Finished | MBZ (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Again, non-zero in the Accept field means a rejection of command. The server MUST specify zero for all remaining fields if Accept is non-zero. The client MUST ignore all remaining fields (except for the HMAC) if Accept is non-zero. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field".
同样，Accept字段中的非零表示拒绝命令。如果Accept为非零，则服务器必须为所有剩余字段指定零。如果Accept为非零，则客户端必须忽略所有剩余字段（HMAC除外）。第3.3节“接受字段的值”中描述了可用接受值的完整列表。
Finished is non-zero if the OWAMP-Test session has terminated.
如果OWAMP测试会话已终止，则Finished为非零。
Next Seqno indicates the next sequence number that would have been sent from this send session. For completed sessions, this will equal NumPackets from the Request-Session. This information is only available if the session has terminated. If Finished is zero, then Next Seqno MUST be set to zero by the server.
Next Seqno表示将从此发送会话发送的下一个序列号。对于已完成的会话，这将等于来自请求会话的numpacket。此信息仅在会话已终止时可用。如果Finished为零，则服务器必须将Next Seqno设置为零。
Number of Skip Ranges indicates the number of holes that actually occurred in the sending process. This information is only available if the session has terminated. If Finished is zero, then Skip Ranges MUST be set to zero by the server.
跳过范围数表示发送过程中实际发生的孔数。此信息仅在会话已终止时可用。如果Finished为零，则服务器必须将跳过范围设置为零。
Number of Records is the number of packet records that fall within the requested range. This number might be less than the Number of Packets in the reproduction of the Request-Session command because of a session that ended prematurely, or it might be greater because of duplicates.
Number of Records是在请求范围内的数据包记录数。由于会话过早结束，此数字可能小于请求会话命令复制中的数据包数，或者由于重复，此数字可能更大。
If Accept was non-zero, this concludes the response to the Fetch-Session message. If Accept was 0, the server then MUST immediately send the OWAMP-Test session data in question.
如果Accept为非零，则表示对获取会话消息的响应结束。如果Accept为0，则服务器必须立即发送有问题的OWAMP测试会话数据。
The OWAMP-Test session data consists of the following (concatenated):
OWAMP测试会话数据包括以下内容（连接）：
+ A reproduction of the Request-Session command that was used to start the session; it is modified so that actual sender and receiver port numbers that were used by the OWAMP-Test session always appear in the reproduction.
+ 用于启动会话的请求会话命令的再现；对其进行修改，以便OWAMP测试会话使用的实际发送方和接收方端口号始终显示在复制中。
+ Zero or more (as specified) Skip Range descriptions. The last (possibly full, possibly incomplete) block (16 octets) of Skip Range descriptions is padded with zeros, if necessary.
+ 零个或多个（按规定）跳过范围说明。如有必要，跳过范围描述的最后一个（可能是完整的，可能是不完整的）块（16个八位字节）用零填充。
+ 16 octets of HMAC.
+ HMAC的16个八位组。
+ Zero or more (as specified) packet records. The last (possibly full, possibly incomplete) block (16 octets) of data is padded with zeros, if necessary.
+ 零个或多个（按规定）数据包记录。如有必要，最后一个（可能是完整的，可能是不完整的）数据块（16个八位字节）用零填充。
+ 16 octets of HMAC.
+ HMAC的16个八位组。
Skip Range descriptions are simply two sequence numbers that, together, indicate a range of packets that were not sent:
跳过范围描述只是两个序列号，它们一起表示未发送的数据包范围：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Skip Range descriptions should be sent out in order, as sorted by First Seqno. If any Skip Ranges overlap or are out of order, the session data is to be considered invalid and the connection SHOULD be closed and any results obtained considered invalid.
跳过范围说明应按顺序发送，按第一个序号排序。如果任何跳过范围重叠或无序，会话数据将被视为无效，连接应关闭，获得的任何结果将被视为无效。
Each packet record is 25 octets and includes 4 octets of sequence number, 8 octets of send timestamp, 2 octets of send timestamp error estimate, 8 octets of receive timestamp, 2 octets of receive timestamp error estimate, and 1 octet of Time To Live (TTL), or Hop Limit in IPv6:
每个数据包记录为25个八位字节，包括序列号的4个八位字节、发送时间戳的8个八位字节、发送时间戳错误估计的2个八位字节、接收时间戳错误估计的8个八位字节和IPv6中生存时间（TTL）或跳数限制的1个八位字节：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00| Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04| Send Error Estimate | Receive Error Estimate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
08| Send Timestamp |
12| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16| Receive Timestamp |
20| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24| TTL |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00| Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04| Send Error Estimate | Receive Error Estimate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
08| Send Timestamp |
12| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16| Receive Timestamp |
20| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24| TTL |
+-+-+-+-+-+-+-+-+
Packet records are sent out in the same order the actual packets were received. Therefore, the data is in arrival order.
数据包记录的发送顺序与实际数据包的接收顺序相同。因此，数据是按到达顺序排列的。
Note that lost packets (if any losses were detected during the OWAMP-Test session) MUST appear in the sequence of packets. They can appear either at the point when the loss was detected or at any later point. Lost packet records are distinguished as follows:
请注意，丢失的数据包（如果在OWAMP测试会话期间检测到任何丢失）必须出现在数据包序列中。它们可以出现在检测到丢失的时间点，也可以出现在以后的任何时间点。丢失数据包记录的区别如下：
+ A send timestamp filled with the presumed send time (as computed by the send schedule).
+ 一个发送时间戳，填充了假定的发送时间（由发送计划计算）。
+ A send error estimate filled with Multiplier=1, Scale=64, and S=0 (see the OWAMP-Test description for definition of these quantities and explanation of timestamp format and error estimate format).
+ 用乘数=1、刻度=64和S=0填充的发送错误估计值（有关这些量的定义以及时间戳格式和错误估计格式的说明，请参阅OWAMP测试说明）。
+ A normal receive error estimate as determined by the error of the clock being used to declare the packet lost. (It is declared lost if it is not received by the Timeout after the presumed send time, as determined by the receiver's clock.)
+ 由用于声明数据包丢失的时钟的误差确定的正常接收误差估计。（如果在假定的发送时间（由接收器的时钟确定）之后的超时未接收到，则声明丢失。）
+ A receive timestamp consisting of all zero bits.
+ 由所有零位组成的接收时间戳。
+ A TTL value of 255.
+ TTL值为255。
This section describes OWAMP-Test protocol. It runs over UDP, using sender and receiver IP and port numbers negotiated during the Request-Session exchange.
本节介绍OWAMP测试协议。它通过UDP运行，使用请求会话交换期间协商的发送方和接收方IP和端口号。
As with OWAMP-Control, OWAMP-Test has three modes: unauthenticated, authenticated, and encrypted. All OWAMP-Test sessions that are spawned by an OWAMP-Control session inherit its mode.
与OWAMP控制一样，OWAMP测试有三种模式：未验证、已验证和加密。由OWAMP控制会话生成的所有OWAMP测试会话都继承其模式。
OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and OWAMP-Test receiver can potentially all be different machines. (In a typical case, we expect that there will be only two machines.)
OWAMP控制客户端、OWAMP控制服务器、OWAMP测试发送器和OWAMP测试接收器可能都是不同的机器。（在典型情况下，我们预计只有两台机器。）
Send schedules based on slots, described previously, in conjunction with scheduled session start time, enable the sender and the receiver to compute the same exact packet sending schedule independently of each other. These sending schedules are independent for different OWAMP-Test sessions, even if they are governed by the same OWAMP-Control session.
前面描述的基于时隙的发送调度，结合调度的会话开始时间，使得发送方和接收方能够彼此独立地计算相同的精确分组发送调度。这些发送计划对于不同的OWAMP测试会话是独立的，即使它们由相同的OWAMP控制会话管理。
Consider any OWAMP-Test session. Once Start-Sessions exchange is complete, the sender is ready to start sending packets. Under normal OWAMP use circumstances, the time to send the first packet is in the near future (perhaps a fraction of a second away). The sender SHOULD send packets as close as possible to their scheduled time, with the following exception: if the scheduled time to send is in the past, and is separated from the present by more than Timeout time, the sender MUST NOT send the packet. (Indeed, such a packet would be considered lost by the receiver anyway.) The sender MUST keep track of which packets it does not send. It will use this to tell the receiver what packets were not sent by setting Skip Ranges in the Stop-Sessions message from the sender to the receiver upon completion of the test. The Skip Ranges are also sent to a Fetch-Client as part of the session data results. These holes in the sending schedule can happen if a time in the past was specified in the Request-Session command, or if the Start-Sessions exchange took unexpectedly long, or if the sender could not start serving the OWAMP-Test session on time due to internal scheduling problems of the OS. Packets that are in the past but are separated from the present by less than Timeout value SHOULD be sent as quickly as possible. With normal test rates and timeout values, the number of packets in such a burst is limited. Nevertheless, hosts SHOULD NOT intentionally schedule sessions so that such bursts of packets occur.
考虑任何OWAMP测试会话。一旦启动会话交换完成，发送方就可以开始发送数据包了。在正常的OWAMP使用情况下，发送第一个数据包的时间是在不久的将来（可能只有几分之一秒远）。发送方应在尽可能接近其预定时间的情况下发送数据包，但以下例外情况除外：如果预定发送时间在过去，且与现在的间隔超过超时时间，则发送方不得发送数据包。（事实上，这样的数据包无论如何都会被接收方视为丢失。）发送方必须跟踪它不发送的数据包。在测试完成后，它将通过在停止会话消息中设置跳过范围来告知接收方哪些数据包没有发送。跳过范围也作为会话数据结果的一部分发送到提取客户端。如果在请求会话命令中指定了过去的时间，或者启动会话交换花费了意外的长时间，或者由于操作系统的内部调度问题，发送方无法按时开始为OWAMP测试会话提供服务，则发送计划中可能会出现这些漏洞。过去的数据包与现在的数据包之间的间隔小于超时值，因此应尽快发送这些数据包。在正常测试速率和超时值的情况下，这种突发中的数据包数量是有限的。然而，主机不应该有意地安排会话，以便出现这样的数据包突发。
Regardless of any scheduling delays, each packet that is actually sent MUST have the best possible approximation of its real time of departure as its timestamp (in the packet).
无论任何调度延迟如何，实际发送的每个数据包都必须具有其实际出发时间的最佳近似值作为其时间戳（在数据包中）。
The sender sends the receiver a stream of packets with the schedule specified in the Request-Session command. The sender SHOULD set the TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The format of the body of a UDP packet in the stream depends on the mode being used.
发送方按照请求会话命令中指定的时间表向接收方发送数据包流。发送方应将UDP数据包中IPv4中的TTL（或IPv6中的跃点限制）设置为255。流中UDP数据包主体的格式取决于所使用的模式。
For unauthenticated mode:
对于未经验证的模式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For authenticated and encrypted modes:
对于认证和加密模式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the timestamp is the same as in [RFC1305] and is as follows: the first 32 bits represent the unsigned integer number of seconds elapsed since 0h on 1 January 1900; the next 32 bits represent the fractional part of a second that has elapsed since then.
时间戳的格式与[RFC1305]中的格式相同，如下所示：前32位表示自1900年1月1日0小时起经过的无符号整数秒数；接下来的32位表示从那时起经过的秒的小数部分。
So, Timestamp is represented as follows:
因此，时间戳表示如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fractional part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fractional part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Estimate specifies the estimate of the error and synchronization. It has the following format:
错误估计指定错误和同步的估计。其格式如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z| Scale | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z| Scale | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first bit, S, SHOULD be set if the party generating the timestamp has a clock that is synchronized to UTC using an external source (e.g., the bit should be set if GPS hardware is used and it indicates that it has acquired current position and time or if NTP is used and it indicates that it has synchronized to an external source, which includes stratum 0 source, etc.). If there is no notion of external synchronization for the time source, the bit SHOULD NOT be set. The next bit has the same semantics as MBZ fields elsewhere: it MUST be set to zero by the sender and ignored by everyone else. The next six bits, Scale, form an unsigned integer; Multiplier is an unsigned integer as well. They are interpreted as follows: the error estimate is equal to Multiplier*2^(-32)*2^Scale (in seconds). (Notation clarification: 2^Scale is two to the power of Scale.) Multiplier MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be considered corrupt and discarded.
如果生成时间戳的一方具有使用外部源与UTC同步的时钟，则应设置第一位S（例如，如果使用GPS硬件并指示其已获取当前位置和时间，或如果使用NTP并指示其已与外部源（包括地层0源等）同步，则应设置该位。）。如果时间源没有外部同步的概念，则不应设置该位。下一位与其他位置的MBZ字段具有相同的语义：发送方必须将其设置为零，其他所有人都将其忽略。下六位Scale构成无符号整数；乘法器也是无符号整数。它们被解释为follows:错误估计值等于乘法器*2^（-32）*2^刻度（以秒为单位）。（符号说明：2^刻度是刻度的二次幂。）不得将乘法器设置为零。如果乘法器为零，则应认为数据包已损坏并丢弃。
Sequence numbers start with zero and are incremented by one for each subsequent packet.
序列号从零开始，每个后续数据包的序列号递增一。
The minimum data segment length is, therefore, 14 octets in unauthenticated mode, and 48 octets in both authenticated mode and encrypted modes.
因此，在未验证模式下，最小数据段长度为14个八位字节，在验证模式和加密模式下，最小数据段长度为48个八位字节。
The OWAMP-Test packet layout is the same in authenticated and encrypted modes. The encryption and authentication operations are, however, different. The difference is that in encrypted mode both the sequence number and the timestamp are protected to provide maximum data confidentiality and integrity protection, whereas in authenticated mode the sequence number is protected while the timestamp is sent in clear text. Sending the timestamp in clear text in authenticated mode allows one to reduce the time between when a timestamp is obtained by a sender and when the packet is shipped out. In encrypted mode, the sender has to fetch the timestamp, encrypt it, and send it; in authenticated mode, the middle step is removed, potentially improving accuracy (the sequence number can be encrypted and authenticated before the timestamp is fetched).
在认证和加密模式下，OWAMP测试数据包布局相同。然而，加密和身份验证操作是不同的。不同之处在于，在加密模式下，序列号和时间戳都受到保护，以提供最大的数据机密性和完整性保护，而在认证模式下，序列号受到保护，而时间戳以明文形式发送。在认证模式下以明文形式发送时间戳允许减少发送方获得时间戳和数据包发出之间的时间。在加密模式下，发送方必须获取时间戳，加密它，然后发送它；在认证模式下，中间步骤被删除，这可能会提高准确性（序列号可以在获取时间戳之前进行加密和认证）。
In authenticated mode, the first block (16 octets) of each packet is encrypted using AES Electronic Cookbook (ECB) mode.
在认证模式下，使用AES电子食谱（ECB）模式对每个数据包的第一个数据块（16个八位字节）进行加密。
Similarly to each OWAMP-Control session, each OWAMP-Test session has two keys: an AES Session-key and an HMAC Session-key. However, there is a difference in how the keys are obtained: in the case of OWAMP-Control, the keys are generated by the client and communicated (as part of the Token) during connection setup as part of Set-Up-Response message; in the case of OWAMP-Test, described here, the keys are derived from the OWAMP-Control keys and the SID.
与每个OWAMP控制会话类似，每个OWAMP测试会话有两个密钥：AES会话密钥和HMAC会话密钥。但是，密钥的获取方式有所不同：在OWAMP控制的情况下，密钥由客户端生成，并在连接设置期间作为设置响应消息的一部分进行通信（作为令牌的一部分）；在这里描述的OWAMP测试的情况下，这些键来自OWAMP控制键和SID。
The OWAMP-Test AES Session-key is obtained as follows: the OWAMP-Control AES Session-key (the same AES Session-key as is used for the corresponding OWAMP-Control session, where it is used in a different chaining mode) is encrypted, using AES, with the 16-octet session identifier (SID) as the key; this is a single-block ECB encryption; its result is the OWAMP-Test AES Session-key to use in encrypting (and decrypting) the packets of the particular OWAMP-Test session. Note that all of OWAMP-Test AES Session-key, OWAMP-Control AES Session-key, and the SID are comprised of 16 octets.
OWAMP Test AES会话密钥的获取如下：使用AES加密OWAMP Control AES会话密钥（与对应OWAMP Control会话使用的AES会话密钥相同，在不同的链接模式中使用该密钥），并使用16个八位字节的会话标识符（SID）作为密钥；这是一个单块ECB加密；其结果是OWAMP测试AES会话密钥，用于加密（和解密）特定OWAMP测试会话的数据包。请注意，所有OWAMP测试AES会话密钥、OWAMP控制AES会话密钥和SID都由16个八位字节组成。
The OWAMP-Test HMAC Session-key is obtained as follows: the OWAMP-Control HMAC Session-key (the same HMAC Session-key as is used for the corresponding OWAMP-Control session) is encrypted, using AES, with the 16-octet session identifier (SID) as the key; this is a two-block CBC encryption, always performed with IV=0; its result is the OWAMP-Test HMAC Session-key to use in authenticating the packets of the particular OWAMP-Test session. Note that all of OWAMP-Test HMAC Session-key and OWAMP-Control HMAC Session-key are comprised of 32 octets, while the SID is 16 octets.
OWAMP Test HMAC会话密钥的获取如下：OWAMP Control HMAC会话密钥（与对应OWAMP Control会话使用的HMAC会话密钥相同）使用AES加密，以16个八位组会话标识符（SID）作为密钥；这是一个两块CBC加密，始终在IV=0时执行；其结果是OWAMP测试HMAC会话密钥，用于验证特定OWAMP测试会话的数据包。请注意，所有OWAMP测试HMAC会话密钥和OWAMP控制HMAC会话密钥都由32个八位字节组成，而SID是16个八位字节。
ECB mode used for encrypting the first block of OWAMP-Test packets in authenticated mode does not involve any actual chaining; this way, lost, duplicated, or reordered packets do not cause problems with deciphering any packet in an OWAMP-Test session.
用于在认证模式下加密OWAMP测试数据包的第一块的ECB模式不涉及任何实际链接；这样，丢失的、重复的或重新排序的数据包就不会在OWAMP测试会话中造成解密任何数据包的问题。
In encrypted mode, the first two blocks (32 octets) are encrypted using AES CBC mode. The AES Session-key to use is obtained in the same way as the key for authenticated mode. Each OWAMP-Test packet is encrypted as a separate stream, with just one chaining operation; chaining does not span multiple packets so that lost, duplicated, or reordered packets do not cause problems. The initialization vector for the CBC encryption is a value with all bits equal to zero.
在加密模式下，使用AES CBC模式对前两个块（32个八位字节）进行加密。要使用的AES会话密钥的获取方式与身份验证模式的密钥相同。每个OWAMP测试数据包被加密为一个单独的流，只需一个链接操作；链接不会跨越多个数据包，因此丢失、重复或重新排序的数据包不会导致问题。CBC加密的初始化向量是所有位都等于零的值。
Implementation note: Naturally, the key schedule for each OWAMP-Test session MAY be set up only once per session, not once per packet.
实现说明：自然地，每个OWAMP测试会话的密钥调度可能只在每个会话中设置一次，而不是在每个数据包中设置一次。
HMAC in OWAMP-Test only covers the part of the packet that is also encrypted. So, in authenticated mode, HMAC covers the first block (16 octets); in encrypted mode, HMAC covers two first blocks (32 octets). In OWAMP-Test HMAC is not encrypted (note that this is different from OWAMP-Control, where encryption in stream mode is used, so everything including the HMAC blocks ends up being encrypted).
OWAMP测试中的HMAC仅覆盖同样加密的数据包部分。因此，在认证模式下，HMAC覆盖第一个块（16个八位组）；在加密模式下，HMAC覆盖前两个块（32个八位字节）。在OWAMP测试中，HMAC是不加密的（请注意，这与OWAMP控制不同，OWAMP控制使用流模式加密，因此包括HMAC块在内的所有内容最终都被加密）。
In unauthenticated mode, no encryption or authentication is applied.
在未经身份验证的模式下，不应用加密或身份验证。
Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be generated independently of any other pseudo-random numbers mentioned in this document). However, implementations MUST provide a configuration parameter, an option, or a different means of making Packet Padding consist of all zeros.
OWAMP测试中的数据包填充应该是伪随机的（它必须独立于本文档中提到的任何其他伪随机数生成）。但是，实现必须提供一个配置参数、一个选项或使数据包填充由全零组成的不同方法。
The time elapsed between packets is computed according to the slot schedule as mentioned in Request-Session command description. At that point, we skipped over the issue of computing exponentially distributed pseudo-random numbers in a reproducible fashion. It is discussed later in a separate section.
根据请求会话命令描述中提到的时隙调度计算数据包之间经过的时间。那时，我们跳过了以可复制方式计算指数分布伪随机数的问题。这将在后面的单独章节中讨论。
The receiver knows when the sender will send packets. The following parameter is defined: Timeout (from Request-Session). Packets that are delayed by more than Timeout are considered lost (or "as good as lost"). Note that there is never an actual assurance of loss by the network: a "lost" packet might still be delivered at any time. The original specification for IPv4 required that packets be delivered within TTL seconds or never (with TTL having a maximum value of 255). To the best of the authors' knowledge, this requirement was never actually implemented (and, of course, only a complete and universal implementation would ensure that packets do not travel for longer than TTL seconds). In fact, in IPv6, the name of this field has actually been changed to Hop Limit. Further, IPv4 specification makes no claims about the time it takes the packet to traverse the last link of the path.
接收方知道发送方何时发送数据包。定义了以下参数：超时（来自请求会话）。延迟超过超时的数据包被视为丢失（或“与丢失一样好”）。请注意，网络从来没有实际的丢失保证：“丢失”的数据包仍可能在任何时候发送。IPv4的原始规范要求在TTL秒内或从不发送数据包（TTL的最大值为255）。据作者所知，这一要求从未真正实现过（当然，只有完整的通用实现才能确保数据包的传输时间不会超过TTL秒）。事实上，在IPv6中，此字段的名称实际上已更改为跃点限制。此外，IPv4规范没有声明数据包穿过路径的最后一条链路所需的时间。
The choice of a reasonable value of Timeout is a problem faced by a user of OWAMP protocol, not by an implementor. A value such as two minutes is very safe. Note that certain applications (such as interactive "one-way ping" might wish to obtain the data faster than that.
选择合理的超时值是OWAMP协议用户所面临的问题，而不是实现者所面临的问题。例如两分钟的值是非常安全的。请注意，某些应用程序（如交互式“单向ping”）可能希望更快地获取数据。
As packets are received,
当收到数据包时，
+ timestamp the received packet;
+ 对接收到的分组加时间戳；
+ in authenticated or encrypted mode, decrypt and authenticate as necessary (packets for which authentication fails MUST be discarded); and
+ 在认证或加密模式下，根据需要解密和认证（认证失败的数据包必须丢弃）；和
+ store the packet sequence number, send time, receive time, and the TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for the results to be transferred.
+ 存储数据包IP报头中的数据包序列号、发送时间、接收时间和IPv4的TTL（或IPv6的跃点限制），以便传输结果。
Packets not received within the Timeout are considered lost. They are recorded with their true sequence number, presumed send time, receive time value with all bits being zero, and a TTL (or Hop Limit) of 255.
在超时时间内未收到的数据包将被视为丢失。记录它们的真实序列号、假定的发送时间、接收时间值（所有位均为零）以及255的TTL（或跃点限制）。
Implementations SHOULD fetch the TTL/Hop Limit value from the IP header of the packet. If an implementation does not fetch the actual TTL value (the only good reason not to do so is an inability to access the TTL field of arriving packets), it MUST record the TTL value as 255.
实现应该从数据包的IP报头获取TTL/Hop限制值。如果实现没有获取实际的TTL值（不这样做的唯一原因是无法访问到达数据包的TTL字段），它必须将TTL值记录为255。
Packets that are actually received are recorded in the order of arrival. Lost packet records serve as indications of the send times of lost packets. They SHOULD be placed either at the point where the receiver learns about the loss or at any later point; in particular, one MAY place all the records that correspond to lost packets at the very end.
实际收到的数据包按到达顺序记录。丢失的数据包记录作为丢失数据包发送时间的指示。应将其放置在接收者了解损失的地点或任何以后的地点；特别地，可以将与丢失的分组相对应的所有记录放在最末端。
Packets that have send time in the future MUST be recorded normally, without changing their send timestamp, unless they have to be discarded. (Send timestamps in the future would normally indicate clocks that differ by more than the delay. Some data -- such as jitter -- can be extracted even without knowledge of time difference. For other kinds of data, the adjustment is best handled by the data consumer on the basis of the complete information in a measurement session, as well as, possibly, external data.)
必须正常记录将来有发送时间的数据包，而不更改其发送时间戳，除非必须丢弃这些数据包。（未来的发送时间戳通常会指示相差超过延迟的时钟。一些数据（如抖动）甚至可以在不知道时间差的情况下提取。对于其他类型的数据，调整最好由数据使用者根据测量会话中的完整信息以及poss进行处理。）（请参阅外部数据。）
Packets with a sequence number that was already observed (duplicate packets) MUST be recorded normally. (Duplicate packets are sometimes introduced by IP networks. The protocol has to be able to measure duplication.)
序列号为已观察到的数据包（重复数据包）必须正常记录。（IP网络有时会引入重复数据包。协议必须能够测量重复。）
If any of the following is true, the packet MUST be discarded:
如果以下任一项为真，则必须丢弃数据包：
+ Send timestamp is more than Timeout in the past or in the future.
+ 发送时间戳在过去或将来超过超时。
+ Send timestamp differs by more than Timeout from the time when the packet should have been sent according to its sequence number.
+ 发送时间戳与根据其序列号应发送数据包的时间相差超过超时。
+ In authenticated or encrypted mode, HMAC verification fails.
+ 在认证或加密模式下，HMAC验证失败。
Here we describe the way exponential random quantities used in the protocol are generated. While there is a fair number of algorithms for generating exponential random variables, most of them rely on having logarithmic function as a primitive, resulting in potentially different values, depending on the particular implementation of the math library. We use algorithm 3.4.1.S from [KNUTH], which is free of the above-mentioned problem, and which guarantees the same output on any implementation. The algorithm belongs to the ziggurat family developed in the 1970s by G. Marsaglia, M. Sibuya, and J. H. Ahrens [ZIGG]. It replaces the use of logarithmic function by clever bit manipulation, still producing the exponential variates on output.
这里我们描述协议中使用的指数随机量的生成方式。虽然有相当多的算法用于生成指数随机变量，但大多数算法都依赖于将对数函数作为基元，从而根据数学库的特定实现产生可能不同的值。我们使用[KNUTH]中的算法3.4.1.S，它不存在上述问题，并且保证在任何实现上都有相同的输出。该算法属于G.Marsaglia、M.Sibuya和J.H.Ahrens[ZIGG]在20世纪70年代开发的ziggurat家族。它通过巧妙的位操作取代了对数函数的使用，仍然在输出上产生指数变量。
For ease of exposition, the algorithm is first described with all arithmetic operations being interpreted in their natural sense. Later, exact details on data types, arithmetic, and generation of the uniform random variates used by the algorithm are given. It is an almost verbatim quotation from [KNUTH], p.133.
为了便于说明，首先描述该算法，所有算术运算均按其自然意义进行解释。随后，给出了该算法使用的数据类型、算法和均匀随机变量生成的确切细节。这几乎是[克努特]第133页的逐字引用。
Algorithm S: Given a real positive number "mu", produce an exponential random variate with mean "mu".
算法S：给定一个实正数“mu”，生成一个平均值为“mu”的指数随机变量。
First, the constants
首先是常数
Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11
Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11
are computed in advance. The exact values which MUST be used by all implementations are given in the next section. This is necessary to ensure that exactly the same pseudo-random sequences are produced by all implementations.
都是预先计算出来的。下一节将给出所有实现必须使用的确切值。这对于确保所有实现产生完全相同的伪随机序列是必要的。
S1. [Get U and shift.] Generate a 32-bit uniform random binary fraction
S1。[获取U和shift.]生成32位统一随机二进制分数
U = (.b0 b1 b2 ... b31) [note the binary point]
U = (.b0 b1 b2 ... b31) [note the binary point]
Locate the first zero bit b_j and shift off the leading (j+1) bits,
setting U <- (.b_{j+1} ... b31)
Locate the first zero bit b_j and shift off the leading (j+1) bits,
setting U <- (.b_{j+1} ... b31)
Note: In the rare case that the zero has not been found, it is prescribed that the algorithm return (mu*32*ln2).
注意：在很少的情况下，没有找到零，规定算法返回（mu*32*ln2）。
S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and terminate the algorithm. (Note that Q[1] = ln2.)
S2。[立即接受？]如果U<ln2，则设置X<-mu*（j*ln2+U）并终止算法。（注意Q[1]=ln2。）
S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k new uniform random binary fractions U1,...,Uk and set V <- min(U1,...,Uk).
S3。[最小化]找到最小k>=2，使U<Q[k]。生成k个新的均匀随机二元分数U1，…，Uk并设置V<-min（U1，…，Uk）。
S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2.
S4。[给出答案]设置X<-mu*（j+V）*ln2。
The high-level algorithm operates on real numbers, typically represented as floating point numbers. This specification prescribes that unsigned 64-bit integers be used instead.
高级算法对实数进行运算，通常以浮点数表示。本规范规定使用无符号64位整数。
u_int64_t integers are interpreted as real numbers by placing the decimal point after the first 32 bits. In other words, conceptually, the interpretation is given by the following map:
u_int64_t整数通过将小数点放在前32位之后解释为实数。换句话说，从概念上讲，解释由以下地图给出：
u_int64_t u;
u_int64_t u；
u |--> (double)u / (2**32)
u |--> (double)u / (2**32)
The algorithm produces a sequence of such u_int64_t integers that, for any given value of SID, is guaranteed to be the same on any implementation.
该算法生成这样的u_int64_t整数序列，对于任何给定的SID值，该序列在任何实现上都保证相同。
We specify that the u_int64_t representations of the first 11 values of the Q array in the high-level algorithm MUST be as follows:
我们指定高级算法中Q数组前11个值的u_int64_t表示必须如下所示：
#1 0xB17217F8, #2 0xEEF193F7, #3 0xFD271862, #4 0xFF9D6DD0, #5 0xFFF4CFD0, #6 0xFFFEE819, #7 0xFFFFE7FF, #8 0xFFFFFE2B, #9 0xFFFFFFE0, #10 0xFFFFFFFE, #11 0xFFFFFFFF
#1 0xB17217F8、#2 0xEEF193F7、#3 0xFD271862、#4 0xFF9D6DD0、#5 0xFFF4CFD0、#6 0xFFFEE819、#7 0xFFFF7FF、#8 0xFFFFFFFE2B、#9 0xFFFFFFFF0、#10 0xFFFFFFFFFFFE、#11 0xFFFFFFFFFFFF
For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32) = 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF.
例如，Q[1]=ln2实际上近似于0xB17217F8/（2**32）=0.693147180601954；对于j>11，Q[j]是0xFFFFFFFF。
Small integer j in the high-level algorithm is represented as u_int64_t value j * (2**32).
高级算法中的小整数j表示为u_int64_t值j*（2**32）。
Operation of addition is done as usual on u_int64_t numbers; however, the operation of multiplication in the high-level algorithm should be replaced by
在u_int64_t编号上，加法操作照常进行；但是，高级算法中的乘法运算应替换为
(u, v) |---> (u * v) >> 32.
(u, v) |---> (u * v) >> 32.
Implementations MUST compute the product (u * v) exactly. For example, a fragment of unsigned 128-bit arithmetic can be implemented for this purpose (see the sample implementation in Appendix A).
实现必须精确地计算乘积（u*v）。例如，可以为此目的实现一段无符号128位算术（参见附录a中的示例实现）。
The procedure for obtaining a sequence of 32-bit random numbers (such as U in algorithm S) relies on using AES encryption in counter mode. To describe the exact working of the algorithm, we introduce two primitives from Rijndael. Their prototypes and specification are given below, and they are assumed to be provided by the supporting Rijndael implementation, such as [RIJN].
获取32位随机数序列（如算法S中的U）的过程依赖于在计数器模式下使用AES加密。为了描述该算法的精确工作，我们引入了Rijndael的两个原语。下面给出了它们的原型和规范，并且假设它们由支持Rijndael的实现提供，例如[RIJN]。
+ A function that initializes a Rijndael key with bytes from seed (the SID will be used as the seed):
+ 使用seed中的字节初始化Rijndael密钥的函数（SID将用作seed）：
void KeyInit(unsigned char seed[16]);
void KeyInit（无符号字符种子[16]）；
+ A function that encrypts the 16-octet block inblock with the specified key, returning a 16-octet encrypted block. Here, keyInstance is an opaque type used to represent Rijndael keys:
+ 一种函数，用指定的密钥加密16个八位字节的块入块，返回一个16个八位字节的加密块。这里，keyInstance是一种不透明类型，用于表示Rijndael键：
void BlockEncrypt(keyInstance key, unsigned char inblock[16]);
void BlockEncrypt（keyInstance密钥，未签名字符inblock[16]）；
Algorithm Unif: given a 16-octet quantity seed, produce a sequence of unsigned 32-bit pseudo-random uniformly distributed integers. In OWAMP, the SID (session ID) from Control protocol plays the role of seed.
算法Unif：给定16个八位组的数量种子，生成一个无符号32位伪随机均匀分布整数序列。在OWAMP中，来自控制协议的SID（会话ID）扮演种子的角色。
U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an unsigned 16-octet (network byte order) counter] c <- 0
U1。[Initialize Rijndael key]key<-KeyInit（seed）[初始化一个无符号的16八位字节（网络字节顺序）计数器]c<-0
U2. [Need more random bytes?] Set i <- c mod 4. If (i == 0) set s
<- BlockEncrypt(key, c)
U2. [Need more random bytes?] Set i <- c mod 4. If (i == 0) set s
<- BlockEncrypt(key, c)
U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1
U3。[将计数器作为无符号16八位字节数量递增]c<-c+1
U4. [Do output] Output the i_th quartet of octets from s starting from high-order octets, converted to native byte order and represented as OWPNum64 value (as in 3.b).
U4。[Do output]从高阶八位字节开始，从s输出第i个四个八位字节，转换为本机字节顺序，并表示为OWPNum64值（如3.b所示）。
U5. [Loop] Go to step U2.
U5。[循环]转至步骤U2。
The goal of authenticated mode is to let one passphrase-protect the service provided by a particular OWAMP-Control server. One can imagine a variety of circumstances where this could be useful. Authenticated mode is designed to prohibit theft of service.
身份验证模式的目标是让一个密码短语保护特定OWAMP控制服务器提供的服务。人们可以想象，在各种情况下，这可能是有用的。身份验证模式旨在禁止窃取服务。
An additional design objective of the authenticated mode was to make it impossible for an attacker who cannot read traffic between OWAMP-Test sender and receiver to tamper with test results in a fashion that affects the measurements, but not other traffic.
认证模式的另一个设计目标是使无法读取OWAMP测试发送方和接收方之间通信量的攻击者不可能以影响测量的方式篡改测试结果，但不会影响其他通信量。
The goal of encrypted mode is quite different: to make it hard for a party in the middle of the network to make results look "better" than they should be. This is especially true if one of client and server does not coincide with either sender or receiver.
加密模式的目标是完全不同的：让网络中间的一方难以使结果看起来比他们“更好”。如果客户机和服务器中的一个与发送方或接收方不一致，则尤其如此。
Encryption of OWAMP-Control using AES CBC mode with blocks of HMAC after each message aims to achieve two goals: (i) to provide secrecy of exchange, and (ii) to provide authentication of each message.
在每条消息之后使用AES CBC模式和HMAC块对OWAMP控制进行加密旨在实现两个目标：（i）提供交换的保密性，以及（ii）提供每条消息的身份验证。
OWAMP-Test sessions directed at an unsuspecting party could be used for denial of service (DoS) attacks. In unauthenticated mode, servers SHOULD limit receivers to hosts they control or to the OWAMP-Control client.
针对不知情方的OWAMP测试会话可用于拒绝服务（DoS）攻击。在未经验证的模式下，服务器应将接收器限制为其控制的主机或OWAMP控制客户端。
Unless otherwise configured, the default behavior of servers MUST be to decline requests where the Receiver Address field is not equal to the address that the control connection was initiated from or an address of the server (or an address of a host it controls). Given the TCP handshake procedure and sequence numbers in the control connection, this ensures that the hosts that make such requests are actually those hosts themselves, or at least on the path towards them. If either this test or the handshake procedure were omitted, it would become possible for attackers anywhere in the Internet to request that large amounts of test packets be directed against victim nodes somewhere else.
除非另有配置，否则服务器的默认行为必须是拒绝接收方地址字段不等于启动控制连接的地址或服务器地址（或其控制的主机地址）的请求。给定TCP握手过程和控制连接中的序列号，这将确保发出此类请求的主机实际上就是这些主机本身，或者至少是在通向它们的路径上。如果省略此测试或握手过程，则Internet上任何位置的攻击者都可能请求将大量测试数据包定向到其他地方的受害节点。
In any case, OWAMP-Test packets with a given source address MUST only be sent from the node that has been assigned that address (i.e., address spoofing is not permitted).
在任何情况下，具有给定源地址的OWAMP测试数据包只能从已分配该地址的节点发送（即，不允许地址欺骗）。
OWAMP-Test sessions could be used as covert channels of information. Environments that are worried about covert channels should take this into consideration.
OWAMP测试会话可以用作隐蔽的信息通道。担心隐蔽通道的环境应该考虑到这一点。
Notice that AES, in counter mode, is used for pseudo-random number generation, so implementation of AES MUST be included even in a server that only supports unauthenticated mode.
请注意，计数器模式下的AES用于生成伪随机数，因此即使在仅支持未经验证模式的服务器中，也必须包含AES的实现。
An OWAMP server can consume resources of various kinds. The two most important kinds of resources are network capacity and memory (primary or secondary) for storing test results.
OWAMP服务器可以消耗各种资源。两种最重要的资源是用于存储测试结果的网络容量和内存（主要或次要）。
Any implementation of OWAMP server MUST include technical mechanisms to limit the use of network capacity and memory. Mechanisms for managing the resources consumed by unauthenticated users and users authenticated with a KeyID and passphrase SHOULD be separate. The default configuration of an implementation MUST enable these mechanisms and set the resource use limits to conservatively low values.
OWAMP服务器的任何实现都必须包括限制网络容量和内存使用的技术机制。管理未经身份验证的用户和使用密钥ID和密码短语进行身份验证的用户消耗的资源的机制应该是分开的。实现的默认配置必须启用这些机制，并将资源使用限制设置为保守的低值。
One way to design the resource limitation mechanisms is as follows: assign each session to a user class. User classes are partially ordered with "includes" relation, with one class ("all users") that is always present and that includes any other class. The assignment of a session to a user class can be based on the presence of authentication of the session, the KeyID, IP address range, time of day, and, perhaps, other factors. Each user class would have a limit for usage of network capacity (specified in units of bit/second) and memory for storing test results (specified in units of octets). Along with the limits for resource use, current use would be tracked by the server. When a session is requested by a user in a specific user class, the resources needed for this session are computed: the average network capacity use (based on the sending schedule) and the maximum memory use (based on the number of packets and number of octets each packet would need to be stored internally -- note that outgoing sessions would not require any memory use). These resource use numbers are added to the current resource use numbers for the given user class; if such addition would take the resource use outside of the limits for the given user class, the session is rejected. When resources are reclaimed, corresponding measures are subtracted from the current use. Network capacity is reclaimed as soon as the session ends. Memory is reclaimed when the data is
设计资源限制机制的一种方法如下：将每个会话分配给一个用户类。用户类通过“包含”关系进行部分排序，其中一个类（“所有用户”）始终存在，并且包含任何其他类。将会话分配给用户类可以基于会话的认证的存在、密钥id、IP地址范围、一天中的时间，以及可能的其他因素。每个用户类对网络容量（以位/秒为单位指定）和存储测试结果的内存（以八位字节为单位指定）的使用都有限制。除了资源使用的限制外，服务器还将跟踪当前的使用情况。当特定用户类中的用户请求会话时，将计算该会话所需的资源：平均网络容量使用（基于发送计划）和最大内存使用（根据数据包的数量和八位字节的数量，每个数据包需要在内部存储——注意，传出会话不需要任何内存使用）。这些资源使用编号将添加到给定用户类的当前资源使用编号中；如果此添加将使资源使用超出给定用户类的限制，则会话将被拒绝。回收资源时，将从当前使用中减去相应的度量值。网络容量将尽快回收会话结束。当数据丢失时，内存被回收
deleted. For unauthenticated sessions, memory consumed by an OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control connection that initiated the session is closed (gracefully or otherwise). For authenticated sessions, the administrator who configures the service should be able to decide the exact policy, but useful policy mechanisms that MAY be implemented are the ability to automatically reclaim memory when the data is retrieved and the ability to reclaim memory after a certain configurable (based on user class) period of time passes after the OWAMP-Test session terminates.
删除。对于未经身份验证的会话，应在启动会话的OWAMP控制连接关闭（正常或其他）后回收OWAMP测试会话所消耗的内存。对于经过身份验证的会话，配置服务的管理员应该能够确定确切的策略，但可以实现的有用策略机制包括在检索数据时自动回收内存的能力，以及在特定的可配置（基于用户类）后回收内存的能力OWAMP测试会话终止后经过一段时间。
At an early stage in designing the protocol, we considered using Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401] as cryptographic security mechanisms for OWAMP; later, we also considered DTLS. The disadvantages of those are as follows (not an exhaustive list):
在设计协议的早期阶段，我们考虑使用传输层安全性（TLS）[RFC2246，RFC3546]和IPsec[RFC2401]作为OWAMP的加密安全机制；后来，我们也考虑了DTL。这些方法的缺点如下（不是详尽的列表）：
Regarding TLS:
关于TLS：
+ TLS could be used to secure TCP-based OWAMP-Control, but it would be difficult to use it to secure UDP-based OWAMP-Test: OWAMP-Test packets, if lost, are not resent, so packets have to be (optionally) encrypted and authenticated while retaining individual usability. Stream-based TLS cannot be easily used for this.
+ TLS可用于保护基于TCP的OWAMP控制，但很难使用它来保护基于UDP的OWAMP测试：OWAMP测试数据包如果丢失，将不会重新发送，因此数据包必须（可选）加密和验证，同时保留单个可用性。基于流的TLS无法轻松用于此目的。
+ Dealing with streams, TLS does not authenticate individual messages (even in OWAMP-Control). The easiest way out would be to add some known-format padding to each message and to verify that the format of the padding is intact before using the message. The solution would thus lose some of its appeal ("just use TLS"). It would also be much more difficult to evaluate the security of this scheme with the various modes and options of TLS; it would almost certainly not be secure with all. The capacity of an attacker to replace parts of messages (namely, the end) with random garbage could have serious security implications and would need to be analyzed carefully. Suppose, for example, that a parameter that is used in some form to control the rate were replaced by random garbage; chances are that the result (an unsigned integer) would be quite large.
+ 处理流时，TLS不会对单个消息进行身份验证（即使在OWAMP控制中）。最简单的方法是在每条消息中添加一些已知的格式填充，并在使用消息之前验证填充的格式是否完整。因此，该解决方案将失去一些吸引力（“仅使用TLS”）。在TLS的各种模式和选项下，评估该方案的安全性也会困难得多；这几乎肯定不是所有人都安全的。攻击者用随机垃圾替换部分消息（即末端）的能力可能会带来严重的安全隐患，需要仔细分析。例如，假设以某种形式用于控制速率的参数被随机垃圾所取代；结果（无符号整数）很可能很大。
+ Dependent on the mode of use, one can end up with a requirement for certificates for all users and a PKI. Even if one is to accept that PKI is desirable, there just isn't a usable one today.
+ 根据使用模式的不同，最终可能需要为所有用户提供证书和PKI。即使人们愿意接受PKI是可取的，但目前还没有一个可用的PKI。
+ TLS requires a fairly large implementation. OpenSSL, for example, is larger than our implementation of OWAMP as a whole. This can matter for embedded implementations.
+ TLS需要相当大的实现。例如，OpenSSL总体上比我们的OWAMP实现更大。这对于嵌入式实现可能很重要。
Regarding DTLS:
关于DTL：
+ Duplication and, similarly, reordering are network phenomena that OWAMP needs to be able to measure; yet anti-replay measures and reordering protection of DTLS would prevent the duplicated and reordered packets from reaching the relevant part of the OWAMP code. One could, of course, modify DTLS so that these protections are weakened or even specify examining the messages in a carefully crafted sequence somewhere in between DTLS checks; but then, of course, the advantage of using an existing protocol would not be realized.
+ 重复和类似的重新排序是OWAMP需要能够测量的网络现象；然而，DTL的反重放措施和重新排序保护将防止重复和重新排序的数据包到达OWAMP代码的相关部分。当然，人们可以修改DTL，从而削弱这些保护，甚至可以指定在DTL检查之间的某个地方以精心编制的顺序检查消息；但是，当然，使用现有协议的优势将无法实现。
+ In authenticated mode, the timestamp is in the clear and is not protected cryptographically in any way, while the rest of the message has the same protection as in encrypted mode. This mode allows one to trade off cryptographic protection against accuracy of timestamps. For example, the APAN hardware implementation of OWAMP [APAN] is capable of supporting authenticated mode. The accuracy of these measurements is in the sub-microsecond range. The errors in OWAMP measurements of Abilene [Abilene] (done using a software implementation, in its encrypted mode) exceed 10us. Users in different environments have different concerns, and some might very well care about every last microsecond of accuracy. At the same time, users in these same environments might care about access control to the service. Authenticated mode permits them to control access to the server yet to use unprotected timestamps, perhaps generated by a hardware device.
+ 在认证模式下，时间戳处于清除状态，不以任何方式进行加密保护，而消息的其余部分具有与加密模式下相同的保护。这种模式允许人们权衡加密保护和时间戳的准确性。例如，OWAMP[APAN]的APAN硬件实现能够支持认证模式。这些测量的精度在亚微秒范围内。Abilene[Abilene]（在加密模式下使用软件实现）的OWAMP测量误差超过10us。不同环境中的用户有不同的关注点，有些用户可能非常关心每一微秒的准确性。同时，这些环境中的用户可能关心对服务的访问控制。身份验证模式允许他们控制对服务器的访问，而不使用可能由硬件设备生成的未受保护的时间戳。
Regarding IPsec:
关于IPsec：
+ What we now call authenticated mode would not be possible (in IPsec you can't authenticate part of a packet).
+ 我们现在所说的认证模式是不可能的（在IPsec中，您不能认证数据包的一部分）。
+ The deployment paths of IPsec and OWAMP could be separate if OWAMP does not depend on IPsec. After nine years of IPsec, only 0.05% of traffic on an advanced backbone network, such as Abilene, uses IPsec (for comparison purposes with encryption above layer 4, SSH use is at 2-4% and HTTPS use is at 0.2-0.6%). It is desirable to be able to deploy OWAMP on as large a number of different platforms as possible.
+ 如果OWAMP不依赖于IPsec，则IPsec和OWAMP的部署路径可以是分开的。经过九年的IPsec，高级骨干网络（如Abilene）上只有0.05%的流量使用IPsec（与第4层以上的加密相比，SSH使用率为2-4%，HTTPS使用率为0.2-0.6%）。希望能够在尽可能多的不同平台上部署OWAMP。
+ The deployment problems of a protocol dependent on IPsec would be especially acute in the case of lightweight embedded devices. Ethernet switches, DSL "modems", and other such devices mostly do not support IPsec.
+ 在轻量级嵌入式设备的情况下，依赖于IPsec的协议的部署问题尤其严重。以太网交换机、DSL“调制解调器”和其他此类设备大多不支持IPsec。
+ The API for manipulating IPsec from an application is currently poorly understood. Writing a program that needs to encrypt some packets, to authenticate some packets, and to leave some open -- for the same destination -- would become more of an exercise in IPsec than in IP measurement.
+ 从应用程序中操作IPsec的API目前了解得很少。编写一个需要加密某些数据包、对某些数据包进行身份验证以及为同一目的地保留某些数据包的程序，在IPsec中比在IP测量中更像是一项练习。
For the enumerated reasons, we decided to use a simple cryptographic protocol (based on a block cipher in CBC mode) that is different from TLS and IPsec.
出于上述原因，我们决定使用一个简单的加密协议（基于CBC模式下的分组密码），它不同于TLS和IPsec。
It might become necessary in the future to replace AES, or the way it is used in OWAMP, with a new cryptographic primitive, or to make other security-related changes to the protocol. OWAMP provides a well-defined point of extensibility: the Modes word in the server greeting and the Mode response in the Set-Up-Response message. For example, if a simple replacement of AES with a different block cipher with a 128-bit block is needed, this could be accomplished as follows: take two bits from the reserved (MBZ) part of the Modes word of the server greeting; use one of these bits to indicate encrypted mode with the new cipher and another one to indicate authenticated mode with the new cipher. (Bit consumption could, in fact, be reduced from two to one, if the client is allowed to return a mode selection with more than a single bit set: one could designate a single bit to mean that the new cipher is supported (in the case of the server) or selected (in the case of the client) and continue to use already allocated bits for authenticated and encrypted modes; this optimization is unimportant conceptually, but it could be useful in practice to make the best use of bits.) Then, if the new cipher is negotiated, all subsequent operations simply use it instead of AES. Note that the normal transition sequence would be used in such a case: implementations would probably first start supporting and preferring the new cipher, and then drop support for the old cipher (presumably no longer considered secure).
将来可能有必要使用新的加密原语替换AES，或在OWAMP中使用AES的方式，或对协议进行其他与安全相关的更改。OWAMP提供了一个定义良好的扩展点：服务器问候语中的Modes单词和setup响应消息中的Mode响应。例如，如果需要将AES简单地替换为具有128位块的不同分组密码，则可以按如下方式完成：从服务器问候语的Modes字的保留（MBZ）部分中提取两位；使用这些位中的一位表示使用新密码的加密模式，另一位表示使用新密码的身份验证模式。（事实上，如果允许客户端返回具有多个单个位集的模式选择，则位消耗可以从两个减少到一个：可以指定一个位，表示支持（对于服务器）或选择（对于客户端）新密码并继续将已分配的位用于身份验证和加密模式；这种优化在概念上并不重要，但在实践中最好地利用位是有用的。）然后，如果协商新密码，所有后续操作都只使用它而不是AES。请注意，在这种情况下将使用正常的转换序列：实现可能首先开始支持并首选新密码，然后放弃对旧密码的支持（可能不再被认为是安全的）。
If the need arises to make more extensive changes (perhaps to replace AES with a 256-bit-block cipher), this would be more difficult and would require changing the layout of the messages. However, the change can still be conducted within the framework of OWAMP extensibility using the Modes/Mode words. The semantics of the new bits (or single bit, if the optimization described above is used) would include the change to message layout as well as the change in the cryptographic primitive.
如果需要进行更广泛的更改（可能用256位分组密码替换AES），这将更加困难，并且需要更改消息的布局。但是，仍然可以使用Modes/Mode字在OWAMP扩展性框架内进行更改。新位（或单个位，如果使用上述优化）的语义将包括对消息布局的更改以及加密原语的更改。
Each of the bits in the Modes word can be used for an independent extension. The extensions signaled by various bits are orthogonal; for example, one bit might be allocated to change from AES-128 to some other cipher, another bit might be allocated to add a protocol feature (such as, e.g., support for measuring over multicast), yet another might be allocated to change a key derivation function, etc. The progression of versions is not a linear order, but rather a partial order. An implementation can implement any subset of these features (of course, features can be made mandatory to implement, e.g., new more secure ciphers if they are needed).
模式字中的每个位都可用于独立扩展。由不同比特发信号的扩展是正交的；例如，可以分配一个位以将AES-128更改为其他密码，可以分配另一个位以添加协议功能（例如，支持通过多播进行测量），还可以分配另一个位以更改密钥派生函数等。版本的进程不是线性顺序，而是偏序。一个实现可以实现这些特性的任何子集（当然，可以强制实现这些特性，例如，如果需要新的更安全的密码）。
Should a cipher with a different key size (say, a 256-bit key) become needed, a new key derivation function for OWAMP-Test keys would also be needed. The semantics of change in the cipher SHOULD then in the future be tied to the semantics of change in the key derivation function (KDF). One KDF that might be considered for the purpose might be a pseudo-random function (PRF) with appropriately sized output, such as 256 bits (perhaps HMAC-SHA256, if it is then still considered a secure PRF), which could then be used to derive the OWAMP-Test session keys from the OWAMP-Control session key by using the OWAMP-Control session key as the HMAC key and the SID as HMAC message.
如果需要具有不同密钥大小的密码（例如，256位密钥），还需要用于OWAMP测试密钥的新密钥派生函数。此后，密码中的更改语义应与密钥派生函数（KDF）中的更改语义相关联。为此目的可能考虑的一个KDF可能是具有适当大小输出的伪随机函数（PRF），例如256位（如果仍然认为HMAC-SHA256是安全PRF，则可能是HMAC-SHA256），然后，通过使用OWAMP控制会话密钥作为HMAC密钥，使用SID作为HMAC消息，可以从OWAMP控制会话密钥派生OWAMP测试会话密钥。
Note that the replacement scheme outlined above is trivially susceptible to downgrade attacks: a malicious party in the middle can flip modes bits as the mode is negotiated so that the oldest and weakest mode supported by the two parties is used. If this is deemed problematic at the time of cryptographic primitive replacement, the scheme might be augmented with a measure to prevent such an attack (by perhaps exchanging the modes again once a secure communications channel is established, comparing the two sets of mode words, and dropping the connection should they not match).
注意，上面提到的替换方案很容易受到降级攻击：中间的恶意方可以在模式被协商时翻转模式位，以便使用由双方所支持的最古老和最弱的模式。如果在密码原语替换时这被认为是有问题的，则该方案可以通过一种措施来增强，以防止这种攻击（通过在建立安全通信信道后再次交换模式，比较两组模式字，并在它们不匹配时断开连接）。
OWAMP-Control uses long-term keys with manual management. These keys are used to automatically negotiate session keys for each OWAMP-Control session running in authenticated or encrypted mode. The number of these keys managed by a server scales linearly with (and,
OWAMP控制使用手动管理的长期键。这些密钥用于自动协商以身份验证或加密模式运行的每个OWAMP控制会话的会话密钥。服务器管理的这些密钥的数量与（和，
in fact, is equal to) the number of administratively different users (perhaps particular humans, roles, or robots representing sites) that need to connect to this server. Similarly, the number of different manual keys managed by each client is the number of different servers that the client needs to connect to. This use of manual long-term keys is compliant with [BCP107].
实际上，等于）需要连接到此服务器的管理上不同的用户（可能是特定的人、角色或代表站点的机器人）的数量。类似地，每个客户端管理的不同手动密钥的数量是客户端需要连接到的不同服务器的数量。手动长期钥匙的使用符合[BCP107]。
A natural idea is to use the current time as salt when deriving session keys. Unfortunately, this appears to be too limiting.
一个自然的想法是在导出会话密钥时使用当前时间作为salt。不幸的是，这似乎过于局限。
Although OWAMP is often run on hosts with well-synchronized clocks, it is also possible to run it on hosts with clocks completely untrained. The delays obtained thus are, of course, not directly usable; however, some metrics, such as unidirectional loss, reordering, measures of congestion such as the median delay minus minimum, and many others are usable directly and immediately (and improve upon the information that would have been provided by a round-trip measurement). Further, even delay information can be useful with appropriate post-processing. Indeed, one can even argue that running the clocks free and post-processing the results of a mesh of measurements will result in better accuracy, as more information is available a posteriori and correlation of data from different hosts is possible in post-processing, but not with online clock training.
虽然OWAMP通常在时钟同步良好的主机上运行，但也可以在时钟完全未经训练的主机上运行。因此获得的延迟当然不能直接使用；然而，一些指标，如单向损失、重新排序、拥塞度量（如中间延迟减去最小值）和许多其他指标可以直接和立即使用（并改进往返测量提供的信息）。此外，通过适当的后处理，甚至延迟信息也可能有用。事实上，人们甚至可以争辩说，无需运行时钟并对测量网格的结果进行后处理将获得更高的精度，因为在后处理中可以获得更多的信息，并且可以对来自不同主机的数据进行后验和关联，但在线时钟训练则不行。
Given this, time is not used as salt in key derivation.
有鉴于此，时间在密钥派生中不被用作盐。
OWAMP relies on AES-CBC for confidentiality and on HMAC-SHA1 truncated to 128 bits for message authentication. Random IV choice is important for prevention of a codebook attack on the first block (it should also be noted that, with its 128-bit block size, AES is more resistant to codebook attacks than are ciphers with shorter blocks; we use random IV anyway).
OWAMP依靠AES-CBC进行保密，依靠HMAC-SHA1截断为128位进行消息身份验证。随机IV选择对于防止第一个块上的码本攻击非常重要（还应注意，由于其128位块大小，AES比具有较短块的密码更能抵抗码本攻击；无论如何，我们使用随机IV）。
HMAC MUST verify. It is crucial to check for this before using the message; otherwise, existential forgery becomes possible. The complete message for which HMAC verification fails MUST be discarded (both for short messages consisting of a few blocks and potentially for long messages, such as a response to the Fetch-Session command). If such a message is part of OWAMP-Control, the connection MUST be dropped.
HMAC必须进行验证。在使用信息之前检查这一点至关重要；否则，存在伪造就成为可能。必须丢弃HMAC验证失败的完整消息（对于由几个块组成的短消息和可能的长消息，例如对Fetch会话命令的响应）。如果此类消息是OWAMP控制的一部分，则必须断开连接。
Since OWAMP messages can have different numbers of blocks, the existential forgery attack described in example 9.62 of [MENEZES]
由于OWAMP消息可以具有不同数量的块，因此[MENEZES]的示例9.62中描述的存在伪造攻击
becomes a concern. To prevent it (and to simplify implementation), the length of any message becomes known after decrypting its first block.
这成为一个问题。为了防止这种情况发生（并简化实现），任何消息的长度在解密其第一个块后都是已知的。
A special case is the first (fixed-length) message sent by the client. There, the token is a concatenation of the 128-bit challenge (transmitted by the server in the clear), a 128-bit AES Session-key (generated randomly by the client, encrypted with AES-CBC with IV=0), and a 256-bit HMAC-SHA1 Session-key used for authentication. Since IV=0, the challenge (a single cipher block) is simply encrypted with the secret key. Therefore, we rely on resistance of AES to chosen plaintext attacks (as the challenge could be substituted by an attacker). It should be noted that the number of blocks of chosen plaintext an attacker can have encrypted with the secret key is limited by the number of sessions the client wants to initiate. An attacker who knows the encryption of a server's challenge can produce an existential forgery of the session key and thus disrupt the session; however, any attacker can disrupt a session by corrupting the protocol messages in an arbitrary fashion. Therefore, no new threat is created here; nevertheless, we require that the server never issues the same challenge twice. (If challenges are generated randomly, a repetition would occur, on average, after 2^64 sessions; we deem this satisfactory as this is enough even for an implausibly busy server that participates in 1,000,000 sessions per second to go without repetitions for more than 500 centuries.) With respect to the second part of the token, an attacker can produce an existential forgery of the session key by modifying the second half of the client's token while leaving the first part intact. This forgery, however, would be immediately discovered by the client when the HMAC on the server's next message (acceptance or rejection of the connection) does not verify.
一种特殊情况是客户端发送的第一条（固定长度）消息。其中，令牌是128位质询（由服务器以明文形式传输）、128位AES会话密钥（由客户端随机生成，用AES-CBC加密，IV=0）和用于认证的256位HMAC-SHA1会话密钥的串联。由于IV=0，质询（单个密码块）仅使用密钥加密。因此，我们依赖AES对选定的明文攻击的抵抗力（因为攻击者可以替代该挑战）。需要注意的是，攻击者可以使用密钥加密的选定明文块的数量受到客户端想要发起的会话数量的限制。知道服务器挑战加密的攻击者可以伪造会话密钥，从而中断会话；但是，任何攻击者都可以通过任意方式破坏协议消息来中断会话。因此,这里没有新的威胁,；然而，我们要求服务器永远不要发出相同的质询两次。（如果随机生成挑战，平均而言，在2^64个会话后会出现重复；我们认为这是令人满意的，因为这对于一个每秒参与1000000个会话的异常繁忙的服务器来说已经足够了，在500多个世纪内不会重复。）关于令牌的第二部分，攻击者可以通过修改客户端令牌的后半部分，同时保持第一部分完整，从而产生会话密钥的存在伪造。然而，当服务器的下一条消息（接受或拒绝连接）上的HMAC未验证时，客户端会立即发现这种伪造。
We would like to thank Guy Almes, Mark Allman, Jari Arkko, Hamid Asgari, Steven Van den Berghe, Eric Boyd, Robert Cole, Joan Cucchiara, Stephen Donnelly, Susan Evett, Sam Hartman, Kaynam Hedayat, Petri Helenius, Scott Hollenbeck, Russ Housley, Kitamura Yasuichi, Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah, Allison Mankin, Al Morton, Attila Pasztor, Randy Presuhn, Matthew Roughan, Andy Scherrer, Henk Uijterwaal, and Sam Weiler for their comments, suggestions, reviews, helpful discussion and proof-reading.
我们要感谢盖伊·阿尔姆斯、马克·奥尔曼、贾里·阿克科、哈米德·阿斯加里、史蒂文·范登伯格、埃里克·博伊德、罗伯特·科尔、琼·库奇亚拉、斯蒂芬·唐纳利、苏珊·埃维特、山姆·哈特曼、凯南·赫达亚特、佩特里·海伦纽斯、斯科特·霍伦贝克、罗斯·霍斯利、北村·亚苏伊奇、丹尼尔·H·T·R·劳森、威尔·E·利兰、布鲁斯·马、艾莉森·曼金、艾尔·莫顿、，感谢Attila Pasztor、Randy Presohn、Matthew Rawan、Andy Scherrer、Henk Uijterwaal和Sam Weiler的评论、建议、评论、有益的讨论和校对。
IANA has allocated a well-known TCP port number (861) for the OWAMP-Control part of the OWAMP protocol.
IANA为OWAMP协议的OWAMP控制部分分配了一个众所周知的TCP端口号（861）。
The protocol does not carry any information in a natural language, with the possible exception of the KeyID in OWAMP-Control, which is encoded in UTF-8.
该协议不携带任何自然语言的信息，但OWAMP控制中的KeyID可能例外，它是用UTF-8编码的。
[AES] Advanced Encryption Standard (AES),
http://csrc.nist.gov/encryption/aes/
[AES] Advanced Encryption Standard (AES),
http://csrc.nist.gov/encryption/aes/
[BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[BCP107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
[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月。
[RFC2836] Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.
[RFC2836]Brim，S.，Carpenter，B.，和F.Le Faucheur，“每跳行为识别码”，RFC 28362000年5月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[RFC2898]Kaliski，B.，“PKCS#5：基于密码的加密规范版本2.0”，RFC 28982000年9月。
[APAN] Z. Shu and K. Kobayashi, "HOTS: An OWAMP-Compliant
Hardware Packet Timestamper", In Proceedings of PAM
2005, http://www.springerlink.com/index/
W4GBD39YWC11GQTN.pdf
[APAN] Z. Shu and K. Kobayashi, "HOTS: An OWAMP-Compliant
Hardware Packet Timestamper", In Proceedings of PAM
2005, http://www.springerlink.com/index/
W4GBD39YWC11GQTN.pdf
[BRIX] Brix Networks, http://www.brixnet.com/
[BRIX] Brix Networks, http://www.brixnet.com/
[ZIGG] J. H. Ahrens, U. Dieter, "Computer methods for sampling from the exponential and normal distributions", Communications of ACM, volume 15, issue 10, 873-882, 1972. http://doi.acm.org/10.1145/355604.361593
[ZIGG]J.H.Ahrens，U.Dieter，“指数分布和正态分布抽样的计算机方法”，ACM通讯，第15卷，第10期，873-882，1972年。http://doi.acm.org/10.1145/355604.361593
[MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, revised reprint with updates, 1997.
[MENEZES]A.J.MENEZES，P.C.van Oorschot和S.A.Vanstone，《应用密码学手册》，CRC出版社，修订版和更新版，1997年。
[KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd edition, 1998.
[KNUTH]D.KNUTH，《计算机编程的艺术》，第二卷，第三版，1998年。
[Abilene] One-way Latency Measurement (OWAMP),
http://e2epi.internet2.edu/owamp/
[Abilene] One-way Latency Measurement (OWAMP),
http://e2epi.internet2.edu/owamp/
[RIJN] Reference ANSI C Implementation of Rijndael,
http://www.esat.kuleuven.ac.be/~rijmen/
rijndael/rijndaelref.zip
[RIJN] Reference ANSI C Implementation of Rijndael,
http://www.esat.kuleuven.ac.be/~rijmen/
rijndael/rijndaelref.zip
[RIPE] RIPE NCC Test-Traffic Measurements home, http://www.ripe.net/test-traffic/.
[成熟]成熟的NCC测试交通测量主页，http://www.ripe.net/test-traffic/.
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/.
[测量师]测量师主页，http://www.advanced.org/surveyor/.
[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, "Surveyor: An
Infrastructure for Network Performance Measurements",
Proceedings of INET'99, June 1999.
http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, "Surveyor: An
Infrastructure for Network Performance Measurements",
Proceedings of INET'99, June 1999.
http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC1305，1992年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[RFC3546]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 35462003年6月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
Appendix A: Sample C Code for Exponential Deviates
附录A：指数偏差的样本C代码
The values in array Q[] are the exact values that MUST be used by all implementations (see Sections 5.1 and 5.2). This appendix only serves for illustrative purposes.
数组Q[]中的值是所有实现必须使用的精确值（参见第5.1节和第5.2节）。本附录仅用于说明目的。
/*
** Example usage: generate a stream of exponential (mean 1)
** random quantities (ignoring error checking during initialization).
** If a variate with some mean mu other than 1 is desired, the output
** of this algorithm can be multiplied by mu according to the rules
** of arithmetic we described.
/*
** Example usage: generate a stream of exponential (mean 1)
** random quantities (ignoring error checking during initialization).
** If a variate with some mean mu other than 1 is desired, the output
** of this algorithm can be multiplied by mu according to the rules
** of arithmetic we described.
** Assume that a 16-octet 'seed' has been initialized
** (as the shared secret in OWAMP, for example)
** unsigned char seed[16];
** Assume that a 16-octet 'seed' has been initialized
** (as the shared secret in OWAMP, for example)
** unsigned char seed[16];
** OWPrand_context next;
** OWPrand_context next;
** (initialize state)
** OWPrand_context_init(&next, seed);
** (initialize state)
** OWPrand_context_init(&next, seed);
** (generate a sequence of exponential variates)
** while (1) {
** u_int64_t num = OWPexp_rand64(&next);
<do something with num here>
...
** }
*/
** (generate a sequence of exponential variates)
** while (1) {
** u_int64_t num = OWPexp_rand64(&next);
<do something with num here>
...
** }
*/
#include <stdlib.h>
#include <stdlib.h>
typedef u_int64_t u_int64_t;
typedef u_int64_t u_int64_t；
/* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */
#define K 12
/* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */
#define K 12
#define BIT31 0x80000000UL /* See if first bit in the lower
32 bits is zero. */
#define MASK32(n) ((n) & 0xFFFFFFFFUL)
#define BIT31 0x80000000UL /* See if first bit in the lower
32 bits is zero. */
#define MASK32(n) ((n) & 0xFFFFFFFFUL)
#define EXP2POW32 0x100000000ULL
#定义EXP2POW32 0x100000000整数
typedef struct OWPrand_context {
unsigned char counter[16];/* Counter (network byte order).*/
keyInstance key; /* Key to encrypt the counter.*/
unsigned char out[16]; /* The encrypted block.*/
typedef struct OWPrand_context {
unsigned char counter[16];/* Counter (network byte order).*/
keyInstance key; /* Key to encrypt the counter.*/
unsigned char out[16]; /* The encrypted block.*/
} OWPrand_context;
}OWPrand_语境；
/*
** The array has been computed according to the formula:
**
** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!)
**
** as described in algorithm S. (The values below have been
** multiplied by 2^32 and rounded to the nearest integer.)
** These exact values MUST be used so that different implementation
** produce the same sequences.
*/
static u_int64_t Q[K] = {
0, /* Placeholder - so array indices start from 1. */
0xB17217F8,
0xEEF193F7,
0xFD271862,
0xFF9D6DD0,
0xFFF4CFD0,
0xFFFEE819,
0xFFFFE7FF,
0xFFFFFE2B,
0xFFFFFFE0,
0xFFFFFFFE,
0xFFFFFFFF
};
/*
** The array has been computed according to the formula:
**
** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!)
**
** as described in algorithm S. (The values below have been
** multiplied by 2^32 and rounded to the nearest integer.)
** These exact values MUST be used so that different implementation
** produce the same sequences.
*/
static u_int64_t Q[K] = {
0, /* Placeholder - so array indices start from 1. */
0xB17217F8,
0xEEF193F7,
0xFD271862,
0xFF9D6DD0,
0xFFF4CFD0,
0xFFFEE819,
0xFFFFE7FF,
0xFFFFFE2B,
0xFFFFFFE0,
0xFFFFFFFE,
0xFFFFFFFF
};
/* this element represents ln2 */
#define LN2 Q[1]
/* this element represents ln2 */
#define LN2 Q[1]
/*
** Convert an unsigned 32-bit integer into a u_int64_t number.
*/
u_int64_t
OWPulong2num64(u_int32_t a)
{
return ((u_int64_t)1 << 32) * a;
}
/*
** Convert an unsigned 32-bit integer into a u_int64_t number.
*/
u_int64_t
OWPulong2num64(u_int32_t a)
{
return ((u_int64_t)1 << 32) * a;
}
/*
** Arithmetic functions on u_int64_t numbers.
*/
/*
** Arithmetic functions on u_int64_t numbers.
*/
/*
** Addition.
*/
u_int64_t
OWPnum64_add(u_int64_t x, u_int64_t y)
/*
** Addition.
*/
u_int64_t
OWPnum64_add(u_int64_t x, u_int64_t y)
{
return x + y;
}
{
return x + y;
}
/*
** Multiplication. Allows overflow. Straightforward implementation
** of Algorithm 4.3.1.M (p.268) from [KNUTH].
*/
u_int64_t
OWPnum64_mul(u_int64_t x, u_int64_t y)
{
unsigned long w[4];
u_int64_t xdec[2];
u_int64_t ydec[2];
/*
** Multiplication. Allows overflow. Straightforward implementation
** of Algorithm 4.3.1.M (p.268) from [KNUTH].
*/
u_int64_t
OWPnum64_mul(u_int64_t x, u_int64_t y)
{
unsigned long w[4];
u_int64_t xdec[2];
u_int64_t ydec[2];
int i, j;
u_int64_t k, t, ret;
int i, j;
u_int64_t k, t, ret;
xdec[0] = MASK32(x);
xdec[1] = MASK32(x>>32);
ydec[0] = MASK32(y);
ydec[1] = MASK32(y>>32);
xdec[0] = MASK32(x);
xdec[1] = MASK32(x>>32);
ydec[0] = MASK32(y);
ydec[1] = MASK32(y>>32);
for (j = 0; j < 4; j++)
w[j] = 0;
for (j = 0; j < 4; j++)
w[j] = 0;
for (j = 0; j < 2; j++) {
k = 0;
for (i = 0; ; ) {
t = k + (xdec[i]*ydec[j]) + w[i + j];
w[i + j] = t%EXP2POW32;
k = t/EXP2POW32;
if (++i < 2)
continue;
else {
w[j + 2] = k;
break;
}
}
}
for (j = 0; j < 2; j++) {
k = 0;
for (i = 0; ; ) {
t = k + (xdec[i]*ydec[j]) + w[i + j];
w[i + j] = t%EXP2POW32;
k = t/EXP2POW32;
if (++i < 2)
continue;
else {
w[j + 2] = k;
break;
}
}
}
ret = w[2];
ret <<= 32;
return w[1] + ret;
}
ret = w[2];
ret <<= 32;
return w[1] + ret;
}
/*
/*
** Seed the random number generator using a 16-byte quantity 'seed'
** (== the session ID in OWAMP). This function implements step U1
** of algorithm Unif.
*/
** Seed the random number generator using a 16-byte quantity 'seed'
** (== the session ID in OWAMP). This function implements step U1
** of algorithm Unif.
*/
void
OWPrand_context_init(OWPrand_context *next, unsigned char *seed)
{
int i;
void
OWPrand_context_init(OWPrand_context *next, unsigned char *seed)
{
int i;
/* Initialize the key */
rijndaelKeyInit(next->key, seed);
/* Initialize the key */
rijndaelKeyInit(next->key, seed);
/* Initialize the counter with zeros */
memset(next->out, 0, 16);
for (i = 0; i < 16; i++)
next->counter[i] = 0UL;
}
/* Initialize the counter with zeros */
memset(next->out, 0, 16);
for (i = 0; i < 16; i++)
next->counter[i] = 0UL;
}
/*
** Random number generating functions.
*/
/*
** Random number generating functions.
*/
/*
** Generate and return a 32-bit uniform random value (saved in the
**less significant half of the u_int64_t). This function implements
**steps U2-U4 of the algorithm Unif.
*/
u_int64_t
OWPunif_rand64(OWPrand_context *next)
{
int j;
u_int8_t *buf;
u_int64_t ret = 0;
/*
** Generate and return a 32-bit uniform random value (saved in the
**less significant half of the u_int64_t). This function implements
**steps U2-U4 of the algorithm Unif.
*/
u_int64_t
OWPunif_rand64(OWPrand_context *next)
{
int j;
u_int8_t *buf;
u_int64_t ret = 0;
/* step U2 */
u_int8_t i = next->counter[15] & (u_int8_t)3;
if (!i)
rijndaelEncrypt(next->key, next->counter, next->out);
/* step U2 */
u_int8_t i = next->counter[15] & (u_int8_t)3;
if (!i)
rijndaelEncrypt(next->key, next->counter, next->out);
/* Step U3. Increment next.counter as a 16-octet single
quantity in network byte order for AES counter mode. */
for (j = 15; j >= 0; j--)
if (++next->counter[j])
break;
/* Step U3. Increment next.counter as a 16-octet single
quantity in network byte order for AES counter mode. */
for (j = 15; j >= 0; j--)
if (++next->counter[j])
break;
/* Step U4. Do output. The last 4 bytes of ret now contain
/* Step U4. Do output. The last 4 bytes of ret now contain
the random integer in network byte order */
buf = &next->out[4*i];
for (j=0; j<4; j++) {
ret <<= 8;
ret += *buf++;
}
return ret;
}
the random integer in network byte order */
buf = &next->out[4*i];
for (j=0; j<4; j++) {
ret <<= 8;
ret += *buf++;
}
return ret;
}
/*
** Generate an exponential deviate with mean 1.
*/
u_int64_t
OWPexp_rand64(OWPrand_context *next)
{
unsigned long i, k;
u_int32_t j = 0;
u_int64_t U, V, J, tmp;
/*
** Generate an exponential deviate with mean 1.
*/
u_int64_t
OWPexp_rand64(OWPrand_context *next)
{
unsigned long i, k;
u_int32_t j = 0;
u_int64_t U, V, J, tmp;
/* Step S1. Get U and shift */
U = OWPunif_rand64(next);
/* Step S1. Get U and shift */
U = OWPunif_rand64(next);
while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */
U <<= 1;
j++;
}
/* Remove the 0 itself. */
U <<= 1;
while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */
U <<= 1;
j++;
}
/* Remove the 0 itself. */
U <<= 1;
U = MASK32(U); /* Keep only the fractional part. */
J = OWPulong2num64(j);
U = MASK32(U); /* Keep only the fractional part. */
J = OWPulong2num64(j);
/* Step S2. Immediate acceptance? */
if (U < LN2) /* return (j*ln2 + U) */
return OWPnum64_add(OWPnum64_mul(J, LN2), U);
/* Step S2. Immediate acceptance? */
if (U < LN2) /* return (j*ln2 + U) */
return OWPnum64_add(OWPnum64_mul(J, LN2), U);
/* Step S3. Minimize. */
for (k = 2; k < K; k++)
if (U < Q[k])
break;
V = OWPunif_rand64(next);
for (i = 2; i <= k; i++) {
tmp = OWPunif_rand64(next);
if (tmp < V)
V = tmp;
}
/* Step S3. Minimize. */
for (k = 2; k < K; k++)
if (U < Q[k])
break;
V = OWPunif_rand64(next);
for (i = 2; i <= k; i++) {
tmp = OWPunif_rand64(next);
if (tmp < V)
V = tmp;
}
/* Step S4. Return (j+V)*ln2 */
/* Step S4. Return (j+V)*ln2 */
return OWPnum64_mul(OWPnum64_add(J, V), LN2);
}
return OWPnum64_mul(OWPnum64_add(J, V), LN2);
}
Appendix B: Test Vectors for Exponential Deviates
附录B：指数偏差的测试向量
It is important that the test schedules generated by different implementations from identical inputs be identical. The non-trivial part is the generation of pseudo-random exponentially distributed deviates. To aid implementors in verifying interoperability, several test vectors are provided. For each of the four given 128-bit values of SID represented as hexadecimal numbers, 1,000,000 exponentially distributed 64-bit deviates are generated as described above. As they are generated, they are all added to each other. The sum of all 1,000,000 deviates is given as a hexadecimal number for each SID. An implementation MUST produce exactly these hexadecimal numbers. To aid in the verification of the conversion of these numbers to values of delay in seconds, approximate values are given (assuming lambda=1). An implementation SHOULD produce delay values in seconds that are close to the ones given below.
不同实现从相同输入生成的测试计划必须相同，这一点很重要。最重要的部分是伪随机指数分布偏差的产生。为了验证互操作性，在测试中提供了多个实现器。对于表示为十六进制数的SID的四个给定128位值中的每一个，如上所述生成1000000个指数分布的64位偏差。在生成它们时，它们都会相互添加。对于每个SID，所有1000000个偏差的总和以十六进制数表示。实现必须精确地生成这些十六进制数。为了帮助验证将这些数字转换为延迟值（以秒为单位），给出了近似值（假设λ=1）。一个实现应该以秒为单位产生延迟值，接近下面给出的值。
SID = 0x2872979303ab47eeac028dab3829dab2 SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds)
SID=0x2872979303ab47eeac028dab3829dab2和[1000000]=0x000f4479bd317381（1000569.739036秒）
SID = 0x0102030405060708090a0b0c0d0e0f00 SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds)
SID=0x0102030405060708090a0b0c0d0e0f00总和[1000000]=0x000f433686466a62（1000246.524512秒）
SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)
SID=0xDeadBeefDeadBeefDeadBeefDeadBeefBeefDeadBeef总和[1000000]=0x000f416c8884d2d3（999788.533277秒）
SID = 0xfeed0feed1feed2feed3feed4feed5ab SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)
SID=0xfeed0feed1feed2feed3feed4feed5ab和[1000000]=0x000f3f0b4b416ec8（999179.293967秒）
Authors' Addresses
作者地址
Stanislav Shalunov Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
Stanislav Shalunov Internet2密歇根州安阿伯奥克布鲁克大道1000号300室48104
EMail: shalunov@internet2.edu
WWW: http://www.internet2.edu/~shalunov/
EMail: shalunov@internet2.edu
WWW: http://www.internet2.edu/~shalunov/
Benjamin Teitelbaum Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
Benjamin Teitelbaum Internet2密歇根州安阿伯奥克布鲁克大道1000号300室48104
EMail: ben@internet2.edu
WWW: http://people.internet2.edu/~ben/
EMail: ben@internet2.edu
WWW: http://people.internet2.edu/~ben/
Anatoly Karp Computer Sciences Department University of Wisconsin-Madison Madison, WI 53706
阿纳托利卡普计算机科学系威斯康星大学麦迪逊麦迪逊分校，WI 53706
EMail: akarp@cs.wisc.edu
EMail: akarp@cs.wisc.edu
Jeff W. Boote Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
Jeff W.Boote Internet2密歇根州安娜堡奥克布鲁克大道1000号300室48104
EMail: boote@internet2.edu
EMail: boote@internet2.edu
Matthew J. Zekauskas Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
Matthew J.Zekauskas Internet2密歇根州安阿伯市奥克布鲁克大道1000号300室48104
EMail: matt@internet2.edu
EMail: matt@internet2.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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.
本文件受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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。