Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7456 Marvell
Category: Standards Track T. Senevirathne
ISSN: 2070-1721 S. Salam
D. Kumar
Cisco
D. Eastlake 3rd
Huawei
March 2015
Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7456 Marvell
Category: Standards Track T. Senevirathne
ISSN: 2070-1721 S. Salam
D. Kumar
Cisco
D. Eastlake 3rd
Huawei
March 2015
Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)
大量链路透明互连中的损耗和延迟测量（TRILL）
Abstract
摘要
Performance Monitoring (PM) is a key aspect of Operations, Administration, and Maintenance (OAM). It allows network operators to verify the Service Level Agreement (SLA) provided to customers and to detect network anomalies. This document specifies mechanisms for Loss Measurement and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) networks.
性能监视（PM）是操作、管理和维护（OAM）的一个关键方面。它允许网络运营商验证提供给客户的服务级别协议（SLA），并检测网络异常。本文件规定了大量链路透明互连（TRILL）网络中损耗测量和延迟测量的机制。
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/rfc7456.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7456.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in this Document ...............................4
2.1. Key Words ..................................................4
2.2. Definitions ................................................4
2.3. Abbreviations ..............................................5
3. Loss and Delay Measurement in the TRILL Architecture ............6
3.1. Performance Monitoring Granularity .........................6
3.2. One-Way vs. Two-Way Performance Monitoring .................6
3.2.1. One-Way Performance Monitoring ......................7
3.2.2. Two-Way Performance Monitoring ......................7
3.3. Point-to-Point vs. Point-to-Multipoint PM ..................8
4. Loss Measurement ................................................8
4.1. One-Way Loss Measurement ...................................8
4.1.1. 1SL Message Transmission ............................9
4.1.2. 1SL Message Reception ..............................10
4.2. Two-Way Loss Measurement ..................................11
4.2.1. SLM Message Transmission ...........................12
4.2.2. SLM Message Reception ..............................12
4.2.3. SLR Message Reception ..............................13
5. Delay Measurement ..............................................14
5.1. One-Way Delay Measurement .................................14
5.1.1. 1DM Message Transmission ...........................15
5.1.2. 1DM Message Reception ..............................16
5.2. Two-Way Delay Measurement .................................16
5.2.1. DMM Message Transmission ...........................17
5.2.2. DMM Message Reception ..............................17
5.2.3. DMR Message Reception ..............................18
1. Introduction ....................................................3
2. Conventions Used in this Document ...............................4
2.1. Key Words ..................................................4
2.2. Definitions ................................................4
2.3. Abbreviations ..............................................5
3. Loss and Delay Measurement in the TRILL Architecture ............6
3.1. Performance Monitoring Granularity .........................6
3.2. One-Way vs. Two-Way Performance Monitoring .................6
3.2.1. One-Way Performance Monitoring ......................7
3.2.2. Two-Way Performance Monitoring ......................7
3.3. Point-to-Point vs. Point-to-Multipoint PM ..................8
4. Loss Measurement ................................................8
4.1. One-Way Loss Measurement ...................................8
4.1.1. 1SL Message Transmission ............................9
4.1.2. 1SL Message Reception ..............................10
4.2. Two-Way Loss Measurement ..................................11
4.2.1. SLM Message Transmission ...........................12
4.2.2. SLM Message Reception ..............................12
4.2.3. SLR Message Reception ..............................13
5. Delay Measurement ..............................................14
5.1. One-Way Delay Measurement .................................14
5.1.1. 1DM Message Transmission ...........................15
5.1.2. 1DM Message Reception ..............................16
5.2. Two-Way Delay Measurement .................................16
5.2.1. DMM Message Transmission ...........................17
5.2.2. DMM Message Reception ..............................17
5.2.3. DMR Message Reception ..............................18
6. Packet Formats .................................................19
6.1. TRILL OAM Encapsulation ...................................19
6.2. Loss Measurement Packet Formats ...........................21
6.2.1. Counter Format .....................................21
6.2.2. 1SL Packet Format ..................................21
6.2.3. SLM Packet Format ..................................22
6.2.4. SLR Packet Format ..................................23
6.3. Delay Measurement Packet Formats ..........................24
6.3.1. Timestamp Format ...................................24
6.3.2. 1DM Packet Format ..................................24
6.3.3. DMM Packet Format ..................................25
6.3.4. DMR Packet Format ..................................26
6.4. OpCode Values .............................................27
7. Performance Monitoring Process .................................28
8. Security Considerations ........................................29
9. References .....................................................29
9.1. Normative References ......................................29
9.2. Informative References ....................................30
Acknowledgments ...................................................31
Authors' Addresses ................................................32
6. Packet Formats .................................................19
6.1. TRILL OAM Encapsulation ...................................19
6.2. Loss Measurement Packet Formats ...........................21
6.2.1. Counter Format .....................................21
6.2.2. 1SL Packet Format ..................................21
6.2.3. SLM Packet Format ..................................22
6.2.4. SLR Packet Format ..................................23
6.3. Delay Measurement Packet Formats ..........................24
6.3.1. Timestamp Format ...................................24
6.3.2. 1DM Packet Format ..................................24
6.3.3. DMM Packet Format ..................................25
6.3.4. DMR Packet Format ..................................26
6.4. OpCode Values .............................................27
7. Performance Monitoring Process .................................28
8. Security Considerations ........................................29
9. References .....................................................29
9.1. Normative References ......................................29
9.2. Informative References ....................................30
Acknowledgments ...................................................31
Authors' Addresses ................................................32
TRILL [TRILL] is a protocol for transparent least-cost routing, where Routing Bridges (RBridges) route traffic to their destination based on least cost, using a TRILL encapsulation header with a hop count.
TRILL[TRILL]是一种用于透明最低成本路由的协议，其中路由桥（RBridge）使用带有跳数的TRILL封装报头，基于最低成本将流量路由到其目的地。
Operations, Administration, and Maintenance [OAM] is a set of tools for detecting, isolating, and reporting connection failures and performance degradation. Performance Monitoring (PM) is a key aspect of OAM. PM allows network operators to detect and debug network anomalies and incorrect behavior. PM consists of two main building blocks: Loss Measurement and Delay Measurement. PM may also include other derived metrics such as Packet Delivery Rate, and Inter-Frame Delay Variation.
操作、管理和维护[OAM]是一组用于检测、隔离和报告连接故障和性能下降的工具。性能监视（PM）是OAM的一个关键方面。PM允许网络运营商检测和调试网络异常和错误行为。PM由两个主要构件组成：损耗测量和延迟测量。PM还可以包括其他衍生度量，例如分组交付速率和帧间延迟变化。
The requirements of OAM in TRILL networks are defined in [OAM-REQ], and the TRILL OAM framework is described in [OAM-FRAMEWK]. These two documents also highlight the main requirements in terms of Performance Monitoring.
TRILL网络中的OAM要求在[OAM-REQ]中定义，TRILL OAM框架在[OAM-FRAMEWK]中描述。这两份文件还强调了性能监控方面的主要要求。
This document defines protocols for Loss Measurement and for Delay Measurement in TRILL networks. These protocols are based on the Performance Monitoring functionality defined in ITU-T G.8013/Y.1731 [Y.1731-2013].
本文件定义了TRILL网络中损耗测量和延迟测量的协议。这些协议基于ITU-T G.8013/Y.1731[Y.1731-2013]中定义的性能监控功能。
o Loss Measurement: the Loss Measurement protocol measures packet loss between two RBridges. The measurement is performed by sending a set of synthetic packets and counting the number of packets transmitted and received during the test. The frame loss is calculated by comparing the numbers of transmitted and received packets. This provides a statistical estimate of the packet loss between the involved RBridges, with a margin of error that can be controlled by varying the number of transmitted synthetic packets. This document does not define procedures for packet loss computation based on counting user data for the reasons given in Section 5.1 of [OAM-FRAMEWK].
o 丢失测量：丢失测量协议测量两个RBridge之间的数据包丢失。通过发送一组合成数据包并计算测试期间发送和接收的数据包数量来执行测量。通过比较发送和接收的数据包的数量来计算帧丢失。这提供了所涉及的rbridge之间的分组丢失的统计估计，具有可以通过改变传输的合成分组的数量来控制的误差幅度。由于[OAM-FRAMEWK]第5.1节给出的原因，本文件未定义基于计算用户数据的丢包计算程序。
o Delay Measurement: the Delay Measurement protocol measures the packet delay and packet delay variation between two RBridges. The measurement is performed using timestamped OAM messages.
o 延迟测量：延迟测量协议测量两个RBridge之间的数据包延迟和数据包延迟变化。使用时间戳OAM消息执行测量。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
The requirement level of PM in [OAM-REQ] is 'SHOULD'. Nevertheless, this memo uses the entire range of requirement levels, including 'MUST'; the requirements in this memo are to be read as 'A MEP (Maintenance End Point) that implements TRILL PM MUST/SHOULD/MAY/...'.
[OAM-REQ]中PM的要求级别为“应”。尽管如此，本备忘录使用了整个需求级别范围，包括“必须”；本备忘录中的要求应理解为“实施TRILL PM必须/应该/可能/…”的MEP（维护终点）。
o One-way packet delay (based on [IPPM-1DM]) - the time elapsed from the start of transmission of the first bit of a packet by an RBridge until the reception of the last bit of the packet by the remote RBridge.
o 单向数据包延迟（基于[IPPM-1DM]）—从RBridge开始传输数据包的第一位到远程RBridge接收数据包的最后一位所经过的时间。
o Two-way packet delay (based on [IPPM-2DM]) - the time elapsed from the start of transmission of the first bit of a packet from the local RBridge, receipt of the packet at the remote RBridge, the transmission of a response packet from the remote RBridge back to the local RBridge, and receipt of the last bit of that response packet by the local RBridge.
o 双向数据包延迟（基于[IPPM-2DM]）—从开始从本地RBridge传输数据包的第一位、在远程RBridge接收数据包、从远程RBridge向本地RBridge传输响应数据包所经过的时间，以及本地RBridge接收该响应包的最后一位。
o Packet loss (based on [IPPM-Loss] - the number of packets sent by a source RBridge and not received by the destination RBridge. In the context of this document, packet loss is measured at a specific probe instance and a specific observation period. As in
o Packet loss（基于[IPPM loss]——源RBridge发送但目的RBridge未接收到的数据包数量。在本文档中，数据包丢失是在特定探测实例和特定观察期进行测量的。如
[Y.1731-2013], this document distinguishes between near-end and far-end packet loss. Note that this semantic distinction specifies the direction of packet loss but does not affect the nature of the packet loss metric, which is defined in [IPPM-Loss].
[Y.1731-2013]，本文件区分近端和远端数据包丢失。请注意，这种语义区别指定了数据包丢失的方向，但不影响[IPPM loss]中定义的数据包丢失度量的性质。
o Far-end packet loss - the number of packets lost on the path from the local RBridge to the remote RBridge in a specific probe instance and a specific observation period.
o 远端数据包丢失-在特定探测实例和特定观察期内，从本地RBridge到远程RBridge的路径上丢失的数据包数。
o Near-end packet loss - the number of packets lost on the path from the remote RBridge to the local RBridge in a specific probe instance and a specific observation period.
o 近端数据包丢失-在特定探测实例和特定观察期内，从远程RBridge到本地RBridge的路径上丢失的数据包数。
1DM One-way Delay Measurement
1DM单向延迟测量
1SL One-way Synthetic Loss Measurement
1SL单向综合损耗测量
DMM Delay Measurement Message
DMM延迟测量报文
DMR Delay Measurement Reply
DMR延迟测量应答
DoS Denial of Service
拒绝服务
FGL Fine-Grained Label [FGL]
FGL细粒度标签[FGL]
MD Maintenance Domain
MD维护域
MD-L Maintenance Domain Level
MD-L维护域级别
MEP Maintenance End Point
MEP维护终点
MIP Maintenance Intermediate Point
MIP维护中间点
MP Maintenance Point
MP维修点
OAM Operations, Administration, and Maintenance [OAM]
OAM操作、管理和维护[OAM]
PM Performance Monitoring
PM性能监测
SLM Synthetic Loss Measurement Message
合成损耗测量报文
SLR Synthetic Loss Measurement Reply
单反合成损耗测量应答
TLV Type-Length-Value
TLV类型长度值
TRILL Transparent Interconnection of Lots of Links [TRILL]
大量链路的TRILL透明互连[TRILL]
As described in [OAM-FRAMEWK], OAM protocols in a TRILL campus operate over two types of Maintenance Points (MPs): Maintenance End Points (MEPs) and Maintenance Intermediate Points (MIPs).
如[OAM-FRAMEWK]所述，TRILL校园中的OAM协议在两种类型的维护点（MP）上运行：维护端点（MEP）和维护中间点（MIP）。
+-------+ +-------+ +-------+
| | | | | |
| RB1 |<===>| RB3 |<===>| RB2 |
| | | | | |
+-------+ +-------+ +-------+
MEP MIP MEP
+-------+ +-------+ +-------+
| | | | | |
| RB1 |<===>| RB3 |<===>| RB2 |
| | | | | |
+-------+ +-------+ +-------+
MEP MIP MEP
Figure 1: Maintenance Points in a TRILL Campus
图1:TRILL校园中的维护点
Performance Monitoring (PM) allows a MEP to perform Loss and Delay Measurements on any other MEP in the campus. Performance Monitoring is performed in the context of a specific Maintenance Domain (MD).
性能监控（PM）允许MEP对校园内的任何其他MEP执行损耗和延迟测量。性能监控在特定维护域（MD）的上下文中执行。
The PM functionality defined in this document is not applicable to MIPs.
本文档中定义的PM功能不适用于MIPs。
As defined in [OAM-FRAMEWK], PM can be applied at three levels of granularity: Network, Service, and Flow.
正如[OAM-FRAMEWK]中所定义的，PM可以应用于三个粒度级别：网络、服务和流。
o Network-level PM: the PM protocol is run over a dedicated test VLAN or FGL [FGL].
o 网络级PM：PM协议在专用测试VLAN或FGL[FGL]上运行。
o Service-level PM: the PM protocol is used to perform measurements of actual user VLANs or FGLs.
o 服务级别PM：PM协议用于执行实际用户VLAN或FGL的测量。
o Flow-level PM: the PM protocol is used to perform measurements on a per-flow basis. A flow, as defined in [OAM-REQ], is a set of packets that share the same path and per-hop behavior (such as priority). As defined in [OAM-FRAMEWK], flow-based monitoring uses a Flow Entropy field that resides at the beginning of the OAM packet header (see Section 6.1) and mimics the forwarding behavior of the monitored flow.
o 流量级别PM：PM协议用于在每个流量的基础上执行测量。[OAM-REQ]中定义的流是共享相同路径和每跳行为（如优先级）的一组数据包。如[OAM-FRAMEWK]中所定义，基于流的监控使用位于OAM数据包头开头的流熵字段（见第6.1节），并模拟被监控流的转发行为。
Paths in a TRILL network are not necessarily symmetric, that is, a packet sent from RB1 to RB2 does not necessarily traverse the same set of RBridges or links as a packet sent from RB2 to RB1. Even within a given flow, packets from RB1 to RB2 do not necessarily traverse the same path as packets from RB2 to RB1.
TRILL网络中的路径不一定对称，即，从RB1发送到RB2的分组不一定与从RB2发送到RB1的分组穿过相同的rbridge或链路集。即使在给定的流中，从RB1到RB2的数据包也不一定要通过与从RB2到RB1的数据包相同的路径。
In one-way PM, RB1 sends PM messages to RB2, allowing RB2 to monitor the performance on the path from RB1 to RB2.
在单向PM中，RB1向RB2发送PM消息，允许RB2监视从RB1到RB2的路径上的性能。
A MEP that implements TRILL PM SHOULD support one-way Performance Monitoring. A MEP that implements TRILL PM SHOULD support both the PM functionality of the sender, RB1, and the PM functionality of the receiver, RB2.
实现TRILL PM的MEP应支持单向性能监控。实现TRILL PM的MEP应同时支持发送方RB1的PM功能和接收方RB2的PM功能。
One-way PM can be applied either proactively or on-demand, although the more typical scenario is the proactive mode, where RB1 and RB2 periodically transmit PM messages to each other, allowing each of them to monitor the performance on the incoming path from the peer MEP.
单向PM可以主动或按需应用，尽管更典型的场景是主动模式，其中RB1和RB2定期相互发送PM消息，允许它们中的每一个监控来自对等MEP的传入路径上的性能。
In two-way PM, a sender, RB1, sends PM messages to a reflector, RB2, and RB2 responds to these messages, allowing RB1 to monitor the performance of:
在双向PM中，发送方RB1向反射器RB2发送PM消息，RB2响应这些消息，允许RB1监控以下各项的性能：
o The path from RB1 to RB2.
o 从RB1到RB2的路径。
o The path from RB2 to RB1.
o 从RB2到RB1的路径。
o The two-way path from RB1 to RB2, and back to RB1.
o 从RB1到RB2再返回RB1的双向路径。
Note that in some cases it may be interesting for RB1 to monitor only the path from RB1 to RB2. Two-way PM allows the sender, RB1, to monitor the path from RB1 to RB2, as opposed to one-way PM (Section 3.2.1), which allows the receiver, RB2, to monitor this path.
请注意，在某些情况下，RB1可能只监视从RB1到RB2的路径。双向PM允许发送方RB1监控从RB1到RB2的路径，而单向PM（第3.2.1节）允许接收方RB2监控该路径。
A MEP that implements TRILL PM MUST support two-way PM. A MEP that implements TRILL PM MUST support both the sender and the reflector PM functionality.
实现TRILL PM的MEP必须支持双向PM。实现TRILL PM的MEP必须同时支持发送器和反射器PM功能。
As described in Section 3.1, flow-based PM uses the Flow Entropy field as one of the parameters that identify a flow. In two-way PM, the Flow Entropy of the path from RB1 to RB2 is typically different from the Flow Entropy of the path from RB2 to RB1. This document uses the Reflector Entropy TLV [TRILL-FM], which allows the sender to specify the Flow Entropy value to be used in the response message.
如第3.1节所述，基于流量的PM使用流熵场作为识别流量的参数之一。在双向PM中，从RB1到RB2的路径的流熵通常不同于从RB2到RB1的路径的流熵。本文件使用反射熵TLV[TRILL-FM]，允许发送方指定响应消息中使用的流量熵值。
Two-way PM can be applied either proactively or on-demand.
双向PM可主动或按需应用。
PM can be applied either as a point-to-point measurement protocol, or as a point-to-multi-point measurement protocol.
PM既可以作为点对点测量协议应用，也可以作为点对多点测量协议应用。
The point-to-point approach measures the performance between two RBridges using unicast PM messages.
点到点方法使用单播PM消息测量两个RBridge之间的性能。
In the point-to-multipoint approach, an RBridge RB1 sends PM messages to multiple RBridges using multicast messages. The reflectors (in two-way PM) respond to RB1 using unicast messages. To protect against reply storms, the reflectors MUST send the response messages after a random delay in the range of 0 to 2 seconds. This ensures that the responses are staggered in time and that the initiating RBridge is not overwhelmed with responses. Moreover, an RBridge Scope TLV [TRILL-FM] can be used to limit the set of RBridges from which a response is expected, thus reducing the impact of potential response bursts.
在点对多点方法中，RBridge RB1使用多播消息向多个RBridge发送PM消息。反射器（双向PM）使用单播消息响应RB1。为了防止回复风暴，反射器必须在0到2秒的随机延迟后发送响应消息。这确保了响应在时间上是交错的，并且启动RBridge不会被响应淹没。此外，RBridge Scope TLV[TRILL-FM]可用于限制预期响应的RBridge集合，从而减少潜在响应突发的影响。
The Loss Measurement protocol has two modes of operation: one-way Loss Measurement and two-way Loss Measurement.
损耗测量协议有两种操作模式：单向损耗测量和双向损耗测量。
Note: The terms 'one-way' and 'two-way' Loss Measurement should not be confused with the terms 'single-ended' and 'dual-ended' Loss Measurement used in [Y.1731-2013]. As defined in Section 3.2, the terms 'one-way' and 'two-way' specify whether the protocol monitors performance on one direction or on both directions. The terms 'single-ended' and 'dual-ended', on the other hand, describe whether the protocol is asymmetric or symmetric, respectively.
注：术语“单向”和“双向”损失测量不应与[Y.1731-2013]中使用的术语“单端”和“双端”损失测量混淆。如第3.2节所定义，术语“单向”和“双向”指定协议是在一个方向上还是在两个方向上监控性能。另一方面，术语“单端”和“双端”分别描述协议是不对称的还是对称的。
One-way Loss Measurement measures the one-way packet loss from one MEP to another. The loss ratio is measured using a set of One-way Synthetic Loss Measurement (1SL) messages. The packet format of the 1SL message is specified in Section 6.2.2. Figure 2 illustrates a one-way Loss Measurement message exchange.
单向丢失测量测量从一个MEP到另一个MEP的单向数据包丢失。使用一组单向合成损耗测量（1SL）信息测量损耗率。第6.2.2节规定了1SL报文的数据包格式。图2说明了单向损耗测量消息交换。
TXp TXc
Sender --------------------------------------
\ \
\ 1SL . . . \ 1SL
\ \
\/ \/
Receiver --------------------------------------
RXp RXc
TXp TXc
Sender --------------------------------------
\ \
\ 1SL . . . \ 1SL
\ \
\/ \/
Receiver --------------------------------------
RXp RXc
Figure 2: One-Way Loss Measurement
图2：单向损耗测量
The one-way Loss Measurement procedure uses a set of 1SL messages to measure the packet loss. The figure shows two non-consecutive messages from the set.
单向丢失测量程序使用一组1SL消息来测量数据包丢失。该图显示了集合中的两条非连续消息。
The sender maintains a counter of transmitted 1SL messages, and includes the value of this counter, TX, in each 1SL message it transmits. The receiver maintains a counter of received 1SL messages, RX, and can calculate the loss by comparing its counter values to the counter values received in the 1SL messages.
发送方维护一个已发送1SL消息的计数器，并在其发送的每个1SL消息中包含该计数器的值TX。接收机维护接收到的1SL消息的计数器RX，并可通过将其计数器值与1SL消息中接收到的计数器值进行比较来计算损耗。
In Figure 2, the subscript 'c' is an abbreviation for current, and 'p' is an abbreviation for previous.
在图2中，下标“c”是current的缩写，“p”是previous的缩写。
One-way Loss Measurement can be applied either proactively or on-demand, although as mentioned in Section 3.2.1, it is more likely to be applied proactively.
单向损耗测量可以主动或按需进行，尽管如第3.2.1节所述，它更有可能主动进行。
The term 'on-demand' in the context of one-way Loss Measurement implies that the sender transmits a fixed set of 1SL messages, allowing the receiver to perform the measurement based on this set.
在单向损耗测量的上下文中，术语“按需”意味着发送方发送一组固定的1SL消息，允许接收方基于该组消息执行测量。
A MEP that supports one-way Loss Measurement MUST support unicast transmission of 1SL messages.
支持单向损耗测量的MEP必须支持1SL消息的单播传输。
A MEP that supports one-way Loss Measurement MAY support multicast transmission of 1SL messages.
支持单向损耗测量的MEP可以支持1SL消息的多播传输。
The sender MUST maintain a packet counter for each peer MEP and probe instance (test ID). Every time the sender transmits a 1SL packet, it increments the corresponding counter and then integrates the value of the counter into the Counter TX field of the 1SL packet.
发送方必须为每个对等MEP和探测实例（测试ID）维护一个数据包计数器。发送方每次发送1SL数据包时，都会增加相应的计数器，然后将计数器的值集成到1SL数据包的计数器TX字段中。
The 1SL message MAY be sent with a variable-size Data TLV, allowing Loss Measurement for various packet sizes.
1SL消息可以与可变大小的数据TLV一起发送，从而允许对各种数据包大小进行丢失测量。
The receiver MUST maintain a reception counter for each peer MEP and probe instance (test ID). Upon receiving a 1SL packet, the receiver MUST verify that:
接收器必须为每个对等MEP和探测器实例（测试ID）维护一个接收计数器。接收到1SL数据包后，接收器必须验证：
o The 1SL packet is destined to the current MEP.
o 1SL数据包的目的地是当前MEP。
o The packet's MD level matches the MEP's MD level.
o 数据包的MD级别与MEP的MD级别匹配。
If both conditions are satisfied, the receiver increments the corresponding reception counter and records the new value of the counter, RX1.
如果两个条件都满足，则接收器增加相应的接收计数器，并记录计数器的新值RX1。
A MEP that supports one-way Loss Measurement MUST support reception of both unicast and multicast 1SL messages.
支持单向损耗测量的MEP必须同时支持单播和多播1SL消息的接收。
The receiver computes the one-way packet loss with respect to a probe instance measurement interval. A probe instance measurement interval includes a sequence of 1SL messages with the same test ID. The one-way packet loss is computed by comparing the counter values TXp and RXp at the beginning of the measurement interval and the counter values TXc and RXc at the end of the measurement interval (see Figure 2):
接收器计算关于探测实例测量间隔的单向分组丢失。探针实例测量间隔包括一系列具有相同测试ID的1SL消息。通过比较测量间隔开始时的计数器值TXp和RXp以及测量间隔结束时的计数器值TXc和RXc计算单向数据包丢失（见图2）：
one-way packet loss = (TXc-TXp) - (RXc-RXp) (1)
one-way packet loss = (TXc-TXp) - (RXc-RXp) (1)
The calculation in Equation (1) is based on counter value differences, implying that the sender's counter, TX, and the receiver's counter, RX, are not required to be synchronized with respect to a common initial value.
等式（1）中的计算基于计数器值差，这意味着发送方计数器TX和接收方计数器RX不需要与公共初始值同步。
It is noted that if the sender or receiver resets one of the counters, TX or RX, the calculation in Equation (1) produces a false measurement result. Hence, the sender and receiver SHOULD NOT clear the TX and RX counters during a measurement interval.
注意，如果发送方或接收方重置其中一个计数器TX或RX，则等式（1）中的计算会产生错误的测量结果。因此，发送方和接收方不应在测量间隔期间清除TX和RX计数器。
When the receiver calculates the packet loss per Equation (1), it MUST perform a wraparound check. If the receiver detects that one of the counters has wrapped around, the receiver adjusts the result of Equation (1) accordingly.
当接收器根据等式（1）计算分组丢失时，它必须执行环绕检查。如果接收器检测到其中一个计数器已缠绕，则接收器相应地调整等式（1）的结果。
A 1SL receiver MUST support reception of 1SL messages with a Data TLV.
1SL接收器必须支持通过数据TLV接收1SL消息。
Since synthetic one-way Loss Measurement is performed using 1SL messages, obviously, some 1SL messages may be dropped during a measurement interval. Thus, when the receiver does not receive a 1SL, the receiver cannot perform the calculations in Equation (1) for that specific 1SL message.
由于合成单向损耗测量是使用1SL消息执行的，显然，在测量间隔期间可能会丢弃一些1SL消息。因此，当接收器未接收到1SL时，接收器无法对该特定1SL消息执行等式（1）中的计算。
Two-way Loss Measurement allows a MEP to measure the packet loss on the paths to and from a peer MEP. Two-way Loss Measurement uses a set of Synthetic Loss Measurement Messages (SLMs) to compute the packet loss. Each SLM is answered with a Synthetic Loss Measurement Reply (SLR). The packet formats of the SLM and SLR packets are specified in Sections 6.2.3 and 6.2.4, respectively. Figure 3 illustrates a two-way Loss Measurement message exchange.
双向丢失测量允许MEP测量往返于对等MEP的路径上的数据包丢失。双向损耗测量使用一组合成损耗测量消息（SLM）来计算分组损耗。每个SLM都有一个合成损耗测量应答（SLR）。第6.2.3节和第6.2.4节分别规定了SLM和SLR数据包的数据包格式。图3说明了双向损耗测量消息交换。
TXp RXp TXc RXc
Sender -----------------------------------------------
\ /\ \ /\
\ / . . . \ /
SLM \ / SLR SLM \ / SLR
\/ / \/ /
Reflector -----------------------------------------------
TRXp TRXc
TXp RXp TXc RXc
Sender -----------------------------------------------
\ /\ \ /\
\ / . . . \ /
SLM \ / SLR SLM \ / SLR
\/ / \/ /
Reflector -----------------------------------------------
TRXp TRXc
Figure 3: Two-Way Loss Measurement
图3：双向损耗测量
The two-way Loss Measurement procedure uses a set of SLM-SLR handshakes. The figure shows two non-consecutive handshakes from the set.
双向损耗测量程序使用一组SLM-SLR握手。该图显示了集合中的两次非连续握手。
The sender maintains a counter of transmitted SLM messages and includes the value of this counter, TX, in each transmitted SLM message. The reflector maintains a counter of received SLM messages, TRX. The reflector generates an SLR and incorporates TRX into the SLR packet. The sender maintains a counter of received SLR messages, RX. Upon receiving an SLR message, the sender can calculate the loss by comparing the local counter values to the counter values received in the SLR messages.
发送方维护传输的SLM消息的计数器，并在每个传输的SLM消息中包含该计数器的值TX。反射器保持接收到的SLM消息的计数器TRX。反射器生成SLR并将TRX合并到SLR分组中。发送方维护接收到的SLR消息的计数器RX。收到SLR消息后，发送方可以通过将本地计数器值与SLR消息中接收到的计数器值进行比较来计算损失。
The subscript 'c' is an abbreviation for current, and 'p' is an abbreviation for previous.
下标“c”是current的缩写，“p”是previous的缩写。
Two-way Loss Measurement can be applied either proactively or on-demand.
双向损耗测量可以主动或按需进行。
A MEP that supports two-way Loss Measurement MUST support unicast transmission of SLM messages.
支持双向损耗测量的MEP必须支持SLM消息的单播传输。
A MEP that supports two-way Loss Measurement MAY support multicast transmission of SLM messages.
支持双向损耗测量的MEP可以支持SLM消息的多播传输。
The sender MUST maintain a counter of transmitted SLM packets for each peer MEP and probe instance (test ID). Every time the sender transmits an SLM packet, it increments the corresponding counter and then integrates the value of the counter into the Counter TX field of the SLM packet.
发送方必须为每个对等MEP和探测实例（测试ID）维护已传输SLM数据包的计数器。发送方每次发送SLM数据包时，都会增加相应的计数器，然后将计数器的值集成到SLM数据包的计数器TX字段中。
A sender MAY include a Reflector Entropy TLV in an SLM message. The Reflector Entropy TLV format is specified in [TRILL-FM].
发送方可以在SLM消息中包括TLV。反射层熵TLV格式在[TRILL-FM]中规定。
An SLM message MAY be sent with a Data TLV, allowing Loss Measurement for various packet sizes.
SLM消息可以与数据TLV一起发送，从而允许对各种分组大小进行丢失测量。
The reflector MUST maintain a reception counter, TRX, for each peer MEP and probe instance (test ID).
反射器必须为每个对等MEP和探头实例（测试ID）维护一个接收计数器TRX。
Upon receiving an SLM packet, the reflector MUST verify that:
收到SLM数据包后，反射器必须验证：
o The SLM packet is destined to the current MEP.
o SLM数据包的目的地是当前MEP。
o The packet's MD level matches the MEP's MD level.
o 数据包的MD级别与MEP的MD级别匹配。
If both conditions are satisfied, the reflector increments the corresponding packet counter and records the value of the new counter, TRX. The reflector then generates an SLR message that is identical to the received SLM, except for the following modifications:
如果两个条件都满足，反射器增加相应的分组计数器，并记录新计数器TRX的值。反射器随后生成与接收到的SLM相同的SLR消息，但以下修改除外：
o The reflector incorporates TRX into the Counter TRX field of the SLR.
o 反射器将TRX合并到单反的计数器TRX场中。
o The OpCode field in the OAM header is set to the SLR OpCode.
o OAM标头中的操作码字段设置为SLR操作码。
o The reflector assigns its MEP ID in the Reflector MEP ID field.
o 反射器在反射器MEP ID字段中指定其MEP ID。
o If the received SLM includes a Reflector Entropy TLV [TRILL-FM], the reflector copies the value of the Flow Entropy from the TLV into the Flow Entropy field of the SLR message. The outgoing SLR message does not include a Reflector Entropy TLV.
o 如果接收到的SLM包括反射器熵TLV[TRILL-FM]，则反射器将流熵的值从TLV复制到SLR消息的流熵场中。传出的SLR消息不包括TLV。
o The TRILL Header and transport header are modified to reflect the source and destination of the SLR packet. The SLR is always a unicast message.
o TRILL报头和传输报头被修改以反映SLR分组的源和目的地。单反总是单播消息。
A MEP that supports two-way Loss Measurement MUST support reception of both unicast and multicast SLM messages.
支持双向损耗测量的MEP必须同时支持单播和多播SLM消息的接收。
A reflector MUST support reception of SLM packets with a Data TLV. When receiving an SLM with a Data TLV, the reflector includes the unmodified TLV in the SLR.
反射器必须支持通过数据TLV接收SLM数据包。当接收具有数据TLV的SLM时，反射器在SLR中包括未修改的TLV。
The sender MUST maintain a reception counter, RX, for each peer MEP and probe instance (test ID).
发送方必须为每个对等MEP和探测器实例（测试ID）维护一个接收计数器RX。
Upon receiving an SLR message, the sender MUST verify that:
收到SLR消息后，发送方必须验证：
o The SLR packet is destined to the current MEP.
o SLR数据包目的地为当前MEP。
o The Sender MEP ID field in the SLR packet matches the current MEP.
o SLR数据包中的发送方MEP ID字段与当前MEP匹配。
o The packet's MD level matches the MEP's MD level.
o 数据包的MD级别与MEP的MD级别匹配。
If the conditions above are met, the sender increments the corresponding reception counter, and records the new value, RX.
如果满足上述条件，则发送方增加相应的接收计数器，并记录新值RX。
The sender computes the packet loss with respect to a probe instance measurement interval. A probe instance measurement interval includes a sequence of SLM messages and their corresponding SLR messages, all with the same test ID. The packet loss is computed by comparing the counters at the beginning of the measurement interval, denoted with a subscript 'p', and the counters at the end of the measurement interval, denoted with a subscript 'c' (as illustrated in Figure 3).
发送方根据探测实例测量间隔计算数据包丢失。探测实例测量间隔包括一系列SLM消息及其对应的SLR消息，所有消息都具有相同的测试ID。通过比较测量间隔开始时的计数器（用下标“p”表示）和测量间隔结束时的计数器，计算包丢失，用下标“c”表示（如图3所示）。
far-end packet loss = (TXc-TXp) - (TRXc-TRXp) (2)
far-end packet loss = (TXc-TXp) - (TRXc-TRXp) (2)
near-end packet loss = (TRXc-TRXp) - (RXc-RXp) (3)
near-end packet loss = (TRXc-TRXp) - (RXc-RXp) (3)
Note: The total two-way packet loss is the sum of the far-end and near-end packet losses, that is (TXc-TXp) - (RXc-RXp).
注：总双向数据包丢失是远端和近端数据包丢失的总和，即（TXc TXp）-（RXc RXp）。
The calculations in the two equations above are based on counter value differences, implying that the sender's counters, TX and RX, and the reflector's counter, TRX, are not required to be synchronized with respect to a common initial value.
上述两个等式中的计算基于计数器值差异，这意味着发送方计数器TX和RX以及反射器计数器TRX不需要与公共初始值同步。
It is noted that if the sender or reflector resets one of the counters, TX, TRX, or RX, the calculation in Equations (2) and (3) produces a false measurement result. Hence, the sender and reflector SHOULD NOT clear the TX, TRX, and RX counters during a measurement interval.
注意，如果发送器或反射器复位其中一个计数器TX、TRX或RX，则等式（2）和（3）中的计算会产生错误的测量结果。因此，在测量间隔期间，发送器和反射器不应清除TX、TRX和RX计数器。
When the sender calculates the packet loss per Equations (2) and (3), it MUST perform a wraparound check. If the reflector detects that one of the counters has wrapped around, the reflector adjusts the result of Equations (2) and (3) accordingly.
当发送方根据等式（2）和（3）计算数据包丢失时，它必须执行环绕检查。如果反射器检测到其中一个计数器缠绕，反射器相应地调整等式（2）和（3）的结果。
Since synthetic two-way Loss Measurement is performed using SLM and SLR messages, obviously, some SLM and SLR messages may be dropped during a measurement interval. When an SLM or an SLR is dropped, the corresponding two-way handshake (Figure 3) is not completed successfully; thus, the reflector does not perform the calculations in Equations (2) and (3) for that specific message exchange.
由于使用SLM和SLR消息执行合成双向损耗测量，显然，在测量间隔期间可能会丢弃一些SLM和SLR消息。当SLM或SLR被丢弃时，相应的双向握手（图3）未成功完成；因此，反射器不针对该特定消息交换执行等式（2）和（3）中的计算。
A sender MAY choose to monitor only the far-end packet loss, that is, perform the computation in Equation (2), and ignore the computation in Equation (3). Note that, in this case, the sender can run flow-based PM of the path to the peer MEP without using the Reflector Entropy TLV.
发送方可以选择仅监视远端分组丢失，即，执行等式（2）中的计算，而忽略等式（3）中的计算。注意，在这种情况下，发送方可以在不使用反射熵TLV的情况下运行到对等MEP的路径的基于流的PM。
The Delay Measurement protocol has two modes of operation: one-way Delay Measurement and two-way Delay Measurement.
延迟测量协议有两种操作模式：单向延迟测量和双向延迟测量。
One-way Delay Measurement is used for computing the one-way packet delay from one MEP to another. The packet format used in one-way Delay Measurement is referred to as 1DM and is specified in Section 6.3.2. The one-way Delay Measurement message exchange is illustrated in Figure 4.
单向延迟测量用于计算从一个MEP到另一个MEP的单向数据包延迟。单向延迟测量中使用的数据包格式称为1DM，并在第6.3.2节中规定。单向延迟测量消息交换如图4所示。
T1
Sender ------------------- ----> time
\
\ 1DM
\
\/
Receiver -------------------
T2
T1
Sender ------------------- ----> time
\
\ 1DM
\
\/
Receiver -------------------
T2
Figure 4: One-Way Delay Measurement
图4：单向延迟测量
The sender transmits a 1DM message incorporating its time of transmission, T1. The receiver then receives the message at time T2, and calculates the one-way delay as:
发送方发送包含其传输时间T1的1DM消息。然后，接收器在时间T2接收消息，并将单向延迟计算为：
one-way delay = T2-T1 (4)
单向延迟=T2-T1（4）
Equation (4) implies that T2 and T1 are measured with respect to a common reference time. Hence, two MEPs running a one-way Delay Measurement protocol MUST be time-synchronized. The method used for synchronizing the clocks associated with the two MEPs is outside the scope of this document.
等式（4）表示T2和T1是相对于公共参考时间测量的。因此，运行单向延迟测量协议的两个MEP必须是时间同步的。用于同步与两个MEP相关的时钟的方法不在本文档的范围内。
1DM packets can be transmitted proactively or on-demand, although, as mentioned in Section 3.2.1, they are typically transmitted proactively.
1DM数据包可以主动或按需传输，尽管如第3.2.1节所述，它们通常是主动传输的。
A MEP that supports one-way Delay Measurement MUST support unicast transmission of 1DM messages.
支持单向延迟测量的MEP必须支持1DM消息的单播传输。
A MEP that supports one-way Delay Measurement MAY support multicast transmission of 1DM messages.
支持单向延迟测量的MEP可以支持1DM消息的多播传输。
A 1DM message MAY be sent with a variable size Data TLV, allowing packet Delay Measurement for various packet sizes.
1DM消息可以与可变大小的数据TLV一起发送，从而允许对各种数据包大小进行数据包延迟测量。
The sender incorporates the 1DM packet's time of transmission into the Timestamp T1 field.
发送方将1DM数据包的传输时间合并到时间戳T1字段中。
Upon receiving a 1DM packet, the receiver records its time of reception, T2. The receiver MUST verify two conditions:
在接收到1DM数据包时，接收器记录其接收时间T2。接收器必须验证两个条件：
o The 1DM packet is destined to the current MEP.
o 1DM数据包的目的地为当前MEP。
o The packet's MD level matches the MEP's MD level.
o 数据包的MD级别与MEP的MD级别匹配。
If both conditions are satisfied, the receiver terminates the packet and calculates the one-way delay as specified in Equation (4).
如果这两个条件都满足，则接收机终止分组并计算等式（4）中指定的单向延迟。
A MEP that supports one-way Delay Measurement MUST support reception of both unicast and multicast 1DM messages.
支持单向延迟测量的MEP必须同时支持单播和多播1DM消息的接收。
A 1DM receiver MUST support reception of 1DM messages with a Data TLV.
1DM接收器必须支持使用数据TLV接收1DM消息。
When one-way Delay Measurement packets are received periodically, the receiver MAY compute the packet delay variation based on multiple measurements. Note that packet delay variation can be computed even when the two peer MEPs are not time-synchronized.
当周期性地接收单向延迟测量分组时，接收机可以基于多个测量来计算分组延迟变化。注意，即使两个对等mep不同步，也可以计算分组延迟变化。
Two-way Delay Measurement uses a two-way handshake for computing the two-way packet delay between two MEPs. The handshake includes two packets: a Delay Measurement Message (DMM) and a Delay Measurement Reply (DMR). The DMM and DMR packet formats are specified in Sections 6.3.3 and 6.3.4, respectively.
双向延迟测量使用双向握手来计算两个MEP之间的双向数据包延迟。握手包括两个数据包：延迟测量消息（DMM）和延迟测量应答（DMR）。第6.3.3节和第6.3.4节分别规定了DMM和DMR数据包格式。
The two-way Delay Measurement message exchange is illustrated in Figure 5.
双向延迟测量消息交换如图5所示。
T1 T4
Sender ----------------------- ----> time
\ /\
\ /
DMM \ / DMR
\/ /
Reflector -----------------------
T2 T3
T1 T4
Sender ----------------------- ----> time
\ /\
\ /
DMM \ / DMR
\/ /
Reflector -----------------------
T2 T3
Figure 5: Two-Way Delay Measurement
图5：双向延迟测量
The sender generates a DMM message incorporating its time of transmission, T1. The reflector receives the DMM message and records its time of reception, T2. The reflector then generates a DMR
发送方生成包含其传输时间T1的DMM消息。反射器接收DMM消息并记录其接收时间T2。然后反射器生成DMR
message, incorporating T1, T2, and the DMR's transmission time, T3. The sender receives the DMR message at T4, and using the four timestamps, it calculates the two-way packet delay.
包含T1、T2和DMR传输时间T3的消息。发送方在T4接收DMR消息，并使用四个时间戳计算双向数据包延迟。
DMM packets can be transmitted periodically or on-demand.
DMM数据包可以定期或按需传输。
A MEP that supports two-way Delay Measurement MUST support unicast transmission of DMM messages.
支持双向延迟测量的MEP必须支持DMM消息的单播传输。
A MEP that supports two-way Delay Measurement MAY support multicast transmission of DMM messages.
支持双向延迟测量的MEP可以支持DMM消息的多播传输。
A sender MAY include a Reflector Entropy TLV in a DMM message. The Reflector Entropy TLV format is specified in [TRILL-FM].
发送方可以在DMM消息中包括反射熵TLV。反射层熵TLV格式在[TRILL-FM]中规定。
A DMM MAY be sent with a variable size Data TLV, allowing packet Delay Measurement for various packet sizes.
DMM可以与可变大小的数据TLV一起发送，从而允许对各种数据包大小进行数据包延迟测量。
The sender incorporates the DMM packet's time of transmission into the Timestamp T1 field.
发送方将DMM数据包的传输时间合并到时间戳T1字段中。
Upon receiving a DMM packet, the reflector records its time of reception, T2. The reflector MUST verify two conditions:
在接收到DMM分组时，反射器记录其接收时间T2。反射器必须验证两种情况：
o The DMM packet is destined to the current MEP.
o DMM数据包的目的地是当前MEP。
o The packet's MD level matches the MEP's MD level.
o 数据包的MD级别与MEP的MD级别匹配。
If both conditions are satisfied, the reflector terminates the packet and generates a DMR packet. The DMR is identical to the received DMM, except for the following modifications:
如果两个条件都满足，则反射器终止分组并生成DMR分组。除以下修改外，DMR与接收到的DMM相同：
o The reflector incorporates T2 into the Timestamp T2 field of the DMR.
o 反射器将T2合并到DMR的时间戳T2字段中。
o The reflector incorporates the DMR's transmission time, T3, into the Timestamp T3 field of the DMR.
o 反射器将DMR的传输时间T3合并到DMR的时间戳T3字段中。
o The OpCode field in the OAM header is set to the DMR OpCode.
o OAM标头中的操作码字段设置为DMR操作码。
o If the received DMM includes a Reflector Entropy TLV [TRILL-FM], the reflector copies the value of the Flow Entropy from the TLV into the Flow Entropy field of the DMR message. The outgoing DMR message does not include a Reflector Entropy TLV.
o 如果接收到的DMM包括反射器熵TLV[TRILL-FM]，则反射器将流熵的值从TLV复制到DMR消息的流熵场中。传出的DMR消息不包括TLV。
o The TRILL Header and transport header are modified to reflect the source and destination of the DMR packet. The DMR is always a unicast message.
o TRILL报头和传输报头被修改以反映DMR数据包的源和目的地。DMR始终是单播消息。
A MEP that supports two-way Delay Measurement MUST support reception of both unicast and multicast DMM messages.
支持双向延迟测量的MEP必须同时支持单播和多播DMM消息的接收。
A reflector MUST support reception of DMM packets with a Data TLV. When receiving a DMM with a Data TLV, the reflector includes the unmodified TLV in the DMR.
反射器必须支持使用数据TLV接收DMM数据包。当接收具有数据TLV的DMM时，反射器在DMR中包括未修改的TLV。
Upon receiving the DMR message, the sender records its time of reception, T4. The sender MUST verify:
在接收到DMR消息时，发送方记录其接收时间T4。发件人必须验证：
o The DMR packet is destined to the current MEP.
o DMR数据包的目的地是当前MEP。
o The packet's MD level matches the MEP's MD level.
o 数据包的MD级别与MEP的MD级别匹配。
If both conditions above are met, the sender uses the four timestamps to compute the two-way delay:
如果满足上述两个条件，发送方将使用四个时间戳来计算双向延迟：
two-way delay = (T4-T1) - (T3-T2) (5)
two-way delay = (T4-T1) - (T3-T2) (5)
Note that two-way delay can be computed even when the two peer MEPs are not time-synchronized. One-way Delay Measurement, on the other hand, requires the two MEPs to be synchronized.
请注意，即使两个对等MEP没有时间同步，也可以计算双向延迟。另一方面，单向延迟测量要求两个MEP同步。
Two MEPs running a two-way Delay Measurement protocol MAY be time-synchronized. If two-way Delay Measurement is run between two time-synchronized MEPs, the sender MAY compute the one-way delays as follows:
运行双向延迟测量协议的两个MEP可以是时间同步的。如果在两个时间同步的MEP之间运行双向延迟测量，则发送方可以如下计算单向延迟：
one-way delay {sender->reflector} = T2 - T1 (6)
one-way delay {sender->reflector} = T2 - T1 (6)
one-way delay {reflector->sender} = T4 - T3 (7)
one-way delay {reflector->sender} = T4 - T3 (7)
When two-way Delay Measurement is run periodically, the sender MAY also compute the delay variation based on multiple measurements.
当周期性地运行双向延迟测量时，发送方还可以基于多个测量来计算延迟变化。
A sender MAY choose to monitor only the sender->reflector delay, that is, perform the computation in Equation (6) and ignore the computations in Equations (5) and (7). Note that in this case, the sender can run flow-based PM of the path to the peer MEP without using the Reflector Entropy TLV.
发送方可选择仅监视发送方->反射器延迟，即，执行等式（6）中的计算并忽略等式（5）和（7）中的计算。注意，在这种情况下，发送方可以在不使用反射熵TLV的情况下运行到对等MEP的路径的基于流的PM。
The TRILL OAM packet format is generally discussed in [OAM-FRAMEWK] and specified in detail in [TRILL-FM]. It is quoted in this document for convenience.
TRILL OAM数据包格式通常在[OAM-FRAMEWK]中讨论，并在[TRILL-FM]中详细说明。为了方便起见，本文件中引用了它。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Header . (variable)
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TRILL Header + 6 or more bytes
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Flow Entropy . 96 bytes
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OAM Message Channel . Variable
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Trailer | Variable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Header . (variable)
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TRILL Header + 6 or more bytes
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Flow Entropy . 96 bytes
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OAM Message Channel . Variable
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Trailer | Variable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TRILL OAM Encapsulation
图6：TRILL OAM封装
The OAM Message Channel used in this document is defined in [TRILL-FM] and has the following structure:
本文档中使用的OAM消息通道在[TRILL-FM]中定义，具有以下结构：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Version | OpCode | Flags |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OpCode-specific fields .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Version | OpCode | Flags |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. OpCode-specific fields .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: OAM Packet Format
图7:OAM数据包格式
The first four octets of the OAM Message Channel are common to all OpCodes, whereas the rest is OpCode-specific. Below is a brief summary of the fields in the first 4 octets:
OAM消息通道的前四个八位字节对所有操作码都是通用的，而其余的是特定于操作码的。以下是前4个八位字节字段的简要摘要：
o MD-L: Maintenance Domain Level.
o MD-L：维护域级别。
o Version: indicates the version of this protocol. Always zero in the context of this document.
o 版本：表示此协议的版本。在本文档的上下文中始终为零。
o OpCode: Operation Code (8 bits). Specifies the operation performed by the message. Specific packet formats are presented in Sections 6.2 and 6.3 of this document. A list of the PM message OpCodes is provided in Section 6.4.
o 操作码：操作码（8位）。指定消息执行的操作。具体数据包格式见本文件第6.2节和第6.3节。第6.4节提供了PM消息操作码列表。
o Flags: The definition of flags is OpCode-specific. The value of this field is zero unless otherwise stated.
o 标志：标志的定义是特定于操作码的。除非另有说明，否则此字段的值为零。
o FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field.
o FirstTLVOffset：定义第一个TLV的位置，以八位字节为单位，从FirstTLVOffset字段的末尾开始。
o TLVs: one or more TLV fields. The last TLV field is always an End TLV.
o TLV：一个或多个TLV字段。最后一个TLV字段始终是结束TLV。
For further details about the OAM packet format, including the format of TLVs, see [TRILL-FM].
有关OAM数据包格式（包括TLV格式）的更多详细信息，请参阅[TRILL-FM]。
Loss Measurement packets use a 32-bit packet counter field. When a counter is incremented beyond its maximal value, 0xFFFFFFFF, it wraps around back to 0.
丢失测量数据包使用32位数据包计数器字段。当计数器的增量超过其最大值0xFFFFFFFF时，它会返回到0。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MEP ID | Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MEP ID | Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: 1SL Packet Format
图8:1SL数据包格式
For fields not listed below, see Section 6.1.
对于以下未列出的字段，请参见第6.1节。
o OpCode: see Section 6.4.
o 操作码：见第6.4节。
o FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field. The value of this field MUST be 16 in 1SL packets.
o FirstTLVOffset：定义第一个TLV的位置，以八位字节为单位，从FirstTLVOffset字段的末尾开始。此字段的值在1SL数据包中必须为16。
o Sender MEP ID: the MEP ID of the MEP that initiated the 1SL.
o 发送方MEP ID：启动1SL的MEP的MEP ID。
o Reserved (0): set to 0 by the sender and ignored by the receiver.
o 保留（0）：发送方设置为0，接收方忽略。
o Test ID: a 32-bit unique test identifier.
o 测试ID：32位唯一测试标识符。
o Counter TX: the value of the sender's transmission counter, including this packet, at the time of transmission.
o 计数器TX：传输时发送方传输计数器的值，包括此数据包。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MEP ID | Reserved for Reflector MEP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for SLR: Counter TRX (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MEP ID | Reserved for Reflector MEP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for SLR: Counter TRX (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: SLM Packet Format
图9:SLM数据包格式
For fields not listed below, see Section 6.1.
对于以下未列出的字段，请参见第6.1节。
o OpCode: see Section 6.4.
o 操作码：见第6.4节。
o FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field. The value of this field MUST be 16 in SLM packets.
o FirstTLVOffset：定义第一个TLV的位置，以八位字节为单位，从FirstTLVOffset字段的末尾开始。在SLM数据包中，此字段的值必须为16。
o Sender MEP ID: the MEP ID of the MEP that initiated this packet.
o Sender MEP ID：启动此数据包的MEP的MEP ID。
o Reserved for Reflector MEP ID: this field is reserved for the reflector's MEP ID, to be added in the SLR.
o 为反射器MEP ID保留：此字段为反射器的MEP ID保留，将添加到SLR中。
o Test ID: a 32-bit unique test identifier.
o 测试ID：32位唯一测试标识符。
o Counter TX: the value of the sender's transmission counter, including this packet, at the time of transmission.
o 计数器TX：传输时发送方传输计数器的值，包括此数据包。
o Reserved for SLR: this field is reserved for the SLR corresponding to this packet. The reflector uses this field in the SLR for carrying TRX, the value of its reception counter.
o SLR预留：此字段为该数据包对应的SLR预留。反射器在单反中使用该字段携带其接收计数器的值TRX。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MEP ID | Reflector MEP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TRX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MEP ID | Reflector MEP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TRX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SLR Packet Format
图10:SLR数据包格式
For fields not listed below, see Section 6.1.
对于以下未列出的字段，请参见第6.1节。
o OpCode: see Section 6.4.
o 操作码：见第6.4节。
o FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field. The value of this field MUST be 16 in SLR packets.
o FirstTLVOffset：定义第一个TLV的位置，以八位字节为单位，从FirstTLVOffset字段的末尾开始。在SLR数据包中，此字段的值必须为16。
o Sender MEP ID: the MEP ID of the MEP that initiated the SLM that this SLR replies to.
o Sender MEP ID：启动此SLR答复的SLM的MEP的MEP ID。
o Reflector MEP ID: the MEP ID of the MEP that transmits this SLR message.
o 反射层MEP ID：传输此SLR消息的MEP的MEP ID。
o Test ID: a 32-bit unique test identifier, copied from the corresponding SLM message.
o 测试ID：从相应SLM消息复制的32位唯一测试标识符。
o Counter TX: the value of the sender's transmission counter at the time of the SLM transmission.
o 计数器TX：SLM传输时发送方传输计数器的值。
o Counter TRX: the value of the reflector's reception counter, including this packet, at the time of reception of the corresponding SLM packet.
o 计数器TRX：在接收相应SLM数据包时，反射器接收计数器的值，包括该数据包。
The timestamps used in Delay Measurement packets are 64 bits long. These timestamps use the 64 least significant bits of the IEEE 1588-2008 (1588v2) Precision Time Protocol timestamp format [IEEE1588v2].
延迟测量数据包中使用的时间戳为64位长。这些时间戳使用IEEE 1588-2008（1588v2）精确时间协议时间戳格式[IEEE1588v2]的64个最低有效位。
This truncated format consists of a 32-bit seconds field followed by a 32-bit nanoseconds field. This truncated format is also used in IEEE 1588v1 [IEEE1588v1], in [Y.1731-2013], and in [MPLS-LM-DM].
此截断格式由一个32位秒字段和一个32位纳秒字段组成。IEEE 1588v1[IEEE1588v1]、[Y.1731-2013]和[MPLS-LM-DM]中也使用了这种截断格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for 1DM receiving equipment (0) |
| (for Timestamp T2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for 1DM receiving equipment (0) |
| (for Timestamp T2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: 1DM Packet Format
图11:1DM数据包格式
For fields not listed below, see Section 6.1.
对于以下未列出的字段，请参见第6.1节。
o OpCode: see Section 6.4.
o 操作码：见第6.4节。
o Reserved (0): Upper part of Flags field. Set to 0 by the sender and ignored by the receiver.
o 保留（0）：标志字段的上部。发送方设置为0，接收方忽略。
o T: Type flag. When this flag is set, it indicates proactive operation; when cleared, it indicates on-demand mode.
o T：类型标志。设置此标志时，表示主动操作；清除时，它指示按需模式。
o FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field. The value of this field MUST be 16 in 1DM packets.
o FirstTLVOffset：定义第一个TLV的位置，以八位字节为单位，从FirstTLVOffset字段的末尾开始。此字段的值在1DM数据包中必须为16。
o Timestamp T1: specifies the time of transmission of this packet.
o 时间戳T1：指定此数据包的传输时间。
o Reserved for 1DM: this field is reserved for internal usage of the 1DM receiver. The receiver can use this field for carrying T2, the time of reception of this packet.
o 预留1DM：此字段预留给1DM接收器内部使用。接收机可以使用该字段来携带T2，即该分组的接收时间。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMM receiving equipment (0) |
| (for Timestamp T2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMR (0) |
| (for Timestamp T3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMR receiving equipment |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMM receiving equipment (0) |
| (for Timestamp T2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMR (0) |
| (for Timestamp T3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMR receiving equipment |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: DMM Packet Format
图12:DMM数据包格式
For fields not listed below, see Section 6.1.
对于以下未列出的字段，请参见第6.1节。
o OpCode: see Section 6.4.
o 操作码：见第6.4节。
o Reserved (0): Upper part of Flags field. Set to 0 by the sender and ignored by the receiver.
o 保留（0）：标志字段的上部。发送方设置为0，接收方忽略。
o T: Type flag. When this flag is set, it indicates proactive operation; when cleared, it indicates on-demand mode.
o T：类型标志。设置此标志时，表示主动操作；清除时，它指示按需模式。
o FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field. The value of this field MUST be 32 in DMM packets.
o FirstTLVOffset：定义第一个TLV的位置，以八位字节为单位，从FirstTLVOffset字段的末尾开始。在DMM数据包中，此字段的值必须为32。
o Timestamp T1: specifies the time of transmission of this packet.
o 时间戳T1：指定此数据包的传输时间。
o Reserved for DMM: this field is reserved for internal usage of the MEP that receives the DMM (the reflector). The reflector can use this field for carrying T2, the time of reception of this packet.
o 预留给DMM：此字段预留给接收DMM的MEP（反射器）的内部使用。反射器可以使用该字段来携带T2，即该分组的接收时间。
o Reserved for DMR: two timestamp fields are reserved for the DMR message. One timestamp field is reserved for T3, the DMR transmission time, and the other field is reserved for internal usage of the MEP that receives the DMR.
o 为DMR保留：为DMR消息保留两个时间戳字段。一个时间戳字段保留用于T3，即DMR传输时间，另一个字段保留用于接收DMR的MEP的内部使用。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T2 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T3 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMR receiving equipment |
| (for Timestamp T4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T2 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T3 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMR receiving equipment |
| (for Timestamp T4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: DMR Packet Format
图13:DMR数据包格式
For fields not listed below, see Section 6.1.
对于以下未列出的字段，请参见第6.1节。
o OpCode: see Section 6.4.
o 操作码：见第6.4节。
o Reserved (0): Upper part of Flags field. Set to 0 by the sender and ignored by the receiver.
o 保留（0）：标志字段的上部。发送方设置为0，接收方忽略。
o T: Type flag. When this flag is set, it indicates proactive operation; when cleared, it indicates on-demand mode.
o T：类型标志。设置此标志时，表示主动操作；清除时，它指示按需模式。
o FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field. The value of this field MUST be 32 in DMR packets.
o FirstTLVOffset：定义第一个TLV的位置，以八位字节为单位，从FirstTLVOffset字段的末尾开始。在DMR数据包中，此字段的值必须为32。
o Timestamp T1: specifies the time of transmission of the DMM packet that this DMR replies to.
o 时间戳T1：指定此DMR回复的DMM数据包的传输时间。
o Timestamp T2: specifies the time of reception of the DMM packet that this DMR replies to.
o 时间戳T2：指定此DMR回复的DMM数据包的接收时间。
o Timestamp T3: specifies the time of transmission of this DMR packet.
o 时间戳T3：指定此DMR数据包的传输时间。
o Reserved for DMR: this field is reserved for internal usage of the MEP that receives the DMR (the sender). The sender can use this field for carrying T4, the time of reception of this packet.
o 预留给DMR：此字段预留给接收DMR的MEP（发送方）的内部使用。发送方可以使用该字段携带T4，即该数据包的接收时间。
As the OAM packets specified herein conform to [Y.1731-2013], the same OpCodes are used:
由于此处规定的OAM数据包符合[Y.1731-2013]，因此使用相同的操作码：
OpCode OAM packet
value type
------ ----------
OpCode OAM packet
value type
------ ----------
45 1DM
45 1毫米
46 DMR
46 DMR
47 DMM
47数字万用表
53 1SL
53 1SL
54 SLR
54单反
55 SLM
55平方米
These OpCodes are from the range of values that has been allocated by IEEE 802.1 [802.1Q] for control by ITU-T.
这些操作码来自IEEE 802.1[802.1Q]分配给ITU-T控制的值范围。
The Performance Monitoring process is made up of a number of Performance Monitoring instances, known as PM Sessions. A PM session can be initiated between two MEPs on a specific flow and be defined as either a Loss Measurement session or Delay Measurement session.
性能监视过程由许多性能监视实例组成，称为PM会话。PM会话可以在特定流上的两个MEP之间启动，并定义为损耗测量会话或延迟测量会话。
The Loss Measurement session can be used to determine the performance metrics Frame Loss Ratio, availability, and resiliency. The Delay Measurement session can be used to determine the performance metrics Frame Delay, Inter-Frame Delay Variation, Frame Delay Range, and Mean Frame Delay.
损耗测量会话可用于确定性能指标帧丢失率、可用性和恢复能力。延迟测量会话可用于确定性能指标帧延迟、帧间延迟变化、帧延迟范围和平均帧延迟。
The PM session is defined by the specific PM function (PM tool) being run and also by the Start Time, Stop Time, Message Period, Measurement Interval, and Repetition Time. These terms are defined as follows:
PM会话由正在运行的特定PM功能（PM工具）以及开始时间、停止时间、消息周期、测量间隔和重复时间定义。这些术语的定义如下：
o Start Time - the time that the PM session begins.
o 开始时间-PM会话开始的时间。
o Stop Time - the time that the measurement ends.
o 停止时间-测量结束的时间。
o Message Period - the message transmission frequency (the time between message transmissions).
o 消息周期-消息传输频率（消息传输之间的时间）。
o Measurement Interval - the time period over which measurements are gathered and then summarized. The Measurement Interval can align with the PM Session duration, but it doesn't need to. PM messages are only transmitted during a PM Session.
o 测量间隔-收集测量值并进行汇总的时间段。测量间隔可以与PM会话持续时间对齐，但不需要这样做。PM消息仅在PM会话期间传输。
o Repetition Time - the time between start times of the Measurement Intervals.
o 重复时间-测量间隔开始时间之间的时间。
Measurement Interval Measurement Interval
(Completed, Historic) (In Process, Current)
| |
| |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^ ^
| | | |
Start Time Message Stop Time
(service enabled) Period (Service disabled)
Measurement Interval Measurement Interval
(Completed, Historic) (In Process, Current)
| |
| |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^ ^ ^ ^
| | | |
Start Time Message Stop Time
(service enabled) Period (Service disabled)
Figure 14: Relationship between Different Timing Parameters
图14：不同定时参数之间的关系
The security considerations of TRILL OAM are discussed in [OAM-REQ], [OAM-FRAMEWK], and [TRILL-FM]. General TRILL security considerations are discussed in [TRILL].
TRILL OAM的安全注意事项在[OAM-REQ]、[OAM-FRAMEWK]和[TRILL-FM]中讨论。[TRILL]中讨论了一般TRILL安全注意事项。
As discussed in [OAM-Over], an attack on a PM protocol can falsely indicate nonexistent performance issues or prevent the detection of actual ones, consequently resulting in DoS (Denial of Service). Furthermore, synthetic PM messages can be used maliciously as a means to implement DoS attacks on RBridges. Another security aspect is network reconnaissance; by passively eavesdropping on PM messages, an attacker can gather information that can be used maliciously to attack the network.
如[OAM Over]中所述，对PM协议的攻击可能会错误地表明不存在性能问题，或阻止检测实际问题，从而导致DoS（拒绝服务）。此外，合成PM消息可被恶意用作对RBridge实施DoS攻击的手段。另一个安全方面是网络侦察；通过被动窃听PM消息，攻击者可以收集可恶意用于攻击网络的信息。
As in [TRILL-FM], TRILL PM OAM messages MAY include the OAM Authentication TLV. It should be noted that an Authentication TLV requires a cryptographic algorithm, which may have performance implications on the RBridges that take part in the protocol; thus, they may, in some cases, affect the measurement results. Based on a system-specific threat assessment, the benefits of the security TLV must be weighed against the potential measurement inaccuracy it may inflict, and based on this trade-off, operators should make a decision on whether or not to use authentication.
与[TRILL-FM]中一样，TRILL PM OAM消息可能包括OAM认证TLV。应当注意，认证TLV需要密码算法，这可能对参与协议的rbridge具有性能影响；因此，在某些情况下，它们可能会影响测量结果。基于系统特定威胁评估，必须根据安全TLV可能造成的潜在测量不准确性权衡安全TLV的好处，并基于此权衡，运营商应决定是否使用身份验证。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[TRILL] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[TRILL]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 63252011年7月<http://www.rfc-editor.org/info/rfc6325>.
[FGL] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[FGL]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链路的透明互连（TRILL）：细粒度标记”，RFC 7172，2014年5月<http://www.rfc-editor.org/info/rfc7172>.
[TRILL-FM] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, March 2015, <http://www.rfc-editor.org/info/rfc7455>.
[TRILL-FM]Senevirathne，T.，Finn，N.，Salam，S.，Kumar，D.，Eastlake 3rd，D.，Aldrin，S.，和Y.Li，“大量链路的透明互连（TRILL）：故障管理”，RFC 74552015年3月<http://www.rfc-editor.org/info/rfc7455>.
[OAM-REQ] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. Watve, "Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)", RFC 6905, March 2013, <http://www.rfc-editor.org/info/rfc6905>.
[OAM-REQ]Senevirathne，T.，Bond，D.，Aldrin，S.，Li，Y.，和R.Watve，“大量链路透明互连（TRILL）中的操作、管理和维护（OAM）要求”，RFC 69052013年3月<http://www.rfc-editor.org/info/rfc6905>.
[OAM-FRAMEWK] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, May 2014, <http://www.rfc-editor.org/info/rfc7174>.
[OAM-FRAMEWK]Salam，S.，Senevirathne，T.，Aldrin，S.，和D.Eastlake 3rd，“大量链路的透明互连（TRILL）运营、管理和维护（OAM）框架”，RFC 71742014年5月<http://www.rfc-editor.org/info/rfc7174>.
[Y.1731-2013] ITU-T, "OAM functions and mechanisms for Ethernet based Networks", ITU-T Recommendation G.8013/Y.1731, November 2013.
[Y.1731-2013]ITU-T，“基于以太网的网络的OAM功能和机制”，ITU-T建议G.8013/Y.17311913年11月。
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q, December 2014.
[802.1Q]IEEE，“局域网和城域网的IEEE标准——网桥和桥接网络”，IEEE标准802.1Q，2014年12月。
[IEEE1588v1] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 1", IEEE Standard 1588, 2002.
[IEEE1588v1]IEEE，“网络测量和控制系统精确时钟同步协议的IEEE标准第1版”，IEEE标准15881002。
[IEEE1588v2] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2", IEEE Standard 1588, 2008.
[IEEE1588v2]IEEE，“网络测量和控制系统精确时钟同步协议的IEEE标准版本2”，IEEE标准15881008。
[MPLS-LM-DM] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011, <http://www.rfc-editor.org/info/rfc6374>.
[MPLS-LM-DM]Frost，D.和S.Bryant，“MPLS网络的数据包丢失和延迟测量”，RFC 63742011年9月<http://www.rfc-editor.org/info/rfc6374>.
[OAM] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011, <http://www.rfc-editor.org/info/rfc6291>.
[OAM]Andersson，L.，van Helvoort，H.，Bonica，R.，Romascanu，D.，和S.Mansfield，“IETF中使用“OAM”首字母缩写的指南”，BCP 161，RFC 62912011年6月<http://www.rfc-editor.org/info/rfc6291>.
[IPPM-1DM] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999, <http://www.rfc-editor.org/info/rfc2679>.
[IPPM-1DM]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月<http://www.rfc-editor.org/info/rfc2679>.
[IPPM-2DM] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999, <http://www.rfc-editor.org/info/rfc2681>.
[IPPM-2DM]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的往返延迟度量”，RFC 2681，1999年9月<http://www.rfc-editor.org/info/rfc2681>.
[IPPM-Loss] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999, <http://www.rfc-editor.org/info/rfc2680>.
[IPPM丢失]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向数据包丢失度量”，RFC 26801999年9月<http://www.rfc-editor.org/info/rfc2680>.
[OAM-Over] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, June 2014, <http://www.rfc-editor.org/info/rfc7276>.
[OAM Over]Mizrahi，T.，Sprecher，N.，Bellagamba，E.，和Y.Weingarten，“运营、管理和维护（OAM）工具概述”，RFC 72762014年6月<http://www.rfc-editor.org/info/rfc7276>.
Acknowledgments
致谢
The authors gratefully acknowledge Adrian Farrel, Alexey Melnikov, Jan Novak, Carlos Pignataro, Gagan Mohan Goel, Pete Resnick, and Prabhu Raj for their helpful comments.
作者衷心感谢阿德里安·法雷尔、阿列克谢·梅尔尼科夫、扬·诺瓦克、卡洛斯·皮格纳塔罗、加根·莫汉·戈尔、皮特·雷斯尼克和普拉布·拉吉的有益评论。
Authors' Addresses
作者地址
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel
Tal Mizrahi Marvell 6 Hamada St.Yokneam，20692以色列
EMail: talmi@marvell.com
EMail: talmi@marvell.com
Tissa Senevirathne Cisco 375 East Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞东塔斯曼大道375号，邮编95134
EMail: tsenevir@cisco.com
EMail: tsenevir@cisco.com
Samer Salam Cisco 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1 Canada
加拿大不列颠哥伦比亚省温哥华市伯拉德街595号2123室Samer Salam Cisco V7X 1J1
EMail: ssalam@cisco.com
EMail: ssalam@cisco.com
Deepak Kumar Cisco 510 McCarthy Blvd, Milpitas, CA 95035 United States
美国加利福尼亚州米尔皮塔斯麦卡锡大道510号迪帕克库马尔思科公司，邮编95035
Phone : +1 408-853-9760
EMail: dekumar@cisco.com
Phone : +1 408-853-9760
EMail: dekumar@cisco.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States
唐纳德·伊斯特莱克第三华为技术有限公司美国马萨诸塞州米尔福德海狸街155号01757
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com