[要約] RFC 7456は、TRILL（Transparent Interconnection of Lots of Links）における損失と遅延の測定に関するものであり、TRILLネットワークでのパフォーマンス測定のためのガイドラインを提供しています。目的は、TRILLネットワークのパフォーマンスを評価し、問題を特定して解決するための手法を提供することです。
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.
Performance Monitoring（PM）は、Operations、Administration、and Maintenance（OAM）の主要な側面です。これにより、ネットワークオペレーターは、顧客に提供されるサービスレベルアグリーメント（SLA）を確認し、ネットワークの異常を検出できます。このドキュメントでは、リンクの透過的な相互接続（TRILL）ネットワークでの損失測定と遅延測定のメカニズムについて説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]は、透過最小コストルーティング用のプロトコルです。ルーティングブリッジ（RBridges）は、ホップカウント付きの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]は、接続障害とパフォーマンスの低下を検出、分離、および報告するための一連のツールです。 Performance Monitoring（PM）はOAMの重要な側面です。 PMを使用すると、ネットワークオペレータはネットワークの異常や不正な動作を検出してデバッグできます。 PMは、損失測定と遅延測定という2つの主要な構成要素で構成されています。 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]で説明されています。これら2つのドキュメントでは、パフォーマンスモニタリングに関する主な要件についても説明しています。
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 損失測定：損失測定プロトコルは、2つの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 遅延測定：遅延測定プロトコルは、2つの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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
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の要件レベルは「SHOULD」です。それにもかかわらず、このメモは「MUST」を含む要件レベルの全範囲を使用します。このメモの要件は、「TRILL PMを実装するMEP（Maintenance End Point）を実装する必要があります（SHOULD / MAY / ...）」と読む必要があります。
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 パケット損失（[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
DoSサービス拒否
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
SLM合成損失測定メッセージ
SLR Synthetic Loss Measurement Reply
SLR合成損失測定応答
TLV Type-Length-Value
TLVタイプ-長さ-値
TRILL Transparent Interconnection of Lots of Links [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プロトコルは、メンテナンスエンドポイント（MEP）とメンテナンス中間ポイント（MIP）の2種類のメンテナンスポイント（MP）で動作します。
+-------+ +-------+ +-------+
| | | | | |
| 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機能は、MIPには適用されません。
As defined in [OAM-FRAMEWK], PM can be applied at three levels of granularity: Network, Service, and Flow.
[OAM-FRAMEWK]で定義されているように、PMは、ネットワーク、サービス、およびフローの3つのレベルの粒度で適用できます。
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はPMメッセージをRB2に送信し、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は、一方向のパフォーマンス監視をサポートする必要があります（SHOULD）。 TRILL PMを実装するMEPは、送信側RB1のPM機能と受信側RB2のPM機能の両方をサポートする必要があります（SHOULD）。
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がPMメッセージをリフレクターRB2に送信し、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からRB2へのパスのみを監視することがRB1にとって興味深い場合があることに注意してください。レシーバーRB2がこのパスを監視できる片方向PM（セクション3.2.1）とは対照的に、双方向PMは、送信者RB1がRB1から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は、フローエントロピーフィールドを、フローを識別するパラメータの1つとして使用します。双方向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メッセージを使用して2つの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は、マルチキャストメッセージを使用してPMメッセージを複数のRBridgeに送信します。リフレクター（双方向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.
損失測定プロトコルには、一方向の損失測定と双方向の損失測定の2つの動作モードがあります。
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間での一方向パケット損失を測定します。損失率は、一方向の合成損失測定（1SL）メッセージのセットを使用して測定されます。 1SLメッセージのパケット形式は、セクション6.2.2で指定されています。図2は、一方向の損失測定メッセージ交換を示しています。
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メッセージのセットを使用してパケット損失を測定します。この図は、セットからの2つの連続しないメッセージを示しています。
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」は現在の省略形であり、「p」は以前の省略形です。
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パケットのCounter 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)
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カウンターをクリアしてはなりません（SHOULD NOT）。
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つがラップアラウンドしたことをレシーバーが検出すると、レシーバーは式（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はSynthetic Loss Measurement Reply（SLR）で応答されます。 SLMおよびSLRパケットのパケット形式は、それぞれセクション6.2.3および6.2.4で指定されています。図3は、双方向の損失測定メッセージ交換を示しています。
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ハンドシェイクのセットを使用します。この図は、セットからの2つの連続しないハンドシェイクを示しています。
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パケットのCounter 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を含めることができます。 Reflector Entropy 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 リフレクターは、SLRのCounter TRXフィールドにTRXを組み込んでいます。
o The OpCode field in the OAM header is set to the SLR OpCode.
o OAMヘッダーのOpCodeフィールドは、SLR OpCodeに設定されます。
o The reflector assigns its MEP ID in the Reflector MEP ID field.
o リフレクターは、そのMEP IDをReflector 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メッセージには、Reflector Entropy 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パケットの送信元と宛先を反映するように変更されます。 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).
送信側は、プローブインスタンスの測定間隔に関してパケット損失を計算します。プローブインスタンスの測定間隔には、すべて同じテストIDを持つ一連のSLMメッセージとそれに対応するSLRメッセージが含まれます。パケット損失は、下付き文字「p」で示される測定間隔の最初のカウンターと下付き文字「c」で示される測定間隔の終わりのカウンターを比較することによって計算されます（図3に示すように） 。
far-end packet loss = (TXc-TXp) - (TRXc-TRXp) (2)
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.
上記の2つの式の計算は、カウンター値の違いに基づいており、送信側のカウンター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カウンターをクリアしてはなりません（SHOULD NOT）。
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）に従ってパケット損失を計算するとき、ラップアラウンドチェックを実行する必要があります。リフレクターは、カウンターの1つがラップアラウンドしたことを検出すると、式（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）の計算を無視することを選択できます（MAY）。この場合、送信者はReflector Entropy TLVを使用せずに、ピアMEPへのパスのフローベースのPMを実行できることに注意してください。
The Delay Measurement protocol has two modes of operation: one-way Delay Measurement and two-way Delay Measurement.
遅延測定プロトコルには、一方向遅延測定と双方向遅延測定の2つの動作モードがあります。
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
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が共通の基準時間に対して測定されることを意味します。したがって、一方向の遅延測定プロトコルを実行する2つのMEPは、時間同期する必要があります。 2つの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メッセージのマルチキャスト送信をサポートしてもよい（MAY）。
A 1DM message MAY be sent with a variable size Data TLV, allowing packet Delay Measurement for various packet sizes.
可変サイズのデータTLVを使用して1DMメッセージを送信できます。これにより、さまざまなパケットサイズのパケット遅延測定が可能になります。
The sender incorporates the 1DM packet's time of transmission into the Timestamp T1 field.
送信側は、1DMパケットの送信時間をTimestamp T1フィールドに組み込みます。
Upon receiving a 1DM packet, the receiver records its time of reception, T2. The receiver MUST verify two conditions:
1DMパケットを受信すると、受信機はその受信時間T2を記録します。受信者は次の2つの条件を検証する必要があります。
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.
一方向の遅延測定パケットが定期的に受信される場合、受信機は複数の測定に基づいてパケット遅延変動を計算してもよい（MAY）。 2つのピア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.
双方向遅延測定は、2つのMEP間の双方向パケット遅延を計算するために双方向ハンドシェイクを使用します。ハンドシェイクには2つのパケットが含まれます。遅延測定メッセージ（DMM）と遅延測定応答（DMR）です。 DMMおよびDMRパケット形式は、それぞれセクション6.3.3および6.3.4で指定されています。
The two-way Delay Measurement message exchange is illustrated in Figure 5.
双方向遅延測定メッセージ交換を図5に示します。
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 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を組み込んだDMMメッセージを生成します。リフレクターはDMMメッセージを受信し、その受信時刻T2を記録します。次に、リフレクターは、T1、T2、およびDMRの送信時間T3を組み込んだDMRメッセージを生成します。送信者はT4でDMRメッセージを受信し、4つのタイムスタンプを使用して、双方向パケット遅延を計算します。
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を含めることができます。 Reflector Entropy 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パケットの送信時間をTimestamp T1フィールドに組み込みます。
Upon receiving a DMM packet, the reflector records its time of reception, T2. The reflector MUST verify two conditions:
DMMパケットを受信すると、リフレクターは受信時刻T2を記録します。リフレクターは2つの条件を検証する必要があります。
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 リフレクターは、DMRのTimestamp T2フィールドに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ヘッダーのOpCodeフィールドは、DMR OpCodeに設定されます。
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メッセージには、Reflector Entropy 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を受信すると、リフレクターは変更されていないTLVをDMRに含めます。
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:
上記の両方の条件が満たされている場合、送信者は4つのタイムスタンプを使用して双方向遅延を計算します。
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.
2つのピアMEPが時間同期されていない場合でも、双方向遅延を計算できることに注意してください。一方、一方向遅延測定では、2つの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:
双方向遅延測定プロトコルを実行している2つのMEPは、時間同期される場合があります。 2つの時間同期MEP間で双方向遅延測定が実行される場合、送信者は次のように一方向遅延を計算できます（MAY）。
one-way delay {sender->reflector} = T2 - T1 (6)
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.
双方向遅延測定が定期的に実行される場合、送信者は複数の測定に基づいて遅延変動も計算できます（MAY）。
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）の計算を無視します。この場合、送信者はReflector Entropy 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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つのオクテットはすべてのOpCodeに共通ですが、残りはOpCode固有です。以下は、最初の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 OpCode：オペレーションコード（8ビット）。メッセージによって実行される操作を指定します。特定のパケット形式は、このドキュメントのセクション6.2および6.3に示されています。 PMメッセージOpCodesのリストは、セクション6.4にあります。
o Flags: The definition of flags is OpCode-specific. The value of this field is zero unless otherwise stated.
o フラグ：フラグの定義はOpCode固有です。特に明記しない限り、このフィールドの値はゼロです。
o FirstTLVOffset: defines the location of the first TLV, in octets, starting from the end of the FirstTLVOffset field.
o FirstTLVOffset：FirstTLVOffsetフィールドの終わりから始めて、最初のTLVの場所をオクテットで定義します。
o TLVs: one or more TLV fields. The last TLV field is always an End TLV.
o TLV：1つ以上のTLVフィールド。最後のTLVフィールドは常に終了TLVです。
For further details about the OAM packet format, including the format of TLVs, see [TRILL-FM].
TLVのフォーマットを含むOAMパケットフォーマットの詳細については、[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 .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 OpCode：セクション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：FirstTLVOffsetフィールドの終わりから始めて、最初のTLVの場所をオクテットで定義します。このフィールドの値は、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 Counter 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 .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 OpCode：セクション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：FirstTLVOffsetフィールドの終わりから始めて、最初のTLVの場所をオクテットで定義します。このフィールドの値は、SLMパケットでは16でなければなりません。
o Sender MEP ID: the MEP ID of the MEP that initiated this packet.
o 送信者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用に予約済み：このフィールドは、SLRに追加されるリフレクターのMEP ID用に予約されています。
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 Counter 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用に予約されています。リフレクターは、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 .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 OpCode：セクション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：FirstTLVOffsetフィールドの終わりから始めて、最初のTLVの場所をオクテットで定義します。このフィールドの値は、SLRパケットでは16である必要があります。
o Sender MEP ID: the MEP ID of the MEP that initiated the SLM that this SLR replies to.
o 送信者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：32ビットの一意のテスト識別子。対応するSLMメッセージからコピーされます。
o Counter TX: the value of the sender's transmission counter at the time of the SLM transmission.
o Counter 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）Precision Time Protocolタイムスタンプ形式[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 .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 OpCode：セクション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：FirstTLVOffsetフィールドの終わりから始めて、最初のTLVの場所をオクテットで定義します。このフィールドの値は、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 .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 OpCode：セクション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：FirstTLVOffsetフィールドの終わりから始めて、最初のTLVの場所をオクテットで定義します。このフィールドの値は、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用に予約済み：2つのタイムスタンプフィールドがDMRメッセージ用に予約されています。 1つのタイムスタンプフィールドはT3、DMR送信時間用に予約され、もう1つのフィールドは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 .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 OpCode：セクション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：FirstTLVOffsetフィールドの終わりから始めて、最初のTLVの場所をオクテットで定義します。このフィールドの値は、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が使用されます。
OpCode OAM packet
value type
------ ----------
45 1DM
45 1DM
46 DMR
46 DMR
47 DMM
47 DMM
53 1SL
53 1SL
54 SLR
54一眼レフ
55 SLM
55 SLM
These OpCodes are from the range of values that has been allocated by IEEE 802.1 [802.1Q] for control by ITU-T.
これらのOpCodeは、ITU-Tによる制御のためにIEEE 802.1 [802.1Q]によって割り当てられた値の範囲からのものです。
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.
Performance Monitoringプロセスは、PMセッションと呼ばれるいくつかのPerformance Monitoringインスタンスで構成されています。 PMセッションは、特定のフローの2つの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)
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（サービス拒否）が発生します。さらに、RBridgeにDoS攻撃を実装する手段として、悪意のあるPMメッセージが悪用される可能性があります。もう1つのセキュリティの側面は、ネットワークの偵察です。攻撃者は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の利点とそれがもたらす潜在的な測定の不正確さを比較検討する必要があり、このトレードオフに基づいて、オペレーターは認証を使用するかどうかを決定する必要があります。
[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、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年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.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、RFC 7172、May 2014、<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 7455、2015年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、「多数のリンクの透過的な相互接続における運用、管理、および保守（OAM）の要件（ TRILL）」、RFC 6905、2013年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 3度、「リンクの透過的な相互接続（TRILL）操作、管理、および保守（OAM）フレームワーク」、RFC 7174 、2014年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.1731、2013年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 Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks」、IEEE Std 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 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 1」、IEEE Standard 1588、2002。
[IEEE1588v2] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2", IEEE Standard 1588, 2008.
[IEEE1588v2] IEEE、「ネットワーク化された測定および制御システムバージョン2の高精度クロック同期プロトコルのIEEE標準」、IEEE標準1588、2008。
[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 6374、2011年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 6291 、2011年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.、Kalidindi、S。、およびM. Zekauskas、「A IP-way Delay Metric for 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.、Kalidindi、S。、およびM. Zekauskas、「A IP-Round-trip Delay Metric for 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-Loss] Almes、G.、Kalidindi、S.、およびM. Zekauskas、「A IP-way Packet Loss Metric for IPPM」、RFC 2680、1999年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 7276、2014年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.
著者らは、有益なコメントを提供してくれたAdrian Farrel、Alexey Melnikov、Jan Novak、Carlos Pignataro、Gagan Mohan Goel、Pete Resnick、Prabhu Rajに感謝の意を表します。
Authors' Addresses
著者のアドレス
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel
Tal Mizrahi Marvell 6 Hamada St. Yokneam、20692 Israel
EMail: talmi@marvell.com
Tissa Senevirathne Cisco 375 East Tasman Drive San Jose, CA 95134 United States
Tissa Senevirathne Cisco 375 East Tasman Drive San Jose、CA 95134アメリカ合衆国
EMail: tsenevir@cisco.com
Samer Salam Cisco 595 Burrard Street, Suite 2123 Vancouver, BC V7X 1J1 Canada
Samer Salam Cisco 595 Burrard Street、Suite 2123 Vancouver、BC V7X 1J1 Canada
EMail: ssalam@cisco.com
Deepak Kumar Cisco 510 McCarthy Blvd, Milpitas, CA 95035 United States
Deepak Kumar Cisco 510 McCarthy Blvd、Milpitas、CA 95035アメリカ合衆国
Phone : +1 408-853-9760
EMail: dekumar@cisco.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford、MA 01757アメリカ合衆国
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com