Internet Engineering Task Force (IETF) D. Frost
Request for Comments: 6374 S. Bryant
Category: Standards Track Cisco Systems
ISSN: 2070-1721 September 2011
Internet Engineering Task Force (IETF) D. Frost
Request for Comments: 6374 S. Bryant
Category: Standards Track Cisco Systems
ISSN: 2070-1721 September 2011
Packet Loss and Delay Measurement for MPLS Networks
MPLS网络的丢包和时延测量
Abstract
摘要
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks.
许多服务提供商服务水平协议（SLA）依赖于测量和监控数据包丢失、单向和双向延迟的性能指标以及相关指标（如延迟变化和信道吞吐量）的能力。这种测量能力还为运营商提供了对其网络性能特征的更大可视性，从而有助于规划、故障排除和网络性能评估。本文件规定了协议机制，以便能够在MPLS网络中高效、准确地测量这些性能指标。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6374.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6374.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Applicability and Scope ....................................5
1.2. Terminology ................................................6
1.3. Requirements Language ......................................6
2. Overview ........................................................6
2.1. Basic Bidirectional Measurement ............................6
2.2. Packet Loss Measurement ....................................7
2.3. Throughput Measurement ....................................10
2.4. Delay Measurement .........................................10
2.5. Delay Variation Measurement ...............................12
2.6. Unidirectional Measurement ................................12
2.7. Dyadic Measurement ........................................13
2.8. Loopback Measurement ......................................13
2.9. Measurement Considerations ................................14
2.9.1. Types of Channels ..................................14
2.9.2. Quality of Service .................................14
2.9.3. Measurement Point Location .........................14
2.9.4. Equal Cost Multipath ...............................15
2.9.5. Intermediate Nodes .................................15
2.9.6. Different Transmit and Receive Interfaces ..........16
2.9.7. External Post-Processing ...........................16
2.9.8. Loss Measurement Modes .............................16
2.9.9. Loss Measurement Scope .............................18
2.9.10. Delay Measurement Accuracy ........................18
2.9.11. Delay Measurement Timestamp Format ................18
3. Message Formats ................................................19
3.1. Loss Measurement Message Format ...........................19
3.2. Delay Measurement Message Format ..........................25
3.3. Combined Loss/Delay Measurement Message Format ............27
3.4. Timestamp Field Formats ...................................28
3.5. TLV Objects ...............................................29
3.5.1. Padding ............................................30
3.5.2. Addressing .........................................31
3.5.3. Loopback Request ...................................31
3.5.4. Session Query Interval .............................32
4. Operation ......................................................33
4.1. Operational Overview ......................................33
4.2. Loss Measurement Procedures ...............................34
4.2.1. Initiating a Loss Measurement Operation ............34
4.2.2. Transmitting a Loss Measurement Query ..............34
4.2.3. Receiving a Loss Measurement Query .................35
4.2.4. Transmitting a Loss Measurement Response ...........35
4.2.5. Receiving a Loss Measurement Response ..............36
4.2.6. Loss Calculation ...................................36
4.2.7. Quality of Service .................................37
4.2.8. G-ACh Packets ......................................37
1. Introduction ....................................................3
1.1. Applicability and Scope ....................................5
1.2. Terminology ................................................6
1.3. Requirements Language ......................................6
2. Overview ........................................................6
2.1. Basic Bidirectional Measurement ............................6
2.2. Packet Loss Measurement ....................................7
2.3. Throughput Measurement ....................................10
2.4. Delay Measurement .........................................10
2.5. Delay Variation Measurement ...............................12
2.6. Unidirectional Measurement ................................12
2.7. Dyadic Measurement ........................................13
2.8. Loopback Measurement ......................................13
2.9. Measurement Considerations ................................14
2.9.1. Types of Channels ..................................14
2.9.2. Quality of Service .................................14
2.9.3. Measurement Point Location .........................14
2.9.4. Equal Cost Multipath ...............................15
2.9.5. Intermediate Nodes .................................15
2.9.6. Different Transmit and Receive Interfaces ..........16
2.9.7. External Post-Processing ...........................16
2.9.8. Loss Measurement Modes .............................16
2.9.9. Loss Measurement Scope .............................18
2.9.10. Delay Measurement Accuracy ........................18
2.9.11. Delay Measurement Timestamp Format ................18
3. Message Formats ................................................19
3.1. Loss Measurement Message Format ...........................19
3.2. Delay Measurement Message Format ..........................25
3.3. Combined Loss/Delay Measurement Message Format ............27
3.4. Timestamp Field Formats ...................................28
3.5. TLV Objects ...............................................29
3.5.1. Padding ............................................30
3.5.2. Addressing .........................................31
3.5.3. Loopback Request ...................................31
3.5.4. Session Query Interval .............................32
4. Operation ......................................................33
4.1. Operational Overview ......................................33
4.2. Loss Measurement Procedures ...............................34
4.2.1. Initiating a Loss Measurement Operation ............34
4.2.2. Transmitting a Loss Measurement Query ..............34
4.2.3. Receiving a Loss Measurement Query .................35
4.2.4. Transmitting a Loss Measurement Response ...........35
4.2.5. Receiving a Loss Measurement Response ..............36
4.2.6. Loss Calculation ...................................36
4.2.7. Quality of Service .................................37
4.2.8. G-ACh Packets ......................................37
4.2.9. Test Messages ......................................37
4.2.10. Message Loss and Packet Misorder Conditions .......38
4.3. Delay Measurement Procedures ..............................39
4.3.1. Transmitting a Delay Measurement Query .............39
4.3.2. Receiving a Delay Measurement Query ................39
4.3.3. Transmitting a Delay Measurement Response ..........40
4.3.4. Receiving a Delay Measurement Response .............41
4.3.5. Timestamp Format Negotiation .......................41
4.3.5.1. Single-Format Procedures ..................42
4.3.6. Quality of Service .................................42
4.4. Combined Loss/Delay Measurement Procedures ................42
5. Implementation Disclosure Requirements .........................42
6. Congestion Considerations ......................................44
7. Manageability Considerations ...................................44
8. Security Considerations ........................................45
9. IANA Considerations ............................................46
9.1. Allocation of PW Associated Channel Types .................47
9.2. Creation of Measurement Timestamp Type Registry ...........47
9.3. Creation of MPLS Loss/Delay Measurement Control
Code Registry .............................................47
9.4. Creation of MPLS Loss/Delay Measurement TLV Object
Registry ..................................................49
10. Acknowledgments ...............................................49
11. References ....................................................49
11.1. Normative References .....................................49
11.2. Informative References ...................................50
Appendix A. Default Timestamp Format Rationale ....................52
4.2.9. Test Messages ......................................37
4.2.10. Message Loss and Packet Misorder Conditions .......38
4.3. Delay Measurement Procedures ..............................39
4.3.1. Transmitting a Delay Measurement Query .............39
4.3.2. Receiving a Delay Measurement Query ................39
4.3.3. Transmitting a Delay Measurement Response ..........40
4.3.4. Receiving a Delay Measurement Response .............41
4.3.5. Timestamp Format Negotiation .......................41
4.3.5.1. Single-Format Procedures ..................42
4.3.6. Quality of Service .................................42
4.4. Combined Loss/Delay Measurement Procedures ................42
5. Implementation Disclosure Requirements .........................42
6. Congestion Considerations ......................................44
7. Manageability Considerations ...................................44
8. Security Considerations ........................................45
9. IANA Considerations ............................................46
9.1. Allocation of PW Associated Channel Types .................47
9.2. Creation of Measurement Timestamp Type Registry ...........47
9.3. Creation of MPLS Loss/Delay Measurement Control
Code Registry .............................................47
9.4. Creation of MPLS Loss/Delay Measurement TLV Object
Registry ..................................................49
10. Acknowledgments ...............................................49
11. References ....................................................49
11.1. Normative References .....................................49
11.2. Informative References ...................................50
Appendix A. Default Timestamp Format Rationale ....................52
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks.
许多服务提供商服务水平协议（SLA）依赖于测量和监控数据包丢失、单向和双向延迟的性能指标以及相关指标（如延迟变化和信道吞吐量）的能力。这种测量能力还为运营商提供了对其网络性能特征的更大可视性，从而有助于规划、故障排除和网络性能评估。本文件规定了协议机制，以便能够在MPLS网络中高效、准确地测量这些性能指标。
This document specifies two closely related protocols, one for packet loss measurement (LM) and one for packet delay measurement (DM). These protocols have the following characteristics and capabilities:
本文件规定了两个密切相关的协议，一个用于包丢失测量（LM），另一个用于包延迟测量（DM）。这些协议具有以下特征和功能：
o The LM and DM protocols are intended to be simple and to support efficient hardware processing.
o LM和DM协议旨在简单且支持高效的硬件处理。
o The LM and DM protocols operate over the MPLS Generic Associated Channel (G-ACh) [RFC5586] and support measurement of loss, delay, and related metrics over Label Switched Paths (LSPs), pseudowires, and MPLS sections (links).
o LM和DM协议在MPLS通用相关信道（G-ACh）[RFC5586]上运行，并支持在标签交换路径（LSP）、伪线和MPLS部分（链路）上测量丢失、延迟和相关度量。
o The LM and DM protocols are applicable to the LSPs, pseudowires, and sections of networks based on the MPLS Transport Profile (MPLS-TP), because the MPLS-TP is based on a standard MPLS data plane. The MPLS-TP is defined and described in [RFC5921], and MPLS-TP LSPs, pseudowires, and sections are discussed in detail in [RFC5960]. A profile describing the minimal functional subset of the LM and DM protocols in the MPLS-TP context is provided in [RFC6375].
o LM和DM协议适用于基于MPLS传输配置文件（MPLS-TP）的LSP、伪线和网络部分，因为MPLS-TP基于标准MPLS数据平面。MPLS-TP在[RFC5921]中定义和描述，MPLS-TP LSP、伪线和部分在[RFC5960]中详细讨论。[RFC6375]中提供了描述MPLS-TP上下文中LM和DM协议最小功能子集的配置文件。
o The LM and DM protocols can be used both for continuous/proactive and selective/on-demand measurement.
o LM和DM协议可用于连续/主动和选择性/按需测量。
o The LM and DM protocols use a simple query/response model for bidirectional measurement that allows a single node -- the querier -- to measure the loss or delay in both directions.
o LM和DM协议使用一个简单的查询/响应模型进行双向测量，该模型允许单个节点（查询者）测量两个方向上的损失或延迟。
o The LM and DM protocols use query messages for unidirectional loss and delay measurement. The measurement can be carried out either at the downstream node(s) or at the querier if an out-of-band return path is available.
o LM和DM协议使用查询消息进行单向损耗和延迟测量。如果带外返回路径可用，则可在下游节点或查询器处进行测量。
o The LM and DM protocols do not require that the transmit and receive interfaces be the same when performing bidirectional measurement.
o 在执行双向测量时，LM和DM协议不要求发送和接收接口相同。
o The DM protocol is stateless.
o DM协议是无状态的。
o The LM protocol is "almost" stateless: loss is computed as a delta between successive messages, and thus the data associated with the last message received must be retained.
o LM协议是“几乎”无状态的：丢失被计算为连续消息之间的增量，因此必须保留与最后接收的消息相关联的数据。
o The LM protocol can perform two distinct kinds of loss measurement: it can measure the loss of specially generated test messages in order to infer the approximate data-plane loss level (inferred measurement) or it can directly measure data-plane packet loss (direct measurement). Direct measurement provides perfect loss accounting, but may require specialized hardware support and is only applicable to some LSP types. Inferred measurement provides only approximate loss accounting but is generally applicable.
o LM协议可以执行两种不同类型的丢失测量：它可以测量专门生成的测试消息的丢失，以推断近似的数据平面丢失级别（推断测量），或者它可以直接测量数据平面数据包丢失（直接测量）。直接测量提供了完美的损耗核算，但可能需要专门的硬件支持，并且仅适用于某些LSP类型。推断计量仅提供近似的损失核算，但通常适用。
The direct LM method is also known as "frame-based" in the context of Ethernet transport networks [Y.1731]. Inferred LM is a generalization of the "synthetic" measurement approach currently in development for Ethernet networks, in the sense that it allows test messages to be decoupled from measurement messages.
直接LM方法在以太网传输网络中也称为“基于帧的”[Y.1731]。推断LM是目前正在为以太网网络开发的“综合”测量方法的推广，从某种意义上说，它允许将测试消息与测量消息解耦。
o The LM protocol supports measurement in terms of both packet counts and octet counts.
o LM协议支持数据包计数和八位字节计数的测量。
o The LM protocol supports both 32-bit and 64-bit counters.
o LM协议支持32位和64位计数器。
o The LM protocol can be used to measure channel throughput as well as packet loss.
o LM协议可用于测量信道吞吐量和数据包丢失。
o The DM protocol supports multiple timestamp formats, and provides a simple means for the two endpoints of a bidirectional connection to agree on a preferred format. This procedure reduces to a triviality for implementations supporting only a single timestamp format.
o DM协议支持多种时间戳格式，并为双向连接的两个端点提供了一种简单的方法来商定首选格式。对于仅支持单一时间戳格式的实现，此过程简化为一个小问题。
o The DM protocol supports varying the measurement message size in order to measure delays associated with different packet sizes.
o DM协议支持改变测量消息大小，以便测量与不同分组大小相关联的延迟。
The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way Active Measurement Protocol (TWAMP) [RFC5357] provide capabilities for the measurement of various performance metrics in IP networks. These protocols are not streamlined for hardware processing and rely on IP and TCP, as well as elements of the Network Time Protocol (NTP), which may not be available or optimized in some network environments; they also lack support for IEEE 1588 timestamps and direct-mode LM, which may be required in some environments. The protocols defined in this document thus are similar in some respects to, but also differ from, these IP-based protocols.
单向主动测量协议（OWAMP）[RFC4656]和双向主动测量协议（TWAMP）[RFC5357]提供了测量IP网络中各种性能指标的能力。这些协议没有针对硬件处理进行优化，并且依赖于IP和TCP，以及网络时间协议（NTP）的元素，在某些网络环境中可能无法使用或优化这些元素；它们还缺乏对IEEE 1588时间戳和直接模式LM的支持，这在某些环境中可能是必需的。因此，本文件中定义的协议在某些方面与这些基于IP的协议相似，但也有所不同。
This document specifies measurement procedures and protocol messages that are intended to be applicable in a wide variety of circumstances and amenable to implementation by a wide range of hardware- and software-based measurement systems. As such, it does not attempt to mandate measurement quality levels or analyze specific end-user applications.
本文件规定了适用于各种环境的测量程序和协议消息，并适用于各种基于硬件和软件的测量系统。因此，它不会试图强制要求测量质量级别或分析特定的最终用户应用程序。
Term Definition
----- -------------------------------------------
ACH Associated Channel Header
DM Delay Measurement
ECMP Equal Cost Multipath
G-ACh Generic Associated Channel
LM Loss Measurement
LSE Label Stack Entry
LSP Label Switched Path
NTP Network Time Protocol
OAM Operations, Administration, and Maintenance
PTP Precision Time Protocol
TC Traffic Class
Term Definition
----- -------------------------------------------
ACH Associated Channel Header
DM Delay Measurement
ECMP Equal Cost Multipath
G-ACh Generic Associated Channel
LM Loss Measurement
LSE Label Stack Entry
LSP Label Switched Path
NTP Network Time Protocol
OAM Operations, Administration, and Maintenance
PTP Precision Time Protocol
TC Traffic Class
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section begins with a summary of the basic methods used for the bidirectional measurement of packet loss and delay. These measurement methods are then described in detail. Finally, a list of practical considerations is discussed that may come into play to inform or modify these simple procedures. This section is limited to theoretical discussion; for protocol specifics, the reader is referred to Sections 3 and 4.
本节首先概述用于双向测量数据包丢失和延迟的基本方法。然后详细描述这些测量方法。最后，讨论了可能对这些简单程序起作用的实际考虑事项列表。本节仅限于理论探讨；关于协议细节，读者可参考第3节和第4节。
The following figure shows the reference scenario.
下图显示了参考场景。
T1 T2
+-------+/ Query \+-------+
| | - - - - - - - - ->| |
| A |===================| B |
| |<- - - - - - - - - | |
+-------+\ Response /+-------+
T4 T3
T1 T2
+-------+/ Query \+-------+
| | - - - - - - - - ->| |
| A |===================| B |
| |<- - - - - - - - - | |
+-------+\ Response /+-------+
T4 T3
This figure shows a bidirectional channel between two nodes, A and B, and illustrates the temporal reference points T1-T4 associated with a measurement operation that takes place at A. The operation consists of A sending a query message to B, and B sending back a response.
该图显示了两个节点a和B之间的双向信道，并说明了与在a处发生的测量操作相关联的时间参考点T1-T4。该操作包括a向B发送查询消息，B发送回响应。
Each reference point indicates the point in time at which either the query or the response message is transmitted or received over the channel.
每个参考点指示通过信道传输或接收查询或响应消息的时间点。
In this situation, A can arrange to measure the packet loss over the channel in the forward and reverse directions by sending Loss Measurement (LM) query messages to B, each of which contains the count of packets transmitted prior to time T1 over the channel to B (A_TxP). When the message reaches B, it appends two values and reflects the message back to A: the count of packets received prior to time T2 over the channel from A (B_RxP) and the count of packets transmitted prior to time T3 over the channel to A (B_TxP). When the response reaches A, it appends a fourth value: the count of packets received prior to time T4 over the channel from B (A_RxP).
在这种情况下，A可以通过向B发送丢失测量（LM）查询消息来安排在正向和反向方向上测量信道上的分组丢失，其中每个消息包含在时间T1之前通过信道向B发送的分组的计数（A_TxP）。当消息到达B时，它附加两个值并将消息反射回A：在时间T2之前通过信道从A（B_RxP）接收的数据包计数和在时间T3之前通过信道传输到A（B_TxP）的数据包计数。当响应到达A时，它附加第四个值：在时间T4之前通过信道从B（A_RxP）接收的数据包的计数。
These four counter values enable A to compute the desired loss statistics. Because the transmit count at A and the receive count at B (and vice versa) may not be synchronized at the time of the first message, and to limit the effects of counter wrap, the loss is computed in the form of a delta between messages.
这四个计数器值使A能够计算所需的损失统计信息。由于A处的发送计数和B处的接收计数（反之亦然）可能在第一条消息时不同步，并且为了限制反包裹的影响，以消息之间的增量的形式计算损失。
To measure at A the delay over the channel to B, a Delay Measurement (DM) query message is sent from A to B containing a timestamp recording the instant at which it is transmitted, i.e., T1. When the message reaches B, a timestamp is added recording the instant at which it is received (T2). The message can now be reflected from B to A, with B adding its transmit timestamp (T3) and A adding its receive timestamp (T4). These four timestamps enable A to compute the one-way delay in each direction, as well as the two-way delay for the channel. The one-way delay computations require that the clocks of A and B be synchronized; mechanisms for clock synchronization are outside the scope of this document.
为了在A处测量到B的信道上的延迟，从A到B发送延迟测量（DM）查询消息，该消息包含记录其传输的时刻（即T1）的时间戳。当消息到达B时，添加时间戳，记录接收消息的时刻（T2）。消息现在可以从B反射到A，B添加其发送时间戳（T3），A添加其接收时间戳（T4）。这四个时间戳使A能够计算每个方向上的单向延迟以及信道的双向延迟。单向延迟计算要求A和B的时钟同步；时钟同步机制不在本文档范围内。
Suppose a bidirectional channel exists between the nodes A and B. The objective is to measure at A the following two quantities associated with the channel:
假设节点a和B之间存在双向信道。目标是在a处测量与信道相关的以下两个量：
A_TxLoss (transmit loss): the number of packets transmitted by A over the channel but not received at B;
A_TxLoss（传输损耗）：A通过信道传输但在B未接收到的数据包数；
A_RxLoss (receive loss): the number of packets transmitted by B over the channel but not received at A.
A_RxLoss（接收丢失）：B通过通道传输但在A处未接收到的数据包数。
This is accomplished by initiating a Loss Measurement (LM) operation at A, which consists of transmission of a sequence of LM query messages (LM[1], LM[2], ...) over the channel at a specified rate, such as one every 100 milliseconds. Each message LM[n] contains the following value:
这是通过在a处启动损耗测量（LM）操作来实现的，该操作包括以指定速率（例如每100毫秒一次）在通道上传输一系列LM查询消息（LM[1]、LM[2]、…）。每条消息LM[n]包含以下值：
A_TxP[n]: the total count of packets transmitted by A over the channel prior to the time this message is transmitted.
A_TxP[n]：在发送此消息之前，通过信道发送的数据包总数。
When such a message is received at B, the following value is recorded in the message:
当在B接收到此类消息时，消息中记录以下值：
B_RxP[n]: the total count of packets received by B over the channel at the time this message is received (excluding the message itself).
B_RxP[n]：接收此消息时B通过通道接收的数据包总数（不包括消息本身）。
At this point, B transmits the message back to A, recording within it the following value:
此时，B将消息发送回A，并在其中记录以下值：
B_TxP[n]: the total count of packets transmitted by B over the channel prior to the time this response is transmitted.
B_TxP[n]：在发送此响应之前，B通过信道发送的数据包总数。
When the message response is received back at A, the following value is recorded in the message:
在A接收回消息响应时，消息中记录以下值：
A_RxP[n]: the total count of packets received by A over the channel at the time this response is received (excluding the message itself).
A_RxP[n]：在接收到此响应时，通过通道接收的数据包总数（不包括消息本身）。
The transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n] within the measurement interval marked by the messages LM[n-1] and LM[n] are computed by A as follows:
消息LM[n-1]和LM[n]标记的测量间隔内的发射损耗A_TxLoss[n-1，n]和接收损耗A_RxLoss[n-1，n]由A计算，如下所示：
A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
where the arithmetic is modulo the counter size.
其中，算术运算是对计数器大小的模运算。
(Strictly speaking, it is not necessary that the fourth count, A_RxP[n], actually be written in the message, but this is convenient for some implementations and useful if the message is to be forwarded on to an external measurement system.)
（严格地说，没有必要在消息中实际写入第四个计数A_RxP[n]，但这对于某些实现是方便的，并且在将消息转发到外部测量系统时是有用的。）
The derived values
导出的值
A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ...
A_TxLoss=A_TxLoss[1,2]+A_TxLoss[2,3]+。。。
A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ...
A_RxLoss=A_RxLoss[1,2]+A_RxLoss[2,3]+。。。
are updated each time a response to an LM message is received and processed, and they represent the total transmit and receive loss over the channel since the LM operation was initiated.
每次接收和处理对LM消息的响应时更新，它们表示自LM操作启动以来信道上的总发送和接收损耗。
When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n], the possibility of counter wrap must be taken into account. For example, consider the values of the A_TxP counter at sequence numbers n-1 and n. Clearly if A_TxP[n] is allowed to wrap to 0 and then beyond to a value equal to or greater than A_TxP[n-1], the computation of an unambiguous A_TxLoss[n-1,n] value will be impossible. Therefore, the LM message rate MUST be sufficiently high, given the counter size and the speed and minimum packet size of the underlying channel, that this condition cannot arise. For example, a 32-bit counter for a 100-Gbps link with a minimum packet size of 64 bytes can wrap in 2^32 / (10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on the LM message interval under such conditions. This bound will be referred to as the MaxLMInterval of the channel. It is clear that the MaxLMInterval will be a more restrictive constraint in the case of direct LM and for smaller counter sizes.
在计算A_TxLoss[n-1，n]和A_RxLoss[n-1，n]的值时，必须考虑反向缠绕的可能性。例如，考虑序列号N-1和N的AY-TXP计数器的值。显然，如果允许一个_TxP[n]包装为0，然后超过等于或大于一个_TxP[n-1]的值，则不可能计算明确的A_TxLoss[n-1，n]值。因此，在给定计数器大小、底层信道的速度和最小数据包大小的情况下，LM消息速率必须足够高，这样就不会出现这种情况。例如，最小数据包大小为64字节的100 Gbps链路的32位计数器可以在2^32/（10^11/（64*8））=~22秒内结束，因此在这种情况下，这是LM消息间隔的上限。该界限将被称为信道的MaxLMInterval。很明显，对于直接LM和较小的计数器大小，MaxLMInterval将是一个更具限制性的约束。
The loss measurement approach described in this section has the characteristic of being stateless at B and "almost" stateless at A. Specifically, A must retain the data associated with the last LM response received, in order to use it to compute loss when the next response arrives. This data MAY be discarded, and MUST NOT be used as a basis for measurement, if MaxLMInterval elapses before the next response arrives, because in this case an unambiguous measurement cannot be made.
本节中描述的损耗测量方法具有B无状态和A“几乎”无状态的特点。具体而言，A必须保留与接收到的上一个LM响应相关的数据，以便在下一个响应到达时使用该数据计算损耗。如果MaxLMInterval在下一个响应到达之前经过，则该数据可能会被丢弃，并且不得用作测量的基础，因为在这种情况下，无法进行明确的测量。
The foregoing discussion has assumed the counted objects are packets, but this need not be the case. In particular, octets may be counted instead. This will, of course, reduce the MaxLMInterval accordingly.
前面的讨论假设计数的对象是分组，但不一定是这样。特别是，八位字节可以计算。当然，这将相应地减少MaxLMInterval。
In addition to absolute aggregate loss counts, the individual loss counts yield other metrics, such as the average loss rate over any multiple of the measurement interval. An accurate loss rate can be determined over time even in the presence of anomalies affecting individual measurements, such as those due to packet misordering (Section 4.2.10).
除了绝对总损失计数外，单个损失计数还产生其他指标，例如测量间隔任意倍数的平均损失率。即使在存在影响单个测量的异常情况下，也可以随时间确定准确的丢失率，例如由于数据包错序引起的异常情况（第4.2.10节）。
Note that an approach for conducting packet loss measurement in IP networks is documented in [RFC2680]. This approach differs from the one described here, for example by requiring clock synchronization between the measurement points and lacking support for direct-mode LM.
注意，[RFC2680]中记录了在IP网络中进行分组丢失测量的方法。该方法不同于此处描述的方法，例如，需要测量点之间的时钟同步，并且缺少对直接模式LM的支持。
If LM query messages contain a timestamp recording their time of transmission, this data can be combined with the packet or octet counts to yield measurements of the throughput offered and delivered over the channel during the interval in terms of the counted units.
如果LM查询消息包含记录其传输时间的时间戳，则该数据可与分组或八位字节计数相结合，以根据计数的单位对间隔期间通过信道提供和交付的吞吐量进行测量。
For a bidirectional channel, for example, given any two LM response messages (separated in time by not more than the MaxLMInterval), the difference between the counter values tells the querier the number of units successfully transmitted and received in the interval between the timestamps. Absolute offered throughput is the number of data units transmitted and absolute delivered throughput is the number of data units received. Throughput rate is the number of data units sent or received per unit time.
例如，对于双向信道，给定任意两条LM响应消息（时间间隔不超过MaxLMInterval），计数器值之间的差值告诉查询者在时间戳之间的间隔内成功发送和接收的单元数。绝对提供吞吐量是传输的数据单元数，绝对交付吞吐量是接收的数据单元数。吞吐量是每单位时间发送或接收的数据单元数。
Just as for loss measurement, the interval counts can be accumulated to arrive at the absolute throughput of the channel since the start of the measurement operation or be used to derive related metrics such as the throughput rate. This procedure also enables out-of-service throughput testing when combined with a simple packet generator.
与损耗测量一样，可以累积间隔计数以获得自测量操作开始以来的信道的绝对吞吐量，或者用于导出相关度量，例如吞吐量。当与简单的数据包生成器结合使用时，此过程还支持服务外吞吐量测试。
Suppose a bidirectional channel exists between the nodes A and B. The objective is to measure at A one or more of the following quantities associated with the channel:
假设节点a和B之间存在双向信道。目标是在a处测量与信道相关的以下一个或多个量：
o The one-way delay associated with the forward (A to B) direction of the channel;
o 与信道的前向（A到B）方向相关联的单向延迟；
o The one-way delay associated with the reverse (B to A) direction of the channel;
o 与信道的反向（B到A）方向相关联的单向延迟；
o The two-way delay (A to B to A) associated with the channel.
o 与信道相关联的双向延迟（A到B到A）。
The one-way delay metric for packet networks is described in [RFC2679]. In the case of two-way delay, there are actually two possible metrics of interest. The "two-way channel delay" is the sum of the one-way delays in each direction and reflects the delay of the channel itself, irrespective of processing delays within the remote
[RFC2679]中描述了分组网络的单向延迟度量。在双向延迟的情况下，实际上有两个可能的度量。“双向通道延迟”是每个方向上单向延迟的总和，反映了通道本身的延迟，而与远程系统内的处理延迟无关
endpoint B. The "round-trip delay" is described in [RFC2681] and includes in addition any delay associated with remote endpoint processing.
端点B.“往返延迟”在[RFC2681]中描述，此外还包括与远程端点处理相关的任何延迟。
Measurement of the one-way delay quantities requires that the clocks of A and B be synchronized, whereas the two-way delay metrics can be measured directly even when this is not the case (provided A and B have stable clocks).
单向延迟量的测量要求A和B的时钟同步，而双向延迟度量可以直接测量，即使情况并非如此（前提是A和B具有稳定的时钟）。
A measurement is accomplished by sending a Delay Measurement (DM) query message over the channel to B that contains the following timestamp:
通过将延迟测量（DM）查询消息通过通道发送到包含以下时间戳的B来完成测量：
T1: the time the DM query message is transmitted from A.
T1：从A传输DM查询消息的时间。
When the message arrives at B, the following timestamp is recorded in the message:
当消息到达B时，消息中会记录以下时间戳：
T2: the time the DM query message is received at B.
T2：在B接收DM查询消息的时间。
At this point, B transmits the message back to A, recording within it the following timestamp:
此时，B将消息发送回A，并在其中记录以下时间戳：
T3: the time the DM response message is transmitted from B.
T3：从B发送DM响应消息的时间。
When the message arrives back at A, the following timestamp is recorded in the message:
当消息返回A时，将在消息中记录以下时间戳：
T4: the time the DM response message is received back at A.
T4：在A接收回DM响应消息的时间。
(Strictly speaking, it is not necessary that the fourth timestamp, T4, actually be written in the message, but this is convenient for some implementations and useful if the message is to be forwarded on to an external measurement system.)
（严格地说，第四个时间戳T4实际上不必写入消息中，但这对于某些实现是方便的，并且在将消息转发到外部测量系统时是有用的。）
At this point, A can compute the two-way channel delay associated with the channel as
此时，A可以计算与信道相关联的双向信道延迟，如下所示：
two-way channel delay = (T4 - T1) - (T3 - T2)
two-way channel delay = (T4 - T1) - (T3 - T2)
and the round-trip delay as
往返延误为
round-trip delay = T4 - T1.
往返延迟=T4-T1。
If the clocks of A and B are known at A to be synchronized, then both one-way delay values, as well as the two-way channel delay, can be computed at A as
如果A和B的时钟在A处已知要同步，则可以在A处计算单向延迟值以及双向信道延迟
forward one-way delay = T2 - T1
正向单向延迟=T2-T1
reverse one-way delay = T4 - T3
反向单向延迟=T4-T3
two-way channel delay = forward delay + reverse delay.
双向通道延迟=正向延迟+反向延迟。
Note that this formula for the two-way channel delay reduces to the one previously given, and clock synchronization is not required to compute this metric.
请注意，双向信道延迟的此公式减少到先前给定的公式，并且不需要时钟同步来计算此度量。
Inter-Packet Delay Variation (IPDV) and Packet Delay Variation (PDV) [RFC5481] are performance metrics derived from one-way delay measurement and are important in some applications. IPDV represents the difference between the one-way delays of successive packets in a stream. PDV, given a measurement test interval, represents the difference between the one-way delay of a packet in the interval and that of the packet in the interval with the minimum delay.
包间延迟变化（IPDV）和包延迟变化（PDV）[RFC5481]是从单向延迟测量中得出的性能指标，在某些应用中非常重要。IPDV表示流中连续数据包的单向延迟之间的差异。给定测量测试间隔的PDV表示间隔内数据包的单向延迟与具有最小延迟的间隔内数据包的单向延迟之间的差异。
IPDV and PDV measurements can therefore be derived from delay measurements obtained through the procedures in Section 2.4. An important point regarding delay variation measurement, however, is that it can be carried out based on one-way delay measurements even when the clocks of the two systems involved in those measurements are not synchronized with one another.
因此，IPDV和PDV测量值可以从通过第2.4节中的程序获得的延迟测量值中得出。然而，关于延迟变化测量的一个重要点是，即使在涉及这些测量的两个系统的时钟彼此不同步的情况下，也可以基于单向延迟测量来执行延迟变化测量。
In the case that the channel from A to (B1, ..., Bk) (where B2, ..., Bk refers to the point-to-multipoint case) is unidirectional, i.e., is a unidirectional LSP, LM and DM measurements can be carried out at B1, ..., Bk instead of at A.
在从A到（B1，…，Bk）（其中B2，…，Bk指点对多点情况）的信道是单向的情况下，即是单向LSP，可以在B1，…，Bk处而不是在A处进行LM和DM测量。
For LM, this is accomplished by initiating an LM operation at A and carrying out the same procedures as used for bidirectional channels, except that no responses from B1, ..., Bk to A are generated. Instead, each terminal node B uses the A_TxP and B_RxP values in the LM messages it receives to compute the receive loss associated with the channel in essentially the same way as described previously, that is:
对于LM，这是通过在A处启动LM操作并执行与双向信道相同的程序来实现的，但B1、…、Bk对A没有响应。相反，每个终端节点B使用其接收的LM消息中的A_TxP和B_RxP值，以基本上与前面描述的相同的方式计算与信道相关联的接收损耗，即：
B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
For DM, of course, only the forward one-way delay can be measured and the clock synchronization requirement applies.
当然，对于DM，只能测量前向单向延迟，并且时钟同步要求适用。
Alternatively, if an out-of-band channel from a terminal node B back to A is available, the LM and DM message responses can be communicated to A via this channel so that the measurements can be carried out at A.
或者，如果从终端节点B返回a的带外信道可用，则可以通过该信道将LM和DM消息响应传送给a，以便可以在a处执行测量。
The basic procedures for bidirectional measurement assume that the measurement process is conducted by and for the querier node A. Instead, it is possible, with only minor variation of these procedures, to conduct a dyadic or "dual-ended" measurement process in which both nodes A and B perform loss or delay measurement based on the same message flow. This is achieved by stipulating that A copy the third and fourth counter or timestamp values from a response message into the third and fourth slots of the next query, which are otherwise unused, thereby providing B with equivalent information to that learned by A.
双向测量的基本过程假设测量过程由查询节点A进行，并且针对查询节点A进行。相反，在这些过程只有微小变化的情况下，可以进行二进或“双端”测量测量过程，其中节点A和B根据相同的消息流执行丢失或延迟测量。这是通过规定A将响应消息中的第三个和第四个计数器或时间戳值复制到下一个查询的第三个和第四个插槽中来实现的，这两个插槽在其他情况下是未使用的，从而为B提供与A学习到的信息相同的信息。
The dyadic procedure has the advantage of halving the number of messages required for both A and B to perform a given kind of measurement, but comes at the expense of each node's ability to control its own measurement process independently, and introduces additional operational complexity into the measurement protocols. The quantity of measurement traffic is also expected to be low relative to that of user traffic, particularly when 64-bit counters are used for LM. Consequently, this document does not specify a dyadic operational mode. However, it is still possible, and may be useful, for A to perform the extra copy, thereby providing additional information to B even when its participation in the measurement process is passive.
二元过程的优点是将A和B执行给定类型的测量所需的消息数量减半，但以牺牲每个节点独立控制其自身测量过程的能力为代价，并在测量协议中引入额外的操作复杂性。与用户通信量相比，测量通信量预计也较低，特别是当64位计数器用于LM时。因此，本文件未规定二元操作模式。然而，A仍然可以并且可能有用地执行额外的拷贝，从而向B提供额外的信息，即使其在测量过程中的参与是被动的。
Some bidirectional channels may be placed into a loopback state such that messages are looped back to the sender without modification. In this situation, LM and DM procedures can be used to carry out measurements associated with the circular path. This is done by generating "queries" with the Response flag set to 1.
一些双向信道可被置于环回状态，使得消息在不修改的情况下被环回到发送方。在这种情况下，可以使用LM和DM程序进行与圆形路径相关的测量。这是通过生成响应标志设置为1的“查询”来完成的。
For LM, the loss computation in this case is:
对于LM，这种情况下的损失计算为：
A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
For DM, the round-trip delay is computed. In this case, however, the remote endpoint processing time component reflects only the time required to loop the message from channel input to channel output.
对于DM，计算往返延迟。但是，在这种情况下，远程端点处理时间组件仅反映将消息从通道输入循环到通道输出所需的时间。
A number of additional considerations apply in practice to the measurement methods summarized above.
在实践中，上述测量方法还需要考虑一些其他因素。
There are several types of channels in MPLS networks over which loss and delay measurement may be conducted. The channel type may restrict the kinds of measurement that can be performed. In all cases, LM and DM messages flow over the MPLS Generic Associated Channel (G-ACh), which is described in detail in [RFC5586].
MPLS网络中有几种类型的信道，可以在这些信道上进行损耗和延迟测量。通道类型可能会限制可执行的测量类型。在所有情况下，LM和DM消息在MPLS通用关联信道（G-ACh）上流动，这在[RFC5586]中有详细描述。
Broadly, a channel in an MPLS network may be either a link, a Label Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985]. Links are bidirectional and are also referred to as MPLS sections; see [RFC5586] and [RFC5960]. Pseudowires are bidirectional. Label Switched Paths may be either unidirectional or bidirectional.
一般来说，MPLS网络中的信道可以是链路、标签交换路径（LSP）[RFC3031]或伪线[RFC3985]。链路是双向的，也被称为MPLS部分；参见[RFC5586]和[RFC5960]。伪线是双向的。标签交换路径可以是单向的，也可以是双向的。
The LM and DM protocols discussed in this document are initiated from a single node: the querier. A query message may be received either by a single node or by multiple nodes, depending on the nature of the channel. In the latter case, these protocols provide point-to-multipoint measurement capabilities.
本文档中讨论的LM和DM协议是从一个节点发起的：查询器。根据信道的性质，查询消息可以由单个节点接收，也可以由多个节点接收。在后一种情况下，这些协议提供点对多点测量能力。
Quality of Service (QoS) capabilities, in the form of the Differentiated Services architecture, apply to MPLS as specified in [RFC3270] and [RFC5462]. Different classes of traffic are distinguished by the three-bit Traffic Class (TC) field of an MPLS Label Stack Entry (LSE). Delay measurement applies on a per-traffic-class basis, and the TC values of LSEs above the G-ACh Label (GAL) that precedes a DM message are significant. Packet loss can be measured with respect either to the channel as a whole or to a specific traffic class.
按照[RFC3270]和[RFC5462]中的规定，服务质量（QoS）能力以区分服务体系结构的形式应用于MPLS。通过MPLS标签堆栈项（LSE）的三位流量类别（TC）字段区分不同的流量类别。延迟测量适用于每个通信量类别，并且DM消息之前G-ACh标签（GAL）上方LSE的TC值非常重要。可以根据整个信道或特定的业务类别来测量分组丢失。
The location of the measurement points for loss and delay within the sending and receiving nodes is implementation dependent but directly affects the nature of the measurements. For example, a sending implementation may or may not consider a packet to be "lost", for LM purposes, that was discarded prior to transmission for queuing-
发送和接收节点内的丢失和延迟测量点的位置取决于实现，但直接影响测量的性质。例如，发送实现可以考虑或不考虑数据包“丢失”，对于LM目的，在传输队列之前被丢弃。
related reasons; conversely, a receiving implementation may or may not consider a packet to be "lost", for LM purposes, if it was physically received but discarded during receive-path processing. The location of delay measurement points similarly determines what, precisely, is being measured. The principal consideration here is that the behavior of an implementation in these respects MUST be made clear to the user.
相关原因；相反，接收实现可能或可能不考虑数据包“丢失”，对于LM目的，如果物理接收，但在接收路径处理期间丢弃。延迟测量点的位置同样决定了测量的精确程度。这里主要考虑的是，必须向用户说明实现在这些方面的行为。
Equal Cost Multipath (ECMP) is the behavior of distributing packets across multiple alternate paths toward a destination. The use of ECMP in MPLS networks is described in BCP 128 [RFC4928]. The typical result of ECMP being performed on an LSP that is subject to delay measurement will be that only the delay of one of the available paths is, and can be, measured.
等成本多路径（ECMP）是指通过多条备用路径向目的地分发数据包的行为。BCP 128[RFC4928]中描述了在MPLS网络中使用ECMP。在要进行延迟测量的LSP上执行ECMP的典型结果是，只有一条可用路径的延迟是可以测量的。
The effects of ECMP on loss measurement will depend on the LM mode. In the case of direct LM, the measurement will account for any packets lost between the sender and the receiver, regardless of how many paths exist between them. However, the presence of ECMP increases the likelihood of misordering both of LM messages relative to data packets and of the LM messages themselves. Such misorderings tend to create unmeasurable intervals and thus degrade the accuracy of loss measurement. The effects of ECMP are similar for inferred LM, with the additional caveat that, unless the test packets are specially constructed so as to probe all available paths, the loss characteristics of one or more of the alternate paths cannot be accounted for.
ECMP对损耗测量的影响将取决于LM模式。在直接LM的情况下，测量将考虑发送方和接收方之间丢失的任何数据包，而不管它们之间存在多少条路径。然而，ECMP的存在增加了LM消息相对于数据分组和LM消息本身的错误排序的可能性。这种错误排序往往会造成无法测量的间隔，从而降低损耗测量的准确性。ECMP对推断的LM的影响类似，但另外需要注意的是，除非测试数据包经过特殊构造以探测所有可用路径，否则无法解释一条或多条备用路径的丢失特性。
In the case of an LSP, it may be desirable to measure the loss or delay to or from an intermediate node as well as between LSP endpoints. This can be done in principle by setting the Time to Live (TTL) field in the outer LSE appropriately when targeting a measurement message to an intermediate node. This procedure may fail, however, if hardware-assisted measurement is in use, because the processing of the packet by the intermediate node occurs only as the result of TTL expiry, and the handling of TTL expiry may occur at a later processing stage in the implementation than the hardware-assisted measurement function. The motivation for conducting measurements to intermediate nodes is often an attempt to localize a problem that has been detected on the LSP. In this case, if intermediate nodes are not capable of performing hardware-assisted measurement, a less accurate -- but usually sufficient -- software-based measurement can be conducted instead.
在LSP的情况下，可能希望测量到中间节点或从中间节点以及LSP端点之间的丢失或延迟。原则上，当将测量消息定向到中间节点时，可以通过在外部LSE中适当设置生存时间（TTL）字段来实现。然而，如果使用硬件辅助测量，则该过程可能失败，因为中间节点对分组的处理仅作为TTL到期的结果发生，并且TTL到期的处理可能发生在实现中比硬件辅助测量功能更晚的处理阶段。对中间节点进行测量的动机通常是试图定位LSP上检测到的问题。在这种情况下，如果中间节点不能执行硬件辅助测量，则可以执行精度较低但通常足够的基于软件的测量。
The overview of the bidirectional measurement process presented in Section 2 is also applicable when the transmit and receive interfaces at A or B differ from one another. Some additional considerations, however, do apply in this case:
当A或B处的发射和接收接口彼此不同时，第2节中介绍的双向测量过程的概述也适用。但是，在这种情况下，还需要考虑一些其他因素：
o If different clocks are associated with transmit and receive processing, these clocks must be synchronized in order to compute the two-way delay.
o 如果不同的时钟与发送和接收处理相关，则必须同步这些时钟以计算双向延迟。
o The DM protocol specified in this document requires that the timestamp formats used by the interfaces that receive a DM query and transmit a DM response agree.
o 本文档中指定的DM协议要求接收DM查询和发送DM响应的接口使用的时间戳格式一致。
o The LM protocol specified in this document supports both 32-bit and 64-bit counter sizes, but the use of 32-bit counters at any of the up to four interfaces involved in an LM operation will result in 32-bit LM calculations for both directions of the channel.
o 本文档中指定的LM协议支持32位和64位计数器大小，但在LM操作中涉及的最多四个接口中的任何一个接口上使用32位计数器将导致对通道的两个方向进行32位LM计算。
In some circumstances, it may be desirable to carry out the final measurement computation at an external post-processing device dedicated to the purpose. This can be achieved in supporting implementations by, for example, configuring the querier, in the case of a bidirectional measurement session, to forward each response it receives to the post-processor via any convenient protocol. The unidirectional case can be handled similarly through configuration of the receiver or by including an instruction in query messages for the receiver to respond out-of-band to the appropriate return address.
在某些情况下，可能需要在专用于此目的的外部后处理设备上执行最终测量计算。这可以通过支持实现来实现，例如，在双向测量会话的情况下，通过配置查询器将其接收到的每个响应通过任何方便的协议转发给后处理器。单向情况可以通过接收器的配置或通过在查询消息中包括用于接收器响应带外到适当的返回地址的指令来类似地处理。
Post-processing devices may have the ability to store measurement data for an extended period and to generate a variety of useful statistics from them. External post-processing also allows the measurement process to be completely stateless at the querier and responder.
后处理设备可以具有在较长时间内存储测量数据并从中生成各种有用统计数据的能力。外部后处理还允许查询者和响应者的测量过程完全无状态。
The summary of loss measurement at the beginning of Section 2 made reference to the "count of packets" transmitted and received over a channel. If the counted packets are the packets flowing over the channel in the data plane, the loss measurement is said to operate in "direct mode". If, on the other hand, the counted packets are selected control packets from which the approximate loss characteristics of the channel are being inferred, the loss measurement is said to operate in "inferred mode".
第2节开头的损耗测量摘要参考了通过信道发送和接收的“数据包计数”。如果计数的数据包是在数据平面中流过信道的数据包，则损耗测量称为在“直接模式”下操作。另一方面，如果所计数的分组是从中推断信道的近似损耗特性的控制分组，则损耗测量被称为在“推断模式”下操作。
Direct LM has the advantage of being able to provide perfect loss accounting when it is available. There are, however, several constraints associated with direct LM.
Direct LM的优点是能够在可用时提供完善的损失核算。然而，有几个与直接LM相关的约束。
For accurate direct LM to occur, packets must not be sent between the time the transmit count for an outbound LM message is determined and the time the message is actually transmitted. Similarly, packets must not be received and processed between the time an LM message is received and the time the receive count for the message is determined. If these "synchronization conditions" do not hold, the LM message counters will not reflect the true state of the data plane, with the result that, for example, the receive count of B may be greater than the transmit count of A, and attempts to compute loss by taking the difference will yield an invalid result. This requirement for synchronization between LM message counters and the data plane may require special support from hardware-based forwarding implementations.
为了实现准确的直接LM，在确定出站LM消息的传输计数和消息实际传输之间不得发送数据包。同样，在接收LM消息和确定消息接收计数之间，不得接收和处理数据包。如果这些“同步条件”不成立，则LM消息计数器将不会反映数据平面的真实状态，其结果是，例如，接收计数B可能大于发送计数A，并且尝试通过取差来计算损失将产生无效结果。LM消息计数器和数据平面之间的同步要求可能需要基于硬件的转发实现的特殊支持。
A limitation of direct LM is that it may be difficult or impossible to apply in cases where the channel is an LSP and the LSP label at the receiver is either nonexistent or fails to identify a unique sending node. The first case happens when Penultimate Hop Popping (PHP) is used on the LSP, and the second case generally holds for LSPs based on the Label Distribution Protocol (LDP) [RFC5036] as opposed to, for example, those based on Traffic Engineering extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209]. These conditions may make it infeasible for the receiver to identify the data-plane packets associated with a particular source and LSP in order to count them, or to infer the source and LSP context associated with an LM message. Direct LM is also vulnerable to disruption in the event that the ingress or egress interface associated with an LSP changes during the LSP's lifetime.
直接LM的限制是，在信道是LSP并且接收机处的LSP标签不存在或无法识别唯一发送节点的情况下，可能难以或不可能应用直接LM。第一种情况发生在LSP上使用倒数第二跳弹出（PHP）时，第二种情况通常适用于基于标签分发协议（LDP）[RFC5036]的LSP，而不是例如基于资源预留协议（RSVP-TE）[RFC3209]的流量工程扩展的LSP。这些条件可能使得接收机不可能识别与特定源和LSP相关联的数据平面分组以对其进行计数，或者推断与LM消息相关联的源和LSP上下文。如果与LSP相关的入口或出口接口在LSP的生命周期内发生变化，Direct LM也容易受到中断的影响。
Inferred LM works in the same manner as direct LM except that the counted packets are special control packets, called test messages, generated by the sender. Test messages may be either packets explicitly constructed and used for LM or packets with a different primary purpose, such as those associated with a Bidirectional Forwarding Detection (BFD) [RFC5884] session.
推断的LM与直接LM的工作方式相同，只是计数的数据包是由发送方生成的特殊控制数据包，称为测试消息。测试消息可以是显式构造并用于LM的分组，也可以是具有不同主要目的的分组，例如与双向转发检测（BFD）[RFC5884]会话相关联的分组。
The synchronization conditions discussed above for direct LM also apply to inferred LM, the only difference being that the required synchronization is now between the LM counters and the test message generation process. Protocol and application designers MUST take these synchronization requirements into account when developing tools for inferred LM, and make their behavior in this regard clear to the user.
上面讨论的直接LM的同步条件也适用于推断的LM，唯一的区别是所需的同步现在在LM计数器和测试消息生成过程之间。协议和应用程序设计者在为LM开发工具时必须考虑这些同步要求，并让用户清楚地了解他们在这方面的行为。
Inferred LM provides only an approximate view of the loss level associated with a channel, but is typically applicable even in cases where direct LM is not.
推断的LM仅提供与信道相关的损耗水平的近似视图，但通常即使在不使用直接LM的情况下也适用。
In the case of direct LM, where data-plane packets are counted, there are different possibilities for which kinds of packets are included in the count and which are excluded. The set of packets counted for LM is called the "loss measurement scope". As noted above, one factor affecting the LM scope is whether all data packets are counted or only those belonging to a particular traffic class. Another is whether various "auxiliary" flows associated with a data channel are counted, such as packets flowing over the G-ACh. Implementations MUST make their supported LM scopes clear to the user, and care must be taken to ensure that the scopes of the channel endpoints agree.
在直接LM的情况下，其中对数据平面分组进行计数，对于哪些种类的分组被包括在计数中以及哪些被排除，存在不同的可能性。为LM计数的数据包集称为“丢失测量范围”。如上所述，影响LM范围的一个因素是是否对所有数据分组进行计数，还是仅对属于特定业务类别的数据分组进行计数。另一个问题是是否统计与数据信道相关联的各种“辅助”流，例如在G-ACh上流动的分组。实现必须向用户明确其支持的LM范围，并且必须注意确保通道端点的范围一致。
The delay measurement procedures described in this document are designed to facilitate hardware-assisted measurement and to function in the same way whether or not such hardware assistance is used. The measurement accuracy will be determined by how closely the transmit and receive timestamps correspond to actual packet departure and arrival times.
本文件中描述的延迟测量程序旨在促进硬件辅助测量，并以相同的方式运行，无论是否使用此类硬件辅助。测量精度将取决于发送和接收时间戳与实际数据包出发和到达时间的对应程度。
As noted in Section 2.4, measurement of one-way delay requires clock synchronization between the devices involved, while two-way delay measurement does not involve direct comparison between non-local timestamps and thus has no synchronization requirement. The measurement accuracy will be limited by the quality of the local clock and, in the case of one-way delay measurement, by the quality of the synchronization.
如第2.4节所述，单向延迟的测量要求相关设备之间的时钟同步，而双向延迟测量不涉及非本地时间戳之间的直接比较，因此无同步要求。测量精度将受到本地时钟质量的限制，在单向延迟测量的情况下，还将受到同步质量的限制。
There are two significant timestamp formats in common use: the timestamp format of the Network Time Protocol (NTP), described in [RFC5905], and the timestamp format used in the IEEE 1588 Precision Time Protocol (PTP) [IEEE1588].
常用的时间戳格式有两种：网络时间协议（NTP）的时间戳格式（如[RFC5905]所述）和IEEE 1588精密时间协议（PTP）[IEEE1588]中使用的时间戳格式。
The NTP format has the advantages of wide use and long deployment in the Internet, and it was specifically designed to make the computation of timestamp differences as simple and efficient as possible. On the other hand, there is now also a significant deployment of equipment designed to support the PTP format.
NTP格式具有广泛使用和在Internet上部署时间长的优点，其专门设计目的是使时间戳差异的计算尽可能简单高效。另一方面，目前还部署了大量旨在支持PTP格式的设备。
The approach taken in this document is therefore to include in DM messages fields that identify the timestamp formats used by the two devices involved in a DM operation. This implies that a node attempting to carry out a DM operation may be faced with the problem of computing with and possibly reconciling different timestamp formats. To ensure interoperability, it is necessary that support of at least one timestamp format is mandatory. This specification requires the support of the IEEE 1588 PTP format. Timestamp format support requirements are discussed in detail in Section 3.4.
因此，本文采用的方法是在DM messages字段中包含识别DM操作中涉及的两个设备使用的时间戳格式的字段。这意味着试图执行DM操作的节点可能面临使用不同时间戳格式进行计算并可能协调不同时间戳格式的问题。为了确保互操作性，必须至少支持一种时间戳格式。本规范要求支持IEEE 1588 PTP格式。第3.4节详细讨论了时间戳格式支持要求。
Loss Measurement and Delay Measurement messages flow over the MPLS Generic Associated Channel (G-ACh) [RFC5586]. Thus, a packet containing an LM or DM message contains an MPLS label stack, with the G-ACh Label (GAL) at the bottom of the stack. The GAL is followed by an Associated Channel Header (ACH), which identifies the message type, and the message body follows the ACH.
丢失测量和延迟测量消息在MPLS通用关联信道（G-ACh）上流动[RFC5586]。因此，包含LM或DM消息的数据包包含MPLS标签堆栈，G-ACh标签（GAL）位于堆栈底部。GAL后面是一个关联的通道头（ACH），用于标识消息类型，消息正文后面是ACH。
This document defines the following ACH Channel Types:
本文件定义了以下ACH通道类型：
MPLS Direct Loss Measurement (DLM) MPLS Inferred Loss Measurement (ILM) MPLS Delay Measurement (DM) MPLS Direct Loss and Delay Measurement (DLM+DM) MPLS Inferred Loss and Delay Measurement (ILM+DM)
MPLS直接损耗测量（DLM）MPLS推断损耗测量（ILM）MPLS延迟测量（DM）MPLS直接损耗和延迟测量（DLM+DM）MPLS推断损耗和延迟测量（ILM+DM）
The message formats for direct and inferred LM are identical. The formats of the DLM+DM and ILM+DM messages are also identical.
直接LM和推断LM的消息格式相同。DLM+DM和ILM+DM消息的格式也相同。
For these channel types, the ACH SHALL NOT be followed by the ACH TLV Header defined in [RFC5586].
对于这些信道类型，ACH后面不应跟随[RFC5586]中定义的ACH TLV头。
The fixed-format portion of a message MAY be followed by a block of Type-Length-Value (TLV) fields. The TLV block provides an extensible way of attaching subsidiary information to LM and DM messages. Several such TLV fields are defined below.
消息的固定格式部分后面可以跟一个类型长度值（TLV）字段块。TLV块提供了将辅助信息附加到LM和DM消息的可扩展方式。下面定义了几个这样的TLV字段。
All integer values for fields defined in this document SHALL be encoded in network byte order.
本文件中定义的字段的所有整数值应按网络字节顺序编码。
The format of a Loss Measurement message, which follows the Associated Channel Header (ACH), is as follows:
相关信道头（ACH）后面的损耗测量消息格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DFlags| OTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DFlags| OTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loss Measurement Message Format
损耗测量报文格式
Reserved fields MUST be set to 0 and ignored upon receipt. The possible values for the remaining fields are as follows.
保留字段必须设置为0，并在收到时忽略。其余字段的可能值如下所示。
Field Meaning
--------------------- -----------------------------------------------
Version Protocol version
Flags Message control flags
Control Code Code identifying the query or response type
Message Length Total length of this message in bytes
Data Format Flags Flags specifying the format of message data
(DFlags)
Origin Timestamp Format of the Origin Timestamp field
Format (OTF)
Reserved Reserved for future specification
Session Identifier Set arbitrarily by the querier
Differentiated Differentiated Services Code Point (DSCP) being
Services (DS) Field measured
Origin Timestamp 64-bit field for query message transmission
timestamp
Counter 1-4 64-bit fields for LM counter values
TLV Block Optional block of Type-Length-Value fields
Field Meaning
--------------------- -----------------------------------------------
Version Protocol version
Flags Message control flags
Control Code Code identifying the query or response type
Message Length Total length of this message in bytes
Data Format Flags Flags specifying the format of message data
(DFlags)
Origin Timestamp Format of the Origin Timestamp field
Format (OTF)
Reserved Reserved for future specification
Session Identifier Set arbitrarily by the querier
Differentiated Differentiated Services Code Point (DSCP) being
Services (DS) Field measured
Origin Timestamp 64-bit field for query message transmission
timestamp
Counter 1-4 64-bit fields for LM counter values
TLV Block Optional block of Type-Length-Value fields
The possible values for these fields are as follows.
这些字段的可能值如下所示。
Version: Currently set to 0.
版本：当前设置为0。
Flags: The format of the Flags field is shown below.
标志：标志字段的格式如下所示。
+-+-+-+-+
|R|T|0|0|
+-+-+-+-+
+-+-+-+-+
|R|T|0|0|
+-+-+-+-+
Loss Measurement Message Flags
损失测量消息标志
The meanings of the flag bits are:
标志位的含义如下：
R: Query/Response indicator. Set to 0 for a Query and 1 for a Response.
R：查询/响应指示器。查询设置为0，响应设置为1。
T: Traffic-class-specific measurement indicator. Set to 1 when the measurement operation is scoped to packets of a particular traffic class (DSCP value), and 0 otherwise. When set to 1, the DS field of the message indicates the measured traffic class.
T：交通等级特定测量指标。当测量操作的范围限定为特定流量类别（DSCP值）的数据包时，设置为1，否则设置为0。当设置为1时，消息的DS字段指示测量的流量等级。
0: Set to 0.
0:设置为0。
Control Code: Set as follows according to whether the message is a Query or a Response as identified by the R flag.
控制代码：根据消息是由R标志标识的查询还是响应，设置如下。
For a Query:
对于查询：
0x0: In-band Response Requested. Indicates that this query has been sent over a bidirectional channel and the response is expected over the same channel.
0x0:请求带内响应。指示此查询已通过双向通道发送，并且响应应通过同一通道发送。
0x1: Out-of-band Response Requested. Indicates that the response should be sent via an out-of-band channel.
0x1:请求带外响应。指示应通过带外通道发送响应。
0x2: No Response Requested. Indicates that no response to the query should be sent. This mode can be used, for example, if all nodes involved are being controlled by a Network Management System.
0x2:未请求响应。指示不应发送对查询的响应。例如，如果所有涉及的节点都由网络管理系统控制，则可以使用此模式。
For a Response:
关于答复：
Codes 0x0-0xF are reserved for non-error responses. Error response codes imply that the response does not contain valid measurement data.
代码0x0-0xF保留用于非错误响应。错误响应代码表示响应不包含有效的测量数据。
0x1: Success. Indicates that the operation was successful.
0x1：成功。表示操作已成功。
0x2: Notification - Data Format Invalid. Indicates that the query was processed, but the format of the data fields in this response may be inconsistent. Consequently, these data fields MUST NOT be used for measurement.
0x2:通知-数据格式无效。指示已处理查询，但此响应中数据字段的格式可能不一致。因此，这些数据字段不得用于测量。
0x3: Notification - Initialization in Progress. Indicates that the query was processed but this response does not contain valid measurement data because the responder's initialization process has not completed.
0x3:通知-正在进行初始化。指示已处理查询，但此响应不包含有效的度量数据，因为响应程序的初始化过程尚未完成。
0x4: Notification - Data Reset Occurred. Indicates that the query was processed, but a reset has recently occurred that may render the data in this response inconsistent relative to earlier responses.
0x4:通知-发生数据重置。指示已处理查询，但最近发生重置，这可能导致此响应中的数据与以前的响应不一致。
0x5: Notification - Resource Temporarily Unavailable. Indicates that the query was processed, but resources were unavailable to complete the requested measurement and that, consequently, this response does not contain valid measurement data.
0x5:通知-资源暂时不可用。指示已处理查询，但资源无法完成请求的度量，因此，此响应不包含有效的度量数据。
0x10: Error - Unspecified Error. Indicates that the operation failed for an unspecified reason.
0x10:错误-未指定的错误。指示操作因未指定的原因而失败。
0x11: Error - Unsupported Version. Indicates that the operation failed because the protocol version supplied in the query message is not supported.
0x11:错误-不支持的版本。指示操作失败，因为不支持查询消息中提供的协议版本。
0x12: Error - Unsupported Control Code. Indicates that the operation failed because the Control Code requested an operation that is not available for this channel.
0x12:错误-不支持的控制代码。指示操作失败，因为控制代码请求的操作对此通道不可用。
0x13: Error - Unsupported Data Format. Indicates that the operation failed because the data format specified in the query is not supported.
0x13:错误-不支持的数据格式。指示操作失败，因为不支持查询中指定的数据格式。
0x14: Error - Authentication Failure. Indicates that the operation failed because the authentication data supplied in the query was missing or incorrect.
0x14:错误-身份验证失败。指示操作失败，因为查询中提供的身份验证数据丢失或不正确。
0x15: Error - Invalid Destination Node Identifier. Indicates that the operation failed because the Destination Node Identifier supplied in the query is not an identifier of this node.
0x15:错误-目标节点标识符无效。指示操作失败，因为查询中提供的目标节点标识符不是此节点的标识符。
0x16: Error - Connection Mismatch. Indicates that the operation failed because the channel identifier supplied in the query did not match the channel over which the query was received.
0x16:错误-连接不匹配。指示操作失败，因为查询中提供的通道标识符与接收查询的通道不匹配。
0x17: Error - Unsupported Mandatory TLV Object. Indicates that the operation failed because a TLV Object received in the query and marked as mandatory is not supported.
0x17:错误-不支持的强制TLV对象。指示操作失败，因为不支持在查询中接收并标记为必需的TLV对象。
0x18: Error - Unsupported Query Interval. Indicates that the operation failed because the query message rate exceeded the configured threshold.
0x18:错误-不支持的查询间隔。指示操作失败，因为查询消息速率超过了配置的阈值。
0x19: Error - Administrative Block. Indicates that the operation failed because it has been administratively disallowed.
0x19:错误-管理块。指示操作失败，因为管理上不允许该操作。
0x1A: Error - Resource Unavailable. Indicates that the operation failed because node resources were not available.
0x1A:错误-资源不可用。指示操作失败，因为节点资源不可用。
0x1B: Error - Resource Released. Indicates that the operation failed because node resources for this measurement session were administratively released.
0x1B:错误-资源已释放。指示操作失败，因为此度量会话的节点资源已通过管理方式释放。
0x1C: Error - Invalid Message. Indicates that the operation failed because the received query message was malformed.
0x1C:错误-消息无效。指示操作失败，因为收到的查询消息格式不正确。
0x1D: Error - Protocol Error. Indicates that the operation failed because a protocol error was found in the received query message.
0x1D:错误-协议错误。指示操作失败，因为在收到的查询消息中发现协议错误。
Message Length: Set to the total length of this message in bytes, including the Version, Flags, Control Code, and Message Length fields as well as the TLV Block, if any.
消息长度：设置为此消息的总长度（字节），包括版本、标志、控制代码和消息长度字段以及TLV块（如果有）。
DFlags: The format of the DFlags field is shown below.
DFlags：DFlags字段的格式如下所示。
+-+-+-+-+
|X|B|0|0|
+-+-+-+-+
+-+-+-+-+
|X|B|0|0|
+-+-+-+-+
Data Format Flags
数据格式标志
The meanings of the DFlags bits are:
DFlags位的含义如下：
X: Extended counter format indicator. Indicates the use of extended (64-bit) counter values. Initialized to 1 upon creation (and prior to transmission) of an LM Query and copied from an LM Query to an LM response. Set to 0 when the LM message is transmitted or received over an interface that writes 32-bit counter values.
X：扩展计数器格式指示器。指示使用扩展（64位）计数器值。创建LM查询时（传输前）初始化为1，并从LM查询复制到LM响应。通过写入32位计数器值的接口传输或接收LM消息时，设置为0。
B: Octet (byte) count. When set to 1, indicates that the Counter 1-4 fields represent octet counts. The octet count applies to all packets within the LM scope (Section 2.9.9), and the octet count of a packet sent or received over a channel includes the total length of that packet (but excludes headers, labels, or framing of the channel itself). When set to 0, indicates that the Counter 1-4 fields represent packet counts.
八位字节（字节）计数。设置为1时，表示计数器1-4字段表示八位字节计数。八位字节计数适用于LM范围内的所有数据包（第2.9.9节），通过信道发送或接收的数据包的八位字节计数包括该数据包的总长度（但不包括信道本身的报头、标签或帧）。设置为0时，表示计数器1-4字段表示数据包计数。
0: Set to 0.
0:设置为0。
Origin Timestamp Format: The format of the Origin Timestamp field, as specified in Section 3.4.
原点时间戳格式：原点时间戳字段的格式，如第3.4节所述。
Session Identifier: Set arbitrarily in a query and copied in the response, if any. This field uniquely identifies a measurement operation (also called a session) that consists of a sequence of messages. All messages in the sequence have the same Session Identifier.
会话标识符：在查询中任意设置，并在响应中复制（如果有）。此字段唯一标识由一系列消息组成的测量操作（也称为会话）。序列中的所有消息都具有相同的会话标识符。
DS: When the T flag is set to 1, this field is set to the DSCP value [RFC3260] that corresponds to the traffic class being measured. For MPLS, where the traffic class of a channel is identified by the three-bit Traffic Class in the channel's LSE [RFC5462], this field
DS：当T标志设置为1时，此字段设置为与所测量的流量等级相对应的DSCP值[RFC3260]。对于MPLS，其中信道的通信量等级由信道的LSE[RFC5462]中的三位通信量等级标识，此字段
SHOULD be set to the Class Selector Codepoint [RFC2474] that corresponds to that Traffic Class. When the T flag is set to 0, the value of this field is arbitrary, and the field can be considered part of the Session Identifier.
应设置为与该流量类别对应的类别选择器代码点[RFC2474]。当T标志设置为0时，此字段的值是任意的，并且该字段可以被视为会话标识符的一部分。
Origin Timestamp: Timestamp recording the transmit time of the query message.
原始时间戳：记录查询消息传输时间的时间戳。
Counter 1-4: Referring to Section 2.2, when a query is sent from A, Counter 1 is set to A_TxP and the other counter fields are set to 0. When the query is received at B, Counter 2 is set to B_RxP. At this point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4, and re-initializes Counter 1 and Counter 2 to 0. When B transmits the response, Counter 1 is set to B_TxP. When the response is received at A, Counter 2 is set to A_RxP.
计数器1-4：参考第2.2节，当从a发送查询时，计数器1设置为a_TxP，其他计数器字段设置为0。当在B处收到查询时，计数器2设置为B_RxP。此时，B将计数器1复制到计数器3，将计数器2复制到计数器4，并将计数器1和计数器2重新初始化为0。当B发送响应时，计数器1设置为B_TxP。当在A接收到响应时，计数器2被设置为A_RxP。
The mapping of counter types such as A_TxP to the Counter 1-4 fields is designed to ensure that transmit counter values are always written at the same fixed offset in the packet, and likewise for receive counters. This property may be important for hardware processing.
计数器类型（如A_TxP）到计数器1-4字段的映射旨在确保发送计数器值始终以相同的固定偏移量写入数据包，接收计数器也是如此。此属性对于硬件处理可能很重要。
When a 32-bit counter value is written to one of the counter fields, that value SHALL be written to the low-order 32 bits of the field; the high-order 32 bits of the field MUST, in this case, be set to 0.
当一个32位计数器值写入其中一个计数器字段时，该值应写入该字段的低位32位；在这种情况下，字段的高阶32位必须设置为0。
TLV Block: Zero or more TLV fields.
TLV块：零个或多个TLV字段。
The format of a Delay Measurement message, which follows the Associated Channel Header (ACH), is as follows:
在相关信道头（ACH）之后的延迟测量消息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Delay Measurement Message Format
延迟测量消息格式
The meanings of the fields are summarized in the following table.
下表总结了这些字段的含义。
Field Meaning
--------------------- -----------------------------------------------
Version Protocol version
Flags Message control flags
Control Code Code identifying the query or response type
Message Length Total length of this message in bytes
QTF Querier timestamp format
RTF Responder timestamp format
RPTF Responder's preferred timestamp format
Reserved Reserved for future specification
Session Identifier Set arbitrarily by the querier
Differentiated Differentiated Services Code Point (DSCP) being
Services (DS) Field measured
Field Meaning
--------------------- -----------------------------------------------
Version Protocol version
Flags Message control flags
Control Code Code identifying the query or response type
Message Length Total length of this message in bytes
QTF Querier timestamp format
RTF Responder timestamp format
RPTF Responder's preferred timestamp format
Reserved Reserved for future specification
Session Identifier Set arbitrarily by the querier
Differentiated Differentiated Services Code Point (DSCP) being
Services (DS) Field measured
Timestamp 1-4 64-bit timestamp values TLV Block Optional block of Type-Length-Value fields
时间戳1-4 64位时间戳值TLV块类型长度值字段的可选块
Reserved fields MUST be set to 0 and ignored upon receipt. The possible values for the remaining fields are as follows.
保留字段必须设置为0，并在收到时忽略。其余字段的可能值如下所示。
Version: Currently set to 0.
版本：当前设置为0。
Flags: As specified in Section 3.1. The T flag in a DM message is set to 1.
标志：如第3.1节所述。DM消息中的T标志设置为1。
Control Code: As specified in Section 3.1.
控制代码：如第3.1节所述。
Message Length: Set to the total length of this message in bytes, including the Version, Flags, Control Code, and Message Length fields as well as the TLV Block, if any.
消息长度：设置为此消息的总长度（字节），包括版本、标志、控制代码和消息长度字段以及TLV块（如果有）。
Querier Timestamp Format: The format of the timestamp values written by the querier, as specified in Section 3.4.
查询器时间戳格式：查询器写入的时间戳值的格式，如第3.4节所述。
Responder Timestamp Format: The format of the timestamp values written by the responder, as specified in Section 3.4.
响应者时间戳格式：响应者写入的时间戳值格式，如第3.4节所述。
Responder's Preferred Timestamp Format: The timestamp format preferred by the responder, as specified in Section 3.4.
响应者首选时间戳格式：响应者首选的时间戳格式，如第3.4节所述。
Session Identifier: As specified in Section 3.1.
会话标识符：如第3.1节所述。
DS: As specified in Section 3.1.
DS：如第3.1节所述。
Timestamp 1-4: Referring to Section 2.4, when a query is sent from A, Timestamp 1 is set to T1 and the other timestamp fields are set to 0. When the query is received at B, Timestamp 2 is set to T2. At this point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0. When B transmits the response, Timestamp 1 is set to T3. When the response is received at A, Timestamp 2 is set to T4. The actual formats of the timestamp fields written by A and B are indicated by the Querier Timestamp Format and Responder Timestamp Format fields respectively.
时间戳1-4：参考第2.4节，当从a发送查询时，时间戳1设置为T1，其他时间戳字段设置为0。当在B接收到查询时，时间戳2被设置为T2。此时，B将时间戳1复制到时间戳3，将时间戳2复制到时间戳4，并将时间戳1和时间戳2重新初始化为0。当B发送响应时，时间戳1被设置为T3。在接收到响应时，时间戳2被设置为T4。由A和B写入的时间戳字段的实际格式分别由查询器时间戳格式和响应器时间戳格式字段指示。
The mapping of timestamps to the Timestamp 1-4 fields is designed to ensure that transmit timestamps are always written at the same fixed offset in the packet, and likewise for receive timestamps. This property is important for hardware processing.
时间戳到时间戳1-4字段的映射旨在确保发送时间戳始终以相同的固定偏移量写入数据包中，同样，对于接收时间戳也是如此。此属性对于硬件处理非常重要。
TLV Block: Zero or more TLV fields.
TLV块：零个或多个TLV字段。
The format of a combined Loss and Delay Measurement message, which follows the Associated Channel Header (ACH), is as follows:
相关信道报头（ACH）后面的综合损耗和延迟测量消息的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DFlags| QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DFlags| QTF | RTF | RPTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier | DS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loss/Delay Measurement Message Format
损失/延迟测量消息格式
The fields of this message have the same meanings as the corresponding fields in the LM and DM message formats, except that the roles of the OTF and Origin Timestamp fields for LM are here played by the QTF and Timestamp 1 fields, respectively.
此消息的字段与LM和DM消息格式中的相应字段具有相同的含义，不同的是，此处LM的OTF和原始时间戳字段分别由QTF和时间戳1字段扮演。
The following timestamp format field values are specified in this document:
本文档中指定了以下时间戳格式字段值：
0: Null timestamp format. This value is a placeholder indicating that the timestamp field does not contain a meaningful timestamp.
0:空时间戳格式。此值是一个占位符，指示时间戳字段不包含有意义的时间戳。
1: Sequence number. This value indicates that the timestamp field is to be viewed as a simple 64-bit sequence number. This provides a simple solution for applications that do not require a real absolute timestamp, but only an indication of message ordering; an example is LM exception detection.
1：序列号。此值表示时间戳字段将被视为简单的64位序列号。这为不需要真正的绝对时间戳，而只需要指示消息顺序的应用程序提供了一个简单的解决方案；LM异常检测就是一个例子。
2: Network Time Protocol version 4 64-bit timestamp format [RFC5905]. This format consists of a 32-bit seconds field followed by a 32-bit fractional seconds field, so that it can be regarded as a fixed-point 64-bit quantity.
2：网络时间协议版本4 64位时间戳格式[RFC5905]。此格式由32位秒字段和32位分数秒字段组成，因此可以将其视为定点64位量。
3: Low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time Protocol timestamp format [IEEE1588]. This truncated format consists of a 32-bit seconds field followed by a 32-bit nanoseconds field, and is the same as the IEEE 1588v1 timestamp format.
3:IEEE 1588-2008（1588v2）精密时间协议时间戳格式的低阶64位[IEEE1588]。此截断格式由32位秒字段和32位纳秒字段组成，与IEEE 1588v1时间戳格式相同。
Timestamp formats of n < 64 bits in size SHALL be encoded in the 64-bit timestamp fields specified in this document using the n high-order bits of the field. The remaining 64 - n low-order bits in the field SHOULD be set to 0 and MUST be ignored when reading the field.
大小为n<64位的时间戳格式应使用字段的n个高阶位在本文件规定的64位时间戳字段中进行编码。字段中剩余的64-n低位应设置为0，并且在读取字段时必须忽略。
To ensure that it is possible to find an interoperable mode between implementations, it is necessary to select one timestamp format as the default. The timestamp format chosen as the default is the truncated IEEE 1588 PTP format (format code 3 in the list above); this format MUST be supported. The rationale for this choice is discussed in Appendix A. Implementations SHOULD also be capable of reading timestamps written in NTPv4 64-bit format and reconciling them internally with PTP timestamps for measurement purposes. Support for other timestamp formats is OPTIONAL.
为了确保可以在实现之间找到互操作模式，有必要选择一种时间戳格式作为默认格式。默认选择的时间戳格式是截断的IEEE 1588 PTP格式（上面列表中的格式代码3）；必须支持此格式。该选择的基本原理在附录A中讨论。实现还应能够读取以NTPv4 64位格式写入的时间戳，并在内部将其与PTP时间戳进行协调，以便进行测量。对其他时间戳格式的支持是可选的。
The implementation MUST make clear which timestamp formats it supports and the extent of its support for computation with and reconciliation of different formats for measurement purposes.
实现必须明确它支持哪些时间戳格式，以及它支持不同格式的计算和协调的程度，以便进行测量。
The TLV Block in LM and DM messages consists of zero or more objects with the following format:
LM和DM消息中的TLV块由零个或多个具有以下格式的对象组成：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format
TLV格式
The Type and Length fields are each 8 bits long, and the Length field indicates the size in bytes of the Value field, which can therefore be up to 255 bytes long.
类型字段和长度字段的长度各为8位，长度字段表示值字段的大小（以字节为单位），因此最长可达255字节。
The Type space is divided into Mandatory and Optional subspaces:
类型空间分为强制子空间和可选子空间：
Type Range Semantics
-------------- ---------
0-127 Mandatory
128-255 Optional
Type Range Semantics
-------------- ---------
0-127 Mandatory
128-255 Optional
Upon receipt of a query message including an unrecognized mandatory TLV object, the recipient MUST respond with an Unsupported Mandatory TLV Object error code.
收到包含无法识别的强制TLV对象的查询消息后，收件人必须使用不受支持的强制TLV对象错误代码进行响应。
The types defined are as follows:
定义的类型如下：
Type Definition
-------------- ---------------------------------
Mandatory
0 Padding - copy in response
1 Return Address
2 Session Query Interval
3 Loopback Request
4-126 Unallocated
127 Experimental use
Type Definition
-------------- ---------------------------------
Mandatory
0 Padding - copy in response
1 Return Address
2 Session Query Interval
3 Loopback Request
4-126 Unallocated
127 Experimental use
Optional 128 Padding - do not copy in response 129 Destination Address 130 Source Address 131-254 Unallocated 255 Experimental use
可选128填充-不在响应中复制129目标地址130源地址131-254未分配255实验使用
The two padding objects permit the augmentation of packet size; this is mainly useful for delay measurement. The type of padding indicates whether the padding supplied by the querier is to be copied to, or omitted from, the response. Asymmetrical padding may be useful when responses are delivered out-of-band or when different maximum transmission unit sizes apply to the two components of a bidirectional channel.
两个填充对象允许增加数据包大小；这主要用于延迟测量。填充类型指示是将查询器提供的填充复制到响应中，还是从响应中忽略。当响应在带外传送时，或者当不同的最大传输单元大小应用于双向信道的两个分量时，非对称填充可能是有用的。
More than one padding object MAY be present, in which case they MUST be contiguous. The Value field of a padding object is arbitrary.
可能存在多个填充对象，在这种情况下，它们必须是连续的。填充对象的值字段是任意的。
The addressing objects have the following format:
寻址对象具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addressing Object Format
寻址对象格式
The Address Family field indicates the type of the address, and it SHALL be set to one of the assigned values in the "IANA Address Family Numbers" registry.
地址系列字段表示地址的类型，应将其设置为“IANA地址系列号”注册表中的指定值之一。
The Source and Destination Address objects indicate the addresses of the sender and the intended recipient of the message, respectively. The Source Address of a query message SHOULD be used as the destination for an out-of-band response unless some other out-of-band response mechanism has been configured, and unless a Return Address object is present, in which case the Return Address specifies the target of the response. The Return Address object MUST NOT appear in a response.
源地址和目标地址对象分别表示消息的发送者和预期接收者的地址。查询消息的源地址应用作带外响应的目标，除非已配置其他带外响应机制，并且除非存在返回地址对象，在这种情况下，返回地址指定响应的目标。返回地址对象不能出现在响应中。
The Loopback Request object, when included in a query, indicates a request that the query message be returned to the sender unmodified. This object has a Length of 0.
当包含在查询中时，Loopback请求对象指示将查询消息未经修改地返回给发送方的请求。此对象的长度为0。
Upon receiving the reflected query message back from the responder, the querier MUST NOT retransmit the message. Information that uniquely identifies the original query source, such as a Source Address object, can be included to enable the querier to differentiate one of its own loopback queries from a loopback query initiated by the far end.
在从响应者接收到反射的查询消息后，查询者不得重新传输该消息。可以包含唯一标识原始查询源的信息，例如源地址对象，以使查询者能够将其自己的环回查询与远端启动的环回查询区分开来。
This object may be useful, for example, when the querier is interested only in the round-trip delay metric. In this case, no support for delay measurement is required at the responder at all, other than the ability to recognize a DM query that includes this object and return it unmodified.
例如，当查询者只对往返延迟度量感兴趣时，此对象可能有用。在这种情况下，响应程序根本不需要对延迟测量的支持，除了能够识别包含此对象的DM查询并返回未修改的DM查询之外。
The Value field of the Session Query Interval object is a 32-bit unsigned integer that specifies a time interval in milliseconds.
会话查询间隔对象的值字段是一个32位无符号整数，以毫秒为单位指定时间间隔。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Session Query >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
< Interval (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Session Query >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
< Interval (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Session Query Interval Object Format
会话查询间隔对象格式
This time interval indicates the interval between successive query messages in a specific measurement session. The purpose of the Session Query Interval (SQI) object is to enable the querier and responder of a measurement session to agree on a query rate. The procedures for handling this object SHALL be as follows:
此时间间隔表示特定度量会话中连续查询消息之间的间隔。会话查询间隔（SQI）对象的目的是使测量会话的查询者和响应者能够就查询速率达成一致。处理该物体的程序如下：
1. The querier notifies the responder that it wishes to be informed of the responder's minimum query interval for this session by including the SQI object in its query messages, with a Value of 0.
1. 查询者通过在其查询消息中包含SQI对象（值为0），通知响应者它希望被告知响应者此会话的最小查询间隔。
2. When the responder receives a query that includes an SQI object with a Value of 0, the responder includes an SQI object in the response with the Value set to the minimum query interval it supports for this session.
2. 当响应程序接收到包含值为0的SQI对象的查询时，响应程序将在响应中包含一个SQI对象，该值设置为该会话支持的最小查询间隔。
3. When the querier receives a response that includes an SQI object, it selects a query interval for the session that is greater than or equal to the Value specified in the SQI object and adjusts its query transmission rate accordingly, including in each subsequent query an SQI object with a Value equal to the selected query interval. Once a response to one of these subsequent queries has been received, the querier infers that the responder has been apprised of the selected query interval and MAY then stop including the SQI object in queries associated with this session.
3. 当查询器接收到包含SQI对象的响应时，它会为会话选择一个大于或等于SQI对象中指定的值的查询间隔，并相应地调整其查询传输速率，包括在每个后续查询中包含一个值等于所选查询间隔的SQI对象。一旦接收到对这些后续查询之一的响应，查询者就推断响应者已被告知所选查询间隔，然后可能停止在与该会话相关联的查询中包括SQI对象。
Similar procedures allow the query rate to be changed during the course of the session by either the querier or the responder. For example, to inform the querier of a change in the minimum supported query interval, the responder begins including a corresponding SQI object in its responses, and the querier adjusts its query rate if necessary and includes a corresponding SQI object in its queries until a response is received.
类似的过程允许查询者或响应者在会话过程中更改查询速率。例如，为了通知查询者支持的最小查询间隔的变化，响应者开始在其响应中包括相应的SQI对象，并且查询者在必要时调整其查询速率，并在其查询中包括相应的SQI对象，直到收到响应为止。
Shorter query intervals (i.e., higher query rates) provide finer measurement granularity at the expense of additional load on measurement endpoints and the network; see Section 6 for further discussion.
更短的查询间隔（即，更高的查询速率）提供了更精细的测量粒度，但代价是测量端点和网络上的额外负载；进一步讨论见第6节。
A loss or delay measurement operation, also called a session, is controlled by the querier and consists of a sequence of query messages associated with a particular channel and a common set of measurement parameters. If the session parameters include a response request, then the receiving node or nodes will (under normal conditions) generate a response message for each query message received, and these responses are also considered part of the session. All query and response messages in a session carry a common session identifier.
丢失或延迟测量操作（也称为会话）由查询器控制，由一系列与特定通道相关联的查询消息和一组公共测量参数组成。如果会话参数包括响应请求，则接收节点（在正常情况下）将为接收到的每个查询消息生成响应消息，并且这些响应也被视为会话的一部分。会话中的所有查询和响应消息都带有一个公共会话标识符。
Measurement sessions are initiated at the discretion of the network operator and are terminated either at the operator's request or as the result of an error condition. A session may be as brief as a single message exchange, for example when a DM query is used by the operator to "ping" a remote node, or it may extend throughout the lifetime of the channel.
测量会话由网络运营商自行决定启动，并根据运营商的请求或错误情况终止。会话可以与单个消息交换一样简短，例如，当操作员使用DM查询“ping”远程节点时，或者会话可以在信道的整个生命周期内延长。
When a session is initiated for which responses are requested, the querier SHOULD initialize a timer, called the SessionResponseTimeout, that indicates how long the querier will wait for a response before abandoning the session and notifying the user that a timeout has occurred. This timer persists for the lifetime of the session and is reset each time a response message for the session is received.
当启动请求响应的会话时，查询器应初始化一个称为SessionResponseTimeout的计时器，该计时器指示查询器在放弃会话并通知用户超时之前等待响应的时间。此计时器在会话的生命周期内持续存在，并且在每次收到会话的响应消息时重置。
When a query message is received that requests a response, a variety of exceptional conditions may arise that prevent the responder from generating a response that contains valid measurement data. Such conditions fall broadly into two classes: transient exceptions from which recovery is possible and fatal exceptions that require termination of the session. When an exception arises, the responder SHOULD generate a response with an appropriate Notification or Error control code according to whether the exception is, respectively, transient or fatal. When the querier receives an Error response, the session MUST be terminated and the user informed.
当接收到请求响应的查询消息时，可能会出现各种异常情况，阻止响应者生成包含有效测量数据的响应。这种情况大致可分为两类：可以从中恢复的暂时异常和需要终止会话的致命异常。当出现异常时，响应者应根据异常是暂时的还是致命的，生成带有适当通知或错误控制代码的响应。当查询者收到错误响应时，必须终止会话并通知用户。
A common example of a transient exception occurs when a new session is initiated and the responder requires a period of time to become ready before it can begin providing useful responses. The response control code corresponding to this situation is Notification -
一个常见的瞬态异常示例是，当启动新会话时，响应者需要一段时间准备就绪，然后才能开始提供有用的响应。与此情况对应的响应控制代码为通知-
Initialization in Progress. Typical examples of fatal exceptions are cases where the querier has requested a type of measurement that the responder does not support or where a query message is malformed.
正在进行初始化。致命异常的典型示例是查询者请求了响应者不支持的度量类型，或者查询消息格式不正确。
When initiating a session, the querier SHOULD employ the Session Query Interval mechanism (Section 3.5.4) to establish a mutually agreeable query rate with the responder. Responders SHOULD employ rate-limiting mechanisms to guard against the possibility of receiving an excessive quantity of query messages.
在启动会话时，查询者应使用会话查询间隔机制（第3.5.4节）与响应者建立相互一致的查询速率。响应者应该使用速率限制机制来防止接收过多查询消息的可能性。
An LM operation for a particular channel consists of sending a sequence (LM[1], LM[2], ...) of LM query messages over the channel at a specific rate and processing the responses received, if any. As described in Section 2.2, the packet loss associated with the channel during the operation is computed as a delta between successive messages; these deltas can be accumulated to obtain a running total of the packet loss for the channel or be used to derive related metrics such as the average loss rate.
特定通道的LM操作包括以特定速率通过通道发送LM查询消息序列（LM[1]、LM[2]、…），并处理收到的响应（如果有）。如第2.2节所述，操作期间与信道相关的分组丢失计算为连续消息之间的增量；这些增量可被累积以获得信道的分组丢失的运行总数，或用于导出诸如平均丢失率之类的相关度量。
The query message transmission rate MUST be sufficiently high, given the LM message counter size (which can be either 32 or 64 bits) and the speed and minimum packet size of the underlying channel, that the ambiguity condition noted in Section 2.2 cannot arise. In evaluating this rate, the implementation SHOULD assume that the counter size is 32 bits unless explicitly configured otherwise or unless (in the case of a bidirectional channel) all local and remote interfaces involved in the LM operation are known to be 64-bit-capable, which can be inferred from the value of the X flag in an LM response.
鉴于LM消息计数器大小（可以是32位或64位）以及底层信道的速度和最小数据包大小，查询消息传输速率必须足够高，以避免出现第2.2节中提到的歧义情况。在评估该速率时，实现应假设计数器大小为32位，除非明确另行配置，或者除非（在双向信道的情况下）已知LM操作中涉及的所有本地和远程接口都具有64位功能，这可以从LM响应中的X标志值推断出来。
When transmitting an LM Query, the Version field MUST be set to 0. The R flag MUST be set to 0. The T flag SHALL be set to 1 if, and only if, the measurement is specific to a particular traffic class, in which case the DS field SHALL identify that traffic class.
传输LM查询时，版本字段必须设置为0。R标志必须设置为0。当且仅当测量特定于特定交通等级时，T标志应设置为1，在这种情况下，DS字段应识别该交通等级。
The X flag MUST be set to 1 if the transmitting interface writes 64-bit LM counters and otherwise MUST be set to 0 to indicate that 32-bit counters are written. The B flag SHALL be set to 1 to indicate that the counter fields contain octet counts or to 0 to indicate packet counts.
如果传输接口写入64位LM计数器，则必须将X标志设置为1，否则必须设置为0以指示写入32位计数器。B标志应设置为1表示计数器字段包含八位字节计数，或设置为0表示数据包计数。
The Control Code field MUST be set to one of the values for Query messages listed in Section 3.1; if the channel is unidirectional, this field MUST NOT be set to 0x0 (Query: In-band Response Requested).
控制代码字段必须设置为第3.1节中列出的查询消息的值之一；如果通道是单向的，则此字段不得设置为0x0（查询：请求带内响应）。
The Session Identifier field can be set arbitrarily.
会话标识符字段可以任意设置。
The Origin Timestamp field SHALL be set to the time at which this message is transmitted, and the Origin Timestamp Format field MUST be set to indicate its format, according to Section 3.4.
根据第3.4节，原点时间戳字段应设置为该消息传输的时间，且原点时间戳格式字段必须设置为指示其格式。
The Counter 1 field SHOULD be set to the total count of units (packets or octets, according to the B flag) transmitted over the channel prior to this LM Query, or to 0 if this is the beginning of a measurement session for which counter data is not yet available. The Counter 2 field MUST be set to 0. If a response was previously received in this measurement session, the Counter 1 and Counter 2 fields of the most recent such response MAY be copied to the Counter 3 and Counter 4 fields, respectively, of this query; otherwise, the Counter 3 and Counter 4 fields MUST be set to 0.
计数器1字段应设置为在该LM查询之前通过信道传输的单位总数（根据B标志，数据包或八位字节），或者如果这是计数器数据尚不可用的测量会话的开始，则应设置为0。计数器2字段必须设置为0。如果先前在该测量会话中接收到响应，则可将最近此类响应的计数器1和计数器2字段分别复制到该查询的计数器3和计数器4字段；否则，计数器3和计数器4字段必须设置为0。
Upon receipt of an LM Query message, the Counter 2 field SHOULD be set to the total count of units (packets or octets, according to the B flag) received over the channel prior to this LM Query. If the receiving interface writes 32-bit LM counters, the X flag MUST be set to 0.
收到LM查询消息后，计数器2字段应设置为在该LM查询之前通过通道接收的单位总数（根据B标志，数据包或八位字节）。如果接收接口写入32位LM计数器，则X标志必须设置为0。
At this point, the LM Query message must be inspected. If the Control Code field is set to 0x2 (No Response Requested), an LM Response message MUST NOT be transmitted. If the Control Code field is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band Response Requested), then an in-band or out-of-band response, respectively, SHOULD be transmitted unless this has been prevented by an administrative, security, or congestion control mechanism.
此时，必须检查LM查询消息。如果控制代码字段设置为0x2（未请求响应），则不得发送LM响应消息。如果控制代码字段设置为0x0（请求带内响应）或0x1（请求带外响应），则应分别发送带内或带外响应，除非这已被管理、安全或拥塞控制机制阻止。
In the case of a fatal exception that prevents the requested measurement from being made, the error SHOULD be reported, via either a response, if one was requested, or else as a notification to the user.
如果发生致命异常，导致无法进行请求的测量，则应通过响应（如果请求响应）或通知用户来报告错误。
When constructing a Response to an LM Query, the Version field MUST be set to 0. The R flag MUST be set to 1. The value of the T flag MUST be copied from the LM Query.
构造对LM查询的响应时，版本字段必须设置为0。R标志必须设置为1。必须从LM查询中复制T标志的值。
The X flag MUST be set to 0 if the transmitting interface writes 32-bit LM counters; otherwise, its value MUST be copied from the LM Query. The B flag MUST be copied from the LM Query.
如果传输接口写入32位LM计数器，则X标志必须设置为0；否则，必须从LM查询复制其值。必须从LM查询复制B标志。
The Session Identifier, Origin Timestamp, and Origin Timestamp Format fields MUST be copied from the LM Query. The Counter 1 and Counter 2 fields from the LM Query MUST be copied to the Counter 3 and Counter 4 fields, respectively, of the LM Response.
会话标识符、源时间戳和源时间戳格式字段必须从LM查询中复制。LM查询中的计数器1和计数器2字段必须分别复制到LM响应的计数器3和计数器4字段。
The Control Code field MUST be set to one of the values for Response messages listed in Section 3.1. The value 0x10 (Unspecified Error) SHOULD NOT be used if one of the other more specific error codes is applicable.
控制代码字段必须设置为第3.1节中列出的响应消息值之一。如果其他更具体的错误代码之一适用，则不应使用值0x10（未指定的错误）。
If the response is transmitted in-band, the Counter 1 field SHOULD be set to the total count of units transmitted over the channel prior to this LM Response. If the response is transmitted out-of-band, the Counter 1 field MUST be set to 0. In either case, the Counter 2 field MUST be set to 0.
如果响应在频带内传输，则计数器1字段应设置为在该LM响应之前通过信道传输的单位总数。如果响应在带外传输，计数器1字段必须设置为0。无论哪种情况，计数器2字段都必须设置为0。
Upon in-band receipt of an LM Response message, the Counter 2 field is set to the total count of units received over the channel prior to this LM Response. If the receiving interface writes 32-bit LM counters, the X flag is set to 0. (Since the life of the LM message in the network has ended at this point, it is up to the receiver whether these final modifications are made to the packet. If the message is to be forwarded on for external post-processing (Section 2.9.7), then these modifications MUST be made.)
在带内接收到LM响应消息时，计数器2字段设置为在该LM响应之前通过信道接收的总单位数。如果接收接口写入32位LM计数器，则X标志设置为0。（由于LM消息在网络中的寿命到此结束，因此是否对数据包进行这些最终修改取决于接收者。如果要转发消息进行外部后处理（第2.9.7节），则必须进行这些修改。）
Upon out-of-band receipt of an LM Response message, the Counter 1 and Counter 2 fields MUST NOT be used for purposes of loss measurement.
在带外收到LM响应消息后，计数器1和计数器2字段不得用于损耗测量。
If the Control Code in an LM Response is anything other than 0x1 (Success), the counter values in the response MUST NOT be used for purposes of loss measurement. If the Control Code indicates an error condition, or if the response message is invalid, the LM operation MUST be terminated and an appropriate notification to the user generated.
如果LM响应中的控制代码不是0x1（成功），则响应中的计数器值不得用于损耗测量。如果控制代码指示错误情况，或者如果响应消息无效，则必须终止LM操作，并向用户生成适当的通知。
Calculation of packet loss is carried out according to the procedures in Section 2.2. The X flag in an LM message informs the device performing the calculation whether to perform 32-bit or 64-bit arithmetic. If the flag value is equal to 1, all interfaces involved in the LM operation have written 64-bit counter values, and 64-bit
根据第2.2节中的程序计算数据包丢失。LM消息中的X标志通知执行计算的设备是执行32位还是64位算术。如果标志值等于1，则LM操作中涉及的所有接口都写入了64位计数器值和64位计数器值
arithmetic can be used. If the flag value is equal to 0, at least one interface involved in the operation has written a 32-bit counter value, and 32-bit arithmetic is carried out using the low-order 32 bits of each counter value.
可以使用算术。如果标志值等于0，则操作中至少有一个接口写入了32位计数器值，并使用每个计数器值的低位32位执行32位算术。
Note that the semantics of the X flag allow all devices to interoperate regardless of their counter size support. Thus, an implementation MUST NOT generate an error response based on the value of this flag.
请注意，X标志的语义允许所有设备进行互操作，而不考虑其计数器大小支持。因此，实现不能基于此标志的值生成错误响应。
The TC field of the LSE corresponding to the channel (e.g., LSP) being measured SHOULD be set to a traffic class equal to or better than the best TC within the measurement scope to minimize the chance of out-of-order conditions.
与正在测量的信道（例如，LSP）对应的LSE的TC字段应设置为等于或优于测量范围内最佳TC的流量等级，以最大限度地减少出现故障的可能性。
By default, direct LM MUST exclude packets transmitted and received over the Generic Associated Channel (G-ACh). An implementation MAY provide the means to alter the direct LM scope to include some or all G-ACh messages. Care must be taken when altering the LM scope to ensure that both endpoints are in agreement.
默认情况下，直接LM必须排除通过通用关联信道（G-ACh）传输和接收的数据包。一个实现可以提供改变直接LM作用域以包括一些或所有G-ACh消息的方法。更改LM范围时必须小心，以确保两个端点一致。
In the case of inferred LM, the packets counted for LM consist of test messages generated for this purpose, or of some other class of packets deemed to provide a good proxy for data packets flowing over the channel. The specification of test protocols and proxy packets is outside the scope of this document, but some guidelines are discussed below.
在推断出的LM的情况下，为LM计数的分组包括为此目的生成的测试消息，或被认为为在信道上流动的数据分组提供良好代理的某些其他类别的分组。测试协议和代理数据包的规范不在本文档的范围内，但下面将讨论一些指导原则。
An identifier common to both the test or proxy messages and the LM messages may be required to make correlation possible. The combined value of the Session Identifier and DS fields SHOULD be used for this purpose when possible. That is, test messages in this case will include a 32-bit field that can carry the value of the combined Session Identifier + DS field present in LM messages. When TC-specific LM is conducted, the DS field of the LSE in the label stack of a test message corresponding to the channel (e.g., LSP) over which the message is sent MUST correspond to the DS value in the associated LM messages.
可能需要测试或代理消息与LM消息共用的标识符，以使关联成为可能。如果可能，会话标识符和DS字段的组合值应用于此目的。也就是说，在这种情况下，测试消息将包括一个32位字段，该字段可以携带LM消息中存在的组合会话标识符+DS字段的值。当执行特定于TC的LM时，测试消息标签堆栈中LSE的DS字段必须与相关LM消息中的DS值相对应，该测试消息对应于发送消息的信道（例如LSP）。
A separate test message protocol SHOULD include a timeout value in its messages that informs the responder when to discard any state associated with a specific test.
单独的测试消息协议应在其消息中包含一个超时值，该超时值通知响应者何时放弃与特定测试相关的任何状态。
Because an LM operation consists of a message sequence with state maintained from one message to the next, LM is subject to the effects of lost messages and misordered packets in a way that DM is not. Because this state exists only on the querier, the handling of these conditions is, strictly speaking, a local matter. This section, however, presents recommended procedures for handling such conditions. Note that in the absence of ECMP, packet misordering within a traffic class is a relatively rare event.
由于LM操作由一个消息序列组成，其状态从一条消息到下一条消息保持不变，因此LM会受到消息丢失和数据包顺序错误的影响，而DM不会受到影响。因为这种状态只存在于询问者身上，所以严格来说，这些条件的处理是一个局部问题。但是，本节介绍了处理此类情况的建议程序。请注意，在没有ECMP的情况下，流量类中的数据包错误排序是一种相对罕见的事件。
The first kind of anomaly that may occur is that one or more LM messages may be lost in transit. The effect of such loss is that when an LM Response is next received at the querier, an unambiguous interpretation of the counter values it contains may be impossible, for the reasons described at the end of Section 2.2. Whether this is so depends on the number of messages lost and the other variables mentioned in that section, such as the LM message rate and the channel parameters.
可能发生的第一种异常是，一条或多条LM消息可能在传输过程中丢失。这种损失的影响是，当查询器下一次收到LM响应时，由于第2.2节末尾所述的原因，可能无法对其包含的计数器值进行明确解释。是否如此取决于丢失的消息数量以及该部分中提到的其他变量，如LM消息速率和信道参数。
Another possibility is that LM messages are misordered in transit, so that, for instance, the response to LM[n] is received prior to the response to LM[n-1]. A typical implementation will discard the late response to LM[n-1], so that the effect is the same as the case of a lost message.
另一种可能性是LM消息在传输过程中顺序错误，因此，例如，对LM[n]的响应在对LM[n-1]的响应之前接收。典型的实现将丢弃对LM[n-1]的延迟响应，因此其效果与丢失消息的情况相同。
Finally, LM is subject to the possibility that data packets are misordered relative to LM messages. This condition can result, for example, in a transmit count of 100 and a corresponding receive count of 101. The effect here is that the A_TxLoss[n-1,n] value (for example) for a given measurement interval will appear to be extremely (if not impossibly) large. The other case, where an LM message arrives earlier than some of the packets, simply results in those packets being counted as lost.
最后，LM可能存在数据包相对于LM消息顺序错误的情况。例如，这种情况可能导致发送计数为100，相应的接收计数为101。这里的效果是，给定测量间隔的A_TxLoss[n-1，n]值（例如）将看起来非常大（如果不是不可能的话）。另一种情况是，LM消息比某些数据包更早到达，这只会导致这些数据包被视为丢失。
An implementation SHOULD identify a threshold value that indicates the upper bound of lost packets measured in a single computation beyond which the interval is considered unmeasurable. This is called the "MaxLMIntervalLoss threshold". It is clear that this threshold should be no higher than the maximum number of packets (or bytes) the channel is capable of transmitting over the interval, but it may be lower. Upon encountering an unmeasurable interval, the LM state (i.e., data values from the last LM message received) SHOULD be discarded.
实现应该识别一个阈值，该阈值指示在单个计算中测量的丢失数据包的上限，超过该上限的间隔被认为是不可测量的。这称为“MaxLMIntervalLoss阈值”。很明显，该阈值不应高于信道在该间隔内能够传输的最大数据包数（或字节数），但可能更低。遇到不可测量的间隔时，应丢弃LM状态（即接收到的最后一条LM消息的数据值）。
With regard to lost LM messages, the MaxLMInterval (see Section 2.2) indicates the maximum amount of time that can elapse before the LM state is discarded. If some messages are lost, but a message is
对于丢失的LM消息，MaxLMInterval（参见第2.2节）表示在丢弃LM状态之前可以经过的最大时间量。如果某些消息丢失，但有一条消息丢失
subsequently received within MaxLMInterval, its timestamp or sequence number will quantify the loss, and it MAY still be used for measurement, although the measurement interval will in this case be longer than usual.
随后在MaxLMInterval内接收，其时间戳或序列号将量化损失，并且它仍然可以用于测量，尽管在这种情况下，测量间隔将比平常更长。
If an LM message is received that has a timestamp less than or equal to the timestamp of the last LM message received, this indicates that an exception has occurred, and the current interval SHOULD be considered unmeasurable unless the implementation has some other way of handling this condition.
如果接收到的LM消息的时间戳小于或等于接收到的最后一条LM消息的时间戳，则表示发生了异常，并且当前间隔应被视为不可测量，除非实现有其他方法来处理此情况。
When transmitting a DM Query, the Version and Reserved fields MUST be set to 0. The R flag MUST be set to 0, the T flag MUST be set to 1, and the remaining flag bits MUST be set to 0.
传输DM查询时，版本和保留字段必须设置为0。R标志必须设置为0，T标志必须设置为1，其余标志位必须设置为0。
The Control Code field MUST be set to one of the values for Query messages listed in Section 3.1; if the channel is unidirectional, this field MUST NOT be set to 0x0 (Query: In-band Response Requested).
控制代码字段必须设置为第3.1节中列出的查询消息的值之一；如果通道是单向的，则此字段不得设置为0x0（查询：请求带内响应）。
The Querier Timestamp Format field MUST be set to the timestamp format used by the querier when writing timestamp fields in this message; the possible values for this field are listed in Section 3.4. The Responder Timestamp Format and Responder's Preferred Timestamp Format fields MUST be set to 0.
查询器时间戳格式字段必须设置为查询器在该消息中写入时间戳字段时使用的时间戳格式；第3.4节列出了该字段的可能值。响应程序时间戳格式和响应程序的首选时间戳格式字段必须设置为0。
The Session Identifier field can be set arbitrarily. The DS field MUST be set to the traffic class being measured.
会话标识符字段可以任意设置。DS字段必须设置为正在测量的流量类别。
The Timestamp 1 field SHOULD be set to the time at which this DM Query is transmitted, in the format indicated by the Querier Timestamp Format field. The Timestamp 2 field MUST be set to 0. If a response was previously received in this measurement session, the Timestamp 1 and Timestamp 2 fields of the most recent such response MAY be copied to the Timestamp 3 and Timestamp 4 fields, respectively, of this query; otherwise, the Timestamp 3 and Timestamp 4 fields MUST be set to 0.
Timestamp 1字段应设置为发送此DM查询的时间，格式由Querier Timestamp format字段指示。时间戳2字段必须设置为0。如果先前在该测量会话中接收到响应，则最近的此类响应的时间戳1和时间戳2字段可分别复制到该查询的时间戳3和时间戳4字段；否则，时间戳3和时间戳4字段必须设置为0。
Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be set to the time at which this DM Query was received.
收到DM查询消息后，时间戳2字段应设置为接收此DM查询的时间。
At this point, the DM Query message must be inspected. If the Control Code field is set to 0x2 (No Response Requested), a DM Response message MUST NOT be transmitted. If the Control Code field is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band Response Requested), then an in-band or out-of-band response, respectively, SHOULD be transmitted unless this has been prevented by an administrative, security, or congestion control mechanism.
此时，必须检查DM Query消息。如果控制代码字段设置为0x2（未请求响应），则不得发送DM响应消息。如果控制代码字段设置为0x0（请求带内响应）或0x1（请求带外响应），则应分别发送带内或带外响应，除非这已被管理、安全或拥塞控制机制阻止。
In the case of a fatal exception that prevents the requested measurement from being made, the error SHOULD be reported, via either a response, if one was requested, or else as a notification to the user.
如果发生致命异常，导致无法进行请求的测量，则应通过响应（如果请求响应）或通知用户来报告错误。
When constructing a Response to a DM Query, the Version and Reserved fields MUST be set to 0. The R flag MUST be set to 1, the T flag MUST be set to 1, and the remaining flag bits MUST be set to 0.
构造对DM查询的响应时，版本和保留字段必须设置为0。R标志必须设置为1，T标志必须设置为1，其余标志位必须设置为0。
The Session Identifier and Querier Timestamp Format (QTF) fields MUST be copied from the DM Query. The Timestamp 1 and Timestamp 2 fields from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4 fields, respectively, of the DM Response.
会话标识符和查询器时间戳格式（QTF）字段必须从DM查询中复制。DM查询中的Timestamp 1和Timestamp 2字段必须分别复制到DM响应的Timestamp 3和Timestamp 4字段中。
The Responder Timestamp Format (RTF) field MUST be set to the timestamp format used by the responder when writing timestamp fields in this message, i.e., Timestamp 4 and (if applicable) Timestamp 1; the possible values for this field are listed in Section 3.4. Furthermore, the RTF field MUST be set equal to either the QTF or the RPTF field. See Section 4.3.5 for guidelines on the selection of the value for this field.
响应者时间戳格式（RTF）字段必须设置为响应者在该消息中写入时间戳字段时使用的时间戳格式，即时间戳4和（如果适用）时间戳1；第3.4节列出了该字段的可能值。此外，RTF字段必须设置为等于QTF或RPTF字段。有关选择该字段值的指南，请参见第4.3.5节。
The Responder's Preferred Timestamp Format (RPTF) field MUST be set to one of the values listed in Section 3.4 and SHOULD be set to indicate the timestamp format with which the responder can provide the best accuracy for purposes of delay measurement.
响应者的首选时间戳格式（RPTF）字段必须设置为第3.4节中列出的值之一，并且应设置为指示响应者可以提供最佳精度的时间戳格式，以进行延迟测量。
The Control Code field MUST be set to one of the values for Response messages listed in Section 3.1. The value 0x10 (Unspecified Error) SHOULD NOT be used if one of the other more specific error codes is applicable.
控制代码字段必须设置为第3.1节中列出的响应消息值之一。如果其他更具体的错误代码之一适用，则不应使用值0x10（未指定的错误）。
If the response is transmitted in-band, the Timestamp 1 field SHOULD be set to the time at which this DM Response is transmitted. If the response is transmitted out-of-band, the Timestamp 1 field MUST be set to 0. In either case, the Timestamp 2 field MUST be set to 0.
如果响应在频带内传输，则时间戳1字段应设置为发送此DM响应的时间。如果响应在带外传输，则时间戳1字段必须设置为0。无论哪种情况，时间戳2字段都必须设置为0。
If the response is transmitted in-band and the Control Code in the message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields MUST have the same format, which will be the format indicated in the Responder Timestamp Format field.
如果响应在频带内传输，且消息中的控制代码为0x1（成功），则时间戳1和时间戳4字段必须具有相同的格式，即响应者时间戳格式字段中指示的格式。
Upon in-band receipt of a DM Response message, the Timestamp 2 field is set to the time at which this DM Response was received. (Since the life of the DM message in the network has ended at this point, it is up to the receiver whether this final modification is made to the packet. If the message is to be forwarded on for external post-processing (Section 2.9.7), then these modifications MUST be made.)
在带内接收到DM响应消息时，Timestamp 2字段设置为接收此DM响应的时间。（由于DM消息在网络中的寿命到此结束，因此是否对数据包进行最终修改取决于接收者。如果要转发消息进行外部后处理（第2.9.7节），则必须进行这些修改。）
Upon out-of-band receipt of a DM Response message, the Timestamp 1 and Timestamp 2 fields MUST NOT be used for purposes of delay measurement.
在带外接收到DM响应消息时，时间戳1和时间戳2字段不得用于延迟测量。
If the Control Code in a DM Response is anything other than 0x1 (Success), the timestamp values in the response MUST NOT be used for purposes of delay measurement. If the Control Code indicates an error condition, or if the response message is invalid, the DM operation MUST be terminated and an appropriate notification to the user generated.
如果DM响应中的控制代码不是0x1（成功），则响应中的时间戳值不得用于延迟测量。如果控制代码指示错误情况，或者如果响应消息无效，则必须终止DM操作并向用户生成适当的通知。
In case either the querier or the responder in a DM transaction is capable of supporting multiple timestamp formats, it is desirable to determine the optimal format for purposes of delay measurement on a particular channel. The procedures for making this determination SHALL be as follows.
在DM事务中的查询器或响应器能够支持多个时间戳格式的情况下，为了在特定信道上进行延迟测量的目的，需要确定最佳格式。作出该决定的程序如下所示。
Upon sending an initial DM Query over a channel, the querier sets the Querier Timestamp Format (QTF) field to its preferred timestamp format.
在通过通道发送初始DM查询时，查询器将查询器时间戳格式（QTF）字段设置为其首选时间戳格式。
Upon receiving any DM Query message, the responder determines whether it is capable of writing timestamps in the format specified by the QTF field. If so, the Responder Timestamp Format (RTF) field is set equal to the QTF field. If not, the RTF field is set equal to the Responder's Preferred Timestamp Format (RPTF) field.
收到任何DM查询消息后，响应程序确定是否能够以QTF字段指定的格式写入时间戳。如果是，则将响应者时间戳格式（RTF）字段设置为等于QTF字段。如果不是，则RTF字段设置为响应者的首选时间戳格式（RPTF）字段。
The process of changing from one timestamp format to another at the responder may result in the Timestamp 1 and Timestamp 4 fields in an in-band DM Response having different formats. If this is the case,
在响应者处从一种时间戳格式改变为另一种时间戳格式的过程可导致带内DM响应中的时间戳1和时间戳4字段具有不同的格式。如果是这样的话,，
the Control Code in the response MUST NOT be set to 0x1 (Success). Unless an error condition has occurred, the Control Code MUST be set to 0x2 (Notification - Data Format Invalid).
响应中的控制代码不得设置为0x1（成功）。除非出现错误情况，否则控制代码必须设置为0x2（通知-数据格式无效）。
Upon receiving a DM Response, the querier knows from the RTF field in the message whether the responder is capable of supporting its preferred timestamp format: if it is, the RTF will be equal to the QTF. The querier also knows the responder's preferred timestamp format from the RPTF field. The querier can then decide whether to retain its current QTF or to change it and repeat the negotiation procedures.
收到DM响应后，查询者从消息中的RTF字段知道响应者是否能够支持其首选时间戳格式：如果能够，RTF将等于QTF。查询者还可以从RPTF字段了解响应者的首选时间戳格式。然后，查询者可以决定是保留其当前QTF还是更改QTF并重复协商过程。
When an implementation supports only one timestamp format, the procedures above reduce to the following simple behavior:
当一个实现只支持一种时间戳格式时，上述过程简化为以下简单行为：
o All DM Queries are transmitted with the same QTF;
o 所有DM查询都使用相同的QTF传输；
o All DM Responses are transmitted with the same RTF, and the RPTF is always set equal to the RTF;
o 所有DM响应都使用相同的RTF传输，并且RPTF始终设置为等于RTF；
o All DM Responses received with RTF not equal to QTF are discarded;
o 所有接收到的RTF不等于QTF的DM响应被丢弃；
o On a unidirectional channel, all DM Queries received with QTF not equal to the supported format are discarded.
o 在单向通道上，所有接收到的QTF不等于支持格式的DM查询都将被丢弃。
The TC field of the LSE corresponding to the channel (e.g., LSP) being measured MUST be set to the value that corresponds to the DS field in the DM message.
与被测量信道（例如，LSP）相对应的LSE TC字段必须设置为与DM消息中DS字段相对应的值。
The combined LM/DM message defined in Section 3.3 allows loss and delay measurement to be carried out simultaneously. This message SHOULD be treated as an LM message that happens to carry additional timestamp data, with the timestamp fields processed as per delay measurement procedures.
第3.3节中定义的组合LM/DM消息允许同时进行损耗和延迟测量。该消息应被视为一条LM消息，该消息碰巧携带额外的时间戳数据，时间戳字段按照延迟测量程序进行处理。
This section summarizes the requirements placed on implementations for capabilities disclosure. The purpose of these requirements is to ensure that end users have a clear understanding of implementation
本节总结了功能公开对实现的要求。这些要求的目的是确保最终用户清楚地了解实施情况
capabilities and characteristics that have a direct impact on how loss and delay measurement mechanisms function in specific situations. Implementations are REQUIRED to state:
直接影响损失和延迟测量机制在特定情况下如何发挥作用的能力和特征。实现需要声明：
o METRICS: Which of the following metrics are supported: packet loss, packet throughput, octet loss, octet throughput, average loss rate, one-way delay, round-trip delay, two-way channel delay, packet delay variation.
o 指标：支持以下哪些指标：数据包丢失、数据包吞吐量、八位字节丢失、八位字节吞吐量、平均丢失率、单向延迟、往返延迟、双向通道延迟、数据包延迟变化。
o MP-LOCATION: The location of loss and delay measurement points with respect to other stages of packet processing, such as queuing.
o MP-LOCATION：与数据包处理的其他阶段（如排队）相关的丢失和延迟测量点的位置。
o CHANNEL-TYPES: The types of channels for which LM and DM are supported, including LSP types, pseudowires, and sections (links).
o 通道类型：支持LM和DM的通道类型，包括LSP类型、伪线和段（链路）。
o QUERY-RATE: The minimum supported query intervals for LM and DM sessions, both in the querier and responder roles.
o QUERY-RATE：查询者和响应者角色中LM和DM会话支持的最小查询间隔。
o LOOP: Whether loopback measurement (Section 2.8) is supported.
o 回路：是否支持回路测量（第2.8节）。
o LM-TYPES: Whether direct or inferred LM is supported, and for the latter, which test protocols or proxy message types are supported.
o LM-TYPES：支持直接LM还是推断LM，对于后者，支持哪些测试协议或代理消息类型。
o LM-COUNTERS: Whether 64-bit counters are supported.
o LM-COUNTERS：是否支持64位计数器。
o LM-ACCURACY: The expected measurement accuracy levels for the supported forms of LM, and the expected impact of exception conditions such as lost and misordered messages.
o LM-准确度：支持的LM形式的预期测量准确度水平，以及异常情况（如丢失和错误排列的消息）的预期影响。
o LM-SYNC: The implementation's behavior in regard to the synchronization conditions discussed in Section 2.9.8.
o LM-SYNC：与第2.9.8节中讨论的同步条件有关的实现行为。
o LM-SCOPE: The supported LM scopes (Sections 2.9.9 and 4.2.8).
o LM-SCOPE：受支持的LM范围（第2.9.9节和第4.2.8节）。
o DM-ACCURACY: The expected measurement accuracy levels for the supported forms of DM.
o DM-精度：支持的DM形式的预期测量精度水平。
o DM-TS-FORMATS: The supported timestamp formats and the extent of support for computation with and reconciliation of different formats.
o DM-TS-FORMATS：支持的时间戳格式以及对不同格式的计算和协调的支持程度。
An MPLS network may be traffic-engineered in such a way that the bandwidth required both for client traffic and for control, management, and OAM traffic is always available. The following congestion considerations therefore apply only when this is not the case.
MPLS网络可以以这样的方式进行流量工程，即客户端流量以及控制、管理和OAM流量所需的带宽始终可用。因此，以下拥塞注意事项仅在情况并非如此时适用。
The proactive generation of Loss Measurement and Delay Measurement messages for purposes of monitoring the performance of an MPLS channel naturally results in a degree of additional load placed on both the network and the terminal nodes of the channel. When configuring such monitoring, operators should be mindful of the overhead involved and should choose transmit rates that do not stress network resources unduly; such choices must be informed by the deployment context. In case of slower links or lower-speed devices, for example, lower Loss Measurement message rates can be chosen, up to the limits noted at the end of Section 2.2.
为了监视MPLS信道的性能，主动生成丢失测量和延迟测量消息自然会导致在信道的网络和终端节点上施加一定程度的额外负载。在配置此类监控时，运营商应注意所涉及的开销，并应选择不会对网络资源造成过度压力的传输速率；这些选择必须由部署上下文通知。例如，对于较慢的链路或较低速度的设备，可选择较低的损耗测量消息速率，直至达到第2.2节末尾所述的限值。
In general, lower measurement message rates place less load on the network at the expense of reduced granularity. For delay measurement, this reduced granularity translates to a greater possibility that the delay associated with a channel temporarily exceeds the expected threshold without detection. For loss measurement, it translates to a larger gap in loss information in case of exceptional circumstances such as lost LM messages or misordered packets.
通常，较低的测量消息速率会以降低粒度为代价降低网络负载。对于延迟测量，这种降低的粒度转化为与信道相关联的延迟在没有检测的情况下暂时超过预期阈值的更大可能性。对于损失测量，在特殊情况下，如丢失LM消息或错误排列的数据包，它会导致损失信息的更大差距。
When carrying out a sustained measurement operation such as an LM operation or continuous proactive DM operation, the querier SHOULD take note of the number of lost measurement messages (queries for which a response is never received) and set a corresponding Measurement Message Loss Threshold. If this threshold is exceeded, the measurement operation SHOULD be suspended so as not to exacerbate the possible congestion condition. This suspension SHOULD be accompanied by an appropriate notification to the user so that the condition can be investigated and corrected.
当执行持续测量操作（如LM操作或连续主动DM操作）时，查询者应注意丢失测量消息的数量（从未收到响应的查询），并设置相应的测量消息丢失阈值。如果超过此阈值，则应暂停测量操作，以免加剧可能的拥塞情况。暂停时，应向用户发出适当的通知，以便调查和纠正情况。
From the receiver perspective, the main consideration is the possibility of receiving an excessive quantity of measurement messages. An implementation SHOULD employ a mechanism such as rate-limiting to guard against the effects of this case.
从接收者的角度来看，主要考虑的是接收过多测量消息的可能性。实现应该使用诸如速率限制之类的机制来防止这种情况的影响。
The measurement protocols described in this document are intended to serve as infrastructure to support a wide range of higher-level monitoring and diagnostic applications, from simple command-line
本文档中描述的测量协议旨在作为基础设施，支持从简单的命令行到更高级别的广泛监控和诊断应用
diagnostic tools to comprehensive network performance monitoring and analysis packages. The specific mechanisms and considerations for protocol configuration, initialization, and reporting thus depend on the nature of the application.
诊断工具，用于全面的网络性能监视和分析软件包。因此，协议配置、初始化和报告的具体机制和注意事项取决于应用程序的性质。
In the case of on-demand diagnostics, the diagnostic application may provide parameters such as the measurement type, the channel, the query rate, and the test duration when initiating the diagnostic; results and exception conditions are then reported directly to the application. The system may discard the statistics accumulated during the test after the results have been reported or retain them to provide a historical measurement record.
在按需诊断的情况下，诊断应用程序可在启动诊断时提供测量类型、通道、查询速率和测试持续时间等参数；然后将结果和异常情况直接报告给应用程序。报告结果后，系统可丢弃试验期间累积的统计数据，或保留这些统计数据以提供历史测量记录。
Alternatively, measurement configuration may be supplied as part of the channel configuration itself in order to support continuous monitoring of the channel's performance characteristics. In this case, the configuration will typically include quality thresholds depending on the service level agreement, the crossing of which will trigger warnings or alarms, and result reporting and exception notification will be integrated into the system-wide network management and reporting framework.
或者，测量配置可作为信道配置本身的一部分提供，以支持信道性能特性的连续监测。在这种情况下，配置通常包括质量阈值，具体取决于服务级别协议，超过该阈值将触发警告或警报，结果报告和异常通知将集成到系统范围的网络管理和报告框架中。
This document describes procedures for the measurement of performance metrics over a pre-existing MPLS path (a pseudowire, LSP, or section). As such, it assumes that a node involved in a measurement operation has previously verified the integrity of the path and the identity of the far end using existing MPLS mechanisms such as Bidirectional Forwarding Detection (BFD) [RFC5884]; tools, techniques, and considerations for securing MPLS paths are discussed in detail in [RFC5920].
本文档描述了在预先存在的MPLS路径（伪线、LSP或段）上测量性能指标的过程。因此，它假设参与测量操作的节点先前已经使用诸如双向转发检测（BFD）[RFC5884]之类的现有MPLS机制来验证路径的完整性和远端的身份；[RFC5920]详细讨论了保护MPLS路径的工具、技术和注意事项。
When such mechanisms are not available, and where security of the measurement operation is a concern, reception of Generic Associated Channel messages with the Channel Types specified in this document SHOULD be disabled. Implementations MUST provide the ability to disable these protocols on a per-Channel-Type basis.
当此类机制不可用时，如果测量操作的安全性受到关注，则应禁用接收具有本文件中指定信道类型的通用相关信道消息。实现必须能够在每个通道类型的基础上禁用这些协议。
Even when the identity of the far end has been verified, the measurement protocols remain vulnerable to injection and man-in-the-middle attacks. The impact of such an attack would be to compromise the quality of performance measurements on the affected path. An attacker positioned to disrupt these measurements is, however, capable of causing much greater damage by disrupting far more critical elements of the network such as the network control plane or user traffic flows. At worst, a disruption of the measurement protocols would interfere with the monitoring of the performance
即使远端的身份已经得到验证，测量协议仍然容易受到注入攻击和中间人攻击。这种攻击的影响是影响受影响路径上性能度量的质量。然而，定位为破坏这些测量的攻击者能够通过破坏网络中更关键的元素（如网络控制平面或用户流量）造成更大的破坏。在最坏的情况下，测量协议的中断会干扰性能的监控
aspects of the service level agreement associated with the path; the existence of such a disruption would imply that a serious breach of basic path integrity had already occurred.
与路径相关联的服务级别协议的各个方面；这种中断的存在意味着基本路径完整性已经受到严重破坏。
If desired, such attacks can be mitigated by performing basic validation and sanity checks, at the querier, of the counter or timestamp fields in received measurement response messages. The minimal state associated with these protocols also limits the extent of measurement disruption that can be caused by a corrupt or invalid message to a single query/response cycle.
如果需要，可以通过在查询器处对接收到的测量响应消息中的计数器或时间戳字段执行基本验证和健全性检查来缓解此类攻击。与这些协议相关的最小状态还将损坏或无效消息可能导致的测量中断程度限制在单个查询/响应周期内。
Cryptographic mechanisms capable of signing or encrypting the contents of the measurement packets without degrading the measurement performance are not currently available. In light of the preceding discussion, the absence of such cryptographic mechanisms does not raise significant security issues.
目前还没有能够在不降低测量性能的情况下对测量数据包的内容进行签名或加密的加密机制。根据前面的讨论，缺少这种加密机制不会引起重大的安全问题。
Users concerned with the security of out-of-band responses over IP networks SHOULD employ suitable security mechanisms such as IPsec [RFC4301] to protect the integrity of the return path.
关心IP网络带外响应安全性的用户应采用适当的安全机制，如IPsec[RFC4301]，以保护返回路径的完整性。
Per this document, IANA has completed the following actions:
根据本文件，IANA已完成以下行动：
o Allocation of Channel Types in the "PW Associated Channel Type" registry
o 在“PW关联通道类型”注册表中分配通道类型
o Creation of a "Measurement Timestamp Type" registry
o 创建“测量时间戳类型”注册表
o Creation of an "MPLS Loss/Delay Measurement Control Code" registry
o 创建“MPLS丢失/延迟测量控制代码”注册表
o Creation of an "MPLS Loss/Delay Measurement Type-Length-Value (TLV) Object" registry
o 创建“MPLS丢失/延迟测量类型长度值（TLV）对象”注册表
As per the IANA considerations in [RFC5586], IANA has allocated the following Channel Types in the "PW Associated Channel Type" registry:
根据[RFC5586]中的IANA注意事项，IANA已在“PW关联通道类型”注册表中分配了以下通道类型：
Value Description TLV Follows Reference
------ ---------------------------------------- ----------- ---------
0x000A MPLS Direct Loss Measurement (DLM) No RFC 6374
0x000B MPLS Inferred Loss Measurement (ILM) No RFC 6374
0x000C MPLS Delay Measurement (DM) No RFC 6374
0x000D MPLS Direct Loss and Delay Measurement No RFC 6374
(DLM+DM)
0x000E MPLS Inferred Loss and Delay Measurement No RFC 6374
(ILM+DM)
Value Description TLV Follows Reference
------ ---------------------------------------- ----------- ---------
0x000A MPLS Direct Loss Measurement (DLM) No RFC 6374
0x000B MPLS Inferred Loss Measurement (ILM) No RFC 6374
0x000C MPLS Delay Measurement (DM) No RFC 6374
0x000D MPLS Direct Loss and Delay Measurement No RFC 6374
(DLM+DM)
0x000E MPLS Inferred Loss and Delay Measurement No RFC 6374
(ILM+DM)
IANA has created a new "Measurement Timestamp Type" registry, with format and initial allocations as follows:
IANA创建了一个新的“测量时间戳类型”注册表，其格式和初始分配如下：
Type Description Size in Bits Reference
---- ----------------------------------------- ------------ ---------
0 Null Timestamp 64 RFC 6374
1 Sequence Number 64 RFC 6374
2 Network Time Protocol version 4 64-bit 64 RFC 6374
Timestamp
3 Truncated IEEE 1588v2 PTP Timestamp 64 RFC 6374
Type Description Size in Bits Reference
---- ----------------------------------------- ------------ ---------
0 Null Timestamp 64 RFC 6374
1 Sequence Number 64 RFC 6374
2 Network Time Protocol version 4 64-bit 64 RFC 6374
Timestamp
3 Truncated IEEE 1588v2 PTP Timestamp 64 RFC 6374
The range of the Type field is 0-15.
类型字段的范围为0-15。
The allocation policy for this registry is IETF Review.
此注册表的分配策略为IETF Review。
IANA has created a new "MPLS Loss/Delay Measurement Control Code" registry. This registry is divided into two separate parts, one for Query Codes and the other for Response Codes, with formats and initial allocations as follows:
IANA创建了一个新的“MPLS丢失/延迟测量控制代码”注册表。此注册表分为两个独立部分，一个用于查询代码，另一个用于响应代码，格式和初始分配如下：
Query Codes
查询代码
Code Description Reference
---- ------------------------------ ---------
0x0 In-band Response Requested RFC 6374
0x1 Out-of-band Response Requested RFC 6374
0x2 No Response Requested RFC 6374
Code Description Reference
---- ------------------------------ ---------
0x0 In-band Response Requested RFC 6374
0x1 Out-of-band Response Requested RFC 6374
0x2 No Response Requested RFC 6374
Response Codes
响应代码
Code Description Reference
---- ----------------------------------- ---------
0x0 Reserved RFC 6374
0x1 Success RFC 6374
0x2 Data Format Invalid RFC 6374
0x3 Initialization in Progress RFC 6374
0x4 Data Reset Occurred RFC 6374
0x5 Resource Temporarily Unavailable RFC 6374
0x10 Unspecified Error RFC 6374
0x11 Unsupported Version RFC 6374
0x12 Unsupported Control Code RFC 6374
0x13 Unsupported Data Format RFC 6374
0x14 Authentication Failure RFC 6374
0x15 Invalid Destination Node Identifier RFC 6374
0x16 Connection Mismatch RFC 6374
0x17 Unsupported Mandatory TLV Object RFC 6374
0x18 Unsupported Query Interval RFC 6374
0x19 Administrative Block RFC 6374
0x1A Resource Unavailable RFC 6374
0x1B Resource Released RFC 6374
0x1C Invalid Message RFC 6374
0x1D Protocol Error RFC 6374
Code Description Reference
---- ----------------------------------- ---------
0x0 Reserved RFC 6374
0x1 Success RFC 6374
0x2 Data Format Invalid RFC 6374
0x3 Initialization in Progress RFC 6374
0x4 Data Reset Occurred RFC 6374
0x5 Resource Temporarily Unavailable RFC 6374
0x10 Unspecified Error RFC 6374
0x11 Unsupported Version RFC 6374
0x12 Unsupported Control Code RFC 6374
0x13 Unsupported Data Format RFC 6374
0x14 Authentication Failure RFC 6374
0x15 Invalid Destination Node Identifier RFC 6374
0x16 Connection Mismatch RFC 6374
0x17 Unsupported Mandatory TLV Object RFC 6374
0x18 Unsupported Query Interval RFC 6374
0x19 Administrative Block RFC 6374
0x1A Resource Unavailable RFC 6374
0x1B Resource Released RFC 6374
0x1C Invalid Message RFC 6374
0x1D Protocol Error RFC 6374
IANA has indicated that the values 0x0 - 0xF in the Response Code section are reserved for non-error response codes.
IANA指出，响应代码部分中的值0x0-0xF是为非错误响应代码保留的。
The range of the Code field is 0 - 255.
代码字段的范围为0-255。
The allocation policy for this registry is IETF Review.
此注册表的分配策略为IETF Review。
IANA has created a new "MPLS Loss/Delay Measurement TLV Object" registry, with format and initial allocations as follows:
IANA创建了一个新的“MPLS丢失/延迟测量TLV对象”注册表，其格式和初始分配如下：
Type Description Reference
---- --------------------------------- ---------
0 Padding - copy in response RFC 6374
1 Return Address RFC 6374
2 Session Query Interval RFC 6374
3 Loopback Request RFC 6374
127 Experimental use RFC 6374
128 Padding - do not copy in response RFC 6374
129 Destination Address RFC 6374
130 Source Address RFC 6374
255 Experimental use RFC 6374
Type Description Reference
---- --------------------------------- ---------
0 Padding - copy in response RFC 6374
1 Return Address RFC 6374
2 Session Query Interval RFC 6374
3 Loopback Request RFC 6374
127 Experimental use RFC 6374
128 Padding - do not copy in response RFC 6374
129 Destination Address RFC 6374
130 Source Address RFC 6374
255 Experimental use RFC 6374
IANA has indicated that Types 0-127 are classified as Mandatory, and that Types 128-255 are classified as Optional.
IANA指出，类型0-127被归类为强制性，类型128-255被归类为可选。
The range of the Type field is 0 - 255.
类型字段的范围为0-255。
The allocation policy for this registry is IETF Review.
此注册表的分配策略为IETF Review。
The authors wish to thank the many participants of the MPLS working group who provided detailed review and feedback on this document. The authors offer special thanks to Alexander Vainshtein, Loa Andersson, and Hiroyuki Takagi for many helpful thoughts and discussions, to Linda Dunbar for the idea of using LM messages for throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and Ben Mack-Crane for their valuable comments.
作者希望感谢MPLS工作组的许多参与者，他们对本文件提供了详细的审查和反馈。作者特别感谢Alexander Vainstein、Loa Andersson和Hiroyuki Takagi提出的许多有益的想法和讨论，感谢Linda Dunbar提出的使用LM消息进行吞吐量测量的想法，感谢Ben Niven Jenkins、Marc Lasserre和Ben Mack Crane提出的宝贵意见。
[IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", March 2008.
[IEEE1588]IEEE，“1588-2008网络测量和控制系统精密时钟同步协议IEEE标准”，2008年3月。
[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月。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Vigoureux，M.，和S.Bryant，“MPLS通用关联信道”，RFC 55862009年6月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[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月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的往返延迟度量”，RFC 2681，1999年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]Grossman，D.“区分服务的新术语和澄清”，RFC 3260，2002年4月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.和P.Pate，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4656]Shalunov，S.，Teitelbaum，B.，Karp，A.，Boote，J.，和M.Zekauskas，“单向主动测量协议（OWAMP）”，RFC 46562006年9月。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.
[RFC4928]Swallow，G.，Bryant，S.和L.Andersson，“避免MPLS网络中的等成本多路径处理”，BCP 128，RFC 4928，2007年6月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Minei，I.，和B.Thomas，“LDP规范”，RFC 5036，2007年10月。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008.
[RFC5357]Hedayat，K.，Krzanowski，R.，Morton，A.，Yum，K.，和J.Babiarz，“双向主动测量协议（TWAMP）”，RFC 5357，2008年10月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481]Morton，A.和B.Claise，“数据包延迟变化适用性声明”，RFC 54812009年3月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 58842010年6月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921]Bocci，M.，Bryant，S.，Frost，D.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年7月。
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC5960]Frost，D.，Bryant，S.，和M.Bocci，“MPLS传输配置文件数据平面架构”，RFC 59602010年8月。
[RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011.
[RFC6375]Frost，D.，Ed.和S.Bryant，Ed.，“基于MPLS的传输网络的数据包丢失和延迟测量模式”，RFC 63752011年9月。
[Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and Mechanisms for Ethernet based Networks", February 2008.
[Y.1731]ITU-T建议Y.1731，“基于以太网的网络的OAM功能和机制”，2008年2月。
This document initially proposed the Network Time Protocol (NTP) timestamp format as the mandatory default, as this is the normal default timestamp in IETF protocols and thus would seem the "natural" choice. However, a number of considerations have led instead to the specification of the truncated IEEE 1588 Precision Time Protocol (PTP) timestamp as the default. NTP has not gained traction in industry as the protocol of choice for high-quality timing infrastructure, whilst IEEE 1588 PTP has become the de facto time transfer protocol in networks that are specially engineered to provide high-accuracy time distribution service. The PTP timestamp format is also the ITU-T format of choice for packet transport networks, which may rely on MPLS protocols. Applications such as one-way delay measurement need the best time service available, and converting between the NTP and PTP timestamp formats is not a trivial transformation, particularly when it is required that this be done in real time without loss of accuracy.
本文件最初建议将网络时间协议（NTP）时间戳格式作为强制默认格式，因为这是IETF协议中的正常默认时间戳，因此似乎是“自然”选择。然而，许多考虑因素导致将截断的IEEE 1588精确时间协议（PTP）时间戳指定为默认值。NTP作为高质量定时基础设施的首选协议，在工业上尚未得到重视，而IEEE 1588 PTP已成为专门设计用于提供高精度时间分配服务的网络中事实上的时间传输协议。PTP时间戳格式也是包传输网络选择的ITU-T格式，它可能依赖于MPLS协议。诸如单向延迟测量之类的应用需要可用的最佳时间服务，并且NTP和PTP时间戳格式之间的转换不是一个简单的转换，特别是当需要在不损失准确性的情况下实时进行转换时。
The truncated IEEE 1588 PTP format specified in this document is considered to provide a more than adequate wrap time and greater time resolution than it is expected will be needed for the operational lifetime of this protocol. By truncating the timestamp at both the high and low order bits, the protocol achieves a worthwhile reduction in system resources.
本文件中规定的截断IEEE 1588 PTP格式被认为提供了比本协议运行寿命所需的更充分的包装时间和更高的时间分辨率。通过在高阶和低阶位截断时间戳，该协议实现了系统资源的有效减少。
Authors' Addresses
作者地址
Dan Frost Cisco Systems
丹弗罗斯特思科系统公司
EMail: danfrost@cisco.com
EMail: danfrost@cisco.com
Stewart Bryant Cisco Systems
思科系统公司
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com